DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-yml-archive-non-versioning-archive/pull/360 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-yml-archive-non-versioning-archive.git

Docs Build status updates of commit aebbe15:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/TOC.yml
:white_check_mark:Succeeded
View

docs/index.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-3.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/sql-database-engine.png
:white_check_mark:Succeeded

docs/to-be-archive/level2/article3-2-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-3.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


1.0.0

Resolves #100
Yes, I migrated (via cargo fix --edition) and tested (by running goon with the dll) the edition change.


about categories in the coco datasets

In the json file (datasets of coco format), whether the categories correspond in the order of enumeration or in the order of category id. why do I change the order (the corresponding relationship between category name and ID hasn't changed), the mPAP of bbox obtained from the test.py becomes 0

You need also check whether the box is organized following the correct order.


Failure on Debian 8.4, mismatched version number

Cookbook version
8.0.3
Chef-client version
12.13.37
Platform Details
Debian 8.4 (AWS ami-98e114f8)
Scenario:
Trying to install MySQL 5.5
Steps to Reproduce:
mysql_service db_dbname do
port '3306'
version '5.5'
initial_root_password db_root_password
action [:create, :start]
end
Expected Result:
Running MySQL daemon
Actual Result:
The mysql-server package is not retrieved.   The error log has scrolled out of my life, but the problem was that the wrong minor version is used.
In helpers.rb, line 183, the version is specified as 5.5.49-0.
That version is not available via the apt package manager.
I changed the number to 5.5.52-0 and it worked.
Setting the version in the lwrp only works for the major number.  It would have been more convenient to be able to set the minor number there as well.
Maybe a fallback to the default major version number (i.e. 5.5)  in cases where the package is not found?

Should be fixed when pull request #478 is merged.


RBAC is WAY to permissive

The operator cluster role grants access to a lot of resources/verbs cluster-wide, and I cannot imagine all these permissions are required to operate:
https://github.com/oracle/oracle-database-operator/blob/bb344e4dee6ae72e5132f55e15ca4deb55557e71/oracle-database-operator.yaml#L2528-L2690
In particular, CRUD on nodes and namespaces should NOT be required, making the operator an elevated component if installed like this. You should do a massive cleanup of the RBAC!

Also should make work in a non root k8s container.

Also should make work in a non root k8s container.

I agree, but that is worth a separate issue. Do you mind opening one, @djjeffr?

Yes I will open a new issue

Also should make work in a non root k8s container.

Did you open the new issue thread on this? If yes, please let me know the details so that I can review the exact issue.

@psaini79 thanks for the feedback! What took you so long? 😉 We would appreciate if the RBAC granted to the operator was least-privilege based: only grant required permissions. CRUD to nodes is probably the worst, but I think there is a lot more that can be removed from the list of permissions.
About containers running as root, @djjeffr opened https://github.com/oracle/oracle-database-operator/issues/74. I will add some more details to that issue, but again it's all about least-privilege. It's particularly important to support OpenShift - since OpenShift requires additional configuration (SCC) to allow containers to run as root.

@erikgb Sure, CRUD to the nodes level will be removed. I am reviewing it internally and will update the roles and privs accordingly.

Please review the latest branch, the operator is namescoped and all the privileges are explained in each respective controller.
Please reopen the thread if you have any question.


NotEmptySet from class to interface

Description
Migrate the NotEmptySet from a class to a sealed interface for simplifying the API and not introducing useless operations to the documentation like the toString function, for example.
Checklist

[x] Implement.
[x] Test.
[x] Refactor.
[x] Update Work in progress section in changelog.

Done.


why sqlx.Stmt never close?

type pgDb struct {
	dbConn *sqlx.DB

	sqlSelectPeople *sqlx.Stmt
	sqlInsertPerson *sqlx.NamedStmt
	sqlSelectPerson *sql.Stmt
}

I see your example code. you never close sqlx.Stmt. why?
discuss reference

Because if a sqlx.Stmt is closed, then you can't use it anymore until you Prepare() it again? The reference to the prepared statement lives in *pgDb, and you can use it again and again throughout the life of the app. Perhaps when the app exits it would be better to Close() it, but I'm pretty sure that it's not necessary - Postgres will see that the connection ended and will free the resources.

ok


Properly deprecate lombok.addGeneratedAnnotation configuration property

I accidentally found that lombok.addGeneratedAnnotation was being deprecated but I couldn't find anything about it. I'd expect that such information should be added to changelog.

Thanks for the feedback.


What's the workaround for "ChatGPT is at capacity" feature?

First of all, thanks for creating an app that helps using ChatGPT.
One of the features listed on the Readme says "chatgpt is at capacity" workaround", however, I didn't see how I could access it.
Even if I am a plus subscriber, when I get a login link and click, it directs me to the browser instead of the app. In other words, I can't use ChatGPT with this app when OpenAI is at capacity.

hi, thanks. i found that visiting https://chat.openai.com/auth/ext_callback?next= (instead of https://chat.openai.com) often redirects to login page (even if not it is at capacity). I also use VPN, reload page many times + clear storage (it helps sometimes) . is is basically it
it will be probably be fixed in the future (if not already, i haven't seen chatgpt is at capacity for long time to test)

No, I tried the latest release, however, the "at capacity" page still takes over the entire screen and there is no refresh button. Not sure if it is a phone problem(I am using a Huawei mate 40 pro).
And it appears that a new issue comes up, it logs me out if I close the app). But in release 1.0.1, it keeps my login status even if I kill the app.


Testing with workspaces ava

Testing sputnik-dao2 with workspaces-ava

@Buckram123 @deveusss @NinoLipartiia4ire @adsick can you please take a look on this guys?
Since this has been merged, the macos job is failing on every PR with multiple errors that look like this one:
  views.ava.ts › View get_available_amount

  Rejected promise returned by test. Reason:

  Error {
    message: 'Sandbox Server with port: 6441 failed to start after 20000ms',
  }

  › sandboxStarted (node_modules/near-workspaces/src/container/server.ts:70:9)
  › async SandboxServer.start (node_modules/near-workspaces/src/container/server.ts:164:5)
  › async SandboxRuntime.beforeRun (node_modules/near-workspaces/src/container/runtime.ts:263:5)
  › async SandboxRuntime.fork (node_modules/near-workspaces/src/container/runtime.ts:86:7)
  › async Workspace.fork (node_modules/near-workspaces/src/workspace.ts:152:5)
  › async node_modules/near-workspaces-ava/src/index.ts:111:9

If we don't get this fixed soon, i'll be force to revert this PR and remove it from master.


Itr update

Following the discussion we had during the IDR call,
I have updated the links pointing to the notebooks now available in the various guides.
Some notebooks currently available from https://idr.openmicroscopy.org/about/itr.html do not work e.g. R one.
I have also added a link to the ilastik notebook
Note: I found at last night that ilastik is broken (not our mistake)

accession number + description (+ s3 optional) is probably the most suitable approach


cesu8 decode error

I'm receiving an UnicodeDecodeError error when I try to pull data from HANA using the PyHDB library while iterating through the results in the following code.
from sqlalchemy import create_engine
engine = create_engine('hana+pyhdb://%s:%s@%s:%s' % (username, password, host, port))
connection = engine.connect()
result = connection.execute("select * from TASKS")
for row in result.fetchall():
   test = row
connection.close()

I've narrowed it down to the following snippet.
import pyhdb.cesu8
input = b'\xed\xa0\xbd'
pyhdb.cesu8.decode(input)

Which generates the error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid continuation byte
Is this the expected behavior? My assumption is that if the data can be stored in HANA we should be able to read it with the library but my knowledge of utf-8/cesu8 is limited.
Thanks,
Jon

I ran into similar issues, mostly when reading in LOB/CLOB/NLOB types.  What I found was that python was having issues decoding latin character with the encode utf-8 (such as i's with accents).  I have found success using latin-1 encoding instead of utf-8 in my own clone pyhdb but cannot say with 100% certainty that this will fix all problems of this type.

After a bit more examination it comes down to Python an issue in Python:
When passed in as a str object \xed has no issues:
Out: 'í'```

However when the input is a `bytes` object `b'\xed`, `utf-8` can't decode the character.  The utf8 version of the `bytes` object is `b'\xc3\xad'`:
```In: 'í'.encode('utf8')
Out: b'\xc3\xad' ```

Finally `'\xed` CAN be decoded as an `í` by using a different codec:
```b'\xed'.decode('ISO-8859-1')
Out[214]: 'í'```

All this to be said, the encoding/decoding issues are a bit complex and it seems like the approach of `pyhdb` does not take into account some of the complexities of the return values.

The interesting question is from where the encoded byte string comes. How did you inserted the data into the database via PyHDB or another client e.g. HANA Studio or another database driver?

For me, the original data came in via SAP Data Services. To add, if I use the hdbcli python library with the same query there are no errors.

It seems like the trouble is that CESU-8 SHOULD pass in 6 byte long sequence, but what we are running into is at some point SAP Hana is passing just a 3 byte sequence (b'\xed\xa0\xbd' in @jstorryefx 's case) and the so the conversion fails.  A 6 byte CESU-8 sequence should correspond to a 4 byte UTF-8 sequence, but I do not know if the same holds try for a 3 byte sequence (i.e. does 3 byte CESU-8 correspond to a 2 byte UTF-8?)

Let me summarise the problem:

b'\xed\xa0\xbd' isn't a valid CESU-8 byte sequence as additional 3 bytes are missing for a unicode point. Ether the data is incomplete stored in the database (the SAP HANA product support would be happy to help in that case) or maybe the character/byte sequence is at the end of a LOB and PyHDB's encoding fails in that corner case as it doesn't fetch the missing 3 bytes. @jstorryefx Would it be possible to get the original data as unicode text? You can also send the data directly via mail to me. Can you describe the structure of the table? Is the column a NVARCHAR or NCLOB? Is it a row or column store table? If you retrieve the data with another client e.g. HANA Studio is the tool able to display the full data?
Until now there is no prove or scenario that shows a bug in PyHDB's CESU decoding or encoding.

I had a chance to test the changes today and the issue that I was having has been resolved with  946a0f4 !
Thanks @jarus! and also @wadeej for helping to clarify what the issue was!

I update my pyhdb to the latest,and test this
import pyhdb.cesu8 test = b'Should say Professional Designation \xed\xa0\xbd\xed\xb8\x8aThis was in the New Hire PAR' pyhdb.cesu8.decode(test)
it's correct,but i still  miss this error when I read  data from hana,here is mycode
def get_mat(conn,sql):     cursor = conn.cursor()     cursor.execute(sql)      mat =cursor.fetchall()     return mat
and the error message is
'utf-8' codec can't decode byte 0xed in position 90: invalid continuation byte

I have also updated the pyhdb with the latest version i am getting this error
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 11: invalid continuation byte

Hi,
I am not sure if I should open a new issue. I am receiving the following:
   connection = pyhdb.connect(   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/__init__.py", line 30, in connect     conn.connect()   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/connection.py", line 141, in connect     agreed_auth_part = self._auth_manager.perform_handshake()   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/auth.py", line 50, in perform_handshake     response = self.connection.send_request(request)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/connection.py", line 83, in send_request     payload = message.pack()  # obtain BytesIO instance   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/message.py", line 55, in pack     self.build_payload(payload)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/message.py", line 45, in build_payload     segment.pack(payload, commit=self.autocommit)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/segments.py", line 94, in pack     self.build_payload(payload)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/segments.py", line 80, in build_payload     part_payload = part.pack(remaining_size)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 103, in pack     arguments_count, payload = self.pack_data(remaining_size - self.header_size)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 591, in pack_data     payload = Fields.pack_data(fields)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 48, in pack_data     field = field.encode('cesu-8') LookupError: unknown encoding: cesu-8
This is executing on  pyhdb.connect()

Hi,
I am not sure if I should open a new issue. I am receiving the following:
   connection = pyhdb.connect(   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/__init__.py", line 30, in connect     conn.connect()   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/connection.py", line 141, in connect     agreed_auth_part = self._auth_manager.perform_handshake()   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/auth.py", line 50, in perform_handshake     response = self.connection.send_request(request)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/connection.py", line 83, in send_request     payload = message.pack()  # obtain BytesIO instance   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/message.py", line 55, in pack     self.build_payload(payload)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/message.py", line 45, in build_payload     segment.pack(payload, commit=self.autocommit)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/segments.py", line 94, in pack     self.build_payload(payload)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/segments.py", line 80, in build_payload     part_payload = part.pack(remaining_size)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 103, in pack     arguments_count, payload = self.pack_data(remaining_size - self.header_size)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 591, in pack_data     payload = Fields.pack_data(fields)   File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 48, in pack_data     field = field.encode('cesu-8') LookupError: unknown encoding: cesu-8
This is executing on  pyhdb.connect()

Hi,
I am not sure if I should open a new issue. I am receiving the following:
    connection = pyhdb.connect(
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/__init__.py", line 30, in connect
    conn.connect()
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/connection.py", line 141, in connect
    agreed_auth_part = self._auth_manager.perform_handshake()
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/auth.py", line 50, in perform_handshake
    response = self.connection.send_request(request)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/connection.py", line 83, in send_request
    payload = message.pack()  # obtain BytesIO instance
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/message.py", line 55, in pack
    self.build_payload(payload)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/message.py", line 45, in build_payload
    segment.pack(payload, commit=self.autocommit)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/segments.py", line 94, in pack
    self.build_payload(payload)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/segments.py", line 80, in build_payload
    part_payload = part.pack(remaining_size)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 103, in pack
    arguments_count, payload = self.pack_data(remaining_size - self.header_size)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 591, in pack_data
    payload = Fields.pack_data(fields)
  File "/home/thomas/.local/lib/python3.9/site-packages/pyhdb/protocol/parts.py", line 48, in pack_data
    field = field.encode('cesu-8')
LookupError: unknown encoding: cesu-8

This is executing on pyhdb.connect()

Same for me. My inputs to pyhdb.connect() are pretty simple characters (numbers, upper and lower case letters without accents, dashes, periods, underscores) but I get this error.

Same for me: Statement executed -> pyhdb.connect()
Error message -> unknown encoding: cesu-8
Python version -> 3.9

I am having the same issue as @amarvin and @darveshsingh and receive the cesu-8 error with pyhdb.connect(). I have no accents or encoded chars in the input parameters.
Code:
import pyhdb
conn = pyhdb.connect(host = 'host01',
                                  port = 123,
                                  user = 'user',
                                  password = 'password1!')

Output:
LookupError: unknown encoding: cesu-8

3 most recent calls:
...\pyhdb\protocol\parts.py in pack(self, remaining_size)
    101     def pack(self, remaining_size):
    102         """Pack data of part into binary format"""
--> 103         arguments_count, payload = self.pack_data(remaining_size - self.header_size)
    104         payload_length = len(payload)
    105

...\pyhdb\protocol\parts.py in pack_data(self, remaining_size)
    589             fields = fields + list(method_data)
    590
--> 591         payload = Fields.pack_data(fields)
    592         return 1, payload
    593

...\pyhdb\protocol\parts.py in pack_data(fields)
     46         for field in fields:
     47             if is_text(field):
---> 48                 field = field.encode('cesu-8')
     49
     50             size = len(field)

Python = 3.9.2

I am having the same issue as @amarvin and @darveshsingh and receive the cesu-8 error with pyhdb.connect(). I have no accents or encoded chars in the input parameters.
Code:
import pyhdb
conn = pyhdb.connect(host = 'host01',
                                  port = 123,
                                  user = 'user',
                                  password = 'password1!')

Output:
LookupError: unknown encoding: cesu-8

3 most recent calls:
...\pyhdb\protocol\parts.py in pack(self, remaining_size)
    101     def pack(self, remaining_size):
    102         """Pack data of part into binary format"""
--> 103         arguments_count, payload = self.pack_data(remaining_size - self.header_size)
    104         payload_length = len(payload)
    105

...\pyhdb\protocol\parts.py in pack_data(self, remaining_size)
    589             fields = fields + list(method_data)
    590
--> 591         payload = Fields.pack_data(fields)
    592         return 1, payload
    593

...\pyhdb\protocol\parts.py in pack_data(fields)
     46         for field in fields:
     47             if is_text(field):
---> 48                 field = field.encode('cesu-8')
     49
     50             size = len(field)

Python = 3.9.2

Had to rollback to using Python 3.6

Closing due to the sunset of the project. Please check active maintained alternative: https://pypi.org/project/hdbcli/


NTR: copper import into the mitochondrion

modelled in
GO:0048250    iron import into the mitochondrion
The process in which iron is transported from the cytosol, into the mitochondrial matrix. PMID:12006577
please add
GO:NEW    copper import into the mitochondrion
The process in which copper is transported from the cytosol, into the mitochondrial matrix.
https://pubmed.ncbi.nlm.nih.gov/32979421/

but also please remove the spurious commas from the text defs


docker: Error response from daemon

I have this error (on commit 75c9f5243358f920ee478f277d350491471b081d all worked properly).
Env:

ubuntu 16.04
docker 1.11.2
kubectl 1.2.0

docker: Error response from daemon: linux mounts: Path /var/lib/kubelet is mounted on / but it is not a shared mount..

Problem is cgroup memory not enabled in the linux distro.
Open the file:  /etc/default/grub
Edit the line with: GRUB_CMDLINE_LINUX="" to be:
GRUB_CMDLINE_LINUX="cgroup_enable=memory"
Then run update-grub with a reboot and it should work.


Is this compatible for react website ?

Hi Team,
This is not an issue.
I think this boilerplate is for react mobile app.
Actually I'm looking for react boilerplate for website development with React^16+Redux^5+ES7+Webpack4+CodeSpilliting  or chunk feature.
Thanks,
BSR

This RB is suitable for Production grade Web applications so you can use it Just use the latest version 3.6 you will get all the stack what you are looking for.


Component: Light page headers

The light page headers have the following variations.

[x] Analysis
[x] Programs
[x] Events
[x] Projects, About page
[x] Author archives

Closed by #95


perf: side effects when there aren't too many optimizable dependencies

Summary
Improve performance for side effects plugin when there aren't too many dependencies are optimizable:

20000 case: 26ms -> 2.6ms
Internal big project (FS): 190ms -> 180ms

Checklist

[x] Tests updated (or not required).
[x] Documentation updated (or not required).

!bench


refactor[cartesian]: Replace is_start_state= with is_start_block= when buiding the SDFG for DaCe

Description
When building an SDFG for DaCe it is sometimes necessary to specify the starting point of the graph. In the past, is_start_state=  was used for this. In never versions of Dace, is_start_state has been deprecated and replaced with is_start_block. This PR replaces the two occurrences in the cartesian/ folder and removes warnings generated during test runs. It looks like the next/ folder has already been cleaned.
Requirements

[ ] All fixes and/or new features come with corresponding tests.
[ ] Important design decisions have been documented in the appropriate ADR inside the docs/development/ADRs/ folder.

If this PR contains code authored by new contributors please make sure:

[ ] The PR contains an updated version of the AUTHORS.md file adding the names of all the new contributors.

PR deprecating is_start_state: https://github.com/spcl/dace/pull/1404, release with version v0.15.1
@egparedes would you have time for a quick review?
/cc @FlorianDeconinck as mentioned today

cscs-ci run


Comparative content to clarify Kedro positioning

What are the alternatives to using Kedro?
I took the following from https://blog.streamlit.io/using-chatgpt-to-build-a-kedro-ml-pipeline/

Airflow: Airflow is a platform to programmatically author, schedule, and monitor workflows. It was originally developed by Airbnb, and is now a popular open-source project. Airflow provides a flexible and powerful platform for building and managing ML pipelines, and has a large user base and community.
Kubeflow: Kubeflow is an open-source project that aims to make it easy to deploy and manage machine learning workflows on Kubernetes. It provides a range of tools and frameworks for building, deploying, and managing ML pipelines, including Jupyter notebooks, TensorFlow, and PyTorch.
Prefect: Prefect is an open-source platform for building, scheduling, and monitoring data pipelines. It is designed to be highly scalable and resilient, and provides a range of features for building and managing ML pipelines, including support for distributed execution and automatic retries.
Luigi: Luigi is an open-source Python library for building complex pipelines of batch jobs. It was developed by Spotify and is designed to be easy to use and flexible. Luigi provides a range of features for building and managing ML pipelines, including support for dependencies, parallel execution, and error handling.
These are just a few examples of the alternatives to Kedro that you can consider. Each platform has its own strengths and weaknesses, and the right choice will depend on your specific needs and requirements.

I think we should create some content (either a non-navigable "topic" page or a blog post) that compares Kedro with each of these and maybe provides a visual "matrix" to check off which each offers and compare with Kedro (maybe a bit like this).

This is a duplicate of https://github.com/kedro-org/kedro-devrel/issues/41


Dev

Codecov Report

Merging #122 into master will increase coverage by <.01%.
The diff coverage is 77.77%.

@@             Coverage Diff              @@
##             master     #122      +/-   ##
============================================
+ Coverage     61.47%   61.47%   +<.01%
- Complexity     2435     2438       +3
============================================
  Files           304      304
  Lines          5988     5994       +6
============================================
+ Hits           3681     3685       +4
- Misses         2307     2309       +2

Impacted Files
Coverage Δ
Complexity Δ

src/Controller/Api/Base/AbstractApiController.php
79.06% <100%> (ø)
16 <0> (ø)
:arrow_down:

src/Service/TrialService.php
96.51% <75%> (-2.24%)
21 <0> (+3)

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 69775b4...6ecb8e0. Read the comment docs.


[Discussion] Color theme

I love this extension very much as it helps me sift through big issues.
One thing I'd like to discuss is the use of @wesbos yellow which does not really fit well on github. Would you be opposed to using a dark/light theme color that matches github or allow the user to control them?
Quick mock up with slightly more on theme colors.

Personally I've accepted that as the github/emoji standard style but the controls on the other hand should be consistent with github overall style.

I agree with this, actually. I know it's a small thing, but it would be nice if the extension could better fit in with GitHub's styles. e.g. by inheriting and/or using their class names. Would make it feel less "clunky". e.g.
Before & After:

Note:

"Reactions" heading matches other GitHub sidebar headings (Classes: discussion-sidebar-heading text-bold)
Addition of dividing line, like other sidebar sections. (From: .discussion-sidebar-item+.discussion-sidebar-item)
Adjustment of "by" text to match GitHub sizing. (Inherited automatically if this was a p instead of a div).
etc

I agree (though I am flattered by Cobalt2) - it should use the github CSS variables.
var(--color-fg-default)
--color-social-reaction-bg-hover