Disable Idle/Dynamic Separation in Kepler

Add flag to allows users to disable Idle/Dynamic Separation in Kepler, so Kepler only exports direct power measurements. Idle/Dynamic Separation is faulty and also complicates the validation process.

This is an interesting statement. Could you elaborate why this is faulty ? Overall I agree with the fact that it is easier to only have one value.

From a previous test, idle power never goes down. It seems to always select the maximum "total power" and sticks to it. So what happens is if you stress the cpu to 100%, idle will adopt this power and sticks to it. When the stressing stops, the total power from rapl goes down but idle assigned by kepler does not change. When dynamic is calculated with max(total power - idle power, 0), dynamic is stuck at 0 after the first stress and idle is stuck at the highest power level.

Flag has been added so the issue can be closed.

Could you give the link to the PR that add the flag please ? Thanks


DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.

Framework7 version: [4.2.2]
React.js version: [16.0.0]
Platform and Target: [any]
Live Link or JSFiddle: https://jsfiddle.net/alimamed/zjkc8udr/

Describe the bug
DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.
To Reproduce
Steps to reproduce the behavior:

Open Fiddle (you can use this link for full view https://fiddle.jshell.net/alimamed/zjkc8udr/show#)
Click on "menu" link
Click on "list" link in panel
Click each Item on master page
Click on "menu" link again
Click on "about" link in panel
Click on "menu" link again
Click on "list" link again - you get the crash

Spent some time on debugging but could not understand the behaviour that leads to the error.

Hi, check the "red" note in this section http://framework7.io/docs/view.html#master-detail
When navigating from master page to something else (like in your case to another master page), we need to use reloadAll on router link. Because new Master page suppose to have other Detail pages. So it needs to be reloaded. Here is the working example https://jsfiddle.net/kvxpcnu3/
And I can also recommend to use reloadDetail on links that load detail pages within master

Great thanks


Add "shouldComponentUpdate" support as needed

With https://github.com/Microsoft/BotFramework-WebChat/pull/257 the major offender (typing in shell forced re-render of entire history) is now fixed. Let's hold off on more until we know there's a performance problem to solve.


DPL-083 Improve workflows to better handle release versioning

Part of https://github.com/sanger/deployment/issues/71

Could rename .github/workflows/check_release_name_bump.yml to .github/workflows/check_release_version.yml to match other repos


Add CI to error on FIPS checksum changes

The current CI workflow for FIPS checksums (compute-checksums) does not
error out when FIPS checksum files need to be updated.
This CI workflow errors out when the checksum files change; indicating
that the PR needs to update those files.

Checklist

[ ] documentation is added or updated
[X] tests are added or updated

It appears that the checksums are already out of date...

The current workflow adds a label to indicate fips checksum changes...
I guess it's a matter of taste what's the better signal

The current workflow adds a label to indicate fips checksum changes...
I guess it's a matter of taste what's the better signal

I haven't seen this label? Is there an example somewhere? The tip of master needs to have the hashes recalculated; but I haven't seen a label for it? I don't know where to look.

The current workflow adds a label to indicate fips checksum changes...
I guess it's a matter of taste what's the better signal

I haven't seen this label? Is there an example somewhere? The tip of master needs to have the hashes recalculated; but I haven't seen a label for it? I don't know where to look.

https://github.com/openssl/openssl/pull/16019

#16019 or more generally all PRs with
severity:fips-change

OK, so it only shows up on PRs that actually caused the failure?
As @levitte said, it depends on one's preferences. The label seems a little low-key to me. A CI failure (e.g. "make update" or the "nits") is a bit more obvious, but would impact all future PRs until it is fixed.
Is there any indicator or dashboard that indicates if the FIPS checksums needs to updated? AFAICT, once a PR with that label has been merged, there's no indicator that the checksums need to be updated.

The label is far better than getting errors and incessant merge conflicts.
Something a bit more visible would be good however.

Treating "FIPS checksums need updating" as less noticeable than doc-nits seems wrong.

We no longer require the FIPS checksums to be updated by PRs. This was a deliberate change. It caused far too many conflicts. We now update the checksums as part of the release script:
https://github.com/openssl/openssl/blob/d19dacd55f03cb36974fe69e6649bca16d80ab35/dev/release.sh#L331

We no longer require the FIPS checksums to be updated by PRs. This was a deliberate change. It caused far too many conflicts. We now update the checksums as part of the release script:

For beta1, the release script didn't properly update ordinals in util/lib*.num. (So, I apologize for my lack of confidence in the release script.)
In a way, this implies that there might be beta releases at a regular cadence?

For beta1, the release script didn't properly update ordinals in util/lib*.num. (So, I apologize for my lack of confidence in the release script.)

Like lots of the code, the release script is itself in "beta". But it did correctly update the FIPS checksums:
8af25d0a3bb

In a way, this implies that there might be beta releases at a regular cadence?

Not really. I do not expect a regular cadence of beta releases. The beta releases are "release candidates". I hope we will move to final release asap.

I'm going to close this, but it sounds as though maybe the label is a bit too subtle. Something like this might be more useful for those who fork OpenSSL to make sure they don't much with code within the FIPS boundary.


Update main-bundle.js

main-bundle does not need to be updated in PR, it is compiled by me in the releases.


Add containerized option to kubelet binary

@vmarmol Now with stub file

kicked shippable

LGTM, did you get a chance to run hack/build-cross.sh btw?

@vmarmol I had breakages in that script, even in master.  Is it possible that I did something wrong?

LGTM, verified it builds. Thanks @pmorie!

:+1:


Add responsive support

Instead of fixed width is there any way to make dropdown responsive to adjust different view port?

You can do what you'd like with the CSS. :)

@Robdel12 Could you please provide some gist examples?

@Purush0th  try this
.dk-select, .dk-select-multi {
width: 100% !important;
}

What @arunsathyan01 said with the addition if you change this file to what ever width you'd like. That way you don't need the !important.
.dk-select,
.dk-select-multi {
[..]
  width: 200px;
[..]
}


Expand code coverage to 100%

These are the features yet to test:

the subscription to the creation of a cat in the resolver;
the auth guard implementation for the cat.

cats.guard.ts still has insufficient coverage


fastlane pilot add "Some operations failed: undefined method `admin?' for nil:NilClass"

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I have read the Contribution Guidelines

Issue Description
trying to add email to test flight with the below command
fastlane pilot add<EMAIL_ADDRESS>-a com.tst.testing -u<EMAIL_ADDRESS>Complete output when running fastlane, including the stack trace and command used

You can use: --capture_output as the last commandline argument to get that collected for you

ERROR [2017-07-28 12:22:57.32]: undefined method admin?' for nil:NilClass /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/fastlane_core/lib/fastlane_core/ui/interface.rb:131:in user_error!': [!] Some operations failed: undefined method admin?' for nil:NilClass (FastlaneCore::Interface::FastlaneError) 	from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/fastlane_core/lib/fastlane_core/ui/ui.rb:14:in method_missing'
from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/pilot/lib/pilot/commands_generator.rb:38:in handle_multiple' 	from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/pilot/lib/pilot/commands_generator.rb:95:in block (2 levels) in run'
from /Library/Ruby/Gems/2.0.0/gems/commander-fastlane-4.4.5/lib/commander/command.rb:178:in call' 	from /Library/Ruby/Gems/2.0.0/gems/commander-fastlane-4.4.5/lib/commander/command.rb:178:in call'
from /Library/Ruby/Gems/2.0.0/gems/commander-fastlane-4.4.5/lib/commander/command.rb:153:in run' 	from /Library/Ruby/Gems/2.0.0/gems/commander-fastlane-4.4.5/lib/commander/runner.rb:476:in run_active_command'
from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:64:in run!' 	from /Library/Ruby/Gems/2.0.0/gems/commander-fastlane-4.4.5/lib/commander/delegates.rb:15:in run!'
from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/pilot/lib/pilot/commands_generator.rb:159:in run' 	from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/pilot/lib/pilot/commands_generator.rb:12:in start'
from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/fastlane/lib/fastlane/cli_tools_distributor.rb:58:in take_off' 	from /Library/Ruby/Gems/2.0.0/gems/fastlane-2.49.0/bin/fastlane:20:in <top (required)>'
from /usr/local/bin/fastlane:23:in load' 	from /usr/local/bin/fastlane:23:in '
Environment
Please run fastlane env and copy the output below. This will help us help you :+1:
If you used --capture_output option please remove this block - as it is already included there.
🚫 fastlane environment 🚫
Stack

Key
Value

OS
10.12.5

Ruby
2.0.0

Bundler?
false

Git
git version 2.11.0 (Apple Git-81)

Installation Source
/usr/local/bin/fastlane

Host
Mac OS X 10.12.5 (16F73)

Ruby Lib Dir
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib

OpenSSL Version
OpenSSL 0.9.8zc 19 Mar 2015

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
8.3.3

System Locale

Error

No Locale with UTF8 found 🚫

fastlane files:
No Fastfile found
No Appfile found
fastlane gems

Gem
Version
Update-Status

fastlane
2.49.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

slack-notifier
1.5.1

CFPropertyList
2.3.5

claide
1.0.2

colored2
3.1.2

nanaimo
0.2.3

xcodeproj
1.5.0

rouge
2.0.7

xcpretty
0.2.8

terminal-notifier
1.8.0

unicode-display_width
1.3.0

terminal-table
1.8.0

plist
3.3.0

public_suffix
2.0.5

addressable
2.5.1

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.5.0

babosa
1.0.2

colored
1.2

highline
1.7.8

commander-fastlane
4.4.5

excon
0.57.1

faraday
0.12.1

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20170404

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

fastimage
2.1.0

gh_inspector
1.0.3

uber
0.1.0

declarative
0.0.9

declarative-option
0.1.0

representable
3.0.4

retriable
3.0.2

mime-types-data
3.2016.0521

mime-types
3.1

little-plugger
1.1.4

multi_json
1.12.1

logging
2.2.2

jwt
1.5.6

memoist
0.16.0

os
0.9.6

signet
0.7.3

googleauth
0.5.1

httpclient
2.8.3

google-api-client
0.12.0

json
1.7.7

mini_magick
4.5.1

multi_xml
0.6.0

rubyzip
1.2.1

security
0.1.3

xcpretty-travis-formatter
0.0.4

dotenv
2.2.1

bundler
1.15.1

faraday_middleware
<IP_ADDRESS>

generated on: 2017-07-28

Looks like your on the system ruby. That might be causing the problem.
Update ruby to a much newer version, reinstall fastlane, and try again.
Easiest way I've found to update ruby is with homebrew, brew install ruby then gem install fastlane

Hey @kamleshkatios - would you mind sharing all of the output from your command line when you run pilot? It would be helpful to see some more context around what is failing. Thanks! @PetrosIchor - Thanks for jumping in to help ❤  ! I'm not sure this error has to do with the ruby version, it seems like something is wrong with fetching the current user from iTC and that it is nil when we are checking if they are an admin and have privileges to add testers. Let me know if you have any other thoughts! 🐙

Let's move the discussion over to https://github.com/fastlane/fastlane/issues/9973


Find References doesn't find React components that are lazy loaded

Does this issue occur when all extensions are disabled?: Yes
Does this issue occur in the Insiders build?: Yes
VS Code Version: 1.71.2
OS Version: MacOS 12.5.1 (MacBook Pro 2019)
The problem is that Find References doesn't find React components that are lazy loaded.
Steps to Reproduce:

Export a React component.

Lazy load it somewhere.

Check that VS Code doesn't find any reference for the component.

Not sure if it's a bug or intended behavior (probably intended), but nonetheless it would be nice that finding references would also find lazy-loaded ones. This forces me to always use standard search (with all the downsides of it) to see if I've used the Component somewhere that references can't find.

Please share an minimal example project the demonstrates  the problem

Sure: https://stackblitz.com/edit/react-ts-wtgage?file=App.tsx
If you right-click on App function in App.tsx and then select "Go to References", it won't find anything despite having it imported (lazy-loaded) and used in index.tsx.


Add support to disable memoization for streams

As we have discussed previously certain types of streams, specifically those triggered by events like Tap and in future KeyPress events should prevent memoization ensuring that the event is actually processed.

Just to summarize our previous discussion, we just need something to mark streams that shouldn't be memoized and then we can add a hash e.g a uuid to make sure the memoization system never sees repeat keys (and therefore won't be able to memoize).

This has now been implemented in form of the transient option on streams.


Roll Flutter Engine from a7decc3e459b to 0a2029cf3fa6 (1 revision)

https://github.com/flutter/engine/compare/a7decc3e459b...0a2029cf3fa6
2023-01-01<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from OOL-jWRElkQ2P3vJz... to AE3lAqTc632VsY14L... (flutter/engine#38588)
Also rolling transitive DEPS:
fuchsia/sdk/core/linux-amd64 from OOL-jWRElkQ2 to AE3lAqTc632V
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Adding github actions

Added github actions for testing bucket requests via cephadm
Minor update to examples

somehow the action did not run

Action failed on my local repo. I am trying to debug it there


Moving images to sites/default directory

Updating the problem shares image magic script to place the generated images in /sites/default/files/images directory. This seems to be a more standard path used across all instances and it is shared across all web heads.
Should fix #4837
@angaither @sheydari-ds

:+1:


Fixing docker tags to publish latest

PR description
Fixing docker tags to publish latest

So I'm missing the subtlety as to why it was failing. Is it because when a release.releaseVersion was present in dockerUpload we were only pushing to hyperledger/besu and not hyperledger/besu:1.3.6?

Regex was slightly off, and I've cleaned up the vars we use so its consistently just 'dockerVersion' now


Initial implementation

This expands upon f0rmiga/initial-impl to work; this has been tested on a KubeCF deployment.
Notable changes:

Fixed up the helm chart to actually work. (Unclear why that was a separate chart, but since it was I just kept going.)
The docker image is now built without the preexisting binary as a dependency (but builds it from source in a separate container instead).  This ensures that we don't end up with things being out of sync (e.g. manually forgetting to rebuild things).
GitHub Actions workflow for building docker image + helm chart, publishing to GitHub Pages.  Modelled after the pipeline in eirinix-helm-release.
Everything is tagged to include the commit hash.

Note that I don't have write access to the repository, hence not just pushing on top of the branch.  I also can't seem to request a review…

@mook-as I think you may need to adjust this PR to use the new kubecf-apps-dns. It was introduced by https://github.com/cloudfoundry-incubator/kubecf/pull/1313.


bundles: Remove unnecessary imports of effect-free modules

Some of these may have once been necessary to enforce an ordering on cyclic imports, but we’ve fixed all of those now.

Merged, thanks @andersk!


Channel control not getting rendered in Firefox

The channel control not showing up in the Firefox. The channel control is not able to render in the same manner as chrome with the slider to select the value for brightness, contrast or hue.
Note: This issue was already there on production before merging the new code.

@rastogi-bhavya I think this is in one of the test cases.. So if the problem has been solved, please close the issue.

I tested for the following URL: https://dev.rebuildingakidney.org/chaise/viewer/#2/Gene_Expression:Image/id=16-2EC6?url=/iiif/2/https%3A%2F%2Fderiva-imaging.isi.edu%2Fimages%2F20160707-hKDCS19_133-JAM-0-30-000-3.tif/info.json&url=/~vipul/chaise-demo/data/20160707-hKDCS19-133-JAM-0-30-00_scene3_fixed.svg&channelName=TL Brightfield&meterScaleInPixels=455504&waterMark=GUDMAP.org
Firefox version: 76.0.1 (64-bit)
As it can be seen in the screenshots that after changing the channel control is rendered, and changing the value causes the image to be changed as is expected.


feat: contentUri to alby boost button

A clear and concise description of what you want to happen
add contentUri field to battery responses of Alby boost button
support for youtube video, youtube channel, vimeo and medium
Type of change

feat: New feature (non-breaking change which adds functionality)

Screenshots of the changes [optional]
Blocker::
we are trying to extract contentUri using battery and store it in payerData (LUD18). boost button calls extractlightningData() function  which runs battery via windows.location but for the endpoint LNURLPay.tsx this will not work as window.location will be chrome://extension...<something>

simplest solution was to use ```extractLightningData function in lnurlpay.tsx to attach contenturi in payment data which has a above blocker
currently i  tried to pass contentUri as a optional argument to webln.lnurl() and extract that parameter from args to payerdata in lnurlpay payerdata
@rolznz wdyt?

Checklist

[X] My code follows the style guidelines of this project and performed a self-review of my own code
[X] New and existing tests pass locally with my changes
[X] I checked if I need to make corresponding changes to the documentation (and made those changes if needed)

From Slack:
Please review Adithya's latest changes. It now includes alby-tools
. I think we can use that to include the contentUri in the LUD18 data by passing the following to ln.generateInvoice:
payerData: {
          contentUri,
        },

getPayerData also looks a bit complicated now, could you think about simplifying it? you could create an empty object first and then check each field, if it is valid, then add it to the object
.

did some research on ipfs providers. here are some ipfs providers we can consider

IPFS Providers
Amount of Storage Space
Centralized/Decentralized

Pinata
1 GB (free)
Centralized

Temporal Cloud
1 GB (free)
Centralized

Fleek
1 GB (free)
Centralized

Infura
5 GB (free)
Centralized

Textile.io
2 GB (free)
Centralized

Filecoin
Varies (decentralized)
Decentralized

Arweave
Varies (decentralized)
Decentralized

Textile Threads
Varies (decentralized)
Decentralized

Skynet
Varies (decentralized)
Decentralized


feat: do not reset the form when a backend error happens

Fixes #36

@erral Merged.
Please tag also @pnicolli and @SaraBianchi when you create some pull-request. I'll be off for some months..


Can't add arguments to clang-format

Would like to say first of all, great plugin by the way.
However I was wondering, how can I add arguments to clang-format? I keep trying to add the --style argument however now whenever I save and guard tries to format, I get an error and it doesn't format anything. Without any arguments, the clang-format works and formats, however I would like to change some factors of the command, hence my arguments.
The arguments do work and actually formats when I use them in the actual command.
Here's my guard config file
local ft = require("guard.filetype")

ft("c,cpp"):fmt({
	cmd = "clang-format",
	args = { "--style='{BasedOnStyle: Google, UseTab: Always, IndentWidth: 8, TabWidth: 8}'" },
	stdin = true,
})
ft("typescript,javascript,typescriptreact,javascriptreact"):fmt("prettierd")

require("guard").setup({
    -- the only options for the setup function
    fmt_on_save = true,
    -- Use lsp if no formatter was defined for this filetype
    lsp_as_default_formatter = false,
})

Thanks!

Does it work without the single quotes?
args = { "--style={BasedOnStyle: Google, UseTab: Always, IndentWidth: 8, TabWidth: 8}" },

Does it work without the single quotes?
args = { "--style={BasedOnStyle: Google, UseTab: Always, IndentWidth: 8, TabWidth: 8}" },

That was it! Thank you so much haha.


Add docker instruction

for issue #24

Those are some clear instructions, good job. I had a couple of small suggestions, otherwise this looks good. Thanks for making this.

Thanks for writing this! I merged it now!


Auto layout is not coming properly

I have created a DB schema using dbml but its not coming as proper. I have 62 tables with 3 Table groups (includes 5-7 tables) and all other tables independent.
Can you please see if this can be corrected? Also glowing all ref by default?

Hello, Bhupesh!
I think you are trying to use "Table groups" - paid feature of dbdiagram: https://docs.dbdiagram.io/table-groups.
It works here just like this:
TableGroup "HubsTestGroup" {
  HubUser
  HubPromocode
}

I added feature for glowing constraints with that logic: you have to click on some regular line and it become red


Split libc into types and impl crates

C libraries (including system ones like glibc or musl) change, but C fundamentals stay put.
I expect many FFI bindings may rely only on fundamental language-provided types like size_t and c_void, not on specific library-provided ones like sockaddr or FILE.
To bring more stability to such use case, libc may be split into something like libc-pure with only type-level things that are expected to change when C as a language changes and libc-sys with everything else. libc itself is just a bunch of re-exports.
Exact splitting line and naming details is left to further discussion. A simple no-brainer constraint maybe that unix:notbsd:fexecve and c_int should appear on opposite sides of the barricades.

There has been discussion about exposing a ctypes crate somewhere: https://github.com/rust-lang/rust/issues/36193

As Rust as a language is somewhat defined in C terms (so inherently relies on it), maybe multiple low-level primitive C types should be in core?
If #[repr(C)] directly mentions C, why not core?

Because core is platform-independent while std is platform dependent (and hence why the ctypes are already in std::os::raw). The only ctype that is platform independent is c_void AFAIK, all others can change, depending on the target platform.

FYI c_void is already in core::ffi - if you only want ctypes, you should check out the cty crate.


Gdx.input.getTextInput window is hidden by the main app windows on Windows 7.

Test case. The app is windowed, the window covers most of the screen space. There is the button to call Gdx.input.getTextInput. No input window appear after pressing the button. If the user press Alt-Tab the input window appears (so it was existing, but just covered by the main window). After that one can close the input window and open it again, works like expected. The problem arise again after fresh app start. The problem appears for me only on Window 7. Mac OS X work like expected.
Another problem is when the user accidentally clicks outside the input window and activated main app window. The input window disappears again without any clear indication that it is still working and how to bring it back.
Probably the best option would be to make it modal and to force it to front.

Quick & dirty solution which works is to place dialog.setAlwaysOnTop(true) right before dialog.setVisible. However it makes the dialog system-wide always on top and does not solve the modality issue. dialog.setModalityType(?) does not work. Probably because it has no Swing parent. I have completely no experience in Swing so can not prepare PR with better solution.

I'm afraid this can't be fixed, as a modal dialog needs a parent frame for it to be made modal. Since we use LWJGL, we don't have that luxury.
The getTextInput methods on the desktop are really just a kludge. In a real application i'd highly suggest to implement text input via scene2d.

I've come to the same conclusion. However just adding one line
dialog.setAlwaysOnTop(true);
right before
dialog.setVisible(true);
makes the problem much less apparent. It's not the best, but it is simple and it works in the case.


Intraday Support for Crypto

I've noticed that support for intraday crypto was removed, or at least I'm novice enough to not know where this is. I'm currently using from alpha_vantage.cryptocurrencies import CryptoCurrencies and can't seem to find intraday in this package. Should I be looking elsewhere, and if not, will support for this feature be returning any time soon?

@XemnasAutomated, since this Python library is just a pass-through of the main Alpha Vantage API, could you please relay functionality-specific questions to<EMAIL_ADDRESS>directly? Thanks!


Update HDF5 format compatibility

This is a proposal to update netCDF4/HDF5 file format controls within netCDF-C.  The recent HDF5 release 1.10.2 in March 2018 provides new options for fine grained control of the HDF5 internal file format.  HDF5 documentation hints at possible performance gains and bug avoidance.
The best format version for universal compatibility is the one created by the latest HDF5 1.8.* library version, currently 1.8.20.  This is the traditional netCDF4 format that was made by all previous netCDF4 library versions, until HDF5 1.10.0 was released in March 2016.  This is the so-called "superblock 2" format.
Objectives

Maintain full backward read and write format compatibility.  Files created through this proposed change should be readable and writable by older software builds, specifically older versions of netCDF and HDF5 libraries.

When possible, avoid "earliest" HDF5 file format selection, loosely known as "superblock 0" format.  This variation is unavoidable when using HDF5 library versions 1.10.0 and 1.10.1, due to lack of fine grained controls.  However, this format variation is avoidable with both older (1.8.*) and newer (1.10.2 and later) HDF5 library versions.

History of HDF5 format control
Current and previous HDF5 versions provide file format control through this function, which takes arguments "low" and "high":
https://portal.hdfgroup.org/display/HDF5/H5P_SET_LIBVER_BOUNDS
All netCDF-C library versions 4.0 through 4.4.0, linked with HDF5 1.8.*, created the traditional "V1.8" or "superblock 2" format using these settings:
low  = H5F_LIBVER_LATEST
high = H5F_LIBVER_LATEST

With the advent of HDF5 1.10.0, more recent netCDF-C versions 4.4.1 through 4.6.1 used the following settings to preserve backward format compatibility.  See #250 for the original discussion. This created "superblock 0" files:
low  = H5F_LIBVER_EARLIEST
high = H5F_LIBVER_LATEST

Proposed format control for new netCDF-C releases
Select format controls based on the detected HDF5 library version within the current netcdf-C library build.
All HDF5 1.8.* versions:  Use the traditional settings to select "V1.8" file format:
low  = H5F_LIBVER_LATEST
high = H5F_LIBVER_LATEST

HDF5 1.10.0 and 1.10.1:  These versions lack the new fine grained control.  Select "earliest" as the only available backward compatible setting.  This will create "superplock 0" files, and avoid making incompatible "superblock 3" files:
low  = H5F_LIBVER_EARLIEST
high = H5F_LIBVER_LATEST

HDF5 1.10.2 (new release) and later:  Select the traditional "V1.8" or "superblock 2" format with this newly available configuration:
low  = H5F_LIBVER_V18
high = H5F_LIBVER_LATEST

Note:  "high = H5F_LIBVER_LATEST" is retained in all cases.  This setting allows the possible development of new HDF5 features such as SWMR, without additional complication of the format control code.

This makes sense.

For anyone interested, here is more detailed documentation on HDF5 format controls and the internal implementation.  This came from the HDF help desk.  The version on the HDF5 website is currently out of date.
RFC-bounds.v4.2018-jan-19.docx

I do recall that that was the case, but that was with the original 1.10 version (as you mention).  I do not recall if this was expected behavior or a bug.  We should re-investigate.

Release announcement for HDF5 1.10.2, 2018 March 30:
https://forum.hdfgroup.org/t/release-of-hdf5-1-10-2-newsletter-160/4247
Full release notes:
https://portal.hdfgroup.org/display/support/HDF5+1.10.2

HDF5 format compatibility was documented in the next netCDF-C release announcement, version 4.4.1, release date 2016 June 28:
https://www.unidata.ucar.edu/blogs/news/entry/netcdf-4-4-1

Format version control is an HDF5 file access property, not a file creation property.  This means that version settings are transient, not permanently embedded somehow in the file.  In particular the superblock number is not a reliable indicator of internal HDF5 object versions, if a file was ever updated after initial creation.
https://portal.hdfgroup.org/display/HDF5/H5P_SET_LIBVER_BOUNDS
For this proposal to work as expected, format settings must be selected every time a file is re-opened for writing, not just during initial creation.  Otherwise you can get a non-optimal mix of object versions within the same file.  That is probably safe, but non-optimal.
In the current netcdf-C release 4.6.1, H5Pset_libver_bounds is called only during create, and not when a file is re-opened.  Please add to this proposal, format control should be selected in both create and read/write modes.  Apply the same three-way algorithm above, for both of these open modes.

This raises an interesting question. Can the superblock version number change
over time. You seem to be saying it can, which surprises me. Have you run a test
case to verify this?

@DennisHeimbigner, my understanding is that the superblock is written one time on file creation, and never again rewritten during normal read or write operations.  There are a few dynamic fields within the superblock that get updated, such as end of file pointer and file lock status.  But the superblock version number and some of the other fields appear to be permanent.

I am withdrawing this proposal.  I will submit a new proposal to include an optional control for 1.10 format forward compatibility.

Re-opening.  This part, update to v1.8 format compatibility, is good as it stands now.  It would be better to get this part done first, then consider a 1.10 compatibility option later.  1.10 compatibility will be problematic.

@Dave-Allured @WardF @DennisHeimbigner
Was there anymore work done for this, i.e. a new proposal submitted? I need to introduce a mechanism for enabling the latest HDF5 version as an option.  Currently, the latest is always set to 1.8:
#ifdef HAVE_H5PSET_LIBVER_BOUNDS
#if H5_VERSION_GE(1,10,2)
    if (H5Pset_libver_bounds(fapl_id, H5F_LIBVER_EARLIEST, H5F_LIBVER_V18) < 0)
#else
        if (H5Pset_libver_bounds(fapl_id, H5F_LIBVER_EARLIEST,
                                 H5F_LIBVER_LATEST) < 0)
#endif
            BAIL(NC_EHDFERR);
#endif

This will not work with the DAOS VOL connector we have developed, which is only able to produce 1.12 compatible versions. I can make it, if NetCDF is creating a file using the DAOS connector, to automatically use the latest HDF5 version. However, if the DAOS container is converted to native HDF5, it will not be readable by HDF5 1.8 or 1.10.

I need to review this issue so I may be repeating some things addressed above as I think out loud below; feel free to tell me that this is a non-issue (I'd welcome such news, frankly :)).
The issue we'll need to consider internally, before accepting this change, would be the impact when files created this way are distributed. From a practical perspective, we want to avoid a situation where netCDF-4 files are being created and distributed (say, through the Unidata THREDDS server) which cannot be read, failing in a non-transparent way, on systems which are using an older libhdf5 install.  The last time I tested this (which was a while ago and will bear re-testing, but it was right after the 1.10.0 release, which caught us off guard), libhdf5 1.8.x-based libnetcdf installs simply reported a generic HDF5 file error.
So as I return to speed on this issue, we will need to particularly focus on the potential impact of broad compatibility, both to avoid creating and distributing files which are indistinguishable from corrupted files, and to avoid the administrative/support overhead on the already-stretched Unidata staff and their support time.
Having stated that I'll start digging in to this, and will also ask @lesserwhirls and @dopplershift for comment.

@brtnfield, no, I never submitted a new proposal.  What I outlined above should still be good for maximal forward and backward compatibility.
I think there is actually a mistake in the current implementation (4.7.4).  This line which you quoted above:
   if (H5Pset_libver_bounds(fapl_id, H5F_LIBVER_EARLIEST, H5F_LIBVER_V18) < 0)

Should actually be:
   if (H5Pset_libver_bounds(fapl_id, H5F_LIBVER_V18, H5F_LIBVER_LATEST) < 0)

This would correspond with the third part of my suggestion above under "Proposed format control", for HDF5 1.10.2 and above.
There may be a reason for the current implementation, but I do not understand it.  This current implementation, combined with newer HDF5 versions 1.10.2 and above, will create only netcdf-4 files with "v1.6 compatibility", represented as superblock zero.  This suggested one-line change should create the desired netcdf-4 files with "v1.8 compatibility", represented as superblock 2.
Also, if the third argument is changed to the suggested H5F_LIBVER_LATEST, then advanced HDF5 features will be unblocked.  This might achieve compatibility with your DAOS VOL connector, without needing further changes.  Would you mind patching netcdf 4.7.4 with this one-line change, and see if this by itself solves your compatibility needs?

@brtnfield, no, I never submitted a new proposal.  What I outlined above should still be good for maximal forward and backward compatibility.
I think there is actually a mistake in the current implementation (4.7.4).  This line which you quoted above:
   if (H5Pset_libver_bounds(fapl_id, H5F_LIBVER_EARLIEST, H5F_LIBVER_V18) < 0)

Should actually be:
   if (H5Pset_libver_bounds(fapl_id, H5F_LIBVER_V18, H5F_LIBVER_LATEST) < 0)

This would correspond with the third part of my suggestion above under "Proposed format control", for HDF5 1.10.2 and above.
There may be a reason for the current implementation, but I do not understand it.  This current implementation, combined with newer HDF5 versions 1.10.2 and above, will create only netcdf-4 files with "v1.6 compatibility", represented as superblock zero.  This suggested one-line change should create the desired netcdf-4 files with "v1.8 compatibility", represented as superblock 2.
Also, if the third argument is changed to the suggested H5F_LIBVER_LATEST, then advanced HDF5 features will be unblocked.  This might achieve compatibility with your DAOS VOL connector, without needing further changes.  Would you mind patching netcdf 4.7.4 with this one-line change, and see if this by itself solves your compatibility needs?

I think @Dave-Allured has a great suggestion above. Can you submit a PR with this one-line change?
There is not a great reason for the current implementation. I think Dave's makes more sense.

I think @Dave-Allured has a great suggestion above. Can you submit a PR with this one-line change?
There is not a great reason for the current implementation. I think Dave's makes more sense.

The CGNS library has the following:
    /* Compatibility with V1.8 */
    H5Pset_libver_bounds(g_propfileopen,
#if H5_VERSION_GE(1,10,3)
          H5F_LIBVER_V18, H5F_LIBVER_V18);
#else
          H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);
#endif

If compatability with hdf5-1.8.X is desired and the hdf5 library is 1.10.3 or newer, then use H5F_LIBVER_V18 for both arguments.  If the library is older or we don't need compatibility with hdf5-1.8.X then use H5F_LIBVER_LATEST for both arguments.
We also are looking at using VOL capabilities...

The CGNS library has the following:
    /* Compatibility with V1.8 */
    H5Pset_libver_bounds(g_propfileopen,
#if H5_VERSION_GE(1,10,3)
          H5F_LIBVER_V18, H5F_LIBVER_V18);
#else
          H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);
#endif

If compatability with hdf5-1.8.X is desired and the hdf5 library is 1.10.3 or newer, then use H5F_LIBVER_V18 for both arguments.  If the library is older or we don't need compatibility with hdf5-1.8.X then use H5F_LIBVER_LATEST for both arguments.
We also are looking at using VOL capabilities...

To be clear, the current behavior by specifying H5F_LIBVER_EARLIEST, H5F_LIBVER_V18 is the superblock will be v0 (v1.6) if no v1.8 format features are being used. If v1.8 format features are being used, which is possible with NetCDF, then the superblock will be v2.
The proposal is to use H5F_LIBVER_V18, H5F_LIBVER_LATEST, which will create, by default, v2 superblock. If a newer format feature is used, which requires a higher format (SWMR, VDS, new references), the lowest (H5F_LIBVER_V18) will be set to V110. The superblock will be v3.
CGNS users had an issue with readers built with hdf5 1.8 not reading the CGNS files (we had used H5Pset_file_space_strategy, a format upgrade), so CGNS is currently enforcing 1.8 compatibilities. This policy will need to be changed because it would be beneficial to use some of the new HDF5 features.
NetCDF users might have the same issue with readers not reading the netCDF files with this change.

To be clear, the current behavior by specifying H5F_LIBVER_EARLIEST, H5F_LIBVER_V18 is the superblock will be v0 (v1.6) if no v1.8 format features are being used. If v1.8 format features are being used, which is possible with NetCDF, then the superblock will be v2.
The proposal is to use H5F_LIBVER_V18, H5F_LIBVER_LATEST, which will create, by default, v2 superblock. If a newer format feature is used, which requires a higher format (SWMR, VDS, new references), the lowest (H5F_LIBVER_V18) will be set to V110. The superblock will be v3.
CGNS users had an issue with readers built with hdf5 1.8 not reading the CGNS files (we had used H5Pset_file_space_strategy, a format upgrade), so CGNS is currently enforcing 1.8 compatibilities. This policy will need to be changed because it would be beneficial to use some of the new HDF5 features.
NetCDF users might have the same issue with readers not reading the netCDF files with this change.

@gsjaardema et al,  I will go into the CGNS case because it is a good example for netcdf.  The SECOND function arg (low =) is the important one for this part of the discussion.  You said:
    /* Compatibility with V1.8 */
    H5Pset_libver_bounds(g_propfileopen,
#if H5_VERSION_GE(1,10,3)
          H5F_LIBVER_V18, H5F_LIBVER_V18);
#else
          H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);
#endif

My understanding is that this will result in v1.10 (superblock 3) files when used with HDF5 library versions 1.10.0, 1.10.1, and 1.10.2, in other words files that are NOT v1.8 compatible, therefore NOT universally readable.  This is because the second arg "low = H5F_LIBVER_LATEST" takes effect for these particular cases, therefore v1.10 format is engaged.
If the CGNS project does not care about possible use of older HDF5 versions, then just mandate HDF5 1.10.3 or later, and there is no problem.  If they DO care, as I do for netcdf, then I suggest a change along the lines of my original proposal above.  At minimum, change the LOW arg in the ELSE clause as follows.
#if H5_VERSION_GE(1,10,3)
          H5F_LIBVER_V18, H5F_LIBVER_V18);
#else
          H5F_LIBVER_EARLIEST, H5F_LIBVER_LATEST);
#endif

This will result in v1.6 (superblock 0) files, which are universally readable, when used with older HDF5 library versions, specifically all 1.8.X versions, also 1.10.0 through 1.10.2.
Now I am no fan of unnecessary downgrading, so I suggest this more fine grained solution would be better.  I think I will also invert the conditionals so that the code will progress sensibly from earliest to latest HDF5 versions.  This corresponds to my original proposal above, except for the final "high = " arg which relates only to advanced features, to be discussed later.  Notice also the tweak for lib version 1.10.2.
#if H5_VERSION_LT(1,10,0)
          H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);     /* all HDF5 1.8 lib versions */
#else
#if H5_VERSION_LE(1,10,1)
          H5F_LIBVER_EARLIEST, H5F_LIBVER_LATEST);    /* lib versions 1.10.0, 1.10.1 */
#else
          H5F_LIBVER_V18, H5F_LIBVER_V18);      /* lib versions 1.10.2 and higher */
#endif
#endif

This will result in the optimal v1.8 (superblock 2) files with ALL HDF5 library versions, older and newer, EXCEPT for library versions 1.10.0 and 1.10.1, which will create v1.6 (superblock 0) files.  Both of these format versions are universally readable.  Reminder, this middle exception occurs only because of a compatibility option that is missing in only those two library versions.
This part of the discussion deals only with basic file compatibility across library versions, and does not address advanced features.  Do you agree with this analysis so far?

@gsjaardema et al,  I will go into the CGNS case because it is a good example for netcdf.  The SECOND function arg (low =) is the important one for this part of the discussion.  You said:
    /* Compatibility with V1.8 */
    H5Pset_libver_bounds(g_propfileopen,
#if H5_VERSION_GE(1,10,3)
          H5F_LIBVER_V18, H5F_LIBVER_V18);
#else
          H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);
#endif

My understanding is that this will result in v1.10 (superblock 3) files when used with HDF5 library versions 1.10.0, 1.10.1, and 1.10.2, in other words files that are NOT v1.8 compatible, therefore NOT universally readable.  This is because the second arg "low = H5F_LIBVER_LATEST" takes effect for these particular cases, therefore v1.10 format is engaged.
If the CGNS project does not care about possible use of older HDF5 versions, then just mandate HDF5 1.10.3 or later, and there is no problem.  If they DO care, as I do for netcdf, then I suggest a change along the lines of my original proposal above.  At minimum, change the LOW arg in the ELSE clause as follows.
#if H5_VERSION_GE(1,10,3)
          H5F_LIBVER_V18, H5F_LIBVER_V18);
#else
          H5F_LIBVER_EARLIEST, H5F_LIBVER_LATEST);
#endif

This will result in v1.6 (superblock 0) files, which are universally readable, when used with older HDF5 library versions, specifically all 1.8.X versions, also 1.10.0 through 1.10.2.
Now I am no fan of unnecessary downgrading, so I suggest this more fine grained solution would be better.  I think I will also invert the conditionals so that the code will progress sensibly from earliest to latest HDF5 versions.  This corresponds to my original proposal above, except for the final "high = " arg which relates only to advanced features, to be discussed later.  Notice also the tweak for lib version 1.10.2.
#if H5_VERSION_LT(1,10,0)
          H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);     /* all HDF5 1.8 lib versions */
#else
#if H5_VERSION_LE(1,10,1)
          H5F_LIBVER_EARLIEST, H5F_LIBVER_LATEST);    /* lib versions 1.10.0, 1.10.1 */
#else
          H5F_LIBVER_V18, H5F_LIBVER_V18);      /* lib versions 1.10.2 and higher */
#endif
#endif

This will result in the optimal v1.8 (superblock 2) files with ALL HDF5 library versions, older and newer, EXCEPT for library versions 1.10.0 and 1.10.1, which will create v1.6 (superblock 0) files.  Both of these format versions are universally readable.  Reminder, this middle exception occurs only because of a compatibility option that is missing in only those two library versions.
This part of the discussion deals only with basic file compatibility across library versions, and does not address advanced features.  Do you agree with this analysis so far?

I think I need some clarification vis-a-vis netcdf backward compatibility.
At the moment, we are implicitly committed to superblock <= 2 so that netcdf
combined with hdf5 1.8.21 (our minimal recommended version) can read all
currently created files. This change appears to replace this commitment to one
in which netcdf can only read certain netcdf files (with superblock > 2) if the
netcdf library is built using some version of HDF5 with version greater than 1.8.21.
Is this correct?

I think I need some clarification vis-a-vis netcdf backward compatibility.
At the moment, we are implicitly committed to superblock <= 2 so that netcdf
combined with hdf5 1.8.21 (our minimal recommended version) can read all
currently created files. This change appears to replace this commitment to one
in which netcdf can only read certain netcdf files (with superblock > 2) if the
netcdf library is built using some version of HDF5 with version greater than 1.8.21.
Is this correct?

@DennisHeimbigner, no, not correct.  For normal netcdf operations, the governing of file format during create and write operations is the SECOND function arg, known as "low =" in HDF5 documentation.
When linked with all 1.8.X HDF5 lib versions, "low = H5F_LIBVER_LATEST" results in  v1.8 (superblock 2) files.
When linked with lib versions 1.10.0 and 1.10.1, "low = H5F_LIBVER_EARLIEST" results in  v1.6 (superblock 0) files.  For optimal results, use "low = H5F_LIBVER_EARLIEST" only when required to link with one of these now-obsolescent lib versions.
When linked with lib versions 1.10.2 and greater, "low = H5F_LIBVER_V18" results in  v1.8 (superblock 2) files.
All three together, via these conditionals, should always result in the superblock <= 2 condition that you want for normal netcdf creates and writes.
The third arg "high =" governs format only when some discrete operation invokes an advanced HDF5 feature, such as SWMR.  My limited understanding of the netcdf core library is that such advanced features are never invoked in normal operations.  This is something that would only be done, and very explicitly, in support of a new capability, such as the DAOS VOL connector discussed above.
All this is subject to oversight and testing, to be sure.  I have not lately run any advanced test cases for this.

@DennisHeimbigner, no, not correct.  For normal netcdf operations, the governing of file format during create and write operations is the SECOND function arg, known as "low =" in HDF5 documentation.
When linked with all 1.8.X HDF5 lib versions, "low = H5F_LIBVER_LATEST" results in  v1.8 (superblock 2) files.
When linked with lib versions 1.10.0 and 1.10.1, "low = H5F_LIBVER_EARLIEST" results in  v1.6 (superblock 0) files.  For optimal results, use "low = H5F_LIBVER_EARLIEST" only when required to link with one of these now-obsolescent lib versions.
When linked with lib versions 1.10.2 and greater, "low = H5F_LIBVER_V18" results in  v1.8 (superblock 2) files.
All three together, via these conditionals, should always result in the superblock <= 2 condition that you want for normal netcdf creates and writes.
The third arg "high =" governs format only when some discrete operation invokes an advanced HDF5 feature, such as SWMR.  My limited understanding of the netcdf core library is that such advanced features are never invoked in normal operations.  This is something that would only be done, and very explicitly, in support of a new capability, such as the DAOS VOL connector discussed above.
All this is subject to oversight and testing, to be sure.  I have not lately run any advanced test cases for this.

... if the netcdf library is built using some version of HDF5 with version greater than 1.8.21.

The minimum superblock value for earliest is not dependent on what version of hdf5 is used; it is possible that a user can build netCDF with HDF5 1.12 and have a file with superblock v0. It only depends on what APIs are called. For example, if NetCDF calls H5Pset_attr_creation_order, that would force the superblock to be v2.
Currently, if NetCDF had the upper bound to be lastest, it will never have a superblock > v2 since it does not use any feature requiring greater than that, independent of the HDF5 version. The commitment to <=2 is still valid with these changes; it will only be an issue in the future if NetCDF starts to use v3 dependent APIs. It is possible for a user to not have version > 2 assuming they don't use any new NetCDF feature that needs v3 superblock.

... if the netcdf library is built using some version of HDF5 with version greater than 1.8.21.

The minimum superblock value for earliest is not dependent on what version of hdf5 is used; it is possible that a user can build netCDF with HDF5 1.12 and have a file with superblock v0. It only depends on what APIs are called. For example, if NetCDF calls H5Pset_attr_creation_order, that would force the superblock to be v2.
Currently, if NetCDF had the upper bound to be lastest, it will never have a superblock > v2 since it does not use any feature requiring greater than that, independent of the HDF5 version. The commitment to <=2 is still valid with these changes; it will only be an issue in the future if NetCDF starts to use v3 dependent APIs. It is possible for a user to not have version > 2 assuming they don't use any new NetCDF feature that needs v3 superblock.

@Dave-Allured  I guess I don't understand why low is set to H5F_LIBVER_EARLIEST for some cases and not for others; why do you want to allow for v0 with a certain version of HDF5 and not others? That would change the current behavior of what NetCDF allows now.

@Dave-Allured  I guess I don't understand why low is set to H5F_LIBVER_EARLIEST for some cases and not for others; why do you want to allow for v0 with a certain version of HDF5 and not others? That would change the current behavior of what NetCDF allows now.

@brtnfld, the short answer is that the function H5Pset_libver_bounds and its enum parameters have changed several times over the history of HDF5.  You can find traces of this in the function doc page and the release notes.  There are a lot of gory details if you dive into the full history.
The proposed three-way conditional represents the most appropriate method to coax a "universally readable" file format (superblock <= 2), at each of three different stages in the API evolution.
H5F_LIBVER_EARLIEST is necessary only with HDF5 library versions 1.10.0 and 1.10.1, because unfortunately v1.8 format compatibility was neglected in those versions.  This meant that netcdf had to resort to a downgrade from v1.8 to v1.6 compatility (superblock 0) following the 1.10.0 HDF5 release in 2016 April.  See #250 for history.
The desired symbol H5F_LIBVER_V18 was added in HDF5 library version 1.10.2.  This remains the optimal choice for the "low =" parameter through the remainder of 1.10.X, and into 1.12.X library versions.
Unfortunately I never got around to following up on restoring low = H5F_LIBVER_V18, which is why netcdf has been stuck on v1.6 compatibility (superblock 0), until now.

@brtnfld, the short answer is that the function H5Pset_libver_bounds and its enum parameters have changed several times over the history of HDF5.  You can find traces of this in the function doc page and the release notes.  There are a lot of gory details if you dive into the full history.
The proposed three-way conditional represents the most appropriate method to coax a "universally readable" file format (superblock <= 2), at each of three different stages in the API evolution.
H5F_LIBVER_EARLIEST is necessary only with HDF5 library versions 1.10.0 and 1.10.1, because unfortunately v1.8 format compatibility was neglected in those versions.  This meant that netcdf had to resort to a downgrade from v1.8 to v1.6 compatility (superblock 0) following the 1.10.0 HDF5 release in 2016 April.  See #250 for history.
The desired symbol H5F_LIBVER_V18 was added in HDF5 library version 1.10.2.  This remains the optimal choice for the "low =" parameter through the remainder of 1.10.X, and into 1.12.X library versions.
Unfortunately I never got around to following up on restoring low = H5F_LIBVER_V18, which is why netcdf has been stuck on v1.6 compatibility (superblock 0), until now.

Are we done here? Or is there more work to be done?

Are we done here? Or is there more work to be done?

I'm done with this issue.

I'm done with this issue.

Ignore that first commit.  I wish I understood how to back out mistakes more gracefully than this.  The PR is good.


CodeceptJS v3.3.7 uses a vulnerable version of flat and minimatch

What are you trying to achieve?
Run 'npm audit --recursive'.
What do you get instead?
Vulnerable version of flat and minimatch.

Provide console output if related. Use --verbose mode for more details.

# npm audit report

flat  <5.0.1
Severity: critical
flat vulnerable to Prototype Pollution - https://github.com/advisories/GHSA-2j2x-2gpw-g8fm
fix available via `npm audit fix --force`
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/flat
  yargs-unparser  <=1.6.3
  Depends on vulnerable versions of flat
  node_modules/yargs-unparser
    mocha  5.1.0 - 9.2.1
    Depends on vulnerable versions of minimatch
    Depends on vulnerable versions of yargs-unparser
    node_modules/mocha
      codeceptjs  >=2.3.0
      Depends on vulnerable versions of mocha
      node_modules/codeceptjs

minimatch  <3.0.5
Severity: high
minimatch ReDoS vulnerability - https://github.com/advisories/GHSA-f8q6-p94x-37v3
fix available via `npm audit fix --force`
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/mocha/node_modules/minimatch

5 vulnerabilities (2 high, 3 critical)

┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └──<EMAIL_ADDRESS>

┬<EMAIL_ADDRESS>  ├─┬<EMAIL_ADDRESS>  │ └──<EMAIL_ADDRESS>  ├─┬<EMAIL_ADDRESS>  │ └─┬<EMAIL_ADDRESS>  │   └──<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    ├─┬<EMAIL_ADDRESS>    │ └──<EMAIL_ADDRESS>deduped
    └──<EMAIL_ADDRESS>

Provide test source code if related

package.json dependencies:
"dependencies": {
    "codeceptjs": "^3.3.7",
    "playwright": "^1.29.2"
  },
  "devDependencies": {
    "@types/node": "^18.11.18",
    "ts-node": "^10.9.1",
    "typescript": "^4.9.4"
  }

Details

CodeceptJS version: 3.3.7
NodeJS Version: 18.13.0
Operating System: MacOS Ventura
puppeteer || webdriverio || testcafe version (if related)
Configuration file:

import { setHeadlessWhen, setCommonPlugins } from '@codeceptjs/configure';
// turn on headless mode when running with HEADLESS=true environment variable
// export HEADLESS=true && npx codeceptjs run
setHeadlessWhen(process.env.HEADLESS);

// enable all common plugins https://github.com/codeceptjs/configure#setcommonplugins
setCommonPlugins();

export const config: CodeceptJS.MainConfig = {
  tests: './tests/*_test.ts',
  output: './output',
  helpers: {
    Playwright: {
      url: 'http://todomvc.com/examples/react/',
      show: false,
      browser: 'chromium',
      waitForNavigation: "networkidle0"
    }
  },
  include: {
    I: './steps_file'
  },
  name: 'playwright-codeceptjs',
  fullPromiseBased: true
}

we have also the same issue

i am also having this issue

We have the same problem.

Came here to log that as well

Is this getting addressed?

I'm attempting to work around it for now using overrides in package.json.
{
  "dependencies": {
    "codeceptjs": "^3.3.7",
  },
  "overrides": {
    "minimatch": "^6.2.0",
    "flat": "^5.0.2"
  }
}

@DavertMik Still have those one in 3.4.0


Get-DbaDBSnapshot errors on dbo.sysdatabases

Before submitting a bug report:

[X] Ensure you are able to reproduce it on the latest released version (we release often)
[ ] Verified this bug is not already reported in an issue
[X] Verified errors are not related to permissions
[X] Can reproduce in a clean PowerShell session (clean = powershell -NoProfile)

Steps to Reproduce

New-DbaDbSnapshot -path s:\temp -server MYSERVER -database MYDB
Get-DbaDbSnapshot -server MYSERVER -database MYDB

Expected Behavior
New DB snapshot created, no errors
Actual Behavior
Snapshot is created, but only output of New-DbaDbSnapshot is:
WARNING: [New-DbaDbSnapshot][13:47:57] Failure | Invalid object name 'dbo.sysdatabases'.

Get-DbaDbSnapshot returns:
Exception calling "Query" with "1" argument(s): "Exception calling "ExecuteWithResults" with "1" argument(s): "Execute with results failed for Database
'DBNAME_20180626_134752'. ""
At C:\Program Files\WindowsPowerShell\Modules\dbatools\0.9.359\allcommands.ps1:28196 char:102
+ ...  top 1 BytesOnDisk from fn_virtualfilestats(db_id('$($db.Name)'),null ...
+                                                          ~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ScriptMethodRuntimeException`

Environmental data

PowerShell: 5.1

SQL Server: Microsoft SQL Server 2008 R2 (SP3) - 10.50.6220.0 (X64)   Mar 19 2015 12:32:14   Copyright (c) Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.3  (Build 9600: )

I have the beginnings of a patch but it needs a decision point to distinguish between sys.databases (2008+) and dbo.sysdatabases (2005)

dang! fn_virtualfilestats is not there in 2005 either.

those useful error messages tho 😍

aw wait that second error message blows 😂 . yay, i needed an example, thank you

@niphlod - i found fn_virtualfilestats  worked well in my version of sql2005. @alevyinroc -thanks for reporting this error, im gonna go ahead and submit a PR since i just wrote about it and im eager to resolve.

memory failed me, sorry


Update Help to cover absence of citations on next/previous dwellings.

A  note needed in help to explain why there is no citation button on records found through next/previous dwelling.
Insert between "using the search page" and "exploring your results":
Why is there no citation button on every result?
If you have moved to a previous or next dwelling, there is no citation button because the way we generate the citations means that they refer to the original dwelling found, not the dwelling being viewed.  If you want to generate a citation for a person found in the next/previous dwelling, please search for that person: the citation generator will then be there, and generate the correct details for this person.
P0 U3 S5 C9:P17

Done on systemwide draft on FreeREG.

Is this still something for @dhousman to take a look at?

@dhousman, Alison is going to make a new DRAFT which you can copy and edit, as she is bringing over some code from FreeREG and wants you to work on that, rather than the existing page.

In Scrum, @PatReynolds advised that this text needs to be added to a DRAFT of the Help page (Pat created in Scrum), in between Using Filters and Exploring your Results
@AlOneill is your DRAFT Help with Citations page still relevant for #760 ?

@AlOneill any update or help needed on this one?

@richpomfret Work stalled until UCF documentation is complete — then this will be my next task.

Updates done and pages are sync-ready.

This appears to be a duplicate of #760 …

Not a duplicate, Alison, but could be part of it - I will add to that, and close this

Duplicate, and done, so clusing


add maintainer

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

seems travis has not built this....odd

seems travis has not built this....odd

Unfortunately no :unamused:
People are issue too many changes and conda-smithy and issuing dozen of re-renderings which clogs Travis-CI. Hopefully this will be sorted out at the weekend when the load is lower.

thanks
did you guys solve the dedupe or problem on Travis (iow pushing the same pr cancels the previous) which appveyor and circleci just do nicely

did you guys solve the dedupe or problem on Travis (iow pushing the same pr cancels the previous) which appveyor and circleci just do nicely

I am not on top of that b/c, I was mostly away the past moth, but at least uritemplate made it! Now I restarted https://travis-ci.org/conda-forge/google-api-python-client-feedstock/builds/208310251

thanks @ocefpaf that is proceeding


How to use this warehouse with LVGL?

I am a novice and want to use LVGL, but I don't know how to use it together. Hope to add some clarification

Unfortunately I have never used LVGL.

@nopnop2002
https://github.com/espressif/esp-iot-solution/issues/122
I got the information about using LVGL on parallel port at Espressif's official components


Improve deref for better MVC Integration

Currently deref has poor ergonomics for the following reasons:

it is async
it requires specifying a path to at least one value in the event that a round-trip is required to optimize the path (cannot retrieve branch nodes from a Falcor Server)
there is no guarantee that if you run a get, and asynchronously later run a deref, you will get the same object at a branch position. The JSON Graph could have changed after all.

The last issue is particularly problematic for UI integrations, because these integrations generally get a large block of data, distribute the JSON to component children, and also pass a deref'ed model to those Components that will later lazily load additional data. The issue is that component expansion is  asynchronous in most MVC frameworks. This means that in between the get and deref call it is possible that the JSON Graph will have changed. As a result deref could be bound to different branch node than the one retrieved during get. This would cause a component to lazily load data from a different entity then it's eager load was retrieved from. At this puts the user interface into an inconsistent state.
At the moment the only solution is to deref all nodes immediately when the get call comes back, so that you have Models to dispense to Views in the event they need lazy loading. Obviously this is not efficient.
There is an elegant solution to the problem of deref:
To improve deref, we must first modify the get method to include a private “_path” property in the JSON whenever a reference is crossed. When a reference is not crossed, a reference to the parent node and the key at which to retrieve the current node at the parent node is set on the JSON branch node.
As an example, today get([“lolomo”,0,0,”item”,”name”]) returns this:
{
  genrelist: {
     0: {
         0: {
        item: {
          name: “Die Hard”
          }
         }
     }
  }
}

After this change, the same method would return this:
{
  genrelist: {
    _path: [“lolomos”,23],
     0: {                     <--|
         _path: [“lists”, 51],   |
         0: {                    |
           _parent: -------------|,
           _key: “0”, // key at which node can be found in parent
           item: {
             _path: [“videos”, 51],
             name: “Die Hard”
           }
      }
    }
  }
}

Now instead of deref accepting a deref Path and value paths, it accepts a branch node from the JSON.
model.
  get([“genrelist”,0,0,”item”,”name”]).
  then(response => {
    var lolomo = response.json.lolomo;
    var lolomoModel =
      model.deref(response.json.lolomo);
  });

If deref finds the hidden _path parameter, it immediately creates a new Model bound to the optimized path. If it finds the _key parameter, it follows the _parent up until it finds a _path key. Along the way it builds up a path suffix using the _key fields, and when it discovers a _path it concatenates the suffix to it and uses the new path as the deref path.
Deref is now synchronous, never has to make a round trip, and requires no value paths to preload. The changes to "get" also requires no new allocations. The cost of the additional property sets in get should be offset by the dramatic reduction in value gets during deref. Furthermore avoiding the creation of an Observable is also expected to save quite a bit of time.
At first the only valid input for deref will be branch nodes created during a get operation. All other inputs will throw. It is up to the developer to guard against passing null, undefined, or any of the other value types to deref.The one exception is reference. If a reference is passed to deref, the reference's target path will become the Model's deref'ed path. If we assume no dangling references, we should maintain the invariant we have today: deref only creates a Model once it verifies that the reference target exists.

Forgot to mention that we will have to rev semver because this is a breaking change. I think it's the right decision. Old deref was really bad (my fault) and we're in preview mode. It's way too early to allow cruft to accululate on the API.
@sdesai please provide feedback if anything here is unclear.

@gdi2290 FYI

sweet, yeah this would help for Angular 2 integrations :+1:
I wouldn't worry too much about the versioning during developer preview

semver.org
Doesn't this discourage rapid development and fast iteration?

Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.

To be clear, the field is not _path but <prefix>path. Because _path is a much more likely candidate for valid path than the prefix version.

Instead of devising a new JSON schema that augments a Model#get response with path metadata, why not have Model#get return an object:

That understands the structure and location of the graph being requested and returned.
That exposes a #deref method that can be used to dereference a path within the scope of the graph it understands.
That exposes a toJSON() method that can be used to generate output consistent with what is already done?

As I work mostly in the Promised land, I'm not sure that my proposal would work very well in an Observable context.

@ggoodman your idea sounds more like what I had in mind. Each model could take a basePath argument. Any call to get or getValue would prepend the basePath before firing of the request. Deref would just mean returning a new model with the given path appended to the current base path.
So deref looks like:
deref(subPath: Path): Model;

And you can do thing like:
model.deref('location').deref('address').getValue('formatted')

Which would be equivalent to:
model.getValue('location.address.formatted')

Am I understanding the purpose of deref correctly?

@ewinslow you do understand deref, but may not have all the subtle issues that come with deref.  The issue with lazy deref (where the value passed into deref is not evaluated) does not seem to be an issue until you have a list of objects whose order changes on the UI.  Imagine a grid of messages whose order changes on the UI when interacted with. To prevent any misalignment Model#get provides the correct deref information for the secondary cache it generates.  This way the UI is dereference to ID that existed at the time of its creation.
@ggoodman the issue with your suggestion is performance.  We have performance critical requirements as some of the devices we run on have low processing power.  The performance overhead of creating these prototype style objects will simply cost to much.  So a happy medium is a schema change where there are hidden objects on the output that hint deref on how to dereference the secondary cache so the UI remains consistent with what is being displayed.
This change was merged in #551


Taiwan localization and fix input handling

Add "zh-TW" translation to localizedStrings.json
Add "zh-TW" translation to messages.json
Fix input handling in main.UI.tsx

Thanks for the contribution


List FAQs under an event

I plan to list them in a new fragment leading from Event Details Fragment
Working on it :+1:
@iamareebjamal Should I proceed with this because as far as the eventbrite app is concerned there isnt a dedicated section where you can view FAQs. But our API does support it though

Not needed rn IMO

But the feature is quite helpful I guess

Lets wait for mentor for his views on this

IMO we should first implement everything that's there in Eventbrite and then add these additional features

Closing this for now then :+1:


Use second temporary directory to install roms

steamcmd doesn't seem to like installing into the same directory as
itself and will instead install in the default directory (typically
~/.steam on ubuntu) instead.
We create a second temporary directory in which to install sega classics
instead, and use that for the rom testing.
Fixes #4

Looks good, I'll have to test on macOS before I merge it though.


Prevent images with transparency from being negatively affected by dark theme

Images with transparency, for example the language family diagram image at https://en.wikipedia.org/wiki/Czech_language#Classification, are rendered indecipherable when there's a dark theme applied, such as Dimmed Dust, as in the following screenshot:

Currently you can switch to the Filter mode to fix this issue if necessary.
Current strategy is based on the image size, not its transparency - small images are inverted.

OK thanks, that worked :)

Current strategy is based on the image size, not its transparency - small images are inverted.

Is there a way to adjust the size at which that happens?
Is it the same as the "Automatic mode switch limit"?
I'm finding that the 6th lowercase svg image from the top at https://wikiless.org/wiki/Coptic_alphabet#Letters (not at the equivalent wikipedia URL) is inverting to light and is more readable, while the others remain dark and less readable.

There is no direct way to change the inversion size for users. But in case you are using other extensions to inject custom styles then you can instruct Midnight Lizard how to handle this images or just do it yourself
a.image > img[width="43"] {
  filter: invert(1);
}

PS: this website even injects the dark theme made specifically for them and it still does not handle those images: https://github.com/StylishThemes/Wikipedia-Dark
So I don't feel bad for not handling it properly as well :)


Adding access permissions

Granting myself access permissions to the HTAN S3 bucket. This is necessary for me to run the nf-artist pipeline with @adamjtaylor.

@aditigopalan Could you add a description to the PR detailing the request.
@milen-sage @adamjtaylor Does anyone from the HTAN project and/or the IT team need to give their sign-off on this change that this access is being granted.

@BryanFauble I approve this request. Aditi will be helping with running and refining some of the HTAN workflows we use.


Bring axes to 0 for drop percents figure, update axes labels, and change percents figure to use R^2

Not sure why the dependencies are failing to install for the test build

Not sure why the dependencies are failing to install for the test build

Should be good now!

Thanks! Do you know if the codecov is something I need to fix or is it ok failing as is?
@andrewram4287

Thanks! Do you know if the codecov is something I need to fix or is it ok failing as is? @andrewram4287

It's okay if it fails! Before we merge this, can you write an explanation as to the changes you made to the code?

All set to me. You can merge.


Test & Fix CLN-Rescue Export & Import

Tested the CLN-Import from an older/veryearly c-lightning node ... the test failed. To be retested.

Test worked with RC3 - closing issue.


If remapping MERRA2, either require 21z as hour or don't ask?

When running remap_restarts.py from the command line and you ask to regrid from MERRA-2, it is possible to specify an impossible time:
$ /discover/swdev/mathomp4/Models/GEOSgcm-FixMAPL2081/GEOSgcm/install-Release/bin/remap_restarts.py
? Would you like to remap archived MERRA-2 restarts? Yes
? From what restart date/time would you like to remap? (must be 10 digits: yyyymmddhh)<PHONE_NUMBER>
? Enter the directory for new restarts:

There are no 06z restarts from MERRA-2, only 21z.
So this leads to two ways of thinking:

If MERRA-2, you only ask for date, not for the time. Internally, we append the 21 and the yaml file gets that, but we don't ask the user
If MERRA-2, we ask for the time but die or cycle if a non-21 time is supplied

Myself or @weiyuan-jiang could probably code this, but I'll ping @tclune and @JulesKouatchou for more thoughts.
I think the first is more elegant, but it does mean we need two different questions for a date depending on the first question.

I prefer a modified version of option 1:   With MERRA-2, only ask for a date.  But then report to the user that it will be for 21z.  I.e, make it explicit so that there is no surprise.   Don't know if Questionary lets you do that, but presumably you can have a "Null Question"?

Option 1 is taken and pushed to my new branch #19

This issue is addressed with #19


Assume deps on variants of api or impl are correctly on that variant.

Addresses https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/issues/340.
WIP: still needs tests.

Build failed https://gradle.com/s/sp7yfy7ijnc5m

Build failed https://gradle.com/s/ag47x74rdm7vq


Unify journal related fsadmin commands

Fixes https://github.com/Alluxio/alluxio/issues/9542

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/5572/
Test PASSed.

@calvinjia PTAL. Thanks!

@ggezer Do we need to update the documentation for the journal commands?

@calvinjia Right. Doc for checkpoint will need to change. We don't have a doc for quorum yet, so it'll need to be included.

@ggezer Do you plan to update the docs in this PR or a separate one?

@calvinjia I'll have a separate doc PR to cover journal related changes.

alluxio-bot, merge this please.


Changed file location for supported_locales.yml to avoid collisions with dictionaries

https://bugzilla.redhat.com/show_bug.cgi?id=1217216

@Fryguy Please review

:+1:


Hash probe performance regression with https://github.com/facebookincubator/velox/pull/10652

Bug description
I found that TPC-DS hash probe performance is regressed by ~10% with the PR, https://github.com/facebookincubator/velox/pull/10652.
System information
Spark 3.5 & Gluten 1.2.0
Relevant logs
No response

@tanjialiang Some good candidates to address during code freeze

@JunhyungSong would you like to fix the regression?

I have no time now. Will try in December if no one takes this until then.

Fixed by #11438


Update gettingstarted.rst

as new to ocelot I found that convinced to understand when you mention minimal API and code seems not.
Fixes / New Feature #
Proposed Changes

Hello, Abdallh!
I'd accept this PR to update docs if you update Basic sample too.

As new to Ocelot I found that convinced to understand when you mention minimal API and code seems not.

The documentation could be divided into two subsections: minimal API and non-minimal. If a minimal API design is not feasible, I would suggest omitting the phrase "minimal API" entirely from the documentation.

You could return to us with more refined code in the feature branch.


Arrays in Sets vs Lists

Updated:
Immutable.Set.of("a","b","c").first() => a // OK
Immutable.Set.of(["a"],["b"],["c"]).get(1) => undefined  // expecting ["a"]

Immutable.Set.of("a","b","c").get("a") => "a" //
Immutable.Set.of(["a"],["b"],["c"]).get(["a"]) => undefined

Immutable.List.of("a","b","c").get(1) => "b" // OK
Immutable.List.of(["a"],["b"],["c"]).get(1) => ["b"] // OK

Why does Set.of(["a"],["b"],["c"]).get(1) fails?
And Set.of(["a"],["b"],["c"]).get(["a"]) fails too?
Question from: http://stackoverflow.com/questions/36098807/accessing-immutablejs-orderedset - was trying to access 2nd element in OrderedSet.

Take this with a grain of salt since I'm new to ImmutableJS and ES6/2015 but Set and List are two different data types which behave differently. From quick glance at List from the doc, it's supposed to be much like Arrays and extends from Collection.Index while Set is a different data type which extends from Collection.Set. That should answer why you get undefined when you try get(1) in Set but what I'm a little confused on is why get even works with Set in the first place when it's not even available in ES6/2015.
On, Immutable.Set.of(["a"],["b"],["c"]).get(["a"]), if you want to check the value then you can do
var x = Immutable.Set.of(["a"],["b"],["c"]);
var y = x.values();
y.next().value;
y.next().value; //at index 1

But as you stated you don't want to iterate over the Iterables I suppose you can do :-
var x = Immutable.Set.of(["a"],["b"],["c"]);
var vals = [...x]
vals[1]

But I don't know if you're taking advantage of Immutable by doing this.
Again, I'm new to this so feel free to correct me on anything that I've said here is blatantly wrong.

There is no wrong or right just little quirks in Immutable which hopefully will be resolved through discussion and better understanding.
It is like saying when I'm in this room List, I scratch my nose the usual way but if I walk into next room Set with same items, the usual method will fail. Even Sets of arrays will behave differently from Set of strings.
To summarize, Immutable has:-
Sets — Unordered collections of unique elements, use interable to access
OrderedSet — Ordered collections of unique elements, use interable to access (no direct access).
Lists — Ordered collections of elements, direct access.
Note: My original question was why OrderedSet can't be accessed directly since it is similar to a list, only with duplicate checking.


[TASK] Implement DeepL Translator API

Title
Implement DeepL Translator API
Description
Create functional translator using DeepL API calls
Acceptance criteria
Successful Translation using API
Estimate
2
Associated feature
#3

Successfully implemented, closing Task


Module Aliasing

How do I build my project with a webpack config using a resolve.alias. I have a 3rd party library dependency that requires aliasing a module what is the best way of accomplishing this?

There is no way to directly access resolve.alias.
If you need typescript aliasing, you can just use the paths property in tsconfig.
If you need alias for sass/etc, this PR might help when it's merged: https://github.com/angular/angular-cli/pull/2747

@filipesilva File aliasing seems like a fairly trivial feature to add since it's built into webpack, and it's super helpful for keeping code clean. Any chance this feature is coming soon?


Token selection modal: should save custom token in user's token list

waiting to hear: should we save just for the session, or persist between sessions?

When you add a custom token, it does not save it in the menu of tokens a user can select

https://user-images.githubusercontent.com/5423313/228402041-4c229d8d-a1a0-4b69-8097-11fabc49bbe3.mp4

Seems like multiple sessions is preferred


Feature: Portfolio

Added the HTML page and created a new navbar and header tag for the mobile view of the portfolio website

I just need to create a new branch and submit the code


Comparisons with a junction return a junction instead of a boolean

The docs for Junction says

Junctions collapse into a single value in boolean context.

However, it appears they return another junction:
> 4 > any( 2, 3 )
any(True, True)
> any( 2, 3 ) > 4
any(False, False)

You might explain that by saying this isn't in boolean context yet and it does collapse:
 > ( any( 2, 3 ) > 4 ).so
 False

But, from the docs on >, I expected that the comparison operator itself would provide that already:

returns True if the first argument is larger than the second.

Although not explicit, I take that to mean it evaluates to a Boolean, not a Junction. I don't particularly mind that it returns a Junction as long as its documented as such.
I think that junctions should collapse into unique values  and asked about that in perl6: Should junctions collapse unique values?.

Well… and there is a sentence before the one you pasted, which says:

Junctions autothread over many operations, which means that the operation is carried out for each junction element (also known as eigenstate), and the result is junction of the return values of all those operators.

While I agree that there may be a way to make it even clearer, I am still not sure what is so confusing about it.
As for the documentation on <, are you saying that we should mention junctions for every single operator? What about subs?
I think adding one of your examples to (Junction)[https://docs.perl6.org/type/Junction) page, like this one:
> 4 > any( 2, 3 )
any(True, True)

will resolve the issue.

That auto threading sentence is fine for general operations, but if an operator says it returns True or False, that's what it should return. The confusion comes in when what it does isn't what it says it does.
And, as usual, I'm saying that the docs should document what actually happens. As for what should happen, I'm neutral (as long as it is documented). If the thing that happens isn't what should happen, we should fix that. It is hard to know what should happen without an a priori spec though.

That auto threading sentence is fine for general operations

Hm… what general operations?

A general operation is any operation that you haven't specified yet and can't constrain further until you know what it is.

Would it be wrong to say:
because of auto threading, a junction operation creates a sort of outer
envelop around an expression, so even though an expression like " 4 >
any( 2, 3) " appears to have one operator which has a unique result, in
reality we have something more like Thread_any( 4 > 2, 4 > 3), which is
why we get the junction (True, True) as the result
?
If this is correct, it might be useful to explain this, as only by
writing this question, I worked out what 'Autothreading' actually meant.
If I am wrong, some extra explanation would be useful.
Richard
On Friday, April 07, 2017 08:33 PM, brian d foy wrote:

That auto threading sentence is fine for general operations, but if an
operator says it returns True or False, that's what it should return.
The confusion comes in when what it does isn't what it says it does.
And, as usual, I'm saying that the docs should document what actually
happens. As for what should happen, I'm neutral (as long as it is
documented). If the thing that happens isn't what should happen, we
should fix that. It is hard to know what should happen without an /a
priori/ spec though.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/perl6/doc/issues/1269#issuecomment-292524300, or
mute the thread
https://github.com/notifications/unsubscribe-auth/AAWMnHwkJk28fESjUwKpdRR4M6WeRdSkks5rti0OgaJpZM4M20MK.

The &infix:«<» operator does return only True or False
The junction calls it for every one of its values, and creates a junction from that. (simplified)
This happens for everything that doesn't specifically handle Junctions or Mu.
Should we add a boilerplate to every operator/sub/method that it doesn't specifically handle Junctions?
Should this operator be one that collapses a Junction?
(I don't think any currently do)
I will add that Junctions should be Bool-ified as soon as practical, but currently it is up the programmer to determine where that is. (I typically use so for this)


Contributing MD and building files.

Hi,
Recently I made a pr and there was no command to build the UMD version of the files.

Ah, my bad. The commands are contained within the Makefile, but it's not documented anywhere.
I've added a brief note to the readme.


Update TMS example for new menu

TMS example works for previous menu. Menu has been updated, TMS example needs minor update for full example with updated menu.

possibly assign to @AndreasAch

Closing the issue since it was implemented for the pause menu version that existed during Milestone 09
Refer to Issue #149 for the new TMS example for the updated pause menu


Hide number of changes in UI, add it in debug logging utility

Closes https://github.com/mui/mui-toolpad/issues/781 (fix just for UX, not the number of updates yet)

Show either Saving changes... (saving), You have unsaved changes. (unsaved changes, not saving) or All changes saved! in UI
Create small debug logging infrastructure with a new TOOLPAD_DEBUG environment variable and utils/logs with a method for debug logs. Feel free to suggest changes or alternatives about this.
Log unsaved/saved DOM changes if debugging is active, this should be helpful in fixing any issues with number of updates

https://user-images.githubusercontent.com/10789765/186950577-66304226-0ecf-48a8-804d-3cc291953a24.mov

Show either Saving changes... (saving), You have unsaved changes. (unsaved changes, not saving) or All changes saved! in UI

I would suggest the "All changes saved" to be transient (disappear after a few second delay), benchmarking based on how Google Docs does it:
https://user-images.githubusercontent.com/19550456/187029532-49ab65a4-c91d-4583-b6ef-b873e5a4695a.mov

To reduce the amount of space it takes in the UI and avoid layout shifting, perhaps it makes sense to just use an icon for this?
We could use color to indicated "all saved"/"has unsaved changes" and a spinner to indicate "saving"?

I would suggest the "All changes saved" to be transient (disappear after a few second delay), benchmarking based on how Google Docs does it:

Good idea! I'll add something like that.

Yes, taking it a bit further even, to reduce the amount of space it takes in the UI and avoid layout shifting, perhaps it makes sense to just use an icon + tooltip for this?
We could use color to indicated "all saved"/"has unsaved changes" and a spinner to indicate "saving"?

On one hand this make the information we're conveying less clear, but this information is also a bit secondary, so I think this would make sense. I'll try something like this too.

With icon and tooltip:
https://user-images.githubusercontent.com/10789765/187490790-1f01cc7b-a09f-4177-bded-fb547eaa7489.mov

Looking good 👍
we could also use the CloudDone icon for this

ok i'll make a quick switch before merging, it's more techy i guess :D


NullpointerException in integration tests after upgrade from Dalston.SR4 to Edgware

After upgrading from Dalston.SR4 to Edgware our integration tests are failing. The log:
Application startup failed
java.lang.NullPointerException: null
	at org.springframework.cloud.context.scope.refresh.RefreshScope.start(RefreshScope.java:121)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)

Line 121 of the RefreshScope class states: this.context.getBean(name).getClass();
In our case this.context.getBean(name) returns null because this bean is optional so getClass() results in a NullPointerException.
It seems getClass() is added in this commit: https://github.com/spring-cloud/spring-cloud-commons/commit/c28ca5de91408e6c64a2c9a3e1977b8f104940ac
In our case we have a java config class where we autowire an optional class:
@Configuration
public class MyCustomConfig {
...
@Autowired(required = false)
@Qualifier("myCustomBean")
private MyCustomBean myCustomBean;
}

@sanderino666 is that class @RefreshScope?

Fixed via 464624e3759526bbc227127d621822bc80d5dc6d

Reopening for a test.

@spencergibb I believe you fixed it before I could comment on it :-). Indeed, the injected bean has a @RefreshScope annotation.

Ha, by merging to master it closed it again. @sanderino666 could you provide a sample of what that looks like? I'm unable to craft a test that recreates it, so we can prevent a regression in the future.

@spencergibb I created an integration test which proves it all. I hope this helps. If you run the tests it should pass with Dalston.SR4 in the pom.xml and it should fail with Edgware.RELEASE.
Uploading spring-cloud-commons-issue-297.zip…

Thanks @sanderino666, very helpful, but very odd to create a bean and return null.

@spencergibb I know :). In this case it is a simple example but in our codebase there are some beans that are only created when there is a specific property present in the application.properties for example.

Right, but in that case there wouldn't be a bean definition with a null value

Here's the magic ;-)
@Bean
@RefreshScope
public ILogResource logResource(@Value("${logging.file:}") String logfile) {
	if (logfile == null) {
	  LOG.info("No log resource file configured");
	  return null;
	}

	LogFileResource logFileResource = new LogFileResource(logfile);

	if (!logFileResource.exists()) {
	  LOG.warn("Configured log resource file does not exist");
	  return null;
	}

	return logFileResource;
}

Yeah, I'd put that in a custom condition and never create the bean

I agree. Just going through our codebase to see if this is the only place where we return a null bean so we can fix it. Thanks for your help!


Not saving state on rotating screen

First of all thanx for the greate control.
When the screen is rotating the control not save the data

Hi @encore121 when you rotate a device the activity or fragment will be recreated.
It's is good practice that the developer handles such situations.
Please take a look at onSaveInstanceState and onRestoreInstanceState callbacks.
For a more in depth understanding I would also recommend taking a look at the Android lifecycle documentation

Sure but the default spinner handle this by default only with his ID. But thanx any way.

Hi @encore121 seems I have misinterpreted the issue.
I'm reopening the issue until I properly fix it.

Hi @encore121 I just released version 1.3.3 that should fix the issue.
Please try it out and let me known if you still have any issues.

Hi @tiper sorry for the late in the answer. I try the version 1.3.3 and works equals the default spinner
Thanx

Thanks for the feedback.
Cheers


Update testing for XQTS test special case.

Altered the test result checking process to allow for XQTS tests which have either an error or a result.

Looks good to me - haven't run tests ...


Get blocked MAC list every 5 seconds.

Codecov Report

Merging #36 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #36   +/-   ##
=======================================
  Coverage   72.92%   72.92%
=======================================
  Files           5        5
  Lines         373      373
  Branches       71       71
=======================================
  Hits          272      272
  Misses         58       58
  Partials       43       43

Impacted Files
Coverage Δ

src/decode.c
79.34% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 84e24d0...41b1449. Read the comment docs.


Create a set of questions for the survey and interview

@Mayaleeeee please add a description to this issue


Problem at connection

I'm using clank bundle and I want to test if socket server is running without problem
I have set the configuration as follow :
# Clank Configuration
clank:
    web_socket_server:
        port: 8080        #The port the socket server will listen on
        host: domain.com #(optional) The host ip to bind to

the port 8080 is open and tested
after adding the two js files : autobahn.min.js and clank.js I do the following :
var myClank = Clank.connect("wss://domain.com:8080"); // I use SSL

		myClank.on("socket/connect", function(session){
			//session is an Autobahn JS WAMP session.

			console.log("Successfully Connected!");
		})

		myClank.on("socket/disconnect", function(error){
			//error provides us with some insight into the disconnection: error.reason and error.code

			console.log("Disconnected for " + error.reason + " with code " + error.code);
		})

note that the server is already running with the command :
php app/console clank:server

the problem is I can't get the success message in my console.. When I stop clank server , it outputs the failure message.
I don't know what's happening please help me ..

Hi @Sshuichi , do you know how to do this same thing but with apache2? Thanks a lot!

This mod should answer your need  : https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html

Thans a lot, I'll do that.

It work's! Thanks a lot.


787 test with invalid block sizes

Part of https://github.com/input-output-hk/cardano-ledger-specs/issues/787

@dnadales should we have been requested as reviewers instead of added as assignees? 🙂

@dnadales should we have been requested as reviewers instead of added as assignees? slightly_smiling_face

Ups. Thanks for the heads up!

bors r+


feat: add astronvim editor client

This adds the AstroNvim distribution to the available clients (we already maintain our own discord client ID)

thanks! glad to be a part of the community


Runtime Enum Creator + a few improvements and bug fixes.

Fixes #463

This PR would be better as several, since it changes/adds so much.

Is there a reason why so many things should be renamed? And are we sure it will not break existing mods?

agreed. changing gameobject names would/could be a breaking change.

I don't know why it would be a breaking change. None of the mods I use break just from a simple name change.

I removed the unrelated commits

If there was a less complicated way then I would totally use it, but this is the best I have right now.


separate stderr in conmon

We need to separate stderr/stdout in the logs (by using a separate pipe for it).

Fixed by #445


Storyshots - Storybook Visual Regression

Created a custom jest config for "storyshots" visual regression.
Added storyshots test path to exclude path in the global jest configuration.
Added yarn storyshots yarn script to run the storyshots tests (assumes you are running storybook)
Base comparison images for the visual regression are included now in the repo.

To Test
yarn storybook
yarn storyshots

Coverage remained the same at 28.822% when pulling 012aa19cea23dd2cd16a01e0be5057ff8ed5e623 on patthiel:M3-603 into d00b1a3b7a4d92e1516ae8b20dbc953c8ad7ef7f on linode:develop.

Blocked by referenced issue.


[v3] Client ICQ

Closing this as this test has been added to the relayer along with stride ICQ support https://github.com/cosmos/relayer/pull/1076


NetworkingDSC: Update LICENSE file to match the Microsoft Open Source Team standard. Issue #363

Pull Request (PR) description
In new repositories that are created by the Microsoft Open Source Team, the LICENSE file does not contain the year in the copyright "header".
This Pull Request (PR) fixes the following issues
- Fixes #363

Task list

[x] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md in resource folder.
[ ] Resource parameter descriptions added/updated in schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #364 into dev will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff         @@
##            dev   #364   +/-   ##
===================================
  Coverage    98%    98%
===================================
  Files        27     27
  Lines      1953   1953
===================================
  Hits       1920   1920
  Misses       33     33

I will get one right the first time soon.... :)
Thanks @PlagueHO