pip install error installing example dependencies

Describe the bug
I ran pip install -r requirements.txt in the examples folder and got the following error:
Collecting osqp>=0.6.2
Downloading osqp-0.6.3.tar.gz (228 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 228.4/228.4 KB 16.0 MB/s eta 0:00:00
Installing build dependencies ... error
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> [113 lines of output]
Collecting oldest-supported-numpy
Downloading oldest_supported_numpy-2023.10.25-py3-none-any.whl (4.9 kB)
Collecting setuptools>=40.8.0
Downloading setuptools-69.0.2-py3-none-any.whl (819 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 819.5/819.5 KB 5.0 MB/s eta 0:00:00
Collecting wheel
Downloading wheel-0.42.0-py3-none-any.whl (65 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 65.4/65.4 KB 7.1 MB/s eta 0:00:00
Collecting setuptools_scm>=6.2
Downloading setuptools_scm-8.0.4-py3-none-any.whl (42 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 42.1/42.1 KB 5.8 MB/s eta 0:00:00
Collecting qdldl
Downloading qdldl-0.1.7.post0.tar.gz (70 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 71.0/71.0 KB 10.8 MB/s eta 0:00:00
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Installing backend dependencies: started
Installing backend dependencies: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'done'
Collecting numpy==1.21.6
Downloading numpy-1.21.6-cp310-cp310-macosx_11_0_arm64.whl (12.4 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 12.4/12.4 MB 38.6 MB/s eta 0:00:00
Collecting packaging>=20
Using cached packaging-23.2-py3-none-any.whl (53 kB)
Collecting tomli>=1
Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
Collecting typing-extensions
Using cached typing_extensions-4.9.0-py3-none-any.whl (32 kB)
Collecting scipy>=0.13.2
Downloading scipy-1.11.4-cp310-cp310-macosx_12_0_arm64.whl (29.8 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 29.8/29.8 MB 48.6 MB/s eta 0:00:00
Building wheels for collected packages: qdldl
Building wheel for qdldl (pyproject.toml): started
Building wheel for qdldl (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error
    × Building wheel for qdldl (pyproject.toml) did not run successfully.
    │ exit code: 1
    ╰─> [65 lines of output]
        running bdist_wheel
        running build
        running build_ext
        Traceback (most recent call last):
          File "<string>", line 81, in build_extensions
          File "/Users/davidarbirk/miniforge3/lib/python3.10/subprocess.py", line 420, in check_output
            return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
          File "/Users/davidarbirk/miniforge3/lib/python3.10/subprocess.py", line 501, in run
            with Popen(*popenargs, **kwargs) as process:
          File "/Users/davidarbirk/miniforge3/lib/python3.10/subprocess.py", line 966, in __init__
            self._execute_child(args, executable, preexec_fn, close_fds,
          File "/Users/davidarbirk/miniforge3/lib/python3.10/subprocess.py", line 1842, in _execute_child
            raise child_exception_type(errno_num, err_msg, err_filename)
        FileNotFoundError: [Errno 2] No such file or directory: 'cmake'

        During handling of the above exception, another exception occurred:

        Traceback (most recent call last):
          File "/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/tmp_isdzniu_in_process.py", line 363, in <module>
            main()
          File "/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/tmp_isdzniu_in_process.py", line 345, in main
            json_out['return_val'] = hook(**hook_input['kwargs'])
          File "/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/tmp_isdzniu_in_process.py", line 261, in build_wheel
            return _build_backend().build_wheel(wheel_directory, config_settings,
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/build_meta.py", line 404, in build_wheel
            return self._build_with_temp_dir(
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/build_meta.py", line 389, in _build_with_temp_dir
            self.run_setup()
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/build_meta.py", line 311, in run_setup
            exec(code, locals())
          File "<string>", line 113, in <module>
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/__init__.py", line 103, in setup
            return distutils.core.setup(**attrs)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 185, in setup
            return run_commands(dist)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
            dist.run_commands()
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 969, in run_commands
            self.run_command(cmd)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/dist.py", line 963, in run_command
            super().run_command(command)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
            cmd_obj.run()
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/normal/lib/python3.10/site-packages/wheel/bdist_wheel.py", line 368, in run
            self.run_command("build")
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
            self.distribution.run_command(command)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/dist.py", line 963, in run_command
            super().run_command(command)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
            cmd_obj.run()
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/command/build.py", line 131, in run
            self.run_command(cmd_name)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/cmd.py", line 318, in run_command
            self.distribution.run_command(command)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/dist.py", line 963, in run_command
            super().run_command(command)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 988, in run_command
            cmd_obj.run()
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/command/build_ext.py", line 88, in run
            _build_ext.run(self)
          File "/private/var/folders/xp/9tpdfsb14h19rmvd1prj9d9h0000gn/T/pip-build-env-xs99b8zu/overlay/lib/python3.10/site-packages/setuptools/_distutils/command/build_ext.py", line 345, in run
            self.build_extensions()
          File "<string>", line 83, in build_extensions
        RuntimeError: CMake must be installed to build qdldl
        [end of output]

    note: This error originates from a subprocess, and is likely not a problem with pip.
    ERROR: Failed building wheel for qdldl
  Failed to build qdldl
  ERROR: Could not build wheels for qdldl, which is required to install pyproject.toml-based projects
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
Environment
(base) ➜  examples git:(main) marimo env
{
"marimo": "0.1.64",
"OS": "Darwin",
"OS Version": "23.1.0",
"Python Version": "3.10.4",
"Binaries": {
"Chrome": "120.0.6099.71",
"Node": "v18.7.0"
},
"Requirements": {
"black": "23.11.0",
"click": "8.1.7",
"jedi": "0.18.1",
"pymdown-extensions": "10.5",
"tomlkit": "0.12.3",
"tornado": "6.2",
"typing_extensions": "4.9.0"
}
}
Code to reproduce
pip install -r requirements.txt

Hi @arbirk, thanks for reporting!
It looks like pypi isn't able to find a wheel for qdldl, and your machine doesn't have cmake installed so the build fails. Probably because qdldl doesn't have a universal wheel for macOS.
I will follow-up with the qdldl maintainers elsewhere.

In the meantime, you can workaround this issue using the tip here: https://github.com/osqp/qdldl-python/issues/26

Closing as there is no action on our end


postgresql_14: fix build

Building postgresql_14 currently fails with this on master:
error: derivation contains an illegal reference specifier 'man'

The odd thing is, that changing anything in the postInstall phase seems to fix this, including just adding a single character as a comment.
I have no clue what's happening here.
I don't have too much time the next couple of days to investigate this.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@wolfgangwalther postgresql_14 builds for me on master
commit 87060a022a39438d025221bb6848fa2e4ffb113d (HEAD -> master, origin/master, origin/HEAD)
Merge: 083902dc0105 a36a61d30840
Author: nixpkgs-merge-bot[bot]<EMAIL_ADDRESS>Date:   Wed Dec 25 11:07:03 2024 +0000

    shopware-cli: 0.4.61 -> 0.4.62 (#367898)

[kirillvr@osaka:~/nixpkgs]$ nix-build -A postgresql_14
/nix/store/m9vb40xxr6gckjzpfxnqcmjqsks2gx03-postgresql-14.15

can you provide more info ? perhaps create an issue ?

[kirillvr@osaka:~]$ nix-info -m
 - system: `"x86_64-linux"`
 - host os: `Linux 6.12.6, NixOS, 25.05 (Warbler), 25.05.20241223.cde85e7`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.24.11`
 - nixpkgs: `/nix/store/a4x7j50qdyq62p31kw0n2p37xs94lb37-source`

also for me, it wasn't in a cache, i had to build it

try flakes
nix build github:nixos/nixpkgs/87060a022a39438d025221bb6848fa2e4ffb113d#postgresql_14

i get same output hash
[kirillvr@osaka:~/nixpkgs]$ ls -lah result
lrwxrwxrwx 1 kirillvr users 60 Dec 25 20:25 result -> /nix/store/m9vb40xxr6gckjzpfxnqcmjqsks2gx03-postgresql-14.15

 nix eval github:nixos/nixpkgs/87060a022a39438d025221bb6848fa2e4ffb113d#postgresql_14
«derivation /nix/store/bxp6g57limvwiga61vdlyvhy7i8rp6wd-postgresql-14.15.drv»

lolwat :sweat_smile:
Does this affect v14 only or other versions as well?
Is this a new thing? Because 2.91.1 exists for a while now.
Would prefer to spend a little more time to investigate this. I don't think I'll get to much during the holidays though.

The error is very odd, but rebuilding all postgresql versions on master would be relatively expensive, as labeled by CI.

Looking at https://hydra.nixos.org/eval/1810750?filter=postgresql_ – the darwin errors seem different, so I think only postgresql_14.x86_64-linux is affected.
I think it would be fine to merge this if conditional, e.g. for version 14 on any platform.

I'm doing a full bisect now.

working on nix 2.24.11 (kirillrdy)

I have the same build failure with nix 2.24.11 as well (both with and without flakes). No idea why it succeeded to build for @kirillrdy.

@wolfgangwalther have you tried pure build using flakes ? and do you still get same output hash as me ? or different ?

ok, so now I get same build failure, and I can not reproduce build using same nixos rev and nixpkgs rev :shrug:

I was able to fix the build with this commit: https://github.com/bendlas/nixpkgs/commit/a468e26caae2de75d7d7b15de30f2a146b7c5b0e
also relevant: https://github.com/NixOS/nix/pull/12105

c207a2becd4d89c5ffbadaed40e74bc6d64e128b is the first bad commit

It's an automatic merge.  I retested again that it really fails on this commit and succeeds on both parents.

Sometimes this happened when a sloppy regex was matching a part of the /nix/store hash.


Regression: Cross-compilation does not work after CC/CXX changes

Description
I noticed that my own cross-compiled binaries from https://builds.shipilev.net/async-profiler/ do not build cleanly anymore. In fact, there is a bug in Makefile, introduced by this hunk:
https://github.com/async-profiler/async-profiler/commit/3cf733d58970f8c130b659821e244150eef40ee8#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52R19
The problem is that CC and CXX are pre-defined in GNU Make: https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html. So, ?= does not work well: it never overwrites to $(CROSS_COMPILE)..., which results in binaries being compiled by host compiler, and only later strip discovers the binary format is wrong:
$ ARCH_TAG=aarch64 CROSS_COMPILE=/home/buildbot/deps/x-tools/aarch64-linux-gnu/bin/aarch64-linux-gnu- make clean release
rm -f -r build
mkdir -p build/bin
mkdir -p build/lib
for f in src/*.cpp; do echo '#include "'$f'"'; done |\
g++  -O3 -fno-exceptions -fno-omit-frame-pointer -fvisibility=hidden -std=c++11  -U_FORTIFY_SOURCE -Wl,-z,defs -Wl,--exclude-libs,ALL -static-libstdc++ -static-libgcc -fdata-sections -ffunction-sections -Wl,--gc-sections -fwhole-program -DPROFILER_VERSION=\"3.0\" -I/usr/lib/jvm/java-11-openjdk-amd64/include -Isrc/helper -I/usr/lib/jvm/java-11-openjdk-amd64/include/linux -fPIC -shared -o build/lib/libasyncProfiler.so -xc++ - -ldl -lpthread -lrt
cc  -O3 -fno-exceptions  -DPROFILER_VERSION=\"3.0\" -o build/bin/asprof src/main/*.cpp src/jattach/*.c
/home/buildbot/deps/x-tools/aarch64-linux-gnu/bin/aarch64-linux-gnu-strip build/bin/asprof
/home/buildbot/deps/x-tools/aarch64-linux-gnu/bin/aarch64-linux-gnu-strip: Unable to recognise the format of the input file `build/bin/asprof'
make: *** [Makefile:152: build/bin/asprof] Error 1

This PR reverts ?= back to original form.
Related issues
https://github.com/async-profiler/async-profiler/pull/1036 introduced the bug.
How has this been tested?
Tested to build fine on builds.shipilev.net workers.
I am not actually sure it does not break some assumptions in https://github.com/async-profiler/async-profiler/pull/1036, and GHA workflows need maintainer approval to run :)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Actually, I might need to adjust the CC= in places like this:
https://github.com/async-profiler/async-profiler/blob/78f78cf6817a07f7c9a2353c42d67ab1a6c63921/.github/workflows/test-and-publish-nightly.yml#L79
Maybe a cleaner way out would be to drop CROSS_COMPILE completely, and just rely on CC/CXX/STRIP overrides.

All good. Thanks for pointing out a bug and a quick fix.

Thanks! Looks like my binaries are built well now: https://builds.shipilev.net/async-profiler/
But I still have a question about this block:
https://github.com/async-profiler/async-profiler/blob/78f78cf6817a07f7c9a2353c42d67ab1a6c63921/.github/workflows/test-and-publish-nightly.yml#L79
Now that we override CC/CXX unconditionally to CROSS_COMPILE-d path, have we lost compilation with musl-gcc in the line above?

Now that we override CC/CXX unconditionally to CROSS_COMPILE-d path, have we lost compilation with musl-gcc in the line above?

Ah no, I confused myself. In current master, if we override CC from a command line, make would ignore our definition in Makefile. Which is the same effect I think we originally wanted with ?=.
Anyway, do you think CROSS_COMPILE still holds water? I think we can just drop all these three lines and ask users to configure their CC/CXX/STRIP instead:
CC=$(CROSS_COMPILE)gcc
CXX=$(CROSS_COMPILE)g++
STRIP=$(CROSS_COMPILE)strip

@shipilev Right, it's possible to override a local Makefile assignment on the command line.
?= would also allow overriding it with an environment variable, but that's not something we absolutely need.
Of course, a user can override all of CC, CXX and STRIP. CROSS_COMPILE is just a shortcut for doing that in a common use case when all have the same prefix. I think we can leave it for convenience.


Ignore cipher suites when setting cipher list

set_cipher_list() sets TLSv1.2 (and below) ciphers, and its success or
failure should not depend on whether set_ciphersuites() has been used to
setup TLSv1.3 ciphers.

Checklist

[x] tests are added or updated

This is a fix for an issue I posted about on the mailing list.
Currently proposed Node.js workaround and discussion.

On Nov 23, 2018, at 2:25 PM, Sam Roberts<EMAIL_ADDRESS>wrote:
In 1.1.0j, if SSL_CTX_set_cipher_list() is called with "not-a-cipher"
or "rc4", then SSL_R_NO_CIPHER_MATCH will occur.
In 1.1.1a, set_cipher_list() suceeds, seems to return the complete
cipher list (should it do this?) but later ssl_cipher_list_to_bytes()
will find that ssl_cipher_disabled() is true for all the ciphers, and
SSL_R_NO_CIPHERS_AVAILABLE will occur.

So what is happening is happening is that while there  are two APIs,
SSL_CTX_set_ciphersuites()(TLSv1.3) and
SSL_CTX_set_cipher_list()(<=TLSv1.2), they both put cipher suites into
SSL_CTX.cipher_list.
This basically makes the cipher_list error check:
if (sk_SSL_CIPHER_num(sk) == 0) {
    SSLerr(SSL_F_SSL_CTX_SET_CIPHER_LIST, SSL_R_NO_CIPHER_MATCH);
    return 0;
 }

bogus, because even when there were, in fact zero TLSv1.2 cipher
suites configured, the check for cipher suite number will find the
number greater than zero if there are TLSv1.3 cipher suites in the
list. Which there will be, by default. The actual behaviour of  this
check depends on the order in which set_ciphersuites() and
set_cipher_list() are called, a fact I can exploit to make the API
backwards compatible for Node.js.
I will call SSL_CTX_set_ciphersuites(ctx,"") just before calling
set_cipher_list(). This will clear out the TLSv1.3 suites (we don't
support 1.3 yet). Since the 1.3 suites are gone, the check for a
length of zero causing NO_CIPHER_MATCH will now behave as it would be
expected.
This won't work in the future.
I think what really should be done is that the check for _num(sk) == 0
needs to be rewritten, to iterate the list, and find the number of
TLSv1.2 and below ciphers, and return NO_CIPHER_MATCH if that number
is zero.

Try make TESTS=test_ssl_old V=1 test to get verbose output

Is this enough code that I need to sign a CLA? If it is, I need to get our lawyer's OK :-(. They will OK it, I just need to get the process moving. If I don't need a CLA, I won't bother them.

Thanks for https://github.com/openssl/openssl/pull/7759#issuecomment-444424890, I fixed the tests, PTAL.

I'm not on the OMC, but this was tagged with need-cla, so I think you need to go through the process...

All non-trivial contributions need a CCLA and ICLA on file (in general) so getting that sorted out is a prerequisite for progressing.
This contribution is non-trivial.

Kicked CLA process into gear. Looks like it will be rubber stamped.

CLA signed and emailed.

All green! @mattcaswell I made all your requested changes.

Placing this temporarily on hold while we sort out a CLA issue.

Removed the "hold" - the CLA issues are now resolved. @sam-github - please could you update your commits to show your ibm email as the author and then force push?

OK, renamed the counting function, changed to rsam@ email address. Thanks for your patience with the CLA process.

I think there are two seperate issues here:

https://www.openssl.org/docs/faq.html#MISC8 --- 1.1.1 should be ABI compatible with 1.1.0, but should it also be API compatible? That is, should it behave the same? My reading is "yes", so this change fixes a bug.
Does the 1.1.1 API work well. I agree with @mattcaswell 's points. Both failing, AND having a side-effect is undesireable. Also, the current behaviours are a bit weird.

Some thoughts, no particular order.
openssl ciphers -v none is undocumented: Usage: ciphers [options]
openssl ciphers -tls1_3 -v -s is a bit more obvious than openssl ciphers -v some-invalid-string
I don't understand why -tls1_3 in the absence of -s does nothing, I would have expected -tls1_3 to do what only -tls1_3 -s did. In fairness, behaviour is documented in the full man page, but not the usage.
clearing cipher_list or ciphersuites should not be an error, but there is no specific api to do either now, unless you count set_cipher_list("") and set_ciphersuites("")
It surprised me that set_ciphersuites(":") is an error, and this behaviour has some odd effects in the openssl ciphers command:
~/s % openssl ciphers -ciphersuites ":"
Error setting TLSv1.3 ciphersuites

I'd expect that to empty the ciphersuites. " An empty list is permissible." (docs) doesn't really say what an empty list looks like.
openssl ciphers -ciphersuites "" works, because set_ciphersuites() has special handling for a zero-length string, "" is an "empty list".
~/s % openssl ciphers ":"
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
~/s % openssl ciphers -ciphersuites "" ":"
Error in cipher list

Current behaviour. Kindof odd that ":" is not a cipher list error in the first case, but is in the second.
This PR makes a cipher list of ":" always an error, as it was in 1.1.0, but I think it would be better to always be NOT an error (in openssl 1.2). I'd also expect a ciphersuites argument of ":" to NOT be an error (equivalent to "" now).
Stepping back, I'm not sure why set_ciphersuites() was created for TLSv1.3 only. The docs state it as fact, but don't give rationale.
Is it because set_cipher_list has a complex legacy string format, and you didn't want to change anything about its behaviour? That would make sense, but I don't understand why set_ciphersuites can't be used with TLSv1.2 and below ciphers -- of course, not with magic characters, but only containing full, exact, cipher suite names, in preference order, as it does for TLSv1.3.
Equivalently, I'm not sure why set_cipher_list() can't be used to set TLSv1.3 ciphers. Is it because you want people to stop using it, but didn't want to break API compatibility, so you just added the new/TLSv1.3 cipher suites to the new API, as a gentle nudge?

set_ciphersuites should accept ":" and " : " as same meaning as ""
set_cipher_list should clear all TLSv1.2 ciphersuites and NOT error for a list of "" and " : " and ":" (same set of "empty list" strings as supported by set_ciphersuites)
set_cipher_list should error if given a non-empty list argument that results in no TLSv1.2 cipher suites, and should not modify the configured suites when it errors

I'm wondering if there is any reason why we can't make these three changes now (in master and 1.1.1)? The first one definitely shouldn't break anything. The second I suppose could in theory...but it seems unlikely. I'm also struggling to think of a usage scenario that the third change would break.

I'd be in favour of just fixing this issue as noted - i.e. correctly "empty" string handling inconsistencies.

I'd be in favour of just fixing this issue as noted - i.e. correctly "empty" string handling inconsistencies.

I'm not really sure what you mean by that. There are a number of inconsistencies here around empty string handling. This PR fixes one, but introduces more around the output of the "ciphers" command.

I was responding to "I'm wondering if there is any reason why we can't make these three changes now (in master and 1.1.1)?"

Introducing error return with side-effect would be very ugly. I do not think this PR makes much sense without actually doing all the three mentioned changes.

Your example!

Hmm. Right. Good point. Although OTOH openssl ciphers -v "" would work.

@sam-github what is the status of this PR?

IMO this change should proceed.

I'll address your comments tomorrow @mattcaswell

@mattcaswell please take a look

Pushed. Thanks.


New project is not created where I would expect

Please provide us with the following information:

OS?

Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

10.2.2 Sierra
Versions.

Please run ng --version. If there's nothing outputted, please run in a Terminal: node --version and paste the result here:

$ ng version
angular-cli: 1.0.0-beta.22-1
node: 6.8.0
os: darwin x64
Repro steps.

Was this an app that wasn't created using the CLI? What change did you do on your code? etc.

$ ng new test

When test is actually created, it is located at
~/cli-test

Cannot reproduce it. I created a test folder in my Downloads folder (git-demo), cded into it and ran
ng new cli-test and got back the file path for project /Downloads/git-demo/cli-test
angular-cli: 1.0.0-beta.22-1
node: 7.2.1
os: darwin x64

I doubt this is the issue, but only differences I see are

I am using node 6.8, you are using 7.2.1
I am creating at a deeper level
~/documents/projects/angular
you are at
~/downloads

I will try again using the same as you

I am doing it a bit deeper, created a folder inside downloads. I could nest like 10 folders and try.

You have a node_modules inside your home folder or somewhere above where you want to create your project. Some people create node_modules folders by running npm install (instead of installing something globally), it's a common mistake. The solution is to delete that rogue node_modules and try to run ng new again. The reason the CLI gets confused is because Ember CLI (which we're based on) uses the existence of a node_modules folder as the root of your project.
Closing this.

@hansl ah yes indeed, I did have a rogue node_modules directory.  I removed the node_modules directory and all worked as expected


Can you give an example on using the training conf. of the following training strategy of Applying the two-stage training strategy or the one-stage training strategy?

Hi,
Can you give an example on using the training conf. of the following training strategy?
(1) Apply the two-stage training strategy or the one-stage training strategy:
Two-stage training:
First stage: Restore darknet53_body part weights from COCO checkpoints, train the yolov3_head with big learning rate like 1e-3 until the loss reaches to a low level.
Second stage: Restore the weights from the first stage, then train the whole model with small learning rate like 1e-4 or smaller. At this stage remember to restore the optimizer parameters if you use optimizers like adam.
One-stage training:
Just restore the whole weight file except the last three convolution layers (Conv_6, Conv_14, Conv_22). In this condition, be careful about the possible nan loss value.

It is different from what you got:  I got a 87.54% test mAP (not using the 07 metric).

Results on epoch 99 is kind of overfitting. I got 87.54% mAP after 36 epochs.
Here is my training logs for your reference:
training.log

thanks for the quick reply. pls see the attachment for my train.py, args.py (in txt extension file) and progress.log. Did I do anything wrong?
progress.log
args_voc.txt
train_voc.txt

======> Epoch: 8, global_step: 33209.0, lr: 0.0001 <======
EVAL: Class 0: Recall: 0.9164, Precision: 0.0949, AP: 0.8745
EVAL: Class 1: Recall: 0.8766, Precision: 0.0888, AP: 0.7734
EVAL: Class 2: Recall: 0.8802, Precision: 0.0969, AP: 0.7795
EVAL: Class 3: Recall: 0.8397, Precision: 0.0487, AP: 0.6078
EVAL: Class 4: Recall: 0.8143, Precision: 0.0601, AP: 0.6424
EVAL: Class 5: Recall: 0.9252, Precision: 0.0613, AP: 0.8753
EVAL: Class 6: Recall: 0.9448, Precision: 0.1212, AP: 0.8627
EVAL: Class 7: Recall: 0.9378, Precision: 0.1001, AP: 0.9063
EVAL: Class 8: Recall: 0.8443, Precision: 0.1052, AP: 0.6356
EVAL: Class 9: Recall: 0.9331, Precision: 0.0577, AP: 0.8472
EVAL: Class 10: Recall: 0.8763, Precision: 0.0441, AP: 0.6926
EVAL: Class 11: Recall: 0.9528, Precision: 0.1576, AP: 0.8723
EVAL: Class 12: Recall: 0.9468, Precision: 0.0981, AP: 0.8533
EVAL: Class 13: Recall: 0.9079, Precision: 0.0610, AP: 0.8196
EVAL: Class 14: Recall: 0.9283, Precision: 0.1743, AP: 0.8330
EVAL: Class 15: Recall: 0.8159, Precision: 0.0503, AP: 0.5252
EVAL: Class 16: Recall: 0.8907, Precision: 0.0462, AP: 0.7814
EVAL: Class 17: Recall: 0.9268, Precision: 0.1195, AP: 0.7236
EVAL: Class 18: Recall: 0.9570, Precision: 0.0689, AP: 0.8745
EVAL: Class 19: Recall: 0.9446, Precision: 0.0538, AP: 0.8228
EVAL: Recall: 0.9073, Precison: 0.0978, mAP: 0.7801
EVAL: loss: total: 6.42, xy: 0.54, wh: 0.34, conf: 4.12, class: 1.42
this is my best map, i also met this appearance.

first stage: i restore yolov3 darknet weights and update yolov3_head,
second stage: i update darknet53 and yolov3_head
this is my train process

Thanks. Can you share your two stages' arg.py files?

this is my arg.py:
first_stage:  use darknet weights, restore darknet53, update yolov3_head
second_stage: use first_stage trained weights , restored  darkent53 and yolov3_head， update darkent53 and yolov3_head
first_stage.txt
second_stage.txt

Hi, @wizyoung. Can you pls review the one stage and two stage args.py files? and give us some suggestions? Thanks.

@liminghuiv Are your training and test txt files correct? Here are my txt files:
train.txt
val.txt
I hope you make efforts to understand the yolo v3 model and its parameters, and finetune the model yourself.

@wizyong, I used your misc/experiments_on_voc script and data. The training/Val text files are exact the same. Thanks a lot.

this is my arg.py:
first_stage: use darknet weights, restore darknet53, update yolov3_head
second_stage: use first_stage trained weights , restored darkent53 and yolov3_head， update darkent53 and yolov3_head
first_stage.txt
second_stage.txt

Hi @lovepan1, it seems that you did not use higher learning rate (i.e. 1e-3) at the first stage, and lower learning rate at the second stage (<1e-4) according to the readme?

ok, i will use the appropriate lr to train my model, thanks a lot

this is my arg.py:
first_stage: use darknet weights, restore darknet53, update yolov3_head
second_stage: use first_stage trained weights , restored darkent53 and yolov3_head， update darkent53 and yolov3_head
first_stage.txt
second_stage.txt

Hi @lovepan1, it seems that you did not use higher learning rate (i.e. 1e-3) at the first stage, and lower learning rate at the second stage (<1e-4) according to the readme?
ok, i will use the appropriate lr to train my model, thanks a lot

@lovepan1 , hope it works. Can you update your running result when you finish the running?

@lovepan1 , hope it works. Can you update your running result when you finish the running?

ok, in this weekend, i will retrain my model to use appropriate lr, hope it works, thank you.

@liminghuiv @wizyoung @lovepan1 hi guys， i have met the same problem， i use the /misc/experiments_on_voc/args_voc.py， and do not use two stage train, just use one stage,  my log is similar with @liminghuiv ,  after several epochs, the training conf_loss and class_loss is very small ,like 0.02 0.35, bug is very different with @wizyoung  1.5x 2.2x..., so can you help me found the problem? @wizyoung

@zyc4me  Did you find a solution? I also use one stage training and met the same problem.

Results on epoch 99 is kind of overfitting. I got 87.54% mAP after 36 epochs.
Here is my training logs for your reference:
training.log

Mon, 01 Jul 2019 08:50:21 INFO Epoch: 50, global_step: 140400 | loss: total: 4.13, xy: 0.32, wh: 0.23, conf: 1.48, class: 2.10 | Last batch: rec: 0.937, prec: 0.007 | lr: 0.0001
Mon, 01 Jul 2019 08:50:56 INFO Epoch: 50, global_step: 140500 | loss: total: 4.12, xy: 0.32, wh: 0.23, conf: 1.48, class: 2.10 | Last batch: rec: 0.857, prec: 0.014 | lr: 0.0001
Mon, 01 Jul 2019 08:51:39 INFO Epoch: 50, global_step: 140600 | loss: total: 4.14, xy: 0.32, wh: 0.23, conf: 1.48, class: 2.11 | Last batch: rec: 0.786, prec: 0.014 | lr: 0.0001
Mon, 01 Jul 2019 08:52:30 INFO Epoch: 50, global_step: 140700 | loss: total: 4.15, xy: 0.32, wh: 0.23, conf: 1.49, class: 2.11 | Last batch: rec: 0.867, prec: 0.012 | lr: 0.0001
Mon, 01 Jul 2019 08:56:02 INFO ======> Epoch: 50, global_step: 140708.0, lr: 0.0001 <======
According to your training logs, recall is very high but precision is low. Is that normal?


Add option to display/hide square around face tags

Is your feature request related to a problem? Please describe.
All faces in my pictures are tagged (using digikam). When opening a picture with a tagged face, a square is shown around the face. This is not helpful because I know the people in my pictures. It's rather annoying as I'm interested in the actual pictures and not the location of the faces in the pictures.
Describe the solution you'd like
It would be great if we could configure on the settings page whether the square is displayed or not.

Sounds good to me.
It should be added here: https://github.com/bpatrik/pigallery2/blob/22954550bfd473d85206d62aca50e47853b20862/src/frontend/app/ui/gallery/lightbox/controls/controls.lightbox.gallery.component.html#L58

We should soon have this

The latest commit should contain this.


chore(master): release 1.1.22

:robot: I have created a release beep boop
1.1.22 (2023-08-17)
Bug Fixes

deps: update dependency wayofdev/laravel-cycle-orm-adapter to v4.0.62 (9aa2b64)

This PR was generated with Release Please. See documentation.

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


Freeze on "Shutting down Steam" when using "Shutdown" or "Reboot" option in Game Mode

Describe the bug
When attempting to shutdown or reboot the system from the Game Mode UI, the system hangs on the "Shutting down Steam" screen.
What did you expect to happen?
A successful shutdown or reboot.
Output of rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:latest
                   Digest: sha256:b5b9747ef6b7608fcca8b9813d95509b2ae9235a1ba37a1fb49ef175c46e86bb
                  Version: 40.20240621.0 (2024-06-21T05:13:33Z)
          LayeredPackages: strace
            LocalPackages: lact-0.5.4-0.x86_64

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:latest
                   Digest: sha256:b5b9747ef6b7608fcca8b9813d95509b2ae9235a1ba37a1fb49ef175c46e86bb
                  Version: 40.20240621.0 (2024-06-21T05:13:33Z)
            LocalPackages: lact-0.5.4-0.x86_64

Hardware
bazzite-deck:stable 
Fedora Linux 40 (Kinoite) x86_64
Linux 6.9.4-201.fsync.fc40.x86_64
15 mins
Spawned on Jan 20 2024

Z390 AORUS PRO WIFI
Intel(R) Core(TM) i9-9900K (16) @ 5.00 GHz
AMD Radeon RX 7600 [Discrete]
3.35 GiB / 31.26 GiB (11%)
31.93 GiB / 68.35 GiB (47%) - ext4 [Read-only]
3.08 TiB / 7.15 TiB (43%) - ext4
1920x1080 @ 60Hz
3840x2160 @ 60Hz [External]

bash 5.2.26
/dev/pts/0
2746 (rpm), 48 (flatpak-system), 7 (flatpak-user)

Extra information or context
There seems to be a zombie process:
marco@fedora:~$ ps aux | awk '$8 ~ /^[Zz]/'
marco       6174  0.0  0.0      0     0 ?        Z<s  12:55   0:00 [steam-runtime-s] <defunct>

It comes from the following parent process:
marco@fedora:~$ ps -o ppid= 6174
   6104
marco@fedora:~$ ps -Flww -p 6104
F S UID          PID    PPID  C PRI  NI ADDR SZ WCHAN    RSS PSR STIME TTY          TIME CMD
4 S marco       6104    5970  1  75  -5 - 200659 hrtime 229048 12 12:55 ?       00:00:14 /var/home/marco/.local/share/Steam/ubuntu12_32/steam -srt-logger-opened -gamepadui -steamos3 -steampal -steamdeck

Which gives he following strace output (ad infinitum):
marco@fedora:~$ sudo strace -p 6104
strace: Process 6104 attached
[ Process PID=6104 runs in 32 bit mode. ]
restart_syscall(<... resuming interrupted read ...>) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [CHLD], 8) = 0
getpid()                                = 6104
tgkill(6104, 6511, 0)                   = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=50000000}, 0xffbf2234) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [CHLD], 8) = 0
getpid()                                = 6104
tgkill(6104, 6511, 0)                   = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=50000000}, 0xffbf2234) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [CHLD], 8) = 0
getpid()                                = 6104
tgkill(6104, 6511, 0)                   = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=50000000}, 0xffbf2234) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [CHLD], 8) = 0
getpid()                                = 6104
tgkill(6104, 6511, 0)                   = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=50000000}, 0xffbf2234) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [CHLD], 8) = 0
getpid()                                = 6104
tgkill(6104, 6511, 0)                   = 0

The process mentioned in the strace output (6511) doesn't seem to exist:
marco@fedora:~$ ps -Flww -p 6511
F S UID          PID    PPID  C PRI  NI ADDR SZ WCHAN    RSS PSR STIME TTY          TIME CMD

But, for some reason, sending a kill command to the phantom process successfully continues the shutdown process:
marco@fedora:~$ kill -9 6174 (the zombie process, but this doesn't seem to do anything)
marco@fedora:~$ kill -9 6511
marco@fedora:~$
Broadcast message from marco@fedora (Sun 2024-06-23 13:28:34 CEST):

The system will reboot now!

client_loop: send disconnect: Broken pipe

Please excuse the unintended strikethroughs.

Can sign that one. Have the Same Issue for weeks now.

Strangely, the problem seems to have fixed itself a few days ago (I didn't notice, but my girlfriend said she used our HTPC and never even knew it was an issue, which was quite funny).
This is the second time I've had this bug (should have mentioned that in the original post, sorry). Last time I thought one of my troubleshooting steps helped, but now I'm unsure.
Since it isn't the first time and someone else also had the issue now, I'll leave the issue open for now.

Alright everyone, get your voodoo dolls and detective hats out, because we have a curse to investigate: after applying the fix script to be able to receive updates again, the issue reappeared!
I'm genuinely stumped, and quite annoyed.

I had to completely reinstall Bazzite to get rid of it. Not even Rebasing solved it.
I could also rule out Decky and all its Plugin as it also happened with Decky removed.

I managed to fix it! (Sorry that I found it too late for you, @NightHammer1000 )
This thread describes the issue for Steam Deck.
For Bazzite:

sudo mkdir -p /etc/systemd
sudo nano /etc/systemd/coredump.conf
Enter the following into this new file and save and exit:
[Coredump]
Storage=none
ProcessSizeMax=0
rm -rf /home/deck/.local/share/Steam/compatibilitytools.d/*
rm -rf /home/deck/.local/share/Steam/steamapps/compatdata/0
Reboot while still in desktop mode, and hopefully that should be it.

Considering how many people are complaining about this issue without a fix, I'm surprised how far I had to scroll to find a someone with an actual solution (4th or 5th page of Google).
While the issue itself is now resolved, I'd like a dev's comment on if a preventative fix can be applied to avoid this issue in the future. Afterwards the issue can be closed.

I managed to fix it! (Sorry that I found it too late for you, @NightHammer1000 ) This thread describes the issue for Steam Deck.
For Bazzite:

sudo mkdir -p /etc/systemd
sudo nano /etc/systemd/coredump.conf
Enter the following into this new file and save and exit:
[Coredump]
Storage=none
ProcessSizeMax=0
rm -rf /home/deck/.local/share/Steam/compatibilitytools.d/*
rm -rf /home/deck/.local/share/Steam/steamapps/compatdata/0
Reboot while still in desktop mode, and hopefully that should be it.

Considering how many people are complaining about this issue without a fix, I'm surprised how far I had to scroll to find someone with an actual solution (4th or 5th page of Google). While the issue itself is now resolved, I'd like a dev's comment on if a preventative fix can be applied to avoid this issue in the future. Afterwards the issue can be closed.

Unfortunately, this did not resolve the issue on my end. After following the steps and rebooting from the desktop, it still hangs on reboot/shutdown from game mode.
bazzite 40.20240705.0

Subscribing as this bug also affects ChimeraOS on some devices.

Aaaaand it's back with my fresh Bazzite install as well

I am also seeing this issue, luckily a sudo poweroff seems to solve it for now. I only noticed when I realized the light on my HTPC tower was still on after I had stopped gaming hours before.


Dropped items via clothing removal stick to secway

Description
As the title says, If you remove your clothes while on a secway then the items in the pocket attach to the secway rather than to the floor.

Screenshots

Additional context
Pretty low key issue, can still pick up items off secway, just looks a bit shit.

hey that's me, can confirm this is funny


compile error with config sycl

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):no
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):Linux Ubuntu 16.04
TensorFlow installed from (source or binary):source
TensorFlow version (use command below):1.4,the latest version I git from tensorflow
Python version: 3.6.3
Bazel version (if compiling from source):0.8.1
GCC/Compiler version (if compiling from source):5.4.0
CUDA/cuDNN version:no
GPU model and memory:no
Exact command to reproduce:bazel build -c opt --config=sycl //tensorflow/tools/pip_package:build_pip_package

##something else
OpenCl version:1.2
computecpp path:    /usr/local/computecpp  version 0.5.0
computecpp_info:
Device Info:
Discovered 1 devices matching:
platform    :
device type :
Device 0:
Device is supported                     : UNTESTED - Vendor not tested on this OS
CL_DEVICE_NAME                          : Hainan
CL_DEVICE_VENDOR                        : Advanced Micro Devices, Inc.
CL_DRIVER_VERSION                       : 2482.3
CL_DEVICE_TYPE                          : CL_DEVICE_TYPE_GPU
clinfo:
Number of platforms                               1
Platform Name                                   AMD Accelerated Parallel Processing
Platform Vendor                                 Advanced Micro Devices, Inc.
Platform Version                                OpenCL 2.0 AMD-APP (2482.3)
Platform Profile                                FULL_PROFILE
Platform Extensions                             cl_khr_icd cl_amd_event_callback cl_amd_offline_devices
Platform Extensions function suffix             AMD
Platform Name                                   AMD Accelerated Parallel Processing
Number of devices                                 1
Device Name                                     Hainan
Device Vendor                                   Advanced Micro Devices, Inc.
Device Vendor ID                                0x1002
Device Version                                  OpenCL 1.2 AMD-APP (2482.3)
Driver Version                                  2482.3
Device OpenCL C Version                         OpenCL C 1.2
Device Type                                     GPU
Device Profile                                  FULL_PROFILE
Device Board Name (AMD)                         AMD Radeon HD 8500M
Device Topology (AMD)                           PCI-E, 04:00.0
Max compute units                               4
SIMD per compute unit (AMD)                     4
SIMD width (AMD)                                16
SIMD instruction width (AMD)                    1
Max clock frequency                             850MHz
Graphics IP (AMD)                               6.0
Device Partition                                (core)
Max number of sub-devices                     4
Supported partition types                     none specified
Max work item dimensions                        3
Max work item sizes                             256x256x256
Max work group size                             256
Preferred work group size multiple              64
Wavefront width (AMD)                           64
Preferred / native vector sizes
char                                                 4 / 4
short                                                2 / 2
int                                                  1 / 1
long                                                 1 / 1
half                                                 1 / 1        (n/a)
float                                                1 / 1
double                                               1 / 1        (cl_khr_fp64)
Half-precision Floating-point support           (n/a)
Single-precision Floating-point support         (core)
Denormals                                     No
Infinity and NANs                             Yes
Round to nearest                              Yes
Round to zero                                 Yes
Round to infinity                             Yes
IEEE754-2008 fused multiply-add               Yes
Support is emulated in software               No
Correctly-rounded divide and sqrt operations  Yes
Double-precision Floating-point support         (cl_khr_fp64)
Denormals                                     Yes
Infinity and NANs                             Yes
Round to nearest                              Yes
Round to zero                                 Yes
Round to infinity                             Yes
IEEE754-2008 fused multiply-add               Yes
Support is emulated in software               No
Correctly-rounded divide and sqrt operations  No
Address bits                                    32, Little-Endian
Global memory size<PHONE_NUMBER> (1.993GiB)
Global free memory (AMD)                        <printDeviceInfo:68: get number of CL_DEVICE_GLOBAL_FREE_MEMORY_AMD : error -33>
Global memory channels (AMD)                    2
Global memory banks per channel (AMD)           8
Global memory bank width (AMD)                  256 bytes
Error Correction support                        No
Max memory allocation<PHONE_NUMBER> (1.482GiB)
Unified memory for Host and Device              No
Minimum alignment for any data type             128 bytes
Alignment of base address                       2048 bits (256 bytes)
Global Memory cache type                        Read/Write
Global Memory cache size                        16384
Global Memory cache line                        64 bytes
Image support                                   Yes
Max number of samplers per kernel             16
Max size for 1D images from buffer            134217728 pixels
Max 1D or 2D image array size                 2048 images
Base address alignment for 2D image buffers   256 bytes
Pitch alignment for 2D image buffers          256 bytes
Max 2D image size                             16384x16384 pixels
Max 3D image size                             2048x2048x2048 pixels
Max number of read image args                 128
Max number of write image args                8
Local memory type                               Local
Local memory size                               32768 (32KiB)
Local memory syze per CU (AMD)                  65536 (64KiB)
Local memory banks (AMD)                        32
Max constant buffer size                        65536 (64KiB)
Max number of constant args                     8
Max size of kernel argument                     1024
Queue properties
Out-of-order execution                        No
Profiling                                     Yes
Prefer user sync for interop                    Yes
Profiling timer resolution                      1ns
Profiling timer offset since Epoch (AMD)<PHONE_NUMBER>761772748ns (Thu Dec  7 20:46:23 2017)
Execution capabilities
Run OpenCL kernels                            Yes
Run native kernels                            No
Thread trace supported (AMD)                  No
SPIR versions                                 1.2
printf() buffer size                            1048576 (1024KiB)
Built-in kernels
Device Available                                Yes
Compiler Available                              Yes
Linker Available                                Yes
Device Extensions                               cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event
NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  AMD Accelerated Parallel Processing
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   Success [AMD]
clCreateContext(NULL, ...) [default]            Success [AMD]
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
Platform Name                                 AMD Accelerated Parallel Processing
Device Name                                   Hainan
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
Platform Name                                 AMD Accelerated Parallel Processing
Device Name                                   Hainan
ICD loader properties
ICD loader Name                                 OpenCL ICD Loader
ICD loader Vendor                               OCL Icd free software
ICD loader Version                              2.2.8
ICD loader Profile                              OpenCL 1.2
NOTE:	your OpenCL library declares to support OpenCL 1.2,
but it seems to support up to OpenCL 2.1 too.
Describe the problem
I want Compile With sycl config  with the command
bazel build -c opt --config=sycl //tensorflow/tools/pip_package:build_pip_package
but  unfortunately get the error
Illegal ambiguous match on configurable attribute "deps" in @local_config_sycl//sycl:sycl:
@local_config_sycl//sycl:using_sycl_ccpp
@local_config_sycl//sycl:using_sycl_trisycl
Multiple matches are not allowed unless one is unambiguously more specialized.
I did not know what casue this compile error. Please Help

Sorry, opencl is not fully supported.

Illegal ambiguous match on configurable attribute "deps"

That doesn't seem opencl *specific*

@mirh ,yeah, I am not familiar with bazel  tools ,But I guess that some Configuration may not be appropriate because I find that  in /third_party/sycl/sycl/BUILD.tpl  some configuration confuse me.
In that file
config_setting(
name = "using_sycl_ccpp",
define_values = {
"using_sycl": "true",
"using_trisycl": "false",
},
)
config_setting(
name = "using_sycl_trisycl",
define_values = {
"using_sycl": "true",
"using_trisycl": "false",
},
)
that the setting named "using_sycl_ccpp"  whosed define_values are same as "using_sycl_trisycl",,there must be some conflict in cuda's configruation cause the same error。but It's difficault for me to handle the problem . Just wait for someone is good at bazel to handle the problem.

The thing build fine for me with this tree
Can you check ?

Thanks for your guide ,I will try this tree and reply the result.
发自贺敏琪
在 2017年12月19日，上午12:06，mirh <notifications<EMAIL_ADDRESS>写道：
The thing build fine for me with this treehttps://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu
Can you check ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/tensorflow/tensorflow/issues/15204#issuecomment-352470374, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANFVQuU6sM7kLREjX1wFCP4Wq6BPiBBnks5tBo0vgaJpZM4Q6qSR.

I ran into a similar issue but I could get a successfull SYCL-based build once switching back to ComputeCpp 0.4.0 (building against TensorFlow ~r1.4). So you might want to give that a try as well, if that is something possible for you.

Thanks, I try the branch amd_gpu It can build. But I Have got another error about
this rule is missing dependency declarations for the following files included by 'external/protobuf_archive/python/google/protobuf/internal/api_implementation.cc'
the command is
bazel build --config=opt --config=sycl --verbose_failures //tensorflow/tools/pip_package:build_pip_package 2>&1 | tee ~/tfbuild.log
can you help me with  @this@mirh

For as much as I know, it might have been due to one of the plenty of updates they made in this last couple of days.
Maybe.. Try this revision for starters?

I am getting this issue when compiling with Intel GPU. Is there a solution to this anywhere?

This is the branch.

Found the actual cause
Somebody screwed kinda hard.
@huoyushi can you reopen?

@mirh  were you able to fix this issue?

This specific one, yes.
You just need to remove the trisycl line.
OTOH normal tf is just rotten to the core for sycl.
As I said 2 comments above, use Luke's branch.


Added 'pkgset' beacon tests for SLES and RHEL minions (slenkins branch)

This PR adds tests for the pkgset beacon for SLES and RHEL minions using SLEnkins:

Scenario: Manually removing a package in a minion
Scenario: Manually installing a package in a minion

When users manually perform package installation or removal directly in the minion (using zypper or yum commands) then the pkgset beacon is aware of these changes and does report them to the SUMA UI.
So package changes manually done by zypper or yum actions are shown in the UI.
/cc @MalloZup @mseidl

yop, cool, for me seems nice, i will test it


add a simple python example

I have written a simple python example for MT5 using .NET.
Test with MT5 Build 2650
In addition, the folder Examples was created.
Since the website is currently not usable.

@KptKuck Thank you.


Nested scrolling support

CollapsingToolbarScaffold doesn't seem to report scroll events until the toolbar is fully collapsed when a nested scroll connection is provided. Is this expected? Does Compose UI require special handling from CollapsingToolbarScaffold?
CollapsingToolbarScaffold(
  modifier = Modifier.nestedScroll(nestedScrollConnection)
)

I think I know why -- CollapsingToolbarScaffold needs to expose the nested scroll connection so that it can be used in its parent. This would be in line with what Material components is doing. Here's an example:
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/AppBarSamples.kt;l=155;drc=e658f4148cec10e19c3c827173abebae1fb93a31

I'm not sure whether I understood your issue correctly, I get reported of the scroll events even if it is not fully collapsed. Can you provide the full snippet you used to reproduce the issue?

@saket do you have a repro project for this issue?
I have stumbled into the same issue now, but I will need some time if I need to come up with a repro project as I can't share my current code here.
Basically I'm using CollapsingToolbarScaffold with ExitUntilCollapsed scroll strategy, and as part of the content I have a composable with a multiline Text composable. This Text composable is (vertically) scrollable itself, but only becomes scrollable in the UI when the toolbar is fully collapsed.


Edge case: Aggregation crash when ignoreNullKeys=true and all input rows are filtered out

Bug description
Consider this table:
c0, c1
null, 1
And this query WITH ignoreNullKeys = true:
select c0, sum(c1) group by c0
Expected result:
0 result rows.
Actual result:
HashAggregation crash
Analysis and commentary:
Subtly, the ignoreNullKeys option effectively turns HashAggregation operator into a two-in-1 (Filter + Agg).
Namely, this query select c0, sum(c1) group by c0 when ignoreNullKeys = true is semantically equivalent to:
select c0, sum(c1) group by c0 where c0 is not null. A.k.a a filter + agg.
When this edge case occurs, after deselectRowsWithNulls, there's no rows to aggregate. And thus, HashAggregation's AddInput should simply return. Instead, it continues to proceed, triggering runtime asserts.
Recommended fix:
Gracefully return as soon as we realize there are no rows to agg in current batch. Gracefully being keyword here because we may need to "unwind partial states", such as aggregation statistics before returning. Or at least move the return logic to very early on of HashAgg->AddInput.
cc @mbasmanova @oerling
System information
n/a
Relevant logs
Testing started at 7:04 PM ...
unknown file: Failure
C++ exception with description "Exception: VeloxRuntimeError
Error Source: RUNTIME
Error Code: INVALID_STATE
Reason: (0 vs. 0)
Retriable: False
Expression: n > 0
Function: incrementProbes
File: /Users/shiyu/repos/velox/velox/./velox/exec/HashTable.h
Line: 793
Stack trace:
# 0
E20240109 19:04:53.955655 5960668 Exceptions.h:69] Line: /Users/shiyu/repos/velox/velox/./velox/exec/HashTable.h:793, Function:incrementProbes, Expression: n > 0 (0 vs. 0), Source: RUNTIME, ErrorCode: INVALID_STATE
# 1

@shiyu-bytedance Hi Shiyu, thank you for reporting this crash. Let's fix it, but I'd like to clarify that ignoreNullKeys option should not be set freely. The query planner must ensure it is safe to ignore nulls. This is the case for example, if aggregation is followed by join on the group-by key. However, this is not valid to set this option for the queries you provided in the example.
Would you like to open a PR to fix the crash?

The query planner must ensure it is safe to ignore nulls. This is the case for example, if aggregation is followed by join on the group-by key.

Could you explain why it's not valid to set ignoreNullKeys for aggregation followed by join? What's the different between a ingoring null keys aggregation with all null input and a normal aggregation with empty input in this example.

@mbasmanova Sorry, I misunderstood earlier. Your meaning is that an aggregation followed by a join is valid to set ignore null keys, but it is not valid for a standalone aggregation.

@mbasmanova I reported this  issue to Shiyu. It seems that our usage does not align with your design intentions. We are trying to integrate Velox into Elasticsearch, and the native aggregation operator in ES filters out null keys(Inconsistent with SQL semantics). I accidentally discovered that Velox's hash aggregate operator has this configuration and used it.

@ViggoC Thank you for clarifying the use case.

We are trying to integrate Velox into Elasticsearch, and the native aggregation operator in ES filters out null keys(Inconsistent with SQL semantics).

I see. In this case it is valid to set ignoreNullKeys=true. We should fix the crash. Would you like to help with the fix?

@shiyu-bytedance and I will try to fix it. Shiyu is more familiar with this part of the code, so he will take the lead. I am willing to provide assistance if he needs it.

@shiyu-bytedance Hi Shiyu, thank you for reporting this crash. Let's fix it, but I'd like to clarify that ignoreNullKeys option should not be set freely. The query planner must ensure it is safe to ignore nulls. This is the case for example, if aggregation is followed by join on the group-by key. However, this is not valid to set this option for the queries you provided in the example.
Would you like to open a PR to fix the crash?

@mbasmanova I understand that the query I provided is not valid for ignoreNullKeys because it's Agg (not followed by Join). However, I do think (and would like to confirm we are on the same page) that this is still a legitimate bug.
Even if Agg is followed by Join and ignoreNullKeys is set to true, it's still possible that, by chance, some splits may have all their rows filtered out (due to null keys) and trigger this bug.

@shiyu-bytedance Yes, crash is never an expected outcome. This is a bug that we'd need to fix.

@shiyu-bytedance Yes, crash is never an expected outcome. This is a bug that we'd need to fix.

@mbasmanova Actually, just to be specific, this does not crash like deref null ptr, this case triggers an VELOX_CHECK. VELOX_CHECK's are littered through out Velox to ensure that we do not run into unexpected situations, such as those that arise from "bad" planning/optimizer.
I think to be very precise about qualifying this bug, this can be described as a case where even when planner/optimzer behaves correct, we can still "crash" by triggering the VELOX_CHECK in question.
So this bug is really:

An overly conservative VELOX_CHECK that needs to be relaxed to allow this edge case.
All subsequent works required to handle the relaxed assumption (i.e. don't crash).

All this is to say, crash, by way of triggering VELOX_CHECK, can be an expected outcome if the trigger is an impossible/invalid situation from bad planner/optimizer. But that's not this case.

@shiyu-bytedance Thank you for clarifying. Indeed, let's make sure to use the term 'crash' only for crashes and otherwise say 'fail'. I updated the PR title. Would be nice to update PR description as well.

aligned

I am new to Velox codebase and I am looking at this issue. I am curious that if Velox allows nullable keys? I try to crack a fix and I find there is assumption in many test case that key should not be nullable. Please correct me if I am wrong. @mbasmanova @shiyu-bytedance

Unit test repro:
TEST_F(AggregationTest, xxx) {
  auto data = makeRowVector({
      makeAllNullFlatVector<int32_t>(3),
      makeFlatVector<int32_t>({1, 2, 3}),
  });

  auto plan = PlanBuilder()
                  .values({data})
                  .aggregation(
                      {"c0"},
                      {"sum(c1)"},
                      {},
                      core::AggregationNode::Step::kPartial,
                      true /*ignoreNullKeys*/
                      )
                  .planNode();

  AssertQueryBuilder(plan).assertEmptyResults();
}


Output source command at the end

http://superuser.com/questions/1130688/bash-how-to-output-command-to-next-prompt-for-user-to-use


Add support for specifying P31 restrictions on property/item query

When the user is searching for a property/item to wikify to, the search engine interface (both the frontend and the service) should allow the user to specify P31 (instance of) restrictions, eg if the user specifies P5 then results will be limited to wikidata items that are instances of "human". The P31 input needs to also be a search box, ie the user could search for "human" and get P5 as a suggestion and then use that to help them narrow down their search results for "George Washington"

@szeke  have i described accurately how this is supposed to work?

Constraining by instance-of is only relevant for item wikification, but not for property wikification

Already supported in the backed search API


Malformed comment throws: undefined method `type' for nil:NilClass

Great tool!  We hit a small bug with a malformed comment in our codebase.  Minimal repro:
=# bad comment

$ haml-lint -i UnnecessaryStringOutput bug.haml
undefined method `type' for nil:NilClass
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/linter/unnecessary_string_output.rb:34:in `outputs_string_literal?'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/linter/unnecessary_string_output.rb:25:in `visit_script'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/haml_visitor.rb:18:in `visit'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/haml_visitor.rb:27:in `block in visit_children'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/haml_visitor.rb:27:in `each'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/haml_visitor.rb:27:in `visit_children'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/haml_visitor.rb:23:in `visit'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/linter.rb:28:in `run'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/runner.rb:58:in `block in collect_lints'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/runner.rb:57:in `map'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/runner.rb:57:in `collect_lints'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/runner.rb:21:in `block in run'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/runner.rb:20:in `map'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/runner.rb:20:in `run'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/cli.rb:82:in `scan_for_lints'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/cli.rb:51:in `act_on_options'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/lib/haml_lint/cli.rb:23:in `run'
/Users/joshlory/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/haml_lint-0.14.1/bin/haml-lint:7:in `<top (required)>'
/Users/joshlory/.rbenv/versions/2.0.0-p481/bin/haml-lint:23:in `load'
/Users/joshlory/.rbenv/versions/2.0.0-p481/bin/haml-lint:23:in `<main>'
Report this bug at https://github.com/brigade/haml-lint/issues

Thanks for the report, @joshlory.
Fixed in a9ce99409166c76abc8adb5a5d3ee287c49939c9.


2018 n2c2 data availability

Hi is 2018 n2c2 data publicly available, as I would like to replicate your codes:
https://github.com/uf-hobi-informatics-lab/ClinicalTransformerClassification/blob/580670f02baf9dc2a2112f5776935ec8a89a28f1/src/data_processing/preprocessing.ipynb#L535
Thanks

please contact the n2c2 team to get the data.  You have to sign DUA with them. We cannot share the dataset.
https://n2c2.dbmi.hms.harvard.edu/data-sets


✨ Add support for static client certificates defined in fastly.toml.

As it says in the CHANGELOG entry:
Add support for supplying client certificates in fastly.toml, through the use of the
client_cert_info table, which must have one of a "certificate" or "certificate_file"
key, as well as one of a "key" and "key_file" key. The "_file" variants can be used to
point to certificate/key files on disk, whereas the non-"_file" variants should be
multi-line string constants in the toml. In all cases, they should be in PEM format.

I was going to ask about adding documentation for this to https://www.fastly.com/documentation/reference/compute/fastly-toml/, but I see that "ca_certs" isn't documented there either. I guess this means we need to launch an 'audit' project to get the docs up to date with what the CLI and Viceroy actually support in fastly.toml.


RTT on WB-FC-Firmware

Next time I'm on that board I will add this so that we can use RTT to debug at faster speeds than printfs.
I've set up the first commit on the DAQ firmware so it works nicely to transfer over.

As of 0ac6c7c, RTT builds on MCUXpresso for WB-FC. Still need to test if it works and make sure that it hasn't broken x86 compilation.

I think it would be a good idea to do something will build flags so we can control whether this (and maybe other 'debug' code) is included in builds. We don't need this on the actual flight, so it would be good to be able to add and remove this functionality without having to make large changes to the codebase.

I can confirm that RTT is working on the flight computer. There were some issues where it didn't seem to be working, but that's just because the IMU task was fucked up and killing everything somehow.

With the IMU task removed, RTT works (at least for sending messages, which is all I need it for at the moment, so should be able to package this up cleanly pretty quick and merge it in.
I also made a very minor update the RTT documentation about where it's located on windows.

Moved it into the HAL to make things nicer for x86. Will test again, should be good to go after that.
Am I jinxing myself? of course. Do I care? Of course not. Will I suffer for my hubris? Absolutely.

Tested it, still works fine.


CSV output no longer has TITLE_ID for CIS

Is your feature request related to a problem? Please describe.
The CSV output used to include the TITLE_ID for the AWS CIS benchmarks.
Describe the solution you'd like
Include the CIS benchmark ID so it can be referenced from the CSV output.

Hi @jsherm-fwdsec in prowler v3  we have implemented compliance using a different flow. To launch a CIS scanning please check this out  prowler --compliance cis_1.5_aws

Thanks @n4ch04. That's how I ran the CIS scan, using a command similar to the one you've provided. I think I understand the intention, which is to completely separate the Prowler checks from compliance, by not having anything CIS-related in the results. It might be useful to add an option to include the CIS information along with the results of each check, since some users like to see which CIS item is associated with a check.

Hi @jsherm-fwdsec right now we have that information split in the two output formats to allow us to provide more details about the results and the compliance info depending on the approach.
If you want to correlate both formats I suggest to use a "table" approach using the check id as primary and foreign key for the different outputs.
At this moment we have not planned some kind of merge of the two outputs methods since the information from one can be easily referenced from another. I hope this trick could help you to map the info between the two formats.
Thank you for using Prowler!!


high number of chromosomes not accepted?

Hi there,
This seems like a great tool and I am really keen to try it! I was trying to set this for 42 chromosomes, but it doesn't seem to accept this. My organism is 2n=6x=42
This is my error message:
RuntimeError: Pipeline Abortion: Inflation recommendation failed. It seems that some chromosomes were grouped together, or the maximum number of clusters is even less than the expected number of chromosomes. For more details, please check out the logs.
Traceback (most recent call last):
File "/gpfs01/home/mbars7/HapHiC/./haphic", line 96, in
subprocess.run(commands, check=True)
File "/gpfs01/home/mbars7/miniconda3/envs/haphic/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/gpfs01/home/mbars7/HapHiC/scripts/HapHiC_pipeline.py', '/gpfs01/home/mbars7/danica_2/hetero_hifiasm_HiC_HiFi/danica_hetero_HiC_hifi.hic.p_ctg.fa', '/gpfs01/home/mbars7/danica_2/hetero_hifiasm_HiC_HiFi/filtered_name.bam', '42']' returned non-zero exit status 1
Is there something else I should be adding to this?
Thank you for any advice!

Thank you very much! :)

Dear Zeng,
I have a same ERROR although I used *.p_ctg and through the mapping I used right _1 and _2 pair end reads.
Traceback (most recent call last):   File "/public/home/wusong/sfw/HapHiC/scripts/HapHiC_pipeline.py", line 529, in <module>     main()   File "/public/home/wusong/sfw/HapHiC/scripts/HapHiC_pipeline.py", line 510, in main     haphic_cluster(args)   File "/public/home/wusong/sfw/HapHiC/scripts/HapHiC_pipeline.py", line 393, in haphic_cluster     raise RuntimeError( RuntimeError: Pipeline Abortion: Inflation recommendation failed. It seems that some chromosomes were grouped together, or the maximum number of clusters is even less than the expected number of chromosomes. For more details, please check out the logs. Traceback (most recent call last):   File "/public/home/wusong/sfw/HapHiC/haphic", line 117, in <module>     subprocess.run(commands, check=True)   File "/public/home/wusong/miniconda3/envs/haphic/lib/python3.10/subprocess.py", line 526, in run     raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['/public/home/wusong/sfw/HapHiC/scripts/HapHiC_pipeline.py', 'allhaps.fa', 'HiC.filtered.bam', '32', '--threads', '20', '--processes', '20', '--gfa', 'darwin.asm.hic.hap1.p_ctg.gfa,darwin.asm.hic.hap2.p_ctg.gfa,darwin.asm.hic.hap3.p_ctg.gfa,darwin.asm.hic.hap4.p_ctg.gfa']' returned non-zero exit status 1.
I noticed that the file size for bam file changed dragmatically from 1.1G (HiC.bam) to 4.2M (HiC.filtered.bam), is it a potential problem?


/collections route returns array

The /collections route according to the API spec returns an object with collections and links keys --

route
capital C collections
lowercase c collections

The deployed version of the API that I saw this on was based on this branch so I don't know if this is also true on master. If not I won't be offended by a quick close.

This was fixed, but a regression that was introduced in a recent refactor.
The response model for the collections endpoint is Collections, which is the correct format; however, all_collections on the backends and the base class (https://github.com/stac-utils/stac-fastapi/blob/9ef8601a1dfbf69c7a634eb255af2d84327b6294/stac_fastapi/types/stac_fastapi/types/core.py#L384) return a list of TypeDict Collection objects.
This should instead construct a stac-pydantic Collections object or a TypedDict with the appropriate entries, and return with the appropriate links (see the PC endpoint for reference)
This could either be solved by changing the all_collections signature and modifying the backend core clients, or translating the list of collections at the API level so that all backends use the same logic to construct the Collections response


Fix Kotlin version compatibility tests

Fixes a failure in the New Kotlin compatibility tests due to the old version of the plugin using Scala 2.10 but the new sbt 1.x version using Scala 2.12.

@pfn sorry for the extra noise on this one - didn't expect the sbt 1.x one to get merged in so quickly :D

Thanks, I'm kinda just going on auto-pilot right now  :D


Use build script to generate grammars

TypeScript Grammar is written in yaml file
TypeScriptReact Grammar has only additions and changes in its yaml file. The tmLanguage file for it is generated using build script
Theme files are yaml files too. TypeScriptReact contains only additions to be applied to typescript theme

Hi @sheetalkamat, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Sheetal Nandi). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Doesn't display 'headline' for the Blog Posting type?!

Ive noticed that if you chose Blog Post as the type - it doesnt display the 'headline' - even if its passed into the create method...i.e:
$JSONsructuredData = \JsonLd\Context::create('blog_posting', [
			'name'             => $post->title,
			'headline'         => $post->title,
			'datePublished'    => $post->publish_date->format('Y-m-d').'T'.$post->publish_date->format('H:m:s'),
			'dateModified'     => $post->publish_date->format('Y-m-d').'T'.$post->publish_date->format('H:m:s'),
			'image'            => [
				'type' => 'ImageObject',
				'url'  => env('APP_URL').$post->feature_image,
				'width'  => '850',
				'height' => '350'
			],
			'publisher'        => [
				'type' => 'Organization',
				'name' => 'SomeBlogSite',
				'logo' => [
					'type'   => 'ImageObject',
					'url'    => env('APP_URL').'img/logo/imge.png',
					'width'  => '600',
					'height' => '150'
				],
			],
			'mainEntityOfPage' => [
				'type' => 'WebPage',
				'id'   => env('APP_URL').'lobby/'.$post_slug,
			],
			'author'           => [
				'type' => 'Person',
				'name' => $post->user->name,
			],

		]);

It just ignores the ''headline'         => $post->title,' - although I can see in the $structure of the CreativeWork Class it had 'headline' => null' ...but would appear it never actually sets it for display, even when passing in the value???
Cheers

Just checked your example with this code
$post_title = 'Test post title';

$JSONsructuredData = \JsonLd\Context::create('blog_posting', [
    'name'             => $post_title,
    'headline'         => $post_title,
    'datePublished'    => '2017-06-09T12:10:49+03:00',
    'dateModified'     => '2017-06-09T12:10:49+03:00',
    'image'            => [
        'type' => 'ImageObject',
        'url'  => 'http://example.com/logo/imge.png',
        'width'  => '850',
        'height' => '350'
    ],
    'publisher'        => [
        'type' => 'Organization',
        'name' => 'SomeBlogSite',
        'logo' => [
            'type'   => 'ImageObject',
            'url'    => 'http://example.com/logo/imge.png',
            'width'  => '600',
            'height' => '150'
        ],
    ],
    'mainEntityOfPage' => [
        'type' => 'WebPage',
        'id'   => 'http://example.com/lobby/slug',
    ],
    'author'           => [
        'type' => 'Person',
        'name' => 'Person name',
    ],

]);

echo $JSONsructuredData;

Output is
<script type="application/ld+json">{"@context":"http:\/\/schema.org","@type":"BlogPosting","name":"Test post title","image":{"@type":"ImageObject","url":"http:\/\/example.com\/logo\/imge.png","height":"350","width":"850"},"publisher":{"@type":"Organization","name":"SomeBlogSite","logo":{"@type":"ImageObject","url":"http:\/\/example.com\/logo\/imge.png","height":"150","width":"600"}},"dateModified":"2017-06-09T12:10:49+03:00","datePublished":"2017-06-09T12:10:49+03:00","author":{"@type":"Person","name":"Person name"},"mainEntityOfPage":{"@type":"WebPage"},"headline":"Test post title"}</script>

Headline at the end of output (last property)

This seems like it's not an issue


Bench the sad function for 8 bit and 10 bit

They have different paths and ASM functions.

Maybe we should have two tests instead?

Coverage remained the same at 82.647% when pulling 5d6c7b17ac78a25aeb2bab1a076a64f4be1b987f on magwyz:bench-sad-u8-u16 into 9317e7d2323c36d2e2667576384a0c6463a89ca3 on xiph:master.

Maybe we should have two tests instead?

I would lean towards yes, since it would make it easier to identify whether a regression affects one path or the other (or both) without modifying the test.


grt: Algorithm should not change with execution time

Remove some strange code which measures the time taken to execute a
chunk of code, and then makes decisions based on that.
Signed-off-by: Anton Blanchard<EMAIL_ADDRESS>

A lot of the CI fails look like small differences in grt stats output, which is expected.

@antonblanchard I'll start a secure ci run with your updates before approving this PR. Meanwhile, could you update the ok files for the grt failing tests?

The changes look fine to me - I'll leave it to you and Eder to work out the CI issues and approve.

@eder-matheus Could do with some double checking. I had to manually do save_guideok for each test that mentioned differences in the test output, rerun the regression tests and finally save_ok failures. Makes me wonder if I am missing something.

Thanks, @antonblanchard. The public CI is green, now I'm just waiting for the secure CI to end.

@antonblanchard please update your branch with the latest master branch. We have two new grt tests that require updates in the ok files after your changes.

@eder-matheus updated to master


Specify the order of tests

You should be able to specify the order in which tests are run. Right now tests are run in alphabetical order. Since some contracts might depend on other contracts working it is confusing if the dependant contract runs first. Therefore it would be nice to be able to specify the order in a config file.

Thanks @oed

Since some contracts might depend on other contracts working it is confusing if the dependant contract runs first

Your test files shouldn’t be dependent on each other. Your contracts can be, but your test files shouldn’t. That said, every test file has access to all contracts, and every test file gets contracts redeployed before the tests in the file run. So as far as running is concerned, order of test files shouldn’t matter. Order of tests on the other hand (it “…”) are run in the order they’re listed in the test file, I believe.

yes I have hit the same issue.  To test the time-dependent functionality of my smart contracts I have time-travelled the testnet which then causes many of the subsequent tests to fail. I need the time travelled tests to run last.


ExtraSound settings are not saved

When re-entering ExtraSound settings, Item drop, Empty Hotbar, Footstep, Effects, Poof parameters do not save the changed values, but are reset to default values, but the sliders work properly

I am experiencing the same issue, changing any of the on/off settings does not work, they revert to their original values immediately after leaving the extra sounds menu, i have experienced this on 1.20.1 fabric

well it did save but it doesn't change ui, ok I wil fix it soon