Do not ask for updating .copier-answers.yml

I did not expect to have to force update .copier-answers.yaml after running copier update, so I'm probably doing something wrong...
This is my result at copier update:
PS C:\copier-template> cd ..
PS C:\> copier update myproj
No git tags found in template; using HEAD as ref

package_name? Format: yaml
...
copyright_license? Format: yaml
🎤 [CC-BY-4.0]:
Either 1b4d418 or None is not a PEP 440 valid version.

    create  .gitignore
 identical  copier.yaml
 identical  pyproject.toml
  conflict  .copier-answers.yml
 Overwrite C:\myproj\.copier-answers.yml? [Y/n]
     force  .copier-answers.yml

(I now also noted that stray comment about Either 1b4d418 or None is not a PEP 440 valid version....)
The changes in .copier-answers.yml doesn't strike me as odd, (except perhaps the ^M ;-)
PS C:\> cd myproj
PS C:\myproj> git diff
diff --git a/.copier-answers.yml b/.copier-answers.yml
index 2850703..ba49cb9 100644
--- a/.copier-answers.yml
+++ b/.copier-answers.yml
@@ -1,5 +1,5 @@
 # Changes here will be overwritten by Copier
-_commit: 1b4d418
+_commit: a86b2dd^M
 _src_path: copier-template
 author_email<EMAIL_ADDRESS> author_name: Cecron

I'm on Windows 10 and the full transcript of my actions are:
Create a directory to place the template in:
PS C:\> mkdir copier-template
PS C:\> cd copier-template

Create a short pyproject.toml.tmpl with ninja variables like [[ package_name ]]:
PS C:\copier-template> type pyproject.toml.tmpl
[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

[tool.poetry]
name = "[[ package_name ]]"
version = "0.1.0"
description = "[[ package_description ]]"
authors = ["[[ author_name ]] <[[ author_email ]]>"]
maintainers = ["[[ author_name ]] <[[ author_email ]]>"]
license = "[[ copyright_license ]]"
readme = "README.rst"

[tool.poetry.dependencies]
python = "^3.8"

[tool.poetry.dev-dependencies]
pytest = "^5.2"

Create copier.yaml with questions and settings
PS C:\copier-template> type copier.yaml
package_name: my-package
package_description: A short description of the package.
author_name: Cecron
author_email<EMAIL_ADDRESS>copyright_license: "CC-BY-4.0"

_exclude:
    # Exclude git repo
    - ".git"
    # Don't match emacs backup files
    - "*~"

Create [[ _copier_conf.answers_file ]].tmpl so copier registers answers
PS C:\copier-template> type *answers*
# Changes here will be overwritten by Copier
[[_copier_answers|to_nice_yaml]]

Register template and commit to git:
PS C:\copier-template> git init
PS C:\copier-template> git add .
PS C:\copier-template> git commit -m "Initial template version"

Run copier to create project
PS C:\copier-template> cd ..
PS C:\> copier copier-template myproj
  # Answer questions
  package_name? Format: yaml
  🎤 [my-package]:
  package_description? Format: yaml
  🎤 [A short description of the package.]:
  author_name? Format: yaml
  🎤 [Cecron]:
  author_email? Format: yaml
  🎤<EMAIL_ADDRESS>  copyright_license? Format: yaml
  🎤 [CC-BY-4.0]:
      create  copier.yaml
      create  pyproject.toml
      create  .copier-answers.yml

Run Poetry to install project dependencies and create Python virtual environment
PS C:\> cd myproj
PS C:\myproj> poetry install

Register project and commit to git:
PS C:\myproj> git init
PS C:\myproj> git add .

PS C:\> copier update myproj
No git tags found in template; using HEAD as ref

package_name? Format: yaml
🎤 [my-package]:

package_description? Format: yaml
🎤 [A short description of the package.]:

author_name? Format: yaml
🎤 [Cecron]:

author_email? Format: yaml
🎤<EMAIL_ADDRESS>
copyright_license? Format: yaml
🎤 [CC-BY-4.0]:
Either 1b4d418 or None is not a PEP 440 valid version.

    create  .gitignore
 identical  copier.yaml
 identical  pyproject.toml
  conflict  .copier-answers.yml
 Overwrite C:\myproj\.copier-answers.yml? [Y/n]
     force  .copier-answers.yml

Hi and welcome to copier!

I did not expect to have to force update .copier-answers.yaml after running copier update, so I'm probably doing something wrong...

Relax, it's OK.
This is a small pain point that I still didn't have time to fix.  It should be a forced "yes" always.
Until it's fixed, just say yes always 🤷🏼♂

(I now also noted that stray comment about Either 1b4d418 or None is not a PEP 440 valid version....)
The changes in .copier-answers.yml doesn't strike me as odd, (except perhaps the ^M ;-)

Well, these changes reveal you're not using git tags to version your template.
If you don't Copier might get tricked about which commit is newer, so it's better if you start versioning it 😉

Hi and welcome to copier!

I did not expect to have to force update .copier-answers.yaml after running copier update, so I'm probably doing something wrong...

Relax, it's OK.
This is a small pain point that I still didn't have time to fix.  It should be a forced "yes" always.
Until it's fixed, just say yes always 🤷🏼♂

(I now also noted that stray comment about Either 1b4d418 or None is not a PEP 440 valid version....)
The changes in .copier-answers.yml doesn't strike me as odd, (except perhaps the ^M ;-)

Well, these changes reveal you're not using git tags to version your template.
If you don't Copier might get tricked about which commit is newer, so it's better if you start versioning it 😉

Hi and welcome to copier!

I did not expect to have to force update .copier-answers.yaml after running copier update, so I'm probably doing something wrong...

Relax, it's OK.

Thanks!

(I now also noted that stray comment about Either 1b4d418 or None is not a PEP 440 valid version....)
The changes in .copier-answers.yml doesn't strike me as odd, (except perhaps the ^M ;-)

Well, these changes reveal you're not using git tags to version your template.
If you don't Copier might get tricked about which commit is newer, so it's better if you start versioning it 😉

I'll look into adding tags in my work flow right away!
(Also, thanks for editing my post adding the "Details" tag. I was actually looking for something like that when writing my post, and now I learned how to do it!)

Hi and welcome to copier!

I did not expect to have to force update .copier-answers.yaml after running copier update, so I'm probably doing something wrong...

Relax, it's OK.

Thanks!

(I now also noted that stray comment about Either 1b4d418 or None is not a PEP 440 valid version....)
The changes in .copier-answers.yml doesn't strike me as odd, (except perhaps the ^M ;-)

Well, these changes reveal you're not using git tags to version your template.
If you don't Copier might get tricked about which commit is newer, so it's better if you start versioning it 😉

I'll look into adding tags in my work flow right away!
(Also, thanks for editing my post adding the "Details" tag. I was actually looking for something like that when writing my post, and now I learned how to do it!)


Android Basics: Activities and intents, Starter branch missing @layout/word_item_view

URL of codelab
https://github.com/google-developer-training/android-basics-kotlin-words-app/blob/starter/app/src/main/res/layout/activity_detail.xml
In which task and step of the codelab can this issue be found?
<androidx.recyclerview.widget.RecyclerView
        android:id="@+id/recycler_view"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:clipToPadding="false"
        android:padding="16dp"
-      tools:listitem="@layout/word_item_view" />
+     tools:listitem="@layout/item_view" />

Describe the problem
word_item_view does not exist in res>layout. It should be @layout/item_view not @layout/word_item_view

Thanks for filing! This should be fixed in https://github.com/google-developer-training/android-basics-kotlin-words-app/pull/209

Btw, there's a few things missing from the lunch-tray-app. I tried submitting a pull request with the changes but it wouldn't go through. It says "Missing CLA from one or more contributors." I signed up for CLA at the link but it says I have to ask a repo manager to rescan the PR.
Repo: https://github.com/google-developer-training/android-basics-kotlin-lunch-tray-app
Issues:

In activity_main.xml the ConstraintLayout is missing tools:context=".MainActivity"
In NavigationTest.kt all instances of startOrder need to be changed to startOrderFragment
In EntreeMenuFragment, SideMenuFragment, AccompanimentMenuFragment, and CheckoutFragment the override fun onCreate(savedInstanceState) method is unnecessary and can be removed because it's not adding anything new to the inheritted method. I suppose it could be left in there for eductional purposes but it might be helpful to leave comment mentioning that it's not necessary and can be removed.

Lastly, I'm not 100% sure I did everything correctly but I'm pretty sure I did. I passed all tests except for radio_buttons_update_entree_menu_subtotal and radio_buttons_update_accompaniment_menu_subtotal.
Error for radio_buttons_update_entree_menu_subtotal:
androidx.test.espresso.base.DefaultFailureHandler$AssertionFailedWithCauseError: 'with text: a string containing "Subtotal: $3.00"' doesn't match the selected view. Expected: with text: a string containing "Subtotal: $3.00"
Error for radio_buttons_update_accompaniment_menu_subtotal:
androidx.test.espresso.base.DefaultFailureHandler$AssertionFailedWithCauseError: 'with text: a string containing "Subtotal: $1.00"' doesn't match the selected view. Expected: with text: a string containing "Subtotal: $1.00"
I don't know if you caught that but it looks like the issue seems to be that it's adding an extra ' after the subtotal which doesn't really make sense to me because that test runs containsString() and it clearly shows that it does contain that string.
The reason why I think it's an issue with the test is because all other tests including the test for  radio_buttons_update_entree_menu_subtotal pass and when I manually test my app everything seems to work correctly.
Oh also, I had a question how come in this codelab: https://developer.android.com/codelabs/basic-android-kotlin-training-livedata?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-3-pathway-3%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-livedata#6
...they have us change the FragmentBinding to DataBindingUtil but in subsequent codelabs it's not used. Just thought that was a little confusing and could possibly use clarification about when it's necessary to use and when it's not.

Here is my finished app if you want to check it out: https://github.com/shawn-fetanat/kotlin-completed-lunch-tray-app


OCPBUGS-35569: Replace wildcards by explicit list of verbs

OCPBUGS-35569

/approve
/lgtm

/retitle OCPBUGS-35569: Replace wildcards by explicit list of verbs

/jira refresh

From https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-kube-descheduler-operator/361/pull-ci-openshift-cluster-kube-descheduler-operator-master-e2e-aws-operator/1802687780015312896/artifacts/e2e-aws-operator/gather-extra/artifacts/pods/openshift-kube-descheduler-operator_descheduler-operator-575dc566d8-mjn82_descheduler-operator.log:
E0617 13:49:18.428021       1 target_config_reconciler.go:682] key failed with : clusterroles.rbac.authorization.k8s.io "openshift-descheduler-operand" is forbidden: user "system:serviceaccount:openshift-kube-descheduler-operator:openshift-descheduler" (groups=["system:serviceaccounts" "system:serviceaccounts:openshift-kube-descheduler-operator" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:["coordination.k8s.io"], Resources:["leases"], ResourceNames:["descheduler"], Verbs:["patch" "delete"]}
{APIGroups:["events.k8s.io"], Resources:["events"], Verbs:["get" "watch" "list" "create" "update" "patch" "delete"]}

/hold

{APIGroups:["coordination.k8s.io"], Resources:["leases"], ResourceNames:["descheduler"], Verbs:["patch" "delete"]}

Corresponds to https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/test/e2e/bindata/assets/03_clusterrole.yaml#L74-L80, resp. https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/manifests/cluster-kube-descheduler-operator.clusterserviceversion.yaml#L190-L197.

{APIGroups:["events.k8s.io"], Resources:["events"], Verbs:["get" "watch" "list" "create" "update" "patch" "delete"]}

https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/test/e2e/bindata/assets/03_clusterrole.yaml, resp. https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/manifests/cluster-kube-descheduler-operator.clusterserviceversion.yaml#L124-L206 does not have "events.k8s.io" as all.

This is interesting. Looks like * verbs have no validation when it comes to "granting RBAC permissions not currently held"

@kramaranya can you please add the missing verbs/resources into both https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/test/e2e/bindata/assets/03_clusterrole.yaml and https://github.com/openshift/cluster-kube-descheduler-operator/blob/master/manifests/cluster-kube-descheduler-operator.clusterserviceversion.yaml#L124-L206?

FYI: manifests/cluster-kube-descheduler-operator.clusterserviceversion.yaml is not tested by the CI. So both manifests/cluster-kube-descheduler-operator.clusterserviceversion.yaml and test/e2e/bindata/assets/03_clusterrole.yaml needs to be in sync.

["system:serviceaccounts" "system:serviceaccounts:openshift-kube-descheduler-operator" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["endpoints"], Verbs:["get" "list" "watch"]}

looks better :) test/e2e/bindata/assets/03_clusterrole.yaml needs to be extended with:
- apiGroups:
  - ""
  resources:
  - "endpoints"
  verbs:
  - "get"
  - "watch"
  - "list"

Thank you. Much appreciated.
/lgtm


Main Menu

Some thoughts:

Do we need the resolution or quality options? Might be extra work to implement the quality specifically, but I have no idea
Before merging, we need to update this branch from main and then hook up the "start" to put us in either the basement scene or a new scene before that which introduces the story AND THEN goes into the basement
Also after merging from main try to clean up the Assets directory, like moving the main menu and settings scripts into Assets/Scripts

Also, it would be nice for us to have a "credits" with the names of everyone, and also a logo+title for our club

Resolution seems hard but quality we would just need to go to the projects quality setting and copy settings from something else
I think do we should introduce the story & controls after pressing start
I will clean up the directory
do you want credits before the story or in their own button in the main menu, and do you want the logo on the main menu or the credits

Resolution seems hard but quality we would just need to go to the projects quality setting and copy settings from something else

Feel free to research this and update, I have no idea how it works so maybe its feasible!

I think do we should introduce the story & controls after pressing start

I can create a new task for somebody to make an "intro" scene which segways from main menu into basement (effectively a slideshow giving info as text)

do you want credits before the story or in their own button in the main menu, and do you want the logo on the main menu or the credits

I think we should just put the logo in the corner of the main menu, and then have credits play at the end of the game with names as well as the logo again

I agree with everything Ryan mentioned above.

I think we should just put the logo in the corner of the main menu, and then have credits play at the end of the game with names as well as the logo again

@Cavekitty16 I want to note that the UI does not need to be perfect right now. Just put stuff in a "nice" spot for now and we can always adjust it later.

I just created the intro slideshow scene ( #22 ), which you can hook up the play button to when it gets merged

The main blockers to merge are:

hooking up the play button to load the intro cutscene
removing the settings menu?
putting the logo on?
cleaning up the assets

#22 merged, should be all ready for you to hook into

I don't see where the cutscene is, I hid the settings and added the logo


Resized title and paragraph to fit a map on the right

I was told that a map was going to be put in the landing page, so I resized the text to fit in said map.

map on landing postponed, probably going to just ditch the site as a whole soon


Upgrade to Elixir 1.11 and use multistage Dockerfile

Plan

Upgrade to Elixir 1.11
Create multistage docker file for quicker releases

Use hexpm elixir images which are more explicit on the Erlang, Alpine and Elixir versions used. Also they are locked to those versions to prevent breaking deploys in the future.

@benawad if you are good with this plan assign this to me and I will do it either today or Monday.

that would be great!

Closed by: #1020


slash commands

will added in discord js v13 so i will wait

discord js v13 is out now, so i rewrite menus and add slash commands


PFORM-3233

Export-Migration will now include extended properties on schemas, views, and view columns.

This should target the develop branch. I think you've got more Rivet work, so let's accumulate it all into one release before actually releasing it.


Update to suit standards.calconnect.org flow

exe/relaton-metanorma-extract is now combines Relaton files into a "Relaton collection", and automatically inserts file links if the files exist (HTML, PDF, DOC, XML)
exe/relaton-yaml-xml now creates with extension .rxl (for Relaton XML) and allows setting a prefix for generated, individual Relaton entry files.
namespace for Bibcollection is changed to https://open.ribose.com/relaton-xml
docidentifier is now called docidentifier everywhere, not docid

The thing is, those scripts relaton-metanorma-extract and relaton-yaml-xml  are meant to be replaced by thor functionality within lib/cli/command.rb . Reopening ticket to take care of that.

Functionality moved to Thor scripts.


Define nfs export_arguments per equipment group

Hi everyone,
We're looking for a solution to define export_arguments per equipment group. Our use-case is we need no_root_squash option for some cluster administration purposes but we would prefer to clearly choose the type of nodes we allow it.
What do you think about implementing such feature into bluebanquise ?
Thanks
Mathis

Dear @gavillom
This is already implemented.
If I understand you well, you wish to specify different nfs parameters per equipment profiles ?
Solution is the following: group_vars/equipment_X has greater precedence over group_vars/all.
So you can define in group_vars/all/general_settings/nfs.yml some parameters, and define others in group_vars/equipment_X/nfs.yml. All hosts will use the one from group_vars/all/general_settings/nfs.yml, and memebers of equipment_X will use the one from group_vars/equipment_X/nfs.yml.
Would that be what you are looking for ? 😊

@oxedions,
My functional need is to have a way to enable no_root_squash option that is part of export_arguments parameter only for few client node types (for example, I want to have root access on a mangement node to my NFS filesystems and not on compute nodes).
So from what I understand, export_arguments (that is used by nfs_server role) will take care of global nfs settings and not per equipment type. Am I right ?
For mount parameter (used by nfs_client role), I agree that would work. But this is not what I'm looking for.

Dear @gavillom
You are right, my apologies, I did not understood your need.
Please give me few days to compute that need. If you have a nice idea between on how to format inventory for that, please do not hesitate to propose 😊
Have a nice weekend !

No problem.
I've done a small POC on my side with the following inventory definition.
nfs:
  my_mountpoint:
    mount: /my_mountpoint
    export: /my_mountpoint
    server: nfs-server
    clients_groups:
      - name: mg_managements
        export_arguments: rw,no_root_squash,async
      - mg_computes
      - mg_logins
    take_over_network: ib0
    export_arguments: rw,root_squash,async
    mount_arguments: nfsvers=4.2,bg

This lets the ability to support current nfs inventory definition and also can provide some export_arguments for some equipment_groups. I can propose a PR if this definition suits you.
Have a nice week

Dear @gavillom
Thanks a lot.
So to generate export file, you iterate over each hosts inside mg_management group and add their main ip on the same line ?

@oxedions,
Not on the same line. But each host on a dedicated line. But this can do a huge file, you're right.
From exports man :

Machine  names may contain the wildcard characters * and ?, or may contain character class lists within [square brackets].

Would it be possible to have something like nodeset format ? Would be interesting to make some tests on it.
Mathis

You could rely on Wildcards and DNS lookup:
https://www.golinuxcloud.com/nfs-exports-options-examples/
But this is not really nodeset compliant. Note that in the next BB (1.5) we provide a nodeset filter.

Small test done today :
[root@homenfs ~]# cat /etc/exports
/exports/counter m0-ib0.bench.local(rw,no_root_squash,async)
/exports/counter c[172-173]-ib0.bench.local(rw,no_root_squash,async)
/exports/counter g[430-431]-ib0.bench.local(rw,no_root_squash,async)
/exports/counter <IP_ADDRESS>/16(rw,root_squash,async)

[root@c173 ~]# mkdir /counter/test
mkdir: cannot create directory ‘/counter/test’: Permission denied

[root@m0 bluebanquise]# mkdir /counter/test2
[root@m0 bluebanquise]#

Works with single node definition but not with group of nodes definition. I think it won't be easy to define group of nodes into /etc/exports file.

Only solution I see is to add one line per host.
This can be done, but may be a bit ugly.
But you are right, in its current shape this role cannot do advanced configurations. We need to redesign it a bit.
I need to finish an urgent task, and I will focus on your need 😊

Hello @gavillom
Do you have any updates ? Is the need still valid ?
Ox


double-beep: Watch (?:(mahendra|best)\W*)?eye\W*hospital

double-beep requests the watch of the watch_keyword (?:(mahendra|best)\W*)?eye\W*hospital. See the MS search here and the Stack Exchange search here.

(?:(mahendra|best)\W*)?eye\W*hospital has been seen in 2 true positives, 0 false positives, and 0 NAAs.

!!/approve

Approved by tripleee in Charcoal HQ


How to integrate it with mongodb

Please take a look here http://stackoverflow.com/questions/29606290/authentication-with-spring-security-spring-data-mongodb
or search Google with something like "spring security with mongodb".


the merc web vest is incorrectly contraband marked

Description

it's marked as syndicate contraband, which is incorrect as it is not affiliated with the syndicate
it should be marked as major contraband as it is still contraband but is not affiliated with the syndicate
this should be upstreamed by the way

fixed, was using the web vest as a parent so it was automatically adopting syndicate contraband level

When the test build is outdated :finnadie:


feature request: balanced shuffle for tvshows (shuffle in order)

a balanced shuffle for tv shows to prevent shows with more episodes dominating the schedule and shows with less episodes hardly playing at all

A way to balance the chance of a show being picked would be lovely

I think this can now be achieved with Fill With Group Mode added with #1534 - every show (group) within a collection will be played for the same time (duration) or number of items (multiple), which effectively balances the schedule.

..also for fillers will be great!, so they will be less grouped...perhaps a simple 1 from each collection even if shorter colections gets repeated ....

"Fill With Group Mode" doesn't work with "Shuffle In Order". Get warning: Unable to build playout 26: Unexpected error building playout for channel: Sequence contains no elements.
This is correct since Fill with Group Mode should work with Shuffle in that it airs the shorter shows more times than long shows, so it won't be a shuttle anymore. Probably should not allow this Fill with Group Mode with Shuffle and Shuffle In Order.

Working on a PR of balanced random (random rotation) schedule for block.


pull request for e2e test at 01/24/2017 00:15:09

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Errors due to usage of deprecated 'np.int'

The alias 'np.int' for the builtin 'int' was deprecated with NumPy 1.20.0. This leads to errors when running the example commands from the README.md after a fresh install.

Thank you for pointing this out and making the required pull request. We will run tests and merge your pull request.


Pause and resume actions or not?

Context
The definition of the startPause action [6.8.1] states: "... Actions can continue...", whereas the definition of the stopPause action states: "... Movement and all other actions will be resumed (if any)..."
The "finished" column in the table in [6.8.2] suggests that actions should be paused (startPause: "... All actions will be paused..." and stopPause: "... All paused actions will be resumed...").
Questions

Is it safe to assume that actions should be paused and that the first quote is a mistake?
If used in a preemptive fashion as described in Issue #8 (which makes perfect sense to me - if I want to pause something, I must preempt it), do we maybe need some additional flag indicating whether or not to resume any preempted actions?

if you have atomic actions you may delay the action result until this action if finished, and the mark the pause action as finished. or you reject the pause action with an error.
so would prefer the first way.

@AntonDueck : I agree; if an already running action cannot be paused, the state of 'startPause' is RUNNING, until the running action is finished. Rejecting 'startPause' would be unlucky, because it depends on timing whether  'startPause' is accepted or not.

you have to inspect the action result (of all actions) after your instant action is finished to see what is been paused and which actions have finished.


Concerns about the scope of the solution

I started writing this in reply to https://github.com/tc39/proposal-extractors/issues/18#issuecomment-2040769594, but realized that I was sidetracking that issue. My concerns aren't really about the problem statement, but about the scope within which a solution to the problem is desirable.
Overall, I get the value of extraction within the context of pattern matching, but not really outside that. Inside match or with an is test, the reader is primed to expect validation and, potentially, extraction. But in destructuring or elsewhere, not so much. In those other places, it comes as added complexity, and doesn't really bring a great benefit compared to current syntax patterns.
Reviewing past presentations and discussions of this proposal, it seems like I'm echoing concerns raised by @brad4d during the 2022-09 meeting:

BSH: Yeah, my main concern here is, I feel like this feature is creating a way to write code that's very terse and clever but not necessarily easier to get right or easier to understand. In several of the examples, it looks to me like, you'd have to - to really know what's going on you would have to go and read what the extractor code does to understand. Well, what things can I use this extractor with? And what can I put on the right hand side? I don't see the benefit to balance out the readability. or what, wait, what does this in some way? Let you write more efficient code easily. or does it somehow - aside from the magical feeling and cleverness, what's the benefit?
[...] So I think what would address this - Not something you can do now, but what would address my concern here, is if I could have a solid example of some code. Like, here's how you would write the code with this feature available and here's how you write it without it, and it's not just that it's shorter, but it should be actually easier to understand and maybe more performant. because, there's some benefit that you're getting performance-wise out of like the environment doing this for you. That's what I would need to see. That's all I'm saying. I'm not trying to block this or anything. I just that's that's my concern. I feel like it's just feels too clever and not really overall beneficial. That's it for me.

In other words, my concern is that the examples currently in the readme or presented in the preceding discussion don't really seem like they present the new syntax as "easier to understand and maybe more performant".

Extractors encourage a leaner coding style that is often preferred by JS developers and is regularly seen in other languages with language features like Pattern Matching:
// (assumes Point.{ x, y } are public for the purpose of this example)

const { p1, p2 } = line; // top-level destructuring
if (!(p1 instanceof Point) || !(p2 instanceof Point)) throw new Error(); // data validation
const { x: x1, y: y1 } = p1; // nested destructuring
const { x: x2, y: y2 } = p2; // nested destructuring

// vs
const { p1: Point(x1, y1), p2: Point(x2, y2) } = line;

On the other hand, if we were to presume an equivalent Point definition like
class Point {
  #x;
  #y;
  constructor(x, y) {
    this.#x = x;
    this.#y = y;
  }
  static extract(subject) {
    return #x in subject ? [subject.#x, subject.#y] : false;
  }
}

the user code could look like
const [x1, y1] = Point.extract(line.p1);
const [x2, y2] = Point.extract(line.p2);

Sure, that doesn't do the work all on one line and during the destructuring, but the result is the same and much clearer to a reader, given that each part of the code is only doing one thing.

In addition to the conciseness of Extractors in destructuring, they also allow for optimal short-circuiting in Pattern Matching:
match (shape) {
  when { p1: Point(let p1), p2: Point(let p2) }: drawLine(p1, p2);
  ...
}

Here, the brand check in Point[Symbol.customMatcher] allows the pattern to attempt to match p1 and if that fails, short-circuit to the next when clause.

Ok, I'll grant you that in this case we do save one access of shape.p1 and shape.p2 compared to what's possible with switch, which also requires the break:
switch (true) {
  case shape.p1 instanceof Point && shape.p2 instanceof Point:
    drawLine(shape.p1, shape.p2);
    break;
  ...
}

Presuming that a Line class was being used, and with perhaps more common JS, those issues can be avoided:
if (shape instanceof Line) drawLine(shape.p1, shape.p2);
else ...

Another place they shine is within parameter lists where there is no Statement context within which to split out code without shifting work to the body:
function encloseLineInRect(
  {p1: Point(x1, y1), p2: Point(x2, y2)},
  padding = defaultPadding(x1 - x2, y1 - y2)
) {
  const xMin = Math.min(x1, x2) - padding;
  const xMax = Math.max(x1, x2) + padding;
  const yMin = Math.min(y1, y2) - padding;
  const yMax = Math.max(y1, y2) + padding;
  return new Rect(xMin, yMin, xMax, yMax);
}

function defaultPadding(dx, dy) {
 // use larger padding if x or y coordinates are close
 if (Math.abs(dx) < 0.5 || Math.abs(dy) < 0.5) {
   return 2;
 }
 return 1;
}

const rect = encloseLineInRect(line);

Here, extractors let you validate the input arguments and extract coordinates without needing to shift default argument handling for padding to the body.

On the other hand, if we were to presume that Point provided public accessors x and y, our code could look like:
function encloseLineInRect(
  { p1: { x: x1, y: y1 }, p2: { x: x2, y: y2 } },
  padding = defaultPadding(x1 - x2, y1 - y2)
) {
  ...
}

If the author of Point did require always getting both coordinates at the same time, then it'd probably make more sense to handle the default padding in the body:
function encloseLineInRect({ p1, p2 }, padding) {
  const [x1, y1] = Point.extract(p1);
  const [x2, y2] = Point.extract(p2);
  padding ??= defaultPadding(x1 - x2, y1 - y2);
  ...
}

Actually, having written out those alternatives, this last one is by far the clearest to me, as each part of it is only doing one thing, and it's much clearer that extracting the values actually involves some work.
Why should having this code in the function body be considered a bad thing?

My concerns aren't really about the problem statement, but about the scope within which a solution to the problem is desirable.
Overall, I get the value of extraction within the context of pattern matching, but not really outside that. Inside match or with an is test, the reader is primed to expect validation and, potentially, extraction. But in destructuring or elsewhere, not so much. In those other places, it comes as added complexity, and doesn't really bring a great benefit compared to current syntax patterns.

When I first discussed extractors with the Pattern Matching champions, their position was that Extractors must be part of destructuring if they are included in pattern matching, and I agree. There are clear parallels between the two syntaxes. Destructuring is, in its way, a limited form of pattern matching with no branching. Statements like const {x, y} = obj; and const [a, b] = ar; do perform validation, with the first expecting an object and the second expecting an iterable.
I've also received a fair amount feedback from @littledan and others that, should pattern matching have this capability, then the same capability must be available in destructuring as well.
If we limited extractors to pattern matching alone we end up with a significant discrepancy between the conditional pattern syntax and non-conditional destructuring. This heavily impacts refactoring in cases where a function that previously accepted multiple possible types of inputs is rewritten to accept a single type of input. For example, let's say you are rewriting code containing a branching match clause`:
match (value) {
    when Point(let x, let y): ...;
    when Line(let p1, let p2): ...;
}

As part of this rewrite, you determine that value can now only receive Point values, thus the other match legs are unnecessary. With extractors in destructuring, the refactor is fairly straightforward:
const Point(x, y) = value;

It is also consistent with an equivalent refactor from when [let a, let b] to const [a, b] or when { let x, let y } to const { x, y }.
Without extractors in destructuring, you have to either convert to is and variable patterns and roll your own error handling
if (!(value is Point(const x, const y))) throw new Error();

or manually validate and read values across multiple statements. While is/const is a valid use for variable patterns, it's far less readable or convenient than const Point(x, y). If you refactor to multiple statements, you have to ensure you can replicate the same validation logic the extractor performs (probably by also using is), and the extracted values must be reachable outside of the extractor. That refactoring might require visual inspection of the [Symbol.customMatcher] method to ensure rules are consistently applied, which will likely result in code duplication.
The extractor concept is not a new one. The syntax and semantics are directly inspired by Scala and Rust. For example, Rust supports let (x, y) = obj;, which is roughly the equivalent of const [x, y] = obj; in JS, and let Point(x, y) = obj; which would be the equivalent of const Point(x, y) = obj; in JS. In Rust every variable binding is just pattern matching, but that's not an option for JS. In the Pattern Matching proposal I've already had discussions with the champions about the possibility of extending the existing destructuring syntax to a full pattern matching syntax, but that direction was ultimately rejected — destructuring offers no mechanism to reference a value in scope, which would be necessary for patterns like x is +Infinity or x is undefined, and does not have the correct exhaustiveness requirements for array patterns since [1, 2] in pattern matching is exhaustive (input must have exactly two elements) while [a, b] in destructuring is not exhaustive.

Reviewing past presentations and discussions of this proposal, it seems like I'm echoing concerns raised by @brad4d during the 2022-09 meeting:

BSH: Yeah, my main concern here is, I feel like this feature is creating a way to write code that's very terse and clever but not necessarily easier to get right or easier to understand. In several of the examples, it looks to me like, you'd have to - to really know what's going on you would have to go and read what the extractor code does to understand. Well, what things can I use this extractor with? And what can I put on the right hand side? I don't see the benefit to balance out the readability. or what, wait, what does this in some way? Let you write more efficient code easily. or does it somehow - aside from the magical feeling and cleverness, what's the benefit?
[...] So I think what would address this - Not something you can do now, but what would address my concern here, is if I could have a solid example of some code. Like, here's how you would write the code with this feature available and here's how you write it without it, and it's not just that it's shorter, but it should be actually easier to understand and maybe more performant. because, there's some benefit that you're getting performance-wise out of like the environment doing this for you. That's what I would need to see. That's all I'm saying. I'm not trying to block this or anything. I just that's that's my concern. I feel like it's just feels too clever and not really overall beneficial. That's it for me.

In other words, my concern is that the examples currently in the readme or presented in the preceding discussion don't really seem like they present the new syntax as "easier to understand and maybe more performant".

I've since added further examples to the explainer and in the slides presented in February, but I'm happy to add more.
I believe the extractor syntax itself is not terribly difficult to learn and understand, especially if the same syntax in pattern matching gains significant traction in the community, which I expect it will. The most common forms of extractors will be duals to constructors:
const p = new Point(1, 2);
const Point(x, y) = p;

This duality is also an important characteristic to a planned future proposal for ADT enums, as an evolution of the enum proposal Jack Works previously presented and the enum proposal I'd been working on. The current design for ADT enums would maintain this duality, leveraging extractors as a JS mechanism to mirror similar mechanisms in languages like Scala, Rust, C#, etc.:
enum Message {
    FillBackground({ r, g, b }),
    DrawText(text, p, { halign = "center", valign = "middle" } = {}),
    DrawLine(p1, p2, color, [endcap1 = "dot", endcap2 = "dot"] = [])
}

function onMessage(msg) {
  match (msg) {
    when Message.FillBackground({ let r, let g, let b }): gfx.fill(r, g, b);
    when Message.DrawText: drawText(msg);
    when Message.DrawLine: drawLine(msg);
  }
}

function drawText(msg) {
  const Message.DrawText(text, p, { halign, valign }) = msg;
  ...
}

function drawLine(msg) {
  const Message.Line(p1, p2, color, endcaps) = msg;
  drawStroke(p1, p2, color);
  drawEndcaps(p1, p2, color, endcaps);
}

One of my main focus areas for ADT enums has been the potential for significantly better performance than regular JS objects due to a fixed shape and fixed domain, which have the potential to positively impact IC optimizations. I've only recently started discussing the possibilities of ADT enums with V8 as I've been fleshing out the design and goals for that proposal.
As a result, performance is a key area of focus for extractors as well. The worst performing part of destructuring today is array destructuring. As far as I am aware, no engine optimizes array destructuring today. This gives us two directions to pursue for extractors. First, that we could specify that the return value from an extractor must be an Array, such that we can leverage length and ordinal indexes for destructuring, which has the potential to be as fast as const { 0: x, 1: y } = obj is in most engines today. Second, that we can work with implementers to improve "array" destructuring performance in general for Array (or even typed arrays), which has the potentential to postively impact performance across the board in destructuring and pattern matching. I find the second option the most promising one as improving the performance of const [x, setX] = useState() would greatly benefit the React community.

Extractors encourage a leaner coding style that is often preferred by JS developers and is regularly seen in other languages with language features like Pattern Matching:
// (assumes Point.{ x, y } are public for the purpose of this example)

const { p1, p2 } = line; // top-level destructuring
if (!(p1 instanceof Point) || !(p2 instanceof Point)) throw new Error(); // data validation
const { x: x1, y: y1 } = p1; // nested destructuring
const { x: x2, y: y2 } = p2; // nested destructuring

// vs
const { p1: Point(x1, y1), p2: Point(x2, y2) } = line;

On the other hand, if we were to presume an equivalent Point definition like
class Point {
  #x;
  #y;
  constructor(x, y) {
    this.#x = x;
    this.#y = y;
  }
  static extract(subject) {
    return #x in subject ? [subject.#x, subject.#y] : false;
  }
}

the user code could look like
const [x1, y1] = Point.extract(line.p1);
const [x2, y2] = Point.extract(line.p2);

Sure, that doesn't do the work all on one line and during the destructuring, but the result is the same and much clearer to a reader, given that each part of the code is only doing one thing.

Once pattern matching advances you would want this logic in a [Symbol.customMatcher] anyways, and explicitly invoking symbol-named methods is generally unfavorable.
This also doesn't have equivalent semantics to what is proposed. If line.p1 in your example is not a Point, you'll receive the rather opaque error false is not iterable. Implementations will be able to provide a more reasonable error using the extractor syntax, such as p1 does not match Point. To get equivalent semantics, you must wrap the call to [Symbol.customMtcher] with in a method that throws when that call returns false, which is a lot of boilerplate code that we can avoid.
The other issue with just having a static extract method is that it doesn't guarantee a consistent API design. For each Point.extract() there might also be a Message.unapply() or Node.deconstruct(). Extractors and Symbol.customMatcher define a common protocol for this mechanism along with syntactic support for that protocol, much like for..of and Symbol.iterator or using and Symbol.dispose.

In addition to the conciseness of Extractors in destructuring, they also allow for optimal short-circuiting in Pattern Matching:
match (shape) {
  when { p1: Point(let p1), p2: Point(let p2) }: drawLine(p1, p2);
  ...
}

Here, the brand check in Point[Symbol.customMatcher] allows the pattern to attempt to match p1 and if that fails, short-circuit to the next when clause.

Ok, I'll grant you that in this case we do save one access of shape.p1 and shape.p2 compared to what's possible with switch, which also requires the break:
switch (true) {
  case shape.p1 instanceof Point && shape.p2 instanceof Point:
    drawLine(shape.p1, shape.p2);
    break;
  ...
}

Presuming that a Line class was being used, and with perhaps more common JS, those issues can be avoided:
if (shape instanceof Line) drawLine(shape.p1, shape.p2);
else ...

For this narrow case, maybe, but who is to say for a given Line the p1 property might not be a Point | Point3D that you must distinguish between, or any object having a property whose value could be any constituent of a discriminated union.
In general, switch (true) is a bit of an antipattern, but not only for the reasons that you mentioned. Yes, one of the values of switch (foo) is that it avoids repetition of foo, but switch (true) limits optimizations for case clauses since each clause must be reevaluated every time the switch statement is run, meaning there's no opportunity to optimize the switch into, say, a jump list. It's likely that match will suffer from that limitation as well by its very nature, but it's a poor choice for switch.

Another place they shine is within parameter lists where there is no Statement context within which to split out code without shifting work to the body:
function encloseLineInRect(
  {p1: Point(x1, y1), p2: Point(x2, y2)},
  padding = defaultPadding(x1 - x2, y1 - y2)
) {
  const xMin = Math.min(x1, x2) - padding;
  const xMax = Math.max(x1, x2) + padding;
  const yMin = Math.min(y1, y2) - padding;
  const yMax = Math.max(y1, y2) + padding;
  return new Rect(xMin, yMin, xMax, yMax);
}

function defaultPadding(dx, dy) {
 // use larger padding if x or y coordinates are close
 if (Math.abs(dx) < 0.5 || Math.abs(dy) < 0.5) {
   return 2;
 }
 return 1;
}

const rect = encloseLineInRect(line);

Here, extractors let you validate the input arguments and extract coordinates without needing to shift default argument handling for padding to the body.

On the other hand, if we were to presume that Point provided public accessors x and y, our code could look like:
function encloseLineInRect(
  { p1: { x: x1, y: y1 }, p2: { x: x2, y: y2 } },
  padding = defaultPadding(x1 - x2, y1 - y2)
) {
  ...
}

If the author of Point did require always getting both coordinates at the same time, then it'd probably make more sense to handle the default padding in the body:
function encloseLineInRect({ p1, p2 }, padding) {
  const [x1, y1] = Point.extract(p1);
  const [x2, y2] = Point.extract(p2);
  padding ??= defaultPadding(x1 - x2, y1 - y2);
  ...
}

Actually, having written out those alternatives, this last one is by far the clearest to me, as each part of it is only doing one thing, and it's much clearer that extracting the values actually involves some work.
Why should having this code in the function body be considered a bad thing?

This doesn't necessarily have the same semantics as the example I posted. ??= includes null, while parameter defaults do not, and a different function might consider null to be a valid argument with an independent meaning. Also, as I've mentioned before this doesn't provide a useful error at the sites of each .extract call, unless .extract itself throws on an invalid input, and that again is boilerplate you must provide for every .extract method you write.
This is a fairly limited example. I've seen real world code with functions that have 8+ parameters, some with consecutive defaults based on prior arguments and their defaults. If any of those defaults would depend on a destructured input, you might have to shift all of that logic to the body to preserve evaluation order. That can have other effects as well, such as changing the .length property of the function. If .length is an important characteristic for your function, you're then having to either replace parameter defaults with = undefined or rely on arguments or a rest parameter. In non-trivial cases all of these papercuts can add up.
In addition, unless we can convince implementations to optimize array destructuring, extractors will likely require Array return values and leverage an Array-as-object destructuring approach. If that is the case, const Point(x, y) = obj could be up to 30% faster than const [x, y] = Point.extract(obj) because normal array destructuring is so slow (based on some rudimentary microbenchmark comparisons of object destructuring vs array destructuring in V8).

So is this proposal predicated on pattern matching, or should its merits be assessed independently of that proposal? Most of the arguments being made for this proposal appear to rely on pattern matching, but it's being advanced independently and ahead of pattern matching, which would suggest the opposite.
Right now I'm struggling a bit to identify the value of extractor objects without reference to pattern matching, which, if accepted, would indeed bring in custom matcher methods to account for pattern matching's inability to include more than one expression per case.
In that pattern matching world, it does become more interesting to use the same matching syntax outside the match, but even then it's not clear to me that the destructor approach proposed here is the right one. Compared to what's currently proposed for pattern matching, destructor extractors:

Throw rather than return false if the custom matcher fails.
Have completely different syntax inside the parentheses.

Without do-expressions, it's also not at all clear that the refactoring complexities of taking a single expression out of a match and adjusting it for life outside would be actually hard.
Separately from pattern matching, you've also brought up algebraic data types as something with which extractors would be useful. If that should be considered a part of the value proposition here, is there a better definition of exactly what they might look like, and should they too be considered as a dependency of this proposal?
Finally, inline replies to your last three paragraphs, which consider our current world without pattern matching:

This doesn't necessarily have the same semantics as the example I posted. ??= includes null, while parameter defaults do not, and a different function might consider null to be a valid argument with an independent meaning.

Sure, null could be a valid value so the ??= shorthand is not universal. In this case, though, the padding is being added to a number. But this is rather irrelevant to the larger point of default values being definable in the function body, often with succinct syntax and clear meaning.

Also, as I've mentioned before this doesn't provide a useful error at the sites of each .extract call, unless .extract itself throws on an invalid input, and that again is boilerplate you must provide for every .extract method you write.

You're right, an extractor object does allow for slightly more informative errors than the current "false is not iterable" or similar. However, those errors do already tend to come with a source reference, so this seems like a marginal improvement.

This is a fairly limited example. I've seen real world code with functions that have 8+ parameters, some with consecutive defaults based on prior arguments and their defaults. If any of those defaults would depend on a destructured input, you might have to shift all of that logic to the body to preserve evaluation order. That can have other effects as well, such as changing the .length property of the function. If .length is an important characteristic for your function, you're then having to either replace parameter defaults with = undefined or rely on arguments or a rest parameter. In non-trivial cases all of these papercuts can add up.

Sure, code like that exists, and refactoring it can be a pain. Though tbh 8+ parameters or depending on function length kinda sounds like it's complicated enough without defaults depending on previous destructured inputs. On the flipside, do I understand right that the cost of this would be to accept code like this as valid?
function foo(bar(baz)) { ... }

Actually, can extractors nest? As in, could this too be valid?
function foo(bar(baz(quux))) { ... }

In addition, unless we can convince implementations to optimize array destructuring, extractors will likely require Array return values and leverage an Array-as-object destructuring approach. If that is the case, const Point(x, y) = obj could be up to 30% faster than const [x, y] = Point.extract(obj) because normal array destructuring is so slow (based on some rudimentary microbenchmark comparisons of object destructuring vs array destructuring in V8).

Have you tested the performance of a custom extractor against code for a Point implementation that doesn't try to hide its coordinates?
const x = obj.x;
const y = obj.y;

// or

const { x, y } = obj;

So is this proposal predicated on pattern matching, or should its merits be assessed independently of that proposal? Most of the arguments being made for this proposal appear to rely on pattern matching, but it's being advanced independently and ahead of pattern matching, which would suggest the opposite.

Extractors have been proposed for both pattern matching and for destructuring, with Extractors for pattern matching folded into the pattern matching proposal itself. The pattern matching proposal is large enough on its own that it is best to have a separate proposal for Extractors for destructuring and manage the commonalities as cross-cutting concerns between the two proposals.
Though there is a strong link to pattern matching, Extractors are intended to stand on their own. They fill a capability gap in the destructuring syntax and, as @erights put during the February plenary, "[the Extractor syntax] has a tremendous amount of reach. And it’s fairly small and elegant for something with this much reach, this many different things you can apply it to in a coherent and unified manner."
When I presented an update on Extractors in February, I'd indicated that I planned to bring Extractors for Stage 2 around the time that Pattern Matching was proposed for Stage 2. At that time I was encouraged by many on the committee to consider advancing the proposal independently regardless as to whether Pattern Matching was also seeking advancement as they need not advance in lock step so long as cross-cutting concerns are maintained.

Right now I'm struggling a bit to identify the value of extractor objects without reference to pattern matching, which, if accepted, would indeed bring in custom matcher methods to account for pattern matching's inability to include more than one expression per case.

I am not clear on what you mean by "inability to include more than one expression per case". Can you clarify? Do you mean the inability to accept multiple arguments? Extractors are meant to work on a single input value to produce zero or more output values, just as constructors accept zero or more inputs to produce a single output. There is an intentional duality behind the design. This one-to-many behavior is also explicitly consistent with other destructuring patterns which take one object or one array to produce zero or more bindings. Extractors are unary functions by design.

In that pattern matching world, it does become more interesting to use the same matching syntax outside the match, but even then it's not clear to me that the destructor approach proposed here is the right one. Compared to what's currently proposed for pattern matching, destructor extractors:

Throw rather than return false if the custom matcher fails.

Just as in Rust, destructuring extractors are irrefutable. There is no alternative to pursue when you write const Point(x, y) = obj, so the only option is to throw. This is, again, consistent with {} and [] in destructuring which throw if the input is not an object or an iterable, respectively. This is also consistent with match expressions which will also throw if the subject is not matched by any when clause. Also, it is not the extractor object that throws, but the extractor syntax. The [Symbol.customMatcher] method is still expected to return false (or any falsy value) when the match fails.

Have completely different syntax inside the parentheses.

This syntax difference is precisely the same syntax difference as [] and {} have between pattern matching and destructuring. If there is a cost to be paid in learning the differences between pattern matching and destructuring, that cost will be paid regardless as to whether extractors are present. let/const patterns in pattern matching are a necessity to disambiguate between identifier references and bindings, which is a distinction pattern matching must make but destructuring does not. In my opinion, (2) is an example of consistency in the design, not inconsistency.

Without do-expressions, it's also not at all clear that the refactoring complexities of taking a single expression out of a match and adjusting it for life outside would be actually hard.

Can you clarify what you mean here? I'm not sure the presence or absence of do expressions affects this at all.

Separately from pattern matching, you've also brought up algebraic data types as something with which extractors would be useful. If that should be considered a part of the value proposition here, is there a better definition of exactly what they might look like, and should they too be considered as a dependency of this proposal?

This proposal does not depend on ADT enums, but is certainly informed by them. Its too early to say whether ADT enums will have the performance characteristics I'm hoping for. There have been discussions about them here and here, though neither fully represent my current thinking on the approach. I'm not ready to share the new design publicly yet, but I'd be happy to discuss some of the thinking in an offline discussion.

Sure, code like that exists, and refactoring it can be a pain. Though tbh 8+ parameters or depending on function length kinda sounds like it's complicated enough without defaults depending on previous destructured inputs. On the flipside, do I understand right that the cost of this would be to accept code like this as valid?
function foo(bar(baz)) { ... }

Actually, can extractors nest? As in, could this too be valid?
function foo(bar(baz(quux))) { ... }

Yes, this would be valid, and yes, extractors can nest. Most extractors are likely to be classes (or ADT enums when that time comes) and the generally accepted naming convention for such definitions in JS is pascal-case, thus the more common case will be something like
function foo(Bar(baz)) { ... }

and thus be more readily distinguished, not to mention that most editors will apply syntax highlighting that further distinguishes an extractor from a parameter.
While likely not the norm, nested extractors have their place when combined with utility types like Option. The Message refactoring I mentioned above could very easily be an Option.Some(Message.DrawText(text)), but its rare to see anything more complex in the wild in other languages.

Have you tested the performance of a custom extractor against code for a Point implementation that doesn't try to hide its coordinates?
const x = obj.x;
const y = obj.y;

// or

const { x, y } = obj;

If you break down an extractor to its independent steps and use "Array-as-object" destructuring, extractors would essentially have the same overhead as this:
const { 0: x, 1: y } = Point.extract(obj);

The 30% number above came from some microbenchmarks we ran comparing the performance of the following two statements in React:
// scenario 1 - array destructuring
const [foo, setFoo] = setState();

// scenario 2 - array-as-object destructuring
const { 0: foo, 1: setFoo } = setState();

The "Array-as-object" destructuring scenario was ~30% faster than iterator destructuring. We don't have any numbers comparing { 0: x } destructuring to { x: x } destructuring, though it's possible implementations could handle numeric index properties in a less efficient way than regular properties. Aside from that, there is expected overhead incurred when invoking user code, whether its Point.extract() or Point[Symbol.customMatcher](). If Point doesn't hide its coordinates and you don't need the brand check, then { x, y } will obviously be faster. But if you need the brand check or some other data transformation behavior in addition to destructuring, you'd be paying that cost regardless.
If implementations don't opt to invest in array destructuring improvements, and Extractors choose to use "Array-as-object" destructuring as a result, I expect someone will write
const Elements = {
  [Symbol.customMatcher](subject) {
    return Array.isArray(subject) && subject;
  }
};

to get that speed boost for destructuring when the input is known to be an array:
const [a, b] = ar; // iterator destructuring
// vs.
const Elements(a, b) = ar; // "Array-as-object" destructuring

which is likely still faster than normal array destructuring even with the user-code overhead, and I expect function inlining could make that overhead fairly negligible as well.

I should also note that Pattern Matching is on the agenda for possible advancement to Stage 2 at this plenary.

Right now I'm struggling a bit to identify the value of extractor objects without reference to pattern matching, which, if accepted, would indeed bring in custom matcher methods to account for pattern matching's inability to include more than one expression per case.

I am not clear on what you mean by "inability to include more than one expression per case". Can you clarify? Do you mean the inability to accept multiple arguments? Extractors are meant to work on a single input value to produce zero or more output values, just as constructors accept zero or more inputs to produce a single output. There is an intentional duality behind the design. This one-to-many behavior is also explicitly consistent with other destructuring patterns which take one object or one array to produce zero or more bindings. Extractors are unary functions by design.

I meant that the body of a pattern matching case is a single expression, rather than allowing multiple statements as switch does. This means that in a match, there's no "function body" in which to e.g. destructure values so that they can be used, and therefore it's much more useful to be able to get it all done in the MatchPattern.

Without do-expressions, it's also not at all clear that the refactoring complexities of taking a single expression out of a match and adjusting it for life outside would be actually hard.

Can you clarify what you mean here? I'm not sure the presence or absence of do expressions affects this at all.

Without do-expressions, the pattern match body is a single expression for each case, and therefore it's reasonable to expect it to be relatively simple, such as a single function call. Refactoring something like that is in general simpler than refactoring a generic block of code. Of course the body could be an IIFE or something, but that's unlikely to be too common.

Closing in favour of #20, as runtime types are a pretty clear value proposition.

Without do-expressions, the pattern match body is a single expression for each case, and therefore it's reasonable to expect it to be relatively simple, such as a single function call. Refactoring something like that is in general simpler than refactoring a generic block of code. Of course the body could be an IIFE or something, but that's unlikely to be too common.

If do expressions do not materialize, it's possible that match will subsume a limited form do to support statement execution, e.g.,
match (value) {
  when pattern: do {
    // statements
  }
}

The ability to support statements is important to many of the pattern matching champions as they also want match to be a "better" switch.

See https://github.com/tc39/proposal-pattern-matching/issues/322 , especially the end of the thread starting at https://github.com/tc39/proposal-pattern-matching/issues/322#issuecomment-2045865071


Add support for latest IS versions

Purpose

Add support for IS 7
Add unit tests

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


Alert Feat (2024) Incorrectly applied for initiative

2024 Alert Feat applies Prof Bonus in addition to Dex Mod, and rolls at advantage.
DND 4.1.0 seems to indicate that, but incorrectly display initiative bonus in character sheet, and only rolls D20+Dex Mod, Not D20+dex+Prof.

Screen Cap of interaction:
https://www.dropbox.com/scl/fi/79luelec072b8cbrmg8th/Screencast-From-2024-11-09-20-40-15.webm?rlkey=lm5ac2izgyqicgipqy7s7ll9n&dl=0
Foundry Initiative:

Chat log after rolling:

DND Beyond Character:

Alert in 4.0.4 and 4.1.0 is incorrect.
It is adding a flat +5.
It should be +Prof (in addition to d20+dex).
But alert does not give advantage.
Your Barbarian is getting advantage from Feral Instinct, which is a level 7 feature.

Initiative Proficiency. When you roll Initiative, you can add your Proficiency Bonus to the roll.

Feral Instinct. Your instincts are so honed that you have Advantage rolls.

Ok, thanks for the correction.
However Foundry was not properly rolling with advantage nonetheless. It would show the 2d20kh but only roll/show results of 1 die.


Support the new model

Hi 👋
Firstly, we are glad to see that VisionZip has caught your attention. We’ve received several issues like #5 #7 #4  requesting support for additional models, and we appreciate your interest in VisionZip.
The VisionZip code is released and easy to implement, so we encourage users to try migrating models on their own first.😊
Additionally, I will begin supporting some new models soon, so stay tuned.🔥
If you have any questions, feel free to ask me. We truly hope VisionZip can benefit your research. ✊
Best,
Senqiao

I think it is better to first start on integrating visionzip in huggingface transformers environment. That way, both you and other contributors can implement new models easier.


Add pl tag and reverse complement QUAL

I determined that it makes sense to reverse the orientation of the qual string if the SEQ is also being reverse complemented

This additionally has the option to output a tag "pl:Z" that contains the location of the primary alignments which can be useful


Error when adding dice.py python layer to caffe alex-net

Hi,
Trying to add Dice metric layer to network to manage dataset imbalance.
I followed the instructions in the medical imaging example but receive error this when training the net:

ERROR: Check failed: registry.count(type) == 1 (0 vs. 1) Unknown layer type: Python (known types: AbsVal, Accuracy, ArgMax, BNLL, BatchNorm, BatchReindex, Bias, Concat, ContrastiveLoss, Convolution, Crop, Data, Deconvolution, Dropout, DummyData, ELU, Eltwise, Embed, EuclideanLoss, Exp, Filter, Flatten, HDF5Data, HDF5Output, HingeLoss, Im2col, ImageData, InfogainLoss, InnerProduct, Input, LRN, LSTM, LSTMUnit, Log, MVN, MemoryData, MultinomialLogisticLoss, PReLU, Parameter, Pooling, Power, RNN, ReLU, Reduction, Reshape, SPP, Scale, Sigmoid, SigmoidCrossEntropyLoss, Silence, Slice, Softmax, SoftmaxWithLoss, Split, TanH, Threshold, Tile, WindowData)

from output log:

I1110 16:44:09.254968 172016 layer_factory.hpp:77] Creating layer dice

F1110 16:44:09.255031 172016 layer_factory.hpp:81] Check failed: registry.count(type) == 1 (0 vs. 1) Unknown layer type: Python (known types: AbsVal, Accuracy, ArgMax, BNLL, BatchNorm, BatchReindex, Bias, Concat, ContrastiveLoss, Convolution, Crop, Data, Deconvolution, Dropout, DummyData, ELU, Eltwise, Embed, EuclideanLoss, Exp, Filter, Flatten, HDF5Data, HDF5Output, HingeLoss, Im2col, ImageData, InfogainLoss, InnerProduct, Input, LRN, LSTM, LSTMUnit, Log, MVN, MemoryData, MultinomialLogisticLoss, PReLU, Parameter, Pooling, Power, RNN, ReLU, Reduction, Reshape, SPP, Scale, Sigmoid, SigmoidCrossEntropyLoss, Silence, Slice, Softmax, SoftmaxWithLoss, Split, TanH, Threshold, Tile, WindowData)

*** Check failure stack trace: ***
@     0x7ffff1b4c9fd  google::LogMessage::Fail()
@     0x7ffff1b4e7cc  google::LogMessage::SendToLog()
@     0x7ffff1b4c5ec  google::LogMessage::Flush()
@     0x7ffff1b4f0de  google::LogMessageFatal::~LogMessageFatal()
@     0x7ffff730079f  caffe::LayerRegistry<>::CreateLayer()
@     0x7ffff742544c  caffe::Net<>::Init()
@     0x7ffff7427545  caffe::Net<>::Net()
@     0x7ffff740cf3a  caffe::Solver<>::InitTrainNet()
@     0x7ffff740e03c  caffe::Solver<>::Init()
@     0x7ffff740e36a  caffe::Solver<>::Solver()
@     0x7ffff7400e23  caffe::Creator_SGDSolver<>()
@           0x410aed  caffe::SolverRegistry<>::CreateSolver()
@           0x409ec2  train()
@           0x40752c  main
@     0x7fffe9ebcb15  __libc_start_main
@           0x407d9d  (unknown)

Hello, you need to enable support for Python layers in Caffe. Did you build Caffe yourself from the top-level makefile? Our recommendation is to get Caffe from the caffe-nv .deb package (instructions) or if you need to build Caffe yourself, use cmake to generate the makefile as explained in the Caffe build instructions.

Thanks! I'm running on the HPC so I'll ask the admin to install it according to the instructions.

After compiling caffe with python layer support and adding the dice.py layer as in the medical imaging example I get another error:
I1112 11:45:39.933650 39113 net.cpp:150] Setting up loss
I1112 11:45:39.933662 39113 net.cpp:157] Top shape: (1)
I1112 11:45:39.933665 39113 net.cpp:160]     with loss weight 1
I1112 11:45:39.933730 39113 net.cpp:165] Memory required for data: 203912492
I1112 11:45:39.933735 39113 layer_factory.hpp:77] Creating layer dice
I1112 11:45:43.071300 39113 net.cpp:100] Creating Layer dice
I1112 11:45:43.071329 39113 net.cpp:434] dice <- score_score_0_split_1
I1112 11:45:43.071341 39113 net.cpp:434] dice <- label_label_0_split_1
I1112 11:45:43.071349 39113 net.cpp:408] dice -> dice
Traceback (most recent call last):
File "/pstore/home/klaimane/.local/digits/20161112-114537-b333/digits_python_layers.py", line 17, in reshape
raise Exception("Prediction must have twice the number of elements of the input.")
Exception: Prediction must have twice the number of elements of the input.

Hello, the Dice Python layer only works (and makes sense) for binary segmentation so you need to have only two classes in your final softmax. Refer to the medical imaging example.

Of course, how silly of me :-)
Are there any "dice-like" layers that support multiple classes? (in our case I think 3 would be the absolute minimum.)
I'm currently trying to compensate by painting a proportional part of the background with the ignore label, but this technique only compensates for background quantity balance and not balance of other classes.

Note that the Dice layer from the medical imaging example is just a metric to replace accuracy. It is not a loss layer so it has no impact on training. The backward() method needs to be implemented to use it as a loss. If you have more than 2 classes you might be interested in the InfoGainLoss which makes it possible to penalize some errors more strongly (e.g. predicting background instead of foreground). However the caveat is the default implementation in Caffe doesn't work with FCNs (besides, even after integrating changes to fix this, I didn't manage to get it to produce better predictions).

Thanks! I guess this leaves the balancing on the dataset side?

Is class imbalance that much of an issue for you? On the medical imaging example even though the background represents 98.5% of pixels we get a Dice metric of 0.86 when using FCN-8s. I am not totally convinced by the benefits of doing class balancing in the dataset. I like it when the training dataset represents the true distribution of the data that you're likely to encounter during testing.

I guess it would be relatively easy to test a balanced vs unbalanced set and comapre the results.

Sure.
I'll be closing this issue for now.


VCCW with 'vagrant up' or 'vagrant up --provision' do not work on a Mac

Operating System: Mac OS
Vagrant Version: Latest (12 Sept, 2020)
Virtual Box Version: Latest
I normally love discovering and trying new things, but this has been a mess from the start. I knew I should have bailed after seeing install instructions that just didn't care  ("download the zip" - And what? ).
Anyway, after trial and error, figure out I needed to create a directory of my choose, unzip, put the folder contents in that new directory, and then all look good.
Except after all that, on a Mac, it doesn't work.
After using 'vagrant box add vccw-team/xenial64' , If I run vagrant up, I'm told I need to run vagrant provision or vagrant up --provision
None of those work. Nothing is started, no local server is available.
On the first run I had it working, but then the connection went for no apparent reason while I was navigating Wordpress admin. After that, it was the runaround of the 3 commands above.
Before I give up on this, is there any sensible way to make this work on a Mac?
 Not only does that not work, but it takes ages and ends up at the same place.
It's clear this is a big issue. You look aroung and see the questions, but there are not solutions out there that I have found. Just vague references to needing to use --provision, but that actually doesn't work (no local server is run). Lets gets some proper Mac instructions out there and save this huge time-waste for those new to Vagrant.
If there's any chance I can figure this out soon, I'll help write some tutorial.

Hi @seffw, I've been using VCCW on OSX for a long time with no major issues.
Here are the steps I take in settings up a new VCCW repository:

Download and Extract VCCW.zip
Move and rename to a folder of your choosing. I will use ~/Projects/wordpress.
Copy ~/Projects/wordpress/provision/default.yml to ~/Projects/wordpress/provision/site.yml.
Edit the ~/Projects/wordpress/provision/site.yml.

I normally just update hostname and leave the rest.

Run vagrant plugin install vagrant-hostsupdater
Run vagrant box add vccw-team/xenial64
Run vagrant up.

Now you can use vagrant halt and vagrant up as you like. If you change site.yml you must run vagrant up --provision.


mobile-controls.js getAllBodyLinks() clears all tabindex values

mobile-controls.js line 116.  getAllBodyLinks() is a VERY large search that includes most controls on the page..."  // all focusable elements other than navigation".
The tabindex values are cleared for everything.
We probably don't want that.

@lakey8085CDT this is now updated in dev. Please test on form elements page

Fixed in 6.3.1


Custom ERD foreign key relations not showing for other members

System information:

Operating system (distribution) and version : Windows 10
DBeaver version: Community Edition 21.0.5
Java version "1.8.0_291"
Additional extensions

Connection specification:

Database name and version : SQL Server 2016
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
I have created a custom ERD by mapping the virtual foreign keys for the tables in my database. However, When I share this custom ERD file with my team, they are unable to view any of the data.
I then went through the past issues and found this https://github.com/dbeaver/dbeaver/issues/2440. I did as mentioned by one of the user in that message. I updated the data source id for my other users and opened the file in their system. They are now able to see all the files in the custom ERD, however all the foreign key relationships that i created initially are gone. Users are only able to see the tables and the relations are missing.
Can you please advice what is the best way to share the custom ERD diagrams with other members of the team outside of git framework.
Steps to reproduce, if exist:
Include any warning/errors/backtraces from the logs

@KarthikDulam Yes, actually the only possible way to do this is either manually copying the whole project or by making a repository and using the git extension.


Parse the error from the backend

I guess we can add a json parser that would try to extract the "error" message, so we don't show the json in plaintext.

This is the standard error format for both alertmanager and prometheus, will be nice to have this


Cannot pass all-in-one-mode assertion

What happened?
TASK [cloudalchemy.cortex : Services should be empty when all-in-one-mode is enabled] **************************************************************************************************************************************************
fatal: [cortex]: FAILED! => {
    "assertion": "cortex_all_in_one == (cortex_services|length == 0)",
    "changed": false,
    "evaluated_to": false,
    "msg": "Exactly one of cortex_all_in_one or cortex_services should be set."
}

Did you expect to see some different?
expected to pass assertion.
How to reproduce it (as minimally and precisely as possible):
- hosts: all
   roles:
    - cloudalchemy.cortex

Environment

Role version:
`jesse.quinn@monitoring-security:~/ansible$ ansible-galaxy role list

/home/jesse.quinn/.ansible/roles

cloudalchemy.cortex, master
`

Ansible version information:
ansible --version
ansible 2.9.6 config file = /home/jesse.quinn/ansible/ansible.cfg configured module search path = ['/home/jesse.quinn/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3/dist-packages/ansible executable location = /usr/bin/ansible python version = 3.8.10 (default, Jun  2 2021, 10:49:15) [GCC 9.4.0]

Variables:

n/a

Ansible playbook execution Logs:

TASK [cloudalchemy.cortex : Services should be empty when all-in-one-mode is enabled] **************************************************************************************************************************************************
fatal: [cortex]: FAILED! => {
    "assertion": "cortex_all_in_one == (cortex_services|length == 0)",
    "changed": false,
    "evaluated_to": false,
    "msg": "Exactly one of cortex_all_in_one or cortex_services should be set."
}

Hi, I am also facing the same issue.. so found quick work around for this assertion task as below.
preflight.yml:
tasks:
- name: Services should be empty when all-in-one-mode is enabled
assert:
that: cortex_all_in_one == (cortex_services|length == 0)| bool
msg: "Exactly one of cortex_all_in_one or cortex_services should be set."
when: cortex_services is defined or (cortex_all_in_one | default(true) == false)


Create github actions for auto-deployment to fly.io on PR merge!

@memosys I assigned this to you and put in review since it is done and working. Just wanted to make sure you didn't have any last bits on this.

currently only handling our apps not services so do we want to automate that as well? thoughts on automating prod? but on main branch?

ok, I'll move it back to in progress

currently only handling our apps not services so do we want to automate that as well? thoughts on automating prod? but on main branch?

could you respond on expectation @plor

I am ok with prod being manual as I don't think actions are high enough value there. Adding services would be my expectation, though since those are not code we manually edit (just updating version) I'm also ok leaving that out. Docs needs some love still.

We can close it then


Add const lvalue ref to core/* container parameters

Adds const lvalue reference to the core container types specified in the documentation that are declared in function parameters in core/* files
initial: https://github.com/godotengine/godot/pull/51156

This doesn't just cover core, you need to split it down further place, let's keep it to just core/

Please limit it to just core, this is still too big to do a proper review of for these kinds of changes 🙂 no harm in multiple PRs, especially when it makes it possible to review

I tried to just upload the core/* files but it was issuing build errors because of core/* virtual methods overridden across multiple parts of the engine

Then those should be handled separately in their own PR because this still has over 300 files, far too big for a review like this, for those specific methods you can do a dedicated PR

Ok I'll leave the virtual methods that are issuing build errors out of this PR and put then in another PR

Or at minimum remove all unrelated changes from other parts, because they make up a lot of it 🙂

You mean remove all folders except core and core's virtual methods that aren't compiling?

Those non-core/* are inevitable for all core/* files to build

Will take a look, thank you and sorry for the inconvenience (and you'll get a bonus of more PRs!)

You have a merge commit in your history, please use rebasing instead, do this by:
git reset --hard HEAD^
git rebase -i master
git push --force

Sorry for the delay. Looks good to me overall, needs a rebase and then this should be ready to merge if nobody has any outstanding concerns about the change.

I'd like an eye by a core maintainer familiar with the method_ptrcall.h file, just to ensure there's no weirdness with that, otherwise I think this looks good
CC @reduz perhaps

The changes in method_ptrcall.h seem fine to me! The const is added to Vector's that we're only reading from.

Thanks!


Updated readme, setup

Thanks!
One question, though: is versioneer a better choice than setuptools_scm (and setuptools_scm_git_archive)?

On 28.06.2018 15:50, Christoph Wehmeyer wrote:

Thanks!
One question, though: is versioneer a better choice than setuptools_scm (and setuptools_scm_git_archive)?

I prefer it, since I have only good experiences with it. The other tools
still contain too many bugs to be production reader IMHO. Of course
versioneer pollutes the repo a bit, but this is a small price to pay for
this valuable asset.

The error is related to a change in PyEMMA's plot_feature_histograms function and will be fixed upon merging my feature_plotting branch.

On 28.06.2018 16:40, Christoph Wehmeyer wrote:

The error is related to a change in PyEMMA's plot_feature_histograms function and will be fixed upon merging my feature_plotting branch.

ok, this change actually broke the api and btw the docstring of the
function is also wrong (in pyemma).

ok, this change actually broke the api and btw the docstring of the function is also wrong (in pyemma).

This function is pretty new, so I do not worry too much about the API. But the incorrect docstring does bother me. Can we patch this somehow?

You mean in the release from like 3 hours ago?

Yes.

I can have a look. But I would suggest to wait to build a patched
version until we have accumulated something more serious, eg. one will
discover something which really justifies this workload.

Given that the broken plot is the only source of error, I'd say go ahead and merge. Thanks for taking care of this!


Is it realistic to get a VAC ban if you launch a CSGO in the achievement manager when a real CSGO is launched?

Today I wanted to open achievements in the CSGO, but I forgot to turn off the already launched CSGO, I did not open the achievements, I opened it only after the CSGO was closed. The question is, can I get VAC if I started the CSGO from the achievement manager during an already running game?

I'm not Valve/Steam and can't give you an answer here.

Thanks for the answer! I believe that you can’t get a lock because the achievement manager does not change / read the game’s memory, so you can’t get a lock.

VAC doesn't do anything that would detect this, I believe valve's anticheat started hooking OpenProcess and LoadLibrary but I'm sure that this doesn't do anything like that - it would be very easy for Valve to detect this & hand out community bans if they chose to, so you might wan to bear that in mind.

 Because VAC only works on it.If you also started cs: go in SAM during the already running cs: go, would you be worried? I have paranoia that will ban the wak, and there are 900 games on my account.

Pointless to worry about that, because if you were flagged for that, it's already done and there's no reversing it. It will be what it is.

And what i should to do?Six months have passed but there is no VAC, suddenly he will come in 5 years.

CSGO had an ingame announcement of a kernel level anti cheat coming soon.
I already don't reccomend it. But def. after that.
Also people crying about bugged achievements, then discussing ways to exploit it, they didn't delete any of the exploits but when I mentioned SAM I got a community warning/comment deleted "illicit or illegal activity" warning...

CSGO had an ingame announcement of a kernel level anti cheat coming soon.

Valve did not say anything about an ring0 anticheat, they pride themselves on having an unintrusive anticheat, where did you hear that?
This isn't going to get you vac banned unless Valve changes their policy.

Can i ask you?Does VAC work in the CSGO main menu?

‘Trusted Launch’ is an optional setting which is currently in beta. It was launched yesterday by the developers to work in conjunction with the Valve Anti-Cheat (VAC) to bolster their fight against cheaters.
Maybe I missunderstood the intrusiveness in the new beta.

yeah there hasn't been anything announced about a kernel mode anticheat - the new anticheat update doesn't really stop cheaters either which is ironic since it caused more bugs for legit players than cheaters.

wait, you can't get VAC banned anymore by using sam now?

I have never heard of any legitimate report of a VAC ban for SAM.

I have never heard of any legitimate report of a VAC ban for SAM.

weren't people used to get vac banned if using SAM during playing on VAC secured servers?

or am I having mandela effect?

or am I having mandela effect?

that has never happened from what I've read, SAM doesn't r/w any game memory.

or am I having mandela effect?

that has never happened from what I've read, SAM doesn't r/w any game memory.

https://www.steamgifts.com/discussion/oeGWk/friend-got-vac-ban-sam
This is a 5 year old thread, from what I have heard steam vac bans users who run sam when playing on vac-protected servers.
What my question was "Does is still do that or has it been changed?"

I have used it for years while on vac secured servers, it has never done that to me - it doesn't hook/modify memory (I assume) so I don't know why vac would ban for it.

idk either tbh, maybe it used to do that in previous versions.

SAM has never hooked/modified either Steam or any particular game in any version.

@denosee you get VAC?

@michaellrowley you not getting VAC running SAM while playing on vac secured servers?


Node 14 development

Node 14 has an issue connecting to Postgres with pg versions below 8.3.0 which breaks the setup-test-db.js script.
This PR bumps the local dep for pg to 8.3.0 and knex to 0.21.5 (which relies on<EMAIL_ADDRESS>so you can develop Objection locally using Node 14.
Tests pass with Node 10.22.0, 12.18.3, and 14.7.0

Coverage remained the same at 97.061% when pulling d44cfa3a2a42701b9d6fe01f191077c519d7473d on kjs3:node-14-development into 9070af7e0666c64a14dbfb66a6e54fd8b4a9f075 on Vincit:master.

Give me a sec to release 0.21.6 prior to merging this :)

Could you please bump to 0.21.6? Quite annoying noise was addressed in this one.

Can you also add Node 14 to the test matrix?

@kibertoad: Bumped Knex to 0.21.6 and added Node 14 to Travis setup.


Update free-programming-books-langs.md

What does this PR do?
Added [Java Notes for Professional] (PDF) - GoalKicker.com
For resources
It contains all of the topics for Java users which is a sign of good resource
Why is this valuable (or not)?
The GoalKicker team has always put the resources which are valuable and free for people to access.
How do we know it's really free?
For book lists, is it a book? For course lists, is it a course? etc.
It is a book in pdf format
Checklist:

[ ] Read our contributing guidelines.
[ ] Search for duplicates.
[ ] Include author(s) and platform where appropriate.
[ ] Put lists in alphabetical order, correct spacing.
[ ] Add needed indications (PDF, access notes, under construction).
[ ] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

existing entry uses our prefered style for goalkicker


HandHeld radios are broken

Description

Looks like they were broken by the chat update maybe?
Screenshots

can't replicate, even with a headset off as demonstrated
https://user-images.githubusercontent.com/19853115/126892050-f68970db-de7c-46ff-8842-3f6559396187.mp4


Linux Spot min/max costs are flipped for some instance types

For a p3.16xlarge instance, the Linux Spot Minimum cost and Linux Spot Maximum cost are $14.64 and $9.15 respectively (at time of writing). Unless I'm misunderstanding what those columns mean, it seems like the max cost should always be >= the min cost.

Thanks for reporting this, sounds like a bug, we probably do string sorting instead of handling them as floating point numbers. I'll have a look at this sometime next week.

I figured out the problem and I have it fixed locally,  I'll make a PR later tonight

Created #579
@Bensign please review, this is a 2-liner change, should only take you a few seconds.


Add new deriving type for moshi data classes

Superseded by https://github.com/UbiqueInnovation/djinni/pull/14


Move provider class manager interfaces to a public package

Summary
These are to be implemented by providers. Thus, they make no sense to be
internal interfaces.
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[x] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

the unit test failures look related to the PR

@jhrozek they are, I gotta look into them.


Improved Makefile

Reduced clean average compilation time from 72 to 16 seconds for the default targets
Reduced subsequent average compilation time from 2 to 1 second for the default targets
Fixed files not rebuilding after changing a header file
Added debug target to debug Makefile variables
Updated comments to match with the code
Added .PHONY target to prevent future errors

2 more COMPILER_FLAGS to add to suppress warning compiling with clang: -Wno-implicit-int-float-conversion -Wno-inconsistent-missing-override


avoid kubernetes import for slice contains logic

In an effort to reduce direct dependency on k8s.io/kubernetes, I have declared the trivial slice contains method for use within inspect.go

@bacongobbler FYI

Looks like appveyor has failed because it attempted to find a dep manifest. Is that a cue for me to PR this to dev-v3 instead?


Define formatting settings. Part 2

Part 2 of https://github.com/servicefabric/servicefabric/issues/16

Add suppression for javadoc check on test
Used false for join wrapped length property
Min line count method require javadoc is 4
Fail build in case of checkstyle violations.

+1


DiscordClient.Connected event handler does not fire

Not sure if it's my app, but all of my event handlers work perfectly fine - except for this one:
DiscordClient client = new DiscordClient(token, true);
client.Connected += (sender, e) => {
    // code in here never runs
};

I have tried replacing it with other things, other forms of things, I've tried debugging it, but it never fires.

did you call client.Connect(); ?

@Luigifan yessir, all the way at the bottom after defining all my handlers. Not sure why this one will not work. As you can see here, I called client.Connect();, but nothing happens. The handler will never be called.

I can't say I can reproduce. :/

@Luigifan I will do some more testing when I get home and let you know how it goes, but I was not able to fix the problem.

Not sure if I should open a new issue.
I actually have the same issue, but only when I run it on my linux server using mono.
It works fine on my windows pc's, but not on my linux one.

@Akuba- I'm running Windows here, so it isn't an OS-dependent problem.

Closing out of old age and lack of reproducibility.


Support PCNs

Agreed to:

Use the same approach Peter used for Regions and STPs (q.v. old PRs)
Take the opportunity for light refactoring with a view to our planned big refactor about groupings

The relevant PRs:

#1238 (Add RegionalTeam and STP models)
#1243 (Add tasks to import STPs and regional teams)
#1244 (Update import_measures for STPs and regional teams)
#1251 (Support CCG groupings in API)
#1257 (Preparation for CCG grouping frontend changes)
#1345 (Fix e2e tests)
#1415 (Add Regional Team and STP pages)

Closed by #1810 #1813 #1825 and #1828


Code duplication - process_unions

In process unions we are repeating the pattern of
todo.drain:
  sort parents
  dedup parents and update metadata
  union everything

This pattern repeats itself a few time during process_unions and colored_process_unions and for memo in some places.
Currently it is implemented for each case separately as the typing of each case differs a bit. We should find a way to generalize the types and dedup closures to a single framework. It will be extra difficult to maintain performance because in process_unions we are usin Vec::dedup_by which is more efficient then rebuilding the vector, but in process_colored_unions we use an iterator.

The new process (with singly colored edges) has less duplication, so I am closing this for now (not worth the engineering time).


WIP: Fix missing and incorrect DebugValues

Specificially, this fixes DebugValues coming out of eliminate-local-single-store and eliminate-local-multi-store AKA SSA rewrite.
This is done by bypassing the IsDeclareVisibleToInstr() analysis in the DebugInfoManager and just always generating a DebugValue when calling AddDebugValueIfVarDeclIsVisible() ie. assuming that the associated DebugDeclare is always visible. This is currently done through a force argument to AddDebugValueIfVarDeclIsVisible(), but this method will ultimately be changed to just AddDebugValue() along with other clean-up once this change is approved.
This change was created because several different issues with DebugValues were tracked back to this logic: several cases of missing DebugValues, one case of a DebugValue generated with stale (ie. no longer defined) operands.
While contemplating fixing AddDebugValueIfVarDeclIsVisible(), it became apparent that the visibility analysis is unnecessary, at least for generating valid and correct SPIR-V. This was confirmed empirically when bypassing this logic and always generating DebugDeclares fixed all the issues and generated valid and correct code for the shaders at issue. The two regression tests that changed likewise still generated valid and correct SPIR-V. Subsequent use of the fix by RenderDoc revealed no problems.
The theoretical reason the visibility analysis is not necessary is because the position of a DebugDeclare within a function is not truly significant. Admittedly, the description of DebugDeclare is misleading: Define point of declaration of a [local variable]. However, if one looks at the operands of DebugDeclare, one realizes the true purpose of this instruction: to link a (whole or partial) DebugLocalVariable to a (whole or partial) OpVariable. The line, column and scope of the DebugLocalVariable declaration is actually already contained in the the DebugLocalVariable instruction itself. To have the position of the DebugDeclare also represent this information would be redundant at best and error-prone at worst.
Given that the position of a DebugDeclare within a function is not truly significant, any analysis based on that position consequently is not meaningful. Another way to think about this is that a DebugDeclare is visible everywhere in the function it appears in.
While it is tempting to think that a DebugValue instruction must have a scope that is contained in the scope of its DebugLocalVariable, that in fact is not stated in either of the DebugInfo specs. This allows DebugValues to be easily generated at the spot of the OpStore that it is replacing. The DebugLocalVariable in the DebugValue contains all the information the tool needs to figure out what local variable is truly changed.
Once this change is approved, I will complete cleanup of this change.

There does seem to be a problem.  The SSARewriter was not written to be shader specific.  So you cannot always compute the structured order.

Here is an example where the number of debug value instruction is much larger:
struct PSInput
{
        float4 color : COLOR;
};

void foo0(inout int in_foo) {
        ++in_foo;
}
void foo1(inout int in_foo) {
        ++in_foo;
}
void foo2(inout int in_foo) {
        ++in_foo;
}

float4 PSMain(PSInput input) : SV_TARGET
{
        int j = 0;
        foo0(j);
        foo1(j);
        foo2(j);
        j++;
        return input.color+j;
}

I will be a problem when the same variable is passed by reference to multiple functions.  This may not be a real problem, but keep it in the back of your mind in case it does cause a problem.


make check for container name case insensitive too

@alena1108 @cjellick @ibuildthecloud
Making check for container names case insensitive as well (in addition to host labels and container labels)

LGTM

LGTM


unable to connect to supabase

Describe the bug
im unable to connect to supabase the icon is not available to click
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-sxihyehh
Validations

[X] Please make your project public or accessible by URL. This will allow anyone trying to help you to easily reproduce the issue and provide assistance.

Steps to reproduce

go to bolt.new site
access Flebo Blood Sample Collection App Setup project
review error message
supabase icon is not available t oselect

Expected behavior
im expectign the supabase connection to be resolved t ocomplete the code
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 131
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>
performance.memory = {
  "totalJSHeapSize": 53242619,
  "usedJSHeapSize": 49382971,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = sabiry
Chat ID = c0dfe88abb4a

Additional context
No response

i refreshed the page and it synced


Vue Introduction page error

Version
2.3.3
Reproduction link
https://vuejs.org/v2/guide/#Conditionals-and-Loops
Steps to reproduce
Currently code on website looks like this:

Now you see mep>
div>

There is missing </ before p> and </ before closing div.
What is expected?
Add </ to the example code
What is actually happening?
I just noticed the error. I think everyone notice and this is not a big bug but yea if someone just started learning html then he'll be confused what happen or if someone just copy and paste code.

Maybe report it here https://github.com/vuejs/vuejs.org/issues?

it looks fine so it may have been fixed in the meantime. For this kind of problems, it's better to directly send a PR to the vuejs.org repo 🙁