Implement EIP232 new transaction format

What is wrong?
Discussion started in #326 which are about how to supply salt value to contract-creating transaction in Sharding where CREATE2 style contract creation is implemented. CREATE2 takes in a value salt and init code code, address of the new contract is derived from hashing these two values together: sha3(salt | code).
In the short term,  we can simply add a salt field in transaction format, but this field is only useful in contract creation transactions. EIP232 provides a more elastic format which adopts the notion of a version(or format) number. With EIP232 we can assign different type of transaction with different version/format number which corresponds to different transaction format.
How can it be fixed
Implement EIP232 in Sharding.
@pipermerriam provides a rough sketch of the possible implementation in the thread(https://github.com/ethereum/py-evm/issues/326#issuecomment-362714619):
Quote:
class EIP232Transaction(rlp.Serializable):
    fields = (
        ('version', ...),
        ('inner_data', sedes.binary),
    (
    transaction_formats = {
        1: TransactionFormatA,
        2: TransactionFormatB,
    }

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.txn_data = rlp.decode(self.inner_data, sedes=self.transaction_formats[self.version])

    def __getattr__(self, name):
        return getattr(self.txn_data, name)

We have an outer transaction class which contains a mapping of version numbers to inner transaction classes. Then, during initialization, we decode the outer data packet, and then lookup the appropriate inner transaction class and use it to decode the inner data packet. Then we put some convenience APIs on the outer class to allow direct property access to the inner transaction properties.

deactivate


$("blah").shouldNot(exist.because("")) throws ElementNotFound

The problem
Introduce in Selenide 5.11.0

$("blah").shouldNot(exist) - ok
$("blah").shouldNot(exist.because("")) - fails (NOK)

Tell us about your environment

Selenide Version:  5.11.0

fixed by https://github.com/selenide/selenide/pull/1131


Can't build jni libsvm (please read and answer)

First I use android studio 2.3.3 (Windows)
I download the file and started extracting it
In the first i opened, android studio ask me to update gradle, because gradle in this project v 2.3.3 and and in android studio v 3.3 (I click update)
I'm updated all gradle config (:app, :aFileChooser, :openCvLibrary249) to newer sdk version

    compileSdkVersion 25
    buildToolsVersion "25.0.3"
    defaultConfig {
        minSdkVersion 19
        targetSdkVersion 25
    }

Next i must Build the jni libraries libHandGestureApp.so and libsignal.so, In Instalation readme file, i follow this post to build ndk file in app/src/main/jni, when I build give this error message :

for calloc() I added #include <stdlib.h> and give new error, jni/src/train.cpp:8:9: warning: 'LOG_TAG' macro redefined [-Wmacro-redefined]#define LOG_TAG "TRAIN", and warning: conversion from string literal to 'char *' is deprecated [-Wc++11-compat-deprecated-writable-strings] :(

Thank you so much
Best Regards

Any solution ? :)

Having the same issue:
Android NDK: WARNING:jni/Android.mk:HandGestureApp: non-system libraries in linker flags: -lopencv_java
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK:     current module
Android NDK: WARNING:jni/Android.mk:HandGestureApp: non-system libraries in linker flags: -lopencv_java
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK:     current module
[armeabi-v7a] Compile++ thumb: HandGestureApp <= jni_process.cpp
[armeabi-v7a] SharedLibrary  : libHandGestureApp.so
[armeabi-v7a] Install        : libHandGestureApp.so => libs/armeabi-v7a/libHandGestureApp.so
[armeabi-v7a] Compile++ thumb: signal <= onload.cpp
[armeabi-v7a] Compile++ thumb: signal <= info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp
jni/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp:34:32: error: use of undeclared identifier 'calloc'
float **values = (float **)calloc(rowNum, sizeof(float *));
^
jni/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp:35:29: error: use of undeclared identifier 'calloc'
int **indices = (int **)calloc(rowNum, sizeof(int *));
^
jni/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp:42:30: error: use of undeclared identifier 'calloc'
values[i] = (float *)calloc(colNum, sizeof(float));
^
jni/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp:43:29: error: use of undeclared identifier 'calloc'
indices[i] = (int *)calloc(colNum, sizeof(int));
^
jni/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp:56:9: error: use of undeclared identifier 'free'
free(values[i]);
^
jni/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.cpp:57:9: error: use of undeclared identifier 'free'
free(indices[i]);
^
6 errors generated.
make: *** [obj/local/armeabi-v7a/objs/signal/jni/info_kunli_androidlibsvmexample_AndroidLibsvmExampleActivity.o] Error 1
Process finished with exit code 2


Allow action binding to UIBarButtonItem

Allows for similar action binding to UIBarButtonItem as found for UIButton.

Thanks for the PR! Just one quick comment.

Updated according to the comment.

:sparkles:


Tsa secret optional for tuf

Description of the change
Make the TSA secret reference optional for TUF chart.
Existing or Associated Issue(s)
#735
Additional Information
Checklist

[x] Chart version bumped in Chart.yaml according to semver. Where applicable, update and bump the versions in any associated umbrella chart
[x] Variables are documented in the values.yaml and added to the README.md. The helm-docs utility can be used to generate the necessary content. Use helm-docs --dry-run to preview the content.
[x] JSON Schema generated.
[x] List tests pass for Chart using the Chart Testing tool and the ct lint command.

------------------------------------------------------------------------------------------------------------------------
 Charts to be processed:
------------------------------------------------------------------------------------------------------------------------
 tuf => (version: "0.1.13", path: "charts/tuf")
------------------------------------------------------------------------------------------------------------------------

"sigstore" already exists with the same configuration, skipping
Linting chart "tuf => (version: \"0.1.13\", path: \"charts/tuf\")"
Checking chart "tuf => (version: \"0.1.13\", path: \"charts/tuf\")" for a version bump...
Old chart version: 0.1.12
New chart version: 0.1.13
Chart version ok.
Validating ~/Workspace/helm-charts/charts/tuf/Chart.yaml...
Validation success! 👍

Linting chart with values file "charts/tuf/ci/ci-values.yaml"...

==> Linting charts/tuf
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

------------------------------------------------------------------------------------------------------------------------
 ✔ tuf => (version: "0.1.13", path: "charts/tuf")
------------------------------------------------------------------------------------------------------------------------
All charts linted successfully```

@cvegagimenez This looks good., However, while thinking it through in practice enabled should by default be true as it aligns with the current functionality of the chart. By setting to false, it would be a breaking change for anyone currently leveraging it.
The goal of this PR is to provide a way to opt out of providing secrets a, but in practice, this has now introduced the functionality where you have to opt in to achieve the current functionality. A simple swap of the default values as we should be good to integrate this change.

@cpanato does this look good to you?

but need to update the docs, can you please take a look?

but need to update the docs, can you please take a look?

@cpanato the README was updated
is there anything else missing? would you like the description field to be populated?

@cpanato , the tests are failing but I am not able to find the issue. Could you help here?
{"level":"fatal","ts":1728294947.0237236,"logger":"fallback","caller":"server/main.go:247","msg":"failed to parse /var/run/tuf-secrets/tsa.certchain.pem: unmarshaling certificates: error during PEM decoding","stacktrace":"main.main\n\tgithub.com/sigstore/scaffolding/cmd/tuf/server/main.go:247\nruntime.main\n\truntime/proc.go:272"}

@cpanato , the tests are failing but I am not able to find the issue. Could you help here?
{"level":"fatal","ts":1728294947.0237236,"logger":"fallback","caller":"server/main.go:247","msg":"failed to parse /var/run/tuf-secrets/tsa.certchain.pem: unmarshaling certificates: error during PEM decoding","stacktrace":"main.main\n\tgithub.com/sigstore/scaffolding/cmd/tuf/server/main.go:247\nruntime.main\n\truntime/proc.go:272"}

Looking at previous test runs, we always had this error but it was somehow still passing the chart installation (incorrect behaviour). The error happens because by default all the secrets are enabled and scaffolding tuf server expects a valid certificate for tsa certificate chain.
The test failing now is the correct behavior, presumable a result of latest scaffolding tuf server image. To fix the actual problem, we could set create: true for TSA secret but this enables it by default for everyone using the default values.


docs_main.cr is a mess

docs_main.cr serves as entry point to generate the API docs for the standard library. It requires all files that contain documented features.
It's quite a chaotic mess.
Entries are unordered. That's probably due to some forced order dependencies, not sure about the details.
Many entries are omitted because they're already required as part of the prelude or are transitive dependencies of others. This makes it hard to follow which files actually end up being included in the docs.
There's generally quite a bit of overlap with prelude.cr. But it's inconsistent because some parts of the prelude are also in docs_main.cr (require "array") while others aren't (require "base64").
It would be cleaner to either embrace the prelude and remove duplicates, or spell out all requires in docs_main.cr explicitly and even remove the prelude from the docs build (crystal docs src/docs_main.cr --prelude=empty).
I don't think removing the prelude makes much sense. It would allow us to exclude files that don't contain any documented features, but they might be implicit requirements of other code that's relevant for documentation.
It would also be helpful to have a reminder to ensure newly added files are present in docs_main.cr. That's a relatively rare event, so we don't always remember it (see #14624). Most new files are added to paths like src/compiler, src/crystal or src/lib_c anyway, which can be ignored for docs.
Not sure if there's an easy way to do this, though. It might not be terribly relevant because we should usually notice if API docs are missing when preparing the release notes, so we should be able to fix it in time before a release.
So I'd suggest to do the following:

Remove all entries in docs_main.cr which are already in prelude.cr.
Order all entries in docs_main.cr by path. If there are any forced order exceptions, document them (like in prelude.cr).
Consider if we can add some kind of automation to alert us of adding new files to docs_main.cr.

I wish we had a folder for std (e.g. src/std), then docs_main.cr could be (almost) reduced to:
require "./annotations"
require "./compiler/crystal/macros"
require "./std/*"
require "./docs_pseudo_methods"


spurious docker files

Thanks for this!
One little thing. This:
❯ npx node-ts-starter-cli create csl-next-ts -g -l -p

... creates docker files also (Dockerfile and .dockerignore).

I think that the following lines are a copy paste mistake that cause this, they shouldn't be in the github-action part.
https://github.com/FreekMencke/node-ts-starter-cli/blob/c202165c2884677491db9ec0ec1f382be65b20a2/src/create.js#L112-L115
I'll probably fix this in the weekend, thanks for logging it.

Be sure to use npx node-ts-starter-cli@latest or npx<EMAIL_ADDRESS>


Live share support with VS Code Custom editor

I believe this has been turned off today.
Leaving in new issues to get this proritized.
@rchiodo Or is this meant to be done as part of the syncing multiple editors?

Thanks for your feedback. This issue will be addressed once VS Code adds native support for editing notebooks. Please see https://github.com/microsoft/vscode/issues/91987. You can experiment by using VS Code insiders, which defaults to the new notebook experience.


Add ACI runtime config

First part of effort to address: https://github.com/metaparticle-io/package/issues/23
Minor cleanup

LGTM, thanks!

@brendandburns is there a way to publish Nuget with the latest change?


[QUESTION] How to programmatically shutdown hyperf?

[x] I've been read all documentation
[x] I've been search all existed issues

Is there an official supported way for stopping & shutting down hyperf gracefully within the framework code?
Some hyperf method/function to exit all workers, stop the manager, stop the Master process, exit php etc., without restarting the process again, just exit and end completely

I think signal component give us a way about how to resolve this question.
https://github.com/hyperf/signal/blob/master/src/Handler/WorkerStopHandler.php#L43
$this->container->get(Server::class)->stop();

This seems to work - but is this really the correct way?...
// 1. Get container
// 2. Get Hyperf\Server\ServerFactory from container
// 3. ServerFactory->getServer() returns Hyperf\Server\Server
// 4. Hyperf\Server\Server->getServer() returns Swoole\Http\Server
// 5. Swoole\Http\Server->shutdown()

\Hyperf\Context\ApplicationContext::getContainer()->get(\Hyperf\Server\ServerFactory::class)->getServer()->getServer()->shutdown();


[main] Update community files (#75)

Update community files
Signed-off-by: Knative Automation<EMAIL_ADDRESS>

OCF Webhook is merging this PR


Generic array allocation unreasonably slow

When allocating an array using a generic type parameter,  the allocation is much slower than necessary. After a short look at the created code, I suspect that the default value for the type is determined for each individual array element, which has a considerable performance overhead.
In contrast, when creating an array with 0 elements, and resizing it afterwards, everything runs by an order of magnitude faster. There this default value is only queried once and used for the whole array.
Fixing this issue may also speed up the collections library.
Steps To Reproduce
https://deck.net/9d47f4a62abf9957bf83c70b3c759304
using System;
using System.Diagnostics;

public class Program
{
    public static void Main()
    {
        test("int alloc    ", false, false);
        test("int resize   ", false, true);
        test("string alloc ", true, false);
        test("string resize", true, true);
    }

    static void test(string label, bool reftype, bool resize)
    {
        Stopwatch sw = new Stopwatch();
		sw.Start();
        for (int i=0; i<1000; i++)
        {
            if (reftype) Alloc<string>(10000,resize);
            else         Alloc<int>(10000,resize);
        }
        sw.Stop();
        Console.WriteLine(label+" "+sw.ElapsedMilliseconds+" ms");
    }

    static T[] Alloc<T>(int len, bool resize)
    {
        if (resize)
        {   T[] a = new T[0];
            Array.Resize(ref a, len);
            return a;
        }
        return new T[len];
    }
}

Expected Result
All execution times should be in a similar range
Actual Result
int alloc     765 ms
int resize    62 ms
string alloc  571 ms
string resize 99 ms

Thanks for the info. The performance will be improved for primitive and reference types. But structures will have the same performance because a structure must be created for each array element.

Before improvement:
int alloc     985 ms
int resize    30 ms
string alloc  1031 ms
string resize 26 ms

After improvement:
int alloc     35 ms
int resize    30 ms
string alloc  35 ms
string resize 27 ms

Looks like at least for the "intended audience" (non-structures), the performance is now pretty close to what is the "resize" test.
The improvement seems stable enough to go to next Bridge release (according to assigned milestone).


Optimizing Shared Memory Usage

Hi. I am working on writing a Triton kernel for the backward pass of a sub-quadratic attention architecture. Currently, I'm receiving the following error when compiling the kernel:
triton.runtime.errors.OutOfResources: out of resource: shared memory, Required: 167936, Hardware limit: 166912. Reducing block sizes or `num_stages` may help.

The operations involved in the kernel are complex, and I have many loads and intermediate variables created during the derivation. I had a few questions on the SRAM usage inside the kernel:

Does the order of tl.load matter, or is Triton smart enough to compile it into the most memory optimal form. IE, can I tl.load all required variables at the beginning and expect the same memory usage as if were tl.load them right before the operation they were involved in?
Is there a way to forcibly evict a variable from shared memory after loading it, if I no longer need to use it?
If I use tl.store and tl.load in the same kernel, will this force triton to write it out to HBM and then reload it from HBM?
If I load x1 = tl.load(ptr) and then later load another variable into it x1 = tl.load(ptr2) will this overwrite the memory in SRAM?
Is there a way to understand memory usage breakdown in a compiled kernel?

Note: I'm using a simple grid of shape [Batch, Heads] (like Flash Attention). I don't think blocks or num stages is relevant.
I'm also happy to share the kernel code, if needed. Hopefully there's some way I can re-arrange operations and evict from SRAM to optimize usage.

Any progress? I am quite interested in this Shared Memory Usage issue. Would it be possible for you to share your code?

@karan-dalal @Li-dongyang good day!
Triton is pretty smart in terms of shared memory usage. But it does not expose explicit handles to tweak it's usage, plus it consider load/store operations as an "anchors". If you have loads and stores, they will stay there forever, unless load results are unused. In general, moving load/store/dot operations around could help with shared memory problem, but I struggle to give a particular instructions.
Another way to address this problem is to try optimize shared memory usage in compiler. AMD backend has an optimization which potentially can help.
Currently it is AMD specific, but I think we can move it to common code if it is useful.
Could any one with this problem share a kernel code + parameters or triton gpu IR (it is saved in ~/.triton/cache/*/*.ttgir file)?


1st commit for pac-man-loader

Issue reference:
no issue
Proposed changes:
added pac man loader using css and html
Type of change:
added css and html
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Other (please specify)
[ ] This change requires a documentation update

Checklist:

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

Additional info (if any):

Thanks for the contribution @Pranay36.


We want to use setupCreateOperation function for setValidation(StoreRequest::class) or else?

I noticed this thing in backpack upgrade documention (3.6 to 4.0).
protected function setupCreateOperation()     {         $this->crud->setValidation(StoreRequest::class);     }
I think the function name will come setupStoreOperation . What about this?

Sorry @senthu1994 , I don't understand. Could you please rephrase?

@tabacitu i updated my question. Thanks.

Yes, you should setup the validators inside create and update operations.
Create operation is both responsible for setting up the form and validating on submission.
Going to close this. It's not an issue. If I am wrong please re-open, sometimes I am :)
Best,

Yes, you should setup the validators inside create and update operations.
Create operation is both responsible for setting up the form and validating on submission.
Going to close this. It's not an issue. If I am wrong please re-open, sometimes I am :)
Best,

@pxpm Thanks I got it.


allow scenario tags to be accessed by velocity template

Allow access of scenario tags from the velocity template, this would allow us to write custom velocity template based on the cucumber scenario/feature tags, for example the @ui tag could generate a runner that extends a class with webdriver setup functionality while a scenario without the @ui tag would generate a normal runner
eg frameworkium-runner.txt

This should already be possible. Have a look at: https://github.com/temyers/cucumber-jvm-parallel-plugin/issues/112


Add generated files to sdist

Generated files were not being added to the sdist.
This is useful for pandas, since we run a versioneer script to generate the sdist.
I think scipy avoids this, since they don't add generate a version file for their sdist?
I'll add a test, sometime in the future, but I'm a little busy now, so feel free to push to this branch in the meantime.

cc @rgommers @FFY00

Thanks @lithomas1. I don't think this specific change is a good idea - it's going to pull in all sorts of files that were not intended to be included. I think what you want instead to include specific files that are not under version control (like version.py generated by versioneer) is either meson.add_dist_script() or the if fs.exists... code from https://github.com/FFY00/meson-python/issues/159#issuecomment-1265962676.

I think scipy avoids this, since they don't add generate a version file for their sdist?

We had a similar version-related file with the git hash, but got rid of it when moving to Meson. We may want to bring it back, but it hasn't been a priority so far.

I'm a little confused. I'm pretty sure the only way to get generated files into the sdist is by adding them with meson.add_dist_script()(which I'm using with pandas), so there wouldn't be any unwanted generated files.
One thing that meson-python might consider doing, is parsing a MANIFEST file like setuptools. The .targ.z meson generates includes a bunch of extra things, and its probably much easier to do this filtering in meson.

it's going to pull in all sorts of files that were not intended to be included

Ralf, can you elaborate on that? AFAICT it will only pull files that are present in the Meson dist but not on the git checkout.

it's going to pull in all sorts of files that were not intended to be included

Ralf, can you elaborate on that? AFAICT it will only pull files that are present in the Meson dist but not on the git checkout.

I think I misunderstood what's going on here. A quick try with a breakpoint under path.is_file() showed files that we didn't want to include on SciPy, and the PR title/description seemed to say "all generated files". I did some more testing with the actual change in this PR, and it seems fine indeed.

Cool, I'll add tests in the future then.

I pushed a small refactoring to make the code a bit easier to maintain, I hope you don't mind. Let me know if you want me to avoid that in the future.

I pushed a small refactoring to make the code a bit easier to maintain, I hope you don't mind. Let me know if you want me to avoid that in the future.

No worries. Thanks for fixing the pre-commit as well.
I'm going to be busy since midterms are rolling around again, so feel free to finish up anything I have open in case I don't circle back to it in time.

pre-commit.ci autofix

@rgommers @FFY00 This is as green as it gets.


Feature Request: Drop In Replacement for torch.nn.MultiheadAttention

It would super cool, if this could be a drop in replacement for torch.nn.MultiheadAttention, thus following the API torch uses so far.

Although this is a good idea, the drop-in module isn't implemented because models require more flexibility due to their mechanisms and structures. Instead efficient_dot_product_attention is intended to be used within those custom attention modules implementations.
You can simply modify the source code of MultiheadAttention or another attention module (such as from hugging face implementations) to incorporate this function. That, I believe, would provide more flexibility.
If you did this and liked to share it, please submit a pull request, and I'll gladly check and merge it.


Error in melonnpan-train - Data should be normalized to proportions...

Dear Dr. Mallick,
I am trying to follow the code for  Melonnpan-Train however I encounter different problems:

First problem was running the melonnpan train code in Studio v 1.2.5042, it seems that I was unable to set the parallel processing and I got the following error:
Error in makePSOCKcluster(names = spec, ...) :
Cluster setup failed. 4 of 4 workers failed to connect.

It seems that there is a bug in Rstudio with the package parallel so I decided to run it directly in the R Terminal, however I  encountered other problems that I did not observed in RStudio:

First problem was associated to my input data, when I used the commands to check proportionality I got the error below. This is weird because using the same input data in Rstudio didn't get this error, and seems my input accomplishes with normality.

Proportionality Check
if(any(metab<0)||any(metab>1)|| any(metag<0)||any(metag>1))
stop("All measurements should be normalized to proportions.")
   Error: All measurements should be normalized to proportions._

I have checked my metab and metag inputs several times, and rows sum 1 in metab input and around 0.99 in metag input as I filtered OTUs features with mena relative abundance  > 0.01% in at least 10 % of the samples as recommended in the paper.
I am also very confuse with the pipeline according to the code  in the following link [https://rdrr.io/github/biobakery/melonnpan/src/R/melonnpan_train.R]
I have uploaded a reduced example of my input files in order you can help me to find the answer to this issues.
Many thanks for your time and your help,
metab_input_ex.xlsx
metag_input_ex.xlsx

Hi @sandradiazsanchez - I changed the example input files you sent to .csv format and it worked on my end using the following code chunk (I am using R 3.6.3):

#############
# Libraries #
#############

library(tidyverse)
library(data.table)
library(melonnpan)

##############
# Input Data #
##############

metab<-fread('metab_input_ex.csv')
metag<-fread('metag_input_ex.csv')
metab<-column_to_rownames(metab, 'ID')
metag<-column_to_rownames(metag, 'ID')

#######
# Run #
#######

melonnpan.train(metab, metag)

Does the above trick resolve the issue on your end as well?

Dear Himel,
Thanks for your quick response, I really appreciate your help, I am pretty
new with this kind of analysis,  I've just tried to run your code with the
same example data I attached before but I got the following error:

metab <- fread
("/Users/sandradiaz/Desktop/Melonnpan/input/metab_input_ex.csv")

metab<-column_to_rownames(metab, 'ID')

metag <- fread
("/Users/sandradiaz/Desktop/Melonnpan/input/metag_input_ex.csv")

metag<-column_to_rownames(metag, 'ID')

melonnpan.train(metab, metag)

Job started at: Mon Feb  8 19:00:22 2021
Training a MelonnPan model...
Predicting metabolite compositions using MelonnPan...
Fitting an elastic net regularized linear model...
Finding the best combination of alpha and lambda...
k-fold CV: 10
Job finished at: Mon Feb  8 19:00:33 2021
Computational time: 0.187 minutes
Error in file(file, ifelse(append, "a", "w")) :
no se puede abrir la conexión
Además: Warning messages:
1: In cor(rank(x), rank(y)) : the standard deviation is zero
2: In cor(as.numeric(as.vector(pred[, i])), as.numeric(as.vector(metab[,  :
the standard deviation is zero
3: In cor(rank(x), rank(y)) : the standard deviation is zero
4: In cor(as.numeric(as.vector(pred[, i])), as.numeric(as.vector(metab[,  :
the standard deviation is zero
5: In cor(rank(x), rank(y)) : the standard deviation is zero
6: In cor(as.numeric(as.vector(pred[, i])), as.numeric(as.vector(metab[,  :
the standard deviation is zero
7: In file(file, ifelse(append, "a", "w")) :
no fue posible abrir el archivo
'/Users/sandradiazMelonnPan_Training_Summary.txt': Permission denied
As well I tried to use my complete input data set (in previous e-mail I
attached only a example with few columns in order to make it more
manageable), with the same code and I got error as well as showed below:

metab <- fread
("/Users/sandradiaz/Desktop/Melonnpan/input/metab_input.csv")

metag <- fread
("/Users/sandradiaz/Desktop/Melonnpan/input/metag_input.csv")

metab<-column_to_rownames(metab, 'ID')

metag<-column_to_rownames(metag, 'ID')

melonnpan.train(metab, metag)

Error in melonnpan.train(metab, metag) :
Both training datasets should have the same rownames.
I have attached the original files so it can be helpful.
Many Thanks again,
Sandra
El lun, 8 feb 2021 a las 18:33, Himel Mallick<EMAIL_ADDRESS>escribió:

Hi @sandradiazsanchez https://github.com/sandradiazsanchez - I changed
the example input files you sent to .csv format and it worked on my end
using the following code chunk (I am using R 3.6.3):
############## Libraries ##############
library(tidyverse)
library(data.table)
library(melonnpan)
############### Input Data ###############
metab<-fread('metab_input_ex.csv')metag<-fread('metag_input_ex.csv')metab<-column_to_rownames(metab, 'ID')metag<-column_to_rownames(metag, 'ID')
######## Run ########
melonnpan.train(metab, metag)
Does the above trick resolve the issue on your end as well?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/biobakery/melonnpan/issues/23#issuecomment-775315465,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYCZ643ZU2EON7FBY7E5Y3S6AOANANCNFSM4XIY6CWA
.

--
Sandra Díaz Sánchez
Postdoctoral Research Assistant
IREC-SaBiO
Department of Animal Health
Ronda de Toledo  s/n, 13005
Ciudad Real, Spain

Hi @sandradiazsanchez - looks like you need to specify the outputDirectory with a forward slash to get the output. The following ran without an error in my computer (no need to separate out the ID variable as mentioned previously):
melonnpan::melonnpan.train(metab = "/Home/metab_input_ex.csv", metag = "/Home/metag_input_ex.csv", outputDirectory = "/Home/")

The output files from the example run above are attached. Let me know if it works on your end after explicitly naming the output directory.
MelonnPan_Trained_Metabolites.txt
MelonnPan_Trained_Weights.txt
MelonnPan_Training_Summary.txt

Dear Himel,
Thanks again for your help and your quick response, I was able to run the
script with your help and the complete data input. However, after a couple
of hours runnings it gave me the following error:

melonnpan::melonnpan.train(metab =
"/Users/sandradiaz/Desktop/Melonnpan/input/metab_input.csv", metag =
"/Users/sandradiaz/Desktop/Melonnpan/input/metag_input2.csv",
outputDirectory = "/Users/sandradiaz/Desktop/Melonnpan/")
Job started at: Tue Feb  9 10:45:59 2021

Training a MelonnPan model...
Predicting metabolite compositions using MelonnPan...
Fitting an elastic net regularized linear model...
Finding the best combination of alpha and lambda...
k-fold CV: 10Error in { :
task 63 failed - "task 9 failed - "y is constant; gaussian glmnet fails
at standardization step""
Además: There were 12 warnings (use warnings() to see them)

warnings()
Warning messages:
1: cerrando la conenexion 15 (<-localhost:11557) que no esta siendo
utilizada
2: cerrando la conenexion 14 (<-localhost:11557) que no esta siendo
utilizada
3: cerrando la conenexion 13 (<-localhost:11557) que no esta siendo
utilizada
4: cerrando la conenexion 12 (<-localhost:11557) que no esta siendo
utilizada
5: cerrando la conenexion 11 (<-localhost:11557) que no esta siendo
utilizada
6: cerrando la conenexion 10 (<-localhost:11557) que no esta siendo
utilizada
7: cerrando la conenexion 9 (<-localhost:11557) que no esta siendo
utilizada
8: cerrando la conenexion 8 (<-localhost:11557) que no esta siendo
utilizada
9: cerrando la conenexion 7 (<-localhost:11557) que no esta siendo
utilizada
10: cerrando la conenexion 6 (<-localhost:11557) que no esta siendo
utilizada
11: cerrando la conenexion 5 (<-localhost:11557) que no esta siendo
utilizada
12: cerrando la conenexion 4 (<-localhost:11557) que no esta siendo
utilizada

I am sorry for all the inconvenience, I do not know if something with my
input data...
Thanks again,
Sandra
El lun, 8 feb 2021 a las 20:20, Himel Mallick<EMAIL_ADDRESS>escribió:

Hi @sandradiazsanchez https://github.com/sandradiazsanchez - looks like
you need to specify the outputDirectory with a forward slash to get the
output. The following ran without an error in my computer (no need to
separate out the ID variable as mentioned previously):
melonnpan::melonnpan.train(metab = "/Home/metab_input_ex.csv", metag = "/Home/metag_input_ex.csv", outputDirectory = "/Home/")
The output files from the example run above are attached. Let me know if
it works on your end after explicitly naming the output directory.
MelonnPan_Trained_Metabolites.txt
https://github.com/biobakery/melonnpan/files/5946244/MelonnPan_Trained_Metabolites.txt
MelonnPan_Trained_Weights.txt
https://github.com/biobakery/melonnpan/files/5946245/MelonnPan_Trained_Weights.txt
MelonnPan_Training_Summary.txt
https://github.com/biobakery/melonnpan/files/5946246/MelonnPan_Training_Summary.txt
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/biobakery/melonnpan/issues/23#issuecomment-775381544,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYCZ65KF3BZPD6KPN2ZZ4LS6A2PFANCNFSM4XIY6CWA
.

--
Sandra Díaz Sánchez
Postdoctoral Research Assistant
IREC-SaBiO
Department of Animal Health
Ronda de Toledo  s/n, 13005
Ciudad Real, Spain

Hi @sandradiazsanchez - this has been addressed previously. You need to make sure all the metabolites have a sufficient number of unique values (e.g. more than 10 or so). Likewise, metabolites with only a few unique values need to be removed beforehand.

Hi Himmel,
It worked! Many thanks for your help.
Sandra
El mar, 9 feb 2021 a las 14:05, Himel Mallick<EMAIL_ADDRESS>escribió:

Hi @sandradiazsanchez https://github.com/sandradiazsanchez - this has
been addressed previously
https://github.com/biobakery/melonnpan/issues/20. You need to make sure
all the metabolites have a sufficient number of unique values (e.g. more
than 10 or so). Likewise, metabolites with only a few unique values need to
be removed beforehand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/biobakery/melonnpan/issues/23#issuecomment-775920836,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYCZ62XCIRPALPVX3KMVEDS6EXHXANCNFSM4XIY6CWA
.

--
Sandra Díaz Sánchez
Postdoctoral Research Assistant
IREC-SaBiO
Department of Animal Health
Ronda de Toledo  s/n, 13005
Ciudad Real, Spain


Service principal to use AWS::URLSuffix to work in all regions

Proposed Changes
AWS Service principals "domains" should use AWS::URLSuffix for easy portability to different regions.

This translation is hard coded for China at https://github.com/aws-ia/cfn-ecr-aws-soci-index-builder/blob/main/functions/source/soci-index-generator-lambda/handler.go#L179-L186 which may deserve a better implementation as well.

Does that mean no need for this, can close? Not that I'd need to use it nor that I have seen it supported, but wouldn't that work for us-gov regions too?
Happy either way :)

No, I didn't mean to say this is not needed. This is a good PR. My observation was about another location that is currently more functional than what you're fixing, but is less functional than your fixed version, so it might need an update as well.

I don't think this change is needed. We have successfully tested this stack in both GovCloud and China. The lambda/events service principals do not need the URL suffix.

Closing This PR


Firstpaint

Getting closer! When writing tests, the only time you should have an if statement with an expect statement inside of it is if you also have a corresponding else statement that also has an expect statement, and that typically only happnens if you're creating a function to return a property that you want to mock out, as we do in the #performanceTiming test.
So in this case, SNPProto.chromeLoadTimes() should return window.chrome.loadTimes() if it exists, and undefined if it does not. The test for #chromeLoadTimes should have an if & else, each with an expect statement that returns that value. Then, in your 3 Browser built-in Time to First Paint tests, you can mock chromeLoadTimes to return either the object you want or undefined using spies:
// for the 'when the client is using Chrome' test:
spyOn(SurfNPerf, 'chromeLoadTimes').andReturn({firstPaintTime:<PHONE_NUMBER>.123456});
// for the other tests:
spyOn(SurfNPerf, 'chromeLoadTimes').andReturn(undefined);

SNPProto.msFirstPaint() would be similar. If window.performance.timing.msFirstPaint exists, return it, else return undefined. Do the same if & else, each with an expect statement in the test, and then mock msFirstPaint in the other tests to either return the value you want or undefined.
Also make sure that your it statements describe what the code should actually be doing ;-)

@rosmaryg address the latest inline comments and we should be all set!


AttributeError: module 'hydrogym.firedrake' has no attribute 'IPCS'

What solver should I use, since latest code does not include IPCS yet all the examples do?
Traceback (most recent call last):
File "/IdeaProjects/hydrogym/examples/ppo/cyl.py", line 53, in
ppo.ppo(
File "/IdeaProjects/hydrogym/examples/ppo/ppo.py", line 361, in ppo
env = env_fn()
File "/IdeaProjects/hydrogym/examples/ppo/cyl.py", line 54, in
lambda: gym.make("Cylinder-v0", env_config=env_config),
File "/home/firedrake/firedrake/lib/python3.10/site-packages/gym/envs/registration.py", line 640, in make
env = env_creator(**_kwargs)
File "/IdeaProjects/hydrogym/examples/ppo/cyl.py", line 17, in init
"solver": hydrogym.firedrake.IPCS,
AttributeError: module 'hydrogym.firedrake' has no attribute 'IPCS'

@dmitryshribak The examples are, unfortunately, outdated. You should use the semi-implicit solver from https://github.com/dynamicslab/hydrogym/blob/main/hydrogym/firedrake/solvers/bdf_ext.py

We are currently fixing issues with the main core HydroGym code + its flow environments, and will then rewrite the examples (+notebooks).
I'm afraid it'll probably take +/- 1 month though..


Replace Brian A. Benjamin with Cordell Cleare (NY-30)

Brian A. Benjamin became Lt. Gov on September 9, 2021. He then resigned as Lt. Gov on April 12, 2022.

Thank you for doing this! Just requesting that you add the end date to Brian's role in his file, can check other retired legislature files to see what I mean.

@NewAgeAirbender All set, can you re-review?


feat(tests/): Added simple test cases for custom user model

updated requirements
deleted unrequired files from accounts app.

solves #5

Looking good so far, nice work @aniketmaithani !
Can you separate the test requirements into a dev-requirements.txt so to keep the dependencies separated as to what is necessary and what is only required for running tests.
Also, a quick writeup on how to run these tests in the README would be great, too :)
:beers:

@jonathanchu  on it. Updating the PR

Awesome, thank you so much! :+1:


Avoid unpad/pad repeated calls when use_cache=False

As per title. The difference is quite large. This is only done out of curiosity, cc @younesbelkada
Note: Speedup over the base PR is expected only in case of batch_size > 1 when padding / masked tokens are used. In the benchmark below, we use a padding percentage of 30%.
This is on a single A100 for meta-llama/Llama-2-7b-hf.
Forward only with no_grad mode
batch_size=4, len=1000

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

395
321
237
1.228
1.665

batch_size=4, len=2000

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

OOM
627
475
/
/

batch_size=8, len=500

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

357
318
231
1.120
1.545

batch_size=2, len=4000

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

OOM
327
262
/
/

forward + backward
batch_size=4, len=1500

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

OOM
1353
1062
/
/

batch_size=2, len=3000

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

OOM
1422
1178
/
/

batch_size=2, len=1000

Transformers latency (ms)
Younes PR latency (ms)
This PoC latency (ms)
Younes speedup / transformers
This PoC speedup / transformers

580
506
423
1.146
1.370

Benchmark script out of completeness: https://pastebin.com/zWE9Aedr

This is a draft by the way, I just wanted to get results. I'm not sure if it is very fit for transformers though, with the modifications directly in the LlamaModel forward?
generate with use_cache=True can unfortunately not use this path, because the KV cache implementation in transformers makes the size of keys and values have a dynamic shape in the attention, where basically the cumulative sequence length, max sequence length always change, with length different than the hidden_states that is e.g. simply 1 in a decoding phase.


Compatibility pass on flutter/painting tests for JavaScript compilation. (3)

Description
Flags certain test cases in foundation using package:test tags in order to facilitate landing support for running all framework tests in a browser
Requires https://github.com/flutter/flutter/pull/33349

Updated with feedback, to run on CI, and to add more failing tests to skip :(


Improved Anchor Block Tuning

cc: @tqchen @MasterJH5574 @spectrometerHBH

The old anchor trace apply assumes that the prefix of the "new" outputs matches with the "old" outputs, which is not the case for some tasks in stable diffusion. In this PR, I maintain a block mapping between the old IRmodule and the new IRmodule, so that we can find the matching parts in both IRmodule with no assumptions of the relationship of their locations in IRModule.

One minor but important thing: would always be great to have decent PR description on what this PR is about and how this PR can make difference. So that everyone can quickly get the context.


The text of social buttons are not visible clearly

Describe the bug
Expected behavior of what should have happened (if applicable)
Screenshots (if applicable)
Additional notes

I think changing the font family will help here...... which font family should I add here

@dsnehasish74 i didn't found any such problem in the page ..i guess the page might not loaded properly

the lower portion of g is getting cut. Is not it  ???? or it is the font style???????????

the lower portion of g is getting cut. Is not it ???? or it is the font style???????????

This is due to the font


TaskManager TaskUpdateEvent correlationId incorrect

Description
The correlationId on the TaskUpdateEvent is not correct after consuming a TaskDispatchEvent.
Steps to reproduce

Switch to branch task-manager-int-tests
Uncomment line 48 in Assertions.cs
Run integration test "Task Update event is published by the Task Manager after receiving a clincial review Task Dispatch event"

Expected behavior

TaskUpdateEvent inherits correlationId from TaskDispatchEvent

Actual behavior

TaskUpdateEvent creates new guid correlationId

Issue still exists

This was a non issue, the int framework was generating a new correlationId in the header so when comparing the TaskDispatchEvent to the TaskCallbackEvent they were different. Framework was updated to use the correlationId from the TaskDispatchEvent body as the correlationId in the header which fixed this issue


Check connectionState in stopso we don't null ref

Issue: https://github.com/aspnet/SignalR/issues/3303
When there is a failure to fully connect the connectionState variable doesn't get set and so when we try to clean up the outstanding invocations in the stopConnection logic we don't check if connectionState was initialized.
There's no test here because the exception is just logged.

When there is a failure to fully connect the connectionState variable doesn't get set and so when we try to clean up the outstanding invocations in the stopConnection logic we don't check if connectionState was initialized.

That the situation completes without an exception seems like it is worth testing to avoid future regressions.

Good point. We currently don't have the testing support to test this properly in a timely manner though and I don't want to get caught up on this since it's essentially just a defensive change that happens after a connection has already entered the stop flow.


zha & conbee - cannot join devices

Home Assistant release with the issue:
0.86.4
Last working Home Assistant release (if known):
N/A
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Component/platform:
zha
Description of problem:
I set up zha using Integrations menu, but now i cannot join any devices.
Tried with Ikea Tradri and Osram Lightify. All devices were working before with Deconz Hassio addon and were reset since then
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
Zha set up through Integrations, so no relevant yaml configuration
Traceback (if applicable):
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:01:59 WARNING (MainThread) [zigpy_deconz.zigbee.application] Error while sending frame: 0xe9
2019-02-02 15:02:00 WARNING (MainThread) [zigpy_deconz.zigbee.application] Error while sending frame: 0xe9
2019-02-02 15:02:08 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0x5484, 7c:b0:3e:aa:00:aa:cb:c1
2019-02-02 15:02:08 INFO (MainThread) [zigpy.application] Device 0x5484 (7c:b0:3e:aa:00:aa:cb:c1) joined the network
2019-02-02 15:02:08 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:08 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0x3e2b, 7c:b0:3e:aa:00:aa:54:c1
2019-02-02 15:02:08 INFO (MainThread) [zigpy.application] Device 0x3e2b (7c:b0:3e:aa:00:aa:54:c1) joined the network
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:09 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
    r = await func()
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 110, in request
    return await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
2019-02-02 15:02:10 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
    r = await func()
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 110, in request
    return await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
    r = await func()
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 110, in request
    return await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
2019-02-02 15:02:15 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0x49ab, 7c:b0:3e:aa:00:aa:48:27
2019-02-02 15:02:15 INFO (MainThread) [zigpy.application] Device 0x49ab (7c:b0:3e:aa:00:aa:48:27) joined the network
2019-02-02 15:02:15 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:15 INFO (MainThread) [zigpy.device] [0x49ab] Discovering endpoints
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:27 WARNING (MainThread) [zigpy_deconz.zigbee.application] Error while sending frame: 0xe9
2019-02-02 15:02:33 INFO (MainThread) [homeassistant.components.zha.api] Permitting joins for 60s
2019-02-02 15:02:35 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0x3e2b, 7c:b0:3e:aa:00:aa:54:c1
2019-02-02 15:02:35 INFO (MainThread) [zigpy.application] Device 0x3e2b (7c:b0:3e:aa:00:aa:54:c1) joined the network
2019-02-02 15:02:35 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:35 INFO (MainThread) [zigpy.device] [0x3e2b] Discovering endpoints
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:38 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0xda3c, 7c:b0:3e:aa:00:aa:48:27
2019-02-02 15:02:38 INFO (MainThread) [zigpy.application] Device 0xda3c (7c:b0:3e:aa:00:aa:48:27) joined the network
2019-02-02 15:02:38 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:38 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 58, in retry
    await asyncio.sleep(delay)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 482, in sleep
    return (yield from future)
concurrent.futures._base.CancelledError
2019-02-02 15:02:38 INFO (MainThread) [zigpy.device] [0xda3c] Discovering endpoints
2019-02-02 15:02:39 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:41 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:41 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0x642e, 7c:b0:3e:aa:00:aa:cb:c1
2019-02-02 15:02:41 INFO (MainThread) [zigpy.application] Device 0x642e (7c:b0:3e:aa:00:aa:cb:c1) joined the network
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:41 INFO (MainThread) [zigpy.device] [0x642e] Discovering endpoints
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:45 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:47 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:51 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:53 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:02:59 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:03:03 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:03:06 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fc7ed8e9dd8>, Serial<id=0x7fc7ed843470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:03:09 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
    r = await func()
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 110, in request
    return await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
2019-02-02 15:03:13 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
    r = await func()
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 110, in request
    return await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
2019-02-02 15:03:15 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
    epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
  File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
    r = await func()
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 110, in request
    return await asyncio.wait_for(reply_fut, timeout)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

Also getting this on HA start:
2019-02-02 15:51:54 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fd38e7beeb8>, Serial<id=0x7fd38e7954a8, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:51:55 ERROR (MainThread) [homeassistant.components.openuv] Config entry failed: Invalid API key
2019-02-02 15:51:55 WARNING (MainThread) [homeassistant.config_entries] Config entry for openuv not ready yet. Retrying in 80 seconds.
2019-02-02 15:51:55 ERROR (MainThread) [homeassistant.components.openuv] Config entry failed: Error requesting data from protection: 500, message='Internal Server Error'
2019-02-02 15:51:57 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fd38e7beeb8>, Serial<id=0x7fd38e7954a8, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3
2019-02-02 15:52:00 INFO (MainThread) [homeassistant.components.automation] Executing ebusd_mqtt_update
2019-02-02 15:52:00 INFO (MainThread) [homeassistant.helpers.script] Script ebusd_mqtt_update: Running script
2019-02-02 15:52:00 INFO (MainThread) [homeassistant.helpers.script] Script ebusd_mqtt_update: Executing step call service
2019-02-02 15:52:00 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_deconz.uart.Gateway object at 0x7fd38e7beeb8>, Serial<id=0x7fd38e7954a8, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
  File "uvloop/cbhandles.pyx", line 62, in uvloop.loop.Handle._run
  File "/usr/local/lib/python3.6/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/uart.py", line 63, in data_received
    self._api.data_received(frame)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 159, in data_received
    getattr(self, '_handle_%s' % (command, ))(data)
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/api.py", line 235, in _handle_aps_data_indication
    data[16])   # rssi
  File "/usr/local/lib/python3.6/site-packages/zigpy_deconz/zigbee/application.py", line 130, in handle_rx
    raise Exception("Unsupported address mode in handle_rx: %s" % (src_addr.address_mode))
Exception: Unsupported address mode in handle_rx: 3

closing as linked issue is resolved.


Android Keystore System use on encryption key storage

Currently, app uses NFC token to decrypt PGP keyphrase.
To support fingerprint API, app must store encryption/decryption key in Android Keystore System.
Due to the nature of encryption system, this method will work independently from NFC auth.

Delayed until API v10 upgrade - #10

Too busy ATM, will close for now and reopen when there are enough requests.


ng test --watch has undesired behavior

This is a design fault. Currently, --watch=false and --single-run is exactly duplicate.
When --watch=false is specified, it sets singleRun. This is not passed to Karma, since it's named autoWatch.
When singleRun is set, Karma will automatically override the autoWatch variable. This makes both the options same.
Summary: there's two things to resolve.

singleRun and watch flips the same switch.
watch should be autoWatch or it doesn't make sense at all.

Correcting this would probably alter the interface, making it a breaking change.
Proposed solutions:

Remove --single-run. Alter the code so it changes the property name of "watch" to "autoWatch".
Remove --watch. This is the most simple way (in change amount).

The concerns about the --watch name:
ng build uses it with both meaning of "single run" and "watch".
ng serve uses it for only the meaning of "watch".
Different meaning of the option can lead to confusion.

The two options in question are essentially aliases of each other (more like inverted aliases).  The options themselves may be confusing from a karma perspective but there is no design defect.  They work as intended (E2E tests cover their usage).   In addition, the use of the watch nomenclature aligns with the other CLI commands.
As to the potential confusion regarding watch within build and serve.  The operation of the option is consistent across the commands.  watch controls whether the source files are monitored for changes.  The difference between the commands is the intrinsic nature of the commands themselves (i.e., the act of serving is a long-lived process; whereas building is not).
With regards to the karma autoWatch setting, for completeness the argument could be made that enabling the watch option should ensure that the autoWatch settings is enabled as well.
Also please note that changing the public surface of the CLI is a breaking change; as such a major version bump would be required.

Since they're mutually exclusive and does the same thing, what's the point of having two? The one-line argument description is not so helpful to user, and I was totally confused by that until I dig into it.
I'm aware that this is breaking change; I have noted in the issue body and restructuring the interface is quite important for this case.
I mentioned the two existing usecase because test is also somewhat different: watch is on by default, but the behavior is more similar to build which is single run by default.

I think @clydin covered most of your points. I'd like to clarify why it ended up like this though.
Initially we only had --watch and that only worked in build/serve/test ( e2e didn't have that option at the time). To make more consistent with karma usage, and to allow a shorter alias (--no-watch/--w=false versus --sr) we introduced the --single-run option for ng test.
We didn't want to break existing apps so we left both in.
Removing it now would be a breaking change, which needs a major version. However, 2.0 is still in the design process so we're not accepting PRs for it.
Your PR (#5892) subtly changes the logic and defaults for no clear benefit. Usually changing the defaults would be a major version, but you seem to be trying to keep the behavior, so I don't think is worth it to change.
If you want to simply change the documentation to reflect that those two flags do the same, I'm happy to re-review your PR.

As I wrote, the PR is now targeting another fix.
The code is just working by luckily chaining one implication in cli with the other in Karma. It's definitely not intended to be so. (The author tried to add "watch" parameter, but it must be "autoWatch" if it need to be directly passed to Karma)

Please note that autoWatch is purposefully set to true in the karma configuration and as mentioned watch controls singleRun; thereby allowing the watch option to function as intended.
Also, allowing watch to control the value of karma's autoWatch option does not necessitate the renaming of watch.  However, you could argue that making watch also control autoWatch is indeed a valid fix.

Fixed via #5892

Not fixed, please reopen.

@ishitatsuyuki can you elaborate? I thought #5892 was addressing these concerns. What other changes do you think are necessary?

@filipesilva the PR was originally trying to address the design problems but I removed them due to being too breaking. Instead, I made an issue for discussion here.
The PR is shrinked down to only fix the default value not honored. The rest, about command interface, should be discussed here. The removal is probably breaking, so I have no idea what version it would land.

Atm we're not allowing breaking changes in 1.x, but will allow them in 2.x. At that time we'll remove this confusing behaviour since the only reason it's still around is for legacy purposes.

Can you reopen this then?

Right, sorry!


Rely: Compiler error when running example

The rely docs suggest you should structure your tests like this:
open TestFramework;

describe("my first test suite", ({test}) => {
  test("1 + 1 should equal 2", ({expect}) => {
    expect.int(1 + 1).toBe(2);
  });
});

However, this actually produces a warning (which is an error with default dune settings):
Error (warning 9): the following labels are not bound in this record pattern:
describe
Either bind these labels explicitly or add '; _' to the pattern.

The compiler wants this to be:
+    describe("my first test suite", ({describe, test}) => {

instead of:
-    describe("my first test suite", ({test}) => {

In my opinion - it feels a bit clunky to have to pass these values in (compared to the JS Jest API). It would be awesome if describe, test, and expect were all available from the TestFramework module.
Otherwise, it'd be worth updating the docs so that first-time users don't hit this error.

Interesting, I have not ever seen this warning and I don't think we ignore warning 9 anywhere explicitly. Not sure why this might be happening, we can investigate.
I actually prefer injecting test via the record to Jest's API. It makes the framework much cleaner to implement, fewer "magic" globals, and it avoids ordering issues. What should we do if you call describe within test or expect at the top level?

Warning 9 is ignored by default by ocamlc as far as I can tell. Per https://caml.inria.fr/pub/docs/manual-ocaml/comp.html, the default setting is -w +a-4-6-7-9-27-29-32..42-44-45-48-50-60
My guess is that the Dune dev profile is stricter than this by default and we have largely been developing with the release profile which is less strict.

Yes, dune's warnings are stricter than default ocaml's ones.
I found Warning 9 very useful with records to make sure compiler catches cases where I need to handle all fields of the record (a common case with product types) when I'm adding a new field to a record. For cases where I don't need to handle all fields I just don't do destructuring then. Therefore I think the following API would work:
describe("my first test suite", define => {
  define.test("1 + 1 should equal 2", test => {
    test.expect.int(1 + 1).toBe(2);
  });
});

(copying my comment from elsewhere)
I don't like the change of having to be explicit with all fields in a record. I can understand the point of warning 9, and why it might be helpful in some cases, but this is explicitly not one of those cases. We don't really care about making sure each field in the record is listed and designed the API in that way on purpose.
Are there examples of this being an important thing that catches bugs? I can understand theoretically how it might come up, but it never seems relevant in practice.
I wonder what some alternatives might be.

Hey, sorry for the slow reply here!
I should've put this originally, but here's an example branch where I have this problem.
https://github.com/bryphe/merlin-language-server/tree/bryphe/repro/reason-native-38
Note that I do not explicitly set warning 9. As @andreypopp mentioned, dune's default warnings are stricter. I can workaround this by setting (flags (:standard (-w -9))) in the dune file.
I don't have a strong opinion about the warning, I just expected rely to build with this vanilla config. If we're OK with the behavior / API as is, suppressing this warning should be added to the dune config example. If it's desired for rely to work w/o changing the warning profile of dune, then @andreypopp 's suggestion sounds reasonable.
Regarding the global API:

It makes the framework much cleaner to implement
This makes sense, but IMO it should be the very last consideration - the developer experience when using the library should be more important than what the framework has to do under the hood.

fewer "magic" globals
Can totally understand the rationale for this 😄

and it avoids ordering issues.
Hmm, what ordering issues? Is jest impacted by this too?

What should we do if you call describe within test or expect at the top level?
I believe jest would have solved these problems - what does it do in these cases? Throwing an exception seems reasonable to me.

My personal preference would still be for the global API... but I understand where you're coming from too!

Yeah, we want this to work well "out of the box" without having to do custom setup in dune files. Perhaps our recommendation will be to do whichever of these the user prefers:

Use {field, _} syntax for records
Or ignore warning 9

It would be nice if we could use some sort of annotation on the record types to ignore warning 9 explicitly for everyone, since it is not relevant for these records.

(this is getting a little off-topic from original issue, if you want to keep discussing I'm happy to do so though, perhaps in another issue)

very last consideration

Yeah, definitely far less important than the dev experience. I do think it is still an important consideration. If something can't be implemented cleanly and becomes full of hacks to satisfy a particular API it can cause the framework to be hard to maintain and hard to adapt. That indirectly affects the dev experience.

what ordering issues

This is referring to the next sentence 😄 sorry I was not clear.

Throwing an exception seems reasonable to me

It is a solution, but I think it's a much worse experience. We don't want to do exactly what Jest does if we can do better. We want to catch or prevent issues at compile time rather than defer them to runtime (just like with static type checking). In the current setup it is harder to call things out of order, you would have to intentionally break it by storing the provided functions in mutable state out of the current scope.
As we start expanding the capabilities of Rely, everything being a global will become a mess. These are some of the functions that we could add:

https://jestjs.io/docs/en/api
https://jestjs.io/docs/en/jest-object

A little bikeshedding, I like that ava makes static type inferences easier
import test from 'ava';

test('foo', t => {
	t.pass();
});

test('bar', async t => {
	const bar = Promise.resolve('bar');
	t.is(await bar, 'bar');
});

The syntax that @thangngoc89 and @andreypopp is in fact available with the current API (mod the ava specific utilities). The below works out of the box with Rely.
open TestFramework;

describe("my test suite", d => {
  d.test("my test", t => {
    t.expect.int(1 + 1).toBe(2);
  });
});

How do people feel about updating the docs accordingly?
@bryphe @kyldvs
I agree with not liking the magic globals and the assertion that UX should trump implementation details, Jest's behavior with improper nesting of describe/test isn't great if I recall correctly. In the past I have had issues with various CI reporters not liking tests that weren't inside describes.

I think we should continue to use destructuring syntax in the docs, and have the official recommendation to be ignoring warning 9. Then we can mention two alternatives, {expect, _} or t.expect syntaxes.

Thanks all for your thoughts on this!

think we should continue to use destructuring syntax in the docs, and have the official recommendation to be ignoring warning 9. Then we can mention two alternatives, {expect, _} or t.expect syntaxes.

Sounds reasonable to me. There's already a prescribed dune config (ie, including the -linkall and -g flags), so not a big deal to suppress the warning there too.


session 002 (11/20/2021)

Session2:  Take-home Hospital Showup

Date: 11/20/2021 13:00 PST   Skype: https://join.skype.com/WzRQJuTDFrMe
host: @stanghong
facilitator:  @john
Please follow this link to review the notebook and provide your feedback

https://app.reviewnb.com/suredream/hack-your-ds-interview/blob/main/notebook%2FMedNoShow_Improve_Cycle4-FinalUpdate.ipynb

Note: a take-home example from a health insurance company which requires to complete within 48 hours
5 min summary deck

需要与 zhang 确定的内容：

notebook 的主要内容
文档模板
checklist

@John-Cai-ds

add discussion to reviewnb as comments
add bulletin points and comment link to wiki home (https://github.com/suredream/hack-your-ds-interview/wiki)
@stanghong
add session 1 note to wiki home (https://github.com/suredream/hack-your-ds-interview/wiki)


Shouldn't the installation fail if the GnuPG key cannot be verified?

I just installed Terraform using ASDF. This is the result in the terminal:
[x80486@uplink:~]$ asdf install terraform 1.3.7
Downloading terraform version 1.3.7 from https://releases.hashicorp.com/terraform/1.3.7/terraform_1.3.7_linux_amd64.zip
Verifying signatures and checksums
gpg: keybox '/tmp/asdf_terraform_m7UiU3/pubring.kbx' created
gpg: /tmp/asdf_terraform_m7UiU3/trustdb.gpg: trustdb created
gpg: key 34365D9472D7468F: public key "HashiCorp Security (hashicorp.com/security<EMAIL_ADDRESS>imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Signature made Wed 04 Jan 2023 10:27:45 AM EST
gpg:                using RSA key 374EC75B485913604A831CC7C820C6D5CD27AB87
gpg: Good signature from "HashiCorp Security (hashicorp.com/security<EMAIL_ADDRESS>[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C874 011F 0AB4 0511 0D02  1055 3436 5D94 72D7 468F
     Subkey fingerprint: 374E C75B 4859 1360 4A83  1CC7 C820 C6D5 CD27 AB87
terraform_1.3.7_linux_amd64.zip: OK
Cleaning terraform previous binaries
Creating terraform bin directory
Extracting terraform archive

I wonder if this should fail because the key couldn't be verified? Otherwise, what's the point on checking it...unless it's part of the Terraform's built-in install process.

It already passed.
If it failed, it will throw something like this:

The warning in the output is expected and doesn't indicate a problem. It occurs because there isn't a chain of trust between your personal PGP key (if you have one) and the AWS CLI PGP key. For more information, see Web of trust.


Unable to follow test examples in spring-cloud-stream 3.x

Hello,
I'm trying to follow the testing guide here: https://github.com/spring-cloud/spring-cloud-stream/blob/master/docs/src/main/asciidoc/spring-cloud-stream.adoc#testing
but I'm not sure how to pull in the required dependency to get classes like TestChannelBinderConfiguration; I'm using Gradle.
Are there plans to publish the "test jar" with these classes?

Hi, try this one:
testImplementation(group: 'org.springframework.cloud', name: 'spring-cloud-stream', classifier: 'test-binder')


CVE-2023-45288: deps: bump x/net and related

Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2.
xref: golang/go#65051

/hold
still evaluating the impact and the perf consequences

/hold cancel
we move ahead for main branch but we still on hold for the other branches

/cherry-pick release-4.15


Add learning rate finder

A learning rate finder can easily be implemented as shown in https://arxiv.org/abs/1506.01186

I you want to give suggestions of new functions, I think it's more appropriate to go to the repo keras-contrib, suggest it in the issues/mailing list and close the issue here. Make a pull request to keras-contrib if you want to speed up the process. Thank you.