[BUG] get file size not right

System info

Playwright Version: 1.25.0/1.31.0
Operating System: Windows 10
Browser: chrome:110.0.5481.178
jdk: 1.8.0_251

Source code

I provided exact source code that allows reproducing the issue locally.

source file
public static void main(String[] args) throws Exception {
        BrowserType.LaunchOptions launchOptions = new BrowserType.LaunchOptions();
        launchOptions.setExecutablePath(new File("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe").toPath());
        launchOptions.setSlowMo(3000);
        launchOptions.setHeadless(false);
        launchOptions.setDevtools(true);
        Playwright.CreateOptions createOptions = new Playwright.CreateOptions();
        Map<String, String> map = new HashMap<>();
        map.put("PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD", "1");
        createOptions.setEnv(map);
        try (Playwright playwright = Playwright.create(createOptions);
             Browser launch = playwright.chromium().launch(launchOptions)) {
            BrowserContext browserContext = launch.newContext();
            Page page = browserContext.newPage();
            page.onRequest((request) -> {
                try {
                    Response response = request.response();
                    if (response != null) {
                        if (response.body() != null) {
                            String contentType = Optional.ofNullable(response.headers().get("content-type")).orElse("");
                            if (Stream.of("audio", "video").anyMatch(e -> contentType.toLowerCase().contains(e))) {
                                try {
                                    FileUtils.writeByteArrayToFile(new File(new Random().nextInt()+".m4a"), response.body());
                                    String range = response.headers().get("range");
                                    System.out.println("  ->range=" + range);
                                } catch (IOException e) {
                                    throw new RuntimeException(e);
                                }
                            }
                        }
                    }
                } catch (PlaywrightException e) {
                    e.printStackTrace();
                }
            });
            page.navigate("https://music.163.com/#/song?id=1984434609");
            Frame contentFrame = page.frame("contentFrame");
            contentFrame.click("//*[@id=\"content-operation\"]/a[1]");
            Thread.sleep(500000);
    }}

Steps

Run the main method

I want to use playwright to get 163 music audio files, but when the browser loads the page and clicks to play, the audio file size is 2.43 MB, but the downloaded file is 4.09MB. This is likely to be a problem with the "range" in the request header. But chrome's devTools doesn't seem to have this problem
Expected
download file is  4.09 MB
Actual
download file is  2.43 MB

I see a bunch of errors in the console and no files written:
com.microsoft.playwright.PlaywrightException: Error {
  message='Protocol error (Network.getResponseBody): No data found for resource with given identifier
  name='Error
  stack='Error: Protocol error (Network.getResponseBody): No data found for resource with given identifier

when looking at the network panel in devtools I see the same error for the .m4a resource:

looks like a problem with network instrumentation in chromium.

System info

firefox(Nightly):103.0 (64-bit)
chrome(Chromium)：105.0.5195.19

When I look in devTools, when the audio is fetched for the first time, the browser cancels the request, so he has no response body. No problem the second time around.
When I use chrome he returns the wrong audio file size, but when I use firefox he seems to have no problem.
Does the principle of playwright-java call Chrome DevTools Protocol internally?
public static void main(String[] args) throws Exception {
        BrowserType.LaunchOptions launchOptions = new BrowserType.LaunchOptions();
        launchOptions.setSlowMo(3000);
        launchOptions.setHeadless(false);
        launchOptions.setDevtools(true);
        Playwright.CreateOptions createOptions = new Playwright.CreateOptions();
        try (Playwright playwright = Playwright.create(createOptions);
             Browser launch = playwright.firefox().launch(launchOptions)) {
            BrowserContext browserContext = launch.newContext();
            Page page = browserContext.newPage();
            page.onRequest((request) -> {
                try {
                    Response response = request.response();
                    if (response != null) {
                        if (response.body() != null) {
                            String contentType = Optional.ofNullable(response.headers().get("content-type")).orElse("");
                            if (Stream.of("audio", "video").anyMatch(e -> contentType.toLowerCase().contains(e))) {
                                try {
                                    FileUtils.writeByteArrayToFile(new File(new Random().nextInt()+".m4a"), response.body());
                                    String range = response.headers().get("range");
                                    System.out.println("  ->range=" + range);
                                } catch (IOException e) {
                                    throw new RuntimeException(e);
                                }
                            }
                        }
                    }
                } catch (PlaywrightException e) {
                    e.printStackTrace();
                }
            });
            page.navigate("https://music.163.com/#/song?id=1984434609");
            Frame contentFrame = page.frame("contentFrame");
            contentFrame.click("//*[@id=\"content-operation\"]/a[1]");
            Thread.sleep(500000);
        }}

The download behavior is implemented differently in different browsers. Playwright does use CDP internally. Are you seeing the same errors as I mentioned above? Would be nice if you could reduce it to a self-contained example which wouldn't depend on third-party pages and let us reproduce it reliably.

The problem I found is the same as yours, which is that the response shu'jv cannot be loaded. So far I've only found this issue on 'music.163.com'.
Should I close this issue?


Support for several services under one provider and several providers

In my project I have several services from one provider, so the below is proposed structure.
It will be good, if generator will support it.
/src/Services/Provider1

AdGroups (own wsdl)
ArrayType
EnumType
ServiceType
StructType
Campaigns (own wsdl)
ArrayType
EnumType
ServiceType
StructType

/src/Services/Provider2

AdGroups (own wsdl)
ArrayType
EnumType
ServiceType
StructType
Campaigns (own wsdl)
ArrayType
EnumType
ServiceType
StructType

Currently you are able to have such a hierarchy if each provider's service has its own WSDL (/src/Services/Provider1/ and /src/Services/Provider2/ are your existing main directory), am I wrong?

/src/Services/

Provider1/

AdGroups/ (own wsdl)

src/

ArrayType/
EnumType/
ServiceType/
StructType/
composer.json

Campaigns/ (own wsdl)

src/

ArrayType/
EnumType/
ServiceType/
StructType/
composer.json

Provider2/

AdGroups/ (own wsdl)

src/

ArrayType/
EnumType/
ServiceType/
StructType/
composer.json

Campaigns/ (own wsdl)

src/

ArrayType/
EnumType/
ServiceType/
StructType/
composer.json

So I don't see what you would like to do actually, could you precise more please?

Yes, the proper structure of folders can be generated.
First, you need to setup --namespace="Provider1\Campaigns"
Second, you need to update the composer.json of your project with proper paths
    "autoload": {
        "psr-4": {
          "Provider1\\Campaigns\\": "./Provider1/AdGroups/src/",
          "Provider1\\Campaigns\\": "./Provider1/Campaigns/src/",
          "Provider2\\Campaigns\\": "./Provider2/AdGroups/src/",
          "Provider2\\Campaigns\\": "./Provider2/Campaigns/src/",
        }
     }

Third, you need to run composer dump-autoload to update autoloader.
This issue can be closed, and I suggest to add this info to manual.

I think it's more about FAQ, don't you think ?
Plus, I think the readme is already long enough.

Agree absolutly.

Done : https://github.com/WsdlToPhp/PackageGenerator/wiki/FAQ#how-to-have-several-packages-under-the-same-directory-and-common-namespaces. You tell me if you think this is not clear


Thanks for the pull request. I will have a look at this: but I have noticed that it doesn't quit before, so looks like a good patch.
However

At the moment I'm not keen on removing the dependency from package.json. I'm more pro bumping the version to be able to use https://github.com/nwjs/npm-installer/ , which at the moment accepts a parameter in .npmrc to set a custom download location. Slightly awkward as it then needs a http server running I think, but I wonder if this could be changed in a future version. Essentially I think this launcher should just work without having to install nodewebkit separately, and if someone wants to optimize the install process by pre-loading the binary somewhere, that should be optional.
In any case, this should be in a separate pull request, so can be discussed separately.

I think the comment is far too verbose. Something like "Kill child processes created by NodeWebkit Chromedriver" I think is enough.

Thanks.

I confirm the issue on the last version of karma-nodewebkit-launcher (0.0.11). I also confirm that this PR correctly kills the node-webkit subprocesses.
However, I am wondering if a kill -9 all isn't a too brutal solution...

@mackwic and @iamdenny I'm still not able to reproduce the issue. Can you post

How you're determining the child subprocesses aren't exiting? (Is it just that karma doesn't exit, or something else?
Version of Karma, and OS

Thanks.

I tested it on MacOS. and the Karma version is 0.12.31
here is my karma.config.js
if (!process.env.NODEWEBKIT_BIN) {
    process.env.NODEWEBKIT_BIN = getNodewebkitPath();
}

module.exports = function(config) {
	config.set({

		// base path that will be used to resolve all patterns (eg. files, exclude)
		basePath: './',

		// frameworks to use
		// available frameworks: https://npmjs.org/browse/keyword/karma-adapter
		frameworks: ['mocha'],

		// list of files / patterns to load in the browser
		files: [
			'......',
			'test/**/*.js',
                         {pattern: 'test/**/*.png', watched: false, included: false, served: true},
		],

		// list of files to exclude
		exclude: [

		],

		// preprocess matching files before serving them to the browser
		// available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
		preprocessors: {
            'js/**/*.js': ['coverage']
		},

		// test results reporter to use
		// possible values: 'dots', 'progress'
		// available reporters: https://npmjs.org/browse/keyword/karma-reporter
		reporters: ['spec', 'coverage'],

        // coverage
        coverageReporter: {
            dir: '../coverage/studio/',
            reporters: [
                { type: 'html', subdir: 'report-html' },
                { type: 'text', subdir: '.', file: 'text.txt' },
                { type: 'text-summary',  subdir: '.', file: false}
            ],
            watermarks: {
                statements: [ 50, 75 ],
                functions: [ 50, 75 ],
                branches: [ 50, 75 ],
                lines: [ 50, 75 ]
            }
        },

		// web server port
		port: 9876,

		// enable / disable colors in the output (reporters and logs)
		colors: true,

		// level of logging
		// possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
		logLevel: config.LOG_INFO,

		// enable / disable watching file and executing tests whenever any file changes
		autoWatch: false,

		// start these browsers
		// available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
		browsers: ['nodewebkit'],

		customLaunchers: {
			'nodewebkit': {
				base: 'NodeWebkit',
				options: {
					"version": "test",
					"window": {
                        "show": false
					}
				}
			}
		},

		// Continuous Integration mode
		// if true, Karma captures browsers, runs the tests and exits
		singleRun: true
	});
};

/**
 * get nodewebkit path
 * @returns {String}
 */
function getNodewebkitPath () {
    var path;
    var which = require('which').sync;

    try {
        path = which('nodewebkit');
    } catch (e) {}
    if (!path) {
        try {
            path = which('nw');
        } catch (e) {}
    }

    return path;
}

The PR Code is only for linux and mac, not for window. so It need to be checked the OS before killing sub process.

@iamdenny Does the issue still occur if you don't set process.env.NODEWEBKIT_BIN, and just use the default path the launcher uses?

How you're determining the child subprocesses aren't exiting? (Is it just that karma doesn't exit, or something else?

The window is still here, even if karma has closed in the shell. Also, circle-ci build doesn't finished when it should (that's how I found the issue).

Your Karma config

here, note that I also use the NODEWEBKIT_BIN environment variable, it's part of our build matrix (yeah yeah... native plugins and cross platform makes a very special kind of hell).
I will test with the default path.

version of karma and OS

default Ubuntu of circle-ci (12.04) + osx 10.9, only seen on karma 0.0.11

@michalc
if (!process.env.NODEWEBKIT_BIN) {
    process.env.NODEWEBKIT_BIN = getNodewebkitPath();
}

This code is for multi OS. our team has linux, mac, window OS. and we install nodewebkit as global.
so using getNodewebkitPath() is good for us.
Anyhow you don't have child process of chrome after karma test?

Closing due to inactivity (on my part perhaps). Feel free to submit a new PR if desired.


Updating operator-sdk from go1.15 to go 1.16

Updating operator-SDK from go1.15 to go 1.16
https://github.com/operator-framework/operator-sdk/issues/4828
Signed-off-by: sujil02<EMAIL_ADDRESS>
Description of the change:
Motivation for the change:
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

@sujil02 looks like you need to add a go mod tidy to the testdata generator.

Looks like ubi:8.3 does not support go1.16 yet. You'll have to download and install it from the golang DL page with curl: https://golang.org/dl/


[ FR ] Mobile Support

Would you consider making the plugin available for mobile as well?
Translating on the go would be a huge win!
Thank you for looking into it.

Excellent and thank you!


How can I download the dataset ?

Dear Sir,
Thank you very much for your sharing code. I want to try your code. However, I cannot download dataset. When I downloaded, it go through the baidu. I try to register but not successfully. Therefore, is there any alternative link for download ? Thank you very much sir.

Hi, I have uploaded the dataset to the google cloud, you can download it from the following link:
https://drive.google.com/drive/folders/1gIMun9bM5JDrs98sLjXt7XoFCdvy1DXF?usp=sharing

Thank you very much sir. I really appreciate your kindness.


Updating mbed-os to mbed-os-5.6.6

Please test this PR
If successful then merge, otherwise provide a known issue.
Once you get notification of the release being made public then tag Master with mbed-os-5.6.6 .

/morph uvisor-test


Burrow which uses Sarama internally fails to start with Kafka Version 2.8.x

Hi team,
I am using Burrow version 1.40.0 which uses Sarama version 1.30.0 as per the release notes. I am seeing an issue where burrow task is failing to start with Kafka version 2.8.1 as it is unable to start consumer for topic __consumer_offsets.
Log snippet:
{"level":"debug","ts":1642109643.8627968,"msg":"Successfully initialized new client","name":"sarama"}

{"level":"debug","ts":1642109643.862842,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642109643.8712587,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"debug","ts":1642109643.8713126,"msg":"client/metadata retrying after 250ms... (3 attempts remaining)","name":"sarama"}

{"level":"info","ts":1642109643.9436781,"msg":"starting evaluations","type":"coordinator","name":"notifier"}

{"level":"debug","ts":1642109644.1217878,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642109644.1244755,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"debug","ts":1642109644.1245284,"msg":"client/metadata retrying after 250ms... (2 attempts remaining)","name":"sarama"}

{"level":"debug","ts":1642109644.3755918,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642109644.3778868,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"debug","ts":1642109644.377944,"msg":"client/metadata retrying after 250ms... (1 attempts remaining)","name":"sarama"}

{"level":"debug","ts":1642109644.6290717,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642109644.6317284,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"error","ts":1642109644.6317704,"msg":"failed to get partition count","type":"module","coordinator":"consumer","class":"kafka","name":"local-kafka","topic":"__consumer_offsets","error":"kafka server: Request was for a topic or partition that does not exist on this broker."}

{"level":"debug","ts":1642109644.631847,"msg":"Closing Client","name":"sarama"}

{"level":"error","ts":1642109644.6318607,"msg":"failed to start consumer","type":"module","coordinator":"consumer","class":"kafka","name":"local-kafka","error":"kafka server: Request was for a topic or partition that does not exist on this broker."}

{"level":"debug","ts":1642109644.6318827,"msg":"Close() called on already closed client","name":"sarama"}

{"level":"info","ts":1642109644.631897,"msg":"stopping","type":"coordinator","name":"cluster"}

Same version of Burrow works fine with Kafka version 2.7:
{"level":"debug","ts":1642108786.214034,"msg":"client/brokers registered new broker #0 at uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642108786.2141097,"msg":"Successfully initialized new client","name":"sarama"}

{"level":"debug","ts":1642108786.214155,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642108786.2637825,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"debug","ts":1642108786.2638936,"msg":"client/metadata retrying after 250ms... (3 attempts remaining)","name":"sarama"}

{"level":"info","ts":1642108786.2936275,"msg":"starting evaluations","type":"coordinator","name":"notifier"}

{"level":"debug","ts":1642108786.5140655,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642108786.5219843,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"debug","ts":1642108786.522035,"msg":"client/metadata retrying after 250ms... (2 attempts remaining)","name":"sarama"}

{"level":"debug","ts":1642108786.7730803,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"debug","ts":1642108786.782377,"msg":"client/metadata found some partitions to be leaderless","name":"sarama"}

{"level":"debug","ts":1642108786.7824466,"msg":"client/metadata retrying after 250ms... (1 attempts remaining)","name":"sarama"}

{"level":"debug","ts":1642108787.0329359,"msg":"client/metadata fetching metadata for [__consumer_offsets] from broker uem-kafka:9092","name":"sarama"}

{"level":"info","ts":1642108787.0380993,"msg":"starting consumers","type":"module","coordinator":"consumer","class":"kafka","name":"local-kafka","topic":"__consumer_offsets","count":50}

I have created a ticket for Burrow team as well but did not get any response so reaching out here to see if there is any suggest on how to troubleshoot this further.
https://github.com/linkedin/Burrow/issues/737

Hmm, having investigated this some more it seems like a change in behaviour on the broker in 2.8.x onward means that __consumer_offsets is not getting created by a MetadataRequest alone and it's only a JoinGroup from a consumer group that causes it to spring into life

Kafka dev mailing list agree this is a regression in the broker.
https://lists.apache.org/thread/cxzq6009t2vsyc05tcro77mov12zhpvm
Raised upstream as https://issues.apache.org/jira/browse/KAFKA-13612


Initial table implementation

📌 User Story
This user story covers the creation of the nimble-table component, and any other components needed to render a set of data as outlined in the data API HLD (spec reference coming).
Accessibility
This basic table should have appropriate aria labels to meet accessibility standards
This version of the table will use the table role
https://w3c.github.io/aria-practices/examples/table/table.html
https://w3c.github.io/aria-practices/#table
Design
This table should implement the basic visual design:

#883

Platform support
The basic table should have versions available for Angular and Blazor
Other functionality
If the data of the table updates, the table should update

This behavior allows existing workflows of filtering and searching to work.

Related PRs

#902
#914
#921
#928
#931
#932
#945
#969

@RickA-NI, can you verify that the table implementation matches the visual design spec?
You can see an example of the table at: https://nimble.ni.dev/storybook/?path=/story/table--table
@mollykreis, do we need to validate the Angular and Blazor (when ready) implementations as well or is the code shared enough that they will be identical?

do we need to validate the Angular and Blazor (when ready) implementations as well or is the code shared enough that they will be identical?

@nate-ni, there is no need to validate the styling in Angular and Blazor. All the styling is shared.

The Light skin and Dark skin look correct the something is off on the color skin the lighter background color for the rows and headers is not showing up all I'm seeing is text on the dark green.

@RickA-NI, we were unsure the correct way to style the Color theme. We were confused because the dividers between the rows was speced to be ForestGreen@75% while the rows themselves are ForestGreen@100%. This means that the dividers are only visible on some backgrounds. Could you clarify what color the dividers should be on the Color theme? ForestGreen@75% layered on top of some other color (that at least I couldn't find in the XD document)?
If the answer isn't straight forward, we can follow up in person.

@mollykreis looks like that was due to poor design on my part. I've updated the color page of the spec to match how the other color controls are styled. It should work properly now. If there's questions let me know.

#969 resolves the open items to get this issue resolved.


Cannot compile on Linux Debian

After generating config through "ccmake ."
Can you try not to build the library in the source folder? I mean, could you try to first create a 'reactphysics3d-build' directory, and then build the library inside it with the following commands instead?
mkdir reactphysics3d-build
cd reactphysics3d-build
ccmake <path-to-reactphysics3d-source-folder>

Let me know if you still have an error.

Have you been able resolve your issue?

Hello. Unfortunately no. The output was as below
$ reactphysics3d/reactphysics3d-build$ ccmake ../src/

 CMake Error: The source directory "reactphysics3d/src" does not appear to contain CMakeLists.txt.
 Specify --help for usage, or press the help button on the CMake GUI.

As described in the documentation here, you need to use the reactphysics3d/ folder you have cloned with the 'ccmake' command, not the src/ folder.
Moreover, you should not have a ../src folder in the parent directory of reactphysics3d-buid.
Here are all the commands you need to use:
git clone git@github.com:DanielChappuis/reactphysics3d.git
mkdir reactphysics3d-build
cd reactphysics3d-build
ccmake ../reactphysics3d

Have you been able to build the library?


accessibility pass

should be able to keyboard navigate any interactive elements
anything relying on color (like city's climate category) should be available in alt/aria tags

see guidelines here:
https://www.notion.so/thepudding/Accessibility-Checklist-4cf13cb408454d9984e8c5fe88c518e2


Support /v2/api/delete in 1.X

PR: 23247
This implements a /v2/api/delete endpoint that supports a subset of the V2 delete functionality

This will permit common code to run against V1 and V2.

Relevant URLs

https://docs.influxdata.com/influxdb/v2.1/reference/syntax/delete-predicate
https://docs.influxdata.com/influxdb/cloud/api/#tag/Delete
https://docs.influxdata.com/influxdb/cloud/reference/syntax/delete-predicate/

This should include an example similar to the current v2 endpoints in Enterprise docs.

see this example:
https://docs.influxdata.com/influxdb/cloud/write-data/delete-data/#delete-data-using-the-api

Replace 2.0 with 2.x here where applicable:
https://docs.influxdata.com/enterprise_influxdb/v1.10/tools/api/


fix(scheduler): deis run could never reach the failed state

The way I reproduced it was running a command that does not exist on the pod but instead of getting a failure it would try for 30 seconds and then fail with a "timeout" message

Now I get this output after the change:
 deis run -a excess-ziggurat env
Running 'env'...
{"kind":"Pod","apiVersion":"v1","metadata":{"name":"excess-ziggurat-v6-run-nph2t","namespace":"excess-ziggurat","selfLink":"/api/v1/namespaces/excess-ziggurat/pods/excess-ziggurat-v6-run-nph2t","uid":"5a89e595-f795-11e5-9572-080027969e8a","resourceVersion":"19614","creationTimestamp":"2016-03-31T23:07:34Z"},"spec":{"volumes":[{"name":"default-token-vu38v","secret":{"secretName":"default-token-vu38v"}}],"containers":[{"name":"excess-ziggurat-v6-run-nph2t","image":"<IP_ADDRESS>:80/excess-ziggurat:v6","command":["/bin/bash"],"args":["-c","env"],"env":[{"name":"Helgi_Hi","value":"Foo"},{"name":"Helgi","value":"Foo"}],"resources":{},"volumeMounts":[{"name":"default-token-vu38v","readOnly":true,"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount"}],"terminationMessagePath":"/dev/termination-log","imagePullPolicy":"IfNotPresent"}],"restartPolicy":"Never","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","serviceAccountName":"default","serviceAccount":"default","nodeName":"<IP_ADDRESS>","securityContext":{}},"status":{"phase":"Failed","conditions":[{"type":"Ready","status":"False","lastProbeTime":null,"lastTransitionTime":"2016-03-31T23:07:34Z","reason":"ContainersNotReady","message":"containers with unready status: [excess-ziggurat-v6-run-nph2t]"}],"hostIP":"<IP_ADDRESS>","podIP":"<IP_ADDRESS>","startTime":"2016-03-31T23:07:34Z","containerStatuses":[{"name":"excess-ziggurat-v6-run-nph2t","state":{"terminated":{"exitCode":-1,"reason":"ContainerCannotRun","message":"[8] System error: exec: \"/bin/bash\": stat /bin/bash: no such file or directory","startedAt":"2016-03-31T23:07:34Z","finishedAt":"2016-03-31T23:07:34Z","containerID":"docker://0c376a24132ecd0c5fc6f1bbf1e2d4476982ba831855e3318becf4d1d4ac6440"}},"lastState":{},"ready":false,"restartCount":0,"image":"<IP_ADDRESS>:80/excess-ziggurat:v6","imageID":"docker://6a1c6b797413cc9fabf2d88541844445ea12e7b08f6ceaf19c21d9b8ada6cf22","containerID":"docker://0c376a24132ecd0c5fc6f1bbf1e2d4476982ba831855e3318becf4d1d4ac6440"}]}}

Current coverage is 83.34%

Merging #589 into master will not affect coverage as of 61d0a7e

@@            master    #589   diff @@
======================================
  Files           36      36
  Stmts         2384    2384
  Branches       347     347
  Methods          0       0
======================================
  Hit           1987    1987
+ Partial        117     116     -1
- Missed         280     281     +1

Review entire Coverage Diff as of 61d0a7e

Powered by Codecov. Updated on successful CI builds.


packetblaster synth: Generate synthesized packets

Tests are missing, but it works as it should.
Hope you're happy now, @lukego!

Great feature!
Often we have wanted to test with a different packet size, or specific mixes of packet sizes (e.g. to have variation but maintain a definite average size), and it is really primitive to do this by creating new pcap files all the time. Much better to be able to do it on the command line with a series of packet sizes.
The Synth selftest method looks like it may depend on the app outputting exactly the same number of packets when executed for a very short time period? That seems like it could break in one of two ways: first that we could change the size of struct link so that it would output a different number of packets per breath, and second that the engine might run the app for multiple breaths. Can we make this more robust somehow? (Just to avoid confusing the next person who changes the size of a link or the engine event loop behavior and sees this test start failing.)

@lukego Yeah we are aware of this, but didn't come up with an elegant solution yet, I think the Match app from #708 could solve this.

@lukego What do you think, is the flaky Synth:selftest a deal breaker? If not I would merge this into max-next and fix the selftest when Match is ready.

Is synth envisaged to be a general purpose packet crafter?
So far I've been using scapy to generate pcaps on the fly and /dev/stdout and /dev/stdin as hacks to run it as a single command. That is then combined with PcapReader and Repeater
'wrpcap("/dev/stdout", [ Ether()/Dot1Q(vlan=x)/IP(src="<IP_ADDRESS>")/UDP(sport=10)/Raw(open("/dev/urandom","rb").read(10)) for x in range(5,70) ])' | scapy | snabb snsh vlan.lua

lib.protocol doesn't really have the brevity of scapy.
Would you see synth eventually replacing this use case?
If it doesn't what's the line of reasoning to not include this in Source?
Is the use case for synth particularly wide spread as it currently stands?
Does having Match join Synth under test make sense?
Match doesn't help where tests haven't run for long enough but would help where more than 1 breath is taken.

Is synth envisaged to be a general purpose packet crafter?
Would you see synth eventually replacing this [scapy] use case?

Synth was born mainly with this PR in mind, e.g. to support a synthesizing packetblaster. It could certainly be extended, or replaced by a more sophisticated app for that matter.

If it doesn't what's the line of reasoning to not include this in Source?

Synth is Ethernet aware so I felt it was too specific for basic_apps.

Is the use case for synth particularly wide spread as it currently stands?

I don't think so / I don't know.

Does having Match join Synth under test make sense?

I thought the same thing. I think so, yes.

Match doesn't help where tests haven't run for long enough but would help where more than 1 breath is taken.

Why is that? That seems like an arbitrary limitation. I imagined this would be a perfect case for “fuzzy” matching, e.g. ensure at least one packet of each specified size is sent.

@eugeneia I would prefer to see max-next passing tests so that I can merge the changes that are already there. I'm not sure what the optimal workflow is for releases but I feel like I should be merging max-next onto next at least once per week or so. Then we would be using next as a place to land changes as quickly as they can be reviewed by a subsystem maintainer and also by me and other people could test them there.

@eugeneia oh it is passing :-) Cool! I merged max-next into next now. Sure, merging this onto max-next seems okay to me, though it seems likely we will forget about fixing the tests if we don't do it now.

@lukego I will merge it then and take personal responsibility for remembering to fix the test. :-)


bug: GET /settings/pipettes takes a long time and blocks other requests

Overview / current behavior
Hitting the robot's GET /settings/pipettes endpoint:

Takes a long time. (~4 seconds on my OT-2, I think scaling with the number of pipettes for which the OT-2 is storing settings.)
Synchronously blocks subsequent requests.

One user-facing effect of this is that the calibration jog buttons will have a latency of up to ~4 seconds. The app polls GET /settings/pipettes every 5 seconds during pipette offset calibration, so a jog action will usually get stuck waiting for that poll to complete.
Steps to reproduce

Transplant my OT-2's /data/pipettes directory onto your OT-2.

As a benchmark, run:
curl --request GET '<robot_ip>:31950/modules' --header 'Opentrons-Version: 2'

And see that it returns after a fraction of a second, as expected.

Run the problematic command:
curl --request GET `<robot_ip>:31950/settings/pipettes' --header 'Opentrons-Version: 2'

And see that it returns after approximately 4 seconds, a long time.

Run the command from step 3 and then immediately run the command from step 2. See that they both return after approximately 4 seconds; the slow command blocks the fast command.

Tested on robot and app 4.0.0-alpha.7.
Expected behavior

While GET /settings/pipettes is doing its thing, a concurrent unrelated request, like GET /modules, should be processed and responded to quickly.
GET /settings/pipettes should probably not take as long as 4.2 seconds? (Not sure. My OT-2 has seen an unusually high number of pipettes. The duration may be suitably short on OT-2s that have seen fewer pipettes.)

@SyntaxColoring what are the contents of the .opentrons/pipettes directory on your robot?

The handler for /settings/pipette calls pipette_config.known_pipettes walks the pipette config directory finding configurations.
After that, for each pipette file we call pipette_config.list_mutable_configs. list_mutable_configs in turn calls pipette_config.known_pipettes to get all the pipette ids. It then does linear search in the known_pipettes list.
suggestions:

list_mutable_configs accepts known_pipettes as input.
known_pipettes returns a Set or list_mutable_configs creates a Set from input list.

I poked at it with a "quick fix" of changing list_mutable_configs to look like this:
def list_mutable_configs(pipette_id: str) -> Dict[str, Any]:
    """
    Returns dict of mutable configs only.
    """
    cfg: Dict[str, Any] = {}

    try:
        config, model = load_config_dict(pipette_id)
    except FileNotFoundError:
        log.info(f'Pipette id {pipette_id} not found')
        return cfg
    ...

which is a) more pythonic and b) avoids the quadratic issue. it's still pretty slow! and the reason appears to be that while the code is complex, at its base opentrons_shared_data.pipette.fuse_specs takes like 40ms because parsing the stupid gigantic pipette model spec is hard. tossing that in a cache fixes that issue and cuts the time if you have the attached pipettes dict down. Doing those two things cuts the time for the request to about a second (after the cache is built) but that's still not good!

MLM - not immediate fix; check with @sfoster1 on the "quick fix" status of this


[6.4.x] BZ-1310439 - RuntimeManagerFactory may fail to initialize in OSGi - t…

…est case
(cherry picked from commit d799fe234e4791a839c4417a7ff2daf6fab277e0)

jenkins reset this

merged into 6.4.x


[#75811634] Revoke session after deployment (+ update vers)

Use the new vcloud-logout utility in vcloud-core 0.16.0 to revoke the
session token after we've deployed any changes.
This requires updating vcloud-core and all things that depend on it. I don't
have an easy way to test these locally, but I'll run each of the jobs in
after merging.

@dcarley Where's this actually used on boot?

@dcarley Where's this actually used on the machine?

It's used by vcloud/jenkins_carrenza.sh before running vcloud-launch and vcloud-edge-configure.

Oh, sorry. Yes. Pre-caffeine :(


Added primary P2P protocols and improve P2P module

Added version/verack/ping/pong protocols, and heart beat logic.
Now the P2P module (the p2p folder) is better.
The integration test is p2papp.

Next we need to improve and integrate local RPC (the rpc folder) to P2P module, then connect each modules together.

Close it due to wrong target branch


Fix #115 add EXPOSE of EXPOSE_PORT (default 8080)

Not sure whether we need this. Is the EXPOSE_PORT env something from the s2i spec ?
Also, EXPOSE in a Dockerfile actually only adds meta information and doesn't really open a port by itself (e.g. in plain Docker its only used for docker -P to expose all ports.  No EXPOSE_PORT is not from the s2i spec at all, I made it up... :smile: default to 8080 and EXPOSE_PORT so that one could override it. Understood about docker -P, but where I ran into and wanted to fix it for was is #115 ... perhaps we can discuss what the right solution would be on that issue instead of this PR? I don't mind closing this one.

@vorburger note to self ;) need to remove the fix for the broken build from this PR, if not abandoned.


discover: init at 5.15.3

Motivation for this change
Is this worth merging considering discover doesn't actually do anything on NixOS?
Cc: @bkchr @adisbladis @ttuegel
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

Failure on x86_64-linux (full log)
Partial log (click to expand)
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 266 ms
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 636 ms
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 1216 ms
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 2051 ms
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 4163 ms
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 9337 ms
warning: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7); retrying in 19584 ms
error: unable to download 'http://<IP_ADDRESS>:32062/nix-cache-info': Couldn't connect to server (7)

Success on aarch64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5/bin/plasma-discover
shrinking /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5/lib/qt-5.10/qml/org/kde/discovernotifier/libDiscoverNotifierDeclarativePlugin.so
shrinking /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5/lib/plasma-discover/libDiscoverNotifiers.so
shrinking /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5/lib/plasma-discover/libDiscoverCommon.so
strip is /nix/store/xmpjypwjmp2qi1chs5kr0hacnh161ls4-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5/lib  /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5/bin
patching script interpreter paths in /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5
checking for references to /build in /nix/store/188r2a1apnzcx37ga4rg8i6913rdfzz2-discover-5.11.5...
postPatchMkspecs
postPatchMkspecs

I think it is not useful, because everything you install will not be runable. So, I would not add the discover package.

And for those wondering what "discover" is supposed to do anyway: https://userbase.kde.org/Discover
After reading that I would agree it doesn't seem to be a good idea to inlcude.  Does existing software cleanly deal with its omission (no do-nothing buttons or borked context menu entries...)?

I agree, I don't think this adds any value for our users.

Does existing software cleanly deal with its omission (no do-nothing buttons or borked context menu entries...)?

AFAIK, everything works correctly without it. And if not, that's upstream's problem for not checking dependencies 😉

Discover supposedly supports flatpak (and snap?) as a mechanism to install software which could be compatible with NixOS albeit far from the preferred option for getting software installed.

I think you are right, but are they only ship flatpaks/snaps with Discover?

but are they only ship flatpaks/snaps with Discover?

Discover can also be used to install/upgrade distribution packages which doesn't apply in to our situation.

So I haven't given up completely on this yet.
Discover can be used to handle things obtained through "Get New Hot Stuff" such as icons, wallpapers, plasma widgets and so on. When (if?) we get flatpak support at some point, discover can be used for that too. And should anyone decide to write a nix-env backend that would be an option as well.
In my opinion, the "Get Hot New Stuff" use-case is sufficiently strong to include discover.
Note: The appstream bits are included in #35308.

Success on x86_64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2/lib/plasma-discover/libDiscoverCommon.so
shrinking /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2/lib/plasma-discover/libDiscoverNotifiers.so
shrinking /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2/lib/qt-5.10/plugins/discover/kns-backend.so
shrinking /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2/lib/qt-5.10/qml/org/kde/discovernotifier/libDiscoverNotifierDeclarativePlugin.so
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2/lib  /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2/bin
patching script interpreter paths in /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2
checking for references to /tmp/nix-build-discover-5.12.2.drv-0 in /nix/store/vyr3y080vyvzyp6jrz5fa0qvr2jjpz15-discover-5.12.2...
postPatchMkspecs
postPatchMkspecs

Success on aarch64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2/lib/qt-5.10/qml/org/kde/discovernotifier/libDiscoverNotifierDeclarativePlugin.so
shrinking /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2/lib/qt-5.10/plugins/discover/kns-backend.so
shrinking /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2/lib/plasma-discover/libDiscoverNotifiers.so
shrinking /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2/lib/plasma-discover/libDiscoverCommon.so
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2/lib  /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2/bin
patching script interpreter paths in /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2
checking for references to /build in /nix/store/4hrkq7bsk7y167y627xngv8f4v9gz9lq-discover-5.12.2...
postPatchMkspecs
postPatchMkspecs

Success on x86_64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2/lib/plasma-discover/libDiscoverCommon.so
shrinking /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2/lib/plasma-discover/libDiscoverNotifiers.so
shrinking /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2/lib/qt-5.10/plugins/discover/kns-backend.so
shrinking /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2/lib/qt-5.10/qml/org/kde/discovernotifier/libDiscoverNotifierDeclarativePlugin.so
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2/lib  /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2/bin
patching script interpreter paths in /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2
checking for references to /tmp/nix-build-discover-5.12.2.drv-0 in /nix/store/0dl77ksdw2cx8hrw9lgyh159r451s0w1-discover-5.12.2...
postPatchMkspecs
postPatchMkspecs

Success on aarch64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2/lib/qt-5.10/qml/org/kde/discovernotifier/libDiscoverNotifierDeclarativePlugin.so
shrinking /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2/lib/qt-5.10/plugins/discover/kns-backend.so
shrinking /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2/lib/plasma-discover/libDiscoverNotifiers.so
shrinking /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2/lib/plasma-discover/libDiscoverCommon.so
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2/lib  /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2/bin
patching script interpreter paths in /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2
checking for references to /build in /nix/store/v91f28wc11777yqh9y1pi0k1r23fhpg4-discover-5.12.2...
postPatchMkspecs
postPatchMkspecs

We will have packagekit-nix eventually. And flatpak support is only missing tests in order to be merged.

The reasons for not merging discover are disappearing fast! Thanks for your work on flatpak - looking forward to that.

We're getting closer although the flatpak bits aren't quite working yet.

Any progress?

Not quite. It's currently blowing up complaining about packagekit but I haven't had the time to look at it.

This PR alone allows installing application and plasma addons (not applications) but requires #60146 in order to not complain like crazy.
While flatpak support is compiled in, it doesn't work yet but I don't think that's a show stopper for merging as is.

Using somewhat different tree[1] I can run this and successfully installed a flatpak app "kstars" and it runs successfully!
[1]
No clue if any of this matters, but JIC:

5.15.4 (https://github.com/NixOS/nixpkgs/pull/57520#issuecomment-480420357 I guess)
newer (dev) flatpak (needs new user and such), and enabled nixos flatpak service
I have misc flatpak remotes from gnome and kde (although TBH they generally haven't worked well for me, but dunno)

Anyway! This seems good--it's a bit unpolished UI experience that seems generally not always handling gracefully some of the details of our environment.  Anyway I think that's arguably upstream issue and our portion of it can be iterated on IMO.
Didn't have the courage to see what happens if I install things like cursors or themes O:).

Can you share more details on getting flatpak running? I have it enabled as well as the kde portal, but discover doesn't show any flatpaks.


[Question] Could we Live Streaming as Broadcaster from video/audio source files?

Hello, i have a feature live streaming from camera or other source from files. Could you please help how can i get this? Thanks so much.

Sorry for the late reply, You can refer to https://github.com/AgoraIO/Agora-Flutter-SDK/blob/master/example/android/app/src/main/kotlin/io/agora/agora_rtc_engine_example/custom_capture_audio/CustomCaptureAudioPlugin.kt and implement it on the native layer.

I believe this is now possible with agora_rtc_engine 6.0.0-rc.2, is that right?

Check this out:
https://docs.agora.io/en/interactive-live-streaming/develop/play-media/

@babihutan yes play source media files is not possible directly with sdk apis.

Thanks @plutoless, I've been eagerly watching and waiting for this feature for more than a year, going to hook up the new v6 api later this week.

These features are available on agora_rtc_engine: ^6.0.0.
Push a camera stream, you can use MediaEngine. pushVideoFrame , check https://github.com/AgoraIO-Extensions/Agora-Flutter-SDK/blob/main/example/lib/examples/advanced/push_video_frame/push_video_frame.dart for reference.
Push a video stream, you can use the MediaPlayer to handle this, check https://github.com/AgoraIO-Extensions/Agora-Flutter-SDK/blob/main/example/lib/examples/advanced/media_player/media_player.dart for reference.


fix: fsync: false when writing cache files

Summary
writeFileAtomic defaults to running fsync on the file after use.
fsync is a nearly 3x slowdown for me, ts-jest'ing my whole codebase (~900 files in testcase).
ubuntu defaults to /tmp as regular filesystem (i.e. not tmpfs), and some filesystems/devices have a large overhead for these repeated fsyncs. I happen to be on nvme (sm961), and btrfs.
We're using writeFileAtomic here in order to get atomic rename, not to get full system power failure resilience. Most(tm) filesystems will guarantee either/or during a system power failure here, which is plenty enough for us.
Test plan
There should be no functional changes here (even during a system power failure), only a performance increase in all cases, and a drastic performance increase in some cases.

Some tests are failing since we have assertions about what the function is called with, updating the tests should be quick 👍

Codecov Report

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

@@           Coverage Diff           @@
##           master    #9695   +/-   ##
=======================================
  Coverage   65.09%   65.09%
=======================================
  Files         287      287
  Lines       12144    12144
  Branches     3007     3009    +2
=======================================
  Hits         7905     7905
  Misses       3604     3604
  Partials      635      635

Impacted Files
Coverage Δ

packages/jest-transform/src/ScriptTransformer.ts
69.64% <100.00%> (ø)

Continue to review full report at Codecov.

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


Contact Navbar always active despite not in contact section

Description
In Hactoberfest 2022 page, Navbar link " Contact" remains active all the time despite not in contact section.
On refreshing, Navbar link "Blog" appears in active state.
Screenshots

Hi @SauravMukherjee44 @imyoungsparda ,
Could you please assign this issue to me as a part of hacktoberfest


Using Java 11 format language doesn't compatible to most of Fabric version Minecraft Launcher.

Crashing when uses Minecraft launcher to start Fabric version Minecraft, but doesn't in IntelliJ IDEA using Gradle built environment. The reason is you wrote this MOD under Java 11 environment.
My Minecraft launcher's Fabric loader version: 0.11.1, Fabric version: 0.30.0+1.16(all newest). The same as IntelliJ's environment. So IntelliJ automatically uses mappings that are libraries from Java 11, but the vanilla launcher's not.
I checked just now that all Fabric MODs(nearly 30 from CurseForge) I'm using are under Java 8 environment. Except for this MOD...
p.s. take it easy. no need to hurry. I already fixed it before reporting this.

I actually was a bit worried about that after all...
Well, thanks, a new fixed release will be available as soon as CurseForge approves my new file.

Oh my god... So quick... 😮

Can I pull req., or u determined to do it yrself bai yr IRON soul?(lol)
On Tue, Feb 16, 2021, 19:47 Francesco Di Gennaro<EMAIL_ADDRESS>wrote:

Closed #4 https://github.com/nivoridocs/flowstone/issues/4.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/nivoridocs/flowstone/issues/4#event-4335540483, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ALTZ6J6JXSPQJDQN5RGCQQDS7JELPANCNFSM4XV7PWGA
.

Sure, but be aware that I might reject your pull request if I think it doesn't fit the project.


Add /api prefix for /v3 API

Signed-off-by: Pavol Loffay<EMAIL_ADDRESS>Implementation for https://github.com/jaegertracing/jaeger-idl/pull/82

The CI is failing due to https://github.com/jaegertracing/jaeger/issues/3179


Support new compilation warnings format with mix

Hi, semi-related to https://github.com/elixir-lang/elixir/issues/5143
mix compile --warnings-as-errors returns a multiline string now:
 /tmp/foo $ mix compile
Compiling 1 file (.ex)
warning: variable world is unused
  lib/foo.ex:3

This PR fixes the mix maker, so both warnings and compilation errors are detected properly.

cc @geowa4

Thanks!


ci: testing with py3.11

What does this PR do?

Fixes #14652

Before submitting

Was this discussed/agreed via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
Did you make sure to update the documentation with your changes? (if necessary)
Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
Did you list all the breaking changes introduced by this pull request?
Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

Reviewer checklist

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

some dependencies could be updated much sooner like onnixruntime, encreasing queue in #17823

could be related https://github.com/cython/cython/issues/4461


Use net.LookupHost since it is more consistent.

nslookup does very different behavior depending on whether or not bind-tools is installed.
nslookup performs parallel A, AAAA lookups only if bind-tools is
NOT installed. Once bind-tools is installed, it sends AAAA queries only
after all A queries have been sent and unanswered.

What type of PR is this?
/kind bug

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

/assign @marseel

/lgtm
/approve


Update configure-service-account.md

Missing a signal.

This change is

@chenopis This is ready to be merged


Help wanted: attempt to implement an abstract container route

A big problem with exposing our functionality is that everything has a 5x multiplier: AddAcquisitionNote. This blocks doing some useful stuff in the SDK because the functions would be irritating and confusing.
We should provide /container/x routes that figure out which type of container we mean, and just serve the equivalent route. This PR is an incomplete version of doing just that!
Solved problem: we need an efficient way to resolve the container noun. Might be solved for free if we ever can truly homogenize containers. While the func snippet + db command approach here is a bit ugly on the code, I can confirm it is quite efficient and safe to use.
Unsolved problem: make webapp2 just serve a different handler, dangit. The commented-out self.redirect approach totally works: you can GET api/container/x/sessions where x is a project ID. But that won't work for non-gets, and we shouldn't redirect anyway. We should just serve.
I'm 90% sure we can take these code scraps, and either:

Modify the (~5) fields of the request object to reflect the "proxying"
Construct a new context with the same body reader?

And call a handler method. Help?

A bunch of doc links:
https://webapp2.readthedocs.io/en/latest/guide/request.html
https://webapp2.readthedocs.io/en/latest/guide/routing.html
https://webapp2.readthedocs.io/en/latest/api/webapp2.html#webapp2.Request
https://webapp2.readthedocs.io/en/latest/api/webapp2.html#webapp2.Router
https://webapp2.readthedocs.io/en/latest/api/webapp2.html#webapp2.Route
https://webapp2.readthedocs.io/en/latest/_modules/webapp2.html#Router.default_matcher
I've mostly solved the puzzle just from hopping through various function sigs & bits of source code.

Codecov Report

Merging #937 into master will decrease coverage by 0.39%.
The diff coverage is 17.14%.

@@            Coverage Diff            @@
##           master     #937     +/-   ##
=========================================
- Coverage   90.19%   89.79%   -0.4%
=========================================
  Files          48       49      +1
  Lines        6413     6448     +35
=========================================
+ Hits         5784     5790      +6
- Misses        629      658     +29

Flag
Coverage Δ

#python
89.79% <17.14%> (-0.4%)
:arrow_down:

Impacted Files
Coverage Δ

api/api.py
100% <100%> (ø)
:arrow_up:

api/handlers/abstractcontainerhandler.py
14.7% <14.7%> (ø)

Continue to review full report at Codecov.

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

This was later completed in flywheel-io/core#937


Allow setting select data without losing the current selection.

First of all, I want to thank you for your awesome work. MetroUI has made my life easier for a few years now. The current version is a blast and it looks gorgeous.
Now to my suggestion: I recently built upon the Ajax Select sample to create a server-side suggestion list, i.e. the user types in some string and the server returns a JSON-list of suggestions using AJAX. I found this a little bit cumbersome, since while it is possible to set the select options using .data(...), it completely rebuilds the options list, which also removes the previously selected items (in case of a multiple select).
I came up with a solution that caches the current selection manually:
var selectControl = Metro.getPlugin('#select1', 'select');
var element = selectControl.element;
var input = selectorContainer.closest('.select').find('.drop-container input[type="text"]');

// Hook typing event of filter input.
input.on('input', function () {
        // Store the current selection.
        var selectedKeys = selectControl.getSelected();
        var currentSelection;

        selectedKeys.forEach(function (key) {
            currentSelection[key] = $(element).find('option[value="' + key + '"]').text();
        });

        // Post an ajax request to the server.
        $.ajax({
            url: '/suggest',
            method: "GET",
            parseJson: true,
            data: {
                filter: $(this).val(),                  // Current filter text
                except: JSON.stringify(selectedKeys)    // Currently selected keys, that should not be included in the response.
            }
        }).then(
            function (response) {
                // Parse the response
                var suggestions = JSON.parse(response);

                // Add the current selection back to the suggestions.
                selectedKeys.forEach(function (key) {
                    suggestions[key] = currentSelection[key];
                });

                // Build the selection list.
                selectControl.data(suggestions);

                // Select all previously selected keys.
                selectControl.val(selectedKeys);
            },
            function (xhr) {
                console.log(xhr.status, xhr.statusText);
            }
        );
    }
});

There are two things that I think would greatly improve the select control. First of all (and my main point, as the title suggests), I would love to be able to set the response and keep the currently selected options. The select control already stores them, but is getting reset with setting the data. Maybe a boolean flag could be added, which already reduces the code to something like this:
var selectControl = Metro.getPlugin('#select1', 'select');
var input = selectorContainer.closest('.select').find('.drop-container input[type="text"]');

// Hook typing event of filter input.
input.on('input', function () {
        // Post an ajax request to the server.
        $.ajax({
            url: '/suggest',
            method: "GET",
            parseJson: true,
            data: {
                filter: $(this).val(),
                except: JSON.stringify(selectControl.getSelected())
            }
        }).then(
            function (response) {
                // Second parameter could be used to keep currently selected values.
                selectControl.data(JSON.parse(response), true);
            },
            function (xhr) {
                console.log(xhr.status, xhr.statusText);
            }
        );
    }
});

Second, I think it would be nice to have some built-in events to hook filtering (e.g. onFiltering which hooks into the filter-control input event and onFiltered, which could be executed, after the filtered results are shown). This would further simplify the code above:
// Hook typing event of filter input.
Metro.getPlugin('#select1', 'select').on('filtering', function (filterString) {
        // Post an ajax request to the server.
        $.ajax({
            url: '/suggest',
            method: "GET",
            parseJson: true,
            data: {
                filter: filterString,
                except: JSON.stringify($(this).getSelected())
            }
        }).then(
            function (response) {
                selectControl.data(JSON.parse(response), true);
            },
            function (xhr) {
                console.log(xhr.status, xhr.statusText);
            }
        );
    }
});

Thanks in advance and keep up your work! 👍

In 4.3.10 I added

[x] Select: for API method data(newOptions, selectedValues) added second argument. Must be a string or array

<!DOCTYPE html>

    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
    <link href="../metro/css/metro-all.css?ver=@@b-version" rel="stylesheet">

    <title>Select set data test - Metro 4 :: Popular HTML, CSS and JS library</title>

Select set data test page

        <button class="button" onclick="loadData()">Load data</button>

            <select id="sel1" data-role="select">
                <option value="1">Item 1</option>
                <option value="2" selected>Item 2</option>
                <option value="3">Item 3</option>
            </select>

            <select id="sel2" data-role="select" multiple>
                <option value="1">Item 1</option>
                <option value="2" selected>Item 2</option>
                <option value="3" selected>Item 3</option>
            </select>

Thank you very much! 😊 I will update my version and try this out, when I've got time.
Also, I've send you a donation. Hope it helps you out! 💸

Thank you for your donation ❤. Could you clarify the details of the donation, I can not find the transaction.  Thanks you.

I've used the SEPA EURO bank account from your support page (GB61CLJU00997180121989). It should be transferred in a couple of days.

Thank you my friend ❤


RFC: Reserved prefixes in the 2021 edition

Beginning with the 2021 edition, reserve the syntax ident#foo, ident"foo", ident'f', and ident#123, as a way of future-proofing against future language changes.
Rendered

This looks great. :)

how about also adding ident#number, and ident#'char'? seems like it might be useful for future user-defined literals

Ah yes, I totally forgot about char; if we go through with this for string literals, it seems to make sense to go through with it for chars as well. And I'd propose to reserve ident'foo', for symmetry with b'foo'; no need for the intervening # in this case. For integers we would still need the #; I only didn't include numeric literals out of some desire not to increase the scope without cause (at least for string literals, there are pre-proposals in mind). That said, it would be precedented from other languages; e.g. Ada has foo#num# where foo is the radix of the literal.

I feel like reserving character literals and numbers seems reasonable.

I've pushed changes based on the feedback here and on Zulip. Highlights:

Reserve prefixes on char literals and numeric literals as well.
The use of an unknown prefix is now a pre-tokenization error, rather than a post-tokenization error.

I think ident#"... and ident#'... where the ... is any arbitrary text (and possibly ident'ident and ident'number) should also be reserved (except we should keep raw strings and other stuff that's already defined, of course).

Can you explain in more detail what you'd like to reserve and why?

ident#"... would be reserved so we could add raw string variants of whatever new strings may be added in the future, e.g. fr#"raw format string"# could be shorthand for format_args!(r#"raw format string"#).
similarly for ident#'....
now that I'm typing this, I realized we should also add ident##... to support fr##"my f-string"##.
Though maybe we should just reserve everything of the form ident#... -- that makes the rule for # much easier to explain and implement.

@programmerjake , note that the RFC as written does indeed reserve this syntax for raw string literals (for all possible quantities of surrounding #s); see the tokenizing rule for RESERVED_STRING_LITERAL in the reference-level explanation.
WRT "reserve everything of the form ident#...", what do you mean by "everything"? Every single production in the language, e.g. attributes ident#[foo], blocks ident#{...}, lifetimes ident#'foo, etc? Just the things referred to by this proposal? I think the former would take a large amount of justification, and for the latter I would say it is at odds with my perception of this RFC; IMO the important thing is the identifier prefix, and the # only exists where necessary to disambiguate the prefix from the following item. E.g., I don't see any scenario where it would be useful to be able to write b"foo" as b#foo"; not even macros (which historically have motivated a lot of the ""useless"" flexibility in the grammar) need this sort of generic flexibility.

@rfcbot fcp merge
In our 2021-04-06 meeting, we decided that we'd like to move forward with this RFC.
There were also a few other notes with respect to the right time to report an error and so forth (we felt reporting the error during tokenization time would be better, gives us maximal choices later).

'Reserving' these by making them one token seems like a good idea, but refusing to lex them feels like a step too far.  See also https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/reserved.20prefixes/near/233436712
Originally we just wanted to reserve k#ident and f"..", by making those one token. Then the idea was generalized to include all prefixes, which seemed like an easy generalization. But that turned out to be a bit more complicated, since we would already need to decide on the validity of e.g. bar"å\" (Is it a raw string (accepting the \)? Is it a byte string (which doesn't accept å)?). So now the proposal is to refuse to even tokenize/lex these, making them unusable even as $($_:tt)* or TokenStream, which some (proc) macros rely on. I'm not sure that's worth it.
Also note that the crater run is now only testing k#ident and nothing else, since the try build failed with the other proposed reserved syntax errors enabled.

Can this at least acknowledge some of the concerns raised in #3098?  Presumably this syntax space is reserved with an intent to use it, but there are some that don't want to see it used.  The motivation section here just seems to say reserving for the sake of reserving something, but doesn't say what it is being reserved for. That seems quite vague to me. Without concrete use cases, it is hard to see why this is even being done.
Additionally, I asked why new keywords couldn't be handled in a nightly-only capacity, but did not receive a response.

I think a good idea for the motivation would be to discuss some of the prior additions that we have done using these syntactic categories:

r#foo for raw identifiers
adding r"foo" for raw strings
adding b"foo" for byte strings

rather than going into possible future choices.

Regarding the use of nightly and keywords specifically, well, that's a different RFC, so perhaps I'll just respond over there.

The motivation section here just seems to say reserving for the sake of reserving something, but doesn't say what it is being reserved for.

Well, the point is that we want to leave the option open to make such reservations in the future. :) I tried to avoid giving more concrete examples so as to to not bog down the RFC with particulars, but if you look closely you will see that I do mention something I've given some small amount of thought to: edition prefixes for more fine-grained transitions.  If identifiers could be prefixed with an edition, then when Rust 2018 changed the semantics of use, it could preserve the old semantics under e15#use, introduce the new semantics under e18#use, and then make use map to both of these on the 2015 and 2018 editions respectively. Then a user on the 2015 edition could run rustfix --soft, which would update their edition to 2018 but, for any use statement that begins emitting a warning or error, could instead change it to e15#use until it has precisely identified all the use statements that need manual updating, and then commit the resulting code, which is now a warning-free 2018-edition crate. The e15#use could then be tackled on a per-case basis, at the author's leisure; think of them sort of like git conflict markers, except they don't stop your code from compiling. The same mechanism could have been used for the match changes in 2018, or the potential Range changes proposed for 2021, or (temporal causality aside) this very change, i.e. e18#macro_rules! could tokenize differently from e21#macro_rules! . Whether or not these specific examples would actually pan out with such a mechanism, I don't know (I haven't written any RFC), but I think the promise is there, and leaving the door open for it (in addition to raw keywords) seems like a reasonable trade-off for what it costs (which is, as far as we can tell, very little).
In addition, the RFC notes that other languages do reserve "syntactic space" for their own use, even when they don't know what that space will eventually be used for; their designers considered that having any motivation at all is less important than having an emergency escape hatch.

RFC updates: I've taken the liberty to demote this reservation from a tokenization error to a parser error. The only reason that it was a tokenization error was because it was easier to loosen the rule later if a good use case could be found, and I figure that the current objection is as good a use case as any. :P
I've also clarified regarding the restrictions that the current parsing of strings imposes on future prefix choices. The reference-level tokenization rules have the same effect as previously, but have been split out for clarity.

@rfcbot resolve lex-error

@rfcbot concern error-on-unknown-reserved-syntax
Please note, this is a concern I'm open to discussing further. I just feel like the RFC has changed substantially since I originally checked the rfcbot box, and I'm not sure where it ended up will be sufficiently future-proof.
While I don't specifically feel this needs to be a lex error, I do think it's important for us to have a compiler error at some phase on any use of unknown reserved syntax. A rule like "ends in r" doesn't seem like something we should commit to just so we can lex unknown reserved syntax; we could use that as a recovery heuristic, but I don't think we should commit to it for all future language extensions.

This originally started out proposing to reserve ident#ident. The addition of ident"string" and ident'c' has turned up conflicts with existing macros that people already have, and I understand not wanting to break those macros. But I don't think that we should reduce the degree to which we future-proof this syntax reservation because of that. If we reserve syntax, and we're choosing not to make unknown syntax an error because macros might touch it, then those same macros may prevent us from defining some new syntax in the future, which defeats the purpose of the syntax reservation.
If necessary, I would much rather see the proposal pared back to just reserve ident#ident, if that would be sufficient to allow reserving the syntax in a future-proof manner. We could always reserve ident"string" and similar at another time, and discuss what that reservation should look like and how to handle it smoothly.

There is a hybrid option:

We could lex error on most things but have a list of prefixes that we permit but report errors on during parsing -- most notably we would want to permit f to not break crates like @m-ou-se's crate.

@nikomatsakis I'd be entirely in support of that option. Reserving that syntax and un-reserving some specific items to avoid conflicts is strictly better than not reserving any of the syntax.

I'm curious @m-ou-se and @bstrie what you think about calling out f"..." specifically. I would expect it to be lexed like any other string.
I seem to recall there being some concern that we may want to change lexing modes when we encounter an embedded {, so that f"foo{bar.baz("...")}qux" could be accepted? We could just do that now, I do sort of agree that it's the better behavior, but we're effectively 'pre-committing" to this feature in that case. =)
Alternatively we could make it a lexer error if f strings contain embedded quotes inside of a { or something like that.
Are there other concerns around f?
Are there other prefixes we know of that may be in use in this way?
Finally, just to confirm, the entire concern here is around procedural macros that snoop on whitespace, right?

The last time we discussed strings with embedded formats was in the context of println/format/etc. We discussed the possibility of arbitrary expressions at that time, and rejected them. That doesn't mean we could never consider them in the future, but I think it makes it less likely that format strings would have embedded expressions that in turn have embedded strings. I would propose that we lex f"..." strings exactly the way we currently lex unprefixed strings. We could always extend it in the future.

The last time we discussed strings with embedded formats was in the context of println/format/etc. We discussed the possibility of arbitrary expressions at that time, and rejected them. That doesn't mean we could never consider them in the future, but I think it makes it less likely that format strings would have embedded expressions that in turn have embedded strings. I would propose that we lex f"..." strings exactly the way we currently lex unprefixed strings. We could always extend it in the future.

Yes, I don't foresee any problem there. I personally feel it's unlikely that there would be much demand for allowing implicit captures to include every possible Rust expression; the future work on implicit captures suggests pursuing only a restricted subset of expressions such as format!("{foo.bar}"). Since the only problematic characters here are \ and ", and since those don't show up anywhere in Rust syntax except in strings, this imposes very few future restrictions on extending implicit captures in such a selective way. And even then, if people did want to support arbitrary expressions, then raw (format-)strings would still permit that, e.g. fr#"foo{bar.baz("...")}qux"#. I don't see an advantage to attempting any sort of mode switching on embedded {}.

@m-ou-se and I discussed this in the 2021 Edition meeting. We were feeling pretty good about reverting the RFC to a lexer error, and then having follow-up RFCs for particular prefixes that we wish to enable (e.g., f). This way we can discuss the motivations for each such prefix separately as well as any particular lexing rules that may or may not be appropriate.

I'm fine with reverting to the draft where these were lexing errors rather than parsing errors.

ok, I think we've reached consensus:

This RFC introduces strict lexing errors, to maximize future flexibility.
Follow-up RFCs will outline the rules for specific prefixes on a case-by-case basis.
Naturally we retain the option to just specify the lexing rules for all future prefixes at some point if we wish, similar to what a prior draft of this RFC attempted to do.

@joshtriplett can you resolve error-on-unknown-reserved-syntax?

Thanks for the updates!  I read through this again after the round 3 updates, and I like the text and plan.
@rfcbot reviewed

@rfcbot resolved error-on-unknown-reserved-syntax

Thanks for the proposal, @nikomatsakis, and thanks for the update, @bstrie!

Since this makes the lexer edition-dependent, what will this mean for proc_macro::TokenStream::from_str? That takes a string without any span/edition info. Does it use the edition of the proc macro crate? Or of the crate the proc macro was invoked from? (And if so, what does that mean if it was invoked by a macro_rules macro from an edition 2018 crate which was in turn invoked from a 2021 crate?) Or does it always use the latest edition?

Since this makes the lexer edition-dependent, what will this mean for proc_macro::TokenStream::from_str? That takes a string without any span/edition info. Does it use the edition of the proc macro crate? Or of the crate the proc macro was invoked from? (And if so, what does that mean if it was invoked by a macro_rules macro from an edition 2018 crate which was in turn invoked from a 2021 crate?) Or does it always use the latest edition?

Maybe deprecate it and add a new function that takes an edition parameter?

That's a good question, @m-ou-se =)
I'd like to know a bit more about how that function is used in practice. It seems clear that the ideal would be to use the edition of the crate from which that string originated, but without any span, we can't know that.
We could indeed deprecate in favor of an API that takes span information-- I'm not overly familiar with that crate, does such an API already exist?
I was planning on merging this RFC, and I think I will do so, but I'll add this to the list of unresolved question and open an issue for follow-up.

Huzzah! The @rust-lang/lang team has decided to accept this RFC. Please follow along on the tracking issue https://github.com/rust-lang/rust/issues/84978.


Finish physics documentation

https://github.com/BabylonJS/Documentation/issues/454

@RaananW Hello my friend, do you think this could be done by end of nov?

Yes, for sure.


Weird problem with asdf-crystal's 0.23.1 on macOS 10.12

Hello.
I'm trying out this new web framework, and I installed 0.23.1 using asdf-crystal. When I run lucky init <name> it all seems to work, but then when I go the created dir and run lucky dev, I see this:
...
16:16:27 web.1      |  [warn] kq_init: detected broken kqueue; not using.: Undefined error: 0
16:16:28 web.1      |  Error in tasks.cr:2: while requiring "./src/app"
16:16:28 web.1      |  require "./src/app"
16:16:28 web.1      |  ^
16:16:28 web.1      |  in src/app.cr:1: while requiring "./dependencies"
16:16:28 web.1      |  require "./dependencies"
16:16:28 web.1      |  ^
16:16:28 web.1      |  in src/dependencies.cr:1: while requiring "lucky_record": can't find file 'lucky_record' relative to '/Users/bruno/Code/WORK/constable-crystal/src'
16:16:28 web.1      |  require "lucky_record"
16:16:28 web.1      |  ^
16:16:28 web.1      Exited Successfully
...

But if I run this with Crystal 0.23.1 from homebrew, it works fine:
[WARN] No ENV file found
16:17:35 assets.1   |  yarn run v1.0.1
16:17:35 assets.1   |  warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts.
16:17:35 assets.1   |  $ "/Users/bruno/Code/WORK/constable-crystal/node_modules/.bin/brunch" "watch"
16:17:37 web.1      |  Beginnning to watch your project
16:17:37 web.1      |  compiling...
16:17:38 assets.1   |  16:17:38 - info: compiled 6 files into 2 files in 2.0 sec
16:17:39 web.1      |  Listening on http://<IP_ADDRESS>:8080...
16:17:39 web.1      |  yarn run v1.0.1
16:17:40 web.1      |  warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts.
16:17:40 web.1      |  $ "/Users/bruno/Code/WORK/constable-crystal/node_modules/.bin/browser-sync" "start" "-c" "bs-config.js"
16:17:40 web.1      |  [Browsersync] Proxying: http://localhost:8080
16:17:40 web.1      |  [Browsersync] Access URLs:
16:17:40 web.1      |   ------------------------------------
16:17:40 web.1      |         Local: http://localhost:3000
16:17:40 web.1      |      External: http://<IP_ADDRESS>:3000
16:17:40 web.1      |   ------------------------------------
16:17:40 web.1      |            UI: http://localhost:3001
16:17:40 web.1      |   UI External: http://<IP_ADDRESS>:3001
16:17:40 web.1      |   ------------------------------------
16:17:40 web.1      |  [Browsersync] Watching files...
16:17:41 web.1      |  GET /favicon.ico? - 404 (230.0µs)
16:17:41 web.1      |  GET /? - 200 (4.42ms)
16:17:41 web.1      |  GET /favicon.ico? - 404 (33.0µs)
16:17:41 web.1      |  GET /favicon.ico? - 404 (34.0µs)
16:17:41 web.1      |  GET /favicon.ico? - 404 (48.0µs)
16:17:41 web.1      |  GET /favicon.ico? - 404 (42.0µs)
16:17:41 web.1      |  GET /favicon.ico? - 404 (44.0µs)
16:17:42 web.1      |  GET /favicon.ico? - 404 (47.0µs)
16:17:42 web.1      |  GET /favicon.ico? - 404 (36.0µs)

I have no idea why this would be the case. Here are the -v outputs for both versions:

homebrew:
Crystal 0.23.1 (2017-09-08) LLVM 4.0.1
asdf-crystal:
[warn] kq_init: detected broken kqueue; not using.: Undefined error: 0 Crystal 0.23.1 [e2a1389] (2017-07-13) LLVM 3.8.1

Is this a compilation flag issue for asdf-crystal's builds?
Thanks for any help!

I have the code I'm using up as a repo https://github.com/sardaukar/constable-crystal

Thank you @sardaukar and sorry for the delay. I'm very busy these days.
About your output, showing the differences in versions.
Seem that the error
[warn] kq_init: detected broken kqueue; not using.: Undefined error: 0 Crystal 0.23.1
are in the LLVM version.
You can see the same problem here https://github.com/marciogm/asdf-crystal/issues/4#issuecomment-320245582
I think that the require issue, are causing by CRYSTAL_CONFIG_PATH.
I cannot check this until the weekend. 😕
Maybe the right fix for this is to set the correct path in https://github.com/marciogm/asdf-crystal/blob/master/bin/exec-env

No need to apologize @marciogm ! I've found a workaround for now, but would like to continue using this plugin. Anyway, if you need more info to debug this, let me know.

Could you send the output from this.
crystal eval 'puts ENV["CRYSTAL_CONFIG_PATH"]'
From boths crystal (asdf and homebrew)

The output is the same for both:
Missing ENV key: "CRYSTAL_CONFIG_PATH" (KeyError)
0x1024ba865: *CallStack::unwind:Array(Pointer(Void)) at ??
0x1024ba801: *CallStack#initialize:Array(Pointer(Void)) at ??
0x1024ba7d8: *CallStack::new:CallStack at ??
0x1024b9af5: *raise<KeyError>:NoReturn at ??
0x102505fa7: *ENV::fetch<String>:String at ??
0x102505f19: *ENV::[]<String>:String at ??
0x1024a98d1: __crystal_main at ??
0x1024b9998: main at ??

@sardaukar Thank You.
I just pushed a fix to that. Can you try now? :)

It works! Thanks for fixing this! ❤


Update modals.html

Remove extra spaces.

modals.html is compiled from jade. We can only merge changes made to those source files.


White Screen - App content failed to load after launch released iOS app

Hello to everyone.
I installed my application play store seamlessly. However, when I tried to install the App Store, the application was rejected and I received the following message.
Guideline 2.1 - Performance - App Completeness
We discovered one or more bugs in your app when reviewed on iPad running iOS 12.3.1 on Wi-Fi.
When we launched the app, app displayed a splash screen and no further action occurred in the app during the review.
Next Steps
To resolve this issue, please run your app on a device to identify any issues, then revise and resubmit your app for review.
If we misunderstood the intended behavior of your app, please reply to this message in Resolution Center to provide information on how these features were intended to work.
For new apps, uninstall all previous versions of your app from a device, then install and follow the steps to reproduce the issue. For updates, install the new version as an update to the previous version, then follow the steps to reproduce the issue.
Resources
For information about testing your app and preparing it for review, please see Technical Note TN2431: App Testing Guide.
For a networking overview, please review About Networking.
Please see attached screenshots for details.
When I write flutter doctor there is no problem.
I tried the application on the real device again no problem.
But the app store made such a turn. Does anyone know the reason or are having the same problem?

Resolved
https://www.flutterforum.org/d/97-white-screen-app-content-failed-to-load-after-launch-released-ios-app

@ishakdas I think it's safe to close the issue as it's already fixed on master. If you disagree or encounter it again, please comment and I will re-open it right away.


New export options in iOS

This PR adds a number of capability switches, adds orientation settings and adds a number of privacy strings you need to set up.
This is by no way complete but I am removing the WIP status. Most of the things not implemented are things Godot currently doesn't support anyway. As there are additional entitlements related to some of the capability switches it is best we leave implementation of those until someone has a usecase and can actually test if things work as expected.
For now, this adds the ones that have an impact on what we currently do such as gamekit, in app purchases etc.
There are two reasons we add these into the export settings even though xcode allows you to toggle them after exporting:

when you de-select anything in xcode it will also remove the associated frameworks and dylibs, this is a problem because it means we can't link Godot. Even when not used we still have the code in our binaries.
if you don't have a paid developer account you don't get access to most of the capabilities including not having access to turn them off!

Both these remarks should probably be in the documentation for exporting to iOS.

Thanks!

I have added a usage description to Photo Library in iOS export, but did not get a permissions popup.  I am getting the Camera permissions popup although I left the camera usage description blank.
I'm trying to get access to OS.get_system_dir(6)    "Pictures directory path" with the photo library usage description but no luck.
OS.get_system_dir(6) is working fine on android with read/write external storage permission enabled.
Is there another way to do this?


Updated release Workflow with latest Action inputs

Current dependencies on/for this PR:

main

PR #1371   👈

This comment was auto-generated by Graphite.


[stable/kiam] added whitelist argument in agent-daemonset.yaml

Signed-off by: Pravar Agrawal<EMAIL_ADDRESS>What this PR does / why we need it:

Makes it possible to specify whitelist arguments for allowing other AWS metadata API paths which are currently blocked by default
Update the README.md
Bump the version

https://github.com/uswitch/kiam/blob/a7456b01a22ea60adcf7dda861953af64efc3478/cmd/kiam/agent.go#L49
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @maorfr

/ok-to-test
/lgtm
thanks!


Golang's built in MySQL driver works but gorm's does not

Your issue may already be reported! Please search on the issue track before creating one.
What version of Go are you using (go version)?
go version go1.9 darwin/amd64
Which database and its version are you using?
MySQL 5.7.14
package main

import (
    "database/sql"
    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, err := sql.Open("mysql", "root:pass@tcp(ip:3036)/gcp?charset=utf8&parseTime=True&loc=local")
}

The above works, the below does not.
package main

import (
    "github.com/jinzhu/gorm"
    _ "github.com/jinzhu/gorm/dialects/mysql"
)

func main() {
    db, err := gorm.Open("mysql", "root:pass@tcp(ip:3036)/gcp?charset=utf8&parseTime=True")
}

The connection times out and the error ends up being: dial tcp <ip>:3036: getsockopt: operation timed out. Any idea what the problem may be and how I can debug?

Using the wrong port.


Upgrade deps and add linting & formatting

As preparation to make a PR for #2, I’ve upgraded TypeScript and added eslint, prettier and jest-environment-jsdom-global to allow tests to modify window.location.
Hope this looks good to you but happy to make changes!

Looks good! I personally prefer async/await over using Promises directly - but it's just a pet peeve :) Keep 'em coming! Adding you as a maintainer now

Thanks! :) I also prefer async/await but couldn’t work out how to use it in that context—feel free to fix!


Differnet backend per listener mix HTTP and HTTPS?

It is possible at this time, or will it be possible in the future to create multiple backends, some HTTP and some HTTPS and specify which listener port listens to which backend? Currently it looks like I can specify multiple backends, but not specify which goes with with listener. Also, it appears that all backends are all HTTP or all HTTPS.

This is super important to simplify how redirecting works. If you can specify different backends for the same host/path based on if it's http or https then you can put in a simple http to https redirect backend that does the 301 (like https://github.com/coreos/docker-nginx-https-redirect).
At the moment the only way to achieve this is to catch it in each application and do the redirect there.
What would be even nicer is if alb-ingress-controller paid attention to ingress.kubernetes.io/ssl-redirect: "true" for us. In ALB there is no native way to do this so we could automate spinning up a redirect service in k8s and point the http part to that service.

It's not possible. Would this be something that could be addressed by multiple ingress definitions?

Would #135 solve your problem?


SendGrid Free is not available

This document says "Azure customers can unlock 25,000 free emails each month". I can confirm that this has worked before. However, now, when choosing the "Free" plan, the pricing tier automatically defaults to Bronze. When you click "Change plan", the Free plan is no longer available.
I can replicate this scenario in four different tenants using different subscriptions. Can you confirm if this is still applicable? or If not, perhaps you should update your documentation.

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

ID: 73d91616-a93f-84af-7900-5aa34b361ffd
Version Independent ID: f202a678-4853-d024-55c5-19f89558415c
Content: How to use the SendGrid email service (.NET)
Content Source: articles/sendgrid-dotnet-how-to-send-email.md
Service: multiple
GitHub Login: @georgewallace
Microsoft Alias: gwallace

Hi @junecastillote - Thank you for your feedback! It does appear that the Free offering is no longer an available option. As the next step, we are proceeding to assign this issue to the author to review further and take the next course of action.

#reassign:timwarner-msft

Hi @junecastillote. Thanks for raising this issue. Because our page was (404s now - I just checked it) a redirect to sendgrid.com, we can't update their docs from our end. I'm sorry. Kindest regards, Tim

#please-close


use JEE 3.0 to allow cookie session tracking

This is useful for us locally. It isn't supported for Tomcat 6, so depending on what installation requirements you want to have, may elect not to merge it yet while Tomcat 6 is still supported for security updates.

This is fine with me, thanks!


config: remove CONFIG_REFCOUNT_FULL in config.base for arm

CONFIG_REFCOUN_FULL is gone since v5.5, so remove it here as
kernel for virtio-fs base on v5.6.
Fixes: #1168
Signed-off-by: Jianyong.Wu<EMAIL_ADDRESS>@devimc  @jodh-intel

/test

Sorry about prematurely running /test.
Our DCO check is failing because of:
  3047df809ea237bbd68e3d6e1819c42592e97452    Expected "Jianyong Wu<EMAIL_ADDRESS>but got "Jianyong.Wu<EMAIL_ADDRESS>

Thanks @fidencio, having reposted it. this PR has merged to kata-container-2.0

/test

Thanks @fidencio, having reposted it. this commit has merged to kata-container-2.0

If the exactly same commit was merged in 2.0, we have a discrepancy in our scripts.
@jodh-intel, are you aware of something different in 2.0 and this branch about the DCO checks?

sorry @fidencio -, I make mistake, this PR has not posted to kata-2.0. It's the PR has merged into kata-2.0.

sorry @fidencio -, I make mistake, this PR has not posted to kata-2.0. It's the PR has merged into kata-2.0.

Okay, no problem. :-). Thanks!

Hello @jodh-intel @devimc - need test for this.

/test

/AzurePipelines run

@jongwu Need a bump in kata_config_version here

thanks @amshinde , done.

/test

/test

/test

/test

Hi @lifupan @amshinde,  can you help trigger the tests? thanks.

Hi @lifupan @amshinde,  can you help trigger the tests? thanks.

/test

/test

/retest

/retest

hello @jodh-intel @devimc , it seems the CI is broken as it can't be triggered.

hello @jodh-intel @devimc , it seems the CI is broken as it can't be triggered.

@jongwu can you rebase and try again ?

@jongwu can you rebase and try again ?

/test-snap

/test-snap

/retest-snap

/retest-snap

@devimc ^ looks like the snap build isn't triggering ;(

@devimc ^ looks like the snap build isn't triggering ;(

@jodh-intel you can't trigger github actions using comments :sweat_smile:

@jodh-intel you can't trigger github actions using comments :sweat_smile:

please ignore the snap CI, I still need to backport a patch to fix yq

please ignore the snap CI, I still need to backport a patch to fix yq

@devimc - Doh! ;) We need to remove the entry from https://github.com/kata-containers/community/wiki/Controlling-the-CI.

@devimc - Doh! ;) We need to remove the entry from https://github.com/kata-containers/community/wiki/Controlling-the-CI.

/test

/test

hello @jodh-intel @devimc , this PR blocked by CI for a long time. Is there any process?

hello @jodh-intel @devimc , this PR blocked by CI for a long time. Is there any process?

@jongwu - I've restarted the failing CI's, so ... :crossed_fingers: it works this time... :smile:
/AzurePipelines run

@jongwu - I've restarted the failing CI's, so ... :crossed_fingers: it works this time... :smile:
/AzurePipelines run

@jongwu - the static checks are failing:
ERROR: Required SPDX license header check ('SPDX-License-Identifier: Apache-2.0') failed for the following files:

kernel/configs/fragments/arm64/acpi.conf
kernel/configs/fragments/arm64/base.conf

You can either add that header, or you might want to raise a 1.x PR on the tests repo to make the static checker ignore files below kernel/configs/. We already did that for 2.x so you could raise a PR very similar to:

https://github.com/kata-containers/tests/pull/2964

@jongwu - the static checks are failing:
ERROR: Required SPDX license header check ('SPDX-License-Identifier: Apache-2.0') failed for the following files:

kernel/configs/fragments/arm64/acpi.conf
kernel/configs/fragments/arm64/base.conf

You can either add that header, or you might want to raise a 1.x PR on the tests repo to make the static checker ignore files below kernel/configs/. We already did that for 2.x so you could raise a PR very similar to:

https://github.com/kata-containers/tests/pull/2964

thanks @jodh-intel -, I will raise a PR to fix it.

thanks @jodh-intel -, I will raise a PR to fix it.

hello @jodh-intel  @devimc, any comments?

/test

/AzurePipelines run

/AzurePipelines run

/AzurePipelines run

/test