E2E Tests are flakey

Identify and fix flakey tests.
May need to add appropriate checks for elements being visible/available - tests may run fine on a fast box, but not on a slower one.
Flakey tests:
preferences.spec.ts - 1) Can navigate to Preferences Page
AssertionError: Timed out retrying after 60000ms: Expected to find element: [data-testid="user-menu-dropdown"], but never found it.

WIP - Brief initial findings
Timins
Baseline - https://github.com/rancher/dashboard/actions/runs/5245832081/jobs/9473832080
Disabling Recording (videos on) - https://github.com/rancher/dashboard/actions/runs/5266079336/jobs/9519532031?pr=9122
Disabling Videos - https://github.com/rancher/dashboard/actions/runs/5266241986/jobs/9519921253?pr=9122

Baseline
Disabling Recording (videos on)
Disabling Videos

30 seconds
23 seconds
19 seconds

13 minutes, 36 seconds
8 minutes, 16 seconds
5 minutes, 17 seconds

3 minutes, 26 seconds
2 minutes, 11 seconds
1 minute, 32 seconds

4 minutes, 10 seconds
3 minutes, 9 seconds
2 minutes, 27 seconds

20 seconds
14 seconds
11 seconds

26 seconds
18 seconds
13 seconds

Flaky test (success on retry)
Performance / Inactivity

should reset the settings - showed inactivty modal because page took too long to load http://<IP_ADDRESS>/instance/0827f541-9f5d-4509-81a3-64ca2f852af3/others/RECORDED_VIDEO

Preferences

Can select Hide All Type Description Boxes - 10s wait to nav to page failed as page took too long to load http://<IP_ADDRESS>/instance/66d5fa8b-983d-4bde-9ea4-3dbc0c23fa51/others/RECORDED_VIDEO

Workloads / Pods

Should have same spec as the original pod - wait for request to fetch specific pod times out as page took too long to load http://<IP_ADDRESS>/instance/925b8f24-6c91-41a9-a8c4-f861e05ed37e/others/RECORDED_VIDEO

Given these three PRs tests should be running better now. We'll monitoring and then close this issue
https://github.com/rancher/dashboard/pull/9063
https://github.com/rancher/dashboard/pull/9123
https://github.com/rancher/dashboard/pull/9143

Tests look pretty stable, except for a few probably in dev runs. They're also running at around the 40 minute mark.  https://github.com/rancher/dashboard/actions/workflows/test.yaml.
Think we're safe to close this now


Syntax error in installation file.

Hi, i have found a sintax error in your bash install script, when you execute the script i get:
informix_install.sh: line 182: /var/informix//ifx_dev.env: No such file or directory
chown: cannot access `/var/informix//ifx_dev.env': No such file or directory
There is an extra slash in the script.
It should be :in line 182:
cat < "${USER_HOME}"ifx_${INSTANCE_NAME}.env
in line 200:
chown informix: "${USER_HOME}ifx_${INSTANCE_NAME}.env"

This is strange. AFIR the // in path shouldn't be issue in most Linux distros (especially Debian based), but I have fixed it - try updating to newest commit, delete created docker-informix image and rebuild it:
here is sample output on my machine:
   >>>    Create group and user for Informix
   >>>    Uncompress Informix Archive: iif.12.10.FC4DE.linux-x86_64.tar
   >>>    Launch silent install ...
   >>>    Postconfig onconfig ...
   >>>    Postconfig sqlhost ...
   >>>    Include tcp support ...
   >>>    Create informix user environnement
   >>>    Chown Informix binary directory structure
   >>>    Create data directory
   >>>    Deleting unpacked files
   >>>    Deleting downloaded packages
   ###############################################
   #         Installation completed              #
   ###############################################

Here is log from starting Informix database:
>>>    Create data directory structure in /home/informix/data (ifx initialization)
>>>    Create user "test"...
>>>    Starting up the IBM Informix Database (dev) ...
*** Startup of dev SUCCESS ***
>>>    Create database "test"...
>>>    Grant DBA to database "test" for user "test"...
IBM Informix Dynamic Server Version 12.10.FC4DE Software Serial Number AAA#B000000
	#################################################
 	# Informix container login information:
 	#   database:    test
 	#   user:        test
 	#   password:    test
 	#################################################

If bug is fixed please close this issue or write me a comment to close this. If my changes won't fix bug, please provide me some details (stdot/stderr from building docker container, docker version etc.).

Hi, i'm using debian wheezy, but i'm using your script to install informix in the system and not inside a container, it saved me some work, thank you. It is curious that in other parts of the script, or other scripts like, the start-database.sh the double slash does work.  However the bug is still valid. Thank you for fixing it.  I will create a fork of your repo, for the installation scripts in your system. Thanks.

hi, In recent commit I have added ability to change username/groupname and uid/gid in installation script. It may be useful in your use case ;).


couldn't find libcardioDecider.so

I've developed an Android app a couple of months ago using Card.IO. It was working normally but now Card.IO don't work and I can't find where's the problem.
Here's my configuration:
build.gradle (from my app module)
buildscript {
    repositories {
        maven { url 'https://maven.fabric.io/public' }
    }

    dependencies {
        classpath 'io.fabric.tools:gradle:1.+'
    }
}
apply plugin: 'com.android.application'
apply plugin: 'io.fabric'
apply plugin: 'com.google.gms.google-services'

android {
    compileSdkVersion 22
    buildToolsVersion "23.0.2"

    defaultConfig {
        applicationId "appID"
        minSdkVersion 14
        targetSdkVersion 22
        versionCode 6
        versionName "1.4.1"
        multiDexEnabled true
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    dexOptions {
        javaMaxHeapSize "4g"
    }
}

repositories {
    mavenCentral()
    maven { url 'https://maven.fabric.io/public' }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile(project(':volley')) {
        exclude module: 'support-v4'
    }
    compile files('libs/commons-codec-1.9.jar')
    compile('com.navercorp.volleyextensions:volley-views:2.0.+') {
        exclude module: 'library'
    }
    compile('com.crashlytics.sdk.android:crashlytics:2.5.5@aar') {
        transitive = true;
    }
    compile 'com.android.support:appcompat-v7:22.2.1'
    compile 'com.android.support:cardview-v7:22.2.1'
    compile 'com.android.support:recyclerview-v7:22.2.1'
    compile 'com.google.code.gson:gson:2.3.1'
    compile 'io.card:android-sdk:5.3.0'
    compile 'com.github.ksoichiro:androidpagecontrol:0.1.1'
    compile 'me.relex:circleindicator:1.1.5@aar'
    compile 'com.nineoldandroids:library:2.4.0'
    compile 'com.daimajia.easing:library:1.0.1@aar'
    compile 'com.daimajia.androidanimations:library:1.1.3@aar'
    compile 'com.facebook.android:facebook-android-sdk:4.5.0'
    compile 'br.com.jansenfelipe:androidmask:1.0.1'
    compile 'com.google.android.gms:play-services-analytics:8.3.0'
    compile 'com.google.android.gms:play-services:8.3.0'
    compile 'com.android.support:multidex:1.0.0'
    compile 'com.android.support:design:22.2.1'
    compile 'com.squareup.picasso:picasso:2.5.2'
}

In my first Activity:
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        MultiDex.install(getBaseContext());
        Fabric.with(this, new Crashlytics());
        FacebookSdk.sdkInitialize(StartActivity.this);
        setContentView(R.layout.start_activity);
        System.out.println("CARDIOVERIFIER:::::" + CardIOActivity.canReadCardWithCamera());

    }

And here is the output of logcat:
01-12 11:23:57.385 30672-30672/? I/card.io: Checking hardware support...
01-12 11:23:57.386 30672-30672/? I/card.io: card.io 5.1.1 10/14/2015 15:59:57 -0500
01-12 11:23:57.386 30672-30672/? E/card.io: Failed to load native library: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/app-package-2/base.apk"],nativeLibraryDirectories=[/data/app/app-package-2/lib/arm, /vendor/lib, /system/lib]]] couldn't find "libcardioDecider.so"
01-12 11:23:57.386 30672-30672/? W/card.io: - Processor type is not supported
01-12 11:23:57.386 30672-30672/? I/System.out: CARDIOVERIFIER:::::false

I have installed the Card.IO SampleApp on my device and it worked perfectly, so my device has support for Card.IO.
I searched the internet about this and everyone said that I need to put *.so on my libs folder, but when I export the App I can see all the directories that Card.IO use (arm64-v8a, armeabi, armeabi-v7a, etc.) and inside of then have libcardioDecider.so file.
Can anyone help me?

I'm have unzip de .zip file and inside of then has the lib folder with all the files of Card.IO
There's another way to check that?

I have found the source of the problem: gradle version. I was using 1.2.3.
When I updated to 1.5.0 everythings work fine! I just discovered that posting the same question on stackoverflow.. link: http://stackoverflow.com/questions/34745715/card-io-android-couldnt-find-libcardiodecider-so/34782711#34782711


Performance degradation when using aliases with date_format in order by clause

CrateDB version:
3.0.0-SNAPSHOT-01a5fae
Environment description: Centos 7.4
Problem description:
When using aliases and ordering by them, query times take longer to return results. This appears to be an issue when using the date_format function. We haven't tried other functions.
Steps to reproduce:
SELECT colA, date_format('%Y-%m-%dT%H:%i:%s.%fZ', startdate) as start_date FROM table ORDER BY start_date desc

This query takes ~8s
SELECT colA, date_format('%Y-%m-%dT%H:%i:%s.%fZ', startdate) as start_date FROM table ORDER BY startdate desc

This query takes <1s
startdate's type: timestamp

If you sort on the timestamp column it can internally utilize a column store data structure to do efficient sorting. If instead you sort on the date_format function it has first to evaluate that function on all records, this is expected to be slower.

@mfussenegger Makes sense....I'll close unless you think further action is needed.


manual backport of 37573

Signed-off-by: Rama Chavali<EMAIL_ADDRESS>Please provide a description of this PR:

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@ramaraochavali: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio_release-1.12
69cdc6a5605f4e81ff935939d1c1045637ff6741
link
true
/test lint_istio_release-1.12

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio_release-1.12
69cdc6a5605f4e81ff935939d1c1045637ff6741
link
true
/test lint_istio_release-1.12

unit-tests_istio_release-1.12
69cdc6a5605f4e81ff935939d1c1045637ff6741
link
true
/test unit-tests_istio_release-1.12

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali could you take a look at the failing tests?

/test unit-tests_istio_release-1.12

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio_release-1.12
69cdc6a5605f4e81ff935939d1c1045637ff6741
link
true
/test lint_istio_release-1.12

unit-tests_istio_release-1.12
69cdc6a5605f4e81ff935939d1c1045637ff6741
link
true
/test unit-tests_istio_release-1.12

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@Kmoneal Sorry. Fixed now.


ActivityIndicator is showing as reload icon in Android

Description
Description
When using ActivityIndicator in ReactNative, it works in IOS. But for Android, it is shown as a reload icon
Screenshots:

Version
66.4
Output of npx react-native info
System:
OS: macOS 12.2.1
CPU: (8) x64 Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
Memory: 799.34 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 12.22.8 - ~/.nvm/versions/node/v12.22.8/bin/node
Yarn: 1.22.17 - ~/.nvm/versions/node/v12.22.8/bin/yarn
npm: 6.14.15 - ~/.nvm/versions/node/v12.22.8/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
Android SDK:
API Levels: 28, 29, 30, 31, 32
Build Tools: 30.0.2, 30.0.3, 32.0.0, 32.1.0, 33.0.0
System Images: android-25 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom_64, android-28 | Google Play Intel x86 Atom, android-29 | Android TV Intel x86 Atom, android-29 | ARM 64 v8a, android-29 | Intel x86 Atom, android-29 | Intel x86 Atom_64, android-29 | Google APIs ARM 64 v8a, android-29 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom_64, android-29 | Google Play ARM 64 v8a, android-29 | Google Play Intel x86 Atom, android-29 | Google Play Intel x86 Atom_64, android-30 | Intel x86 Atom_64, android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom, android-31 | Intel x86 Atom_64, android-31 | Google APIs ARM 64 v8a, android-31 | Google APIs Intel x86 Atom_64, android-32 | Google APIs Intel x86 Atom_64
Android NDK: Not Found
IDEs:
Android Studio: 2021.1 AI-211.7628.21.2111.8092744
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
Languages:
Java: 1.8.0_292 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.66.4 => 0.66.4
react-native-macos: Not Found
npmGlobalPackages:
Steps to reproduce
Just running this code:
import {View, TouchableOpacity } from 'react-native';

<ActivityIndicator
animating={true}
style={{
flex: 1,
justifyContent: 'center',
alignItems: 'center',
height: 80
}}
color='#bc2b78'
size="large" />

Snack, code example, screenshot, or link to a repository

This is what is shown when animations are disabled: check under developer options that animations are not set to 'off'

Fixed, thank you


Remove wall timing fallback from python/triton/testing.py

Once we switch to the version of the elapsed_time in PyTorch, this is no longer necessary.
Part of #2030

I think we should keep it for awhile to support legacy versions of PyTorch (e.g. 2.5 which probably will not support DLE). Certainly until 2.6 is released in January.

I think we should keep it for awhile to support legacy versions of PyTorch (e.g. 2.5 which probably will not support DLE). Certainly until 2.6 is released in January.

Good point, but are we testing with PyTorch 2.5 somewhere?


explicitly shut down server

Here is where we start up a server:
https://github.com/pangeo-gallery/binderbot/blob/d3200af23ee9e83162204e845824a025c476f2c1/binderbot/binderbot.py#L55-L62
But I can't figure out how to explicitly shut it down.
https://github.com/pangeo-gallery/binderbot/blob/d3200af23ee9e83162204e845824a025c476f2c1/binderbot/binderbot.py#L91-L95
This is too bad, because we are potentially wasting resources by leaving these binders running when we don't need them.

We use the kubernetes API to shut down user pods occasionally...could you just do this at the k8s level? e.g. see here for inspiration? https://github.com/jupyterhub/mybinder.org-deploy/blob/master/scripts/delete-pods.py

Good suggestion...but I don’t want to assume that binderbot has any privileged access to the binderbub beyond a normal user.
Sent from my iPhone

On Mar 31, 2020, at 3:33 PM, Chris Holdgraf<EMAIL_ADDRESS>wrote:

We use the kubernetes API to shut down user pods occasionally...could you just do this at the k8s level? e.g. see here for inspiration? https://github.com/jupyterhub/mybinder.org-deploy/blob/master/scripts/delete-pods.py
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Include hearing type as apart of the unique identifier for each case event

Closing this since now we have access to daily excel files.


Setting navigationBarTitleDisplayMode doesn't work for modal routing.

When presenting a modal view using router.route(to: \.newCall) the navigation title is always displayed as .large even though the view has .navigationBarTitleDisplayMode set to .inline. It doesn't happen when the same view is presented using standard SwiftUI .sheet.
iPhone

View presented with router.route(to: \.newCall):
View presented with .sheet:

Code from the parent view and the coordinator:
struct TestView: View {
	@State var isPresented = false
	@EnvironmentObject private var router: TestCoordinator.Router

	var body: some View {
		VStack {
			Spacer()
			Button("Test sheet") { isPresented.toggle() }
				.sheet(isPresented: $isPresented, content: {
					NavigationView {
						NewCallView()
							.navigationTitle("New call")
							.navigationBarTitleDisplayMode(.inline)
					}
				})
			Spacer()
			Button("Test Stinsen") {
				router.route(to: \.newCall)
			}
			Spacer()
		}
	}
}

final class TestCoordinator: NavigationCoordinatable {
    (...)
		@Route(.modal) var newCall = makeNewCallView

		@ViewBuilder
		func makeNewCallView() -> some View {
			NavigationView {
				NewCallView()
					.navigationTitle("New call")
					.navigationBarTitleDisplayMode(.inline)
			}
		}
    }
}

Hi, there is a branch that might solve this issue: navbarless. Could you please test it out and see if it works? I'm not 100% done with it yet, so I haven't merged it...

Thanks for the reply. It works on the navbarless branch.

Do you have any ETA on the branch to be merged in or at least stable for production?

There are still some bugs left to fix (try for instance presenting a modal screen and then pushing a new one), I'll look into it this week and hopefully fix it.

To work with the current state of Stinsen (and how I think it should properly be), instead of creating an explicit NavigationView to present, return a NavigationViewCoordinator<NewCallCoordinator>. This will require creating a new NewCallCoordinator that conforms to NavigationCoordinatable and might just have a single view but this pattern has worked for me for a long time.
Change from your example to:
final class TestCoordinator: NavigationCoordinatable {
    (...)
    @Route(.modal) var newCall = makeNewCallView

    func makeNewCallView() -> NavigationViewCoordinator<NewCallCoordinator> {
        NavigationViewCoordinator(NewCallCoordinator())
    }
}

and create:
final class NewCallCoordinator: NavigationCoordinatable {

    let stack = NavigationStack(initial: \NewCallCoordinator.start)

    @Root
    var start = makeStart

    @ViewBuilder
    func makeStart() -> some View {
        Text("Hello There")
            .navigationBarTitle("Inline Me", displayMode: .inline)
    }
}

Names are just used for examples. I have used this pattern ever since I used Stinsen as I feel it's how its supposed to work by handling the NavigationView creation to our coordinator pattern. We shouldn't have to create our own NavigationView at all. This does increase some code boilerplate and files but conforms to the pattern a lot better.

I agree here. modally presenting a NavigationView is not really the "Stinson"-esque way. Usually you'd want to present a Coordinator here. This might be a bit tricky to fix since Stinson needs to "inject" it's navigation-logic inside the view presented by the NavigationView, not the navigationview itself... I haven't had time to look for an alternative solution yet, but this is probably the top priority issue I want to attempt to fix at least.
But as @LePips says, there are workarounds that are "better".


Feature: BIP-0353 support

Feature Description
I'd like BIP-0353 support so that offers can be automatically fetched from DNS records and paid in one simple command.
Design

Decode user@domain and convert to user.user._bitcoin-payment.domain.
Fetch TXT record.
Verify DNSSEC proofs.
Concatenate strings in TXT record.
Extract offer from bitcoin: URI.
Pay offer.

So....Strike implemented this. I believe they just used Matt's open source code, is that right @mrfelton ?

That's right!


Correct way to authenticate a VSTS poweshell task

I'm writing a task that uses Invoke-AzureRmResourceAction however, when run I get an error message
Invoke-AzureRmResourceAction : Run Login-AzureRmAccount to login
What's the correct way to get an authentication token so that I can invoke this?

Instead of using the PowerShell task, use the Azure PowerShell task, which injects the needed credentials into the current PowerShell session before running your script

If you are writing a task, the best way to authenticate to Azure Resource Manager (ARM) will be to give an input in the task to select an ARM endpoint. Please see our Azure Powershell task to see how we are doing it.

@rajatagrawal-dev  Thanks I'll give it a go

Closing this. Please reopen or create new for further questions.

I am using Azure PowerShell (v5) but still facing Run Login-AzureRmAccount to login. error
Here are my configurations


New tests for floats, symbols, and general whitespace

Add coverage for floats with underscores.
Add coverage of vertical tab and form feed in general whitespace.
Add coverage for TAB (bad) and DEL (good) in symbols.

I was surprised to discover that too.  I suspect it's an oversight;  can't think of a reason for the omission.


Merge topology checks

The commit merges the two sets of topology validations into a single set of code and tests. All are now handled similarly, with regard to replacing old failures so that they don't flicker, generating events and logging.
Note that currently, they are logged as warnings and do not halt the make-right, which which be changed in a future PR.
Jenkins run https://build.weblogick8s.org:8443/job/weblogic-kubernetes-operator-kind-new/9982/

@russgold, I've run the gating tests twice with the same (or at least similar -- I didn't look carefully) failures.

@russgold, I've run the gating tests twice with the same (or at least similar -- I didn't look carefully) failures.

I'm seeing failures to POST to WLS instances, and NPEs in ResponseStep. Investigating now.

The operator log now contains messages such as:
{"timestamp":"2022-04-12T23:27:48.757980941Z","thread":28,"fiber":"engine-operator-thread-9-fiber-556 NOT_COMPLETE","namespace":"ns-ewvvlt","domainUID":"myintrodomain","level":"WARNING","class":"oracle.kubernetes.operator.helpers.WlsConfigValidator","method":"reportFailure","timeInMillis":1649806068757,"message":"Cluster 'cl2' specified in the domain resource does not exist in the WebLogic domain home configuration.","exception":"","code":"","headers":{},"body":""}

which is a direct result of this change - it means that our tests are configuring topology elements that don't exist. I think we'll need help from the testing group to fix this.

The integration test failure, it turns out, was not related to the comparison of the new domain with the old topology, although that is a problem. The actual failures were happening because of the oversight that Dongbo noticed - that the next parameter was unused. There was no relevant unit test, so I didn't notice when I didn't complete my refactoring.
The tests are now clean: https://build.weblogick8s.org:8443/job/weblogic-kubernetes-operator-kind-new/10048/


yellow file as output

Hey,
I've been using the code for counting PNNs on a few images and it as worked nicely.
Recently, the output picture files are all yellow.
Also, the patches are first mentioned as 234 and later and in the excel file are 54.
I would very much appreciate your help in understanding why.
Thanks so much!
The code in the terminal:
PS C:\Users\Desktop\counting_perineuronal_nets-0.5> python predict.py pnn_v2_fasterrcnn_640/ -r pnn_v2_scoring_rank_learning/ -t 0.0 C:\Users\Desktop\Project\new\C1-e3_enr_2_wfa_pv_merged_downsized.tif
[  DATA] PatchedMultiImageDataset: 1 image(s), 234 patches
[ MODEL] detection - FasterRCNN(in_channels=1, out_channels=1, backbone=resnet50, backbone_pretrained=False, model_pretrained=True, max_dets_per_image=200, nms=0.3, det_thresh=0.05, cache_folder=./model_zoo)
[DEVICE] cpu
[  CKPT] pnn_v2_fasterrcnn_640\best.pth
[PARAMS] thr = 0.00
[OUTPUT] localizations.csv
[  DATA] RandomAccessMultiImageDataset: 1 image(s), 54 patches
[ MODEL] ConvNet(in_channels=1, num_classes=1)
[DEVICE] cpu
[  CKPT] pnn_v2_scoring_rank_learning\best.pth
io.imsave(out_path, drawn)
Saving: high_predictions_C1-e3_enr_2_wfa_pv_merged_downsized.png
draw_predictions.py:87: UserWarning: high_predictions_C1-e3_enr_2_wfa_pv_merged_downsized.png is a low contrast image
io.imsave(out_path, drawn)
Saving: loc_C1-e3_enr_2_wfa_pv_merged_downsized.png
draw_predictions.py:93: UserWarning: loc_C1-e3_enr_2_wfa_pv_merged_downsized.png is a low contrast image
io.imsave(out_path, drawn)

Can you also provide the content of the output file localizations.csv?

X
Y
class
score
imgName
thr
rescore

3195.046
639.9374
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.039958

7039.94
1600
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.042483

3199.981
2240
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.083928

7650.468
2559.973
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.03685

609.5144
2559.994
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.023485

3839.976
2880
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.050107

1919.947
3520
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.492849

4479.941
3520
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.039336

2559.966
4160
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.067137

5119.974
4160
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.050234

5759.974
4160
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.030111

3839.994
4800
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.071894

1889.232
5119.945
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.104583

3862.85
5119.957
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.15545

7649.845
5119.968
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.030831

7039.971
5200.402
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.031196

7039.979
5245.449
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.035805

7039.96
5264.851
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.028216

5119.963
5440
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.048684

5759.967
5440
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.032413

6399.983
5440
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.052409

2559.963
6080
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.048215

3199.956
6080
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.075119

4479.971
6434.289
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.045559

3839.952
6720
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.041288

4479.936
6720
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.053373

5119.944
6720
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.041288

6399.941
6720
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.047817

4479.964
7360
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.034603

5119.937
7360
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.03962

5759.944
7360
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.122521

1275.156
7679.935
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.048502

5067.972
7679.983
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.062388

3199.993
8000
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.039917

5759.965
8000
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.059435

5759.995
8000
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.059435

5759.944
8937.26
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.041341

646.5934
8959.938
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.026069

646.214
9599.978
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.029056

1884.402
10239.95
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.024003

1244.426
10239.95
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.023626

6.656007
10239.95
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.034613

5726.914
10239.96
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.032791

7644.343
10239.97
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.025334

1287.775
10239.98
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.027145

2567.708
10239.99
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.021677

2566.832
10879.94
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.028561

5766.557
10879.94
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.023681

3846.687
10879.96
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.027956

7646.819
10879.98
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.020486

7047.76
10879.98
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.022071

7004.387
10879.99
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.031689

1927.663
10879.99
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.038003

3806.838
10879.99
0
0.448782
C1-e3_enr_2_wfa_pv_merged_downsized.tif
0
0.03004

The number of patches in the two phases are correct. In the first stage, the image is divided into 234 squared patches and 54 PNNs are found in total. In the second stage, 54 image patches around the found PNNs are considered and restored.
It's a bit strange that the score given at the first stage are all equal to 0.448782.. Can you share also the input image and the all yellow output image?

Yes. Thank you for your check.
What is the range of values that can be given to the threshold?
Here i tried half a brain scan, but the same happens for a whole brain scan. In the output image you can see some marks of the patches.

I am assuming you are using the draw_prediction.py script to produce these images.
In that script, the thersholds are fixed in the code, e.g.:
https://github.com/ciampluca/counting_perineuronal_nets/blob/9ea18287b612b8ba6da7cbe614a5f34be5a33292/draw_predictions.py#L71-L75
Low-scored predictions should appear only in the all_predictions_... and low_predictions_... PNG files.
The yellow images may come from bad intensity scaling of the input image. Can you check the values of the image variable before and after this line?
https://github.com/ciampluca/counting_perineuronal_nets/blob/9ea18287b612b8ba6da7cbe614a5f34be5a33292/draw_predictions.py#L60

Is there a difference between the types of image files in the code?
And which values of the image should i check? how do i do that?
Thanks!


ARROW-1276: enable parquet serialization of empty DataFrames

Fixes ARROW-1276 and fixes Python dev. documentation (encountered during the preparation of this PR).

I will await the build to merge


earthly: maintainer disappeared and license became unfree

Describe the bug
https://github.com/NixOS/nixpkgs/pull/131169#issuecomment-886007895
Steps To Reproduce
Steps to reproduce the behavior:

...
...
...

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

Fixed by #131365.

No, that's just an update. The listed maintainer don't has a github account anymore.
This is fixed when the package has a new maintainer (or the maintainer is empty).

I can send a quick PR to leave the maintainers empty.

Please do.

@davidak with the PR merged this should be closed.


Made AutoField consistent between postgresql and mysql

The problem
Currently, (Big)*AutoField becomes an integer AUTO_INCREMENT field in MySQL whereas it becomes a serial in PostgreSQL (which is a positive integer).
The resolution
This patch updates the MySQL version to use the serial datatype (which is just a macro for bigint unsigned not null auto_increment unique).
Caveats
The MySQL serial datatype might introduce too many unwanted restrictions. If the community thinks this might break too much code, I would suggest to at least make the MySQL version unsigned too, to increase the consistency between the DB adapters.
Cheers

I just saw that I need to open a TRAC ticket for you guys to be able to merge this, so I opened one here. Do you want to keep this PR open while this is discussed or rather close it and reopen when applicable?

As described in https://code.djangoproject.com/ticket/56, just changing the type will result in inconsistencies in existing databases, won't it?

That is possible - I was unaware of the existance of that ticket. I will review it and get back at you. I am really interested in resolving this, since it affects a project I maintain; though I do understand my simple approach might fall short in that respect.


[cloud] Improve cloud shell error messages

Summary
This shows better error messages when cloud shell fails. A possibly common case is when a nix package doesn't exist or doesn't build correctly. Ideally we don't end the shell and let the user fix it, but in the meantime this shows a more relevant error message.
To implement this efficiently and extensibly, this uses an io.Writer to collect pre-defined ssh session errors without explicitly storing the output.
How was it tested?

Added a bad package to my devbox.json and did devbox cloud shell
To test generic failures did devbox cloud shell, turned off my wifi and waited for a timeout

@mikeland86 looking at the screenshot in the Test Plan. The red error message is much more helpful now.
Should we omit the part about the full ssh command that comes after the custom error message about nix packages not existing or failing to build? That ssh command is an internal implementation detail of devbox.

@savil I agree that omitting that would be bette. This is actually the current behavior of all user errors. It prints the "cause" below the human readable part.
This was functionality I copied over from launchpad errors. At the time it was added because sometimes the underlying error (the cause) contained important information. In hindsight I think this was only needed because we were accidentally wrapping user errors over each other. That has since been fixed so I think we could get rid of that, but it makes me a bit nervous to fix it in this PR.


Regression in v4.0.0 when hosted behind a path rewriting reverse proxy

Prerequisites

[X] I have written a descriptive issue title
[X] I have searched existing issues to ensure the regression has not already been reported

Last working version
3.1.0
Stopped working in version
4.0.0
Node.js version
18.x
Operating system
Linux
Operating system version (i.e. 20.04, 11.3, 10)
Debian 11
💥 Regression Report
When a reverse proxy rewrites the URL path before forwarding the request to the Node.js server running swagger-ui the interface gets confused and the Swagger UI becomes inoperable.
For example when a GET /api/documentation request is remapped to GET /documentation before being passed on to swagger-ui v4.0.0 the resulting html page it responds to contains resources links to /documentation/static/<resource>, which will not load as the server hosts these resources under /api/documentation/static/<resource>. Trying to access /api/documentation/static/index.html which used to work causes swagger-ui to redirect the browser to /documentation.
In swagger-ui v3.1.0 all links were relative. A GET /api/documentation request remapped to GET /documentation would correctly reply with a relative redirect to ./documentation/static/index.html sending the browser to /api/documentation/static/index.html. This page only used relative links of the form ./<resource> so it wasn't sensitive to the path prefix being remapped.
Steps to Reproduce
Configure a reverse proxy in front of swagger-ui, for example with an Apache ProxyPass directive.
<Location /api/>
    ProxyPass http://localhost:3000/
</Location>

Observe that in v3.1.0 you can access the swagger UI under /api/documentation, while in v4.0.0 it doesn't work at all.
Expected Behavior
Upgrading from 3.1.0 shouldn't cause the swagger UI to break when hosted behind a reverse proxy where the path has been rewritten. Or alternatively, this breakage/new requirement should be clearly documented.

This wasn't expected, but I guess we should have caught it.
Would you like to send a PR to fix?

cc @jdhollander

@mcollina Thanks for mentioning me, I've made a fix, see what you think...


Error: Cannot find module '../../npm.js'

So im trying to install it on Windows. After fixing this https://github.com/isaacs/npm/issues/1488 theres a new problem. Her is my npm-debug.log:
info it worked if it ends with ok
verbose cli [ 'node', 'C:\node\npm\cli.js', 'install', 'npm', '-gf' ]
info using<EMAIL_ADDRESS>info using<EMAIL_ADDRESS>verbose config file C:\Users\Alexander.npmrc
verbose config file C:\node\etc\npmrc
verbose config file C:\node\npm\npmrc
ERR! Error: Cannot find module '../../npm.js'
ERR!     at Function._resolveFilename (module.js:334:11)
ERR!     at Function._load (module.js:279:25)
ERR!     at Module.require (module.js:357:17)
ERR!     at require (module.js:368:17)
ERR!     at Object. (C:\node\npm\lib\utils\tar.js:6:11)
ERR!     at Module._compile (module.js:432:26)
ERR!     at Object..js (module.js:450:10)
ERR!     at Module.load (module.js:351:31)
ERR!     at Function._load (module.js:310:12)
ERR!     at Module.require (module.js:357:17)
ERR! Report this entire log at:
ERR!     http://github.com/isaacs/npm/issues
ERR! or email it to:
ERR<EMAIL_ADDRESS>ERR!
ERR! System Windows_NT 6.1.7601
ERR! command "node" "C:\node\npm\cli.js" "install" "npm" "-gf"
ERR! cwd C:\node\npm
ERR! node -v v0.5.8
ERR! npm -v 1.0.100
verbose exit [ 1, true ]

I have tried changing installation directory and changing node version to 059

Well, this is odd, because the tar.js that you have isn't the same as the lib/utils/tar.js in the npm source.  Did you update before trying to install the new version?  Delete the npm folder, then go through all the steps again from the beginning.


Inquiry for ARC Performance

Thanks for sharing the amazing project.
But I have a question why the performance of GPT-4o in arc dataset can only reach 7% ?
Looking for your reply !

Hi! Thanks for checking out. The naming of this augment is a bit confusing because args.model only controls the model used in the meta agent. If you would like to change the model used for evaluating the generated agents, please change the default value defined here.

@AllenPiaoHong   Hi, have you successfully reproduced the result?


(Solved)Cyclic dependency issue with ahash crate - maybe worthwhile to document.

Dear Sea ORM creators / maintainers,
first of all, thanks a lot for all the effort you seem to spend on this nice peace of software. I was just skimming around to look for a ORM to try for a new project I am trying to build. While knowing diesel (no it's not async, so it's not really interesting to me anymore) and also trying rbatis, Sea ORM looks the most promising to be honest. I have been working with sqlx before but wished for a more high level layer for regular crud operations.
I have been trying to pull in Sea ORM in an quasi active project with openidconnect / oauth dependency, however failed to pull in Sea ORM. I got a cyclic dependency error:
> cargo build
    Updating crates.io index
error: cyclic package dependency: package `ahash v0.7.4` depends on itself. Cycle:
package `ahash v0.7.4`
    ... which is depended on by `hashbrown v0.11.2`
    ... which is depended on by `indexmap v1.7.0`
    ... which is depended on by `serde_json v1.0.67`
    ... which is depended on by `wasm-bindgen v0.2.77`
    ... which is depended on by `js-sys v0.3.54`
    ... which is depended on by `getrandom v0.2.3`
    ... which is depended on by `ahash v0.7.4

I was a bit puzzled and did a cargo clean but this did not help, too. I searched for such an Issue and found an unanswered SO post: https://stackoverflow.com/questions/68399961/how-do-i-resolve-a-cyclic-dependency-in-cargo in the same question range.
I then wanted to do a minimal example for reproduction in a clean project ... I failed! I was unabled to reproduce, which left me puzzled. The only thing for me, left to do was to do rm Cargo.lock && cargo clean && cargo build and this suddenly worked (remark: i did not change any version specs in Cargo.toml, but I never pinned to patch versions, but usually minors). Seems like I was locked to an older version somewhere - the changes in Cargo.lock were too many to track down where the issue could have been, however it resolved the issue for me. Instead of deleting Cargo.toml I just learned, that i should have better used cargo update :).
Anyways, other people pulling Sea ORM in existing projects might stumble upon this issue and do not jump on the train. A simple 'cargo update' instruction for the above error somewhere in the documentation could help :)
Keep up the great work and feel free to close if too minor for you guys!

it's caused by this issue:https://github.com/tkaitchuck/aHash/issues/95.
Using indexmap = "~1.6.2" works as a workaround.

@baoyachi thanks for the quick reply! I never claimed that sea orm can solve the issue, sorry if that somehow sounded like that (which is why I put solved in the ticket title). I just wanted to point out that this happened to mem while adding sea orm to the project and never happend before with any other crate I added. Therefore i thought it might be good to document this here, too, just someone else stumbles upon this same issue. And if you guys want, you could add a short remark to your already great documentation. No must have, just came to my mind.


Sprint 1 - Drivetrain - Rio and Kai

Main objective:
Ideate the main design of the frame
Incorporate the motors into the frame, while leaving room for Mecanum Wheels
Compensate for space needed by the moving arm that will be placed near the front of the robot
Ensure the frame is sturdy and able to hold weight
Ensure the frame and wheels fit within competition regulations
End Goal:
Finish 95% of Drivetrain (Mechanisms working, but both halves of the drivetrain connected with little amounts of support)
Will try to push for 100% completion, but most likely not doable.

October 7th, 2024
Ideating stage is complete, planning on having the motors on the inside of the two side brackets, as shown in the image. Planning on moving the front motors back to compensate for the space that will be used by the moving arm. Also planning on adding supports to ensure it will not break during competition, by using two long 15mm extrusions and using the smaller C-Channels in between to have more points of connection, while also protecting the motors.

October 8th, 2024
Motor has been moved back on one side, starting the process of creating the chain loop to redirect the motor's power to the front of the robot. All of the planetary motors have been tested, with one needing to be taken apart and rebuilt. Planning on scrapping the old robots for another motor to finish the build.

October 9th, 2024
Recreated some key components through the help of the online manual. Kai tested and fixed our faulty third motor, and found a fourth motor to use. I started working on getting the chain to the right length so it can be used in redirecting the motor's power to the front of the drivetrain, while Kai is creating a mirrored version for the other side of the drivetrain. We have generated a couple of ideas on combining the two sides with various supports.

October 10th, 2024
Both sides of the drivetrain have been created. Chain was too short, so had to make it longer. Drivetrain should either be fully completed or almost fully completed by the end of the sprint. Ideas for how to bring both sides of the drivetrain have been thought of, and will most likely be put into effect tomorrow in class.

October 11th, 2024
As Kai and I were done our respective sides of the drivetrain, we both decided to create the chain together. Unfortunately, we were unable to finish the chain, as we had to make constant readjustments to it. The closest we got to completing the chain is shown in the image below, but it is not fully functional. We tried increasing the size of the chain, but that made it too long, leading to unnecessary slack that could mess up our driving. Due to this shortcoming, we were barely unable to reach our goal for this sprint.


Upgrade Mariadb binaries to version >= 10.2.7 in order to support JSON data type

Please upgrade binaries to version of mariadb >= 10.2.7 branch in order to support JSON data type which was introduced in 10.2.7: https://mariadb.com/kb/en/library/json-data-type/ .

@dargiri thanks for your interest in this project. FYI this is an open source community effort, not a commercially supported product, so if you need a newer MariaDB version, then please see https://github.com/vorburger/MariaDB4j#mariadb-database-jars-and-version-upgrades how YOU can make a contribution for that!

hi,
I've read https://github.com/vorburger/MariaDB4j#mariadb-database-jars-and-version-upgrades and I think I understand that. AND I can see that there are
ch.vorburger.mariaDB4j | mariaDB4j-db-win32 | 10.2.11  all (4) | 26-Jan-2018 | pom  jar  sources.jar
ch.vorburger.mariaDB4j | mariaDB4j-db-linux64 | 10.2.11  all (4) | 26-Jan-2018 | pom  jar  sources.jar
ch.vorburger.mariaDB4j | mariaDB4j-db-mac64 | 10.2.11  all (4) | 18-Jan-2018 | pom  jar  sources.jar

in search.maven.org
BUT I cannot see any corresponding launcher jar. so am I blind or there is something not published yet :(
I understand that with those binaries we are almost there. new launcher should have those binary deps included and I should not override versions in my pom's dependencyManagment as I do right now

@pawel-kaminski-krk watch #106 - I'll try to do that (release) ASAP...

@pawel-kaminski-krk so sounds like you are cool with closing this? I have. Comment to re-open if NOK.


Remove tvParallaxProperties

Hi team,
The prop tvParallaxProperties is not there anymore. Would you say it make sense to remove it from the docs as well?
Ref: changelog, pr

Hey @mbelsky, nice catch! Can you also removed the prop from versioned docs for 0.75 release?

https://github.com/facebook/react-native-website/tree/main/website/versioned_docs/version-0.75

@Simek thank you for taking a look! I've just added the requested changes


Add millisecond support

Combined with https://github.com/wojtekmaj/date-utils/pull/74, this adds a new useMilliseconds: boolean parameter to react-clock that allows it to show milliseconds as incremental angles, so the hands can move more smoothly instead of only snapping to seconds.
This is primarily useful for stopwatch modes, like in this demo:
https://github.com/wojtekmaj/react-clock/assets/11964962/44fb2022-d909-4034-b457-e89564100b2c
Thanks!

Hey, this PR got a bit cluttered, and also I've decided to take another approach with date-utils, so I reworked it in 8e32aa1 and marked you as a co-author. Thanks for contributing!


Refactor ansible tower service provisioning state machine methods

Refactor ansible tower service provisioning state machine methods with the new style to start with a complete class definition
Add spec tests for these methods
During this work a bug fixed in #8336 was discovered.

The commit for #8336 is included since it has not been merged yet.
We could also discard #8336 and merged all work in this PR.

@gmcculloug @mkanoor please review

@mkanoor updated. please review

@bzwei
Can you please fix up the rubocop errors

@mkanoor I have addressed most rubocop complains. The remaining ones are more readable to me.

👍
@gmcculloug should this be back ported to Darga

@mkanoor Yes, since these are all new methods in darga I would like to get it so we do not have to deal with discrepancies if we need to back-port fixes in the future.


Rework livemark store mechanism

It sounds to me that the onChanged listener is causing trouble here. Getting rid of it would probably help with memory/CPU/crash issues.
Here's a proposed list of changes:

[ ] Remove strange StoredMap data structure and just inline all that code into LivemarkStore
[ ] Possibly centralize storage writes to only one thread (background page), but allow reads from any thread. So change events would only come from background page

@evilpie What do you think ? Can you think of any other changes to make ?

I think most importantly if we ever want to re-enable sync, is that we somehow prevent write->change event->write cycles. Where outside the background page do we access storage? Do you mean the settings page.

@evilpie We read storage on the settings page + the background page. We write to storage from the settings page and from the reader page (Add Livemark button).

I think one thing that may be worth doing is simply use runtime messaging instead of the onChange listener. Since every part of the UI knows when it changes storage, they can just send an explicit message, instead of having the other side wait for a onChange listener.


Converted old 'arrow'-style hashes to new style.

I took the chance to update the views to the symbol style hashes, as I didn't see any reason why they shouldn't be updated.

Thanks @jeroenvisser101

Thanks for being so super quick!

:+1:


Add instructions for adding authorization to your controllers #11777

Do these changes to the doc make it more clear how authorization should be implemented in controllers?

Thanks!


Kibana Milestones Vis 7.3.1 Release

Hello,
Thank you for your work, the plugin looks interesting and I wanted to try it but my environment is Elasticsearch and Kibana version 7.3.1.
Do you have plans to make a plugin compatible?
Thank you!

Hey! Yes, a release is planned. Kibana 7.2.0 had quite some changes how its API works so this update takes a bit more time but I'm working on it.

Hello, these are great news! Anything I could help, please do not hesitate to request.

Believe it or not, 7.3.1 is out the door: https://github.com/walterra/kibana-milestones-vis/releases/tag/v7.3.1


Update README supabase/auth to supabase/gotrue

What kind of change does this PR introduce?
docs update
What is the current behavior?
404 on page opens
What is the new behavior?
opens repository page
Additional context

Hey the links will continue to work once we rename the repo which should happen today.

We're delaying the rename for a while. Merging this.


feat: Schema-driven visual editor - migrates 15 simple types

UI schema Implementation Plan

[x] stage 1 (current) - support basic rendering with uischema definition

set up uischema definition & implement a generic renderer based on uischema
covered $types: 15 simple $types, such as LogAction

[ ] stage 2 - support complicated content rendering

extract more widget to support complicated node content
covered $types: SendActivity, CallDialog, BeginDialog

[ ] stage 3 - support multiple nodes rendering

implement a InputWidget which looks like current BaseInput
covered $types: all input $types, such as TextInput, NumberInput (but exclude OauthInput)

[ ] stage 4 - support nested uischema definition

extend 'uischema''s definition to support rendering nested $types such as IfConditon, Foreach
covered $types: branching - IfCondtion, SwitchConditon; loop - Foreach, ForeachPage;

Description
fixes #1770
Use an uischema definition to define visual nodes' rendering process.
Schema is defined like this:
[SDKTypes.EditArray]: {
    'ui:widget': ActionCard,
    title: generateSDKTitle(),
    content: data => `${data.changeType} {${data.itemsProperty || '?'}}`,
},

[SDKTypes.EndTurn]: {
    'ui:widget': ActionCard,
    title: 'End Dialog Turn',
    content: 'Wait for another message',
}

This pr retires DefaultRenderer and migrates 15 Adaptive types to the new uischema renderer:

[x] 1. EditArray
[x] 2. InitProperty
[x] 3. SetProperty
[x] 4. SetProperties
[x] 5. DeleteProperty
[x] 6. EndDialog
[x] 7. CancelAllDialogs
[x] 8. EndTurn
[x] 9. EmitEvent
[x] 10. HttpRequest
[x] 11. TraceActivity
[x] 12. LogAction
[ ] 13. EditActions (not available in Composer)
[x] 14. QnAMakerDialog
[x] 15. OAuthInput

4 $types are influenced by this migration:

[x] 1. SwitchCondition (add <ConditionNode />)
[x] 2. IfCondition (add <ConditionNode />)
[x] 3. Foreach (add <ForeachDetail />)
[x] 4. ForeachPage (add <ForeachPageDetail />)

To make sure this PR won't bring any different behavior,

[x] I've checked the render results of all those $types listed above.

Task Item
resolves #1770
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Code refactor (non-breaking change which improve code quality, clean up, add tests, etc)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Doc update (document update)

Checklist

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have functionally tested my change

Screenshots
Please include screenshots or gifs if your PR include UX changes.

I've resolved those formatMessage comments but not very sure about the solution on resolving sdk title, @a-b-r-o-w-n what's your opinion on my comments?

Made some improvements


Implement "feign" modifier to regular beats

Just opening this here for visibility.
Feign notes appear to go in a specific direction (HitObject.Angle + 180), before rotating back to the correct direction halfway to the circle.
Currently can be set via a bool value, as I personally think that this is more a modifier than an actual note type, seeing as it could also be applied to other notes such as BigBeat.
Footage of the note in action (It replaces all notes simply for demonstration purposes):
https://streamable.com/lbvj1e
TODO before this could even be considered ready, discussion preferably in the server:

[ ] Differentiate visual to not look exactly the same as regular beat (perhaps a colour change)
[ ] Consider when this modifier should be used in the context of beatmaps converted from std

The whole idea is that this gets implemented as a unique note type to complement the existing beat types (to spice things up a bit), and not meant to change all the notes.
Would you like to continue this discussion on Discord?


Enforce field uniqueness in selections

I'm not super sure what this means. Is this to catch a query like this:
{
  a
  a
  b
}

?

It's kind of detailed actually.  I'll try to sum up:
Handle fragment spreads
e.g. This is a valid query:
{
  foo
  bar
  ... myFrag
}

fragment myFrag {
  bar
  qux
}

And the output should look something like:
{
  "foo": 1,
  "bar": 2,
  "qux": 3,
}

Aggregate identical fields
e.g.
{
  a
  b
  b
}

Should just be processed as if it were:
{
  a
  b
}

Bork on non-identical fields
{
  a
  b
  b(1)
}

Relevant parts of the spec:

https://facebook.github.io/graphql/#sec-Field-Selection-Merging
https://facebook.github.io/graphql/#sec-Field-Collection
https://facebook.github.io/graphql/#sec-Value-Completion (esp. MergeSelectionSet)

Reason all these are together is because the implementation for all of them will involve changing the type of SelectionSet in validation. Currently, it's a list of Selection, but it'll probably become some sort of OrderedMap or at least something more structured.
Probably also FragmentSpread will disappear from the fully-resolved type, which will be a mercy.
Anyway, as you can guess from this commentary, I'm at the level where it's easier for me to code it than to explain it.

Also!
{
  a {
    foo
  }
  a {
    bar
  }
}

=>
{
  "a": {
    "foo": 1,
    "bar": 2
  }
}

The way this works in the spec is that validation confirms that everything is mergeable and at execution each selection set gets flattened to fields only (one level at a time), and then evaluated.
The natural thing to do in our approach would be to flatten everything in the validator, but we this doesn't chime with the way we're doing unions (which I understand less now than I did before I started reading the spec).
Will continue to mull.

Here's where I've got to conceptually. Don't know how this fits into our code.

after validation, each selection set will be a thing that contains:

fields
inline fragments with type conditions
no fragment spreads
i.e. a slightly narrower Selection (with no need for spread type parameter!)

although validation can check for uniqueness across those, it'll be extremely difficult to construct a value that guarantees uniqueness (e.g. a map)
however, instead of thinking of it like a mixed bag of Selection as we currently do, we can think of is like a function: TypeName -> OrderedMap FieldName Field

that is, once we know the type that the selection set is for, we can immediately flatten it to an ordered map of unique fields
might be an error condition in the type too, if the type name is not one that's in the selection set
if we do this, the Resolver becomes a thing that operates only on SelectionSets and Fields—a nice property, IMO—also eliminates possibility of duplicate fields and gives us the merging behaviour above "for free"

Still mulling though.
I think this (and lots of other things) will be easier with end-to-end, which will allow for easier experimentation.

Thanks, that was useful! My initial reaction is that after FragmentSpread has been resolved it should be possible to rewrite the nested SelectionSets into a single, well-formed SelectionSet query, including union for which we can treat each InlineFragment separately: it's a sum type and we'll chose exactly one. I'm sure I'm missing something so let's chat tomorrow!

After discussing this in person we can probably implement this by rewriting the selectionSet in the HasGraph m (API.Union unionName objects) instance. Whether we do that by making all selectionSets a function that take e.g. a PickBranch Name or whether we do that locally in just the Union instance depends on which design will be easier in the end.

I have a branch for this in progress. Can do basic leaf/non-leaf validation
without schema and can do pretty solid validation + nice API for resolver
with schema
On Sun, 22 Jan 2017 at 14:34, teh<EMAIL_ADDRESS>wrote:

After discussing this in person we can probably implement this by
rewriting the selectionSet in the HasGraph m (API.Union unionName objects)
instance. Whether we do that by making all selectionSets a function that
take e.g. a PickBranch Name or whether we do that locally in just the
Union instance depends on which design will be easier in the end.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/jml/graphql-api/issues/59#issuecomment-274334411, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHq6taGm6k6-Zu5XjPms5gUS5lon91kks5rU2jZgaJpZM4LZPjI
.


Deploying smart contract from template fails due to an unknown interface version

Following the deployment example from the documentation deploying the smart contract generated by this template fails:
Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: Error calling the VM: Error during static Wasm validation: Wasm contract has unknown interface_version_* marker export (see https://github.com/CosmWasm/cosmwasm/blob/main/packages/vm/README.md): create wasm contract failed: invalid request

It seems like this starts with this commit which upgrades the cosmwasm-std version to 1.0.0-beta. Rolling the dependencies back to:
cosmwasm-std = { version = "0.16" }
cosmwasm-storage = { version = "0.16" }
cw-storage-plus = "0.9"
cw2 = "0.9"

Appears to resolve the issue.

This is for Terra.
Terra uses 0.16.
The main branch targets latest cosmwasm 1.0.0-beta as it should.
Please follow the Readme and use --branch 0.16 which is what Terra uses.
If you want to make a pr to the Readme saying this, I'd merge it

This is a docs issue actually...
https://docs.cosmwasm.com/docs/0.16/getting-started/installation refers to wasmd 0.18!
We need to either explicitly refer to the old branch in those docs, or update docs to use wasmd 0.20, which is 1.0-beta.
@orkunkl can you take a hand on this?

Hi @ethanfrey
I have the following issue for 0.18.0 version of wasmd and for 0.20.0-18-g14e58bf as well
I followed steps from this docs: https://docs.cosmwasm.com/dev-academy/develop-smart-contract/intro#start-with-a-template
But when I make RES=$(wasmd tx wasm store artifacts/my_first_contract.wasm --from wallet $TXFLAG -y), I have the following issue:
Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: Error calling the VM: Error during static Wasm validation: Wasm contract has unknown interface_version_* marker export (see https://github.com/CosmWasm/cosmwasm/blob/main/packages/vm/README.md): create wasm contract failed: invalid request

@sp41mer still looks like version mismatch, we release CosmWasm docs 1.0 https://docs.cosmwasm.com/docs/1.0. You can use uni juno testnet for testing with cosmwasm version 1.0

@ezekiiel can you close the issue after you verify it is resolved?

Recently did this here and it all worked fine out of the box. Seems good to me :) Thanks!

Still having this issue. Followed steps described in the docs here: https://docs.terra.money/docs/develop/guides/smart-contracts/write-smart-contract.html
As stated in docs it refers to branch 0.16:

cargo generate --git https://github.com/CosmWasm/cw-template.git --branch 0.16 --name my-first-contract
cd my-first-contract

But when deploying to localterra I get this error:

$ terrad tx wasm store artifacts/my_first_contract.wasm --from test1 --chain-id=localterra --gas=auto --fees=100000uluna --broadcast-mode=block
Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: Error calling the VM: Error during static Wasm validation: Wasm contract has unknown interface_version_* marker export (see https://github.com/CosmWasm/cosmwasm/blob/main/packages/vm/README.md): create wasm contract failed: invalid request

@taitruong probably localterra cw vm version and contract cw version do not match

@orkunkl in which file can I check which version localterra is using?


wazero support compile python?

package main

import (
	"context"
	"embed"
	_ "embed"
	"io/fs"
	"log"

	"github.com/tetratelabs/wazero"
	"github.com/tetratelabs/wazero/wasi_snapshot_preview1"
)

//go:embed testdata/env.py
var envPy embed.FS

//go:embed testdata/bin/python3.wasm
var greetWasm []byte

func main() {
	ctx := context.Background()

	// 新建一个 wasm 运行时
	r := wazero.NewRuntimeWithConfig(ctx, wazero.NewRuntimeConfig().
		WithWasmCore2())
	defer r.Close(ctx)

	// 实例化一个名为“env”的 Go 定义的模块，该模块导出一个函数以记录到控制台
	_, err := r.NewModuleBuilder("env").
		Instantiate(ctx, r)
	if err != nil {
		log.Panicln(err)
	}

	if _, err = wasi_snapshot_preview1.Instantiate(ctx, r); err != nil {
		log.Panicln(err)
	}

	code, err := r.CompileModule(ctx, greetWasm, wazero.NewCompileConfig())
	if err != nil {
		log.Panicln(err)
	}

	rooted, err := fs.Sub(envPy, "testdata")
	if err != nil {
		log.Panicln(err)
	}

	config := wazero.NewModuleConfig().WithFS(rooted)

	env := config.
		WithEnv("PYTHONHOME", "testdata/lib/python3.11").
		WithEnv("PYTHONPATH", "testdata/lib/python3.11")
	if _, err = r.InstantiateModule(ctx, code, env); err != nil {
		log.Panicln(err)
	}
}

I Already have a python3.wasm，I want to run the env.py on the python3.wasm
Use wasmer run testdata/bin/python3.wasm --mapdir /::./ --env 'PYTHONHOME=testdata/lib/python3.11' --env 'PYTHONPATH=testdata/lib/python3.11' -- testdata/env.py command is ok
But use wazero will appear error
2022/08/26 16:20:41 module "" closed with exit_code(1)
panic: module "" closed with exit_code(1)

goroutine 1 [running]:
log.Panicln({0xc001255e40?, 0x11b2bd0?, 0xc0000000d8?})
        /usr/local/go/src/log/log.go:399 +0x65
main.main()
        /Users/bytedance/goProject/src/code.byted.org/chenmin.tate/wasm_project/python/greet.go:57 +0x50f
exit status 2

May be I have a problem of the usage，ask for help～

I tested it and the mapdir is missing

wamser-go的example:

wasmer has the MapDirectory is similar to the wasmer-go?
wasmBytes, _ := ioutil.ReadFile("module.wasm")

	store := wasmer.NewStore(wasmer.NewEngine())
	module, _ := wasmer.NewModule(store, wasmBytes)

	wasiEnv, _ := wasmer.NewWasiStateBuilder("wasi-program").
		// Choose according to your actual situation
		// Argument("--foo").
		// Environment("ABC", "DEF").
		// MapDirectory("./", ".").
		Finalize()

The way to grant access to files is via WithFS and you can only give one fs.FS.
Do you mind making a GitHub repo with this project or something similar in it (using the same wasm), as it will be easier to identify what's going on. Particularly, you can use the experimental logging filter to see where it crashes.
If you open that repo, you can ping me on an issue there and I can help you troubleshoot over the next couple days (free time). this will reduce the amount of spam here, then if we find a solution we can report back what it was here.

Is the current version ready for production?
My main requirement is: wasm and go communicate with each other through linear memory

@mougeCM wazero will have a beta release end of this month and 1.0 is scheduled for early next year. We don't test python yet so I wouldn't recommend thinking it is ready for production. This is also why I asked you if you can create a demo repo so I can help you figure out where the problem exists. For example, some language compilers are better for troubleshooting, for example, having helpful error messages to tell if some problem is due to an unimplemented syscall  in wazero, or some undefined behavior or something else. You are the first to ask about python, so until at least your demo works and you can know why it does or doesn't in the context of python I wouldn't recommend using it :D

Also it seems python and wasm is very much a work in progress. There are two different ways that wasm might have been built, ex via emscripten or wasi. Without knowing the source and how the wasm binary was compiled, we can't guess what's going on. Can you mention how you downloaded or compiled python3.wasm? This is an example of what can be in the troubleshooting repo
https://pythondev.readthedocs.io/wasm.html#wasi

Taking a guess that this is using what seems to be the de'facto python build from https://github.com/singlestore-labs/python-wasi (25MB of python3.11.wasm), I would say it is likely that an error is due to less syscalls (WASI) supported in wazero vs what it imports.
Since it is a dynamic language it is hard to tell which you are hitting. It also remains curious what the error is.  My current first job is connecting to Go (Host: Go, SandBox: Go). Can the current beta support my production needs?

Runing Python in WebAssembly: https://www.fermyon.com/blog/python-wagi
python3.wasm from: https://github.com/fermyon/wagi-python/tree/main/opt/wasi-python/bin

What is "connecting"? If that is "wasm and go communicate with each other through linear memory": you can use Memory() (https://github.com/tetratelabs/wazero/blob/06ad22f33fc4/api/wasm.go#L140-L141) to read/write data direct into the memory, without any WASI requirement. Of course, the "memory" contains the wasm controlled information, so you can't write at random places. You need to create some slice on the guest-side, then give the pointer to the host (calling exported function, or exporting a function to be called), then you can write that into that specific index, using something like: Memory().Write(context.Background(), uint32(index_from_guest), []byte{....}).
I'm currently using Wazero with 7 different languages (TinyGo, Zig, AssemblyScript, Odin, .NET, Swiftwasm, C), and I'm writing/reading that using the Memory(), and calling exported functions to get the indexes of the array. So, Wazero is capable to do that, and already have examples exchanging data.
If you want to "connect" by calling some WASI Filesystem, then that is another history. I never used that feature, but I think Wazero supports that too.

Accessing python is my second job. My current first job is connecting to Go (Host: Go, SandBox: Go). Can the current beta support my production needs?

@mougeCM In summary, you can use wazero now, but anything you use in production should be tested by you. Until wazero turns 1.0 in Feb there's a chance of API changes, but we hope to not have too many breaks.
The beta that will be released in the next couple days is already in use, ex by Trivy, anyone using waPC as well projects GitHub knows about and those it doesn't.
 If you mean normal Go as in GOARCH=wasm GOOS=js, it is not often used.
I would recommend reading https://wazero.io/languages/ on the language choice you feel dominant. For support, wazero isn't well placed to support the guest side deep on every language, that's why we have links to their support. Support includes the libraries you use also, and ones that are tested with wazero, like https://github.com/inkeliz/karmem, are likely to have a better experience.
Meanwhile, this is an issue and typically we use issues for things like code changes, not open questions. Please watch this repo for updates as when we release our beta we'll mention a chat channel for use.

I ran into this as well when attempting to run CPython 3.11's new wasm target in wazero (https://docs.python.org/3/whatsnew/3.11.html#build-changes).
My reproduction steps:
$ git clone https://github.com/python/cpython.git
$ git checkout 3.11 # v3.11.0 release has issues, checkout patch branch for now
$ git rev-parse HEAD
2d5f4ba17480c1f883a0822c90af25d2ec9bf7ed
$ WASI_SDK_PATH=../wasi-sdk-16.0 ./Tools/wasm/wasm_build.py wasi
...
# Before building the stdlib, need to make sure it is not compressed
# That seems to work for the emscripten target, but not wasi.
$ git apply - <<-EOF
diff --git a/Tools/wasm/wasm_assets.py b/Tools/wasm/wasm_assets.py
index 6557e3f37a..7a1696d700 100755
--- a/Tools/wasm/wasm_assets.py
+++ b/Tools/wasm/wasm_assets.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 """Create a WASM asset bundle directory structure.

 The WASM asset bundles are pre-loaded by the final WASM build. The bundle
@@ -232,8 +232,8 @@ def main():

     # bpo-17004: zipimport supports only zlib compression.
     # Emscripten ZIP_STORED + -sLZ4=1 linker flags results in larger file.
-    args.compression = zipfile.ZIP_DEFLATED
-    args.compresslevel = 9
+    args.compression = zipfile.ZIP_STORED
+    args.compresslevel = 0

     args.builddir = get_builddir(args)
     args.sysconfig_data = get_sysconfigdata(args)
EOF
$ cd builddir/wasm
$ make wasm_stdlib
...

Where wasmtime can drop me into a repl
$ wasmtime --mapdir /usr/local/lib::usr/local/lib python.wasm
Python 3.11.0+ (heads/3.11-dirty:2d5f4ba174, Dec  1 2022, 15:50:36) [Clang 14.0.4 (https://github.com/llvm/llvm-project 29f1039a7285a5c3a9c353d05414 on wasi
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

Whereas with wazero:
$ go install github.com/tetratelabs/wazero/cmd/wazero@latest
go: downloading github.com/tetratelabs/wazero v1.0.0-pre.4
$ wazero run --mount usr/local/lib:/usr/local/lib/ python.wasm
Fatal Python error: init_sys_streams: can't initialize sys standard streams
Python runtime state: core initialized
OSError: [Errno 8] Bad file descriptor

Current thread 0x00000000 (most recent call first):
  <no Python frame>

Using<EMAIL_ADDRESS>I added a small listener that would print every time def.ModuleName() == "wasi_snapshot_preview1", I can see at least the following thing marked as missing in https://wazero.io/specs/#webassembly-system-interface-wasi are called:
wasi_snapshot_preview1.fd_fdstat_get
wasi_snapshot_preview1.fd_readdir
wasi_snapshot_preview1.path_filestat_get
wasi_snapshot_preview1.path_readlink

$ wasm-objdump --section 'import' --details python.wasm
python.wasm:    file format wasm 0x1

Section Details:

Import[43]:
 - func[0] sig=1 <__imported_wasi_snapshot_preview1_args_get> <- wasi_snapshot_preview1.args_get
 - func[1] sig=1 <__imported_wasi_snapshot_preview1_args_sizes_get> <- wasi_snapshot_preview1.args_sizes_get
 - func[2] sig=1 <__imported_wasi_snapshot_preview1_environ_get> <- wasi_snapshot_preview1.environ_get
 - func[3] sig=1 <__imported_wasi_snapshot_preview1_environ_sizes_get> <- wasi_snapshot_preview1.environ_sizes_get
 - func[4] sig=1 <__imported_wasi_snapshot_preview1_clock_res_get> <- wasi_snapshot_preview1.clock_res_get
 - func[5] sig=23 <__imported_wasi_snapshot_preview1_clock_time_get> <- wasi_snapshot_preview1.clock_time_get
 - func[6] sig=24 <__imported_wasi_snapshot_preview1_fd_advise> <- wasi_snapshot_preview1.fd_advise
 - func[7] sig=25 <__imported_wasi_snapshot_preview1_fd_allocate> <- wasi_snapshot_preview1.fd_allocate
 - func[8] sig=0 <__imported_wasi_snapshot_preview1_fd_close> <- wasi_snapshot_preview1.fd_close
 - func[9] sig=0 <__imported_wasi_snapshot_preview1_fd_datasync> <- wasi_snapshot_preview1.fd_datasync
 - func[10] sig=1 <__imported_wasi_snapshot_preview1_fd_fdstat_get> <- wasi_snapshot_preview1.fd_fdstat_get
 - func[11] sig=1 <__imported_wasi_snapshot_preview1_fd_fdstat_set_flags> <- wasi_snapshot_preview1.fd_fdstat_set_flags
 - func[12] sig=1 <__imported_wasi_snapshot_preview1_fd_filestat_get> <- wasi_snapshot_preview1.fd_filestat_get
 - func[13] sig=26 <__imported_wasi_snapshot_preview1_fd_filestat_set_size> <- wasi_snapshot_preview1.fd_filestat_set_size
 - func[14] sig=24 <__imported_wasi_snapshot_preview1_fd_filestat_set_times> <- wasi_snapshot_preview1.fd_filestat_set_times
 - func[15] sig=27 <__imported_wasi_snapshot_preview1_fd_pread> <- wasi_snapshot_preview1.fd_pread
 - func[16] sig=1 <__imported_wasi_snapshot_preview1_fd_prestat_get> <- wasi_snapshot_preview1.fd_prestat_get
 - func[17] sig=3 <__imported_wasi_snapshot_preview1_fd_prestat_dir_name> <- wasi_snapshot_preview1.fd_prestat_dir_name
 - func[18] sig=27 <__imported_wasi_snapshot_preview1_fd_pwrite> <- wasi_snapshot_preview1.fd_pwrite
 - func[19] sig=4 <__imported_wasi_snapshot_preview1_fd_read> <- wasi_snapshot_preview1.fd_read
 - func[20] sig=27 <__imported_wasi_snapshot_preview1_fd_readdir> <- wasi_snapshot_preview1.fd_readdir
 - func[21] sig=28 <__imported_wasi_snapshot_preview1_fd_seek> <- wasi_snapshot_preview1.fd_seek
 - func[22] sig=0 <__imported_wasi_snapshot_preview1_fd_sync> <- wasi_snapshot_preview1.fd_sync
 - func[23] sig=1 <__imported_wasi_snapshot_preview1_fd_tell> <- wasi_snapshot_preview1.fd_tell
 - func[24] sig=4 <__imported_wasi_snapshot_preview1_fd_write> <- wasi_snapshot_preview1.fd_write
 - func[25] sig=3 <__imported_wasi_snapshot_preview1_path_create_directory> <- wasi_snapshot_preview1.path_create_directory
 - func[26] sig=8 <__imported_wasi_snapshot_preview1_path_filestat_get> <- wasi_snapshot_preview1.path_filestat_get
 - func[27] sig=29 <__imported_wasi_snapshot_preview1_path_filestat_set_times> <- wasi_snapshot_preview1.path_filestat_set_times
 - func[28] sig=17 <__imported_wasi_snapshot_preview1_path_link> <- wasi_snapshot_preview1.path_link
 - func[29] sig=30 <__imported_wasi_snapshot_preview1_path_open> <- wasi_snapshot_preview1.path_open
 - func[30] sig=16 <__imported_wasi_snapshot_preview1_path_readlink> <- wasi_snapshot_preview1.path_readlink
 - func[31] sig=3 <__imported_wasi_snapshot_preview1_path_remove_directory> <- wasi_snapshot_preview1.path_remove_directory
 - func[32] sig=16 <__imported_wasi_snapshot_preview1_path_rename> <- wasi_snapshot_preview1.path_rename
 - func[33] sig=8 <__imported_wasi_snapshot_preview1_path_symlink> <- wasi_snapshot_preview1.path_symlink
 - func[34] sig=3 <__imported_wasi_snapshot_preview1_path_unlink_file> <- wasi_snapshot_preview1.path_unlink_file
 - func[35] sig=4 <__imported_wasi_snapshot_preview1_poll_oneoff> <- wasi_snapshot_preview1.poll_oneoff
 - func[36] sig=7 <__imported_wasi_snapshot_preview1_proc_exit> <- wasi_snapshot_preview1.proc_exit
 - func[37] sig=2 <__imported_wasi_snapshot_preview1_sched_yield> <- wasi_snapshot_preview1.sched_yield
 - func[38] sig=1 <__imported_wasi_snapshot_preview1_random_get> <- wasi_snapshot_preview1.random_get
 - func[39] sig=3 <__imported_wasi_snapshot_preview1_sock_accept> <- wasi_snapshot_preview1.sock_accept
 - func[40] sig=16 <__imported_wasi_snapshot_preview1_sock_recv> <- wasi_snapshot_preview1.sock_recv
 - func[41] sig=8 <__imported_wasi_snapshot_preview1_sock_send> <- wasi_snapshot_preview1.sock_send
 - func[42] sig=1 <__imported_wasi_snapshot_preview1_sock_shutdown> <- wasi_snapshot_preview1.sock_shutdown

While fd_fdstat_get is marked as implemented in https://wazero.io/specs/#webassembly-system-interface-wasi, the implementation seems incomplete:
https://github.com/tetratelabs/wazero/blob/40e698e068d9daa98a1660b7a0a31a1886ec3691/imports/wasi_snapshot_preview1/fs.go#L171
I took a bit of a stab at implementing the stat & readdir related ones in imports/wasi_snapshot_preview1/fs.go, but I realized quickly that it's not as straightforward as I'd hoped. I could get something to work by making the fs.FS in sys.FSContext public, I figured that that this would be a good time to start asking for help.
Is this something you'd be open to guiding an external contributor through or may be easier done by people more familiar with wazero?

Whoa, I now see that https://github.com/tetratelabs/wazero/pull/865, https://github.com/tetratelabs/wazero/pull/858 & https://github.com/tetratelabs/wazero/pull/838 all went in in the last few days! This is really great!
The CustomListenerFactory that I had attached was actually when I was on the v1.0.0-pre.3 release. I'll update and see if I can more concretely pinpoint what is missing!

It seems like

https://github.com/tetratelabs/wazero/blob/40e698e068d9daa98a1660b7a0a31a1886ec3691/imports/wasi_snapshot_preview1/fs.go#L171-L175
https://github.com/tetratelabs/wazero/blob/40e698e068d9daa98a1660b7a0a31a1886ec3691/imports/wasi_snapshot_preview1/fs.go#L278-L279

Need to special case the fd numbers for stdin/stdout/stderr. Once I have those write stat results indicating they are a character device with read/write rights python recognizes them as tty and drops me into a wazero based repl. I would have to read up more on exactly how the rights work before I could make a PR, I may get to that later but wanted to share in case anyone else is more familiar.

@robbertvanginkel excellent work! ps "rights" has been dropped from wasi and no one implements it, so you can ignore it. It is a goal to complete python and finally seems we have some action to take!
It would be grand if you are up to completing the impl, but either way this helps. Keep us posted here or on gophers slack #wazero-dev channel.

I forget if you are already there (if not, you may need an invite to join gophers).

I'll implement fdstat today, as I ran into it for another reason

@robbertvanginkel please against https://github.com/tetratelabs/wazero/pull/895 or after merge!

@robbertvanginkel also, if you get a chance, can you check if latest cpython still needs hacks for wasi to build correctly? at some point would be nice if some version of python+wasi works and can be published somewhere without instructions

The repl works now!
$ go install github.com/tetratelabs/wazero/cmd/wazero@main
$ wazero run --mount usr/local/lib:/usr/local/lib/ python.wasm
Python 3.11.0+ (heads/3.11-dirty:2d5f4ba174, Dec  7 2022, 11:12:35) [Clang 14.0.4 (https://github.com/llvm/llvm-project 29f1039a7285a5c3a9c353d05414 on wasi
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 + 1
2
>>>

In addition to fixing python, it actually also fixed a stat thing I was running into when using SwiftWasm so double thanks 🎉
Python does sort of work without patches, on a fresh build from the cpython repo this does work:
$ wazero run -env PYTHONPATH=/builddir/wasi/build/lib.wasi-wasm32-3.11:/Lib -mount /Users/robbert/dev/cpython:/ builddir/wasi/python.wasm
Python 3.11.0+ (heads/3.11-dirty:2d5f4ba174, Dec  7 2022, 11:30:37) [Clang 14.0.4 (https://github.com/llvm/llvm-project 29f1039a7285a5c3a9c353d05414 on wasi
Type "help", "copyright", "credits" or "license" for more information.
>>>

This works for development, but bundling a stdlib makes more sense for a deployment. zlib support for the wasi build is tracked in https://github.com/python/cpython/issues/93819, once that's fixed the output of make wasm_stdlib should work without modifications.

https://github.com/python/cpython/issues/93819 doesn't seem to be going anywhere, so I raised this PR instead to close out the issue. Thanks all, for the attention! https://github.com/fermyon/wagi-python/pull/4

updates:

there seems more maintenance upstream despite the zlib thing outstanding https://github.com/python/cpython/pull/101003
there's another build curated by vmware, though I've not tried it with wazero https://github.com/vmware-labs/webassembly-language-runtimes/tree/main/python

@mougeCM @robbertvanginkel if either of you have time, I'm curious what use cases you have, or have heard of, for an embedded python interpreter.
Is it for the repl, or for a script? Are the interesting parts sandboxing, or embedding or something else? Have you needed or tried packages or otherwise custom libraries?
I'm nervous about saying game over because we can start the repl. In zig and tinygo, we currently run the stdlib OS tests which raise confidence that most things work (or are known to not work due to things outside our control, such as syscalls unmapped to wasi, etc). I wonder how we can achieve confidence python works.
Anyway, any thoughts appreciated!

wrt https://github.com/vmware-labs/webassembly-language-runtimes/tree/main/python
I personally can't get the non-wasmedge variant working, as it errs like below. Their docker image is also wasmedge-specific which clashes with signatures in normal wasi.  For now, best to use fermyon until those things sort out.
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Our python usecase is to run a script as a plugin to our protobuf compiler.
The high level is that protobuf is a language independent schema format, in which most language bindings are generated from plug-in binaries that reads an encoded form of the schema from stdin and writes generated code as an encoded message to stdout. There's an existing ecosystem in out there that we'd like to support where instead of looking up native binaries from a user's PATH, we allow them to specify a single wasm file and run that instead.
For python (and other interpreted languages like js) we currently compile the interpreter to a wasm file, bundle the stdlib and plugin code (packaged as a pyz with zipapp) in a custom wasm section. We read that out and make it available to wazero before starting the run. Using the build script I provided to the python team at https://github.com/python/cpython/issues/93819#issuecomment-1384541880 to compile with zlib support, this works well for us!

curious what's left to close this?

It was blocking on https://github.com/python/cpython/issues/93819, but really this is incidental to wazero. We can close it and someone can know that once ^^ is resolved the normal cpython build can work instead of relying on community repackaging


[quickstarts] Make code snippets consistent; link to repo

Signed-off-by: Hannah Hunter<EMAIL_ADDRESS>Description

Link to quickstarts repo
Make code snippets consistent w dapr client

Issue reference
PR will close: #2339

I have to say this, but not a fan of the "we" and "our" repo, since who are we and the repo is community owned in essence. Can we change "Clone the [sample we've provided in our quickstarts repo]" to "Clone the [sample in the Quickstarts repo]"
Also note the Capital "Q" for Quickstarts :-)

@hhunter-ms Looks like also need to update the pubsub Quickstarts. You only updated Service Invocation


Modifications
Discard invalid readers and producers for producer state manager snapshot topics.
Documentation
Check the box below.
Need to update docs?

[ ] doc-required
(If you need help on updating docs, create a doc issue)

[x] no-need-doc
(Please explain why)

[ ] doc
(If this PR contains doc changes)

spotbugs-check problem https://github.com/spotbugs/spotbugs/issues/1001


Conflict when using google maps sdk plugin

Hi, recently i tried to use this plugin  in one of my projects, but when i installed and try to build,  a merge conflit error with the com.google.android.geo.API_KEY, I'm also using google maps sdk plugin.. any advise?

Manifest merger failed : Attribute meta-data#com.google.android.geo.API_KEY@value value=(@string/nativescript_google_maps_api_key) from AndroidManifest.xml:9:13-69
is also present at AndroidManifest.xml:9:13-30 value={api key}.
Suggestion: add 'tools:replace="android:value"' to  element at AndroidManifest.xml:7:9-9:72 to override.

I tried to use the tools:replace, but i guess i'm using it in the wrong way

Hi,
This is because the api_key conflicted with google maps sdk plugin. My solution is remove one of the api key (google maps sdk plugin api key). Edit the plugin's Android Manifest (not application Manifest) at directory node_modules/nativescript-google-maps-sdk/platforms/android/AndroidManifest.xml
remove <meta-data .... /> tag inside the <application></application>
and then rebuild the app.


0.10 Release Snapshot Issue

We recently upgraded to 0.10 Release snapshot (taken codebase on Thursday- 09th March 2017)  and i noticed one strange thing when i used KAFKA Indexing Service.
For one of the KAFKA Indexing Supervisor it is not committing the data to segment (I have not mentioned any task duration so it should take it as default which is 1 HOUR PT1H). It is running since last many hours now and not started committing the data yet.
Please let me know if there is any open issue with respect to kafka indexing service or if you need any logs to investigate this further.

There isn't a known issue. Could you please provide some more details including logs?

Hi Gian, we forgot to take those logs but i found some disk space issue and heavy load issue on KAFKA and it looks like that caused some issue to this supervisor which was not allowing them to close the task and start a new one.
I am observing one more strange issue - I am getting below logs after supervisor calls itself success. I see data on HDFS but them are not getting loaded on Historical. I see nothing in any of the logs for this supervisor and datasource.
2017-03-13T18:22:06,235 INFO [task-runner-0-priority-0] io.druid.indexing.worker.executor.ExecutorLifecycle - Task completed with status: {
"id" : "index_kafka_SEGMENT_082e4a96a18542b_okmncokb",
"status" : "SUCCESS",
"duration" : 1399971
}
2017-03-13T18:22:06,244 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void
io.druid.server.coordination.AbstractDataSegmentAnnouncer.stop()] on object[io.druid.server.coordination.BatchDataSegmentAnnouncer@26c7b1c
6].
2017-03-13T18:22:06,244 INFO [main] io.druid.server.coordination.AbstractDataSegmentAnnouncer - Stopping class io.druid.server.coordination
.BatchDataSegmentAnnouncer with config[io.druid.server.initialization.ZkPathsConfig@22e2266d]
2017-03-13T18:22:06,244 INFO [main] io.druid.curator.announcement.Announcer - unannouncing [/druid/announcements/<IP_ADDRESS>:8100]
2017-03-13T18:22:06,263 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void
io.druid.server.listener.announcer.ListenerResourceAnnouncer.stop()] on object[io.druid.query.lookup.LookupResourceListenerAnnouncer@7cf8f45a].
2017-03-13T18:22:06,263 INFO [main] io.druid.curator.announcement.Announcer - unannouncing [/druid/listeners/lookups/__default/<IP_ADDRESS>:8100]
2017-03-13T18:22:06,265 INFO [main] io.druid.server.listener.announcer.ListenerResourceAnnouncer - Unannouncing start time on [/druid/listeners/lookups/__default/<IP_ADDRESS>:8100]
2017-03-13T18:22:06,265 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void io.druid.query.lookup.LookupReferencesManager.stop()] on object[io.druid.query.lookup.LookupReferencesManager@53a301f3].
2017-03-13T18:22:06,265 INFO [main] io.druid.query.lookup.LookupReferencesManager - Stopping lookup factory references manager
2017-03-13T18:22:06,272 INFO [main] org.eclipse.jetty.server.AbstractConnector - Stopped ServerConnector@4d81e83a{HTTP/1.1,[http/1.1]}{<IP_ADDRESS>:8100}
2017-03-13T18:22:06,274 INFO [main] org.eclipse.jetty.server.handler.ContextHandler - Stopped o.e.j.s.ServletContextHandler@1c1fa494{/,null,UNAVAILABLE}
2017-03-13T18:22:06,278 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void io.druid.indexing.worker.executor.ExecutorLifecycle.stop() throws java.lang.Exception] on object[io.druid.indexing.worker.executor.ExecutorLifecycle@5b1efaaf].
2017-03-13T18:22:06,279 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void io.druid.indexing.overlord.ThreadPoolTaskRunner.stop()] on object[io.druid.indexing.overlord.ThreadPoolTaskRunner@5463f035].
2017-03-13T18:22:06,280 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void io.druid.curator.discovery.ServerDiscoverySelector.stop() throws java.io.IOException] on object[io.druid.curator.discovery.ServerDiscoverySelector@ab2e6d2].
2017-03-13T18:22:06,290 INFO [main] com.metamx.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void com.met
amx.http.client.NettyHttpClient.stop()] on object[com.metamx.http.client.NettyHttpClient@31e739bf].
2017-03-13T18:22:06,307 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void io.druid.storage.hdfs.HdfsStorageAuthentication.stop()] on object[io.druid.storage.hdfs.HdfsStorageAuthentication@729c8063].
2017-03-13T18:22:06,308 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void com.metamx.metrics.MonitorScheduler.stop()] on object[com.metamx.metrics.MonitorScheduler@5a08b084].
2017-03-13T18:22:06,308 INFO [main] io.druid.curator.CuratorModule - Stopping Curator
2017-03-13T18:22:06,312 INFO [Curator-Framework-0] org.apache.curator.framework.imps.CuratorFrameworkImpl - backgroundOperationsLoop exiting
2017-03-13T18:22:06,315 INFO [main] org.apache.zookeeper.ZooKeeper - Session: 0x15ac727da6b006e closed
2017-03-13T18:22:06,315 INFO [main-EventThread] org.apache.zookeeper.ClientCnxn - EventThread shut down for session: 0x15ac727da6b006e
2017-03-13T18:22:06,315 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void com.metamx.emitter.service.ServiceEmitter.close() throws java.io.IOException] on object[com.metamx.emitter.service.ServiceEmitter@7126e26].
2017-03-13T18:22:06,315 INFO [main] com.metamx.emitter.core.LoggingEmitter - Close: started [false]
2017-03-13T18:22:06,316 INFO [main] io.druid.java.util.common.lifecycle.Lifecycle$AnnotationBasedHandler - Invoking stop method[public void io.druid.initialization.Log4jShutterDownerModule$Log4jShutterDowner.stop()] on object[io.druid.initialization.Log4jShutterDownerModule$Log4jShutterDowner@47b33e07].
2017-03-13 18:22:06,370 Thread-2 ERROR Unable to register shutdown hook because JVM is shutting down. java.lang.IllegalStateException: Not started
at io.druid.common.config.Log4jShutdown.addShutdownCallback(Log4jShutdown.java:45)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.addShutdownCallback(Log4jContextFactory.java:273)
at org.apache.logging.log4j.core.LoggerContext.setUpShutdownHook(LoggerContext.java:256)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:216)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:145)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:182)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:103)
at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:42)
at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at org.apache.hadoop.hdfs.LeaseRenewer.(LeaseRenewer.java:72)
at org.apache.hadoop.hdfs.DFSClient.getLeaseRenewer(DFSClient.java:699)
at org.apache.hadoop.hdfs.DFSClient.close(DFSClient.java:859)
at org.apache.hadoop.hdfs.DistributedFileSystem.close(DistributedFileSystem.java:853)
at org.apache.hadoop.fs.FileSystem$Cache.closeAll(FileSystem.java:2407)
at org.apache.hadoop.fs.FileSystem$Cache$ClientFinalizer.run(FileSystem.java:2424)
at org.apache.hadoop.util.ShutdownHookManager$1.run(ShutdownHookManager.java:54)

I think it is failing before it writes an entry into MySQL and that is the reason it is not loading the data in Historical.

@naman-aasaan do you have logs from the overlord that show it trying to write to MySQL and failing?
Is the supervisor active and responding to endpoints like status? See "Get Supervisor Status Report" at http://druid.io/docs/latest/development/extensions-core/kafka-ingestion.html. (supervisorId is the datasource name)

@naman-aasaan my guess is this isn't a bug, it seems more likely that you're out of disk space on historicals and that's why data isn't getting loaded. Please double-check that and reopen if you still do think this is a bug.


support for RC_CHANNELS  message

I noticed that when the SERIAL_PROTOCOL is set to 2 (Mavlink2), the RC_CHANNELS_RAW is not sent, and RC_CHANNELS  takes its place and dronekit cannot read the rc channels anymore.

Thank you very much, this helped me a lot! I did expand for channels 9-16 and it works the same.
`@vehicle.on_message('RC_CHANNELS')
def RC_CHANNEL_listener(vehicle, name, message):
# Channel 1-8 must be updated here in the simulation. Not required on real autopilot.
set_rc(1, message.chan1_raw)
set_rc(2, message.chan2_raw)
set_rc(3, message.chan3_raw)
set_rc(4, message.chan4_raw)
set_rc(5, message.chan5_raw)
set_rc(6, message.chan6_raw)
set_rc(7, message.chan7_raw)
set_rc(8, message.chan8_raw)
set_rc(9, message.chan9_raw)
set_rc(10, message.chan10_raw)
set_rc(11, message.chan11_raw)
set_rc(12, message.chan12_raw)
set_rc(13, message.chan13_raw)
set_rc(14, message.chan14_raw)
set_rc(15, message.chan15_raw)
set_rc(16, message.chan16_raw)
vehicle.notify_attribute_listeners('channels', vehicle.channels)
def set_rc(chnum, v):
	vehicle._channels._update_channel(str(chnum), v)

    print("Now I can read all my RC-channels, here is the value of ch13", vehicle.channels[13])

`
Thumbs up!

I tried setting serial protocol to 1 and it works, though. I can read the channels


Add orientation

Hi there !
Sometimes, the label for your button is too long to be displayed correctly, which results in something like this

This PR add a new parameter in the init : orientation. This parameter have the type PMAlertControllerOrientation which have the following values :
Default (this is the default value) -> The buttons will be show as for now (horizontally if 1 or 2 buttons, vertically if more than 2 buttons)
Vertical -> force the buttons to be shown vertically
Horizontal -> force the buttons to be shown horizontally
Example:

@IBAction func showVertical2Buttons(sender: AnyObject) {
        let alertVC = PMAlertController(title: "Locate your device",
             description: "Enables access to you.....",
             image: UIImage(named: "flag.png"),
             style: .Alert,
             orientation: .Vertical)

        alertVC.addAction(PMAlertAction(title: "Cancel", style: .Cancel, action: { () -> Void in
            print("Cancel")
        }))
        alertVC.addAction(PMAlertAction(title: "Allow", style: .Default, action: { () in
            print("Allow")
        }))

        self.presentViewController(alertVC, animated: true, completion: nil)
    }

which will be displayed like this

Hi @bmichotte, thank you for your contribution, but i think that all this implementation is not necessary, because there is the possibility to access to the stackview and change the axis (vertical or horizontal). In this way the popup as a default behavior, but if you want you can change the axis.
Thanks
-Paolo

Hi @Codeido, my first attempt was to use the stackview directly. There's only one problem with this which is that alertStackViewHeightConstraint is private, so if we want to use your constraint, it's not possible. Could you at least mark this var public ?

@bmichotte thanks for the suggestion. I updated the library and now alertStackViewHeightConstraint is public.
From now you can use the release 1.0.5.
Thanks
-Paolo

Thanks @Codeido