Add an aggregation function for integration using Riemann sums.

I'd really like an integration aggregation function, so I've written one. At present it only works for float64 values. Some help making this idiomatic Go would be appreciated. I rarely write Go and don't know all the best practices for dealing with interface{}.
Another thing up for discussion is how to deal with the (physical) time unit used during integration. Timestamps are stored as nanoseconds but it seems impractical to make people always deal with for example W ns values when integrating power (W) over time. For now I've just made the integration unit seconds.
Also up for discussion is what type of Riemann sum to use. At the moment this is a left Riemann sum, as that makes the most sense for my particular data-set. The way I see it is that the value stored at a given timestamp would generally persist until the next point is inserted. This makes the area of a single block:
A_i = v_i * (t_(i + 1) - t_i)
  for 0 <= i <= n - 2

# Or equivalently (the version used in the mapping code):
A_i' = v_(i - 1) * (t_i - t_(i - 1))
  for 1 <= i <= n - 1

See: https://en.wikipedia.org/wiki/Riemann_sum
Addresses #1400
Happy to sign whatever if you decide to merge this. Thanks!

@mjdesa can you vet the math, please?

@beckettsean all the math checks out.
My only concern is that the method uses seconds as its unit interval. Ideally the unit should be set by the user.
Any thoughts @toddboom

I noticed another problem with my approach - cutting a large interval into chunks misses the area between the end of one chunk and the start of the next. I've fixed this in the most recent commit.
Other things I still need to do:

[ ] Prevent panics when the type of the field being integrated over isn't numeric.
[ ] Add a paramater to integral so you can do for example: integral(field, 1s) to integrate with seconds.

Ok, I haven't fixed the panics for integration badly typed expressions but I suspect that should be solved in a general way (#3353).
I'm not sure why the tests are failing...

@michaelsproul -- from out the test output:
=== RUN TestInitializeMapFuncPercentile
--- FAIL: TestInitializeMapFuncPercentile (0.00s)
panic: runtime error: index out of range [recovered]
	panic: runtime error: index out of range

goroutine 10 [running]:
testing.funcÂ·006()
	/usr/local/go/src/testing/testing.go:441 +0x249
github.com/influxdb/influxdb/influxql.InitializeMapFunc(0xc20803d3b0, 0xa25ee8, 0x0, 0x0)
	/home/ubuntu/influxdb-build/src/github.com/influxdb/influxdb/influxql/functions.go:51 +0x1797
github.com/influxdb/influxdb/influxql.TestInitializeMapFuncPercentile(0xc208032750)
	/home/ubuntu/influxdb-build/src/github.com/influxdb/influxdb/influxql/functions_test.go:80 +0x11f
testing.tRunner(0xc208032750, 0xa1cd20)
	/usr/local/go/src/testing/testing.go:447 +0x134
created by testing.RunTests
	/usr/local/go/src/testing/testing.go:555 +0xd4e

goroutine 1 [chan receive]:
testing.RunTests(0x945dd0, 0xa1ccc0, 0x2f, 0x2f, 0xa1ee01)
	/usr/local/go/src/testing/testing.go:556 +0xdc3
testing.(*M).Run(0xc20802e0f0, 0xa25940)
	/usr/local/go/src/testing/testing.go:485 +0xe1
main.main()
	github.com/influxdb/influxdb/influxql/_test/_testmain.go:152 +0x28d
FAIL	github.com/influxdb/influxdb/influxql	0.018s
=== RUN TestConfig_Parse

https://circle-artifacts.com/gh/influxdb/influxdb/4198/artifacts/1/tmp/circle-artifacts.9dMRvTF/test_logs_race.txt for full details.

@otoolep: So the failure is due to me removing some redundant code in InitializeMapFunc for checking that aggregates are given the right number of arguments. I took it out because I found the exact same logic duplicated in validateAggregates. The test only fails because it calls InitializeMapFunc directly. Would you prefer that I leave the redundant code in so that the test passes or remove the test entirely?

I should add some tests for integral too...

Please remove it, we don't have an objection to removing dead code.
On Friday, July 17, 2015, Michael Sproul<EMAIL_ADDRESS>wrote:

@otoolep https://github.com/otoolep: So the failure is due to me
removing some redundant code in InitializeMapFunc for checking that
aggregates are given the right number of arguments. I took it out because I
found the exact same logic duplicated in validateAggregates. The test
only fails because it calls InitializeMapFunc directly. Would you prefer
that I leave the redundant code in so that the test passes or remove the
test entirely?
—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb/pull/3344#issuecomment-122467615.

[ ] CHANGELOG.md updated
[ ] Rebased/mergable
[ ] Tests pass
[ ] Sign CLA (if not already signed)

Thanks @michaelsproul -- there are no tests however. Can you add some? Otherwise we will not catch any regressions. You could add them somewhat like this:
https://github.com/influxdb/influxdb/blob/master/cmd/influxd/run/server_test.go#L1206

Can you also move this CHANGELOG entry to 0.9.3? This is unlikely to ship in 0.9.2, since feature-freeze has passed for 0.9.2.

Ah, perfect, was looking for the high-level tests. I'll add some and bump the version :smile:

Ok, I've written some tests but I seem to be getting some really weird behaviour. In the test called eleven point integral (actually 10 points) the map function seems to get called with an empty iterator. I've changed the aggregate function to count for testing purposes and it behaves the same...
On my local machine (more clearly than in the interleaved CircleCI output), you can see there's only one empty partition for the map function to act on:
# This is the single point, it passes.
NEW QUERY
FIRST VALUE IS:<PHONE_NUMBER>0000 100
ONLY ONE VALUE 0 <nil>
[]interface {}{influxql.chunkIntegral{Area:0, StartTime:8.64e+13, EndTime:8.64e+13, EndValue:100}}
REDUCING 1 CHUNKS
# This is the two point, it passes.
NEW QUERY
FIRST VALUE IS:<PHONE_NUMBER>0000 100
computed the area of the first block
[]interface {}{influxql.chunkIntegral{Area:1000, StartTime:8.64e+13, EndTime:8.641e+13, EndValue:200}}
REDUCING 1 CHUNKS
# This is the "eleven" point, it fails.
NEW QUERY
MapCount called
ReduceSum called on  [<nil>]
[snapshot] 2015/07/22 17:35:14 snapshot listener closed
--- FAIL: TestServer_Query_Integral (1.12s)
	server_test.go:1324: input does not match format
	server_test.go:1327: integration test failed: eleven point integral
		expected: 10000.000000 actual: 0.000000
		query: SELECT count(value) FROM db0.rp0.power WHERE time >= 86440s AND time <= 86516s
		response: {"results":[{"series":[{"name":"power","columns":["time","count"],"values":[["1970-01-02T00:00:12Z",null]]}]}]}

I thought it was possibly the retention policy, but I've tried 0 (infinite?) and very large values without it making any difference.

@mjdesa, @beckettsean, @otoolep: Any ideas? I feel like this is so close to working that it's worth pursuing.

@mjdesa and I are on the support team, we aren't particularly qualified to review code for a PR. @otoolep is unavailable for a few weeks.
I've asked @pauldix to take a quick look, but the whole core team is heads-down on a just discovered query locking issue that's preventing us from cutting 0.9.2 final. Once that logjam is unblocked expect some attention from core devs on this PR.

Ok great! Thanks for the update! I can sit tight for a bit, no worries :)

@michaelsproul I fixed an odd bug on Friday that might have caused the problem you were seeing. Can you test again and resolve the merge conflict?

Unfortunately the same problem remains. Although I'm glad the Iterator Next method now returns -1 to signal the end of the iterator.

I'm using Postgres now instead, so I'll close this PR.

Nice feature, but moving to Postgres seems to be the solution...


Allow passing --include on the CLI?

Clear and concise description of the problem
Right now, there's no documented way I could find to specify the include config option with the CLI. Would the project be open to adding an --include CLI option?
Suggested solution
Being able to run vitest --include 'some/globs'.
--exclude support was added in #4148 -> #4279. I suppose this proposal is roughly the same idea.
Alternative
In the meantime, we can -t to specify on test names. But it'd be nice to go by file name.
Additional context
My use case is a project that has a few end-to-end tests defined with Vitest. Each of those tests runs a lot of commands and modifies the current directory. So being able to run e.g. pnpm run test:e2e:create that calls `vitest --include
Validations

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

Can't you just pass it down as a filter? The terminal usually handles it before Vitest ever needs to.
vitest **/some-glob.ts

Ah, that makes sense. I don't know why I didn't think of that as an implicit --include. Thanks! 😄

vitest **/some-glob.ts will limit the filter to files inside include and exclude patterns, so this is not a full replacement. See: https://github.com/vitest-dev/vitest/discussions/5348#discussioncomment-8718122

We believe that it's better to use a workspace feature to organize your Vitest configuration:
import { defineWorkspace } from 'vitest/config'

export default defineWorkspace([
  {
    test: {
      include: ['tests/**/*.unit.test.ts'],
      name: 'unit',
      environment: 'happy-dom',
    }
  },
  {
    test: {
      include: ['tests/**/*.e2e.test.ts'],
      name: 'e2e',
      environment: 'node',
    }
  }
])

You can then run it as vitest --project=e2e.
For that reason, as a team, we decided that it's better to wait until there is more demand for this feature (CLI --include).


Creating a sibling scene of the parent when Queue Freed causes material issues.

Godot version
4.0 beta 8.mono
System information
Windows 10
Issue description
When Queue Free is called on a parent node, this node should create a sibling of the parent, effectively resetting the scene.
However, instead it throws a number of errors about materials being set to true.
This does not occur if merely queue freeing the parent, or creating the sibling. It is only the specific combination of creating the sibling and freeing the parent that appears to cause this.
Noted this contains this issue as well, but it simply will swap to repo paths instead, and run into the same issue  as expected.
https://github.com/godotengine/godot/issues/68661
Steps to reproduce
Create a main scene.
That main scene should have a child node, which I will call "SceneToUnload"
SceneToUnload should in turn, have a child node, which I'll call "UnloadingNode"
UnloadingNode should have a script where on exiting tree, it creates a new instance of SceneToUnload as a sibling to its parent node.
Than simply calling QueueFree on SceneToUnload will work.
The attached example project uses DevBlocks as its block.
The script of note is under UnloadingNode.cs
In the production project the scene to unload is called BaseStage.
Simply running the project will run the necessary scripts as UnloadingNode QueueFrees its parent on process.
Minimal reproduction project
SiblingCreationFreeBug.zip

You should be getting this error:
ERROR: Parent node is busy setting up children, `add_sibling()` failed. Consider using `add_sibling.call_deferred(sibling)` instead.

This error means you are trying to add a node at a time that is not supported and recommends you to use call_deferred instead which will add the node during the idle frame instead of immediately.
Judging from the error message I guess this behavior is intended, maybe it could be better documented.

I in fact can confirm that the issue pops up in other cases, if you preload a scene or load it, than unload the original before it fully unloads the node, it can sometimes cause a material issue.
My workaround appears to be use load, not preload, shift the method to another class, and to use a timer to wait a second or so between the unload and load.
I have tried with call deferred as well.
If it is intended, it really should be better documented, as I would like to know if I unload one scene, I need to wait for a while before reloading it.


Disable Ability to Add to Collection or Delete From Collection

I have a collection of reviews that are stored in a database table. This table is populated by people who visit the website and leave what are essentially product reviews.
What I'd like to do is use Fluidity to mostly view those reviews. However, there is one thing that can be edited on each review (a toggle to approve reviews so they can display on the website). What they should not be able to do is delete reviews and add reviews.
I see that I can do this to make the entire collection read only:
collection.MakeReadOnly();

That's 99% of what I need, except then they can't edit the toggle on the reviews.
I suppose what I'm after is a "shallow read only". Meaning, the collection itself can't be modified, but the data on those items can be modified. Sort of like IReadOnlyCollection in C#.
I realize one workaround would be to create my own repository and hack it a bit so items can't be deleted or added. That's quite a lot of work though for something that could be built in, and it would be confusing for the user because they'd still see the buttons to add and delete items.

This will be fixed by merged in PR #75. I just need to get around to releasing it.


Add support for BYSETPOS (monthly and yearly frequency)

In August 2016, @NicolasMarlier added BYSETPOS support (https://github.com/seejohnrun/ice_cube/pull/349).
Then, in July 2018, @nehresma added a few small changes to run in modern Ruby and a more modern rspec (https://github.com/seejohnrun/ice_cube/pull/449).
Then, in January 2019, @davidstosik and @k3rni suggested changes to reduce complexity.
This incorporates all the above into a single diff.

Note that currently, all logic is passing but some builds are failing due to (I believe): https://github.com/tzinfo/tzinfo/issues/84

Looks like Travis has other problems, related to the Bundler version.

@davidstosik Thanks! I'll have a look at your branch.
I branched off the latest master to add these changes, so I'm also not sure why bundler is complaining.
I'm also trying to work on the to_s representation of the BYSETPOS data.

I also like your more generic version of BYSETPOS, so I'll close this in favor of your branch.


Chef Partner cookbook build badge

Description
Added the build badge per the new Chef Partner cookbook guide guidelines. This required us to ignore the .direnv in simplecov. I also fixed up the tests so they didn't output unwanted error messages.
Issues Resolved
(none)
Check List

[x] New functionality includes testing.

[x] All tests pass ($ rake test).
[x] New resources and/or actions have are included in the matchers.rb and matchers_spec.

[x] New functionality has been documented in the README if applicable.

[x] New functionality has been thoroughly documented in examples (please include helpful comments).

[x] Changes documented in the CHANGELOG.

@jjasghar , the last thing (assuming this passes now), is integrating this build into the PR process. If we're going to be posting the badge on the README, I think we'll want to verify it's passing before merging it. Travis reports back it's status on the PR, and I think it would be nice to do something similar here. Does the job automatically try to post a status back? If so, we can just set up the permissions accordingly.

@russellseymour we should look into this.

Also, @jjasghar , is there any additional value provided by this build over our Travis build? I assumed that the partner program requirements stated we needed to include a badge from Chef's Jenkins test infrastructure, but if that's not the case, can we just put a badge up from the Travis build instead? They run the same tests...
It would just kinda stink to have to mange multiple builds, one of which we can make PRs to, but don't have real control over to fix things quickly, run builds at will, etc.

Also, @jjasghar , is there any additional value provided by this build over our Travis build? I assumed that the partner program requirements stated we needed to include a badge from Chef's Jenkins test infrastructure, but if that's not the case, can we just put a badge up from the Travis build instead? They run the same tests...

Good question. In order for us to integration tests for other cookbooks we needed to standardize on a build system. If you want, you can remove your travis tests; but for us we are going to be validating via our Jenkins build.
If you see though: https://travis-ci.org/HewlettPackard/ilo-chef/jobs/166815356 and https://jenkins-01.eastus.cloudapp.azure.com/job/ilo-cookbook/101/console show that things aren't pin correctly?
After reading this, I feel like i'm not getting my point across. Can we sync on a Zoom in the near future?

Definitely! I'll be out of the office this morning, but free all afternoon. (and available tomorrow afternoon as well)

I'm in EMEA this week, but next week i'll be around. I'll send an invite out next week.

Sounds good! Thanks JJ :smile:

:+1:


Wrong word used?

In this sentence "Use similar rations for your new themes." I suspect the intended word was either "ratios" or "rationales".
Perhaps there is a colloquial meaning for "ration" that isn't in the dictionary.  If so, such a non-standard use should be clarified.

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

ID: 1e078819-d3b4-8b28-1e76-b005af5d15c6
Version Independent ID: e426087e-f2e2-1911-56b1-84b4aaa0435b
Content: Change the color scheme or add a logo  in Dynamics 365 Customer Engagement (on-premises)
Content Source: ce/customerengagement/on-premises/customize/change-color-scheme-add-logo-match-organizations-brand.md
Service: crm-online
GitHub Login: @Mattp123
Microsoft Alias: matp

@Mbrmanning - Thank you for pointing this out. The topic has been revised to indicate "ratios" instead of "rations." Closing issue.


Fix: Blocks table

Number of records of the blocks table is not accurate.

finney

nakamoto

subquery issue
reported to the team


Added missing metal resistor symbols

I'm using some metal resistors in local interconnect and metal 3, and the symbols were missing. To get the LVS correct I copied the res_generic_m1 to the other metal layers.
Example files:
Sch: https://github.com/wulffern/aicex/blob/main/ip/sun_pll_sky130nm/design/SUN_PLL_SKY130NM/CAP_LPF.sch
Lay: https://github.com/wulffern/aicex/blob/main/ip/sun_pll_sky130nm/design/SUN_PLL_SKY130NM/CAP_LPF.mag

Added the new symbols. Thank you.


Will FlurryWatch work with watchOS standalone app?

@sjsoad Currently we do not provide support for FlurryWatch to work with watchOS standalone app. We do plan to provide support for this in the future so stay tuned!

Hello. Any changes there?


silly warning related to fread

/home/defle/deflemask/src/rombuilders/gbvgm/gbvgm.c:108:5: warning: ignoring return value of 'fread', declared with attribute warn_unused_result [-Wunused-result]
fread(vgmBuffer->buffer,1,fileSize,f);

I'll fix this in the next update

Patched in https://github.com/Pegmode/-DeflemaskGBVGM-/commit/bcb44c944dc492c0315a9d06fb7f20dd883f7c9f

new update pushed


CSS variable consistancy

Prerequisites

[X] I have searched for duplicate or closed feature requests
[X] I have read the contributing guidelines

Proposal
I am currently working on a Figma design to incorporate variable-based theme support for a BS5-based site. During the process, I found the CSS Variable documentation to be particularly helpful.
I understand that the Bootstrap team invested significant time and effort in determining these names, likely with good reasons for maintaining the status quo. However, I firmly believe that constructive feedback is always beneficial, hence I would like to share my thoughts.
Expectations
To begin with, I have certain expectations from a variable collection:

Conciseness should be prioritized, with elements omitted if uncertain.
Clear and distinct intended purposes for each variable.
Semantic naming should be followed, focusing on the function rather than appearance.
Consistency across both light and dark themes.
Completeness: There should be no other "magic" colors in the CSS to allow seamless switching between light and dark themes by only replacing the variable definitions.
Bonus: Semantic grouping through the use of prefixes like status-, text-, bg- would be beneficial when sorting alphabetically, though I recognize this may be a personal preference.

While developing the variable specification, I found the current naming conventions rather challenging to work with. As a result, I created a mapping table to prevent any errors. I am sharing my findings with the hope that they might be considered for inclusion in a future version of Bootstrap.
Suggestions

Align definitions for dark and light themes for completeness and consistency.
Remove the --bs-gray-XXX variables, as their inversion for the dark theme could lead to misleading names. A potential alternative could be naming it --bs-foreground-???, where --bs-foreground-full represents the pure color for the light theme and --bs-foreground-000 represents the background color. (Although there might be better names for foreground).
Remove all duplicate occurrences of -rgb. It's extremely unfortunate that CSS does not allow RGBA variables to be used in rules like...
background-color: rgba(var(--bs-danger-rgb),var(--bs-bg-opacity))
But I strongly believe that placing the burden on the theme-developer is confusing, adds unnecessary duplication, is error-prone, and bloats the size of the variable collections. I would prefer to enforce all variable definitions as rgb(23,23,23) as most of them don't use transparency anyways.
Replace the -color suffix with -text to avoid confusion and maintain consistency with variables such as --bs-warning-text-emphasis or --bs-border-color.
Replace -light and -dark with alternative wording. My suggestion is to use terms like -highlight and -invert.
I think the definition of emphasizing levels like subtle, (normal), emphasis, should be orthogonal to signals like warning, success, and usage text, bg, border.  I just would have preferred separate variables for default -text and -bg colors to clarify that --bs-danger is never used for text and -emphasize is actually the default. If there is a --bs-secondary-bg, shouldn't there be --bs-danger-bg? I have the feeling that the naming for layout colors (e.g. --bs-secondary-rgb) collides with levels for signals like --bs-secondary-bg-subtle.

I propose the following mapping:

BS5
Proposal
Remark

--bs-primary
--bs-primary-fill
Colored button background used with white text

--bs-primary-text-emphasis
--bs-primary-text
Colored text in alert boxes, etc

--bs-primary-bg-subtle
--bs-primary-bg
Background for alert boxes with colored text

--bs-primary-border-subtle
--bs-primary-border
Outline for buttons and boxes

--bs-primary-bg
(removed)
Either remove or clarify usage with a suffix like -table-bg

--bs-body-bg
--bs-bg-body
Separate layout from signal.

--bs-secondary-rgb
--bs-bg-secondary
makes it more relatable to layout.

I initially missed variables for input-components, like input-fill, input-border, input-placeholder and states like focused, required, disabled. But after checking the source-code of the Button-example, I noticed that there actually is a variable --bs-btn-disabled-color and the documentation was just incomplete. A link to the complete list would have helped me.

Proposal (RFC).
For my project, I have created the following mapping. If things go well, I can release the figma-library with the correct mapping for dev export.

Figma
BS5
Default dark

text/body
--bs-body-color
#dee2e6

text/emphasis
--bs-emphasis-color
#fff

text/secondary
--bs-secondary-color
rgba(222, 226, 230, 0.75)

text/tertiary
--bs-tertiary-color
rgba(222, 226, 230, 0.5)

text/code
--bs-code-color
#e685b5

text/highlight
--bs-highlight-color
#dee2e6

bg/border-translucent
--bs-border-color-translucent
rgba(255, 255, 255, 0.15)

bg/body
--bs-body-bg
#212529

bg/border
--bs-border-color
#495057

bg/highlight
--bs-highlight-bg
#664d03

bg/secondary
--bs-secondary-bg
#343a40

bg/tertiary
--bs-tertiary-bg
#2b3035

form/invalid-border
--bs-form-invalid-border-color
#ea868f

form/invalid-bg
--bs-form-invalid-color
#ea868f

form/valid-border
--bs-form-valid-border-color
#75b798

form/valid-bg
--bs-form-valid-color
#75b798

text/heading
--bs-heading-color
inherit

text/link
--bs-link-color
#6ea8fe

text/link-hover
--bs-link-hover-color
#8bb9fe

signal/primary-fill
--bs-primary
#2c0b0e

signal/primary-bg
--bs-primary-bg-subtle
#2c0b0e

signal/primary-border
--bs-primary-border-subtle
#842029

signal/primary-text
--bs-primary-text-emphasis
#ea868f

signal/secondary-fill
--bs-secondary
#2c0b0e

signal/secondary-bg
--bs-secondary-bg-subtle
#2c0b0e

signal/secondary-border
--bs-secondary-border-subtle
#842029

signal/secondary-text
--bs-secondary-text-emphasis
#ea868f

signal/tertiary-fill
--bs-tertiary
#2c0b0e

signal/tertiary-bg
--bs-tertiary-bg-subtle
#2c0b0e

signal/tertiary-border
--bs-tertiary-border-subtle
#842029

signal/tertiary-text
--bs-tertiary-text-emphasis
#ea868f

signal/success-fill
--bs-success
#2c0b0e

signal/success-bg
--bs-success-bg-subtle
#2c0b0e

signal/success-border
--bs-success-border-subtle
#842029

signal/success-text
--bs-success-text-emphasis
#ea868f

signal/info-fill
--bs-info
#2c0b0e

signal/info-bg
--bs-info-bg-subtle
#2c0b0e

signal/info-border
--bs-info-border-subtle
#842029

signal/info-text
--bs-info-text-emphasis
#ea868f

signal/danger-fill
--bs-danger
#2c0b0e

signal/danger-bg
--bs-danger-bg-subtle
#2c0b0e

signal/danger-border
--bs-danger-border-subtle
#842029

signal/danger-text
--bs-danger-text-emphasis
#ea868f

signal/warning-fill
--bs-warning
#2c0b0e

signal/warning-bg
--bs-warning-bg-subtle
#2c0b0e

signal/warning-border
--bs-warning-border-subtle
#842029

signal/warning-text
--bs-warning-text-emphasis
#ea868f

signal/invert-fill
--bs-dark
#2c0b0e

signal/invert-bg
--bs-dark-bg-subtle
#2c0b0e

signal/invert-border
--bs-dark-border-subtle
#842029

signal/invert-text
--bs-dark-text-emphasis
#ea868f

-
--bs-body-color-rgb
222, 226, 230

-
--bs-emphasis-color-rgb
255, 255, 255

-
--bs-link-color-rgb
110, 168, 254

-
--bs-link-hover-color-rgb
139, 185, 254

-
--bs-tertiary-color-rgb
222, 226, 230

-
--bs-secondary-bg-rgb
52, 58, 64

-
--bs-tertiary-bg-rgb
43, 48, 53

-
--bs-light-border-subtle
#495057

-
--bs-light-text-emphasis
#f8f9fa

Motivation and context
see above.

Thanks a lot @pixtur for such detailed feedback.  I'm tagging it as v6 as it can be studied in depth when we start working on the new major version of Bootstrap where we plan some CSS refactoring, especially regarding the themes (and so the Sass/CSS vars linked to that).
I'll read your feedback thoroughly as soon as possible.

@julien-deramond  Thank you. I hope I didn't come across too negative here. While writing the issue and reading the documentation more thoroughly,  I had to remove and adjust many of my initial complaints. This is just my way of learning stuff. BS really has come a long way. So, if I can slightly contribute to upcoming releases, perfect!


[Bug]: Wrong font color in email template

Preflight Checklist

[X] I could not find a solution in the documentation, the existing issues or discussions
[x] I have joined the ZITADEL chat

Environment
Self-hosted
Describe the bug
I setup custom branding for the light and dark mode. Now I send a test verification mail to my own user address. The font color is white despite the primary color being also a bright color...
To reproduce

Setup custom branding, choose a bright primary color
Send a verification mail
Zitadel will use the primary color in the mail as background of the button with a white text which makes it hard to read

Screenshots

Expected behavior
If the email is in the light mode, it should also take the same colours like setup in the branding settings - which would be black text in my case.
Version
2.14.3
Operating System
Irrelevant
Relevant Configuration
Light Mode Config:

Dark Mode Config:

Additional Context
No response

Is connected with #4191


Changes filed_in_one_year values from True/False to Yes/No/Unknown

Description
Stakeholder wanted filed_in_one_year values to be yes/no/unknown instead of True/False

Adds conditional to uploadRouter to change True/False received from DS to yes/no/unknown to be passed to frontend
Changes filed_in_one_year column type to string instead of boolean to handle conversion from True/False to yes/no/unknown
Changes seeds for filed_in_one_year from True/False to yes/no/unknown.
Update reflected in the ReadMe documentation

** See corresponding PR on frontend for reference: Frontend PR **
Trello Card
Contributors: @schandrupatla
Fixes issue of the user seeing True/False for Filed Within One Year on the frontend
Type of change
Please delete options that are not relevant.

[X] Bug fix (non-breaking change which fixes an issue)
[X] This change requires a documentation update

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have removed unnecessary comments/console logs from my code
[X] I have made corresponding changes to the documentation if necessary (optional)
[X] My changes generate no new warnings
[X] I have checked my code and corrected any misspellings
[X] No duplicate code left within changed files
[X] Size of pull request kept to a minimum
[X] Pull request description clearly describes changes made & motivations for said changes

Loom Video

You're right, @ZacharyCooremans . It looks like it doesn't like the commented out ds_case migration file (the migration file to go with the ds_case seed file that we removed because it was breaking running our seeds). I will try deleting the migration file as well since we've deleted the corresponding seed file since Alex Tran shared with us that these files were not needed but rather for his reference.
This same failed check is occurring in the alignment of schema PR. I'll make note of it in that PR and delete the migration file there too, unless you think this could create some sort of merge conflict down the line.


Pattern matching (switch) for GDScript

I'd like to suggest adding pattern matching to GDScript and I would be willing to implement it.
As of now, GDScript doesn't feature a switch statement - you have to chain multiple if statements.
(All the syntax here is just a first sketch, suggestions welcome)
Pattern matching
Pattern matching is the inspection of the structure and contents of a value to branch execution.
So for simple values (like numbers, strings) it acts like a switch statment.
var num = 42
match num:
    0:  print("Zero")
    23: print("Half way there")
    42: print("The answer")

The difference to a switch statement is that those cases can be nested. You can match on the contents of an array for example.
var array = [13, "37", ["test", "array"]]
match array:
    [13, "37", ["test", "array"]]: print("Wow, a perfect match!")
    [13, 37, ..]:                  print("l33t man") # .. matches the rest of the array
    []:                            print("empty array")

Matching on a dictionary would work the same, except that matching on keys wouldn't be possible.
Dictionaries would be matched on the key and the value.
Deconstructing values
Instead of simply branching depending on the equality of values it would be possible to bind new variables.
When the first pattern that matches the value is encountered the corresponding branch will be executed. If a pattern doesn't match the next one is tried. So the *more general patterns should be defined beneath the more specific.
To bind a new variable you would simply write a new identifier instead of a value.
var array = [13, "37", ["test", "array"]]
match array:
    [13, "37", [var a, var b]]: print(a, ", ", b) # a = "test", b = "array"
    var n:                      print("Unknown array structure: " + str(n))

When matching dictionaries only the value would be bindable. e.g. {"test": var a}
Just matching on a new identifier is equal to the default case in switch-statements.
_Let me know what you think_ :blush:

Here, have a :+1: from me :) do the haskell :P

I like this because the syntax is basically equivalent to a switch (bar fall-through but who needs this anyway), but can optionally more powerful when needed

I assume you mean this to accept a block of statements:
var num = 42
match num:
    0:
        do_the_zero_routine()
        print("Zero")
    23:
        print("Half way there")
    42:
        print("The answer")
        make_it_sparkle()

@vnen Yes, of course!

I don't see how useful such a syntax is compared to the cost of implementing it in GDScript. I almost never had to do that in any game I made. And when I needed matching it was straightforwardly implemented with some ifs.

Just throwing an idea in here.
In Haskell it's possible to add guards to every pattern, like this:
case [1, 3, 3, 7] of
    [1, a, b, 7]
        | a * 10 + b < 42 -> "Ok, passed the test"
        | otherwise       -> "That is unacceptable!" -- otherwise = True
    _ -> "I won't inspect you! >=D"

Possible GDScript syntax could be something like this:
match [1, 3, 3, 7]:
    [1, a, b, 7]
        if a * 10 + b < 42: print("Ok, passed the test")
    [1, a, b, 7]:           print("That is unacceptable!")
    n:                      print("I won't inspect you! >=D")

I feel like the if is more pythonesque but it adds a lot more noise to the code.
Also when taking the if route I don't know if the otherwise case should be implemented. A fall-through works too like in the example.

@Zylann I think it's much clearer and easier to read than multiple ifs. But sure, this isn't needed, but I think it would be a great addition to the language because it's really pleasant to use. But that's subjective of course.
The performance cost shouldn't be that high. I would transform these nested patterns into multiple simple pattern matches. If a pattern doesn't match in the first inspection the next case is tested, so it wouldn't be that much slower than ifs.

Well, I agree that performance penalties should be avoided. I'm not sure if this syntax will or not be more costly than regular if chain though. It depends a lot on implementation.

@vnen regarding implementation,  I want to implement it like described in this book. (The implementation of functional programming languages by Simon Peyton Jones)
Example translation from
match array:
    [1, 3, a]: print(a)
    n:         print("No match")

to
if array[0] == 1:
    if array[1] == 3:
        var a = array[2]
        print(a)
else:
    var n = array
    print("No match")

So the complexity of not matched expressions should not have any impact on execution speed compared to hand written ifs.

@karroffel well, it looks confusing to me. Not that reading it is confusing, but regarding all current features of GDScript it looks like an alien, and I don't see where this could be used often. I never worked in functional languages like Haskell btw :s

@Zylann it can be used everywhere where a switch could be used. Just read it like a switch statement :wink:
I understand the lack of "need" to have it, but then I could argue that for loops are unnecessary because there are if-statements and recursion :laughing:
Like I said, you can do everything in GDScript without a pattern matcher, but once you got used to pattern matching it becomes really useful and powerful.

var inventory = ["sword", "shield", "magic key"]
match array:
	["sword", "shield", "magic key"]:
		print("You came as a pure warrior, Welcome!")
		can_open_door = true
		break;
	["sword", "shield", ..]:
		can_kill_monster = true
		can_broke_door = true
		can_evade_monster = true
		break;
	["sword", .. ]:
		can_broke_door = true
		break;
	["shield", .. ]:
		can_evade_monster = true
		break;

@karroffel Will this be possible?
Will a negative pattern format to make ".." not to match with "magic key" implemented? Or an if inside a pattern better fit for this situation.

Should this pattern matching be as full-featured as regular expressions? :D

For me having a negative pattern (not a regex) will make a use case, cause it will make scenario coding easy and readable. But if result will be less than that, I would prefer regular "switch" and "if" statements unless there is a side benefit like performance gain or less LOC.

@hubbyist arrays depend on order, so your example wouldn't work that way. The .. is just there to ignore the rest of the array and match it (because it depends on order and you don't care about the rest, only the first few elements for example). Dictionaries don't have a specified order, maybe I could add special syntax to just match the keys to use it like a regular set.
@Zylann No, it will only compare for equality and bind variables and all of that can be nested.

I implemented the parser yesterday. I added a "set syntax" for dictionaries to check if a key is present.
var inventory = {"sword": 20, "shield": 100, "magic key": 2]
match inventory:
    {"sword", "shield", "magic key"}:
        print("You came as a pure warrior, Welcome!")
        can_open_door = true
    {"sword", "shield", ..}:
        can_kill_monster = true
        can_broke_door = true
        can_evade_monster = true
    {"sword", .. }:
        can_broke_door = true
    {"shield", .. }:
        can_evade_monster = true

So in the example I don't care about the values, I just want to check if a property is present.
It is also possible to use simple constant expressions as a pattern, like this:
var size = 1024 * 1024 * 1024 # GiB

match size:
    1024:
        print("KiB")
    1024 * 1024:
        print("MiB")
    1024 * 1024 * 1024:
        print("GiB")
    a:
        print("something different")

Today I will transform this into ifs and vars and then most of the hard work is done

I would love to see this implemented. I ask about switch statements every 3-6 months :)

@karroffel About guards, pattern if cond sounds pretty good :smile:
(I'm talking about cases like
var arr = [1,2,3]
var first_required_value = 1
match arr:
  [x, ..] if x == first_required_value:
    foo(bar)
  a:
    printerr("Bad luck")

)

Would an else be allowed too?

At first: matching on constants is already finished, so basically a switch (it's finally here!!), now I have to work on the array and dictionary matching...
I don't know how to implement fallthrough efficiently yet. To maximize efficiency I want to sort the patterns, so a general fallthrough could be problematic. (if I don't sort I may have to check array contents multiple times)
@Zylann I still have to think about how to implement guards. else should be allowed if guards are allowed IMO but there should also be a fallthrough if there is no else and the other guards fail, so it's a bit problematic right now.

Something like try catch style may be better than a fallthrough IMO.
var inventory = {"sword": 20, "shield": 100, "magic key": 2}
match inventory:
	{"sword", "shield", "magic key"}:
		print("You came as a pure warrior, Welcome!")
		can_open_door = true
	...
	...
	...
	{"shield", .. }:
		can_evade_monster = true
otherwise:
	print("You can't do anything here!")

I think that for no match, an else would be more readable (not sure if it should be inside or outside the block though).

What about
match x:
	...
	...
otherwise:
	...

Usually, pattern matching uses:
_ = matches anything when there's no identifier ("wildcard pattern"). Does not bind an identifier.
This is consistent in all languages I know: Haskell, Scala, Elm, Racket, F#, OCaml, Rust. I don't think there's an exception.
So the idiomatic way to do it, to stay sorta in tune with other languages that have pattern matching, should be to use _.
Incidentally, all those languages usually (not always, Scala does not iirc) implement some sort of Nothing pattern, for when there's no value (which is different from fallthrough).

So after discussing guards on the IRC (thanks @akien-mga) I think we got a nice compromise.
Instead of adding guards it is possible to use continue to check the other patterns. So guards would be simple if/elses in the branching code and failing/fallthrough would be done via continue.
That keeps the parser simple and the patterns are a bit easier to read.
I think _ should be the default wildcard pattern.
I will do the matching in-order which may be more inefficient but it simplifies a lot of the transformations.

I would honestly just implement the standard switch syntax, simply because
users ask a lot for it, and wouldn' t go much further than that
On Fri, Oct 7, 2016 at 9:12 AM, Karroffel<EMAIL_ADDRESS>wrote:

So after discussing guards on the IRC (thanks @akien-mga
https://github.com/akien-mga) I think we got a nice compromise.
Instead of adding guards it is possible to use continue to check the
other patterns. So guards would be simple if/elses in the branching code
and failing/fallthrough would be done via continue.
That keeps the parser simple and the patterns are a bit easier to read.
I think _ should be the default wildcard pattern.
I will do the matching in-order which may be more inefficient but it
simplifies a lot of the transformations.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6593#issuecomment-252236803,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z24qABylU7GPi4UNXJ1myXyKsGcIdks5qxjcRgaJpZM4KFJl9
.

@reduz I see, but why strip away features that don't need to be used, they are optional. All the switch functionality is there and pattern matching got a lot more common in programming languages in general.
If a new construct is added to the language, I don't see why it should be made less powerful than it could be.
And like I said many times, this syntax isn't written into stone, it could be changed to the switch syntax without tossing away the additional features.

naive question : isn't
match size:
    1024:
        print("KiB")
    1024 * 1024:
        print("MiB")
    1024 * 1024 * 1024:
        print("GiB")
    a:
        print("something different")

the same as :
switch size:
    case 1024 :
        print("KiB")
        # implicit break
    case 1024 * 1024 :
        print("MiB")
        # implicit break
    case 1024 * 1024 * 1024 :
        print("GiB")
        # implicit break
    case a :
        print("something different")
        # implicit break

???
so wouldn't it jsut be a matter of adding/replacing keywords and keeping the more powerfull pattern matching ?

@SuperUserNameMan It is the same. (but case a would be default)
That's what I'm saying, it would be possible to use the switch syntax but keep all the destructive pattern matching features

if using this to do basic switch/case (without using the more powerful pattern matching features thing), does it adds extra cost compared to a if/elif/else equivalent :
if size == 1024 : print("KiB");
elif size == 1024 * 1024 : print("MiB");
elif size == 1024 * 1024 * 1024 : print("GiB");
else : print("something different");

?
does it generate more opcodes ?
is the code behind it as fast ?

@SuperUserNameMan basic typechecking is needed to catch invalid equality checks. Other than that the code would be the same as you wrote it.

I support this. The idea of removing functionality from something that's already implemented makes no sense. People can use it just like a switch, but also make use of the pattern matching. I don't understand why it has to be dumbed down.

@karroffel : then, i personally see no reasons (me neither) to get rid of the more advanced pattern matching features things that you have already implemented if it can do basic switch/case without extra cost (or just little cost) and if the little extra cost adds a little benefit compared to the if/elif/else statements.
So it would be just a matter of replacing/adding  traditional switch/case/default keywords to make it look more "familiar" and more "friendly".

(btw, maybe the case keyword could be made optional, and switch could be made an alias of match ... this way, everybody could be happy )

(btw, maybe the case keyword could be made optional, and switch could be made an alias of match ... this way, everybody could be happy )

No, trying to make everybody happy this way leads to bloat and a terrible syntax and UX. Find the best syntax, and enforce it.

In "regular" switch statements there must be a break to avoid fallthrough which isn't idiomatic pattern matching style. So mixing these syntax's would require bookkeeping of which syntax was used and code has to be generated differently. I'd like to have a uniform syntax

I'd like to suggest using the match syntax. There would be no mandatory break and even in switch statements fallthrough is very uncommon.
All that changes is:

change switch to match
drop case and break
for fallthrough use continue

That's it. The functionality is there, pointing to the match statement in the docs should be enough since everybody new has to learn GDscript anyway.

Personally I hate to write break keyword in switch statements. It is mostly extra line of code which is mostly not necessary. If another case starts this is clear indication that previous one has finished. Fall through just works for channeling multiple choices into single function and only this makes break meaning full. But this can be done by combining empty cases into one single case with or keyword like using switch(true): method or using continue keyword as suggested by @karroffel.

continue would be the programmatic way of doing it. I don't see any reason not to implement something like 1, 2, 3 or even 1 .. 3 in patterns. Yes, it would increase complexity, but so does a mandatory break

Would it be possible to replicate this switch usage with pattern matching?
switch(val):
    case 0:
        return false
    case 1:
    case 2:
    case 3:
        print("Stuff")
        break
    case 4:
        print("42")
        break
    default:
        print("Default")

@Zylann
match val:
    0: return false
    x:
        if x >= 1 && x <= 3:
            print("Stuff")
        else:
            continue
    4: print("42")
    _: print("Default")

or maybe I'll add something like this
match val:
    0: return false
    1 .. 3: print("Stuff")
    # different version
    # 1, 2, 3: print("Stuff")
    4: print("42")
    _: print("Default")

What if _ is an existing variable? It's a valid name after all :)

@Zylann _ is a kind of pattern, not a name bind. If it would be a name it would shadow the other variable but since it's just a pattern nothing special happens and the old _ can still be used

What happens if you put _: not as the last match? Should it throw an error?

@Zylann Well, it matches everything, so everything after that wouldn't be executed except for when you place a continue inside the branch

About 1..3 construct, I prefer, by far, the x,y,z one.
Rationale:

match 1..3 is ambiguous. Am I matching against the full pattern, or one of the members of the genrated ranged? What if I want to actually match an array that looks like [1,2,3]?
If you need to match against several values, they won't always (I'd say probably almost never) be consecutive. Consider:

match http_response:
    200: "data loaded successfully"
    403,404,500: "an error occurred"

or
match tile_at(x,y):
    TILE_WATER:
        drown()
    TILE_WALL,TILE_BARREL,TILE_CHAR,TILE_SPIKE:
        stop()
        continue
    TILE_SPIKE:
        life = life -2

Unrelated, but on the subject of dreamland implementations, I like that in some languages, match is an expression, so you can do something like:
var acceleration = match input:
    UP:
        vector(1,0)
    DOWN:
        vector(-1,0)

Not advocating for this, as the whitespace-type syntax of GD makes it cumbersome, just thought it's an interesting thing :)

For people advocating for switch vs match. I frankly do not see a valid rational reason for that
This is going to be a bit lengthy, not because I care about this so much (I am likely to almost never use switch of match myself anyway), but because I'd like the convo to be more constructive, instead of being lost in meanderings.
Here are the arguments against match, from what I can gather:

match doesn't have fallthrough
switch is more familiar

Let's start with argument 1:

match does everything switch does, minus default fallthrough.
However, fallthrough by default is:

virtually never used (in 20 years of programming, I've never seen a program in which switch was implemented without a break after each case. I'm sure it exists, but never seen it)
Bug-inducing (easy to forget, and compiler throws no errors)
If ever used, the exception rather than the common use case (in which case, tackling it through continue makes more sense).

TL;DR: match does everything switch does well, while avoiding the pitfalls of switch, and allows for deeper semantics if the programmer wishes to use them (not the case with switch, which is less flexible than regular ifs)

The argument for familiarity is also flawed, as GD is it's own language, and there shouldn't be a problem in learning one new word.
Alternatively, the argument of familiarity should be extended to: whitespace as syntax, elif, no curly braces, one file = one class, ...All of which may or may not be familiar, depending on which languages you've used before. None of the above were for me, for example, but match is.
Python doesn't even have switch at all (and for good reason), so even invoking GD's syntactic closeness with Python isn't a valid argument.
But, assuming switch is "familiar" (which, again, really depends which language you're coming from, but let's say it is, for the sake of argument), for a programmer, looking up the doc and replacing
switch val:
    a:
        do_something()
        break;
    b:
        do_something_else()
        break;

with:
match val:
    a:
        do_something()
    b:
        do_something_else()

...is trivial.
There's basically no learning curve at all. For someone reading code, it's also just as trivial to understand what's going on, even if you've never seen a match before. Incidentally, that's how I learned of the match construct: reading code and stumbling upon it. I didn't need more than a split second to understand it was just a cleaner switch without breaks. Sure, understanding how powerful it was required to read the docs, but understanding it and using it everywhere a switch could be used needs about 1 to 10 seconds of learning.
For a newbie, it's easier to learn, and he or she doesn't need to deal with understanding what fallthrough is, or remembering to add a break after each statement.
TL,DR: the argument of familiarity doesn't hold; first, it is subjective. Second, even assuming it is true, for a programmer, learning a slightly different syntax is on par for the course, and for non-programmers, match is less likely to be buggy, yet, slightly easier to learn (same syntax minus one construct).

In summary, this language improvement proposal:

is proven to be semantically efficient and a valuable abstractions (as demonstrated by all the languages that have implemented it)
is easier to learn and more bug-proof for newbies, with no hidden things to look out for
allows for more powerful abstractions than its alternative
...while not only not adding bloat, but actually removing some
doesn't impose any added cognitive load on the programmer (not more than remembering elif instead of else if)

I think it should be possible to use constants as a pattern (to match stuff like TYPE_FLOAT or so). Problem is, that it's not possible to detect at parse time (where I am doing the transformations) if a StringName names a constant or not.
So to differentiate constants and bindings it would be necessary to use var name for a binding and simply SOME_CONSTANT for constants. (I'll update the examples in my initial comment)
In order to match on patterns of different types it's necessary to add simple typechecking to avoid errors at runtime. To keep things simple I just want to do stuff like that (I'm actually doing it like this right now):
match 4:
    "hello": print("It's a string that says \"hello\"")
    4:       print("It's 4")

# compiles to something like this
var match_value = 4 # actually it's "#match_value"
                    # this name can only be created by the compiler
                    # but this messes up syntax highlighting ;)
if typeof(match_value) == typeof("hello") && match_value == "hello":
    print("It's a string that says \"hello\"")
    # goto end
if typeof(match_value) == typeof(4) && match_value == 4:
    print("It's 4")
    # goto end
# end:

If you try to match on patterns that have side effects the pattern would execute twice (because of the typecheck), so it wouldn't be good to use patterns with side effects. I could work around this but that would require bookkeeping of temporary variables that would just make the whole transformation more complex.
So I'd say that patterns with side effects should be avoided but not disallowed. What do you think?

What is a pattern with side effects? Calling a function in the pattern?
match val:
    get_some_int(val): some_effect()
    get_some_other_int(val): some_other_effect()

...That?
And yeah, I think using var to declare variables in the pattern is less confusing and more appropriate.

quoted from : @Xananax

I think using var to declare variables in the pattern is less confusing and more appropriate.
:+1:

@Xananax no, something like that:
var counter = 0
func side_effect_pls(x):
    counter += x
    if counter > 1:
        return x
    return counter

...
match 3:
    side_effect_pls(3): print("<- that's baaad")

Yes, that's what I meant.
I think that may be useful (being able to invoke functions in the pattern), but if the implementation gets overly complex because of it, then it's not worth it. It can always be implemented later, if people request it.
"Don't code for average case, don't code for best or worst case, code for most used case and stop at that" -- some dude, I don't remember who.

Should follow @reduz's principle: "Add the minimum needed to work. Only add more stuff if many people request it".

How are you going to count the people who request it? How much is many?

With our fingers. If it doesn't fit on one hand, it's probably many.

Is there a reason you need to use the underscore for a fallthrough? This takes away the possibility of using it as a variable

@ClikCode
Fallthrough? Fallthrough is done with continue. You mean wildcard patterns.
Quote Xananax:

This is consistent in all languages I know: Haskell, Scala, Elm, Racket, F#, OCaml, Rust. I don't think there's an exception.
So the idiomatic way to do it, to stay sorta in tune with other languages that have pattern matching, should be to use _.

@karroffel All of those languages are functional or heavy functional-inspired. What about the imperative languages?

@bojidar-bg most imperative languages don't feature pattern matching so it's not really possible to give an example.
C# 7 will have some form of pattern matching but it's just an addition to a basic switch, so it's not useful here.
Imperative languages don't have pattern matching because it has its roots in algebraic datatypes, which still aren't adopted in imperative languages. Many modern languages have pattern matching as they have algebraic datatypes too. So it's mostly a historic thing.

match blah:
    1:print("I am some one")
else:
    print("I am no one")

Is how python would do it if they ever did this

@ClikCode what about
match x:
    [1, _, _, 7]: print("kek")

what about using '?' or '*' instead of '_' character ? These are used as wildcards for regular expressions so not to far from pattern matching. This will leave valid variable name characters out of pattern matching syntax.

What happened to "variables should have descriptive names"? Is there any valid reason that someone would want to call a variable _ unless they want it to be forgotten?
func (_,x) => x+1

The implicit meaning of the function above is the that the first argument is skipped (without even reading its body). Regardless of pattern matching, I doubt you can make a case for wanting to call a variable _, unless, again, you don't want to use it.
The javascript library "underscore" is called _ precisely because no one ever would use this as a variable name and was as such a relatively "safe" global.
In 20 years of code, working with open-source, in companies small and big, I've never seen once someone use _ for a variable name, unless they really really wanted it forgotten. Not saying my anecdotal experience is proof of anything, but it's still an indicator.
So that's about the "why". I realize it is not a compelling argument, someone could still want to name a variable _, but considering most common case is important nonetheless.
Secondly; in some languages (don't know if the Godot implementation does that), the _ does resolve to whatever was passed; It is a usable variable, whereas it'd be syntaxically impossible to use ? or * for the same effect.
e.g:
match val:
    0: print("it's a zero")
    4: print("it's a four")
    [_]: prints("it's an array containing",_)
    _: prints("it's a ",_)

Again, I don't know if Karroffel's implementation has that (not all match implementations do), but regardless; that's a useful convenience and could potentially be added later. It's the reason why underscore was chosen rather than a reserved keyword or an non-valid variable name character.
Lastly; Usage and compatibility with common syntax trumps this minor convenience. For that one coder with his/her own special style that likes to use _, we'd:

annoy every single coder that knows pattern matching (because they'd have to remember that Godot is a special case)
would train every single coder that doesn't know pattern matching to bad habits (because they'd have to unlearn this)

@Xananax thanks for taking the time to write that, those are the key factors why I think _ is the best choice.
Currently I just ignore the value but it would only be a small addition to make _ a useable variable. If that's requested I'll add that.
😄 for yes, please make _ a usable variable
🎉 for no, don't make it a usable variable.
(Yes, both are positive emojis, why always be negative? 😉 )

"Add the minimum needed to work. Only add more stuff if many people request it"

me quoting vnen quoting reduz

Seems like I'm going to have to step in on this one. I don't really expect my suggestion to find any traction, but still, there are some things which need to be mentioned.
@karroffel
Let me share some python usability on this topic:
match foo:
    [_, _]: print("what ever")

could just as easily be replaced with
match foo:
    [*, *]: print("what ever")

problem with that would be that it's harder to type, at least in my US keyboard, but, there are numerous other symbols that could be sacrificed for a throw away variable.
match foo:
    [*, *]: print("what ever")

regarding using _ as a value returned for a wildcard. I believe you've already implemented this.
match bar:
    var n: print("Unknown array structure: " + str(n))

could just as easily be:
match bar:
    var _: print("Unknown array structure: " + str(_))

Only problem is, it doesn't look as nice. But it still helps with readability since you are keeping the rules across all valid variable names.

@Xananax
I think you kind of proved my point. the underscore library for javascript uses the _ because it is so rarely being used for anything else. But it's being used now, isn't it?
I don't think bringing up other languages is the way to go with this conversation.

Regarding the underscore's usefulness as a variable that resolves to whatever was passed.
for this pattern [1, _, _, 2]:print(_) which one would be printed? Not that clear is it. Try this instead [1, *, var _, 2]: print(_) and we all know which one will be printed, don't we.

My problem is not with the underscore being used, my problem is using a valid variable name. So either change the valid variables or change the implementation.
You tell a newbie, "A variable is a name for a value, it can use any letter, number, or the underscore character, and it has to start with either a letter or an underscore. You can use this anywhere, except for here, here, and here."
Regards, to all who took the time to listen.

What was the original motivating use case to add this to GDScript? I haven't used array pattern matching in Godot, and am having trouble coming up with a generic common use case where you would use this within Godot, for more than sugar syntax.
It is also awkward that we can't use this style of array pattern matching within conditionals. For example, to do
if my_array == [_,2,_,..]:
    pass

Finally, not having a richer pattern language makes this feel like incomplete feature. At a minimum, I should be able to match [0,1,2,3,3,2,1,0] with something like [*,2,_,*,2,..]. Why I would want to do this I don't know, like previously said, I not sure what is the use case for such power pattern matching in GDScript.
Or perhaps if array pattern matching exists, then we should also be able to Array.get_matches(pattern) -> Array[Array], so that [1,2,1,2,2,2].get_matches([_, 2]) would return [[1,2],[1,2],[2,2],[2,2]]. Again, don't know why would use this within GDScript.

Why I would want to do this I don't know

Well if whoever actually has a valid need for this finds their way here, they are welcome to open a proposal about it 🙂

@menip well the discussion here should explain it. In sum it was add instead of a switch statement since it's more modern and powerful. Also, this issue is specifically about the match statement, not general pattern matching in any expression.
I also don't understand what your issue is. You mention that those don't work but also don't know why they would be useful. So do you want those or not?

Finally, not having a richer pattern language makes this feel like incomplete feature. At a minimum, I should be able to match [0,1,2,3,3,2,1,0] with something like [*,2,_,*,2,..]. Why I would want to do this I don't know, like previously said, I not sure what is the use case for such power pattern matching in GDScript.

Not sure what the * means in this case (the _ is already the wildcard), but you can match that, only that you have to use the match statement for that (which is the proposal in this issue and what was implemented in the end).
So yeah, if want to know the motivation for the feature see the discussion, if you're asking for something else then open a proposal.

@vnen I like the match statement and use it, but I'm confused as to the motivating use case for array pattern matching inside GDScript. I didn't see a good reason (beyond sugar syntax) for array matching when reading through the discussion here, which is what prompted my question.
As for the star, it isn't a wildcard, we have _, but it is like "any number of items". So in my example, my understanding is that I can't easily match both  [0,1,2,3,3,2,1,0] and [-1,0,1,2,3,2,1,0], I would need two patterns: [_,_,2,_,_,2,..] for the first, and [_,_,_,2,_,2,..] for the second. With star, both would get matched by [*,2,_,*,2,..].

The difference to a switch statement is that those cases can be nested. You can match on the contents of an array for example.

The OP just states that array matching is part of proposal, doesn't say why. Later in discussion, I didn't find a good reason for pattern matching arrays, beyond: well, haskell and other languages do it.

@menip ah, I see, I misunderstood your concern. I would say that not adding arrays and dictionaries would at least feel incomplete (especially considering that other languages with pattern matching have similar features). For instance, considering that GDScript don't have tuples, it's not uncommon to have a function returning an array when you need to return multiple values. In this case, matching the structure of the array for a specific element makes a lot of sense.
For your specific example, maybe we can expand to other wildcards, but usually we try to match an actual structure. I believe what want (if you want that case) is not really what match is meant for. In this case opening a new proposal would make sense.


Wrong message display.

Hi Guys,
Thanks a lot for this nice library. I was testing this library, and I faced this issue that when there is no internet connection, it is showing message that "You've turned on the airplane mode" and "Please turn off" even when airplane mode is turned off and internet connection is off.
Steps to reproduce this:

Start application, and then turn on Airplane mode
When Airplane dialog open, then turn off Airplane mode
Go back to application, and then turn off WIFI while remaining on same activity
Now when dialog appears, it'll show the same old i.e. "You've turned on the airplane mode" and "Please turn off"

I think you people are not refreshing the old message

I came across the same issue when testing the library. Please provide a fix for this.


ARROW-11092: [CI] (Temporarily) move offending workflows to separate files

Without warning, INFRA broke several of our GitHub Actions workflows, and have been unresponsive all week. See https://issues.apache.org/jira/browse/INFRA-21239. Since then, the Rust developers have removed their offending actions, so those are no longer blocked. This PR does harm reduction for C++ and R workflows, moving the workflows that INFRA doesn't like to their own files (temporarily, I hope, while this business gets sorted out). This enables the other workflows in each file to run, so we at least get some C++ and R tests running, and we can still verify on our personal forks the workflows that have been blocked on apache/arrow.

fyi @kou @kszucs @wesm @pitrou


Add PriorityAdjustCountFilterV2

增加优先级数量调整 V2 版本，对于在多个召回重复出现的 Item，尽量使其能够保留下来

 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.鲁建强 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


In version 2.0 console commands do not work

In version 2.0 console commands do not work -f and -nn. In version 1.9 everything works

@KASaLEX-2020
UE4localizationsTool.zip

It all works now. THANK YOU.


Temporarily not block testing on failed build stages

Issue automation#98

To get this in before the nightly, I'm going to go ahead and merge this.


Could someone show a piece of samples about "all_comments.txt " file ,I Can't reach the YouTube

I want to know the format of  all_comments.txt file ,but I can't reach Youtube case the networks .

It is a CSV format that uses '~' as the delimiter.  Each row has 3 values:

YT's video id
Title of Video
Comment

You need to create a developer account and project to access the YouTube API.  This should help you get started: https://developers.google.com/youtube/v3/
Once you have your API key, you'll have to add it to Scrape.py at the top of the file.

Thanks


Updates with ftcRobotController v8.0

Before issuing a pull request, please see the contributing page.

Merged by using the command line.


Keyboard does not change size when rotated to landscape

This is true both when rotating to landscape and presenting the keyboard in landscape.

I have added this to the 4.4 milestone, but may release it as a hot fix if 4.4 takes time.

This is done and can be tested in master.


[CSS] hr left border on Firefox

On Firefox, dividers are displayed with a black dot on the left, coming from the left border. Removing the left border fixed this bug for me. You could also use a 1px height on dividers with a background-color but without any border…
Edit: the right border also cause problems in some cases (on dark bg for me); it should be removed too if you continue to use borders.

Not just FF; there's a dot there in Chrome too. And there's a dot on the right (tho it's a lighter, less noticeable color). You can see them both clearly if you change the height of the <hr> to 10px. need the following added to the hr{} rule:
border-right: 0;
border-left: 0;

Fixed in #7153.


Re-import via recovery phrase: StrongholdError: the mnemonic was already stored

Briefly describe the issue.
I successfully migrated, send some transactions and then I deleted my profile from firefly. When I added my new seed again via recovery phrase (without closing the app), an error occurs at the last step when setting up the pin. The user cannot go further. Please take a look at the pictures. (btw: Adding via backup-file works fine)
Which version of wallet are you using?
firefly version 1.1.0
System specification
Win 10

Workaround
Simply close and open the app again, then everything is working fine

Hey @dnalneh, whenever this error occurred were you using the same profile name as the one you deleted beforehand? I am trying to replicate the issue but am not able to. From what I've tried however, using the same name results in an AccountAliasAlreadyExists error initially occurring then the mnemonic was already stored one afterwards - does this happen for you as well?

Fixed in https://github.com/iotaledger/firefly/pull/1209


Support setting headers like Allow, Supported

more related on this PR #140
We could potentially have this headers or behavior part of client or server.
Ex server could detect what methods are supported and if caller wants those values could be passed on response.
Avoiding implicit behavior is desirable.

The idea would be to maintain compatibility of what the endpoint offers via header between peers, but it would be the server's responsibility to define whether the methods are supported or not, if not supported it would remove it from the response or even from the forwarding.

hey @SilvaMendes I suggest exploring this more from server API then. As in some cases I used this API to build that headers.
Checkout RegisteredMethods .
Unfortunately I think we would need better middleware implementation for supporting this.
For now I think it is on Caller user to build custom reply wrapper that inject this headers.


Restrictions on the input mesh

Can you please tell me what are the requirements of the input mesh? like it should be watertight, manifold, triangular, etc.

The input should be a manifold triangle mesh, doesn't need to be watertight.

Thank you! I tried it on non triangular manifold mesh and it is still working!

I am surprised that it is working. However, I hope to remind you that the code is writing under the assumption of manifold triangle meshes. Thus even if it is “working” (didn’t output any error), I would still be cautious, you may be encountering a runtime error.
-Derek

On Sep 19, 2023, at 12:48 AM, Prathamesh Dinkar @.***> wrote:
Thank you! I tried it on non triangular manifold mesh and it is still working!
—
Reply to this email directly, view it on GitHub https://github.com/HTDerekLiu/intrinsic-simplification/issues/5#issuecomment-1724997664, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVU26LCRCHE4GCDZ4I2EVTX3FE47ANCNFSM6AAAAAA4XTTV6Q.
You are receiving this because you modified the open/close state.


Allow ingestion of partitioned Sparkey files

This can be done extremely quickly, since there's no need for us to process these files.
This doesn't remove sequencefiles, they're still perfectly legal.
Also add some internal docs about the input data formats we allow.
r? @jerry-stripe

We do need to do some sort of testing that the data we output remains exactly the same, vs the un-repartitioned sequencefile pipeline. Before moving this into production, I'll find a way to do that.

Overall the code looks good,  I would like to see the docs updated before we merge this.  I think we should be super clear why it is a good idea to have hadoop generate the sparkey files ahead of time.
I also think an example scalding job would be probably pretty useful, but not a deal breaker for this feature.

Ok, added a ton of docs. And also a sample Hadoop job!

:shipit:

Pushed docs to sequins.io


[WIP] Enable sort for single-level nesting struct columns on GPU

This PR contributes to #1605. It depends on https://github.com/rapidsai/cudf/pull/7422

adds single-level struct type

Signed-off-by: Gera Shegalov<EMAIL_ADDRESS>

Status:
TEST_PARALLEL=1 SPARK_HOME=~/spark-3.1.1-bin-hadoop3.2 integration_tests/run_pyspark_from_build.sh \
  -k "test_single_orderby and struct"

we observe the failure:
ai.rapids.cudf.CudfException: cuDF failure at: /home/gshegalov/gits/cudf/cpp/src/sort/sort_column.cu:112: Column type must be relationally comparable
	at ai.rapids.cudf.Table.orderBy(Native Method)
	at ai.rapids.cudf.Table.orderBy(Table.java:1441)
	at com.nvidia.spark.rapids.GpuSorter.$anonfun$sort$2(SortUtils.scala:183)

build

$ TEST_PARALLEL=1 COVERAGE_SUBMIT_FLAGS=$JDBSTR SPARK_HOME=~/spark-3.1.1-bin-hadoop3.2 integration_tests/run_pyspark_from_build.sh -k "test_single_struct and orderby"

=========================== short test summary info ============================
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS FIRST'>0-Struct(['child0', Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])])]
  second-level structs are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS FIRST'>0-Array(String)]
  arrays are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS FIRST'>0-Map(String(not_null),Map(String(not_null),String))]
  maps are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS FIRST'>1-Struct(['child0', Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])])]
  second-level structs are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS FIRST'>1-Array(String)]
  arrays are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS FIRST'>1-Map(String(not_null),Map(String(not_null),String))]
  maps are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS LAST'>-Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS LAST'>-Struct(['child0', Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])])]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS LAST'>-Array(String)]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a ASC NULLS LAST'>-Map(String(not_null),Map(String(not_null),String))]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS LAST'>0-Struct(['child0', Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])])]
  second-level structs are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS LAST'>0-Array(String)]
  arrays are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS LAST'>0-Map(String(not_null),Map(String(not_null),String))]
  maps are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS FIRST'>-Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS FIRST'>-Struct(['child0', Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])])]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS FIRST'>-Array(String)]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS FIRST'>-Map(String(not_null),Map(String(not_null),String))]
  opposite null order not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS LAST'>1-Struct(['child0', Struct(['child0', Byte],['child1', Short],['child2', Integer],['child3', Long],['child4', Float],['child5', Double],['child6', String],['child7', Boolean],['child8', Date],['child9', Timestamp],['child10', Null])])]
  second-level structs are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS LAST'>1-Array(String)]
  arrays are not supported
XFAIL ../../src/main/python/sort_test.py::test_single_nested_order_orderby[Column<'a DESC NULLS LAST'>1-Map(String(not_null),Map(String(not_null),String))]
  maps are not supported
=============== 4 passed, 4848 deselected, 20 xfailed in 43.43s ================

Breaking tests can be traced to the fact that null in nested integer columns seems to be interpreted as zero in https://github.com/rapidsai/cudf/pull/7422
The minimum repro:
scala> val schema = new StructType().add("nestedInt", new StructType().add("value", IntegerType)  )
schema: org.apache.spark.sql.types.StructType = StructType(StructField(nestedInt,StructType(StructField(value,IntegerType,true)),true))

scala> val df = spark.createDataFrame(sc.parallelize(Seq( Row(Row(1)), Row(Row(null)), Row(Row(-1))  )), schema)
df: org.apache.spark.sql.DataFrame = [nestedInt: struct<value: int>]

scala> df.sort("nestedInt").select("nestedInt.value").show
21/03/15 04:49:38 WARN GpuOverrides:
*Exec <TakeOrderedAndProjectExec> will run on GPU
  *Expression <SortOrder> nestedInt#18 ASC NULLS FIRST will run on GPU
  *Expression <Alias> cast(nestedInt#18.value as string) AS value#23 will run on GPU
    *Expression <Cast> cast(nestedInt#18.value as string) will run on GPU
      *Expression <GetStructField> nestedInt#18.value will run on GPU
  !NOT_FOUND <RDDScanExec> cannot run on GPU because no GPU enabled version of operator class org.apache.spark.sql.execution.RDDScanExec could be found
    @Expression <AttributeReference> nestedInt#18 could run on GPU

+-----+
|value|
+-----+
|   -1|
| null|
|    1|
+-----+

build

Also the single partition work around makes no since to me at all. Until that is also fixed I see no way for us to merge this in.

I understand the concern about GPU Sort.
As for the single partition workaround, It's just incremental delivery which mimics the progress we have on the cuDF side. It would make sense to me  as long as it works as documented.

build

@jlowe these existing tests cover the scenarios you are calling out. they are passing now locally

build

these existing tests cover the scenarios you are calling out. they are passing now locally

Great, thanks @gerashegalov!


feat: Update note around release tagging.

Make it clear that the release option won't do anything unless the
repository is in the openedx organization in github.
Relates to https://github.com/openedx/build-test-release-wg/issues/203

https://github.com/openedx/edx-repo-health/issues/338


feat: add basic LocalHdWallet functionality

In this pull request, I've introduced the fundamental functionality for a LocalHdWallet. I've included a straightforward test script within the prefabs scene to demonstrate error and success states. In the future, LocalHdWallet could also support multiple accounts per mnemonic and set additional seed passwords to secure the wallet even more.
To make Nethereum's HdWallet work, I had to update the Nethereum package to the latest version. Also, there's a lot of junk left from copying the latest Nethereum package, we can remove it if necessary.

Hello @dreamqip first of all thanks for the PR! Added a few minor preliminary comments. If possible, could you also:

Add it to Prefab_ConnectWallet prefab (inspector) so we can test the Scene_Prefabs functionality with LocalHdWallet
Do not add additional Nethereum DLLs if possible, but feel free to update the existing ones, assuming this is 4.16?

For edge cases related to LocalWallet like going through the TransactionManager, I can handle that at the end and make sure everything works.
Thanks again!

Hey @dreamqip - will be closing this for now and revisiting; it will be part of our upcoming EmbeddedWallet modular product, where LocalWallet will move into that option and you'll have a clear separation of auth methods and separation methods. So in this case, you'd be able to choose the strategy you want to encrypt your local wallet with. Apologies for not getting on this sooner, but longer term vision here will surely encapsulate this!

Great news! Sorry, that I couldn't finish the PR


Use docopt for a better CLI

We can leverage docopt to make generator and mazerunner usage more intuitive and easy to use. For example:
$ python mazerunner/generator.py -o <filename> -w <width> -h <height>

and
$ python mazerunner/mazerunner.py -m <filename>

would be nice to see.

#12 should solve this issue.


Produce the *_gnu import libraries more deterministically

This addresses item 3 in #1964.

This addresses item 3 in #1964.

Thanks for the fix! Sorry to be a stickler, but could you open a new issue for this PR? It's not clear to me what "item 3" refers to.
@riverar is this related to the consistent application of full file names in the win32 metadata that you've been working on?

This PR stabilizes dlltool temporary file output (which, by default, uses the process ID in its naming scheme) for reproducible build purposes. Isn't related to our suffix issue.


Add support for Presets attributes and commands to the Thermostat cluster

Clean up the Thermostat cluster and remove the TemperatureSetpointHoldPolicy attribute and SetTemperatureSetpointHoldPolicy command
Fixes: #34531
Added the skip-protocol-compatibility flag in the PR because of the following updates.
The 1.4 spec has updated PresetScenarioEnum with a new value added. Hence vacation has changed its value.
Also sdk had SetTemperatureSetpointHoldPolicyRequest command, TemperatureSetpointHoldPolicyBitmap and temperatureSetpointHoldPolicy attribute that has been removed from the spec. Hence setpointHoldExpiryTimestamp changed its code.
Following are the changes flagged by the compatibility checker -
2024-07-26 07:53:09 ERROR   Enumeration Thermostat::PresetScenarioEnum changed code for entry kUserDefined from 6 to 7
2024-07-26 07:53:09 ERROR   Struct Thermostat::SetTemperatureSetpointHoldPolicyRequest has been deleted.
2024-07-26 07:53:09 ERROR   Bitmap Thermostat::TemperatureSetpointHoldPolicyBitmap was deleted
2024-07-26 07:53:09 ERROR   Command Thermostat::SetTemperatureSetpointHoldPolicy was removed
2024-07-26 07:53:09 ERROR   Attribute Thermostat::temperatureSetpointHoldPolicy has been deleted.
2024-07-26 07:53:09 ERROR   Attribute Thermostat::setpointHoldExpiryTimestamp changed its code.

Should Thermostat cluster revision be updated to 7?


Updates to reflect changes we made in the node repo

We moved some samples around and renamed some of the pnp files. This will fix the issues.

@dominicbetts this needs to get merged ASAP. The docs have 404 links to the repo pages.

#sign-off

@danhellem: I'm sorry - only the author of this article, @dominicbetts, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

#sign-off


[Site] Fix mobile menu

Improve mobile navigation & fix bugs

Foo
Foo
Bar
Bar

Would you any change ? i'm open to everything... everything.... except launching "Icons" without a working mobile menu 😅

@WebMamba  ? @kbond  ?

needs a rebase.

@kbond good

Thanks Simon.


Fix Dialog overflow UI issues

For desktop only: the dialog does not have a max-height, so it grows until it reaches the vertical boundaries of the screen and then overflows.
Example

Proposed solution: Add max-height to DialogContent. The scrollbar will look "off" due to the rounded corners.
The scrollbar could be fixed by directly styling it to match the rounded corners, but not all browsers allows changes to the scrollbar styles.
::-webkit-scrollbar {
    width
}
::-webkit-scrollbar-track {
    border-radius
}
::-webkit-scrollbar-thumb {
    border-radius
}

Example: lg:max-h-[75vh]

does this still occur @eduardopicolo-cb? I think you have solved it already, haven't you?


WIP: Fix group theme override

Ref

https://nanopay.atlassian.net/browse/NP-4634

Changes

Fix group default menu override
Support copyFrom on nested FObject (as JS already supports nested copyFrom)

@lchanmann we do not want to change the behaviour of copyFrom.
I've been working 'overlay' (nested copyFrom), similar to what you are after, but have never had time to finish it.  It suffers from infinite recursion when it encounters nested FObjects.
see: https://github.com/kgrgreer/foam3/pull/521

So overlay should call merge for Map and Array types?
Trying to work through how the following may work together or the clear use of each.

copyFrom
merge
overlay

@jlhughes @kgrgreer please re-review when you have a chance, thanks.

Do you need to do this by adding new methods to PropertyInfo. Could you just have type-overloaded support methods in your own code?