Ran the whole x/image test suite on ppc64le and s390x architectures
What did you expect to see?
I expected the whole x/image test suite to pass
What did you see instead?
the following test on golang.org/x/image/vector failed:
go test -compiler gc -ldflags '' golang.org/x/image/vector
--- FAIL: TestMakeFlInXxx (0.00s)
	acc_test.go:473: height 16: got:
		0, 0, -0.022306755, -0.3782405, -0.33334962, -0.1741521, -0.0607556, 0.11660573,
		0.14664596, 0.4146287, 0.2907673, 0.0001568835, 0, 0, -0.14239307, -0.7012868,
		-0.15632017, 0, 0, 0, 0, 0, 0, 0.32303032,
		0.6690931, 0.007876594, -0.05189419, -0.832786, -0.11531975, 0.026225802, 0.42518616, 0.3154636,
		0.06598757, -0.15304242, -0.47969276, -0.20012793, 0, 0.5327272, 0.46727282, -0.45950258,
		-0.5404974, 0, 0.63484025, 0.36515972, 0, 0, 0, -0.04351709,
		-0.82933456, -0.12714837, 0.11087036, 0.88912964, -0.35792422, -0.2053554, 0.0022512944, 0.53743976,
		0.023588562, 0, 0, 0, 0, -0.55346966, -0.44653034, 0.0002531938,
		0.9088273, 0.090919495, 0, 0, 0, 0, 0, 0,
		0, 0, -0.44745448, -0.5525455, 0, 0.80748945, 0.19251058, 0,
		0, -0.092476256, -0.2661464, -0.11322958, -0.11298219, -0.055094406, 0, -0.16045958,
		-0.1996116, 0, 0.80748653, 0.19251347, -0.09804727, -0.51129663, -0.3610403, -0.029615778,
		0, 0, 0, 0, 0, 0, 0, 0.80748653,
		0.14411622, -0.76251525, -0.1890875, 0.01527351, 0.27528667, 0.29730347, 0.101477206, 0.07259522,
		0.009900213, -0.34395567, -0.42788061, 0, 0.80748653, -0.3648737, -0.4426128, 0.015778137,
		0.6826565, 0.30156538, 0, 0, 0, 0, -0.44563293, -0.55436707,
		0, 0.80748653, -0.60703933, -0.20044717, 0.22371745, 0.77628255, 0, 0,
		0, 0, 0, -0.44563293, -0.55436707, 0, 0.80748653, -0.75503904,
		-0.05244744, 0.2797074, 0.7202926, 0, 0, 0, 0, 0,
		-0.57440215, -0.42559785, 0, 0.80748653, -0.59273535, -0.21475118, 0.04544862, 0.8114854,
		0.14306602, 0, 0, 0, -0.369642, -0.6184122, -0.011945802, 0,
		0.7791623, -0.20691396, -0.57224834, 0, 0.08218568, 0.42637306, 0.1586175, -0.089709565,
		-0.32935485, -0.24788953, -0.00022224105, 0, 0, 0.7085409, 0.2882107, -0.6476579,
		-0.34909374, 0, 0, 0, 0, 0, 0.16679136, 0.31914654,
		-0.48593786, 0, 0.537915, 0.462085, -0.00041967133, -0.3120329, -0.41914812, -0.15886839,
		-0.042683024, 0.19370952, 0.24624406, 0.45803425, -0.07049577, -0.6091341, 0, 0.22253075,
		want:
		0, 0, -0.022306755, -0.3782405, -0.33334962, -0.1741521, -0.0607556, 0.11660573,
		0.14664596, 0.41462868, 0.2907673, 0.0001568835, 0, 0, -0.14239307, -0.7012868,
		-0.15632017, 0, 0, 0, 0, 0, 0, 0.3230303,
		0.6690931, 0.007876594, -0.05189419, -0.832786, -0.11531975, 0.026225802, 0.42518616, 0.3154636,
		0.06598757, -0.15304244, -0.47969276, -0.20012794, 0, 0.5327272, 0.46727282, -0.45950258,
		-0.5404974, 0, 0.63484025, 0.36515975, 0, 0, 0, -0.04351709,
		-0.8293345, -0.12714837, 0.11087036, 0.88912964, -0.35792422, -0.2053554, 0.0022513224, 0.5374398,
		0.023588525, 0, 0, 0, 0, -0.55346966, -0.44653034, 0.0002531938,
		0.9088273, 0.090919495, 0, 0, 0, 0, 0, 0,
		0, 0, -0.44745448, -0.5525455, 0, 0.80748945, 0.19251058, 0,
		0, -0.092476256, -0.2661464, -0.11322958, -0.11298219, -0.055094406, 0, -0.16045958,
		-0.1996116, 0, 0.80748653, 0.19251347, -0.09804727, -0.51129663, -0.3610403, -0.029615778,
		0, 0, 0, 0, 0, 0, 0, 0.80748653,
		0.14411622, -0.76251525, -0.1890875, 0.01527351, 0.27528667, 0.29730347, 0.101477206, 0.07259522,
		0.009900213, -0.34395567, -0.42788061, 0, 0.80748653, -0.3648737, -0.44261283, 0.015778137,
		0.6826565, 0.30156538, 0, 0, 0, 0, -0.44563293, -0.55436707,
		0, 0.80748653, -0.60703933, -0.20044717, 0.22371745, 0.77628255, 0, 0,
		0, 0, 0, -0.44563293, -0.55436707, 0, 0.80748653, -0.7550391,
		-0.05244744, 0.2797074, 0.72029257, 0, 0, 0, 0, 0,
		-0.57440215, -0.42559785, 0, 0.80748653, -0.59273535, -0.21475118, 0.04544862, 0.81148535,
		0.14306602, 0, 0, 0, -0.369642, -0.61841226, -0.011945802, 0,
		0.7791623, -0.20691396, -0.57224834, 0, 0.08218567, 0.42637306, 0.1586175, -0.089709565,
		-0.32935485, -0.24788953, -0.00022224105, 0, 0, 0.7085409, 0.28821066, -0.64765793,
		-0.34909368, 0, 0, 0, 0, 0, 0.16679136, 0.31914657,
		-0.48593786, 0, 0.537915, 0.462085, -0.00041967133, -0.3120329, -0.41914812, -0.15886839,
		-0.042683028, 0.19370951, 0.24624406, 0.45803425, -0.07049577, -0.6091341, 0, 0.22253075,
FAIL
FAIL	golang.org/x/image/vector	0.015s

The following can be observed in some lines above:
got
-0.042683024, 0.19370952, 0.24624406, 0.45803425, -0.07049577, -0.6091341, 0, 0.22253075,

want
-0.042683028, 0.19370951, 0.24624406, 0.45803425, -0.07049577, -0.6091341, 0, 0.22253075,

Which seems to be a precision problem

Thanks for the report. This is almost certainly due to the new fused multiply add (FMA) support on these architectures. We could:

check the outputs are close rather than identical
insert explicit casts to block fused multiply add extraction as needed
add golden data specific to platforms that have FMA enabled

Any thoughts @nigeltao?

I started a golang-dev thread at https://groups.google.com/d/topic/golang-dev/Sti0bl2xUXQ/discussion

Based on that discussion, I think the right fix for now is to explicitly write "float32(xy)" instead of just "xy" all throughout the Rasterizer.floatingLineTo method in raster_floating.go.
I don't have access to s390x or ppc64le hardware, so somebody else will have to write (and verify) the patch.

Oh, and when somebody does write the patch, it'd also be nice to get some benchmark numbers to see how much an effect FMA has. If it really is a massive speed-up, it might be worth considering loosening the design so that the output is merely close, not always identical.

It looks like the floating point code is only really used for testing, is that correct?

Ah, yes, the comment on floatingPointMathThreshold in vector.go says:
// floatingPointMathThreshold is the width or height above which the rasterizer
// chooses to used floating point math instead of fixed point math.
//
// Both implementations of line segmentation rasterization (see raster_fixed.go
// and raster_floating.go) implement the same algorithm (in ideal, infinite
// precision math) but they perform differently in practice. The fixed point
// math version is roughtly 1.25x faster (on GOARCH=amd64) on the benchmarks,
// but at sufficiently large scales, the computations will overflow and hence
// show rendering artifacts. The floating point math version has more
// consistent quality over larger scales, but it is significantly slower.
//
// This constant determines when to use the faster implementation and when to
// use the better quality implementation.
//
// The rationale for this particular value is that TestRasterizePolygon in
// vector_test.go checks the rendering quality of polygon edges at various
// angles, inscribed in a circle of diameter 512. It may be that a higher value
// would still produce acceptable quality, but 512 seems to work.
const floatingPointMathThreshold = 512

So we didn't have a vector_test.go benchmark that tickles the floating point code path. We had acc_test.go benchmarks that do, but they're narrower in scope, rather than end-to-end.
I've just submitted https://go-review.googlesource.com/c/image/+/62130 to fix that.


feat: one time mint

Description
It is necessary to mint a large amount of coins.
For this, x/foundation provides a minting function(one time mint) through proposals.
However, this function is limited to only 1 time.

closes: #XXXX
Motivation and context

How has this been tested?

Screenshots (if appropriate):
Checklist:

[ ] I followed the contributing guidelines and code of conduct.
[x] I have added a relevant changelog to CHANGELOG.md
[x] I have added tests to cover my changes.
[ ] I have updated the documentation accordingly.
[x] I have updated API documentation client/docs/swagger-ui/swagger.yaml

Please update swagger and statik file.

Please update statik.go file also. And could you change the title more easier to understand about this changes?

My system's statik.go is a little difference with upstream. But the code is not difference, just comment and new line. So it is not problem. Sorry.


Have a controller env variable to display builds with build numbers instead of shas

I would be interested in users being able to see the output image with the build tag instead of the SHA. This could be a switch on the controller side that can default to a SHA but if set to true, shows the image status with the build tag instead of the SHA

Would this be in the build output?


Camera Control Tutorial Proposal

Description
This tutorial will cover the fundamentals of dynamic camera control using some camera functions in SplashKit, with applications primarily in game development. The intended audience is intermediate learners, and the tutorial will guide them through implementing camera movements and zoom effects. It will also explore how to create responsive camera controls that track objects in real-time, enhancing user interactivity. By the end, readers will gain a deeper understanding of using dynamic camera mechanics to improve the visual appeal and functionality of their projects.
How Has This Been Tested?
This is just a markdown file, tutorial to come
Testing Checklist

[x] Tested in latest Chrome
[x] Tested in latest Safari
[x] Tested in latest Firefox

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code in hard-to-understand areas
[x] My changes generate no new warnings

@sharvani28 In future PRs to this repo, make sure to run npm run format and npm run lint before committing your changes (I've done this on my side for this PR).


Possible code typos?

The new Xcode noticed two code errors in AppController.m:
if (GrowlSpam_ConnectingToProxy == 0) {
	[growl message:connectingConnectionStatusText];
	GrowlSpam_ConnectingToProxy == 1; // Want single "="?
}

And:
// Reset GrowlSpam variable to allow notifications now that spam should have ended
GrowlSpam_ConnectingToProxy == 0; // Here as well?

Fixed. Will release with the next version.


Add template to mktemp command

Older versions of MacOS seem to require a template in calls to mktemp.
Ref: https://github.com/yarnpkg/yarn/issues/1984

Sorry I realised this is a mirror, will redo the PR on gitlab.

Moved to gitlab https://gitlab.haskell.org/haskell/ghcup/merge_requests/124


Create ReadMe_CN中文.md

js-tableland CHN translation....

@hehanbo1990 Thanks for this. I think we can merge, but @carsonfarmer and I were discussing making some changes to the EN readme today. Having something in CHN is better than nothing, but would you be willing to revisit after those changes? Thanks again, this is much appreciated!

surely!my pleasure!


localhost:8100 not available

Hey I tried your container and for me it didnt work out of the box. I have an ionic project which works with ionic and everything installed on my machine, but it does not, when i try to start the same project with your container.
I started
docker run -ti \
-v /path/to/your/ionic-project/:/myApp:rw \
-p 8100:8100 -p 35729:35729 \
mkaag/ionic

, but localhost:8100 was not available. I use a Mac. Could that be the problem? Do you have an idea what could be the problem? I'm not too experienced with docker, but i thought using others containers could work.
Thank you very much

Hi Julian,
can you let me know how do you run docker on OSX?
I do use dinghy on my OSX and explicitly open TCP 8100 on the installed VirtualBox. Then while running ionic serve I select the interface mapped to eth0. You can from there enable consolelogs and serverlogs and see if you can reach http://localhost:8100 from OSX.
Have a try and let me know.
Cheers!


Q14siX.de.Mathematikum version <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Installation failed with exit code -1978334957 2023-05-25 10:07:02.130 [CLI ] ShellExecute installer failed: 1633
MSI (s) (4C:BC) [10:07:01:972]: Windows Installer installed the product. Product Name: Mathematikum. Product Version: <IP_ADDRESS>. Product Language: 1031. Manufacturer: Q14siX.de. Installation success or error status: 1633.

Manual Validation failed with:

Faulting application name: Mathematikum.exe, version: <IP_ADDRESS>, time stamp: 0xe815d0ab
Faulting module name: KERNELBASE.dll, version: 10.0.22621.1778, time stamp: 0x11df5af5 Exception code: 0xe0434352 Fault offset: 0x00148462
Faulting process id: 0x0x1F48
Faulting application start time: 0x0x1D98F70F6653558
Faulting application path: C:\Program Files\Q14siX.de\Mathematikum\Mathematikum.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: d37e8174-ca36-411e-929b-4ccbe6140865
Faulting package full name:
Faulting package-relative application ID:

The package installed normally, but gave the above error when launched.

Close with reason: Stale pull request;


stm32 sha1 acceleration does not work since 2.16.8 release

I'm using mbedtls on stm32f7 board. Until 2.16.7 it worked fine with alternative functions providing hw acceleration (same as ones in mbedos (https://github.com/ARMmbed/mbed-os/blob/master/connectivity/drivers/mbedtls/TARGET_STM/sha1_alt.cpp)). I have recently tried to update to actual 2.16 tip but here I noticed that my webserver does not work and reports SSL - Verification of the message MAC failed when MBEDTLS_SHA1_ALT is defined. With internal SHA1 everything works fine.
With bisecting I have found that it started with this commit de02b580c8bd2d122746616205344dae4a2e9243. I do not see on the first sight what could be the issue here, hopefuly someone with more knowledge can help...

Any progress here, please?

Hi, and sorry for the long response time.
Thanks for bisecting the issue. The commit is somewhat consistent with the error you're getting, in the this commit changes how the MAC is verified, which is what the error is about. OTOH, I don't really see what in this commit could trigger issues in the SHA1 alt implementation. First I was going to say that perhaps it might have to do with the fact that after this commit, the computation relies on mbedtls_md_clone() which wasn't used here before this commit. But on the other hand, clone() is also used in computing the TLS handshake hash and always has been, so if the alt implementation got it wrong, we should be already have been observing failures in all handshakes that use SHA-1 long before this commit.
This would be easily verified by running the test suites on your device, but I'm afraid we don't have good facilities for running our test suites on embedded devices yet... Could you try running the following test on your device (possibly adapting the calls to printf) with check if the two printed hash values are identical?
#include "mbedtls/md.h"
#include "stdio.h"

int main( void ) {
    int ret;
    mbedtls_md_context_t ctx, clo;
    const mbedtls_md_info_t *sha1 = mbedtls_md_info_from_type( MBEDTLS_MD_SHA1 );
    unsigned char buf[250];
    const size_t split = 123;
    unsigned char out[20];

    mbedtls_md_init( &ctx );
    mbedtls_md_init( &clo );

    for( size_t i = 0; i < sizeof( buf ); i++ )
        buf[i] = i;

    /* start computation with one context */
    ret = mbedtls_md_setup( &ctx, sha1, 0 );
    if( ret != 0 )
        goto exit;

    ret = mbedtls_md_starts( &ctx );
    if( ret != 0 )
        goto exit;

    ret = mbedtls_md_update( &ctx, buf, split );
    if( ret != 0 )
        goto exit;

    /* clone in the middle */
    ret = mbedtls_md_setup( &clo, sha1, 0 );
    if( ret != 0 )
        goto exit;

    ret = mbedtls_md_clone( &clo, &ctx );
    if( ret != 0 )
        goto exit;

    /* finish computation with original */
    ret = mbedtls_md_update( &ctx, buf + split, sizeof( buf ) - split );
    if( ret != 0 )
        goto exit;

    ret = mbedtls_md_finish( &ctx, out );
    if( ret != 0 )
        goto exit;

    printf( "Origin:" );
    for( size_t i = 0; i < sizeof( out ); i++ )
        printf( " %02x", out[i] );
    printf( "\n" );

    /* finish computation with clone */
    ret = mbedtls_md_update( &clo, buf + split, sizeof( buf ) - split );
    if( ret != 0 )
        goto exit;

    ret = mbedtls_md_finish( &clo, out );
    if( ret != 0 )
        goto exit;

    printf( "Cloned:" );
    for( size_t i = 0; i < sizeof( out ); i++ )
        printf( " %02x", out[i] );
    printf( "\n" );

exit:
    mbedtls_md_free( &ctx );
    mbedtls_md_free( &clo );

    return( ret );
}

(If the results are identical, can you try varying the value of split, trying for example 63, 64, 65, 127, 128, 129?)

Ok, thanks for running the test!
The debug output you posted confirms that the problem is with the computation of the expected MAC, which was modified in the commit identified by git bisect, so that part really checks out.
So, I went again line by line over this commit looking for things that would trip up a alt implementation, and now I think I've found my mistake. Could you try applying the following patch on top of the current mbedtls-2.16 and see if it fixes the problem?
diff --git a/library/ssl_tls.c b/library/ssl_tls.c
index c749a8611c43..a6c629748163 100644
--- a/library/ssl_tls.c
+++ b/library/ssl_tls.c
@@ -1895,6 +1895,9 @@ int mbedtls_ssl_cf_hmac(
             MD_CHK( mbedtls_md_update( ctx, data + offset, 1 ) );
     }

+    /* The context needs to finish() before it starts() again */
+    MD_CHK( mbedtls_md_finish( ctx, aux_out ) );
+
     /* Now compute HASH(okey + inner_hash) */
     MD_CHK( mbedtls_md_starts( ctx ) );
     MD_CHK( mbedtls_md_update( ctx, okey, block_size ) );

Bingo!
This really solves the described issue. Thank you for your support.

Good news! Thanks for testing the patch! I'll create a PR so that the fix lands in the next release of 2.16.


chore(master): release 1.2.8

:robot: I have created a release beep boop
1.2.8 (2024-02-13)
Bug Fixes

deps: update dependency cycle/orm to v2.7.1 (dd9893f)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wayofdev/laravel-webhook-client/releases/tag/v1.2.8 :sunflower:


Kafka Source Dispatcher crashing

Describe the bug
Kafka Source Dispatcher goes in to status CrashLoopBackOff.
Expected behavior
When I install Kafka source I expect it to not crash, but have status Running.
To Reproduce
Use kn quickstart kind or kn quickstart minikube
Install Kafka controller and Kafka source v.1.2.3 (Also occurs with v1.2.0)
kubectl apply --filename https://github.com/knative-sandbox/eventing-kafka-broker/releases/download/knative-v1.2.3/eventing-kafka-controller.yaml
kubectl apply --filename https://github.com/knative-sandbox/eventing-kafka-broker/releases/download/knative-v1.2.3/eventing-kafka-source.yaml
Knative release version
v1.2.0
Additional context
Log output from the pod:
{"@timestamp":"2022-02-26T13:31:38.116Z","@version":"1","message":"Failed to startup the dispatcher","logger_name":"dev.knative.eventing.kafka.broker.dispatcher.main.Main","thread_name":"main","level":"ERROR","level_value":40000,"stack_trace":"java.io.IOException: Function not implemented\n\tat java.base/sun.nio.fs.LinuxWatchService.<init>(Unknown Source)\n\tat java.base/sun.nio.fs.LinuxFileSystem.newWatchService(Unknown Source)\n\tat dev.knative.eventing.kafka.broker.core.file.FileWatcher.start(FileWatcher.java:88)\n\tat dev.knative.eventing.kafka.broker.dispatcher.main.Main.main(Main.java:122)\n"}

I'm using MacBook with M1 processor. I think that could be the reason.

Hi @niels-busch-maersk, thanks for reporting!
Yes, unfortunately, images aren't multi-arch as reported in https://github.com/knative-sandbox/eventing-kafka-broker/issues/1908.


Reading view

Trying out your new plugin.
Works great in source mode and live preview mode.
However, it does not appear to work in the reading view.
Is the plugin intended to work in reading view?

I'm not going to implement it in reading view.
This plugin mainly aims to solve the problem of: when writing in fragmented time, I often forget which heading level I am currently at, or which level I should use for the next heading.
The obsidian's core plugin Outline is good enough when reading.

Its now on Obsidian's community plugins, you can search and install.

We need this to be available in live preview mode too!
This plugin is super helpful, given the existence of core plugin!


map the nodes to embeddings

I converted a graph represented with its weighted edge list to the bcsr format using your convert code and got the embeddings back. How can I know which node is associated with which embedding? is the ordering the same as the order in the edge list? meaning that if the first line of the edge list shows nodes 10 is connected to node 2 with the weight 0.5 (10,2,0.5), then the first embedding is associated with node 10 and the second is for node 2?

convert script generates a node2id map to convert IDs to sequential integers which is used in BCSR. You can change the converter script to save this mapping somewhere.
https://github.com/xgfs/verse/blob/51fcfe9ac1b4c5a029091d2d41e77efe82bac8ab/python/convert.py#L67
Note that because this mapping is generated based on a set of nodes, there is no guaranty on ordering of nodes, so the generated mapping may be vary each time you run the convert script.

Note that I still sort the nodes, so the order should be deterministic.

Note that I still sort the nodes, so the order should be deterministic.

Oh yes. I missed the sort part. 🤦🏻♂

Hi Author,
I also want to know how to map the node to its embedding, and I am confused about using the same train data but getting different results each time?

What do you mean by results? By default, the embeddings are initalized randomly each time, so it's normal that you get different embedding each time you run the model.

oh yes, I mean got different embeddings. Could I ask how to get the embedding of each node? Are these embedding results sorted in ascending order by node number?

If you converted the graphs with the supplied converter, then the node IDs are sorted in the ascending order.

I got it, thanks for your reply!


aio rt:activation:list does NOT work in Windows 10

After deploying app into IO, I ran "aio app run" in command prompt and then using the url under web-src/src/config.json, I invoked my app. Then I entered "aio rt:activation:list" in Terminal tab of VS code and I got the below error. I got the same error when I repeated these same steps with "aio app run --local". However, "wsk activation list" gave me the list of activation ids.
"aio rt:activation:list
aio : File C:\Users\mallicha\AppData\Roaming\npm\aio.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1

aio rt:activation:list

CategoryInfo          : SecurityError: (:) [], PSSecurityException
FullyQualifiedErrorId : UnauthorizedAccess"

OS: Windows 10 Enterprise
Browse: Google Chrome - Version 79.0.3945.130 (Official Build) (64-bit)
aio --version --> @adobe/aio-cli/3.0.0 win32-x64 node-v12.13.1

Hey @visaq,
Unfortunately this is a recent behavior change in npm which will cause this problem for any globally installed packages:
https://github.com/npm/cli/issues/470
Some work-arounds are offered in that thread

Closing the issue as this related to npm/cli#470


Using negative number as a array index before checking

Currently using negative number as a array index before checking:
    if (args[idx].v_type != VAR_STRING)
    {
	if (idx >= 0)

I checked where functions in typval.c are used, Nowhere is using negative number as a array index for functions in typval.c.
This PR will be an internal error is occurred if using negative number as a array index for functions in typval.c.

Thanks for checking.  I can also see in codecov that the "else" in none of these functions is reached.
I don't think we need an internal error, we can just remove the check for a negative index.
In case a negative index is used, it's very likely there is a crash or at least an ASAN error.


Update OpenSSL

MNT: Re-rendered with conda-build 3.17.8, conda-smithy 3.3.3, and con…da-forge-pinning 2019.04.18

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


Ignore invalid post_logout_redirect_uri

After validating id_token_hint we previously treated the incorrect post_logout_redirect_uri for that client as an error. Change the behavior to ignore it (and the state param), as opposed to treating as an error. This way the user is not prompted for signout, but they won't get their link back to the client.

done


installation problem

Hi,
My name is Kochler and i have some problems with pagecache installation.
I try to install your extension Free Page Cache for OC 2.X on my opencart site : www.eatermagazine.ro/Shop and I have this error "Cannot find bottom marker in index.php".
I try to install it manually by your advices but still won't work.
Can you help me?
Thank you
Kochler

There's a separate github repo for the 2.x version, here: https://github.com/budgetneon/v2pagecache
Two things
a) I haven't looked at whether it works on OpenCart 2.3.x yet, it may well not work there.
b) I just uploaded a new version that should fix some issues on OpenCart 2.2.x.

Closing because it's opened in the wrong repo.   Re-open in https://github.com/budgetneon/v2pagecache if you like.


Not working

I run the "PySilon.bat" and fill out the config, once I finish filling it out I click Generate source and then Compile. After that, nothing happens.

do you do the reqs?

Yes

It's creating a dist folder but the exe or whatever the malware file is it's not going in that folder.

So it compiled successfully? If so, can you check if your AV removed it? If not then I need the error that you got while compiling

I somehow also get the same thing (nothing in the dist) but I though it was because of wine. The error I get says Permission Denied, but wine is already running as admin by default.

wine actually worked fine for me ( wine is for linux so nothing to worry about for windows users ) and it was good, you can send me the error in dms on discord if you want. Also @Lancmo if you compile the malware and it's not in the dist folder, then you didn't compile it correctly or it got removed by your anti virus, please check both and if you have errors while compiling send them here :)

I somehow also get the same thing (nothing in the dist) but I though it was because of wine. The error I get says Permission Denied, but wine is already running as admin by default.

is this still happening? Also send me the error that you mean :>

i cant find the generate button lol

Make your own issue for that or join our discord server


matio: 1.5.19 -> 1.5.20

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/matio/versions.
meta.description for matio is: "A C library for reading and writing Matlab MAT files"
meta.homepage for matio is: "http://matio.sourceforge.net/"
meta.changelog for matio is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/xfcy64rk3ywi48c8vb2lr1mbsjp17wyk-matio-1.5.20/bin/matdump passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 1.5.20 with grep in /nix/store/xfcy64rk3ywi48c8vb2lr1mbsjp17wyk-matio-1.5.20

found 1.5.20 in filename of file in /nix/store/xfcy64rk3ywi48c8vb2lr1mbsjp17wyk-matio-1.5.20

directory tree listing: https://gist.github.com/7eafc8129176ac5d924cf5dfd9c81bd9

du listing: https://gist.github.com/2643923d0fb79b0a50ff3c9397c8547b

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gnss-sdr
matio

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xfcy64rk3ywi48c8vb2lr1mbsjp17wyk-matio-1.5.20 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A matio https://github.com/r-ryantm/nixpkgs/archive/019ec087a08bd07d733fd18e12b9e9e8761ef237.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xfcy64rk3ywi48c8vb2lr1mbsjp17wyk-matio-1.5.20
ls -la /nix/store/xfcy64rk3ywi48c8vb2lr1mbsjp17wyk-matio-1.5.20/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @vbgl for testing.

Result of nixpkgs-review pr 117610 at 019ec087 run on x86_64-linux 1

1 package skipped due to time constraints:

gnss-sdr

1 package built successfully:

matio

Result of nixpkgs-review pr 117610 run on x86_64-linux 1

2 packages built:

gnss-sdr
matio

tested matio with a sample dataset


EVALSYS-1100 Improvements in weighted means and pdf reports

The PDF export support for individuals is just a copy of the normal export with a could of extra lines, this really should be refactored as it's means you have to make the changes in 2 files.

Commits here look good to me.  Ready to merge?

@buckett is this ready to merge?

Yep, thanks for the prod.


The way to overwrite or prepend PATH variable in integrated terminal.

It seems that existing API that can be used to change environment variables in VS Code (EnvironmentVariableCollection) doesn't allow to fully control PATH variable. After altering PATH with .prepend() or .replace() methods there is still some "default" paths prepended in PATH variable (in case of macos it is /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin).
In my case it leads to various issues with nix command which relies on correct PATH variable.
Is it possible to fully control PATH variable in integrated console?

when VS Code launches, we source a "dev environment" by running your default shell, so that PATH is used. We don't have control of the PATH in other words


Please Help me , You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders

You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders

Since you placed this issue at the Laravel adapter, I assume you're using Laravel mix v6. A quick search with the error + laravel mix led me to this issue/solution https://github.com/JeffreyWay/laravel-mix/issues/2625#issuecomment-733842722
So all you need to do is replace .js() with .vue() / .vue({ version: 2 }) in your webpack.mix.js file.

Since you placed this issue at the Laravel adapter, I assume you're using Laravel mix v6. A quick search with the error + laravel mix led me to this issue/solution https://github.com/JeffreyWay/laravel-mix/issues/2625#issuecomment-733842722
So all you need to do is replace .js() with .vue() / .vue({ version: 2 }) in your webpack.mix.js file.

Thanks for your help here @RobertBoes. That looks correct.

Thanks for your help here @RobertBoes. That looks correct.

This didn't solve the issue for me, but this did:
app.js
`require('./bootstrap');
import App from './vue/App.vue';
import { createApp } from 'vue'
const app = createApp(App).mount('#app');
`

[Solved] You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file in vueJs


docs(guides): clarify some caveats about dynamic import manual preloa…

…d via script tag webpack/webpack/issues/14874
Add an explanation about an unexpected behavior of dynamic scripts from https://github.com/webpack/webpack/issues/14874

@evenstensberg what does EasyCLA mean?

@webpack/documentation-team Somebody can review?

Thx @alexander-akait


Support MCPileUp in MonteCarlo and MonteCarloFromGEN request types

for fastsim workflows, one needs to use either type and should be able to provide MCPileup parameter and it should be treated properly. This would facilitate greatly central production.
This ticket should have been opened a few months ago already @srimanob

Any reason not to use TaskChain request type for such cases?

that is the trick that is being used. what you suggest could be achieved but for the sake of consistency in this case it would probably mean that all workflows would then come in as taskchain regardless their types (which is known to work just fine) and we could drop all types but TaskChain.
Doing what you suggest demands quite a large amount of work on the injection side, if the amount of work to enable MCPileup as specified in this ticket is not too large I would suggest doing so, that would simplify things and let MonteCarlo and MonteCarloFromGEN fulfilling their purpose.

Ok. Then I believe the work on ppd/mcm side would be much bigger than what it should take in WMCore. However, I don't think we can make it before November, at best. Is that ok?

Fine by me. @srimanob

Thanks @vlimant @amaltaro
I think it's fine for November, we are just starting the FastSim campaigns.

So we talked about this in the WMAgent meeting on Thursday and I too think WMAgent should be able to do this. We don't want to artificially push things into TaskChain or even into multiple steps on the same worker node that we don't have to.
The only reason I see for TaskChain is if things need to run different releases or with different #'s of cores or need to run on different sets of resources.

@vlimant @ericvaandering do you see the need for deterministic pileup as well (premixing)?

It is actually primarily for premixing these days ; not sure it is actually used (switch on in the workload by requester) though

Thanks https://github.com/cms-PdmV/wmcontrol/issues/21 and https://github.com/cms-PdmV/cmsPdmV/issues/790 needs working on the requester's end

@vlimant @srimanob this is in testbed now and the WMCore functionality seems to be Ok. However I do not have a working workflow/configuration to test the whole chain, if you do and want to test a real thing, please inject it in testbed (or share the config with me) and we can test it before next Tuesday.

pdmvserv_HIG-RunIISpring15FSPremix-00002_00008_v1__151116_133903_473


Why use process.nextTick ?

https://github.com/AzureADQuickStarts/AppModelv2-WebApp-OpenIDConnect-nodejs/blob/f037b4651b4b93b80f405b703f6d2df2deb7e32a/app.js#L128
Can you please elaborate this?
I understand what nextTick does (https://nodejs.dev/learn/understanding-process-nexttick), but why use it here?

Apologies as this went unattended for so long. process.nextTick here is used to simulate an async operation.
Closing this as we are archiving the sample. Please refer to the new sample using MSAL Node: https://github.com/Azure-Samples/ms-identity-node


Optional installation of CRDs

Feature Description
Some users prefer to install and manage CRDs outside of charts. This can help ensure CRDs (and CRs) remain installed even when the chart is uninstalled.
When CRDs are installed as part of the chart templates, it's common to wrap them around a toggle. See for example cert-manager and external-secrets.
Suggested Solution (optional)
Add an installCRDs boolean helm value.

Hi @illrill,

This can help ensure CRDs (and CRs) remain installed even when the chart is uninstalled.

Thanks for pointing this use case out! I vaguely remember wondering if we'll need such a field in k6-operator Helm but had doubts about its usefullness :smile:

For completeness sake; and in case it'll be needed to locate the problem.
With this change, it's now possible to run k6-operator without CRDs installed very easily (arguably, easier than before) and doing that will result in errors like this:
2023-11-23T15:05:06Z	ERROR	controller-runtime.source.EventHandler	failed to get informer from cache	{"error": "failed to get API group resources: unable to retrieve the complete list of server APIs: k6.io/v1alpha1: the server could not find the requested resource"}

It is an expected error in this case. Solution: make a full installation with CRDs included.

@yorugac thanks, that's valuable information (I was initially considering just installing TestRun) 👍
If anyone is interested, this is how I handled CRD installation using kubectl, separately from the Helm release lifecycle.
helm template k6-operator grafana/k6-operator \
  --set k6-operator.installCRDs=true \
  | yq 'select(.kind == "CustomResourceDefinition")' \
  | kubectl apply --server-side --force-conflicts -f -

helm install k6-operator grafana/k6-operator \
  --set k6-operator.installCRDs=false


Cannot remote debug from VsCode. From terminal its working

OS: <Ubuntu : 22.04>
VSCode version:  <1.72.2>
CodeLLDB version: <1.8.1.>
Compiler:
Debuggee: <remote lldb armv7 raspian 32bit bullseye>
Hello
I have problem with remote debugging on raspberry pi 4. If i wanna start remote debugging from VScode i got error : failed to launch or debug process.
if i run from my linux terminal its working fine :
lldb version 14.0.0
lldb adopsio
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'
(lldb) target create "adopsio"
Current executable set to '/home/hofman/ProjektyIMA/adopsio/target/armv7-unknown-linux-gnueabihf/debug/adopsio' (arm).
(lldb) platform connect connect://<IP_ADDRESS>:1234
Platform: remote-linux
OS Version: 5.15.61 (5.15.61-v7l+)
Hostname: raspberrypi
Connected: yes
WorkingDir: /home/pi/adopsio
Kernel: #1579 SMP Fri Aug 26 11:13:03 BST 2022
(lldb) process launch
Process 5080 launched: '/home/hofman/ProjektyIMA/adopsio/target/armv7-unknown-linux-gnueabihf/debug/adopsio' (arm)
2022-10-27 10:29:30 [INFO] - Version : 0.0.1
Process 5080 stopped and restarted: thread 2 received signal: SIGCONT
Process 5080 stopped and restarted: thread 3 received signal: SIGCONT
Process 5080 stopped and restarted: thread 4 received signal: SIGCONT
Process 5080 stopped and restarted: thread 5 received signal: SIGCONT
Process 5080 stopped and restarted: thread 6 received signal: SIGCONT
Process 5080 stopped and restarted, reasons:
thread 7 received signal: SIGCONT
thread 8 received signal: SIGCONT
Process 5080 stopped and restarted: thread 9 received signal: SIGCONT
Process 5080 stopped and restarted: thread 10 received signal: SIGCONT
Process 5080 stopped and restarted: thread 11 received signal: SIGCONT
Process 5080 stopped and restarted: thread 12 received signal: SIGCONT
2022-10-27 10:29:30 [DEBUG] - starting new connection: http://peckahp.ima.cz:2760/
Process 5080 stopped and restarted: thread 13 received signal: SIGCONT
2022-10-27 10:29:30 [INFO] - Available serial port /dev/ttyUSB0
2022-10-27 10:29:30 [INFO] - Available serial port /dev/ttyAMA0
114:18
Initial debug configuration: {
name: 'Remote launch',
sourceLanguages: [ 'rust' ],
type: 'lldb',
request: 'launch',
program: '${workspaceFolder}/target/armv7-unknown-linux-gnueabihf/debug/adopsio',
initCommands: [
'platform select remote-linux',
'platform connect connect://<IP_ADDRESS>:1234',
'settings set target.inherit-env false'
],
__configurationTarget: 6
}
Resolved debug configuration: {
name: 'Remote launch',
sourceLanguages: [ 'rust' ],
type: 'lldb',
request: 'launch',
program: '${workspaceFolder}/target/armv7-unknown-linux-gnueabihf/debug/adopsio',
initCommands: [
'platform select remote-linux',
'platform connect connect://<IP_ADDRESS>:1234',
'settings set target.inherit-env false'
],
__configurationTarget: 6,
relativePathBase: '/home/hofman/ProjektyIMA/adopsio',
_adapterSettings: {
displayFormat: 'auto',
showDisassembly: 'auto',
dereferencePointers: true,
suppressMissingSourceFiles: true,
evaluationTimeout: 5,
consoleMode: 'commands',
sourceLanguages: null,
terminalPromptClear: null,
evaluateForHovers: true,
commandCompletions: true,
reproducer: false
}
}
liblldb: /home/hofman/.vscode/extensions/vadimcn.vscode-lldb-1.8.1/lldb/lib/liblldb.so
environment: {}
params: {
evaluateForHovers: true,
commandCompletions: true,
sourceLanguages: [ 'rust' ]
}
[2022-10-27T08:22:29.345Z DEBUG codelldb] New debug session
[2022-10-27T08:22:29.529Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true,"supportsMemoryReferences":true,"supportsArgsCanBeInterpretedByShell":true},"type":"request","seq":1}
[2022-10-27T08:22:29.529Z DEBUG codelldb::dap_codec] <-- {"seq":1,"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"rust_panic","label":"Rust: on panic"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true,"supportsWriteMemoryRequest":true}}
[2022-10-27T08:22:29.533Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"name":"Remote launch","sourceLanguages":["rust"],"type":"lldb","request":"launch","program":"/home/hofman/ProjektyIMA/adopsio/target/armv7-unknown-linux-gnueabihf/debug/adopsio","initCommands":["platform select remote-linux","platform connect connect://<IP_ADDRESS>:1234","settings set target.inherit-env false"],"__configurationTarget":6,"relativePathBase":"/home/hofman/ProjektyIMA/adopsio","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null,"evaluateForHovers":true,"commandCompletions":true,"reproducer":false},"__sessionId":"b805b177-5a60-4711-b673-f9451de06cb8"},"type":"request","seq":2}
[2022-10-27T08:22:29.535Z DEBUG codelldb::dap_codec] <-- {"seq":2,"type":"event","event":"output","body":{"output":"Console is in 'commands' mode, prefix expressions with '?'.\n"}}
[2022-10-27T08:22:29.535Z DEBUG codelldb::dap_codec] <-- {"seq":3,"type":"event","event":"output","body":{"output":"Executing script: initCommands\n"}}
[2022-10-27T08:22:29.535Z DEBUG codelldb::debug_session] platform select remote-linux -> SuccessFinishResult, Error:  Success
Output Message:
Platform: remote-linux
Connected: no
[2022-10-27T08:22:29.535Z DEBUG codelldb::dap_codec] <-- {"seq":4,"type":"event","event":"output","body":{"output":"  Platform: remote-linux\n Connected: no\n\n"}}
[2022-10-27T08:22:29.546Z DEBUG codelldb::debug_session] platform connect connect://<IP_ADDRESS>:1234 -> SuccessFinishResult, Error:  Success
Output Message:
Platform: remote-linux
OS Version: 5.15.61 (5.15.61-v7l+)
Hostname: raspberrypi
Connected: yes
WorkingDir: /home/pi/adopsio
Kernel: #1579 SMP Fri Aug 26 11:13:03 BST 2022
[2022-10-27T08:22:29.547Z DEBUG codelldb::dap_codec] <-- {"seq":5,"type":"event","event":"output","body":{"output":"  Platform: remote-linux\nOS Version: 5.15.61 (5.15.61-v7l+)\n  Hostname: raspberrypi\n Connected: yes\nWorkingDir: /home/pi/adopsio\n    Kernel: #1579 SMP Fri Aug 26 11:13:03 BST 2022\n\n"}}
[2022-10-27T08:22:29.547Z DEBUG codelldb::debug_session] settings set target.inherit-env false -> SuccessFinishResult, Error:  Success
INFO(Python) 10:22:29 formatters: Initializing
INFO(Python) 10:22:29 formatters.rust: Initializing
[2022-10-27T08:22:30.185Z DEBUG codelldb::dap_codec] <-- {"seq":6,"type":"event","event":"initialized"}
[2022-10-27T08:22:30.185Z DEBUG codelldb::debug_session] Debug event: 0x5601cbad5090 Event: broadcaster = 0x5601cbac0400 (lldb.target), type = 0x00000002 (modules-loaded), data = {adopsio}
[2022-10-27T08:22:30.186Z DEBUG codelldb::dap_codec] <-- {"seq":7,"type":"event","event":"module","body":{"module":{"addressRange":"FFFFFFFFFFFFFFFF","id":"FFFFFFFFFFFFFFFF","name":"adopsio","path":"/home/hofman/ProjektyIMA/adopsio/target/armv7-unknown-linux-gnueabihf/debug/adopsio","symbolFilePath":"/home/hofman/ProjektyIMA/adopsio/target/armv7-unknown-linux-gnueabihf/debug/adopsio","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-10-27T08:22:30.190Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/home/hofman/ProjektyIMA/adopsio/src/main.rs"},"lines":[50],"breakpoints":[{"line":50}],"sourceModified":false},"type":"request","seq":3}
[2022-10-27T08:22:30.291Z DEBUG codelldb::debug_session] Debug event: 0x5601cc02bd40 Event: broadcaster = 0x5601cbac0400 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {bkpt: 1 type: breakpoint added}
[2022-10-27T08:22:30.291Z DEBUG codelldb::dap_codec] <-- {"seq":8,"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":50,"message":"Resolved locations: 0","verified":true}]}}
[2022-10-27T08:22:30.295Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2022-10-27T08:22:30.295Z DEBUG codelldb::dap_codec] <-- {"seq":9,"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2022-10-27T08:22:30.298Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2022-10-27T08:22:30.298Z DEBUG codelldb::dap_codec] <-- {"seq":10,"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2022-10-27T08:22:30.303Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["rust_panic"]},"type":"request","seq":6}
[2022-10-27T08:22:30.308Z DEBUG codelldb::debug_session] Debug event: 0x5601cdf2f0b0 Event: broadcaster = 0x5601cbac0400 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {bkpt: 2 type: breakpoint added}
[2022-10-27T08:22:30.308Z DEBUG codelldb::dap_codec] <-- {"seq":11,"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2022-10-27T08:22:30.312Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2022-10-27T08:22:30.312Z DEBUG codelldb::dap_codec] <-- {"seq":12,"type":"event","event":"output","body":{"output":"Launching: /home/hofman/ProjektyIMA/adopsio/target/armv7-unknown-linux-gnueabihf/debug/adopsio\n"}}
[2022-10-27T08:22:30.312Z ERROR codelldb::debug_session] failed to launch or debug process
[2022-10-27T08:22:30.312Z DEBUG codelldb::dap_codec] <-- {"seq":13,"type":"response","request_seq":2,"success":false,"command":"","message":"failed to launch or debug process","show_user":true}
[2022-10-27T08:22:30.312Z DEBUG codelldb::dap_codec] <-- {"seq":14,"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2022-10-27T08:22:30.317Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":8}
[2022-10-27T08:22:30.317Z DEBUG codelldb::dap_codec] <-- {"seq":15,"type":"response","request_seq":8,"success":true,"command":"disconnect"}
[2022-10-27T08:22:30.817Z DEBUG codelldb::dap_session] Client has disconnected
[2022-10-27T08:22:30.817Z DEBUG codelldb::debug_session] End of the requests stream
[2022-10-27T08:22:30.817Z DEBUG codelldb::debug_session] DebugSession::drop()
[2022-10-27T08:22:30.818Z DEBUG codelldb] End of the debug session
[2022-10-27T08:22:30.828Z DEBUG codelldb] Exiting
Debug adapter exit code=0 (0x0), signal=null.

#798 Similar issue

I updated lldb on raspberry to version 13  and everything is working now.


number of Storage account management operations requests

Is it possible to get number of Storage account management operations requests? and how if it's possible?

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

ID: b0e0e84a-7aa0-e751-f7b0-f60505df154a
Version Independent ID: 93bfc173-6c71-5601-dbf1-8cf551a42495
Content: Request limits and throttling - Azure Resource Manager
Content Source: articles/azure-resource-manager/resource-manager-request-limits.md
Service: azure-resource-manager
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

@kazshi Thanks for the feedback! We are currently investigating and will update you shortly.

@kazshi Are you looking for Operations - List Lists all of the available Storage Rest API operations.

@tamram - do you know if Storage returns response header values that indicate how many operations are available before throttling is applied? I am referring to the Storage resource provider scale limits. I ran a test operation and did not see any value that was specific to Storage.

@tfitzmac - I don't believe that we do, but adding @cbrooksmsft to confirm.

@kazshi - the number of remaining requests for Storage management operations are not returned as header values. You would want to handle any requests that return the 429 error code and retry as appropriate. Here's some related info:
Azure Storage scalability and performance targets for storage accounts

#please-close

@tfitzmac Thanks for your comment.


Preroll and Postroll plugins don't play together nicely in native html5 mode

When you have the postroll and preroll plugins enabled, the postroll content loads after the preroll ad finishes playing, while the normal video continues to play underneath the postroll content. This appears to only happen when using native HTML5 playback.
Here's a test case: http://bill-williams.org/test/mediaelement.html

@malevolence Closing old issues. If you'd like to reopen this, let us know. Thanks!


Integration into nixpkgs

Are there any plans or reasons not to include this in nixpkgs?
I think we lack something like this as go-to solution that just comes with nixpkgs.

There are two issues with bringing Nixt to nixpkgs:

I don't know anything about that process and would require some charity there
The number of people who have used Nixt is so low that I have no idea if it is actually useful

There's a simpler test runner in lib.debug.runTests, and another project (yet) outside nixpkgs at https://github.com/adisbladis/nix-unit. nix-unit is backwards-compatible with tests written for runTests and includes a comparision table to nixt and others at the end of its README.
From a quick glance at your docs, it seems like it would be possible for nixt to also support runTests-style tests like e.g.
´´´
runTests {
testIsEven_1 = {
expr = math.isEven 2;
expected = true;
};
};

Not directly related to an integration into nixpkgs, but might make it easier to converge towards a community consensus around unit testing.


Add a direct URL to the action in "more info"

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

This change appends the action's name to the more information URL, routing it directly to the documentation of said action, instead of pointing to the general action list.

This fixes #10854

This change can be tested by running bundle exec fastlane action [action] and verifying that the more information URL now points to https://docs.fastlane.tools/actions/[action] instead of https://docs.fastlane.tools/actions.
Description

Before:
$ bundle exec fastlane action get_info_plist_value
[..]
More information can be found on https://docs.fastlane.tools/actions

Now:
$ bundle exec fastlane action get_info_plist_value
[..]
More information can be found on https://docs.fastlane.tools/actions/get_info_plist_value

The only changed needed for this was to append the filter to the URL.

I signed it!

Cc @joshdholtz

@BasThomas Are there any tests around this already that we can add to? And does this also work for plugins too? 🙃

@joshdholtz it doesn't seem like there are tests that check the printed text here. If you think we should add some, please let me know. Could probably use some help with it in that case.
Plugins already print a direct URL to the respective GitHub repository:
$ fastlane search_plugins bearychat
[..]
You can find more information for bearychat on https://github.com/dvlprliu/fastlane-plugin-bearychat

Friendly reminder that this PR is still open. I think this is ready to merge! 😄


Prepare for move EnoghTokenValidator to commons

Moved errors, interface and resolve depend on contracts

Split to 2 prs


fix(client): prefer CLI arguments, following OpenSSH behaviour

This PR fixes issue #35 where the client preferred the values from the configuration file ~/.ssh/config instead of the CLI arguments. The new behaviour reflects the one used by OpenSSH, preferring the port from the CLI and the hostname from the configuration.

The integration test suite might be a bit agressive sometimes, I'll run it locally later and let you know

How do I run the tests? go test ./... says everything is OK.

In my opinion, the failures are not a result of code changes, as I get the same errors when running integration tests on the main branch.

I'm not familiar with the Ginko test framework, so I don't know where the faults are coming from. I am willing to help resolve the failing tests with time assistance.
Furthermore, I find it interesting that macOS builds pass, but Linux do not. Do you happen to know the reason for this?

Sorry for the delay, I am bit busy on week ends :-)
Sooo, it is a bit surprising, especially that I am not able to reproduce the fails on my own setup on several distros. It seems either the server in the integration tests crashes at some point. What is also weird is that I cannot reproduce the fails on the main branch when I rerun the Github action on it, but the error seems unrelated to your PR. We probably need a bit more logging on the server-side, and in the test suite, check that the server Consistently does not crash with an error, so that we can get the actual error if it crashes. I can try to add that additional checks on the test suite to debug that.
Thanks for the PR ad the help ! Let's continue to investigate.

Allright, both the integration test suite and your PR seem fine, the problem is probably the github secrets that do not seem accessible in PRs from non-maintainers. These secrets are not real secrets so I'll remove these and generate all the stuff (mock certs and keys) in the CI script. Let's get back to the real topic of this PR, I'll do a review soon. :-)

Thank you for investing the time looking into this. I have just merged with main. We'll see how GitHub likes the changes :yum:

Github seems to love it.
I'll do the PR review tomorrow.
Thanks gain!

Nice! Your changes seem to make GitHub happy, which makes me happy (^u^). Thanks again for investigating the problem. Please don't hesitate to ask for changes if needed.


Prevent/override autosave on field

I have a custom-built typeahead-like input. I want to be able to autosave this form which contains several fields, however the loss of focus on the field happens before the click event for the options, so autosave submits before a proper value is selected.
I couldn't find anything in the docs or code that looked like a way to prevent this on one field, or a way to call it manually from my own event handlers if I could stop it. Correct me if I'm wrong, or perhaps this could be a future feature?

 Using 'mousedown' instead of 'click' fixes this issue. Sleep deprivation yay!
It may still be useful to be able to disable/enable autosave for specific elements.

At the moment, an "autosave" is just a form submit, so calling $('#myFormId').submit() is all you need to do to manually autosave. I hope to make a more advanced autosave eventually.

Tracking autosave enhancements in #799


OutputFormat.Detailed does not affect intermediate recognition

Overview of the Issue
Intermediate results from continuous recognition don't have a confidence score, even when OutputFormat has been set to detailed.
Is there documentation on what is included in intermediate results, and/or what is included in simple vs detailed output?
Expected output -
Changing OutputFormat from simple to detailed will give have the intermediate results report their confidence level.
Version - what version is affected (e.g. 0.1.2)
1.8.0, java SDK
Motivation for or Use Case - explain what are you trying to do and why the current behavior is a bug for you
Operating System - Linux
Reproduce the Error -
var config = SpeechConfig.fromSubscription("YorKey","AValidRegion")
config.outputFormat = OutputFormat.Detailed
//Audioconfig is from an audiostream
var recognizer = SpeechRecognizer(speechConfig, audioConfig)
recognizer.recognizing.addEventListener{s,e ->
e.result.properties.getProperty(PropertyId.SpeechServiceResponse_JsonResult)
//Gives a json that has duration, text, and offset
}
recognizer.recognized.addEventListener{s,e ->
e.result.properties.getProperty(PropertyId.SpeechServiceResponse_JsonResult)
//Gives a json that has duration, text, offset, and a list of nbest results with confidence scores.
}

The OutputFormat.Detailed only controls the recognized results. The intermediate results only contains Text, Offset and Duration regardless the OutputFormat is set to.
I would not put too much trust into the intermediate results since they are changing. So the confidence score sounds not very useful.


App freezing on launch due to Crashlytics

Using the latest version of this plugin v2.0.1 (although, not tried this with a plain Cordova app).
As soon as I'm launching the app, an exception is being thrown:
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: Settings request failed.
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: java.io.InterruptedIOException: timeout
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.RealCall.timeoutExit(RealCall.java:107)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.RealCall.execute(RealCall.java:96)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.firebase.crashlytics.internal.network.HttpRequest.execute(com.google.firebase:firebase-crashlytics@@17.0.0-beta02:129)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.firebase.crashlytics.internal.settings.network.DefaultSettingsSpiCall.invoke(com.google.firebase:firebase-crashlytics@@17.0.0-beta02:86)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.firebase.crashlytics.internal.settings.SettingsController$1.then(com.google.firebase:firebase-crashlytics@@17.0.0-beta02:200)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.firebase.crashlytics.internal.settings.SettingsController$1.then(com.google.firebase:firebase-crashlytics@@17.0.0-beta02:193)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.android.gms.tasks.zzp.run(Unknown Source:2)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.firebase.crashlytics.internal.common.ExecutorUtils$1$1.onRun(com.google.firebase:firebase-crashlytics@@17.0.0-beta02:60)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at com.google.firebase.crashlytics.internal.common.BackgroundPriorityRunnable.run(com.google.firebase:firebase-crashlytics@@17.0.0-beta02:27)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at java.lang.Thread.run(Thread.java:764)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: Caused by: java.io.IOException: Canceled
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:254)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	at okhttp3.RealCall.execute(RealCall.java:92)
03-25 14:33:44.346 18825 18922 E FirebaseCrashlytics: 	... 10 more

I checked the release notes, I found that v17.0.0-beta02 was release recently so tried with that as well:
cordova plugin add cordova-plugin-firebase-crash --variable FIREBASE_CRASHLYTICS_VERSION=17.0.0-beta02

Any idea?
I'm using other Firebase plugins:
"cordova-plugin-firebase-analytics": "^4.1.2",
"cordova-plugin-firebase-crash": "^2.0.1",
"cordova-plugin-firebase-dynamiclinks": "^4.2.0",
"cordova-plugin-firebase-inappmessaging": "^3.1.0",
"cordova-plugin-firebase-messaging": "^4.1.1",

@sagrawal31 do you have a working internet connection? It seems like crashlytics SDK can't connect to their servers.

Yes @chemerisuk, the device has the working internet connection.
I too had that question first (after seeing the logs).

@sagrawal31 I don't have such an issue in my app. Everything works and exceptions are recorded.

That's weird. Not sure why it's breaking on my app. Let me retest things.

But @chemerisuk, will the app wait for crashlytics to initialize before it starts? Will it block the main UI thread?

@sagrawal31 it shouldn't block. I think Crashlytics initializes in a ContentProvider.

Okay, thank you for help. I'm working on it. It was working day before yesterday and suddenly got broken today.

@chemerisuk I saw that you upgraded the dependencies and published a new release. Thank you for that.
I was banging my head for the last 8 hours and I finally got my production app working.
Looks like, my app is freezing because of cordova-plugin-firebase-inappmessaging. Because as soon as I'm removing it, my app is working fine.

@sagrawal31 I also have cordova-plugin-firebase-inappmessaging in my app and haven't noticed anything. Yesterday some google services didn't work properly in my region, may be you had similar issues in your region and it was the cause.

@chemerisuk actually, I'm about to create an issue in that repository

But let's discuss this first here and if needed, I'll create it there.
Basically, I'm able to reproduce that constantly in a fresh Cordova app and I'm still facing this issue.

By the way, I was looking yesterday on the status dashboard at https://status.firebase.google.com/ & https://status.cloud.google.com/ because I too was thinking that this must be because of some Firebase issue.

@sagrawal31 agree, go ahead and create an issue in that repo.

@chemerisuk done, sir.


ELB OTP deployment failed to assign ec2 server to target group

:tada: This issue has been resolved in version 3.7.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add ability for users to turn off major features of the plugin in their preferences

Do this for suggestion feature and table formatter

Do we want this to be project specific or workspace specific?


Add google collab/binder links

@BioGeek does this look correct?

The Colab link gives me the following modal:

I think that is because you are linking to the notebook file on your personal Google drive? You can adapt the link to point to the publicly accessible Github file like this:
https://colab.research.google.com/github/chris-rands/biopython-coronavirus/blob/master/biopython-coronavirus-notebook.ipynb
The Binder link can be slightly improved by instructing it to open the notebook directly:
https://mybinder.org/v2/gh/chris-rands/biopython-coronavirus/master?filepath=biopython-coronavirus-notebook.ipynb
So the button becomes:

Thank you, better now?

The Binder link now works as expected. But for the Google Colab link we get an import error because BioPython is not installed by default (and Google Colab doesn't look at the environment.yml file). So I would add a conditional before the imports that first tries to import to import a module that only exists in Colab and if so also installs BioPython.
This code cell shouldn't have any effect when run on mybinder.org.
try:
  import google.colab
  # We're running this notebook in Google Colab, so first install BioPython
  !pip install biopython==1.76
except:
  pass

Thanks, that was careless of me (I added this on my local google drive copy before), added it to the repo now via https://github.com/chris-rands/biopython-coronavirus/commit/435c6e0e0483031933905786cee219c65c6984fb. Okay now?

Yes, this looks good now.
A final tiny nitpick. Your commit 435c6e0  also includes updated values for the execution_count metadata. If you don't want these to clutter up your commit you can adapt a script like this to reset them before committing the notebook (but I would suggest to keep the outputs), or use nbdime and configure it to ignore execution_count.

Great, thanks for your help!
Yes, I deliberately included the full output here, since the Notebook is small and some users may just view it. I have used nbstripout (and nbdime) for other projects

@BioGeek  Would you like to be named as a contributed at the bottom of the README?
e.g.
Contributors

Chris Rands
Jeroen Van Goey

That is kind of you to suggest that, but you did the hard work of writing the notebook itself. I'm glad that I could be of assistance but no need to specifically mention me as contributor.


Add files via upload

@hiemke file/lib/domains/de/lsh-marquartstein.txt: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@hiemke First stage of verification passed, official domain for Gymnasium Landschulheim Marquartstein is lsh-marquartstein.de as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@hiemke Thank you for your patience while waiting for a review and processing your request. Pull request merged.
Please start requesting the licenses in about an hour, to let the changes to propagate through our system.


Non-string anchors no longer work

Passing non-string values to url_for no longer works. For example,
url_for('my_endpoint', _anchor=5)

It now fails with TypeError: quote_from_bytes() expected bytes.

But it was never intended to accept non-strings, that was just a side effect of the extra checks that were required to support bytes

The effect was that you could pass non-strings to this function and they would be converted automatically. Many other parameters to this function work this way. For example, if you have an int parameter on your endpoint, it will be converted to str automatically.
The intention doesn't really matter. This is a regression in behavior.

Where was the deprecation period? You should also have something in the release notes about changing the behavior...

https://werkzeug.palletsprojects.com/en/2.3.x/changes/#version-2-3-0

Deprecate the werkzeug.urls module, except for the uri_to_iri and iri_to_uri functions. Use the urllib.parse library instead.

Passing bytes where strings are expected is deprecated ... Anywhere that was annotated, documented, or tested to accept bytes shows a warning.

Passing a non-string as an anchor was never intentionally supported, you were relying on undefined behavior. I don't plan to add a warning back in just to then remove it again. It's the same result either way here: you need to pass a string.


Excluded Concierge, Chronos and receipts from IOU Requests search

@marcaaron
Details
Just excluded bot accounts from IOU Participants Search Results
Fixed Issues

$ #4413
Tests & QA Steps

Search any of the following emails on the IOU request/split participants page.

 CHRONOS -<EMAIL_ADDRESS> CONCIERGE -<EMAIL_ADDRESS> RECEIPTS -<EMAIL_ADDRESS>

Fix - In search results, the above emails will not appear now.

Note: Chronos/Receipts may appear in recent items - it will be handled in another issue check issue description for more.
Tested On

[x] Web
[x] Mobile Web
[x] Desktop
[x] iOS
[x] Android

Screenshots
Screenshots for all platforms tested. Pull requests won't be merged unless the screenshots show the app was tested on all platforms.-->
Desktop

Web

Mobile Web

iOS

Android

@marcaaron I see a conflict in this PR due to some recent changes so can I close this and create a new PR?

I Have tested it once again & all checks are passed marking it ready for review.

Working on the request changes

@marcaaron Requested changes have been updated.


Fix test assertions

This commit fixes some of the test assertions for 8.x snapshots.

Ok, I'll look to see if this test can be hardened further; I didn't see any failures locally.


Construct BST Program

Code the given problem in any of the programming language. The code should be appropriate and don't use any extra words while printing the answer.
Statement:
Given a sorted integer array A of size n, which contains all unique elements. You need to construct a balanced BST from this input array. Return the root of constructed BST.
Note: If array size is even, take first mid as root.
Input format:
The first line of input contains an integer, which denotes the value of n. The following line contains n space separated integers, that denote the values of array.
Output Format:
The first and only line of output contains values of BST nodes, printed in pre order traversal.
Constraints:
Time Limit: 1 second
Sample Input:
7
1 2 3 4 5 6 7
Sample Output:
4 2 1 3 6 5 7

please assign

i have a doubt how to merge program if i have code.
#include <bits/stdc++.h>
using namespace std;
/* A binary tree node has data, pointer to left child
and a pointer to right child /
class node {
public:
int data;
node left;
node* right;
};
// A utility function to create a node
node* newNode(int data)
{
node* temp = new node();
temp->data = data;
temp->left = temp->right = NULL;

return temp;

}
// A recursive function to construct Full from pre[].
// preIndex is used to keep track of index in pre[].
node* constructTreeUtil(int pre[], int* preIndex, int low,
int high, int size)
{
// Base case
if (*preIndex >= size || low > high)
return NULL;
// The first node in preorder traversal is root. So take
// the node at preIndex from pre[] and make it root, and
// increment preIndex
node* root = newNode(pre[*preIndex]);
*preIndex = *preIndex + 1;

// If the current subarray has only one element, no need
// to recur
if (low == high)
    return root;

// Search for the first element greater than root
int i;
for (i = low; i <= high; ++i)
    if (pre[i] > root->data)
        break;

// Use the index of element found in preorder to divide
// preorder array in two parts. Left subtree and right
// subtree
root->left = constructTreeUtil(pre, preIndex, *preIndex,
                               i - 1, size);
root->right
    = constructTreeUtil(pre, preIndex, i, high, size);

return root;

}
// The main function to construct BST from given preorder
// traversal. This function mainly uses constructTreeUtil()
node* constructTree(int pre[], int size)
{
int preIndex = 0;
return constructTreeUtil(pre, &preIndex, 0, size - 1,
size);
}
// A utility function to print inorder traversal of a Binary
// Tree
void printInorder(node* node)
{
if (node == NULL)
return;
printInorder(node->left);
cout << node->data << " ";
printInorder(node->right);
}
// Driver code
int main()
{
int pre[] = { 1, 2, 3, 4, 5, 6,7 };
int size = sizeof(pre) / sizeof(pre[0]);
node* root = constructTree(pre, size);

cout << "Inorder traversal of the constructed tree: \n";
printInorder(root);

return 0;

}

@Harsh-COE Send the PR, if your code will be correct then only it will be considered for merging.

okk
On Sun, Oct 3, 2021 at 12:01 AM Jatin Aggarwal @.***>
wrote:

@Harsh-COE https://github.com/Harsh-COE Send the PR, if your code will
be correct then only it will be considered for merging.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jatinagg2/OOPS-Programs-Hacktoberfest-2021/issues/6#issuecomment-932799747,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARHVC665EXRRSIAPP5BLFJLUE5FZ5ANCNFSM5FGTT45A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Fragment+MvRxView's asyncSubscribe not (quite?) disposed with mavericks-rxjava2

I'm trying out swapping in mavericks:2.1.0 and mavericks-rxjava2:2.1.0 on an app with existing screens that were previously using mvrx:1.5.1. I've made the changes described in the transition docs and also deleted the explicit viewLifecycleOwner first argument in all my uses of asyncSubscribe since it's no longer present.
With no other changes I started getting exceptions with the "Subscribing with a duplicate subscription id" error message when navigating forward and then returning back to any fragment that was using deliveryMode = uniqueOnly() on a subscription. I looked at a subscription without the unique delivery mode and it seems isDisposed on the returned Disposable remains false beyond onDestroyView back through to the next onCreateView. I started adding subscriptions to a list and logging which looks like this on 1.5.1:
onCreateView ⇒ 1 subscriptions created, isDisposed: [false]
onDestroyView ⇒ 1 subscriptions created, isDisposed: [true]
onCreateView ⇒ 2 subscriptions created, isDisposed: [true, false]
onDestroyView ⇒ 2 subscriptions created, isDisposed: [true, true]
onCreateView ⇒ 3 subscriptions created, isDisposed: [true, true, false]
onDestroyView ⇒ 3 subscriptions created, isDisposed: [true, true, true]

but now this on 2.1.0:
onCreateView ⇒ 1 subscriptions created, isDisposed: [false]
onDestroyView ⇒ 1 subscriptions created, isDisposed: [false]
onCreateView ⇒ 2 subscriptions created, isDisposed: [false, false]
onDestroyView ⇒ 2 subscriptions created, isDisposed: [false, false]
onCreateView ⇒ 3 subscriptions created, isDisposed: [false, false, false]
onDestroyView ⇒ 3 subscriptions created, isDisposed: [false, false, false]

Active subscriptions are now stacking up every time the view lifecycle loops, or in the case where unique delivery mode is requested they're an immediate exception throw at the point where they would be resubscribed. I looked at the default subscriptionLifecycleOwner and would expect viewLifecycleOwner to get used implicitly for asyncSubscribe called in Fragment.onCreateView here, but also tried overriding it in the fragment to only supply viewLifecycleOwner and got the same result.

@krage Mavericks ViewModel subscriptions should be made in onCreate. Can you move them there and see if that helps?

For tidiness and preventing misuse of the viewbinding it's not available in some of these fragments outside of onCreateView so moving all subscriptions up to onCreate would take some restructuring. The easier bandaid fix for me is probably tacking on an extra observer to directly call dispose() on each of these subscriptions at viewLifecycle's destroyed state - they already each need an edit to remove the old lifecycle arg anyways.
Regardless of potential workarounds though shouldn't subscriptions made with viewLifecycle still be disposed when view lifecycle reaches destroyed? The doc comment linked above for subscriptionLifecycleOwner in MavericksView still suggests that's the case:

Subscriptions made in or after onCreateView should use the fragment's view's lifecycle owner so that they are cleared in onDestroyView.

Added a test subscription started in onCreate (should be subscribing with fragment lifecycle), logged there and in fragment onDestroy:
onCreate ⇒ 1 subscriptions started in onCreate, isDisposed: [false]
onDestroy ⇒ 1 subscriptions started in onCreate, isDisposed: [false]

Also logged the state of the previous collection started in onCreateView (with view lifecycle) to fragment's onDestroy and none of them are disposed at that point either:
onCreateView ⇒ 1 subscriptions started in onCreateView, isDisposed: [false]
onDestroyView ⇒ 1 subscriptions started in onCreateView, isDisposed: [false]
onCreateView ⇒ 2 subscriptions started in onCreateView, isDisposed: [false, false]
onDestroyView ⇒ 2 subscriptions started in onCreateView, isDisposed: [false, false]
onCreateView ⇒ 3 subscriptions started in onCreateView, isDisposed: [false, false, false]
onDestroyView ⇒ 3 subscriptions started in onCreateView, isDisposed: [false, false, false]
onDestroy ⇒ 3 subscriptions started in onCreateView, isDisposed: [false, false, false]

No obvious adverse effects from subscriptions lingering though onDestroy but there's also no new state being produced in the viewmodel... maybe subscriptions are eventually still ending by their sources completing as the fragment-scoped viewmodel is cleared?

Another round switching instead to jobs created with onAsync and tracking their isActive.
For fragment lifecycle jobs started in onCreate looks good:
onCreate ⇒ 1 jobs created in onCreate, isActive: [true]
onDestroy ⇒ 1 jobs created in onCreate, isActive: [false]

But for view lifecycle jobs started in onCreateView:
onCreateView ⇒ 1 jobs created in onCreateView, isActive: [true]
onDestroyView ⇒ 1 jobs created in onCreateView, isActive: [true]
onCreateView ⇒ 2 jobs created in onCreateView, isActive: [true, true]
onDestroyView ⇒ 2 jobs created in onCreateView, isActive: [true, true]
onCreateView ⇒ 3 jobs created in onCreateView, isActive: [true, true, true]
onDestroyView ⇒ 3 jobs created in onCreateView, isActive: [true, true, true]
onDestroy ⇒ 3 jobs created in onCreateView, isActive: [false, false, false]

no longer active in onDestroy is an improvement vs the disposables but I still would've expected these to have ended earlier by onDestroyView.

@krage Mavericks handles all of that for you :) You do your subscription in onCreate but it will only ever be invoked with the view is started so you can freely using bindings in it.

@gpeal Whether or not that's the case MavericksView docs still say subscriptions made in or after onCreateView should use viewLifecycle and will be cleared in onDestroyView:
    /**
     * The [LifecycleOwner] to use when making new subscriptions. You may want to return different owners depending
     * on what state your [MavericksView] is in. For fragments, subscriptions made in `onCreate` should use
     * the fragment's lifecycle owner so that the subscriptions are cleared in `onDestroy`. Subscriptions made in or after
     * `onCreateView` should use the fragment's _view's_ lifecycle owner so that they are cleared in `onDestroyView`.
     *
     * For example, if you are using a fragment as a [MavericksView] the proper implementation is:
     * ```
     *     override val subscriptionLifecycleOwner: LifecycleOwner
     *        get() = this.viewLifecycleOwnerLiveData.value ?: this
     * ```
     *
     * By default [subscriptionLifecycleOwner] is the same as the MvRxView's standard lifecycle owner.
     */
    val subscriptionLifecycleOwner: LifecycleOwner
        get() = (this as? Fragment)?.viewLifecycleOwnerLiveData?.value ?: this

@krage Yes, this is what ensures that the callback only happens when your view is started which is why it's safe to use bindings in your callback. However, it is still advised to make the subscription in onCreate.

@gpeal I feel like you're still not hearing the issue here. Previous behavior and current documentation both say that subscriptions made in/after onCreateView should use the view's lifecycle. Currently they do not.
After more investigation the main problem is that viewLifecycleOwnerLiveData.value is still null in onCreateView so default subscriptionLifecycleOwner implementation still uses Fragment lifecycle there. A possible fix to support using view lifecycle in the way it's described in the documentation is replacing/overriding subscriptionLifecycleOwner with:
val subscriptionLifecycleOwner: LifecycleOwner
    get() = try {
        (this as? Fragment)?.viewLifecycleOwner ?: this
    } catch(e: IllegalStateException) {
        this
    }

I feel like it's not great to have to use the exception as a signal here but with the change in Mavericks to not directly accept a lifecycle owner at the point of subscription this seems like the available alternative.
There's also a secondary kind of cosmetic issue where the disposable wrapper added to jobs in MvRxView doesn't get marked disposed when the internal job completes. Here's a possible quick fix that works. It would probably be improved with a more direct implementation of Disposable that was job-aware so that isDisposed could be derived directly from !isActive and the job being cancelled wouldn't need to call dispose() thus re-triggering the action and calling cancel() on that already complete job:
private fun Job.toDisposable() = Disposables.fromAction {
    cancel()
}.apply {<EMAIL_ADDRESS>{ dispose() } }

I added similar logging (with better formatting) to the hellohilt sample app. To keep changes minimal since HelloHiltState has no Async fields I used onEach/selectSubscribe instead of onAsync/asyncSubscribe.  Disposables are logged as "subscriptions" with subscribed status from !isDisposed so they're directly comparable to Job.isActive.
Before the above fixes:
onCreate      ⇒ 1 jobs started in onCreate,                isActive: [true]
onCreate      ⇒ 1 subscriptions started in onCreate,     subscribed: [true]
onCreateView  ⇒ 1 jobs started in onCreateView,            isActive: [true]
onCreateView  ⇒ 1 subscriptions started in onCreateView, subscribed: [true]
onDestroyView ⇒ 1 jobs started in onCreateView,            isActive: [true]
onDestroyView ⇒ 1 subscriptions started in onCreateView, subscribed: [true]
onCreateView  ⇒ 2 jobs started in onCreateView,            isActive: [true, true]
onCreateView  ⇒ 2 subscriptions started in onCreateView, subscribed: [true, true]
onDestroyView ⇒ 2 jobs started in onCreateView,            isActive: [true, true]
onDestroyView ⇒ 2 subscriptions started in onCreateView, subscribed: [true, true]
onCreateView  ⇒ 3 jobs started in onCreateView,            isActive: [true, true, true]
onCreateView  ⇒ 3 subscriptions started in onCreateView, subscribed: [true, true, true]
onDestroyView ⇒ 3 jobs started in onCreateView,            isActive: [true, true, true]
onDestroyView ⇒ 3 subscriptions started in onCreateView, subscribed: [true, true, true]
onDestroy     ⇒ 3 jobs started in onCreateView,            isActive: [false, false, false]
onDestroy     ⇒ 3 subscriptions started in onCreateView, subscribed: [true, true, true]
onDestroy     ⇒ 1 jobs started in onCreate,                isActive: [false]
onDestroy     ⇒ 1 subscriptions started in onCreate,     subscribed: [true]

and after these two fixes:
onCreate      ⇒ 1 jobs started in onCreate,                isActive: [true]
onCreate      ⇒ 1 subscriptions started in onCreate,     subscribed: [true]
onCreateView  ⇒ 1 jobs started in onCreateView,            isActive: [true]
onCreateView  ⇒ 1 subscriptions started in onCreateView, subscribed: [true]
onDestroyView ⇒ 1 jobs started in onCreateView,            isActive: [false]
onDestroyView ⇒ 1 subscriptions started in onCreateView, subscribed: [false]
onCreateView  ⇒ 2 jobs started in onCreateView,            isActive: [false, true]
onCreateView  ⇒ 2 subscriptions started in onCreateView, subscribed: [false, true]
onDestroyView ⇒ 2 jobs started in onCreateView,            isActive: [false, false]
onDestroyView ⇒ 2 subscriptions started in onCreateView, subscribed: [false, false]
onCreateView  ⇒ 3 jobs started in onCreateView,            isActive: [false, false, true]
onCreateView  ⇒ 3 subscriptions started in onCreateView, subscribed: [false, false, true]
onDestroyView ⇒ 3 jobs started in onCreateView,            isActive: [false, false, false]
onDestroyView ⇒ 3 subscriptions started in onCreateView, subscribed: [false, false, false]
onDestroy     ⇒ 3 jobs started in onCreateView,            isActive: [false, false, false]
onDestroy     ⇒ 3 subscriptions started in onCreateView, subscribed: [false, false, false]
onDestroy     ⇒ 1 jobs started in onCreate,                isActive: [false]
onDestroy     ⇒ 1 subscriptions started in onCreate,     subscribed: [false]

Not ideal fixes but made with a relatively light touch. The subscription lifecycle results are now what I'd expect. Thoughts?

@krage yes, you're right that subscribing in onCreateView is supposed to be supported, and result in the subscription being canceled in onDestroyView. We added that support explicitly with https://github.com/airbnb/mavericks/pull/210
The code you pointed to looks like it should still be working
    override val subscriptionLifecycleOwner: LifecycleOwner
        get() = this.viewLifecycleOwnerLiveData.value ?: this

and it is a bit alarming if it doesn't. I don't know that that implementation would have changed from mvrx 1.x so I'm curious if the upgrade to 2.x is actually related (besides that before you could make it work with an manual lifecycle override). We rely on this fairly often at airbnb for subscribing in onViewCreated, and haven't had problems.
Looking at getViewLifecycleOwnerLiveData the javadoc says This will be set to the new {@link LifecycleOwner} after {@link #onCreateView} returns a non-null View and will set to null after {@link #onDestroyView()}.
Whereas getViewLifecycleOwner javadoc clearly says it is accessible within onCreateView.
So I think that explains the behavior you are seeing (and also why we haven't had a problem at airbnb since we use onViewCreated). One option is to change documentation to say that view lifecycle subscriptions should only be done in onViewCreated, but I think that is a bit confusing and error prone so using your try/catch approach does seem like the best thing to do.
As far as the Disposable not being disposed, that seems like a good catch and a reasonable fix - I don't have a strong opinion on it.

Yeah that's the distinction I recognized as well - the existing implementation would work in onViewCreated but earlier in onCreateView even though the view lifecycle itself is available the livedata's value is null until the return so it does the wrong thing.
As described in my upgrade from 1.x I was passing in an explicit LifecycleOwner to every subscribe call made in fragments so I provided viewLifecycleOwner directly there. Upon review it looks like those variations of subscribe methods in BaseMvRxViewModel that include that lifecycle owner as first arg were marked @RestrictTo(RestrictTo.Scope.LIBRARY) at least in 1.5.1 so I'm not sure how I ended up using them... maybe they weren't marked restricted in some prior version so they popped up as options in Android Studio autocomplete? In any case that explains why it worked for me in 1.x - I was bypassing the old implementation of subscriptionLifecycleOwner in BaseMvRxFragment which does appear equivalent to the one currently in MavericksView and would have the same issue.

Just had a quick try deleting those viewLifecycleOwner overrides made in onCreateView in my old build using 1.5.1 and it definitely fails in the same way without them.

Here's a more complete Disposable wrapper for Job adapted from ReferenceDisposable to avoid the unnecessary re-cancel:
private class JobDisposable(job: Job) : AtomicReference<Job>(job), Disposable {
    init {
        job.invokeOnCompletion { set(null) }
    }

    override fun dispose() {
        getAndSet(null)?.cancel()
    }

    override fun isDisposed(): Boolean = get()?.isActive?.not() ?: true
}

private fun Job.toDisposable(): Disposable = JobDisposable(this)

Should I put this and the try/catch view lifecycle change in a PR (or two)?

@krage If you could just bundle those in the same PR we'd appreciate the contribution!