Memory leaks in bamboo components.

After my experience with https://github.com/phetsims/bamboo/issues/64, I decided to review bamboo components for other memory leaks.  Here's what I found:

[ ] BarPlot: creates a set of Rectangle instances that make be linked to global ProfileColorProperty.
[ ] SpanNode: creates an ArrowNode instance that may be linked to a global ProfileColorProperty.
[ ] UpDownArrowPlot: creates a set of ArrowNode instances that may be linked to global ProfileColorProperty.

These leaks need to be addressed in the update and dispose methods of each component.
These components are not an issue for https://github.com/phetsims/fourier-making-waves/issues/123.  FMW does not use SpanNode and UpDownArrowPlot.  And while it uses BarPlot, a single instance is reused, and the number of bars is constant.
@samreid FYI.

I set up this test harness to investigate a leak in BarPlot.pointToPaintableFields, but it does not seem to leak at all.

Subject: [PATCH] Use PhetioIDUtilsModule, see https://github.com/phetsims/tandem/issues/316
---
Index: js/demo/DemoBarPlot.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/demo/DemoBarPlot.ts b/js/demo/DemoBarPlot.ts
--- a/js/demo/DemoBarPlot.ts	(revision c5be5907ba3f3898d478bcaa15881884b9af346a)
+++ b/js/demo/DemoBarPlot.ts	(date<PHONE_NUMBER>876)
@@ -12,7 +12,7 @@
 import Vector2 from '../../../dot/js/Vector2.js';
 import Orientation from '../../../phet-core/js/Orientation.js';
 import MathSymbols from '../../../scenery-phet/js/MathSymbols.js';
-import { Color, Node, NodeOptions, Text, VBox } from '../../../scenery/js/imports.js';
+import { Color, ColorProperty, Node, NodeOptions, Text, VBox } from '../../../scenery/js/imports.js';
 import TextPushButton from '../../../sun/js/buttons/TextPushButton.js';
 import bamboo from '../bamboo.js';
 import BarPlot from '../BarPlot.js';
@@ -62,6 +62,17 @@
       }
     } );

+    const myColorProperty = new ColorProperty( Color.blue );
+    setInterval( () => {
+      const m = new BarPlot( chartTransform, createDataSet( 2, 0.1 ), {
+        pointToPaintableFields: ( point: Vector2 ) => {
+          return { fill: myColorProperty };
+        }
+      } );
+      console.log( 'hello' );
+      m.dispose();
+    }, 100 );
+
     const chartClip = new Node( {
       clipArea: chartRectangle.getShape(),
       children: [
Index: js/demo/BambooDemoScreenView.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/demo/BambooDemoScreenView.ts b/js/demo/BambooDemoScreenView.ts
--- a/js/demo/BambooDemoScreenView.ts	(revision c5be5907ba3f3898d478bcaa15881884b9af346a)
+++ b/js/demo/BambooDemoScreenView.ts	(date<PHONE_NUMBER>066)
@@ -34,37 +34,37 @@
      * {(layoutBounds: Bounds2) => Node} createNode - creates the scene graph for the demo
      */
     const demos: DemoItemData[] = [
-      {
-        label: 'AreaPlot',
-        createNode: layoutBounds => new DemoAreaPlot( { center: layoutBounds.center } )
-      },
+      // {
+      //   label: 'AreaPlot',
+      //   createNode: layoutBounds => new DemoAreaPlot( { center: layoutBounds.center } )
+      // },
       {
         label: 'BarPlot',
         createNode: layoutBounds => new DemoBarPlot( { center: layoutBounds.center } )
       },
-      {
-        label: 'ChartCanvasNode',
-        createNode: layoutBounds => new DemoChartCanvasNode( emitter, { center: layoutBounds.center } )
-      },
-      {
-        label: 'LinearEquationPlot',
-        createNode: layoutBounds => new DemoLinearEquationPlot( { center: layoutBounds.center } )
-      },
-      {
-        label: 'LinePlot',
-        createNode: layoutBounds => new DemoLinePlot( { center: layoutBounds.center } )
-      },
-      {
-        label: 'MultiplePlots', createNode: layoutBounds => new DemoMultiplePlots( { center: layoutBounds.center } )
-      },
-      {
-        label: 'ScatterPlot',
-        createNode: layoutBounds => new DemoScatterPlot( { center: layoutBounds.center } )
-      },
-      {
-        label: 'UpDownArrowPlot',
-        createNode: layoutBounds => new DemoUpDownArrowPlot( { center: layoutBounds.center } )
-      }
+      // {
+      //   label: 'ChartCanvasNode',
+      //   createNode: layoutBounds => new DemoChartCanvasNode( emitter, { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'LinearEquationPlot',
+      //   createNode: layoutBounds => new DemoLinearEquationPlot( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'LinePlot',
+      //   createNode: layoutBounds => new DemoLinePlot( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'MultiplePlots', createNode: layoutBounds => new DemoMultiplePlots( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'ScatterPlot',
+      //   createNode: layoutBounds => new DemoScatterPlot( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'UpDownArrowPlot',
+      //   createNode: layoutBounds => new DemoUpDownArrowPlot( { center: layoutBounds.center } )
+      // }
     ];

     super( demos, {

Perhaps a Rectangle that is cut off from the GC roots also does not retain a reference for fill or stroke Properties? @pixelzoom what do you think?

Perhaps a Rectangle that is cut off from the GC roots also does not retain a reference for fill or stroke Properties?

I'd be very surprised if that were the case. TickLabelSet was leaking due to Line, and I doubt that scenery would be handling disposable of Line and Rectangle differently.  That said...
My bad, BarPlot is not leaking, because it does not pass anything observable to Rectangle:
      const rectangle = new Rectangle( 0, 0, 0, 0 );

SpanNode can leak via arrowNodeOptions passed to ArrowNode:
      const arrowNode = new ArrowNode(
        leftBar.right,
        leftBar.centerY,
        rightBar.left,
        rightBar.centerY,
        this.arrowNodeOptions
      );

UpDownArrowPlot can also leak via arrowNodeOptions passed to ArrowNode:
      const arrowNode = new ArrowNode( 0, 0, 0, 0, this.arrowNodeOptions );

Here's a propose (untested) patch for SpanNode and UpDownArrowNode.  Please review, feel free to apply and commit if it looks correct.

patch
Subject: [PATCH] visibleProperty phetioReadOnly: true, https://github.com/phetsims/natural-selection/issues/366
---
Index: js/UpDownArrowPlot.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/UpDownArrowPlot.ts b/js/UpDownArrowPlot.ts
--- a/js/UpDownArrowPlot.ts	(revision c5be5907ba3f3898d478bcaa15881884b9af346a)
+++ b/js/UpDownArrowPlot.ts	(date<PHONE_NUMBER>841)
@@ -67,7 +67,10 @@
     const changedListener = () => this.update();
     chartTransform.changedEmitter.addListener( changedListener );

-    this.disposeUpDownArrowPLot = () => chartTransform.changedEmitter.removeListener( changedListener );
+    this.disposeUpDownArrowPLot = () => {
+      chartTransform.changedEmitter.removeListener( changedListener );
+      this.arrowNodes.forEach( node => node.dispose );
+    };
   }

   // Sets the dataSet and redraws the plot.
@@ -92,6 +95,7 @@
     // if any data points were removed, remove any extra ArrowNodes
     while ( this.arrowNodes.length > this.dataSet.length ) {
       const arrowNode = this.arrowNodes.pop()!;
+      arrowNode.dispose();
       this.removeChild( arrowNode );
     }

Index: js/SpanNode.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/SpanNode.ts b/js/SpanNode.ts
--- a/js/SpanNode.ts	(revision c5be5907ba3f3898d478bcaa15881884b9af346a)
+++ b/js/SpanNode.ts	(date<PHONE_NUMBER>835)
@@ -43,6 +43,7 @@
   private readonly color: string | Color;
   private readonly outerLineLength: number;
   private viewWidth: number;
+  private arrowNode?: ArrowNode;
   private readonly arrowNodeOptions: ArrowNodeOptions;
   private readonly disposeSpanNode: () => void;

@@ -92,7 +93,10 @@
     const changedListener = () => this.update();
     chartTransform.changedEmitter.addListener( changedListener );

-    this.disposeSpanNode = () => chartTransform.changedEmitter.removeListener( changedListener );
+    this.disposeSpanNode = () => {
+      chartTransform.changedEmitter.removeListener( changedListener );
+      this.arrowNode && this.arrowNode.dispose();
+    };
   }

   /**
@@ -116,11 +120,13 @@

       //TODO https://github.com/phetsims/bamboo/issues/21 support Orientation.VERTICAL

+      this.arrowNode && this.arrowNode.dispose();
+
       // Create double-headed arrow with perpendicular lines at ends to show modelDelta
       const createBar = ( centerX: number ) => new Line( 0, 0, 0, this.outerLineLength, { stroke: this.color, centerX: centerX } );
       const leftBar = createBar( 0 );
       const rightBar = createBar( viewWidth );
-      const arrowNode = new ArrowNode(
+      this.arrowNode = new ArrowNode(
         leftBar.right,
         leftBar.centerY,
         rightBar.left,
@@ -128,7 +134,7 @@
         this.arrowNodeOptions
       );
       const arrowWithBars = new Node( {
-        children: [ leftBar, rightBar, arrowNode ]
+        children: [ leftBar, rightBar, this.arrowNode ]
       } );

       //TODO https://github.com/phetsims/bamboo/issues/21 support Orientation.VERTICAL

This line does not look correct:

 this.arrowNodes.forEach( node => node.dispose );

Furthermore, creating a harness to try to intentionally trigger a leak SpanNode does not cause a leak in main (without the patch above):

Subject: [PATCH] Use PhetioIDUtilsModule, see https://github.com/phetsims/tandem/issues/316
---
Index: js/demo/DemoBarPlot.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/demo/DemoBarPlot.ts b/js/demo/DemoBarPlot.ts
--- a/js/demo/DemoBarPlot.ts	(revision c5be5907ba3f3898d478bcaa15881884b9af346a)
+++ b/js/demo/DemoBarPlot.ts	(date<PHONE_NUMBER>283)
@@ -12,13 +12,14 @@
 import Vector2 from '../../../dot/js/Vector2.js';
 import Orientation from '../../../phet-core/js/Orientation.js';
 import MathSymbols from '../../../scenery-phet/js/MathSymbols.js';
-import { Color, Node, NodeOptions, Text, VBox } from '../../../scenery/js/imports.js';
+import { Color, ColorProperty, Node, NodeOptions, Text, VBox } from '../../../scenery/js/imports.js';
 import TextPushButton from '../../../sun/js/buttons/TextPushButton.js';
 import bamboo from '../bamboo.js';
 import BarPlot from '../BarPlot.js';
 import ChartRectangle from '../ChartRectangle.js';
 import ChartTransform from '../ChartTransform.js';
 import GridLineSet from '../GridLineSet.js';
+import SpanNode from '../SpanNode.js';
 import TickLabelSet from '../TickLabelSet.js';
 import TickMarkSet from '../TickMarkSet.js';

@@ -62,6 +63,17 @@
       }
     } );

+    const myColorProperty = new ColorProperty( Color.blue );
+    setInterval( () => {
+      const s = new SpanNode( chartTransform, Orientation.HORIZONTAL, Math.PI * 12, new Text( 'hello' ), {
+        arrowNodeOptions: {
+          fill: myColorProperty // Intentional attempt to leak by attaching to the color Property above
+        }
+      } );
+      console.log( 'hello' );
+      s.dispose();
+    }, 100 );
+
     const chartClip = new Node( {
       clipArea: chartRectangle.getShape(),
       children: [
Index: js/demo/BambooDemoScreenView.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/demo/BambooDemoScreenView.ts b/js/demo/BambooDemoScreenView.ts
--- a/js/demo/BambooDemoScreenView.ts	(revision c5be5907ba3f3898d478bcaa15881884b9af346a)
+++ b/js/demo/BambooDemoScreenView.ts	(date<PHONE_NUMBER>568)
@@ -34,37 +34,37 @@
      * {(layoutBounds: Bounds2) => Node} createNode - creates the scene graph for the demo
      */
     const demos: DemoItemData[] = [
-      {
-        label: 'AreaPlot',
-        createNode: layoutBounds => new DemoAreaPlot( { center: layoutBounds.center } )
-      },
+      // {
+      //   label: 'AreaPlot',
+      //   createNode: layoutBounds => new DemoAreaPlot( { center: layoutBounds.center } )
+      // },
       {
         label: 'BarPlot',
         createNode: layoutBounds => new DemoBarPlot( { center: layoutBounds.center } )
       },
-      {
-        label: 'ChartCanvasNode',
-        createNode: layoutBounds => new DemoChartCanvasNode( emitter, { center: layoutBounds.center } )
-      },
-      {
-        label: 'LinearEquationPlot',
-        createNode: layoutBounds => new DemoLinearEquationPlot( { center: layoutBounds.center } )
-      },
-      {
-        label: 'LinePlot',
-        createNode: layoutBounds => new DemoLinePlot( { center: layoutBounds.center } )
-      },
-      {
-        label: 'MultiplePlots', createNode: layoutBounds => new DemoMultiplePlots( { center: layoutBounds.center } )
-      },
-      {
-        label: 'ScatterPlot',
-        createNode: layoutBounds => new DemoScatterPlot( { center: layoutBounds.center } )
-      },
-      {
-        label: 'UpDownArrowPlot',
-        createNode: layoutBounds => new DemoUpDownArrowPlot( { center: layoutBounds.center } )
-      }
+      // {
+      //   label: 'ChartCanvasNode',
+      //   createNode: layoutBounds => new DemoChartCanvasNode( emitter, { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'LinearEquationPlot',
+      //   createNode: layoutBounds => new DemoLinearEquationPlot( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'LinePlot',
+      //   createNode: layoutBounds => new DemoLinePlot( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'MultiplePlots', createNode: layoutBounds => new DemoMultiplePlots( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'ScatterPlot',
+      //   createNode: layoutBounds => new DemoScatterPlot( { center: layoutBounds.center } )
+      // },
+      // {
+      //   label: 'UpDownArrowPlot',
+      //   createNode: layoutBounds => new DemoUpDownArrowPlot( { center: layoutBounds.center } )
+      // }
     ];

     super( demos, {

Please advise.

Why does this.arrowNodes.forEach( node => node.dispose ); not look correct?
Why do you think that ArrowNode will not leak if it's not disposed?
Let's chat on Zoom instead of assigning this back and forth.

Why does this.arrowNodes.forEach( node => node.dispose ); not look correct?

It is not calling the dispose() function (missing parens).

Why do you think that ArrowNode will not leak if it's linked to a global Property and not disposed?

I demonstrated it empirically by running the memory profiler with my patch and observing that there was no memory leak.

Let's chat on Zoom instead of assigning this back and forth.

I'm on zoom at the moment, or please reach out to me on slack to schedule a time.

@pixelzoom and I met and reproduced the example above. We were both surprised that there is no leak in the patch. We would like to ask @jonathanolson how this is happening, and whether the same can be done for StringProperty instances.

@samreid and I discussed.  We suspect that scenery is automatically cleaning up links to color Properties (for fill, stroke,...) but is not cleaning up links to string Properties (Text, RichText).  @samreid will confirm with @jonathanolson.  If that's the case, then this issue can be closed.  And it would be nice to discuss making scenery automatically cleanup string Property links (Text, RichText) since they have been a continual cost and problem while converting sims to dynamic locale.

How can I reproduce the leak? I'd be interested to try it out and debug.

@jonathanolson @samreid and I discussed.  Scenery does not create links to color Properties (fill, stroke, ...) so the "leaks" that I identified herein are a non-issue, and this can be closed without further work.  @samreid thanks for demonstrating the lack of leakage and getting us to the bottom of this.
Automatically cleanup string Property links (Text, RichText) is not possible. We can't simply dispose a Text/RichText when it's removed from the scene graph because we may intended to add it again later.


Release Google.Cloud.Deploy.V1 version 3.4.0

Changes in this release:
New features

A new field dns_endpoint is added to message .google.cloud.deploy.v1.GkeCluster (commit c6f4346)

Documentation improvements

A comment for field internal_ip in message .google.cloud.deploy.v1.GkeCluster is changed (commit c6f4346)
A comment for field skaffold_version in message .google.cloud.deploy.v1.Release is changed (commit c6f4346)
A comment for field requested_cancellation in message .google.cloud.deploy.v1.OperationMetadata is changed (commit c6f4346)
Documentation improvements. skaffold_version field is no longer explicitly marked as optional (commit 5671fb8)
Minor documentation updates (commit efd4894)

Created release for Google.Cloud.Deploy.V1-3.4.0


Repository update to include release for Debian 10 (Buster)

Debian 10 (Buster) was officially released on July 6th (https://www.debian.org/News/2019/20190706), and it is the current stable release for the distribution. There isn't a compatible repository at https://packages.microsoft.com/repos/azure-cli/dists/ yet.

I'm moving to a new team after this week, but we should definitely start publishing for buster.

Any forecast about when support for buster would be introduced?

I switched to a manual installation and use bionic - works well (Debian Testing user)

The Microsoft Docs say that Buster is not supported and having to rely on the Troubleshooting section to install Azure CLI on (as far as I understand your post) any upcoming release of Debian and Ubuntu is just bad.
Yes, we need Buster support.
And concerning the Raspberry Pi: It doesn't seem that arm-linux is supported.

If you are running a distribution that comes with apt, such as Ubuntu or Debian, there's an x86_64 package available for the Azure CLI.

We are working on Buster support currently. @zikalino will update this issue once it is released.

@zikalino is working on this issue and will give update by next week.

Just ran into this, so looking forward to the release. Thanks @zikalino !

I'm also eagerly awaiting this! =D

I'm using the binaries for Debian Stretch on Debian Buster and ... "it works".
However, I don't remember if I had troubles when I've first installed it.


⚠ ClamAV has degraded performance

In 638fa0b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 66 ms

Resolved: ClamAV performance has improved in 473cce5.


design-doc: interoperable ether

Description
Adds a design doc for what interoperable ether. This is a core feature for interop devnet v2.
The ISuperchainERC20 spec can be found here

This should include the following options:

new predeploy
keep existing predeploy (do nothing)

It should also cover how custom gas token impacts things

I'm going to be taking over this spec/design work from @tynes. Dropping my own version of the initial design doc here as a comment before I likely turn this into its own PR following the design review meeting today.
Context and Key Problems
ETH is the native asset of Ethereum and has by extension also become the native asset of many Ethereum L2 blockchains. In its role as a native asset, ETH can be used to pay for transaction fees and can be transferred from account to account via calls with attached value. ETH plays a significant role in the economics of most L2s and any protocol that enables interoperability between chains must be able to account for ETH.
We want to handle native assets other than ETH
Not all chains using the OP Stack use ETH as the native asset. We would like these chains to be able to interoperate with chains that do use ETH as a native asset. Certain solutions that might work when all chains use ETH as a native asset begin to break down when alternative native assets are introduced. For example, a protocol that burns the native asset on one chain and mints it on another will work if both chains use the same native asset but will obviously fail if either chain uses a different native asset.
We want to minimize protocol complexity
Support for native ETH opens the door to unnecessary complexity. Any solution to this problem should aim to minimize the amount of protocol code required to support native ETH. This generally points towards an app-layer solution if possible but does not preclude a protocol-layer solution as long as we minimize implementation size.
We want to maximize functionality
Any solution should strive to maximize the functionality of the underlying message-passing protocol. Support for native ETH should not unnecessarily restrict the interop protocol.
We want to streamline the user experience
An ideal solution would make it possible to streamline the user experience such that ETH transfers between chains look just like ETH transfers between addresses on the same chain. Much of the user experience can be solved at the wallet level but it’s also important that the underlying protocol doesn’t require an unnecessary number of transactions to
Proposed Solution
We propose solving for interoperable ETH by introducing a predeployed WETH contract that supports the ISuperchainERC20 interface. This contract, referred to as “Superchain WETH” for the remainder of this document, would be redeemable for the native asset on chains that use ETH as a native asset but would only be usable in its wrapped ERC-20 form on chains that use any other native asset.
Considerations
Dealing with existing the WETH predeploy
We have an existing WETH predeploy that is already used by a number of contracts on OP Mainnet and other OP Stack chains. Adding a new WETH predeploy would potentially fragment ETH liquidity in certain app-level protocols. We should carefully explore the impact of this fragmentation and determine if this impact justifies a fork that upgrades the existing WETH contract rather than introducing a new predeploy.
It is important to note that the existing WETH contract represents “wrapped native asset” and not “wrapped ETH” and any solution must account for this discrepancy. We want Superchain WETH to universally represent “wrapped ETH” on every chain. An ideal solution here would not create a massive diff between ETH and non-ETH chains.
Supplying ETH liquidity
Superchain WETH introduces the need to supply some sort of ETH liquidity that makes it possible to actually withdraw WETH into ETH. We can easily credit a WETH balance on a receiving chain but the receiving WETH contract will not actually have the ETH balance to facilitate the transfer into native ETH. We propose solving this issue by giving the Superchain WETH contract access to a very large (uint248 max) balance of ETH on each chain. Other projects (notably Scroll) have taken a similar strategy to handling ETH bridging as an alternative to minting ETH natively.
Allowing WETH to access a large ETH balance should not introduce any security concerns. WETH balances that allow ETH withdrawals would still be governed by the standard WETH logic. We must make sure to maintain the key invariant that the total amount of withdrawable WETH is exactly equal to the amount of deposited WETH.
We can implement this logic by either (1) crediting the WETH contract directly with a large ETH balance or (2) crediting some other contract (the ”Superchain Liqudiity” contract) with a large ETH balance and exclusively allowing WETH to tap into this contract. Crediting WETH directly is a simpler design but has the unintended side-effect of also creating an artificially large total WETH supply on paper because the standard WETH9 contract reads the total supply from address(this).balance. We need to consider whether we should modify WETH9 to compute the total supply from deposits and withdrawals or if we should introduce a separate Superchain Liquidity contract to sidestep this total supply issue.
Handling chains that use native assets other than ETH
As previously noted, we want Superchain WETH to represent “wrapped ETH” on all chains regardless of the native asset. This means that Superchain WETH must be able to distinguish between chains that use ETH as a native asset and chains that do not. Superchain WETH on ETH-native chains should be redeemable for the native asset while Superchain WETH on all other chains must remain in the ERC-20 form.
Streamlining user experience
An ideal user experience would mean that sending ETH from one chain to another feels just like sending ETH between two accounts on the same chain. We can mostly solve this at the wallet level but we should aim to keep the transfer process to a single transaction.
We can get pretty far by providing two ways to interact with Superchain WETH:

Call a function sendETH that wraps the msg.value, transfers the WETH balance to the Superchain WETH contract on the receiving chain, and unwraps ETH to the recipient address if the receiving chain uses ETH as a native asset. ETH would remain in WETH form if the receiving chain uses a different native asset.
Call a function sendERC20 that wraps the msg.value, transfers the WETH balance to the Superchain WETH contract on the receiving chain, and keeps the balance in WETH regardless of the native asset used by the receiving chain.

As usual, we could reduce this into a single function with toggles if desired:
function sendWETHTo(
    address recipient,
    uint256 amount,
    uint256 chainId,
    bool unwrap
)
    public
    payable
{
    // If amount is zero, send using WETH balance.
    // If amount is nonzero, send using msg.value.
    // Send message to recipient chain.
}

function relayWETHTo(
    address recipient,
    uint256 amount,
    bool unwrap
)
    public
{
    // Check that this is from the cross domain messenger.
    // Increase the recipient's balance.
    // If unwrap and this is a native ETH chain then perform unwrap.
}

The weth supply is not accurate because you can use selfdestruct to transfer ether to the contract without any execution (where it would usually mint weth). This would increase the totalSupply of weth without minting any erc20 tokens.
I still lean towards keeping the liquidity in its own contract to keep a clear boundary around the superchain ending bug of that ether being able to be removed somehow. The control flow of accessing this locked ether should be defined super clearly and it unlocks future modifications to the superchain weth predeploy in the future

This should be a proxied contract and only upgradable by the system transactions

Can we make this solution more generic? So it doesn't enshrine ether as deeply in the design

Should we use the mirror approach for this to solve the liquidity issue?

After chatting with @smartcontracts about our constraints and optimization targets, we decided that we shouldn't focus on making the solution more generic or use the mirror approach. Right now there is extremely low usage of custom gas token chains, so it would be a premature optimization to make it more generic right now. We can solve the usecase for the chains that contribute the most revenue to the collective now (all ether as gas) then think about a more generic solution in the future

After chatting with @smartcontracts about our constraints and optimization targets, we decided that we shouldn't focus on making the solution more generic or use the mirror approach. Right now there is extremely low usage of custom gas token chains, so it would be a premature optimization to make it more generic right now. We can solve the usecase for the chains that contribute the most revenue to the collective now (all ether as gas) then think about a more generic solution in the future

What are the tradeoffs of not using the mirror contract and using a new custom pre-deploy to handle the WETH case ?

What are the tradeoffs of not using the mirror contract and using a new custom pre-deploy to handle the WETH case ?

I think the main reason not to use the mirror contract is because the chain contracts end up looking different if you're on a custom gas chain or not. I don't really love the idea of having some chains have a mirror contract while other chains just have this new Superchain WETH contract.
Mirroring would also require upgrading the existing WETH contract which requires a hardfork. Would be very annoying. Current approach works well enough, doesn't need a hardfork, and doesn't end up with different contracts on different chain types.

Approving but would like to see @skeletor-spaceman's response to the above before merging.

Mirroring would also require upgrading the existing WETH contract which requires a hardfork

yeah, this is a big counter-point to the Mirror approach. Since the standard bridge just sends raw msg.value, and WETH is not used as a _isOptimismMintableERC20(...). where the internal mint on WETH, would pull from the "infinite" ETH pre-mine
with this in mind, and going back to one of the key-points above:

We should carefully explore the impact of this fragmentation and determine if this impact justifies a fork that upgrades the existing WETH contract rather than introducing a new predeploy.

I'm still a bit hesitant on why we would need to create a new "custom" pre-deploy that would behave almost exactly as any other superc20, for which we could leverage all the superc20 tooling and periphery for a better more comprehensive UX/DX. I'd love to avoid "contract/flow" fragmentation when sending tokens, native or not.
mirror is out of the question, we agree there. liquidity fragmentation is inevitable without a complex hard-fork that would modify the WETH pre-deploy for it to be able to handle ETH + custom gas tokens under the same address. (even if possible, is a mess)
but, why do we need superWETH to be a pre-deploy?

Got it, if the question is predeploy vs not, I have no strong opinions there. cc @tynes for input.

but, why do we need superWETH to be a pre-deploy?

The superchain erc20 spec includes the fact that the address is the same on all chains so making superchain weth be the same address on all chains as a predeploy is the most simple option. Since we want this on all op stack chains, the two options are predeploy or preinstall, I definitely lean towards predeploy since the existing weth aka wrapped native asset is a predeploy

for which we could leverage all the superc20 tooling and periphery for a better more comprehensive UX/DX.

The ABI on superchain weth will implement super erc20, so the tooling will still work. super erc20 is an interface, not all super erc20 tokens must be mirrors, superchain weth is an instance of a super erc20 that is meant to be weth on all chains, custom gas token or not

We need to be careful of pulling in too many features, ie making superchain weth support IOptimismMintableERC20 and allowing L1 weth to populate it. That seems like a nice to have feature in the future, we don't necessarily need that now

@tynes agreed, my understanding was that if possible we'd want to keep the number of pre-deploys at a minimum.
But if it's easier to just make this a pre-deploy, I'm onboard.


Implement best practices in Docker image

Description
This PR implements best practices in the Docker image.
In summary, the changes do the following:

Changes the python image from alpine to slim bullseye as the cryptography related packages come pre-installed so there is no need to install them manually.
Pins the version of poetry to prevent unexpected breakages in future.
Removes the command for disabling virtualenv due to issues identified in DG API - more here
Combines the RUN commands so that there are less layers.
Build cache is leveraged in the build stage to reduce the build time when changes are made to the source code over and over again. This is accomplished by copying the poetry.lock and pyproject.toml files and installing the dependencies first, and then copying the source code and building the app. Because each COPY and RUN command is a new layer, this ensures that the layers for copying and installing the dependencies are cached when changes are made to the source code.

I tried to to find another way of including the RSA keys into the container because generating them inside the image is deemed unsecure as they can be seen if the image is inspected. I have added an entry for this in the technical debt table as it looks like this may be involved or they might be a better way for dealing with this in k8s. I also tried to set the image to run as non-root but could not get it to work. The volumes are mounted as root so running the container as non-root results in permission issues when the application tries to read the config file, RSA keys, and maintenance files.
Testing Instructions

[ ] Review code
[ ] Check GitHub Actions build
[ ] Review changes to test coverage
[ ] Image builds successfully
[ ] Container starts successfully

adding do-not-merge:blocked label to stop reminders of this PR pinging slack


use Back-end to secure apiKey

Describe the problem
Actually, there is no way to use restriction API Key.
My first idea to limit problem is get API Key by fetch at the app launch.
But a user man in the middle can get request and decode api key...
So I have a question.
My idea is to use my back-end to request google maps autocomplete.
Instead of request to googlemaps.api..., request to my back-end.
On my back, I check user is logged, and I do the request, and I return response to user autenticated.
The problem is, my request is twice : RN => backend => googlemaps api
Additional context

Library Version: [2.1.3]

React Native Version: [0.63.2]

[X ] iOS

[X ] Android

[ ] Web

If you are using expo please indicate here:

[X ] I am using expo

If you use this library, you can either proxy your requests or not use a restricted key.
I suggest you look for a library that uses the native Google Maps SDKs. The only one that I know of is react-native-google-places.

Thanks for your reply.
I'm using managed Expo so I can't use this library...

These are the limitations of the library, as stated in the README here.

Yes I've seen
Finally I have created my own API on my backend with restricted key IP.
And I have created a simple component with flatlist.
It's secure


Please can I have an AKS environment

Application Information
Application Name: demo-app-10
Business Justification: Because I want it
Technical Information
Host Environment Type:

[ ] Basic Web Application (App Service)
[X] Containerised Application (AKS)

Yeah this looks good to me, go ahead

All done - enjoy!


Fix summary bug: remove target message & refine update strategy

fix this bug https://github.com/eclipse-symphony/symphony/issues/378 first part: status.targets.xxx's error message won't be reset if current deployment is succeeded.

Please take a screenshot how current status looks like after you remove the duplicated target message?

Please take a screenshot how current status looks like after you remove the duplicated target message?

Thanks for comments. Add now


Replace cmd+L with another one

Validations

[X] I believe this is a way to improve. I'll try to join the Continue Discord for questions
[ ] I'm not able to find an open issue that requests the same enhancement

Problem
CMD+L is the default shortcut in vscode to select multiple rows below the cursor. Plugin shortcuts should not conflict with existing shortcuts in vscode self.
Solution
No response

UP!!
I totally agree, i disabled extension due this inability to change shortcut. I use a lot of CMD+L in regular days

+1 This is so frustrating.


"Valea Rizii" is listed in the drop-down menu

Description:
"Valea Rizii" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Valea Rizii" in the search bar.

Expected results
The location is listed in the drop-down menu as "Valea Rizii, Argeș (Dârmănești)".


bug: java.util.concurrent.CompletionException: java.lang.Exception: Failed to start Cody agent

Plugin version: 5.3.1544
IDE version: GO-231.8109.199
Stacktrace:
java.util.concurrent.CompletionException: java.lang.Exception: Failed to start Cody agent
	at java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:413)
	at java.base/java.util.concurrent.CompletableFuture.getNow(CompletableFuture.java:2134)
	at com.sourcegraph.cody.agent.CodyAgentService$Companion.isConnected(CodyAgentService.kt:143)
	at com.sourcegraph.cody.statusbar.CodyAutocompleteStatusService.didStatusChanged(CodyAutocompleteStatusService.kt:64)
	at com.sourcegraph.cody.statusbar.CodyAutocompleteStatusService.onCodyAutocompleteStatusReset$lambda$1(CodyAutocompleteStatusService.kt:43)
	at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:252)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.Exception: Failed to start Cody agent
	at com.sourcegraph.cody.agent.CodyAgentService.startAgent$lambda$3(CodyAgentService.kt:82)
	... 10 more
Caused by: java.util.concurrent.TimeoutException
	at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1960)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2095)
	at com.sourcegraph.cody.agent.CodyAgentService.startAgent$lambda$3(CodyAgentService.kt:69)
	... 10 more

Hey, thanks for reporting this issue!
We are aware of this and are working on a fix. A temporary workaround is to improve internet connection (this timeout issues are caused by low speed/temporary lags).
I'm closing this in favor of #723.


Clean up and optimize BasisUniversal

This PR aims to clean up BasisUniversal's code to make it easier to read, as well as extracts the code from register_types.cpp into its own files.
It also slightly optimizes the memory usage and compression times by using the get_mipmap_offset_size_and_dimensions() function instead of copying each mipmap's data into a new image.
While it seems to function correctly, it still needs some testing, especially on mobile devices.

I'm generally ok with this but I agree that testing on mobile devices is required.

Unlike our usual practice, such a change would be much easier to review if done as two separate commits: one to move the code to a separate file, and one to actual do logic changes. With both types of changes made in the same commit it's pretty difficult to review.

The commits are now split, as suggested.

Thanks!


Add Resume entry_path param

Lowkey PR - adds support for entryPath resume create parameter.

Marked as 'don't merge' since the change the API itself isn't live yet. I'll remove the label once this rolls tomorrow morning 👍

Alright, this can be merged! The API changes are live, flag is active, and I have seen the functionality work via pry. I can provide testing instructions if that helps with review. Warning: getting an oauth token to test with isn't the most direct thing but there are ways.


feat: Added new motivational quote

Hello @Shariar-Hasan This repo is perfect for a beginner like me to get started with Hactoberfest. Thank you for creating this repo. Added a quote, please give your suggestions.
Ref https://github.com/Shariar-Hasan/QuoteVerse/issues/93

Thank you for your comment @Shariar-Hasan I have updated the PR. Please let me know if anything else is needed.

@Shariar-Hasan Thank you for merging this. Could you please add the Hackcoberfest label to this PR.

@Shariar-Hasan Thank you for merging this. Could you please add the Hackcoberfest label to this PR?

dont worry about it,
the repository have hacktoberfest topiced,
so your merge will autometically counted.
you can check your hacktoberfest profile


feat: support run entry from stdin

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[ ] N
[x] Y

Close #130

feat: support run entry from stdin

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

4 of 26 (15.38%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 14.263%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/options/run.go
4
12
33.33%

pkg/fs/util.go
0
14
0.0%

Totals

Change from base Build<PHONE_NUMBER>6:
0.05%

Covered Lines:
89

Relevant Lines:
624

💛  - Coveralls


Welcome update to OpenMMLab 2.0

Welcome update to OpenMMLab 2.0
I am Vansin, the technical operator of OpenMMLab. In September of last year, we announced the release of OpenMMLab 2.0 at the World Artificial Intelligence Conference in Shanghai. We invite you to upgrade your algorithm library to OpenMMLab 2.0 using MMEngine, which can be used for both research and commercial purposes. If you have any questions, please feel free to join us on the OpenMMLab Discord at https://discord.gg/A9dCpjHPfE or add me on WeChat (ID: van-sin) and I will invite you to the OpenMMLab WeChat group.
Here are the OpenMMLab 2.0 repos branches:

OpenMMLab 1.0 branch
OpenMMLab 2.0 branch

MMEngine

0.x

MMCV
1.x
2.x

MMDetection
0.x 、1.x、2.x
3.x

MMAction2
0.x
1.x

MMClassification
0.x
1.x

MMSegmentation
0.x
1.x

MMDetection3D
0.x
1.x

MMEditing
0.x
1.x

MMPose
0.x
1.x

MMDeploy
0.x
1.x

MMTracking
0.x
1.x

MMOCR
0.x
1.x

MMRazor
0.x
1.x

MMSelfSup
0.x
1.x

MMRotate
1.x
1.x

MMYOLO

0.x

Attention: please create a new virtual environment for OpenMMLab 2.0.

Hi @vansin, thank you for the heads up. The developer team will evaluate the upgrade and possibly implement it in the long run. At this moment, we don't have a plan for an upgrade.


"extend" for read-only TTrees/merging user-defined content

Apologies if I use the incorrect keywords - that might be a part of my problems ;).
At the lowest level I am trying to
muon_py, muon_pz = input_tree.arrays(["Muon_Py", "Muon_Pz"], how=tuple)
muon_momentum = np.hypot(muon_py, muon_pz) # stand-in for arbitrary user function or awkward user data
# missing steps
# the below should work now
arrays = input_tree.arrays(["Muon_Py", "Muon_Pz", "Muon_momentum"], how=tuple)

Essentially, I would like to make use of the .arrays functionality for user-defined data, but input_tree is of type Model_TTree_v19 - i.e. has no extend functionality.
I know I can use aliases for data that is well represented through an expression with existing data, but I am looking for a more general solution, .e.g
arrays = input_tree.arrays(["Muon_Py", "Muon_Pz", "Muon_momentum"], how=tuple, extra_data={"Muon_momentum" : muon_momentum})

in a similar way that numexpr.evaluate uses local_dict.

Is that something that is already possible?
Would you recommend a workaround using library.group in a wrapper?
Would such an extension to the functionality make sense at all from your design perspective?

I think you're making a mistake (that a lot of people make) in thinking of TTree.arrays as a method for computation: it's a method for reading data from disk. I should never have added the ability to evaluate expressions in that method, since this keeps coming up—not just your question, but others in which people are trying to shoehorn multi-statement calculations into the expression strings.
One tip-off is that you're comparing with numexpr.evaluate, which is a method (and a whole library) for computation. Uproot is just I/O; what computation it does (in the expressions and cut arguments) is just reading into temporary arrays and evaluating the expression in the string with Python. By adding the convenience of doing that in one line with the reading, I've created the expectation that this is how computation happens, and led a lot of people into unproductive alleys based on that expectation. This is a lesson for me in design: sometimes adding "shortcuts/conveniences/another way of doing something" can make things very inconvenient for users—I'm sorry about that!
If you want to make the second line possible because you want the "Muon_momentum" data to be in the file, so that you can give the file to someone else and maybe open it in ROOT, UnROOT, Laurelin, or another Uproot somewhere, the only way that's currently implemented is to read from one file/TTree and write to another. Modifying a TTree in place is not in-principle impossible, but it would be a major project to implement. (I wish I could find the GitHub Issues or Discussions where I've outlined what would be involved, but I can't find them.)
If you know all of the above (that TTree.arrays is meant for I/O, and expressions/cuts are really just evaluating in Python) and just want to be able to add variables to the context of the expressions that are evaluated in Python—that is, add muon_momentum to the dict of local or global variables that TTree.arrays passes into eval, then that would be a matter of getting it into this dict:
https://github.com/scikit-hep/uproot4/blob/027f7a11e4032eb26a05659e5fe1c9371c52f46d/src/uproot/language/python.py#L429
But please don't! That would make the I/O-compute confusion even worse!


Mobile UI: 'display: fixed' components (timebox, tooltip, etc.) does not stay in place when scrolling, and behaves like 'display: sticky' instead

Video: https://vimeo.com/692944498/1da7a7ef99

Similar to #272 I think this is just an issue with desktop chrome (developer mode) forcing screen size. I personally haven't encountered this issue on actual mobile yet

I think we can close these two? Unless anyone else has encountered this issue


Add connection pool

The goal of this PR is to add a connection pool that will handle connection, reconnection, and other aspects of multiple connections.
It allows to:

configure each connection separately
start with 1 of N connections and start re-create process for failed connections
re-create connections closed by server waiting for ReconnectWait before next attempt
get connections in round-robin filtered (by address, key/value, etc.)

Things yet to be done:
1 We need to be able to send network management messages to server when connection is established
Use-case: when we establish the connection we should send sign on message and receive confirmation. Only after that we can use the connection.
maybe we need something like OnConnect hook (it will be synchronous) - which will perform required actions before adding connection to the pool?
2. How do we get only online connections on the client side? Maybe add GetBy with filter func:

func (c *Client) getActiveConnection() (*Connection, error) {
       // loop over connections? using pool.Connections() is not safe for this as some connections can be closed
       // maybe add pool.GetBy(func(c *Connection) bool) ?
       conn := c.pool.GetBy(func(c *Connection) bool {
            return c.Status() == "online"
       })
       if conn != nil {
            return conn, nil
       }

        return nil, errors.New("no active connections")
}

also, this (and I wanted to add status to the connection anyway) will require us to add status method so the client can set arbitrary status and check if all connections are online, etc. Right now - there is no way for us to implement the status of the connection unless we wrap it into another type...
func (c *Connection) Status() string {
        // mutex
        return c.status
}
func (c *Connection) SetStatus(status string) {
        // mutex
        c.status = status
}

I really like this approach as an alternative to spinning up multiple nodes in a K8s pod or K8s cluster.

@adamdecaf @ashton-herrington @ev-the-dev I've done the work on this PR.
While iso8583 Pool is not a typical pool, it's still a pool. It's just a domain-specific pool with features needed to make iso8583 client work and satisfy most use cases.
I added different callbacks, etc. to make our brand gateway work with the pool.
Please, review.

Nice! This looks pretty good

Added some observations/suggestions/questions, overall looks great though!


Schedules aren't scheduled right after server start up

When UA starts up it schedules the jobs with hangfire. I'm noticing an error when starting up and the schedules aren't setup right away.
2020-03-10 07:30:33 [WARN]  (Hangfire.AutomaticRetryAttribute) Failed to process the job 'ada39f27-97aa-42b7-9c29-b69697867d7f': an exception occurred. Retry attempt 1 of 10 will be performed in 00:00:19.
System.IO.IOException
The process cannot access the file 'C:\Users\adamr\AppData\Local\UniversalAutomation\database.db' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at LiteDB.FileDiskService.CreateFileStream(String path, FileMode mode, FileAccess access, FileShare share)
   at LiteDB.FileDiskService.Initialize(Logger log, String password)
   at LiteDB.LiteEngine..ctor(IDiskService disk, String password, Nullable`1 timeout, Int32 cacheSize, Logger log, Boolean utcDate)
   at LiteDB.LiteDatabase.<>c__DisplayClass11_0.<.ctor>b__0()
   at LiteDB.LazyLoad`1.get_Value()
   at LiteDB.LiteCollection`1.<Find>d__17.MoveNext()
   at LiteDB.LiteQueryable`1.<ToEnumerable>d__21.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at UniversalAutomation.LiteDBTable`1.ToArray()
   at UniversalAutomation.LiteDBTable`1.Get()
   at UniversalAutomation.JobScheduler.Schedule()

You'll notice the NextExecutionTime is DateTime.MinValue.

Resolved.


[Question] How do you re-enable Sync & Login with Microsoft Edge

I've been searching for hours and I can't figure out how to either revert it or prevent it from changing.
Greatly appreciate your help in solving this, and thank you for all the effort you two put in!

Optimize-Offline does not disable Microsoft Edge synchronization, though that's not to say the removal of a System Application/Capability/Package would not affect it from working properly.
According to my ADMX templates, the Group Policy setting for this is located here:
Computer Configuration\Administrative Templates\Windows Components\Sync your settings
Lastly, is this for Edge HTML or Edge Chromium?

Edge Chromium.
I was following the guide on MDL/GitHub that listed a bunch of services that could be safely removed and it seems to be a side effect of one of the ones listed. I tried to deduce it down to a specific service but wasn't able to after rebuilding and reformatting quite a few times.
I followed the rest of the guide exactly and only removed Edge/EdgeDevKit and Windows Defender (can't remember the name) and Sync worked perfectly with only those removed even with all of the registry tweaks enabled.
I only just realized that you're not the author of the thread on MDL as well, so sorry for wasting your time.

Diving into this error a bit more, the exact error description is  "A specified logon session does not exist. It may already have been terminated." This kind of error is primarily isolated to domain-joined devices (usually a result of 'domain jumping').
Is your device connected to a domain by any chance?
I would recommend creating a new administrator profile and signing into it - keeping it in its default state - and then checking if synchronization works on a fresh, untouched account.

Yes, when I format I always join a domain instead of logging into a Microsoft account.
Unfortunately I'm not in a situation at the moment where I can test and see if that would resolve the issue.
I appreciate all of your help!


default Caching results in wrong download behavior

the standard caching behavior of not only the packages, but also of query request lead to the following issue

execute a Save-NugetPackage request based on an non-existing package -> "not found" error
upload the package
immediatly afterwards execute Save-NugetPackage again

Expected Behavior:   the package should be downloaded
Actual Behaviror:   again "Not found" error occurs
Analysis:

after executing "nuget locals all -clear" and re-executing the save command the file is found on the server
the used standard cache context caches request results with quite a long timeout

Solution proposal:

disable cacheing as the normal use-cases for the cmdlets do not necessarily need the caching (in contrast to nuget restore scenarios)
disable caching leads to longer response time, BUT to consistent behavior, which is currently more important
option to implement retry with cache-ignore after unsuccessful retrievals could combine best of both worlds later

Check other SourceCacheContext usages as well, not only Save-NugetPackage

try this
https://mega.nz/file/1vkGlJTL#yU-SJLlIilF0mx5qwpPOd3BM8iKZqOJLEQUStR76rrQ
If you don't have the c compliator, install it.(gcc or clang)


Problem with Build Pipeline and Run-AlPipeline

Hi Freddy, we are trying to upgrade our build pipelines to use BCContainerHelper instead of NAVContainerHelper.  However, we are having trouble with an error in the Run-AlPipeline script:
##[error]Directory 'c:\sources.._BuildPipeline' could not be found
The way our workspace for this project is structured is as follows:
.\ (root)
.\_BuildPipelineScripts\CI.Yml
.\_BuildPipelineScripts\scripts\ (all the PS scripts)
.\Extension1
.\Extension2
.\Extension3
.\BaseExtension\
To account for this structure, I have fiddled with the scripts and parameters a bit - I think this may boil down to line 21 on the DevOps-Pipeline.ps1 script:
$baseFolder = (Get-Item (Join-Path $PSScriptRoot "..")).FullName
If I leave the Join-Path parameter as "..", then the container won't create.  The $PSScriptRoot would be ._BuildPipelineScripts\scripts, so it would navigate up only to ._BuildPipelineScripts\ and won't find the folders.  When I change this to navigate two directories up (to .), then I get the error above with c:\sources.._BuildPipeline not being found.
The Run-AlPipeline script specifies this folder on line 221 I believe.
New-BcContainer `
    -accept_eula `
    -containerName $containerName `
    -imageName $imageName `
    -artifactUrl $artifactUrl `
    -Credential $credential `
    -auth UserPassword `
    -updateHosts `
    -licenseFile $licenseFile `
    -EnableTaskScheduler:$enableTaskScheduler `
    -MemoryLimit $memoryLimit `
    -additionalParameters @("--volume $($baseFolder):c:\sources")

Is there a way to work with this directory structure?  I am puzzled by the error and will try to move our script files around, but there may be another way to fix it.
Thank you!

Hi Freddy, please disregard.  This suddenly started working - I'm not sure what happened.  Sorry for the trouble.

Hi Freddy, please disregard.  This suddenly started working - I'm not sure what happened.  Sorry for the trouble.

7 minutes for self-healing to work:-)
Have a nice weekend.

7 minutes for self-healing to work:-)
Have a nice weekend.


How to determine the containers IP

With the current method to obtain the container ip: getent hosts $HOSTNAME or even the new one: dig +short $HOSTNAME, there is no way to use an overlay network if it exists.
And that's the case if you are using tools like Rancher to manage your containers.
With Rancher you normally ask the rancher metadata to get that IP: curl -s http://rancher-metadata/latest/self/container/primary_ip.
I think there should be some flexibility to obtain the IP to allow more use cases for the images.
Somehow related, specifying the dns server to obtain the consul ip also breaks the Rancher dns: dig +short consul @<IP_ADDRESS>

Thanks for this issue. You raise a good point. I'll update the containers so that it's easier to change the method in which the current IP is retrieved. I'll move this functionality into a shell script in /usr/bin that can be used in all other scripts to determine the current IP. That will make it much easier to provide another method to retrieve the IP in non-standard environments such as Rancher.
Thanks for letting me know that the new method dig +short consul @<IP_ADDRESS> also breaks on Rancher. I've got a hunch I don't need to use that IP specifically. I'll investigate this a little more.
I'll work on this change as part of the branch in which I'm working on a bunch of improvements to Consul. https://github.com/smebberson/docker-alpine/tree/alpine-consul-ui-upgrades

@ncornag, any chance you could send me your /etc/resolv.conf file after one of your containers in Rancher starts up?

Sure!
/ # cat /etc/resolv.conf
nameserver <IP_ADDRESS> # added by go-dnsmasq
search local micro-example.rancher.internal consul-ui.micro-example.rancher.internal rancher.internal
# disabled by go-dnsmasq # nameserver <IP_ADDRESS>

@ncornag, have you found success in using the latest version of these containers by overriding /usr/bin/container-ip as found in alpine-base?

Yes, it gives me a lot of flexibility.


Equivalent of @versioned for one object

Hi,
I do not use DataStore and Delta Sync.
I just want to handle concurrent writes for only one object. But when I select CONFLICT DETECTION with Optimistic Concurrency, it is for all objects. All objects have a new _version attribute.
How to set CONFLICT DETECTION with Optimistic Concurrency, only for one object with the CLI ?

Hi @rudyhadoux, in the V2 transformer there is no equivalent directive for @versioned, DataStore is the way we provide conflict detection. Today different options for conflict detection resolution strategy can be selected for each individual object but the conflict detection feature is at the API level. Every @model will have it if enabled.

With @versioned it was PER OBJECT. And it was very simple ans useful.
Why delete it ???


Snappy compressor can't compress more than 32767 bytes

Expected behavior
I expect the Snappy compressor to be able to compress a much larger amount than 32767 bytes.
Actual behavior
An exception is thrown if the data is too large.
Steps to reproduce
Try to compress a ByteBuf larger than 32767 bytes using the Snappy.encode method.
Minimal yet complete reproducer code (or URL to code)
public static void main(String[] args) {
    final byte[] random = new byte[40_000];
    ThreadLocalRandom.current().nextBytes(random);
    { // This should work
        final Snappy snappy = new Snappy();
        final ByteBuf data = Unpooled.wrappedBuffer(Arrays.copyOfRange(random, 0, 32767));
        final ByteBuf out = Unpooled.buffer();
        snappy.encode(data, out, data.readableBytes());
    }
    { // This does not work
        final Snappy snappy = new Snappy();
        final ByteBuf data = Unpooled.wrappedBuffer(random);
        final ByteBuf out = Unpooled.buffer();
        snappy.encode(data, out, data.readableBytes());
    }
}

Netty version
4.1.89
JVM version (e.g. java -version)
java version "1.8.0_291"
Java(TM) SE Runtime Environment (build 1.8.0_291-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.291-b10, mixed mode)
OS version (e.g. uname -a)
Windows 10 x64 22H2 19045.2546

The implementation is for use in the SnappyFrameEncoder, which limit its chunk size to this in order to conserve memory.

Being able to configure the maximum allowed chunk size in the constructur would be a nice feature as I would like to use the Snappy encoder/decoder outside of the SnappyFrameEncoder without needing extra libraries

@RaphiMC we love contributions

I would if I knew why it is not working and how to fix it. As a temporary workaround I am just writing the data as uncompressed snappy chunks: https://github.com/RaphiMC/ViaBedrock/blob/main/src/main/java/net/raphimc/viabedrock/netty/SnappyCompression.java#L35

Why not just chunk the data as we do in SnappyFrameEncoder ?

The protocol I am implementing expects raw snappy data without framing. I would just use the SnappyFrameEncoder if it accepted that

Got it... Then there is not much you can do other than adjusting Snappy and provide a PR.


[Missing documentation] How to actually setup VS Code portable to remote into legacy servers

Like many I was hit by the discontinued support to remote in legacy servers with 1.86.1.
The documentation says one option is to set up a Portable Mode installation fixed to version 1.85, which is the last with that support.
Ok let's follow those links: the download page for 1.85 and the instructions for Portable Mode. I am on Windows.

Where is this ZIP archive? Surely not on the download page of 1.85. After quite a bit of looking around, here is the correct path to find it

Go to the default download page. Ignore it and got the the tiny Get previous versions at the bottom.
Follow the instructions to build the download link by yourself, which in my case is https://update.code.visualstudio.com/1.85.2/win32-x64-archive/stable

Now you can follow the instructions for Portable Mode. Note however that

It will group in the taskbar with your standard installation of VS Code
It will have the same icon as your standard installation of VS Code

I followed the instructions in this reddit post to fix this.
Another problem: the suite of remote extensions will not work because by default it tries to install the latest versions, which are incompatible. You have to manually pick the last working version for each. This includes the Remote Explorer extension, which for some reason is not part of the Remote Development extension pack.

1.86.1 made VS Code work again on 'legacy servers'. If you're unable to connect using more recent versions of VS Code, please share more information about the issues you experience.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


serde_magnus discontinued?

not totally related to magnus but idk any better place to ask about this
refering to https://github.com/matsadler/magnus/pull/47
i tried searching for forks but can't find any , does anyone know what happened?

I don't know what happened, but I hope the author is doing ok.
I do happen to have a reasonably recent local checkout of the code, which I have pushed to https://github.com/matsadler/serde-magnus, but I don't have any plans to maintain it. If the original author is reading this and you'd prefer I take this down, comment here, or my email address is on my GitHub profile.
If anyone takes up maintenance of that crate, let me know and I can link it from the Magnus readme/docs.

OneSignal is starting to work with serde-magnus, and I wanted to share that we published an update to crates.io to bring the magnus version up to 0.6.2. The code is currently under the OneSignal org.
We are not yet using the code in prod, and I can't make any guarantees that we will maintain it in the long term, but for the time being we are happy to maintain and work with the community to fix issues and accept patches.

Great! I've linked to it from the readme and docs (though I've not done a release, so you won't see the links on crates.io/docs.rs til I do).


Add compression parameters

Added manual compression, best, brute and ultra-brute compression flags.
Manual compression is called with the -c flag and ranges from 1 through 9.
-best, -brute and -ultra-brute call their repective UPX compression levels.

Thanks for the pull request. Is there a way we can arrange to simply pass through all of the parameters? I  think that would be the best solution. Otherwise we have to A) update goupx if upx's parameters ever change B) reimplement a lot of parameter validation logic and C) our arguments won't be compatible with upx.
I realise this might have been done because there were existing flags. I think these could be implemented fairly easily by just looking at os.Args rather than sending them through the flags package.
What do you think?

Do you mean simply passing a list of input arguments, regardless of what they may be, directly to UPX? If so, that is certainly doable.

Yes, that is my preference :)

Should I simply replace your usage of flags or create an additional flag parameter that passes it's string to UPX?
Additional Flag: goupx -a "--ultra-brute" filename
Replacing Flag: goupx --ultra-brute filename
The only downside to directly passing parameters in this manner is that passing multiple files as an argument will currently crash the program.

I'm a bit confused. I think my preference is just that goupx more or less directly forwards the arguments to upx. That might mean dropping UPX's current flags if necessary, or replacing them with ones which don't collide with UPX. If we do keep flags, we should manually remove them from the list of flags and forward everything else.

By "Keep flags" here, I mean keep -s and -u.

Essentially, you can either use the flag package for handling arguments, or use os.Args() and parse the flags manually yourself. You can't mix both methods at the same time. Therefore, yes, if you are wanting to act as a simple wrapper that just passes arguments directly to UPX, you may have to rename -s and -u to something that doesn't conflict with UPX's native flags (supposing it uses these flags). That way, we can parse out the goupx-specific flags from the upx-specific flags.
It may also be a good idea to make additional changes so that goupx can process multiple files, as UPX natively supports accepting any number of file arguments. If a user tries to use goupx in the same fashion it will crash when trying to process other file arguments.

Yes, I'm proposing to drop the flag parsing and pass os.Args() through. You could also add a feature to pluck from os.Args() -s and -u, or you could just drop them. I don't think they are very useful,

Hopefully this resolves your concerns. It passes all arguments to UPX directly, besides the goupx-specific arguments, which I've renamed to --no-upx and --strip-binary. It also allows you to pass multiple files as arguments.

This looks really good! :)
Would you like to add a CONTRIBUTORS file and add yourself to it, too? (Along the lines of this: https://github.com/go-gl/glfw/blob/master/AUTHORS)

It's fine. I've added the check for empty arguments.

Thanks again!


Assert on Duplicate Field Names

Small change that asserts that DB field names are unique. Helpful in cases where you're renaming a lot of DB fields to something shorter and could have collisions.

Thanks @adamaflynn for the initial code.  Now in dev


Image upload for Activity page

In my first attempt to upload an image to the Activity page as an admin, I received a 500 error.

In my second attempt, I received an untangled exception error.
An unhandled exception occurred while processing the request.
FormatException: No valid combination of account information found.
Microsoft.WindowsAzure.Storage.CloudStorageAccount.<>c.b__87_0(String err)
Stack
Query
Cookies
Headers
FormatException: No valid combination of account information found.
Microsoft.WindowsAzure.Storage.CloudStorageAccount.<>c.b__87_0(String err)
Microsoft.WindowsAzure.Storage.CloudStorageAccount.ParseImpl(String connectionString, CloudStorageAccount& accountInformation, Action`1 error)
Microsoft.WindowsAzure.Storage.CloudStorageAccount.Parse(String connectionString)
AllReady.Services.ImageService.d__6.MoveNext() in ImageService.cs

           var account = CloudStorageAccount.Parse(_settings.StorageAccount);

--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
AllReady.Services.ImageService.d__4.MoveNext() in ImageService.cs

       return await UploadImageAsync(blobPath, image);

--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
AllReady.Areas.Admin.Controllers.ActivityController.d__12.MoveNext() in ActivityAdminController.cs

       a.ImageUrl = await _imageService.UploadActivityImageAsync(a.Id, a.Tenant.Id, file);

--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Controllers.ControllerActionExecutor.d__8`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Controllers.ControllerActionInvoker.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.d__50.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.d__41.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Infrastructure.MvcRouteHandler.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Routing.Template.TemplateRoute.d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Routing.RouteCollection.d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Builder.RouterMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Authentication.AuthenticationMiddleware`1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.ApplicationInsights.AspNet.ExceptionTrackingMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Diagnostics.Entity.DatabaseErrorPageMiddleware.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Diagnostics.Entity.DatabaseErrorPageMiddleware.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware.d__6.MoveNext()

This might be a configuration issue: if you run with UseDevelopmentStorage (it might be DevelopmentStorage) as true and attempt to access Azure storage I think this is the message you get.  But it might also arise if AzureStorage is misconfigured in other ways?
Running the site locally, I can successfully upload an image to Azure.

I can duplicate the second error above.
Can anyone confirm the form of the connection string that is used for Data:Storage:AzureStorage on http://allready-d.azurewebsites.net/?
On my local machine I have a string of the form:
DefaultEndpointsProtocol=https;AccountName=simonkittle;AccountKey=<removed>
No other items, no whitespace.  And it works okay.

My goodness.  There was a space between the ; and 'A' in AccountName that was causing this :-1:
Fixed now.  Thanks all.


Allow to customize float window appearance e.g. of the doctor

Describe the feature
The doctor float window is created here:
https://github.com/scalameta/nvim-metals/blob/6065608a98a6add79886ad8ab6d2f2619cff8a09/lua/metals/doctor.lua#L164-L175
It has hardcoded parameters for creating the window and relies on plenary. I would be very happy if this could be more customizeable. I.e., I would want to do something like this to specify configuration:
require("metals").setup {
  floats = {
    window_options = {
      width = 0.9,
      height = 0.9,
      title_pos = "left",
    },
    border = {
      style = "double",
    },
  },
}

where window_options and border have are similar to the options for the builtin nvim_open_win.
Perhaps it would make sense to rely on Popup from nui.nvim instead of plenary here? It provides something that is more in line with nvim_open_win and that it may be easier to customize; possibly.
Potential ways to implement
I could possibly help with implementing this, but I would need some guidance and I think it should be done for more than just the doctor. That is, I would want to allow custom configuration for all the floating windows similar to the doctor using the same mechanism.

Thanks for opening this up @lervag. I can understand why someone may want a bit more control here.

Perhaps it would make sense to rely on Popup from nui.nvim instead of plenary here?

I don't think I really want to switch at this time. I use Plenary for a couple other modules throughout nvim-metals, like Path, etc, so it's not as easy to swap it out, even if I wanted to. I also wouldn't want to require another dependency.
Let me think on this a bit and I'll see if I can come up with a direction I feel comfortable with that would allow something like this. It's also worth being said that I've purposefully kept configuration in nvim-metals very minimal just to make maintenance easier, so I also want to be a bit careful here.

Perhaps it would make sense to rely on Popup from nui.nvim instead of plenary here?

I don't think I really want to switch at this time. I use Plenary for a couple other modules throughout nvim-metals, like Path, etc, so it's not as easy to swap it out, even if I wanted to. I also wouldn't want to require another dependency.

Ok, that's fine and understandable.

Let me think on this a bit and I'll see if I can come up with a direction I feel comfortable with that would allow something like this.

Cool!

It's also worth being said that I've purposefully kept configuration in nvim-metals very minimal just to make maintenance easier, so I also want to be a bit careful here.

Yes, I like that idea personally. But on this specific topic, I think there is a reason to allow more flexibility. I've tried to make all my floating windows have a consistent style. I believe for everyone who wants to do that, we actually need a way to provide this configuration. Of course, we will use sensible defaults that many people will be fine with.


Spec unclear on isolators

Pod schema says "value can be a freeform string"
Image schema says just list of objects and nothing more
Isolators section says value "can be an arbitrary JSON value"

Attached.

LGTM


Hashes don't match

I ran the script with full extraction and absolutely none of the hashes had a match. Would this be because the hash is acquired after the file has been converted?

Probably due to of updates to Overwatch since the last commit, so the hashes are all mixed up now. I would also really like to see a fix for this.

Then perhaps we need to start the process over and rebuild the list. Hopefully Blizzard doesn't intend on changing this every time they update the game.

Is there a way to reliably categorize the sounds? If so, could we automate it?

Duration seems like an option to me. Long files could be assumed to be music but it gets more difficult further down. Maybe voice lines are all the same length if we are lucky. Hopefully patterns will emerge.

Ok, forget about categorize. I can do that manually :)
How do detect that file is Wwise audio? I was trying to convert files manually, no success. File detection program (/bin/file) reports "data" for most files. I also hope that "RIFF" files is what I need.
$ find . -exec file {} +
./00/00002638bdc461b9ede5f9fdf31b135a.xxx: data
./00/00006db6c663e15633625718b0ba01f2.xxx: data
./00/0001c4b23ec41c27f2012d70cbce28c3.xxx: RIFF (little-endian) data, WAVE audio, mono 48000 Hz
./00/0001ef3a17f0cd232fd8aa35f19bf796.xxx: data
./00/0002e9538d4f7bad945a68e55278d4fd.xxx: RIFF (little-endian) data, WAVE audio, mono 48000 Hz
./00/000353202638fa0b37eb765390cc5901.xxx: data
./00/0003a6f2fe11cd4d6220e655270d2427.xxx: data
./00/00044a1546a0816c82041d1d19f084aa.xxx: data Hz


Update links from 2022 -> 2023 edition of the OEWN

They changed the URIs of the IDs of the entire OEWN dataset.

The base URI for the synsets used to be https://wordnet.dk/dannet/data/, but is now https://en-word.net/id/.
The base URI for the lemmas used to be http://wordnet-rdf.princeton.edu/lemma/, but is now https://en-word.net/lemma/.

The lemma base URI doesn't matter, but the synset links need to be deleted and re-added using the new base URI.

This example can be used for reference: http://localhost:3456/dannet/data/synset-298
DanNet currently contains 3 separate outbound links:

wn:eq_synonym
dns:eqHyponym
dns:eqHypernym

They link to both CILI resources and OEWN synsets, so any query using these relations to fetch all OEWN links will need to filter out the CILI resources.

(I also removed the old OEWN extension dataset and generated new ones for this issue, since the old ones also referred to the old synset IDs)


aya: Make FEATURES public

This commit adds a new probe for bpf_attach_cookie, which would be used to implement USDT probes. Since USDT probes aren't currently supported, this triggers a dead_code warning in clippy.
There are cases where exposing FEATURES - our lazy static - is actually helpful to users of the library. For example, they may wish to choose to load a different version of their bytecode based on current features. Or, in the case of an orchestrator like bpfd, we might want to allow users to describe which features their program needs and return nice error message is one or more nodes in their cluster doesn't support the necessary feature set.

We can't expose the static because it leaks lazy_static API (you need to call .get() or deref), and we can't expose the Features type as it is as it would be the ultimate API breaking type: every new feature breaks API.
What we can do is to add a features() -> &'static Features util function somewhere, and then add pub method accessors for all the still private fields in Features. That would allow us to add features without breaking API.


Add telemetry for when the "join mailing list prompt" is displayed

Right now we collect information for when users selects things or dismiss it, but it was brought up to me that we should also collect if it's displayed. A lot of people simply don't see notification prompts, so it'd be good to be able to differentiate those

Done.

Done.


Add @font-face declarations using 'BC Sans' for font-family

I'm making this PR for discussion - there might be a better way to solve this that I'm missing.
The CSS file that ships with this package has always used BCSans (no space) for the font-family value inside its @font-face declarations. By contrast, the metadata in the font files use BC Sans (with a space) for the font family name.
Here's an example of the metadata for the WOFF file for BC Sans Regular in a Font Forge window:

We (OSS Design Team in GDX) have begun work on a new version of the BC Design System where we will be shipping a Figma design system file and a design tokens package for use by designers and developers. Figma alows for designers to design using custom fonts like BC Sans, either through its desktop app directly, or through its web interface using a separate desktop font integration app. Since the BC Sans font files use the name BC Sans with a space, all designs that reference the font end up using the name with the space in the code samples generated by Figma. Because of this, if I want to allow our @bcgov/design-tokens package to work with the CSS provided by this package, I would need to manually update the name of the font-family in the design tokens variables.
Example design token CSS variable using code as it comes out of Figma:
--bcds-typography-regular-body: 400 1rem/1.688rem 'BC Sans';

If I were to use that CSS variable along with the CSS @font-face code in this package as it is today, my end users would not see the BC Sans font as intended.
Any Figma user designing with BC Sans will have this issue, regardless of whether they choose to use our design tokens or not. Here's an example new Figma file that doesn't use the design tokens, which I've built using the web interface. I've set the font face to BC Sans using Figma's font agent on my Mac:

To improve the designer and developer experience of using this package along with Figma, I propose that we should add the correct font name to the CSS declarations as I've done in d13e52f47d478dafb491a85623321dc0fc67daec. I don't think we can make the correction in place, because many apps use this package and have code written to reference the BCSans name. Even fixing it in place with a major version bump will cause a lot of pain. I think any change like this would need to be additive.
I recognize that this will mean more code shipped to the end user. However, I feel the benefit in terms of designer and developer experience are worth the extra 1.2K. Figma has been increasing in popularity to the point where it's the most popular UI prototyping software, and it has been requested by our design community for years. Without this change, any future designer/developer teams using Figma to generate code in our ecosystem would also need to be aware of this bug, manually updating their code. It's also not easy for employees on Gov-provisioned laptops to notice that there is a problem with Figma's generated code - assuming they have the BC Sans font installed, the reference to BC Sans from Figma's code will work with their system fonts, and the problem might make it to the end user.
Please let me know your thoughts, @ShawnTurple , @mhaswell-bcgov .

After talking with @ShawnTurple, he suggested adding the new @font-declaration rules to a new CSS file. I've done this in 1129131a479d4c7bfac8b4f0147b0e1e1057c42e. This will allow new projects to use the new CSS file while existing projects can continue using the old one, minimizing their bundle sizes.
I've updated the README in c53455d942bb1127738fe1642a9ebee2e008334d. I am referencing the new css/BC_Sans.css file as the default in the existing code samples. I've added a section on why the two files exist, aiming for a grade 7 reading level on Hemingway.

I have bumped the package version to v2.1.0 in 4d961d438b947483b78496d3042d835176edb480.


Have a meeting with Designsystemet

In order to create a scalable colour system we need to generate colour families programmatically. To gather some insight from somebody who already does that, let’s have a conversation with the designers from Designsystemet.

[x] Call for meeting
[x] Write a summary

A summary from the meeting is written  here


Add a new button for refreshing the page.

Will you plz add a new button in the extension that could start/stop refreshing the page after a given interval or after all clicks ends.
That will increase more functionality of extension and will be helpful.

added refresh feature


translate pomodoro-clock to pt-br

#10

closing this as there's already a PR translation for this #15


logging: Ensure constant side effects of log API

When log API is used it should give the same side effect when enabled
or disabled e.g. LOG_INF(%d,cnt++) should always increment cnt.
Before this change cnt would be incremented twice when log enabled
and never incremented when log was disabled.
Signed-off-by: Krzysztof Chruscinski<EMAIL_ADDRESS>

fyi, it may be not clear from the diff but only log_printf_arg_checker(VA_ARGS) has been moved to else case and comment was added.

Codecov Report

Merging #8850 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8850      +/-   ##
==========================================
- Coverage   52.32%   52.32%   -0.01%
==========================================
  Files         195      195
  Lines       24730    24730
  Branches     5140     5140
==========================================
- Hits        12941    12939       -2
- Misses       9715     9717       +2
  Partials     2074     2074

Impacted Files
Coverage Δ

include/logging/log_core.h
0% <ø> (-100%)
:arrow_down:

Continue to review full report at Codecov.

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


TTL destruction polling

As a developer I would like the clusternator to automatically clean up my resources after a fixed amount of time.
All PR EC2 resources are tagged with a TTL.  Iterated over the ec2's, find, and destroy all related services using the PR teardown system:
PR Teardown
Closing a PR triggers a tear down.  There is a TTL flag that will also tear down
a PR.

reduce services' task counts to zero (0)
delete services / tasks
unbind (deregister) ec2 containers
delete the ecs cluster
delete the ec2 instances
delete security groups
delete network interfaces
delete route 53 entry

[ ] default TTL setting
[ ] project TTL setting
[ ] TTL constant tag
[ ] Add TTL Tag to EC2 instance

ec2.describe().then()
Then filter for:
Tag with Key === clusternator-pr (check constants file)
Tag with projectId clusternator-project
Tag with expiry key
Then run
projectManager.destroyPR('projectId', 'prNumber').then(...
Adding tags to ec2s can be done in ec2Manager.js line ~200
Finally the loop / watcher needs to go in the server section.


[Feature Request] Support for ready-to-use GPT3.5

Irrelevant Remarks
Great library by the way, and as someone who does not like to deal with REST APIs, having it exposed as native methods makes my code cleaner.
Is your feature request related to a problem? Please describe.
According to official API doc and Engadget news, ChatGPT's model is officially available as of today (2023.03.01). It would be nice if this library can support the corresponding names for the completion API.
Describe the solution you'd like
I think there should be minimal API change - essentially adding an enumeration. This feature request only concerns the completion API.
Describe alternatives you've considered
I tried to make a fork but the ModelNameBuilder programming model is a bit confusing to me so I will leave this feature implementation to the original author😂
Additional context

It's on the way

Sorry about ModelNameBuilder, it's a bit messy but It is really hard to follow OpenAI naming rules :D however, check version 6.7.0