Use final ref for projjson

The current ref, https://proj.org/schemas/v0.7/projjson.schema.json, is actually a redirect to https://proj.org/en/latest/schemas/v0.7/projjson.schema.json:
$ curl -s -D - https://proj.org/schemas/v0.7/projjson.schema.json -o /dev/null | head -n5
HTTP/2 302
date: Thu, 26 Sep 2024 12:10:21 GMT
content-type: text/html; charset=utf-8
content-length: 0
location: https://proj.org/en/latest/schemas/v0.7/projjson.schema.json

This isn't wrong per-se, but does cause an extra request when validating which is slightly annoying. This was discovered because that redirect is causing breakages in rare situations, e.g. https://github.com/stac-utils/pystac/issues/1409.

We had this discussion before in PROJ, because the initial link wasn't working anymore when they changed the documentation system.
I think the canonical links is meant to be https://proj.org/schemas/v0.7/projjson.schema.json while https://proj.org/en/latest/schemas/v0.7/projjson.schema.json may change at any time when their doc syszem changes (see the /en/ in the URL). So I'm not sure whether we should depend on it.

Ok, thanks for the context. I'm 👎🏼 on redirects for links that get hit a lot as a part of validation but that's not a you problem 😄.

Yeah, I didn't like the change either and think their schemas should be hosted separate from their documentation system but it is as it is...


Handle Dungeon Narrator Text

Design Decision to figure out where this information is stored

Added ILookable interface to all objects so that we can start using an interface to receive text from. Since we're using the ObjectBehavior script we can probably go and enter our text for them there and then call "Look" on each object when the player "looks" at them.


[BUG] Illegal memory with multi-node

Describe the bug
When running GemmRS on two nodes, each with 4 A100 80G connected via NVLINK. Each node has 1 NIC to IB HDR200.
W0907 22:34:09.000000<PHONE_NUMBER>6464 torch/distributed/run.py:779]
W0907 22:34:09.000000<PHONE_NUMBER>6464 torch/distributed/run.py:779] *****************************************
W0907 22:34:09.000000<PHONE_NUMBER>6464 torch/distributed/run.py:779] Setting OMP_NUM_THREADS environment variable for each process to be 1 in default, to avoid your system being overloaded, please further tune the variable for optimal performance in your application as needed.
W0907 22:34:09.000000<PHONE_NUMBER>6464 torch/distributed/run.py:779] *****************************************
before flux shm initialization
before flux shm initialization
before flux shm initialization
before flux shm initialization
after flux shm initialization
after flux shm initialization
after flux shm initialization
after flux shm initialization
[rank1]:[E907 22:34:22.723784108 ProcessGroupNCCL.cpp:1515] [PG 0 (default_pg) Rank 1] Process group watchdog thread terminated with exception: CUDA error: an illegal memory access was encountered
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

Exception raised from c10_cuda_check_implementation at /opt/conda/conda-bld/pytorch_1724789115564/work/c10/cuda/CUDAException.cpp:43 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x96 (0x145b3b587f86 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #1: c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::string const&) + 0x64 (0x145b3b536d10 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #2: c10::cuda::c10_cuda_check_implementation(int, char const*, char const*, int, bool) + 0x118 (0x145b3b663ee8 in flux/lib/python3.10/site-packages/torch/lib/libc10_cuda.so)
frame #3: c10d::ProcessGroupNCCL::WorkNCCL::finishedGPUExecutionInternal() const + 0x56 (0x145b3c86fa36 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #4: c10d::ProcessGroupNCCL::WorkNCCL::isCompleted() + 0xa0 (0x145b3c874c50 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #5: c10d::ProcessGroupNCCL::watchdogHandler() + 0x1da (0x145b3c87b90a in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #6: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x10c (0x145b3c87dd4c in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #7: <unknown function> + 0xdbbf4 (0x145b9ef0bbf4 in flux/lib/python3.10/site-packages/torch/lib/../../../.././libstdc++.so.6)
frame #8: <unknown function> + 0x81ca (0x145bb4c711ca in /lib64/libpthread.so.0)
frame #9: clone + 0x43 (0x145bb4153e73 in /lib64/libc.so.6)

[rank2]:[E907 22:34:22.821294480 ProcessGroupNCCL.cpp:1515] [PG 0 (default_pg) Rank 2] Process group watchdog thread terminated with exception: CUDA error: an illegal memory access was encountered
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

Exception raised from c10_cuda_check_implementation at /opt/conda/conda-bld/pytorch_1724789115564/work/c10/cuda/CUDAException.cpp:43 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x96 (0x14e20c855f86 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #1: c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::string const&) + 0x64 (0x14e20c804d10 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #2: c10::cuda::c10_cuda_check_implementation(int, char const*, char const*, int, bool) + 0x118 (0x14e20c931ee8 in flux/lib/python3.10/site-packages/torch/lib/libc10_cuda.so)
frame #3: c10d::ProcessGroupNCCL::WorkNCCL::finishedGPUExecutionInternal() const + 0x56 (0x14e20db3da36 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #4: c10d::ProcessGroupNCCL::WorkNCCL::isCompleted() + 0xa0 (0x14e20db42c50 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #5: c10d::ProcessGroupNCCL::watchdogHandler() + 0x1da (0x14e20db4990a in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #6: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x10c (0x14e20db4bd4c in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #7: <unknown function> + 0xdbbf4 (0x14e2701d9bf4 in flux/lib/python3.10/site-packages/torch/lib/../../../.././libstdc++.so.6)
frame #8: <unknown function> + 0x81ca (0x14e285f3f1ca in /lib64/libpthread.so.0)
frame #9: clone + 0x43 (0x14e285421e73 in /lib64/libc.so.6)

[rank3]:[E907 22:34:22.821407422 ProcessGroupNCCL.cpp:1515] [PG 0 (default_pg) Rank 3] Process group watchdog thread terminated with exception: CUDA error: an illegal memory access was encountered
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

Exception raised from c10_cuda_check_implementation at /opt/conda/conda-bld/pytorch_1724789115564/work/c10/cuda/CUDAException.cpp:43 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x96 (0x1529560c1f86 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #1: c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::string const&) + 0x64 (0x152956070d10 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #2: c10::cuda::c10_cuda_check_implementation(int, char const*, char const*, int, bool) + 0x118 (0x15295619dee8 in flux/lib/python3.10/site-packages/torch/lib/libc10_cuda.so)
frame #3: c10d::ProcessGroupNCCL::WorkNCCL::finishedGPUExecutionInternal() const + 0x56 (0x1529573a9a36 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #4: c10d::ProcessGroupNCCL::WorkNCCL::isCompleted() + 0xa0 (0x1529573aec50 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #5: c10d::ProcessGroupNCCL::watchdogHandler() + 0x1da (0x1529573b590a in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #6: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x10c (0x1529573b7d4c in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #7: <unknown function> + 0xdbbf4 (0x1529b9a45bf4 in flux/lib/python3.10/site-packages/torch/lib/../../../.././libstdc++.so.6)
frame #8: <unknown function> + 0x81ca (0x1529cf7ab1ca in /lib64/libpthread.so.0)
frame #9: clone + 0x43 (0x1529cec8de73 in /lib64/libc.so.6)

[rank0]:[E907 22:34:22.823452114 ProcessGroupNCCL.cpp:1515] [PG 0 (default_pg) Rank 0] Process group watchdog thread terminated with exception: CUDA error: an illegal memory access was encountered
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

Exception raised from c10_cuda_check_implementation at /opt/conda/conda-bld/pytorch_1724789115564/work/c10/cuda/CUDAException.cpp:43 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x96 (0x153118a11f86 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #1: c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::string const&) + 0x64 (0x1531189c0d10 in flux/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #2: c10::cuda::c10_cuda_check_implementation(int, char const*, char const*, int, bool) + 0x118 (0x153118aedee8 in flux/lib/python3.10/site-packages/torch/lib/libc10_cuda.so)
frame #3: c10d::ProcessGroupNCCL::WorkNCCL::finishedGPUExecutionInternal() const + 0x56 (0x153119cf9a36 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #4: c10d::ProcessGroupNCCL::WorkNCCL::isCompleted() + 0xa0 (0x153119cfec50 in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #5: c10d::ProcessGroupNCCL::watchdogHandler() + 0x1da (0x153119d0590a in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #6: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x10c (0x153119d07d4c in flux/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #7: <unknown function> + 0xdbbf4 (0x15317c395bf4 in flux/lib/python3.10/site-packages/torch/lib/../../../.././libstdc++.so.6)
frame #8: <unknown function> + 0x81ca (0x1531920fb1ca in /lib64/libpthread.so.0)
frame #9: clone + 0x43 (0x1531915dde73 in /lib64/libc.so.6)

W0907 22:34:23.038000<PHONE_NUMBER>6464 torch/distributed/elastic/multiprocessing/api.py:858] Sending process 1834997 closing signal SIGTERM
W0907 22:34:23.038000<PHONE_NUMBER>6464 torch/distributed/elastic/multiprocessing/api.py:858] Sending process 1834999 closing signal SIGTERM
W0907 22:34:23.038000<PHONE_NUMBER>6464 torch/distributed/elastic/multiprocessing/api.py:858] Sending process 1835000 closing signal SIGTERM
E0907 22:34:23.482000<PHONE_NUMBER>6464 torch/distributed/elastic/multiprocessing/api.py:833] failed (exitcode: -6) local_rank: 1 (pid: 1834998) of binary: flux/bin/python
Traceback (most recent call last):
  File "flux/bin/torchrun", line 33, in <module>
    sys.exit(load_entry_point('torch==2.4.1', 'console_scripts', 'torchrun')())
  File "flux/lib/python3.10/site-packages/torch/distributed/elastic/multiprocessing/errors/__init__.py", line 348, in wrapper
    return f(*args, **kwargs)
  File "flux/lib/python3.10/site-packages/torch/distributed/run.py", line 901, in main
    run(args)
  File "flux/lib/python3.10/site-packages/torch/distributed/run.py", line 892, in run
    elastic_launch(
  File "flux/lib/python3.10/site-packages/torch/distributed/launcher/api.py", line 133, in __call__
    return launch_agent(self._config, self._entrypoint, list(args))
  File "flux/lib/python3.10/site-packages/torch/distributed/launcher/api.py", line 264, in launch_agent
    raise ChildFailedError(
torch.distributed.elastic.multiprocessing.errors.ChildFailedError:
========================================================
test/test_gemm_rs.py FAILED
--------------------------------------------------------
Failures:
  <NO_OTHER_FAILURES>
--------------------------------------------------------

To Reproduce
Steps to reproduce the behavior. The easier it is to reproduce the faster it will get maintainer attention.
Expected behavior
A clear and concise description of what you expected to happen.
Stack trace/logs
If applicable, add the stack trace or logs from the time of the error.
Environment
Each node has 4 A100 80G, connected via NVLINK.
$ nvidia-smi topo -m
        GPU0    GPU1    GPU2    GPU3    NIC0    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV4     NV4     NV4     SYS     24-34,36-46     1               N/A
GPU1    NV4      X      NV4     NV4     SYS     0-10,12-22      0               N/A
GPU2    NV4     NV4      X      NV4     NODE    72-82,84-94     3               N/A
GPU3    NV4     NV4     NV4      X      SYS     48-58,60-70     2               N/A
NIC0    SYS     SYS     NODE    SYS      X

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

NIC Legend:

  NIC0: mlx5_0

Interconnection is IB HDR200:
$ ibstat
CA 'mlx5_0'
        CA type: MT4123
        Number of ports: 1
        Firmware version: 20.36.1010
        Hardware version: 0
        Node GUID: 0xe8ebd30300401a34
        System image GUID: 0xe8ebd30300401a34
        Port 1:
                State: Active
                Physical state: LinkUp
                Rate: 200
                Base lid: 766
                LMC: 0
                SM lid: 1864
                Capability mask: 0xa651e848
                Port GUID: 0xe8ebd30300401a34
                Link layer: InfiniBand

Proposed fix
If you have a proposal for how to fix the issue state it here or link to a PR.
Additional context
Add any other context about the problem here.

Thanks for your interests! @YJHMITWEB
How do you run the test for multi-node? via the launch script we provided or just torchrun?
If you check the launch.sh under script folder, you can see that we haven't released (or at least fully release) multi-node support yet IIRC. cc @zheng-ningxin


Latest 1.19.2 Forge version crashes the game

It doesn't put out a crash report and the logs hardly give any information.

This is caused by my project structure changes, sorry about that! I have uploaded new files to Curseforge/Modrinth.
https://modrinth.com/mod/fish-of-thieves/version/2.2.8-forge


minor issue, there is an error if there isn't a maps key

Go to Google Static Maps API and register for a browser key (this is optional, only do this if you want to have the mirror show a maps view of your home on command)

On the readme you say that it's optional. I think you should specify that getting a key is optional but the resource string has to be there even if it's empty.
Error:(82, 25) error: cannot find symbol variable static_maps_api_key
Error:(42, 8) error: dagger.internal.codegen.ComponentProcessor was unable to process this class because not all of its dependencies could be resolved. Check for compilation errors or a circular dependency with generated code.

Fixed in PR #40


Make a compile error while facing unused variables

To prevent further bugs, we can make it fail to compile while facing unused variables.

Have it found some already exists unused variables bug?

The following error is reported when building version 2.7:
kvrocks/src/cluster/cluster.cc:537:22: error: unused variable ‘’ [-Werror=unused-variable]
for (auto &[, info] : slots_infos) {


Create a print Event to replace the print usage in dbt-core

related to https://github.com/dbt-labs/dbt-core/issues/8756
Related PR https://github.com/dbt-labs/dbt-core/pull/10131

Description
We want to have some event that

would still output to stdout when --quiet is specified,
without the timestamps in front
This PR does so by creating a specific event in dbt-common and implemented logic to have this event always passed to logger as 'error' level.

Checklist

[x] I have read the contributing guide and understand what's expected of me
[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[x] I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
[x] I have run changie new to create a changelog entry

Codecov Report
Attention: Patch coverage is 26.47059% with 50 lines in your changes are missing coverage. Please review.

Project coverage is 56.63%. Comparing base (3b61b6f) to head (21f3abf).

:exclamation: Current head 21f3abf differs from pull request most recent head af7ed83. Consider uploading reports for the commit af7ed83 to get more accurate results

Files
Patch %
Lines

dbt_common/events/types_pb2.py
10.90%
49 Missing :warning:

dbt_common/events/logger.py
87.50%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #130      +/-   ##
==========================================
+ Coverage   56.37%   56.63%   +0.25%
==========================================
  Files          50       50
  Lines        3090     3106      +16
==========================================
+ Hits         1742     1759      +17
+ Misses       1348     1347       -1

Flag
Coverage Δ

unit
56.63% <26.47%> (+0.25%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Bump node to minimal supported version

This action previously requested node-16 which is unsupported and was
automatically bumped to the minimal supported version node-20. This
triggered a warning for users:
The following actions use a deprecated Node.js version and will be forced to run on node20: boa-dev/criterion-compare-action@v3.  For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

This has slight overlap with #118 which among other things also bumps node.


Borderless Mining vs. Cubes Without Borders

Original issue
#814, #78
Why should it be in the modpack
Cubes Without Borders seems to be the new and better alternative.
Why shouldn't it be in the modpack
Borderless Mining seems to be... outdated?
Additional details
https://github.com/Fabulously-Optimized/fabulously-optimized/blob/main/INCLUDED-MODS.md#functional
Both mods are described with same details, this is confusing. Why include both?
Confirm

[X] This mod removal request was written in good faith, taking into consideration why the mod was added in the first place. This is not a mod replacement request - for that purpose I should use the normal mod request form.

Both mods are described with same details, this is confusing. Why include both?

The table indicates that the latest stable versions from 1.16.5 to 1.19.4 used Borderless Mining, and the current stable version 1.20.4 uses Cubes Without Borders.


Count function not use TableName method

Your Question

if i use the CountRoleByIds function, then report
unsupported data type: 0x1400003a688: Table not set, please set it like: db.Model(&user) or db.Table
but when i use the GetRoleByIds function, it's ok.
why Count not use the TableName

Because we have no way to get the table name


Token Claims

I am giving a try to DID and I like the concept as a whole, but I have some remarks that I would like to mention.
Token Claims
On a success login we get this Token Claims:
%{
  "aud" => "test_xxxxxx",
  "email" =><EMAIL_ADDRESS>  "email_verified" => true,
  "exp" =><PHONE_NUMBER>,
  "iat" =><PHONE_NUMBER>,
  "iss" => "https://did.app",
  "nonce" => nil,
  "sub" => "cc694f41-56b0-4a6d-9f7e-bc60cd660290"
}

Why are you leaking the following?
Client ID in DID.app
In my opinion this could not be revealed, but do you have a reason to have it in the claims?
User Email
This is the type of data that can be retrieved by using the sub claim to query the DID backend.
I understand that may be convenient, but at least I would like that this value would not be there by default. Maybe an option to not include it in the DID Dashboard?
The email is verified
You can achieve the same by signing the token with an invalid CLIENT_SECRET, thus when the backend is not able to verify the token signature it knows the token is invalid. This means that the email is not indeed verified or that the token was tampered with.
But if you want to keep the current flow of letting the backend know that the email is indeed not verified, then you can sign the token with the CLIENT_INVALID_SECRET.
With this approach you don't reveal to an attacker introspecting the claims If the token represents a valid user or not.
JWE Instead of JWS
Currently signed tokens(JWS) are being used, that leave the claims publicly exposed, and an alternative would be to use encrypted tokens(JWE), did you though about using JWE?

Client ID in DID.app
Just to confirm, do you mean the aud claim?
To check the token is for your service you should validate that the aud is the client_id for your service.
As much as possible I am trying to follow the OpenID spec https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation point 3
User Email,
What would be the value of not including it to a site implementing DID?
The email is verified
I don't quite understand your suggestion here, sorry.
Tokens aren't signed with the CLIENT_SECRET but a publically available key at the jwks url
JWE Instead of JWS
The OpenID standard does include the option for supporting encryption, it's something we would add. For now we are trying to validate the user flow for end users and developers integrating DID at the moment so it's not a top priority.
If someone explained that they required it for an application then I guess yes we would jump it up the priority list.

Client ID in DID.app

Just to confirm, do you mean the aud claim?

Yes

To check the token is for your service you should validate that the aud is the client_id for your service.

So at least you could hash it, then I would do the same in my backend, and I would know that it's the client_id I expect, thus not revealing it to the world.
User Email,

What would be the value of not including it to a site implementing DID?

Client privacy, data protection, preventing client emails collection just by collecting them from networks attacks or even more usual from logs. Developers forgot how often Logs can be the source of a Data Breach. Logs contain too much valuable data, that lots of us don't even realize.
Remember GDPR fines are huge, therefore anything we can do to reduce exposure of Personal Identifiable Information(PII)  we must do, otherwise GDPR in a data breach will take it as you have not done enough to protect the user data.
It's a common mistaken across the developer community to include more data then it should in normal JWS tokens. You just need to include a uuid that it seems you already do in the sub claim, and then the backend of the client should be the one responsible to query the DID backend to retrieve the PII data it needs, like the user email.
The email is verified

I don't quite understand your suggestion here, sorry.

No problem. I also made the assumption you where using secrets, when it's using a public key to verify them.

Tokens aren't signed with the CLIENT_SECRET but a publicly available key at the jwks url

Oh I see, that defeats the solution that I was proposing, because they are public available, while if the JWS was signed with a secret, it would be only known by the DID backend and the client backend, therefore allowing for JWS tokens to not reveal to the outside world if they represent a valid authentication or an invalid one.
JWE Instead of JWS

If someone explained that they required it for an application then I guess yes we would jump it up the priority list.

As I mention PII information needs to be kept private all the time, and in my opinion JWE should be the only option available when PII data is included in a token, despite what any standard may say, because standards are always lagging years behind the needs of the real world. Bear in mind that I am not saying that standards are not good or should not be followed, by the contrary, but sometimes you have to upgrade them on your own when it makes sense, like in PII data protection.

On the subject of emails being in the token claim, I think there are different use cases.
I'd like the user to have the option of logging in anonymously or not. If not, then my website can examine the email address and decide whether they have specific privileges. If anonymous, then they may have limited access to my website, perhaps only with the ability to save data/preferences in local storage.
The above assumes that the email address is reliable, which for me means that it has been verified (by DID) in the past, say, 7 days. Like mobile phone numbers, email addresses can be recycled. Or when someone leaves a company they can be terminated, and I don't want that person to have access.
--
On other issues above, since the aud claim is being sent securely to my backend, which already has the client id in an environment variable, I like that I can compare them. Perhaps with a SPA, I would have some concern that the user would have access to it, or perhaps that's solved with PKCE.
As an alternative to JWT, JWS and JWE, I've been looking at PASETO, which was "developed as a simpler, more secure alternative to JWTs".


OCaml 4.09.0 (or 4.08.1 (or 4.08.0))

ppx_tools is not in OPAM for 4.08, though it's updated in Github.
Do we wait for OPAM to catchup, or put ppx_tools in src/external?

I think we can just wait as we're not in a big rush -- I made an issue here https://github.com/ocaml-ppx/ppx_tools/issues/73

ppx_tools is now available for 4.08. But some other ppx-related packages are not yet caught up, like ppxlib. That package will install, but it uses 4.07 parse trees, making it incompatible with other packages, like ppx_deriving, which use 4.08 trees.
Current plan: wait for the ecosystem to catch up to 4.08 before migrating.
Other issues: a signature constraint on recursive modules in Cached is an error in 4.08.
Also, [%%error for optcomp doesn't seem to work with 4.08, for whatever reason.

OCaml 4.08.1 was just released.

Jane Street's ppx_module_timer is not ready for 4.08.x.
There was code committed within the last few days that appears to do the upgrade, not yet in OPAM.
Meanwhile, I rebased my tentative branch on develop:  https://github.com/CodaProtocol/coda/tree/feature/ocaml-4.08.1

Ocaml 4.09.0 is released: https://ocaml.org/releases/4.09.0.html

OCaml 4.10 was due in January 2020; there were issues that have stalled the release.

Superseded by #5413.


Turn SwiftLint back on

Task/Issue URL: https://app.asana.com/0/414709148257752/1196995126357495
CC:
Description:
This PR turns SwiftLint back on and fixes existing violations.
There are a couple things to do before this PR is ready to be merged:

[x] Test that CI is failing PRs appropriately – will introduce a failing change on this branch and see what happens
[ ] Verify that the fixes here make sense. For example, I have a couple type_body_length comments in test files, but it might make more sense to disable those for the UnitTests directly wholesale (assuming SwiftLint can configure each rule with that level of granularity?)
[ ] Decide if the current rules are still valid and if any need to change

Steps to test this PR:

Build the main app target and verify that no warnings appear
Introduce a violation deliberately and verify that a warning appears

I've tested that SwiftLint fails on CI in this commit: https://github.com/duckduckgo/iOS/pull/738/commits/b6adfc85e5001a8c52e0fd51ceffd1bb260da895


Leaders configuration consolidation and behavior correction

TLDR; This removes theme-monorail-leaders package, migrating any unique items contain within to package-global, this will prevent (go forward) any confusion regarding what is being used by the sites pertaining to Leaders as it will now either be from "core" or package-global.
The "old" block behavior is setup for Mundo here is a test article ID 22884285:

The "new" block behavior is setup for PW here is a test article ID 21577187:

 URGENT: Article category taxonomy are not triggering LIP categories on PackWorld.com


Conv2DTranspose problem

I have 2 problems with Conv2DTranspose layer:

When I try to create model with gpu: false an error with shapes occurs:

Error: Mismatched array shapes for matrix product

Same model, with gpu: false.  There are several warnings:

WebGL: INVALID_VALUE: texImage2D: width or height out of range

And wrong prediction in the end.
I suppose there is a problem with Conv2DTranspose layer. Original TF + Keras works well.
Model summary:
_________________________________________________________________
Layer (type)                 Output Shape              Param #
=================================================================
input (InputLayer)           (None, 3, 1, 1)           0
_________________________________________________________________
ConvNd_0 (Conv2DTranspose)   (None, 512, 4, 4)         25088
_________________________________________________________________
SELU_1 (Activation)          (None, 512, 4, 4)         0
_________________________________________________________________
ConvNd_2 (Conv2DTranspose)   (None, 256, 8, 8)         2097408
_________________________________________________________________
SELU_3 (Activation)          (None, 256, 8, 8)         0
_________________________________________________________________
ConvNd_4 (Conv2DTranspose)   (None, 128, 16, 16)       524416
_________________________________________________________________
SELU_5 (Activation)          (None, 128, 16, 16)       0
_________________________________________________________________
ConvNd_6 (Conv2DTranspose)   (None, 64, 32, 32)        131136
_________________________________________________________________
SELU_7 (Activation)          (None, 64, 32, 32)        0
_________________________________________________________________
ConvNd_8 (Conv2DTranspose)   (None, 32, 64, 64)        32800
_________________________________________________________________
SELU_9 (Activation)          (None, 32, 64, 64)        0
_________________________________________________________________
ConvNd_10 (Conv2DTranspose)  (None, 3, 128, 128)       1539
_________________________________________________________________
Tanh_11 (Activation)         (None, 3, 128, 128)       0
=================================================================
Total params: 2,812,387
Trainable params: 2,812,387

A keras model:
model.zip
Browser 1: Firefox 57.0
Browser 2: Chromium 62.0
Browser 3: Firefox 56.0 (Win64)

Updates:
I thought the problem was with dimension ordering (in previous model it was CHW), so, I've converted the model to other dimension ordering (HWC).
A new error in a console:
Error: [Model] error loading weights.


Add take_along_axis

pfnCI, test this please.

Jenkins CI test (for commit dfabbbcd7610730eac810c1d44d0f2f4df7a48d0, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit 6d17aa1804ca0ff4438921a5a7342c05f0a481f2, target branch master) succeeded!

LGTM!


can replace "hostname" with "ip address"

can replace hostname with ip address ?

I updated the script to include a new field for all the attached NICs.
Machines won't have a consistent one IP address to use if they have multiple NICs so you can filter through the NIC information if you use static IPs and associate the info with the correct machine.


Refactoring in test for callable

Added a new method to test callable object

Thanks @raphaelcsilva for your PR. The changes you propose have been proposed multiple times and they were rejected for several reasons: speed is what matters most for Pimple, the code does not change that much, so a small duplication is not really a problem.


Feature request: //@ts-ignore style ignores for js syntax + ts / js ignore for entire function, etc.

Request: please enable some way to disable JavaScript syntax checks for the next line of code as well as the next statement, entire function and entire class if possible.
Currently it seems to be an all or nothing ordeal with JS syntax checking

Tracked upstream by https://github.com/Microsoft/TypeScript/issues/19573


Curly bracket removal / vscript values output fix

Closes https://github.com/momentum-mod/lumper/issues/53
Curly brackets are currently being treated as special characters that only signify the start and end of sections, but they can appear in any entity - for instance, a valid entity name is {a} - this pr should fix this. (Regarding changes made to EntityLump.cs)
The second part of the change is regarding vscript outputs not saving correctly - previously, commas were used to delimit but when a file is compiled to use vscript, it instead uses \u001b but this was not being taken into account when writing the string to the disk, and as such was being loaded incorrectly (as a regular key/value pair rather than as a specific EntityIO) (Regarding changes made to EntityIO.cs)
Here's a bsp I made for TF2 to test this issue: https://filebin.net/5az4cvzf7mik93ys and it now loads and saves the values correctly (vscript is on the func_button, targetting 'test' with an input of RunScriptCode).

Nice job finding these.
Since the EntityIO stuff is currently in review I don't want to add this change on top of it, I've just applied the ToString fix on my commit that I'll force-push in a minute.
Please can you get rid of the changes to the EntityIo stuff, and just push the curly braces changes?

Thanks - I've updated with just the curly brace changes.


[About Page] Implement page layout

All required components already exist, so simply finish the page structure using existing components (familiarize yourself with repo to see which ones to use)
About, Board Member Highlights, and Alumni Recollections sections are static
Upcoming Events and Past Events are dynamic, but simply fill them with dummy data for now

PR: https://github.com/UCLA-Creative-Labs/sunshine/pull/166


Replace native alert, prompt and confirm with custom modals

Per @aldipower's comment here, we should no longer use native alert, prompt, and confirm calls.

[ ] custom alert
[ ] custom prompt
[ ] custom confirm

Perhaps @pierlo-upitup likes this.. ;)


New version with explicit variable for confluent license.

A simple change to explicitly allow users to enter their confluent license during deployment rather than having to add an environment variable after the deployment.

diff --git a/HEAD:./5/config.json b/HEAD:./6/config.json
index e170c44..5684de7 100644
--- a/HEAD:./5/config.json
+++ b/HEAD:./6/config.json
@@ -61,6 +61,11 @@
           "description": "Replication factor for kafka topics used to store data from the interceptor classes",
           "type": "number"
         },
+        "confluent-license": {
+          "default": "",
+          "description": "License key for Confluent Enterprise (default is 30-day trial)",
+          "type": "string"
+        },
         "zookeeper-connect": {
           "default": "master.mesos:2181/dcos-service-confluent-kafka",
           "description": "Zookeeper Connect string for service cluster. Format is comma-separated list of :/",

diff --git a/HEAD:./5/marathon.json.mustache b/HEAD:./6/marathon.json.mustache
index 6352a24..29f56ac 100644
--- a/HEAD:./5/marathon.json.mustache
+++ b/HEAD:./6/marathon.json.mustache
@@ -23,6 +23,7 @@
     "CONTROL_CENTER_INTERNAL_TOPICS_PARTITIONS": "{{control-center.confluent-controlcenter-intern
al-topics-partitions}}",
     "CONTROL-CENTER_MONITORING_INTERCEPTOR_TOPIC_PARTITIONS": "{{control-center.confluent-monitor
ing-interceptor-topic-partitions}}",     "CONTROL_CENTER_REPLICATION_FACTOR": "{{control-center.confluent-controlcenter-internal-topics-replication}}",
+    "CONTROL_CENTER_LICENSE": "{{control-center.confluent-license}}",
     "CONTROL_CENTER_ZOOKEEPER_CONNECT": "{{control-center.zookeeper-connect}}"
   },
   "healthChecks": [

diff --git a/HEAD:./5/package.json b/HEAD:./6/package.json
index 2ce77a6..1a6afe5 100644
--- a/HEAD:./5/package.json
+++ b/HEAD:./6/package.json
@@ -1,7 +1,7 @@
 {
   "packagingVersion": "3.0",
   "name": "confluent-control-center",
-  "version": "0.9.8-3.2.0",
+  "version": "0.9.8-3.2.0e",
   "scm": "https://github.com/confluentinc/control-center",
   "description": "Confluent Control Center service\n\n\tDocumentation: http://docs.confluent.io/3.2.0/control-center/docs/userguide.html\n\tDC/OS Specifics: https://www.confluent.io/whitepaper/deploying-confluent-platform-with-mesosphere",
   "maintainer"<EMAIL_ADDRESS>

Lgtm.

Done


make synth stuck at synth -top $::env(DESIGN_NAME) -run fine: {*}$synth_args

Version
Yosys 0.45 (git sha1 3e0dc2ff1, clang++ 14.0.0-1ubuntu1 -fPIC -O3)
On which OS did this happen?
Linux
Reproduction Steps
pull the my branch of https://github.com/janboeye/OpenROAD-flow-scripts.
execute make synth
Expected Behavior
finish the synthesis without any error
Actual Behavior
when I synthesis Xiangshan which is a big riscv cpu, it stuck at the second round yosys synth command
synth -top $::env(DESIGN_NAME) -run fine: {*}$synth_args
at stage
5.3.1. Executing OPT_EXPR pass (perform const folding).

@janboeye Hello, can you post reproduction steps for this second issue?

after upgrade to 0.46, the issue is gone.
Thanks


Altered types in NotificationCommon & EventReaction

Issue in focus: #2052
Type of content_truncated which was previously defined as string was changed to boolean as commented out next to it which proved to be iccurate.
Changed type of EventReaction.user from any to string.

Thanks @flowkraD for looking at this!
I think the EventReaction#user annotation is not right; see e.g. aggregateReactions.js, where we pull .user.email off of one of these.
As I mentioned just now in an inline thread above, though, I think these two aren't among the higher-priority things for us to nail down the correct type for. So I'd actually prefer that instead of trying to sort out the right annotations for these, we set them aside for now (so I'll close this PR) and instead go after some of the higher-value annotations to add.
I've just gone and updated #2052 with current stats and a bit of guidance on finding the highest-value areas to add types now:

#2971 is a great source of high-value places to add types. Running yarn run test:flow-coverage remains another great source.

Want to try those?

I'll surely give it a try. I am a bit tight on time (still in freshman year of college) but I'll contribute whenever time permits. Thanks for bringing #2971 to my notice (^_^)


k3sup: 0.12.0 -> 0.12.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/alexellis/k3sup/releases.
meta.description for k3sup is: "Bootstrap Kubernetes with k3s over SSH"
meta.homepage for k3sup is: "https://github.com/alexellis/k3sup"
meta.changelog for k3sup is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.12.3 with grep in /nix/store/gid210zqshy1j005bm3zncak3xakwa5g-k3sup-0.12.3
found 0.12.3 in filename of file in /nix/store/gid210zqshy1j005bm3zncak3xakwa5g-k3sup-0.12.3

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
k3sup

Instructions to test this update (click to expand)

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

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

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

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

k3sup

Maintainer pings
cc @welteki for testing.

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

1 package built:

k3sup


Current destructor strategy yields panic-in-panic

Observe the following backtrace, from the tail end of a compute-sanitizer report. If a panic occurs when Rust is inside what is supposed to be a "nounwind" function, then Rust will adopt a more cynical attitude and start doing what it takes to contain the clearly-unsalvageable runtime.
thread 'main' panicked at ${HOME}/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cudarc-0.11.7/src/driver/safe/core.rs:252:76:
called `Result::unwrap()` on an `Err` value: DriverError(CUDA_ERROR_LAUNCH_FAILED, "unspecified launch failure")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at ${HOME}/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cudarc-0.11.7/src/driver/safe/core.rs:252:76:
called `Result::unwrap()` on an `Err` value: DriverError(CUDA_ERROR_LAUNCH_FAILED, "unspecified launch failure")
stack backtrace:
   0:     0x55b30644ed72 - std::backtrace_rs::backtrace::libunwind::trace::he4ee80166a02c846
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/libunwind.rs:105:5
   1:     0x55b30644ed72 - std::backtrace_rs::backtrace::trace_unsynchronized::h476faccf57e88641
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55b30644ed72 - std::sys_common::backtrace::_print_fmt::h430c922a77e7a59c
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:68:5
   3:     0x55b30644ed72 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hffecb437d922f988
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x55b30647be4c - core::fmt::rt::Argument::fmt::hf3df69369399bfa9
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/rt.rs:142:9
   5:     0x55b30647be4c - core::fmt::write::hd9a8d7d029f9ea1a
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/fmt/mod.rs:1153:17
   6:     0x55b30644b6bf - std::io::Write::write_fmt::h0e1226b2b8d973fe
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/io/mod.rs:1843:15
   7:     0x55b30644eb44 - std::sys_common::backtrace::_print::hd2df4a083f6e69b8
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x55b30644eb44 - std::sys_common::backtrace::print::he907f6ad7eee41cb
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x55b3064502fb - std::panicking::default_hook::{{closure}}::h3926193b61c9ca9b
  10:     0x55b306450053 - std::panicking::default_hook::h25ba2457dea68e65
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:292:9
  11:     0x55b30645079d - std::panicking::rust_panic_with_hook::h0ad14d90dcf5224f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:779:13
  12:     0x55b306450672 - std::panicking::begin_panic_handler::{{closure}}::h4a1838a06f542647
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:657:13
  13:     0x55b30644f246 - std::sys_common::backtrace::__rust_end_short_backtrace::h77cc4dc3567ca904
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:171:18
  14:     0x55b3064503a4 - rust_begin_unwind
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:645:5
  15:     0x55b304a8af95 - core::panicking::panic_fmt::h940d4fd01a4b4fd1
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:72:14
  16:     0x55b304a8b583 - core::result::unwrap_failed::h5119205a73b72b0d
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1654:5
  17:     0x55b3055841fa - core::result::Result<T,E>::unwrap::h4351702c55915e75
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1077:23
  18:     0x55b3055841fa - <cudarc::driver::safe::core::CudaSlice<T> as core::ops::drop::Drop>::drop::h199522ab8947bf06
                               at ${HOME}/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cudarc-0.11.7/src/driver/safe/core.rs:252:17
  19:     0x55b30557f437 - core::ptr::drop_in_place<cudarc::driver::safe::core::CudaSlice<f32>>::hc474f8aea52e9fe5
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  20:     0x55b30557eece - core::ptr::drop_in_place<candle_core::cuda_backend::CudaStorageSlice>::h02edab09154be304
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  21:     0x55b30557ead7 - core::ptr::drop_in_place<candle_core::cuda_backend::CudaStorage>::h4e03b09cdf55c603
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  22:     0x55b30557debc - core::ptr::drop_in_place<candle_core::storage::Storage>::h7be6009f4c2999a5
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  23:     0x55b30557fddb - core::ptr::drop_in_place<core::cell::UnsafeCell<candle_core::storage::Storage>>::hf62ca5d0a694c5b9
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  24:     0x55b30558012f - core::ptr::drop_in_place<std::sync::rwlock::RwLock<candle_core::storage::Storage>>::h9c84a0dc451d5c0b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  25:     0x55b3054f4f9f - alloc::sync::Arc<T,A>::drop_slow::h963cb23aaa1b6829
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/sync.rs:1804:18
  26:     0x55b305581902 - <alloc::sync::Arc<T,A> as core::ops::drop::Drop>::drop::h0bfec242c64e8bd3
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/sync.rs:2459:13
  27:     0x55b30557a63b - core::ptr::drop_in_place<alloc::sync::Arc<std::sync::rwlock::RwLock<candle_core::storage::Storage>>>::hb3ee87cb7d8fccdc
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  28:     0x55b30557dd3e - core::ptr::drop_in_place<candle_core::tensor::Tensor_>::ha997d43af8c0f265
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  29:     0x55b3054f4fef - alloc::sync::Arc<T,A>::drop_slow::h9e22af1c62f14f2f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/sync.rs:1804:18
  30:     0x55b305581a82 - <alloc::sync::Arc<T,A> as core::ops::drop::Drop>::drop::h469fb82faeb75789
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/sync.rs:2459:13
  31:     0x55b30557fa0b - core::ptr::drop_in_place<alloc::sync::Arc<candle_core::tensor::Tensor_>>::h476f8404d54093fe
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  32:     0x55b30557dafb - core::ptr::drop_in_place<candle_core::tensor::Tensor>::h586db7ae68ea4be0
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ptr/mod.rs:515:1
  33:     0x55b30501e6ed - candle_transformers::models::quantized_llama::ModelWeights::forward::h0dfb5d857c758ce3
                               at ${HOME}/${CRATE_USING_CANDLE}/candle-transformers/src/models/quantized_llama.rs:486:9
  34:     0x55b304a9acd2 - <ai_lib::models::llama_3_70b_instruct_32k_gguf::Llama3_70bInstruct32kGGUF as ai_lib::models::model_wrapper::ModelWrapper>::inference::h279f36a3b9cc9fbf
                               at ${HOME}/${CARGO_PROJECT}/ai-lib/src/models/llama_3_70b_instruct_32k_gguf.rs:189:26
  35:     0x55b304a9787a - cli::main::h8ee7a7979e775a0e
                               at ${HOME}/${CARGO_PROJECT}/cli/src/main.rs:103:24
  36:     0x55b304a96fcb - core::ops::function::FnOnce::call_once::h772466b7bf645693
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
  37:     0x55b304a9740e - std::sys_common::backtrace::__rust_begin_short_backtrace::h8af7e217acbaa4da
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/sys_common/backtrace.rs:155:18
  38:     0x55b304a96f71 - std::rt::lang_start::{{closure}}::h67443931d40186ff
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:166:18
  39:     0x55b306443a03 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h52f5991f9ab8b369
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:284:13
  40:     0x55b306443a03 - std::panicking::try::do_call::h0ac4bee9a397a1bf
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
  41:     0x55b306443a03 - std::panicking::try::hc005decaf198d0ed
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
  42:     0x55b306443a03 - std::panic::catch_unwind::hb0f967d870b2a382
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
  43:     0x55b306443a03 - std::rt::lang_start_internal::{{closure}}::hd140b84b0efe534b
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:148:48
  44:     0x55b306443a03 - std::panicking::try::do_call::h1ddfaf1d0d576c38
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:552:40
  45:     0x55b306443a03 - std::panicking::try::hdd4bdf855547659f
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:516:19
  46:     0x55b306443a03 - std::panic::catch_unwind::h276ba91c7706110c
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panic.rs:146:14
  47:     0x55b306443a03 - std::rt::lang_start_internal::h103c42a9c4e95084
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:148:20
  48:     0x55b304a96f4a - std::rt::lang_start::he3400f8001dc9f83
                               at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/rt.rs:165:17
  49:     0x55b304a97c7e - main
  50:     0x7f850a229d90 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  51:     0x7f850a229e40 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:392:3
  52:     0x55b304a96e45 - _start
  53:                0x0 - <unknown>
thread 'main' panicked at library/core/src/panicking.rs:164:5:
panic in a destructor during cleanup
thread caused non-unwinding panic. aborting.
========= Error: process didn't terminate successfully
========= Target application returned an error
========= ERROR SUMMARY: 4835 errors
========= ERROR SUMMARY: 4735 errors were not printed. Use --print-limit option to adjust the number of printed errors

Well if one of the kernels fails to launch, continuing on could result in undefined behavior. For example maybe the kernel the failed was setting uninitialized memory, and if we continue on, then successive kernels may be working with memory that wasn't initialized.
Also I'm not sure if the call to free in this case succeeds or not if it returns back an error from a previous call. So the memory is in an unclear state. The nvidia docs don't specify so to me that is undefined behavior (could be either).

Hmm. So, when I discuss the soundness of Rust programs, and I say "undefined behavior", I do not mean "it may be this or that". I mean that a generous compiler would then abort the program if it recognized the case occurred, and that most compilers will simply ignore it and do something that should never happen, like arrange the code so that code that is never called, is reached.
This is most useful to distinguish this from a nondeterministic result. By which I mean, the classic "one of 2 outcomes occurred, and it's not clear which".
Part of why it is very useful to make this distinction is sometimes acting on the assumption that one of two possible results happened can lead to full-stop no-holds-barred undefined behavior. So nondeterminism is not UB yet, but it is a common source of UB in a program (e.g. if we free a second time "just to make sure" we may double-free).
And as far as uninitialized memory, it is allowed to manipulate uninitialized memory in a Rust program. It is not even unsafe:
fn main() {
    let mut byte = std::mem::MaybeUninit::<u8>::uninit();
    byte.write(5);
}

Deallocated memory, or never-allocated memory, however, should not be examined.
Anyways, in another example I had encountered, the error was, in fact, CUDA_ERROR_ILLEGAL_ADDRESS. I am slightly concerned that what may wind up happening sometimes is that a panic occurs for other reasons and, the panic unwinds the stack, starts executing destructors, and because we're in a "doomed universe"... as you said, a prior error can be returned... we essentially-automatically panic-in-panic. This makes it harder to debug an already-bad situation.

Fair points, that all tracks with me.
I guess I'm still not sure if there's a better way to handle this inside cudarc. One CUDA specific thing that would help debugging in this situation is to set export CUDA_LAUNCH_BLOCKING=1, which basically makes all the launch calls blocking. That would take care of the fact that this error is from a previous launch.
However in the case where the call to free actually fails with its own error, I'm not sure there's much we can do other than panic.

Thanks for the tip! I'll try to use that for debugging the issues I'm seeing a bit more intently.
One option is that you could consider whether Rust is currently panicking and decide on whether or not to throw another panic or whether or not to cudaFreeAsync then? Definitely a panic should happen.


Arifact GC not executing when a workflow has tasks with inline templates

Pre-requisites

[X] I have double-checked my configuration
[X] I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
[X] I have searched existing issues and could not find a match for this bug
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?
I have not checked the latest version of Argo because I don't have control over our environment
Happened:
The artifactGC task was not created and the artifacts remained in a GCS bucket
Expected:
The artifactGC task was created for a workflow with inline templates, artifacts were deleted from a GCS bucket
Version(s)
v3.5.4
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: artifact-passing-
spec:
  serviceAccountName: argo-workflow
  entrypoint: artifact-example
  ttlStrategy:
    secondsAfterCompletion: 180
  artifactGC:
    strategy: OnWorkflowCompletion
    serviceAccountName: argo-workflow
  templates:
  - name: artifact-example
    steps:
    - - name: generate-artifact
        inline:
          container:
            image: docker/whalesay:latest
            command: [sh, -c]
            args: ["cowsay hello world | tee /tmp/hello_world.txt"]
          outputs:
            artifacts:
            - name: hello-art
              path: /tmp/hello_world.txt
    - - name: consume-artifact
        inline:
          inputs:
            artifacts:
            - name: message
              path: /tmp/message
          container:
            image: alpine:latest
            command: [sh, -c]
            args: ["cat /tmp/message"]
        arguments:
          artifacts:
          - name: message
            from: "{{steps.generate-artifact.outputs.artifacts.hello-art}}"

Logs from the workflow controller
kubectl logs -n argo deployment.apps/argo-workflows-workflow-controller | grep artifact-passing-p2qgn

time="2024-07-16T21:12:49.260Z" level=info msg="Processing workflow" Phase= ResourceVersion=648699592 namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.267Z" level=info msg="Task-result reconciliation" namespace=kddadev6-capture-workflows numObjs=0 workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.267Z" level=info msg="Updated phase  -> Running" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.267Z" level=warning msg="Node was nil, will be initialized as type Skipped" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.268Z" level=info msg="was unable to obtain node for , letting display name to be nodeName" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.268Z" level=info msg="Steps node artifact-passing-p2qgn initialized Running" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.268Z" level=info msg="StepGroup node artifact-passing-p2qgn-1879951682 initialized Running" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.268Z" level=warning msg="Node was nil, will be initialized as type Skipped" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.269Z" level=info msg="Pod node artifact-passing-p2qgn-1402143536 initialized Pending" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.316Z" level=info msg="Created pod: artifact-passing-p2qgn[0].generate-artifact (artifact-passing-p2qgn--1402143536)" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.316Z" level=info msg="Workflow step group node artifact-passing-p2qgn-1879951682 not yet completed" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.316Z" level=info msg="TaskSet Reconciliation" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.316Z" level=info msg=reconcileAgentPod namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:49.327Z" level=info msg="Workflow update successful" namespace=kddadev6-capture-workflows phase=Running resourceVersion=648699596 workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.317Z" level=info msg="Processing workflow" Phase=Running ResourceVersion=648699596 namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.318Z" level=info msg="Task-result reconciliation" namespace=kddadev6-capture-workflows numObjs=0 workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.319Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argo-workflows.readthedocs.io/en/release-3.5/workflow-rbac/" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.319Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argo-workflows.readthedocs.io/en/release-3.5/workflow-rbac/" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.319Z" level=info msg="node changed" namespace=kddadev6-capture-workflows new.message= new.phase=Succeeded new.progress=0/1 nodeID=artifact-passing-p2qgn-1402143536 old.message= old.phase=Pending old.progress=0/1 workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.320Z" level=info msg="Step group node artifact-passing-p2qgn-1879951682 successful" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.320Z" level=info msg="node artifact-passing-p2qgn-1879951682 phase Running -> Succeeded" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.320Z" level=info msg="node artifact-passing-p2qgn-1879951682 finished: 2024-07-16 21:12:59.320623319 +0000 UTC" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.320Z" level=info msg="StepGroup node artifact-passing-p2qgn-738926495 initialized Running" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.320Z" level=info msg="SG Outbound nodes of artifact-passing-p2qgn-1402143536 are [artifact-passing-p2qgn-1402143536]" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.320Z" level=warning msg="Node was nil, will be initialized as type Skipped" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.321Z" level=info msg="Pod node artifact-passing-p2qgn-3674481728 initialized Pending" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.343Z" level=info msg="Created pod: artifact-passing-p2qgn[1].consume-artifact (artifact-passing-p2qgn--3674481728)" namespace=kddadev6-capture-workflows workflowartifact-passing-p2qgn
time="2024-07-16T21:12:59.343Z" level=info msg="Workflow step group node artifact-passing-p2qgn-738926495 not yet completed" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.344Z" level=info msg="TaskSet Reconciliation" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.344Z" level=info msg=reconcileAgentPod namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.355Z" level=info msg="Workflow update successful" namespace=kddadev6-capture-workflows phase=Running resourceVersion=648699727 workflow=artifact-passing-p2qgn
time="2024-07-16T21:12:59.362Z" level=info msg="cleaning up pod" action=labelPodCompleted key=kddadev6-capture-workflows/artifact-passing-p2qgn--1402143536/labelPodCompleted
time="2024-07-16T21:13:09.345Z" level=info msg="Processing workflow" Phase=Running ResourceVersion=648699727 namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.347Z" level=info msg="Task-result reconciliation" namespace=kddadev6-capture-workflows numObjs=0 workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.347Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argo-workflows.readthedocs.io/en/release-3.5/workflow-rbac/" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.347Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argo-workflows.readthedocs.io/en/release-3.5/workflow-rbac/" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.347Z" level=info msg="node changed" namespace=kddadev6-capture-workflows new.message= new.phase=Succeeded new.progress=0/1 nodeID=artifact-passing-p2qgn-3674481728 old.message= old.phase=Pending old.progress=0/1 workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="SG Outbound nodes of artifact-passing-p2qgn-1402143536 are [artifact-passing-p2qgn-1402143536]" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="Step group node artifact-passing-p2qgn-738926495 successful" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="node artifact-passing-p2qgn-738926495 phase Running -> Succeeded" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="node artifact-passing-p2qgn-738926495 finished: 2024-07-16 21:13:09.348391234 +0000 UTC" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="Outbound nodes of artifact-passing-p2qgn-3674481728 is [artifact-passing-p2qgn-3674481728]" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="Outbound nodes of artifact-passing-p2qgn is [artifact-passing-p2qgn-3674481728]" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="node artifact-passing-p2qgn phase Running -> Succeeded" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="node artifact-passing-p2qgn finished: 2024-07-16 21:13:09.348486263 +0000 UTC" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="TaskSet Reconciliation" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg=reconcileAgentPod namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="Updated phase Running -> Succeeded" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.348Z" level=info msg="Marking workflow completed" namespace=kddadev6-capture-workflows workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.353Z" level=info msg="cleaning up pod" action=deletePod key=kddadev6-capture-workflows/artifact-passing-p2qgn-1340600742-agent/deletePod
time="2024-07-16T21:13:09.358Z" level=info msg="Workflow update successful" namespace=kddadev6-capture-workflows phase=Succeeded resourceVersion=648699854 workflow=artifact-passing-p2qgn
time="2024-07-16T21:13:09.360Z" level=info msg="Queueing Succeeded workflow kddadev6-capture-workflows/artifact-passing-p2qgn for delete in 3m0s due to TTL"
time="2024-07-16T21:13:09.439Z" level=info msg="cleaning up pod" action=labelPodCompleted key=kddadev6-capture-workflows/artifact-passing-p2qgn--3674481728/labelPodCompleted

Logs from in your workflow's wait container
kubectl logs -n argo -c wait -l workflows.argoproj.io/workflow=artifact-passing-p2qgn,workflow.argoproj.io/phase!=Succeeded

No resources found in argo namespace.

I have reproduced the problem and will see how to solve it.

After reconfirming, I found that this problem does not exist in the latest version.


Incompatible module not loaded but bad error message

Using the daily build with the new Compatibility Deny list.
Loading a denied module results in curious error message.
Steps to reproduce
# With daily build
Import-Module -Name BestPractices

Expected behaviour
Import-Module: Failed to Load module 'BestPractices' in a PSWinCompatability session. This module is on the PowerShellCompatibilityModuleDenyList. See XXXX for more details on this issue.

Actual behavior
PS C:\Dailybuild> Import-Module -Name BestPractices
Import-Module: Failed to generate proxies for remote module 'bestpractices'. Running the Get-FormatData command in a remote session reported the following error: Unable to cast object of type 'Microsoft.PowerShell.Commands.Internal.Format.ControlReference' to type 'Microsoft.PowerShell.Commands.Internal.Format.ComplexControlBody'..``

# Environment data

```none
PS C:\Dailybuild> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.0-rc.2
PSEdition                      Core
GitCommitId                    7.0.0-rc.2
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.0.0, 6.1.0, 6.2.0, 7.0.0-rc.2}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Also - in the error message, the module name is in all lower case, yet it was in entered differently. Shouldn't the error message reflect what was actually typed?

/cc @anmenaga

@doctordns  That is pre-fix behavior. what link did you use to download the daily build?


[BUG] Mux player crushed in Nextjs 14.0.2

Discussed in https://github.com/muxinc/elements/discussions/817

Originally posted by zrtsky November 10, 2023
Failed to load @mux/mux-player-react: 2.1.0  on next: 14.0.2 because some problems with hls.js import
Screen

Logs

PS
I think it's can be started from next: 14.0.2-canary.0, here is the link to discussion about this issue

same issue on https://github.com/muxinc/next-video/issues/109

Is there any way to fix this?

Thanks for reporting! We're searching for the cause of this issue. We'll keep you updated here.

I can confirm this also happen on my app since I upgraded next to 14.0.2. Had no issues on 14.0.1

https://github.com/vercel/next.js/releases/tag/v14.0.2-canary.0 still works
https://github.com/vercel/next.js/releases/tag/v14.0.2-canary.1 fails

Hello guys, is there any update on the progress of this?

For me it stopped since the release of Next 14.0.3

I am also having this problem with next.js 14.0.3 , turbo, typescript 5.3.2

@luwes Hey! Any update on this? Still seeing the issue on v14.0.4-canary.26, I'm keeping my project at 14.0.01 but would love to upgrade for the cache fixes in 14.0.4.

this is resolved in Next.js v14.0.4 https://github.com/vercel/next.js/releases/tag/v14.0.4


Create representation of request data prior to submission

Is your feature request related to a problem? Please describe.
In order to move development forward, it would be helpful to have a sense of what data should look like prior to submission (i.e. what ProcessRequest().run() produces).
Describe the solution you'd like
A static representation of request data, ideally as fixtures that could be pulled into unit tests. This could initially be done by looking at the fields that Aeon captures.
Ultimately we'll probably want to codify this in a JSON Schema so we can validate inputs and outputs.

Example of data required from as in fixtures/as_data.json.


KryoNet doesn't allow usage of Kryo 5.0.2's StdInstantiatorStrategy

Been working on a project since 2010 in Java, has been migrated through all the versions since. It's essentially outsider art what I'm working on.
Ran into a problem where I tried to serialize a SynchronizedRandomAccessList after migrating from Vectors both of which are part of the Java Standard Library. Easy way to do this, and how I'm going to fix it is simply modify the source of the Java Standard Library to add a no arg constructor for this. I shouldn't have to do this with any library.
What I should be doing is changing Kryo to use the standard strategy to StdInstantiatorStrategy as described in the Kryo Documentation, however KryoNet is using Kryo 2.2.0, instead of 5.0.2 and as such it doesn't exist that far back.
How to fix this:
Update Kryonet to use Kryo 5.x
How to reproduce it:
Try to declare a Instantiate Strategy with the library.

Can't modifiy the Java Standard Library anyway, so yeah.
Tried a workaround by using SerializationInstaniationStrategy and I'm getting
Caused by: org.objenesis.ObjenesisException: java.io.NotSerializableException: class com.esotericsoftware.kryonet.FrameworkMessage$RegisterTCP not serializable
So yeah, I'm gonna have to switch libraries. Worked 7 years ago when the last version came out, but doesn't work now.

Can't modifiy the Java Standard Library anyway, so yeah.
Tried a workaround by using SerializationInstaniationStrategy and I'm getting
Caused by: org.objenesis.ObjenesisException: java.io.NotSerializableException: class com.esotericsoftware.kryonet.FrameworkMessage$RegisterTCP not serializable
So yeah, I'm gonna have to switch libraries. Worked 7 years ago when the last version came out, but doesn't work now.

Hey @Daburnell112! This issue is basically a – more up to date – duplicate of #77 or any of the PRs that suggest updating the framework to Kryo 4.0. If you want to use Kryo 5 with Kryonet, your are best off taking a look at any of the forks that have already done this.

Hey @Daburnell112! This issue is basically a – more up to date – duplicate of #77 or any of the PRs that suggest updating the framework to Kryo 4.0. If you want to use Kryo 5 with Kryonet, your are best off taking a look at any of the forks that have already done this.

Alright I figured it out.
I ended up implementing the KryoSerializer class and changing the list to an array, deleting the reference to the list, and then serializing the class with the array.
I think the problem I encountered was that the code button to download a zip uses an outdated version of Kryo in the Jar file that's with the distributable. I built the jar file from one of the branches into a jar file with the latest Kryo build and I think it works.
Apart from that, I think I figured it out so the issue is closed.


Is it possible to implement add references extension from Tao Liu?

I am using this tool (https://visualstudiogallery.msdn.microsoft.com/6d40737b-9a08-466a-9316-e6371c81a14a) from Tao Liu in VS2012. I know that in VS2013 you can right click and references are loaded in the FSI. But it does not create the Scripts folder with script files that contain the references. That works much nicer, as you can then load the 'add reference script' file at the top of your own script file.
Any change that this will be added to the power tools?

I am now using this excellent feature. At first I did not understand that you had to add your script files to the Script folder (unlike the original tool), due to the fact that you use relative paths. But I do think that this setup is nicer, as you now separate source code with script code. So I came up with the following setup:

However, maybe this should be mentioned in the user guides? The fact that you cannot use the load scripts from the root folder?

Thanks. The original doc is at https://github.com/fsprojects/VisualFSharpPowerTools/blob/master/docs/content/generatereferences.fsx, which generates the html version at http://fsprojects.github.io/VisualFSharpPowerTools/generatereferences.html. Please feel free to send a pull request if you would like to add more information.


Different version numbers used for the same dependency

In 1.1.0-SNAPSHOT it looks like the org.symphonyoss.symphony/symphony-authenticator-java-jersey2-client and org.symphonyoss.symphony/symphony-pod-java-jersey2-client JARs end up having dependencies on different versions of com.fasterxml.jackson.core/jackson-databind.
The former ends up dependent on 2.8.4, while the latter ends up dependent on 2.8.9.  In contrast, the main SJC library says it's dependent on Jackson 2.9.1, which is a whole minor version higher than either of these.

The dependency graphs are:
org.symphonyoss.symphony/symphony-authenticator-java-jersey2-client:1.48.0-SNAPSHOT -> com.fasterxml.jackson.datatype/jackson-datatype-jsr310:2.8.4 -> com.fasterxml.jackson.core/jackson-databind:2.8.4
and
org.symphonyoss.symphony/symphony-pod-java-jersey2-client:1.48.0-SNAPSHOT -> io.swagger/swagger-core:1.5.16 -> com.fasterxml.jackson.core/jackson-databind:2.8.9

Note that this was discovered while tracking down a recently reported CVE:


Add support for Matic (Polygon)

The third network to be supported is Matic

Being replaced with tasks on Subgraph v2


Contextual Visibility of certain elements in sheets and subsheets/lists

Right now Depot assumes you want to see everything all the time. However, some things should be contextually hidden/shown to make the interface less overwhelming. Specifically:

[ ] The line removal icon should only be shown if the specific line it removes is being hovered
[x] The new field buttons in List fields should only be shown if that list is being hovered
[ ] The add line buttons in List fields should only be shown if that list is being hovered

I've experiemented with fixes for hiding the line removal icon and add line buttons and none of them really "feel" that great. The add line one especially is actually a nice visual element to indicate the end of a sheet. If someone else has ideas for how to tackle the rest of this issue in an elegant way I'm happy to reopen the issue, but for now I'm closing it.

I've experiemented with fixes for hiding the line removal icon and add line buttons and none of them really "feel" that great. The add line one especially is actually a nice visual element to indicate the end of a sheet. If someone else has ideas for how to tackle the rest of this issue in an elegant way I'm happy to reopen the issue, but for now I'm closing it.


provide charset encoding in content-type request header for xmla requests

In current implementation it's not clear which encoding is used for transport. This might result in broken passwords with umlauts when using e.g. iso-8859-1 for decoding the basic authentication token. With the charset information the destination is able to decode the token properly.

Fixed in https://github.com/olap4j/olap4j/commit/c8dcebc9d58182fafcdd680c44248c4223a6f0a7.


About attribute predictor and re-scoring analysis.

Dear @ShenYujun  :
Thanks for your excellent works. It is very useful for my research and I will cite your work in my study. However, I have some issues with re-scoring analysis since the attribute predictor is lost (The same issue on InterfaceGAN). Would you mind releasing your pre-trained attribute predictor's code and model?
Thank you again.
Best wishes.

Please refer to this repo.

Many thanks for your prompt reply. After reading this repo, I still haven't found how to train a predictor with an attribute of the pose. Can you give me some suggestions?

A very simple solution as an example: to get the pose (i.e., left v.s. right), you can use the x-coordinate of the nose point or the x-coordinate of the middle point between two eyes.

Sure, I am very grateful for your guidance. I will train a classifier for it.

Hi,
Could you release code for rescoring-analysis metric in order to reproduce the results in the paper?
Thanks!


[stable/keycloak] Fix Openshift permission error on test pod startup

What this PR does / why we need it:
Enables the test pod to run in Openshift (or any other Kubernetes distribution that enforces containers to not run as the root user) environments.
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes https://github.com/helm/charts/issues/12374

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md

Thanks for the PR. However, any change requires a chart version bump and commits need to be signed off.
I think this is an important issue, so I decided to pick it up. I think we should really use a security context for the test pod as well. I created another PR that also implements this: #12383

@juv please sign the DCO and bump the chart version as well, thanks!

Closing in favor of #12383.


Add CSV read/write converters for all data types

CSV format support was added in commits ab6c11a3dec6e565b1aff8443618619a3739ff0e and 9e1694faaec6aeaebb9993c1d7653bafe71924d0, but converters for all data types have been implemented yet. Currently, only write converter for EyeMovement is available for CSV in the UXI.GazeToolkit.Serialization library, but for JSON, converters for all main data types are available.

changed name of the issue

Support for CSV format was added in 1cd0b5ffc9418517c15dedb4bb7d89d1b35203f6


/values/strings.xml Missing

/values/strings.xml file is not there in the app , after opening in the app editor given by the Th30neAnd0nly
Please Fix the app file As soon as it could be.......................

can you share some screenshots regarding that , it would be helpful

Ok can I send the Video of It?

Yes


Fix semantic release attempt two

Second attempt to fix the issue happening on the Github action with semantic release.
The issue with v24 seems to be with conventional commits dependency (/semantic-release/release-notes-generator/issues/657) but in this case I'm installing semantic release instead to lock its version down and avoid these kinds of issues unexpectedly creeping in when we don't expect to have to deal with them.

:tada: This PR is included in version 1.47.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fatal error: updated constraint could not find existing matching constraint to update

New Issue Checklist

[X] I have looked at the Documentation
[X] I have read the F.A.Q.
[X] I have filled out this issue template.

Issue Info

Info
Value

Platform
ios

Platform Version
12.2

SnapKit Version
5.0.0

Integration Method
cocoapods

Issue Description
After SnapKit update (5.0.0 was 4.2.0) I have now fatal error on updateConstraints

Updated constraint could not find existing matching constraint to update
After some investigations I discovered where the issue is located: LayoutConstraint.swift
The object comparison between firstAnchor or secondAnchor doesn't work properly.

I don't understand the purpose of #574 because firstItem is unowned(unsafe) meaning it'll crash if you try to update constraints for deallocated object
The real question is: Why are you trying to update constraints for deallocated objects 😄

The point of the https://github.com/SnapKit/SnapKit/pull/574 is that the object that the constraints are updated for is not deallocated and the EXC_BAD_ACCESS was raises when the firstAnchor or secondAnchor were accessed. The problem is fixed with https://github.com/SnapKit/SnapKit/pull/574. Please, follow Apple documentation about this properties:
/* accessors
firstItem.firstAttribute {==,<=,>=} secondItem.secondAttribute * multiplier + constant
Access to these properties is not recommended. Use the firstAnchor and secondAnchor properties instead.
*/

It is ”not recommended by Apple”, so what? It's not deprecated and I join @arnauddorgans, this version completely broken my projects too, rollback to 4.2 needed.

@bill350 @arnauddorgans I think @sashabelonogov's intentions were good so there's no need to be ill willed about this.
@sashabelonogov I believe the problem is that you're doing a === compare which compares the object pointers (invalid since NSLayoutAnchor is unique to each constraint) instead there is a weak var item: AnyObject inside NSLayoutAnchor that we can compare which from looks is identical to the old NSLayoutConstraint.item but weak so a nil value will not cause a crash.
@arnauddorgans @bill350 can either of you two check against develop and see if this solves your issue?

Sorry @robertjpayne if we were annoyed.
Fixes are always good intentions, but in this case the issue reproductibility was easy.
To avoid that in the future,  we can add UI tests target on the SnapKit project ;)
Anyway, according to your reply, there are two things:
develop fixes not compile
I just tried to link the top commit c904582015d5a8eed917d79a7f28ea2b5a8ddde3 on the develop branch but I've got compile errors on an "item" property for NSLayoutAnchor 🤔. I think something is missing, or maybe you've mixed firstItem property?

Cocoapods 1.6.1
iOS 10 minimum target

NSLayoutAnchor introduction
I think the basis of the problem, with the merge of https://github.com/SnapKit/SnapKit/pull/574, is the introduction of the anchor system for the layout constraint comparaison, where NSLayoutAnchor seems to change after constraint creation.
I understand the Apple documentation that @sashabelonogov mentioned, but it's different things & levels for SnapKit equality comparaison.
Here an example between anchors vs items comparaison on a topMargin update (from 0 to 30):

Anchor pointers comparaison (false)
Items pointers comparaison (true)

Please check the @arnauddorgans sample too.

@bill350 thanks for your help, can you test again with latest commit? Sorry my time is extremely limited (the .item property is only available on macOS fun times…)

@robertjpayne, no pressure 🤗.
We have to take our time for this issue, with @sashabelonogov and @arnauddorgans too.
Create a dedicated branch will be better, I will find time for a PR tomorrow.
I can still have my project on Swift 5 and point to the 4.2 release of SnapKit in Swift 4.2 ;)
I've checked the commit and I still have a fatal error with the same sample of @arnauddorgans.
I don't understand why you are using anchor objects comparaison instead of items because it will simply not succeed. NSLayoutAnchor property will be different during the comparaison. Perhaps there is a difference between iOS and macOS layouting?
I've not developed macOS apps so far... I'm waiting for @sashabelonogov details too 🙂.

I will be able to dedicate some time to it to help with the issue.
I have an example that raises EXT_BAD_ACCESS randomly (every second/third time the application is opened) when the items are used (4.2.0 of SnapKit) The application works well with the changes applied in 5.0.0.
@bill350 or @arnauddorgans, does every updateConstraints raise this fatalError?
If not, could you please share an example to help reproduce it?
Thank you!

@sashabelonogov, sure, it fails with margin properties, with topMargin for instance, but no crash with .top.
Simply use this sample code to test the crash:
import UIKit
import SnapKit

class ViewController: UIViewController {

  let snapView = UIView()

  override func viewDidLoad() {
    super.viewDidLoad()
    self.view.addSubview(self.snapView)
    self.snapView.snp.makeConstraints { (make) in
      make.topMargin.equalToSuperview()
    }

    self.snapView.snp.updateConstraints { (make) in
      make.topMargin.equalToSuperview()
    }
  }
}

Sound like xxMargin (xx: top,  left, right, bottom)as a computed property,  created every time when accessed it.  Using === is not the right way.  There is no problem when updating only top, left, right, bottom. Also, it does not work when using as the following way, ` self.snapView.snp.makeConstraints { (make) in
make.top.equalTo(self.view.topMargin)
}
self.snapView.snp.updateConstraints { (make) in
  make.top.equalTo(self.view.topMargin)
}`

Any updates on this regression @sashabelonogov ?
Did you check the sample code?

Has this problem been resolved?

No. We just raised the regression about margins update crash, but no strong investigation started to fix it (simply rollback).

I'm looking into this again today, I'm really sorry for the major delay just been super busy.

This is now resolved with release of 5.0.1, the solution was an entire rollback on #574. @arnauddorgans if you can provide a more concrete example of what is causing this bug we can possibly work towards a fix.
The main issue is that SnapKit has no other way to compare constraints (NSLayoutAnchor is simply just not equatable and does not have public API's suitable for comparing).
My guess is your main issue is caused by you losing references to NSLayoutGuide's or NSLayoutAnchor's and then attempting an update constraint.

v5.0.1 Has this problem been resolved?

encounter same problem


Add nostrcheck.me to image hosts

Add nostrcheck.me to image hosts

LGTM! But I'd link to the public gallery as this is about image hosting.

Of course, it is better to link to the gallery.
Thanks for adding it 🙂


[CSL-555] Use 'onException' in 'applyWithRollback'

@neongreen can you merge/rebase? There are multiple conflicts and I had a feeling that I was looking at old code when I was reviewing it. After that I will review again.

Required statuses must pass before merging

I blame macOS.

Did you report it to DEVOPS-204?

I think I did. Not sure.


WARNING: img2table 1.0.1 does not provide the extra 'paddle-gpu'

when i run !pip install img2table[paddle-gpu] on colab, is this normal?

Hi,
Nope, I checked and there is a bug. I will fix it and include it in the next release

It is now fixed in the newest release.
The syntax is now pip install img2table[paddlegpu]. I guess the dash was messing up this thing.


web app up: getting error on command Create a web app

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az webapp up
Errors:
'NoneType' object has no attribute 'resource_group'
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 603, in execute
    raise ex
cli/core/commands/__init__.py, ln 661, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 652, in _run_job
    cmd_copy.exception_handler(ex)
...
cli/core/commands/__init__.py, ln 306, in __call__
    return self.handler(*args, **kwargs)
azure/cli/core/__init__.py, ln 485, in default_command_handler
    return op(**command_args)
cli/command_modules/appservice/custom.py, ln 2793, in webapp_up
    current_rg = app_details.resource_group
AttributeError: 'NoneType' object has no attribute 'resource_group'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az webapp up --location {} --name {}

Expected Behavior
Environment Summary
Linux-4.15.0-1059-azure-x86_64-with-debian-stretch-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.74

Additional Context

duplicate with #10713

Close this one as it is duplicated with #10713


Timestamps - localTimestamp/issueTimestamp, conversion, and URL parameters

Issue
There may be in issue with how the timestamps are handled in this library. I have reached out to MSW for additional information. Some questions that should be answered:

When querying the API, should the timestamps provided to the start and end URL parameters be in the user's local time or in UTC?
localTimestamp is described in the docs as Unix timestamp adjusted to represent local time for this location. Should this be converted to a Python datetime object as datetime.fromtimestamp() or datetime.utcfromtimestamp().
issueTimestamp is described as in the docs as GMT unix time for the start of this forecast. Although we call it the ‘issue’ time it’ll always actually become available after this time because we need to create or obtain the model data and prepare it for delivery. Is this referring to the time when the forecast was made?

Observations

Example query with start and end parameters set to datetime.now().timestamp()<PHONE_NUMBER>.53376) returned:

[
  {
    "timestamp":<PHONE_NUMBER>,
    "localTimestamp":<PHONE_NUMBER>,
    "issueTimestamp":<PHONE_NUMBER>,
    "fadedRating": 0,
    "solidRating": 0,
    "swell": {
      "absMinBreakingHeight": 0.82,
      "absMaxBreakingHeight": 1.28,
      "probability": 75,
      "unit": "ft",
      "minBreakingHeight": 1,
      "maxBreakingHeight": 1,
      "components": {
        "combined": {
          "height": 1.8,
          "period": 7,
          "direction": 268.24,
          "compassDirection": "E"
        },
        "primary": {
          "height": 0.9,
          "period": 7,
          "direction": 253.39,
          "compassDirection": "ENE"
        },
        "secondary": {
          "height": 0.9,
          "period": 8,
          "direction": 285.52,
          "compassDirection": "ESE"
        },
        "tertiary": {
          "height": 1.1,
          "period": 3,
          "direction": 303.51,
          "compassDirection": "ESE"
        }
      }
    },
    "wind": {
      "speed": 5,
      "direction": 305,
      "compassDirection": "SE",
      "chill": 91,
      "gusts": 9,
      "unit": "mph"
    },
    "condition": {
      "pressure": 1018,
      "temperature": 86,
      "weather": "1",
      "unitPressure": "mb",
      "unit": "f"
    },
    "charts": {
      "swell": "https://hist-1.msw.ms/wave/750/21-1533772800-1.gif",
      "period": "https://hist-1.msw.ms/wave/750/21-1533772800-2.gif",
      "wind": "https://hist-1.msw.ms/gfs/750/21-1533772800-4.gif",
      "pressure": "https://hist-1.msw.ms/gfs/750/21-1533772800-3.gif",
      "sst": "https://hist-1.msw.ms/sst/750/21-1533772800-10.gif"
    }
  }
]

Converting localTimestamp to a datetime object produced these results:

>>> datetime.utcfromtimestamp(1533751200).strftime("%a %-I %p")
'Wed 6 PM'
>>> datetime.fromtimestamp(1533751200).strftime("%a %-I %p")
'Wed 2 PM'

Converting issueTimestamp to a datetime object produced these results:

>>> datetime.utcfromtimestamp(1533729600).strftime("%a %-I %p")
'Wed 12 PM'
>>> datetime.fromtimestamp(1533729600).strftime("%a %-I %p")
'Wed 8 AM'

Theory

localTimestamp should use datetime.utcfromtimestamp()
issueTimestamp should use datetime.fromTimestamp()
These seem contradictory to the documentation's description.

I came across the same issue with localTimestamp when working with the MSW api directly. In particular, when daylight savings is applicable, the timestamp intervals in localTimestamp (when converted using datetime.fromTimestamp()) returned 01:00, 04:00, 07:00, etc. instead of 00:00, 03:00, 06:00. When I use datetime.utcfromtimestamp() instead, the intervals return as expected i.e. 00:00, 03:00, 06:00, etc. Sounds like your theory is right. Thanks for the pointer!


Modified external field

I modified external fields.

Implemented a new envelope Ecos2 for the ARTED part.
Merged the namelist of linear_response into em_field.

Thank you for your implementation, @shunsuke-sato san. It's fine for me. (I've checked that a result for the GCEED part doesn't change.) @uemoto1 san, could you check this PR and merge?

I'm going to modify an example file for the GCEED part after this PR passes. This is just a comment.

Okey, I confirmed that the group of the impulse amplitude in the inputfile and the preferred CEP value of Ecos2 pulse are changed, and the code still reproduce the results obtained in previous version.


Agent stuck in a loop

The agent is stuck in a loop.
=============

Agent 1 -> System:

writeNote
title: Resources for Ruby on Rails Learning
content:
% ff9d7713-0bb0-40d4-823c-5a66de48761b%
- Ruby on Rails Guides: https://guides.rubyonrails.org/
- Ruby on Rails API: https://api.rubyonrails.org/
- Intermediate Rails: Understanding Models, Views and Controllers: https://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
% ff9d7713-0bb0-40d4-823c-5a66de48761b%

viewNote
title: Resources for Ruby on Rails Learning

=============

System -> Agent 1:

--- ERROR ---

Your action could not be parsed.  Is that what you’re using?

 Is that what you’re using?

Yes I am using the default gpt-3.5-turbo model. Thanks for clarifying. I asked it to remove the ":" from the content part. It took multiple attempts but I think it got out of it. Thanks for clarifying.

It is getting stuck in every step now:


Update pt_BR.ts

Thanks. By the way, you can also contribute translations by using Weblate here: https://hosted.weblate.org/projects/polymc/polymc/


Spatio-temporal demo isn't indexed

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

Go to '...'
Execute '...'
See error

Observed behavior
Describe or paste the exact output that demonstrates the bug (for example, the stack trace if it is an exception).
Expected behavior
A clear and concise description of what you expected to happen.
Environment
Operating system: for example: macOS, Ubuntu
Python version: for example: 3.7.2
Package versions: for example: stellargraph==0.8.3, tensorflow==2.0.0
The following Python code can automatically compute the data for this section (for example: run the code in a Jupyter notebook cell, or, on macOS, copy the code and run pbpaste | python - in a terminal):
import subprocess, platform, sys
pkgs = subprocess.Popen(["pip", "freeze"], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0].decode("utf-8")
print("Operating system: `{}`\nPython version:\n```\n{}\n```\nPackage versions:\n<details>\n\n```\n{}\n```\n\n</details>".format(platform.platform(), sys.version, pkgs))

Additional context
Add any other context about the problem here. For example:
Data used: if this occurs with a specific dataset, which dataset and how to acquire it
Screenshots: if applicable, add some screenshots to explain the behaviour

Folder doesn't appear in read the docs.
Isn't indexed in tables.
High priority - this is a key demo of 1.0


Where to encode URIs for controlaccess terms?

Submitted on Monday, September 30, 2013 - 3:03pm
Submitted values are:
Name: Julie Hardesty
Affiliation: Indiana University
Does this represent an official comment from your affiliated group? Yes

Control Access headings (<corpname>, <subject>, etc) - If we wish to
associate URIs for authorized access points, there appear to be 2 possible
attributes that could contain this value: @id or @identifier – which should
receive this value?

Updated documentation to clarify @id and @identifier. Closing.