Added extension point for custom delta requests

See https://github.com/apache/tomcat/pull/240

I think merging #240 was a bad idea: we are not going to add extension points for just about anything, which are then supposed to be set in stone while looking rather useless to just about everyone and in great danger of being refactored away.
-1 for adding this.

I think this is the same as #240; I just haven't back-ported it.
Can we discuss on #240 what your objections are? The alternative is for a user to re-implement 100% of e.g. DeltaManager just to change one aspect of it's behavior.

The change implies all methods of concrete classes become supported stable APIs. I think this is too much and we cannot / should not promise that the added methods are not going to be refactored away.
Also, as I pointed out, there's pretty much an infinity of convenient hooks that can be added everywhere for extensibility.
When extending into custom components, I don't think some amount of code duplication is that bad. Sure, you may miss bugfixes but it's more likely to remain stable that way. And when things work and you have no problems, you don't need magic bugfixes and random behavior changes IMO.


upgrade ES target to es2022

This upgrades the output to use ES2022. This includes native private fields syntax. We see almost zero devices on github.com that do not support private fields. And we've been considered private fields part of our baseline support for a while now.
This means users on macos Mojave and below, using Safari, may have a further degraded experience than they already have. They can improve their experience by switching to another browser such as Chrome or Firefox, but Apple does not release Safari 15 for macos Mojave or below, as Apple has not supported macOS Mojave since Oct 2021 - when it was EOLd.
This also means users on ios/ipados 14 may see a further degraded experience. ios/ipados 14 was EOL in October 2021, and Apple no longer provides security updates for these devices. Some of these devices can upgrade to ios/ipados 15. Some devices, like the iPad Mini 3 (discontinued October 2014), 4th generation iPad (discontinued October 2014), or the iPhone 6 (discontinued September 2016) will be unable to upgrade to iOS 15, and so visiting a page with <relative-time> will cause JS to SyntaxError.

FWIW, I avoid private fields because of https://lea.verou.me/blog/2023/04/private-fields-considered-harmful/.

I'm not sure I share those opinions; if you're extending a class it's fairly common to have to override parts of the class to deal with things like private state or copying (see the whole @@species debacle). The alternatives to private fields are: make everything public (but then lose the ability to observe changes or have two public fields), or use a WeakMap, and then the loud errors about private field access turn into silent ones where properties using a WeakMap can return undefined instead.

make everything public

I prefer all-public fields because they enable advanced use cases that the original author has not considered. For example, there are numerous cases in Node.js API where one needs to access underscore props. With private fields, you restrict the consumer too much imho.

Many of the private fields in this codebase (and our other custom element codebases) are public, but they need to be observed, for example #onRelativeTimeUpdated has a get/set but it has (warranted) side-effects which can only happen if we store the state under a different name. We could publicise the field name but that means coming up with some alternative name, and runs the risk of exposing undesirable information which can cause memory leaks - for example setting onRelativeTimeUpdated removes the old event listener, but if one were to assign to the #onRelativeTimeUpdated and not remove the old event listener, it would continue to fire and could cause further errors. We could make this field a WeakMap instead, but as I say, we then face the same issue with regard to subclassing, so I feel like this is a well justified use case where the alternatives have greater trade-offs.


Run AssertJ best practices OpenRewrite recipe

Fairly simple changes automatically applied through OpenRewrite.
Now consistently uses static imports for assertions, and test method names dropped the no-longer-needed-test-prefix.
https://docs.openrewrite.org/reference/recipes/java/testing/assertj/assertj
https://docs.openrewrite.org/reference/recipes/java/testing/cleanup/bestpractices

Thanks for your PR
from my point of view such changes should come together with some automatic rules which could prevent future methods name in similar way, otherwise it does not make big sense

Thanks for your PR
from my point of view such changes should come together with some automatic rules which could prevent future methods name in similar way, otherwise it does not make big sense

While I don't mind the cleanup, I'm quite opposed to any rule which makes a fail for non-functional reasons, and I don't see myself changing my standpoint on this any time soon.
Also having another build would not be a great solution, it would just be a build which always fails, I'm not going to let a build fail because someone uses a "test" prefix as a method name for example, or has a space too many, or prefixes a test method with public, or any of those reasons, you can have prescriptive rules like this at your work if you fancy them, but not here.

I actually personally prefer methods starting with "test" (or my real preference is "should"), but I see zero reasons to strip the test prefix from methods, so I'm going to close this one.

No worries; as I said, most of these changes were made automatically, and I understand that (not) using a test prefix is a matter of taste. The additional build step I only added after it was suggested, but understandable that you do not want to throw up any hurdles. In other projects I've seen such automated checks take off some of the review burden, but if it does not fit here that's fine.
You might want to cherry pick https://github.com/datafaker-net/datafaker/pull/454/commits/956e73056464c6f059bd683334586ffde5590095 only to get the static imports for AssertJ, even if it's not enforced through https://github.com/datafaker-net/datafaker/pull/454/commits/99f0f658a67fda5d5c15eee323701bbf33f3705e.
Or you can recreate those changes by executing this command:
mvn org.openrewrite.maven:rewrite-maven-plugin:4.36.0:run \
  -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-testing-frameworks:1.30.0 \
  -DactiveRecipes=org.openrewrite.java.testing.assertj.Assertj

I'll leave the fork & branch up for a while still, before I clean it up.
Happy to help; no problem if not all of my suggestions make it in. :)

Thanks for your understanding. I feel not great about rejecting PRs knowing they have been created with the best intentions.
I probably will cherry pick your commits indeed (or feel free to send another PR if it's not too much effort), cause I do like consistency and the static imports would be great to incorporate, I'm just slightly hesitant to make this a standard.
Thanks again!

Ps: absolutely love Open Rewrite. Great tool, and I hope there will be support for Kotlin soon, since our (work) code base (Java+Kotlin) would greatly benefit from some of the migrations.

Glad to hear you already know and like the tool! :) I've opened https://github.com/datafaker-net/datafaker/pull/456 to separately and only update those imports.


Remote Desktop with mouse & keyboard control.

A suggestion to join to To-Do list.

I actually recently recoverd a old rat (developed around 2015-2016) with a fully functional remote desktop and keyboard support, I will see what I can do about porting that feature to this project as a fork

That would be awesome. Recently I'm getting used  playing in console, I am not sure that makes you waste time. Anyway thank you.


movie.get_content('main_page') freeze often

movie.get_content('main_page') freeze often
from kinopoisk.movie import Movie
movie = Movie(id=278229)
movie.get_content('main_page') # hang on this row

after long timeout displayed error message
requests.exceptions.ConnectionError: HTTPConnectionPool(host='www.kinopoisk.ru', port=80): Max retries exceeded with url: /film/278229/ (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x10507e8d0>: Failed to establish a new connection: [Errno 65] No route to host',))

May be your IP was banned. Are you able to open it with browser?

This problem seems to be related to the temporary ban on the kinopoisk side


Add better documentation

~Add explanation in readme~
~Explain what dat is / how it works / comparison in readme~
Add detailed usage to readme
Add a gif showing usage
Add a man file??
Explain any limitations - ~I think, for example, files need to fit in memory?~

Files no longer need to fit in memory with https://github.com/tom-james-watson/dat-cp/commit/c43900d475918837f69b47436e118d41710ce684


Issue fixes & style change

Solves:

#101 (I HIGHLY RECOMMEND READING THIS BEFORE CONSIDERING A MERGE)

Changes:

Seperated title header and search header from the chat area (makes it work with calls)
Removed the black call background and gradient to match the rest of the themes
Rounded call corners and added spacing
Fix the new discovery icon to be consistent with the theme
Change the scrollbar color in the emotes menu to bg-2 so it's visible

not a fan of this. i think it changes the identity of the theme way too much just to fix an issue in calls. there has to be another solution (sorry i'm too busy to work on this stuff right now).

I thought so, I can open a pull request with just the other fixes if that's what you'd like

One last thing, should I put back the black call background with the gradient as well?

Does this seem good to you?


Project schema in Mediaflux

We should update our code to create the schema using the same definitions used by Chuck in td-meta1. Notice that their are using CamelCase instead of snake_case for the properties.
We probably want to wait on this until Matt and Chuck are back, though.

The camel case field names more closely match the google doc with the schema


[Bug] Unexpected behavior when configuring http header for query in variable section

Describe the bug
On the section "Settings/Variables/Edit" for a dashboard, when configuring the query options using the Inifnity datasource, it is impossible to configure headers, the pop-up window always close after clicking on the button "Configure".
Steps to reproduce

Open/Create a dashboard

Open the settings of the dashboard (cog-wheel on the top right) and go into the "Variables" section

Create or Edit a variable

In the query options select Infinity Datasource

Click on Configure "Headers"

The pop-up window closes unexpectedly

Sample Data
Screenshots

Version Details:

Grafana version : 8.4.7
Plugin version : Infinity DataSource 1.0.0

Additional context
I have configured an allowed host in the Datasource configuration. This problem was not occurring with version 0.8.8.
Could not reproduce this unexpected behaviour in Grafana v9.0.2.

I do not have any authentication configured, I only restrict the allowed hosts url.


add typing information

closes #368
This PR goes hand in hand with https://github.com/python-hyper/hpack/pull/277 and https://github.com/python-hyper/hyperframe/pull/163 and might be refined together.
This PR is still a draft. The major outstanding issues are around handling of Headers, with their (bytes, bytes) or (str, str) or HeaderTuple types. I'm open to suggestions on how to best address these issues. Currently, mypy still reports about 26 typing-related errors and a few tests are failing.

@BYK happy to hear your thoughts on the header typing dilemma!

@BYK I think I solved the headers type confusion and now all tests pass again. mypy is almost happy, but I think I would like to hear your input on the few remaining findings as they mostly relate to #1286 :
src/h2/utilities.py:130: error: Argument 1 to "startswith" of "str" has incompatible type "bytes"; expected "str | tuple[str, ...]"  [arg-type]
src/h2/utilities.py:138: error: Argument 1 to "startswith" of "str" has incompatible type "bytes"; expected "str | tuple[str, ...]"  [arg-type]
src/h2/utilities.py:259: error: Argument 1 to "search" of "Pattern" has incompatible type "bytes | str"; expected "Buffer"  [arg-type]
src/h2/utilities.py:604: error: Argument 1 to "append" of "list" has incompatible type "bytes | str"; expected "bytes"  [arg-type]
src/h2/utilities.py:624: error: Unsupported operand types for in ("bytes | str" and "bytes | str")  [operator]
src/h2/utilities.py:625: error: Argument 1 to "split" of "bytes" has incompatible type "bytes | str"; expected "Buffer | None"  [arg-type]
src/h2/utilities.py:625: error: Argument 1 to "split" of "str" has incompatible type "bytes | str"; expected "str | None"  [arg-type]

@BYK the new Headers is defined here https://github.com/python-hyper/hpack/pull/277/files#diff-e10aaf7dbceff5ef795c06588c5b846012815fd4c2fec5b1008255699e9c7b0bR48
Though, I just noticed this syntax is not yet supported on Python 3.9... so I need to find a different solution.

@Kriechi made a suggestion over there. I think that also takes care of the py3.9 issue as it doesn't have nested Unions?


Data branch

#description
making the data branch and upload the files.(augmentation.py bps_dataset.py and data_utils.py).create the week 1 report in README.md
#issues
closed #2
#contributers
@MehrdokhtNoranian
@ASingh082
@bixu7
@wilsonfong56

This looks good!

I reviewed your code, looks good to me.


[WIP] Move "Manage user" modal into "Full profile" modal

Move standalone "Manage user" modal into "Full profile" modal. Also, render an edit link next to users (only visible to members who have authorization to manage user info).
Fixes:
#21806

Screenshots and screen captures:
https://user-images.githubusercontent.com/38874449/164407509-389e8510-9963-4649-a36d-06d4b5d40719.mov
Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Misunderstood the ask for the issue. Will create a new PR


partsLimit is being thrown when busboy is configured for one file

Busboy is configured as:
const options = {
    headers,
    defCharset: 'utf8',
    limits: {
      fieldNameSize: 0,
      fieldSize: 0,
      fields: 0,
      fileSize: 10496000,
      files: 1,
      parts: 1,
      headerPairs: 2000
    }
  };

A single file upload like so:
<body style="background-color: black">
  <form enctype="multipart/form-data" method="post">
    <label>single file
      <input type="file" name="file_v1" />
    </label><br />

    <button type="submit">Upload</button>
 </form>
</body>

Why would the partsLimit be thrown? Is there something else inside the multipart? On the other hand when I configure the options to limit the files to 2, and when I upload 2 files, the filesLimit is not thrown. The same for field limit. I would expect the same behaviour for partsLimit -- to be thrown when I have violated the limit, not fulfilled the limit.

Same.
Minimal code to reproduce the issue here: https://github.com/reviewingcode/busboy-multipart-file-upload
^basically the example code from README - with limits and events for partsLimit, filesLimit, fieldsLimit.
https://github.com/expressjs/multer/issues/1105

It seems that the issue has something to do with the part limit not being followed, and was introduced in this commit!
After looking at the code, I could not explain this line and I thought that this might be the issue:
https://github.com/mscdex/busboy/blob/master/lib/types/multipart.js#L445
@mscdex
Why do we break if the limit is reached or surpassed?
Don't we need to break if the limit is surpassed?

It seems that the issue has something to do with the part limit not being followed, and was introduced in this commit!
After looking at the code, I could not explain this line and I thought that this might be the cause of the issue: https://github.com/mscdex/busboy/blob/master/lib/types/multipart.js#L445
@mscdex Why do we break if the limit is reached or surpassed? Don't we need to break only if the limit is surpassed?

When you look at the code changes, it looks like two changes collided. The event 'partsLimit' used to be emitted too late, now it is emitted when the limit is reached, as described in the readme file. But on the other hand, part limit, which was enforced in the same code chunk, was right. The check on line 445 seems indeed to be too zealous, and the new code drops parts too early.
I am by no means qualified to work on this code, just comparing versions without an understanding of the full context. But is this code still maintained (sorry, can't help on this :-( )? Thanks!

@mscdex hi, thanks for maintaining this lib so far
would you consider looking into this issue in the near future?
or if not, could you please mention if this is a wont-fix type situation?


feat: activity form sequence data

Add seq id selection form to activity form
Allow for inserting or deleting seq ids from simulated activities
Demonstrate end-to-end command expansion
See: https://jira.jpl.nasa.gov/browse/AERIE-1801


GEM-144

@saeedmb8 @KaitCrawford
Fixed styling on report_response template by adding container wrappers.

:+1:

:+1:


Supernotes update

Adds a command to whisper note to self

Found errors in code. Submitting new PR.


configure HTTPS doesnt work

Hi,
I try to configure https.
i followed the steps from https://github.com/codecasts/ambientum/issues/46 (production)
Steps i did:

Login into the server (SSH)
created the folder (/home/ambientum/ssl)
cd /home/ambientum/ssl
openssl req -x509 -nodes
-days 3650
-newkey rsa:2048
-keyout nginx.key
-out nginx.crt \
-subj  "/C=AM/ST=Ambientum/L=Ambientum/O=Ambientum/CN=*.nl"
openssl dhparam -out dhparam.pem 2048
docker-compose restart

can reach https.
who can help me, please
it says:
ERR_CONNECTION_REFUSED
nginx log
"ssl_stapling" ignored, issuer certificate not found for certificate

You should add in your file docker-compose.yml
     volumes:
       - ./.ssl:/home/ambientum/ssl
".ssl" is the directory where your files are (nginx.key, nginx.crt and dhparam.pem)

Thank you

@zgelici HTTPS is bundled by default on the images for development and "behind a proxy" usage.
The port where HTTPS works is 8083 on the container, so you will need to map a second port there.
If're you planning on using the default HTTP and HTTPS ports.
Bind 80 on the host to 8080 on the container
Bind 443 on the host to 8083 on the container.
Mounting the volume and generating the new certificate is only useful for replacing the default certificate.


policy: Do not scan all entries when adding new ones

Hold MapStateEntries in entries map, trie and cidr are additional indices for the same MapStateEntries. cidr only indexes keys with CIDR identities, while trie indexes keys by traffic direction, protocol, destination port and mask.
Use the new cidr index when adding entries to MapState with deny entries, and the existing trie index when adding entries to MapState with auth entries. Likewise, use the trie index when adding visibility entries. With this we no longer scan through all entries in MapState when adding new entries.
MapState now contains an optional validator interface that can be set in unit tests to add calls to validation code for the new ancestor/descendants code.
On local benchmarking for generating MapState for an egress policy with 1000 deny and 1000 allow CIDR rules:
Before:
Number of MapState entries: 117515
goos: linux
goarch: arm64
pkg: github.com/cilium/cilium/pkg/policy
BenchmarkRegenerateCIDRDenyPolicyRules-12    	       1<PHONE_NUMBER>94 ns/op
PASS
ok  	github.com/cilium/cilium/pkg/policy	763.696s

After:
Number of MapState entries: 117515
goos: linux
goarch: arm64
pkg: github.com/cilium/cilium/pkg/policy
BenchmarkRegenerateCIDRDenyPolicyRules-12    	       1<PHONE_NUMBER> ns/op
PASS
ok  	github.com/cilium/cilium/pkg/policy	3.634s

This is a 230x speedup :-)
Deny rule processing has been improved to run faster on larger policies.

/test

/test

/test

/test

/test

Moved identityIsSupersetOf validation from production code to unit test. This sped up the bechmark almost 2x and removed panics from production code.

Split refactoring from commit policy: Add cidr index to mapstate to a new commit just before it.

/test

@jrajahalme what do you want me to look at here? I don't have any code ownership.

@jrajahalme what do you want me to look at here? I don't have any code ownership.

Added you by mistake, sorry for the noise.

/test

A better approach would be to index the CIDRs by key and do simple lookups within a port-protocol traversal.

Interesting, could you elaborate on this, i.e., be more specific?

It is also unclear to me why this PR traverses all CIDR ancestors of a given policy identity, when most of them can be completely eliminated from comparison by a simple port-protocol traversal of the indices.

In any case the CIDR ancestors is a small subset of all entries, as all (other) leaf entries as well as all non-CIDR entries are eliminated.
The problem with proto-protocol traversal is that it could degenerate to scanning almost all entries, if there are many CIDR rules for a few port-protocol pairs or wildcards thereof.

/test

This PR is on the right track, but how CIDRs and identity are indexed to one another and compared needs overhaul. This PR optimizes CIDR comparisons, but at the expense of the gains that can be made by optimizing port protocol comparison, which is, by far, the more common case. These two things do not have to be mutually exclusive, but the insertion logic in this PR neglects the gains that could be made with more robust port-protocol comparison. It is also unclear to me why this PR traverses all CIDR ancestors of a given policy identity, when most of them can be completely eliminated from comparison by a simple port-protocol traversal of the indices. A better approach would be to index the CIDRs by key and do simple lookups within a port-protocol traversal.

So the design I came up with adds a separate CIDR index, that needs to find a subset of key/entry pairs. I did consider changing MapState to hold MapStateEntry pointers instead of entries themselves to be able to point to the same entries from multiple indices. It seemed simpler to just store the full Keys in the indices and have the entries in a separate map. This makes some operations on the mapstate also faster (getting a specific entry with full key, iterating all entries).
CIDR index provides the "identityIsSuperset" relations almost directly, and I saw that as the potential main determinant of performance, as most identities in the MapState would not satisfy that relation. I left the existing port/protocol checks as-is. I did not try stacking the indices see how much it would help.

@jrajahalme

I did not try stacking the indices see how much it would help.

I think the port-protocol indices should be used first. This makes the logic easier to follow in insertion.
Here is a draft PR  that modifies this one up to the identity comparison logic using CIDR cache (so the whole PR isn't represented).

Here is a draft PR

See comments in the draft PR.

/test

/test

I think the port-protocol indices should be used first. This makes the logic easier to follow in insertion.

@nathanjsweet Thanks for this push-back! I implemented this into this PR, and adding the use of the PortProto trie in insertion made the new CIDR-specific benchmark 8x faster, to a combined 1800x speedup!

Rebased to pick up merged  #33447.
cidr can be nil, had to add check for it to avoid nil dereference.

/test

/test

Rebased to fix merge conflicts

/test

Added comment as requested :-)

/test

Removed empty commit due to merged #33449

/test


WMS ID: 7921 + 9522 "Updated the title to match with rainfocus"

WMS ID: 7921
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[Yes ] All filenames are lower case (including folders, images, files, etc.)
[Yes] Filenames are descriptive
[Yes] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[Yes] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[Yes] Image references in markdown contain an alternate text

Hi Arabella, Yes Steve Lemme added me as observer for this workshop. Could you please go ahead and approve the request now.
Thanks.

Hi Arabella, I got it updated as observer for the workshop #9522. Could you please approve now.
Thanks.


Release/wrong release number

Should this work?

Should be failing on develop checks for a main directed PR? (Develop branch gitflow / branch-name-check)
Also, should this work with my random version number?
@Lukazcreations

What happens if I merge to main but not to develop?

@hjoaquim So this PR would not be merged because it failed the required branch-name-check and also you didn't request a review.


HHH-11808 - Update migration guide and documentation

https://hibernate.atlassian.net/browse/HHH-11808
this PR targets master branch.

Applied upstream, thanks


Create Responsive Layout with Media Queries

Ensure that the layout adapts to different screen sizes. When the viewport width is less than 768px, portfolio columns should stack vertically. For wider viewports, they should align horizontally.

Media queries have been added to ensure the layout is responsive. The portfolio columns stack vertically when the screen width is less than 768px, and they align horizontally for wider viewports.


Update Globals “site_data”

Automatically generated by Netlify CMS

👷 Deploy Preview for shimmering-marigold-4f5b4a processing.

Name
Link

🔨 Latest commit
f0759fe2eb6120dfbab78bb0ce3981c0446ff9e1

🔍 Latest deploy log
https://app.netlify.com/sites/shimmering-marigold-4f5b4a/deploys/64ff9454a2a3ae00088188cf


Validate on generation

In GitLab by @jakebeal on Feb 21, 2020, 15:30
When we generate a structured request, we should run it through the validator first.
If it succeeds validation, no problem.
If it fails validation, then the user should be warned that they are downloading a faulty request.

In GitLab by @tramyn on Feb 24, 2020, 15:52
mentioned in merge request !94

In GitLab by @tramyn on Feb 24, 2020, 15:52
created merge request !94 to address this issue

In GitLab by @tramyn on Feb 25, 2020, 12:55
mentioned in merge request !95

In GitLab by @tramyn on Feb 25, 2020, 12:55
created merge request !95 to address this issue

In GitLab by @tramyn on Feb 27, 2020, 12:05
closed via merge request !94

In GitLab by @tramyn on Feb 27, 2020, 12:05
mentioned in commit 5e5e8d5a03180e277e07a2514ba53fff4b38976e


Add comment button at top of page to let you scroll into form comment box

Created new branch from recent main branch

added scroll into comment box
Decided not to add focus on the comment textbox area because the current text box library is not NextJS compatible and raise accessibility issues. The code we implemented does focus on the box for us, but if the page renders slowly, it will take you to the bottom but won't always auto focus.

@rio-k9 @jpmaHub the "current text box library" is this something to something compatible?

@simplybenuk It is not compatible.

@jpmaHub sorry I didn't write that very well. I meant is this something we can change to something that is compatible?

@simplybenuk I can certainly have a look to see what there is for Next compatibility and report back


Error: Cannot read property 'sslHost' of undefined (client.js:546:23)

We're using the new SSL support and saw this error when trying to create our Kafka producer:
Cannot read property 'sslHost' of undefined
    at connect [as createBroker] (/Users/philidem/Development/third-party/kafka-node/lib/client.js:546:23)
    at Client.setupBroker (/Users/philidem/Development/third-party/kafka-node/lib/client.js:535:24)
    at Client.reconnectBroker (/Users/philidem/Development/third-party/kafka-node/lib/client.js:610:24)
    at null._onTimeout (/Users/philidem/Development/third-party/kafka-node/lib/client.js:599:12)
    at Timer.listOnTimeout (timers.js:92:15)

I'm logging this issue here to keep track of it but I will try to add more details later.
Problem lines are these:
host = brokerProfile[this.ssl ? 'sslHost' : 'host'] || host;
port = brokerProfile[this.ssl ? 'sslPort' : 'port'] || port;

I think this is the right fix:
host = brokerProfile && brokerProfile[this.ssl ? 'sslHost' : 'host'] || host;
port = brokerProfile && brokerProfile[this.ssl ? 'sslPort' : 'port'] || port;

I don't know enough about brokerFile. I would like to understand a little better why it might be undefined in some cases before applying this fix. I don't want to hide another underlying problem.

@CharlesWall @hyperlink can you take a look at this error to provide insight into why brokerProfile is undefined and if my fix described above is reasonable?

I'll take a look.


Feature/ir 216/transaction processor map

What is this pull request?
This pr provide effective, but strict realization of transaction processor.
How to use the features provided in the pull request?
There are available:

Async api for responses based on rxcpp
Stateless validation statuses
Tests for current functionality

Limitations:

Blocking execution of transaction_notifier
Not supported transaction responses for commit, rejects and others
Missed testable subscription in tests

Details/Features
Restore previous interface of transaction processor, thus, restore responsibility of transaction processor for manage transaction statuses.
Additional dependencies (optional)
In this pr was used gmock. So, after merging this pr into develop all developers may use mocks for own purposes.

What about reasoning?

We have decided the design drawing.
There is no Transaction Processor there.

It looks like there's a tx processor to me.

we definitely need to draw something meaningful as components diagram, this is my fault. Please remind about this in sprint review when we will discuss issues and in case I may forget to say about it

Transaction Processor proposed to be renamed to TransactionHandler I think.


add: test / game

Via Courtney B in Beta Feedback.

via Parantak Joshi via email.

+1 via Ruslan Aybazov via email.


[ETFE-1248] Update content and add drop down details for item

Includes refactor of the Select Item Details page so that it uses a Summary List instead of a Table to match prototype

This one should be good to review now


Properly handle operation as init process

Proposed Changes
Properly handle operation as init process. This includes both vacating the root cgroup on cgroupv2 systems, and reaping child processes since containerd doesn't clean up after its own shims.
This is a Go adaptation of the behavior proposed in #3237; we rejected doing this in shell and K3d has been using a workaround ever since.
Types of Changes
bugfix
Verification

Run K3s in Docker on a system with cgroup v2; note that it works
Note that there are no <defunct> processes inside the Docker container

Linked Issues

#4085
#2722

User-Facing Change
The K3s docker image now works on cgroup v2 systems, and properly reaps terminated containerd shim processes.

Further Comments

So does this supersede https://github.com/k3s-io/k3s/pull/3242 ?

@iwilltry42 I believe so yes. It doesn't do everything that your PR did but it doesn't appear to be necessary to get things working?

@brandond I'm not sure.. I think the evacuation is the most important bit and that's the same in both.
I think you just put it in a different spot and I changed some other cgroup related things with it back then.
I guess the codebase also changed quite a bit since then.
If it works with your changes in k3d with the entrypoint disabled, then I'm happy already 😁

Is there an easy way to test k3d without the entrypoint?

Not 100% sure right now (on my phone) but using export K3D_FIX_CGROUPV2=0 should work

No, it doesn't work with K3D_FIX_CGROUPV2=0 because /sbin/docker-init is pid 1. The K3s containers need to be started without --init for our fix to take effect; is there a way to do that?

Yeah, it's hardcoded right now, but I can add an env var switch for that, if needed and drop it in the next v5 pre-release?

This commit seems to have broken rootless mode
https://github.com/k3s-io/k3s/runs/3726354551

I believe it's been failing since before that commit. I can run rootless locally so I think it's something with the CI configuration. Unfortunately the cgroup v2 tests don't output any logs and I'm not sure how to execute them locally so it's been difficult to troubleshoot.

Looking at https://github.com/k3s-io/k3s/commits/master , the CI was green ✅  for the previous commit (“ set transport to skip verify if se skip flag passed ”)

Ah, indeed. Looks like it is legit just broken:
INFO[0000] Acquiring lock file /var/lib/repos/k3s/data/.lock
INFO[0000] Preparing data dir /var/lib/repos/k3s/data/ffe439099bcec803a4a982d914444fc964d4e58050884e9ab0015ae0fe8956ad
FATA[0000] failed to evacuate root cgroup: mkdir /sys/fs/cgroup/init.scope/init: permission denied

Do you have a suggestion as to how we could better surface errors from the rootless cgroup v2 CI? It has a history of flaking so I do not personally look too closely at the results.


Readme update

I was very happy to discover your plugin, nice work and thank you !
I saw the links were broken so here is a README update.
Plus, the install procedure can be achieved via the import button in the user defined dialog box so I changed that to !

Fixed and thanks!


fix(test): fix PID capture from test indexer

Fixes Granola-Team/mina-indexer#767
The wrong PID was being captured. The PID captured was for a bash process and thus the kill signal wasn't reaching the Indexer itself.

@jhult It is true that the PID captured is not the PID of the indexer, but it is a sufficiently good PID to keep because sending it a signal will kill its child (the mina-indexer) as desired. The solution you have here will not work as-is because it backgrounds the 'idxr' command, but that command must not always be backgrounded as it is often used for foreground things.


Investigate "Generate" option available without active document

See #4
Visibility of the Generate action is handled via CodegenGenerateAction.kt

Found this isn't that the generate option is available, but that attempting to generate before any language is selected will cause the problem mentioned in the linked issue. The fix was to select the first item in the panel (which it wasn't doing properly before). Now, a "Swagger Codegen" details page is displayed when no language is selected on dialog open.


Revert "Bump dd-trace from 1.1.0 to 1.1.1"

Reverts quirrel-dev/quirrel#688
This broke prod 😓

Coverage increased (+3.4%) to 79.961% when pulling 44b3207950528b0f153edb8d44095273230fad6b on revert-688-dependabot/npm_and_yarn/dd-trace-1.1.1 into 08b5860c3e70f69940efa0b312133b30d0fc9f50 on main.


KnowAgent is vulnerable to Information Disclosure, and it results to attackers can read arbitrary files.

When I study the source code of KnowAgent, the file-content route in NormalLogCollectTaskController.java gets my attention. It seems to be a file read function.

2）Then I access the route via http request. It is a vulnerability which leads to an arbitrary file reading.
The request URL is http://<IP_ADDRESS>:9010/api/v1/normal/collect-task/file-content?hostName=<IP_ADDRESS>&path=/etc/passwd

谢谢宝贵的建议，这的确是个漏洞，我们将修复.


Setup issue

Logger: homeassistant.config_entries
Source: config_entries.py:2077
First occurred: 12:25:23 (1 occurrences)
Last logged: 12:25:23
Error occurred loading flow for integration ecoflow: cannot import name 'Observable' from 'reactivex' (/usr/local/lib/python3.11/site-packages/reactivex/init.py)

Logger: homeassistant.config_entries
Source: config_entries.py:402
First occurred: 10:42:45 (1 occurrences)
Last logged: 10:42:45
Error setting up entry for ecoflow
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 402, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ecoflow/init.py", line 429, in async_setup_entry
hass.config_entries.async_setup_platforms(entry, _PLATFORMS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ConfigEntries' object has no attribute 'async_setup_platforms'

https://github.com/vwt12eh8/hassio-ecoflow/pull/79


Outdated information about package flight deletion

It looks like the information about package deletion is outdated or it is not possible to delete published flights. If the second option is true, then it is not clear from the documentation.
See screenshot that shows that there is no Modify button

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

ID: 17105757-d0a7-1427-6461-0c98f1a6ffa2
Version Independent ID: e6f704bd-5b5e-d601-81bd-c92e1301bdd8
Content: Package flights - UWP applications
Content Source: windows-apps-src/publish/package-flights.md
Product: uwp
Technology: publish
GitHub Login: @hickeys
Microsoft Alias: hickeys

We are changing the way we track issues filed from our documentation pages: please see this blog post for more details. The Microsoft Store documentation has been updated several times since your issue was reported, and there's a good chance your problem has been addressed. Right now, this issue is being closed but if you feel it is still valid and has not been addressed, please re-open it with any more available information. Please note that if you question is more general and not related to documentation, Microsoft Q&A is a great way to get questions answered.


Toggle panels and no-Distraction mode

Full code view with all other panels/toolbars hidden.
Also minor refactoring of variable names for toggle/hide for sidebar.
shortcut : ctrl+shift+` for toggle panels
shortcut : ctrl+shift+2 for no distraction mode
Also added panel management API's to workspace manager.
@nethip

Should it be hide panels or toggle panels? toggle seems to be troublesome at times.

@petetnt @ficristo @zaggino

I think that hidePanels should be sufficient, at least until the panels are grouped together with something like #11586. Panels get currently opened and closed all the time so it would be tons of trouble to keep up with their states at this point IMO.

Thanks @petetnt for reviewing.
Made the change to toggle panel only if workspace has not changed after a hide panels command is issued. This looked intuitive to me.
The documentation for the preference was intentionally worded as Code view only. The string describes what no distractions mode in simple terms.

In the View menu, Toggle Panels menu doesn't show the shortcut.
@abose I briefly tested the patch and seems fine.
I agree with @petetnt for the panels.

@zaggino There seems to be a bug. If you hide the git panel, the blue active icon for the git extension still remains in the main-toolbar. So added events when panels are shown or hidden so that extensions can listen to panel close events.

thanks for the info @abose

Tested this out again against https://github.com/adobe/brackets/commit/51c023279576b78d8f61886991a50c10609b72df , love the No distractions mode.
There's a small issue with toggle panels though (other than the shortcut not showing up/working)

Open foo.js
Create a validation error (I am using brackets-eslint)
Click Toggle Panels -> nothing happens (expected: panel closes)
Click Toggle Panels -> panel closes.

That issue that affects brackets-git affects other Extensions too, such as brackets-todo. Is there a way to (at least temporarily / during 1.6.) to throw a warning if panel was closed but the button state remained + link to say Brackets-Wiki where those events would be explained). That would provide a easy way for extension makers that use panels to know that they should update their extensions).

Looks good to me. And agree, that the no distraction mode is a nice touch.
Do we have an idea of how often people will want to jump into this? Main question is wether we can set an easier shortcut.
I also like that it doesn't go full screen the way Sublime Text does, but any thought about whether we need that?

@ryanstewart there was an issue about "true" fullscreen some while ago (#11594) and when checking out that one I saw that CEF got updated to support fullscreen quite recently so it could be implemented relatively easily (needs a brackets-shell update though) separate from this feature. :+1:

@petetnt ahh, awesome. And I'm definitely not advocating for that, just wanted to throw it out there. Sounds like it's been covered though!

ctrl+shift+~ falls in the same vertical last line in the key board, so i thought it would be easily accesible to dismiss panels with one hand.

@petetnt i have created https://github.com/adobe/brackets/issues/11924
This is an issue in extract extension too.

Couple of quick comments.

We need to add unit tests for the new No Distraction feature. I saw some changes in the unit tests but I am not sure if they are going to cover the new workflows
We need to add health logs for the new functionality. Also make sure to update our Health Data wiki with this new data
It is better to have null checks at places where we calling APIs, as we would never know if the API returns an actual value or null. If you want to catch errors here, use a null check along with console.warn/console.error. That should raise errors in the console, in case of failures
Please update the documentation, wherever required
Make sure we update our API docs with the changes/additions

Overall it looks good :+1: It is good to merge, provided the review comments are addressed.

@nethip thanks for reviewing. Made the changes.
Will add unit tests soon.

@abose No problem :) I took the liberty to add unit tests checkbox to your first comment. Also I created a waffle card for tracking the unit tests for this feature I am going ahead merging this.
Thanks for this feature @abose !

Comment on pull request

Comment on pull request


Network insight, cleanup and testability

Cleanup the flowd aggregator and ease testability a bit (support custom config paths).

Both my main installs have issues since this work started with flowd_aggregate stopping soon after startup. On the office box port total still work, but traffic is always empty.

@fichtner sorry about that, I just noticed the same on my box too, fix will follow

@AdSchellevis no worries, just letting you know before forgetting about it again :)

@fichtner can you sync again? the current status should be good, I've fiddled a bit with parameters, it should be more consistent now.

looks good, many thanks!


Show Michelson expression instead of raw data in the signing preview

Hello👋
Sometimes users need to sign some Michelson data. When users sign such data via Temple, it shows raw data that is a bit not user-friendly. It'd be great if Temple could show decoded Michelson data like Kukai. For example:
Let's imagine we have a contract that verifies a signature of pair of some string and nat (Pair string nat). Like this: https://ide.ligolang.org/p/gvtsX0KZn42XScTPXHEznw
And we have a client application that allows a user to enter signing values and sign them using their favorite wallet via Beacon SDK:
import { packDataBytes } from '@taquito/michel-codec';
// ...

// Account is connected
// const dAppClient: DAppClient = ...

const signingMichelsonData = packDataBytes({
  prim: 'Pair', args: [
    { string: 'some text' }, // We've hardcoded the data for simplicity
    { int: '123456789' }
  ]
}).bytes;

const walletSignedData = await dAppClient.requestSignPayload({
  signingType: SigningType.MICHELINE,
  payload: signingMichelsonData
});
console.log(walletSignedData.signature);

When the app requests to sign from the wallet, the wallet will show the user a signing popup.

Temple
Kukai

Tested Account
const account = {
  address: 'tz1dzNhmfwGHLLyQhmD9XRqfsTwU4NEAihRv',
  secretKey: 'edskRs5nrtPgFpUSXFtNhq1HBuAVG2sKDDeor3bAFE5ZpZ1NJh6yYGm4fX3qrGScW9HYjTXpkLobJEaGABpdg5zw4LPUocWrec',
  publicKey: 'edpkv9MW8Ddpg3SqAd5yncr26thhNTtm9Rz7qVf1aE1kGNepo1RJp3'
}

Test the contract in Ligo IDE

Select Dry Run
Enter ("some text", (123456789, ("edpkv9MW8Ddpg3SqAd5yncr26thhNTtm9Rz7qVf1aE1kGNepo1RJp3", "edsigtpbrj7fJJCg7q7u9UgKAiVsK6KWEcgtcAzAjNQy1aQ4pqdnnAUuEw63c7AQy5aqJ6CbyUH1Q7ZGKhcCNFUjPB3Ho7UJvNH"))) as the parameter
Enter false to the storage input
Run
Output: ( LIST_EMPTY() , True(unit) )

What do you think?

Yeah, having this same issue. It's really strange too. Using the example message
"Tezos Signed Message: mydapp.com 2021-01-14T15:16:04Z Hello world!"
from a tutorial it shows the string totally fine. However, if I change the Tezos to all-caps like
"TEZOS Signed Message: mydapp.com 2021-01-14T15:16:04Z Hello world!"
It suddenly only shows the raw.
Works flawlessly in kukai, but I much prefer temple. I know signing isn't very often used right now in the tezosphere, but would be nice as signing allows me to verify ownership of wallets without having people pay any gas fees in tez. Thanks.

Hi, should be available in 1.14.10.
Could you check, please?

Hi guys! Sorry for the late response. I've checked, it works fine now. Thank you!


AbilityBuilder expected 1 arguement, but got 0

Steps to reproduce
I just installed feathers-casl in a typescript feathers project. While figuring casl out I just started from your basic example to define the rules for the newly authenticated user.
 const { can, cannot, rules } = new AbilityBuilder(); throws the error Expected 1 arguments, but got 0. and expects AbilityType: AnyClass<T> as input.
How do I deal with this? And funny enough am I the first one to get the error?
Expected behavior
Should work according to the docs :)
Actual behavior
It throws the error and does not compile.
System configuration
Not much to say here.
Module versions:
"@angular/animations": "13.1.1",
"@angular/common": "13.1.1",
"@angular/compiler": "13.1.1",
"@angular/core": "13.1.1",
"@angular/forms": "13.1.1",
"@angular/platform-browser": "13.1.1",
"@angular/platform-browser-dynamic": "13.1.1",
"@angular/router": "13.1.1",
"@angular/service-worker": "^13.1.1",
"@casl/ability": "^5.4.3",
"@casl/angular": "^6.0.0",
"@feathersjs/authentication": "^4.5.12",
"@feathersjs/authentication-client": "^4.5.13",
"@feathersjs/authentication-local": "^4.5.12",
"@feathersjs/configuration": "^4.5.12",
"@feathersjs/express": "^4.5.12",
"@feathersjs/socketio": "^4.5.13",
"@feathersjs/socketio-client": "^4.5.13",
"@nrwl/angular": "13.4.6",
"@nrwl/web": "13.4.6",
"axios": "^0.21.4",
"compression": "^1.7.4",
"cors": "^2.8.5",
"express": "4.17.1",
"feathers-authentication-management-ts": "^2.1.2",
"feathers-casl": "^0.7.1",
"feathers-hooks-common": "^5.0.6",
"feathers-mongodb": "^6.4.1",
"feathers-reactive": "^0.8.2",
"feathers-validate-joi": "^4.0.1",
"helmet": "^4.6.0",
"joi": "^17.5.0",
"lodash": "^4.17.21",
"luxon": "^2.3.0",
"mongodb": "^3.7.3",
"mongodb-core": "^3.2.7",
"ng-zorro-antd": "^12.1.1",
"nodemailer": "^6.7.2",
"rxjs": "~6.6.0",
"shx": "^0.3.4",
"ts-node-dev": "^1.1.8",
"tslib": "^2.3.1",
"winston": "^3.4.0",
"zone.js": "0.11.4"
NodeJS version:
v14.18.2

I confirm it works! After opening the issue I kept on searching and ended in the casl for angular section and I saw that.
Until answering my own question, you beat me to the punch.
I guess it should be in the docs?
Thanks

Could you open a PR with the change to the docs? That would be awesome! I would merge it immediately.
Maybe even an issue/PR over at the official casl repo would be nice.

Closing #53 again.


Remove All Version-Specific Methods

Describe the Bug
This module includes a lot of public methods that assume there are are only 2 versions of the spec. We shouldn't copy-and-paste functions across versions. Rather, we should just pass a parameter to specify the CloudEvent version.
Here's an example:
Actual
export function createV1(attributes: CloudEventV1Attributes): CloudEventV1 {
  const event: CloudEventV1 = {
    specversion: schemaV1.definitions.specversion.const,
    id: uuidv4(),
    time: new Date().toISOString(),
    ...attributes,
  };
  return new CloudEvent(event);
}

export function createV03(attributes: CloudEventV03Attributes): CloudEventV03 {
  const event: CloudEventV03 = {
    specversion: schemaV03.definitions.specversion.const,
    id: uuidv4(),
    time: new Date().toISOString(),
    ...attributes,
  };
  return new CloudEvent(event);
}

Expected
export function create(attributes: CloudEventV03Attributes | CloudEventV1Attributes): CloudEvent {
  ...
  return new CloudEvent(event);
}

It looks like https://github.com/cloudevents/sdk-javascript/pull/277 addresses at least those 2 functions from above

@lholmquist there are no other version specific functions that I am aware of being exported at the top level. I am closing this. @grant - If there are specific functions in nested files that should be addressed, please open a specific issue for them.

Yup, looks good to close @lance.


[LICENSE][FOLLOWUP][KYUUBI #449] Update license

Why are the changes needed?

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

thanks, merged to master for v1.2.0


Handle exit by promisifying lumo compilation

This patch fixes the fact that serverless could not display the failures of
compilation in lumo. It also needs the very latest lumo for it to work.

Yep I will change it and yes that is why I think we should wait for a merge/release. Unfortunately the old versions cannot be made to work as well. Note that lumo compilation has always been experimental so I don't think we can rely on version numbers these. The good news is that the next release will probably be at par with JVM cljs.
On September 13, 2017 1:35:24 AM PDT, Moe Aboulkheir<EMAIL_ADDRESS>wrote:

moea commented on this pull request.

(run! classpath/add! inputs)

(lumo.build.api/build
(apply lumo.build.api/inputs inputs)
compiler-opts))

(js/Promise.
(fn [resolve reject]

(js/console.info

 "Invoking the Lumo compiler w/ inputs"

 (.stringify js/JSON (clj->js inputs)))

(run! classpath/add! inputs)

(lumo.build.api/build

 (apply lumo.build.api/inputs inputs)

 compiler-opts

 nil

 #(let [promise-fn (if (:error %) reject resolve)]

    (promise-fn %))))))

This would be clearer if the only statement inside the promise was:
(js/Promise.
 (fn [resolve reject]
   (lumo.build.api/build
      ...
      (fn [result]
        (if (:error result)
          (reject result)
          (resolve result))))

What happens if the user doesn't have the latest lumo?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/nervous-systems/serverless-cljs-plugin/pull/22#pullrequestreview-62364706

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

My PR is not in lumo yet and I am waiting for feedback from Antonio. I fixed this, but we'd better wait. In the meantime, I fixed another problem in another PR.

So this is now in lumo 1.8.0-beta and I don't think it is a feature that can be retrofitted: before the lumo.build.api call was only able to return the compilation result synchronously. This means that we versions older than this new one, if compilation fails things gets weird.

In second thought, this one now should work for older lumos as well because the compiler function probably throws on errors, making the promise reject anyways.

Yeah, but if the signature doesn't include a callback argument, presumably it'll be a problem?

Oh right, well what do you think is the best approach? I think lumo compilation before this version is not worth keeping compatibility with, as you have probably guess it was very experimental.

If we clearly document the status of the lumo dependency in the README (either a commit hash or version #, whatever's applicable), then I'm fine with the change.

Ok I will add that, there is an actual version published on npm, 1.8.0-beta1 .

If you get a moment, can you address the previous review comment which suggested removing everything from the Promise monad except for the final build call?

Sure, do you mean the console.log?  The add-classpath is better inside in case it throws

If it throws outside the promise, the process will exit irregularly in any case.

So I think that thanks to https://github.com/anmonteiro/lumo/commit/80192d10b15d13de5439fd146daf9ca60efec124 this patch can be entirely dropped. The build api is sync now.


Node GUI broken, hidden, example scene broken

Tried to test out if this package still works, sadly not really. Found these issues in first 15 min on testing:

No node connections can be seen in node window

Start node cannot be moved
Example scene throws has null reference exceptions for DialogueContainer

Perhaps I installed something wrong, but as there are no instructions, I just cloned this repo into an assets folder...
EDIT:
Forgot to mention version: 2022.3.5f1 LTS

Did you figure out how to solve it ?

Did you figure out how to solve it ?

I managed to fix the problem of incorrect connection display by adding the following line to StoryGraphView.cs
textField.style.flexDirection = FlexDirection.Column;

Source: https://github.com/Wafflus/unity-dialogue-system/issues/1


DOC-559 | Adjust URLs, work on lead paragraphs and cards

Description
TODO:

[ ] Find a solution for Deploy > Deployment > Cluster > Deployment
[ ] Fully apply to 3.10 and 3.11
[ ] Add support for Hugo aliases + version aliases
e.g. this page does not work at the moment (but using /3.12/ does):
https://deploy-preview-316--docs-hugo.netlify.app/devel/introduction/use-cases/
[ ] Test Hugo redirects
[ ] Test Netlify redirects
[ ] Update legacy redirects in WPEngine

Upstream PRs

3.10:
3.11:
3.12:

Deploy > Deployment > Cluster > Deployment: We could move the content of https://deploy-preview-316--docs-hugo.netlify.app/devel/deploy/deployment/cluster/deployment/ into https://deploy-preview-316--docs-hugo.netlify.app/devel/deploy/deployment/cluster/#deployment. This way we can get rid of this extra Deployment page.

Would be nice to have Javascript API and HTTP API next to each other in the menu.


Fix Windows compilation

The recent commit https://github.com/ros-visualization/rviz/commit/dd1779e78dbb1468fdb11968632fafd5e7a272f2 broke compilation on Windows. This PR fixes this issue.
Compiler error without this patch:
%SRC_DIR%\ros-noetic-rviz\src\work\src\rviz\default_plugin\screw_display.cpp(87): error C2491: 'rviz::ScrewDisplay<MessageType>::ScrewDisplay': definition of dllimport function not allowed
%SRC_DIR%\ros-noetic-rviz\src\work\src\rviz\default_plugin\screw_display.cpp(95): error C2491: 'rviz::ScrewDisplay<MessageType>::onInitialize': definition of dllimport function not allowed
%SRC_DIR%\ros-noetic-rviz\src\work\src\rviz\default_plugin\screw_display.cpp(103): error C2491: 'rviz::ScrewDisplay<MessageType>::reset': definition of dllimport function not allowed
%SRC_DIR%\ros-noetic-rviz\src\work\src\rviz\default_plugin\screw_display.cpp(125): error C2491: 'rviz::ScrewDisplay<MessageType>::updateProperties': definition of dllimport function not allowed
%SRC_DIR%\ros-noetic-rviz\src\work\src\rviz\default_plugin\screw_display.cpp(132): error C2491: 'rviz::ScrewDisplay<MessageType>::updateHistoryLength': definition of dllimport function not allowed
%SRC_DIR%\ros-noetic-rviz\src\work\src\rviz\default_plugin\screw_display.cpp(191): error C2491: 'rviz::ScrewDisplay<MessageType>::processMessagePrivate': definition of dllimport function not allowed

With patch compilation succeeds.

Many thanks @traversaro for the hint
/cc @wolfv

Hi, thanks for getting back to me so quickly. I tried removing the export first and it didn't work for some reason. Unfortunately I won't have time to look at this again. Many other files probably have unnecessary exports, too - I suggest to merge this PR to get a working compilation and open an issue to clean the exports up. What do you think?

PS: on https://github.com/RoboStack/ros-noetic we'll have regular builds on Win, OSX and Linux.

I tried removing the export first and it didn't work for some reason.

Maybe, you forgot the one export in declaration of WrenchVisual?
 Please, give that a try on Windows.

Many other files probably have unnecessary exports, too.

No, that's the only plugin source declaring a superfluent export. To keep the code clean, I would prefer to fix it immediately.

on https://github.com/RoboStack/ros-noetic we'll have regular builds on Win, OSX and Linux.

Would be nice to have CI integrated here with github...

If you're interested I can push a GitHub action that uses micromamba to install the RViz dependencies from our robostack channel!

Hi @wolfv, I'm not used to github actions yet. Don't you need to pay for that service? If not, a full stack of github actions to build rviz on Windows would be highly welcome.

nope, github actions for open source is free. Azure Pipelines is also free & open source and both are pretty similar.
Travis CI is the one which, unfortunately, recently changed their business model to disallow "unlimited" use for opensource projects.

github actions for open source is free.

Good to know. Need to learn about its configuration now...

Travis CI is the one which, unfortunately, recently changed their business model to disallow "unlimited" use for opensource projects.

Yeah, they did. But they already reverted that decision for open-source: https://blog.travis-ci.com/oss-announcement

This is good to be merged.


Revert "@craigspaeth => Gucci routes"

Reverts artsy/force#1940

Fixed in https://github.com/artsy/force/pull/1947


#1025 Bump Azurite to 3.26

What does this PR do?
Bump Azurite to v3.26.0

Why is it important?
Support API version to 2023-08-03

Related issues

Closes #1025

Ready for review


Add correct window to touch pointers.

Simple follow-up to https://github.com/bevyengine/bevy/pull/11128. Adds the correct window ref to touch pointer events.

Ah, this is a bevy 0.13 thing

Thanks!


No pause(); method on generators?

Hi
I searched the generator.dart and the context.dart and didn't find a trace of that function anywhere, Is this not implemented yet?
I didn't check, But probably since pause() Didn't exist probably play(); doesn't exist as well, So if you're planning to add pause and play was not there, It should be added as well.
Regards.

Hi,
Play and pause are implemented for generators, sources, and contexts. I've just added an example as part of commit 4b3827109b61650cbea1eb198688ff1bbcb514ea.


OracleCoherence: Fix the permission issue while running the container

Got the following error while running the Coherence container:
"sh: /start.sh: Permission denied"
This patch intends to fix it.
Signed-off-by: Dong Zhu<EMAIL_ADDRESS>

I'm not sure why there's a difference in using +x vs 755. But, I don't think this is the best solution either and it highlights that these Dockerfiles are not aligned with our best practice around not setting fixed passwords during build.
Let me notify the Coherence maintainer to review all the Dockerfiles and bring them more into alignment. I'm not going to close this PR yet, but I want a larger PR that fixes more issues to be submitted instead.

@Djelibeybi There is no "read" permission of this file. So it can not be executed even though it has "x" permission.

In which case, the permission of the file in git should be fixed too.

@Djelibeybi In general one commit fix one issue, and it is a critical issue because the container could not be started successfully without this patch.

@Djelibeybi I do not think so, I think fix it in Dockerfile is a good way.

Yeah, good point. Merged.


Added semicolons to Bonfire: Drop It tests

close #4610

Thanks for the PR, however, so forgot to add some semi-colons in the messages of the tests.
Also, please remove the issue number from the PR title and instead put closes #4610 in your PR message body.

@AryanJ-NYC thanks for the PR. Please, move close #4610 to the description and do not include it in commit messages/PR titles/branch names and remove the semicolon from the title, thanks.

@ltegman @bugron Thanks for your help on the pull request. I'll remember to include the close messages in the description next time. Also, can't believe I missed the other semicolons!  I amended the commit to add the semicolons.  Thanks again!

Great work!  Thank you!


[bugfix] More complete type definitions for changes from #4611

see #4611

Coverage decreased (-0.07%) to 88.432% when pulling 8eb8e2b54152cf1e8b6536a4e99a6d8730977cb8 on thorn0:strict-parse-ts31 into e3c67905f9d714d43a28dc627ee8efdab06dbce3 on moment:develop.

@Alanscut what do you think?


Bugfixes in Relayer

For reference: https://knowhow.brainbot.com/r1hYDTiESz6dDXdL17EESA
The relayer will need to send every relay message transaction with a manual gas estimation multiplied by a factor of 1.5.
Additionally, every relay message coming from optimism, which is either Portal.finalizeWithdrawTransaction or CrossDomainMessenger.relayMessage, will have a fixed 3M gas limit. This needs to be in place until the 0x1 estimtaiton address hack for gas estimation can be used by the relayer again. It is currently blocked due to ArbitrumL1Messenger using tx.origin.
Acceptance criteria

[ ] Relayer sends relay message transactions with gas limit buffer of factor 1.5
[ ] Relayer sends relay message transactions from optimism with 3M gas fixed.

Hey team! Please add your planning poker estimate with Zenhub @bilbeyt @compojoom @GabrielBuragev @istankovic


refactor: clean standard implementation of cli modules

Currently with the modules all being declared first as functions and then as if-statements in the template, the system looks kind of hacked together to me. It'd be nicer to have a module be able to be in it's own file, and just a function that outputs a string or something, as it is likely that the amount of transpiler modules will increase.
Each module here should also have it's module.yml, readme and a jsonschema file for generating a reference on the website. That probably requires each module to have its own directory.

I agree with this. Ever since I wrote the logic for flattening the recipe for the bug report (pulling in the from-file contents) I've been wanting to do that for the main Containerfile template so that we don't have to recursive templating. We could kill two birds with one stone on this issue.


Update syslog-ng.conf for Ubuntu 22.04

Description of the change
Updates the syslog-ng configuration file format from 3.25 to 3.35 for the version of syslog-ng installed in Ubuntu 22.04
Benefits
Quiets the warning when phusion/baseimage:jammy-1.0.0 boots:
WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode. Please update it to use the syslog-ng 3.35 format at your time of convenience. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file; config-version='3.25'
WARNING: The internal_queue_length stat counter has been renamed to internal_source.queued. The old name will be removed in future versions; config-version='3.25'

Possible drawbacks
I did not investigate whether other changes are necessary to the configuration file.

I will wait for this solution. Thank you very much.


fix(curriculum): refactored example in step 16

Checklist:

[X] I have read freeCodeCamp's contribution guidelines.
[X] My pull request has a descriptive title (not a vague title like Update index.md)
[X] My pull request targets the main branch of freeCodeCamp.
[X] I have tested these changes either locally on my machine, or GitPod.

Closes #46899

Refactored example in step 16 of: Learn CSS Colors by Building a Set of Colored Markers in new Responsive Web Design.
It seems that it's the first time that the concept of "multiple classes in css" is introduced to the user. I hope this helps to understand it better now.

I don't think we have actually come to a consensus on how to rework this step.

Sorry, my bad, didn't know we had to come to an agreement i thought i just had to make a pull request and await for feedback. I am new to contributing to open source.

No worries. I appreciate the effort. But with a potentially major change like this we usually wait for a discussion and some sort of agreement before opening a PR. I left a lot of questions unanswered in the issue I opened, so those definitely need to be answered first.

Thank you, but this has become too long. An user should be able to complete the challenge in less than 120 seconds. Reading all that will eat all the time.

What about this, i removed the first paragraph as @bbsmooth suggested, the last 2 markdowns in my previous solution and created a second paragraph in wich the user is introduced to the color markers exercise and the concept of multiple classes.
I even moved the task given to the user to the bottom, i think it makes more sense since the user is being introduced for the first time to the concept of multiple classes and therefore has to read the example.

@VincenzoParrinelli I think you are just jumping the gun a little here. Do we even need an example of adding two classes to an element? That was one of my questions that needs to be answered before we can move on this. Also, if we do need the example I'm guessing we will not want two example code blocks.

@bbsmooth As i said, i think we do need an example since it's the first time getting introduced.
Should it be shrinked to one example code block?

Ok, i agree about getting new classnames, but i checked the next steps, and the thing is:
-the class "one" actually gets changed to "red" in step 41 among the others in the subsequent steps to 45
-if we want to edit the classes that way we must edit all the steps (html + css) from 16 to 41
-and we must delete/rework all the steps from 41 to 45

I just picked two simple class names off the top of my head. I had no idea that "red" was actually used later on. No, we shouldn't use that as an example then. Maybe "cat" and "dog"? I'm just coming up with simple random names. Perhaps someone else has a better suggestion?

I have closed this because it hasn't received any new updates.


Undefined semantic on comparison between a Tensor and its permutations

I have noticed a potential area for improvement regarding the use of isequal and isapprox functions for our Tensor struct. Currently, these functions distinguish a tensor from a permuted version of the same tensor as different.
From a mathematical perspective, one might argue that a tensor and its permutation should be treated as essentially the same entity. This is because the labels of the tensor already indicate that the data is permuted. Nevertheless, the current implementation of isequal and isapprox treats them as distinct. Here's a simple illustration:
julia> using Tensors

julia> A = Tensor(rand(2, 2, 2), (:i, :j, :k))
2×2×2 Tensor{Float64, 3, Array{Float64, 3}}: ...

julia> B = permutedims(A, (2, 1, 3))
2×2×2 Tensor{Float64, 3, Array{Float64, 3}}: ...

julia> A ≈ B
false

julia> A == B
false

My suggestion is to consider adjusting the isequal and isapprox functions to return true in cases like this. I believe this adjustment will not only make the comparison of different tensors more flexible but will also enhance the user-friendliness of our library.

I agree with you. We should bet on mathematical coherence.
A question that I have is how would we implement the comparisons: should we permute one of the arrays to make the comparison or should we create some kind of specialization of eachindex to iterate both tensors in the same way?

Also, if a user wants to use legacy/Julia-like comparison, it can be done by calling parent on the tensors.


[Feature]: Implement tags for git-sync

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Providing a tag for commits can be helpful to mark certain commits when the user archives certain milestones and later can be distinguished easily. This will be particularly helpful for making releases for their apps and can version depending upon their current nomenclature.
Why should this be worked on?
This will ease the integration of Appsmith apps to customers existing development lifecycle. This can later be used to create release notes etc.

I was referring to these tags only just expose them from the appsmith UI, so in the event users want to revert to specific commit this will make their life easier.


wiki: SQLDrivers

Drivers marked with [*] are both included in and pass the compatibility test suite

https://go.dev/wiki/SQLDrivers
The list of drivers tested has not been updated in years:
https://github.com/bradfitz/go-sql-test/blob/master/src/sqltest/drivers.go

I suggest you:
a) update the drivers to be tested and the update the wiki page afterward (and update it periodically)
b) remove the mention of the compatibility test suite
c) state that the compatibility test was done in 2019 (5 years ago)

I'm wondering if there would be any benefit from the Go team adopting this test suite, perhaps integrating it into x/tools.
Apart from that, updates to the documentation page would be appreciated.
cc @bradfitz

The list of drivers seems to be updated with a certain frequency. I guess the question is more about the test suite itself, I highly doubt the entries added to the list were tested with go-sql-test.


Getting StopIteration error

Hey,I am getting a StopIteration error when valid_generator( ) is called .The error is given below
StopIteration                             Traceback (most recent call last)
 in ()
6                     #callbacks=callbacks,
7                     validation_data=valid_generator(),
----> 8                     validation_steps=np.ceil(float(len(ids_valid_split)) / float(batch_size)))
/Users/shivamchandhok/anaconda2/lib/python2.7/site-packages/keras/legacy/interfaces.pyc in wrapper(*args, **kwargs)
85                 warnings.warn('Update your ' + object_name +      86                               ' call to the Keras 2 API: ' + signature, stacklevel=2)
---> 87             return func(*args, **kwargs)
88         wrapper._original_function = func
89         return wrapper
/Users/shivamchandhok/anaconda2/lib/python2.7/site-packages/keras/engine/training.pyc in fit_generator(self, generator, steps_per_epoch, epochs, verbose, callbacks, validation_data, validation_steps, class_weight, max_queue_size, workers, use_multiprocessing, initial_epoch)
1807                 batch_index = 0
1808                 while steps_done < steps_per_epoch:
-> 1809                     generator_output = next(output_generator)
1810
1811                     if not hasattr(generator_output, 'len'):
StopIteration:

Can't reproduce this issue. Is your Keras version up-to-date? If you remove validation from fit_generator do you still get the error?

yes the error is still there.
there is some issue with the line
generator_output=next(output_generator)

Have you tried on another Python environment?

My problem was that the train_mask data is the gif format. Converting them to png may solve this.

OpenCV doesn't read GIF. You can easily switch to sklearn.io.imread

Getting the same error...please help

@ykataoka  Converting them to png didn't solve this issue. Any other solutions?


[Bug]: "snowflake_tag_association" failing if table was recreated without a tag outside of Terraform

Terraform CLI Version
1.9.2
Terraform Provider Version
0.93.0
Terraform Configuration
resource "snowflake_tag" "privacy_tag" {
  database = "DB"
  name = "PRIVACY_TAG"
  schema = "TAG_LIBRARY"
  allowed_values = ["NO_CLASSIFICATION","OBJECT_ID","PERSONAL_DATA","PII"]
  comment = "high level column level tagging to categorise sensitive data for Snowflake data classification"
}

resource "snowflake_tag_association" "tag_pii_columns_prod_db" {
  object_identifier {
    name     = "EXAMPLE_TABLE.COLUMN"
    database = "DB"
    schema   = "EXAMPLE_SCHEMA"
  }
  object_type = "COLUMN"
  tag_id      = snowflake_tag.privacy_tag.id
  tag_value   = "PERSONAL_DATA"
}

Category
category:resource
Object type(s)
resource:tag_association
Expected Behavior
Provider identifies that tag was removed from column, plans to add it.
Actual Behavior
Error: sql: Scan error on column index 0, name "TAG": converting NULL to string is unsupported
Steps to Reproduce

Create a snowflake_tag_association resource to tag a column
Run terraform apply
Drop the table
Create the same table
Run terraform plan or terraform apply

How much impact is this issue causing?
High
Logs
No response
Additional Information
Issue could potentially be around this line -> https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/da98bc3f5f37f721fed623d7ab110e75ff9557e2/pkg/sdk/system_functions.go#L28
Would you like to implement a fix?

[ ] Yeah, I'll take it 😎

Hi @dbieliaiev 👋
Tags will be redesigned as part of https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#preparing-essential-ga-objects-for-the-provider-v1. I will link this issue to https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/v1-preparations/ESSENTIAL_GA_OBJECTS.MD.

Hi @dbieliaiev  👋
We've just released v0.100.0 (release, migration guide) in which we reworked tag associations. Unassigned tags should now be detected and corrected in terraform apply.
Please upgrade to this version and let us know if you have any issues.


improve layout of user profile actions

https://stackblitz.com/run?file=src%2Fapp%2Fcdk-menu-standalone-menu-example.ts
according to the example above merge user profile actions into a menu
Menu content:
Change password
Sign out


Start using the new aos-art-automation address

In general this change makes it such that automated emails don't go
directly to the team email address. This hits most of the big
spammers. Changes follow this format.

'to' field is aos-art-automation+SOME_TOPIC@, OTHER_PEOPLE@
'replyTo' field is always the team email address
'from' will include aos-art-automation@

LGTM! Great idea to enable better filters!


[SPARK-34473][SQL] Avoid NPE in DataFrameReader.schema(StructType)

What changes were proposed in this pull request?

This fixes a regression in DataFrameReader.schema(StructType), to avoid NPE if the given StructType is null. Note that, passing null to Spark public APIs leads to undefined behavior. There is no document mentioning the null behavior, and it's just an accident that DataFrameReader.schema(StructType) worked before. So I think this is not a 3.1 blocker.
Why are the changes needed?

It fixes a 3.1 regression
Does this PR introduce any user-facing change?

yea, now df.read.schema(null: StructType) is a noop as before, while in the current branch-3.1 it throws NPE.
How was this patch tested?

It's undefined behavior and is very obvious, so I didn't add a test. We should add tests when we clearly define and fix the null behavior for all public APIs.

cc @yaooqinn @HyukjinKwon

Test build #135269 has started for PR 31593 at commit 8306ab2.

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

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

Shall we fix DataStreamReader too?

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

Test build #135269 has finished for PR 31593 at commit 8306ab2.

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

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

Test build #135330 has started for PR 31593 at commit 8a38f52.

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

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

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

Test build #135330 has finished for PR 31593 at commit 8a38f52.

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

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

Test build #135341 has started for PR 31593 at commit 643f002.

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

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

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

thanks for the review, merging to master/3.1!

Test build #135341 has finished for PR 31593 at commit 643f002.

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

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

+1, late LGTM.


Fix parser horusec

I'm doing this update because when trying to import a report from Horusec you get the following error:

I noticed that the reports of the new version of Horusec the "line" comes empty where it ends up breaking the parser of the integer:

I opened a new PR: https://github.com/DefectDojo/django-DefectDojo/pull/6563


Update sbt to 1.4.6

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

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

labels: library-update, semver-patch

Pull Request Test Coverage Report for Build 145

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 72.327%

Totals

Change from base Build 144:
0.0%

Covered Lines:
115

Relevant Lines:
159

💛  - Coveralls

Superseded by #56.

Superseded by #56.


fix(data-table): selection column style overlap

close #4298

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

Coverage data is based on head (e39c4e0) compared to base (a822751).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4299   +/-   ##
=======================================
  Coverage   62.50%   62.50%
=======================================
  Files        1069     1069
  Lines       22420    22420
  Branches     5882     5882
=======================================
  Hits        14013    14013
  Misses       6882     6882
  Partials     1525     1525

Impacted Files
Coverage Δ

src/data-table/src/styles/index.cssr.ts
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.


[BUG] mobilenet_v2_140 is not trained

Describe the bug
mobilenet_v2_140 is not trained
To Reproduce
Steps to reproduce the behavior:

timm.create_model('mobilenetv2_140', pretrained=True)
2.run test on Imagenet
get accuracy of 0.1%@Top1

Additional context
Was tested on other models that got the reported accuracy.
It is probably a wrong checkpoint that is downloaded

@sefibk I tried on master in pytorch 1.7 and 1.8 with no issues, and last results run is fine as you can see from the csv files in results/. something wrong on your end, and you didn't provide specific version info as requiested to dig any further so I'm going to leave this.


add license

closes https://github.com/ClickHouse/control-plane/issues/4675

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


Created Running Instructions & Added Contribution Instructions

Created a Running section that details how to clone the repo and launch locally
Added Contribution Instructions including forking, cloning, and raising a PR

@catrinalim This is super awesome! Thank you for taking the time to do this.
Let me know when this PR is good to go, and I will give it a review. I think you need to request it the review.
Cheers 🍻

@Kully Hello! I am attempting to request you as a reviewer but it states I don't have the correct permissions to do so. I have attached an image of the error message:
![permission error]()
Please let me know if there's anything on my end to get this reviewed.


[wip] Add SWF support

Work in progress, do NOT merge!
See #429. This branch implements mocks for SWF endpoints, mapping directly to boto.swf.Layer1, which is the low-level layer used by boto.swf.Layer2 and libraries above. As SWF is mostly a coordination service with complex logic, so making moto/swf useful boils down to reimplementing part of the logic behind SWF (much more easy though: non distributed, few limits, no permissions).
Implementation progress
Implemented endpoints (by category):

Actions Related to Activities

[x] PollForActivityTask
[x] RespondActivityTaskCompleted
[x] RespondActivityTaskFailed
[ ] RespondActivityTaskCanceled
[x] RecordActivityTaskHeartbeat

Actions Related to Deciders

[x] PollForDecisionTask
[x] RespondDecisionTaskCompleted (partial; see below)

Actions Related to Workflow Executions

[ ] RequestCancelWorkflowExecution
[x] StartWorkflowExecution
[ ] SignalWorkflowExecution
[x] TerminateWorkflowExecution

Actions Related to Administration

Activity Management

[x] RegisterActivityType
[x] DeprecateActivityType

Workflow Management

[x] RegisterWorkflowType
[x] DeprecateWorkflowType

Domain Management

[x] RegisterDomain
[x] DeprecateDomain

Visibility Actions

Activity Visibility

[x] ListActivityTypes
[x] DescribeActivityType

Workflow Visibility

[x] ListWorkflowTypes
[x] DescribeWorkflowType

Workflow Execution Visibility

[x] DescribeWorkflowExecution
[ ] ListOpenWorkflowExecutions
[ ] ListClosedWorkflowExecutions
[ ] CountOpenWorkflowExecutions
[ ] CountClosedWorkflowExecutions
[x] GetWorkflowExecutionHistory

Domain Visibility

[x] ListDomains
[x] DescribeDomain

Task List Visibility

[x] CountPendingActivityTasks
[x] CountPendingDecisionTasks

Implemented decision types for RespondDecisionTaskCompleted endpoint:

[ ] CancelTimer
[ ] CancelWorkflowExecution
[ ] ContinueAsNewWorkflowExecution
[x] CompleteWorkflowExecution
[x] FailWorkflowExecution
[ ] RecordMarker
[ ] RequestCancelActivityTask
[ ] RequestCancelExternalWorkflowExecution
[x] ScheduleActivityTask
[ ] ScheduleLambdaFunction
[ ] SignalExternalWorkflowExecution
[ ] StartChildWorkflowExecution
[ ] StartTimer

Implemented timeout types:

[x] Workflow Execution: Execution Start to Close
[x] Decision Task: Start to Close
[x] Activity Task: Heartbeat
[ ] Activity Task: Schedule to Close
[ ] Activity Task: Schedule to Start
[ ] Activity Task: Start to Close

Implemented limits (most are hard to test or implement, this section is only there as reference):

General limits

[ ] Maximum registered domains: 100
[ ] Maximum workflow and activity types: 10,000 each per domain [likely never]
[ ] Maximum request size: 1 MB per request

Limits on Workflow Executions

[ ] Maximum open workflow executions: 100,000 per domain [likely never]
[ ] Maximum workflow execution time: 1 year [likely never]
[ ] Maximum workflow execution history size: 25,000 events [will do]
[ ] Maximum child workflow executions: 1,000 per workflow execution. [will do]
[ ] Workflow execution idle time limit: 1 year [likely never]

Limits on Task Executions

[ ] Maximum task execution time: 1 year (constrained by workflow execution time limit) [likely never]
[ ] Maximum time SWF will keep a task in the queue: 1 year (constrained by workflow execution time limit) [likely never]
[ ] Maximum open activity tasks: 1,000 per workflow execution. [will do]
[ ] Maximum open timers: 1,000 per workflow execution [will do]
[ ] Maximum input/result data size: 32,000 characters [will do]
Maximum decisions in a decision task response [will do]

Throttling limits

none: too hard and few benefits in the general case

Known limitations

permissions and request limits are not implemented, namely LimitExceededFault and OperationNotPermittedFault ; I don't think it's needed for now
pagination and max number of results are generally not implemented (nextPageToken is omitted in responses ; nextPageToken and maximumPageSize have no effect in requests) ; but I think I'll implement them because I need to test SWF limits in our client library
in case of timeouts, the timeout events are properly timestamped but the successive decisions may not be ; this is because we don't have a running daemon to handle things at regular interval, so history is computed on demand afterwards ; this will eventually be fixed

some TODO comments in the code

Some remarks

I wanted to have a working service before submitting a PR, but I do understand that it is a lot of code to review ; you can mostly follow the progress commit by commit, should be easier to handle
I'm not happy with moto.swf.responses.SWFResponse.call_action(), which is completely copied from BaseResponse except one modified line (see comment inside) ; I don't know if it could be changed though,  what do you think?
I had trouble working with freezed dates + timestamps ; Travis assumes dates are in UTC it seems, so I personnally run the tests with TZ=GMT; don't know if it should be part of the Makefile or something else
I'm not sure which names should have been namespaced, let me know ; "Timeout" for instance may be too generic (?)
I wonder where to keep some documentation, especially where to keep track of a status of what is implemented like I did above

As a general remark, I'm just a beginner in Python so let me know if you see any improvement, I'd be happy to learn.
Also I realize the end result might be a bit complicated for now. It could be simplified or released as a separate lib if you tell me so.
I'll continue to work on this PR in the next few days. Thanks!

This is looking great!
I have no problem merging now and then we can have subsequent pull requests for additional features. Your call. Let me know when you would like me to start reviewing.

Thanks! The current state allows for running administrative tasks as long as running a basic workflow. I'd be happy if you can start reviewing now and tell me what you think of the limitations/remarks I mentionned above. This will help me to improve things in the subsequent pull requests. I'm also open if you want to discuss some things on IRC or a Slack channel, let me know.
NB: I edited the initial PR text with a new section about implemented limits, and one more point in "remarks"

After more review, I still think this is great :)
A few small comments, but pretty solid code (especially for a Python beginner). If you address a few of the comments, I would be happy for us to merge this now. I don't think any of the limitations are blockers.
You should also feel free to add yourself to AUTHORS.md

@spulec: thanks a lot for your review, lots of insights!
I'll re-push now with:

all the small things fixed
TODO now: move type checks into response to keep models clean
TODO now: refactor the history events handling (I agree it was a bit ugly)
TODO later: use werkzeug exceptions instead of boto ones ; not sure how I'll do that, see my comment above ; but I'll dig into that

I should have the 2 "TODO now" done before tomorrow, if you're OK we could merge this once they're done.
Thanks again!

@spulec: done as for the two minor "TODOs", sorry for the delay. I let you review the last commits when you have some time. Let me know what you think for the errors base exception. Thanks!

Awesome, thanks again for all your work.

Wow! Awesome job!
I wish I had seen this PR before jumping directly to httpretty for my tests.
Maybe SWF should be mentioned in the README ?

Thanks @prior! Forgot about the README yes, I'll update it in the next PR.


FW-3158 kids only content in songs/stories

Make kids only default checked

@gmcauliffe missed your note on FW-3158


IGAPP-495: Content of page on first level not displayed

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword IGAPP.

Please also test with Regensburg (Stadt)/Language, school, university/{School, University Study} and change the language to arabic.
After the update of the package react-native-render-html they changed the property rawChildren in the passProps to transientChildren. Please change this. :)

@tagotty I don't really understand the comment to be honest, but I guess you're right. However, I don't have time today or tomorrow therefore I'll merge it. Do you think you could test it? Otherwise I'll add it to my todos and will do it some time next week.

@tagotty I don't really understand the comment to be honest, but I guess you're right. However, I don't have time today or tomorrow therefore I'll merge it. Do you think you could test it? Otherwise I'll add it to my todos and will do it some time next week.

If you don't have time i'll fix it in a separate pr.
This PR I already tested. And it at least displays all inner contents without lists 👍🏼
Feel free to merge.


AttributeError: 'Flask' object has no attribute 'before_first_request'

Hi All, the error is obviously related to Flask rather than the sample apps but the stack trace at the bottom shows the exception is raised in dash.py and I got it after executing
...\dash-clinical-analytics>python -m venv .venv
...\dash-clinical-analytics>.venv\Scripts\activate
(.venv) ...\dash-clinical-analytics>pip install -r requirements.txt

in an up-to-date working copy of the Dash sample app dash-clinical-analytics/.
The pip install command finished with
Successfully installed Flask-2.3.2 Jinja2-3.1.2 MarkupSafe-2.1.2 Werkzeug-2.3.4 async-generator-1.10 attrs-23.1.0 beautifulsoup4-4.12.2 blinker-1.6.2 brotli-1.0.9 certifi-2023.5.7 cffi-1.15.1 charset-normalizer-3.1.0 click-8.1.3 colorama-0.4.6 dash-1.0.0 dash-core-components-1.0.0 dash-html-components-1.0.0 dash-renderer-1.0.0 dash-table-4.0.0 datetime-4.3 exceptiongroup-1.1.1 flask-compress-1.13 gunicorn-20.1.0 h11-0.14.0 idna-3.4 importlib-metadata-6.6.0 iniconfig-2.0.0 itsdangerous-2.1.2 lxml-4.9.2 numpy-1.24.3 outcome-1.2.0 packaging-23.1 pandas-2.0.1 pathlib-1.0.1 percy-2.0.2 plotly-5.14.1 pluggy-1.0.0 pycparser-2.21 pysocks-1.7.1 pytest-7.3.1 pytest-mock-3.10.0 pytest-sugar-0.9.7 python-dateutil-2.8.2 pytz-2023.3 requests-2.31.0 selenium-4.9.1 six-1.16.0 sniffio-1.3.0 sortedcontainers-2.4.0 soupsieve-2.4.1 tenacity-8.2.2 termcolor-2.3.0 tomli-2.0.1 trio-0.22.0 trio-websocket-0.10.2 tzdata-2023.3 urllib3-2.0.2 waitress-2.1.2 wsproto-1.2.0 zipp-3.15.0 zope.interface-6.0

so I continued doing
...\dash-clinical-analytics>call .venv\Scripts\activate
(.venv) ...\dash-clinical-analytics>python app.py
Traceback (most recent call last):
  File "app.py", line 12, in <module>
    app = dash.Dash(
  File "...\dash-clinical-analytics\.venv\lib\site-packages\dash\dash.py", line 337, in __init__
    self.init_app()
  File "...\dash-clinical-analytics\.venv\lib\site-packages\dash\dash.py", line 376, in init_app
    self.server.before_first_request(self._setup_server)
AttributeError: 'Flask' object has no attribute 'before_first_request'

I found the closed issue AttributeError: type object 'Flask' has no attribute 'before_first_request' with Flask > 2.2.4 but seem to be unable to derive any way for getting the dash-clinical-analytics sample app to run.
Any help is greatly appreciated, thanks!
I'm on Windows 10 using Python 3.8.8

I was able to work around this by setting Flask==2.1.3 in requirements

I was able to work around this by setting Flask==2.1.3 in requirements

That worked for me, too. Thank you so much!


release using cargo-dist

Fixes: https://github.com/EricLBuehler/mistral.rs/issues/263
As of now, musl and windows based build are disabled because they were breaking, I can take a look at fixing those later.
I created a release on my fork here: https://github.com/kranurag7/mistral.rs/releases/tag/v0.1.24

Hi @kranurag7! Thanks for adding this. I noticed you added a few new CI steps: build-global-artifacts, host, announce. I was wondering if you could give a quick overview of what you added and generally how it works? In particular, we already use GH releases to create tags and track releases, so I'm not sure if that would be affected by the new announce step?

As of now, musl and windows based build are disabled because they were breaking, I can take a look at fixing those later.

Sounds good.

The build jobs builds the artifacts and then we create a release in GitHub. This means you'll get your release assets uploaded and a table which will ease the downloading of tarballs for users.
See https://github.com/kranurag7/mistral.rs/releases/tag/v0.1.24
This is what is done in the last announce step. It as the last stage which gets executed after the build is finished.
From what I see, you push a tag to build the image via two workflow.

build_cpu.yaml and build_cuda_all.yaml

This workflow extends that, now when you push the tag, you'll have your binaries present as well on the releases.

so glad to see this! sorry i dropped the ball on actually making the PR.
in case it's not clear, the tool cargo-dist fully generates the workflow. to update the workflow, you'll use the cargo-dist tool and edit config in your Cargo.toml. to update- you can run cargo dist selfupdate which will fetch the new version of cargo-dist and also run cargo dist init which will ask you some questions and re-gen your workflows. we do not recommend you hand edit the workflow and cargo-dist will complain if you do (you can tell it to stop, but again, we don't recommend that). feel free to ask me if you have any questions or hop in our discord, https://discord.gg/qzzYcWPh


add js-file title-edit

Coverage remained the same at 46.617% when pulling 7e9d2d6f5bc5a4bb824e4884e8b6f11b32133195 on jorjoh:master into 853a126dd8b61cf8580dc8fc887bd174b6c73990 on telemark:master.


Fix IConfiguration to HOCON adapter

Fixes #351
Changes

Default behaviour change, only configurations pulled from the environment variables are automatically converted to lower case
Update documentation

Solution rejected due to use of reflection magic

Hi @Arkatufus,
I also not pleasant with this solution, as it uses reflection. And has some methods that return NotImplementedException, it reminds me a smell of Interface Segregation problem. Another issue IMHO is that the code is not easy to understand, simple and needs comments.
@Aaronontheweb
My first proposal is detecting strings in double quotes and lowercase others, as I saw the HOCON, only strings enclosed in double quotes are case-sensitive, such as "System.Object" = hyperion in serialization-bindings