text:
Does/can beartype enforce static typing within the body of a function?

For example, do we ever intend it to detect the issue in either of these:
from beartype import beartype

@beartype
def fn(n: int) -> None:
    n = "waffle"

@beartype
def fn2() -> None:
    n = 5
    n = "waffle"

Or is that out of the scope of the project?
Basically, I would like to be able to completely ditch mypy in favor of this project, and this is what's holding me back.

This question can be succinctly rephrased as follows:

Would we like to destroy mypy and every other static type checker?

The answer to this and many other questions is:

...yes. Why, yes. We would like to do that thing.

We sympathesize with your urge to dump mypy into a ditch while wearing vinyl gloves which you then quietly incinerate. Dumping mypy into a ditch is entirely in-scope for beartype. That's why we're here, after all – to realize that utopian dream we all share.
Basically, we regard:

Static type-checking as the ignoble past we all put up with because we have to.
Runtime type-checking as the Halcyon Golden Age we are rocketing towards at risky speeds that may not be sustainable, safe, or a good idea. But it sure is fun.

So How We Do This, Bro?
We go full AST on this mutha. I even have internal #FIXME: comments hidden somewhere within the beartype codebase documenting a probable route to pragmatically achieving this.
Of course, ASTs are a fathomless black hole from which few return alive and even fewer return sane. This may not necessarily happen within the expected lifetime of my life is what I'm saying. A drip-feed of corporate and/or governmental sponsorship would probably get us there sooner than later. Until Money Shangri La materializes, however, this is lower on the priority list than you'd like. Ugh!
tl;dr
Money. That's what can make this happen. :money_mouth_face:

Disclaimer: I got a little lost on the verbosity, and will nonetheless comment here to avoid potentially opening a duplicate, as this came up a little close in a search of the issues.
From reading the code to an extent, I may come to understand that if __debug__ is turned off using python's python -O mode, then the runtime checking is simply turned off. At least that's how I implemented my own similarly purposed numpy oriented code that I have created instead of using a library:
from typing import Dict, Callable, NamedTuple, Tuple
import numpy as np
import functools
import pytest

""" this module defins a decorator for functions that return a numpy tensor, a decorater that asserts the type,
shape and arbitrary properties of a function's return value when the function is supposed to return a numpy tensor """

# (optional) dict of callables per tensor dimension, which may verify that dimension's length,
# which is a feature that for example allows to only verify some of the dimensions but not all.
ShapeSpec = Dict[int, Callable]

# verification specification type
class NPVerifySpec(NamedTuple):
    ndim: int = None               # number of dimensions
    dtype: np.dtype = None         # data type of the elements
    shape: Tuple[int, ...] = None  # length of each dimension
    shape_spec: ShapeSpec = None
    allow_none: bool = False

def np_verify_do(arr, spec: NPVerifySpec):

    """ a development time verification function, which can be applied via the decorator that follows it:
    meant for functions that return a numpy tensor, it verifies the numpy tensor properties (in a broader
    fashion rather than rely on leaky type hints from nptyping or beartype), and does nothing if we are
    running with debug set to False (e.g. via python -O, see python -h for details), so that when we are
    no longer running in development mode we skip the verification to avoid the overhead """

    # noinspection PyUnreachableCode
    if __debug__:

        print(spec)

        # allow a None return value
        if spec.allow_none and arr is None:
            return

        assert isinstance(arr, np.ndarray), f"{arr} is not a numpy array"

        if spec.ndim is not None:
            assert arr.ndim == spec.ndim, f'unexpected number of dimensions {arr.ndim}, expected {spec.ndim}'
        if spec.dtype is not None:
            assert arr.dtype == spec.dtype, f'unexpected dtype {arr.dtype}, expected {spec.dtype}'
        if spec.shape is not None:
            assert arr.shape == spec.shape, f'unexpected shape {arr.shape}, expected {spec.shape}'
        if spec.shape_spec is not None:
            for dim in spec.shape_spec:
                fn = spec.shape_spec[dim]
                assert fn(arr.shape[dim]) is True, f'dimension {dim} fails validation with validation function: {fn}'

def test_np_verify_do():
    arr = np.zeros((3, 4))
    # verify number of dimensions, data type, and length of each dimension
    np_verify_do(arr, NPVerifySpec(ndim = 2, dtype = np.float64, shape = (3, 4)))
    # verify that each dimension has length greater than 2
    np_verify_do(arr, NPVerifySpec(shape_spec = {0: lambda dim: dim > 2, 1: lambda dim: dim > 3}))

""" following is a decorator wrapper for the above np_verify function, and some tests demonstrating it
    (tecnique adopted from https://realpython.com/primer-on-python-decorators/#decorators-with-arguments) """

def np_verify(np_verify_spec: NPVerifySpec):
    def decorator(fn):
        @functools.wraps(fn)
        def with_output_verification(*args, **kwargs):
            result = fn(*args, **kwargs)
            np_verify_do(result, np_verify_spec)
            return result
        return with_output_verification
    return decorator

def test_np_verify_positive():
    """ verifies that verification via the decorator succeeds when it should """
    @np_verify(NPVerifySpec(ndim=2, dtype=np.float64, shape_spec={0: lambda dim: dim > 2, 1: lambda dim: dim > 3}))
    def foo():
        return np.zeros((3, 4))

    foo()

def test_np_verify_negative():
    """ verifies that verification via the decorator fails when it should """
    with pytest.raises(AssertionError):
        @np_verify(NPVerifySpec(ndim=10))
        def bar():
            return np.zeros((3, 4))

        bar()

Anyway, this code does nothing that beartype doesn't already allow with its Is thing.
So my question or feature request is twofold:

Will python's -O flag skip runtime checking and reduce its cost to an empty function call?
Is there any sense in adding a finer resolution way of turning off runtime checking, such as turning it off for some places/types/functions and not others? this would correspond to some scenarios mentioned in the docs/issues that speak to the need to sanitize runtime external input if you are an api project v.s. avoiding checking each and every other object in the api code. In short, there may seem to be some reasons for controlling very flexibly, the extent of checking, during a development and release process, in ways that do not require removing the annotations.

I'm not sure how much this relates to the idea of static typing which is mentioned in this discussion, as I didn't really get its example code (apologies). I thought that since beartype is PEP compliant and all then when used in an IDE that does static type checking it does result in static type checking.
Glad to learn.

If -O is set, @beartype will indeed do absolutely nothing at all. Stuff will still end up imported, and annotations get evaluated, but that shouldn't be too significant. Since it's just a decorator run at runtime, you have the full power of Python in regards to where you apply it. If you wanted to only sometimes apply it to your library, conditionally either import it or define a dummy in one of your modules.

What I mean by the annotations being evaluated is that as part of the function definition, the Union[str, dict[bool, float]] code would be run. That's not really something beartype can affect, it's all syntax. You can use from __future__ import annotations to make them strings again, but that might not work in all cases (since beartype has to call eval() and try to recreate the globals/locals environment). This is kinda an open problem, PEP 563 and PEP 649 are kinda competing.

Superb repeated saves by @TeamSpen210 – as expected of the greatest issue outfielder of all time.
So, we've dramatically leapt off of the original issue of static type checking and are now hip-deep in tangentially unrelated but nonetheless interesting waters: namely, "How do I curbstomp @beartype from doing what it wants to do?"
Let's see if we can't incrementally unpack this Gordion knot.

Will python's -O flag skip runtime checking and reduce its cost to an empty function call?

Yup. This is happening already.

Is there any sense in adding a finer resolution way of turning off runtime checking, such as turning it off for some places/types/functions and not others?

Yup. This is happening already. Specifically, our new configuration API released under beartype 0.10.0 and only documented here currently (just 'cause) provides a new O(0) no-time type-checking strategy that selectively disables specific @beartype decorations enabling that strategy.
Example or it didn't happen, so:
# Import the requisite machinery.
from beartype import (
    beartype,
    BeartypeConf,
    BeartypeStrategy,
)

# Global runtime type-checking strategy, where
# "I_AM_A_RELEASE_BUILD" is externally defined
# by your app stack to be True for release builds.
# Specifically:
# * If a release build, reduce @beartype to a noop
#   via the no-time type-checking strategy.
# * If a debug build, default @beartype to the usual
#   constant-time type-checking strategy.
_beartype_strategy = (
    BeartypeStrategy.O0
    if I_AM_A_RELEASE_BUILD else
    BeartypeStrategy.O1
)

# Beartype decorator configured with this strategy.
# Use this rather than the vanilla @beartype
# decorator everywhere throughout yoru app stack.
goodbeartype = beartype(
    conf=BeartypeConf(_beartype_strategy))

# Use @goodbeartype rather than @beartype everywhere.
@goodbeartype
def muh_performance_critical_func(big_list: list[int]) -> int:
    return len(big_list)

That's actually useful fodder for a new FAQ entry. :thinking:
Of course, it's probably pertinent to note here that @beartype is so fast and adds so little runtime overhead that it will never be a performance bottleneck – unless you're implementing a real-time digital signal processing operating system in pure-Python, in which case I concede the point.
Seriously. We're unbelievably fast. Profile us if you don't believe us – which you shouldn't, because your app stack depends on us telling the truth.

Actually if annotations get evaluated when __debug__ is False it is significant with large data.

Fascinating. Absolutely no snark here, because customer is king. You are customer, ergo king. Still... Have you actually profiled annotations as consuming non-trivial space for your use case or is this a bit of worst-case theory-crafting?
The reason I ask is that type hints originating from the standard typing module are self-memoizing and thus extremely space-efficient. For example, if you repeatedly annotate callables with the typing.List[str] type hint, only one instance of that hint is instantiated for the lifetime of the active Python process: e.g.,
>>> import typing
>>> typing.List[str] is typing.List[str]
True

Of course, PEP 585 deprecates typing.List by list. Is list[str] similarly self-caching? Nope. CPython devs completely dropped the ball here, because they're replacing something good (i.e., self-memoizing PEP 484 type hints) with something less good (i.e., non-self-memoizing PEP 585 type hints):
>>> list[str] is list[str]
False

You are now possibly cogitating: "Well, this is all a great ball of steaming matter of a nondescript nature." You're not wrong. Fortunately, @beartype solves that issue, too. Internally, @beartype caches all non-self-memoizing PEP 585 type hints. So, when you use @beartype, there's actually no space costs for either PEP 484 or 585 type hints.
Great, right? Almost. Remember that no-time type-checking strategy we enabled above? Okay. When we say "no-time," we mean literally that. @beartype immediately reduces to a noop when configured by that strategy. This means it does nothing, because doing something would violate the meaning of "no-time," right?
Unfortunately, doing something includes (wait for it) caching all non-self-memoizing PEP 585 type hints. That no longer happens, so PEP 585 type hints will suddenly begin consuming space when you disable @beartype.
Of course... that's why you shouldn't disable @beartype unless you're certain you need to. Again, please profile @beartype against your usual real-world use case. If we're surprisingly slow, we'll do our utmost to resolve that for you and the world.
Back to the question at hand. Let's suppose you actually have profiled:

@beartype and it's stupidly slow, so you need to disable it with the above no-time strategy in release builds.
Annotations and they're stupidly big, so you also need to disable them.

One or both of these are probably not going to be the case. But let's suppose they are. In other words, we are now on the worst historical timeline and the Four Arthritic Horsemen of the apocalypse are now rearing outside your bedroom window.
Can you do anything about that? You can – but you really don't want to. As @TeamSpen210 yet again correctly suggests, you can manually litter the top of every Python module across your entire app stack with a futures import enabling PEP 563:
from __future__ import annotations

Please don't do that. Although @beartype technically is the most PEP 563-compliant runtime type checker, enabling PEP 563 will:

(A) Break everything else that depends on annotations (e.g., pydantic).
(B) Introduce weird corner case subtleties that could conceivably break @beartype (when you do actually run it). Nested callables and closures are especially susceptible to breaking here.
(C) Dramatically slow down @beartype (when you do actually run it).

tl;dr
Please profile. We promise you'll be pleasantly surprised.

One thing I did notice while looking through the __debug__ handling is that since all of beartype is contained in submodules, you could move the __debug__ check into beartype.__init__, and then only import the actual core components if __debug__ is off. Then in "optimised" mode, most of beartype won't even need to be loaded, probably just the config if anything. It'd probably be negligible, but might as well.

That's... an unsurprisingly fantastic idea! But of course it is. It's Spen's. Type-checking QA :bear: approves.
I'll add an internal FIXME: comment to that effect straightaway.

Let's rename this issue to something I can actually accomplish within a single lifetime. :smiling_face_with_tear:

I think perhaps it would be good to have a feature request for this in full scope that lives somewhere, even if it's closed as "requires funding", just so that people are less likely to ask again for the same thing.
Does this make sense, or have I become confused?

From: Cecil Curry @.>
Sent: Wednesday, February 23, 2022 6:33:01 AM
To: beartype/beartype @.>
Cc: William Blake @.>; Author @.>
Subject: Re: [beartype/beartype] [Feature Request] Optionally enforce static typing (Issue #94)
Let's rename this issue to something I can actually accomplish within a single lifetime. 🥲
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/beartype/beartype/issues/94*issuecomment-1048484776__;Iw!!KGKeukY!gzY95Z6n87bJzAxNC_6mWtGMF3IwoIpL7NekrTf8VAG64HIHh13xWBhKhY9yAalla-y5$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AISQNI6CUDV2R6KQPSPXL43U4R5R3ANCNFSM5NEMXDOA__;!!KGKeukY!gzY95Z6n87bJzAxNC_6mWtGMF3IwoIpL7NekrTf8VAG64HIHh13xWBhKhY9yAWt4rg6w$.
Triage notifications on the go with GitHub Mobile for iOShttps://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!KGKeukY!gzY95Z6n87bJzAxNC_6mWtGMF3IwoIpL7NekrTf8VAG64HIHh13xWBhKhY9yAf3LBFM0$ or Androidhttps://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!KGKeukY!gzY95Z6n87bJzAxNC_6mWtGMF3IwoIpL7NekrTf8VAG64HIHh13xWBhKhY9yAVoBOMa3$.
You are receiving this because you authored the thread.Message ID: @.***>

It makes sense, because you always do. Let's copy-and-paste my initial response elsewhere to avoid violating DRY... yet again. Ain't nobody got the money to repeat a money-grubbing rant. Once is enough, GitHub!

Partially resolved by ccac042. By following the spun gold of @TeamSpen210's prior comment, we've mildly optimized the @beartype decorator under -O optimization by avoiding importing anything unnecessary (which is everything).
We still have yet to actually document any of this, however. Let's do that this year, shall we then? :sweat:

authors: TeamSpen210 langfield leycec matanster

repo: beartype/beartype


text:
Update Remote Playback API demo for compatibility with WebKit

This updates the Remote Playback API demo for compatibility with the currently shipped WebKit API:
https://developer.apple.com/documentation/webkitjs/adding_an_airplay_button_to_your_safari_media_controls
This is mostly to understand the current behavior of the API.  If you don't want to include WebKit support in this demo, I can put it in a separate file or keep it in my repo.
I also changed the video timestamp to start at the beginning since there are only about 20 seconds left otherwise.
CC @mounirlamouri

Is this on iOS without an AirPlay device?  Then that looks correct.

source: gharchive/pull-request

repo: beaufortfrancois/sandbox

license: MIT

license_type: permissive

license_source: github-api


text:
[HTML]: Add option to indent HTML tag text in a newline

Description
I've read the js-beautify-html options and issues with label language: html.
Input
With this new feature, when I give like this input:

Lorem ipsum.

Lorem ipsum.

Lorem ipsum.Lorem ipsum.Lorem ipsum.

Expected Output
I'd like to see this output:

    Lorem ipsum.

    Lorem ipsum.

    Lorem ipsum.

        Lorem ipsum.

    Lorem ipsum.

Environment
OS: MacOS High Sierra & Mojave

@ntnyq
Thanks for the report.
These two inputs produce different formatting due to span being an inline tag, so that will never be supported.
Lorem ipsum.

    Lorem ipsum.

However the other part is reasonable and is tracked by #980 (was missing the html label, added now).

source: gharchive/issue

authors: bitwiseman ntnyq

repo: beautify-web/js-beautify


text:
WIP: Multi role

Updates:

User roles have been divided into super user and practitioner.
Introduced the capability to share patient demographic and clinical data with practitioners using Consent resources.
Implemented the ability to create, read, and update HealthcareService resources.

[ ] Use default aidbox admin as super user, super user should not be linked with a practitioner.
[ ] Use FHIR format for resources/seeds/Mapping/edit-appointment-extract.yaml to rid of references conversion

                    - actor:
                        $if: $ selectedPatientReference
                        $then:
                          reference: selectedPatientReference
                        $else:
                          reference: $ 'Patient/' + patientId
                      status: accepted

[ ] Double-check changes in src/components/Select/Select.styles.ts
[ ] Double-check how multiple _has works. Are they query the same resource, what will happen if I create 4 Consents that match only by one criteria.
[ ] Consult with @maximpetov about better design for src/containers/SignIn/index.tsx

@ir4y Why would one use a super user without having a practitioner resource in the system?

repo: beda-software/fhir-emr


text:
To SpaceBrace or not to SpaceBrace

This is the SpaceBrace

It is not how c# has really been formatted.
It is how prettier formats js/ts.
It may have not been used before prettier.
Should CSharpier not use SpaceBrace?
See https://github.com/belav/csharpier/issues/34 for some discussion

After thing to consider. How will generic methods print? This is their current state, which will change.
        public static Doc Print<T>(
            SeparatedSyntaxList<T> list,
            Func<T, Doc> printFunc,
            Doc afterSeparator
        )
            where T : SyntaxNode {

I think it's worthwhile to stick with what the community is doing, especially in cases where the mandate is clear. And this is one of them.
For the generic method, I think we can put the constraint on the same line as the parameter end bracket.
public static Doc Print<T>(
    SeparatedSyntaxList<T> list,
    Func<T, Doc> printFunc,
    Doc afterSeparator
) where T : SyntaxNode
{
    var docs = new List<Doc>();
    return docs;
}

We've settled on SpaceBrace and have generic methods formatting well. I'm going to close this.

authors: belav respel

repo: belav/csharpier


text:
IndexError when running outputClean.py

I'm seeing an Index out of range issue when running cleanOutput.py. The fastq and input sam files were generated with blockParse and bowtie2 against bowtie2 generated GRCh38 index respectively.
(probeMining) root@83eb7974bb0f:/app/OligoMiner# python outputClean.py -u -f work/sam/sense_26_32_u.sam Traceback (most recent call last):   File "outputClean.py", line 486, in <module>     main()   File "outputClean.py", line 480, in main     reportVal, debugVal, metaVal, outNameVal, startTime)   File "outputClean.py", line 70, in cleanOutput     if x[0] is not '@' else ' ' for x in file_read] IndexError: list index out of range
Running OligoMiner in container built with environment.yml file provided in repo:
(probeMining) root@83eb7974bb0f:/app/OligoMiner# conda list
# packages in environment at /root/miniconda3/envs/probeMining:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                 conda_forge    conda-forge
_openmp_mutex             4.5                       2_gnu    conda-forge
biopython                 1.70                np112py27_1    bioconda
blas                      1.1                    openblas    conda-forge
bowtie2                   2.3.5.1          py27he513fc3_0    bioconda
ca-certificates           2024.8.30            hbcca054_0    conda-forge
certifi                   2019.11.28       py27h8c360ce_1    conda-forge
freetype                  2.12.1               h267a509_2    conda-forge
jellyfish                 2.2.10               h6bb024c_1    bioconda
jemalloc                  4.5.0                         0    bioconda
jpeg                      9e                   h0b41bf4_3    conda-forge
ld_impl_linux-64          2.43                 h712a8e2_1    conda-forge
lerc                      3.0                  h9c3ff4c_0    conda-forge
libblas                   3.9.0           16_linux64_openblas    conda-forge
libcblas                  3.9.0           16_linux64_openblas    conda-forge
libdeflate                1.10                 h7f98852_0    conda-forge
libffi                    3.2.1             he1b5a44_1007    conda-forge
libgcc                    14.1.0               h77fa898_1    conda-forge
libgcc-ng                 14.1.0               h69a702a_1    conda-forge
libgfortran-ng            7.5.0               h14aa051_20    conda-forge
libgfortran4              7.5.0               h14aa051_20    conda-forge
libgfortran5              14.1.0               hc5f4f2c_1    conda-forge
libgomp                   14.1.0               h77fa898_1    conda-forge
liblapack                 3.9.0           16_linux64_openblas    conda-forge
libopenblas               0.3.21               h043d6bf_0
libpng                    1.6.43               h2797004_0    conda-forge
libsqlite                 3.46.0               hde9e2c9_0    conda-forge
libstdcxx                 14.1.0               hc0a3c3a_1    conda-forge
libstdcxx-ng              14.1.0               h4852527_1    conda-forge
libtiff                   4.3.0                h0fcbabc_4    conda-forge
libwebp-base              1.4.0                hd590300_0    conda-forge
libxcrypt                 4.4.36               hd590300_1    conda-forge
libzlib                   1.2.13               h4ab18f5_6    conda-forge
mmtf-python               1.0.2                    py27_0    bioconda
msgpack-python            1.0.0            py27h9e3301b_1    conda-forge
ncurses                   6.5                  he02047a_1    conda-forge
numpy                     1.12.1          py27_blas_openblash1522bff_1001    conda-forge
olefile                   0.46               pyh9f0ad1d_1    conda-forge
openblas                  0.3.3             h9ac9557_1001    conda-forge
openssl                   1.1.1w               hd590300_0    conda-forge
perl                      5.32.1          7_hd590300_perl5    conda-forge
pillow                    6.2.1            py27hd70f55b_1    conda-forge
pip                       20.1.1             pyh9f0ad1d_0    conda-forge
python                    2.7.15          h5a48372_1011_cpython    conda-forge
python_abi                2.7                    1_cp27mu    conda-forge
readline                  8.2                  h8228510_1    conda-forge
reportlab                 3.5.42           py27heca39a3_0    conda-forge
scikit-learn              0.20.4          py27_blas_openblashebff5e3_0    conda-forge
scipy                     1.2.1            py27h09a28d5_1    conda-forge
setuptools                44.0.0                   py27_0    conda-forge
sqlite                    3.46.0               h6d4b2fc_0    conda-forge
tbb                       2020.2               h4bd325d_4    conda-forge
tk                        8.6.13          noxft_h4845f30_101    conda-forge
wheel                     0.37.1             pyhd8ed1ab_0    conda-forge
xz                        5.2.6                h166bdaf_0    conda-forge
zlib                      1.2.13               h4ab18f5_6    conda-forge
zstd                      1.5.6                ha6fb4c9_0    conda-forge

Hi,
Can you please paste a snippet of your .fastq file (first ~10 lines is fine) and verify you are getting alignments reported in your .sam file (ie, your reads are not failing to align to reference)

Hi Brian,
I think that might be the culprit! I have a significant number of reads not aligning, seems like I may have some things to work out upstream. Thank you for your quick response.

repo: beliveau-lab/OligoMiner


text:
update csso version

All tests are passed successfully. Test it on the real project — it works fine for me. There is no bugs.
Accept it please :)

@lancedikson Thank you!

authors: lancedikson tadatuta

repo: bem/borschik

license: mit

license_source: bigquery


text:
Plugin crash on startup (IntelliJ IDEA 2021.2.1)

Describe the bug
A clear and concise description of what the bug is.
Cannot create configurable

com.intellij.diagnostic.PluginException: Cannot create class uk.co.ben_gibson.git.link.UI.Settings.ConfigurableSettings (classloader=PluginClassLoader(plugin=PluginDescriptor(name=GitLink, id=uk.co.ben-gibson.remote.repository.mapper, descriptorPath=plugin.xml, path=~/.local/share/JetBrains/IntelliJIdea2021.2/GitLink, version=3.3.3, package=null), packagePrefix=null, instanceId=53, state=active))
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:870)
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:887)
	at com.intellij.openapi.options.ConfigurableEP$ClassProducer.createElement(ConfigurableEP.java:440)
	at com.intellij.openapi.options.ConfigurableEP.createConfigurable(ConfigurableEP.java:346)
	at com.intellij.openapi.options.ex.ConfigurableWrapper.createConfigurable(ConfigurableWrapper.java:42)
	at com.intellij.openapi.options.ex.ConfigurableWrapper.getConfigurable(ConfigurableWrapper.java:116)
	at com.intellij.openapi.options.ex.ConfigurableWrapper.cast(ConfigurableWrapper.java:91)
	at com.intellij.openapi.options.ex.ConfigurableWrapper.getId(ConfigurableWrapper.java:211)
	at com.intellij.openapi.options.ex.ConfigurableExtensionPointUtil.groupConfigurables(ConfigurableExtensionPointUtil.java:264)
	at com.intellij.openapi.options.ex.ConfigurableExtensionPointUtil.getConfigurableGroup(ConfigurableExtensionPointUtil.java:126)
	at com.intellij.openapi.options.ex.ConfigurableExtensionPointUtil.lambda$getConfigurableGroup$1(ConfigurableExtensionPointUtil.java:116)
	at com.intellij.openapi.util.ClearableLazyValue$2.compute(ClearableLazyValue.java:26)
	at com.intellij.openapi.util.ClearableLazyValue.getValue(ClearableLazyValue.java:39)
	at com.intellij.openapi.util.AtomicClearableLazyValue.getValue(AtomicClearableLazyValue.java:9)
	at com.intellij.openapi.options.ex.EpBasedConfigurableGroup.<init>(EpBasedConfigurableGroup.kt:111)
	at com.intellij.openapi.options.ex.ConfigurableExtensionPointUtil.getConfigurableGroup(ConfigurableExtensionPointUtil.java:114)
	at com.intellij.ide.actions.ShowSettingsUtilImpl.getConfigurableGroups(ShowSettingsUtilImpl.java:53)
	at com.intellij.ide.actions.ShowSettingsAction.perform(ShowSettingsAction.java:55)
	at com.intellij.ide.actions.ShowSettingsAction.actionPerformed(ShowSettingsAction.java:42)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.lambda$performActionDumbAwareWithCallbacks$4(ActionUtil.java:240)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.performDumbAwareWithCallbacks(ActionUtil.java:261)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.performActionDumbAwareWithCallbacks(ActionUtil.java:240)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem$ActionTransmitter.lambda$actionPerformed$0(ActionMenuItem.java:248)
	at com.intellij.openapi.wm.impl.FocusManagerImpl.runOnOwnContext(FocusManagerImpl.java:236)
	at com.intellij.openapi.wm.impl.IdeFocusManagerImpl.runOnOwnContext(IdeFocusManagerImpl.java:67)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem$ActionTransmitter.actionPerformed(ActionMenuItem.java:240)
	at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem.lambda$fireActionPerformed$0(ActionMenuItem.java:90)
	at com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:94)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem.fireActionPerformed(ActionMenuItem.java:90)
	at com.intellij.ui.plaf.beg.BegMenuItemUI.doClick(BegMenuItemUI.java:515)
	at com.intellij.ui.plaf.beg.BegMenuItemUI$MyMouseInputHandler.mouseReleased(BegMenuItemUI.java:545)
	at java.desktop/java.awt.Component.processMouseEvent(Component.java:6652)
	at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3345)
	at java.desktop/java.awt.Component.processEvent(Component.java:6417)
	at java.desktop/java.awt.Container.processEvent(Container.java:2263)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5027)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4859)
	at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
	at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
	at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2784)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4859)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:778)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:727)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:751)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:749)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:748)
	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:887)
	at com.intellij.ide.IdeEventQueue.dispatchMouseEvent(IdeEventQueue.java:816)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:753)
	at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$7(IdeEventQueue.java:443)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:825)
	at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$8(IdeEventQueue.java:442)
	at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:794)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:494)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.invoke.WrongMethodTypeException: cannot convert MethodHandle(Project,UrlModifierProvider)ConfigurableSettings to ()Object
	at java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:861)
	at java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:847)
	at java.base/java.lang.invoke.Invokers.checkGenericType(Invokers.java:495)
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:854)
	... 69 more

To Reproduce
Steps to reproduce the behavior:

Just start IDE.

Expected behavior
Plugin should not crash.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Kubuntu 21.04
IDE: IntelliJ IDEA 2021.2.1 Ultimate Edition

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

I'm getting the same exception in Rider 2021.2.1.

Commenting just to show that this is a real problem :)

Here's my stacktrace from:
IntelliJ IDEA 2021.2.1 (Ultimate Edition)
Build #IU-212.5080.55, built on August 23, 2021
Runtime version: 11.0.11+9-b1504.16 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 11.5.2

Cannot create configurable
com.intellij.diagnostic.PluginException: Cannot create class uk.co.ben_gibson.git.link.UI.Settings.ConfigurableSettings (classloader=PluginClassLoader(plugin=PluginDescriptor(name=GitLink, id=uk.co.ben-gibson.remote.repository.mapper, descriptorPath=plugin.xml, path=~/Library/Application Support/JetBrains/IntelliJIdea2021.2/plugins/GitLink, version=3.3.3, package=null), packagePrefix=null, instanceId=82, state=active))
at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:870)
at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:887)
at com.intellij.openapi.options.ConfigurableEP$ClassProducer.createElement(ConfigurableEP.java:440)
at com.intellij.openapi.options.ConfigurableEP.createConfigurable(ConfigurableEP.java:346)
at com.intellij.openapi.options.ex.ConfigurableWrapper.createConfigurable(ConfigurableWrapper.java:42)
at com.intellij.openapi.options.ex.ConfigurableWrapper.getConfigurable(ConfigurableWrapper.java:116)
at com.intellij.openapi.options.ex.ConfigurableWrapper.cast(ConfigurableWrapper.java:91)
at com.intellij.openapi.options.ex.ConfigurableWrapper.getId(ConfigurableWrapper.java:211)
at com.intellij.ide.util.gotoByName.GotoActionModel.lambda$new$0(GotoActionModel.java:83)
at com.intellij.openapi.util.NotNullLazyValue$3.compute(NotNullLazyValue.java:99)
at com.intellij.openapi.util.NotNullLazyValue$3.getValue(NotNullLazyValue.java:84)
at com.intellij.ide.util.gotoByName.GotoActionModel.getConfigurablesNames(GotoActionModel.java:368)
at com.intellij.ide.util.gotoByName.GotoActionItemProvider.processOptions(GotoActionItemProvider.java:151)
at com.intellij.ide.util.gotoByName.GotoActionItemProvider.filterElements(GotoActionItemProvider.java:97)
at com.intellij.ide.actions.searcheverywhere.ActionSearchEverywhereContributor.fetchWeightedElements(ActionSearchEverywhereContributor.java:99)
at com.intellij.ide.actions.searcheverywhere.MixedResultsSearcher$ContributorSearchTask.run(MixedResultsSearcher.java:177)
at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:213)
at com.intellij.util.ConcurrencyUtil.lambda$underThreadNameRunnable$3(ConcurrencyUtil.java:201)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:265)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.invoke.WrongMethodTypeException: cannot convert MethodHandle(Project,UrlModifierProvider)ConfigurableSettings to ()Object
at java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:861)
at java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:847)
at java.base/java.lang.invoke.Invokers.checkGenericType(Invokers.java:495)
at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:854)
... 27 more

It turns out there is a fix available in a PR https://github.com/ben-gibson/GitLink/pull/148

This should be fixed in 3.3.5

Thanks @ben-gibson .
Worked for me.
I also checked your commit for it, gradle upgrade.

authors: ben-gibson cade-rea jjanuszkiewicz mbaric ofry rkrv stevepiercy

repo: ben-gibson/GitLink


text:
Search: show no results message when there only 2 characters typed

Searchbar Message
Currently it takes at least more than 2 characters in the searchbar to trigger the actual search. If someone doesn't type more than 2 characters, they'l get an blank search result box. It would be nice to get a hint or the "no results" message :)

I think thats something with SQL, or maybe its just coded like that

authors: Ingokoepp XfaonXE

repo: benawad/dogehouse


text:
All pulled & saved tarballs are in Docker format

# first fix the examples etc, remove from [project]ignore, blah

$ buck2 build examples/rust:image --show-simple-output
buck-out/v2/gen/root/200212f73efcd57d/examples/rust/__image__/image.tar

$ mkdir dir
$ cd dir
$ tar -xf ../buck-out/v2/gen/root/200212f73efcd57d/examples/rust/__image__/image.tar
$ ls
6b0b1527d75b1e49c2cb08f4eb8616c64c9a20a8b9d8c1179146b2675586536b.tar.gz
8fa58e2afd032b7e4c012742a8b2de285f6c9acf565b2e22ab72369c2ead8272.tar.gz
26e3e4b0848c0e87391a7a844b11fcd2e6d223bd516be6ac8b17bac4e6808609.tar.gz
manifest.json
sha256:bca585cff135417e69bdf27793a0328c59f9c60ce232c59c19bf15c25009d6a3

There's no index.json, so it's not OCI. This is a Docker image.

pull.py is missing --format=oci in the call to crane pull. So the pulled images are Docker format, because the default is --format=tarball.
It appears crane mutate --output tarball.tar doesn't support writing to OCI-format tarballs?
I think you have to crane mutate without --output and then crane pull --format=oci from localhost.

I think the output of oci_image should probably just be an OCI-layout directory. I think that's what rules_oci's one does. Podman loads these just fine using podman load -i directory.

repo: benbrittain/oci-rules


text:
Feature: migration support (embark/disembark in shuttle terminology)

Feature request, support migration to/from Mastodon.
From what I've seen, migrating to Shuttlecraft just needs us to add knownAs to the account, then we will acquire new followers when Mastodon tells them to move.
To move from Shuttlecraft to Mastodon (once the user sets up knownAs on their target server), we just send all followers an ActivityPub Move message telling them where we've gone to.
https://github.com/mastodon/mastodon/pull/9629
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-move

Not sure if this will help, but I was just able to migrate my personal account from Hometown (a Mastodon fork) to Shuttlecraft with these steps:
In .data/account.json, add this object to the @context array:
{
  "alsoKnownAs": {
    "@id": "as:alsoKnownAs",
    "@type": "@id"
  }
}

Then add alsoKnownAs value to the actor object, with the value set to the ID of the old account. For example, here's what I added to move from my previous account:
  "alsoKnownAs": "https://goshdarn.fun/users/tyler",

Then, I was able to log into my Mastodon account and begin the move with these steps. That sends the Move request to my followers, and everyone automatically began following my new account.

Thanks for the update!

repo: benbrown/shuttlecraft


text:
[code][low prio] Rename Query.java

CreateQueries.java or similar would be better, as the file contains exactly these kinds of queries and other kinds are parts of other files.

@SeineEloquenz Can this be closed?

No as this has not yet been merged

authors: Jakob-Bach SeineEloquenz Weitspringer

repo: bendixsonnenberg/CS-Select


text:
🛑 mastodon is down

In e315dd4, mastodon (https://tilde.zone) was down:

HTTP code: 0
Response time: 0 ms

Resolved: mastodon is back up in 32cafe1 after 15 minutes.

repo: benharri/upptime


text:
Complete map of Europe

Would it be possible to connect all the data and make a map of how well the cities and countries perform relative to each other?
This could be a chart where each point gets a color from the weighted area that they can reach.
For example one place might have 100 sqkm within 1 hours, 50 sqkm within 1 and 2 hours and 50 sqkm within 2 and 3 hours and so on = 100x5+50x4+50x3+...
Another place might have perhaps half and thus be a different color. Then the collection of all places would make a very interesting chart that could show "hey look how bad/good you are compared to others" and if this could be compared to driving or flying this could also show how well the trains of Europe performs in general.

That's a good idea and I have started exploring in that direction, but
haven't been satisfied with the visual results yet.
I'll keep you posted.
On Tue, Nov 8, 2022, 7:20 AM jmagnes @.***> wrote:

Would it be possible to connect all the data and make a map of how well
the cities and countries perform relative to each other?
This could be a chart where each point gets a color from the weighted area
that they can reach.
For example one place might have 100 sqkm within 1 hours, 50 sqkm within 1
and 2 hours and 50 sqkm within 2 and 3 hours and so on = 1005+50
4+50*3+...
Another place might have perhaps half and thus be a different color. Then
the collection of all places would make a very interesting chart that could
show "hey look how bad/good you are compared to others" and if this could
be compared to driving or flying this could also show how well the trains
of Europe performs in general.
—
Reply to this email directly, view it on GitHub
https://github.com/benjamintd/chronotrains/issues/21, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACVPB42WWGBLTFFUNYQMTSTWHHWMDANCNFSM6AAAAAARZ6IXMI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Cool, if you show an alpha version I might give some feedback how to improve it 😊

authors: benjamintd jmagnes

repo: benjamintd/chronotrains


text:
[no-unused-modules] Dynamic import doesn't mark exports as used

Repro:
// foo.ts
export const foo = "foo"

// index.ts
async function test() {
  const { foo } = await import("./foo")
  const foo2 = await import("./foo").then(mod => mod.foo)
  const mod = await import("./foo") // should mark all non-type exports as used
}

My specific use case is:
import { lazy } from "react"
const Foo = lazy(() => import("./Foo"))

exported declaration 'foo' not used within other modules

Config:
{
  "extends": [
    "plugin:import/recommended",
    "plugin:import/typescript",
    // and more ...
  ],
  "rules": {
    "import/no-unused-modules": ["error", { "unusedExports": true }],
  },
}

Versions:
@typescript-eslint/parser: 4.8.0
eslint: 7.13.0
eslint-plugin-import: 2.22.1

This was intentional during the design of the rule (#1142, cc @rfermann).
When a dynamic import is done with a static, hardcoded path, it does seem possible for this plugin to detect it, but it would have to ignore any other forms of import(). A PR that detects these would be appreciated.

This was intentional during the design of the rule (#1142, cc @rfermann).
When a dynamic import is done with a static, hardcoded path, it does seem possible for this plugin to detect it, but it would have to ignore any other forms of import(). A PR that detects these would be appreciated.

me too.
components are lazy imported.

Related PR: https://github.com/benmosher/eslint-plugin-import/pull/1660

authors: ljharb phaux silverwind taoliujun

repo: benmosher/eslint-plugin-import


text:
How make stream with HLS URL?

I have a question. Can i make stream with HLS URL?

Depends on what you mean? Please clarify a little on what you're trying to do?
If you mean can the scripts output be served via HTTP(S) then all you need to do is have it write out into a directory that's served by a webserver (e.g. NGinx/Apache).

authors: Quiec bentasker

repo: bentasker/HLS-Stream-Creator


text:
Reconsider the interface of core

If you are writing something that uses the core of Kernel Tuner you have quite a few objects that need to juggle around in order call the functions in core. We should reconsider how core is organized. Also, the creation of an object that represents a compiled kernel instance might be useful for later facilitation tuned kernel integration into other applications.

I just wrote the code for kernelbuilder 3ed1a24 on top of core and it's not that bad actually.


text:
Data Makefile V1

For now, V1 procedure is: download data from openmri website, unzip, validate.
In the future, we might download data directly from the google drive link to make things easier.

From FB Chat:
Steve Yucheng Dong
11/2, 2:42pm
Steve Yucheng Dong
I have done the makefile part

Cindy Mo
11/2, 2:49pm
Cindy Mo
thanks steve!

Raj Agrawal
11/2, 3:35pm
Raj Agrawal
thanks!

authors: cxmo yuchengdong


text:
make failure subscriber use producer

The FailureSubscriber could do with using the producer.
The main thing this fixes is that the bernard.produce event will now be dispatched when failed messages are produced.

cool. thanks :)

authors: bendavies henrikbjorn

repo: bernardphp/bernard


text:
Update to 1.16.2

Update to 1.16.2

 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.

Looks good!

authors: CLAassistant Louwind bernie-g

repo: bernie-g/geckolib


text:
Null parameters handling

Currently, if a parameter is passed in the params_range dict, it is counted as one of the dimensions, even if it's not used (e.g. it's fixed to a value). Decide how to better handle this case.

This was fixed as per 9b29b8e52d3adf30a66f5bbe26800ec522a7ef78.
Now the parameters to be counted are regulated by the 'tides', 'spins' and 'eccentricity' flags, all other parameters are counted by default. To fix a value, the training range will simply by set to a narrow interval.

repo: bernuzzi/PyROQ


text:
Fix Output products issues [WIP]

OK, this is one of those pull requests.
I've addressed issues with the output products of cosimulation. There are three ways to run code: Without ANY output products (aside from print_stats), With waveforms, and with traces.
I'm still trying to get combinations to work (i.e. with traces AND waveforms) but I think this PR addresses the 95% case.
Here's the output of make help
      regression: Run all cosimulation regression tests for
             this subdirectory
      waveforms: Run all cosimulation regression tests for
             this subdirectory and generate waveforms
      traces: Run all cosimulation regression tests for
             this subdirectory and generate traces
      <test_name>: Build the cosimulation binary for a specific
             test
      <test_name.log>: Run a specific cosimulation test and
             generate the log file (will not generate traces)
      <test_name.vanilla.log>: Run a specific cosimulation test and
             generate the vanilla.log and vanilla_operation_trace.csv
             and vanilla_operation_trace.csv file
      <test_name.vanilla_operation_trace.csv>: Same as above

      clean: Remove all subdirectory-specific outputs

(Thanks to @dpetrisko for ideas)

Just curious... how did you get around this for no_debug_pp?
https://github.com/aws/aws-fpga/blob/1f67d8e375be81176a9f672544d870dfb24303e8/hdk/common/verif/tb/sv/tb.sv#L32-L33
That needs -debug_pp or equivalent, right?

I'm magical

(Just kidding. This is why I use -undef_vcs_macro)

No side affects with that?

Not that we've noticed. We've be running with -undef_vcs_macro for months now, you just didn't know it. It was part of EXTRA_TURBO

So a major question is: Should all waveforms produce traces?

I found traces helpful in getting a sense of direction in the sea of signals available in waveforms.

So a major question is: Should all waveforms produce traces?

I found traces helpful in getting a sense of direction in the sea of signals available in waveforms.

I think a tcl file with the list of important signals checked into the repo would do the job. Since traces make sim considerably slow, I agree that it's better to avoid them when possible.

name | regression | traces | waveforms | waveforms+traces
-- | -- | -- | -- | --
test_barrier | 55.5 | 38.92 | 84.29 | 103.67
test_binary_load_buffer | 35.47 | 42.37 | 76.56 | 102.94
test_conv1d | 40.81 | 61.62 | 92.87 | 262.44
test_conv2d | 49.28 | 48.65 | 95.49 | 117.46
test_device_memcpy | 38.1 | 39.65 | 102.51 | 90.7
test_device_memset | 38.63 | 46.76 | 84.34 | 111.65
test_dram_device_allocated | 56.34 | 62.87 | 103.32 | 131.28
test_dram_host_allocated | 39.73 | 41.26 | 82.93 | 104.11
test_dram_load_store | 58.24 | 72.59 | 125.18 | 155.4
test_empty | 34.5 | 38.48 | 77.39 | 99.13
test_empty_parallel | 39.03 | 40.55 | 85.7 | 98.11
test_float_all_ops | 112.51 | 177.64 | 229.08 | 314.14
test_float_matrix_mul | 82.66 | 117.53 | 160.51 | 215.01
test_float_matrix_mul_shared_mem | 134.18 | 262.86 | 320.22 | 498.71
test_float_vec_add | 50.23 | 59.41 | 116.63 | 125.41
test_float_vec_add_shared_mem | 57.19 | 81.81 | 121.28 | 163.15
test_float_vec_div | 65.16 | 110.22 | 140.8 | 215.44
test_float_vec_exp | 82.75 | 141.04 | 168.19 | 247.07
test_float_vec_log | 76.64 | 139.96 | 168.75 | 258.1
test_float_vec_mul | 52.84 | 70.71 | 109.13 | 141.72
test_float_vec_sqrt | 72.38 | 111.02 | 165.33 | 217.45
test_host_memset | 37.74 | 39.76 | 105.52 | 101.22
test_log_softmax | 128.45 | 274.16 | 246.45 | 448.4
test_matrix_mul | 91 | 137.5 | 161.72 | 252.49
test_matrix_mul_shared_mem | 133.6 | 288.69 | 317.35 | 513.32
test_max_pool2d | 46.78 | 44.43 | 110.73 | 127.09
test_multiple_binary_load | 67.67 | 70.52 | 146.73 | 169.9
test_scalar_print | 38.01 | 44.26 | 83.8 | 114.49
test_shared_mem_load_store | 87.1 | 98.8 | 153.54 | 215.91
test_shared_mem | 42.08 | 45.94 | 106.95 | 115.86
test_softmax | 82.95 | 163.34 | 188.47 | 282.14
test_stack_load | 40.79 | 40.48 | 87.64 | 110.47
test_tile_info | 41.3 | 62.59 | 92.12 | 121.96
test_vec_add | 62.04 | 59.54 | 102.73 | 128.3
test_vec_add_parallel | 59.99 | 64.77 | 116.58 | 144.83
test_vec_add_parallel_multi_grid | 54.78 | 76.27 | 121.31 | 174.65
test_vec_add_serial_multi_grid | 70.27 | 72.41 | 119.8 | 159.53
test_vec_add_shared_mem | 49.36 | 62.74 | 98.78 | 120.3
TOTAL | 2406.08 | 3452.12 | 5070.72 | 7073.95

maybe regress, regress-waves, regress-traces, regress-waves-traces, so that
it is clear they are all regressions?
On Tue, Feb 25, 2020 at 3:34 PM Dustin Richmond notifications@github.com
wrote:

OK, this is one of those pull requests.
I've addressed issues with the output products of cosimulation. There are
three ways to run code: Without ANY output products (aside from
print_stats), With waveforms, and with traces.
I'm still trying to get combinations to work (i.e. with traces AND
waveforms) but I think this PR addresses the 95% case.
Here's the output of make help
  regression: Run all cosimulation regression tests for
         this subdirectory
  waveforms: Run all cosimulation regression tests for
         this subdirectory and generate waveforms
  traces: Run all cosimulation regression tests for
         this subdirectory and generate traces
  <test_name>: Build the cosimulation binary for a specific
         test
  <test_name.log>: Run a specific cosimulation test and
         generate the log file (will not generate traces)
  <test_name.vanilla.log>: Run a specific cosimulation test and
         generate the vanilla.log and vanilla_operation_trace.csv
         and vanilla_operation_trace.csv file
  <test_name.vanilla_operation_trace.csv>: Same as above

  clean: Remove all subdirectory-specific outputs

(Thanks to @dpetrisko https://github.com/dpetrisko for ideas)
You can view, comment on, or merge this pull request online at:
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509
Commit Summary

First attempt at teasing apart VPD and trace generation
Added .PRECIOUS targets to hardware.mk
Added .PRECIOUS to compilation.mk
Improved simlibs.mk
Fixed missing -undef_vcs_macro vlogan flag
New rules work with SPMD
Propogating changes to all other test suites
Removed dve.mk

File Changes

M hardware/hardware.mk
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-0
(1)
M regression/compilation.mk
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-1
(1)
M testbenches/cosimulation.mk
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-2
(61)
M testbenches/cuda/Makefile
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-3
(23)
D testbenches/dve.mk
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-4
(76)
M testbenches/library/Makefile
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-5
(22)
M testbenches/link.mk
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-6
(45)
M testbenches/python/Makefile
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-7
(6)
M testbenches/pytorch/Makefile
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-8
(6)
M testbenches/simlibs.mk
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-9
(42)
M testbenches/specint/Makefile
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-10
(8)
M testbenches/spmd/Makefile
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509/files#diff-11
(27)

Patch Links:

https://github.com/bespoke-silicon-group/bsg_replicant/pull/509.patch
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bespoke-silicon-group/bsg_replicant/pull/509?email_source=notifications&email_token=AEFG5AAZNM6CCFZDMSOFIVTREWTJFA5CNFSM4K3WQ6I2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IQHSFEQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEFG5AH3TYIX5X2J7DIST3LREWTJFANCNFSM4K3WQ6IQ
.

Yeah, I can do something like that. At the very least I'll be sticking with regression because that's currently how you run regression and I don't want to change it.
regression+waves+traces might be tricky. I'll experiment again when I have more time. Going to try to get #503 reviewed and in.

OK, this is ready to roll.

make {target(s)}
      regression: Run all cosimulation regression tests for
             this subdirectory and print pass/fail results

      regression+traces: Run all cosimulation regression tests
             for this subdirectory and generate traces for each
             test. Does not print aggregate pass/fail results.

      regression+waveforms: Run all cosimulation regression
             tests for this subdirectory and generate waveforms
             for each test. Does not print aggregate pass/fail
             results.

      regression+traces+waveforms: Run all cosimulation
             regression tests for this subdirectory and generate
             traces and waveforms for each test. Does not print
             aggregate pass/fail results.

      <test_name>: Build the cosimulation binary for a specific
             test

      <test_name>.log: Run a specific cosimulation test and
             generate the log file (will not generate traces)

      <test_name>.vanilla.log: Run a specific cosimulation test
             and generate the vanilla.log file.

      <test_name>.vanilla_operation_trace.csv: Run a specific
             cosimulation test and generate the
             vanilla_operation_trace.csv file.

      clean: Remove all subdirectory-specific outputs

      help: Print this message (default)

Available <test_name> targets:
        test_scalar_print test_empty test_tile_info test_barrier test_striped
        test_binary_load_buffer test_empty_parallel test_multiple_binary_load
        test_host_memset test_stack_load test_dram_load_store
        test_dram_host_allocated test_dram_device_allocated
        test_device_memset test_device_memcpy test_vec_add
        test_vec_add_parallel test_vec_add_parallel_multi_grid
        test_vec_add_serial_multi_grid test_vec_add_shared_mem
        test_max_pool2d test_shared_mem test_shared_mem_load_store
        test_matrix_mul test_matrix_mul_shared_mem test_float_all_ops
        test_float_vec_add test_float_vec_add_shared_mem test_float_vec_mul
        test_float_vec_div test_float_vec_exp test_float_vec_sqrt
        test_float_vec_log test_float_matrix_mul
        test_float_matrix_mul_shared_mem test_softmax test_log_softmax
        test_conv1d test_conv2d

example make help

authors: drichmond taylor-bsg vb000


text:
ListGroupItem on:click not responding

on:click in ListGroupitem is not responding.
here is example in repl
https://svelte.dev/repl/b9dc70579b52428fb866ae77dc846f61?version=3
Am I using it right ?

Hi @ieow ,
Yes this looks like an oversight, we only pass on:click when tag="button", but you shouldn't have to do that.
I can look at fix but temp workaround is by adding <ListGroupItem tag="button" ...>:
https://svelte.dev/repl/bcc040a319bf44608172bcddc38b6f59?version=3.38.3

Hi @ieow , this should be fixed in sveltestrap@5.3.0 :
https://svelte.dev/repl/359466e990224b53afdf84ce013ebd29?version=3.38.3

That was fast.
Thanks for the quick fix !

authors: bestguy ieow

repo: bestguy/sveltestrap


text:
chore: update check to avoid open redirect to url //evil.com or /evi…

…l.com

sinon p-e un moyen plus simple serait de toujours préfixer par notre hostname

authors: LucasCharrier revolunet

repo: betagouv/espace-membre-next


text:
🛑 API Camino is down

In 8190b09, API Camino (https://api.camino.beta.gouv.fr/titres) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API Camino is back up in a8f703f.


text:
🛑 API Camino is down

In 265ed9b, API Camino (https://api.camino.beta.gouv.fr/titres) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API Camino is back up in eef7a25.


text:
Discussion - Optional fields in pact

Hi Beth,
I had so many discussions in my company about the same problem, that I'd like to expose it.
Just so we can talk about it, as I feel I'm missing some kind of capability.
We are "pact verifying" a lot of end points and there are always some properties on a JSON output that are not always there. Properties or even whole objects.
We kind of come to conclusion where we should either:

hard-code end point output in the interaction, use provide states, and not use matchers
remove optional fields from interaction

Here is a simple example of a list of categories for books:
{
	"_embedded": {
		"categories": [
			{
				"name": "Children",
				"_links": {
					"doc:books": {
						"href": "http://example.com/list-of-books?category=children"
					}
				}
			},
			{
				"name": "Factual",
				"_links": {}
			}
		]
        }
}

In this list of categories, the _links object may or may not contain a url that point to a list of books.
This is how my response interaction looks like:
{
    "_embedded": {
        "categories": Pact.Matchers.eachLike({
            "name": Pact.Matchers.somethingLike("Children"),
            "_links": {
                "doc:books": {
                    "href": Pact.Matchers.term({
                        matcher: "^(?=.*list-of-books)(?=.*category=)",
                        generate: "http://example.com/list-of-books?category=children"
                    })
                }
            }
        })
    }
}

When I come to verifying mocks, which may or may not have the links in each categories, the verification would fail as the pact interaction is expecting to always have a doc:books links.
What are my solutions?

remove the optional part:

{
    "_embedded": {
        "categories": Pact.Matchers.eachLike({
            "name": Pact.Matchers.somethingLike("Children")
        })
    }
}

Problem: it doesn't represent the reality, url are not tested
Benefit: can verify any mock files

use provider state, remove eachLike matcher, basically hard-code response

{
    "_embedded": {
        "categories": [
            {
                "name": "Children",
                "_links": {
                    "doc:books": {
                        "href": Pact.Matchers.term({
                            matcher: "^(?=.*list-of-books)(?=.*category=)",
                            generate: "http://example.com/list-of-books?category=children"
                        })
                    }
                }
            },
            {
                "name": "Factual",
                "_links": {}
            }
        ]
    }
}

Problem: it still doesn't represent the reality, can't verify mock files that are different from this response
Benefit: can test both case of having and not having the links
How I would like to write the interaction
I don't know if that's feasible, but if I had some kind of an "optional matcher", that would be applied or not applied depending of the existence of a node, it would help me write the interaction. I would also be able to verify any mock files and it would also represent the reality.
Something like (see the <Pact.Matchers.optional> in the node property):
{
    "_embedded": {
        "categories": Pact.Matchers.eachLike({
            "name": Pact.Matchers.somethingLike("Children"),
            "_links": {
                "<Pact.Matchers.optional>doc:books": {
                    "href": Pact.Matchers.term({
                        matcher: "^(?=.*list-of-books)(?=.*category=)",
                        generate: "http://example.com/list-of-books?category=children"
                    })
                }
            }
        })
    }
}

Any thought of how to approach this problem?

Hi Romuald,
This is a frequently asked question. See if this answers your query. If not, lets talk about it so I can add further clarifications. https://github.com/realestate-com-au/pact/wiki/FAQ#why-is-there-no-support-for-specifying-optional-attributes

Hi Beth,
Thanks for the references, very much appreciated!
The solution 2 works in the case of contracting the consumer with the provider, which is the goal of pact. But when it comes down to verifying mocks, any alterations from the responses hard-coded in the original pact file would fail the verification. This is somehow crippling, and I feel less of a point in using pact if I can't verify mocks.
Let's imagine I need 100 fixtures json files to test special cases in an acceptance tests step, each fixtures files would have small alterations with optional fields and objects. If I want these fixtures files to be pact verified I would need to create provider states and a 100 alterations for the same request.
That still sounds a bit weird.
Also, how would I differentiate these 100 interactions from one another as they are the same request? With a dummy parameter? Pact-mock-service doesn't allow me to add the same request multiple, which makes complete sense.
/platform/books?testCase=1
/platform/books?testCase=2
...

Is verifying mocks the actual downside of pact because it hasn't been made for that in the first place?
Any further thought appreciated if you have any!
Cheers.
Romu

A small addition in case it helps other people.
We are going to a solution 3.
We won't hard-code responses, we will still use eachLike matchers.
We will include every single optional (but used) fields so they are tested.
On the micro-service/API side, provider states will be used to generate the proper data with optional fields always present, no problem there.
On the mock verification side, and this is the key of the solution, we will only verify "standard" mocks (mocks with all optional fields present), and not verify other altered mocks (missing optional fields).
So this is still not perfect, because not all mocks are verified. But we are "less unhappy" and should be able to effectively catch broken contracts. Compared to the other 2 first solutions, the pact file sanity and tests made on back-end side is stronger.
Hope that make sense, and thanks again for your time @bethesque
Romu

Ah, I see your problem more clearly now.

Let's imagine I need 100 fixtures json files to test special cases in an acceptance tests step

Personally, I don't use pact for acceptance tests, as I find they generate a million different interactions which are a pain to maintain, as you have found. The way I use pact is to test just the API client thoroughly (the one class through which all HTTP requests to your API go). Then I use a different mocking solution for the higher level tests. I would either mock at the HTTP level, and reuse the same fixtures that I used in the pact tests, or I would mock the API client class, and reuse some object that I shared between the pact tests and the acceptance tests to ensure they stayed in sync.

We won't hard-code responses, we will still use eachLike matchers.
Yes, I would always use "like" by default for just about everything.

Also, how would I differentiate these 100 interactions from one another as they are the same request?

The mock service is only designed to have a few interactions loaded into it at a time, and to have a separate test for each one or two requests (ie. sometimes a client will hide the fact that it is making multiple requests to service one method call, for example, following HAL links). You'd need to put each of the hundred interactions into separate test cases I'm afraid.

On the mock verification side, and this is the key of the solution, we will only verify "standard" mocks (mocks with all optional fields present), and not verify other altered mocks (missing optional fields).

There used to be an option to do a more lax verification, but I can't remember the details. I've been trying to find it in the code.
Your solution sounds like it is giving you sufficient certainty without creating a million use cases, so it sounds reasonable to me.

authors: bethesque soundstep


text:
fix invalid includes, could be 5.4 specific bug

This wouldn't build until I added the directory structure to these includes. I am using 5.4.

Thank you!

repo: betidestudio/SteamIntegrationKit


text:
Reflection allows users to clone arbitrary reflected components, but Reflect does not have a Clone bound

Problem

ReflectComponent::copy_component allows users to copy any arbitrary component data to different entities, and across worlds, as long as it is reflect-able.
Neither Reflect nor Component has a Clone bound, and so we can sneakily clone components that are not expecting to be cloned. I'm pretty sure this is ultimately done by just copying their raw memory.
Components are effectively cloned in a way that bypasses the Clone method, which can cause issues with things like ref-counting (used for Handle).

Possible Solutions

Give Reflect and/or Component a Clone bound. This fixes problem 2, but not problem 3, and may be painful in niche use cases (although I have not seen any concrete use cases for components that cannot be cloned raised, see #1515).

Furthermore, not all fields of a component should be reflected. Cloning components with some cloneable field and defaulting the others is a reasonable strategy here, but does not permit a Clone bound.

Use the appropriate Clone methods when they exist.

Leave the existing behavior in place, and very clearly document what's going on and how to use it safely.

I believe this copy would happen based on creating a new default, then reflecting the old onto the new

@mockersf points out that this Clone-bypassing behavior is not uniquely isolated to this reflection method.
If we implement both Serialize and Deserialize for a type (which we need to, for reflection to be useful to store scenes), we can (tediously) clone arbitrary structs, bypassing any limitations. I've documented this behavior in #3366 at least, and I suspect that's probably the best we can do.
This does however make me increasingly convinced that we should have either Reflect: Clone or Component: Clone, as uncloneable structs cannot be reasonably reflected, and almost all components should be both reflected and cloneable.

This does however make me increasingly convinced that we should have either Reflect: Clone or Component: Clone, as uncloneable structs cannot be reasonably reflected, and almost all components should be both reflected and cloneable.

FromWorld, which is a superset of Default, is required to use ReflectComponent:
https://github.com/bevyengine/bevy/blob/ed9d45fae57e8f01d13ca3a6c12a5f3005b6c610/crates/bevy_ecs/src/reflect.rs#L81
https://github.com/bevyengine/bevy/blob/ed9d45fae57e8f01d13ca3a6c12a5f3005b6c610/crates/bevy_ecs/src/world/mod.rs#L1171-L1175

FromWorld, which is a superset of Default, is required to use ReflectComponent:

Yes, which is a nice feature (although I still like FromReflect from #1395). This should avoid unsoundness, but won't save us from logic errors around things like ref-counting. Handle for example could easily implement Default, but handles cloned in this fashion wouldn't keep assets alive in the proper feature.

Yeah, this is just an ecosystem-wide "problem". Closing.

authors: DJMcNab Davier alice-i-cecile

repo: bevyengine/bevy


text:
Assets not loading for compiled binaries

Platform:
macOS 10.15.4 and iOS 13.6 (as part of #87)
Description:
While testing sprite sample I've encountered an issue running a compiled (not cargo run) binary.
Both macOS and iOS didn't show sprite if binary was run directly even if asset folder was next to binary.
Changing relative (?) path to full path using std::env::current_exe() fixed the issue for macOS, but didn't work for iOS.
Edit:
Running binary on macOS from console fixes the issue.
Running binary by double clicking on it does not. Placing assets at ~ directory fixes the issue.
Making an .app package and running it also results in empty scene.
Console output for std::env::current_dir() and std::env::current_exe():
Running in console (works out of the box):
cargo run
dir: /Users/naithar/Projects/my_bevy_game, exe: /Users/naithar/Projects/my_bevy_game/target/debug/my_bevy_game
loading untyped at assets/branding/icon.png
loading: Handle<Texture>(d5e86b7d-a8d4-4cf4-bbca-9ed16033dc08)
...
./my_bevy_game
dir: /Users/naithar/Projects/my_bevy_game/target/debug, exe: /Users/naithar/Projects/my_bevy_game/target/debug/./my_bevy_game
loading untyped at assets/branding/icon.png
loading: Handle<Texture>(a7fbd902-d958-4c6a-8919-5c69fb27e992)

Running by double clicking (requires moving assets to HOME folder):
dir: /Users/naithar, exe: /Users/naithar/Projects/my_bevy_game/target/debug/my_bevy_game
loading untyped at assets/branding/icon.png
loading: Handle<Texture>(95a6da42-d8a9-404c-8ac5-734ffdd88e02)

.app package (specifying full path worked):
dir: /, exe: /Users/naithar/Projects/my_bevy_game/target/debug/Godot.app/Contents/MacOS/Godot

iOS application (specifying full path didn't work loading by full path seems to be working, but it's not displayed due to some other problem):
dir: /, exe: /private/var/containers/Bundle/Application/02EF133B-F04C-47FE-A936-770F5757D494/BevyTest.app/BevyTest
loading untyped at /private/var/containers/Bundle/Application/02EF133B-F04C-47FE-A936-770F5757D494/BevyTest.app/assets/branding/icon.png
loading: Handle<Texture>(9d955d34-51cd-4b36-996d-bf866fd048ac)

load returns correct texture handle all the time, even if there is nothing to load.

I am unable to reproduce this issue (running macOS 10.14.2). I did cargo run and it worked. Then, I copied the compiled binary into the project directory and it still worked. Finally, I tried just copying the binary and the assets folder into a separate directory and ran it. It did not work when I ran it from outside that directory, but it did work when I ran it from within that directory.
What is happening in my case is that the binary attempts to access the relative path from the working directory that  the binary was called from, not necessarily where the binary is located. That would explain why std::env::current_exe() worked for you.
Could this be what is going on?

@Xavientois thanks :) Which OS did you test on?

Updated description with more info and logs.

Adding std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); at the start of the app works as workaround for compiled binaries for both macOS and iOS.

Running from console works as expected, in that assets are relative to the current working directory. It might be nice to be able to provide a base dir for the asset loader (haven't checked if this is already supported). Especially for iOS, although I'm sure we can figure out the right way to drop in asset directories to xcode so that it works with the default path.
Packaged games is a different matter... on windows with your installer you could just setup the shortcut with the correct working directory. I don't know how to make a mac .app bundle. I haven't used linux desktop in a long time to know what the current state is there.
I suppose that iOS is special here in that the development build setup is already the packaged build.

Stumbled across this https://agmprojects.com/blog/packaging-a-game-for-windows-mac-and-linux-with-rust
Sounds like you are on to something with the current_exe() suggestion, though not ideal for dev builds with cargo run.
Perhaps the answer is per-OS config switch or different config when bundling to set the asset base path?

I am also having this issue but on windows 10. Cargo run works perfectly in all the examples however I am having issues with cargo build (and cargo build --release). Some of the compiled binaries such as 3d_scene and spawner do load assets correctly but the 2d ones like sprite do not.

3d_scene and spawner doesn't load anything with asset_server.load, so it's not a surprise.
Does adding std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); at the start of main help you?

3d_scene and spawner doesn't load anything with asset_server.load, so it's not a surprise.

Ah okay! haha, should have realized that tbh! Cheers!

Does adding std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); at the start of main help you?

No unfortunately not. Using std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); for me causes assets not to load with cargo run and not to load with the cargo build binary either. Using std::env::current_exe().expect(""); results in the same behavior as before where the assets load with cargo run but do not load in the binary.

If you use std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap());  you should place assets at the same folder as executable - somewhere like target/debug

Thank you @naithar that worked.

Fixed by https://github.com/bevyengine/bevy/pull/693
assets folder should be placed next to the compiled binary. For iOS assets folder should be lited in Copy bundle resources phase.

Stumbled across this https://agmprojects.com/blog/packaging-a-game-for-windows-mac-and-linux-with-rust
Sounds like you are on to something with the current_exe() suggestion, though not ideal for dev builds with cargo run.
Perhaps the answer is per-OS config switch or different config when bundling to set the asset base path?

For anyone else that stumbles upon this in future and is interested in the link (even if it's not needed for Bevy anymore), then this is a fixed link (as at today, at least; the original is missing .html on the end): https://agmprojects.com/blog/packaging-a-game-for-windows-mac-and-linux-with-rust.html

authors: J1M-RYAN Kage-Yami MichaelHills Xavientois naithar


text:
Dynamic vertex attribute shader definition

Bevy's shader Vertex struct — the input type for vertex shaders — is messy, extending the mesh pipeline with new attributes is error prone. You have to keep track of the @location(x) attribute_name: attribute_type of each of bevy's attributes and your own custom attributes.
What solution would you like?
Bevy currently defines its Vertex through a series of #ifdef, neither ideal or the most readable.
What about dynamically defining this struct based on the attributes existing in the Mesh struct?
MeshVertexAttribute already contains everything we need to know about an attribute: its name and its type. We should be able to generate the Vertex struct based on them.
Advantages are:

No need to keep track of location(x), fully handled by bevy
Avoid noisy definitions like the current #ifdef bag we use
Avoid duplication, no need to specify Vertex means no need to duplicate the specification of Vertex.

Additional context
This idea came as I was thinking about how it could be possible to extend the morph targets feature to support arbitrary vertex attributes, including user-supplied ones.

related:

#5370
#5703

Biggest disadvantage I'm seeing is an inability (or at least an additional challenge) when it comes to pre-compiling shaders, as the attributes on Mesh are runtime state.

However we already have things like "shader defs", which are a similar class of thing. Pre-compiling would probably involve specifying permutations of shader defs and vertex attributes.

If both the mesh & shaders are pre-processed, I can see how list(mesh)<->list(shader) could work. As you said, both shaders defs and mesh attributes are runtime-dependent.
A way to look at asset pre-processing is: formalize and define assumptions about files, so that runtime checks and conversions (N runtime cost) are replaced by assumptions (0 runtime cost).

authors: cart nicopap


text:
Add Meshable trait and implement meshing for 2D primitives

Objective
The first part of #10569, split up from #11007.
The goal is to implement meshing support for Bevy's new geometric primitives, starting with 2D primitives. 3D meshing will be added in a follow-up, and we can consider removing the old mesh shapes completely.
Solution
Add a Meshable trait that primitives need to implement to support meshing, as suggested by the RFC.
/// A trait for shapes that can be turned into a [`Mesh`].
pub trait Meshable {
    /// The output of [`Self::mesh`]. This can either be a [`Mesh`]
    /// or a builder used for creating a [`Mesh`].
    type Output;

    /// Creates a [`Mesh`] for a shape.
    fn mesh(&self) -> Self::Output;
}

This PR implements it for the following primitives:

Circle
Ellipse
Rectangle
RegularPolygon
Triangle2d

The mesh method typically returns a builder-like struct such as CircleMeshBuilder. This is needed to support shape-specific configuration for things like mesh resolution or UV configuration:
meshes.add(Circle { radius: 0.5 }.mesh().resolution(64));

Note that if no configuration is needed, you can even skip calling mesh because From<MyPrimitive> is implemented for Mesh:
meshes.add(Circle { radius: 0.5 });

There is also a new Facing enum used by most 2D primitives. It allows you to specify which direction the mesh should be facing upon creation, similar to Godot's "Orientation" for quad meshes. It also doubles as a way to flip 2D meshes with e.g. Facing::NEG_Z.
// These are equivalent
meshes.add(Rectangle::new(5.0, 2.5).mesh().facing(Facing::X));
meshes.add(Rectangle::new(5.0, 2.5).mesh().facing_x();

Another reason for Facing is that it will allow us to cleanly reuse code for 3D primitives. For example, Cylinder, Cone, and ConicalFrustum can use Circle with different orientations for the bases instead of reimplementing the same logic each time.
I also updated the 2d_shapes example to use primitives, and tweaked the colors to have better contrast against the dark background.
Before:

After:

Here you can see the UVs and different facing directions: (taken from #11007, so excuse the 3D primitives at the bottom left)

Changelog

Added bevy_render::mesh::primitives module
Added Meshable trait and implemented it for:

Circle
Ellipse
Rectangle
RegularPolygon
Triangle2d

Added Facing enum
Implemented Default and Copy for several 2D primitives
Updated 2d_shapes example to use primitives
Tweaked colors in 2d_shapes example to have better contrast against the (new-ish) dark background

I think we should also consider re-exporting the primitives so that you don't need primitives::foo everywhere. They're meant to be used all over the place, for e.g. meshes, bounding volumes, and eventually gizmos and colliders, so I think having them in the prelude is justified.
I'll probably make a separate PR for this now

@ManevilleF has done similar things in hexx for hexagonal meshes: could you give us a review?

I like it ! it also could allow for user custom primitives.
Some concerns:

I'm not a fan of the Facing enum, why not use a Vec3 directly ? like mesh.facing(Vec3::Z), it would allow for more rotation options
I think the builders should not take in account the shape agnostic options like facing, offset, etc which all work the same, changing the facing means rotating the vertex positions and normals, changing offset just offsets the vertex positions, etc. those methods could be added to Mesh instead and applied by the builders

I'm not a fan of the Facing enum, why not use a Vec3 directly ? like mesh.facing(Vec3::Z), it would allow for more rotation options

Yeah, I could maybe do this instead. It would just be more expensive since you'd need to rotate everything afterwards instead of having the vertex positions "predefined" as rotated. But this cost probably isn't that substantial in practise.
I'll try this and see if there are any larger issues that would make this unviable

I think the builders should not take in account the shape agnostic options like facing, offset, etc which all work the same, changing the facing means rotating the vertex positions and normals, changing offset just offsets the vertex positions, etc. those methods could be added to Mesh instead and applied by the builders

I believe EllipseMeshBuilder::build_mesh_data is currently the only method that has an offset, and it's not public. The reason it has it is to allow reusing the same implementation for e.g. bases of 3D primitives like cylinders, as I briefly mentioned earlier.
My code for adding bases to cylinders currently looks like this:
// Top and bottom
let base = CircleMesh::new(self.cylinder.radius, self.resolution as usize);
base.facing_y().build_mesh_data(
    Vec3::Y * self.cylinder.half_height,
    &mut indices,
    &mut positions,
    &mut normals,
    &mut uvs,
);
base.facing_neg_y().build_mesh_data(
    Vec3::NEG_Y * self.cylinder.half_height,
    &mut indices,
    &mut positions,
    &mut normals,
    &mut uvs,
);

I need the offset so that the top and bottom are at the correct positions, and the facing direction is needed so that they're oriented correctly. I don't think it's possible to efficiently pass in a Mesh and just extend its positions, normals, and so on, which is why they're passed separately and the Mesh is only created at the end. This is somewhat similar to what bevy_more_shapes does with its MeshData struct, although it doesn't reuse code as much for e.g. the cylinder top and bottom.

Another reason for not having facing on Mesh is that you'd need to first build the mesh, which makes the API slightly less convenient:
// Now
meshes.add(Circle::default().mesh().facing_y())

// With facing on Mesh
meshes.add(Circle::default().mesh().build().facing_y())

Probably not a huge deal though. I think a transform_by on Mesh would be valuable either way.

Another reason for not having facing on Mesh is that you'd need to first build the mesh, which makes the API slightly less convenient:
// Now
meshes.add(Circle::default().mesh().facing_y())

// With facing on Mesh
meshes.add(Circle::default().mesh().build().facing_y())

Probably not a huge deal though. I think a transform_by on Mesh would be valuable either way.

It's not incompatible, the facing method can be on the builder but be applied to Mesh. That's what I do in hexx mesh

Basically my suggestion is that those primitive mesh builders output a Mesh, which has generic methods like facing, rotated, offsetted, scaled, or whatever.
So the builder only has to think about building a Mesh, and not care about transformation specifics, as it will simply call the appropriate Mesh methods

Gotcha, makes sense. I already made PRs to add transformation methods (#11454) and merging support (#11456) for Mesh directly since they're useful to have anyway. It might be a bit expensive compared to a separate MeshInfo/MeshData struct though, so I'll probably add that too

I don't know if an extra struct is needed, I have one in hexx because bevy is not a dependency of the lib

I think it would actually make sense to just remove the stuff related to facing for now and to split it up into a future PR. It's a feature that doesn't exist for the old/current shapes, so it's probably not needed for initial primitive meshing support either.
Moving facing things to a follow-up PR might make the changes in this PR more trivial and easier to review, which would help us move forward with meshing support quicker. Some 3D shapes might end up havIng a bit more code duplication (because e.g. Circle can't be reused), but that's also the way the current shapes work, so it wouldn't be a regression in that sense.

Yep, let's split that out!

Alright, I've made some changes:

Removed Facing and other code related to transformations.
Removed builder structs from RegularPolygon, Rectangle, and Triangle2d; without facing they only store the shape, so it makes more sense to just return a Mesh directly.
Moved all 2D meshing to a single dim2 file for now. This is more consistent with primitive code in other crates (e.g. bevy_math::primitives::dim2) and some files were only about 30 lines of code when the impls were separate. We can always split this up as needed later on.

One extra thing to note is that Bevy's "old" Quad mesh has a flip property for flipping the UVs horizontally. I didn't add this to Rectangle yet because (1) I think you could just flip the texture in some other way, and (2) I'm not sure why only quads would support this and not other meshes. I could add it if it's actually valuable and I'm missing something though

authors: Jondolf ManevilleF alice-i-cecile


text:
bevy_reflect: Automatic arg count validation

Objective
Functions created into DynamicFunction[Mut] do not currently validate the number of arguments they are given before calling the function.
I originally did this because I felt users would want to validate this themselves in the function rather than have it be done behind-the-scenes. I'm now realizing, however, that we could remove this boilerplate and if users wanted to check again then they would still be free to do so (it'd be more of a sanity check at that point).
Solution
Automatically validate the number of arguments passed to DynamicFunction::call and DynamicFunctionMut::call[_once].
This is a pretty trivial change since we just need to compare the length of the ArgList to the length of the [ArgInfo] in the function's FunctionInfo.
I also ran the benchmarks just in case and saw no regression by doing this.
Testing
You can test locally by running:
cargo test --package bevy_reflect --all-features

The doc of with_args should probably be updated too.

Good point! I’m actually thinking we remove these info-modifying methods since they break function overloading and don't really provide any benefit.


text:
GPU Picking v2

Objective

Add native support for gpu picking to bevy
This is an updated version of https://github.com/bevyengine/bevy/pull/6991

Solution
This happens over multiple frames

Frame N:

For each visible mesh, generate a mesh id.
For each mesh being rendered, output it's mesh id to a texture. This is just a new render attachment to the main pass.
Once everything is rendered copy that texture to the cpu

Frame N + 1:

Map the mesh id buffer and send it to the main world.
This step will poll the gpu if necessary, so it could block here

Frame N + 2:

From the main world you can give it a position like the current mouse position and know exactly which entity was rendered at that specific screen location. Since this takes multiple frames, the exact entity under the mouse might not be the same as the one visible.

This works at the Camera level, so it will work with multiple windows or split-screen.

The texture format is Rg16Uint, this means it can only render up to 65536 visible entities

Currently only implemented for 3d to keep it simple

Works with transparency, opaque, alpha mask and custom materials:
https://github.com/bevyengine/bevy/assets/8348954/7e0bce0b-e5be-40a0-98fd-dad66c317dbe
Here's the mesh id texture generated for the above video

Multiple window support:
https://github.com/bevyengine/bevy/assets/8348954/8e9d0c17-8f7f-4390-8a30-01aa362acaa4
Open Questions

Should this be in the prepass instead of the main pass?
Naming could probably be improved

I tried to name most things GpuPicking instead of just Picking because this is not intended as an end user api and more of a low level api for things like bevy_mod_picking to build on top.

What to do with the mesh id field added to MeshUniform?

Should it be a separate uniform?
Just feature flag it?
Just keep it, it could be useful for things like occlusion culling and maybe even a debug view

Changelog

Added GpuPickingPlugin, GpuPickingCamera, GpuPickingMesh

Future Work

2d
Copy depth buffer and use it to determine world position under mouse
Various performance improvements
Web support (currently untested, it might already work)

Co-Authored By: @torsteingrindvik

Any chance that this PR will be able to get into 0.11? Looks like you have done a lot of good work on it @IceSentry  and would be great to be able to use it with an actual Bevy release soon!

It's pretty much ready, but it needs reviews and since 0.11 is so close people are focusing on older PR and getting the release ready. It will most likely get merged pretty fast after 0.11 is released though.

Oh, just saw the conflicts, I'll need to fix that first.

The mouse position should use the physical coordinate because the readback buffer is using the physical size.
// ***** now the result is correct  ****//
let mouse_position = (moved_event.position.as_dvec2() * moved_event.scale_factor).as_uvec2();

    for gpu_picking_camera in &gpu_picking_cameras {
        // This will read the entity texture and get the entity that is at the given position
        if let Some(entity) = gpu_picking_camera.get_entity(mouse_position) {
            if let Some(hovered) = *hovered {
                if entity != hovered {
                    set_color(hovered, Color::BLUE);
                }
            }
            set_color(entity, Color::RED);
            *hovered = Some(entity);
        } else {
            if let Some(hovered) = *hovered {
                set_color(hovered, Color::BLUE);
            }
            *hovered = None;
        }
    }

I have made the example working on web/wasm, but the blend function is a problem because we use the TextureFormat::R16Uint, this format doesn't support the blend function. So the blend function had to be set to none when using gpu picking, you can see the left cube is not transparent.

@happydpc can you make a PR to my branch with the web support

Sure, I am still trying modify the copied buffer size, if we only want to pick the point nearby, we don't need to copy the entire texture then.

I intentionally left that out as a feature for 2 reasons:

I don't want to overcomplicate a PR that is already really big. This can be done in a future PR
It won't work with multi touch on mobile so it needs to be optional.

Should this be in the prepass instead of the main pass?
I see definite uses for this if it can be done in the prepass when enabled. Accurate outlines are one example.

What is the current status of this PR? Hoping to see this merged at some point, lots of good work has been done already

Hello! I want to ask what the current status of this PR is and how it will behave with custom shaders. Will it also be possible to render something in the picking that is not visible in the normal render mesh? For example a bigger interaction circle for mobile/touch input but without rendering that in the real scene. And it also seems like it just directly results in the entity id, I wonder if it would be easy to add support for multiple picking textures which then not directly hold the entity id but an id created with the picking texture in a follow-up PR.
Thanks

The branch is currently very outdated so I'll need to update it. It's not high on my priority list right now but I want to get back to this at some point in the next few months

Bevy's internals have change too much since this PR and this would most likely need a rewrite. The general principle would still be the same though.
This is currently low priority for me, so I'll close the PR but if anyone wants this feel free to adopt it.

authors: DasLixou IceSentry Jeff425 happydpc mtsr


text:
GitHub Actions: reduce cache usage

Objective

Bevy repo is pretty much always over quota on GitHub Actions cache
Has GitHub is cleaning to keep the repo under quota, actions almost never hit cache

checking a few times in the last few days, cache is between 20 and 40GB

Solution

Reduce cache usage in actions:

don't cache on nightly build as it's not valid for very long anyway
share cache between jobs where it seems possible
don't cache mobile builds as they are big and slower to save than to rebuild
remove example bins from cache

I don't think the cache sharing will work in this way.
For example, cargo check and cargo test cannot share a cache, because they are compiled with different profiles.
For example, the cargo check job might complete first and generate the cache entry for the cache key.
Then cargo test will use this entry, but require a full re-compilation every time, because the cached artifacts cannot be used for the test profile.
Afterwards, the cache will not be updated, because the cache key didn't change.

authors: TimJentzsch mockersf


text:
Server slowness caused by statistics that is running even I set to false

Hi. Thank you for making our life easier! This lib helped me a lot!
I've tried to change the value of 'enable_statistics' to false to avoid server making extra load when sending messages through the WebSocket, but without success.
The config/broadcasting.php apps section:
'apps' => [
    [
        'id' => env('PUSHER_APP_ID'),
        'name' => env('APP_NAME'),
        'key' => env('PUSHER_APP_KEY'),
        'secret' => env('PUSHER_APP_SECRET'),
        'enable_client_messages' => true,
        'enable_statistics' => false,
    ],
],

As you can see, the laravel-websockets route still working. I think it also works when sending events through the server and it's causing the slowness.

The route will always work. I think the difference if you set enable_statistics to false is that you won't see the nice stats graph anymore.

@stefandanaita Thanks for reply!
But, how to disable the statistics? Is it causing the slowness?

I would also like to know if this is responsible for slowness. @sayhicoelho did you find out more about this?

I did not know how to solve this yet @andrew-bibby

I think it's a good fix to add an --enable-statistics flag when opening the server to avoid any ticker coming for statistics.

authors: andrew-bibby rennokki sayhicoelho stefandanaita

repo: beyondcode/laravel-websockets


text:
hardware address calculation bug

there's technically a bug on this line https://github.com/beyonddream/snowid/blob/0a6c4abc99bc80c84979e24ad1f085a905912bc3/snowid_util.c#L91
you need to + 1 to strlen so that the terminal null characters are also compared, otherwise the user could specify eno1 but the function would hit on eno10. obviously i doubt this would ever be reached, but in the interest of absolute correctness!

the loopback check could also be moved outside of the loop, and the strncmp(ifa->ifa_name, interface, strlen(interface)) moved to the very beginning of the loop (no sense checking or calculating anything else if this is false)

the loopback check could also be moved outside of the loop, and the strncmp(ifa->ifa_name, interface, strlen(interface)) moved to the very beginning of the loop (no sense checking or calculating anything else if this is false)

Not sure how loopback check can be moved outside the loop. I don't want to assume it is going to be first in the list either.
Regarding moving the comparison check to the beginning, the behavior of this function is that if the check is false always, it should pick a random one (right now it picks the last one) from the array of hw addresses.

authors: beyonddream victorstewart

repo: beyonddream/snowid