How to check the file type is valid?

I'm using the following code to upload images:
require_once './vendor/autoload.php';

use AYazdanpanah\SaveUploadedFiles\File;
use AYazdanpanah\SaveUploadedFiles\Validator;
use Gumlet\ImageResize;

if(isset($_POST['submit'])) {
    $image_path = __DIR__ . "/images/user/123456";
    $export_image = function ($filename) use ($image_path) {
        //Add a  Validator: check if the file is image
        if (!is_type("image", $filename)) {
            throw new Exception("Your file is not an image!");
        }
        return exif_read_data($filename);
    };

    $validator = new Validator();

    $validator = $validator->setMinSize(1)
        ->setMaxSize(1024 * 3)
        ->setType(['jpg', 'png', 'jpeg']);

    $upload = new File();

    $upload = $upload->file('upload_image')
        ->setValidator($validator)
        ->setOverride(false)
        ->setSaveAs('my_image')
        ->save($image_path, $export_image);

    var_dump("<pre>", $upload, "</pre>");
}

As you see this a part of your example file!
Every thing is fine while I'm uploading images! but what about the situation which I try to upload a wrong file (Ex: index.php) ?
oops! the following exception will be thrown! while I was expecting that I would got an error!

Fatal error: Uncaught Error: Call to undefined method AYazdanpanah\SaveUploadedFiles\Validator::getType();

I have just fixed the bug and now you need to update the package:
composer update aminyazdanpanah/handling-file-uploads


https://github.com/phe-sto/enthic/blob/master/.github/workflows/shellcheck.yml obsolete

Hi,
The Github CI probably changed recently and the ShellCheck YAML description file seems obsolete. Even though it is not obvious, this step is just skipped.
The error raised is:
You have an error in your yaml syntax on line 1

https://github.com/phe-sto/enthic/pull/29/checks?check_run_id=2365711259 indicate the shellcheck step is now running. I think this issue can be closed once the PR https://github.com/phe-sto/enthic/pull/29 will be merge.


fix: Truncation on grouped cards

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[x] Refactoring

Needs Design check

@exezbcz please review

Context

[x] Closes #9321

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[x] My fix has changed UI

Copilot Summary
copilot:summary
copilot:poem

thanks!
pay 20 usd

😍 Perfect, I’ve sent the payout
💵 $20 @ 7.28 USD/DOT ~ 2.747 $DOT
🧗 16SjUbGKSdjCdWTy3NNT3JxbRVGGqD4mwkHpc6BD9U2Rp29Z
🔗 0xa7eb1b873c35ff939364f75ad1f2893ec4f738f2f33ab50bbc9ec35b78eea159
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Further refactoring of HostedCluster controller

Modifies *Name functions to return typed resources

/test e2e-aws

failed to create iam: cannot create worker role: Throttling: Rate exceeded

/retest

Looks like quay is down
'Failed to pull image "quay.io/hypershift/cluster-api:hypershift": rpc error: code = Unknown desc = can''t talk to a V1 docker registry'

/retest

/lgtm


precision problem about GEMM example

Following tutorial CPU GEMM, I ran this demo using cross-compilation on Cortex-A72 and my local machine. But it seems have a precision problem about decimal part as below:
yuens@Spark:~/Documents/charm/TVM_TRY$ python cross_compilation_and_rpc.py
[11:02:53] src/codegen/llvm/codegen_llvm.cc:75: set native vector to be 32 for target aarch64
Traceback (most recent call last):
  File "cross_compilation_and_rpc.py", line 49, in <module>
    np.testing.assert_equal(c.asnumpy(), answer)
  File "/usr/local/lib/anaconda2/lib/python2.7/site-packages/numpy/testing/utils.py", line 322, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "/usr/local/lib/anaconda2/lib/python2.7/site-packages/numpy/testing/utils.py", line 813, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/usr/local/lib/anaconda2/lib/python2.7/site-packages/numpy/testing/utils.py", line 739, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not equal

(mismatch 92.1112060547%)
 x: array([[ 247.566803,  256.043182,  244.30249 , ...,  252.350616,
         254.953583,  243.431519],
       [ 250.601807,  253.233948,  239.882767, ...,  246.857391,...
 y: array([[ 247.566772,  256.042938,  244.302505, ...,  252.350739,
         254.953506,  243.431747],
       [ 250.601807,  253.233917,  239.882919, ...,  246.857468,...

Code
I defined dtype=“float32” for a, b and c.
from __future__ import absolute_import, print_function
import tvm
import numpy as np
import numpy
from tvm.contrib import rpc, util

server = rpc.Server(host='<IP_ADDRESS>', port=9090)

# The size of the square matrix
N = 1024
# The default tensor type in tvm
dtype = "float32"
# Random generated tensor for testing
a = tvm.nd.array(numpy.random.rand(N, N).astype(dtype), tvm.cpu(0))
b = tvm.nd.array(numpy.random.rand(N, N).astype(dtype), tvm.cpu(0))
c = tvm.nd.array(numpy.zeros(shape=[N,N], dtype=dtype), tvm.cpu(0))
# The expected answer
answer = numpy.dot(a.asnumpy(), b.asnumpy())

# Algorithm
k = tvm.reduce_axis((0, N), 'k')
A = tvm.placeholder((N, N), name = 'A')
B = tvm.placeholder((N, N), name = 'B')
C = tvm.compute(
           A.shape,
           lambda x, y: tvm.sum(A[x, k] * B[k, y], axis = k),
           name = 'C')
# Default schedule
s = tvm.create_schedule(C.op)
func = tvm.build(s, [A, B, C], target='llvm -target=aarch64-linux-gnu -mcpu=cortex-a72 -mattr=+neon', name='mmult')
# save the lib at local temp folder
temp = util.tempdir()
path = temp.relpath('mylib.o')
func.save(path)

host = '<IP_ADDRESS>'
port = 9090
remote = rpc.connect(host, port)
remote.upload(path)
f = remote.load_module('mylib.o')

# create array on the remote device
ctx = remote.cpu(0)
a = tvm.nd.array(a.asnumpy().astype(dtype), ctx)
b = tvm.nd.array(b.asnumpy().astype(dtype), ctx)
c = tvm.nd.array(c.asnumpy().astype(dtype), ctx)
# the function will run on the remote device
f(a, b, c)
#np.testing.assert_equal(c.asnumpy(), answer)

time_f = f.time_evaluator(f.entry_name, ctx, number=1)
cost = time_f(a, b).mean
print('%g secs/op' % cost)

# terminate the server after experiment
server.terminate()

the default rtol of numpy is quite high, consider use a bigger rtol to, use assert_allcose with rtol

@tqchen I faced the similiar problem. For the default schedule, the test passed, but after applying several optimizations, I have to release the eps to pass numpy.testing.assert_allclose.

It is possible, because the summation order becomes different so the exact number may not match exactly

Yeah, I know. It is caused by the mechanism of float point add.

I think it is a non-ssue, should use numpy.testing.assert_allclose with released rtol


AOT Build supported?

Does this work with AOT?

Sure. The only thing you need to do is define the ngOnDestory method.

ok, perfect 👍 Another question:
here you do the check a second time, even though you did it in line 13. Is there a reason behind it?

Nope, it can be cached.


Unity just crashes when running

It hangs my GPU then unity saves my GPU and crashes itself, using Unity 2020.3.16f1

Did you read the error?  I'm pretty sure this just means that this code is unfortunately too performance intensive for your computer to run.

The gameObject that generates the world has a parameter to choose the number of points (per axis and chunk, i.e. 100 means each chunk has 1000000 points if I'm not mistaken).
Reducing this number might make world generation less GPU intensive.

I had the same issue here but I have a good GPU.

I also reduced the axis per chunk but still a crash I am on linux though.


Docker image missing for v0.20.3

Which version are you using?
v0.20.2
Which operating system are you using?

[ ] Linux amd64 standard
[x] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[ ] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue
Docker image missing on DockerHub for latest version.
Describe how to replicate the issue

check DockerHub for latest tag
latest tag not found
...

Did you attach the server logs?

no
Did you attach a network dump?

no

Thanks for reporting this, it has been fixed.


[CONTROLLER/CLOUD] supports learning huawei rds/redis

This PR is for:

Server

supports learning huawei rds/redis
Checklist

[ ] Added unit test.

Backport to branches

main

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.zhengya seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


ILU Preconditioning

This PR adds ILU preconditioning for our conjugate gradient method. The ILU factorizor should work for both 1d and 2d poisson matrices, provided the correct parameters are provided.
Changes
I have added the following new functions:

Under poisson_matrix_creaters.c:

createPoissonILU: regular version of the ILU factorization algorithm
getLfromPoissonILU: extracts the lower triangular part of the ILU factorization
getLfromPoissonILU: extracts the lower triangular part of the ILU factorization
createPoissonILUCSR: ILU factorization algorithm for a CSR formatted matrix
find_l: helper function for createPoissonILUCSR
getLfromPoissonILUCSR: extracts the lower triangular part of the ILU factorization for CSR matrices
getUfromPoissonILUCSR: extracts the upper triangular part of the ILU factorization for CSR matrices

Under preconditioner_solve:

ILU_PC_Solve: performs two triangular solves using the Incomplete L and U from the factorization functions described above.

I also updated the following functions:

Under preconditioner_solve.c:

PC_Solve: added parameters L and U both of type struct A_csr; added if-statement for selecting ILU_PC_Solve

Under mpi_pccg_solvers.c:

mpiPCCG_solveCSR: added parameters L and U both of type struct A_csr; updated calls to PC_Solve incorporating these parameters.
PCCG_CSRMPI_timer_output: added parameters L_CSR and U_CSR both of type struct A_csr; updated calls to mpiPCCG_solveCSR incorporating these parameters.

In PCCGbasicSolver: Added calls to the create... and getL/U functions to create variables ILU_CSR, L_CSR, U_CSR; added L_CSR and U_CSR to mpiCCG_solveCSR parameters.

Known issues:
Running solver with the ILU preconditioning option yields no solution (every entry is nan).

There are a few files that I need to cover with this PR that I haven't yet, specifically the PCCGTimer files. Will do this tomorrow or Thursday.

most recent commit sometimes causes this to happed:
PCCGbasicSolver.c Compiled with mpicc

free(): double free detected in tcache 2
free(): double free detected in tcache 2
[beloyarsk:04235] *** Process received signal ***
[beloyarsk:04235] Signal: Aborted (6)
[beloyarsk:04235] Signal code: User function (kill, sigsend, abort, etc.) (0)
[beloyarsk:04233] *** Process received signal ***
[beloyarsk:04233] Signal: Aborted (6)
[beloyarsk:04233] Signal code: User function (kill, sigsend, abort, etc.) (0)
[beloyarsk:04235] [ 0] [beloyarsk:04233] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x46520)[0x7fb81100c520]
[beloyarsk:04235] [ 1] /lib/x86_64-linux-gnu/libc.so.6(+0x46520)[0x7ff9072c6520]
[beloyarsk:04233] [ 1] /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0xf8)[0x7fb811060808]
[beloyarsk:04235] [ 2] /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0xf8)[0x7ff90731a808]
[beloyarsk:04233] [ 2] /lib/x86_64-linux-gnu/libc.so.6(raise+0x16)[0x7fb81100c476]
[beloyarsk:04235] [ 3] /lib/x86_64-linux-gnu/libc.so.6(abort+0xd7)[0x7fb810ff27b7]
[beloyarsk:04235] [ 4] /lib/x86_64-linux-gnu/libc.so.6(raise+0x16)[0x7ff9072c6476]
[beloyarsk:04233] [ 3] /lib/x86_64-linux-gnu/libc.so.6(abort+0xd7)[0x7ff9072ac7b7]
[beloyarsk:04233] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x8d5e6)[0x7fb8110535e6]
[beloyarsk:04235] [ 5] /lib/x86_64-linux-gnu/libc.so.6(+0x8d5e6)[0x7ff90730d5e6]
[beloyarsk:04233] [ 5] /lib/x86_64-linux-gnu/libc.so.6(+0xa4adc)[0x7fb81106aadc]
[beloyarsk:04235] [ 6] /lib/x86_64-linux-gnu/libc.so.6(+0xa4adc)[0x7ff907324adc]
[beloyarsk:04233] [ 6] /lib/x86_64-linux-gnu/libc.so.6(+0xa6a2f)[0x7fb81106ca2f]
[beloyarsk:04235] [ 7] /lib/x86_64-linux-gnu/libc.so.6(+0xa6a2f)[0x7ff907326a2f]
[beloyarsk:04233] [ 7] /lib/x86_64-linux-gnu/libc.so.6(free+0x55)[0x7fb81106ece5]
[beloyarsk:04235] [ 8] pccgbasic_sol.exe(+0x6763)[0x557e8d8b1763]
[beloyarsk:04235] /lib/x86_64-linux-gnu/libc.so.6(free+0x55)[0x7ff907328ce5]
[beloyarsk:04233] [ 8] pccgbasic_sol.exe(+0x6763)[0x56081abec763]
[beloyarsk:04233] [ 9] [ 9] pccgbasic_sol.exe(+0x6fe4)[0x557e8d8b1fe4]
[beloyarsk:04235] [10] pccgbasic_sol.exe(+0x6fe4)[0x56081abecfe4]
[beloyarsk:04233] [10] /lib/x86_64-linux-gnu/libc.so.6(+0x2dfd0)[0x7fb810ff3fd0]
[beloyarsk:04235] [11] /lib/x86_64-linux-gnu/libc.so.6(+0x2dfd0)[0x7ff9072adfd0]
[beloyarsk:04233] [11] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x7d)[0x7fb810ff407d]
[beloyarsk:04235] [12] pccgbasic_sol.exe(+0x1385)[0x557e8d8ac385]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x7d)[0x7ff9072ae07d]
[beloyarsk:04233] [12] pccgbasic_sol.exe(+0x1385)[0x56081abe7385]
[beloyarsk:04235] *** End of error message ***
[beloyarsk:04233] *** End of error message ***
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 0 on node beloyarsk exited on signal 6 (Aborted).
--------------------------------------------------------------------------
Job Run using mpirun - completed


ServerSocialScript line 145, ServerStarterScript line 56

11:30:24  -- OnServerInvoke can only be implemented on the server
11:30:24  -- Script 'Script Context.ServerCoreScripts/ServerSocialScript', Line 145
11:30:24  -- Stack End
11:30:24  -- OnServerEvent can only be used on the server
11:30:24  -- Script 'Script Context.ServerStarterScript', Line 56
11:30:24  -- Stack End
Every game. Local f9 developer console.
Are they localscripts or something?

Maybe a change with the engine.
-----Original Message-----
From: "Ayukito"<EMAIL_ADDRESS>Sent: 7/2/2016 11:42 AM
To: "ROBLOX/Core-Scripts"<EMAIL_ADDRESS>Subject: [ROBLOX/Core-Scripts] ServerSocialScript line 145,ServerStarterScript line 56 (#442)
11:30:24 -- OnServerInvoke can only be implemented on the server
11:30:24 -- Script 'Script Context.ServerCoreScripts/ServerSocialScript', Line 145
11:30:24 -- Stack End
11:30:24 -- OnServerEvent can only be used on the server
11:30:24 -- Script 'Script Context.ServerStarterScript', Line 56
11:30:24 -- Stack End
Every game. Local f9 developer console.
Are they localscripts or something?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Yeah, we discovered a weird little issue where the client thinks it's running the server because it hasn't fully initialized. Since the core scripts run so early, the client started running the server stuff as well.
It'll be fixed in the near future. In the meantime, sorry about the output spam! It won't break anything; that script isn't intended to run on the client anyway.

Ok
-----Original Message-----
From: "Kyle Emmerich"<EMAIL_ADDRESS>Sent: 7/2/2016 1:56 PM
To: "ROBLOX/Core-Scripts"<EMAIL_ADDRESS>Cc: "BinaryResolved"<EMAIL_ADDRESS>"Comment"<EMAIL_ADDRESS>Subject: Re: [ROBLOX/Core-Scripts] ServerSocialScript line 145,ServerStarterScript line 56 (#442)
Yeah, we discovered a weird little issue where the client thinks it's running the server because it hasn't fully initialized. Since the core scripts run so early, the client started running the server stuff as well.
It'll be fixed in the near future. In the meantime, sorry about the output spam! It won't break anything; that script isn't intended to run on the client anyway.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

This issue was moved to GitBlox/Core-Scripts#21

This bug seems to have the unintended consequence of breaking the ServerSocialScript(i.e. follower functionally) and the server dialog script.
This happens because the local versions of the ServerSocialScript and the server dialog script create their own RemoteEvents, which are then incorrectly invoked by the other localscripts instead of invoking the ones created by the server. Thus, the actual server scripts are not receiving the intended data, and thus both of these scripts are not functioning properly in game.

This should have been fixed on the engine level. I'll have to verify that though. It may not have been released yet.


Check Node version if not 4.0+

It would probably be pretty easy to check and do a graceful message if the Node version is below 4.0, instead of it throwing an ES6 syntax error. You could do this by having an <4.0 compatible first page that then loads the rest of the code after the check.
Just an idea.

What do you mean by "first page"? You mean a <4.0-compatible file that then requires the other files aftr a check? Will it work? I'll try.

Nice handling! :fire:


Raise exception when uploading more than 100MB to viv

I got a cryptic SSH error when trying to upload a file that was too large. The viv server doesn't accept anything larger than 100MB, so raise a informative exception when too large a file is being uploaded.
Testing:

covered by automated tests

Can one of you merge this? I'd don't have permissions


Keyboard manager and better RDP interactions

There are a host of issues filed against KBM regarding RDP.  We believe they are the same 'class' of bugs where if we fix one, we'll fix them all.
We'll be using this as the primary tracker issue for this host of bugs and break it into further issues once investigation is complete.

Note to dev: https://github.com/microsoft/PowerToys/issues/4756#issuecomment-659092399

@crutkas
I tested with the old and new Remote Connection client.

the new client transfers the local remapping to the remote machine, and you don't need to restart the KBM to work in order to get the precedence. There are some limitations, for example remapping shortcuts that use the Win key, don't seem to work.
the old client doesn't allow to transfer the local remapping to the remote machine, not even if you restart KBM and run it as admin after the connection is established. In that scenario you can still run KBM on the remote machine and it will work as expected, including shortcuts that use the Win key.

In my opinion, there is not much we can do about it beside documenting the behavior.
The only solution that would work for all cases is to implement a keyboard driver, but that is currently not an option.


Workbench contribution RemoteStartEntry blocked restore phase by 23ms

Run Code-OSS
Open dev tools
:bug: see Workbench contribution RemoteStartEntry blocked restore phase by 23ms (note that I see this even if I do not have the start entry enabled in settings)

IMHO this contribution does not need to appear in LifecyclePhase.Starting, because it appears in the Welcome page, which only kicks in on LifecyclePhase.Restored.
https://github.com/microsoft/vscode/blob/adaad1a6cd5cada95bb5b4ff2eb075f8accb0e09/src/vs/workbench/contrib/remote/browser/remote.contribution.ts#L25-L26
https://github.com/microsoft/vscode/blob/adaad1a6cd5cada95bb5b4ff2eb075f8accb0e09/src/vs/workbench/contrib/welcomeGettingStarted/browser/gettingStarted.contribution.ts#L327
I would suggest to also instantiate RemoteStartEntry in LifecyclePhase.Restored.

Like the idea

This is a good find 👍 , can we get this out for April? We should put startup perf improvements always in as soon as possible.

@bhavyaus ping

Thanks!


numpy bool type error

Have seen issues with numpy attributes under other conditions, but I am currently getting this one. Current setup:
python 3.9
numpy 1.24.0
vedo 2023.4.3
vtk 9.5.2
  File "/code/aind_smartspim_quantification/utils.py", line 189, in crop_cells
    cells_out = region_scaled.inside_points(cells)
  File "/opt/conda/envs/quantification/lib/python3.9/site-packages/vedo/mesh.py", line 1560, in inside_points
    mask = vtk2numpy(varr).astype(np.bool)
  File "/opt/conda/envs/quantification/lib/python3.9/site-packages/numpy/__init__.py", line 284, in __getattr__
    raise AttributeError("module {!r} has no attribute "
AttributeError: module 'numpy' has no attribute 'bool'

Hi @nal10 thanks for reporting this, it should be now fixed in the master:
pip install -U git+https://github.com/marcomusy/vedo.git


[3.3] Fix some angular velocity calculations

The angular velocity estimate for kinematic bodies was calculated
incorrectly. Also, fixes its use in some kinematic/rigid collision
calculations.
3.3 version of #47130

Thanks!


Readme update ssh

Issue #, if available:
Description of changes:

Added instructions on how to create a new EC2 instance and set it up in the same VPC as Neptune to be used as a bastion server
Added instructions for setting up an SSH tunnel on Windows

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

It is probably worth mentioning that an SSH tunnel is only one way to connect to Neptune. It's a simple and convenient way but there are others such as creating a load balancer.

Added this line to the first paragraph of Neptune README.md: "Please note that this wiki is not an official recommendation on network setups as there are many ways to connect to Amazon Neptune from outside of the VPC, such as setting up a load balancer or VPC peering." @krlawrence
Moved content to from primary README.md to neptune/README.md @austinkline

The JSON seems to have lost its indentation.


Added a method to return the dependency levels to DepenendencyGraph.java class

Purpose
Added a method to return the dependency levels to DepenendencyGraph.java class
Fixes #43027
Check List

[ x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

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

@hinalp02 please properly tick the Contributing Guide and other items in the check list.


[WIP] Add dedicated optimization pass for fusion

This PR repurposes most of the code in #11 to enable Blockwise/IO fusion as a distinct optimization pass. Note that this iteration is designed to compose and fuse arbitrary groups of Fusable Exprs where no members of the group have external "dependents" (e.g. diamond-shaped sub-graphs).
Supersedes #11
TODO:

[ ] Clean up and organize new utilities

Oh fun.  I look forward to reviewing this.  My afternoon is somewhat packed, but hopefully tomorrow morning (or this afternoon if I find some time)

I hope you don't mind I pushed a minor change (hopefully good)

@rjzamora how best can I help on this PR?  Are you waiting for me on any particular decision or do you have a clear path to proceed?

I hope you don't mind, but I cleaned up substitute a little, added tests for it, and pushed.

Type checks are pretty cheap.  I'm curious what the motivation is to avoid type checks.

Going a different direction, here are the things that are stopping me from pressing the green button.  This is what I would probably prioritize in order to get this in:

Make sure that we have good tests for this functionality
Make sure that tests are fast
Consider finding a new name for _blockwise_subgraph (but maybe keep it if we think it's the best we can find)
Make sure that we have docstrings for things (example IndexableArg doesn't describe its parameters)

Do you have other thoughts for larger concerns?

I'm referring to code complexity

Or maybe I'm missing something.  Is there serious code complexity currently due to this?  Types aren't currently hitting  warning bells for me in the same way that slow tests, test coverage, and docstrings are.

This is the case today I think?

It is at the Expr level, but the IO methods then include IndexableArg objects in their dependencies output. I'm just saying that there is no real reason that IndexableArg couldn't be a lightweight Expr subclass.

Make sure that we have good tests for this functionality

Do you think we can do this without having "broadcastable" operations to break fusion into multiple groups?

Make sure that tests are fast

If the problem is just in assert_eq, do we just use smaller collections and fewer expressions?

These are dataframes with ~100 rows. It's hard for me to believe that computation is what's taking up time. It's got to be something in our code. Maybe I'm wrong though? Have you profiled here? Saying that assert_eq is slow could mean, for example, that graph generation is slow or meta generation is slow or many other things that are still in this code base

I'm profiling now. It's definitely our fault.  One sec, I'll see if I can push up a change.
For context on how I identified this, I like using snakeviz, so I removed parameters from the test
diff --git a/dask_match/tests/test_collection.py b/dask_match/tests/test_collection.py
index b663cf4..0095766 100644
--- a/dask_match/tests/test_collection.py
+++ b/dask_match/tests/test_collection.py
@@ -170,8 +170,11 @@ def test_optimize_fusion(ddf):
     assert len(fused_2.dask) == len(fused.dask) + 1

-@pytest.mark.parametrize("persist", [True, False])
-def test_optimize_fusion_many(ddf, persist):
+def test_optimize_fusion_many():
+    persist = False
+    df = pd.DataFrame({"x": range(100)})
+    df["y"] = df.x * 10.0
+    ddf = from_pandas(df, 10)

Then I install snakeviz
mamba install snakeviz

Then I did the following in ipython
from dask_match.tests.test_collection import test_optimize_fusion_many
test_optimize_fusion_many()
%load_ext snakeviz
snakeviz test_optimize_fusion_many()

That gave me this view:

I'll go throw cached_property around on a few methods and see what happens.

Yeah, my local branch has a few more cached_property decorators - Things are certainly faster if you cache the _layer result.

With my recent commit we cache only small things (_meta, _name) and I've got tests down to about 1.5s

profiling shows that the rest of the time is spent in the dask local scheduler, and matchpy (about half-half)

Snakeviz screenshot

There's still room for improvement, but only about 20-30% of total I think.

Okay - I added in basic broadcasting support for now. I will shift focus on making the necessary changes for this to be merged:

Improve tests
"Make sure that tests are fast" (probably need to re-profile)
"Consider finding a new name for _blockwise_subgraph" - I don't personally care much about this name. Feel free to suggest any name you like.
Add/improve missing docstrings

Pushed a couple more:

I noticed None names in the graph, I think from from_pandas
I added a basic broadcast test.   It seems like this is important to us, is potentially tricky, and is an easy thing to test in isolation

I've cleaned them up (at least according to my aesthetics) and pushed to a new file

I've renamed _blockwise_subgraph to _blockwise_layer.  I don't love this name either, but it at least reuses the same term "layer" that is used elsewhere in the codebase.  Hopefully that helps newcomers quickly identify the structure of what that method does.

Merging later today if there are no further comments

I've renamed _blockwise_subgraph to _blockwise_layer

Seems like a reasonable name to me.

Merging later today if there are no further comments

Sounds good. Thanks for cleaning things up!


Added startup for result backends.

Fixes #116.

Codecov Report

Merging #118 (fd20866) into develop (e66f3aa) will decrease coverage by 3.24%.
The diff coverage is 44.28%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##           develop     #118      +/-   ##
===========================================
- Coverage    67.62%   64.39%   -3.24%
===========================================
  Files           37       39       +2
  Lines          942     1025      +83
===========================================
+ Hits           637      660      +23
- Misses         305      365      +60

Impacted Files
Coverage Δ

taskiq/cli/watcher.py
0.00% <ø> (ø)

taskiq/cli/worker/process_manager.py
0.00% <0.00%> (ø)

taskiq/cli/worker/run.py
0.00% <0.00%> (ø)

taskiq/receiver/params_parser.py
96.87% <ø> (ø)

taskiq/utils.py
72.72% <25.00%> (-27.28%)
:arrow_down:

taskiq/middlewares/prometheus_middleware.py
26.78% <26.78%> (ø)

taskiq/brokers/zmq_broker.py
45.71% <28.57%> (+5.17%)
:arrow_up:

taskiq/abc/broker.py
83.51% <60.00%> (-1.88%)
:arrow_down:

taskiq/receiver/receiver.py
89.69% <91.30%> (ø)

taskiq/__init__.py
100.00% <100.00%> (ø)

... and 9 more

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Loading the following snippet (Snipmate-like) breaks the engine

Some extra details that may be useful:
I'm using it as a custom snippet for markdown files
I have installed friendly-snippets
I use the snippets via nvim-cmp
I load the custom snippets via
require("luasnip.loaders.from_snipmate").lazy_load({ paths = { "./custom-snippets" } })
This is the snippet that makes it fail:
snippet bno  "Code block without pygments"
    ``` { use_pygments=false }
    ${0}
    ```

This is the error:
E5108: Error executing lua ...pack/packer/start/LuaSnip/lua/luasnip/util/functions.lua:39: Vim(echo):E121: Undefined variable: use_pygments
stack traceback:
        [C]: in function 'nvim_exec'
        ...pack/packer/start/LuaSnip/lua/luasnip/util/functions.lua:39: in function 'fn'
        ...k/packer/start/LuaSnip/lua/luasnip/nodes/dynamicNode.lua:134: in function 'update'
        .../pack/packer/start/LuaSnip/lua/luasnip/nodes/snippet.lua:813: in function 'update'
        .../pack/packer/start/LuaSnip/lua/luasnip/nodes/snippet.lua:504: in function 'trigger_expand'
        ...nvim/site/pack/packer/start/LuaSnip/lua/luasnip/init.lua:233: in function 'snip_expand'
        ...e/pack/packer/start/cmp_luasnip/lua/cmp_luasnip/init.lua:143: in function 'execute'
        .../nvim/site/pack/packer/start/nvim-cmp/lua/cmp/source.lua:390: in function 'execute'
        ...e/nvim/site/pack/packer/start/nvim-cmp/lua/cmp/entry.lua:478: in function 'execute'
        ...re/nvim/site/pack/packer/start/nvim-cmp/lua/cmp/core.lua:487: in function <...re/nvim/site/pack/packer/start/nvim-cmp/lua/cmp/core.lua:486>
        ...te/pack/packer/start/nvim-cmp/lua/cmp/utils/feedkeys.lua:47: in function <...te/pack/packer/start/nvim-cmp/lua/cmp/utils/feedkeys.lua:45>

Oh, wow, that's a first xD
Hmm, seems like the problem is just that `` are normally meant to delimit a vimscript-expression. Would you add a backslash before each `?

I've tried the following snippet but it still produces the same error.
snippet bno  "Code block without pygments"
    \`\`\` { use_pygments=false }
    ${0}
    \`\`\`

Srry, this snippet is working on my end.
Both via
ls.snip_expand(ls.parser.parse_snipmate("", "\\`\\`\\` { use_pygments=false }\n${0}\n\\`\\`\\`"))

and when loading it with the snipmate-loader.
Could you test it again? Maybe the old version was still in there or something

Sorry, you were right the single backslash worked properly I'm using vimwiki to handle markdown files and I forgot to update vimwiki.snippets.

Ahh okay, nice👍
I'll extend the doc with a note about this, there might not be one


[backport] Allow snapshot_object have condition and writer option (backport #6762)

Manual backport of #6762 .

The diff itself looks good to me.
@toslunar Do you think we should backport this feature?
I think this PR is a feature addition, not enhancement.

While it's not usual to backport this, let me wait for the decision whether #6856 is backported to v6.

@toslunar We agreed to backport #6856, so let's merge this.
Jenkins, test this please

Jenkins CI test (for commit fb9dfb8e5c0cd3f6281275c2d081858648190331, target branch v6) failed with status FAILURE.

LGTM

Thanks!


doc: add diagrams for standalone and no-BMC

Signed-off-by: Boris Glimcher<EMAIL_ADDRESS>

Is it possible to add a white or other coloured background to the images? The current transparent background doesn't work if you use the github website with the dark template as a lot of people I know do (incl. myself)....

Reference

@stolsma sure, can you show me how to change it on http://draw.io/ ?

Reference

@stolsma sure, can you show me how to change it on http://draw.io/ ?

Hmmmm.... to be honest I don't have a clue but I will try to find out 🤔

Reference

@stolsma sure, can you show me how to change it on http://draw.io/ ?

Hmmmm.... to be honest I don't have a clue but I will try to find out 🤔

:-) same here

@glimchb Found it! Right side on the Diagram tab->background box! 😀

@glimchb Found it! I think... 😊Right side on the Diagram tab->background box! 😀

great, thanks

@stolsma I will merge this and then we change background as a separate commit, hope this works for you


Clarify "desktop"

Hi, it mentions "desktop" in this article. It would be worth clarifying if it works or does not work on other "desktops" such as Windows365, RDC, etc.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 9b8d11e4-f9c6-383a-38d4-6cf7633edb7c
Version Independent ID: 7015ed77-ae66-cc97-301c-b0c6ebfb2bd3
Content: Screen capture - UWP applications
Content Source: uwp/audio-video-camera/screen-capture.md
Product: uwp
Technology: audio-video-and-camera
GitHub Login: @drewbatgit
Microsoft Alias: drewbat

@dombat, thanks for calling this out. This page was authored during the Windows Phone era, so in this case it's not even referring to the "desktop", as-in the thing you see when all windows are minimized. I updated the content to refer to "Windows desktops", which hopefully will help to clarify.


Defining a stable core API for better maintainability

Proposal: Defining a stable core API for better maintainability
Description
As a developer using Bevy for project development, I've encountered challenges with maintaining my projects due to the rapid evolution of the Bevy API. While I understand and appreciate the reasons behind the frequent changes (rapid iteration, performance improvements, keeping up with the evolving Rust gamedev ecosystem), I believe that defining a stable core API could provide significant benefits for project maintainability and long-term adoption.
Proposal
I suggest that we consider defining a stable core API that encapsulates the fundamental primitives and patterns that are unlikely to change frequently. This could include things like:

Colors
Transforms
Basic ECS composition and usage
Core math types and operations
Key input event handling
Basic rendering setup and configuration

The goal would be to provide a fixed, well-documented API for these core concepts that developers can rely on across Bevy versions, even as the wider framework continues to evolve and improve.
Potential Benefits

Improved maintainability for long-lived projects
Reduced upgrade friction and breaking changes for fundamental use cases
A stable foundation for learning Bevy and building reusable libraries
Increased adoption and confidence in using Bevy for serious projects

Potential Approaches

Carefully designing core APIs with forwards/backwards compatibility in mind
Providing a separate "core" library with a fixed API, distinct from the main library
Maintaining thorough documentation and guides for the stable APIs
Providing detailed changelogs and migration guides for any necessary breaking changes
Offering a slower-moving, stability-focused release channel in addition to the current cutting-edge channel

Open Questions

What specific primitives and patterns should be included in the stable core?
How do we balance stability with the need for ongoing improvement and evolution?
How do we handle necessary breaking changes to the stable core over time?
What's the best way to structure and distribute a stable core API alongside the main library?

I'm open to discussion and feedback on this proposal. I believe that with careful design and community input, we could define a stable core that would make Bevy even more powerful and appealing for long-term, serious project development.
Cheers,
Neshume

But i would suggest after the minimum vertical slice implementation mvp..what that mvp is good discusion. I think at least some editor (i dont need it) but is better for adoption,basic buildin physcs, 2d light,audio and ui. Basic 3d anim and navigation. Asset prperation.. my fear is that we keep updating 3d and the api and try to compete with unreal..

I totally get where you're coming from about defining an MVP and focusing on features like an editor or built-in physics—those are definitely important for adoption and growth.
That said, my main point here was more about the stability of the core API—things like transforms, colors, and basic ECS patterns. These are the building blocks that a lot of us rely on, and having them stay stable across versions would make it so much easier to maintain projects long-term.
;o)
I think Bevy can avoid the whole "compete with Unreal" thing by doubling down on being lightweight, flexible, and reliable. Even if other features evolve (and they should!), having a stable foundation gives everyone a solid starting point.
Cheers,
Neshume

There's still a lot of major changes to the public API being made which would make this kind of stabilisation very challenging. For example, the no_std support I'm adding is technically a massive set of breaking changes, since you now must enable an std feature if you were disabling defaults. Once bsn, relationships, the editor, and probably several other major APIs I'm not thinking of right now ship, maybe there'd be room to stabilise APIs. But right now, there's still debate around fundamentals like whether Resource should just be a component, or if observers should include an on_mutate hook.

I don't think rendering is ready to commit to any stable APIs. I expect not just the internals to change, but basic stuff like the Mesh, Material, and RenderGraph APIs to get major overhauls at some point in the future. Additionally, every time we upgrade wgpu that's a breaking change.

https://bevyengine.org/learn/contribute/introduction/

Bevy also currently has the following "development process" goals:

Rapid experimentation over API stability: We need the freedom to experiment and iterate in order to build the best engine we can. This will change over time as APIs prove their staying power.


Incorrect Toast Message Displayed for Blocked/Disabled User Access Attempt

Expected behavior
The toast message should accurately convey that the user account is blocked or disabled, providing clear information to the user about the reason for denied access.
Steps to reproduce the issue
Block or disable a user account within the application.
Attempt to access the application using the blocked or disabled user account credentials.
Observe the toast message displayed upon denied access.
Environment details

App version: v1.6.0
Testing Environment: UAT

Additional information

@dt2patel Sir, Currently we are thinking of updating the message to Sorry, either your login details are incorrect, or your account has been disabled or blocked. Please try again or contact administrator.. As its difficult to identify from the api response that whether the credentials are wrong or account is blocked.

Let's work on improving the API response. @ymaheshwari1 we can discuss in person

UI for blocked user will be handled in this issue:
https://github.com/hotwax/dxp-components/issues/204


[🐛 BUG]: Error while declaring metrics by on_init command: duplicate metrics collector registration attempted

No duplicates 🥲.

[X] I have searched for a similar issue in our bug tracker and didn't find any solutions.

What happened?
A bug happened!
Version (rr --version)
version: 2023.2.0, buildtime: 2023-07-06T19:02:05+0000
How to reproduce the issue?
Try to init some metrics by on_init command and got error "duplicate metrics collector registration attempted".
Demo: see metric.php, rr.yaml and README.md
Relevant log output
2023-07-19T10:47:02+0000        DEBUG   rpc             plugin was started      {"address": "tcp://<IP_ADDRESS>:6001", "list of the plugins with RPC methods:": ["app", "metrics", "informer", "resetter", "lock"]}
2023-07-19T10:47:02+0000        DEBUG   metrics         declaring new metric    {"name": "test", "type": "counter", "namespace": ""}
2023-07-19T10:47:02+0000        DEBUG   metrics         metric successfully added       {"name": "test", "type": "counter", "namespace": ""}
2023-07-19T10:47:02+0000        DEBUG   metrics         adding metric   {"name": "test", "value": 1, "labels": []}
2023-07-19T10:47:02+0000        DEBUG   metrics         metric successfully added       {"name": "test", "labels": [], "value": 1}
2023-07-19T10:47:02+0000        INFO    server          ON INIT
handle_serve_command: Function call error:
        got initial serve error from the Vertex *metrics.Plugin, stopping execution, error: duplicate metrics collector registration attempted

Hey @Kaspiman 👋🏻
I don't think this is the on_init case. Since you are trying to declare the metric twice, which is not allowed by Prometheus, this is the worker problem.

You can use lock plugin: https://github.com/roadrunner-php/lock to prevent registration of the same metrics. Regustration should be done by the one process (worker). Lock the resource with a wait time like 1 millisecond. Only 1 worker would be able to get a lock. Then register all needed metrics and release the lock.

Two calls of rpc declare looks like that:
2023-07-19T11:21:13+0000        DEBUG   rpc             plugin was started      {"address": "tcp://<IP_ADDRESS>:6001", "list of the plugins with RPC methods:": ["metrics", "app", "lock", "resetter", "informer"]}
2023-07-19T11:21:13+0000        DEBUG   metrics         declaring new metric    {"name": "test", "type": "counter", "namespace": ""}
2023-07-19T11:21:13+0000        DEBUG   metrics         metric successfully added       {"name": "test", "type": "counter", "namespace": ""}
2023-07-19T11:21:13+0000        DEBUG   metrics         declaring new metric    {"name": "test", "type": "counter", "namespace": ""}
2023-07-19T11:21:13+0000        ERROR   metrics         metric with provided name already exist {"name": "test", "type": "counter", "namespace": ""}
2023-07-19T11:21:13+0000        INFO    server
Fatal error: Uncaught Spiral\Goridge\RPC\Exception\ServiceException: Error 'metrics_plugin_declare: tried to register existing collector with the name `test`' on tcp://<IP_ADDRESS>:6001 in /var/www/html/vendor/spiral/goridge/src/RPC/RPC.php:101
Stack trace:
#0 /var/www/html/vendor/spiral/goridge/src/RPC/RPC.php(75): Spiral\Goridge\RPC\RPC->decodeResponse(Object(Spiral\Goridge\Frame), NULL)
#1 /var/www/html/metric.php(28): Spiral\Goridge\RPC\RPC->call('Declare', Array)
#2 {main}
  thrown in /var/www/html/vendor/spiral/goridge/src/RPC/RPC.php on line 101
2023-07-19T11:21:13+0000        ERROR   server          process wait    {"error": "exit status 255"}
[INFO] RoadRunner server started; version: 2023.2.0, buildtime: 2023-07-06T19:02:05+0000

I tried on_init but it does not working

It's hard to tell what's happening in your env. The on_init command is called once after the server plugin initialization. But the fact is that somewhere (maybe in the regular worker) or in the configuration, you have already declared this metric and trying to re-declare it then.

It's easy to see what's happening in my env because i attached DEMO with simple reproduce steps

As I mentioned, the problem is somewhere in your env.
Tested on the following inputs:

config:

version: '3'

metrics:
  address: '<IP_ADDRESS>:9254'

logs:
  level: debug
  mode: development

rpc:
  listen: 'tcp://<IP_ADDRESS>:6001'

server:
  command: "php foo"
  on_init:
    command: "php ../../php_test_files/on-init-metrics.php"

worker:

require __DIR__ . '/vendor/autoload.php';

use Spiral\Goridge\Relay;
use Spiral\Goridge\RPC\RPC;

$rpc = new RPC(
    Relay::create('tcp://<IP_ADDRESS>:6001')
);
echo "foo";
$rpc = $rpc->withServicePrefix('metrics');

$rpc->call('Declare', [
    'name'      => 'test',
    'collector' => [
        'namespace' => '',
        'subsystem' => '',
        'type'      => 'counter',
        'help'      => '',
        'labels'    => [],
        'buckets'   => [],
    ],
]);

echo "foo2";
$rpc->call('Add', [
    'name'   => 'test',
    'value'  => 1.0,
    'labels' => [],
]);

echo "ON INIT";

logs:

2023-07-19T15:56:42+0000	DEBUG	rpc         	plugin was started	{"address": "tcp://<IP_ADDRESS>:6001", "list of the plugins with RPC methods:": ["metrics"]}
{"time":"2023-07-19T17:56:42.265395585+02:00","level":"DEBUG","msg":"calling serve method","plugin":"*logger.Plugin"}
{"time":"2023-07-19T17:56:42.265400356+02:00","level":"DEBUG","msg":"calling serve method","plugin":"*metrics.Plugin"}
{"time":"2023-07-19T17:56:42.265407797+02:00","level":"DEBUG","msg":"calling serve method","plugin":"*server.Plugin"}
2023-07-19T15:56:42+0000	INFO	server      	foo
2023-07-19T15:56:42+0000	DEBUG	metrics     	declaring new metric	{"name": "test", "type": "counter", "namespace": ""}
2023-07-19T15:56:42+0000	DEBUG	metrics     	metric successfully added	{"name": "test", "type": "counter", "namespace": ""}
2023-07-19T15:56:42+0000	INFO	server      	foo2
2023-07-19T15:56:42+0000	DEBUG	metrics     	adding metric	{"name": "test", "value": 1, "labels": []}
2023-07-19T15:56:42+0000	DEBUG	metrics     	metric successfully added	{"name": "test", "labels": [], "value": 1}
2023-07-19T15:56:42+0000	INFO	server      	ON INIT
{"time":"2023-07-19T17:56:42.275236164+02:00","level":"DEBUG","msg":"serving"}
{"time":"2023-07-19T17:56:47.27813494+02:00","level":"DEBUG","msg":"calling stop"}
{"time":"2023-07-19T17:56:47.27827736+02:00","level":"DEBUG","msg":"calling stop function","plugin":"*server.Plugin"}
{"time":"2023-07-19T17:56:48.279396177+02:00","level":"DEBUG","msg":"calling stop function","plugin":"*rpc.Plugin"}
{"time":"2023-07-19T17:56:48.279640634+02:00","level":"DEBUG","msg":"calling stop function","plugin":"*metrics.Plugin"}
{"time":"2023-07-19T17:56:48.279796815+02:00","level":"DEBUG","msg":"calling stop function","plugin":"*logger.Plugin"}

I would be happy to help you, but I do not have a reproduction of the problem.

Reopening, looks like I found a problem.


this is very useful!

Thanks, with this and candle, there's a good chance to replace rust-bert.
Will you be planning to be covering more rust-bert pipelines?

Hi @jondot, thanks!
Yes, my idea is at some point cover all the pipelines offered in https://github.com/huggingface/transformers + embeddings pipelines. Right now I'm implementing the ones I think are most used: text-classification, token-classification, text-generation, etc.


Unable to build against ffmpeg 2.5.3

On Debian 7.4, I have built and installed a local copy of ffmpeg mostly by following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
The only change is that I had to run ffmpeg's configure script with the --enable-pic option, in addition to the other options already listed.
When I try to build PyAV by running make inside PyAV's directory, I get this:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -O0 -g build/temp.linux-x86_64-2.7/src/av/packet.o -L/home/ksze/ffmpeg_build/lib -lSDL -lX11 -lXext -lXv -lasound -lass -lavcodec -lavdevice -lavfilter -lavformat -lavutil -lbz2 -ldl -lfdk-aac -lfreetype -ljack -llzma -lm -lmp3lame -logg -lopus -lpostproc -lpthread -lrt -lswresample -lswscale -ltheoradec -ltheoraenc -lva -lvorbis -lvorbisenc -lvpx -lx264 -lxcb -lxcb-render -lxcb-shape -lxcb-shm -lxcb-xfixes -lz -o build/lib.linux-x86_64-2.7/av/packet.so
/home/ksze/ffmpeg_build/lib/libavutil.a(frame.o): In function `av_frame_get_best_effort_timestamp':
/home/ksze/ffmpeg_sources/ffmpeg/libavutil/frame.c:30: multiple definition of `av_frame_get_best_effort_timestamp'
build/temp.linux-x86_64-2.7/src/av/packet.o:/home/ksze/PyAV/include/libavcodec/avcodec.pyav.h:6: first defined here
/home/ksze/ffmpeg_build/lib/libavutil.a(mem.o): In function `av_calloc':
/home/ksze/ffmpeg_sources/ffmpeg/libavutil/mem.c:253: multiple definition of `av_calloc'
build/temp.linux-x86_64-2.7/src/av/packet.o:/home/ksze/PyAV/include/libavutil/avutil.pyav.h:8: first defined here
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
make: *** [build] Error 1

Would you know what's the problem and how to fix it?

Ok, I think this has to do with library and function detection (ffmpeg vs libav), as discussed in #2. However, I can't find anything pertaining to autoconf in the repository - e.g. I can't find a configure.ac file. So what are we really supposed to do to make it detect ffmpeg vs libav and define the macros correctly? There is no mention in the installation instructions (http://mikeboers.github.io/PyAV/#installation).

So it appears that you are not actually using autoconf afterall. I found the check_for_func function in setup.py
Here is some more debugging info, by adding a couple of print and pprint statements to check_for_func (you can find the print and pprint changes here: https://github.com/ksze/PyAV/commit/d3d593f55d1b66d42161df31750e29f9bb8dc043):
$ PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" make
CFLAGS="-O0" LDFLAGS="" python setup.py build_ext --inplace --debug
avformat found.
lib_paths:
['libavformat.so.53', u'/home/ksze/ffmpeg_build/lib/libavformat.so.53']
Found avformat at libavformat.so.53
avutil found.
lib_paths:
['libavutil.so.51', u'/home/ksze/ffmpeg_build/lib/libavutil.so.51']
Found avutil at libavutil.so.51
avcodec found.
lib_paths:
['libavcodec.so.53', u'/home/ksze/ffmpeg_build/lib/libavcodec.so.53']
Found avcodec at libavcodec.so.53
av_frame_get_best_effort_timestamp not found in any of ['avformat', 'avutil', 'avcodec'].
avformat found.
lib_paths:
['libavformat.so.53', u'/home/ksze/ffmpeg_build/lib/libavformat.so.53']
Found avformat at libavformat.so.53
Found avformat_close_input in avformat (libavformat.so.53).
avformat found.
lib_paths:
['libavformat.so.53', u'/home/ksze/ffmpeg_build/lib/libavformat.so.53']
Found avformat at libavformat.so.53
avformat_alloc_output_context2 not found in any of ['avformat'].
avutil found.
lib_paths:
['libavutil.so.51', u'/home/ksze/ffmpeg_build/lib/libavutil.so.51']
Found avutil at libavutil.so.51
av_calloc not found in any of ['avutil'].
running build_ext
writing build/temp.linux-x86_64-2.7/include/pyav/config.h
running cythonize
building 'av.packet' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -O0 -fPIC -g -I/home/ksze/ffmpeg_build/include -Iinclude -I/usr/include/python2.7 -Ibuild/temp.linux-x86_64-2.7/include -c src/av/packet.c -o build/temp.linux-x86_64-2.7/src/av/packet.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -O0 -g build/temp.linux-x86_64-2.7/src/av/packet.o -L/home/ksze/ffmpeg_build/lib -lSDL -lX11 -lXext -lXv -lasound -lass -lavcodec -lavdevice -lavfilter -lavformat -lavutil -lbz2 -ldl -lfdk-aac -lfreetype -ljack -llzma -lm -lmp3lame -logg -lopus -lpostproc -lpthread -lrt -lswresample -lswscale -ltheoradec -ltheoraenc -lva -lvorbis -lvorbisenc -lvpx -lx264 -lxcb -lxcb-render -lxcb-shape -lxcb-shm -lxcb-xfixes -lz -o build/lib.linux-x86_64-2.7/av/packet.so
/home/ksze/ffmpeg_build/lib/libavutil.a(frame.o): In function `av_frame_get_best_effort_timestamp':
/home/ksze/ffmpeg_sources/ffmpeg/libavutil/frame.c:30: multiple definition of `av_frame_get_best_effort_timestamp'
build/temp.linux-x86_64-2.7/src/av/packet.o:/home/ksze/PyAV/include/libavcodec/avcodec.pyav.h:6: first defined here
/home/ksze/ffmpeg_build/lib/libavutil.a(mem.o): In function `av_calloc':
/home/ksze/ffmpeg_sources/ffmpeg/libavutil/mem.c:253: multiple definition of `av_calloc'
build/temp.linux-x86_64-2.7/src/av/packet.o:/home/ksze/PyAV/include/libavutil/avutil.pyav.h:8: first defined here
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
make: *** [build] Error 1

It looks like there is a problem with relying on ctypes.util.find_library. Note that ctypes.util.find_library finds me libraries such as libavformat.so.53, which are the older, system-wide version of libav/ffmpeg, and hence don't contain the definition for av_frame_get_best_effort_timestamp.
My guess is that ctypes.util.find_library might not be using the same information as pkg-config to find the libraries.

From the presence of the newer issue, it seems that you got it to build. Can you tell us what you did?

I ended up installing system-wide ffmpeg for wheezy-backports from deb-multimedia.org for now, and PyAV builds fine against it.

Ouch! I'm sorry you had to do that.
The build system for PyAV is very sketchy. It would be TONS easier if we weren't trying to support both FFmpeg and LibAV...

Some packages allow you to set CFLAGS="-I/path/to/ffmpeg/lib python setup.py install to use libraries in another location. That is something that we can potentially do here as well (but it takes a bit more logic for that to work).
Does that seem reasonable, and/or do you have another suggestion (i.e. pkg-config)?

I should read everything in detail before getting ahead of myself... sigh

I think I agree with most of your diagnosis. We are using pkg-config to get the compiler flags, which picks up on whatever you have specified via PKG_CONFIG_PATH, but using ctypes.utils.find_library to find the specific library in order to check for the presence of functions.
In your specific case, it seems like PyAV has made some decisions about what functions exist based on the system-wide library, but then attempted to link against the local one.
I just pushed a "build" branch in which we try to manually search the paths indicated by pkg-config for the libraries. I just successfully linked against a non-systemwide install of ffmpeg (and it even passed all of the tests where my homebrew-ed ffmpeg does not).
This feels really iffy to me, but so does most of this build process already. *shrugs*

It looks like f0d1e82 does allow me to build PyAV against my local ffmpeg now.

Oops. It builds, but I end up unable to use it anyway:
In [1]: import av
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-55f15964059f> in <module>()
----> 1 import av

/home/ksze/PyAV2/av/__init__.py in <module>()
      2 # MUST import the core before anything else in order to initalize the underlying
      3 # library that is being wrapped.
----> 4 from ._core import time_base, pyav_version as __version__
      5
      6 # Capture logging (by importing it).

ImportError: libavcodec.so.56: cannot open shared object file: No such file or directory

Cool.
I'd like to leave this open until it feels less like a proof-of-concept and gets merged into master.


Deposit tickets

This update introduces support for Credit records (type 61) inside Bundles. These records are frequently used to represent deposit tickets.
closes #112 and #317

Tests are failing because the linter thinks there are real credentials in one of the file samples. I'll address that tomorrow.

Tests are failing because the linter thinks there are real credentials in one of the tests. I'll address that tomorrow.

You can ignore them pretty easily. https://github.com/moov-io/achgateway/blob/master/.gitleaksignore

Codecov Report

Merging #321 (5d5b852) into master (c0c5c78) will decrease coverage by 0.30%.
Report is 1 commits behind head on master.
The diff coverage is 69.11%.

:exclamation: Current head 5d5b852 differs from pull request most recent head 8d164d2. Consider uploading reports for the commit 8d164d2 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #321      +/-   ##
==========================================
- Coverage   87.86%   87.57%   -0.30%
==========================================
  Files          36       36
  Lines        5028     5039      +11
==========================================
- Hits         4418     4413       -5
- Misses        404      417      +13
- Partials      206      209       +3

@adamdecaf @atonks2 - Any update regarding R61? @jgulledge19 is reporting that R61 did not appear in the X9 file generated (as of Dec 20). We're interested in using the function and are determining whether we should customize the solution to include the feature or await the resolution of this issue.

@adamdecaf @atonks2 - Can you provide a status update?

@IdoMeros Sorry for the delay. Unfortunately I had to switch over to another project, but when I was working on this I believe I got stuck trying to figure out the best way to work with conflicting spec versions. I'll need to do some research to get the context back, but we may have to favor one spec over another which is something we've tried to avoid in the past.

@atonks2 No apology is necessary at all. Do you mean Record 61 in a Wells Fargo X9 vs a Record 61 in other versions? Which version did you code the R61 for?

Do you mean Record 61 in a Wells Fargo X9 vs a Record 61 in other versions? Which version did you code the R61 for?

I'm struggling to recall the specifics, but I think it came down to a common problem of how some institutions use 61 vs 62, and whether the item is inside a bundle, or on its own.

@atonks2 Interesting. I've never seen an R61 outside of the bundle. I'm not too familiar with an R62 record, so maybe it's more specific to it.
Attaching a screenshot showing the comparison between a R61 in a Wells Fargo X9 vs Non-Wells Fargo (practically every other bank which requires a R61) X9.


Adjust graph forces

I wish there was a way to adjust the forces in the graph. Here is my global graph in Zola vs Obsidian. I'm not sure if there is a fix for this that I am missing or if my way of linking isn't ideal for Zolas graph view.

Added in 79214eb99d3008be9389f5de2145e7bf8e1fa903


Near Network Integration

About
Integration of Near network in the UI. Mainnet Near network is considered an Exotic Network (non-EVM) in the Ark Network.
Required Changes
The function of linking an exotic address to your identity in the Ark Network Oracle v0.0.9 is different than the function for EVM addresses linkage (check it in the repo's code).
So for any user trying to link his Arweave address with a Near address, the SWC interaction should be as follow:

Ark Oracle v0.0.9: 5H5Hj81G5j5P2raDhe5VFU-zkf08KDc588GJ8dtlHTw

{
  "function": "linkExoticIdentity",
  "address": "abc.near",
  "verificationReq": "...",
  "network": "NEAR-MAINNET" // Near mainnet network identifier
}

notice that the only diff is the function's name linkEvmIdentity -> linkExoticIdentity

✅ Integrated a while ago


Highlights media is empty

When I fetch highlight highlight.item(0) return that they are 6 media but highlight.item(0).media is empty

@watergr I checked it and I am not having any problems right now. Can you share your code block?

    self.handler.stories.highlightsBy(user: .primaryKey(11830955)) { (result) in
                   switch result {
                   case .success(let medias):
                       print(medias.items[1])
                      (print:  "mediaCount": SwiftyInsta.DynamicResponse.number(30))

                       print(medias.items[1].media)
                       (print: [])

                       print(medias.items[1].media.first)
                       (print: nil)

                   case .failure(let err):
                       print(err)
                   }
        }

Ok, I understand the problem. MediaCount is returns from directly Instagram. Story based responses not always populated. This is how Instagram api works. Its not related SwiftyInsta.
You should call related methods.
In your case your code should be like this;
handler.stories.highlightsBy(user: .primaryKey(11830955)) { [weak self] (result) in
            switch result {
            case .success(let tray):
                let identifiers = tray.items.compactMap({ $0.identity.identifier })

                self?.handler.stories.reelsMedia(identifiers) { (result) in
                    switch result {
                    case .success(let dict):
                        print(dict)
                    case .failure(let error):
                        print(error.localizedDescription)
                    }
                }
            case .failure(let error):
                print(error)
            }
        }


A few improvements to the header files.

I noticed a few things that can be impoved upon on the C header files:

the STRINGIFY macro can be replaced with the Py_STRINGIFY macro which does the exact same thing. (Macro from Python.h)
I would like a special version of pyodbc.h header file which can be included with the package so that way people who want to make C extensions that needs to check pyodbc types can with simply including a C header file that defines the package's typeobjects for each python type it creates from the C code. This will help even my own project where I actually need to do such a thing in my C code to check if an argument is pyodbc.Row and error if not. Even ChatGPT if you ask it to help you generate your c code to check the type and see if it's pyodbc.Row will attempt to then #include <pyodbc.h> (does not exist when pip installing pyodbc), and then it will try to do something like PyOdbcRowObject for the type check (which will not work as well).

I was not aware of the need for the second bullet.  It sounds like we should split the headers into two - one with the very basics that can ship with the product and one with the rest.  I'll look into that.
Another option we are looking at is refactoring pydobc to have a private C core that is just functions and a public Python layer with all of the classes like Cursor and Row.  That would eliminate the need for the header.


[libtorch] build failure

Operating system
Ubuntu22.04 @ Windows 11 WSL2
Compiler
GCC-12
Steps to reproduce the behavior
./vcpkg install libtorch

Failure logs
Computing installation plan...
The following packages will be built and installed:
libtorch[core,xnnpack]:x64-linux -> 1.12.1#2
Detecting compiler hash for triplet x64-linux...
Restored 0 package(s) from /home/more/.cache/vcpkg/archives in 40.4 us. Use --debug to see more details.
Installing 1/1 libtorch:x64-linux...
Building libtorch[core,xnnpack]:x64-linux...
-- Note: libtorch only supports dynamic library linkage. Building dynamic library.
-- Using cached pytorch-pytorch-v1.12.1.tar.gz.
-- Cleaning sources at /home/more/vcpkg/buildtrees/libtorch/src/v1.12.1-d15308d103.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/more/vcpkg/downloads/pytorch-pytorch-v1.12.1.tar.gz
-- Applying patch pytorch-pr-85958.patch
-- Applying patch fix-cmake.patch
-- Applying patch fix-fbgemm-include.patch
-- Applying patch fix-c10-glog.patch
-- Applying patch use-flatbuffers2.patch
-- Applying patch fix-windows.patch
-- Using source at /home/more/vcpkg/buildtrees/libtorch/src/v1.12.1-d15308d103.clean
-- Using flatc: /home/more/vcpkg/installed/x64-linux/tools/flatbuffers/flatc
-- Using protoc: /home/more/vcpkg/installed/x64-linux/tools/protobuf/protoc
-- Setting up python virtual environmnent...
-- Installing python packages: typing-extensions;pyyaml;numpy
-- Setting up python virtual environmnent...finished.
-- Using Python3: /home/more/vcpkg/buildtrees/libtorch/x64-linux-venv/bin/python
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Building x64-linux-dbg
-- Building x64-linux-rel
-- Building x64-linux-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
Command failed: /home/more/vcpkg/downloads/tools/cmake-3.25.1-linux/cmake-3.25.1-linux-x86_64/bin/cmake --build . --config Debug --target torch_cpu -- -v -j25
Working Directory: /home/more/vcpkg/buildtrees/libtorch/x64-linux-dbg
See logs for more information:
/home/more/vcpkg/buildtrees/libtorch/build-torch_cpu-x64-linux-dbg-out.logbuild-torch_cpu-x64-linux-dbg-out.log
Call Stack (most recent call first):
installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
ports/libtorch/portfile.cmake:157 (vcpkg_cmake_build)
scripts/ports.cmake:147 (include)
error: building libtorch:x64-linux failed with: BUILD_FAILED
Please ensure you're using the latest port files with git pull and vcpkg update.
Then check for known issues at:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+libtorch
You can submit a new issue at:
https://github.com/microsoft/vcpkg/issues/new?title=[libtorch]+Build+error&body=Copy+issue+body+from+%2Fhome%2Fmore%2Fvcpkg%2Finstalled%2Fvcpkg%2Fissue_body.md
Additional context
No response

Looking at the error message in the log, it should be that we used the -Werror compilation option to convert the warning into an error, so a warning that did not return at the end of the function was converted into an error.


Provide way to get sheet gid

I'd like to be able to create links that will take the user to a specific sheet in a document. Links to specific sheets take the form:
https://docs.google.com/spreadsheets/d/<DOCID>/edit#gid=<GID>
I haven't been able to find any way for tabletop to give me the GID of a sheet - can you please provide that ability?

Happy to entertain a PR if someone comes up with one!


chore(examples) reorganize and add README

Matching deck.gl examples organization. Isolating website and kepler examples so that they can be built separately in the website.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 26.442%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
256

Relevant Lines:
843

💛  - Coveralls


Remove final instances of argparse.SUPPRESS

Closes #675.
Also removes the dead code for the old folded parameters that the Fat Client used to use.

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[N/A] The PR has modified HISTORY.rst with an appropriate description of the change (see Modifying change log).

Command Guidelines

[N/A] Each command and parameter has a meaningful description.
[N/A] Each new command has a test.

(see Authoring Command Modules)

Merge after CI passes

Codecov Report

Merging #3659 into master will increase coverage by 0.12%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3659      +/-   ##
==========================================
+ Coverage   72.24%   72.37%   +0.12%
==========================================
  Files         422      422
  Lines       26342    26291      -51
  Branches     3987     3976      -11
==========================================
- Hits        19031    19028       -3
+ Misses       6080     6035      -45
+ Partials     1231     1228       -3

Impacted Files
Coverage Δ

...ofile/azure/cli/command_modules/profile/_params.py
68.42% <100%> (ø)
:arrow_up:

...li-core/azure/cli/core/commands/template_create.py
59.49% <100%> (+21.5%)
:arrow_up:

...twork/azure/cli/command_modules/network/_params.py
92.97% <100%> (-0.02%)
:arrow_down:

src/azure-cli-core/azure/cli/core/util.py
72.1% <0%> (ø)
:arrow_up:

...nent/azure/cli/command_modules/component/custom.py
16.23% <0%> (ø)
:arrow_up:

...dback/azure/cli/command_modules/feedback/custom.py
31.25% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Update index.md to check anchor first delivery and completed

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


FireFly 2023 Q4 update

thanks @tkuhrt for catching the image link mismatch. Just merged your suggestion!


Python 3 - test_dump

[ ] Squash Commits etc.

Now that tnetstring deals with bytes a lot of changes need to be made that look like this

@mhils Now that tnetstring deals with bytes a lot of changes need to be made that look like this. Is there an alternative to doing this?

@dufferzafar: I think we have three ways to tackle this:

Add a new data type to our tnetstring implementation for utf8-encoded bytes.
Do the changes you sketched out. Hopefully it's not too bad.
convert dict keys by default and keep all values as bytes. Fixes most of the changes for the price of  inconsistency.

An implementation for 1 is at https://github.com/mitmproxy/mitmproxy/compare/master...mhils:tnetstring3-unicode-type?expand=1. For 2, we'd ideally make everything serializable subclass StateObject and handle the dict key conversion 3. 3 is relatively simple to implement, but that would force all dict keys to be str, which is a deviation from "normal" tnetstrings as well, so we can probably just go for 1 immediately.
@cortesi, thoughts?

After playing around with this for a bit longer, #1318 should be the way to go.

Only one test fails now (and that too seems easy to fix.)

\o/

Yeah!!!! 🎉🎉🎉 👍👍👍


Artifactory Generic Upload failing

Artifact Generic Upload task is failing due to the below errors:
[Error] [Thread 2] Artifactory response: 404 Not Found
{
"status": 404,
"message": "Checksum deploy failed. No existing file with SHA-1: "
}
]
}
[Error] Failed uploading 1 artifacts.
{
"status": "failure",
"totals": {
"success": 0,
"failure": 1
}
}
##[error]Error: Command failed: C:\hostedtoolcache\windows\jfrog\1.42.3\x64\jfrog.exe rt u --url="https://XXX/artifactory" --spec="D:\a\1\s\uploadSpec1614784091734.json" --user=*** --password=***
Expected behavior
Artifact should upload without any errors.
Versions

Artifactory Azure DevOps extension version: 1.11.2
Agent operating system: Windows
JFrog Artifactory version: SAAS
JFrog CLI version: 1.42.3

@vin4git,
Does this error repeat itself every time you try uploading the file or did this happen once?
Does this happen with a specific file only or with any file you try to upload?
To test and troubleshoot this, you can also run this upload command outside of Azure DevOps with jfrog-cli directly.

@eyalbe4 ,
It is happening every time the build is triggered and for any file trying to upload.

Thanks @vin4git.
In that case, my guess is that this is a permission issue for the user attempting to upload the file, although the error message received is not the best.
Here's what I suggest:
Try uploading a file using jfrog-cli with the same user from the terminal. I would expect you get the same result. Then see if this user has deploy permissions on Artifactory. If it doesn't, add the permission and try again.
Feel free to share your findings here.

@eyalbe4 ,
That's the "admin" user and have full privileges. :)

I see @vin4git. Will you be able to verify that you're uploading the file to a local repository?
If you are, then I suggest you open a ticket to JFrog Support, so that we can help you pinpoint and solve the problem.

@vin4git - were you able to get this issue resolved?


ARROW-17792: [C++] Use lambda capture move construction

Simplify some code using functors for the purpose of capturing a moved value.
 I missed this.
I have seen the error but it was disappeared without any changes... So I don't know why this is happened yet.


Cull unnecessary data on export data

If something doesn't have values, do not add it.

Evolutions and Evolution Conditions currently include too much data - including 0'd out fields, etc.
Find some way to cull these values.
Check output files to see if other data is subject to this as well.
Find a 'minimum' case that we can try to replicate - such as Venusaur's gmax form?

I believe this could do it. We could switch on, for example, evolution condition type and only serialize the respective data for that.

Currently, we have issue with Evolution Conditions - primarily the shiny condition.
It is also worth considering the following points:

An important point to note here is that any form that isn't default will inherit fields at the forms top level from the default if they aren't specified (i.e: You can inherit the entire moves object, but not just the levelUpMoves because that's a level nested inside moves). A good example of this in practice is battle bond greninja (note this is a seprate form to ash greninja which gets better stats etc) - which only changes abilities, egg groups and male percentage and inherits the rest from default greninja


AsyncStorage setItem issue

Error when trying to setItem for AsyncStorage:
"Entries must be arrays of the form [key: string, value: string]"
React Native version:
0.60.4
Steps To Reproduce

AsyncStorage.setItem('key', value);

The official AsyncStorage is now this one: https://github.com/react-native-community/async-storage


http2: Set SSN active on create_stream

Prior to the change, if a HTTP/2 stream is open on a session, but it doesn't make new transaction by some reason, the inactivity timeout of the connection never get fired.
Current ATS v10.0.x cancels inactivity timeout of proxy session in the Http2ConnectionState::create_stream (introduced by 7d5e673309b985d8e699328d58b55e2df89e861b). We need to get back the session inactivity timeout when all streams are gone, but there is a activity check of proxy session. To pass the check, we need to make the proxy session active.
https://github.com/apache/trafficserver/blob/66940f5768641b22dd36e7ae172fa72dcacdcb11/src/proxy/http2/Http2ConnectionState.cc#L1994-L1998

[approve ci autest]

Cherry-picked to v10.0.x


Installation Error in Version 0.0.4: Missing 'distutils ' and 'pkgutil' Issue

I am experiencing issues when attempting to install version 0.0.4 of the package. The installation process fails with two specific errors:

ModuleNotFoundError: No module named 'distutils'
AttributeError: module 'pkgutil' has no attribute 'ImpImporter'

This issue does not occur with version 0.0.3, which installs and functions correctly. The errors suggest there may be compatibility or dependency issues introduced in version 0.0.4.
Installing and upgrading 'pip', 'wheel', and 'setuptools' resolved the 'distutils' error. The upgrade and installation command is:
pip install --upgrade pip setuptools wheel
Environment

Python version: 3.12
Pip version: 24.2
Operating System: Windows

Thank you for looking into this issue. Please let me know if further information is required.

@mrbakhtyari Thank you for opening this issue. Could you check if you are still encountering the error with version 0.0.5 of repliclust?

Thank you for fixing the issue. The installation now works perfectly.


"Unload all" button (Prepare experiment, Sample change) is not working

When pressing "Unload all" button, table values "Cell", "Position" and sample changer image should become empty.

Done. The exception is that after pressing "Unload all" button user has to reload the page to see the result. New issue #15 is opened for that.


Type mismatch on http methods

The 2 code snippets provided below is the bug.
The get evaluates correctly, but the put gives a type mismatch, namely expected Session.Expression[String], actual Validation[String].
Using Gattling 2.2.2
only way to get it working is through a workaround which is the 3rd scenario
import io.gatling.core.Predef._
import io.gatling.http.Predef._

  val get = scenario("scenario")
    .exec(http("")
    .get("/some-url-path/" + userId))

  val putFail = scenario("scenario")
    .exec(http("")
    .put("/some-url-path/" + userId))

  val putFail2 = scenario("scenario")
    .exec(http("")
    .put(s"/some-url-path/$userId"))

  val putUrl = "/some-url-path/" + userId
  val putWorks = scenario("scenario")
    .exec(http("")
      .put(putUrl))

Pretty certain the error is on your side.
Could you please provide a full sample that's supposed to compile? Here, userId is undefined.

Tested with userId declared in scope as an Int or a String and compiles perfectly fine.
Closing for now.


Issue #02: Difference between MQTT protocols (mqtt, mqtts, ws, wss). Pros and cons.

mqtt, mqtts is TCP/IP connection with unsecure and SSL/TLS
ws, wws is usually used for web application
=>> in this context (device orientaion), we should use TCP/IP.

next question: how to get the .cert from emqx to set up mqtts connection? Have an evidence in https://github.com/emqx/MQTT-Client-Examples/blob/master/mqtt-client-Node.js/index.js#L33.
Should explore this to have the answer


fix(license): Updating license file

:tada: This PR is included in version 1.0.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


The problem when I run meshcnn classification

First, thank you for providing an open-source paper and code for processing 3D meshes, which has greatly benefited me. I'm new in meshCNN, when I set the norm parameter to 'none', I successfully ran the code, but the acc was only around 70%. When I used the default norm parameter 'batch', it would report the error 'normalization layer [BatchNorm2d] is not found', how to solve this problem? Do I need write BatchNorm2d in model?

Hi! Were you able to solve the issue?


Cannot use ionic command

When I type ionic into the command line, I get this error:
Caught exception:
 Error: Cannot find module 'extend'
    at Function.Module._resolveFilename (module.js:472:15)
    at Function.Module._load (module.js:420:25)
    at Module.require (module.js:500:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/ionic/node_modules/request/index.js:17:29)
    at Module._compile (module.js:573:32)
    at Object.Module._extensions..js (module.js:582:10)
    at Module.load (module.js:490:32)
    at tryModuleLoad (module.js:449:12)
    at Function.Module._load (module.js:441:3)

Mind letting us know? https://github.com/driftyco/ionic-cli/issues

How could I fix this? I'm using Mac 10.11.5 and I installed ionic using sudo npm install -g ionic

Solved this by installing extend using npm. My NODE_PATH was empty as well, not sure if that caused this to happen.


Classic Theme incorrectly overwrites og:image meta tag

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[ ] I have tried the npm run clear or yarn clear command.
[ ] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[ ] I have tried creating a repro with https://new.docusaurus.io.
[ ] I have read the console error message carefully (if applicable).

Description
When the image front matter is specified in a blog post or a docs article, and the themeConfig specifies the default metadata og:image, the theme incorrectly always overwrites the og:image meta tag in the built pages.
Reproducible demo
No response
Steps to reproduce
Repro of the configuration:
blogpost.md:
---
image: whatever.img
---

docusaurus.config.js:
/** @type {import('@docusaurus/types').Config} */
const config = {
  title: 'The place',
  tagline: 'The tagline',
  url: 'https://whereever.com/',
  baseUrl: '/',
  onBrokenLinks: 'throw',
  onBrokenMarkdownLinks: 'warn',
  favicon: 'img/favicon.ico',

  // Even if you don't use internalization, you can use this field to set useful
  // metadata like html lang. For example, if your site is Chinese, you may want
  // to replace "en" with "zh-Hans".
  i18n: {
    defaultLocale: 'en',
    locales: ['en']
  },

  presets: [
    [
      'classic',
      /** @type {import('@docusaurus/preset-classic').Options} */
      ({
        docs: {
          sidebarPath: require.resolve('./sidebars.js')
        },
        blog: {
        },
        theme: {
          customCss: require.resolve('./src/css/custom.css')
        }
      })
    ]
  ],

  // https://docusaurus.io/docs/api/themes/configuration
  themeConfig:
    /** @type {import('@docusaurus/preset-classic').ThemeConfig} */
    ({
      metadata: [
        { name: 'og:image', content: 'https://authress.io/knowledge-base/img/getting-started.jpg' },
      ]
  })
};
module.exports = config;

Expected behavior
image front matter to take precedence over global metadata default.
Actual behavior
The metadata og:image overwrites the locally defined image value.
Your environment
No response
Self-service

[x] I'd be willing to fix this bug myself. (But only if someone tells me where this code is, I have zero idea what I'm looking for)

Your repro screenshot doesn't match the issue ticket description. From yours it says image: 'img/docusaurus-social-card.jpg', but in mine I wrote specifically:
metadata: [
        { name: 'og:image', content: 'https://authress.io/knowledge-base/img/getting-started.jpg' },
      ]

I can easily switch to the image property to see if that fixes it, but as it is, it would be good if you could try to repro it with specifically the metadata specified.

Ok I understand.
Actually it's by design that this metadata field overrides any defaults that the theme set, and it is documented.

What's the use case for that? How does that make sense?
We want to set fallbacks for everything, how do we do that correctly?

As far as I remember, themeConfig.metadata was initially introduced as a way to override the default <meta name="twitter:card" content="summary_large_image" /> that the theme sets.
Remember theme metadata is not a site-wide metadata, and a Docusaurus site might use multiple themes with different configs and layouts.
Passing this theme metadata remains a default, and will always be overridden by document-specific metadata (including description). If you don't like that behavior you'll have to implement your "force metadata" behavior with swizzle, but IMHO it makes sense that if you set a description on each doc that description is used in priority over your generic theme metadata that will be only used as a global fallback when you forgot to set a page description.

If you want to set a global site metadata for a whole site, you'd rather use the headTags API.
I'm not 100% sure but as far as I remember metadata are applied/overriden in this order:

Core metadata hardcoded
Core headTags metadata
Theme metadata hardcoded (like the opinionated twitter:card display)
themeConfig.metadata (gives the ability to override twitter:card display)
blog/docs/page layout metadata (may be no metadata but can be added with swizzle
docs specific metadata

If all this doesn't make sense to you and you have a better proposal, please write down an exhaustive proposal on why a change is needed, and how it should be designed.
IMHO the current system is fine and works as intended, but I admit it can be a bit confusing.
Your image use-case has a better first-class API already.
Your description use-case looks quite artificial to me, and I see no reason for anyone to want that description overridden (ie all your pages have the exact same description). What is the goal here?

I think there are some actual things missing here:

having both image in the themeConfig and og:image in the metadata, creates two different og:image  tags, and same goes for any blog or dog with an image front matter attribute
Adding the head metadata https://docusaurus.io/docs/markdown-features/head-metadata AND the image front matter to a post also creates two og:image tags, without the Head metadata, two og:image tags are still created, with the second being the themeConfig metadata override.
layout specific metadata overwrites - It seems there is no way to do this except with the swizzle and it seems reasonable to me I want to do this. For instance I want the the theme override twitter:card to be summary but leave the summary_large_image for both the blog and the docs. I don't see a way of doing that without the swizzle

I think that means there are two "bugs":

the metadata property of the theme just doesn't really work, I can't find a use for it, unless, literally no other component creates the same meta tag, but since others are likely to do that, we'll end up with "two" of them in a lot of cases, unless it is overwritten in the exact same way. image is the biggest culprit because we allow it to populate the og:image, anything in the front matter that can populate head metadata, is going to suffer this problem.
There is no way to set the twitter:card type for a whole layout, blog, docs, etc... it can either be set at the theme OR at the individual post level. The problem here is that it can't actually be set at the theme level because it will overwrite everything.

Did I get that correct?

Please create repros for every case that you report, so that I can inspect those in practice.
Please avoid creating artificial use-cases. Don't use metadata image if there's themeConfig.image, or if you do, please justify your motivation do not use the API that is designed exactly for this use-case.
React-Helmet-Async is supposed to deduplicate metadata instead of inserting 2 tags, and in my experience it has worked well so far.
We do set 2 (eventually more in the future) metadata when you use the image API or frontMatter:
      {pageImage && <meta property="og:image" content={pageImage} />}
      {pageImage && <meta name="twitter:image" content={pageImage} />}

layout specific metadata overwrites - It seems there is no way to do this except with the swizzle and it seems reasonable to me I want to do this. For instance I want the the theme override twitter:card to be summary but leave the summary_large_image for both the blog and the docs. I don't see a way of doing that without the swizzle

There is no way to set the twitter:card type for a whole layout, blog, docs, etc... it can either be set at the theme OR at the individual post level. The problem here is that it can't actually be set at the theme level because it will overwrite everything.

Indeed, as explained you can only do this with swizzle atm. We don't have an API for that, and nobody ever requested that so far. If you want to contribute this feature, I'm open, but please share a concrete use-case for using it. We don't want to introduce APIs that nobody will use.
For me, this use-case is niche enough that swizzle is a good enough workaround. We can't have first-class APIS for every single little UI tweaks that users imagine, and swizzling remains a valid option.
If there's a good-enough workaround for implementing something, and nobody used it in production yet, then it's likely that there's not enough traction for this feature to be officially implemented.

the metadata property of the theme just doesn't really work

Yes it does, just copy-paste the docs example and see it in action. If the docs example doesn't work then it's a real bug, but please create a repro. It's hard to understand everything you claim with pure text. If I see the code, I can tell if it's the intended behavior or not, and explain why.


[DRAFT] Add scripts to create bodyfile for Docker containers

Depends on https://github.com/log2timeline/dfvfs/pull/659

@sydp what is the status of this PR?

This is dependent on https://github.com/log2timeline/dfvfs/pull/659.

@sydp what is the status of this PR?

@sydp be aware that the scripts have been moved due to using entry points https://github.com/log2timeline/dfimagetools/pull/96


[Fix] Split autoware_msgs

Internal Fix
All Autoware-dedicated messages belong to autoware_msgs. This issue splits autoware_msgs based on Design Rules to better understand the inter-package dependencies and how the ROS nodes talk to each other.

@esteve I've created the issue you mentioned at https://github.com/CPFL/Autoware/issues/1409#issuecomment-409625199. Is it OK to assign it to you?
https://github.com/esteve/Autoware/tree/fix/split_autoware_msgs

@kfunaoka yeah, it's ok, thanks!

We've been working on autoware_msgs refactoring. I'm almost done with new organization of namespaces and currently running tests (still some manual adjustments).
Here is the document describing the work so far (feature/autoware_msgs_refactoring branch):
https://github.com/CPFL/Autoware/blob/feature/autoware_msgs_refactoring/ros/concerning-autoware-msgs.md
Kindly check whether it satisfies what you expected.

Regarding autoware_msgs refactoring, I got some feedback. There are some minor changes as to the plan and message packages.
First, the changes:

Merge navigation and decision messages, and rename that as planning.
IndicatorCmd and LampCmd are exactly the same thing (contents), replace IndicatorCmd for LampCmd.
Move VehicleCmd into the new planning namespace (see 1)
Some objections regarding socket namespace (i.e., autoware_socket_msgs). It currently holds the RemoteCmd message advertised by "mqtt_receiver.cpp" (which lives in src/socket/packages/mqtt_socket). If there are no other objections I still will keep autoware_socket_msgs.

Second, the plan:
For each category C in [detection, localization, planning, sensing, sync, socket]:

Create the new message package autoware_C_msgs with its corresponding message files (move the message files out of autoware_msgs into autoware_C_msgs)
Keep the old autoware_msgs package (except those files that went to autoware_C_msgs)
Create a new branch based on develop called fix/refactoring_C_msgs
Apply the refactoring script to change autoware_msgs into autoware_C_msgs only to those files which are using messages in autoware_C_msgs
Build Autoware on branch fix/refactoring_C_msgs, then issue the PR for that branch
You would be able to merge and fully build each PR.

Some other concerns/comments:

Some messages are used without referring the autoware_msgs message type. Ex: in "twist_gate.cpp" -> state_cmd_pub_ = nh_.advertise<std_msgs::Int32>("/state_cmd", 1, true); BUT there is already autoware_msgs::StateCmd (which has header and a std_msgs::Int32). While the refactoring won't affect such cases, it's preferable to use the existing message (or delete the message type if nothing is using it)
My script searches for the publishers of each message type as a hint for message namespaces name and message type association. However, it wasn't designed to find type aliases, ex. in "twist_gate.cpp" -> using remote_msgs_t = autoware_msgs::RemoteCmd; and also in "twist_gate.cpp" -> using vehicle_cmd_msg_t = autoware_msgs::VehicleCmd;. VehicleCmd was associated to an incorrect namespace socket while it should have been planning. Fortunately this aliasing is limited to "twist_gate.cpp". I don't suggest to prohibit type aliases, but using directly the autoware message without the alias makes the code easier to read.

Here are my comments on the document prior to the most recent update, for completeness of this discussion.

If a message is completely unused, we should delete it now, not make a package for it. If we need it again in the future we can grab it from the repository history.
Please update your tables to match your new diagram.
Is IndicatorCmd a utility message, or should we have a package for car-status-related messages? We have VehicleStatus as well, which is proposed to be in localization_msgs.
Once the splitting up is done we need to consider renaming some of these messages to better match their purpose.
ExtractedPosition contains information about a single bulb in a traffic light. Why is it in navigation_msgs? (It should probably be renamed, too.)
What is LampCmd for and how is it different from IndicatorCmd?
I'm not fond of the name "socket_msgs". Why did you choose this?
The distribution of command-related messages between decision_msgs and navigation_msgs is not clear. Why are they done this way?
In general justification for the location of each message would be good; it would make a PR easier to review and facilitate discussion.

Here are some comments on the most recent edition.

Many of the messages need to be renamed, such as ExtractedPosition. We should do this in a separate PR after this one is done, but I just want everyone to be aware that renaming will happen.
Same goes for removing duplicate messages with different names, e.g. LampCmd and IndicatorCmd. We'll do these in a separate PR.
We'll also need to put comments in the message definitions as well because some of them just have data fields with no clear purpose for the message coming from the name.
Can and should we split messages related to data for planning, such as lanes and waypoints, from commands for controlling hardware?
I would prefer to choose and name message locations based on the purpose of the message, not who publishes it. Treat messages as data types, because that is what they are. So autoware_socket_msgs doesn't tell me the purpose of the messages contained within, whereas autoware_remote_control_msgs does. (I'm not saying that's the right name for that package; I cannot tell what that message is used for based on its content or name.)
The messages in sensing_msgs seem more about sensors than sensed data. Should the package be autoware_sensor_msgs?
VehicleStatus does not contain localisation information. It talks about the state of the vehicle. It would do well in a package with other hardware-related messages. Perhaps the hardware control command messages.

The plan sounds good to me. Make sure, if possible, that each PR can be merged independent of the others so we do not have to merge them in the correct order.

@gbiggs Thanks for the comments.

As for the autoware_sensing_msgs, @amc-nu also mentioned this. However I respectfully disagree. Different from ROS sensor_msgs which are actually messages exchanged by sensors, autoware_sensing_msgs are for sensing (sensor data processing) tasks. So far such messages are limited to CameraExtrinsic.msg, PointsImage.msg, ProjectionMatrix.msg purely sensor data post-processing. While in ROS sensor_msgs you find the joystick, laser, pointcloud2, temperature, battery, etc., purely sensor data. We don't need to imitate ROS naming convention. But that's my opinion.
As for your very last comment, I'm afraid we cannot do independent PRs in this case. There are several message inter-dependencies, each new branch will add new messages progressively replacing the old ones, and in the end we will remove old autoware_msgs. Cannot start testing with the PR which removes autoware_msgs.

As for the autoware_sensing_msgs, @amc-nu also mentioned this. However I respectfully disagree. Different from ROS sensor_msgs which are actually messages exchanged by sensors, autoware_sensing_msgs are for sensing (sensor data processing) tasks. So far such messages are limited to CameraExtrinsic.msg, PointsImage.msg, ProjectionMatrix.msg purely sensor data post-processing. While in ROS sensor_msgs you find the joystick, laser, pointcloud2, temperature, battery, etc., purely sensor data. We don't need to imitate ROS naming convention. But that's my opinion.

I wasn't mimicking the ROS core package name. I was thinking about the content of the messages in that package. If you want to avoid causing confusion with a major ROS package name, then I suggest autoware_sensor_info_msgs.

As for your very last comment, I'm afraid we cannot do independent PRs in this case. There are several message inter-dependencies, each new branch will add new messages progressively replacing the old ones, and in the end we will remove old autoware_msgs. Cannot start testing with the PR which removes autoware_msgs.

You can, but it involves touching the content of the files as well as moving them. If we had lots of tests so we could be sure each change wasn't breaking things, I'd insist you do it that way, but since we don't I'm not going to push such an unreasonable demand. I just want you to consider doing so if you find it possible for one of the PRs.


can't establish TLS with client <....>:TlsException("(-1,unexpected EOF)")

Problem Description
can't establish TLS with client <....>:TlsException("(-1,unexpected EOF)")
Steps to reproduce the behavior:

mitmproxy installed in win7
two cell phones connect with mitproxy ,
one is HuaWei   , another is XiaoMi ,    Huawei runs ok ,   XiaoMi show me error as above . i don't know why ?

System Information
Paste the output of "mitmproxy --version" here.
4.0.4

Thanks for getting in touch. We're generally happy to help out, but can I please ask you to use StackOverflow for all support and how-to questions? You can post the link to your question here so that people can follow up.
Thanks!

Can you provide more detail of your android system information of your both phone.
Because i m having same issue, like yours
https://stackoverflow.com/questions/59509156/cannot-establish-tls-with-client


Share a link for a first time user

What I'm trying to achieve
Try to share a link for a product
Steps to reproduce the problem

deploy to hosting (ex. firebase hosting)
share a link of a product ex. https://kashima-app.firebaseapp.com/product/kashima-pastillas-de-freno-delanteras-hyundai-accent-1400cc-2010/437/
open in a browser who never got the app before
Got a 404

What I expected to happen
Open the app with the product shared
Screenshots

System information
Operating system:
Browser:

Hello @ridiaz. It's a matter of configuring your hosting. You need to use Firebase's rewrites to support push-state URLs.