Binary field arithmetic

A user must be able to operate in $F_{2^m}$ fields using ycurve

Closed by 1f29bc823cdbb544bed06250dd52cbd1f626368c


Bowyer's lock button attack able to damage characters?

Seen by Alanim on flaafykins's stream.  Bowyer's lock button attack was able to damage a character and killed Geno.  Need to check if this attack is a "spell" in game data that's having properties shuffled.

Seed<PHONE_NUMBER>: http://randomizer.smrpgspeedruns.com/h/Qhjjl2Apxg
Apparently this seed also has the Bowyer button lock attack.

This is a spell attack, and if it's attack power is being shuffled then this is probably the issue.

Attacks 102, 103, 104 are the button lock attacks.  These need to be excluded from the shuffle.

Added these attacks to the disallowed list so they're not shuffled.  This should be fixed now.


[imgui] build with #define IMGUI_API __declspec( dllimport )

Is your feature request related to a problem? Please describe.
I would like to build imgui into a dll and then allow the functions to be accessed from another dll (along with my own functions). Uncommenting this line in imconfig.h before build and then recommenting it after installation allows me to acheive the desired behavior because the resulting .lib file will have the required exported symbols
Proposed solution
I have implemented this as a feature named dllexport in my fork here
Describe alternatives you've considered
Compiling imgui as a shared library with CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS set to ON, would also solve this problem, but after messing around with this, it appeared to breakd several downstream packages
Additional context
I have only recently become familiar with how the Windows linker works, and I may be missing a simpler solution.
If this is acceptable, I would also be interested in implementing something similar for implot

@robbiefish, Thanks for posting this issue, Could you please submit a PR to solve this issue?


resolved the event drop issue for stream synchronize.

In this PR, I solved the drop event issue regarding the StreamSynchronize activities. The main issue was that we did not extract the Device ID for these kind of events and it causes them to be dropped due to invalid Device ID condition.

This PR will not be merged as it has some commits with wrong email address in the commits (might be problematic when we push into the upstream where CLA is required). I will resubmit this PR.


Pushgateway Error code 200

Description
I have an error using prometheus push gateway, i configured the variable with endpoint and keycloak push successfully metrics to pushgateway, but in keycloak log i have an error
Expected Behavior
log 200 ok for push to prometheus pushgatway
Actual Behavior
`
2020-06-22T08:19:33.374 [] [] [Thread-401] ERROR -- o.j.a.k.m.PrometheusExporter             : Unable to send to prometheus PushGateway: java.io.IOException: Response code from http://pushgateway.********.svc:9091/metrics/job/keycloak/instance/<IP_ADDRESS>  was 200
| at io.prometheus.client.exporter.PushGateway.doRequest(PushGateway.java:297)
  | at io.prometheus.client.exporter.PushGateway.pushAdd(PushGateway.java:171)
  | at org.jboss.aerogear.keycloak.metrics.PrometheusExporter.push(PrometheusExporter.java:289)
  | at org.jboss.aerogear.keycloak.metrics.PrometheusExporter.lambda$pushAsync$0(PrometheusExporter.java:281)
  | at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
  | at java.base/java.lang.Thread.run(Thread.java:834)
`
Environment

Operating system: rhel7
OpenShift versions: 3.11
Project Versions: 2.0.1

Steps to reproduce
Deploy keycloak on openshift and use the library

@Alexxanddr strange, a valid response code was declined. I'll try to investigate, but do you need to use the PushGateway in your case? If you are using the Prometheus Operator you could use something like a PodMonitor to monitor multiple Keycloak Instances. And if you only have one Keycloak instance there shouldn't be any need to use the PushGateway, scraping will work fine.

@pb82 i have deployed prometheus with deployment config, not with operator,  and at this moment i have 2 instances of keycloak in dev environment, but in production environment i want to add more pod. I need push gateway because i have a prometheus for entire cluster, and this scrape all pod, and now the scraping directly on keycloak not show the instance value.

@pb82 i have changed the version of prometheus simpleclient  library with the latest, with argument at build:
-PprometheusVersion="0.9.0"
and it works successfully! i think the problem it was the 0.3.0 version of prometheus library

Great, glad that it worked. Hmm yeah the defautl is quite old we should probably upgrade that.

Is there any plan on when to upgrade the prometheus version?


When an intersection is going to produce an expression too complex error...

eagerly perform reductions in a last-ditch effort to avoid the error. I've wanted to do something like this since #29949 was opened, and since we added getReducedType and associated machinery, alongside machinery for bailing when expressions are producing unions/intersections are too complex. I feel like we now have a scenario where it's justifiable to invoke the reduction machinery earlier than we normally do in order to try to save us from resorting to an "Expression produces a union type that is too complex to represent" error, since that error is ultimately heuristic and, in fact, the union produced is not too complex if significant reductions take place.
#29949 has had acceptable perf for awhile, it just also had a complexity error in it, so could already be considered "fixed". This really fixes #29949, IMO, by finally removing that "expression too complex" error once react's types are adjusted to make the two ref object types mutually exclusive by adding a current?: undefined property to the RefCallback type and the callback in ForwardedRef.
This shouldn't impact perf generally, since this fallback heuristic only takes effect when we would already issue an error.

@typescript-bot perf test this
@typescript-bot run dt
@typescript-bot test this
@typescript-bot user test this
@typescript-bot pack this

Unfortunately, we never finished reviewing this PR. It is pretty old now, so I'm going to close it to reduce the number of open PRs.


Change the README so that it's less intimidating for newcomers

As noted in #23, the current project README is too long, being a copy-paste of the Veracruz FAQ that was submitted as supporting material to the CCC technical committee to explain the project.  The majority of this material has now been moved into the Veracruz project wiki, where appropriate, making room for a new README that's less intimidating, and gets to the point quicker.
There's probably lots of scope for bikeshedding over what should be contained within the README, so feel free to suggest changes/additions/etc.

LGTM

1+1+1 = +1 reached.  merging.


Upgrade storybook to 6.1

Storybook 6.1 is out. Mostly performance related improvements but also includes a slight UI refresh.

https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md

Interesting, the clean/build step seems to fail


When Resizer allocates Image/AcquisitionData triggers a warning

at this line the Resizer triggers a deprecation warning.

In practice at this line it should be enough to add the parameter suppress_warning=True


[LIVY-582][Tests] Hostname in python-api test should be lower case to avoid test failures

What changes were proposed in this pull request?
In the python-API test code, when returning a mocked response, the mock lib will compare the URL with the predefined URLs case sensitive. However, the Request lib used in the Livy python API will change the URL to lower case. This will cause test failures on a machine with an upper case hostname.
This patch turns the hostname in python-API test code into the lower case to avoid such test failures.
How was this patch tested?
Existing test. Run test specifically on a machine with an upper case hostname.

Codecov Report

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

@@             Coverage Diff              @@
##             master     #180      +/-   ##
============================================
+ Coverage     68.63%   68.67%   +0.03%
+ Complexity      905      902       -3
============================================
  Files           100      100
  Lines          5666     5666
  Branches        850      850
============================================
+ Hits           3889     3891       +2
+ Misses         1224     1218       -6
- Partials        553      557       +4

Impacted Files
Coverage Δ
Complexity Δ

...cala/org/apache/livy/scalaapi/ScalaJobHandle.scala
52.94% <0%> (-2.95%)
7% <0%> (ø)

...ain/java/org/apache/livy/rsc/driver/RSCDriver.java
76.69% <0%> (-2.12%)
39% <0%> (-3%)

...main/scala/org/apache/livy/server/LivyServer.scala
35.46% <0%> (-0.5%)
11% <0%> (ø)

...ain/scala/org/apache/livy/utils/SparkYarnApp.scala
79.57% <0%> (+6.33%)
33% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Merging to master branch, thanks for the fix!


Long-Distance Test

We should check that openDuT works across a distance (e.g. 50+ km).
Tasks:

[ ] Basic ICMP ping
[ ] UDS discovery should detect ECU across openDuT

PC (ICMP ping) --> ETH1 (ETH2USB) --> OLU -->  ETH2 tunnel --> OLU2 --> ETH1 (USB2ETH) --> PC2 (respond to ping)
alternative:
PC (CAN send) --> USB2CAN --> OLU --> ETH tunnel --> OLU2 --> CAN2USB --> PC2 (CAN dump)


Fix default UI node size

Fixes #291
This changes the default node size (width and height) to Auto instead of Undefined to match the Stretch implementation.
See comment https://github.com/bevyengine/bevy/issues/291#issuecomment-678807641, I think the solution in this comment would be better, but currently doesn't work with how the crates are structured.

Thanks! This looks good to go!


Add support for pyarrow 6

Addresses #324

@xhochy Is there a way for me to run these checks again without committing some unnecessary change? I see that pyarrow 6 is on conda-forge now so I think my original pull request should be successful.

Closing/opening a PR retriggers the tests ;)

Seems like we have an actual error:
              +build | /src/cpp/turbodbc_arrow/Library/src/set_arrow_parameters.cpp: In function 'std::shared_ptr<arrow::Table> turbodbc_arrow::unwrap_pyarrow_table(const pybind11::object&)':
              +build | /src/cpp/turbodbc_arrow/Library/src/set_arrow_parameters.cpp:427:64: error: too many arguments to function 'arrow::Result<std::shared_ptr<arrow::Table> > arrow::py::unwrap_table(PyObject*)'
              +build |   427 |     if (not arrow::py::unwrap_table(pyarrow_table.ptr(), &table).ok()) {
              +build |       |

That might very well be related to #317  .

Closing/opening a PR retriggers the tests ;)

Ah nice thanks, I'll keep that in mind for next time.
Regarding the error, I do not know C++ at all. The message above seemed to be about the second argument to this function: arrow::py::unwrap_table(pyarrow_table.ptr(), &table), which is what @jorisvandenbossche mentioned in #317.
In the code from pyarrow.cc, it looks like unwrap_##FUNC_SUFFIX(PyObject* obj) only accepts the object argument which in the turbodbc code seems to be pyarrow_table.ptr(). I thought perhaps std::shared_ptr<TYPE_NAME>* out (which has been removed) is the &table argument. So perhaps simply removing that would work.
I tried to remove &table locally from that function so it only has one argument ran the earthly test-python3.9-arrow6.x.x test.
First three tests passed quickly:
+test | 1/4 Test #1: cpp_odbc_unit_test ...............   Passed    0.05 sec
+test | 2/4 Test #2: turbodbc_unit_test ...............   Passed    0.11 sec
+test | 3/4 Test #3: turbodbc_arrow_unit_test .........   Passed    0.03 sec

Final test took a bit longer to complete, but ultimately failed. Segmentation fault during the test_executemanycolumns test. Not sure if it is caused by the change I made.

+test |     Start 4: turbodbc_integration_test
+test *failed* | 4: ============================= test session starts ==============================
+test *failed* | 4: platform linux -- Python 3.9.7, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
+test *failed* | 4: rootdir: /src
+test *failed* | 4: plugins: cov-3.0.0
+test *failed* | 4: collected 420 items
+test *failed* | 4:
+test *failed* | 4: test_connect.py ........
+test *failed* | 4: test_connection.py ............
+test *failed* | 4: test_constructors.py ...
+test *failed* | 4: test_cursor_async_io.py .
+test *failed* | 4: test_cursor_basics.py ............FF
+test *failed* | 4: test_cursor_insert.py ..FF.FF.FF.FF.FF.FF.FF.FF..FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF
+test *failed* | 4: test_cursor_select.py .FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.FF.F..
+test *failed* | 4: test_cursor_unsupported_features.py ..
+test *failed* | 4: test_data_types.py ..
+test *failed* | 4: test_executemanycolumns.py sFatal Python error: Segmentation fault
+test *failed* | 4:
+test *failed* | 4: Current thread 0x00007ff6a8fba740 (most recent call first):
+test *failed* | 4:   File "/src/build/turbodbc/cursor.py", line 201 in executemanycolumns
+test *failed* | 4:   File "/src/build/turbodbc/exceptions.py", line 41 in wrapper
+test *failed* | 4:   File "/src/python/turbodbc_test/test_executemanycolumns.py", line 45 in _test_basic_column
+test *failed* | 4:   File "/src/python/turbodbc_test/test_executemanycolumns.py", line 122 in _full_column_tests
+test *failed* | 4:   File "/src/python/turbodbc_test/test_executemanycolumns.py", line 146 in test_integer_column

Changing the code linked by @pacman82 and @jorisvandenbossche seems to help, however someone check it, since I didn't write C++ in the past 10 years and I literally have no idea how this works. #fixedaccidentally
https://github.com/blue-yonder/turbodbc/pull/326


Update set-up-compliance-boundaries.md

updated New-ComplianceSecurityFilter with action parameter

@JohanFreelancer9 Please copy review

Issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/6803

@markjjo Please merge this PR. Thanks

Closing. Action parameter not required. All actions added by default, which is why examples don't include this parameter.


Assert.NotEmpty should be used for non-nil types

Several tests within secretless-broker assert NotNil on
strings and other structures that cannot be nil. We need to correct
these tests, otherwise the assertions are useless.

[ ] Assert.NotEmpty is used in place of Assert.NotNil when asserting on strings and other non-nil types

In reviewing usages of assert.NotNil in the current master branch, I've determined there are no existing misuses remaining, this issue will be closed for now.


Add SacreBLEUScore

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure to update the docs?
[x] Did you write any new necessary tests?

What does this PR do?
Fixes #487
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

TODOs:

[ ] Fix mypy issues: Sequence not compatible with list comprehension
[ ] Polish copyrights for functional/text/sacrebleu.py

Hi @SkafteNicki, I've been a bit struggling to enforce the Sequence[str] input is considered as the List[str] before passing it into the list comprehension. Do you have, please, any idea how to ensure mypy is working here? :)

Hi @stancld, I have fixed it now :]


Issue 60

Uses react-accessible-dropdown-menu-hook to support desired keyboard navigation for dropdown menus. Because this is a React Hook, it was necessary to convert the class-based Dropdown Component to a function-based one.
Fixes #60

Yes!


Default to merge_system_user_message if mistral model detected

Resolves: https://github.com/instructlab/eval/issues/97
Requires https://github.com/instructlab/eval/pull/98 to be able to function but won't cause any harm to merge before.

@JamesKunstle FYI


Allow description for basic programs

So, will it be possible?
PS: Seems that Adriweb didn't translate everything in Cesium (french version), can I help ?

PS: Seems that Adriweb didn't translate everything in Cesium (french version), can I help ?

It as complete at some point, but maybe new things aren't translated - feel free to open a PR modifying the strings here

Added in adb6704. More information can be found here.

Thank you very much Mateo !!! 😀


Non S3 URI as source resulting on local filesystem scanning

Description
An issue surfaced in Azcopy where users encountered a bug during copy operations with a source URI of "https://isd-storage.obs.ae-ad-1.g42cloud.com". This triggered a scan of the local file system, resulting in failures. Upon investigation, it was discovered that unsupported cloud platforms, such as g42cloud, were incorrectly identified as local sources by the backend.
As can be observed below-

This PR addresses this issue by categorizing all unsupported cloud platforms as Unknown instead of Local, thus preventing repetitive scans of local files and ensuring early failure in processing.
According to the new flow it would be as follows:

Implementation:

Implemented a check to categorize unsupported cloud platforms as Unknown.

Tests:

This pull request concentrates on refining internal processing methods, ensuring consistent output while refining task execution. Previously, job failures occurred during local file system scanning. With this modification, although the job would still fail, the processing approach has been revamped. This update secures cost savings by removing unnecessary steps. While tests aren't included, given their limited relevance to these particular adjustments, the changes prioritize efficiency and reliability without compromising functionality.

Needs tests, otherwise lgtm

Needs tests

Done


pm: Dynamically bind a device to a power domain

Add API to add devices to a power domain in runtime. The number of
devices that can be added is defined in build time.
The script gen_handles.py will check the number defined in
CONFIG_PM_DEVICE_POWER_DOMAIN_DYNAMIC to resize the handles vector,
adding empty slots in the supported sector to be used later.
v2:

Only resize power domains (instead of all devices when the option is enabled)
The changes in the linker script is in one separated file now
Add a hidden option to simplify the ifdef logic
Add an api to remove a device from a power domain (the counter part of the add function)

I'd really like to understand the use case for this, since all domain information should be available at build time. Zephyr doesn't support dynamic devices, so why should a feature like this be needed?

That is true, we can't instantiate device at runtime, but tthis is usefeul when one wants to re-use the same firmware in slightly different targets and just  bind a device to a power domain  during the system intialization.

I'd really like to understand the use case for this, since all domain information should be available at build time. Zephyr doesn't support dynamic devices, so why should a feature like this be needed?

That is true, we can't instantiate device at runtime, but tthis is usefeul when one wants to re-use the same firmware in slightly different targets and just bind a device to a power domain during the system intialization.

Isn't that the purpose of board revisions?

I'd really like to understand the use case for this, since all domain information should be available at build time. Zephyr doesn't support dynamic devices, so why should a feature like this be needed?

That is true, we can't instantiate device at runtime, but tthis is usefeul when one wants to re-use the same firmware in slightly different targets and just bind a device to a power domain during the system intialization.

Isn't that the purpose of board revisions?

No, the use case here is to use the same binary in different targets.

No, the use case here is to use the same binary in different targets.

Right, but my point is that if they are different targets, why are they not board revisions with the appropriate modifications in overlay files? Why are we doing this hackery, when the problem is already solvable with Zephyr's existing mechanism for different targets.

I'd really like to understand the use case for this, since all domain information should be available at build time. Zephyr doesn't support dynamic devices, so why should a feature like this be needed?

That is true, we can't instantiate device at runtime, but tthis is usefeul when one wants to re-use the same firmware in slightly different targets and just bind a device to a power domain during the system intialization.

Isn't that the purpose of board

No, the use case here is to use the same binary in different targets.

Right, but my point is that if they are different targets, why are they not board revisions with the appropriate modifications in overlay files? Why are we doing this hackery, when the problem is already solvable with Zephyr's existing mechanism for different targets.

This require to build two images, the use case we have involves one single image that can be  deployed in slightly different targets. Of course, it is possible to have two images and distribute them to the right target, but that is not the use case we have.

This require to build two images, the use case we have involves one single image that can be deployed in slightly different targets. Of course, it is possible to have two images and distribute them to the right target, but that is not the use case we have.

I understand that.
Is it worthwhile and desired to support this feature, when no other part of Zephyr works this way.
Why is it possible to do this with power domains, but not SPI or I2C pins? Would support for those be merged if someone asked?
Unless the answer to the above is yes, my feeling is that it would be very inconsistent to have this one corner of Zephyr work in this way, but nothing else. But these are larger questions better answered by dev-review or the TSC IMO.

Of course there is nothing stopping you from writing another version of power_domain_gpio which has a custom API for dynamically adding dependencies. I would have no problems with that.

This require to build two images, the use case we have involves one single image that can be deployed in slightly different targets. Of course, it is possible to have two images and distribute them to the right target, but that is not the use case we have.

I understand that.
Is it worthwhile and desired to support this feature, when no other part of Zephyr works this way? Why is it possible to do this with power domains, but not SPI or I2C pins? Would support for those be merged if someone asked?
Unless the answer to the above is yes, my feeling is that it would be very inconsistent to have this one corner of Zephyr work in this way, but nothing else. But these are larger questions better answered by dev-review or the TSC IMO.

If someone asked and had a use case and the implementation wouldn't  impact others use case, much likely yes ...
That is not a big feature nor something that has a toll in anything, if things like that needs to go to TSC or dev-meeting my understand is that everything has to pass trough meetings ....

That is not a big feature nor something that has a toll in anything, if things like that needs to go to TSC or dev-meeting my understand is that everything has to pass trough meetings ....

It's not a big feature, but it does go against the current model of "Hardware relationships are defined in devicetree".
Maybe that's not worthy of a trip to dev-review, maybe it is, it's not my call, I'm just a lowly collaborator :)

That is not a big feature nor something that has a toll in anything, if things like that needs to go to TSC or dev-meeting my understand is that everything has to pass trough meetings ....

It's not a big feature, but it does go against the current model of "Hardware relationships are defined in devicetree". Maybe that's not worthy of a trip to dev-review, maybe it is, it's not my call, I'm just a lowly collaborator :)

that is not the common for sure, but there is, at lest, one other case
https://docs.zephyrproject.org/latest/guides/pinctrl/index.html?highlight=one effects#dynamic-pin-control
Dynamic pin control refers to the capability of changing pin configuration at runtime. This feature can be useful in situations where the same firmware needs to run onto slightly different boards, each having a peripheral routed at a different set of pins.

The pinctrl dynamic option that was added because it can cover some edge cases, and it's super simple: it's just dropping const qualifier and a pointer swap, really. It doesn't for example require changing core scripts. Its usage, scope, and capabilities are clearly documented so that we avoid people abusing the functionality.

This is EXACTLY the same case.
The end goal here was NOT to introduce dynamic devices, it is about assigning devices to a power domain at runtime, based on events or hardware discovery that can only happen at runtime and It happens that we use devices for managing power domain.
We also want to for example manage device dependencies and extend what we get from device tree at runtime and feed this to power management for device power management. This is similar. DT device dependencies was always just the start and more resources will come in to be managed during the powerup and powerdown process.

We have the concept of board revisions to handle hardware variations. If that option doesn't solve the problem you're attempting to solve with this PR, we should first understand why.

That was explained above already. There are cases where differences between HW variants do not justify a new firmware image and the process associated with managing multiple FW images.

The pinctrl dynamic option that was added because it can cover some edge cases, and it's super simple: it's just dropping const qualifier and a pointer swap, really. It doesn't for example require changing core scripts. Its usage, scope, and capabilities are clearly documented so that we avoid people abusing the functionality.

This is EXACTLY the same case.

No, it's not EXACTLY the same. This PR is hacking into core scripts, pinctrl doesn't go that far.

The end goal here was NOT to introduce dynamic devices, it is about assigning devices to a power domain at runtime, based on events or hardware discovery that can only happen at runtime and It happens that we use devices for managing power domain.

Could we have concrete examples, as we did for pinctrl? There's even a sample that was presented to showcase it. This is not happening here. I think it would help to make progress here.

The pinctrl dynamic option that was added because it can cover some edge cases, and it's super simple: it's just dropping const qualifier and a pointer swap, really. It doesn't for example require changing core scripts. Its usage, scope, and capabilities are clearly documented so that we avoid people abusing the functionality.

This is EXACTLY the same case.

No, it's not EXACTLY the same. This PR is hacking into core scripts, pinctrl doesn't go that far.

That is the SAME use case, not the same implementation. And lets be honest:
One of the effects of enabling dynamic pin control is that pinctrl_dev_config will be stored in RAM
instead of ROM (not states or pin configurations, though). The user can then use pinctrl_update_states()
to update the states stored in pinctrl_dev_config with a new set. This effectively means that the device
driver will apply the pin configurations stored in the updated states when it applies a state.

So, it was not needed to go that far because the whole thing was stored in RAM to support the "SAME" use case. This implementation is this way to not have any impact for those who don't need it.

The end goal here was NOT to introduce dynamic devices, it is about assigning devices to a power domain at runtime, based on events or hardware discovery that can only happen at runtime and It happens that we use devices for managing power domain.

Exactly ... The only thing that is dynamic is binding existent devices to existent domains.

Could we have concrete examples, as we did for pinctrl? There's even a sample that was presented to showcase it. This is not happening here. I think it would help to make progress.

There is a test for this use case, it is not like we have real samples for all features that are provided. For example your pr https://github.com/zephyrproject-rtos/zephyr/pull/42040 introduced new API / feature and it was validated with tests and not samples in real product. That is understandable, there are people using it in products that can't be disclosed.

#42020 introduces a similar API to Linux PM QoS (simpler and part of policy manager because of Zephyr design), so it's not anything new in the end.

Confused how #42020 is relevant here.

Regarding dynamic pinctrl, it was added because a few people asked for it multiple times, so there was an interest in the community.

aha, and what part of this PR is not "interest in the community"?

Regarding the proposal in this PR, I think an example would help. Samples don't need to show any private or confidential information, just illustrate a case where it is clear that this feature is useful and that can't be achieved in any other way, not doing that because this is only in products that can't be disclosed doesn't sound really convincing.

You have two SKUs that share 99.9% of the HW but assume there are some differences in how certain devices are connected to power, so device A which is part of domain A in SKU 1 is part of domain B in SKU 2. You can discover what SKU you are running on and adjust things accordingly at runtime. This is not something anyone would want to spend time on writing a sample, such sample wont make any sense for Zephyr and I would personally reject it.
It should be enough to describe this in the documentation.

There is a test for this use case, it is not like we have real samples for all features that are provided. For example your pr #42040 introduced new API / feature and it was validated with tests and not samples in real product. That is understandable, there are people using it in products that can't be disclosed.

#42020 introduces a similar API to Linux PM QoS (simpler and part of policy manager because of Zephyr design), so it's not anything new in the end.

Really ? https://github.com/torvalds/linux/blob/master/include/linux/pm_domain.h#L243
This is supported by Linux API as well.

Regarding dynamic pinctrl, it was added because a few people asked for it multiple times, so there was an interest in the community. It's also there because it was easy to implement without too much hackery, and the scope of the change was in the subsystem itself (pinctrl.h). I personally had no much interest on it, because in the end Zephyr doesn't have a dynamic device model so one is fairly limited on things that can be done at runtime. Also, it doesn't solve all cases: it is only guaranteed to work on non-initialized devices (see we still have #11918 open).
Regarding the proposal in this PR, I think an example would help. Samples don't need to show any private or confidential information, just illustrate a case where it is clear that this feature is useful and that can't be achieved in any other way, not doing that because this is only in products that can't be disclosed doesn't sound really convincing. Tests just show that the API works, but other than that don't tell me how this is expected to be used or what is the usecase (for #42020 one could refer e.g. to these slides or kernel docs).

The use case is pretty simple,  the information about which power domain a device belongs is not know at build time, and a lookup has to be done at runtime figure it out and bind the device to a domain. Write a simple sample that does it would be that different from the test ? Much likely not, this would make the review different, certainly not !
Regarding #42020, it could refer but it didn't. Also point to Linux is not right approach, and one could ask the use case on Zephyr (not telling that there is not use case, just to be clear). And if points to Linux is enough to justify things, you are going to find information about generic power domain and capability to add/remove devices at runtime in the slides you have linked.

#42020 introduces a similar API to Linux PM QoS (simpler and part of policy manager because of Zephyr design), so it's not anything new in the end.

Confused how #42020 is relevant here.

Just to point out that the criteria used to reject this PR was not applied in that one.

Regarding dynamic pinctrl, it was added because a few people asked for it multiple times, so there was an interest in the community.

aha, and what part of this PR is not "interest in the community"?

Regarding the proposal in this PR, I think an example would help. Samples don't need to show any private or confidential information, just illustrate a case where it is clear that this feature is useful and that can't be achieved in any other way, not doing that because this is only in products that can't be disclosed doesn't sound really convincing.

You have two SKUs that share 99.9% of the HW but assume there are some differences in how certain devices are connected to power, so device A which is part of domain A in SKU 1 is part of domain B in SKU 2. You can discover what SKU you are running on and adjust things accordingly at runtime. This is not something anyone would want to spend time on writing a sample, such sample wont make any sense for Zephyr and I would personally reject it.
It should be enough to describe this in the documentation.

#42020 introduces a similar API to Linux PM QoS (simpler and part of policy manager because of Zephyr design), so it's not anything new in the end.

Confused how #42020 is relevant here.

Just to point out that the criteria used to reject this PR was not applied in that one.

oh, you mean https://github.com/zephyrproject-rtos/zephyr/pull/42040, @gmarull  linked the wrong pr

#42020 introduces a similar API to Linux PM QoS (simpler and part of policy manager because of Zephyr design), so it's not anything new in the end.

Confused how #42020 is relevant here.

It introduces a new API, with no in-tree users (yet), that's the only relation really.

Regarding dynamic pinctrl, it was added because a few people asked for it multiple times, so there was an interest in the community.

aha, and what part of this PR is not "interest in the community"?

Dynamic pinctrl was asked by multiple people and was a recurrent topic, as far as I can remember. So by "community" I mean multiple parties, not just a single company.

You have two SKUs that share 99.9% of the HW but assume there are some differences in how certain devices are connected to power, so device A which is part of domain A in SKU 1 is part of domain B in SKU 2.

Sticking to this definition, you must know how they are connected, so you can have 2 board revisions: SKU1 and SKU2.

You can discover what SKU you are running on and adjust things accordingly at runtime.

Sounds like the same case as pinctrl, yes. For pinctrl you could use the dynamic version, true, but you could also have board revisions. As I said, dynamic pinctrl is a contained solution, the proposal here has a wider impact, which is what worries me. I think we should have a discussion on what are the limits of dynamic stuff because current Zephyr foundations go into another direction.
For this case, I guess you could have a power domain driver that can be configurable at runtime based on input readings. So all devices are connected to it, but what it does is decided at runtime (I miss usecase information to understand if this is a valid option).

Dynamic pinctrl was asked by multiple people and was a recurrent topic, as far as I can remember. So by "community" I mean multiple parties, not just a single company.

Maybe we should drop x86 architecture, what the hell is this architecture doing in zephyr if it is used only by one company.
Please do not make up policies and rules as we go, we are better than this and zephyr would not made it so far following this logic.
Most of the APIs and usages came from ONE company and evolved. Something that is used and advanced by one company today moves forward and is re-used, the examples of this are countless.

Sticking to this definition, you must know how they are connected, so you can have 2 board revisions: SKU1 and SKU2.

No I can't.

#42020 introduces a similar API to Linux PM QoS (simpler and part of policy manager because of Zephyr design), so it's not anything new in the end.

Confused how #42020 is relevant here.

It introduces a new API, with no in-tree users (yet), that's the only relation really.

Regarding dynamic pinctrl, it was added because a few people asked for it multiple times, so there was an interest in the community.

aha, and what part of this PR is not "interest in the community"?

Dynamic pinctrl was asked by multiple people and was a recurrent topic, as far as I can remember. So by "community" I mean multiple parties, not just a single company.

You have two SKUs that share 99.9% of the HW but assume there are some differences in how certain devices are connected to power, so device A which is part of domain A in SKU 1 is part of domain B in SKU 2.

Sticking to this definition, you must know how they are connected, so you can have 2 board revisions: SKU1 and SKU2.

You can discover what SKU you are running on and adjust things accordingly at runtime.

Sounds like the same case as pinctrl, yes. For pinctrl you could use the dynamic version, true, but you could also have board revisions. As I said, dynamic pinctrl is a contained solution, the proposal here has a wider impact, which is what worries me. I think we should have a discussion on what are the limits of dynamic stuff because current Zephyr foundations go into another direction.
For this case, I guess you could have a power domain driver that can be configurable at runtime based on input readings. So all devices are connected to it, but what it does is decided at runtime (I miss usecase information to understand if this is a valid option).

But then you are not able to re-use existent power domains and you will need to re-implement it for all your domains.

Dynamic pinctrl was asked by multiple people and was a recurrent topic, as far as I can remember. So by "community" I mean multiple parties, not just a single company.

Maybe we should drop x86 architecture, what the hell is this architecture doing in zephyr if it is used only by one company.

I'd be the first to complain about this removal because this clearly benefits the project and many companies can benefit from x86 support, I'm not sure how that compared to what we're discussing here. We're talking about technical stuff: the implications of adding dynamic stuff when Zephyr device model seems to be faced into another direction.

Please do not make up policies and rules as we go, we are better than this and zephyr would not made it so far following this logic.

I'm sorry, but I'm not making any policy here.

Most of the APIs and usages came from ONE company and evolved. Something that is used and advanced by one company today moves forward and is re-used, the examples of this are countless.

And you'll find countless examples of features that get pushed back because the community doesn't think they're right, even though one company thinks it is.

But then you are not able to re-use existent power domains and you will need to re-implement it for all your domains.

And what is the exact problem of having, e.g., a new driver or an out of tree driver that supports a runtime configurable domain? Most projects I see have out of tree drivers, really. It could also be upstreamed if it is generic enough.

But then you are not able to re-use existent power domains and you will need to re-implement it for all your domains.

And what is the exact problem of having, e.g., a new driver or an out of tree driver that supports a runtime configurable domain? Most projects I see have out of tree drivers, really. It could also be upstreamed if it is generic enough.

Almost everything can be done out of tree ... Again, there is not criteria everything done in #42040 could be done in a "custom policy" that is out of tree or in a new policy and not the default and it could be upstreamed later. It seems that this will be an endless conversation, you are pointing and asking things here that yourself has not done in other situations and that is very frustrating.

But then you are not able to re-use existent power domains and you will need to re-implement it for all your domains.

And what is the exact problem of having, e.g., a new driver or an out of tree driver that supports a runtime configurable domain? Most projects I see have out of tree drivers, really. It could also be upstreamed if it is generic enough.

Almost everything can be done out of tree ... Again, there is not criteria. Almost everything done in #42040 could be done in a "custom policy" that is out of tree or in a new policy and not the default and it could be upstreamed later. It seems that this will be an endless conversation, you are pointing and asking things here that yourself has not done in other situations and that is very frustrating.

But then you are not able to re-use existent power domains and you will need to re-implement it for all your domains.

And what is the exact problem of having, e.g., a new driver or an out of tree driver that supports a runtime configurable domain? Most projects I see have out of tree drivers, really. It could also be upstreamed if it is generic enough.

Almost everything can be done out of tree ... Again, there is not criteria. Almost everything done in #42040 could be done in a "custom policy" that is out of tree or in a new policy and not the default and it could be upstreamed later. It seems that this will be an endless conversation, you are pointing and asking things here that yourself has not done in other situations and that is very frustrating.

And, please don't mark prs to be reviewed in meetings few hours before the meeting happens because the owner may not attending the meeting to talk about the change. Also, specific to this PR, there is a regular meeting to discuss power management that is the natural place to discuss power management first.

I'm going to come back to a variation of my original suggestion, and propose moving this to custom behaviour of https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/power_domain/power_domain_gpio.c
This PR is focused entirely on power domains, so why not extend that driver, which is the only power domain currently in tree.
The existing build infrastructure stays the same, the handles for every device don't need to move to RAM, and you don't need to bloat the handles array for every other device. If we end up having multiple power domains in tree, the functionality could be added to a common power_domain_api.

I'm going to come back to a variation of my original suggestion, and propose moving this to custom behaviour of https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/power_domain/power_domain_gpio.c
This PR is focused entirely on power domains, so why not extend that driver, which is the only power domain currently in tree.
The existing build infrastructure stays the same, the handles for every device don't need to move to RAM, and you don't need to bloat the handles array for every other device. If we end up having multiple power domains in tree, the functionality could be added to a common power_domain_api.

Why I would add this API for a power domain that is not used in our use case ? Sorry but this is not generic for power domains, the use case is to be able to map a device to any sort of power domain and we would end up needing to re-implement for all different power domains. Once again, the feature is completely optional as has no impact for those who not want to use it

Why I would add this API for a power domain that is not used in our use case ? Sorry but this would be specific for this power domain, the use case is to be able to map a device to any sort of power domain and we would end up needing to re-implement for all different power domains.

There are options beyond just copy pasting an implementation into N different drivers.

Once again, the feature is completely optional as has no impact for those who not want to use it

Personally what I'm not a fan of is that enabling a feature for a single type of device changes device generation and memory layout globally. I feel like there are more targeted solutions. I will add come comments of what I think would improve this if the global path is still chosen.

So then, why isn’t it possible to implement a custom PM domain driver instead of a more invasive solution like the one presented here? Or use board revisions? I think these question have not been clearly answered yet.

So then, why isn’t it possible to implement a custom PM domain driver instead of a more invasive solution like the one presented here? Or use board revisions? I think these question have not been clearly answered yet.

Can you deploy the same binary (without re-compile) in two different targets using board revisions ? If the answer is no you have your answer. Because that is a behavior that is useful for any power domain. Let me be clear, one more time, it can be done in custom driver, but we would end up having to do it for our custom pm_driver_x, the custom_pm_driver_y, so on a so forth. It is not like all the pm drivers would do the same thing .... This is not invasive,  .... it does not change anything if it is disabled and it it is not a major change.
These questions were answered many times in this discussion, there is a real use case for this feature. Now what I getting here is, I don't like the feature and I don't care if there are users asking for it, simply because I don't care ...

Why I would add this API for a power domain that is not used in our use case ? Sorry but this would be specific for this power domain, the use case is to be able to map a device to any sort of power domain and we would end up needing to re-implement for all different power domains.

There are options beyond just copy pasting an implementation into N different drivers.

Once again, the feature is completely optional as has no impact for those who not want to use it

Personally what I'm not a fan of is that enabling a feature for a single type of device changes device generation and memory layout globally. I feel like there are more targeted solutions. I will add come comments of what I think would improve this if the global path is still chosen.

I can resize only devices that are domains, and so not increase memory usage for other devices ... This of course will require more complicated changed. Doing it in an additional commit so we can review it.

I will join the club of those who do not like this for two reasons:

Everything of this commit is hidden deep inside the Zephyr core code. There is no DT exposure at all and all the magic is done in some automatic way behind the curtains in a way that is kinda special and custom. And yes, this is inconsistent with very much all the other zephyr components.

To me it looks like this PR is taking shortcuts. Why this is not implemented as a new driver or subsystem or framework with a proper set of changes well compartmentalized?

I will join the club of those who do not like this for two reasons (at least):

Everything of this commit is hidden deep inside the Zephyr core code. There is no DT exposure at all and all the magic is done in some automatic way behind the curtains in a way that is kinda special and custom. And yes, this is inconsistent with very much all the other zephyr components.

The logic behind the handles is probably is why this is deep inside the code. We have that magic happen in build time and in order to reserve some slots we have to change there. That is not allocating anything dynamically, it is about to configure / reconfigure something at runtime.

To me it looks like this PR is taking shortcuts. Why this is not implemented as a new driver or subsystem or framework with a proper set of changes well compartmentalized?

The reason is because this is a behavior that applies for any power domain and it is not particular to one driver. Another use case that would take advantage of this feature is when you have a dma controller that is reconfigured to do a transfer in a different bus. In this case it makes sense to bind the controller to the power domain that the bus is in.

Everything of this commit is hidden deep inside the Zephyr core code.

isn't this how Zephyr works in general? All the userspace and syscall code generation, DT device dependencies and handles, build system automagic all over the place, so when you try to do something simple, you end up touching all those areas under the hood.

So I wonder why something like this can't be done:
static int mydomain_init(const struct device *dev)
{
	struct mydomain_data *data = dev->data;
	const struct mydomain_config *config = dev->config;

	/* determine at runtime if SKU1 or 2 */
	if (is_sku1()) {
		data->gpio = config->sku1_gpio;
	} else {
		data->gpio = config->sku2_gpio;
	}

	/* configure data->gpio */
	...

	return 0;
}

#define MYDOMAIN_DEFINE(n)						       \
	static const struct mydomain_config mydomain_config##n = {	       \
		.sku1_gpio = GPIO_DT_SPEC_INST_GET(n, sku1_gpios),	       \
		.sku2_gpio = GPIO_DT_SPEC_INST_GET(n, sku2_gpios),	       \
	};								       \
									       \
	static struct mydomain_data mydomain_data##n;			       \
									       \
	DEVICE_DT_INST_DEFINE(n, &mydomain_init, NULL, &mydomain_data##n,      \
			      &mydomain_config##n, POST_KERNEL,		       \
			      0, NULL);

DT_INST_FOREACH_STATUS_OKAY(MYDOMAIN_DEFINE)

So I wonder why something like this can't be done:
static int mydomain_init(const struct device *dev)
{
	struct mydomain_data *data = dev->data;
	const struct mydomain_config *config = dev->config;

	/* determine at runtime if SKU1 or 2 */
	if (is_sku1()) {
		data->gpio = config->sku1_gpio;
	} else {
		data->gpio = config->sku2_gpio;
	}

	/* configure data->gpio */
	...

	return 0;
}

#define MYDOMAIN_DEFINE(n)						       \
	static const struct mydomain_config mydomain_config##n = {	       \
		.sku1_gpio = GPIO_DT_SPEC_INST_GET(n, sku1_gpios),	       \
		.sku2_gpio = GPIO_DT_SPEC_INST_GET(n, sku2_gpios),	       \
	};								       \
									       \
	static struct mydomain_data mydomain_data##n;			       \
									       \
	DEVICE_DT_INST_DEFINE(n, &mydomain_init, NULL, &mydomain_data##n,      \
			      &mydomain_config##n, POST_KERNEL,		       \
			      0, NULL);

DT_INST_FOREACH_STATUS_OKAY(MYDOMAIN_DEFINE)

@gmarull The reason was said before, because this has to be done for all power domain (or another additional kind of infrastructure has to be provided to avoid copy&paste. Also, this does not solve problem of when you have a dma controller that is reconfigured to do a transfer in a different bus and you want to bind the controller to the power domain that the bus is in.

@gmarull The reason was said before, because this has to be done for all power domains (or another additional kind of infrastructure has to be provided to avoid copy&paste). Also, this does not solve problem of when you have a dma controller that is reconfigured to do a transfer in a different bus and you want to bind the controller to the power domain that the bus is in.

With this description, it's clear to me that there's missing usecase information here. We went from SKU1/2 to a DMA controller that is reconfigured to do X and Y. Note that dynamic pinctrl would not be able to handle such scenarios (it's limited to boot time pre-device init). So, it's definitely not the same case as some kept insisting.

@gmarull that is not the initial use case, we not went from one to another, but to a second use case ... you are not being reasonable, it was never said that the sku1/2 use case is not longer needed or exists ... I've added a second use case that was brought my attention by another co-worker.

note: the only thing being modified here is the const attribute for device handles, so I think a better option would be something like:

#ifdef CONFIG_DEVICE_HANDLES_ROMABLE
#define Z_DEVICE_HANDLE_CONST const
#else
#define Z_DEVICE_HANDLE_CONST
#endif

and make CONFIG_DEVICE_HANDLES_ROMABLE a hidden option selected by PM domains (name may be changed, it's the first that came to my mind). Then, just use Z_DEVICE_HANDLE_CONST instead of const everywhere.
p.d. I did something similar for pinctrl https://github.com/zephyrproject-rtos/zephyr/blob/main/include/drivers/pinctrl.h#L194-L204
I liked the idea, just the new Kconfig symbol that I don't think it is necessary. We already have the  HAS_DYNAMIC_DEVICE or whatever other name we come up. Basically,
#ifdef CONFIG_HAS_DYNAMIC_DEVICES
#define Z_DEVICE_HANDLE_CONST const
#else
#define Z_DEVICE_HANDLE_CONST
#endif

CONFIG_PM_DEVICE_POWER_DOMAIN_DYNAMIC=y
No, this breaks the logic, that symbols is the one that is used to check how many slots should be pre-allocated.

@nashif @gmarull can you re-approve it please ?


fixed some errors in my previous requset

learned a lesson to double check before you submit.
here's to hoping i did a better job at it

no worries, I should have tests! someday!


Move urlEncodingParameters defaults to shell app

And expand default currencies to accomodate more values

QA steps:

Check if it is possible to run spartacus with different site than electronics
Check if removing siteCoontext configuration from app.module.ts will disable language and currency support in url (intended behavior for our libs)

tested on apparel-uk and apparel-de, worked
was also able to change defaults in config to de/EUR for apparel-de
and removing sitecontext worked as described.
passing...
however, if i set the defaults to en/usd and then try a url with de/EUR. the site completely hangs. created #1454


Updates to coded pagination component

We discussed some design changes to the simple pagination component a while back.

Icon on next button should move to left side (was causing issue when page title was overly long)
Should stack buttons on top of each other instead of having them inline (better for screen mag users)

This was done after conducting some research and doing the icons audit.
See gov uk example "For Navigating Through Content Pages"
https://design-system.service.gov.uk/components/pagination/
See updated GCDS component
https://www.figma.com/design/mh2maMG2NBtk41k1O1UGHV/GC-Design-System?node-id=1431-4617&node-type=canvas&t=uFKuAMDAgqT1CrW5-0
Acceptance Criteria

[ ] Icon has been moved to left side of next button for SIMPLE pagination
[ ] Buttons should be vertically stacked when used together instead of side by side on SIMPLE pagination
[ ] There should be a dividing line between the two stacked buttons like in the figma example for SIMPLE pagination

Done when

[ ] Component is updated and live

Deliverables

[ ] Pull request

reminder to get back to client in Freshdesk https://cds-snc.freshdesk.com/a/tickets/19583 once left-justify pagination is available.


Evaluation Code for CroHD

Hi, Dr. Harley
I re-test the new reference model (updated on 12/15/22) on CroHD, and here is the result I got:
ate = 7.71; ate_vis = 5.79; ate_occ = 11.12
The result is different from the one on the github homepage:
vis: 4.57, occ: 7.71
It seems that 7.71 is the result averaged over vis. and occ.
This is the original line of code, I modified it a little bit to print vis. and occ. results:
https://github.com/aharley/pips/blob/d8d77e2c675388e71c0729ba928f564de31a4c23/test_on_crohd.py#L346-L348

Yes, that's not an error I think, but definitely could be written better. The "real" vis/occ switch is in req_occlusion=True: https://github.com/aharley/pips/blob/d8d77e2c675388e71c0729ba928f564de31a4c23/test_on_crohd.py#L233
The vis/occ separation you are referencing has to do with the per-timestep occupancy, whereas this binary variable selects data where occlusions happen or not.
Using average ate is indeed intentional, since it gives us the accuracy on tracks that undergo occlusion. So, to reproduce the repo's vis/occ results (vis: 4.57, occ: 7.71), you need to run the model twice. (I should probably write that part of the code better...)

Yes, that's not an error I think, but definitely could be written better. The "real" vis/occ switch is in req_occlusion=True:
https://github.com/aharley/pips/blob/d8d77e2c675388e71c0729ba928f564de31a4c23/test_on_crohd.py#L233
The vis/occ separation you are referencing has to do with the per-timestep occupancy, whereas this binary variable selects data where occlusions happen or not.
Using average ate is indeed intentional, since it gives us the accuracy on tracks that undergo occlusion. So, to reproduce the repo's vis/occ results (vis: 4.57, occ: 7.71), you need to run the model twice. (I should probably write that part of the code better...)

Got it, Dr. Harley. I re-run the code, and now the result can be matched. Thanks again for your support!


Allow Prior Guesses for Parameters?

Hey there, thank you so much for this project, I use it all the time and really get a lot out of it. I have a question/idea for a possible enhancement. Would it be difficult to allow a user a guess (and maybe some certainty level) of the optimal value of each parameter in addition to specifying the region to search over? Do you think this would be keeping with the idea behind the project? For me, I often feel that I have a strong sense of where the right parameters are but want to allow for a decent sized range in case I am wrong.

That is an interesting question.
There is a "hack" in place that does something along these lines, the explore method. You can pass combinations of parameters you want the optimizer to probe, and it will do so when initializing.
bo.explore({'x': [-1, 3], 'y': [-2, 2]})

will add the points (-1, -2) and (3, 2), to the list of initialization points (together with some other points drawn at random. Obviously this is not a formal approach to your question, and has limited scope, but in case you didn't know about it, might be of help.
But yes, I would love a feature where the user could pass arbitrary parameter subspaces as having a strong "gut feeling" prior, and let the model handle it. I believe a carefully constructed kernel could encode this information (since it dictates the general type of function the GP can model), however actually translating it to an user friendly UI might be hard.
I'll see if I can play around with it a bit.

Thank you sir, I think the explore feature is great and had not been leveraging it fully. Appreciate the response. I don't really consider prior guessing to be all that important of a feature now, so please feel free to close this issue..


Jesse: Watch internationalshippingusa.com

Jesse requests the watch of the watch_keyword internationalshippingusa\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

internationalshippingusa\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ


Can you share the updated (with balance info) code?

hi
i would like to modify, of course want to integrate some other features.
will let you know more information later.
can you share the updated code, including balances info?
thanks in advance...
Regards,
K1LL3R K1NG

Hi,
Saracen didn't make the site with balances, I did.
What features do you want added?
I don't want to share the source yet.
Thanks,
Jude

hi. pls can anyone help to make directory.io with balances , i tryed for 3 days cannot succeed.. i love this project.. Big thanks to the creator!

@Zeeko22  me too i need some free bitcoins

haha... well to find free bitcoins is not the goal ... it is to try finid and if so, to tell all that impossible is nothing... but here we need to have the luck on our side. BIG luck!

Maybe you can look at https://github.com/saracen/bitcoin-all-key-generator instead, which does the same thing directory.io does, but locally.
There's little point in displaying balances on directory.io.

I'm closing this issue because directory.io does not display balances.

I got all-key generator alredy.. I see.. with all respect!

I Sell directory io with balance and préfix address Check contact me to<EMAIL_ADDRESS>


Notify applicants when new programs they may qualify for are added

As CiviForm adds more benefit programs, we will want to alert past applicants that there are new programs they can apply for.
So when a new program they are eligible for (based on their past answers) is added to CiviForm, we should email them (or otherwise notify them).
This is also a great way to bring "lapsed users" (those who used CiviForm in the past but have forgotten about it) back on.

Duplicate of #974


ROS node for hand gesture recognition

This PR implements a ROS node for rgbd_hand_gesture_learner.

Looks like there are a few formatting fixes that need to be done before being able to merge


Tasks Disappear

I just installed the plugin but out of 10 tasks that I send to Todoist, 8 to 9 of them disappear. (The block in Logseq becomes empty, and the task in todoist gets imported as empty as well).
any idea why this happens and how it can be fixed?

Hmm, I am not able to replicate this issue. Do you have other plugins installed?

Yes I have many others installed.

Tasks disappear for me as well. Pulling tasks into logseq gets the whole task list, except the first task. But the whole list is dropped from Todoist.
Other plugins installed, but disabled:

Automatic Linker
logseq-calendar-plugin
Journals calendar
TODO Exploder

Please try v5.0.3.


lb: Use index based consistent hashing

When I proposed https://github.com/envoyproxy/envoy/issues/9074 and solved it by using the host's hostname instead with https://github.com/envoyproxy/envoy/pull/10233, it only partially fixed the underlying problem. The core problem is the need to consistently hash to semantically and logically equal hosts that could have different addresses. My original solution just moved the problem one step further without really fixing it.
We ran into this when we had to migrate our workloads/clusters inplace. In these cases even the hostnames change and we end up with inconsistent hashing. The solution to this seems to be to use the index in your endpoints array as the hash key as done in mcrouter e.g.
So instead of doing it based on the hostname which can still change,  I've used the array index in the list of hosts instead.
I haven't handled the deprecation of the old config partly because I'm not sure how we want to do this and what the considerations are. I don't think the previous option was used much and with this feature it is probably not very useful so it seems like it should be deprecated. However, if there are existing uses then this scheme will change the hash so it isn't a direct swap. So perhaps we need to keep both around? But that seems like carrying dead code. If we keep both then perhaps this config needs to become an enum with different schemes for the hash_key.
cc @mattklein123
Additional Description:
Risk Level: Medium
Testing: unit
Docs Changes: yes
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
Deprecated: use_hostname_for_hashing
Fixes https://github.com/envoyproxy/envoy/issues/9074

Isn't using the index inherently unstable? There is nothing special about the ordering of hosts, control planes are free to reorder across updates.

Isn't using the index inherently unstable? There is nothing special about the ordering of hosts, control planes are free to reorder across updates.

+1. Also, I don't understand why your original patch would not work operationally. Why can't you just do the DNS swap in-place during your upgrades?

Isn't using the index inherently unstable? There is nothing special about the ordering of hosts, control planes are free to reorder across updates.

+1. Also, I don't understand why your original patch would not work operationally. Why can't you just do the DNS swap in-place during your upgrades?

I hadn't considered envoy's control plane API. But otherwise the ordering of hosts is just hardcoded and something that can be relied upon by convention. It's not my favourite idea but it's simple and it's already out there for the same use case.
I guess the problem that we ran into is something that happens at scale. We had to break up our redis clusters into multiple clusters in GCP because they were getting too large. Semantically for clients, this level of infrastructure detail is not their concern. They just want to connect to a redis and our cluster management should be opaque to their consistent hashing needs. Currently we have regional CNAMEs and we actually did what you suggest and swapped them in place to point to the new structure. You know how complex systems change and old naming decisions become obsolete and come to haunt very soon. We're not there yet but we're stuck with the old names forever unless we do some sort of multi redis replication that flows through envoy so that the URLs can change without data loss.
What about adding something like a hash_key to the metadata of LbEndpoint so the lb can use that? Or it could be part of the Endpoint object like hostname is (I think that is being used for something like this even though it doesn't have to resolve to anything).

What about adding something like a hash_key to the metadata of LbEndpoint so the lb can use that? Or it could be part of the Endpoint object like hostname is (I think that is being used for something like this even though it doesn't have to resolve to anything).

I like this better. It seems a lot more generic. Can you propose an API change for this and we can discuss?
/wait


region may not trigger split check

Bug Report

What version of TiKV are you using?
v4.0.9-v4.0.12,  v5.0.0, v5.0.1
What operating system and CPU are you using?
doesn't matter
Steps to reproduce
doesn't need special operation
What did you expect?
trigger split check when needed
What did happened?
doesn't trigger split check sometimes
https://github.com/tikv/tikv/pull/9081 introduced a new task in the split checker whose name is GetRegionApproximateSizeAndKeys. https://github.com/tikv/tikv/blob/eb2ed7f64efa95f3b80890f795127c1d61a292a7/components/raftstore/src/store/fsm/peer.rs#L3563-L3573 However, the code above has an assumption that if the approximate_size is not None, the split check has been done before, which is not true now.
So if the region has no enough write cmd to trigger the threshold(compaction_declined_bytes or size_diff_hint), it may not be split no matter how large it is.
Furthermore, restarting TiKV can not solve this problem because the leader will call heartbeat_pd and update its approximate_size after a while then split check will be skipped.

/cc @gozssky @Little-Wallace @Connor1996

/severity major

This might block one of our critical PoC tests which needs to prove horizontal scalability. Encountering large regions, the workload won't be scatter among nodes well on TiFlash.


Logs are being sent to stderr

I'm running substreams-sink-postgres on GCP via a Kubernetes and a Deployment with 1 Pod. All the logs are being recognized as error, which means that all the logs are being sent to stderr.
You can reproduce by saving the stderr into a file:
substreams-sink-postgres run <database> <host> <spkg> db_out 2> stderr.log

That is the expected behavior, logging is often performed on stderr. We do run also on Kubernetes and I don't remember seeing this.
Do you see the log formatted as JSON at least on your deployment?

Yeah so the problem is that it still prints as text. Our logging library normally would have detected that your are in a container environment and switched to JSON which I think would solve the issue for you.
Are you building from master?

RUN cargo build --release && rm src/*.rs

# code compilation
COPY ./Makefile ./substreams.yaml ./
COPY ./proto ./proto
COPY ./src ./src

RUN make compile

FROM debian:bullseye as application
ARG TARGET

ENV SUBSTREAMS_POSTGRES_VERSION=2.3.2
ENV SUBSTREAMS_GIT_REPO=https://github.com/streamingfast/substreams-sink-postgres/releases/download

RUN apt-get update && \
            apt-get install -y wget \
                               make && \
            rm -rf /var/lib/apt/lists/*

# install substreams-sink-postgres
RUN wget $SUBSTREAMS_GIT_REPO/$SUBSTREAMS_POSTGRES_VERSION/substreams-sink-postgres_linux_x86_64.tar.gz && \
            tar -xvf substreams-sink-postgres_linux_x86_64.tar.gz && \
            mv substreams-sink-postgres /usr/local/bin

WORKDIR /app

COPY --from=build /app/substreams.spkg ./substreams.spkg
COPY ./schema.sql ./Makefile ./

# setup + sink
ENTRYPOINT ["make", "execute"]

The latest version that I tested directly from releases was 2.3.2. Since then I was using the branches that I was working on. Usually they were synced with the master branch from streamingfast. I never got a jsonPayload in GCP.

Can you retry to build from develop branch, I've just bumped to use our latest logging library which once you re-built your container with it, it should be good now.

Could you create a patch release or a prerelease? My current dockerfile is tightly attached to your releases

Thank you! Everything is working smoothly.


Made requested Changes, missing track icon as well as main SDHacks 2022 icon

remove the fellowship link on the navbar
update tracks to the following: (health and wellbeing, civic engagement, community, sustainability)
remove all the sponsors and put "Coming soon!" or some other message about the sponsors being uploaded later
remove all the partners except Tau Beta Pi

also there's some unused imports on the Home Sponsors page, but I didn't know if it was okay to delete them so I left them in :/


[Bug] https://temporal.io/blog/temporal-and-kubernetes is 404

What are you really trying to do?
Read the readme
Describe the bug
One of the first links explaining if you should use these chats in production 404s
Minimal Reproduction
click the link "See our recent discussion on this topic" in the 3rd para of the readme
Environment/Versions
n/a
Additional context
n/a

Thanks for reporting! I've removed the dead link and updated the README to say that the only portions of the helm chart that are production ready are the parts that configure and manage Temporal Server itself—not Cassandra, Elasticsearch, Prometheus, or Grafana.


Fixes #68201 - adds qs.* label formatting tokens

Addresses https://github.com/Microsoft/vscode/issues/68201
Allows ${qs.*} tokens in the resourceLabelFormatters.formatting.label, where the * is resolved to a property of the querystring json object (assuming it is a json object)
/cc @isidorn

Thanks for your PR.
However this milestone we are not focused on adding new features (more about that in the iteratino plan).
Thus putting this to on-deck for now.

Doh -- oh sir, it's only wafer thin 🤣

@isidorn Any chance for this soon?

@eamodio you are the only user that wants this currently. I understand we could use this to better provide label in the explorer for the GitLens or RemoteHub extension but could you point me to a feature request for those extensions such that I possible get motivated to merge this in.

@isidorn I don't have any feature request that cover this (mainly because my uri hacks mostly provide a decent experience). It is more of debt that extensions have to pay in formatting uris in strange ways to get them to display nicely in the UI.

Ok, that is good enough. This is nice work, so I would merge it in if we add some tests.
Here's a code pointer for tests https://github.com/Microsoft/vscode/blob/73643c60a644145c6a57b61787efd6a62e153cfa/src/vs/workbench/services/label/test/label.test.ts#L22

@isidorn sorry for the long delay on this. I've rebased it with master and added a handful of tests. Let me know what you think. 🤞 this can still make it for July.

@isidorn any chance? 😉

@eamodio sorry for the slow response, I was on a 3 week vacation.
Thanks for adding tests. Merging in


x/build/cmd/relui: workflow parameters of slice types aren't visibly shown

relui currently renders a recent "announce-and-tweet-minor" workflow from the Go 1.18.5 and 1.17.13 minor release:

The values for the string parameters "Version", "Security Summary", etc., are displayed, but not for the "Release Coordinator Names" and "Security Fixes" parameters, likely because their type is []string.
(The parameter values are there in the database and were correctly used by the tasks; this is only a presentation issue.)
CC @golang/release, @cherrymui.

Looked at this briefly. As expected, it was only a problem for non-string parameters, and it's because the current parameter display code assumes all parameters are strings, which isn't always the case as of #51191.
Long term, we could extend the nice type-specific presentation that @toothrot did for results and outputs in #53382 to parameters too, but for now I'll mail a small CL that shows their JSON encoding, which is much better than invisible.

This change breaks the layout a bit for some workflows. I am happy to fix it, though, and give it a little nicer visual treatment.
https://build.golang.org/releases/workflows/14dad363-ab84-41b7-af65-1928299f3390

Sure, thanks for helping!

I'll send a CL that implements this screenshot. It's not perfect, but it's closer to something nice.


Blacklisted sites to consider adding

Here's my list of blacklisted sites to consider blocking by default.
www.watson.ch
www.20min.ch
www.blick.ch

I was able to block watson.ch, update the definitions and try again.
I can't really block the other two sites. I have the same problem with Facebook. Whatever they use for their site, the class names are randomly generated, and while they might stay the same for a little while, they frequently change. It makes nearly impossible to successfully block comments.


Reimplement basic logging for OVSP4RT

Implemented a rudimentary logger for OVSP4RT, together with some helper functions to handle the most common message patterns. The initial implementation simply prints to the console.

Replaced printf() calls with calls to the logger or helper functions.

I've reengineered the logging code to display table names without violating the abstraction model.


Not able to checkout code from master branch

ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

how are you building it ? azure devops options are completely differnt to those presented in the book.

Hi, could you please give more details about the issue ?

The name of the branch is main.


AttributeError: module 'enum' has no attribute 'IntFlag' Python 3.6.2

hi
I run command pip install infobip-api-python-client
the command failed
error

Collecting infobip-api-python-client
Using cached https://files.pythonhosted.org/packages/d8/b6/6f975e3e795643dc86b4c19cc57f1acdc04bea35f9613ce93ce4244bb645/infobip-api-python-client-2.2.0.tar.gz
Collecting enum (from infobip-api-python-client)
Using cached https://files.pythonhosted.org/packages/0c/4e/1ea357e7783c756bb579333c1e4a026fb331371ee771f616ffedc781e531/enum-0.4.6.tar.gz
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "", line 1, in
File "/Users/folt/Documents/Working/dev_messenger/venv/lib/python3.6/site-packages/setuptools/init.py", line 5, in
import distutils.core
File "/Users/folt/Documents/Working/dev_messenger/venv/lib/python3.6/distutils/init.py", line 4, in
import imp
File "/Users/folt/Documents/Working/dev_messenger/venv/lib/python3.6/imp.py", line 27, in
import tokenize
File "/Users/folt/Documents/Working/dev_messenger/venv/lib/python3.6/tokenize.py", line 33, in
import re
File "/Users/folt/Documents/Working/dev_messenger/venv/lib/python3.6/re.py", line 142, in
class RegexFlag(enum.IntFlag):
AttributeError: module 'enum' has no attribute 'IntFlag'
----------------------------------------

Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/j_/qkr9lhfd0g593b64465q50cr0000gn/T/pip-install-59o613b7/enum/

I use Python 3.6.2

Hi,
currently, we support only python2 as listed in the supported languages section on pypi.
We will see to it that support for python3 gets added in the future.
Kind regards

@denis-cutic hi man! This is taking too long, everybody is using python 3 now!

Hi @neoecos!
We are in the process of making new libraries, including a new Python lib for Python 3. I realize the process is slow, but you can expect changes in the upcoming months.
Kind regards

Hi,
Do you guys have some lib for python 3 already? I the there is a pull request pending for some time now.
Thanks

Hi,
as the code is automatically generated we are not accepting pull requests.
Also, we are not planning to upgrade the current Python library to support Python 3.
On the other hand we are working on providing OpenApi specifications for our APIs. This will allow you to generate libraries for various languages, including Python 3.
For the time being I suggest either forking the repository or using one of the existing forks supporting Python 3.
Kind regards

a separate library is a good solution

@hkozacinski , @denis-cutic
Any update on this ?
Is Python 3 supported now ?
Or that OPEN API Specification document ready ?

i have a problem while running code on pycharm
every code i try to run using pygame it throw me with an error module 'enum' has no attribute 'IntFlag'
i have also tried to uninstall enum 34 but it shows me this "Skipping enum34 as it is not installed."
please help me with this i am using python 3.8 version

Traceback (most recent call last):
File "C:/Users/DELL/Desktop/pyhton/OOPS/game.py", line 1, in
import pygame
File "C:\Users\DELL\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pygame_init_.py", line 202, in
import pygame.threads
File "C:\Users\DELL\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pygame\threads_init_.py", line 15, in
import traceback, sys
File "C:\Users\DELL\AppData\Local\Programs\Python\Python38-32\lib\traceback.py", line 5, in
import linecache
File "C:\Users\DELL\AppData\Local\Programs\Python\Python38-32\lib\linecache.py", line 11, in
import tokenize
File "C:\Users\DELL\AppData\Local\Programs\Python\Python38-32\lib\tokenize.py", line 32, in
import re
File "C:\Users\DELL\AppData\Local\Programs\Python\Python38-32\lib\re.py", line 145, in
class RegexFlag(enum.IntFlag):
AttributeError: module 'enum' has no attribute 'IntFlag'

please help

Any updates?

I suggest making a fork

Hi! We are currently upgrading all our client libraries, next will be Python, it will be automatically generated and completely different from the current version.
You can expect this next month.


Submit to JSDelivr

Would be great to have this on JSDelivr so we can download it with our other scripts (via JSDelivr's concatenation feature).
See https://github.com/jsdelivr/jsdelivr/blob/master/CONTRIBUTING.md

@bradvogel Just sent a PR :)

Done @bradvogel: 8d31243679bb1fc652896c43ddbda8bb7882c24c

Thanks!


RFDuino library expects g++ compiler, which is no longer present

The RFDuino library, via its "platform.txt" configuration file, expects there to be a g++ compiler.  In Arduino 1.5.7 and 1.5.8 for Windows (maybe also other platforms, and maybe also earlier versions), the g++ compiler is no longer present.  So, the code won't compile.
A workaround has been found using the gcc compiler through the Arduino toolchain (presumably in place of the g++ compiler).  See:
http://openbci.com/forum/index.php?p=/discussion/259/missing-compiler-when-re-programming-the-rfduinos-dongle-and-openbci-device#latest
Can this be fixed so that it works without users having to edit any files?
Chip

Changed the platform.txt file so that it points to the right compiler path.
Also verified that this will work on Mac and Windows


Create User Profile Page

Create the structure for User Profile page
Create the initial file structure, boilerplate code and routing for the Profile page.

[x] Create directory structure
[x] Create file boilerplates
[x] Create react-router logic to get to page

path will be /<user-id>

[x] Set path based on session context (logged in user)

Allow access to other users profiles
Expand on the Profile page to allow it to display other users profile's, not just a logged in users.

[x] One component is used to render both dashboard and profiles
[x] Pass user-id through the request query params

Create content for User Profile page
Create the three main content sections for the profile page. Fill them with initial content in both the profile and dashboard setting.

[x] Query all necessary User info for the Info component

[x] Username
[x] Last Active Date (days, hours if less than 1 week)
[x] Account Age
[x] #14

[x] Render info data in temporary <p> tags
[x] Query all necessary Score data for Scores components
[x] #17

[x] Create calendar component
[x] Create totals component
[x] Create stat chart component

[ ] Implement score chart from #7

Define initial styling structure
Start defining the structure of the components and how they will be style. Using tailwind classes of course.

[x] Set up flexbox/grid to
[x] Define containers and borders
[x] Add placeholder profile picture
[x] #21

Initial Boiler Plate and structure set up. Will start working on the actual content tomorrow!

Create content for User Profile page
Create the three main content sections for the profile page. Fill them with initial content in both the profile and dashboard setting.

[ ] Query all necessary User info for the Info component
[ ] Render info data in temporary <p> tags
[ ] Query all necessary Score data for Scores and Stats components
[ ] Render score data in temporary <p> tags

Define initial styling structure
Start defining the structure of the components and how they will be style. Using tailwind classes of course.

[ ] Set up flexbox/grid to
[ ] Define containers and borders
[ ] Add placeholder profile picture

Just about done! Just bug fixing for now until the score chart component is complete. Should get pushed this week.

Closed by #24


Fix for Java 5 and 6 JVMs

Fixing the dependency on Java 7 by removing the java.util.Objects.requireNonNull calls.
The project will now be able to run on Java 5 JVMs again.

Codecov Report

Merging #214 into master will not change coverage.
The diff coverage is 50%.

@@            Coverage Diff            @@
##             master     #214   +/-   ##
=========================================
  Coverage     86.62%   86.62%
  Complexity      148      148
=========================================
  Files             4        4
  Lines          1839     1839
  Branches        460      460
=========================================
  Hits           1593     1593
  Misses          126      126
  Partials        120      120

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/picocli/CommandLine.java
89.07% <50%> (ø)
87 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Good catch, thank you!

The codecov plugin prevents me from merging this on my phone. (Unsure why, looks like a codecov bug.)
I’ll merge this when I get back to my pc tonight.

This has been merged into master, and a new release (v2.0.1) is now available from Maven Central and JCentral.
Thanks again for the PR!


Dotnet.

Issue Title
Be as descriptive as you can with your title.
General
Provide details on the problem you are experiencing including the .NET Core version, operating system version and anything else that is relevant.
Please provide a code sample for your issue if it is relevant, either inline, link to a gist (or similar) or add it as a zipped attachment.
For some issues, you will get a quicker and better response if you file it at a more specific .NET repo. For example, if the problem is with ASP.NET Core, you are encouraged to use the aspnet/home repo.

Please provide information about the issue or the question that you have @gouaic.


Redux added to the project

What is added new

[ ] redux toolkit added to the project
[ ] redux directory added to the project
[ ] files added for books slice and categories slice
[ ] store is configured
[ ] book slice includes a reducer which adds a book and removes a book
[ ] categories slice includes a reducer that checks the status and returns Under construction

What is added new

[ ] the error is been solved


Can't compile

Hello, i am trying to compile, because the one compiled on release not work on my machine.

CMAKE logs
CMakeOutput.log
CMakeCache.txt

Hi, quick question. Are you building on OpenSUSE ?

Hi, quick question. Are you building on OpenSUSE ?

yes

Can you share the output of flutter doctor, only it appears from the logs you may be missing some of the needed toolchain ( e.g. ar isn't found ). I'm guessing here, but trying to get enough info to move forward.

Found with doctor, that i need to install gtk3-devel.
is good to put on the doc:
for build
enable flutter linux build
flutter config --enable-linux-desktop
opensuse requiremente
zypper in gtk3-devel
after compiling and executing:

quickemu work normally, but quickgui no

are you in <quickgui_src>/build/linux/release/bundle/ ? You maybe just need to execute .//build/linux/release/bundle/quickgui if you're at the top of the source after building.

are you in <quickgui_src>/build/linux/release/bundle/ ? You maybe just need to execute ./build/linux/release/bundle/quickgui if you're at the top of the source after building.

this is the folder that is created on the build:
./build/linux/x64/release/intermediates_do_not_run/quickgui

Hmm, that looks to me as if you still don't quite have a working build environment.  Beyond my capacity to help here (not a flutter dev and not used OpenSuSE since 10.x days ) but maybe a bit of google-fu can find a guide (post or person) that can get you to a completed build.  Something similar to the Ubuntu-based guide linked in the Readme.  The one that a quick search suggested to me is here but you may find better. Working through to a running example/test desktop app should hopefully put you in a position to build this successfully.
I'm surprised that just unpacking the release archive somewhere and running it from there doesn't work for you: it is supposed to be portable after all, and works fine for me (and others clearly) so if there's an OpenSUSE-specific problem we'll need to sort that too - thankfully we can quickget opensuse ...  . Some more detail on how the release fails for you might help, along with what release/version of OpenSUSE you're running. Hopefully then smarter eyes than mine can take a look.

Thank.
The links have nothing of the website not share nothing new to me.
And is weird that isn't working neither the release version.

i am using Tumbleweed.

Found with doctor, that i need to install gtk3-devel.
is good to put on the doc:
for build
enable flutter linux build flutter config --enable-linux-desktop
opensuse requiremente zypper in gtk3-devel

I don't think I'll put that in the doc. It's a "install flutter properly" problem, not a quickgui problem. Besides, I can't put in the doc everything everyone has to do on every distro to install flutter.

intermediates_do_not_run

That's your clue :-) Do not run a binaray that is in a folder names "do_not_run".
As @philclifford said, you probably still have a problem with your flutter installation.
Try this :
flutter create helloworld
cd helloworld
flutter build linux --release
./build/linux/x64/release/bundle/helloworld

You should have the default app running.

Also, as @philclifford said, why are you not using the provided binaray files ? Did you try to go to https://github.com/quickgui/quickgui/releases/tag/v1.1.1, and download quickgui-1.1.1.tar.xz ?

Don't know what happened, but with the version 1.1.2 is working now.
thanks for the patience and support.

NAME="openSUSE Tumbleweed"
VERSION="20211107"
KDE Plasma 5.23.2

Do you still have a problem with this ?

I think I have an idea.
Where is quickget installed ?
I bet quickget is not in the PATH when you use the file manager, but it is when you run from a terminal.
Can you check that ?

I think I have an idea. Where is quickget installed ? I bet quickget is not in the PATH when you use the file manager, but it is when you run from a terminal. Can you check that ?


move faker to prod deps so that it can be used during prod seed

This is not necessary. I still need to take the time to write the docs in Epic Stack, but here's how I'm recommending seeding in production: https://github.com/epicweb-dev/data-modeling/tree/main/exercises/04.seed
We don't want to install faker in prod, so I'm going to close this. Thanks!


HSEARCH-4148 Polymorphic "derivedFrom" definition for derived properties

https://hibernate.atlassian.net/browse/HSEARCH-4148

Merged thanks!

Thanks


#Mongo-optimization-task. Andrey Tereshkin

https://travis-ci.org/github/Terem/db-assignments/builds/746629365

Closing the PR as accepted! Thanks!


#559289: added implementation getEEMarkup into sitecore-jss-nextjs

Description / Motivation

Testing Details

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Was there no way to solve this (make it editor-friendly) without using getEEMarkup? As mentioned, this wasn't intended to be used externally... If this is the only way, then we can go with this.

Yeah! I removed this getEEMarkup and now there is using


Is parse-server reliable for a new project?

Hi Parse Team and contributors,
I was planning to start a new project on Hosted Parse, but due the Parse shutdown I'm looking for other alternative.
What do you think? May I use ParseServer?
Thanks

I'm currently in the process of migrating all my existing projects and clients to parse server.
For a new project I would recommend and still use the existing parse.com as the back as this will still be active for 12 months then migrate to parse server in around say April after some of the initial bugs have been ironed out and the web UI is added.

Thanks, I'm also migrating my projects into a own-hosted MongoDB Database, and I will keep Parse hosted till the bugs and WebUI is added.
Thank you.

We'll do our best to get this rock-solid as soon as possible.  I don't think that will take long at all.  Thanks for your patience and support!


Plugin Store prerequisites

A new plugin-management.js file has been introduced, responsible for handling plugin installation, listing, upgrades, and deletions. Additionally, the runCommand function has been enhanced to support electron-node command, enabling seamless execution of Node commands within the Electron environment.
For https://github.com/headlamp-k8s/headlamp/issues/1654

@yolossn I guess you saw these app CI failures? https://github.com/headlamp-k8s/headlamp/actions/runs/8662622201/job/23754940075?pr=1907#step:5:237
They look like real failures. About some module missing.

@yolossn there's some lint errors.
Would you mind rebasing against main? It's been a while.

Oh there's also a plugins test failure here:
https://github.com/headlamp-k8s/headlamp/actions/runs/9069183339/job/24918162976?pr=1907#step:4:898
Error: Cannot find module '../plugin-management-utils'
Require stack:
-<EMAIL_ADDRESS>    at Module._resolveFilename (node:internal/modules/cjs/loader:1143:15)
    at Module._load (node:internal/modules/cjs/loader:984:27)
    at Module.require (node:internal/modules/cjs/loader:1231:19)
    at require (node:internal/modules/helpers:179:18)
    at Object.<anonymous> (/home/runner/work/headlamp/headlamp/plugins/headlamp-plugin/headlamp-myfancy/node_modules/@kinvolk/headlamp-plugin/bin/headlamp-plugin.js:16:23)
    at Module._compile (node:internal/modules/cjs/loader:1369:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1427:10)
    at Module.load (node:internal/modules/cjs/loader:1206:32)
    at Module._load (node:internal/modules/cjs/loader:1022:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
<EMAIL_ADDRESS>  ]
}

Also... it could probably do with a rebase against main.

(added issue to PR description)


(Fix): Default upstream ref to main

This fix allows users to manually specify check-mode: pull_request and specify their own upstream to run in "pull request mode" from non-pull_request GH Workflow triggers.

Closed in favor of eventually adding a manual check-mode
In the meantime all mode can be hacked around with --all=false


Helm chart updates

Codecov Report

Merging #4105 into master will decrease coverage by 0.01%.
The diff coverage is 72.13%.

@@            Coverage Diff             @@
##           master    #4105      +/-   ##
==========================================
- Coverage   57.88%   57.86%   -0.02%
==========================================
  Files         900      901       +1
  Lines       28871    28912      +41
  Branches     4082     4090       +8
==========================================
+ Hits        16711    16731      +20
- Misses      12160    12181      +21


Add support for multiple countdowns in multiplayer

Prereqs:

[x] https://github.com/ppy/osu/pull/20145

The general structure is the same and the core "run-time" part of countdowns hasn't changed. The important changes are:

The new CountdownInfo class stores supporting information about countdowns that was previously stored at a class-level.
Countdowns are no longer exclusive by default. The previous behaviour is preferred for the match start and gameplay start countdowns by overriding MultiplayerCountdown.IsExclusive.

@smoogipoo made some minor naming changes, can you check you're okay with them?
I'm not going to test this locally because it doesn't seem like it needs it, but will test on dev/staging once this is merged.

Lgtm!


fix(button): prevent event propagation to children of disabled buttons

Related Ticket(s)
Fixes #693
Description
Adds a hostlistener to the button component that uses the capture phase to prevent click propagation to child elements
Changelog
Changed

disabled buttons prevent click propagation to their child elements

cc: @kennylam


Provide Helm Values override for using custom port names with Kubernetes Deployment Object

provide custom helm values which will be used for ports mapping for OpenMetadata Helm Kubernetes Deployment Object containerPorts. Current scenario, we are using hard coded TCP Protocol and overridable Port number (still within TCP Protocol).

Here is the detailed implementation requirement -
Under Values.yaml

commonLabels
podAnnotations

Will be applied to -

deployment object (common labels to both deployment and pod spec and podAnnotations to only pod spec)
check-db-migrations-job-hook (common labels to both job and pod spec and podAnnotations to only pod spec)
ingress, service, serviceaccount (apply common labels along with already configured labels)

Hello, Update on this. It seems we will only support TCP Protocol on Deployment Object as containerPort, Other Options are UDP and SCTP which is not relevant in our case. Closing this ticket for now as we already support TCP and is overridable with Port number from Helm Values.


Packages folder is empty?

Looks like starting frm 6.0.0, the packages folder doesn't contain anymore perbuilt css and js bundle files

Yes, install it from NPM or download files from UNPKG<EMAIL_ADDRESS>


Support asdf's .tool-versions file

Hey all,
Happy new year! 🎉
First time contribution so apologies in advance if I'm going about this the wrong way. I figured this could be a worthwhile feature addition to Rubocop.
For context:
I recently switched to asdf from rbenv on my personal dev environment.
I decided to try out Ruby 3.0 today on a project, and when I started getting errors from Rubocop on Ruby 3.0-specific syntax, I realized that project had a leftover .ruby-version pointing to 2.6.3 which surprisingly Rubocop was picking up.
At that point I felt there was an opportunity to extend the target version detection logic to be aware of asdf's .tool-versions file, so here is a proposed change to support that.
Suggest reading the commit message for detail.
Thanks!

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
~[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).~
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

(For the of sake of transparency: I had this on draft with a note eliciting opinions on whether/how to eliminate some duplication in the original commit, but eventually I realized the file detection logic I had for .tool-versions was unnecessary so I reworked the PR to be a bit more concise.)

(For the of sake of transparency: I had this on draft with a note eliciting opinions on whether/how to eliminate some duplication in the original commit, but eventually I realized the file detection logic I had for .tool-versions was unnecessary so I reworked the PR to be a bit more concise.)

Looks good. Thanks!

Looks good. Thanks!


Going to search results on headings seems to add the path twice

When going to search results on headings inside a doc, docusaurus-search-local seems to add the path in the URL bar twice.
So, actual path to the heading:

localhost:3000/docs/etc/docname#heading

Path in URL after clikcing heading from the search results:

localhost:3000/docs/etc/docname/docs/etc/docname#heading

Doh! I did not run yarn after I updated the dependency in package.json. After I did and ran yarn build then yarn serve it seems to work. I'll create a PR.


Change to checkpoint_dump_im handling for AM3

In UM <= 11.4 (so including CM2), CHECKPOINT_DUMP_IM in the xhist file is an array because n_internal_model_max = 2. In later versions n_internal_model_max = 1 so it's just a string. Scripts that use this need to be modified.

Fixed in am3 branch by 7f2ce3f6c02b7db61058b32bbbbad795eafb1b15