_bias_correction forces recompilation of integer_pow

This might be related to #197, but I don't have enough knowledge to confirm it.
In short, while using optax with flax.linen, optimizer.update forces jit-recompilation of the integer_pow jax primitive.
I get these results on a GPU backend.
from functools import partial
import jax
import jax.numpy as jnp
import optax
from flax import linen as nn
from jax.config import config
import os

config.update("jax_log_compiles", 1)
os.environ["TF_CPP_MIN_LOG_LEVEL"] = "0"

def biascorrection_recompilation_test():
    class M(nn.Module):
        @nn.compact
        def __call__(self, x):
            x = nn.Dense(1)(x)
            return x

    m = M()
    o = optax.adam(0.025, b1=int(1))

    input_array = jnp.ones((8,), dtype=float)
    params = m.init(jax.random.PRNGKey(0), input_array)
    opt_state = o.init(params)

    m_forward = jax.vmap(m.apply, in_axes=(None, 0))

    @jax.jit
    @partial(jax.value_and_grad, has_aux=True)
    def loss_fn(params, x, y):
        params_m = params
        y_m = m_forward(params_m, x)
        loss = jnp.mean(y_m - y ** 2)
        return loss, ()

    for i in range(1000):
        print(i)
        inputs = jax.random.normal(jax.random.PRNGKey(i), (32, 8))
        outputs = jax.random.normal(jax.random.PRNGKey(-i), (32, 8))
        (loss, aux), grads = loss_fn(params, inputs, outputs)
        updates, opt_state = o.update(grads, opt_state)
        params = optax.apply_updates(params, updates)

if __name__ == "__main__":
    biascorrection_recompilation_test()

At each i:
WARNING:absl:Finished tracing + transforming prim_fun for jit in 0.00016188621520996094 sec
WARNING:absl:Compiling prim_fun<PHONE_NUMBER>89792 for args (ShapedArray(float32[], weak_type=True),).
WARNING:absl:Finished XLA compilation of integer_pow in 0.02527928352355957 sec

Where prim_fun refers the integer_pow op at this line:
https://github.com/deepmind/optax/blob/b4aa6657bbf79985279dea76eaf6d53b25d7e8d9/optax/_src/transform.py#L105
#329 does remove the issue by replacing the call tointeger_pow with pow, but I am not sure this is the direction you would like to take.

Hello @epignatelli,
I am not totally sure why the recompilation is happening on every step (for integer pow) - although, this should not happen if you jit the the full update function, and apply that jitted function in every loop iteration.
e.g.
def update_fn(params, inputs)

    @partial(jax.value_and_grad, has_aux=True)
    def loss_fn(params, x, y):
        params_m = params
        y_m = m_forward(params_m, x)
        loss = jnp.mean(y_m - y ** 2)
        return loss, ()

    (loss, aux), grads = loss_fn(params, inputs, outputs)
    updates, opt_state = o.update(grads, opt_state)
    params = optax.apply_updates(params, updates)
    return params

update_fn = jax.jit(update_fn)

for i in range(1000):
    print(i)
    inputs = jax.random.normal(jax.random.PRNGKey(i), (32, 8))
    outputs = jax.random.normal(jax.random.PRNGKey(-i), (32, 8))

@hbq1 suggests that the recompilation for interger_pow may be happening because the exponent is a static argument for integer pow. This would be because more efficient algorithms exist when the exponent is a known integer.
Does the above help?

Indeed, the docs state that the exponent in integer_pow is a fixed integer.

(I just checked, and this is not related to #197 as much as I wish it were.)

HI @rosshemsley, thanks for the directions! And apologies for the delayed response, I have been away.
I tested the code with a fully jitted update function.
The main difference for the purpose of recompilation is that when jitting the update function count is a Traced<ShapedArray>, instead of a DeviceArray.
Some details:

Exponentiation for DeviceArray hits the lax.integer_pow primitive.
Exponentiation for Traced<ShapedArray> hits the jax.core.Tracer.__rpow__ primitive.

On a different note, when not jitting the full update function, recompiling integer_pow at each iteration seems more expensive than calling pow.
Computational times for this function, five runs and 1000 iterations per run, measures in seconds.

Branch
Avg
Std
1
2
3
4
5

master
72.08428
2.1065526
68.44841027259827
71.01362156867981
73.1131432056427
73.90358185768127
73.94265246391296

#329
3.465429
0.3372677
4.1398454
3.29095
3.2909377
3.3082917
3.2971206

def biascorrection_recompilation_test():
    class M(nn.Module):
        @nn.compact
        def __call__(self, x):
            x = nn.Dense(1)(x)
            return x

    m = M()
    o = optax.adam(0.025, b1=int(1))

    input_array = jnp.ones((8,), dtype=float)
    params = m.init(jax.random.PRNGKey(0), input_array)
    opt_state = o.init(params)

    m_forward = jax.vmap(m.apply, in_axes=(None, 0))

    @jax.jit
    @partial(jax.value_and_grad, has_aux=True)
    def loss_fn(params, x, y):
        params_m = params
        y_m = m_forward(params_m, x)
        loss = jnp.mean(y_m - y ** 2)
        return loss, ()

    start = time.time()
    for i in range(1000):
        print(i)
        inputs = jax.random.normal(jax.random.PRNGKey(i), (32, 8))
        outputs = jax.random.normal(jax.random.PRNGKey(-i), (32, 8))
        _, grads = loss_fn(params, inputs, outputs)
        updates, opt_state = o.update(grads, opt_state)
        params = optax.apply_updates(params, updates)
    print(time.time() - start)

Guys, any idea on the status of this?

@epignatelli is this issue still relevant or should we close it?

Hi @hbq1 -- sorry for the big delay.
Let me re-test this today and will get feed back into the conversation.

@hbq1 I can confirm that the behaviour w/o fully jitting the update function is still the same, i.e., xla is recompiling pow_integer of any new exponent.
If we fully jitted update function and follow the same benchmark above, we get the following results, in seconds.
On master:

Runs [1.8947148323059082, 1.6692390441894531, 1.6632952690124512, 1.666994333267212, 1.6678147315979004]
Mean 1.7124115
Mean excluding first hit 1.6668358
Std 0.091172755
Std excluding first hit 0.0021962684

On https://github.com/deepmind/optax/pull/329:

Runs [1.9085335731506348, 1.6419365406036377, 1.6377665996551514, 1.657588243484497, 1.6615831851959229]
Mean 1.7014817
Mean excluding first hit 1.6497186
Std 0.1039175
Std excluding first hit 0.010076091

Results are quite similar, although, the issue w/o jitting reimans, and jitting the full update function might not depend on the user in some cases.

Thanks @hbq1, I just reopened #329 in case you decide to merge up.

Hi @epignatelli, it tuned out that casting the denominator to t.dtype resulted in numerical instabilities in half-precision arithmetic, so your original PR was rolled back. We came up with a different solution that solves both issues, see #448.

Hi @hbq1, so sorry about this -- the solution makes very much sense.
Thanks very much for pinging me!


Clear exception from editor based on cursor location

I'd like to be able to remove result of evaluation of the row the cursor is on. Especialy in case of exceptions. And do that using keyboard only.
As mentioned here
in my stack overflow question
I'd like to achieve the same thing you can already do with mouse right button and choosing "remove exception" or "remove result" in the context menu over evaluation results like that very long one in the picture
As far as I know, in 0.8.1. you can either save or do as Scott Bauer suggested in the SO post and use Eval: Clear inline results command by adding [:editor "pmeta-i" :clear-inline-results] into User keymap.
That works, but clears all results, instead of just the desired one.

The resulting command/behavior for this enhancement should be added to eval.cljs


missing architectures on 'full version' tags

I'm using the "patch version" tags (5.85.2) to pull docker images in a multi-arch build.
But these tags are missing some architectures (arm64 for example).
You can see it here: https://hub.docker.com/_/ghost/tags
while 'latest', '5.85' and '5' all have amd + arm builds, the '5.85.2' tag does not.
This breaks my multi-arch build as seen here: https://github.com/remcoros/ghost-startos/actions/runs/9615892103/job/26524160498#step:4:142
I'm temporarily working around it by using the '5.85' tag, but prefer to pin it to the exact version.
edit: actually, I think the 5.85.2 version of Ghost doesn't have a container build and tagged for arm64.

The arm64 variant is probably being built right now

Thanks, I see more arm builds appearing now. Guess I am too quick updating 🤣


assemble shader source incrementally + fix duplicate shaderblocks

This patch makes multiple point lightsources work. The issue was actually the additional '\n' inserted in addSourceBlock..

Why was the extra line breaking the shader?
On Saturday, September 26, 2015, Hannes Janetzek<EMAIL_ADDRESS>wrote:

This patch makes multiple point lightsources work. The issue was actually
the additional '\n' inserted in addSourceBlock..
You can view, comment on, or merge this pull request online at:
https://github.com/tangrams/tangram-es/pull/308
Commit Summary

assemble shader source incrementally + fix duplicate shaderblocks

File Changes

M core/src/gl/shaderProgram.cpp
https://github.com/tangrams/tangram-es/pull/308/files#diff-0 (105)
M core/src/gl/shaderProgram.h
https://github.com/tangrams/tangram-es/pull/308/files#diff-1 (3)
M core/src/scene/light.cpp
https://github.com/tangrams/tangram-es/pull/308/files#diff-2 (21)

Patch Links:

https://github.com/tangrams/tangram-es/pull/308.patch
https://github.com/tangrams/tangram-es/pull/308.diff

—
Reply to this email directly or view it on GitHub
https://github.com/tangrams/tangram-es/pull/308.

@bcamper I've pushed the small fix only: https://github.com/tangrams/tangram-es/commit/5aa31503e5eed4ae6cf65aac48b5902aa5c842e4

Ah, thanks, I see, was just wondering why the \n caused a problem, I see
now.
On Sunday, September 27, 2015, Hannes Janetzek<EMAIL_ADDRESS>wrote:

@bcamper https://github.com/bcamper I've pushed the small fix only:
5aa3150
https://github.com/tangrams/tangram-es/commit/5aa31503e5eed4ae6cf65aac48b5902aa5c842e4
—
Reply to this email directly or view it on GitHub
https://github.com/tangrams/tangram-es/pull/308#issuecomment-143576729.


Pvb/codeaction/api

Add CodeAction API

Please add this to the tsserver, you will need to define a new request and response kinds in server\protocol.d.ts, and add a handler for it in server\session.ts

Changes to tsserver are done by @sarangan12 will create a PR when this is checked in.


Remove go vet download as it's included in the latest go binaries

Source: https://github.com/golang/tools/blob/master/README

Build script has been fixed, please rebase so CI testing can re-run.

Thanks @marcosnils -- anything that speeds up the build is great.
+1 once I see a green build.

@otoolep rebased. waiting for build to pass.

I'll close and re-open it


Display scanner versions in Scan Report Web App

At the moment, one cannot see which version of e.g. ScanCode was used for a scan when looking at the Scan Report Web App. It would be great, if this information was displayed in the about information (or maybe in the component information, if it makes more sense because they could be scanned with different versions when using a db?)
It looks like this information is already available in the scan-result.yml

I doubt that this can be done on a global level as you suggested in the about information, because the scanner version used for each of each package might differ if a scanner storage is being used.
That's why the scan-result.yml stores this information in the provenance data of each package.
Having that in mind, it might be possible to display this information in the details of each package.


Fix matrix usage on pbr sheen roughness

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/14912/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14912/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14912/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/14912/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/14912/merge
https://gui.babylonjs.com/?snapshot=refs/pull/14912/merge
https://nme.babylonjs.com/?snapshot=refs/pull/14912/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/14912/merge#BCU1XR#0

WebGL2 visualization test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14912/merge/testResults/webgl2playwright/index.html

Visualization tests for WebGPU (Experimental)
Important - these might fail sporadically. This is an optional test.
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14912/merge/testResults/webgpuplaywright/index.html


Can't change item when a modifier is already on there, or item is leveled

I try to add a modifier and that goes all well. But even when it comes to that...I can't figure out how to replace it. I've tried but it said Error, need one or more modifiers (1 more) every time I try replacing a part on my tool.

You're trying.. to replace a modifier? That's not possible.

I'm getting the same thing, but the original wording of the issue is a bit weird.  What is being said is that when you swap parts without a modifier on the tool at all, you're fine.  However, if a modifier is present on the tool and you try to swap parts, as shown in my image below, you get an error.  I tested this with a new tool as well to throw out changing config mid play-through and it produces the same result.  The tool provided has 2 modifiers gained from levels, one being used by the obsidian plate.  I have not tested with any other modifiers applied to the tool.

Not sure if there is a mod conflict or not.  Running both 1.10.2 versions of each mod.

Update for 1.12.2; issue is still happening.
Config is set to 0 (so they start with 0 modifiers), and if a mod is added to a tool, then the tool can never have a part swapped out cause of the error message.

This actually is a TiC issue, which checks if modifiers are still valid when replacing a toolpart. However to do so it requires free modifiers (it just checks on the new tool, it doesn't actually consume the free modifiers). If it's set to 0, it always fails. I'll see to have this fixed in TiC.


Added Math Magicians React App Setup

In this milestone of the Math Magicians project :

the development environment for the Math Magicians React application was setup.
create React App was used to create the React application
linter errors were fixed
gitflow was followed correctly
clear and professional documentation was written
best practices for JavaScript were followed
node.js was installed on the machine

Thank you for reviewing this pull request.

Thank you @DuaneDave ! Have a great week!


Class to create metrics from predict

Make a Class to create metrics like f1, confusion matrix, ROC AUC from predict results

Finally, instead of a class of metrics, create an evaluate method. With the VisionClassifier instantiated, it is possible to obtain the metric indicated by the user. Example:
vc = VisionClassifier(
   model_name="vit_huge_patch14_224_in21k",
   num_classes=2,
   task="single_label",
)

vc.evaluate(data, "accuracy")

Which metrics would you support for .evaluate()? Note that as in sklearn, for a classifier we could have metrics that would return a numeric array based on pure predictions from predict()  (e.g., accuracy), but we could also have probabilistic metrics that would require a predict_proba() beforehand.
And things get even trickier for multiclass problems...

Right now we are going to standardise to metrics that accept y_true and y_pred as pure predictions 1D array. However, we are open to suggestions, what metrics that require probabilities would you like to see?


[INFRA] Improve usage of the r-lib action

Replace custom configuration and bash script by lib-r action

ℹ I have check the logs to ensure we still run the same checks
The only difference is that, now we don't see
* checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
Maintainer: ‘Celine Souchet<EMAIL_ADDRESS>
This is because the actions set _R_CHECK_CRAN_INCOMING_ to false (see https://github.com/r-lib/actions/blob/v2.2.1/check-r-package/action.yaml#L32). As this is an informational message and we have dedicated checks of the source package that runs afterwards, this is ok.


Switch to GitHub actions

Switch from Jenkins pipeline to GitHub actions.
Example test run in my fork is green 💚: https://github.com/StefanScherer/docker-install/runs/442976093

ping @thaJeztah happy with that move to GH actions? 😸


Update schema enduserids

What are the schemas that are affected by the issue
enduserids
identity
namespace
What are examples of products that are impacted by the issue
platform xdm tooling

Can you clarify how the schema should be updated?

See PR here: https://github.com/adobe/xdm/pull/114

introduce two new schemas identity and namespace
remove the patternProperties and call out the fields explicitly like below:

"properties": {
"https://ns.adobe.com/experience/mcId": {
"title": "Adobe Marketing Cloud Id",
"$ref": "https://ns.adobe.com/xdm/context/identity",
"description": "A unique identifier from Adobe Marketing Cloud."
},
"https://ns.adobe.com/experience/analytics": {
"title": "Adobe Analytics Cloud End User Ids",
"$ref": "https://ns.adobe.com/xdm/context/identity",
"description": "Adobe Analytics Cloud extension to End User Ids."
}
}

This is fixed.


Can't compile - multiple 'undeclared here (not in a function)' errors

I've just noticed that new changes has been pushed to the git repo.
Unfortunately this 6 commit seems to have a compilation problem.
Maybe not all changes were pushed to Git?

evdevshift.c:509:12: error: ‘KEY_NUMERIC_A’ undeclared here (not in a function)
(..)

evdevshift.c:510:12: error: ‘KEY_NUMERIC_B’ undeclared here (not in a function)
(..)

Full log in attachment:
compilation_error.txt

Fixes the problem on my 14.04 machine by using already preprocessed name list.
Kind regards,
Michal


Skip the formats that error out

Skip invalid formats that error out and cause a crash

Some formats raise exceptions because they are unexpected by the extractor.
In such cases just skip them and make sure there is at least one expected format remaining.
Fixes #4690
Template
Before submitting a pull request make sure you have:

[X] At least skimmed through contributing guidelines including yt-dlp coding conventions
[X] Searched the bugtracker for similar pull requests
[X] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[X] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[X] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

This is too broad. It's enough to make just that error non-fatal


Inaccurate float constant on compute shader

Hi.
I ran a simple SPIR-V using Vulkan SDK.
Here is a pseudo code (OpenCL)
#define PI 3.14159274f
__kernel void testConstant(__global float* result)
{
  if (get_global_id(0) == 0)
    result[0] = PI;
}

So I expect result[0] is 3.14159274, but it was actually set to 3.1415901 on macOS.
The output value was bit different from I expected.
It didn't happened on Linux and Windows on AMD and NV gpus (result[0] was 3.14159274).
But I'm not sure it's a MoltenVK issue.
Thanks.
disassembled SPIR-V code
; SPIR-V
; Version: 1.0
; Generator: Codeplay; 0
; Bound: 35
; Schema: 0
               OpCapability Shader
               OpExtension "SPV_KHR_storage_buffer_storage_class"
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %28 "testConstantValues" %gl_GlobalInvocationID
               OpSource OpenCL_C 120
               OpDecorate %18 SpecId 0
               OpDecorate %19 SpecId 1
               OpDecorate %20 SpecId 2
               OpDecorate %_runtimearr_float ArrayStride 4
               OpMemberDecorate %_struct_3 0 Offset 0
               OpDecorate %_struct_3 Block
               OpDecorate %gl_GlobalInvocationID BuiltIn GlobalInvocationId
               OpDecorate %gl_WorkGroupSize BuiltIn WorkgroupSize
               OpDecorate %23 DescriptorSet 0
               OpDecorate %23 Binding 0
      %float = OpTypeFloat 32
%_runtimearr_float = OpTypeRuntimeArray %float
  %_struct_3 = OpTypeStruct %_runtimearr_float
%_ptr_StorageBuffer__struct_3 = OpTypePointer StorageBuffer %_struct_3
       %void = OpTypeVoid
          %6 = OpTypeFunction %void
       %uint = OpTypeInt 32 0
%_ptr_StorageBuffer_float = OpTypePointer StorageBuffer %float
       %bool = OpTypeBool
         %10 = OpTypeFunction %uint
     %v3uint = OpTypeVector %uint 3
%_ptr_Input_v3uint = OpTypePointer Input %v3uint
%_ptr_Input_uint = OpTypePointer Input %uint
%_ptr_Private_v3uint = OpTypePointer Private %v3uint
     %uint_0 = OpConstant %uint 0
%float_3_14159274 = OpConstant %float 3.14159274
%gl_GlobalInvocationID = OpVariable %_ptr_Input_v3uint Input
         %18 = OpSpecConstant %uint 1
         %19 = OpSpecConstant %uint 1
         %20 = OpSpecConstant %uint 1
%gl_WorkGroupSize = OpSpecConstantComposite %v3uint %18 %19 %20
         %22 = OpVariable %_ptr_Private_v3uint Private %gl_WorkGroupSize
         %23 = OpVariable %_ptr_StorageBuffer__struct_3 StorageBuffer
         %24 = OpFunction %uint Pure %10
         %25 = OpLabel
         %26 = OpAccessChain %_ptr_Input_uint %gl_GlobalInvocationID %uint_0
         %27 = OpLoad %uint %26
               OpReturnValue %27
               OpFunctionEnd
         %28 = OpFunction %void None %6
         %29 = OpLabel
         %30 = OpAccessChain %_ptr_StorageBuffer_float %23 %uint_0 %uint_0
         %31 = OpFunctionCall %uint %24
         %32 = OpIEqual %bool %31 %uint_0
               OpSelectionMerge %34 None
               OpBranchConditional %32 %33 %34
         %33 = OpLabel
               OpStore %30 %float_3_14159274
               OpBranch %34
         %34 = OpLabel
               OpReturn
               OpFunctionEnd

OS: 10.14.3
Vulkan SDK: <IP_ADDRESS>
Devices: RX vega 56, Intel HD Graphics 4000

What Metal code do you get? If you set MVK_DEBUG=1, MoltenVK will print this for you.

Sure this isn't just normal floating point inaccuracy? The result seems accurate to about 6 digits and that's normal for FP32.

When I set MVK_DEBUG=1, any Metal code wasn't printed.
And when I passed "VK_MVK_moltenvk" extension to a vulkan device.
I got an error message from validator.
VUID_Undefined(ERROR / SPEC): msgNum: 0 - Device Extension VK_MVK_moltenvk is not supported by this layer.  Using this extension may adversely affect validation results and/or produce undefined behavior.

Maybe my host vulkan code is wrong?

This is slightly disturbing, on Linux I'm getting:
kernel void testConstantValues(device _7& _9 [[buffer(0)]], uint3 gl_GlobalInvocationID [[thread_position_in_grid]])
{
    uint3 _24 = gl_WorkGroupSize;
    if (_25(gl_GlobalInvocationID) == 0u)
    {
        _9._m0[0u] = 3.1415927410125732421875;
    }
}

This is basically the same as when I try to run a C program doing:
#include <stdio.h>

#define PI 3.14159274f

int main(void)
{
        volatile float f = PI;
        printf("PI in fp32 is: %.16f\n", f);
}

I know that Metal shaders compiled at runtime have -ffast-math on by default. I wonder if that has something to do with it.

When I set MVK_DEBUG=1, any Metal code wasn't printed.

Are you sure? You should see it on stderr. There should be lines tagged with [mvk-info] in the output on stderr.

Oh, I tried with MVK_DEBUG=1 again, but it didn't show any line with [mvk-info].
And I tried to enable VK_MVK_moltenvk to call vkGetMoltenVKConfigurationMVK and vkSetMoltenVKConfigurationMVK when a vulkan instance creation.
Vulkan raised an error ERROR: loader_validate_instance_extensions: Extension VK_MVK_moltenvk not found in list of known instance extensions....
I'm sorry, I couldn't help you.

@byzin
Are you setting MVK_DEBUG as a build variable during app compilation...or as a runtime environment variable during app execution? It needs to be a runtime environment variable set prior to app launch.
Unfortunately the loader does not support vkSetMoltenVKConfigurationMVK.

Hi @billhollings
UnitTest.zip
Could you extract the zip and run runUnitTest.sh?
In the script, MVK_DEBUG=1 is set and UnitTest runs a kernel in math.spv, but any debug info of Metal isn't printed on my machine...
If you need anything, let me know.

Did you run the unit test?
Do you need anything else?

@byzin
Sorry for the delay in responding.
Hmmm...the libMoltenVK.dylib in your sample has MoltenVK logging completely disabled. Did you compile that library yourself...or does it come directly from the SDK?
When I run your sample against MoltenVK with logging enabled and MVK_DEBUG=1, the following appears in the log:
[mvk-info] Converting SPIR-V:
; SPIR-V
; Version: 1.0
; Generator: Codeplay; 0
; Bound: 35
; Schema: 0
               OpCapability Shader
               OpExtension "SPV_KHR_storage_buffer_storage_class"
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %28 "testConstantValues" %17
               OpSource OpenCL_C 120
               OpDecorate %18 SpecId 0
               OpDecorate %19 SpecId 1
               OpDecorate %20 SpecId 2
               OpDecorate %2 ArrayStride 4
               OpMemberDecorate %3 0 Offset 0
               OpDecorate %3 Block
               OpDecorate %17 BuiltIn GlobalInvocationId
               OpDecorate %21 BuiltIn WorkgroupSize
               OpDecorate %23 DescriptorSet 0
               OpDecorate %23 Binding 0
          %1 = OpTypeFloat 32
          %2 = OpTypeRuntimeArray %1
          %3 = OpTypeStruct %2
          %4 = OpTypePointer StorageBuffer %3
          %5 = OpTypeVoid
          %6 = OpTypeFunction %5
          %7 = OpTypeInt 32 0
          %8 = OpTypePointer StorageBuffer %1
          %9 = OpTypeBool
         %10 = OpTypeFunction %7
         %11 = OpTypeVector %7 3
         %12 = OpTypePointer Input %11
         %13 = OpTypePointer Input %7
         %14 = OpTypePointer Private %11
         %15 = OpConstant %7 0
         %16 = OpConstant %1 3.14159274
         %17 = OpVariable %12 Input
         %18 = OpSpecConstant %7 1
         %19 = OpSpecConstant %7 1
         %20 = OpSpecConstant %7 1
         %21 = OpSpecConstantComposite %11 %18 %19 %20
         %22 = OpVariable %14 Private %21
         %23 = OpVariable %4 StorageBuffer
         %24 = OpFunction %7 Pure %10
         %25 = OpLabel
         %26 = OpAccessChain %13 %17 %15
         %27 = OpLoad %7 %26
               OpReturnValue %27
               OpFunctionEnd
         %28 = OpFunction %5 None %6
         %29 = OpLabel
         %30 = OpAccessChain %8 %23 %15 %15
         %31 = OpFunctionCall %7 %24
         %32 = OpIEqual %9 %31 %15
               OpSelectionMerge %34 None
               OpBranchConditional %32 %33 %34
         %33 = OpLabel
               OpStore %30 %16
               OpBranch %34
         %34 = OpLabel
               OpReturn
               OpFunctionEnd

End SPIR-V

Converted MSL:
#pragma clang diagnostic ignored "-Wmissing-prototypes"

#include <metal_stdlib>
#include <simd/simd.h>

using namespace metal;

struct _3
{
    float _m0[1];
};

constant uint _18_tmp [[function_constant(0)]];
constant uint _18 = is_function_constant_defined(_18_tmp) ? _18_tmp : 1u;
constant uint _19_tmp [[function_constant(1)]];
constant uint _19 = is_function_constant_defined(_19_tmp) ? _19_tmp : 1u;
constant uint _20_tmp [[function_constant(2)]];
constant uint _20 = is_function_constant_defined(_20_tmp) ? _20_tmp : 1u;
constant uint3 gl_WorkGroupSize = uint3(_18, _19, _20);

uint _24(thread uint3& gl_GlobalInvocationID)
{
    return gl_GlobalInvocationID.x;
}

kernel void testConstantValues(device _3& _23 [[buffer(0)]], uint3 gl_GlobalInvocationID [[thread_position_in_grid]])
{
    uint3 _22 = gl_WorkGroupSize;
    if (_24(gl_GlobalInvocationID) == 0u)
    {
        _23._m0[0u] = 3.14159;
    }
}

End MSL

Estimated original GLSL:
#version 450
layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z_id = 2) in;

layout(set = 0, binding = 0, std430) buffer _3_23
{
    float _m0[];
} _23;

uvec3 _22 = gl_WorkGroupSize;

uint _24()
{
    return gl_GlobalInvocationID.x;
}

void main()
{
    if (_24() == 0u)
    {
        _23._m0[0u] = 3.14159;
    }
}

End GLSL

...which uncovered the problem.
By default...MoltenVK limits floats to 6 digits via the use of the SPIRV_CROSS_FLT_FMT build setting. The reasons for this are lost to the mists of time...as part of the original MSL generation within SPIRV-Cross...but may have to do with the rounding issues that @HansKristian-Work alludes to above.
You can disable this...and allow full float accuracy within MoltenVK by opening the ExternalDependencies.xcodeproj Xcode project, removing this build setting from the SPIRV-Cross-macOS and SPIRV-Cross-iOS targets, and running ./fetchDependencies again. You might need to remove the Externals/build directory first.
I'll do a bit more research about whether the 6-digit limit is needed anymore.

That would explain it, but it's a bit scary if that setting has been used up until now.

I used the library of SDK <IP_ADDRESS>.
OK, I'll try to compile the library without the 6-digit limit.
Thanks!

This is fixed in PR #518. MoltenVK no longer sets SPIRV_CROSS_FLT_FMT when building SPIRV-Cross.


Cannot reach containers attached to user-defined bridge network

Containers attached to the default bridge network work as expected. The following command should spin up portainer correctly.
docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer-ce

However, attaching it to a user-defined bridge network doesn't work correctly yet. Steps to reproduce:
docker network create my-net
docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --network my-net --restart=always -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer-ce

Docker provides extensive documentation about bridge networking. Especially the section Enable forwarding from Docker containers to the outside world seems relevant.

Configure the Linux kernel to allow IP forwarding.
sysctl net.ipv4.conf.all.forwarding=1
Change the policy for the iptables FORWARD policy from DROP to ACCEPT.
sudo iptables -P FORWARD ACCEPT

Step 2 has been addressed in version v1.2.0 of the script. The first step doesn't work on Synology DSM yet.

hey @markdumay , I appreciate your tenacity 👍
Yesterday I spent some time getting everything "back to normal".
Today I got your email so I re-tried the update and a simple portainer launch in bridge mode.
I can confirm it doesn't work for me. not even with the sysctl and the uptables policy change.

So I was able to successfully use the iptables command above that you mentioned to get successful connectivity on my docker custom network. I'm not sure if it has to do with the fact that I created the bridge prior, but I wouldn't think it should.
That said - my bigger question/concern - is the impact of that policy change really something we want here?

I agree with your concern, it wouldn't be great to suddenly have your NAS fully exposed to the public internet. It's quite a challenging subject, as Docker messes with the iptables quite a bit under the hood. I found this discussion on stack overflow with some in-depth observations about Docker's networking configuration.

For now I'm reverting to the official supported docker. I followed a tutorial around Traefik setup that highlighted being able to just drop in replace the docker-compose binary - which is the core of what I needed. Would it be possible to make a modification to this script that could do this work instead? If left to my own devices, I might be able to augment your script and/or make a PR. But I figure if you're intimately familiar it might take a few moments to plug in another option to ONLY modify the docker-compose binary. I like your script overall, so an elegant option to potentially only replace the compose binary would be fantastic.
Just my .02 - thanks for the script as is though. The backup alone is a nice function.

Hi @1activegeek, I added preliminary support for your request in the develop branch. I haven't thoroughly tested it yet (and I'm about to go offline for a few days ;-) ) - especially the execute_restore_bin() function requires testing. Care to give it a spin? Curious to hear your thoughts!
The general approach I followed was to support a new flag --target. If set, you can specify to target either engine, compose, or driver updates only. This acts as a global flag, and as such affects all commands - except for backup. For now, I decided to always backup all relevant files, regardless of the target.

For those interested, I ran into this gist by @pedrolamas. I haven't tested it myself yet, but it seems worth looking into.

Hey @markdumay, not sure if this will help but I wrote a post on the reason behind that gist and what it helps to fix: https://www.pedrolamas.com/2020/11/04/exposing-the-client-ips-to-docker-containers-on-synology-nas/

Thanks for the heads up @pedrolamas! I was indeed curious about the reason behind your script. I'm running Pi-Hole on my NAS - eager to find out if your script fixes the missing client IPs. I like the WOMM certification by the way. ;-)

Ah, if the problem you are experiencing is the missing client IPs in Pi-hole, then yes, that script will indeed fix that! 🙂

Cool! It probably won't solve the networking issues mentioned in this issue thread then - I'll create a new issue in this repository instead ;-).

Wow. I wish I had read my mail earlier than trying to trailblaze around. I just spent about the last 4 hours trying to troubleshoot this exact issue, and JUST stumbled upon your script @pedrolamas. I'm pulling up a man iptables now to decipher for myself what the rule is actually doing in the grand scheme. If it doesn't seem to terrible, I'll roll with it. So thank you in advance for the script, I only wish I had found it earlier.

Shawn, did @pedrolamas script solve the "bridge" issue for you?
On Wed, Dec 30, 2020, 04:10 Shawn Mix<EMAIL_ADDRESS>wrote:

Wow. I wish I had read my mail earlier than trying to trailblaze around. I
just spent about the last 4 hours trying to troubleshoot this exact issue,
and JUST stumbled upon your script @pedrolamas
https://github.com/pedrolamas. I'm pulling up a man iptables now to
decipher for myself what the rule is actually doing in the grand scheme. If
it doesn't seem to terrible, I'll roll with it. So thank you in advance for
the script, I only wish I had found it earlier.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/markdumay/synology-docker/issues/35#issuecomment-752311699,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACP6EX2SWDBYWLHEGUYYKXDSXKKZPANCNFSM4T4MK6SA
.

It is working for me for this specific use case around the SourceIP being passed properly (aka the x-forwarded-for header being present and showing the correct SourceIP). I have not tested this as a resolution to the bridge issue faced when replacing the docker binary on the syno. I'm hesitant to test that again as I had a major pain last time - I think because I forgot to manually spin down a bunch of docker-compose items I had running, so there was some sort of overwritten conflict that went unnoticed in the docker setup.
So again to answer your question - no this has not been tested to resolve the "no internet" issue faced with the bridge networks.

Hello,
I have same issue on DS716II+. It work on my other nas DS718+.
I do not manage to find a solution yet. I try to debug and found something strange.
If I try to ping a container it failed but if I start a tcpdump on the interface, it start working.
I think tcpdump put the interface in promiscuous mode. It could be a hint to find a solution :)

I have another issue :( with interface hassio I have no NAT so no internet.

I know this is an older post and an ongoing issue
Has anyone figured out a working fix?

I don't know if this is 'noise' or if it's worth trying for the folks having an issue with custom bridge networks... On my DS218+, I have run into issues even in the stock Docker/ContainerManager package with bridge mode if you have "Enable Multiple Gateways" enabled in the Advanced Network Settings on the Synology.
You might try disabling that setting (I think it might be enabled by default) and see if it changes how things are working with custom networks.
Again... not sure if this is noise or if it's something worth trying, but... might be worth a shot.


Fix logical plan serialization

Which issue does this PR close?

Closes #3555
Rationale for this change

Currently round-trip logical plan serialization is broken for some aggregation queries. This happens when the TypeCoercion optimizer casts literal values in aggregate function expressions and then the const evaluator optimizes out the cast (replacing with a literal for the casted value). This effectively changes the expression name and causes a mismatch when rebuilding the plan after deserialization.
What changes are included in this PR?

In TypeCoercion special-case the handling of aggregation function expressions to make sure we alias back to the original expression name if it has changed. This should ensure the schema is still valid and the plan can be rebuilt from its serialized representation.
Are there any user-facing changes?

no

no

@alamb @andygrove This feels like a bit of hacky special casing but seemed like the least insrusive way to deal with this. If optimizers can change expression names in general though this could come up in other places w/r/t serde of aggregation plans where we rely explicitly on the expression name.

I wish I had a better story for you

I believe this PR is going to fail its checks until is it merged to include https://github.com/apache/arrow-datafusion/pull/3576

I wonder if https://github.com/apache/arrow-datafusion/issues/3568 could be related

I wonder if #3568 could be related

Yeah, if I understand that ticket correctly then it's the same underlying issue


Addition of display item script

Script to construct a display item set, with label, value and unit
This example is made with this code. Can also be constructed with yaml
id(displayitem).execute(2,2,"Gemeten","size_2_label","orange",20,1,"","size_2_value","white","°C","size_2_unit","white","TOP_LEFT");
id(displayitem).execute(160,2,"Buiten","size_3_label","orange",9,1,"","size_3_value","white","°C","size_3_unit","white","TOP_CENTER");

How it works:
Calculates the baseline height of the label label_height
Positions the value at y+label_height
Positions the unit at x+value_width, y+label_height+value_height-unit_height
It scales with font size, unit will always be at same baseline as value

I like the idea! but maybe we can build a card for this? It is basically the same idea, but it "optional" instead of hard coded. What do you think? Check out the music card: https://github.com/dixi83/ESPhome_ButtonPlus/tree/main/package/cards

It is essentially a card, optional is fine. I am not sure how to deal with the fonts and colors though. My config is almost ready by the way, soon to be loaded in the device on the wall. Will share pictures on got

I changed this to my dev branch i will try to convert this to a card


Change deprecated Bazel single file attr param

This removes the need for --incompatible_disable_deprecated_attr_params

I was updating our internal version of Bazel to 0.16 and these errors showed up with --all_incompatible_changes enabled, so I fixed them.

Okay Google, I approve of this pull request.

I'm ok with my commits being contributed to this project.


nd4j-native: crash on gemm with multithreading

Running the Iris Spark example (in Spark local) results in a crash with a large number (10 or more) threads in the spark configuration.
https://gist.github.com/AlexDBlack/ceb127ac5e3fd8f8f3a15cf36a60a024
This behaviour can be easily replicated with the following code:
    public static void main(String[] args){
        final INDArray first = Nd4j.create(10,10);
        final INDArray second = Nd4j.create(10,10);

        int nThreads = 10;
        final int iterationCount = 1000;
        for( int i=0; i<nThreads; i++ ){

            Thread t = new Thread(new Runnable(){
                @Override
                public void run() {
                    for( int i=0; i<iterationCount; i++ ){
                        first.mmul(second);
                    }
                }
            });
            t.start();
        }
    }

This appears to be due to openblas (bundled); running this on 0.4-rc3.10-SNAPSHOT (i.e., nd4j/libnd4j master) with MKL works fine (even with 1000 threads doing mmuls simultaneously).

@AlexDBlack, could you confirm that bug persists? I wasn't able to reproduce it even increasing sizes of the arrays and the number of threads.

Probably it was fixed ages ago...


Popper moves out of viewport when resizing

Hey there,
at first, popper.js is really nice and I try to use it instead of tether.io owing to performance problems.
It works quite well, but there is a problem when resizing the viewport, which I tried to understand and solve for some hours now.
The problem is as follows. Open the popover and now resize the browser width. At a specific point, the popover moves to the right. This leads to a positioning problem in some viewports, where the popover is fully shown, but the positioning is wrong. I would expect, that the popover pins to the right side of the viewport when resizing.
For a better understanding, here's the Codepen.
Thanks for your suggestions and hope we find a solution together.
Kind regards,
Falingorn

It's the preventOverflow modifier that kicks in when it shouldn't...
A temporary fix is to disable this modifier:
http://codepen.io/FezVrasta/pen/Lkjjqb
But the modifier should be fixed.

Thanks a lot 👍  ... I'll probably use it as you suggest and try to fix it later on if I'll get a timeframe for this.
Happy coding! :)

@Falingorn had you a chance to look at this problem?

I'm digging into it, seems like the problem is the arrow modifier, not preventOverflow

Ok found the problem, in your example, the arrow element has not style, this makes the arrow wide as the popper, and creates the problem you describe.
You should not add an arrow if you don't want to use it, or give a width to the arrow to make it work properly.
http://codepen.io/FezVrasta/pen/ZOmBkQ
I'm closing it for now because it doesn't seem like a bug of the library but a misconfiguration. If you have any idea to avoid this problem let me know.
For now I'd say: Don't use arrow if you don't want to display one.

Thanks a lot ... will try it.
Is there a possibility to decide via configuration options if popper has an arrow or not? I think this would be a better approach than solve this with css.
You rock man! ;)

you can set arrowTagName to undefined to avoid the creation of the arrow element.

I have to same problem in version "@popperjs/core": "^2.11.0"
node 10.
framework Vue 2
createPopper(document.querySelector(...), document.querySelector(...), {
        placement: 'bottom',
        modifiers: [...], // offset[0,5]
      });

Ok. I fix it. You need wrap your's trigger div with position: absolute
<div style="position: absolute">
    <i
      class="icon-custom icon-custom--info"
    />
    <div
      :style="..."
      role="tooltip"
    >
      <slot name="content"/>
      <div
        id="arrow"
        data-popper-arrow/>
    </div>

  </div>


fixed content overlapping(minor)

So i ran a fix the best way i could to avoid changing/rewriting lots of codes that are not mine, i added a scroll to it and reduced some font, did same with the mobile width i added so it would look good, i hope this minor fix is accepted.
regards.

Hi @ify47, I think the text is a bit too small


VSCode: Module 'webpack' is not listed as dependency in package.json while it presents

Bug Report

TSLint version: 5.10.0
TypeScript version: 2.9.2
Running TSLint via:  VSCode

TypeScript code being linted
import webpack from 'webpack';

with tslint.json configuration:
{
    "defaultSeverity": "error",
    "extends": ["tslint:latest", "tslint-react", "tslint-config-prettier"],
    "jsRules": {},
    "rules": {
        "ordered-imports": false,
        "object-literal-sort-keys": false
    },
    "rulesDirectory": []
}

Actual behavior
webpack is installed and presents in package.json
        "webpack": "^4.12.0",
        "webpack-cli": "^3.0.8",
        "webpack-dev-server": "^3.1.4",
        "webpack-node-externals": "^1.7.2"

but in VSCode I have tslint error:
[tslint] Module 'webpack' is not listed as dependency in package.json (no-implicit-dependencies)

Expected behavior
expected - code without error

@budarin check the options for this rule. you may need to enable the one that allows devDependencies.

@giladgray
It did not help
I tried:
"no-implicit-dependencies": [true, "dev"],
"no-implicit-dependencies": "dev"
"no-implicit-dependencies": false

any of that has helped :(

well then. where is the package.json relative to your tslint.json and your source file? maybe the paths are confusing it.

in the root of the project on the same level
try in repo

sorry mate I don't know what's up here. everything looks in order. it's likely some quirk of your setup.

so, how should I live with it? :)

investigate further. have you installed @types for these packages? i honestly don't know the internals of this rule or your code so there's little i can do for you from over here.

i checked out your code and can definitely repro this. i have no idea what's up.

I am confused by the fact that the error is intermittent: first, it was in the import webpack then moved on react-hot-loader

@budarin my friend i have bad news. setting the correct config handily fixed this.
"no-implicit-dependencies": [true, "dev"]

https://github.com/palantir/tslint/issues/3991#issuecomment-399704725 has a trailing comma after the ] which may have caused the whole thing to blow up.

I have successfully  disabled this rule today 21:47, 27 июня 2018 г., Gilad Gray notifications@github.com:#3991 (comment) has a trailing comma after the ] which may have caused the whole thing to blow up.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.
С уважением Бударин Вадим

i checked out your code  and enabled it and it worked flawlessly.

https://github.com/budarin/react-ssr-bootstrap-project/pull/1/files

But disabling it - is not good solution (21:49, 27 июня 2018 г., Gilad Gray notifications@github.com:i checked out your code  and enabled it and it worked flawlessly.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.
С уважением Бударин Вадим

Thanks!


Thanks for

Current Situation
all these wonderful test release emails I receive from this project... ;-)
Logs
No response
Config
No response
Homebridge UI Version
latest
Homebridge Version
latest
Node.js Version
latest
Operating System
Other (specify in description)
Environment Info

[ ] Using Docker?
[ ] Using Hyper-V?
[ ] Using hb-service?

Raspberry Pi Model
No response


[Feature] Move routes config generation from runtime to build time

Currently routes config is generated on run-time, which means that on each page load, the routes config gets parsed with a bunch logic and regex run against it. Not an issue for a small site, but as you enter in the realm of hundreds of routes (or alternatively if the initial page load is already CPU-intensive), it can easily add up to a few ms of processing time before routes can be mounted / data loaded. An unnecessary processing time, since the routes config is static by nature, and not run-time dependent.
I suggest moving that logic to build-time processing similar to how router.ts types file is generated.
There are two major side-benefits from this:

Easier inspectability, since you can see the end-result that gets passed into e.g. createBrowserRouter of react-router-dom, you can more easily understand the end-structure and spot any errors easily.
Eject-ability. Want to move back to config-based routing? Just remove the plugin and you have a working config file to build on top of.

Hey @lauri865, I implemented that at some points (not long time ago) for those benefits but there were couple of major issues directly related to the dev experience. That can be revisited in the future though.

What were the issues @oedotme? Happy to take a stab at it.

@lauri865 that was initially released at v1.7.0 fb6496a and removed at v1.9.0 9df4161

Thanks, will try out out. But if you can share what the issues were with DX, it'd be very helpful 🙏
As a benchmark, I'll add the auto-generated output file of Tanstack router's CLI:
https://github.com/TanStack/router/blob/4dbd334fdad68ff80f91824da6d32ffc1450fc4e/examples/react/file-based-routes/src/routeTree.gen.ts#L4

Thanks! Yeah sure, the main issue was the routes and exports detection while adding/removing routes and the HMR while updating routes.

Also I've had those issue mostly with vite@v4, I've updated the dependencies now to vite@5 which fixes some issues regrading certain files detection and also HMR in general in my experience.

Seems like Tanstack's vite plugin for file based routing works pretty well. Would benefit neat to have sth similar with react router as well.
We're considering three options right now:

Create a custom vite plugin and/or contribute to generouted
Move over to tanstack/router (difficult to prioritise)
Move back to config based routing for the time being, until we can prioritise 1 or 2

@oedotme, can you reopen this?
Another reason to do it in the plugin is to remove a circular dependency in Vite due to importing Modals from @generouted/react-router:
vite:hmr circular imports detected: /src/pages/(app)/_layout.tsx -> /node_modules/.vite/deps/@generouted_react-router.js?v=977c9260 -> /src/pages/(app)/_layout.tsx

@oedotme, we finished a custom plugin for this now. Reimplemented everything from scratch, but pretty much same ideology with generouted, with some additional features, and support for multi page apps in the same src dir.

Build times are 25% faster
We discovered that the generouted approach broke code splitting and tree shaking, now our bundle sizes are smaller
Noticable improvement on page loads
Better error handling and customization (import.meta approach is static by nature)
Better visibility / ejectability. Something doesn't quite work with the file based routing but we need to quickly get a fix to prod? Disable the plugin and edit the config for the time being.

@lauri865 What about the dev experience, HMR or the changes detection in general?
I'm interested to see how it differs from my previous implementation. Could you please share an example with this plugin?
Thanks!

Well, we had to hook up watch for add and unlink events to get the tree to regenerate when renaming, adding or deleting files.
There's another issues with your implementation, and that's around the use of prettier. You're spawning a child process with prettier CLI, which is slow. Much better to make it prettier a dependency, and invoke it directly. Much faster, but also just a single file change. Otherwise, you're pushing the same effective code twice with different formats and with a delay in between (can be a second).
When it comes to HMR – the only case it doesn't work in where it does currently for generouted is editing an inline component that is directly defined in the route file. And this only works in generouted if the route file only exports the said inline component. Should you export anything but a single component in Vite, HMR breaks.
And we're completely fine with that, since most of our routes export a loader or metadata anyways, so we'd want them to be reloaded. And we avoid defining components within route files, and use route files only as a route configs – keeps things easier to follow and more reusable (need to have the same page with a different path? Just duplicate the file with a different name, etc.).
So, HMR works perfectly fine in the happy path.


change(consensus): Update mainnet and testnet checkpoints

Motivation
We're seeing some slow syncs, updating the checkpoints might help.
Let's try PR #5257 without these, then if that doesn't work we can merge them and try again:
Depends-On: #5257
Review
This is routine, but required for tagging the release candidate.
Reviewer Checklist

[ ] Will the PR name make sense to users?

[ ] Does it need extra CHANGELOG info? (new features, breaking changes, large changes)

[ ] Are the PR labels correct?
[ ] Does the code do what the ticket and PR says?
[ ] How do you know it works? Does it have tests?

Failed due to #5366, logs in that ticket.

I added some intermediate jobs between logs-1790k and logs-checkpoint in https://github.com/ZcashFoundation/zebra/pull/5372

@mergifyio refresh

@mergifyio refresh

The macOS job failed while building the Zcash parameter path binary, which is really unusual. (It's not particularly big, and it doesn't do much.)
I'll try again, but if that doesn't work, we should clear the macOS build cache:
https://github.com/ZcashFoundation/zebra/blob/main/book/src/dev/continuous-integration.md#fixing-disk-full-errors-and-zcash-parameter-errors
And if that doesn't work, we can disable the macOS job, because we don't support macOS tests.

There was no test cache for this PR or main, but I deleted the clippy cache:
    {
      "id": 39427,
      "ref": "refs/heads/main",
      "key": "v0-rust-clippy-cargo-lock-1.64.0-x86_64-unknown-linux-gnu-a55dd71d5fb0-1b751ccaa4b37d9524c4",
      "version": "8a9936d632ad0d67adaee02f5d9fd8c1dddbbd5af8d94331392b76f17401cf6d",
      "last_accessed_at": "2022-10-11T01:06:11.716666700Z",
      "created_at": "2022-10-10T19:34:51.596666700Z",
      "size_in_bytes":<PHONE_NUMBER>
    },

@mergifyio refresh


Integrate Webpack Dashboard

Would it be possible to integrate Webpack Dashboard? Currently this is possible once you've ejected, but I think a lot of users would benefit from it who may not want to eject just to have this plugin.
https://github.com/FormidableLabs/webpack-dashboard

Already discussed in #449

Yea, let’s wait it out a little bit.
Is there anything particular you’re missing from it?

No, it just seemed like a really nice project - but you're right, maybe a little premature to integrate it. Thanks for the create-react-app project by the way; makes knocking up little experiments so easy, whereas before I just wouldn't bother. Cheers!

@gaearon what do you think of considering webpack-dashboard again, given that it's been around for one year?

What information do you find valuable in particular?

I'm particularly interested in the module size breakdown, i.e some feedback that would make me more thoughtful when doing another npm install xyz / import. If I'm not wrong, the only time CRA brings file sizes to the developer's attention is after npm run build. Seeing that the gzipped main.js is already 1MB is useful, but there no extra info on what modules to blame.
Maybe adding webpack bundle analyzer (https://github.com/facebookincubator/create-react-app/pull/2359) can improve the feedback and thus make a positive impact on the obesity many modern web apps (including mine) suffer with.

The problem is that the stats shown by Webpack dashboard are wrong. They are not representative of real file size distribution because they don't take dead code elimination and minification into account.
I think it's better to educate users about measuring their dependencies with sourcemap explorer that shows real numbers, than show wrong numbers immediately.

Seeing that the gzipped main.js is already 1MB is useful, but there no extra info on what modules to blame.

Once it's over 512 kB we show a warning that includes a link to instructions on both bundle splitting and dependency analysis with sourcemap explorer. So I don't think it's accurate to say we don't help you learn about those tools.

The problem is that the stats shown by Webpack dashboard are wrong. They are not representative of real file size distribution because they don't take dead code elimination and minification into account.

How about electron-webpack-dashboard ? Does it show more accurate size estimations ?

Last time I checked its numbers were wrong too. They might have fixed it by now, but maybe not.
I still suggest using source-map-explorer for best results.


CoreGraphics port: add "-framework CoreFoundation" to the linker flag to use libSVGNativeViewerLib.

d1f8a2c cannot finish the linking of testC. To finish it, "-framework CoreFoundation" is added to the linker flag in CMakeLists.txt.
An archive library does no record its dependency, so the dependencies should be supplied by the linker flags explicitly, also it is added to pkg-config file.

@mpsuzuki Thanks! Was planning to do it today. Merging.

Thanks! I'm happy to see Green badge on this branch!!


Various changes to the reconnect strategy of TCP provider

This PR fixes #86

@tkurki any objections? Otherwise I'd like to merge :)

Wouldn't it be easier to use something like https://www.npmjs.com/package/net-socket-reconnect (just googled, no experience with this or other npm solutions).

If you're happy with this go ahead and merge.


Setup error: "The name 'RotativaConfiguration' does not exist in the current context"

I keep getting the error:
Error CS0103: The name 'RotativaConfiguration' does not exist in the current context (CS0103)
I've followed steps from several tutorials but keep ending up with this error after I add in this to the Startup.cs:
RotativaConfiguration.Setup(env);
I am using Visual Studio Mac Community, in case this makes any difference

Are you adding this using?
using Rotativa.AspNetCore;
or alternatively, just do:
Rotativa.AspNetCore.RotativaConfiguration.Setup(env);
Does this fix it?

@webgio this using Rotativa.AspNetCore; is not being recognized as a package, but this using Rotativa.NetCore; is, and there is no method there called RotativaConfiguration, the error checking says I may be missing  a reference? not so sure what to do here... no one else seems to have this issue

I do have tha same issue. Did you solve your issue?


Typo fix in searchlight/README.md

Line 76: Delete duplicated "the the"

/ok-to-test
/lgtm

/lgtm


Add Platys to awesome-compose once we are ready

https://github.com/docker/awesome-compose

move the platys as issue: https://github.com/TrivadisPF/platys/issues/10


Evaluate consistency of terminology regarding VM collections

While working on #851 I notice what appears to be an inconsistency across various LongServiceOutput helper functions for these collections of VMs:

allVMs
evaluatedVMs
"problem" VMs

vmsNeedingResponse
vmsWithBackups
vmsNeedingConsolidation
...

Essentially the "all" VMs collection ends up not really being all VMs, or at least no guarantee that it really is all VMs (e.g., the sysadmin may limit plugin focus to just one resource pool).
The "evaluated" VMs collection is generally the VMs after filtering is applied.
The "problem" VMs collection contains the VMs of specific focus for the plugin, those which should be reported. These VMs were evaluated and match "should be reported" criteria for the specific plugin.
Other collection types are also present and often encompass all types as an aggregate.
Other reporting functions also focus on just two sets:

allVMs
evaluatedVMs

I believe that I meant for "all" VMs to represent the collection of VMs after initial resource pool inclusion/exclusion filtering and the "evaluated" VMs collection is after other filtering (e.g., by name, by power state) is applied.

Essentially the "all" VMs collection ends up not really being all VMs, or at least no guarantee that it really is all VMs (e.g., the sysadmin may limit plugin focus to just one resource pool).

I need to add logic to actually pull a count (only a count) of all VMs in the inventory. This can be our starting count before filtering of any kind is applied. At that point "evaluated VMs" becomes a lot clearer in intent.

NOTE: The "filtered" prefix also applies (or should apply) to resource pools, presumably folders and other container or collection types.

Evaluated is the number after all filtering is applied. For the VM list plugin this is the same as "remaining" VMs.
For the VM list plugin spelling out each stage of filtering is fine for perf data metrics.
After rp filtering.
After folder filtering
After power state filtering
After name filtering
Etc.

A side effect of working on #809 is that much of the discrepancies noted thus far will be resolved; refactoring of related functionality will provide common terminology (which is hopefully much clearer).


Create job tracker using ActionCable

[x] Create status page for jobs (showing list of jobs in queue)
[x] Create ActionCable channel
[x] Update ActionCable channel as the job finishes
[x] Update DOM with new ActionCable status

#110


fix: hide donation for unsupported keepkey swaps

Description
Currently, KK signing EVM transactions with donations does not work (see https://github.com/shapeshift/web/issues/4518).
We should not show the donation button for these swaps, as it currently does nothing.
Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
Closes https://github.com/shapeshift/web/issues/4993
Risk
Small
Testing
When connected to a KK, try a trade from an EVM asset with sufficient sell amount to allow for a donatiion.
The donation toggle should not show.
Trades from non-EVM assets should still allow donations with KK.
No other wallets should be affected by this PR.
Engineering
☝
Operations
☝
Screenshots (if applicable)
N/A

Current dependencies on/for this PR:

develop

PR #4996   👈

This comment was auto-generated by Graphite.


stack level too deep on #get in request specs

Subject of the issue
I just installed rspec in the rails engine gem i maintain. All i did was adding rspec-rails as a dependency and run rails g rspec:install. I created the simplest request spec possible:
require 'rails_helper'

RSpec.describe 'Root request', type: :request do
  describe 'GET /' do
    it 'returns a successfull response' do
      get '/'
      expect(response).to be_success
    end
  end
end

However, running it raises :
Failure/Error: get '/'

     SystemStackError:
       stack level too deep

I'm sorry if that was solved anywhere but the error produced and keywors are so generic it's very hard to find anything even remotely similar to my issue.
Your environment

Ruby version: 3.2.0
rspec-core version: 3.13.2

Steps to reproduce
Clone this app and run bundle exec rspec

If you run rspec with --backtrace, will there be anything pointing at an infinite loop? Can you share?

Sure, there you go: https://gist.github.com/mbajur/2835f7b8adf5b933adb4e35eec70024c

Ok, it turned out it was happening because i had no root_to route defined, rails was serving a default root template and it somehow messed up the get. Using a real route fixed that for me.


Split API section in docs

Describe your changes

API section split into functions and OOP
.. seealso:: added to docs

Issue ticket number and link
Closes #172
Checklist before requesting a review

[x] I have performed a self-review of my code

Please fix the CI.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.1%) to 94.568%

Files with Coverage Reduction
New Missed Lines
%

src/sklearn_evaluation/telemetry.py
2
96.92%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
2646

Relevant Lines:
2798

💛  - Coveralls


[Bug]: Indices for Stage 5 manual clipping shift after each clip

FAQ check

[X] Yes, I checked the FAQ and my question has not been addressed.

Instrument
Light curve fitting (Stages 4-6)
What happened?
If trying to clip the indices for several lists, during Stage 5 manual clipping, the indices will shift.
For example, if you're trying to clip every tenth index:
You would expect the clipping to behave as it did in Stages 3 & 4, where the indices to be clipped would be designated as [[10,10], [20,20], [30,30]]. However, to achieve this example clipping, at the moment, the indices need to be specified as [[10,11], [19,20], [28,29]].
Error traceback output
No response
What operating system are you using?
No response
What version of Python are you running?
No response
What Python packages do you have installed?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

So the relevant lines of the code are:
https://github.com/kevin218/Eureka/blob/43c4a2363d57d211a9e7f11975faa771ff1cb15b/src/eureka/lib/util.py#L142-L146
From these lines, I can tell that the bug you mention is not actually present (we flag all the requested indices, and then remove them so that we don't need to worry about shifting indices).
Where I think your confusion arises is how to specify the indices you want to clip, and I do think our documentation page could be a bit clearer about this. If you want to clip the 10th and 20th integrations, these would be indices 9 and 19 (since python uses zero-indexing). And the manual_clip start and end values are used to slice a numpy array, so they follow the same convention of inclusive start index and exclusive end index. In other words, to trim the 10th and 20th integrations, you would set manual_clip to [[9,10], [19,20]].
I'll clarify that a bit more on the documentation page here.


feat: Next iteration of chatui

@cpacker sharing this for you to see my last status of the day.
added some error handling, but I believe this still needs a lot of improvements.
added timestamps for when messages are sent.
when changing to a new agent the agent initiates the conversation.
persisting messages for now. Storing them in localstorage so users can see their
history and don't lose it on reload. replacing this with intelligent fetching asap.

TODOs
Highest priority marked with ⚠
🎄 Pending

[ ]  [Pure UI] Display current agent name somewhere in the chat view (probably top middle?)

[ ]  [Pure UI] An "agent search" box that filters the grid view based off of name

[ ]  [Pure UI] Have a "update successful" indicator / model / toast when a memory update goes through properly

[x]  ⚠ [Pure UI] On an exception / failed message sent: the UI should indicate that the message failed to send (similar to FB messenger etc, red text or outline indicating failed message) + propagate error message to the UI (in some capacity)

More details here: feat: next iteration of chatui #642 (comment)

[x]  ⚠ [Pure UI] On an exception / failed message sent: "typing..." lock should be released (currently gets trapped on "typing..." state

[ ]  [Pure UI] Add syntax highlighting to function call views

[ ]  ⚠ [UI + backend] When a chat window is opened, populate it with the last N messages

we can start by just displaying the messages in the agent buffer agent.messages
eventually add a scroll-back fetch based on a paginated query to recall memory (messages from recall should be styled differently in the UI to indicate that they are out-of-context)

[ ]  ⚠ [UI + backend] Enable viewing archival memory fragments in a modal (eg called "archival memory")

[ ]  [UI + backend] Allow modifying agent configs + base config via settings page

[ ]  [UI + backend] Allow attaching data (/attach) via a GUI / modal

[ ]  [UI + backend] Allow viewing available data sources (post /attach) via a GUI / modal

[ ]  [backend] REST requests for retrieving data in archival

[ ]  [backend] REST requests for retrieving data in recall

Saw new todos. Can work on some of them tomorrow!

Also @goetzrobin some weird jank happened with me merge of main into chatui (had to double merge), the diff looks OK but might want to make sure that the current cpacker/chatui is synced to the latest changes you made on this PR.

Code LGTM but FYI I'm still getting a hanging thinking but, is reproducible on my end when I do the following:

start server
message a working agent
go home
go to an agent i know that has a bad config
message, throws error (see below), but the POST response doesn't appear to be a non-success (200?) according to chrome dev tools
this results in the chat locking with a permanent "thinking..."
this also results in all the other agents locking with "thinking..."

Future exception was never retrieved
future: <Future finished exception=Exception('API call got non-200 response code (code=400, msg={"object":"error","message":"This model\'s maximum context length is 32768 tokens. However, you requested 32835 tokens (526 in the messages, 32309 in the completion). Please reduce the length of the messages or completion.","type":"invalid_request_error","param":null,"code":null}) for address: http://api.memgpt.ai/v1/completions. Make sure that the vLLM server is running and reachable at http://api.memgpt.ai/v1/completions.')>
Traceback (most recent call last):
...
    raise Exception(
Exception: API call got non-200 response code (code=400, msg={"object":"error","message":"This model's maximum context length is 32768 tokens. However, you requested 33284 tokens (3457 in the messages, 29827 in the completion). Please reduce the length of the messages or completion.","type":"invalid_request_error","param":null,"code":null}) for address: http://api.memgpt.ai/v1/completions. Make sure that the vLLM server is running and reachable at http://api.memgpt.ai/v1/completions.

Oh this is interesting. I think there is some things to iron out with error handling and connections closing, throwing errors. I think it has to do with the asyncio exception handling and the streaming response... Maybe figure out a better way to standardize this. I need to read up on this streaming response, error handling with asyncio and also aborting the post stream from the frontend


[SPARK-42297][SQL] Assign name to _LEGACY_ERROR_TEMP_2412

What changes were proposed in this pull request?
This PR proposes to assign name to _LEGACY_ERROR_TEMP_2412, "UNSUPPORTED_EXPR_FOR_WINDOW".
Why are the changes needed?

We should assign proper name to LEGACY_ERROR_TEMP*
Does this PR introduce any user-facing change?

No
How was this patch tested?

./build/sbt "sql/testOnly org.apache.spark.sql.SQLQueryTestSuite*"

cc @srielau @MaxGekk @cloud-fan PTAL when you find some time 🙏

+1, LGTM. Merging to master/3.4.
Thank you, @itholic and @srielau @khalidmammadov @LuciferYang for review.


Fix bundle entrypoint

Problem:
Upgrade pods are in StartError status.
Error: failed to create containerd task: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "--prepare": executable file not found in $PATH: unknown

Solution:
Fix entrypoint in the bundle image.
Related Issue:
https://github.com/rancher/harvester/issues/383

Updated


[C++][Python] Pass extra kwargs to S3 Pyarrow Filesystem

Describe the enhancement requested
AFAIK current implementation of Pyarrow s3fs does not support passing extra kwargs to the various APIs. One example is x-amz-request-payer (i.e. Requester pays) which cannot be set in get_file_info or open_input_file.
#10251 has addressed this for one particular use case (ACL) but a more general approach would be preferred
Component(s)
Python

Do you know of a more generic capability that exists in the S3 SDK?  We use that to make requests and so our ability to tackle things generically is somewhat limited by the SDK's APIs.  That being said, I don't have full knowledge of the SDK though and so maybe there is something that exists that I'm just not aware of.
For example, even though x-amz-request-payer is (conceptually) "just another HTTP header" the API exposes it as a property with getter and setter methods.  https://sdk.amazonaws.com/cpp/api/LATEST/aws-cpp-sdk-s3/html/class_aws_1_1_s3_1_1_model_1_1_put_object_request.html#a63072f3d8080c36ea6ad97851b22d255
I suppose we could perhaps expose the underlying HTTP headers though that seems a very crude tool.

I am not aware of a more generic capability. As you say the C++ SDK exposes the arguments as getter/setter and the Python APIs as additional arguments. I agree that passing them as HTTP headers wouldn't be recommended

Also marking my interest in being able to provide additional arguments to the underlying SDK.  My particular use case is around setting the SSECustomerAlgorithm and SSECustomerKey in get_object
As noted in https://github.com/apache/arrow/issues/10251, s3fs uses additional_kwargs and forwards these to the underlying botocore client.


Add support for building using bazel

This code change adds support for building using bazel if the --use-bazel flag is set. It will be unset by default.

TFTQR!


Remove direct dictionary access of schema values in core

This PR removes the last few direct accesses of schema values from core.py.
In order to facilitate this, I added some new functionality to the Schema class:

A class method for instantiating a Schema object from a manifest file, which can be shared by read_manifest() and _find_deps()
A method for getting a Schema object that provides a mutable reference to a history dictionary, for use in _merge_manifest()

I think there are a few other ways to tackle this, including moving the read_manifest() and _merge_manifest() methods into Schema itself. However, one minor annoyance is that the Schema object doesn't have access to the logger, so we'd have to remove a few warnings. Keeping the methods in the same place also gives a diff that's easier to review, and I made some changes to _merge_manifest() to fix a bug.
This PR also makes a few other semi-related changes:

Removes merge_manifest() from the core public API

This might have wanted to be its own PR, but I included it here since I had to touch it anyways to account for the _merge_manifest() API change. As far as I can tell we're not using this method in any of our own user code, and I don't anticipate other users really needing this - all user code I've seen just uses read_manifest().

Fixes a bug I introduced in #1147 that breaks the ability to read manifests into a particular job.

I snuck a few more changes in to refactor graph() - it includes a change to the getkeys() function to replace its behavior with no args with a new allkeys() function, which can take in a keypath prefix to restrict the return values.

Thanks for the feedback! I renamed get_history() and made the manifest filepath checks case-insensitive.
I should have been a bit clearer summarizing the public API changes, I'll do that here (with rationale):
Chip
Remove merge_manifest()

This method is a wrapper over a private method _merge_manifest(). The private method will stay.
We don't have any examples or user code that I can find that uses merge_manifest(). The private method is used to implement read_manifest(), which is what all the user code calls.
Happy to keep it if we can see a use for it, but I'd probably change the API slightly to take in a Schema object rather than a dictionary.

Schema
Add from_manifest()

This is a class method (think alternate constructor) that reads in a manifest and returns a schema object. It's a generalization of code that was repeated in 2 places: read_manifest() and _find_deps(). read_manifest() performs additional merging logic, so we want to keep that around. I do think it would be nice to add a from_manifest() method to the Chip class as well in a future PR.

Add history()

This is a getter that allows us to manipulate the history of a Schema object as a Schema object itself. It was necessary for cleaning up the low-level schema access in read_manifest() and _merge_manifest(). I'm not super happy with since it feels like a weird special-case, but I think in the future we may be able to eliminate it if we reimplement the history stuff to be nested instances of Schema objects.

Chip/Schema
Change getkeys() to eliminate special-case behavior

getkeys() with an argument returns a list of individual keys, but without an argument it returns a list of lists of all keypaths
I think there are cases where it's useful to iterate over the top-level keypaths, so I think it would be best to make its behavior more consistent

>>> chip.getkeys('option') # same behavior before and after change...
['remote', 'credentials', 'jobscheduler', 'mode', ...]
>>> chip.getkeys() # behavior BEFORE change
[['schemaversion'], ['design'], ['input', 'default', 'default'], ['output', 'default', 'default'], ...]
>>> chip.getkeys() # behavior AFTER change
['history', 'library', 'schemaversion', 'design', ...]

Add allkeys()

This already existed as a private method, and replaces the old getkeys() special-case behavior
This also provides additional functionality by accepting a keypath argument that specifies a prefix for what's returned. Currently the returned values do not include the prefix (which made some other code I'm working on simpler), but we can tweak that behavior

>>> chip.allkeys()
[['schemaversion'], ['design'], ['input', 'default', 'default'], ['output', 'default', 'default'], ...]
>>> chip.allkeys('flowgraph', 'default', 'default', 'default')
[['input'], ['weight', 'default'], ['goal', 'default'], ['tool'], ['task'], ['args'], ['valid'], ['timeout'], ['status'], ['select']]

Thanks for the justifications and updates!

Is 'from_manifest()' meant to be a public method? I am ok with it as long as we agree to do an API review as well in the next few weeks.
I find the new allkeys() / getkeys() behavior bit confusing for a public facing api. They do similar things but with different slightly different behavior. What is the actual motivation/use case for the user facting change?

Thanks for breaking down allkeys/getkeys offline.With changes to constructor, I am happy.😁

Sounds good, I made the constructor changes!

@gadfort I think there are quite a few places where we only check for lower case file suffixes. Can we defer that to a separate holistic PR and merge this one?

@gadfort I think there are quite a few places where we only check for lower case file suffixes. Can we defer that to a separate holistic PR and merge this one?

I think we can defer and merge this one. I'll make a note of it.


entry not available in edit form

Hi
after update the package to 3.1 , $this->entry   not available in edit form .
what is the problem ?

tried $entry?

yes ... not work

Can you please post some more code and describe the issue a little more then.
e.g Where are you trying this? in a template? if so which template? in a controller? in a model? in a bacon sandwich?

before version 3.1  $this->entry   in CrudController   return the entry  (actually when we  are in edit  form)
but after update the package $this->package not available in crudcontroller  . when I want to use it , this error happens :
Undefined property: App\Http\Controllers\Admin\PostCrudController::$entry

Sorry we still need to see code, cannot guess blind.
If you were to look inside vendor/backpack/crud/src/app/Http/Controllers/CrudController.php
You would see something like
public function edit($id)
    {
        $this->crud->hasAccessOrFail('update');

        // get the info for that entry
        $this->data['entry'] = $this->crud->getEntry($id);
        $this->data['crud'] = $this->crud;
        $this->data['saveAction'] = $this->getSaveAction();
        $this->data['fields'] = $this->crud->getUpdateFields($id);
        $this->data['title'] = trans('backpack::crud.edit').' '.$this->crud->entity_name;

        $this->data['id'] = $id;

        return view('crud::edit', $this->data);
    }

As you can see it does $this->data['entry'] and passes it to the crud edit template - which will convert into $entry
If you have changed your edit() methods and/or templates and are no longer passing all the expected information to the templates, then it wont be able to see it.
I would recommend to never touch the edit() create() or other core functions as it makes it harder to maintain. Try find alternative ways to achieving things to keep better maintainability.


feat: import project to CSS Library

Currently, the Project uses core CSS which is Hard or takes time to write. Instead of using core CSS, We can use TailwindCSS or other UI libraries like MaterialUI, Chakra UI etc.

Hey, @1010nishant,
In my opinion, Mui is a better option because it offers a range of pre-built components, a robust theming system, and is generally easier to comprehend.
If you'd like, I can work on this task.

@1010nishant @ronaklalwanii I think it is good for new comers in open source to understand and contribute. Many new developers don't know about TailwindCSS and other library. Maybe we can switch in future. What do you say?

@shyamtawli I agree, but it's better to write some utility classes for flex, grid, padding, margin, font-size etc. so that we can keep the UI consistent atleast.

@sampath88 Yes we can do that. If you want to do it, feel free to open a PR.

Hey @shyamtawli, Can I work on this issue? I will be able to enhance the project's CSS using Tailwind CSS.


Xcode 11 release build Yoga.cpp compiling error

Impossible to assemble release iOS build with latest Xcode 11.0 or 11.1.
During assembling release build we can see Yoga.cpp compiling error:
error: non-portable path to file ‘“/Users/distiller/mobile-web-app/ios/Pods/Target Support Files/yoga/yoga-prefix.pch”’; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
Full logs:
Building library libReact-jsiexecutor.a
[15:22:29]: ▸ Building library libReact-jsiexecutor.a
[15:22:30]: ▸ Compiling log.cpp
[15:22:30]: ▸ ❌  error: non-portable path to file ‘“/Users/distiller/mobile-web-app/ios/Pods/Target Support Files/yoga/yoga-prefix.pch”’; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
[15:22:30]: ▸ Compiling experiments.cpp
[15:22:30]: ▸ Compiling event.cpp
[15:22:30]: ▸ Compiling Yoga.cpp
[15:22:30]: ▸     The iOS deployment target ‘IPHONEOS_DEPLOYMENT_TARGET’ is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.1.99. (in target ‘react-native-version-number’ from project ‘Pods’)
[15:22:30]: ▸     The iOS deployment target ‘IPHONEOS_DEPLOYMENT_TARGET’ is set to 6.0, but the range of supported deployment target versions is 8.0 to 13.1.99. (in target ‘RSKImageCropper’ from project ‘Pods’)
[15:22:30]: ▸ ** ARCHIVE FAILED **
[15:22:30]: ▸ The following build commands failed:
[15:22:30]: ▸     CompileC /Users/distiller/Library/Developer/Xcode/DerivedData/Brandgility-ccncokfacuuibwcjplhtkspodqby/Build/Intermediates.noindex/ArchiveIntermediates/Brandgility/IntermediateBuildFilesPath/Pods.build/Release-iphoneos/Yoga.build/Objects-normal/armv7/event.o /Users/distiller/mobile-web-app/node_modules/react-native/ReactCommon/yoga/yoga/event/event.cpp normal armv7 c++ com.apple.compilers.llvm.clang.1_0.compiler
[15:22:30]: ▸ (1 failure)

With Xcode 10.2.1 everything works fine.
React Native version:
System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz
    Memory: 105.80 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.4.0 - ~/.nvm/versions/node/v12.4.0/bin/node
    Yarn: 1.19.0 - /usr/local/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v12.4.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.0, DriverKit 19.0, macOS 10.15, tvOS 13.0, watchOS 6.0
    Android SDK:
      API Levels: 23, 24, 25, 26, 27, 28
      Build Tools: 23.0.1, 25.0.1, 26.0.1, 26.0.2, 26.0.3, 27.0.3, 28.0.0, 28.0.3
      System Images: android-23 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom, android-23 | Google APIs Intel x86 Atom_64, android-25 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom
  IDEs:
    Android Studio: 3.5 AI-191.8<IP_ADDRESS>91312
    Xcode: 11.0/11A420a - /usr/bin/xcodebuild
  npmPackages:
    @react-native-community/cli: 2.9.0 => 2.9.0
    react: 16.9.0 => 16.9.0
    react-native: 0.61.2 => 0.61.2

Steps To Reproduce

Run assembling release build
Use Xcode 11.0 or 11.1
Check Build error during compiling Yoga.cpp

Expected result:
Build assembled correctly without Yoga.cpp compiling error.

@oleksandr-dziuban
I'm migrating from 0.59.1 to 0.61.2 and I solved this issue exporting the MapKit.framework.

I hope that solves your issue.

@EdgarXolop Thanks a lot! But could you please provide quick instructions where is this framework can be found to map it in Xcode? Thank you

@oleksandr-dziuban

Press the + button.

And search for the MapKit.framework here

Thanks a lot, will try to add it and check my CI flow again

@oleksandr-dziuban Were you able to solve your issue?
I finished migrating to 0.61.2

@EdgarXolop, not unfortunately I have same error, when Yoga.cpp compiles.
MapKit is not related to Yoga framework in my case.
Did you have this error with Yoga.cpp in your app?

I have finally found a workaround....
Just deleted all pods, deleted whole pods cache, deleted Pods folder from Git (it was under git to speed up CI builds) and everything is working now.
Closing this issue.

System:
    OS: macOS 10.15.5 (19F101)
  Binaries:
    Node: v10.15.1
    npm: 6.4.1

  IDEs:
    Xcode: 11.5 (11E608c)

  npm Packages:
   react: ^16.11.0
    react-native:0.62.2

@MahiK14 are you able to resolve this issue?

@MahiK14 I'm having the exact same issue (Xcode: 12.3, react-native: 0.62.2), I've already deleted my node modules and podfile and reinstalled them. Didn't work. Please let us know if you come up with any solutions

@MahiK14 I'm having the exact same issue (Xcode: 12.3, react-native: 0.62.2), I've already deleted my node modules and podfile and reinstalled them. Didn't work. Please let us know if you come up with any solutions

@ecemac I have solved it by reintsalling mac os in my system.

@ecemac I have solved it by reintsalling mac os in my system.


CASMINST-5667

Description
Add http_proxy verbiage for the purpose of downloading artifacts from external endpoints using a proxy
https://jira-pro.its.hpecorp.net:8443/browse/CASMINST-5667

[x] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[ ] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[ ] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

Comments left here: https://github.com/Cray-HPE/docs-csm/pull/2909/file


Debian ARM64 package ships an AMD64 Python

Related command
az
Describe the bug
azure-cli seems to ship its own python3, which does not run on arm64, despite being included in the arm64 package.
$ file /opt/az/bin/python3.10
/opt/az/bin/python3.10: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=31858101716e114b215ec920ba48d398ece36797, for GNU/Linux 3.2.0, with debug_info, not stripped

Running the following works around the issue:
sudo rm /opt/az/bin/python3 && sudo ln -s /usr/bin/python3 /opt/az/bin/python3

To Reproduce
Install azure-cli on arm64 Debian from the official Microsoft deb repo.
Expected behavior
az runs on aarch64
Environment summary

Debian sid (bookworm) aarch64 (VM on a M1 Max Macbook)
azure-cli is 2.44.1-1~bullseye
Using upstream packages.microsoft.com repo

$ cat /etc/apt/sources.list.d/packages_microsoft_com_repos_azure_cli.list
deb [arch=arm64] https://packages.microsoft.com/repos/azure-cli/ bullseye main

Additional context

Looks like the same issue as #22875


hex display and send raw data

In embedded debugging sometimes it is necessary to directly display and send raw binary data (hexadecimal data), hope to add it
Similar to this extension:https://github.com/imlinhanchao/vsc-serialport-helper

Thanks for linking to the example -- that will help a lot to design this feature correctly. Marking as a feature request.

I'd like to have this implemented as toggle autoscroll button, so when it active we see HEX data (and send input aslo accept only hex), when not - default ASCII

We're working on sending raw data such as hex through the input bar currently!

Support for sending hex data is now available in the pre-release channel. To switch to pre-release, simply click the pre-release icon in the VS Code Marketplace.

The upcoming release won't yet support viewing hex data in the output, so I'm renaming this issue to make it easier to track.

This suggestion is more practical

There is one other thing that needs to be added to serial monitor:
Microcontroller programmers usually send HEX numbers from the microcontroller to VS Code but Serial monitor can not show HEX codes.
Please add a feature to change RX view from TEXT to HEX to show the HEX codes or tell me the way to do this if it can do it.


Make AStar to use 64-bit logic

Should fix https://github.com/godotengine/godot/issues/43494

Can this be backported to 3.x? I need AStar to use the whole 64 bits of an int, not just 32...

Can this be backported to 3.x? I need AStar to use the whole 64 bits of an int, not just 32...

Changing a return type in any way breaks the GDNative API. This can be considered for 3.6, but not 3.5.


gulp test - errors

I did an update of the repo this afternoon and now experience many errors.
1984 specs, 1116 failures
Example
TypeError: undefined is not a constructor (evaluating 'expect($('.columnChart')).toBeInDOM()')

are you missing jasmine JQuery? Refer to this instruction in the ReadMe.
"Copy the jasmine-jquery.js Jasmine Extension Library file from GitHub into the following folder on your local machine "[PowerBIVisuals folder]\src\Clients\Externals\ThirdPartyIP\JasmineJQuery"  "


Salary Clustering

Description
Unsupervised Learning Algorithm for Salary Clustering
Fixes #1928

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md
[x] My documentation follows Template for README.md

Project Metadata
If there is no-file/nothing to fill the below fields with, then type: none
Example: If no requirements.txt needed/present, then type none in Requirments.
Category:

[x] AI/ML

Title: Unsupervised Learning Algorithm for Salary Clustering
Folder:K-Means-Clustering
Script: K-Means-Clustering/Unsupervised_Learning_.ipynb
Contributor: ayush-09
Description:Unsupervised_Learning

@avinashkranjan @Yashbhadiyadra Please review this PR


add debug tools to ytsaurus-odin docker image

Fixed here https://github.com/ytsaurus/ytsaurus/pull/496


Added today's assignments

:loud_sound: :volcano:

Should I be getting worried about these icons?


HDFS-16039. RBF: Some indicators of RBFMetrics count inaccurately

3086

 Quality gate: Failed
1 Issues

 1 Code issues

Details


ci: refactor website-only pipelines

fixes https://github.com/asyncapi/website/issues/1726
deploy.yml removed intentionally, it never worked and should not work - old leftover

@akshatnema approval please :D

/rtm


Error in PathEventProxy.disconnect

entry is an object but expected to be an array. Not sure how this is supposed to be.

Can you have a look? Error occurs when you click the link anno toggle.

Fixed via https://github.com/substance/substance/commit/8877e159caa68e8fbbb1d47404fdc56381b34fb2. Please review and close issue when ok.


[Feature] Do a docs-only forward build after reverse build (in watch mode?)?

In watch mode, it may be helpful to do a forward pass for only documentation output after a reverse pass.
This way, changes in code files are reflected also in documentation output, not only in the sources.

Fixed by #170.


Fix typo in README.md

Trivial fix. Please merge.

Thanks @esabol, your contribution has been approved and merged


istioctl: ztunnel-config cmds in examples should be experimental

Please provide a description of this PR:
The ztunnel-config command is an experimental command. The istioctl example output should reflect this to the user for consistency.

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

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bb911e247557d62f219ba844cc2afa8c0e988c92
link
true
/test release-notes

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

/retest


About test

Hi, thanks a lot for sharing your interesting and great work.
I ran test.py following your instructions but got results like this.

There are no results of vehicles. I noticed there is an args item "type", but it seems to only work for saving directory. Is there anything I got wrong?

Thanks for following our work. Since some datasets provide the annotations for road layout or vehicle occupancies only, we generate roads and vehicles separately, even Argoverse dataset.  Maybe you are using a road model, you should just replace it with a vehicle.
This is my test parameter for the vehicle model：
python test.py
--type dynamic
--model_path <path to the model directory. e.g. KITTI 3D Object>
--image_path <path to the image directory>
-out_dir ./output/kitti/3Dobject


feat(avatar): add user avatar as a component

Mandatory

[ ] What does this PR do?
Add User Avatar as a reusable component

[ ] What issue/task does this PR references?
https://openshift.io/openshiftio/openshiftio/plan/detail/2528

[ ] @mention(s) to expected reviewer(s) included
@sanbornsen @vikram-raj @rgarg1

Ike Plugins (test-keeper)
Thank you @SMahil for this contribution!

It appears that no tests have been added or updated in this PR.
Automated tests give us confidence in shipping reliable software. Please add some as part of this change.
If you are an admin or the reviewer of this PR and you are sure that no test is needed then you can use the command /ok-without-tests as a comment to make the status green.
For more information please head over to official documentation. You can find there how to configure the plugin - for example exclude certain file types so if PR contains only them it won't be checked.

@SMahil Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 and visit http://localhost:5000 to access it.

In Timeline section text moved to next line.

@SMahil Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 and visit http://localhost:5000 to access it.

@SMahil Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 and visit http://localhost:5000 to access it.

@jarifibrahim @Raunak1203 Pls retrigger the build. It failed due to rxjs issue, which is now resolved.

@SMahil Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 and visit http://localhost:5000 to access it.

[test]

[test]

[test]

[test]

[test]

@SMahil Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 and visit http://localhost:5000 to access it.

@Raunak1203 I am unable to reproduce this bug

@SMahil Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2665 and visit http://localhost:5000 to access it.


Fix a few nits in docker-rally.sh

Need to re-set xtrace after prepare.sh and rather than
return with the status, we need to exit with it.
Signed-off-by: Ryan Moats<EMAIL_ADDRESS>

LGTM, waiting on travis-ci before merging.


Deprecate Modulefile in favour of metadata.json

forgot this one

ah! so much better on Github with Travis working :)


Simularium Engine doesn't build with GCC 11

Description
The aws-sdk-cpp dependency fails to build with GCC 11, blocking local native builds on 'up-to-date' Linux distributions
Expected Behavior
A successful build with GCC 11
Reproduction
Attempt to build the project with GCC 11.x
Solution
Update the AWS SDK CPP, to receive relevant fixes needed to build w/ GCC 11

Is this related?
https://github.com/aws/aws-sdk-cpp/issues/1635

Yes,

Is this related/relevant?
aws/aws-sdk-cpp#1635

Yes, this is one of the (now resolved) issues. The fix they suggested didn't work in our case, but I was able to find a work-around between another similar issue and the gcc manual (additional flags, aws-sdk-build config, and disabling the auto-run tests).
Some others include:
https://github.com/aws/aws-sdk-cpp/issues/1697 (resolved)
https://github.com/sakra/cotire/issues/87 (not exactly, but similar)