Bug: Some Content-Security-Policy values breaking the functionality/design

Thank you for this useful plugin.
Some Content-Security-Policy values break the functionality or design of the plugin page:
Examples:
default-src 'self'
and
default-src 'self' frame-ancestors 'none'
=> Effect: Custom Header records can't be added or removed anymore. The plus and minus buttons don't work.
default-src 'none'
=> Effect: shows an unstyled plugin page.
Grav v1.7.43
Plugin v1.0.1

I think you just need to set: enabled_in_admin: false in the confuiguration if you want to use the admin


Should symptoms be deleted after uninstall and reinstall?

App version: iOS <IP_ADDRESS>
OS: iOS 14
Device: iPhone SE
Reproducible: Always
Summary: App with symptom history does not get deleted on uninstall. Should it?
Steps to reproduce:

Install app (TestFlight) and add symptoms
Uninstall app
Install again and onboard
Go to My health log

Actual Results: Symptoms from before are shown

No it shouldn't, and this is something we'd been meaning to change.
@denisedresbach This is a tricky but particularly important one to test because the first time a user loads up the app after updating we move their symptom history from a type of storage that persists after uninstall to a type that doesn't - and we want to be absolutely sure this transfer can't fail causing users to lose their symptoms history on updating the app.
As well as testing that it doesn't persist after uninstall, please can you make sure you have some symptoms checker history before updating to <IP_ADDRESS>, then check that it is all present and correct after updating, including after closing and reopening the app after updating.
Where possible, especially if you can do the update from a previous version to <IP_ADDRESS> multiple times, can you please see if you can find any way of messing up the process after updating such that your symptoms history gets lost (e.g. turning the phone off while the app loads, that sort of thing). It should be impossible...

@AlanSl Ok sounds good I will do this testing. Thank you for the info!

Testing notes:
iOS

Update with symptoms - Verify symptom history is still there after update ---
Uninstall and reinstall with symptoms - Verify that the symptoms are cleared when reinstalling ---PASSED
Update and try to disrupt multiple ways to verify symptoms are not lost ---

Android

Update with symptoms - - Verify symptom history is still there after update ---I don't think I can test this one since I cannot go back a version like iOS?
Uninstall and reinstall with symptoms - Verify that the symptoms are cleared when reinstalling ---PASSED
Update and try to disrupt multiple ways to verify symptoms are not lost ---

@denisedresbach Do you have any Android devices used only for testing where you can add and remove Google accounts without any problems?
If so can you try this please:

Remove the Google account linked to the NYS beta testers program from the device in device accounts settings and uninstall Covid Alert NY (if that was the only Google account either add a different one or set up a basic google account for this)
Install the public Covid Alert NY from the normal (non-beta) app store
Set it up, add some symptoms history, make a note or take a screenshot of the symptom history
Re-add the Google account linked to the NYS beta testers program to the device in device accounts settings
Update the app when the Google Play Store listing for Covid Alert NY shows as being linked to internal testing and an update becomes available (I think this happens almost immediately but there might be a delay of up to 24 hours like when an account is linked)
Check the app is now the right version and check the symptom history is unchanged.
Re-open the app and check it's still unchanged
Add another symptom check-in and check that the symptom history is as expected

Thanks!

Hi @AlanSl I only have the one Android device and it is my personal device. The linked Google account is my main account unfortunately. Also, I thought if we go from public app to a test app it will make me re onboard. At least that is what I found with the other apps. I was told that was the reason. Is that not true for this one?

Ah okay, didn't know that about switching types of app. In that case we can't test this beyond what I was doing locally which all worked fine so it should be fine to close this


How to set cache properties for Hibernate scond level cache?

I'm working on a Java spring project where I have multiple entities to be cached using @Cache annotation, ex:
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE ,region = "cache1")
I have set  spring.jpa.properties.hibernate.cache.region.factory_class to be RedissonRegionFactory
As I'm using Redis cache as Hibernate second Level cache, I want a way to customize the properties of each cache region in a Java class, by properties I mean the TTL and maxEntriesLocalHeap.

Hello @AseelAbushhadeh , what I have done in my project is configure each cached entity with my own configuration class. I am also open to hear if there is another way of achieving this.

@OdaybatLFC
Why can't you use spring.jpa.properties.hibernate.cache... settings?
spring.jpa.properties.hibernate.cache.redisson.entity.expiration.time_to_live=
spring.jpa.properties.hibernate.cache.redisson.entity.expiration.max_idle_time=
spring.jpa.properties.hibernate.cache.redisson.collection.expiration.time_to_live=
spring.jpa.properties.hibernate.cache.redisson.collection.expiration.max_idle_time=

thanks for the suggestion, I can use it but this will apply to all caches, I want to customize the properties for each cache individually.

Hello @AseelAbushhadeh , what I have done in my project is configure each cached entity with my own configuration class. I am also open to hear if there is another way of achieving this.

Hi, I think it is a good solution, can you elaborate more ?

You can specify region name as well.
spring.jpa.properties.hibernate.cache.redisson.my_object.expiration.time_to_live=
spring.jpa.properties.hibernate.cache.redisson.my_object.expiration.max_idle_time=
spring.jpa.properties.hibernate.cache.redisson.my_collection.expiration.time_to_live=
spring.jpa.properties.hibernate.cache.redisson.my_collection.expiration.max_idle_time=

You can specify region name as well.
spring.jpa.properties.hibernate.cache.redisson.my_object.eviction.max_entries=
spring.jpa.properties.hibernate.cache.redisson.my_object.expiration.time_to_live=
spring.jpa.properties.hibernate.cache.redisson.my_object.expiration.max_idle_time=

spring.jpa.properties.hibernate.cache.redisson.my_collection.expiration.time_to_live=
spring.jpa.properties.hibernate.cache.redisson.my_collection.expiration.max_idle_time=

Thanks it works!!
Hoping I can find a way to do that in a java class.


How to bind username with the user's inputs ?

Hello,
First, i'd like to thank for this bundle. LDAP Authentication is killing my mind since long time.
Is it possible to avoid to provide the ldap_tools.domains.example.username  in app/config/config.yml ?
I want the user to provide his own username and password to bind the ldap server

Hi there,
I finally found a solution randomly. By leaving the username and password empty, it works ! :+1:
ldap_tools:
    domains:
        company:
            domain_name: vnet.company.com
            username:
            password:
            base_dn: "dc=vnet,dc=company,dc=com"
            servers: ['ldap01.vnet.company.com']

Currently this is not possible, but it should be. The problem at the moment is I'm requiring the username/password in the config tree:
https://github.com/ldaptools/ldaptools-bundle/blob/master/DependencyInjection/Configuration.php#L133
So I'd have to remove that requirement. Easy enough. But then I also need to adjust the Guard and LdapAuthenticationProvider to attempt a bind with user credentials prior to searching for the user.
Edit: You got it working as I was typing this, hah. You must be using a user provider that's not LDAP? I'm going to re-open as this is still a feature I think would be handy for those wanting to use the LDAP user provider. And you shouldn't have to provide an empty username/password.

I have the same problem, I would like to use this configuration to log in and then retrieve the data from the DB.
But it does not seem possible to get username and password from the login form.
I need to add the bind_format uid=username too...

@Xeyos88 I'm not sure that's the same problem? This issue this is about removing the need to enter a username/password in the LdapTools domain config in config.yml, and instead just rely on the username/password for both the LDAP user provider search and then the bind for the authentication provider.
Unless you're talking about using the user supplied username/password from the login form and then using those some credentials for subsequent LDAP calls after they login? This is possible, but you need to utilize the events properly to store the user credentials so you can use it later.
Or maybe I'm just misunderstanding your request?
Anywho, I should be able to get around to some improvements soon. Busy with work and moving apartments lately. Should have more free time soon.

Yes, what I mean is just based on the username and password of the user. Because entering your password and username in config.yml, it looks like your user password is ignored.

Partially resolved with https://github.com/ldaptools/ldaptools-bundle/commit/05b46e81feacc2847c8a9297b23286003c0f82d1. That was the easy part anyway. This makes it possible to not need a username/password for the domain configurations. However, this only helps if you're using this bundle for the authentication piece, and not the user provider piece too.
Still thinking about how to handle the rest.

Ok, this is resolved now with this addition too https://github.com/ldaptools/ldaptools-bundle/commit/396fc40758f8180333703519bb6e692c3f59a8ac. Now all that is technically required for a domain config is a domain name.  It will still work for LDAP authentication and the the LDAP user provider. This is currently Guard only. I still need to look into the other LdapAuthenticationProvider.
Also, this currently requires the master branch of LdapTools. As I had to make a change to the requirements of the DomainConfiguration class. I will need to tag a new version there and then bump the version here.

Closing. I have bumped the required LdapTools version (which was needed for this), and both the LDAP Guard and Authentication Provider support using user supplied credentials for the user provider (if using this bundles LdapUserProvider). So now the domain config username/password is truly optional (depending on your needs and how you want to configure this anyway).
I have tagged a new version of this bundle. Let me know if you have any issues.


feat: Implement io.RuneScanner

Add a UnreadRune method to implement the io.RuneScanner interface. UnreadRune stores the last read rune and allows the reader to unread the rune. Only the last read rune can be unread.
Fixes #6

Codecov Report

Merging #29 (c15cb5a) into main (e95799d) will decrease coverage by 3.67%.
Report is 1 commits behind head on main.
The diff coverage is 77.77%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #29      +/-   ##
==========================================
- Coverage   96.05%   92.39%   -3.67%
==========================================
  Files           1        1
  Lines          76       92      +16
==========================================
+ Hits           73       85      +12
- Misses          2        5       +3
- Partials        1        2       +1

Files
Coverage Δ

reader.go
92.39% <77.77%> (-3.67%)
:arrow_down:


Deprecated github actions

security-scan
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, github/codeql-action/upload-sarif@v2. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.Show more
security-scan
CodeQL Action v2 will be deprecated on December 5th, 2024. Please update all occurrences of the CodeQL Action in your workflow files to v3. For more information, see https://github.blog/changelog/2024-01-12-code-scanning-deprecation-of-codeql-action-v2/Show more
verify
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, actions/setup-java@v3, actions/cache@v3, <EMAIL_ADDRESS><EMAIL_ADDRESS>scacap/action-surefire-report@v1, actions/upload-artifact@v3, <EMAIL_ADDRESS>For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Partly solved by PR #305
Left over :
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/setup-java@v3, actions/cache@v3, <EMAIL_ADDRESS><EMAIL_ADDRESS>scacap/action-surefire-report@v1, <EMAIL_ADDRESS>For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

pull request #325 will solve some more issues.
Last deprecated message is related to<EMAIL_ADDRESS>A pull request for this action is ready for review.

issues are solvedd


Sleep workload can use distribution sampling

This refactors the Sleep workload so that users have a variety of options for using it. Before, the Sleep workload could either accept a number of milliseconds to sleep the thread, or it would generate a number less than a given max.
Now, users still have the option of providing a simple number of milliseconds as before, but they also have the option of drawing from a uniform distribution with min and max, a Poisson distribution with a given mean (especially useful for simulating multiple users on a cluster), or a Gaussian distribution with a mean and standard deviation. This model is extensible to other distributions in the future should users require.
The distribution functionality is built using the Breeze library.

@showermat @cin Your code review comments are welcome!

Codecov Report

Merging #60 into master will increase coverage by 0.6%.
The diff coverage is 97.82%.

@@            Coverage Diff            @@
##           master      #60     +/-   ##
=========================================
+ Coverage   87.52%   88.12%   +0.6%
=========================================
  Files          26       26
  Lines         521      556     +35
  Branches       17       19      +2
=========================================
+ Hits          456      490     +34
- Misses         65       66      +1

Impacted Files
Coverage Δ

...bm/sparktc/sparkbench/utils/GeneralFunctions.scala
32% <100%> (-8.75%)
:arrow_down:

.../workload/exercise/PartitionAndSleepWorkload.scala
100% <100%> (ø)
:arrow_up:

...parktc/sparkbench/workload/ml/KMeansWorkload.scala
87.27% <100%> (ø)
:arrow_up:

...m/sparktc/sparkbench/workload/exercise/Sleep.scala
97.87% <97.61%> (+7.87%)
:arrow_up:

Continue to review full report at Codecov.

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


Crash on server startup when used with ServerCore

MC 1.17.1
Fabric API 0.40.8
Better nether map 1.5.0
ServerCore 1.2.1
When trying to use ServerCore together with Better nether map, the server crashes on startup. Initially opened the issue on ServerCore's github, here, thinking it was an incompatibility between ServerCore and Promenade, but the author discovered that it's actually Better nether map causing it: https://github.com/Wesley1808/ServerCore-Fabric/issues/2#issuecomment-945108164. Removing Better nether map lets the server launch just fine.
Log: latest.log

I've opened up the latest JAR and changed the version requirements so it works with 1.18.1, just thought I'd let you know it still has an issue with the latest servercore version 1.2.6. Seems to work fine without it though, but I didn't actually make a map to test it.

@pahanakun could you try if this issue is still present in version 2.0.0? I refactored the mixins to be much less intrusive.

Thanks for the quick test! It seems like the mixins don't work in the exported version. I'll look into it.

I can't reproduce the error with just fabric API 0.47.10. Could you try to see if the error persists if you only use nethermap, fabric-api and cloth-config?

The issue never happened with just Better nether map, it happens when Server core is also installed.

I found the issue, push a new build right new.

Could you try again with 2.0.1?

Odd, now the client can start just fine with Server core + Better nether map, but the server shuts down claiming there's hard incompatibility with Server core: https://gist.github.com/Footage2-Amply-Pounce/b9a13091e5ebf2f7b84fdcbd8ffe9a2d

Oh, I didn't remove the incompatibility from the mod.json :smile:
But it's a good sign that it's able to get to that point.

2.0.2 pushed with fdc4ad6de604ac982c49f1467100a01d7896d91e

Yep, now everything works. Thanks!


Update Grandchase

Game Title
Grandchase
Status of the Anti-Cheat
⭐ Supported
Tinkering Steps
It works out of the box without any tinkering.
I don't think the developers made any comment on it or if it's possible to verify without trying it but I'm playing it just fine currently and there are protondb reports of it working.
Proof of Mention
https://www.protondb.com/app/985810

as of the latest update on their steam page they addressed it and officially support it for steam deck.
https://store.steampowered.com/news/app/985810?emclan=103582791470333051&emgid=3861338313403449561


Release/0.14.1

This release introduces greater flexibility for custom integrations and general improvements to CLI handling.
Changes

Added support for custom integration paths with the -i <path-to-integration> CLI argument.

Can be used with commands like fetch, start, build:app, etc.
Defaults to the integration directory if the argument isn't specified, ensuring backward compatibility.

Improvements

Enhanced CLI command management:

Switched to yargs for improved CLI parsing.
Each command now has a dedicated handler file for better modularity.

Improved the docs app build process:

Introduced a cleanup procedure that ensures only files present in the working directory are included in the final build.

Looks great to me.  I've tested all of the cli commands and they all work as expected.  The Integration flag seems to work great too.  Lets release it.


Enh/matrix actions

here's the first try;
Note that the action (ex_C2_linear.jl) is not given by
x → x+y
y → x-y

but rather normalized (or rather: orthonormalized)
x → (x+y)/√2
y → (x-y)/√2

This nicely extends to an actual action on larger basis (modulo numerics).
I see several problems arising here: if features/their images are not orthogonal (whatever that means) this code has no chance of working in general (or so I think);
should we then vectors when we compute their action?
there are a few more things I guess, but I'm too tired now, and will be arriving home in 30 minutes, so time to wrap it up ;)
@tweisser @blegat

@blegat I should note that I simplified somehow the API compared to what we discussed yesterday, but of course this is just a first try ;)

I fixed the issue with Julia v1.0. I guess it's important that the basis is linearly independent. It probably also needs to be orthogonal, not sure.

thanks for those fixes; but it seems that either we should drop this InducedActionHomomorphism, or replace those type methods by functions.
I'll try to play with the dihedral group later in the evening

@blegat I tried to fix DihedralAction in SOS, but I ran into some trouble.  Could you have a look at my branch?

ok, I'll create a testset based on the C2 example and once coverage is high enough i'll merge

@blegat ready to register?

Almost, one last detail :)


Could not find module 'tiledbsoma.dll' (or one of its dependencies). Try using the full path with constructor syntax

Describe the bug
when I install by : pip install -U cellxgene-census, get error
Could not find module 'tiledbsoma.dll' (or one of its dependencies). Try using the full path with constructor syntax
A clear and concise description of what the bug is.
Collecting cellxgene-census
Downloading cellxgene_census-1.0.0-py3-none-any.whl (11 kB)
Collecting s3fs
Downloading s3fs-2023.5.0-py3-none-any.whl (28 kB)
Requirement already satisfied: certifi in d:\anaconda\lib\site-packages (from cellxgene-census) (2022.12.7)
Collecting tiledb>=0.21.3
Downloading tiledb-0.21.3-cp310-cp310-win_amd64.whl (5.2 MB)
---------------------------------------- 5.2/5.2 MB 3.4 MB/s eta 0:00:00
Requirement already satisfied: numpy<1.24,>=1.21 in d:\anaconda\lib\site-packages (from cellxgene-census) (1.23.5)
Requirement already satisfied: requests in d:\anaconda\lib\site-packages (from cellxgene-census) (2.28.1)
Requirement already satisfied: typing-extensions in d:\anaconda\lib\site-packages (from cellxgene-census) (4.4.0)
Requirement already satisfied: anndata in d:\anaconda\lib\site-packages (from cellxgene-census) (0.9.1)
Collecting tiledbsoma==1.2.2
Downloading tiledbsoma-1.2.2.tar.gz (146 kB)
---------------------------------------- 146.5/146.5 kB ? eta 0:00:00
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'done'
Requirement already satisfied: scipy in d:\anaconda\lib\site-packages (from cellxgene-census) (1.10.0)
Requirement already satisfied: scanpy>=1.9.2 in d:\anaconda\lib\site-packages (from tiledbsoma==1.2.2->cellxgene-census) (1.9.3)
Requirement already satisfied: pyarrow>=9.0.0 in d:\anaconda\lib\site-packages (from tiledbsoma==1.2.2->cellxgene-census) (12.0.0)
Collecting attrs>=22.2
Using cached attrs-23.1.0-py3-none-any.whl (61 kB)
Requirement already satisfied: numba==0.56.4 in d:\anaconda\lib\site-packages (from tiledbsoma==1.2.2->cellxgene-census) (0.56.4)
Requirement already satisfied: pandas in d:\anaconda\lib\site-packages (from tiledbsoma==1.2.2->cellxgene-census) (1.5.3)
Collecting somacore==1.0.1
Downloading somacore-1.0.1-py3-none-any.whl (32 kB)
Requirement already satisfied: packaging in d:\anaconda\lib\site-packages (from tiledb>=0.21.3->cellxgene-census) (22.0)
Requirement already satisfied: setuptools in d:\anaconda\lib\site-packages (from numba==0.56.4->tiledbsoma==1.2.2->cellxgene-census) (65.6.3)
Requirement already satisfied: llvmlite<0.40,>=0.39.0dev0 in d:\anaconda\lib\site-packages (from numba==0.56.4->tiledbsoma==1.2.2->cellxgene-census) (0.39.1)
Requirement already satisfied: natsort in d:\anaconda\lib\site-packages (from anndata->cellxgene-census) (8.3.1)
Requirement already satisfied: h5py>=3 in d:\anaconda\lib\site-packages (from anndata->cellxgene-census) (3.7.0)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in d:\anaconda\lib\site-packages (from requests->cellxgene-census) (1.26.14)
Requirement already satisfied: charset-normalizer<3,>=2 in d:\anaconda\lib\site-packages (from requests->cellxgene-census) (2.0.4)
Requirement already satisfied: idna<4,>=2.5 in d:\anaconda\lib\site-packages (from requests->cellxgene-census) (3.4)
Requirement already satisfied: aiohttp!=4.0.0a0,!=4.0.0a1 in d:\anaconda\lib\site-packages (from s3fs->cellxgene-census) (3.8.4)
Collecting fsspec==2023.5.0
Downloading fsspec-2023.5.0-py3-none-any.whl (160 kB)
------------------------------------- 160.1/160.1 kB 10.0 MB/s eta 0:00:00
Collecting aiobotocore~=2.5.0
Downloading aiobotocore-2.5.0-py3-none-any.whl (72 kB)
---------------------------------------- 72.7/72.7 kB 3.9 MB/s eta 0:00:00
Collecting aioitertools>=0.5.1
Downloading aioitertools-0.11.0-py3-none-any.whl (23 kB)
Requirement already satisfied: wrapt>=1.10.10 in d:\anaconda\lib\site-packages (from aiobotocore~=2.5.0->s3fs->cellxgene-census) (1.14.1)
Collecting botocore<1.29.77,>=1.29.76
Downloading botocore-1.29.76-py3-none-any.whl (10.4 MB)
---------------------------------------- 10.4/10.4 MB 7.4 MB/s eta 0:00:00
Requirement already satisfied: yarl<2.0,>=1.0 in d:\anaconda\lib\site-packages (from aiohttp!=4.0.0a0,!=4.0.0a1->s3fs->cellxgene-census) (1.9.2)
Requirement already satisfied: aiosignal>=1.1.2 in d:\anaconda\lib\site-packages (from aiohttp!=4.0.0a0,!=4.0.0a1->s3fs->cellxgene-census) (1.3.1)
Requirement already satisfied: async-timeout<5.0,>=4.0.0a3 in d:\anaconda\lib\site-packages (from aiohttp!=4.0.0a0,!=4.0.0a1->s3fs->cellxgene-census) (4.0.2)
Requirement already satisfied: multidict<7.0,>=4.5 in d:\anaconda\lib\site-packages (from aiohttp!=4.0.0a0,!=4.0.0a1->s3fs->cellxgene-census) (6.0.4)
Requirement already satisfied: frozenlist>=1.1.1 in d:\anaconda\lib\site-packages (from aiohttp!=4.0.0a0,!=4.0.0a1->s3fs->cellxgene-census) (1.3.3)
Requirement already satisfied: pytz>=2020.1 in d:\anaconda\lib\site-packages (from pandas->tiledbsoma==1.2.2->cellxgene-census) (2022.7)
Requirement already satisfied: python-dateutil>=2.8.1 in d:\anaconda\lib\site-packages (from pandas->tiledbsoma==1.2.2->cellxgene-census) (2.8.2)
Requirement already satisfied: session-info in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (1.0.0)
Requirement already satisfied: seaborn in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.12.2)
Requirement already satisfied: joblib in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (1.1.1)
Requirement already satisfied: tqdm in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (4.64.1)
Requirement already satisfied: networkx>=2.3 in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (2.8.4)
Requirement already satisfied: scikit-learn>=0.22 in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (1.2.1)
Requirement already satisfied: statsmodels>=0.10.0rc2 in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.13.5)
Requirement already satisfied: patsy in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.5.3)
Requirement already satisfied: umap-learn>=0.3.10 in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.5.3)
Requirement already satisfied: matplotlib>=3.4 in d:\anaconda\lib\site-packages (from scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (3.7.0)
Requirement already satisfied: jmespath<2.0.0,>=0.7.1 in d:\anaconda\lib\site-packages (from botocore<1.29.77,>=1.29.76->aiobotocore~=2.5.0->s3fs->cellxgene-census) (0.10.0)
Requirement already satisfied: pyparsing>=2.3.1 in d:\anaconda\lib\site-packages (from matplotlib>=3.4->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (3.0.9)
Requirement already satisfied: cycler>=0.10 in d:\anaconda\lib\site-packages (from matplotlib>=3.4->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.11.0)
Requirement already satisfied: pillow>=6.2.0 in d:\anaconda\lib\site-packages (from matplotlib>=3.4->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (9.4.0)
Requirement already satisfied: fonttools>=4.22.0 in d:\anaconda\lib\site-packages (from matplotlib>=3.4->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (4.25.0)
Requirement already satisfied: kiwisolver>=1.0.1 in d:\anaconda\lib\site-packages (from matplotlib>=3.4->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (1.4.4)
Requirement already satisfied: contourpy>=1.0.1 in d:\anaconda\lib\site-packages (from matplotlib>=3.4->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (1.0.5)
Requirement already satisfied: six>=1.5 in d:\anaconda\lib\site-packages (from python-dateutil>=2.8.1->pandas->tiledbsoma==1.2.2->cellxgene-census) (1.16.0)
Requirement already satisfied: threadpoolctl>=2.0.0 in d:\anaconda\lib\site-packages (from scikit-learn>=0.22->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (2.2.0)
Requirement already satisfied: pynndescent>=0.5 in d:\anaconda\lib\site-packages (from umap-learn>=0.3.10->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.5.10)
Requirement already satisfied: stdlib-list in d:\anaconda\lib\site-packages (from session-info->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.8.0)
Requirement already satisfied: colorama in d:\anaconda\lib\site-packages (from tqdm->scanpy>=1.9.2->tiledbsoma==1.2.2->cellxgene-census) (0.4.6)
Building wheels for collected packages: tiledbsoma
Building wheel for tiledbsoma (pyproject.toml): started
Building wheel for tiledbsoma (pyproject.toml): finished with status 'error'
Failed to build tiledbsoma
Note: you may need to restart the kernel to use updated packages.
error: subprocess-exited-with-error
Building wheel for tiledbsoma (pyproject.toml) did not run successfully.
exit code: 1
[5 lines of output]
running bdist_wheel
Checking: C:\Users\dawei bushen\AppData\Local\Temp\pip-install-cnpsyu3e\tiledbsoma_e2881eba42714a998e29c98e09ab98a5\dist_links\dist\lib\tiledbsoma.dll exists: False
Checking: C:\Users\dawei bushen\AppData\Local\Temp\pip-install-cnpsyu3e\tiledbsoma_e2881eba42714a998e29c98e09ab98a5\dist_links\dist\bin\tiledbsoma.dll exists: False
Could not find module 'tiledbsoma.dll' (or one of its dependencies). Try using the full path with constructor syntax.
error: [WinError 2] 系统找不到指定的文件。
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for tiledbsoma
ERROR: Could not build wheels for tiledbsoma, which is required to install pyproject.toml-based projects
To Reproduce
pip install -U cellxgene-census
Expected behavior
A clear and concise description of what you expected to happen.
Environment
Provide a description of your system and the software versions.
Python 3.10.9 | packaged by Anaconda, Inc. | (main, Mar  1 2023, 18:18:15) [MSC v.1916 64 bit (AMD64)]
Windows-10-10.0.19045-SP0
Additional context
Add any other context about the problem here.

Hello!
Thanks for you interest on Census, unfortunately tiledbsoma which is a central dependency of cellxgene-census is not supported on Windows. A potential and completely untested option to consider is WSL.
If you have access to a Linux/Mac machine I would recommend that. Alternatively you could use the Census for light-weight usage via google colab. For example:
https://colab.research.google.com/drive/1ytioSg1XtBg5vJTlPxiYgjoJC4tBvZkb?usp=sharing#scrollTo=hp6h0_lZJyEv

thank you very much for reply，thats really pity，cellxgene-census is so good for single cell analysis，but i only have windows system。


Test on multi-segment indices?

Tantivy may be using concurrency for a single query even on a single segment.
Maybe, to make the query latency comparisons more fair, we should create a multi-segment index, and use Lucene's concurrent (across segment) search?  This also better matches real-world usage for applications that need to continuously update their indices.

Tantivy may be using concurrency for a single query even on a single segment.

Hmm, I don't think that is the case. I could double-check. In case Tantivy doesn't use more threads (or async IO within single thread) for a single segment, I believe the single-segment setup is a fair and simple in a good way (less variables) setup.

Tantivy may be using concurrency for a single query even on a single segment.

Hmm, I don't think that is the case. I could double-check. In case Tantivy doesn't use more threads (or async IO within single thread) for a single segment, I believe the single-segment setup is a fair and simple in a good way (less variables) setup.

Yeah you are right -- when I watch CPU when do_query is running it is pegged at nearly 100%.


GHC 8.6.5 binary source URL has changed

Checklist

[x] Checked the nixpkgs master branch

[x] Checked the nixpkgs pull requests

Project name
nix search name: ghc

current version:
desired version:
Notify maintainers

maintainers: @MarcWeber @peti
Note for maintainers
Please tag this issue in your PR.

Today I tried to install ghc-8.10.4, but it failed at downloading ghc-8.6.5-x86_64-fedora27-linux.tar.xz: complained about hash mismatch. It seems like URL has changed.

I used the following overlay as a workaround:
let
  overlay = self: super:
    let
      ghc865 = super.haskell.compiler.ghc865Binary;
    in {
      haskell = super.haskell // {
        compiler = super.haskell.compiler // {
          ghc865Binary = ghc865.overrideAttrs (old: {
            src = ghc865.src.overrideAttrs (old2: {
              urls = [
                "https://downloads.haskell.org/ghc/8.6.5/ghc-8.6.5-x86_64-fedora27-linux.tar.xz"
              ];
            });
          });
        };
      };
    };
  pkgs = import <nixpkgs> { overlays = [ overlay ]; };
in
  pkgs.ghc

Should work with #122005.


[X11] Fix window names not supporting UTF-8

Currently, UTF-8 characters don't render correctly in window titles (c.f. screenshots below). This is likely due to the fact that the X11 driver only uses XStoreName, which sets a name in a way that's not really intended for the user to see. This PR fixes that, making it possible to use UTF-8 characters (I tested diacritics and emojis) in the window title.
How ?
In addition to the existing XStoreName call, I also call XChangeProperty to set the _NET_WM_NAME/UTF8_STRING property. This adds one possible point of failure: XChangeProperty takes an int nelements as its last parameter, and the actual length of the string could be bigger than what a c_int can store. In the unlikely event that this happens, a specific error message is returned.
Screenshots (context: I replaced a dash - with an em dash — in the fractal example)
Before:

After:

Feel free to ask me to change a few things if needed, this PR is spontaneous, and I've never got to discuss the issue before.

Great! Thanks :)


Turn old multi-image helpers (sequenceMode, collectionMode, reference strip) into plugins

When they were created originally, they were hacks to allow a little bit of multi-image-ness. Now that we have the full range of multi-image possibilities, they would probably be better as plugins, opening up the field to many other related features as plugins.

:+1:

Note that @atacraft has expressed interest in doing the sequence mode plugin over in #761.

I am currently looking into customizing the position of the Image Reference Strip and would benefit from more customizability options. Defining this component as a plugin might indeed help with that.
@iangilman Are there any updates since this issue was last updated? Or is targeting div.referencestrip and surrounding elements with CSS the way to go?

There have not been any updates... I'd still love for someone to turn it into a plugin, but no one has yet.
Targeting it with CSS is a good start. You can also take a look at the reference strip code... There's not a lot to it.

I did have a look at the reference strip code and noticed something odd: there is the referenceStripPosition option that get's assigned in the reference strip constructor, but seems then ignored when the strip is actually positioned...
@iangilman did I assess that correctly?

Yes, looks like you're correct. Unfortunately the reference strip code hasn't had a lot of love.

One thing to be aware of with the reference strip is that its prototype has been extended with OpenSeadragon.Viewer, so it inherits a lot from that. I don't think position is used in that code though.


Fix outdated environment variable for docker compose

Also removed a deprecated links setting from the docker-compose, since that's not needed any more
Resolves #379

Also removed a deprecated links setting from the docker-compose, since that's not needed any more

Absolutely right, thanks!


Revert "[flutter_tools] fix multiple defines in flutter tooling, web"

Reverts flutter/flutter#54909
Tbr @jmagman

Landing on red to fix build


[BUG] Misalignment on Humanoid-v3

Reported by rl_games
Initial result reported by @Benjamin-eecs

envpool v3 train gym v3 test
gym v3 17 step, reward ~82
envpool v3 1001 step, reward ~10000, but has variance (maybe not fix seed?)
gym v3 train envpool v3 test
gym v3 1000 step, reward ~6200
envpool v3 29 step, reward ~144

For Humanoid env, there exists some differences in cost calculation: humanoid-v3, humanoid-v4
Also, find ant v3-v4 has bug too: ant-v3, ant-v4


adding spin to path

Signed-off-by: MacKenzie Olson<EMAIL_ADDRESS>Content must go through a pre-merge checklist.
Pre-Merge Content Checklist
This documentation has been checked to ensure that:

[ ] The title, template, and date` are all set
[ ] File does not use CRLF, but uses plain LF (hint: use cat -ve <filename> | grep '^M' | wc -l and expect 0 as a result)
[ ] Has passed bart check
[ ] Has been manually tested by running in Spin/Bartholomew (hint: use PREVIEW_MODE=1 and run npm run styles to update styling)
[ ] Headings are using Title Case
[ ] Code blocks have the programming language set to properly highlight syntax and the proper copy directive
[ ] Have tested with npm run test and resolved all errors

Added to PATH. @mikkelhegn would be good to get your review given 822

I'm a little concerned with this as it might break a flow which is deliberately very hard to break. Not sure if everyone can run the sudo command. Can we somehow make it optional by adding it in a quote section or but it in the "Learn more".
I think the real way to solve this is through https://github.com/fermyon/spin/issues/641 and then make the quickstart use those.

Let me know if I'm too much of a chicken :-)

I'm aligned with that thought process - we may lose some users who don't have the ability to run sudo if we put PATH in the mainstream directions.
I really like how Nomad's UI on their install options . We should do something like once https://github.com/fermyon/spin/issues/641 is completed

@tpmccallum ☝🏻

rustup seems to be able to add the Rust tooling to PATH without sudo, by installing into ~/.cargo, then adding . "$HOME/.cargo/env" to .bashrc (which in turn adds ~/.cargo/bin to PATH).  Makes the installer a bit more complicated of course...

Going to hold off merging until we have a complete installation story


Add nosection flag to task create

Current dependencies on/for this PR:

main

PR #539   👈

This comment was auto-generated by Graphite.


Elastic APM crashes when trying to inspect hits from queries while track_total_hits is False

Describe the bug:
The Elastic APM instrumentation for Elasticsearch tries to get total number of hits in the results of a query but if the track_total_hits is set to False the result.body['hits'] does not have a total key.
Fails at this line exactly with a KeyError('total'): https://github.com/elastic/apm-agent-python/blob/8b22d6a910ceda6587b99e47d8b3c9fa95c8d490/elasticapm/instrumentation/packages/elasticsearch.py#L180
To Reproduce

Instrument your python code with ElasticAPM, you don't even need to have the APM server up it crashes while collecting the data
Run any search query with track_total_hits set to False
client.search(params={'track_total_hits': False}, **query_body)

Environment (please complete the following information)

OS: Linux
Python version: 3.9
Framework and version [e.g. Django 2.1]: Flask
APM Server version: Irrelevent
Agent version: 6.13.0

Additional context
This will crash no matter the config. We've reverted our code to use ElasticAPM 6.12 to make it work again.

Thanks for the report! This is fixed in #1687 and we should have a 6.13.1 release out soon.


set the header in default_headers if defined there

@oreoshake how do you feel about this as a fix for #130 ? Seems to work fine for me when I test it manually, and only overwrites a header in config.action_dispatch.default_headers if we're explicitly setting it with secureheaders.
If it looks like an okay solution I'll add in specs.

Hm, something else I just thought of is the skip_before_filters. Doing, for example skip_before_filter :set_x_frame_options_header will cause it to return to the Rails default of SAMEORIGIN as opposed to removing the header, which would probably be what you expect.

Good point. We could clear just the headers that this gem sets, and then things would be have as expected.

Good idea, @oreoshake. I've done that in the initializer and it seems to work fine. I've also added another fixture for Rails 4 matching what you had for the others, but setting the headers that Rails sets to something else to ensure this fix is working.
If this looks good, let me know if you'd prefer me to squash the commit history.

HPKP headers are in now.

Hmm that test failure might be annoying. Rails 4 doesn't support 1.8.7 and it generates a mixed bag of hash syntaxes. Would you mind converting those? I can take a stab at it, but probably won't get to it.

No problem, I'll do that later today.

Luckily the only thing in the Rails 4 fixture not using the hash rocket was the route, so it passes on 1.8.7 now.

:sparkles:

I'll release a gem tomorrow


Only run completion checks for request bodies, if we have

actually seen all of the body. In case ProcessPartial is configured
and our input filter only processed part of the request, checking
for a complete request body makes no sense.
See issue #2093.

There is a discussion on issue #2093 about this pull request.


Make close icon hyperlink (a tag) instead of span

With (close-icon) being span had difficulty get the click working in mobile devices.
Changed it to <a href="#"...

I'm not sure I understand how an  or a  will behave differently when clicked... Both should have the same area and respond the same way

Semantically, it shouldn't be an  tag, because it's 'href' attribute has no meaningful value. Might be better to make it a <button> element if  causes onclick problems.

Right, but <button> has user-agent styling that we don't want.
Closing this as no reproducible issue with current code.


[not an issue] godot 4 psvita export template when?

i was wondering if a godot 4 ps vita export template is being made?

afaik not possible, godot 4 uses a different render pipeline that isnt cross compatible.

Godot 4 has its rendering engine rewritten and a bunch of code and features are not compatible between 3.x and 4.x. I think this is because of the Forward renderer.
I believe it would be possible if the other rendering engines are used instead.

It would be possible, but it would be a lot of extra work to make an essentially new rendering backend from scratch for the Vita for Godot 4.
Unlike Godot 3, 4 doesn't have any GLES2-ish backends, so one would have to be made and then used either as a base, or directly, for Vita.

That's understandable.


Change the appearance of the GUI #1

8 enthusiasm points for working on making the GUI look better, not able to merge since the code was already updated.

!bounty 8


Browser not support

hello
navigation bar not show in mozilla browser any one help me

Hi,
I checked Mozilla Firefox version 50.1.0 and Windows 10 Operation System, and i couldn't see any error about this. Could give more info your browser and system?


Adding Support for Unix OHI

ref: PR #14
Adding Unix host entity type based on newrelic-unix-monitor OHI.

Closing this issue, since support for this entity type has been added, thanks for the contribution!


Add tests for supported functionality

Because otherwise how would we now that we don't regress? 🤷♂

Closed in #8


Add support for Ghostty terminal

Add support for Amazon Q in Ghostty

Im working on adding support in #335, also where did all of you see this issue? Seems there are a lot of 👍


Pyinstaller pipeline

Contains scripts to generate the new builds.
Note: Librosa 0.9.2 has to be used or it won't work, see my issue here.

Thanks


GEODE-5604: Fix over-zealous fix for adding NOTICE to jar manifest

Removal of a bad doLast around the insertion of the default NOTICE,
only if the module did not have its own file
Co-authored-by: Robert Houghton<EMAIL_ADDRESS>Co-authored-by: Patrick Rhomberg<EMAIL_ADDRESS>Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[x] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[x] Is your initial contribution a single, squashed commit?

[x] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

LGTM, please commit and cherry-pick to release/1.9.0.  @sboorlagadda


Updating OAO deps to support Go 1.22

What type of PR is this?
(maintenance)
What this PR does / why we need it?
This PR updates the dependencies for OAO to support Go 1.22. Additionally there are boilerplate changes too. Functional tests to reconcile the ocmagent resource was done and it worked fine.
Which Jira/Github issue(s) this PR fixes?
Fixes # OSD-25349
Special notes for your reviewer:
Pre-checks (if applicable):

[x] Tested latest changes against a cluster
[x] Included documentation changes with PR

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

Project coverage is 64.22%. Comparing base (1c7db7a) to head (cc0e560).
Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #147   +/-   ##
=======================================
  Coverage   64.22%   64.22%
=======================================
  Files          22       22
  Lines        1504     1504
=======================================
  Hits          966      966
  Misses        459      459
  Partials       79       79

Thanks, @ravitri for the PR.
/lgtm


"Is Missing" handling by Nickel

Automatically add "Is Missing" statuses for all characters

StatusMeta.deckToMissingStatus is important

Done in ddc21d0e6cbd61951e31b7ff2c6b4cb65e0d24b9.


Another backwards compatibility break propagating through projects: rename logrus_syslog package to syslog - PROPOSAL

Another pull request .. https://github.com/sirupsen/logrus/issues/108 about nomenclature.. and https://github.com/sirupsen/logrus/pull/587 renames logrus_syslog .. breaking all packages that use it.
# github.com/osrg/gobgp/gobgpd
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:30: syslog redeclared as imported package name
	previous declaration at /ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:21
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:53: undefined: "github.com/sirupsen/logrus/hooks/syslog".Priority
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:56: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_KERN
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:58: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_USER
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:60: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_MAIL
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:62: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_DAEMON
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:64: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_AUTH
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:66: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_SYSLOG
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:68: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_LPR
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:70: undefined: "github.com/sirupsen/logrus/hooks/syslog".LOG_NEWS
/ws/wrk/src/github.com/osrg/gobgp/gobgpd/util.go:70: too many errors

I really am surprised that after the last fiasco with renaming this repo that I am dealing with yet another rename today. This time breaking all dependencies using the "syslog" package in exchange for the following value- justified by @dmathieu:

Package names shouldn't be using underscores. There is also nothing
wrong with naming this package syslog. People can include it with any
name they wish.

Yes- people can include it with any name they wish. So the people who are bothered by the name can use "logrus". I have no idea how you can justify breaking dependencies to remove an underscore....?
Anyways- this leads me into a proposal for @sirupsen, that is to FREEZE this API for master and please stop breaking projects that depend on this library. It is wildly popular, with that comes the responsibility to be stable. Incompatible API changes should be weighed very heavily and well thought out. "Just vendor" isn't an option, the ship has sailed and logrus predates some of the best practices that have emerged in the Go community. I believe it needs the stability to the standard libary.
A new import path and version could be made for a "cleaned" up version- I suggested some time ago in https://github.com/sirupsen/logrus/issues/451#issuecomment-264241243 for a logrus organization for this purpose, or something like gopkg.in. I think it would be beneficial to all library consumers though to find some form of resolution for stability in logrus.

Oh- and of course I propose immediately reverting #587 before it's propagated into peoples workspaces as they update and really cause a mess. These changes can take a while to emerge as we saw with the last rename so the earlier you revert the less impact in the long run.

I think this is a legit concern, @dmathieu what was the motivation for the change?

Hi @cstockton, thank you for taking the time to write this up.
As one of the maintainers of logrus and the one reviewing the change you refer to, I'd like to add my thoughts on this. Before getting into details, I'd like to repeat that I'm thankful for your input but would also ask you for a constructive discussion. I understand that you're angry about having to change import paths again though.
In general, we should all stick to the convention that binaries vendor their dependencies (and/or contain requirement files that are managed by a go package manager like dep). In my experience, logrus isn't the only library that changes its exported types and packages. Nevertheless, I understand that vendoring imposes other challenges.
Libraries on the other hand should (this is only my opinion, not necessarily an agreed-upon convention) not depend on a specific logging library and keep dependencies to third-party libraries as limited as possible.
In order to keep change possible at all, I'm currently 👍 for your suggestion to freeze the current API in master and start working in branches that then are referred to using gopkg.in. I will definitely take some time to discuss this with @dmathieu and @sirupsen in the next few days.
One thing that I don't understand is how you ended up in the situation of your error message though. Could you please elaborate on that?
I looked at the project you're referring to and found a "Gopkg.toml" that contains a constraint to logrus in version 1.0.2. Did you run dep ensure before or do you rely on the logrus version from your $GOPATH? Did you stumble upon this before the constraint was updated to point to the new logrus version?
Regarding your question @sirupsen: I'm pretty sure that @dmathieu wanted to get rid of the old issue https://github.com/sirupsen/logrus/issues/108 and followed the suggestion in there.

Before getting into details, I'd like to repeat that I'm thankful for your input but would also ask you for a constructive discussion. I understand that you're angry about having to change import paths again though.

Not sure what about my post isn't constructive or what implies I'm angry. As stated I'm surprised to be running into more logrus issues, nothing more or less.

In general, we should all stick to the convention that binaries vendor their dependencies (and/or contain requirement files that are managed by a go package manager like dep). In my experience, logrus isn't the only library that changes its exported types and packages. Nevertheless, I understand that vendoring imposes other challenges.
Libraries on the other hand should (this is only my opinion, not necessarily an agreed-upon convention) not depend on a specific logging library and keep dependencies to third-party libraries as limited as possible.

I understand the position and agree that they should, simple fact is that they don't. Many applications, libraries, tools exist that were written long before dep, and predate vendoring as well. I could go on but I don't think the importance of backwards compatibility really needs justified in the Go ecosystem. I'm not sure about other libraries changing exported identifiers, I've never experienced this myself but would be willing to read through comments from an issue for an exported identifier that changed that has a dependency graph as massive as what logrus has.

One thing that I don't understand is how you ended up in the situation of your error message though. Could you please elaborate on that?
I looked at the project you're referring to and found a "Gopkg.toml" that contains a constraint to logrus in version 1.0.2. Did you run dep ensure before or do you rely on the logrus version from your $GOPATH? Did you stumble upon this before the constraint was updated to point to the new logrus version?

They define a Gopkg.toml, recently yes. But my docker containers that existed long before dep predate this, as well as many projects I've made in the past. I haven't even adopted dep yet and will wait as long as possible to do so, my first experience with dep was having it rm -rf my vendor folder which at least led to https://github.com/golang/dep/issues/552. Even if I loved dep (I don't) and was excited for any opportunity to upgrade things to it as time goes on this becomes an impossible task. It's why backwards compatibility (go1promise) and such exist for highly depended upon libraries (like logrus), so developers don't have to randomly stop all work to upgrade a stable and completed project, subjecting it to test cycles, ci/cd, code review, all the noise along with it.

Would the logrus team accept a pull request for this or will the change remain?

@dmathieu I very strongly disagree.

I don't think reverting the package name change is a good idea. We'll get other people saying they're relying on the latest version and it breaks again.

For every person that complains it was broken and fixed again, there will be much more that report it was broken months from now. If you leave it broken you make sure every single person who has it in their dependency tree is affected. If you revert it the people who have been affected by the change are limited to those who upgraded earliest. We have already seen how these sort of issues take time to cascade through your packages dependency graph, the pain for the users is multiplied by the fact that the longer it takes for them to be impacted the further away the dependency is from their project and more difficult it can be to resolve.

The true issue here is that we're unable to do anything on logrus except basic maintenance due to the impossibility of doing any breaking changes. This is the true thing we need to fix.

The main issue is making backwards incompatible changes on a library which has a massive dependency graph. There are options that could be exercised here that don't involve breaking every users project for nomenclature purity. The value of this change measured against the expense of breaking every single dependency seems impossible to justify from me personally. Hopefully the fact this subpackage is less used will cause less trouble for users down the road.
While I strongly disagree with the Logrus maintainers that it is okay to simply break dependencies without strong justification, I accept it and thank you for at least hearing me out.

Let me rephrase. I, and the other maintainers of logrus ( @seiffert and @sirupsen ) are entirely aware that breaking backward compatibility is entirely shitty.
At this point though, properly working on improving the project will require a version 2.0 which will bring backward-incompatible changes. But we're stuck with it, as we can't bring them to master (they'd be pulled by everybody), and we can't really create a 2-0 branch, as no PRs would be based against it.
Basically, we're at a state where we either bring backward-incompatible changes, or the project slowly dies by not being updatable.
I' slowly starting to feel we should go with the second solution, and possibly start a new repository implementing the hooks API. But giving up like this really sucks.

@dmathieu If you understand it's undesirable and I've yet to see justification for the change I don't understand why you don't want to revert it? I don't agree that you're options are limited here or that there is the slightest hint of contention while quantifying them. This is what I would do:

Revert this change immediately because the longer it exists the more people that will be affected, I've already explained the reasoning above so I won't reiterate.
Adopt the Go1 compatibility promise which means only breaking logrus API if ABSOLUTELY necessary. If someone complains the name of a package or publicly exported identifier is not idiomatic the issue is assigned a 2.0 tag. If someone raises a troublesome security concern that can only be mitigated via a API change- then the code is changed.
Use the logrus organization offered to you to resolve 2.0 tags. This would give the opportunity for sub repos containing plugins / log adapters to be maintained by separate individuals. You may give a completely fresh start for logrus where you can define expectations around backwards compatibility.

All users with the flexibility to immediately change logrus to a newer version to enjoy the improvements can do so early. Without forcing another year of pain as backwards incompatible changes cascade through the dependency graph of projects for users who are not positioned to upgrade immediately. I think Aliases show the importance of API compatibility and how when you have such a large dependency graph at that scale and velocity breaking changes are no longer an option. Logrus is at a much larger disadvantage then Google was even, since in logrus you replace velocity with disparity and remove the ability to update every dependency of a packages change.
My last two cents for @sirupsen I don't want to beat a dead horse or anything just really want to avoid what I see as a pretty awesome project come under anymore heat like the rename. Not when there are other perfectly reasonable options.
-Chris

Use the logrus organization offered to you to resolve 2.0 tags.

How will moving logrus to another organization not be another case of casegate?

@sirupsen To clarify by "use the logrus org" I mean specifically to use it for future development while freezing the API for this repository. I don't know what options github has around keeping issues, stars and so on so I don't have an opinion about the semantics of the move. Only detail I think is important is that the repositories are separate and the current repository remains in tact.
Under this clarification we can see that changing cases gave people one option, stop what they are doing and make changes to their code. While creating a repository in a new organization for a v2.0 logrus and keeping the existing logrus at sirupsen/logrus with stricter compatibility solves all the major pain points:

People can upgrade to the new logrus when they choose to.
The new repo could be used to vet out the design by logrus users who have the flexibility (and desire) to test the new features or changes, allowing those who don't have the luxury for one reason or another to wait until the API is solidified.
Both import paths can live side by side allowing dependencies in your gopath to update at their own paces.
You may defines stricter expectations up front in the new logrus repo- such as you assume users will be using dep. This allows you to make tiny incompatible changes and experiment without frustrating users.


Work with 0 players online

I'm attempting to setup a restart setup with the countdown, but the esb commands dont complete when no one is online

Should work for in the latest release


Add missing "waf configure" step when building from source on Windows

It should be done before the make.bat build test step.

This is covered in the directions already.


Catch 2.0 doesn't work on older macOS Sierra

Catch 2.0 wouldn't work after the update (clicking the app doesn't produce any results; no app on the task bar, no process in activity monitor).
Reverted back to v.1.9.4, now working again.
macOS 10.12.6

Closing in favor of #176


Loading trains and components by CSV

Implement helper methods to load trains and components from a CSV file. This will require some sort of system to identify the 'Type' of component being added, plus any *args and **kwargs that might be specific to that particular component.

This clearly needs to be handled in JSON format


[Avatar] 0.15.2 - Unknown props onKeyboardFocus, iconStyle on  tag

This probably was missed out in react 15.2 prop changes.
Warning: Unknown props `onKeyboardFocus`, `iconStyle` on <img> tag. Remove these props from the element. For details, see https://fb.me/react-unknown-prop
    in img (created by Avatar)
    in Avatar (created by IconMenu)
    in div (created by IconMenu)
    in IconMenu (created by App)
    in div (created by AppBar)
    in div (created by Paper)
    in Paper (created by AppBar)

@halayli We were expecting some warnings to be catched with the latest release.
Do you want to submit PR to fix them?

fyi release of 15.2.1 is significantly better for warnings, but still getting these:
bundle.js:70805 Warning: React.__spread is deprecated and should not be used. Use Object.assign directly or another helper function with similar semantics. You may be seeing this warning due to your compiler.  Trying to access it will result in `undefined` being returned.  Remove these props from the element.  Remove this prop from the element. For details, see https://fb.me/react-unknown-prop
    in div (created by CardText)
    in CardText (created by Explorer)
    in div (created by Card)
    in div (created by Paper)
    in Paper (created by Card)
    in Card (created by Explorer)

hope this helps!

@oliviertassinari I found a couple more. Will submit a PR today/tomorrow.

Looks like IconMenu can't be composed with an Avatar as the current API is designed 😞 .

Any update on this? It seems like this error is still happening when trying to use Avatar with IconMenu

@prescottprue if it is for the iconButtonElement you should wrap it in a <IconButton>, solved it for us and I saw in the documentation that it is required.

@crudh I can't believe I missed that in the docs. Works perfectly, thanks!

@prescottprue Right, I think that we can close this issue. Thanks for the confirmation.

Wrapping is not an option for me, due to the inherent issue with trying to override styles of spans in buttons.
I need a  as an IconMenu button (from react router) or plain old , but using either of these throws this warning, this should be suppressible.


fix: Update DynamoDB Table AttributeName max length to 255

Overview

Description: [rationale/reason for change]
Schema update type: [create, modification, extend, remove]
Services affected:

References

[documentation/forum thread links]

How was this tested?
[Describe what steps were taken to ensure this schema change is correct & necessary]

This is good, thanks!


Replace fetch-mock with nock

fetch-mock has been replaced with nock. Both libraries do basically the same thing. I chose to use nock because the types shipped with fetch-mock were incorrect and they were giving me trouble. But nock also has a nicer API, and it's what we use for mocking fetch in most of our other libraries.

The unit test failure is being caused by a bug in a dependency. Currently investigating how to best solve this; I'll move this back into draft in the meantime.

The bug previously causing tests to fail has been addressed in #341 , which this PR now depends upon.


停词如何添加

您好，如何添加停用词，常见的停词表在哪里可以下载呢

停用词表推荐这个：https://github.com/dongxiexidian/Chinese/blob/master/stopwords.dat

多谢！

@tukeyone  , here is the example for adding the stop words
# build stop word list
def stopwordslist(filepath):
    stopwords = [line.strip() for line in open(filepath, 'r').readlines()]
    return stopwords

def seg_sentence(sentence):
    sentence_seged = jieba.cut(sentence.strip())
    # loading stop word list
    stopwords = stopwordslist("your_stop_word_txt_file")
    outstr = ''
    for word in sentence_seged:
        if word not in stopwords:
            if word != '\t':
                outstr += word
                outstr += " "
    return outstr

Thank you ！ this problem has been solved .


an error

<Please be sure to remove any private information before submitting.>
Repro steps:
<Enter steps to reproduce issue>
Action: cosmosDB.createMongoCollection
Error type: 10107
Error Message: not master
Version: 0.10.0
OS: darwin

This looks like an admin privileges issue AFAICT. There's usually access-control at the collection level.


Studyfield delete and refactoring

Deleting studyfields
bugfixes to thesislist and thesis edit page

Coverage decreased (-1.6%) to 65.784% when pulling 7c4c9cf22882bb61913782402c6946886247ab3f on studyfield_delete into 10b68c34597dfd186a40014685a7af62c9f69384 on master.

Coverage decreased (-1.6%) to 65.784% when pulling c4af54a4949d76d463e2403a8ac4c737cd7155bf on studyfield_delete into 10b68c34597dfd186a40014685a7af62c9f69384 on master.


RTSP Support?

Hello!
When I try to load star a RTSP url the log says "Protocol not found"
There is any way to make this work or Giraffe does not support RTSP at all ?
Thanks!

compile 'com.github.tcking:giraffeplayer2:0.1.16-full'


Add e2e test prototype for Cluster lifecycle API

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Fixed #233 -- Allowed sending html template in updates mail

Closes #233

Changes

Changed the send mass email to EmailMultiAlternatives for more robust functioning.

Type of change

[x] Bug fix
[ ] Feature update
[] Breaking change
[ ] Documentation update

Author Checklist

[ ] Code has been commented, particularly in hard-to-understand areas
[x] Changes generate no new warnings
[ ] Vital changes have been captured in unit and/or integration tests
[ ] New and existing unit tests pass locally with my changes
[ ] Documentation has been extended, if necessary
[x] Merging to main from fork:branchname

@DevilsAutumn I have made the required changes. Please review and let me know if any further modification is required.

LGTM. Second opinion awaiting from @DevilsAutumn

Checkout an approach at https://github.com/djangoindia/djangoindia.org/issues/230#issuecomment-2491682713
We should create a separate template dir containing different email HTML (jinja) templates with place holders and use render_to_string to convert it into customised string to be passed in email_body parameter for send_email function.

@salty-ivy Thanks for review. I'll start working with your approach.

Checkout an approach at #230 (comment)
We should create a separate template dir containing different email HTML (jinja) templates with place holders and use render_to_string to convert it into customised string to be passed in email_body parameter for send_email function.

I have 2 questions:

Are you suggesting that we should not be having update model and be directly sending formatted mail templates ?
By "different email HTML (jinja) templates with place holders" you mean that we should have fixed templates for different workflows like sending updates, communication mail, registration mail etc?

Checkout an approach at #230 (comment)

We should create a separate template dir containing different email HTML (jinja) templates with place holders and use render_to_string to convert it into customised string to be passed in email_body parameter for send_email function.

I have 2 questions:

Are you suggesting that we should not be having update model and be directly sending formatted mail templates ?

By "different email HTML (jinja) templates with place holders" you mean that we should have fixed templates for different workflows like sending updates, communication mail, registration mail etc?

Yes, though we can still have update model for historical record purposes and to store other more relevant meta data. The other way using jinja templates for different type of emails is most robust, memory saving efficient way.

@salty-ivy Writing custom emails provide us more flexibility when writing mails, sending same templates again n again increase the changes of getting mails ignored. So, lets move forward with current approach with some tweaks.
@Yadavanurag13 We can do one thing, Instead of writing complete mail template for updates, we can define a basic html template structure (similar to registration success mail template) beautifying with css but without the body, title and first name added as placeholders. And in update model, we can rename html_template -> email_body and title -> email_subject. We can simply format our email template with custom body, first_name and subject and send it.

@salty-ivy Writing custom emails provide us more flexibility when writing mails, sending same templates again n again increase the changes of getting mails ignored. So, lets move forward with current approach with some tweaks.
@Yadavanurag13 We can do one thing, Instead of writing complete mail template for updates, we can define a basic html template structure (similar to registration success mail template) beautifying with css but without the body, title and first name added as placeholders. And in update model, we can rename html_template -> email_body and title -> email_subject. We can simply format our email template with custom body, first_name and subject and send it.

Wouldn't the custom elements be injected in the template we would still need a fixed and efficient way to emails.
Some elements would always remains the same.
Other custom elements like name, emails and their particular events
Will be injected at render to string time? As context ?

Some elements would always remains the same.

yes few basic structure elements for just the "updates" model.

Other custom elements like name, emails and their particular events Will be injected at render to string time? As context ?

yes.

@Yadavanurag13 We can do one thing, Instead of writing complete mail template for updates, we can define a basic html template structure (similar to registration success mail template) beautifying with css but without the body, title and first name added as placeholders. And in update model, we can rename html_template -> email_body and title -> email_subject. We can simply format our email template with custom body, first_name and subject and send it.

Sure. @DevilsAutumn

@Yadavanurag13 Any updates on this?

@DevilsAutumn Yes, I'm working on it.


TermDebug expression cleanup

General:

\s in vim only matches space and tabs, so extra check for newlines (hopefully matches both unix and dos eol)
trailing spaces fixed again (those are consumed by the group, so don't use that)

COBOL: included periods may occur in numeric assignments, so only drop trailing ones

Thanks @lacygoill for the review!

I'll include it, thanks.

Cool, but a warning @brammool: I've just pushed a last change which fixed a broken assignment in the updated code (was too happy to found out why some expressions did not work to not test that assignment before) - 10 seconds before your message.

I checked, I have the last version.


Prevent tpf.cadenceno from returning zeros for TESScut TPFs

interact() does not work on TESScut TPFs because the CADENCENO column is all zeros (cf. #373).  This will likely be resolved in a few months (cf. https://twitter.com/GeertHub/status/1071172334982094848 ), but for now I propose we merge this workaround.
@gully Can you review, test, and merge?

The current implementation tests if the first cadenceno is 0, are we convinced cadences starting with 0 could not be valid?  What do you think of a check for unique cadences? len(set(cadences)) == len(cadences)  would fail for nan cadences, so would have to be cleaned, which adds unnecessary complexity.

Codecov Report

Merging #375 into master will decrease coverage by 0.01%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #375      +/-   ##
==========================================
- Coverage   91.25%   91.23%   -0.02%
==========================================
  Files          26       26
  Lines        4058     4061       +3
==========================================
+ Hits         3703     3705       +2
- Misses        355      356       +1

Impacted Files
Coverage Δ

lightkurve/targetpixelfile.py
90.47% <75%> (-0.13%)
:arrow_down:

Continue to review full report at Codecov.

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

I tried interact on a tess-cut TPF and it worked fine with this change.


using es6 arrow function

I applied es6 code in test code.
Thank you for creating a good open source project.

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @olramde!

  Generated by :no_entry_sign: dangerJS against 995b2bbfc36badf46f090804d7cbc3905e52351f


Fabio Clustering.

Hello guys,
Can you please relate to #229? I wrote a comment there a week ago and still haven't got an answer.
Thank you,
Ori

Please do not open a new issue if you don't get a response (in a timeframe you expected). Everybody working on fabio is volunteering their time. If you don't get a response, perhaps the question wasn't clear or not something others could relate too. Or perhaps you need a bit more patience as others were busy 😊.

My reply on #229 was a reply on a close issue. That's the reason I open a new one. I'm aware that everyone works here are volunteers. I believe that my question was clear enough 🙂

@orikalinski What exactly are you trying to accomplish?  Why do you want to cluster Fabio?

I'm trying to get HA for my haproxy load balancer. The first instinct was to use floating ip. The issue that I'm using DigitalOcean which only provides public floating ip. I need to run over the private network hence that solution is not working for me. I tried to explore consul, and came across fabio. I tried to understand if I'm missing something and you can use a cluster of fabios, with the round robin distribution instead of the random one. In the #229 mentioned that running multiple fabio services willl do the job and I can only assume it will fit to those who need random distribution. Am I missing something?

Sharing a virtual IP is going to be the most common solution for HA between hosts.  The DigitalOcean floating IP solution should be fine for this use case.
https://www.digitalocean.com/docs/networking/floating-ips/resources/#more-information
It appears that they support active/passive and the ability to only failure once a check has failed which would preserve round-robin routing within an "active" node.  You would only get a reset to that routing if a failover happened.
Outside of a vendor solution such as DigitalOcean's floating IP or a network layer solution like any cast BGP you could look at using OS level solutions like keepalived.  See the following article for an example:
https://tecadmin.net/ip-failover-setup-using-keepalived-on-centos-redhat/

Thank you for you response but as mentioned the floating ip implementation is not the problem, the issue with that is that DigitalOcean doesn't provide private floating ip but only public floating ip. Therefore, I was looking for an alternative.
Anyway, appreciate the response

@leprechau / @orikalinski / @nathanejohnson could this be closed?

@orikalinski,

Therefore, I was looking for an alternative.

You could have DNS point at multiple public IPs, with fabio listening on each. Or you could use a LB from the cloud provider.

closing due to age


Makes the plugin package discoverable

Did you find which was the cause of the plugin not being discoverable?

Yes, it appers there were 2 simple things that caused troubles:

On the package.xml we defined the licence by doing <license file='LICENSE'> BSD 3 Clause </license> and when I was testing the package it gave me problem the file='LICENSE' so I removed it.
I noticed that on the setup.cfg the [develop] and [install] were using snake_case ('_') instead of hyphen ('-') on the naming of the variables (I'm not sure this actually makes a difference but I left it with hyphen since that is how it is created when doing ros2 pkg create --build-type ament_python <package_name>).

Note that there are some changes that I think aren't related to the PR's purpose(at least pr's title.)

Linters being added
resources being added.
You are right, I forgot to delete a couple of things. For the resource I changed the name of the .ui file to keep consistency with other rqt plugins.


Update README.md for Java and already added the Binary Tree code in DS folder of Java

Please read how to contribute first!
Description
Submission description here
Checklist

[x] I've checked the issue list BEFORE deciding what to submit
[x] I've read the contribution guidelines
[x] I've edited the README.md link to my code

Don't forget to visit our website!
Feel free to add this badge after your submission is accepted!

Completed all the things. Now I understood , I guess :)))

closing


merging with pob, refactor

Guiding by https://github.com/Vilsol/poe-dat-diff

@SnosMe ready for review


[TIR] CSE-TIR Pass - More deterministic behavior

Running the CSE-TIR pass led to some variation in lowering to TIR from the same schedule multiple times. I tracked this down to iterating over an unordered map. I think having consistency in lowering to TIR is a desirable property to have so I made the offending code a little better in this regard.
Example test script:
https://github.com/AndrewZhaoLuo/TVM-Sandbox/blob/19284ddbd6bb28af61c0c2aa8bb334c5c53731a7/tir/test_inconsistent_tir_lowering.py#L1
^--- Running the above off main produces different hashes every time, running after this diff it produces the same hash.
There may be more examples of non-determinism in CSE-TIR but this is what I found for now 👀

cc some folks from https://github.com/apache/tvm/pull/9482: @masahi @FranckQC @mbs-octoml @jroesch

@AndrewZhaoLuo maybe we can also solve this by changing the comparison functor in
https://github.com/apache/tvm/blob/09f7be28a1ed7e629ddc0c9fcf19d4feace05dd4/src/tir/transforms/common_subexpr_elim_tools.h#L54

Hmm, so the unordered map doesn't have an ordering so all it needs is some way of determining equality of elements.
An alternative would be std::map which does have a notion of ordering (and you can define a comparator). However, it's performance characteristics are different (usually self-balancing binary tree so O(log n) lookup instead of O(~1)).
In general though yeah, we need to be on the lookout for iterating over unordered collections cause it will be non-determinstic. I'll try refactoring this sometime later, though need to read more about performance (it's already kind of slow when processing a statement with 100 common subexpressions).

Hmm, so the unordered map doesn't have an ordering

The actual order doesn't matter, does it? unordered_map doesn't store elements in a sorted order, but it does have some ordering internally determined by the comparison functor. And what we need is just a fixed order, not necessarily the sorted order, so I think unordered map should do the job.

ah sorry, I was confused with something, "but it does have some ordering internally determined by the comparison functor" is not correct.

@AndrewZhaoLuo I think we can merge this as is for now. The CI failed on the mac os, probably need to kick another job.

Hi,
Sorry I couldn't discuss this with you last Thursday/Friday. Thanks for improving the CSE!
Yes, indeed, iterating through the hash table will not necessary lead to accessing its elements always in the same order. That's because the iteration order depends on the hashes (and we use structural_hash for that), which themselves are based on pointers, so different run will give different addresses, which will give different hashes, and thus a different order in which elements are accessed.
I guess it is not an issue as far as the CSE is concerned, because after producing this hashtable, we use it to produce a vector of semantic entities (which are pairs <expr, count>).
The main loop of the CSE will later iterate through the elements of this vector.
But before that, this vector gets sorted by the size (called "complexity") of the expression (the first component).
So the order of the end result (the vector) is non-deterministic only for elements with the same size / complexity, for which it does not matter (again, only for the CSE) in which order we common them. (i.e. it should not add or remove opportunities for commoning more later). Said differently, this non-determinism should appear for orthogonal choices.
I guess as in:
Mem[i1] = (a+b)+ (c+d);
Mem[i2] = a+b;               // We can common this one before or after
Mem[i3] = c+d;               // this one, it does not matter for the CSE
Mem[i4] = (a+b) + (c+d) + e;

for which we could produce:
let cse_var_2 = a+b in
let cse_var_3 = c+d in
let cse_var_1 = cse_var_2 + cse_var_3 in
Mem[i1] = cse_var_1;
Mem[i2] = cse_var_2 in
Mem[i3] = cse_var_3 in
Mem[i4] = cse_var_1

Or the alternative version were (c+d) gets introduced before (a+b).
I did not think that having this level of non-determinism would be an issue, but you're clearly right that its better to always produce exactly the same resulting TIR code, that just makes testing easier.
Your way of making it deterministic (by first transitioning the hashtable into an array, which you then sort using the actual syntax that the expressions represent) is perfectly fine to me.
According to the doc about structural_hash ( here : https://tvm.apache.org/docs/reference/api/python/ir.html ), it seems an alternative could have been to set map_free_vars to true, as that's the reason the hashes use pointers. If that was the only place were addresses are used in the hashes, it should make everything deterministic too. I'll see if that works too, out of curiosity.
Many thanks for having spotted that and for having fixed it!
Kind regards,
Franck


[Feature request] Add our own preset with reasonable defaults

Right now, each rule must be set inside the rules section of the .eslintrc configuration file.
We could make a default preset with the following config:
"rules": {
  "tailwindcss/classnames-order": "warn",
  "tailwindcss/no-custom-classname": "warn",
  "tailwindcss/no-contradicting-classname": "error"
}

Available on v1.10.0


Questionable Celebs

Describe the bug
Some people should not be shown
To Reproduce
Look for non movie people
Expected behavior
Look if the person has a relevant profession
[actor, director, writer,...], please check which are the names of the occupations which are ledgit.

.5h for review logged


Intellij doesn't recognize imports from @com_google_protobuf

Despite multiple "Sync" runs, GoLand does not recognize its @com_google_protobuf dependencies. Example:

Running:

GoLand 2021.2
Bazel Plugin 2<IP_ADDRESS>.2-api-version-212
Protocol Buffers Plugin 212.4746.57

The relevant target in our BUILD.bazel file:
load("@rules_proto//proto:defs.bzl", "proto_library")

proto_library(
    name = "pb_proto",
    srcs = ["mymessage.proto"],
    visibility = ["//visibility:public"],
    deps = [
        "@com_google_protobuf//:timestamp_proto",
        "@com_google_protobuf//:wrappers_proto",
    ],
)

The com_google_protobuf dependency from our WORKSPACE file:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_google_protobuf",
    sha256 = "6b6bf5cd8d0cca442745c4c3c9f527c83ad6ef35a405f64db5215889ac779b42",
    strip_prefix = "protobuf-3.19.3",
    urls = ["https://github.com/protocolbuffers/protobuf/archive/v3.19.3.zip"],
)

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")

protobuf_deps()

It's worth mentioning that this resolution doesn't work in *.proto files but works in *.go files.

That the resolution is only not working in *.proto files but successfully works in *.go files is an important detail. If *.go files were affected, we'd need to look for an issue with attaching the proto stubs generated by the Bazel build.
For imports in *.proto files, implementing the FileResolveProvider extension point from the Protobuf plugin would indeed be an option (as @fkorotkov suggested via chat). By default, the Protobuf plugin provides two implementations for FileResolveProvider. One of them resolves imports from the project roots. The other one uses the paths configured in the settings.
Out of the box, the Protobuf plugin doesn't seem to provide a way to resolve imports of protos which come in via dependencies. I'd assume that you would see the same issue in a Gradle- or Maven-based project. Did you test this?
That would also influence where an appropriate implementation needs to be placed. If it's possible to write a FileResolveProvider which locates a file in IntelliJ's attached libraries, it would be best placed in the Protobuf plugin as it would then be independent of the build language.
If that's not entirely possible, then the Bazel plugin should only bridge the remaining gap.

Thanks for the responses! I tested this out only with Bazel (not with Gradle or Maven). Should I open an issue for the Protobuf plugin on this then?

I don't think it's a Proto plugin issues since these external proto files are not in project scope (if you try "Go to File" action then you'll see that IntelliJ doesn't know about the files).
I'll open a PR shortly that adds integration with Protocol Buffers plugin to do the resolution.

Opened #3228 draft which fixes the issue for my use case.

Thanks for following up on this Fedor!

I looked at https://github.com/bazelbuild/intellij/pull/3228 and this implementation is exactly what I meant that we should avoid. The implementation of course works as the Bazel plugin is explicitly gathering a reference to any sources it encounters (but does so outside of it's regular data management) and then resolves any references to other proto files queried by the Protobuf plugin directly against those sources. This is working completely around IntelliJ's project model and the design of the Bazel plugin, introduces hard dependencies between the plugins, and introduces a special purpose implementation. In addition, there's a large risk that the generic data the aspect gathers in that implementation will be quite large for large projects, resulting in performance issues.
I'm convinced that there's an alternative solution which avoids all/most of these disadvantages and lets the plugins stay within their respective scope. Instead of pulling in everything in the aspect, it would be necessary to figure out how to exactly reference the currently missing proto files/sources. Potentially, these sources are already gathered for some languages but seemingly hidden with other names. For that case, duplicate data mustn't be collected. A next step would be to figure out how to attach them to IntelliJ's project model such that they are indexed and that the Protobuf plugin can reference them (in an implementation of FileResolveProvider within the Protobuf plugin) without the two plugins knowing about each other. I would be surprised if this wasn't possible somehow. A positive consequence of this would be that users would be able to find those proto files via the "GoToFile" action, which I would expect as a user.

figure out how to exactly reference the currently missing proto files/sources

I wasn't able to find any target that already contains this information. I inspected all the target infos that were presented for my test project. Maybe you can take a look and help us to figure this out?

figure out how to attach them to IntelliJ's project model such that they are indexed and that the Protobuf plugin can reference them

This is done BlazeProtoAdditionalLibraryRootsProvider in my PR. With this extension *.proto files are indexed and available for "GoToFile" action.

... without the two plugins knowing about each other. I would be surprised if this wasn't possible somehow.

It doesn't seem possible with the current two implementation of FileResolveProvider that the Proto plugin has out of the box as you mentioned yourself above.
Overall after digging into the code I don't see a way to get the external *.proto files into the project without BlazeProtoAdditionalLibraryRootsProvider. For which we need somehow to get the info from Bazel either via the generic info, separate proto configuration or some other way which I wasn't able to find.
The only part of the PR that IMO can be moved to the Proto plugin itself is the resoling part so just adding BlazeProtoAdditionalLibraryRootsProvider from the Bazel plugin side will be enough. But this still require the GenericIdeInfo thing. I though of making it as a separate proto language so you can add it to additional_languages to enable the integration but proto_library is a generic target already and seems pretty impossible to abstract out.


fix: improve handling of tabs scrolling

The scrollbar for tabs would usually end up being shown behind other UI elements. This change brings the following enhancements:

reduce tabs height when the scrollbar is shown to fit the scrollbar
use a transparent scrollbar to look nicer, especially when using dark mode

closed because there will be no scroll for tabs in graphiql v4 https://github.com/graphql/graphiql/pull/3644


[UI] Logs do not continue scrolling

After the log stretches to fill the screen it stops scrolling. The expected behavior is that it would continue following along with new lines added.

v0.16.0
Verified Fixed


Fix for #647 (GPO issue)

Proposed Changes
Avoid $toUpdate/$toSkip.GetUpperBound(0)
Related Issues
#647

Fixes #647


Save grafana dashboard button does not work

Type:
Bug
Rancher version:
v2.2.5
Description:
We just upgraded 2.2.4 to 2.2.5, here's what I'm doing that doesn't work.
For whatever reason, I'm able to save reliably by hitting the "ctrl-s" keyboard shortcut, but not with the "save" button in the ui. So, at least I have a workaround.
See this on Firefox 68 on Ubuntu 18.04.  Did not try on other browsers

I was able to verify that the save button now works in 2.2.5.

Tested the builtin Grafana (template version v3.8.6)in both Rancher:v2.3-head and master-head
Both the saving button and the shortcut Ctrl + s work


Add support for Cohere and others.

Description
Add support for Cohere and others.
Issues Resolved
[List any issues this PR will resolve]
Check List

[ x] New functionality includes testing.

[ x] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Working on resolving a conflict caused by another PR, but this diff for this PR should be fairly small and clean.

Tests are failing.

@dhrubo-os @HenryL27

@dhrubo-os


bump: upgrade Rust toolchain to nightly-2022-08-23

@HAOYUatHZ

prefer to be approved&merged by @xgaozoyoe or @lispc