Cube creation times grow exponentially.

Cube creation time grow exponentially. In our environment its taking 7006.51 secs to create 20 empty cubes.
Steps to reproduce
Invoke simulate(session)  with a valid Atoti session.
Note: There are 2 sets. As the 2nd set of data tables use fresh look up tables, creating initial cubes is faster and then the performance degrades.
import platform
import sys
from datetime import datetime
from typing import List

import atoti as tt
from atoti.session import Session

def create_lookup_table(session: Session, table_name: str):
    key_column = f"{table_name}_key"
    value_column = f"{table_name}_value"
    session.create_table(
        table_name,
        keys=[key_column],
        types={
            key_column: tt.type.STRING,
            value_column: tt.type.STRING,
        },
    )

def create_data_cube(session: Session, table_name: str, lookup_tables: List[str]):
    key_column = f"{table_name}_key"
    value_column = f"{table_name}_value"

    all_columns = {
        key_column: tt.type.STRING,
        value_column: tt.type.STRING,
    }
    for lookup_table in lookup_tables:
        all_columns[f"{lookup_table}_key"] = tt.type.STRING
    table = session.create_table(
        table_name,
        keys=[key_column],
        types=all_columns,
    )
    for lookup_table in lookup_tables:
        table.join(session.tables.get(lookup_table), mapping={
            f"{lookup_table}_key": f"{lookup_table}_key",
        })
    session.create_cube(table)

def timed(operation: str, fn):
    started_at = datetime.utcnow()
    if not callable(fn):
        raise RuntimeError("`timed` must be invoked with a callable")
    fn()
    finished_at = datetime.utcnow()
    time_taken = format((finished_at - started_at).total_seconds(), ".2f")
    print(f"{operation} took {time_taken}s")

def simulate(session: Session):
    print(f"""
    - atoti: {tt.__version__}
    - Python: {platform.python_version()}
    - Operating System: {sys.platform}
    """)
    lookup_table_set1 = []
    for i in range(10):
        lookup_table_set1.append(f"lookup_table_set1_{i}")

    lookup_table_set2 = []
    for i in range(10):
        lookup_table_set2.append(f"lookup_table_set2_{i}")

    for lookup_table in lookup_table_set1:
        timed(f"{lookup_table} creation", lambda: create_lookup_table(session, lookup_table))

    print(f"**** Creating Cubes with {len(lookup_table_set1)} joins. Observe the times ****")
    for i in range(8):
        data_table = f"data_table_set1_{i}"
        timed(f"{data_table} creation", lambda: create_data_cube(session, data_table, lookup_table_set1))

    for lookup_table in lookup_table_set2:
        timed(f"{lookup_table} creation", lambda: create_lookup_table(session, lookup_table))

    print(f"**** Creating New Cubes with {len(lookup_table_set2)} joins. They start quickly as they use new Lookup tables ****")
    for i in range(20):
        data_table = f"data_table_set2_{i}"
        timed(f"{data_table} creation", lambda: create_data_cube(session, data_table, lookup_table_set2))

Actual Result
Cube creation time grows exponentially.
Expected Result
Cube creation time should be linear.
Environment
- atoti: 0.6.3
- Python: 3.9.7
- Operating System: darwin

Thanks for reporting this issue and sharing a reproducible case, it will help us a lot.
For context, here's what I get on my machine:

I have checked, times are equivalent with these improvements https://github.com/activeviam/atoti/pull/2968 something else must be done

First possible improvements with this internal ticket : https://support.activeviam.com/jira/browse/PIVOT-5238

Second possible improvement : https://support.activeviam.com/jira/browse/PIVOT-5239

Results using unreleased version of the core product :

    - atoti: 0.6.5.dev0
    - Python: 3.8.10
    - Operating System: linux

lookup_table_set1_0 creation took 0.24s
lookup_table_set1_1 creation took 0.03s
lookup_table_set1_2 creation took 0.01s
lookup_table_set1_3 creation took 0.01s
lookup_table_set1_4 creation took 0.01s
lookup_table_set1_5 creation took 0.01s
lookup_table_set1_6 creation took 0.02s
lookup_table_set1_7 creation took 0.01s
lookup_table_set1_8 creation took 0.02s
lookup_table_set1_9 creation took 0.02s
**** Creating Cubes with 10 joins. Observe the times ****
data_table_set1_0 creation took 0.56s
data_table_set1_1 creation took 0.57s
data_table_set1_2 creation took 0.63s
data_table_set1_3 creation took 0.68s
data_table_set1_4 creation took 0.79s
data_table_set1_5 creation took 0.76s
data_table_set1_6 creation took 0.96s
data_table_set1_7 creation took 1.23s
lookup_table_set2_0 creation took 0.09s
lookup_table_set2_1 creation took 0.10s
lookup_table_set2_2 creation took 0.11s
lookup_table_set2_3 creation took 0.10s
lookup_table_set2_4 creation took 0.10s
lookup_table_set2_5 creation took 0.11s
lookup_table_set2_6 creation took 0.10s
lookup_table_set2_7 creation took 0.12s
lookup_table_set2_8 creation took 0.13s
lookup_table_set2_9 creation took 0.11s
**** Creating New Cubes with 10 joins. They start quickly as they use new Lookup tables ****
data_table_set2_0 creation took 1.41s
data_table_set2_1 creation took 1.46s
data_table_set2_2 creation took 1.73s
data_table_set2_3 creation took 2.09s
data_table_set2_4 creation took 2.38s
data_table_set2_5 creation took 2.56s
data_table_set2_6 creation took 3.26s
data_table_set2_7 creation took 4.16s
data_table_set2_8 creation took 4.50s
data_table_set2_9 creation took 5.88s
data_table_set2_10 creation took 6.71s
data_table_set2_11 creation took 7.00s
data_table_set2_12 creation took 7.99s
data_table_set2_13 creation took 8.85s
data_table_set2_14 creation took 9.48s
data_table_set2_15 creation took 11.36s
data_table_set2_16 creation took 12.57s
data_table_set2_17 creation took 13.98s
data_table_set2_18 creation took 15.25s
data_table_set2_19 creation took 16.20s

Hello,
Improvements will be available in the next release


Skip rebuilding if not needed

Tsoding has a very cool solution to this problem, which he implements in this video: https://www.youtube.com/watch?v=wH963jJ1lRM
Basically using touch correctly. We can and should port that mechanism to Go as well. Makes sense for big projects like raylib. And thanks to Tsoding we can actually get it right! :)

Fixed with 966ff664b5c0dca5d2484a10e171ea307ba89ddd


Unable to provide webpack as a dependency for a preprocessor in karma.config file

Using->
AngularJS 1.5.7
Node 6.5.0
WebPack 3.0.0
OS : MacOS
I have configured the stryker.config file using stryker init and it is generated as follows:
module.exports = function(config){
	config.set({
		testRunner: 'karma',
		testFramework: 'jasmine',
		karmaConfigFile: 'karma.conf.js',
                coverageAnalysis: 'off',
		reporter: [
			'progress',
			'clear-text',
			'dots',
			'html',
			'event-recorder'
		],
		plugins: [
			'stryker-jasmine',
			'stryker-karma-runner',
			'stryker-html-reporter'
		]
	});
}

and in karma.conf.js as :
'use strict';

var webpackConfig = require('./config/webpack.test.config.js');

module.exports = function (config) {
	config.set({
		basePath: '',
		frameworks: ['jasmine'],
		port: 9800,
		colors: true,
		logLevel: config.LOG_INFO,
		autoWatch: false,
		browsers: ['PhantomJS'],
		singleRun: true,
		files: [
			'./node_modules/angular/angular.js',
                       // .. and some more dependencies like jquery and the
			'./test.index.js'
		],
		preprocessors: {
			'./test.index.js': ['webpack']
		},

		webpack: webpackConfig
	});
};

and in test.index.js
var __karmaWebPackManifest__ = [];

var testsContext = require.context("../unit/", true,/Spec$/);

function inManifest(path){
return __karmaWebpackManifest__.indexOf(path) >=0;
}

var runable = testsContext.keys().filter(inManifest);

if(!runnable.length){
runnable = testsContext.keys();
}

runnable.forEach(testsContext);

The webpack.test.config.js

var webpack = require('webpack');
var path = require('path');
module.exports = {
	resolve: {
		modules: [{
test:/\.js$/,
loader: 'webpack-replace',
},{
        test:/\.js$/,
        include:path.resolve('../src/'),
        exclude:/\.spec.js$/,
        loader: 'istanbul-instrumenter-loader',
}		],
	},
	plugins: [
		new webpack.ProvidePlugin({
			$: 'jquery',
			jQuery: 'jquery',
			'window.jQuery': 'jquery',
			'window.jquery': 'jquery',
                        '_':'underscore'
		}),
	],
resolve:{
       alias:{
         'angular-translate':'angular-translate/angular-translate'
                }
           }
  };

The error I m getting:
Error: No provider for "files" !  (Resolving: preprocess -> preprocessoer: webpack -> framework:jasmine -> files)
ERROR [preprocess]: Can not load "webpack"!
ReferenceError: Webpack is not defined
DEBUG [karma]: Registered a load error of type preprocessor with the name webpack
Am I missing something ?
Can you please help me for the same ?
Sorry for omitting some portions of code.

@anithashok1910 thanks for reporting this issue.
If you run stryker with logLevel: 'trace' you will be able to see the karma output. I'm particularly interested in the part where it says: [TRACE] TestRunnerChildProcessAdapter - [2018-02-08 13:36:12.522] [INFO] KarmaTestRunner - using config. Could you look that up and confirm that the expected files are present in the array.
That being said, I'm not sure if this plugin is something we can support in the long run. We're working on getting coverage analysis support for webpack and friends. That means that Stryker should be in charge of the bundling/transpiling process. Could you try to use the stryker-webpack-transpiler plugin? Your karma config would remain the same, except without "preprocessors".


chore: update SDK to v2.27.0

Description of changes:
Update SDKs to 2.25.0
removed all existing Podfile.lock files
updated all .podspec files to point to 2.25.0
updated build-support/dependencies.rb to point to 2.25.0
ran pod update everywhere to regenerate all Podfile.lock files
ran swift package resolve
Check points: (check or cross out if not relevant)
- [ ] Added new tests to cover change, if needed

[x] Build succeeds with all target using Swift Package Manager
[x] All unit tests pass
[x] All integration tests pass
- [ ] Documentation update for the change if required
[x] PR title conforms to conventional commit style
- [ ] If breaking change, documentation/changelog update with migration instructions

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #1596 (2582e30) into main (6b94016) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1596      +/-   ##
==========================================
- Coverage   59.18%   59.17%   -0.01%
==========================================
  Files         712      712
  Lines       21639    21639
==========================================
- Hits        12806    12804       -2
- Misses       8833     8835       +2

Flag
Coverage Δ

API_plugin_unit_test
62.36% <ø> (ø)

AWSPluginsCore
71.61% <ø> (ø)

Amplify
46.90% <ø> (-0.06%)
:arrow_down:

Analytics_plugin_unit_test
71.76% <ø> (ø)

Auth_plugin_unit_test
79.60% <ø> (ø)

DataStore_plugin_unit_test
76.10% <ø> (+0.01%)
:arrow_up:

Geo_plugin_unit_test
52.12% <ø> (ø)

Predictions_plugin_unit_test
26.81% <ø> (ø)

Storage_plugin_unit_test
58.04% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...s/AWSHubPlugin/Internal/HubChannelDispatcher.swift
79.41% <0.00%> (-8.83%)
:arrow_down:

...gin/Sync/InitialSync/ModelSyncedEventEmitter.swift
90.62% <0.00%> (+1.04%)
:arrow_up:

Continue to review full report at Codecov.

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


Reorganize python

I've placed this on the Beta milestone by virtue of being a dependency of #2699 (which gives us coverage testing in Python).
Due to the nature of splitting up PRs, this will have merge conflicts with #2697. We'll deal with that when we get there. My preference, though, is for #2697 to go in first, followed by a rebase and a fixup (on the paths of #2697 s:src/python/src:src/python/grpcio:g) in this PR.
cc #1149

git rebase and git cherry-pick are champs.

LGTM; waiting for Travis.

Only Ruby is failing in Travis; merging.


Helm integration test framework

This introduces helm integration tests by providing helm.Install and helm.Delete functions. Additionally, this extends the k8s module with additional functions that map better to helm. Specifically, when you install a chart, it is not obvious what name is chosen for the chart. However, you are always guaranteed to have a bunch of labels defined on the resources, so it is more common to query Kubernetes resources using the labels than directly by name with helm.
Here is the list of new functions introduced:

helm.Install: Install a helm chart onto a Kubernetes cluster
helm.Delete: Delete a deployed release from Tiller
k8s.ListPods: List pods in a given namespace
k8s.ListServices: List services in a given namespace
k8s.WaitUntilNumPodsCreated: Waits until the number of pods matching the given filters reaches the desired count.
k8s.Tunnel: A struct that can be used to create and manage port forward tunnel to a Pod.

Finally, I had to further separate out the helm tests because Tiller overloaded minikube when running with the kubernetes tests.

Ok I believe I addressed all the comments except for the concurrency issue with GetAvailablePort. I will look into that tomorrow.

Also verified the private var conversion for Tunnel struct still works with helm-kubernetes-services.

Ok I believe I addressed all the review comments, and build is passing, so going to go ahead and merge + release this!


Clean up logging

Motivation
A developer should be able to tell what's going on by following the node log. This cleans up a lot of the noise in the logs and highlights important information such as sync status. No log lines are removed, but verbosity is decreased (e.g., warn -> info, info -> debug). libp2p logs in particular are moved to warn level.
Test Plan
N/A, no logic changes
TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[ ] Update documentation as needed
[ ] Update changelog as needed

this is stale by now, closing and will revisit these later if needed.


[BUG]The required fields in API doc still not quite correct

Describe the bug
This is a followup to https://github.com/harvester/harvester/issues/890. The newly generated API doc here https://docs.harvesterhci.io/v0.3-dev/reference/api/ still not quite correct. For example, when creating SSH key pairs, apiVersion, kind, and either metadata/name or metadata/gererateName are required. But none of them have a red asterisk (*) symbol next to them.
To Reproduce
See the newly generated doc here https://docs.harvesterhci.io/v0.3-dev/reference/api/
Expected behavior
All the required field should have the red asterisk (*) symbol next to them
Support bundle
N/A
Environment:
Harvester version: 0.3-dev
Additional context

If users can use either name or generateName I think we cannot add the red asterisk to any of them. The kind and apiVersion (and the names) are from kubernetes core API and they are not required in the schema. We might need to find a hacky way to improve. For example in kubevirt docs: https://kubevirt.io/api-reference/master/definitions.html#_v1_kubevirt

Problem is if they are absent Harvester will return HTTP 422. So from end user's perspective, they are required.

Looks like the network APIs are missing as well.

The network API doc is now available here https://docs.harvesterhci.io/v0.3-dev/reference/api/
Regarding apiVersion, kind, metadata/name and metadata/gererateName as required fields. it looks good to me if I'm checking the POST command to create a KeyPair object:

@guangyee is ok for you? Maybe I can try to create/change network settings through the API?

The networking API are there. The name field still not consistent for some resources. For example, for virtualmachinetemplates, the name or generateName still required but it was marked as required.

@gitlawr Could you take a look at this please?

@guangyee I can see that the name of virtualmachinetemplates is marked as required, is there anything I am missing?

Would be awesome if we can document the metrics APIs as well. Basically API that UI uses we should have them documented in Swagger.


Correct Linea chainId and add Linea documentation

Description
Correct Linea chainId to 59144 vs 59160 and add Linea chain Ids to the documentation documentation
I am not sure/where how to validate the tests.

Resolves # (issue)
How Has This Been Tested?

Due Diligence

[ ] Breaking change
[x] Requires a documentation update
[ ] Requires a e2e/integration test update

Hey @thedarkjester ! We are not supporting the Linea chain in our RPC yet.

Wen ser ? any timelines? I see there is already a Linea ID in there which was wrong that I was also trying to update.


ss: Also run from apm_bundle with no APM_BUNDLE env var set

This will aid in adoption. If you can also just cd into the apm_bundle directory without setting the APM_BUNDLE environment variable, that would lower the barrier to entry. And apm_bundle/bin or apm_bundle/script would feel like a natural place for ss to live. Incidentally, a different name might be a good idea. Also consider a --init or --install argument for ss that can, say, check through ~/bin:/usr/local/bin:/usr/bin for a dir that you own and symlink ss into that place.
Distributing the script with apm_bundle also solves the problem of how to keep the up-to-date version distributed.

Also, we could just assume ~/src/apm_bundle and probably get 99% of people. Maybe just try a list of dirs in succession. Have some criteria for checking if it's apm_bundle, like examining the git repo or something.

Moved to https://github.com/justinforce/apm_helpers/issues/28


I75W fails to activate wireless interface using MicroPython v1.24.0, picow v1.24.0-beta1

I have two recently-purchased Interstate 75 W boards, which both fail to activate their wireless network interface when using the latest Pimoroni picow Micropython release:
MicroPython v1.24.0, picow v1.24.0-beta1 on 2024-10-31; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> import network
>>> wlan = network.WLAN(network.STA_IF)
>>> wlan.active(True)
[CYW43] Failed to start CYW43
>>> print(wlan.active())
False
>>>

Whereas the network interface was successfully activated with vanilla Micropython:
MicroPython v1.24.1 on 2024-11-29; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> import network
>>> wlan = network.WLAN(network.STA_IF)
>>> wlan.active(True)
>>> print(wlan.active())
True
>>>

I raised this on the Pimoroni forum and tried all of Hel's suggestions, without success.
After nuking the I75W flash and reloading the latest Pimoroni picow MP image, it didn't produce the error message, but still failed to activate the wireless interface.

It seems that wlan.active() returns False even when the network interface is active.
It returns True once the network is connected, mimicking the behaviour of wlan.isconnected():
MicroPython v1.24.0, picow v1.24.0-beta1 on 2024-10-31; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> import network
>>> wlan = network.WLAN(network.STA_IF)
>>> wlan.active(True)
>>> print('wlan.active():', wlan.active())
wlan.active(): False
>>> from secrets import WIFI_SSID, WIFI_PASSWORD
>>> wlan.connect(WIFI_SSID, WIFI_PASSWORD)
>>> print('wlan.status():', wlan.status())
wlan.status(): 3
>>> print('wlan.active():', wlan.active())
wlan.active(): True
>>> print('wlan.isconnected():', wlan.isconnected())
wlan.isconnected(): True
>>> wlan.disconnect()
>>> print('wlan.active():', wlan.active())
wlan.active(): False
>>> print('wlan.isconnected():', wlan.isconnected())
wlan.isconnected(): False
>>>


[Ftx] Adding volumeScale support + liquidationPrice on openPositions + feeUsd field on BorrowingHistoryDto

The time parameter seems does not work
FTX API accept seconds while Date.getTime() return millseconds


Update to the getting started docs.

Category

[x] Content fix
[ ] New article

Related issues
What's in this Pull Request?
Update to the sharepoint/debug location of the packaged spfx solution. Change is in the docs/spfx/web-parts/get-started/serve-your-web-part-in-a-sharepoint-page file.
Current location points to sharepoint/debug. Gulp packages the web-part with the folder structure sharepoint/solution/debug.

Thank you for the submission... this is actually addressed in a big refresh pending for the SPFx docs, so we'll close this as a dupe. Thanks again!

That is definitely a big refresh. OK, well thanks for taking the time to review! The docs have been really helpful for me. I'll look for other ways to contribute.


RuntimeError: tensor should be 2 dimensional

Hello
I try dis project but it's not working show like this error
"RuntimeError: tensor should be 2 dimensional"
how to fix it
I used Windows 10 it's windows error or code or module idk pls guys someone know dis i installed all requirements

Wrong version of pytorch, I think.

ty i found it
can i up resolution, quality and size prediction. how i do it

Guess you can try https://github.com/tg-bomze/Face-Image-Motion-Model

it's only 256x256 i'll plus pixels 460 or 720 so
can i do it and how i do

They use some upsampling method to increase the resolution. Otherwise not possible.


Deprecate Uni/Multi 'then' in favor of 'stage'

Relates to #178

Just did a forced push after a boring rebase.


Incorrect display of answers in search results

For answers, only display the votes number. If it has been accepted, display the acceptance status.

Originally posted by @fenbox in https://github.com/apache/incubator-answer/issues/798#issuecomment-1963274610

Hi @fenbox , I'd like to fix this issue if not assigned yet.


refactor!: migrate EVERYTHING to the new viem approach

refactor(aa-core): complete migration to viem based approach in aa-core
refactor(aa-alchemy): migrate aa-alchemy to new viem interfaces
refactor(aa-accounts)!: migrate aa-accounts to viem approach
test: get most of the e2e tests passing
refactor(aa-ethers): refactor aa-ethers to use the viem client and accounts

Pull Request Checklist

[ ] Did you add new tests and confirm existing tests pass? (yarn test)
[ ] Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
[ ] Do your commits follow the Conventional Commits standard?
[ ] Does your PR title also follow the Conventional Commits standard?
[ ] If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
[ ] Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
[ ] Did you follow the contribution guidelines?

PR-Codex overview
This PR focuses on cleaning up the codebase by deleting unused files and dependencies.
Detailed summary

Deleted several files and directories related to packages, providers, and accounts.
Updated import statements to remove references to deleted files.
Updated package.json files to remove unnecessary dependencies.
Updated tsconfig.build.json files to exclude test files from the build.
Updated vitest.config.e2e.ts files to include only end-to-end test files.
Updated middleware files to fix import statements and remove unused code.
Updated schema files to remove unused imports and dependencies.

The following files were skipped due to too many changes: packages/accounts/src/nani-account/schema.ts, packages/accounts/src/light-account/viem/getLightAccountVersion.ts, packages/core/src/actions/publicErc4337/getUserOperationByHash.ts, packages/core/src/actions/publicErc4337/getUserOperationReceipt.ts, packages/accounts/src/msca/plugin-manager/uninstallPlugin.ts, packages/accounts/src/msca/plugin-manager/installPlugin.ts, packages/core/src/actions/publicErc4337/sendRawUserOperation.ts, packages/accounts/plugingen/phases/plugin-generator/client-actions.ts, packages/core/src/actions/publicErc4337/estimateUserOperationGas.ts, packages/core/src/viem/actions/buildUserOperationFromTxs.ts, packages/core/src/viem/actions/checkGasSponsorshipEligibility.ts, packages/core/src/viem/actions/sendTransaction.ts, packages/ethers/src/types.ts, packages/core/src/viem/actions/sendUserOperation.ts, packages/accounts/src/light-account/viem/transferOwnership.ts, packages/core/src/viem/actions/sendTransactions.ts, packages/core/src/viem/middleware/types.ts, packages/core/src/account/schema.ts, packages/alchemy/src/schema.ts, packages/core/src/viem/actions/dropAndReplaceUserOperation.ts, packages/alchemy/src/client/rpcClient.ts, packages/core/src/account/base.ts, packages/alchemy/src/viem/middleware/userOperationSimulator.ts, packages/accounts/src/msca/plugins/multi-owner/plugin.ts, packages/core/src/viem/actions/types.ts, packages/accounts/plugingen/phases/plugin-actions/index.ts, packages/core/src/viem/actions/buildUserOperationFromTx.ts, packages/alchemy/src/actions/simulateUserOperationChanges.ts, packages/alchemy/src/actions/types.ts, packages/alchemy/src/viem/middleware/feeEstimator.ts, packages/alchemy/src/client/decorators/smartAccount.ts, packages/core/src/utils/testUtils.ts, packages/accounts/src/light-account/createLightAccountClient.ts, packages/core/src/viem/middleware/actions.ts, packages/core/src/viem/actions/internal/sendUserOperation.ts, packages/core/src/viem/actions/internal/runMiddlewareStack.ts, packages/core/src/actions/smartAccount/upgradeAccount.ts, packages/core/src/client/publicErc4337Client.ts, packages/alchemy/src/index.ts, packages/core/src/viem/actions/waitForUserOperationTransacation.ts, packages/accounts/src/nani-account/transferNaniAccountOwnership.ts, packages/alchemy/src/middleware/client.ts, packages/alchemy/src/client/lightAccountClient.ts, packages/core/src/viem/actions/buildUserOperation.ts, packages/core/src/viem/account.ts, packages/alchemy/src/client/internal/smartAccountClientFromRpc.ts, packages/core/src/account/types.ts, packages/core/src/client/schema.ts, packages/accounts/src/msca/plugins/token-receiver/plugin.ts, packages/accounts/src/index.ts, packages/alchemy/src/viem/middleware/gasManager.ts, packages/ethers/src/__tests__/provider-adapter.test.ts, packages/accounts/src/msca/plugins/session-key/plugin.ts, packages/core/src/account/simple.ts, packages/ethers/e2e-tests/simple-account.test.ts, packages/core/src/client/types.ts, packages/core/src/viem/decorator.ts, packages/core/src/client/smartAccountClient.test.ts, packages/ethers/src/provider-adapter.ts, packages/accounts/src/nani-account/account.ts, packages/ethers/src/account-signer.ts, packages/alchemy/src/client/smartAccountClient.ts, packages/core/src/index.ts, packages/core/src/viem/client.ts, packages/accounts/src/msca/utils.ts, packages/accounts/src/nani-account/__tests__/account.test.ts, packages/core/src/client/decorators/publicErc4337Client.ts, packages/accounts/src/light-account/__tests__/account.test.ts, packages/core/src/account/__tests__/simple.test.ts, packages/core/e2e-tests/simple-account.test.ts, packages/alchemy/e2e-tests/light-account.e2e.test.ts, packages/accounts/src/light-account/e2e-tests/light-account.test.ts, packages/accounts/src/light-account/account.ts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

NOTE TO SELF: when merging this one make sure to rebase and merge to preserve the commits. They contain the BREAKING CHANGE note in them which will be necessary for generating changelogs. We'll have a migration guide nonetheless, but good to track anyways

gonna merge this chain all the way down to https://github.com/alchemyplatform/aa-sdk/pull/383 because honestly it'll be just as hard to review 4 prs as it will be one massive PR


More modular PythonOS

Hi,
first thing to say I like the idea of PythonOS very much.
I thought about adding some apps for my radio project. Then I had the idea to add a gui component for it and was a bit frighten of that monolithic 2k loc block. So I started to break it down in a more modular way.
a first draft can be found here: https://github.com/NeoBelerophon/PythonOS/tree/WIP_refactoring
I would like to here what you think about it. IMHO this also could make portion to Python 3 easier and lower the entry barrier for other developers.
BR
Neo

This is a great idea. PythonOS need to be more modular, and have a good range of testing coverage on non-GUI code. We don't know what will happen if somebody successfully merged their pull request to the main repository, and suddenly introduced a bug that is very hard to track down later.


added italian translation

for issue #78

Thanks! It looks like Giovanni was a little faster with PR #206, but it was my fault for not telling people to check the open PRs first (I've updated #78 to reflect this).
I will merge your changes soon to make sure you get credit for your effort.


feat(nmt): add nmt client

basic  python NMT client

Could you please update variables __riva_version__, __riva_release__, __riva_models_version__ in riva/client/package_info()?

Could you please update variables riva_version, riva_release, riva_models_version in riva/client/package_info()?


Update README for Enhanced Appeal and Contributor Section

Propose to enhance the README file by making it more engaging and visually appealing. Additionally, include a contributor section similar to the one in the provided image to acknowledge the contributors effectively.

assigned @AnushkaChouhan25


Fleet should report an error when it has trouble scheduling the service

Hello,
I use coreos beta (fleet 0.10.2), and when i do fleetctl start unit@1 on an unit that is not schedulable (there is no free node to run that unit on) then fleetctl just hangs and reports no error (even in system journal).
I think that should be changed.
Michal

+1 agreed. highly annoying and because the start command sometimes can take a few seconds to complete normally its hard to figure out when it give up and control-c it.

+1 agree completely. When I interrupt it with control-c as @drshade says, it behaves very badly: when fleet fails to find a node to run a unit on, it optimistically still partially reports the service as running. It has to be destroyed fleetctl.
Try this out by creating a service which has MachineMetadata=foo=bar and then just don't provide that metadata in any running node. fleetctl will just sit there, waiting until the service is available. It is obvious that the metadata check is not performed initially, but rather, at some later step in the process.


Install Cylc 8 on DKRZ

Hi @remi-kazeroni, @zklaus,
Thanks to help from Dave Matthews, I have installed Cylc 8 on DKRZ in the /work/bd0854/metomi/ directory :)
To use Cylc 8, add export PATH=/work/bd0854/metomi/bin:${PATH} to your ~/.bashrc file.
I created a very simple workflow in /work/bd0854/cylc8_test_workflow/ for testing purposes. To run this workflow:
cd /work/bd0854/cylc8_test_workflow/

# Validate the workflow:
cylc validate .
cylc lint

# Install the workflow:
cylc install .

# Run the workflow:
cylc play cylc8_test_workflow

I still need to do some reading about the platforms to configure Cylc appropriately for DKRZ, but is there anything else I need to consider?

Hi @ehogan, thanks for your work on deploying Cylc8 at DKRZ! I followed your instructions and could successfully run the simple workflow you created.

I still need to do some reading about the platforms to configure Cylc appropriately for DKRZ, but is there anything else I need to consider?

I'm not sure how to answer your question. It might be nice to have an example cylc suite to submit recipes from recipes/examples and working with Cylc 8 in case some users would need that. We have such suite already here and documented here but that works only with Cylc 7 which is not available on Levante. But perhaps that is not worth the effort since it would be redundant with the RTW under development :)


Add flag: non-standard-requirements

[X] Address #5340
[ ] special case

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matklad (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

@csmoe this looks great! Would you mind opening a PR against semver as well? We can only use published crates. I am not actually sure that is_semver_open is necessary the best API extension, @steveklabnik would know better!

@matklad Here is the VersionReq API:
    pub fn is_semver_open(&self) -> bool {
        if self.predicates.is_empty() {
            return true;
        }

        self.predicates.iter().all(|p| {
            match p.op {
                Ex |
                Lt |
                LtEq |
                Gt |
                GtEq |
                Tilde |
                Wildcard(_) => false,
                Compatible => true, // deal with "1.0.0" or "^1.0.0"
            }
        })
    }

^x.y.z is not necessary, because ^ is default

That means that any semver requirement, except for ^x.y.z, does not make sense.

These two statements seem to contradict each other. So as the comment writes above, I didn't address the first rule(^ is non-semver-open).
Before PR to semver, should I split Compatible to "" and "^" like:
...
match p.op {
    ...
    Compatible => {
        if is_^(op) {
            return false;
        } else {
            return true;
        }
     ...
}
...

These two statements seem to contradict each other. So as the comment writes above, I didn't address the first rule(^ is non-semver-open).

Yeah, I've written something very confusing :-) I mean that specifying ^ is not necessary, because that is a default.

Before PR to semver, should I split Compatible to "" and "^" like(draft):

Probably... And I think a better name for "semver-open" should be invented, because ^1.2.0 is semver open, but you shouldn't use it anyway, because 1.2.0 form is preferable. Perhaps fn is_plain_semver()? Also, I think self.predicates.is_empty() should perhaps be replaced with self.predicates.len() == 1?

@matklad Thank for your suggestions.

is_plain_semver(): ^1.2.0 is semver open, but you shouldn't use it anyway, because 1.2.0 form is preferable.

So is_plain_semver is stricter than is_open_semver since it exclude any version manifest except 1.0.0. I'll address your mentoring instructions later.
I find that "1.0.0" and "^1.0.0" were simply marked Compatible as whole, it seems no way to split them. So a PR to semver-parser is needed:
enum CompatibleOp {
    Caret, // `^1.2.0`
    Default_, // `1.2.0`
}

@matklad
ohh, that's more complicated than I thought since semver currently depends on semver-parser v0.7.0, but the latest semver-parser codebase has changed a lot(real breaking changes).
So PR to semver will be blocked before those PRs done:

rebase CompitableOp(currently based on v0.7.0) onto semver-parser lastest.
merge semver-parser lastest into semver.

@csmoe oh, I didn’t know about semver-parser at all! I think this actually makes things easier: we can use semver-parser directly. It exposes the internal structure of versions, so we don’t need any API changes and can implement all checks in Cargo!

@matklad FWIW while I do agree we should tackle something like https://github.com/rust-lang/cargo/issues/5340 long-term I don't think we should start warning today, even for the epoch. The last discussion around this for publishing to crates.io (which ended up only disallowing *) IIRC had a lot of discussion and I think that if we wanted to institute a change like this we'd likely want to reboot some of that discussion and otherwise more broadly advertise this change. I think it's fine to land this functionality gated for now, but I'd prefer to not enable by default just yet

:umbrella: The latest upstream changes (presumably #5473) made this pull request unmergeable. Please resolve the merge conflicts.

@csmoe sorry for letting this to fall through the cracks!
The two things to do here I think 1) switch to semver parser from semver 2) feature-gate this functionality.
For 2, you'll need to add a flag to CliUnstable:
https://github.com/rust-lang/cargo/blob/c51ed7b9f3595e6f9e742c778830ef279314443c/src/cargo/core/features.rs#L277-L311

@matklad relist this into my TODO.

FWIW while I do agree we should tackle something like #5340 long-term I don't think we should start warning today, even for the epoch.


User Interaction

As part of pre-draw delegation, the camera matrices need to be recalculated.  Changes to this matrix are initiated by User Interaction through the keyboard and mouse.  Will utilize a KeyboardMap and consider the mediation of these interactions to the appropriate object through Protocols.

User interaction has been successfully implemented with Respondable, Instructable, and an instruction map.  However, only the foundation was laid as the instruction map is currently implemented as a global variable that is scoped to fileprivate.  There's not way to access or modify it outside of SwiftOpenGLViewProtocols.swift.
After completion of the SwiftOpenGLView lifecycle, we'll consider wrapping this variable into a Singleton.  The problem that will arise is access to the instructionMap from with extension Respondable.


feat(Order/WellFounded): StrictMono.not_bddAbove_range

A strict monotonic function in an unbounded well-order has an unbounded range.

The lemma StrictMono.not_bddAbove_range already exists with incompatible assumptions. Should either be renamed, or is it ok to use a primed lemma here?

The primed and unprimed versions are special cases of a more general lemma: If f : alpha -> beta is strictly monotone, Ici b is well-founded for all b : beta and cof  beta <= cof alpha, then f has unbounded range. I'm not saying you should be proving the two special cases using this general lemma (because it would require importing cofinality), but you should prove it, give it the unprimed name and name the two special cases something like _of_succArchimedean and _ofWellFoundedLT.

I don't think your generalization is true as stated. The embedding from ω_ 1 into ω_ ω satisfies the hypotheses but has bounded range.

As in, the maximum rank of the well-founded order Set.Iic x? This should be true, but it'd be a hassle to state and prove, and I'm not even sure it subsumes the PredArchimedean lemma, at least not without further API. Do we have that these intervals are well-founded in any PredArchimedean order?
More than that, I do question whether anyone would ever find this generalization useful. It feels a bit too much on the specific side to me.

Sure, but at least the existence of this general statement and the fact it could eventually be proved should guide us in (re)naming its special cases. Can you therefore please rename the two special cases something like _of_succArchimedean and _ofWellFoundedLT?

What about StrictAnti.not_bddBelow_range? There wouldn't be any corresponding StrictAnti.not_bddBelow_range_of_wellFoundedX.
I'm fine with simply renaming the new lemmas to end in of_wellFoundedX and leaving the other ones as is.

Why wouldn't there be? Isn't there a WellFoundedGT version?

Yes, but that also takes in a StrictMono argument.

I don't get it. If you dualise both alpha and beta, then f : alpha -> beta goes from StrictMono to StrictMono, not StrictAnti.

Yeah, that's the thing. We wouldn't have StrictAnti.not_bddAbove_range_of_wellFoundedLT. But we do have StrictAnti.not_bddAbove_range

Ah sure. I think it makes sense to rename them for consistency

Thanks :tada:
bors merge


Ikea Tradfri GU10 bulb issue  TRADFRIbulbGU10WS345lm

Hi!
I have installed zigbee2mqtt and added my devices. All devices are fine except one: Ikea Tradfri GU10 354lm bulb. Tried to repairing, restart addon, restart core, but nothing helped. Reconfig button also shows error message. Here is the log entry:
Zigbee2MQTT:warn  2021-12-12 16:38:03: Received message from unsupported device with Zigbee model 'TRADFRIbulbGU10WS345lm' and manufacturer name 'IKEA of Sweden'
I have seen a difference between the name of the unsupported and the supported devices: GU10WS and GU10WW
Any ideas to get it work? With ZHA it was ok. Thanks!

I have the same issue. Someone found a solution yet? Other IKEA GU10 bulbs (400 lumen old model) work fine.

I have got a tip: use the edge version. It is working fine for me now with GU 10

Edge version of zigbee2mqtt? Where can I find this?

Any updates? what do you mean by edge verions in using zigbee2mqtt and home assistant

You should probably ask here: https://github.com/Koenkk/zigbee2mqtt/issues/new/choose
as it might not be a problem of the add-on itself but z2m itself...


Write some fewer empty records

I'm trying to generate QIF files to import into GnuCash and found two issues that made this process a little bumpy. This is one of them.
GnuCash was crashing on some of the QIF files that I created but didn't spit out any useful (to me, anyway) error messages.
Looking at the generated QIF in more detail, I noticed that there were instances of consecutive lines each consisting of just the ^, indicating the end/beginning of a record, i.e. there were empty records.
One could say GnuCash should simply skip over those, but I think there's no reason why quiffen should write empty records. So if there's a chance for us to write records here that will be accepted by more software such as GnuCash, I think we should do that! 😊
It turns out that if there are no accounts, categories or classes, then code like this:
qif += '^\n'.join(
            cls.to_qif()
            for cls in self.classes.values()
        ) + '^\n'

will always result in at least the trailing ^\n, without actually having written any records. This results in an empty record if there were e.g. no classes to write.
I hope you will accept this PR! :) Let me know if there's anything else you'd like me to do!

This all looks good! Thank you for your contribution!


bundle-size

Hey there,
I got some issue while deploying an application. It seems like lodash as dependency of useInertiaForm is blowing the bundle-size to the limit:

Issue on my side, or are there some things we could do to optimize it here? tree-shakin might be a point.
Thanks!
Cheers,
Dom

I'll be honest, I'm not very familiar or comfortable with publishing packages or optimizing bundle sizes. If you have any suggestions I'd love to get them, I'm currently trying some things out on the bundle branch. So far I've tried moving all non dev-dependencies into peerDependencies, but when building, the bundle size doesn't change much at all for me.
I'm going to keep trying to optimize, and I'll make another release in a few days once I've tried some things out. Do let me know if you have any tips though.

I'll be honest, I'm not very familiar or comfortable with publishing packages or optimizing bundle sizes. If you have any suggestions I'd love to get them, I'm currently trying some things out on the bundle branch. So far I've tried moving all non dev-dependencies into peerDependencies, but when building, the bundle size doesn't change much at all for me.
I'm going to keep trying to optimize, and I'll make another release in a few days once I've tried some things out. Do let me know if you have any tips though.

Thanks @aviemet for your reply,
I'm not really a professional with build processes either - but I think I already have a clue.
I'll get back to you in a few days with a change request.


On Advanced Topics, can you please put a more thourough example of WKScriptMessageHandler message passing?

From the quick start guide https://github.com/hotwired/turbo-ios/blob/main/Docs/QuickStartGuide.md, it is very easy to get up and running, and even link up a local dev project after allowing arbitrary loads.
What I would like to understand is what does a naive two-way call look like in code, and where to add that code to get it functioning.
I know the following code does not work, but what I'm looking for to be added to advanced topics would be similar to the following:
// from your rails application
let messagePasser = Turbolinks.messagePasser()
messagePasser.send({msg: 'Hello World'})

let messageResponder = Turbolinks.messagePasser()
messageResponder.onMessageRecieved(msg => {
  console.log(msg)
})

Replace ViewController.swift with the following:
import UIKit
import WebKit

class ViewController: UIViewController, WKScriptMessageHandler {

    func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
        print(message)
        userContentController.session.webView.evaluateJavaScript("messageResponder.onMessageRecieved('hello')") //does not work
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
    }
}

@zachwaugh am I on the right track?

Potentially something in this file? https://github.com/hotwired/turbo-ios/blob/main/Source/WebView/turbo.js

Potentially something in this file? https://github.com/hotwired/turbo-ios/blob/main/Source/WebView/turbo.js

I intentionally left that out since it isn't really Turbo-specific, but just standard iOS WKWebView APIs. I can add a small section to the docs though.
I probably wouldn't have your ViewController be responsible for receiving the messages. I'd recommend a dedicated object that receives and parses those messages into some other type and then passes them on to whatever other object needs to handle it. Here's a general sketch of how it works. For simplicity to start, just make whatever object owns and configures your Turbo.Session responsible for setting up the web view to handle receiving messages and to receive those messages. Later you'll probably want to extract that handling to a separate object.
import Turbo
import WebKit

// WKScriptMessageHandler requires NSObject conformance
class SessionController: NSObject {
    lazy var session: Turbo.Session = {
        let configuration = WKWebViewConfiguration()

        // Setup your session with a WKWebViewConfiguration and script message handler
        configuration.userContentController.add(self, name: "nativeApp")

        let session = Turbo.Session(webViewConfiguration: configuration)
        session.delegate = self

        return session
    }()
}

extension SessionController: WKScriptMessageHandler {
    func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
        // WebView JS sends a message with
        // webkit.messageHandlers.nativeApp.postMessage(message)

        // Native app receives message and processes it as needed, maybe pass to another object
        // message.body...

        // Native app can call more JS functions as needed
        session.webView.evaluateJavaScript("someReplyMessage()")
    }
}

@zachwaugh thanks!
So extending the quick start example, this works:
import UIKit
import Turbo
import WebKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    private lazy var navigationController = UINavigationController()

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let _ = (scene as? UIWindowScene) else { return }
        window!.rootViewController = navigationController
        visit(url: URL(string: "http://lvh.me:3000")!)
    }

    private func visit(url: URL) {
        let viewController = VisitableViewController(url: url)
        navigationController.pushViewController(viewController, animated: true)
        session.visit(viewController)
    }

    lazy var session: Turbo.Session = {
        let configuration = WKWebViewConfiguration()
        // Setup your session with a WKWebViewConfiguration and script message handler
        configuration.userContentController.add(self, name: "nativeApp")
        let session = Turbo.Session(webViewConfiguration: configuration)
        session.delegate = self
        return session
    }()
}

extension SceneDelegate: SessionDelegate {
    func session(_ session: Session, didProposeVisit proposal: VisitProposal) {
        visit(url: proposal.url)
    }

    func session(_ session: Session, didFailRequestForVisitable visitable: Visitable, error: Error) {
        print("didFailRequestForVisitable: \(error)")
    }
}

extension SceneDelegate: WKScriptMessageHandler {
    func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
        // WebView JS sends a message with
        // webkit.messageHandlers.nativeApp.postMessage(message)
        print(message.body)

        // Native app receives message and processes it as needed, maybe pass to another object
        // message.body...

        // Native app can call more JS functions as needed
        session.webView.evaluateJavaScript("someReplyMessage()")
    }
}

And in the webview javascript:
  if(window.webkit){
    window.webkit.messageHandlers.nativeApp.postMessage({msg: 'ping'})
  }

  var someReplyMessage = function (){
    console.log('nativeApp ponged back')
  }


Syncing only releases

Backstroke is great for syncing commits from a branch. But in certain situations, it'd be ideal to create backstroke PRs only for upstream releases.
Taking create-react-app as an example, I don't really want to have Backstroke create a PR for every other commit on master, because the changes may not be ready for production. I'd want to have a PR created whenever a release is cut.
What would be the best approach here?

Option to sync releases instead of choosing a branch, then use the API to find the latest release during sync.
Be less tied to what Github deems as a release, instead allowing configuration of an optional commit message regex, eg. ^Publish.*$. This would be easier to implement but less user friendly and prone to false positives.

@jdcrensh Cool idea!
Once requirement is that Github requires pull requests to be made off of a branch, which would make pull requests off of tags a bit hard. I'm exploring https://github.com/backstrokeapp/server/issues/74, which could potentially make syncing to a tag possible.
A commit message regex would definitely be easier, though an inferior solution.
Is this a feature you'd like to work on? This isn't something that I would likely work on in anytime soon.
Thanks for the idea!

I hadn't considered that limitation of PRs, thanks for pointing it out before I spent too much time on it. May have some time to explore it in a week or so, but I'll watch #74 cause it might be a prerequisite.

@jdcrensh Here's a PR for that issue: https://github.com/backstrokeapp/worker/pull/2

@jdcrensh That PR I previously mentioned has been merged. Don't know if this is still something you're interested in working on but if so the backend code for that feature is in a good place.


Windows fixes

This fixes #61 and various other Windows issues.  We were having tons of issues with fs.unlink.  Windows can be a little finicky.  I replaced fs.unlink with rimraf, which supports retrying on Windows issues.
I also added the AppVeyor badge, which shows continuous integration status with Windows.  It currently points to the master branch, so while it may look broken on first-glance, taking a look at the windows_fixes branch will show that tests are passing for Node versions 0.10.x, 0.12.x, 4.0.x, 4.1.x, and 5.0.x on both x86 and x64.

@kesla @AdamMagaluk Do either of you have a Windows machine to use for testing?  Just hoping to get a review.  I guess making sure nothing breaks on other operating systems is also important.

@kevinswiber On<EMAIL_ADDRESS>it failed on my Windows machine.
  82 passing (1m)
  2 failing

  1) Medea #compact compacts successfully:
     Error: timeout of 30000ms exceeded
      at null.<anonymous> (C:\Users\adamm\software\medea\node_modules\mocha\lib\runnable.js:165:14)
      at Timer.listOnTimeout (timers.js:92:15)

  2) Medea "after all" hook:
     Uncaught AssertionError: false == true
      at C:\Users\adamm\software\medea\test\medea_test.js:241:11
      at C:\Users\adamm\software\medea\compactor.js:64:7
      at C:\Users\adamm\software\medea\node_modules\async\lib\async.js:148:21
      at C:\Users\adamm\software\medea\compactor.js:212:16
      at C:\Users\adamm\software\medea\node_modules\async\lib\async.js:148:21
      at C:\Users\adamm\software\medea\compactor.js:372:28
      at FSReqWrap.oncomplete (fs.js:82:15)

npm ERR! Test failed.  See above for more details.

What version of Windows are you using, out of curiosity?
On Wed, Feb 17, 2016 at 7:41 AM Adam Magaluk<EMAIL_ADDRESS>wrote:

@kevinswiber https://github.com/kevinswiber On<EMAIL_ADDRESS>it failed on
my Windows machine.
82 passing (1m)
2 failing

Medea #compact compacts successfully:
Error: timeout of 30000ms exceeded
at null. (C:\Users\adamm\software\medea\node_modules\mocha\lib\runnable.js:165:14)
at Timer.listOnTimeout (timers.js:92:15)

Medea "after all" hook:
Uncaught AssertionError: false == true
at C:\Users\adamm\software\medea\test\medea_test.js:241:11
at C:\Users\adamm\software\medea\compactor.js:64:7
at C:\Users\adamm\software\medea\node_modules\async\lib\async.js:148:21
at C:\Users\adamm\software\medea\compactor.js:212:16
at C:\Users\adamm\software\medea\node_modules\async\lib\async.js:148:21
at C:\Users\adamm\software\medea\compactor.js:372:28
at FSReqWrap.oncomplete (fs.js:82:15)

npm ERR! Test failed.  See above for more details.
—
Reply to this email directly or view it on GitHub
https://github.com/medea/medea/pull/62#issuecomment-185261325.

Windows 10 x64

FYI: both issues show up in master branch as well, so it doesn't look like anything new was introduced.

@AdamMagaluk I checked 4.3.1 on Windows 8 (x64).  It seems to pass without issue.  Can you try upping the timeout value and see what happens?  mocha -R spec -t 60000

Ok bumping it up to 120000 worked. Looks like it was taking 63 seconds to complete on those tests.

Great.  So it's not incorrect; it's just slow.  The tests take 17 seconds to complete on my Windows 8 VM.  Any idea why that might be?  I can grab a Windows 10 image and toy around with it, too.  Thanks for testing it out!

I think it's probably the computer i'm running it on, it's running on my old desktop not a VM. I guess that's what you get with 2011 tech and spinning drives.


There is no trg when for evaluation, but the tutorial has used this for input: trg_len

When we evaluate this model, we have no trg, as well as trg_len. How can we use this to evaluate this model.
def forward(self, src, trg, teacher_forcing_ratio = 0.5):
    #src = [src len, batch size]
    #trg = [trg len, batch size]
    #teacher_forcing_ratio is probability to use teacher forcing
    #e.g. if teacher_forcing_ratio is 0.75 we use teacher forcing 75% of the time

    batch_size = src.shape[1]
    trg_len = trg.shape[0]
    trg_vocab_size = self.decoder.output_dim

    #tensor to store decoder outputs
    outputs = torch.zeros(trg_len, batch_size, trg_vocab_size).to(self.device)

    #encoder_outputs is all hidden states of the input sequence, back and forwards
    #hidden is the final forward and backward hidden states, passed through a linear layer
    encoder_outputs, hidden = self.encoder(src)

    #first input to the decoder is the <sos> tokens
    input = trg[0,:]

    for t in range(1, trg_len):

        #insert input token embedding, previous hidden state and all encoder hidden states
        #receive output tensor (predictions) and new hidden state
        output, hidden = self.decoder(input, hidden, encoder_outputs)

        #place predictions in a tensor holding predictions for each token
        outputs[t] = output

        #decide if we are going to use teacher forcing or not
        teacher_force = random.random() < teacher_forcing_ratio

        #get the highest predicted token from our predictions
        top1 = output.argmax(1)

        #if teacher forcing, use actual next token as next input
        #if not, use predicted token
        input = trg[t] if teacher_force else top1

    return outputs

The forward method of the Seq2Seq class is for training the model only. Not for inference.
See the translate_sentence function in notebook 4 if you want to see how to use the model for inference, which does not use a target sequence at all.


Make the .ios class in Core -> Base -> Forms customisable

The .ios class here: https://github.com/chris-pearce/scally/blob/master/core/base/_forms.scss#L207 needs to be customisable.
@stowball spotted this.

Fixed in #112.


Implement a way to build database.html dynamically from database.csv

This pull request:

Adds two python scripts to generate the database.html file dynamically from database.csv and database-template.html
Modifies database.csv to have a constant number of columns.
Adds a “Building the Database” section to README.md.

On the database.csv file being modified: lines terminating in an empty entry like
[Q14481419](https://www.wikidata.org/wiki/Q14481419),,[0-1 law](https://leanprover-community.github.io/mathlib4_docs/./Mathlib/Probability/Independence/ZeroOne.html#ProbabilityTheory.measure_zero_or_one_of_measurableSet_limsup_atTop),,,

had the last , removed, e.g.:
[Q14481419](https://www.wikidata.org/wiki/Q14481419),,[0-1 law](https://leanprover-community.github.io/mathlib4_docs/./Mathlib/Probability/Independence/ZeroOne.html#ProbabilityTheory.measure_zero_or_one_of_measurableSet_limsup_atTop),,

as this caused an extra sixth column to be added.

Indeed, many thanks for this!!

It's my pleasure! Thank you so much too for developing such a nice project :)


Fix/1492 handle ln address server error response

Describe the changes you have made in this PR

lnurlLib.getDetails is checking for an Axios error and returns it instead of throwing
Implementations need to take care of this

Link this PR to an issue
Fixes #1492
Type of change (Remove other not matching type)

fix: Bug fix (non-breaking change which fixes an issue)

How has this been tested?
Not sure how to test this

can all the places where getDetails is used handle this change?

can all the places where getDetails is used handle this change?

I believe so. What do you think? Is it possible to test this with a real failing request? Otherwise I could try to mock the response maybe.

did you check all the places where getDetails is used?
also when is it an axios error?
I don't think this solves #1492
because the server might return a HTTP 200 and the JSON like the one mentioned in the issue: {"status": "ERROR", "reason": "couldn't find user"}
So I don't really understand what is different with this change.
and if you have not tested it, then it needs to be tested.

shouldn't we also check if it is status error?
(and the response could be completely broken, e.g when a service is down. there is no tag and no reason in the responsee)

I guess the global catch (of a network error or such) is already handled, isn't it?
I just say that if there is no tag it does not mean that there is a reason in the response. You take something from the first success JSON and assume something from the second error JSON. it likely is.
I just would have checked only if it's the second error case. if status is error and there is a reason then we show that, otherwise we need to show something generic and we don't know what's up.

I guess the global catch (of a network error or such) is already handled, isn't it?

Right, this:
https://github.com/getAlby/lightning-browser-extension/blob/fix/1492_hande-ln-address-server-error-response/src/common/lib/lnurl.ts#L76-L78
So for now this would also silently fail for the user. But I'm happy to tackle this after this PR.

I just say that if there is no tag it does not mean that there is a reason in the response. You take something from the first success JSON and assume something from the second error JSON. it likely is. I just would have checked only if it's the second error case. if status is error and there is a reason then we show that, otherwise we need to show something generic and we don't know what's up.

Updated it to make sure we show reason or a generic message.

@bumi I switched it to a helper function to make this more clear.
In general we should be able to trust our types.
Currently these types are expected to be LNURLDetails:
https://github.com/getAlby/lightning-browser-extension/blob/fix/1492_hande-ln-address-server-error-response/src/types.ts/#L326-L371
None of these have a status prop unless it's an error:

https://github.com/fiatjaf/lnurl-rfc/blob/luds/02.md
https://github.com/fiatjaf/lnurl-rfc/blob/luds/03.md
https://github.com/fiatjaf/lnurl-rfc/blob/luds/06.md
https://github.com/fiatjaf/lnurl-rfc/blob/luds/04.md
This can return {"status": "OK"} but not in the case of our getDetails function because:

tag with value set to login which means no GET should be made yet.

Does this make sense? If we can't trust this we can adjust the types further. In a later PR.

look at this: https://getalby.com/.well-known/lnurlp/bumi
I guess we implement the spec wrong then...
(btw. imo a fail of the spec then: they don't respect HTTP codes, and then selectively only use a status code)

look at this: https://getalby.com/.well-known/lnurlp/bumi I guess we implement the spec wrong then...

Guess we did :P
Will make a note and update our types and add a comment. Thanks!

(btw. imo a fail of the spec then: they don't respect HTTP codes, and then selectively only use a status code)

Yes, agreed it's weird.


Site deployed guide and API should respect and use stable version tag, not master branch

Hello!
http://www.yiiframework.com/doc-2.0/guide-index.html
http://www.yiiframework.com/doc-2.0/index.html
It turns out the guide and API both shows what is in master branch now. Which is not very good, and can confuse framework users. Developers will have non-standard behavior, and this is quite weird when documentation is for master, but 99% of people use stable (2.0.10 at the moment).
Example:
http://www.yiiframework.com/doc-2.0/guide-input-validation.html#creating-validators
/**
 * @param string $attribute the attribute currently being validated
 * @param mixed $params the value of the "params" given in the rule
 * @param \yii\validators\InlineValidator related InlineValidator instance
 */
function ($attribute, $params, $validator)

Third parameter is true for 2.0.11: https://github.com/yiisoft/yii2/blob/master/framework/validators/InlineValidator.php#L72
But not for 2.0.10: https://github.com/yiisoft/yii2/blob/2.0.10/framework/validators/InlineValidator.php#L69
I didn't manage to find similar issue, so please close this if there is something similar.
Cheers,
@resurtm

It turns out the guide and API both shows what is in master branch now. Which is not very good, and can confuse framework users. Developers will have non-standard behavior, and this is quite weird when documentation is for master, but 99% of people use stable (2.0.10 at the moment).

this is going to be fixed on the new website. There will be a switch to choose between 2.0.x 2.1.x and dev-master docs.
We also usually add something like "This parameter is available since version 2.0.11" so that problem is not that big. have been overseen in this case. will add it.

fixed, thanks for reporting!


Display APR data (iframe)

Asaf Shachaf, [1. Aug 2020 at 13:47:30]:
...here is some data from dune for APR.
for the "data" page, we can use these queries and show the information in iframe.
https://explore.duneanalytics.com/dashboard/bancor-v2-data
for example:
APR iframe (current APR d)

APR graph (once you click to view the APR data)

@asaf
how should this be handled? I assume the apr number should be displayed for each token in a separate column of the table in the data section?
the iframes are to big to put in each row of the table. What should I display as a button to open a window that presents the iframe?
and how would I get each iframe for all the tokens?

@ashachaf My current understanding is that we require some more links?

@ashachaf closing till we get some more direction on this.

we are working with blocklytics to have bancor v2 subgraph ready.
an APR query should be there soon.
https://thegraph.com/explorer/subgraph/blocklytics/bancor-v2?query=Converters

@ashachaf Is this now going to be replaced with the new GraphQL endpoint we have?

@Velua that's the plan

Alright @yudilevi will close this and continue work towards the new graph.


No annotations for test set

Test sets don't have annotations to build a "ground truth", would it be possible to have them to evaluate how our model is performing?

Hi, you may evaluate your model using the leaderboards on our Big data Cup website. For further details, you may refer to the summary paper.

Hi, you may evaluate your model using the leaderboards on our Big data Cup website. For further details, you may refer to the summary paper.

Hello @DeekshaArya and thank you for your reply.
What I intended is that test1 and test2 dataset do not have annotations like train dataset does.
Since it's not possible anymore to submit our work and be evaluated, I'd like to know if you could release annotations for those as well, to evaluate ourselves and compare to the leaderboard.
Kind regards.

Hello @DeekshaArya and thank you for your reply.
What I intended is that test1 and test2 dataset do not have annotations like train dataset does.
Since it's not possible anymore to submit our work and be evaluated, I'd like to know if you could release annotations for those as well, to evaluate ourselves and compare to the leaderboard.
Kind regards.

Hi @DarthGalm.
The new submissions for test1 and test2 leaderboards for GRDDC have been disabled but you may still utilize the newly created test1-2 and test2-2 leaderboards for evaluating your predictions on test1 and test2. You may create an account and submit your prediction outputs for both the test datasets.
The following video may be helpful for further details.

Hi @DarthGalm.
The new submissions for test1 and test2 leaderboards for GRDDC have been disabled but you may still utilize the newly created test1-2 and test2-2 leaderboards for evaluating your predictions on test1 and test2. You may create an account and submit your prediction outputs for both the test datasets.
The following video may be helpful for further details.

Hello @DeekshaArya The race is over. why did you just release annotations? I think hi want to test locally.

Hello @DeekshaArya The race is over. why did you just release annotations? I think hi want to test locally.

I also would be interested in the annotations for the test sets.
Thank you in advance.

Hi, what does the test1-2 and test2-2 mean?

I'm interested to know if there will be available the annotations for test1 and test2


Issue 3085 - DC::GetAttNames() not returning global attributes

Fixes #3085
Accessing global attributes was never implemented by the DC* classes.

@clyne thanks for the fast turnaround.  It's working for me so far but I want to test it more in #3070 before accepting it.  I'll have a better update tomorrow.

@clyne this fixes the problem, however now whenever I query DC::GetAttType() for global attributes, I always get INVALID for the DC::XType. I can't read the global attribute value without knowing the type. I'm seeing this on Kauffman, Katrina, MayControl, and our hist.mpas-o datasets.

Fixed.

It works. Thank you.
I see the changes have been pushed to the PMetadataClasses PR, #3073. I don't mind whether we accept the changes here, or in that PR.

Oops, pushing the the PMetadataClassses PR was a mistake. I can back out those changes and submit to this PR, or leave as is. Whatever you prefer.

No problem - the changes are already in my branch so it's probably easer to close #3086 and merge this one.  Same difference either way, imo.

Closed!


Review of FMRI code

[ ] check the FMRI code - running from a fresh environment
[ ] update readme if need be
[ ] list installation steps of addtional software / drivers / toolboxes if need be
[ ] document environment / additional steps to get the code working
[ ] flag any other gotchas / issues found during running the code
[ ] fill in about.md (rename and use template_about.md)

Looping in @YamilVidal as well.

@YamilVidal  For the python environment files, can we use the ones on HPC?


[Spotify Player] Create new queue command

Description
Adds a new command that allows the user to view their queue.
Closes #9704
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

I think it's cool to see the queue, but I was surprised when I couldn't play a specific item from the queue. Why is that? Only seeing the queue doesn't seem to add that much value imo.

Yeah, I'm not sure what I was thinking. I used EpisodeListItem and TrackListItem, so the queue items have actions now.

Much cleaner ✨

Such a cool command 👏
Wanted to build one for loooong 😬


Skip compiler-rt in Xcode-driven builds

What's in this pull request?
Skip building compiler-rt when using -x. It's currently not supported, and we're breaking '-x' builds by leaving compiler-rt turned on.
I tested this by running build-script with -x, -r, and -- --cross-compile-tools-deployment-targets and inspecting the cmake lines.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please smoke test

(LGTM, just wanted to get our standard configurations on it.)


fix: multiple seeks called on same time

This fix was originally part of PR #791 but was separated due to failing tests and the need for additional validation to ensure it works as expected. This specific change addresses an issue where holding the arrow keys during video seeking caused repeated seek operations to the same position—up to 27 times in one case. This behavior resulted in the video player being stuck in a loading state, as each completed seek triggered another to the same position. This refactor aims to optimize the seek functionality and prevent redundant operations to enhance the viewing experience.

seek relative shouldn't have this problem and can be useful to seek -N seconds/+N seconds. How do you feel about extending the seek method interface to allow relative seeking? For example, seek(duration, relative: true). A positive duration seeks forward, while a negative duration seeks backward.

The other pr was closed which was the relative seek, since it's not accurate, this pr is only to fix the problem of seeking to same time calls are stuck waiting for each other
As Alex mentioned if you want to use relative in your app, use the set property

Sorry, forgot to add exact, which is accurate  seek relative+exact
I see, +- N seconds is so common in every player. Maybe it’s worth extending the interface? Or adding skipForward, skipBackward methods? Given that it solves the problem of pressing the +N seconds multiple times
@alexmercerind wdyt?

lets think feature wise what we will gain?
instead of getting the position and adding the time, mpv will do it internally
and we will have to make the same feature on web and any other platform we add.
from my point of view if its not faster then there is no pros to it.

Let's try to improve seek in a better way...
Not sure how helpful this is, considering Duration can be different even down to milliseconds.

My thought process that yes it can be improved in another way, but this way is needed also to ignore not needed seeks
The keyboard arrow is making too many not needed seeks because they are the same


Can i have multiple instances of this running at the same time?

Im wondering if you can have the autobot running in two different accounts in the same pc at the same time. Thanks in advance

You should be able to yes Sent from my iPhoneOn Jul 21, 2023, at 4:27 PM, Nicksw21 @.***> wrote:
Im wondering if you can have the autobot running in two different accounts in the same pc at the same time. Thanks in advance
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Would it be possible to monitor two channels at the same time? if so, how would i have to put it in settings?

the best way would be to copy the folder and then change the setting in the new one and launch both. windows aint too smart like that if you were on linux you probably could off just the same folder.


Add support for publishing vssdk/vs-impl artifacts

Arcade publishes packages built by a repo to feed(s) associated with the default channel for the repo and branch.
Some repositories however need to publish some packages to different feeds. For example, Roslyn packages that contain VS public APIs are published to vssdk feed. Customers who extend VS use this feed to get access to VS components they can reference. Roslyn also publishes to vs-impl feed. This feed is used by other VS teams that consume Roslyn APIs that are not intended for public consumption.
This publishing logic is currently implemented in a custom publishing script in Roslyn. There are other repositories (e.g. dotnet/interactive-window) that need to publish to these feeds however and they would need to replicate this logic.
Proposal
Instead of implementing custom publishing logic, repositories that need to publish to additional feeds would tag the packages that need publishing with a new artifact type (e.g. "vssdk", "vs-impl", etc.). Arcade publishing would then associate feeds with these tags and publish the packages.

@tmat is this still relevant?

I think so. We have custom publishing logic in dotnet/roslyn repo: https://github.com/dotnet/roslyn/blob/main/eng/publish-assets.ps1
If other repos need to have their custom publishing logic, then perhaps it would make sense to have more publishing features Arcade.

The model being used, is interesting.  It seems like not a terrible amount of work to take this concept and split up the pieces.  ie

move the feeds section to Arcade
allow repos to provide the packages section (either via their own PublishData.json or an ItemGroup)
branches might be the controversial bit and thought needs to be put into where / how this should be controlled.  It feels too dogmatic to have Arcade control branch information for every repo, but you also don't want to leave it entirely open ended.  Perhaps the model would be to define in Arcade a section for permitted publishing repos and their metadata containing branch.  That's a little confusing, so I'll try to provide an example.

Arcade@main - PublishData.json
{
  "feeds": {
    "vssdk": "https://pkgs.dev.azure.com/azure-public/vside/_packaging/vssdk/nuget/v3/index.json",
    "vs-impl": "https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-impl/nuget/v3/index.json",
    "vs": "https://pkgs.dev.azure.com/DevDiv/_packaging/VS/nuget/v3/index.json"
  },
  ...,
  "comment-about-publishing-repository-branches-data": "publishing-repository-branches-data defines the permitted repositories for publishing and the branch of that repo which contains the publishData.json for that repo.",
  "publishing-repository-branches-data": {
    "dotnet/arcade": "main",
    "dotnet/roslyn": "main",
    ...,
  }
}

Roslyn@main - PublishData.json
  "packages": {
    "default": {
      "Microsoft.CodeAnalysis": "arcade",
      "Microsoft.CodeAnalysis.Common": "vssdk",
       ...
    }
  },
  "branches": {
    "dev15.9.x-vs-deps": {
      "nugetKind": "PerBuildPreRelease",
      "vsBranch": "rel/d15.9",
      "vsMajorVersion": 15
    },
  ...
}

Reference: https://github.com/dotnet/roslyn/blob/e5ed5817204c40b98a5431aa2cb9c5dfd5145511/eng/build-utils.ps1#L25


Godot 4.0  white screen on startup

Godot version
4.0.beta4(e6751549c)
System information
Windows10,64,RTX3070,latest drive
Issue description
When I start 4.0, the program shows a white screen and soon disappears automatically.
I can use 3.5.1 fine, but 4.0 won't open anyway.
Both my graphics card and driver support vulkan.
I didn't do any extra settings.
CMD does not prompt any errors.
I tried beta3 and beta4, but there is no way to open and use.

I use another computer and it still won't start,this computer also works fine with 3.5.1

Steps to reproduce
Double click to start Godot 4.0
Minimal reproduction project
No response

Related to #67652 and/or #63622 ?

@saleewisdom If you're using MSI Afterburner or similar programs - try to disable them and try again.

与#67652和/或#63622 相关？

It doesn't seem to be consistent, my Godot doesn't prompt any errors

@saleewisdom如果您使用的是 MSI Afterburner 或类似的程序 - 请尝试禁用它们并重试。

I'm not using a similar program and it's annoying

Can you try running Godot from the command line and using the --verbose argument and then tell us what is printed?
So the full argument would be ./Godot_v4.0-beta4_win64.exe --verbose

I've been getting the same thing throughout b5,7, and now 8. It'll work fine for a while, and then it starts having problems. Once it starts, the only thing that has fixed it for me has been a restart (which didn't actually solve it for me today, hence me being here) or downloading a new version (again, b8 didn't fix it today).
It does eventually "catch up" but doing any work in the app is so slow as to be pointless, whereas things like starting the game were near instant when this white screen is happening.
Closing Afterburner made  no difference.
Verbose output has the white screen hang after Test-to-Speech: SAPI initialized and before `using "winink" pen tablet driver
C:\Users\USERNAME\Downloads>Godot Engine v4.0.beta8.official.45cac42c0 - https://godotengine.org
TextServer: Added interface "Dummy"
TextServer: Added interface "ICU / HarfBuzz / Graphite (Built-in)"
Text-to-Speech: SAPI initialized.
Using "winink" pen tablet driver...
OpenGL Renderer: NVIDIA GeForce RTX 3080/PCIe/SSE2
WASAPI: Activated device using IAudioClient3 interface
WASAPI: wFormatTag = 65534
WASAPI: nChannels = 2
WASAPI: nSamplesPerSec = 48000
WASAPI: nAvgBytesPerSec = 384000
WASAPI: nBlockAlign = 8
WASAPI: wBitsPerSample = 32
WASAPI: cbSize = 22
WASAPI: mix_rate = 48000
WASAPI: fundamental_period_frames = 480
WASAPI: min_period_frames = 480
WASAPI: max_period_frames = 480
WASAPI: selected a period frame size of 480
WASAPI: detected 2 channels
WASAPI: audio buffer frames: 480 calculated latency: 10ms

TextServer: Primary interface set to: "ICU / HarfBuzz / Graphite (Built-in)".
CORE API HASH:<PHONE_NUMBER>
EDITOR API HASH: 959301086
EditorSettings: Load OK!
Loaded builtin certs
EditorSettings: Save OK!


[bugfix] Unable to correctly gc port group

Pull Request

[ ] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Bug fixes

Which issue(s) this PR fixes

When EnableNP  is not enabled, cannot gc node and subnet port group
#4456

@cmdy Hi, please fix the DCO.  use git commit -s

@cmdy Hi, please fix the DCO. use git commit -s

Hi, I find that the check task failed. What should I do to merge the code? Please review my code.

@cmdy Does master has the same issue? would you please help to fix it too?

@cmdy Does master has the same issue? would you please help to fix it too?

Okay, I'd be happy to. you can assign it to me.

Thanks! @cmdy


Doesn't seem to protect any static files in public

I would like to also protect some static files that I'm serving from public/, such as documentation and a static blog site. It would be great if lockup could also intercept those requests.

I put together this Rack middleware as a proof of concept: https://gist.github.com/ndbroadbent/983d30d58e3bae89bb45baaf6108eeeb
Seems to be working fine. But not sure the best way to integrate this with the lockup project.

Unfortunately, this won't work. Most production deployments serve assets from public without hitting Rails at all.
In practice, it's not a problem since static assets can usually only be reached from dynamic pages. That is, unless someone happens to know the url(s) to hit, they won't be able to reach your assets.
If you really need your static assets secured, you'll probably want to use HTTP basic auth in nginx or apache.

Ah, good point. I needed this because I'm hosting on Heroku, so I'm serving all of my assets with Rails, and caching them behind CloudFlare. This setup works great, because only a single request hits my Rails server.
And for staging, I turned off CloudFlare, so all requests go to Rails. But with this middleware I wrote, now I have lockup pages for all of my static blog pages and documentation, so it's working pretty well for me. But you're right, this is probably not a very common situation.


Enable AddGraph operation to be run through the UI

This includes creating a component which can build a schema.

The UI fails to meet our Accessibility policy. It is unmaintainable and will be removed shortly.


Update Typora.Typora to 0.11.8

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Accidentally created this PR here instead of PR to https://github.com/microsoft/winget-pkgs


Make scrolling speed configurable

What is your Scenario?
Resurrecting https://github.com/DevExpress/testcafe/issues/2837
I would like to scroll to the bottom of a page at a slower speed.
What are you suggesting?
The current scroll functions (scroll(), scrollBy(), and scrollIntoView()) scroll the page at the maximum speed possible. This should be configurable, akin to the behavior option of Element.scroll().
What alternatives have you considered?
No response
Additional context
No response

Hi @aweaver5-chwy ,
Thank you for your feedback. We will consider this enhancement and update this thread once we have results.

Thank you @Aleksey28,
For context, we are using scroll() to trigger Google Analytics/GTM events set to activate when elements are visible in the window. We are testing that the correct amount and types of events trigger for a given page. Currently, the events aren't triggered because the scroll speed is too fast. I've verified that the events trigger at a slower scroll speed by manually scrolling in --debug-mode.
The implementation of a scroll speed modifier would serve as a tremendous unblocker for our automated testing.


Add dockerfiles for old releases

Uses the appropriate repo for the release
Adds the gpg key for latest, since the forked repo may contain packages signed with the key from latest if they haven't been rebuilt since being forked.

Coverage remained the same at 41.003% when pulling 6e0b49d199a5970e9be195f7099e60cb32bcc4b0 on jmontleon:dockerfiles-for-old-releases into 9e164b11d85884c70458da8948d1ee6422c0f59c on openshift:master.


AWS Credential failure during S3 deploy

Deploy is no longer possible when using AWS SSO profiles. This appears to be related to changes in AWS CLI and may have a fix in the upstream aws-sdk-go, see also https://github.com/aws/aws-sdk-go/issues/4649 and https://github.com/hashicorp/terraform/issues/32448
I encountered the same error in Terraform this morning, and was forced to update to resolve the issue. It appears that Hugo needs a similar update.
Some redactions done to protect environment names, but the output is the real error I get when running the command which worked a week ago.
% AWS_PROFILE=sso-profile-name hugo deploy --dryRun
Deploying to target "s3" (s3://bucket-name?region=us-east-1)
Error: blob (code=Unknown): NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.120.4-f11bca5fec2ebb3a02727fb2a5cfb08da96fd9df+extended darwin/arm64 BuildDate=2023-11-08T11:18:07Z VendorInfo=brew

Does this issue reproduce with the latest release?
Yes

I merged an update in #11724 -- I don't have time to test this particular issue, so I'll leave this open until others can confirm. I will cut a release early next week.

Thanks! I am not too familiar with go, but I did try the following, and the issue appears to be fixed!
CGO_ENABLED=1 go install -tags extended github.com/gohugoio/hugo@d528bbd6d0e63bb366ea8a3e95042f771c17817a
AWS_PROFILE=profile-name ~/go/bin/hugo deploy --dryRun

The SHA was HEAD at the time of my test, wasn't sure how to specify the head of the master branch.
Thanks for the quick fix!


Use Safari for webapp on ios

webapps uses the limited webview on IOS
we decided to skip the fullscreen mode in IOS for better user experience

Checked on  eWallet environment
Work as per requirements
v0.13.0
Device: iPhone X // iOS 12.4


Module not found: Error: Can't resolve './EventStack' in './node_modules/semantic-ui-react/dist/es/lib/eventStack'

Hi! Thanks very useful library. 😄
Bug Report
I got a build error in Linux (alpine linux) environment.  😭
When in Mac environment, I don't get an error.
I think that eventStack.js must be EventStack.js.

Steps

Add semantic-ui-react to the package.json dependencies.
run yarn
run yarn build: I use webpack & typescript.
I got error.

Actual Result
I got following error.
ERROR in ./node_modules/semantic-ui-react/dist/es/lib/eventStack/index.js
Module not found: Error: Can't resolve './EventStack' in '/root/project/app/node_modules/semantic-ui-react/dist/es/lib/eventStack'
 @ ./node_modules/semantic-ui-react/dist/es/lib/eventStack/index.js 1:0-38 2:19-29
 @ ./node_modules/semantic-ui-react/dist/es/lib/index.js
 @ ./node_modules/semantic-ui-react/dist/es/collections/Grid/GridRow.js
 @ ./node_modules/semantic-ui-react/dist/es/index.js
 @ ./src/App.tsx
 @ ./src/index.tsx

Version
0.81.0

Try to reinstall deps fully, the master branch has a needed file, see the folder

I tried to download the tar boll from  https://registry.npmjs.org/semantic-ui-react/-/semantic-ui-react-0.81.0.tgz.
And I extract it. I got eventStack.js file. Is this the correct file? @layershifter

Rename
/node_modules/semantic-ui-react/dist/es/lib/eventStack/eventStack.js
to
/node_modules/semantic-ui-react/dist/es/lib/eventStack/EventStack.js
fix the error

I am affected by this issue as well, it is especially annoying because this only occurs in my automated tests (which run on Travis CI / Linux), and not in my development environment (Mac OS).
I furthermore tried the fix from @wallena3, and noticed that it did not work in commonjs environments.
To completely fix the issue, I had to use:
mv node_modules/semantic-ui-react/dist/es/lib/eventStack/eventStack.js node_modules/semantic-ui-react/dist/es/lib/eventStack/EventStack.js

mv node_modules/semantic-ui-react/dist/commonjs/lib/eventStack/eventStack.js node_modules/semantic-ui-react/dist/commonjs/lib/eventStack/EventStack.js

Having to add these lines everywhere is less than optimal, as it is no longer possible to install semantic-ui-react as a package.json dependency and manual intervention is required.
Can this issue please be re-opened and fixed?

Please reopen this issue 😭  @layershifter

I reopened issue, the problem needs an investigation.

The master branch and the v0.81.0 tag has the correctly named EventStack.js file. I tried to perform the build locally and everything went okay.
The v0.81.0 contains a valid file in the src folder, however dist folders contains a wrong eventStack.js file :sob: Merged #2870 with same problem.
@levithomason can you check, please? As I'm remember you're builds locally.

Renaming the file does solve the issue locally, but when another dev tries to work with the new version, he/she will have to perform the same fix on their machine - not a very long term fix. With that said, thanks for the suggestion, I can do my local development for now.

Thanks for reopen a issue.
Was the publishing process broken?
I patiently wait to fix.

Hey folks, I'll release a patch for this as soon I finish investigating why the camelCased eventStack.js was built.  Standby.

Fixed in<EMAIL_ADDRESS> The tarball also includes the properly cased EventStack.js file.

Hi, has the NPM package been generated? I got a message saying "No matching version found for<EMAIL_ADDRESS>Thanks.


Add editor-in-editor textel editor

To make freehand painting much easier.
Also indicate if the supplied material index already exists or not.

Use key 'E' (for edit).


tfsec: 1.27.5 -> 1.27.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/aquasecurity/tfsec/releases.
meta.description for tfsec is: "Static analysis powered security scanner for terraform code"
meta.homepage for tfsec is: "https://github.com/aquasecurity/tfsec"
meta.changelog for tfsec is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.27.6 with grep in /nix/store/45af029qv9fm72q2wk8lbkhsh1h6hz8s-tfsec-1.27.6
found 1.27.6 in filename of file in /nix/store/45af029qv9fm72q2wk8lbkhsh1h6hz8s-tfsec-1.27.6

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
tfsec

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/45af029qv9fm72q2wk8lbkhsh1h6hz8s-tfsec-1.27.6 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A tfsec https://github.com/r-ryantm/nixpkgs/archive/d3a91fea40f1e536598fb5cab060e70b02a631f2.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/45af029qv9fm72q2wk8lbkhsh1h6hz8s-tfsec-1.27.6
ls -la /nix/store/45af029qv9fm72q2wk8lbkhsh1h6hz8s-tfsec-1.27.6/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

tfsec

Maintainer pings
cc @fabaff @marsam @peterromfeldhk for testing.

Result of nixpkgs-review pr 189197 run on x86_64-linux 1

1 package built:

tfsec


Answer Questions (load/save/show)

[ ] handle input + storage in front-end
[x] Create Answer-entity in back-end
[x] Create endpoint(s) to POST and GET answers
[ ] handle requests to back-end in front-end
[ ] Show answers on Report-page
[ ] Show answers in "Input"-mode
[x] Change /answers api to accept array and {ProgramId}/answers
[x] Add orderPriority to section
[x] Sort by orderPriority section + questions

@elwinschmitz @arsforza

Answers can be posted through /answers
Answers can be get through /programs/{programId}/questions if they are avaiable and if the user has correct authentications for that program

Let me know if you need a separate endpoint for getting answers.

@RubenGeo
Your points make sense indeed, but in the interface we'll only "save" the answers "per section at once" (at least that is the initial plan). So there will be multiple questions, but only 3-6 or so, I think (but I haven't looked at the 'real' questions yet...)
Batching the requests is to reduce the number of requests/amount of data-over-the-wire... But all the code to handle the edge-cases will add to the total size as well...
So I think a "per question/answer"-approach would be a good MVP/starting point for now at least. And we could maybe later optimize some more. (If it is even worth it then...)
So I've updated the task-list... ;)


Feature/24

https://github.com/Bukashk0zzz/YmlGenerator/issues/24

Codecov Report

Merging #25 into master will decrease coverage by 0.26%.
The diff coverage is 83.33%.

@@             Coverage Diff              @@
##             master      #25      +/-   ##
============================================
- Coverage     99.59%   99.33%   -0.27%
- Complexity      267      268       +1
============================================
  Files            19       19
  Lines           741      749       +8
============================================
+ Hits            738      744       +6
- Misses            3        5       +2

Impacted Files
Coverage Δ
Complexity Δ

src/Generator.php
98.5% <83.33%> (-1.5%)
50 <5> (+1)

Continue to review full report at Codecov.

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

Thanks for PR. I will merge it as soon as you make changes that I described.


Sharding-JDBC  can not convert LONGTEXT data in MySql  to java.sql.Clob

Sharding-JDBC Version: 4.0.0-RC2
org.apache.shardingsphere.core.execute.sql.execute.result.QueryResultUtil convert column data to crossponding java Object by ResultSetMetaData, but the target data type may be a compatible java type.
Suggestion:
Mysql driver restore LONGTEXT as String as default, but if caller ask for java.sql.Clob type, the driver will convert to clob silently. The QueryResultUtil  should consider the target type and ask the driver  to convert to the target type.

Thank you for your suggestion. Can you give me more details? Some configuration, code and exception will help me.

Closed for no response any more.


Fix Await overload return type.

The return type for Await, here, is supposed to be a reference, because it's used in a byref sense by the caller.

Looks good.


multi cpu/core support

Hello, glorytun currently supports only one core/cpu per process. Which gives me ~220Mbps on 2,1GHz
is a multi-core support introduction planned?

Hi,
Yes it is planned, I'll work on perf after the 1.0 release.