DSR 3.0: First Class Tasks + Parallelization

DSR 3.0 First Class Tasks and Parallelization
Closes #PROD-1895
Closes #PROD-1892
👉 This is smaller than it looks. There's about 2K lines of real changes - a lot of code was shuffled around, tests had to change, and we needed a lot of new tests - inflating the line count.  Pay particular attention to graph_task.py, request_runner_service.py, create_request_tasks.py, and execute_request_tasks.py for DSR 3.0.
DSR 2.0 is largely contained in deprecated_graph_tasks.py.
Description Of Changes
Adds the new DSR 3.0 scheduler which supports executing DSR's in parallel and treats individual tasks in the Access, Erasure, and Consent Graphs as first-class objects.  The graph is built per usual, but then these nodes are persisted to the database as RequestTasks that can be run as celery tasks in parallel. It uses a custom event-driven scheduler, where each node runs, and upon completion, queues its downstream tasks provided the task has all of its upstream tasks completed. The terminator task in each graph also is responsible for queueing the Privacy Request itself from the appropriate checkpoint to wrap up processing.  The individual access, erasure, and consent graphs still run sequentially, but the tasks within the graphs can run in parallel.
Maintains support for DSR 2.0 which uses Dask, which runs each of tasks in the Access, Erasure, and Consent graphs sequentially and in-memory.
Code Changes
Data model

New encrypted PrivacyRequest column, filtered_final_upload that contains the access results we uploaded to the user keyed by policy rule
New encrypted PrivacyRequest column access_result_urls to store the access result URL's in case the Privacy Request exits in DSR 3.0 and is requeued, losing access to access result url's in memory (this could happen if a policy had both an access and an erasure rule)
New RequestTasks model. Request tasks are now first class objects in DSR 3.0.  Every single node in the access, consent, and erasure graphs (which correspond roughly to a collection) is saved as a RequestTask to the database immediately after the graph is built.  RequestTasks store the data they collect on the RequestTasks themselves, whereas with DSR 2.0 stores them in the cache. For backwards compatibility, we continue to write to the cache regardless.

Endpoints

Removes async callback endpoints that supported the deprecated v1 Manual Connector that assumed sequential task execution . ("/privacy-request/{privacy_request_id}/manual_input" and "/privacy-request/{privacy_request_id}/erasure_confirm").  The underlying deprecated connector has never been exposed in the admin UI and that connector is likewise removed here.
Adds GET /privacy-request/{privacy_request_id}/tasks  to get all request tasks associated with a Privacy Request
Adds GET /privacy-request/{privacy_request_id}/access_results to get the data for the upload packages that we sent to the end user
Adds POST /privacy-request/{privacy_request_id}/tasks/{task_id}/queue to queue a task by hand if it gets stuck

Internal

Removes sending code to fideslog related to DSR graphs and DSR failures.  We are phasing out fideslog anyway and this avoids having to refactor for DSR 3.0 related pieces. (Removes graph/analytics_events.py and graph/graph_differences.py)
Adds Collection.parse_from_task to support hydrating a serialized collection saved in the database under RequestTask.collection into a Collection object.
Add new ExecutionNode class to be used for executing a node. The existing TraversalNode class is now only used for building the graph, not executing it.  The ExecutionNode largely only has knowledge of itself and incoming and outgoing data edges which we can create from the database record, unlike the TraversalNode which is aware of the whole graph.  DSR 2.0 was previously able to use the TraversalNode because the graph was executed immediately in memory.
Updates connectors to use ExecutionNodes instead of TraversalNodes
Adds new access_runner, erasure_runner, and consent_runner which support running an access, erasure, or consent graph on the DSR 2.0 scheduler (in memory with Dask in sequence) or DSR 3.0 scheduler (in parallel, with persistent request tasks)
GraphTasks are instantiated later, as part of running an individual celery task for a single Node.  They are now created from just TaskResources instead of TraversalNodes since they won't have the context of the whole graph.
Logic that writes ExecutionLogs now also updates the new RequestTask status and additionally can mark all nodes that can be reached from the current node as errored if the  current node fails.
Likely breaks the Fides Connector when run with DSR 3.0
Stops passing in input_data into the request to mask a node.  These are the upstream access results that feed into the current node which were useful for erasure requests on email connectors that did not send access requests directly.  This functionality no longer exists.

AP Scheduler Tasks

Recurring task "poll_for_exited_privacy_request_tasks" that runs on a configurable interval that looks to see if all Request Tasks have had a chance to run, but some have errored, and puts the entire Privacy Request in a status of error so it can be re-processed
Weekly task DSR_DATA_REMOVAL that clears out old RequestTasks and selected columns on the Privacy Request model that are older than a configurable TTL containing encrypted PII

Tests

A lot of the DSR tests modified to run both on the DSR 2.0 and DSR 3.0 schedulers
Persist privacy requests in the database and add the correct policy to the privacy request for testing, which is needed for DSR 3.0 because each node is run as a celery task and relies on persisted objects.  For testing, we currently do a lot of creating a Privacy Request in memory and the policy we pass into the runner doesn't always match the policy on the privacy request (which is okay for 2.0 but not 3.0)
Policies also need to be persisted for DSR 3.0 testing, so this means we can't use fake data categories - like "A" and B"

Steps to Confirm
The best way we can test this is to try to run DSR's under a lot of different conditions -

[ ] In your toml file, toggle DSR 3.0 to on:

[execution]
use_dsr_3_0 = true

[ ] nox -s dev -- shell postgres mongodb worker
[ ] Set up postgres, mongodb, and mailchimp connectors - run access and erasure requests and verify data looks as expected
[ ] Set up mailchimp transactional and run consent requests
[ ] Verify email connector works as expected
[ ]  In your toml file, turn off DSR 3.0 to use DSR 2.0:

[execution]
use_dsr_3_0 = false

Repeat, and verify you can use DSR 2.0 as expected
Verify exception logs in Admin UI look as expected - except DSR 3.0 has evidence items are running in parallel

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

@galvana I think this is ready for review! This week I am continuing to work on followup tickets to add things like catch-all schedulers and manage the number of connections but I think the core work is stable. Thank you for offering to review this 🙏

I completed the testing checklist and verified the different integration types work as expected for both DSR 2.0 and 3.0 🙌

Thank you for your first-pass review @galvana, I've responded to your changes here.  For database connection limits, I am looking into that under one of my other tickets, "Scheduler Robustness" to have ways to automatically schedule tasks that get into these weird states -

I introduced some bugs in my logging - fixing

Thanks again for all the code review Adrian! 🏆


tests: sys_mem_pool: Bus fault occurs on ARM boards (frdmk64f and nrf52840_pca10056)

When tests/kernel/mem_pool/sys_mem_pool is run on frdm_k64f and nrf52840_pca10056 platforms, bus fault occurs. I have tested only on only these 2 platforms of ARM.
Please refer the sample log:
 ***** Booting Zephyr OS v1.11.0-675-g9c032eb*****
Running test suite test_sys_mem_pool_api
==============================================
starting test - test_sys_mem_pool_alloc_free
***** BUS FAULT *****
  Executing thread ID (thread): 0x20007c84
  Faulting instruction address:  0x6663742c
  Instruction bus error
Fatal fault in thread 0x20007c84! Aborting.

Whereas the test passes on X86, Xtensa, nios2, riscv32 boards.
Sample log below:
 Running test suite test_sys_mem_pool_api
 ===================================================================
 starting test - test_sys_mem_pool_alloc_free
 PASS - test_sys_mem_pool_alloc_free.
 ===================================================================
 starting test - test_sys_mem_pool_alloc_align4
 PASS - test_sys_mem_pool_alloc_align4.
 ===================================================================
 starting test - test_sys_mem_pool_min_block_size
 PASS - test_sys_mem_pool_min_block_size.
 ===================================================================
 ===================================================================

 PROJECT EXECUTION SUCCESSFUL

The test doesn't fail on current master (7be3236) on frdm_k64f. @spoorthik, do you know which commit this failed on?

@MaureenHelm : I dont see this issue with the latest commit as you said. Let this issue be closed. I will reopen with the right commit ID.


make opt not impl Decodable

Moving the lifetime into Decodable makes it much more restrictive when actually using <'a, T: Decodable<'a>. Opt is an internal type so it doesn't need to implement the trait.

Wish: Having the above text in git log.
Yeah, a  commit message should be more as just one line.

Actually, I try to keep the first line under 50 characters so it shows up nicely in git log.
An argument could be made to include additional details on separate paragraph, I try to follow most of this advice: https://cbea.ms/git-commit/

Oops, found the wished text after clicking on an extra button.

Thanks for link on good commit messages.


Improve MST performance by prefering lock-free atomics

Variation on #660
As in the original PR by Andrey, the performance improvement comes from introducing an intermediate array that stores the weights, and taking advantage of lock-free atomics when searching for the component nearest neighbors.
Suggested improvements in this PR include

smaller increase in memory footprint (allocate View<float*> instead of View<WeightedEdge*>)
avoid allocating and deallocating at each iteration step
one extra kernel  launch instead of three

This patch does not fix the issue for PortoTaxi:
#660
#   0: [  81712629]  time :      0.101
#   1: [  10636628]  time :      0.123
#   2: [   3602596]  time :      0.113
#   3: [   1269724]  time :      0.090
#   4: [    154763]  time :      0.082
#   5: [     28660]  time :      0.047
#   6: [      5750]  time :      0.034
#   7: [      1148]  time :      0.030
#   8: [       177]  time :      0.036
#   9: [        25]  time :      0.025
#  10: [         2]  time :      0.020
#  11: [         1]
-- construction     :      0.131
-- core distances   :      0.000
-- boruvka          :      0.721
total time          :      0.867

This patch:
#   0: [  81712629]  time :      0.136
#   1: [  10636628]  time :      0.206
#   2: [   3602596]  time :      0.442
#   3: [   1269724]  time :      0.777
#   4: [    154763]  time :     32.414
#   5: [     28660]  time :     23.592
#   6: [      5750]  time :      3.113
#   7: [      1148]  time :      2.143
#   8: [       177]  time :      2.570
#   9: [        25]  time :      0.859
#  10: [         2]  time :      0.015
#  11: [         1]
-- construction     :      0.130
-- core distances   :      0.000
-- boruvka          :     66.291
total time          :     66.431

Retest this please

Please also try if these changes allow the tests to run with SYCL. I would think they do now. Since we are not using atomics on big types anymore.

Confirmed that 2cd20dc0 works correctly, and retains all the benefits from the original version of this PR.


[Feature request]: SBBLoadingIndicator bigger sizes?

Preflight Checklist

[X] I have read the Contributing Guidelines for this project.
[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Request type
Request for enhancement of a component
It affects the following packages
Components
Functionality
We need a bigger size of the SbbLoadingIndicator component. At least "XXL" or better "4XL" and "5XL".
Link to design proposal file
No response


Support for Scala Native and ScalaJS

Since this library is fully programmed on Scala, could it be possible to add support for Native and JS targets?

https://github.com/sqids/sqids-scala/pull/10


Create MOUNIR_NODE.toml

I think I could colaborate with ANOMA like I do with MASSA, HUMANODE, CONCORDIUM and another chain. Thanks

When will I know if I am a pre-validator node? Thanks


Add Fraud Detection with Machine Learning Project

Description:
This issue is for adding a new project titled "Fraud Detection with Machine Learning" to the repository. The goal of this project is to help users understand how machine learning can be applied to detect fraudulent financial transactions.
Tech Stack:

Programming Language: Python
Libraries/Tools:

pandas for data manipulation
NumPy for numerical computing
scikit-learn for implementing machine learning algorithms (Logistic Regression, Decision Trees, Random Forest)
Matplotlib for data visualization
imbalanced-learn to handle class imbalance (e.g., SMOTE)

Approach:

Data Preprocessing:

Load a publicly available dataset (e.g., the Credit Card Fraud Detection dataset from Kaggle).
Perform exploratory data analysis (EDA) to understand the features and label distribution (identify class imbalance).
Handle missing values and outliers, if any.
Normalize/scale the data as necessary.

Model Selection:

Train different classification algorithms such as Logistic Regression, Decision Trees, and Random Forests.
Use techniques like cross-validation to evaluate model performance.

Handling Class Imbalance:

Since fraud detection is a highly imbalanced problem, employ techniques like oversampling (SMOTE) or undersampling to address the imbalance between fraudulent and non-fraudulent cases.

Model Evaluation:

Evaluate models using performance metrics like confusion matrix, precision, recall, and F1-score, focusing on fraud detection accuracy.
Visualize model results using ROC-AUC curves and precision-recall curves.

Outcome:

The project will allow users to predict whether a financial transaction is fraudulent or not based on historical data.
Provide a well-documented notebook explaining each step.

If that sounds tempting feel free to assign this issue to me, I will be more than happy to work on it!

I am a gssoc 2024 extended contributor . Please assign this to me.

@coderhetal  this kind of projects already there pls try to add something new


Removed Writing task from IPipelineWriter

For better symmetry between reading and writing, the Writing
task was removed IPipelineWriter.
FlushAsync returns a bool when awaited which the producer can use to
stop producing. False means the consumer is complete.

/cc @benaadams

@dotnet-bot test this please

@dotnet-bot test Windows Debug please


[labs/analyzer]: ecma #private methods marked as public

Which package(s) are affected?
Other/unknown (please mention in description)
Description
Given
class HasHash {
  #priv = 0;
  #hash() { }
}

I get
{
  "schemaVersion": "1.0.0",
  "modules": [
    {
      "kind": "javascript-module",
      "path": "has-hash.js",
      "declarations": [
        {
          "kind": "class",
          "name": "HasHash",
          "members": [
            {
              "kind": "method",
              "name": "#hash",
              "privacy": "public",
              "return": {
                "type": {
                  "text": "void"
                }
              }
            }
          ]
        }
      ]
    }
  ]
}

Reproduction
have a private method in a class
Workaround
I will modify the generated manifest post-facto
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
"@lit-labs/analyzer": "^0.9.0",     "@lit-labs/gen-manifest": "^0.2.4",

Browser/OS/Node environment
Node 18.12.1

This is still relevant


[FABG-948] Add support for extra hosts at enrollment

Provide WithHosts option and add hosts to CSR info at enrollment request
This allows us to pass extra hosts for certificate enrollment, so it can be valid to
those hosts as well for its CN
Signed-off-by: Manoel<EMAIL_ADDRESS>

Pls run codecov again, test added for WithHosts

Integration tests are breaking, but I don't think it's a problem with the code itself, updating branch to see if it passes

@alikic any other changes?

Any updates on this issue?

Here is where we stand - the feature is useful, but the implementation has two issues. It introduces a third party dependency in the public API, and it is missing tests. It makes sense to group all parameters relevant to the creation of a CSR into a structure (perhaps initially having only hosts in the structure), which could be called CSRInfo, but no third party structures are allowed in the public API.

I'm going back to this issue, @alikic this test should be written in integration tests too, right?
On unit tests return is always empty for hosts entry on returned certificate.

Integration tests are broken again
updating with last master hope it fix

Done :)


Fix rubocop violations

Add a .rubocop.yml to the generator cookbook_files
Updated app generator to write out rubocop.yml
Updated cookbook generator to write out rubocop.yml
Added .rubocop.yml to chefignore
Fixed rubocop violation in Berksfile
Fixed rubocop violations in metadata.rb
Fixed rubocop violations in serverspec default_spec.rb
Fixed rubocop violations in chefspec default_spec.rb

Some notes:

The rubocop.yml is based mostly on the .rubocop.yml published by @someara in the chef-cookbooks/mysql and chef-cookbooks/httpd repos, as those seem to be a de facto standard. I added some stuff to get rid of specious violations in metadata.rb around column alignment and some warnings whose corrections would have made the spec tests less readable, but it's mostly the same. The important thing is to get something out there for people to argue about, we can always iterate.

'chef generate cookbook' and 'chef generate app' now make rubocop-clean output with this file.

I'm on the fence about adding the .rubocop.yml to 'chef generate repo.'  Seems like a good idea but also room for unintended consequences, so I didn't. Thoughts?

StringLiterals should also be turned off, as per https://github.com/bbatsov/rubocop/issues/520 even bbatsov recognizes that the community is split on this one, and I positively can't stand it.
Generally rubocop is going to be quite a bit of a bikeshed which is why we left it off initially I think

See #37 for other discussion.
Between the cops where Rubocop doesn't do the right thing (e.g. 'rescue Exception` followed by immediately re-raising the exception is perfectly valid), tries to engineer a brand new community standard where there isn't one (e.g. replacing 'raise' with 'fatal' because someone bbatsov is impressed with suggested it at one point), tries to engineer a standard that i'd argue goes against the community (e.g. suppressing trailing commas on multiline hashes and arrays), and just picks one side by default in a bikeshed war (StringLiterals), I don't think there's any way to arrive a decent consensus.

THE QUICKENING BEGINS. See, I like StringLiterals. Clearly we must fight with knives.
Persona bias right up front: I see lots of value in Rubocop, it definitely helped me level up a lot of my code as a sysadmin-turned-Chef.
In the absence of a defined style guide / standard for Ruby in general and Chef in particular, I agree that de facto solutions such as Rubocop can be aggravatingly fluid, misguided, and flat-out wrong. But also, right now CHEF has a small army of customer-facing engineers/consultants engaging with the community and preaching Rubocop as good practice for Chef code. We also ship the tool as part of the ChefDK. By having no .rubocop.yml in the generator, we're saying that Every. Single. Cop. is valid for Chef cookbooks, which I think we CAN agree is pretty much madness. If we're shipping Rubocop then some set of almost-sane defaults seems a reasonable thing to ship with it.
If people don't like those defaults, they can configure their own. That's why .rubocop.yml exists, along with custom generator support. Also, what we ship here can evolve over time.
Yes, there's probably no way to reach a happy consensus on this, but I think we can find a everyone-grumbles-about-it consensus. However, if we can't come to consensus, then perhaps another PR ripping out Rubocop completely is in order? What I don't want to see is that CHEF continues shipping it and preaching it, while also leaving it with insane defaults.

Yeah, but are we preaching it?  @sethvargo invented preaching about it in the chef community then backed way off after he felt they jumped the shark quite a bit.  I also think its got some utility, but it needs to be put onto a fairly tight leash.

SingleSpaceBeforeFirstArg needs to be off for providers/ and recipes/ as well, or else you can't justify you arguments together, which I definitely like to do:
file do
  owner "root"
  group "root"
  mode  "0644"
end

Having literally gone 360° on this, I agree with @lamont-granquist on this one. Let me elaborate...
It really boils down to this - at the end of the day Chef != Ruby. Sure, Chef is written in Ruby, but recipes are a highly specialized DSL that does not fit in the guise of standard Ruby programming.
At the end of the day, style is a team decision. As a single individual writing cookbooks, style matters not. Once I share the responsibility of that cookbook maintenance with my team, however, a style begins to emerge. This is highly variant based on the individuals involved, and it is also an evolving process - you don't just BOOM, style. The argument that open source cookbooks should follow a common style is also lost on me. Maintainers should totally decide the style that works best for their repos, but that's not Chef Software's decision to enforce tbh. If Sean wants to use Rubocop, that's great, but that doesn't mean every user should, or that every user should have the same set of rules either. Each project is unique and has its own style which is up to the maintainer(s) to enforce with whatever tools they please.
From a purely economic perspective, the cost-benefit-analysis does not pay off. "Errors" (if you can call them that) are confusing to new users. You are only increasing the already huge learning curve for Chef. You must learn x, y, z, and now w before you can write package "apache2". From Chef Software's perspective, go look at foodcritic. It's become a giant bikeshed because people are passionate about something that really doesn't matter. They waste valuable time and energy arguing over something that is ultimate insignificant, like using symbol keys in mashed. (You can argue that symbols are faster than strings because of GC, but when your CCR takes 30s, do you really notice the additional 0.0000052s incurred for the Ruby VM to throw some strings on the stack?) I think there are much bigger fish to fry (and much bigger engineering wins) than pointing sharp sticks at each other. To put it another way, I think @danielsdeleo, @lamont-granquist, et al's time is better spent making Chef(DK) a better experience than arguing with a vocal community member on single versus double quotes.
Introducing Rubocop to the Chef community is one of my biggest regrets. If I could go back and change it, I would. But I can't. So here we are. I would heavily discourage this addition.

So, TL;DR the solution to the problem is not to add a .rubocop.yml and expose the foundation of the largest bike shed construction of all time, but rather stop preaching about Rubocop. Sometimes the simpler solution is better, and I firmly believe this is one of those cases.

Yep, I'd prefer to see PRs that refactored code into tighter objects with better specs, which is 100x the payoff for a better codebase than style fixes.

If consensus is that the best way to make ChefDK awesome is to rip Rubocop out completely, I'm down. As I said, what I don't want to see is that CHEF continues shipping Rubocop and preaching it, while also leaving it with an insane set defaults.

Thing is that right now we just ship it, we don't wire it up in any way as far as I know, so its just there if you want to use it.  If you start using it, I think you inherently start needing to buy into maintaining your own .rubocop.yml file and that needs to go into your own custom generators.

I still believe rubocop is a helpful tool to allow teams to maintain some style consistency.  But I also agree that the style should reflect our Chef environment more so then a pure Ruby one.   I think it would be great to have ChefDK continue to include rubocop AND include an example rules file that focuses on the basic style most cookbooks already have (like the one above).

This is an illuminating thread, with lots of good discussion.
I feel pretty strongly that "do nothing" is a bad option.  "Here is a tool but the output is bonkers useless unless you write your own customized config dotfile in yaml, and locating the docs for that config file and determining its location in your project is left as an exercise to the user" is an even more lousy thing to say.
ChefDK's purpose is to give the user tools to be awesome at writing Chef code. By bundling Rubocop we're tacitly blessing it as a tool for that purpose. By bundling it without a .rubocop.yml in the generator, we're tacitly blessing Rubocop with AllCops enabled on every file. Which I think we all agree makes it useless out of the box.
So if we leave it in, then I think we have to have the bikeshed, and at least dictate some starting point for a community standard. And if we rip it out, then we don't have the bikeshed, but also we don't have the tool, and maybe that's okay? But I'd like to hear from more people on that one.
As to how widely it's used: CHEF currently teaches Rubocop as part of the Intermediate Chef training, so if we make this change then that will need revision as well.

Mark me down as a +1 for shipping rubocop + a curated .rubocop.yml.
The whole point of the DK is to put people in The Right Path (tm).
Having a tool that can do automated lint correction  (rubocop -a) is a
very powerful thing, and we should ship it.
[ "having"
, 'eleventy',
:billiion.to_s,
]
%w( syntactically valid ways) %w{to do a thing} is actually hostile to new
users, and anything that encourages standardization is a huge win in my
book.
The default rubocop rules are annoying, but there is a LOT of good stuff in
there.
Shipping a Chef Software Recommended starting rubocop.yml, with commented
links to the rubocop docs is a good way to not throw the baby out with the
bath water.
-s
On Tue, Feb 17, 2015 at 1:32 PM, Charles Johnson<EMAIL_ADDRESS>wrote:

This is an illuminating thread, with lots of good discussion.
I feel pretty strongly that "do nothing" is a bad option.  "Here is a
tool but the output is bonkers useless unless you write your own customized
config dotfile in yaml, and locating the docs for that config file and
determining its location in your project is left as an exercise to the
user" is an even more lousy thing to say.
ChefDK's purpose is to give the user tools to be awesome at writing Chef
code. By bundling Rubocop we're tacitly blessing it as a tool for that
purpose. By bundling it without a .rubocop.yml in the generator, we're
tacitly blessing Rubocop with AllCops enabled on every file. Which I think
we all agree makes it useless out of the box.
So if we leave it in, then I think we have to have the bikeshed, and at
least dictate some starting point for a community standard. And if we rip
it out, then we don't have the bikeshed, but also we don't have the tool,
and maybe that's okay? But I'd like to hear from more people on that one.
As to how widely it's used: CHEF currently teaches Rubocop as part of the
Intermediate Chef training, so if we make this change then that will need
revision as well.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef-dk/pull/320#issuecomment-74723054.

I just don't see how shipping rubocop without any wiring at all is tacitly blessing all cops.
Also WRT this statement: "Here is a tool but the output is bonkers unless you write your own customized config dotfile in yaml, and locating the docs for that config file and determining its location in your project is left as an exercise to the user"
That is exactly what you've got now when you gem install rubocop.   That feels like a statement of fact about the way the world is.  They didn't write rubocop to be minimally invasive and generally correct out of the box and instead wrote it with a ton of opinions so to make it usable you have to turn them off.   Yet some people may like all the cops being turned on as well (I know there's arguments on twitter suggesting exactly that).

And when it comes to %w{} vs %w() I've been doing it the former for years and don't buy bbatsov's argument that I need to change (I don't think dan does either).

I fail to see how pasting around a 50+ line YAML file to every cookbook (and then changing that YAML file each time rubocop decides to include another rule) is a productive use of anyone's time.
The simple fact is that it really doesn't matter. We should be encouraging users to pick a style of their choosing. You have to write recipes this way seems to go against the original founding principles of Chef.

CHEF promises paying customers contractual support for all things in the package. Thus all of the things that are included in the ChefDK package are blessed by sheer virtue of that inclusion. In addition, nothing has been explicitly wired together in the ChefDK, so that would imply that none of the package contents are blessed at all.
Providing a standard is not the same as telling people they have to do things a certain way. CHEF advocated for single repository development for years before Berks came along and blew that up. Standards provide guidance, and a point to argue with if that guidance is not positive. Standards can evolve.
Plus there's already a standard for Rubocop defined in the ChefDK, and that standard is "use Rubocop with AllCops," which I think is confusing, harmful, and should not remain. Thus this thread.
(I'm intentionally ignoring syntax/style arguments for a moment. I'd rather focus on "should we include Rubocop at all" as the question.)

should we include Rubocop at all?

No. My vote is a very hard "no".

This less about the "philosophy of freedom" than it is about "the reality
of chaos".
It really boils down to two questions:
Do we lose anything by shipping a .rubocop.yml in the default generator?
Do we win anything by shipping a .rubocop.yml in the default generator?
Losses:

Having to curate the default rules over time, dealing with ridiculous
rules as they appear.
A loss of "git blame" value in the face of "rubocop -a" commits

Wins:

Automated(!!) standardization of style across codebases. (tabs/spaces,
whitespace, strings, symbols)
Less explaining to do around Ruby syntax TMTOWTDI
Easy stepping stone to cookbook testing (Foodcritic provides this too)

My view on this is colored by spending large amounts of time dealing with
other people's code AND dealing with new users.
-s
On Tue, Feb 17, 2015 at 2:35 PM, Seth Vargo<EMAIL_ADDRESS>wrote:

I fail to see how pasting around a 50+ line YAML file to every cookbook
(and then changing that YAML file each time rubocop decides to include
another rule) is a productive use of anyone's time.
The simple fact is that it really doesn't matter. We should be
encouraging users to pick a style of their choosing. You have to write
recipes this way seems to go against the original founding principles of
Chef.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef-dk/pull/320#issuecomment-74736177.

Personally, I'd be quite receptive to an outcome where we could say "some teams find enforcement of style rules to be a useful process to improve code readability within/across working groups. If you'd like to opt-in, Here's a set of sane defaults you can easily tailor to your needs. And we have a sane way of upgrading this component without causing a bunch of test failures or maintenance hassles." I don't think we can do this with rubocop because:

Making style stuff opt-in not really a problem, but isn't in this PR as written.
There is no consensus on what a sane set of defaults is for rubocop.
The generator cookbooks aren't very pluggable at the moment, you have to fork the whole thing to customize rubocop rules (which is what you'd need to do to add rubocop if we didn't provide it out of the box).
Rubocop is a compatibility disaster. Each new version adds a bunch of checks that make your existing code fail the style checks. The only way to deal with this is to strictly version rubocop with the codebase you run it against or have some way that your team manages the global version you use everywhere. The only reasonable way to version it with your code is to use bundler. For the second option, we could say "you get the version in ChefDK and we don't consider upgrading it a compatibility breakage." But that's a pretty frustrating user experience. People are going to want "no rubocop updates before Christmas because the team is too busy" or whatever.
Problem (4) is exacerbated by the fact that Rubocop is configured on a per-project basis, so if you upgrade the version in use globally, you potentially have to modify N config files.

I still fail to understand how shipping rubocop installed but without any default wiring becomes a 'standard'.
However, given that, then I'm in agreement with dan and seth that it simply needs to get dropped and users need to chef gem install or bundle install the exact version they desire.

+1 on dropping if we're not going to ship sane defaults
-s
On Tue, Feb 17, 2015 at 4:16 PM, Lamont Granquist<EMAIL_ADDRESS>wrote:

I still fail to understand how shipping rubocop installed but without any
default wiring becomes a 'standard'.
However, given that, then I'm in agreement with dan and seth that it
simply needs to get dropped and users need to chef gem install or bundle
install the exact version they desire.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef-dk/pull/320#issuecomment-74755355.

Is there another ruby-level linter that allows for rule whitelisting vs
Rubocop's rule blacklisting model?
On Tue, Feb 17, 2015 at 5:02 PM, Sean OMeara<EMAIL_ADDRESS>wrote:

+1 on dropping if we're not going to ship sane defaults
-s
On Tue, Feb 17, 2015 at 4:16 PM, Lamont Granquist <
<EMAIL_ADDRESS>wrote:

I still fail to understand how shipping rubocop installed but without any
default wiring becomes a 'standard'.
However, given that, then I'm in agreement with dan and seth that it
simply needs to get dropped and users need to chef gem install or bundle
install the exact version they desire.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef-dk/pull/320#issuecomment-74755355.

+1 here for keeping Rubocop and providing sane defaults as well, in case that's not clear by the PR itself. The counter-arguments are compelling but it still seems a least-worst option.

+1 for keeping rubocop (convenient to have tools available) ...as for providing defaults, that's nice but not necessary.

+1 from me on sane default.

I know everyone wants a sane default, I do, too. But again, I don't have the slightest idea how that's possible with rubocop without significant downside:

We just never upgrade it until the end of time, so that the good defaults we pick today are good forever.
Or accept that every rubocop upgrade could have a terrible UX, because the sane defaults changed in response to some new rubocop rule so you have to apply the new sane defaults to every cookbook you have (also you have to preserve users customizations somehow).
Or go back to using bundler for everything and every cookbook can use whatever version of rubocop it wants to pin. But then it doesn't need to be in ChefDK because you're gonna bundle install it.

I'm with you Dan. For example, some time ago the name of the 'todo' file changed.
The generated .rubocop.yml doesn't need to have all of the rules activated, they can (and perhaps should) all be there commented out. Just having the scaffolding is a great step forward with much less overhead.
# inherit_from: .rubocop_todo.yml
# LineLength:
#   Max: 200
# etc...

Just ran across someone wrapping rubocop into their own gem with their own default style:
https://github.com/reevoo/reevoocop

Out in the field, working with Chef newbies (who are also Ruby newbies), I've been finding a lot of value with Rubocop. As @charlesjohnson mentioned, it has personally helped ME level up my Ruby as a non-coder, which a lot of our customers are. When I teach a POC to a group, I always use Rubocop (after giving them my own .rubocop.yml, which I stole from @charlesjohnson who I think stole it from @someara). I can see how this seems redundant or inappropriate for deep Chefs, who already are good at this stuff, or for a team that is already working. But for the "we are just getting started", everything we can do to make it easier and cleaner helps them move faster.
So I'm +1 for still shipping Rubocopy with the DK, but with at least a base .rubocop.yml that removes some of the more useless cops.

My suggestion:
Use rubocop --lint - so it only does lint checking and doesn't do any style checking, since there isn't even a single style guide for the community, and so many people disagree with the defaults in rubocop (hence the above discussion).

RuboCop helps people learn Ruby, and makes folks who are new to the ecosystem happier writing code. Happy coders make happy code.
Iterating a cop towards the most readable standard should be part of the journey. Everyone out there in the community has varying degrees of experience, and varying levels of success at achieving their goals from month to month. Really good teams are rare, and they don't really last that long. There's a reason why Times New Roman looks the way it does, and Helvetica looks the way it does. Readable code is more readable, and there are multiple contexts for readability.
I advocate starting with more firm rules, and relaxing or altering them over time as needed. Starting with a style guide is certainly better than none and will result in more readable code, which means fewer errors over time.

The --lint checks are the ones that actually raise red flags to programming errors.  The use of %w{} vs. %w() is just a bikeshed that doesn't catch any programming errors.  And the most useful errors to fix aren't going to be pointed out by static analysis -- if rubocop could turn someone into a software developer that'd be great, but its slightly more involved than that.

A little bike shedding can be a good thing.
%w(this works)
%w{this works}
%w[this works]
%w[this works]
%w|this works|
%w$ this works $
%w^ this works^
%w! this works !
-s
On Mon, Mar 2, 2015 at 11:55 PM, Lamont Granquist<EMAIL_ADDRESS>wrote:

The --lint checks are the ones that actually raise red flags to
programming errors. The use of %w{} vs. %w() is just a bikeshed that
doesn't catch any programming errors. And the most useful errors to fix
aren't going to be pointed out by static analysis -- if rubocop could turn
someone into a software developer that'd be great, but its slightly more
involved than that.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef-dk/pull/320#issuecomment-76887195.

It seems like rubocop can now run in an opt-in mode if you use configuration like this:
AllCops:
  DisabledByDefault: true

cf. https://github.com/bbatsov/rubocop/blob/master/README.md#enabled
So I think we can now actually make progress on this and have a default config that won't break the universe on every rubocop upgrade. This solves my number one objection to rubocop. I would be happy with a config that makes all the rules opt-in and does not enable the bike shed garbage rules. And for the love of all that is good, never enable the string literal thing.

Turning off all cops by default doesn't see ideal as it disables the lint cops which are very useful and catch many code errors. The best long term solution is a shipping a "chefstyle" wrapper for RuboCop that works very similar to https://github.com/fnichol/finstyle. I believe at the community summit hack day @fnichol and @robbkidd began scheming on some ideas for this one.
It would be nice to have 2 sane sets of rules:

one set for validating Chef's various Ruby projects
one set for validating cookbooks. This would also allow us to begin deprecating Foodcritic...any Foodcritic rules that should be preserved can be recreated as custom RuboCop cops.

A final thought - we should listen to the words of wisdom from our community, customers and Chef's customer facing teams: most new Chef users find a lot of value in RuboCop (even with its warts). Project maintainers and more experienced users also benefit from allowing a tool to tell new contributors when their code is not up to par! Code style and consistency is important.

My point is you disable everything, then enable a set of things that are actually good (personally, the lint rules are the only ones I actually like). It'll probably make the rubocop yaml pretty big, but the benefit is that when a new version of rubocop comes out, it doesn't enable a bunch of new rules that fail your previously passing builds. Thus we can actually use rubocop as part of a stable project that people can upgrade with confidence. The opt-out mode of configuration is not acceptable because new rules can fail your builds on upgrade, which is not acceptable for stable software.

me and @thommay are also talking about a 'chefstyle' for chef/chef at some point, and @tas50 was interested in a chefcop for cookbook style, which would be the thing i'd suggest shipping with chef-dk since it would be tuned for cookbooks and not for chef/chef.

Yeah, as Lamont said we were discussing chefstyle and chefcop; if we can start from everything disabled and build up incrementally that seems like goodness.

With the addition of opt-in configuration mode, I think we can get pretty close to optimal with rubocop. Things that I predict would still be less-than-perfect:

Have to be very clear that we're only supporting rubocop with our config, and if you disable the opt-in mode you're on your own for dealing with breakages caused by upgrades.
With opt-in mode, it looks like we have to enable every rule individually, so the generated rubocop config would be pretty big, and we'd probably have to include commented out sections for all the rules we're disabling. Users who like the bikeshed parts of rubocop probably would need to use custom generators or do a lot of fiddling.
Rubocop's config search doesn't match ChefDK/knife
probably more stuff that I can't anticipate in advance

Despite that, at this point I think it's still a win to start by putting a rubocop config in the generators, so we can avoid issues like https://github.com/chef/chef-dk/issues/611

Yeah the problems with the massive config file is what leads me to want to bundle that up in a gem and ship it as chefcop so that users don't see a default 8,000-line long .rubocop.yml generated in every cookbook...

Can this get closed now that we have chefcop applied to both chef and ohai. A new PR applying chefcop here seems like it would make more sense.  Ping Mr. Rubocop @lamont-granquist

@tas50 So this ticket is mostly about making our generated cookbooks (and Berksfile and Policyfile.rb files) rubocop-valid. I had thought we settled on making two rubocop derivatives--one for our ruby applications (which is chefstyle) and another one with our minimum recommended set of rules for cookbooks and such (not started AFAIK). Now that we have chefstyle we should be able to take a quick look to see if we think it's a thing we'd recommend to users for the latter case and re-evaluate that plan.
In either case we'd need to do at least a little more work, so this isn't done. But maybe we replace it with a new ticket or a feedback.chef.io thing? I don't have strong opinions on how we track it.

So, chefstyle is still about our code, not user code, and that isn't going to change for awhile, its still not done.  It would probably be better to fork off a cookstyle or just chefcop that was recommended rulesets for cookbooks.
Here's the TODO list for chefstyle right now (these are offenses which chefstyle disables by default but we haven't made a decision on if or how to enable):
5502   Style/HashSyntax
963    Style/BracesAroundHashParameters
749    Style/BlockDelimiters
695    Style/AlignParameters
425    Style/DotPosition
281    Style/LeadingCommentSpace
196    Style/MethodCallParentheses
185    Style/DeprecatedHashMethods
183    Style/EmptyLiteral
180    Lint/UselessAssignment
164    Style/AndOr
161    Style/RegexpLiteral
159    Lint/DeprecatedClassMethods
153    Style/RedundantSelf
152    Style/NegatedIf
140    Style/PerlBackrefs
130    Style/SymbolProc
128    Style/ClassCheck
120    Style/Alias
111    Style/ClassAndModuleChildren
110    Style/StringLiteralsInInterpolation
106    Style/MutableConstant
99     Style/CommentIndentation
98     Lint/ParenthesesAsGroupedExpression
95     Style/ConditionalAssignment
93     Style/LineEndConcatenation
89     Style/RedundantReturn
87     Style/AlignArray
84     Style/NumericLiterals
82     Lint/AmbiguousRegexpLiteral
79     Style/Lambda
74     Style/GuardClause
74     Style/ZeroLengthPredicate
73     Lint/AssignmentInCondition
72     Style/UnneededInterpolation
71     Style/RedundantBegin
70     Style/NestedParenthesizedCalls
70     Style/Semicolon
66     Style/MultilineBlockLayout
63     Style/MethodName
63     Style/SpecialGlobalVars
60     Style/BarePercentLiterals
60     Style/ParallelAssignment
53     Style/PredicateName
52     Style/BlockComments
52     Style/UnneededPercentQ
50     Style/IndentArray
48     Style/AccessorMethodName
47     Style/Proc
45     Style/BlockEndNewline
45     Style/CommentAnnotation
43     Style/EachWithObject
39     Style/RaiseArgs
38     Style/Next
37     Style/RedundantParentheses
30     Style/CaseEquality
30     Style/GlobalVars
30     Style/IdenticalConditionalBranches
28     Style/IfInsideElse
27     Performance/RedundantBlockCall
27     Style/ClassVars
27     Style/EmptyElse
27     Style/FirstParameterIndentation
27     Style/SpaceAfterNot
26     Style/UnlessElse
25     Style/ClassAndModuleCamelCase
25     Style/SingleLineMethods
19     Lint/IneffectiveAccessModifier
18     Performance/Detect
18     Performance/StringReplacement
18     Style/Not
17     Style/ClosingParenthesisIndentation
17     Style/SpaceBeforeComma
16     Style/CaseIndentation
15     Lint/ShadowingOuterLocalVariable
15     Style/SingleLineBlockParams
14     Style/SpaceBeforeSemicolon
12     Style/NilComparison
12     Style/VariableInterpolation
11     Style/DefWithParentheses
10     Style/ModuleFunction
9      Lint/UselessAccessModifier
9      Lint/Void
8      Style/AccessModifierIndentation
8      Style/MultilineTernaryOperator
8      Style/NonNilCheck
8      Style/RedundantException
8      Style/SpaceInsideStringInterpolation
8      Style/WhileUntilModifier
7      Style/ConstantName
7      Style/RescueModifier
7      Style/SelfAssignment
7      Style/SpaceAfterSemicolon
6      Lint/Eval
6      Lint/NestedMethodDefinition
6      Performance/Casecmp
6      Performance/RedundantMatch
6      Style/AsciiComments
6      Style/MultilineIfThen
6      Style/MultilineMethodCallIndentation
6      Style/OpMethod
5      Performance/RedundantMerge
5      Style/FileName
4      Lint/UnderscorePrefixedVariableName
4      Style/IndentAssignment
4      Style/SpaceBeforeComment
3      Style/MultilineBlockChain
2      Performance/TimesMap
2      Style/VariableName
1      Performance/Count
1      Performance/RangeInclude
1      Style/OptionalArguments
1      Style/StructInheritance

for future posterity, we went with cookstyle:
https://github.com/chef/cookstyle
it is for cookbook usage.  the similar 'chefstyle' gem is for chef/chef and related ruby code.


anchorPoints doesn't seem to work for combos.

G6 Version: 3.6.0
Platform: MacOS
Mini Showcase(like screenshots):
CodePen Link: Link

Can we control the start and end of the edges for combos?
As anchorPoints doesn't seems to work for the combos. When we collapse the combos the start of the edges doesn't follow  the anchorPoints. Any suggestions or solutions to achieve the same?

Try to set the sourceAnchor and targetAnchor for defaultEdge


Windows manage script use correct quotes

Description
Use correct quote characters. For some reason were not used correct quotes in manage script.

Using MS Word as an IDE again? :D


Add x-bit to all files with shebangs

Changes the file mode to 755 for all files with shebang lines. This is very helpful on posix systems.

thanks merged in pr


AS400 Support

I added as400 support classes.
These classes were based on the DB2 classes with modifications for the way catalogs are managed.

Thanks. As I don't have an AS400 available for testing, would you be willing to support this in the future, should issues come up?
Also could you please submit a pull request against the flyway-4.0 branch of flyway/flywaydb.org with a DB-specific page (like http://flywaydb.org/documentation/database/oracle.html)?
Then we should be good for a speedy merge.
Cheers
Axel

Any news?

I missed your previous message as I was on leave at the time.
Getting back into things and would probably not get to this in the next few
weeks.
[image: --]
Corneil du Plessis
[image: https://]about.me/corneil
https://about.me/corneil?promo=email_sig
On 27 October 2015 at 12:43, Axel Fontaine<EMAIL_ADDRESS>wrote:

Any news?
—
Reply to this email directly or view it on GitHub
https://github.com/flyway/flyway/pull/1034#issuecomment-151452850.

Closing as we have no plans to add this, as we won't have access to an AS400 for testing in the foreseeable future.


Editor slowdown when resolving due to translations in assertions

Describe the bug
For the game I work on, I decided on using Dialogue Manager to help me do the variable substitutions in parts of my UI.
For this, I passed the parser a line, and then passed the result to create a DialogueLine:
var parse_result: DialogueManagerParseResult = DialogueManagerParser.parse_string(": {entry_hint} [ID:hint_{id}]".format({"entry_hint": tr(entry.hint, &"galleries.images.hints"), "id": entry.cg_resource_uri}), "")
var line: DialogueLine = await DialogueManager.create_dialogue_line(parse_result.lines["1"], [])

This is done for a UI with a 4x3 grid, so 12 calls are done per page.
However when changing the page, there is a big hiccup which seems to be of about 300ms, due to the DialogueConstants.translate calls:

It seems that when using a debug run, the DialogueConstants.translate calls within the 6 assert(limit < 1000, translate(xxx)) are done, and due to the way the function works, it slows down the game.
I suspect this also may slow down the editor when using the plugin normally.

Affected version

Dialogue Manager version: v2.32.2
Godot version: v4.2.1.stable.custom_build [b09f793f5] (Godot 4.2.1, but with the Esoterics Software Spine plugin)

Hardware: i5-12600K, 16GB RAM, RX 6900 XT, 2TB PCIe 4 NVMe SSD

To Reproduce
Make a new project, ask the parser to parse a string on the fly, then create the DialogueLine associated with it and run it with in debug mode:
var parse_result: DialogueManagerParseResult = DialogueManagerParser.parse_string(": Some string [ID:some_line_id]", "")
var line: DialogueLine = await DialogueManager.create_dialogue_line(parse_result.lines["1"], [])

The more calls are done like this, the worst the issue becomes, due to the 6 assert calls that are done to see if something went wrong, and the hard loop limits are reached.

Expected behavior
One of the following:

Improve the way the translate function is to make use of some sort of cache, and speed it up ;
The translate call is evaluated only when needed, which would make writing ifs around the assert()s the easiest solution.

If you would like me to make a PR, just tell me which route you'd like to take :) for the time being I'll add ifs around the assert()s so I no longer have the 300ms hiccups :)

I wasn't able to replicate the slowdown that you're experiencing but I have moved all runtime asserts to be behind conditional checks to stop early evaluation of the message expressions.
I'd also suggest you use Expressions for evaluating stuff instead of trying to parse individual lines with Dialogue Manager.


fix: Updated umbraco-package JS path to work on case-sensitive systems.

Issue
The "js" file path entry for umbraco-package.json in the Umbraco.Community.BlockPreview.UI project has mismatching casing when compared to the actual folder path. This breaks on case-sensitive operating systems.
Fix
The file path has been updated to match the casing of the folder path. This should now be working as expected, tested via Ubuntu WSL.
Fixes #68

Thank you for all your hard work on this package @kevin9092!


Improve messages displayed during item & spell import

Display messages during the spell and item data download phases.
Display messages during the spell and item data filtering phases.

Thanks!

Close function calls/fix linting.


soc: xilinx_zynq7000: fix VBAR, SCTLR contents when coming from u-boot

If a Zephyr binary is booted on the Zynq-7000 not via JTAG download,
but via u-boot's ELF boot function instead, Zephyr will have to revert
certain changes made by u-boot in order to boot properly:

clear the ICache/DCache enable, branch prediction enable and
strict alignment enforcement enable bits in the SCTLR register.
By default, u-boot will also set up the MMU prior to Zephyr
doing so as well, this can be avoided by changing the u-boot
build configuration. Therefore, the MMU enable bit is not changed
at this point.

set the VBAR register to 0. U-boot moves the interrupt vector
table to a non-standard location using the VBAR register (no
change is made by u-boot for SCTLR.V, only VBAR is changed
to a non-zero memory location).

Without these changes, Zephyr will crash upon the first context
switch at latest, when SVC is invoked and u-boot's vector table
is used rather than the vectors copied to address zero by Zephyr.
In order to perform these changes before coming anywhere near the
MMU / device driver / kernel initialization stages or even the
first context switch, the z_arm_platform_init hook is used, which
is now enabled for the Zynq via the Kconfig.defconfig file.
Signed-off-by: Immo Birnbaum<EMAIL_ADDRESS>

Maybe U-boot needs something like this: https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/Kconfig#L146

Usually this is something that should be taken care of on the U-Boot side. For some ARM64 boards this is done at U-Boot level, see for example: https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm64/imx8mm_evk/doc/index.rst
Anyway, this is fine if for whatever reason this is not possible on the U-Boot side.

@ibirnbaum looks like this needs a rebase

@ibirnbaum looks like this needs a rebase

@mbolivar-nordic Thanks for the hint, looks like while this PR was on the home stretch, I fooled myself with #44865...

@wmamills FYI

@carlocaione As with QEMU, Xilinx has chosen to maintain their own fork of u-boot, so some features might be missing on the Zynq... Yet, the command-line based dcache/icache disable that you mentioned are there, but there's neither a console command nor a build option that will change how u-boot works with VBAR. In the Xilinx u-boot source tree, there's only a single board made by B&R where VBAR is modified prior to booting the OS as the board is obviously intended to run VxWorks, which expects the vectors at a certain location. Are you aware if VBAR or its ARMv8 equivalent is modified by u-boot at all on boards like the one you mentioned, so that the cache-related disable commands on the boot command line are sufficient to boot Zephyr?

Just for clarity this is Zynq7000 only.  Ie the Dual A9 version.  Correct?
The comments talking about Armv8 are confusing me.

The comments talking about Armv8 are confusing me.

We are just comparing solutions between the two archs for the same problem, nothing more than that.


input.match is not a function

isValid command comes up with input.match is not a function

how u fixed that?


egressgw: test: switch to WaitForEgressPolicyEntries

To wait for a CiliumEgressGatewayPolicy to be effective in a ginkgo test
suite, we rely on the WaitForEgressPolicyEntry helper, which lists the
entries in the bpf egress policy map and makes sure that at least one
entry matches the k8s3 node IP (as that's used as destination CIDR in
one of the policies).
This is not optimal as matching that IP doesn't guarantee that the full
policy/all policies are effective.
With this commit, instead of looking for a particular IP, we just count
the number of entries, since, given a policies manifest, it's easy to
determine how many entries we should expect in the bpf map.

/test-only --focus="K8sDatapathEgressGatewayTest.*" --k8s_version=1.26 --kernel_version=net-next

/test-only --focus="K8sDatapathEgressGatewayTest.*" --k8s_version=1.26 --kernel_version=net-next

No code changes, CI was green, marking as ready


Creating and updating cluster doesn't give user enough feedback

While updating the runtime specs of a cluster, I clicked to open a notebook. The opening page stuck around for so long that I thought it had failed, but a few minutes later the notebook opened. I think that we should give more feedback to the user (animations, etc) to let them know that their notebook is actually opening.

No longer an issue now that #589 makes the notebook load much faster

I think this is still a problem when a user is trying to open a notebook and they are waiting 5+ minutes for their cluster to start. The user does not know that the cluster is still starting, and it looks like the page has frozen. I think that some kind of animation would be helpful in telling the user that the app has not crashed and that they just need to wait a little longer.
Illumina example:

Can we distinguish runtime creation from runtime start, and include an explicit message:

that this can take 5-7 minutes
that the user can nav away and come back once their runtime is in status 'running'

Is the spinner sufficiently animated to convey "we're not dead here"


Fix incorrectly reported width when measuring lines

This commit fixes what seems to be a bug in Chromium. Fixes #9382.
Before:

After:

When measuring lines (and with a special character sequence), it could happen
that Range(0, 0). getBoundingClientRect().width reports a number greater than 0.
This seems to happen when the font size is smaller than 12px and it's probably
due to subpixel font scaling. To solve it we've explicitly included a guard
clause that prevents this problem to happen.
/cc: @nathansobo @50Wliu @thomasjo @atom/feedback  for :eyes:

@as-cii Does this affect beta or stable?

I think it affects stable, as it's most likely related to the enablement of subpixel font-scaling.

For posterity, after double checking this we've concluded this affects only beta and not stable.


Implement worker-EDM interface tests (multi worker, multi channel, workers per channel varies)

This is happening organically as we add more ccl ops/variants. Closing this as it's largely redundant.


ci: use current node.js versions in matrix build

Issue
The Node.js versions used in the matrix of .github/workflows/ci.yml are no longer aligned with versions of Node.js shown as active under the Node.js release schedule:

Node.js version
Status

19.x
End-of-life Jun 1, 2023

22.x
Released Apr 24, 2024

23.x
Released Oct 15, 2024

Change
In .github/workflows/ci.yml make the following changes to the node-version matrix:

Node.js version
Change

19
Drop

22
Add

23
Add

@tcort
I tested the workflow in my fork and it ran successfully with the updated set of Node.js versions.


TypeError: cannot serialize '_io.BufferedReader' object

demo.ipynb
trainer.train(batch_size=8,
epochs=20)
TypeError: cannot serialize '_io.BufferedReader' object

Would you comment out the line 58 of wavenet_training.py?
In my case,
    self.dataloader = torch.utils.data.DataLoader(self.dataset,
                                                  batch_size=batch_size,
                                                  shuffle=True,
                                                  # num_workers=8,
                                                  pin_memory=False)

commenting out the "num_workers=8" has made progress.


Can we upgrade xml-encryption to "xml-encryption": "~0.7"?

Currently, set at ~0.3.4.  The new version supports a few more encryption/decryption That library supports a few more encryption/decryption algorithms.

Done.


[MINOR][ML][TESTS] Increase tolerance to make NaiveBayesSuite more robust

What changes were proposed in this pull request?
Increase the rel tol from 0.2 to 0.35.
Why are the changes needed?
Fix flaky test
Does this PR introduce any user-facing change?
No
How was this patch tested?
UT.

Test build #135073 has started for PR 31536 at commit 6678916.

Merged to master, branch-3.1 and branch-3.0.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39655/

Test build #135073 has finished for PR 31536 at commit 6678916.

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

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39655/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39655/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135073/

https://github.com/apache/spark/runs/5729445588
https://github.com/apache/spark/runs/5707208835

This seems still flaky .. can we increase the tolerance a bit more?


Compatibility with Swift 2.0

Mostly resolves warnings related to unnecessary variable declarations (that are now changed to constants). Some syntax for named parameters has also changed.

When is this one going to be merged?


Handling long filenames with preview

Hello,
When file name is a bit long it can cut off symbol searches. See screenshot.

Any ideas on how to handle this better? I'd like to see the symbols all the time regardless of the length of the filepath.

This behavior is controlled by fzf, perhaps there is an fzf flag to disable this?
Otherwise I’d have to shorten the file names and then try to expand them again on preview/selection, too much work for this minor inconvenience honestly.

Didn’t try it but how does this behave?
lsp_workspace_symbols({ fzf_opts = { ['—keep-right'] = '' } })

@ibhagwan that fails to open the fzf dialogue.
I understand this is minor. Curious if placing the preview window always on the bottom is the easy solution?

@ibhagwan that fails to open the fzf dialogue.

That's because I posted from mobile and the -- turned out to be something else, just tried this and it does the job:
:lua require('fzf-lua').lsp_workspace_symbols({ fzf_opts = { ['--keep-right'] = '' } })

I understand this is minor. Curious if placing the preview window always on the bottom is the easy solution?

You could easily do that by sending preview_layout = 'vertical', that will force the previewer to be at the bottom (flexible is controlled by nvim width).

Okay, I think this is a fine solution. Unless there is a way to use "flex" and have it take path length into account?

Okay, I think this is a fine solution. Unless there is a way to use "flex" and have it take path length into account?

That can be done but IMO it's a very non-intuitive behavior, plus I'll have to delay rendering until all entries are displayed as I'd have to check first that the longest entry isn't longer than a certain length, causing a UI hang until all lines are rendered, or alternatively triggering a layout change mid way, far from optimal.
I think the --keep-right does the job no?

better, but always vertical is better. Here is screenshot with --keep-right

I see, seems functional enough.

Btw, I noticed you’re using bat previewer, out of curiosity, do you prefer that to the built in?

@ibhagwan I don't really know the difference between them. Is there a reason to prefer the built in?

@ibhagwan I don't really know the difference between them. Is there a reason to prefer the built in?

The main reason would be treesitter highlights, the syntax highlighting would be done by nvim and match your current color scheme other than using the bat color scheme.
in addition it as the ability to expand to max size by pressing (default bind F2).

thanks! just switched over and everything works great. Having the preview match my theme is much better.

thanks! just switched over and everything works great. Having the preview match my theme is much better.

Great! Forgot to mention you also get the benefit of highlighting the exact column where the match hits (not just the line), if you’d like to change these colors look for hl_cursor and hl_cursorline under previewers.builltin.

FYI, incase you're interested the last few commits added new functionalities that would help you with the above issue in an indirect manner.
The new functionalities enable you to do 2 things:

Toggle the preview window and fzf window fullscreen
Rotate the preview window clockwise/counter-clockwise

So if you prefer you can stay in horizontal layout and when the lines are long and require more screen real-estate you can rotate it clockwise (<F6> by default) to switch the preview up (or <F5> to switch the preview down).
Note that if you wish to changes those, the keybinds were migrated and are now specified in keymap.builtin (instead of previewers.builtin.keymap).

This is great. The rotate functionality will work for m issue.


..?

i didn't touch the thing, but for some reason the repo test failed...? apparently the css was incorrect, but it's valid.
Please check if what you want to add to beautiful-discord-community/resources list meets quality standards before sending pull request. Thanks!
Please provide package links to:

github.com repo:
embed url:

Make sure that you've checked the boxes below before you submit PR:

[x] I have added my package in alphabetical order
[ ] I know that this package was not listed before
[x] I have added @import compatible link (ex. rawgit.com) to the repo and to my pull request
[x] I have read Contribution guidelines.

Thanks for your PR, you're awesome! :+1:

Still failing the test, sorry 😓 , I can't accept the PR till it passes.
(no like literally, I cant, the button is greyed out)

Zeta fix the build 👀

No wait the CSS is legit broken

Apparently..
   content:"	";

Thank you! For some reason the script thinks it's invalid.

Is there a way to make the check "not required?"

fix ur shite

this is a travesty

I can't fix it, @TheBITLINK. It's something strange with the test, thinking that a quote is unclosed.

If we accept with a check on this future PRs will fail on it

I don't know, you'll have to fix it.

@LewisTehMinerz can't you just remove whatever symbol you used here?
content:"	";

Or just use multiple spaces, idk

This has dragged on for longer then I would've liked it, please open a PR when you fix the issue.


Unable to type amount more than 1 digit

Hi, thank you for developing a new app for firefly III
I tried to use it and add a transaction but I cannot input amount larger than 1 digit.
I don't know if it is due to my default currency or not (NTD) maybe it is a custom currency I added I don't remember.
Here is a video to show what I mean.
https://github.com/dreautall/waterfly-iii/assets/22869682/ef23b632-746e-4e0f-8493-383465a817c1

The only thing that is uncommon with this currency is that it has no decimal digits.
I guess this must be where the problem comes from.


fix: re create README.md

Description
Since README.md was deleted in the previous merge, it is prepared again.

Closes #0
Types of changes

[ ] Bug fix (changes which fixes an issue)
[ ] New feature (changes which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] ETC (build, ci, docs, perf, refactor, style, test)

Checklist

[ ] I followed the contributing guidelines.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] The PR title and commits are followed conventional commit form.

The CI failure is fixed in https://github.com/line/cosmwasm/pull/203


Not able to send mail from Node Mailer

I am trying to send mail through nodemailer in my node js application. when i send mail via gmail services it works fine but when i use some smtp server to send message some error occured "dh key is too small". interesting thing is when i send mail using same configuration from windows server mail sending is working flawlessly. but when i try to send via ubuntu using same configuration same message occur "dh key is too small". here is my configuration
var smtpTransport = nodemailer.createTransport({
host: "mail.XXXX.com", // hostname
secureConnection: false, // use SSL
port:"XX",
auth: {
user<EMAIL_ADDRESS>pass: "XXXX"
}
});
The same code is working when I am using windows machine but not on Ubuntu

This is probably an issue with openssl. You should try to upgrade Node.js on your ubuntu box to get the latest openssl bindings.


Invalid artifact groupId

Maven groupIds must not contain slashes, so using this from Maven/Java as currently hosted on Bintray requires some hacking. github.com/TanUkkii007 should ideally be changed to com.github.TanUkkii007.

Thanks for letting me know.
I confirmed Maven naming conventions.
https://maven.apache.org/guides/mini/guide-naming-conventions.html
I will fix as you suggested.


[IMPROVEMENT] Update nginx.conf

In raising this pull request, I confirm the following (please check boxes):

[x] I have read and understood the contributing guidelines?
[x] I have checked that another pull request for this purpose does not exist.
[x] I have considered, and confirmed that this submission will be valuable to others.
[x] Do the TravisCI tests pass?
[x] Does the StyleCI test pass?

Description of change
Add comment in nginx example about websockets and https

Current coverage is 8.65% (diff: 100%)

Merging #304 into master will not change coverage

@@            master      #304   diff @@
========================================
  Files          103       103
  Lines         2021      2021
  Methods        353       353
  Messages         0         0
  Branches         0         0
========================================
  Hits           175       175
  Misses        1846      1846
  Partials         0         0

Powered by Codecov. Last update 81007fe...811325a


All Hex colors to variables

https://github.com/Herm71/hds-storefront-child/blob/c61e90faa6fe168c82e5e6c033f8d8e3cca8deea/TODOS.md#L6-L6

this can be changed via the customizer. Closing.


RHIROS-928| Exclusion filter for RHEL 7 systems - psi-enabled-count

Changes:

Added RHEL 7 filter for psi-enabled-count

Codecov Report
Base: 72.45% // Head: 72.45% // No change to project coverage :thumbsup:

Coverage data is based on head (c65ebc3) compared to base (3ccdd87).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #288   +/-   ##
=======================================
  Coverage   72.45%   72.45%
=======================================
  Files          26       26
  Lines        1238     1238
=======================================
  Hits          897      897
  Misses        341      341

Flag
Coverage Δ

unittests
72.45% <100.00%> (ø)

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

Impacted Files
Coverage Δ

ros/api/v1/hosts.py
86.14% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@pgarciaq Hello Pau!
It looks like we might need a RHEL 7 filter for psi_enabled_count as well.
The reason for this is rules doesn't really have this PSI cannot be enabled in RHEL 7 logic.
One fine day if there is a bug from rules and we end up saving a bunch of psi_enabled=True RHEL 7 records,
our psi numbers would look bad.
We can take this up with Xiangce but IMHO our code should be fault tolerant because it depends a lot on
external sources of data.
Let me know your thoughts, thanks!

@kgaikwad @PreetiW  I have wrapped the filtering code into a function cause,

code wasn't DRY
only one chunk of the code gets unit-tested now
needed to get rid of the hackish #noqa comment

The test suite takes 25 secs to run atm with 40 tests.
I can add another test for True input, but IMO it would be good to keep the test suite lean, whenever possible.
Thanks for testing Preeti :raised_hands: I don't think you'll need to retest :v:

@kgaikwad @PreetiW I have wrapped the filtering code into a function cause,
1. code wasn't DRY

2. only one chunk of the code gets unit-tested now

3. needed to get rid of the hackish `#noqa` comment

The test suite already takes 25-28 secs to run with 40 tests. I can add another test for True input, but IMO it would be good to keep the test suite lean, whenever possible.

As long as it checks with different data records then I guess it is fine to test one input (False/True).


[stable/k8s-spot-rescheduler] Added podAnnotations option.

What this PR does / why we need it:
Added podAnnotations so that Prometheus metrics can be exported.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/chart])

/lgtm


RadioGroup doesn't support name prop

RadioGroup generates a random name prop, making it unusual for JS handling and unusable for HTML form submissions.
i.e.

This should be resolved in https://github.com/segmentio/evergreen/releases/tag/v6.10.4


Integrate more advanced configuration options

@giobart for the go based implementation please take a look at https://github.com/spf13/cobra as well as https://github.com/spf13/viper for both command generation as well as configuration management.
Creating this issue, as discussed today.

Did we manage to solve these configuration problems?

im not sure, maybe @giobart can give more input on this

We don't have any problem per se, but cobra would definitely be nice to have for the configurations both on our NodeEngine and the NetManager

@giobart if for some mysterious reason I do find some time apart from working, I will evaluate cobra and push a PR for it :)

fixed in #341


additional library discussion

we can discuss adding 3rd party libraries (I mean, other than the core ones) here, I suggest:

classnames
redux-thunk
immutablejs (not a must but would be nice because I have its sticker on my laptop)

@batuhan @ilgooz

can't we just use Object.assign instead of immutablejs? I know it has additional benefits but are we going to take advantage of those benefits?
classnames is a nice to have, it doesn't add too much overhead to disturb us.
I like redux-thunk. So I'm giving it a +1.
anything you would like to add, @ilgooz?


Rebuild with build plan metadata change errors

If I rebuild the default app by adding build=true metadata to plan.toml, the build fails.
To reproduce
# checkout v0.1.0

./scripts/package.sh -v 8.8.8

cd integration/testdata/default_app

pack build minimage -b ../../../build/buildpackage.cnb -b gcr.io/paketo-community/build-plan
# Build succeeds

# now add build=true to plan.toml
cat plan.toml
[[requires]]
  name = "conda"

  [requires.metadata]
    launch = true
    build = true

pack build minimage -b ../../../build/buildpackage.cnb -b gcr.io/paketo-community/build-plan
===> DETECTING
[detector] paketo-community/miniconda  8.8.8
[detector] paketo-community/build-plan 0.0.11
===> ANALYZING
[analyzer] Restoring metadata for "paketo-community/miniconda:conda" from app image
===> RESTORING
===> BUILDING
[builder] Paketo Miniconda Buildpack 8.8.8
[builder]   Reusing cached layer /layers/paketo-community_miniconda/conda
[builder]
===> EXPORTING
[exporter] ERROR: failed to export: layer 'paketo-community/miniconda:conda' is cache=true but has no contents

I expect
I expect that a new image is built where miniconda is available at build time for downstream buildpacks.
Right now it seems to fail with this lifecycle error.

I might push back on the idea that this scenario should work. I think that you may be a little deep in the guts of the machine for this to be a real world problem. I think that the extra overhead logic is not worth it in this case and instead we should maybe have a disclaimer that if you are manipulating the build plan between builds there may be caching issues that could be solved by clearing your build cache on a subsequent build.

I'm inclined to agree with @ForestEckhardt - I don't think this is a problem that needs to be solved. I'm happy to be convinced otherwise, but I currently can't see a valid situation where a user interacts with the buildpack in this way.


update pkg/dap for the use_super_parameters lint

We're excluding pkg/dap from using the new use_super_parameters due to some work required in the code generator (the generated code is triggering the lint). This issue tracks updating the generator and generator code (the work is not expected to be great).
cc @DanTup

Is there not a label to use for package:dap issue?

The DAP implementation is still in DDS (only the protocol classes were moved out into their own package), so the label is (at least currently) dds-dap.


API Issue after install

This is a bug.

Prerequisites

[x] Are you running the latest version? yes
[x] Are you reporting to the correct repository? yes
(enso is made of many specialized packages: https://github.com/laravel-enso)
[x] Did you check the documentation? yes
[x] Did you perform a cursory search? yes

Description

I'm having a problem getting my API working after install.
I started the root using the PHP artisan serve command and getting an output of "Starting development server: HTTP:// <IP_ADDRESS>:8000"
then opening a new terminal going to the client directory and running the command yarn serve getting "Done compiled successfully App running at: Local: http://localhost:8080"
The problem comes when I try visiting the page localhost:8080 (Which is the only URL that works) I see a green gradient screen but nothing else, on the terminal I get the error "Proxy error: could not proxy request /API/meta from localhost:8080 to localhost:8000"
My root .env file has the APP_URL set to "APP_URL=http://localhost:8080/" this is also added in my SANCTUM_STATEFUL_DOMAINS
My Client .env file has the APP_URL set to "APP_URL=http://localhost:8000" also added to DOMAINS list
I've tried switching the numbers around but am having no luck.
I am using a VM Ubuntu 20.4 | php8.0 | MySQL 8 | composer 2

After looking at this and getting it to work I feel dumb :D

I am still having a problem with this application tho,
I moved the root folder from my LAMP server to my Windows Wamp64 server and was able to get a login screen but now once I'm logged in I'm stuck on a loading screen, the console shoots out

Failed to load resource: the server responded with a status of 500 (Internal Server Error)
chunk-vendors.8623315e.js:21 Uncaught (in promise) Error: Request failed with status code 500
at e.exports (chunk-vendors.8623315e.js:21)
at e.exports (chunk-vendors.8623315e.js:70)
at XMLHttpRequest.p.onreadystatechange (chunk-vendors.8623315e.js:36)
I'm completely stuck on what I'm needing to do now. Any and all help is welcomed!

If it's a 500 Error code it's a server issue. Check your laravel.log and see what is reported there.

Thank you for that! i fixed that issue but now all I'm getting in counsel is a 401 error:
Failed to load resource: the server responded with a status of 401 (Unauthorized)
chunk-vendors.8623315e.js:21 Uncaught (in promise) Error: Request failed with status code 401
    at e.exports (chunk-vendors.8623315e.js:21)
    at e.exports (chunk-vendors.8623315e.js:70)
    at XMLHttpRequest.p.onreadystatechange (chunk-vendors.8623315e.js:36)


Issue with unstable_vitePlugin

Describe the bug
When using the new unstable_vitePlugin the dev server and build failes with the following error:
10:54:31 AM [vite] Error when evaluating SSR module /app/lib/i18n/i18next.server.ts: failed to import "remix-i18next"
export * from "./client";
^^^^^^

SyntaxError: Unexpected token 'export'
    at internalCompileFunction (node:internal/vm:77:18)
    at wrapSafe (node:internal/modules/cjs/loader:1288:20)
    at Module._compile (node:internal/modules/cjs/loader:1340:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at Module.load (node:internal/modules/cjs/loader:1207:32)
    at Module._load (node:internal/modules/cjs/loader:1023:12)
    at cjsLoader (node:internal/modules/esm/translators:345:17)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:294:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)

Steps to Reproduce the Bug or Issue
Us the new unstable_vitePlugin
Expected behavior
It does not throw an error.

Hi @hauptrolle, I'm facing the same issue, I don't know Vite very well but it seems that using :
export default defineConfig({
  plugins: [remix(), tsconfigPaths()],
  ssr: {
    noExternal: ["remix-i18next"],
  },
});

makes this specific error you are mentioning disappear but introduces another error :
TypeError: headers.get is not a function
    at Module.getClientLocales (/Users/davo/dev/dials/node_modules/remix-i18next/browser/lib/get-client-locales.js:7:34)

I'll keep an eye on this issue to see if someone comes with a good fix.

As a temporary fix, try
import { RemixI18Next } from "node_modules/remix-i18next/browser/server.js"; and etc if this is a blocker for your vite migration.

I'm seeing another issue with remix-i18n where Vite chokes on accept-language-parser and its use of module.exports syntax.
10:51:44 AM [vite] Error when evaluating SSR module /node_modules/accept-language-parser/index.js?v=caa3510c:
ReferenceError: module is not defined
    at /node_modules/accept-language-parser/index.js?v=caa3510c:73:1
    at instantiateModule (/node_modules/vite/dist/node/chunks/dep-6e2fe41e.js:50317:15)

I was recommended this Vite plugin, see if this solves it for you https://github.com/cyco130/vite-plugin-cjs-interop

I solved the accept-language-parser by inlining the pick function into remix-i18n.

Now I'm seeing this:
TypeError: headers.get is not a function
    at Module.getClientLocales (/node_modules/remix-i18next/browser/lib/get-client-locales.js:7:34)

Now I'm seeing this:
TypeError: headers.get is not a function
    at Module.getClientLocales (/node_modules/remix-i18next/browser/lib/get-client-locales.js:7:34)

Seems like what's discussed in https://github.com/remix-run/remix/issues/7819

I don't have this issue anymore after upgrading remix to 2.3.0 and vite to 5.0.0.
Still using this configuration:
export default defineConfig({
  plugins: [remix(), tsconfigPaths()],
  ssr: {
    noExternal: ["remix-i18next"],
  },
});

TypeError: headers.get is not a function
    at Module.getClientLocales (/node_modules/remix

This seems resolved in the 2.4.0 pre-release of remix/dev however it seems that the Server script returns an error
TypeError: __vite_ssr_import_2__.Response is not a constructor
    at onShellReady (/home/pim/projects/onderwijscatalogus/frontend/app/entry.server.tsx:59:13)
    at finishedTask (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6513:7)
    at retryTask (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6598:5)
    at performWork (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6642:7)
    at Immediate._onImmediate (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6969:12)
    at process.processImmediate (node:internal/timers:476:21)
TypeError: __vite_ssr_import_2__.Response is not a constructor
    at onShellReady (/home/pim/projects/onderwijscatalogus/frontend/app/entry.server.tsx:59:13)
    at finishedTask (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6513:7)
    at retryTask (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6598:5)
    at performWork (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6642:7)
    at Immediate._onImmediate (/home/pim/projects/onderwijscatalogus/frontend/node_modules/.pnpm/react-dom@18.2.0_react@18.2.0/node_modules/react-dom/cjs/react-dom-server.node.development.js:6969:12)
    at process.processImmediate (node:internal/timers:476:21)

As of writing this, the issue is not presenting itself with remix 2.4.0. Seems like it's been fixed and the solution is to upgrade remix.

It still requires the noExternal config to run with Remix 2.5.
export default defineConfig({
  plugins: [remix(), tsconfigPaths()],
  ssr: {
    noExternal: ["remix-i18next"],
  },
});


[Clarification]: Do App Owners OR employees accessing Apps/Flows of COE environment would be done with O365 with PowerApps license or everyone would require PowerApps per user plan??

Describe the bug
Do App Owners approving decisions OR employees accessing Apps of COE environment would require premium license? OR all external actions by app owners/employees against COE environment can be done with Office 365 with PowerApps Plan?
Component (please tell us which flow or app you are experiencing issues with):
Core Solution
CoE Starter Kit - v2.1
All COE Resources
Hello,
In COE Environment, there are couple of flows that sends an approval emails to App Owners, while couple of apps that are accessible via all employees of the organization, I assume that they can perform their actions without premium license.However can you please clarify on followings:

For example, archival approval email for canvas/SP forms can be approved by app owners with Office 365 with PowerApps license? OR they would need PowerApps Per User license?
Similarly is this the same for all external actions what Apps Owners/Employees would execute against COE Environment via COE Apps/Flows?
Also, which are those external actions that App Owners/employees have to make against COE Environment in COE Starter Kit? Can you please provide the list if available?

Thanks and Regards,
Dipti

Yes, app maker can perform approvals in the archival process without a license to CDS, so they will be able to approve/reject from the email.
I dont follow your other questions. But do note that all flows / apps that use CDS require a CDS license to use.
The only exception to this is approvals, which do use CDS under the covers, but which have been given a license exception.
Please refer to Power Platform Licensing FAQ for more details.
Thanks for using CoE

Thank you for the response Jenefer!
I have noticed that user with "Microsoft 365 with PowerApps" Plan, was able to submit the form of "Developer  Compliance Center" App. that updates data in CDS Entity "PowerApps App" - does it mean that, "App Owners" of MPP don't require "PowerApps Per User plan" to update data behind the scene in COE database?
My only concern is, whether to govern the Power Platform via COE Starter Kit, do all App Owners must have "PowerApps Per User Plan" assigned OR "Microsoft 365 with PowerApps" licenses would be enough?
Thanks and Regards,
Dipti


Move deployment scripts to separate repository

Currently several deployment scripts with DaaS specific functionality are contained inside the scripts folder. These scripts implement specific functionality for DaaS. Therefore these scripts should be moved to a separate repository biz.dfch.PS.Sunrise.DaaS.Scripts (or similar).
Furthermore these scripts (file.ps1) currently contain functions that need to be dot-sourced in order to be executed. Either move them to a module so they can be invoked as a regular Cmdlet or change the functions inside the script files to a script file with a PARAM block (the latter is preferred).
These scripts can still be packaged as nuget packages and be deployed with a regular install.ps1 if desired.

Repository has been created and is available at BitBucket


[clonezilla] "clonezilla image home directory /home/partimag is not a mounting point"

Saw this error when trying to create a disk image using clonezilla.
/dev/sdc1 filesystem: fat32
mount -t auto -o noatime,nodiratime /dev/sdc1 /home/partimag
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or helper program, or other error

This directory is not a mount point: /home/partimag
There is no way to mount the sub-directory.
Pragram terminated!
Clonezilla image home directory /home/partimag is not a mounting point! Failed to mount other device as /home/partimag!
Are you sure you want to continue?

My note from last year tells me using FAT32 for the target usb is better so I did (as following) but I still get the same error.
$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.31.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sdb: 7.5 GiB,<PHONE_NUMBER> bytes, 15669248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3b6532a5

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        2048 15669247 15667200  7.5G 83 Linux

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x343e72d9.

Command (m for help): p
Disk /dev/sdb: 7.5 GiB,<PHONE_NUMBER> bytes, 15669248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x343e72d9

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
      e   extended (container for logical partitions)
      Select (default p):

Using default response p.
Partition number (1-4, default 1):
First sector (2048-15669247, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-15669247, default 15669247):

Created a new partition 1 of type 'Linux' and of size 7.5 GiB.

Command (m for help): p
Disk /dev/sdb: 7.5 GiB,<PHONE_NUMBER> bytes, 15669248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x343e72d9

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        2048 15669247 15667200  7.5G 83 Linux

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): b
Changed type of partition 'Linux' to 'W95 FAT32'.

Command (m for help): p
Disk /dev/sdb: 7.5 GiB,<PHONE_NUMBER> bytes, 15669248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x343e72d9

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        2048 15669247 15667200  7.5G  b W95 FAT32

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

USB must have a formatted partition. File system didn't matter (ext4 worked).
lsblk
sudo fdisk /dev/sdb
(In fdisk commandline) press "o", "n", "w". Follow default values.

sudo mkfs.vfat /dev/sdb1

mkdir -p /tmp/test_partition
sudo mount /dev/sdb1 /tmp/test_partition

Ref https://askubuntu.com/questions/22381/how-to-format-a-usb-flash-drive


Remove Qwen2-7b from NPU example for "Run Optimized Models (Experimental)"

Merge for now :) Will raise other PRs for any further comments


debug

2 bugs are fixed.

I'm not sure about the correctness, but by fixing these bugs, the training process can be completed.
Glad to be part of this project :)


fix(curriculum): cat photo app workshop step 11-15

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #56311

@ilenia-magoni updated PR.

@huyenltnguyen thanks for the tip. Will do that from now on.


file watcher triggers too much

If I carefully write to a file with a simple unix tool, like
echo "" >> file then I see exactly one rebuild when watching file.
But with any editor, after saving a file I see a bunch of rebuilds. On linux with VScode, I saw exactly two rebuilds, but on Mac it triggers endlessly and the ibazel command needs to be killed.

iblaze specifically debounces the writes for that reason, it triggers on the first fs event, but then collects fs events for another 100 ms (or so, not sure about the number). The reason is that most editors don't just write a file, they have some dance like writing a new copy, then move the copy over the old file, and sometimes even moving the old file to a backup before that, which of course causes multiple events.

@alexeagle, is this happening on macOS? It could be additionally related to howeyc/fsnotify#62. The correct solution is to debounce this but while I look into how to do that it might be helpful to try their suggested fix of turning off spotlight indexing.


Add VScode tasks to build and flash efr32 apps with selected boards.

Problem
no problem just adding a vscode task
Change overview
Add two tasks in .vscode/task.json
Update efr32.py and targets.py to support efr32 board selection
Testing
Use the new tasks to build and flash a few examples on efr32 boards

/rebase


Add test cases for debug node

Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes
Add test cases for debug node to improve the code coverage.
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage increased (+0.3%) to 86.908% when pulling c319ccafde83fe9fce64c47adbade7aaad255082 on HirokiUchikawa:master-testdebug into 23c2a771d34b7c0a54e342e7c25b3efa7d3b4260 on node-red:master.

Thanks!


Remove msys dependency for Windows.

Bazel genrules require a msys shell to execute
shell commands. Replace the genrules with a
simple C++ regex replacement binary.
Fixes #303.

I trust you compiled the library with this patch and it works.
I did bazel<EMAIL_ADDRESS>and everything built. I inspected the generated headers and they seemed kosher.


Repo/test manifest divergence

What this PR does / why we need it:
Adds CI task to run the manifest generation script, check if it resulted in changes, and fail if it did. This ensures that single and base manifests do not diverge.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #668
Special notes for your reviewer:
https://github.com/Kong/kubernetes-ingress-controller/runs/960118920?check_suite_focus=true failed because it should. The manifests aren't in sync currently. In a local test directory where I have updated them:
15:20:02-0700 yagody $ git status
On branch repo/test-manifest-divergence
nothing to commit, working tree clean
15:20:04-0700 yagody $ ./hack/build-single-manifests.sh
15:20:21-0700 yagody $ git status
On branch repo/test-manifest-divergence
nothing to commit, working tree clean
15:20:22-0700 yagody $ make verify-manifests
./hack/verify-manifests.sh
diffing ./hack/../deploy/single/ against freshly generated single manifests
./hack/../deploy/single/ up to date.

How do we want to handle that? Just update them and roll the changes into this PR, or separate PR to update them and then rebase this onto next (or main) after it's merged?

Latest updates apply @mflendrich 's bash suggestions and comingle a manifest update along with the CI update so that the test now passes. Please refer to the run linked earlier/CI history for a demonstration of the failure case behavior.