Support Fragment instead of v4 fragment

hello
is it possible to use fragment which is extend com.android.fragment?

Hi @ZulfikarRahman,
Assuming you meant android.app.Fragment this is possible, however not out-of-the-box.
To do so you need to include support-v13 library in your project (https://developer.android.com/reference/android/support/v13/app/package-summary.html)
and create your own step adapter which would be using the native fragments and FragmentPagerAdapter from support-v13, i.e.

package com.stepstone.stepper.adapter;

import android.app.Fragment;
import android.app.FragmentManager;
import android.content.Context;
import android.support.annotation.IntRange;
import android.support.annotation.NonNull;
import android.support.v13.app.FragmentPagerAdapter;
import android.support.v4.view.PagerAdapter;

import com.stepstone.stepper.R;
import com.stepstone.stepper.Step;
import com.stepstone.stepper.viewmodel.StepViewModel;

/**
 * A base adapter class which returns step system fragments to use inside of the {@link com.stepstone.stepper.StepperLayout}.
 */
public abstract class AbstractNativeFragmentStepAdapter
        extends FragmentPagerAdapter
        implements StepAdapter {

    @NonNull
    private final FragmentManager mFragmentManager;

    @NonNull
    protected final Context context;

    public AbstractNativeFragmentStepAdapter(@NonNull FragmentManager fm, @NonNull Context context) {
        super(fm);
        this.mFragmentManager = fm;
        this.context = context;
    }

    @Override
    public final Fragment getItem(@IntRange(from = 0) int position) {
        return (Fragment) createStep(position);
    }

    /** {@inheritDoc} */
    @SuppressWarnings("unchecked")
    public Step findStep(@IntRange(from = 0) int position) {
        String fragmentTag =  "android:switcher:" + R.id.ms_stepPager + ":" + this.getItemId(position);
        return (Step) mFragmentManager.findFragmentByTag(fragmentTag);
    }

    /** {@inheritDoc} */
    @NonNull
    @Override
    public StepViewModel getViewModel(@IntRange(from = 0) int position) {
        return new StepViewModel.Builder(context).create();
    }

    /** {@inheritDoc} */
    @Override
    public final PagerAdapter getPagerAdapter() {
        return this;
    }
}

and use that adapter with android.app.Fragment.
However, I would still recommend using the Support Fragments instead. Please see: http://stackoverflow.com/questions/17295497/fragment-or-support-fragment

yes, that's what i mean.
sorry for the title, should be "supporting  anndrod.app.fragment instead of v4 fragment".
thanks for the solution, i will try


The edit tags link on the home page doesn't do anything

The is an edit tags link on the home for the disabled list of tags. It doesn't do anything.

Removed the edit tags link.


Selecting reset option in mat-select

Bug, feature request, or proposal:
When undefined (reset) option is selected in mat-select, and you open the options list and select the undefined option again, both valueChange and ngModelChange events are fired. When you do the same with non-undefined option, none of the events is fired.
What is the expected behavior?
I would expect undefined options to behave same as non-undefined ones, i. e. not to fire an event when the same option is selected twice.
What is the current behavior?
See above.
What are the steps to reproduce?
https://stackblitz.com/edit/angular-hbmfjn-wk5qdh
Small example in Stackblitz. Undefined option is set as default. Try opening the options list and select the undefined (None) option again. You can see that both valueChange and ngModelChange events are fired (see the timestamps below the mat-select).
You can try selecting any non-undefined option twice and observe the timestamps. You will see that the events are fired only once (after the first selection), but not again when you select the same option for the second time.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Issue occurs in both Chrome and IE on Win7. Not tested anywhere else.
Is there anything else we should know?
Probably not.

What's the status on this issue? Any chance it will be merged anytime soon?

Any update as I'm facing this issue as well.

I am struggling with the same issue right now.

Does anyone have a workaround for this issue until we have an official fix?

I solved this issue with additional checking
onChangeFilter(matSelectChange: MatSelectChange) {
if (JSON.stringify(this.filter) != JSON.stringify(this.lastFilter)) {
}
this.lastFilter = JSON.parse(JSON.stringify(this.filter));
}
so I have to remember the last state of my filter and then compare it with new one. If there is difference I let pass executing further if there is no changes I just skip this invocation.
It works perfectly for me.

Thanks!
I used this flag to bypass this problem:

'event.isUserInput'

Template
<mat-select placeholder="Assign Order"
       formControlName="selectFormControl">
      <mat-option (onSelectionChange)="assignOrder($event)">None</mat-option>
      <mat-option *ngFor="let u of users" [value]="u
           (onSelectionChange)="assignOrder($event)">{{u.value}}</mat-option>
</mat-select>

TS
assignOrder($event){
  if (event.isUserInput) {
    // Do what you want here. This will be invoked only once!
  }
}

Is there any thing new with this issue? Every other work around isn't really a solution.

Is there any thing new with this issue? x2

I develop this work around (I'm was working with forms too so...), setting the value to undefined to reset the mat-select.
HTML
<mat-form-field>
          <mat-label>Add roles</mat-label>
          <mat-select formControlName="rolesFormCtrlStepper3" (selectionChange)="createRole($event.value)">
                <mat-option *ngFor="let roleComboBox of rolesComboBox" [value]="roleComboBox">
                             {{roleComboBox}}
                </mat-option>
           </mat-select>
</mat-form-field>

TS
createRole(r) {
...
...
    this.formArray.get([2]).get('rolesFormCtrlStepper3').setValue(undefined);
}


Heading of "Sharpen Your Skills" is not in similarity with others

Describe the bug
The heading of "Sharpen Your Skills" is not looking in line with others, the font size is less and not bold enough in comparison to others.
Possible solution
Match the css
Screenshots

If applicable, add screenshots to help explain your problem.

Go ahead @MonalikaKapoor


Remove mock contract from test

Let's start removal from test ;)

Coverage remained the same at 29.402% when pulling dbece4ec9420ba8e237c54398b2b967c8e62a663 on qingweibinary:qingwei/rm_mock_contract into 3485f5d2e2401cfb21560495f9551f91a4cbfa61 on binary-com:master.

👍


[ROX-13400] : Add RoleBindings search options to subject's search options

Description
The subjects on backend are resolved by querying the roleBindings datastore and then building a set of subjects from the results. Since any passed query is actually passed to roleBIndings datastore, we can add search options for RoleBindings to subjects' search options.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/test gke-postgres-qa-e2e-tests


Document site https://material-ui.com/ resolve as plain text.

When request to site https://material-ui.com/ resolve as plain text. Even v4 preview fails: https://next--material-ui.netlify.com/

Please include browser and OS version. Might also be an issue with the netlify CDN.


enhancement optimize the histogram bucketing strategy, etc

Proposed changes
The "equal height" histogram will ensure that the sum of the frequencies of the values in each bucket is 1/N of the total number of rows.
However, strictly adhering to the principle of "equal height" for bucketing will cause some values to fall out of the boundary of the bucket, resulting in the same value appearing in two different buckets. Obviously, this will interfere with the estimation of selectivity.
So this PR has made certain modifications to it in the implementation (implemented by an algorithm):

If adding a value to a bucket would cause the data in the bucket to occur more frequently than 1/N of the total number of rows, then put the value into that bucket or the next bucket, depending on which is closer to 1/N.

Others:

Optimize the time-consuming part of the operator, and improve the performance.
Removed the sampling parameter in the operator (this can be done using SAMPLE in the query).

Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[x] Has unit tests been added
[x] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildal

run buildall

@morrySnow @Kikyou1997 review plz.

run buildall

run buildall

run feut

run p0

run buildall

run buildall

run buildall

We'd better pesistence the histogram's bucekts in another structure rather than VARCHAR, it's very likely that the length of json string of buckets info exceeds 65533 characters.


[test-framework] integrate local registry support with test framework

There is an ongoing work to integrate local-registry support to the existing test framework.
We also need the same integration to happen with the new test framework.
The PR for the current test-framework is here: https://github.com/istio/istio/pull/5855
In addition, the image loading/resolution algorithm when installing the image should work as follows:

If nothing is specified, use local changes/bits with local registry
Allow override of individual images from the command line.

@sebastienvas does any of your recent work apply here? Would you be willing to take this on?

yes on it.

I believe this is made obsolete by our use of kind. We just directly load the docker images, there is no registry required at all. If I misunderstand then feel free to reopen

@howardjohn are we using kind for everything now? Or are there still jobs running on gke directly?

all integration tests are on kind and have been for a month or so. The only e2e jobs are multicluster and dashboard - just because they need some more effort, I am planning on moving them over as well

ok sounds good ... yeah, closing this makes sense.


x/build: sharded iOS builders

Currently, the android/amd64 and android/386 builders run on an Android emulator with a amd64 system image. This is taxing the heavyly loaded mobile builder Mac Mini. It is also inefficient: the emulator builds competes with Android device builds and any concurrent iOS builds. Because builds are slow, android is not in the trybot set, leaving me to often pester CL authors with "this CL broke android".
Is it possible to add (and run) the Android emulator inside the existing docker images used for regular builders and then run android sharded tests as any other GOOS? If so, android/amd64 and android/386 builds would complete much faster, and take some pressure off the mobile device builder.
If the emulator builds are stable enough, android/amd64 (and perhaps android/386) could even join the trybot set, avoiding most (if not all) android specific followup work after a CL is submitted.

This issue is about Android, but in theory the same could be done for the iOS simulator.

CC @bradfitz @andybons

This
https://paulemtz.blogspot.dk/2013/05/android-testing-in-headless-emulator.html
seems to indicate that the standard emulator supports headless mode.

Sure, prepare a Docker image that lets us do the traditional make.bash, then snapshot, then clone to several mirrors, then run tests one-at-a-time.
It'll require some tweaking of the build system probably, but I'll do those parts if you do the bulk of the work in preparing the Dockerfile.

seems to indicate that the standard emulator supports headless mode.

headless helps but isn't required. Worst case we could run a headless X server so it thinks it has a window.

The following Dockerfile
# Copyright 2014 The Go Authors. All rights reserved.
# Use of this source code is governed by a BSD-style
# license that can be found in the LICENSE file.

Let me know how to proceed.

The 3 CLs are now submitted.

Ping @bradfitz

Sorry, I realistically won't be able to get to start on this until April 1st. I'm preparing for an upcoming Gophercon talk this weekend, traveling next week for the talk, and then on vacation the last week of March.
I might be able to work on this next week from Moscow, but no promises.
@andybons has been wanting to learn how this whole system works more, so this might be a good "starter project" for adding a builder.
BTW, I forgot to ask earlier: how long does this all take? I imagine sharding is necessary for being a trybot, but is your goal for it to be a trybot right away, or just to have it run on GCE by us in Kubernetes? If it's easier, we could skip sharding for the first version.
But I'm also fine with sharding for the first version, but curious about timing. I imagine make.bash is still fast like always (1 minute or less), but then how long are the various tests?

Sorry, I realistically won't be able to get to start on this until April 1st. I'm preparing for an upcoming Gophercon talk this weekend, traveling next week for the talk, and then on vacation the last week of March.

No problem at all. My ping was just as much to see if the Docker image was enough.

BTW, I forgot to ask earlier: how long does this all take? I imagine sharding is necessary for being a trybot, but is your goal for it to be a trybot right away, or just to have it run on GCE by us in Kubernetes? If it's easier, we could skip sharding for the first version.

My wishlist ordered by importance:

Run emulated android/386 and android/amd64 builder on GCE (non-sharded or sharded, whatever is convenient for you). That will take a good amount of load off the strained mac mini that runs all mobile builders today. Also, it will ensure a builder is running if the mini is down which happens from time to time.
Use the GCE builder to run the gomobile subrepository tests. There is no meaningful automatic testing for gomobile today, so this would be a great way to get some coverage there.
Android trybot builders, to catch any Android specific issues with CLs before they're submitted.

(And in the future: 4. Do 1-3 for a darwin builder running an 386/amd64 iOS emulator.)
In other words, "just" a regular non-sharded builder on GCE would make me very grateful.

But I'm also fine with sharding for the first version, but curious about timing. I imagine make.bash is still fast like always (1 minute or less), but then how long are the various tests?

On my i7-6700K@4GHz with 32GB memory with a running Android 8 x86_64 emulator, ./androidtest.bash takes ~2min and ./all.bash on the same machine takes ~3min.
BTW, I'm not even sure trybots can be stable enough before #23795 is fixed. You wouldn't happen to know someone to ping for the corresponding adb bug, https://issuetracker.google.com/issues/73230216 ?

Gentle ping. If I can do anything to help this, please let me know.

I've been focused on vgo reviews and bugs (since that's fairly urgent for keeping 1.11 on schedule). I plan to get back to this after the 1.11 release, but if anybody else would like to take it before then you're welcome to it.

@eliasnaur, this is ready from my side if you want to give me a Docker image that uses the Android SDK + emulator (which can now use KVM on our buildlets) to run tests.

Is the one from https://github.com/golang/go/issues/23824#issuecomment-365800874 good enough?

Oh right. Forgot about that. I'll try.

@eliasnaur,
Step 8/14 : RUN yes | /android/sdk/tools/bin/sdkmanager --licenses      && /android/sdk/tools/bin/sdkmanager ndk-bundle "system-images;android-26;google_apis;x86_64"       && /android/sdk/tools/bin/sdkmanager "build-tools;21.1.2" "platforms;android-19"        && /android/sdk/tools/bin/sdkmanager --update
 ---> Running in 1288386ab097
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
        at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
        at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
        at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
        at com.android.sdklib.tool.SdkManagerCli.main(SdkManagerCli.java:117)
        at com.android.sdklib.tool.SdkManagerCli.main(SdkManagerCli.java:93)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 5 more
The command '/bin/sh -c yes | /android/sdk/tools/bin/sdkmanager --licenses      && /android/sdk/tools/bin/sdkmanager ndk-bundle "system-images;android-26;google_apis;x86_64"       && /android/sdk/tools/bin/sdkmanager "build-tools;21.1.2" "platforms;android-19"        && /android/sdk/tools/bin/sdkmanager --update' returned a non-zero code: 1

I updated the Dockerfile and run-emulator.sh script, please try again. Changes:

Replaced default-jdk with openjdk-8-jdk in Dockerfile to make sdkmanager run.
Removed the prebuilding of the NDK toolchains from run-emulator.sh and updated the androidtest.bash instructions to use the builtin prebuilt toolchains introduced in NDK r19b.
Updated Gradle to 5.2.1 in the Dockerfile since the old one was no longer supported by gomobile.

I've created CL 163377 to fix a gomobile test failure with jdk8, and I'm working on another CL to make gomobile use the prebuilt NDK toolchains so that the gomobile init step can go away.
Thank you for working on this.

I updated the Dockerfile and run-emulator.sh script, please try again. Changes:

Replaced default-jdk with openjdk-8-jdk in Dockerfile to make sdkmanager run.
Removed the prebuilding of the NDK toolchains from run-emulator.sh and updated the androidtest.bash instructions to use the builtin prebuilt toolchains introduced in NDK r19b.
Updated Gradle to 5.2.1 in the Dockerfile since the old one was no longer supported by gomobile.

I've created CL 163377 to fix a gomobile test failure with jdk8, and CL 163378 so the gomobile init step can go away.
Thank you for working on this.

I'm running it locally as a test.
I notice that when androidtest.bash is still doing the make.bash phase, the Android qemu process is successfully using KVM (great) but is also using 200% CPU and I haven't even started sending it tests yet because make.bash is still running. What is the emulator doing early on? Animating some live wallpaper or something? Anything we can do to reduce unnecessary CPU usage to make the build & tests faster?

I'm not sure. There is an emulator flag, -no-boot-anim that disable animation for faster boot, but I assumed -no-window already effectively did that.

Performance isn't bad, btw... 9.5 minutes on my dev machine.
We'll need to figure out where/when to run run-emulator.
I imagine we'll want to start the emulator before make.bash runs, so it can finish booting while make.bash finishes, and then we'll run the:
/android/sdk/platform-tools/adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;'

... before we start running tests.
Does that sound right?
Should all that logic go into androidtest.bash? But that doesn't help us get to sharded builders, if the goal is still to be trybots (5 minute total goal). So perhaps the logic of starting an emulator & waiting for an emulator needs to be in the coordinator, because each sharded buildlet will need its own emulator.
But to start, it'd probably be easier just to move that into androidtest.bash for phase 1 of this bug (moving to GCE w/ KVM). Could you send a change to make androidtest.bash do that, conditional on some new environment variable?

That sounds about right.
Why not always wait-for-device/shell in androidtest.bash?

I created a Dockerfile (and run-emulator.sh) variant that

Avoids the google apis in the emulator system image. Saves some space and perhaps bootup time.
Create the emulator instance inside Dockerfile. Wastes some image space, but might boot faster.

I wanted to also run the emulator once for warm up, but it seems kvm is not enabled at docker build time.

Added -no-boot-anim.

https://gist.github.com/eliasnaur/facb204db915a2adba60b5cd9445dd1b

FWIW, here's a Dockerfile that uses a pre-warmed emulator instance: https://gist.github.com/eliasnaur/b9bfc7c619738e78009d5f875e11142d. To create android-avd.avd and android-avd-ini:

run run-emulator.sh on the host machine. You probably need to run many of steps from the Dockerfile first.
Change "/home/" to "/root" in anvoid-avd.ini so it looks like this:

avd.ini.encoding=UTF-8
path=/root/.android/avd/android-avd.avd
path.rel=avd/android-avd.avd
target=android-26

I see it takes 1m11s to run run-emulator.sh. I imagine that'll parallelize nicely with make.bash.
I just ran the amd64 build again with the new Dockerfile and it's still 9.5 minutes (or just under: 9:26.22elapsed).
But preparing the emulator image in the Dockerfile is good. No need to do it for each build.
To move to a sharded world we'll need to do make.bash first and then running tests over N machines. That means androidtest.bash will likely be copied/gutted/moved elsewhere. Perhaps into the go_android_exec.
Of the 9.5 minutes, 3 minutes are the make.bash part, 30 seconds are adb sync. So 6 minutes for tests. If we had 3 shards, that's ~2 minutes each, so 3.5+2 minutes = 5.5 minutes and they could be a trybot.
root@57e6dfecd4fb:/go-tip/src# export PATH=$PATH:/android/sdk/platform-tools; GOROOT_BOOTSTRAP=/go1.4 CC_FOR_TARGET=/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android26-clang GOARCH=amd64 GOOS=android CGO_ENABLED=1 time ./make.bash --no-banner
Building Go cmd/dist using /go1.4.
Building Go toolchain1 using /go1.4.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for host, linux/amd64.
Building packages and commands for target, android/amd64.
394.83user 41.92system 3:01.99elapsed 239%CPU (0avgtext+0avgdata 1104028maxresident)k
7752inputs+1902944outputs (29major+8290732minor)pagefaults 0swaps

I suspect we could move all the "Push GOROOT to target device." part of androidtest.bash into ../misc/android/go_android_exec.go
Then we should be able to do just do make.bash followed by go tool dist test and the sync-to-device part will happen lazily on the first test.
Also, we should probably do the:
GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH go build \
        -o ../bin/go_android_${GOARCH}_exec \
        ../misc/android/go_android_exec.go

... part of androidtest.bash in the Dockerfile, so that binary just exists in our $PATH, rather than needing to build it in androidtest.bash.
Thoughts?

FWIW, here's a Dockerfile that uses a pre-warmed emulator instance:
...
To create android-avd.avd and android-avd-ini:
..

run run-emulator.sh on the host machine.

Why can't that go in the Dockerfile? I'm not going to do things by hand on the host. And I'm not installing Java or Android SDK on the host.

FWIW, here's a Dockerfile that uses a pre-warmed emulator instance:
...
To create android-avd.avd and android-avd-ini:
..

run run-emulator.sh on the host machine.

Why can't that go in the Dockerfile? I'm not going to do things by hand on the host. And I'm not installing Java or Android SDK on the host.

Because docker build doesn't run with kvm enabled, so the warm up run of the emulator fails.
I solved the problem with docker commit: I used a Dockerfile that only created the emulator, then ran
sudo docker run --privileged -it <image> /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 100
to run the emulator through boot before shutting down again. Then docker commit <container> to create a new image with a warm boot enabled emulator.

I suspect we could move all the "Push GOROOT to target device." part of androidtest.bash into ../misc/android/go_android_exec.go
Then we should be able to do just do make.bash followed by go tool dist test and the sync-to-device part will happen lazily on the first test.

I don't see an easy way to do that without replicating adb sync that avoids copying data that already exist on a device. In other words, go_android_exec.go doesn't have a quick way to know whether to skip the sync.

Also, we should probably do the:
GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH go build \
        -o ../bin/go_android_${GOARCH}_exec \
        ../misc/android/go_android_exec.go

... part of androidtest.bash in the Dockerfile, so that binary just exists in our $PATH, rather than needing to build it in androidtest.bash.

I hope that won't be necessary. We'll lose testing of go_android_exec.go itself if we bake it  into the docker image.
Given the above, how about the other way around: androidtest.bash without the tests? "androidtest.sh --no-test" perhaps, and then run that instead of make.bash in the builder.

Because docker build doesn't run with kvm enabled, so the warm up run of the emulator fails.

Ah, thanks. And we can't do a super slow no-kvm warm-up in Docker and then use that image later with kvm, right? I recall @danderson talking about this  (in https://twitter.com/dave_universetf/status/1098158628857511936) but that was about suspend/resume, not between two different boots.

I don't see an easy way to do that without replicating adb sync that avoids copying data that already exist on a device

When I said "happen lazily", I meant we'd record outside of the emulator whether we'd run adb sync yet. Imagine some file $TMP/did-adb-sync that we touch once we've run it. And then cmd/dist test will check for that file and not adb sync if it exists.

I hope that won't be necessary. We'll lose testing of go_android_exec.go itself if we bake it into the docker image.

In that case, if that's a concern/goal, we should build it as part of make.bash. We can teach dist to compile it for GOOS=android builds during cmdbootstrap. That work?

Given the above, how about the other way around: androidtest.bash without the tests? "androidtest.sh --no-test" perhaps, and then run that instead of make.bash in the builder.

I want to make Android less unique. If we can get it down to just make.bash & cmd/dist test, then it works like everything else and sharding comes basically for free.
I'm even thinking we can have the buildlet binary do the emulator start-up too, so then nothing needs to know about that. It'll just be like a phone is attached.

Because docker build doesn't run with kvm enabled, so the warm up run of the emulator fails.

Ah, thanks. And we can't do a super slow no-kvm warm-up in Docker and then use that image later with kvm, right? I recall @danderson talking about this (in https://twitter.com/dave_universetf/status/1098158628857511936) but that was about suspend/resume, not between two different boots.

The emulator disables warm boot whenever the configuration or some flags change. Besides the error messages when I tried everything in the Dockerfile indicated that the emulator requires KVM for amd64 at least.

I don't see an easy way to do that without replicating adb sync that avoids copying data that already exist on a device

When I said "happen lazily", I meant we'd record outside of the emulator whether we'd run adb sync yet. Imagine some file $TMP/did-adb-sync that we touch once we've run it. And then cmd/dist test will check for that file and not adb sync if it exists.

Ok, but how will it know that the device files are current and not left over from a previous run? But see below.

I hope that won't be necessary. We'll lose testing of go_android_exec.go itself if we bake it into the docker image.

In that case, if that's a concern/goal, we should build it as part of make.bash. We can teach dist to compile it for GOOS=android builds during cmdbootstrap. That work?

Yes.

Given the above, how about the other way around: androidtest.bash without the tests? "androidtest.sh --no-test" perhaps, and then run that instead of make.bash in the builder.

I want to make Android less unique. If we can get it down to just make.bash & cmd/dist test, then it works like everything else and sharding comes basically for free.

I see. But then why not fold all of androidtest.bash into make.bash or cmd/dist? Perhaps with a flag (--prepare?) that is set by the builders and all.bash to avoid surprising users that only want a build.

I'm even thinking we can have the buildlet binary do the emulator start-up too, so then nothing needs to know about that. It'll just be like a phone is attached.

Great.

Ok, but how will it know that the device files are current and not left over from a previous run?

Our GCE-based builder VMs are fresh per build and get nuked after each build. So there is no previous run.
But even ignoring that, we could make make.bash delete that file so it'd work even on reused hosts.

I see. But then why not fold all of androidtest.bash into make.bash or cmd/dist?

We don't want everything in one place. We want the split make-vs-test phases (like everything else) which permits sharded tests. Then we could make Android be a trybot. The x/build/cmd/coordinator runs make.bash, does a snapshot, mirrors a snapshot to N VMs, and then runs tests across those N. If we support the make.bash phase as normal and the cmd/dist test phase like normal, then we get sharded tests for free.

to run the emulator through boot before shutting down again. Then docker commit <container> to create a new image with a warm boot enabled emulator.

great! I had forgotten about docker commit. I think that'll work great. Did you measure the start-up time of the emulator doing that?

Because docker build doesn't run with kvm enabled, so the warm up run of the emulator fails.

Ah, thanks. And we can't do a super slow no-kvm warm-up in Docker and then use that image later with kvm, right? I recall @danderson talking about this (in https://twitter.com/dave_universetf/status/1098158628857511936) but that was about suspend/resume, not between two different boots.

Between two different boots should work, that's just a change in the virtual hardware, which the disk won't notice. Your warmup will be 4-10x slower in pure user emulation, depending on what you're doing.

I don't see an easy way to do that without replicating adb sync that avoids copying data that already exist on a device

When I said "happen lazily", I meant we'd record outside of the emulator whether we'd run adb sync yet. Imagine some file $TMP/did-adb-sync that we touch once we've run it. And then cmd/dist test will check for that file and not adb sync if it exists.

I hope that won't be necessary. We'll lose testing of go_android_exec.go itself if we bake it into the docker image.

In that case, if that's a concern/goal, we should build it as part of make.bash. We can teach dist to compile it for GOOS=android builds during cmdbootstrap. That work?

Given the above, how about the other way around: androidtest.bash without the tests? "androidtest.sh --no-test" perhaps, and then run that instead of make.bash in the builder.

I want to make Android less unique. If we can get it down to just make.bash & cmd/dist test, then it works like everything else and sharding comes basically for free.
I'm even thinking we can have the buildlet binary do the emulator start-up too, so then nothing needs to know about that. It'll just be like a phone is attached.

Between two different boots should work, that's just a change in the virtual hardware, which the disk won't notice. Your warmup will be 4-10x slower in pure user emulation, depending on what you're doing.

It sounds like the Android emulator (wrapper around qemu) requires KVM, even if qemu doesn't.

Between two different boots should work, that's just a change in the virtual hardware, which the disk won't notice. Your warmup will be 4-10x slower in pure user emulation, depending on what you're doing.

It sounds like the Android emulator (wrapper around qemu) requires KVM, even if qemu doesn't.

This is the error I get if I include the warm up command in the Dockerfile:
emulator: ERROR: x86_64 emulation currently requires hardware acceleration!
Please ensure KVM is properly installed and usable.
CPU acceleration status: /dev/kvm is not found: VT disabled in BIOS or KVM kernel module not loaded

to run the emulator through boot before shutting down again. Then docker commit <container> to create a new image with a warm boot enabled emulator.

great! I had forgotten about docker commit. I think that'll work great. Did you measure the start-up time of the emulator doing that?

With the pre-warmed emulator (12.2 GB docker image) created with docker commit:
$ time sudo docker run --rm --privileged -it dfccdbafbc02 /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 200
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
emulator: Cold boot: different AVD configuration
Your emulator is out of date, please update by launching Android Studio:
 - Start Android Studio
 - Select menu "Tools > Android > SDK Manager"
 - Click "SDK Tools" tab
 - Check "Android Emulator" checkbox
 - Click "OK"

emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 7079 ms

real	0m52,134s
user	0m0,021s
sys	0m0,034s

Without warm boot (9.6 GB docker image):
$ time sudo docker run --rm --privileged -it 3d1aeceaeb3a /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 200
Couldn't statvfs() path: No such file or directory
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
Your emulator is out of date, please update by launching Android Studio:
 - Start Android Studio
 - Select menu "Tools > Android > SDK Manager"
 - Click "SDK Tools" tab
 - Check "Android Emulator" checkbox
 - Click "OK"

emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 17271 ms

real	1m1,979s
user	0m0,019s
sys	0m0,023s

So a bit faster with warm boot.

@bradfitz , CLs 163619 and 163618 should implement your suggestions. The only magic thing left for Android (and iOS) is that the exec wrapper needs to be in PATH. Perhaps the go tool should look for the exec wrapper in GOROOT/bin and/or GOBIN if PATH doesn't contain any?

I did the docker commit thing, but I'm seeing it take 20 seconds later to use the warm image rather than the base pre-commit image:
Here I build golang/android, then run the emulator in it with docker run --privileged, commit it as golang/android-warm, and then time re-starting the emulator in both the original image vs the warm image. The warm image seems to take 1m40s and the original is 1m20s-ish.
Am I missing a step?
bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ docker build --tag=golang/android .
...
Successfully built f06b8bc59234
Successfully tagged golang/android:latest

bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ docker run --privileged -it golang/android /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 100
Couldn't statvfs() path: No such file or directory
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
Your emulator is out of date, please update by launching Android Studio:
 - Start Android Studio
 - Select menu "Tools > Android > SDK Manager"
 - Click "SDK Tools" tab
 - Check "Android Emulator" checkbox
 - Click "OK"

emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 75431 ms

bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS               NAMES
2a03a697a8ff        golang/android      "/android/sdk/emulat…"   About a minute ago   Exited (0) 30 seconds ago                       unruffled_neumann
....

bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ docker commit 2a03a697a8ff golang/android-warm
sha256:314bb914743d041d6366415b2078264c53ed1718d5ae880e795059e600ac8da5

bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ time docker run --privileged -it golang/android-warm /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 100
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
emulator: ERROR: fail to boot after 100 seconds, quit
emulator: Saving state on exit with session uptime 97567 ms

real    1m41.658s
user    0m0.084s
sys     0m0.016s
bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ time docker run --privileged -it golang/android /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 100
Couldn't statvfs() path: No such file or directory
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
Your emulator is out of date, please update by launching Android Studio:
 - Start Android Studio
 - Select menu "Tools > Android > SDK Manager"
 - Click "SDK Tools" tab
 - Check "Android Emulator" checkbox
 - Click "OK"

emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 74576 ms

real    1m19.830s
user    0m0.092s
sys     0m0.020s

bradfitz@gdev:~/src/golang.org/x/build/env/android-amd64$ time docker run --privileged -it golang/android-warm /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 100
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
emulator: ERROR: fail to boot after 100 seconds, quit
emulator: Saving state on exit with session uptime 98278 ms

real    1m42.308s
user    0m0.088s
sys     0m0.024s

That's essentially the same thing I did so I don't think you missed a step. I did get some strange timings the first few times I ran the warm image; it took longer for the emulator to start but it booted faster. Perhaps docker is doing something slow with the image data?
Also your warm image timing is actually worse than what you see. The -quit-after-boot flag takes a number of seconds to wait for boot (100 in your case), and the emulator failed to boot in that time: emulator: ERROR: fail to boot after 100 seconds, quit

Perhaps we should start with the simpler cold booted emulator? Even if your timings eventually match mine, it might not apply to GCE.

My dev instance is also on GCE, on the same VM types.
So the warm boot isn't even working it seems. Can you investigate that while I finish up the buildlet & Dockerfile & dashboard/builders.go configuration? (I'll be sending that to you soon here.)

I'm on my own machine, not on GCE :) So I think that's a pretty good indication that warm booting is not a net win. The extra time probably goes to fetching the extra ~3GB of Docker image across the network.

Why should warm booting be slower, though?
Presumably it's faster on a developer's desktop, so why isn't it faster for us? In this case I have all the images pulled locally, so network isn't a concern. And we'll have these Docker files pre-baked into the image whose block device is lazily read over the super fast network anyway, so Dockerfile size isn't really a concern here.

Why should warm booting be slower, though?
Presumably it's faster on a developer's desktop, so why isn't it faster for us? In this case I have all the images pulled locally, so network isn't a concern. And we'll have these Docker files pre-baked into the image whose block device is lazily read over the super fast network anyway, so Dockerfile size isn't really a concern here.

I don't know. And now I can't even reproduce my numbers above.
Warm boot attempts:
1m17,427s
1m15,680s
1m12,846s
1m15,234s
Cold boot attempts:
1m12,414s
1m36,328s
1m29,003s
1m10,898s
Cold boot times vary quite a bit and is even faster than warm boot sometimes.
In an attempt to optimize the image I tried to docker export and then docker import the warm boot container, but that made it much worse and similar to your warm boot case.
$ docker run --privileged -it warmboot /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 200
$ docker container ls --all
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                     PORTS               NAMES
8d026f942a82        warmboot            "/android/sdk/emul..."   3 minutes ago       Exited (0) 2 minutes ago                       hopeful_liskov
$ docker export 8d026f942a82 > warmboot.tar
$ docker import warmboot.tar :warmboot-import
$ time docker run --rm --privileged -it warmboot-import /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 200
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
emulator: ERROR: fail to boot after 200 seconds, quit
emulator: Saving state on exit with session uptime 181916 ms
0.02user 0.00system 3:22.36elapsed 0%CPU (0avgtext+0avgdata 18580maxresident)k
0inputs+0outputs (0major+1808minor)pagefaults 0swaps
```

Compare that to emulator runs from my host machine:
$ time emulator @android27 -no-window -no-boot-anim -quit-after-boot 200
Couldn't statvfs() path: No such file or directory
Your emulator is out of date, please update by launching Android Studio:
 - Start Android Studio
 - Select menu "Tools > Android > SDK Manager"
 - Click "SDK Tools" tab
 - Check "Android Emulator" checkbox
 - Click "OK"

emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 12187 ms

real	0m13,183s
user	0m19,371s
sys	0m2,603s

13 seconds is much better. Weird. I wonder what's going wrong within Docker.

Can we get more verbose logs out of it?

FWIW, I can get closer to my host timing by warming up the Docker container:
$ docker run --rm --privileged -it cold /bin/bash
[sudo] password for elias:
root@7775accc64eb:/# time /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 200
Couldn't statvfs() path: No such file or directory
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
Your emulator is out of date, please update by launching Android Studio:
 - Start Android Studio
 - Select menu "Tools > Android > SDK Manager"
 - Click "SDK Tools" tab
 - Check "Android Emulator" checkbox
 - Click "OK"

emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 17154 ms

real	1m4.910s
user	0m14.057s
sys	0m4.621s
root@7775accc64eb:/# time /android/sdk/emulator/emulator @android-avd -no-window -no-boot-anim -quit-after-boot 200
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
^Cemulator: Saving state on exit with session uptime 51646 ms

real	0m51.995s
user	0m4.143s
sys	0m1.630s
root@7775accc64eb:/# time /android/sdk/emulator/emulator @android-avd -wipe-data -no-window -no-boot-anim -quit-after-boot 200
Couldn't statvfs() path: No such file or directory
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 17304 ms

real	0m31.853s
user	0m13.885s
sys	0m4.415s
root@7775accc64eb:/# time /android/sdk/emulator/emulator @android-avd -wipe-data -no-window -no-boot-anim -quit-after-boot 200
Couldn't statvfs() path: No such file or directory
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: Connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
emulator: INFO: boot completed
emulator: Saving state on exit with session uptime 17136 ms

real	0m32.429s
user	0m15.675s
sys	0m4.477s

Note that -wipe-datawas needed to avoid a hang on the second window-less run.

I found this on the slowness of Docker's loopback mounted disks: https://github.com/moby/moby/issues/21485

I found this on the slowness of Docker's loopback mounted disks: moby/moby#21485

Are we loopback mounting anything, though?
In any case, I can get it down to 36 seconds with:
root@3a11990d0b49:/# time /android/sdk/emulator/emulator @android-avd -no-audio -no-window -no-boot-anim -no-sim -quit-after-boot 200
...
(builds snapshot)
...

Then:

root@3a11990d0b49:/# time /android/sdk/emulator/emulator @android-avd -no-audio -no-window -no-boot-anim -quit-after-boot 200 -no-snapshot-save -show-kernel -no-sim
...
emulator: INFO: boot completed
emulator: WARNING: Not saving state: RAM not mapped as shared

real    0m36.144s
user    0m44.888s
sys     0m23.976s

Haven't yet tried to docker commit the first step, though.

Getting closer. I almost have all the pieces done.
Testing it all out now,
FAIL    crypto/tls      0.002s
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;: exec: "adb": executable file not found in $PATH
FAIL    crypto/x509     0.002s
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;: exec: "adb": executable file not found in $PATH
FAIL    database/sql    0.006s
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;: exec: "adb": executable file not found in $PATH
FAIL    database/sql/driver     0.002s
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;: exec: "adb": executable file not found in $PATH
FAIL    debug/dwarf     0.002s
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;: exec: "adb": executable file not found in $PATH

Few little config things missing it appears.

Works now.
bradfitz@gdev:~/src/golang.org/x/build$ debugnewvm --host=host-android-amd64-emu -run-build=android-amd64-emu
...
....
##### ../misc/cgo/testasan
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb shell mkdir -p /data/local/tmp/main-1465
go_android_exec: adb shell mkdir -p /data/local/tmp/goroot/misc/cgo/testasan
go_android_exec: adb push /workdir/tmp/go-build746649494/b001/exe/main /data/local/tmp/main-1465/main-1465
[  5%] /data/local/tmp/main-1465/main-1465
[ 10%] /data/local/tmp/main-1465/main-1465
[ 15%] /data/local/tmp/main-1465/main-1465
[ 21%] /data/local/tmp/main-1465/main-1465
[ 26%] /data/local/tmp/main-1465/main-1465
[ 31%] /data/local/tmp/main-1465/main-1465
[ 37%] /data/local/tmp/main-1465/main-1465
[ 42%] /data/local/tmp/main-1465/main-1465
[ 47%] /data/local/tmp/main-1465/main-1465
[ 53%] /data/local/tmp/main-1465/main-1465
[ 58%] /data/local/tmp/main-1465/main-1465
[ 63%] /data/local/tmp/main-1465/main-1465
[ 69%] /data/local/tmp/main-1465/main-1465
[ 74%] /data/local/tmp/main-1465/main-1465
[ 79%] /data/local/tmp/main-1465/main-1465
[ 85%] /data/local/tmp/main-1465/main-1465
[ 90%] /data/local/tmp/main-1465/main-1465
[ 95%] /data/local/tmp/main-1465/main-1465
[100%] /data/local/tmp/main-1465/main-1465
/workdir/tmp/go-build746649494/b001/exe/main: 1 file pushed. 77.5 MB/s (1232413 bytes in 0.015s)
go_android_exec: adb shell export TMPDIR="/data/local/tmp/main-1465"; export GOROOT="/data/local/tmp/goroot"; export GOPATH="/data/local/tmp/gopath"; cd "/data/local/tmp/goroot/misc/cgo/testasan"; '/data/local/tmp/main-1465
/main-1465' ; echo -n exitcode=$?
exitcode=0go_android_exec: adb shell rm -rf /data/local/tmp/main-1465

##### ../misc/cgo/testsigfwd
go_android_exec: adb wait-for-device shell while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;
go_android_exec: adb shell mkdir -p /data/local/tmp/main-1653
go_android_exec: adb shell mkdir -p /data/local/tmp/goroot/misc/cgo/testsigfwd
go_android_exec: adb push /workdir/tmp/go-build400298215/b001/exe/main /data/local/tmp/main-1653/main-1653
[  3%] /data/local/tmp/main-1653/main-1653
[  6%] /data/local/tmp/main-1653/main-1653
[  9%] /data/local/tmp/main-1653/main-1653
[ 12%] /data/local/tmp/main-1653/main-1653
[ 15%] /data/local/tmp/main-1653/main-1653
[ 18%] /data/local/tmp/main-1653/main-1653
[ 22%] /data/local/tmp/main-1653/main-1653
[ 25%] /data/local/tmp/main-1653/main-1653
[ 28%] /data/local/tmp/main-1653/main-1653
[ 31%] /data/local/tmp/main-1653/main-1653
[ 34%] /data/local/tmp/main-1653/main-1653
[ 37%] /data/local/tmp/main-1653/main-1653
[ 41%] /data/local/tmp/main-1653/main-1653
[ 44%] /data/local/tmp/main-1653/main-1653
[ 47%] /data/local/tmp/main-1653/main-1653
[ 50%] /data/local/tmp/main-1653/main-1653
[ 53%] /data/local/tmp/main-1653/main-1653
[ 56%] /data/local/tmp/main-1653/main-1653
[ 60%] /data/local/tmp/main-1653/main-1653
[ 63%] /data/local/tmp/main-1653/main-1653
[ 66%] /data/local/tmp/main-1653/main-1653
[ 69%] /data/local/tmp/main-1653/main-1653
[ 72%] /data/local/tmp/main-1653/main-1653
[ 75%] /data/local/tmp/main-1653/main-1653
[ 79%] /data/local/tmp/main-1653/main-1653
[ 82%] /data/local/tmp/main-1653/main-1653
[ 85%] /data/local/tmp/main-1653/main-1653
[ 88%] /data/local/tmp/main-1653/main-1653
[ 91%] /data/local/tmp/main-1653/main-1653
[ 94%] /data/local/tmp/main-1653/main-1653
[ 98%] /data/local/tmp/main-1653/main-1653
[100%] /data/local/tmp/main-1653/main-1653
/workdir/tmp/go-build400298215/b001/exe/main: 1 file pushed. 114.1 MB/s (2069533 bytes in 0.017s)
go_android_exec: adb shell export TMPDIR="/data/local/tmp/main-1653"; export GOROOT="/data/local/tmp/goroot"; export GOPATH="/data/local/tmp/gopath"; cd "/data/local/tmp/goroot/misc/cgo/testsigfwd"; '/data/local/tmp/main-1653/main-1653' ; echo -n exitcode=$?
exitcode=0go_android_exec: adb shell rm -rf /data/local/tmp/main-1653

ALL TESTS PASSED
---
Installed Go for android/amd64 in /workdir/go
Installed commands in /workdir/go/bin
2019/02/27 22:42:23 ran src/androidtest.bash in 8m18s
2019/02/27 22:42:23 done.
2019/02/27 22:42:25 SERIAL: Feb 27 22:42:24 debug-temp-1551306784 containerd[677]: time="2019-02-27T22:42:24.295592684Z" level=info msg="shim reaped" id=aa181c26866f80366f38706e4509922d7db9e24af15ff9cbe64ff01e4bf954eb
                            Feb 27 22:42:24 debug-temp-1551306784 dockerd[675]: time="2019-02-27T22:42:24.305745697Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
                            Feb 27 22:42:24 debug-temp-1551306784 containerd[677]: time="2019-02-27T22:42:24.442179713Z" level=info msg="shim containerd-shim started" address="/containerd-shim/moby/aa181c26866f80366f38706e4509922d7db9e24af15ff9cbe64ff01e4bf954eb/shim.sock" debug=false pid=3208
bradfitz@gdev:~/src/golang.org/x/build$
bradfitz@gdev:~/src/golang.org/x/build$

Now that Android builders are on GCE and soon joining the trybot set (thank you Brad!), I wonder how far we can get with iOS. @bradfitz can we have Darwin hosts in the cloud with Xcode installed running iOS tests on the iPhone simulator? Even without sharding and trybots, having cloud builders is a major step up from the very slow (and impossible to gomote) device builders we have now.

@eliasnaur, I don't know what remains here (is it done? iOS stuff maybe?) so reassigning to you for now.

iOS builders, yes. You mentioned that your macstadium VMs might be improving enough for me to use them for iOS simulator builds. Now that we have Corellium virtual arm64 devices, iOS simulators are probably only interesting if we can have enough simulators to run trybots.

@bradfitz @eliasnaur Do you know if there are there known limitations on the android-amd64-emu builder type? I checked its notes in dashboard and it just says "Android emulator on GCE". Does it support filesystem reads/writes? Is gomote ssh supported?
I can't seem to ssh into a gomote instance, but maybe it's just not supported:

~ $ gomote create android-amd64-emu
user-dmitshur-android-amd64-emu-0
~ $ gomote ssh user-dmitshur-android-amd64-emu-0
$ ssh -p 2222<EMAIL_ADDRESS># auth using https://github.com/dmitshur.keys
# Welcome to the gomote ssh proxy, dmitshur.
# Connecting to/starting remote ssh...
#
failed to connect to ssh on user-dmitshur-android-amd64-emu-0: unexpected /connect-ssh response: 502 Bad Gateway, dial tcp [::1]:2200: connect: connection refused

Connection to farmer.golang.org closed.

Asking because there was a trybot failure that happens only on this trybot configuration, not others in CL 196321. /cc @ianthehat


Is that possible to change list plain text items into buttons, textbox, some other radio button,

Event check box as well.
The elements can be either in the original or in the dropped place.

It is..


WIP:add changelog github workflow action

What this PR does:
add changelog action
Which issue(s) this PR fixes:
#390

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

Codecov Report
Base: 35.96% // Head: 35.80% // Decreases project coverage by -0.15% :warning:

Coverage data is based on head (0ec5c33) compared to base (186a3f8).
Patch coverage: 1.60% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #451      +/-   ##
==========================================
- Coverage   35.96%   35.80%   -0.16%
==========================================
  Files         124      124
  Lines       19966    20032      +66
==========================================
- Hits         7180     7173       -7
- Misses      12000    12072      +72
- Partials      786      787       +1

Impacted Files
Coverage Δ

pkg/boot/discovery.go
42.56% <0.00%> (-0.44%)
:arrow_down:

pkg/config/api.go
80.00% <ø> (ø)

pkg/config/config.go
0.00% <ø> (ø)

pkg/config/default.go
85.71% <ø> (ø)

pkg/config/diff.go
10.37% <ø> (+0.04%)
:arrow_up:

pkg/config/equals.go
6.17% <ø> (+0.07%)
:arrow_up:

pkg/config/etcd/etcd.go
73.11% <ø> (-0.57%)
:arrow_down:

pkg/config/file/file.go
73.68% <ø> (-0.31%)
:arrow_down:

pkg/config/nacos/nacos.go
38.85% <ø> (+0.24%)
:arrow_up:

pkg/executor/redirect.go
4.93% <ø> (+0.02%)
:arrow_up:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[cxx-interop] Do not give the default C++ constructor's return statement a result.

The default C++ object constructor assigns the newly created object out of the function so, it should not return a value. Returning a value will trigger SILGen assertions.
Refs #32402.

@jckarter good idea, will do. Thanks.

@swift-ci please smoke test and merge.

@swift-ci please smoke test and merge.

@zoecarver Sorry for the late review, but could you adjust the test to have a stronger postcondition than just "does not crash"? Could you add a SILGen test that checks the actual SIL instructions in the body of the generated no-arg initializer in the test/Interop directory?

@zoecarver Another question is why is this issue only caught by assertions (I assume SIL verifier?) only for C++ types? Are we missing some SIL verifier checks?

Could you add a SILGen test that checks the actual SIL instructions in the body of the generated no-arg initializer in the test/Interop directory?

Sure. Will do.

Another question is why is this issue only caught by assertions (I assume AST or SIL verifier?) only for C++ types? Are we missing some AST or SIL verifier checks?

The assertion was only caught for C++ types because the issue with this constructor was only visible for address types. I'm not sure if there are any non-c++ address only types that are default constructible (and if so, we should make tests for them).

Also, for what it's worth, this crashed in SILGen IRC. If it had been able to generate the function, the SILVerifier probably would have errored.

The assertion was only caught for C++ types because the issue with this constructor was only visible for address types.

WDYM by "visible"? Is it valid to return () from an initializer for a loadable type? Shouldn't the AST verifier catch this problem regardless of whether the type is loadable or address-only?

Is it valid to return () from an initializer for a loadable type? Shouldn't the AST verifier catch this problem regardless of whether the type is loadable or address-only?

Hmm, I think you're right. It would make sense that the verifier should catch that sort of error. I'll make a patch to add a verifier check for this tomorrow.
Looking at it again, for a loadable C++ type, we sill generate a return statement with an empty tuple, but it looks like the SIL function actually does return a value. Any idea how that happens?

@zoecarver The conversion to indirect return is part of SILGen's job. The AST should still formally return a result, but because the type is not loadable when lowered to SIL, it should result in the SIL function getting an indirect return argument, and writing the result to that, instead of returning by value. If you've already modified SIL type lowering so that nontrivial C++ types are classified as address-only, then that should just work, and if it isn't, it sounds like we still have work to do to figure out why.

@jckarter my confusion is because in synthesizeStructDefaultConstructorBody we create an AssignExpr to initialize self and (unconditionally) emit a ReturnStmt with no result.

If you've already modified SIL type lowering so that nontrivial C++ types are classified as address-only, then that should just work, and if it isn't, it sounds like we still have work to do to figure out why.

Yes, currently everything works. I'm just curious as to why. It seems like what we maybe should have done is returned the call to zeroInitializer (address or not) and removed the assignment completely. That would let SILGen figure out what's the best course of action (either return the value directly or copy into an indirect result).

my confusion is because in synthesizeStructDefaultConstructorBody we create an AssignExpr to initialize self and (unconditionally) emit a ReturnStmt with no result.

To elaborate a bit: Assigning self out of the function seems like it shouldn't work but, it does. Especially for loadable structs, assigning one value type to another seems like it should have no effect in the worst case, and error in the best case. The reason this works is SILGen somehow figures out what we're trying to do is emit a return of the newly created object. I don't know much about SILGen so, I'm not sure if this is the conventional way to do things but, I suspect it's not.

It could be that the code path in synthesizeStructDefaultConstructorBody has not ever had to deal with address-only types in the past (which would make sense, because an empty struct in Swift would always be a trivial type), so we need to add those code paths now. You can look at how code generation for regular functions works to get a sense of how this is supposed to work, by comparing:
func foo(x: Int) -> Int { return x }

with
func bar(x: Any) -> Any { return x }

Since Int is a trivial loadable type, foo should accept its argument and return by value, but because Any is address-only, it will be loaded from memory and stored to the indirect return.

It could be that the code path in synthesizeStructDefaultConstructorBody has not ever had to deal with address-only types in the past.

I agree. It's likely it hasn't.
I'll create a new patch to update this function and similar ones to work with address types. When building the AST, we don't have to create a special path for address type, or do we? In other words, can I just create a ReturnStmt with the object and let SILGen figure out whether that can be returned directly or needs to be stored to the indirect return address? I'll give it a try and see what works.
Thanks for the help :)

When building the AST, we don't have to create a special path for address type, or do we?

Right -- at the AST level we don't even know whether the type is address-only or loadable, so the AST for the no-arg initializer should be identical between the two. My suggestion regarding the verifier seems to be relevant for the AST verifier then. If SILGen wants a specific shape of ReturnStmt in the AST for initializers of address-only types, but does not care about that detail for loadable types, we should still treat it as a universal invariant and always enforce it in the verifier.

Sorry for all the back and forth. I went to go make this change and I realized because of how the constructor body synthesizer works, we actually aren't allowed to directly create the return statement in the synthesizer function. So, I think the change this PR made is good.
I will add the AST verifier check, though.

@zoecarver Yeah, if we're able to make it so that the intended semantics of the initializer can be synthesized into the AST, then we should be able to allow SILGen to just do its thing lowering from a valid AST without special code.

@jckarter Sounds good. I think we're on the same page. That's how it works on TOT (after this PR) so, I don't think we need to make any changes, right?
Here's the added AST verifier check: #32656.


Custom script extension is not updating on existing instances in vmss

I have set custom script extension on the vmss using az command:
az vmss extension set --publisher Microsoft.Azure.Extensions --version 2.0 --name CustomScript --resource-group resource_group_name --vmss-name vmss_name --settings @./customConfig.json
customConfig.json
{
"fileUris": ["publiclinkoffile"],
"commandToExecute": "./filename"
}
I could see extension is set suceesfully but it is reflecting only on the newly scaled instances. It is not updating on the existing instances.
Attached logs of existing instance for reference.
/var/log/azure/custom-script/handler.log
``
/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.2/bin/custom-script-extension install
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 event=start
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 status="not reported for operation (by design)"
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 event="migrate to mrseq" error="Can't find out seqnum from /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.2/status, not enough files."
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 event="created data dir" path=/var/lib/waagent/custom-script
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 event=installed
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 status="not reported for operation (by design)"
time=2019-11-18T09:50:46Z version=v2.1.2/git@b73cc91-clean operation=install seq=1 event=end
Writing a placeholder status file indicating progress before forking: /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.2/status/1.status

nohup /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.2/bin/custom-script-extension enable
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=start
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=pre-check
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="comparing seqnum" path=mrseq
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="seqnum saved" path=mrseq
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="reading configuration"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="read configuration"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="validating json schema"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="json schema valid"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="parsing configuration json"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="parsed configuration json"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="validating configuration logically"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="validated configuration"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="creating output directory" path=/var/lib/waagent/custom-script/download/1
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="created output directory"
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 files=0
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="executing command" output=/var/lib/waagent/custom-script/download/1
time=2019-11-18T09:50:49Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="executing protected commandToExecute" output=/var/lib/waagent/custom-script/download/1
time=2019-11-18T09:51:23Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="executed command" output=/var/lib/waagent/custom-script/download/1
time=2019-11-18T09:51:23Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=enabled
time=2019-11-18T09:51:23Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=end
Not writing a placeholder status file, already exists: /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.2/status/1.status
nohup /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.2/bin/custom-script-extension enable
time=2019-11-18T10:32:01Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=start
time=2019-11-18T10:32:01Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=pre-check
time=2019-11-18T10:32:01Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event="comparing seqnum" path=mrseq
time=2019-11-18T10:32:01Z version=v2.1.2/git@b73cc91-clean operation=enable seq=1 event=exit message="this script configuration is already processed, will not run again"
``

@soumya6541, Thanks for leveraging Azure docs feedback channel!  We are taking a look into this and will get back to you soon. Could you also share the document to which this feedback is applicable to?

@soumya6541 do you have automatic OS upgrades enabled? If not, that is the issue. You will need to update each of the images of the VMSS instances when you make a change.
Otherwise, enable automatic OS image updates and it will apply to all the instances automatically.
https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade

@soumya6541, Thanks for leveraging Azure docs feedback channel! We are taking a look into this and will get back to you soon. Could you also share the document to which this feedback is applicable to?

https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-faq#if-the-extensions-associated-with-an-existing-virtual-machine-scale-set-are-updated-are-existing-vms-affected
Though I upgraded each instance manually the extension changes are not picked by existing instances in vmss.
However reimage of instance is worked! I hope it need to be added in the docs too.

@soumya6541 do you have automatic OS upgrades enabled? If not, that is the issue. You will need to update each of the images of the VMSS instances when you make a change.
Otherwise, enable automatic OS image updates and it will apply to all the instances automatically.
https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade

Upgrading is not working in my case. Reimaging of instance got worked.

Can I use reimaging of instances in production environment?

@soumya6541 for a production environment you should use upgrade in most cases. I have tested this multiple times and when I have Auto Upgrades enabled the Custom Script applies to all the instances.
From a doc perspective, it is correct.
I would suggest you reach out to Azure Support to dig in deeper as to what is not configured correctly in your environment. If you don't have the ability to open a technical support ticket, you can email me at<EMAIL_ADDRESS>and provide me with your SubscriptionID and Link to this issue and I can help enable that for you.
I will close this as there is no doc update needed but will keep an eye out for that email if needed.


Additional ANN methods

It would be nice to also have wrappers for

[x] annoy: https://github.com/spotify/annoy
[x] ONNG: https://github.com/yahoojapan/NGT/blob/master/README.md#onng
[x] Puffinn: https://github.com/puffinn/puffinn
[ ] PyNNdescent: https://github.com/lmcinnes/pynndescent (for custom metric support)
... ?

Added annoy in dev branch #21

Hi @VarIr
Many thanks for such great package!
I was wondering if you can include a wrapper for pyNNDescent at https://pynndescent.readthedocs.io/en/latest/api.html
Ivan

Glad to hear you find the package useful.
Do you have specific reasons to use NNdescent? Last time I checked it seemed to provide inferior results compared to the graph-based methods like HNSW and ONNG.

Hi @VarIr
Thanks for asking for my opinion.
I think that NNdescent offers something than other solutions do not have: the support of several metrics including custom metrics. This is aspect is very important for me. My data sets are in the form of n x d (where n >>> d, and d varies [7,12]). As you can see, I like to have a solution that allows me to test euclidean, manhattan, fractional or custom metrics to see which one will help me to deal with large amount of data in relative high dimensional space. And now, I started learning more about hubness and its impact. This is where your package will play an interesting role in the analysis that I conduct.
Ivan

Thanks for your input. Including support for custom dissimilarity measures seems worthwhile. Currently, most (all?) of the implemented methods at least support Euclidean and Manhattan distances.
I'll add nndescent to the list here. Unfortunately, I cannot give ETA, as I can work on this project only in spare time.

Thanks for considering pynndescent. In addition to support custom metrics, it also supports much more metrics than annoy package. For instance, the metric Minkowski with 0<p<1 seems to provide better results than Euclidean distance when working with high dimensional data

Yes, that's why skhubness allows fractional norms while sklearn doesn't. :)

Cool! I just need to be able to install this great package on my windows workstation (see incident #76 at https://github.com/VarIr/scikit-hubness/issues/67)

I tried to use a fractional norm with the following code:
from skhubness.data import load_dexter
from skhubness import Hubness
hub= Hubness(k= 10, return_value= 'all', metric= 'minkowski', algorithm= 'hnsw', algorithm_params= {'p': 0.1}, hubness= 'local_scaling', random_state= 1969, n_jobs= -1)
hub.fit(X)
which gave the error below:
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\IMarroquin\Downloads\Important_Python_Libraries_VisualBuildTools\scikit-hubness-master\skhubness\analysis\estimation.py", line 283, in fit
raise ValueError(f"Unknown metric '{metric}'. "
ValueError: Unknown metric 'minkowski'. Must be one of ['euclidean', 'cosine', 'precomputed'].
For hubness analysis, the package only supports three metrics

The next version v0.30 will see compatibility with sklearn's KNeighborsTransformer. Since PyNNDescent ships with its own wrapper to act as a KNeighborsTransformer, there is no need to roll an additional implementation of that. We can, thus, consider PyNNDescent supported.

Closing, as the original list of wrappers has been dealt with. Users with requests for any other additional approximate neighbor wrappers, please open a new issue for each algorithm separately. This helps me to keep overview of open tasks. Thank you.


Add a lua code based generator

If you add a lua based code generator it could make developers who want to make something from the lua language can find instructions to do something for ex: playing the og angry birds classic game,etc.

Hello @Parkway747 ,
Thank you for your suggestion.
Best Regards,
Jon


No module named 'prompt_toolkit.formatted_text'

Problem Description
No module named 'prompt_toolkit.formatted_text'
What steps reproduce the problem?

$ spyder
bug report textbox opens suggestion spyder --reset
$ spyder --reset
$ spyder
Go to step (1) above.

Also tried $pip  install prompt_toolkit but "Requirement already satisfied".
Should I switch to PyCharm?
What is the expected output? What do you see instead?
Spyder console expected to open but instead stdout " No module named 'prompt_toolkit.formatted_text'"
Paste Traceback/Error Below (if applicable)
File "C:\Users\user\anaconda3\lib\site-packages\IPython\terminal\interactiveshell.py", line 21, in
from prompt_toolkit.formatted_text import PygmentsTokens
ModuleNotFoundError: No module named 'prompt_toolkit.formatted_text'

PASTE TRACEBACK HERE

Versions

Spyder version: 3
Python version: 3.7.x
Qt version:
PyQt version:
Operating System name/version: Windows

Dependencies
N/A: can't open Spyder now

Hi @QuetzalcoatlRosso sorry to here that, seems like the env you are working on got corrupted some how. Please try to check our Troubleshooting Guide and FAQ to see if that helps you :)
Also, maybe the problem could be the version of prompt-toolkit you are using so you could try running something like pip install -U prompt-toolkit (which should update prompt-toolkit if it's already installed).
For now there is not much we can do in case like the one you are experiencing, sorry about that :/

thanks for the quick response! I appreciate it. will compare with pycharm.


Doesn't work on AMD

Hello,
I followed all of your steps and it doesn't work on AMD RX 6600. I even saw your youtube videos.
Please help.
Thanks,
JP

This is not a hardware specific issue.
Assuming that ZetaLoader is properly installed for the game's multiplayer, simply just enable Fullscreen in ZetaLoader's configuration file.
Check if the game is automatically is in borderless fullscreen and changing the Z-Order depending on the foreground window status.
If that's working then the problem whatever display mode, you are specifying.
What display mode are you specifying is it supported by your display?

I copied over dpapi.dll to the game folder. Then made a new text document and called it ZetaLoader.ini. Added in fullscreeen =1 and 1280x720 resolution and 60 hz refresh. Started the game and it still has the screen cutoff. 1280x720 is supported by my monitor and I play Hogwarts Legacy and CS2 with it.

Is ZetaLoader.ini in %LOCALAPPDATA%\HaloInfinite\Settings?
Assuming that it is, try to remove the width, height and frequency parameter as mentioned before and see if ZetaLoader just uses the default display mode.

I copied over dpapi.dll to the game folder. Then made a new text document and called it ZetaLoader.ini. Added in Fullscreen =1 and 1280x720 resolution and 60 hz refresh. Started the game and it still has the screen cutoff. 1280x720 is supported by my monitor and I play Hogwarts Legacy and CS2 with it. Also, it isn't working putting the game into borderless Fullscreen. I can set to window mode and exit. Then start the game again and it will start in windowed mode, not Fullscreen borderless. I even tried the script and it said successfully installed for multiplayer, but still cut off at bottom.

"Not putting it into Fullscreen", that telling me that the issue is the configuration file somehow.

It doesn't work, what happens is what happens without Zetaloader, black bars on top and cutoff on bottom. 1440x810 is the lowest res that works. Screenshot attached.

The configuration file looks fine but can tell me if the game does fullscreen if you remove the width, height and frequency parameters?

Do you have a discord account by any chance?
I help you further from there so everything can happen mostly in real time.
https://discord.com/users/419449186531147790


grant all privileges on zipkin MySQL db to zipkin user

To simplify testing and future migrations, we can give all privileges, so i.e. future migrations will not fail

thanks!
re-pushed release-1.17.1


RFM - jdk8

Current Maintainer

[ ] I am the maintainer of the package and wish to pass it to someone else;

I DON'T Want To Become The Maintainer

[x] I have followed the Package Triage Process and I do NOT want to become maintainer of the package;
[X] There is no existing open maintainer request for this package;

Checklist

[X] Issue title starts with 'RFM - '

Existing Package Details
Package URL: https://chocolatey.org/packages/jdk8
Package source URL: https://www.oracle.com/java/technologies/javase-jdk8-downloads.html

Date the maintainer was contacted: yesterday, chocolatey. several months ago on his github site.
How the maintainer was contacted: chocolatey, github issue.

@carsten-engelke We can't accept this request until the maintainer has been contacted via the 'Contact Maintainers' link on the package page and after 7 days has elapsed.

Hello. This is Ota that current maintainer of JDK8 package.
I agree that I have followed the Package Triage Process and I do NOT want to become maintainer of the package;
Sorry it is very difficult to support current Oracle specifcation to download JDK.

As per an update to our Readme, the trusted status of this package have been removed.
See https://github.com/chocolatey-community/chocolatey-package-requests#how-to-create-packages-for-a-request


Potential divide by zero when setting tank properties

When a tank is first added using the EN_addnode function its maximum volume property (Vmax) is set to zero. After its maximum level (EN_MAXLEVEL) is set, the value of Vmax will then become something other than zero. However, if certain other properties are set first, such as EN_VOLCURVE, EN_MINVOLUME, EN_TANKDIAM, etc., then the following code segment that updates the tank's mixing zone volume and appears multiple times in EN_setnodevalue will give rise to a divide by zero condition:
        vTmp = Tank[j].Vmax;                           // old max. volume
        Tank[j].Vmax = tankvolume(p, j, Tank[j].Hmax); // new max. volume
        Tank[j].V1max *= Tank[j].Vmax / vTmp;          // new mix zone volume

Although this can be fixed by testing for Vmax == 0 a more robust solution would be to replace V1max in the Tank data structure with the Mixing Zone Fraction value which is the actual parameter that the user supplies when specifying a tank's properties. The conversion to a V1max can be made as needed when the two-zone mixing model is executed.

This issue has been successfully addressed in PR #580.


[PayPal] Make up the right place of storing the plugin

Acceptance criteria:
[ ] - It's assumed that is one place to store such thing as a plugin (nuxt plugin / SW6 plugin)
[ ] - there is an interface of that kind of plugin with:

library to be imported   (could be in the same component if payment plugin is a standalone one)
configuration for possible modes: sandbox, production, and corresponding credentials
[ ] - the strict structure of files is described

We decided that the SW6 pwa part of the plugin is the right place of storing such logic. We just need to find out how to generate slots for the payment plugins. A related Issue is created.

Will this implementation be some sort of blueprint for next plugins implementations? In which cases should we put business logic in the pwa part of SW6 plugin and in which other cases should we call plugins API endpoints?

Will this implementation be some sort of blueprint for next plugins implementations? In which cases should we put business logic in the pwa part of SW6 plugin and in which other cases should we call plugins API endpoints?

Yes, it will be some kind of template for next implementations.
Basically we should treat PWA (vue) components like twig templates with minimum logic.
DAO is still on the server side.
So, some assumptions will come up after the first plugin implementation (paypal case), for instance:

consistent endpoint prefix for endpoints that are called from the pwa components (and shopware-pwa/shopware-6-client will only have methods: get, post, patch, etc prefixed under the hood to interact with all the controllers from the pwa plugin - it's not agreed yet, just RFC)


0 spanning read counts

Hello,
I'm trying to use SVclone for a list of BRASS calls and the original BAM file. It generates counts and estimates plausible VAFs but the 'spanning' counts column remains empty for all SVs except one. I have visualised all these breakpoints myself in Jbrowse and confirmed they map to other genomic regions using UCSC blat so I'm not sure why it would fail to count them. Do you know of any reason why SVclone might be failing to flag these reads as spanning? It leaves me with a *filtered_svs.tsv file with a single SV rather than 61.
Thanks for your time.

Please check the read_params.txt file under your output directory. If the fragment length and standard deviation don't look sensible, then this is the most likely cause of your issue and you'll have to manually set them. This can be done by setting these values in the config file under [BamParameters]. Delete the read_params.txt file and try rerunning from the annotate step.

Ah, OK thanks. I will be sure to manually set these.


traefik 2.1 dashboard  not show  is 404

go generate
go build go build ./cmd/traefik
it build success
and then vim traefik.sample.toml  change port 80 to 8093 ,443 to 8094 save
./traefik --configFile=traefik.sample.toml
http://<IP_ADDRESS>:8093/dashboard/  not show  .is 404
what should i need to do?

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.

traefik.sample.toml is
[global]
checkNewVersion = true
sendAnonymousUsage = true
[entryPoints]
[entryPoints.http]
address = ":8093"
[entryPoints.https]
address = ":8094"
[log]
[api]
dashboard = true
insecure = true
[ping]

go generate
go build go build ./cmd/traefik
it build success
and then vim traefik.sample.toml change port 80 to 8093 ,443 to 8094 save
./traefik --configFile=traefik.sample.toml
http://<IP_ADDRESS>:8093/dashboard/ not show .is 404
what should i need to do?
traefik.sample.toml is
[global]
checkNewVersion = true
sendAnonymousUsage = true
[entryPoints]
[entryPoints.http]
address = ":8093"
[entryPoints.https]
address = ":8094"
[log]
[api]
dashboard = true
insecure = true
[ping]

Hi @zzxap as the bot told you, it is not a bug, but a misconfiguration.
Can you open a topic on the community forum (https://community.containo.us/) to get help please?


How to add seq?

The name of the SEQ property is "SEQ" but its text output is "SEQUENCE" (as defined by the rfc).
How do you suggest to handle this? I cannot do event.addProp('SEQUENCE', 1) as it's not allowed in the list of props. Also, event.addProp('SEQ', 1) would output SEQ: 1 which is not valid.
The easiest way I can think of for your lib is to rename the SEQ prop to SEQUENCE.
Otherwise probably a getPropName() method defined in the Property class which can be overloaded?

Good catch! The SEQUENCE property is listed as SEQ in the library because the RFC denotes it using the shortened version. Unfortunately, I missed that.
// RFC 5545, Page 53
class / created / description / geo /
last-mod / location / organizer / priority /
seq / status / summary / transp /
url / recurid /

I'll change the property name from SEQ to SEQUENCE.
Please let me know if you find any more of these.

@terebentina v0.8.3 should fix this.


Create The_OSU_ChemEs

Project Descripton

Awesome! Looking forward to seeing this in action. @Farshudsor lmk if there's a particular benchmark you have in mind. I believe we have one that emphasizes chemical descriptors.

I added a couple of recommendations in the Google sheet. Unfortunately,
they are all unconstrained single objective, single fidelity problems.
Maybe we can add sythesizability metrics with some popular tools and treat
them as either a constraint or a secondary objective.
On Tue, Mar 26, 2024 at 9:23 AM Sterling G. Baird @.***>
wrote:

Awesome! Looking forward to seeing this in action. @Farshudsor
https://github.com/Farshudsor lmk if there's a particular benchmark you
have in mind. I believe we have one that emphasizes chemical descriptors.
—
Reply to this email directly, view it on GitHub
https://github.com/AC-BO-Hackathon/ac-bo-hackathon.github.io/pull/41#issuecomment-2020419281,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEXL4U5JIC3JUJGJPG4YLFTY2FZDNAVCNFSM6AAAAABFH6UPH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRQGQYTSMRYGE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Conflicting Information and Clarification...

Hello There @iBotPeaches! :-)
I just noticed that the following link...
https://ibotpeaches.github.io/Apktool/
... Shows that one of the requirements is "Java 7 (JRE 1.7)".
Though, the following link...
https://ibotpeaches.github.io/Apktool/install/
... Shows the requirement of at least "Java 1.8".
I've seen similar conflicts on a few other areas and was wondering if you were aware of this.
I know that you're busy with other items on your agenda and I only pointed this out as a friendly "Heads Up" my friend.
On a separate note, i'm also wondering about any requirements for the JDK that includes JRE instead of outlining JRE only.
I may be wrong about this part but, I just wanted to be sure if there were any added benefits to using the JRE over the stand alone JDK.
Thank you very much for your time and understanding with this! :-)
~Ibuprophen

To build Apktool, you need Java 8 now (JDK).
To run Apktool, you need at least Java 7 (JRE). I am debating with the upcoming release whether to also move the JRE requirement to 8.

Java is moving too frequent these days. The next release will stay at JRE7, so docs are right.

I really appreciate your taking the time @iBotPeaches to address this minor question since I do you have more pertinent items on your agenda.
Keep up the GREAT work My Friend! 🍻👍
~Ibuprophen

sudo update-alternatives --config java
use this cmd to change the default version of java choose number 2 in most probably case java 8 will be on number 2
that's it.


Fix for connection state listener

Currently connectionStateListener act based on the response of a request. But when there is no request on the channel, we are going to miss the close channel event. This fix will improve this part.

add metrics to track how many times connectionStateListener has acted on
Before the change:
"serviceEndpointStatistics": {
"availableChannels": 1,
"acquiredChannels": 0,
"executorTaskQueueSize": 0,
"inflightRequests": 1,
"lastSuccessfulRequestTime": "2022-02-17T17:57:26.082Z",
"lastRequestTime": "2022-02-17T17:57:26.064Z",
"createdTime": "2022-02-17T17:57:25.000727Z",
"isClosed": false
}
After the change:
The extra metrics will only show up if the customer has enabled connection state listener
"serviceEndpointStatistics": {
"availableChannels": 1,
"acquiredChannels": 0,
"executorTaskQueueSize": 0,
"inflightRequests": 1,
"lastSuccessfulRequestTime": "2022-02-20T20:30:13.507Z",
"lastRequestTime": "2022-02-20T20:30:13.481Z",
"createdTime": "2022-02-20T20:30:11.920759Z",
"isClosed": false,
"cerMetrics": {
"lastCallTimestamp": "2022-02-20T20:30:13.481Z"
}
}

If the connectionStateListener can act on the exception:
"serviceEndpointStatistics": {
"availableChannels": 1,
"acquiredChannels": 0,
"executorTaskQueueSize": 0,
"inflightRequests": 1,
"lastSuccessfulRequestTime": "2022-02-20T20:30:13.507Z",
"lastRequestTime": "2022-02-20T20:30:13.481Z",
"createdTime": "2022-02-20T20:30:11.920759Z",
"isClosed": false,
"cerMetrics": {
"lastCallTimestamp": "2022-02-20T20:30:13.481Z",
"lastActionableContext": "(2022-02-22T15:48:32.276683Z,0)"
}
}
Closes #28269

API change check for com.azure:azure-cosmos
API changes are not detected in this pull request for com.azure:azure-cosmos

/azp run java - cosmos


Filling match arms replaces #[async_trait] attribute instead of actual match statement

Before:

After:

This problem occurs also in user's code when implementing the trait

This is a bug in whatever IDE you are using.

I believe it is rust-analyzer than. Because I had the same behavior in neovim also

@vikulikov Did you report this on the rust_analyzer side?

No, for some reason I forgot to do that

https://github.com/rust-lang/rust-analyzer/issues/12938


[BDGR-158] Remove upload "gone state"

Just remove the upload from the state entirely. Plus, a test to check that it goes away.

Codecov Report
Attention: Patch coverage is 0% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 3.02%. Comparing base (107f6dd) to head (fb217de).

Files
Patch %
Lines

server/components/Uploader.tsx
0.00%
7 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #267       +/-   ##
==========================================
- Coverage   22.55%   3.02%   -19.54%
==========================================
  Files          95      88        -7
  Lines        3595    2510     -1085
  Branches      563     518       -45
==========================================
- Hits          811      76      -735
+ Misses       2784    2434      -350

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix property type for OpenXR display refresh rate

Looks like a typo that slipped in by copying some code and not changing the type.. oops.

Thanks!


MicroBitUtilityService - to read MicroBitLog MYDATA via BLE

This depends on and includes PR https://github.com/lancaster-university/codal-microbit-v2/pull/177 "Add MicroBitLog::readData".
TODO: How should the service and characteristic UUIDs determined?
This currently uses the micro:bit base UUID plus 1 and 2.
MicroBitUtilityService.h/cpp - BLE service providing replies to simple client requests
MicroBitUtilityTypes.h - Details of the service requests that support reading MicroBitLog data
MicroBitCompat.h - Define MICROBIT_ID_UTILITY for service events
MicroBitConfig.h - Macros to control creation in pairing / application mode, default pairing mode only.
MicroBit.cpp - Create service according to config macros. To create in BLEManager::init would need to pass MicroBitLog.
MicroBitBLEChar.cpp - Changed DMESGF to DMESG.
Example hex log-read-data-ble.hex.zip is built from https://github.com/martinwork/microbit-v2-samples/tree/log-read-data-ble.

So I've done some digging, and for UUIDs it seems that we can either:

Register with the Bluetooth folks for a specific set of numbers, at extreme cost
Use pre-existing ones from the giant list here: https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit UUID Numbers Document.pdf
Just make some up (what you've got here 👍 ) and just have magic micro:bit numbers.

3 is nice and simple, but is frowned upon my the Bluetooth folks, and there are a lot of UUIDs in the 16-bit table, so there may well be an appropriate one for us to use, but scanning them right now I haven't spotted one yet (but the list is massive).
If someone fancies like scouring the UUID list I'd appreciate it, as I have to look at other issues for v0.2.40 and this is a big time sink :(
Otherwise if we have time before zero-hour, I'll see what I can find and see if we can get this and #177 merged in for v0.2.40.

Just make some up (what you've got here 👍 ) and just have magic micro:bit numbers.

I've always assumed micro:bit has a registered base UUIID, so I didn't expect we would need to register a new one:
https://github.com/lancaster-university/codal-microbit-v2/blob/master/source/bluetooth/MicroBitBLEService.cpp#L44
Many of the existing micro:bit specific UUIDs combine this base ID with various 16 bit IDs
https://github.com/lancaster-university/codal-microbit-v2/blob/master/source/bluetooth/MicroBitEventService.cpp#L40
https://github.com/lancaster-university/codal-microbit-v2/blob/master/source/bluetooth/MicroBitIOPinService.cpp#L37
I don't know how those 16bit IDs were picked. They look random, maybe to minimise clashes with users experimenting with their own services.

Bumped to *41, as its too close to release to keep now with undefined IDs.

By the way, I think just getting the data from readData() leaves a few things out.  I included:

Getting the current micro:bit time (to correlate log data with wall clock time --- there are some limitations doing this, but nothing like it is easily possible with the current data logger.  Well, unless you use an RTC extension.
A modest notion of "security".  I use a simple passphrase to authenticate.  It's a non-encrypted link and could be sniffed out, but this approach seems like a good balance between the some optional security, ease of use, and the minor risks posed.
The ability to remotely erase the log.
An estimate of the total log space currently used.

Things that would be really nice:  a rolling log (when full, just overwrite the earliest entries).  This requires some additional  thought to the logging approach.  I think my initial ideas all require a little more wear on flash in ways.  For example, use sentinel values that represent log start, stop, or the combined start stop if the log has rolled over.  Each write would have to do the data and write/update the sentinel.   On the other hand, the current approach will always start at the beginning of the designated after any clear().  The rolling approach could start at wherever the start sentinel is, so it may wear the flash more uniformly.  A clear() would really just be an update of the end sentinel value and not reset writes to the beginning.

@bsiever I like the ability to get the micro:bit time, but I wonder if MicroBitUtilityService and some equivalent Web USB service/protocol should also allow us to set wall clock time on the micro:bit. Certainly when playing with some RTC-based addon boards recently that felt useful.
For security, why not use the encryption options provided by Bluetooth, like turning on passphrase pairing? This seems better than doing roll-our-own which is always going to be fairly easily worked around?
Erasing the log without user action seems a bit suspect, but I guess this would allow us to setup a case where the micro:bit is out of reach or deeply embedded in something?
Do you need to be able to estimate log space available without reading the whole file?

@jaustin
Setting time
Current Time Service (https://www.bluetooth.com/specifications/specs/current-time-service-1-1/) may be an ok fit, but probably more overhead than needed.  I'll leave that to you and the rest of the micro:bitters (hmm...that can't be the right term).
Security
I'm definitely open to thinking more about security....but:

Pairing with "Just works" doesn't really secure the data. Anyone can pair.
Pairing with a passphrase requires considering all the devices one wants to pair with in advance of deployment.

Setup takes time
Reprogramming / redeploying or upgrades can sometimes reset the keys on just one end.  This is frustrating to users who went through pairing and don't know why it's not connecting.
Teachers may use this very intermittently.  I don't want someone who does this once a year to have to think about "Did I pair this micro:bit?  To this computer? It is still good?".
I want it to be easy to have multiple sensors collecting data.  Deploy the same code to 5 sensors.  Dump them somewhere. Three days later walk by, open an app, and get data from all 5 with the same passphrase.  Minimal effort.  An example suggested by a colleague:  Collect temperature at several places on a playground.  See the impact of shadow, day/night, shelter from the wind, etc.

For the bulk of use cases I have in mind, no security or a simple password seems easier and doesn't carry much risk.
Erasing

Erasing does require a passphrase if one was selected.
I wouldn't bother if there was a rolling log.  The main concern is long term deployments that will fill the log.

Log Space
It'd be nice if CODAL did support an estimate of remaining log, but here's how I'm currently doing it (not well tested): https://github.com/bsiever/microbit-pxt-blelog/blob/754578c06e0f3bbcfbd7f702454a5865fe0e8268/BLELogService.cpp#L250 .

Created https://github.com/lancaster-university/codal-microbit-v2/pull/287 to replace this one.

Closing this PR in favour of continuing the work in:

https://github.com/lancaster-university/codal-microbit-v2/pull/287