I noticed, that when I'm converting a nn.TransformerEncoderLayer, the parameter counts are mismatched, despite the fact that the conversion proceeds without issue (all green according to nobuco).
The problem seems to come from the linear1 which for some reason, doesn't get constructed with the right dimensions (or as a normal Dense layer). The correct number of parameters would be 128 x 256 + 256 = 33'024. However, the resulting tensorflow model seems to construct a layer of size 512 x 256 = 131'072.
torchinfo's summary:
==========================================================================================
Layer (type:depth-idx)                   Output Shape              Param #
==========================================================================================
TransformerEncoderLayer                  [1, 512, 128]             --
├─MultiheadAttention: 1-1                [1, 512, 128]             66,048
├─Dropout: 1-2                           [1, 512, 128]             --
├─LayerNorm: 1-3                         [1, 512, 128]             256
├─Linear: 1-4                            [1, 512, 256]             33,024
├─Dropout: 1-5                           [1, 512, 256]             --
├─Linear: 1-6                            [1, 512, 128]             32,896
├─Dropout: 1-7                           [1, 512, 128]             --
├─LayerNorm: 1-8                         [1, 512, 128]             256
==========================================================================================
Total params: 132,480
Trainable params: 132,480
Non-trainable params: 0
Total mult-adds (M): 0.07
==========================================================================================
Input size (MB): 0.26
Forward/backward pass size (MB): 2.62
Params size (MB): 0.27
Estimated Total Size (MB): 3.15
==========================================================================================

Keras's summary:
__________________________________________________________________________________________________
 Layer (type)                Output Shape                 Param #   Connected to
==================================================================================================
 input_1 (InputLayer)        [(1, 128, 512)]              0         []

 tf.compat.v1.transpose_2 (  (1, 512, 128)                0         ['input_1[0][0]']
 TFOpLambda)

 multi_head_attention_2 (Mu  (1, 512, 128)                66048     ['tf.compat.v1.transpose_2[0][
 ltiHeadAttention)                                                  0]',
                                                                     'tf.compat.v1.transpose_2[0][
                                                                    0]',
                                                                     'tf.compat.v1.transpose_2[0][
                                                                    0]']

 dropout_1 (Dropout)         (1, 512, 128)                0         ['multi_head_attention_2[1][0]
                                                                    ']

 tf.compat.v1.transpose_3 (  (1, 128, 512)                0         ['dropout_1[0][0]']
 TFOpLambda)

 weight_layer_4 (WeightLaye  (1, 512, 256)                131072    ['input_1[0][0]']
 r)

 tf.__operators__.add (TFOp  (1, 128, 512)                0         ['input_1[0][0]',
 Lambda)                                                             'tf.compat.v1.transpose_3[0][
                                                                    0]']

 dropout_2 (Dropout)         (1, 512, 256)                0         ['weight_layer_4[0][0]']

 tf.compat.v1.transpose_4 (  (1, 512, 128)                0         ['tf.__operators__.add[0][0]']
 TFOpLambda)

 dense_1 (Dense)             (1, 512, 128)                32896     ['dropout_2[0][0]']

 layer_normalization (Layer  (1, 512, 128)                256       ['tf.compat.v1.transpose_4[0][
 Normalization)                                                     0]']

 dropout_3 (Dropout)         (1, 512, 128)                0         ['dense_1[0][0]']

 tf.__operators__.add_1 (TF  (1, 512, 128)                0         ['layer_normalization[0][0]',
 OpLambda)                                                           'dropout_3[0][0]']

 layer_normalization_1 (Lay  (1, 512, 128)                256       ['tf.__operators__.add_1[0][0]
 erNormalization)                                                   ']

 tf.compat.v1.transpose_5 (  (1, 128, 512)                0         ['layer_normalization_1[0][0]'
 TFOpLambda)                                                        ]

 tf.identity (TFOpLambda)    (1, 128, 512)                0         ['tf.compat.v1.transpose_5[0][
                                                                    0]']

==================================================================================================
Total params: 230528 (900.50 KB)
Trainable params: 230528 (900.50 KB)
Non-trainable params: 0 (0.00 Byte)
__________________________________________________________________________________________________

To reproduce:
import torch
import torch.nn as nn
import nobuco
from nobuco import ChannelOrder
from torchinfo import summary

pytorch_module = nn.TransformerEncoderLayer(128, 4, dim_feedforward=256, batch_first=True).eval()
#pytorch_module = nn.TransformerEncoderLayer(128, 4, dim_feedforward=256, batch_first=True).linear1.eval()
dummy_image = torch.rand(size=(1, 512, 128))

print(pytorch_module(dummy_image).mean())
print(summary(pytorch_module, dummy_image.shape))
keras_model = nobuco.pytorch_to_keras(
    pytorch_module,
    args=[dummy_image], kwargs=None,
    inputs_channel_order=ChannelOrder.TENSORFLOW,
    outputs_channel_order=ChannelOrder.TENSORFLOW
)

print(keras_model.summary())

Any idea why this could happen?

Whoa, great find. Turns out, nn.TransformerEncoderLayer hits a rare corner case which I did not foresee. Long story short, because the activation function was passed as a default argument (activation: Union[str, Callable[[Tensor], Tensor]] = F.relu), and also because TransformerEncoderLayer is not a part of some third-party package but torch itself, Nobuco failed to trace the activation. Hence, its output was orphaned and included into the graph as a constant tensor (WeightLayer). nn.Linear is not to blame.
Made a quick fix, should work fine in v0.11.7.

Thanks, it seems to have fixed the problem with the TransformerEncoderLayer.
However, I'm now running into small issue where buffers are registered as trainable parameters. Should I handle buffers differently?
Simple example:
import torch
import torch.nn as nn
import nobuco
from nobuco import ChannelOrder
from torchinfo import summary
import math

class Rotate2D(nn.Module):
    def __init__(self, theta=0.3) -> None:
        super().__init__()
        a = torch.Tensor([[math.cos(theta), -math.sin(theta)], [math.sin(theta), math.cos(theta)]])
        self.register_buffer('a', a)

    def forward(self, x):
        return torch.einsum('ij, ... j -> ... i', self.a, x)

pytorch_module = Rotate2D().eval()
dummy_image = torch.rand(size=(1, 100, 2))

print(pytorch_module(dummy_image).mean())
print(summary(pytorch_module, dummy_image.shape))
keras_model = nobuco.pytorch_to_keras(
    pytorch_module,
    args=[dummy_image], kwargs=None,
    inputs_channel_order=ChannelOrder.PYTORCH,
    outputs_channel_order=ChannelOrder.PYTORCH
)

print(keras_model.summary())

Try constants_to_variables=False. In the future I should somehow check whether the tensor is trainable or not.

Thanks! I'm very sorry, but I think I may have discovered another issue with Transformer layers. It looks like a stack of transformer layers constructed with TransformerEncoder only retains the Dense layers for the first TransformerEncoderLayer in the Stack.
Keras:
Total params: 199040 (777.50 KB)
Trainable params: 199040 (777.50 KB)

Pytorch:
trainable params: 264960 || all params: 264960

Difference: 264'960 - 199'040 = 65'920

Size of inverse bottleneck dense layers:
33024 + 32896 = 65'920

For n=3 layers, the parameter difference becomes 65'920*2 =131840, etc.
import torch
import torch.nn as nn
import nobuco
from nobuco import ChannelOrder

pytorch_module = nn.TransformerEncoder(
    nn.TransformerEncoderLayer(128, 4, dim_feedforward=256, batch_first=True).eval(),
    2)

dummy_image = torch.rand(size=(1, 512, 128))

print(pytorch_module(dummy_image).mean())
def print_trainable_parameters(model):
    trainable_params = 0
    all_param = 0
    for _, param in model.named_parameters():
        all_param += param.numel()
        if param.requires_grad:
            trainable_params += param.numel()
    print(
        f"trainable params: {trainable_params} || all params: {all_param} || trainable%: {100 * trainable_params / all_param:.2f}"
    )
keras_model = nobuco.pytorch_to_keras(
    pytorch_module,
    args=[dummy_image], kwargs=None,
    inputs_channel_order=ChannelOrder.TENSORFLOW,
    outputs_channel_order=ChannelOrder.TENSORFLOW
)

print(keras_model.summary())
print_trainable_parameters(pytorch_module)

I appreciate you perseverance! You just discovered a major bug: nobuco couldn't handle deepcopy. Like almost everything else, it traces the forward method of nn.Module via decorating. Decorated methods are stored in the class instance, so copy.deepcopy deepcopies them too. That means each copy's forward is bound to the original object, so both of them do the same computation. The bug is especially insidious as it breaks the original Pytorch model, and the debug log does not show any problems (all green). Anyways, fixed in v0.12.0 Good riddance.

Thanks @AlexanderLutsenko, the parameter counts match now. Fingers crossed that the results are the same, too! Thanks for all the help! :) I will close this issue now.

I appreciate you perseverance!

I'm just very eager to avoid having to do anything myself.


Console log errors on 2d tiles track

Commit:
Steps to reproduce

Open a matrix dataset
Switch to the 2d-tiles view. Move the view around.

Observed behavior

Console log errors:

Expected behavior

No console log errors.

Uhhh what's this flashy easy tag? :)
Do you know which track is behind 2d-tiles? Normally the mouseMoveZoom handle should work fine with HeatmapTiledPixiTrack


Possible problem with redirect logic

If my cluster is configured to have the following members:
localhost:1000, localhost:1001, localhost:1002
The following code will not redirect to the leader properly since the port that is used for the redirect is not the leader port:
internal Task Redirect(HttpContext context)
{
    if (context.Request.Path.StartsWithSegments(pathMatch, StringComparison.OrdinalIgnoreCase))
    {
        var leader = cluster.Leader;
        if (leader is null)
        {
            context.Response.StatusCode = StatusCodes.Status503ServiceUnavailable;
            return Task.CompletedTask;
        }
        else if (leader.IsRemote)
        {
            return redirection(context.Response, new UriBuilder(context.Request.GetEncodedUrl()) { Host = leader.Endpoint.Address.ToString(), Port = applicationPortHint ?? context.Connection.LocalPort }.Uri);
        }
    }

    return next(context);
}

should this not use something like the following?
new UriBuilder(context.Request.GetEncodedUrl()) { Host = leader.Endpoint.Address.ToString(), Port = leader.Endpoint.Port }.Uri)

The logic is correct. In embedded mode, Raft service endpoint shares the same port with main application. In hosted mode, Raft service endpoint uses separated port. Service endpoint is responsible for working with Raft RPC calls, which is black box to end user. API exposed via main endpoints by the application implementing high-level data access logic, such as data reads and writes, locks etc. Therefore, redirection works with application port.

The logic is correct. In embedded mode, Raft service endpoint shares the same port with main application. In hosted mode, Raft service endpoint uses separated port. Service endpoint is responsible for working with Raft RPC calls, which is black box to end user. API exposed via main endpoints by the application implementing high-level data access logic, such as data reads and writes, locks etc. Therefore, redirection works with application port.

This will only work assuming all nodes share the same port and have different IPs. Something that will indeed be universally true in any deployed environment. In a local environment, however, it is legitimate to host nodes on the same IP with a different port for each node, in which case this logic fails since it ends up rerouting to itself.

This will only work assuming all nodes share the same port and have different IPs. Something that will indeed be universally true in any deployed environment. In a local environment, however, it is legitimate to host nodes on the same IP with a different port for each node, in which case this logic fails since it ends up rerouting to itself.

When you deploying microservice, you assuming that it's configuration is identical for each hosting node except infrastructure. In case of Docker or Kubernetes it's true. Moreover, it's hard to write deployment scenario in Octopus or Ansible to have a different configuration for each instance of the same microservice. For local dev you still can use Kubernetes or Docker deployed locally or on virtual machine.
I don't see the reason to have some special support for loopback address because this configuration will not be relevant to any real production environment.

When you deploying microservice, you assuming that it's configuration is identical for each hosting node except infrastructure. In case of Docker or Kubernetes it's true. Moreover, it's hard to write deployment scenario in Octopus or Ansible to have a different configuration for each instance of the same microservice. For local dev you still can use Kubernetes or Docker deployed locally or on virtual machine.
I don't see the reason to have some special support for loopback address because this configuration will not be relevant to any real production environment.

If you still want to use local host as testing env then just register additional loopback interfaces. It's easily can be done on Linux or FreeBSD. Check this discussion as an example. Not sure about Windows, I'm not using it.

If you still want to use local host as testing env then just register additional loopback interfaces. It's easily can be done on Linux or FreeBSD. Check this discussion as an example. Not sure about Windows, I'm not using it.

I checked it on Windows, you can register additional Loopback Adapters through Control Pane as described here.

I checked it on Windows, you can register additional Loopback Adapters through Control Pane as described here.

From my point view, your dev and test environment should be close to the production environment to eliminate potential infrastructure problems during deployment.

From my point view, your dev and test environment should be close to the production environment to eliminate potential infrastructure problems during deployment.


Specific events causes error logs

I understand this is the current approach for handling events but I think it should end without a failure.

if present, the action will exit with a failing status code for any event that is not allowed.

This causes some confusion in the following scenario:
{
  event: [ 'issues.opened' ],
}

In GitHub we cannot specify to run an action on issues.opened we can only run an action on issues. This means that all the actions that run on issues are going to get an error log. Which causes confusion like seen in this issue: https://github.com/alex-page/add-new-issue-project/issues/3
✖  error     Event `issues.opened` is not supported by this action.

I think these actions should log with a neutral state if the user is using a specific action and they are using the parent event.
I can do a simple work around which is nice:
if( tools.context.payload.action !== 'opened' ){
  tools.exit.neutral( `Event ${ action } is not supported by this action.` )
}

Let me know if you think this is an issue, happy to close it if there is some functionality I don't understand or reasoning for this approach.

Thanks for opening this @alex-page 🙏 I see the issue here. This can be handled in user-land, but in a scenario where I want to act on pull_request.opened, it'd fail on any pull_request.synchronize - and post failure statuses to the same PR 👎  It'd be cool to do something like (pseudo-code):
const [eventName, action] = eventString.split('.')

// Standard wrong event
if (eventName !== GITHUB_EVENT_NAME) {
  exit.failure()
}

// Right event, but wrong action
if (eventName === GITHUB_EVENT_NAME && action && action !== payload.action) {
  exit.neutral()
}

I'm super swamped at the moment - if you're interested in a PR that'd be 🔥 🙏

I would love to help. I would like some clarity around this:

act on pull_request.opened, it'd fail on any pull_request.synchronize - and post failure statuses to the same PR 👎

The PR will get failing status checks when synchronise fires as it needs to exit the action with an error?

I think that's the behavior right now - if I make an Action with this:
new Toolkit({ event: 'pull_request.opened' })

workflow "Stuff" {
  on = "pull_request"
}

It will exit with a failure whenever I push the the PR (kicking off a pull_request.synchronize). It should instead exit neutral, otherwise it'll report a failing status. Does that help clarify things?

Yeah definitely, thanks @JasonEtco

I'm going to close this issue since the behavior is different in Actions v2. Thanks for opening!


How does one get to the web ui to see the results?

You'll need to run the sixpack-web dashboard as specified here.


Resolve visually the decimal numbers

Currently, we are displaying all decimal parts without much care about, and it generates a larger string
We need to apply any transformation on it to improve readability
Some suggestions:

Display only 2 (or 4) decimal numbers
Decrease the font-size of the decimal numbers

Maybe we can use the same solution of FiatCurrency, but it'll lose precision. At least we'll need to have a title={123.456789} as a last resource of precision


onResize method

Hi!
Have a problem, why onResize method doesn't work when I change size of window.Works just when load page.Responsive option - is true.

Please ask questions on StackOverflow: https://stackoverflow.com/questions/tagged/chart.js


travis: attempt to fix osx builds

travis builds for osx no longer work. some dependency broke. doesn't look like travis will be supporting py2.7.
this PR disables FLOSS builds for osx.

ref #293


Adding more Integration test

I noticed that there is only one file for test:- here. Can i add more test cases and datamocks ?

@Sonichigo Yes. Please. Thank you very much. Assigning this to you.

Thanks @paraswaykole !! I would be using go-test and keploy for datamocks and testcases. Would that be okay?

Interesting! Looking forward to reviewing your PR.


A new release?

Is there anything that blocks a new release now?
In particular I'm interested in https://github.com/paritytech/wasmi/issues/41

Hey! Before the release, we wanted to fix parity-wasm (see https://github.com/paritytech/wasmi/issues/37).
However, since the fix for parity-wasm most likely will be a patch release I guess we can publish wasmi before that...

Well, I realized my project isn't on crates.io. So I can stick with git version for now. No hurry.

btw, 0.1.0 has been released.


Backend game search doesn't work if both mainGame is false and year is null

If mainGame is false and year is undefined, a blank where clause will be passed to IGDB which is a 400


platformVersion: Add fallback for rolling release linux distros

On rolling release based Linux distros (at least on ArchLinux) getting the platform version from info.versionId fails. Looks like getting it from _p.version  is a meaningful fallback. On my system this prop contains Linux kernel version and build time  which gives you some idea about the system.

Thanks!


WIP: Retain sensitive context from resources to RAL properties

This is so gross it's actually kinda cool.

CLA signed by all contributors.


Rename declared.RootReconciler to RootScope

While ":root" does identify the resource manager named "root-reconciler" in the managed-by annotation, this constant is a Scope type, not a Manager type. So putting the right type in the name of the const should make the code a little easier to read.
Add help funcs for converting between the Scope and other related types, like the reconciler deployment name, sync kind, and sync namespace.

/hold
A few more changes coming.

/unhold
I added Scope.String() and Scope.Validate() and removed all the string casting I could find. This should make it clearer if the user wants the string value or the namespace value (same thing for RepoSyncs).

/lgtm

/retest
TestNoSSLVerifyV1Alpha1 seems flaky


[schema-stitching]: Alias arguments: Fields X conflict because they have differing arguments.

Now with #411 this query results in the correct response now:
{
  orders {
    itemTotal: total(category: TAXES) {
      amount
      currency
    }
  }
}

But as soon as you add a second alias with the same field and different arguments, new errors pop up.
This one works:
{
  orders {
    itemTotal: total {
      amount
      currency
    }
    taxesTotal: total {
      amount
      currency
    }
  }
}

But that one here does not:
{
  orders {
    itemTotal: total(category: ITEMS) {
      amount
      currency
    }
    taxTotal: total(category: TAXES) {
      amount
      currency
    }
    paymentTotal: total(category: PAYMENT) {
      amount
      currency
    }
    deliveryTotal: total(category: DELIVERY) {
      amount
      currency
    }
    netTotal: total(category: NET) {
      amount
      currency
    }
  }
}

Response is:
{
  "data": null,
  "errors": [
    {
      "message": "Fields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "orders"
      ]
    }
  ]
}

And this is the result when firing the same query directly to the proxied server:
{
  "data": {
    "orders": [
      {
        "itemTotal": {
          "amount": 5958,
          "currency": "CHF"
        },
        "taxTotal": {
          "amount": 441,
          "currency": "CHF"
        },
        "paymentTotal": {
          "amount": 0,
          "currency": "CHF"
        },
        "deliveryTotal": {
          "amount": 0,
          "currency": "CHF"
        },
        "netTotal": {
          "amount": 5958,
          "currency": "CHF"
        }
      },...

Ugly workaround at the moment:
{
  order {
    total(category: TAXES) {
      amount
      currency
    }
  }
  taxes: order {
    total(category: ITEMS) {
      amount
      currency
    }
  }
}

Should be fixed in #418.


nixos/nix-daemon: fix buildMachines eval

Motivation for this change
https://github.com/NixOS/nixpkgs/pull/139075#issuecomment-1023523898
cc @polykernel
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

And this is why we want static type checks

Sure, but we need tests too, and we can have tests today. The same can't be said about types for Nix.
As a reminder, an earlier project failed and the active project for typing Nix doesn't build on the Nix language.


Add caching for pip

Container-based builds allow to cache files. There is support
for caching pip files with cache: pip, but because of
https://github.com/travis-ci/travis-ci/issues/3239 it gets disabled
if .travis.yml provides own install section. Therefore adding
cached dir manually.

I don't see Travis kicking in to test that. Seems like #3262 needs to be merged first.

I don't see how that would help. Almost all of the dependencies are in the vendor/ dir, pip doesn't download them. It's compiling the C(++) libs that slows down our builds, we could try caching env/lib/python2.7/site-packages.

Needs to be redone on top of master.

How can I restore the branch to rebase on top?


community: add batch querying functionality for ChromaDB

Description: :
Chroma supports batch querying of documents but it's not possible in the langchain integration.
this PR allows users to perform either single or batch queries by providing a string or a list of strings to the query argument of the search function.

it works with: similarity_search, similarity_search_by_vector, similarity_search_by_vector_with_relevance_scores, similarity_search_with_relevance_scores, similarity_search_by_vector,  max_marginal_relevance_search, etc.

@baskaryan @hwchase17  I'm unsure how to resolve the lint errors, as the type hints seem accurate. :(


test ui elements

🚀 Deployment available! Here are the direct links to the updated files:

https://docs-getdbt-com-git-test-ui-elements-dbt-labs.vercel.app/docs/introduction

closing test pr


Create a contract defining common data structures

Issue To Be Solved
It would be helpful to have common data structure implementations in Cadence (stack, queue, linked list, binary trees, heaps, etc.)
Suggest A Solution
Contract that defines common data structures in their Cadence implementations. Even better if we can include benchmarks for use at scale so builders have reasonable expectation of their performance.

this 100%, actually we can have libraries; and some of them depending on usage, can graduate to stdlib.


A question on source code of tag:v0.1.0

Notice that tag:v0.1.0 uses the old file names and paths.
Is the source code of this repository tagged v0.1.0 the same as the one of https://github.com/openblockchain/obc-peer(tag:v0.1.0)?
Do you keep the updating on https://github.com/openblockchain/obc-peer(tag:v0.1.0)?
Thanks,

Yes, I believe it is https://github.com/openblockchain/obc-peer(tag:v0.1.0). A new tag will be created at some point in the future.


Drag and drop to open files is not working

Type: Bug
This is on Fedora 37.
If I drag a file from the file manager (Nautilus) onto the vscode window, it will not be opened (the drop is simply ignored).
VS Code version: Code 1.76.0 (92da9481c0904c6adfe372c12da3b7748d74bdcb, 2023-03-01T10:25:16.105Z)
OS version: Linux x64 6.1.14-200.fc37.x86_64
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
AMD Ryzen 9 3900X 12-Core Processor (24 x 4341)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
0, 0, 1

Memory (System)
31.26GB (25.86GB free)

Process Argv

Screen Reader
no

VM
0%

DESKTOP_SESSION
gnome

XDG_CURRENT_DESKTOP
GNOME

XDG_SESSION_DESKTOP
gnome

XDG_SESSION_TYPE
wayland

Extensions (7)

Extension
Author (truncated)
Version

toml
be5
0.6.0

vscode-markdownlint
Dav
0.49.0

rainbow-csv
mec
3.5.0

cpptools
ms-
1.14.4

rust-analyzer
rus
0.3.1418

code-spell-checker
str
2.18.0

vscode-lldb
vad
1.8.1

I don't know when this started but it used to work some time back.

sob., 4 mar 2023, 22:58 użytkownik Barugon @.***>
napisał:

I don't know when this started but it used to work some time back.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/176141#issuecomment-1454899640,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUUNXNCQAUSDCG7VLI5BV5DW2O3I7ANCNFSM6AAAAAAVPYV4TI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Same on Elementary OS

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

Screencast from 2023-04-15 13-35-39.webm

This happens on Wayland.

This sounds like a upstream issue to me then.

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

Merging to https://github.com/microsoft/vscode/issues/156723


Brushing README

The goal is to make the main README more structured and consistent.

/retest

/lgtm

/label qe-approved
/label px-approved

Darshan's LGTM
/label docs-approved

/lgtm

/retest


add grunt tasks to run tests automatically

Great, thank you! Would be extremely useful if you could also add Travis CI integration, though I realize that's a bit more work. I'm currently fairly swamped, otherwise I'd add it myself.


feat(qwik-city): allow customizing SVGO options of image plugin

Overview
Allow customizing SVGO options of image optimization plugin.

What is it?

[x] Feature / enhancement
[ ] Bug
[ ] Docs / tests / types / typos

Description
SVGO has a sensible defaults, which are used by qwik, but configurability from developer space is missing, and the default config can cause some unexpected results.
Use cases and why
For example, objects defined inside  can collide with each other, causing unexpected references to be loaded. See reproduction here: https://github.com/hbendev/qwik-svg-render-bug/tree/571a2057914b334a3a3220865868e85a7eb731c3.
These modifications allow the 'prefixIds' plugin to be used, and in turn, SVGO prefixes the ids with the svg file's name, making them all unique. See the issue resolved here: https://github.com/hbendev/qwik-svg-render-bug/tree/bf040e67ec2e618a8b778859fa78ffdf477371f7 (requires rebuliding qwik based on this source branch, and linking it to the reproduction package).
Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[x] Added new tests to cover the fix / functionality

There's a long discussion in SVGO about doing the above - making all ids unique - by default in SVGO-land, but using plugins is suggested there by the authors. In my opinion it's worth adding 'prefixIds' to qwik-city for all users by default, because here it's used for optimizing the files to be used specifically in browsers. I'm happy to do a follow-up PR for that, if you agree.

I suspect some of the examples listed in qwik's home page might be avoiding optimizing svgs using the custom ?jsx loader due this particular problem as well.

Nice, thanks!

@hbendev

In my opinion it's worth adding 'prefixIds' to qwik-city for all users by default, because here it's used for optimizing the files to be used specifically in browsers. I'm happy to do a follow-up PR for that, if you agree.

What is the real-world impact of this?

Hi @wmertens.
Here's a shortened quote from the above mentioned issue to quickly sum rationale behind the suggestion up.

SVGO when cleaning up IDs [...] does not have a concept of "other svgs" - which means if you minified 100 svgs, they would all end up having the id of 'a' which means they're next to useless to be embedded into webpages.

Since qwik is meant to be used to render webpages, and SVGO is used to optimize SVGs that are often rendered together, we should take care of generating unique references, instead of the users. By enabling the provided prefixId plugin, and passing the path of the file to SVGO (which I added in this PR), all ids would be unique as long as their file names are unique. I think it makes sense in most cases to assign different names to SVGs, so almost no-one would face this issue going forward. If one still has conflicts, they would still be able to work around this by extending the configuration further per the above modifications.
A very minor drawback is that all the inlined SVGs that use any variables via <defs /> would be a few bytes larger.
Again, here's a minimal reproduction: https://github.com/hbendev/qwik-svg-render-bug, or you can also see the issue using the SVG I used for the unit test.


Remove headers from overrideIOPSYaml

Fix: https://github.com/istio/istio/issues/21121

In response to a cherrypick label: new pull request created: #21919


youtube homapage shows：something went wrong

Is there an existing issue for this?

[X] I have searched the existing issues

Have you read the FAQ?

[X] Yes, I read the FAQ

Device info

iOS/iPadOS version:16.2
Device model:xsmax
Sideload tool (AltStore, SideStore, Sideloadly, TrollStore,...):trollstore
The specific version of YouTubeRebornPlus (latest or newest is NOT a version number!):v19.05.3 4.2.4

Describe the bug
the app was working fine till yesterday suddenly give this error,so decided to install pre release version and it work but can’t watch live, so give the latest release se v19.05.3 4.2.4 a new try but the error is still there
Steps to reproduce the issue

Open app
Error

Crash log (if the app crashes)
No response
Are you using the newest version of YouTubeRebornPlus? If not, why?
✅ Yes, I'm using the latest version of YouTubeRebornPlus right now
Does the issue happen with the official YouTube from AppStore?
❌ No, It doesn't
Additional context
No response

I am getting a similar issue. I am getting an error message saying “Error Loading. Tap to retry.” Nothing will work.

Older versions work fine.

Updating to the latest release, Latest Release
Seems to fix the issue on my end.


Documentation and test coverage for custom types

Describe the feature
Currently, the fct_documentation_coverage  and fct_test_coverage models require users to have a 'marts' model type/folder in their project. Otherwise, the associated test will return an error with a division by zero.
CTE in the model where 'mart' is hard-coded.
conversion as (
    select
        resource_id,
        case when is_described then 1.0 else 0 end as is_described_model,
        case when model_type = 'marts' then 1.0 else NULL end as is_marts_model,
        case when is_described and model_type = 'marts' then 1.0 else 0 end as is_described_marts_model

    from models
),

I would like to be able to override the baked-in value for fact models and customize is through the dbt_project.yml file, just as in case of  tests.
Describe alternatives you've considered
My first though is to keep it in a {{ var("mart_alias", "marts") }}, which can be driven via project config, but still has it's default value.
Additional context
This is a universal issue. It can also be the case that you (dbt Labs) want to enforce people using the same conventions, but still would be great to customize.
Who will this benefit?
It would benefit those who want to tailor the evaluator to fit their folder structure. Personally, I'm not able to see these coverage percentages without having a folder named 'mart'
Are you interested in contributing this feature?

Absolutely! Although I might need a hand in finding out the best way we can tackle this.

Good catch! I just opened a PR to loop through all model types (listed in the model_types variable in your dbt_project.yml file) and return a field for coverage for each model type. Let me know if that would solve your issue!

Looks good to me @graciegoheen! Thanks for the quick fix ⚡. I will also check the functionality no later than end of next week:)


fix fm last command

idk if I did this right but it works for me now

2021-04-17 16:55:26] [ERROR] red: Exception in command 'fm last'
Traceback (most recent call last):
  File "C:\Users\Jamie\Documents\pikachu-red\.venv\lib\site-packages\discord\ext\commands\core.py", line 85, in wrapped
    ret = await coro(*args, **kwargs)
  File "C:\Users\Jamie\Documents\red-stuff\lastfm-red\lastfm\lastfm.py", line 282, in last
    await self.listening_report(ctx, "week", name)
  File "C:\Users\Jamie\Documents\red-stuff\lastfm-red\lastfm\utils.py", line 309, in listening_report
    "dt": int(dt.timestamp()),
TypeError: 'int' object is not callable```

I get the following but it appears fine on what's currently on master. What was the issue beforehand?

I got this error, in addition to a few other bots in #testing
discord.ext.commands.errors.CommandInvokeError: Command raised an exception: TypeError: Invalid variable type: value should be str, int or float, got <bound method Arrow.timestamp of <Arrow [2021-04-09T00:00:00+00:00]>> of type <class 'method'>

What is your arrow version? I'm wondering if they changed something and that's why it works for some people but not others.

Yeah, updating to latest Arrow fixed the issue.

Thanks for the PR :D


docs: Clarify/decide on what goes into docs/*.rst and what - into module docstrings

When reading https://ppci.readthedocs.io/en/latest/reference/codegen/registerallocator.html , I was surprised that corresponding .rst file is almost empty: https://github.com/windelbouwman/ppci-mirror/blob/master/docs/reference/codegen/registerallocator.rst , and the contents comes fully from the corresponding .py module, https://github.com/windelbouwman/ppci-mirror/blob/master/ppci/codegen/registerallocator.py
It doesn't seem that this pattern is followed consistently, e.g. Peephole doc has quite a bunch of content in .rst: https://github.com/windelbouwman/ppci-mirror/blob/master/docs/reference/codegen/peephole.rst
So, would be nice to decide which way to do it is the best, and follow it.

An idea here may be that having a docstring for module giving an overview of module is not a bad idea. But stuffing too much content there, e.g. introductory material on the topic, instead of the info pertinent to specific module implementation, may be not ideal, such a content is better suited for .rst.
(Oh, and btw, thumbs up for having such an introductory content. It's unclear if PPCI would find its good niche. But if it is, chances that this niche will include being a learning tool for people interested in topics on compilation. And having already pretty good introductory/reference content is :+1: ).


documentation: inprecise description of the return value of HTTP serve functions

What version of Go are you using (go version)?
go version go1.10.3 darwin/amd64
In net.http package, there are following fucntions/methods related to serve HTTP:

http.Serve
http.ListenAndServe
http.ListenAndServeTLS
http.Server.Serve
http.Server.ListenAndServe
http.Server.ListenAndServeTLS

Except the first one, all docs for those functiosn/methods say something like always returns a non-nil error. But if such a function/method is terminated by a signal which is a common way to terminate a HTTP server, it will not return. For example, consider the following go code http.go:
package main

import (
	"log"
	"net/http"
)

func main() {
	var srv http.Server
	srv.Addr = ":12345"

	if err := srv.ListenAndServe(); err != http.ErrServerClosed {
		log.Printf("http error: %s", err)
	}
}

A SIGINT signal will terminate the program and http.ListenAndServe will not return.
➜  local go run http.go
^Csignal: interrupt

Only if srv is teriminated by Server.Shutdown,  srv.ListenAndServe will return.
I think that the descripion always returns a non-nil error should mention this behaviour. Otherwise, people will tend to write the following code:
	err = (&http.Server{Handler: rc.transport.Handler()}).Serve(ln)
	select {
	case <-rc.httpstopc:
	default:
		log.Fatalf("raftexample: Failed to serve rafthttp (%v)", err)
	}

They are hoping that Serve will return. But it will not since Shutdown is not used in a way descripted in Shutdown's example code.

I think "always" is a description of the "non-nil" quality of the error as opposed to a description of the "return" of the error. But perhaps there's a way to phrase it with less ambiguity,

Perhaps the sentences could be reworded, like:

The returned error will always be non-nil.

Yep, it just says that the returned error will always be non-nil. It does not say anything about the scenarios in which the function will return. Seems clear enough to me, but maybe we can be more explicit.
/cc @bradfitz

I've sent a small CL above with the proposed change.
More broadly, I've filed #26268 to look into all the other cases of "always returns X" in the standard library.

Closing, just like #26268. See Russ's point there. We didn't reach consensus, and it doesn't look like we found a wording that was considerably better.


Add Pinkt to the Community section

Pinkt is a well established Android app which serves as an unofficial client for Pinboard for over 5 years. Version 3.0 has finally introduced support for Linkding and most of its features, and the app is now ready to be used as an unofficial client for Linkding too.

Thanks!


The motor / encoder arrangement on Proto Bot is backwards

The WPI library expects the motors and motor encoders to be arranged a certain way, but the arrangement on Proto Bot is said to be backwards.  The result is that the robot forward / backward motion is oriented backwards.  More details are needed, and a specification is required before we begin design work during the next build season.

Should we rearrange the motors and controllers so that they are arranged
in the proper way on proto bot.   What are the other details that we are
missing or specifications we are missing?
On Wed, Nov 8, 2017 at 3:36 PM Chad Stryker<EMAIL_ADDRESS>wrote:

The WPI library expects the motors and motor encoders to be arranged a
certain way, but the arrangement on Proto Bot is said to be backwards. The
result is that the robot forward / backward motion is oriented backwards.
More details are needed, and a specification is required before we begin
design work during the next build season.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cwstryker/SteelRidge/issues/7, or mute the thread
https://github.com/notifications/unsubscribe-auth/AWNAip3RQYvv4_ZBZT4K0nSXpurZZa9xks5s0jsEgaJpZM4QXNhG
.

--
Jeff Brink
Physical Science
Physics, Chemistry
Steel Ridge Robotics
Ridgefield High School


pcel:loading makes client integration tests to hang

Hello,
I found that window.pleaseWait() function from pcel:loading https://github.com/pcel/meteor-loading/blob/master/lib/please-wait.js makes client integration tests to load forever, but i cant find any error in the log.
[velocity] Mirror detected - Not adding velocity core
[velocity] Not adding mirror-registry because NODE_ENV is development  and IS_MIRROR is true
[velocity-mirror] Mirror is initializing...
[proxy-package-sync] Mirror detected - Not adding code
[velocity-mirror] Mirror started. Connecting via DDP to parent
[velocity] Mirror connected to parent. Registering mirror...
LISTENING
[velocity-mirror] Mirror is ready.

You may find the error in the browser console when you navigate to your app (or the mirror directly).

Now it's working O_o


x/tools/gopls: show optimization information from the compiler

@dr2chase has recently added functionality to the compiler to produce diagnostic information about which optimizations were not performed.
gopls doesn't run the compiler, so we can't integrate this information easily, but as a starting point, we can have the user run this as a command. My thinking is that the user manually executes the command, which under the hood runs the compiler with the correct flags and publishes diagnostics with the output. The main issue is - how long should these diagnostics last? With our current architecture, the next time the user types a character, these diagnostics will automatically clear.
More information can be found on https://golang.org/cl/206658/.

This feature has been implemented as of https://golang.org/cl/243119 and will be available in gopls/v0.5.0.


Added examples to test tapping on overflowed Views to RNTesterApp

Summary
By default, Views in React Native have overflow: visible. When a child view is outside of the parent view's boundaries, it's visible on Android, but not tappable. This behaviour is incorrect, and doesn't match iOS behaviour.
#26374 and #29039 both fix this. @shergin suggested:

Can we start from decoupling the example from this diff for quick landing? We think we solved this issue in Fabric on iOS and Android, and the test will be very helpful to verify that.

This change does that.
Changelog

[Internal] [Added] - Added examples to test tapping on overflowed Views to RNTesterApp
Test Plan
Added tests to RNTesterApp. Here are the current results of testing on Android:

master
With #29039
With #26374

@shergin does this work on Fabric?

@shergin does this work on Fabric?


Fitting functions for XSVS

closed and reopened to force travis to use the new master branch that has lmfit pinned to 0.8.3 on travis

:+1: modulo the concerns about the names.

lgtm


Chore/dependencies 2022 06 13

Description of change
This PR contains this week's dependabot updates.
Checklist

[ ] If this is a releasable change, has a news fragment been added?

Explanation
A news fragment is required for any releasable change (i.e. code that runs in or affects production) so that a corresponding changelog entry is added when releasing.
Check changelog/README.md for instructions.

[ ] Has this branch been rebased on top of the current develop branch?

Explanation
The branch should not be stale or have conflicts at the time reviews are requested.

[ ] Is the CircleCI build passing?

General points

Other things to check

Make sure fixtures/test_data.yaml is maintained when updating models
Consider the admin site when making changes to models
Use select-/prefetch-related field lists in views and search apps, and update them when fields are added
Make sure the README is updated e.g. when adding new environment variables

See docs/CONTRIBUTING.md for more guidelines.

When I looked at the opensearch upgrade last week https://github.com/uktrade/data-hub-api/blob/develop/docs/Dependabot.md said that
If the OpenSearch version has been updated, the version used by [the e2e tests](https://github.com/uktrade/data-hub-frontend/blob/master/docker-compose.e2e.backend.yml#L48) needs to be updated to match.
but I couldn't get the tests running in my local machine. Did you have more luck?

@marijnkampf this only updates the client library, the OpenSearch version has not changed, so that should be fine.


Remove forced calibration if no calibration data available

Closes #19
Removes the forced calibration if the user sets should_calibrate to false and no calibration is stored in flash. If no calibration is loaded, users are issued a warning and all closed-loop control modes are disabled.
This should mostly help internal dev - removing the requirement to run a calibration to test the boards.

@stilsota Requesting a test from you on some fresh boards to make sure this is working as expected.

This appears to be working and build tests are passing. Merging into dev.


Symbol change for BitCurrency

BitCurrency (BTCR) is now symbol BC
https://bitcointalk.org/index.php?topic=3369654.msg40915825#msg40915825
Cheers!

It appears that BitCurrency is still seen as BTCR according to the cryptocompare API, which means the change in symbol request should be sent directly to them, so that this list will pick up on the change automatically.

RealBank(RBT)


[WIP] refactor: detector architecture, split to own files

To avoid all these if-else cases to check for which detector to use I propose that we split up those to own detector objects and use some kind of factory to use them. This way it would be really easy to add another 4:th detector in the future instead of putting in more logic.
I think it'll be easier to maintain if the architecture goes this direction
This is just an initial proposal/commit for how the recognize feature could look like, and before refactoring further please add some feedback/thoughts.
The interesting part is really the difference in recognize.util.js where we just replace the detector-switching logic and actual axios-calls with a one-liner
What do you think about it @jakowenko ?

I really like the direction you're going with this. I've been working on some local changes to include object detection support too, but would like to help you work on this detector refactor before I add in any more changes.

npm-watch is actually using nodemon under the hood, I just like the way watch is configured in package.json, but go with nodemon if you prefer that :)
Keeping nodemon local/global keeps makes one less dependency for the project though
I didn't have the time to go through other parts of the application yet, but I also started looking into saving images with face < CONFIDENCE to an unmatched directory.
If you'd like to we can merge this into your beta-branch and then you can continue from there? I suspect you put more time into this than I am so if you'd like to prioritize it maybe its better you take over this. Still want to be able to contribute from time to time

Good to know about npm-watch. I noticed it was using nodemon when I was testing it out, just don't have a lot of experience with it, so I will look into it a bit more.
Merging into beta sounds good to me! Thanks for updating that. I'll try to get this merged in this evening.

I'll take a look at what would be involved to save unmatched faces to an unmatched directory too. That makes perfect sense and would make it easier to retrain the models with these faces if no match is found.

I'll take a look at what would be involved to save unmatched faces to an unmatched directory too. That makes perfect sense and would make it easier to retrain the models with these faces if no match is found.

I have a branch here might be useful, not sure if this is the best place to put the code though.  https://github.com/erikarenhill/double-take/tree/feat/save_unmatched_for_training

Feel free to open another WIP PR if you'd like, or I can just copy over the changes directly if that's easier for you. Looks like you only touched that one file. I agree with your TODO's in it. I wanted to move the logic of saving the files outside of the polling function, but this should suffice for now. I can work on refactoring that logic after.

Do you think all faces that aren't matched should be saved? Compreface seems to always return one of the names it was trained with even if there's a really low confidence score so the logic you had would work for that detector. But, Facebox and DeepStack will return a boolean if a face is found but no match is found from the model.
I think saving all non matched faces is ideal. I will need to update normalize function to take in all the results and then filter out the unmatched ones for saving. Right now any faces that aren't matched from Facebox or DeepStack are removed from the current array.
I'll try to take a closer look at this logic tomorrow.


chainId changed unexpected while upgrading 0.19rc to 0.20

Description
模拟测试chainId 为3，0.19rc 链，升级0.20。检测是否出现 chainId 异常，操作脚本如下：
https://gist.github.com/ouwenkg/dc7825ed58cd02d3bad4548f59226b3f
Output:
1. Prepare 0.19rc envionoment(compiled from 0.19rc tag)
2. Change default chainId(modify chainId setting in scripts/)
3. Run 0.19rc chain firstly
Initializing chain from provided state
INFO:cita.block	Block pre-sealed, 2162077 quota used
INFO:cita.chain	Adding to head head=4c29c1f1
Saved 3 address change logs
INFO:cita.chain	Added block 1 (4b0d01cf) with 1 txs and 2162077 quota
INFO:cita.block	Block pre-sealed, 2357091 quota used
INFO:cita.chain	Adding to head head=4b0d01cf
Saved 2 address change logs
INFO:cita.chain	Added block 2 (dd235979) with 1 txs and 2357091 quota
INFO:cita.block	Block pre-sealed, 1035750 quota used
INFO:cita.chain	Adding to head head=dd235979
Saved 2 address change logs
INFO:cita.chain	Added block 3 (f6c5e1b7) with 1 txs and 1035750 quota
INFO:cita.block	Block pre-sealed, 2073590 quota used
INFO:cita.chain	Adding to head head=f6c5e1b7
Saved 2 address change logs
INFO:cita.chain	Added block 4 (1011324d) with 1 txs and 2073590 quota
INFO:cita.block	Block pre-sealed, 2657330 quota used
INFO:cita.chain	Adding to head head=1011324d
Saved 2 address change logs
INFO:cita.chain	Added block 5 (8552ed0f) with 1 txs and 2657330 quota
INFO:cita.block	Block pre-sealed, 2942019 quota used
INFO:cita.chain	Adding to head head=8552ed0f
Saved 2 address change logs
INFO:cita.chain	Added block 6 (922b6742) with 1 txs and 2942019 quota
INFO:cita.block	Block pre-sealed, 4292430 quota used
INFO:cita.chain	Adding to head head=922b6742
Saved 2 address change logs
INFO:cita.chain	Added block 7 (e55700d6) with 1 txs and 4292430 quota
INFO:cita.block	Block pre-sealed, 2292209 quota used
INFO:cita.chain	Adding to head head=e55700d6
Saved 2 address change logs
INFO:cita.chain	Added block 8 (a2a2b059) with 1 txs and 2292209 quota
INFO:cita.block	Block pre-sealed, 2359465 quota used
INFO:cita.chain	Adding to head head=a2a2b059
Saved 2 address change logs
INFO:cita.chain	Added block 9 (72a2f3bb) with 1 txs and 2359465 quota
INFO:cita.block	Block pre-sealed, 2050168 quota used
INFO:cita.chain	Adding to head head=72a2f3bb
Saved 2 address change logs
INFO:cita.chain	Added block 10 (4a5b1af3) with 1 txs and 2050168 quota
INFO:cita.block	Block pre-sealed, 2659328 quota used
INFO:cita.chain	Adding to head head=4a5b1af3
Saved 2 address change logs
INFO:cita.chain	Added block 11 (c317e46a) with 1 txs and 2659328 quota
INFO:cita.block	Block pre-sealed, 2618514 quota used
INFO:cita.chain	Adding to head head=c317e46a
Saved 2 address change logs
INFO:cita.chain	Added block 12 (46e738a3) with 1 txs and 2618514 quota
INFO:cita.block	Block pre-sealed, 221810 quota used
INFO:cita.chain	Adding to head head=46e738a3
Saved 2 address change logs
INFO:cita.chain	Added block 13 (bcf35358) with 1 txs and 221810 quota
INFO:cita.block	Block pre-sealed, 2524998 quota used
INFO:cita.chain	Adding to head head=bcf35358
Saved 2 address change logs
INFO:cita.chain	Added block 14 (e5bff93a) with 1 txs and 2524998 quota
INFO:cita.block	Block pre-sealed, 115435 quota used
INFO:cita.chain	Adding to head head=e5bff93a
Saved 2 address change logs
INFO:cita.chain	Added block 15 (1ff2a43a) with 1 txs and 115435 quota
INFO:cita.block	Block pre-sealed, 1166769 quota used
INFO:cita.chain	Adding to head head=1ff2a43a
Saved 2 address change logs
INFO:cita.chain	Added block 16 (69b2e9d9) with 1 txs and 1166769 quota
INFO:cita.block	Block pre-sealed, 1235457 quota used
INFO:cita.chain	Adding to head head=69b2e9d9
Saved 2 address change logs
INFO:cita.chain	Added block 17 (4370dae0) with 1 txs and 1235457 quota
INFO:cita.block	Block pre-sealed, 1193520 quota used
INFO:cita.chain	Adding to head head=4370dae0
Saved 2 address change logs
INFO:cita.chain	Added block 18 (b971947a) with 1 txs and 1193520 quota
INFO:cita.block	Block pre-sealed, 2184514 quota used
INFO:cita.chain	Adding to head head=b971947a
Saved 2 address change logs
INFO:cita.chain	Added block 19 (d0aadb49) with 1 txs and 2184514 quota
INFO:cita.block	Block pre-sealed, 2185090 quota used
INFO:cita.chain	Adding to head head=d0aadb49
Saved 2 address change logs
INFO:cita.chain	Added block 20 (04d5ebcd) with 1 txs and 2185090 quota
INFO:cita.block	Block pre-sealed, 2185218 quota used
INFO:cita.chain	Adding to head head=04d5ebcd
Saved 2 address change logs
INFO:cita.chain	Added block 21 (1cf713a2) with 1 txs and 2185218 quota
INFO:cita.block	Block pre-sealed, 2185410 quota used
INFO:cita.chain	Adding to head head=1cf713a2
Saved 2 address change logs
INFO:cita.chain	Added block 22 (cccd082e) with 1 txs and 2185410 quota
INFO:cita.block	Block pre-sealed, 2247435 quota used
INFO:cita.chain	Adding to head head=cccd082e
Saved 2 address change logs
INFO:cita.chain	Added block 23 (623cf081) with 1 txs and 2247435 quota
INFO:cita.block	Block pre-sealed, 2215147 quota used
INFO:cita.chain	Adding to head head=623cf081
Saved 2 address change logs
INFO:cita.chain	Added block 24 (b0e5253f) with 1 txs and 2215147 quota
INFO:cita.block	Block pre-sealed, 2246987 quota used
INFO:cita.chain	Adding to head head=b0e5253f
Saved 2 address change logs
INFO:cita.chain	Added block 25 (1520f76b) with 1 txs and 2246987 quota
INFO:cita.block	Block pre-sealed, 2184834 quota used
INFO:cita.chain	Adding to head head=1520f76b
Saved 2 address change logs
INFO:cita.chain	Added block 26 (0d206e12) with 1 txs and 2184834 quota
INFO:cita.block	Block pre-sealed, 2185026 quota used
INFO:cita.chain	Adding to head head=0d206e12
Saved 2 address change logs
INFO:cita.chain	Added block 27 (c3a5acea) with 1 txs and 2185026 quota
INFO:cita.block	Block pre-sealed, 2247051 quota used
INFO:cita.chain	Adding to head head=c3a5acea
Saved 2 address change logs
INFO:cita.chain	Added block 28 (3ecaf08c) with 1 txs and 2247051 quota
INFO:cita.block	Block pre-sealed, 2184834 quota used
INFO:cita.chain	Adding to head head=3ecaf08c
Saved 2 address change logs
INFO:cita.chain	Added block 29 (8b35c85e) with 1 txs and 2184834 quota
INFO:cita.block	Block pre-sealed, 2215339 quota used
INFO:cita.chain	Adding to head head=8b35c85e
Saved 2 address change logs
INFO:cita.chain	Added block 30 (599941da) with 1 txs and 2215339 quota
INFO:cita.block	Block pre-sealed, 2184898 quota used
INFO:cita.chain	Adding to head head=599941da
Saved 2 address change logs
INFO:cita.chain	Added block 31 (4a1e3438) with 1 txs and 2184898 quota
INFO:cita.block	Block pre-sealed, 2185090 quota used
INFO:cita.chain	Adding to head head=4a1e3438
Saved 2 address change logs
INFO:cita.chain	Added block 32 (1f02f36f) with 1 txs and 2185090 quota
INFO:cita.block	Block pre-sealed, 2247115 quota used
INFO:cita.chain	Adding to head head=1f02f36f
Saved 2 address change logs
INFO:cita.chain	Added block 33 (e64ca02c) with 1 txs and 2247115 quota
INFO:cita.block	Block pre-sealed, 2184834 quota used
INFO:cita.chain	Adding to head head=e64ca02c
Saved 2 address change logs
INFO:cita.chain	Added block 34 (66475af6) with 1 txs and 2184834 quota
INFO:cita.block	Block pre-sealed, 2185026 quota used
INFO:cita.chain	Adding to head head=66475af6
Saved 2 address change logs
INFO:cita.chain	Added block 35 (6333f705) with 1 txs and 2185026 quota
INFO:cita.block	Block pre-sealed, 2185026 quota used
INFO:cita.chain	Adding to head head=6333f705
Saved 2 address change logs
INFO:cita.chain	Added block 36 (6c03becb) with 1 txs and 2185026 quota
INFO:cita.block	Block pre-sealed, 2215467 quota used
INFO:cita.chain	Adding to head head=6c03becb
Saved 2 address change logs
INFO:cita.chain	Added block 37 (37709434) with 1 txs and 2215467 quota
INFO:cita.block	Block pre-sealed, 2185026 quota used
INFO:cita.chain	Adding to head head=37709434
Saved 2 address change logs
INFO:cita.chain	Added block 38 (18a1e828) with 1 txs and 2185026 quota
INFO:cita.block	Block pre-sealed, 2184834 quota used
INFO:cita.chain	Adding to head head=18a1e828
Saved 2 address change logs
INFO:cita.chain	Added block 39 (ddbe372b) with 1 txs and 2184834 quota
INFO:cita.block	Block pre-sealed, 2185282 quota used
INFO:cita.chain	Adding to head head=ddbe372b
Saved 2 address change logs
INFO:cita.chain	Added block 40 (fd30db1e) with 1 txs and 2185282 quota
INFO:cita.block	Block pre-sealed, 2185026 quota used
INFO:cita.chain	Adding to head head=fd30db1e
Saved 2 address change logs
INFO:cita.chain	Added block 41 (22b29eb6) with 1 txs and 2185026 quota
INFO:cita.block	Block pre-sealed, 2184834 quota used
INFO:cita.chain	Adding to head head=22b29eb6
Saved 2 address change logs
INFO:cita.chain	Added block 42 (a7dd5acf) with 1 txs and 2184834 quota
[sudo] wpf 的密码：
ok
===> Check height
{
  "jsonrpc": "2.0",
  "result": "0x3",
  "id": 1
}
===> Check chainId
{
  "jsonrpc": "2.0",
  "result": {
    "operator": "test-operator",
    "website": "test-chain",
    "tokenAvatar": "https://avatars1.githubusercontent.com/u/35361817",
    "chainId": 3,
    "economicalModel": 0,
    "blockInterval": 3000,
    "chainName": "test-chain",
    "tokenSymbol": "NAC",
    "version": 0,
    "validators": [
      "0x49dc4bd69bd57930454e401f79b00ead8dc70ba7"
    ],
    "genesisTimestamp":<PHONE_NUMBER>833,
    "tokenName": "Nervos AppChain Test Coin"
  },
  "id": 1
}
4. Stop 0.19rc node
ok
/home/wpf/working/github/ouwenkg/bearshell
5. Swap binary
===> Use bft-wal
===> Restart the node
ok
/home/wpf/working/github/ouwenkg/bearshell
===> Check height
{
  "jsonrpc": "2.0",
  "result": "0x3",
  "id": 1
}
{
  "jsonrpc": "2.0",
  "result": "0x5",
  "id": 1
}
6. Amend two step
===> amend the code of group management
{
  "id": 4,
  "jsonrpc": "2.0",
  "result": {
    "hash": "0xb8656c5e6aa48e0f3358a8a6d99c23494a8171c0cf6fbca9f8d2e0675e703e50",
    "status": "OK"
  }
}
===> amend the authorizatioin
{
  "id": 4,
  "jsonrpc": "2.0",
  "result": {
    "hash": "0x75dde42dac9983c9e04d933fcb288e58cd343d165ec516b58a50b140494deed9",
    "status": "OK"
  }
}
7. Protocol upgrade
省略部分输出

8. Set version
{
  "id": 4,
  "jsonrpc": "2.0",
  "result": {
    "hash": "0x6ead6c5d3a8b801a6052e18622bd76a2aba4bfc650cafc78b06681f88b24a41b",
    "status": "OK"
  }
}
9. Check getMetaData again
{
  "jsonrpc": "2.0",
  "result": {
    "tokenSymbol": "NAC",
    "operator": "test-operator",
    "economicalModel": 0,
    "tokenAvatar": "https://avatars1.githubusercontent.com/u/35361817",
    "chainIdV1": "0",
    "chainName": "test-chain",
    "genesisTimestamp":<PHONE_NUMBER>833,
    "blockInterval": 3000,
    "tokenName": "Nervos AppChain Test Coin",
    "website": "https://www.example.com",
    "validators": [
      "0x49dc4bd69bd57930454e401f79b00ead8dc70ba7"
    ],
    "chainId": 3,
    "version": 0
  },
  "id": 1
}

Versions
0.19 rc， 0.20
结论
一整套操作下来，没有异常情况。试了下 step 6 执行失败，出现了问题：chainId 由 3 变为 1

@kaikai

After the Protocol upgrade, Why the version of metadata is still 0?

Maybe i should wait 5s after set version, i will try again.

After the Protocol upgrade, Why the version of metadata is still 0?

There is a bug about getMetadate in this version.  In cli, we can get normal result, i.e. version = 1

There is a bug about getMetadate in this version.

What bug? RPC? Why is cli normal?

Missing the amend_system_contracts operation.

Should check the chainIdV1 at the version 1, while the getMetaData interface did not show the chainIdV1  field。

The real reason:
The script amend_sys_cont_to_v0-20(amend_system_contacts) is missed a chainId param. it's default to amend it to 1.
the code:
https://github.com/cryptape/cita/blob/v0.20/scripts/amend_sys_cont_to_v0-20.py#L141-L142


Lab-11-deploy-azure-database-using-template: replace copy activity by an auto-type

Module: 06
Lab/Demo: 11
Task: Deploy an Azure SQL Database
Step: 03
Description of issue
Suggest replacing the copy by auto-type functionality:

Copy functionality is not working even I used the "Type Clipboard Text" option offered by Skillable.

Thanks for your submission.
The module [Configure automatic deployment for Azure SQL Database] is on the queue to be released, including a new lab profile and instructions for this lab.


fixed issue with alpha value and loss combination in warmup baseline

fixes #51
simply updating the alpha value inside the if epoch < self.n_epochsstatement suffices to ensure self.alpha<=1 all the time.
Also, fixes the combination of baseline losses as described here

Thanks a lot, I think this is how I intended it! However I really don't understand as the code seems to have worked for me (and many others) previously.


Error in installing awsiot

I am trying to install awsiot on yocto build for Rpi4b
I added below line to local.conf -
IMAGE_INSTALL_append = "aws-iot-device-sdk-python-v2 python3-pip"
I am facing below error -
ERROR: Nothing RPROVIDES 'aws-iot-device-sdk-python-v2' (but /home/...../poky/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'aws-iot-device-sdk-python-v2' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['aws-iot-device-sdk-python-v2']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'aws-iot-device-sdk-python-v2']
I have a recipe under meta-openembedded/meta-python/receipes-devtools/python named "aws-iot-device-python_1.4.8.bb"
I am new to yocto. Any help will be much appreciated. Thank you

Hi Neal,
Were you able to add the meta-aws layer to your bblayers.conf file?
It also appears that you are on an older release. If you have nothing else tying you to that release, we recommend using a newer one such as Kirkstone.

Hi Nate,
I do not have a meta-aws layer. this python3-aws-iot-device-sdk-python_1.4.8.bb file is under meta-openembedded/meta-python/recipes-devtool/python.

Ah, I see. I think the issue is that they do not have the -v2 recipe. You should add python3-aws-iot-device-sdk-python to your image or add our layer and use the v2 recipe.

could you please guide me how can i add your layer to use the v2 recipe. Apologies if this is a dumb question but I am new to this and trying to learn.

Sure. If you are using Poky you can use bitbake-layers after activating your build environment to add the dependency layers and meta-aws to your layer config.
git clone -b $RELEASE https://git.yoctoproject.org/poky
git clone -b $RELEASE https://git.openembedded.org/meta-openembedded
git clone -b $RELEASE https://github.com/aws4embeddedlinux/meta-aws.git

. ./poky/oe-init-build-env build

bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-openembedded/meta-python
bitbake-layers add-layer ../meta-openembedded/meta-networking
bitbake-layers add-layer ../meta-openembedded/meta-multimedia
bitbake-layers add-layer ../meta-aws

Where $RELEASE Is the yocto release you are using.
Your conf/bblayers.conf file should then have a variable BBLAYERS that lists all the layers.
Then add to your config (conf/local.conf):
(dunfell or later)
IMAGE_INSTALL:append = "aws-iot-device-sdk-python-v2"

Before dunfell:
IMAGE_INSTALL_append = "aws-iot-device-sdk-python-v2"

We do recommend using more recent releases if possible.

Let us know if you need any more help


Bump UI package version

You have to update the version of the appservice package so that we can release this.
I suggest 0.58.1 -> 0.59.0. I'm somewhat iffy on whether or not a breaking change in a dependency (ui) means a breaking change for this package (appservice), but better to be safe I guess


Add API for configuring whether ShardingSphere cache the metadata of the same sharding tables at startup

Add API for configuring whether ShardingSphere cache the metadata of the same sharding tables at startup.
Question
Many users will pay more attention on performance at startup, and the metadata of the sharding-tables are mostly the same. So add a cache can reduce startup time.
Therefore we will add API to make user decide to cache metatata or not.

duplicate with #1688

It is not a duplicate question with #1688. I means the sharding tables of the same logical table all have the same table structure, so we don't need to load the table structure of each table from the database. we can cache the table structure of the same logical table and therefore reducing the startup time.


Floats are being converted to String

Floats in swagger spec are being converted to String in graphql.
Steps to reproduce:
npx swagger-to-graphql --swagger-schema=swagger_schema.yaml > ./types.graphql
swagger_schema.yaml
swagger: "2.0"
info:
    version: 1.1.0
    title: Test server
basePath: /api/v1
host: localhost
paths:
    /user/{id}:
        get:
            operationId: getUserId
            tags:
                - users
            produces:
                - application/json
            parameters:
                - name: id
                  in: path
                  description: User Id
                  required: true
                  type: integer
                  format: int64
            responses:
                200:
                    description: A User Response
                    schema:
                        $ref: "#/definitions/UserResponse"
definitions:
    UserResponse:
        type: object
        required:
            - userId
        properties:
            userId:
                type: integer
                format: int64
            userName:
                type: string

Expected output:
type Query {
  getUserId(id: Float!): UserResponse!
}

type UserResponse {
  userId: Float!
  userName: String
}

Actual output:
type Query {
  getUserId(id: String!): UserResponse!
}

type UserResponse {
  userId: String!
  userName: String
}

Same here with int return type
       "WorkflowCaseId": {
          "format": "int64",
          "type": "integer"
        }

Gets back
type WorkflowCaseIdentifier {
  WorkflowCaseId: String
}

Any remedy?

@0xR Any reason to convert Int64 to String https://github.com/yarax/swagger-to-graphql/blob/master/src/typeMap.ts#L52?

The JavaScript number type doesn't have enough accuracy to represent a 64 bit integer. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
It's safer to stick to a int32 on your backend. In Java an int would be 32 bit and a long would be 64 bit.

Thanks @0xR for the clarification 👍


If path parameter is an encoded URL, the request is not routed correctly

What version of Hono are you using?
4.1.0
What runtime/platform is your app running on?
Node.js
What steps can reproduce the bug?
Add this to the route:
app.get('/entity/:id', async (c, next) => {
  console.log(c.req.param('id'));
  return c.json({});
}

And do HTTP GET /entity/https%3A%2F%2Ftest.com%2F123
That route handler will not be called.
What is the expected behavior?
It should print https://test.com/123 on the console
What do you see instead?
Nothing in the console, and 404 response
Additional information
The string passed to id parameter is generated using encodeURLcomponent('https://test.com/123') so I believe it should be treated just like a path component as a whole instead of being parsed before the route matching.
If I add a middleware to log the req.path, it will print /entity/https:/test.com/123.

Hi @alvinsw
I can't reproduce it. It prints https://test.com/123 correctly. Can you check it again to make sure it works?

Sorry my bad. I just traced it further and just found that it is caused by Nginx!! I am closing the issue.

@alvinsw Ah, Nginx!! No problem!


Issue Linking of rule '//tensorflow/python:_pywrap_tensorflow.so' failed while building

I have added a new Op kernel in "user_ops" folder of "tensorflow" source directory. I have also written a test to verify if the Op is successfully implemented. But while building and testing my Op kernel using the command, "bazel test //tensorflow/user_ops:xxxx_test", I am getting the following error:
Linking of rule '//tensorflow/python:_pywrap_tensorflow.so' failed: gcc failed: error executing command /usr/bin/gcc -shared -o bazel-out/local-py3-fastbuild/bin/tensorflow/python/_pywrap_tensorflow.so -Wl,--version-script tensorflow/tf_version_script.lds -pthread -Wl,-no-as-needed -B/usr/bin -B/usr/bin ... (remaining 9 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
I am unable to build and test my new Op kernel. Please help in resolving this issue as I am blocked because of this error.

Please provide more information (see the template for issue submission). OS? Python Version? Does /usr/bin/gcc exist? What version? What version of bazel? Thanks.

Closing due to lack of activity.


[Feature] Add --show-events support in describe collector

Problem Statement
Add --show-events support in describe collector.
Solution Description
Add ShowEvents field in describe struct and take it into consideration in the collect package.
Alternatives
No response
Additional Context
No response
Slack discussion
No response
Research

[X] I have searched other issues in this repository and mine is not recorded.

@eddycharly events are already shown in the do you want to turn them off

do you want to turn them off

yup, it's true by default but can be set to false.

    --show-events=true:
	If true, display events related to the described object.


Fix install_package_at_version matcher to work with single symbol actions

Awesome - thanks guys. I've merged the content matching changes and template convenience method.
For getaroom/chefspec@dabff2ace8737d3d0c8e76b0ac0df229aa2506d3 do you have an example (and Ruby / Chef versions) where install_package_at_version was broken? I can't reproduce.

We were executing the test against Chef 0.10.4 on Ruby 1.9.2 and we got "NoMethodError: undefined method `include?' for :foo:Symbol".
package "monit" do
  version "5.1.1"
end


[Addition]: Location spoofed miners in my area.  Only communicate with each other. (only pisces miners in area)

Hotspot b58 Addresses
112un27NV55KKZHjUHw7Bu8ZE4VqEPtn1Y8YsKJ76kKdtJAxL9wP
11Rgg9uigN5UL9H2YqW2ADSKN7AsmMfoLjmapTpm6iLt95xtcaP
112bMnpTfg7VexVqFHopQjw6mYjYcDZTBWTFhG1dDraAbMGzrYd1
11GVQxNxKTrY5tGKVJsuscB5gYBEQ1Jnd4JPb7sZbXibecinn7d
112JF7VUCuTTErAxfYpthkQzSBpVCmch4wQKmXN2pZbZM95T7D7L
112MCoGwZWN1MM3KaARKxg7YhqnahDtaVCXi55ahzubuYHZyrPrY
11NhYd3dXeKzYxW5zK8jsMWAKdNaK5v7i9zUPh4fRgYL2myd7SD
112pUrayYhBZd8zDb7CdCwAmBaMvGkVKCrKMsttrwVqE13AtNHqo
Discord Handle
BadLag#0935
Reason(s)
These miners are "located" in an area where I have 15+ miners within a few miles, and none of the miners I've installed have witnessed any of these 8.  Many of my miners have upgraded antennas mounted outdoors at 30+ ft of elevation.  2 of the miners in question share a hex with miners of mine.  These 8 miners only communicate with each other.  All 8 of them are also, coincidentally, Pisces brand miners.
If you would like to see the miners in my wallet and their coverage, here is my wallet address: 13JZ3YQnGSZnr3xjJEN7dRUfSoktKEzRspSFU8o5ZdXZ25gRvTs

This does seem to be a clear cluster.

I can confirm the addresses:
112JF7VUCuTTErAxfYpthkQzSBpVCmch4wQKmXN2pZbZM95T7D7L
112bMnpTfg7VexVqFHopQjw6mYjYcDZTBWTFhG1dDraAbMGzrYd1
112MCoGwZWN1MM3KaARKxg7YhqnahDtaVCXi55ahzubuYHZyrPrY
112pUrayYhBZd8zDb7CdCwAmBaMvGkVKCrKMsttrwVqE13AtNHqo
112un27NV55KKZHjUHw7Bu8ZE4VqEPtn1Y8YsKJ76kKdtJAxL9wP
11GVQxNxKTrY5tGKVJsuscB5gYBEQ1Jnd4JPb7sZbXibecinn7d
11NhYd3dXeKzYxW5zK8jsMWAKdNaK5v7i9zUPh4fRgYL2myd7SD
11Rgg9uigN5UL9H2YqW2ADSKN7AsmMfoLjmapTpm6iLt95xtcaP


Performance issue in ListView

Hi, I am developing with Xamarin Forms. As for a ListView with lots of images (about 10 image in each cell), it suffers from scrolling lag. Note, I have done all the optimization for the ListView to speed it up (include recycle cell strategy). After some experiments, I find the bottleneck is the image loading process. When I scroll the ListView up or down, image source of the recycled view cell will be updated. Then it will cause a short pause. This impose a serious influence on the user experience. So, how to fix this problem? (I thought the visited image will be cached automatically, hence there should not be any performance issue when I scroll back to show the images before, what's wrong? )

All loaded images are cached by default.
It's probably something with your layout design. It's hard to tell without any sample reproduction.
Another tip for fast cells: don't use bindings, use cell's OnBindingContextChanged override.

The layout design is all right. Experiment shows that this issue will occur only when I change the binding image source for every view cell. I will try to remove bindings and put everything in OnBindingContextChanged.

Hi, I haven't solved this problem yet. To make things clear, I am showing my code now. I test on a Nexus 5.0 with Android 6.0.

Here is the ListView config:

Here is the ListView code:

Here is the ViewCell code
public class PostViewCell : ViewCell
{
private List<CachedImage> _collections;
  public PostViewCell()
  {
      _collections = new List<CachedImage>()
      {
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          },
          new CachedImage()
          {
              Aspect = Aspect.AspectFill,
              HorizontalOptions = LayoutOptions.Fill,
              VerticalOptions = LayoutOptions.Fill,
              CacheDuration = TimeSpan.FromDays(30),
              TransparencyEnabled = false,
          }
      };

      var grid = new Grid()
      {
          HorizontalOptions = LayoutOptions.Fill,
          VerticalOptions = LayoutOptions.Fill,
          RowSpacing = 10,
          ColumnSpacing = 10,
          HeightRequest = 300,
          Margin = new Thickness(0, 20, 0, 0)
      };
      grid.RowDefinitions.Add(new RowDefinition() {Height = GridLength.Star });
      grid.RowDefinitions.Add(new RowDefinition() {Height = GridLength.Star });
      grid.RowDefinitions.Add(new RowDefinition() { Height = GridLength.Star });
      grid.ColumnDefinitions.Add(new ColumnDefinition() {Width = GridLength.Star});
      grid.ColumnDefinitions.Add(new ColumnDefinition() {Width = GridLength.Star});
      grid.ColumnDefinitions.Add(new ColumnDefinition() {Width = GridLength.Star});

      int index = 0;
      for (int i = 0; i < 3; i++)
      {
          for (int j = 0; j < 3; j++)
          {
              Grid.SetRow(_collections[index], i);
              Grid.SetColumn(_collections[index], j);
              grid.Children.Add(_collections[index]);
              index++;
          }
      }

      View = grid;
  }

  protected override void OnBindingContextChanged()
  {
      foreach (var image in _collections)
      {
          image.Source = "https://farm9.staticflickr.com/8625/15806486058_7005d77438.jpg";
      }
  }

}

Problem
As you can see, each cell own 9 images. When the BindingContext changed, I simply reassign the image source. Then a scroll lag will occur. Note I use the same image url for all CachedImages just for test.

I have the same problem with my ListView. The scroll lags happen when the image is loaded or OnBindingContextChanged is called.

Any solutions or suggestions?

There's a new prerelease (2.1.8) nuget which contains some fixes / enhancements. One of them is ability to set maximum concurrent image loading tasks through config (SchedulerMaxParallelTasks property). You could try it and tune FFImageLoading to your needs. https://github.com/luberda-molinet/FFImageLoading/commit/9687b42eb1664c4b6b78b1008244fc1fb7a48875

I will fully debug this problem these days and give the result soon.

2.1.8-pre-150 nugets released. It contains many Android stability & performance fixes. Do you still experience it? If you do, please reopen this issue.


alternate style support for formatter [atkenny15]

Invitation for @atkenny15 to express style differences from current Verible implementation.
Reference: https://github.com/MikePopoloski/slang/issues/291
Useful information:

An existing style guide would be great
Examples of desirable formatting

Verible also does linting for SV code so I am wondering as how this project is different?

Not sure if I'm understanding the question, but linting and formatting are different operations.  Linting is read-only analysis, while formatting is transformative.  They are no doubt related when it comes to rules of style.

What I mean is, this project verible does linting and formatting, so why do we need the new project slang used for?

The slang project includes full semantic analysis, type checking, elaboration, but the Verible project still lacks those.


WARNING_MSG conflicts with SQL Lab

If WARNING_MSG is set in the config, the view in SQL Lab breaks, meaning that the header overlaps with the warning message.
Maybe WARNING_MSG can be moved into the very top header, between the menu and the right icons?

i've noticed that too, fix here: https://github.com/airbnb/caravel/pull/1312


MWPW-105258 - Milo Gnav

Ported Helix Gnav back into Milo
Supports LocalNav, small nav, medium nav, and large nav.
Supports IMS login and admin console links
Made gnav search extensible
Added support for locale contentRoot
Re-architected codeRoot and contentRoot for better consumer support

Resolves: MWPW-105258
Test URLs:
Before:

Blog
Business Blog

After:

Blog
Business Blog

Other test URLs:

Milo
Stock

@seanchoi-dev,  First off, fantastic work!!! This looks sleek and awesome.  l just found a few issues when viewing the Adobe Stock and Milo test URLs provided above on different browsers as shown and described below:

Firefox is wonky with the gnav, see my screenshot.

Safari also has a similar issue as Firefox does with rendering issues.

for the milo URL you provided on Safari the Adobe icon to the far right isn’t showing up but the link is there when I hover over it.

The last question I had was about the adobe stock test page.  When you click on the search icon it darkens out the background but only if there isn’t an image.  So the main banner still shows up regular and the card tiles as well instead of everything behind the search bar being darkened like it is on all the other adobe sites.  Was this intentional or requested?
Oh and if you scroll down the page the search bar drop-down scrolls down the page instead of being sticky at the top with the navigation like all other adobe sites.  Just wondering if that is a requested feature from Adobe Stock or not.

oh, one last thing sorry…The bottom border on the top navigation still shows up when you click on the search icon, all other adobe sites remove it when the search icon is pressed.


[BUG] Failed to create the reconcile looper: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded

Describe the bug
reconciler failure was reported when we tried to scale in/out pods.
reconciler job scheduled for every 5 minutes but failed to execute with the given error -
[error] failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded.
[error] failed to create the reconcile looper: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded
[verbose] reconciler failure: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded.
Current Behavior
the deployment of pod replicas to 500, the same for ippam podreferences. But when we scale in replicas to 1, pods are scaled successfully but 130 podreferences are left. I did 2 series of scale in/out and then release uninstall and redeployment - the same issue every time: 130 podreferences left undeleted after scale in.
To Reproduce
Steps to reproduce the behavior:

the deployment of pod replicas to 500, the same for ippam podreferences.
But when we scale in replicas to 1, pods are scaled successfully but 130 podreferences are left.
Do these 2 series of scale in/out and then release uninstall and redeployment - the same issue every time: 130 podreferences left undeleted after a scale in.

Environment:

Whereabouts version : 0.6.2
Kubernetes version (use kubectl version): N/A
Network-attachment-definition: N/A
Whereabouts configuration (on the host): N/A
OS (e.g. from /etc/os-release): N/A
Kernel (e.g. uname -a): N/A
Others: N/A

Additional info / context
Add any other information / context about the problem here.

@dougbtv kindly check this issue.

Got a respone from @dougbtv, get suggestion to disable overlapping IP addresses. We are checking if this issue can be fixed by disabling it.
https://github.com/k8snetworkplumbingwg/whereabouts/tree/master#overlapping-ranges

@dougbtv @andreaskaris
We are using the overlapping ip ranges feature for the k8s storage backend and disabling it will not serve our goal. I think this is a proper bug which needs your attention and help to overcome the issue.

I would like to explain the issue here in steps for better view:

IPs are stored as the ippools CRD of whereabouts, There is an overlapping IP ranges CRD used to store all IPs.[Which creates 1 object for each IP]
The issue is when reconciler code tries to fetch all the objects in under the overlappingipranges. When the number of IPs grows, the number of overlappingipranges objects grow(one for each IP)
Reconciler on the initialization of the the first executor objects tries to list all objects under the overlappingipranges CRD, and hits a context-deadline.

Link of the code where we get the error: code

if it's related to timeout we can fix it in 2 ways:

Increase timeout
Add pagination to ListOptions, I have created PR with this fix(https://github.com/k8snetworkplumbingwg/whereabouts/pull/438) @dougbtv please check. It should not affect any current workflows.

/cc @manuelbuil
Hi, We are facing this issue for longtime and couldn't find a fix or workaround to this issue. Would you please take a look of this issue?

Hi all, I am coming from k8s sig-scalability to help you with fixing this issue.
Error client rate limiter Wait returned an error: context deadline exceeded indicates that there were many requests issued at the same time and they were throttled on client-side (nothing do to with k8s itself).
This particular PR: https://github.com/k8snetworkplumbingwg/whereabouts/pull/438 won't really help, it will even make things probably worse, as you will be issuing more calls.
So how it works:

client-go rate-limits qps of requests - default is 5 qps
I am guessing you are issuing a batch of requests (probably 1 per pod in this case?), which are queued in client-go. So with 500 requests and 5 qps, it will take 100 seconds for them to finish
Then you also issue List request that is added to the end of requests queue with some timeout on context, but because you already have 100s worth of waiting requests in queue and also set timeout, it receives context deadline exceeded client rate limiter Wait returned an error: context deadline exceeded. So essentially that request doesn't even reach k8s control plane and times out on client-side, just like the error states rate limiter Wait ...  context deadline exceeded

Timeout that you now setting in the context, is not just requests timeout, but timeout for the sum of "waiting in a queue" and "request timeout".
If you want to have a timeout for request only, you can specify it by setting TimeoutSeconds in meta.v1.ListOptions instead.
For List operations, I would recommend setting the timeout mentioned above to 1 minute, as the official SLO for List requests states 30s for 99% of requests: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/api_call_latency.md#definition
(this SLO is just for requests, not waiting in queue).
On a high-level design, I would recommend not using List at all and use informer instead.
Hope this helps :crossed_fingers:

Hi @smoshiur1237, I'll work on this.

I might fix the issue for 500 pods but as I mentioned in your pr, we have a customer reporting this issue with 100 nodes and 30k pods. I'll explore other options and let you know.

@smoshiur1237, I don't believe this issue can be solved by increasing the request timeout. Also, the reconciler job doesn't make a batch of requests before listing the cluster wide reservations. What it does is to list the pods and ip pools.
The root of the issue is that the this reconciler job is expected to finish in 30 seconds. A context is created with this time and is used as parent for contexts of all requests. So, in large clusters, this parent context expires by the time it has to list the cluster wide reservations. If you check the logic for listing pods, it uses the same time that was set for the parent (30s).
What I'm gonna do is remove this parent context and use 30 seconds for all listing operations (supported by what @marseel mentioned above the SLO). All other type of requests will continue using the RequestTimeout value (10s). I will also use pagination for listing pods and cluster wide reservations.

@smoshiur1237, @adilGhaffarDev, could you please share complete logs of the reconciler when this issue happens?

@mlguerrero12  here is the original logs that we got initially on this issue from a running whereabouts pod logs, where I have trimmed similar kinds of instances to make it visible :
2023-10-27T11:50:38Z [debug] the IP reservation: IP: x:y::1:2c is reserved for pod: bat-t1/cnf-complex-t1-2-stor-rwo-0
2023-10-27T11:50:38Z [debug] pod reference bat-t1/cnf-complex-t1-2-stor-rwo-0 matches allocation; Allocation IP: x:y::1:2c; PodIPs: map[x.y.1.44:{} x:y::1:2c:{}]
2023-10-27T11:50:38Z [error] failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded
2023-10-27T11:50:38Z [error] failed to create the reconcile looper: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded
2023-10-27T11:50:38Z [verbose] reconciler failure: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded
2023-10-27T11:55:00Z [verbose] starting reconciler run
2023-10-27T11:55:00Z [debug] NewReconcileLooper - inferred connection data
2023-10-27T11:55:00Z [debug] listing IP pools
2023-10-27T11:55:37Z [debug] Added IP x.y.1.130 for pod bat-t1/cnf-complex-t1-1-dpdk-0
2023-10-27T11:55:37Z [debug] Added IP x.y.1.112 for pod bat-t1/cnf-complex-t1-1-dpdk-0
2023-10-27T11:55:37Z [debug] the IP reservation: IP: x:y::1:25 is reserved for pod: bat-t1/cnf-complex-t1-1-stor-rwo-1
2023-10-27T11:55:37Z [debug] pod reference bat-t1/cnf-complex-t1-1-stor-rwo-1 matches allocation; Allocation IP: x:y::1:25; PodIPs: map[x.y.1.37:{} x:y::1:25:{}]
2023-10-27T11:55:37Z [error] failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded
2023-10-27T11:55:37Z [error] failed to create the reconcile looper: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded
2023-10-27T11:55:37Z [verbose] reconciler failure: failed to list all OverLappingIPs: client rate limiter Wait returned an error: context deadline exceeded

Opened a new issue to track pod reference problem:
https://github.com/k8snetworkplumbingwg/whereabouts/issues/483


Spark job parameters

Spark job parameters should be handled via a configuration file. For instance, LogParserJob could read its parameters from a config file log-parser.yml located in the conf directory.

implemented in 0.9.4


Fix binders that need to be wrapped in parens

Fixes #7. I also fixed a similar issue with exprCase and binderTyped

Thanks!