Provide easier method to get latest version of devcon

The instructions referenced in the README to get a version of devcon which supports Windows Vista and later are a significant inconvenience.  They require downloading a ~650MB ISO file, mounting it, running an installer and/or extracting the required file from the installer cab all for a <1MB exe file.  It would be highly preferable to provide a link to a direct download of the file (particularly from Microsoft) or to host this file ourselves.  However, the license terms on the WDK do not allow us to do distribution.
Anyone interested in making this process easier should contact Microsoft to request that they either host the new version of devcon (possibly by updating KB311272) or allow third parties to redistribute this file.

Thanks @avluis!  Those methods are definitely a lot better than downloading the ISO.  I'll update the docs (and perhaps implement in the script) using one of those methods when I get a chance.


Fetch Aeroplanes Data and Display on Homepage

In this PR I fetched aeroplanes data from the backend API and displayed it in the homepage.
Below are the highlights

Diplay a carousel of all planes in the database
Display buttons for scrolling to the left or right to view all the planes
Display a link to the details page for each specific plane

Cheers and Happy Reviewing!

Hello @sharon-odhiambo ,
The Homepage looks amazing, I dig the button's functionality, great work there! But It looks like there are a couple of issues.
The Page doesn't fetch when refreshed, If I want to fetch the data I need go to another route and come back. Kindly add a way of fetching on page load.
You can see there is a Gap on the right side. If it was on purpose, it still looks like it was cut off to me.

Here the page overlaps with the mobile navigation

The component Aeroplanes should go inside the div with the className of 'main' in the App component for styling purposes. It might solve the mobile navigation overlap problem but if it doesn't I'll help you with it.
function App() {   return (
       <Navbar />

Hello World

   ); }
should be
function App() {   return (     <BrowserRouter>       <Navbar />
         <Routes>           <Route path="/" element={<Aeroplanes />} />         </Routes>
     </BrowserRouter>   ); }

Hi @Berkay-akbas , thank you for the review.


ConstraintAnalysis: add matchCount() or matchesSize()

But don't add it to the json serialization, as it can be derived from the matches.
Convenience methods for POC building to print to System.out etc.
Also consider, easily finding:

the constraint weight
the match weight
the impact weigh (= constraint weigh * match weight)

Fail fast if matches are null (= not fetched)?

Fail fast if matches are null (= not fetched)?

We have a flag, analyzeConstraintMatches, that can cause the InnerScoreDirector#getConstraintAnalysis to set matches to null. So, failing fast could potentially cause existing code to break, e.g., SolutionManager#analyze.

Fail fast if matches are null (= not fetched)?

We have a flag, analyzeConstraintMatches, that can cause the InnerScoreDirector#getConstraintAnalysis to set matches to null. So, failing fast could potentially cause existing code to break, e.g., SolutionManager#analyze.

That depends on where the fail fast is. I think no issue will occur if the fail fast occurs in matchCount() and matchesSize() (provided these new methods are not called).

Fail fast if matches are null (= not fetched)?

We have a flag, analyzeConstraintMatches, that can cause the InnerScoreDirector#getConstraintAnalysis to set matches to null. So, failing fast could potentially cause existing code to break, e.g., SolutionManager#analyze.

That depends on where the fail fast is. I think no issue will occur if the fail fast occurs in matchCount() and matchesSize() (provided these new methods are not called).

That's correct. @ge0ffrey, did you mean "failing fast" with the new method?

Aren't we just moving the same problem on a lower level now? In order to call matchCount, you need to know if it will or will not throw an exception - and in this case, you don't even have a way to find out.
In my opinion, returning -1 or something like that is a better approach.

Aren't we just moving the same problem on a lower level now? In order to call matchCount, you need to know if it will or will not throw an exception - and in this case, you don't even have a way to find out.
In my opinion, returning -1 or something like that is a better approach.

I prefer exception compared to returning -1. It suppose to fail hard so users know what to fix. The problem that @zepfred alluded to is SolutionManager.analyze too eagerly fail fasting because matches is null.

Yes, only scoreAnalysis.matchCount() should throw an exception if matches weren't fetched. SolutionManager.analyse() should still work.
Similarly, ScoreAnalysis.toString() or getSummary() should always work, but it has the top 3 matches per constraint only if matches were fetched.


Only show options for PDFs [normalize fields, etc] when someone uploads a PDF

It should be possible to walk the DOM and identify the files that are uploaded. Here's some code that works with the file upload input already that might help us out:
https://github.com/SuffolkLITLab/docassemble-MotionToStayEviction/blob/main/docassemble/MotionToStayEviction/data/static/limit_upload_size.js

var has_pdf_field = function ( ) {
    var $dafiles = $(".dafile");

    if ($dafiles) {
        files = $dafiles[0].files

        var has_pdf = false;
        for (var i=0; i<files.length; i++) {
            if (files[i].type === "application/pdf") {
                has_pdf = true;
                break;
            }
        }
    }
    return has_pdf
}


fixed a problem with seri log now logs are working fine in any class

Hi mukesh,
First of all thanks for an awsome project,
there was a problem i faced that for some reason logging was not working in this project (seri log) so i have added a fix and now it's working fine in all classes.
Regards

Hi @iammukeshm  can you please look at this when you get a chance thanks

Thanks a lot!
I am currently working on a newer version of this project with much more stuff.
Do Checkout - https://github.com/fullstackhero/dotnet-webapi-boilerplate
Regards

Sure :) thank you


Favicon

We should add the Kubeapps icon as favicon for the hub.

@Angelmmiguel will take this one


Nuxt Link does not scroll to top on new page...

Environment

Operating System: Darwin
Node Version:     v19.1.0
Nuxt Version:     3.1.1
Nitro Version:    2.1.0
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      runtimeConfig, pages, modules, plugins, build, googleFonts, i18n, strapi, vite
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
Simply add normal <NuxtLink :to"newPage"></NuxtLink> or in my situation with i18n :
<NuxtLink :to="localePath({ name: newPage })"></NuxtLink>
Describe the bug
Hi,
I know this was already added in bugs, but none of solutions I found here worked for me...
When clicking a classical NuxtLink, page does not scroll to top.
Solutions I found and tried but not working :
Plugin use : /plugins/router.ts
import { defineNuxtPlugin } from "#app";

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.$router.options.scrollBehavior = () => {
    return { left: 0, top: 0 };
  };
});

Middleware use : /middleware/route.global.ts
export default defineNuxtRouteMiddleware((to, from) => {
  useNuxtApp().hook("page:finish", () => {
    if (history.state.scroll) {
      setTimeout(() => window.scrollTo(history.state.scroll), 0);
    } else {
      setTimeout(() => window.scrollTo(0, 0), 0);
    }
  });
});

And finally router options use : /app/router.options.ts
import type { RouterConfig } from "@nuxt/schema";

export default <RouterConfig>{
  scrollBehavior(to, _from, savedPosition) {
    return new Promise((resolve, _reject) => {
      setTimeout(() => {
        if (savedPosition) {
          resolve(savedPosition);
        } else {
          if (to.hash) {
            resolve({
              el: to.hash,
              top: 80,
            });
          } else {
            resolve({ top: 0 });
          }
        }
      }, 100);
    });
  },
};

or :
import type { RouterOptions } from "@nuxt/schema";

export default <RouterOptions>{
  scrollBehavior(to, from, savedPosition) {
    if (savedPosition) {
      return savedPosition;
    } else {
      return {
        top: 0,
        behavior: "smooth",
      };
    }
    return { top: 0 };
  },
};

Non of these solutions are working and page never goes top after nuxt link click.
Additional context
No response
Logs
No response

Hi, any help on this pls?
Here is my package.json file, if could help:
{
  "private": true,
  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "nuxt preview",
    "postinstall": "nuxt prepare"
  },
  "devDependencies": {
    "@nuxtjs/google-fonts": "^3.0.0-1",
    "@nuxtjs/i18n": "^8.0.0-beta.9",
    "@nuxtjs/strapi": "^1.7.1",
    "@nuxtjs/tailwindcss": "^6.3.0",
    "@tailwindcss/forms": "^0.5.3",
    "@tailwindcss/typography": "^0.5.9",
    "@types/markdown-it": "^12.2.3",
    "markdown-it": "^13.0.1",
    "nuxt": "npm:nuxt3@latest"
  },
  "dependencies": {
    "@nuxtjs/markdownit": "^2.0.0",
    "daisyui": "^2.49.0",
    "vue-agile": "^2.0.0",
    "vue-easy-lightbox": "^1.12.0",
    "vue-recaptcha": "^2.0.3",
    "vue3-google-map": "^0.15.0"
  }
}

I think this is mentioned in the docs, with a link to a workaround: https://nuxt.com/docs/migration/component-options#scrolltotop

your last option is working for me:
import type { RouterConfig } from "@nuxt/schema"

export default <RouterConfig>{
    scrollBehavior(to, from, savedPosition) {
        if (savedPosition) {
            return savedPosition;
        } else {
            return {
                top: 0
            };
        }
    }
}

can you reproduce the problem in a fresh nuxt3 install?

Hi, thanks for your answer but still not working.

can you reproduce the problem in a fresh nuxt3 install? that might help you to narrow down the problem.

can confirm this a issue all nuxt3 sites.   using vue telescope i found a few.   open a new tab then scroll to top as soon as you can,  you will it it jumps back up.
https://smartdogcollar.com/
https://dih.telekom.com/en
https://paladium-pvp.fr/
though i think this is being fixed here
https://github.com/nuxt/nuxt/issues/19664

It'd be great if someone could attach a StackBlitz or CodeSandbox as reproduction 👍🏻

@manniL I am not convinced this would be easily reproducible on stack blitz,  for me this issue is most prominent on new tabs and fast loads.    stackblitz has its own little deploy loader and is a lot slower.

For me does not work neither.

For me does not work neither.

See my comment above please ☺

Also, besides a minimal reproduction, please mention the browser / os you're experiencing the issue in :pray: I think there could potentially be differences between browsers in scrolling behavior.

I also experienced this issue on https://movies.nuxt.space/ also where I tried to click on the movie and the position of the screen does not reset to top, it statyed on where I clicked.
https://github.com/nuxt/nuxt/assets/39415776/785580c5-9c50-4d25-983c-9e97f8809df3
System: MacOS Ventura 13.3.1
Browser: Brave v1.51.118 (Chromium to 113.0.5672.126)

I found this code on nuxt/movies. I hope it help.
https://github.com/nuxt/movies/commit/20a859bd14d5d80673ea03722aa46ad72d24abe6

I found this code on nuxt/movies. I hope it help.
nuxt/movies@20a859b

I have this problem too, but in my case 'page:transition:finished' didn't fix the problem, but 'page:finished' did
I wrote next plugin which scrolls page to top. It simulates definePageMeta({ scrollToTop: true }) behaviour.
So all is you need is to install this plugin and use definePageMeta as usual.
In some case,  you can change hook to transition (which is not works for me but may be for you), or set similar code on different hooks
// scroll.client.ts
export default defineNuxtPlugin({
  name: 'scroll-client',
  hooks: {
    'page:finish': () => {
      if (!useRouter().currentRoute.value.meta.scrollToTop)
        return

      document.scrollingElement?.scrollTo({ left: 0, top: 0 })
      document.body?.scrollTo({ left: 0, top: 0 })
    },
  },
})

I don't really expected that Nuxt will be such broken :(

Hope that 3.6.0 will release as soon as possible, because as I understand definePageMeta is fixed there

https://github.com/nuxt/nuxt/issues/19239#issuecomment-1564551022
This helped me

Happens to me too

CSS scroll-behavior: smooth; Can cuse this behavior

If you are encountering this, please let me know with a minimal reproduction and I'll happily reopen and investigate. 🙏

@danielroe this issue does seem to be an issue when the CSS for smooth-scrolling is set:
html { scroll-behavior:smooth; }
If you set this, it causes NuxtLink to do weird things on new routes, setting the scroll depth of the resulting page to the value of the originating page.  I really think Nuxt should fix this issue as it causes a serious usability problem.  I've looked at this problem on various sites since Nuxt 2.0 and didn't realize the problem was so basic.
Thank you @fos7er for the insight!

holy christ, yes. I just spent forever trying to fix this and this thread is the one that finally clued me in on the scroll-behavior: smooth issue. It's bad.
@danielroe here's a minimal reproduction in stackblitz: https://stackblitz.com/edit/nuxt-starter-4f9fpe?file=app.vue It doesn't seem to happen in Chrome, but it definitely hoses Firefox. Here's what it looks like for me:
https://github.com/nuxt/nuxt/assets/6187555/124b872f-1bd3-4e76-8311-e8462587b99b

@Chalks Would you open a new issue, and first check whether it's reproducible without Nuxt (i.e. an upstream vue-router issue?)
https://stackblitz.com/github/nuxt-contrib/vue3-ssr-starter

Done. I think there's an easy fix though, so I'll open a PR shortly as well.


Use root to run titus-metatrond, not the image's USER

Starting the metatron-sync service was failing with:
"exec: \"/titus/metatron/bin/titus-metatrond\": stat /titus/metatron/bin/titus-metatrond: permission denied"

This is because runc exec will use the USER value of the container's image if it's set, rather than always running as root.

Pull Request Test Coverage Report for Build 3004

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 25.981%

Totals

Change from base Build 2984:
0.0%

Covered Lines:
3000

Relevant Lines:
11547

💛  - Coveralls


Nextjs AdvancedRealTimeChart error with redirects

Bug Description
The graph opens on top of the entire application, and breaks the entire page in nextjs projects
Steps to Reproduce

Create next project using next v12.1.5 or next v13.2.4
Create 2 page with redirect between them
Integrate AdvancedRealTimeChart widget v1.0.12 or v1.0.14 (didn't try other versions) on first page
Throttle your network speed to low
Be on page 2 (which is without a chart), quickly switch to the page with a chart and go back instantly by clicking on the redirect button. An error occurred

Additional Context
Video with error
error.webm

Can you share code/repo?

Yeah, sure https://github.com/Doberman2029/react-ts-tradingview-widgets-error
To reproduce it is important to slow down the speed of the Internet. And you need to switch from the page with the chart instantly, while, as I understand it, the data for the chart is being loaded

@JorrinKievit Hey Jorrin. Do you have some news about problem?

Nope, haven't had the time to look into it.

Hello, Jorrin. Haven't been able to see the issue yet?

I have, but to be honest i have no idea on how to fix it yet. It's quite time consuming too to debug external behaviour of iframes. I dont wanna come across as mean, but if you have the time please feel free to clone and see if you can figure it out ;D

I tried to fix. But also no result :)

Ye it for sure is an interesting one, ill take a look again this weekend but don't keep your hopes up haha

Hoped to fix it with the fix i just did for the other issue, but no luck :(. To be honest i have no idea what is happening haha

I think the problem is that if the widget gets data after leaving the page with the widget it tries to rerender itself. But since he no longer sees the container with the given id it's drawn on the entire page and breaks it


Investigate ways to enable IDE autocomplete process for generated code

Problem
People complain that they don't have code completion when writing tests with marine_test macro. Can we do something to enable auto-completion in IDE? The answer is yes.
Possible solution
Right now code is generated by procedural macros. I didn't find methods to enable auto-completion from them, but we can use a different approach: generate definitions in cargo build scripts. CLion and VS Code support code completion for names from files generated by cargo build scripts.
Cargo build scripts
This is typically a build.rs file on the same level as Config.toml and the src folder. It executes before build and it can write files in the directory specified in the OUT_DIR environment variable, read files anywhere. If the build script generated a file, say, some_generated_file.rs in OUT_DIR, it can be included in the project by writing in some file the following line:
include!(concat!(env!("OUT_DIR"), "/some_generated_file.rs"));

Then code in this file will have access to any names defined in some_generated_file.rs. But there is some more to do to enable auto-completion for  names from some_generated_file.rs:
CLion

in the Help -> Actions -> Experimental Futures enable org.rust.cargo.evaluate.build.scripts
refresh cargo project in order to update generated code: change Cargo.toml and build from IDE or press Refresh Cargo Project in Cargo tab.

VS Code

install rust-analyzer plugin
change Cargo.toml to let plugin update code from generated files

What to do

find a good way to use build scripts for generating definitions
discuss it
implement it

it would be awesome, it is one of productivity blockers in are for rust coding.


fix inability of loading the settings menu

fix #1

ah small mistake, we should probably remove the following line:
// Show the menu now after installing the extension
        menuSelected(null);

Now it shows the settings panel every time Burp loads a project   😅


Starting screen setting does not effect "Browse" and "History"

Steps to reproduce
Change your starting screen to "Manga"
Expected behavior
Browse and History should inherit the default library type
Actual behavior

Go to "Updates" - it now defaults to "Manga" since it is your starting screen
Go to "Browse" and "History" - These do not default to manga.

Crash logs
No response
Aniyomi version
<IP_ADDRESS>
Android version
Android 14
Device
Google Pixel 8 Pro
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an official extension, I should be opening an issue in the extensions repository.
[X] If this is an issue with an official manga extension and this issue can be replicated in the Tachiyomi app, that I should be opening an issue in Tachiyomi's extensions repository.
[X] I have gone through the FAQ and troubleshooting guide.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

Ohh a good one, will be useful.


Release v4.0.5 needs ES6 modules syntax?

During my build I'm getting:
/usr/src/app/node_modules/type-detect/index.js:49
export default function typeDetect(obj) {
^^^^^^

SyntaxError: Unexpected token export
    at createScript (vm.js:74:10)
    at Object.runInThisContext (vm.js:116:10)
    at Module._compile (module.js:533:28)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)

It's intentional? Because it seems like huge change, not a minor patch – v4.0.3 used old module syntax.

Could you tell me are you actually using type-detect 4.0.5? It works fine for me on fresh installs in both yarn and npm. Are you using a build system?

I'm using chai 4.1.2 with node 6.12.0. type-detect 4.0.4 and I have this error too.

@amiram please update to type-detect 4.0.5.

I'm not explicitly using type-detect, just chai 4.1.2, and am having this same issue

Could you please try npm i -D<EMAIL_ADDRESS>to see if it fixes the problem.

@keithamus ran that command. problem persists

@Mattenable please try npm rm chai; npm i -D<EMAIL_ADDRESS>

no luck. I'll try to come up with a simple test to share

4.0.5 is working. You have to delete chai and type-detect folders from node_modules and install chai again

@keithamus I made this:
https://github.com/Mattenable/chaitest
Just clone, npm install, npm run test

Hello @Mattenable I tried to reproduce with your repo
I got this:

My package-lock.json
{
  "name": "chaitest",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "assertion-error": {
      "version": "1.0.2",
      "resolved": "https://registry.npmjs.org/assertion-error/-/assertion-error-1.0.2.tgz",
      "integrity": "sha1-E8pRXYYgbaC6xm6DTdOX2HWBCUw=",
      "dev": true
    },
    "balanced-match": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.0.tgz",
      "integrity": "sha1-ibTRmasr7kneFk6gK4nORi1xt2c=",
      "dev": true
    },
    "brace-expansion": {
      "version": "1.1.8",
      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.8.tgz",
      "integrity": "sha1-wHshHHyVLsH479Uad+8NHTmQopI=",
      "dev": true,
      "requires": {
        "balanced-match": "1.0.0",
        "concat-map": "0.0.1"
      }
    },
    "browser-stdout": {
      "version": "1.3.0",
      "resolved": "https://registry.npmjs.org/browser-stdout/-/browser-stdout-1.3.0.tgz",
      "integrity": "sha1-81HTKWnTL6XXpVZxVCY9korjvR8=",
      "dev": true
    },
    "chai": {
      "version": "4.1.2",
      "resolved": "https://registry.npmjs.org/chai/-/chai-4.1.2.tgz",
      "integrity": "sha1-D2RYS6ZC8PKs4oBiefTwbKI61zw=",
      "dev": true,
      "requires": {
        "assertion-error": "1.0.2",
        "check-error": "1.0.2",
        "deep-eql": "3.0.1",
        "get-func-name": "2.0.0",
        "pathval": "1.1.0",
        "type-detect": "4.0.5"
      }
    },
    "check-error": {
      "version": "1.0.2",
      "resolved": "https://registry.npmjs.org/check-error/-/check-error-1.0.2.tgz",
      "integrity": "sha1-V00xLt2Iu13YkS6Sht1sCu1KrII=",
      "dev": true
    },
    "commander": {
      "version": "2.11.0",
      "resolved": "https://registry.npmjs.org/commander/-/commander-2.11.0.tgz",
      "integrity": "sha512-b0553uYA5YAEGgyYIGYROzKQ7X5RAqedkfjiZxwi0kL1g3bOaBNNZfYkzt/CL0umgD5wc9Jec2FbB98CjkMRvQ==",
      "dev": true
    },
    "concat-map": {
      "version": "0.0.1",
      "resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz",
      "integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=",
      "dev": true
    },
    "debug": {
      "version": "3.1.0",
      "resolved": "https://registry.npmjs.org/debug/-/debug-3.1.0.tgz",
      "integrity": "sha512-OX8XqP7/1a9cqkxYw2yXss15f26NKWBpDXQd0/uK/KPqdQhxbPa994hnzjcE2VqQpDslf55723cKPUOGSmMY3g==",
      "dev": true,
      "requires": {
        "ms": "2.0.0"
      }
    },
    "deep-eql": {
      "version": "3.0.1",
      "resolved": "https://registry.npmjs.org/deep-eql/-/deep-eql-3.0.1.tgz",
      "integrity": "sha512-+QeIQyN5ZuO+3Uk5DYh6/1eKO0m0YmJFGNmFHGACpf1ClL1nmlV/p4gNgbl2pJGxgXb4faqo6UE+M5ACEMyVcw==",
      "dev": true,
      "requires": {
        "type-detect": "4.0.5"
      }
    },
    "diff": {
      "version": "3.3.1",
      "resolved": "https://registry.npmjs.org/diff/-/diff-3.3.1.tgz",
      "integrity": "sha512-MKPHZDMB0o6yHyDryUOScqZibp914ksXwAMYMTHj6KO8UeKsRYNJD3oNCKjTqZon+V488P7N/HzXF8t7ZR95ww==",
      "dev": true
    },
    "escape-string-regexp": {
      "version": "1.0.5",
      "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz",
      "integrity": "sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=",
      "dev": true
    },
    "fs.realpath": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz",
      "integrity": "sha1-FQStJSMVjKpA20onh8sBQRmU6k8=",
      "dev": true
    },
    "get-func-name": {
      "version": "2.0.0",
      "resolved": "https://registry.npmjs.org/get-func-name/-/get-func-name-2.0.0.tgz",
      "integrity": "sha1-6td0q+5y4gQJQzoGY2YCPdaIekE=",
      "dev": true
    },
    "glob": {
      "version": "7.1.2",
      "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
      "integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
      "dev": true,
      "requires": {
        "fs.realpath": "1.0.0",
        "inflight": "1.0.6",
        "inherits": "2.0.3",
        "minimatch": "3.0.4",
        "once": "1.4.0",
        "path-is-absolute": "1.0.1"
      }
    },
    "growl": {
      "version": "1.10.3",
      "resolved": "https://registry.npmjs.org/growl/-/growl-1.10.3.tgz",
      "integrity": "sha512-hKlsbA5Vu3xsh1Cg3J7jSmX/WaW6A5oBeqzM88oNbCRQFz+zUaXm6yxS4RVytp1scBoJzSYl4YAEOQIt6O8V1Q==",
      "dev": true
    },
    "has-flag": {
      "version": "2.0.0",
      "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-2.0.0.tgz",
      "integrity": "sha1-6CB68cx7MNRGzHC3NLXovhj4jVE=",
      "dev": true
    },
    "he": {
      "version": "1.1.1",
      "resolved": "https://registry.npmjs.org/he/-/he-1.1.1.tgz",
      "integrity": "sha1-k0EP0hsAlzUVH4howvJx80J+I/0=",
      "dev": true
    },
    "inflight": {
      "version": "1.0.6",
      "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz",
      "integrity": "sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=",
      "dev": true,
      "requires": {
        "once": "1.4.0",
        "wrappy": "1.0.2"
      }
    },
    "inherits": {
      "version": "2.0.3",
      "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz",
      "integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=",
      "dev": true
    },
    "minimatch": {
      "version": "3.0.4",
      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz",
      "integrity": "sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==",
      "dev": true,
      "requires": {
        "brace-expansion": "1.1.8"
      }
    },
    "minimist": {
      "version": "0.0.8",
      "resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.8.tgz",
      "integrity": "sha1-hX/Kv8M5fSYluCKCYuhqp6ARsF0=",
      "dev": true
    },
    "mkdirp": {
      "version": "0.5.1",
      "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.1.tgz",
      "integrity": "sha1-MAV0OOrGz3+MR2fzhkjWaX11yQM=",
      "dev": true,
      "requires": {
        "minimist": "0.0.8"
      }
    },
    "mocha": {
      "version": "4.0.1",
      "resolved": "https://registry.npmjs.org/mocha/-/mocha-4.0.1.tgz",
      "integrity": "sha512-evDmhkoA+cBNiQQQdSKZa2b9+W2mpLoj50367lhy+Klnx9OV8XlCIhigUnn1gaTFLQCa0kdNhEGDr0hCXOQFDw==",
      "dev": true,
      "requires": {
        "browser-stdout": "1.3.0",
        "commander": "2.11.0",
        "debug": "3.1.0",
        "diff": "3.3.1",
        "escape-string-regexp": "1.0.5",
        "glob": "7.1.2",
        "growl": "1.10.3",
        "he": "1.1.1",
        "mkdirp": "0.5.1",
        "supports-color": "4.4.0"
      }
    },
    "ms": {
      "version": "2.0.0",
      "resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz",
      "integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=",
      "dev": true
    },
    "once": {
      "version": "1.4.0",
      "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz",
      "integrity": "sha1-WDsap3WWHUsROsF9nFC6753Xa9E=",
      "dev": true,
      "requires": {
        "wrappy": "1.0.2"
      }
    },
    "path-is-absolute": {
      "version": "1.0.1",
      "resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz",
      "integrity": "sha1-F0uSaHNVNP+8es5r9TpanhtcX18=",
      "dev": true
    },
    "pathval": {
      "version": "1.1.0",
      "resolved": "https://registry.npmjs.org/pathval/-/pathval-1.1.0.tgz",
      "integrity": "sha1-uULm1L3mUwBe9rcTYd74cn0GReA=",
      "dev": true
    },
    "supports-color": {
      "version": "4.4.0",
      "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-4.4.0.tgz",
      "integrity": "sha512-rKC3+DyXWgK0ZLKwmRsrkyHVZAjNkfzeehuFWdGGcqGDTZFH73+RH6S/RDAAxl9GusSjZSUWYLmT9N5pzXFOXQ==",
      "dev": true,
      "requires": {
        "has-flag": "2.0.0"
      }
    },
    "type-detect": {
      "version": "4.0.5",
      "resolved": "https://registry.npmjs.org/type-detect/-/type-detect-4.0.5.tgz",
      "integrity": "sha512-N9IvkQslUGYGC24RkJk1ba99foK6TkwC2FHAEBlQFBP0RxQZS8ZpJuAZcwiY/w9ZJHFQb1aOXBI60OdxhTrwEQ==",
      "dev": true
    },
    "wrappy": {
      "version": "1.0.2",
      "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
      "integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=",
      "dev": true
    }
  }
}

I'm running node 6. do I need to update to 8 to use this package?

No, type-detect should work with node >= 4

@Mattenable if you have a package-lock.json you'll need to run npm rm chai and maybe npm rm type-detect to clear it out of your lockfile. In a few hours we'll release<EMAIL_ADDRESS>which will absolutely fix the issue, so if you can wait just a few hours we'll have this fixed.

BTW I have unpublished 4.0.4 (the irony of which is not lost on me)
npm i<EMAIL_ADDRESS>
npm ERR! code ETARGET
npm ERR! notarget No matching version found for<EMAIL_ADDRESS>npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

lol
I did notice, however, that chai 4.1.2 is pulling down type-detect 4.0.4 instead of 4.0.5. I think this is an issue with my organization's internal nexus repo :( when i npm set registry=https://registry.npmjs.org/ everything works. Sorry for the trouble

@keithamus @vieiralucas Thanks for handling this crisis so quickly. Sorry I can't be of much help during business hours.

That was mostly @keithamus by the way.
I was here just responding issues while he was fighting travis. 😸

I'm going to close this issue; I'm pretty sure we've resolved this. If anyone else has any issues please feel free to comment (or raise a new issue) and we can look into it.


Exporting a method with a different name drops the default parameters

Compiler version
Scala 3.3.1
Minimized code
case class Foo(bar: String, baz: Int)
object Foo:
  def withDefaults(bar: String = "", baz: Int = 0) = Foo(bar, baz)

object Test1:
  export Foo.withDefaults

object Test2:
  export Foo.withDefaults as fooWithDefaults

// this works
Test1.withDefaults("test1")

// this doesn't work
Test2.fooWithDefaults("test2")

Output
val res0: Foo = Foo(test1,0)
-- [E171] Type Error: ----------------------------------------------------------
1 |Test2.fooWithDefaults("test2")
  |^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |missing argument for parameter baz of method fooWithDefaults in object Test2: (bar: String, baz: Int): Foo
1 error found

Expectation
Same behavior as Test1, renaming should have no effect on the default values of the methods.
I did't find any mention of this in the documentation so, I don't know if this is a design choice to avoid collisions and other problems or it's a bug.

this is definitely a bug, here is output with -Xprint:typer flag:
final lazy module val Test2: Test2 = new Test2()
    final module class Test2() extends Object() { this: Test2.type =>
      export Foo.{withDefaults as fooWithDefaults}
      final def fooWithDefaults(bar: String, baz: Int): Foo =
        Foo.withDefaults(bar, baz)
      final def withDefaults$default$1: String @uncheckedVariance =
        Foo.withDefaults$default$1
      final def withDefaults$default$2: Int @uncheckedVariance =
        Foo.withDefaults$default$2
    }

We've noticed the same problem in Besom on Monday where we export methods from internals to the public API. Defaults are gone after the export, even method signature hint from PC shows there are no defaults.

So it seems export is currently dropping modifier (like infix), annotations, and also default parameters.
When we are thinking about language feature interaction, we should really consider better coverage for future language improvements.

Slightly related https://github.com/scala/scala3/issues/17930 links to the recent fix for flags.
The PR is just for the bug in renaming.
Now that bishabosha is moving on from Scala Center, minions must step up.


fix: typeahead in demo

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


i18n(App) update with latest language file changes

Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] language translations

Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[ ] I have run npm run test to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Notes
I would appreciate it if you could add the hacktoberfest tag to the project or the hacktoberfest-accepted tag to this PR if you are ok with that.
thanks

thanks for accepting. do you have any comment on the hacktoberfest labels?

@knolleary, asking one last time if you can add the hacktoberfest label to the project or hactoberfest-accepted tag to this PR. Thanks.


"Reserve" stock

Reserved stock cannot be allocated to a build
Perhaps a 'reserved' tag for a StockLocation prevents parts being taken?

This has now been implemented but in a slightly different name


Windows vs POSIX

When creating a new baseline on a Windows OS machine using vendor/bin/phpstan analyze  --configuration=core/phpstan.neon.dist --generate-baseline ./core/phpstan-baseline.neon on drupal/core with (at least) 1.1.16 I get this suppression:
		-
			message: "#^File core/modules/system/tests/modules/entity_test\\\\entity_test\\.inc could not be loaded from Drupal\\\\Core\\\\Extension\\\\ModuleHandlerInterface\\:\\:loadInclude$#"
			count: 2
			path: modules/system/tests/modules/entity_test/entity_test.install

on a POSIX machine I get:
		-
			message: "#^File core/modules/system/tests/modules/entity_test/entity_test\\.inc could not be loaded from Drupal\\\\Core\\\\Extension\\\\ModuleHandlerInterface\\:\\:loadInclude$#"
			count: 2
			path: modules/system/tests/modules/entity_test/entity_test.install

This leads to sad TestBots and sad users.

Hm. I'm not sure what to do here: https://github.com/mglaman/phpstan-drupal/blob/main/src/Rules/Drupal/ModuleLoadInclude.php#L40
        try {
            // Try to invoke it similarly as the module handler itself.
            [$moduleName, $filename] = $this->parseLoadIncludeArgs($args[1], $args[0], $args[2] ?? null, $scope);
            $module = $this->extensionMap->getModule($moduleName);
            if ($module === null) {

Which is from
    protected function parseLoadIncludeArgs(Node\Arg $module, Node\Arg $type, ?Node\Arg $name, Scope $scope): array
    {
        $moduleName = $this->getStringArgValue($module->value, $scope);
        if ($moduleName === null) {
            return [];
        }
        $fileType = $this->getStringArgValue($type->value, $scope);
        if ($fileType === null) {
            return [];
        }
        $baseName = null;
        if ($name !== null) {
            $baseName = $this->getStringArgValue($name->value, $scope);
        }
        if ($baseName === null) {
            $baseName = $moduleName;
        }

        return [$moduleName, "$baseName.$fileType"];
    }

@mglaman I think for this case we're looking at https://github.com/mglaman/phpstan-drupal/blob/main/src/Rules/Drupal/LoadIncludes.php#L73, but the principle seems to be the same.
For reasons, I as a mere mortal don't understand, on Windows OS, the dirname() in in $module->getPath() (See https://github.com/mglaman/phpstan-drupal/blob/2453a2e58b75a166afb91b39dc824e3e8d283bc7/src/Drupal/Extension.php#L121) returns a path with / as directory separator (hence the core/modules/system/tests/modules/entity_test-bit in the message), but the actual DIRECTORY_SEPARATOR in line https://github.com/mglaman/phpstan-drupal/blob/main/src/Rules/Drupal/LoadIncludes.php#L73 always  returns a \ (which seems to gets double-escaped and ends up as a \\\\ in the message).
That leaves us with the worst of both worlds.
I would replace the DIRECTORY_SEPARATOR with an actual /, and I think that's a pattern that's used more throughout the code (and should be replaced more if my theory is correct).
In fact I see that you're already doing so in lines like this https://github.com/mglaman/phpstan-drupal/blob/2453a2e58b75a166afb91b39dc824e3e8d283bc7/src/Drupal/Extension.php#L157 and https://github.com/mglaman/phpstan-drupal/blob/2453a2e58b75a166afb91b39dc824e3e8d283bc7/src/Drupal/Extension.php#L182 for example.
Does that make any sense?

@Boegie makes sense! How does https://github.com/mglaman/phpstan-drupal/pull/417 look? PHP does some fancy fixes of mixed / or \ and DIRECTORY_SEPARATOR. For the fix, I just made sure we do not use DIRECTORY_SEPARATOR in the error message.

@mglaman Works for me :)


Consider storing ddev db on persistent (local) storage

What happened (or feature request):
Feature request: Store ddev db on persistent storage
So far I've destroyed a lot lot lot of sites. I've imported databases, and imported files Things work OK. But then I destroy them. And they aren't there when I want them.
My workflow in the past has always been to have many of my sites in dev form on my Mac workstation, always easily accessible. Even if I destroy a site the database is still in my mysql db. So I haven't been able to wean myself from that so far, because I know that at any moment I might destroy all my ddev containers.
Could we consider moving to persistent storage to avoid this?
I was reminded of this by Ten Things to Avoid in Docker Containers. NUMBER 1 is "Don’t store data in containers". We know that's going to be an issue in other products... but lo and behold I think it's an issue in ddev.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else do we need to know:
Related source links or issues:

I think part of the motivation behind providing the "stop" command is to help alleviate this issue and allow shutting down the environment without data loss, but I do agree we should make it possible to retain the mysql data even if the containers are removed. This would likely be more in line with user expectations, and I would hate for people to lose data due to misunderstanding what rm currently does.
Making this change does have some important considerations however:

Performance - transitioning mysql data to volume mount will severely degrade performance. Future docker FS cache options may help alleviate this, but this will require some benchmarks to determine which option will best suit us - we may also have to decide to favor reads or writes in choosing a method. Alternatively, we may actually consider rsync to another location to get a local copy without a performance hit on the site. This approach may be viable since we're not dealing with 2-way sync between host and container.
Clean state - If we support persisting the mysql data, we need to provide a way for users to hit the reset button and get a clean mysql instance. This might be a case easily resolved with documentation to delete the mount directory.

In the meantime, we could probably add confirmation to ddev rm and warn of its destructive nature.

A few thoughts:

Approximately two years ago, Kevin was working on a solution with Docker that created almost a "black box" approach where the container was loading the files, code, AND db from the host machine. I don't think it was much of a performance issue as a stability issue, where the local files might get corrupted if the mount dropped midflight.
The problem we're trying to solve is a user's habits and expectations. I know that the practice @rfay is referring to is one that I'm a bit hard-wired into myself. I would typically get the entire files + code + db working but let the DB persist the longest with the ability to simply nuke the files/code at a moment's notice. And if the files got out of sync, I typically didn't care because local was meant to be a sandbox. Perhaps there is a different way to solve it. What if we prompted a user before a ddev rm to (by default) save a drush archive. That still wouldn't address the use case where someone decides to delete the docker containers directly by bypassing ddev, but it does give some guardrails.

Sounds like we need further investigation on LOE, OS compatibility, and performance before this can become prioritized and actionable.

Additional thoughts:

If the idea is that a user could reconnect with a database that was already imported, we would need to work through the scenarios of how a user would re-attach. For example, during ddev config, would we scan the file mount to determine which databases are available and then run the additional functionality contained within the import-db command to re-establish a settings.php for Drupal? Or do we provide a flag on import-db to specify an existing database location?
Do we provide users with the option (via a config) to flag whether they want to use the container versus file mount?

Since we're in a research phase, we should get a sense of the performance impact and LOE to implement.

Here are the results of some of Rick's favorite testing: D8 install:

Mount type
D8 web install
D8 drush si -y

host-mounted (not cached)
2:45
1:13

host-mounted cached
2:45
1:14

Internal
2:40
1:10

After install, the general feel of the site was just fine with the host mount. I'm quite surprised that there was this little degradation (if there is any - hard to measure in this case)
All that's required to change this is

[ ] minor change to remove VOLUME from the mysql container's dockerfile
[ ] ddev should create the directory for mysql (in .ddev I'd assume)
[ ] ddev adds the mysql mount to the docker-compose template.

Hi @rfay. Thanks for completing the performance tests and detailing out the specific requirements. I believe I'm tracking, but think it's important to reflect back what you're saying to ensure I don't have any gaps.

Performance: based on web and CLI tests, it looks like there is a slight performance penalty of up to 5 seconds (representing 3% to 6% of the total time) by mounting the mysql directory on the host machine.
Requirements: given that we're only talking about the mysql files/storage, this adds no new requirements on the host machine (e.g. this doesn't require a Linux, macOS, or Windows user to install mysql on the host machine if it's not already present).
Directory: You mention that it would make sense to store in the .ddev directory, but it wasn't clear if you were proposing the local project directory OR the global .ddev directory. If the goal is persistent storage that an end-user wouldn't accidentally delete, it would probably make sense to use the global ~/.ddev directory. Of course, we could just start with the app specific .ddev directory because it's more likely to get cleaned out if a user goes beyond ddev rm and wants to wipe out everything, they don't have lingering databases hanging around.
Workflow: We still need to nail down when this is removed. Anyone running a ddev import-db would expect to lose the previous DB, but what about ddev rm? We already explicitly warn the user about the containers going. However, there is likely a scenario where someone wants to nuke the containers but leave the DB. And if the user leaves the DB on persistent storage with the containers gone, it would seem reasonable when running ddev start to essentially look for that DB and generate the settings.php and wp-config.php files to point to that persistent DB. Just things that we need to nail down, at least for a first pass so that this persistence is actually useful and it doesn't get wiped out anyway!

Two next actions before I think we can make a decision on this:

Get the workflow item resolved.
Sanity check with another member of the dev team.

It's pretty easy to do an experimental PR for this if that will help sort things.

Reviewing. Providing some resources for those that are following along https://docs.docker.com/engine/tutorials/dockervolumes/.

After a quick scan of the Docker documentation, I'm actually biasing towards the Docker Volumes approach. A couple key points:

Fat Finger Protection. One of my concerns with storing a database in ~/.ddev or in project/.ddev is that if someone says something like "oh just delete your .ddev folder" to fix another issue that they don't inadvertently lose their data. It's going to happen. It's only a matter of time!
Container Independence. Initially, I thought volumes might be lost when a container was discarded. It seems like there are protections in place to make that happen. Notably, you need to use a completely different command to add/remove volumes and the default behavior of pruning volumes is to leave ones that are being actively used by a container.
Business Logic. We get functionality for free. We no longer have to check if containers are still using that data.
Parity with non-local Solutions. We are likely going to need to use a similar approach in our hosting offerings. It would seem useful to adopt similar solutions when possible.

I realize we're bouncing around the conversation between multiple PRs and the issue summary. Regardless of the approach, we still need to figure out the fate of the ddev rm command (see conversation here) as well as providing a ddev means of removing the data.
Proposed next actions:

[ ] Need to resolve ddev rm and provide a way to purge the data (potentially with a new command).
[ ] Thoroughly test the workflow to make sure it makes sense.

Regardless, unless there is a major reason to adopt the non-docker approach, I think we gained a lot from both PRs but we should go in that direction.

Not done yet, done & redone and reverted, still needs work.


Add [side] parameter for FormBuilderFilterChip and FormBuilderChoiceChip

Copy [side] parameter from Material's ChoiceChip widget with documentation. Copy [side] parameter form Material's FilterChip widget.
Connection with issue(s)

Connected to https://github.com/flutter-form-builder-ecosystem/flutter_form_builder/issues/1328
Solution description
I  copied parameter definition from FilterChip and ChoiceChip widgets. I  also copied documentation only for FormBuilderChoiceChip, because FormBuilderFilterChip doesn't have documentation.
Screenshots or Videos

To Do

[x] Read contributing guide
[x] Check the original issue to confirm it is fully satisfied
[x] Add solution description to help guide reviewers
[ ] Add unit test to verify new or fixed behaviour
[ ] If apply, add documentation to code properties and package readme

Hi, how long do I have to wait for approval?

@fatyga what is the changes? Only see the updated example dependencies

Sorry, I have forgotten to stage all files.


[Enhancement] Make routine load error msg more clear

Why I'm doing:
When there is an error in the interaction between the BE and the Kafka broker, the current error message is very confusing for users. Users cannot determine the specific reason why the routine load job has been paused.

What I'm doing:
Expose librdkafka logs to users.

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[x] 3.1
[ ] 3.0
[ ] 2.5

Will the ReasonOfStateChanged only be set when the job state changes? How to know the error when the state does not change?

Will the ReasonOfStateChanged only be set when the job state changes? How to know the error when the state does not change?

If kafka broker down when routine load job runing, we can use 'show routine load task' to know what has happend. Just  like this:


Add Extensible Clipboard Data Loading

(Note: This is very freshly written, so I haven't even implemented it on Windows yet.)
This mostly addresses godotengine/godot-proposals#7899 by adding several functions to DisplayServer:

clipboard_has_type, implemented per-platform, to test if a given type is available on the clipboard.
clipboard_add_type_handler and clipboard_remove_type_handler, for adding and removing type handlers (Callables which map the raw data to the correct type) from the internal list.
clipboard_get_raw_type, implemented per-platform, which is not exposed outside the engine and simply produces the raw bytes of a type from the clipboard in a PackedByteArray.
clipboard_get_type, implemented for all platforms, which takes the raw data from clipboard_get_raw_type and converts it using the appropriate Callable from the handler map to produce the correct type.

Something not explicit in the code is that p_type, the type name being requested by the user, is a MIME type, which should be directly supported on Linux and (as far as I can tell) Windows, and which should be convertable to the correct representation on Mac.
I still want to implement this for windows, and I don't know if the API is really what we'd want to expose for this, but I'm making this draft PR to let anyone who'd like to leave feedback on it.

Nice to see you're working on this, some comments:
Perhaps a bit of a nitpick, but for me the naming get_type/get_raw_type feels wrong as it's not returning a type, but rather data or resources. If you feel clipboard_get_data_for_type is too long I'd propose getting rid of type instead, as in clipboard_get_data since it's the data we're getting and type is already a required variable to pass. Or perhaps clipboard_get_object for the parsed and processed resources and clipboard_get_raw_data for the raw data?

Something not explicit in the code is that p_type, the type name being requested by the user, is a MIME type

Regarding this there's also the case of custom types, one of the more important usecases for expanding the clipboard functionality in my mind. In other words getting and setting data to the clipboard in propriety formats used only in your own application. So for cases where the type isn't a MIME type that can be translated to something appropriate for the local platform the type string should be used as is.
And finally, regarding the image specific versions like clipboard_has_image() and clipboard_get_image() it looks like you've started implementing this as just checking for image/png data. I'm not sure about linux, but both Windows Clipboard and macOS NSPasteboard have dedicated functions for checking if there is image data on the clipboard and returning this image regardless of image format. Using these system features we can ensure that we can get access to any image on the pasteboard that the system supports, regardless of format.

I agree the naming of the functions is a bit awkward, I was aiming for consistency with the existing functions without being overly verbose. I don't love clipboard_get_object, since the data loaded can be of non-object type (i.e. String, Dictionary, int, etc). I'm also just not sure this is the right design - it feels inconsistent for the engine to register callbacks to handle clipboard parsing in this way. Maybe it might be better to use an API more like that of ResourceFormatLoader? Or is that overkill? I'm not sure.

Regarding naming, perhaps the current clipboard_get/set/has() could just be used to get a shorter version, but with a new optional p_type variable to pass. If this is optional and defaults to a clipboard string type it would retain compatibility with the current clipboard_get/set/has() implementations for strings currently on the pasteboard? Only the return type of clipboard_get and first clipboard_set parameter would now be a Variant instead of String, which shouldn't break compatibility I think?
I also agree that the clipboard_add_type_handler seems a little inconsistent. I figured this was a design you liked, but to me it would be ok to just have the clipboard_get (or whatever they'll be called) return the data directly and skip the handlers. Either return raw as a PackedByteArray for further processing, or maybe with hints in clipboard_get for how the data should be parsed to basic types like String or Dictionary returned instead (se examples below).
To me I think the most important thing is to allow getting and setting custom and multiple specified types of data on the clipboard instead of the current just getting and setting single standard bitmap image or text string.
For example if I copy a graphical element in the graphics app I'm working on I'd like to place a bitmap image, an svg vector representation and my own custom format data structure all on the pasteboard. The two first for exporting to other apps that might prefer a bitmap images or vector svg graphics, and the third custom format data for internal use if the user pastes it in somewhere in my own app. Similarly when pasting something into the app I'd like to be able to check if there is data of different such supported types on the clipboard to determine which one should be used and pasted in.
So for these types of situations I imagined there would be need for something like this to access this data from the clipboard when pasting:
if DisplayServer.clipboard_has("my_custom_format"):
	#paste my custom data
	custom_data_dictionary = DisplayServer.clipboard_get("my_custom_format", ClipboardParseType.DICTIONARY)
elif DisplayServer.clipboard_has("image/svg+xml"):
	#get and parse svg data specifically
	svg_string = DisplayServer.clipboard_get("image/svg+xml", ClipboardParseType.STRING)
elif DisplayServer.clipboard_has_image():
	#get any available image data from pasteboard, converted to a Godot Image
	image = DisplayServer.clipboard_get_image()

And to set multiple format data on the clipboard when copying:
clipboard_set_image(image) #might set multiple image data formats for compatibility
clipboard_set(svg_string,"image/svg+xml")
clipboard_set(custom_data_dictionary,"my_custom_format")

I think removing the type handler callback system entirely and just providing engine methods for text and images solves the common use cases, and then an additional method to get arbitrary types as a PackedByteArray should allow users with less common uses to solve their issue. I think that design should adhere better to the Godot development philosophy, so I'll make the change soon.

@Setadokalo any progress on this? Anything I can do to help? I've got a use case now in the project I'm working on where I'm copying graphical layer and I'd like to put both a string SVG representation and my own internal data format on the clipboard at the same time, and conversely also then examine the clipboard and see if there is data there in my internal format when pasting in.
Currently this is very tricky and doesn't really work as expected in all cases as I can only actually put strings on the clipboard with the current clipboard functionality and have to rely on my own faked internal clipboard for the custom data. So getting this functionality to put multiple data formats on the clipboard and look for and get specific custom formats would be very useful!

sorry, the thing that stopped me from progressing last time was actually a bug I noticed in the current implementation; when I get an image from the clipboard and it triggers the multipart mechanism, it also for some reason makes the window unable to receive focus anymore. I've meant to try to track that bug down, but haven't had the time.

I see, I assume this input issue is on Windows, where the Clipboard seems more closely tied to windows? But still it seems unexpected that getting data from the clipboard should affect input. Could it be related to an unbalanced OpenClipboad / CloseClipboard call set (as described here)?
And also, does getting an image need to trigger a "multipart mechanism" of some kind? On Windows there seems to be a dedicated Clipboard.GetImage method that will allow getting an image from the Clipboard without needing to know what format it is in. On macOS there is a similar method via NSImage initWithPasteboard that can be used to create an NSImage (that we can then turn into PNG data for example) from the clipboard, without needing to know what formats images are stored on the clipboard.
Is the code updated with this latest version in this pr draft? If you update that I could take a look at the code there and see if I can find anything that looks like it could cause issues.

it's actually a linux issue - and increment transfer is chosen by the owner of the clipboard data, not the requesting client. I'm not sure if it's a godot, xwayland, or kde bug at this point - I haven't had the time and motivation to investigate it enough.

actually a linux issue - and increment transfer is chosen by the owner of the clipboard data

I see, that's unfortunate. But that sounds like it wouldn't be a new issue or specific to this new extended multi-format clipboard support. But rather something more general with linux clipboard access in Godot? Does the current DisplayServer.clipboard_get_image() implementation suffer from the same issue? If not perhaps there is a solution in how that is implemented.

I don't know how helpful it can be, but since SDL 3 now has support for mime types in its clipboard implementation, maybe you could have a look there for inspiration? https://wiki.libsdl.org/SDL3/SDL_SetClipboardData
It would definitely be nice to see support for pasting images into the clipboard.

So, I finally got around to trying to pin down if it was a KDE Wayland bug or a bug in my code, but now I can't reproduce the bug anymore at all. A different bug occurs on weston, but XWayland in general doesn't seem to behave right on weston. If it rears its head again maybe we'll find a way to fix it for good, but for now I'm assuming it was actually a KDE Wayland bug (and somehow most applications just didn't run into it). I don't have time to work on the actual PR tonight, but I plan to actually work on it later this week.


Graphql-Server + Graphene + Flask issues

I'm trying to setup flask with graphene and graphql-server. As this is just a test which I am running, I'm using the latest beta releases:

graphene: 3.0.0b7
graphql-server: 3.0.0b4

Note: I had to use the beta versions of both packages, otherwise I run into dependency issues with graphql-core
Now I found some example which use graphql_server.flask.GraphQLView for the flask views. However, I couldnt use the graphene schema directly, I had to use schema.graphql_schema instead.

Is this expected?
Are there some side effects of this usage?

The following code is a minimal working example:
from flask import Flask
from graphene import ObjectType, String, Schema
from graphql_server.flask import GraphQLView

class Query(ObjectType):
    hello = String(name=String(default_value='stranger'))
    goodbye = String()

    def resolve_hello(root, info, name):
        return 'Hello {}'.format(name)

    def resolve_goodbye(root, info):
        return 'See ya!'

schema = Schema(query=Query)
app = Flask(__name__)

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
    'graphql',
    schema=schema.graphql_schema,  # TODO: Check what the consequences are of using the graphql_schema
    graphiql=True,
    graphiql_version='1.3.2'
))

app.add_url_rule('/graphql/batch', view_func=GraphQLView.as_view(
    'graphql_batch',
    schema=schema.graphql_schema,  # TODO: Check what the consequences are of using the graphql_schema
    batch=True
))

if __name__ == '__main__':
    app.run(host='<IP_ADDRESS>')

Nevermind: Just found a note in the docs which exactly mentiones this...

Nevermind: Just found a note in the docs which exactly mentiones this...

Hi @jrast
ich steh auf dem Schlauch! I have the same issue but can work it out how the docs can help me. Can you show me what you did to solve this issue?