Inflection Observed Frequency Marking

This implements #455
Bold font is not used on observed forms because currently some labels are in bold font
Gray text and frequency superscript is implemented.
Need more suggestions on how to make it looks better,
currently it looks like this:

Codecov Report

Merging #506 into master will increase coverage by 0.02%.
The diff coverage is 95.08%.

@@            Coverage Diff             @@
##           master     #506      +/-   ##
==========================================
+ Coverage   88.69%   88.71%   +0.02%
==========================================
  Files          71       71
  Lines        2626     2658      +32
==========================================
+ Hits         2329     2358      +29
- Misses        297      300       +3

Impacted Files
Coverage Δ

CreeDictionary/utils/paradigm_filler.py
96.90% <93.10%> (-1.80%)
:arrow_down:

CreeDictionary/tests/API_tests/model_test.py
96.63% <93.33%> (-0.76%)
:arrow_down:

CreeDictionary/paradigm.py
94.73% <100.00%> (+0.70%)
:arrow_up:

...ctionary/tests/utils_tests/test_paradigm_filler.py
100.00% <100.00%> (ø)

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 d396484...98aa550. Read the comment docs.

@aarppe btw, I found two malformed lines:
line "*PV/e+PV/wah+ohtohtêw+V+AI+Cnj+Prs+3Pl" is broken in ahenakew_wolfart_MGS_tab-sep-anls_freq-sorted.txt
line "*PV/e+PV/wah+ohtohtêw+V+AI+Cnj+Prs+3Pl" is broken in ahenakew_wolfart_MGS_tab-sep-anls_freq-sorted.txt


Feature Request: Strong Name the assembly

Please strong name the nuget package. It is recommended to do so on open source libraries, and to check in the signing key to the git repo.
https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named
It doesn't affect projects that are not strong named, but projects that are cannot use this library from nuget.

PR merged. Thank you!

:rocket: 5.2.1 version is released now!
Prerelease NuGet packages will be unlisted soon, so please update the package references to the new version.
Thanks for using the library!


doc: update python manual to reference python 3.8 instead of 3.5

Improvement suggested in #87094
CC @fridh @jonringer

Question: Why not use python3 so it will point to whatever's considered as Python3 ?

Depends on the exact use whether that is possible. Sometimes it's used to indicate specifically there are other versions available.

Looks good. Will also need to get rid of blaze as example because that package is no longer maintained and entirely functioning.

Sounds good; I see a couple other things that are not idiomatic and could use touchups, but I'll send those in a follow-up and keep this PR just on the 3.5 -> 3.8 rename for easy reviewability.


Deprecate specification

As per Steering/BoD decision today

Perhaps spec.yml should include show_in_index: false so it doesn't appear on https://github.com/AMWA-TV/nmos?

Probably best to leave it in the index (could be in a separate section for deprecated specs?) but we could omit it from the IS menu.
Could have a tickbox to show Deprecated specifications (and one for WIP specs?)
In any case that shouldn't affect approval of this PR


Fix listing in Gnome Software to show that it is community built in the open

Currently in the Gnome software store, Tomboy-NG gets shown as "potentially unsafe" due to proprietary code and in the license section states "This software is not developed in the open".

Instead it should be saying something like the original Tomboy does: "Community Built This software is developed in the open by a community of volunteers, and released under the LGPL-2.1+ license.  You can contribute and help make it even better." with a "Get Involved" link to https://wiki.gnome.org/Apps/Tomboy

Mincn, I am guessing Ubuntu ?  Are you looking at an entry in the Gnome Software app's catalog or are you using that app to open a tomboy-ng deb file downloaded by yourself ?  Ubuntu have a policy of stamping any deb that does not come from their own catalog as proprietary. Its not a mistake, its deliberate as the problem has been pointed out to them on many occasions and applying to many different apps.
https://askubuntu.com/questions/1117073/why-does-software-centre-mark-any-local-deb-as-proprietary
Using gdebi is, IMHO the better way to install a downloaded deb file with a GUI, apt from the commandline. Synaptic is, by far, a better way to install applications from the official repository.
All code in tomboy-ng is stamped with a completely open source license and it has a copyright file listing all those licenses that is acceptable to Debian, and they are the gold standard when it comes to open licenses, believe me ! And, of course, Ubuntu get their packages, ready made, from Debian.
https://metadata.ftp-master.debian.org/changelogs//main/t/tomboy-ng/tomboy-ng_0.32-2_copyright
https://metadata.ftp-master.debian.org/changelogs//main/t/tomboy-ng/tomboy-ng_0.34-1_copyright
I personally have abandoned Ubuntu because of its disinterest in its users. I, and many, many other people have reported this bug, they ignore it, then there is the Snap issue, the failure to update Evolution or Thunderbird to do Google Contacts, hostility to the Tray Icon.... Perhaps because they don't really care about open source, perhaps because they want to direct you to their commercial partners ?  Its all a mystery to me. And totally out of my hands, you could try reporting it to Ubuntu (or even Gnome) but I cannot find my original bug reports so I assume its on their "will not fix" list.
Sorry I cannot be of more help.
Davo

OK, Ben, you got me thinking. While I can explain the above away, I still resent it !  But your post gave me an idea. "No screenshot provided" ?
So, I found that Debian run a repository of all the screenshots that appear in (eg) the Gnome Software Centre, so, I have uploaded one that shows tomboy-ng and a couple of notes. The main note shown says, quite prominently, that tomboy-ng is 100% open source !
Will take a few days to be approved apparently, we'll see.  Thanks for the prod !
Davo

Hmm, no, that did not help on Ubuntu, seems it gets its screen shots elsewhere. Maybe they are a bit scared you may get accurate information.
Which OS are you using mlncn ?
Davo

Debian 11 with Gnome 41.4

OK, beats me.  https://screenshots.debian.net claims that Ubuntu Software uses it, but my test says otherwise. The site, despite being a Debian service, does not claim Debian uses it.
I have established that Synaptic does, and thats a far better install manager that Gnome|Ubuntu Software IMHO. Both
packages.debian.org and packages.ubuntu.com do use it.
Sorry, thats all I can do. It is Open Source, the copyright file clearly says so. I have logged it as a bug against Ubuntu Software several years ago.
Davo

Hey, I just looked at U22.04, the "Software Store" no longer describes apps other than their own as Proprietary - now says "Potentially unsafe, provided by a third party" and does not mention the license specifically. As most distros use the same app (its from Gnome), I guess that's not perfect but a lot better !
( Gnome (who make the app) states that packages installed from debs or RPMs cannot have any safety information, implying that Snaps, Flatpacks etc are safer. Maybe, but slower and wasteful of memory and diskspace. And we all know how useful it is trying to influence Gnome policy. )
As most distros use the same app, I guess that's not perfect but a lot better ! I'll close this ticket....


Add logging methods for new rowtypes (log_tradeoff_row! etc.)

Add generic methods for the new rowtypes, in service of LWB PR

Nice, I suggest three changes:

Add to docs: just add the names here https://github.com/beacon-biosignals/Lighthouse.jl/blob/0540cdd5fcfc7a95cdd0b8c080febc42da736dbe/docs/src/index.md?plain=1#L44
. This will make CI happy: https://github.com/beacon-biosignals/Lighthouse.jl/runs/6730161644?check_suite_focus=true#step:5:15
Give default definitions in terms of log_values!. E.g. just log the scalars as values with some _log_scalars_from_row helper. Or just return nothing. (But logging the scalars is more friendly IMO). That way we can freely use these functions in Lighthouse or LighthouseFlux etc without worrying that there will be errors if the user doesn't have a logger that supplies methods here. In other words: let us not expand the required logger interface that loggers need to satisfy, just the optional interface.
Don't export log_evaluation_row. We should encourage moving to the new rows, not the old ones.

Cool got all but the docs knocked out i think!

cool! want to add some tests for these?

[ ]  add tests
[ ]  add to docs

yes!


Automatically add docker compose stacks as groups to be tracked

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
New Monitor
🔖 Feature description
I am happily using Dockge and Uptime Kuma but I frequently forget to create new monitors in uptime-kuma whenever I create a new container/ docker compose file in dockge.
Could it be possible to have an integration between the two systems, so that any new container managed in dockge automatically gets a monitor created within Uptime Kuma?
✔ Solution
Could it be possible to have an integration between the two systems, so that any new docker compose stacks managed in dockge automatically gets a monitor-group created within Uptime Kuma?
❓ Alternatives
No response
📝 Additional Context
No response

dockge creates docker-compose files and applies them.
I have reworded your request to make this clearer.
Related/ depends on #957

Any updates regarding this?

No, no updates since 2 months ago.
Would you expect updates since my last post?
We are hard at work preparing the v2.0 release. Please see https://github.com/louislam/uptime-kuma/issues/4500 for further context.
You can subscribe to the issue on the right to get notified of any changes
.

[!TIP]
If you have a look at the dependency linked above https://github.com/louislam/uptime-kuma/issues/957, @BigBoot has shared https://github.com/BigBoot/AutoKuma
I have not tested if it works as advertised, nor audited said software.


My cool stuff

update <image_classification.ipynb>:

add some note for the MNIST API return date structure
add  model.summary for the LeNet after model build, have a visual pic of the net shape

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

@TCChenlong


Creation time of images

Is there a way to access the creation time of the images? By this one could wait 3 hours before downloading a new file.
Currently the images do not contain EXIF data and the server response with this header:
t = 'https://clouds.matteason.co.uk/images/2048x1024/clouds.jpg'
response = requests.head(t, allow_redirects=True)
print(json.dumps(dict(response.headers), indent=4))

{
    "Date": "Sun, 07 Jan 2024 15:03:36 GMT",
    "Content-Type": "image/jpeg",
    "Content-Length": "453521",
    "Connection": "keep-alive",
    "last-modified": "Sun, 07 Jan 2024 14:40:10 GMT",
    "access-control-allow-origin": "*",
    "etag": "\"659ab7ca-6eb91\"",
    "expires": "Sun, 07 Jan 2024 14:56:22 GMT",
    "Cache-Control": "max-age=600",
    "x-proxy-cache": "MISS",
    "x-github-request-id": "D7A6:3CB921:4663A39:478CE79:659AB93E",
    "via": "1.1 varnish",
    "x-served-by": "cache-fra-eddf8230113-FRA",
    "x-cache": "MISS",
    "x-cache-hits": "0",
    "x-timer": "S1704638782.245013,VS0,VE116",
    "vary": "Accept-Encoding",
    "x-fastly-request-id": "d37c7c93eee1d54d41bbf3af796af759af214a7b",
    "CF-Cache-Status": "REVALIDATED",
    "Accept-Ranges": "bytes",
    "Report-To": "{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=HcZUwe2O41bkdngpsz%2FeRquqDosFjSkMRrYWri%2FNvekWfdQ91DnaRhMtXxdsYvD7ussoKqgzLnrtu6yxtNp4Uii2pJvcg2uhh%2F%2BfiVW%2FXcUl8waPfh%2Bxc4MDJ5zSgU6C1N%2FfYWvlE3CW\"}],\"group\":\"cf-nel\",\"max_age\":604800}",
    "NEL": "{\"success_fraction\":0,\"report_to\":\"cf-nel\",\"max_age\":604800}",
    "Server": "cloudflare",
    "CF-RAY": "841d16a639d16d6e-MUC",
    "alt-svc": "h3=\":443\"; ma=86400"
}

Date is the time of downloading and last-modified seems to change every 30 minutes. It would be best, if this information were available in the header sent by the server. Of perhaps in a separate text/json file on the server.

Okay, I guess the 30 minutes interval of new images results from this: https://github.com/matteason/live-cloud-maps/blob/main/.github/workflows/generate-images.yml#L6
So in fact it is a new image every 30 minutes. So I guess it would require more work to determine if the base images have changed and store this information somewhere.

Hi @jmozmoz - yes, this is a good idea. Ostensibly the source data is updated every three hours, but the workflow runs more frequently because sometimes the base images contain holes which later get filled in.
What I could do is take a hash of the newly generated file, compare it to the currently published file, and only republish if it's changed. Then the last-modified should be accurate and you could issue a HEAD request to determine if you need to refetch.

See https://github.com/jmozmoz/cloudmap/issues/12#issuecomment-1882050380


Visual Studio 2019 support

It looks like this project can be compiled with Visual Studio 2019 basically as is (after retargeting it to v142), even though it says Visual Studio 2022 is a prerequisite.
There are only two caveats:

vcpkg fails to compile boringssl, unless you have Windows SDK >= 10.0.22000. Previous versions of the Windows SDK are missing stdalign.h. See a similar issue here:

https://github.com/google-deepmind/mujoco/issues/862

It seems like this header has been removed from boringssl, so this may no longer be an issue in the future.

In ResourceTypes.cpp, iResTable::add uses append_range() on an std::vector, which is a C++23 feature. I fixed it with this workaround:

// replace this line (~4260)
typeList.append_range(srcPg->types[j]);

// with this:
#ifdef __cpp_lib_containers_ranges
    typeList.append_range(srcPg->types[j]);
#else
    typeList.insert(typeList.end(), srcPg->types[j].cbegin(), srcPg->types[j].cend());
#endif

Thanks. I will fix the second caveat.


Allow users to pass inner to sc.pl.violin when multi_panel=True

Might fix my proposed solution for #2051
@WeilerP, do you remember why you explicitly set inner=None here in #1422?

Hm, no, sorry not entirely sure. I guess it was to mimic the behavior here. In the original implementation, kwds wasn't passed to the stripplot function (see here) but it was in #1422. From briefly skimming the docs here I believe inner and cut aren't valid arguments.


CI: ci-ginkgo failure in Spec Setup

CI failure
Failure encountered on multiple runs in main branch, for example :
#21024
#21027
 #21056
 #21058
Sysdump from 21058
sysdumps.zip
K8sAgentChaosTest Connectivity demo application
  Endpoint can still connect while Cilium is not running
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515
16:40:26 STEP: Running BeforeAll block for EntireTestsuite
16:40:26 STEP: Starting tests: command line parameters: {Reprovision:false HoldEnvironment:false PassCLIEnvironment:false SSHConfig: ShowCommands:false TestScope: SkipLogGathering:false CiliumImage:quay.io/cilium/cilium-ci CiliumTag:b1455f07c490e22f8330474a1f70343025687d79 CiliumOperatorImage:quay.io/cilium/operator CiliumOperatorTag:b1455f07c490e22f8330474a1f70343025687d79 CiliumOperatorSuffix:-ci HubbleRelayImage:quay.io/cilium/hubble-relay-ci HubbleRelayTag:b1455f07c490e22f8330474a1f70343025687d79 ProvisionK8s:false Timeout:24h0m0s Kubeconfig:/root/.kube/config KubectlPath:/tmp/kubectl RegistryCredentials: InstallHelmOverrides: CiliumExtraOpts: Multinode:true RunQuarantined:false Help:false} environment variables: [SHELL=/bin/bash KERNEL=net-next K8S_NODES=3 *** LOGNAME=root KUBEPROXY=0 HOME=/root LANG=C.UTF-8 NO_CILIUM_ON_NODES=kind-worker2 NETNEXT=1 SSH_CONNECTION=<IP_ADDRESS> 46148 <IP_ADDRESS> 22 INTEGRATION_TESTS=true CILIUM_NO_IPV6_OUTSIDE=true USER=root CNI_INTEGRATION=kind SHLVL=1 K8S_VERSION=1.32 SSH_CLIENT=<IP_ADDRESS> 46148 22 PATH=/root/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin MAIL=/var/mail/root OLDPWD=/root _=./test.test CILIUM_IMAGE=quay.io/cilium/cilium-ci CILIUM_TAG=b1455f07c490e22f8330474a1f70343025687d79 CILIUM_OPERATOR_IMAGE=quay.io/cilium/operator CILIUM_OPERATOR_TAG=b1455f07c490e22f8330474a1f70343025687d79 CILIUM_OPERATOR_SUFFIX=-ci HUBBLE_RELAY_IMAGE=quay.io/cilium/hubble-relay-ci HUBBLE_RELAY_TAG=b1455f07c490e22f8330474a1f70343025687d79 SKIP_K8S_PROVISION=true]
16:40:27 STEP: Ensuring the namespace kube-system exists
FAIL: failed to ensure the namespace kube-system exists: exit status 2
16:40:27 STEP: Running AfterEach for block EntireTestsuite
<Checks>

</Checks>

• Failure in Spec Setup (BeforeEach) [0.381 seconds]
K8sAgentChaosTest [BeforeEach]
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
  Connectivity demo application
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
    Endpoint can still connect while Cilium is not running
    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515

    failed to ensure the namespace kube-system exists: exit status 2

    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:652
------------------------------
K8sAgentChaosTest Restart with long lived connections
  TCP connection is not dropped when cilium restarts
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515
FAIL: failed due to BeforeAll failure
16:40:27 STEP: Running AfterEach for block EntireTestsuite
<Checks>

</Checks>

• Failure in Spec Setup (BeforeEach) [0.013 seconds]
K8sAgentChaosTest [BeforeEach]
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
  Restart with long lived connections
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
    TCP connection is not dropped when cilium restarts
    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515

    failed due to BeforeAll failure

    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:652
------------------------------
K8sAgentChaosTest Restart with long lived connections
  L3/L4 policies still work while Cilium is restarted
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515
FAIL: failed due to BeforeAll failure
16:40:27 STEP: Running AfterEach for block EntireTestsuite
<Checks>

</Checks>

• Failure in Spec Setup (BeforeEach) [0.012 seconds]
K8sAgentChaosTest [BeforeEach]
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
  Restart with long lived connections
  /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:461
    L3/L4 policies still work while Cilium is restarted
    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:515

    failed due to BeforeAll failure

    /home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:652
------------------------------
SSSSSSSSSSSSSSSSSSSSSSSSAfterSuite: not running on Jenkins; leaving VMs running for debugging

Summarizing 3 Failures:

[Fail] [BeforeEach] K8sAgentChaosTest Connectivity demo application Endpoint can still connect while Cilium is not running
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:652

[Fail] [BeforeEach] K8sAgentChaosTest Restart with long lived connections TCP connection is not dropped when cilium restarts
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:652

[Fail] [BeforeEach] K8sAgentChaosTest Restart with long lived connections L3/L4 policies still work while Cilium is restarted
/home/runner/work/cilium/cilium/test/ginkgo-ext/scopes.go:652

Ran 3 of 121 Specs in 0.416 seconds
FAIL! -- 0 Passed | 3 Failed | 0 Pending | 118 Skipped

Seems to appear only on k8s v 1.32

Function failing is EnsureNamespaceExists

Running locally setup of kubectl client 1.32
cilium/test [ main]
❯ sudo  curl --output /tmp/kubectl/1.32/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.32.0-rc.0/bin/linux/amd64/kubectl && sudo chmod +x /tmp/kubectl/1.32/kubectl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   225  100   225    0     0   1108      0 --:--:-- --:--:-- --:--:--  1113

cilium/test [ main]
❯ /tmp/kubectl/1.32/kubectl version
/tmp/kubectl/1.32/kubectl: line 1: syntax error near unexpected token `<'
/tmp/kubectl/1.32/kubectl: line 1: `<?xml version='1.0' encoding='UTF-8'?><Error>NoSuchKey<Message>The specified key does not exist.</Message>No such object: kubernetes-release/release/v1.32.0-rc.0/bin/linux/amd64/kubectl</Error>'

Fix for this :
cilium/test [ main]
❯ sudo curl -L --output /tmp/kubectl/1.32/kubectl https://dl.k8s.io/release/v1.32.0-rc.0/bin/linux/amd64/kubectl && sudo chmod +x /tmp/kubectl/1.32/kubectl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   138  100   138    0     0    639      0 --:--:-- --:--:-- --:--:--   641
100 54.6M  100 54.6M    0     0  4456k      0  0:00:12  0:00:12 --:--:-- 5587k

cilium/test [ main][⏱ 12s]
❯ /tmp/kubectl/1.32/kubectl version
Client Version: v1.32.0-rc.0
Kustomize Version: v5.5.0
Server Version: v1.32.0-rc.0

should be fixed by https://github.com/cilium/cilium/commit/b927504a0626bb5fa9b08095f065e5137ecf664b

nevermind, some workflows still have the issue https://github.com/cilium/cilium/actions/runs/12122758933

looking at the output of the test it is still using old mirror despite https://github.com/cilium/cilium/commit/b927504a0626bb5fa9b08095f065e5137ecf664b changing the curl call to the new mirror

workflows running on main with the old mirror where coming from pr from forked repo not up to date, closing this


refactor shutdown sequence to use plugin.stop

Change shutdown sequence to be triggered by plugin.stop instead of ShutdownSignal exception.
Also remove any calls to: shutdown, finished, finished?, running? or terminating?
This depends on https://github.com/elastic/logstash/pull/3895

FIxed by https://github.com/logstash-plugins/logstash-input-eventlog/pull/19


[adc_ctrl/dv] Added counter tests

Added tests

adc_ctrl_poweron_counter
adc_ctrl_lowpower_counter

Added test sequences

adc_ctrl_counter_vseq
Randomize wakeup_time powerup_time and low/high/one shot power mode, wait for data then repeat.
adc_ctrl_poweron_counter_vseq
Extends adc_ctrl_counter_vseq for normal and one shot mode.
adc_ctrl_lowpower_counter_vseq
Extends adc_ctrl_counter_vseq for low power mode.

Added assertions

WakeupTime_A - checks wakeup timing in low power mode
EnterLowPower_A - Checks ADC controller enters low power mode

Updated model

Updated to latest spec / RTL
Modelled adc_fsm_reset register
Modelled interrupt registers for One Shot mode.

Updated adc_ctrl_filters_polled_vseq to perform FSM reset at the end of each iteration as
to make sure model and RTL are synchronised before each new configuration
Updated PwrupTime_A to new spec (programmed value + 2) cycles
Enabled PwrupTime_A for all tests and removed plusarg control

Signed-off-by: Nigel Scales<EMAIL_ADDRESS>

@cindychip I've put this back to draft while I fix up the model in the scoreboard to suit the latest RTL.

@cindychip I've fixed up the model and a few tweaks to the sequences.
adc_ctrl_filters_polled and adc_ctrl_filters_interrupt tests should now work.
I'll fix up adc_ctrl_filters_wakeup in the next PR.


native user

can you provide definition of native user

Thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


Unicode is hard

NEGATE ALL THE THINGS

Never mind, someone has already pull-requested

This PR had a much better title and comment. May you win the next round!

Haha 😂 thanks guys! 🙏


feat(code-block): client-side highlighting

Closes #1091
What I did

add highlighting="client attribute
add dedent boolean attribute

Testing Instructions

/elements/code-block/demo/client-side-highlighting/

Notes to Reviewers

Axe DevTools complains that #content-lines needs to be focusable so that users can scroll the content within the <div>.
I propose we add tabindex="0" to that div when there are scrollbars / the code block is not expanded.
<div id="content-lines" tabindex="0">
  ...
</div>

6418df9 implements tabindex, but in reverse.
Right now, the tabindex attribute shows when the code block is expanded. It should only be there when the code block is not expanded.


Pancakeswap API Update

Please note that the Pancakeswap API has an udptate. The new url is https://api.pancakeswap.info/api/v2/.

Thank you very much for letting me know, I already updated it to v2


[occm] Move CCM rbac to manifests/

What this PR does / why we need it:
This PR moves the required RBAC for OCCM to new location manifests/controller-manager
And also delete the rbac for pvl-controller, which is not required.
/kind cleanup
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

@lingxiankong @jichenjc PTAL

/lgtm

/approve


[tutorial request] how to ssh into club systems

it would be cool if someone wrote a tutorial explaing how to ssh into the club's systems.

tutorial can be found here

Stallman: ssh<EMAIL_ADDRESS>Idle2: ssh<EMAIL_ADDRESS>Mosh: Replace ssh with mosh

merged


When default value is set, it interferes with going back

I'm not sure what's happening, but I know it affects master. Visually, the correct radio option will be chosen, but any conditional questions that are supposed to appear based on it won't appear. The questionAnswers become incorrect when I go back, too, even though I didn't change the answer.
I can confirm that removing the default value fixes the issue, too. Without a default, the props and state match, but with a default, they don't have to.

Interesting, can you perhaps get a CodePen|Live version running so I can see exactly what you mean?
Thanks!

Sure, check out https://codepen.io/KingMob/pen/paqmJZ

Hey @KingMob, having checked this out...this is kind of by design. Question IDs are not question set specific, they’re global. So when switching to the second panel, the default is set for the ID “first” question ID and when switching back, it will be set for the previous panel. Does that make sense?

Uhh...not really. Why would the default for a question ever be used once I've chosen an actual answer? When people hit "back", they expect to see the same panel they just left.

Correct, but as the developer you should be having unique questionIds then this issue will be resolved. :)

Ahh, I hadn't even noticed the CodePen questionId was duplicated. Unfortunately... I checked my real code, and there's no duplicate questionIds there.
I think I may have introduced a bug in the CodePen that's not related to the original issue. See this updated Codepen for an example where the conditional question doesn't appear when you go back: https://codepen.io/KingMob/pen/RMbVoM And if you comment out the default property, the conditional question appears correctly when going back.
(I suppose it's also possible I had two issues at once. E.g., some copy-and-paste and didn't notice I hadn't fully changed the copied question.)

Ah, okay this shows the bug! Reopening, CodePen v2 helps show the problem at hand.


isEmpty returns true for whitespace only strings

since isEmpty just checks if the string's length is zero, it still returns true given a string of only whitespace, which I feel, for most implementations is not what people need when checking if a string is empty.
Perhaps implementing .trim() on the string before checking if it's empty is worthwhile? Perhaps, if the original behaviour is to be maintained, and not break existing code the function could look something like this:
function isEmpty(string, allowOnlyWhitespace = true) {
  return (allowOnlyWhitespace ? string.length : string.trim().length) === 0;
}

Would love to make a PR if this is deemed a worthwhile addition.

I'm 50-50 on this one, just because we can't "see" the space character, doesn't mean it's not there (empty)... On the other hand, having this as a choice with allowOnlyWhitespace sounds like a good idea to me, not just for b/c.

@ProfNandaa I think that having an option for not allowing whitespace, as mentioned, is a good choice, so will make a PR to reflect this, and allow any other opinions to come up in PR review.

@ProfNandaa @ZooeyMiller Did this PR ever get written/merged in? If not, I'm happy to write it. I was literally just looking for this functionality, although I expected it to be under the name isBlank (coming from Rails).

Credits to @ZooeyMiller for the pull request :)

Fixed by #880.


App Lifecycle

Summary
Status

Customer / job-to-be-done: App developers using WPF, WinForms, or Win32 C++ need to register for certain activation types like file associations and startup activation, need to selectively single-instance their apps, and need to use power states to selectively suspend their apps.Problem: Non-packaged apps use a different set of APIs to achieve all of the above, and they also don't have access to power state notifications
How does our solution make things easier? All types of apps will benefit from the same single API regardless of app type, apps can now listen to power states, and WIn32 apps have a built-in easy way to single instance.

✅ Problem validation
❌ Docs
🔄 Dev spec
❌ Solution validation
❌ Implementation
❌ Samples

Summary
Provide a core set of functionality related to app activation and lifecycle. The initial release focuses on the following 4 main feature areas:

Activation.
Selective Multi-instancing.
Restart and Recovery.
Power/State Notifications.

Rationale

Enable all apps to register for the core activation contracts, consistently in the same way.
Enable all apps to use platform support for single-instancing, or selective multi-instancing.
Enable all apps to request immediate restart, or to opt in to recovery/restart in the event of app failure or system reboot.
Enable all apps to get power/battery/user/system-state change notifications so that they can be better power/battery citizens.

This aligns with Project Reunion's roadmap:

Enable all applications (packaged and not-packaged) to use the same mechanisms for managing app activation and lifecycle.

Scope

Capability
Priority

This proposal will allow developers to use the same mechanism to register for different activation kinds regardless of app technology (classic Win32, Windows Forms, WPF, UWP or WinUI).
Must

This proposal will allow developers to use the same mechanism to get rich activation event arguments regardless of app technology.
Must

This proposal will allow users to activate any app by double-clicking it in file explorer, or typing in a path in a command window.
Must

This proposal will allow developers to use a consistent mechanism to single-instance or multi-instance their apps, based on app-defined logic.
Must

This proposal will allow developers to use a consistent mechanism to take part in app and system restart and recovery.
Must

This proposal will allow developers to use a consistent mechanism to get power and system state notifications.
Must

This proposal will allow apps to better tune their operations to improve power/battery usage.
Must

This proposal will allow developers to take part in system resource management
Could

This proposal will allow developers to take part in app suspend/resume behavior
Could

Important Notes

This is not "yet another app framework" -- rather it is an easier way for all app types to use features in the platform consistently.
In some cases, we'll be providing parallels to existing APIs -- and the benefit is that converging traditional Win32 APIs with modern WinRT APIs into one component allows all app types to use the same APIs (instead of one app type using Win32 APIs, and another app type using WinRT APIs) consistently. This will also make it easier for app developers to move from one app type to another as appropriate -- they can continue to use the same AppLifecycle component regardless.
We will not wrap existing public APIs as this would result in a performance penalty -- rather, we will provide parallel APIs that use the same underlying primitives.
Whatever we build, we strive to make it as easy as possible for app developers to use. We aim not to introduce new hurdles, new development paradigms, or new architectural concepts that would cause friction. We also won't make the developer change what they're doing just because we version the Reunion component. As we add improvements/new features over time, these should "just work" seamlessly.

Rich Activation Behaviors
The activation part of the AppLifecycle component is focused on the
following 4 functional requirements:

Enable activation of any app (including Desktop Bridge and UWP) via CreateProcess on its path.
Enable all apps to register for any of the most common activation kinds.
Provide a GetActivatedEventArgs API that all apps can use to get any of the supported rich arguments for any of the supported activation kinds.

CreateProcess activation
In the Win32 world, it is normal to activate an app by calling CreateProcess (or ShellExecute), specifying the filesystem path to the executable file. When the user double-clicks an executable file in File Explorer, this uses that same mechanism. When the user types in an executable file name into a command window, the same thing happens. In contrast, up until now, when a UWP or Desktop Bridge app is activated, this is done via the app's Application User Model ID (AUMID). For example, when an app calls Launcher.LaunchUriAsync, it specifies the target AUMID -- or a file or protocol, which causes the platform to look up registered AUMIDs in its State Repository database, before activating
the app.
The Windows a-la-carte features introduced in 2004 include the ability to activate an app via CreateProcess on its path, as well as by the UWP AUMID lookup. The gap here is that the CreateProcess mechanism only works for Win32 apps -- as part of Reunion, we will bring this to packaged (Desktop Bridge and UWP) apps also.
With this, you will be able to CreateProcess a UWP app by specifying the path to its executable, or navigate to the filesystem location and double-click it there.
Activation kinds
UWP supports ~40 different activation kinds. Traditional Win32 apps have a much smaller set available -- the most common being file-type associations and protocol handling. In UWP both of these are formalized into specific activation contracts (ActivationKind.File and ActivationKind.Protocol) and when the app is activated in this way, the platform passes in rich FileActivatedEventArgs or ProtocolActivatedEventArgs. The same applies for command-line activation, activation at user login (startup activation), and so on.
Of the many different kinds of activation that UWP supports, 6 of the most commonly-used kinds are also supported for Desktop Bridge apps, and almost the same set is supported for Windows a-la-carte apps. We will support this core set of activation kinds for unpackaged Win32 apps also, plus command-line and restart activation. So the initial list is as follows:

Launch
File
Protocol
StartupTask
ToastNotification
ShareTarget
CommandLine
Restart

How should we ask developers to specify their registrations for the various activation kinds? For the activation kinds that are supported in Win32 -- such as file and protocol -- apps commonly write registry keys. Conversely, UWP apps write morally equivalent extension entries in their regular MSIX manifest.
Apps that write regkeys on install sometimes don't clean them up on uninstall, and this is a primary source of winrot. This is one of the main benefits of MSIX. Therefore, the proposal is to encourage app developers to specify their activation registrations in an XML manifest rather than in the registry.
An additional advantage of the manifest approach is that it also provides an easy way for the app to get identity. The proposal is that we ask an app to craft some subset of an MSIX manifest -- sufficient for the activation extension registrations, plus identity. We will not require that the app is MSIX-packaged, merely that they have a simple manifest. While this will be a subset of the full MSIX manifest, it must use the same schemas. The platform can then use the same Deployment Extension Handlers (DEHs) on deployment to register these extensions.
Activation and ActivatedEventArgs
Traditional Win32 apps expect to get their arguments passed into WinMain in the form of a string array. Windows Forms apps expect to call Environment.GetCommandLineArgs to return a string array. ulti-instanced UWP and Desktop Bridge apps can call the AppInstance.GetActivatedEventArgs API to return strongly-typed objects for each activation kind. We will provide a converged GetActivatedEventArgs which will get all args, regardless of activation kind -- including both traditional command-line activation and also the richer UWP activation objects. This will be available to all apps.
Activation broker
Two of the proposed activation kinds present particular problems: ToastNotification and ShareTarget. Both of these will likely require some additional component at runtime to act as a broker between the source and target of the activation.
The a-la-carte model has paved the way for apps of all kinds to get a system-recognized identity. This then provides several benefits when using modern features -- including the activation kinds under consideration for the undocked AppLifecycle component. We would like to use the a-la-carte model for undocked activation. However, there are a few issues:

The a-la-carte implementation is unfortunately very tightly coupled with the OS and the app platform, and it is infeasible to undock it in the timeframe of Reunion v1.
The model is only available from OS version 2004, but there is a desire for the undocked AppLifecycle functionality to be available down to OS version 1809.
For the same reasons that it is infeasible to undock a-la-carte, it is also infeasible to service the OS down to 1809 to include a-la-carte.
For ShareTarget specifically, the model uses a small MSIX broker which must be authored for each app. From 2004, ShareTarget can be achieved with just the manifest registration alone, no broker.

Identity
Both UWP and Desktop Bridge apps have an identity that is registered on the platform, and on which multiple APIs in the platform rely. Unpackaged Win32 apps do not have such an identity, and therefore cannot use any of the APIs that require identity.
In the Windows a-la-carte model, the app creates an XML manifest specifying its identity, and registers this with the system during install (or at runtime) via new PackageManager APIs.
There is an initiative in the Cobalt timeframe to enable the Store to serve up unpackaged Win32 apps in addition to UWP and Desktop Bridge apps. This is part of a general strategy of de-fragmenting the user experience of apps. Right now, there are several places where packaged apps are treated differently from unpackaged apps. A user experience example is the Apps & features page, where the options are differentiated. A more critical example is in the API surface where many WinRT APIs require the caller to have identity.
Crucially, some WinRT APIs behave differently depending on whether or not the caller has identity. Given that even unpackaged Win32 apps are already using WinRT APIs, we cannot apply identity unless the app specifically registers for identity. Instead, if an app wants to call an API, we should simply document whether or not that API requires identity, and guide the app developer to creating the appropriate manifest if they need it.
Single/Multi-Instancing
In the Win32 world, apps are multi-instance by default. That is, if the user launches Notepad 3 times in a row, they get 3 separate instances of the app. Conversely, in the UWP world, apps are single-instance by default: if the user launches Maps times in a row, the first request causes the Maps app to launch, and the second and subsequent requests cause the platform to make another activation call into the first (and only) instance.
Since Windows OS version 1803, a UWP app can opt in to multi-instancing via a manifest declaration. This feature also includes APIs to allow an app to declare itself to be multi-instanced, and yet to choose dynamically for each instance that is activated whether in fact it wants to redirect that activation to an existing instance instead. In this way, the app has the freedom to choose among several options:

constrain itself to a single instance
constrain itself to an app-defined finite set of instances
allow for an open-ended set of multiple instances.

Win32 apps have existing mechanisms (most commonly, named mutexes and named pipes) which they can use to achieve single-instancing in this context. There's also a Visual Basic Application Model which Windows Forms apps (whether written in Visual Basic or not) can use for single-instancing. The undocked AppLifecycle component will include a consistent, platform-supported API for selective
multi/single-instancing. This updates the UWP mechanism and enables it for use by Desktop Bridge and unpackaged Win32 apps.
The specific multi-instance redirection APIs that we will provide for all apps are all based on the existing WinRT
AppInstance class. The proposal is to expose equivalents to almost all AppInstance methods and properties from the new AppLifecycle class.
The existing APIs allow an app to intercept each activation, find any other running instances, and choose which instance to handle the new activation (either the current instance, or any other). The app doesn't control the activation event args -- these are simply directed to the chosen instance. In the Win32 world, apps have the opportunity to intercept the args, and therefore have the opportunity to modify/suppress/replace these args before forwarding them on. So, we propose to enhance the existing WinRT APIs to allow each activation to pass in additional payload to the target instance (at a lower priority, possibly deferred to a later release). This payload is in addition to the ActivatedEventArgs that the system originally passed in, and which the system will pass on to the target activated instance.
The multi-instancing part of the AppLifecycle component is focused on the following functional requirements:

Provide an undocked implementation of the existing AppInstance multi-instance redirection APIs so they are also usable by Desktop Bridge and unpackaged Win32 apps.
Enhance the multi-instance APIs to enable apps to intercept the activation args and manipulate them in any way they require: including modifying, suppressing or replacing them.
Provide an Activated event on AppLifecycle, specifically so that apps that are using multi/single-instancing can handle being the target of a redirection.

App Restart and Recovery
The CoreApplication WinRT class exposes the RequestRestartAsync method, which allows a UWP app to terminate and restart itself immediately, on request, and to provide an arbitrary command-line string for the restarted instance.
A related API exists in the Win32 world: RegisterApplicationRestart
and the matching UnregisterApplicationRestart API. This is intended for an app to register itself to be restarted if it was running when a system update occurs, or if it crashed or hung. This behavior is currently not available to UWP apps.
The use-cases for these 2 APIs are different, but related enough that it makes sense to offer both from the same place in the undocked
AppLifecycle.
Related to RegisterApplicationRestart, there are 2 further Win32 APIs that enable an app to save state or perform other clean-up operations prior to termination. As part of this recovery, the app can choose to update the command-line to be used when the app is restarted:

Let-me-save-state-before-termination. An app can call
RegisterApplicationRecoveryCallback
to register a callback for the system to call before terminating the app. If an application encounters an unhandled exception or becomes unresponsive, Windows Error Reporting (WER) calls the specified recovery callback, where the app can save state information. The system pings the app every n seconds to make sure that it hasn't hung in its callback. The app can specify the ping interval when it registers the callback. In its recovery callback, the app can call RegisterApplicationRestart a second time, to update the command-line.

Recovery-in-progress. While the app is doing work in its recovery callback, the app must periodically call
ApplicationRecoveryInProgress
-- if it doesn't call within the registered ping interval, WER will terminate the process.

These APIs will also be included in the Converged AppLifecycle component.

Undock RequestRestartAsync, to enable any app to terminate and restart itself, and to provide an arbitrary command-line string for the restarted instance.
For consistency with other activation scenarios, provide a new Restart ActivationKind and RestartActivatedEventArgs. This will encapsulate the app-supplied command-line payload. For old apps this is surfaced in the LaunchActivatedEventArgs. For new apps, they can use the new RestartActivatedEventArgs.
Alongside the RequestRestartAsync API, expose an additional RegisterApplicationRestart, which mirrors the Win32 app to allow an app to register itself to be restarted if it was running when a system update occurs. Also provide an associated UnregisterApplicationRestart.
AppLifecycle should include functionality equivalent to RegisterApplicationRecoveryCallback and ApplicationRecoveryInProgress.

Improved Power Usage
For UWP apps, a major factor in improving device power usage and battery life is that the platform can suspend an app if the user is not actively engaged in it. UWP apps are familiar with the suspend/resume aspects of app lifecycle. That said, the suspend/resume behavior is not without problems. Power usage and battery life is an important factor for users, and there are 2 main aspects in this spec:

System state changes: notifications that the system sends to an app when interesting battery/power changes occur (eg, switching
between AC and DC, critical power level changes, critical battery level changes, etc). In addition to power state, we'll send
notifications for other interesting events such as user inactive, screen off, and so on -- since these can also be used by an app to
better tune its work. All of these are simply informative notifications: the app can do whatever it likes with the information.

Suspend/resume or resource throttling: for UWP apps, the platform has heuristics to determine when to suspend or resume an
app, including whether the main window is minimized, whether certain critical background triggers are fired, and so on. The pattern here is more than a simple notification, specifically:
a.  There is a notification that suspension is imminent.
b.  There is an opportunity for the app to defer suspension for a finite period so that it can complete some arbitrary work. After
this period, the app will be suspended.
c.  There is a notification that the app is being resumed from suspension.

Note: it will likely be difficult for many Win32 apps to adopt UWP-style suspend/resume, but more apps might want to take part in resource throttling, and all apps could listen for interesting power/system-state notifications if they wish.

The proposed features for this part of the AppLifecycle component are as follows:

A new undocked API that provides equivalent functionality to Windows.System.Power.PowerManager.
Additional events in the PowerManager type, based off events used in PowerSettingRegisterNotification.
A new API for suspend/resume/throttle, plus a ResourceUsageChange notification. Merging with the RegisterForReducedUsage API -- that is, an API where the app can opt in and say "you can throttle me", or "you can suspend me".
Apps & features "good resource citizen" badge.

Power state changes
There are several existing APIs which apps can use to detect changes in battery/power status, in order to participate in improved battery life.

Windows.UI.Xaml.Application.Suspending, Windows.UI.Xaml.Application.Resuming
RegisterAppStateChangeNotification
RegisterPowerSettingNotification
PowerSettingRegisterNotification
SystemEvents.PowerModeChanged
Windows.System.Power.PowerManager

These APIs cover most if not all of the battery/power state change scenarios that apps would care about -- but there's no single API that is consumable by all app types. There's also no single API that's undocked from the OS. The proposal is to incorporate a clone of the W.S.P.PowerManager API in the undocked AppLifecycle component, and augment it with additional notifications based on the Win32
PowerSettingRegisterNotification API.
Suspend/resume and throttling
In UWP-style suspend/resume behavior, the constraints of the UWP app-container allow the system to suspend the app safely. Conversely,
traditional Win32 apps can't always reliably be suspended because they might be using system-wide resources (file handles, named pipes, etc), so suspending the app would lock these resources, and the platform has no mechanism to deal with this scenario. Such apps would not opt in to UWP suspend/resume.
What does suspend/resume actually mean? When an app is suspended it remains in memory, but its threads are not scheduled to run -- this
allows the system to restore it quickly when needed.
When does an app get suspended? In the UWP world, the most obvious manifestation is when the app's main window is minimized this is usually (but not always) following by the app getting suspended. The system can use its own heuristics and policies to decide when is a good time to suspend an app, including (but not limited to) when the app has no foreground, un-obscured or un-minimized windows.
What should an app do in its suspending handler? The key reason an app wants to know when it is about to be suspended is that there's no
guarantee that the system will ever resume it, and might terminate the app at any time while it is suspended -- therefore the suspending event is the app's opportunity to save state such that it can pick up again seamlessly when it is next activated. If a suspended UWP app is holding a file open, the system can terminate the app if necessary to release the lock.
Even some UWP apps have found that the suspend/resume behavior can be difficult to work with. One mitigation that the platform offers is the option to take a SuspendingDeferral
in the Suspending event handler. The app is given a SuspendingEventArgs which includes a method to request a deferral. On top of that, beyond a simple deferral, an app can request an ExtendedExecution -- including potentially an indefinite extension (although this is rarely granted, by policy).
Given the difficulties that UWP apps experience with suspend/resume, and the added complexities of Win32 apps which perform operations outside the control or awareness of an app-container context, it is most likely that very few complex Win32 apps would be able to use UWP-style suspend/resume, and a trivially simply Win32 app is unlikely to be a significant resource-hog. However, there are likely more apps that could take part in some form of throttling -- and especially if the throttling is under app control. Exactly how this throttling might work is TBD.
Recognition for good citizens
Apps will want to opt in to lifecycle and resource management because they want to be good citizens. To further incentivize apps, we should also surface this to the user in some way. One approach would be to add a "battery-aware" or "good resource citizen" badge in the Apps & features list in Settings, similar to the badge used in the traditional TaskManager (although this badge is conferred simply whenever the app is suspended).
We could apply the badge for any app that opts in to throttling and/or suspension. Note: simply registering for power state change
notifications is not enough to qualify: the app could respond to low power/battery states by doing less work -- or it could respond by doing more work.
It has been pointed out that neither TaskManager nor the Apps & Features page in Settings are highly visible, especially to a non-technical user. Two other options present for consideration:

Show a notification for excessive usage -- more of a stick than a carrot.
Put the good-citizen badge on the app's icon in the taskbar and/or in the app's window chrome (if it has any).

Final implementation TBD.
Open Questions

Should we include the broker model in v1 of Reunion so that apps can target down to 1809, or do we defer support for ShareTarget
-- and avoid the need for a broker -- until a later release when apps might be OK with targeting only down to 2004?
Can we provide a way for unpackaged apps to have identity without undocking the whole of Windows a-la-carte?
Is there any suspend/resume or resource (CPU, network) throttling behavior that would actually be useful for a traditional Win32 app to take part in, or is this just too difficult to work with?

Would this be a good place to consider how the app behaves when an App Update is installed from the store, to prevent apps restarting in the middle of the user working on an unsaved document?

Should #9 be closed in favor of this?

@mdtauk permissions are mostly relevant only within the context of an AppContainer, so this proposal alone won't do anything to enable Win32 apps to have the same experience as UWP apps. We're interested in doing more here but it should be a separate issue.

As a part of these changes, it would be great if UWP app activation no longer relied upon explorer.exe running!

@dremin - we're definitely aware of that! Is there a specific use case you're looking for that it'd enable for you?

@jonwis For me, that would be fantastic to allow for alternate shells (such as one I maintain) to continue to exist in the future. As more functionality moves into UWP applications, alternate shells have unfortunately become far less feasible (and running an alternate shell atop Explorer brings its own set of issues).

Feedback

The proposal uses some internal jargon that requires definition:

Windows a-la-carte
Cobalt timeframe

The proposal has spacing issues that need correction and would greatly improve readability.

Questions

With regards to CreateProcess activation of modern apps, the proposal suggests "you will be able to CreateProcess a UWP app by [...navigating to the] filesystem location and double-click". With most modern apps being delivered via the Microsoft Store, this puts apps in an un-browsable location on disk. How will users double-click these app executables? What if the app has multiple applications in its manifest?

With regards to activation, the proposal suggests that apps should have a "simple manifest", perhaps "a subset of the full MSIX manifest". The proposal, however, leaves the location of this manifest open-ended. Will this manifest sit side-by-side with the executable? Can it be embedded, a la fusion manifests? (highly recommended)

Answers to open questions

Should we include the broker model in v1 of Reunion so that apps can target down to 1809, or do we defer support for ShareTarget -- and avoid the need for a broker -- until a later release when apps might be OK with targeting only down to 2004?

Target 1809. 1809 EOL is May 11, 2021. Users will not be able to min-target 2004 until ~May 10, 2022.

Can we provide a way for unpackaged apps to have identity without undocking the whole of Windows a-la-carte?
It's not clear what "undocking the whole of Windows a-la-carte" refers to. But I suggest re-using the appxmanifest approach as outlined in Activation kinds above.  Or update an app that restarts the shell to update a shell extension. When I do these things, app modern apps often terminate.

@riverar FYI clean shutdown of explorer is possible when its not hung, in the shutdown dialog (e.g. click the taskbar and Alt+F4) hold ctrl+alt+shift and press cancel. This is documented for explorer extension authors to test their extensions without rebooting.
Never tested this before so I don't know if its consistent across versions but UWP apps seem to stay open and stop rendering when you close explorer this way, when you restart explorer they all seem to close. In general very poor behavior.

@weltkante TIP: Ctrl+Shift then right-clicking Taskbar also offers a Exit Explorer option.
Where is this officially documented? It doesn't work properly on Windows 10 Version 2004. My Mail app terminated. Further, starting a new File Explorer process resulted in a shell load/crash loop that I had to resolve manually.

Thanks, wasn't aware.

Where is this officially documented?

That was years ago when I had to write an explorer extension, seems the docs are updated to use the method you mentioned, but they still list the other method as well, even if not recommending it.
I mostly just chime in when someone speaks of "killing explorer" because clean shutdown is often preferrable to killing processes. Will mention your method in the future since it seems preferable.

@stevewri I see the "needs-triage" tag was removed. Can you provide more details as to what that means for proposals as such? I have unanswered questions above.

Needs-triage is the bot-assigned label for new issues; triage is just the process of routing it to the right area label and owner.
From: Rafael Rivera<EMAIL_ADDRESS>Sent: Tuesday, July 21, 2020 6:28 PM
To: microsoft/ProjectReunion<EMAIL_ADDRESS>Cc: Steve Wright<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/ProjectReunion] App Lifecycle (#111)
@stevewrihttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstevewri&data=02|01|swright%40microsoft.com|84ef610348a147775b8c08d82dde6ad9|72f988bf86f141af91ab2d7cd011db47|1|0|637309780580265601&sdata=7V4f5P%2F840VT6dSb1EtfedvFrvJhrCGgZWfzrHKHgnw%3D&reserved=0 I see the "needs-triage" tag was removed. Can you provide more details as to what that means for proposals as such? I have unanswered questions above.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FProjectReunion%2Fissues%2F111%23issuecomment-662188962&data=02|01|swright%40microsoft.com|84ef610348a147775b8c08d82dde6ad9|72f988bf86f141af91ab2d7cd011db47|1|0|637309780580275557&sdata=AEDyJDmohk5Q5K2ldwBXzIK5xe8lfhbPsOT4KkOAzXE%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAPVPII2NLE2NJWRSEKIMG5TR4Y6ARANCNFSM4OZ65PWA&data=02|01|swright%40microsoft.com|84ef610348a147775b8c08d82dde6ad9|72f988bf86f141af91ab2d7cd011db47|1|0|637309780580275557&sdata=RDqrA2r4sfcAjCy6oxdc8iyNx1FZVmbNVd0CjlT1QP4%3D&reserved=0.

@andreww-msft Reading this proposal made me think about Microsoft Edge's use of sparse MSIX to register PWAs/better integrate with Windows. (Currently behind a flag)
When you say any "app technology", are you referring to scenarios like this? In other words, is it possible for sparse MSIX packages registered by Edge to take advantage of the WinRT app lifecycle improvements?

Would it be possible for an app to declare, as a UWP app declares capabilities, it's need to remain open until the user shuts it down? This is important for business apps. I know most of these currently are Win32/Web, but moving forward this capability should be available I think.

Hi @VagueGit, can you be more specific? Apps can already use confirmAppClose to implement "Are you sure you want to exit?" style dialogs, and extendedExecution on Desktop to keep running when minimized. Is there another scenario you're thinking of?

@ptorr-msft Currently we have to deal with UWP apps being suspended and request an extendedExecution, but this might be denied. It would be nice not to have to deal with it at all.
If the app could declare on install that it doesn't want Windows to suspend it and give the user the option to accept that, then the issue goes away. We have both UWP and Win32 versions of our business app and our customers are used to leaving the app open all day.

Thanks for the extra info. I agree it's a useful feature to add (whether it's a manifest opt-in or something else that is easier to manage than "sessions").
In the meantime, as long as your users are on Desktop and not running on battery, the Extended Execution should run forever. If they are running on battery power, there is a setting they can use to still enable the app to run forever (see Run with Extended Execution)

I started looking at WinUI and am confused.  I have the option to choose a WinUI Desktop project or a WinUI UWP project.
In the UWP project I noticed that a MainPage is created.
The Desktop project a MainWindow is created.
Why are their pages in the UWP project and Windows in the Desktop project?  What fundamentally is the difference?
Why are there these two platforms? I thought the idea was to allow developers to create a single Windows development environment that targets all API's. kind of like a reunion?
Which project platform do we target going forward?  There is massive investment when building a LOB app, We want to ensure we have chosen the correct platform before investing in thousands of hours of development.
As @VagueGit says, surely it is easier to offer a single platform so third party tools venders can build tools with confidence and not go in half baked because they are unsure of the traction a platform may have.
Where can one find more information on the differences between WinUI UWP and WinUI Desktop and Pages verses Windows?

Very good points, and the dichotomy between "Win32" / "UWP" in this area is something we're acutely aware of. The best place to learn / create issues / etc. is on the WinUI repo; I would suggest looking at The WinUI 3 roadmap and commenting there.

Hey @ptorr-msft, why are named pipes not working incase of a packaged desktop apps?
I couldn't wait till Project Reunion is released just to have single instance apps, so I made my own implementation using Mutex and Named Pipes for a packaged WPF app.
They work perfectly fine when the app is either started as an unpackaged app or deployed from VS. But once the app is published as an MSIX or to Store, this issue happens. The Documentation states that we need to add LOCAL to the pipe name (i.e. like this "\.\pipe\LOCAL"). But would it work for my case?
I saw a repo which demonstrates a way to communicate between a UWP app and a Console app within the same container? But it is so complex. Are there any other ways to do it?
It would be so great if you could help me with this issue 🙏

@mikebattista is that \.\pipe\local requirement for all packaged apps, or only AppContainer apps?

I'd like to chime in on @VagueGit's comment:
Working with document centric applications it's confusing that UWP apps can be closed by the user without being asked to "save unsaved documents" along with the corresponding workflow. It leaves a disquieting, uncomfortable, dubious feeling behind.
Wouldn't it be reasonable to add a cancellable OnCloseRequested event to an app's lifecycle?

Found https://github.com/microsoft/ProjectReunion/issues/59

I think command-line activation is not curently good for UWP bécause the CommandLineActivationOperation expose the command line arguments  as string instead of string[]  like all the Win32 App models
It can be useful to add a property to expose arguments as string[]in CommandLineActivationOperation object and maybe depreciate the old arguments property or create a helper to do this.

Will there be a functional equivalent for CoreApplication.EnablePrelaunch(Boolean)?
This would fit nicely with the activation and performance (and being a good citizen) parts of this item.

@RobMeyer just to be clear, are you asking because you want to opt IN to pre-launch (the current default is to not pre-launch)?

@ptorr-msft Yes, that’s right. I’d like to opt-in to prelaunch. We’d also need activation args to differentiate a prelaunch vs regular launch.

@RobMeyer you're suggesting string[] CommandLineActivatedEventArgs.Arguments akin to
string[] Arguments()
{
    argv = CommandLineToArgvW(this.Arguments, &argc)
    args = new string[argc];
    for (int i=0; i<argc; ++i)
        args[i] = new string(argv[i])
    return argv
}

where .Arguments is parsed per CommandLineToArgvW ?

@DrusTheAxe I don't think CommandLineActivatedEventArgs is related. I'm referring to the UWP PreLaunch functionality which has two parts.

Opt-in to pre-launch by calling CoreApplication.EnablePrelaunch(true)
Detect and handle prelaunch. There are some app workflows that need to take prelaunch into account. For example, a music player like Spotify might want to auto-play music on launch or a camera app may want to start accessing the camera and microphone data, but this doesn't make sense in the context of prelaunch. UWP apps do this by checking the LaunchActivatedEventArgs.PrelaunchActivated property, typically in Application.OnLaunched.

@RobMeyer I was thinking about the .Arguments part of your coment. LaunchActivatedEventArgs has a .Arguments property so it should also expose this .ArgV equivalent but ditto any other *ActivatedEventArgs with .Argument[*] properties -- DialReceiverActivatedEventArgs, GameUIProviderEventArgs, etc
You're thinking specifically of Prelaunch of non-Universal apps? e.g. something akin to
boolean IsPrelaunchActivation()
{
    var args = AppInstance.GetActivatedEventArgs()
    return (args.Kind == ActivationKind.Launch) and ((IPrelaunchActivatedEventArgs) args).PrelaunchActivated
}

You don't need different arguments for different prelaunch activations? Is that even possible?

currently, all packaged apps be it win32 or UWP suffer from this Packaged Apps Update issue.   they just never save the current app data state during package updates and also never restarts itself after an update has been installed. so if an update has been installed all the unsaved data gets lost.😕
I will like Project Reunion consider & provide something like :.
installing package updates (store or I myself locally through App Installer) ➡ check if the app is open ➡ if not open , apply update silently ||| or if open, save all the unsaved current working data/app state ➡ terminate the process & apply package updates ➡ restart the app itself and restore the all the unsaved current working data/app state.           everybody happy.
This is a pain and needs to be fixed ASAP.

currently, all packaged apps be it win32 or UWP suffer from this Packaged Apps Update issue.   they just never save the current app data state during package updates and also never restarts itself after an update has been installed. so if an update has been installed all the unsaved data gets lost.😕
This is a pain and needs to be fixed ASAP.
I will like Project Reunion consider & provide something like :.
installing package updates (store or I myself locally through App Installer) ➡ check if the app is open ➡ if not open , apply update silently ||| or if open, save all the unsaved current working data/app state ➡ terminate the process & apply package updates ➡ restart the app itself and restore the all the unsaved current working data/app state.           everybody  is  happy.  👍

@ecovio1 that's unexpected. Your ask of Project Reunion is unnecessary, as that's how Windows (is supposed to) work. Thank you for raising the issue. @kanismohammed is investigating.
FYI Windows won't service a package while it's in use, i.e. running processes are using it. PackageManager.AddPackageAsync() etc will fail, unless a DeploymentOptions.Force* option is specified. Then running processes are 'stopped', as in, suspend semantics -- tell the process it's being suspended, and if it doesn't stop in a timely manner it's TerminateProcess'd.
Let's continue this discussion on the Packaged Apps Update issue thread as it's more extensively discussed there.

Concerned with the event handler delegates not being strongly typed. As a developer, if I've registered to an event, I expect to just get the latest relevant data I need from the event arguments like other .NET and UX events do (mostly or should). See event design from .NET framework guidelines.
Otherwise, I also can't just proactively discover how to use the API after finding the root type PowerManager. I'm forced to search for up-to-date documentation or a sample to understand how to respond and utilize events effectively vs. just grabbing a property from the EventArgs for straight-forward access, unless I need to correlate multiple values (less common).
It's also handy to know what the sender is of the underlying type (like a PowerManager instance). I may register an event in a different context, and thus may not have access to the original object from the context in which I registered the event (though if PowerManager is a singleton this isn't as much of an issue).

I really hope the "good resource citizen" badge or an equivalent is added.

For unpackaged applications it would seem that the intent is for the application (or installer) to be responsible for registering and unregistering. The question then is, what happens if an unpackaged application doesn't unregister - for example, if the user simply deletes the application folder, or moves it to a different location? Is there a mechanism where the cleanup (ie unregistering) can be automated?

I beg the team to please consider my proposal (https://github.com/microsoft/ProjectReunion/issues/126) when creating the design of the manifest for this feature. My proposed changes would immensely benefit from a little forethought here. Thanks!

Many single instance desktop apps today just either terminate when a new instance is created or show an message box that an instance is already running. Even more, there's a difference between multiple windows in a single instance versus multiple instances. UWP has the concept of the MainView which is created by the OS however since Win32 desktop apps create their own window, it should be handled in the framework level and not the app model level to switch to the right window when a new instance is created

For unpackaged applications it would seem that the intent is for the application (or installer) to be responsible for registering and unregistering. The question then is, what happens if an unpackaged application doesn't unregister - for example, if the user simply deletes the application folder, or moves it to a different location? Is there a mechanism where the cleanup (ie unregistering) can be automated?

Well, that is after all one of the benefits of MSIX packaging and deployment, and an unpackaged app misses out on those benefits. For the platform to be able to fully track unpackaged app uninstall/move/delete would require significant infrastructure that would probably parallel the MSIX infrastructure.

I beg the team to please consider my proposal (#126) (and possible future extensions) when creating the design of the manifest for this feature. My proposed changes would immensely benefit from a well-thought out manifest container. Thanks!

Yes, thanks Rafael, #126 is under consideration.

Many single instance desktop apps today just either terminate when a new instance is created or show an message box that an instance is already running. Even more, there's a difference between multiple windows in a single instance versus multiple instances. UWP has the concept of the MainView which is created by the OS however since Win32 desktop apps create their own window, it should be handled in the framework level and not the app model level to switch to the right window when a new instance is created

Different apps have different requirements here. We want to be very careful not to force all apps into one path. So instead we provide tools where each app can choose how it wants to behave - and in fact, can make this choice dynamically. This leaves control firmly in the hands of the app itself.

@nickrandolph For unpackaged applications it would seem that the intent is for the application (or installer) to be responsible for registering and unregistering

Yes - as they already are. If you're an MSIX package then your "installer" is Windows (and more specifically, the MSIX deployment pipeline in windows). If you're not an MSIX package then you have an install model (run foosetup.exe or foo.msi, unzip foo.zip, even XCOPY has an install model -- copy foo.exe(+friends)). You can use Project Reunion to supplement your app. Like many components and frameworks, Project Reunion has 'install' needs to 'register' appropriately with Windows (and uninstall/deregister on the flip side).

what happens if an unpackaged application doesn't unregister
Same thing that happens with any other component/framework that's installed and not uninstalled. Ideally it's inert (just using some disk space) but YMMV, depending on the framework.

for example, if the user simply deletes the application folder
If ProjectReunion is installed via MSIX framework packages then its files don't live with the application, they live where the package is managed by Windows, e.g. C:\ProgramFiles\WindowsApps\Microsoft.ProjectReunion.0.5_<IP_ADDRESS>_x86__1234567890abc, and since it's managed by Windows it's possible to cleanly remove it (worst case, via powershell -c Get-AppxPackage *reunion*|Remove-AppxPackage).

Of course that assumes the app that installed ProjectReunion is the only one using it. That's unlikely (especially over time). You wouldn't want to remove ProjectReunion if any app on the system needs it.
OTOH if an in-app deployment model is used then any registrations and the app's directory is deleted (or at least Project Reunion's files) then whatever's wired up won't be found if/when Windows tries to access it. Impacts depend on the nature of the registration and can range from nothing (inert, not used) to error dialogs ("I need to run X but can't find it"), broken functionality  or other negative user experiences.

or moves it to a different location?
Any registrations needing those files would result in the same experience as if you deleted them. Unless you tell Windows "these files? they're over there now" it's the same broken experiences.

Is there a mechanism where the cleanup (ie unregistering) can be automated?
Ultimately PackageManager.RemovePackageAsync() is the key to removing an MSIX package. If it can be removed - some can't, for varying reasons. Some packages can't be uninstalled (e.g. Settings) as it would break Windows. Framework packages can't be removed if there's any package dependent on them (again, ripping out FoooFramework.msix would break Bar if BarMain.msix depends on it).

Generally MSIX packages can be uninstalled (if it wouldn't break things). Some people have asked Project Reunion to not be uninstallable, as they view it as critical infrastructure where the cons of being uninstallable (causing problems and support headaches) outweighs the value of being uninstallable. Project Reunion 0.5 is uninstallable (if no one's dependent on it). We are of course interested in developers needs and desires so the feedback is being considered (as is all input).
Good discussion but we're drifting off the App Lifecycle topic. If there's additional questions or issues we should discuss them under new Issues or Discussions more focused on the matter(s).

@DrusTheAxe in the case on in-app deployment, I see the lack of automated cleanup to be a nasty side effect. I get that the whole point of having installers (and ideally MSIX) it to provide for cleanup but if we're providing a mechanism for apps to register (for the in-app deployment scenario), can't we provide a mechanism where cleanup can be done automatically if the app or folder is deleted, or moved. I guess this is something that the community could provide......

@nickrandolph can't we provide a mechanism where cleanup can be done automatically if the app or folder is deleted, or moved
Yes, I think we can. In particular I'm thinking of the LifetimeKind + LifetimeArtifact model like in MddTryCreatePackageDependency.
Ideally we'd want LifetimeKind + LifetimeArtifact parameters on the deployment APIs next to ExternalLocation, so you could specify "here's my stuff AND automagically remove me if this thing is gone". Since we're talking ideal  we'd want various codepaths to check/handle this as well as a general maintenance task (i.e. garbage collection) to run every so often.
Doing something equivalent in Project Reunion is possible, at least in part. I'll need to think on it some more and talk with a few folks but, yes. This does look very promising. Thanks for the suggestion!

Some additional things I would like to see in new App Lifecycle management for multi-instance scenario:

Ability to check if an instance is pre-launched, this would come handy when an app is trying to create new instance and instead of creating one they can redirect activation to pre-launched instance for better performance.

Ability to check if there is any instance present in the external display/virtual desktop the activation initiated. One of the pain points in multi-instancing is when user switches to external display/another virtual desktop and launches app/ tries to open file with an app and being dragged to the other virtual desktop where app is already present. This would allow apps to launch a new instance instead of redirecting activation in such scenarios.

Question: which WinUI preview release was the to include support for lifecycle management in UWP apps?
Note: a lot of the notes on changes to the lifecycle API are only present in versioned GitHub links to transient versions of MarkDown documents in the repo that are no longer available in HEAD/master. Is there a single "source of truth" document that survives that includes the changes to the APIs?

Is there a single "source of truth" document that survives that includes the changes to the APIs?

I believe that would be docs.microsoft.com. Process lifetime management is a broad set of related apis and has changed/grown over time, so you’ll want to look up a specific api endpoint to see when it was introduced. For example, https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.activation.appointmentsprovideraddappointmentactivatedeventargs?view=winrt-20348 was introduced in v1.0, 10.0.10240.0

Is the RequestRestartAsync working? I tried it in my WindowsAppSDK V0.8.1 app and it seems to not be working.

Is the RequestRestartAsync working? I tried it in my WindowsAppSDK V0.8.1 app and it seems to not be working.

RequestRestartAsync is only for UWP apps. In a desktop app, you can start a new instance of your app and terminate the current one.

I have observed GetActivatedEventArgs() returning null in packaged WinMain applications under Project Reunion 0.8.x and Windows App SDK 1.0.0-experimental1.
I have a hunch that this might be because the kind of activation is one of the ~34 other types that @andreww-msft didn't explicitly mention (Launch, File, Protocol, StartupTask, ToastNotification, ShareTarget, CommandLine, Restart). Is there no way for packaged (or unpackaged) WinMain apps to handle being activated in response to such an event, even if it requires manually piecing together an instance of IActivatedEventArgs from various, disjoint sources and then invoking App.OnActivated/App.OnBackgroundActivated/etc yourself?

Why was this issue closed @aeloros when it hasn't been fully implemented yet.

This issue was closed because it is fully implemented.  If there are bugs in the code, then they should be filed as separate issues.  This issue was for the initial implementation which is done.

Folks
Although this issue is closed, I wanted to clarify a few points. This was the very first Reunion/Windows App SDK feature document to be published - at a time when we were still very much feeling our way through a whole bunch of new processes around how we would publish docs and specs. We wanted to get the doc out very early, to gather feedback - and we have indeed received a lot of feedback - so many thanks for that!
Reading through all the comments again, it's clear there's been a little confusion: it's worth calling out that the doc was to some extent aspirational - it was a set of proposals rather than a committed detailed design. The more detailed API specs for AppLifecycle features were published much later. This initial doc therefore contains some ideas that we ended up changing as we fine-tuned the designs, and some ideas that got re-shuffled in the schedule, for example, the Restart support is now targeting 1.1. Another example: we originally proposed unpackaged support for 8 activation kinds, but it turns out that Launch and CommandLine are indistinguishable for unpackaged apps, so we combined these, and we deferred ToastNotification and ShareTarget to later releases.
Going forward, I'll leave this document as is, for historical reference. The aforementioned API specs and the docs.microsoft.com documentation should be considered more accurate references. Also, for suggestions for improving or extending the AppLifecycle support, we'll file new issues. For example, I've just created a new issue 1709 for improvements to the instancing redirection APIs. Of course, we're also considering issues that other folks file, such as 126 Loosen import redirection restrictions from Rafael.


Make PVC storage size configurable for each app

Purpose
PVC storage size are currently hard-coded to a default 2Gb size. There is room for improvement to make it configurable.
Proposal

[x] add a volume_storage_size variable for each application's volume
[x] use this variable in each PersistentVolumeClaim template

Fixed in #178


CCDB GE/045 - Section <IP_ADDRESS>.3

Para 496
Comment:
Regarding the table, what value is in the cell "Pseudorandom salt values" x "SP 800-108".  Should it not be "n/a" like in the cell below? Leaving the cell empty is misleading.
Proposal:
Priority:

Agree, v1.1 fix


Layer multiple instances of  on top of one another to create a cool layering effect?

Might not actually be a bug (just wondering if a certain thing is possible to do in vue-parallax)
Right now, I’m trying to layer together about 6 images to have a cool effect (whereby further assets scroll slower than closer ones).
I can’t seem to figure out how to layer all the parallax windows on top of one another (without setting position to absolute, which obviously breaks the parallax plugin).
Any help would be mightily appreciated.
Thanks,

Hey @gilgameshskytrooper
Mhh I think this is not really possible right now. Because this use case was never intented.

cool. thanks


LambDynamicLights implementation doesn't seem to work

hi! i'm trying out clean f3 in a small 1.21.4 modpack and it seems that even with the option "hide lambdynamiclights' debug info" on, the supposed info still appears, is this a bug? thanks x)

This is a duplicate of #30.
As I've warned the debug lines changed in LambDynamicLights' v4, which this mod's current code doesn't currently catch.

I have been very busy irl over the last few weeks, so I couldn't take care of this earlier. It will be fixed in the upcoming release soon!


[doc] correct copyright info

这个地方其实是不是可以直接用 © ？

👍👍 可以可以 这样简单些

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

Is it possible to use © directly in this place?

👍👍 It can be easier

@earthjasonlin 还有这个位置得辛苦改下 https://github.com/dromara/hertzbeat/blob/master/web-app/src/app/layout/basic/basic.component.ts#L83

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

@earthjasonlin and this position has to be changed https://github.com/dromara/hertzbeat/blob/master/web-app/src/app/layout/basic/basic.component.ts#L83

@earthjasonlin 还有这个位置得辛苦改下 https://github.com/dromara/hertzbeat/blob/master/web-app/src/app/layout/basic/basic.component.ts#L83

改完了

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

@earthjasonlin and this position has to be changed https://github.com/dromara/hertzbeat/blob/master/web-app/src/app/layout/basic/basic.component.ts#L83

Finished

@all-contributors please add @earthjasonlin  for code, doc


The images on the sample projects - samplepr2.html

The file samplepr2.html have faulty images or maybe the images are not available in the main directory.

In any case, that needs to be sorted out.
Thank you!!

Considering you've previously worked on the Project section PR, would you want to be assigned for these issues?

Sure I would.

You can assign me to all 4 issues in the sample project folder. Thank you!!

Since the sample projects folder is deleted, this issue is closed.


Verification of tenant compatibility during the process of OneDrive migration

You should move the part about verifying the tenant compatibility at the very top of the process.

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

ID: 6e0e727b-b868-8c3d-8baf-2995c5cd6ca2
Version Independent ID: 6e0e727b-b868-8c3d-8baf-2995c5cd6ca2
Content: OneDrive Cross-tenant OneDrive migration Step 5 - Microsoft 365 Enterprise
Content Source: microsoft-365/enterprise/cross-tenant-onedrive-migration-step5.md
Service: sharepoint-online
Sub-service: sharepoint-migration
GitHub Login: @JoanneHendrickson
Microsoft Alias: jhendr

@jrfuste Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/12516
Once the author approves, the changes will be live.
Thanks
Sri

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful
Article was unhelpful

Finally, select Submit and you're done!


Added a 'Note' part.

The 'Note' part describes how we can check for odd even with the help of & operator.

[ x] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[ x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


[Text] Underline with intercepts

What's is underline intercepts? - g,j,y,p chars are intercepting underline and to render it good some render engines are making spaces before and after intercepts.
See underline on screenshot below. It's splitted.

This feature was implemented in Lunacy. I'm just sharing it. I hope you need it. It's ok to reject/rework.
Sorry for a huge screenshots. To see a difference you should zoom in.
What does the pull request do?
Adds intercepts to underline.
What is the current behavior?
Now it works like this:

What is the updated/expected behavior with this PR?
Should work like in chrome:

After implementation it works like in chrome:

How was the solution implemented (if it's not obvious)?
I use SKTextBlob.GetIntercepts method to get underline intercepts.
I didnt' implement this method to dx2d render platform. Don't know how. Anyway code fallbacks to previous non-intercepted underline.
Checklist

[ x] Added unit tests (if possible)?
[ x] Added XML documentation to any related classes?
[ x] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

I think we should just add GetIntercepts to IGlyphRunImpl and implement the underline feature on top of it instead of having UnderlineData etc.
Thanks for sharing your solution.

You can test this PR using the following package version. 11.0.999-cibuild0028455-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

Currently trying to work out how to calculate interceptions at custom positions like Overline etc. after that this will be ready for merge

You can test this PR using the following package version. 11.0.999-cibuild0028535-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0028544-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]


Scrape fails with connection reset by peer

I have targets migrated from Jetty 9.2 to 9.3 and scraping start failing with exception: connection reset by peer.
If Jetty 9.2 is used on target then scraping doesn't fail.
It seems that Go http client in Prometheus Server doesn't work well with Jetty 9.3 "half-closed" connections.
This is probably related to https://github.com/eclipse/jetty.project/issues/359
Can anyone else confirm this issue?

Do you have reason to believe that Prometheus is acting incorrectly here?

Problem solved on server side. Go HTTP client handle connection closing correctly.


[Event Request] Codeunit 5883 "Phys. Invt. Order-Post (Y/N)"

Could you please add the following event and code to Codeunit 5883 "Phys. Invt. Order-Post (Y/N)" event subscriber OnRunPreview:
    IsHandled := false;
    OnBeforeRunPreview(Result, RecVar, IsHandled);
    if IsHandled then
        exit;

Example (code with **):
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Gen. Jnl.-Post Preview", 'OnRunPreview', '', false, false)]
    local procedure OnRunPreview(var Result: Boolean; Subscriber: Variant; RecVar: Variant)
    var
        PhysInvtOrderHeader: Record "Phys. Invt. Order Header";
        PhysInvtOrderPost: Codeunit "Phys. Invt. Order-Post";
    begin
       **IsHandled := false;
        OnBeforeRunPreview(Result, RecVar, IsHandled);
        if IsHandled then
            exit;**

        PhysInvtOrderHeader.Copy(RecVar);
        PhysInvtOrderPost.SetPreviewMode(true);
        Result := PhysInvtOrderPost.Run(PhysInvtOrderHeader);
    end;

Publisher:
[IntegrationEvent(false, false)]
local procedure OnBeforeRunPreview(var Result: Boolean; RecVar: Variant; var IsHandled: Boolean)
begin
end;

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


How to set height of all elements by most large height.

https://jsfiddle.net/JJaun/o29a4q45/
How to implement in react

Any solutions/workarounds?

This is not a carousel specific problem

it is. Only way is to set rows: 0 as seen resolved in ☝  jsfiddle that is now implemented using slick.js (not react-slick).
But does not work with react-slick due to this issue where now setting rows: 0 crashes the app.
A fix with issue #1254 will hopefully resolve this.
Unless you can demonstrate any other way??

For my own purposes I was able to set height of elements to largest height with this css:
`.slick-track {
display: flex;
.slick-slide {
    height: auto;
    display: flex;

    > div {
        display: flex;
        width: 100%;
    }
}

}`

For my own purposes I was able to set height of elements to largest height with this css:
.slick-track {
    display: flex;

    .slick-slide {
        height: auto;
        display: flex;

        > div {
            display: flex;
        }
    }
}

Thank you so much, my friend! It works!

For my own purposes I was able to set height of elements to largest height with this css:
.slick-track {
    display: flex;

    .slick-slide {
        height: auto;
        display: flex;

        > div {
            display: flex;
        }
    }
}

Save my day!
tks!

I love you 3000

For my own purposes I was able to set height of elements to largest height with this css:
.slick-track {
    display: flex;

    .slick-slide {
        height: auto;
        display: flex;

        > div {
            display: flex;
        }
    }
}

i love you 3000


Remove compilesdk validation

This will remove the strict versioning of some Android libraries that prevented enforcing a compileSdk version higher than 33. It should help solve this issue.

Same in happening in latest version 0.19.0. Please fix it.

@LikeTheSalad Any version which support without upgrading to android 34.

Version 0.15.0 was the latest one that didn't require upgrading to Android 34.


npm support

Hi!
I guess, it would be handy to publish the loader on npmjs.com to make it friendly for, say, browserify users.

@gaydenko Thanks for the suggestion. I thought about adding LoadJS to NPM but decided against it because:

LoadJS is meant to be inlined in the HTML so you can start using it without fetching a separate file
NPM/Browserify users have more sophisticated script loading capabilities at their disposal

Maybe I'm not thinking about it the right way though. I'd be curious to hear your thoughts on the LoadJS/NPM issue.

At the moment I use script.js bundled into SPA to load external service script (the last one can depend on user-agent and/or geolocation and can not be included into SPA bundle). That is by "loading" I mean something remote :)

On the other hand such tiny library can be easy included directly into an app, so closing the issue.


Codecov not configured correctly

Describe the bug
I'm not sure if this is the place to raise this issue, but there's some problem with how codecov interprets information, or something related with it.
Check out the warning introduced here for https://github.com/OCA/account-financial-tools/pull/1424.
Just in case it gets garbage-collected, I put here a screenshot:

The warning is wrong because that line was of course executed by a test (it is a test!):

Expected behavior
No warning.

Could it be that line 61 raised and line 62 was not executed?

If 61 is not executed, test fails. Dont you think ?

The test will succeed if 61 raises the expected ValidationError.

Ah of course! I didn't realize this is an assertRaises. 🤦🏼♂
Thanks folks.


borders same size and perfectly aligned, signup button visible, solid…

@yyppsk please assign it to me.

it is same as original design i have just aligned the borders and also made the signup button visible by translating the full box above.

Original :

After Your Code:

It's UI is now looking more appealing and also sign up button became visible, which couldn't be dine without moving the box up, ping me and say the changes in the original you'd like then.

It's UI is now looking more appealing and also sign up button became visible, which couldn't be dine without moving the box up, ping me and say the changes in the original you'd like then.

Try to keep the same design aesthetics but change the positon to fit the signup button.

now check @yyppsk


Ml modeling

Here I integrated the sklearn custom pipeline for logging with MLFlow. I then trained a few tree based regression models and tracked them with mlflow.
There are also some bug fixes from github actions. DVC pull inside the CML test now works.

close #5


Document the no-shell popen behavior

As became evident through this video, not having the block's commands being run through a shell (and therefore, not supporting pipes etc) does go against the expectations of users and makes it seem like this is a bug. Better documentation should help here. In the future, considering a new command line switch to enable a vanilla popen() behavior (spawning a shell) would be an option, but I'd rather stick with the minimalist solution.

There is now an entire paragraph / section in the README dedicated to this. :)


feat: apply SuperchainWETH contracts to forked networks

#148  👈
main

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

Join @tremarkley and the rest of your teammates on  Graphite


chart doesn't show

macOS
brew install
Tested in 2 terminals warp and kitty

Edit: it randomly started working now.

I have the same issue.

Edit: it randomly started working now.

I don't think it's random. I had the same problem before, and after a fresh OS install, now. Do you remember changing anything? Maybe compositor config or font.

I don't think it's random. I had the same problem before, and after a fresh OS install, now. Do you remember changing anything? Maybe compositor config or font.

Nope, I didn't change anything. I think it simply wasn't loading for some connection issue but there's no tell in the UI besides the missing chart.