Roll Engine from 3984c21bd8b8 to 201ee6f792f9 (11 revisions)

https://github.com/flutter/engine/compare/3984c21bd8b8...201ee6f792f9
2021-06-11<EMAIL_ADDRESS>Roll Skia from 1907f9051e17 to 9b0841d822c3 (1 revision) (flutter/engine#26713)
2021-06-11<EMAIL_ADDRESS>Revert dart rolls (flutter/engine#26714)
2021-06-11<EMAIL_ADDRESS>[web] text_editing_test.dart nnbd; bump test dep (flutter/engine#26709)
2021-06-11<EMAIL_ADDRESS>Roll Skia from bc215ba3bbfe to 1907f9051e17 (1 revision) (flutter/engine#26708)
2021-06-11<EMAIL_ADDRESS>Roll Dart SDK from c8a66f8e7ca1 to 935470ea59c4 (1 revision) (flutter/engine#26707)
2021-06-11<EMAIL_ADDRESS>Add support for native callbacks to the macOS embedder test harness (flutter/engine#26694)
2021-06-11<EMAIL_ADDRESS>Roll Skia from dd84dd09f304 to bc215ba3bbfe (2 revisions) (flutter/engine#26706)
2021-06-11<EMAIL_ADDRESS>Roll Skia from 2a07fd68ebdd to dd84dd09f304 (2 revisions) (flutter/engine#26704)
2021-06-11<EMAIL_ADDRESS>Roll Dart SDK from d622b98e77d7 to c8a66f8e7ca1 (1 revision) (flutter/engine#26703)
2021-06-11<EMAIL_ADDRESS>Roll Skia from 08ac524b4331 to 2a07fd68ebdd (1 revision) (flutter/engine#26702)
2021-06-11<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from jNlbyBr6p... to OP_AFyX5C... (flutter/engine#26701)
Also rolling transitive DEPS:
fuchsia/sdk/core/mac-amd64 from jNlbyBr6pSn1 to OP_AFyX5CNKN
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

"Windows tool_tests_commands" has succeeded but it's not getting picked up here @CaseyHillers.


Route Service feature seems to be misconfigured

Reading cf docs, one may assume that route services are enabled when
properties:
 router:
   route_services_secret: YOUR-SECRET-PASSPHRASE

is set in the router instance group for gorouter job.
Indeed this is what we see in [cf-genesis-kit/manifests/cf/router.yml](https://github.com/genesis-community/cf-genesis-kit/blob/9e4fef13cb11e3805f3d7e197fabc397bc934a35/manifests/cf/router.yml#L21
This, however, does not enable route service support, and all attempts to create a user-provided-service with -r option fail with error, to the effect of "Support for route services is disabled. This service instance cannot be bound to a route."
It looks like Route Service will be enabled when the following configuration is applied to the api instance group:
jobs:
- name: cloud_controller_ng
  properties:
    router:
      route_services_secret: (( vault meta.vault "/gorouter/route_services:secret" ))

Fixed with PR #94


RuntimeError: Error(s) in loading state_dict for ControlLDM

stable_diffusion_inpainting_controlnet_colab.ipynb doesn't work.

Hi @haofanwang 👋 thanks for the info ❤

Hi @haofanwang 👋 this one is working please try it https://github.com/camenduru/stable-diffusion-webui-colab/blob/v2.0/stable_diffusion_inpainting_webui_colab.ipynb


Implement Events Card Mockup

ITS-Pro time category: https://its-pro.ucsd.edu/browse/MA-113
This is done when:

[x] Events card redesign integrated to campus mobile
[x] If event has no image, then use student placeholder image
[x] Event detail text renders (both light mode and dark mode) on physical device

[x] Event tile widget file reimplementation (to fix the alignment and container size issue, try to avoid magic numbers)
[x] Clip thumbnail images to one shape such that the width fits the container
[x] Dark mode theme is supported
[x] New placeholder image for the event tile widget (no white border)
[x] Resolve rendering issue for detail view seen on TestFlight

[ ] PR 1662 Test Plan PASS on iOS
[ ] PR 1662 Test Plan PASS on Android

Notes:

tags attribute is available via Events API for Category filtering
college attribute is not available via Events API for College filtering. Omit College filter from implementation

https://xd.adobe.com/view/5f69745a-1bcd-4b0e-8785-eb1df9a72c2e-0a3a/

Failed on iOS, saw a lot of the same issues Kevin reported on Android.

The rendering issue is not caused by dark mode/brightness. When I switched to light mode, the text still won't show up. Investigating if it's a data fetching issue or caused by something else.

iOS and Android testing complete from me. Provided notes in both spreadsheets. Android build may not be a pass. Formatting issue, requires further investigation.

Same results as peter, they functioned properly, but I noticed some formatting errors on Android. There are some design choices that might need to be followed up on (the arrow on each tile and the spacing between each card)


FLightSQL: add helpers to create CommandGetCatalogs, CommandGetSchemas, and CommandGetTables requests

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
FlightSQL has several APIs for a server to report available catalogs, db schemas, and tables. These APIs require filtering and sorting against the available information, which can be re-used across implementations.
Describe the solution you'd like
IOx contains implementations to simplify handling these requests that could benefit other rust implementations.
Describe alternatives you've considered
Not doing it.
Additional context

label_issue.py automatically added labels {'arrow'} from #4296

label_issue.py automatically added labels {'arrow-flight'} from #4296


Update paydollar.rb

As our system structure have some update, the payment link require to change.

@SimonLeungAPHK looks good, can you please update the tests too, thanks

@elfassy The test page have updated, please check again. Thanks.

@elfassy May I know when will changes apply to production? Thanks.

@SimonLeungAPHK Looks like tests are not passing. It usually takes a couple of weeks once merged to get changes to production

@elfassy We have applied the changes again after the test run failed.  How would we rerun the test again? Or we have to submit another pull request ? thanks.

test will run after any code change to this PR

<"https://www.paydollar.com/b2c2/eng/payment/payForm.jsp"> expected but was
<"https://www.paydollar.com/b2c2/eng/payment/payShopify.jsp">

You also need to update the tests:
https://github.com/activemerchant/offsite_payments/blob/master/test/unit/integrations/paydollar/paydollar_module_test.rb#L16
https://github.com/activemerchant/offsite_payments/blob/master/test/unit/integrations/paydollar/paydollar_module_test.rb#L23

@elfassy We have updated the test. Could you help to continue process this PR?


Add health check to make sure  Developer Mode is on for Android devices

Make sure Android device developer mode is on before reserving tests.
Related issue: https://github.com/flutter/flutter/issues/75164

This has been implemented and validated in staging pool.


Improve IPython 4.0 compatibility

Try IPython 4.0 imports
fall back to IPython 3.2

Automatic tests only test IPython 3.2.

@pl31 this looks great.  I noticed that you originally bumped the requirements to >=3.2.1 rather than exactly equal, but then it looks like you restored it back to an exact check.  Are there still test failures on 4.0 that we should fix?  I think the easiest way to test both versions would be to make the IPython version part of the travis build matrix.  Does that seem reasonable?

It also might be worth pulling out the shared logic of "try to import from IPython 4, fall back to IPython 3" into an ipython_compat module.  That can be added later though.

@ssanderson I restored the exact dependency, as it broke the test.
I justed checked (found) some documentation here. See chapter 3.3 Imports:
"IPython 4.0 includes shims so if you have the dependencies all imports that
work on IPython 3 should continue to work on IPython 4."
I will investigate a little bit further, and do some tests with a 'ipython_compat' module. This sounds like a good idea.

In this test run you can find exactly the same error I encountered using pgcontents with IPython 4.0.

@pl31 interesting.  It looks like with the new updates to traitlets, we're not configuring our custom subclasses correctly in the tests anymore.  I'll try to take a stab at finding the right way to do this over the holiday.

also interesting that this is only failing in Python 3.4, which makes me wonder if this might be an upstream bug.  ping @minrk, do the type-checking failures in https://travis-ci.org/pl31/pgcontents/jobs/93214358 ring any bells for you?

Now the test fails for python 2.7 as well :(. Funny enough the build works perfectly in 'my' branch.
I have to stop now, but will continue the next days.
Do you have any proposal how to build an 'ipython_compat' module?

Looks not that bad now. Still this pull request just adds IPython 4 compatibility and related tests, but it still won't work due to the fixed version in requirements.txt. Two new requirements files for the tests are included, so the original requirements.txt could be modified.

Looks like you got this sorted before I got around to checking in, but you are right that you need to be careful about importing if you have some of the post-4.0 packages, but IPython < 4, since type checks fail when you mix two implementations of traitlets.


[Crash]: Portal 2 crashes when loading the plugin (Wine)

Portal 2 crashes when trying to load the plugin (plugin_load sar)
SAR 1.12.8-pre10 (Built 00:05:36 Mar 16 2023)
Segmentation fault caused by address 0x0072ccbb
	(+0x32d020) [0x0072ccbb]
	(+0x32d020) [0x1bc24773]
	(+0x32d020) [0x1bcfba73]
	(+0x32d020) [0x0a8a7679]
	(+0x32d020) [0x0a8a86b2]
	(+0x32d020) [0x0a8a876b]
	(+0x32d020) [0x0a9e8477]
	(+0x32d020) [0x0a8c9dac]
	(+0x32d020) [0x0a8c9f87]
	(+0x32d020) [0x0a908515]
	(+0x32d020) [0x0a908fe3]
	(+0x32d020) [0x0a917b1b]
	(+0x32d020) [0x0a917c6a]
	(+0x32d020) [0x0a917d04]
	(+0x32d020) [0x0a96a15d]
	(+0x32d020) [0x0a968f40]
	(+0x32d020) [0x0a96905f]
	(+0x32d020) [0x0a969a9e]
	(+0x32d020) [0x100090c0]
	(+0x32d020) [0x004011dc]
	(+0x32d020) [0x0040177e]
	(+0x32d020) [0x7b828a50]
	(+0x32d020) [0x7bc5afe7]
	C:\windows\system32\ntdll.dll(RtlCreateUserThread+0x5b820) [0x7bc5b820]

ok nvm i just used an older version by nekzor and it worked


opt: improve key_memcmp with word-comparisons

This does word-wise comparisons for the two slices in key_memcmp. This gives another 10% or so improvement over the previous PR.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#515  👈
#514
#511
#510
#509
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rphmeier and the rest of your teammates on  Graphite


Add hysteresis to PopupMenu

Closes #11219
Before:

After:

However I have some problem with menus not closing correctly, so the PR is WIP. If anyone knows why using popup() on a sub-menu disables gui_input on the parent popup and why changing it to show+grab_focus breaks nested menus, that would be helpful.
Here's some scene for testing:
GUI.zip

Superseded by #41851.


Tests

This gets us up to 100% test coverage and fixes a bunch of polr issues (some in #39, for instance)

This all looks great to me! Do we need to merge in the mathjax branch before this one or does it matter?

I made the branch from master, not mathjax, so there are a few conflicts in the diff that'll need to be handled manually. I'll do that tomorrow

Okay, no worries. I would have merged that one in already but I wanted to fix whatever I had broken with the glm extractor first. I think you may have basically done that here so hopefully it won't be too bad.


Update dependencies (mostly AWS SDK)

Bump version of AWS SDK to latest.
I am currently using my fork's changes in an iOS project of mine and it is working good.

Any chance on getting this reviewed/merged?  I've been using @levibostian branch since November in multiple projects without any issues.

To make this PR even better, we may want to consider doing a couple of changes that I have discovered since making this original PR.

Change the Gemfile ruby version from 3.1 to 3. From AWS's docs, they follow symantic versioning so we can be safe with declaring the major version only to prevent us having to update this plugin as frequently when minor changes happen.
The aws ruby gem in v3 added gem modularity. Instead of us having to install aws-sdk ruby gem, we can just install aws-sdk-s3. See list of all gems

Closing as other PR got merged


fix get link download lowResolution

update got version
replace
const link = res.body.split('sd_src_no_ratelimit:"')[1].split('",aspect_ratio:1,')[0];
to
const link = res.body.split('sd_src:"')[1].split('",hd_tag')[0];

yes i try sample link it work but me tested on new video other page not working.
const video = 'https://www.facebook.com/9gag/videos/10155721204506840/';

I tested it and your solution is working with every link I used. Good find!
Thank you!


support turbo-16k

Thank you I like what you've come up with, however the idea you have given me going forward is that the model should be chosen by a message property. But I believe msg.model may be less conflicting than using msg.topic due to existing flows/examples. I've created a issue #9 to give more information about requirements for how this feature should be implemented.

Thank you for your reply. I appreciate your feedback and look forward to the new version.


Add in test dependency on pytest.

While there are no tests currently defined, this sets it so that it can use pytest in the future.

CI:

Linux
Linux-aarch64
Windows


Flutter IOS - Thread 1: EXC_BAD_ACCESS (code=1, address=0x0) error in xcode

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
I updated my xcode from version 13.4.1 to version 14.3, when I run my flutter app the following error appears in the SharedPreferencesPluguin.
Expected results
in this part of the code let messenger = registrar.messenger() following error appears Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)
Actual results
The package uses the following version specification:
shared_preferences: ^2.0.12
Code sample
Code SharedPreferencesPluguin
import Foundation

#if os(iOS)
import Flutter
#elseif os(macOS)
import FlutterMacOS
#endif

public class SharedPreferencesPlugin: NSObject, FlutterPlugin, UserDefaultsApi {
  public static func register(with registrar: FlutterPluginRegistrar) {
    let instance = SharedPreferencesPlugin()
    // Workaround for https://github.com/flutter/flutter/issues/118103.
#if os(iOS)
    let messenger = registrar.messenger()
#else
    let messenger = registrar.messenger
#endif
    UserDefaultsApiSetup.setUp(binaryMessenger: messenger, api: instance)
  }

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
2023-05-08 10:06:39.748064-0300 Runner[11700:114618] <SKPaymentQueue: 0x6000007a4670>: No observers found that respond to "paymentQueue:shouldAddStorePayment:forProduct:", will not check for purchase intents
2023-05-08 10:06:39.789407-0300 Runner[11700:114875] 10.3.0 - [FirebaseMessaging][I-FCM002022] APNS device token not set before retrieving FCM Token for Sender ID '33811314958'. Notifications to this FCM Token will not be delivered over APNS.Be sure to re-retrieve the FCM token once the APNS device token is set.
2023-05-08 10:06:39.791714-0300 Runner[11700:114879] 10.3.0 - [FirebaseMessaging][I-FCM001000] FIRMessaging Remote Notifications proxy enabled, will swizzle remote notification receiver handlers. If you'd prefer to manually integrate Firebase Messaging, add "FirebaseAppDelegateProxyEnabled" to your Info.plist, and set it to NO. Follow the instructions at:
https://firebase.google.com/docs/cloud-messaging/ios/client#method_swizzling_in_firebase_messaging
to ensure proper integration.
(lldb)

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.7.0, on macOS 13.1 22C65 darwin-x64, locale pt) • Flutter version 3.7.0 on channel stable at /Users/pedro/fvm/versions/3.7.0 • Upstream repository https://github.com/flutter/flutter.git • Framework revision b06b8b2710 (3 months ago), 2023-01-23 16:55:55 -0800 • Engine revision b24591ed32 • Dart version 2.19.0 • DevTools version 2.20.1

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2) • Android SDK at /Users/pedro/Library/Android/sdk • Platform android-33, build-tools 33.0.2 • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495) • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3) • Xcode at /Users/pedro/Downloads/Xcode 2.app/./Contents/Developer • Build 14E222b • CocoaPods version 1.11.3

[✓] Chrome - develop for the web • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1) • Android Studio at /Applications/Android Studio.app/Contents • Flutter plugin can be installed from: 🔨 https://plugins.jetbrains.com/plugin/9212-flutter • Dart plugin can be installed from: 🔨 https://plugins.jetbrains.com/plugin/6351-dart • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] IntelliJ IDEA Community Edition (version 2022.1.4) • IntelliJ at /Applications/IntelliJ IDEA CE.app • Flutter plugin can be installed from: 🔨 https://plugins.jetbrains.com/plugin/9212-flutter • Dart plugin can be installed from: 🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.76.0) • VS Code at /Applications/Visual Studio Code.app/Contents • Flutter extension version 3.62.0

[✓] Connected device (3 available) • iPhone 14 Pro (mobile) • CD024760-9AF2-42C8-B34D-C1F79D73141C • ios • com.apple.CoreSimulator.SimRuntime.iOS-16-4 (simulator) • macOS (desktop) • macos • darwin-x64 • macOS 13.1 22C65 darwin-x64 • Chrome (web) • chrome • web-javascript • Google Chrome 113.0.5672.63

[✓] HTTP Host Availability • All required HTTP hosts are available

Hi, have you tried upgrading shared_preferences to the latest version?
shared_preferences: ^2.1.0

I tried it now, got the same error

You upgraded xcode, did you also upgrade your cocoapods dependencies?
pod clean
pod install

if you need to upgrade your dependencies, then run pod update as well.
It may also help to run  flutter clean as well.

Thanks for the report @Pedro-rdn
Can you provide the complete error log that shows the error line reported as in title ?
The logs you shared doesn't seem to be related to shared_preferences package.
Maybe related to https://github.com/flutter/flutter/issues/118103 as mentioned in the code snippet shared.

I have same error

This snippet of code cause the error
public static func register(with registrar: FlutterPluginRegistrar) {
    let flutterChannel = FlutterMethodChannel(
        name: Definitions.CHANNEL_FLUTTER_PLUGIN,
        binaryMessenger: registrar.messenger())

    SwiftAwesomeNotificationsPlugin()
        .AttachAwesomeNotificationsPlugin(
            usingRegistrar: registrar,
            throughFlutterChannel: flutterChannel)
}

i solved the error, the problem was not shared preferences, it was ios 16, i solved it by deleting the ios folder and running flutter create . in the project and resetting the folder


[FLINK-11547][flink-connector-kinesis] Fix JsonMappingException in DynamoDBStreamsSchema

What is the purpose of the change
This pull request resolves an exception while using the provided DynamoDBStreamsSchema class in the Flink Kinesis Connector.
Brief change log

Replace ObjectMapper instance with RecordObjectMapper in DynamoDBStreamsSchema

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
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, Kubernetes/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

@flinkbot approve all

@tweise looks like CI failed for some transient reason:
rm: cannot remove '/home/vsts/work/1/s/flink-end-to-end-tests/test-scripts/temp-test-directory-39845753958/tmp/backup': No such file or directory
The STDIO streams did not close within 10 seconds of the exit event from process '/bin/bash'. This may indicate a child process inherited the STDIO streams and has not yet exited.
##[error]Bash exited with code '2'.

How can we trigger a new run?

@flinkbot run azure

@rmetzger above did not trigger rerun for the failed test. How do I go about it?

The most reliable way is pushing a new commit (empty commit in this case I guess). I've asked @zentol to look into why the manual trigger didn't work.

@flinkbot run azure

@rmetzger there appears to be something broken with the CI. Is there anything we can do to move this forward?

@flinkbot run azure

The bot command is working now, let's wait for the test result. I see successful CI runs in other PRs.

@tweise success! What are the next steps?

Actually all test runs show a failure when you click through, regardless what is shown in the status here. That's quite confusing. The failures also have nothing to do with the change in this PR.

@flinkbot run azure

We are looking into the CI bot issues. Sorry for the inconveniences

The problem is probably just a side-effect of a bug in the CI bot (it was triggering the same build multiple times, and we can not distinguish the builds properly from the status GitHub is reporting). We should not have this problem with regular builds.


Prevent MsgHdr::with_control with empty buffer causes error in macOS

Otherwise panic when cfg(debug_assertions) will be another good prevention.

To tell about the valid reasons, I am not familiar with low level socket API that much.
At least it was a programmer error for my case. Is panic better?

To tell about the valid reasons, I am not familiar with low level socket API that much. At least it was a programmer error for my case. Is panic better?

No, I would say not doing anything would be better. We're not going to introduce panics in our API, but hiding errors/problematic code is also not something we want.

It was a small glitch but painful to debug.
I finally could find the buffer is wrong, but it was hidden inside socket2 crate.
As a library user, I could see something goes wrong on sendmsg but not on with_control. If with_control is not expected to be called with empty buffer by nature, it could be warned at the moment, instead of deferring it.
Maybe one of the reason was Debug for MsgHdr was useless and didn't display its contents.
I changed the patch to debug_assert!() make it neither panic(in real use) nor hiding and deferring error. Please take a review if you agree it is a UX caveat.

I understand your concern. Is there any plan to implement better Debug for MagHdr in that case? Debug can be platform-specific implementation and it will not affect any actual behavior. Minor platforms still can use current implementation

A pr for that would be accepted.

Closing this since I still don't think it's something we want.


[Perforamnce] Feature to use Zlib-ng

For my workflow (Gstreamer encoding 50 fps in 4k using https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/video/png) I needed a bit of performance. This more or less solved my speed issues.

Could you take a look at #364 and see if that helps for your usecase? If we can get away with pure Rust dependencies we avoid some difficulties around cross compilation and conflicting features (which seems to be causing a few of the CI failures).

Could you take a look at #364 and see if that helps for your usecase? If we can get away with pure Rust dependencies we avoid some difficulties around cross compilation and conflicting features (which seems to be causing a few of the CI failures).

That broke encoding completely in my case :/
I did test https://github.com/image-rs/image-png/pull/363 also, but it seemed to be worse with it. (Tho my measuring here is based on how fast memory fills up. I have a queue before processing)

Hm, weird that #364 broke encoding for you. It would be super helpful if you could share exactly what went wrong in that other PR thread given that we're moving towards merging it...

Hm, weird that #364 broke encoding for you. It would be super helpful if you could share exactly what went wrong in that other PR thread given that we're moving towards merging it...

Got cold so can't access my work PC, but you should be able to reproduce my case. (Not sure how familiar you are with gstreamer, but wont hurt to learn it)
Example pipeline that records 4k images.
gst-launch-1.0 videotestsrc is-live=false num-buffers=10 ! videoconvert ! video/x-raw, format=RGB, width=3840 , height= 2160 ! rspngenc compression-level=2 filter=4 ! multifilesink location="out/frame%d.png"

You will need to install gstreamer https://gstreamer.freedesktop.org/documentation/installing/on-linux.html?gi-language=c

Next git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs and cargo build -p gst-plugin-png --release. It should create .so lib for png plugin.

Add its dir to gst plugin path  export GST_PLUGIN_PATH=<path-to-release-folder>:$GST_PLUGIN_PATH

Try out previously mentioned pipeline. Make sure that it works and png files are not corrupted

Now change https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/video/png/Cargo.toml png to your performance branch.

Recompile

Try pipeline again and inspect generated PNGs (They should be corrupted)

I tried the steps you suggested but the resulting images seem to be valid. However, an old version of my branch did used to produce subtly corrupt images.
When you get a chance, if you're able to share one of the corrupted PNGs that would be very helpful for debugging purposes. This is the first frame I get when running your command with compression-level=1 (my branch only swaps out the compression algorithm if mode "fast" is selected):

Ou ye compression-level=1  in pipeline. I was using commit 975d4f873eb9374d0fa6e4c31e17e88d36857a47. Just checked the latest changes and it works :)
Tho wouldn't this feature flag help as well?

One drawback I see in your branch:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2022-12-02T12-33_day-2_red-table-7_h34.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2022-12-02T12:33:01.000000Z
  Duration: 00:00:26.44, start: 0.000000, bitrate: 1987370 kb/s
  Stream #0:0[0x1](und): Video: png (png  / 0x20676E70), rgba(pc, gbr/bt709/iec61966-2-1, progressive), 3840x2160, 1987368 kb/s, SAR 1:1 DAR 16:9, 50 fps, 50 tbr, 5k tbn (default)
    Metadata:
      creation_time   : 2022-12-02T12:33:01.000000Z
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]

My branch
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2022-11-25T14-28_day-2_red-table-7_h34.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2022-11-25T14:28:30.000000Z
  Duration: 00:01:27.72, start: 0.000000, bitrate: 643139 kb/s
  Stream #0:0[0x1](und): Video: png (png  / 0x20676E70), rgba(pc, gbr/bt709/iec61966-2-1, progressive), 3840x2160, 643137 kb/s, SAR 1:1 DAR 16:9, 50 fps, 50 tbr, 5k tbn (default)
    Metadata:
      creation_time   : 2022-11-25T14:28:30.000000Z
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]

Bitrate increase to 1987370 kb/s from bitrate: 643139 kb/s (3x)

The problem isn't the native dependency per-se, but rather the way these are integrated (as in this case). It's a compile time choice. But features in Cargo.toml are additive, that is, the final build configuration is the union of all features specified through the whole dependency tree. In theory, the png library shouldn't even be drawn into this configuration choice of flate2.
Unfortunately, the usual case does not implement features as additive and flate2's rust backend is mutually exclusive with the zlib-ng backend. I don't think that this is something we can or want do about here.
In particular, also note that this is breaking because downstream can (and probably did) specify the dependency on png:
[dependencies.png]
default-features = false

Imagine we could detect the encoder choice at runtime, by some available method in flate2. Compare this to SIMD detection in jpeg, for instance. There's a feature that enables the detection and the SIMD code portion, but if that feature is not enabled then it will simply always use the slow fallback. That's purely additive and it suffices if the final binary enables it, no matter how deep in the dependency tree all other consumers will benefit without them having to explicitly specify or change their code base.
The depth really matters since I'd strongly veto propagating the flag to image as well, but we'd have to with the design of this PR / the design of flate2's feature flags.


Using as prop don't keep the styles defined by the component

Environment

System:

OS: Linux 4.18 Ubuntu 18.04.2 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
Memory: 191.34 MB / 7.70 GB
Container: Yes
Shell: 4.4.19 - /bin/bash

Binaries:

Node: 11.13.0 - /usr/bin/node
Yarn: 1.15.2 - /usr/bin/yarn
npm: 6.7.0 - /usr/bin/npm

npmPackages:

styled-components: ^4.1.3 => 4.2.0

Reproduction

https://codesandbox.io/s/xjk57mlmr4
The styled-components version in the reproduction is the: 4.2.0
Expected Behavior
The expected behavior is what is described in the doc, that if I want just change the HTML element but keep all the defined styles I can use the as prop.
Actual Behavior
When I create a styled component that renders an p HTML element:

Text.js

const StyledText = styled.p`
  margin: 0;
  color: blue;
  font-size: 20px;
`;

const Text = ({ style, as, className, children }) => (

);

I create another component that applies other styles to the Text component and uses it. What happens is that the StyledLabel lost the Text style if I use the as prop:

Example.js

const StyledLabel = styled(Text)`
  font-weight: bold;
`;

const Example = () => (

Example

);

Ran into this as well, what happens makes sense tho.
Using your example above setting as on StyledLabel will replace the component, in this case Text with label.
But what you are trying to do is set the inner components as prop, ie you don't want the first styled component to consume it. Kind of like good ol ref vs innerRef, if you were to make an innerAs and use that in your text component everything would work as expected.
Code sandbox example:
https://codesandbox.io/s/2xj2kw2q5n

Oh, I got it.
The point is that I was passing the as prop to the first level of the styled component instead to pass to the last component.
It does total sense, thank you so much @Flydiverny


Doubt on YAML header and deconfiguration of "highlight" attribute in 'html_document' output

Hi, Mr. George Cushen,

My repo: https://github.com/lsbjordao/academic
Blog: https://lsbjordao.netlify.com

I do not know if this place is the best place to ask about an issue I've been facing, because that's certainly not a bug. I have tried every possible way to solve this problem alone, but I can not solve it. If you indicate the best place for it, I will search for it.

I used the YAML header in the .rmd file and through the Knit function, I generated an .html file, which contained NO YAML header. So, I include the same YAML header from the .rmd file in the generated .html file... But, when I submit it to github + Netlify, the page rendered by Netlify deconfigures the attribute "highlight: tango", the background color of the chunk results became gray instead of white, and the title became duplicated. (Ex: Post 1))
However, when I do NOT include the YAML header in the .html file, the page is perfect, but without the menu (or navigation bar). (Ex: Post 2)
The only post where everything was correct was this one: Post 3)

Really thank you!

ERRATE: Correct link from post 3:
Post 3

ERRATE: Correct link from Post 3

As stated in the docs, Rmarkdown should be used, not Rmd.


how to use data from the query

Hi! I am very new to Grafana, Javascript and SQL. I am now trying to develop an interface on ACE.SVG. I have no trouble with my query. Although, I can't find the way to use it properly with this plugin. Could someone give me a quick example or explanation on how to get my data?
I have seen this demo, but this is very unclear to me. Especially "let buffer = data.series[0].fields[1].values.buffer;".
options.animateLogo = (svgmap, data) => {     let buffer = data.series[0].fields[1].values.buffer;     let valueCount = buffer.length     let chartData = [];     for (let i=0; i<valueCount; i+=(Math.floor(valueCount / 4)-1)) {         chartData.push(buffer[i])     }     let minData = chartData.reduce((acc, val) => {         return Math.min(acc, val);
Thank you to help a beginner!

@SamuelJoly
The data variable is how you access the Grafana data frame API.
Grafana has great documentation for that API here: https://grafana.com/docs/grafana/latest/developers/plugins/data-frames/
All the code above is just sampling values from the time series, specifically 4 values, at even spacing, then getting the max and min from that set of 4 values.
Also remember you can use your browser's developer tools and console.log() to dig into any of this.
Here's pseudocode with literal values:
let buffer = [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,16,17,18,19] // The first series in the data frame, the second column (value rather than timestamp) and the values in the form of a single buffer, or array let valueCount = buffer.length // this is just capturing the length of the series for clarity let chartData = [] // this is just making an empty list for us to put the 4 samples we want into for 0 through 3 as i, get the value at the address i times 1/4 the length of the list, and add that value to the chartData array let minData equal the smallest value in the chartData Array we built
Does any of that help?

Thank you! This makes it very clear!
Might have other questions later ;)


Update connector version to 0.13.0-SNAPSHOT

Problem description
Update connector version to 0.13.0-SNAPSHOT on master branch
Problem location
build configuration
Suggestions for an improvement

Closed via #155


Add our first unit test

Added notes on how to run and update testdata using make test and make test UPDATE_GOLDEN=true to our contributing.
Added failing test to demonstrate how it all looks when a test fails. Will fix before merging. 😉
Tweaked command constructor to pass in an alternate output so we can validate test output.
I pulled in pkg/errors because stack traces make troubleshooting failing tests so much easier.

TODO

[x] Need to setup a test http server in the test and point our kubeconfig at it.
[x] ~Once we are okay with this, I'll remove the temporary function and plumb the rest of the commands with the alternate output.~ oops, I had to do it sooner than I had thought because reasons. 😀

Closes #30

@carolynvs looks like CI failure is legit

@arschles Yup! I broke it on purpose (see the OP) so that people could see what a failing test would look like. I'll fix it before merging if everything else is good.

I've fixed the purposefully failing test and got a passing build. Is it okay for me to merge or do we want another set of 👀?

@carolynvs this needs a rebase 😦


fix: enable status endpoints

Signed-off-by: Andrew Rudoi<EMAIL_ADDRESS>
What this PR does / why we need it:
This PR adds the kubebuilder annotations for enabling the status endpoint. The status patches don't work without this being enabled, as far as I'm aware.
Release note:

👍
/approve
/lgtm


Capture R errors

The logging is very useful but when an issue occurs that doesn't have a built-in logging message then there is no feedback as to why this may have occurred. Obviously one option would be to add logging messages for all possible issues but this will end up being essentially a rewrite of R's own warning/error system. Given this, it might be a good idea to set up console sinking to a separate logging file (https://stackoverflow.com/questions/11666086/output-error-warning-log-txt-file-when-running-r-script-under-command-line) as a secondary debug tool.

Hi @seabbs , do you have an example of these? we should be getting the warning / errors caught into the logs from the run-regional and once the global switch over that should do likewise.

From the script that launches EpiNow2? This was happening when I was hacking around with the global level estimates so perhaps will also be resolved when switch over to the new format?

yes, the global levels don't yet go through the same error handling.
https://github.com/epiforecasts/covid-rt-estimates/blob/master/R/run-region-updates.R#L59 should give you an idea of what we have done so far:
WithCallingHandlers get triggered in the call stack at the point of the error.
Warnings can then continue without breaking (which happens with try/catch loop catching warnings) and the muffle command stops them propogating to other handlers. This could have the trace added but could get very noisy! Perhaps we could add it to log the stack trace at "trace" debug level
Errors log the stack trace location using this (so the trace is from the correct point in the call stack) then bubble to the error handler in the try/catch
Try catch has the error bubble up to it and handles logging and continuing.
It's slightly cumbersome to need the three prongs but it seems to cover off all the scenarios. It's annoying that the error object in R doesn't contain the triggering trace so you have to dump it yourself!

ah okay that all sounds sensible. Thanks!


UP034 misses unnecessary parenthesis

class C:
    def __init__(self, arg):
        ...

    @classmethod
    def from_env(cls):
        return cls(arg=("str"))

Run ruff check --fix test.py with such config:
[tool.ruff]
select = ["UP"]

I expect ruff to remove the parenthesis around "str":
class C:
    def __init__(self, arg):
        ...

    @classmethod
    def from_env(cls):
        return cls(arg=("str"))

I don't think this is in scope for the upgrade rule as these parentheses were never necessary. Perhaps I misunderstand the intent of the rule though cc @charliermarsh

I'm not sure that any lint rule is relevant here. However, the ruff formatter doesn't remove those parentheses, whereas it does for:
def fun():
	return (1 + 1)

It seems that the formatter doesn't format function call arguments correctly.

We could consider a separate rule for removing superfluous parentheses.

I think that the last time this came up, we said we'd treat it as a request to implement Pylint's C0325: https://github.com/astral-sh/ruff/issues/2389. So let's do the same here.


feature/TECH 598 separate mpyl stages

TECH-598 Add the option to pass a stage to the build run cli command
TECH-598 Add stage arg to the runner
TECH-598 Split up the jenkins stages per mpyl stage

📕 TECH-598 Separate stages in runner
Add a flag to run mpyl build command: e.g. --stages build
This should run the flow up to_ _and including stage Build.
This is to ensure no stages are skipped and the step requirements are filled in.
Caching ensures that the stages and not run over again.
Sample flow in jenkins:
stage('Build') {
  mpyl build run --stages build
}

stage('Test') {
  mpyl build run --stages test
}

stage('Deploy') {
  mpyl build run --stages deploy
}

stage('PostDeploy') {
  mpyl build run --stages postdeploy
}

🏗 Build 13 ✅ Successful, started by Jorg Post
🚀 cloudfront-service, example-dagster-user-code, job, kong-sync, nodeservice, sbtservice, sparkJob

Closing and re-opening the pr to see if that fixes the stuck pipeline build check


Refactor statistics calculations

This PR does an ND refactor of the statistics calculation routine. Here is a list of major changes:

The krige and krige3d methods in the core module have been merged in _krige.
The find_statistics and find_statistics_3d methods in core have been merged into _find_statistics.
_find_statistics has been updated to deal with the potential for subsequent kriging points being too close together... Previously, the mean error could at times end up being basically zero (< 1e-10), which lead to problems in the statistics calculation. The should robustify the statistics calculation routine.

This address steps 3 and 4 in #31.

Cool, thanks. You're much better with the nuances and details of Python than I am, so I appreciate the reviews!


[Enhancement] Show mokapot fit information

In particular it would be nice to have the report that shows how many peptides pass fdr filtering and the weights for every column.

Added in https://github.com/TalusBio/diadem/pull/14/commits/2d03ef8edf9fb6d92ffc28c1e463439f11a0e39e


Update to last Vue CLI v4 template

Hello,
Eventually I had the time to create this PR we talked about for months now! Hope this will work flawlessly...
This PR is way smaller than Vue CLI3 and should be way shorter to review too... I still hope to find time to make Wegue fully functional with Vue-CLI V5 in a not too distant future... it already is, only unit tests are having some troubles...
This one is based on the last Vue CLI V4 template (4.5.19).
New Wegue functionalities developed since this migration was done have been merged before applying. So this PR should be up to date for now...
To stay in tune with one of our previous discussions, minimal versions of node and npm have been set according to the official Vue documentation where it is stated that minimal recommended version is V10+. However I took
"engines": {
  "node": ">= 10.13.0",
  "npm": ">= 6.4.1"
}

to use the first LTS version among V10 ones.
We also discussed an issue with the portfinder mechanism:

For some reason the portfinder mechanism of the dev-server runs into a problem when port 8081 is already in use. It correctly finds a free port (8082 for me) and spawns the service there, but some internal part still adresses 8081, so I see a lot of GET http://localhost:8081/sockjs-node/info?t=1661260791345 net::ERR_FAILED 404 in the logs. I wonder if something can be done about that issue?

it seems to be working as expected with the underlying updates that this PR makes.
If this is of interest for you and to make a followup of my comment, I can try and see if I can easily add the official Vuetify plugins in order to have access to Vuetify ESLint rules. I already did it with ESLint plugin only, not with the full plugins pack. Just tell me if this is of interest and I'll give it a try as soon as I'll have a little time...
Merry X-Mas to the whole team!
Cheers
Sébastien

Hi @sronveaux.
I didn`t find time to give this a test yet - hopefully will have by the beginning of next year.
From looking over the code there are suprisingly little changes.
Regarding eslint-plugin-vuetify:
In general I appreciate the idea. Is installing the plugin an option when creating an app via cli-4? If so it might go in here.
But keep in mind that this will probably impose some more code changes. So when in doubt put this in a separate PR.
The choice of "node": ">= 10.13.0" makes perfectly sense to me.
Anyway, thanks a lot for providing this so quickly! I wish you a nice and relaxing christmas time.
Cheers,
Felix

Hi @fschmenger,
Thanks for the fast reply, don't worry and take your time...
As you said, there is nothing big here, the transition from V2 to V3 was huge compared to this...

Regarding eslint-plugin-vuetify:
In general I appreciate the idea. Is installing the plugin an option when creating an app via cli-4? If so it might go in here.
But keep in mind that this will probably impose some more code changes. So when in doubt put this in a separate PR.

Installing the plugin is not an option when creating an app but almost. When the new app is created, you start by running vue add vuetify which runs you through another wizard (such as when creating a pure Vue app) and changes the package.json and main.js files accordingly. So it's something you should do directly as another app template is applied at that time.
The idea would be to stick with the Vuetify version currently used by Wegue but adding some Vue-CLI possibilities. This can easily go in a separate PR by the way...
I'll give it a try when I'll have some time next year and will share if something useful gets out of it...
Cheers,
Sébastien

Hi @sronveaux.
I gave it a test this morning in a larger custom app and everything works out fine.
As you pointed out, they also fixed up portfinder, so no more trouble there.
One last finding:
From looking at a template v4.5.19 app I can see that the vue versions in package.json are assigned with a ^ , so a user could possibly choose to go with vue-v2-latest. So I suggest we do the same here:
"vue": "^2.6.11"
"vue-template-compiler": "^2.6.11"

I haven`t installed vuetify in the template app, but might be the same thing. Could you check that?
Anyway I hope you had some relaxing christmas days.
A happy new year to you!

Ooops, I just discovered that the docker build is failing at npm run build stage. The node version running inside the lts-alpine image is currently 18.12.1 - see dockerhub and nodejs docker source.
For me it currently results in this build error:
#12 1.417 > vue-cli-service build
#12 1.417 #12 2.198
#12 2.199 -  Building for production...#12 3.669 Error: error:0308010C:digital envelope routines::unsupported
#12 3.669     at new Hash (node:internal/crypto/hash:71:19)
#12 3.669     at Object.createHash (node:crypto:133:10)
#12 3.669     at module.exports (/app/node_modules/webpack/lib/util/createHash.js:135:53)
#12 3.669     at NormalModule._initBuildHash (/app/node_modules/webpack/lib/NormalModule.js:417:16)
#12 3.669     at handleParseError (/app/node_modules/webpack/lib/NormalModule.js:471:10)
#12 3.669     at /app/node_modules/webpack/lib/NormalModule.js:503:5
#12 3.669     at /app/node_modules/webpack/lib/NormalModule.js:358:12
#12 3.669     at /app/node_modules/loader-runner/lib/LoaderRunner.js:373:3
#12 3.669     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
#12 3.669     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
#12 3.669     at /app/node_modules/loader-runner/lib/LoaderRunner.js:236:3
#12 3.669     at runSyncOrAsync (/app/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
#12 3.669     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
#12 3.669     at Array.<anonymous> (/app/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
#12 3.669     at Storage.finished (/app/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
#12 3.669     at /app/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9
#12 3.672 Error: error:0308010C:digital envelope routines::unsupported
#12 3.672     at new Hash (node:internal/crypto/hash:71:19)
#12 3.672     at Object.createHash (node:crypto:133:10)
#12 3.672     at module.exports (/app/node_modules/webpack/lib/util/createHash.js:135:53)
#12 3.672     at NormalModule._initBuildHash (/app/node_modules/webpack/lib/NormalModule.js:417:16)
#12 3.672     at handleParseError (/app/node_modules/webpack/lib/NormalModule.js:471:10)
#12 3.672     at /app/node_modules/webpack/lib/NormalModule.js:503:5
#12 3.672     at /app/node_modules/webpack/lib/NormalModule.js:358:12
#12 3.672     at /app/node_modules/loader-runner/lib/LoaderRunner.js:373:3
#12 3.672     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
#12 3.672     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
#12 3.672     at /app/node_modules/loader-runner/lib/LoaderRunner.js:236:3
#12 3.672     at runSyncOrAsync (/app/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
#12 3.672     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
#12 3.672     at Array.<anonymous> (/app/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
#12 3.672     at Storage.finished (/app/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
#12 3.672     at /app/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9#12 6.801 /app/node_modules/loader-runner/lib/LoaderRunner.js:114
#12 6.801 throw e;
#12 6.801 ^
#12 6.801
#12 6.801 Error: error:0308010C:digital envelope routines::unsupported
#12 6.801     at new Hash (node:internal/crypto/hash:71:19)
#12 6.801     at Object.createHash (node:crypto:133:10)
#12 6.801     at module.exports (/app/node_modules/webpack/lib/util/createHash.js:135:53)
#12 6.801     at NormalModule._initBuildHash (/app/node_modules/webpack/lib/NormalModule.js:417:16)
#12 6.801     at handleParseError (/app/node_modules/webpack/lib/NormalModule.js:471:10)
#12 6.801     at /app/node_modules/webpack/lib/NormalModule.js:503:5
#12 6.801     at /app/node_modules/webpack/lib/NormalModule.js:358:12
#12 6.801     at /app/node_modules/loader-runner/lib/LoaderRunner.js:373:3#12 6.801     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
#12 6.801     at iterateNormalLoaders (/app/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
#12 6.801     at /app/node_modules/loader-runner/lib/LoaderRunner.js:236:3
#12 6.801     at context.callback (/app/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
#12 6.801     at /app/node_modules/cache-loader/dist/index.js:147:7
#12 6.801     at /app/node_modules/graceful-fs/graceful-fs.js:61:14
#12 6.801     at FSReqCallback.oncomplete (node:fs:197:23) {
#12 6.801   opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
#12 6.801   library: 'digital envelope routines',
#12 6.801   reason: 'unsupported',
#12 6.801   code: 'ERR_OSSL_EVP_UNSUPPORTED'
#12 6.801 }
#12 6.801
#12 6.801 Node.js v18.12.1

Here is some background I found on Stack overflow.
The cause seems to be some OpenSSL security fixes in recent node versions and webpack using OpenSSL to create md4 hashes. We don`t run into this in the current Wegue master branch.
Could you have a look into that too? Maybe something along the proposed solutions e.g. using output.hashFunction = 'xxhash64'  works for us ?!

Hi @fschmenger and thanks for the review !
Christmas break was very resourcing, hope it was great for you too!  All the best for 2023 for you and your family, and to the rest of the team too!
I took the time to look at the two things you mentioned up there and here is what I arrived to:

Concerning the tagging of Vue and Vuetify versions:

You're true that the official Vue template tags Vue as ^2.6.11. I tried to install Vuetify from their latest template updated in September 2022 and there they tag Vuetify as ^2.6.0.
In fact, in current Wegue version, Vue and Vuetify are pinned to fixed versions which was not the case in the Vue V2 template. As this was a deliberate choice at a given time to do it this way I prefered to let it untouched for now...
For sure I can easily change this but it all depends how @chrismayer feels about #295. Should I change it in this PR or should it be done in #295 ?
I'm planning to get back on the upgrade to Vue-CLI V5 soon and hope to get it working flawlessly. In this potential upgrade, I'll have to upgrade Vue to 2.6.14 by the way so what I'd propose for the current PR is to go for
"vue": "~2.6.11"
"vue-template-compiler": "~2.6.11"
"vuetify": "~2.2.18"

That way it shouldn't break anything as compared to what was experienced with #295. I have the feeling there shouldn't be any problem when upgrading Vue to 2.7 but Vuetify will not be as easy...

Concerning the unsupported digital envelope routines:

Gosh I missed this one... to be honest I don't use Docker myself which explains why I missed it, however this was induced by the fact that Node 18 is now LTS and so was upgraded in those Docker images. I could easily reproduce the bug simply by upgrading Node on my computer.
As you saw, this is linked to the fact that Node is since v17 using an OpenSSL version where MD4 was removed... and this MD4 implementation was used by Webpack.
Good news is that it was fixed in Webpack5, bad news is we are here on Webpack4...
The idea of using output.hashFunction = 'xxhash64' doesn't work as simple in our case as the MD4 hash is also used by some Webpack plugins underneath. So adding this line makes the process go further but the same error fires again multiple times during the build process...
I have to mention that I tested with the update to Vue-CLI V5 (and so with Webpack5) and there the error is gone... one more reason for me to try again to finish this upgrade!
As this will be fixed if I manage to make unit tests working in Vue-CLI V5, I went on with another easier and direct fix for now. This consists in using NODE_OPTIONS=--openssl-legacy-provider inside the npm scripts involving Webpack. This reintroduces the security hole which was fixed in Node v17 but I think I shouldn't lose too much time on this for now as this will perhaps be a temporary patch before the leap to Webpack5...
Just tell me what you think about those two points and I'll amend the PR accordingly !
Cheers,
Sebastien

Hi @sronveaux,
thanks for looking into this again.
Regarding the vue/ vuetify versions you are absolutely right. I just found this when comparing the code against the template generated definitions. Since we already figured out in #295, that some of the code isn't compatible, I think you can just leave it as is. We can look into this in the process of a v5 template again. Since all of this will be part of Wegue v2 some smaller breaking changes are no biggie.
The second point is a bit unfortunate. I agree that we should rather sit on the upcoming v5 version then. If this is our best bet, then I'm fine to set the proposed  NODE_OPTIONS=--openssl-legacy-provider workaround for the time being.
Cheers,
Felix

Hi @fschmenger @chrismayer and @JakobMiksch,
I don't know if this is the best place to discuss this...
I took back my tests of upgrading Wegue to Vue-CLI V5 which was 99% done but had a bug when using Karma to run unit tests.
In fact, it was difficult to make it work when I first tried in July 2022 (had to tweak the Webpack configuration disabling some optimization for the tests to run fine) and I think that those difficulties blinded me and made me think there were other problems where in fact there weren't...
At that time, I arrived at the point where I could run the unit tests but only in single-run mode. There were some problems when running in watch mode and attaching a browser, using the debug functionality of Karma etc...
Now that I try this again with a fresh mind, I think that my lack of practice with Karma was the only problem. When you run it in watch mode and attach a headless browser + your browser and run the debug window all at the same time then make some changes in the code to make the whole process run again, you experience problems even on a simple fresh project. It seems you have to close the debug window when triggering a compile/test cycle THEN reopen it if you need afterwards...
That's why I open this discussion here and ask to all of you who certainly have more practice of Karma than me, does what I've written up here make sense, do you sometimes use Karma in watch mode and use theses debug functionalities, etc... and do you sometimes experience difficulties while doing so?
Depending on your comments and feelings, I think I can prepare the long-awaited PR to upgrade Wegue to Vue-CLI V5 which is perhaps not having problems in the end...
I just have a (real) problem left, which I discovered is in fact also present in the upgrades to Vue-CLI V3 and V4... code coverage doesn't take .vue files into account anymore, only .js files. It seems to be a known problem not that easy to solve but I'll try to arrange something here...
Thanks in advance for your comments and all the best to the team
Cheers,
Sebastien

Just a word to let you know that I resolved the coverage bug described above. So I amended the PR with this and the workaround needed to function properly with recent Node.js versions...

Hi @sronveaux,
thanks for finalizing this one! I never noticed there is a bug in the reported coverage, good job figuring this one out.
Regarding the browser debugging functionality I never tried anything with the unit tests apart from the headless single-run functionality. However I can point you to the Stepwise Debugging chapter of the readme, so I assume it is supposed to work. Maybe @chrismayer or @JakobMiksch can provide you with more information on that.
If the Karma tests is the only remaining problem, then I propose you provide the v5 version in a separate PR and we can discuss related stuff there!?
Cheers,
Felix


Resizing with options position not correct

Hello there,
I couldn't understand about resize options position. According to the document. The options.position is can be a value with two dimensions like: sharp.position: right top, right bottom, left bottom, left top or  sharp.gravity: northeast, southeast, southwest, northwest. But I'm concern that with fit mode: cover, it will preserve aspect ratio. It mean that only one dimension will be 'cut/crop' and the other doesn't.
I have a question that: Is the document about resize with option position wrong ? If not, can you show me how to resize image with correct options position?
Thank you!

@ngocbuildxuan Are you able to provide the requested information?

Closing due to inactivity but please feel free to reopen with more details if further help is required.


How does one generate human readable documentation for the API's registered through the operator-sdk

Feature Request
How do I generate documentation (either in html, or md) of the CRD API's that I create using the operator sdk?
It would be nice to see this clearly documented within the operator-sdk documentation.
Proper html documentation might look like the apis found within the  K8S documentation, for example this is the API documentation of daemonset.
Alternatively if the documentation were in a markdown (md) that would be good too. I've seen genkubedoc use this mecahnism. It uses cobra to generate markdown for core k8s applications.
It also looks like genswaggertypedocs might be related to API documentation generation. I am not sure if it is

@davesargrad We were tracking this feature upstream in controller-tools https://github.com/kubernetes-sigs/controller-tools/issues/240 although doesn't look like there's been much progress since.
There are some existing tools out there to generate the API docs from the Go type definitions although I'm not sure of the limitations if any.
This one does it in html:
https://github.com/ahmetb/gen-crd-api-reference-docs

@davesargrad For now the workaround is to use one of the existing tools like the one I linked above.
For markdown there's also the the prometheus-operator's docgen util which lets you generate markdown, although I had some issues running that when I last tried it.
https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md
But longterm we still need to follow up on the upstream issue to get this added to controller-tools. We need a proposal/POC for that first though.
In any case I'm going to close this issue since we won't be adding this feature directly to the SDK but please feel free to follow up on the upstream issue.

@hasbro17 Ty for your response.. I appreciate this much. I'll look into your suggestion.


Percona Postgres operator install mode

Hello,
in the clusterserviceversion file of the Percona Postgres Operator, the supported installMode is only OwnNamespace :
https://github.com/k8s-operatorhub/community-operators/blob/main/operators/percona-postgresql-operator/1.2.0/percona-postgresql-operator.v1.2.0.clusterserviceversion.yaml#L224
But, in the Percona Repo, it supports other modes:
https://github.com/percona/percona-postgresql-operator/blob/main/installers/olm/postgresoperator.csv.yaml#L59
Is it possible to allow all supported modes ?
Rgds.

@cap1984 FYI

Hi
We've decided to narrow the scope of possible namespace deployment options just for keeping our users safe.
Thus there is no plans to change such a behavior in the future.


Remove debezium module

The CDC extension modules from the main Jet repo completely cover the functionality that the debezium module did, so we should remove it from here.

I would leave a token readme file pointing to the cdc module:
Similar to this https://github.com/hazelcast/hazelcast-jet-contrib/tree/master/elasticsearch

Good idea Frantisek, have done so now.


KResource has address as a pointer, test it for nil

Changes

:bug: The original IsAddressable code came from Brokers, Brokers do not have address pointers or I never ran into a case where it was nil. Was getting NPE when integrating the method. This fixes those issues.

/kind bug

Fixes #

Release Note

Fix NPE on k8s.IsAddressable().

/lgtm


Support joining Discord Calls

The bot needs to be able to join Discord calls so that people streaming together can all hear the bots responses.

This requires a custom TTS client to support connecting and streaming data to two different places simultaneously. Currently joining Discord calls is not a feature of Speaker.bot. We will look into this as a possible 2.0 feature.

This is going to take a custom client app to do. Similar to the implementation of Speech-to-Text. I also need to learn the Discord Voice API, unless we can find a specialist in the community that has worked with it before. Definitely in the 2.0 conversation, or PNGTuber-GPT Pro, whatever shape it takes as we continue on the roadmap.

What kind of use case is this for? Just outputting the bot audio to the calls along with the stream?

So, how this came about, was that people who are playing games together on stream; frequently use Discord. Once they hit a certain level, they are probably using something more sophisticated, like VDO.Ninja. Some people actually send their bot and the bot audio through VDO.Ninja so that everyone can hear the bot when it talks. However, it was brought up that it would just be simpler if what the bot was saying could play on the discord call, without taking over the mic from discord from the streamer. If it could use the discord API to play directly to a bot account on the call; this would be better. However, the practicality of implementing that has seen this get slightly back burnered over some other more critical features.

It was also brought up that once this was implemented, it could be further enhanced by other features in development, like speech-to-text, to actually have the bot listen to discord and take commands from the users in it. There are definitely solid use cases; but it hasn't seen such strong support, and it hasn't had priority for development yet.

I haven't heard of VDO.ninja before, but it seems really neat. If I'm following right, the goal is to create a separate bot user to join a discord call for playing bot audio, because using something like VDO.ninja feels a bit extra, and to play it in Discord currently requires changing the input device in Discord to the bot's virtual cable, so the user and the bot can't both be talking at once (and doesn't sound very efficient at all anyway)
I wish I had any knowledge on discord's API to contribute, but I think a workable solution for having the bot output in a Discord call would be to set up VB-Audio VoiceMeeter. You can set up input from the user's microphone for one source, the bot's VB-Audio cable for the second source, set the output to whatever the primary output is, mute the physical microphone's A channel so there's no echo, and finally change the mic in Discord to the VoiceMeeter output. This also makes it so there's no need to set up the "monitor output" in OBS's advanced audio properties either, because it will play through VoiceMeeter.

You're following correctly, for sure. For most folks here, Virtual Audio Cable is probably their first exposure to this kind of thing with audio routing. I do agree with your solution, it just takes a bit a know-how. Also, some of the streamers already use VoiceMeeter somewhere in their tool chain, so it adds more complication to then use it for Discord too. I'm honestly not all that familiar with it, other than being an audio bus tool for routing inputs and outputs. I just know it had come up in conversations as well. I don't have enough knowledge at this point to have a workable solution with Discord either, but this is here to kind of track it, so I don't forget to look into it further.


[Bug] Fix the unstable testRollbackToTagWithChangelogDecoupled

Purpose
if the commit times is 5, the changelog-1 is not expired may lead to unexpected file left.
such as
https://github.com/Aitozi/incubator-paimon/actions/runs/8590046982/job/23537660465

Tests

API and Format

Documentation

+1


Click on the canvas blank area to trigger mackdown to rearrange and calculate styles

What platform were you using when you found the bug?

React Flow / Svelte Flow version: 11.10.4
Browser and version: 126.0.6478.183 (arm64)
OS and version: Apple M1 Pro

Live code example
No response
Describe the Bug

In my program, I use reactfl to render the code text. If I click on the blank area of the canvas, my react component will not be re rendered at all, but it will become too laggy if I start the Recalculate Style of the text markdown
Steps to reproduce the bug or issue

go to https://flowith.io/
Create multiple elements within the canvas, which contain a lot of code
Click on the blank area of the canvas

Expected behavior
When clicking on the blank area of the canvas, it should be given the same as sliding, without triggering the Recalculate Style of the element
Screenshots or Videos
https://github.com/user-attachments/assets/6bdf6957-4ed1-428d-b2dd-74761f42aae2
Additional context
I am certain that my React component has not been re rendered

Recalculate style is triggered whenever you change any kind of style - in this case the transform of the viewport changes. Just to clarify, this is not a reflow, but recalculate style.

Re-rendering nodes should not happen if you just click the canvas. Are your custom nodes wrapped with memo?
Do you have any chance to check if this issue also occurs for you with v12?


[Feature]: Add aerosol burden to lat-lon and other core sets

Is your feature request related to a problem?
Global mean aerosol burden is included in the aerosol budget table. To add 2D aerosol burden in lat-lon sets would allow showing the global distribution as well as global metrics. It can also serve as back up if the aerosol budget table is not available.
Describe the solution you'd like
Including aerosol burden in standard lat-lon sets, and compare with obs/reanalysis if available.
Describe alternatives you've considered
No response
Additional context
No response

Your plan sounds great! Thank you.


Show Pagination (optionally)

Add config option to show pagination too (maybe for jumping directly to some other page)

Nobody has asked for this feature yet. Closing until this comes up again.


[FEATURE]-Add a GenericQueue class

Is your feature request related to a problem? Please describe.
Add a generic, threadsafe queue class similar to the specific implementation in the MC plugin.
Duplicated issue from Core

see #398


Register v0.1.0

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/38892
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 5c9155efe96f93284b86420daaf5e17f65f96343
git push origin v0.1.0


Xamarin.Forms - Crashlytics  is not logging crashes [Crashlytics 4.6.2]

Hi! I'm using Crashlytics v4.6.2 for my Xamarin.Forms app. Though the crash count is increasing but still no error message/stack trace is logged in the Firebase Console. I tried in release device build as well.
I get the following logs which makes me think that something else is interfering, but though I tried, I couldn't find what is interfering with Crashlytics (if I've perceived it correctly) :
[Crashlytics] The signal SIGABRT has a non-Crashlytics handler (sigabrt_signal_handler).  This will interfere with reporting.

[Crashlytics] The signal SIGBUS has a non-Crashlytics handler (mono_sigsegv_signal_handler).  This will interfere with reporting.

[Crashlytics] The signal SIGFPE has a non-Crashlytics handler (mono_sigfpe_signal_handler).  This will interfere with reporting.

[Crashlytics] The signal SIGILL has a non-Crashlytics handler (<redacted>).  This will interfere with reporting.

[Crashlytics] The signal SIGSEGV has a non-Crashlytics handler (mono_sigsegv_signal_handler).  This will interfere with reporting.

[Crashlytics] The signal SIGSYS has a non-Crashlytics handler (mono_crashing_signal_handler).  This will interfere with reporting.
[Crashlytics] The signal SIGTRAP has a non-Crashlytics handler ((null)).  This will interfere with reporting.

I even get symbols uploaded successfully in the logs during build process in Visual Studio.
What I've tried
Tried uninstalling App Center Analytics. [I'm not using App Center Crashlytics)
Other Analytics SDKs I'm using
Google Analytics
Firebase Analytics

I didn't have this problem before upgrade
Earlier Crashlytics version I was using : 3.14.0

I'm experiencing the same problem 😬

@sebastiansondergaard, was this issue fixed for you? I'm trying for a solution still..

Thank you JESUS..!! This issue is resolved.
Don't know why.. After uninstalling CarouselView.FormsPlugin package, the logs went off. Crashes are now reported properly
Maybe some error handling is being done in the CarouselView.FormsPlugin package.

While testing each crash, I only got this CarouselView.FormsPlugin named exception being reported in the Firebase console. In that way, I identified that this package is interfering with the Crashlytics reporting as displayed in the logs

Hi @PaulsonMac , nice to hear that removing a package has made it work !
However, I don't understand how were you able to see named exceptions in the Firebase Console.
In my case, I still have "missing DSYM files" displayed :/
Did you have this message ?

Hi @Kapusch! I too still have the "missing DSYM files" displayed. But, after everytime I crashed the app, when I checked the console I could see the crash count increasing in my case and the stack trace was always about the same CarouselView exception increasing in count in the Crashlytics dashboard.

Would that mean that even if we have DSYM files are missing, it is not relative to an actual crash ?

I think "No". Even the message says "Upload x missing dSYM required to process n crashes".
In my case, after I crashed the app, when I checked in the dSYMs tab, there was no new entry in the "Missing dSYMs" section of the dSYMs tab. In this scenario, obviously DSYM files are not related to the actual crash

I have a question : There is not even a single crash logged in your Crashlytics dashboard ?

From time to time yes, I can see a problem is reported in the Crashlytics dashboard, however, I still have several missing dSYM files; even for my last release :/

@PaulsonMac We also get no crash reports even though we use the current version.

@PaulsonMac We also get no crash reports even though we use the current version.


Our macOS os_unfair_lock does not match platform behavior when the lock is moved

In https://github.com/rust-lang/miri/pull/3745, the question came up what to do when a os_unfair_lock is moved. Apparently the real implementation uses the address of the lock to identify the wait queue, so a moved lock will be a "fork" of the old lock: it will start in whatever state the lock had at the time of the move, but reset the wait queue.
In Miri, we use a mutex ID tracked in the os_unfair_lock value to identify the lock, so the wait queue moves with the lock.
I don't think it makes sense to exactly replicate the macOS behavior here, but it would make sense to detect when a lock is moved, and throw an "unsupported" error.  This could work similar to what https://github.com/rust-lang/miri/pull/3784 does for pthread mutexes.

Behavior changed a bit with https://github.com/rust-lang/miri/pull/3966: the queue no longer moves with the lock.
However, we should probably do something to detect a lock that is moved while being locked -- that seems like a rather dubious thing to do. The best way to do this probably is to store something non-zero in the lock whenever it is held, and to refuse initializing a new lock in os_unfair_lock_getid when the value is non-zero.


[MULI-23] Language Support for Russian

User Story
I as a user
Want to use the app in Russian
So that I can enter the Russian market with my product
Acceptance Criteria
Scenario 1: Changing the Application Text to Russian
GIVEN a user has started the app
AND the app is in English
WHEN navigating to the settings
AND navigating to "language"
AND navigating to "Russian"
THEN all texts in the app are in Russian (except for the user entered input)
Scenario 2: Changing the Application Text to English
GIVEN a user has started the app
AND the app is in Russian
WHEN navigating to the settings
AND navigating to "language"
AND navigating to "English"
THEN all texts in the app are in English (except for the user entered input)
Technical Specification

[ ] per default the app is in english
[ ] the solution should be extendable to work with further developments
check: https://developer.android.com/training/basics/supporting-devices/languages

Texts Translations
Games = Игры
Statistics = Статистика
History = История
Tips = Подсказки
Options = Опции
This is xxx Fragment = Это ххх фрагмент
Start New Game = Начать новую Игру
Enter Player Names = Впиши имена игроков
Player <> = Игрок <>
Heart Round = Раунд Черви
Underdog = Проигравший
End Game = Конец игры
Create User = Создай пользователя
Please Enter Your Username = Пожалуйста, введите ваш ник пользователя
Mockups
Mockup of the options menu:

Mockup of the language chooser:

Options = Настройки, Enter Player Names = Введите имена игроков, Create User = Создать пользователя, Please Enter Your Username = Пожалуйста, введите Ваше имя пользователя

another link which the team wanted to share: https://protocoderspoint.com/how-to-change-whole-app-language-in-android-programmatically/#Step_2_-_Create_a_new_stringsxml_with_locale


Multiple tweaks and fixes

This PR fixes and tweaks multiple found issues:

Adds alt text to images and logos that are used as links, for better screen reading of link. Although, the texts aren't the best as alt text, and could be something to review in the future.
Tweaks the icon width of links in the video pages, hopefully resolving #215
Tweaks text color in Tabs component (present in video pages) to be colored when normal, and black when selected.
Adds ability for Tags component to have different types of headings, so that they fit appropriately in the headings order of the page, improving page structure.
Fixes a couple of instances where <ul> elements don't have direct <li> children.
Replaces a character separator in about page that presented node depth issues.
Fixes little react list rendering found in guides page.

This also resolves and fixes #121, and the pending points listed in them.

Looks good!


Add svelte/attributes-line-break

Motivation
There are currently 2 existing rules that helps formatting attributes line break:

"svelte/first-attribute-linebreak"
"svelte/max-attributes-per-line"

The problem with them is that there is no way to consider the line length to enforce proper style.
Description
"svelte/attributes-line-break": ["error", { printWidth: 90 }]
Examples
<script>
</script>

<!-- ✓ GOOD -->

<!-- 41 characters -->
<MyComponent attr1="test" attr2="test" />

<!-- 99 characters -->
<MyComponent
  attr1="test"
  attr2="test"
  attr3="some very long text that takes spaces and many..."
/>

<!-- ✗ BAD -->

<!-- 41 characters -->
<MyComponent
  attr1="test"
  attr2="test"
/>

<!-- 99 characters -->
<MyComponent  attr1="test"  attr2="test"  attr3="some very long text that takes spaces and many..."/>

Additional comments
These are only examples, I am not very much opiniated on the rule name or customization as long as it can give the proper result in the end.
Right now Prettier is able to enforce this style correctly, however Prettier is very opiniated and doesn't offer much customization and i would like to get rid of it.

Thank you for the rule suggestion.
I'm interested in that rule, but I think it conflicts with svelte/max-attributes-per-line.
Could you please consider changing the rule so that it doesn't conflict, or consider deprecating svelte/max-attributes-per-line and creating a new rule that includes the use case of svelte/max-attributes-per-line?
https://sveltejs.github.io/eslint-plugin-svelte/rules/max-attributes-per-line/

Thank you for the rule suggestion. I'm interested in that rule, but I think it conflicts with svelte/max-attributes-per-line. Could you please consider changing the rule so that it doesn't conflict, or consider deprecating svelte/max-attributes-per-line and creating a new rule that includes the use case of svelte/max-attributes-per-line?
https://sveltejs.github.io/eslint-plugin-svelte/rules/max-attributes-per-line/

Indeed I'm open to all this. I currently have these 2 rules disabled in favor of Prettier for the time being until anyone implement this suggestion :)
Do you have a proposal? I could edit the top post


Support 6-pin Joystick

Hi There,
Great project! I have the PCB and ESP32 setup, but I just realised my analogue stick is a 6-pin version, not the 4pin like the board has been designed. From what I can tell the 6-pin is the standard type.
This pinout is like this https://dpedu.io/article/2015-03-11/nintendo-64-joystick-pinout-arduino
Im looking at how to modify the code to support but do you have any ideas about where to start?
get_analog_raw looks promising but not sure how to bring the other pin into it..
Thanks

Interesting. All of the USB controllers I've seen had 4-pin joystick cables. Does your controller have an N64 plug instead of USB? And is it an original controller or a repro?
If it is a repro, it might still use a 2-axis potentiometer which you can easily convert to 4-pin. Later this week I can try to dig up some pictures of a 6-pin to 4-pin "conversion" I did for a potentiometer based joystick.

Ah, that might be it, I am looking to convert my original OEM N64 controllers, everything else looks the same apart from the joystick. Looking to save some controllers from landfill:)
After a bit of research, the OEM 6pin sticks use two linear sensors and are not true analog as with the repro ones in the USB controllers.:
_The analog stick uses a pair of optical encoding disks to determine its relative position. This works similarly to linear encoders found in printers, except that instead of being a strip of tape/film, the N64 uses a rotating disk for each axis. Each disk has small holes along the circumference of the disk. These holes allow light to pass through to an optical sensor on the opposite side.
When the stick is moved, there are two signals generated per axis, for a total of four, which are slightly offset from each other. One of the two signals is used as the interrupt signal (XA and YA for the x-axis and y-axis respectively), and the other (XB and YB) is compared with the state of the first in order to determine which direction (positive or negative) that analog stick is moving for that axis.
To determine the direction along a particular axis and how far the stick has moved, the NUS-CNT chip will listen for any changing edge of that axis' interrupt signal (e.g. XA for the x-axis). A changing edge means any time the signal goes from LOW to HIGH, or HIGH to LOW. When an edge change is detected, the state of XA is compared against XB. If input, then the stick has moved +1 units. If input, then the stick has moved -1 units. While the analog stick reports relative movement whenever it moves, the N64 console requires the current position, not relative. In order to provide that, the NUS-CNT chip keeps track of these movements. The initial values for each axis is zero._
I am thinking something like this, y axis only here for an example (would duplicate for x axis):
int16_t county = 0;

int16_t analogy_to_combined_value() {
    int16_t rawa = gpio_get_level(ANALOG_Y);
    int16_t rawb = gpio_get_level(ANALOG_Yb);
  if(rawa == rawb) {
    county++;
  }
  else{
    county--;
  }
  int32_t yaxis = (county * 365); //scale by factor of 365 as n64 sensors range from -90 -> +90
  return (analog_to_joystick_value(yaxis, min_y, center_y, max_y))
}

This will replace the get_analog_raw function when polling for the joystick. Not sure how this will interact with analog_to_joystick_value map functions..
Any thoughts on this so far, love to get your advice on this?

I'll have to read up a bit more, but two things come to mind so far:

You're going to need 4 sensor pins from the ESP32, not just the two that are already dedicated to the joystick. And you'll need to connect these somehow since the PCB only has two traces for the joystick signals

Or you could add hardware to convert the encoder signal into analog signals for the ESP32, but this doesn't seem worth it in my opinion

Seems like you will need to use interrupts to detect XA and YA changes instead of monitoring this in the poll loop

Thanks! I have a test project working with interrupts and the additional Pins (13,35) via the PCB :)
I will take a look at embedding this into the project on my fork, making it optional, 4-pin or 6-pin.

First cut is on branch here:
https://github.com/craigmillard86/wireless-n64-controller/tree/6pin-n64

Very cool! Glad you were able to make this work!
This seems like a great feature to add back to this repo if you want to send a Pull Request 😁 That might take a little more work but hopefully it's not too bad (e.g. to update or disable calibration)

I have updated it to include Calibration, which required a refactor but all good now!
I have raised a PR here let me know your thoughts

Thank you! I will try to take a look and try this out this weekend

Support for 6-pin style joysticks was added in https://github.com/sfraint/wireless-n64-controller/pull/9
Thanks again @craigmillard86!


#2343 - Remove JUnit version from project generated by archetype

the JUnit version is already managed by the BOM
Signed-off-by: Aurélien Pupier<EMAIL_ADDRESS>

I have an extremely flaky internet connection today so I'll continue our discussion here....
We should be able to take this further and remove version properties:
<version.wildfly.arquillian>
<version.apache.camel>
<version.jboss.arquillian>

Dependencies related to these should already be inherited from the BOM import.
Please can you also follow the project commit convention [resolves #issue number] Some comment.

Please can you also follow the project commit convention [resolves #issue number] Some comment.

I updated it

We should be able to take this further and remove version properties:
<version.wildfly.arquillian>
<version.apache.camel>
<version.jboss.arquillian>

effectively it seems to be working when i remove them.
I will provide an additional commit to get rid of them

Thanks!
Do you mind squashing up those commits. This project is a little quirky in that the build does the merge instead of the GitHub merge button. So it needs things pre-squashed.

ok to test

retest this please


gravatarHash seems not to work anymore

Using the latest hugo 0.18 seems to have broken the gravatar image since it will not be generated.

Encountered the same. Fix was to change layouts/partials/sidebar.html from
{{ if isset .Site.Params "gravatarHash" }}

to
{{ if isset .Site.Params "gravatarhash" }}

python code to get hash5


Migrate Spanish Ask to English templates

Moves Spanish Ask content into shared templates with English Ask.
Additions

Translations in django.po for hard-coded content in templates that will now be used on Spanish pages
Script to migrate formatted first paragraphs into short answer field on Spanish answer pages
Spanish mega menu vars file
Spanish logo images

Removals

Spanish Ask templates
Spanish answer page print view
Virtual pageview event for Ask answer pages
Customization of Ask breadcrumbs based on referrer

Changes

Update English Ask templates to also work for Spanish content
Update Ask page models to use a single shared template for English and Spanish
Update header / footer templates to create a Spanish version that will be applied to all pages whose language is set to Spanish in Wagtail

Testing

Check out branch & run python cfgov/manage.py runscript migrate_spanish_short_answers
Navigate to Spanish Ask landing page, Spanish Ask category page, and Spanish Ask answer page and

verify that they display/function like their English counterparts but with a Spanish header & footer
verify that first paragraph on answer page displays as larger text

Navigate to a non-Ask Spanish page and verify that it also displays the Spanish header/footer

Screenshots
Spanish answer page

@virginiacc This looks great! Thank you for taking this on.
I'm wondering if it's possible to add a few tests that check that the translations are working as expected?  Not so much to test that Django utilities work, since we would expect those to, but to check everything is configured correctly.  Of course this wouldn't catch a spacing or syntax issue in a particular line but might still be nice to have in place.  I'm imagining a test or two that renders a particular page that uses translations (seems like most pages would suffice due to the translated headers/footers), and checks for the correct Spanish translation in it -- but also open to other ways to do this or if anyone thinks it's a bad idea. Also happy to pair on this.  Apologies if this was already added and I overlooked it in the diff.

Thanks for the testing suggestion, @richaagarwal! I added a couple of tests in https://github.com/cfpb/cfgov-refresh/pull/4943/commits/234ada30409f52ed3b496aa16c30c1bf49db9a1c to verify that translated header/footer content is displayed correctly based on page language.


settings iobroker mqtt

hi,
i use the adapter in iobroker with mqtt.
I see all roller shutter and the values change when they are used but when you change the direction manually in the iobroker, the roller shutters do not move.
Send values is activated.
What can I do, where is the mistake?
Thank you!

The direction change is done through the set topic.  So the full path for the current direction value is
<root topic>/shades/<shade id>/direction  and the full path to set the direction is <root topic>/shades/<shade id>/direction/set

command

.../target/set 0
.../target/set 100

work well

.../directon/set 0
.../directon/set 1
.../directon/set -1

did not work

auf SomfyHelga/shades/1/target/set 0
zu SomfyHelga/shades/1/target/set 100
MY SomfyHelga/shades/1/directon/set 0
AU SomfyHelga/shades/1/directon/set 1
ZUF SomfyHelga/shades/1/directon/set -1`

10:05:58.507
SENT
SomfyHelga/shade
0

10:06:02.963
SENT
SomfyHelga/shades/1/directon/set
0

10:06:11.460
SENT
SomfyHelga/shades/1/target/set
100

10:06:11.874
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:06:11.917
client_00001066954ece8c
SomfyHelga/shades/1/position
0

10:06:11.934
client_00001066954ece8c
SomfyHelga/shades/1/direction
1

10:06:11.959
client_00001066954ece8c
SomfyHelga/shades/1/target
100

10:06:11.984
client_00001066954ece8c
SomfyHelga/shades/1/remoteAddress
970381

10:06:12.001
client_00001066954ece8c
SomfyHelga/shades/1/lastRollingCode
95

10:06:12.026
client_00001066954ece8c
SomfyHelga/shades/1/mypos
-1

10:06:12.043
client_00001066954ece8c
SomfyHelga/shades/1/tiltType
0

10:06:12.060
client_00001066954ece8c
SomfyHelga/shades/1/sunFlag
0

10:06:12.077
client_00001066954ece8c
SomfyHelga/shades/1/sunny
0

10:06:12.094
client_00001066954ece8c
SomfyHelga/shades/1/windy
0

10:06:12.353
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:06:12.372
client_00001066954ece8c
SomfyHelga/shades/1/position
1

10:06:12.405
client_00001066954ece8c
SomfyHelga/shades/1/direction
1

10:06:12.422
client_00001066954ece8c
SomfyHelga/shades/1/target
100

10:06:12.439
client_00001066954ece8c
SomfyHelga/shades/1/remoteAddress
970381

10:06:12.456
client_00001066954ece8c
SomfyHelga/shades/1/lastRollingCode
95

10:06:12.473
client_00001066954ece8c
SomfyHelga/shades/1/mypos
-1

10:06:12.490
client_00001066954ece8c
SomfyHelga/shades/1/tiltType
0

10:06:12.507
client_00001066954ece8c
SomfyHelga/shades/1/sunFlag
0

10:06:12.523
client_00001066954ece8c
SomfyHelga/shades/1/sunny
0

10:06:12.540
client_00001066954ece8c
SomfyHelga/shades/1/windy
0

10:06:12.834
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:06:12.853
client_00001066954ece8c
SomfyHelga/shades/1/position
2

10:06:12.885
client_00001066954ece8c
SomfyHelga/shades/1/direction
1

10:06:12.902
client_00001066954ece8c
SomfyHelga/shades/1/target
100

10:06:12.919
client_00001066954ece8c
SomfyHelga/shades/1/remoteAddress
970381

10:06:12.936
client_00001066954ece8c
SomfyHelga/shades/1/lastRollingCode
95

10:06:12.953
client_00001066954ece8c
SomfyHelga/shades/1/mypos
-1

10:06:12.970
client_00001066954ece8c
SomfyHelga/shades/1/tiltType
0

10:06:12.987
client_00001066954ece8c
SomfyHelga/shades/1/sunFlag
0

10:06:13.004
client_00001066954ece8c
SomfyHelga/shades/1/sunny
0

10:06:13.021
client_00001066954ece8c
SomfyHelga/shades/1/windy
0

10:06:13.314
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:06:13.333
client_00001066954ece8c
SomfyHelga/shades/1/position
3

10:06:13.366
client_00001066954ece8c
SomfyHelga/shades/1/direction
1

10:06:13.383
client_00001066954ece8c
SomfyHelga/shades/1/target
100

10:06:13.400
client_00001066954ece8c
SomfyHelga/shades/1/remoteAddress
970381

10:06:13.417
client_00001066954ece8c
SomfyHelga/shades/1/lastRollingCode
95

10:06:13.434
client_00001066954ece8c
SomfyHelga/shades/1/mypos
-1

10:06:13.451
client_00001066954ece8c
SomfyHelga/shades/1/tiltType
0

10:06:13.468
client_00001066954ece8c
SomfyHelga/shades/1/sunFlag
0

10:06:13.485
client_00001066954ece8c
SomfyHelga/shades/1/sunny
0

10:06:13.502
client_00001066954ece8c
SomfyHelga/shades/1/windy
0

10:06:13.882
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:06:13.901
client_00001066954ece8c
SomfyHelga/shades/1/position
3

10:06:13.918
client_00001066954ece8c
SomfyHelga/shades/1/direction
0

10:06:13.944
client_00001066954ece8c
SomfyHelga/shades/1/target
3

10:06:13.969
client_00001066954ece8c
SomfyHelga/shades/1/remoteAddress
970381

10:06:13.986
client_00001066954ece8c
SomfyHelga/shades/1/lastRollingCode
96

10:06:14.011
client_00001066954ece8c
SomfyHelga/shades/1/mypos
-1

10:06:14.028
client_00001066954ece8c
SomfyHelga/shades/1/tiltType
0

10:06:14.045
client_00001066954ece8c
SomfyHelga/shades/1/sunFlag
0

10:06:14.061
client_00001066954ece8c
SomfyHelga/shades/1/sunny
0

10:06:14.078
client_00001066954ece8c
SomfyHelga/shades/1/windy
0

...

10:08:26.740
SENT
SomfyHelga/shades/1/target/set
0

10:08:27.152
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:08:27.171
client_00001066954ece8c
SomfyHelga/shades/1/position
20

10:08:27.189
client_00001066954ece8c
SomfyHelga/shades/1/direction
-1

10:08:27.214
client_00001066954ece8c
SomfyHelga/shades/1/target
0

10:08:27.239
client_00001066954ece8c
SomfyHelga/shades/1/remoteAddress
970381

10:08:27.256
client_00001066954ece8c
SomfyHelga/shades/1/lastRollingCode
98

10:08:27.281
client_00001066954ece8c
SomfyHelga/shades/1/mypos
-1

10:08:27.298
client_00001066954ece8c
SomfyHelga/shades/1/tiltType
0

10:08:27.315
client_00001066954ece8c
SomfyHelga/shades/1/sunFlag
0

10:08:27.332
client_00001066954ece8c
SomfyHelga/shades/1/sunny
0

10:08:27.349
client_00001066954ece8c
SomfyHelga/shades/1/windy
0

10:08:27.509
client_00001066954ece8c
SomfyHelga/shades/1/shadeType
3

10:08:27.528
client_00001066954ece8c
SomfyHelga/shades/1/position
19

10:08:27.561
client_00001066954ece8c
SomfyHelga/shades/1/direction
-1

10:08:27.578
client_00001066954ece8c
SomfyHelga/shades/1/target
0

I'm sorry I do not understand what works and what doesn't from your post.  Are you saying .../target/set works but .../direction/set does not?

Yes hat is the problem.
SomfyHelga/shades/1/target/set 0 works
SomfyHelga/shades/1/direction -1 not
SomfyHelga/shades/1/direction/set -1 must bei right.
I will give it a try today - sorry, i am already learning

Do you use iobroker?
The negative value must be set separately in the settings!

I am using MQTT2_Server of fhem.
If my broker send
SomfyHelga/shades/1/target/set 100 - awning ist driving down
SomfyHelga/shades/1/target/set 0 - awning ist driving up
My problem is if i want to stop this device sending
SomfyHelga/shades/1/direction/set 0 - does not work
If i press MY on WEB-Interface ist stops immediately
SomfyHelga/shades/1/direction/set 1 - does not work
SomfyHelga/shades/1/direction/set -1 - does not work
That is the reason i am thinking there ist something wrong with command direction

can you limit the values (-1, 0 , 1) in the data point as possible choices?
I had to set this in iobroker mqtt, only then did the roller shutters move...

in MQTT.cpp i find this
line 107 single shade - else if

line 133 group shade - if

could this be the problem?

I use MQTT explorer with a mosquitto instance and it all works perfectly.  Bear in mind ESPSomfy RTS never publishes to a set leaf.  It only subscribes to it.  And if you publish a value to its descendant you will get no response.  In fact that response will be overwritten on the next go around.
The above code is correct.  Is it possible to look at your broker in MQTT explorer to see what is actually being written to the leaf?

I use MQTT2_Server - MQTT explorer show

That is very odd that in MQTT explorer I am not seeing values on your parent leaf.  It is like something is publishing null to them.  Notice my MQTT explorer below.  Here are the differences.

The intermediate nodes have values but something has cleared these. for instance the topic ../shades has index values that are set at startup to allow you to enumerate all the shade ids in the subsequent topic.  These may not always be 1,2,3,4 ... Since motors can be deleted out of the middle.
You are publishing the set command to a misspelled topic.  You are publishing SomfyHelga/shades/1/directon/set when you should be publishing to SomfyHelga/shades/1/direction/set I suspect this is your problem.  You forgot the i in direction.

Sorry, making trouble.
I will try on monday

No worries sometimes it takes another eye to catch things like that.

installed 2.1.1 and tried direction worked perfect.

I am going to close this for now.  Let me know if you have other issues.


[dashboard] page title does not change back after navigating away from dashboard

Expected results
When navigating away from a dashboard the page title change back to "Superset"
Actual results
The page title is still the dashboard's title
Screenshots

How to reproduce the bug

view a dashboard, eg "World Bank's Data"
notice title of the page/tab/document is the name of the dashboard, eg "World Bank's Data"
navigate away via the menu, eg Data > Databases
notice the title of the page/tab/document is still the title of the dashboard, eg "World Bank's Data"

Environment

superset version: master
python version: 3.7.5
node.js version: 14
any feature flags active: None

Additional context
Very minor issue, likely happened when we move the dashboard "app" into the SPA bundle.

i didn't notice before. 🤦🏾♀ tyty @nytai 🙏
@geido slightly higher priority 🙏


bookstore: fix test suite equality checks

Closes #416.
Example implementation was updated to match the xcsharp implementation.
I also ran the classes through my formatter to make them more consistent with other files in the repo.

Comparison view ignoring whitespace-only changes: https://github.com/exercism/xjava/pull/422/files?w=1