ci(release): v0.94.0 @ master

Summary
In this release, we:

Cached Message resources upon transaction submission
Made typegen API more straightforward and ergonomic
Reduced required roundtrips & bandwidth for submitting TXs
Made ContractFactory.deployAsBlobTx a non-blocking call
Upgraded forc to v0.63.0 & v0.63.1
Added support for the new ABI spec (#596, #599)
Improved the bytecode compression for Typegen, making files 40%+ smaller
Improved the type handling for () and Option<T> types
Upgraded fuel-core to v0.32.1
Implemented deploying large contracts using blob transactions
Fixed forc and fuel-core version reporting on typegen-generated files
Fixed getInputFromAssetId so it returns the correct InputCoin and InputMessage
Upgraded fuel-core to v0.33.0
Added createAssetId function to create a native AssetId type
Added validation for max. input limit exceeded, as per the consensus parameters
Removed FUEL_NETWORK_URL and LOCAL_NETWORK_URL constants
Removed  generateTestWallet, seedTestWallet and launchNodeAndGetWallets utilities
Renamed testing class AssetId to TestAssetId

Breaking

Features

#2872 - Consider message on resources cache, by @Torres-ssf
#2824 - Prettify typegen api, by @arboleya
#2962 - Read malleable fields from transaction status on subscription, by @nedsalk
#2929 - Non-blocking blob deployment, by @danielbate
#2856 - Adding abi transpiler, by @arboleya
#2777 - Improve () and Option<T> type handling, by @petertonysmith94
#2827 -<EMAIL_ADDRESS>and large contract deployments, by @danielbate

Fixes

#2963 - Assembly process for account transfer operation, by @Torres-ssf

Chores

#2915 - Deprecate FUEL_NETWORK_URL and LOCAL_NETWORK_URL, by @petertonysmith94
#2811 - Integrate launchTestNode in remaining packages, by @maschad
#2964 - Wrap subscriptions in promise, by @nedsalk
#2905 - Renamed AssetId to TestAssetId, by @petertonysmith94

Features

#2897 - Improve typegen bytecode compression, by @Dhaiwat10
#2903 - Add randomUUID into fuel-ts/crypto, by @Torres-ssf

Fixes

#2888 - Typegen reporting the correct versions, by @petertonysmith94
#2982 - Avoid re-add fake resources at Account.getTransactionCost, by @Torres-ssf
#2896 - Transaction revert error, by @petertonysmith94
#2981 - Gas price estimation test flakiness, by @nedsalk
#2926 - Account.createTransfer return type, by @Torres-ssf
#2859 - Typegen generic configurables, by @nedsalk
#2782 - Return correct operations from coin and message inputs, by @maschad

Chores

#2839 - Refactor helpers related to transaction operations, by @maschad
#2978 - Upgrade<EMAIL_ADDRESS>by @danielbate
#2665 - Implement a helper createAssetId function, by @bolajahmad
#2822 - Handle exceeding maximum inputs when funding a transaction, by @mvares
#2925 - Improve node incompatibility warning, by @Torres-ssf
#2891 - Default TestMessage to be spendable, by @Torres-ssf
#2883 - Dependencies version consistency, by @petertonysmith94
#2879 - Switching Error to FuelError, by @petertonysmith94
#2890 - Add missing reasons to PANIC_REASONS constant, by @Torres-ssf
#2899 - Add validation for TX max outputs exceeded, by @Torres-ssf
#2851 - Add infra to support multiple create fuels templates, by @Dhaiwat10

Migration Notes
Features
#2872 - Consider message on resources cache
The provider option flag cacheUtxo was renamed to resourceCacheTTL
// before
const provider = await Provider.create(FUEL_NETWORK_URL, {
  cacheUtxo: 5000,
});

using launched = await launchTestNode({
  providerOptions: {
    cacheUtxo: 5000,
  },
});

// after
const provider = await Provider.create(FUEL_NETWORK_URL, {
  resourceCacheTTL: 5000,
});

using launched = await launchTestNode({
  providerOptions: {
    resourceCacheTTL: 5000,
  },
});

#2824 - Prettify typegen api
Predicate class

Predicate class constructor parameters renamed: inputData > data

// before
import { Predicate } from 'fuels';

const predicate = new Predicate({
  ...unchangedParameters,
  inputData,
});

// after
import { Predicate } from 'fuels';

const predicate = new Predicate({
  ...unchangedParameters,
  data,
});

Typegen extended/generated Predicate now accepts a single parameter for initialization

// before
import { TestPredicateAbi__factory } from './typegend';

TestPredicateAbi__factory.createInstance(provider, data, configurableConstants);

// after
import { TestPredicate } from './typegen';

new TestPredicate({
  provider,
  data,
  configurableConstants
});

launchTestNode utility

Renamed contractsConfigs[].deployer to  contractsConfigs[].factory
Removed contractsConfigs[].bytecode and .hex.ts file

The bytecode is now saved within the factory class, so you don't have to deal with it.
// before
import { TokenAbi__factory } from './typegend';
import TokenAbiHex from './typegend/contracts/TokenAbi.hex';

using launched = await launchTestNode({
  contractsConfigs: [{
    deployer: TokenAbi__factory,
    bytecode: TokenAbiHex
  }],
});

// after
import { TokenFactory } from './typegend';

using launched = await launchTestNode({
  contractsConfigs: [{
    factory: TokenFactory,
  }],
})

Renamed method deployContract to deploy
Removed the redundant suffix on the ContractFactory class method name.
// before
import { ContractFactory } from 'fuels';

const factory = new ContractFactory(wallet);

factory.deployContract();

// after
import { ContractFactory } from 'fuels';

const factory = new ContractFactory(wallet);

factory.deploy();

Typegen Contract template

Removed Abi__factory suffix from class names
The file <name>.hex was removed (access it via <Name>.bytecode)
The files <name>__factory.ts and <name>.d.dts were merged into <name>.ts
The class <Name> and the interface <Name>Abi are now just <Name>
Method <Name>Factory.deployContract() renamed to <Name>Factory.deploy()
You may need to remove the previously generated <typegenDir>/contracts/factories directory

// before
import { TestContractAbi, TestContract__factory } from './typegen'
import testContractBytecode from './typegen/contracts/TestContract.hex'

const instance = await TestContract__factory.connect(id, wallet);

const deploy = await TestContract__factory.deployContract(testContractBytecode, wallet);
const { contract } = await deploy.waitForResult();

// after
import { TestContract, TestContractFactory } from './typegen'

const instance = new TestContract(id, wallet);

const deploy = await TestContractFactory.deploy(wallet);
const { contract } = await deploy.waitForResult();

Typegen Predicate template

Removed Abi__factory suffix from class names
Started accepting a single param object in constructor
You may need to remove the previously generated <typegenDir>/predicates/factories directory

// before
import { TestPredicateAbi__factory } from './typegen'

const predicate = TestPredicateAbi__factory.createInstance(provider);

// after
import { TestPredicate } from './typegen'

const predicate = new TestPredicate({ provider });

Typegen Script template

Removed Abi__factory suffix from class names
You may need to remove the previously generated <typegenDir>/scripts/factories directory

// before
import { TestPredicateAbi__factory } from './typegen'

const script = TestScriptAbi__factory.createInstance(wallet);

// after
import { TestPredicate } from './typegen'

const script = new TestScript(wallet);

#2962 - Read malleable fields from transaction status on subscription
Removed TransactionResult.gqlTransaction. You can use the TransactionResult.transaction field and other fields on the response instead, which have all the data that TransactionResult.gqlTransaction has.
// before
const { gqlTransaction } = await new TransactionResponse('your-tx-id').waitForResult();

// after
const { transaction, id, fee, ...rest } = await new TransactionResponse('your-tx-id').waitForResult();

#2929 - Non-blocking blob deployment
The transaction ID from a contract deployment is now returned as a promise.
// before
import { ContractFactory } from 'fuels';

const factory = new ContractFactory(bytecode, abi, wallet);
const { waitForResult, contractId, transactionId } = await factory.deploy();
console.log(transactionId); // 0x123....

// after
import { ContractFactory } from 'fuels';

const factory = new ContractFactory(bytecode, abi, wallet);
const { waitForResult, contractId, waitForTransactionId } = await factory.deploy();
const transactionId = await waitForTransactionId();
console.log(transactionId); // 0x123....

#2856 - Adding abi transpiler
New ABI spec
The SDK now adheres to the new specs introduced via:

https://github.com/FuelLabs/fuel-specs/pull/596
https://github.com/FuelLabs/fuel-specs/pull/599

Check these out to understand all its changes.
AbiCoder is no longer available to import
The class AbiCoder is no longer exported, and the way to do encoding and decoding of specific types is now via the Interface.encodeType and Interface.decodeType methods:
// before
const abi = yourAbi;
const functionArg = abi.functions.inputs[0];

const encoded = AbiCoder.encode(abi, functionArg, valueToEncode);
const decoded = AbiCoder.decode(abi, functionArg, valueToDecode, 0);

// after
import { Interface } from 'fuels';

const abi = yourAbi;
const functionArg = abi.functions.inputs[0];

const abiInterface = new Interface(abi);

const encoded = abiInterface.encodeType(functionArg.concreteTypeId, valueToEncode);
const decoded = abiInterface.decodeType(functionArg.concreteTypeId, valueToDecode);

Interface.findTypeById has been removed
Previously, you could get a type from the ABI via the Interface.findTypeById. This method was removed after introducing the new abi specification because the concept of a type has been split into concrete and metadata types. If you want a specific type, you can get it directly from the ABI.
// before
const abiInterface = new Interface(abi);

// internally this method searched the abi types:
// abi.types.find(t => t.typeId === id);
const type = abiInterface.findTypeById(id);

// after
import { Interface } from 'fuels';

// search the types on the abi directly
const concreteType = abi.concreteTypes.find(ct => ct.concreteTypeId === id);
const metadataType = abiInterface.jsonAbi.metadataTypes.find(mt => mt.metadataTypeId === id);

JsonAbiArgument is no longer exported
The JsonAbiArgument type isn't part of the new ABI spec (#596, #599) as such so we stopped exporting it. Its closest equivalent now would be a concrete type because it fully defines a type.
// before
const arg: JsonAbiArgument = {...};

// after
import { Interface } from 'fuels';

type ConcreteType = JsonAbi["concreteTypes"][number]
const arg: ConcreteType = {...};

#2777 - Improve () and Option<T> type handling

() and Option<T> Sway types are now either required or optional, dependent on where the argument appears in the function arguments.

Given these Sway functions:
fn type_then_void_then_type(x: u8, y: (), z: u8) -> ()
fn type_then_void_then_void(x: u8, y: (), z: ()) -> ()

fn type_then_option_then_type(x: u8, y: Option<u8>, z: u8) -> ()
fn type_then_option_then_option(x: u8, y: Option<u8>, z: Option<u8>) -> ()

This is what changes:
// before
contract.functions.type_then_void_then_type(42, 43)
contract.functions.type_then_void_then_void(42) // Unchanged

contract.functions.type_then_option_then_type(42, undefined, 43)
contract.functions.type_then_option_then_option(42, undefined, undefined)

// after
contract.functions.type_then_void_then_type(42, undefined, 43)
contract.functions.type_then_void_then_void(42) // Unchanged

contract.functions.type_then_option_then_type(42, undefined, 43)
contract.functions.type_then_option_then_option(42)

#2827 -<EMAIL_ADDRESS>and large contract deployments
MAX_CONTRACT_SIZE is no longer exported, it should now be fetched from the chain.
// before
import { MAX_CONTRACT_SIZE } from 'fuels';

// after
import { Provider, FUEL_NETWORK_URL } from 'fuels';

const provider = await Provider.create(FUEL_NETWORK_URL);
const { consensusParameters } = provider.getChain();
const maxContractSize = consensusParameters.contractParameters.contractMaxSize.toNumber();

Fixes
#2963 - Assembly process for account transfer operation
The getTransferOperations helper function now requires an additional baseAssetId parameter.
// before
const transferOperations = getTransferOperations({ inputs, outputs, receipts })

// after
const transferOperations = getTransferOperations({ inputs, outputs, receipts, baseAssetId })

Chores
#2915 - Deprecate FUEL_NETWORK_URL and LOCAL_NETWORK_URL
Removed FUEL_NETWORK_URL constant.
// before
import { FUEL_NETWORK_URL } from 'fuels';

const provider = await Provider.create(FUEL_NETWORK_URL);

// after
const provider = await Provider.create('https://<IP_ADDRESS>:4000/v1/graphql');

Removed LOCAL_NETWORK_URL constant.
// before
import { LOCAL_NETWORK_URL } from 'fuels';

const provider = await Provider.create(LOCAL_NETWORK_URL);

// after
const provider = await Provider.create('https://<IP_ADDRESS>:4000/v1/graphql');

#2811 - Integrate launchTestNode in remaining packages
Removed generateTestWallet and seedTestWallet utilities.
// before
import { bn } from "@fuel-ts/math";
import {
  seedTestWallet,
  generateTestWallet,
} from "@fuel-ts/account/test-utils";

const provider = await Provider.create("http://<IP_ADDRESS>:4000/v1/graphql");

// seeding
const walletA = Wallet.fromPrivateKey("0x...", provider);
const baseAssetId = provider.getBaseAssetId();
seedTestWallet(wallet, [{ assetId: baseAssetId, amount: bn(100_000) }]);

// generating
const walletB = await generateTestWallet(provider, [[1_000, baseAssetId]]);

// after
import { launchTestNode } from 'fuels/test-utils';

// create two wallets seeded with 100_000 units of the base asset
using launched = await launchTestNode({
  walletsConfig: {
    count: 2,
    amountPerCoin: 100_000,
  },
});

const {
  wallets: [walletA, walletB]
} = launched;

const balance = await walletA.getBalance() // 100_000

Removed launchNodeAndGetWallets utility.
// before
import { launchNodeAndGetWallets } from 'fuels/test-utils';

const { provider, wallets } = await launchNodeAndGetWallets();

// after
import { launchTestNode } from 'fuels/test-utils';

using launched = await launchTestNode();

const { provider, wallets } = launched;

#2964 - Wrap subscriptions in promise
// before
const subscription = provider.operations.statusChange({ transactionId });
for await (const response of subscription) { ... }

const submittedTxSubscription = this.operations.submitAndAwait({ encodedTransaction: '0x' });

// after
const subscription = await provider.operations.statusChange({ transactionId });
for await (const response of subscription) { ... }

const submittedTxSubscription = await this.operations.submitAndAwait({ encodedTransaction: '0x' });

#2905 - Renamed AssetId to TestAssetId
Renamed testing class AssetId to TestAssetId.
// before
import { AssetId } from 'fuels/test-utils';

const [assetA] = AssetId.random();

// after
import { TestAssetId } from 'fuels/test-utils';

const [assetA] = TestAssetId.random();

On release of this PR:

Compare the time of release with the time of sync within CDNJS:
#2385
Check that the minified version (browser.min.mjs) is available 0.94.0:
#1728

On release of this PR:

Compare the time of release with the time of sync within CDNJS:
CDNJS not updating to our latest version #2385
Check that the minified version (browser.min.mjs) is available 0.94.0:
Add minified version in CDN #1728

Release published to CDNJS in about 10 minutes ⚡

https://github.com/FuelLabs/fuels-ts/releases/tag/v0.94.0
https://github.com/cdnjs/logs/commit/6470e5156e1715c8a33ad48bc03ce6d79c4887b7


Minor fix for improving support for error replies

Minor fix dealing with error replies.
Tested with AWS DocumentDB and MongoDB Atlas (TLS with no SNI).

Hello @rydnr, thanks for the contribution. I added an inline review comment to learn more about the change.
Do you know what's the version of MongoDB running in AWS DocumentDB and MongoDB Atlas, where you tested it? I wonder why there is a new way to detect errors. Maybe Mongo 4.4 has news?

Hello @rydnr, thanks for the contribution. I added an inline review comment to learn more about the change.
Do you know what's the version of MongoDB running in AWS DocumentDB and MongoDB Atlas, where you tested it? I wonder why there is a new way to detect errors. Maybe Mongo 4.4 has news?

AWS DocumentDB is not MongoDB, but supports the protocol. Or so they say.
In practice, I found some issues and ended up discarding it. But in the mean time, the errors I received from DocumentDB bypassed the existing check so I added this numb change.
It seems DocumentDB uses $errmsg instead of $err. The $code and $ok checks are there to exactly match the errors I found. For example, someone in his application uses $errmsg, as long as it doesn't use $code and $ok, this change would be harmless.
On the other hand, someone trying to use AWS DocumentDB might find this useful, if DocumentDB is suitable in his use case.
However, my motivation was two fold:

Maybe suggest a refactor to support an extensible mechanism to detect error messages.
Maybe include it in a set of changes to support AWS DocumentDB.

Since I'm not using DocumentDB, I don't need this change anymore.

AWS DocumentDB is not MongoDB, but supports the protocol. Or so they say.
In practice, I found some issues and ended up discarding it. But in the mean time, the errors I received from DocumentDB bypassed the existing check so I added this numb change.
It seems DocumentDB uses $errmsg instead of $err. The $code and $ok checks are there to exactly match the errors I found. For example, someone in his application uses $errmsg, as long as it doesn't use $code and $ok, this change would be harmless.
On the other hand, someone trying to use AWS DocumentDB might find this useful, if DocumentDB is suitable in his use case.
However, my motivation was two fold:

Maybe suggest a refactor to support an extensible mechanism to detect error messages.
Maybe include it in a set of changes to support AWS DocumentDB.

Since I'm not using DocumentDB, I don't need this change anymore.

Since I'm not using DocumentDB, I don't need this change anymore.

Well, we can close the PR. It will remain as a closed PR and can be recovered in the future if needed.

uses $errmsg, as long as it doesn't use $code and $ok

For the record, my question before was still valid anyway... I think there were missing "not"s on your code? something like: (results first includesKey: 'code') not and: [ (results first includesKey: 'ok') not ] .

Since I'm not using DocumentDB, I don't need this change anymore.

Well, we can close the PR. It will remain as a closed PR and can be recovered in the future if needed.

uses $errmsg, as long as it doesn't use $code and $ok

For the record, my question before was still valid anyway... I think there were missing "not"s on your code? something like: (results first includesKey: 'code') not and: [ (results first includesKey: 'ok') not ] .


dashboard: edit ecosystem partner dialog does not allow editing the prompt setting

When editing ecosystem partner configuration, clicking the prompt setting doesn't bring down the dropdown so you're not able to switch between prompt and never prompt.
macOS 14.2.1
Brave Browser Version 1.70.117 Chromium: 129.0.6668.59
https://github.com/user-attachments/assets/2aa2894c-b078-44b7-ab26-960f4c607f7a

This option is no longer relevant, We are removing it in https://github.com/thirdweb-dev/js/pull/4745


if region is < max_fragment_size, change max_fragment_size to region width

Currently if max_fragment_size is > region width, vplot will crash.
Instead, use region width as fragment size max & print message to user about
this change.

Really this should be abstracted into the Vmatrix struct with an insert and construct method.


Mouse pointer Crosshair & Mouse Jump Issue

Microsoft PowerToys version
0.68.0
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
Mouse Utilities
Steps to reproduce

Turn Mouse pointer Crosshairs & Mouse Jump utilities on
Activate Mouse Jump screen while having crosshairs enabled
Click anywhere to "mouse jump"

✔ Expected Behavior
Mouse pointer Crosshairs should follow pointer's coordinates after "mouse jump"
❌ Actual Behavior
Mouse pointer Crosshairs stayed in pointer's previous coordinates after "mouse jump"
Other Software
No response

It updates as soon as you move the mouse, but indeed it doesn't update right after the jump. It's because when we move the cursor there's no actual low level keyboard input to react to. Wonder if we need to fake it.

It’s possible SendInput might make the problem worse with the LittleBigMouse ticket - I think LBM looks for the first mouse event on a new monitor and scales the position and moves the cursor again - at the moment Mouse Jump moves the cursor ok with LBM enabled but LBM “skips” it when you move it, whereas it might skip it as part of the Mouse Jump if sees the synthetic SendInput event above, which would mean it would land in the wrong place rather than land, then skip.
Its glitchy behaviour either way, but I guess it depends on what’s least undesirable all round…
I’m happy to take a look if no-one else has started working in this yet…

Fixed in 0.69 which was released in the start of April 2023.


error below : protocol error for h2-server when trying to run in browser

error below : protocol error for h2-server when trying to run in browser
cargo run --example h2-server --release
    Finished release [optimized] target(s) in 0.08s
     Running `target/release/examples/h2-server`
listening on Ok(<IP_ADDRESS>:8080)
listening on Ok(<IP_ADDRESS>:8080)
listening on Ok(<IP_ADDRESS>:8080)
listening on Ok(<IP_ADDRESS>:8080)
  -> err=Error { kind: GoAway(b"", PROTOCOL_ERROR, Library) }
  -> err=Error { kind: GoAway(b"", PROTOCOL_ERROR, Library) }
  -> err=Error { kind: GoAway(b"", PROTOCOL_ERROR, Library) }
  -> err=Error { kind: GoAway(b"", PROTOCOL_ERROR, Library) }

Any updates on this? I'm experiencing the same issue.


What does missing plan mean?

This test is taking a while to run too, it times out after 30sec
test('Healthcheck', function(assert) {
  assert.plan(2);

  request.get(`${mock.baseUrl}/user/healthcheck`, function(err, res) {
    assert.equal(res.statusCode, 200);
    assert.equal(res.body, 'healthy', 'should return Healthcheck');
    assert.end();
  });
});

✓ should be equal
  ✓ should return Healthcheck
  1) missing plan

  2 passing (5s)
  1 failing

  1) test/health-check.test.js missing plan:
     missing plan

I'm not really sure - that phrase doesn't seem to appear anywhere in the codebase. Can you include the entire file, specifically the part that's requiring test?

check.test.js
var test = require('tape');
var request = require('request');
var nock = require('nock');
//var app = require('../bin/www');
var mock = require('./mocks/mock');
nock(mock.baseUrl)
.get(/user/${mock.sender}/profile)
.reply(200, mock.userProfile);
test('User Test', function(assert) {
//assert.plan(2);
request.get(${mock.baseUrl}/user/${mock.sender}/profile, function(err, res) {
let json = JSON.parse(res.body);
console.log('data99', json, mock.sender);
assert.equal(json.data.id, mock.sender);
assert.end();
});
});
==================================

tap --cov -R=spec test/*.test.js

Server listening on port 3001 !
GET /user/healthcheck 200 5.949 ms - 7
test/health-check.test.js
✓ should be equal
✓ should return Healthcheck

missing plan

and if you uncomment the "plan", the error goes away?
If so, that's expected. async tests need to either declare a planned number of assertions, or synchronously end.

The missing plan error remains with or without comment out  //assert.plan(2);
I added another test suite, and am trying to understanding the reporting result
GET /user/healthcheck 200 5.372 ms - 7
test/health-check.test.js
✓ should be equal
✓ should return Healthcheck

missing plan
Server listening on port 3001 !
test/user.test.js
✓ name should be Some Guy
test/user.test.js  (what does this mean?)

3 passing (4s)
2 failing

test/health-check.test.js missing plan:
missing plan

test/user.test.js:
test/user.test.js

I'm not really sure :-/ do you have a repo where I can reproduce this?

Here is the sample repo
https://github.com/playground/sample
try comment and uncomment out different asserts, it will produce different errors.
test('First test!', function (assert) {
request.get('http://localhost:3000/api/users', function(err, res) {
let json = JSON.parse(res.body);
assert.equal(json[0], 'John', 'name should be John');
//assert.equal(json[1], 'Joe', 'name should be John');
assert.end();
});
});
test('Second test!', function (assert) {
request.get('http://localhost:3000/api/users', function(err, res) {
let json = JSON.parse(res.body);
assert.equal(json[0], 'John', 'name should be John');
//assert.equal(json[1], 'Joe', 'name should be Joe');
assert.end();
});
});

if you comment out the second test, you will get
Server running on port 3000
test/user.test.js
✓ name should be John

test/user.test.js

1 passing (2s)
1 failing

test/user.test.js:
test/user.test.js

In both cases, you'd need to assert.plan() outside of the request.get, at the top level of the test.

I tried that already with assert.plan(1), still gets
test('First test!', function (assert) {
assert.plan(1);
request.get('http://localhost:3000/api/users', function(err, res) {
let json = JSON.parse(res.body);
assert.equal(json[0], 'John', 'name should be John');
//assert.equal(json[1], 'Joe', 'name should be John');
assert.end();
});
});
test('Second test!', function (assert) {
assert.plan(1);
request.get('http://localhost:3000/api/users', function(err, res) {
let json = JSON.parse(res.body);
assert.equal(json[0], 'John', 'name should be John');
//assert.equal(json[1], 'Joe', 'name should be Joe');
assert.end();
});
});
Server running on port 3000
test/user.test.js
✓ name should be John
✓ name should be John

missing plan

2 passing (2s)
1 failing

test/user.test.js missing plan:
missing plan

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

That's very strange. I'd love to see an example repo I could clone and reproduce locally.

https://github.com/playground/sample

You're using tap there, not tape. Run tape tests with node or tape. When I run node test/user.test.js everything works (altho it doesn't exit, because the server is still started, and not killed on test exiting)

hmm, do you know why it is failing with tap?  Tap gives a very nice report.

I'm not really sure - our tests use tap v0.7 so it's highly likely that we're not compatible with the latest version of tap. Typically you want to use node or tape as a runner, and then pipe the output to a formatter (like faucet, or perhaps tap itself).

Can you share with me one of your test and your setup?

https://github.com/ljharb/mocha-wrap/blob/master/package.json#L24


add execute block command

https://github.com/joereynolds/SQHell.vim/commit/cc4674a99affe0bfd75087fa07c1bf82868524d2


Adding Nicknames (New Feature) and fixing auto-color names in text events

Hello, Emilio and everyone else! My name is Zak. I have been wanting to add Nicknames to the project since I tried it out. I call my friends nicknames and it is common in literature and video games as well, so I felt that naturally it should be included. I finally decided to do it myself and I hope everyone else can find some use for them as well as a feature! What this entails is this: any Nicknames that you give to the character and enable in the editor will also follow auto-color rules. If you don't have auto-color enabled it does nothing. This is also per character so each one doesn't need to have Nicknames (similar to display names). What is different is that these are not on the name tag and you will not need to go in and manually color nicknames in text events using BBCode. This could be expanded upon in the future with Nicknames having more functionality (although I don't know what, maybe branch it off into a different feature) but that is all at the moment. Here are some GIFs showing the changes to the editor and the functionality:

General conversation showing their nicknames and names at the same time

Showing changes to the Character Editor

Showing off adding more Nicknames (you just put a comma in-between on the Nicknames: line edit)

Showing off that disabling it for one person only affects the Nicknames for that person. Everyone else continues to work.

Additionally, here is a screenshot where I show the previous issue with the names (this needed a fix regardless of this feature) and another with it fixed for comparison. As you can see the name should not be highlighted when part of another word:

Anyway, I thought this was neat and it seems to work well. I will be using this for my own games in the future (maybe not all of them but that is what makes it flexible) so I figured it would be something some people may want to use but obviously no one is required to use and doesn't impede on any existing functionality to do so (as far as I am aware). I hope you think it is worth adding as well. I love the project so far! To make it easier for you to go through, the files that were changed were: CharacterEditor.tscn (checkbox and line edit additions), CharacterEditor.gd, DialogicUtil.gd, and dialog_node.gd all had changes to accomplish this, though most were admittedly minor and nothing was really removed, just added to.
An additional note:
I have not tried it on a small screen like 13" so I don't know if the additional checkbox will make it seem to cramped there since I only have a 17" and 27" and seems to fit right in for me on both just fine. Some testing may be needed and is easy to just change a checkbox position to underneath the display name checkbox or something if needed (any contributor can do this if they want).
Have a Great day!
-Zak

Looks good! I'll test it a bit and see if I can merge it

Awesome! Looking forward to it!

Thank you! sorry for the delay 🙇♂


AAD authentication stopped working in Vs Code. Documentation need to be updated?

In our organization, we authenticate to Live Share using our corporate AAD. To do that, we had our admin approve the application "Visual Studio Live Share" in Azure AD, following this documentation: https://github.com/MicrosoftDocs/live-share/blob/f727e58c5f2f5752f8a18b8f21817efe92c2508e/docs/reference/security.md#aad-admin-consent
Recently, we found out after updating VsCode, we are no longer able to authenticate, but it still works in Visual Studio. We are now getting a message asking to have admin consent to approve "Visual Studio Services Client", which is not something present anywhere in the docs..
Can you please update the AAD Admin Consent section accordingly with the updated details, especially if the configuration details are now different for the 2 IDEs? Also, is it possible to have more info about this new application name, and what exactly it includes. It does not seem very specific to Live Share... Thank you!

@mfjerome Thanks for reaching out and sorry for the disruption. We changed our default to VSCode account authentication recently. To disable it and revert to the old flow, you can run Live Share: Disable VSCode account authentication command. Lets us know if this unblocks you.

@dlebu Thanks, I tried it quick and it seems to work. Can you elaborate on the difference between the 2 flows and what is the prefered way for the future? When you say VsCode account, does it have anything to do with VS Online?

I am glad you got unblocked. In the first scenario, for Microsoft accounts, we use the LiveShare website as an intermediate step for authentication (VSCode -> LiveShare website -> Microsoft Login -> LiveShare website -> VSCode). In the second, we skip the LiveShare website completely (VSCode -> Microsoft Login -> VSCode). The default behavior today is the latter, but we are still running experiments to decide what is the best way forward. Thanks for using Live Share!

Adding @lostintangent and @fubaduba as we need to update our documentation.

@dlebu I tried running that command with the latest extension version 1.0.2274, but it does not show up in the command prompt. Was this recently removed? I rather use VS 2019 since it works correctly, but some of my colleagues won't bother making the switch to VS 2019.

We've changed our authentication service. See #4128 and if the new authentication is giving you an issue, please create a new issue. Thank you for your patience.


Reorganize microservices in their own package; remove unused

Fixes #10356
Status
not-tested
Description
This PR doesn't contain any logical changes, only:

removed unused modules, such as: Regexp.py, Injector.py, Stageout.py, UnifiedStageout.py (from WMCore/MicroService/Unified)
restructuration of our microservices core code (and direct data structure) into their own package

Is it backward compatible (if not, which system it affects?)
yes (the IDE should have caught all the references and updated them for me)
Related PRs
none
External dependencies / deployment changes
none

Previous tree organization was:
src/python/WMCore/MicroService/
|-- CherryPyThreads
|   |-- HeartbeatMonitor.py
|   `-- __init__.py
|-- DataStructs
|   |-- DefaultStructs.py
|   |-- DefaultStructs.pyc
|   |-- MSOutputTemplate.py
|   |-- MSOutputTemplate.pyc
|   |-- MSRuleCleanerWflow.py
|   |-- MSRuleCleanerWflow.pyc
|   |-- Workflow.py
|   |-- Workflow.pyc
|   |-- __init__.py
|   |-- __init__.pyc
|   `-- campaigns.json
|-- Regexp.py
|-- Service
|   |-- Data.py
|   |-- Data.pyc
|   |-- RestApiHub.py
|   |-- RestApiHub.pyc
|   |-- __init__.py
|   `-- __init__.pyc
|-- Tools
|   |-- PycurlRucio.py
|   |-- PycurlRucio.pyc
|   |-- __init__.py
|   `-- __init__.pyc
|-- Unified
|   |-- Common.py
|   |-- Common.pyc
|   |-- Injector.py
|   |-- MSCore.py
|   |-- MSCore.pyc
|   |-- MSManager.py
|   |-- MSManager.pyc
|   |-- MSMonitor.py
|   |-- MSMonitor.pyc
|   |-- MSOutput.py
|   |-- MSOutput.pyc
|   |-- MSOutputStreamer.py
|   |-- MSRuleCleaner.py
|   |-- MSRuleCleaner.pyc
|   |-- MSTransferor.py
|   |-- MSTransferor.pyc
|   |-- RSEQuotas.py
|   |-- RSEQuotas.pyc
|   |-- RequestInfo.py
|   |-- RequestInfo.pyc
|   |-- SiteInfo.py
|   |-- SiteInfo.pyc
|   |-- Stageout.py
|   |-- TaskManager.py
|   |-- TaskManager.pyc
|   |-- __init__.py
|   `-- __init__.pyc
|-- UnifiedStageout.py
|-- WebGui
|   |-- FrontPage.py
|   `-- __init__.py
|-- __init__.py
`-- __init__.pyc

6 directories, 56 files

with this PR, the tree became:
src/python/WMCore/MicroService/
|-- CherryPyThreads
|   |-- HeartbeatMonitor.py
|   `-- __init__.py
|-- DataStructs
|   |-- DefaultStructs.py
|   |-- DefaultStructs.pyc
|   |-- __init__.py
|   |-- __init__.pyc
|   `-- campaigns.json
|-- MSCore.py
|-- MSManager.py
|-- MSMonitor
|   |-- MSMonitor.py
|   `-- __init__.py
|-- MSOutput
|   |-- MSOutput.py
|   |-- MSOutputStreamer.py
|   |-- MSOutputTemplate.py
|   `-- __init__.py
|-- MSRuleCleaner
|   |-- MSRuleCleaner.py
|   |-- MSRuleCleanerWflow.py
|   `-- __init__.py
|-- MSTransferor
|   |-- MSTransferor.py
|   |-- RSEQuotas.py
|   |-- RequestInfo.py
|   |-- Workflow.py
|   `-- __init__.py
|-- Service
|   |-- Data.py
|   |-- Data.pyc
|   |-- RestApiHub.py
|   |-- RestApiHub.pyc
|   |-- __init__.py
|   `-- __init__.pyc
|-- TaskManager.py
|-- Tools
|   |-- Common.py
|   |-- PycurlRucio.py
|   |-- PycurlRucio.pyc
|   |-- __init__.py
|   `-- __init__.pyc
|-- Unified
|   |-- SiteInfo.py
|   |-- SiteInfo.pyc
|   |-- __init__.py
|   `-- __init__.pyc
|-- WebGui
|   |-- FrontPage.py
|   `-- __init__.py
|-- __init__.py
`-- __init__.pyc

10 directories, 43 files

Well done @amaltaro! I like this reorganization pretty much. It is in perfect coherence with my practice of running the micro services standalone. And I like to have everything from a module at a single place.

@amaltaro , if you do reorganization please be consistent, e.g.
|-- MSCore.py
|-- MSManager.py
|-- MSMonitor
|   |-- MSMonitor.py
|   `-- __init__.py

Instead, you should put MSCore and MSManager in their own areas. This will achieve consistency and proper importing, e.g. from WMCore.MicroService.MSCore import MSCore, etc. It also will allow proper expansion of MSCore and MSManager if you'll need this in a future.

@vkuznet Valentin, the reason I kept those at the top level package of MicroService is:

MSCore is a super class common to all microservices
MSManager is sort of a microservice manager, creating/start/stop them; it also provides REST source code(which one could say it sort of doesn't belong here though).

In my opinion, it's also consistent with other parts of the WMCore repository, like the WMCore/Services package (where Service/Requests/pycurl_manager are common modules for all those services).
Perhaps another alternative could be to create another directory named MSCore (or even Core) and move both modules inside it (and the TaskManager, which isn't clear to me whether it's currently used or not). Still, I'm not convinced this approach would be better than leaving them at the top level MicroService package.
What do you/Todor think? Thanks for your feedback btw, I wanted to ask you about this as well.

Hi @amaltaro @vkuznet I would apply a simple logic here. If any of those could exist and provide meaningful functionality for instantiating or controlling (some kind of) a micro service independent of the other, then I would opt for putting them each in its own area. But in case their internal logic is inseparably connected then I would put them both together in a their common space.
So all that  said and giving a quick look again on them both I notice they do not even import each other. They both serve kind of core functionality, but while one is providing an interface to other central services, the other one is meant to be for driving the running MS processes. I can foresee a use case where a service of some kind may be created and using one of them but not the other. So in this case I tend to be more inclined in separating them each one in its own area.

Most of the WMCore project has been organized before I was even part of the team. However, in my analysis I see it organized in the following two ways:

by service/component and or functionality
by information/data type, e.g.: structures, utils, tools, rest/http, main logic, etc

So, in my opinion, the two alternatives that make more sense are:
a) as it is provided in this PR, thus core functionality for the microservices at the WMCore/MicroService package
b) we create a Core package and move MSCore, MSManager and TaskManager under it. Those provide core functionality and none of the WMCore Microservices can work without MSCore and MSManager.
It isn't clear what would we gain by creating another package for MSCore, and another for MSManager (and perhaps even another one for TaskManager). That's why I don't even list it as another alternative. Meaningful names also don't come to my mind.
Todor, Valentin, if you have further comments, please let me know. Otherwise I planning to get it merged tonight. It's anyways a big improvement on the current structure.

That is fine with me Alan, and the key sentence here is:

Those provide core functionality and none of the WMCore Microservices can work without MSCore and MSManager.

As I said earlier a valid reason for me to put them in a common package would be if their logic is hardly coupled.
And I totally agree this is a huge improvement!

Thanks Todor. I will just try to separate the test from the src changes, which I mistakenly put all in the same commit.

 Thanks Todor.

Hi @amaltaro, Sorry for writing in an already closed PR, but I just found we  have reorganized the source code modules but we somehow missed to do so for the unit tests related to them. If you did not leave those behind for a reason, I think we should change the directory structure there too.

Good catch Todor, sorry for missing it. I'm going to create another PR to complement this one.


Connection Drop/Network drop on a Jest Client

Not really an issue, but I wanted to know how Jest handles a connection/network drop. What do we need to do when a singleton jest client goes through a network drop while querying the node?

As stated in here any exceptions thrown by Apache HttpClient are not handled by jest so they'll be thrown to user.


runtime: immediate lock-up when using go library in Unity 6

Go version
go1.21.1 darwin/arm64 (we have observed identical behaviour when using go 1.23.1 and 1.23.4)
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='Library/Caches/go-build'
GOENV='Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='temp/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/$HOME/temp/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/f8/0nlswm8x445_jl3720jx6kmw0000gn/T/go-build2270444360=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?
When running on Apple Silicon hardware:
Prerequisites:

Extract plugin code: TestPlugin.zip
Extract Unity 2022.3.43f1 repro project: Unity2022ReproProject.zip. Do not open the project yet.
Extract Unity 6000.0.28f1 repro project: Unity6ReproProject.zip. Do not open the project yet.
Install dylibbundler required for dylib signing (brew install dylibbundler)
Build attached TestPlugin go lib as .dylib on MacOS (using cgo). You can use the included magefile.
Copy build/TestPlugin.dylib to the extracted Unity 2022 project in Assets/Plugins/TestPlugin.dylib.
Copy the same build/TestPlugin.dylib to the extracted Unity 6 project in Assets/Plugins/TestPlugin.dylib.

What did you see happen?
In Unity 2022
Unity 2022 (and also other versions like Unity 2021 and Unity 2023) is working as expected.
Open the Unity 2022 project, open the Scenes/SampleScene and click the Play button. Observe that the Unity Console shows:
Calling HelloWorld on plugin...
Successfully called HelloWorld on plugin...

If you open ~/Library/Logging/Unity/Editor.log it will show:
Calling HelloWorld on plugin...
UnityEngine.StackTraceUtility:ExtractStackTrace () (at /Users/bokken/build/output/unity/unity/Runtime/Export/Scripting/StackTrace.cs:37)
UnityEngine.DebugLogHandler:LogFormat (UnityEngine.LogType,UnityEngine.Object,string,object[])
UnityEngine.Logger:Log (UnityEngine.LogType,object)
UnityEngine.Debug:Log (object)
MacOSPluginLoader:Start () (at Assets/Scripts/MacOSPluginLoader.cs:17)

(Filename: Assets/Scripts/MacOSPluginLoader.cs Line: 17)

Hello from Go!
Hello from Go 2!
Hello from Go 3!
Successfully called HelloWorld on plugin...
UnityEngine.StackTraceUtility:ExtractStackTrace () (at /Users/bokken/build/output/unity/unity/Runtime/Export/Scripting/StackTrace.cs:37)
UnityEngine.DebugLogHandler:LogFormat (UnityEngine.LogType,UnityEngine.Object,string,object[])
UnityEngine.Logger:Log (UnityEngine.LogType,object)
UnityEngine.Debug:Log (object)
MacOSPluginLoader:Start () (at Assets/Scripts/MacOSPluginLoader.cs:19)

In Unity 6
Unity 6 is immediately locking up (showing a beachball spinner) as soon as any go API is called.
Open the Unity 6 project, open the Scenes/SampleScene and click the Play button. Observe that the Unity Console shows:
Calling HelloWorld on plugin...

If you open ~/Library/Logging/Unity/Editor.log it will show:
Calling HelloWorld on plugin...
UnityEngine.StackTraceUtility:ExtractStackTrace () (at /Users/bokken/build/output/unity/unity/Runtime/Export/Scripting/StackTrace.cs:37)
UnityEngine.DebugLogHandler:LogFormat (UnityEngine.LogType,UnityEngine.Object,string,object[])
UnityEngine.Logger:Log (UnityEngine.LogType,object)
UnityEngine.Debug:Log (object)
MacOSPluginLoader:Start () (at Assets/Scripts/MacOSPluginLoader.cs:17)

What did you expect to see?
Unity 2022 and Unity 6 to behave the same. Instead, Unity 2022 is behaving as expected wheras Unity 6 immediately locks-up the Unity Editor.

I'm sorry, I don't know what Unity is.  But from your description, this seems like a problem with Unity, not a problem with Go.  Have you raised this with the developers of Unity?

I'm sorry, I don't know what Unity is.

Unity is a 3D game engine that is used abundantly.

But from your description, this seems like a problem with Unity, not a problem with Go. Have you raised this with the developers of Unity?

Plugins written in plain C/C++ work just fine in the Unity Editor. When you add (c-)go in the mix Unity locks-up, hence our believe that this (c-)go related.
In the meantime we have a couple more findings:

The exact same go code works fine in Unity 6000.0.28f1 when compiled as a Windows DLL.
If you build the Unity 6 project into a stand-alone app on MacOS it also works OK.

Just to set expectations, while the problem may be Go related, since we don't know anything about Unity it's unlikely that we'll be able to figure this out.

Just to set expectations, while the problem may be Go related, since we don't know anything about Unity it's unlikely that we'll be able to figure this out.

Appreciated that. We are willing to contribute. Any pointer on where to start debugging this issue would be appreciated.
To set the scene, the following minimal example (from the ZIP files attached to the first post) is causing the lock-up:
package main

// #include <stdio.h>
// #include <stdlib.h>
import "C"
import (
	"fmt"
)

//export HelloWorld
func HelloWorld() {
	fmt.Println("Hello from Go!")
}

func main() {}

Build:
go build -o ./TestPlugin.dylib -buildmode=c-shared -ldflags="-s -w" TestPlugin.go
C#:
    private const string PluginRelativePath =  "TestPlugin";
    [DllImport(PluginRelativePath, EntryPoint = "HelloWorld", CallingConvention = CallingConvention.Cdecl)]
    private static extern void HelloWorld();

    void Start() {
            Debug.Log("Calling HelloWorld on plugin...");
            HelloWorld();
            Debug.Log("Successfully called HelloWorld on plugin...");
    }

Unity locks up when executing HelloWorld();

I'm sorry, I have no idea.  From your description, it works with one version of Unity and fails with a different one.  So something must have changed in Unity, but I have no idea what.

We have reported this issue to Unity (issue 91704, I do not have a public link (yet?)).
Our own investigation (by sprinkling log lines in the go source code) has shown that the go runtime is at least reaching x_cgo_init:
https://github.com/golang/go/blob/05d8984781f7cf2f0f39b53699a558b6a1965c6c/src/runtime/cgo/gcc_darwin_arm64.c#L129
and we see a number of threads spinning up in _cgo_sys_thread_start:
https://github.com/golang/go/blob/05d8984781f7cf2f0f39b53699a558b6a1965c6c/src/runtime/cgo/gcc_darwin_arm64.c#L27
when the plugin is loaded  by the unity editor.
But when we call the exported function, it immediately hangs. At this point, I have no clue where to look next. Are there other spots where I can add some log lines to see what is going on? Any pointer is greatly appreciated.

When a Go library is built with -buildmode=c-shared, then when the library is loaded the Go initializers are run automatically in a separate thread.  This means that we can have a deadlock in the case where code in a Go initializer calls a non-Go function that then calls a Go function. The call to the Go function will wait for initializers to complete, but that will never happen because the initializer is waiting for the non-Go function to complete. Perhaps that is what is happening here, somehow.


Attack an ensemble of networks

Hi, thx for your sharing. I notice that in your CVPR-19 paper "Improving transferbility of Adversarial examples with input diversity", your work contains attacking an ensemble of networks, but in your released code, I haven't found the corresponding code, can you release it?

Thanks for your interest in our work.
You can find the ensemble template in this repo https://github.com/dongyp13/Non-Targeted-Adversarial-Attacks/blob/master/attack_iter.py


docs: update the events-example README

Includes some cleanup in the packaging for the example. At the moment, the function fails to execute because of auth failures. This is a draft PR until that is resolved.

Figured out the auth issue by removing the trailing slash on the basePath. Updated the README.
Once the developer token is available in the NAD, we can update this demo and readme to use either your creds or your token.


Catch exceptions when cleanUp is used from the main menu

Catch exceptions during use of the cleanUp menu action (dev mode).
If there are some exception, display a popup with the list of detected problems.

Fixed in #87


Add bindings far WasmValidator and use it if PassOptions.validate

See wasm-opt.cpp

We don't actually need to bind the type since wasm-opt.cpp just calls 'validate' on it. Instead we can create a free function called validateWasm that both instantiates and runs the validator.

done


Release-Please does not detect the scope in a monorepo

Environment details

OS: ubuntu-latest
Node.js version: 19.0.0
npm version: 8.19.2
release-please version: 2.0.0

Steps to reproduce

Add commits according to conventional-commit syntax, like:

fix(package-a): Some title
feat!(package-b): Some other title

If they are merge by the same PR to the target-branch both changelog are going to be updated with the braking change on the next release, scopes: package-a and package-b

Q: How do we address scopes? package name? package path? Non of them are working to avoid update wrong package

In a monorepo, commits are applied to different components by the files touched in the commit. So if you configure paths as package-a/ and package-b/, then a commit that only touches files within one of those paths will apply to that component. If a commit touches both, then it will apply to both components.
The scope part of the conventional commit is only used as a prefix in the release notes. Example: fix(deps): upgrade dependency foo to 1.2.3 would look like:

Bug Fixes

deps: upgrade dependency foo to 1.2.3

This gets weird when I tried to use an empty commit to force a version bump.


Release proposal: v1.33.2

There are currently only three commits queued up for release, but I'd like to get them out the door next week (11/17 - 11/23). Currently, this would be a semver-patch release.
As usual, please raise any comments or concerns here.

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1625/
Node integration CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/111/

This will be 1.34.0 due to https://github.com/libuv/libuv/pull/2548.
I'm currently just waiting on https://github.com/libuv/libuv/pull/2546 and https://github.com/libuv/libuv/pull/2545 before moving forward with the release.

I'm currently just waiting on #2546 and #2545 before moving forward with the release.

I've addressed Ben's comments on both of these and kicked off CI's. FYI I won't be able to land anything until Sunday evening at the earliest but assuming the CI's are good I consider these landable (although more reviews always welcome).

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1654/
Node integration CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/114/


Add ability to import some/all packages for a given vendor

Created a backlog card for this in Trello to track there.


Bump up cypress version to 7.3.0

@tianfeng92 What about https://github.com/saucelabs/sauce-cypress-runner/blob/master/Dockerfile#L9 ?


Add the option to change the probability of the atom type occurence

I noticed that many structures include e.g. B or Al since they lead to stable structures. Therefore, it would be helpful to change the probability of their occurrence. This could, e.g, be done in a similar way as element_composition by setting the probability to 100% for every atom type and letting the user set custom probabilities in the .toml file:
element_probability = "Al:0.5,B:0.3"

After our in-person discussion, I spent some thoughts on this, and one way to implement this (while still being in accordance with the basic working principle of the code and not cluttering it too much) would be the following:

Initializing an array of len(103) filled with 1.0 for each
User input similar to the one for element_composition would enable manipulating these values for specific elements. Values > 1.0 would increase the probability of this element being chosen, while values < 1.0 would decrease it.
For the part, in which random atoms are assigned for the atom list (of the resulting molecule) (and only for that part!), an integer element number ranging from 1 to 103 (or currently 86) would not be chosen completely randomly but weighted by the aforementioned array. This is probably super easy to realize using numpy.

What do you think about these ideas, @gasevic? And maybe pinging also @jonathan-schoeps?

Sounds good to me!


Type 'X' is not assignable to type 'X'.

Bug Report
Since 4.6 TS is complaining about that false is not assignable to boolean, when it is "wrapped by interface".
🔎 Search Terms
4.6 type
🕗 Version & Regression Information

This is a compile problem
This changed between versions 4.5.5 and 4.6

⏯ Playground Link

Playground Link
💻 Code

interface Observable<T>
{
  (): T;
  (value: T): any;
}

function observable<T>(value: T): Observable<T>
{
  return undefined as any;  // the implementation is not important
}

const x: Observable<boolean> = observable(false);

🙁 Actual behavior
Type 'Observable<false>' is not assignable to type 'Observable<boolean>'.
  Types of parameters 'value' and 'value' are incompatible.
    Type 'boolean' is not assignable to type 'false'.

🙂 Expected behavior
No compiler problem as in previous versions.

I believe this is a correct error which was not handled properly in old versions.
The generic parameter T is invariant as it is used in both a covariant position () => T and a contravariant position (value: T) => any.

@whzx5byb Suppose this is correct behavior, can you suggest how to continue to use the sketched concept? The interface in fact represents the core concept of Knockout.js library.
To set value to x - use x(val).
To read value from x - use x().
If x is defined to operate on boolean, It is very illogical that I can not set true or false as val. Of course I can cast to boolean, but is it the correct way? And is it the only way?

If x is defined to operate on boolean, It is very illogical that I can not set true or false as val. Of course I can cast to boolean, but is it the correct way? And is it the only way?

A way to make your example work:
function observable<T>(value: T extends infer U ? U: never): Observable<T>
{
  return undefined as any;  // the implementation is not important
}

const x: Observable<boolean> = observable(false); // no error

@whzx5byb  Just perfect, thanks!
I do not know if it is appropriate here, but if you want, you could post this as answer on https://stackoverflow.com/questions/71319489/type-observablefalse-is-not-assignable-to-type-observableboolean . Or I could do it using the code you proposed if you want. Please give me the info, I will close this bug then.

@tomhanax perhaps this should be referred to the knockout project so that the necessary changes can be made there.

@tomhanax perhaps this should be referred to the knockout project so that the necessary changes can be made there.
Done: https://github.com/knockout/knockout/issues/2589, hope that somebody there will pick that up, because the project seem to go to winter sleep for good.

@tomhanax I don't care, you could post it yourself.

@tomhanax
The answer in https://github.com/microsoft/TypeScript/issues/48150#issuecomment-1060539236 is not perfect, as it will produce unknown without a type annotation.
const bad = observable(false);
//     ^ unknown, which should be Observable<boolean>

The issue here is the inference T extends infer U ? U : never infers U from the LHS of assignment. But when there is none, the default constraint type unknown will be used.
Here is an alternative workaround which will produce the same behavior without a type annotation, but a bit more verbose. I have to introduce two type parameter. T is for the refered type which is from LHS. U is for the "raw" widening type, which will be used only when T is unknown.
declare function observable<T, U>(value: T extends infer R ? R : U): unknown extends T ? Observable<U> : Observable<T>;

I'm not sure if there is a better solution. If you find some please let me know.

Cross-posting here, just for the record. Make sure that also both these lines are valid with any new proposal.
const x = observable<false | undefined>(false);
const y = observable(false);

@mbest, the "most updated" playground contains many examples and seems OK, of course anybody can check and correct if needed, I am no expert in this.
Playground Link
I am not saying anything about what "should" be fixed, I am no expert at all. Simply trying to help to solve existing issue, because now we are forced to remain on TS 4.5 until this is solved.

@tomhanax why was the issue closed? Isn't this a valid bug in Typescript?
As @mbest pointed out:
const w = observable(false); // Typescript identifies 'w' as Observable<boolean>
const x: Observable<boolean> = observable(false); // Type being Observable<false> now

Typescript seems to change it's mind of what type observable(false) actually is.

@maskmaster to be honest I am not sure. I only know that what worked previously does not work now. As @whzx5byb pointed out, the whole thing may be "reversed" - it was working because of less perfect previous TS version that allowed this and now it is not working because simply it should not work in the first place. I am not good at type theory at all, so anybody else have to say funded words.
Anyway, I am reopening this in hope for clarification.

Typescript seems to change it's mind of what type observable(false) actually is.

This should be related to the "type widening" mechiasm. For more details: https://github.com/microsoft/TypeScript/pull/10676, https://github.com/microsoft/TypeScript/pull/11126, https://github.com/microsoft/TypeScript/pull/24310.
And here boolean behaves a little bit different because it is actually implemented as a union equivalent to true | false.
declare function fn<T>(x: T): T[];

const b1 = fn(true); // T is boolean (widening)
const n1 = fn(1);  // T is number (widening)

const b2: boolean[] = fn(true); // T is true (non-widening)
const n2: number[] = fn(1); // T is number (widening)

const b3: (true | false)[] = fn(true); // T is true (non-widening)
const n3: (1 | 0)[] = fn(1); // T is 1 (non-widening)

The following is valid
const w = observable(false);
const v: Observable<boolean> = w;

However, this is not valid
const v: Observable<boolean> = observable(false);

To me, it makes no sense.

@maskmaster any type with a contravariant position has this problem

Bisected to #47341. @ahejlsberg this seems like an unintended consequence?

Before 4.6 we'd measure variance of Observable<T> wrong:
declare let xb: Observable<boolean>;
declare let xf: Observable<false>;

xb = xf;  // Error, but wasn't before 4.6
xf = xb;  // Error

The type parameter T is used in both input and output positions within Observable<T>, so clearly Observable<T> is invariant and our current behavior is correct. We got it wrong before because we'd cross-relate the signatures, which sometimes makes sense for different source and target types, but never makes sense when source and target are instantiations of the same type (which they are when we're measuring variance). Not only was it wrong to cross-relate them, it also generated a lot more work, which was the problem fixed in #47341.

@ahejlsberg I totally agree with the correctness of your example and that the new behavior as you describe is correct.
I think we are talking about two different things.
In this simple example
const w = observable(false);

According to Typescript 4.6 'w' is an Observable<boolean>.
Still, it is not possible to do (exactly what typescript suggests)
const w: Observable<boolean> = observable(false);

According to you, what is the correct type of 'w' in const w = observable(false)?

@maskmaster Hmm, yeah, that is a known design limitation, and I agree it's unfortunate. See my comment here. The workaround is to write:
const w: Observable<boolean> = observable(false as boolean);

@maskmaster Regarding the type of
const w = observable(false);

it is producing the intended Observable<boolean>. There is no contextual type for the false argument and therefore we widen the type to boolean. Just like we would widen 42 to number.

const w: Observable<boolean> = observable(false as boolean);

Bluntly said this is absolutely silly. In year 2022 you can not possibly tell this to the "average programmer".
Anyway, what is the problem with "more verbose" typings illustrated in the beforementioned playground? I am only asking because that "simply works", but to be true, I really do not understand the magic there.

Bluntly said this is absolutely silly

Yeah, as I said, it's unfortunate. I'll open an issue on this specifically and we'll see if we can do better.

Thank you @ahejlsberg for the explanation. It makes sense if it a design limitation. I'll try to wrap my head around this later on so I understand exaxtly what happens.
Please, could you also link the other issue that you opened/will open?

Hi,
It seems this issue is not yet solved.
I use Knockout with TS and am currently stuck using TS version 4.5.
Using higher versions of TS (currently trying v4.8.4), I get unexpected errors.
Half of the errors are fixed by the more specific definition suggested by @tomhanax.
//export function observable<T>(value: T): Observable<T>;
export function observable<T, U = any>(value?: T extends infer R ? R : U): unknown extends T ? Observable<U> : Observable<T>;
export function observable<T = any>(value: null): Observable<T | null>

E.g.: Without the fix, the following results in a TS compiler error:
AttestType: Observable<EAttestType> = ko.observable(EAttestType.Consultatie);

And, in order to please the TS compiler, would need to be changed to this:
AttestType: Observable<EAttestType> = ko.observable<EAttestType>(EAttestType.Consultatie);

or this:
AttestType: Observable<EAttestType> = ko.observable(EAttestType.Consultatie as EAttestType);

However, we still encounter other TS compiler errors, specifically related to types inheriting abstract classes in observables in the following form:
export class ModalExistingPatientsComponentParams extends BaseComponentParams {
    ComponentViewModel: Observable<ModalExistingPatientsComponentViewModel | null> = observable<ModalExistingPatientsComponentViewModel | null>(null);

    constructor() {
        super();
    }
}

Property 'ComponentViewModel' in type 'ModalExistingPatientsComponentParams' is not assignable to the same property in base type 'BaseComponentParams'.
  Type 'Observable<ModalExistingPatientsComponentViewModel | null>' is not assignable to type 'Observable<BaseComponentViewModel | null>'.
    Types of parameters 'value' and 'value' are incompatible.
      Type 'BaseComponentViewModel | null' is not assignable to type 'ModalExistingPatientsComponentViewModel | null'.

TS says that it cannot assign the base type to the derived type, which is correct.
But the question is, why is it trying to do this in the first place?
I think that the knockout TS definitions are not supporting working with derived types in observables.
Here is a simplified playground detailing the issue:
Playground link


Ryan M: Watch f[a4]g+[oie0]try

Ryan M requests the watch of the watch_keyword f[a4]g+[oie0]try. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

f[a4]g+[oie0]try has been seen in 3 true positives, 1 false positive, and 0 NAAs.

Approved by Eliah Kagan in Charcoal HQ


ReferenceError: recognizedKeywords is not defined

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0)
v0.29.0 Release
running locally
Iam trying to get an answer on: Hello Iam Jan
And rasa should answer: Hello Jan
So i have created a custom keyword with regex matcher: (?<=Hello Iam).*
The system matches users name successfully but throws an error on my console and no response is given.

{ error:
api_1            |    ReferenceError: recognizedKeywords is not defined
api_1            |        at recognizedKeywords (/usr/src/app/lib/services/agent/agent.converse-fill-action-slots.service.js:278:63)
api_1            |        at Array.forEach ()
api_1            |        at AgentService.forEach (/usr/src/app/lib/services/agent/agent.converse-fill-action-slots.service.js:205:32)
api_1            |        at Generator.next ()
api_1            |        at asyncGeneratorStep (/usr/src/app/lib/services/agent/agent.converse-fill-action-slots.service.js:9:103)
api_1            |        at _next (/usr/src/app/lib/services/agent/agent.converse-fill-action-slots.service.js:11:194)
api_1            |        at process._tickCallback (internal/process/next_tick.js:68:7),
api_1            |   message: null }
api_1            | Debug: handler, error
api_1            |     Error: recognizedKeywords is not defined
api_1            |     at /usr/src/app/lib/routes/agent/agent.converse.route.js:43:24
api_1            |     at Generator.throw ()
api_1            |     at asyncGeneratorStep (/usr/src/app/lib/routes/agent/agent.converse.route.js:19:103)
api_1            |     at _throw (/usr/src/app/lib/routes/agent/agent.converse.route.js:21:291)
api_1            |     at process._tickCallback (internal/process/next_tick.js:68:7)

We fixed these one, but is in master. Haven't been released


feat: no more delay on first run

What does this PR do?
No more delay on first run.
Fixes #709.
Motivation
#709
Additional Notes
To do this, make sure the service waits for the network to be ready before starting:
Systemd configures dependencies with Dependencies. e.g. https://github.com/kardianos/service/blob/fffe6c52ed0fd8653543bbe72432dbf6ea02f300/example/logging/main.go#L73
Windows uses DelayedAutoStart to change the startup type to 自动(延迟启动) (wait for the 自动 service to finish starting before starting). e.g. https://github.com/Graylog2/collector-sidecar/blob/e10b4c66dc1cc683a2168521fba414bcb855c0da/services/service_options_windows.go#L22
Ref: https://stackoverflow.com/a/25575496

考虑这种情况，停电后来电了，nas启动了，路由器还未完全启动

有个方案不知如何？增加一个dns检测，未报错，直接运行，报错，首次启动延迟10s

等待网络连接后再继续。

请求baidu.com还是检测dns？ 检测dns感觉要轻量些，万一百度没干了不是运行不起了


Adding dev environment

Description
Thanks for the presentation just now at the IAEA Open Source Software Conference. I thought you might be interested in this feature to allow users to launch the ARMI python environment in GitHub code spaces.
Checklist

[ ] The code is understandable and maintainable to people beyond the author.
[ ] Tests have been added/updated to verify that the new or changed code works.
[x] There is no commented out code in this PR.
[ ] The commit message follows good practices.
[ ] All docstrings are still up-to-date with these changes.

If user exposed functionality was added/changed:

[ ] Documentation added/updated in the doc folder.
[ ] New or updated dependencies have been added to setup.py.

Very interesting, and thanks for the demo of what this can do at the workshop. I think we definitely will take this in.
@john-science  this is effectively a github based jupyterhub environment that people can interact with, including the code and ipython!

hmm it didn't show up immediately, probably b/c we have to turn something on at the organization level?

Also users with code space enabled can run this without it being enabled on the terrapower org

It's a neat idea!
I'm curious where these dependencies came from:
https://github.com/terrapower/armi/blob/4894a56c4c5498272d47b6bc307765eb207f4801/.devcontainer/devcontainer.json#L17-L18
and:
https://github.com/terrapower/armi/blob/4894a56c4c5498272d47b6bc307765eb207f4801/.devcontainer/devcontainer.json#L22-L26
In reality, we use black. And while we "technically" use pylint, in my year on the project no one has ever mentioned it during a single PR.
Are these just standard pieces of the Python version of codespaces?   Or can I go through and pair down these dependencies a bit, without affecting anything?


Not compatible

"formsy-material-ui": "^0.6.3",
and
"formsy-react": "^1.1.4",
throws Error when use
<Formsy.Form>
....
</Formsy.Form>

try  - i.e. drop the .Form.  This is a (subtle) change from previous versions, the new syntax is documented, but the need to change it isn't very well signposted!


[HBASE-22874] Canary should not be IA.Public

Things I changed in this PR:

Created CanaryInterface class which will be marked as Public. (I am not that good with names. Please let me know if you can think of something better).
Created 3 methods to call RegionCanary, RegionServerCanary and ZookeeperCanary via Api.
Created conf properties for all options that we pass via ToolRunner.
Tried to commonalize the code between ToolRunner and API usage.

Outstanding questions that I need help from community.

Does it make sense to have "daemon" flag via api usage ?
Should we allow using "interval" argument via api. If I specify interval it means canary will run every "interval" seconds.
There are 3 properties which fails on error. -f, -treatFailureAsError, -failureArError
Can we just create 1 conf property for usage via API. We still will support all 3 arguments via ToolRunner interface.
How to figure out which constructor for CanaryInterface to expose ?
Do we need to instantiate executor if it is null ? Today Canary has one constructor which accepts executor as argument. We never verify whether the passed executor is instantiated or not. Feels like bug to me. Or is it understood that if someone calls that constructor, its his/her responsibility to instantiate executor.

For some unknown reason asfgit user closed my earlier PR: https://github.com/apache/hbase/pull/565 so I created another one.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
82
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ master Compile Tests _

+1
mvninstall
401
master passed

+1
compile
68
master passed

+1
checkstyle
94
master passed

+1
shadedjars
304
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
40
master passed

0
spotbugs
276
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
273
master passed

_ Patch Compile Tests _

+1
mvninstall
331
the patch passed

+1
compile
60
the patch passed

+1
javac
60
the patch passed

-1
checkstyle
89
hbase-server: The patch generated 2 new + 21 unchanged - 2 fixed = 23 total (was 23)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
323
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1108
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
javadoc
37
the patch passed

+1
findbugs
282
the patch passed

_ Other Tests _

-1
unit
16255
hbase-server in the patch failed.

+1
asflicense
27
The patch does not generate ASF License warnings.

20185

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestFromClientSide

Subsystem
Report/Notes

Docker
Client=19.03.2 Server=19.03.2 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/580

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux<PHONE_NUMBER>3a 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-580/out/precommit/personality/provided.sh

git revision
master / dfe5280d0c

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/1/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/1/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/1/testReport/

Max. process+thread count
4621 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/1/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
0m 36s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  1s
No case conflicting files found.

:green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

:green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ master Compile Tests _

:green_heart:
mvninstall
5m 24s
master passed

:green_heart:
compile
0m 55s
master passed

:green_heart:
checkstyle
1m 18s
master passed

:green_heart:
shadedjars
4m 31s
branch has no errors when building our shaded downstream artifacts.

:green_heart:
javadoc
0m 37s
master passed

:blue_heart:
spotbugs
4m  0s
Used deprecated FindBugs config; considering switching to SpotBugs.

:green_heart:
findbugs
3m 58s
master passed

_ Patch Compile Tests _

:green_heart:
mvninstall
4m 49s
the patch passed

:green_heart:
compile
0m 54s
the patch passed

:green_heart:
javac
0m 54s
the patch passed

:broken_heart:
checkstyle
1m 19s
hbase-server: The patch generated 1 new + 21 unchanged - 2 fixed = 22 total (was 23)

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

:green_heart:
shadedjars
4m 34s
patch has no errors when building our shaded downstream artifacts.

:green_heart:
hadoopcheck
15m 34s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

:green_heart:
javadoc
0m 35s
the patch passed

:green_heart:
findbugs
4m 16s
the patch passed

_ Other Tests _

:broken_heart:
unit
158m 29s
hbase-server in the patch failed.

:green_heart:
asflicense
0m 28s
The patch does not generate ASF License warnings.

215m  1s

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/580

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 8bfe6c5d2891 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-580/out/precommit/personality/provided.sh

git revision
master / 0d338a1820

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/2/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/2/testReport/

Max. process+thread count
4916 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/2/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

@jatsakthi Would like to see this commit in 1.3 release also. Apologies if I am requesting to review too many PR's. I will really appreciate if you can review this PR. Thank you !

Outstanding questions that I need help from community.
Does it make sense to have "daemon" flag via api usage ?
Should we allow using "interval" argument via api. If I specify interval it means canary will run every "interval" seconds.
There are 3 properties which fails on error. -f, -treatFailureAsError, -failureArError
Can we just create 1 conf property for usage via API. We still will support all 3 arguments via ToolRunner interface.
How to figure out which constructor for CanaryInterface to expose ?
Do we need to instantiate executor if it is null ? Today Canary has one constructor which accepts executor as argument. We never verify whether the passed executor is instantiated or not. Feels like bug to me. Or is it understood that if someone calls that constructor, its his/her responsibility to instantiate executor.

On 'daemon' api option, it is an odd option to expose IMO. Would think it daemon would be set always when calling something via API (i.e. in context).
Interval as argument seems fine. What you thinking?
One error option makes sense.
" Feels like bug to me. " Me too.
From an API, I'd think you'd be passing an executor?

Thank you @saintstack  for your review.

Interval as argument seems fine. What you thinking?

If I understand the interval parameter correctly, it will run the given canary periodically every interval seconds. If we are running the Canary via ToolRunner, it will create a new process and we can make it run every few seconds but if we call via api from some application, then it is the application's responsibility to call canary every interval seconds.
Any thoughts ?

Makes sense.  Interval is for the daemon version of Canary which makes no sense when being called from API. Yeah, no 'interval'. No 'daemon' option either.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
0m 42s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  0s
No case conflicting files found.

:green_heart:
hbaseanti
0m  1s
Patch does not have any anti-patterns.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

:green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ master Compile Tests _

:green_heart:
mvninstall
6m 54s
master passed

:green_heart:
compile
0m 57s
master passed

:green_heart:
checkstyle
1m 26s
master passed

:green_heart:
shadedjars
4m 32s
branch has no errors when building our shaded downstream artifacts.

:green_heart:
javadoc
0m 38s
master passed

:blue_heart:
spotbugs
4m 16s
Used deprecated FindBugs config; considering switching to SpotBugs.

:green_heart:
findbugs
4m 14s
master passed

:yellow_heart:
patch
4m 23s
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

:green_heart:
mvninstall
5m 12s
the patch passed

:green_heart:
compile
1m  0s
the patch passed

:green_heart:
javac
1m  0s
the patch passed

:broken_heart:
checkstyle
1m 25s
hbase-server: The patch generated 3 new + 21 unchanged - 2 fixed = 24 total (was 23)

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

:green_heart:
shadedjars
4m 46s
patch has no errors when building our shaded downstream artifacts.

:green_heart:
hadoopcheck
15m 38s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

:green_heart:
javadoc
0m 35s
the patch passed

:green_heart:
findbugs
4m 26s
the patch passed

_ Other Tests _

:green_heart:
unit
160m 44s
hbase-server in the patch passed.

:green_heart:
asflicense
0m 38s
The patch does not generate ASF License warnings.

220m 12s

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/580

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux b9370cd1227d 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-580/out/precommit/personality/provided.sh

git revision
master / cb62f73406

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/4/artifact/out/diff-checkstyle-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/4/testReport/

Max. process+thread count
4357 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-580/4/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

@saintstack  @busbey  could you guys please make another pass ? Thank you !

overall this looks good to me. I've made a correction locally to make sure bin/hbase references the new CanaryTool class. I'm running a last set of tests locally then I'll merge.

Thank you @busbey  for the review and merge. Let me know if you want me to create PR for branch-1 or branch-2.

@shahrs87 I am waiting for this commit to go into branch-1.3 for the 1.3 release. Could you please take care of the backports to branch-1 & branch-2 as well?

Could you please take care of the backports to branch-1 & branch-2 as well?

I am relatively new to this project. I don't know the protocol of who handles the backport to branch-1 and branch-2. I was of the view that committer will take care of backports and if it needs more work than simple cherry-pick then he/she will let me know. In any case, I am fine to create a new PR for branch-1 and branch-2. Please let me know.

Also I see that @busbey  merged this commit to branch-2.1 and branch-2.2. So I think he is taking care of backports. :)


Jo/support 1d

First attempt for a 1D solver.

@JuliaOd You should add your name to AUTHORS.md

One feature I would like to have in 1D concerns visualization: Instead of using trixi2txt from utils/trixi2txt.jl to write a .txt file and read that again in Julia to plot something, could we just have a function returning the respective x and u arrays directly? Then, users can just create their own plots in Julia directly without having to deal with another set of files.

This sounds like a good idea. I'll open an issue for it.


chore(run-tests): run tests in circle ci

What Changed
Adds an extra step to run tests in circle ci
Why
Requested here https://github.com/intuit/accessibility-snippets/issues/47
Todo:

[ ] Add Semantic Version Label
[ ] Add tests
[ ] Add docs

@kendallgassner Please review when you got some time. I don't have access to add circle ci as part of the prs, but this should add the yarn test as part of the master circle ci at least.
Also, i noticed that the yarn test command was failing because the snippets did not have json format as it was merged here https://github.com/intuit/accessibility-snippets/pull/44 (maybe something got updated later and reverted the changes). Anyway, i renamed it back so now yarn test is passing

I renamed them back to the old file name. I wasn't sure why we changed the file type but the files are actually referenced in the package.json so we will need to update the name there as well

@kendallgassner I've updated the package.json file names and re-tested that yarn test works


Add ktlint to the project and auto format everything

Fixes https://github.com/home-assistant/home-assistant-android/issues/39

Hi @marciogranzotto,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

I closing this pull request and start an open discussion about quality
https://github.com/home-assistant/home-assistant-android/issues/47
Feel free to reopen it if we decide to go on ktlint


⚠ Samsung has degraded performance

In 94efabe, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2606 ms

Resolved: Samsung performance has improved in a904568.


Fixed #8721 - Velocity theme: "->" is not decoded to "->" when add…

Issue Reference
#8721
Description
using str_replace() to decode -> to  -> when storing home_page_content in velocity_meta_data
How To Test This?

Go to "/admin/velocity/meta-data"
Click on  "Home Page Content" field
Click on the source code and add the code below

@php
    $categories=app('Webkul\Category\Repositories\CategoryRepository')->getVisibleCategoryTree(core()->getCurrentChannel()->root_category_id);
@endphp

This will not throw an error anymore, the categories are fetched successfully
Documentation

[ ] My pull request requires an update on the documentation repository.

The only array key value support is given in the editor in the older version. these codes are not supported in the editor and also not planned in this version.

The only array key value support is given in the editor in the older version. these codes are not supported in the editor and also not planned in this version.

I think most developers would like for this to be supported.


VeloViewer refresh activities broken

Summary
Refreshing the activities on vv.fork.pl does not seem to work for my VeloViewer account
Steps to reproduce

Go to https://vv.fork.pl/index.php
Enter valid athlete ID with settings according to instructions
Click on "Refresh Explorer Stats"

Expected behavior
Great success and beautiful VeloViewer tiles available for B(ike)Router use.
Actual behavior
Error message: ERROR: can't find explorer url (activities)
Suspicion
I suspect the regular expression not matching the explorer URL in line 116 of refresh_vv.php. It expects a digit following the explorer String. However, looking at the network inspector, the URL I see for explorerSrc does not include trailing digits before the .js suffix:
explorerSrc= "https://s3.veloviewer.com/athletes2/7/5/621764/8549de2e1876afc00bde88109ec87824explorer.js";

Perhaps it would be more robust to grep for explorerSrc, but you could also make the dot and the digits following "explorer" optional.

Somehow I missed this report, sorry :( fortunately someone else pointed out the same problem.
It was just fixed https://github.com/marcin-gryszkalis/veloviewer-explorer-overlay/commit/a6227b2763563cfd975d2b1d0a360fe21fcfe0c4
Actually it was not about regexp but some internal logic of vv caused it not to publish so called "definite set" of visited squares. Nevertheless - I just added few if-s to skip it when it's not available and it seems to be working properly.


temporarily remove migrations docs; implement redirects

In #15033 I hid the links to some currently incorrect migrations docs, but did not remove the docs from the repo, and they were still accessible through search and other links.

Removed the docs from v21.2-v22.2
Implemented server-side redirects for those versions

The docs will be replaced and redirects will be removed once the instructions are updated.

This change is

Looks like there are some link removals/changes that need to happen here... I'll wait till you've done that and review! :)

Thanks @kathancox! Closing in favor of #15179.


Getting error in Angular 7 when importing SwiperModule

I'm using Angular 7 and today I downloaded the last version of Swiper. But when I import SwiperModule inside my app.modules, is throwing this errors:
ERROR in ../node_modules/swiper/angular/fesm2015/swiper_angular.js;
Module not found: Error: Can't resolve '@angular/common' in 'C:\Users\Beatriz\Projetos\Porto-Store\node_modules\swiper\angular\fesm2015';
ERROR in ../node_modules/swiper/angular/fesm2015/swiper_angular.js;
Module not found: Error: Can't resolve '@angular/core' in 'C:\Users\Beatriz\Projetos\Porto-Store\node_modules\swiper\angular\fesm2015';
ERROR in ../node_modules/swiper/angular/fesm2015/swiper_angular.js;
Module not found: Error: Can't resolve 'rxjs' in 'C:\Users\Beatriz\Projetos\Porto-Store\node_modules\swiper\angular\fesm2015';
I followed all the installation steps here https://swiperjs.com/angular
=/

Please, don't ignore issue template, it is there for a reason


fix: update packages & replace request dependency

Updated dependencies
Removed the usage of request in next-edge
Added support for Next.js App Router
Overall refactor: separate common functions and consts

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@t1nky Ah, just saw, could you sign the CLA? Otherwise, we can't merge this PR.

@t1nky Ah, just saw, could you sign the CLA? Otherwise, we can't merge this PR.

Done, apologize for the delay


Scaling up PM simulations on Perlmutter for Cosmological Forward Modeling

Scaling up differentiable PM simulations on Perlmutter for Cosmological Forward Modeling
Improving the framework for running differentiable lensing and clustering simulations to scale to larger volumes (i.e. multi-gpu parallelisation; pretty technical), and adding currently missing components (IA models, pz models, galaxy bias models, etc.; new contributor friendly!)
Contacts: @EiffL
Day/Time: All week
Main communication channel: #desc-sprint-bayescosmo
GitHub repo: https://github.com/LSSTDESC/bayesian-pipelines-cosmology
Zoom room (if applicable): DESC #19
Goals and deliverable

[ ] : Implement multi-GPU distribution of JaxPM nbody model (single node)
[ ] : [stretch goal] implement multi-GPU distribution over multiple nodes!
[ ] : Merge missing modeling components (IA, pz, bias) into main branch
[ ] : Implement validation tests for the simulated fields

Resources and skills needed
This sprint has two different skills requirements:

For the multi-GPU parallelisation stuff (!!! very technical !!!): Enthusiasm for parallel computing :-) Ideally previous experience with distributed ML / underlying NCCL tensorflow/jax primitives for distributed collectives / experience with JAX pmap or xmap.

For the model extension stuff (adding missing components like IA): Just enthusiasm! Ideally some pre-existing knowledge about the particular effect to be implemented, but also a good opportunity to learn!

Detailed description
(coming soon)

Big progress yesterday! 2048^3 FFT successfully distributed on 8 GPUs across two nodes with NCCL
The report is here:
https://github.com/DifferentiableUniverseInitiative/JaxPM/issues/8#issuecomment-1281826189


Add fields to HandshakeRequest & ConnectionData

Add MigratableStatus field to HandshakeRequestMessage to indicate if the client connection mapped to the designated server connection can be migrated to another server connection.
Add SequenceId field to ConnectionDataMessage to help the server-side SDK to guarantee the message order (cause it could be sent from different signalr-runtime)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: terencefan sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

We shouldn't be updating the types without also updating the spec. We need to treat the protocol itself like part of the product. Changes need to be documented and backwards compatible (since there's no versioning scheme).


#242/fo card with image

Thanks for your support to the project. Please check below mentioned points -
Detailed description of changes
...
Recommendations on how to test the changes
...
Checklist for developer

[x] The code builds clean without any errors or warnings
[x] The code does not contain commented out code
[x] The code does not log anything to console
[x] I have added unit test(s) to cover new code and successfully executed ran it
[x] I have thoroughly tested the new code and any adjacent features it may affect

Link to related issue(s)
...
Screenshots or videos (before and after if appropriate)
Before
...
After

...

Hi Bayu please help with the Description ya
Thanks


requirements.txt

Could we please adopt the approach that flask uses to manage py3 support: https://github.com/mitsuhiko/flask/blob/master/.travis.yml ?

Closing in favour of #377.


feat request: Patch colorized git-diff style output

Would it be possible to represent the diffs similar to the way git diffs work?

@blacktop This library generates a JSON Patch (RFC6902), which is a list of operations representing the differences between two JSON documents.
What you're asking for is outside the feature scope of this package.
You're probably looking for something like this, which doed what you described: https://github.com/andreyvit/json-diff

@blacktop This library generates a JSON Patch (RFC6902), which is a list of operations representing the differences between two JSON documents.
What you're asking for is outside the feature scope of this package.
You're probably looking for something like this, which doed what you described: https://github.com/andreyvit/json-diff

Thank you for those links! ❤


Welcome Dialogue Box Submits on Pressing Enter Key

Fixes #271
Now a user can press enter after typing in his/her name, and it will automatically set the name, and close the dialogue box, just like on clicking the Enter button.
(Screenshot not possible as it's not possible to show enter key being pressed)

YES


mysensors serial gateway Invalid config after update to HA0.37.1

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
0.37.1
Python release (python3 --version):
Python 3.5.2rc1
Component/platform:
Windows 7
Description of problem:
after updating to .37.1 I now get an error message when I load home assistant "Invalid config
The following components and platforms could not be set up: mysensors
Please check your config "
however I have checked my config and nothing has changed from when it was working before the update. I have also tried to copy the example config again and no resolving it.
Problem-relevant configuration.yaml entries and steps to reproduce:
mysensors:
  gateways:
    - device: 'COM10'
      persistence_file: 'C:\Users\Media-Admin\AppData\Roaming\.homeassistant'
      baud_rate: 115200
  debug: true
  optimistic: false
  persistence: true
  retain: true
  version: 2.0

This could be a duplicate of #5661. Please check the error lines in your log, and post it here. It should say more than what you've reported so far. Your persistence file path also is not correct in your posted config.

@MartinHjelmare  yes same issue, not sure how i missed it when i was searching for the problem. In any event I also had the persistence file path correct prior was monkeying around trying to fix the issue and had changed that before copying to here oops. i corrected it now in my .yaml back to the old one.
here is what the log reports:
ERROR (MainThread) [homeassistant.bootstrap] Invalid config for [mysensors]: No device at /dev/ttyUSB4 found for dictionary value @ data['mysensors']['gateways'][0]['device']. Got '/dev/ttyUSB4'. (See C:\Users\Media-Admin\AppData\Roaming.homeassistant\configuration.yaml, line 40). Please check the docs at https://home-assistant.io/components/mysensors/

correction I am having a really bad day with copy and past!!
Here is what my log reads ugh: ERROR (MainThread) [homeassistant.bootstrap] Invalid config for [mysensors]: No device at COM4 found for dictionary value @ data['mysensors']['gateways'][0]['device']. Got 'COM4'. (See C:\Users\Media-Admin\AppData\Roaming.homeassistant\configuration.yaml, line 40). Please check the docs at https://home-assistant.io/components/mysensors/

Thanks for reporting back. I'm going to close this and will update #5661 when I have a fix.


Incorrect line wrapping in locals window

Line selection wraps up to expanded parent instead of first line.
https://github.com/user-attachments/assets/ec4168ff-fbbb-4e80-bc73-483387c9b81e

This should be fixed on dev, let me know if you see it again after 0.9.12 is out.


Refactor: Removing all unused files and codes for example

Description
As we are using storybook, it's time to clean up all dead codes related to example
This PR removed all the files and codes that used for example and also clear the build process process for example.
Screenshots (if appropriate):
N/A
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have used ESLint & Prettier to follow the code style of this project.
[x] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

This pull request fixes 1 alert when merging e01840992dc5c3bc531dcc0538ede98c8a8cf0e9 into b01621f2b5715a171d7ae1f7a4e8156758e666ba - view on LGTM.com
fixed alerts:

1 for Incomplete URL substring sanitization

Comment posted by LGTM.com

Coverage remained the same at 93.401% when pulling e01840992dc5c3bc531dcc0538ede98c8a8cf0e9 on fix/example-cleanup into b01621f2b5715a171d7ae1f7a4e8156758e666ba on master.

This pull request fixes 1 alert when merging 855479118a8ee7d4f4ac76d548ebd5e537306660 into b01621f2b5715a171d7ae1f7a4e8156758e666ba - view on LGTM.com
fixed alerts:

1 for Incomplete URL substring sanitization

Comment posted by LGTM.com


Two Stuck Transactions (since 05/26/2024)

Hi,
i have two transaction which seem to be still in the processing state since the 05/26/2024:

uid: 0x1dcae8bd2209fc8c7603bd6ca7d4e42022c262bd
uid: 0xd8fd096d93d8efe3a7401f619ddc65eeb5591f7f
This is related to the discord bugissue-587.
Can you please support in fixing this problem?

Here are also the two Soonaverse links to the NFTs (however, they no longer work).
https://soonaverse.com/nft/0x40e0cfe6e5459d8029fcb37ad0a47e1827289bdd
https://soonaverse.com/nft/0x26ea504017917caf85b39e49a5ce9a6c61d8dbe5

@Eyerkaufer It sounds like your query would be best dealt with by the support team.
Please see the link below to our dedicated support line:
Support :Help Center
Note: Click on the live chat icon at the bottom corner of the page to start a conversation

related to https://github.com/soonaverse/app/issues/182