Has LVDS out been tested?

Clifford,
Has LVDS out been tested**?
code sample: lvds.txt
simple LVDS code builds with no errors reported:
using iCEcube2 runs as expected
Total number of logic levels: 12
Total path delay: 14.37 ns (69.58 MHz)
on iCEstorm does not run as expected
Total number of logic levels: 22
Total path delay: 23.95 ns (41.76 MHz)
**I only found reference to LVDS in:
http://www.clifford.at/icestorm/io_tile.html

Ah.. No wonder I never got my lvds code to do anything.

Please post a complete synthesizable example, including pcf file.
There is no special hardware support in iCE40 devices for LVDS output (the dedicated LVDS hardware is for input only), so it is not clear to me what you think is not supported or not tested.
Quoting Lattice TN1253 "Using Differential I/O (LVDS, Sub-LVDS) in iCE40 LP/HX Devices":

For some differential I/O standards, such as LVDS, the output driver is actually a current source. On iCE40 FPGAs, however, differential outputs are constructed using a pair of single-ended PIO pins as shown in Figure 3, and an external resistor network consisting of three resistors. Because differential outputs are built from two single-ended LVCMOS outputs, differential outputs are available in any I/O bank.

Clifford,
Are you able to post "a complete synthesizable example" using
.PIN_TYPE = 6'b011100; that you believe to work?
NB: does it build similarly on iCEcube2 and iCEstorm?
as I wrote you by email, in order to create a reduced testcase or "a complete synthesizable example" that clearly identifies LVDS as the issue, I need further guidance:
This might be for instance be:
A way for me to identify the differences between the examples synthesised by iCEstorm and iCEcube2.
Clearly the difference between 22 logic levels and 12 may be significant,
I need to understand how to assess this in order to define the issue more clearly for both of us.
regards
Jonathan

Clifford,
Are you able to post "a complete synthesizable example" using
.PIN_TYPE = 6'b011100; that you believe to work?
NB: does it build similarly on iCEcube2 and iCEstorm?

First of all: It is custom, when writing a bug report, to provide an example that demonstrates the alleged bug, not to demand proof from the original developer that the (vaguely described) bug does not exists. This is ridiculous, a waste of my time, and extremely inconsiderate. Especially considering that you have to have some kind of example already, but for some reason you have decided to only post a fraction of it, and now refuse to post a complete example, wasting my time because now I have to try to reproduce what's going on on your side, without you showing me what you are trying to do.
However, here is an example that does work on the iCEstick, with Yosys+Arachne-pnr as well as with iCEcube:
module top (
        input  clk,
        output LED1,
        output LED2,
        output LED3,
        output LED4,
        output LED5
);

        localparam LOG2DELAY = 22;

        reg [LOG2DELAY-1:0] counter = 0;
        reg slowclock = 0;
        reg outval = 0;

        always@(posedge clk) begin
                if (!counter)
                        slowclock <= !slowclock;
                counter <= counter + 1;
        end

        always@(posedge slowclock)
                outval <= !outval;

        SB_IO #(
                .PIN_TYPE(6'b 0111_00)
        ) test_P (
                .PACKAGE_PIN(LED5),
                .OUTPUT_CLK(slowclock),
                .D_OUT_0(outval)
        );

        assign {LED1, LED2, LED3, LED4} = 0;
endmodule

Here is the PCF file that goes with it:
set_io LED1 99
set_io LED2 98
set_io LED3 97
set_io LED4 96
set_io LED5 95
set_io clk 21

This is a variation of the examples/icestick/ example bundled with project icestorm. I simply used to makefile from that example.
As I have now proven to you that this indeed works, and you have refused to post an example that does not work, I am now closing this issue. This is the first and last time I do this. In the future, if you think you have found a bug, but refuse to post example code, I will simply close the issue without any further comment. I have only limited time and will not spend it on BS like this.

Clearly the difference between 22 logic levels and 12 may be significant,

Clearly this is an independent problem and clearly I can't do anything about it when you do not post your test case.
I appreciate your interest in project icestorm, but do not waste my time like this ever again.
Don't get me wrong: It is OK to report an issue that turns out the be a problem on your side. Most reported issues are. But this "I'm not going to post my example -- you have to post an example that proves that it is working" crap is unacceptable, and if you try to pull it ever again, there is a certain chance that I will simply ignore all further communications from you. I hope this is clear now.
Have a good day.

Clifford
your example is not an LVDS pair, so may not be related to this bug.
-- differential being the keyword.
I do understand we all have bad hair days, but really you need to take a time out.
best
Jonathan

As I wrote before:

THERE IS NO HARDWARE SUPPORT IN ICE40 FOR LVDS OUTPUT! IT IS JUST TWO PIOS! READ THE PARAGRAPH I QUOTED FROM THE LATTICE DOCUMENTATION!

I do understand we all have bad hair days, but really you need to take a time out.

Clearly you don't seem to understand that I asked repeatedly for information you decline to provide. That is not me having a "bad hair day", that you wasting my time for no good reason. I can't make you understand that, but I can lock this conversation. Go waste someone else's time!


Read intensities in scientific format for DAVE files

Description of work.

Switched the format of a few numbers to scientific format in the DAVE data file for testing
Regex to pick up numbers in scientific format

To test: N/A
Fixes #53
Code Review

[ ] Is the code of an acceptable quality?
[ ] Does the code conform to the [coding standards]?
[ ] Are the unit tests small and test the class in isolation?
[ ] If there are changes in HISTORY.rst then do they describe the changes appropriately?

Functional Tests

[ ] Do changes function as described? Add comments below that describe the tests performed?
[ ] Do the changes handle unexpected situations, e.g. bad input?

Documentation

[ ] Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @qef/gatekeepers will take care of it.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@a880264). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master      #54   +/-   ##
=========================================
  Coverage          ?   93.06%
=========================================
  Files             ?       10
  Lines             ?      274
  Branches          ?        0
=========================================
  Hits              ?      255
  Misses            ?       19
  Partials          ?        0

Impacted Files
Coverage Δ

qef/io/loaders.py
81.25% <100%> (ø)

Continue to review full report at Codecov.

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


Doesn't work with npm start

Below is the image I get on the browser when I run npm start after npm install

duplicate of #37 ?

same issue as link with #29 #34 #36 #37


Create PR rather than direct commit (directory workflow)

Things added/changed:

Create PR rather than direct commit for the directory workflow.

Ready to use in other repositories! Thanks for reviewing. 🙂


:memo: Feat: Add tutorial

Description
Add a bunch of more docs
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #829   👈

This stack of pull requests is managed by Graphite.


Unit tests take an unacceptable amount of time

For years, Cesium unit tests took about ~45 seconds to run.
I just tried to run the unit tests locally under Chrome and they took 229.713 seconds (and that's using the webGL stub which is the fastest way to test).
So what's changed and how can we fix this?

It appears that GroundPrimitive tests, especially texture-related ground primitives may be the main culprit here.  @likangning93 do you know off hand if these are known slow tests?

Duplicate #6570


Replacing CLI to Next.js plugin

Now we have changed the way we do the "build". Before it made much more sense, because there was no i18n routing support in Next.js, so what we were doing was creating all possible static pages, working in a parallel directory like pages_.
This now after 0.19 has evolved in such a way that we only need the build to load the namespaces, so it's time to think of a better alternative.

I have been doing tests in the 1.0.0-experimental branch and I see it very feasible to move this logic to a Next.js plugin, moving the builder part to a webpack loader.
This is going to fix:

Hotreloading/refresh files
Faster build
De-duping logic. Right now there are some alternatives: with builder, without builder + appWithI18n, etc. This can be all integrated inside the plugin, skipping the webpack loader or not.
Working in the same pages directory than Next.js. No need of workarounds.
Easy to test
Easy to migrate in the future
No need to indicate to the Next.js config the locales and defaultLocales on next.config.js, this will be injected by the plugin. So you only will have a i18n.js or i18n.json root file.

The only change (after renaming pages_ to pages) will be:
Instead of this on package.json:
{
  "scripts": {
    "dev": "next-translate && next dev",
    "build": "next-translate && next build",
  }
}

Use in next.config.js file:
const nextTranslate = require('next-translate')

//...

module.exports = nextTranslate(nextConfig)

The idea is to keep the same i18n.json / i18n.js configuration file.

If someone wants to experiment, I did a first experimental version under 1.0.0-experimental.1 prerelease.

Note: instead of localesPath, now is loadLocaleFrom (already in the doc) for all the cases: build step, custom server, etc

When trying to load a normal page I get the following error in the console:

When trying to load a page with getInitialProps I get:
error - ./node_modules/next-translate/index.js:1:833
Module not found: Can't resolve 'fs'
null
TypeError: Cannot read property 'prototype' of undefined
    at loadGetInitialProps (/Users/bjoern/projects/inventhora/page-builder/node_modules/next/dist/next-server/lib/utils.js:3:690)
    at appGetInitialProps (/Users/bjoern/projects/inventhora/page-builder/node_modules/next/dist/pages/_app.js:4:106)
    at /Users/bjoern/projects/inventhora/page-builder/node_modules/next-translate/appWithI18n.js:1:2454
    at tryCatch (/Users/bjoern/projects/inventhora/page-builder/node_modules/regenerator-runtime/runtime.js:63:40)
    at Generator.invoke [as _invoke] (/Users/bjoern/projects/inventhora/page-builder/node_modules/regenerator-runtime/runtime.js:293:22)
    at Generator.next (/Users/bjoern/projects/inventhora/page-builder/node_modules/regenerator-runtime/runtime.js:118:21)
    at asyncGeneratorStep (/Users/bjoern/projects/inventhora/page-builder/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
    at _next (/Users/bjoern/projects/inventhora/page-builder/node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9)
    at /Users/bjoern/projects/inventhora/page-builder/node_modules/@babel/runtime/helpers/asyncToGenerator.js:32:7
    at new Promise (<anonymous>)
Could not find files for /project in .next/build-manifest.json

@BjoernRave Try with 1.0.0-experimental.2 that now it has some corrections with respect to the experimental.1. If it doesn't work either, you would paste here your code of your _app.js file? 😊   Thank you!

@aralroca I am getting a Module not found: Error: Can't resolve 'fs error when using 1.0.0-experimental.2. I am using TypeScript, NextJS 10, React 16, a very simple babel file... what further information would you need to help me pinpoint this?

I usedfs inside the plugin to read the configuration file (i18n.json). I don't have any problem with it,  but maybe it could be related to this https://github.com/vercel/next.js/issues/7755#issuecomment-508633125 ?
If adding this works:
module.exports = {
  webpack: (config, { isServer }) => {
    // Fixes npm packages that depend on `fs` module
    if (!isServer) {
      config.node = {
        fs: 'empty'
      }
    }

    return config
  }
}

I will include it inside the same plugin to make it work. Can you confirm it? 😊  and thank you very much for the feedback!

if you can provide a simple repo reproducing the error, it would be very helpful 🙏

That fixed it indeed! Also, check out this comment: https://github.com/vercel/next.js/issues/7755#issuecomment-624544303
That might be the solution?

Yep, that comment is right. If I simply include any fs call, such as
fs.stat("/a.tsx", () => {});

in my getStaticProps method, then NextJS' babel plugin removes that import from the browser plugin and everything works

However, now I get this error:
Error was not caught ReferenceError: exports is not defined
    at Module.eval (webpack-internal:///./node_modules/next/dist/pages/_app.js:8)
    at eval (webpack-internal:///./node_modules/next/dist/pages/_app.js:108)

You can reproduce my setup here: https://github.com/jan-wilhelm/next-translate-error-reproduction

Update: I have found that the error appears when using<EMAIL_ADDRESS>but disappears on<EMAIL_ADDRESS>

Question - Is there any way at all for next-translate not to use getStaticProps? I am trying to set up a NextJS application where we have a route like products/[productId]. I do not know all possible productIds at build time, as they can constantly change. However, I want that ProductID-Page to be statically prerendered and to use next-translate. NextJS currently forces me to export all possible getStaticPaths.
Apparently, next-translate currently circumvents this by using getServerSideProps which disables automatic static optimisation. However, the loading screen for each productID is always the same and content is only fetched on the client side, so theoretically NextJS should just be able to pre-generate the loading screen for all any productID.
I wouldn't normally need any of getStaticProps, getStaticPaths or getServerSideProps at all on this page, however next-translate currently forces me to use SSR :/

@jan-wilhelm next-translate now uses the existing loaders if the page already has one. If your page has a getStaticProps, it will use a getStaticPropsto load the translations. The problem is with the default values, when there is no existing loader. In this case, there are 3 cases:

The normal case: Always use a getStaticProps to have maximum performance.
For a dynamic page (example/[slug] or example/[...catchall]), it's using getServerSideProps because it is required by Next.js that if you want to provide the getStaticProps you must also write the getStaticPaths, and  we have no idea of the paths that will be used, and to avoid putting a "fallback: false", we decided that perhaps, in this case, it was better that the fallback was the getServerSideProps.
When the page uses an external HOC it is using getInitialProps by default to avoid possible conflicts.

However, remember that these are default values when the page has no loader. Writing an empty getStaticProps will cause next-translate to use getStaticProps to load the translations.
Translated with www.DeepL.com/Translator (free version)

@jan-wilhelm Do you think it would make more sense for the fallback for dynamic pages ([slug]) to provide a getStaticPaths with fallback: false? I would love that next-translate uses a getStaticProps by default in this case too, but at the same time I don't like that the translations are loaded in CSR without having the page prerendered

yeah I totally get that. What would you suggest to do in this scenario? Are we just gonna have to wait for NextJS to support getStaticProps without getStaticPaths? It feels wasteful to me to always render the same loading screen skeleton over and over again, because I do not want to use SSR.
I think personally, for me, I could either go with the fallback: true approach or make it so that the page is not dynamic (something like products/?id=PRODUCT_ID so that it can get pre-rendered. I think it is fine for next-translate to keep using getServerSideProps for this by default.
I asked the same question on a next-i18next GitHub Issue and I'm curious to see what option they will choose.

I would say that the easiest way is to use SSR temporarily for these pages (unless you know all the paths). It is the simplest thing, although it has the cost of optimization, we know that it is temporary. If you make temporary alternative routes I think it will be much worse to change it in the future, since you will have to provide a 301 redirect to the new route for each of your products, and you could have serious SEO problems.
The i18n support of Next.js right now is only routing, but it is also in their plans to develop a method to load the translations. So this would solve your problem.
A little bit the idea to make now the plugin is about the future of i18n inside Next.js. We want that in a future it will be very easy to migrate from one way to another just by upgrading Next.js and next-translate without breaking changes, and gaining then optimization in these pages.
I guess and hope that the development about loading the translations from Next.js team will be declarative at the configuration level. It's clear that writing manually in each page which namespaces you want inside a loader (getStaticProps, getServerSideProps) is a pain, and that's why we give the opportunity to define it this way:
{
  "locales": ["en", "de"],
  "defaultLocale": "en",
  "pages": {
    "*": ["common"], // all pages
    "/": ["home"],
    "/product/[id]": ["product"],
    "rgx:^/account": ["account"], // all pages under /account
    "rgx:^/admin": ["admin"] // all pages under /admin
  }
}

Hello, I have tested the Feature Branch 1.0.0 experiment. The setup of my Next Configuration looks like this.
const { merge } = require('webpack-merge');
const nextTranslate = require("next-translate");
const nextConfig = {
	// Called within next-Translate, criteria the property webpack a function
  webpack: (config, options) => {
    return merge(
      config,
      process.env.NODE_ENV === 'development
        ? webpackConfigDev(config, options)
        : webpackConfigProd(config, options)
    );
  },
module.exports = nextTranslate(nextConfig)

From the configuration you can see how to use Webpack. An essential module contained in the feature supplements the Next-Translate Loader in any detectable module rules, which were created by upstream Webpack steps. In my case these are not only the steps defined by NextJs, but also those that are created in the mentioned merge parts depending on whether development or production. Whether a local or outsourced Webpack configuration is used here is not questionable.
The call of dedicated Webpack steps is controlled by next-translate.
So projects that have their own Webpack configuration must be called by the call.
Adaptation 1:
In NextJs there is a request to block the FS if !server
https://github.com/vinissimus/next-translate/blob/c2579f6d96df6bc4add109a916fa44e363851087/src/index.js#L58
webpack(conf) {
	const config =
		typeof nextConfig.webpack === 'function
		? nextConfig.webpack(conf)
		: conf

webpack(conf, options) {
	const config =
		typeof nextConfig.webpack === 'function
		? nextConfig.webpack(conf, options)
		: conf

Adaptation 2:
The Branch 1.0.0-experimental.2 is not compatible to Webpack 5. The existing code creates undefined values in the array if "use". The existing code distinguishes two variants, if array or not. If the variable is not an array it is expected to be an object.
At least one case I could identify, where this expectation does not come true.
Input:
{ test: /\.m?js/, resolve: { fullySpecified: false } },

Output:
{ test: /\.m?js/, resolve: { fullySpecified: false }, use: [] },

https://github.com/vinissimus/next-translate/blob/c2579f6d96df6bc4add109a916fa44e363851087/src/index.js#L82
const use = Array.isArray(r.use) ? [...r.use, loader] : [r.use, loader]

let use = [];
if(array.isArray(r.use)) {
	use = [...r.use, loader];
} else if (typeof r.use === 'object') {
	use = [r.use, loader]
} else if ( r !== zero && r.use === zero) {
	use = [{...r}, loader]
}

What needs to be clarified additionally is how to handle loaders which follow an outdated nesting specification, those where the specification differs from module/rules/ (test|use). Maybe not relevant here.
module.loaders were deprecated since Webpack 2 and are now removed in favour of module.rules.

Basic procedure
As seen in the last step, all loaders are mutated exactly on the first pass. My question is what exactly should be achieved when this is done across all rules, to mount the next-translate Loader.
Is it not enough to do this exactly for Javascript files?
Maybe it is possible that someone will validate, improve and experiment with the proposed changes via NPM.
Thanks for listening and keep up the cool library!

@gurkerl83 Thank you very much for your feedback! 👏 About passing the webpack configuration all the way through is something I'm going to fix right now! 😊  Thanks! About webpack 5 support is on the TODO list! heh! In the same file above there are some comments about everything that is still missing. I will take into account everything you tell me to continue developing version 1.0, very useful your comments.

Question to the overall approach.
As seen in the last step, all loaders are mutated exactly on the first pass. My question is what exactly should be achieved when this is done across all rules, to mount the next-translate Loader.

Is it not enough to do this exactly for Javascript files?

I don't know if I understood the question correctly. You mean that instead of making a .map and replacing the existing JavaScript loader to include our loader what I should do is add another independent loader inside rules?
The truth is that I also thought about doing it this way, and maybe we can change the way we load it. Basically, I preferred to use this approach because Next.js already adds which files to include and which to exclude, so instead of taking all the .js files, it only enters the necessary ones. With the idea that if these changes in the future because Next.js changes its internal structure, with this implementation our loader will not be broken.
But, now you have made me wonder that maybe this is not enough reason. So maybe it makes more sense to add an independent rule with our loader, making sure that it always runs before Babel. With this perhaps if it would be enough, excluding node_modules and little more.

@aralroca I saw you made the changes, and provided a new experimental release. Unfortunately it is not working. The reason is that you have initialised the variable use
let use = [loader] // use has to be initialised with an empty array.

for the webpack options please do not spread them, there is no reason to do that but makes code more complicated to understand
webpack(conf, ...rest) {
      const config =
        typeof nextConfig.webpack === 'function'
          ? nextConfig.webpack(conf, ...rest)
          : conf

just replace it with

webpack(conf, options) {
      const config =
        typeof nextConfig.webpack === 'function'
          ? nextConfig.webpack(conf, options)
          : conf

Thx!

@gurkerl83 thanks for this amazing feedback, I applied the changes under 1.0.0-experimental.4 😊 👍

Hi @aralroca, with 1.0.0-experimental.10 I get the following compile error when using the Trans component:
  Its return type 'string | ReactNode[]' is not a valid JSX element.
    Type 'string' is not assignable to type 'Element'.

  82 |
  83 |             <Form.Text muted>
> 84 |                 <Trans i18nKey="signup:acceptTermsDescription" components={[<Link href="/terms">
     |                  ^
  85 |                     terms
  86 |                 </Link>]}/>
  87 |             </Form.Text>

Changing the return type to JSX.Element solves the compile error, however I am not sure if this is recommended.

@chrisss404 thank you to report it. I fix it on 1.0.0-experimental.11.
I'm taking advantage to migrate the project to TypeScript, so if you see more type errors comment it here or do PR yourself in the 1.0.0-experimental branch! Thanks a lot!

@aralroca
Using version1.0.0-experimental.13, I set up my next.config.js like this, but it doesn't work. Is this still how you apply the plugin?
const nextTranslate = require( 'next-translate')

module.exports = nextTranslate({})

@andrehsu are you getting this error? For this error you should update React to 17 (meanwhile I can't find a way to fix it). If is another error, I would appreciate it very much if you would report what you get. Thank you very much! 🙏

@aralroca
I did not get that error, I was already on react 17.0.1.
My IDE inspection gave a warning on nextTranslate saying Method expression is not of Function type, don't know if that's relevant or not.

@andrehsu are you using Webstorm? I see this: https://intellij-support.jetbrains.com/hc/en-us/community/posts/206346419--Method-expression-is-not-of-function-type-error-on-Typescript-constructor-call (I dunno if is related)

@aralroca
Yes I am, but the issue exists independent of that.

However, now I get this error:
Error was not caught ReferenceError: exports is not defined
    at Module.eval (webpack-internal:///./node_modules/next/dist/pages/_app.js:8)
    at eval (webpack-internal:///./node_modules/next/dist/pages/_app.js:108)

You can reproduce my setup here: https://github.com/jan-wilhelm/next-translate-error-reproduction

@jan-wilhelm it should work with 1.0.0-experimental.15 👍

The migration guide to 1.0.0 is still available on https://github.com/vinissimus/next-translate/blob/1.0.0-experimental/docs/migration-guide-1.0.0.md (replacing the version to the latest experimental prerelease it should work).
Everything is already quite stabilized, in a short time we will surely go from the experimental version to the canary, since it looks like we will finally evolve around here. And I hope that the final version 1.0.0 will be available in December.
It would help a lot if you could try the latest prerelease and report possible problems; things in the documentation, issues... 🙏

I tested 1.0.0-experimental.16". Things were running smooth, only switching language was not really working. This is my logic:
  const changeLanguage = (lng: string) => {
    if (router.asPath === '/') {
      router.push('/', '/', { locale: lng })
    } else {
      const routes = router.asPath.split('/')
      if (allLanguages.includes(routes[1])) {
        routes.splice(1, 1)
      }

      const route = routes.join('/') ? routes.join('/') : '/'

      router.push(route, route, { locale: lng })
    }
  }

the url path get's changed and the locale value on useRouer as well, but the translations stay the same.

@BjoernRave I have copied your changeLanguage function in the examples of the experimental branch and tried several combinations and it seems to work in all cases. Perhaps it would help me if you could provide a reproducible example.
By the way, the last experimental one, for now, is the 1.0.0-experimental.18, with this one it happens too?
Could it happen on a particular page that you have getInitialProps on this page? There is this known issue, which has been going on since version 0.19:

https://github.com/vercel/next.js/issues/18396

In +0.19 we are displaying this warning:

https://github.com/vinissimus/next-translate/blob/6ae141b020e3785fe3eb36e99cc4cc1f19f2fdf7/cli/builder.js#L227

I see that now this warning is lost, I'll add it again.
Do you think it could be that?
Thank you!

ah yes, that might be the problem. When switching the language on a page without it, it works fine

so version 1.0 will not support the usage of getInitialProps ?

@BjoernRave the idea is that it works the same as next-translate >= 0.19 where we moved all the routing part of i18n to the way that now the Next.js v10 core has.
In Next.js version 10 they support i18n within:

getStaticProps
getServerSideProps
getInitialProps on _app.js

But the support for i18n within getInitialProps on individual pages is missing. I understand that this is a problem, so I opened the issue in the Next.js repo. However, it is something that until it is solved in the Next.js core will not have a solution for now.
And understanding that this issue exists since version 0.19 and comes from Next.js core, I guess that version 1.0.0 will leave without this. When there is a solution will only need to upgrade the version of Next.js.
Perhaps I will try to contribute in Next.js to try to add this, I suppose that other i18n libraries will also miss it.

got it, thanks for the clarification and your dedication to make everything work as smooth as possible :)

Closing this. Already implemented on 1.0.0-canary.1. The 1.0 will be released approximately 1-2 weeks. 😊


Train GPU

Hi, thank you for your great work!
How much resources does it take to train this task on each GPU? Thank you🌹

Thank you very much for your interest. The required GPU memory usage varies depending on the token compression ratio. If the compression ratio is sufficiently small, a 4090 should suffice. However, if generation frame is a concern, we recommend using an A100. Feel free to reach out via email at<EMAIL_ADDRESS>.


chore: add support for uploading Java artifacts

This depends on https://github.com/apache/arrow/pull/14830 .

We can confirm uploaded files by seeing "orgapachearrow-1094" at https://repository.apache.org/#stagingRepositories .
If it's needed, I can publishes the artifacts to the staging repository: https://repository.apache.org/content/repositories/staging/org/apache/arrow/
I'll remove "orgapachearrow-1094" after we confirm the result.


Debug adapter process has terminated unexpectedly

Reopening as the issue is not resolved.
Please do not close as I will as soon as it's resolved
https://github.com/WebFreak001/code-debug/issues/59

I just reopened the original one, gonna close this one as duplicate


Application.make_handler(...) is deprecated, use AppRunner API instead

I am trying to run using python3.8 but I keep running into this
telegramircd.py:135: DeprecationWarning: Application.make_handler(...) is deprecated, use AppRunner API instead   self.handler = self.app.make_handler() telegramircd.py:111: RuntimeWarning: coroutine 'TelegramBaseClient.connect' was never awaited   self.proc.connect() RuntimeWarning: Enable tracemalloc to get the object allocation traceback Traceback (most recent call last):   File "telegramircd.py", line 294, in init     web.get_self()   File "telegramircd.py", line 290, in get_self     server.user_id = data.id AttributeError: 'coroutine' object has no attribute 'id' telegramircd.py:298: RuntimeWarning: coroutine 'UserMethods.get_me' was never awaited   traceback.print_exc() RuntimeWarning: Enable tracemalloc to get the object allocation traceback
I've tried older versions of aiohttp but have no luck. Any ideas?

Having the same issue, I think it has to do with telethon-sync being dropped upstream and there don't appear to be any mirrors.
I'm also not sure how to compile telethon into a compatible library either.

temporary solution
diff --git a/requirements.txt b/requirements.txt
index f2fe048..472c3fa 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,6 +1,6 @@
-aiohttp
+aiohttp==3.1.0
 python-magic
 ipdb
 ipython
 configargparse
-telethon-sync
+https://github.com/LonamiWebs/Telethon/archive/sync-stale.zip

Thanks confirm this works

I have applied
-telethon-sync
+https://github.com/LonamiWebs/Telethon/archive/sync-stale.zip

for now. For https://github.com/aio-libs/aiohttp/pull/3157 , how to properly fix it?

I have applied
-telethon-sync
+https://github.com/LonamiWebs/Telethon/archive/sync-stale.zip

for now. For aio-libs/aiohttp#3157 , how to properly fix it?

tbh, I tried, and failed (and well I am noob), so decided to go for an older version of aiohttp


removed files that was not needed

(feed_to_vespa.py, _config.yml and doc.sd)
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Please read https://chris.beams.io/posts/git-commit/
(This one pretty good, except using past tense.)

👍


[ServiceBus] Allow messages to be sent twice concurrently, improve some exceptions in that space.

Providing the wrong type when constructing a batch now results in a TypeError, not a ValueError.
Add an inner exception to ServiceBusError unknown exceptions for better diagnostics.
Add tests for double-sending
Add tests for sending something that's not a message returning a TypeError instead of a ValueError.

/azp run python - servicebus - tests

/azp run python - servicebus - tests

/azp run python - servicebus - tests

/azp run python - servicebus - tests

/azp run python - servicebus - tests

/azp run python - servicebus - tests


remove mulesoft maven repo

Out of interest and given there is no referenced issue, what prompted this PR?

Mulesoft doesn't have provenance on their repo as central does.


New version: Adobe.Acrobat.Reader.64-bit version 23.003.20320

[x] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@stephengillie morning Stephen, could you check this one please?


Fix #427 websocket --admin-api-key connect issue

This change is based on the 2 proposals in #427

Codecov Report

Merging #513 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #513   +/-   ##
=======================================
  Coverage   95.25%   95.25%
=======================================
  Files         236      236
  Lines       12058    12058
=======================================
  Hits        11486    11486
  Misses        572      572

Alternative implementation in pull request #528


fix(RHINENG-802): Always display Reset filters button

Always display the Reset filters button in SigTable & SysTable filter chips
Adds All as a filter chip in SigTable

Without Reset Filters when using multiple filters ...

With Reset Filters when using multiple filters ...

Without All filter chip ...

With All filter chip ...

Including the All filter chip makes the experience the same between the SigTable and SysTable.  Adding back the Reset filters button makes it less confusing when the button disappears for no apparent reason.  Yes there is nothing to reset back to if the Status is 'Matched' but if you also choose to filter on Signature name as well, then there definatly is a need for the Reset filter button.  My 2c anyway.


query for number of rare diseases in Mondo

@matentzn : what this query does is explained in the comment in the query.
And for convenience:
MONDO classes with the axiom "'has modifier' some rare" AND/OR "has subset :‘gard_rare’" AND limited to the 'disease' branch (ie not including terms from the 'disease susceptibility' branch)

@matentzn
Actually, it looks like what it did is not correct: according to here, we need to "consider only leaf nodes".
If I understand well, it means that I have to filter out the results which would be terms that have children (ie filter out terms which are parents). I don't know how to do that... help!!!!!! please!!! :-)

Excellent job finding the ^ operator! This looks really nice. :) The queries look great to me!


Update CIS 1.5 in v2 CIS

[x] Update the CIS 1.5 profile to include all scored=false tests

[x] Same for RKE profiles using CIS 1.5

To Test:

Pre-upgrade: launch CIS scan chart
Run a RKE permissive and RKE hardened scan
Upgrade Rancher
Run a RKE permissive and RKE hardened scan
Upgrade CIS scan chart
Run RKE permissive and RKE hardened scan

Confirm that the scan passes as expected on all 3 steps where we are running scans.

Available to test with https://github.com/mrajashree/charts/tree/cis16
Create new clusterRepo with repo https://github.com/mrajashree/charts and branch cis16, it has the new tags for security-scan and cis-operator images
On adding all missing tests in RKE 1.5 profiles from upstream CIS 1.5 profiles, some of them get counted as "Pass". Most others are "manual" with no audit scripts and generate "Warn" output. Ran them on both, hardened and non-hardened clusters.
I've created this to show all the new tests being added and the output they generate
https://docs.google.com/spreadsheets/d/15s8Ll1-Ih6N_vFdZSsQoEcyB7JbJ26C-LL50QU6QXv0/edit?usp=sharing
Ran hardened and permissive profiles on the hardened cluster, and ran only the permissive profile on the non-hardened cluster (since hardened profile will fail on it even with current profiles)

Upgrade use case from 2.5.3 to 2.5-head - commit id: baf4867c

On 2.5.3, deploy a custom cluster.
Deploy CIS v2 app
Run cluster scans - rke-permissive, rke-hardened, and cis 1.5 profiles
Upgrade rancher to 2.5-head
On the UI, the "warn" column is NOT shown for an admin user and a user who has cis-admin role can see the "warn" column but no "warn" count of tests. - Logged these  issues - https://github.com/rancher/dashboard/issues/2054 and  to track it
Create a cluster scan, user is able to set the schedule scan and alerting on the UI. (doesnt work though as a cis v2 app upgrade is required). Logged this issue to track it
Upgrade cis v2 app.


refactor: use signals in chipped content and related components

#881  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


M52: Initialize MaterialDesignController in XWalkMainDelegate::PreSan…

…dboxStartup
Recently Material design related changes were landed in upstream because of that
we need to initialize MaterialDesignController in our code. Without this some of
the browsertests were failing as tracked by XWALK-7073.
adapt to,
https://codereview.chromium.org/1878973002

@darktears PTAL

LGTM


Move authable to included_apps

Coverage remained the same at 79.07% when pulling 40ee208d592d629bcadf1bbc10c022edd1ec36a4 on gmile:debugging-authable into 75725c987d3b78af6e8268f90029059306d150f2 on Nebo15:master.


[IMPROVEMENT] Add support for hardcoded server URL

The IOS client supports RC_SERVER_URL in info.plist file, which allows the user to skip the initial screens that are about selecting a server. It would be great if the Android client supported a similar mechanism and, if set, would take the user directly to the login screen.

I am also looking for something similar, even login user with credentials coming from API and creating a direct session for chatting without showing any onboarding, server or user login screens. Kindly respond If you managed to achieve above.


C++ code compilation for pip wheel

Fixes #75
Adds setup.py and MANIFEST.in in order to include the compiled C++ extensions into the pip wheel. The C++ source files are modified to be compatible with the Microsoft C++ compiler, so that the pip wheel can also be built on Windows.
Also some reorganization to move non-essential Python modules and C++ source files to a new submodule called dev inside ppafm. This module is excluded from the pip wheel.

Before deep-diving into the code, I have tried to download it and install it:
pip install -e . went succesfully, but of cousre the compilation of C++ did not went through as I do not have MS Visual Studio.
I was thinking that it was supposed to be compiled during the pip installation - which In my case would caused direct error during the installation. And not only during the first try run ...

@NikoOinonen I see there are conflicts in Forces.h and ProbeParticle.cpp. Is it due to my merge of damp func (https://github.com/Probe-Particle/ppafm/pull/87#pullrequestreview-1314533660)? If so, what was the proper way to do ?

@NikoOinonen I see there are conflicts in Forces.h and ProbeParticle.cpp. Is it due to my merge of damp func (#87 (review))? If so, what was the proper way to do ?

@ProkopHapala You did it right. We just happened to modify the same files in parallel a way that could not be automatically resolved. I just did a manual merge of the main branch into this branch, which resolved the conflict.

What is the purpose of the ppafm/dev folder? You write that they are non-essential, why?

@yakutovicha We had some discussion with @ProkopHapala in https://github.com/Probe-Particle/ppafm/issues/75#issuecomment-1438472896 about the fact that these modules are something that are not essential to the core functionality of ppafm, and they are rather some additional functionality that Prokop intends to eventually move to his other project, so they are for now moved to this separate submodule.

@ProkopHapala suggests deleting the bin folder from ppafm/dev.

@NikoOinonen, for your information - I just merged the main branch into the current one.


Add option to disable rate limit

Everything was working fine before, but after some recent commits (feat/mongo-rate-limiter) an error occurred
500: INTERNAL_SERVER_ERROR
Code: FUNCTION_INVOCATION_FAILED
[GET] /
11:32:29:67
2022-06-11T04:32:31.186Z	undefined	ERROR	Error: collection or collectionName and uri should be set
    at new MongoStore (/var/task/node_modules/rate-limit-mongo/lib/mongoStore.js:28:9)
    at Object.<anonymous> (/var/task/api/server.js:29:12)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at ModuleWrap.<anonymous> (internal/modules/esm/translators.js:192:29)
    at ModuleJob.run (internal/modules/esm/module_job.js:183:25)
    at async Loader.import (internal/modules/esm/loader.js:178:24)
    at async getListener (/var/task/___vc/__launcher.js:37:11)
RequestId: c53c5a9b-29c3-4259-a563-f78fb6e***** Error: Runtime exited with error: exit status 1
Runtime.ExitError

The error turned out to be from the rate-limit feature, because I deploy it on my own instance I don't think I need this rate-limit feature. It would be great if there was an option for disable this rate limit. maybe from Environment Variables?
Thank you!

Solved at https://github.com/gadingnst/quran-api/pull/35 @Khuirul-Huda


Don't do anything under miri?

AFAIU, trycmd is executing a pre-compiled binary so miri wouldn't do anything with the actual code under test. Every user could #[cfg_attr(miri, ignore)] their trycmd tests, but I wonder if it'd make more sense to just noop trycmd runs under miri.

I think, if anything, we would mark all tests as ignored to help draw attention to it.


Enhance docs with array.find, array.filter behavior

I think the docs should contain examples of array.find and array.filter in the reactivity and tracking sections. It's not clear, for instance:

Do all of the nodes visited by array.find become reactive?
Is the (new immutable) node returned by array.find reactive?
Are all of the (new immutable) nodes returned by array.filter reactive?

Just released version 1.1.0 which improves the behavior with filter and find, so that it should make more sense.
Now, if you call .find or .filter on an observable array, then:

Yes, nodes visited by any looping functions become reactive
Yes, array.find returns the observable of the array element
Yes, nodes returned by array.filter are the observables of the array elements

I'm not entirely sure what you mean by "immutable" in this case so just to clarify: it's not creating special new observables or anything - if array.find finds an element at index 5, it returns the observable for the element at index 5 which is the same as array[5].
But if you .get() or .peek() on the observable first to get the raw array, then that would have the standard behavior since it's just an array.
I'll add more documentation about this behavior to the docs soon.

This was an awesome change, thank you! We no longer need to find the index of the array observable first and now can just use find directly:
  const navigatedProfile = useMemo(() => {
    return profilesAtom.find(
      (profile) => profile.name.peek() === route.params.name
    );
  }, []);

  const onPressGetCredentials = async () => {
      // ...

      // push the new credential to state
      navigatedProfile?.credentials.push(normalizedCredential);
    }
  };

Regarding mutability thank you for pointing that out. I had only just recently noticed in my POCing that this package uses the mutable state model like Valtio and MobX and trying to clone stuff would break things.


IOD-120 Create Git ACtion for TEST deploy

Description
This PR includes the following proposed change(s):
IOD-120
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Version change

if your change is a breaking change, please add breaking change label to this PR
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Does the change impact or break the Docker build?

[ ] Yes
[x] No

If Yes: Has Docker been updated accordingly?

[ ] Yes
[x] No

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[x] New and existing unit tests pass locally with my changes

@SDToews whoopsie, fixed that.


Add NCCL support

Resolves issue https://github.com/awslabs/graphstorm/issues/87
This PR is blocked by DGL's PR (https://github.com/dmlc/dgl/pull/5929) which adds NCCL support to distDGL.

Resolved in the latest codebase.


jakarta.activation-api is not a Multi Release JAR

Describe the bug
Latest  jakarta.activation-api (2.1.1) includes 3 classes compiled to bytecode 53 and 44 classes to compiled to bytecode 52. All classes are found in the unversioned space which means enforcer rules for both Maven and Gradle will trigger and fail a build.
To Reproduce
Steps to reproduce the behavior:

Get jarviz

$ jarviz bytecode show --gav jakarta.activation:jakarta.activation-api:2.1.1
Unversioned classes. Bytecode version: 52 total: 44
Unversioned classes. Bytecode version: 53 total: 3

If the --details flag is added you get the names of the 3 classes causing trouble
Unversioned classes. Bytecode version: 53 total: 3
jakarta.activation.spi.package-info
jakarta.activation.package-info
module-info

Expected behavior
These 3 classes should be inside /META-INF/versions/9. The JAR's manifest should have a manifest entry such as Multi-Release: true
https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#multi-release-jar-files

Activation 2.1 is part of Jakarta EE 10 so the classes all should be Java 11 byte code, i.e. version 55, shouldn't it?

Activation 2.1 is part of Jakarta EE 10 so the classes all should be Java 11 byte code, i.e. version 55, shouldn't it?

right, that is the requirement. OTOH we want mail, which depends on activation, to be able to support SE 8/Android

Normally I'd suggest using the moditect-maven-plugin to manage module-info.class in such a way that it can be versioned while still keeping Java 8 compatibility. However, in this case there are 2 additional package-info.class entries that are also compiled with Java 9.
IF these two additional classes must remain Java 9+ then moditect will be of little use. Instead, the build must be updated to support 2 source trees, probably add toolchains or expect the build to be invoked with a Java 9+ JDK as a requirement.

jaxb API had to deal with this as well:  https://github.com/jakartaee/jaxb-api/blob/3.0.1/jaxb-api/pom.xml#L214 should help give some ideas on how to do it.

package info part of the problem is caused by a backward incompatible change in maven compiler plugin v 3.10.0


[slim2erb] sessions/ pages

@spavlishak Could you please squash commits and write good message (changelog):
Convert views/sessions Slim templates to ERB


WebClient uses absolute request URI in requests when used via the proxy and host is listed in the no_proxy

Environment Details

Helidon Version: 2.3.3 but also happens in 2.3.1
Helidon SE
JDK version: 11.0.12
OS: Oracle linux
Docker version (if applicable):  20.10.6

Problem Description
Looks similar to issue #2302
Helidon WebClient uses an absolute request URI rather than a relative one when submitting HTTP requests. Most of times this is not an issue, but there are some HTTP server implementation that are not able to deal with it.
For example, due to this issue using Helidon WebClient I'm not able to get an OAuth Token from Oracle Identity Cloud because my requests fail with a 404.
The requests issued by Helidon WebClient look like the following:
POST <idcs-host>/oauth2/v1/token HTTP/1.1
Accept: text/plain
Accept: application/json
Content-Type: application/x-www-form-urlencoded
host: <idcs-host>

While instead the expected format should be:
POST /oauth2/v1/token HTTP/1.1
Accept: text/plain
Accept: application/json
Content-Type: application/x-www-form-urlencoded
host: <idcs-host>

Section 5 of RFC 2116 is a bit ambiguous about the Request-URI format responsibilities:
To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
To avoid such kind of issues, the Helidon WebClient should used absolute URI only when effectively required, or make this behavior configurable.
Steps to reproduce
Add a proxy to your configuration:
client:
 proxy:
   host: someproxy.url
   port: 80
   no-proxy:
     - localhost
     - .oc9qadev.com

It only seems to happen with idcs token request.
Here is a detailed trace.
Without proxy it sends:
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 4f 53 54 20 2f 6f 61 75 74 68 32 2f 76 31 2f |POST /oauth2/v1/|
|00000010| 74 6f 6b 65 6e 20 48 54 54 50 2f 31 2e 31 0d 0a |token HTTP/1.1..|
|00000020| 41 75 74 68 6f 72 69 7a 61 74 69 6f 6e 3a 20 62 |Authorization: b|
|00000030| 61 73 69 63 20 51 55 6c 42 51 31 4e 66 51 31 68 |asic QUlBQ1NfQ1h|

With proxy configures it sends:
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 4f 53 54 20 68 74 74 70 73 3a 2f 2f 69 64 63 |POST https://idc|
|00000010| 73 2d 65 61 39 36 34 31 30 63 64 31 65 38 34 33 |s-ea96410cd1e843|
|00000020| 66 63 62 32 35 34 61 34 35 35 33 37 63 62 31 37 |fcb254a45537cb17|
|00000030| 35 63 2e 69 64 65 6e 74 69 74 79 2e 63 39 64 65 |5c.identity.c9de|
|00000040| 76 32 2e 6f 63 39 71 61 64 65 76 2e 63 6f 6d 3a |v2.oc9qadev.com:|
|00000050| 34 34 33 2f 6f 61 75 74 68 32 2f 76 31 2f 74 6f |443/oauth2/v1/to|
|00000060| 6b 65 6e 20 48 54 54 50 2f 31 2e 31 0d 0a 41 75 |ken HTTP/1.1..Au|
|00000070| 74 68 6f 72 69 7a 61 74 69 6f 6e 3a 20 62 61 73 |thorization: bas|
|00000080| 69 63 20 51 55 6c 42 51 31 4e 66 51 31 68 66 51 |ic QUlBQ1NfQ1hfQ|

@istaveren This is identical to #2302. I guess what you're stating here is that the fix for that original issue is somehow incomplete. It should definitely be in 2.3.X.

Yes, correct. I think the original fix is incomplete or the same problem happens when a proxy is used.

PR #3442

Should be fixed by PR #3442. Reopen if you find any problems.


[2201.9.x] Fix creating redundant future values for default value function calls

Purpose
$subject
Fixes #42566
Approach
Happens only when record values with defaultable fields are created outside of Ballerina runtime - E.g. : netty environment
Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Before the fix:

After the fix:

The master PR is failing for the Full Build Pipeline. I am checking it currently.


AWS CLI bash script bug fix

The AWS CLI bash script wont run on boot up, need to be investigate further as ./bin/install_aws_cli runs without fault.

The bug magically fixed itself after a short break and a CDE refresh.


cannot install centos:latest

python install.py rootfs_centos_latest.tar.xz
[*] Probing the Linux subsystem...
[!] Failed to get home directory of default user in WSL: [WinError 2] 。

Do you have WSL installed already? You need a working installation first.
Are you running the script inside WSL or from command prompt? You need to run it from command prompt, outside of WSL, while WSL is not running.

I'm getting the same error on my desktop trying to install Fedora 23. To answer your questions:

Yes WSL is installed and working.
Running the install script from command prompt outside of WSL directory and WSL is not running.

As a side note, I have used the distro switcher for a month or so on my laptop now and it has worked fine.

There are a few people reporting similar errors. I'll try to install a fresh insiders build and run the script on a few distributions, in order to see if anything is broken.
For the record, what build of Windows 10 are you using?

Version 1607, build 14393.693

Have you been able to resolve this issue? If not, I will be requiring more information, since I cannot reproduce it.

I have not been able to. I was planning to try reinstalling lxss since I don't have anything critical on it currently.

FWIW, I was able to get centos:latest installed as of today, 3/30/2017. However, I cannot restart services, I get the following error when trying to run systemctl:
Failed to get D-Bus connection: Operation not permitted

I'm getting the same error when trying to py install.py nixos/nix. Any suggestions? I tried to run this immediately after alwsl (which completed successfully).

Hmm! Running the following command in Windows (cmd shell):
c:> lxrun /setdefaultuser someuser

seems to create the registry values! I'll try to run install.py again with this...

As to my intended docker repo (nixos/nix), after successful install.py, when trying to run "bash" I'm getting 0x80070002, so I assume it's the same as #20, meaning roughly that Alpine Linux doesn't currenly work on WSL.

RoliSoft , add lxrun /setdefaultuser username to the README, please.


Release OpenPCDet v0.5.0

Improve the performance of all models on Waymo Open Dataset. Note that you need to re-prepare the training/validation data and ground-truth database of Waymo Open Dataset (see GETTING_STARTED.md).
Support anchor-free CenterHead, add configs of CenterPoint and PV-RCNN with CenterHead.
Support lastest PyTorch 1.1~1.10 and spconv 1.0~2.x, where spconv 2.x should be easy to install with pip and faster than previous version (see the official update of spconv here).
Support config USE_SHARED_MEMORY to use shared memory to potentially speed up the training process in case you suffer from an IO problem.
Support better and faster visualization script, and you need to install Open3D firstly.

Windows does not support SharedArray，so i can not install pcdet v0.5.How to solve the problem?

Traceback (most recent call last):
File "E:\PythonFile\OpenPCDet-master---updated\tools\demo.py", line 112, in
main()
File "E:\PythonFile\OpenPCDet-master---updated\tools\demo.py", line 98, in main
pred_dicts, _ = model.forward(data_dict)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\detectors\pv_rcnn.py", line 11, in forward
batch_dict = cur_module(batch_dict)
File "D:\Anconda\envs\pytorch\lib\site-packages\torch\nn\modules\module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\roi_heads\pvrcnn_head.py", line 149, in forward
targets_dict = self.proposal_layer(
File "D:\Anconda\envs\pytorch\lib\site-packages\torch\autograd\grad_mode.py", line 28, in decorate_context
return func(*args, **kwargs)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\roi_heads\roi_head_template.py", line 89, in proposal_layer
selected, selected_scores = class_agnostic_nms(
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\model_utils\model_nms_utils.py", line 17, in class_agnostic_nms
keep_idx, selected_scores = getattr(iou3d_nms_utils, nms_config.NMS_TYPE)(
File "e:\pythonfile\openpcdet-master---updated\pcdet\ops\iou3d_nms\iou3d_nms_utils.py", line 98, in nms_gpu
num_out = iou3d_nms_cuda.nms_gpu(boxes, keep, thresh)
RuntimeError: expected scalar type Int but found Long

The above is my error message（that i  have  #SharedArray）

`assert boxes.shape[1] == 7
order = scores.sort(0, descending=True)[1]
if pre_maxsize is not None:
order = order[:pre_maxsize]
boxes = boxes[order].contiguous()
keep = torch.IntTensor(boxes.size(0))

thresh = int (thresh)
num_out = iou3d_nms_cuda.nms_gpu(boxes, keep, thresh)

keep = torch.LongTensor(boxes.size(0))

return order[keep[:num_out].cuda()].contiguous(), None`

I replace those code in iou3d_nms_utils.py to solve this problem, but new error appear
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [32,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [33,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [34,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [35,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [36,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [37,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [38,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [39,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [40,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [41,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [42,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [43,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [44,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [45,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [46,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [47,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [48,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [49,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [50,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [51,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [52,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [53,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [54,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [55,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [56,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [57,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [0,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [1,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [2,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [3,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [4,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [5,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [6,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [7,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [8,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [9,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [10,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [11,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [12,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [13,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [14,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [15,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [16,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [17,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [18,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [19,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [20,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [21,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [22,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [23,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [24,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [25,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [26,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [27,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [28,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [29,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [30,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
C:\cb\pytorch_1000000000000\work\aten\src\ATen\native\cuda\IndexKernel.cu:93: block: [0,0,0], thread: [31,0,0] Assertion index >= -sizes[i] && index < sizes[i] && "index  out of bounds" failed.
Traceback (most recent call last):
File "E:\PythonFile\OpenPCDet-master---updated\tools\demo.py", line 112, in
main()
File "E:\PythonFile\OpenPCDet-master---updated\tools\demo.py", line 98, in main
pred_dicts, _ = model.forward(data_dict)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\detectors\pv_rcnn.py", line 11, in forward
batch_dict = cur_module(batch_dict)
File "D:\Anconda\envs\pytorch\lib\site-packages\torch\nn\modules\module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\roi_heads\pvrcnn_head.py", line 158, in forward
pooled_features = self.roi_grid_pool(batch_dict)  # (BxN, 6x6x6, C)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\roi_heads\pvrcnn_head.py", line 93, in roi_grid_pool
global_roi_grid_points, local_roi_grid_points = self.get_global_grid_points_of_roi(
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\roi_heads\pvrcnn_head.py", line 124, in get_global_grid_points_of_roi
local_roi_grid_points = self.get_dense_grid_points(rois, batch_size_rcnn, grid_size)  # (B, 6x6x6, 3)
File "e:\pythonfile\openpcdet-master---updated\pcdet\models\roi_heads\pvrcnn_head.py", line 135, in get_dense_grid_points
dense_idx = faked_features.nonzero()  # (N, 3) [x_idx, y_idx, z_idx]
RuntimeError: CUDA error: device-side assert triggered
CUDA kernel errors might be asynchronously reported at some other API call,so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
PS E:\PythonFile\OpenPCDet-master---updated\tools>


Fix 'see transaction details' from chat in nav2

cc @MarcoPolo, who suggested this approach

Okay, made a separate action for this. PTAL @cjb!


Add table aws_qldb_stream

References
Terraform Link
Go SDK Link

Closing this issue since the Amazon QLDB service is in a retirement state, and they have stopped supporting the creation of resources under the QLDB service. Announcement: https://docs.aws.amazon.com/qldb/latest/developerguide/what-is.html


Remove Capi Machines when deleting Hosts

Summary
PR Checklist

Is this a multi-tenancy feature/bug?

[ ] Yes, the relevant RBAC changes are at:

Do we need to backport changes to the old Rancher UI, such as RKE1?

[ ] Yes, the relevant PR is at:

Are backend engineers aware of UI changes?

[ ] Yes, the backend owner is:

Resolves https://github.com/harvester/harvester/issues/5258

Occurred changes

We are changing the behavior of Host's delete action by removing the CAPI machines only; It should trigger the node deletion in the backend then.

Technical notes summary

Added a custom prompt to safe confirm the Host to be deleted.
in case of capiMachine is null for the Node, then it deletes the node itself (current behavior).

Areas or cases that should be tested

Hosts page -> delete actions (menu and bulk)

Areas which could experience regressions

Screenshot/Video

Confirmation dialog

Capi machines delete

Is it possible to modify the dialog confirmation text as well. The current one is questionable.
Here are some things that i do not like:

Without looking into the message template, as a user i'm asking why Node is in upper case.
The sentence is too convoluted and does not clearly state the important question.
How is the {names} part of the template created. It seems a . (dot) is added somehow and the whole thing is rendered bold (which is good).
Emphasizing the {type} in the message template, e.g. {type} to make it clear that this IS the type of the processed resource.

Original
Deleting the {type} will remove all the resources on this particular {type} and this is not revertable, are you sure you want to continue deleting {names}?

Suggestion
Deleting the {type} will remove all the resources on this particular {type} . Attention, this is irreversible. Are you sure you want to continue deleting {names}?

Instead of Attention we can make use of Note, instead. Depends on what is used in other messages.
Note, {names} is already modified somehow, so  might not necessary here.


Use ndcube >= 2.0

We chatted about this on the PyAstro telecon - but did we decide to use NDCube master or 1.3.2?

Let's just jump in the end and say master. By the time this actually sees a release, NDCube 2.0 will be out so we can just pin to >2.0 when that happens

sounds like a plan

Though we have just "ndcube" in the setup.cfg so when you pip install -e . you get the latest stable version so there's some dissonance there I guess

ndcube 2.0 is in beta and will be out soon. We should adapt sunkit-dem to 2.0 and pin appropriately. It is likely that 2.0 is going to break a lot of things.


[ADAP-692] [Bug] snowflake-connector-python dependency version too strict

Is this a new bug in dbt-snowflake?

[X] I believe this is a new bug in dbt-snowflake
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
When using dbt with Airflow 2.5.1, python package installation fails because Airflow constraints snowflake-connector-python version to 2.9.0 which is incompatible to dbt-snowflake which requires 3.0.0
Expected Behavior
Package installation should not fail.
Steps To Reproduce
Create a requirements.txt file with content:
--constraint https://raw.githubusercontent.com/apache/airflow/constraints-2.5.1/constraints-3.10.txt
dbt-snowflake

pip install -r requirements.txt will fail
Relevant log output
The conflict is caused by:
    dbt-snowflake 1.5.2 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.5.1 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.5.0 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.4.3 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.4.2 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.4.1 depends on snowflake-connector-python[secure-local-storage]<2.8.2 and >=2.4.1
    dbt-snowflake 1.4.0 depends on snowflake-connector-python[secure-local-storage]<2.8.2 and >=2.4.1
    dbt-snowflake 1.3.2 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.3.1 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.3.0 depends on cryptography<37.0.0 and >=3.2
    dbt-snowflake 1.2.1 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.2.0 depends on cryptography<37.0.0 and >=3.2
    dbt-snowflake 1.1.1 depends on snowflake-connector-python[secure-local-storage]~=3.0
    dbt-snowflake 1.1.0 depends on snowflake-connector-python[secure-local-storage]<2.8.0 and >=2.4.1
    dbt-snowflake 1.0.1 depends on snowflake-connector-python[secure-local-storage]<2.8.0 and >=2.4.1
    dbt-snowflake 1.0.0 depends on snowflake-connector-python[secure-local-storage]<2.8.0 and >=2.4.1
    dbt-snowflake 0.21.1 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.21.0 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.20.2 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.20.1 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.20.0 depends on snowflake-connector-python[secure-local-storage]~=2.4.1
    dbt-snowflake 0.19.2 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.19.1 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.19.0 depends on cryptography<4 and >=3.2
    dbt-snowflake 0.18.2 depends on snowflake-connector-python[secure-local-storage]==2.2.10
    dbt-snowflake 0.18.1 depends on snowflake-connector-python[secure-local-storage]==2.2.10
    dbt-snowflake 0.18.0 depends on snowflake-connector-python==2.2.10
    dbt-snowflake 0.17.2 depends on azure-storage-blob<12.0.0
    dbt-snowflake 0.17.1 depends on azure-storage-blob<12.0.0
    dbt-snowflake 0.17.0 depends on azure-storage-blob<12.0.0
    dbt-snowflake 0.16.1 depends on azure-storage-blob<12.0.0
    dbt-snowflake 0.16.0 depends on azure-storage-blob<12.0.0
    dbt-snowflake 0.15.3 depends on azure-storage-blob~=2.1
    dbt-snowflake 0.15.2 depends on snowflake-connector-python<2.1 and >=1.6.12
    dbt-snowflake 0.15.1 depends on snowflake-connector-python<2.1 and >=1.6.12
    dbt-snowflake 0.15.0 depends on snowflake-connector-python<2.1 and >=1.6.12
    dbt-snowflake 0.14.4 depends on snowflake-connector-python==2.0.3
    The user requested (constraint) azure-storage-blob==12.14.1
    The user requested (constraint) snowflake-connector-python==2.9.0
    The user requested (constraint) cryptography==38.0.4

Environment
- OS:
- Python:
- dbt-core:
- dbt-snowflake:

Additional Context
The snowflake-connector-python requirement was bumped to 3.0.0 because of a snyk vulnerability see: https://github.com/dbt-labs/dbt-snowflake/commit/967a8e93b7e60a0442cc9f34b3b2172ecc085d5b
But it would have been sufficient to bump it to 2.8.2 or higher. The dbt-snowflake library can be a lot more flexible when the requirement is defined like so:
"snowflake-connector-python[secure-local-storage]>=2.8.2"

Happy to push a PR if the maintainers agree with this change.

@ivanstillfront thanks for opening this and doing your homework! I understand the frustration of too strict dependencies.
My hesitation is that we often experience user-facing issues that require fixes in the upstream connector library. The PR in which the snowflake connector version was bumped, #476, makes reference to #393 (correspondingly https://github.com/snowflakedb/snowflake-connector-python/pull/1274)
As we speak, we're finally on a path to resolving a long-standing multi-threading seg fault issue that dbt-snowflake users have been experiencing in both Core and Cloud that will also likely be resolved in  https://github.com/snowflakedb/snowflake-connector-python/issues/1627. Once this happens we plan to bump the minimum required version of the connector to 3.0.5 for at least versions 1.5 and 1.6 of dbt-snowflake.
I'm not trying to say that we don't want to fix your problem, rather that's the perspective from which we've been thinking lately. Maybe there's a middle ground here? Can we open a PR with airflow to bump the upper limit on their version constraint? I'd love to hear more about your perspective on next steps. cheers

Thank you @dataders , @nenkie76 has opened an issue with AWS MWAA but I doubt they will modify the constraints because they are provided by Airflow
Since AWS maintains the constraints for their managed Airflow system our hands are tied in this matter. Our only options are to fork dbt-snowflake or run our own Airflow deployment.

@ivanstillfront appreciate the teamwork! I accidentally went down a rabbit hole and have some information to share.
your file, constraints-2.5.1/constraints-3.10.txt does indeed have an earlier version of the connector library, but the version I saw on mentioned on the main branch of the Airflow repo is constraints-main/constraints-3.8.txt, which actually has the latest version of snowflake_connector_python pinned.
https://github.com/aws/aws-mwaa-local-runner/pull/243 was instructive to discover that this AWS managed airflow repo depends on another PyPI package sauce, apache-airflow-providers-snowflake (PyPI). The latest version of this package is 4.3.0
Therefore I don't believe that apache-airflow-providers-snowflake is the issue because, iiuc, this provider pacakge specifies snowflake-connector-python>=2.4.1 (sauce)
Instead, I'm very suspicious of how aws/aws-mwaa-local-runner's Docker image is configured. There is a hard-coded, committed docker/config/constraints.txt  in which apache-airflow-providers-snowflake is hard pinned to be 4.0.2. Until April 11, this requirement was 3.3.0.
The first two lines of that file are telling
# This constraints file was automatically generated on 2023-01-18T18:46:04Z
# via "eager-upgrade" mechanism of PIP. For the "v2-5-test" branch of Airflow.

I still am very uncertain as to how Airflow uses a static GitHub links to auto-generate these constraint files, but certain enough to be suspicious of hard-coding.
Airflow's guidance on the constraints file, apache/airflow/blob/main/constraints/README.md, says the following

For development use only, you can store your own version of constraint files used during CI image build here and refer to them during building of the image using --airflow-constraints location constraints/constraints.txt This allows you to iterate on dependencies without having to run --upgrade-to-newer-dependencies flag continuously.

I think the real "issue" is that this constraints file is being used "in production" when it really is only for a temporary, local development and CI build environments. The smoking gun for me is that all of those dependencies are hard-pinned (`==) which by definition is not flexible.
The workaround, imo, would be to submit a pull request to aws/aws-mwaa-local-runner in which you updated the existing constraints file to refer to a newer version?
The long-term solution is to improve the version specification strategy that is implemented by aws/aws-mwaa-local-runner

@ivanstillfront closing this issue for now. please re-open if you think there's a way we can be of help here

@dataders thank you for that elaborate investigation, sorry I could not reply sooner. You are correct, AWS is using the constraints "in production" which is a huge PITA to work with. Here is their documentation on this matter: https://docs.aws.amazon.com/mwaa/latest/userguide/working-dags-dependencies.html#working-dags-dependencies-syntax-create
Long term, we will most likely stop using AWS managed Airflow and roll our own deployment. For now, we have forked dbt-snowflake and patched install_requires in setup.py to satisfy the constraints.


Update Regal to v0.23.1

Hi there! It's been a while :)
I figured I'd see how the latest Regal release would work here, and it worked just well. Just some minor changes needed:

Remove rules from config that aren't needed
Add configuration for new rules (only 'messy-rule' needed)
Modify 'no-whitespace-comment' config to allow common exception
Fix 'identically-named-tests' violation by renaming the tests

@Sloane4 done 👍 Also tested using Regal main and lints without issues there too :)


Remove Remote Resources

Remove Remote Resources (e.g. Google Fonts and other third parties) from the Source Code. GDPR Compliance

Noted for further inspection

Bump

thx4bump, am working on it

Okay I ran into a problem:
For some reason, I can import the font into BSS as a file but can't remove the import line in the HTML as it's forced. I think we could check for a change with some action at upload and remove the line via that as I'm too lazy to do it myself every time.

lol

should be fixed in #5 <3


Expose config settings for navigation service.

Hi,
This query is to expose config settings for navigation service. This can be achieve using Get.config:

Get.config(
      enableLog = true,
      defaultPopGesture = true,
      defaultTransition = Transitions.cupertino}

Regards,

This request was to access the transition properties of the Get package. We can accomplish this by annotating our routes with CustomAutoRouter and CustomRouter.
If we want to use custom transitions for specific routes, pr #38 will address these types of actions.


added an API call

Didn't clean it up.
Still need to finish the complete list of pairs functionality.
I got a free API key, stored in keys.json.

Awesome job here, let me know if you need any help with this or if you get stuck on anything.


Unexpected higher parameter count after sparsification

Describe the bug
Estimated parameter count 1.2 million but getting 7 million for original 7.2 million parametr model
Expected behavior
model expected to have 1.2 million
Environment
Include all relevant environment information:

OS : Ubuntu 20.04.3 LTS
Python version: 3.9.1

To Reproduce
1)yolov5 model
2)convert to onnx
3)made recipe file using sparsify , showed for 80 %sparsification, expected parameter 1.2 million form 7.2 million model
4)Followed github commands and san sparsification, after sparsification got 7 million paramters.
Errors
7 million parameters

Hi @vipulnath, pruning does not explicitly remove parameters, but rather sets the pruned ones to 0. So the number of parameters the yolov5 library returns is not actually indicative of the set of "active" parameters in your model. You can manually check the sparsity of your model by looking at the weight tensor values, but I'd recommend deploying the model with DeepSparse and tracking your inference speedups instead. Also, functionality to automatically calculate your model's sparsity will be released with a suite of new model-management features soon, so stay tuned (:

unstructured pruning does not explicitly remove parameters, but rather sets the pruned ones to 0.

Can the SparseML library use sparse matrix implementation for unstructured pruning? I mean, instead of setting pruned parameters to 0, can the SparseML library turns the pruned parameter tensor in "sparse matrix" format in an hope to reduce model size and inference time?


Switch to ES6 modules in tslint source

Rather than TS internal modules / namespaces, let's try to switch to ES6 modules.
This would also fix #280.

You can't use ES6 modules, this runs on node.
Sent from a phone
On Jun 24, 2015, at 18:07, Adi Dahiya <notifications<EMAIL_ADDRESS>wrote:
Rather than TS internal modules / namespaces, let's try to switch to ES6 modules.
This would also fix #280https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_tslint_issues_280&d=BQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=jafYnmwAIy7b95Z05TKJr1hFAxZozsv6_JDDlWyuJk8&m=A1zEfDJcMFAw9wcFb7eDHMq1wWD8s9bOkUB1J3pxUtg&s=8FIxA4rLx2aGdgt4LcvNVMOjcnmtNaa8gClujchFJpk&e=.
—
Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_tslint_issues_465&d=BQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=jafYnmwAIy7b95Z05TKJr1hFAxZozsv6_JDDlWyuJk8&m=A1zEfDJcMFAw9wcFb7eDHMq1wWD8s9bOkUB1J3pxUtg&s=MU3P6AscJ3-DzTqdIaBkjLF9eneuo-ycFps5rME785E&e=.

from https://github.com/Microsoft/TypeScript/issues/2242

TypeScript supports down-level compilation of external modules using the new ES6 syntax.

cool!


quiche congestion control based on ECN

Hello
I saw in quiche documentation that there are two congestion control algorithm
based on Reno and Cubic  used by quiche (QUIC implementation) to detect and control congestion.
But I would like to know if there is an other congestion control algorithm that uses ECN marking
to detect or control congestion or if the algorithms based on Reno and Cubic can used ECN marking
to manage congestion?
Your help will be apprecieted
Regards

Currently we don't implement ECN bits.


pip-29: Draft Batch Transactions

Draft for a new PIP to define Batch Transactions in Pactus.
Should be discussed and get completed.

@maxipaz Please fix request changes before merge.


Font Awesome render as  not

can you help me with this issue? it working correctly but the icon not rendering as svg but as
<i aria-hidden="true" class="fa fa-angle-right"></i>

it should be SVG, which version and browser you are using?

i'm using "version": "2.0.11"

version 2.0.11 using fontawsome 4, it should be an SVG file,  maybe you should check if your package installed correctly, can't help you without more details.

@luhegi, I was wrong with the version, it's using fontawesome 5, can't help you if you can't provide more details.

i'm using https://github.com/cretueusebiu/laravel-vue-spa, he using font awesome 5 in resources/assets/js/plugins/fontawesome.js

@luhegi I've been checked again with larave-vue-spa, there was no issue for using this plugin, please make sure you are using it correctly. This issue should be closed now since it's not this plugins problem.

ok, thanks for checking. i'll try to fix it


Expose Integration Flow Endpoint as API and Test the Flow

Tutorials: https://developers.sap.com/tutorials/cp-starter-isuite-api-management.html
Step 3: Copy credentials from service key : The default instance name that the booster provides is 'default-it-rt-integration-flow'
Please update the sentence in the tutorial accordingly.
Expected:

Actual:

@NidhiMurkute - the issue is fixed. will publish as soon as I have other feedback from your entire testing.

@NidhiMurkute - the issue is fixed. will publish as soon as I have other feedback from your entire testing.

@MichaelCzcz - I'm not able to close the issue which I used to do in the past. Could you please check why am I not able to close?


Added --sort to ps

Also podman ps now allows user to only output size of root FS, and changed language of images and ps --sort to be sorted by "created" as opposed to "time".
Finishes fix: #898
Signed-off-by: haircommander<EMAIL_ADDRESS>

LGTM

before merging this, id like to run some perf on it and see what comes out...ill work with @haircommander on that first thing next week.

@mheon and I decided on IRC to change when the sorting happens. It now occurs before template or JSON output is decided, so now JSON and templated output can be sorted. This refactor is in anticipation for a larger job of moving away from the way ps is outputted, because it is currently a large bottleneck. PTAL @rhatdan @TomSweeneyRedHat @baude

LGTM

@rh-atomic-bot r+


Ui improvement

Hitting the Enter key on input field will not be able to submit. Previously only hitting the submit button allows you to submit.
Got rid of the constant refresh of state that cause old submitted data to be wiped every time you type something new into the input field.

Nice! I tested it out and it works as intended. Thanks!

Thanks!


add isJWT validation

isJWT() can be useful for validating user tokens sent in querystring parameters in WebSocket connections

Probably best achieved with .regex()

You can use .refine(value => validator.isJWT(value)) where validator comes from https://www.npmjs.com/package/validator


Add PL translation for #481

💥  Thanks @Koziolek
@kdebowski could you look at this one too?

@Koziolek It's ok


Resume from Kodi library

Hello
Every time I try to resume a movie or a show from Kodi library, it start from the beginning and not from the place I stop watching earlier.
Is this normal or you can fix it?
Thanks

No log = no help.

I think that's it
Log.txt

I don't see anything special.
You can try a test case:

scrape movie/show with TMDB (not TVDB).
start a playback, seek to somewhere, stop.
start a playback again.

Then post a log file, so I can see what is there.

Any information?

Resume is done and requested by Kodi.
If item (show/movie) is added to Kodi - we will try to find it and force resume function.
If not added to Kodi - it's all about Kodi.

I have the same problem. I am using elementum with download in memory, and Kodi doesn't even offer me to resume elementum movies. I've added movie to the library, and there si indicator that movie was partially watched, but when trying to play movie there is no resume option. Local movies or shows resume with no problem. Is there anything I need to setup in Elementum addon settings to make this work?

@qzem it will be, probably, fixed in 0.1.* branch, which is in development currently.

@qzem it will be, probably, fixed in 0.1.* branch, which is in development currently.

Thank you for a quick response. BTW, great work so far!


Service port should be configured to listen on 8080

Suggest that step 12 of the instructions under Connect and select your repository should be amended.
The step currently states:

You can leave the image name and the service port set to the defaults.

Suggest that this is changed to:

You can leave the image name set to default.
Change the service port to 8080.

This will configure the service port to list on 8080 which the text further down the document implies should be the chosen port.
Step 6 under See your app deploy states:

Open a new browser tab or window and enter :8080.

I have also raised an issue on the referenced repository because a recent pull request has changed the port the express app listens on from 8080 to 3000.

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

ID: 0717d289-c339-ed12-4d24-3d968121c75d
Version Independent ID: c20939c5-96b4-e4c5-6737-e3407d52f3de
Content: Deploy to Azure Kubernetes Service with Azure Pipelines - Azure Kubernetes Service
Content Source: articles/aks/devops-pipeline.md
Service: container-service
GitHub Login: @juliakm
Microsoft Alias: jukullam

Thanks for reporting this. I have assigned the issue to the content author to investigate further and update the document as appropriate.


[Question]:  "Table 'rag_flow.knowledgebase' doesn't exist" and  "Table 'rag_flow.document' doesn't exist"

Describe your problem
pymysql.err.ProgrammingError: (1146, "Table 'rag_flow.knowledgebase' doesn't exist")

Thanks for following!
Mysql didn't initialize properly.
Recommand, remove all the data and try that again.
docker compose down -v
docker compose up

Thanks for following!
Mysql didn't initialize properly. Recommand, remove all the data and try that again.
docker compose down -v docker compose up

same error, it doesn't work

Thanks for following!
Mysql didn't initialize properly. Recommand, remove all the data and try that again.
docker compose down -v docker compose up

same error, it doesn't work

change this num as 180
then input this command
docker build -t swr.cn-north-4.myhuaweicloud.com/infiniflow/ragflow:v1.0 .
docker compose -f docker-compose-CN.yml up -d


words is removed from load_embedding() and sample_embedding() parameters

found a minor error in review.py while loading embedding

Good catch. @qubixes ran into the same problem. See PR #9. I will merge #13 first because #9 is not ready yet.