Add support for named exports

Summary
See https://github.com/gregberge/loadable-components/issues/245
Currently to create a loadable component, the module that is asynchronously loaded must export the component as the default export (or be a commonjs module exporting the component as module.exports). This is problematic/limiting because:

There are good reasons to avoid default exports (prevents grepping a codebase to find usages of an export, prevents import auto completion from working in most/all IDEs)
It is not possible to make multiple loadable components using the same split point (instead one must hard code chunk names with webpack "magic comments" - not a standard feature)

Detailed choices
See https://github.com/gregberge/loadable-components/issues/245 for preliminary discussion of the API

loadable and loadable.lib still accept the import creator as the first argument. This means that for the common/simple case of loadable(() => import('./xyz')), there is no breaking change, instead options are added.
resolveComponent is optional and defaults to the existing behaviour. Again, no breaking change, but typescript type inference (for the props of the loadable component) does not work unless it is specified. I think this is a consequence of the CommonJS compatibility.

Benefits
Ability to use named exports (including on the server side)
Use resolveComponent to select the export
Ability to create multiple loadable components from a single split point
// split.tsx
import React from 'react';

type Props1 = {
  prop1: string;
};

export const Component1 ({ prop1 }: Props1): JSX.Element => (
  {prop1}
);

type Props2 = {
  prop2: string;
};

export const Component2 ({ prop2 }: Props2): JSX.Element => (
  {prop2}
);

import loadable from '@loadable/component';

const LoadableComponent1 = loadable(() => import('./testComponent'), {
  resolveComponent: (mod) => mod.Component1,
});

const LoadableComponent2 = loadable(() => import('./testComponent'), {
  resolveComponent: (mod) => mod.Component2,
});

resloveComponent has access to props
import loadable from '@loadable/component';
const DynamicLoadableComponent = loadable(() => import('./xyz'), {
  resolveComponent: (mod, props) => mod[props.export],
});

Typescript type inference
When using resolveComponent, typescript is able to infer the type of the Props of the loadable component (previously they were always unknown). I think the default type/implementation of resolveComponent breaks type inference somehow by supporting commonjs default exports.
Before
// testComponent.tsx
import React from 'react';

type TestProps = {
  prop1: string;
};

export default ({ prop1 }: TestProps): JSX.Element => (
  {prop1}
);

// loadableTestComponent.ts
import loadable from '@loadable/component';

// Inferred type: `LoadableComponent<unknown>`  :(
const LoadableComponent = loadable(() => import('./testComponent'));

After
// testComponent.tsx
import React from 'react';

type TestProps = {
  prop1: string;
};

export default ({ prop1 }: TestProps): JSX.Element => (
  {prop1}
);

// loadableTestComponent.ts
import loadable from '@loadable/component';

// Inferred type: `LoadableComponent<TestProps>` :)
const LoadableComponent = loadable(() => import('./testComponent'), {
  resolveComponent: (mod) => mod.default,
});

Test plan

Existing tests have been changed where necessary and new tests have been added for new functionality

Amended types: https://github.com/DefinitelyTyped/DefinitelyTyped/compare/master...hedgepigdaniel:loadable-named-exports?expand=1

Will this feature be in next release ?

there should be some updates to the readme/site about the new feature
watchdog sounds a bit strange for me. So it is a secondary promise resolver, which might do nothing more, but delay loadable resolution a bit, but only in "async" mode. It sounds more like a condition or guard. For example, I am using something like it to "delay" lazy component resolution till extra .css files, previously "critically inlined" got loaded.

there should be some updates to the readme/site about the new feature

I've added documentation to the website to go with each commit

watchdog sounds a bit strange for me. So it is a secondary promise resolver, which might do nothing more, but delay loadable resolution a bit, but only in "async" mode. It sounds more like a condition or guard. For example, I am using something like it to "delay" lazy component resolution till extra .css files, previously "critically inlined" got loaded.

I thought of "watchdog" because its like a parallel process that supervises the loading process and may intervene if it goes wrong. "guard" also sounds fine to me, so I've updated it to be called "guard". That probably fits better with delays (the guard took a while to let the promise through) vs timeouts (the guard gave up waiting for the promise and rendered the error state).

Also, I've put the commit that changes the Babel plugin last.
So if you wanted to delay the breaking change, this could be released in two steps:

New features resolveComponent and guard, updates to documentation to stop recommending wrapping the import promise and instead recommend guard for delays and timeouts
Breaking change: the Babel plugin makes an error if the import() is wrapped

You have got the approval from me. I like the change to the API, and I like the implementation. @gregberge - please take a look.

Hello guys! @hedgepigdaniel @theKashey
First, thanks for your work on this feature! It is great!
I think we could make the API more generic and more powerful. I explain my idea:
import loadable from '@loadable/component'

const Loadable = loadable(() => import('./components'))

// this function has to be synchronous, it is called on client and server
Loadable.resolveProps = ({ $component, $module, props, ctx }) => {
  // we got some data from context
  const data = ctx.books[props.id]
  // we are able to change the component
  return { $component: $module.Foo, props: { ...props, data } }
}

// this function will only be called on client-side, it can be asynchronous
Loadable.resolveContext = async ({ props }) => {
  // we actually load data dynamically with the component
  const book = await getBook(props.id)
  // we could also add a default delay
  await delay(200)
  // we are able to change the component
  return { books: { [props.id]: book  }
}

<Loadable id="10" />

On the server, we will be able to pass a context:
const  book = await getBook(req.params.id)
const ctx = { books: { [req.params.id]: book }  }
const extractor = new ChunkExtractor({ statsFile, ctx })

If Suspense is available one day, resolveContext could be called on server-side. For now it is not possible.
What do you think?

Another proposal:
import loadable from '@loadable/component'

const Loadable = loadable(() => import('./components'))

Loadable.resolveProps = () => {

}

// this function will only be called on client-side, it can be asynchronous
Loadable.getContext = async ({ props }) => {
  // we actually load data dynamically with the component
  const book = await getBook(props.id)
  // we could also add a default delay
  await delay(200)
  // we are able to change the component
  return { books: { [props.id]: book  }
}

// this function has to be synchronous, it is called on client and server
Loadable.resolve = ({ $component, $module, props, ctx }) => {
  // we got some data from context
  const data = ctx.books[props.id]
  // we are able to change the component
  return { $component: $module.Foo, props: { ...props, data } }
}

<Loadable id="10" />

On the server, we will be able to pass a context:
const  book = await getBook(req.params.id)
const ctx = { books: { [req.params.id]: book }  }
const extractor = new ChunkExtractor({ statsFile, ctx })

If Suspense is available one day, resolveContext could be called on server-side. For now it is not possible.
What do you think?

Oups I closed it!

Data loading is great, but it should be like a "single point of truth". Ie getContext should be also called - on the clientside, as well as on SSR.
Data loading is important, and it could work "this" way after Suspense, but right now it has to be finished before the render, and bound to the routing.
getContext might use some hooks(useContext) to provide data for a component, as well as suspense features in the future, but in sync way, so it should be more compatible with today.

hey, thanks for taking a look at this.

What do you think?

getContext is first defined on a particular loadable component, but on the server side it's passed to the entire react tree? This seems imconsistent.
Is Loadable.resolve the part that can resolve named exports? If so, how is it possible that it receives the resolved component as a prop already?
having options assigned imperatively (e.g. Loadable.resolve = ...) will make it hard for type inference to know the type of the loadable component

Having a way of passing extra props to the component seems neat, but I'm not sure how to do it consistently without suspense. If you have to set up 2 different methods for SSR and client side, I suspect using an external state management instead (e.g. Redux + route based data loading) would work better.

You are right. Data fetching is another problem, not our business here.
Your implementation is nice. I am wondering if guard is enough explicit or not.

Well, let's think what it is:

it is a guard(as seen in type guards, or more like xstate guards, which prevent state transition)  - it might stop something
it is a check - it might perform some operation, or wait for some operation before resolving import promise
it a timeout - it might reject, causing component to fall into the error state
it is only for clientside, only for async, and it also could be async
and we don't care about the result, only about "open" or "close" mode.

It could be a guard, it could be a gateway.
Another question - why we might use it:

to emulate time-in, like "flash of loading content". The better option would be to use useTransition, which is not yet "official", but roughly reflect how one should handle a situation like this.
to emulate time-out, but it could be done in another, more suspense friendly, way. Like Suspense fallback might change some state after timeout, causing Application to display an error state.
to wait for some "external" condition. I personally use it with critical CSS extraction - like before "resolving" split code I have to "reinject" slit css. A quite rare case.

So what about just not mark this option as an experimental? I am pretty sure not many people were using this functionality so far, as long as they would had their SSR broken, and React.lazy does not provide anything like this, and people are "ok" with it...

Another option is to have options more specifically tailored to common use cases. For example:

Add built in minDelay and timeout options (probably 95% of the use cases for guard)
rename guard to something related to loading extra modules/requests... e.g. loadExtra or sideload (probably 95% of the remaining use cases)

Marking it as experimental or simply not adding the option is also fine (and therefore not making the babel plugin complain basically the first 2 commits only). That still makes named exports possible, which is the most important thing.
My thinking in including that change here is that it is confusing that the current loadFn works differently on the server side - delaying the promise works as you would hope, but changing its return value fails spectacularly. That is a trap for users, and trying to use named exports with the current API is one way you can fall into that trap, as in https://github.com/gregberge/loadable-components/issues/245.

rename guard to something related to loading extra modules/requests

Which would not be called if this components was SSRed and loaded in a "sync" way, so please don't put any valuable logic inside. 😒
From a customer point of view it would be great to have just a global option to control minDelay/timeout, both of them could be "fixed" from the outside of Loadable component. In a bit harder way, but could.

OK, I've separated out the guard part into https://github.com/gregberge/loadable-components/pull/511, since that seems like its controversial/unclear and its not the most important thing.
So now this is just adding the resolveComponent option, which is the minimum for named exports to work.

Back online. Where are we?

@theKashey I will try to merge it this week-end

#97 shows us how it is not natural for users to use resolveComponent instead of doing it in the function.
I have another idea. Why not supporting only async function, we could replace the async function to a synchronous one and replace all await import() by a synchronous one. What do you think?

But it will be asynchronous in the "client-side" space, so we still have to support sync and async.

But it will be asynchronous in the "client-side" space, so we still have to support sync and async.

I mean:
const Loadable = loadable(async () => {
  const { Foo } = await import('x')
  return Foo
})

Will be transformed in:
const Loadable = loadable(() => {
  const { Foo } = syncImport('x')
  return Foo
})

What do you think?

So I will explain my vision:
resolveComponent is not intuitive for users and make the library more complicated than it should. The usage is not natural.
The natural usage is to use that syntax:
const Loadable = loadable(async () => {
  const { Foo } = await import('x')
  return Foo
})

With this syntax, we can easily detect that the user extract { Foo } from import('x'). It means that we have the information.
The idea is to infer the synchronous operation:
function load() {
  const { Foo } = importSync('x')
  return Foo
}

Complex cases
If we allow an async function, users would be able to do something much more complex:
const Loadable = loadable(async () => {
  const { Foo } = await timeout(import('x'), 2000)
  return Foo
})

What do we have here, we can easily detect that there is a pattern await <not an import>. In this case we can't infer the synchronous operation, the user have to write it:
const resolveComponent = ({ Foo }) => Foo
const Loadable = loadable(async () => {
  return resolveComponent(await timeout(import('x'), 2000))
}, {
  loadSync(props, { importSync }) {
    return resolveComponent(importSync('x'))
  }
})

It has several advantages:

In most of cases it does not require any code to work
It supports multiple import() in a single function
It supports custom components creation

Custom component creation
const Loadable = loadable(async () => {
  const { data } = await import('./data')
  const { Hello } = await import('./Welcome')
  return () =>
<Hello />

})

This custom component could work without any problem!
What do you think?

Ok, so here are my thoughts:

I am not sure I personally capable not only to create, but even to design, a babel plugin to do the job. That would be a very complex transformation, and we don't need it.
But you can use babel/ts transform to rewrite import to loadableRequire in all places.

That is all we need

loadableRequire would detect the origin of a call (LoadableComponent will set a scope)
if called from the user code - it shall behave like a normal import
if it called from the loadable - it shall try to be synchronous,
if that is not possible - it shall 😄 throw a Promise.
if it is possible - it shall report used module/chunk/mark to the caller (loadable)

@theKashey I don't get it. If the function is async then we can't do anything to make it synchronous except a babel transformation isnt'it?
About the Babel transformation, I think I could write it.

@theKashey I don't get it. If the function is async then we can't do anything to make it synchronous except a babel transformation isnt'it?

You are transforming only import, not a "function".
However, 😢, in this case stuff like TS will stop you from doing that.

The natural usage is to use that syntax:
const Loadable = loadable(async () => {
  const { Foo } = await import('x')
  return Foo
})

With suspense this would be the clear path forward, but given that we still need to synchronously resolve the component on the server side, It can't work 100% like that (somewhere there has to be a compromise).
The main difference with this proposed API and what I've written is that it doesn't require a second function (resolveComponent or loadSync) to handle a case where loadFn simply returns a key in the module. Let's call this API "exports" (because its automatic for exports of the module), and the code as I've written it "default" (because its automatic for the default export).

:heavy_check_mark: Automatic from only loadFn
:large_orange_diamond: Manual with resolveComponent/loadSync
:x: Not possible

status quo
"default"
"keys"

default export
:heavy_check_mark:
:heavy_check_mark:
:heavy_check_mark:

directly* return named export
:x:
:large_orange_diamond:
:heavy_check_mark:

return named export in non obvious way
:x:
:large_orange_diamond:
:large_orange_diamond:

also do async things on client side
:x:
:large_orange_diamond:
:large_orange_diamond:

use helper function to return export
:x:
:large_orange_diamond:
:large_orange_diamond:

You could spend a very long time making the babel plugin more and more complex so that it can handle more of these cases automatically with only loadFn, but it would never work automatically 100% of the time. There will always be more ways to return a component in loadFn that the Babel plugin can't handle.

resolveComponent is not intuitive for users and make the library more complicated than it should. The usage is not natural.

What is not natural about it?
I think its still an improvement on the current API. Currently loadFn can do async things, but these silently fail on the server side. This is a big problem. It is inconsistent and confusing for users, and causes bugs. Specifying resolveComponent is slightly annoying (2 functions instead of just one), but is 100% consistent with no traps (it always works the same, client side or server side). And it lets you use any component you can get synchronously from the imported module, which is currently not possible.

It has several advantages:

I think all these things are supported well enough with the resolveComponent API

* In most of cases it does not require any code to work

resolveComponent is not needed for when you use the default export, which is already most of the time (currently 100% of the time, because non default exports don't work). True this alternative is more automatic, but its also more complex and the boundary between what is automatic and what isn't is harder to define.

* It supports custom components creation
* It supports multiple `import()` in a single function

You can do this with resolveComponent as follows:
// async.js

export { Apple } from './apple';
export { Banana } from './banana';

// loadable.js

const Loadable = loadable(() => import('./async'), {
  resolveComponent: ({ Apple, Orange }) => () =>
<Apple /><Orange />
,
});

It's better to have only one import() since then there is only one split point, and bundlers like webpack know to create only one chunk rather than two.

Meanwhile in the parallel universe: Suspense would work for SSR as well. Eventually, and probably quite soon.
We should design a future API with that "future" in mind. This also includes stuff like non-components to be trackable throughout the library, and that's not only about loadable.lib

So I will explain my vision:
resolveComponent is not intuitive for users and make the library more complicated than it should. The usage is not natural.
The natural usage is to use that syntax:
const Loadable = loadable(async () => {
  const { Foo } = await import('x')
  return Foo
})

With this syntax, we can easily detect that the user extract { Foo } from import('x'). It means that we have the information.
The idea is to infer the synchronous operation:
function load() {
  const { Foo } = importSync('x')
  return Foo
}

Complex cases
If we allow an async function, users would be able to do something much more complex:
const Loadable = loadable(async () => {
  const { Foo } = await timeout(import('x'), 2000)
  return Foo
})

What do we have here, we can easily detect that there is a pattern await <not an import>. In this case we can't infer the synchronous operation, the user have to write it:
const resolveComponent = ({ Foo }) => Foo
const Loadable = loadable(async () => {
  return resolveComponent(await timeout(import('x'), 2000))
}, {
  loadSync(props, { importSync }) {
    return resolveComponent(importSync('x'))
  }
})

It has several advantages:

In most of cases it does not require any code to work
It supports multiple import() in a single function
It supports custom components creation

Custom component creation
const Loadable = loadable(async () => {
  const { name } = await import('./data')
  const { Hello } = await import('./Welcome')
  return () =>
<Hello /> {name}

})

This custom component could work without any problem!
What do you think?

It's great to support multiple import ideas.

@hedgepigdaniel the problem with your implementation is that it restricts a lot possibilities if you don't use the SSR.
Actually it is very easy, you can use anything in your async function. I want to keep that and to provide a way for user to fix their code for SSR. Adding a loadSync method is an easy migration path for the SSR user. And the non-SSR user keep all power.
We can't make an API more restrictive than React.lazy. The Babel magic is optional.
I am sorry because you worked a lot on this but it is very important and we have to switch to loadSync approach for the future of this library.

@hedgepigdaniel the problem with your implementation is that it restricts a lot possibilities if you don't use the SSR.
Actually it is very easy, you can use anything in your async function. I want to keep that and to provide a way for user to fix their code for SSR. Adding a loadSync method is an easy migration path for the SSR user. And the non-SSR user keep all power.

I gathered that - that's why I've separated this PR from https://github.com/gregberge/loadable-components/pull/511. With the change in this PR now, I don't think there are any restrictions added that were not there before.
In particular, you can still do anything you want in the importFn, and it still works on the client side - with this change as it currently stands, users do not need to migrate to anything, their existing code will work.
I'm not sure why loadSync is a better API than resolveComponent - if users want to start using named exports then they are going to have to change something in their code. With resolveComponent they only have to write the import once, and the only difference is that the extraction of the export from the module needs to be in a different function (resolveComponent). With loadSync, the user needs to import the same file twice (one async, one sync), which seems unecessary/confusing.

We can't make an API more restrictive than React.lazy. The Babel magic is optional.

Again, I don't think there are any breaking changes or new restrictions in this PR as it is now. I personally would recommend doing some. e.g. with https://github.com/gregberge/loadable-components/pull/511, but that is not necessary for this PR and to have functioning named exports.

@hedgepigdaniel I don't agree. The resolveComponent implies to return only an import from the function. Else it does not make sense sense. Except if you only apply it for SSR, in this case it should be resolveSyncComponent and make things more complicated than it should.

Not sure what you mean by "imply", but

having resolveComponent in the API does not prevent users from doing anything they want in loadFn - they still can and it still works as much as it did before
It probably does give a hint that returning something other than the import in loadFn is not a good idea. I think that's a good thing, because returning different things in loadFn does not work properly and cannot be fixed!

So yes, resolveComponent is intended to replace the practice of returning different things from loadFn. It's a necessary replacement because the current API doesn't work for SSR, and its backwards compatible because everything that currently works will keep working (i.e. the client side).
If your concern is not that there is a breaking change, then what is your concern? I don't think I understand. Do you want so solve the problem in a different way? Do you want to solve the problem at all?

I just read again the documentation of React.lazy and I changed my mind. It it explicitly said that it has to return an import with a default component.
Maybe we should keep this restriction. They also say that named exports are not supported.
That's said, my point is :

We make a change to only support a function that returns an import. We warn user that returning anything except an import function will not be supported in next major version.
We introduce the resolveComponent option to provide a solution for named exports
We implement delay, fallbackDelayMs is a good time.
We document how to set timeout directly in webpack

Sorry for this discussion. After a lot of thinking, I think your API is the good one. Now let's implement things and add some warning to make the transition easier to v6.
Actually I have time (we are confined in France). I will try to work on it this week-end!

There could also a good thing to document/explain why default exports are bad for common import/exports, but good for code splitting. Well - Formats over Functions, the same thing why it's expected to have redux selectors in selectors.js.
Probably it would be also great to have a few examples where named exports could be good for code splitting as well, and chunk exporting more that one thing is a good example. Or it's actually bad? Why you need other things, when you actually dont?
I reckon this less technical change, and more about "how it actually should work", and thus it's really important to get it right.

Hooray, great to hear!

That's said, my point is :
1. We make a change to only support a function that returns an `import`. We warn user that returning anything except an import function will not be supported in next major version.

2. We introduce the `resolveComponent` option to provide a solution for named exports

3. We implement [delay](https://loadable-components.com/docs/delay/), `fallbackDelayMs` is a good time.

4. We document how to set [timeout](https://loadable-components.com/docs/timeout/) directly in [webpack](https://webpack.js.org/configuration/output/#outputchunkloadtimeout)

Sounds like a good plan. Only issue is that 2 has to happen before 1, otherwise there will be no way to implement delay without generating warnings.
Re 4 - I didn't know it was possible to specify a timeout in import() - how do you do that?
How about we start with the resolveComponent functionality (i.e. merge this PR). Then task 1 will be unblocked, and we can think about how design a good API for delay and timeout before adding warnings/errors for users using the old API? https://github.com/gregberge/loadable-components/pull/511 would need a few changes to fit into this plan - perhaps we can discuss that there once this is merged?

Probably it would be also great to have a few examples where named exports could be good for code splitting as well, and chunk exporting more that one thing is a good example. Or it's actually bad? Why you need other things, when you actually dont?

Hard to answer without looking at the use case I think - I guess its useful if as the developer you know that there a a few components (small unique code size for each one) that users usually use all/many of them, or none at all. That way it might be a good idea to make the first chunk slightly bigger and eliminate the delay for the other components. I did add an example in this PR (something to do with apples and oranges - but at least it illustrates the idea of having one split point with multiple components. Do you think that's enough, or it should be something else?

Re 4 - I didn't know it was possible to specify a timeout in import() - how do you do that?

https://webpack.js.org/configuration/output/#outputchunkloadtimeout

Hard to answer without looking at the use case I think - I guess its useful if as the developer you know that there a a few components (small unique code size for each one) that users usually use all/many of them, or none at all. That way it might be a good idea to make the first chunk slightly bigger and eliminate the delay for the other components. I did add an example in this PR (something to do with apples and oranges - but at least it illustrates the idea of having one split point with multiple components. Do you think that's enough, or it should be something else?

Naming imports are not a good idea because you don't have Tree Shaking. We have to warn about it on the documentation.
As soon as I have time, I will merge this one and work on it. Last week-end I was working on SVGR. One project per week-end :).

Naming imports are not a good idea because you don't have Tree Shaking.

That's not quite bound to this case. It's more about - you will not get treeshaking if you have more that one thingy exported from a module, and more that one thingy consumed.
But, if it's always one, and always use through the loadable - why not to use default?

But, if it's always one, and always use through the loadable - why not to use default?

Yeah, the point is maybe we just have to "not support named exports". Creating a module wrapper is not a big deal and it is a good practice for tree shaking.

Ok, so it sounds like we are trying to work out what is the use case for named exports. Here's a few use cases (using a module wrapper with a default export breaks these use cases):
1. Project where named exports are used for DX reasons
Default exports encourage the same thing to have different names in different files. This is confusing, prevents easy refactoring, prevents good support by tooling (e.g. import auto complete), and adds to cognitive load. See this short and sweet post for more info.
2. Connecting multiple loadable components to the same split point
Take an example that there is a modal that the user may open, and the modal that has tabs inside it. Users usually explore all the tabs after they open the modal. There are 5 tabs. 2 tabs are visible to all users, but 3 tabs are only accessible to administrators.. The content of the tabs is reasonably small (not much data to download), but each request still adds latency.
In this case, it might be a good optimization to use the same split point for all of the 3 components used in the administrator tabs. That way if a user opens one of the tabs, the code for all the tabs is downloaded, so there is no extra latency when they switch to other tabs.
It's not possible for webpack to determine which split points will be loaded at the same time at runtime, so allowing multiple named exports in a single points allows the user to give webpack that information so that it can make a more optimal choice of which code to put in which chunks.
There seems to be a few users interested in this ability: https://github.com/gregberge/loadable-components/issues/245#issuecomment-564467163

To put it really simply, javascript supports named exports, webpack supports named exports, so loadable-components should support named exports. The fact that it currently doesn't is surprising and inconsistent with the rest of the ecosystem.
Re tree shaking, it seems like its a fundamental limitation with the current javascript that import() does not support statically importing a particular export - it always returns the entire module. I think this problem is out of scope for this PR (and this library). The user is free to use 1 default export, 1 named export, or multiple named exports. The user writes the code that does import('./xyz'), so they are responsible for what that does. This problem already exists anyway - even though the user must use a default export with loadable-components, they can still add more (unused) named exports to the imported module if they want, and tree shaking will not remove them. Perhaps one day there will be an import async { Thing } from './module';.

Ok. So in short - the main advantage for named exports is the ability to use them "more often" without overthinking the problem and extra boilerplate.
Ie just use.

@hedgepigdaniel the chunk name resolves the second issue. Webpack group chunks with the same name.
Also the case you mentioned is not the nominal one, I think most of time users will use it for wrong reasons and just lose the tree shaking.

No, chunk names does not resolve the issue. Chunk names lets you force webpack to put things in the same chunk, but:

it prevents webpack from combining that with other chunks if it sees fit (as it does, to make the best compromise the number of requests vs the amount of data downloaded).
That feature is a non standard webpack specific protocol, and it uses JSON inside comments which is awful.
That means the user is responsible for choosing unique chunk names, which is insane

The idiomatic way to have multiple things behind a single split point is to export multiple things from one module, with named exports. No non standard features, no hacks to force a specific compiler to do what you want, just using the standard features of the language.

You only "lose" tree shaking to the extent that you put multiple named exports in one file anyway - but loadable-components is currently broken even with a single named export. The use cases are already explained in the original PR description and the linked issue. This is clearly causing pain and confusion (and bugs in production), and there is a simple fix right here. @gregberge It's been almost 4 months now since this PR was opened, and you've already said twice in this thread that you will merge it as it is, but every 2 weeks you change your mind. How much longer do we have to continue this discussion?

@hedgepigdaniel since I am not very involved in the project it takes time and I am sorry for that. Yeah it is broken but we have two choices:

Make it work
Make it impossible

https://reactjs.org/docs/code-splitting.html#named-exports
"React.lazy currently only supports default exports." The currently makes me think that it is not definitive.
Let's make it possible. Also @hedgepigdaniel are you interested to be more involved in the project? Maintainer?

This project? I thought you were the author of it?
Sure, I'm happy to help with maintaining. HMU if you want to chat about it.

Morning @gregberge @hedgepigdaniel thanks for your work on this - reading through the thread it seems like this has been ready to ship for a while. From a consumer perspective, it'd be great to see that happen as it's probably a blocker for us considering we'd have to refactor our project to use default exports.

Meanwhile...
Long story short but at the "real work project" we are using only names imports. And just a few days ago I've got a good example of exporting multiple entities from one chunk.

there is a Page
the Page defines data query above it, so it could load js in a parallel with data
the Page contains a subroute, which initialization code is a part of the Page
but that code would be executed only after Page loads and that might take a while.

So - if you are landing to a subroute, you have to "see" how parent page is loading.
The right fix for the problem
Refactor all routing, so the problem will not exists.
The "faster" fix for the problem
Hoist Route a bit above, and "pick" one more export from the chunk. The case is solved, roughly 1 minute for all.

In other words - named exports, as well as multiple imports from one file, are very refactoring friendly.
In other other words - we should not bound our decisions to "React", as long as codesplitting is just a generic module management pattern. As long as we are not using the same module system as Facebook - their decisions might not be very applicable to our webpack world.

👍 make it possible.

Would love to see this merged soon! I really want to use the package in my org's codebase but we have a ton of named exports

Hi @hedgepigdaniel and @gregberge what is the plan for this?

I also would love to see it merged in the main tree.

Then let's do it!
(reading PR again)

+1, would love to see this merged, happy to help fix any blockers

+1, looking forward to seeing this merged as soon as possible :)

Ok. So the only missing piece is to update definitely-typed

where are the docs for this?  I don't see it on the site anywhere?

https://loadable-components.com/docs/api-loadable-component/#optionsresolvecomponent

Ah yes thanks!


Modify unit tests to work with CityScape dataset.

Mostly passing on this one, as it involves re-writing some of the helper functions as well around loading and saving images. I added some additional text around how to be able to do this, but since it's mostly out of the scope of the project, leaving it at that.


Connect styles to html

Connect styles by adding the next line inside the  section.

***
Also add this meta tag inside the  section for responsive design.
***

Підключив стилі в index.html.
Добавив мета тег  для responsive design.


Eslint and fix syntax

We should do a cleanup of code and syntax with `eslint-config-finn? latest.

Fixed with https://github.com/finn-no/unleash/pull/141


[ldd-img_surface] Additional correlation labels

Additional labels supporting stereo correlation processing.
Add items to img_surface:Stereo_Product_Parameters:
correlation_pixel_count - int, card 0-1, range 0-any
Contains a count of the number of pixels that successfully correlated in the image.
correlation_average_scale - float, card 0-1, range any
Contains the "average" scale factor for the correlation. In other words, given the reference image, scale it by this amount to match the target image. This scale factor is not precisely defined; it is determined in different ways by different correlation programs. The intent is to provide a "hint" for users of the correlation without requiring a full set of transform coefficients.
correlation_overlap_percentage - float, card 0-1, range 0-100
Contains the percentage of the reference image that could overlap, geometrically speaking, with the target image. It does not indicate the actual correlation percentage, but rather what might correlate ideally. This can be used to distinguish, for example, nearly perfect correlation in a small overlapping area vs. very poor correlation over the entire image - both of which could have the same correlation_pixel_count). This percentage is not precisely defined; it is an approximation intended to facilitate culling of results.

These all come from VICAR labels of the same names in DERIVED_IMAGE_PARMS.

implemented at v<IP_ADDRESS>


Implement dummy listener for lang.test module

Purpose

$title. Use this listener for testing in the ballerina-lang repository (replacement for HTTP listener).

Fixes #26636
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

With this PR, enable some test cases(tests which used HTTP module) which disable with JDK 11 migration(https://github.com/ballerina-platform/ballerina-lang/issues/26082).


Add info on NDVI calculations, data sources, bands, etc. to README

@gmyenni Can you look over the README to see if I covered all the info we discussed during last week's meeting?

Looks good, thanks!


Enable common-types rule by default.

:x: There is undocummented changes. Run chronus add to add a changeset or click here.
The following packages have changes but are not documented.

:x:@azure-tools/typespec-azure-resource-manager

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/567/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/567/


uninitialized constant FileUtils

when running octopod setup I see this:
===== Creating a backup of the configuration file ... =====
/Users/funkenstrahlen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/jekyll-octopod-0.6.5/bin/octopod:242:in `<top (required)>': uninitialized constant FileUtils (NameError)
Did you mean?  FileTest
	from /Users/funkenstrahlen/.rbenv/versions/2.3.1/bin/octopod:23:in `load'
	from /Users/funkenstrahlen/.rbenv/versions/2.3.1/bin/octopod:23:in `<main>'

Missing require?

FileUtils is part of the standard library, so I guess not.
Your paths look a bit weired, first 2.3.1 then 2.3.0 (Is this normal for rben? I have only experience with rvm).

This is common with rbenv but I also can not tell you why they do it like this with the versions.
I found this thread: https://github.com/yeahrb/yeah/issues/9 So I guessed maybe adding a require might help.

Let's try. I pushed a new version with a require. (bundle update ... )

works fine now. thank you!


fix(decodeOpReturn): Added NFT child test case

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Backend url

It seem that backend url is changed to backend_name from env.php
in our case its backend + downloadable
so if i visit site/backend i get 404 but when i visit site/backend/downloadable i get admin login page.
all sections are affected by that backend/downloadable/cache/index
any idea on how to fix this ?

Hello @Naberdz, I didn' encountered such an issue. Can you provide more guidelines how to reproduce this issue? Module shouldn't touch env.php file's values

Hallo @bartoszkubicki,
my env.php contains just standard magento specs it wasn't changed by plugin..
not sure what went wrong, maybe it has to do that it was a migration from M1 and was multistore and now it's a single store.
Had to change because when user added attachment at store level to a product you where unable to open it got some error that title didn't exists.
so to prevent it had to change settings to use it as single store. Afterwards it became like that.

@Naberdz today module has been tested against php 7.3 and magento 2.3.4. Please post exact error communicates and describe carefully how have you added attachments in backend

@bartoszkubicki
Have found only this error:
Uncaught TypeError: Return value of LizardMedia\\ProductAttachment\\Controller\\Download\\Attachment::loadAttachmentById() must implement interface LizardMedia\\ProductAttachment\\Api\\Data\\AttachmentInterface or be null, none returned in /home/pplazam2/domains/plafondplaza.nl/public_html/app/code/LizardMedia/ProductAttachment/Controller/Download/Attachment.php:110\nStack trace:\n#0 /home/pplazam2/domains/plafondplaza.nl/public_html/app/code/LizardMedia/ProductAttachment/Controller/Download/Attachment.php(71): LizardMedia\\ProductAttachment\\Controller\\Download\\Attachment->loadAttachmentById(19)\n#1 /home/pplazam2/domains/plafondplaza.nl/public_html/generated/code/LizardMedia/ProductAttachment/Controller/Download/Attachment/Interceptor.php(24): LizardMedia\\ProductAttachment\\Controller\\Download\\Attachment->execute()\n#2 /home/pplazam2/domains/plafondplaza.nl/public_html/vendor/magento/framework/App/Action/Action.php(108): LizardMedia\\ProductAttachment\\Controller\\Download\\Attachment\\Interc...\n
I don't add attachments.. client does..
as far as i see he adds them on global level or on store level.
when he sets it on store level default store has no values.
And we get error when trying to edit this product on global level. Can't seem to find this error. to solve that i make direct query and set store id to 0.
since i have changed it to single store mode this problem is not happening.

@Naberdz now it's clear, I will check if I am able to reproduce an error, or make sure that it's not going to happen anymore.

https://github.com/lizardmedia/product-attachments-magento2/pull/17

@Naberdz please check if error still persits with actual codebase

Have updated plugin. for now i don't see any errors.

@Naberdz thank you for your report. One bug less!


Fix #4491: Check the body of a JS constructor as an expression.

Instead of a statement.

Currently IRCheckerTest is limited to fairly intricate issues. It is very, very far from being exhaustive. Is it worth adding a test for this? Should we say that every new or fixed rule in IRChecker needs to have appropriate tests from now on?

Should we say that every new or fixed rule in IRChecker needs to have appropriate tests from now on?

Yes, maybe. Or maybe just add tests for bugs we fix / changes we make. Essentially, write tests for the diffs (while consolidating if appropriate of course).

Rebased, and added a test for the diff.


Stratifications loaded from csv do not appear in LineUp

I'm currently trying to get some basic StratomeX plots to visualise some clusterings I've done on different data types from the same data set.  It shows my two groupings in the dialogue, and loads everything in. But when I go to LineUp, it shows the data as being ungrouped.
This happens on multiple platforms. I'd be happy to send minimal example data to verify.

could you send the small example to<EMAIL_ADDRESS>please

As far as I understood, you loaded groupings for the columns. Unfortunately, StratomeX is currently not smart enough to transpose tables by its own. A simple solution is to either transpose your data outside or within the import dialog (2nd page: Swap Rows and Columns), ensuring that the samples are the rows. And then load groupings for the rows.

Thanks, that does seem to fix it.
On 26 February 2015 at 15:04, Samuel Gratzl<EMAIL_ADDRESS>wrote:

As far as I understood, you loaded groupings for the columns.
Unfortunately, StratomeX is currently not smart enough to transpose tables
by its own. A simple solution is to either transpose your data outside or
within the import dialog (2nd page: Swap Rows and Columns), ensuring that
the samples are the rows. And then load groupings for the rows.
—
Reply to this email directly or view it on GitHub
https://github.com/Caleydo/caleydo/issues/1878#issuecomment-76294785.


Turn off scrolloff while lightspeeding?

After pressing the second character, lightspeed immediately jumps to the first match. Unfortunately, if one has 'scrolloff' activated, this may cause the screen to scroll, making it hard to keep focus on the remaining labels. Would it be possible to temporarily disable the setting?

Absolutely, good idea, I use scrolloff too, but haven't thought about this yet. I will fix this soon.

Sidenote: a pending Neovim issue complicates this - we could hack around it, or just wait for it to be resolved. :)

Food for thought: I've implemented this, but when we want to target to the first match, it is just as annoying that on the next command, the window suddenly scrolls...


Docstrings for Forth words

probably just do it with zig, rather than building it into forth

could use a separate 'docs' wordlist
would work like this:
docs
: dup s" ( a b c -- a b c c )" ;
: drop s" ( a b c -- a b )" ;
forth

and something like 'word doctype' could lookup and print docstrings
could also use :doc name value ; and have :doc be written in zig


Enable Ember Octane features to fix Ember v4 scenarios

This removes deprecations and build failure caused by ember.edition  field in package.json and missing optional features

CI still fails because of liquid-fire which is transitive dependency added by ember-cli-addon-docs.
liquid-fire was removed from ember-cli-addon-docs v4 but we are not ready for the upgrade just yet, hence merging as is (as it actually fixes one of the issues in v4 scenarios)


license_file is deprecated - setup-cfg-fmt should remove this and convert to license_files

setuptools as of v62.3 warns that license_file is deprecated and license_files should be used instead.
setup-cfg-fmt currently requires license_file to exist.

general open source advice: search the issue tracker next time


update copyleft

:tada: This PR is included in version 4.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Define list of rules to be deprecated

Some of rules are not AEM-specific or should retire from various reasons. Prepare list and mark them as deprecated.

Possible candidate: https://github.com/Cognifide/AEM-Rules-for-SonarQube/issues/188


set US as first option

Thanks @mgilbert1, could you confirm this is the key code?
state_names = state_names[state_names != 'US']
state_names = np.insert(state_names, 0, 'US')

Also could you restart and run all so we have a clean execution count? Looks like the last cell may have been re-run.


tile_map not showing

Hi!
I've been using MapViz for ROS indigo for a while now, but for some reason the tile_map plugin never seemed to work for me. If I add the tile_map display it says "OK" but no tiles are displayed with any of the options. I also tried adding custom tile_map sources as well as installing from the ROS apt repository and from source. Everything else is working fine!
Here is my launch-file:
<launch>
<node pkg="tf" type="static_transform_publisher" name="swri_transform" args="0 0 0 0 0 0 /map /base_link 100"  />

<node pkg="swri_transform_util" type="initialize_origin.py" name="initialize_origin" >
    <param name="local_xy_frame" value="/map"/>
    <param name="local_xy_origin" value="auto"/>
    <rosparam param="local_xy_origins">
        [{ name: Bar,
         latitude: 37.9879772,
         longitude: 23.9078602,
         altitude: 129.69,
         heading: 0.0}]
    </rosparam>
</node>

<node pkg="mapviz" type="mapviz" name="mapviz"/>
</launch>

Is my transformation wrong or can this have something to do with my company's proxy settings and how can I test this?
Thank you for your help!

Are you able to add and see the tile_map plugin when you run roslaunch mapviz mapviz.launch?
It looks like maybe you have an issue with the local origin in the launch file you provided.  You have it set to 'auto', which will only publish an origin when it receives a GPS message.  If the initialize_origin.py node doesn't receive a GPS message it will never initialize.  If you set it to 'Bar' instead it should publish immediately.

Hi! Thanks a lot for your quick response.
When I run roslaunch mapviz mapviz.launch I can see the transformation of the GPS message (GPS display ) and also the /local_xy_origin seems to be published when I run rostopic echo /local_xy_origin. Setting the local origin to Bar unfortunately does not make a difference.
I can still add but not see the tile_map plugin. The status says OK.

It's possible there is an issue with your internet connection.  If you run the mapviz.launch file in the mapviz package and add a tile_map plugin you should get something similar to this:

The config file contains this:
capture_directory: ~
fixed_frame: far_field
target_frame: <none>
fix_orientation: false
rotate_90: false
enable_antialiasing: true
show_displays: true
show_status_bar: true
show_capture_tools: true
window_width: 1000
window_height: 804
view_scale: 1
offset_x: 0
offset_y: 0
use_latest_transforms: true
background: "#a0a0a4"
displays:
  - type: mapviz_plugins/tile_map
    name: new display
    config:
      visible: true
      collapsed: false
      custom_sources:
        []
      bing_api_key: ""
      source: Stamen (terrain)

You could try loading this exact configuration after running roslaunch mapviz mapviz.launch
If it is a network issue I would expect it to spew NETWORK ERROR ROS_ERROR messages in the console.
You could also try using another source like Bing Maps.  With Bing you need to provide an API key.  It looks like you need to restart mapviz after entering in and saving the key.
It is also possible to load tiles locally to bypass the network altogether.  You would select custom source and set the base url to something like:  file:///home/malban/map_tiles/{level}/{x}/{y}.png
If none of that works, I'm not sure.  You may need to dig into the plug-in and add some debugging log messages to find out what is going on.

Hi!
My config file looks very similar to your, but still no tile_map and no error message.
I finally got it to work by loading the tiles locally and selecting custom source (using this tool to download the tiles https://github.com/sjev/mapCreator in case somebody else needs it).
Thanks a lot for your support!

Another solution to use this: https://github.com/danielsnider/MapViz-Tile-Map-Google-Maps-Satellite

Hello! Does anyone knows what is the config file synthax the set a Custom WMTS Source?
Basically I want to replicate the following file to use CustomWMTS Source:
`capture_directory: ~
fixed_frame: far_field
target_frame:
fix_orientation: false
rotate_90: false
enable_antialiasing: true
show_displays: true
show_status_bar: true
show_capture_tools: true
window_width: 1000
window_height: 804
view_scale: 1
offset_x: 0
offset_y: 0
use_latest_transforms: true
background: "#a0a0a4"
displays:

type: mapviz_plugins/tile_map
name: new display
config:
visible: true
collapsed: false
custom_sources:
[]
bing_api_key: ""
source: Stamen (terrain)`


SIGINT event listener doen't work with handleSIGINT

Steps to reproduce
Tell us about your environment:

Puppeteer version:
Platform / OS version:
URLs (if applicable):
Node.js version:

What steps will reproduce the problem?
const puppeteer = require('puppeteer');

const cleanup = async () => {
    console.log('Received kill. Cleaning up.');
    await new Promise((resolve => setTimeout(resolve, 3000)));
    console.log('This won\'t be logged.');

    process.exit(0);
};

process.on('SIGINT', cleanup);

(async () => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await new Promise((resolve => setTimeout(resolve, 10000)));
    await browser.close();
})();

Just emit SIGINT event right after the browser was launched.
I guest that this is because you exit process in SIGINT event listener.
https://github.com/GoogleChrome/puppeteer/blob/4c62e09a766593c7902a7068896caa6b690b55ba/lib/Launcher.js#L167
I know that I can disable it with handleSIGINT  option, but in this case, you will loose logic which killing browsers.
What is the expected result?
console.log('This won\'t be logged.'); will log the message.
What happens instead?
There is no message.

Well, you can set cleanup callback on SIGINT event inside your async module block and call browser.close() directly:
const puppeteer = require('puppeteer');

(async () => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await new Promise((resolve => setTimeout(resolve, 10000)));
    await browser.close();

    const cleanup = async () => {
        console.log('Received kill. Cleaning up.');
        await new Promise((resolve => setTimeout(resolve, 3000)));
        console.log('This won\'t be logged.');

        await browser.close();  // <--------- write here

        process.exit(0);
    };

    process.on('SIGINT', cleanup);
})();

Also you can see such solution here - https://github.com/GoogleChrome/puppeteer/issues/1225#issuecomment-357214851


Add new colors

Color names are from https://www.htmlcsscolor.com/

I can confirm that Facebook has changed their color themes. Most of the colors are still the same, but FERN (#67b868), CAMEO (#d4a88c) and BILOBA_FLOWER (#a695c7) are no longer in use.
This is related to https://github.com/carpedm20/fbchat/pull/371. In the future, we shouldn't need to keep track of these updates (we should just return the color as-is).
Additionally, Facebook has added a new way to change these colours, using graphql, though that might not be important for us, as our old system still works. For future reference though, here's the information I could find:

theme_id
Color
Accessibility label
fbchat name
Gradient

205488546921017
#ff7ca8
Candy
TICKLE_ME_PINK
#ff8fb2 #a797ff #00e5ff

370940413392601
#1adb5b
Citrus
MALACHITE
#ffd200 #6edf00 #00dfbb

164535220883264
#f01d6a
Berry
RUBY
#005fff #9200ff #ff2e19

930060997172551
#ff9c19
Mango
DARK_TANGERINE
#ffdc2d #ff9616 #ff4f00

417639218648241
#0edcde
Aqua
BRIGHT_TURQUOISE
#19c9ff #00e6d2 #0ee6b7

196241301102133
#0084ff
Default Blue
MESSENGER_BLUE

1928399724138152
#44bec7
Teal Blue
VIKING

174636906462322
#ffc300
Yellow
GOLDEN_POPPY

2129984390566328
#fa3c4c
Red
RADICAL_RED

2058653964378557
#d696bb
Lavender Purple
SHOCKING

2136751179887052
#13cf13
Green
FREE_SPEECH_GREEN

175615189761153
#ff7e29
Orange
PUMPKIN

980963458735625
#e68585
Coral Pink
LIGHT_CORAL

234137870477637
#7646ff
Bright Purple
MEDIUM_SLATE_BLUE

2442142322678320
#20cef5
Aqua Blue
DEEP_SKY_BLUE

169463077092846
#ff5ca1
Hot Pink
BRILLIANT_ROSE

To update the color:
data = {
    "client_mutation_id": 0,
    "actor_id": client.uid,
    "thread_id": thread_id,
    "theme_id": theme_id,
    "source": "SETTINGS"
}
client.graphql_request(
    GraphQL(
        doc_id="1727493033983591",
        params={"data": data},
    )
)

I rebased this commit on master and fixed the formatting errors, thanks for your work! 👍


AttributeError: 'module' object has no attribute 'StatefulBrowser'

Using the example from the readme I get the above error.

You need the latest version (from git, not the latest released version yet) for this to work. Otherwise, you can also use example_manual.py which works with older releases (but requires a bit more code to write).

thank you

Still not working, I cloned MechanicalSoup and ran setup.py. I also tried just installing it directly from github. I'm still running into this issue. I have Python 3.5.2.

I'm 99.9 % sure you're still using the old version (or perhaps a mix between the old and the new one). Perhaps you have one installed user wide and the other system wide?

I am using python 3.6 and installed mechanical soup using the pip, I get this error. How do I use a different version I clicked on the link but no link for 3.6

Not sure how many times I'll have to repeat this: the released version doesn't contain statefulBrowser. I'll make a release when I get time (might not be so soon :-().


Wrong name in parameter MultiBufferOp skip validation

This is a very small thing, but I found it and I'd might as well report it.
https://github.com/smallrye/smallrye-mutiny/blob/1ddf9ecc0113a8a1ae11a90bd98625aa39c9f4f6/implementation/src/main/java/io/smallrye/mutiny/operators/multi/MultiBufferOp.java#L54
Keep up the good work!

Oh nice catch!


inventory, label, and store all glider lab equipment

Setting up the proto- Humboldt Glider Lab for working on Calanus. Tony and Caleb brought up a lot of supplies. Double checking inventory and labeling everything with "NOAA ESD" wherever possible.

Organized (stored, labeled) most of everything besides individual tools that are part of sets. Might just wrap blue labeling tape around the handles of important tools.


Unable to install pods on bare project with new arch enabled

Description
I am unable to install pods with new arch enabled on bare RN 0.70.0 project. I get the following error:
[!] Invalid `Podfile` file: No such file or directory @ rb_sysopen - ../node_modules/react-native/package.json.

 #  from /Users/fawadkhalil/Documents/samplern/Cargr/ios/Podfile:13
 #  -------------------------------------------
 #
 >    use_react_native!(
 #      :path => config[:reactNativePath],
 #  -------------------------------------------

[!] [Codegen] warn: using experimental new codegen integration

Version
0.70.0
Output of npx react-native info
info Fetching system and libraries information...
System:
OS: macOS 12.4
CPU: (8) arm64 Apple M1
Memory: 826.41 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.0/bin/yarn
npm: 8.1.4 - ~/.nvm/versions/node/v16.13.0/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
Android SDK: Not Found
IDEs:
Android Studio: 2021.2 AI-212.5712.43.2112.8815526
Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
Languages:
Java: 12.0.2 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.1.0 => 18.1.0
react-native: 0.70.0 => 0.70.0
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce

Create new RN project with npx react-native init sampleapp
Run USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 pod install --project-directory=ios

Snack, code example, screenshot, or link to a repository
Not needed. It's just a bare RN project.

use
cd ios
USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 pod install

Thank you. That has worked. So it won't work from the root dir.


Navbar changes

I removed this style right here, to avoid conflicting with the home page expanding when using next/image component, I also reviewed the other pages to see any problem my changes would cause, so far fixed problem with the movie page and with mobile. Haven't tried with the protected pages as I can't use account in local.

There are some strange issues will scrolling on some pages
/movies

/user/qnydtrfNxWSKBZrZvLYkvMIY7k72/preview
z-index issues on /trending

closed but code is still on dev 💯


Error when Testing pretrained model

When I follow the command of Testing pre-trained models
$ python launch.py \
	--cfg configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml \
	--mode test \
	TEST.WEIGHTS pretrained_models/configs/video/2d_best/01_R101_best_hungarian.yaml/model_final.pkl

Error occurs
Done (t=0.54s)
creating index...
index created!
INFO subprocess.py:  53: detection range command 0: tools/test_net.py --range 0 1477 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1
INFO subprocess.py:  53: detection range command 1: tools/test_net.py --range 1477 2954 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1
INFO subprocess.py:  53: detection range command 2: tools/test_net.py --range 2954 4430 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1
INFO subprocess.py:  53: detection range command 3: tools/test_net.py --range 4430 5906 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1
INFO subprocess.py:  80: # ---------------------------------------------------------------------------- #
INFO subprocess.py:  82: stdout of subprocess 0 with range [1, 1477]
INFO subprocess.py:  83: # ---------------------------------------------------------------------------- #
tools/test_net.py: line 10: Test a Fast R-CNN network on an image database.: command not found
tools/test_net.py: line 12: from: command not found
tools/test_net.py: line 13: from: command not found
tools/test_net.py: line 14: from: command not found
tools/test_net.py: line 15: from: command not found
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
tools/test_net.py: line 18: from: command not found
tools/test_net.py: line 21: from: command not found
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
import: unable to grab mouse `': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047.
tools/test_net.py: line 34: syntax error near unexpected token `FORMAT'
tools/test_net.py: line 34: `FORMAT = '%(levelname)s %(filename)s:%(lineno)4d: %(message)s''
Traceback (most recent call last):
  File "tools/test_net.py", line 142, in <module>
    main(ind_range=args.range, multi_gpu_testing=args.multi_gpu_testing)
  File "tools/test_net.py", line 103, in main
    engine.test_net_on_dataset(multi_gpu=multi_gpu_testing)
  File "/data3/lilin/my_detect_and_track/DetectAndTrack/lib/core/test_engine.py", line 319, in test_net_on_dataset
    num_images, output_dir)
  File "/data3/lilin/my_detect_and_track/DetectAndTrack/lib/core/test_engine.py", line 284, in multi_gpu_test_net_on_dataset
    'detection', num_images, binary, output_dir)
  File "/data3/lilin/my_detect_and_track/DetectAndTrack/lib/utils/subprocess.py", line 67, in process_in_parallel
    log_subprocess_output(i, p, output_dir, tag, start, end)
  File "/data3/lilin/my_detect_and_track/DetectAndTrack/lib/utils/subprocess.py", line 97, in log_subprocess_output
    assert ret == 0, 'Range subprocess failed (exit code: {})'.format(ret)
AssertionError: Range subprocess failed (exit code: 2)

I've googled a lot but could not find a answer.

The same error, need urgent reply.

As mentioned in the error message, the subprocess calls are failing. Have you tried running the command tools/test_net.py --range 0 1477 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1 directly on the shell to see what error you get?
Unfortunately this seems to be dependent on specific shell/environment setup, so I can't really reproduce/debug without more information.

Error message:
loading annotations into memory...
Done (t=0.45s)
creating index...
index created!
Video-fying the roidb: 100%|##########################################################################################| 5906/5906 [00:03<00:00, 1492.55it/s]
INFO video.py: 200: Video-fied roidb contains 5906 elements
WARNING cnn.py:  40: [====DEPRECATE WARNING====]: you are creating an object from CNNModelHelper class which will be deprecated soon. Please use ModelHelper object with brew module. For more information, please refer to caffe2.ai and python/brew.py, python/brew_test.py for more information.
Traceback (most recent call last):
File "tools/test_net.py", line 150, in
main(ind_range=args.range, multi_gpu_testing=args.multi_gpu_testing)
File "tools/test_net.py", line 101, in main
engine.test_net(ind_range=ind_range)
File "/home/data/DetectAndTrack-wjb/lib/core/test_engine.py", line 135, in test_net
model = initialize_model_from_cfg()
File "/home/data/DetectAndTrack-wjb/lib/core/test_engine.py", line 59, in initialize_model_from_cfg
init_params=cfg.TEST.INIT_RANDOM_VARS_BEFORE_LOADING)
File "/home/data/DetectAndTrack-wjb/lib/modeling/model_builder.py", line 61, in create
return get_func(model_name)(init_model(model_name, train, init_params))
File "/home/data/DetectAndTrack-wjb/lib/modeling/model_builder.py", line 154, in keypoint_rcnn
add_roi_keypoint_head_func=get_func(cfg.KRCNN.ROI_KEYPOINTS_HEAD))
File "/home/data/DetectAndTrack-wjb/lib/modeling/model_builder.py", line 305, in build_generic_fast_rcnn_model
build_data_parallel_model(model, _single_gpu_build_func)
File "/home/data/DetectAndTrack-wjb/lib/modeling/model_builder.py", line 951, in build_data_parallel_model
single_gpu_build_func(model)
File "/home/data/DetectAndTrack-wjb/lib/modeling/model_builder.py", line 197, in _single_gpu_build_func
blob_conv, dim_conv, spatial_scale_conv = add_conv_body_func(model)
File "/home/data/DetectAndTrack-wjb/lib/modeling/FPN3D.py", line 51, in add_fpn_ResNet101_conv5_body
ResNet.stage_info_ResNet101_conv5)
File "/home/data/DetectAndTrack-wjb/lib/modeling/FPN3D.py", line 98, in add_fpn_generic_onto_body
conv_body_func(model)
File "/home/data/DetectAndTrack-wjb/lib/modeling/ResNet3D.py", line 389, in add_ResNet101_conv5_body
return add_ResNet_convX_body(model, (3, 4, 23, 3), freeze_at=2)
File "/home/data/DetectAndTrack-wjb/lib/modeling/ResNet3D.py", line 262, in add_ResNet_convX_body
p = model.AffineChannelNd(p, 'res_conv1_bn', dim_out=feat_dims[0], inplace=True)
File "/home/data/DetectAndTrack-wjb/lib/modeling/detector.py", line 107, in AffineChannelNd
return self.net.AffineChannelNd([blob_in, scale, bias], blob_in)
File "/usr/local/caffe2_build/caffe2/python/core.py", line 2040, in getattr
",".join(workspace.C.nearby_opnames(op_type)) + ']'
AttributeError: Method AffineChannelNd is not a registered operator. Did you mean: [AffineChannel]

@rohitgirdhar  Yes,
python tools/test_net.py --range 0 1477 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1
could work.
@wjbKimberly
It seems the code could not support multi-gpu setting and we need to comment the lines
https://github.com/facebookresearch/DetectAndTrack/blob/d66734498a4331cd6fde87d8269499b8577a2842/launch.py#L50
https://github.com/facebookresearch/DetectAndTrack/blob/d66734498a4331cd6fde87d8269499b8577a2842/launch.py#L51

@zhujiagang  Thanks a lot for your kind help!

The code should work with multi-GPU testing. In @wjbKimberly's case, it seems the additional ops (AffineChannelNd) has not been compiled (instructions). Closing as it seems the issue is resolved.

@rohitgirdhar Yes,
python tools/test_net.py --range 0 1477 --cfg outputs/configs/video/2d_best/01_R101_best_hungarian-4GPU.yaml/test/posetrack_v1.0_val/keypoint_rcnn/detection_range_config.yaml NUM_GPUS 1
could work.
@wjbKimberly
It seems the code could not support multi-gpu setting and we need to comment the lines
DetectAndTrack/launch.py
Line 50 in d667344
if args.mode in ['train', 'test']:
DetectAndTrack/launch.py
Line 51 in d667344
other_opts += '--multi-gpu-testing '

我还是一样的错误哎，有没有其他的建议了啊


Make the list of pages publicly available.

I couldn't find the list anywhere on the website. By the way, the search does not work anymore.

Yep, i can confirm search does not work today for me, i trying different browser and didnt work.
Public list of the websites will be really nice featured.
Thank you for your project, I found it very inspiring and interesting, have you thought about making a Spanish version?


Local alleles

Description
In this pull request, vcf2zarr computes a genotype-level, local alleles field, LAA, during the explode step unless specifically told not to. The LAA field is a list of one-based indices into the variant-level ALT field that indicates which alleles are relevant (local) for the current sample. The source of truth for the LAA field is the GT, AD, and PL genotype fields.
vcf2zarr does not try to compute the LAA field if the LAA field is already present in a genotype entry.
With these changes, vcf2zarr computes the LAA field by default. To prevent vcf2zarr from introducing the LAA field, the user can specify --local-alleles false when running the vcf2zarr explode CLI.
This pull request makes progress on #185.
Testing
I updated and added several unit tests. I am happy to add more tests.
I was not able to use the bcftools tag2tag plugin as discussed in #185 because generating local-allele fields is not actually implemented in the plugin yet. (See here.)
Discussion
Format of the call_LAA field
To simplify the format of the call_LAA field, vcf2zarr always assigns three-dimensional values to the LAA field, filling space with the fill value, -2, where necessary. If none of the entries use alternate alleles, then each entry's LAA is [-2]. When an entry does use alternate alleles, the alternate allele indices come first in sorted order followed by any necessary fill values. For example, [2, 5, 6, -2, -2] is a valid LAA value.
Deciding when to localize
The issue (#185) seems to focus on the PL field. vcf2zarr only introduces the local-allele fields if the PL field is present in the VCF file, and the user has not specified to not introduce local-allele fields.
Inferring which alleles are used in the PL field
When the ploidy is one, the index of the PL corresponds to the index of the allele.
When the ploidy is two, then the index of the PL value corresponds to a diploid genotype. Given a positive PL value, we want to determine which alleles are in the genotype associated with the PL value. Given a genotype $a/b$, the index of the associated PL value is $$\frac{b(b+1)}{2} + a.$$
Suppose the index of the positive PL value is $n$. To determine $b$, we can momentarily set $a = b$ and solve $$n = \frac{b(b+1)}{2} + b.$$
We have $$2n = b^2 + 3b$$ $$\implies 2n + \frac{9}{4} = b^2 + b + \frac{9}{4}$$ $$\implies 2n + \frac{9}{4} = \left( b + \frac{3}{2} \right)^2$$ $$\implies \sqrt{2n + \frac{9}{4}} = b + \frac{3}{2}$$ $$\implies b =  \sqrt{2n + \frac{9}{4}} - \frac{3}{2}.$$
Since $a$ can be less than $b$, we take the ceiling: $$b = \left\lceil \sqrt{2n + \frac{9}{4}} - \frac{3}{2} \right\rceil .$$
Determining $a$ is then simple: $$a = n - \frac{b(b+1)}{2}.$$
References

VCFv4.5 specification PDF

This VCF specification defines the LAA field as well as the other local-allele genotype fields. The latest version, v4.5, was apparently finalized and published last week.

The Scalable Variant Call Representation paper

This paper introduces the local-alleles approach for the Scalable Variant Call Representation and highlights the motivation for introducing local alleles.

coverage: 98.868% (-0.03%) from 98.895%
when pulling 8547acecd33e3ddb4b32e88cfe3175feab761858 on Will-Tyler:local-alleles
into 69ee0e82c03933ff06369764610168a4c8694642 on sgkit-dev:main.

coverage: 98.91% (+0.02%) from 98.895%
when pulling 8547acecd33e3ddb4b32e88cfe3175feab761858 on Will-Tyler:local-alleles
into 69ee0e82c03933ff06369764610168a4c8694642 on sgkit-dev:main.

Thanks for the feedback! Let me try to answer your questions here.

Why do we just count the 1-based ALT alleles? It's the same thing to count all alleles, zero based isn't it?

I assume we want the result of localizing genotype fields in vcf2zarr to be the same as if the genotype fields were already localized in the input VCF file according to the VCF specification. Therefore, the localized genotype fields produced by vcf2zarr should also follow the VCF specification.
The VCF specification dictates that if any local-allele genotype field is present, then the LAA field must be present. The LAA field is by definition a list of the one-based indices into the ALT variant field that indicates which alleles are observed in the sample at the variant.
I think staying consistent with the VCF specification helps keep the VCF Zarr representation simple. For example, if VCF Zarr data consumers encounter a call_LPL field, then they know to use the call_LAA field to determine which genotypes the values of the call_LPL field correspond to.

What's the reasoning for looking at AD as well?

The AD field might have positive values for alleles that are not called in the GT field. This is demonstrated in the LAA example in the v4.5 specification (page 14) reproduced here:

POS
REF
ALT
FORMAT
sample

1
G
A,C,T,<*>
GT:AD:PL
2/2:20,.,30,.,10:90,.,.,80,.,0,.,.,.,.,100,.,110,.,120

I think inferring which alleles are observed with the PL field as well as you suggested is a good idea. I will look into this.

Would you mind adding an example file based on the SVCR paper example?

I am happy to add more tests—thanks for the suggestion!

I think the application to PLs is the important thing here. Otherwise, we don't really care about creating LAA at all, so I think we should try adding in LPL pretty soon so we're sure we're going in the right direction.

Good to know—I wanted to create a pull request after implementing the LAA field to get feedback, make sure I was on the right track, and keep the pull request size manageable. I will modify these changes so that vcf2zarr does not introduce local-allele fields unless the PL field is present in the input VCF. Once the LAA field changes look good, I can add the LPL field either as part of this pull request or a new pull request.

As I was thinking about this, I realized that vcf2zarr should not compute and add the LAA field if the LAA field is already present in the input VCF. I need to make some changes for that.

coverage: 98.882% (-0.01%) from 98.895%
when pulling 46cf7bbadd19d3219b129b031c6ab891339fa9a9 on Will-Tyler:local-alleles
into 69ee0e82c03933ff06369764610168a4c8694642 on sgkit-dev:main.

coverage: 98.881% (-0.01%) from 98.895%
when pulling 819820a1b4012ec35462ee0a94f8bbc8baad467e on Will-Tyler:local-alleles
into 69ee0e82c03933ff06369764610168a4c8694642 on sgkit-dev:main.

coverage: 98.922% (+0.03%) from 98.895%
when pulling 819820a1b4012ec35462ee0a94f8bbc8baad467e on Will-Tyler:local-alleles
into 69ee0e82c03933ff06369764610168a4c8694642 on sgkit-dev:main.

I made some changes, but I'm not quite ready for a new review. I want to try simplifying the compute_LAA_field method. I will use the request a new review GitHub feature when I am ready.

coverage: 98.841% (-0.05%) from 98.895%
when pulling 4b04086a3d3bff0d36d2969783e066f12816b66d on Will-Tyler:local-alleles
into 69ee0e82c03933ff06369764610168a4c8694642 on sgkit-dev:main.

Were you planning on adding LPL in for this PR, or doing in a follow up? I'm happy either way.

In that case, I would like to add LPL in a follow-up PR. I think this one is large enough as is.

Great, let's merge. Can you rebase please?

Should be rebased now

Thank you for reviewing!

Le 10 juil. 2024 à 20:09, Jerome Kelleher @.***> a écrit :
Merged #266 https://github.com/sgkit-dev/bio2zarr/pull/266 into main.
—
Reply to this email directly, view it on GitHub https://github.com/sgkit-dev/bio2zarr/pull/266#event-13461517797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTQUPJ4UGZBQ7MRGKUVBD3ZLWIHLAVCNFSM6AAAAABKKA6WJ2VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGQ3DCNJRG43TSNY.
You are receiving this because you were mentioned.

Thanks for contributing!


PageSpeed Insight does not see changes

I just added lazysizes.min.css to project also changed img classes to lazyload and see that the classes of the pictures have gone to "lazyloaded" from the elements panel. But Google pagespeed insights persistently says I have not uploaded these pictures lazyload.
I use webp as a format. Can it be related to this?

Sorry, my mistake.
I forgot to change src to data-src.
I can not handle only webp format.


WIP - Calls documentation updates - 2024-05-22

@kodster28 this is not a Cloudflare API at api.cloudflare.com. This is a product specific API with a different endpoint. They are not related.

@kodster28 good question! This is not a Cloudflare API at api.cloudflare.com. This is a product specific API with a different endpoint. They are not related.

Oh... interesting. Gotcha, let me unblock then.
Assuming y'all have a process for updating this when the API changes?

@kodster28 good question! This is not a Cloudflare API at api.cloudflare.com. This is a product specific API with a different endpoint. They are not related.

Oh... interesting. Gotcha, let me unblock then.
Assuming y'all have a process for updating this when the API changes?

Yes, this is the source of truth now.

@kodster28 I set pcx_content_type: get-started in the markdown header each time, but don't know what it does. Do you have any insight into what this is for?

@kodster28 I set pcx_content_type: get-started in the markdown header each time, but don't know what it does. Do you have any insight into what this is for?

Metadata that we add to the rendered page. It helps us group by the type of content for reporting, etc.
Full list of options + values at https://developers.cloudflare.com/style-guide/documentation-content-strategy/content-types/


Add filepath command line argument for testing queries

For local testing purposes, this allows the user to do something like:
pytest tests/unit/test_queries.py::test_gpu_query['q1.sql'] --runqueries --rungpu --filepath "/home/nfs/syurick/dask-sql/tests/unit/data/sf1/parquet_2gb_sorted/"

cc @randerzander

Codecov Report

Merging #1161 (80517c9) into main (2df7476) will decrease coverage by 3.02%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main    #1161      +/-   ##
==========================================
- Coverage   81.46%   78.45%   -3.02%
==========================================
  Files          78       76       -2
  Lines        4403     4307      -96
  Branches      798      779      -19
==========================================
- Hits         3587     3379     -208
- Misses        640      743     +103
- Partials      176      185       +9

see 9 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Reconstruction image is always a solid color

Hello,
I've been working on training this on the imagenet data, but I'm concerned I'm doing something wrong because the reconstructions are always a solid color. I haven't trained it very long ~1500 steps (batch size 10), but I just wanted to check if this is expected.
1300 steps:

1200 steps:

from magvit2_pytorch import (
    VideoTokenizer,
    VideoTokenizerTrainer
)

tokenizer = VideoTokenizer(
    image_size = 256,
    codebook_size=1_024,
    use_gan=True,
    use_fsq=True,
    init_dim=128,
    adversarial_loss_weight=0.1, # From the paper
    perceptual_loss_weight=0.1, # From the paper
    grad_penalty_loss_weight=10.0,
    lfq_entropy_loss_weight=0.3, # From the paper
    layers = (
        'residual',
        'compress_space',
        ('consecutive_residual', 2),
        'compress_space',
        ('consecutive_residual', 2),
        'compress_space',
        ('consecutive_residual', 2),
        'linear_attend_space',
        'compress_space',
        ('consecutive_residual', 2),
        'attend_space',
    ),
)

trainer = VideoTokenizerTrainer(
    tokenizer,
    dataset_folder='/projects/users/pfeiljx/imagenet/TRAIN',
    dataset_type = 'images',                        # 'videos' or 'images', prior papers have shown pretraining on images to be effective for video synthesis
    batch_size = 10,
    grad_accum_every = 8,
    num_train_steps = 1_000_000,
    num_frames=1,
    max_grad_norm=1.0,
    learning_rate=1e-4, # From the paper
    accelerate_kwargs={"split_batches": True, "mixed_precision": 'fp16'},
    random_split_seed=171,
    optimizer_kwargs={"betas": (0.9, 0.99)}, # From the paper
    ema_kwargs={}
)

trainer.train()

@jpfeil could you retry with fp32?

@jpfeil also share your training curve, try out wandb's report for easy sharing

Thanks @lucidrains I'll let you know when the wandb report is ready.

@lucidrains This was run on 0.1.24, so I'm going to pull the latest version and retry. The loss was slowly improving, but around step 1000, the loss became nan. The only change I've made is I added a cosine schedule with warmup. I'm also still using bf16, so I'll change that in the next run.
https://api.wandb.ai/links/pfeiljx/p2x7x2x2

Hi @lucidrains
I ran it using fp32 and trained for 5000 steps, but I did not see any improvement.
https://api.wandb.ai/links/pfeiljx/8kqeyypi
Let me know if you have any suggestions.

@lucidrains I ran the fashion mnist data last night and the model was able to converge:
https://api.wandb.ai/links/pfeiljx/udspvdgu

@jpfeil @jacobpfeil i think this repository should support pretraining with with 2d conv, and then a way to convert it to 3d for video. but let me meditate on the simplest way to achieve this

at google they can just throw a gazillion TPUs at it and it converges, but that just isn't realistic in the academic setting

Thanks @lucidrains. Let me know if I can help run some tests. I have access to a few A100 GPUs.

@jpfeil sounds good
let me think about this for a few days or the code will come out wrong
measure twice cut once kinda thing

@lucidrains After looking at the FashionMNIST results, it looks like the discriminator collapsed to zero loss. So, I think the learning stopped prematurely. I'm also not getting good reconstructions.

@jpfeil yea i could add that, but only if need be
what happens if you set adversarial_loss_weight to 0.
it really should converge for fashion mnist quite quickly, even without the GAN

I get an assertion error because self.has_gan attribute gets set to False.

@jpfeil could you point to the line number?
could you also give 0.1.29 a quick try? may be a bug but not entirely sure

@jpfeil oh nvm, yes i see it. we should be able to turn off adversarial loss, let me fix

@jpfeil try 0.1.30

@lucidrains, I'm still getting an assertion error. The assert is here:
https://github.com/lucidrains/magvit2-pytorch/blob/bf716ef603276d2a0ce2518ed86722dc5053afa8/magvit2_pytorch/magvit2_pytorch.py#L1684C14-L1684C14

Woops. My Tokenizer change wasn't saved. Running now...

@jpfeil give the imagenet run another try
there may have been a bug with how I zeroed the gradients a few patches ago

This is resolved for fashion mnist, but I haven't been able to run through enough imagenet data to see if it works for imagenet. I'm going to close this now and if it comes up again for imagenet, I'll open a new issue.

This is resolved for fashion mnist, but I haven't been able to run through enough imagenet data to see if it works for imagenet. I'm going to close this now and if it comes up again for imagenet, I'll open a new issue.

Hi, do you mind sharing how did you end up solving it? I run into the same issue.

Hi @coolbunnyx,
Sorry for the delay. I think you already solved it, but I was able to get good reconstruction after training for longer.


Place a Policy in each cluster namespace for a RateLimitPolicy

Refactor the RateLimitPolicy controller to place an OCM Policy in each cluster namespace where the targeted Gateway is.
With these changes a RateLimitPolicy is 'synced' to the target clusters using an OCM Policy resource in each cluster namespace in the hub.
Example Policy that encapsulates a RateLimitPolicy
The reason for using a Policy instead of a ManifestWork is to leverage the Policy framework and compliance reporting.
TODO:

[ ] Add the cluster descriptor key/value to the RLP
[ ] Test for descriptor
[ ] Address TODOs in code
[ ] Verify (& update if needed) the RLP walkthrough
[ ] Verify & Test RLP deletion cleans up Policies
Refactor the various OCM types that have been imported directly into the project at a later stage (depends on ocm upstream work. See note in pkg/apis folder)

Closing this PR. See #176 for details


copy additional files to /var/lib/rancher/conf

add -f <file1,file2,file3> optional parameter to os-installer:
handy for provisioning system services in compose yml files

Now this is pretty obsolete. Feel free to close and merge #13 instead.


Issue 418 - Fix Node Detail API

Removed PUT method

Removed unit tests for PUT method

Modified PATCH method

Can no longer update hostname or port
Now returns node details and resources

Modified unit tests for PATCH method to verify we are returning node details and resources

I think the last thing is to update the REST API docs with your changes in scale/docs/rest/node.rst.

Documentation has now been updated to reflect the changes

The recommended changes are completed!

LGTM


Discover fails with 'Error [ERR_SOCKET_CANNOT_SEND]: Unable to send data'

I'm trying to discover my HEOS device on Windows 10 Pro with node.js 10.16.0 and heos-api 3.7.7. Due to using Hyper-V with Docker my OS has multiple (virtual) network interfaces. All discover functions throw the following error:
events.js:174
      throw er; // Unhandled 'error' event
      ^

Error [ERR_SOCKET_CANNOT_SEND]: Unable to send data
    at Socket.onListenError (dgram.js:328:22)
    at Object.onceWrapper (events.js:286:20)
    at Socket.emit (events.js:198:13)
    at state.handle.lookup (dgram.js:243:14)
    at process._tickCallback (internal/process/next_tick.js:63:19)
    at Function.Module.runMain (internal/modules/cjs/loader.js:832:11)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)
Emitted 'error' event at:
    at Socket.onListenError (dgram.js:328:8)
    at Object.onceWrapper (events.js:286:20)
    [... lines matching original stack trace ...]
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

I disabled all network interfaces except the hardware one but the problem remains.

Wierd. There is a known issue that you can't have Spotify on when doing a discover. Can you show the code that you run that create this issue?

I got it work as a standalone.  But what I'm attempting to do is to have an Express API which acts as a proxy between a web app (SPA) and the HEOS device (Actually heos-api -> HEOS device). But when the Express app is started via listen function heos-api (dgram) can't send messages to the socket.
It seems it's not possible to run the heos-api in the browser due to dgram.

Actually found the root cause. If I have any software running that uses UPnP heos-api (or dgram) can't send messages to the socket. Don't know if this is only Windows specific.
...but this is little problematic as I use my PC a UPnP server...

This is a problem as SSDP that is the basis of UPnP is specified on a specific UDP port and host. If any program on your computer already uses port 1900, heos-api can not open a new UDP socket on that port, and can therefore not use UPnP to discover HEOS devices.
I am looking in to if it is possible to use a different destination port than source port. If that is the case, maybe heos-api could open a UDP socket on a free port, and then send the message on port 1900. I am not sure if this is possible though.

Tried it, works. At least port 1901 on my PC.
Maybe the UDP port could be defined via environment variable? If not set fallback to 1900.

Great! I will try to look into it and write a fix as soon as possible but it will probably take about a week.

Is it fixed for you?

:tada: This issue has been resolved in version 3.7.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 3.8.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Added default_server option for the default server

If you're using wildcard host names the default backend will no longer be available due to the way nginx has predence on wildcards. By providing default_server it indicates a catch-all so regardless of wildcards if there is no direct match they will end up in default server block.

This change is

@alexw23 please check the new version https://github.com/kubernetes/ingress
We are moving the code to that repository.


Fix #978

This fix put the primary keys into an array while building the object. From this array, the values will be used to create the criteria for updating. After updating an object, the values in the array will be regenerated to ensure multiple changes in one request.

Why are those checks failing
Didnt you use latest master as reference?

Why are those checks failing Didnt you use latest master as reference?

I used latest master. They failed because of:
Error: dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe.
You can run "composer config --no-plugins allow-plugins.dealerdirect/phpcodesniffer-composer-installer [true|false]" to enable it (true) or disable it explicitly and suppress this exception (false)
See https://getcomposer.org/allow-plugins

In PluginManager.php line 762:

  dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin w
  hich is blocked by your allow-plugins config. You may add it to the list if
   you consider it safe.
  You can run "composer config --no-plugins allow-plugins.dealerdirect/phpcod
  esniffer-composer-installer [true|false]" to enable it (true) or disable it
   explicitly and suppress this exception (false)
  See https://getcomposer.org/allow-plugins

See https://github.com/propelorm/Propel2/runs/7263266989?check_suite_focus=true
All other current PR also failing.

Yeah, but we have the same here whitelisted
So this seems to be composer bug/regression
I opened a ticket for now: https://github.com/composer/composer/issues/10981

Master is fixed, can you please rebase?

I wonder if this should come with a test case
cc @mringler

I wonder if this should come with a test case

Yes, @basteyy, could you please add a test verifying the updated behavior?
If you want to run test on your machine, there is a page with hints how to get it running. It is partially outdated though, specifically the part about "custom credentials". Not sure if that ever worked, but on MySQL, AFAIK you need to use user "admin" and password "" (empty string). Might be easier to use SQLite.
Anyway, let me know if you want help with that.

Any update on this one?

Any update on this one?

Next week I will try to update it.

ping @basteyy

ping @basteyy

Setting up the local test environment needed time, and I'm struggling with a test case. Thanks for pinging, try to modify the patch end of this week.

Testing should now be easier, see updated docs


Update broke organization

https://wordpress.org/support/topic/update-broke-organization/

After the most recent update on 1/13/2020, the organization feature is broken. Images are only getting as far as the year for organization rather than month and there is a 0 being prefixed to the front of the images.

Wasn't able to replicate.

Hi, this issue is happening in a multisite installation that i am working on.
I have 2 sites with the same settings. One in English, the other one in portuguese.
The english site is working fine. But in the portuguese version this problem started since the beginning of this month (may 2020).
All images uploaded are returning with a broken path as described:
/5/2020/0latam-investimentos.jpg
/5/2020/0Tatiana-Pimenta-Vittude-scaled.jpg
Settings:
CDN
Organization: enabled
Cache-busting: disabled
Compatibility
Dynamic image support: disabled
WP Smush: enabled

I've tested changing the bucket folder to a random name and the folder organization works fine. This might be a conflict when the bucket folder has the same number as the month.

Updates about this issue:
Now that we are in June (month 6), my english version started with this same broken path issue (bucket folder /6/). The portuguese version is working fine with bucket folder /5/.
So i still think this is a conflict when the bucket folder has the same number as the month.

Hello @koganas
Is issue still relevant after update to version 3.1?

@planv Yes, I've got this issue in v3.1.0.

Found the solution to my problem in https://github.com/udx/wp-stateless/issues/493#issuecomment-649231809
I did not realise the year/month variables needed to be defined as well:
-define("WP_STATELESS_MEDIA_ROOT_DIR", "media");
+define("WP_STATELESS_MEDIA_ROOT_DIR", "media/%date_year/date_month%");


docs: steps to use nightly build

Type: docs
Ionic Version: 2.x
Platform: mobile webview
It would be great to have steps to use nightly build to try out latest features.
it's not like i haven't searched for it, somewhere in the issues i found 'how to' for it but didn't worked out.
Things which i have done already but didn't worked out
1- upgraded all @angular** to rc.4
and then  npm install ionic-angular@nightly - no luck
2- upgraded all @angular** to rc.4.
git clone ionic master branch followed step to build & test then manually copied dist folder to project's node_modules folder - still no luck
Update: followed steps from here  https://github.com/driftyco/ionic/issues/7125

This issue was moved to driftyco/ionic-site#739

Hello, because this was an issue related to the docs and not the framework I have moved this issue to the appropiate repo. Thanks for using Ionic!


Nested list

Hey! This plugin looks awesome, but I noticed that there is no support for nested lists. Or did I miss this? If not, will this featured be added soon, or is it something I do not have to expect in the near future?

Nested lists support is being tracked in #152.

+1 for nested list support


cleanup: remove mirror.azk8s.cn

What type of PR is this?

/kind cleanup
What this PR does / why we need it:
remove mirror.azk8s.cn
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

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

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

Totals

Change from base Build<PHONE_NUMBER>4:
0.0%

Covered Lines:
2564

Relevant Lines:
3611

💛  - Coveralls


Midea AG-12NXD1.WIK

Does this integration has support for Midea AG-12NXD1.WIK model?
Thank you and keep up the good work.

Can't say for sure. Easiest way is to just test for support with https://github.com/mill1000/midea-msmart.
Or if you know which app it uses that can be helpful.

The problem is I do not own mentioned AC and I would like to know if it is supported before I buy it.

It looks like it uses Midea Air app.

Based on the Midea Air app, it's likely that the device is compatible. I can't guarantee that of course.

Thank you!


Add WebNN delegate for tfjs-tflite-node

This change is

@pyu10055, @mattsoulanille, @huningxin, PTAL, thanks!

This is just a lint error, and we're in different time zones, so I'm going to commit a fix to this PR (if GitHub will let me) so we can get it merged.