Push Notifications on Android 13 and higher devices

We are following versions
Cordova android - 12.0.1
GradlePluginGoogleServicesVersion - 4.4.0
android-targetSdkVersion - 33
cordova-plugin-firebase-messaging - 5.0.1
Issue Facing
Push notification is working in foreground and background until android 12.
From android 13 and higher we are receiving push notification only for the 1st time when the app is in foreground.
We are not receiving notification once we close/ minimize/ in background , the app basically stops receiving the notification once app moves to background.
We are using Firebase Cloud Messaging token based authentication via AWS SNS service.
As per AWS SNS service the message pushed successfully but not getting notified.
We have enabled the allow notification permission in device for the respective app.
This issue is a showstopper for us , could you kindly guide us to address this issue.

Hi, Is there any update on this ticket?


Fix: No support for newest version of EventFlow

Implemented new version of IReadModelStore
This Fixes #17

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Shane Padellaro seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@rasmus Would you mind having a look?

@ShanePadellaro Sorry for the delay, I'm currently travelling with work. I'll have  a look

@rasmus no worries, Cheers mate!


Fix awesome.load_surface() in various ways

This fixes #518 and details are in the individual commits.
I wonder if it makes sense to add an unit test for this. Such a test would prepare a pixbuf with some specific content, call this function and then do some assertions on the contents of the returned ImageSurface. However, such a test would be relatively verbose, I fear.... Do you want me to write one?
On the various casts that this adds:

channels is either 3 or 4, so safe to cast to usize
The code in GdkPixbuf ensures that width/height are positive numbers (even though the interface uses signed integers for them...), so casting them to usize is okay (as long as usize is larger than i32, which I am fine with assuming)
The rest of the added casts are bugfixes, so ought to be fine. :-)

I wonder if it makes sense to add an unit test for this. Such a test would prepare a pixbuf with some specific content, call this function and then do some assertions on the contents of the returned ImageSurface. However, such a test would be relatively verbose, I fear.... Do you want me to write one?

Once this works it works, so I see no need to write a unit test.
Looks great though, thanks!


[android] Share to Zulip from other apps [part 2]

Fixes: #117
Continuation of work done in #4514
The previous PR thread was getting too long, so as suggested by @gnprice It is now broken into two parts.
To see the screen capture of the demonstration of this feature checkout #4514.
Reviews on that thread by @chrisbobbe: https://github.com/zulip/zulip-mobile/pull/4514#pullrequestreview-632774278
Reviews on that thread by @gnprice: https://github.com/zulip/zulip-mobile/pull/4514#pullrequestreview-645458694
Note that the specific commit that fixes #117 is present in this PR and not #4514.

@gnprice I've made the revision you asked, and did a bit more.

I've done as much of deduplication as possible between ShareToStream and ShareToPm.
I've moved 1 commit about displaying file name under content preview, earlier than the previous revision.
I've noticed that getFileName and getType has the potential to return null, this will take place only when provided with an invalid url and here I am essentially falling back to displaying unknown.bin file in such a case.
Then there is 1 concern that I will make an inline comment for.

Partway through reviewing, but dinnertime here :slightly_smiling_face:

@gnprice made the changes, you may see them.

Thanks for the fast revision! Reading now.
One thought I meant to put in the overall review comment for yesterday's review (but then didn't think of when I was submitting the partly-done review):
The second commit here, the one deduplicating the sharing code into the new SharingWrapper, has kind of a lot of things going on. Typically I'd ask for a commit like that to be broken up into smaller pieces, because that makes it easier to read all the changes closely and really verify they're not changing anything, or changing only things we intend to change.

For example, one commit could make SharingWrapper and give it a handleSend that still looks like the handleSend on the two old components, and then a later commit does the part where the separate handleSend helper function gets inlined into that.

When I'm doing a refactor myself, I'll generally write it more or less that way in the first place. I find that helps a lot for being pretty sure I'm changing on the things I intend to change -- and especially for doing large or complex refactors.

The frequent git commit -am 'wip add WidgetFrobber' is easy, and often very helpful even just for writing the code. I think I would do that even if I were ultimately going to squash everything into one commit.
The git rebase -i takes some effort, though it gets faster with practice. We do this for the sake of people reading the changes.

But... the existing code isn't live code that people are using, so it's not like we have a presumption that it currently works despite being tangly. So it's actually OK if the behavior changes, as long as we think the new behavior is fine. It's not even important (like it usually would be) that we understand what the old behavior was and why it was that way.
So I have some questions where I do notice what look like changes. But in this case I won't ask you to do the work to split the commit up into smaller pieces; and for those changes, it's fine for the answer to be that you tested that aspect of the new behavior and it seems good.

OK, finished re-reviewing the parts you just revised! (Including a couple of replies in the threads above.) That covers the first 6 commits:
af4e9a9e9 translation: Add some english words used in sharing screen.
91ef4651e sharing [nfc]: Deduplicate code b/w Pm and Stream sharing screens.
beb81e748 sharing [nfc]: Write type of sendTo more aptly.
1c8a52696 sharing [nfc]: Move helper kotlin code to a new file.
f8f2c150a sharing: Make the app not quit after share to zulip concludes.
ba0c1e4fa sharing [nfc]: Add doc about synchronising native and js data type.
There are a few small things left to fix; I think we're quite close to merging those.
Next I'll take a look at the next few commits, corresponding to the remaining commits I reviewed the first time and that you revised this week.

@gnprice done resolving, you can check. I will also make the PR for Multiple Share and link it here.
I see from this review that I should focus on splitting up my commits some more, and I will keep that in mind. One reason for doing this is that I do not notice this sometimes (which I will try to improve upon) but also that my thought process was that associated code should change together to convey the meaning of why we did that change in the first place; moreover sometimes (less frequently though) it can lead to doing extra changes to accommodate the changes introduced in the prep commit that will be changed in the next commit regardless, which feels unnecessary.
But I understand your point that this increases the chances of us catching side effects we may have from this prep code and it makes for a better code review experience so I will try to do this as much as possible. Thanks!

Thanks for the revision! All looks good, except that it looks like send.js got revived in this one (i.e. it's no longer deleted in the deduplication commit.) I'll fix that and merge.

my thought process was that associated code should change together to convey the meaning of why we did that change in the first place

I started writing some thoughts in reply to this, and then realized it'd be better as a chat thread :slightly_smiling_face: So I'll do that.


[CT-1361] dbt CLI preview command

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Be able to run dbt preview my_dbt_model  to show the results of the model in the terminal similar to the preview functionality in dbt cloud.
Describe alternatives you've considered
No response
Who will this benefit?
dbters who live in the CLI. Being able to preview the results of a model before it materializes in the database can be helpful to see if the output matches the user's expected behavior.
Are you interested in contributing this feature?
Yes, working on it for the hackathon project
Anything else?
I have a GitHub discussion open about this feature request.

hi @TylerHillery, thanks for opening this and working on it at the Coalesce hackathon! I wanted to let you (and anyone else reading) know that we're very interested in adding this new CLI command, but we won't be proceeding with the PR from the hackathon. the primary reason for this is that for v1.4 we're refactoring our internal Python APIs, notably reworking the CLI into a new framework -- so we'd need to merge this and then completely redo it anyway
if you or anyone is interested in contributing this once we have a bit more concrete next steps from the CLI rework, let us know! otherwise it's something we'll get in ourselves

@lostmygithubaccount Thanks for letting me know! Once you have more concrete steps I would definitely like to help out


RapiD login bug

Description
I am unable to login to RapiD. I am able to made edits and use the UI normally, however, when I try to upload a prompt asks me to login unsuccessfully.
I have tried clearing chrome data and relogging in to both my OpenStreetMap account and Rapid account separately. I have also tried using incognito mode to no success.
Version
2.1.1
What browser are you seeing the problem on? What version are you running?
Chrome v117.0
The OS you're using
mac
Steps to reproduce
No response
The browser URL at the time you encountered the bug
https://rapideditor.org/edit#background=Bing&datasets=fbRoads,msBuildings&disable_features=boundaries&map=3.59/24.61/-43.79
The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

Thanks for reporting-  I also just started getting this a few minutes ago..
We'll investigate!

This may be a known issue server-side. See https://github.com/openstreetmap/operations/issues/867#issuecomment-1747476977 .

The issue has been fixed server-side.

Thanks!


Carthage support

Added framework and test schemes for each supported platform.
Made the schemes Shared for Carthage support.
Embedded the Pods in the repo for Carthage build support.
Upgraded the Podfile.
Bumped the pod version.
Raised the minimum deployment version to 6.0 to support bitcode.

Nice job getting the tests working!
However, rather than include the Pods directory in the repository, I would suggest instead that you create Cartfile.private and add the dependencies that are in the Podfile there.

Thanks @weissazool!
I've made those changes but for some reason Travis CI doesn't use the proper .travis.yml config for the latest commits but you can check the status of the build for my fork here: https://travis-ci.org/arturgrigor/TransitionKit/builds/233918533.

@arturgrigor Great! I have a question, though.
If you remove the Podfile and the Podfile.lock, won't it no longer be possible to add this framework via Cocoapods, since it won't be able to fetch its dependencies?
Also, the Carthage directory should probably be added to .gitignore.

@weissazool no, removing the Podfile doesn't affect that at all because the installation uses the TransitionKit.podspec in which you define the dependencies. The Podfile is just for building the project locally but as long as you got the Carthage frameworks in place you no longer need that.
Yeah, I guess you're right with the .gitignore file.

@arturgrigor I see. But for any existing users, there's no guarantee that they will have Carthage. Since the primary method of integration up until now has been Cocoapods, it's quite likely that they have that. My concern is that this would break this part of the readme for any current users of this framework.

@weissazool That wouldn't be affected at all because when you install this framework using CocoaPods it uses the TransitionKit.podspec file which already exists. The Podfile needs to be there only if you want to build this particular framework locally in order to contribute to it. So as you can see these are 2 different people, an app developer and a framework developer.
But don't worry because I did a few changes and I added the Podfile and Podfile.lock files back.

@blakewatters can you please take a look at this small PR?
The whole purpose of this PR is to add Carthage support to this project and in order to do so I have  followed the setup from AlamofireImage for building the project and linking the dependencies.


[DiscordCoreAPI] to v2.0.1 and [Jsonifier] to v0.9.9

DiscordCoreAPI changes:
-Made the members of EventManager static.
-Modifed the VoiceConnection's send logic.
-Improved the parsing of ETF character strings.
-Improved the byte-swapping functions for ETF parsing to improve performance.
-Improved the polling logic of the TCP connection sockets.
-Fixed a couple serialization key exclusions.
-Updating to accommodate for camel-case swapped casing of Jsonifier classes.
-Modified the CoRoutineThreadPool class to derive from its container.
-Modified the socket read/write logic.
-Updated the DetectArchitecture.cmake script.
-Improved the logic of the SongAPI and related classes.
-Fixed an issue where timeout was enabled on CoRoutines that it should not have been.
-Improved the voice connection's connection logic.
-Replaced local instances of DiscordCoreClient* with the statically held version.

-Updated some of the integer-postfixes.
-Switched to camel-case for types, and concepts.
-Modified the DetectArchitecture.cmake script.
-Added the check for the lzcnt instruction.
-Added a universal fallback tzcnt function.
-Modified the string class.
-Removed a few unnecessary explicit template parameters.
-Implemented the new SelectMenuDefaultValues type.
-Improved the ISADetection headers, by splitting it into multiple different headers.
-Added an implementation for parsing tuple-array-types.
-Moved the concepts out into their own header.

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[x] The "supports" clause reflects platforms that may be fixed by this new version
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

It seems as though the OSX implementation on your runner is lacking the source_location header that is required by my code.

Our CI uses the OSX machine with AppleClang <IP_ADDRESS>30022 installed. If this version doesn't support source_location, then I suggest you can add discordcoreapi:x64-osx=fail to the CI baseline.


Add filename check to avoid crashing when its none

If the filename is None, the flow gets interrupted in the middle, add a check to ensure it picks the largest file.

Summary by CodeRabbit

Bug Fixes

Improved handling of the filename parameter in download link creation and file selection processes, preventing errors when filename is invalid.

Refactor

Enhanced logic for conditional checks to optimize processing efficiency.

I have written a util function to correctly get the file index https://github.com/mhdzumair/MediaFusion/blob/f2be00dec5bcbbcce7571144cd3e5fe8fb8ef567/streaming_providers/parser.py#L6  this function is being use under 4 debrid services, so best to refactor both torbox and offcloud

I have written a util function to correctly get the file index
https://github.com/mhdzumair/MediaFusion/blob/f2be00dec5bcbbcce7571144cd3e5fe8fb8ef567/streaming_providers/parser.py#L6
this function is being use under 4 debrid services, so best to refactor both torbox and offcloud

Fixed torbox to use it, but offcloud is a bit more complex, the largest file cannot be found with the current way the utils is - there is no key available, will do that later in a different one?


HAIL CAPITALISM

Whats going on here?

Broke and losing my mind.

Done with open-source/GitHub.
I'll leave stuff on npm (it's actually useful) and have removed myself from Jeet/Lost so no worries.
Feel free to fork https://github.com/corysimmons/postcss-ant/commit/9f39eddb8df3671ec1cfede99351d8a7c5e54b6c if you need docs.

Sorry to hear that.
Ant is your best work yet. You should keep it up even if only for sentimental reasons. There are people out there who really appreciate your stuff. Just hang on there...


Relative Exclude

The Exclude relative pathing seems broken based upon where you run rubocop from. I mostly want to confirm that this behavior is broken, and if so I can try to find some time to apply a patch. I've never looked at rubocop source and may be about as quick as a sloth stuck in velcro.
Thanks!
Expected behavior
In an inherited .rubocop-todo.yml file, if you have an Exclude block and run rubocop from in that directory tree, to continue to treat the Excluded files as relative to the .rubocop.yml (or .rubocop-todo.yml if inherited)
Actual behavior
The exclusion fails, unless I have an entry for the specific file without the directory (some/path/foo.rb and foo.rb listed as Excludes)
Steps to reproduce the problem
I setup a gist!
git clone https://gist.github.com/jshirley/e1cdfd0e5dd04612d112e4675d038a91 rubocop-bug-report
cd rubocop-bug-report
bundle
mkdir -p rel/path && mv broken.rb rel/path # gist doesn't allow subdirectories
bundle exec rubocop rel/path/broken.rb # this works, as expected
cd rel/path
bundle exec rubocop broken.rb # this should pass!

RuboCop version
$ rubocop -V
0.40.0 (using Parser <IP_ADDRESS>, running on ruby 2.1.2 x86_64-darwin15.0)

I started digging in a little bit, and looking at base_dir_for_path_parameters, it is converting .rubocop-todo.yml into .rubocop_todo.yml, which obviously doesn't match (therefor it is returning Dir.pwd).
If I rename my file to .rubocop_todo.yml everything works as expected.
I will continue investigating why the conversion from - to _ is happening.

Exclude paths are relative to the file where they are given only for .rubocop.yml and .rubocop_todo.yml. For other files they are relative to the current directory, and this is by design so that paths given in .../rubocop/config/default.yml, for example, are relative to where you run. So use the standard naming .rubocop_todo.yml and you'll be fine.
There is no conversion of names BTW. The message Attention: rubocop_todo.yml has been renamed to .rubocop_todo.yml means that RuboCop changed how it names the todo-file at one point.

Ah, I see now. Thanks!


Use enums and sets

There are workarounds for each issue, it's time to try this.

Works fine for ConfigFlags
type
  ConfigFlags* = enum
    Invalid,
    FullscreenMode, ## Set to run program in fullscreen
    WindowResizable, ## Set to allow resizable window
    WindowUndecorated, ## Set to disable window decoration (frame and buttons)
    WindowTransparent, ## Set to allow transparent framebuffer
    Msaa4xHint, ## Set to try enabling MSAA 4X
    VsyncHint, ## Set to try enabling V-Sync on GPU
    WindowHidden, ## Set to hide window
    WindowAlwaysRun, ## Set to allow windows running while minimized
    WindowMinimized, ## Set to minimize window (iconify)
    WindowMaximized, ## Set to maximize window (expanded to monitor)
    WindowUnfocused, ## Set to window non focused
    WindowTopmost, ## Set to window always on top
    WindowHighdpi, ## Set to support HighDPI
    WindowMousePassthrough, ## Set to support mouse passthrough, only supported when FLAG_WINDOW_UNDECORATED
    InterlacedHint, ## Set to try enabling interlaced video format (for V3D)

proc isWindowState*(flag: ConfigFlags): bool =
  ## Check if one specific window flag is enabled
  echo cast[int32]({flag})

proc setWindowState*(flags: set[ConfigFlags]) =
  ## Set window configuration state using flags (only PLATFORM_DESKTOP)
  echo cast[int32](flags)

proc clearWindowState*(flags: set[ConfigFlags]) =
  ## Clear window configuration state flags
  echo cast[int32](flags)

proc setConfigFlags*(flags: set[ConfigFlags]) =
  ## Setup init configuration flags (view FLAGS)
  echo cast[int32](flags)

discard isWindowState(FullscreenMode)
setWindowState({FullscreenMode, VsyncHint})

Duplicate enum values are covered:
type
  MaterialMap = enum
    Diffuse, Metalness

  ShaderLocationIndex = enum
    MapDiffuse, MapMetalness

template Albedo(_: typedesc[MaterialMap]): untyped = Diffuse
template Specular(_: typedesc[MaterialMap]): untyped = Metalness

template MapAlbedo(_: typedesc[ShaderLocationIndex]): untyped = MapDiffuse
template MapSpecular(_: typedesc[ShaderLocationIndex]): untyped = MapMetalness

This is totally wrong and can cause issues:
type
  Gesture* {.size: sizeof(int32).} = enum
    # None, ## No gesture
    Tap, ## Tap gesture
    Doubletap, ## Double tap gesture
    Hold, ## Hold gesture
    Drag, ## Drag gesture
    SwipeRight, ## Swipe right gesture
    SwipeLeft, ## Swipe left gesture
    SwipeUp, ## Swipe up gesture
    SwipeDown, ## Swipe down gesture
    PinchIn, ## Pinch in gesture
    PinchOut, ## Pinch out gesture

echo sizeof(set[Gesture]) # 2!

This is also wrong:
proc setGesturesEnabled*(flags: set[Gesture]) =
  ## Enable a set of gestures using flags
  echo cast[int32](flags)

proc isGestureDetected*(gesture: Gesture): bool =
  ## Check if a gesture have been detected
  echo cast[int32]({gesture})

proc getGestureDetected*(): Gesture =
  ## Get latest detected gesture
  result = cast[Gesture](0)
  echo result

setGesturesEnabled({Doubletap, Drag}) # 10, correct
setGesturesEnabled({PinchIn}) # 256, correct
discard getGestureDetected() # Tap!

So many ops to support sets, it is not worth it imo. Better use enums and flags[enum]

Done


OPL3 FM Synthesizer Synthesis and Simulation Issues

Verilator Simulation Warnings
While running the synthesis for the OPL3 FM Synthesizer, I encountered several warnings related to the RTL code. Although the synthesis completes successfully due to the Makefile being configured to ignore these warnings, it's crucial to address these warnings for cleaner code and synthesis. Other tools like yosys might treat these warnings as errors, potentially causing issues in the future. To run the Makefile go to 2.sim/  folder and run make. The following flags are currently set to ignore warnings in the Makefile:
VERILATOR_FLAGS += -Wno-TIMESCALEMOD
VERILATOR_FLAGS += -Wno-LITENDIAN
VERILATOR_FLAGS += -Wno-WIDTH
VERILATOR_FLAGS += -Wno-UNOPTFLAT
VERILATOR_FLAGS += -Wno-CASEINCOMPLETE
VERILATOR_FLAGS += -Wno-UNDRIVEN
VERILATOR_FLAGS += -Wno-VARHIDDEN
VERILATOR_FLAGS += -Wno-IMPORTSTAR
VERILATOR_FLAGS += -Wno-REALCVT
VERILATOR_FLAGS += -Wno-UNUSED

By removing the flags one by one you can see for your self the warnings that Verilator has such as:
%Warning-WIDTH: /home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/3.build/../1.hw/modules/channels/src/channels.sv:212:71: Bit extraction of var[5:0] requires 3 bit index, not 4 bits.
                                                                                : ... In instance opl3.channels
  212 |                     signals.add_c = !is_new || (chc && !connection_sel[self.channel_num]);
      |                                                                       ^
%Warning-WIDTH: /home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/3.build/../1.hw/modules/channels/src/channels.sv:213:71: Bit extraction of var[5:0] requires 3 bit index, not 4 bits.
                                                                                : ... In instance opl3.channels
  213 |                     signals.add_d = !is_new || (chd && !connection_sel[self.channel_num]);
      |                                                                       ^
%Warning-WIDTH: /home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/3.build/../1.hw/modules/channels/src/channels.sv:230:90: Operator ADD expects 20 bits on the RHS, but RHS's SEL generates 14 bits.
                                                                                : ... In instance opl3.channels
  230 |             'b01, 'b10: next_self.channel_l_acc_pre_clamp = self.channel_l_acc_pre_clamp + signals.channel_2_op;
      |                                                                                ^
%Warning-WIDTH: /home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/3.build/../1.hw/modules/channels/src/channels.sv:236:90: Operator ADD expects 20 bits on the RHS, but RHS's SEL generates 14 bits.
                                                                                : ... In instance opl3.channels
  236 |             'b01, 'b10: next_self.channel_r_acc_pre_clamp = self.channel_r_acc_pre_clamp + signals.channel_2_op;
      |                                                                                ^

I won't list all the warnings here due to readabilty but there are 108 WIDTH warnings, 37 UNUSED warnings, and several minor warnings.
Cocotb Simulation Warnings
Running make  in the 2.sim/cocoTB folder also results in warnings related to the RTL code:
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:73: warning: Port 3 (out) of pipeline_sr expects 3 bits, got 2.
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:73:        : Padding 1 high bits of the port.
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:123: error: Index bankb_p[2] is out of range.
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:73: warning: Port 3 (out) of pipeline_sr expects 3 bits, got 2.
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:73:        : Padding 1 high bits of the port.
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/operator/src/phase_generator.sv:282: sorry: constant selects in always_* processes are not currently supported (all bits will be included).
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/operator/src/phase_generator.sv:302: sorry: constant selects in always_* processes are not currently supported (all bits will be included).
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/operator/src/phase_generator.sv:302: sorry: constant selects in always_* processes are not currently supported (all bits will be included).
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/operator/src/phase_generator.sv:314: sorry: constant selects in always_* processes are not currently supported (all bits will be included).
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/operator/src/phase_generator.sv:314: sorry: constant selects in always_* processes are not currently supported (all bits will be included).
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:73: warning: Port 3 (out) of pipeline_sr expects 3 bits, got 2.
/home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/2.sim/cocotb/../../1.hw/modules/misc/src/mem_multi_bank.sv:73:        : Padding 1 high bits of the port.

And so on... As said I won't list all the listed warnings and errors.

Hi @gtaylormb. This is essentially:

standalone Verilator-based Linter for opl3_fpga RTL
Icarus-based Linter for opl3_fpga RTL (within cocotb environment)

In a follow up to @hzeller recommendation, we are also planning to bring up Verible-based Linter for opl3_fpga RTL.
Please consider using these flows to make the opl3_fpga RTL even better than it already is.

Verilator's linting is way over the top, and satisfying all the warnings would lead to messier, more verbose, and harder to read code that's not necessary for synthesis.
Icarus does not fully support SystemVerilog and probably can't be used for this project.
I suggest switching to https://github.com/MikePopoloski/slang for sane linting. I have found a few minor things running slang and will try to update https://github.com/gtaylormb/opl3_fpga shortly.

It's wonderful news that RTL Linting is now also a step in the OPL3 QA process!
However, we are still curious about Verilator findings that are over the top? Could you please send a few, say three most useless.
As we have in the meantime also become more familiar with Verible, we are starting to put it to good, not only for Linting, but also for unified code look-and-feel, i.e. formatting. We therefore highly recommend taking a close look at it.

@gtaylormb could you please share the script (or workflow) you are using for your Slang-based OPL3 RTL linting? That's to bootstrap our effort in that direction.

However, we are still curious about Verilator findings that are over the top? Could you please send a few, say three most useless.

Basically any WIDTH* warning; Verilator is really dumb about these:
%Warning-WIDTHEXPAND: modules/operator/src/calc_envelope_shift.sv:119:31: Operator SHIFTL expects 4 bits on the LHS, but LHS's VARREF 'block' generates 3 bits.
                                                                        : ... note: In instance 'opl3.channels.control_operators.operator.envelope_generator.calc_envelope_shift'
  119 |         block_shifted = block << 1;

Is generated from this code, truncated for brevity:
module calc_envelope_shift
    import opl3_pkg::*;
(
    input wire clk,
    input wire [REG_BLOCK_WIDTH-1:0] block
);
    logic [REG_BLOCK_WIDTH:0] block_shifted;

    always_comb
        block_shifted = block << 1;

This can be eliminated by changing the line to this monstrosity:
        block_shifted = (REG_BLOCK_WIDTH+1)'(block << 1);
Terrible--there's hundreds of these in opl3_fpga. But if you turn off the WIDTH* warnings it may provide some useful stuff. Mostly not though.
I tried Verible. Seems okay. It mostly complained about missing EOL characters at the end of files, tabs instead of spaces in some files, and using always instead of always_ff or always_comb in a Verilog (non-SystemVerilog) .v file that I didn't write.

@gtaylormb could you please share the script (or workflow) you are using for your Slang-based OPL3 RTL linting? That's to bootstrap our effort in that direction.

I just added a lint target to the Makefile in my fpga folder:
lint:
	slang $(PKG_SRC) $(RTL_SRC)

IEEE.1364-2005.Verilog.pdf
Regarding Verilator linting, let's note that it is excruciatingly precise -- Verilog shift operators indeed don't change the operand width.
While VHDL would error-out  on that line, Verilog is silently zero-padding the extra MSB. That's exactly what Verilator is warning about (and rightly so).
As shown by @gtaylormb, a way to silence it is by explicitly declaring the zero-padding intent. Here is a bit less verbose form of the same: block_shifted = {1'b0, (block << 1)};
For better transparency of what is going on: block_shifted = {1'b0, block[REG_BLOCK_WIDTH-2:0], 1'b0};
This fully spelled out form (which we recommend for shifting) brings a question: Does block_shifted really need to have one extra MSB bit, which is always and only 0?! Is that bit perhaps getting optimized out in synthesis? Has there been any reference to it in the synth warnings?

This fully spelled out form (which we recommend for shifting operations) brings a question: Does block_shifted really need to have one extra MSB bit, which is always and only 0?! Is that bit perhaps getting optimized out in synthesis? Has there been any reference to it in the synth warnings?

That's wrong, and both spelled out forms are IMHO a bad way to code due to the verbosity which I was highlighting, but also highlight a misunderstanding of how Verilog works. If REG_BLOCK_WIDTH is 3, and block is 'b111, block_shifted gets 'b1110. There are no synthesis warnings and no other tools complain because the original syntax is correct. This type of shift is all over the code and proven in both Xilinx and Altera FPGAs.
Verbosity = more potential for bugs both when coding and maintaining. The verilator warning is counterproductive.
Waveform from Questa:

Regarding the language in the LRM, you left out some info just above the chart you pasted (I'm looking at IEEE Std 1800-2012 for reference):
"A context-determined expression is one where the bit length of the expression is determined by the bit length
of the expression and by the fact that it is part of another expression. For example, the bit size of the right-
hand expression of an assignment depends on itself and the size of the left-hand side."
You'll notice for shifts only j is described as self-determined. This implies i is context-determined, thus I believe you have misinterpreted the LRM, and why the original syntax works.

Another proof i is context-determined:
    initial
        $display("Result: %0x", (1'b1 << 15) >> 15 == 1);

# Result: 1

    initial
        $display("Result: %0x", (1'b1 << 15) >> 15 == 1'b1);

# Result: 0

Anyway, I've merged slang and Verilator linting to opl3_fpga: https://github.com/gtaylormb/opl3_fpga/pull/51
Of course I've turned off the WIDTH* warnings in Verilator. I didn't find any others to be as blatantly misguided.

Great that OPL3 RTL is now cleaner👍 We are soon to take a fresh new copy of it and try porting it again to GateMate, pending PNR improvements that CologneChip has in the pipe.
As for the width question, it seems that the very fact we are having a lengthy discussion on it, resorting to LRM quotes, and pulling in other folks for their expert opinion, supports the statement that explicit expression of designer intent has value 😉

I mean, I would argue it was the misguided Verilator warning that threw us into this discussion in the first place. The original code is quite clear IMO. This point was illustrated by the fact that he (I think unintentionally) said the code is quite clear--move the bits over 1 into the wider vector (even though that is the code that throws the warning) :)
I would still further argue against more verbose syntax. Part selects to perform shifts are harder to read and more error prone than the shift operator IMO. E.g. try changing it to shift 5 instead of 1, or a parameterized X amount.

Pretty excited to see your progress

Stay tuned! @DadoCCAG, since an old timer C64 and SoundBlasterPro adict, is even more excited 😄.
BTW, would something like this block_shifted = {block, SHIFT_NUM'(0)};
be an acceptable alternative to block_shifted = block << SHIFT_NUM ?!

Stay tuned! @DadoCCAG, since an old timer C64 and SoundBlasterPro adict, is even more excited 😄.

That's awesome. I actually had a C64 at one point that was my grandfather's back in the day. He actually coded music on it, saved on a bunch of tapes, but I believe those are long gone I'm afraid. In the 90s my family bought a 486 with a PAS-16; that was my exposure to the OPL3. A lot of nostalgia. BTW have you guys checked out https://github.com/MiSTer-devel/ao486_MiSTer? A really, really cool project. OPL3_FPGA was ported to it, so you can play all those old DOS games using this code on an FPGA.

BTW, would something like this block_shifted = {block, SHIFT_NUM'(0)};
be an acceptable alternative to block_shifted = block << SHIFT_NUM ?!

I mean, I think you can guess my preference. Nothing conveys design intent for a shift better than using the shift provided with the language. When you're scanning through code debugging or whatever, it is advantageous to quickly understand the code without having to stare at it, and move on--hence my preference for concise, readable code, and why I've been using the more advanced features of SystemVerilog in design for the past 15 years. You used SHIFT in the parameter name, but otherwise I'd have to stare at that line for a bit to understand, "oh, this guy's doing a shift here." In my brain I'd literally replace the concatenation/bit extension code with a << operator. I'd also wonder why a shift operator wasn't used, and probably stare at it a bit longer, thinking I'm missing something. In complex designs this becomes really tedious and distracts from real problems. This is why higher-level languages were designed.
Of course in using the features of a language, it helps to have extensive knowledge of the language and the trust that it does what you want which happens with experience (and test benches), so coders that are unsure or mistrustful of the language tend to produce worse looking code to avoid imagined problems--sort of, go with what you know or think you know. And not just newer coders--I've seen older, more experienced engineers still code in old school Verilog and explicitly define things down to the finest granularity, because they never allowed that trust to occur or bothered to try or learn new ways of doing things (e.g. SystemVerilog) even though they have years and years of coding experience. This is actually extremely common.
Anyway, I think we got a bit derailed (no pun intended) with the Verilator warning. No other tool gives that warning that I'm aware of, and I think (I hope) you understand now why I don't agree with it and think it's detrimental. It should not scare you from using the shift operator--it's really quite simple and clean. Linting and good coding style cannot replace a good test bench and testing of course. People still make mistakes, and there are tradeoffs with every approach.

@wsnyder, given that Verilator WARNING got us derailed, and that our Question on Verilator Issues' page is now closed, would it make sense to reopen this Issue as an Enhancement or even Bug, looking to improve its Linting rules and so preempt future derailments?!

Yes, feel free to file a bug asking for the specific width shift case get suppressed.

Heads up, we may also get a CDC linter

After updating the OPL3 FM Synthesizer to the latest version, where Greg added Verilator and Slang linting as a step in the workflow, I tried the GateMate synthesis after converting the SystemVerilog files to Verilog as discussed here. The output now has much fewer warnings, but there are still a few that I would like to address.
Warning Type 1: Unused Wires
Warning: Wire opl3.\host_if.dout_sync.in [7] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [6] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [5] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [4] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [3] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [2] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [1] is used but has no driver.
Warning: Wire opl3.\host_if.dout_sync.in [0] is used but has no driver.

Going through all the SystemVerilog and generated Verilog files in question I don't see a problem. I am going to go through the generated Verilog files because those are the ones synthesized. Code ommited for brevity and clarity.
In opl3.v:
wire [7:0] status;

host_if host_if(
    .clk(clk),
    .reset(reset),
    .clk_host(clk_host),
    .ic_n(ic_n),
    .cs_n(cs_n),
    .rd_n(rd_n),
    .wr_n(wr_n),
    .address(address),
    .din(din),
    .dout(dout),
    .opl3_reg_wr(opl3_reg_wr),
    .status(status),
    .force_timer_overflow(force_timer_overflow)
);

In host_if.v:
input wire clk_host;
input wire [7:0] status;
wire [7:0] host_status;

synchronizer #(.DATA_WIDTH(opl3_pkg_REG_FILE_DATA_WIDTH)) dout_sync(
    .clk(clk_host),
    .in(status),
    .out(host_status)
);

In synchronizer.v:
input wire [DATA_WIDTH - 1:0] in;

always @(posedge clk)
    {sync_regs[DATA_WIDTH+:DATA_WIDTH], sync_regs[0+:DATA_WIDTH]} <= {sync_regs[0+:DATA_WIDTH], in};

The warnings indicate that the dout_sync.in wire in the host_if module is not driven. This is suspicious because dout_sync should be connected to status, which should be driven by the opl3 module.
Warning Type 2: Port Resizing
Warning: Resizing cell port opl3.$flatten\channels.\control_operators.\operator.\phase_generator.\exp_lut_inst.$auto$proc_rom.cc:155:do_switch$1939.0.0.A_DO from 10 bits to 20 bits.
Warning: Resizing cell port opl3.host_if.afifo.mem.0.0.A_BM from 10 bits to 20 bits.
Warning: Resizing cell port opl3.host_if.afifo.mem.0.0.A_DI from 10 bits to 20 bits.
Warning: Resizing cell port opl3.host_if.afifo.mem.0.0.B_DO from 10 bits to 20 bits.

Most of these warnings refer to the following line in afifo:
reg [WIDTH-1:0] mem [(1<<LGFIFO)-1:0];

In afifo.v, the tool is resizing the WIDTH from 10 bits to 20 bits. Similar warning is also present in the control_operators file.
Note
If anyone wants to try the synthesis for themselves you can just type in the 3.build folder:
make synth

That will generate the Verilog files from the SystemVerilog files(assuming you installed sv2v).
If you don't have sv2v you can run these commands instead:
./create_rtl_fileslist -v
make synth_vlog

Warning Type 1
@gtaylormb, how about tying off status  in the generate else branch?!

Warning Type 2
@ZipCPU did you know that your AFIFO from 10GE Switch was also used to synthesize FM music 😉
@pu-cc Any tips on this Yosys resizing, from the perspective of CologneChip memory form-factors?

Why is the synth choosing larger 20-bit primitive when the 10-bit RAM is also available in GateMate library?

Almost all of my IP has various blocks within it, such as this one (below) in order to avoid the UNUSED variable lint warning.
// Make Verilator happy
// {{{
// Verilator lint_off UNUSED
wire	unused;
assign	unused = &{ 1'b0, S_AXI_AWCACHE, S_AXI_AWPROT, S_AXI_AWQOS,
    S_AXI_ARCACHE, S_AXI_ARPROT, S_AXI_ARQOS };
// Verilator lint_on  UNUSED
// }}}

It's easy enough to do, and it also acts as a documentation that you are aware of the issue.
Dan

Also, one other note: beware that Verilator tends to only generate warnings for parameter paths chosen during the lint step.  A full Verilator lint requires running lint with all potential parameter settings.

... good tips. However, the warnings from this, second round of scrutiny, are from Yosys synthesis (GateMate fork) -- Greg has in the first cleanup round already taken care of Verilator and Slang linting.

Well ... I tried.  I read "Warning Type 1: Unused Wires" and figured that's what was going on.  After a second look, the issue appears to be used but not driven wires.  Verilator can typically detect that sort of thing.  I'm not sure why Verilator hasn't flagged these issues then.

... you are right, we have updated that subtitle to make it more precise. Looking at Greg's Verilator option
verilator --lint-only -Wno-WIDTHEXPAND -Wno-WIDTHTRUNC --top-module $(TOP) $(VLOG_SRC)
we don't see  -Wno-UNDRIVEN. @wsnyder any thoughts on this miss? Interestingly, Slang and Verible have also not caught it...

UNDRIVEN isn't enabled by default,  see the docs for what is. I recommend -Wall then turn off what you have to.

When running Verilator linting in our script with the -Wall flag we get the UNDRIVEN warning aswell.
 %Warning-UNDRIVEN: /home/user/openCologne/4.Advanced--4--Yamaha-OPL3-FM-Synth/3.build/../1.hw/modules/top_level/src/opl3.sv:66:37: Signal is not driven: 'status'
                                                                                : ... note: In instance 'opl3'
    66 |     logic [REG_FILE_DATA_WIDTH-1:0] status;
       |                                     ^~~~~~

UNDRIVEN and UNUSEDSIGNAL are useful warnings. I can fix in opl3_fpga.
Note these occur if the timers are turned off via the INSTANTIATE_TIMERS parameter in opl3_pkg.sv. I'm not sure how you guys are planning on using opl3_fpga, but if you want the full chip (as used in ao486 MiSTer), you may want these on. If timers are turned off these signals just get trimmed out. Status is useless in this case. I didn't use them for the base opl3_fpga implementation because I just use an internal timer in the Zynq PS to control writes from .dro files.

... please, send a note when you want us to refresh the OPL3 RTL again. Given the resolution of the last GateMate build issue, we are ready to try the OPL3 core. We are looking for a featherweight demo SOC to put the OPL3 into, one that can only read and play the soundtracks. Basically, something on par with your Xilinx BD example, but portable to all FPGA vendors.
We are also curious on your take on the following idea:

set OPL3 into Manta
use PC Python script to convert standard soundtrack files to OPL3 programming sequences
and transfer them to OPL3 via UART at 115.2kbps
Would that be too slow? What host_if  throughput does OPL3 need to play Doom?

The other option is to use on-chip PicoRV32 RISC-V microcontroller. We are seeking your guidance and tips...

use PC Python script to convert standard soundtrack files to OPL3 programming sequences

I'd probably start with porting imfplay over to your platform and highjacking the OPL3 writes. This is what I did for opl3_fpga and my modified version is here. You won't need the timers and won't need to read anything back. DRO files are already in the format of OPL3 programming sequences with 1us timer gaps essentially.
I suspect that UART speed should be fast enough but I've never characterized the actual write speeds.

@TarikHamedovic if you believe that the original topic of this issue is now resolved, and corresponding discussion track exhausted, please proceed with closing it.

Greg added Linting, we also fixed some GateMate synthesis and implementation issues and now the sythesis and implementation of the OPL3 are okay, so I think the original issue is resolved.


kie-issue#636: DMN Monaco highlighting throws error when used with DMN Runner

Closes: https://github.com/apache/incubator-kie-issues/issues/636
This looks like a Monaco issue, reported here.
This is a fix that prevent key events inside DMN Runner to be "bubbled" outside it.
I didn't found any other key event that trigger that issue in Monaco (properties panel, Data Types editor, renaming the node in diagram editor, etc.).

Thanks for this PR @danielzhe. The error only happens using the DMN Runner form? I guess it would be good to ensure it doesn't happen while using the DMN Runner table too.

@ljmotta good point about DMN Runner Form mode and Table mode. @danielzhe could you please double check? Please let us know if you do not know how to switch to DMN Runner table mode.

I just tested and it's working, @jomarko @ljmotta ! 🎉


fix typo in rabbitmq-ha/values.yaml

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:

/ok-to-test
/lgtm


Colors not exporting in v48

Colors don't seem to be exporting along with the rest of the text styles. I believe this may be a bug with Sketch v48 since it made several tweaks to color functionality.
As a test, I created a bright red text style:

After exporting and importing, this is the result:

Looking at the JSON, the color value is missing:
{"styles":[{"name":"Test","font":"DINPro-Medium","size":44,"color":{},"alignment":0,"spacing":0,"lineHeight":0,"textTransform":0}]}
Thanks for the help!

I'm also experiencing this issue. Haven't found a solve.

This looks to be because of the newly supported color profiles. Will be working on a fix!

Thanks for the update @nilshoenson. Just curious if you are close to a fix? Would be super helpful!

Yes I love this plugin — and just updated to 48 and noticed this bug. Thanks for fixing!!

I just pushed an update which should fix this! Thanks for the feedback all!


Clarify decimal constants

My co-worker and I each spent 4 hours trying to understand what we were seeing in SQL Server Profiler.  This was the first page I went to in order to try to understand what I was seeing.  Hopefully this saves someone else some time.

Thank you for the submission. This must have been very frustrating.
How profiler renders values in a text field seems beyond the scope of the https://docs.microsoft.com/en-us/sql/t-sql/data-types/constants-transact-sql?view=sql-server-ver15#float-and-real-constants article.
I'm going to close this as a doc update, but if you'd like to have us evaluate it as a documentation issue with Profiler, please open an issue with the Profiler article

@MikeRayMSFT Is your suggestion to link back to the Profiler page from this page?  It seems incorrect to not link the two somehow.


code review audit - repo error validation

code review audit - repo error validation done against the time range, pull requests, commits.

please address the review comments.

discussed, no change neeeded


Webp support for shopware store

It would be great if possible to upload extension preview images in webp format as well

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/NEXT-37746.
[created from NEXT-37746, comment 487491]

[public]Thank you for your report. We close this ticket, as this is a request for our Extension store. However, the issue tracker is only for bug reports of the Shopware product and its extension.
We have forwarded the request to our Extension Store team and in fact, we have plans already to allow more formats including Webp in the future.
[created from NEXT-37746, comment 488116]


http, lavalink: Remove http1 feature flag from hyper

This removes the http1 feature flag from hyper. It means that all connections made will use http2, which is supported by Cloudflare and Discord and has several advantages over http1, especially when the same server is requested over and over again, which is the case here.
http1 pulls in quite a bit of conditionally compiled code that won't be used and might make the connections use http1, which isn't desired. Both Discord/Cloudflare and Lavalink support http2 and would benefit from it, so forcing the use of it would only make sense. If a user would like to keep using http1, they can add a hyper = { version = 0.14, features = ["http1"] } to their Cargo.toml to force enabling the feature.
Not adding lavalink tag because it only effects the examples.
Tested with the current http-proxy version and works fine with it. When that is rewritten to 0.3, http1 server should be enabled.

Thanks

Thanks


Encrypt.dll not found

2016-08-08 12:01:10,857 [PokemonGoBot] [ERROR] encrypt.dll is not found! Please place it in the bots root directory.
2016-08-08 12:01:10,857 [PokemonGoBot] [INFO] Platform: win32 Bot root directory: C:\Users\Anthony\Downloads\PokemonGo-Bot
Other Information
OS:
Git Commit: (run 'git log -n 1 --pretty=format:"%H"' and paste it here)
Python Version: (run 'python -V' and paste it here)

You need to grab them from the Internet.

https://github.com/PokemonGoMap/PokemonGo-Map/tree/develop/pogom

#2780
For the love of God please read/search before you post.


Improvements to persist annotations

Description:

Both persist:Relation and persist:AutoIncrement can be added to records without persist:Entity
Even if persit:Entity annotation is not present this is taken into validation for duplicate records

The existing implementation allow persist:Relation without persist:Entity.
import ballerina/persist;

public type Profile record  {|
    readonly int id;
    string name;
    @persist:Relation {keyColumns: ["userId"], reference: ["id"]}
    MultipleAssociations user?;
|};

public type MultipleAssociations record {|
    readonly int id;
    string name;
|};

But persist:AutoIncrement is related to the primary key. persit:Entity must be added to add primary key. Therefore, restricted by the current implementation.

IMO  this is valid only if both records are marked as persist:Entity.
Also the same for AutoIncrement.
Looping in @kaneeldias for clarifications

IMO this is valid only if both records are marked as persist:Entity.
Also the same for AutoIncrement.
Looping in @kaneeldias for clarifications

+1 both @persist:Entity and @persist:AutoIncrement should be allowed only inside records marked with @persist:Entity

Closing this issue as this is fixed now.


post_build: support explicitly mkdocs-awesome-pages-plugin nav

do not recursively call 'on_nav' to fix issue #65
this makes this plugin and the awesome-pages one 100% compatible
thanks to @phasel74, @scmcca and of course @lukasgeiter

@scmcca @lukasgeiter @phasel74 would you please check and test this PR? I believe I found a way to fix the problem after all thanks to Lukas help.

Thanks for taking care of this so quickly!
I'd love to test this out, but I'm somewhat new to this. Any hints on how I could use the changes made here to the plugin in my project? Much appreciated!

This doesn't really work for me. For example in this simple scenario, Page 1 doesn't get translated:
site_name: Test
theme: material
plugins:
  - i18n:
      default_language: en
      languages:
        en: English
        de: Deutsch
      nav_translations:
        de:
          Page 1: Seite 1
  - awesome-pages

nav:
  - Page 1: page1.md

This can probably be fixed... However, I also noticed a conceptual issue with the current approach. Right now, you translate the navigation first, and then run it through awesome-pages. This should work in some cases, but doesn't hold up for all of them.
For example, my plugin allows users to set titles (for sections, pages and links) in .pages files placed anywhere in the docs directory. But because the translation phase happens before awesome-pages does its thing, these custom titles cannot be translated.

To understand the problem better, I have a question for you: Is the structure of the navigation the same in all languages or can it be different? Meaning, can it be that one language has a nav item that the other does not?

To understand the problem better, I have a question for you: Is the structure of the navigation the same in all languages or can it be different? Meaning, can it be that one language has a nav item that the other does not?

It can be different yes, so I have to deal with a nav per language. As a matter a fact, I do have to create a config, a files and a nav for each language.

version 2.6.1 of awesome-pages plugin fixed the issue; I'm closing here and will add a warning on i18n plugin if used with awesome-pages < 2.6.1


LookupExtractor javadoc needs clarification about what to do when stop or start is called

... on an object that is already started or stopped

@drcrallen @b-slim what is the progress here?

@drcrallen please check out https://github.com/druid-io/druid/pull/2925


Remove headless services for instance manager pods

See explanation at https://github.com/longhorn/longhorn/issues/8844#issuecomment-2197769331
longhorn/longhorn#8844

Yeah. Those temporary patched services were mistakenly merged for 1.2.4 and continued to be used in the following feature and patch versions. This is a good fix, even though the orphaned headless services should not hurt.

@mergify backport v1.6.x v1.5.x


ENGINE_pkey_asn1_find_str(): don't assume an engine implements ASN1 method

Just because an engine implements algorithm methods, that doesn't mean
it also implements the ASN1 method.  Therefore, be careful when looking
for an ASN1 method among all engines, don't try to use one that doesn't
exist.
Fixes #6381

Merged.
master / 1.1.1:
5eb774324a14b03835020bb3ae2e1c6c92515db0 ENGINE_pkey_asn1_find_str(): don't assume an engine implements ASN1 method
1.1.0:
13b578ada3106a4ce9b836f167ee520539f5fa8f ENGINE_pkey_asn1_find_str(): don't assume an engine implements ASN1 method
1.0.2:
1ac3cd6277f880fac4df313702d5e3b3814e56e2 ENGINE_pkey_asn1_find_str(): don't assume an engine implements ASN1 method


Ability to enqueue a task ahead of already-enqueued tasks?

I skimmed the docs and didn't see anything but - is there any existing feature where we could "short-circuit" already-enqueued tasks so that the next thing enqueued is taken off the queue and performed next?

Am I wrong if I suggest it's a duplicate of https://github.com/procrastinate-org/procrastinate/issues/386 ?


Update customer-key-availability-key-roll.md

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks

@KCCross Please merge this PR. Thanks


Add internal env and associated licenses to windows daisy builds

Adding internal environment and associated licenses to daisy publish files

/hold

/unhold


When back or zoom is not used

What problem does this feature solve?
I want to use only one dataZoom(back or zoom).
how to use that?
When operated with show's boolean, both icons appear or both disappear.
I want to use only one of dataZoom's zoom and back.
What does the proposed API look like?
`toolbox:{
feature: {
    dataZoom: {
          title: {
          zoom: "" //i don't wanna use that(zoom)
          back: "Zoom Out" //i wanna use back.
          },
  },
}

}`

You can use custom toolbar to make a custom button and handle the click event by calling setOption and update the zoom.


Can't use perf even compile from source in WSL2

Windows Version
Microsoft Windows [Version 10.0.19045.3693]
WSL Version
<IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>-1
Distro Version
ubuntu20.04
Other Software
No response
Repro Steps
I'm using Linux version <IP_ADDRESS>-microsoft-standard-WSL2 (root@1c602f52c2e4) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Thu Oct 5 21:02:42 UTC 2023 and have
hardwarePerformanceCounters=true in my .wslconfig file

git clone --depth=1 https://github.com/microsoft/WSL2-Linux-Kernel.git
install all essential depend: build-essential flex bison libssl-dev libelf-dev libbabeltrace-dev libunwind-dev libdw-dev binutils-dev libiberty-dev
run make under WSL2-Linux-Kernel/tools/perf and make say:

Auto-detecting system features:
...                         dwarf: [ on  ]
...            dwarf_getlocations: [ on  ]
...                         glibc: [ on  ]
...                        libbfd: [ on  ]
...                libbfd-buildid: [ on  ]
...                        libcap: [ on  ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ on  ]
...                     libpython: [ on  ]
...                     libcrypto: [ on  ]
...                     libunwind: [ on  ]
...            libdw-dwarf-unwind: [ on  ]
...                          zlib: [ on  ]
...                          lzma: [ on  ]
...                     get_cpuid: [ on  ]
...                           bpf: [ on  ]
...                        libaio: [ on  ]
...                       libzstd: [ on  ]
...        disassembler-four-args: [ on  ]

run sudo ./perf stat -d ls, unexpectedly got:

Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (slots).
/bin/dmesg | grep -i perf may provide additional information.

run /bin/dmesg | grep -i perf
got
[    0.079396] Performance Events: Icelake events, 32-deep LBR, full-width counters, Intel PMU driver.
[    0.281393]     Performance counters on

Expected Behavior
Can use perf with all rich features
Actual Behavior
Can't even start it
Diagnostic Logs
No response

Is there a reason you don't want to use the perf included with the linux-tools-generic package?
See: https://github.com/microsoft/WSL/issues/10734

Is there a reason you don't want to use the perf included with the linux-tools-generic package?
See: #10734
Thank you!
I read from a stackoverflow problem(https://stackoverflow.com/questions/60237123/is-there-any-method-to-run-perf-under-wsl) saying that should fix my problem, must be outdated, never mind, I fixed my problem with install linux-tools-generic
However I'm still curious what I did wrong that I can't compile from source XD

Have the exact same issue. Both linux-tools-generic and manually compiled version fail with the same error.
  Virtualization: wsl
Operating System: Ubuntu 22.04.3 LTS
          Kernel: Linux <IP_ADDRESS>-microsoft-standard-WSL2
    Architecture: x86-64

From here:

Add<EMAIL_ADDRESS>as this issue is in virtualization env.
The topdown metrics events became default since
commit 42641d6f4d15 ("perf stat: Add Topdown metrics events as default
events"). The perf will use 'slots' if the
/sys/bus/event_source/devices/cpu/events/slots is available.
Unfortunately, the 'slots' may not be supported in the virualization
environment. The hypervisor may not expose the 'slots' counter to the VM
in cpuid. As a result, the kernel may disable topdown slots and metrics
events in intel_pmu_init() if slots event is not in CPUID. E.g., both
c->weight and c->idxmsk64 are set to 0.
There will be below error on Icelake VM since 'slots' is the leader:
$ perf stat
Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (slots).
/bin/dmesg | grep -i perf may provide additional information.
This is because the stat_handle_error() returns COUNTER_FATAL when the
'slots' is used as leader of events.
There are three options to fix the issue.

Do not expose /sys/bus/event_source/devices/cpu/events/slots to
userspace so that pmu_have_event(pmu->name, "slots") returns false.

Run cpuid at perf userspace and avoid using 'slots' if it is not
supported in cpuid.

Do not fatal perf if the leader is failed. Do not create events for an
evsel if its leader is already failed.

This RFC patch is with the 3rd option. Would you mind suggesting which
option is better?

The workaround is to run perf stat -e and explicitly NOT specify slots.
For example, the command ./perf stat -e cache-misses -d ls will be successful:
 Performance counter stats for 'ls':

              5268      cache-misses:u
            221626      L1-dcache-loads:u
              8179      L1-dcache-load-misses:u   #    3.69% of all L1-dcache accesses
   <not supported>      LLC-loads:u
   <not supported>      LLC-load-misses:u

       0.000868303 seconds time elapsed

       0.000943000 seconds user
       0.000000000 seconds sys


Feature - Add to snapstore

For Linux, snaps are the easiest way to make cross-platform installable apps. However, right now, people need to run snap install botpress-installer.snap --force-dangerous to run it, which is slightly inconvenient.
Adding it to the snapstore would solve this issue, and make it easier to find Botpress.
https://snapcraft.io/docs/electron-apps
An alternative format is AppImage, but that's not installable.

Is the snap store specific to ubuntu?

No it's not, but I believe some distros don't ship with snapd. You just need to install it and then everything should work. It's not like .deb which is meant for debian based OSes.


CASMPET-6607: Update loftsman manifest for certmanager add checks

The prior release would only catch the cray-certmanager on a loftsman install. Update this section to ensure we install:

cray-drydock
cray-certmanager
cray-certmanager-issuers

Note the first and last helm charts are "technically" not needed but we want to be safe and include anything that might be affected by namespace removals and ownership transferrals.
While here also add checks to ensure that the helm chart uninstalls behave as we expect and if any helm uninstall does not occur, exit the prereqs run.
If prereqs was not ran or did not get to this section of code we will see helm install issues with CRD ownership due to cray-certmanager-init not being removed.

Description

Checklist

[ ] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[ ] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[ ] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

Looks like shellcheck can't parse my fancy way of saving writes to files. BOO aka this is totally valid but shellcheck is angry.
{
printf "a\n"
printf "b\n"
} >> /some/file

Its a way to do multiple commands and pipe them all into one file or have stdout be ordered into one file vs multiple open()/write() calls per thing. Oh well...


use_launch_template attribute added for ASG resource.

use_launch_template attribute added for ASG resource.

Task linked: DUPLO-7090 TF: ASG duplocloud_asg_profile add new bool field


Where are the release notes for the latest version of Docker CE for Windows?

File: docker-for-windows/release-notes.md

@smarts - We believe this is no longer an issue - please open another issue if there's something we missed. Thank you!


Fix secrets

@RedHatProductSecurity/corgi-devs This will run a daily check for secrets committed to our repo in addition to our daily pip-audit check.

LGTM thx for doing this


FoodClassification example does not run

FoodClassification example has a few problems:

Use wrong iterator
No dataset
Does not safely state the path of dataset.(will fail on Linux)

https://github.com/CertifaiAI/TrainingLabs/blob/master/dl4j-cv-labs/src/main/java/global/skymind/solution/classification/FoodClassification.java#L76-L78
This is not intended. There's FoodDataSetIterator in the same folder which is not being used.

this example has since been removed, closing it


[6.0] Try to unify the query builder select behaviour

This PR attempts to standardize the query builder "select" behaviour in Laravel.
Why
Currently the addSelect() method actually behaves like select() if no previous columns have been defined. This is confusing, since adding a column shouldn't inadvertently REMOVE all other columns. Further, this creates issues when adding subqueries, which are (almost) always intended to be added to all the columns.
The change
This automatically adds table.* in the addSelect() method if no other columns have been defined yet.
More work
Right now I try to (mostly) maintain existing behaviour for selectSub() and selectRaw(), but ideally we would actually have two methods for each:
$query->selectSub();        // Replaces the current selection with a sub select.
$query->addSelectSub();     // Adds a new sub select to the existing columns.
$query->selectRaw();        // Replaces the current selection with a raw select.
$query->addSelectRaw();     // Adds a new raw select to the existing columns.

Breaking changes

selectRaw() now works like select(), meaning it replaces all existing columns, and doesn't get added to them.
addSelect() now adds table.* to queries if no columns were previously set.
Not entirely sure what the implications of my changes to HasManyThrough. I've got the tests passing, but I'm still not super confident in it.

@reinink maybe better that you sent this in as a WIP pr and move it to "ready for review" once it's ready?

I didn't even mean to submit it. 🤦🏻♂
My goal was to PR this against my own repo...but for some reason that didn't happen.
How do I change it to a "WIP"?

@reinink you can't change that once it's submitted. You'll have to close this and re-submit as WIP.

Closing this for now. It's mostly just an experiment for @staudenmeir to review.

I came here because I observed that addSelect(), without any other explicit selection, removes the default set of attributes. I understand the PR is merged, but I still see this behavior. I'm on a fresh v6.15.0.
For now I additionally work around it with a conditional
if ( ! $builder->getQuery()->columns) {
    $builder->addSelect('*');
}

If I apply multiple scopes and each added select('*') without condition, they would overwrite previous additions. I demoed this here: https://github.com/michapietsch/laravel-add-select-preserve-default-attrs
A thought regarding "more work":
I'm afraid it would get even more confusing, if addSelectSub() were to preserve the columns, but addSelect() would still replace the existing ones.

I understand the PR is merged, but I still see this behavior.

Negative, this PR did not get merged. It was simply something that I was experimenting with, but ultimately decided to close.
I actually spent a ton of time trying to clean this behaviour up in Laravel. However, for better or worse, I think it's here to stay. There is a lot of existing code, both within Laravel, but also within apps built with it, and even packages for Laravel, that depend on the current behaviour.
So while I agree the current behaviour is a bit wonky, I'm not sure I'm personally prepared to fight this battle...at least not at this time.

Ah, my bad, I looked at the referenced PR, and then confused the two.
Have you ever experienced problems with adding the select('*'), or, from your experience, are there drawbacks or limitations to just evaluating $builder->getQuery()->columns)?

Yes, I have experienced those issues, which is why I basically never do a select() or addSelect() in any of my scopes, unless it's within a subquery (which won't affect the rest of the primary, parent query).
And no, I don't see any issues checking columns. I've done this before, as you can even see in my Advanced Eloquent package here. (Note, this package is mostly not needed anymore, since I added all the subquery stuff to Laravel core in V6.)

Ok, thanks! I just had two local scopes with sub selects clashing. But it's no big deal once one's aware.
Thanks for your work and digging into it!


find-packages not working in 1.16.0

The web request shows that the data is retrieved.

I am able to reproduce the problem with <IP_ADDRESS> on my work computer. When I build the executable myself with latest, I am unable to reproduce.

My announcement post for Paket.PowerShell is written and queued up as soon as this and #886 are fixed. :)

Related to #888.

This was fixed in 0.17.0.


Wrong git repo in SOME ipynb---- https://github.com/samthiele/hylite_demo2.git

01_The_basics.ipynb
01_The_basics.ipynb_Notebook unstarred
Changes will not be saved
Setup GoogleColab environment
Install hylite and download tutorial data
[1]
3s
! git clone https://github.com/samthiele/hylite_demo2.git
account_circle
Cloning into 'hylite_demo2'...

Thanks for the heads-up. This should be fixed now?

Sure not, sometimes. Low low priority)
On Tue, 23 Jan 2024, 14:22 Sam Thiele, @.***> wrote:

Thanks for the heads-up. This should be fixed now?
—
Reply to this email directly, view it on GitHub
https://github.com/hifexplo/hylite/issues/10#issuecomment-1905834352,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAUM2WHSD2HPMOFHEARRI5DYP6MN3AVCNFSM6AAAAABCFJQJSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVHAZTIMZVGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Is done; please check everything works for you :-)


Docker / K8 --features BLOOD_PRESSURE

Hi, not so much of an issue as not well described.
How do I add the --features BLOOD_PRESSURE in either k8 or Docker containers?
Thanks,
Brisnick

Hi yes, it's not well described (yet).  You will have to pass extra parameters to the docker entrypoint by completely replacing it.
ex ENTRYPOINT ["withings-sync", "--verbose", "--features BLOOD_PRESSURE"]

Thanks. I got this working with k8s-deployment.yaml by changing to:
    command: ["/bin/sh"]
    args: ["-c", "while true; do date; withings-sync --features BLOOD_PRESSURE; echo; sleep 21600; done"]

But with k8s-jobs.yaml I couldn't get the same to work:
     containers:
      - args: ["--features BLOOD_PRESSURE"]
        #- -v
        #- --features BLOOD_PRESSURE

2024-12-22 14:21:36 usage: withings-sync [-h] [--garmin-username GARMIN_USERNAME]
2024-12-22 14:21:36                      [--garmin-password GARMIN_PASSWORD]
2024-12-22 14:21:36                      [--trainerroad-username TRAINERROAD_USERNAME]
2024-12-22 14:21:36                      [--trainerroad-password TRAINERROAD_PASSWORD]
2024-12-22 14:21:36                      [--fromdate DATE] [--todate DATE] [--to-fit] [--to-json]
2024-12-22 14:21:36                      [--output BASENAME] [--no-upload]
2024-12-22 14:21:36                      [--features BLOOD_PRESSURE [BLOOD_PRESSURE ...]]
2024-12-22 14:21:36                      [--verbose]
2024-12-22 14:21:36 withings-sync: error: unrecognized arguments: --features BLOOD_PRESSURE
Any ideas how to set this up as a k8s cronjob?

In case this helps anyone else, I think I have cracked it. My args should have been in the k8-jobs.yaml:
containers:
- args: ["--features",  "BLOOD_PRESSURE"]
I will reset everything up in the next day or two and comment again that it all works.
Cheers.


Remove APIs that were deprecated before 0.8

Pytorch core is moving to a 2-version deprecation cycle, and so are we.
This PR removes APIs that were removed before or on 0.8, released 1.5 years ago. We're going to release 0.12 so technically we could remove stuff up to 0.10, but we're just being extra nice.

D34048252 is green internally, this should be good to merge


Skip failing test case

This test breaks all commits, likely cause by TLS certs expired. This
means all past commits will no longer pass tests, and all new commits
will be blocked. We should disable this test for now until it can be
properly fixed.
https://github.com/istio/istio/issues/13668
If a real fix is applied before this gets in then close this, but this is blocking every other dev currently

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: howardjohn
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: incfly
If they are not already assigned, you can assign the PR to them by writing /assign @incfly in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

security/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/assign  @diemtvu @incfly @myidpt @quanjielin @wattli

/cc @lei-tang

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: howardjohn, quanjielin
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

security/OWNERS [quanjielin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: howardjohn, lei-tang, quanjielin
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

security/OWNERS [quanjielin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@howardjohn FYI it appears that the skip doesn't seem to take affect for the codecov task. Not sure why that would be.

It runs the previous commit which fails so we need to override

These test failures are due to that the GKE cluster hosting the Vault server on the GCP endpoints-jenkins project were deleted. I have to find a GKE cluster that is reliable, re-create a Vault server, and update the test cases to use the IP address of the new Vault server. In addition, all Vault related user guides and integration tests need to be updated to use the new IP address.

@howardjohn @nmittler Is there a GKE cluster I can use to re-create a Vault server for the Vault related tests in Istio CI/CD and for the Vault related user guides on istio.io?

@howardjohn: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
f11f3f60947505605c728c5c358f7f109c9923dc
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

With https://github.com/istio/istio/pull/13675 that disable SDS Vault integration test before Vault server is recovered, istio-integ-k8s-tests should pass.

https://github.com/istio/istio/pull/13683 fixes the failed unit tests of Vault CA integration.


Resolves #43

Ended up implementing my own change request (#43). It builds on #42, but I decided to separate the pull requests, as this change introducing minor breaking API changes, whereas #42 just fixes odd behavior.
As mentioned in the issue, this change changes input type of the validator to match the generic type of Input.
Personally, and in my use cases, this is a desired change, since when the parsed value is already an i32, then I would like to validate on that i32 as well, instead of having to parse it a separate time.
Example:
Input::<i32>::new()
//      ^^^
    .validate_with(|input: &i32| -> Result<(), &str> {
//                          ^^^
        todo!()
    });

Input::<char>::new()
    .validate_with(|input: &char| -> Result<(), &str> {
        todo!()
    });

That merge did not go as expected. However, the comment has been removed.


Slowdown from BufRead

To address #489, vim-plug now triggers BufRead autocmd when a plugin is loaded by on condition. However BufRead autocmd considerably slows down the loading process especially when editing a large file. Can we do better?

One idea is to check if the plugin contains ftdetect or ftplugin files.


Changing Status and closing/reopening tickets with notes

What about providing change status option as a different button rather than giving it inside edit page?
And each time someone changes the status have to leave a note on his/her action (Also for closing and re-opening the ticket).
Just a thought!

This kind of history is going to be available in v2.
If you want custom buttons, you can just override vendor views.

Thank you, Will wait for the update even though I have managed to meet my requirement for now. I added new button as update status, where a user can manage status (including Reopen and close ticket) and record the history of changes with description.


The Elder Scrolls Online, no rendering device with dxvk 0.65

The game works fine with dxvk 0.64. With 0.65 the game fails to start, showing a dialog with a no rendering device message,
System information

GPU: RX560
Driver: Oibaf ppa Mesa
Wine version: 3.13 staging
DXVK version: 0.65

The game is free for 3 days.

With this amount of information I can only point you to #369.

i installed 0.65 again and did  run winecfg and now it works.


[Event Request] Codeunit 6620 "Copy Document Mgt." - OnAfterCopySalesDocSalesLineArchive

Please add parameter to the event OnAfterCopySalesDocSalesLineArchive.
[IntegrationEvent(false, false)]
local procedure OnAfterCopySalesDocSalesLineArchive(FromSalesHeaderArchive: Record "Sales Header Archive"; var ToSalesHeader: Record "Sales Header"; ToSalesLine: Record "Sales Line"; var TransferOldExtLines: Codeunit "Transfer Old Ext. Text Lines")
begin
end;

                    OnAfterCopyArchSalesLine(ToSalesHeader, ToSalesLine, FromSalesLineArchive, IncludeHeader, RecalculateLines);
                end;
            until FromSalesLineArchive.Next() = 0;
        OnAfterCopySalesDocSalesLineArchive(FromSalesHeaderArchive, ToSalesHeader, ToSalesLine, TransferOldExtLines);
    end;
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 47404.


added style to package.json

This would help browserify users get the chartist styles without guessing the current path.

In reference to this discussion https://github.com/twbs/bootstrap/pull/12441 I agree to add this to the package json. Thanks for the PR!

Thanks to you for merging!


adding an code sample and rule for extract processing of async events -

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area plugin-sdk

/area tests

What this PR does / why we need it:
Current documentation is not complete
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: an1245
Once this PR has been reviewed and has the lgtm label, please assign mstemm for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Use KUBEVIRT_NO_BAZEL env var instead of GO_BUILD

GO_BUILD env var becomes redundant and it can be dropped.

What this PR does / why we need it: Just a small cleanup in the build scripts.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer: N/A
Release note:

NONE

/test pull-kubevirt-build

/test pull-kubevirt-generate

/lgtm

@dhiller Can you have a look?

/retest

/test pull-kubevirt-e2e-k8s-1.20-sig-compute

/test pull-kubevirt-e2e-k8s-1.21-sig-compute


Added mission statement in the charter, pulled from README

We've tended to have projects embed the mission statement in the charter lately, so pulling what was in the README to add here.
Signed-off-by: John Mertic<EMAIL_ADDRESS>

I'd recommend that @lgritz - I can be on that call if it's helpful.

I'm sure we can handle it, we'll just do it at next week's TSC meeting.

Sounds good - keep me posted

Approved by the TSC by vote on 2020-12-10

Thank you Larry - having the series agreement filed now.


Fixed #32549 -- Added check for nested empty Q objects

Fixed ticket-32549
Contains pull #14126 to avoid a regression in logical operations between query expressions and empty Q objects.

Closing per ticket.


The evaluation of MotionAGFormer-L with GT 2D points as input.

Thank you for your great work. We would like to evaluate the MPJPE metric of MotionAGFormer-L with GT 2D points as input, and I was wondering if you could provide the weights corresponding to an MPJPE of 17.3. Thanks！

@poker-xu Sorry but I'm afraid the I removed the checkpoints of that due to shortage of space. In case you're needing that because of using it in a application, note that it is trained when the 2D pose sequence as input is perfect and has no estimation noise, which is achieved by projecting 3D points into 2D. Although the model achieves a better performance, it should generally be worse at inference time since once you give it 2D pose as input, it is estimated from a 2D estimator that is noisy but the model is not robust against noise since it hasn't seen noisy 2D pose throughout training.


Bug fixes needed to support interchangeable use of "/" and "" in file paths on Unix-like platforms

Note:

This issue is meant to supersede #8158 and #6833; if there's consensus that this issue covers both the latter (in a more focused manner), they should be closed.

From the committee decision at https://github.com/PowerShell/PowerShell/pull/8587#issuecomment-477375667:

Filesystem accepting both / and \ on all systems is an explicit cross platform experience decision for PowerShell.

Given that it's currently impossible on Unix-like platforms - where \ is a legal filename character - to access or wildcard-match filenames with embedded \ chars., the following fixes are needed:

Wildcard matching must able to match \ chars., namely via ? or * or [\].

Note that inside [...], \ shouldn't require escaping, analogous to [.] matching a literal . in a regex.

-Path and -LiteralPath arguments must support `-escaping of \ chars. to request their literal treatment.

The .PS* provider property values (.PSPath, .PSParentPath, .PSChildName) must reflect the escaped path.

To-native-path conversions such as with Convert-Path must remove the escaping.

Note:

Even the above doesn't address the awkwardness of the - unescaped - .FullName value of System.IO.FileSystemInfo not being directly usable with the filesystem provider; e.g., with the provider bug fixed, something like (Get-ChildItem "$HOME/a\b").FullName would return something like /Users/jdoe/a\b - unescaped.

Similarly, native paths from outside sources with embedded \ - e.g., read from a file - will break in PowerShell commands, unless explicit escaping with -replace '`', '\`' is performed.

` as the escape char. means that it requires doubling inside "..."  and therefore also in unquoted arguments in order to be passed through; i.e., the following calls would be equivalent and match a file literally named a\b:

Get-Item 'a`\b'
Get-Item "a``\b" # !!
Get-Item a``\b # !! implicitly treated like a "..." string

Handling ` instances that precede a char. other than \ gets quite tricky:

Literal paths: So as not to break the existing ability to match ` literally in paths, ` must be special only before \ and before ` itself. This follows the model of \ use in double-quoted strings in Bash, but introduces the awkwardness of needing to interpret 'a`b' and  'ab' `` the same (similar to how "a\b" and "a\\b" are equal in Bash).

Wildcard paths: Wildcard matching itself always requires doubling of ` for literal use; e.g.,
'a`b' -like  'a`b' is $false, and only 'a`b' -like  'a``b' is $true (edge case: 'a`' -like  'a`' is also $true - the trailing syntactically incomplete use of ` is interpreted as a literal).

However, use of wildcards with the filesystem provider:

currently makes Get-Item -Path 'a`b' match a file literally named a`b, even though it shouldn't.
currently doesn't find a match with  Get-Item -Path 'ab' and neither with Get-Item -Path 'a?' , even though it should.

In other words: wildcard handling by the filesystem provider is currently broken - this may be related to #7999.
While falling back to literal interpretation is perhaps useful, especially given that -Path is the default parameter, this should be fixed, separately.

Steps to reproduce
On macOS or Linux, run the following Pester tests:
# Note: -Skip isn't yet supported at the level of Describe and Context blocks.
#        See https://github.com/pester/Pester/issues/442
if ($env:OS -eq 'Windows_NT') {
  Write-Warning "Tests apply to Unix-like platforms only" }
else {
  Describe "Support for backslashes in Unix filenames" {
    BeforeAll  {
      Push-Location TestDrive:\
      # File with literal backslash in its name.
      touch 'a\b'
      $nativePath = ($PWD.ProviderPath -replace '/$') + '/' + 'a\b'
      $escapedName = 'a`\b'
      $escapedPath = ((Get-Item .).PSPath -replace '/$') + '/' + $escapedName
      # File with literal backtick in its name.
      touch 'a`b'
    }
    It "Backslashes can be matched with wildcards" {
      (Get-Item -Path 'a?b').Name   | Should -BeExactly 'a\b'
      (Get-Item -Path 'a*b').Name   | Should -BeExactly 'a\b'
      (Get-Item -Path 'a[\]b').Name | Should -BeExactly 'a\b'
    }
    It "Backtick-escaped backslashes match literal ones in filenames" {
      (Get-Item -Path 'a`\b').Name | Should -BeExactly 'a\b'
      (Get-Item -LiteralPath 'a`\b').Name | Should -BeExactly 'a\b'
    }
    It "Backticks not preceding a backslash or backtick are literals in literal paths" {
      (Get-Item -LiteralPath 'a`b').Name | Should -BeExactly 'a`b'
    }
    It "Doubled backticks are also literals in literal paths" {
      (Get-Item -LiteralPath 'a``b').Name | Should -BeExactly 'a`b'
    }
    It "Backtick-escaped backticks must be recognized as a literal backtick in wildcard paths" {
      (Get-Item -Path 'a``?').Name | Should -BeExactly 'a`b'
    }
    It "Provider properties contain escaped paths" {
      (Get-Item -LiteralPath 'a`\b').PSChildName | Should -BeExactly $escapedName
      (Get-Item -LiteralPath 'a`\b').PSPath | Should -BeExactly $escapedPath
    }
    It "Convert-Path removes the PS-specific escaping" {
      Get-Item -LiteralPath 'a`\b' | Convert-Path | Should -BeExactly $nativePath
    }
    AfterAll {
      Pop-Location
    }
  }

}

Expected behavior
All tests should pass.
Actual behavior
All tests except "Backticks not preceding a backslash or backtick are literals in literal paths" fail.
Environment data
PowerShell Core 6.2.0-rc.1

If we ever get around to https://github.com/PowerShell/PowerShell/issues/5785, we can decide what the default behavior should be with regards to slashes.

@SteveL-MSFT, can you please clarify?

with regards to slashes

Did you mean backslashes?

If we ever get around to #5785

Does this mean that, for the time being, explicit cross platform experience translates to:

"You can use \ and / interchangeably on all platforms, as long as you don't expect filenames with embedded \ chars. to work on Unix-like platforms"?

Do you feel that there are aspects of #8158 and #6833 not covered here?

If so which?
If not, can you please close them?

I'm using 'slashes' as a generic term for both forward and backslashes.
Yes, current expectation is that you can use \ and / interchangeably on all platforms, except where filename/directoryname contains \.
https://github.com/PowerShell/PowerShell/issues/6833#issuecomment-389690161 summarizes the PS-Committee stance.
Unlike the square brackets, it's unclear to me how often people use the backtick `  or the backslash \ within file/directory names.
I'm ok closing the older issues as dupes of this one (although it's a bit backwards...) as I believe this does summarize the issues.

Thanks, @SteveL-MSFT.
Good point that use of  ` and \ in filenames may be rare, but it's still problematic to make native capabilities inaccessible (currently) and providing a workaround is both a nontrivial implementation effort and a pitfall for and burden on those who do wish to use \.

I'm ok closing the older issues as dupes of this one (although it's a bit backwards...

I don't think that's problematic, as long as the later issue properly references and summarizes the earlier one(s), and the benefit is that future readers are spared the need to cull information from lengthy exchanges and potential confusion over what the way forward is.


obs data information lost in the table in master

The variable name was truncated and lost the obs data information. The "row_name" in viewer was changed incorrectly.
@zshaheen Please hold the release before this issue is solved. Thank you!
Old_table variable format:

The one from master:

@chengzhuzhang View your old code that was in acme_diags_driver.py here

@chengzhuzhang I think I fixed this in 52ac7b8eaf8e612c50622683887e4bf0a75e4799. This was my fault, b/c I didn't notice the change you made when I ported over the code. It should all be good now:
Old code:

Code from 52ac7b8eaf8e612c50622683887e4bf0a75e4799:

If you can test it and let me know if it's good, that would be great. Then we can release if there aren't any other issues.

@chengzhuzhang Actually, I fixed more stuff in 42a3d8d4f81f8951ae326ca7484b5aafacea53b2
Before the fix:

After:

I think it's good now. Again, just let me know what's good.

The fix is as I expected:) thank you for fixing it quickly! I think it is all good.


Add release steps

Closes #38
Adds a job to create releases when new tags are pushed. I looked at the flux2 configuration for reference, but much of that does not apply to this project (ie docker and brew builds), so this is closer to a default goreleaser config.

Please use the same naming conventions, architectures and semver format as flux2. If we want to integrate the ui into flux cli then the release assets must be the same.

@stefanprodan Changed the template to match the flux2 repo.
I prefix'd the binary name with flux_webui, since a binary named webui is too vague.


Dropdown not displayed properly at the bottom of the screen

When the page is scrolled down that much that the dropdown doesn't completely fit on it, the background and other styles disappear.

It only happens apparently with the pointing dropdowns. I think you shouldn't care that much about the style, but about displaying the dropdown in the proper direction, as with the other kinds of dropdowns.
I hope this was not reported already.
Cheers.

I'm able to replicate this in chrome, unsure of cause.

Sorry for not clarifying that, I was using Firefox 39.0 at the moment I took the screenshot.

Fixed in 2.1


unified-test-documentation/dasharo-security/200-tpm-support: Fix comm…

…and to verify tpm presence
Signed-off-by: Igor Bagnucki<EMAIL_ADDRESS>

@macpijan @IgorBagnucki  I rewrote the test case and add:

Command for checking the version of the tpm2_tools package.
Two test options: what to do if tpm2_tools version is 4.0 or higher and what to do if not.

According to the tpm2-tools changelog, this command has been re-named in version 4.0 (https://github.com/tpm2-software/tpm2-tools/blob/4.0/CHANGELOG.md).


samples: lwm2m: Add support for Connection Manager

Using Connection Manager, it's easy to run lwm2m sample on devices supporting different connectivity technologies (for example, Wi-Fi and LTE).

@rlubos I made the requested changes. Please re-check


Auto-growing Textareas [feature request]

I found the Textarea component. It would be great if it had a prop to enable/disable auto-growing.

I have created one.
Autosize textarea

I have created one. Autosize textarea

Hey @hsuanyi-chou thanks for putting this together! Just chiming in that I had an edge case in my app that's different from the examples on your site and I wanted to share what worked for me to make it look right:
I have a very long placeholder. But when the component rendered, its height per the Inspector was always 54px. Not 52 like the default for the minHeight prop, nor 58 like I was passing as minHeight to the textarea. Odd. Either way, it was clear minHeight wasn't being respected, at least on mount, and I needed to do something to force a that first height calculation.
I have never felt like I fully understood refs, but theoretically, the useAutosizeTextArea() hook should fire first when the component renders and again once textAreaRef becomes not null, which I assumed would happen immediately, since the ref is set in the JSX. Sort of like a useEffect runs right after mount. But this appears to not be the case.
When the component renders, textAreaRef = null, and triggerAutoSize = "", as console logged from the useAutosizeTextArea() hook's useEffect(). Clicking into the textarea does not change these values, in fact there is no further console log until either a) I type something, or b) I blur focus out of the textarea, at which point the height calculation runs and everything looks right from then on. I have other normal text input fields on the same page, and clicking into (then blurring from) them also triggers the ref to change, and the height to recalculate.
So clearly I needed to make something change its value on mount, because the component wasn't going to run the calculation on its own, perhaps because the ref gets set silently? Seems weird.
Here's what I did that worked:
I set triggerAutoSize's useState() to " " (with a space) to start. Then in the useAutosizeTextArea() hook's useEffect() I removed the if so setTriggerAutoSize will always run when the component mounts, and I made sure it would pass an empty string when value is undefined.
It appears that a post-mount change to triggerAutoSize will fire useAutosizeTextArea(), which will pick up on the newly-set textAreaRef, and set the initial height of the textarea to fit my multiline placeholder text!
An annoying behavior but an easy fix :) Cheers!

@tatwater
Hi, can you provide a minimal reproducible example?
There's an offset in the useAutosizeTextArea.
The 2px offset is because of the border of textarea.

I have created one. Autosize textarea

Thanks a lot!🎉

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

I have created one. Autosize textarea

Absolute ledgend.

Just as an aside if others are attempting to have the text area start out as a smaller or larger size, you can make a very simple adjustment. In your component file, adjust the <textarea /> to have a height of your choosing. Here's an example:
return (
      <textarea
        {...props}
        value={value}
        ref={textAreaRef}
        className={cn(
          "flex h-[42px] w-full rounded-md border border-input bg-background px-3 py-2 text-sm ring-offset-background placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:cursor-not-allowed disabled:opacity-50",
          className,
        )}
        onChange={(e) => {
          setTriggerAutoSize(e.target.value);
          onChange?.(e);
        }}
      />
    )

Here I set the height to 42px. Then once the text is passed on the useEffect() , the proper height is given.

I can solve this on NextJS with Tailwind CSS, I think it can use on any JS framework.
<Textarea
  className="overflow-hidden min-h-9 h-9"
  onInput={(e) => {
    const target = e.target as HTMLTextAreaElement;
    target.style.height = "0px";
    target.style.height = target.scrollHeight + "px";
  }}
/>

Here is the updated version using the reference. Now, the input textarea will expand as well.
  <Textarea
        ref={(textarea) => {
               if (textarea) {
                    textarea.style.height = "0px";
                   textarea.style.height = textarea.scrollHeight + "px";
                         }
                   }}
  />

This is perfect. Tried a few solutions, this is absolutely smooth. Cheers1

@hsuanyi-chou That works great. Thanks so much for sharing!