add taxon constraints on apoptosis

Currently:
relationship: never_in_taxon NCBITaxon:33090 {id="GOTAX:0000490"} ! Viridiplantae

That's it, including inherited. So it's valid to annotate E coli with apoptosis in GO.
I suggest Opisthokontes conservatively

Hi Chris,
Yes, restricting ‘apoptotic process’ to Opisthokonta (Fungi/Metazoa group - Taxonomy ID: 33154) sounds like a good idea.
If that’s ok with you, I’ll keep this edit for next week when Melanie is on her first GH/TG rotation, so I can show her an example of taxon rule edit - and one best done with OBO-Edit at the moment ;-)
Note that while the use of ‘apoptosis’ is indeed discouraged in bacteria (http://www.sciencedirect.com/science/article/pii/S1286457913001044), there is growing evidence of programmed cell death events in prokaryotes (http://www.nature.com/nrmicro/journal/v12/n1/full/nrmicro3136.html). But we’re good - ‘programmed cell death’ doesn’t have any taxon restriction.
Paola

Edited taxon rule for GO:0006915 'apoptotic process' as follows:
-relationship: never_in_taxon NCBITaxon:33090 {id="GOTAX:0000490"} ! Viridiplantae
+relationship: only_in_taxon NCBITaxon:33154 ! Opisthokonta
Thanks,
Paola


Max output length: Maximum number of new tokens in LLM response in CLI Parameter?

Hi as title suggest could you please share the parameter for Max output length in CLI.

python generate.py --base_model=llama --max_new_tokens=1024

would limit to 1024 new tokens in output.


Please add LICENSE, license headers to code, contribution guidelines and code of conduct

Hey, Fil from Adobe's Open Source Office here.
Before open sourcing it is important to ensure you have legal bits in place like a license, code has source code headers that are compatible with your chosen license, contribution guidelines that make clear to external contributors the need to sign a CLA, and our Adobe Legal-approved code of conduct.
You can copy these files from github.com/adobe/starter-repo.
If the above is confusing or you have more questions, we highly recommend you fill out the form at opensource.corp.adobe.com, where members from the Open Source Office can help set you up with all of that and make sure to do the requisite checks.

Added License, Contribution guidelines and Code of Conduct.
License headers to code will be added as they are added in repo.


Add SBT in cache managers.

Description:
Describe your changes.
Add SBT cache manager.
Related issue:
Add link to the related issue.
https://github.com/actions/setup-java/issues/266#issuecomment-1077368457
Check list:

[x] Mark if documentation changes are required.
[ ] Mark if tests were added or updated to cover the changes.

Hello @fmeriaux. Could you please sync with the main branch?

Hello @fmeriaux. Could you please sync with the main branch?

Done

Hello @fmeriaux. Could you please add e2e tests for sbt ?

e2e

Yes, no problem, but can you detail a little more what I have to do?

Hello @fmeriaux. Could you please add e2e tests for sbt ?

Yes, no problem, but can you detail a little more what I have to do?

I think it should be something similar to Gradle test.

Hello @fmeriaux. Could you please add e2e tests for sbt ?

Yes, no problem, but can you detail a little more what I have to do?

I think it should be something similar to Gradle test.

Thanks, done !

I am so sick of receiving Github emails from Subscribers 6 a day? How can I
be attached to the thread when I unsubscribed after 5 days last year?
Please delete my email
@.*** @.**>
Donna Murdoch
On Tue, 12 Apr 2022, 4:50 pm Florian Meriaux, @.***>
wrote:

Hello @fmeriaux https://github.com/fmeriaux. Could you please add e2e
tests for sbt ?
Yes, no problem, but can you detail a little more what I have to do?
I think it should be something similar to Gradle
https://github.com/actions/setup-java/blob/main/.github/workflows/e2e-cache.yml#L18-L66
test.
Thanks, done !
—
Reply to this email directly, view it on GitHub
https://github.com/actions/setup-java/pull/302#issuecomment-1096186153,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVVEBHXVXZIALDGTVVEZIOTVEUMJXANCNFSM5RQPPSSQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Failing to record a perfetto-trace seems due to perfetto's crash

Hi, recently I failed to record a perfetto-trace on on one of my phone.
The trace's size should be over 100MB, but the fact is that it takes over just 2271 bytes.
It's so small that it records nothing.

 Stalling
12-12 18:14:58.303  9999 24993 24993 F DEBUG   : [842.702] ory_arbiter_impl.cc:167 Recovered from stall after 13 iterations
12-12 18:14:58.303  9999 24993 24993 F DEBUG   : [845.020] ory_arbiter_impl.cc:192 Shared memory buffer overrun! Stalling
12-12 18:14:58.303  9999 24993 24993 F DEBUG   : [846.868] ory_arbiter_impl.cc:167 Recovered from stall after 47 iterations
12-12 18:14:58.303  9999 24993 24993 F DEBUG   : [850.106] ory_arbiter_impl.cc:192 Shared memory buffer overrun! Stalling
12-12 18:14:58.303  9999 24993 24993 F DEBUG   : [850.250] ory_arbiter_impl.cc:167 Recovered from stall after 13 iterations
12-12 18:14:58.303  9999 24993 24993 F DEBUG   : [855.205] ory_arbiter_impl.cc:192 Shared memory buffer overrun!
Can anyone give me some advice on it?
Thanks First!

Is this a very low end device? If so our stalling might be a bit too aggressive there. The only real "fix" (without modifying the OS) is to increase the [shared memory buffer size] (https://cs.android.com/android/platform/superproject/+/master:external/perfetto/protos/perfetto/config/perfetto_config.proto;l=2634?q=buffer_size_kb f:Perfetto)
Another reason is that uour config might also be trying to collect too much data: you might want to trim that down.
If you have control over the system image, you could also make traced_probes run at a higher priority or on a "big" CPU.


Messaging:  Invitation message for establishing connection

Represent an invitation message for establishing connection
Represent connection request message.
Represent connection response message.

Reference : https://github.com/hyperledger/aries-cloudagent-python/tree/master/aries_cloudagent/messaging/connections/messages

RFC spec: https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange

Not required

Not required


rm-element.py

Added a solution for LeetCode's 'Remove Element' problem

Your commit message is not descriptive enough. Please take a look at the assignment for example and amend your commit by EOD Wednesday October 2nd if you want full credit for the assignment.

Added a solution for LeetCode's 'Remove Element' problem

Implemented a Python solution to remove all instances of a specified value from an array.
Used a while loop to iterate through the array and remove the specified value.
Tested the solution with a sample input nums = [3, 2, 2, 3] and val = 3, resulting in getting Test Passed

@ssjaryan so you have added a comment to this PR describing what you did, but you need to add it to the commit otherwise it won't show up in the commit history. Right now your commit messages are just rm-element.py and update rm-element.py.
Additionally, please squash your commits so you only have one commit with your changes and commit message. You can google how to do that.


arm: ARMv6-M vector table offset register support

Summary
Add ARMv6-M arch optional vector table offset register support.
Impact
No impact because the existing Cortex-M0 ports don't use this feature.
Testing
Tested by upcoming Raspberry Pi Pico port.

Sup?
On Friday, February 19, 2021, 08:24:32 PM MST, Xiang Xiao<EMAIL_ADDRESS>wrote:
Merged #2876 into master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


parser: prevent JSX expressions using comma operator

If I have interpreted the TODO correctly, then something like:
const Component = ({ foo }) => <div>{foo}</div>;
const foo = <Component foo={<div />,<div />} />;

is not valid JSX.
This PR checks whether the parsed expression in a JSX assignment is an Expression::SequenceExpression, and errors if so.

 I'm not sure if there's any tests for this.

 I'm not sure if there's any tests for this.

I tried but I don't think I've cloned the repo properly, the test directories are empty (I tried git submodule update --recursive but nothing happened), and hence the coverage is 0% across everything 😅

Have you run cargo coverage? I'm not sure if there's any tests for this.

I tried but I don't think I've cloned the repo properly, the test directories are empty (I tried git submodule update --recursive but nothing happened), and hence the coverage is 0% across everything 😅

You need to clone the submodules, it's in the adjacent README.

I have run it now, coverage % seems to have gone down but there does seem to be a test for this case

Thank you!


Return ProvisionFailedOfflineError instead of APINetError

I tested this with real devices and in all offline cases, the error that came back from LoginProvision was an APINetError.  So this transforms that error to a new one, ProvisionFailedOffline, which is properly exported across RPC calls.
Frontend could handle it and show a nice error screen.  At the very least, the user will now see "Device provisioning failed because the device is offline" instead of the current mess.
cc @chrisnojima @keybase/react-hackers

The commits 8c3c799f25bb...9aa5652ea11c introduce visual changes on linux. :mag_right: 1 changed

Changed: Markdown-emoji (before) (after)

I was turning off wifi on the new device at various points during provisioning.
That is needed in order to get network errors.
In my notes, I did the following:
scenario 1

username entered
turn off wifi
continue to provision

scenario 2

do everything up until the provisioner device selection screen
turn off wifi
select a device and continue to provision


Typescript needs to be a peer dependency

Hi there, thank you so much for developing this plugin, it is awesome! However, I have a major problem: I can only use TS 2.* because it is a direct dependency of the plugin. We need to have typescript be peer dependency in package.json so we can use whatever version of TS we see fit.

I would like to use typescript v3. Any chance of doing this?

This has been resolved, please open a new issue if there's something I missed :smiley:


feat: Add hide sensitive data switch to environment config

Thanks for submitting a PR! Please check the boxes below:

[X] I have run pre-commit to check linting
[X] I have filled in the "Changes" section below?
[X] I have filled in the "How did you test this code" section below?

Changes

Added "hide sensitive data" switch to environment config.
Added ConfirmToggleEnvFeature to confirm the change.
Added feature flag configure_hide_sensitive_data, If the value is true, the hide sensitive data switch will be displayed in the environment settings.

How did you test this code?

Click on the 'Settings' of an environment.
Click the hide sensitive data switch to open ConfirmToggleEnvFeature modal.
Click 'Confirm Changes' button.

Docs PR: https://github.com/Flagsmith/flagsmith/pull/2247/files


Add Format.accept_types and Format.accept_type.

This allows Format.content_type to be provided with priority parameters for the type, and aliases. These are stripped out to allow Format.reader_types and so-forth, to continue to return values without parameters.
Fixes #327.

Coverage increased (+0.03%) to 90.862% when pulling ad025bc5dd76f37402298dc55f8d7b0d7a3ff612 on feature/accept_type into e46839c0fffa2b53b50e92cb338c472e2512db65 on develop.


json error in core.entity_registry

Since 0.104.0 at reboot of home assistant these two errors appear in the registry.
I'm using hassio 0.104.3 on rpi3b+ in docker (raspbian)
I didn't find any evident malfunctions, however I can't understand what the generation of this error can be linked to.
Error writing config for core.entity_registry: Object of type set is not JSON serializable
Failed to serialize to JSON: /config/.storage/core.entity_registry
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/util/json.py", line 57, in save_json
    json_data = json.dumps(data, sort_keys=True, indent=4, cls=encoder)
  File "/usr/local/lib/python3.7/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/local/lib/python3.7/json/encoder.py", line 201, in encode
    chunks = list(chunks)
  File "/usr/local/lib/python3.7/json/encoder.py", line 431, in _iterencode
    yield from _iterencode_dict(o, _current_indent_level)
  File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "/usr/local/lib/python3.7/json/encoder.py", line 325, in _iterencode_list
    yield from chunks
  File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "/usr/local/lib/python3.7/json/encoder.py", line 438, in _iterencode
    o = _default(o)
  File "/usr/local/lib/python3.7/json/encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type set is not JSON serializable

UPDATE: the error appears also in 0.105.0 and 0.105.1

Same issue, as below.
I'm using 0.104.3 on VM in QNAP virtualization station.
In same time, Xiaomi Aqara multi_sensors name customization do not remain saved.
2020-02-02 15:15:59 ERROR (SyncWorker_0) [homeassistant.util.json] Failed to serialize to JSON: /config/.storage/core.entity_registry
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/util/json.py", line 57, in save_json
json_data = json.dumps(data, sort_keys=True, indent=4, cls=encoder)
File "/usr/local/lib/python3.7/json/init.py", line 238, in dumps
**kw).encode(obj)
File "/usr/local/lib/python3.7/json/encoder.py", line 201, in encode
chunks = list(chunks)
File "/usr/local/lib/python3.7/json/encoder.py", line 431, in _iterencode
yield from _iterencode_dict(o, _current_indent_level)
File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/local/lib/python3.7/json/encoder.py", line 325, in _iterencode_list
yield from chunks
File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/local/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/local/lib/python3.7/json/encoder.py", line 438, in _iterencode
o = _default(o)
File "/usr/local/lib/python3.7/json/encoder.py", line 179, in default
raise TypeError(f'Object of type {o.class.name} '
TypeError: Object of type set is not JSON serializable
2020-02-02 15:15:59 ERROR (MainThread) [homeassistant.helpers.storage] Error writing config for core.entity_registry: Object of type set is not JSON serializable

I noticed core.entity_registry last update was on 01/15/20 (0.104.0 release date)

the problem seems to be related to the inability to write to the core.entity_registry file
I think this because I tried to manually delete the file and make it re-create it automatically at reboot. Then I customized some entities (changing the name of the entities from sensor.XXXX to sensor.YYYY) and at reboot the changes were not present.

I didn't change manually the file.
Entities  added (with Deconz) until 01/15/2020 are present, after 01/15/2020 are not present and file cannot be modified by Hassio (issue supposed caused by by 0.104 version ...?)

I was able to reproduce the error in another context. in the Entity Registry every time I change the name of an entity, the error appears.

+1

I've opened https://github.com/home-assistant/home-assistant/pull/31901 which will help us point out what data is incorrect.

Please update to Home Assistant Core 0.105.5 and check your logs. It should now tell you the paths to the data that is incorrect.

From my log:
2020-02-18 10:29:04 ERROR (SyncWorker_12) [homeassistant.util.json] Failed to serialize to JSON: /etc/hass/.storage/core.entity_registry. Bad data found at $.data.entities[33].capabilities.hvac_modes, $.data.entities[34].capabilities.hvac_modes
2020-02-18 10:29:04 ERROR (MainThread) [homeassistant.helpers.storage] Error writing config for core.entity_registry: Failed to serialize to JSON: /etc/hass/.storage/core.entity_registry. Bad data found at $.data.entities[33].capabilities.hvac_modes, $.data.entities[34].capabilities.hvac_modes

The "bas data", I think, come from an air conditioner through a SmartThings integration.

The same from Deconz integration
2020-02-18 12:28:35 ERROR (SyncWorker_3) [homeassistant.util.json] Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[52].capabilities.hvac_modes, $.data.entities[53].capabilities.hvac_modes, $.data.entities[54].capabilities.hvac_modes, $.data.entities[55].capabilities.hvac_modes 2020-02-18 12:28:35 ERROR (MainThread) [homeassistant.helpers.storage] Error writing config for core.entity_registry: Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[52].capabilities.hvac_modes, $.data.entities[53].capabilities.hvac_modes, $.data.entities[54].capabilities.hvac_modes, $.data.entities[55].capabilities.hvac_modes

@andrewsayre could you verify that air conditioners do not return a set for hvac modes?
@Kane610 could you verify that Deconz does not return a set for hvac modes?

@balloob it is only returning data that is from json structures so shouldn't be possible. (I also double checked the code, no sets as far as I can see)

I guess my updated error message wasn't very helpful :(

I found the SmartThings Air Conditioner issue and have a fix here https://github.com/home-assistant/home-assistant/pull/31959

@fudu could you look in the file <config>/.storage/core.entity_registry and see what integration is responsible for entities 52, 53, 54 and 55?

Same here

Error writing config for core.entity_registry: Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[150].capabilities.hvac_modes, $.data.entities[151].capabilities.hvac_modes, $.data.entities[152].capabilities.hvac_modes, $.data.entities[153].capabilities.hvac_modes, $.data.entities[154].capabilities.hvac_modes

I don't know where to find which device the number 150 corresponds to, but the entity number is 5 (150-151-152-153-154) and I have 7 tado thermostats (climate.___) and 5 SmartThings air conditioners, so I think it's their fault...

There aren't data entities 52,53,54,55 in core.entity_registry, but message:
2020-02-18 12:28:35 ERROR (SyncWorker_3) [homeassistant.util.json] Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[52].capabilities.hvac_modes, $.data.entities[53].capabilities.hvac_modes, $.data.entities[54].capabilities.hvac_modes, $.data.entities[55].capabilities.hvac_modes 2020-02-18 12:28:35 ERROR (MainThread) [homeassistant.helpers.storage] Error writing config for core.entity_registry: Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[52].capabilities.hvac_modes, $.data.entities[53].capabilities.hvac_modes, $.data.entities[54].capabilities.hvac_modes, $.data.entities[55].capabilities.hvac_modes
appears when I try to personalize (name change...) ANY entities from ANY integration (Deconz, Smartthings, mobile App).
Changes are reverted after HA restart.
This happens from HA v0.104.0:  core.entity_registry is untouched from 01/15 (0.104.0 release date)

actually, i own 4 samsung air conditioners .... probably entities 52,53,54,55 involved ??

There aren't data entities 52,53,54,55 in core.entity_registry, but message:
2020-02-18 12:28:35 ERROR (SyncWorker_3) [homeassistant.util.json] Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[52].capabilities.hvac_modes, $.data.entities[53].capabilities.hvac_modes, $.data.entities[54].capabilities.hvac_modes, $.data.entities[55].capabilities.hvac_modes 2020-02-18 12:28:35 ERROR (MainThread) [homeassistant.helpers.storage] Error writing config for core.entity_registry: Failed to serialize to JSON: /config/.storage/core.entity_registry. Bad data found at $.data.entities[52].capabilities.hvac_modes, $.data.entities[53].capabilities.hvac_modes, $.data.entities[54].capabilities.hvac_modes, $.data.entities[55].capabilities.hvac_modes
appears when I try to personalize (name change...) ANY entities from ANY integration (Deconz, Smartthings, mobile App).
Changes are reverted after HA restart.
This happens from HA v0.104.0: core.entity_registry is untouched from 01/15 (0.104.0 release date)

actually, i own 4 samsung air conditioners .... probably entities 52,53,54,55 involved ??

Alright, fix for the Samsung ACs will be in the next release 👍

Solved with 0.106.0, however I had to remove the SmartThings integration and re-enable it. No way to use previous smart-app.
everything seems to be ok


Update isolating-code-under-test-with-microsoft-fakes.md

erroneously mentions shims in the stubs section, probably copypasta

#sign-off

@Mikejo5000
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Fix build on Windows ARM64

CMAKE_SYSTEM_PROCESSOR is 'ARM64' on Windows ARM64.

@compnerd what do you think?

@swift-ci please test

It looks like my repos were in an out-of-date state for some reasons. This PR wasn't necessary. Sorry for the confusion.


thread 'main' panicked at 'Entity does not exist'

Bevy version
47004dfc)
Operating system & version
Windows 10
What you did
I have a system that adds/removes unit struct components via Commands. Sometimes my game runs fine for several minutes before crashing. Others, it crashes quickly with this panic:
panic: thread 'main' panicked at 'Entity does not exist'
The full log of my run, with Bevy set to debug mode and the system ambiguity checker added, can be found here. I can't pin down an easy reproduction even in my own game--it just seems like things crash after a while and I don't know why. If I'm tracing the panic back correctly to the system in question, it isn't immediately obvious to me that it's accessing despawned entities.
I'm seeing lots of this in the log:
Mar 24 10:46:27.784 DEBUG bevy_ecs::system::commands: Failed to despawn non-existent entity 271v1
I'm not sure where this is happening, but this is logging on debug. I'm also not sure how to trace back from this failing command invocation, to whatever system originated it. Obviously I want to do something about these failed despawns--I just don't know how.
What you expected to happen
Not panicking would be nice. as would some mechanism for tracing back from the panic to the specific command that caused it. Maybe some sort of no-op remove (I.e. "remove this component, but don't panic if the entity doesn't exist") would be nice too, though maybe I'm hitting a soundness bug somewhere that shouldn't be papered over by no-op commands. :)
What actually happened
Panics at random times. It's always when interacting with a specific subsystem of my game, but never in response to a specific action type or at a transition point.
Additional information
Happy to provide any, just let me know how to turn logging up to 11. :)

This discussion hints at a similar bug, introduced in #1471. I expect @cart will be merging a fix shortly, but until then does the behaviour go away if you revert to before that PR was merged?

Ugh, I'm now relying on reliable change detection, so I can't revert
that. I'll wait for a fix. and see if this goes away.
But something similar happened on 0.4, so it's possible these are
different issues. I didn't log because I'd hoped the ECS rewrite would
nuke it from orbit, but the behavior is the same.

This does not appear to be the issue in #1743. Seems like they are attempting to insert a component into a non-existent entity. This should be an error as it has real implications for app state (unlike removing components from non-existent entities or despawning non-existent entities, which we have previously agreed should not be errors due to Command synchronization complexity).

From #1748 :) Perhaps add in a check to see if the entity exists before issuing the component insertion command? Failing that, you could write a custom command that checks if the entity exists before trying to insert into it.
Perhaps we should be batch processing commands and always running component insertion before entity deletion, but that's a long way off.

Perhaps we should be batch processing commands and always running component insertion before entity deletion, but that's a long way off.

Maybe we need to do command commits in a way that respects system dependencies?

Ah wait i think we already do because we topologically sort the "parallel system" list.

I'm thinking a simple remove_system.system().after(AddSystemLabel) should resolve this

Maybe we need to do command commits in a way that respects system dependencies?

Yeah, talking with @BoxyUwU about this has convinced me that commands should be handled in the same order as the systems that generated them in order to keep the mental model clear.

Ah wait i think we already do because we topologically sort the "parallel system" list.

This is correct.

Yeah, talking with @BoxyUwU about this has convinced me that commands should be handled in the same order as the systems that generated them in order to keep the mental model clear.

Applying command buffers in the exact order of the systems that issued them is not possible unless we forbid parallelization: e.g., "order" doesn't make sense for systems A and B where A started before but ended after B. And timestamping and sorting all individual commands by default will most definitely have perf implications.

Obviously I want to do something about these failed despawns--I just don't know how.

From my understanding, the issue is that there's no way to trace back the failing command to which system added it, making it hard to debug system order

Yeah, system order would be tough, because in this case it may be across
plugin boundaries. So I'm not even sure what that means or how it would
help here.
Not sure to what extent this is orthogonal, but I'd love some sort of
trace logging where commands are annotated with whatever system
triggered them. Is that a tracing span? It'd be nice to grep the log for
these failed despawns so I can track them back to whatever system
created the entities. Right now my logs tell me that the entity failed
to despawn, but not even debug-level lets me know what created them in
the first place. And I'm not sure if these are the entities in question,
but I don't know that I have the tooling to fix the issue and find out.
Killing performance would be fine for that use case, since it'd be
rarely used and more of an absolute last option.

#846 may be relevant here

Im thinking this this issue isn't really something we can solve in the next day (and system ordering/restructuring logic is a workaround), so I'm removing this from the 0.5 milestone. We can add it back if thats unpopular or if I missed something important.

Agreed: I'm much less concerned now that we understand what's going on better.

Sorry, I'm fine with pushing this past 0.5, but there's a workaround?
I'm not clear on what it is. I seem to be despawning a bunch of entities
that I have no way of knowing where they were spawned, and I don't know
what to reorder much less which order to put things in. This does seem
to be a bit of a corner case, so by all means don't delay the release,
but if a workaround for my current situation was mentioned here, I must
not be smart enough to have spotted it. :) Is the workaround just to
brute-force reorder systems touching this particular component until my
crashes stop?
Thanks.

This is biting me hard also, and I have not yet been successful in reordering systems to avoid the dreaded "Entity not found" crash.  As a temporary workaround could this somehow be made into a non-fatal error?

Sorry for the noise, but this has bitten me twice in the last hour on two different systems. The weird thing is that it seems to happen when things are despawned, and with operations that could safely fail if the entity doesn't exist. I.e. if I'm tweaking something's name, and that thing is gone because a) the player destroyed it or b) the entire game was reset, then it's absolutely fine for that thing to fail in a way that doesn't toast the entire process.
Maybe the ambiguity-checker could help, but that seems like overkill for situations where I don't care if this fails. Could it just be made a non-panic, maybe log it at some high level and move on?

Related to #2581.

Closing; there's more specific issues for remaining improvements.


Revert "fix: make iterateTLSConfig only work for TLS config"

Reverts alibaba/pouch#2057

Since it is a revert action, we can merge this. LGTM

Why to revert this? @Ace-Tang

Codecov Report

Merging #2111 into master will increase coverage by 0.11%.
The diff coverage is 75%.


panic in rdp_proto::nego::parse_negotiation_request

This fuzzing case triggers a panic when calling consume on a slice.
fuzz case: https://drive.google.com/file/d/1DtCGePWZlBaW4WRo1Lpc2duNqrc_rl72
Note: The fuzzers are currently on the fuzzers branch.
Crash output:
cargo +nightly fuzz run fuzz_nego

thread '<unnamed>' panicked at 'slice index starts at 19 but ends at 18', src/libcore/slice/mod.rs:2561:5

14: std::io::impls::<impl std::io::BufRead for &[u8]>::consume
             at /rustc/0b680cfce544ff9a59d720020e397c4bf3346650/src/libstd/io/impls.rs:263
  15: rdp_proto::nego::parse_negotiation_request
             at ./src/nego.rs:187
  16: rust_fuzzer_test_input
             at fuzz_targets/fuzz_nego.rs:15

Crashing code in nego.rs:
let nego_data = if let Some((nego_data, read_len)) = read_nego_data(slice) {
        slice.consume(read_len);

The crash was fixed in https://github.com/Devolutions/IronRDP/pull/4/.


The overall_output_flows constraint should be written in the highest resolution not the lowest

What and Why
The overall output constraint is to limit the capacity (i.e., power), so it should be in the highest resolution. We need to double-check if, after this change, we need the upper bound constraints since they might not be necessary anymore (analyze the case with investment).
Generally, all energy-related constraints (e.g., balance) should be in the lowest resolution, whereas all capacity-related constraints should be in the highest resolution.
We need to update the documentation too.
Possible Drawbacks
N.A.
Related Issues
No response

Yes, after 9h, please. Send me an invite.


deprecated hideCurrentSnackBar showSnackBar

Scaffold.of(context)
..hideCurrentSnackBar()
..showSnackBar(snackBar);
Can be changed to:
ScaffoldMessenger.of(context)
..hideCurrentSnackBar()
..showSnackBar(snackBar);

Yep, Thanks.

Fixed, Just uploaded new refactored version 2.0.0. Thank you!


Optimise STAR command for riboseq data

Description of feature
I'm noticing a lot of multi-mapping reads and those unmapped as 'too short'. Some of this is just down to the short read lengths I guess, but we should try to add some STAR optimisations. See the STAR MultiQC plot below. The top runs are RNA-seq, bottom Riboseq.

I will explore this when I have time. Below are some thoughts on it. Any input would be helpful.
Looks like this param is a bit permissive. I often refer to what ORFik does and they use 10 rather than 20. This will only increase the number mapped to too many loci though.
I also wonder what the trade off is between Local and EndToEnd. Local allows softclipping which is useful if there are untemplated additions or if there was issues with the preprocessing of adapters/UMIs. But I can't see how to limit the number of softclipped bases so maybe we are better off leaving it EndToEnd.
outFilterMismatchNmax is currently default as far as I can see, which is 10. This should be max 3 for Ribo-Seq due to their short read lengths.
I am unclear how we get the 'too short' as it was my understanding that --outFilterMatchNmin controlled this and the default is 0.  ORFik have a min length of 20 but it is my understanding that there are potentially valid Ribo-Seq reads as short as 18nt long. Their validity can be determined downstream of alignment based on periodicity etc. Also, maybe this could be used to control the degree of softclipping tolerated.

Could you PR any modifications you feel may be appropriate, and post the above plot to show the impact of the change with the test or test_full profiles please?
'too short' is a bit misleading with STAR, it doesn't quite mean what it seems.

Hey everyone, I’ll chip in case helpful. My apologies @JackCurragh if you’ve already figured these things out for your upcoming PR.

I agree w reducing the number of multi-mappers.

The most likely cause for the high fraction of “too short” reads is the --alignEndsType EndToEnd. I however, think this is the most appropriate default setting for ribo-seq data given their short length, and the fact that the read length encodes important positional information related to ribosomal decoding (unlike RNA-seq reads), and the degree of soft-clipping is hard to control. This precision is important for accurately determining the position of ribosomes on mRNAs. I would trade-off specificity over sensitivity, but that depends on what downstream analyses the data will be used for.

The stringent requirement of EndToEnd alignment likely fails when ends of the reads do not perfectly match the reference, thus "too short".
Although --outFilterMatchNmin affects this, you can fine-tune the alignment sensitivity by adjusting several other parameters that control its behaviour:
•	Reducing --outFilterScoreMinOverLread and --outFilterMatchNminOverLread to accept shorter or less perfect alignments.
•	Increasing --outFilterMismatchNmax to accommodate more mismatches.
However, these alterations might affect the distribution of reads in other categories as well - i.e. if we allow too many mismatches we might get many more multi-mappers.
I recommend checking the multiQC/STAR log output alongside the BAMs’ riboseq QC metrics to fully assess the impact of any parameter adjustments.
I have also noticed high variability between datasets in relation to the STAR settings used, so I do wonder before changing the defaults to look how they behave on other datasets besides the test_full one before fully making the switch?
I can help with some of these matters, feel free to message me.

Hi Ira, thanks for the input. I have this ready to PR with the updated params but I agree that it is worth further investigation. Unfortunately I probably won't have time to do this until later this week but will be sure to report back when we have results to discuss.

I messed around quite a bit (see e.g. https://github.com/nf-core/riboseq/pull/37) and didn't manage to make any improvements to the mapping statistics, so didn't proceed further.
Of course the parameter space is large, so I'm sure there are improvements to be made, we just need to demonstrate the utility.


rltk.CrfTokenizer() no longer available?

I was following a tutorial using rltk.CrfTokenizer() but in the latest version, the code seems to have migrated elsewhere. Could you help me figure out how to now instantiate a tokenizer, i.e., the new equivalent of the old:
Tagging recent contributors: @saggu
tokenizer = rltk.CrfTokenizer()

Found it here: https://github.com/usc-isi-i2/rltk/blob/master/rltk/tokenizer/crf_tokenizer/crf_tokenizer.py
tokenizer = rltk.tokenizer.crf_tokenizer.crf_tokenizer.CrfTokenizer()


module unknown

Hello, I've noticed you're tryna use a module called googlesearch which isn't actually a module, you can say because it doesn't work on Kali or Parrot and the module named "googlesearch" isn't in the Python3 docs

Requirements.txt will make error and when you run the script it will work fine


Adds Bower install to postinstall

Documentation states that both node_modules and bower_components are install when running npm install which wasn't the case. Added bower as a local dependency and bower install to the postinstall script to fix this.

I believe dependencies on bower were removed for the tether based projects. Mainly because having two registries to depends on seemed unnecessary and required users to install bower. I would be more inclined to update the documentation to omit bower and replace bower usage with npm/node_modules.

@geekjuice Sounds like a better option to me, will update the PR to reflect those changes.

Any reason you need bower? Is npm not suitable to your needs?

I don't think we need bower anymore, so closing this PR.


NEW: Dropdown links in header

This is a demonstration of allowing users to manually add dropdown links in the header. Currently this PR adds a new configuration value (dropdown_links). This takes a list of dictionaries. Each dictionary has a name, and either has:

url in it, in which case it is treated as an extra top-level link in the header.
items in it, in which case items is treated as a list of links that will populate a dropdown menu.

If url does not start with http, then we assume it is a document and we resolve it by using pathto(
In this way, you can add extra items in the header in dropdown menus in order to save space. I also refactored this and the document links into their own templates in case other folks want to over-ride them.
Should this be merged into extra_links behavior?
Currently, extra_links allows users to provide extra top-level links that are "appended" to our site's document tree. We then use the n_links_before_dropdown to automatically create a More dropdown when the number of top-level links are above that number.
Instead, we could allow extra_links to accept the Dropdown configuration provided here (it already accepts a list of dictionaries, so this would only mean supporting the items value to add dropdowns). Then, n_links_before_dropdown would only apply to the site's documents, and extra_links would be used for any extra links.
To do

[ ] Answer question above
[ ] Agree on config and UX
[ ] Add tests
[ ] Document

References

maybe closes https://github.com/pydata/pydata-sphinx-theme/issues/1061
maybe closes https://github.com/pydata/pydata-sphinx-theme/issues/1016

Feel free to take this one over and/or totally rework it @Carreau - I won't have time to get it over the finish line.


[For pure_jupyter_version] Logging file scheme

Have the file for logging be a rondel of 5 files of maximum size equal to the upload size of files in GitHub issues (possibly under a top-level directory /logs).
This makes it viable to safely use the application locally or in the same instance all the time. It is not relevant for mybinder or other deployments (Heroku etc.), where an instance of the app is continuously re-created from scratch after a period of non-usage.

Fixed in #25


Inconsistent results - Mittens VS standard Glove

I am using mittens with a pre-built cooccurrence matrix of domains with the hopes of clustering certain domains that are thematically related, close to each other. Using the non-vectorized glove implementation from https://github.com/stanfordnlp/GloVe, I get very strong results. The current initialization is:
glove_model = Glove(no_components=50, learning_rate=0.03)
glove_model.fit(coo_matrix(matrix, dtype=float), epochs=50, no_threads=64, verbose=True)

Finding the nearest domains to nintendo using cosine distance yields good results.
find_nearest(glove_model, "nintendo", 10)

[('game', 0.955347329117499),
('zavvi', 0.9382098190168783),
('eurogamer', 0.9296358002057901),
('playstation', 0.9290108695965159),
('gamespot', 0.9241452666014682),
('gamesradar', 0.9210470827690169),
('365games', 0.9193152241566838),
('ign', 0.9178656620515147),
('ea', 0.912055674280889),
('forbiddenplanet', 0.9118661547211797)]

Given these results, I wanted to use mittens for two reasons: take advantage of the vectorized implementation for speed, and harness the ability to extend glove into a retrofitted model. However, when I used a basic mittens (without retrofitting existing embeddings), the results come out quite poor, even when the same hyperparameters are used.
glove_mittens_50_50 = GloVe(n=50, max_iter=50, learning_rate=0.03)
cooccurance = np.array(matrix.todense()) # was sparse matrix for original glove
glove_mittens_trained_50_50 = glove_mittens_50_50.fit(cooccurance)

I built a pd dataframe with the resulting numpy matrix and incorporated the domains as the index before writing a function that would calculate the cosine distance in the same way that the original glove model does.
find_nearest(mittens_glove_df_50_50, "nintendo", 10)

[('hmrc', 0.9992567),
('anglingdirect', 0.999141),
('axa', 0.99907136),
('greatist', 0.99906415),
('techadvisor', 0.99906313),
('victorianplumbing', 0.99903136),
('dell', 0.9990228),
('imore', 0.99899846),
('carpetright', 0.99899185)]

As you can see, the results are not at all as expected. Furthermore, while the original glove model will have converged and not change much (only very slightly) by increasing the number of iterations, the vectorized glove in this package will.
find_nearest(mittens_glove_df_50_100, "github", 10)  # 100 iterations

[('yammer', 0.9993163),
('twitch', 0.9992425),
('axs', 0.9992203),
('rottentomatoes', 0.99920493),
('travelsupermarket', 0.99919695),
('lbc', 0.99919665),
('motors', 0.99918556),
('goodreads', 0.9991843),
('deezer', 0.9991767),
('nationalexpress', 0.99917376)]

Is there a reason why this is the case? Am I doing anything wrong, or is there anything else you'd like me to try?
Thanks.

I am experiencing similar issues, but I am not certainly sure that my method is 100% correct so that to only suspect mittens. Here's what I've tried:
I have constructed a vocabulary consisting of the top 20,000 most frequent words from a custom corpus (python documentation [1]), and the corresponding co-occurrence matrix (20k x 20k), then I have fine-tuned glove.840B.300d embeddings as mentioned in the readme (with window size = 5, num_iter = 5000), thus obtaining a 20000 x 300 matrix.
The final embedding matrix was constructed as such:
final_glove_emb = load('glove.840B.300d')

for w in fine_tuned_glove_emb:
    if w not in glove_emb:
        final_glove_emb[w] = fine_tuned_glove_emb[w]
    else:
        final_glove_emb[w] = 0.5 * fine_tuned_glove_emb[w] + 0.5 * final_glove_emb[w]

Here's a list of 20 most similar words to function:
[('fromaddr', 0.6572332),
 ('functions', 0.65711826),
 ('preserving', 0.6557628),
 ('roundrobiniterables', 0.6226967),
 ('parameters', 0.59739476),
 ('asynciosleepdelay', 0.5884969),
 ('encodes', 0.5867052),
 ('preservation', 0.582687),
 ('maintaining', 0.58013296),
 ('singledispatch', 0.5575917),
 ('fractionsgcd', 0.5569468),
 ('preserve', 0.5410574),
 ('restoring', 0.53190446),
 ('snippet', 0.5317656),
 ('distutilscoresetup', 0.5273622),
 ('conserving', 0.51967645),
 ('essential', 0.50960046),
 ('defect', 0.5081374),
 ('subsection1', 0.5065669),
 ('vital', 0.50164175)]

I was hoping for words like procedure, call, arguments etc to appear at the top.
I am guessing that maybe the python docs may not serve as a quality corpus for what I'm trying to achieve? I just want to rule out the possibility that there's something wrong with how I've performed the fine-tuning process, so that to focus only on the 'data' part.
Thanks.
[1] https://docs.python.org/3/download.html

From the ReadMe file it says that we need pre-trained matrix in order to use mittens. This means you should have implied some kind of reweighting scheme to your co-occurrence matrix and then use Mittens.

I met the same problem,and I think it's about how co-occurrence matrix generates.


Reconcile fails in GitLab runners with database lock issue

Describe the bug
With the new sfpowerkit version(4.1.4) in the docker image for pipelines, the profile reconciliation is breaking due to database lock issue in GitLab shared runners. This is only observed in the GitLab shared runners, and I cannot reproduce the behavior in the local machine.
To Reproduce

Setup the orchestrator pipeline (which uses latest Docker image for sfpowerscripts) in GitLab
Deploy the access-mgmt package to any sandbox using the pipelines
The reconciliation breaks with data-base lock issue

Command:  sfdx sfpowerkit:source:profile:reconcile
Expected behavior
The behavior of reconciliation should be same when run in local machine or cloud runners(using docker)
Screenshots

There are a total of 41 profiles in queue for reconciliation, split into 4 workers. When the reconcile errored out in each worker, it stopped processing reconciliation for all the remaining profiles in the queue of that worker, resulting in deployment failures.
Desktop (please complete the following information):

OS: Linux[GitLab.com shared runners]
Node Version: latest
Version of sfpowerkit: 4.1.4
Salesforce Org Version [ In case of pre release window ]

Additional context
I have tried several times on my local machine to reproduce the error, but local machine works fine. This seems like the issue is more related to the runners on GitLab. Not sure if the same is happening across other cloud runners.

This is fixed in 4.1.5 and currently undergoing testing.


feat(ON-1467): adds new disabled-click event to SbToggle component

adds a new 'disabled-click' event to the <SbToggle/> component so that we can apply some logic when this event is triggered.

Pull request type
Jira Link: ON-1467

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Other (please describe):

How to test this PR

The component just emits a new 'disabled-click' event so no particular test is needed 🙂
What is the new behavior?

The component emits a new 'disabled-click' event when the user clicks on the toggle while being disabled.

Other information

@lisilinhart just double-checking, can I merge? 🙂

Yeah we can merge it, i'm making some updates to the submodules this week, but it shouldn't affect the merge here


Followup commit to https://github.com/docker/docker/pull/12986

Followup commit to https://github.com/docker/docker/pull/12986 where the information about the mailing lists, IRC channels, etc. are copied from the CONTRIBUTORS.md file to the README.md file also.

I dont think this needs 3 commits can you please squash them

Even for the HTML tag removal, you do not need them to be individual micro-commits ? In my past doc submission patches (not for docker though), I was always told to split into micro-commits without merging such changes in a single commit. Thanks for the review.

I think 1 will suffice

Merged the commits into a single commit. Please check again. Thanks.

LGTM
ping @docker/docs-owners

Ping. Can someone either merge or deny it ? Thanks.

@psankar We required two docs maintainers to merge. I'll ping them again.  ping @thaJeztah @jamtur01 @fredlf @SvenDowideit

Sorry, missed the first ping (docs-owners doesn't work for me)
LGTM (I restarted the failed W1ndows build for good measures).

LGTM. Sorry to be slow, was out on vacation last week.