fix: avatareditor hud audiodesign

What?
Redesigned audio and some small feature alterations for the Avatar Editor HUD.
Why?
The audio wasn't optimal before. More polished now.

I'd be comfortable with merging this branch at this point. Issues I want to fix later:

The music should loop more seamlessly.
The music is only one minute long. Need to add more to avoid driving users insane.
The randomize button leads all of the wearable sounds to play. I feel like it works, but needs Shibu's approval.

Alright, now it should be good to merge.


I want to send a pull request for es_features.cfg

Hi, where is es_features.cfg?
The comment in the file says:
<!-- es_features.cfg edited for Batocera ES Windows Build. -->
But my change will have a global impact.
I found only some usage of it here: CustomFeatures.cpp
How is it generated? Where is it stored?
I work on CRT SwitchRes fix and finally, after two years, got interlaced resolution fixed on NTSC/PAL CRT TV's such as Sony PVM.
To work with that, I had to add this last property to es_features.cfg:
    <feature name="CRT SCREEN OUTPUT" value="CRTSwitch">
      <choice name="NO" value="false"/>
      <choice name="15KHz" value="1"/>
      <choice name="31KHz (Standard)" value="2"/>
      <choice name="31KHz (120Hz)" value="3"/>
      <choice name="Switchres.ini (INI)" value="4"/>
    </feature>

The actual fix will be in this SwitchRes C++ library: https://github.com/antonioginer/switchres/issues/96 , which RetroArch developers manually copy to their 'deps' directory in RetroArch source code repo.

generated by https://github.com/batocera-linux/batocera.linux/blob/master/package/batocera/emulationstation/batocera-es-system/batocera-es-system.py
mainly from
https://github.com/batocera-linux/batocera.linux/blob/master/package/batocera/emulationstation/batocera-es-system/es_features.yml

Thank you, that is a little bit unlucky for me to have another emulationstation folder somewhere in batocera.linux repository. So I will need to send pull request there and ask @fabricecaruso how they generate it on Windows. As I cannot find this one in Batocera-Ports Visual Studio solution.

It depends if you are taking about batocera or retrobat. It's not the same file & not the same place

Lets say I would like to cover all the grounds for everyone:
batocera.linux
batocera.windows
batocera.ports
retrobat
That would be the best for people. If I forgot something, feel free to correct me.

batocera.windows ???? Batocera & Retrobat are different projects.
Retrobat is some kind of consolitation of many subprojects including this EmulationStation.
If you want to see how retrobat setup is build, see https://github.com/kaylh/retrobat/

You have had WIN branch in Batocera for a long time. Yes, I know it is not easy to answer.
Just tell me how you build this es_features.cfg in Windows, please and where can I send that pull request. Or you are using batocera.linux python script? I already look in Retrobat as well. It is not there.

Thanks for providing the link, I will provide it myself: https://github.com/kaylh/RetroBat/blob/ffe3091fe5520b77a10cb327e67f54f492b63a4c/system/templates/emulationstation/es_features.cfg
Sometimes asking a developer for info is like left hand does not know what right hand is doing.

It is strange that searching for 'es_features.cfg' file directly will not find it - that's why a link would be helpful next time. Also your style of communication could be better. Instead of having your keyboard stuck at '????', you could provide a helpful information beforehand. Perhaps a more respect to senior developers would be nicer. Thank you for consideration & understanding.

waoh... you are very beginner with git ?
Use "go to file" button instead, or search you fork local files....
It's in /system/templates/emulationstation/es_features.cfg


envAtlas problems with StandardMaterial

In class StandMaterial, property "prefilteredCubemaps" is defined with setter, witch generating envAtlas from prefilteredCubemaps.
The result of generated Texture is just stored in the material instance, not shared with others.
If there are multiple material instances, with save prefilteredCubemaps asset, same number of envAtlas texture (512 * 512) will be generated at runtime.
That makes our projects crash on mobile device, such as iPhone.
The envAtlas texture, generated by generatePrefilteredAtlas, cannot be restored by uploading source, when context restore.

Hi @Casval111 ,
Just generate the envAtlas yourself from the cubemap and set it directly on StandardMaterial.envAtlas on all materials that need it?

The envAtlas texture, generated by generatePrefilteredAtlas, cannot be restored by uploading source, when context restore.

You are correct, this is a known issue. Ultimately the envAtlas should be pre-generated and stored in a PNG so reloading after restore would just work.
Thanks!

@Casval111 Just a note that the Texture Tool has been updated to allow you to generate the envAtlas texture.

We can close this as done, new prefiltering lighting in the Editor is stored as png.


GOVUK PaaS

Your call as to whether or not to change to .fetch (see comments). I'm happy with it either way. Good work. :shipit:

Thanks!


-RemoveSharePointLocationException

When you remove a site from the -removeSharePointLocationException it never goes back on retention.

Hello @jluce512 how are you?
Do you refer to which article? can you put the URL here? maybe the article for Set-DlpCompliancePolicy?
I created a test dlp policy, chose All SharePoint sites and excluded a site, and then successfully removed the site using the parameter removeSharePointLocationException, let me know if I understood you correctly.
Thanks

The article I was referring to is set-retentioncompliancepolicy I set one to addsharepointlocationexception did some maintenance on some file versions, then reran the script with a removesharepointlocationexception.  The site is removed, but when you check the site in SharePoint Admin Center you no longer see This Site has a compliance policy to block deletion:
The site below has never had any exception.  The site I did put the exception to had this notification before the site was excluded.  When the site was removed from the exclusion that notification does not reappear.
<EMAIL_ADDRESS>From: Andres Mariano Gorzelany<EMAIL_ADDRESS>Sent: Tuesday, March 2, 2021 8:16 AM
To: MicrosoftDocs/office-docs-powershell<EMAIL_ADDRESS>Cc: Jamie Luce<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/office-docs-powershell] -RemoveSharePointLocationException (#7348)
Hello @jluce512https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjluce512&data=04|01|jamie_luce%40gensler.com|a569274820d14c18826608d8dd85c031|94a74758f2ff413c9f705725701b8d02|0|0|637502913828204664|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=8CcDqbTqwPnLcYNsOrdBYOrzvU9XgLwhB%2BRGE4SH0QA%3D&reserved=0 how are you?
Do you refer to which article? can you put the URL here? maybe the article for Set-DlpCompliancePolicy?
I created a test dlp policy, chose All SharePoint sites and excluded a site, and then successfully removed the site using the parameter removeSharePointLocationException, let me know if I understood you correctly.
Thanks

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Foffice-docs-powershell%2Fissues%2F7348%23issuecomment-788939742&data=04|01|jamie_luce%40gensler.com|a569274820d14c18826608d8dd85c031|94a74758f2ff413c9f705725701b8d02|0|0|637502913828204664|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=VgXOwiXK6LXUe%2BBwpmWCLjWosQE%2BL8b%2BNuFvbuGLBjk%3D&reserved=0, or unsubscribehttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJWJVHEW2VP3AWNMNRBQQFTTBTXLHANCNFSM4YLIIHUQ&data=04|01|jamie_luce%40gensler.com|a569274820d14c18826608d8dd85c031|94a74758f2ff413c9f705725701b8d02|0|0|637502913828214616|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=6iHQ8TPmNmFbAwXWI0b6hQAJsYqTOUHbhyu87yj8sSU%3D&reserved=0.

The article I was referring to is set-retentioncompliancepolicy I set one to addsharepointlocationexception did some maintenance on some file versions, then reran the script with a removesharepointlocationexception. The site is removed, but when you check the site in SharePoint Admin Center you no longer see This Site has a compliance policy to block deletion: The site below has never had any exception. The site I did put the exception to had this notification before the site was excluded. When the site was removed from the exclusion that notification does not reappear.

Hello @jluce512 how are you? Hope you are doing good, in that case, the best option would be to open a support ticket to understand why the site did not get the policy to block deletion again, as here we are limited to documentation changes and fixes.

@get-itips Thank you very much for the contribution and sharing this explanation. @jluce512 Hope this comment is helpful for you. Considering the nature of the issue, as advised, please open a service ticket in your tenant and follow with them for the resolution. We proceed here to close it.
We will be very happy if you can share the outcome or resolution with us if you see documentation update is required. We will certainly update this documentation with that valuable information. Thanks again, for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Missing ExpressionProcessor

With 2.0.1 i got the Exception java.lang.NoClassDefFoundError: nz/net/ultraq/thymeleaf/expressions/ExpressionProcessor
at nz.net.ultraq.thymeleaf.decorators.DecorateProcessor.doProcess(DecorateProcessor.groovy:110)
and the class misses in my distribution.. what's wrong?

You forgot to include the additonal JAR for expressions added since 2.0.1
Le 27 juil. 2016 ? 16:49, ochsA <notifications<EMAIL_ADDRESS>a ?crit :
With 2.0.1 i got the Exception java.lang.NoClassDefFoundError: nz/net/ultraq/thymeleaf/expressions/ExpressionProcessor
at nz.net.ultraq.thymeleaf.decorators.DecorateProcessor.doProcess(DecorateProcessor.groovy:110)
and the class misses in my distribution.. what's wrong?

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/ultraq/thymeleaf-layout-dialect/issues/128, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATA21_sT_TO7JnLsAo3tebSxcgdgrzF8ks5qZ2_UgaJpZM4JWRaz.

Add this to your dependencies

nz.net.ultraq.thymeleaf
thymeleaf-expression-processor
1.1.1

This dependency is already a part of the layout dialect (see: https://github.com/ultraq/thymeleaf-layout-dialect/blob/master/build.gradle#L50, or the generated POM on Maven: https://repo1.maven.org/maven2/nz/net/ultraq/thymeleaf/thymeleaf-layout-dialect/2.0.1/thymeleaf-layout-dialect-2.0.1.pom) so should be downloaded/installed by your build tools when they're run.
If you opted to download the layout dialect via the ZIP bundle (eg: from the Downloads section of the release page on https://github.com/ultraq/thymeleaf-layout-dialect/releases/tag/2.0.1), then all the dependencies including that one are in the Libraries folder, so make sure they're on the classpath of your project when building/running your app.

If you are in some weird state where that dependency isn't being downloaded (which it sounds like), then doing as @ddelamotte suggested and adding the dependency yourself might be one way to kick your build tools in the guts to download it, but you shouldn't have to do that.  I might suggest performing cleans/refreshes of your build tool's cache(s) to make sure it's getting everything right.

Thanks worked fine!


Fixing various typos

Resolving some minor spelling mistakes

Dear @TheFreal,
thank you for the contribution. The project team is working tirelessly on getting the app ready in time and working on many backlog items in parallel. This also means that some implementations cannot be done, yet, as we are, for example, waiting for final texts and translations from dedicated streams as these are not provided by the development team.
Therefore, we unfortunately have to reject your PR for now, please see issue #72 for more details.
To avoid this situation in the future, please open an issue for your fixes first, and wait until the team assigns you to the issue. We will further create issues with the community label, which you can claim by commenting on them and don't have to wait for the assignment.
Thank you for your understanding!
Best,
Marc


refactor: expand programme/curriculum to CM queue

When a Programme or Curriculum record is received the enrichment starts from that record, performing a lookup of associated CurriculumMemberships and syncing them all in a single job.
Refactor the enrichment to instead populate a queue with all related CurriculumMemberships. This queue will then become the single source from which records are pulled for CurriculumMembership enrichment.
This refactoring was previously done for the Placement enrichment.
TIS21-2399

Is there a related PR to add that new queue and entry to tthe parameter store?


FIX: RHMAP-19268 - Client gets null pointer exception when connection tag is disabled

Ref the Issue: https://github.com/feedhenry/fh-js-sdk/issues/256
JIRA: https://issues.jboss.org/browse/RHMAP-19268
Root cause: The validation/implementation req.status was added without considering that the req can be undefined in some situation. In order to prove it note that the req is checked at another point implemented previously. ( https://github.com/feedhenry/fh-js-sdk/blob/2.23.0/src/modules/initializer.js#L81 )

@davidffrench all done for we merge it. Now we just need the approval to do that. Tks :-)


Do not print the variable

Huh, the change is still not there in the master branch.

You probably could manually do what I intended to.

I think I messed up a force push.

It should be fixed now.

Imao the whole code is lost now

#!/usr/bin/env sh

# This script must be run as a normal user as it needs to read the XDG_CONFIG_HOME variable.
# The user will be asked for their password after saving the variable to a file in /tmp.

if [ $USER != root ]
then
    echo This script must be run as root, you will be prompted for your password
    echo ${XDG_CONFIG_HOME:-~/.config} | sudo tee /tmp/user.txt >/dev/null
    sudo chmod 755 $0
    sudo ./$0
    sudo rm /tmp/user.txt
    exit 0
fi

continue=unset

for file in "/usr/share/pulseaudio/alsa-mixer/profile-sets/apple-t2.conf" \
            "/usr/share/alsa-card-profile/mixer/profile-sets/apple-t2.conf" \
            "/usr/lib/udev/rules.d/91-pulseaudio-custom.rules" \
            "/usr/share/alsa/cards/AppleT2.conf"
do
    if [ -f "$file" ]
    then
        if [ "$continue" = "unset" ]
        then
            read -p "Old configuration files are present, do you want to delete them? (y/n) " continue

            if [ "$continue" != "y" ]
            then
                break
            fi
        fi

        rm -v $file
    fi
done

config_home=$(cat /tmp/user.txt)

for file in "$config_home/pulse/default.pa" \
            "$config_home/pulse/daemon.conf"
do
    if [ -f "$file" ]
    then
        echo "You seem to have pulseaudio configuration files present, don't forget to update them if they contain anything specific to T2 Macs"
        break
    fi
done

for dir in "/usr/share/alsa-card-profile/mixer" "/usr/share/pulseaudio/alsa-mixer"
do
    if [ -d "$dir" ]
    then
        cp -rv files/profile-sets $dir
        cp -rv files/paths $dir
    fi
done

cp -v files/91-audio-custom.rules /usr/lib/udev/rules.d/

I had a backup


Triggers comments are not shown

When inspecting triggers of a table, either going to "Triggers" menu or to "Table / Triggers" menu, their comments are not shown.

Please, try the installer from the artifact from here: (will be ready in some minutes)
https://github.com/mariuz/flamerobin/actions/runs/6551576355

Thanks !


Security vulnerability related to dependency https-proxy-agent

The dependency https-proxy-agent v2.1.1 used by mixpanel-node 0.9.0 has a high-severity security vulnerability.
https://snyk.io/vuln/npm:https-proxy-agent:20180402
Please update this dependency to 2.2.1 when you can. Thanks!

Thanks for the ping @mkarazin. v0.9.1 is now published and uses https-proxy-agent 2.2.1.

Thanks for the quick response and version bump!


Bot Goes into Larger cells

Sometimes when it is easily able to get out of a situation, the bot makes the cell go into a larger one, even though it makes no sense and should be able to get out no problem, but it just goes straight into the larger cell.

It's not that it goes into the enemy cells, it's that when it can't find anywhere to go, it simply freezes in place, or goes to the last location where it tried to go to.

Thank you for clearing it up for me :)
Thanks for being so active on this project by the way
On Jun 25, 2015 4:17 PM, "Apostolique"<EMAIL_ADDRESS>wrote:

It's not that it goes into the enemy cells, it's that when it can't find
anywhere to go, it simply freezes in place, or goes to the last location
where it tried to go to.
—
Reply to this email directly or view it on GitHub
https://github.com/Apostolique/Agar.io-bot/issues/157#issuecomment-115400557
.


Revert part of #39

#39 contained some unintended copy pasta in ad8f836 that

increased checkpoint slots to MAX_SLOT+2
introduced unnecessary let-ins in Precompute

This reverts both.

do we split MAX_SLOT into MAX_BLOCK_SLOT and MAX_CHECKPOINT_SLOT in a yet-to-be-committed followup?

I was staring at it with Igor, and having 3 constants (we also have MAX_VOTES) doesn't improve things. Maybe we should just nuke MC_ffg.tla and rewrite it from scratch, now that we know how things work.


Remove pinned scikit since 0.24.0 was released

This PR:

Removes the pin in CI for scikit-image after the release of version 0.24.0 that supports numpy==2.0

Thanks!


Add a constants registry

Description
This pull request adds a constants registry that all constants classes should be registered in. It also adds a couple of helper functions that make use of the registry to remove boiler plate code. Let me know if the implementation looks sensible.
My original intention was to also write something to document the contents of the constants registry. However, I couldn't get the registry to play nicely with sphinx.ext.autodoc. Went down a bit of a rabbit hole with Sphinx custom directives, but in the end gave up on that as well (feature/custom_directive shows my progress there).
This partially addresses #259, though not completely as that issue mentions using the registry for documentation.
Type of change

[ ] New feature (non-breaking change which adds functionality)
[x] Optimization (back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)

Key checklist

[x] Make sure you've run the pre-commit checks: $ pre-commit run -a
[x] All tests pass: $ poetry run pytest

Further checks

[x] Code is commented, particularly in hard-to-understand areas
[x] Tests added that prove fix is effective or that feature works

Codecov Report

Merging #295 (a7427ff) into develop (173c791) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #295      +/-   ##
===========================================
+ Coverage    97.04%   97.08%   +0.03%
===========================================
  Files           46       47       +1
  Lines         2067     2090      +23
===========================================
+ Hits          2006     2029      +23
  Misses          61       61

Files Changed
Coverage Δ

virtual_rainforest/core/__init__.py
100.00% <ø> (ø)

virtual_rainforest/core/config.py
98.66% <ø> (ø)

virtual_rainforest/core/utils.py
100.00% <ø> (ø)

virtual_rainforest/core/constants.py
100.00% <100.00%> (ø)

...rtual_rainforest/models/abiotic_simple/__init__.py
100.00% <100.00%> (ø)

...rest/models/abiotic_simple/abiotic_simple_model.py
100.00% <100.00%> (ø)

virtual_rainforest/models/hydrology/__init__.py
100.00% <100.00%> (ø)

...ual_rainforest/models/hydrology/hydrology_model.py
100.00% <100.00%> (ø)

virtual_rainforest/models/litter/__init__.py
100.00% <100.00%> (ø)

virtual_rainforest/models/litter/litter_model.py
100.00% <100.00%> (ø)

... and 2 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

LGTM - replaces a load of boilerplate with a shared function. The only thing I wondered about is if we can simply run the registry on the constant class name alone, rather than model name and class name, but I can see that parallel implementations (e.g. abiotic) could easily clash. They shouldn't do because as of #278 being resolved only the required constants for models are loaded but it just seems safer to leave it as is.

I might give this a try as I think it could be a solution to the documentation problem. Like autodoc struggles with the current structure of dict[str,dict[str,Class]] but might be able to handle dict[str,Class].

I'm also wondering if we want to replace the model __init__ code with a shared register_model core function? This works but we could bundle a lot of the code into one function and use inspect to autodiscover the components?

Would we be able to us inspect to discover all constants classes (from virtual_rainforest.models.model_name.constants) in cases where a model had more than one class?

So if we define this function:
from types import ModuleType
import inspect
from importlib import resources
from dataclasses import is_dataclass

from virtual_rainforest.core.base_model import BaseModel
from virtual_rainforest.core.logger import LOGGER
from virtual_rainforest.core.config import register_schema
from virtual_rainforest.core.constants import register_constants_class

def register_model(module: ModuleType, schema_filename: str) -> None:
    """Draft model registration function"""

    # Locate the BaseModel subclass for the model, which should be imported into the
    # module root for the model
    model_obj_found = [
        obj
        for nm, obj in inspect.getmembers(module)
        if inspect.isclass(obj) and issubclass(obj, BaseModel)
    ]

    # Check only one BaseModel subclass is found
    if len(model_obj_found) != 1:
        msg = f"Model {module} does not define a single model class"
        LOGGER.critical(msg)
        raise RuntimeError(msg)

    model = model_obj_found[0]

    # Register the schema
    with resources.path(module, schema_filename) as schema_file_path:
        register_schema(
            module_name=getattr(model, "model_name"), schema_file_path=schema_file_path
        )

    # Find and register the constant dataclasses
    constants_classes = [
        nm for nm, obj in inspect.getmembers(module.constants) if is_dataclass(obj)
    ]
    module_model_stem = module.__name__.split(".")[-1]
    for const_class in constants_classes:
        register_constants_class(module_model_stem, const_class)

Then I think the boilerplate in the model __init__ can be:
import from virtual_rainforest.models.soil as this_module
from this_module.soil_model import SoilModel

register_model(this_module,  "soil_schema.json")

Another big advantage to this is that we only have one place to adapt the model registration code when it changes, rather than having to adjust every model. Note that if the xxx_model submodule file was consistently named (e.g. model.py, we wouldn't even have to import the model here, we could inspect module.model in the function. At the moment, I'm using the convenience that it is imported to search from a single BaseModel subclass.

We could always use pkgutil.iter_modules to search all the model submodules for a BaseModel to avoid that import being needed!

I think the decision is that they are all configurable (even g!). The model ones need to be because they are part of sensitivity analysis. Some recent PRs have been explicitly about exposing those values through config. There are then a bunch of shared constants, some of which are truly constant (like g) but some of which are subject to revision. So we use the same mechanisms to access them all, rather than having two different approaches.
The main point of this is to facilitate documentation, by providing somewhere to look up all the defined constants.

@alexdewar this isn't really about core constants, I just added the registry into core.constants as it seemed like the most obvious place. The registry is populated with the default constants classes from each model, so that helper functions can access the classes more easily. These classes can be given non-default values (via the helper functions) when the models are set up.
As David mentioned the other reason is for documentation of constants, but as I mentioned I couldn't really get CONSTANTS_REGISTRY to document nicely with Sphinx, even when I reduced the nesting of the dictionary.

@jacobcook1995 Ahh I see. That makes more sense. In that case though, I think the word "constant" is kind of misleading. If they are properties of the models that you want users to be able to change, then effectively they are parameters. How about calling them "model constants" to make the distinction clearer?
I'm still sceptical about making all constants modifiable though. Would any user really want to modify g? You don't get rainforests on the moon.

You don't get rainforests on the moon.

Maybe we can get Elon to grow some on Mars 😄
We did discuss parameters/constants - these are all values that will be held constant within a single vr_run. While some of them might never vary, having a single kind of structure for holding "constants" seemed simpler to use and to document, rather than having to remember whether it is CoreConst.variable_thing or GRAVITY_G.

Then I think the boilerplate in the model __init__ can be:
import from virtual_rainforest.models.soil as this_module
from this_module.soil_model import SoilModel

register_model(this_module,  "soil_schema.json")

@davidorme I don't think this would work because the model then imports itself during it's import process

@jacobcook1995  Gaah - of course. However, we can probably make it work with __name__ instead. That's a string not a module object but should work.

Surprisingly, it seems fine with import virtual_rainforest.models.soil as this_module actually, it's from this_module.soil_model import SoilModel that causes the problem

Huh. If you use the full name does it work?

Ahh that seems to work!

But... I think we can reduce it to something even simpler - give me 5 minutes.

The logger messages in that are confusing! I was using them to track that it worked. It would be nice to import the BaseModel within the register_model for a complete container of the process, but maybe that's the next PR?

I've implemented the register_model helper function and made the changes that @alexdewar suggested. I didn't reduce the nesting of the dictionary though, as it contains potentially useful information for documenting  (i.e. which model each constants class belongs to).

Is there a reason we can't just standardise on a schema file name (e.g. model_schema.json) and use that everywhere? It seems redundant to have to pass in a file name every time you register a model.

I would be in favour of using a standardised name. The reason we used different names for the {model_name}_model.py files is that there's often reason to look at multiple model's code simultaneously so them having named the same creates significant confusion. I honestly very rarely look at the schema for even one model, let alone look a multiple model's schema at once, so I really don't think there's a chance of significant confusion here

It isn't really magic exactly - it's just auto-discovering the components. The advantage is that __init__ doesn't need to be updated as much as the model code changes, but I do take your point about explicit being clearer.
On the file names, it would be more systematic to have model_name/model_schema.json (and  also model_name/model_class.py for that matter, but that is less important because we access it without the filename). I think the main reason we didn't was to avoid having VSCode tabs with identical titles. Isn't it also better to be explicit about the filename rather than using magic to discover it 😈
I had been wondering about merging the registries too. I think it makes a lot of sense for the models but the core complicates things - it has constants and a configuration schema but isn't a model.

Given that we're only allowing users to register one model class per module (which I think is sensible!), you could move the model registration code out of BaseModel.__init_subclass__...
...and once you've done that you will have all the model registration code in one place (i.e. for model class, schema and constants). Then you can put all of this information into a single model registry object, which should simplify things:

@dataclass
class ModelInfo:
    cls: type[BaseModel]
    schema: dict[str, Any]
    constants: WhateverTypeThisIs

model_registry: dict[str, ModelInfo]
"""Information about models, keyed by name."""

This approach seems sensible to me, far cleaner to have one registry rather than three implicitly associated registry. I guess it does tie us to having a single constants data class per model? But that's probably not an unreasonable restriction anyway

The constants slot could be list of constants classes, so that's fine.
I think we can get this to work with core as well but it would mean that the model registry code has to have a special case where the ModelInfo for core doesn't have a model?  It really doesn't make sense to have to look in a different location for core constants and schema.

It isn't really magic exactly - it's just auto-discovering the components. The advantage is that __init__ doesn't need to be updated as much as the model code changes, but I do take your point about explicit being clearer.

On reflection, I think auto-discovering the constants isn't so bad if there are likely to be multiple constants classes, though personally I think it would be cleaner if models only had one constants class and explicitly passed it to register_model().
For the model class though, as there's only going to be one and you have to import it into __init__.py anyway you might as well pass it to register_model() as that's where it's going to be used. Then you won't have to suppress that flake8 warning.

On the file names, it would be more systematic to have model_name/model_schema.json (and also model_name/model_class.py for that matter, but that is less important because we access it without the filename). I think the main reason we didn't was to avoid having VSCode tabs with identical titles. Isn't it also better to be explicit about the filename rather than using magic to discover it 😈

Hey, I didn't say I was consistent :wink:. I do think it's slightly different for file names though. If someone's looking through your code to figure out where SomeModelClass is instantiated, it would help them to see that it's being passed into register_model.py. It seems more obvious (to me, anyway) that if there are a bunch of files called model_schema.json, that this is a convention and that the core code is doing something special with them. But you could leave it as is if you want to be extra explicit.
I personally don't think having the files called the same thing should be much of an issue -- how often do you have multiple models' schemas open at once anyway? -- but you could stick to the convention you're already using of calling them {model_name}_schema.json and still have them be auto-discovered.

I had been wondering about merging the registries too. I think it makes a lot of sense for the models but the core complicates things - it has constants and a configuration schema but isn't a model.

I'd thought about that. I'd be inclined to just have the core constants and schema be represented by standalone variables separate from the model repository. That way you don't have to have a pseudo-model called "core" or whatever. For when you want to iterate over all constants classes/schemas, you could add helper functions that look in the core as well as in the models repository.

Yeah I terms of the core config schema, it is already treated as a special case (it has to be as it contains a list of model schemas to load). So, it would really just be a change to treating the core constants as a special case, which isn't ideal but doesn't feel like a massive problem either

Given that we're only allowing users to register one model class per module (which I think is sensible!), you could move the model registration code out of BaseModel.__init_subclass__...
...and once you've done that you will have all the model registration code in one place (i.e. for model class, schema and constants). Then you can put all of this information into a single model registry object, which should simplify things:

@dataclass
class ModelInfo:
    cls: type[BaseModel]
    schema: dict[str, Any]
    constants: WhateverTypeThisIs

model_registry: dict[str, ModelInfo]
"""Information about models, keyed by name."""

Okay so I've renamed all the schema files, and started supplying the Model classes directly to register_model. Do we think it makes sense to tackle point 2 & 3 on this PR, or leave that for a later PR?

I'd say a later PR.

Okay cool, if everyone's happy with the current state I'll merge it in, and make an issue for Alex's outstanding points + the documentation issue


TypeError: pad() got an unexpected keyword argument 'pad_witdth' in test.py

Good job! May I ask a question?
I tried to run the test.py on a V100 with the Cuda version being 10.2. The data is from ./img, and I set the size being 1280*720, the same as the original size. But I meet the following error:
File "CREStereo/nets/corr.py", line 42, in get_correlation     (0, 0), (0, 0), (pady, pady), (padx, padx)), mode="replicate") TypeError: pad() got an unexpected keyword argument 'pad_witdth'
It means that I may use the wrong type, but I checked the code and did not find the problems:
`
def pad(
src: Tensor,
pad_width: Tuple[Tuple[int, int], ...],
mode: str = "constant",
constant_value: float = 0.0,
) -> Tensor:
r"""Pads the input tensor.
Args:
    pad_width: A tuple. Each element in the tuple is the tuple of 2-elements,
        the 2 elements represent the padding size on both sides of the current dimension, ``(front_offset, back_offset)``
    mode: One of the following string values. Default: ``'constant'``

        * ``'constant'``: Pads with a constant value.
        * ``'reflect'``: Pads with the reflection of the tensor mirrored on the first and last values of the tensor along each axis.
        * ``'replicate'``: Pads with the edge values of tensor.
    constant_val: Fill value for ``'constant'`` padding. Default: 0

Examples:
    >>> import numpy as np
    >>> inp = Tensor([[1., 2., 3.],[4., 5., 6.]])
    >>> inp
    Tensor([[1. 2. 3.]
     [4. 5. 6.]], device=xpux:0)
    >>> F.nn.pad(inp, pad_width=((1, 1),), mode="constant")

`
I used the right Tuple type, but something wrong happened.

I had the same issue and found a typo in the original corr.py line 39 (line 42 in your case). Change 'pad_witdth' to 'pad_width' should solve the problem. Hope this helps!

In the original corr.py line 39 (line 42 in your case), change 'pad_witdth' to 'pad_width' should solve the problem. Hope this helps!

@yupeichen Thank you! I take many things into consideration except this. It works.


Keep checkboxes in viewport

@hediet I think this is a good example

I got feedback from a friend who hit this same behavior. They had several coworkers look at this screen and they could not discover what to do the first time. Only after finding a tutorial on YouTube did they figure out that checkmarks were the mechanism.
Essentially we should show the checkmarks always even if the chunks are larger than the viewport, they should probably float. Another idea discussed was allowing you to right click in the chunk to accept it
Originally posted by @sbatten in https://github.com/microsoft/vscode/issues/155911#issuecomment-1199539654

Closing as duplicate


moveit_py and franka_ros2

I have a situation where I need to be able to use moveit_py and franka_ros2, but moveit_py isn't available for humble, and franka_ros2 doesn't compile for iron.
In general, would you recommend that I try to compile moveit_py for humble, or try to debug franka_ros2 for iron (or perhaps another solution I haven't thought of)?
I've tried the approach here:
https://moveit.ai/moveit 2/ros/2023/05/31/balancing-stability-and-development.html
but that led to libsrdfdom version incompatibility issues

Hi @adamrankin ,
are you sure that moveit_py isn't available for humble? Maybe I don't understand this page https://index.ros.org/p/moveit_py/#humble but it should be available.. no?
Otherwise, I also read in some thread to compile moveit for humble from source - at least the moveit_py bindings should then also come along.
Cheers,
Andreas

Yes, moving the moveit repo leads to libsrdfdom version conflicts. Moveit uses 2.0.5 but something in humble still uses 2.0.4. I will investigate.

After much exploration what I'm really looking for is a python interface to MoveGroupInterface, which doesn't exist for ros2. moveit_py is more about creating your own motion planning instance, whereas I want to send messages to an existing motion planning instance.
This is barely related to the above question, but moveit_py for humble was what started me on this path.
For anyone who reads this, I just made a symbolic link for 2.0.4 to 2.0.5 to avoid the issue.

Thank you for sharing :smile:


Failure not an embedded list when using Prims.norm

The following example raises Failure("(Tm_name: y) Not an embedded list: y"):
module Norm_unit

let foo (_:unit) : unit = norm [zeta] ()

The argument and return type annotations are necessary. Having some reduction step is needed, but it doesn't seem to matter which one.

The workaround is to define the steps at the top-level, i.e.:
module Norm_unit

let steps = [zeta]

let foo (_:unit) : unit = norm steps ()

Error is now slightly different
/home/guido/r/fstar/bin/../ulib/prims.fst(149,30-149,31): (Warning) Not an embedded list: y (see also /home/guido/r/fstar/bin/../ulib/prims.fst(149,13-149,14))
Unexpected error; please file a bug report, ideally with a minimized version of the source program that triggered the error.
Failure("Empty option")

This is caused by the let binding in the encoding. The formula we're normalizing contains roughly y == [zeta] ==> norm y (), and then y is not a list of steps definitionally, causing the unembedding failure.

This works with F* master. I remember @nikswamy fixed this sometime back. Closing the issue.


Fix 2384

Fixes #2384

Review checklist
The author performs the actions on the checklist. The reviewer evaluates the work and checks the boxes as they are completed.

[ ] Summary. Write a summary of the changes. Explain what you did to fix the issue, and why you did it. Present the changes in a logical order. Instead of writing a summary in the pull request, you may push a clean Git history.
[ ] Documentation. Write documentation for new functions. Update documentation for functions that changed, or complete documentation where it is missing.
[ ] Tests. Write unit tests for every change. Write the unit tests that were missing before the changes. Include any examples from the reported issue as integration tests.
[ ] Clean up. The changes are already clean. Clean up anything near the changes that you noticed while working. This does not mean only spatially near the changes, but logically near: any code that interacts with the changes!

The actual issue was not related to the pull requests I reverted in this branch, so I'm closing this pull request.


rustc: 1_52, use correct llvm version

Motivation for this change
rustc form rustup uses llvm12
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

It would be great to see this merged before the start of next staging-next.

ofborg failure is not related to this changes, I've managed to successfully build and run fd (on x86_64).


Added connecting with the default credentials (GCE, GAE)

Added connecting from default application credentials (compute engine, app engine, cloud shell)
Closes #4

Thanks.


May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
email<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
email<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
email:<PHONE_NUMBER>@qq.com(or<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much<EMAIL_ADDRESS>
您好，您收到代码了嘛

没收到，没给我
---- Replied Message ----
| From | @.> |
| Date | 08/20/2024 22:25 |
| To | lhy-zjut/CFMW @.> |
| Cc | ymengjiang @.>,
Author @.> |
| Subject | Re: [lhy-zjut/CFMW] May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much! (Issue #6) |
May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much! @.***
您好，您收到代码了嘛
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

请问您能否将论文中的完整代码发送给我？仅出于学习和研究目的，非常感谢！
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much<EMAIL_ADDRESS>

我没有啊，不是我写的😭
---- Replied Message ----
| From | @.> |
| Date | 08/27/2024 09:42 |
| To | lhy-zjut/CFMW @.> |
| Cc | ymengjiang @.>,
Author @.> |
| Subject | Re: [lhy-zjut/CFMW] May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much! (Issue #6) |
May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much! @.***)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

请问可以把论文中的完整代码发给我吗？仅供学习研究，非常感谢！
<EMAIL_ADDRESS>

他这个代码我觉得应该跟Cross-Modality Fusion Transformer for Multispectral Object Detection这篇论文一样，只不过把别人的transformer block改成了Mamba：代码地址在：https://github.com/DocF/multispectral-object-detection。感兴趣自己看

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
email<EMAIL_ADDRESS>

May I ask if you can send me the complete code in the paper? For learning and research purposes only, thank you very much!
email: [2420748920@qq.com](or<EMAIL_ADDRESS>

请问您能否将论文中的完整代码发送给我？仅出于学习和研究目的，非常感谢！
电子邮件：<EMAIL_ADDRESS>


set random_state in rotation forest

Reference Issues/PRs
see #711
What does this implement/fix? Explain your changes.
attempts to fix the sporadic fail by setting the random_state in RotationForestClassifier

_clone_estimator should already be setting the random state, if it was not, I think we would be seeing issues with other estimators.
Have you managed to reproduce the failure locally? Just wondering if it is OS specific really.

Ah never mind, I see you have linked in the issue. Appears everywhere.

just had a quick scan and took a punt on this, its appearing frequently, but not so frequently to be an obvious bug. Cant reproduce it, although a lot of the fails are windows. Ah this fails for something else!

I think the test is just the transform portion, not the classifier

just ran it 20 odd times locally, no fails


Argo-workflows with name > 52 characters fail if run as CronWorkflows

If name > 52 characters, the workflow fails to start anyway. The workflow controller fails with:
time="2024-04-29T19:07:01.554Z" level=error msg="invalid cron workflow" cronWorkflow=jobs-default/nbcreditscorev4d5mx.prod.main.eventtrainnbcswithfixeddata error="cron workflow name \"abcreditscorev4d5mx.prod.main.eventtrainabcspqrfixederty\" must not be more than 52 characters long (currently 57)"

Would be easy if the user got this error (or similar) at the time of creating the workflow itself.

The user experience is quite tricky here because the permissible name length for regular Argo workflows is greater than for Cron workflows.
So,

The user creates a flow and run python flow.py argo-workflows create. This creates the workflow template without any error
The user is able to run this flow either via python flow.py argo-wokflows trigger or via the Argo UI and it works just fine.
The user then adds @schedule decorator and run python argo-workflows create. This creates the workflow template and the CronWorkflow. No errors.
But if the name > 52 characters, the actual flows don't run on the cron schedule. The only way to identify the problem is to look at the argo-workflows-controller logs as shown above and see the error.

What's needed here is the following.
When a user creates a flow with @schedule:

Construct the name as it is done today. If the name length < 52 chars, create the template, cronworkflow.
If the name length > 52 chars:

check if there is a previously created cronworkflow object. If so, delete it (since it wouldn't be running anyway).
create a name such that it is < 52 characters. e.g. take all characters > 46 and construct a 6 byte has to fit into 52 chars

Create the new cronworkflow

/cc @savingoyal @saikonen


tests: drivers: sensor: temp_sensor: drivers.sensor.temp_sensor fails on nrf54h20

Describe the bug
The tests:

tests/drivers/sensor/temp_sensor/drivers.sensor.temp_sensor

Observed for

nrf54h20dk/nrf54h20/cpuap

To Reproduce
Steps to reproduce the behavior:

have nrf54h20dk/nrf54h20/cpuap connected
go to your zephyr dir
call ./scripts/twister -T  tests/drivers/sensor/temp_sensor -p nrf54h20dk/nrf54h20/cpuapp --device-testing --device-serial /dev/ttyACM0 -v --inline-logs
See console output with error

Expected behavior
Valid console output
Impact
Not clear
Logs and console output
**ASSERTION FAIL [len <= sizeof(rx_buffer)] @ ../../../../../../../../../../zephyr/zephyr/subsys/ipc/ipc_service/lib/icmsg.c:190
E: r0/a1:  0x00000004  r1/a2:  0x000000be  r2/a3:  0x00000000
E: r3/a4:  0x00000004 r12/ip:  0x00000001 r14/lr:  0x0e0a8129
E:  xpsr:  0x21000000
E: Faulting instruction address (r15/pc): 0x0e0b04f6
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x2f0119a8 (icmsg_workq)
E: Halting system

There are expected ping/pong messages.
Environment (please complete the following information):

OS: Ubuntu 20.04.1 LTS
Toolchain Zephyr SDK 0.16.8
Commit SHA or Version used: v3.7.0-4183-g66ff30efb4d7

This assertion (or another one in the test itself) starts to fail with 022122d659a7c10180b8a91c6a0b49874f2850fa, but the problem disappears when the SysCtrl firmware is updated accordingly. Thus, there's nothing to be fixed here.


Add log2 to Work

Adds method Work::log2() providing value equivalent to Bitcoin Core's log2_work in its logs. Fixes #1326.
Questions:

The original issue (#1326) also suggests to add log2 to Target but it does not seem to be meaningful, does it? Bitcoin Core, to which the issue refers, also displays only log2 of work.
Although work should not be 0, the type allows it. In this case, log2 would return -inf. I think we could leave it like that but if there are suggestions to deal with it in a different way, please let me know.

but it does not seem to be meaningful, does it?

Oh, right. It wouldn't hurt but also probably not useful.

0, the type allows it. In this case, log2 would return -inf.

Yeah, -inf makes sense. I think last time we concluded preventing zero doesn't make sense.

can you please squash the commits?

Yes, squashed, @sanket1729.

Hah, cool! I was pretty apprehensive about this feature, but just manually coercing 2**128 to a f64 is a pretty clever solution.

Frustratingly CI is failing because log2 is not available on ARM...I think we should feature-gate this method, but I'm not sure how exactly.

Frustratingly CI is failing because log2 is not available on ARM.

I am not familiar at all with other architectures. How about log10 or ln, might they be available?

How about log10, might it be available?

I managed to run the embedded test and seems like the answer is negative.

Heh, maybe just log? But I'm doubtful.

This has nothing to do with ARM, logarithm just isn't in core, it needs std.
I suggest we just #[cfg(feature = "std")] #[cfg_attr(docsrs, doc(cfg(feature = "std"))] it. If someone wants to submit software-implemented log2 I'll be happy to ACK.

This has nothing to do with ARM, logarithm just isn't in core, it needs std.

Ah, makes sense.

I suggest we just #[cfg(feature = "std")] #[cfg_attr(docsrs, doc(cfg(feature = "std"))] it.

Done.

Will ACK when you squash the commits. :)

Will ACK when you squash the commits. :)

And done!

Nice one man, I started to investigate writing a "software implementation" of this the other week and couldn't do it :)


New extension buyer consent capability

WHY are these changes introduced?
Resolves: https://github.com/Shopify/checkout-web/issues/25433
This PR relates to the SMS Consent project being worked on in Checkout Extensibility.
WHAT is this pull request doing?

Adds a new extension capability called collect_buyer_consent with it's own sub-capability/policy for sms_marketing.

Note that email_marketing will be added in the future.

Updates capability types to accept recursive typing for nested capabilities (new concept for this PR)
Updates tests which confirms the following configuration works as expected

[extesnions.capabilities.collect_buyer_consent]
sms_marketing = true

and legacy config
[capabilities.collect_buyer_consent]
sms_marketing = true

How to test your changes?
Post-release steps

Measuring impact
How do we know this change was effective? Please choose one:

[ ] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[ ] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[ ] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[ ] I've considered possible documentation changes
[ ] I've made sure that any changes to dev or deploy have been reflected in the internal flowchart.

/shipit


build: fix mypy (local and CI)

Needs a new release of midea_local (> 1.1.0) before merge

Create https://github.com/rokam/midea-local/pull/179 to add set_target_temperature for MideaFBDevice so to use float

Needs midea_local v1.1.2

Hello, I made some commits for above conversations. Feel free to modify or drop them if you have different opinions

I would rephrase the error and fix the return of the function as we saw it should never be none


🍾 launch blog post of bootstrapping phase

[x] create draft
[x] release on substack once token page is ready

published: https://0xhabitat.substack.com/p/the-habitat-token-is-live-


Feature Request: Set min value of slider

Hi,
can you implement an attribute for setting slider min value so that the slider starts for example at 23 instead of 0?
Thanks in advance!

Hi @WebTiger89 ,
I think maybe you can use ValueLabelFormatter to customize begin value with offset?
For example:
mSlider.setValueLabelFormatter(new DiscreteSlider.ValueLabelFormatter() {

    @Override
    public String getLabel(int input) {
        return Integer.toString(input + 23);
    }
});

Thanks for the reply.
I already thought about this solution but then I have to convert the numbers internally (0 is 23, 23 is 46) which is not a problem. It would be cool to have this feature out of the box but consider that the SeekBar widget from android don't have such a feature so its up to you if you will implement this. It would be just a nice to have :)

@WebTiger89
I can implement this, but i'm busy this month.
Maybe you can create PR, I'll review it & merge it 👍

@WebTiger89 I've released new version 1.2.0, you can try now!


Change some translations.

@DRvanR :exclamation: :exclamation: :exclamation:

yeah yeah, just merge it already :tongue:


feat: Add Input and InputSearch components

https://github.com/user-attachments/assets/ae371daf-bc26-46a7-8c9b-e1b96b0f82da
AI Description

This PR updates the version of react-hook-form to ^7.52.1 and introduces a new InputSearch component.

The react-hook-form package is updated to version ^7.52.1 in package.json and package-lock.json.
The InputSearch component is added to the src/interfaces/assistants_web/src/components/Shared/InputSearch/InputSearch.tsx file.
The InputSearch component is imported and used in multiple files: src/interfaces/assistants_web/src/app/test/page.tsx, src/interfaces/assistants_web/src/components/Agents/AgentsList.tsx, src/interfaces/assistants_web/src/components/Agents/DiscoverAgents.tsx, src/interfaces/assistants_web/src/components/ConversationList/ConversationListPanel.tsx, and src/interfaces/assistants_web/src/components/Shared/InputSearch/index.ts.
The Input component in src/interfaces/assistants_web/src/components/Shared/Input/Input.tsx is updated to include a new actionType option, 'reveal', and the disabled` prop is removed.
The kind and theme props are removed from the Input component in src/interfaces/assistants_web/src/components/Shared/Dropdown/Dropdown.tsx.
The hasError prop is removed from the Input component in src/interfaces/assistants_web/src/components/AgentForm.tsx.
The stackPosition and errorText props are removed from the Input component in src/interfaces/assistants_web/src/app/(auth)/login/Login.tsx and src/interfaces/assistants_web/src/app/(auth)/register/Register.tsx.
The actionType prop is updated from 'revealable' to 'reveal' in src/interfaces/assistants_web/src/app/(auth)/login/Login.tsx and src/interfaces/assistants_web/src/app/(auth)/register/Register.tsx.
The color value 100 is updated from '#292929' to '#1A1A1A' in src/interfaces/assistants_web/src/themes/cohereTheme.js.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.72%. Comparing base (4edacee) to head (686e0ad).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #478      +/-   ##
==========================================
+ Coverage   81.38%   81.72%   +0.33%
==========================================
  Files         199      199
  Lines        8354     8381      +27
==========================================
+ Hits         6799     6849      +50
+ Misses       1555     1532      -23

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Stuck on sending Message

(async () => {
    const instance = new Client(process.env.TOKEN, {
      showSteps: true,
    });

    const client = await instance.init();

    await client.sendMessage(
      {
        message: "Hello world",
      },
      (response) => {
        console.log(response);
      },
    );
  })();

output
Downloading Settings...
Waiting for Clients
Downloading next_data...
Subscribing...
WebSocket Connecting...
WebSocket connected!
Sending message...

Me too brother. I am using Glitch and you?

My PR resolved this: https://github.com/mmdzov/poe-chat-api/pull/2/files

The changes were merged


Flutter compass error appears i try to build release apk.

What went wrong:
Execution failed for task ':flutter_compass:verifyReleaseResources'.

A failure occurred while executing com.android.build.gradle.tasks.VerifyLibraryResourcesTask$Action
Android resource linking failed
ERROR: D:\projects\building-materials\build\flutter_compass\intermediates\merged_res\release\values\values.xml:194: AAPT: error: resource android:attr/lStar not found.

this error occurs when i run flutter build apk command but it builds debug apk. can you help me resolve the problem?

@Michael-M-aher  pls

@Michael-M-aher  please fix it

Hello,
Thank you for reaching out. Based on the error you're encountering, it's not specific to the location_picker_flutter_map package. The error occurs due to a mismatch in the SDK versions or the Android Gradle Plugin (mostly SDK 34), which can happen when a package is using resources or attributes that are not available in the SDK version you're currently targeting.
allprojects {
  repositories {
    google()
    mavenCentral()
  }
}

rootProject.buildDir = "../build"

subprojects {
  afterEvaluate { project ->
    if (project.plugins.hasPlugin("com.android.application") ||
        project.plugins.hasPlugin("com.android.library")) {
      project.android {
        compileSdkVersion 34
        buildToolsVersion "34.0.0"
      }
    }
  }
  project.buildDir = "${rootProject.buildDir}/${project.name}"
  project.evaluationDependsOn(":app")
}

tasks.register("clean", Delete) {
  delete rootProject.buildDir
}

Steps:

Add this snippet to your android/build.gradle.
Run flutter clean and then flutter build apk --release.

This should fix the android:attr/lStar error during the release build. Let me know if you need further help!


Add option to disable access logging

For an internally-facing and/or test/qa deployment, web access logs may
be a waste of stackdriver/cloudwatch quota. :)

Pull Request Test Coverage Report for Build 365

6 of 8 (75.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 37.942%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

handlers/handlers.go
6
8
75.0%

Totals

Change from base Build 364:
0.1%

Covered Lines:
461

Relevant Lines:
1215

💛  - Coveralls

LGTM, thanks!


Orgs using D: add eBay

Wohoo we finally got the legal permission to list eBay :tada:
CC @jondegenhardt, thanks again for your hard work. Please check if everything is correct ;-)
@CyberShadow we only have the permission for this explicit use, hence I didn't include a HQ version of the eBay logo. I still have a higher quality version from the contract, which we can use if we want to support monitors with a higher resolution.
Disclaimer @ mac users: I don't have a Retina display, so don't expect such a PR soon.

Disclaimer @ mac users: I don't have a Retina display, so don't expect such a PR soon.

Just set your browser zoom to 200%?

LGTM


Is it possible to add the includeMetadataChanges parameter?

Im using it, but need to change the includeMetadataChanges parameter to true. Is it possible?

It is now added in version 1.0.3. Thanks for using the package @evandrobubiak 🎉


Make hash functions generic

This PR makes the use of hash function (both inner and outer) generic to support user-specific usecases, and make transitions smoother in case a hash function with different parameters (width, rate) is aimed at being used in the future.
The API gets a bit more verbose, but as discussed with @wborgeaud it seems that until const_generic_exprs gets more stable, there's no better apparent solution.
EDIT: The move to crates.io messed up the CI when fully rebasing because of the breaking changes, so I added a patch section to the workspace config file. I assume this may come in handy in the future for other breaking changes in between releases.

Rebasing with latest main changes also allowed to reduce the new added verbosity on some parts of the code by quite a lot.

This LGTM, especially with the recent changes, thanks Robin! I might tweak a few things but I'll just do so after merging, to avoid holding this up any longer.


computeKey in condition?

How would I go about for creating a condition for a computeKey?
...SubEntity
schema: schema({
  subId: string()
    .key()
    .default(() => ulid()),
  bucketId: string().key(),
  amount: number()
}),
computeKey: (data) => ({
    pk: `BUCKET#${data.bucketId}`,
    sk: `SUB#${data.subId}`,
  }),

I want to create a conditional-check that pk exists but sk does not...
await SubEntity.build(PutItemCommand)
    .item(subItem)
    .options({
      condition: {
        and: [
          { attr: 'pk', exists: true }, // not allowed to specify pk
          { attr: 'sk', exists: false }, // not allowed to specify sk
        ],
      },
    })
    .send();

I get ts-errors since the pk/sk does not exist on the entity (but it does in ddb). And when trying anyway (example above) I get this error: Unable to match expression attribute path with schema: pk... help!

Hi @Crafoord 👋
Short answer is you cannot. computeKey operates outside of the schema, and the schema is the center of every validation, including conditions.
What you can do however is use links instead of computeKey:
schema: schema({
  subId: string()
    .key()
    .default(() => ulid()),
  bucketId: string().key(),
  amount: number()
}).and(prevSchema => ({
  pk: string()
    .key()
    .hidden()
    .link<typeof prevSchema>(({ bucketId }) => bucketId)
    .transform(prefix("BUCKET")),
  sk: string()
    .key()
    .hidden()
    .link<typeof prevSchema>(({ subId }) => subId)
    .transform(prefix("SUB")),
}),
computeKey: undefined // not needed anymore

@Crafoord Actually you don't even need links if you save subId and bucketId as pk and sk instead:
schema: schema({
  bucketId: string()
    .key()
    .savedAs('pk')
    .transform(prefix('BUCKET')),
  subId: string()
    .key()
    .default(ulid)
    .savedAs('sk')
    .transform(prefix('SUB'))
})

This way you can just use subId and bucketId in your conditions and they will be mapped to pk and sk!

Thanks @ThomasAribart! It worked great (but did not solve my logic issue) with link but then I realized that for my use-case I need to use a transaction for it to work properly.
Then I figured i could roll-back to using computeKey!
Transaction:

Condition (BucketEntity exists with bucketId)
Put (SubEntity with condition that subId does not exist).

Thanks again for such quick responses/ideas ⭐

Awesome! Closing this issue then!


HTML structure

Description
HTML structure is highly messed up no closing tag no formatting , no semantics lot of redundant tags
Screenshots
No response

i am opening a request fixing the closing tags issue

@SauravMukherjee44 any updates on this?


What happens in test time?

NSM only use question-answer pair to train.
And in test time, NSM generate the SQL logic form.
Am I right?

NSM generates a program that produces the answer. See supplementary A for more details about the program.

Thank you! Best wishes.


[okina] Hold off on okinafying the densemat mult method [artv3/okina-densemat-mult]

Regarding issue #761 , I think we can maintain interoperability with the ComputeL2Error grid function method (on the CPU) by holding off on okinafying the densemat mult method. Certain allocations of memory are not being managed by the okina memory manager and this causes issues when the densemat mult method is called inside the  ComputeL2Error method.
A temporary solution could be to keep dense matrix multiplication on the CPU until the ComputeL2Error grid function method gets reworked.

As mentioned in #768, switching back to host for the mass CG solves the issue.


[ADAM-1451] Make VariantContextConverter class and convert methods public

Resolves #1451.

Coverage decreased (-0.09%) to 80.504% when pulling ce893c8e2f83ee2287a97e9992f4a806375786cd on fnothaft:issues/1451-vcc-public into fd0cb6e372f7cf98d5259e18aeb235b71b525e17 on bigdatagenomics:master.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1902/
Test PASSed.

Thank you @fnothaft @tverbeiren!


Issue in Quantizer decoeder_model_merged.onnx of MT5

System Info
optimum 1.16.2
onnx 1.15.0
onnxruntime 1.17.0

Who can help?
No response
Information

[ ] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction (minimal, reproducible, runnable)
I got onnx files of mt5-large model and when I tried to convert that to quantized files, I got errors at decoder_model_merged.onnx.
from optimum.onnxruntime.configuration import AutoQuantizationConfig
from optimum.onnxruntime import ORTQuantizer
qconfig = AutoQuantizationConfig.arm64(is_static=False, per_channel=False)
quantizer = ORTQuantizer.from_pretrained("/content/drive/MyDrive/mt5-large", file_name="decoder_model_merged.onnx")
quantizer.quantize(save_dir="/content/drive/MyDrive/mt5-large", quantization_config=qconfig)

Expected behavior
decoder_model_merged_quantized.onnx

Hi @jhpassion0621 this is a bug introduced in onnxruntime 1.17, please downgrade to onnxruntime 1.16 to wait for a fix to be released: https://github.com/microsoft/onnxruntime/pull/19421

Thank you very much. it works well on 1.16. @fxmarty


Test and lint workflow

Addresses Issue #25.

I am going to leave this broad workflows being trigger for now and put an issue so this doesn't get left out. Thank you, Joe, for reviewing!


NYC DC Network problem

Plataforma offline... Esperando información del DC

We're investigating an outage in NYC.
This appears to be a connectivity issue related to routing. We are communicating with the datacenter to resolve the issue.

Fixed


15.3 Insert Interval Time Limit Exceeded

Hi, I gotta to run your solution on github.
However, I got a TLE when submit to online judge.
The corresponding testcase is something like
[[1,2],[3,4],[5,6],[7,8],[9,10],[11,12],[13,14],[15,16],[17,18] ... [19999,20000]], [0,20001]]
It cause multiple erase which make your algorithm in worst case O(n^2).
A O(n) time, O(n) space solution that use extra memory to save the result can basically pass the oj.

Just found out dupe with #51, sorry about that.


getkeypool should return both receive and change chain

https://github.com/bitcoin-core/HWI/pull/135


Finishing migration to SupportSQLite

fixes #702

Unfortunately the migration is a lot more detailed than this. There's fundamental changes like the use of Object[] instead of String[] for arguments that we need to address in the generated code.


Adding Ethereum dev resources

I want to work on this @debrajhyper. Please assign this to me

You are all good to go.

Submitted PR.


fix(link): toggle target icon

Allow the toggle of the target icon.

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Split urls.py file

Split the urls.py file into categories to avoid merge conflicts in the future.

lgtm


Invalid rendering of form-append/prepend icons

I found an error of rendering form-append/prepend icons in version 2.0.
This happens because function (FormButton.php, line 351):
$sIconContent = $this->htmlElement('i', ['class' => $aIconOptions['class']]);
returns unclosed <i> tag and it brokes all markup.
Trait HtmlTrait.php returns unclosed tag because it has empty content:
$sElementContent = '<' . $sTag . $sAttributes;
if ($sContent === null) {
    $sElementContent .= $this->getView()->plugin('HtmlTag')->getClosingBracket();
    return $sElementContent;
}

Fixed in version v2.0.1

Thanks for fast response :)
I didn’t make my PR, because I see that you started to actively develop this package again.


Unable to use this addon with Storybook v5

Hi, I'm trying to use this addon with Storybook v5, but there's an error loading the styles, when running start-storybook.
ModuleParseError: Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
> .versions-panel-container {
|   width: 100%;
|   font-family: -apple-system, ".SFNSText-Regular", "San Francisco",
    at handleParseError (/Users/daniel/Dev/dimebox/storybook-test/node_modules/webpack/lib/NormalModule.js:448:19)
    at doBuild.err (/Users/daniel/Dev/dimebox/storybook-test/node_modules/webpack/lib/NormalModule.js:482:5)
    at runLoaders (/Users/daniel/Dev/dimebox/storybook-test/node_modules/webpack/lib/NormalModule.js:343:12)
    at /Users/daniel/Dev/dimebox/storybook-test/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/Users/daniel/Dev/dimebox/storybook-test/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at Array.<anonymous> (/Users/daniel/Dev/dimebox/storybook-test/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/Users/daniel/Dev/dimebox/storybook-test/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
    at provider (/Users/daniel/Dev/dimebox/storybook-test/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9)
    at /Users/daniel/Dev/dimebox/storybook-test/node_modules/graceful-fs/graceful-fs.js:90:16
    at FSReqWrap.readFileAfterClose [as oncomplete] (internal/fs/read_file_context.js:53:3)

It appears this repo is no longer maintained, I've forked it and got a working version with SB 4 (should work fine with 5 too), have a look if you want over at my github.

https://github.com/panosvoudouris/storybook-addon-versions
for the lazier-than-me


runtime: unexpected return pc for runtime.goexit called

What version of Go are you using (go version)?
go version devel +94d7c884c3 Thu Dec 14 14:57:01 2017 +0000 darwin/amd64

Does this issue reproduce with the latest release?
YES
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/qipeng/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/qipeng/workspace/go"
GORACE=""
GOROOT="/Users/qipeng/program/go"
GOTMPDIR=""
GOTOOLDIR="/Users/qipeng/program/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bs/9120vpt14jd7rkhg27kdbj480000gn/T/go-build502747584=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Call http.Get in plugin.
Like:
plugin.go
func Init() {
	res, err := http.Get("https://www.google.com")
	if err != nil {
		fmt.Println("Init Error:", err)
	}
	res.Body.Close()
}

main.go
	p, err := plugin.Open("post.so")
	if err != nil {
		panic(err)
	}
	add, err := p.Lookup("Init")
	if err != nil {
		panic(err)
	}
	add.(func())()

DEMO
What did you expect to see?
 The traces are different though, and this is involving plugins.
/cc @aclements @ianlancetaylor

This seems to work for me on GNU/Linux.
It's weird that the number 0x5466c00 appears both in the error message and in the call to net/http.(*Transport).getConn on goroutine 1.  That makes it seem that the traceback is messed up somehow.

CC @crawshaw

This issue still happens in 1.10. and Go 1.10 release notes says that it supports plugin build on Darwin.

It does look like there is something strange going on.  When I add this line to goroutine creation:
	println("newg goexit", hex(goexitPC), hex(funcPC(goexit)))

Most of the time, it prints:
newg goexit 0x404da50 0x404da50

But sometimes, it prints:
newg goexit 0x404da50 0x704d6e0

Those two values should always be the same (startup does goexitPC = funcPC(goexit), and they are never subsequently modified), but they aren't.
The first value printed is correct, it is the address of the goexit function in the main binary.  The second value, when wrong, is the address of the goexit function in the plugin.  Which is extra weird, because it's not just 2 copies of the runtime.  Instead, a single line of code is using a global variable from one runtime (goexitPC) and a static closure from another (goexit refers to the runtime.goexit.f symbol).
On Darwin, I see the following symbols:
$ go tool nm main | grep -w goexit
 404da50 T runtime.goexit
 407db18 R runtime.goexit.f
$ go tool nm plugin.so | grep -w goexit
   4d6e0 T runtime.goexit
   eb9b8 D runtime.goexit.f

On Linux, there's something different:
$ go tool nm main | grep -w goexit
  4823a0 t local.runtime.goexit
  4823a0 T runtime.goexit
  4b35c0 R runtime.goexit·f
$ go tool nm plugin.so | grep -w goexit
  126cb0 t local.runtime.goexit
  126cb0 T runtime.goexit
  3e7b28 D runtime.goexit·f

I'm not sure if that's relevant.
@crawshaw @ianlancetaylor , any ideas?

I'm not familiar with how dynamic linking works on MacOS.  But this looks like the failing code is running inside the plugin.  It's essential for correctness that the main executable and a shared library agree on the location of a global variable.  So it's not surprising that the plugin gets the value of goexitPC correct.  It's much less essential for the main executable and a shared library to agree on the address of a function.  For a function it's important that all calls go to the same place, and in shared libraries that is normally done by having the shared library use a Procedure Linkage Table to branch to the function in the main executable if it is defined there, and to use the copy in the shared library if it is not.  But that is only calls, not addresses.  ELF dynamic linkers go to considerable effort to ensure that equality comparisons of functions in executables and shared libraries resolve as is required by C.  It's possible that the Darwin dynamic linker does not.  In that case, the reference to the function in the plugin may be retrieving the address of the PLT entry, not the address of the function in the main executable.  In particular funcPC is going to pull apart the goexit.f value to fetch the PC.
If my guess is correct then the simple fix is to introduce a package scope variable initialized to funcPC(goexit) and use that instead of calling funcPC(goexit) each time.  The main executable will set the value to the address in the main executable, and the reference in the shared library will reliably retrieve that value from the main executable.  Since the shared library PLT stub should always branch to the main executable version, the global variable should match what is on the stack.

If my guess is correct then the simple fix is to introduce a package scope variable initialized to funcPC(goexit) and use that instead of calling funcPC(goexit) each time.

That was the fix I was thinking of, but I was worried that there might be a larger issue that this was just the tip of the iceberg for.  But maybe you're right, the only issue is function address equality, and as long as we don't rely on that across packages, it's ok if the plugin and main program are using two different runtimes with identical contents.  As long as all the mutable global variables are shared.
goexitPC is already that package scope variable you describe.  We just have to use that instead of funcPC(goexit) everywhere.  And audit all other uses of funcPC.

Audit of uses of funcPC:

funcPC results passed to race detector. Those should all be ok, they will just be used to map back to function names.
funcPC results passed to routines that call the result.  pthread_create, bsdthread_create, asmcgocall, sigaction, sysvicall0, stdcallX, onosstack, setsig.  Also ok, as it doesn't matter which copy of the funcPCd function we call.
funcPC results used for profile samples.  This may end up with attributing those samples to multiple routines of the same name, but that's going to happen anyway.
funcPC results used for various traceback special cases.  These are not fine.  It turns out that the goexit one is easy to fix, because we write the pc explicitly.  Lots of others, though, the pc is written implicitly as part of a call.  If there are multiple instances of, say, the function jmpdefer, then comparing the pc against a single value obtained with funcPC(jmpdefer) will miss one of those instances.   Some of these are never called directly, only by function pointer, for example sigpanic.  For those we could always use a single cached version of funcPC(sigpanic) everywhere, so we always call a particular version.  For others like mcall, though, we don't control which version is called.  We could call all such functions indirectly instead, but that gets ugly quickly.

Long story short, the goexit fix is easy, but there are other bugs lurking here.  I think we really need to fix whatever is different about the linking to make sure we use only a single copy of the runtime's functions.

I don't see any particular problem with jmpdefer.  The only comparison there is comparing it against f.entry.  f.entry is going to come from the symbol table.  The value in the symbol table ought to be correct in all cases.  If it is not, we should clearly fix that.
The problem with goexit is different.  The value is set in newproc1 with a call funcPC(goexit).  Calls to funcPC can, I think, return different values in different shared modules on Darwin.  Calls to f.entry ought to return the same value in all cases.  Similarly, the actual PC value on the stack ought to be the same in all cases; actually calling the function in the plugin should call a stub that jumps to the code in the main executable.  The only problematic case (and, I think, only problematic on Darwin, not GNU/Linux) is calling funcPC in the plugin.

Or to put it another way, in effect only a single copy of the runtime functions will ever be used, with one exception: explicit calls to funcPC.

I don't think that last statement is correct.  We are clearly using two copies of runtime.newproc1, at least.  If I add the line
println(hex(funcPC(goexit)), hex(getcallerpc()))

to runtime.newproc1, I get output lines like this:
0x404df50 0x404b6f6
0x404df50 0x404b6f6
0x704d6e0 0x704b206
0x704d6e0 0x704b206

Sometimes it is the main executable's runtime.newproc1, in which case it gets the address of the main executable's goexit.  Other times, it's the plugin's runtime.newproc1, in which case it gets the address of the plugin's goexit.  I don't think trampolines are in play here; we really are executing whole functions out of the plugin's copy of the runtime (0x704b206 is the address following the call to newproc1 in the anonymous function declared in newproc).
0x704d6e0 is the address of the goexit code in the plugin.  It isn't the address of a trampoline or PLT/GOT entry or whatever.
Which means that the actual PC of runtime functions on the stack won't be the same in plugin vs main instances.  And I suspect, but haven't confirmed, that we get separate symtab entries with different .entry fields when we use those different PCs (the PC is the key, and symtab entries cover a contiguous range of pcs, how could it be otherwise?).

Thanks for checking.  I clearly do not understand how shared libraries work on Darwin.

I'll reopen.  Part of this issue has been fixed, but not all of it.

@randall77 Thanks.

Sorry about that. Moved to 1.10.2 milestone as well.

@gopherbot please open a 1.10 tracking issue.

I have confirmed that this issue has been resolved on GO 1.11 beta

Thanks.

@FiloSottile @ianlancetaylor @andybons, @randall77's first CL 100739 was already backported to Go1.10 with CL 102793 but @randall77 reopened this issue in https://github.com/golang/go/issues/23133#issuecomment-377415066 mentioning that his CL fixed a part of this issue. How do we proceed with closing the requested backport issue https://github.com/golang/go/issues/25038?

I think the other half is CL https://go-review.googlesource.com/c/go/+/104715. So CL https://go-review.googlesource.com/c/go/+/122116 will do.

Cool, thanks for finding and reporting that @cherrymui! I don't think we should tamper with editing that backport message in CL 122116, to state that it finishes up this one, so perhaps this conversation in here suffices.


Check binding annotations in resource variables

Fixes #2007

The smoketest has a ton of failures. They look like cases of compilers not annotating descriptor set or binding as appropriate.


For Issue#132, correct the erroneous instructions and...

#132
(re?)add the /library_ksm folder containing a cautionary README.

The language that you corrected in library_ksm/README.md looks good.  Since I had simply copied this language from the existing HOWTO.md, it needed to receive the same change, so I think I've fixed that now too.
However, I am new to Git, coming from Subversion, and I wasn't sure how to add a change to the pull request.  I googled how to do it, and things didn't go quite how I think they're supposed to.  Did that change make it back to you?


Proposal: mandate unit for all measurement fields

currently MIxS allows any appropriate units to be allowed, using a {float} {unit} syntax, for example:
Environmental package: water
Structured comment name: water_current
        Package item: water current
          Definition: Measurement of magnitude and direction of flow within a fluid
      Expected value: measurement value
        Value syntax: {float} {unit}
             Example: 10 cubic meter per second
         Requirement: X
      Preferred unit: "cubic meter per second, knots"

This has the advantage of allowing people to use whatever units are appropriate, either for the scale they are interested in, for the local context (e.g. imperial vs metric), or simply to measure the direct output of the device. It also saves time and simplifies data entry.
However, it has disadvantages for users of the data, in that they will need to normalize to do comparisons. Of course, this could happen anywhere along the chain, from the submission tool to database or API/downloads. It also introduces potential for error as there are different standards for units, different ways to write them, and potential to accidentally use an inappropriate unit (e.g. "meters" for area), as well as the usual issues that come with string parsing.
Many of the other schemas in use such as NEON, SESAR, etc all bake in the unit into the field. I think there is a danger in implicit baking in to the field (e.g. having depth with range float, and some easily detached documentation stating that this is to be interpreted as meters). But I think explicit baking into the field, e.g. depth_in_meters is acceptable.
I am not necessarily in favor of this proposal, but I have heard voices in favor, and I would like to adhere to MIxS precisely, so it would help to have justification for the current way of doing this. Is there any documentation on why MIxS chose to do it the current way?

Hello Chris,
The decision to have the units in a separate field was early on, some
15 years ago, to enable parsing of the two separate fields and to enable
options in the units. Also, only some terms have units. Look at our
early papers for details. Subsequently, the parsing and QC validation at
INSDC follows this format. Changing the format at this time would break all
MIxS parsers/software.
Cheers,
Lynn
On Thu, Jun 18, 2020 at 5:52 PM Chris Mungall<EMAIL_ADDRESS>wrote:

currently MIxS allows any appropriate units to be allowed, using a {float}
{unit} syntax, for example:
Environmental package: water
Structured comment name: water_current
Package item: water current
Definition: Measurement of magnitude and direction of flow within a fluid
Expected value: measurement value
Value syntax: {float} {unit}
Example: 10 cubic meter per second
Requirement: X
Preferred unit: "cubic meter per second, knots"
This has the advantage of allowing people to use whatever units are
appropriate, either for the scale they are interested in, for the local
context (e.g. imperial vs metric), or simply to measure the direct output
of the device. It also saves time and simplifies data entry.
However, it has disadvantages for users of the data, in that they will
need to normalize to do comparisons. Of course, this could happen anywhere
along the chain, from the submission tool to database or API/downloads. It
also introduces potential for error as there are different standards for
units, different ways to write them, and potential to accidentally use an
inappropriate unit (e.g. "meters" for area), as well as the usual issues
that come with string parsing.
Many of the other schemas in use such as NEON, SESAR, etc all bake in the
unit into the field. I think there is a danger in implicit baking in to
the field (e.g. having depth with range float, and some easily detached
documentation stating that this is to be interpreted as meters). But I
think explicit baking into the field, e.g. depth_in_meters is
acceptable.
I am not necessarily in favor of this proposal, but I have heard voices in
favor, and I would like to adhere to MIxS precisely, so it would help to
have justification for the current way of doing this. Is there any
documentation on why MIxS chose to do it the current way?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GenomicsStandardsConsortium/mixs/issues/56, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBB4DJ52HSXJBXXY7F5DODRXKEBRANCNFSM4OCFWXSQ
.

--
Lynn M. Schriml, Ph.D.
Associate Professor
Institute for Genome Sciences
University of Maryland School of Medicine
Department of Epidemiology and Public Health
670 W. Baltimore St., HSFIII, Room 3061
Baltimore, MD 21201
P:<PHONE_NUMBER> |  F:<PHONE_NUMBER>
<EMAIL_ADDRESS>


b30 & b31 nothing but respring loop then reboot..(wasted 25mins)

as title ios 12.1 SE, jailbreaking goes as normal, then once jailbroken, respringing then reboots..constantly, as in jailbreaks but dont even load lockscreen...everythings fine on b29, which is fantastic & actually works for me, as i expect...uptime is sooo long, i almost forgot what a loop or random reboot was..until now lol reimpacted b29, jailbroke, resprung for like 2seconds, lockscreen appears.. ill stay on this beta for now xD

Try disabling the Restart System Deamon

Tyvm 👍


Errors when launching  ags

Describe the bug
(com.github.Aylur.ags:96164): Gjs-Console-CRITICAL **: 04:10:51.035: GLib.SpawnError: Failed to execute child process “bun” (No such file or directory)
proc@resource:///com/github/Aylur/ags/utils/exec.js:11:27
execAsync@resource:///com/github/Aylur/ags/utils/exec.js:77:19
@file:///home/luri/.config/ags/config.js:15:25
_init/GLib.MainLoop.prototype.runAsync/</<@resource:///org/gnome/gjs/modules/core/overrides/GLib.js:263:34

To Reproduce
Install packages with pacman & aur. Clone the repo and move to your config folder. Launch ags.
 Forgot to install bun!

 Forgot to install bun!

i've got the same issue despite the fact i got bun installed, bit stuck