Multiple problems with text, print to pdf, flunks in conversions and rendering

Computer: Toshiba with Core i3
Web: Google Chrome
I have two huge problems for me since I'm no expert on making PDF's and the like so I'll list said problems:

The brews that I create are not stable, after leaving them for a while, the text shifts unpredictably (but mostly moves upwards) which seems to be a bug of some sort and I cant fix it. When I press enter in the middle of the text (and then delete the change), it goes back to normal which I also don't understand (I'll show an example later).

When I try to save as PDF, the preview looks fine but after I try to save it as PDF, this happens (The bottom part is completely white as if the page is smaller than it should be)

Before as a webpage:
http://homebrewery.naturalcrit.com/print/r1QU9oWz1f?dialog=true
After as a PDF:
file:///C:/Users/TOSHIBA/Downloads/The%20Homebrewery%20-%20NaturalCrit%20TEST.pdf

This issue was opened 3 years ago, so just reviewing to see if it can be closed: I think it can be.  @calculuschild @ericscheid

I haven't seen problems with shifting text myself in all the hours using it, and haven't seen it raised as an issue elsewhere (either here on github or the subreddit)...so perhaps it has been fixed in the meantime?  Would be impossible to know unless someone reports it again.

I suspect that the white space at the bottom of the page was due to a mismatch of the page size in Homebrewery and what the "save to pdf" prompt was set to for page size.  Likely one was set to Letter size, and the other to A4 page size.  This can be adjusted by the A4 snippet (or in the Save to PDF prompt).

Side note, the image formatting is really nice in this brew.

This issue was opened 3 years ago, so just reviewing to see if it can be closed: I think it can be.  @calculuschild @ericscheid

I haven't seen problems with shifting text myself in all the hours using it, and haven't seen it raised as an issue elsewhere (either here on github or the subreddit)...so perhaps it has been fixed in the meantime?  Would be impossible to know unless someone reports it again.

I suspect that the white space at the bottom of the page was due to a mismatch of the page size in Homebrewery and what the "save to pdf" prompt was set to for page size.  Likely one was set to Letter size, and the other to A4 page size.  This can be adjusted by the A4 snippet (or in the Save to PDF prompt).

Side note, the image formatting is really nice in this brew.

Duplicate of #295
As for 1, it looks like a duplicate of #295, which I'm not sure ever got solved. We can close this as a duplicate though. I think you are right about 2.
@Gigglebert, if you are still having this issue, take a look at #295 and see if that matches your situation. Otherwise feel free to reopen this issue.

Duplicate of #295
As for 1, it looks like a duplicate of #295, which I'm not sure ever got solved. We can close this as a duplicate though. I think you are right about 2.
@Gigglebert, if you are still having this issue, take a look at #295 and see if that matches your situation. Otherwise feel free to reopen this issue.

Duplicate of #295

Duplicate of #295


site: Don't capitalize engine names

Babel+core-Js ES5 looks wack :)

Actually renamed to just Babel locally (since version info shows full info), but this is nice for properly capitalizing engine262 (and future) too!


Update ProximityPlacementGroupType description to scope out 'Ultra' from usage

Latest improvements:
This PR for updating description of ProximityPlacementGroupType (added in https://github.com/Azure/azure-rest-api-specs/pull/5507).  ProximityPlacementGroupType can assume value 'Standard' or 'Ultra'. ProximityPlacementGroupType 'Ultra' is not supported. Support for 'Ultra' shall be added in future .
The PR is to add this detail in description of  ProximityPlacementGroupType  so that user can be informed (from documentation generated using the swagger spec) to not use 'Ultra'.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java

Can one of the admins verify this patch?

Do you want to fix Model Validation errors in this PR?

Do you want to fix Model Validation errors in this PR?

The scope of the PR is to just add the description

Only the description should be changed, as follows:
Ultra – For future use


WI_NODISCARD is not very useful because it does not create compiler warnings/errors

Closes #260
Why is this change being made?
I am converting some custom lock wrappers to wil::critical_section and was trying to demonstrate that accidentally dropping the lifetime wrapper generates an error.  Whoops, it does not.  It happily compiles with no obvious warnings and hides a severe bug.
Briefly summarize what changed
Use the C++ standard language feature to detect [[nodiscard]] support and if it is present define WI_NODISCARD to be [[nodiscard]].  If the feature is not present then the existing (mostly unhelpful) annotation is used instead.
How was this change tested?
init_all + build_all + runtests
Building from v:\T\wil\build\clang64debug
[85/85] Linking CXX executable tests\win7\witest.win7.exe
Building from v:\T\wil\build\clang64relwithdebinfo
[85/85] Linking CXX executable tests\win7\witest.win7.exe
Building from v:\T\wil\build\msvc64debug
[86/86] Linking CXX executable tests\win7\witest.win7.exe
Building from v:\T\wil\build\msvc64relwithdebinfo
[86/86] Linking CXX executable tests\win7\witest.win7.exe
All build completed successfully

There was one test failure that seems unrelated (case sensitivity error):
V:\T\wil\tests\FileSystemTests.cpp(613): FAILED:
  REQUIRE( procName == moduleName )
with expansion:
  "V:\T\wil\build\clang64debug\tests\cpplatest\witest.cpplatest.exe"
  ==
  "v:\T\wil\build\clang64debug\tests\cpplatest\witest.cpplatest.exe"
===============================================================================
test cases:    190 |    189 passed | 1 failed
assertions: 111716 | 111715 passed | 1 failed

I also overwrote the macro in the copy of WIL for an existing project and intentionally dropped the lock object.
auto lock = wil::critical_section;
lock.lock(); // discarding lock lifetime object

warning C4834: discarding return value of function with 'nodiscard' attribute
error C2220: the following warning is treated as an error

Now I am super confused.  I dug a little deeper and [[nodiscard]] should be getting defined here: https://github.com/microsoft/wil/blob/master/include/wil/wistd_config.h#L186.

The version is 14 so it does not use [[nodiscard]]

[[nodiscard]] was added in c++17: https://en.cppreference.com/w/cpp/language/attributes/nodiscard

I think the version checking in WIL is wrong for this project.  If I apply this edit to the header used by that project then it works exactly as intended (that is where the warning output came from).

Then I'm confused by your comment. Were you saying that your project is using c++14 or something else?

I am now super confused too.  I took a closer look at our project files and I don't see where the C++ standard is being set.  As a result it seems to be defaulting to C++14.  But that is very weird because [[nodiscard]] feature checking evaluated to true and produced the expected build break.  If it is truly C++14 then it should have broken in a different way.

Interesting. Looks like Clang also allows things like [[nodiscard]] when compiling with older C++ versions: https://godbolt.org/z/e77EW3d1r
We can probably do something like this which will "turn on" the feature, even in situations where it probably shouldn't:
#ifdef __has_cpp_attribute
#if __has_cpp_attribute(nodiscard)
#define __WI_LIBCPP_NODISCARD_ATTRIBUTE [[nodiscard]]
#endif
#endif

#ifndef __WI_LIBCPP_NODISCARD_ATTRIBUTE
#if __WI_LIBCPP_STD_VER > 14
#define __WI_LIBCPP_NODISCARD_ATTRIBUTE [[nodiscard]]
#else
#define __WI_LIBCPP_NODISCARD_ATTRIBUTE _Check_return_
#endif
#endif

MSVC and NVCC both also support [[nodiscard]] downlevel, because it helps make code safer (the STL/other libraries can add nodiscard to functions and client code will get warnings even when using C++14).
I think the #elif __WI_LIBCPP_STD_VER > 14 branch is redundant however, simply a check for defined(__has_cpp_attribute) && __has_cpp_attribute(nodiscard) should be enough

I think the #elif __WI_LIBCPP_STD_VER > 14 branch is redundant

From what I can gather, [[nodiscard]] was added in VS 2017 15.3, but __has_cpp_attribute wasn't added until VS 2019 16.0: https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-170. I did see something that suggests 15.8 had support for __has_cpp_attribute, but that's (1) from a third party and I can't confirm if that's true or not, and (1) it's also later than 15.3

simply a check for defined(__has_cpp_attribute) && __has_cpp_attribute(nodiscard) should be enough

You can't do a defined(xyz) check and use it in the same directive (else you'll get xyz is not a function style macro errors.

Arguably, the C++ version check is probably wrong (I'm not sure when the _MSVC_LANG version got bumped). That said, I haven't seen reports of a finer-grained _MSC_FULL_VER check being needed.

Any updates on this?

I haven't touched the project where I needed this for ~2 weeks.  This is on my list of things to revisit when I am there next.

Closing this out because I have not yet returned to the code base where I thought I needed this and it is unlikely that I will in the future.  This is also much more complicated than I realized and I don't have the time to fully understand it.


fix: 0 is truthy 🤦♂

Description
Fixes a bug where hasNegativeRatio would be false if inputOutputRatio was 0.
Notice

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
N/A
Risk
Very small.
Testing
Couple with an incoming lib PR. TODO.
Engineering
Operations
Screenshots (if applicable)
N/A

Current dependencies on/for this PR:

develop

PR #4177   👈

PR #4159

This comment was auto-generated by Graphite.


Sync and review climaccf fork

Description
Previously the dlr-pa/climaccf repository would only work on older versions of Python. We chose to fork the repository to contrailcirrus/climaccf to create the example ACCF.ipynb.
The origin repository has since been updated and we should investigate if we need this fork anymore.
Additional context
This will be relevant to CICONIA.

Updated contrailcirrus/climaccf to reflect the latest changes from dlr-pa/climaccf.  Unfortunately dlr-pa/climaccf still pins to an older version of numpy so our fork is still needed for now


[Bug]: Regression CDP/BiDi when serializing a typed array

Minimal, reproducible example
import puppeteer from "puppeteer";

(async () => {
  const browser = await puppeteer.launch({
    product: "firefox", // "chrome",
    headless: false,
    protocol: "webDriverBiDi", // "cdp"
  });

  const page = await browser.newPage();
  await page.goto(`data:text/html,
<html>
<script>
window.foo = Uint8Array.from([123]);
</script>
</html>
  `);
  await page.bringToFront();

  await page.waitForFunction(() => !!window.foo);
  const foo = await page.evaluate(() => window.foo);

  await page.close();
  await browser.close();

  if (foo === undefined) {
    throw new Error("Serialized array buffer is undefined");
  }
})();

Error string
Serialized array buffer is undefined
Bug behavior

[ ] Flaky
[ ] PDF

Background
No response
Expectation
With CDP, we got something and it was possible to test it. Unfortunately, with BiDi, there's nothing to test.
Reality
In Firefox/Chrome, the behavior is the same: the typed array is serialized into undefined
Puppeteer configuration file (if used)
No response
Puppeteer version
22.10.0
Node version
18.19.1
Package manager
npm
Package manager version
10.2.4
Operating system
Linux

Here's a log from Firefox:
plop.log

@Lightning00Blade PTAL

This is not a supported operation by the WebDriverBiDi spec at the moment [TypedArrayRemoteValue ].
(https://w3c.github.io/webdriver-bidi/#:~:text=internalId%3A script.InternalId%2C
}-,script.TypedArrayRemoteValue,-%3D {
  type%3A "typedarray"%2C
  %3F handle).
The current implementation of Firefox and Chrome is correct and expected as it follows the spec.
It's only possible to get as a handle - for Puppeteer that is via page.evaluateHandle.
Could you explain your use case and what and why other methods don't work for your use case as well?

To clarify, CDP explicitly serialized to JSON while BiDi serialization aims at maintaining the actual types and TypedArrays are not supported. You can use
const foo = await page.evaluate(() => JSON.stringify(window.foo));

To serialize to JSON.

I want to have a test where a value is a typed array.
That said, I workarounded the issue in converting the typed array into an array before serializing it:
https://github.com/mozilla/pdf.js/pull/18163/files#diff-9a5f53e72714b4209a2aa581af6e316d1908ce47d7d3d4992ae6a99174fc4869
The returned value is tested in node:
https://github.com/mozilla/pdf.js/blob/17e09e54785ed09dd3417983c3ed4085e8ee1fa4/test/integration/highlight_editor_spec.mjs#L317-L329

@calixteman would you mind filing a feature request for the WebDriver BiDi specification?

Done:
https://github.com/w3c/webdriver-bidi/issues/720


Can't get an IP address from vtrust-flash

Hi,
I'm trying to use a raspberry pi 4 with latest raspbian (debian buster) in order to flash a device, but I'm stuck before flashing. My phone can see the vtrust-flash SSID, but when it tries to connect it gets no IP address.
Clone and install prereq are successful. When I start the script I get this:
pi@raspberrypi:~/tuya-convert/tuya-convert $ ./start_flash.sh
Checking for network interface wlan0... Found.
Checking UDP port 53... Available.
Checking UDP port 67... Available.
Checking TCP port 80... Available.
Checking TCP port 443... Available.
Checking UDP port 6666... Available.
Checking UDP port 6667... Available.
Checking TCP port 1883... Occupied by mosquitto with PID 1726.
Port 1883 is needed to run MQTT
Do you wish to terminate mosquitto? [y/N] y
Attempting to terminate mosquitto
Checking TCP port 8886... Available.
======================================================
  Starting AP in a screen
  Starting web server in a screen
  Starting Mosquitto in a screen
  Starting PSK frontend in a screen
  Starting Tuya Discovery in a screen

======================================================

IMPORTANT
1. Connect any other device (a smartphone or something) to the WIFI vtrust-flash
   This step is IMPORTANT otherwise the smartconfig may not work!
2. Put your IoT device in autoconfig/smartconfig/pairing mode (LED will blink fast). This is usually done by pressing and holding the primary button of the device
   Make sure nothing else is plugged into your IoT device while attempting to flash.
3. Press ENTER to continue

So everything seems ok too.
        Ss   20:55   0:00 SCREEN -L -Logfile smarthack-wifi.log -S smarthack-wifi -m -d ./setup_ap.sh
root      2171  0.0  0.3   7676  2844 pts/2    Ss+  20:55   0:00 /bin/bash ./setup_ap.sh
root      2201  0.0  0.0      0     0 ?        I    20:55   0:00 [kworker/3:2-ipv6_addrconf]
nobody    2230  0.0  0.2  11076  1912 ?        S    20:55   0:00 dnsmasq --no-resolv --interface=wlan0 --bind-interfaces --listen-address=<IP_ADDRESS> --dhcp-range=<IP_ADDRESS>,<IP_ADDRESS>,12h --address=/#/10.42.42
root      2235  0.0  0.3   9948  3172 pts/2    S+   20:55   0:00 sudo hostapd /dev/stdin
root      2241  0.0  0.1   7440  1456 pts/2    S+   20:55   0:00 hostapd /dev/stdin
root      2249  0.0  0.2   8132  2076 ?        Ss   20:55   0:00 SCREEN -L -Logfile smarthack-web.log -S smarthack-web -m -d ./fake-registration-server.py
root      2251  1.3  1.7  24764 16232 pts/3    Ss+  20:55   0:07 python3 ./fake-registration-server.py
root      2260  0.0  0.2   8132  2180 ?        Ss   20:55   0:00 SCREEN -L -Logfile smarthack-mqtt.log -S smarthack-mqtt -m -d mosquitto -v
mosquit+  2262  0.0  0.5   8776  4920 pts/4    Ss+  20:55   0:00 mosquitto -v
root      2271  0.0  0.2   8132  2208 ?        Ss   20:55   0:00 SCREEN -L -Logfile smarthack-psk.log -S smarthack-psk -m -d ./psk-frontend.py -v
root      2273  0.0  0.7  15580  7416 pts/5    Ss+  20:55   0:00 python2 ./psk-frontend.py -v
root      2282  0.0  0.2   8132  2084 ?        Ss   20:55   0:00 SCREEN -L -Logfile smarthack-udp.log -S smarthack-udp -m -d ./tuya-discovery.py
root      2284  0.0  1.1  19944 11092 pts/6    Ss+  20:55   0:00 python3 ./tuya-discovery.py

I don't really know what else to try right now, since I can't get any clear error from anywhere.

(I just realized it may be a firewall problem, as soon as I can I'll test the hypothesis and update the bug report)

Ok, can confirm it was a firewall problem, closing the bug report.

Glad to hear you found your issue. Do you mind sharing the details of your resolution? It may concern #424 #450

In my case the problem was caused by firewalld, which by default stopped everything but HTTP/S and SSH.
The solution was just a matter of:
# /etc/init.d/firewalld stop

And everything started working again.


Setup isn't building a Python 3 Wheel.

JK it was because I didn't call setup with Python3. Chalk this up to late night coding.


Update readme.md by adding a new repository

[Insert URL to the list here]
[Explain what this list is about and why it should be included here]
By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

[ ] Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it. Instead use #2242 for incubation visibility.
[ ] Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
[ ] You have to review at least 2 other open pull requests.
Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions. Comments pointing out lint violation are allowed, but does not count as a review.
[ ] You have read and understood the instructions for creating a list.
[ ] This pull request has a title in the format Add Name of List. It should not contain the word Awesome.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ add Swift
❌ Adding Swift
❌ Added Swift

[ ] Your entry here should include a short description of the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb. It should not contain the name of the list.

✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
✅ - [Framer](…) - Prototyping interactive UI designs.
❌ - [iOS](…) - Resources and tools for iOS development.
❌ - [Framer](…)
❌ - [Framer](…) - prototyping interactive UI designs

[ ] Your entry should be added at the bottom of the appropriate category.
[ ] The title of your entry should be title-cased and the URL to your list should end in #readme.

Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.

[ ] No blockchain-related lists.
[ ] The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

[ ] Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
[ ] Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
[ ] The default branch should be named main, not master.
[ ] Includes a succinct description of the project/theme at the top of the readme. (Example)

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

[ ] It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull request will be immediately closed.
[ ] The repo name of your list should be in lowercase slug format: awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

[ ] The heading title of your list should be in title case format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

[ ] Non-generated Markdown file in a GitHub repo.
[ ] The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
[ ] Not a duplicate. Please search for existing submissions.
[ ] Only has awesome items. Awesome lists are curations of the best, not everything.
[ ] Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
[ ] Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to a maximum of half the width of the original image.
Don't include both a title saying Awesome X and a logo with Awesome X. You can put the header image in a # (Markdown header) or <h1>.

[ ] Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
[ ] Includes the Awesome badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

[ ] Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.
Must not feature Contributing or Footnotes sections.

[ ] Has an appropriate license.

We strongly recommend the CC0 license, but any Creative Commons license will work.

Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=main&template=cc0-1.0 (replace <user> and <repo> accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
Place a file named license or LICENSE in the repo root with the license text.
Do not add the license name, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text at the top of the repo.
To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.

[ ] Has contribution guidelines.

The file should be named contributing.md. The casing is up to you.
It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
The section should not appear in the Table of Contents.

[ ] All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
[ ] Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

[ ] Does not use hard-wrapping.
[ ] Does not include a CI (e.g. GitHub Actions) badge.You can still use a CI for linting, but the badge has no value in the readme.
[ ] Does not include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

It looks like you didn't read the guidelines closely enough. I noticed multiple things that are not followed. Try going through the list point for point to ensure you follow it. I spent a lot of time creating the guidelines so I wouldn't have to comment on common mistakes, and rather spend my time improving Awesome.

في الأحد، ١٢ مايو ٢٠٢٤ ٦:٥٣ م Bassam Mejlaoui @.***>
كتب:

[Insert URL to the list here]
[Explain what this list is about and why it should be included here]
By submitting this pull request I confirm I've read and complied with the
below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines
and most people miss a lot.
Requirements for your pull request

Don't open a Draft / WIP pull request while you work on the
guidelines. A pull request should be 100% ready and should adhere to all
the guidelines when you open it. Instead use #2242
https://github.com/sindresorhus/awesome/issues/2242 for incubation
visibility.
Don't waste my time. Do a good job, adhere to all the guidelines,
and be responsive.
You have to review at least 2 other open pull requests
https://github.com/sindresorhus/awesome/pulls?q=is%3Apr+is%3Aopen.
Try to prioritize unreviewed PRs, but you can also add more comments
to reviewed PRs. Go through the below list when reviewing. This requirement
is meant to help make the Awesome project self-sustaining. Comment here
which PRs you reviewed. You're expected to put a good effort into this and
to be thorough. Look at previous PR reviews for inspiration. Just
commenting “looks good” or simply marking the pull request as approved does
not count! You have to actually point out mistakes or improvement
suggestions. Comments pointing out lint violation are allowed, but does
not count as a review.
You have read and understood the instructions for creating a list
https://github.com/sindresorhus/awesome/blob/main/create-list.md.
This pull request has a title in the format Add Name of List. It
should not contain the word Awesome.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ add Swift
❌ Adding Swift
❌ Added Swift

Your entry here should include a short description of the
project/theme of the list. It should not describe the list itself.
The first character should be uppercase and the description should end in a
dot. It should be an objective description and not a tagline or marketing
blurb. It should not contain the name of the list.

✅ - iOS - Mobile operating system for Apple phones and
tablets.
✅ - Framer - Prototyping interactive UI designs.
❌ - iOS - Resources and tools for iOS development.
❌ - Framer
❌ - Framer - prototyping interactive UI designs

Your entry should be added at the bottom of the appropriate category.
The title of your entry should be title-cased and the URL to your
list should end in #readme.

Example: - Software Architecture -
The discipline of designing and building software.

No blockchain-related lists.
The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

Has been around for at least 30 days.
That means 30 days from either the first real commit or when it was
open-sourced. Whatever is most recent.

Run awesome-lint https://github.com/sindresorhus/awesome-lint on
your list and fix the reported issues. If there are false-positives or
things that cannot/shouldn't be fixed, please report it
https://github.com/sindresorhus/awesome-lint/issues/new.

The default branch should be named main, not master
https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/
.

Includes a succinct description of the project/theme at the top of
the readme. (Example)
https://github.com/willempienaar/awesome-quantified-self

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull
request will be immediately closed.

The repo name of your list should be in lowercase slug format:
awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

The heading title of your list should be in title case
https://capitalizemytitle.com/ format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

Non-generated Markdown file in a GitHub repo.

The repo should have awesome-list & awesome as GitHub topics
https://help.github.com/articles/about-topics. I encourage you to
add more relevant topics.

Not a duplicate. Please search for existing submissions.

Only has awesome items. Awesome lists are curations of the best, not
everything.

Does not contain items that are unmaintained, has archived repo,
deprecated, or missing docs. If you really need to include such items, they
should be in a separate Markdown file.

Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the
readme. (Example) https://github.com/sindresorhus/awesome-electron
The image should link to the project website or any relevant
website.
The image should be high-DPI. Set it to a maximum of half the
width of the original image.
Don't include both a title saying Awesome X and a logo with Awesome
X. You can put the header image in a # (Markdown header) or .

Entries have a description, unless the title is descriptive enough
by itself. It rarely is though.

Includes the Awesome badge
https://github.com/sindresorhus/awesome/blob/main/awesome.md#awesome-badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics
header.

Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists
https://commonmark.org/help/tutorial/10-nestedLists.html,
preferably none.
Must not feature Contributing or Footnotes sections.

Has an appropriate license.

We strongly recommend the CC0 license
https://creativecommons.org/publicdomain/zero/1.0/, but any Creative
Commons license https://creativecommons.org/choose/ will work.

Tip: You can quickly add it to your repo by going to this URL:
https://github.com/
//community/license/new?branch=main&template=cc0-1.0
(replace  and  accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not
acceptable. Neither are WTFPL and Unlicense https://unlicense.org.
Place a file named license or LICENSE in the repo root with the
license text.
Do not add the license name, text, or a Licence section to the
readme. GitHub already shows the license name and link to the full text at
the top of the repo.
To verify that you've read all the guidelines, please comment on
your pull request with just the word unicorn.

Has contribution guidelines
https://github.com/sindresorhus/awesome/blob/main/awesome.md#include-contribution-guidelines.

The file should be named contributing.md. The casing is up to you.
It can optionally be linked from the readme in a dedicated
section titled Contributing, positioned at the top or bottom of the
main content.
The section should not appear in the Table of Contents.

All non-important but necessary content (like extra copyright
notices, hyperlinks to sources, pointers to expansive content, etc) should
be grouped in a Footnotes section at the bottom of the readme. The
section should not be present in the Table of Contents.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash.
Example: - AVA - JavaScript test runner.
The description starts with an uppercase character and ends with
a period.
Consistent and correct naming. For example, Node.js, not NodeJS
or node.js.

Does not use hard-wrapping
https://stackoverflow.com/questions/319925/difference-between-hard-wrap-and-soft-wrap
.

Does not include a CI (e.g. GitHub Actions) badge.
You can still use a CI for linting, but the badge has no value in the
readme.

Does not include an Inspired by awesome-foo or Inspired by the
Awesome project kinda link at the top of the readme. The Awesome badge
is enough.

Go to the top and read it again.
You can view, comment on, or merge this pull request online at:
https://github.com/sindresorhus/awesome/pull/3046
Commit Summary

c840e80
https://github.com/sindresorhus/awesome/pull/3046/commits/c840e8083b2ef5cc4eb1fb8abdd61f9c58a30edb
Update readme.md

File Changes
(1 file https://github.com/sindresorhus/awesome/pull/3046/files)

M readme.md
https://github.com/sindresorhus/awesome/pull/3046/files#diff-5a831ea67cf5cf8703b0de46901ab25bd191f56b320053be9332d9a3b0d01d15
(1)

Patch Links:

https://github.com/sindresorhus/awesome/pull/3046.patch
https://github.com/sindresorhus/awesome/pull/3046.diff

—
Reply to this email directly, view it on GitHub
https://github.com/sindresorhus/awesome/pull/3046, or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCTFOWWNNBDFF4QZS3UHDPLZB6GBDAVCNFSM6AAAAABHS5EPBCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4TCMZZGM2DANI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@Hhiskedk145 learn to use a computer...

You Ok


Infinite loading screen

Since last night and this morning a small SE update was released not sure if it was game or a mod or w/e but since then with plugin loader installed (exe file in bin 64) game wont work gets stuck in a infinite unloading screen or a error occurs. deleted the exe from bin 64 and game works fine. Ive removed all plugins and mods from the menu and it still occurred only fix was removing exe file from bin 64.

I will need a game log from when the error happened

Hi, yeah, I'm having the same problem right now, how would I get the log for it.


auth.admin.createUser with password_hash does not save correct hash and id does not save

Bug report

[X] I confirm this is a bug with Supabase, not with my own application.
[X] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
Use the admin sdk to create a new user passing a password_hash does not save the correct password hash:
                let result = await supabase.auth.admin.createUser({
                    id: legacyUser.Id as string,
                    email: legacyUser.EMailAddress as string,
                    password_hash: legacyUser.PasswordHash as string,
                    phone: legacyUser.PhoneNumber as string,
                    email_confirm: true,
                    phone_confirm: true,
                    app_metadata: {

                    }
                });

Expected behavior
The admin sdk should accept setting the password_hash and the id if it is a uuid.
System information

OS: macOs
Version of supabase-js: 2.44.4
Version of Node.js: 22.3.0

does not save correct hash and id does not save

hey @jmarbutt, what error are you getting? it will be alot easier for us to investigate the issue if you can open a ticket on https://supabase.help and indicate that i've directed you from this gh issue

@kangmingtay there is no error, it just doesn't save it to the db.

@jmarbutt have you opened a ticket with us yet?


ui: show chat-engines dropdown to all users including normal users

Make sure all useless chat engines are cleared.

How about adding a public var and set default value to yes

Furthermore, the Chat Engine's visibility should be affected by several conditions:

Chat Engine's public or admin_only field.
Linked Knowledge Base's visibility.
All related components well-configured.


Fix #4 - Updating to custom elements v1

I needed a Custom Elements V1 implementation, I used @0xR 's version in #4  as base to do a es6 class-based implementation.
As @0xR said, when transpiling to es5, you need native-shim.js (see here for more explanations).
About @bspaulding three questions :

What's support look like for v1?

According to Can I use? the support of v1 shines now: Chrome and Safari already have it, Firefox will have it in next version (Firefox 59). And for current and old Firefox, Edge or old Safari and Chrome, you have the polyfill.
The support of V0 is way poorer, only Chrome implements if, and you can use an old polyfill to make it work in other browsers. And even Chrome will drop the support, as it's an outdated spec.

How can we supply versions compatible with v0 and v1 and let the user decide which they require?

Well, I think you could offer two versions of the packager... or, wait a second (I'm thinking while I write...),  two exports! One for v0 and another for v1!
But I am not sure if it would be useful...

As a consumer, what's exceptional about v1 that I would require it over v0?

Well, V1 is already way better supported either natively on Chrome, Safari and soon Firefox or with a faster and leaner polyfill in other browsers.
I'm putting a PR on this, and if you want I can try to put the two exports version, that could allow you to support both v1 and v2.
What do you think ?
Note: I am not sure how you generate the bundle, I have used npx webpack but it generates me a umd module bigger than your bundle. Feel free to overwrite it, and please tell me how to generate the right bundle

Thanks a lot!
I have also began another PR updating babel and webpack dependencies versions, as the current versions are rather outdated. I am not sure if you would be interested on that too...

OK, master runs a simple test in chrome on circleci. If you wouldn't mind rebasing your branch?

Oh, of course, no problem in rebasing. What kind of rebasing would  you like? My branch has only one commit, you want me to rename it or to do something different?
About the card on https://github.com/bspaulding/preact-custom-element/projects/1#card-8007882 on Firefox and native shim, I am not sure to understand it. For me the problem with native shim isn't in Firefox, it happens in chrome or safari, that has Custom Elements v1 support. It happens because the custom elements v1 spec is not compatible with ES5 style classes. This means ES2015 code compiled to ES5 will not work with a native implementation of Custom Elements, so in order to webpack generate an ES5 implementation that Chorme and Safari could use you need to put the (rather minimal) shim in the project. Loading this shim minimally augments the native implementation to be compatible with ES5 code.  Without the shim you would get an error:
Uncaught TypeError:  Failed to construct 'HTMLElement': Please use the 'new' operator, this DOM object constructor cannot be called as a function.

@LostInBrittany Just rebase onto the latest master, so circle will run the tests on these changes.
The FF question is a little off-topic here, but basically FF59 is not out as stable yet, so FF currently fails in the same way. I've promoted that card to an issue, so if you have more thoughts / questions on that, let's do that there.

So I'm closing this one, and keeping instead #11, the same but without Shadow DOM


Calling this.super() from outside extended methods scope.

Hi,
I am working on an extension of  element. I am extending the "go" method of the core element, to return a promise that will be resolved on a response from server.
I got it to work, but while implementing it, I had an issue to call 'this.super()' form inside the promise, even though the "this" argument was the representation of my own element (which extends the code-ajax).
By digging though some Polymer code, I assume this is because, I called 'this.super()', from a method, which was a promise callback, and not exactly the extended method. Because of that Polymer was not able to get the name of the method to be called in the super class.
I was able to work around it, as presented here:
https://github.com/domderen/cachable-ajax/blob/master/cachable-ajax.html#L109
But the line:
that.__proto__.__proto__.go.call(that);
Seems to be a dirty hack, and I wonder if there is some more standard way of calling the super method of the extended class? Or if not, maybe Polymer should handle it somehow internally?

Closing this issue due to age and the release of version 1 of Polymer - please feel free to re-open if this is incorrect.


should.be_ok and should.be_error also unwrap the result

Right now, if we want to test whether a result is Ok and also check the value, this is what we have to do:
pub fn mock_test() {
  process()
  |> should.equal(Ok(correct_result))
}

which is fine, but imagine the following scenario:
pub fn mock_test() {
  process()
  |> should.equal(Ok(2 * base_value * { 1 - ratio }))
}

With this change, I think we could make it a bit cleaner:
pub fn mock_test() {
  process()
  |> should.be_ok
  |> should.equal(2 * base_value * { 1 - ratio })
}

The same with should.be_error.
There is also the fact that in my experience, people are just not using should.be_ok and should.be_error because they usually need to also check the inner value.

Mind updating the changelog? Thank you

I updated the changelog, but I wasn't sure about the version, so let me know if you think it should be changed.


Do not preload all transforms into a tf_buffer in assets_writer_main.

I recently found that tf_buffer was so slow to be the bottleneck in the offline_node - especially for longer bags. We worked around this issues in #342 for the offline_node, but the same logic is also used in the assets_writer_main and should be changed there as well.

FYI, I'm working on tf side to improve tf_buffer performance.
https://github.com/ros/geometry2/pull/267
In my case, that change makes assets_writer >20 times faster for 200k messages of /tf topic.


feat: upload failed golden tests as artifacts

As an engineer, it could be useful to see the failed golden tests after a failed run. Uploading the failures as artifacts would tackle that.

This needs further research to understand the best implementation

May be related https://github.com/VeryGoodOpenSource/very_good_coverage/issues/178


Fix memory leak of PyBytes -> Vec conversion

Resolves #570.
For now, I only added a test.

Could I include PyPy in allow_failures section in travis?
This segfault is exactly the same as #589 and not related to this PR.

I'd prefer skipping only the failing check with some cfg.

@konstin
OK, I added pytest.skipif decorator for the test.


[v6]  crashes if "to" prop is undefined

Version
6.0.0-beta.0
Test Case
https://codesandbox.io/s/loving-hugle-4321b?file=/src/App.js
Steps to reproduce
Run the sandbox above, or try <Link to={undefined}>Text</Link>
Expected Behavior
Ideally, provide a warning and render anyway; or just ignore the problem and render, as per the v5 behaviour.
Actual Behavior
It crashes with the unhelpful error c is undefined.

I'm curious what the maintainers think about this issue.  I haven't experienced it myself, and it may be intentional so we don't accidentally create anchor tags with no href attribute.  If the maintainers want to change this behavior to render even without the to prop (maybe make it default to "#") I'd be happy to work up a PR

this is not a bug, because actually, the Link needs to know where should it go. Therefore, as long as the to prop is required, it can't be undefined

@renatobenks then it would be better with a more descriptive message instead of just crashing.

@timdorr Please reopen, as it is a bug. Although it does need a to prop work, the to prop may be dynamically assigned at runtime. If something goes wrong, I wouldn't expect it to just crash completely with an indecipherable error message.

If something goes wrong, I wouldn't expect it to just crash completely with an indecipherable error message.
What about then dealing with the possible undefined value on your side ? You are pushing the problem that starts in your application, to be dealt by the library. As stated by @renatobenks , if it says that it doesn't take in undefined, you shouldn't provide undefined. Now if the library maintainers have time to deal with that. good luck.

I think my point is that if to is undefined due to a developer's silliness, then crashing completely with c is undefined can be hard to debug in any non-trivial application, and it's not a great developer experience.
If it's the intention of the library authors that it should crash with an indecipherable error message, then that's fine. But I don't think it is - it smells like a bug - and I think the issue should be reopened.

I suggested to close it because once you have static types covering it, you actually don't need a double-check, but maybe, I guessed wrong, what do you think @timdorr?


Better representing the Rust web ecosystem

This has been the widespread feedback when arewewebyet.org has recently landed on /r/rust a couple of times.
The changes made a couple of months ago are extremely misleading, with a few objectively false claims (probably the most significant is that there are multiple mature and production-ready frameworks—actix-web is the closest to mature and production-ready, and it’s an HTTP server library, not a web framework; none of the rest are mature or production-ready). It needs to be rewritten to be far more tentative. The previous text was possibly a little too tentative and modest, but the current text is very seriously overstating the overall ecosystem’s state as any outsider will perceive it. If you’re used to the Ruby, Python or Node.js web ecosystems, you will be sorely disappointed when you come to Rust about how web it is, even if what there is is fast.
Relevant reading with feedback from a number of people:

https://old.reddit.com/r/rust/comments/j76xgg/woohoo_milestones_being_made_updated_2_days_ago/
https://old.reddit.com/r/rust/comments/jkv7ah/is_rust_web_yet_yes_and_its_freaking_fast/
https://blog.0xfa.be/building-a-backend-app-in-rust/ and https://old.reddit.com/r/rust/comments/khhi47/problems_with_building_a_backend_app_in_rust_in/

I asked a couple people for feedback, but no one responded. Maybe you could make some suggestions?

probably the most significant is that there are multiple mature and production-ready frameworks—actix-web is the closest to mature and production-ready, and it’s an HTTP server library, not a web framework;

actix-web is a web framework, not a server library; actix-http is the server library. What makes you think that it is not a framework?

one of the rest are mature or production-ready

Rocket is production ready.
I understand that some might perceive the current homepage as an overstatement. The text was reviewed by a couple people, and merged into the site. Do you have specific suggestions regarding how to provide a better overview of the ecosystem, or know anyone else who might be able to help out?

@chris-morgan I created #309 to address this for now. However, of course, I or anyone else is not qualified to speak on behalf of the entire ecosystem. This is a pretty important issues, so I think we should get some thoughts from others involved in the rust web ecosystem.
ping @SergioBenitez @robjtede @seanmonstar @yoshuawuyts

actix-web is the closest to mature and production-ready, and it’s an HTTP server library, not a web framework

We consider it a web framework and not a library for good reason. actix-http is the library part in the same way hyper is the library part of the rocket framework.
I think people coming from Node.js (which was my background before Rust) would not be expecting some dominant "application framework" since the big players there (Express, Koa, etc) are on the same level as Actix Web or Warp. My experience with Sails.js (as the name suggests, an attempt at a Ruby-on-Rails-like experience) was dissapointing and I found myself reverting to Koa and the package ecosystem for DB connectors and templating.
In my opinion, creating a framework similar to Rails or Django, with a built in HTML templating, ORM, DB migration system, task scheduler, front-end build tools, admin panels and other such stuff is out of scope for the current "web frameworks" in Rust-land. Folks coming from that ecosystem should learn to embrace using and combining crates. I don't think we're anywhere close to a useable "application framework" such as Rails (which is how I would classify it). The better comparison would be Sinatra (Ruby) or Flask (Python).
It remains to be seen wether there will be an Rails equivalent in Rust that can keep pace with teams focussed on the individual parts of what will become solutions for real tasks.
Maybe then, there should be some clarity on the scope of what the library and frameworks are trying to achieve, what is in scope for parts of the current ecosystem, and less of an empasis on the overarching "yes" answer presented at the top with more focus on the maturity of components that create developer's apps.

I think most of the concern was caused by the reference to Rails and Django which I removed. @robjtede 's point can probably be incorporated into the paragraph "While development might not be as smooth as something like Rails or Django...". The headline should also be changed, because assessing an ecosystem based on speed doesn't really make much sense, especially since no benchmarks were referenced.

This issue is old and seems to have been adressed at the time by d64108ca3cd75b0fe0e924079cb4565334ce538f so I believe we can safely close it


bundle: Update CSV capability to Seamless Upgrades

This PR updates the bundle's CSV capabilities from Basic Install to Seamless Upgrades.

/cherry-pick release-4.17

/lgtm
/approve


build boost libs do not have absolute path's set on Linux

Description
The mpi and serialization library part of stan-math are not build with hard-coded dll path's which make them potentially unsafe to use.
Example
Build stan-math on Linux with MPI. Then execute ldd on the libboost_mpi.so file. It will show that the references to the libboost_serialization.so are not found (unless the user includes the lib/boost*/stage/lib directory in LD_LIBRARY_PATH).
Expected Output
Calling ldd on that file should confirm that all dll path's are correctly resolved.
Additional Information
Any additional information goes here.
Current Math Version
v2.18.0

Closed via #1003


Useful

This is a useful page. I tried to figure out how to get an easily readable view of longer strings in debug mode and never even noticed the little icon that brings up the String Visualizer.
The UI design seems rather odd how it offers so much likely-uninteresting information about an object, but then makes the most easily useful control something you need to notice and interpret (or know about somehow) a very small icon that doesn't clearly communicate anything.

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

ID: b3761f60-ec2f-2c51-cfa1-1e192c71bebe
Version Independent ID: 714a4254-b006-5509-9fa1-355da2184942
Content: String Visualizer dialog box - Visual Studio
Content Source: docs/debugger/string-visualizer-dialog-box.md
Product: visual-studio-windows
Technology: vs-ide-debug
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@P-v-K Thanks for the positive comments about the article! If you are looking for functionality that isn’t currently provided by the product, please use our new “Suggest a feature” option in the Visual Studio Developer Community. We’d be happy to have this on record, where others can view it and upvote it, too. For more information about this new functionality in the dev community, see our Suggest a feature page.


Contentful should have just one L in the name

The current list spells Contentful as "Contentfull"!

@cassidoo thanks for noticing this typo! Already fixed by PR #76, so closing this issue.


Add test-execution optimization and sharding options

This PR addresses #199.
Optimizing Test Execution
--related-tests <files>
Finds and executes all related tests for the provided .nf or nf.test files. Multiple files can be provided space separated.
--follow-dependencies
When this flag is set, nf-test will traverse all dependencies when the related-tests flag is set.
This option is particularly useful when you need to ensure that
all dependent tests are executed, bypassing the firewall calculation process.
--only-changed
When enabled, this parameter instructs nf-test to execute tests only for files that have been modified within the
current git working tree.
--changed-since <commit_hash|branch_name>
This parameter triggers the execution of tests related to changes made since the specifie commit.
e.g. --changed-since HEAD^ for all changes between the HEAD and HEAD - 1.
--changed-until <commit_hash|branch_name>
This parameter initiates the execution of tests related to changes made until the specified commit hash.
--graph <filename>
Enables the export of the dependency graph as a dot file.
The dot file format is commonly used for representing graphs in graphviz and other related software.
Sharding
This parameter allows users to divide the execution workload into manageable chunks, which can be useful for
parallel or distributed processing.
--shard <shard>
Splits the execution into arbitrary chunks defined by the format i/n, where i denotes the index of the current
chunk and n represents the total number of chunks. For instance, 2/5 executes the second chunk out of five.
--shard-strategy <strategy>
Description: Specifies the strategy used to build shards when the --shard parameter is utilized.
Accepted values are round-robin or none.. This parameter determines the method employed to distribute workload
chunks among available resources. With the round-robin strategy, shards are distributed evenly among resources in
a cyclic manner. The none strategy implies that shards won't be distributed automatically, and it's up to the
user to manage the assignment of shards. Default value is round-robin.

Wow! some pretty great features coming with this PR I see 🚀
@lukfor FYI - Adam Talbot & Carson Miller were trying to implement some of the functionality here with a GHA

Thanks for the info!
We are in the final stage of preparing the new release, along with the preprint.


Adding rotations to the collision transform table argument

Library allow us to rotate a model, but when we do so, we can't set the rotation to the collision set of vertices.
could we add rotations to the collision transform table like so: collisions.sphereIntersection(verts, {scale={}, translation={}, rotation={}) ?

Unfortunately multiplying each point in a model with a rotation matrix whenever the model rotates can be extremely computationally expensive, and would result in the game's framerate dropping.
Rotating colliders are not necessary for 3D games even as complex as Super Mario 64, so I don't think they're necessary. You can still manually approximate rotating colliders yourself if you want to, but I don't plan on adding them into g3d.

I consider g3d to be roughly "done", I don't plan on adding new features.
I know this isn't the answer you want to hear, but I designed g3d with extensibility in mind. That's part of the reason why it doesn't have a ton of features or a strong opinion about how you structure your game. Implementing that feature yourself would not be very difficult. The basic idea is that you would want to keep a second list of vertices for each model that you use in collisions, and you multiply each vertex by the transformation matrix whenever you call your proposed model:updateState() function.
Good luck!


Check if camera is connected

Hello there. Great job! many thanks for your code.
I have a question for you. How can I check that the user has his camera connected? or even that a camera exists?

Hi, there's a default callback for errors, which you can override by
Webcam.on( 'error', function(err) {
    // an error occurred (see 'err')
});

See #140


OCPBUGS-19841: Add format key into the worker-user-data secret

There is a consensus in the upstream community, that every provider, that supports ignition as its bootstrapping method should adopt field format with value ignition (encoded as base64 string) to indicate that the user intends to use this feature. If this value would be empty, the upstream providers operator would assume that the user wants to use the other option called cloud-init that we don't intend to support in the future.

/jira refresh

/assign @damdo

@odvarkadaniel what kind of testing did you perform to check this works as expected? In other words, does it play correctly with the component that was requesting this change?
Also could you add a description along the lines of the bug to explain the change here?
Thanks!

@odvarkadaniel what kind of testing did you perform to check this works as expected? In other words, does it play correctly with the component that was requesting this change?
Also could you add a description along the lines of the bug to explain the change here? Thanks!

I only tested this with vSphere at the moment and works as expected. I don't see any potential issues with this change for other providers. Maybe @miyadav could pre-merge test the change to verify this.
A usage of this field can be seen in CAPA:

https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/pkg/cloud/scope/machine.go#L203-L205
https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/controllers/awsmachine_controller.go#L843

Got it thanks.
I'm happy with the testing you did with VSphere and checking that it works.
Also considering that for the other providers we have green E2E tests.
/lgtm
/retest

/retest-required

/retest

/retest

/retest

/retest

/retest
VSphere not passing should not be a concern here. From the logs, we can tell that the issue is not brought in with these changes. Should be valid for an override of the test.

/retest

/retest
VSphere not passing should not be a concern here. From the logs, we can tell that the issue is not brought in with these changes. Should be valid for an override of the test.

VSphere CI is currently broken.

/retest


How to Contribute to an Open Source Project on GitHub

https://github.com/nesterone/sf-eng-init-gl-spring-2016/blob/master/00-bootcamp/06-our-model-of-collaboration/our-model-of-collaboration.md#workshop-contribute-to-open-source

Pull request


workaround for bug/behaviour in otlp-metrics-exporter

Checking if reading from an env returns the value undefined and assigning the string the value undefined, so the otlp-metrics doesn't crash until fix in the package is applied.
Worked locally for both services (no load/requests, but was reproducible on simple docker run).
Didn't bump versions, because workaround - opinions?

is this workaround confirmed to work?

just saw the comment about it being an otel bug when the token is undefined. yes, go ahead and pump the last place of every version please

after this is merged, no re-install is necessary, just a manual "sudo philbot_restart" will do the trick.


Merge pull request #1 from superscriptjs/master

Bringing fork up to date

Coverage remained the same at 80.495% when pulling 4ef1dfd712925877e5205b02c53b466fbeabd67d on rensdewolf:master into d7cf87a4b3dc044526861844c3684ddf50e24184 on superscriptjs:master.


raidboss and jobs aren't working

[12/12/2019 6:02:48 PM] Error: JS Handler call failed: System.Exception: Tried to call missing handler "cactbotLoadUser"!
at RainbowMage.OverlayPlugin.EventDispatcher.CallHandler(JObject e)
at RainbowMage.OverlayPlugin.OverlayApi.<>c__DisplayClass16_0.b__0()
is the error I'm getting

Hope you got this fixed!


Is reflective access completely gone?

Does the latest version of metrics-core rely on reflective access?
We have a logging/metrics framework that wraps an old version of metrics-core that requires adding opens to get it to work with Java 9 or higher.
Because the JVM args that define opens aren't backward-compatible with Java 8, we have trouble upgrading existing services (our deployment configuration system didn't anticipate an exception to write-once/run-anywhere).
We can upgrade our logging/metrics framework to a newer metrics-core, but if the latest version still relies on reflective access, that won't help. So we'd like to know ahead of time if it's going to be a waste of time.

metrics on release/4.2.x is 📦 4.2.3-SNAPSHOT
# git checkout v4.1.24
HEAD is now at 25c08486 [maven-release-plugin] prepare release v4.1.24

metrics on HEAD (25c0848) is 📦 4.1.24
# git grep java.lang.reflect
metrics-jcache/src/main/java/com/codahale/metrics/jcache/JCacheGaugeSet.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/NameStrategies.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/ShortNameStrategy.java:import java.lang.reflect.Method;
metrics-jdbi3/src/main/java/com/codahale/metrics/jdbi3/strategies/TimedAnnotationNameStrategy.java:import java.lang.reflect.Method;
metrics-jersey2/src/main/java/com/codahale/metrics/jersey2/InstrumentedResourceMethodApplicationListener.java:import java.lang.reflect.Method;

metrics on HEAD (25c0848) is 📦 4.1.24
# git checkout v4.2.1
Previous HEAD position was 25c08486 [maven-release-plugin] prepare release v4.1.24
HEAD is now at 5e79bdaa [maven-release-plugin] prepare release v4.2.1

metrics on HEAD (5e79bda) is 📦 4.2.1
# git grep java.lang.reflect
metrics-jcache/src/main/java/com/codahale/metrics/jcache/JCacheGaugeSet.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/NameStrategies.java:import java.lang.reflect.Method;
metrics-jdbi/src/main/java/com/codahale/metrics/jdbi/strategies/ShortNameStrategy.java:import java.lang.reflect.Method;
metrics-jdbi3/src/main/java/com/codahale/metrics/jdbi3/strategies/TimedAnnotationNameStrategy.java:import java.lang.reflect.Method;
metrics-jersey2/src/main/java/com/codahale/metrics/jersey2/InstrumentedResourceMethodApplicationListener.java:import java.lang.reflect.Method;
metrics-jersey3/src/main/java/com/codahale/metrics/jersey3/InstrumentedResourceMethodApplicationListener.java:import java.lang.reflect.Method;

I should have been more specific: is forbidden reflective access still required?
In other words, is it still the case that using dropwizard with Java 9 or higher requires doing this?:
--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED

If the question is whether Dropwizard Metrics supports the Java Platform Module System (JPMS), then the answer is only with automatic modules (Automatic-Module-Name) but we don't define a full module descriptor (module-info.java).


V2 Documentation Fix Up

Description of Changes

Updated development documentation
Added documentation links in main operator readme for missing operators
Updated operator documentation to redirect to otel docs for applicable operators
Updated HTTP operator doc to show change in TLS configuration

Please check that the PR fulfills these requirements

[X] Tests for the changes have been added (for bug fixes / features)
[X] Docs have been added / updated (for bug fixes / features)
- [ ] Add a changelog entry (for non-trivial bug fixes / features) (Part of larger v2 release)
[ ] CI passes

Log Files
Logs / Second
CPU Avg (%)
CPU Avg Δ (%)
Memory Avg (MB)
Memory Avg Δ (MB)

1
1000
1.500016
-0.017290235
129.42969
-0.5048523

1
5000
5.103484
-0.44827652
138.40773
+1.7006989

1
10000
9.724333
-0.6896534
150.33742
+1.7311401

1
50000
51.103428
-3.8455048
183.27586
-1.1029053

1
100000
93.20876
-7.7881317
231.98895
-5.077057

10
100
2.0172203
-0.08623934
132.52505
+0.80981445

10
500
6.0862794
-0.017252922
140.85574
-3.6578674

10
1000
12.224385
-0.15486526
151.6642
+3.6535645

10
5000
57.064438
-1.6090355
183.37782
-0.2861023

10
10000
107.41723
-20.409256
307.53784
+56.769928


Remove entity_gym dependency on enn_zoo and lazily initialize griddly

This removes the dependency of entity_gym on griddly, and initializes griddly environments lazily in enn_ppo/train.py to avoid unnecessary loading of files and log output.

Fixes https://github.com/entity-neural-network/incubator/issues/85


pylint disable in pos_multi_session

disable missing-manifest-dependency in pos_multi_session :unicorn:

I approve to merge it now


Remove the Customer IP from the info log message in the request logs

This is a small change that removes the IPs in the log messages that are printed in the info log level in the request logs. We really want to keep the logs for as long as possible since we need them for debugging. However we can not do that because there is a policy in place that stops us from keeping specific customer information for longer than 3 days. Because the IPs in the log messages are customer specific we can not keep our logs longer than 3 days which really hurts debugging for now.

A short explanation of the proposed change:

Remove the customer IPs from the log level info messages.

An explanation of the use cases your change solves:

We can not have the IP of customers in the log messages as it violates our corporate rules

Links to any other associated PRs

[x] I have reviewed the contributing guide

[x] I have viewed, signed, and submitted the Contributor License Agreement

[x] I have made this pull request to the master branch

[x] I have run all the unit tests using bundle exec rake
I run bundle exec rspec spec/middleware/request_logs_spec.rb specifically

[x] I have run CF Acceptance Tests

there is a policy in place that stops us from keeping specific customer information for longer than 3 days

It is regulated by the GDPR. We want to have the Debug Information (logs) for at least 2 weeks which is not allowed here if they contain customer specific IP-Address data.

awesome, thank you for the info @MMisoch and the PR. We'll probably work to merge @FloThinksPi 's PR over this one, so I'm going to close this out. If you have improvements over the other PR feel free to reopen!
closing in favor of
https://github.com/cloudfoundry/cloud_controller_ng/pull/1585

Sure, that was the plan from our side after having some more discussion on the topic.


Modeled Unified Latex Female Snow Leopard.

Fixes #
Proposed Changes

it might be a bug, I don't remember ever commiting those files again


Add github workflows

This adds github workflows. It doesn't delete the travis.yml. It can be amended to do so. Submitted for author feedback.

Sorry for the late reply to this. I will merge right now to see how well github works compared to Travis and compare both for a while.


Mismatched tags

The tags for some versions, e.g. 0.8.2: https://github.com/bazel-contrib/toolchains_llvm/archive/refs/tags/0.8.2.tar.gz do not point to proper source. For the link above the Readme.md contains:
BAZEL_TOOLCHAIN_TAG = "0.8.1"
BAZEL_TOOLCHAIN_SHA = "751bbe30bcaa462aef792b18bbd16c401af42fc937c42ad0ae463f099dc04ea2"
Both the version, and the sha are incorrect. Similar for version 0.9.

Unfortunately, GitHub does not maintain guarantees for the shasum being constant for source archives because they are dynamically generated. The old source archives, with the exact same contents, are gone now, and it will be non-trivial to recreate and house them. The new source archives, will have a different strip prefix (which is also the reason why their shasum is changing), but will be otherwise the same. If you don't need your older commits to work as-is, you can update the shasum and strip_prefix going forward. I can commit the new values as a file in this repo for easy reference.
This project did start generating release artifacts which are static (and hence guaranteed to be the same) from release 0.10.1 onwards.
Best practice for any project that needs to be able to run past revisions of source code as-is, is to mirror/proxy all network resources themselves or through another service.

Sorry for the inconvenience. Hopefully, you will be able to move forward.

@siddharthab Do you happen to also have the before/after checksums for the 0.5.1 release (old, I know)

I do not, but there is also nothing special I do here. Since these are dynamically generated archives, I have to fetch it from GitHub again, and my connection is not that special.
curl -L https://github.com/bazel-contrib/toolchains_llvm/archive/refs/tags/0.5.1.tar.gz | shasum -a 256

@siddharthab OK, thanks for the quick reply! :bow:


Added empty line beetween

Added configuration file for empty line between groups

Hey Andrew!
This is an awesome idea! The only thing is that by default the “border” property should be in the “visual” group. Therefore, before this change will be merged, needs to think about whether there is a way to implement the possibility of combining options and thus get a config which wanted the user (for example: with the “border” property into the "box model" or "visual" group and with or without an empty line between groups).
Of course, we can create a file for each case, but in this way, the implementation will looks ugly and not scalable (and yes, in the context of a simple definition of fields order, it may sound pretty funny =).

Immediately apologize for my English. How about this solution?

@constverum any chance of merging this? I'd love to have it in my project, actually.

It would be good to have border in a separate group. It would just end this war.

Sorry for the delay!
Andrew, you did a really awesome job, thank you! =)
This revision will be included in the next release with minor changes:
borderInBoxModel=> border-in-box-model
emptyLineBeetweenGroup => empty-line-between-groups


feat(config): create new package to facilitate loading application parameters from multiple sources

Features:
Split up the @apoyo/process package into 2 framework agnostic packages: @apoyo/logger and @apoyo/config.  The logger and configuration code will be removed from @apoyo/process package after these 2 packages have been released.
This PR contains the @apoyo/config package, which contains utils to load application parameters from multiple sources:

Environment
AWS SSM

Questions:

Should we rather name @apoyo/config-ssm as @apoyo/config-aws-ssm, to avoid confusion with secret managers from other providers?

Should we also implement AWS Secret Managers? (Currently only Parameters Store is supported). If yes, under which package name? @apoyo/config-aws-secrets?

Note that secret managers from other providers like Google and Azure may also be added in the future. As such, the package names should be clear.


Publish Tanzu CLI as an ASDF plugin

Feature Request

Currently Tanzu CLI is built for each specific distro: TCE, TKG etc. this causes issues for running and managing TKG and TCE from the same machine.
Also having 2 versions of TCE or TKG installed on the same machine is also problematic as the CLI version is coupled with the release version.
ASDF is a great mechanism to allow for installing multiple versions of a CLI and making them interchangeable in a very simple way.
Releasing an ASDF plugin for Tanzu CLI could be a very elegant solution to solve these issues mentioned above.
Describe alternatives you've considered
Having separate machines for managing each platform/version.

Additional context

Since I had to Google it - here's a link explaining what ASDF is: https://asdf-vm.com/

also just for reference, the Carvel team have experience with ASDF as they release all of the carvel tools via ASDF as well.
for carvel tools its also very useful as asdf allows you to set a different version of the CLI on a per folder basis with a single command.
its similar to nvm for those in the node world but is generic and works alot better :)


Evaluating inline scripts within  jsdom container

🐛 Bug Report
Testing vanilla HTML / JS using build-in jsdom - cannot get the inline scripts being executed.
Loading an HTML content with a <script> tags and expecting the scripts to be evaluated by jsdom, but nothing happens.
To Reproduce
  test('evaluates inline script', async () => {
    const html = `
      <script>
        console.debug('evaluated');
        function run() {
          console.debug('run');
          const el = document.createElement('div')
          el.setAttribute('data-testid', 'custom');
          document.body.appendChild(el);
        }

        window.addEventListener('load', run);
      </script>
    `;

    document.body.innerHTML = html;

    window.dispatchEvent(new Event('load'));
    await new Promise((resolve) => setTimeout(resolve, 500));

    const $el = document.querySelector('[data-testid="custom"]');
    expect($el).toBeTruthy();
  });

Expected behavior
The test 👆🏻 should pass - inline JS code should be evaluated and DOM modified.
Link to repl or repo (highly encouraged)
https://repl.it/repls/ClassicDarkvioletCurrency#inline-js.test.js
envinfo
  System:
    OS: macOS 10.15.6
    CPU: (8) x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
  Binaries:
    Node: 13.8.0 - /usr/local/bin/node
    Yarn: 1.22.0 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm

We do pass runScripts: dangerously - I'd have thought that was enough?
https://github.com/jestjs/jest/blob/892f9a6714a9749e22e63098bb1aef9f7a91c46d/packages/jest-environment-jsdom-abstract/src/index.ts#L72C9-L72C19


A way to use handle instead of email

If you want to identify a user using the handle (like some sort of anonymous user) you can't do it at the moment.
I can create the option as a configuration value for the default used parameter, email/handle and send a pull request.
Let me know what you think.
Cheers for this Gem btw! I was just about to create one myself.

Closed with #2

Cheers!


divisible sum

it gives pair of (i,j)divisible by k
Pull Request Template
What have you Changed(must)
Write here what you have changed in the codebase
Issue no.(must) -
Pr will be close and marked as spam. If issue number not found or issue was assigned to someone else.
Marking as spam can block your account from HacktoberFest.
Self Check(Tick After Making pull Request)

[ ] This issue was assigned to me if not it will be marked as spam.
[ ] My file is in the proper folder
[ ] I am following clean code and Documentation.
[ ] I have added the title and what program will do first in the file
[ ] I have named the file as (Problem #). (Problem Title(in Camel Case)).(extension)
ex. 2. AddToNumbers.py

README - How to Contribute

@Arpitpatel2618 you have to mention the issue number in the PR Body.


Can't build SR-IOV Network Operator images

CentOS 8 is EOL now [1]. It means we can't build docker images now because of this error:
CentOS Linux 8 - AppStream 110 B/s | 38 B 00:00
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

We need to update base images to fix our images build
[1] https://forums.centos.org/viewtopic.php?f=54&t=78708

I tested with registry.access.redhat.com/ubi8/ubi:8.5-226 image:
Last metadata expiration check: 0:00:03 ago on Wed Feb  2 16:38:32 2022.
No match for argument: mstflint
Error: Unable to find a match: mstflint
The command '/bin/sh -c yum -y update && ARCH_DEP_PKGS=$(if [ "$(uname -m)" != "s390x" ]; then echo -n ${MSTFLINT} ; fi) && yum -y install hwdata $ARCH_DEP_PKGS && yum clean all' returned a non-zero code: 1

@zshi-redhat  @pliurh do you have any suggestions what base image we should use? I tested with quay.io/centos/centos:stream9 and it works for me. Maybe it's better to use centos8 for now with updated repos?


[NetworkManager/WIP] Use Addressables for scene loads

This should probably be a checkbox instead of forcing it on for everyone :)

Keep this as draft - I'll use it for reference in a proper feature add.

Provided example that should work...awaiting feedback.

I think you guys mentioned in discord that this is not needed/necessary/working for some Unity reason.
closing for now, feel free to reopen.


KAFKA-10535: Split ProcessorContext into Processor/StateStore/Record Contexts

Migrate different components of the old ProcessorContext interface
into separate interfaces that are more appropriate for their usages.
See KIP-478 for the details.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

One unrelated failure:
Build / JDK 11 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true] failed

I'll go ahead and merge, since Guozhang was in favor.


login,logout and signup view and functions

commit: 2bd720243bae047ceb32943ac6f7bb898425862d

login,logout and signup view and functions are added.


Create dependabot.yml

dependabot can be quite annoying when there are a lot of versions being released
suggest changing to monthly for now

Hmm, for npm this seams to be the default (documentation says: overall strategies)
https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#versioning-strategy


[11.x] Fix ratio validation for high ratio images

When uploading images with resolution of 1366x768 which has ratio 16/9 validation fails
so i go with solution to solve the issue provided with test case of the 16/9 ratio
its also increase the precise for other ratios

I have a bit of trouble to understand this change, and to determine if it is really correct.
To summarize, you have replaced:
max($width, $height)
with:
max(($width + $height) / 2, $height)
(and the larger the result is, the lowest the precision (i.e. tolerance) is, and it turn the "stricter" the aspect ratio validation is)
The points I have trouble with:

You are discarding $width. That seems to introduce a bias. Previously, $width and $height had the same "importance". My point is that 16/9 (1366x768 image) and 9/16 (768x1366 image) should validate exactly the same. Your code changed handling of the former, but changed nothing with the latter.
Considering a 1366x768 image, ($width + $height) / 2 gives 1067. So this value 1067 is the new max, whereas previously it was 1366. I have just a bit of trouble to understand the rational behind this calculated value.

Provided that the value of ($width + $height) / 2 is correct to consider, I think the proper fix would not be max(($width + $height) / 2, $height), but just ($width + $height) / 2.

I'm thinking of the following approach:
$desiredRatio = $numerator / $denominator;

$actualRatio = $width / $height;

$otherRatio1 = ($width + 1) / $height;
$otherRatio2 = ($width - 1) / $height;
$otherRatio3 = $width / ($height + 1);
$otherRatio4 = $width / ($height - 1); // TODO: avoid division by 0 if $height === 1

$success = abs($desiredRatio - $actualRatio) === min(
	abs($desiredRatio - $actualRatio),
	abs($desiredRatio - $otherRatio1),
	abs($desiredRatio - $otherRatio2),
	abs($desiredRatio - $otherRatio3),
	abs($desiredRatio - $otherRatio4),
);

We test if the ratio of the image is the closest possible to the desired ratio. We try with width or height changed by 1, and if we were the closest possible, these other 4 cases will have ratios that are further to the desired ratio.
This approach seems to be correct, but I hope there is some way to simplify the code.

The above snippet fails with a 1366x768 image, because 1365x768 would be actually closer to the desired 16/9 ratio.
So, I tried another approach: providing the actual width, or the height, calculate the other dimension using the desired ratio, and test if the result matches the actual other dimension. For instance:
Desiring a 16/9 ratio:

an image with a 1366 px width should have a 768.375 px height (calculated by $width * denominator / $numerator), which is then rounded to 768 px.
an image with a 768 px height should have a 1365.333 px width (calculated by $height * numerator / $denominator), which is then rounded to 1365 px.

Though, note how our 1366x768 image succeeds using the former calculation, but fails using the latter!
Also, as we calculating using floats, there is some "imprecision" due to the nature of floats. Executing the latter calculation, I got results such as float(1366) or even float(1366.01), whereas the proper result is 1365.333…
A solution could be, when the other dimension is between two integers (i.e. the image can't perfectly achieve the desired ratio), to accept both the lower and the upper integer. But this would allow for too much imprecision with small images, for instance, desiring the 16/9 with an image of 5 px width, we should really have a 3 px height, not 2 px.

(still thinking of loud, hope it doesn't bother you)
Considering the pitfalls I exposed in my above post, I figured out this approach:
$calculatedHeight = round($width * $denominator / $numerator);
$calculatedWidth = round($height * $numerator / $denominator);

if ($height === $calculatedHeight || $width === $calculatedWidth) {
    // Pass
}

If at least one of the two calculations matches, we're good. As shown previously, a correct image could have only one calculation that matches. Of course, it is possible that both calculations match. And contrarily, if no calculation matches, we are certain there exists a more appropriate width/height pair.
Nervertheless, I figured out another issue: if a calculated width/height has a ".5" decimal (e.g. 42.5), there is no particular reason to round it up, i.e. it should be equally acceptable to round it down. Sadly, supporting that case leads to a more complicated code:
$calculatedHeight = $width * $denominator / $numerator;
$calculatedWidth = $height * $numerator / $denominator;

if (
    $height === round($calculatedHeight, 0, PHP_ROUND_HALF_UP)
    || $height === round($calculatedHeight, 0, PHP_ROUND_HALF_DOWN)
    || $width === round($calculatedWidth, 0, PHP_ROUND_HALF_UP)
    || $width === round($calculatedWidth, 0, PHP_ROUND_HALF_DOWN)
) {
    // Pass
}

I see your concern but i tried to find an equation to solve almost of ratios, without breaking changes
I thinks of almost all these cases of small images and large images
Your solution may need more tests in some images there is over 4 pixel for difference
You can create pull request with your solution


Add an official URL for this repository

Is it possible to add https://loogle.lean-fro.org/ as an official URL for this repository, so that it would show in the "About" section:

Sure thing!


Example does not show how to actually access the message's content.

Document does not show how to read the content of the service bus message.  It shows getting messages and completing them, but that is not very useful.  Most users need to process the incoming message, so showing how to get the ContentData in the loop would be more helpful.

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

ID: de93e314-ae26-29c3-1594-377081ddb002
Version Independent ID: a65af49c-ba04-b76a-b510-a8646d5056e6
Content: Handle Service Bus events via Event Grid using Azure Logic Apps - Azure Service Bus
Content Source: articles/service-bus-messaging/service-bus-to-event-grid-integration-example.md
Service: service-bus-messaging
GitHub Login: @spelluru
Microsoft Alias: spelluru

Here's the syntax to get the content of the message: base64ToString(items('For_each_message_from_subscription')?['ContentData'])
Here's what I tried.

Added a ForEach loop
Added the "Send an email" action. Configured the body with an expression: base64ToString(items('For_each_message_from_subscription')?['ContentData']) where the name of my for each loop is "For each message from subscription".
Added another action in the ForEach loop to complete the message.

Here's how my logic app looks:

I will update the tutorial soon

Updated the article.
#please-close


Mock api implementation [Models]

Creating an issue for the missing implementations now that the CI enforce it
Update here when added the test https://github.com/Azure/cadl-ranch/blob/main/packages/cadl-ranch/src/actions/validate-mock-apis.ts#L90
Docs for writing mock apis
Use npm run validate-mock-apis to check everything is good or the errors(Remove the exluded line first)

[ ] models/collections-basic         @msyyc
[ ] models/collections-models     @msyyc
[ ] models/enum-properties        @msyyc
[ ] models/inheritance                  @weidongxu-microsoft
[ ] models/input-basic                 @weidongxu-microsoft
[ ] models/readonly-properties   @weidongxu-microsoft
[ ] models/roundtrip-basic          @qiaozha
[ ] models/nested-models           @qiaozha
[ ] models/primitive-properties    @qiaozha
[ ] models/optional-properties    @pshao25
[ ] models/output-basic               @pshao25
[ ] clients/interfaces                      @pshao25

Discussed with the team and each SDK team will pick up a couple of the time for Mock API

We will want to also reconcile these test cases with the efforts to port autorest.testserver tests directly - we don't want to duplicate tests for given features/feature groups, so we can stay clear about which languages support which features.  If we have duplicate test cases, and different languages use different tests for the same feature, it will be hard to communicate about feature parity across languages going forward.  @lmazuel FYI.

Per @lmazuel, please merge "smart Salmon" into inheritance/main.cadl as follows:
Add:
model DerivedFromBaseClassWithDiscriminatorC extends DerivedFromBaseClassWithDiscriminatorB {
  discriminatorProperty: "C";
}


chore: Update to v3

Checklist:

[x] Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
[x] The title of the PR is (a) conventional, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
[x] My organization is added to USERS.md.
[x] I've signed the CLA.
[x] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
[x] My builds are green. Try syncing with master if they are not.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: alexec:x: peterbourgonYou have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: alexec:x: peterbourgonYou have signed the CLA already but the status is still pending? Let us recheck it.


support filter /policies by resource, resourceType, agent, agentType

Is your feature request related to a problem? Please describe.
support filter /policies by resource, resourceType, agent, agentType
Describe the solution you'd like
This endpoint should be extended to support optional parameters for filtering by resource, resourceType, agent, agentType
https://github.com/orchestracities/anubis/blob/master/anubis-management-api/src/policies/routers.py#L103
Describe alternatives you've considered
N/A
Additional context
N/A

fixed by #75


Create a user interface for the document search using Streamlit

Create a user interface which should include -

[ ] File upload
[ ] Verify if file is a .pdf
[ ]  Text input for questions

@sahil-sagwekar2652  I am still learning about Streamlit, but can I work on a portion of this issue?

@sahil-sagwekar2652  Sir can you Assign me this Issue I have made  UI for my team in SIH for ML project using Streamlit. So I have good experience in it

@aindree-2005 You can start working on this issue, I am assigning it to you.

@aindree-2005 I would like to be unassigned from this issue as I don't think I'm suitable for this task. I don't think I'll be able to focus on learning Streamlit well enough to finish it on time. Sorry for the inconvenience

Good call @aindree-2005 . Your accountability is appreciated. People just leave the issue unattended but you chose to reach out.

Yes sir,
I have written the code for the UI but I am unable integrate with existing project


chore: expose TransactionFetcher param in cli

Exposes TransactionFetcher params in cli: DEFAULT_MAX_CAPACITY_CACHE_PENDING_FETCH
https://github.com/paradigmxyz/reth/issues/10326

@emhane Not being able to comprehend the book ci


Sporadic failures: ValueError: bad marshal data (unknown type code)

Details

Project URL:  https://hgvs.readthedocs.io / https://github.com/biocommons/hgvs
Build URL (if applicable): https://readthedocs.org/projects/hgvs/builds/5238348/
Read the Docs username (if applicable): reece

Expected Result
Built documentation at https://hgvs.readthedocs.io .
Actual Result
I recently started getting ValueError: bad marshal data (unknown type code) in my builds. See https://readthedocs.org/projects/hgvs/builds/5238348/. The errors are repeatable.
Local doc builds succeed. I've got a couple of years of docs at RTD, so I'm surprised by the new error.
I don't know how to get started debugging a build problem that I can't reproduce locally.

It appears that these errors are sporadic. For example, here are two builds on the same commit, one failed and one succeeded:

https://readthedocs.org/projects/hgvs/builds/5241407/ (failed)
https://readthedocs.org/projects/hgvs/builds/5241420/ (succeeded)

Hmm. This error appears to be a symptom of a corrupted .pyc.
http://stackoverflow.com/a/30861496/342839
I've tried wiping builds, but this doesn't help.

I also tried bringing up a new documentation project on the same repo (with the presumption that this wouldn't share files with the failing project). No change. So, my guess is that corrupt .pycs are not the issue.

I tracked this down to a build issue with python-slugify (https://github.com/un33k/python-slugify/issues/38).  I can reproduce the issue when generating a bdist_egg on the package, outside of RTD.
I'm closing this issue as the problem is pretty clearly with python-slugify 1.2.2 (release on 2017-04-01, so only recent builds would be affected).


[FLINK-9078][E2ETests] Add test that verifies correct avro behaviour

What is the purpose of the change
There was a specific kind of classloading issue where a flink job would fail with a ClassCastException when restarting after failure, which has now been fixed.
This end2end test adds automated testing to verify that this error does not occur anymore.
Brief change log

Add example module with avro based on quickstart example
Add test script
Add utility functions and improve output in common.sh

Verifying this change
This change added tests and can be verified as follows:
Run ./run-pre-commit-tests.sh
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@aljoscha @patricklucas Could you maybe have a look at this?

@twalthr How are we planning to proceed on this PR?


Implement MapView for other targets

Currently MapView only works for Android and IOS target. Implement the Maps for all the other targets.

Map View added for Web targets using https://github.com/Hamamas/Kotlin-Wasm-Html-Interop and leaflet.js
https://github.com/ShreyashKore/wonderous_compose/pull/7

Implemented
https://github.com/ShreyashKore/wonderous_compose/pull/10


Migrate eixo::docker to Docker Api v 1.24

new branch for the migration

Several tests fail with error:
Error cleaning: $VAR1 = 'hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at /usr/local/share/perl/5.22.1/Eixo/Rest/Client.pm line 232.


A typo in jfm.pdf

The last line of table 1 on page 4: patam -> param ?

Yes, you are right. I will fix it in the next release, thanks.

Closed via 5049e87.


Suse tests failed on Jenkins jobs

Tests have been limited to x86-64, jobs in github action ci passed. Consistently failed in jenkins jobs
> Task :jdk:suse:checkJdkSuse
Picked up _JAVA_OPTIONS: -Xmx4g

ZypperOperationsTest > opensuse/leap:15.1 FAILED
    org.opentest4j.AssertionFailedError at ZypperOperationsTest.java:58

ZypperOperationsTest > opensuse/leap:15.2 FAILED
    org.opentest4j.AssertionFailedError at ZypperOperationsTest.java:58

2 tests completed, 2 failed

> Task :jdk:suse:checkJdkSuse FAILED

https://ci.adoptopenjdk.net/view/work-in-progress/job/Sophia-adoptium-packages-linux-pipeline/1/console

Will be useful to update that code to print out the non-zero error code, https://github.com/adoptium/installer/blob/master/linuxNew/jdk/suse/src/packageTest/java/packaging/ZypperOperationsTest.java#L58

So these tests are failing because Zypper cannot locate the public signing key to verify the GPG signature. I did a quick bit of investigation bit it seems that there is no easy way to skip the verification. As a short term measure, we could import our public key but that wouldn't resolve things for other vendors using our scripts (if any)

Failure seems to be this:
Looking for gpg key ID 65F8F04B in cache /var/cache/zypp/pubkeys.

Repository Plain RPM files cache does not define additional 'gpgkey=' URLs.

Abort, retry, ignore? [a/r/i] (a): a

and
Problem occurred during or after installation or removal of packages:
Installation has been aborted as directed.
Please see the above error message for a hint.
temurin-17-jdk-<IP_ADDRESS>.0.12-1.x86_64 (Plain RPM files cache): Signature verification failed [4-Signatures public key is not available]

So these tests are failing because Zypper cannot locate the public signing key to verify the GPG signature. I did a quick bit of investigation bit it seems that there is no easy way to skip the verification.

How about?
zypper --no-gpg-checks <cmd>

Looks like I was trying that flag in the wrong location (after the install). That seems to work nicely, I'll raise a PR


use eval_string("print"), got crash

I'm quite new to duktape. I just use the sample code:
duk_context *ctx = duk_create_heap_default();
if (ctx) {
if (duk_peval_string(ctx, "print('Hello world!');") != 0) {
printf("eval failed: %s\n", duk_safe_to_string(ctx, -1));
} else {
printf("result is: %s\n", duk_get_string(ctx, -1));
}
duk_pop(ctx);
}
got message:
eval failed: ReferenceError: identifier 'print' undefined
javascript has print function already, right? Or, eval_string must accept an native function?

if I define a native func:
duk_ret_t nativePrint(duk_context* ctx)
{
duk_push_string(ctx, " ");
duk_insert(ctx, 0);
duk_join(ctx, duk_get_top(ctx) - 1);
printf("nativePrint: %s\n", duk_safe_to_string(ctx, -1));
return 0;
}
and register that func:
duk_push_c_function(ctx, nativePrint, DUK_VARARGS);
duk_put_global_string(ctx, "print");
duk_eval_string(ctx, "print('Hello world!!!');");
This time everything works fine. So i just wanna know that, if eval support origin javascript func print, this native print works like hook?
Any help is appreciate, thanks~~

print() and console.log() are not defined by default in the Duktape runtime. You can implement print() yourself or use the bundled extra: https://github.com/svaarala/duktape/tree/master/extras/print-alert

ok, got it. And i guess some sample code in doc should refresh. Thanks a lot.


Migrate inventory collection from REXML to Nokogiri

Alright, let's try again, with some of those commits squished down a bit...
As per the discussion at https://github.com/ManageIQ/manageiq/issues/241
This switches the SCVMM inventory collection from REXML to Nokogiri. The changes were largely to account for some remaining differences between those two libraries. There were also some minor formatting tweaks.
The benefits include a major reduction in memory usage and a minor speed boost.

NoMethodError: private method `load' called for Nokogiri::XML::Document:Clas

Not sure I understand the error yet, since the miq_nokogiri.rb wrapper defines a load method. Maybe we have to explicitly require it.

@gmcculloug Please review.
@djberg96 Are there tests for this already (on the miq-xml side) or does this need new specs?

@Fryguy There are already tests. See gems/pending/test/xml/tc_nokogiri.rb, which I had to modify slightly.

Ok, I basically flipped the logic around, replaced the singleton method, and test for rexml instead of testing for nokogiri. The assumption now is that nokogiri is the default, but you can still specify rexml if desired.

@djberg96 You can ignore my comments here since they are mostly nitpicks.
It is late and I'm procrastinating from doing my other work.

@kbrock No problemo, always nice to have another pair of eyes. Now I need to figure out what's causing these test failures. I think it's a test setup issue, as my local copies of the relevant files seem to parse things fine.

Closing this one. Attempting to default to Nokogiri just isn't practical because too many files assume REXML internally.

sad day for @tenderlove

@kbrock Rejoice! https://github.com/ManageIQ/manageiq/pull/3786
I just took a step back and decided to just focus on what was necessary for the original BZ.