Which versions of node should guerilla work with?

A recent PR used String.prototype.includes, an ES6 feature.
Running node 0.12  with --harmony adds String.prototype.contains, not the the standard's .includes.
Which node versions are supported / how guerilla is supposed to be run?

it works with 5.7.0 and 5.6.0 on my machine. but i don't know what exact versions it is supposed to be run.

We need a philosophy. I suggest that we try to stick to the latest stable release of Node, backing off when we have to.

I think we should try not to use new ES6 features whenever possible as many users of guerilla may be running older versions and/or may not be able to upgrade for various reasons.  In the case of String.prototype.includes, indexOf() works just as well.

A hard call. I would like to improve our productivity and code clarity, and recent enhancements like maps help out there.  I've been assuming (perhaps wrongly) that we would run on the latest and there may be some ES6 creep already!
On Wednesday, March 2, 2016 11:35 AM, Vinay Pulim<EMAIL_ADDRESS>wrote:

I think we should try not to use new ES6 features whenever possible as many users of guerilla may be running older versions and/or may not be able to upgrade for various reasons. In the case of String.prototype.includes, indexOf() works just as well.—
Reply to this email directly or view it on GitHub.

How about this? For now, guerilla should run on 0.12, w/o the harmony flag. That won't break any existing  uses, Map for instance. I can make the changes and cut a PR.
Then, to future proof, something like babel can be added, to allow es6 features to work with the engines currently in use.
Then, either aligned to the LTS schedule or whenever people decide, the engine version can cut over and babel can be removed.
/cc @thekushpatel

@seyeojumu: i like that plan

@seyeojumu agreed, solid plan. would be awesome if you could make those changes and make a note of that in the docs.

done #43 #44


Documentation: mention nixf-tidy in contributing guide

Problem
Since a while, GH actions runs nixf-tidy to detect useless rec and unused variables.
While I'm generally in favor of this, the output sometimes lacks detail, and it's desirable to run some of the checks locally, to prevent spamming PR reviewers (and CI).
However, nixf-tidy and its usage is very sparsely documented.
https://github.com/nix-community/nixd/pull/446 seems to have introduced it to nixd, yet there's neither a --help handler, nor documentation about the tool anywhere
Proposal
document nixf-tidy in both nixd repo, as well in the general nixpkgs contributing guideline and docs.
Checklist

[x] checked latest Nixpkgs manual (source) and latest NixOS manual (source)
[x] checked open documentation issues for possible duplicates
[x] checked open documentation pull requests for possible solutions

Add a :+1: reaction to issues you find important.

https://github.com/nix-community/nixd/tree/main/libnixf#standalone-tools-provided-along-libnixf

I'll write a wrapper around nixf-tidy

I'll write a wrapper around nixf-tidy

Thanks! Such a wrapper could be implementing https://github.com/numtide/treefmt/blob/main/docs/formatter-spec.md, rather than reading contents from stdin - which should make it compatible with treefmt.

I'll write a wrapper around nixf-tidy

Thanks! Such a wrapper could be implementing https://github.com/numtide/treefmt/blob/main/docs/formatter-spec.md, rather than reading contents from stdin - which should make it compatible with treefmt.

It is not a formatter but a linter, hmm, is it still benefitial to be compatible with treefmt in this case?

It is not a formatter but a linter, hmm, is it still benefitial to be compatible with treefmt in this case?

I was mostly refering to the part of having a CLI that allows you to specifiy a list of files to lint, rather than only accepting file contents from stdin. That's already make it much simpler to run locally IMHO.

That's already make it much simpler to run locally IMHO.

JSON output of nixf-tidy is a not human-readable format. When I wrote the first line of nixf-tidy, I just imaging it will be invoked by some automated scripts.

run locally

If the goal is to "reproduce the result" then the best approach is using the language server. It is the most straightforward way to reproduce fancy UI around the tooling and the people get instant feedback after fixing the issue.
Rendering texts / CLI / TUI on terminal mostly reinventing the wheel of editors (e.g. nvim).

I don't have the LSP setup, I got a complaint from the GH actions that a file isn't passing the linter.
It'd be very nice to reproduce it locally, similar to how the formatting check tells you to run a nixfmt $file on files failing the check.

I think making a tool a required CI check that you cannot easily run without deeply integrating it into your editor is a no-no. This either needs to get a better CLI frontend and more documentation in the nixpkgs manual, or should be removed and re-introduced once it has.

Hi @flokli,

I think making a tool a required CI check that you cannot easily run without deeply integrating it into your editor is a no-no.

Generally integrating linters is not a bad idea I think, but I agree that we should leave the freedom to make choices.

This either needs to get a better CLI frontend

I think @Aleksanaa is working on this :). Maybe contact us if you are also interested in?

and more documentation in the nixpkgs manual, or should be removed and re-introduced once it has.

The linter currently generates a readable UI in GitHub's 'Changed Files' view, allowing most users to update the failed branch without needing to reproduce the tooling locally. Therefore, I kindly suggest we keep it as-is, as it hasn't caused significant issues so far(?)

This either needs to get a better CLI frontend

I think @Aleksanaa is working on this :)

I agree with @flokli that we need a local CLI frontend (and some docs on how to run it). I'd rather not leave this in limbo, so unless we know this will be completed in the near future (like within a week or so, is this doable?), I'd be in favor of disabling the workflow until then. Note that it's very easy to disable/reenable workflows in the UI:
I merged the original addition of the workflow fairly quickly and as experimental, so we should also not hesitate to acknowledge some flaws, work them out first, and then try again :)

It's not that we'll gonna have a big risk getting a lot of garbage code. We still have human code review processes in place, we didn't have such a linter for a large part of nixpkgs lifetime, and it's always possible to lint (new) code manually. So yes, I'm in favor of disabling the check until it's more user-friendly (and don't see why we need to wait a week).
As written in the initial description, I do welcome the linting efforts, I just want to make sure it's not more toil for contributors than necessary, and having a documented CLI rather than requiring a full-blown integrated editor setup is one of these points.
Let's temporarily disable this check, and bring it back while documenting it and making it easily accessible for contributors.

I like the link to the draft values! I'd say it's a bit hard to apply it directly here though. When a PR introduces a linter problem:

Not having the check means that either:

A reviewer manually complains about it, the author needs to address it (lots of toil for author and reviewer)
It goes unnoticed (no toil)

Having the check that only runs in CI:

Author needs to address it only after CI runs (toil only for the author)

Having the check also running locally

Author needs to address it, but can do so with immediate feedback (no toil)

So we're trading the chance of toil on behalf of the author and reviewer, for guaranteed toil only for the author.

Well, we didn't have a check before. Humans could give feedback on unused variables etc, and both authors and reviewer were free to dismiss it. This changes with a required CI check, which currently must be fixed by a contributor, making this a bigger toil than something that can be ignored.
Anyways, I think this is going a bit offtopic, and probably also isn't a productive use of our time.
If you only want to disable the check in a week, and not before, that's your call ;-)
The important part is it's easy to reintroduce it once the tooling and documentation issues for it have been addressed.

Well, we didn't have a check before. Humans could give feedback on unused variables etc, and both authors and reviewer were free to dismiss it. This changes with a required CI check, which currently must be fixed by a contributor, making this a bigger toil than something that can be ignored.

That's a good point :+1:

I need to take IELTS and GRE before September (and I barely prepared for them), so I may not have the time and energy to finish this project before then. So it's okay to temporarily close it for now.
My idea is very straightforward: just a simple cli frontend using the famous https://crates.io/crates/ariadne crate and nixf as a library. If possible, add a crate that can handle diff so that we can determine the scope of the error based on the modification range. This cli can be placed in the nixd repo and maintained together with nixd. (I've already thought of a name, let’s call it ninter!)
But I haven't really written Rust code from scratch before, so I'm still in the painful learning process so it's not very fast. Of course, if someone else can do this, we'd also welcome it.

Alright cool, I disabled the workflow manually for now, any committer can reenable it from https://github.com/NixOS/nixpkgs/actions/workflows/check-nixf-tidy.yml when ready :)


81-test_cmp_cli.t fails in MSYS2

I am installing openssl in windows 10 using MSYS2 and using mingw64 as compiler.
Configuration output:

Command line (with current working directory = .):

    perl ./Configure mingw64

Perl information:

    perl
    5.32.1 for x86_64-msys-thread-multi

Enabled features:

    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    bulk
    cached-fetch
    camellia
    capieng
    cast
    chacha
    cmac
    cmp
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    idea
    legacy
    loadereng
    md4
    mdc2
    module
    multiblock
    nextprotoneg
    ocb
    ocsp
    padlockeng
    pic
    pinshared
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    secure-memory
    seed
    shared
    siphash
    siv
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    ssl-trace
    static-engine
    stdio
    tests
    threads
    tls
    ts
    ui-console
    whirlpool
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method

Disabled features:

    acvp-tests          [cascade]        OPENSSL_NO_ACVP_TESTS
    afalgeng            [not-linux]      OPENSSL_NO_AFALGENG
    asan                [default]        OPENSSL_NO_ASAN
    buildtest-c++       [default]
    crypto-mdebug       [default]        OPENSSL_NO_CRYPTO_MDEBUG
    devcryptoeng        [default]        OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128 [default]        OPENSSL_NO_EC_NISTP_64_GCC_128
    egd                 [default]        OPENSSL_NO_EGD
    external-tests      [default]        OPENSSL_NO_EXTERNAL_TESTS
    fips                [default]
    fips-securitychecks [cascade]        OPENSSL_NO_FIPS_SECURITYCHECKS
    fuzz-afl            [default]        OPENSSL_NO_FUZZ_AFL
    fuzz-libfuzzer      [default]        OPENSSL_NO_FUZZ_LIBFUZZER
    ktls                [default]        OPENSSL_NO_KTLS
    makedepend          [unavailable]
    md2                 [default]        OPENSSL_NO_MD2 (skip crypto/md2)
    msan                [default]        OPENSSL_NO_MSAN
    rc5                 [default]        OPENSSL_NO_RC5 (skip crypto/rc5)
    sctp                [default]        OPENSSL_NO_SCTP
    tfo                 [default]        OPENSSL_NO_TFO
    trace               [default]        OPENSSL_NO_TRACE
    ubsan               [default]        OPENSSL_NO_UBSAN
    unit-test           [default]        OPENSSL_NO_UNIT_TEST
    uplink              [no uplink_arch] OPENSSL_NO_UPLINK
    weak-ssl-ciphers    [default]        OPENSSL_NO_WEAK_SSL_CIPHERS
    zlib                [default]
    zlib-dynamic        [default]
    ssl3                [default]        OPENSSL_NO_SSL3
    ssl3-method         [default]        OPENSSL_NO_SSL3_METHOD

Config target attributes:

    AR => "ar",
    ARFLAGS => "qc",
    CC => "gcc",
    CFLAGS => "-Wall -O3",
    HASHBANGPERL => "/usr/bin/env perl",
    RANLIB => "ranlib",
    RC => "windres",
    asm_arch => "x86_64",
    bn_ops => "SIXTY_FOUR_BIT",
    build_file => "Makefile",
    build_scheme => [ "unified", "unix" ],
    cflags => "-m64",
    cppflags => "-DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT",
    defines => [ "OPENSSL_BUILDING_OPENSSL" ],
    disable => [  ],
    dso_scheme => "win32",
    enable => [  ],
    ex_libs => "-lws2_32 -lgdi32 -lcrypt32",
    includes => [  ],
    lflags => "",
    lib_cflags => "",
    lib_cppflags => "-DL_ENDIAN",
    lib_defines => [  ],
    module_cflags => "",
    module_cxxflags => undef,
    module_ldflags => "-static-libgcc -shared -Wl,--enable-auto-image-base",
    multilib => "64",
    perl_platform => "mingw",
    perlasm_scheme => "mingw64",
    shared_argfileflag => "\@",
    shared_cflag => "",
    shared_cppflags => "_WINDLL",
    shared_defflag => "",
    shared_defines => [  ],
    shared_impflag => "-Wl,--out-implib=",
    shared_ldflag => "-static-libgcc -shared -Wl,--enable-auto-image-base",
    shared_rcflag => "--target=pe-x86-64",
    shared_target => "mingw-shared",
    sys_id => "MINGW64",
    thread_defines => [  ],
    thread_scheme => "winthreads",
    unistd => "<unistd.h>",

Recorded environment:

    AR =
    ARFLAGS =
    AS =
    ASFLAGS =
    BUILDFILE =
    CC =
    CFLAGS =
    CPP =
    CPPDEFINES =
    CPPFLAGS =
    CPPINCLUDES =
    CROSS_COMPILE =
    CXX =
    CXXFLAGS =
    HASHBANGPERL =
    LD =
    LDFLAGS =
    LDLIBS =
    MT =
    MTFLAGS =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    RCFLAGS =
    RM =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = ar
    ARFLAGS         = qc
    CC              = gcc
    CFLAGS          = -Wall -O3
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        =
    HASHBANGPERL    = /usr/bin/env perl
    LDFLAGS         =
    LDLIBS          =
    PERL            = perl
    RANLIB          = ranlib
    RC              = windres
    RCFLAGS         =

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
    Makefile

build file:

    Makefile

build file templates:

    Configurations/common0.tmpl
    Configurations/unix-Makefile.tmpl

When I run the test test_cmp_cli, it throws me this error:
# setup_srv_ctx:apps/cmp.c:1072:CMP warning: mock server will not be able to handle signature-protected requests since -srv_trusted is not given
# setup_request_ctx:apps/cmp.c:1584:CMP warning: missing -recipient, -srvcert, -issuer, -oldcert or -cert; recipient will be set to "NULL-DN"
# setup_client_ctx:apps/cmp.c:1977:CMP info: will contact mock server
# CMP info: sending CR
# CMP info: received CP
# CMP info: received 'waiting' PKIStatus, starting to poll for response
# CMP info: sending POLLREQ
# CMP info: received CP
# CMP info: received ip/cp/kup after polling
# CMP info: sending CERTCONF
# CMP info: received PKICONF
# save_free_certs:apps/cmp.c:2024:CMP info: received 1 enrolled certificate(s), saving to file './test.certout.pem'
../../util/wrap.pl ../../apps/openssl.exe cmp -config '' -poll_count 1 -use_mock_srv -srv_ref 'mock server' -srv_secret 'pass:test' -rsp_cert ../../test/certs/ee-cert-1024.pem -cmd cr -subject /CN=any -newkey ../../test/certs/ee-key-1024.pem -secret 'pass:test' -ref 'client under test' -certout ./test.certout.pem => 0
not ok 8 - with polling
# ------------------------------------------------------------------------------
#   Failed test 'with polling'
#   at test/recipes/81-test_cmp_cli.t line 75.
Engine "loader_attic" set.
# setup_srv_ctx:apps/cmp.c:1072:CMP warning: mock server will not be able to handle signature-protected requests since -srv_trusted is not given
# setup_request_ctx:apps/cmp.c:1584:CMP warning: missing -recipient, -srvcert, -issuer, -oldcert or -cert; recipient will be set to "NULL-DN"
# setup_client_ctx:apps/cmp.c:1977:CMP info: will contact mock server
# CMP info: sending CR
# CMP info: received CP
# CMP info: sending CERTCONF
# CMP info: received PKICONF
# save_free_certs:apps/cmp.c:2024:CMP info: received 1 enrolled certificate(s), saving to file './test.certout.pem'
../../util/wrap.pl ../../apps/openssl.exe cmp -config '' -engine loader_attic -use_mock_srv -srv_ref 'mock server' -srv_secret 'pass:test' -rsp_cert ../../test/certs/ee-cert-1024.pem -cmd cr -subject /CN=any -newkey ../../test/certs/ee-key-1024.pem -secret 'pass:test' -ref 'client under test' -certout ./test.certout.pem => 0
not ok 9 - with loader_attic engine
# ------------------------------------------------------------------------------
#   Failed test 'with loader_attic engine'
#   at test/recipes/81-test_cmp_cli.t line 75.

It seems that the problem is similar than that reported on #12514, and resolved in #12537 where the solution was made by skipping the test with mock servers

I am working with the current commit e5f831a

@DDvO any idea? I do not see the failure - the cmp commands seems to succeed.

Which version of OpenSSL is this?

Which version of OpenSSL is this?

According to what @pczero91 wrote before, this is on the current master.

Yes, I believe is 3.1.0

@DDvO any idea?

This looks like a test driver issue, likely regarding the detection of test case success/failure.
It would be some effort at least to me to try to reproduce this on a Windows system.

I do not see the failure - the cmp commands seems to succeed.

Yes - according to the test output, the client-server communication ended successfully,
and the client reports to write the new cert to a file, which is the final step to do on success.

Which version of OpenSSL is this?

According to what @pczero91 wrote before, this is on the current master.

Yes, I believe is 1.1.1o

If you really use commit e5f831a065df1d6e4640ef389f8594a5f10c9c8e, this must be OpenSSL 3.1.0-dev.

And it cannot be 1.1.1 also because there is no CMP there.

Which version of OpenSSL is this?

According to what @pczero91 wrote before, this is on the current master.

Yes, I believe is 1.1.1o

If you really use commit e5f831a065df1d6e4640ef389f8594a5f10c9c8e, this must be OpenSSL 3.1.0-dev.

According to the source it is supposed to be 3.1.0, but after I installed the build and asked for the openssl version my pc showed me that it is 1.1.1o

According to the source it is supposed to be 3.1.0, but after I installed the build and asked for the openssl version my pc showed me that it is 1.1.1o

Then something is wrong with the installation of the new version on your machine -
maybe you need to update at least some environment variables such that 3.1.0-pre is used.

Then something is wrong with the installation of the new version on your machine - maybe you need to update at least some environment variables such that 3.1.0-dev is used.

I am sorry, I got openssl version from the command promt rather than from MSYS2... in MSYS2 says 3.1.0-dev. Sorry for the confusion.

This looks like a test driver issue, likely regarding the detection of test case success/failure.
It would be some effort at least to me to try to reproduce this on a Windows system.

It is something to do with my build?

This looks like a test driver issue, likely regarding the detection of test case success/failure.
It would be some effort at least to me to try to reproduce this on a Windows system.

It is something to do with my build?

I don't know.
Is this the only build/test issue you are facing?
At least if you do not use CMP, a quick workaround of course would be to ignore these test failures
or to disable CMP: perl ./Configure mingw64 no-cmp

I don't know. Is this the only build/test issue you are facing?
At least if you do not use CMP, a quick workaround of course would be to ignore these test failures or to disable CMP: perl ./Configure mingw64 no-cmp

I only have issues with this test (81-test_cmp_cli.t) and with 80-test_pkcs12.t (the same error that happens in #18017 for this test only)

This is the 80-test_pcks12.t error I have:
( SRCTOP=. \
  BLDTOP=. \
  PERL="perl" \
  FIPSKEY="f4556650ac31d35461610bac4ed81b1a181b2d8a43ea2854cbae22ca74560813" \
  EXE_EXT=.exe \
  perl ./test/run_tests.pl test_pkcs12 )
00-prep_fipsmodule_cnf.t .. skipped: FIPS module config file only supported in a fips build
Files=1, Tests=0,  1 wallclock secs ( 0.00 usr  0.05 sys +  0.19 cusr  0.56 csys =  0.80 CPU)
Result: NOTESTS

    # ERROR: (bool) 'p12 == d2i_PKCS12_bio(bio, &p12) == true' failed @ test/pkcs12_api_test.c:46
    # false
    # ERROR: (ptr) 'p12 != NULL' failed @ test/pkcs12_api_test.c:74
    # 0x0
    # ERROR: (bool) 'ret == true' failed @ test/pkcs12_api_test.c:94
    # false
    # 68100000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
    # OPENSSL_TEST_RAND_ORDER=1652703084
    not ok 2 - pkcs12_parse_test
# ------------------------------------------------------------------------------
../../util/wrap.pl ../../test/pkcs12_api_test.exe -in out1.p12 -has-ca 1 => 1
not ok 16 - Test pkcs12_parse()
# ------------------------------------------------------------------------------
    # ERROR: (bool) 'p12 == d2i_PKCS12_bio(bio, &p12) == true' failed @ test/pkcs12_api_test.c:46
    # false
    # ERROR: (ptr) 'p12 != NULL' failed @ test/pkcs12_api_test.c:74
    # 0x0
    # ERROR: (bool) 'ret == true' failed @ test/pkcs12_api_test.c:94
    # false
    # D8320000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
    # OPENSSL_TEST_RAND_ORDER=1652703084
    not ok 2 - pkcs12_parse_test
# ------------------------------------------------------------------------------
../../util/wrap.pl ../../test/pkcs12_api_test.exe -in out2.p12 -pass v3-certs -has-ca 1 => 1
not ok 17 - Test pkcs12_parse()
# ------------------------------------------------------------------------------
    # ERROR: (bool) 'p12 == d2i_PKCS12_bio(bio, &p12) == true' failed @ test/pkcs12_api_test.c:46
    # false
    # ERROR: (ptr) 'p12 != NULL' failed @ test/pkcs12_api_test.c:74
    # 0x0
    # ERROR: (bool) 'ret == true' failed @ test/pkcs12_api_test.c:94
    # false
    # B4210000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
    # OPENSSL_TEST_RAND_ORDER=1652703085
    not ok 2 - pkcs12_parse_test
# ------------------------------------------------------------------------------
../../util/wrap.pl ../../test/pkcs12_api_test.exe -in out3.p12 -pass v3-certs -has-ca 1 => 1
not ok 18 - Test pkcs12_parse()
# ------------------------------------------------------------------------------
    # ERROR: (bool) 'p12 == d2i_PKCS12_bio(bio, &p12) == true' failed @ test/pkcs12_api_test.c:46
    # false
    # ERROR: (ptr) 'p12 != NULL' failed @ test/pkcs12_api_test.c:74
    # 0x0
    # ERROR: (bool) 'ret == true' failed @ test/pkcs12_api_test.c:94
    # false
    # D02C0000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
    # OPENSSL_TEST_RAND_ORDER=1652703085
    not ok 2 - pkcs12_parse_test
# ------------------------------------------------------------------------------
../../util/wrap.pl ../../test/pkcs12_api_test.exe -in out4.p12 -pass v3-certs -has-ca 1 -has-key 1 -has-cert 1 => 1
not ok 19 - Test pkcs12_parse()
# ------------------------------------------------------------------------------
    # ERROR: (bool) 'p12 == d2i_PKCS12_bio(bio, &p12) == true' failed @ test/pkcs12_api_test.c:46
    # false
    # ERROR: (ptr) 'p12 != NULL' failed @ test/pkcs12_api_test.c:74
    # 0x0
    # ERROR: (bool) 'ret == true' failed @ test/pkcs12_api_test.c:94
    # false
    # 88120000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
    # OPENSSL_TEST_RAND_ORDER=1652703086
    not ok 2 - pkcs12_parse_test
# ------------------------------------------------------------------------------
../../util/wrap.pl ../../test/pkcs12_api_test.exe -in out6.p12 -pass '' -has-ca 1 -has-key 1 -has-cert 1 => 1
not ok 21 - Test pkcs12_parse()
# ------------------------------------------------------------------------------
#   Failed test 'Test pkcs12_parse()'
#   at test/recipes/80-test_pkcs12.t line 206.
# Looks like you failed 5 tests of 21.80-test_pkcs12.t ..
Dubious, test returned 5 (wstat 1280, 0x500)
Failed 5/21 subtests

1.1.1 version is out of public support.


Update JsonAdadptedOrder Update JsonAdaptedOrderTest

Codecov Report
Base: 62.84% // Head: 63.78% // Increases project coverage by +0.93% :tada:

Coverage data is based on head (8ece96c) compared to base (bc4efb3).
Patch coverage: 55.76% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #313      +/-   ##
============================================
+ Coverage     62.84%   63.78%   +0.93%
- Complexity     1197     1221      +24
============================================
  Files           189      189
  Lines          4393     4382      -11
  Branches        527      526       -1
============================================
+ Hits           2761     2795      +34
+ Misses         1422     1392      -30
+ Partials        210      195      -15

Impacted Files
Coverage Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)

...ava/seedu/address/logic/commands/MatchCommand.java
100.00% <ø> (ø)

...ss/logic/commands/addcommands/AddOrderCommand.java
100.00% <ø> (ø)

...ress/logic/commands/addcommands/AddPetCommand.java
85.71% <ø> (ø)

...va/seedu/address/logic/parser/PredicateParser.java
61.84% <ø> (-0.50%)
:arrow_down:

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

.../java/seedu/address/model/util/SampleDataUtil.java
0.00% <0.00%> (ø)

...ain/java/seedu/address/storage/JsonAdaptedPet.java
88.73% <0.00%> (+9.85%)
:arrow_up:

...in/java/seedu/address/logic/parser/ParserUtil.java
48.38% <14.28%> (+1.12%)
:arrow_up:

...rc/main/java/seedu/address/model/ModelManager.java
96.53% <40.00%> (-3.47%)
:arrow_down:

... and 19 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

It's good to merge!


CNTK as backend for SharpLearning.Neural

The Microsoft team working on CNTK has recently released the initial version of the C#/.Net API with support for both evaluation and training of neural networks. A more feature complete version, with support for layers and other helpful features, should arrive before the end of the year. Currently, there seems to be a few performance related issues (https://github.com/Microsoft/CNTK/issues/2374 and https://github.com/Microsoft/CNTK/issues/2386) but hopefully these will be also be solved in the next release.
Using CNTK as backend for SharpLearning.Neural will add operators for more layer and network types, while also enabling GPU training and evaluation. Using a well supported deep learning toolkit as backend will also help to ensure that future operator, layer and network types will be available faster.
This task will require a large rewrite of SharpLearning.Neural, most likely only keeping the top level interface. However, since all the core operations are availible from CNTK, most of the hard work is already completed.
This task should be split into multiple others when a design of how CNTK should be integrated has been completed. A few considerations:

Should the integrations be "simple", i.e. only have a NeuralNetLearner and NeuralNetModel in SharpLearning and use the layer construction and related functionality from CNTK directly?
Should the integration hide CNTK behind an adapter to make it easier to support other deep learning toolkits like TensorFlow(Sharp)?

Hi @mdabros , that Microsoft/CNTK#2374 is fixed. If you are using CNTK from source, the fix is effective. If you are using CNTK NuGet package, the fix will be available on Nov 7th in CNTK 2.3 Release. Thanks!

Hi @liqunfu, Thanks for taking the time to inform me and thanks for the great work! Looking forward to the 2.3 release :-).

Initial work/investigation for creating  "backend" projects for interfacing with CNTK and TensorFlowSharp has been started in the branch: backends. This approach focuses on creating a common low level API for interfacing with the deep learning  tool kits, and rewriting SharpLearning.Neural on top of this API. So the more "advanced" of the two options mentioned in the original message.
There is also a pull request where progress/changes can be tracked in #35


Understanding Ngnix and Traefik

Hi,
I noticed that traefik is used to provide load balancing between frontend and backend under the same domain served by different containers.
I also noticed that on Vue dockerfile also contains NGNIX (another load balancer).
I would like to understand the main purpose of using Ngnix in this case. Is it necessary to deal with static files ? With vue-router ? Traefik does not serve static content like NGINX does ?

for prod, traefik is pretty sluggish, but its great for build stage with hot reload and all that jazz. for me personally on prod i prefer nginx. fast, scaleable, great compression, great security. but thats just my opinion and im sure theres alot of pros for traefik aswell

Thanks for the reply @haviduck. It makes sense, maybe traefik is being used just to handle basic tasks.


CLI parameters: what is required, order to pass things, unclear

Currently we have:
$ meteor.diffmap -h
usage: meteor.diffmap [-h] [-da DERIVATIVE_AMPLITUDE_COLUMN]
                      [-du DERIVATIVE_UNCERTAINTY_COLUMN] [-na NATIVE_AMPLITUDE_COLUMN]
                      [-nu NATIVE_UNCERTAINTY_COLUMN] -s STRUCTURE [-o MTZOUT]
                      [-m METADATAOUT] [-k {optimize,fixed,none}] [-w KWEIGHT_PARAMETER]
                      [-tv {optimize,fixed,none}] [-l TV_WEIGHT]
                      derivative_mtz native_mtz

Compute an isomorphous difference map, optionally applying k-weighting and/or TV-denoising
if desired. In the terminology adopted, this script computes a `derivative` minus a
`native` map, using a constant phase approximation. Phases, typically from a model of the
`native` data, are computed from a CIF/PDB model you must provide.

options:
  -h, --help            show this help message and exit
  -s STRUCTURE, --structure STRUCTURE
                        Specify CIF or PDB file path, for phases (usually a native model).
                        Required.
  -o MTZOUT, --mtzout MTZOUT
                        Specify output MTZ file path. Default: meteor_difference_map.mtz.
  -m METADATAOUT, --metadataout METADATAOUT
                        Specify output metadata file path. Default: meteor_metadata.csv.
  -k {optimize,fixed,none}, --kweight-mode {optimize,fixed,none}
                        How to pick the k-parameter. Optimize means max negentropy.
                        Default: `optimize`.
  -w KWEIGHT_PARAMETER, --kweight-parameter KWEIGHT_PARAMETER
                        If `--kweight-mode fixed`, set the kweight-parameter to this value.
                        Default: 0.05.
  -tv {optimize,fixed,none}, --tv-denoise-mode {optimize,fixed,none}
                        How to find a TV regularization weight (lambda). Optimize means
                        pick maximum negentropy. Default: `optimize`.
  -l TV_WEIGHT, --tv-weight TV_WEIGHT
                        If `--tv-denoise-mode fixed`, set the TV weight parameter to this
                        value. Default: 0.01.

derivative:
  The 'derivative' diffraction data, typically: light-triggered, ligand-bound, etc.

  derivative_mtz
  -da DERIVATIVE_AMPLITUDE_COLUMN, --derivative-amplitude-column DERIVATIVE_AMPLITUDE_COLUMN
                        specify the MTZ column for the amplitudes; will try to guess if not
                        provided
  -du DERIVATIVE_UNCERTAINTY_COLUMN, --derivative-uncertainty-column DERIVATIVE_UNCERTAINTY_COLUMN
                        specify the MTZ column for the uncertainties; will try to guess if
                        not provided

native:
  The 'native' diffraction data, typically: dark, apo, etc.

  native_mtz
  -na NATIVE_AMPLITUDE_COLUMN, --native-amplitude-column NATIVE_AMPLITUDE_COLUMN
                        specify the MTZ column for the amplitudes; will try to guess if not
                        provided
  -nu NATIVE_UNCERTAINTY_COLUMN, --native-uncertainty-column NATIVE_UNCERTAINTY_COLUMN
                        specify the MTZ column for the uncertainties; will try to guess if
                        not provided

@alisiafadini pointed out this formatting makes it a bit unclear what is required and what is optional. Better grouping of the arguments could help a lot.

resolved by #49 and then #47


Use Objective-C naming convention for Cluster method names

Problem
The Cluster APIs don't follow Objective-C naming convention. This results in less than perfect Swift interoperability.

Summary of Changes

Added "WithXYZ" to "label" the first argument of each API
Renamed completionHandler to responseHandler

Link to the only meaningful commit here: https://github.com/project-chip/connectedhomeip/commit/65888508a046c68f550efa2d348a51ae062fadd8

@sagar-apple Darwin CI broken :)


Added note about long-running bulk insert transactions

Fixes #7815.

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/38b83377987262b84af782cea1ce832e1fb2d939/
Edited pages:

v20.2/insert.md
v20.2/performance-best-practices-overview.md

@awoods187 Friendly ping on review. :)

LGTM @dt would you mind taking a look as well?

@awoods187 I / bulk-io aren't really the experts on INSERT performance and the SQL / OLTP write path. I'd defer to sql exec team on that I think.

Certainly for the bulk ones you are though? This is about the bulk inserts that result in long-running transactions and steering people away from that? I think it makes sense for you to look at that portion?
@asubiotto will you also PTAL?

Not really: despite the label, "bulk" INSERTS are still just SQL INSERTS, and don't get any special bulk io treatment/consideration/etc, -- it is more up to the SQL experts to advise on how to use or not to use our SQL interface, including its INSERTS, transaction lifetimes, etc.


Port Newtonsoft.Json tests

This pulls in and ports the Newtonsoft.Json tests and converts the existing tests to XUnit.
Fixes #59

My discovery was that the ContractResolverTests from Newtonsoft.Json expected DefaultValueAttribute to be respected.
However, DefaultValueAttribute is not part of the DataContract concept, nor is it respected by System.Text.Json
Something to think about, but not really necessary.
@zcsizmadia

Thanks for the PR!


Template is not found

Describe the bug
I used the latest version of generator & tempalte, got an error.
error: Unknown codegen template: "graphql-codegen-typescript-template", please make sure it's installed using npm/Yarn!
To Reproduce

npm install --save-dev graphql-code-generator graphql
npm install --save-dev graphql-codegen-typescript-template
$ gql-gen --schema http://localhost:3010/graphql --template graphql-codegen-typescript-template --out ./typings/ "./src/**/*.graphql"

Environment:

OS: Windows 10
Codegen:  0.12.6, Template 0.12.6
Node:  8.12.0

Could you try the following command?
gql-gen --template graphql-codegen-typescript-template --out ./typings/ --schema http://localhost:3010/graphql "./src/**/*.graphql"

I had the same issue; Here is my fix
gql-gen--template node_modules/graphql-codegen-typescript-template --out ./src/gqlgen/saberGqlModel.ts --schema http://localhost:65164/graphql"

@alonstar @gardinit which version of node and npm you are using? any chance you can share a reproduction?
Specifying just graphql-codegen-typescript-template should work...

@gardinit  it's work!! thank you.
@dotansimha @ardatan Here is execution log.
D:\Graphql
λ gql-gen --template node_modules/graphql-codegen-typescript-template --out models.ts --schema http://localhost:4701/mutual-fund-admin/gra phql
10:41:36.336 - info: Loading GraphQL Introspection from remote: http://localhost:4701/mutual-fund-admin/graphql...
10:41:39.228 - info: Generated file written to D:\Graphql\models.ts

D:\Graphql
λ gql-gen --template graphql-codegen-typescript-template --out models.ts --schema http://localhost:4701/mutual-fund-admin/graphql
10:42:13.841 - error: Unknown codegen template: "graphql-codegen-typescript-template", please make sure it's installed using npm/Yarn!

D:\Graphql
λ node -v
v8.12.0

D:\Graphql
λ npm -v
6.4.1

I'm note sure what's the actual issue here, but we did changed the way we load templates, so it might work now. @alonstar i'm closing this issue at the moment. Can you please try with the latest API and re-open if it still happens?


Improvements to the Top Shot Contracts

This draft includes my proposed changes to TopShot.cdc to fix a few issues
Make array and dictionary fields private
Public array and dictionary fields cannot be directly assigned to, but their elements can be modified, so I have made them private so the admin cannot modify these fields.
Borrow references to resources instead of loading them from their fields
This is a performance improvement, but also fixes a bug that will show up when cadence is upgraded next where resource owner field is nil when a resource is not stored. This would break event-based ownership tracking for the sharded collection if not fixed before the cadence update.
Create a more easily Queryable struct for set metadata
Currently, querying for set data is difficult because you have to do individual function calls. This method puts all the important data into a single struct so it can be queried all at once

This might not be an appropriate place to ask this... but is there a way to tell on github if this change has been deployed to mainnet? Along the same lines, when the change is live, does the contract live at the same address? Or does flow require that you create a new contract with a new address?

@renschler Great question! We don't have a current indication on github if the contracts are deployed, but that is something we could definitely add. Great suggestion. If a project doesn't have an indication like that though, you could always just check the address on chain to see if the code is the same. We have deployed this upgrade though, so the update in the PR is on-chain.
Upgrades can be done on the same address, so we didn't have to re-deploy for this one. There are restrictions for upgrades though: https://docs.onflow.org/cadence/language/contract-updatability/


Change library package manager -> nuget package manager

Library Package Manager (VS 2013) is now NuGet Package Manager (>= VS 2015).
Also cleaned up whitespace and a few headings.
(Recommend hiding whitespace changes in the diff.)

@gewarren something looks odd here. Let me merge master.

Rebase got rid of the extra PRs. You can squash and merge when ready,

@mairaw Thank you!


Sending xDS response ... message is too verbose

@rlenglet The below log seems a bit high log level, no?
https://github.com/cilium/cilium/blob/9e0db26f6c650a36bb4ffdfa1dadab34a1ed9395/pkg/envoy/xds/server.go#L385

I'm fixing this in https://github.com/cilium/cilium/pull/3131/commits/fd43e84bd702066ce7965d14321e590662b58387.


OwnedTypes on navigation property are not automatically included

If you retrieve an entity from the dbset the OwnedTypes are included by default. If I want to include a child entity that is not owned but has it's own owned types, these are not included by default.
db.Set<Parent>().Include(p=>child); //child owns 1 toy

expected consistent behavior
Either the entity is owned there for always included when the owning entity is or you must explicitly include all owned navigations
Further technical details
EF Core version: 2.0.0
Database Provider: Microsoft.EntityFrameworkCore.Sqlite
Operating system: WIndows 10
IDE: Visual Studio 2017

Duplicate of #9210


Made minor formatting changes and added descriptive text.

this is amazing. I resolved the conflict locally and pushed it back up - git could tell this change was merged! I love git.


0.7.0 Provider encounters API issues with 5.4

Receive "406 Not Acceptable" when attempting to to access data resources in Appgate
data "appgatesdp_site" "default_site" {
  site_name = "Default site"
}
data "appgatesdp_condition" "always" {
    condition_name = "Always"
}

returns:
╷
│Error: 406 Not Acceptable
│
│   with module.appgate_logserver.data.appgatesdp_site.default_site,
│   on modules/appgate_additional_appliance/data.tf line 27, in data "appgatesdp_site" "default_site":
│   27: data "appgatesdp_site" "default_site" {
│
╵
╷
│ Error: 406 Not Acceptable
│
│   with module.appgate_objects.data.appgatesdp_site.default_site,
│   on modules/appgate_objects/data.tf line 1, in data "appgatesdp_site" "default_site":
│    1: data "appgatesdp_site" "default_site" {
│
╵
╷
│ Error: 406 Not Acceptable
│
│   with module.appgate_objects.data.appgatesdp_condition.always,
│   on modules/appgate_objects/data.tf line 4, in data "appgatesdp_condition" "always":
│    4: data "appgatesdp_condition" "always" {
│

Deploying AppGate 5.4 with the 0.6.12 provider was successful
Upgraded provider to 0.7.0
plan still configured for 5.4 image with "appgate_client_version:15"

Closing this issue since this should be resolved now in 0.8.0, Please read the changelog, as this release can require changes in your provider "appgatesdp" {} block


Task: Activate LoRa Features by configuration setting

US: #192
Is your feature request related to a problem? Please describe.
When the platform is not subject to managed LoRa infrastructure. get the possibility to disable it completly.
Describe the solution you'd like
A configuration token on the portal to activate/de-activate the lora features.

Concentrators,
LoRa Commands,
LoRa Device type in model,
...

Describe alternatives you've considered
N/A
Additional context
N/A

Should add a new configuration settings (in Configuration) : App:ActivateLoraFeatures default true.


A ticket cannot depends on itself or on a ticket already depending on it

I added a fix in the ticket dependency form in order to prevent creating a dependency on itself or with a ticket which is already depending on the current ticket, since it would block the process (though we can always delete the dependency after).

Excellent, thanks for catching this bug!


chore: fix project.json

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring
[ ] Code style update
[x] Build or CI related changes
[ ] Documentation content changes

@nsbarsukov @vladimirpotekhin sorry, I need it in separate PR :((


fix(code-uri): encode form tag for preventing ERR_BLOCKED_BY_XSS_AUDITOR

Closes https://github.com/freeCodeCamp/freeCodeCamp/issues/13727

This does encode the URL correctly stripping off the tags and replacing them. But does not resolve the original issue. Will try and update soon.

Closing in favor of the ongoing discussion in the chat.


FORMAT-COMPLEX should be compatible with ~/.../ format strings

~/cl-quil:format-complex/ would be very nice in format. If we did this, then we could use @ or :-modifiers to make it print as cartesian or polar, maybe. Make it so!

Maybe following PR #194 we should have FMT-COMPLEX or FMT-CC or something.

Following PR #194, the final decision was to name things like COMPLEX-FMT.


[enhancement] Indicate a cycle is active

Hi,
I really like the new min_cycle_duration setting, but sometimes I forget about it and fiddle about with the temperature and wonder why it's not switching the heater on/off.
I think an indicator on the ha card that a cycle is currently active (and maybe the time left on the cycle) would be useful.

Ciao
I'm not able to develop cards, so the only things that I could do is to expose a custom attribute with this information.
Anyway I don't have enough time to dedicate to programmable thermostat except to fix breaking changes in HA.
You can open a PR to add this.
In anycase I close this since this issue should have been open on the component page.


worker could be undefined after await getClient()

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.

Here is the diff that solved my problem:
diff --git a/node_modules/monaco-yaml/index.js b/node_modules/monaco-yaml/index.js
index d89e293..c0a34a1 100644
--- a/node_modules/monaco-yaml/index.js
+++ b/node_modules/monaco-yaml/index.js
@@ -398,7 +398,10 @@ function createWorkerManager(defaults) {
   };
   return async (...resources) => {
     const client2 = await getClient();
-    await worker.withSyncedResources(resources);
+    // could be cleaned by stopWorker
+    if (worker) {
+      await worker.withSyncedResources(resources);
+    }
     return client2;
   };
 }

This issue body was partially generated by patch-package.

Thanks for reporting this!
#160 is an open pull request that extracts this logic into a reusable package.
As can be seen in https://github.com/remcohaszing/monaco-worker-manager/blob/main/index.ts#L120-L129, the worker is now assigned synchronously before this line is called, so I think this will be fixed purely by coincidence in the next release.

OK, I'll use my patch temporarily.
When will https://github.com/remcohaszing/monaco-yaml/pull/160 be merged?

I tend to wait for someone to do a code review, as @fleon and @yazaabed have both shown interested in helping out. I really appreciate this, but sometimes it takes quite a long time for them to perform code reviews.
If you really need this fix, I can just merge and release it without a review this weekend.
There are some pending new features too. :)

I just released v4.0.0-alpha.2


DNS queries

I noticed the petio is making 1000's of DNS queries for my plex direct host name. In 1 hour it has asked over 4,000 times.

I'm guessing this is on a linux system since the majority of linux systems do not cache DNS locally which means every request that Petio is doing to your Plex server, has to re-resolve the hostname. If that's a worry for you, you should switch to using the IP for the Plex connection.


ERR: buffer length exceeds 128

Testing 0.9.1 with OBS publishing, I get frequent and disconnects

Hello, OBS studio does not support publishing to RTSP, so i suppose you're talking about the "Media Source" source. Can you describe better the problem? what is your pipeline? for example:
ffmpeg -> rtsp-simple-server -> obs -> rtmp
thanks

This is surely solved, since all buffers have a size greater than 128. If you still have problems, please open another issue.


Add support for pyproject.toml

Description
There are a few nice-to-haves and caveats to this migration to pyproject.toml:

The setup.py file cannot be removed completely due to its flexibility with custom wheel build processes and steps to build extension modules, so this is more of an addition/conjugation with setuptools.build_meta rather than a complete migration—the latter is not possible without the inclusion of a new build-backend such as meson-build or scikit-build-core. Note: the scikit-build-core's support for editable installations is not mature and might break things, and scikit-build is the predecessor to it with limited support for editable installations, which is a deal-breaker.
Project metadata can now be included inside pyproject.toml, which simplifies the setuptools.setup() command. The CMakeBuild.py script is directly included inside setup.py to expose the linking of the IDAKLU extension and usage of the CMake arguments.

A list of tasks:

[x] Editable wheels on Windows, Linux, and macOS are working on GitHub Actions, and on ARM-based macOS machines locally. I will test them on a Windows system locally as well.
[x] pip is able to build non-editable wheels
[x] Both isolated and non-isolated builds work
[x] Unit and integration tests are passing on all platforms
[x] Doctests, example notebooks, and example scripts are passing
[x] cibuildwheel jobs pass for building reproducible wheels for all platforms

Fixes #3049 and supersedes #3053
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

[x] New feature (non-breaking change which adds functionality)
[ ] Optimization (back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)

Key checklist:

[x] No style issues: $ pre-commit run (or $ nox -s pre-commit) (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)
[x] All tests pass: $ python run-tests.py --all (or $ nox -s tests)
[x] The documentation builds: $ python run-tests.py --doctest (or $ nox -s doctests)

You can run integration tests, unit tests, and doctests together at once, using $ python run-tests.py --quick (or $ nox -s quick).
Further checks:

[x] Code is commented, particularly in hard-to-understand areas
[ ] Tests added that prove fix is effective or that feature works

So far unit and integration tests passed for both Windows and macOS but cibuildwheel failed on macOS and passed on Windows. With nox in the CI we run on a global installation of PyBaMM and not in a virtual environment, so we technically don't need to build without isolation. I am unsure how Read the Docs succeeds—we install the [docs] and [all] extras on an Ubuntu distribution, so it should have failed there like it did for the unit tests and other test groups on Ubuntu...

Shall we close #3053?

Shall we close #3053?

Yes, I think we should. This PR has more progress and is almost complete, I can liaise with @arjxn-py and bring it to fruition.

To give an update on the changes here, there are a few more things to be done before I can mark this ready for review. Some of these can also be completed in other, follow-up PRs:

The docs build is failing because the text files included inside the package are not being found. They are found on editable installs, but RTD does not do editable installs. To resolve this, I will set up a MANIFEST.in file and related configuration to ensure that these files and other files like CITATIONS.bib are copied into the SDist (what goes into the source distribution also goes into the wheel). We could use a setup.cfg file for this as well, but the Scientific Python guidelines recommend MANIFEST.in
Resolving the current merge conflicts and fixing the repair procedure on the wheels on GNU/Linux: I managed to do it by fixing the rpath for CasADi's dynamic libraries on macOS, but it is not as simple to do so on GNU/Linux since it uses a Dockerfile from PyPA. I am looking into either modifying the rpath on the idaklu target through CMake directly such that it can do so, or setting LD_LIBRARY_PATH to casadi's installation path. @martinjrobins reports that because the newer procedure successfully links against CasADi, delocate and auditwheel should be able to find that path (they do, but are not able to find it for some reason).
Moving configuration values for tools like ruff, pre-commit, coverage.py, and cibuildwheel into the pyproject.toml file such that we can exercise finer-grained control over all of them from the same file.
Instead of cloning pybind11 from GitHub using a script or through nox, we can now directly indicate it as a build-time dependency (pybind11 actually recommends this) in pyproject.toml and let CMake find its path through suitable modifications in the CMakeLists.txt file.

Shall we close #3053?

Happy to close and move ahead with this. Thanks.

I am marking this as ready for review now since wheel builds and the test suite are both passing on all platforms. This PR is slightly big and changed a lot of files, but everything should work now. Note: casadi is a build-time dependency in pyproject.toml specific to our case because we link against it when compiling the IDAKLU target. Now that the wheels repair error is fixed, I now finally realise its cause as to why auditwheel and delocate failed to find the casadi shared objects and dynamic libraries and so files on Ubuntu and macOS: the existence of the PEP517 pyproject.toml format mandates the creation of a temporary virtual environment in a private directory when installing a package to establish correct versions of dependencies and avoid conflicts with packages that are already installed. This was not the case with a setup.py-only build. I am poised to think that if we were to build and repair the wheels with legacy behaviour (with the use of the —no-build-isolation command-line flag and/or the legacy build_meta build-backend), the original configuration for setting their rpath would have worked, but we don't need to bother with that anymore unless this solution causes errors sometime in the future, plus we would not want anyone to install without isolation every time. Note: Codacy is not happy with the subprocesses running in the scripts but flags them only when files or lines containing them are changed, perhaps we can ignore those (or suppress them if feasible).
There are some other possible improvements as mentioned in https://github.com/pybamm-team/PyBaMM/pull/3301#issuecomment-1731253161, which I will open separate issues for, for visibility. We should also look into building wheels for ARM-based platforms either natively (Linux runners) or through emulation until GitHub Actions provides native support for macOS (cibuildwheel already has support for building universal wheels). The current wheels could be uploaded to TestPyPI in order for us to test them because we aren't checking whether they will install PyBaMM correctly on all platforms currently. They can be downloaded from the job summary page as well

@Saransh-cpp this PR has a lot of infrastructure-related changes, it would be great if you could take a look too before the the next release (#3374)

I was doing some cleanup in the noxfile to speed up the installation of the optional solvers and it looks like the Windows wheels have started failing unrelated to my changes, while they were passing yesterday and in the other workflow runs in this PR. Is it related to the vcpkg issue that has troubled us in the past? I am not sure how to debug the logs. Though it raises a ModuleNotFoundError due to casadi, that is fine here because we don't link against the Python casadi for Windows, we get it from vcpkg. Also, it looks like the registry is picking up SUNDIALS 5.7.0, which is outdated and not the same as our macOS and Linux workflows (we have 6.5.0 there).

Could you generate wheels on this branch and share the workflow's link? Other developers can try the wheels locally to ensure everything works before this is merged in.

I will disable building the wheels on pull requests in a commit at the time just before this will be merged. The latest builds can be downloaded from this link: https://github.com/pybamm-team/PyBaMM/actions/runs/6596974331?pr=3301
@arjxn-py had installed and tried the wheels some while back, so I will re-request a review for testing on amd64 Linux (WSL) and on amd64 (Windows). I will request a review from @kratman so that we can test the wheels on some more Linux machines. We don't have macOS arm64 wheels yet, but perhaps we can tag the maintainer trainees on this PR or on Slack so that anyone who has an Intel-based macOS machine can take a look? I think @tinosulzer could help out too with this. I spun up a container from the latest Docker images under emulation, they were working as expected there.
Note: we don't bundle the functionality or the scripts to run the unit tests in these user installations, so an appropriate and sufficient way to test them might be:

To see if pybamm.have_idaklu() returns True. This would indicate that the IDAKLU extension has been compiled correctly.
To see if the example notebooks and/or example scripts pass with PyBaMM installed from the wheel files (just copy run-tests.py and the relevant files and run the relevant command). This would allow us to see the IDAKLU solver in usage.

Please let me know if there is a better way to test, although imo these tests are redundant (the source installation in CI builds a wheel in the same way cibuildwheel does and therefore we are running the test suite there already). All other dependencies are pure Python and hence do not affect any functionality.

Also, is this blocked by any other PR or is it ready for merging?

This is ready for merging. Although, @brosaplanella had mentioned in this month's developers' meeting that we would like to wait for it until the release is done, and we now have a pre-release up. While this is a big change, it is related to the packaging only and PyBaMM's functionality will remain the same. So it is up to him and @tinosulzer if this is to be merged before the non-RC, since I can then take a look into some of the further improvements and/or #3462—that would be a nice addition for users considering that the next release (24.1) would then come at a much later time, i.e., next year

I think the issue was until the RC was published, which it is now. But I will leave it to @Saransh-cpp as he is the one handling the release.

if this is to be merged before the non-RC

This will/can be merged before the non-RC but into develop and not the release branch. I'd prefer to keep this for the next release.
Only security and bug fixes should be added to the release branch once rc0 is out.

if this is to be merged before the non-RC, since I can then take a look into some of the further improvements and/or https://github.com/pybamm-team/PyBaMM/issues/3462—that would be a nice addition for users considering that the next release (24.1) would then come at a much later time, i.e., next year

Is there a specific reason for including this PR in v23.9 and the further updates in the next one? Both, this PR, as well as other updates can be included in the next release, right?

(Note: I thought we were merging develop into main and adding a git tag on a commit on that branch to create a release. Do we have separate branches for RC and non-RC releases now after #3249, and we push from the RC branch to the non-RC branch to create a stable release? If this is the case, I definitely misunderstood)

Is there a specific reason for including this PR in v23.9 and the further updates in the next one? Both, this PR, as well as other updates can be included in the next release, right?

No, I don't have any specific reason as such. The follow-up issues and PRs required after this will neither be security/bug fixes as you mention, nor can an estimate be provided on how much time they would take to complete. So I agree that both the changes in this PR plus the follow-ups should make it to the next release, i.e., v24.1rcX and subsequently to v24.1.

This will/can be merged before the non-RC but into develop and not the release branch. I'd prefer to keep this for the next release.

Yes, this should be good (assuming that the release workflow I wrote about in the above paragraphs is correct).

I might have misphrased what I was intending to say, however. To clarify, #3462 is about building wheels for more platforms and can be worked upon as a standalone issue as well. I can start working on that soon: if a PR for it gets completed in time and the wheels work without issues, it would be good for them to make it into the v23.9 release itself— users on those platforms would then be able to install v23.9 from pip using those wheels and would not have to wait until the v24.1rcX or v24.1 releases, which are many months away at this time. Of course, building wheels is not a security issue or a bug that needs fixing but rather a packaging feature, but it would be a good feature to add in this case. In any case, I will open a PR and try to work it to completion, just that it would be your choice to merge.

I thought we were merging develop into main and adding a git tag on a commit on that branch to create a release.

The v23.9 branch will be merged into main to create the final release. Merging PRs in develop will not affect the final release in any way. Any bug/security fix that is required in the final release should be merged into develop (like other PRs) and then cherry-picked to the release branch (v23.9).

Of course, building wheels is not a security issue or a bug that needs fixing but rather a packaging feature

Yes, that sounds like a feature. It would be better to include that in the next release!

Makes sense, thanks for the explanation!

@agriyakhetarpal could you merge develop? I was waiting for the release, but now that it is out, we should merge this as soon as possible

@agriyakhetarpal could you merge develop? I was waiting for the release, but now that it is out, we should merge this as soon as possible

Done. Since I am targeting some installation issues, improvements, and documentation in the coming time—it should be fine to merge once @kratman can review (a gentle reminder!)—I can add a minimal test to check for the IDAKLU solver during the cibuildwheel steps, but I think it would be better to do that in a follow-up PR since this is already very big.

I have disabled the wheel building on PRs like it always was and have triggered a final run on my fork, here is the link: https://github.com/agriyakhetarpal/PyBaMM/actions/runs/6935629522

I will download the wheels and test them as well.

@arjxn-py has previously tested ans confirmed on WSL and Windows (amd64). We don't have arm64 wheels yet, so another test on a native Linux machine should be great and would suffice for the most part

I will download the wheels and test them as well.

@arjxn-py has previously tested ans confirmed on WSL and Windows (amd64). We don't have arm64 wheels yet, so another test on a native Linux machine should be great and would suffice for the most part

I am testing Linux Mint with x86_64 right now. Should be able to let you know if it works in a couple minutes

Works on my Linux machine

Merging this, I hope everything works fine!

So glad to see the purple UI elements now, thanks a ton to everyone who helped me out!


We need to test iOS with just bluetooth

Right now we only test with bluetooth and wifi on (but wifi not connected to an access point). We really should run tests with just bluetooth and no wifi.

This is a nice to have. We officially are only testing WiFi + Bluetooth for MPCF.


Print outerHTML when passing an Element to IO.inspect/2

Addresses #266
When passing a Wallaby.Element to IO.inspect/2, the elements outerHTML will be printed along with the normal representation of a struct, like so:

I would like some feedback on a few things:

Where is the best place to define the Inspect implementation?
Keep/change/throw out the coloring?
Is the format alright?
Should we request the outerHTML data when running inspect, or should the outerHTML be added to the Wallaby.Element struct itself?

Thanks!
cc/ @keathley @knewter @nathanl

Your code and the results look great to me! 👏 😄

Should we request the outerHTML data when running inspect, or should the outerHTML be added to the Wallaby.Element struct itself?

I don't know the best answer to this part.


Cannot specify an empty array in the Plugins section of appsettings.json

Given the following appsettings.json:
{
  "Plugins": [ ]
}

GetPluginFiles method throws an InvalidOperationException even though the section exists.
The exception should not happen because in reality the "section" does exist in the json file.

This problem is not related to CPlugin.Net.
See,

https://github.com/dotnet/extensions/issues/1341
https://github.com/dotnet/runtime/issues/58104


fixes for issues discovered during verification process

@JamesMBallard please review/merge. Fixing up a few small issues that Kathleen found:

changing screenshot size
fixing up readme numbering
making the listview not have hardcoded height to ensure all checkboxes show

@JamesMBallard good catch, I missed transporting over a few of those properties. Border, radius, and opacity now applied. Thanks


Docs: explain Dask concepts and Catalog representation better

From lincc-lsdb slack channel, Gregory Dubois-Felsmann asked how do we get list of the columns for a catalog and highlighted that docs are not really helpful in discovering Catalog.columns attribute
It turns, that the real issue Gregory had is in understanding that read_hipscat() loads metadata only and what is actually shown when we run display(catalog) in Jupyter.

It is basically this https://github.com/astronomy-commons/lsdb/issues/129 issue, that we closed... I guess more documentation improvements, but this would not help in this particular workflow that he described.

It's a bit more complicated than that.  It was really a combination of the two, and a couple of other little details that add up to a workflow for someone who's new to a dataset being a little un-obvious -- and it isn't explored explicitly by the existing tutorials.
If you don't know what the columns are, you probably want to examine the schema of the dataset first.
A number of the current demos start with something like:

lsdb.read_hipscat(ztf_object_path, columns=["ps1_objid", "ra", "dec"])

But a natural workflow for a newcomer to a dataset often is:

Find out what columns are available
Decide what columns are appropriate for an analysis job
Start setting up the query

So those people will want to do:

zcat = lsdb.read_hipscat(ztf_object_path)
Look at the columns available in zcat and make a decision
zcat = lsdb.read_hipscat(ztf_object_path, columns=["ps1_objid", "ra", "dec"])

There's something about the way the tutorials are organized that made it less than obvious to me that that's what I needed to do.
I wonder if a more natural workflow would replace 3. with something like a zcat.limit_columns(["ps1_objid", "ra", "dec"]) -- perhaps you already have something like that available?

When it comes to finding out about the columns themselves, it wasn't all that easy to figure out about having to use both the .columns and .dtypes attributes, and how to use what comes back from .dtypes.  The return types from a lot of these operations are fairly obscure and multiply layered, so it's not easy to explore the reference documentation to figure this out in the absence of tutorials.  I did eventually get there after a fair amount of guessing and hitting '.' and Tab on various objects.
I found myself looking for some sort of get_schema() method that would have returned, perhaps, a list or dict of columns, with a dict with a number of attributes for each column (which might expand from just name and type to include descriptions, units, UCDs, etc. in the future).


add cross_spectra_core.py

The goal of this PR is to provide xsarsea users the capability to compute cross spectrum from Sentinel-1 SLC products.
The core the algorithm is provided by @lanougue.

[ ] fix x not declared in compute_SAR_cross_spectrum2()
[x] validation output wrt to original notebook provided
[ ] see what to do with slc.synthetic_duration
[ ] discuss normalization of the cross spectrum
[ ] investigate the NaN values at the edge of the cross spectrum matrices
[ ] add unit test to be sure the code return the same cross spectrum than original notebook
[ ] test co spectrum computation from GRD tiff image using the same function.
[ ] add option to pick up something else than VV polarization

benchmark
time to get all X-spectra on WV with N_look:3 look_width 0.25 look_overlap 0.0 nperseg 512x512  noverlap 256x256 : 39.70 seconds

validation output cross spectra real part from original code using PIL and the output of xsarsea using xsar reader:

expected output from xsarsea.compute_SAR_cross_spectrum2:

a first test with a GRD IW sub image 0:5000 pixels in range and azimuth and 0-tau (ie co spectra):

precision: The scope of this PR is only cross spectrum from WV SLC product.
A TOPS SLC cross spectrum PR will be open soon.


dpm solver v3 in diffusers?

Can we use the dpm solver v3 in diffusers?

Thanks for your interest in DPM-Solver-v3! We have not integrated it into diffusers, since it requires pre-computing the EMS for each pretrained diffusion model. But we do have such a plan in one or two months. Currently, we already provide the code examples which can be used in the research community.


Weird error: "expecting is not a supported rule"

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Ensure autosave is ON, make a new Dockerfile.
Start typing this:

FROM node:latest
WORKDIR

(Note: WORKDIR has a space after it.)
3. A notification should appear: hadolint: expecting is not a supported rule
Expected behaviour
Okay, so an empty "WORKDIR" is nonsense, but I would not expect the hadolint extension to be worrying about it, let alone throwing a cryptic notification.
Screenshots or Dockerfile
FROM node:latest
WORKDIR

(Note: WORKDIR has a space after it.)

...and if I pop open the Help->Developer Tools window, I got this in the JS Console:

Environment and version (please complete the following information):

hadolint:

> hadolint --version
Haskell Dockerfile Linter UNKNOWN

(but actually it's 2.8.0 -- there's an issue logged about the --version output already.)

OS: Windows 10.0.19042 Build 19042

Debug information
I tried running the same command that the extension output log said it was running:
> hadolint C:\Users\alan\repos\redacted\buggy.Dockerfile --no-color
C:\Users\alan\repos\redacted\buggy.Dockerfile:2:9 expecting the workdir path

From my naive understanding, it appears like maybe the extension is expecting rule-style (DLXXXXX....) output strings all the time and not handling those few error messages that don't have a rule to them.
Additional context
This issue looks related to #46 and #55.

I should perhaps add that due to #42 even after closing the buggy file, hadolint continues to haunt my notification corner over the file it can't parse right.

I have kind of the same error:

> hadolint /home/demarteaub/projects/infra/docker/postgres/patroni/Dockerfile
/home/demarteaub/projects/infra/docker/postgres/patroni/Dockerfile:79:5 unexpected '&' expecting '#', '\', ADD, ARG, CMD, COPY, ENTRYPOINT, ENV, EXPOSE, FROM, HEALTHCHECK, LABEL, MAINTAINER, ONBUILD, RUN, SHELL, STOPSIGNAL, USER, VOLUME, WORKDIR, a pragma, at least one space, or end of input

> hadolint --version
Haskell Dockerfile Linter 2.12.0

I had the same error as @bendem - any plans to fix it? @michaellzc

same issue @michaellzc


fix(Swapping): get rid of side effects

We were misusing unexpected side effects in the SDK's executeRoute method. We should use the reference to the initial route object but instead use the updated version provided by the updateRoute callback.
This PR is missing the same fixes for SwappingCarbonOffset.tsx and SwappingEtherspotKlima.tsx but I want to make sure the SDK fixes in https://github.com/lifinance/sdk/pull/62 actually work as expected.

I have converted this to a draft PR because of the needed changes in SwappingCarbonOffset.tsx and SwappingEtherspotKlima.tsx. I'll go through the changes once the Etherspot showcases have been organized and cleaned up and apply them to the needed files


[Bug]: cbuild return exit status 0xc0000409 on windows using cygwin

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
cbuild.exe from a fresh install of cmsis toolbox 2.2.1 on a windows10 machine is failing with 0xc0000409 error code.
Does not appear to be related to specific project, but seeing it initially with this one:
https://github.com/FabKlein/Arm-2D/blob/cde_experiments/csolution/arm2d.csolution.yml
$ cbuild list contexts arm2d.csolution.yml
error cbuild: exit status 0xc0000409

Expected Behavior
On Linux, I'm having the expected context list
>> cbuild list contexts arm2d.csolution.yml
/projects/iot/pj03124_ecps/fabkle01/git/forks/Arm-2D/csolution/arm2d_generic_bench/arm2d_generic_bench.cproject.yml:49:14 -
arm2d_generic_bench.Release+VHT-Corstone-300
arm2d_generic_bench.Release+VHT-Corstone-300-NOLCD
arm2d_generic_bench.Release+VHT-Corstone-300-NOLCD-CDE
arm2d_generic_bench.Release+VHT-Corstone-310
arm2d_generic_bench.Release+VHT-Corstone-310-NOLCD
...

Steps To Reproduce

clone the project:
https://github.com/FabKlein/Arm-2D

checkout the cde_experiments branch

go into csolution folder

install the required packs (cmsis6/cortex-dfp etc..)

run cbuild list contexts arm2d.csolution.yml

Affected tools

[X] cbuild
[ ] cbuild-gen
[ ] cpackget
[ ] csolution
[ ] packchk
[ ] svdconv

Affected operating systems

[X] Windows amd64
[ ] Windows arm64
[ ] Linux amd64
[ ] Linux arm64
[ ] MacOS amd64
[ ] MacOS arm64

Environment
Windows 10 Enterprise, version 10.0.19044

few updates after debug session with @soumeh01:

Issue might be related to cygwin
cohabitation of MDK generated RTE files with cbuild (running from a cygwin terminal) is causing this 0xc0000409 issue
starting from a fresh git cloned environment, without RTE generated content, allows the process to go further, but then it get stucks while executing following command.
cmake -G Ninja -S "D:\projects\Arm-2D\csolution\arm2d_smartwatch_bench.Release+VHT-Corstone-300-NOLCD-AC6\intdir" -B "D:\projects\Arm-2D\csolution\arm2d_smartwatch_bench.Release+VHT-Corstone-300-NOLCD-AC6\intdir" -Wdev
This is using cygwin cmake / ninja
if I do the same using windows installed cmake/ninja, the the build process go to completion

@FabKlein could you please share the versions of cmake and ninja used in cygwin? Is it the same versions you are using when running using windows installed cmake/ninja:
Note: you can run cbuild list environment to see the cmake and ninja version being used.

ARM+fabkle01@S4DU2464 ~/git/fork/Arm-2D/csolution
$ cbuild list environment
CMSIS_PACK_ROOT=C:/Users/fabkle01/AppData/Local/Arm/Packs
CMSIS_COMPILER_ROOT=C:/Keil_v5/cmsis-toolbox-windows-amd64/etc
Long pathname support=enabled
cmake=C:\cygwin64\bin\cmake.exe, version 3.25.3
ninja=C:\cygwin64\bin\ninja.exe, version 1.11.1

Nothing unusual there.

We don't claim to support the cygwin environment.
Should we make the list of supported/tested environments clearer in our documentation.
@FabKlein I hope this is not a show stopper for you. Do you have alternatives to cygwin?
Are you happy to close the issue?

This was only a sporadic window trial. Everything is OK on unix-like environments so happy to close the issue


STT accuracy is very bad when using a stream compared to a .wav file

Describe the bug
I'm getting a much lower STT accuracy when using AudioConfig.FromInputStream() than I do with AudioConfig.FromWavFileInput()
I pass the same file to both methods and get drastically different results.
To Reproduce
Steps to reproduce the behavior:

Create an AudioConfig from a wav file by passing in the file path
Create an AudioConfig from an input stream by passing in a PullAudioInputStream(new BinaryAudioStreamReader(new BinaryReader(audio))))
Pass each AudioConfig to the recognizer
Compare the results

Expected behavior
Exact same text results given the same input file regardless if it comes from a file or a stream.
Version of the Cognitive Services Speech SDK
1.15.0
Platform, Operating System, and Programming Language

OS: MacOS Big Sur 11.2
Hardware - ARM M1
Programming language: C#
Browser: Edge Version 90.0.782.0 (Official build) Dev (64-bit)

Additional context

@aditmer Sharing the discussion which we had on emails which was that the wave file you were using was stereo but configuration was assuming mono (default). Did you managed to get it working by configuring pull audio stream to stereo ?
using (var audioInput = AudioConfig.FromStreamInput(new PullAudioInputStream(new BinaryAudioStreamReader(
new BinaryReader(audio))), AudioStreamFormat.GetWaveFormatPCM(16000, 16,2)))
Alternatively you could use mono wave file.
Closing the issue.


"The type initializer for 'SkiaSharp.SKAbstractManagedWStream' threw an exception." occuring if QuestPDF library published in Docker container.

Hello. I am trying to use the QuestPDF library with docker container.
If i try to send a request via Postman, the following exception was occured:
"The type initializer for 'SkiaSharp.SKAbstractManagedWStream' threw an exception."

Dockerfile
FROM mcr.microsoft.com/dotnet/sdk:6.0-focal as build
WORKDIR /src
RUN apt-get update && apt-get install libfontconfig1 -y
COPY . .
RUN dotnet restore "./DataExportService.csproj"
RUN dotnet publish "./DataExportService.csproj" -c Release -o /app --no-restore
FROM mcr.microsoft.com/dotnet/aspnet:6.0-focal
WORKDIR /app
COPY --from=build /app ./
EXPOSE 5000
ENTRYPOINT ["dotnet", "DataExportService.dll"]

Is it possible to suppress this error and make the container work correctly? Thanks.

Hello again. I managed to solve the problem myself. Below you will find the updated Dockerfile.
FROM mcr.microsoft.com/dotnet/aspnet:6.0-focal AS base
WORKDIR /app
RUN apt-get update && apt-get install -y ttf-mscorefonts-installer fontconfig libc6 libc6-dev libgtk2.0-0 libnss3 libatk-bridge2.0-0 libx11-xcb1 libxcb-dri3-0 libdrm-common libgbm1 libasound2 libappindicator3-1 libxrender1 libfontconfig1 libxshmfence1
RUN chmod 777 .

FROM mcr.microsoft.com/dotnet/sdk:6.0-focal AS build
WORKDIR /src
COPY ["DataExportService.csproj", "DataExportService/"]
RUN dotnet restore "DataExportService/DataExportService.csproj"

WORKDIR "/src/DataExportService"
COPY . .
RUN dotnet build "DataExportService.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "DataExportService.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DataExportService.dll"]

Additional info:
Also you need to specify a supported font in the document
page.DefaultTextStyle(x => x.FontFamily(Fonts.Arial));


Versioneer code in the repo will not work with 3.12 python.

SafeConfigParser that versioneer uses was removed with 3.12 python release so installation from source code will not work.

https://github.com/python-versioneer/python-versioneer/issues/375

The versioneer issue is resolved, but an old versioneer is vendored here. Upgrade with pipx run versioneer install.
See https://github.com/python-versioneer/python-versioneer/blob/master/UPGRADING.md for any migration issues.

The versioneer issue is resolved, but an old versioneer is vendored here. Upgrade with pipx run versioneer install.
See https://github.com/python-versioneer/python-versioneer/blob/master/UPGRADING.md for any migration issues.

Everything in this repo is written by  me - except versioneer - and i applied the fix with this patch. Rest can stay as-is as nobody wont be updating this project anyway


Feat add codemod check to doctor package

Remove codemod CLI usage.
Add codemod check and fix reports to scan.
Result:

interface ICodemodReports {
  score: number;  // 根据可运行的 codemod severity 进行扣分，1 时 -2 分，2时 -5 分
  output: string; // 运行codemod 时控制台的输出，便于上层显示
  reports: Array<{
    transform: string;
    title: string;
    message: string;
    severity: 0 | 1 | 2;
    docs: string;
    'npm-deprecate'?: string;
  }>
}

Before https://github.com/appworks-lab/codemod/pull/1

@appworks/codemod 还没发包 Ci 挂掉 符合预期。
@appworks/codemod  PR : https://github.com/appworks-lab/codemod/pull/1

Codecov Report

Merging #870 (79bc0a0) into release/1.2.0 (f4b2258) will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           release/1.2.0     #870   +/-   ##
==============================================
  Coverage          57.14%   57.14%
==============================================
  Files                  1        1
  Lines                 70       70
  Branches              15       18    +3
==============================================
  Hits                  40       40
  Misses                30       30

Continue to review full report at Codecov.

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


[FEATURE] Able to reach to function_call in result

As some of the models support functions that result with function_call property in the result, I would like to reach it when I send a request to the Flowise prediction endpoint.
Right now Flowise API responses have JSON format but it only includes the text field. I would like to get function_call in addition on this.

FYI: Function call is updated with tools
PS: It would be nice to consider json mode

@emrahtoy the API response now includes a property usedTools which are the tools/functions used by agent:

Awesome @HenryHengZJ, just in time!


pull request for e2e test at 01/29/2017 10:45:10

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Move blog/news to index page

On our page, we have a nice blog feature where we announce workshops, updates about the website, the Alps transition and so on. However, it is not visible at first sight since the starting page is the info about the C2SM Core Team.
With this PR I suggest to have the News on the starting page. Feedback is very welcome 🙂

Thanks @AnnikaLau!
I don't know if it is possible to make the posts collapsible. At least I didn't find such a settings.
What we can do however is to add <!-- more --> to all posts (most of them have it already) so that only the first paragraph of each post is visible on the home page.
Otherwise, there is already an overview of all posts on the right sidebar, and on the left by clicking on "Posts".

one question:
Will the link I posted recently for IUW still be valid?

one question: Will the link I posted recently for IUW still be valid?

Did you reference to the news post? In your email, there is only this (which is still valid): https://c2sm.github.io/events/CIUW/2024/

@jonasjucker If you have posted the news link already, you have to replace it after the merge. New link:
https://c2sm.github.io/2024-11-26-icon-user-workshop-formerly-cosmo-icon-user-workshop/


⚠ Bofrost.be has degraded performance

In 8f2cbf6, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1747 ms

Resolved: Bofrost.be performance has improved in b1fdef2 after 56 minutes.


what is p module?

Traceback (most recent call last):
File "svg2ico.py", line 30, in
import P
ModuleNotFoundError: No module named 'P'

This script is a draft. "P" it was an external library writter for tests.


Image flashes after component mounts

What are you doing to avoid image flashes after element mounts?
That's how I using it. After image loads, I change state to mount child component which contains same image. But image doesn't appears instantly, it looks like it's loading again, it renders progressively. (tested in chome and ff) Do you have any ideas why it may happens?
this.state = {
  imagesLoaded: false
}

...

_handleImageLoadSuccess = () => {
  this.setState({
    imagesLoaded: true
  })
}

...

<Preload
  loadingIndicator={
}
  images={[imageUrl]}
  onSuccess={this._handleImageLoadSuccess}
  mountChildren={imagesLoaded} >
    <div className='my-image' style={{backgroundImage: `url(${imageUrl})`}}>

</Preload>

May be it's problem on my server side..
Could you please publish working examples? I saw examples folder but it seems to be not ready yet

my bad.
this behavior was due to my server config


lua_call is not found

Why there isn't the lua_call method?

Why there isn't the lua_call method?

hi !
look at https://github.com/au-top/dart_lua_ffi/blob/da70638c10099ddf444f37e31768fdd9dcc3f34e/c_header/lua.h  in  283 line
LUA_API void  (lua_callk) (lua_State *L, int nargs, int nresults,
                           lua_KContext ctx, lua_KFunction k);
#define lua_call(L,n,r)		lua_callk(L, (n), (r), 0, NULL)

function lua_call(L,n,r) api  is lua_callk(L, (n), (r), 0, NULL)

Thank you!


library not working on Internet Explorer

Hello, may you kindly give me the version of Internet Explorer that the calendar does not work on?
Thanks in advance.

<div appears blank on IE version: 11.125.16299.0 update version: 11.0.49 (KB4052978) Product ID: 00150-200000-00003-AA459


Explicitly mark readouts that are not implemented

This is probably a controversial change. The idea behind this is to make it more obvious, which readouts/functions are supported in the corresponding targets.
Advantage: It is easier to determine which functions are implemented for a specific target and what might need to be added in the future.
Disadvantage: It might seem messier to have all those ReadoutError::NotImplemented.

❗ Important: I did not yet make the change in the entire library and it therefore does not compile yet. I want to gather some feedback if this is even something that would be accepted, before I finish this work.

How this is any different from:
    static ref STANDARD_NO_IMPL: ReadoutError = ReadoutError::Warning(String::from(
        "This metric is not available on this platform or is not yet implemented by macchina."
    ));

The PR is titled "explicity mark readouts that are not implemented", but by default, any unimplemented functions are going to result in ""This metric is not available on this platform or is not yet implemented by macchina.", which achieves the same goal as what you're trying to do, but with more lines of code. For an end user (developer), there is no noticeable change.

The difference is that my suggestion is 'explicit' while the current implementation is 'implicit'. In the current implementation you have to know which functions any specific readout offers and compare it with the functions that you have actually implemented. You don't see immediately, what functionality is not implemented.
For me these are two different answers to the following question:
"When do I want to realize that I forgot to implement a function?"

Current implementation: I most likely realize it when I run macchina and the readout does not appear.
This PR: I realize during coding when I get an error that I did not implement the function.

You don't see immediately, what functionality is not implemented.

Your point is solid, let's see what the others think.
@uttarayan21
@123marvin123

I think this is a good change, I always try to be explicit with errors and seems like this might be useful when debugging readouts.

In the current implementation you have to know which functions any specific readout offers and compare it with the functions that you have actually implemented.

Yeah, resulting in a lot of wasted time.

Great, I will continue working on this, since your feedback seems to be mostly positive.
I have one more question that would make it easier for me: could we make the GitHub Workflow of this repository more like the one in macchina where we test every possible target? This would give me (or any other contributor) more confidence that I didn't screw something up while refactoring.

could we make the GitHub Workflow of this repository more like the one in macchina where we test every possible target?

Sure, I'll make this happen.

You don't see immediately, what functionality is not implemented.

Your point is solid, let's see what the others think.
@uttarayan21 @123marvin123

I think its a good change 👍🏼

If you've noticed, a lot of our documentation is written for implementors, but we've yet to see anybody implement on top of libmacchina, we should write documentation that explains how to use the functions and their expected output.
This is a topic for another day, though.

I noticed that too.
For this pull-request I will implement the missing functions in the documentation examples, but I agree that the examples should rather target the users than those that implement readout traits.

Something's up with the crates.io API :(

Yes, apparently they are experiencing an outage.

We should refrain from pushing until they can recover, we don't want to be stressing their servers at this moment.

According to their incident report, the issue should be resolved.
Can you trigger the CI pipeline again?

According to their incident report, the issue should be resolved. Can you trigger the CI pipeline again?

Right away ;)

We're set! You've done an outstanding job @FantasyTeddy :heart:

Thank you, glad I can help :)


Missing CLI option for specifying a different port number

I see that the roadmap includes an idea to provide a CLI option to specify a port number different than 3000. If I created a PR would it be useful?

Indeed :)

I'm on it 😄


Update the runtime image to Alpine 3.10

erlang:22-alpine, the base image for elixir:1.9-alpine, was updated to Erlang 22.1 and Alpine 3.10 on September 17th.
https://github.com/erlang/docker-erlang-otp/commit/daa8c85d275ac3b555f7bdadc8c5df24bc6a75a0
We are packaging the OTP release for 3.10, so we need to update the runtime Alpine image to 3.10 too!

🦀 Requesting reviewers for this pull request:

@remiprev (contributor with 6 commits in the last 90 days and 148 commits overall)
@Boubalou (expert reviewer for the elixir stack)


All-data-structures-in-c

#37
I have added All Data Structures in C. I request you to accept my PR.

@RekhaGiri Follow code of conduct by Star the Repo and all the rules in README.md


Modeling Hand-Object Contacts

I am currently working on whole body manipulation in contact-rich scenarios in Crocoddyl. I have noticed that in all examples, there is just one robot in the environment, and the contacts are between the feet of the robot and the ground. I am curious about Crocoddyl's capability to model contacts between the robot and objects. For example, there is a table on the environment, and some objects are placed on the table. If the task involves the robot grasping an object from the table, I can load the URDF files for both the table and the objects.  My question is, how do I model the contacts between the robot's hands and the object? This includes defining the state, actuation, and contacts, etc. Any guidance would be helpful. I really appreciate that.

Let's keep this conversation private.


Last Week in Pony - October 8, 2023

Version 0.1.5 of ponylang/peg has been released.
See the release notes for more details.

Version 0.1.3 of ponylang/github_rest_api has been released.
See the release notes for more details.

Version 0.2.4 of ponylang/templates has been released.
See the release notes for more details.


clipped rounded icon on Ios

I have this problem on Ios, on Android its work fine
When i insert rounded icon, it has bottom clipped part
Can someone help me?
http://joxi.ru/LmGMeENCR8ve7A

here my code

{this.state.active === el ?
<CustomIcon
color={Colors.textBlack}
size={15}
name={'check'}/>
: null
}

checkWrap: {
    position: 'absolute',
    top: 0,
    left: 0,
    height: 60,
    width: 40,
    justifyContent: 'center',
    alignItems: 'center'
}

Same error +1

Hopefully this is fixed in modern RN, if not comment and I'll reopen and investigate


Review

Once I got over the image of spaghetti coming out of Will Smith's eyes, I must ask  what pasta are we talking about? If it's carbonara I am giving extra point.  I liked it, good job.

I almost forgot about those AI generated videos of Will Smith eating spaghetti. Nightmares guaranteed tonight.


Fix requests for invalid certificates

Hi!
We are having some problems with this library in OnPremise CARTO instances with invalid certificates and without the chance of use http, only https.
For fixing this, the APIKeyAuthClient class should have a verify (or something like that) attribute that refers to the verify parameter in requests. We'll need to propagate this change to BasicAuthClient, also for setting the using of the verify parameter in the send method.
We can do that couple of PRs, but we need to now why you convert every boolean to a string here, because the verify parameter needs to be a boolean.
Regards.

Hi!
the boolean to string conversion was because of this issue but yes, I think that's not the right place to do it since it's breaking the boolean support in requests
Let me see how to fix that without breaking anything. You can assume the boolean conversion will not exist in case you want to provide the PRs (will be very appreciated BTW ;) )
Thanks!

Currently preparing a PR for this

Awesome, we'll check it and prepare the code for inserting the verify parameter in another PR(s).

Thanks but it's not necessary, everything comes in #60
Do you mind reviewing?

BTW I found a workaround, it's not necessary to wait for the next release, just pass a proper session instance to the auth client:
import requests
session = requests.Session()
session.verify = False

APIKeyAuthClient(the_url, the_api_key, session=session)

Hope it helps!


feat(ci): enforce conventional-commits

Closes #180
I didn't use an action from the marketplace, because they all use GITHUB_TOKEN which isn't working with forks.
We can speed things up by creating a bundle with the node modules already in it to avoid the npm i phase in the action.
I thought it was an overkill since this runs much faster than the tests.

@YonatanKra , were you able to check that your solution works on Github?
What shows up to the user and when after they try to squash&merge with a message not conforming to conventional commits?
Are all of the types from commitizen supported?

@czerwinskilukasz1
This works according to these rules: https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional
As written on this page, they can be changed (for instance, don't enforce lowercase).
@mhagmajer
What my solution is doing is not passing the PR if its title is not according to the standard. It's a linter for the PR title. Eventually, the PR title is used for the actual commit, so this should solve the issue, isn't it?

@czerwinskilukasz1
This works according to these rules: https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional
As written on this page, they can be changed (for instance, don't enforce lowercase).

Sounds good to me, thanks.


Allow base64 images

Hi,
I would like to have base64 images, so I changed the allowedSchemes.
allowedSchemes    : $w('http https mailto github-windows github-mac data'),

I would recommend to enable this for everyone using this module. What do you think?

This module is designed to replicate exactly what github sanitizer does.
And github doesn't allow data uri, probably for this reason:
[click me](data:application/javascript,alert('XSS'))

This makes sense. Thanks.


Type dialog cannot be accepted if a type is actively parsing

Because the accept button is disabled while user input is being parsed, this forces the user to pause and wait for parsing to finish before they may accept the dialog.

Fixed in build 2835.


Update CAPI secret mechanism to supported method

User Story
As a developer/user/operator I would like to ensure that the secret authentication method for CAPI is utilizing the current supported method.
Detailed Description
The current method the operator helm chart uses to install is the deprecated use of environment variables.

clusterctl init
create k8s secret with creds
refer to the secret via AzureClusterIdentity ref in AzureCluster

Is the current supported way to authenticate and should be reflected by default in the installation process.
/kind feature

@dtzar I followed CAPI quickstart guide and was able to deploy CAPZ with the operator. I think it should be good from the operator side, what users have to do is:

Deploy operator with CAPZ as infra provider, no credentials secret required for it.
Create a k8s secret to be used with AzureClusterIdentity.
Create AzureClusterIdentity.
Create AzureClusters that reference it.


How to align 2 column text?

Hi;
I am trying to display a list of menu items like in the picture:

Data is justified in the db. If I do not use attributed string, it displays justified.
If I use attributed string, it displays like in the picture above.
What is the best way to do it with attributed string?
My code is:
NSAttributedString *attrString = [[NSAttributedString alloc] initWithString:finalStr attributes:@{
                                                           NSFontAttributeName : [UIFont fontWithName:fontFace size:23]
                                                            }];

    [itemDescriptionLabel setAttributedText:attrString];
    itemDescriptionLabel.font = [UIFont fontWithName:fontFace size:23];
    itemDescriptionLabel.lineBreakMode = NSLineBreakByWordWrapping;
    [itemDescriptionLabel setAttributedText:attrString];

This section of the documentation might help:

Never assign to the attributedText property.

If you think there is a bug, please review the contributing guidelines for advice on writing a good issue.
If you're not sure whether it's a TTTAttributedLabel bug, or if it's a usage question, please ask on Stack Overflow first.


Specific Character Run History Is Bugged

If you want to look at past runs in the Run History for Wanderer, in the tab where you pick the specific character to look at, you have to pick CULL to look at old Wanderer runs and vice versa.

Ok, seems to be a bit different than I thought:
The Wanderer character selection only shows CULL runs.
The CULL character selection shows all runs that I have played.

This appears to have been fixed. Not sure when exactly. Please reopen if incorrect.

This appears to have been fixed. Not sure when exactly. Please reopen if incorrect.