Add lite mode to node run

Fixes #116 .
Includes the lite mode parameter on the node run,  an addition to the test_node test,and for testing purposes the account deploy returns the transaction hash.
*Note I'll be a draft until the issues that came after the merge are solved

What you mean by "issues that came after the merge"?

After I merge with the main branch the test node test I put in place to test the lite mode is failing

Closed in favor of #153


Handle cancelled allocation in 'weave attach'

Make IPAM return a simpler message and have the weave script check for that message and exit with status 0, so the proxy does not print any error message.
Fixes #1418
(replacement for #1425 which was against master not 1.1)

@bboreham please take a look at my changes. If you are happy I will squash them, though squashing them into your first commit will be tricky, so may just have to squash the lot.

LGTM.  I can do the squash into 2 commits - have already done it on my own branch.

Squashed.

Two issues:

There is an annoying blank line after the "cancelled" warning in the proxy logs:

INFO: 2015/09/21 19:54:47.023571 Attaching container 2f47c1e67e1b1c49e5aabbc6f0581b7ed04ada93f64c0d91f27d28cb4564bc8f with WEAVE_CIDR "" to weave network
WARN: 2015/09/21 19:54:48.690007 Attaching container 2f47c1e67e1b1c49e5aabbc6f0581b7ed04ada93f64c0d91f27d28cb4564bc8f to weave network: cancelled

INFO: 2015/09/21 19:54:48.690454 POST /v1.19/containers/2f47c1e67e1b1c49e5aabbc6f0581b7ed04ada93f64c0d91f27d28cb4564bc8f/resize?h=24&w=80

In https://github.com/weaveworks/weave/issues/1418#issuecomment-140030376 we observed that the cancellation is triggered by container death. Surely this can occur for most of the operations that invoke ipam_cidrs. And, furthermore, additional cancellation triggers may be introduced in the future. Yet only in attach do we check for the new $IPAM_CIDRS = "cancelled". Elsewhere we simply carry on. And in most cases we don't even look at $IPAM_CIDRS at all, only $ALL_CIDRS (which will be empty or contain CIDRS obtained prior to cancellation). The only thing saving us here is that the subsequent operations will fail if the container has died. This seems rather fragile. Also, what happens if the container dies just before we call ipam_cidrs? I did a quick experiment of adding docker kill $CONTAINER just before the ipam_cidrs call in attach. This causes docker run to stall. So we get different behaviour depending on when the container died.

I did a quick experiment of adding docker kill $CONTAINER just before the ipam_cidrs call in attach.
This causes docker run to stall.

I don't think it does, per se.  This is just the standard user-experience of weave IPAM stalling because it hasn't reached consensus.

This is just the standard user-experience of weave IPAM stalling because it hasn't reached consensus.

are you saying that cancelling container startup just before reaching ipam_cidrs results in a stall, but doing so during ipam_cidrs doesn't? That can't be right.


Remove deprecated 'folder' option

spo file list has an option that is named --folder, while spo folder list has an option that is named --parentFolderUrl
We're deprecating --folder in favour of --folderUrl to align with our naming convention.
For v7 we'll want to remove the deprecated --folder. This ticket is for doing that!

Opening this up as we are releasing v7 after the summer holidays. Warmly recommended for your contribution. 🎉
Target the v7 branch when raising a PR.

Can I work on this?

Hi @martinlingstuyl
May be I am missing something, but I cannot see the v7 branch to raise PR. Can you please guide?

Hi @nanddeepn, that's correct. @waldekmastykarz was going to make it, and you were super fast picking this up 😂

So let's just wait a bit. I'll ping you once it's created...

Thank you @martinlingstuyl
I will wait for v7 branch. The heavy rains here made to raise PR fast, as cannot go outside 😂

It's been created @nanddeepn

Merged in v7


[Mention The Feature]: Update UI

Is your feature request related to a problem? Please describe.
The website is missing some UI interactions
Describe the solution you'd like.
I would like to update the UI of the webpage to make it modern and more interactive.
Describe alternatives you've considered.
No response
Additional context.
No response
Show us the magic with screenshots
No response
Checklist

[X] I have checked the Existing Issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue. (optional)

for now we don't require for UI Improvements, we will look it for later.
So i am closing this issue.
Please Understand.


Profiler possibly ticking inactive chunks again?

Hi Nallar,
I was messing around with aperf tonight and noticed it was printing TE locations for what should have been inactive chunks.
Is it possible that inactive chunks are being ticked again since the change to cauldron? I can't remember the process we used to test that inactive chunks were being ticked.
Currently using Cauldron Build #60

@Cozza38 I wasn't able to replicate the issue initially, but during recent re-engineering fixed a possible cause.
Can you confirm if it's still a problem?

Hi mate,
I'm not doing much in the MC space anymore but I've pinged my staff team to take a look

That's fine :) I'll close it given the lack of response as it should be fixed after that change.
Sorry if I incorrectly closed it originally.


optimise cell registration

I found the tableview cell is instantiated twice un-neccesarily, this reduces the time take to register a table view cell.

Thanks, @stephenjames!
I've released this fix in https://github.com/DenTelezhkin/DTTableViewManager/releases/tag/11.0.1


Made constants fully upper case in camera server

Just making sure all constants in camera server are fully upper case.
Have to remember to check ARKit and ARCore PRs once this is merged.
Bugsquad edit: Fixes #29857.

Thanks!


Encoding file .kv in Windows

Versions

Python: 3.6.4
OS: Windows 10
Kivy: 1.10.0
Kivy installation method: Follow your step by step in: https://kivy.org/docs/installation/installation-windows.html

Description
I have identified an error using this characters in a String: çáàãâäéèêëíìîïóòõôöúùûü
In Windows, there is a problem when using the open (file, 'type') function, it does not open with default encoding "utf-8", so it is necessary to set  encoding='utf-8'  in the function.
For all OS to open without problem, just replace in:
kivy > lang > builder.py > line 288
From:
open (filename, 'r')
To:
open (filename, 'r', encoding='utf-8')
Code and Logs

# the old line
with open(filename, 'r') as fd:
# the new line
with open(filename, 'r', encoding='utf-8') as fd:

That's not an error. By design, Python uses the system's preferred character encoding when opening files. On Windows that happens to be Win-1252 (cp1252).
You can check what encoding your file has been opened with through f.encoding.
But yeah, I recommend you always use open(file, encoding='utf-8') unless you're doing some quick script or the like where it doesn't matter.
That's not a Kivy bug, however.

I believe this has now been carried out - UTF-8 is the new default.
Closing as completed. If the problem is still happening, please let us know.


Support for Kibana 8.0

Hi, wondering if there is a plan to support 8.0?

Sure, it is on roadmap.

Hi. is incompatible with the version 8.1.0
Plugin installation was unsuccessful due to error "Plugin enhancedTable [7.14.0] is incompatible with Kibana [8.1.0]"

Plugin installation was unsuccessful due to error "Plugin enhancedTable [7.17.1] is incompatible with Kibana [8.1.0]"

Well, plug-in is not yet compatible with kibana 8.1.
And globally, you have to install the precise package for kibana version.
so package that ends with “7.17.1” works only with Kibana 7.17.1, no other version.

For information, package for Kibana 8.3.0 is now available here:
https://github.com/fbaligand/kibana-enhanced-table/releases/tag/v1.13.2


Problem with special characters ampersand

I am having a problem when i need to use the ampersand for a password.
Following an example
Service.deploy.cmd /y /M:SERVER3670  /U:user-deploy-test /P:PassTe-&&&&Ld9
So, i got this error
&& was unexpected at this time.
I have also tried to use the escape ^, but did not work.
Do you have any suggestion for this case?

You can URI-escape characters for MSBuild. Try using %26 for each & character.

Tks, it worked


SectionList scrollIndicator

[x] I have reviewed the documentation
[x] I have searched existing issues
[x] I am using the latest React Native version

i use SectionList with  black background  and scrollIndicator not wisible. i did't find in documentation how is possible change color of  scrollIndicator .
(by ScrollView you have this feature but i try it and it's also not work)
Environment
Environment:
OS: macOS High Sierra 10.13.4
Node: 8.10.0
Yarn: Not Found
npm: 4.6.1
Watchman: 4.9.0
Xcode: Xcode 9.3 Build version 9E145
Android Studio: 3.1 AI-173.4670197
Packages: (wanted => installed)
react: 16.3.0-rc.0 => 16.3.0-rc.0
react-native: 0.54.3 => 0.54.3
Steps to Reproduce

Expected Behavior
would be great to have props for control it
Actual Behavior
ScrollView prop 'indicatorStyle' not working and SectionList not have this prop at all.

so i updated and did not get anything except warnings from 'react-navigator' (it's official library?)
property indicatorStyle={'white'} or black not working at all (bacause this props for IOS only)
would be great  if you can provide this prop for android. now it's imposible work with scroll if background dark. this is my Main issue.
thanks.

react-native-bot please . give me answer


How to set behaviours

Hi.
This example doesn't work.
<YMaps.Map
    width={width}
    height={height}
    state={{
        center: center,
        zoom: zoom,
    }}
    options={{
        searchControlProvider: 'yandex#search',
    }}
    behaviors={{
        disable:['drag', 'rightMouseButtonMagnifier']
    }}
>

Hi @leshiple
Behaviors are part of map state, according to this doc, so you can try doing this:
<YMaps.Map
    width={width}
    height={height}
    state={{
        center: center,
        zoom: zoom,
        behaviors: [/* enabled behaviours */]
    }}
    options={{
        searchControlProvider: 'yandex#search',
    }}
>

The only downside will be that currently state.behaviors prop wouldn't be updated if it is changed. I'll try to fix this in next release.
If you need to dynamically change map behavior, you can get an instance of map with instanceRef prop and change behavior with ymaps api methods (this solution is kinds hacky though)
// ...
instanceRef={(map) => this.mapInstance = map}

// somewhere in the code of your component
this.mapInstance.behaviors.disable('drag')
this.mapInstance.behaviors.disable('rightMouseButtonMagnifier')
// ...

Hi @gribnoysup. Thanks. It's cool!

@leshiple I released v1.0.0, now behaviours are updated on props change


http 1.0 is out-of-date?

Hi,
I'm just a Kong user, know little about lua.
Just wondering the code line 1050:
  local request = ("GET %s HTTP/1.0\r\n%sHost: %s\r\n\r\n"):format(path, headers, hostheader or hostname or ip)
if such health check request can adopt HTTP/1.1 ?

It should be fine. Unless you have a specific issue that's caused by this?

Hi @Tieske ,  http 1.0 is blocked by some firewall, maybe due to security concern.


Parallel put/post requests without BODY

Seems like BODY of second request disapears
(Server doesn't accept any request body) :(
Try it
var clientLib = require('node-rest-client-promise');

async getPutResult(someArray)
{
	return new Promise(async(resolve, reject) =>
	{
		var uri = 'http://localhost/some/put/method/';
		let client = clientLib.Client();
		try
		{
			let resp = await client.putPromise(uri,
				{
					data: JSON.stringify(someArray),
				}
				);
			resolve(resp.data);
		}
		catch (e)
		{
			reject(e.message)
		}
	}
	)
}

let twoArrays = await Promise.all([getPutResult([2, 3]), getPutResult([3, 4]]);

Hm. Can't reproduce. I took your example and made it runnable on my side. Here's my version, which works:
var clientLib = require('node-rest-client-promise');

async function getPutResult(post)
{
    return new Promise(async(resolve, reject) =>
    {
        var uri = 'https://jsonplaceholder.typicode.com/posts/1';
        let client = clientLib.Client();
        try
        {
            let resp = await client.putPromise(uri,
                {
                    data: JSON.stringify(post),
                }
                );
            resolve(resp.data);
        }
        catch (e)
        {
            reject(e.message)
        }
    }
    )
}

async function test()
{
    let result = await Promise.all([getPutResult({id: 1, title: "foo1"}), getPutResult({id: 1, title: "foo2"})]);
    console.log(result);
}

test();

results in:
[ { id: 1 }, { id: 1 } ]

Overall your code looks a bit weird as it, for example, creates a Promise, which is an antipattern.
I would rewrite your code like this:
let client = clientLib.Client();
var uri = 'https://jsonplaceholder.typicode.com/posts/1';

function getPutResult2(post) {
    return client.putPromise(uri, {
        data: JSON.stringify(post)
    })
    .then(resp => {
        return resp.data;
    });
}

async function test2()
{
    try {
        let result = await Promise.all([getPutResult2({id: 1, title: "foo1"}), getPutResult2({id: 1, title: "foo2"})]);
        console.log(result);
    } catch (e) {
        console.log(e.message);
    }
}

test2();


fix indexer-cli v0.20.11

Running graph indexer status with 0.20.11 causes an error due to the absence of the axios module.
We will therefore fix this with this request.

#596

Looks like CI is failing because the yarn.lock file is missing.
@mattsu2020 could you please add that change as well, please?
Thanks for your PR! :)

@tilacog
yarn.lock added.

We discovered that the root cause of the error was a missing dependency over indexer-common, so I'm closing this in favor of #605.
Thanks for the insight, @mattsu2020!


🇷🇺Russian translation

I also full tested work of the app with the translation.

Any pros or cons?


[FEATURE] EnumTest

Describe the solution you'd like
Make a class to help with JUnit testing of enums
Is your feature request related to a problem? Please describe.
Not really
Describe alternatives you've considered
None
Additional context
N/A

Reopening for other to/from value types


Fix for issue 765

Hi team,
This PR is to solve the issue #765 (requestBody not correctly populated when Parameters is a list of $refs (OAS 2 to 3 conversion))
Please review the PR and merge the same.
Thanks,
Mohammed

This PR looks good to me. Thank you a lot for this contribution.
I hope it will be merged soon...

Hi @gracekarina
Thanks for merging this commit.
Thanks,
Mohammed


Development & Production branches discussion

Now that we have an addon with traditional versioning (0.1.0, 0.1.1, etc), we need to think about how that affects our Github flow and branches.
The two "simplest" options I can think of are:
1. Single production branch, many forks (our current)
This is basically our current flow, which coincides with Github's own flow.
In this simple case development happens in forks/branches outside the master branch, and new code is only merged after review and passing our regression tests. So the branch is always "stable".
Versioning can be introduced by basically decorating the branch with git tags as we publish code out to AMO:
o <--- master
|
|
|
o <--- tag: v0.1.1
|
|
o <--- tag: v0.1.0
|
|
|

2. One production branch, one development branch, one hot fixes branch
This is a simplified version of git-flow.
In this case experimental code is pushed to a development branch, and occasionally it is merged into the production branch after thorough review, passing all tests, etc.
From time to time, one also pushes code to a "hot-fixes" branch off of a common ancestor between dev and production, which fixes problems with the production branch. Then one merges in hot-fixes into both production and development.
A new version is triggered every time there is a merge into the production branch.
Discussion
I think Github's fork system, combined with our testing infrastructure which is already tightly integrated with pull requests, naturally makes option #1 both doable and the most convenient.
In principle we would have problems applying hot-fixes to our addon since we would necessarily carry all the previous merges from the master branch. This is typically not desirable in most projects, as such merges might have introduced major features like a new UI, or worse unstable code.
In our particular case this is not a problem: the vast majority of our merges are actually "hot-fixes" (since they essentially fix previously broken PDFs), and in the rare cases of new "features" like a new UI we can simply hold that pull request back until we're ready for a new major release. Also our production branch is always "stable" thanks to the bot and PR review.
Looking forward to the ensuing discussion here...
/cc @wfwalker @jviereck @brendandahl @notmasteryet @ironymark

I think at this stage #1 still makes the most sense. We seem to be doing pretty well at not introducing (too many) regressions and our test suite is ever growing so hopefully we'll be catching more and more errors.  I also really like the current workflow and would rather not introduce too many complexities.

+1 for #1 :)


file still exists in ngf after it has been deleted

Hello,
I am experiencing what seems to be an identical issue as from this past Issue in 2015.
https://github.com/danialfarid/ng-file-upload/issues/971
I'm troubleshooting to figure out why. I have an option for the user to delete a file that has yet to be uploaded and saved to the server. I use the ngf-selected attribute that calls a function and if a user decides to add another file, the deleted file comes back with the newly selected file. Meaning, the $files array passed in is still holding the deleted file for some reason.

I was able to resolve this issue using the following code:
ngf-model-options="{updateOn: 'change click drop dropUrl paste', allowInvalid: false, debounce: 0}"


ubuntu 20 LTS -> ubuntu 22 LTS

jammy jellyfish
resolves #1112

GitHub Actions has released Ubuntu 22.04 support in beta.
We are currently suffering from the Docker issues the community is discussing on https://github.com/actions/virtual-environments/issues/5490

closing in favor of #1325 (we now have 3 YAML files to update)


Feat/password in user

What has been done:

Updated models to have password fields.
Added Jwt authentication tokens.
Updated frontend clients to use stored jwt token.
Auto-logout on expired token.
Updated some error handling that was not working properly.

 Task 8: Expose API To Get JWTAuthentication

 Task 8: Expose API to Get "current" user object from JWT Token

 Task 8: Add Token To All client requests


Add videos to docs

Add demo and overview videos from community calls to docs where applicable. Priority topics:

[ ] Pub/sub
[ ] Resiliency
[ ] Security

Which videos are you thinking of here?

@msfussell I was going to see if there were community call videos I could embed


magnetic contact does not change state

Good morning,
I added add-ons and entered the credentials, it sees me everything.
I can turn the alarm on and off.
But the states of the alarm contact do not change.
Axpro scope 1.0.25, but nothing is working, any ideas?
Thank you

What version of integration are you using?
Are you using AXPro or AXHub?

Axpro

sorry I did not understand , the status changes every 30 seconds? I watched it in RealTime thinking that was the reaction ....

Integration is pulling system status (default 30 sec) - configurable in settings. AKA settings "Pull interval".

You can set up this pull interval to be 1 second but it might be too much for the system.
5 seconds can be more reasonable.
Reason to "pull" is - AXPro does not have any "stream/listenable" API. So we pull data from system.

You're right, I put 2 seconds and it's responsive.
but the writings are wrong, and it breaks down

You can always ask.
Question is

Is there any way how to get just simple status updates of the devices? Not full state of all device of the system. But basically "on event" the AXPro would call something else?

The ARC is something like that but we need the update also when alarm is not secured.
Proper documentation would be amazing...

Sadly I cannot make my sensors make working. Tomorrow I am trying again. I will try to give some updates and results.

@winniko
Finally got my sensors working.
It is working, you just have to wait until sync interval (default 30 seconds)
tested on latest version 2.0.0

Closing for now. Please confirm if it is working or not.
We have to look more deeper.


https://iamb.chat/install.html broken links

https://iamb.chat/install.html has:

A snap is available for Linux distributions [which support it][install-snap]:

Perhaps just some bad links in the markdown file. I searched the repository to see if I could make the change myself, but I think it's not in this repository. Thanks!

The repo for the site is over here -> https://github.com/ulyssa/iamb.chat/blob/next/src/install.md#snap

Fixed as part of ulyssa/iamb.chat#27! Thank you for catching this, @valankar !


Removed rich embed filter as its no longer necessary.

closes #2977 .

LGTM, thanks.
I'll remove the filter on the server just before merging, once this has another approval from someone.

I have removed the filter.


Downloading a file link with target=_blank opens a new blank tab

Background
PR https://github.com/duckduckgo/Android/pull/666/ added support for handling target=_blank links, which allows for a link to be opened in a separate tab.
Some of these links can be files that the user wants to download. Downloading any of these files results in the app opening a new blank tab.
Steps to reproduce
Navigate to http://www.granditaliaperth.co.uk/menus.html and click on the download link for the menu.
The download will start and a new blank tab will be opened.
Objective
Ensure that this action does not open a new blank tab.

I would like to work on this issue.


Problem converting pdf to txt with pdf2txt.py

Can someone look into this issue - https://github.com/euske/pdfminer/issues/104  ? I have submitted a pull request to the same repositary - https://github.com/euske/pdfminer/pull/190 .

A fork of this repository has been created at - https://github.com/strideai/pdfminer.six . This issue has been fixed in this fork, and we will now be maintaining the forked repository.

Hi @ganeshtata ,
since you're willing to help, I invited you to the group that is supposed to maintain this fork.
If you have an account on Pypi, I'll add you as a maintainer there so you can upload new versions.
I think it's better not to multiply forks ...

Hi @goulu ,
I have accepted your invitation to join the group, and will help in maintaining this fork. I have also created a Pypi account with username - # tataganesh.

Nice @ganeshtata . I added you as owner on https://pypi.python.org/pypi?:action=role_form&package_name=pdfminer.six
Welcome aboard !

@goulu  Thank you!

This issue has been fixed in this commit -  chttps://github.com/pdfminer/pdfminer.six/commit/1b88575e79fb5a8a77243fa1c227da9366707d40


Too many web connections generates zombie tcp connectoins

What did you do?
When running Prometheus with the default of 512 max web connections and receiving > 512 concurrent connections, Prometheus seems to drop tcp connections in various states.  Netstat shows that there are over 1,500 ESTABLISHED connections to the web port and thousands of connections in failed states.  All other functions of Prometheus (eg: scrapes and alerts) were working as expected.  No CPU or memory contention.
After setting --web.max-connections to 1024 the problem was resolved and there are roughly 800 connections with the majority in ESTABLISHED and 0 dropped connections (CLOSE_WAIT).
What did you expect to see?

Prometheus return an HTTP 503 or similar error that the server is busy.
A steady count of 512 ESTABLISHED connections.
A metric to track the number of concurrent connections (ie: a gauge of how many used or available connections exist when the most recent connection was made)

What did you see instead? Under which circumstances?

Request timeouts
Failed readiness probes due to connection timeouts and response timeouts
Connections to the web port in various poor states (see below for a snapshot)
No more than 512 ESTABLISHED connections
No logs or metrics indicating the connection limit was hit

Snapshot of the number of connections to port 9090 and their various states with max conns of 512
   2680 CLOSE_WAIT
   1573 ESTABLISHED
      1 FIN_WAIT1
   5443 LAST_ACK
      1 LISTEN
    192 SYN_RECV

Snapshot of the number of connections to port 9090 and their various states with max conns of 1024
    634 ESTABLISHED
      1 LISTEN
    158 SYN_RECV
     13 TIME_WAIT

System information
Linux 5.15.74
Prometheus version
Version	2.39.1
Revision	dcd6af9e0d56165c6f5c64ebbc1fae798d24933a
Branch	HEAD
BuildUser	root@273d60c69592
BuildDate	20221007-15:57:09
GoVersion	go1.19.2

Prometheus configuration file
global:
  evaluation_interval: 30s
  scrape_interval: 30s
  external_labels:
    environment: production
  query_log_file: /dev/stdout
rule_files:
- /etc/prometheus/rules/prometheus-prometheus-operator-prometheus-rulefiles-0/*.yaml
scrape_configs:
  ...
alerting:
  alert_relabel_configs:
    ...
  alertmanagers:
    ...

Alertmanager version
No response
Alertmanager configuration file
No response
Logs
No response

It looks like the issue was caused by excessive connections from the Elastic Load Balancer. Changing the ExternalTrafficPolicy to Local and using HTTP health checks instead of TCP health checks appears to have resolved the issue. Based on this information, I'm going to close this issue. Thank you for reporting it!


Update Configuration example version

Mainly for 1st centralized uptest test

Description of your changes

Fixes #
I have:

[ ] Read and followed Upbound's contribution process.
[ ] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested

/test-examples


Breadcrumb: Collapse intermediate levels

The problem
When there is a sufficient level of nesting, breadcrumbs become unwieldy to read. On mobile devices they take up a large amount of real estate as well.
The solution
When there are 5 or more levels in the breadcrumb, collapse the breadcrumbs between the root and the leaf items into a dropdown menu with the condensed icon as the menu trigger.
Additional information
We may want to collapse the breadcrumb even earlier on mobile devices. Maybe we even want this to be a prop of the component?

Closing this for now as the drivers haven't come back up in the intervening 2 years; this can be reopened or revamped if those drivers should come about later on.


How to use regular async import in webpack for non-presentational modules

I'm using this module along with redux-first-router and react-universal-component. Besides splitting up my presentation components i really want to split up my redux middleware, epics and reducers.
I've made pretty good progress using the onLoad in react-universal-component to include the redux ware but really what I need is a way to import my redux dependencies during the thunk for the route. Then I can async include all my extra route specific redux deps, get the state, and then try to render with the universal component.
What I've found is that using this module the result of an import looks "wierd". When I await it returns a function rather than the whole module. I've looked at the code for both react-universal-component and universal module and i just can't wrap my head around the api that import with the plugin produces.
Is there a way to disable the babel plugin for only a few imports? I'm using webpack on both the server and the client... maybe here a short-hand way to use the result of the import ?

glad to hear you're using them all!
...there is some custom stuff there, and im gonna try to remove it in a future release. it's not a real promise, but rather an object with .then and .catch methods. Try calling them directly rather than using async/await.
I'm not the super happiest with what i had to do to preserve the promise-based API, but in the future we'll actually be dropping support for several things and can likely simplify this as well.
Probably a few weeks off.

another option is to use good 'ol require.ensure. those wont be parsed. but try regular promises first. if .then works, it's a good sign, and i just gotta add something for async/await.

At the risk of piling on, I've seen a similar weirdness with getting back functions that return the imported object. dual-import seems to work fine but universal-import has trouble with it.

@phyllisstein do you have the same issue if you use import('fontfaceobserver/fontfaceobserver.standalone').then(FontFaceObserver => ...?

I don't! Looks like this might be another async/await thing à la #14.

well that's a good sign. that's what should be used for now. when i get back around to universal stuff, i'll solve it for good--likely by removing some functionality that we will no longer support, which indirectly will result in not needing some of the fancy stuff here.

Client side i can import async just fine with then, which looks normal, and with await/async i do the following:
const EpicsModule = await import('./epics')
const { createAsyncEpicWare } = await EpicsModule()
const {ware, next} = await createAsyncEpicWare(epics)
addMiddlewares([ware])

Wierd but it works perfectly fine
Server side it does not seem to matter which one i use, i always get this error:
TypeError: __webpack_require__.e is not a function
    at webpackAsyncContext (/Users/jonathanwickens/dev/humanise-web/buildServer/webpack:/src/async/pages lazy ^\.\/.*$:47:1)
    at load (/Users/jonathanwickens/dev/humanise-web/buildServer/webpack:/src/async/index.js:5:38)
    at Object.config.then (/Users/jonathanwickens/dev/humanise-web/buildServer/webpack:/node_modules/babel-plugin-universal-import/universalImport.js:8:1)
    at process._tickCallback (internal/process/next_tick.js:188:7)
[]

For now I'm just using the onLoad functionality to achieve what I need. However I can't await the onLoad server side to make sure that all redux deps are included to then perform initialisation actions.
Doing it in the route thunk would actually be a lot slicker because i already await that server side and it comes with the added benefit that redux-first-router does not call the thunk again client side so i avoid calling my initialisation actions twice :).

Btw I'm using babel 6.26, so nothing to do with babel 7 on my side.

Awaiting onLoad is a different issue. Ultimately the webpack client side dynamic import functions will be problematic in the server.
In the future RFR will have Route level stuff to handle code splitting and all the additional things u might wanna import/do. It's one of the many reasons component level is no bueno.
You can attach stuff to your routesMap for now and then manually "flush" it FYI. Just by discovering which route will render calling and awaiting arbitrary functions you put on it. Then make onLoad simply not work server side. U could also just skip onLoad all together and do something similar with the route object client side.
Ultimately Route level is gonna be the only way to do this at the highest level, since the highest level will involve using the new renderToString streaming API, which means u need to discover which stylesheets to serve solely based on the route before anything is rendered. That's where we will be going with all this, and very soon. But U can manually do all this using the thunk and onAfterChange handlers. You'd basically be a pioneer by piecing this altogether. In a few days I'll in fact adding this functionality to Rudy. So any info will be very helpful.

Thank's so much @faceyspacey for saying that! Really changed my thinking. I'd forgot react 16 was just released and I definitely want to get on that boat. I've switched over to react 16 and am now using RFR + flush chunks to do a pure redux method for async loading components, still early days but this is looking really nice.
Here's a snippet of my route map:
export const ROUTE_MAP = {
  [constants.LOGIN_PAGE]: {
    path: '/login',
    load: loadPage('login'),
    thunk: load
  },

The load thunk just calls load (some other routes also do other things before or after load in the thunk). Load is separated out so on client hydration we can call load separately.
loadPage is itself an async action:
const isServer = typeof window === 'undefined'

export const loadPage = (page) => async (dispatch) => {
  // this payload will be used to identify the module
  const payload = {type: 'page', value: page}
  dispatch({type: constants.ASYNC_MODULE_LOAD_START, payload})
  // import has be different here. YMMV if you use a babel server
  const mod = isServer
    ? await import(/* webpackChunkName: "pages/[request]", webpackMode: "weak" */`../../async/pages/${page}`)
    : await import(/* webpackChunkName: "pages/[request]" */`../../async/pages/${page}`)
  // register in state that we need further chunks
  dispatch({type: constants.ADD_CHUNK, payload: `pages/${page}`})
  // load any reducers, middleware defined in the module
  dispatch(loadModuleRedux(mod))
  // store the component in the state for later rendering
  dispatch({type: constants.ASYNC_MODULE_LOAD_END, payload, component: mod.default})
  return mod
}

The react component itself is simple, all it has to know is how to get its slice (based on payload for the ASYNC_MODULE_LOAD_* actions and then it can get whether its loading and if not its resolved component (breaking the rule on serialisable objects there)
On the server side once I've awaited the route thunk I can then go get all the chunks these loader actions added through ADD_CHUNK, and i then pass these chunk names to flush chunks.
Well that's about it. There's also a bit of work in loadModuleRedux which looks for mod.reducers ect to be defined.
Sorry if this got a bit off track from the repo, but I thought Id share anyway.

the only thing i'd say is you dont need all those actions.  The reducers should be smart enough to know for example that constants.LOGIN_PAGE is the equivalent of dispatch({type: constants.ASYNC_MODULE_LOAD_START, payload})
..So that's one aremoved.
then the last 3 should be combined into one.
In short your thunk only dispatches one "follow-up action" while the initial "setup action" was synchronously handled by the system (i.e. on the server at the beginning,  or a click handler).

the next stage is to provide a function like rfr.flushChunks. And what you do is on each route put an array of chunks that correspond to it, and then you simply grab that array off the current route. Then u can use those chunks to generate the stylesheet names and prepend the stylsheets to the top of your HTML before you even start rendering. That way you can render to a stream for optimum performance.

also, one other thing:
if one route has the ability to produce multiple chunks, you need to put a function on route.chunkNames and pass it params similar to what thunk receives, or perhaps just state. That way you can use the payload of the current action to determine the chunks. For example:
configureStore.js:
const routesMap = {
    FOO: {
        path: '/foo/:param',
        chunkNames: locationState => {
             const upperCaseFirstCharacter(locationState.payload.param)
             return [chunkName])
        }
    }
}
// etc, ie:
// connectRoutes(routesMap)
// return createStore()

*server/render.js:*
```js
export default ({ clientStats }) => async (req, res) => {
   const store = await configureStore(req, res)

   // this is like react-universal-component/flushChunks, but at the route level.
   // essentially RFR will have a method named: `rfr.flushChunks()` that does this:

   const type = store.getState().location.type
   const chunkNames = routesMap[type].chunkNames(store.getState().location)

   const { styles, js, cssHash } = flushChunks(webpackStats, { chunkNames })

   // notice we can now render to string/stream after flushing now!:

   const app = createApp(App, store)

   res.write(`<!doctype html>
      <html>
        <head>
          ${styles}
        </head>
        <body>
          <div id="root">`)

   const stream = renderToNodeStream(app);
   stream.pipe(res, { end: false });

   stream.on('end', () => {
    res.write(`</div>
          <script>window.REDUX_STATE = ${JSON.stringify(store.getState())}</script>
          ${cssHash}
          ${js}
        </body>
      </html>`);
    res.end();
   });
}

So anyway it comes out pretty cool. The idea is we still use webpack-flush-chunks, but instead of getting chunkNames from react universal component, we get it at the "route level" via RFR!
And of course this all plays out for a very specific business purpose: to send the layout of the page + all styles before the stream begins. That way the layout and the content rendered in the stream itself has all the styles it needs from the beginning, without having to fully render to discover the complete list of styles.
Ultimately, to do this at the highest level, you can send the initial layout of the page immediately at the very beginning of the request, before awaiting thunks server side. You'll of course want to get the initial state of the route to insure it's not a redirect, but immediately then you can start sending stuff to the client, which browsers will begin to render immediately, i.e. without closing tags, i.e. without the entire content. It's a major win for React SSR. And you can do all this before RFR automates it for you, pretty much just as above.
Make sure to read this article:
https://hackernoon.com/whats-new-with-server-side-rendering-in-react-16-9b0d78585d67

This is all super cool, the next version of RFR is going to be amazing! That prefetch feature will also be really helpful.
I guess why I have so many redux actions was to break up the different things i have to do on top of RFR. I also find using pure redux actions and reducers really understable and enjoyable in my own setup. Rather than using a function to map the route to a set of styles, dispatching "add chunks" and then getting the chunks out of the state is just so simple, and it allows easy composition of multiple or nested loaders.
I also think "thunk" is no longer descriptive in the api as-is. Its necessary to distinguish between different thunks for different stages:
* entryCheck: optional, to check authorization for example and issue a redirect, skipping other stages. RFR should call this recursively until it the entry check passes.
* load: loads all async components and redux ware for a route. On the server additional state chunkNames are provided. On the client it updates the loading state for the route.
* initialization: called on the first load, also detects hydration for skipping on ssr

Basically you dont want to load if you dont pass the entryCheck, you always want to load, and you only perform initialisation one.
This could allow one additional optimisation: sending the styles before performing initialisation functions that are likely fetching data.
export default ({ clientStats }) => async (req, res) => {
   const { store, initializeRouteAction } = await configureStore(req, res)
   if (!store) return

  const { serverOnly: { chunkNames } } = store.getState()
   const { styles, js, cssHash } = flushChunks(webpackStats, { chunkNames })

   res.write(`<!doctype html>
      <html>
        <head>
          ${styles}
        </head>
        <body>
          <div id="root">`)

   // while our client is loading style sheets the server is fetching data for the first view
   await store.dispatch(initializeRouteAction())

   const app = createApp(App, store)
   const stream = renderToNodeStream(app);
   stream.pipe(res, { end: false });
   stream.on('end', () => {
    res.write(`</div>
          <script>window.REDUX_STATE = ${JSON.stringify(store.getState())}</script>
          ${cssHash}
          ${js}
        </body>
      </html>`);
    res.end();
   });
}

So I ran into one more thing I forgot... loading the CSS. I tried the dual import plugin but that lead to the same problems as above.
Instead I've setup some more redux state and actions to replicate what the plugins were doing.
Here's a redux log of what happens client side on SSR for the login page, followed by switching to the dashboard.

Note a separate hydrate action is required because on the initial load of state when configuring the store client side, extra reducers in the "async modules" are not available, so that state gets ignored.
In the render server side I use an action pass the raw css hash from flush chunks into redux:
css-actions.js
export const registerCssByChunks = (cssHash) => (dispatch, getState) => {
  const { serverOnly: { chunks } } = getState()
  dispatch({
    type: constants.ADD_CSS_BY_CHUNK,
    payload: cssHash
  })
  chunks.forEach(chunk => {
    dispatch({
      type: `${constants.LOAD_CSS}_FULFILLED`,
      payload: { chunkName: chunk }
    })
  })
}

The chunks should be flushed and available on first load. those chunks should have any async modules you need. if for example you were just using babel-plugin-universal-import and react universal component + webpack flush chunks, you could export additional things like the redux stuff from the component file.
As far as the multiple actions thing, the idea is you got a function that takes a (page) param. Then you remake actions and payloads based on that. But you get that same param in the route thunk. So it's a matter of making your reducers smarter to respond to that same action. It's the same thing, just less actions, smarter/fatter reducers. You make the reducer that returns components return strings of the components, and just get them from a global hash somewhere in your component tree.
The RFR way isn't dispatching all this async-related stuff like you're doing. I'm not sure exactly what's different about your setup that makes you want to do this. You're also dispatching all chunks you already have in state in a forEach. You already have the chunk, you don't want to do this. I personally don't trust redux running so much. Performance is horrible when it comes to animations. React 16 improve it, but the browser sucks, and I don't care what anyone else says. I've experienced and spent literal years optimizing on both React Native and web for redux/react updates during animations. So it's horrible for performance. You want to dispatch the least amount of actions, which updates the store the least, and triggers the least re-renders. You're not only updating the store, but getting re-renders as a result. In addition, it's a ton more imperative logic that could just live in smarter/fatter reducers. items.forEach => dispatch I would never do or recommend. You don't want that. What you want is to send the data once in a single action and have your reducers interpret it. It reduces the # of actions and simplifies your application greatly. Ultimately the simplification is more important than the performance.
Also, you know RFR supports "pathless routes" now, right? Check the top of the RFR readme. So you don't need to create traditional thunks. Everything can live under one routesMap. That also means you don't need to dispatch functions from components anymore, have react-redux prepare em, etc. You can just always dispatch async actions (similar to Sagas and Redux Observable), and have Redux-First Router map it to a thunk function. Perhaps more importantly, the "setup action" of a traditional redux thunk is now automatic and implicit. It's the sync action you dispatch. In traditional redux-thunk, you dispatch a function, then you dispatch a "setup action" and then do some async work and then the "follow-up action." That's 3 dispatches. With RFR it's just 2.
I don't think awaiting your component in a thunk is the way to go. That's double the work--because the component has to do it as well. Of if your components are getting it out of a reducer like i think you're doing, you're essentially missing out on all the automation and features of something like react-universal-component. It means you gotta build the related stuff from scratch. That's totally fine, and may just boil down to handling when to show the spinner on your own. Just wanted to point that one out. I'm not sure how I feel about that one. You could be on to something, I just don't know right now. For now though, it means rebuilding more things from scratch.
As far as the additional thunks. We actually have these (and will be released today or tomorrow):

beforeEnter
thunk (tho may have onEnter as an alias)
afterEnter
beforeLeave
onLeave

And they will all exist globally and for each route.
That leaves one more problem, which you brought up: doing auth in conjunction with streaming without running everything in the middleware, particularly the async work. Basically The problem is that you'd like to be able to do res.write with the head of your page immediately, but you can't do that if there may be a redirect.  So as you pointed out we may need another callback or feature for this. I mean basically u can get around it in your own app with a set of simple rules:

if the route is a public route (i.e. is marked as route.public), stream immediately
if route is marked as route.private validate the jwt token first thing before running through the RFR middleware, and then stream
if the route is marked as route.private and there is no valid jwtoken, perhaps run the middleware and let it determine where to redirect to; or perhaps you simply know, and then just redirect to /login immediately.

So this is all easily done in userland. The goal is to find a flexible enough way to build into RFR that can work for enough use-cases. beforeEnter can handle it--you just have to make sure not to also use it for other async work. So we may already have the recipe. But I do like the idea of something built in for redirects and auth stuff. In fact, that's what I'm working on right now. I'm thinking of how to short-circuit the middleware as soon as possible. Here's what i'm thinking:
  const middleware = (store: Store) => (next: Next) => (action: Object) => {
    if (isServer() && isRedirect(action)) return action
``

Previously you had to do `getState()` after the middleware runs on the server, but even that requires all your reducers to run. To do this at the highest level means not running all those reducers unnecessarily. We have the recursive `route -> thunk -> redirect -> another route -> thunk` thing now. So as soon as one of those actions is a redirect, we should short-circuit. The one challenge with that now is simply some of your route thunks may return other things (perhaps the result of an api request). Then you have to detect if the return is an action etc.

Here's how it works now (on both the server and client):

```js
const action = await dispatch(firstRoute())

On the server, you'd do this if we move to returning the action and not letting the whole middleware resolve:
const action = await dispatch(firstRoute())
if (doesRedirect(action)) return false

Anyway, lots to think about to do this perfectly, which is why i was bringing up those things about how ur doing it. If ur absolutely right about the multiple dispatch approach, etc, i wanna know about it. But from my standpoint it's not currently, and it's not going to be in the near-future, the promoted RFR way. And I think there very is a way here. Dispatching entire asynchronously received modules could be, but all the dispatches definitely not. They're simply not needed. It means more code to maintain, and a decrease in performance. This is the cusp man. Rudy is the future of React development. For the 80% use-case that most developers use. Dumb components.  That will mean your most complex logic lives in the "controller" layer, i.e. Rudy. The whole thinking is that components and reducers stay dumb.  If you gotta make an exception to mount a high chart in a lifecycle handler fine, or over-coming a browser bug, fine, but the rest is stateless functional components. That's how they do in clojurescript btw. And it's the right way. The problem for React proper and JS is that on one end of the spectrum we have super experts preaching component level through Relay, Apollo and GraphQL, and then we learners going component level as well (but without those nifty abstractions), and then they run into a bunch of problems where 99% of them are doing things like dispatching redux actions in componentDid/WillMount--when really the correct pattern is to dispatch the actions only on events like clicks and taps. Those learner developers (which are ultimately larger percentage of developers than experts, given the pyramid nature of increasing one's skills) end up in a world of hurt. I've seen a lot of these apps.  And these developers are in pain. Most don't full grok that proper Redux usage means stop using lifecycle handlers to manipulate state. The reason is simply this: middleware is complex, piecing it together with React Router is non-obvious, and there isn't a redux-first router that establishes an obvious idiom (until recently).   The future of React develop as I'm trying to make it is a world where your most complex work is in your controller. And it's a far better world because you don't end up with the mess people have in their components these days. A key ingredient to this world is less actions. Where does your async function that takes that (page) parameter live? Where does it get called? If it's not in a route, that means you gotta insure all those actions are also dispatched if the user presses the back/next buttons or visits the route directly. Same on RN with deep linking and push notifications. Fine, you got thunks and other callbacks--at least that solves it. Before without that, people ended up using lifecycle handlers to dispatch all that stuff when u arrived on a route that rendered that component. The point is the route becomes the controller of the whole setup. It dictates what's needed to reproduce the exact state it will need. And this allows you to reach the route in any way possible--not just when the user clicks the right button with the correct onClick handler in a previous component. So taking that mantra all the way means minimizing the amount of work you're doing in your route thunks (or the other new callbacks we have now). You already have the "setup action" dispatched by virtue of the fact that the route was hit. Any state that can be achieved via its payload, type, etc, should be handled by the reducers. There's only one thing u should do here: things that reducers cant do. I.e. async work. The reason is reducers are dumb. Dumb is a good thing. When things are dumb/pure, it means following their logic is easy. You start detracting from that inherent simplicity when you start dispatching more actions. And ultimately async data fetching is going to be the most complicated part of your app. It just easy. Dumb pure synchronous functions (i.e. components and reducers) are easy. Async functions/thunks that basically mutate state and make multiple function calls, dictating multiple code-paths are complex. And they do mutate state. Even tho it's done through a predetermined mechanism: dispatch and the mechanics of redux, your thunks are basically the one place that mutates state. Sure if you're doing it correctly, you're doing it based solely on the payload, type, etc as just mentioned. BUT, the code still looks like typical spagetti code from the OOP/procedural/imperative days of old. Thunks are essentially a random list of directives of things to do, which may or may not even be related--whereas reducers and components are focused on a return. On an output. A pure output. So even tho thunks are pure on the input, they aren't on the output. Ultimately the thunk and other callbacks will be doing things like scroll restoration, triggering modals, telling tracking tools like Mixpanel what happened, etc. So these thunks are already quite complicated. According to the direction of Rudy, it's the only place that isn't pure on both inputs and outputs. Anything that is pure on inputs and outputs like components and reducers is "easy" by that very nature. So given that components now have a reduced role in terms of the work they will be doing, more of this work will end up in route thunks (or pathless route thunks), or the other aforementioned new callbacks. We're cleaning up the mess in one place and isolating it and moving it to another, the same way you efficiently sweep up messes on the floor. We have 2 boxes checked, now we gotta setup for a scenario where our thunks/etc also don't lose shavings and dust-balls and become un-ordered. To prepare for that world, we must make our focus to do as few dispatches as possible. That will cut the size of those thunks in half or perhaps by 3 quarters or more. Shift everything that can be done in a pure environment--without making it impure--to the pure environment. That's the mantra in a nutshell.

now that all said, i do find it really interesting having those cssChunks (and imported components themselves) living in Redux. That's definitely a fresh take. I think you're on to something with that. Not sure if we need all the actions. And simply it might just be something perfect for Rudy to do for you.

I must admit I also find my current setup a bit spaghetti, some of the new features in Rudy will help a lot to clean that up. Also what you're saying about less actions definately sounds worthwhile. I am getting a big of jank with switching between chunks and my guess that you're saying about the render is definately true. Will look to simplifying that a lot. BTW Regarding the for each to batch send my actions... normally I don't do that! I have a batch action reducer and corresponding action that I use during my async actions.
I have a ton of middleware and enhancers in my redux setup and I really appreciate/need each one. observables, async (which dispatches only 2 actions), optimist (for optimistic updates), responsive for detecting the screen size. Needless to its quite a complex setup and for something like a login page most of its not needed.
So yes I am loading my component from the redux state in my async loaded react components. Its great! It results in a really dumb pure functional component to show either that its loading or to pass the result through from redux-connect.

Just flagging this as still broken, in precisely the way described above: https://github.com/faceyspacey/babel-plugin-universal-import/issues/16#issuecomment-333015917. With universal-import included in the Babel plugins, standard async/await calls don't return the awaited value, but a function that, when called, returns the awaited value.
In the app I've been developing, we use async/await heavily to smooth over Promises, which means we can't use this plugin. But without this plugin, our stopgap solution (adding the universal callback and Webpack resolveWeak calls by hand) breaks HMR. We're kind of backed into a corner.
I'd love to submit a PR but I'm not sure I understand what case https://github.com/faceyspacey/babel-plugin-universal-import/blob/a6e220e31e4c65661fd9e88a321b0fd5bfbf8838/index.js#L190-L202 is covering well enough to preserve the intended behavior. As I mentioned above, ripping it out altogether seems to do wonders.

Based on the test snapshot, it looks like the issue is that in this particular case function doesn't need to be passed to universalImport:
https://github.com/faceyspacey/babel-plugin-universal-import/blob/a6e220e31e4c65661fd9e88a321b0fd5bfbf8838/__tests__/__snapshots__/index.js.snap#L17
Instead of this template:
https://github.com/faceyspacey/babel-plugin-universal-import/blob/master/index.js#L173
we should simply rewrite another one like this:
const awaitLoadTemplate = template(
    'Promise.all([IMPORT, IMPORT_CSS(MODULE, CSS_OPTIONS)]).then(proms => proms[0])'
  )

Notice () =>  is now gone. That seems to be the precise issue described here: https://github.com/faceyspacey/babel-plugin-universal-import/issues/16#issuecomment-333015917
And it shouldn't break anything else.

Thanks so much for the pointer 💖! (Always read the tests, Daniel, schoolboy error.) I'll try to get a PR up this weekend with additional test cases for the vanilla async/await behavior.

That path took me a bit farther, but I think it's creating a circular dependency in Webpack. When I use async/await to load the main application bundle, it throws this error:
Uncaught TypeError: __WEBPACK_IMPORTED_MODULE_8_react_universal_component___default(...) is not a function
    at Object.<anonymous> (https://dugan.cutty.dev/assets/js/app.js:42578:78)

Switching back to a synchronous require resolves it (though Universal Component complains that load isn't a function).
It strikes me that the ideal solution would be to only manipulate import expressions that occurred as arguments to a call to Universal Component, but given that the local identifier lives in userland I can't think of a way to find it without walking all the import statements from the module root, as babel-plugin-lodash does.

In the future I'll rewrite it to make use of bindings to modify the options arg passed to universal instead. I did it this way because I wanted the babel plugin to be as fast as possible, but the costs in complexity of code are too high. It has to change, but that won't be for a few more months.

How are you using async/await before your bundle is ready? I guess it's all polyfilled etc just prior via another way or vendor bundle.
Does async/await work in a simpler more isolated case than when importing the entire main bundle?
What will really help is logging the transformed code from within babel-loader before webpack changed it entirely. If you add a console.log to the file in nod_mosules, your terminal will get filled with text; so you will need to search it for relevant words like "universalImport" to find the relevant code.
After that, compare it to the final webpack output. At one of these stages something incorrect with the transformation will become visible. The logged errors in this case are only a small part of the story.

Sure, that makes sense. Is that an effort that I could kick off, or help with? Obviously we've both got lives and day jobs and other pressures, and I'm very new to Babel's innards, but I'd be more than happy to give some time and energy back to a project that's been so useful.

I was a little unclear: the bundle's entrypoint is one of the places we drop async/await, to guarantee that things like polyfills are available before the main application loads. So it'd look something like this:
// client.js
;(async () => {
  // Polyfills, animation globals, and all that jazz.
  if (!('requestIdleCallback' in window) || typeof window.requestIdleCallback !== 'function') {
    await import('requestidlecallback')
  }

  // Boot the React app.
  await import('app')
})()

We want to define split points for large libraries, especially when they're conditionally required, but choreograph their load order so that they're available to the main application, so awaiting import expressions seems like the way to go.
The problem is that the "vanilla" await expressions get caught in this plugin's net, so that Babel transforms that code snippet into:

Babel output w/ Universal Import
var _importCss = _interopRequireDefault(require("babel-plugin-universal-import/importCss")).default;

var _universalImport = _interopRequireDefault(require("babel-plugin-universal-import/universalImport")).default;

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

// client.js
;

(async function () {
  // Polyfills, animation globals, and all that jazz.
  if (!('requestIdleCallback' in window) || typeof window.requestIdleCallback !== 'function') {
    await _universalImport(function () {
      return Promise.all([import(
      /* webpackChunkName: 'requestidlecallback' */
      'requestidlecallback'), _importCss("requestidlecallback", {})]).then(function (proms) {
        return proms[0];
      });
    }, false);
  } // Boot the React app.

  await _universalImport(function () {
    return Promise.all([import(
    /* webpackChunkName: 'app' */
    'app'), _importCss("app", {})]).then(function (proms) {
      return proms[0];
    });
  }, false);
})();

Ideally, I think, those non-Universal await expressions would be left untouched. I think there's a hacky way to do it with the plugin's current architecture---you could step up a fixed number of parentPaths and check to see if there's a CallExpression roughly where you'd think it would be---but it didn't strike me as the best answer. 🙁

Hey @phyllisstein I just moved this week, so I've been MIA. Honestly I'm super focused on getting the next version of Redux First Router out, and plan to circle back to this and give it a major revamp. It's killing me inside to try to find the time for what will just be a temporary solution. In the next version we'll circumvent this issue via the aforementioned usage of bindings or other similar solutions.

Congrats on the move! And no worries---we'll make do for now. Please do ping me if I can be useful in your efforts though. 💖

Why is this issue closed? I read the entire thread, and it seems that it's still impossible to use regular async/await for importing modules, which is a bummer. Or am I missing something?

@buzinas This is a very low priority on my radar. Always willing to accept PR's but there are newer, more advanced things on the way which ill be using to replace Universal. Babel isn't my strong suit either, Im facing a similar async issue I might need to patch in another plugin - if I do patch it there, ill look at rolling it here

My main problem is that I my project uses react-static, which uses babel-plugin-universal-import under the hood (only in production). I can use async/await in development, but when I deploy it, the problem underlined in this issue happens (the dynamic import returns a function, instead of a promise). If I workaround it by calling the function it returns, everything works – but only in production, and then my development environment breaks. So the only solution for my problem at this time is:
let myModule = await import('my-module')
if (typeof myModule === 'function') myModule = await myModule()

Then it works in both environment, but this is a very very ugly hack.
Dynamic import should just work, I can't see why it doesn't at all.
If you can give me any guidance on how to proceed, I'll definitely come up with a PR, but I can't quite understand this plugin behavior, so I really need some kind of help.


Use generic resource config plumbing to do common resource customizations

Description of your changes

This PR introduces the same generic resource configuration setup as used by aws/gcp jet providers (config/providers.go and config/overrides.go). This should make it easier to do common resource customizations.
Common customizations introduced with this PR:

restructure/rename the provided CRDs to a hopefully more sensible names
changed grouping for some resources to allow cluster/project refs without go cyclic deps
use IdentifierFromProvider for some resources
create cluster_id and project_id references

The api version of manual configured Cluster resource is bumped to v1alpha2, the other resources remain at v1alpha1. The new api reference can be inpsected here
I have:

[X] Read and followed Crossplane's contribution process.
[X] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

ProviderConfig is unchanged and remains at v1alpha1.
Examples tested:

authconfig, Rancher UI shows Auth Provider as expected
catalog, Rancher API browser shows item as expected
cloud credential, Rancher UI shows cloud credentials as expected
project, Project shows up in Rancher UI
namespace, Namespace is created under the example project

@ytsarev hopefully yo have a few mins spare to look at it

Thanks a lot for all the tests and clarifications, I think we can merge this one.

Additional changes to fix individual resources can be separate PRs imo, as it seems some resources are a little bit more 'complex' and require additional config.
For example, managing secrets throws CannotObserveExternalResource", "message": "cannot run refresh: refresh failed: Getting secret V2: Cluster ID and/or Secret V2 ID is nil
Or importing a cluster starts a reconcile like it owns the cluster "reason": "CannotUpdateExternalResource", "message": "cannot apply: apply failed: Bad response statusCode [422]. Status [422 Unprocessable Entity]. Body: [baseType=error, code=InvalidBodyContent, message=must have at least one node pool]

@sboschman could you please create in Issue for last one?

Did some digging into the cluster error, reason: https://github.com/rancher/terraform-provider-rancher2/issues/895
Cluster is imported with Crossplane into Rancher, so cluster lifecycle is managed outside Crossplane and Rancher. Rancher does place some annotations, which are returned by terraform (state). One of these annotations is an internal sync timestamp for Rancher itself. Crossplane detects config drift on this annotation and tries to resync the cluster resource. The terraform apply runs into the terraform-provider-rancher2 issue mentioned above.
So, problem 1 is that imported clusters can not be modified as a result of this bug. Even though changing the description (tested as well) and modifying annotations or labels should be allowed. Upstream problem imo, not something we can fix in the crossplane provider.
Problem 2 is the drift detection of labels/annotations which Crossplane does not control. Resetting the timestamp annotation by Crossplane to a previous value is a no go, regardless if this triggers the bug of problem 1. I guess the solution here should be ignoring (LateInitializer.IgnoredFields) all labels and annotations like xxx.cattle.io/yyy. As I don't want to hardcode labels/annotations I just happen to see on my cluster, it should be some sort of regex/wildcard match.

opened #13 for this cluster issue

@sboschman cool, thanks, merging this one in


No MenuItem in Settings

I've installed this pod with xCode 6.3 and iOS 8.2. But something is wrong. I cannot find a menuitem für Acknowledgements in the Setting Screen.
But the Pods-acknowledgements.plist look good.
So is there anything I missed?

I'm not using Xcode 6.3 beta yet. Does it work with 6.2?

Will it help in writing acknowledgment for project?


Blocking public ingestion causes Linux Log Analytics Agent to fail

The documentation should be modified to note that blocking public ingestion on a Log Analytics Workspace will cause the Linux Log Analytics Agent to fail to install if a Private Endpoint and DNS resolution to the Private Endpoint IP address is not configured. This issue does not come up with the Windows agent. The installation fails with the error:
"Enable failed with exit code 5 sec: can't read /etc/opt/microsoft/omsagent/conf/omsadmin.conf..."
This was validated on agent version 1.4.

@mattfeltonma  Could you please post the documentation link you are referring to?

Sorry about that, closing this issue out and re-opening the issue directly linking to the article: https://github.com/MicrosoftDocs/azure-docs/issues/73441


Stack Underflow (Engine Bug) on yields.

Godot version: v3.2.stable.official (Works on v3.1.2.stable)
OS/device including version: Linux/GNU Kubtunu 19.04
Issue description: This bug occurs after a large complex sequence of yields and signals in my group's project.  It may be related to issues #30269 and #31455 since the error message in the editor is "Stack Underflow (Engine Bug)".
The only error in the errors tab is:
E 0:00:34.283   _disconnect: Disconnecting nonexistent signal 'loop_end', slot: 2474:_signal_callback.
<C++ Error>   Condition "!s->slot_map.has(target)" is true.
<C++ Source>  core/object.cpp:1522 @ _disconnect()
 BattleBars.gd:83 @ slide_player_exp_bar()
The confusing thing is that the signal 'loop_end' is not part of BattleBars.gd and we are not disconnecting any signals in our code. Again, this bug is not present in version 3.1.2.
Minimal reproduction project: We have not been able to recreate this bug in a minimal project yet.

Using call_deferred("method") before yield fixes our problem. Closing.

I have the same problem. I couldn't understand what the solution is. Can you provide a short code example with the solution you suggested?

call_deferred(string) is a Godot Object function that calls a specified function during the idle time of the node. It fixed our problem because the function I needed to call is part of a separate node than the one the code is in. The reason why it fixed our problem is that sometimes the node we are trying to call already finished its task and can not be updated in the current frame so call_deferred will make it so that that node on the next frame will then run that specified function.


createPortalLink 500 error: Invalid string: {isTrusted=>"true"}

Bug report
firestore-stripe-subscriptions
Describe the bug
When calling ext-firestore-stripe-subscriptions-createPortalLink the function encounters a 500 error:
Uncaught (in promise) FirebaseError: Invalid string: {:isTrusted=>"true"}
From the functions logs:

Turns out this was because I was trying to access window.location.href in an insecure context (e.g. in an included script file which I guess is blocked for security reasons?) and so instead of passing my returnTo URL to the Firebase Function, it was passing { isTrusted: "true" } for whatever reason. Thankfully Stripe logs saved me many, many hours of debugging here.


Collaboration Sesion Expries within an hour

Issue Type: Bug
Received an error reporting that the collaboration session end and that I should file the issue. This happens exactly an hour after I started the session. I was signed-in via Github.
Extension version: 1.0.2740
VS Code version: Code 1.49.0 (e790b931385d72cf5669fcefc51cdf65990efa5d, 2020-09-10T17:39:53.251Z)
OS version: Darwin x64 19.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2800)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
3, 3, 3

Memory (System)
16.00GB (0.38GB free)

Process Argv
-psn_0_39753191

Screen Reader
no

VM
0%

Possible duplicate of #3859

I just left a comment on the issue you tagged. Closing it for dup, thank you for reporting this.
This is part of an onging sev we're investigating. Please follow #3835 for updates


Redis Error when running the example

Get this error while running the example.
I installed the necessary requirements from the requirements.txt.
Got this error when I clicked on the Start Long Calculations on the Webpage. Any pointers would be appreciated.
D:\flask-celery-example-master>python app.py

Restarting with stat
Debugger is active!
Debugger PIN: 316-263-277
Running on http://<IP_ADDRESS>:5000/ (Press CTRL+C to quit)
<IP_ADDRESS> - - [06/Mar/2019 17:51:06] "GET / HTTP/1.1" 200 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:06] "GET /favicon.ico HTTP/1.1" 404 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:34] "POST / HTTP/1.1" 500 -
Traceback (most recent call last):
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1836, in call
return self.wsgi_app(environ, start_response)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1820, in wsgi_app
response = self.make_response(self.handle_exception(e))
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1403, in handle_exception
reraise(exc_type, exc_value, tb)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask_compat.py", line 33, in reraise
raise value
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1817, in wsgi_app
response = self.full_dispatch_request()
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1477, in full_dispatch_request
rv = self.handle_user_exception(e)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1381, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask_compat.py", line 33, in reraise
raise value
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1475, in full_dispatch_request
rv = self.dispatch_request()
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\flask\app.py", line 1461, in dispatch_request
return self.view_functionsrule.endpoint
File "D:\flask-celery-example-master\app.py", line 75, in index
send_async_email.delay(msg)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\celery\app\task.py", line 453, in delay
return self.apply_async(args, kwargs)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\celery\app\task.py", line 555, in apply_async
**dict(self._get_exec_options(), **options)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\celery\app\base.py", line 353, in send_task
reply_to=reply_to or self.oid, **options
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\celery\app\amqp.py", line 305, in publish_task
**kwargs
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\messaging.py", line 172, in publish
routing_key, mandatory, immediate, exchange, declare)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\connection.py", line 457, in ensured
interval_max)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\connection.py", line 369, in ensure_connection
interval_start, interval_step, interval_max, callback)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\utils_init.py", line 246, in retry_over_time
return fun(*args, **kwargs)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\connection.py", line 237, in connect
return self.connection
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\connection.py", line 741, in connection
self._connection = self._establish_connection()
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\connection.py", line 696, in establish_connection
conn = self.transport.establish_connection()
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\transport\virtual_init.py", line 809, in establish_connection
self.avail_channels.append(self.create_channel(self))
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\transport\virtual_init.py", line 791, in create_channel
channel = self.Channel(connection)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\transport\redis.py", line 456, in init
self._pool.disconnect()
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\redis\connection.py", line 898, in disconnect
connection.disconnect()
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\transport\redis.py", line 819, in disconnect
channel._on_connection_disconnect(self)
File "C:\Users\AppData\Local\Programs\Python\Python36\lib\site-packages\kombu\transport\redis.py", line 476, in _on_connection_disconnect
raise get_redis_ConnectionError()
redis.exceptions.ConnectionError
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "POST /longtask HTTP/1.1" 500 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "GET /?debugger=yes&cmd=resource&f=style.css HTTP/1.1" 200 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "GET /?debugger=yes&cmd=resource&f=jquery.js HTTP/1.1" 200 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "GET /?debugger=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "GET /?debugger=yes&cmd=resource&f=ubuntu.ttf HTTP/1.1" 200 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "GET /?debugger=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
<IP_ADDRESS> - - [06/Mar/2019 17:51:45] "GET /?debugger=yes&cmd=resource&f=console.png HTTP/1.1" 200 -

Are you running a redis service? The error indicates the application cannot connect to it. Redis is an external dependency, you need to install it and run separately.

Ok thanks for the comment I was not aware of it. I installed and ran the redis-server.exe but still after clicking on "Start Long Calculation" I do not see any updates on the page. It is stuck to 0% pending... Also I am not able to send the email when I enter my email id and click on send. Can you guide? TIA

@shashanktupkar did you check the Flask and Celery terminals for errors?

@miguelgrinberg I got it. Before your comment I did not know that I have to run celery also using command "celery -A app.celery worker". I am using Windows and basically have 3 cmd prompts open. Is there a way I can start the redis server and app.celery working in background?
Thanks again @miguelgrinberg
P.S: Sorry I do not have much experience on Web Development or application side software. I am more of a low level software/driver developer.

When you are developing it is normal to open several terminals to run the different components, as you often want to see the output of all of them. You can probably install Redis as a service on Windows, and that will eliminate one of the processes.
If you want to implement a more robust solution that is good for a production system and you need to stay on Windows, then I recommend that you start using the WSL (Windows Subsystem for Linux). Actually I recommend the WSL for development as well.

Thanks for the advice @miguelgrinberg Appreciate it! I am just doing some initials developments on the Windows but will be running it finally on a Linux/Ubuntu system. So if I understood your previous comment properly, in Linux/Ubuntu systems, opening and starting redis and celery service will not be required. Is it right?

Oh no, you will also need to start everything on Linux, but for third party services such as redis most linux distributions provide it as a service that starts automatically. Your own processes will be handled manually during development, and as services in production. I recommended Linux for robustness as a server platform. You'll still need to figure out a way to run your processes in the background if that is what you want to do.

Got you! Again thanks for your help @miguelgrinberg :)


Ellipsis/More Icons, Distorted if stroke > 2

Prerequisites

Version: 7.7.0
Are you running from source/main: Yes
Are you using a released build: Yes
Operating system: MacOS 14.4.1 (23E224)

Step to reproduce
Set the stroke with of any of the more/ellipsis icons > 2 (although most obvious when > 3).
Actual behavior
It looks as though the dots are tiny outlined circles, as oppose to solid dots.
Any message or error
N/A
Additional info or screenshots

Screenshots

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

Oh, strange... When downloaded and imported into Adobe Illustrator, they look totally fine... which made me check their appearance in a different browser and it seems the issue is unique to Arc. - So, can probs close this issue, as don't think it's on Iconoir's end.

Confirming it looks on the Arc's side. Closing it for now 🙌


Subscription message update not being triggered by ActivityMarker().allSeen()

Hi,
Is there a way to be able to be able to receive updates when a user marks all their notifications as seen / read?
I am getting counts to display an indicator via
final counts = await _notificationFeed.getUnreadUnseenCounts()

Then subscribing to the notification feed via
 _feedSubscription =
          await _notificationFeed.subscribe(_handleSubscriptionMessage);

When the user opens their notifications list I run this
final feedActivities = await _notificationFeed
          .getEnrichedActivities<User, dynamic, String, String>(
              limit: _postsPerPage,
              offset: offset,
              marker: ActivityMarker().allSeen().allRead());

However, the subscription is not triggered and so the indicator does not update correctly.
Can you advise how this should be achieved please?
Thanks,
Rich

Wrong thread, sorry


Line break introduced in the middle of cross join

Hi, wanted to lead off by saying how excited we are by this tool. Thanks for your work on it. Now, to the issue at hand.
sqlfmt 0.4.2 formats this query with a line break between "cross" and "join":
select foo.*, bar.*
from {{ ref('foo_foo_foo') }} as foo cross
join {{ ref('bar_bar_bar') }} as bar

I would prefer to have cross join together on the new line, like so:
select foo.*, bar.*
from {{ ref('foo_foo_foo') }} as foo
cross join {{ ref('bar_bar_bar') }} as bar

Feel free to close the issue if this is intended behavior, but I found it surprising and suspect it might be a bug.

Thanks for the report, @rdeese ! I'm excited too 😀
What you're seeing is definitely not the intended behavior. My guess is that we're not parsing that token correctly. Should be an easy fix if that's the case. I'll keep you updated here

Yep, this is easy. Should be fixed in 0.5.0 this week

0.5.0 has been released! Please upgrade for the patch.


PROCESS: Brainstorm RE: visuals integrations with Dev

Verification Conditions:

Set up a meeting with Joshua, Adam, Dan and Dana
Brainstorm some ideas on how to improve the methods by which we provide/implement visuals
Walk away from the meeting with some ideas

Scheduled a meeting on 5/22 for the discussion with Adam, Dan, Dana and Josh

Met and posted notes here:
https://docs.google.com/a/redhat.com/document/d/1KgRujEC5hsVjdip0XZ8RlFiMgHZs1lZqZmj6uPvcwBY/edit?usp=sharing


The home page of official site doesn't explicitly show "Bun" as a branding name

I got a bit confused when I enter https://bun.uptrace.dev/

Should be fixed - thanks for the feedback.


Fixed #35354 -- Simplified ASGIRequest path handling.

Trac ticket number

ticket-35354
Branch description
Following the ASGI HTTP Connection Scope docs0, the provided path is already the correct value that Django requires.
In combination with root_path, from which script_name is derived, the path_info variable is set. It's then redundant to re-calculate path from script_name and path_info.
See also, a clarifying discussion on the ASGIref repo1.
Checklist

[x] This PR targets the main branch.
[x] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[x] I have checked the "Has patch" ticket flag in the Trac system.
[x] I have added or updated relevant tests.
[x] I have added or updated relevant docs, including release notes if applicable.
[x] For UI changes, I have attached screenshots in both light and dark modes.

@sarahboyce

...do you think it would be more correct to update the docs from saying "when SCRIPT_NAME is not /." to "when SCRIPT_NAME is not ""."?

I pushed a second commit for this, that I think is clearer. (In the context of django.setup(set_prefix=True), SCRIPT_NAME isn't, yet, set, at all... 🤔)
Feel free to use/adjust/discard as you like.

I pushed a second commit for this, that I think is clearer. (In the context of django.setup(set_prefix=True), SCRIPT_NAME isn't, yet, set, at all... 🤔)
Feel free to use/adjust/discard as you like.

Thank you I think this is much clearer ⭐


feat(react-tinacms-inline): Custom block actions

This opens a variety of use cases, such as:

Opening a custom screen when a custom action is clicked.
Toggle a boolean field value when clicked.

Original PR by @alexbchr

[ ] Docs

@DirtyF would love help testing this. There is an example on the nesting page of demo-next.

This looks good to me. I updated the blocks controls interface, but we could use a better explanation / example in the docs.

What would be a good sample case for this feature?

There's a sample case on the nesting page of demo-next on the color block

@kendallstrautman the example works fine, but it's a bit light to my taste, I wish we would come with a more realistic example to better convey when this could be useful.
https://www.loom.com/share/c6c1a10357ef4d0c9f97c0ae19bb1072
@alexbchr Why do you need this feature at the moment? Could you share a concrete example?

@alexbchr What for do you need this feature at the moment? Could you share a concrete example?

@DirtyF I didn't have time to implement it yet, but this would be to use as a "toggle" field. For example, I have 3 tabs but only one needs to be selected at all time. Having the selected status as a field on each block is kind of weird, while putting it in a InlineGroup which contains the blocks adds a focus level which complexify usage and is not very intuitive, especially to show only a toggle field.
So ideally, my idea was to toggle this field directly from the BlocksControls, without having to open the fields modal. I think this feature is very useful to toggle between 2 states, like showing an image for a Card component or not. Of course, it should be used sparingly with editor UX in mind.

I see, in this case, it can wait until you have the time to implement a more realistic example and then @spbyrne might weight in on this feature.

To me, I don't mind that it's simple. It's the first iteration of custom block actions. Eventually we will probably create plugins for this.

This looks pretty good!
Do you envision a need to receive the mouse event in the control's onClick? I'm thinking we likely don't, in which case we should explicitly call the passed-in onClick with 0 arguments. Since we're not sure of all the ways this might be used, passing 0 args now makes it simpler to update later (without breaking BC) if we decide there is something useful we could pass into those callbacks.

This looks pretty good!
Do you envision a need to receive the mouse event in the control's onClick? I'm thinking we likely don't, in which case we should explicitly call the passed-in onClick with 0 arguments. Since we're not sure of all the ways this might be used, passing 0 args now makes it simpler to update later (without breaking BC) if we decide there is something useful we could pass into those callbacks.

No I don't need it! I agree with you, it could be removed then to simplify the code. Also I don't think of any use-case needing it.


refactor(storage): use dynamic trait for storage interfaces

Signed-off-by: Runji Wang<EMAIL_ADDRESS>Dynamic async traits are not so bad for performance, as long as they are not called frequently. The advantage is that they are less invasive as they do not require generic parameters everywhere, and they allow for extensible plugins in the future.
This PR uses #[async_trait] to refactor storage traits into dyn traits. It removes <S: Storage> from executors. The only performance critical part is the TxnIterator::next_batch which is called frequently in scanning. We refactor it into a BoxStream to eliminate boxing the future on each call.

Performance comparison on TPCH

tpch
time

q1
+5.9%

q17
+5.6%

q18
+5.4%

q13
+4.1%

q11
+3.9%

q14
+3.9%

q7
+3.7%

q4
+3.2%

q3
+3.1%

q10
+2.2%

q9
+1.8%

q5
+1.4%

q15
+1.2%

q16
+1.2%

q19
+1.2%

q6
+0.4%

q12
-0.4%

q20
-0.6%

q22
-2.5%

q2
-2.9%

q8
-2.9%

q21
-5.4%

Weakly -1
The current dynamic traits have too many limitations, making them seem like unfinished products.

also objected by @mrcroxx

also objected by @MrCroxx

The #[async_trait] allocates a boxed future on each call. The overhead can be high for memory-only path. e.g. cache hits.

Given that the storage part of the system runs in batches (i.e., we always fetch as many as 1024 rows if possible), I don't think using a dynamic trait would cause a large regression. However, I don't see the code is simplified significantly without static dispatch, except that the S: Storage thing gets removed. Therefore, I'm kind of in the middle of approving or turning down this pull request :(


Fix length validating stream

Fix case where there's single byte read.

API change check for com.azure:azure-core
API changes have been detected in com.azure:azure-core. You can review API changes here


Rebases your branch to squash out open source template commits

This will also reflect in https://github.com/cfpb/grasshopper-ui/pull/10

Hmm, well looks like I was plum incorrect.
The commits were just replayed on top of what you already had, which I suppose I could have suspected.

I'll devise a (non-terrible) solution and hit you with another PR; sorry for the mixup!

Urgh. Dunno if I can make a PR that would fix this.
I think to make this right you'll have to do the following on your fork (I'm assuming your remote is named origin):
git checkout gh-pages
git checkout -b pages-backup
git branch -d gh-pages
git remote add wyatt https://github.com/wpears/grasshopper-ui.git
git fetch wyatt
git checkout -b gh-pages wyatt/andrew-rebase
git push -uf origin
This will rewrite your gh-pages branch to be just the squashed template commits and your changes played on top of them.


Make alerts stateless

Alerting rules should always be evaluated as a range query over the entire hold duration so pending alerts are not lost on restart.

:+1:

This is a dupe of #422 .
I think we'll need something more nuanced to cover both the time when the prometheus server is down (we don't want an alert before 2 scrapes have been done so we have our bearings), and that doing the query historically may not have exactly the same results as doing it at each point in time.

Also, doing the query always over the entire FOR range gets prohibitively expensive for some alert expressions, so the state needs to be kept separately for alerting rules.

That's something I strongly doubt without measurements indicating otherwise.
Our evaluation interval typically is 60s, alerts are on average FOR 10m.
This increases my computation by 10x. Chunk preloading is not affected in
most cases as a single sample of samples over 10m are in the same chunk.
As alerting rule evaluation has never been anything but white noise so far,
the increase is most likely completely negligible.
If on the other hand, it would be an issue. This would be a clear sign to
me that we have to work on our completely naiive query evaluation, which
can most likely be an order of magnitude more efficient.
On Mon, Sep 28, 2015 at 12:54 PM Julius Volz<EMAIL_ADDRESS>wrote:

Also, doing the query always over the entire FOR range gets prohibitively
expensive for some alert expressions, so the state needs to be kept
separately for alerting rules.
—
Reply to this email directly or view it on GitHub
https://github.com/prometheus/prometheus/issues/1117#issuecomment-143710147
.

As FOR durations are not technically limited, some people will have FOR durations of multiple hours, or in pathological cases even days (although the latter would usually be a bad idea in any case). This will definitely have a big impact on rule evaluations. Of course optimizing general expression evaluation is always a good idea, but I don't see that legitimizing making alert evaluations potentially 100x or more expensive than they are now.

I'm expecting to see for expressions up to a month in length in common usage, so I agree with Julius that I don't see this approach working out.

At which evaluating at 1m intervals would be a highly questionable approach.
On Mon, Sep 28, 2015 at 1:14 PM Brian Brazil<EMAIL_ADDRESS>wrote:

I'm expecting to see for expressions up to a month in length in common
usage, so I agree with Julius that I don't see this approach working out.
—
Reply to this email directly or view it on GitHub
https://github.com/prometheus/prometheus/issues/1117#issuecomment-143714887
.

Even if you increase the interval by a bit, that'll be very confusing to a user, why suddenly FOR doesn't work at their defined rule evaluation interval anymore, and also it would still kill the storage because it'd load a huge amount of history. We should keep the FOR state separately.

Also, most rules should be able to be answered from memory alone. Once we need to go to disk, we are already dead for many of them (you can already see that after some beefy servers start up - they take a while to function properly after restart because the rules load so much from disk).

So, the original reason we thought about doing it this way was to get sensible evaluation of FOR over restarts / reloads, without having to introduce yet another bit of storage that needs to be updated and cared for.
We don't need to make the evaluation "really" stateless – but what about using the timeseries data if the rule hasn't been evaluated since a restart / reload, but cache the result of that (the time when it started firing) in memory?

We don't need to make the evaluation "really" stateless – what about using the timeseries data if the rule hasn't been evaluated since a restart / reload, but cache the result of that (the time when it started firing) in memory?

Such as via ALERTS? It needs a little bit more than that (we need the time it started firing and to add a bit more time for 'for' expressions on the lower end), but the general approach sounds good.

We run batch jobs weekly or monthly, so my for time goes back that far.
Without some sort of method for determining the date or day of the week, I
have to go back a week to ensure we get results each week. This may just be
a poor architecture, but it is working well currently.
On Sep 28, 2015 6:33 AM, "Brian Brazil"<EMAIL_ADDRESS>wrote:

We don't need to make the evaluation "really" stateless – what about using
the timeseries data if the rule hasn't been evaluated since a restart /
reload, but cache the result of that (the time when it started firing) in
memory?
Such as via ALERTS? It needs a little bit more than that (we need the
time it started firing and to add a bit more time for 'for' expressions on
the lower end), but the general approach sounds good.
—
Reply to this email directly or view it on GitHub
https://github.com/prometheus/prometheus/issues/1117#issuecomment-143718519
.

@brian-brazil why I write for 1s but the pending to firing use time more than 1s ?

@jinhang Because alerts need at least one rule evaluation cycle to go from pending to firing. I would guess that your rule evaluation cycle is much longer. You can just omit FOR to go directly into firing mode. This question is not related to this issue though.


Codepilot leads to xcodebuild corruption

I found my make command does not work and printed
sh: line 1:  609 Abort trap: 6           /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk / -find make 2> /dev/null
git: error: unable to find utility "make", not a developer tool or in PATH

Then, I checked xcodebuild and it printed
2015-03-03 12:36:42.233 xcodebuild[1300:1007] CPCodePilotPlugin.m:23 +[CPCodePilotPlugin load]; CODE PILOT: CURRENT_XCODE_VERSION: 0 CURRENT_XCODE_REVISION: 0
** INTERNAL ERROR: Uncaught exception **
Exception: Error (1000) creating CGSWindow

Finally, I removed CodePilot and then everything is fine.

+1

+1, after install codepilot, I cannot install other plugins through Alcatraz.
Ideas as to how to circumvent this? Even removing CodePilot from the Plug-ins folder doesn't fix this…

OK; this is HORRIBLE.
Can't open Alcatraz because it says I need to have Developer Tools installed; which I have.
I can't properly "uninstall" CodePilot.
So pretty much everything stopped working for me… and I'm seeing a lack of response on this issue which is starting to make me REALLY worried about this not being a fix that will come soon enough…

NVM; Alcatraz issue was related to something else

I'm kinda bored atm so I took a look at it.
The 'correct' solution would be to make sure the plugin is only initialised when running "real" Xcode, not when xcodebuild is called, but I'm not actually sure if that's possible.
If it's not, the crash is caused because in CPCodePilotPlugin.m#L39, the CPCodePilotWindowDelegate is instantiated, which in L31 creates a new window, which obviously crashes.
My guess is that lazy-instantiating the WindowDelgate would make the problem make away, but I'm that bored to actually go ahead and try it.

yeah; on #18 I offered to help with the project because it seems kind of "forgotten" and this leads me to believe that the contributors (not complaining about your job here guys) maybe don't have the time to work as much as this project requires.
I'll try to dig into this later today and will try to send a PR with hopefully a solution for this; in the meantime I had to remove CodePilot from my Plug-ins folder and from here:
~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/

@esttorhe nice

+1

+1

+1

Hey guys, this problem should no longer appear ( as of #46 ). Let us know if you still have the issue.


Upgrade to GHC 9.0

This was easier than I expected. Commit 1e65b2f2b31768e90978e0385377e6753b711059 is the only one specifically required to support GHC 9.0.

👉 #4

👉 #4


Error: NativeModule: RNTextInputMask is null.

Pod is null
Error: NativeModule: RNTextInputMask is null.
To fix this issue try these steps:
• Rebuild and restart the app.
• Run the packager with --clearCache flag.
• If happening on iOS, run pod install in the ios directory and then rebuild and re-run the app.
• If this happens while testing with Jest, make sure to follow instructions in https://github.com/react-native-text-input-mask/react-native-text-input-mask#testing
, js engine: hermes

I am using an expo managed workflow and get the same error. It looks like react-native-text-input-mask installed succesfully, but then the above error surfaces.
The above troubleshooting steps did not resolve, and neither did expo start --clear.
has anyone found a solution?