[Bug]: react/boolean-prop-naming not working with TS & declaration

Is there an existing issue for this?

[X] I have searched the existing issues and my issue is unique
[X] My issue appears in the command-line and not only in the text editor

Description Overview
There is no indication in IDE that the prop is not correct.
Terminal is throwing:
ESLint: 8.57.0

TypeError: Cannot read properties of undefined (reading 'properties')

The affected component code:
const Component = ({ color, withBackground }: ComponentProps & { withBackground?: boolean }) => (...);
I managed to fix the problem by moving the props definition in a separate type:
type ExtendedComponentProps = ComponentProps & { withBackground?: boolean };

const Component = ({ color, withBackground }: ExtendedComponentProps) => (...);

By doing this, the IDE is properly suggesting that "withBackground" is not covering the rules:
'react/boolean-prop-naming': [
      'warn',
      {
        rule: '^(is|has|are|can|should|show|hide)[A-Z]([A-Za-z0-9]?)+',
      },
]

Packages versions:
 "eslint": "8.57.0",
 "eslint-plugin-react": "7.34.2",
 "@typescript-eslint/eslint-plugin": "7.11.0",
 "@typescript-eslint/parser": "7.11.0",
 "typescript": "5.4.5"

Expected Behavior
Properly validate the props.
eslint-plugin-react version
v7.34.2
eslint version
v8.57.0
node version
v18.18.0

I believe this is fixed but not yet released. See #3733.

Released in v7.34.3. Happy to reopen if it's not fixed.

I'm getting a similar error with sort-prop-types.
Config:
"react/sort-prop-types": [
      "error",
      {
        "callbacksLast": true,
        "requiredFirst": true,
        "sortShapeProp": true,
        "noSortAlphabetically": true,
        "checkTypes": true
      }
    ],

Error:
$ eslint "{src,tests}/**/*.{js,ts,tsx}" --fix

Oops! Something went wrong! :(

ESLint: 8.57.0

TypeError: Cannot read properties of undefined (reading 'typeAnnotation')
Occurred while linting /Users/tyler/Code/condor/paqarina/src/AppWithAuthentication.tsx:9
Rule: "react/sort-prop-types"
    at handleFunctionComponent (/Users/tyler/Code/condor/paqarina/node_modules/eslint-plugin-react/lib/rules/sort-prop-types.js:233:39)
    at ruleErrorHandler (/Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/linter.js:1076:28)
    at /Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit (/Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (/Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/node-event-generator.js:297:26)
    at NodeEventGenerator.applySelectors (/Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/node-event-generator.js:326:22)
    at NodeEventGenerator.enterNode (/Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/node-event-generator.js:340:14)
    at CodePathAnalyzer.enterNode (/Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/code-path-analysis/code-path-analyzer.js:803:23)
    at /Users/tyler/Code/condor/paqarina/node_modules/eslint/lib/linter/linter.js:1111:32

hmm, can you confirm what version of the TS eslint parser you're using? it doesn't reproduce for me.

Ooh yeah, ours is outdated since we didn't get around to updating our eslint config to the new JS style instead of JSON:
"@typescript-eslint/parser": "5.62.0"

hm, that's the same version I have locally (and the latest one we currently test against), which doesn't reproduce the problem.

Here's our full config (minus rules):
"env": { "browser": true, "es2022": true, "node": true, "jest/globals": true },
  "root": true,
  "plugins": ["unused-imports", "filename-export", "consistent-default-export-name", "jsx-expressions"],
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:react/jsx-runtime",
    "plugin:react-hooks/recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:@typescript-eslint/recommended-requiring-type-checking",
    "plugin:@typescript-eslint/strict",
    "plugin:@eslint-community/eslint-comments/recommended",
    "plugin:etc/recommended",
    "plugin:import/warnings", // * All the errors in `import/recommended` are redundant with TypeScript except `import/order`.
    "plugin:jest/style",
    "plugin:jest/recommended",
    "plugin:jest-extended/all",
    "plugin:regexp/recommended",
    "plugin:testing-library/react",

    // * This config should always be at the end of this list in order to disable formatting rules
    "prettier"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaFeatures": { "jsx": true },
    "ecmaVersion": "latest",
    "project": "./tsconfig.json",
    "sourceType": "module",
    "tsconfigRootDir": "./"
  },
  "settings": {
    "react": { "version": "detect" },
    "import/parsers": { "@typescript-eslint/parser": [".ts", ".tsx"] },
    "import/resolver": {
      "node": { "extensions": [".ts", ".tsx"], "moduleDirectory": ["src", "src/tests/utils", "node_modules"] },
      "typescript": { "alwaysTryTypes": true }
    }

And here is our tsconfig.json:
{
  "compilerOptions": {
    "target": "ESNext",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": false,
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "baseUrl": "src",
    "esModuleInterop": true,
    "isolatedModules": true,
    "jsx": "react-jsx",
    "module": "esnext",
    "moduleResolution": "node",
    "noEmit": true,
    "noEmitOnError": false,
    "noFallthroughCasesInSwitch": true,
    "resolveJsonModule": true,
    "strict": true,
    "types": ["vite/client"]
  },
  "files": ["node_modules/jest-extended/types/index.d.ts"],
  "include": ["__mocks__", "src", "**/*.d.ts"]
}

nvm, it reprod, thanks :-)


gitbook plugin flexible alerts epub support

Hello,
As asked before for PDF support, can you add support for ePub too?

Thanks

I've encountered the same issue. Is there any way to solve?


'Protolude.Error.error' produces call stacks

Calling Protolude.Error.error will now include the call stack in the ErrorCall that is raised. Before this was not the case because we used the wrong implicit variable.

Ok, merging this. Thanks for the patch.


Rewrite CLEs caching to use Django cache

Aim
This rewrites the get_control_list_entries service functions in both caseworker and exporter to not use a mutable default variable cache and to use the Django cache instead.
LTD-5397

closing as I'm now working on a different branch


nixos/systemd-confinement: support ProtectSystem=/DynamicUser=

Description of changes
Use a RuntimeDirectory= as RootDirectory= instead of using /var/empty and TemporaryFileSystem=/.
See also a previous discussion about this change.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[X] Tested, as applicable:

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

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

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

[X] Fits CONTRIBUTING.md.

Ping @aszlig as author of systemd-confinement.
Ping @martinetd as fervent user of systemd-confinement.

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

@aszlig, but… those directories are empty (as commented and checked by the test, and I'll make it even more obvious by using rmdir) and they are forced on us by systemd, so much so that in the tests, because each chroot-exec starts a socket activated service they are (re)created by each chroot-exec.
The only reason why those directories were not present before is because TemporaryFileSystem= somehow prevents them from being created by systemd, which only raises "an ugly error and not a hard failure".
So I don't understand your concern here.
It should be possible to rmdir those empty directories with an ExecStartPre=+, but I don't see what additional security this would bring. To the contrary, doing so would then let a BindPaths= to a subpath creates them as an ancestor directory, which uses UMask=, which might raise a security concern by setting too relaxed permissions.

@aszlig, but… those directories are empty (as commented and checked by the test, and I'll make it even more obvious by using rmdir) and they are forced on us by systemd

Oh, saw that "Check that they're empty" comment and skipped over it because it looked like a todo-comment, sorry X-D
If that's the case then it's not a big issue, though it is indeed very ugly :-/
Will do a second (and this time full) review with testing later when awake.

There also seems to be an unrelated commit (765a09e) in this branch, was it pushed by accident?

Nope, this is a change following martinetd's comment to overcome the many systemd services which do not use a list for RuntimeDirectory= even though they should, to let users or here systemd-confinement add their own. Note that it's not removing duplicates though, which is not a problem for RuntimeDirectory=-like options, but may be for ExecStartPre=-like options. Anyway mixing list and non-list values in a systemd option is currently not supported, so this would not take users by surprise. I'm not sure if it requires a release note or not because it's quite a corner case.

I'm not sure if it requires a release note or not because it's quite a corner case.

IMHO this definitely requires a release note and I would certainly move this to a different pull request because it is not a requirement for supporting ProtectSystem/DynamicUser and rather a general nice-to-have. Don't get me wrong: I'm very much in support for this change, since I personally had do work around the list/non-list limitation several times, but it's off-topic here in this pull request.

Any problem remaining with this PR before asking a committer to merge it? or some concern raised that I've overlooked? Please let me know :)

Any problem remaining with this PR before asking a committer to merge it?

I'll merge this as soon as all points are addressed, so that we don't have regressions and/or surprising behaviour by deviating from the upstream documentations without users being aware of that.

or some concern raised that I've overlooked? Please let me know :)

We still have the issue that we now deviate from the systemd documentation and so far nobody has either commented on my proposal (the "you" in that comment was explicitly plural) and/or come up with a better idea.

@ju1m: Are you okay with me adding commits to your branch?

@aszlig, certainly, sorry for the delay, do I have to allow something somewhere?

We still have the issue that we now deviate from the systemd documentation and so far nobody has either commented on my proposal (the "you" in that comment was meant in plural) and/or come up with a better idea.

Ah, sorry I though my comment about piggybacking on PrivateTmp= was clear enough. So, to be more precise, because I was able to depend on serviceConfig.PrivateTmp to set serviceConfig.InaccessiblePaths (via config.systemd.packages) I did not feel the need to add a confinement.dynamicUser, so I just followed the part about documenting, in the option and in the InaccessiblePaths= config:

systemd-confinement's default behavior: recreating PrivateTmp=false,
and how to get systemd's default behavior: by specifying serviceConfig.PrivateTmp=true, note the serviceConfig to be very specific that it has to be set at NixOS-level and not config.systemd.packages' level.

Anecdotically, I was able to understand what to expect and what to do from that new documentation after forgetting about all this for two weeks.
Yet, let me know if your concern about this is not yet solved in a satisfactory manner?

[X] Rebase after conflict in nixos/doc/manual/release-notes/rl-2405.section.md

I haven't forgotten about this, but I've fallen ill and am on the mend.

@ofborg test systemd-confinement

@aszlig thanks!

[X] nix -L build -f . nixosTests.systemd-confinement passed for me
[X] My confinement of services.miniflux using DynamicUser=true worked.
[X] systemd.services.public-inbox-init.confinement = true fails at runtime with the usual cryptic error messages due to RootDirectory = "/var/empty"; TemporaryFileSystem = "/";:

Failed to create /var/empty/usr: Operation not permitted
Failed to create destination mount point node '/var/empty/bin/sh': No such file or directory
Failed to mount /nix/store/gdc7yg4hral8i89p9w4gi6496w1p505z-dash-0.5.12/bin/dash to /var/empty/bin/sh: No such file or directory
public-inbox-init.service: Failed to set up mount namespacing: /var/empty/bin/sh: No such file or directory
public-inbox-init.service: Failed at step NAMESPACE spawning /nix/store/ddhngjm9bahdzgimx6bppkzzgd3hjbas-unit-script-public-inbox-init-start/bin/public-inbox-init-star>

Maybe we should:

Remove lib.mkDefault from systemd-confinement's RootDirectory= to get a build-time error, or maybe use lib.mkForce?
Add an assertion in systemd-confinement checking that there is no "/" in TemporaryFileSystem's list.
Make services.public-inbox only set RootDirectory= and TemporaryFileSystem=/ when confinement is not enabled. I'll prepare a PR for that, though I'll much prefer to just have confinement enabled by default on that service…

Maybe we should:

Remove lib.mkDefault from systemd-confinement's RootDirectory= to get a build-time error, or maybe use lib.mkForce?

Is the issue the RootDirectory option or is it because we now set ReadOnlyPaths?

Add an assertion in systemd-confinement checking that there is no "/" in TemporaryFileSystem's list.
Make services.public-inbox only set RootDirectory= and TemporaryFileSystem=/ when confinement is not enabled. I'll prepare a PR for that, though I'll much prefer to just have confinement enabled by default on that service…

We also have a fourth option that is similar to the second: Check whether there is / in TemporaryFileSystem and if that's the case[^1] we remove it from ReadOnlyPaths.
This however is one particular corner case which we're optimising for in the confinement module, which I'm not sure would be the right place. If it's something that would generally make sense in conjunction with the confinement module, I'd say it's fine but I have a hard time coming up with such a scenario.
So I'd probably opt for the third option and only set those options without confinement enabled.
Is there a feature (or bugfix) that's missing in the confinement module which is preventing it from being enabled by default on that module?
[^1]: This is me assuming the failure is due to the ReadOnlyPaths setting, I haven't verified this.

Remove lib.mkDefault from systemd-confinement's RootDirectory= to get a build-time error, or maybe use lib.mkForce?

Is the issue the RootDirectory option or is it because we now set ReadOnlyPaths?

public-inbox's RootDirectory=/var/empty is the problem.
It's unrelated to ReadOnlyPaths=.
It's a (silent) collision between public-inbox and systemd-confinement both  setting their own RootDirectory=, hence my suggestion to at least remove lib.mkDefault to make the collision visible at build-time.
I've pushed 3. in https://github.com/NixOS/nixpkgs/pull/311181 which tests public-inbox's confinement and fixes it with the changes in this PR.

Add an assertion in systemd-confinement checking that there is no "/" in TemporaryFileSystem's list.
Make services.public-inbox only set RootDirectory= and TemporaryFileSystem=/ when confinement is not enabled. I'll prepare a PR for that, though I'll much prefer to just have confinement enabled by default on that service…

We also have a fourth option that is similar to the second: Check whether there is / in TemporaryFileSystem and if that's the case1 we remove it from ReadOnlyPaths.

Alas, changing serviceConfig settings depending on the content of other serviceConfig settings is not possible (infinite recursion).
That's why we had to resort to the config.systemd.packages hack for setting InaccessiblePaths= when serviceConfig.PrivateTmp is false.

This however is a corner case which we'd be optimising for in the confinement module, which I'm not sure would be the right place. If it's something that would generally make sense in conjunction with the confinement module I'd say it's fine, but I have a hard time coming up with such a scenario.
I agree, I was just suggesting two more build-time checks, not to automatically change the configuration.
So I'd probably opt for the third option and only set those options without confinement enabled.

Yes, I've done 3. I leave it to you whether to do 1. and 2. or not, as this PR is already very good to merge for me, and having it merged before 2024-05-22 would bring it into nixos-24.05.

Is there a feature (or bugfix) that's missing in the confinement module which is preventing it from being enabled by default on that module?

Yes, in the PR I had to change RootDirectory=/var/empty for RootDirectory = "/run/confinement/public-inbox-${srv}"; and remove TemporarySystem=/ which I set before because it was what systemd-confinement was using anyway.

Yes, I've done 3. I leave it to you whether to do 1. and 2. or not, as this PR is already very good to merge for me, and having it merged before 2024-05-22 would bring it into nixos-24.05.

:+1: I'll implement point 1, rebase and merge. Thanks for your input and the work done here :-)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nixos-policy-regarding-systemd-confinement/18976/2


Linear Evaluation LR Sweep Values

Hi,
in the paper, you write "For each model, we sweep the learning rate value.".
What are the swept learning rate values?
Thank you.

@mathildecaron31 would be highly appreciated :)

@mathildecaron31 yeah having some clarity around this would be great. Thanks :)


ES 6.8.0 java.lang.IllegalArgumentException: if you don't need a prefix then use a regular logger

The exception in the title occur at plugin load time, preventing ES from starting up.
Appears to be caused by this change: https://github.com/elastic/elasticsearch/pull/35146/commits/e3763b4be960d6e7bf02953c762d96b8f0f5c33f
Changing all calls to Logger.getLogger() from something like:
private final Logger log = Loggers.getLogger(ChangesFeedPlugin.class);
to:
private final Logger log = Loggers.getLogger(ChangesFeedPlugin.class, "Changes Feed");
Seems to fix the problem.

closing, reopening it on the active project


Add support for cancel streaming requests.

Description of the feature request:
I'm wondering if it's possible to add support to cancel streaming requests
What problem are you trying to solve with this feature?
While streaming long responses from Gemini, users may want to cancel the streaming before it's completed.
Any other information you'd like to share?
This PR https://github.com/MacPaw/OpenAI/pull/214 realizes a similar feature to cancel streaming.

Can be an interesting feature 🤔!

We need this feature 👍

Thanks for the feature request. We've added it to our backlog, but haven't yet scheduled it. In the meantime, please add your 👍 to indicate interest.


merge 3.0 to main

Codecov Report

Merging #189 (19bfb97) into main (7bd7147) will decrease coverage by 0.15%.
The diff coverage is 28.57%.

@@            Coverage Diff             @@
##             main     #189      +/-   ##
==========================================
- Coverage   62.55%   62.41%   -0.15%
==========================================
  Files          99       99
  Lines       22139    22168      +29
==========================================
- Hits        13849    13836      -13
- Misses       8290     8332      +42

Impacted Files
Coverage Δ

taos-query/src/tmq/mod.rs
42.71% <0.00%> (-2.99%)
:arrow_down:

taos-sys/src/tmq/mod.rs
64.69% <0.00%> (-1.07%)
:arrow_down:

taos-ws/src/query/mod.rs
76.59% <0.00%> (+0.96%)
:arrow_up:

taos-ws/src/consumer/mod.rs
78.16% <52.94%> (-1.46%)
:arrow_down:

taos-ws/src/consumer/messages.rs
96.92% <100.00%> (-0.05%)
:arrow_down:

taos-ws/src/schemaless/infra.rs
59.61% <100.00%> (-2.89%)
:arrow_down:

taos/src/tmq.rs
54.38% <100.00%> (-0.07%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Could you also bind ImGui's OpenGL2 backend?

Hi, Pascal,
I just met this awesome repo and trying to use it in my projects.
There were some shaders only support OpenGL 2.1/GLSL 120.
So I have to use GL2 in my project.
I saw imgui_bundle only binded GL3 backend as below.
https://github.com/pthom/imgui_bundle/blob/92b4db4513dc11e2e56bb44842d0193d48debcc9/external/imgui/bindings/pybind_imgui_backends.cpp#L17-L40
Could you also add the Dear ImGui's OpenGL2 backend support?
IMGUI_IMPL_API bool     ImGui_ImplOpenGL2_Init();
IMGUI_IMPL_API void     ImGui_ImplOpenGL2_Shutdown();
IMGUI_IMPL_API void     ImGui_ImplOpenGL2_NewFrame();
IMGUI_IMPL_API void     ImGui_ImplOpenGL2_RenderDrawData(ImDrawData* draw_data);

// Called by Init/NewFrame/Shutdown
IMGUI_IMPL_API bool     ImGui_ImplOpenGL2_CreateFontsTexture();
IMGUI_IMPL_API void     ImGui_ImplOpenGL2_DestroyFontsTexture();
IMGUI_IMPL_API bool     ImGui_ImplOpenGL2_CreateDeviceObjects();
IMGUI_IMPL_API void     ImGui_ImplOpenGL2_DestroyDeviceObjects();

Hello, thanks for the kind words!
This is not in my current target list, sorry.
However, I can show you how you could test it on your side. If you show me that it works, I might consider it a bit later.

Modify external/imgui/bindings/pybind_imgui_backends.cpp:

// [...]
#include "imgui/backends/imgui_impl_opengl2.h"

void py_init_module_imgui_backends(py::module& m)
{
// [...]

    m.def("opengl2_init",
          ImGui_ImplOpenGL2_Init);

    m.def("opengl2_shutdown",
          ImGui_ImplOpenGL2_Shutdown);

    // etc
}

Modify cmake/add_imgui.cmake:

# This will create an imgui target with the correct install, include and link options
function(add_imgui imgui_dir)
    if(NOT TARGET imgui)
        file(GLOB imgui_sources ${imgui_dir}/*.h ${imgui_dir}/*.cpp ${imgui_dir}/misc/cpp/*.cpp ${imgui_dir}/misc/cpp/*.h)
        add_library(imgui STATIC ${imgui_sources})

        # Add this line: this is a hack, since this should be done inside HelloImGui
        target_sources(imgui PRIVATE ${imgui_dir}/backends/imgui_impl_opengl2.cpp ${imgui_dir}/backends/imgui_impl_opengl2.h)

Modify bindings/imgui_bundle/imgui/backends.pyi

+ def opengl2_init() -> bool:
    pass

# etc

This should be enough.
Then , write a modified version of the ImGui standalone example:
bindings/imgui_bundle/demos_python/demos_immapp/imgui_example_glfw_opengl3.py
And test that it works.

Update: since this was actually much easier to do than I thought, I did it and just pushed it.
See https://github.com/pthom/imgui_bundle/commit/eb47c3efb84ddf2a7d0c979b426dab4748e8a336
To test it, you can either pip install from source, or check if the prebuild wheels are available for you here (download and unzip the artifacts)
I plan to release an update to pip (v0.8.3) quite soon.

Thanks for the quick update. It works!


Getting error option sameSite is invalid while setting sameSite:none in cookie options.

Node version: 10.x
Sails version (sails): 1.2.3

Getting error `option sameSite is invalid` while setting `sameSite:none` in response cookie options.
This is because sails is using<EMAIL_ADDRESS>which uses<EMAIL_ADDRESS>which does not support SameSite=None option in cookies. This support was added to the cookie package in version 0.4.x. To fix it can we update express to 4.17.x, which is using<EMAIL_ADDRESS>Express Changelog: https://expressjs.com/en/changelog/4x.html
I am happy to create a PR if required.

Hi, @kriss1897—
Thanks so much for looking into this for us! We'd be happy to check out a PR addressing this issue. If you could link to that PR in a comment to this issue, that would be fabulous. Thanks, again!

@madisonhicks I found one existing PR which should fix this issue.
https://github.com/balderdashy/sails/pull/6870

@kriss1897 Thanks for relaying the PR! After reviewing the changes, we actually can't merge it since it points directly to the Express repo "express-session": "git+https://github.com/expressjs/session.git". Perhaps it’s relying on an unreleased feature at the moment?

@johnabrams7 The issue you mentioned above has been fixed in the PR, is it possible for it to get merged?

@kriss1897 @nino-vrijman @madisonhicks @johnabrams7 just got that PR merged in– if you install the latest Sails (1.4.0) should be fixed now

@kriss1897 @nino-vrijman @madisonhicks @johnabrams7 just got that PR merged in– if you install the latest Sails (1.4.0) should be fixed now

Hi Rachael,
I have updated Sails.js to 1.4.0 by running npm update sails. I can see that it was updated in my package.json:
"dependencies": {
    "@sentry/node": "^5.25.0",
    "async": "2.0.1",
    "aws-sdk": "^2.771.0",
    "bcrypt": "^3.0.8",
    "cheerio": "^1.0.0-rc.3",
    "connect-mongo": "2.0.3",
    "faker": "^4.1.0",
    "json2csv": "^4.5.4",
    "lodash": "^4.17.20",
    "moment": "^2.29.1",
    "nested-pop": "^0.1.4",
    "path": "^0.12.7",
    "sails": "^1.4.0",
    "sails-hook-jobs": "^0.1.6",
    "sails-hook-organics": "^0.15.2",
    "sails-hook-orm": "^2.1.1",
    "sails-hook-sockets": "^1.5.5",
    "sails-mongo": "^1.2.0",
    "sharp": "^0.25.4",
    "skipper": "^0.8.7",
    "url": "^0.11.0",
    "util": "^0.11.1"
  }

Following is my cookie configuration which I am sure is applied for the specific environment:

However, when I log in via Postman I still get sameSite: strict.
I am setting the cookie by this.req.session.userId = user.id; in a corresponding action.
Do you have any idea what am I doing wrong?
Thank you.

Hi @davidkregl, It looks like the problem you are running into is because the secure attribute is set to false. sameSite: 'none' requires secure: true to work properly.

Thanks @davidkregl! I've tested this, it is working fine. Closing this ticket now.

I have same problem


Fix setup.py

Remove south as an explicit dependency, supported versions of django don't need south or expect it to be installed.
One should explicity install south or they might have already installed one.

Thanks for a quick merge 😊


[mesheryctl] improve the error messages in each command

Improve the error messages in each command from the point of user experience. Here is the complete list of commands from which you can claim a command to work on.

[ ] mesheryctl
[ ]  mesheryctl system
[ ]  mesheryctl system channel
[ ] mesheryctl system context
[ ] mesheryctl mesh
[ ] mesheryctl perf
[ ] mesheryctl app
[ ] mesheryctl pattern
[ ] mesheryctl exp

[ ]  mesheryctl exp filter

We need to make sure of the following things

There are proper error messages when users

Give more args than required
Misspell a command
Do not give the required input via flags or args
Use the command without any arguments or flags.

The error messages being displayed to users are meaningful from user's perspective. And if applicable, a potential fix for the problem should be shown too.  For example

"failed to unmarshal response body" could be modified to "couldn't process JSON response from server"
"manifest not found" could be modified to "manifest not found. Please provide the path to the app manifest."

Hi @nishantwrp may I work on this?

@nishantwrp I would like to work on this as well.

I would like to work on this issue.

@nishantwrp if not assigned to anyone I want to contribute to this issue. Thank you

I'd like to take up this issue.

Please breakdown this parent issue into many child issues.

I've created individual issues for each command (#6265 - #6274). @17sushmita @XDRAGON2002 @RotimiFreq @nik132-eng @XanderWatson please comment on one of these issues.


fix: Updating the logic to fix datasource reconnect modal issue

Description
Updating the logic to fix datasource reconnect modal issue where the form content was getting retained even when the datasource has been changed.
PR fixes following issue(s)
Fixes # (issue number)
Type of change

Bug fix (non-breaking change which fixes an issue)

Testing
How Has This Been Tested?

[x] Manual
[ ] Jest
[ ] Cypress

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/build-deploy-preview


[feature request] use texture pack to decorate cpas inventory

I use Vanilla Tweaks 'dark UI', which sets the color of the various inventory to a darker gray. However, the CPAS inventory remains 'light' colored.
It would be great if the CPAS inventory would create it's texture from elements of the texture pack.
If you want an example of that idea at work, in the mod tweakeroo, the function 'preview shulker' feature does create it's interface that way.

I have created a dark theme hopefully it fulfills your needs
CPAS Dark Theme.zip


Update qgis.rb

Thank you for the contribution. It was merged directly as ec758d8183b22b12e7dd32bc2fa5446c1d9c416b to keep commit history cleaner. Your contribution is still credited to you.


Complete export of 'Routed' and 'RoutedT'

Oh, actually, what is the purpose of this?  I think these were not exported in order to preserve invariants.

I wanted RoutedT(..) for defining some instances - just checked and was able to define the instances with mapRoutedT instead.

OK, sounds good.  We can also add unsafeRoutedT if necessary.  The key thing here is that RoutedT provides a strictness guarantee, which could be violated by incorrect uses of RoutedT.

Could we change the type of mapRoutedT from
(m a -> n a) -> RoutedT t r m a -> RoutedT t r n a
To
(m a -> n b) -> RoutedT t r m a -> RoutedT t r n b
While we want to keep the internals of routedT hidden, I found myself
wanting to peel off an eventwriter inside of RoutedT which means the type
of mapRoutedT doesn't quite work because it takes a natural transformation
that has to preserve the return type. Eg I want to be able to write:
mapRoutedT runEventWriterT :: RoutedT t r (EventWriterT t w m) a -> RoutedT
t r m (a,w)
I can pr this if you'd like that as the compromise.
On Mon., 18 Mar. 2019, 05:42 Ryan Trinkle<EMAIL_ADDRESS>wrote:

OK, sounds good. We can also add unsafeRoutedT if necessary. The key
thing here is that RoutedT provides a strictness guarantee, which could
be violated by incorrect uses of RoutedT.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/obsidiansystems/obelisk/pull/378#issuecomment-473707719,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJt3WONL2cRDb9XZt2zljr2N25oNzYyks5vXpq7gaJpZM4b4kF5
.

@benkolera Yes, that looks like a good generalization to me.


Cloud Logging fix

improves GCP logging conformance of generated code
New formatting:

fixes #351

@craiglabenz – needed to run the generator. I did a force push to update the commit message, too. I'll land when green!


Waveguide Separation in get_bundle_from_waypoints.py

When the separation parameter is set, sometime it reduce the separation of two waveguide to 0. I think it's due to line 234 in this file. np.sign(offsets_start[1]) give 0 if offset_start[1] == 0, which happens sometime. I changed it to the following (see attached screenshot) and it fixes the issue. I'd suggest adding this fix to master.
if separation and len(ports1) > 1:
    # the default case when we start with the reference port
    offeset_start_sign = np.sign(offsets_start[1]) if np.sign(offsets_start[1]) != 0 else 1
    offsets_mid = [
        offeset_start_sign * separation * i
        for i, o in enumerate(offsets_start)
    ]

Thank you Athena!
updating it in 5.5.1
gdsfactory/routing/get_bundle_from_waypoints.py
it would also be great if you could also include some code to reproduce the issue, to make sure we can add a test for it


mptcpize: set GODEBUG=multipathtcp=1 env var

GO apps don't use the libC, so the LD_PRELOAD technique doesn't work with these apps.
But since GO 1.21, MPTCP is natively supported, and can be forced by simply setting GODEBUG=multipathtcp=1. So mptcpize can easily support GO apps by also setting this env var.
Similar to the LD_PRELOAD env var, the GODEBUG one is appended with a comma if it was already set.
Link: https://go.dev/doc/godebug
Link: https://pkg.go.dev/net#Dialer.SetMultipathTCP
Depends-on: #315

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 64.075%

Totals

Change from base Build<PHONE_NUMBER>9:
0.0%

Covered Lines:
1409

Relevant Lines:
2199

💛  - Coveralls


[BUG] python Thread remains open after closing window - live data only

Expected Behavior
When closing a Window the python thread should also close,  works well with all of the example but live_data.py example
Current Behaviour
when closing window for live chart the python thread keeps alive in windows manager
Reproducible Example
run
lightweight-charts-python\examples\2_live_data\live_data.py
close the window
python thread keeps open
confirm it on task manager

Environment
- OS: Window
- Library: lightweight-charts-python

Hey @esteban2006,
Whilst this is unexpected behavior, there is no direct way to amend this to automagically quit the thread. My recommendation would always be to use chart.show_async for a live chart setup, and then use the chart.is_alive attribute to check within your loop if the window has been closed.
If you don't want to use asyncio, you could add this statement inside the for loop:
if chart._exit.is_set():
    break

Louis

resoved,
thank you @louisnw01 for you response,


Fixes for issues found in certification

Issues addressed:

iOS - Convex hull wasn't resetting old hull before showing new one.
All platforms - geopackage samples need to be updated for new path behavior
Android samples - alert dialog text unreadable after theme change
Android samples - some samples were missed in earlier effort to prevent sample reset on rotation
Android IWA - keyboard autocompletes in URL field
Forms Android IWA - once the list of maps is scrolled out of view, it couldn't be scrolled back in
Forms Android Find Place - selecting a suggestion result for a location updated the search instead
All platforms - Service area interactive didn't allow finishing drawing barriers
UWP - Find address - selecting a suggestion didn't always zoom to that address.
Forms iOS - Author and save map - couldn't add more than one layer to map
WPF and UWP Author and save a map - sample title updated to be consistent with other platforms

Verified with build 2390. Ran into no issues, all changes looks good to me.


Feature Extraction and ML Implementation on Dataset

Description
The current dataset lacks proper feature extraction, and no machine learning models have been applied for analysis.
Suggested Fix

Feature Extraction: Extract meaningful features (e.g., statistical, spatial, or frequency-based features).
ML Implementation: Train classification models like SVM, Random Forest, or CNN on the extracted features.
Evaluation: Validate model performance using metrics like accuracy, precision, and F1-score.

Expected Outcome
A well-trained ML model with extracted features and improved classification performance.

I've completed my course in Machine learning, I think I'd be a good fit for the issue. @SaranDharshanSP

I've completed my course in Machine learning, I think I'd be a good fit for the issue. @SaranDharshanSP
Hey @Praveen20cent , you've been assigned this issue under Amrita Winter of Code! Please ensure to raise a PR by 30/12/2024, or it will be reassigned to someone else. Best of luck! 🫡


use newer xattr

It would be great if restic could use a newer version of xattr (latest release: v0.2.0). According to vendor/manifest it uses revision b867675798fa7708a444945602b452ca493f2272.
It would help the Debian packaging of the latest restic.

No problem, are you interested in doing a PR?

Sorry, I don't have much time to check if this release changed the api and still is compatible with restic or not. I just have enough time to do the packaging for xattr and the newer restic...
I will probably be an easy check for the person who added xattr support to restic.

No problem at all :)


Reminders Permission

I integrated DBPrivacyHelper into JLPermissions - https://github.com/jlaws/JLPermissions - and for consistency it would be great if you added support for reminders permissions.

Thanks @jlaws , it's done! tag 0.6


Add Support for Using Constant Paths into All Handlers

Very nice!  Are the UI tests also swept in here, such as sidebar_test.py?  If not, it's okay to follow-up.
https://github.com/uProxy/ufo-management-server/blob/master/tests/ui/sidebar_test.py

Reviewed 18 of 18 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from the review on Reviewable.io


"List" command now returns interfaces properly.

This fixes the issue mentioned here: https://github.com/feross/spoof/issues/23
Just a matter of returning the "interfaces" list :)
That being said - most Windows interfaces have a space in the name, as seen here: https://i.imgur.com/IgJ2cpO.png
This causes a single interface, "Wi-Fi 2" to be read as two arguments, event when 'd, i.e. "Wi-Fi\ 2". Any advice on how to fix this one?

Oh wait! I'm a dummy, it just takes quotes, i.e: randomize "Wi-Fi 2".
That being said, it looks like the command isn't changing the MAC address. I'll explore this a bit more.

Looking forward to it!

Slight progress! It seems like in index.js:372,
if (values[x].name == 'AdapterModel') {
should be changed to:
if (values[x].name == 'DriverDesc') {
although I could be incorrect in this assumption.
DriverDesc gives a value such as "802.11n USB Wireless LAN Card" or "LogMeIn Hamachi Virtual Ethernet Adapter". There is no key in these registries called "AdapterMode" as far as I can tell.
@feross If this is how it should be operating, let me know and I'll update the PR with a commit for this. My only concern is it doesn't seem to be checking if this is the right device - I don't want to publish a commit that would accidentally change the MAC address for all devices!
Changing this successfully changed the MAC address, but there's one more problem - although index.js:381-382 are synchronous, it seems like 382 doesn't actually get executed.
I have to manually run the "netsh interface set interface  enable" command in terminal - if I don't it just disables my interface (haha oops). After this, the MAC address is successfully changed, though!

Thanks for the PR to return the interfaces properly. As for your other issue, please send another PR if you're up to fix it still.

Released as 2.0.3.


[NEW] Django Awesome

Project Information

Project Name: Django Awesome

Project URL: https://github.com/django-awesome/django-awesome

Description:

Integrate beautiful UI to Django admin
Custom Admin function that help build dashboard, menu, bookmark and plan to improve more
Bring awesome libraries incorporated into a project
Production ready: ready to form the core for projects of any scale and can be deployed to production right after pulling the code.

Criteria
Please answer the following questions about the project you are submitting. This will help us evaluate if the project should be included in the Awesome Django list.

Is the project new?

[x] Yes
[ ] No

How long has the project been maintained?

Only 3 weeks on Github but the project was build for 4 months

How many releases has it had if it's a library or package?

8 Releases so far

Are you the author or are you submitting the project on behalf of a company?

[x] I am the author
[ ] I am submitting on behalf of a company
[ ] Other (please specify)

What makes it awesome?

Using A curated list of awesome things related to Django from this repo incorporated into a project that help developers can save their time to implement libraries
With the dedication of an experienced programmer to incorporate accumulated knowledge into the project, serving as a foundation for other developers to utilize, such as integrating beautiful templates from the Keenthemes team to replace the default UI of Django admin, expanding Django's logging functionality to generate useful copies for storage in future projects.

Additional Information
Please provide any additional information you believe is relevant to the project or its evaluation for inclusion in the Awesome Django list. This might include information about the project's documentation, test coverage, community support, or any unique features that set it apart from other Django projects.

Thank you for your contribution to the Awesome-Django project. We appreciate your effort but have concerns about the name "django-awesome," as it closely resembles our project name and might cause confusion. We would gladly reconsider your pull request with a different name that maintains distinctiveness from "Awesome-Django."


FionaValueError: No dataset found at path

I suddenly keep getting:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\fiona\__init__.py", line 175, in open
    enabled_drivers=enabled_drivers)
  File "C:\Python27\lib\site-packages\fiona\collection.py", line 147, in __init__
    self.session.start(self)
  File "fiona\ogrext.pyx", line 444, in fiona.ogrext.Session.start (fiona/ogrext.c:9253)
FionaValueError: No dataset found at path '\test.shp' using drivers: *

I use fiona through rasterstats (https://github.com/perrygeo/python-rasterstats). I get this with every .shp files. Even those that used to work.
The problem is that I don't know exactly what changed.
I've updated to:
Python 2.7.13
And from Gohlke:
Fiona 1.7.1
GDAL 2.0.2 (because the 2.1.2 version resulted in Python crashes)
From gisinternals
GDAL 2.1.2
and it started not working.
I used to use:
Python 2.7.11
And from Gohlke:
Fiona 1.6.3
GDAL 2.0.2
From gisinternals
GDAL 2.1.0
The problem is when I uninstall everything (even GDAL from gisinternals) and go back to 1.6.3, the problem persists.
ogrext.pyx doesn't seems to be anywhere (only .pyd) but I guess that's normal?
I apologize already for probably not giving enough information. Many thanks in advance.

@vanderlist can you provide a little more context, like a complete script (smaller the better) that produces the error? I'll try it out.

That's the thing. Just a basic operation invokes it:
with rasterstats:
from rasterstats import zonal_stats
oStats = zonal_stats('test.shp', 'test.tif')

and just with fiona:
import fiona
c = fiona.open('test.shp', 'r')

I first thought it was a SHP issue but it happens too with SHP files that worked before. So I guess you can use whatever SHP file you got. For rasterstats you can use the test data from the package itself.
Then I thought it was a rasterstats issue so I went from 0.11.0 back to 0.10.3, same problem.
Then I tried reinstalling GDAL 2.1.0 back instead of GDAL 2.1.2 from gisinternals.
Then I tried reinstalling everything including Python.
If there is anything else I can provide. I'm working on Windows 10 using Visual Studio 2015 and the Python Tools: PTVS 2.2.50104.00-14.0.
a full list of the python packages

I had rasterio 0.33.0 and pyshp 1.2.3 before but I don't think I matter.
The only similar problems on the internet, I can find is the problem Fiona had with GDAL2.0 instead of GDAL1.0.
I really hope you can reproduce but I doubt it. I hope I'm overseeing something somewhere.
Many thanks in advance for looking into it.

I suspect that there is something wrong with the gdal installation you have. I'm not sure if you can mix gdal from gisinternals with the fiona binaries from gohlke.  If you use the fiona binaries, I would suggest to use the same gdal libraries fiona is compiled against. Do you have other versions of gdal installed, e.g. from osgeo4w? Could you check if ogrinfo works? It should be located in C:\Python\Lib\site-packages\osgeo or similar.
Regarding orgext.pyx: Gdal 1.x ist not API compatible to Gdal 2.x. Fiona uses orgext1.pyx for gdal 1.x and ogrext2.pyx for gdal 2.x. At compile time, ogrext.pyx is created from either  orgext1.pyx or orgext2.pyx depending on the installed version of gdal.

Hello,
I seem to have a solution for fiona. So I tried what @rbuffat suggested and deinstalled everything and not reinstalled the GISinternals GDAL. I even deinstalled QGIS to have no other Python and/or GDAL where ever. Although it had worked before with them installed.
I then installed my previous setup again.
Python 2.7.11
And from Gohlke:
Fiona 1.6.3 (Fiona-1.6.3+gdal200-cp27-none-win_amd64.whl)
GDAL 2.0.2 (GDAL-2.0.2-cp27-none-win_amd64.whl)
And added C:\Python27\Lib\site-packages\osgeo as PATH instead of C:\Program Files\GDAL so I could use GDAL in cmd (the reason I thought I needed the GISinternals GDAL in the first place). I also changed the GDAL_DATA and GDAL_DRIVER_PATH variables accordingly.
Fiona seems to work now with:
import fiona
c = fiona.open('test.shp', 'r')

However rasterstats 0.11.0 does not. With:
from rasterstats import zonal_stats
oStats = zonal_stats('test.shp', 'test.tif')

It gives me
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\rasterstats\main.py", line 28, in zonal_stats
    return list(gen_zonal_stats(*args, **kwargs))
  File "C:\Python27\lib\site-packages\rasterstats\main.py", line 140, in gen_zonal_stats
    for _, feat in enumerate(features_iter):
  File "C:\Python27\lib\site-packages\rasterstats\io.py", line 84, in fiona_generator
    for feature in src:
  File "fiona/ogrext.pyx", line 1126, in fiona.ogrext.Iterator.__next__ (fiona/ogrext.c:19067)
  File "fiona/ogrext.pyx", line 164, in fiona.ogrext.FeatureBuilder.build (fiona/ogrext.c:3357)
IndexError: list index out of range

I don't know what goes wrong there.
The problem was indeed the GDAL fiona is looking for when installing.
I also tried this with the updated setup with Python 2.7.13 and Fiona 1.7.1 but that still didn't work. Updating is a problem to deal with later (my problem of course).
One step closer but not yet there.

@vanderlist it is indeed very easy to get into a bad situation with too many GDALs installed. I'm sorry about that!
There's a chance that upgrading to rasterstats 0.10.1 will fix your problem. I see it has a possibly related change: https://github.com/perrygeo/python-rasterstats/commit/c6c85685275f39fa242a96ef7e74889756f2fca7 /cc @perrygeo

@sgillies
Would it make sense to implement a fiona.debug() / check() function that checks if the current version of gdal matches the version fiona was compiled against, issuing a warning if they do not match?

Hello @sgillies
I was already busy trying out older versions of rasterstats but the problem persists with 0.10.3 and 0.10.1.
Anyway thanks for the suggestion. Should I open an issue at https://github.com/perrygeo/python-rasterstats/issues or is this still fiona related? /cc @perrygeo
Anyway, from a first time poster (but longer user): Thank you all for looking into this.

@vanderlist can you try this and report the results:
import fiona
with fiona.open('test.shp', 'r') as src:
    features = [f for f in src]
print(len(features))

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "fiona/ogrext.pyx", line 1126, in fiona.ogrext.Iterator.__next__ (fiona/ogrext.c:19067)
  File "fiona/ogrext.pyx", line 164, in fiona.ogrext.FeatureBuilder.build (fiona/ogrext.c:3357)
IndexError: list index out of range

You are correct, the same problem. So, it is still a Fiona problem, or more specifically a 'Fiona 1.6.3 on my setup' problem. I will try and upgrade to Fiona 1.7.1 using Gohlke's whl. And see if the problem persists. No use in trying to solve something in an old version, I think.

@vanderlist are you able to share the shapefile? I'd like to rule out a problem in the dataset itself.

If I upgrade to Fiona 1.7.1 I get the following with import fiona:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\fiona\__init__.py", line 76, in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
  File "C:\Python27\lib\site-packages\fiona\collection.py", line 7, in <module>
    from fiona import compat
ImportError: cannot import name compat

I can share the shape file but it happens with all the shape files
sample_selector_grid100_m0_tmp.zip
.

I think fiona 1.6.3 is incompatible with gdal 2.0. Support for Gdal 2.x was introduced with 1.7.0.
IndexError: list index out of range  Indicates, that the shapefile contains a Integer64, which Fiona before 1.7.0 is not aware of.

Indicates, that the shapefile contains a Integer64, which Fiona before 1.7.0 is not aware of.
This is the case. But it worked before. From Golhke:

Fiona-1.6.3+gdal200-cp27-none-win_amd64.whl
GDAL-2.0.2-cp27-none-win_amd64.whl

Of course I did not know which GDAL Fiona used (Gohlke's or GisInternals GDAL, both were 2.x though).
Anyway, strange.  Maybe Gohlke did something in the .whl to make it work (hence the gdal200 reference in filename)?
Sorry for not understanding. I think I'm really overlooking something that happened and broke it. I will look into the compat ImportError.

Correction:
With Fiona 1.7.1. With import fiona I get:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\fiona\__init__.py", line 76, in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
  File "C:\Python27\lib\site-packages\fiona\collection.py", line 8, in <module>
    from fiona.ogrext import Iterator, ItemsIterator, KeysIterator
ImportError: DLL load failed: The specified module could not be found.

It's only after I try to from rasterstats import zonal_stats that it get:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\fiona\__init__.py", line 76, in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
  File "C:\Python27\lib\site-packages\fiona\collection.py", line 7, in <module>
    from fiona import compat
ImportError: cannot import name compat

Ok, it's defintely a dependency problem with Fiona 1.7.1 not finding the GDAL dll. I checked ogrext.pyd with Dependendacy Walker. Tt searches for GDAL201.dll which it does not find in the osgeo folder because it has GDAL200.dll . If try the same with Fiona 1.6.3 it searches for GDAL200.dll .
Is there a way I can force Fiona 1.7.1 to look for GDAL200.dll ?
Does pip install do something wrong when installing?
tbc.

I would recommend deinstalling all gdal / fiona / rasterio libraries.Then check site-packages for left-overs. Then download the latest gdal / fiona / rasterio wheels from gohlke and install them.

Good news everyone, I got it working.
Even though I tried reinstalling everything several times I got it working with installing after deinstalling the packages on Python 2.7.11:

rasterio-1.0a3-cp27-cp27m-win_amd64.whl
GDAL-2.1.2-cp27-cp27m-win_amd64.whl
Fiona-1.7.1-cp27-cp27m-win_amd64.whl
rasterstats 0.11.0

To recapitulate:
The original Fiona error I got probably started when I updated the GISinternals GDAL (from 2.1.0 to 2.1.2).  I didn't uninstall it first so it probably also got faulty. While this still being installed I updated the Gohlke GDAL from 2.0.2 to 2.1.2 and this made python crash so I went back to Gohlke GDAL 2.0.2. And that didn't match with Fiona 1.7.1. So I went back to Fiona 1.6.3 and that gave the Indexerror.
Now that the GISinternals GDAL is removed, the Gohlke GDAL 2.1.2 doesn't crash anymore and it now all works but it took some time for me to try this version again. Which was actually the 2nd part of the issue here.  I also got a small hiccup went l installed rasterio 0.36.0, but it of course needs Gohlke GDAL 2.0.2 so rasterio1.0a3 did the trick. I can also confirm that rasterstats 0.11.0 is needed (0.10.3 does not work).
It all seems logic now. I would like to thank you, @rbuffat @sgillies and @perrygeo, for dealing with this problem even though you shouldn't have. Thank you for being my listening board.
What still remains (and probably forever):
How did it work with Fiona 1.6.3 and GDAL2.0.2 before I updated? (rhetorical....)
Ciao.

Maybe Fiona 1.6.3 from Gohlke was patched with fixes from the fiona 1.7.0 dev branch to work with gdal 2.0. The filename Fiona-1.6.3+gdal200-cp27-none-win32.whl suggests something like this.


Support for Rails 4.2 ?

With the introduction of Active Job and #deliver_later in Rails 4.2, I get the following warning:
DEPRECATION WARNING: #deliver is deprecated and will be removed in Rails 5. Use #deliver_now to deliver immediately or #deliver_later to deliver through Active Job.
So far, emails still get through, but may be this is something that needs to be updated in the gem.
Many thanks.

Support for Rails 5 would be a more appropriate title as this is only warning that it will no longer work in Rails 5 so things are fine for now.  If you wouldn't mind submitting a PR updating the deprecation I'll merge to support Rails 5 otherwise this isn't a high priority for me at the moment.

Released version 1.0.0 using deliver_now to fix deprecation.

Well that was pretty fast! Thanks for updating. I was actually happy to give it a try myself, but, as I am not a programmer, it would have taken me much longer...


Version 8 cannot be build against net8.0

Version 8 does not support net8.0 anymore. I need to target net8.0 to be able to run unit tests. However when my ptoject targets also net8.0 I cannot upgrade library to version 8.

try 9.0-beta

would need to know your version of .net maui and what errors you are getting

I§m getting foloowing error"
Error	NU1202	Package Plugin.InAppBilling 8.0.4 is not compatible with net8.0 (.NETCoreApp,Version=v8.0). Package Plugin.InAppBilling 8.0.4 supports:

net8.0-android34.0 (.NETCoreApp,Version=v8.0)
net8.0-ios18.0 (.NETCoreApp,Version=v8.0)
net8.0-maccatalyst18.0 (.NETCoreApp,Version=v8.0)
net8.0-macos15.0 (.NETCoreApp,Version=v8.0)
net8.0-windows10.0.19041 (.NETCoreApp,Version=v8.0)	Custom	S:\four-part-harmony\Custom\Custom.csproj	1

I see the same error with 9.0.1-beta

NU1202: Package Plugin.InAppBilling 9.0.1-beta is not compatible with net8.0-ios17.5 (.NETCoreApp,Version=v8.0). Package Plugin.InAppBilling 9.0.1-beta supports:

net8.0-android34.0 (.NETCoreApp,Version=v8.0)
net8.0-ios18.0 (.NETCoreApp,Version=v8.0)
net8.0-maccatalyst18.0 (.NETCoreApp,Version=v8.0)
net8.0-macos15.0 (.NETCoreApp,Version=v8.0)
net8.0-windows10.0.19041 (.NETCoreApp,Version=v8.0)
NU1202: Package Plugin.InAppBilling 9.0.1-beta is not compatible with net8.0-ios17.5 (.NETCoreApp,Version=v8.0) / iossimulator-x64. Package Plugin.InAppBilling 9.0.1-beta supports:
net8.0-android34.0 (.NETCoreApp,Version=v8.0)
net8.0-ios18.0 (.NETCoreApp,Version=v8.0)
net8.0-maccatalyst18.0 (.NETCoreApp,Version=v8.0)
net8.0-macos15.0 (.NETCoreApp,Version=v8.0)
net8.0-windows10.0.19041 (.NETCoreApp,Version=v8.0)
NU1202: Package Plugin.InAppBilling 9.0.1-beta is not compatible with net8.0 (.NETCoreApp,Version=v8.0). Package Plugin.InAppBilling 9.0.1-beta supports:
net8.0-android34.0 (.NETCoreApp,Version=v8.0)
net8.0-ios18.0 (.NETCoreApp,Version=v8.0)
net8.0-maccatalyst18.0 (.NETCoreApp,Version=v8.0)
net8.0-macos15.0 (.NETCoreApp,Version=v8.0)
net8.0-windows10.0.19041 (.NETCoreApp,Version=v8.0)
Package restore failed. Rolling back package changes for 'TheApp'.

I experienced the same issue, and the error message is the same as vlasto77's.
Some additional information. The package is only added to target Android after installation.
<ItemGroup Condition="'$(TargetFramework)' == 'net8.0-android'">   <PackageReference Include="Plugin.InAppBilling">     <Version>8.0.4</Version>   </PackageReference> </ItemGroup>
If add the package manually in project file like below, above mentioned error message occurs.
<ItemGroup Condition="'$(TargetFramework)' == 'net8.0-ios'"> 	<PackageReference Include="Plugin.InAppBilling"> 		<Version>8.0.4</Version> 	</PackageReference> </ItemGroup>
The latest ios target framework is net8.0-ios17.5. And the message says it wants net8.0-ios18.0.

Same problem as @vlasto77, happens with 9.0-beta too. I notice that according to the information the NuGet Solution UI shows me, 7.1.3 says it has a dependency on ".NETStandard, Version=v2.0" but 8.0.0-beta and beyond do not (as well as depending on net8.0... rather than 6.0... ).
Why use a net8.0 platform (as opposed to, say. net8.0-android)? It's because that seems to be needed to persuade unit tests to work.

Plugin.InAppBilling 8.0.4 works in my project with
<TargetFrameworks>net8.0-android;net8.0-ios</TargetFrameworks>
No compilation errors.
My first test with sandbox account in iOS 18.0.1 is working.

Same problem as @vlasto77, any solution ?

If it helps, with 8.0.4 I see this at the developer command prompt:
PS > dotnet build .\DivisiBill\DivisiBill.csproj -c:Debug -f:net8.0
...\DivisiBill.csproj : warning NU1608: Detected package version outside of dependency constraint: Xamarin.AndroidX.Lifecycle.Process <IP_ADDRESS> requires Xamarin.AndroidX.Lifecycle.Runtime (>= <IP_ADDRESS> && < 2.7.1) but version Xamarin.AndroidX.Lifecycle.Runtime <IP_ADDRESS> was resolved.
...\DivisiBill.csproj : error NU1202:
  Package Plugin.InAppBilling 8.0.4 is not compatible with net8.0 (.NETCoreApp,Version=v8.0). Package Plugin.InAppBilling 8.0.4 supports:
    - net8.0-android34.0 (.NETCoreApp,Version=v8.0)
    - net8.0-ios18.0 (.NETCoreApp,Version=v8.0)
    - net8.0-maccatalyst18.0 (.NETCoreApp,Version=v8.0)
    - net8.0-macos15.0 (.NETCoreApp,Version=v8.0)
    - net8.0-windows10.0.19041 (.NETCoreApp,Version=v8.0)

With 7.1.3 it builds just fine.

would need to know your version of .net maui and what errors you are getting

Hi @jamesmontemagno! I guess most of us in this thread do not use .NET MAUI directly, but instead have a ".NET class library + Multiple platform-specific projects" setup with something like MvvmCross underneath and native UIs on each platform. This approach pushes most of the app's logic into the .NET class library project which is platform-agnostic.

@ivmirx gotcha gotcha, yeah there was a re-architecture for v8, but this should be doable... let me look at it.

Can you try 8.0.5-beta and let me know. This has the stub for net8.0 in there now like we used to have for netstandard and can be used in a .NET 8 class library

Can you try 8.0.5-beta and let me know. This has the stub for net8.0 in there now like we used to have for netstandard and can be used in a .NET 8 class library

Many thanks, it builds! I only had to replace billing.FinalizePurchaseAsync(purchase.PurchaseToken); with billing.FinalizePurchaseAsync(new[] { purchase.TransactionIdentifier }); for Android.

yay! i will push out a new 9.0 beta as well

I am using MAUI and it worked for me too, with the same update to FinalizePurchaseAsync. Though I did get the warning:
NU1608: Detected package version outside of dependency constraint: Xamarin.AndroidX.Lifecycle.Process <IP_ADDRESS> requires Xamarin.AndroidX.Lifecycle.Runtime (>= <IP_ADDRESS> && < 2.7.1) but version Xamarin.AndroidX.Lifecycle.Runtime 2.8.6 was resolved.

Yeah the nuget versions are a bit funky based on which service release you are using, but probably should be alright...
I actually request <IP_ADDRESS> in v8 in v9 i request 2.8.6 because these are the dependencies of billingclient.
Make sure you have the latest service release for .NET MAUI


nixos/syncoid: Delegate permissions to parent dataset if target is missing

This is to address a regression introduced in #131118. That was brought up in https://github.com/NixOS/nixpkgs/pull/131118#issuecomment-907790819
When syncing the first dataset, syncoid expects that the target dataset doesn't exist to have a clean slate to work with. So during
runtime we'll check if the target dataset does exist and if it doesn't - delegate the permissions to the parent dataset instead.
But then, on unallow, we do the unallow on both the target and the parent since the target dataset should have been created at this point, so the unallow can't know which dataset that got permissions just by which datasets exists.
These are parts of my unit files now:
ExecStartPre=-+/nix/store/0sy0xcwjv4i1j211fjjjnkig6d61inir-zfs-allow-zroot-home
ExecStopPost=-+/nix/store/c2xpiff3pz7xhnhlzvs3s6fs5fnxn7sk-zfs-unallow-zroot-home

Contents of these files:
### Content of /nix/store/0sy0xcwjv4i1j211fjjjnkig6d61inir-zfs-allow-zroot-home
#!/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash
# Here we explicitly use the booted system to guarantee the stable API needed by ZFS

# Run a ZFS list on the dataset to check if it exists
if '/run/booted-system/sw/bin/zfs' 'list' 'zroot/home'; then
  '/run/booted-system/sw/bin/zfs' 'allow' 'syncoid' 'bookmark,hold,send,snapshot,destroy' 'zroot/home'
else
  '/run/booted-system/sw/bin/zfs' 'allow' 'syncoid' 'bookmark,hold,send,snapshot,destroy' 'zroot'
fi

### Content of /nix/store/c2xpiff3pz7xhnhlzvs3s6fs5fnxn7sk-zfs-unallow-zroot-home
#!/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash
# Here we explicitly use the booted system to guarantee the stable API needed by ZFS
'/run/booted-system/sw/bin/zfs' 'unallow' 'syncoid' 'bookmark,hold,send,snapshot,destroy' 'zroot/home'
'/run/booted-system/sw/bin/zfs' 'unallow' 'syncoid' 'bookmark,hold,send,snapshot,destroy' 'zroot'

Motivation for this change
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[X] Fits CONTRIBUTING.md.

@ju1m Thanks for testing, I'll address your feedback this afternoon (about 8-9 hours from now, I hope), but in the meanwhile I'd want to ask a question for the unallow command, would it in your opinion be worth to run a zfs allow to look for permissions on the parent/child datasets to check if permissions exists before dropping them? Maybe look for the exact one we set to not run an unallow to permissions a user might have set?

@ju1m Thanks for testing, I'll address your feedback this afternoon (about 8-9 hours from now, I hope), but in the meanwhile I'd want to ask a question for the unallow command, would it in your opinion be worth to run a zfs allow to look for permissions on the parent/child datasets to check if permissions exists before dropping them? Maybe look for the exact one we set to not run an unallow to permissions a user might have set?

@etu, I would not bother with that because those permissions only concern cfg.user, which should be a dedicated user for syncoid, hence it's ok for me to assume that solely the syncoid module has to be in control of allowing/unallowing the permissions (which can now even be customized).
On that topic, I'm considering changing the syncoid module so that it uses DynamicUser= and enables to send the same dataset to multiple targets .

This breaks if you try to sync an entire pool, because builtins.dirOf returns ., which ZFS doesn't like. I think this can be fixed by only delegating to the target's parent, rather than both the source and the target. You can't target a pool root, so the target will always have a parent.

See #165204


add folder readme.md's

I want to document what each folder is and why it is there

This will also get rid of PLACEHOLDER files

added for the purpose of placeholders, I will make them nicer later


Simplify ingest Rundown to local Sofie environment

Simplify commands for convert.js
Possible to specify another studioId for upload script

The idea was the to make it as simple as possible. Personally, it would be nice not having to always specify the "intermediary" json file.
What do you think about adding the argument for the output.json as optional as well?

Okay, let's make both optional: the output path of convert.js, and the input for upload.sh. The default name should probably be something like converted-rundown.json, or converted.json. And please add that name to .gitignore so that it doesn't bother us when committing or doesn't get committed accidentally.

Updated the PR


[BUG] Unable to use tooltip from within a package

Bug description
When referencing the tooltip inside of a package an error is displayed that says:
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Check the render method of `RequestType`.
Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Check the render method of `OperatingRequest`.
    at createFiberFromTypeAndProps (http://localhost:3000/static/js/bundle.js:111968:25)
    at createFiberFromElement (http://localhost:3000/static/js/bundle.js:111991:19)
    at createChild (http://localhost:3000/static/js/bundle.js:102081:32)
    at reconcileChildrenArray (http://localhost:3000/static/js/bundle.js:102302:29)
    at reconcileChildFibers (http://localhost:3000/static/js/bundle.js:102634:18)
    at reconcileChildren (http://localhost:3000/static/js/bundle.js:105142:32)
    at updateHostComponent (http://localhost:3000/static/js/bundle.js:105690:7)
    at beginWork (http://localhost:3000/static/js/bundle.js:106920:18)
    at HTMLUnknownElement.callCallback (http://localhost:3000/static/js/bundle.js:93934:18)
    at Object.invokeGuardedCallbackDev (http://localhost:3000/static/js/bundle.js:93978:20)

It works as intended when I run the app (before being packaged) locally. If I remove the tooltip from the page then page loads as intended when navigating to that page within another app using the packaged version.
Version of Package
Latest and 5.12.0
To Reproduce
Create an app that has a tooltip and then bundle it as a package with react-tooltip as a dependency.
Create a new app and install the package and reference the package app with the tooltip.
Run the new app and navigate to the page from the package.
Expected behavior
Would expect to be able to load the page and hover over the element with the tooltip
Desktop (please complete the following information if possible or delete this section):

OS: Windows 10
Browser: Chrome
Version: Version 114.0.5735.199
Frameworks: React 17.0.2

If I remove the tooltip from the page then page loads as intended when navigating to that page within another app using the packaged version.

At first glance, this does not seem related to react-tooltip, but with your bundler's configuration. Have you tried bundling your first application without the tooltip just to make sure everything works as expected?
In case you've already tested that, and it seems it IS related to react-tooltip, I believe your steps to reproduce might not be clear enough.
What tools are you using to bundle the first application? The one with react-tooltip as the dependency.
Whenever you have the time, if you could provide a sample project (maybe easier to build 2 separate projects? not sure) it would help a lot.

Yes I have tested it without react-tooltip and then it works as it should. I've also added the tooltip on the app that has the package installed and it works in the app but not where it's referenced inside of the package.
I'm creating the package through the typescript compiler and a mix of moving files for stylesheets into a dist directory from the scripts in my package.json
scripts: {
...
"bundle": "rimraf dist && tsc && npm run copy",
"copy": "copyfiles package.json dist && copyfiles tsconfig.json dist && copyfiles ./src/Styles/** dist",
...
}

I'm running npm run bundle and then npm pack ./dist to create my package.
I'll see if I can create a sample project for it but it will probably have to wait until the weekend.

Not a problem.
Until then, if i get the time I might try to reproduce it.

@JurajKavka if you have the time, can you please test the following.
Manually edit the "main" key on the node_modules/react-tooltip/package.json file:
// node_modules/react-tooltip/package.json
{
  ...
  // old value
  // "main": "dist/react-tooltip.min.cjs",
  "main": "dist/react-tooltip.min.mjs",
  ...
}

Hopefully .mjs doesn't have the same problem.

This is working for me (i had to change also "exports")
 "main": "dist/react-tooltip.min.mjs",
  "module": "dist/react-tooltip.min.mjs",
  "exports": {
    ".": {
      "types": "./dist/react-tooltip.d.ts",
      "require": "./dist/react-tooltip.min.mjs",
      "import": "./dist/react-tooltip.min.mjs",
      "default": "./dist/react-tooltip.min.mjs"
    },
    "./dist/react-tooltip": "./dist/react-tooltip.min.mjs",
    "./dist/react-tooltip.css": "./dist/react-tooltip.min.css",
    "./dist/react-tooltip.d.ts": "./dist/react-tooltip.d.ts",
    "./package.json": "./package.json"
  },

Thanks @JurajKavka
We'll add a troubleshooting section with some tips to workaround this (since updating the package will override the changes).
Since we're not currently planning to make any changes to the default package.json, and to our dist files in general, we'll leave this open until we can figure out a cleaner workaround, or until its fixed by the create-react-app guys.

The have at least 5 PRs adding the support for cjs files.. all opened and as old as one year :smile:


chequebook deployment

Adds chequebook deployment and initial top-up.
Added features:

On startup the node checks if a chequebook has been previously deployed otherwise it will deploy one. If --swap-initial-deposit is specified with a non-0 value it will also transfer bzz token from the overlay to the new chequebook.
Adds a temporary --swap-enable flag so integration tests don't break instantly due to lack of blockchain backend. With the flag a working blockchain connection and funds to deploy the chequebook are necessary for starting the node.
The bytecode of the supplied factory is verified and your own chequebook is verified against it.
Signer interface has been extended with a SignTx function.
As there are no hard-coded factories at the moment, factory addresses need to be passed with --swap-factory-address for all networks. For goerli this is 0xc5a26Fc99B40C7fe3174D9311Aa803e88be78c73. A factory can be setup on a local ganache with the script from here, this will also output the environment variables you can use to configure bee.

Unit tests are still missing.

Thanks for this PR!
My findings:
Good:

The node doesn't boot up without Gorli Eth
The node boots up after funding my address with Gorli Eth and creates chequebook
The node recognizes that a chequebook was already deployed when restarting

Still some problems:

I can pass -swap-initial-deposit, even without having BZZ tokens on my Gorli address. No log, no error
If I pass swap-initial-deposit after having BZZ tokens (I believe @rpicc funded my account, I don't get a feedback from the logs that my chequebook was funded.

To me, it seems as if my account doesn't have BZZ (basing myself on Etherscan). In this case, an error log is missing that deposit is failing. I could not try out the case where deposit is succeeding, as I don't have BZZ yet
My chequebook

swap-initial-deposit only does something when initially deploying the chequebook. On further runs it is ignored. To deploy a new chequebook (with initial deposit) you have to delete the state store first.


Lookups in RUFF_ALIASES use the wrong key, do not get converted.

the RUFF_ALIASES dictionary looks like:
"C0103": {"N815"},
    "C0112": {"D419"},

where the keys are not prefaced with PL.
The lookup in get_ruff_equivalent_codes is using the wrong key to search and so no rules are created from RUFF_ALIASES. The lines around 30-31 should be:

        if m.code in RUFF_ALIASES:
            return RUFF_ALIASES[m.code]

This will map, for example C0411 properly to I001 for wrong-import-order
Similarly the update_ruff_aliases.py hasn't been run in a while. I will make a PR to address these two issues.

Closed via #9