KAFKA-5129: Add ACL checks for Transactional APIs [WIP]

Add ACL checks for Transactional APIs

@guozhangwang @hachikuji @apurvam @ijuma - i've done the broker side changes, though only managed to test one of them as the only way to test seems to be via end-to-end tests requiring the client.
So.. trying to implement the changes in the KafkaProducer. I'm not sure how to handle the errors when they are coming back on the Sender thread. For example, when we do a producer.send(..) and it adds a new partition we send the AddPartitionsToTxnRequest, if this fails with Errors.TRANSACTIONAL_ID_AUTHORIZATION_FAILED i  call fatal(errror.exception()) which marks the transaction manager as having an error, but this doesn't stop any subsequent requests in the Sender from being processed. So despite that the AddPartitionsToTxnRequest it still tries to produce to the partition.
How are we supposed to handle this and propagate the errors back to the user? If a request like AddPartitionstoTxnRequest fails should it also error out any related ProduceRequests?
Anyway, i need some help here as i'm going around in circles.

Hi @dguy, I think you have a good point:
If the transactionManager is an error state, we only block a commit from being propagated. I think we should extend this to block any transactional request from being sent. I already improved this logic a bit to block only commits and not aborts  in my integration test brach see here, and we can extend that to block all transactional requests except aborts.
Also, once the transaction manager is in an error state, no further transactional sends will be allowed see this. In that case, the user will get the authorization failed exception from the send future.
So with a little tweak to block all transactional requests except aborts from an error state, we should be pretty solid in handling this on the client side, no?

Regarding the case when the ProducerIdResource authorization fails, in Sender.maybeWaitForPid, it might make sense to check if the exception is fatal and put the transactionManager in an error state and use the existing logic in KafkaProducer to fail all future sends. This would be a consistent and intuitive way to handle it.
@dguy @hachikuji what do you think?

@apurvam Yes, your suggestion is what I was thinking too.

@hachikuji @apurvam @guozhangwang - i think this is pretty close now. Though, there is bound to be stuff i've missed...


Cannot install (with mamba)

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
When installing version 6.52.3 I get this error
Encountered problems while solving:
  - nothing provides exceptiongroup >=1.0.0rc8 needed by hypothesis-6.52.3-pyhd8ed1ab_0

This change apparently then is the culprit.
Is this maybe a problem with mamba? Since obviously the package/recipe build here succeeded without errors?
Installed packages
This is the base env

    Package              Version  Build               Channel                 Size
  ──────────────────────────────────────────────────────────────────────────────────
    Install:
  ──────────────────────────────────────────────────────────────────────────────────

    + bzip2                1.0.8  h0d85af4_4          conda-forge/osx-64     159kB
    + ca-certificates  2022.6.15  h033912b_0          conda-forge/osx-64     153kB
    + libffi               3.4.2  h0d85af4_5          conda-forge/osx-64      51kB
    + libzlib             1.2.12  hfe4f2af_2          conda-forge/osx-64      65kB
    + ncurses                6.3  h96cf925_1          conda-forge/osx-64     937kB
    + openssl              3.0.5  hfe4f2af_0          conda-forge/osx-64       3MB
    + pip                 22.2.1  pyhd8ed1ab_0        conda-forge/noarch       2MB
    + python              3.9.13  hf8d34f4_0_cpython  conda-forge/osx-64      13MB
    + python_abi             3.9  2_cp39              conda-forge/osx-64       4kB
    + readline             8.1.2  h3899abd_0          conda-forge/osx-64     272kB
    + setuptools          63.3.0  py39h6e9494a_0      conda-forge/osx-64       1MB
    + sqlite              3.39.2  hd9f0692_0          conda-forge/osx-64       2MB
    + tk                  8.6.12  h5dbffcc_0          conda-forge/osx-64       4MB
    + tzdata               2022a  h191b570_0          conda-forge/noarch     124kB
    + wheel               0.37.1  pyhd8ed1ab_0        conda-forge/noarch      32kB
    + xz                   5.2.5  haf1e3a3_1          conda-forge/osx-64     233kB
    + zlib                1.2.12  hfe4f2af_2          conda-forge/osx-64      95kB

Environment info
Best I can do for this is https://github.com/pymor/pymor/runs/7618149039?check_suite_focus=true#step:5:2

The error happens in all our macos, linux and windows builders. These all try to install the same packages, and all currently fail with above message.

Does it install with conda?

I've setup a minimal Dockerfile to replicate my problem. That setup also cannot install hypothesis (which conda), but with a different problem

So for some reason mamba does not consider the package with rc2 (latest in conda forge, current is rc8) for exceptiongroup to be installable.  See here via this Dockerfile
pip install exceptiongroup

works however. There seems to be no way to make mamba accept pre-release versions.
Plain conda also fails to install exceptiongroup directly (w/o any version constraint).
Dockerfile and build result
Would it be alright with you @jochym to remove the dependency for exceptiongroup until they have a final, non-RC, release?

Would it be alright with you @jochym to remove the dependency for exceptiongroup until they have a final, non-RC, release?

Just in case I've prepared a PR for that.

Since #733 made it clear to me that exceptiongroup is actually a hard dependency, I guess there's nothing really to be done for anybody who's using mamba, right?
Maybe pre-installing it with pip before using mamba to install hypothesis?


Adding loading state when disconnecting

Changes

feat: Adding loading state when disconnecting

Associated Issues
closes https://github.com/WalletConnect/web3modal/issues/1084

@0xAsimetriq

Removed keyframes
Added size option instead of small/medium
Added fill color with css variable

Could you review again?

@0xAsimetriq  Last commit was not a great fix. Did some extra change, it works correctly now with the correct options etc. Can you check again?


[Privileges 2] Webhook feature intended usecase

I tried the Privileges Beta 2.0.0b1761 on macOS 15.0.1 and I am very exited for the new Version.
behavior
When I played around with the webhook feature I noticed that the requests are dismissed, when there is no connection to the server. The request will not be resend at a later point.
expected behavior
When the next event appears the application resends the requests that where not delivered successfully.
and/or
The application tries to resends the events at a schedule or event (boot/network change).
impact
When the entries are not queued and send at a later point it cannot be used as a seamless remote logging in my view.
If a device is offline I will never knew if a user gained admin rights through that time.
At this point I question what is the intended use/behavior of the webhook?
Or is this a bug?

This is expected behavior. The same applies to the remote syslog functionality.


mpi not supported for class of sparse functions

MFE
import devito

shape = (12,13,14)
nfreq = 5
nrec = 6
space_order = 8

grid = devito.Grid(shape=shape)
freq_dim = devito.DefaultDimension(name="freq_dim", default_value=nfreq)

p0re = devito.Function(name="p0re", grid=grid, dimensions=(*grid.dimensions, freq_dim), shape=(*shape, nfreq), space_order=space_order)

class CoordSlowSparseFunction(devito.SparseFunction):
    _sparse_position = 0

recdim = devito.Dimension(name="recdim")
p0recre = CoordSlowSparseFunction(name="p0recre", grid=grid, dimensions=(recdim, freq_dim), shape=(nrec, nfreq), npoint=nrec)

interp_eq_re = p0recre.interpolate(expr=p0re)

op = devito.Operator([interp_eq_re], name="interpolator")

op.apply()

Results in:

cvx@cbox-lukedecker-test:~/.julia/dev/JetPackDevitoPSD/test$  DEVITO
_MPI=1 mpirun -n 2  python mfe.py
Traceback (most recent call last):
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/ir/stree/algorithms.py", line 189, in preprocess
    assert not queue
AssertionError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/cvx/.julia/dev/JetPackDevitoPSD/test/mfe.py", line 21, in <module>
    op = devito.Operator([interp_eq_re], name="interpolator")
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 158, in __new__
    op = cls._build(expressions, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 180, in _build
    irs, byproduct = cls._lower(expressions, profiler=profiler, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 258, in _lower
    stree = cls._lower_stree(clusters, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/tools/timing.py", line 76, in __call__
    retval = self.func(*args, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 405, in _lower_stree
    stree = stree_build(clusters, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/ir/stree/algorithms.py", line 21, in stree_build
    clusters = preprocess(clusters, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/ir/stree/algorithms.py", line 192, in preprocess
    raise RuntimeError("Unsupported MPI for the given equations")
RuntimeError: Unsupported MPI for the given equations
Traceback (most recent call last):
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/ir/stree/algorithms.py", line 189, in preprocess
    assert not queue
AssertionError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/cvx/.julia/dev/JetPackDevitoPSD/test/mfe.py", line 21, in <module>
    op = devito.Operator([interp_eq_re], name="interpolator")
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 158, in __new__
    op = cls._build(expressions, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 180, in _build
    irs, byproduct = cls._lower(expressions, profiler=profiler, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 258, in _lower
    stree = cls._lower_stree(clusters, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/tools/timing.py", line 76, in __call__
    retval = self.func(*args, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/operator/operator.py", line 405, in _lower_stree
    stree = stree_build(clusters, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/ir/stree/algorithms.py", line 21, in stree_build
    clusters = preprocess(clusters, **kwargs)
  File "/home/cvx/.conda/envs/conda_jl/lib/python3.10/site-packages/devito/ir/stree/algorithms.py", line 192, in preprocess
    raise RuntimeError("Unsupported MPI for the given equations")
RuntimeError: Unsupported MPI for the given equations
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

  Process name: [[59720,1],1]
  Exit code:    1
--------------------------------------------------------------------------

I think this is fixed, closing


Move bro kafka plugin references to apache/metron-bro-plugin-kafka

The kafka bro plugin is now hosted under github.com/apache, and exists as a plugin.

Coverage remained the same at 91.592% when pulling a29f7f109d9775a9c5693824b464179bb4fc8142 on JonZeolla:repoint_kafka_plugin into 4c481cba2b3bd11f8de7392513de767a4fa63a78 on Kitware:master.


Add IBC-related entry points

Add the possibility to generate IBC-related entry points directly with Sylvia. For now, we need to first establish how the handling of those should be handled and what is to be generated.

Hey @hashedone I see the issue is quote old, any plans to implement it so far? or at least allowing it through override_entry_point?

Leaving it here whoever finds it interesting: https://github.com/AlexanderC/cosmwasm-sylvia-counting-contract (IBC enabled Sylvia counting contract)


Update elixir.md

Any burn or buyback is not a creation of value, but a reallocation of the same value from the token to the token holder.

Discussed with adcv and landed on 'delivers' as a preferred alternative. Merged here: https://github.com/makerdao/endgame-docs/commit/e38257cc11b54731068f8609c3d6faa0eba12ef9.


When building my app, I receive the following warning: the modules is strongly discouraged as it poses security risks and may cause issues with minification

Hi
When building my app, I receive the following warning:
<EMAIL_ADDRESS>(8:18542): The use of eval in<EMAIL_ADDRESS>is strongly discouraged as it poses security risks and may cause issues with minification
Vue version : ^3.4.21
vite version: "^5.1.6",

Hi @AmirHo3sein
The warning is from persian-date package. In the package,  eval function is used. This must be fixed in that package.
Thanks for reporting.


I wanted to be cool like Nathan and do fizzbuzz

I think the title says it all.

Looks fantastic! :+1:


Improve landing page link accessibility

Resolves #341
Changed the color of the link text to use one of your brand colors to increase the contrast and improve accessibility.
Also modified the link text slightly (by capitalizing the T, and making it its own sentence)

This is excellent. Question: should we make this the default in the theme, so we don't have to manually do this elsewhere when we use <a>?

I initially went with this, but it also affects the links in the header: DNS Records and Certificates

Ah, makes sense.  This is a great change as is.


Copy command reference into Go files, e.g. list.go

The goal of #84 was to find a way to auto-generate documentation out of the Cobra commands. @obnoxiousnerd found a simple way to do this natively with Cobra. Thanks!
As a next step, the command references from README.md should me copied into the Cobra commands. Each Cobra command has a Long field for long help texts, and the existing documentation should be moved into that field.
Ideally, as a result, generating the documentation from the commands should produce the same output as the current Markdown documentation in README.md.

Hello! I was experimenting with this and Cobra's doc.GenMarkdownTree.  Here are some observations for your consideration:

It seems that where there's both Short and Long, the cli help message will only display the Long version.

The auto generation script works and generates the Markdown documentation we desire. This is a sample cobra-generated timetrace_delete_project.md:

However this requires that the Markdown annotations go directly into the string for the Long field of the Cobra command. This results in the cli output like so, which I'm not sure is desirable, or if there's a way to configure the cli output to show the Short rather than Long:

@jwnpoh Maybe for .Short to appear in the docs, you might need to customize it.

@obnoxiousnerd I'm not sure if the intention is to include both .Short and .Long in the docs. My understanding of this issue is that @dominikbraun was hoping that populating .Long in the code itself can facilitate easier updating of docs when the different functions of the app gets updated.
Please correct me if I'm wrong?


prisma generate --sql does not read env vars in AWS

Bug description
Today we introduced raw SQL queries in our codebase, requiring us to run prisma generate --sql instead of prisma generate. Locally it builds normally. In AWS, it errors out with prisma generate --sql:
#14 25.81 ><EMAIL_ADDRESS>postinstall /app
--
4921 | #14 25.81 > prisma generate --sql
4922 | #14 25.81
4923 | #14 26.62 Prisma schema loaded from prisma/schema.prisma
4924 | #14 26.66 Error: Prisma schema validation - (get-config wasm)
4925 | #14 26.66 Error code: P1012
4926 | #14 26.66 error: Environment variable not found: DATABASE_URL.
4927 | #14 26.66   -->  prisma/schema.prisma:17
4928 | #14 26.66    \|
4929 | #14 26.66 16 \|   // https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference#string
4930 | #14 26.66 17 \|   url      = env("DATABASE_URL")
4931 | #14 26.66    \|
4932 | #14 26.66
4933 | #14 26.66 Validation Error Count: 1
4934 | #14 26.66 [Context: getConfig]

When I omit --sql, it passes that build step but fails on the type checking later on, because we rely on the generated types.
How to reproduce

Expected behavior
No response
Prisma information

generator client {
  provider        = "prisma-client-js"
  binaryTargets   = ["native", "linux-musl-openssl-3.0.x"]
  previewFeatures = ["typedSql"]
}

datasource db {
  // provider = "postgresql"
  provider = "postgresql"
  // NOTE: When using mysql or sqlserver, uncomment the @db.Text annotations in model Account below
  // Further reading:
  // https://next-auth.js.org/adapters/prisma#create-the-prisma-schema
  // https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference#string
  url      = env("DATABASE_URL")
}

generator zod {
  provider = "zod-prisma-types"
}

// Necessary for Next auth
model Account {
  id                String  @id @default(cuid())
  userId            String
  type              String
  provider          String
  providerAccountId String
  refresh_token     String? @db.Text
  access_token      String? @db.Text
  expires_at        Int?
  ext_expires_in    Int?
  token_type        String?
  scope             String?
  id_token          String? @db.Text
  session_state     String?
  user              User    @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@unique([provider, providerAccountId])
}

model Session {
  id           String   @id @default(cuid())
  sessionToken String   @unique
  userId       String
  expires      DateTime
  user         User     @relation(fields: [userId], references: [id], onDelete: Cascade)
}

model User {
  id                  String           @id @default(cuid())
  name                String?
  email               String           @unique
  emailVerified       DateTime?
  image               String?
  accepted            Boolean          @default(false)
  createdAt           DateTime         @default(now())
  updatedAt           DateTime         @updatedAt
  deletedAt           DateTime?
  roles               Role[]           @default([])
  entities            String[]         @default([])
  jobFamilies         String[]         @default([])
  jobClusters         String[]         @default([])
  jobFunctions        String[]         @default([])
  // Relationships
  accounts            Account[]
  sessions            Session[]
}

Environment & setup

OS: Linux
Database: Postgres
Node.js version: V20.16.0

Prisma Version
5.21.1

Hi @filipjnc, where is the DATABASE_URL env variable defined? Is it in a local .env file, exported as a global variable, or something else? Thanks.

This seems like a breaking change that (as far as I can) aren't mentioned anywhere in the TypedSQL docs: namely, you have to be able to open a connection to the database when running --sql?

i want to revisit this issue. running generate --sql from a docker-compose process + env variable defined in the docker-compose file does not work. (aka Environment variable not found: DATABASE_URL.)
running the same thing without the --sql flag works just fine. something weird is happening here

i want to revisit this issue. running generate --sql from a docker-compose process + env variable defined in the docker-compose file does not work. (aka Environment variable not found: DATABASE_URL.) running the same thing without the --sql flag works just fine. something weird is happening here

@giladv its because the Typed SQL feature requires an active database connection
https://www.prisma.io/docs/orm/prisma-client/using-raw-sql/typedsql#active-database-connection-required

Actually active connection to the database is mentioned in the documentation, but probably poorly emphasized.
Realistically I currently see two options for people using Docker:

Have in DockerFile ENV DATABASE_URL= and provide access to the database
Copy from host the content of  node_modules/.prisma/client/sql after generating the types (I haven't tried this).

Both strongly inconvenient. So what are the recommendations in building a Dockerfile with this option enabled? Because I must admit I like it a lot.


I found that when running UDPST, there were significant differences in the speed test results several times. May I know what went wrong?

I found that when running UDPST, there were significant differences in the speed test results several times. May I know what went wrong?

Well, if I had to guess based on the output, I'd say it was a byproduct of the loss pattern (that was keeping the B algorithm from ramping up). In the first test there was low-level loss after the first interval but apparently not bursty enough to indicate significant congestion (which is inferred based on loss). In the second test, although there is no loss for the first four intervals, after that it must have occurred significantly enough that the algorithm had to back off and stay around that rate (see the 99+ delivered % for intervals 6-10).

I understand the meaning of your first paragraph because there was a significant loss during the second process, hence the speed did not improve. However, I'm not entirely clear on the meaning of your second paragraph. Do you need any more information from me？
Most importantly, I wish to obtain network speed results using this tool. How should I calculate it, should I take an average of multiple tests? Even though I've only posted two test results, in reality, there were several tests, and the differences were similar to these two. I feel that averaging might not be suitable due to substantial variations each time.
Additionally, I would like to ask if it's possible to extend the duration of each test

You can extend the test by using the "-t " option at the client.
The B algorithm ramps up until it infers congestion and then it backs off and will only ramp up slowly after that. The C algorithm will retry a fast ramp up multiple times, even after it infers congestion. So, if your loss type/pattern is causing test variability, it may be worth trying algorithm C via "-A C".
In general, unless your network is experiencing connectivity or reliability issues, you should expect fairly consistent results. However, if you are encountering loss that is causing it to appear as if congestion is starting prematurely you'll need to adjust settings to account for that. As I mentioned, try algorithm C - but you can also try increasing "-c" and/or "-q". You can also start the speed search at a higher rate via "-I @". For example, to start the speed search at 1G use "-I @1000" (note, that number is the index and not the speed - see "-s" output).

Thank you very much for your response. I will try the suggestions you provided later. Additionally, I have another question: should I consider the "upstream max Mbps" in the output as the final speed test result, or should I use the Mbps from "Upstream Summary Delivered"? If the preference is for the "max" value, why choose the maximum, as there may already be significant loss when reaching the maximum?

You should use the values in the "Maximum" line, not the "Summary". The summary includes all the lower values while ramping up and does not normally represent anything close to a max. If you want an average, you should average the "Maximums" recorded. Also, it is understood that with any approach to measure a maximum rate - there will be loss. With TCP-based tests you don't see this, but it's still there. The key with a good search algorithm is that it keeps loss to a minimum, just using it as indicator that the maximum is truly reached.


[Improvement] Less jarring, more convenient updating mechanism

Insomnia Version: 5.8.3 (<IP_ADDRESS>8)
Operating System: OSX, Ubuntu

Details
I know I'm being an entitled, whiny baby here.  The update system is more than adequate.  However, wouldn't it be nice if full restarts of the client were only necessary when electron version updates occurred?
Take Slack for example.  It uses electron for its native desktop client.  However, the client only restarts when an update to electron needs to be pushed out.  If there's an update to their js/html/css code, it can usually be pushed out without a hard restart.  The view in the client just reloads.
Perhaps this is something that can be investigated for Insomnia?

I should also note that although it would require a restart of the client, https://github.com/getinsomnia/insomnia/issues/182 is probably the preferred method of update for Ubuntu.

I'm not quite sure I see the benefit here. In Slack's case, does it not still need to re-initialize the UI when the update happens (like a browser refresh)? Is that really much better than restarting the app?
I'm not exactly sure how Slack is architected, but I would guess bet that it's simply loading the main application in a webview for every team, with some extra Electron logic for handling sessions for team switching. This would allow them to use the same auto-update system as the in-browser version.
Don't get me wrong, I do like the idea of this, but I think it would be a lot more work than it seems. Not to mention the ongoing maintenance cost it would introduce.

I don't think there's much benefit to this to be honest. If there are any bugs with the implementation of the update the first thing a user might try is restarting the app anyway.

Going to close this one for now


[BUG] Client calculates MAC differently than server

Library name and version
Azure.Storage.Blob 12.11.0
Describe the bug
On the server side, customer metadata will be trimmed before the message signature is created. On the client side, the message signature is created as supplied by the developer.
Running the code returns the following HTTP error 403 (Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.) with a description of The MAC signature found in the HTTP request '<base64>' is not the same as any computed signature. Server used following string to sign: 'PUT ...
Expected behavior
If the server side is going to manipulate string such as trimming for white spaces, the client library should do this as well.
Actual behavior
MAC mismatch as long the developer is not trimming the supplied string by himself.
Reproduction Steps
var metadata = new Dictionary<string, string>
{
    { "sender"<EMAIL_ADDRESS>" },
    { "subject", " Lorem Ipsum" },
    { "date", "2022-05-02" }
}

var escapedFileName = Uri.EscapeDataString(fileName);
await blockBlobClient.UploadAsync(
    stream,
    new BlobHttpHeaders
    {
        ContentType = "application/pdf",
        ContentDisposition = $"form-data; name=\"file\"; filename=\"{escapedFileName}\""
    },
    (IDictionary<string, string>)metadata,
    cancellationToken: cancellationToken);

Environment

Happens on .NET 6.0 on Windows, Mac or Linux (as Ubuntu Docker container).
At runtime on Kubernetes as well as on the developer machines with Visual Studio 2022, Rider or CLI

@dannyyy
Thanks for the feedback! We are currently investigating and will update you shortly.

Hello @dannyyy We are routing this to the service team's attention!


CSS of the cards

Describe the feature
I think we can change the css and the animations of the cards.

Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@arghadipmanna101 Can you assign me this issue under the GSOC'24 label?

@arghadipmanna101 I worked on 2 issues in this project and contributed 2 PRs. One was the footer one (UI/UX of Footer #805) and the other was the card one (CSS of the card #806). But the leaderboard of GirlScript Summer of Code doesn't contain my name.

@arghadipmanna101 Pls respond


Rename position to positions in object style API. Optional string array here makes more sense. We'll add number array support once px support is added. Will do it as a follow up to this PR.

TODOs: transition hint syntax support linear-gradient(red, 50%, green) (Done locally, dependent on this PR). px support.

Changelog:
[GENERAL] [FIXED] - Linear gradient color stop spec.

Test Plan:

Added testcases in processBackgroundImage-test.js

Going to mostly trust this based off of the unit tests. Function notation parsing is one of the first things on my list, once I get started back on that again.
I suspect when I turned on “ReactNativeFeatureFlags.enableBackgroundStyleApplicator, I broke gradients on Android, since the new path is on the composite drawbable. I haven’t looked around at fixing that up yet. I think it might look like “BackgroundStyleApplicator.setBackgroundImage()”.

Function notation parsing

yeah i agree to move everything to cpp parser eventually. I built a tiny parser in JS for this syntax instead of using regex. But this is working fine for now.

ReactNativeFeatureFlags.enableBackgroundStyleApplicator. haven’t looked around at fixing that up yet

no worries, will take a look and do a PR by this weekend if you didn't get a chance.


RAM usage of connected ISO streams is higher than necessary for some vendors

The data structure cis_pool contains a number of connected ISO stream LLL structs of type struct lll_conn_iso_stream, This type contains variables of the type struct lll_conn_iso_stream_rxtx. This type again embeds a struct ccm instance, if encryption is enabled.
The need for the ccm data member comes from the nRF radio HAL, which needs this per stream, however, other vendor implementations may have a different LLL data model, and not need this variable.
To save hundreds of bytes of RAM for certain vendors, move this data member ccm and the ULL code initializing it to HAL, and/or add necessary configuration flags.
It is possible to only do Kconfig compile time configuration of the current code, but it is not a very nice solution as it requires use of a very specific new Kconfig, or using an SOC config.
Additionally, some more bytes may be saved by the following reordering of fields:
struct lll_conn_iso_stream {
	uint16_t acl_handle;        /* ACL connection handle (for encryption,
				     * channel map, crc init)
				     */
	uint16_t handle;            /* CIS handle */

	/* Connection parameters */
	uint8_t  access_addr[4];    /* Access address */
	uint32_t offset;            /* Offset of CIS from start of CIG in us */
	uint32_t sub_interval;      /* Interval between subevents in us */
	struct lll_conn_iso_stream_rxtx rx; /* RX parameters */
	struct lll_conn_iso_stream_rxtx tx; /* TX parameters */

	/* Event and payload counters */
	uint64_t event_count:39;    /* cisEventCount */

	/* Acknowledgment and flow control */
	uint8_t sn:1;               /* Sequence number */
	uint8_t nesn:1;             /* Next expected sequence number */
	uint8_t cie:1;              /* Close isochronous event */
	uint8_t npi:1;              /* 1 if CIS LLL has Tx-ed Null PDU Indicator */
	uint8_t flush:2;            /* See states LLL_CIS_FLUSH_XXX */
	uint8_t active:1;           /* 1 if CIS LLL is active */
	uint8_t datapath_ready_rx:1;/* 1 if datapath for RX is ready */
	uint8_t nse:5;              /* Number of subevents */
	uint8_t next_subevent:5;    /* Next subevent to schedule */

#if !defined(CONFIG_BT_CTLR_JIT_SCHEDULING)
	/* Lazy at CIS active. Number of previously skipped CIG events that is
	 * determined when CIS is made active and subtracted from total CIG
	 * events that where skipped when this CIS gets to use radio for the
	 * first time.
	 */
	uint16_t lazy_active;
#endif /* !CONFIG_BT_CTLR_JIT_SCHEDULING */

	/* Transmission queue */
	MEMQ_DECLARE(tx);
	memq_link_t link_tx;
	memq_link_t *link_tx_free;
};

Moved to as bug, issue wrt optimal portability across vendors and IC variants.


Error with --distortion-group-merge average

Hi, I'm running this command:
singularity exec -e docker://pennbbl/qsiprep:0.13.0RC1 /usr/local/miniconda/bin/qsiprep --fs-license-file license.txt --output-resolution 1.2 --output-space T1w --denoise-method dwidenoise --unringing-method mrdegibbs --hmc-transform Affine --nthreads 8 --work-dir qsipworkdir bids output participant --distortion-group-merge average
and I am having this error:
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 129, in validate
    value = Path(value)  # Use pathlib's validation
  File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 994, in __new__
    self = cls._from_parts(args, init=False)
  File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 649, in _from_parts
    drv, root, parts = self._parse_args(args)
  File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 633, in _parse_args
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not list

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 67, in run_node
    result["result"] = node.run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 486, in run
    self._get_hashval()
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 538, in _get_hashval
    self._get_inputs()
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 609, in _get_inputs
    self.set_input(key, deepcopy(output_value))
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 302, in set_input
    setattr(self.inputs, parameter, deepcopy(val))
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 330, in validate
    value = super(File, self).validate(objekt, name, value, return_pathlike=True)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 131, in validate
    self.error(objekt, name, str(value))
  File "/usr/local/miniconda/lib/python3.7/site-packages/traits/trait_handlers.py", line 172, in error
    value )
traits.trait_errors.TraitError: The 'dwi_file' trait of a TensorReconstructionInputSpec instance must be a pathlike object or string representing an existing file, but a value of "['/path/to/qsipworkdir/qsiprep_wf/single_subject_HCD0001305_wf/dwi_finalize_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform0/vol0000_trans.nii.gz', ..., '/path/to/qsipworkdir/qsiprep_wf/single_subject_HCD0001305_wf/dwi_finalize_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform197/vol0197_trans.nii.gz']" <class 'str'> was specified.

Error setting node input:
Node: tensor_fit
input: dwi_file
results_file: /path/to/qsipworkdir/qsiprep_wf/single_subject_HCD0001305_wf/dwi_finalize_wf/transform_dwis_t1/dwi_transform/result_dwi_transform.pklz
value: ['/path/to/qsipworkdir/qsiprep_wf/single_subject_HCD0001305_wf/dwi_finalize_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform0/vol0000_trans.nii.gz', ..., '/path/to/qsipworkdir/qsiprep_wf/single_subject_HCD0001305_wf/dwi_finalize_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform197/vol0197_trans.nii.gz']

(vol are going from vol0000 to vol0197). I'm trying to merge 2 dwis. Do you have any hints? Thank you!

Hi @giulia-berto,
Thanks for reporting. Could you please send a list of an example subject's BIDS directory?

Are you sure run 1 and run 2 have different PhaseEncodingDirections? If not, then this bug appears to be affecting the interactive reports. Are there any output images written?

run-1 has PhaseEncodingDirection j- and run-2 has PhaseEncodingDirection j. In the reportles folder, there are the two following html summary:

Summary
Phase-encoding (PE) direction: Anterior-Posterior
Susceptibility distortion correction: TOPUP
Coregistration Transform: Rigid
Denoising Method: dwidenoise
Denoising Window: auto
HMC Transform: Affine
HMC Model: eddy
DWI series resampled to spaces: T1w
Confounds collected:
Impute slice threshold: 0.0
Note on orientation: qform matrix overwritten
/bids/sub-HCD0001305/dwi/sub-HCD0001305_run-2_dwi.nii.gz:
The qform has been copied from sform.
Note on orientation: qform matrix overwritten
/bids/sub-HCD0001305/dwi/sub-HCD0001305_run-1_dwi.nii.gz:
The qform has been copied from sform.

and

A total of 2 distortion groups were included in the data data. Distortion group '0 1 0 0.095910' was represented by images 0, 2, 4 from sub-HCD0001305_run-2_dwi.nii.gz. Distortion group '0 -1 0 0.095910' was represented by images 3, 4, 5 from sub-HCD0001305_run-1_dwi.nii.gz.

and the attached list of images.

Thank you for looking into this!

were there any _dwi.nii.gz files in the output directory?

yes these

It seems that nipype gets stuck for some reason.

ok, this is actually good news! The preprocessing pipeline finished and these images are usable as inputs for reconstruction workflows, but there was an error creating some reports figures that are just used for conveniently viewing your data. You should see that the desc-preproc_dwi.nii.gz has the same number of volumes as one of your input scans and the images should look very clean. I will take a look at the reports bug

I'm having what appears to be the same issue running the following command (on an LSF cluster):
/home/jtduda/.local/bin/qsiprep-singularity --image  /project/ftdc_hcp/fw_bids_phase1/info/qsiprep-0.12.2.sif /project/ftdc_hcp/fw_bids_phase1/subjects/ /project/ftdc_hcp/fw_bids_phase1/processed participant --participant_label 800002 -w /project/ftdc_hcp/fw_bids_phase1/work --output-resolution 0.8 --output-space T1w --fs-license /project/ftdc_hcp/fw_bids_phase1/info/license.txt --distortion-group-merge average --combine-all-dwi --recon-spec dsi_studio_gqi
The processing appears to finish, but none of the reports are generated. Also, the job just hangs indefinitely and has to be manually killed. I've included the error log below, but as you'll see, it's very similar to the one above.
[WARNING] This document format requires a nonempty  element.
Please specify either 'title' or 'pagetitle' in the metadata.
Falling back to 'CITATION'
file none does not exist .
file none does not exist .
file none does not exist .
exception calling callback for <Future at 0x2b597f1ebe48 state=finished raised FileNotFoundError>
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 129, in validate
value = Path(value)  # Use pathlib's validation
File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 994, in new
self = cls._from_parts(args, init=False)
File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 649, in _from_parts
drv, root, parts = self._parse_args(args)
File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 633, in _parse_args
a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not list
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 67, in run_node
result["result"] = node.run(updatehash=updatehash)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 486, in run
self._get_hashval()
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 538, in _get_hashval
self._get_inputs()
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 609, in _get_inputs
self.set_input(key, deepcopy(output_value))
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 302, in set_input
setattr(self.inputs, parameter, deepcopy(val))
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 330, in validate
value = super(File, self).validate(objekt, name, value, return_pathlike=True)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 131, in validate
self.error(objekt, name, str(value))
File "/usr/local/miniconda/lib/python3.7/site-packages/traits/trait_handlers.py", line 172, in error
value )
traits.trait_errors.TraitError: The 'dwi_file' trait of a TensorReconstructionInputSpec instance must be a pathlike object or string representing an existing file, but a value of "['/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform0/vol0000_trans.nii.gz',
..
'/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform397/vol0397_trans.nii.gz']" <class 'str'> was specified.
Error setting node input:
Node: tensor_fit
input: dwi_file
results_file: /sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/result_dwi_transform.pklz
value: ['/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform0/vol0000_trans.nii.gz',
..
'/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform397/vol0397_trans.nii.gz']
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 232, in process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 70, in run_node
result["result"] = node.result
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 217, in result
op.join(self.output_dir(), "result%s.pklz" % self.name)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/utils.py", line 291, in load_resultfile
raise FileNotFoundError(results_file)
FileNotFoundError: /sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/interactive_report_wf/tensor_fit/result_tensor_fit.pklz
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
callback(self)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
result = args.result()
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
return self.__get_result()
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
raise self._exception
FileNotFoundError: /sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/interactive_report_wf/tensor_fit/result_tensor_fit.pklz
file none does not exist .
file none does not exist .
Traceback (most recent call last):
File "/home/jtduda/.local/bin/qsiprep-singularity", line 8, in
sys.exit(main())
File "/home/jtduda/.local/lib/python3.6/site-packages/qsiprep_singularity.py", line 420, in main
ret = subprocess.run(command)
File "/appl/python-3.6.1/lib/python3.6/subprocess.py", line 405, in run
stdout, stderr = process.communicate(input, timeout=timeout)
File "/appl/python-3.6.1/lib/python3.6/subprocess.py", line 828, in communicate
self.wait()
File "/appl/python-3.6.1/lib/python3.6/subprocess.py", line 1439, in wait
(pid, sts) = self._try_wait(0)
File "/appl/python-3.6.1/lib/python3.6/subprocess.py", line 1386, in _try_wait
(pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt
Process ForkServerProcess-7:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-15:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-64:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-59:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-70:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-38:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-13:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-60:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-31:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-94:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-56:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-37:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-91:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-26:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-86:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-73:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-42:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-71:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-93:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-48:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-10:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-22:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-20:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-6:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-75:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-66:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-19:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-12:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-21:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-47:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-5:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-39:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-87:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-54:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-76:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-30:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-52:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-72:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-14:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-9:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-25:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-8:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
Process ForkServerProcess-32:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 226, in _process_worker
call_item = call_queue.get(block=True)
File "/usr/local/miniconda/lib/python3.7/multiprocessing/queues.py", line 93, in get
with self._rlock:
File "/usr/local/miniconda/lib/python3.7/multiprocessing/synchronize.py", line 95, in enter
return self._semlock.enter()
KeyboardInterrupt
/usr/local/miniconda/lib/python3.7/multiprocessing/semaphore_tracker.py:144: UserWarning: semaphore_tracker: There appear to be 5 leaked semaphores to clean up at shutdown
len(cache))

@jeffduda could you try using the image for 0.13.0RC1? There are a bunch of updates to the html reports in there and should get you to at least the same error state as @giulia-berto

@mattcieslak I updated to 0.13.0RC1 and I'm getting the following in stderr. Job appears to be hanging. Processing appears to have finished, but no report generated.
<< output from stderr >>
[WARNING] This document format requires a nonempty  element.
Please specify either 'title' or 'pagetitle' in the metadata.
Falling back to 'CITATION'
file none does not exist .
file none does not exist .
file none does not exist .
exception calling callback for <Future at 0x2b2ea492f208 state=finished raised FileNotFoundError>
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 129, in validate
value = Path(value)  # Use pathlib's validation
File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 994, in new
self = cls._from_parts(args, init=False)
File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 649, in _from_parts
drv, root, parts = self._parse_args(args)
File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 633, in _parse_args
a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not list
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 67, in run_node
result["result"] = node.run(updatehash=updatehash)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 486, in run
self._get_hashval()
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 538, in _get_hashval
self._get_inputs()
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 609, in _get_inputs
self.set_input(key, deepcopy(output_value))
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 302, in set_input
setattr(self.inputs, parameter, deepcopy(val))
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 330, in validate
value = super(File, self).validate(objekt, name, value, return_pathlike=True)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/traits_extension.py", line 131, in validate
self.error(objekt, name, str(value))
File "/usr/local/miniconda/lib/python3.7/site-packages/traits/trait_handlers.py", line 172, in error
value )
traits.trait_errors.TraitError: The 'dwi_file' trait of a TensorReconstructionInputSpec instance must be a pathlike object or string representing an existing file, but a value of "['/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform0/vol0000_trans.nii.gz', ... '/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform397/vol0397_trans.nii.gz']" <class 'str'> was specified.
Error setting node input:
Node: tensor_fit
input: dwi_file
results_file: /sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/result_dwi_transform.pklz
value: ['/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform0/vol0000_trans.nii.gz', ... '/sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/transform_dwis_t1/dwi_transform/mapflow/_dwi_transform397/vol0397_trans.nii.gz']
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/process.py", line 232, in process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 70, in run_node
result["result"] = node.result
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 217, in result
op.join(self.output_dir(), "result%s.pklz" % self.name)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/utils.py", line 291, in load_resultfile
raise FileNotFoundError(results_file)
FileNotFoundError: /sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/interactive_report_wf/tensor_fit/result_tensor_fit.pklz
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
callback(self)
File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
result = args.result()
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
return self.__get_result()
File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
raise self._exception
FileNotFoundError: /sngl/scratch/qsiprep_wf/single_subject_800002_wf/dwi_finalize_ses_MR2_wf/interactive_report_wf/tensor_fit/result_tensor_fit.pklz
file none does not exist .
file none does not exist .

Thanks for testing @jeffduda, looks like you've arrived at the same error as @giulia-berto. I'll make sure this is fixed in 0.13.0RC2, should be ready soon. In the meantime your data and reports should be usable, just lacking one of the extended reports


Submission of new plugins and storing results in database

in-progress by @kvfairchild and me

I'm going to close this PR for now to avoid triggering travis all the time

completed in different PR


Emotes; Pinephone Pro ; Mobian

Checklist

[X] I'm reporting a problem with Chatterino
[X] I've verified that I'm running the most recent nightly build or stable release
[X] I've looked for my problem on the wiki
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue
Hallo there,
I am trying to run Chatterino 2.3.5 (commit 81a6276) on my Pinephone Pro with Mobian.
(earlier versions had the same behavior)

I can install it via Flatpak / Flathub, log in, join channels, chat, and so on.
But as soon as I click on the Emote Icon on the text field a new tab opens.

I can select the Emotes, select one, and change back to the tab with the chat.
There I can see the Text of the Emote in the Text field. (e.g. catJAM)
At this point I can't send the Emote.
It looks like the emote tab is still active because even I am back on the chat tab and can't
see the Emotes anymore I can add new ones by randomly touching the screen.
At the chat tab is no cursor in the text field, no possibility to delete or add anything.
The same behavior happens if I add a new channel, or make changes in the settings.

Only way I know to get my cursor back working is to completely restart chatterino.
As my own workaround I try to do things with auto complete and just don't use the Emote Icon
and / or don't make any changes in settings or restart after adding a channel and so on.

On the other hand it would be a huge simplification if things would work the way they supposed to. :)
That's why I am reaching out to you guys, hoping that someone knows how to debug this and
make my mobile Linux experience the same awesome way like my Desktop experience. ;)
Thanks in advance. :)
Screenshots
No response
OS and Chatterino Version
Chatterino 2.3.5 (commit 81a6276) and earlier versions / Mobian / Pinephone Pro

sorry for the wrong label, and thx for relabeling it. ;)


Invalid JSON for check run / results gist - build failure?

I'm seeing some strange behaviour with my test process. It runs my tests successfully and seems to generate an output, but then tries and fails to add a check run, citing invalid JSON:
Invoke-WebRequest: /home/runner/work/_actions/zyborg/dotnet-tests-report/v1.3.0/action.ps1:144
Line |
 144 |      Invoke-WebRequest -Headers $hdr $url -Method Post -Body ($bdy | C …
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | {"message":"Problems parsing
     | JSON","documentation_url":"https://docs.github.com/rest/reference/checks#create-a-check-run"}

It also fails to create a results gist, with the same error at line 235.
I did notice it failed to build the solution, but since the tests ran successfully I'm not sure if this is related:
 Results File: /home/runner/work/geodesy-csharp/geodesy-csharp/_TMP/test-results.trx

Test Run Failed.
Total tests: 81
     Passed: 75
     Failed: 6
 Total time: 1.6010 Seconds
     3>Done Building Project "/home/runner/work/geodesy-csharp/geodesy-csharp/geodesy-test/geodesy-test.csproj" (VSTest target(s)) -- FAILED.
     1>Done Building Project "/home/runner/work/geodesy-csharp/geodesy-csharp/geodesy-csharp.sln" (VSTest target(s)) -- FAILED.

Build FAILED.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:05.25
Warning: Execution of tests returned failure: 1

Can you try to disable the Check Run reports by enabling the skip_check_run flag, and then enabling Gist-based reports using the gist_name and gist_token inputs and see if you still get this error?

I get a similar error when it tries to create the gist:

This isn't accessible on a public GitHub project by any chance, is it?

I'm afraid not but I might be able to help you out with bits of logs or any other info. Also happy to try any changes you might suggest - I did fork the repo but then had other work to do so never bothered investigating further.

If you reduce the number of tests, does it also fix the call to create the Gist?

Yeah both work if I reduce the number of tests
On Tue, 6 Apr 2021, 18:43 Eugene Bekker, @.***> wrote:

If you reduce the number of tests, does it also fix the call to create the
Gist?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zyborg/dotnet-tests-report/issues/13#issuecomment-814308573,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAORN47GQRHU2FHSXE5ILT3THNB3ZANCNFSM4XI5B63A
.

I was looking at the documentation for some indication of a limit on the payload for creating Gists, but it doesn't mention anything, I'll need to play around with it and see if I can nail it down.
In the mean time, could you possibly work around the issue by breaking your batch of 2000+ tests into several smaller batches?  If you are categorizing, perhaps run each category as a separate batch with separate result reports?


Coder

Nice work makes working better.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 14ab965b-dc45-f450-1302-5ffe491ca129
Version Independent ID: 0d96d50d-a349-3408-3b93-d8b084e1cbd1
Content: How to get an Azure AD tenant
Content Source: articles/active-directory/develop/active-directory-howto-tenant.md
Service: active-directory
GitHub Login: @CelesteDG
Microsoft Alias: celested

@Vekoding - Thank you for your feedback.

Please close. Not an issue. Thank you.


Deno Module Page Showing "No uploaded versions" Error

I uploaded my Deno Minifier module to the deno.land's third party modules and after going through all of the designated steps, I went to the page at https://deno.land/x/minifier and the website is showing this

I don't really understand why this is happening, as I have two versions uploaded on the github repo releases.  Can someone please help me resolve this error.

@CodingCarter We made a big refactor to how the deno.land/x website works to increase stability. Unfortunately that has caused a bit of instability like you're experiencing as we move over to the new system. Read about it here https://deno.land/posts/registry2
TLDR: go to https://deno.land/x#add and put in "minifier" click next even tho it's grayed out.

@CodingCarter I see you have gone through all of the steps to add it. It is showing up for me. I think it is just caching some old data on your side. Could you hard refresh to wipe the cache? (Ctrl-Shift-R) on Chrome.

@CodingCarter I see you have gone through all of the steps to add it. It is showing up for me. I think it is just caching some old data on your side. Could you hard refresh to wipe the cache? (Ctrl-Shift-R on Chrome)

Thank you very much, this fixed my issue 👍


Any way to turn on search dropdown for cyrillic search requests?

Cyrillic search doesnt cause search result dropdown, thus I cannot choose and open search results. Any way to fix that?

Searching is performed here. You can see if you can do any processing to the index and the query string in Javascript. Or whether changing the elasticsearch settings helps.

Cool! I will try! Can I somehow setup debug/test environment on localhost or whatever not to commit-push forked zola sources and redeploy my netlify website each time I changed a piece of code?

You can reference the build steps in netlify.toml and do it locally, just use zola serve to view the results instead.

I will close the issue for now, hope it went smoothly 😺

Thank you for your great help! Had a several difficulties to run it on Windows, mostly solved. Thank you!


[GHSA-33j4-8vcr-f79v] Cross-site request forgery (CSRF) vulnerability in...

Updates

Affected products
References
Source code location
Summary

Comments
Add some informations about CVE-2010-1244

Hey, similar to https://github.com/github/advisory-database/pull/3086 do you know the affected artifact(s) for this advisory?

This also affected org.apache.activemq:activemq-parent


template(cloudflare): Update remix cloudflare template to latest package versions

Rationale
The template remix-run/remix/templates/cloudflare has fallen major versions behind some packages. Moreover, it is quite far behind in terms of wrangler which has gone through a large amount of updates recently.
This PR aims to bring the package versions up to the their respective latest versions
Edit: As per review request, only Cloudflare related packages have been bumped.
@cloudflare/workers-types         ^4.20230518.0  →  ^4.20240404.0
miniflare                         ^3.20231030.4  →  ^3.20240404.0
wrangler                                ^3.24.0  →        ^3.47.1

How has this been tested
Local testing by creating a brand new remix app using npx create-remix@latest --template ~/personal/forks/remix/templates/cloudflare (pointed at the local versions with changes)
Once the local test app has been made, I ran the following checks

Build the app locally and confirm it can be run using wrangler (using npm start)
Run lint to confirm that the major updates for eslint cause no breaking changes
Run npm run typecheck to ensure tsc works fine
Deploy the built version of the app to Cloudflare and ensure that process works fine. The deployed app can be found at this URL.

I would prefer to just update the cloudflare related packages in this PR.  The other things like react types and eslint deps are applicable to all templates, so I'd rather see a separate PR that bumps common deps across all templates

I would prefer to just update the cloudflare related packages in this PR. The other things like react types and eslint deps are applicable to all templates, so I'd rather see a separate PR that bumps common deps across all templates

Gotcha. I'll make a seperate PR for the other deps.

Okay, myBinding Resources in Production section may be outdated/unnecessary based on the latest wrangler.toml support released during dev week. I'll look into the changes as soon as I can and update the docs accordingly with new best practices


Outdated Scylla causing a test to fail in the CI

While rebasing #180 I've noticed a failing test in the Scylla CI and I've isolated this minimal failing test:
defmodule SimpleQueryTest do
  use XandraTest.IntegrationCase, async: true

  test "simple query is correctly executed", %{conn: conn} do
    statement = "CREATE TABLE users (first_name text, last_name text PRIMARY KEY)"
    Xandra.execute!(conn, statement)

    statement = "INSERT INTO users (first_name, last_name) VALUES (:first_name, :last_name)"

    {:ok, %Xandra.Void{}} =
      Xandra.execute(conn, statement, %{
        "first_name" => {"text", "Chandler"},
        "last_name" => {"text", "Bing"}
      })
  end
end

The example statement is taken from the docs so I assume it's expected to work, but it actually fails with
{:error, %Xandra.Error{message: "Invalid amount of bind variables", reason: :invalid}}

when executed against the Scylla Docker compose (while it succeeds with Cassandra).
I tried bumping Scylla version to the most recent one (4.5.3) here and the test actually passes (together with the whole Scylla testsuite), so I started bisecting and it seems that this is a Scylla bug specific to the 2.3.0 version, because bumping to 2.3.1 seems to work fix that too.
Considering Scylla 2.3.0 is a little old (it was released in September 2018), should the CI start using a more recent version?

@rbino for now, can you make a PR that 1. adds that test (as a regression) and 2. bumps Scylla to 2.3.1? I want to move slowly so bumping to the oldest version that works makes sense. After that, sure we can add some very recent Scylla versions (4.x) to the CI matrix. Thank you in advance!

@whatyouhide done in #214


Size Mapping not working

The sizeMappingName and sizeMappings don't appear to be working.
I've created a minimalistic example based on the demo linked in the documentation here: https://codesandbox.io/s/gpt-prebid-npm-es6-forked-kvnccc?file=/src/config.js:19-31
I hope I've misunderstood how to use this, in which case can someone point me in the right direction.

This might be working if the sizes property is present, but I interpretted sizes & sizeMappingName to be mutually exclusive.


Create applications view (dashboard)

US1 for GUI

[x] Create request from database (handle version, applicationName and the 4 status)
[x] Get tasks only from the last 7 days
[ ] Add tooltip (title) on tasks to view more details
[ ] Create fatories to generate fake data
[ ] Create tabs from applications
[ ] Create view with data

https://github.com/aneoconsulting/ArmoniK.Admin.GUI/pull/57


Make sure to compile using JDK 1.8

If you don't then you get the following error message
[error] (sourceDistGenerate) java.lang.UnsupportedClassVersionError: com/github/pjfanning/sourcedist/ignorelist/FnMatch has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

This is because pekko root only works with JDK 1.8

hopefully solved by https://github.com/pjfanning/sbt-source-dist/commit/47d5af4813da433bb9adb99e97ab748b4841f5c1


Fix Windows build and failing tests

Following commit c6b4b6d, building on
Windows gives the following error in Python.sln/libpython-shared.vcxproj:
1>C:\dev\p\build\python-prefix\src\python\Modules\timemodule.c(1062): error C2491: '_PyTime_FloatTime' : definition of dllimport function not allowed

Defining Py_BUILD_CORE for just timemodule.c fixes the compile error,
but then the following linker error occurs:
1>LINK : fatal error LNK1104: cannot open file 'python27.lib'

This commit fixes the build by ensuring that Py_BUILD_CORE is defined
for all files in libpython-shared.vcxproj.
Additionally, Some of Python's standard regression tests are failing on Windows. For example:
$ ./bin/python -m test.regrtest -v test_codecs
[...]
======================================================================
ERROR: test_bad_decode_args (test.test_codecs.BasicUnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\dev\p\build\INSTALL\Lib\test\test_codecs.py", line 1693, in test_bad_decode_args
    decoder = codecs.getdecoder(encoding)
  File "c:\dev\p\build\INSTALL\Lib\codecs.py", line 949, in getdecoder
    return lookup(encoding).decode
LookupError: unknown encoding: big5

The root cause is that some modules can't be loaded:
>>> import _codecs_tw
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (init_codecs_tw)

In the standard Windows Python build a number of modules are builtin. sys.builtin_module_names lists the builtin modules. This commit explicitly marks those modules as builtin on Windows.

This PR is superseded by #85


Add Aux for hlists.SelectAll

Useful for the same reason records.SelectAll.Aux is useful.

Codecov Report

Merging #703 into master will decrease coverage by 21.93%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master     #703       +/-   ##
===========================================
- Coverage   83.58%   61.65%   -21.94%
===========================================
  Files          66       94       +28
  Lines        2608     3536      +928
  Branches       90      112       +22
===========================================
  Hits         2180     2180
- Misses        428     1356      +928

Impacted Files
Coverage Δ

core/src/main/scala/shapeless/ops/hlists.scala
93.26% <ø> (ø)
:arrow_up:

core/src/main/scala/shapeless/tuples.scala
0% <0%> (-100%)
:arrow_down:

...re/src/main/scala/shapeless/hlistconstraints.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/alacarte.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/default.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/orphans.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/cached.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/fin.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/unions.scala
0% <0%> (-100%)
:arrow_down:

core/src/main/scala/shapeless/conversions.scala
0% <0%> (-100%)
:arrow_down:

... and 47 more

Continue to review full report at Codecov.

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

That's odd. I added 1 line for Aux and a corresponding test for it, but now all these other places I hadn't touched are missing test coverage...any ideas?

The coverage drop looks like a glitch ... not your problem.
I'm a bit puzzled by this PR though ... the Out type of SelectAll[C, P] should be definitionally equal to P, so the align should be unnecessary, and more generally, I'm not completely convinced that the Aux is needed at all. Can you show me an example where this is indeed needed?

the Out type of SelectAll[C, P] should be definitionally equal to P

Ah, you are correct, type Out = S is in the definition of hlist.SelectAll. I was trying to write a structural upcast (like in the test case), and thought it might be necessary to use an Align, but I see now that I was wrong :)
Closing, because I no longer have a usecase.


Changed to uncompressed tarball.

The example data has been updated with an improved data set, and is available to download at http://www.well.ox.ac.uk/~jk/ga4gh-example-data.tar. It is an uncompressed tarball now, as all the internal data is already compressed. This PR updates the downloader script to take this into account.

+1


Context based abilities [discussion prior to PR]

Hey,
Recently, I encountered the need for a context based ability system.
The current way that abilities are built is relying heavily on a coupling between the user to some object.
If you have 2 objects that are decoupled and relations only defined by context objects or other classes you basically can't use the ability class.
Here's what I needed
class Board
  def users_invited_by(user)
    # multiple operations here including different data sources
  end
end

class User
end

Basically, I want to ask "CAN user X remove user Y from this board"
The board is the context here, without it, user X can't do anything with user Y on any other object.

Question is: Would that be something you want to include in the project (it's definitely something that people might need in the future IMHO)?
I have implemented this feature but didn't want to open a PR before discussing whether you want this functionality in or not.
LMK if so, and I would open a PR and we can continue the discussion there
Thanks

I agree with Bryan. The ability to pass in a block, a user, and a model or more should allow you accomplish any kind of complex logic here.
If you still disagree, could you provide a code example of what currently is required to make your situation work versus what you think should be required?


feat(smart-contracts): create, modify and remove actions for an offer…

Resolves #334
… table

@leisterfrancisco  this is looking great! awesome work!

@leisterfrancisco maybe we can arrange a call to view this PR?


Add ability to retrieve URL report URL for download

This adds the ability to retrieve the URL to download the URL report. Example usage:
$diffbot = new Diffbot(MY_TOKEN_HERE);
$crawl = $diffbot->crawl('SomeCrawlNameHere');
$url_report = $crawl->getUrlReportUrl();

// show the url to the url report
echo $url_report;

Brilliant, thanks