No /sys/kernel/debug/qat_* files for c6xx devices

QAT specific debug files are not present under /sys/kernel/debug/.
Following is the details:
Machine Info:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-39
Thread(s) per core:    2
Core(s) per socket:    20
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Gold 6210U CPU @ 2.50GHz
Stepping:              7
CPU MHz:               1110.948
CPU max MHz:           3900.0000
CPU min MHz:           1000.0000
BogoMIPS:              5000.00
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              28160K
NUMA node0 CPU(s):     0-39
QAT driver:
Version: 1.7.l.4.9.0-00008
./configure --enable-icp-debug
QAT Device:
There is 2 QAT acceleration device(s) in the system:
qat_dev0 - type: c6xx,  inst_id: 0,  node_id: 0,  bsf: 0000:19:00.0,  #accel: 4 #engines: 8 state: up
qat_dev1 - type: c6xx,  inst_id: 1,  node_id: 0,  bsf: 0000:1a:00.0,  #accel: 4 #engines: 8 state: up

QAT specific debug files are not present under /sys/kernel/debug/.

did you reload the out-of-tree driver?

I didn't explicitly reload the driver.
As part of 'make install' driver is loaded.
lsmod | grep qa
qat_c62x               20480  2
intel_qat             192512  13 qat_c62x,usdm_drv
uio                    20480  17 intel_qat

QAT specific debug files are not present under /sys/kernel/debug/.

did you reload the out-of-tree driver?

@mythi
I am stuck at this point. Please let me know if there is any way to fix this issue. I compiled QAT-1.7 without any additional configuration.
Just used, ./configure
Thanks

@nitishroy84 do you have debugfs mounted in your distro? any errors in dmesg for QAT?

@nitishroy84 do you have debugfs mounted in your distro? any errors in dmesg for QAT?

Oops...no debugfs mounted on that machine. It is working now.
Thanks a lot !!!

Debugfs should be mounted. If there is no debugfs mounted it should be logged in Syslog.Will file separate issue for the same.
Thanks @mythi

If there is no debugfs mounted it should be logged in Syslog

fw_counters is a service that the kernel driver/firmware provides and it has a dependency to debugfs.


reuse url encoding from url crate, don't use separate percent-encoding

Reuse encoding from url, don't use separate percent-encoding.

There is similar one use with percent-encoding
https://github.com/rust-lang/cargo/blob/ddfe87fc468bee4885650f6beda4ba94f097c508/crates/crates-io/lib.rs#L347-L353
and url
https://github.com/rust-lang/cargo/blob/ddfe87fc468bee4885650f6beda4ba94f097c508/crates/crates-io/lib.rs#L509-L513
but i don't have good (and simple) idea what to do.

Thanks! The example in the crates-io is more difficult since it's a relative URL, and the Url crate can't handle that. The other example doesn't use URL encoding at all, so I think it's fine as-is.
@bors r+

:pushpin: Commit 37d429ca67936f55653837b8cad466e23de28468 has been approved by arlosi
It is now in the queue for this repository.

:sunny: Test successful - checks-actions
Approved by: arlosi
Pushing b6c7fbeb13448dc0c6ae5d214f0968ca7befaa4f to master...

Are there tests for the encoding of +? I don't want to break existing use cases re: https://github.com/rust-lang/crates.io/issues/4891

Are there tests for the encoding of +? I don't want to break existing use cases re: rust-lang/crates.io#4891

No, i don't see tests for that.
cargo search "hello+f" --limit 101
cargo run search "hello+f" --limit 101

both: (go to https://crates.io/search?q=hello%2Bf to see more)

but here the diff
 cargo search "hello+f" --limit 101
(go to https://crates.io/search?q=hello%2Bf to see more)

cargo run search "hello+f" --limit 101
(go to https://crates.io/search?q=hello+f to see more)

crates.io can handle both encodings of   (space) in the query string (%20 and and +). + must always be encoded as %2B
I think there's a copy-paste error in your diff. Searching for "hello f" produces %20 on existing Cargo.
 cargo search "hello f" --limit 101
(go to https://crates.io/search?q=hello%20f to see more)

crates.io can handle both encodings of   (space) in the query string (%20 and and +).

Yes.

+ must always be encoded as %2B

I think you have it backwards. https://static.crates.io/crates/libgit2-sys/libgit2-sys-0.12.25+1.3.0.crate works but https://static.crates.io/crates/libgit2-sys/libgit2-sys-0.12.25%2B1.3.0.crate dose not. This is a bug in crate.io, or really a bug in s3, but we can not start hitting it.

This is a bug in crate.io, or really a bug in s3, but we can not start hitting it.

I think it's a bug in Cargo & crates.io. We should be encoding the + in the URL. However, fixing it would be a significant breaking change. The actual files in S3 are storing the + as a  .

for cross-referencing, I've posted my investigation results at https://github.com/rust-lang/crates.io/issues/4891#issuecomment-1580879109 :)


Openssl 1.1.0i fails a test in debug

Specs:
OS: Win7 x64
Compiler: VS2015 Update 3
OpenSSL: 1.1.0i
Problem:
nmake test fails on openssl-1.1.0i for one of the tests under debug configuration:
perl Configure debug-VC-WIN64A no-shared --debug --prefix="C:\My libs\OpenSSL\1.1.0i\Debug64"

Everything passes fine under release configuration.

I searched a little and found issue #6953.

cc @mattcaswell

Output of nmake V=1 TESTS=test_err test:
Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

	"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" depend && "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" _tests

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

	mkdir .\test\test-runs
A subdirectory or file .\test\test-runs already exists.
	set SRCTOP=.
	set BLDTOP=.
	set RESULT_D=.\test\test-runs
	set PERL=C:\Program Files\Perl64\bin\perl.exe
	set OPENSSL_ENGINES=C:\Users\JustinBieber\Desktop\openssl-1.1.0i_DEBUG\engines
	set OPENSSL_DEBUG_MEMORY=on
	"C:\Program Files\Perl64\bin\perl.exe" ".\test\run_tests.pl" test_err
test\recipes\04-test_err.t ..
1..1
..\errtest.exe: 1 test case
** preserves_system_error failed **
--------
..\errtest.exe: 1 test failed (out of 1)
..\errtest.exe => 1
not ok 1 - running errtest
#   Failed test 'running errtest'
#   at C:\Users\JustinBieber\Desktop\openssl-1.1.0i_DEBUG\util\perl/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Test Summary Report
-------------------
test\recipes\04-test_err.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1, Tests=1,  0 wallclock secs ( 0.03 usr +  0.00 sys =  0.03 CPU)
Result: FAIL
NMAKE : fatal error U1077: '"C:\Program Files\Perl64\bin\perl.exe"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.

Thank you @Justin-Bieber for sending us the test output. Your issue is a duplicate of issue #6953. Please follow that issue, a patch should appear shortly. Closing this one.


How to get url from site tree id

Hi
i am using link filed as many and front end getting value like below.
In this i dont know how to get url from sitetreeid .
<% loop $Buttons %>
<% if $Type == "URL" %>
$Title
<% else_if $Type == "Email" %>
$Email
<% else_if $Type == "Phone" %>
$Phone
<% else_if $Type == "File" %>
$File
<% else %>
pp $Page pp
$getpagebyid($SiteTreeID)
<% end_if %>
<% end_loop %>

Use the has_one returned object through $SiteTree (without the ID).

@Thiyagarajantender is this still an issue that needs to remain open?


WIP [TEVA-1343] Replace HAML with Slim

Jira ticket URL
https://dfedigital.atlassian.net/browse/TEVA-1343

Review app deployed to https://teaching-vacancies-review-pr-2540.london.cloudapps.digital


release 0.25.1

r? @reitermarkus
(rust-highfive has picked a reviewer for you, use r? to override)


crawl: 0.21.1 -> 0.22.0

Motivation for this change
crawl update
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

Both crawl and crawl-tiles binaries works (crawl and crawlTiles packages).
@abbradar

While you're at it, would you mind quoting the variable in patchShebangs $i? Also just in case you know what the purpose of the patch is, it would be nice to document that.

@timokau I'm sorry, but my time was only enough to update the version :)
crawl_purify.patch changes SQLITE_INCLUDE_DIR  in /crawl-ref/source/Makefile
It also changes /crawl-ref/source/util/find_font script (FONTDIRS value, find now has an -L flag)

Well I would appreciate if you make the change once you find the time :)
Now that I think about it that for loop should be unnecessary anyways, patchShebangs 'util' should work just as well. Please also add an explanation comment to the patch ("Patch hard-coded paths in the makefile"). If you want to go the extra mile, it would be best to contact upstream and ask them about configurability. But that's not a hard requirement for me to merge this.

I've made some changes (including changes to all-packages.nix).
In fact, I used to be a crawl contributor.  But now I'm much more interested in roguelikes such as IVAN or NetHack. So I wouldn't want to spend a lot of time on crawl. However, this time (0.22.0) the crawl-tiles interface looks great  :smiley:
The serious problem is that the file init.txt, which defines the crawl configuration (including language), is loading from the nix store.  Thus, it is not possible to play with a configuration other than the default configuration :cry:

From: Timo Kaufmann<EMAIL_ADDRESS>To: NixOS/nixpkgs<EMAIL_ADDRESS>Cc:
Bcc:
Subject: Re: [NixOS/nixpkgs] crawl: 0.21.1 -> 0.22.0 (#44882)
Reply-To:
In-Reply-To<EMAIL_ADDRESS>On 18-08-11 08:36, nonfreeblob wrote:

I've made some changes (including changes to all-packages.nix).

Thanks :)

The serious problem is that the file init.txt, which defines the crawl configuration (including language), is loading from the nix store.  Thus, it is not possible to play with a configuration other than the default configuration :cry:

That sounds like it really should be a user-configuration and not part of the package. It would be best to fix that. But if its not a regression and you don't want to spend the time, I'm happy with the PR as-is.
I'm not sure why you made the all-packages.nix change, but I don't have much of an opinion about that either way. The old way had the advantage/disadvantage that an override to crawl would automatically propagate to crawl-tiles.

init.txt

By the way, stuff like code, filenames etc. is usually enclosed in backticks in markdown, like this: `init.txt` (init.txt). You can also enclose larger code segments in three backticks:
multi
line

@grahamcofborg build crawl crawl-tiles

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: crawl, crawl-tiles
Partial log (click to expand)
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Cannot nix-instantiate `crawl-tiles' because:
error: attribute 'crawl-tiles' in selection path 'crawl-tiles' not found

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: crawl, crawl-tiles
Partial log (click to expand)
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Cannot nix-instantiate `crawl-tiles' because:
error: attribute 'crawl-tiles' in selection path 'crawl-tiles' not found

Success on aarch64-linux (full log)
Attempted: crawl
The following builds were skipped because they don't evaluate on aarch64-linux: crawl-tiles
Partial log (click to expand)
Cannot nix-instantiate `crawl-tiles' because:
error: attribute 'crawl-tiles' in selection path 'crawl-tiles' not found

these derivations will be built:
  /nix/store/0w11xajz1mi7nmiwb31ahi8y4hjfhrwg-crawl-0.22.0.drv
waiting for locks or build slots...
/nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0

Success on aarch64-linux (full log)
Attempted: crawl
The following builds were skipped because they don't evaluate on aarch64-linux: crawl-tiles
Partial log (click to expand)
chown 2>/dev/null  /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0/bin/crawl || true
chmod 2>/dev/null  /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0/bin/crawl || true
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0
shrinking /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0/bin/crawl
strip is /nix/store/ah0va6j4cnwj9nx4j6rwcfc8nh785jwm-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0/bin
patching script interpreter paths in /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0
checking for references to /build in /nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0...
/nix/store/dfhzcnc28wqhgxlssryyna007x1irmm9-crawl-0.22.0

Success on x86_64-linux (full log)
Attempted: crawl
The following builds were skipped because they don't evaluate on x86_64-linux: crawl-tiles
Partial log (click to expand)
chown 2>/dev/null  /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0/bin/crawl || true
chmod 2>/dev/null  /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0/bin/crawl || true
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0
shrinking /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0/bin/crawl
strip is /nix/store/gpc2wld1s0c6qzx9326cwn1wcx29xzsj-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0/bin
patching script interpreter paths in /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0
checking for references to /build in /nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0...
/nix/store/d7j3h5kfj5p7nzd0bfs4ddrszf2cl9w2-crawl-0.22.0

Thanks! :)

I'm not sure why you made the all-packages.nix change, but I don't have much of an opinion about that either way. The old way had the advantage/disadvantage that an override to crawl would automatically propagate to crawl-tiles.

We had some discussion on this topic: https://github.com/NixOS/nixpkgs/pull/42766 (outdated branch).
Although I personally have no preference on how it will be better. But if crawl be deleted or renamed, crawlTiles is also unavailable, I think.

By the way, stuff like code, filenames etc. is usually enclosed in backticks in markdown, like this: init.txt (init.txt). You can also enclose larger code segments in three backticks:

Thanks! I'll keep that in mind. I'm just a little lazy for quality markup  :smiling_imp:

That sounds like it really should be a user-configuration and not part of the package. It would be best to fix that. But if its not a regression and you don't want to spend the time, I'm happy with the PR as-is.

I'm afraid I'm not ready to do that :expressionless:

Maybe I did misunderstand him  :disappointed:  Fortunately, all this can be easily fixed at any time.
Thanks for merging the pull requests and for your patience! :ok_hand:


Slightly improve cxxabi demangler for real this time

Is it documented anywhere that __cxa_demangle's status may safely be a nullptr?

We talked on discord, thanks for updating it. The PR doesn't change much but it can't hurt so I'm happy to merge it. Thanks for the contribution!


ref(registry): change the create_bucket script to avoid allow 'ListAllMyBuckets' on S3 Policy

Use s3.lookup method to identify bucket name instead of list and expose all bucket names to deis cluster.

This looks like it should work just fine. For reference: http://boto.readthedocs.org/en/latest/ref/s3.html#boto.s3.connection.S3Connection.lookup

Attempts to get a bucket from S3. Works identically to S3Connection.get_bucket, save for that it will return None if the bucket does not exist instead of throwing an exception.

@rvaralda If we're making the change for registry, perhaps we should also update database as part of this PR? It does the same thing: https://github.com/deis/deis/blob/2333ccdc19969a6affa1b8b2225b88d186a2af33/database/templates/create_bucket#L15

That's right, I will update and push it.

o/


add warning for GDAL 3 + proj6

ref: https://github.com/RemotePixel/amazonlinux/issues/10#issuecomment-555753913

this is now understood and fixed, the performances downgrade was due to proj version6.2 requiring sqlite3 version > 3.11
ref https://github.com/RemotePixel/amazonlinux/issues/16#issuecomment-559599721


Show parent comments of Reddit user rss feed in Reddit bridge

Is your feature request related to a problem? Please describe.
The Reddit bridge allows a user feed to be generated with options like comments, minimal score, and section (hot, new, and top). But the feed would just show the reddit user's  comments without context with what they are replying to.
Describe the solution you'd like
An option where parent comments are included in the feed when the user is replying to someone.
Example:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Replying to /u/redditor1:
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
An alternative solution would be to link to the parent comment.
Additional context
@dawidsowa is the maintainer of the Reddit bridge.

JSON that is used to generate RSS feed doesn't have in it text of the parent comment, nor even username of it's author, so it's not possible to get it without making additional requests. One for each comment.
But link to the parent comment would be trivial to implement. I don't think there would be any harm in adding it by default.

I found https://github.com/RSS-Bridge/rss-bridge/issues/2770 while researching this. Let's not introduce additional network calls. A link is fine.


Folder data

Thank you for working to support folders. Would you consider adding another conversion option that includes the folder data in a geojson file along with the style and other data you already include? This would be very helpful. There's an approach that will do this by numbering the folder levels and making them geojson properties. The first folder encountered would be "folder0". If it has a description with it that would be "description0". The description numbers would always match the folder number they accompany in the KML. In the rare case that there is a folder with no placemarks in it, the folder name and description would be ignored.
Below is an example of what this conversion process would look like. It would help to treat the file name as the first folder entry if multiple converted KMLs are later combined, so that's what I've done. KMLs can include other KMLs which results in the  tag being used. But like the  tag, it can be treated as another folder. A folderpath property would also be helpful.
Point in KML
<Document>
<name>Bob's_Canada_Map.kml</name>
<Folder>
  <name>Canada_Map</name>
  <Document id="root_doc">
    <name>Alberta</name>
    <Folder>
      <name>Calgary</name>
      <description>Largest city in Alberta</description>
      <Folder>
        <name>Architecture</name>
        <Placemark>
          <name>Shops</name>
          <description>Scotia Centre</description>
          <Point>
            <coordinates>-114.0661567,51.0460943,0</coordinates>
          </Point>
        </Placemark>

Point in geojson
{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -114.0661567,
                    51.0460943,
                    0
                ]
            },
            "properties": {
                "name": "Shops",
                "description": "Scotia Centre",
                "folderpath": "Bob's_Canada_Map.kml/Canada_Map/Alberta/Calgary/Architecture",
                "folder0": "Bob's_Canada_Map.kml",
                "folder1": "Canada_Map",
                "folder2": "Alberta",
                "folder3": "Calgary",
                "description3": "Largest city in Alberta",
                "folder4": " Architecture"
            }
        },

I'm hesitant to include this in the core of this project. There's no real way to represent folders as a property in a way that's unambiguous and wouldn't clobber other properties.


[Cosmos DB] az cosmosdb: add exists command to database and container groups

Description of PR (Mandatory)
This change addresses https://github.com/Azure/azure-cli/issues/12668 by adding supports for "exists" in the new commands that replace the deprecated "cosmosdb database" and "cosmosdb collection" commands. It also updates parameter descriptions to address https://github.com/Azure/azure-cli/issues/13096
These commands are added:
az cosmosdb sql database exists
az cosmosdb sql container exists
az cosmosdb mongodb database exists
az cosmosdb mongodb collection exists
az cosmosdb gremlin database exists
az cosmosdb gremlin graph exists
az cosmosdb cassandra keyspace exists
az cosmosdb cassandra table exists
az cosmosdb table exists
Testing Guide
(Example commands with explanations)
History Notes:
(Fill in the following template if multiple notes are needed, otherwise PR title will be used for history note.)
[Component Name 1] (BREAKING CHANGE:) (az command:) make some customer-facing change.
[Component Name 2] (BREAKING CHANGE:) (az command:) make some customer-facing change.

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

add to S168

@Juliehzl can you please review this PR?

@shurd  LGTM in general. But could you resolve all conflicts and I will merge it for you?

add to S170

@shurd please resolve the conflicts.

add to S171

@yonzhan @Juliehzl I believe the conflicts are now resolved


Issue with reproducing pretraining

Hi, Great work! I pre-trained the network using the provided script with the full AudioSet (unbalanced + balanced), similar to BEATs and AudioMAE. So my pre-training set is slightly larger than yours (1.93M samples). I trained for 10 epochs (40K updates) using the provided script. However, I am unable to reproduce the reported AS20K performance, achieving only around 35.8 mAP compared to the reported 40.2 mAP. I fine-tuned on AS20K using the shared pre-trained weights(EAT-base_epoch10.pt) and achieved the reported performance, so I don't think there is an issue with the dataset. Am I missing something here?

Thanks for following our work!
Here are some possible reasons or advice:

Have you checked your pre-training script and configs to ensure they are the same as ours? Minor differences can lead to significant variations in pre-training results.

Make sure your PyTorch version matches the one specified in our requirements.txt. Some users have experienced reproducing failures using older versions of PyTorch (e.g., 1.x). Additionally, we did not use the Apex library for acceleration in our experiments.

You can compare and validate your results with our training logs available here in wandb.

Feel free to reach out if you have any other questions!


Fiat value not updating

I had Electrum Wallet running with fiat values for each address updating each time it was loaded. However, since I loaded EPS and got it working so the wallet points to it, I have not seeing it update it anymore, although the old values are still showing for each address.
Running: Eelectrum-wallet 3.3.8 and electrum-personal-server-electrum-personal-server-v0.1.7

Thanks for the issue, I'll try to reproduce it.


Partial Evaluation  support

Can we support Partial evaluation ?

https://www.openpolicyagent.org/docs/latest/policy-performance/
https://blog.openpolicyagent.org/partial-evaluation-162750eaf422
Let me know if you require sample partial evaluation policy data and input.

I don't know how that applies to the Wasm side of things, but I haven't looked at https://github.com/open-policy-agent/npm-opa-wasm in a long time.


internal.kafka.reporter.cluster.bootstrap.servers cannot connect to Confluent Cloud

We use a quite common infrastructure for our Kafka ecosystem: the Kafka brokers + schema registry are hosted in/by Confluent Cloud, and we host the Kafka Connect cluster ourselves. All this works well when the Kafka Connect cluster is configured properly: ssl, api-keys, etc.
We are investigating whether to use kafka-connect-file-pulse connector for file reading. It seems to work well on a local Kafka environment. However, the connector tracks file status on a designated Kafka topic. In order to do so it requires the following settings "internal.kafka.reporter.bootstrap.servers".
The file pulse connector uses this property to create an extra/internal connection to our Kafka broker. Most probably because doing so requires more than just the bootstrap.server, it fails with this message:
[Producer clientId=producer-5] Connection to node -1 (aws.confluent.cloud.hostname:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient:748)
Is this a common or known issue? Is there a work-around, perhaps another way of status tracking that does not require this property be set?

Hi @LeonardoBonacci , maybe this issue can help you #19 .
The ConnectFilePulse uses an internal topic to synchronize the tasks and the connector instance. For doing this, it creates a dedicated producer/consumer instance.
Unfortunately (but for security purpose) a connector cannot get access to the worker config. So you also have to configure the internal producer/consumer for the connector.

Hi @LeonardoBonacci did you solve your problem? If so, can you close the issue? If not, how can I help you?

Hi there! Thanks for you inquiry. We've ended up using the spooldir connector. It covered the functionality required for our simple use case.
I hereby close the ticket.


filters in emmet.syntaxProfiles is not honored

According to https://docs.emmet.io/customization/syntax-profiles/#create-your-own-profile, filters in emmet.syntaxProfiles are the default set of filters to be applied
This doesn't work in Emmet 2.0

In tonight's Insiders (Sept 1), you can set either c for comment filter or bem for the bet filter in emmet.syntaxProfiles setting and it will be used. All other filters will be ignored as we don't support them yet.
Note to verifier
Set
"emmet.syntaxProfiles": {
     "html": {
          "filters": "c"
      }
}

And any emmet abbreviation in an html file using the . or # operator will get comments in the expanded text as per https://docs.emmet.io/filters/#comment-tags-c. You don't have to add |c in the end
In the above setting, set bem instead of c and any emmet abbreviation in an html file using the __ operator as per https://docs.emmet.io/filters/bem/ will use the bed filter. You don't have to add |bem in the end

cc @sjelfull


--queue suffers from corruption on power cuts

See https://github.com/peter-wangxu/persist-queue/issues/180
Possible workaround is to use the SQLite-based queue instead.

Hmm, with some further thinking...

This is not satisfied by the default tempdir setting when running in a docker container (with a mounted path for the actual queue).

On the other hand, the default behavior should handle this...
https://github.com/peter-wangxu/persist-queue/blob/master/persistqueue/queue.py#L101-L107


how to fix this crash

Describe your bug here.
cras
PsychEngine_2022-07-05_19'41'04.txt
h
Command Prompt/Terminal logs (if existing)
Note.hx (line 124)
PlayState.hx (line 2353)
PlayState.hx (line 1053)
flixel/FlxGame.hx (line 637)
flixel/FlxGame.hx (line 724)
flixel/FlxGame.hx (line 677)
flixel/FlxGame.hx (line 545)
openfl/events/EventDispatcher.hx (line 402)
openfl/display/DisplayObject.hx (line 1399)

Uncaught Error: Null Object Reference

how to fix

Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
i ported songs but

i know its doing the same thing with me

Somethings wrong with your notes...
If the song your porting has different note skins than the normal ones thats your problem...

Somethings wrong with your notes...
If the song your porting has different note skins than the normal ones thats your problem..,

wait, you mean if i changed the color notes in the options? (also i didn't add any special notes)

Somethings wrong with your notes...
If the song your porting has different note skins than the normal ones thats your problem..,

wait, you mean if i changed the color notes in the options? (also i didn't add any special notes)

No lol...
I looked in the source code where it said something happened and it said it had a problem loading the notes...
"null object reference" means that somethings not there whether it be an animation in the XML or a nonexistent image...


Updated NIST SP 800-53 security controls

Moved policy-scc.yaml, policy-psp.yaml, policy-etcdencryption.yaml and policy-limitmemory.yaml to the SC-System-and-Communications-Protection control family. The changes are inspired by the next documents -

https://www.redhat.com/cms/managed-files/cl-openshift-applicability-guide-fisma-moderate-analyst-paper-f15232bf-201811-en.pdf
https://atopathways.redhatgov.io/ato/products/openshift-container-platform-4/NIST-800-53#SC-6

@gparvin @dockerymick Would be happy if you reviewed the PR, thanks :D
/assign @gparvin


Fix typo

 Issue by dracan
Thursday May 16, 2019 at 06:18 GMT
Originally opened as https://github.com/Wyamio/Wyam.Web/pull/87

dracan included the following code: https://github.com/Wyamio/Wyam.Web/pull/87/commits

See b768366aa4dc05c119fd497cbac0100e4a12ea8c


Implement type parameter constraints

Fix #227

When augmenting a method call, handle the case where the dispatch type is a type variable which is known to implement the typeclass.


ErrorResponse fix

fix Vertica reference errors
fix linting some errors

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


feat: Update GovBanner to match USWDS 2.8.0 release

Summary
Related Issues or PRs
closes #456
How To Test
Verify copy changes in Storybook for .gov and .mil versions of the banner for both English and Spanish
Screenshots (optional)
Storybook stories:

defaults to "english" & ".gov":

with "english" and ".gov" passed:

with "english" and ".mil" passed:

with "spanish" and ".gov" passed:

with "spanish" and ".mil" passed:

Warnings

:warning:
This PR does not include changes to tests, even though it affects source code.

  Generated by :no_entry_sign: dangerJS against f8db555f412ea59ea6758ad81bcbb63eee9ae1c2

Warnings

:warning:
This PR does not include changes to tests, even though it affects source code.

  Generated by :no_entry_sign: dangerJS against f8db555f412ea59ea6758ad81bcbb63eee9ae1c2

Warnings
⚠	This PR does not include changes to tests, even though it affects source code.
Generated by 🚫 dangerJS against f8db555

I'm curious what reviewers think about for testing this story.
I'm cautious to test against specific verbiage being rendered, as that makes for tests that are low in value in terms of likelihood in catching breaking changes, but do make future updates more disproportionally cumbersome. Using something like Enzyme would allow testing of actual property values, which would allow us to test default values for props when not explicitly passed. What are your thoughts on that?
In 7efcce7 I added a basic test verifying render with the newly added props. I'd be happy to expand on that by testing the actual verbiage if maintainers agree there is value in that kind of test.

Warnings
⚠	This PR does not include changes to tests, even though it affects source code.
Generated by 🚫 dangerJS against f8db555

I'm curious what reviewers think about for testing this story.
I'm cautious to test against specific verbiage being rendered, as that makes for tests that are low in value in terms of likelihood in catching breaking changes, but do make future updates more disproportionally cumbersome. Using something like Enzyme would allow testing of actual property values, which would allow us to test default values for props when not explicitly passed. What are your thoughts on that?
In 7efcce7 I added a basic test verifying render with the newly added props. I'd be happy to expand on that by testing the actual verbiage if maintainers agree there is value in that kind of test.

@suzubara / @haworku --- I didn't make it all the way through the happo diff, but is it normal to see so many false positives? when I saw the uswds bump I thought that might be the trigger, but switching to diff view the vast majority of components seem to have no visible changes. any idea why these are showing seemingly empty diffs or whether that's a normal behavior here?
literally the only change I saw in the components I reviewed was the warning icon changing ever so slightly.

@suzubara / @haworku --- I didn't make it all the way through the happo diff, but is it normal to see so many false positives? when I saw the uswds bump I thought that might be the trigger, but switching to diff view the vast majority of components seem to have no visible changes. any idea why these are showing seemingly empty diffs or whether that's a normal behavior here?
literally the only change I saw in the components I reviewed was the warning icon changing ever so slightly.

@suzubara / @haworku --- I didn't make it all the way through the happo diff, but is it normal to see so many false positives? when I saw the uswds bump I thought that might be the trigger, but switching to diff view the vast majority of components seem to have no visible changes. any idea why these are showing seemingly empty diffs or whether that's a normal behavior here?
literally the only change I saw in the components I reviewed was the warning icon changing ever so slightly.

@sojeri I meant to address that here as well with my understanding of a lot of it. Indeed, it looks like some of the icons may have changed ever so slightly. I also noticed the note at the top of Happo:
Some updates were made to Happo workers that might cause unexpected diffs:
1/11/2021, 5:08:00 AM - Our Chrome workers have been updated to run Chrome version 88.

Many of the diffs were from Chrome.
There are some valid diffs from the 2.8.0 upgrade, for instance, the proper alignment of the collapse-icon for the GovBanner:

All that said, I am new to Happo, so I'm not sure what is normal to see.

@suzubara / @haworku --- I didn't make it all the way through the happo diff, but is it normal to see so many false positives? when I saw the uswds bump I thought that might be the trigger, but switching to diff view the vast majority of components seem to have no visible changes. any idea why these are showing seemingly empty diffs or whether that's a normal behavior here?
literally the only change I saw in the components I reviewed was the warning icon changing ever so slightly.

@sojeri I meant to address that here as well with my understanding of a lot of it. Indeed, it looks like some of the icons may have changed ever so slightly. I also noticed the note at the top of Happo:
Some updates were made to Happo workers that might cause unexpected diffs:
1/11/2021, 5:08:00 AM - Our Chrome workers have been updated to run Chrome version 88.

Many of the diffs were from Chrome.
There are some valid diffs from the 2.8.0 upgrade, for instance, the proper alignment of the collapse-icon for the GovBanner:

All that said, I am new to Happo, so I'm not sure what is normal to see.

In 7efcce7 I added a basic test verifying render with the newly added props. I'd be happy to expand on that by testing the actual verbiage if maintainers agree there is value in that kind of test.

Thanks for asking about tests, @brandonlenz !  imo we should add a basic test for the case where these new props are not passed in at all. That is how most people using this component right now out in the wild (since this is new work).  The component should still render with the English text and not break for those folks.
I hear you on Enzmye,  sounds like a bigger topic we could discuss. Want to make an issue about it? I don't think this should block this work from going through now. This def an outlier component because all it does really is display very specific text which we try to avoid (#124).

I didn't make it all the way through the happo diff, but is it normal to see so many false positives?
Um... sometimes. 😇 Lately Happo has been catching bugs for us and has been pretty on point. However, this does look like a bunch of false positives maybe related to what you all already identified. Especially when its just a few pixels change for unrelated components I usually push it through. Its approved now. ✅

In 7efcce7 I added a basic test verifying render with the newly added props. I'd be happy to expand on that by testing the actual verbiage if maintainers agree there is value in that kind of test.

Thanks for asking about tests, @brandonlenz !  imo we should add a basic test for the case where these new props are not passed in at all. That is how most people using this component right now out in the wild (since this is new work).  The component should still render with the English text and not break for those folks.
I hear you on Enzmye,  sounds like a bigger topic we could discuss. Want to make an issue about it? I don't think this should block this work from going through now. This def an outlier component because all it does really is display very specific text which we try to avoid (#124).

I didn't make it all the way through the happo diff, but is it normal to see so many false positives?
Um... sometimes. 😇 Lately Happo has been catching bugs for us and has been pretty on point. However, this does look like a bunch of false positives maybe related to what you all already identified. Especially when its just a few pixels change for unrelated components I usually push it through. Its approved now. ✅

In 7efcce7 I added a basic test verifying render with the newly added props. I'd be happy to expand on that by testing the actual verbiage if maintainers agree there is value in that kind of test.

Thanks for asking about tests, @brandonlenz ! imo we should add a basic test for the case where these new props are not passed in at all. That is how most people using this component right now out in the wild (since this is new work). The component should still render with the English text and not break for those folks.

@haworku The existing test for rendering the component without props should work for this purpose:
  it('renders without errors', () => {
    const { queryByTestId } = render(<GovBanner />)
    expect(queryByTestId('govBanner')).toBeInTheDocument()
  })

I hear you on Enzmye, sounds like a bigger topic we could discuss. Want to make an issue about it? I don't think this should block this work from going through now. This def an outlier component because all it does really is display very specific text which we try to avoid (#124).

Sure, I'll create an issue to start discussion on that. I can definitely see an argument being made to keep this repo lean.
Also thanks for linking #124. I definitely agree this could be slippery slope territory. For the purposes of this PR, if we only want to consider english for now I can remove the logic specific to "spanish", and add optional props in the spirit of

it sounds like we have agreement about using props (with English default values) to handle any necessary language strings (#124)

Otherwise I could see someone taking a look at what I've done here and implementing similar logic in the name of convention elsewhere.

In 7efcce7 I added a basic test verifying render with the newly added props. I'd be happy to expand on that by testing the actual verbiage if maintainers agree there is value in that kind of test.

Thanks for asking about tests, @brandonlenz ! imo we should add a basic test for the case where these new props are not passed in at all. That is how most people using this component right now out in the wild (since this is new work). The component should still render with the English text and not break for those folks.

@haworku The existing test for rendering the component without props should work for this purpose:
  it('renders without errors', () => {
    const { queryByTestId } = render(<GovBanner />)
    expect(queryByTestId('govBanner')).toBeInTheDocument()
  })

I hear you on Enzmye, sounds like a bigger topic we could discuss. Want to make an issue about it? I don't think this should block this work from going through now. This def an outlier component because all it does really is display very specific text which we try to avoid (#124).

Sure, I'll create an issue to start discussion on that. I can definitely see an argument being made to keep this repo lean.
Also thanks for linking #124. I definitely agree this could be slippery slope territory. For the purposes of this PR, if we only want to consider english for now I can remove the logic specific to "spanish", and add optional props in the spirit of

it sounds like we have agreement about using props (with English default values) to handle any necessary language strings (#124)

Otherwise I could see someone taking a look at what I've done here and implementing similar logic in the name of convention elsewhere.

Sure, I'll create an issue to start discussion on that. I can definitely see an argument being made to keep this repo lean.

Added #783

Sure, I'll create an issue to start discussion on that. I can definitely see an argument being made to keep this repo lean.

Added #783

Warnings

:warning:
It looks like there are new component (JSX/TSX) files, but the entrypoint (index.ts) has not changed. - Did you forget to export new components from the library entrypoint?

  Generated by :no_entry_sign: dangerJS against d8b3a91328130c5ac5f5101566543cdff025f0f7

Warnings

:warning:
It looks like there are new component (JSX/TSX) files, but the entrypoint (index.ts) has not changed. - Did you forget to export new components from the library entrypoint?

  Generated by :no_entry_sign: dangerJS against d8b3a91328130c5ac5f5101566543cdff025f0f7


5.4.2 not compatible with python 3

basestring was removed from python 3. For python 3, you need to compare it to str.

Perhaps this is a good time to start automatically testing the flask stuff as well. :P

Fixed in 5.4.3


No image gets downloaded

OS: Windows 10 64-bit
java -version:
java version "18" 2022-03-22
Java(TM) SE Runtime Environment (build 18+36-2087)
Java HotSpot(TM) 64-Bit Server VM (build 18+36-2087, mixed mode, sharing)

Version of lezhin-comics-downloader used: v2.9.0 (latest).
Command used: C:\Users\Utente\Downloads\Lezhin Comics Downloader v2.9.0>java -jar lezhin-comics-downloader.jar -l=en -n=onesmallstep -r=1~2 -j
Results:
C:\Users\Utente\Downloads\Lezhin Comics Downloader v2.9.0>java -jar lezhin-comics-downloader.jar -l=en -n=onesmallstep -r=1~2 -j
        Lezhin Comics Downloader v2.9.0
        If you have any questions, contact me by 'https://github.com/ImSejin/lezhin-comics-downloader/issues'
Starting ChromeDriver 107.0.5304.62 (1eec40d3a5764881c92085aaee66d25075c159aa-refs/branch-heads/5304@{#942}) on port 60004
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
nov 04, 2022 8:01:17 PM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: W3C
nov 04, 2022 8:01:17 PM org.openqa.selenium.devtools.CdpVersionFinder findNearestMatch
WARNING: Unable to find an exact match for CDP version 107, so returning the closest version found: a no-op implementation
nov 04, 2022 8:01:17 PM org.openqa.selenium.devtools.CdpVersionFinder findNearestMatch
INFO: Unable to find CDP implementation matching 107.
nov 04, 2022 8:01:17 PM org.openqa.selenium.chromium.ChromiumDriver lambda$new$3
WARNING: Unable to find version of CDP to use for . You may need to include a dependency on a specific version of the CDP using something similar to `org.seleniumhq.selenium:selenium-devtools-v86:4.1.2` where the version ("v86") matches the version of the chromium-based browser you're using and the version number of the artifact is the same as Selenium's.
        Request login page: https://www.lezhin.com/en/login
        Successfully logged in: access token(a3d4566d-281c-455b-ae24-bc6ba4571dbc)
        Request comic page: https://www.lezhin.com/en/comic/onesmallstep
onesmallstep ep.1   0% [>                ]  0/68 imgs (0:00:01 / ?) | ,0 imgs/s
onesmallstep ep.2   0% [>                ]  0/80 imgs (0:00:01 / ?) | ,0 imgs/s

C:\Users\Utente\Downloads\Lezhin Comics Downloader v2.9.0>

The above screen has always been like this and Your downloader has always worked perfectly until October 31st. I also specify that the downloader has already successfully extracted those chapters, as well as the following one; I also tried with already paid lezhin-comics' chapters.
In all cases, no images got downloaded; only the directories are created😰.

I suspect I've reported a serious or strange problem. But, is it just me the one who has this trouble with images' download?

I experience the same thing, If you hadn't open this thread I would've open one.

@Arekkusu1998
Sorry to slow response.
I found a cause of the issue, but current architecture needs to be changed to fix it.
So It takes time.

Thanks for Your kind reply @ImSejin: no problem for waiting. I supposed an upgrade was needed to fix the issue.

Thanks for Your kind reply @ImSejin: no problem for waiting. I'd assumed an upgrade was needed to fix this issue.

Downloader v3 is released!
Available on here!

C:\Users\WT>java -jar lezhin-comics-downloader-3.0.0.jar -l=en -n=chainofyouth -r=22~22
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Starting ChromeDriver 108.0.5359.71 (1e0e3868ee06e91ad636a874420e3ca3ae3756ac-refs/branch-heads/5359@{#1016}) on port 18077
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
Dec 15, 2022 8:15:34 AM org.openqa.selenium.devtools.CdpVersionFinder findNearestMatch
WARNING: Unable to find an exact match for CDP version 108, so returning the closest version found: 105
chainofyouth ep.22 100% [========] 20/20 imgs (0:00:01 / 0:00:00) | 20.0 imgs/s

In the latest version the image downloaded is smaller than if extracted manually

@yimeji
Thank you for your fast feedback!
I will check that.

@yimeji
I move that issue to #147 to detach it from the original issue.
I close this.


adding support for claude, azure, cohere, replicate

Hi @whitead
Noticed you're calling OpenAI w/ langchain. I'm working on litellm (simple library to standardize LLM API Calls - https://github.com/BerriAI/litellm) and was wondering if we could be helpful.
Added support for Claude, Cohere, Azure and Llama2 (via Replicate) by setting client in the langchain ChatOpenAI class. The code is pretty similar to the OpenAI class - as litellm follows the same pattern as the openai-python sdk.
Would love to know if this helps.
Happy to add additional tests / update documentation, if the initial PR looks good to you.

I was also searching for cohere support.
Adding +1 to the PR
Also, if needed help i could code, but the branch need to be clean and tests passing

Implemented by https://github.com/Future-House/paper-qa/pull/362


Add Multi-Release: true to Perf JARs

Description
Adds the Mutli-Release: true manifest entry to all-in-one/uber JARs used in performance testing. This will allow for any multi-release functionality defined in dependency libraries to be used.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

Closing as this won't be done


Add Github workflow to execute Go tests

Use Github actions to test pull requests.

Replaced by https://github.com/elastic/go-resource/pull/4


[b/357517011] Extract filenames from local filesystem

I could restrict the search to some paths (for example, /usr, /etc, /var), where these files are most likely to be found, but then if there is some custom environment, we would not discover these files' locations, which is undesirable. I understand that it might take hours. I don't see a way around it (besides not including such a task in the discovery process).
Shell is used only as a temporary solution, we can rewrite the shell scripts to another solution later.
I've tested it only on the small server, where scanning the whole filesystem takes a few minutes.


Support the next interop target

As described here, the next set of drafts to implement are (DAP-12):

draft-ietf-ppm-dap-12
draft-irtf-ppm-dap-taskprov-01 (WIP as of 2024/10/16)
draft-irtf-cfrg-vdaf-12 for the Prio3
We also might need to bump draft-dcook-ppm-dap-interop-test-design, but this needs discussion.

The draft set we currently support is (DAP-09):

draft-ietf-ppm-dap-09
draft-irtf-cfrg-vdaf-08 for Prio3
draft-wang-ppm-dap-taskprov-06
draft-dcook-ppm-dap-interop-test-design-07

We will need to add support for DAP-12 alongside DAP-09.
Requirements

The version of a VDAF, of taskprov, or of the interop API that is used is determined by the version of DAP.  In particular, we won't try to support multiple versions of a VDAF or of the taskprov extension with the same DAP version.
Our implementations of Prio2 and Prio3 come from the prio crate. Version 0.16 is compatible with DAP-09; a future version of the crate, perhaps 0.17, will be compatible with DAP-12. We will need to import both versions of the crate at the same time.
DAP-09 MUST support all VDAFs currently supported by the taskprov extension. This includes Prio2, PINE (see below), and some non-standard Prio3SumVec variants.
DAP-12 MUST support all currently supported VDAFs, excluding PINE: draft-chen-cfrg-vdaf-pine-01 is not API compatible with DAP-12, so for now we'll only maintain support for DAP-09.

Notes

DapVersion::Latest is currently set to DAP-10; this should be replaced with DAP-12.
The most important changes since DAP-09 are summarized in the draft's change log. Most are relatively minor, but it will be necessary to plumb the DAP version down more code paths to, for example, account for changes in message formats.
The most significant change since DAP-09 is asynchronous aggregation. This feature is optional, however, and we'll handle it in a separate issue. See #697.
Note that there are some known discrepancies between our implementation and the spec: see #522 and #557.

Validation

This repo has unit tests and end-to-end tests, but for the most part they don't enforce interop. We mainly rely on additional tests in the internal repo for the Helper deployment. These will be useful for making sure we don't regress DAP-09.
Janus is currently working on DAP-12 support as well. The interop/ folder in this directory defines a docker image they can use to automatically run a bunch of interop tests with our Helper; we can use this to test interop with DAP-12.

For the record, we're now targeting DAP-13.

Remaining TODOs as of 2024/12/19:

[ ] public extensions
[ ] improve extension points for batch modes
[ ] add start time to task parameters, replace end time with duration
[ ] taskprov: message formats
[ ] taskprov: derivation of the task ID and (maybe?) the verification key
[ ] allow the leader to indicate it doesn't support extensions

Here's the list of VDAFs we want to support for each version:

DAP-09

Prio2 (+taskprov)
Prio3 w/ XofHmacSha256Aes128 (+taskprov) (these are non-standard variants)
Pine (+taskprov)

DAP-13

Prio2 (+taskprov)
Standard Prio3 variants


Add Device Attestation validation to chip-cert tool for YAML test support

Problem
There is no "freestanding" implementation of the Device Attestation validation procedure that could be executed by implementers and by CSG test harness based on responses obtained, to ascertain the current validity of a given implementation.
Proposed Solution
In order to automate Device Attestation Procedure testing, we could have a command-line tool that can validate the AttestationResponse and and provide a result and logs, so that it can be wrapped in a delegated YAML command.
This will allow executing an instrumented view of the device attestation procedure.
The tooling could then be replaced in the future with an equivalent independent implementation.
Two commands are necessary:

Validation of AttestationSignature on AttestationResponse
Validation of AttestationSignature on NOCSRResponse

The common arguments for both:

PAI cert in DER, encoded as hex
DAC cert in DER, encoded as hex
Attestation Challenge from secure session, encoded as hex
Nonce (AttestationNonce, CSRNonce), encoded as hex
AttestationSignature (from either AttestationResponse or NOCSRResponse), encoded as hex

The specific arguments are either:

AttestationElements from AttestationResponse
NOCSRElements from NOCSRResponse

@tcarmelveilleux This seems important - should it remain in the 1.0 list?

Impact: 8 Device Attestation TCs
Priority: High

This is done.


Should we deprecate the compat and encoding constructor arguments?

In https://github.com/pydata/xarray/pull/1170#discussion_r94078121, @shoyer writes:

...I would consider deprecating the encoding argument to DataArray instead. It would also make sense to get rid of the compat argument to Dataset.
These extra arguments are not part of the fundamental xarray data model and thus are a little distracting, especially to new users.

@pydata/xarray and others, what do we think about deprecating the compat argument to the Dataset  constructor and the encoding arguement to the DataArray (and Dataset via #1170).

I don't have an opinion on compat (seems somehow unrelated to netCDF and https://github.com/pydata/xarray/issues/1170?), but I am +1 on encode. I always use encode when writing a dataset to disk, not at construction.

I haven't used these arguments in the constructors. But I don't find them distracting either.


[BUG] StackTraces allocate garbage when DebugMode = false

Was digging around because of this post: https://www.reddit.com/r/Unity3D/comments/177zvk5/unity_atoms_performance_is_horrible_but_it_doesnt/
and found that for simple integers / floats the following call boxes "item":
https://github.com/unity-atoms/unity-atoms/blob/master/Packages/Core/Runtime/Events/AtomEvent.cs#L104
Also the Get() implementation of the DebugMode flag always looks up the value from the EditorPrefs
https://github.com/unity-atoms/unity-atoms/blob/master/Packages/Core/Runtime/Preferences/AtomsPreferences.cs#L27

Great fidings! Fixed in #436


Can't move Spotify window

Do you have the latest versions of Spicetify, Spotify and Better Bloom?

[X] I'm using the latest versions of Spicetify, Spotify and Better Bloom

Is there already an issue for your problem?

[X] I have checked older issues, open and closed

Is your problem definitely caused by the theme?

[X] I have checked the app behavior without the theme and it is different

Environment & Computer Info
- Spotify version: <IP_ADDRESS>9.g606b7f29
- Installed from:Spotify site
- Spicetify version: v2.36.13
- Color scheme: -
- Extensions: -
- Custom apps: -
- Better Bloom installation method: Spicetify Marketplace

Description
Nothing much; I just can't move Spotify window to anywhere, maybe it's just a bug after Spicetify updated I've tried to disable theme; after disabling it, it function normally
Screenshots
No response

soory for the issue caused i will address it rn !


gitea: Added option sandbox to be able to disable systemd sanboxing

Motivation for this change
Add ability to disable systemd sandbox functionality in order to run gitea inside an lxd container.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"

[nix-shell:/tmp/nixpkgs]# nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
these paths will be fetched (0.03 MiB download, 0.13 MiB unpacked):
  /nix/store/91qp2v2h0fd9d6b6hchzf13zki091grv-nixpkgs-review-2.3.1
copying path '/nix/store/91qp2v2h0fd9d6b6hchzf13zki091grv-nixpkgs-review-2.3.1' from 'https://cache.nixos.org'...
$ git -c fetch.prune=false fetch --force https://github.com/NixOS/nixpkgs master:refs/nixpkgs-review/0
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 16 (delta 4), reused 3 (delta 3), pack-reused 3
Unpacking objects: 100% (16/16), 178.79 KiB | 660.00 KiB/s, done.
From https://github.com/NixOS/nixpkgs
   580a0e52b13..f9f48250fe1  master     -> refs/nixpkgs-review/0
$ git worktree add /root/.cache/nixpkgs-review/rev-4bf631ed876b8b63ff68c6cd3cba4a7d9ea53a03-dirty/nixpkgs f9f48250fe1657f288a88c8ef519576a7b12a31b
Preparing worktree (detached HEAD f9f48250fe1)
Updating files: 100% (22324/22324), done.
HEAD is now at f9f48250fe1 nixos/smartd: add option for notifiction email sender
$ nix-env -f /root/.cache/nixpkgs-review/rev-4bf631ed876b8b63ff68c6cd3cba4a7d9ea53a03-dirty/nixpkgs -qaP --xml --out-path --show-trace
No diff detected, stopping review...
$ git worktree prune

[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Can you explain the issues you are having in more detail please?
ping @flokli @Ma27 @Mic92 @Izorkin

@aanderse
Aug 04 13:52:40 nixos systemd[14745]: gitea.service: Executing: /nix/store/404wfnlg9dvlzphd955zlqfclsaa31aj-gitea-1.11.8-bin/bin/gitea web
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Child 14745 belongs to gitea.service.
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Main process exited, code=dumped, status=31/SYS
Aug 04 13:52:40 nixos systemd[1]: gitea.service: Failed with result 'core-dump'.

Since I already separate my services via lxd containers I don't see the point in additionally sandbox it via systemd.

cc @NixOS/systemd

I don't think we should have a sandbox flag for every systemd service. We introduce "sandboxing" in many services now. It's not a boolean flag, some features might not work in docker, some features might work in lxd. If systemd features don't work in LXD containers we should disable them in general for LXD instead of introducing a flag in every service.

@Mic92 You mean it should be checked for boot.isContainer? Maybe it would make sense to configure the sandboxing stuff on another level of systemd configuration so that the entire level could be enabled/disabled by boot.isContainer on a centralized level.

boot.isContainer also doesn't give you some information inside which container runtime it's running, and how cgroups are mounted in there.
I propose approaching systemd upstream here. This smells like some problem with not all cgroups being available inside lxd, and systemd failing ungracefully.

@asbachb  can try this variant:
systemd.services.gitea.serviceConfig = lib.mkForce {
  ProtectHome = false;
  PrivateDevices = false;
  ProtectKernelTunables = false;
  ProtectKernelModules = false;
  ProtectControlGroups = false;
...
};

@Izorkin Basically this kind of configuration prevents the app.in from beeing generated correctly.
Started another discussion on lxd forums: https://discuss.linuxcontainers.org/t/sandboxed-systemd-service-fails-due-to-cgroups-issue/8650/5

@Izorkin Basically this kind of configuration prevents the app.in from being generated.
Started another discussion on lxd forums: discuss.linuxcontainers.org/t/sandboxed-systemd-service-fails-due-to-cgroups-issue/8650/5

So maybe your solution is to use cgroup v2?


Don't depend on representable being local

This probably should not have been committed.

:grimacing:


[ImproveTLS] fix memory leak issue from users' perspective

This aims to solve the first issue mention here: https://github.com/grpc/grpc/issues/20161#issuecomment-590548552

@yihuazhang The failing tests seem irrelevant. Could you please take a look at this PR please?

@yihuazhang Thanks for the review! I've added some more comments on your review. PTAL, thanks :-)

None of the failed tests seems relevant. Merging now.
Note this PR only fixes the first issue in https://github.com/grpc/grpc/issues/20161#issuecomment-590548552. Fixes for the second issue will come up soon.


[RFC] callback based asyc_request feature

This is not a standard vim/neovim feature, But it seems to be needed for plugin communications
sketch:

let plug = yar#py3('...')

plug.asyc_request({'callback': 'callback_func', 'callback_data': {}}, method', args... )

func callback_func(callback_data, result_of_method)
  ...
endfunc

Cons:

It is hard to forward the error event to callback_func. We'll need global state in vimscript for this behavior

Close for now, I'll reopen when I have a more concrete use case


Align the template to use the correct image tag from Docker Hub

At the moment I believe we're just pulling from "latest" and we need our release process to update this to the tag in question during release.  Ultimately what this becomes is a discussion about: what is our release process, because it's more than simply tagging in Git and running a parameterized build in CI to push the appropriate Git refs to Docker Hub with a tag name; we need to update some source here too as part of it.

FYI @sabre1041 @tnozicka

Now the template that installs launchpad lives outside this repo, now in launchpad-templates; this resolves the release process circular dependency


Change the background opacity for the feedback form fields when not filled

reduce the opacity of the red background to 0.2
Change this:

result:

Now is in this way:

Do you want to apply that styles when error happend in all inputs?


Bundle fails RBAC

What happened?
Deploying the Prometheus Operator using the latest bundle.yaml from master gives issues with RBAC permissions.
kubectl apply -f  https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
Master currently at: https://github.com/coreos/prometheus-operator/commit/d1c3b3f6e6e2c29420a49404a943004ae3460bba
kl prometheus-operator-7676db7c9-sj7g2
ts=2020-04-29T13:42:44.77404249Z caller=main.go:209 msg="Starting Prometheus Operator version '0.38.0'."
ts=2020-04-29T13:42:44.779862337Z caller=main.go:99 msg="Staring insecure server on :8080"
level=info ts=2020-04-29T13:42:44.848251485Z caller=operator.go:452 component=prometheusoperator msg="connection established" cluster-version=v1.17.0
level=info ts=2020-04-29T13:42:44.934005052Z caller=operator.go:214 component=alertmanageroperator msg="connection established" cluster-version=v1.17.0
level=info ts=2020-04-29T13:42:45.03476712Z caller=operator.go:294 component=thanosoperator msg="connection established" cluster-version=v1.17.0
ts=2020-04-29T13:42:45.436600855Z caller=main.go:305 msg="Unhandled error received. Exiting..." err="getting CRD: Alertmanager: customresourcedefinitions.apiextensions.k8s.io \"alertmanagers.monitoring.coreos.com\" is forbidden: User \"system:serviceaccount:default:prometheus-operator\" cannot get resource \"customresourcedefinitions\" in API group \"apiextensions.k8s.io\" at the cluster scope"

Fixed by adding apiextensions.k8s.io and customerresourcedefinitions to ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
rules:
- apiGroups:
  - monitoring.coreos.com
  - apiextensions.k8s.io
  resources:
  - alertmanagers
  - alertmanagers/finalizers
  - customresourcedefinitions
  - prometheuses
  - prometheuses/finalizers
  - thanosrulers
  - thanosrulers/finalizers
  - servicemonitors
  - podmonitors
  - prometheusrules
  verbs:
  - '*'
- apiGroups:
  - apps
  resources:
  - statefulsets
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - configmaps
  - secrets
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
  - delete
- apiGroups:
  - ""
  resources:
  - services
  - services/finalizers
  - endpoints
  verbs:
  - get
  - create
  - update
  - delete
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch

Prometheus Operator version:

quay.io/coreos/prometheus-operator:v0.38.0

Kubernetes version information:

v1.17.0

Applying master bundle version with prometheus operator in version v0.38.0 won't work. You should use the same version of a bundle as prometheus-operator, in this case: https://github.com/coreos/prometheus-operator/blob/release-0.38/bundle.yaml
In https://github.com/coreos/prometheus-operator/pull/3155 we purposefully removed management of CRDs by prometheus-operator, so RBAC for CRD is no longer needed in a bundle.

@paulfantom Ah I see. Thanks very much.


Cluster related bugs

A bug in a tested database can cause many different tests to fail.
There should be a way to cluster bugs that are likely due to the same underlying problem - e.g., based on the top of the stack trace.
This could be beneficial for:

reporting purposes
filing bugs against other databases
ignoring known bugs that haven't been fixed yet

Maybe add a 'filter' mechanism. The filter is called with the executor name, file name and SQL text, and returns whether to skip the test, and/or modified SQL. Filters are orthogonal to executors.

This could have handled (worked around) the HSQLDB bug where '- -2' was invalid, by converting this to '2'.

The filter would generalize the "bugsfile" (option -b).
The trouble is that to do this right you have to parse the query. Or write some regular expressions to account for the number of spaces. There may be other patterns to look for, like "- + 2".

Whether to parse or use regex is up to the implementation of the filter. The typical filter will have a few regexes, but won't parse the query.

I have filed https://github.com/hydromatic/sql-logic-test/issues/21 for this feature.


[Task]: Finalize the design for runtime types representation with semtypes

Description
$subject.

Functionality wise using the same sem-type representation and the subtyping algorithms at runtime would work.
However, performance-wise we could improve the runtime type checking.
Let's see the nBallerina way of handling runtime type checking.
There are only a limited number of scenarios that we require a runtime type checking.
For example: type test, adding a new member to an array, etc
The thing is we know the types related to such operations at compile-time.
Let's say the types t1, t2, t3, ..., tn are involved. So once we know the involved types, we can derive all the subtyping relationships among them. Basically, for every type pair from the list of n types, we check for isSubtype(ti, tj) (nC2 combinations) and make a table out of all the relationships.
Since we have already derived and created a table from all the subtyping relationships at compile-time, we don't need to perform expensive subtyping checks at runtime. We can simply refer to the table.
Question: Why do we compute all these relationships at compile-time while we can do it at runtime? That way we don't need to check all combinations. Instead, we can directly check for the required subtype relationship only.
Answer: We only compile a program once. But, we run it many times. Therefore, additional overhead at compile time would serve its price.
An optimization on top of the aforementioned strategy:
As the n grows the number of combinations grows rapidly. The subtype checking overhead gets heavier as the types become complex. Therefore, we could go for a hybrid approach where for the simple types we do the subtype checking at runtime, while for the complex types only, we derive the subtyping relationship table at compile-time. Drawing the line between what is a simple type and what is a complex type is up to us. In nBallerina, we consider type's having simple BDDs (single atoms) as simple types. However, the member types within them, themselves have to be simple types.

Based on today's discussion. We would revisit the runtime implementation.
Would give priority to fully complete the compile time implementation.

General design we came up with (see #40511 for more details) is as fallows,

There will be a sealed base class called SemType, instead of a marker interface like we have in the compiler side. This is so that we can do direct field access to get all, some and subtype data, without having to do type checks or virtual function calls. For the time being there will be a single class instead of two (BasicTypeBitSet and ComplexSemType) this means we are wasting 12 bytes in the case of BasicTypeBitSet but this means we don't have any runtime overhead with type checking when we try to access fields
There will 2 direct implementations of this class called "PureSemType" and "BSemTypeWrapper". "PureSemType" will be just a SemType similar to what we have in nBallerina. All results from SemType APIs (union, intersect etc) will be of this type and will give us  a light weight representation.
All existing BTypes will extend from either BSemTypeWrapper or implement a SemType supplier. This means as far the type checker is concerned it can treat any type it get's as a semtype  while current runtime API users can treat them as "BTypes"  (for more details on see the next section)
Since these are different classes from the once used by the compilers semtype API there will be a correspondingly separate API. While in compiler side we have faithfully reproduced the same API as the nBAllerina there may be few deviations in the runtime mostly to better exploit JVMs performance profile. However both of these will use the same test suite (in semtype port tests) so in theory they are drop in replacements

Problem with computing all the possible runtime type check relations is unlike nBallerina jBallerina has the ability to create new types at runtime using TypeCreator API. But still we can cache type check results (that is we have check if given type pair T1 and T2 to be subtypes and this is the result in T1 (we can't say the result for T2 to be inverse since T2 could be equal to T1 and to check that we need to do an extra type TypeCheck which is not worth it)
BSemTypeWrapper and type supplier

For simple basic types (int, boolean etc) there will be direct implementations that will use a delegate to support current BType implementations.  This is because for type checking we don't have a way to attach the type to the value which means we have to create these types again and again. This should give us more room to optimize these things by being able to share the inner BType part and caching the creation of these types where applicable. Also these
For others where we have a type attached to the value I decided to treat that type as a semtype supplier. This is because these types can have recursive types. Also we don't have a clear break point where the type has finished initializing since they can be modified after construction.

Handline BTypes during the transition period
While we have only a part of the type space implemented as semtypes I'll introduce a new (temporary) basic type called BType which will hold the the part of the type type currently not implemented as a semtype. Most type operations will not be supported for this BasicType.


The address property in the userinfo endpoint should be an object instead of a string

Describe the bug
When calling the userinfo endpoint with the address scope, the mock-data-recipient expects a string for the address property while the openID connect specs expect a JSON object.
References:

section 5.1 Standard Claims
CDS Scopes and Claims requirements

To Reproduce
Steps to reproduce the behavior:

Register a data_holder and a user with its address parsed as an object
Call userinfo endpoint with the address scope
The mock data recipient returns a 500 error

Expected behaviour
The userinfo endpoint is supposed to return the userinfo data with the address as a JSON object instead of a string as per the openID specs. The address JSON object contains the following properties:
"address": {
    "formatted": "...",
    "street_address": "...",
    "locality": "...",
    "region": "...",
    "postal_code": "...",
    "country": "..."
}

Hi @sjillen,
Thank you for reaching out and raising this issue. We have logged the issue and will include a fix in a future release.

Hi @sjillen,
This issue has now been fixed in the Mock Data Recipient v1.2.5 from our recent production release.


Compatibility with NCZarr.

I've just left comments in #18 and #3 asking about this, perhaps you can summarize your thoughts here @christophenoel ?
Scanning this issue: https://github.com/zarr-developers/zarr-specs/issues/41
I tend to think that NCZarr is a lower level concern and that GeoZarr should try to be agnostic to the particular way that NetCDF attributes are encoded into Zarr. That is, I think that GeoZarr should work whether you also need features supported by NCZarr or are using vanilla Zarr. Someone with a deeper knowledge of the landcape will need to chime in here though. @rabernat or someone else -- can you recommend and pull in someone who might be able to help recommend a path forward on this topic?

From: 21-050r1_Zarr_Community_Standard.pdf

Beginning with NetCDF-C version 4.8.0, Unidata introduced experimental Zarr support
into the NetCDF-C library. This was accomplished via creating a new specification -
NCZarr - which is “similar to, but not identical with the Zarr Version 2 Specification.”
Specifically, NCZarr adds two additional metadata files (“.nczarray" and ".nczattr”),
which are not part of the Zarr V2 Spec. Since NCZarr stores are not fully compatible and
interoperable with Zarr V2, this community standard excludes NCZarr. Work is ongoing
to reconcile NCZarr and the architectural reasons that motivated its development with the
forthcoming Zarr V3 Specification.
Fortunately, the NetCDF-C library also supports reading / writing of data using the
simpler Named Dimension convention described in 4.1.

This seems to indicate that what I stated above, that NCZarr is a lower level concern is basically true.

I don't think this really helps, but I found the following section written by the team in the Cloud-native Format TradeOff report (HDSA project):

NCZarr origins from the need of a pure C implementation of the Zarr API. Starting from 2018, Unidata NetCDF team joined the discussion and provided effort to bring support of Zarr datastores to the existing netcdf-c library. This effort resulted in the creation of an extension of the Zarr specification called NCZarr, which provides a data model close to the existing netcdf-4 data model.
Starting from NetCDF version 4.8.0 (April 2021), the Zarr (and NCZarr) data formats are supported by the netcdf-c library. Since then, the netcdf-c library can provide access to cloud storage such as Amazon S3.
The first NCZarr version relies on special objects that are not part of the Zarr specification (and not supported by the official Zarr library). In the new version of NCZarr, this is no longer the case. The new NCZarr version relies only on pure Zarr objects, using predefined named attributes as a convention. Those specific attributes shall not generate any error when reading Zarr files but might be ignored depending on the Zarr library implementation used.

That aligns with what's been discussed elsewhere. I'll close this issue as I think we've determined that NCZarr is not an issue for geozarr to overcome.


vfs support -- ready for review

#3 Support for vfs, please review

Hey @Buggaboo , first off big thanks for this and the other PR, really appreciate your hard work here! it may take me a few days to review this, and I'm gonna merge a few things in before I get to this. But I 100% intend to review and merge this once it's ready!


[ReactKarma] Cog ready for V3

Gonna redo this pull request because I didn't squash the commits.


e2e test\workflow\idir\cas_pending

Tests of \idir\cas_pending workflow
Landing Page

[x] Login redirected to Profile page (NOTE: tested in client/e2e/pages/onboarding/home/page.spec.ts)
[x] Profile page submit required data (NOTE: tested in client/e2e/pages/authenticated/dashboard/profile/page.spec.ts)
[x] Dashboard design: no tiles are available, message that access request is pending (NOTE: tested in client/e2e/pages/authenticated/dashboard/page.spec.ts)
[x] Cannot navigated to restricted app routes (NOTE: tested in client/e2e/pages/authenticated/routes/page.spec.ts)

WIP
Tests using storageState for cas_pending:

[ ] navigation to "home" is redirected to Profile page

@shon-button , I recall you mentioning that you're developing route protection tied to user roles in issue 1006. Should I skip that part here?

@Sepehr-Sobhani  Updated ACs "done" list with Cannot navigated to restricted app routes


Union, sub-query, enumAdapter compile error

Hi,
currently I'm facing a problem similar to https://github.com/square/sqldelight/issues/640.
When using an enum (and it's corresponding adapter) in combination with sub-queries which include an additional property (in my case n as ordering) the generated code includes an underscore in the reference name for the adapter (statusAdapter_).
Here is the sample code which produces the bug:
CREATE TABLE testA (
  id TEXT NOT NULL PRIMARY KEY,
  status TEXT AS Test.Status,
  attr TEXT
);

test_union_query:
SELECT *
FROM (
  SELECT *, 1 as ordering
  FROM testA
  WHERE testA.attr IS NOT NULL

  UNION

  SELECT *, 2 as ordering
  FROM testA
  WHERE testA.attr IS NULL
);

The bug doesn't occur when removing the where clause of the first sub-query or when removing the additional property n as ordering.
As a reference here's the generated DatabaseAModel:
package com.coyoapp.messenger.android.io.persistence;

import android.database.Cursor;
import android.support.annotation.NonNull;
import android.support.annotation.Nullable;
import com.coyoapp.messenger.android.io.model.Test;
import com.squareup.sqldelight.ColumnAdapter;
import com.squareup.sqldelight.RowMapper;
import com.squareup.sqldelight.SqlDelightQuery;
import com.squareup.sqldelight.internal.TableSet;
import java.lang.Deprecated;
import java.lang.Override;
import java.lang.String;

public interface TestModel {
  @Deprecated
  String TABLE_NAME = "testA";

  @Deprecated
  String ID = "id";

  @Deprecated
  String STATUS = "status";

  @Deprecated
  String ATTR = "attr";

  String CREATE_TABLE = ""
      + "CREATE TABLE testA (\n"
      + "  id TEXT NOT NULL PRIMARY KEY,\n"
      + "  status TEXT,\n"
      + "  attr TEXT\n"
      + ")";

  @NonNull
  String id();

  @Nullable
  Test.Status status();

  @Nullable
  String attr();

  interface Test_union_queryModel<T1 extends TestModel> {
    @NonNull
    T1 testA();

    long ordering();
  }

  interface Test_union_queryCreator<T1 extends TestModel, T extends Test_union_queryModel<T1>> {
    T create(@NonNull T1 testA, long ordering);
  }

  final class Test_union_queryMapper<T1 extends TestModel, T extends Test_union_queryModel<T1>> implements RowMapper<T> {
    private final Test_union_queryCreator<T1, T> creator;

    private final Factory<T1> testModelFactory;

    public Test_union_queryMapper(Test_union_queryCreator<T1, T> creator,
        @NonNull Factory<T1> testModelFactory) {
      this.creator = creator;
      this.testModelFactory = testModelFactory;
    }

    @Override
    @NonNull
    public T map(@NonNull Cursor cursor) {
      return creator.create(
          testModelFactory.creator.create(
              cursor.getString(0),
              cursor.isNull(1) ? null : testModelFactory.statusAdapter_.decode(cursor.getString(1)),
              cursor.isNull(2) ? null : cursor.getString(2)
          ),
          cursor.getLong(3)
      );
    }
  }

  interface Creator<T extends TestModel> {
    T create(@NonNull String id, @Nullable Test.Status status, @Nullable String attr);
  }

  final class Mapper<T extends TestModel> implements RowMapper<T> {
    private final Factory<T> testModelFactory;

    public Mapper(@NonNull Factory<T> testModelFactory) {
      this.testModelFactory = testModelFactory;
    }

    @Override
    public T map(@NonNull Cursor cursor) {
      return testModelFactory.creator.create(
          cursor.getString(0),
          cursor.isNull(1) ? null : testModelFactory.statusAdapter.decode(cursor.getString(1)),
          cursor.isNull(2) ? null : cursor.getString(2)
      );
    }
  }

  final class Factory<T extends TestModel> {
    public final Creator<T> creator;

    public final ColumnAdapter<Test.Status, String> statusAdapter;

    public Factory(@NonNull Creator<T> creator,
        @NonNull ColumnAdapter<Test.Status, String> statusAdapter) {
      this.creator = creator;
      this.statusAdapter = statusAdapter;
    }

    @NonNull
    public SqlDelightQuery test_union_query() {
      return new SqlDelightQuery(""
          + "SELECT *\n"
          + "FROM (\n"
          + "  SELECT *, 1 as ordering\n"
          + "  FROM testA\n"
          + "  WHERE testA.attr IS NOT NULL\n"
          + "\n"
          + "  UNION\n"
          + "\n"
          + "  SELECT *, 2 as ordering\n"
          + "  FROM testA\n"
          + "  WHERE testA.attr IS NULL\n"
          + ")",
          new TableSet("testA"));
    }

    @NonNull
    public <R extends Test_union_queryModel<T>> Test_union_queryMapper<T, R> test_union_queryMapper(
        Test_union_queryCreator<T, R> creator) {
      return new Test_union_queryMapper<T, R>(creator, this);
    }
  }
}

Thanks for the test case!
Verified this is working as intended on master: https://github.com/square/sqldelight/commit/82012843faac7d48d0fa6d2600dd6cc534a5b1a2

Hi Alec,
I still cannot get around this bug. I'm using version 0.7.0. But the output is always the same (refresh, cleaning cache, etc. didn't solve the problem).
Any idea on what I'm doing wrong?
Thanks

Ah I should have been more specific - there isnt a release yet with the fix, if you want to you can target the SNAPSHOT but the library has changed significantly for the upcoming version so might be hard to upgrade. Unfortunately I dont think theres a way to work around this bug otherwise

Thank you Alec. I'll give it a try.

Had no luck with the SNAPSHOT repo. I'll get
Could not find com.squareup.sqldelight:sqlite-migrations:1.0.0-SNAPSHOT
while gradly syncing.

You need to add maven { url "https://oss.sonatype.org/content/repositories/snapshots" }


extract Slice.replaceColumnImpl

Extract Slice.replaceColumnImpl so that we also replace the column impl where Slice is extended (ie in SegmentsWrapper and DerefSlice).
Also a couple more places to replace new Slice with Slice.apply

Both DerefSlice and SegmentsWrapper are just collections of functions used to create size and columns. They aren't actually doing anything polymorphic. Which is to say, they could both be pretty trivially rewritten in terms of Slice.apply. It seems to me that such an implementation would be better than exposing replaceColumnsImpl as an external function, no?

Ah, right, I wasn't really looking at those classes in that mode. Nicer not to expose replaceColumnsImpl indeed, and also to simply create a Slice via Slice.apply instead of extending Slice.


Tools: add link to MoneroLogs

@erciccione conflict how? 1722 changes different files

I linked to the wrong PR. I meant #1732, which changes the same file and almost the same line.

Should be fine to just rebase after 1732 is merged.

Yeah, my point was to avoid the conflict and the need of rebase after the merge by putting the two commits in the same PR. Not a big deal, just makes maintainance easier.


Fix duplicate dynamic chunks

#7392

Please re-send this against canary. I tried rebasing and the base commit is pretty out of date.


Build Fails

Something must have broken the build. Even trivial changes like in #343 (which simply adds text on a Notebook) fail.
I believe #373 fixes this.

yes, test_text.py and test_agents.py, it shows flake8 errors, fixed that in PR #373 , will have to wait for merge.

Yes, as mentioned in #304, now onwards, any tests that don't match flake8 specs will break the build - and one of my PRs that had such tests is breaking the build.

I have removed the test in #386 . That should the problem

This is now fixed. Closing.


Alby state should be stored between closing and opening Alby

The state of the Alby pop-up is not saved when it is closed for some reason. Which might lead to confusion. Here'e an example.
reproduce:

Open Alby click on Receive and enter some amount and description
Click create invoice, the invoice is displayed
Now switch the browser tab ore to another window, etc., i.e. to open another wallet in order to pay the invoice

When going back to Alby the invoice is gone, if you did not copy it immediatley you have to create a new one.
Imo this is not a good solution because everytime I do anything in alby I have to finish it otherwise it'll be gone as soon as I click somewhere else.

There is no easy way to achieve this behavior other than storing the state of the application in some storage and restoring application state from there (which is a very hard thing to do and has a lot of potential side effects, e.g. having two windows opened at the same time, etc).
If you need to switch contexts when doing tasks I suggest you open Alby in a separate window than using the extension popup (you can just click on the "wallet" button in the dropdown menu top open Alby in a new tab):

Closing as I don't see us implementing this over the next months.


Reimplementing get_scratch_devices()

This PR is about re-implementing get_scratch_devices() while keeping the same input/outputs and adding news features

listing all present block devices and not only sda or vda
supporting more than 26 disks per host : sdaa vs sda
auto-detecting the backing device of the root system by reading /proc/cdmline
inspecting dm devices to detect more used devices
expanding UUIDs & symlinks to understand the underlying block devices
return no free block devices if known was detected as used to avoid damaging
data
return no free block devices if we cannot get intersections between the list
of available devices and used devices to avoid damaging data
compute the list of free devices by removing the detected used device from the
complete list

As a result, a block reported to be free is a detected block devices which is
proven not being used by : the root fs, a dm device or a user mounted
filesystem.

Can one of the admins verify this patch?

ok to test

I'd like to see the results of some jobs executed using this teuthology branch, just to be a little more sure that there isn't a regression. Probably need to see smithi, mira and vps

@zmc Good point. I tested my code locally against a mira and it worked but let me check simith & vps before ... I should I done that before pushing the PR.

Tested a smithi and found a bug in my code but the protection code worked and would have avoid issues.
But that brings a question on my side : if we have a /scratch_device file, we should consider the content without touching it and could provide partitions.
If we don't have that scratch file then we should detect the free block devices. Shall consider the actual partition scheme and report each partition individually or shall I report the associate block itself ?
if /dev/sda is featuring /dev/sda1, /dev/sda2, /dev/sda3  : shall I report /dev/sda as free or each individual partition ?

@ErwanAliasr1 re: devices vs. partitions: I believe the current behavior is to detect and report whole devices as opposed to partitions. We should be preserving the existing behavior in this PR. It's good to add the capability to detect different types of devices, but the hosts we use daily in our labs should continue to behave as they have before. That's part of why I mentioned wanting to see test results :)

@zmc Ok, I update the PR this way. I also fixed the nvme support and discovered that I badly handled the /scratch_devs

Looks good for me, local test ran fine

@ErwanAliasr1 any word on scheduled tests using our hardware?

@ErwanAliasr1 Hi.  I can provide some teuthology suite setup and running help you need it.  What tests do you want to run?  Looking at the change and what calls it, I assume that you want to run this against ceph-ansible and ceph-deploy tests.

thx @wusui Any test would be fine if we pass via all kind of hardware types.

Hm... Looks like these changes deserves a separate module like blockdevices or blockdev or dev, and can be placed for example by one of that path:

teuthology.blockdevices
teuthology.orchestra.blockdevices
teuthology.orchestra.blockdev
teuthology.orchestra.dev

Are there any plans to continue efforts?

Can one of the admins verify this patch?


Websocket connection failed, Error: Expected a Sec-WebSocket-Protocol header.

Hi
Would someone know why I'm getting the following error all of a sudden while it has been working for months when I try to scrape data of presents that are being send in the live:
General error! {
info: 'Upgrade to websocket failed',
exception: 'Websocket connection failed, Error: Expected a Sec-WebSocket-Protocol header.'
}
Thanks in advance and kind regards

Same error from today

Upgrade to latest commit

Upgrade to latest commit

Thx! It works again.

Upgrade to latest commit

Thank you! It works

After 2 months with that Parse Error issue and realizing that it was my fault for not keeping my Node JS up to date with the latest version (upgraded to 21)  - I've now upgraded my error status to this one.  I've updated to latest commit on the library and I'm getting the combo    info: 'Upgrade to websocket failed',
exception: 'Websocket connection failed, Error: Expected a Sec-WebSocket-Protocol header.' and then followed by
Error while connecting, Error: TikTok does not offer a websocket upgrade. Please provide a valid sessionId to use request polling instead.
{
info: 'Error while connecting',
exception: Error: TikTok does not offer a websocket upgrade. Please provide a valid sessionId to use request polling instead.
at WebcastPushConnection.connect (node_modules\tiktok-live-connector\dist\index.js:287:17)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
}
I used to have the .env file with the Sessionid and the ttwid - and thought that was the issue.  I removed that.  And upgraded to the latest commit.  Same issue.
Wondering if this is a real issue or has something to do with the sig server and too many requests?

Okay, after a combination sequences of fresh downloads of the tiktok-live-connector to a different directory on my PC and clearing and restoring from backup and running npm update and npm i tikok-live-connector command on it and manually copying and pasting on top of the existing code in node_modules\tiktok-live-connector
I finally - Finally, -- FINALLY got the connector to work!
And was able to go live for an hour with solid chat, gifts, and like events being delivered to my custom game.  (and happy followers rejoicing they could PLAY again after a 2 month hiatus  - that's what this is all about, right?  Bring joy to others through our crafts)
And then, no more than 15 hours later.  I'm getting that Connection failed, Error: Missing cursor in initial fetch response  and then the 429 error that means I gotta wait to try again.
I'm starting to think that the Connection failed, Error: Missing cursor in initial fetch response isn't me, it is the euler server with either too many connections of some random error that might be unhandled.   Not sure.  Unless TikTok did change something in 15 hours.  There is no commits that I am aware of.
Just doing my QA and code testing here trying to get an answer.


[FR] Krista's feedback

PR https://github.com/Azure/azure-sdk-for-net/pull/24326 got merged before @kristapratico feedback.
Addressing it here

API changes have been detected in this PR. You can review API changes here

Beautiful! Sorry for reviewing after it got merged!

No, no. Thank you for reviewing it and catching important things :)


Could I allow spacific directory for gdrive access???

In my drive directory structure:
/private_a
/private_b
/mygdrive

I wold like to allow Gdrive to access only mygdrive directory.
Please help me

Unfortunately, that can't be done. Google provides oauth token for the entire drive and not for some selected containers or files. What you can do is to share "mygdrive" to some other account and give gdrive access to that account. This way private_* folders won't be accessed.
If what you want is for gdrive to have its own space, where neither any other app (including web gui I believe) can access to it nor gdrive can access to any other files. That can be added as a feature, in future.

Very thanks for your reply.
👍


Added a Blog Entry on KubeSlice Security with focus on PSP deprecation

Created a Blog Post for Kube Slice Security and PSP Deprecation.
Looking for Feedback.
Signed-off-by: afro-coder<EMAIL_ADDRESS>

@afro-coder : Gentle reminder on this one :)

@afro-coder : Gentle reminder on this one :)

Hey @divya-mohan0209 changes are made please check :)

Is it me or is the spellcheck failing for words that are correct


Better options default to reduce configurations overhead

What version of this package are you using?
v1.5.1
What problem do you want to solve?
Currently, the defaults options (.vscode/settings.json) for this extension are not correct in terms of "best practices" as it encourages global installation, global configuration (currently it is enabled by default but instead it should be enabled per project) and recommends to disable the built-in VSCode validator ("javascript.validate.enable": false) for no reason.
These defaults contradict, one of the standard goals to make it work out of the box.
What do you think is the correct solution to this problem?

We need to change the default options:

"standard.enable": true

"standard.usePackageJson": true

Instead of recommending (in the README)

Disable the built-in VSCode validator

We can provide an example of .vscode/settings.json for the third steps of "How to use".
After these improvements, we can have a working VSCode setup with standard with only one line of config in .vscode/settings.json :
{
  "standard.enable": true
}

This is necessary to enable the extension only for the project we are currently working on, that way we don't need to disable this extension if we are working on a project that doesn't use standard.
Note: This is a BREAKING CHANGE.
Are you willing to submit a pull request to implement this change?
Yes!

@Divlo Completely agree. Perhaps some examples for popular libraries like CRA that seems to also need the workingDirectories directive.
The following example seems to work for a CRA starter example (assuming an app name of  /app) and doesn't stop formatting of other files.
{
  "editor.formatOnSave": true,
  "[javascript]": {
    "editor.formatOnSave": false
  },
  "[javascriptreact]": {
    "editor.formatOnSave": false
  },
  "[typescript]": {
    "editor.formatOnSave": false
  },
  "[typescriptreact]": {
    "editor.formatOnSave": false,
  },
  "standard.enable": true,
  "standard.engine": "ts-standard",
  "standard.usePackageJson": true,
  "standard.treatErrorsAsWarnings": true,
  "standard.autoFixOnSave": true,
  "standard.workingDirectories": [
    "./app"
  ]
}