SSE4A

Hello,
I have the following processor:
AMD Phenom II X4 945
CPU-Z shows me the following:
SSE, SSE2, SSE3, SSE4A
Should I use SSE3 or SSE4?

@Anbima You have a member of the "Barcelona" CPUs. SSE4 actually comprises three seperate SIMD instruction classes:
SSE4A
SSE4.1
SSE4.2
Thorium SSE4 builds target SSE4.1 for the best of both worlds. The only CPUs that have SSE4.2 but not AVX are 1st gen core. Most SSE4 capable CPUs support SSE4.1. This includes Core 2 Duo.
Unfortunately, the Barcelona class is one exception, only supporting SSE4a (and is the only CPU family to do so). So for you, use the SSE3 releases.
But also don't worry, as it is unlikely that running a release compiled for SSE4a would show any noticeable performance improvement, especially since SSE4a only comprises two instructions > https://en.wikipedia.org/wiki/SSE4#SSE4a


SmoothSetLevel on HLS playback raising GL_INVALID_VALUE

When playerSmoothSetLevel(), Google Chrome raises
[.PPAPIContext]GL ERROR :GL_INVALID_VALUE : glTexSubImage2D: bad dimensions.
Chrome version: 33.0.1750.152
Reading on forums, it seems that it's a bug on opengl+gpu+chrome+MacOS integration. Need to test on other browsers and SO's and if not reproducible, close this issue as wontfix.

@flavioribeiro it can be reproduced here:
http://video.consilium.europa.eu/en/webcast/0174310a-ff8b-4a48-8619-45eb4a66095f
Chrome 48 / win7 64bit


Adds function to simplify the DynamicQuantizeLinear into fp8

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

Comparison is base (2240bba) 78.05% compared to head (e4dd197) 78.09%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #87      +/-   ##
==========================================
+ Coverage   78.05%   78.09%   +0.03%
==========================================
  Files          34       34
  Lines        3236     3241       +5
==========================================
+ Hits         2526     2531       +5
  Misses        710      710

Files
Coverage Δ

onnx_extended/helper/__init__.py
100.00% <100.00%> (ø)

...nx_extended/helper/make_dynamic_quantize_linear.py
92.59% <100.00%> (+1.68%)
:arrow_up:

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


Black effect when set translucent property to "no" in navigation bar

Hi, i've got hierarchy of controllers like this https://github.com/telly/TLYShyNavBar/issues/112,
but when I set  translucent property to "no" for navigation bar, I get black effect when scroll table
(https://cloud.githubusercontent.com/assets/5242687/13523498/80a6976a-e1fe-11e5-97b7-129ee655bcd1.png)

I was going crazy until I saw this issue, got the same problem here! I got a black opaque navigation bar, and when the bar disappears when scrolling down, I also get a black bar where the navigation bar was.

For those wondering how to fix this, you have to check the «Extend Edges» Under Opaque Bars in the View Controller configuration.

Thanks for reporting this. I'll add your solution to the FAQ, @tiois. Cheers.


ci docker build fails to push to ghcr

example: https://github.com/kxcinc/pubinfra.dockerfiles/actions/runs/5502192987/jobs/10026365723
#16 exporting to image
#16 exporting layers
#16 exporting layers 61.2s done
#16 exporting manifest sha256:60bfb82e8b1cb17c49fe032ecedd2a77b2da40dee6d82049522adddc76ec9029 done
#16 exporting config sha256:81333894f48a3e4979c34af408365ba6cdfdd9c7da3322f8b6a5f57f1a47eac9 done
#16 exporting attestation manifest sha256:a34a175078fafa1abe2f8afdf80ab75f591c00b0a5a7b3e81cda5f8e2c027c93 done
#16 exporting manifest list sha256:b8e73413148a943a066413e95112b6c0bf52fa275e2b8cac5d919c24094c1722 done
#16 pushing layers
#16 ...

#17 [auth] kxcinc/ocaml-general:pull,push token for ghcr.io
#17 DONE 0.0s

#16 exporting to image
#16 62.15 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/f8819230-910f-4445-96af-7a3530b8adb4?digest=sha256%3A153d788c40ad6a6f5066ceae8bcd8154f29b8ca3b758c8fff080d2b0aba738da": write tcp <IP_ADDRESS>:56588-><IP_ADDRESS>:443: write: connection reset by peer
#16 62.15 retrying in 1s
#16 62.56 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/c49dd6ec-f116-4189-ae17-db39d8c99084?digest=sha256%3A14338e13dd953879318f0b16120454f671d68bc9b4393a6fb5562c2bc1c1e273": write tcp <IP_ADDRESS>:56574-><IP_ADDRESS>:443: write: connection reset by peer
#16 62.56 retrying in 1s
#16 62.94 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/1fec9bcf-d2c9-4152-bd46-b8b1e59450d7?digest=sha256%3Ae60daa733da2a8c874aa1f20a41f45a80[982](https://github.com/kxcinc/pubinfra.dockerfiles/actions/runs/5502192987/jobs/10026365723#step:10:986)bd9521a2760c649f186b3fa36195": write tcp <IP_ADDRESS>:56564-><IP_ADDRESS>:443: write: connection reset by peer
#16 62.94 retrying in 1s
#16 63.68 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/34d7b08a-8818-43f0-9ddb-90de0677[985](https://github.com/kxcinc/pubinfra.dockerfiles/actions/runs/5502192987/jobs/10026365723#step:10:989)7?digest=sha256%3A153d788c40ad6a6f5066ceae8bcd8154f29b8ca3b758c8fff080d2b0aba738da": write tcp <IP_ADDRESS>:37398-><IP_ADDRESS>:443: write: connection reset by peer
#16 63.68 retrying in 2s
#16 pushing layers 4.5s done
#16 ERROR: failed to push ghcr.io/kxcinc/ocaml-general:ubuntu.22.04-ocaml.4.13.1-node.fermium-amd64: failed to copy: io: read/write on closed pipe
------
 > exporting to image:
62.15 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/f8819230-910f-4445-96af-7a3530b8adb4?digest=sha256%3A153d788c40ad6a6f5066ceae8bcd8154f29b8ca3b758c8fff080d2b0aba738da": write tcp <IP_ADDRESS>:56588-><IP_ADDRESS>:443: write: connection reset by peer
62.15 retrying in 1s
62.56 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/c49dd6ec-f116-4189-ae17-db39d8c[990](https://github.com/kxcinc/pubinfra.dockerfiles/actions/runs/5502192987/jobs/10026365723#step:10:994)84?digest=sha256%3A14338e13dd953879318f0b16120454f671d68bc9b4393a6fb5562c2bc1c1e273": write tcp <IP_ADDRESS>:56574-><IP_ADDRESS>:443: write: connection reset by peer
62.56 retrying in 1s
62.94 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/1fec9bcf-d2c9-4152-bd46-b8b1e59450d7?digest=sha256%3Ae60daa733da2a8c874aa1f20a41f45a80982bd9521a2760c649f186b3fa36195": write tcp <IP_ADDRESS>:56564-><IP_ADDRESS>:443: write: connection reset by peer
62.94 retrying in 1s
63.68 error: failed to copy: failed to do request: Put "https://ghcr.io/v2/kxcinc/ocaml-general/blobs/upload/34d7b08a-8818-43f0-9ddb-90de06779857?digest=sha256%3A153d788c40ad6a6f5066ceae8bcd8154f29b8ca3b758c8fff080d2b0aba738da": write tcp <IP_ADDRESS>:37398-><IP_ADDRESS>:443: write: connection reset by peer
63.68 retrying in 2s
------
ERROR: failed to solve: failed to push ghcr.io/kxcinc/ocaml-general:ubuntu.22.04-ocaml.4.13.1-node.fermium-amd64: failed to copy: io: read/write on closed pipe
Error: buildx failed with: ERROR: failed to solve: failed to push ghcr.io/kxcinc/ocaml-general:ubuntu.22.04-ocaml.4.13.1-node.fermium-amd64: failed to copy: io: read/write on closed pipe

maybe related: https://github.com/felddy/foundryvtt-docker/issues/358

might be helpful: https://github.com/docker/build-push-action/issues/761#issuecomment-1385511949

definitely (?) related: https://github.com/docker/build-push-action/issues/761

also related: https://github.com/moby/buildkit/issues/3969

Workaround example:
https://github.com/runatlantis/atlantis/blob/dd32a792b7200832853ae331c805a67a850a67a4/.github/workflows/atlantis-image.yml#L52-L57
(though https://github.com/moby/buildkit/issues/3969 said setting network mode to host would help?)


A few ideas

It would be nice to have the possibility to ping a range when added to detect hosts that are alive.
And/or a ping button next to every host to check it's alive
Automatically get the Hostname from a host
Possibility to check a list of ports for listening services?

This would make it possible to add a range and automatically add a bunch of hosts in 1 go
(maybe it is already on the todo list)

I love the simplicity of this product.  Thank you for taking the time to put something like this together.  I literally just got it running (on my UNRAID server), So I am not up to speed on all of the features available.  The ideas @croontje  mentioned would be helpful.  Another idea I had was a way to upload a spreadsheet to populate the data.  Assuming that most people use spreadsheets to track this data, it would be awesome to allow for uploading existing data to populate the IPs in your product.
I am not a software engineer, but I will take a look at how complicated it would be to integrate the ability to upload a .xls to populate the port and description for a matching IP.


Feature request: time series functionality

Hello, I hope this finds you well.
Please could you implement machine learning time series functionality within SmartCore? I would like to work with machine learning-based time series forecasting, classification, regression, etc in Rust. I just thought it would be useful and interesting to me for a Rust machine learning library to implement the type of time series functionality in existing Python libraries like sktime, Prophet, and Tensorflow, and that it may be the case for others as well.
There are obviously additional considerations that would take time to address and implement like making sure data are stationary and deseasonised, windowing and framing, etc. It may be useful or necessary to implement models that perform well with time series data, such as LSTM neural networks, classical models, like ARIMA, to use as a baseline against which to compare machine learning models, additional relevant evaluation metrics, etc.
Thank you for your time and consideration.

Hi Tom! I was thinking about adding ARMA/ARIMA and some other simple methods from R's Tswge package, but I can't find time to do it myself. Let me know if you are interested in developing such an extension yourself. I have some basic understanding of time series analysis myself and I know a person from SMU, who might help us if we decide to implement functionality similar to Tswge in Rust.

Hi Tom! I was thinking about adding ARMA/ARIMA and some other simple methods from R's Tswge package, but I can't find time to do it myself. Let me know if you are interested in developing such an extension yourself. I have some basic understanding of time series analysis myself and I know a person from SMU, who might help us if we decide to implement functionality similar to Tswge in Rust.

Thanks for your reply!
Yes I would be interested in adding time series functionality to this package, but I wouldn't be able to start for a while - both because of other commitments I have now as well as that I would need to read up on time series stuff more to be able to actually implement it. But in the future, I'd definitely be interested.


chore: capitalize text

🔗 Linked issue

📚 Description

text is capitalized for consistency,  similar to its previous link.

@danielroe , can you check it ?

Thanks 👍🏻


No LICENSE

Heya, can't use this awesome library due to a license absence. Would you care to add some?

It's dependencies need licensing too!

Library licensed under the MIT license.
bitset also licensed now.


Feature/auto scroll to current sesion

Issue

close #509

Overview (Required)
When the screen opens, it scrolls to the item with the current time. The timetablegrid also scrolls.

If it is a breaking time between sessions, it scrolls to the previous session.
If it is after the end of the day's sessions, it scrolls to the last session.
Allow the user to save their position when they perform a scroll operation.
I also created a ui test.

It does not retain the scroll position when returning from the grid view, but this is an existing issue. I will not take action this time.
I wanted to animate the scrolling, but it seemed to cause a nasty bug, so it is out of the scope of this PR.
The work has been made by @yjyoon-dev until the middle of the work. Thanks.
Links

Screenshot (Optional if screenshot test is present or unrelated to UI)

Before
After

Movie (Optional)
I have changed the date and time in the system settings.

Before
After

Sorry, the test was unexpected on the search screen. I will fix it.

I used Instant to group the listings. This especially affected the tablet screen. We have restored to grouping using hours and minutes.

Could you solve the conflict? 🙏

I noticed when I was merging that it scrolled down even if it wasn't the day of the conference. Please wait a little bit.

I fix probrem. Please review!

Looks great! Thank you for your contribution!


downloading original file

This issue is related to https://github.com/buda-base/archive-ops/issues/702 and specifically this feature. Here's a provisional spec:
Files on s3
Let's assume the files on s3 are:
Works/ed/W0GN010020/images/W0GN010020-I0GN010020001/I0GN010020001001.jpg

for the web image and
Works/ed/W0GN010020/sources/Senior Images/RS20/DigitalPublication/RSF20-01-recto.jpg

or the alternative
Works/ed/W0GN010020/sources/W0GN010020-I0GN010020001/Senior Images/RS20/DigitalPublication/RSF20-01-recto.jpg

for the source image (I tend to prefer the first option).
Connective data
The two are connected through a new property in the bvm, sourcePath, available for each image:
    {
     "filename":"I0GN010020001001.jpg",
     "sourcePath": "Senior Images/RS20/DigitalPublication/RSF20-01-recto.jpg"
    }

indication in the info.json
The IIIF server would provide in the info.json a link in the form
{
   "seeAlso": {
      "id": "URL",
      "type": "Image",
      "format": "image/jpeg",
      "label": { "en": ["File originally provided to BDRC"]}
   }
}

where URL is described below.
API
The source image will not be available in IIIF but only as download. The API could be
/sourcefile/bdr:I0GN010020001::I0GN010020001001.jpg

it would return the bytes directly from s3 without any processing, with a file name indication for download (the same as in the s3 path), and an inferred mimetype.

done!


Update azure-netapp-files-understand-storage-hierarchy.md

Adjusted smallest volume size from 4 TiB to 100 GiB

Thanks @arntdg !
@Court72 - Thanks for checking. OK to merge for publishing.
#sign-off

Due to the upcoming conference, all merging and publishing are on hold until the morning of 5/23.
This PR is ready for merge on 5/23.
#label: "event-triaged-to-10AM"
#label: "missed-content-complete"


Use webpack to improve performance

Use webpack to improve performance

@jdneo, @Eskibear please help review this PR.

test this please

okay to test


Refactor multimodal embedding code

Description
Refactor multimodal embedding code
Issues
n/a
Type of change
List the type of change like below. Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would break existing design and interface)
[x] Others (enhancement, documentation, validation, etc.)

Dependencies
None
Tests
Local test and CI test.

https://github.com/opea-project/GenAIExamples/pull/1244 is created to  update the dockerfile path.


write UUID fail on _check_schema_compatible

Apache Iceberg version
main (development)
Please describe the bug 🐞
I can't write a UUID in an iceberg table
from pyiceberg.catalog.rest import RestCatalog
from pyiceberg.schema import Schema
from pyiceberg.types import NestedField, UUIDType
import polars as pl
import uuid

catalog = RestCatalog(
    "default",
    **{
        "uri": "http://localhost:8181",
        "warehouse": "s3://test-bucket/",
        "s3.endpoint": "http://localhost:9020",
    },
)

catalog.create_namespace("default")
id_to_write = uuid.uuid4()

iceberg_schema = Schema(
    NestedField(1, "id", UUIDType(), required=True),
)
catalog.create_table(
    "default.aaa",
    schema=iceberg_schema,
)
df = pl.DataFrame({}).with_columns([pl.lit(id_to_write.bytes).alias("id")])

df = df.to_arrow()

df = df.cast(target_schema=iceberg_schema.as_arrow())

table = catalog.load_table("default.aaa")
table.append(df)

but if I comment the call to _check_schema_compatible then it write to the table
https://github.com/apache/iceberg-python/blob/a6cd0cf325b87b360077bad1d79262611ea64424/pyiceberg/table/__init__.py#L485
and I can read the data with trino

thanks for reporting this issue!
The _check_schema_compatible is currently more strict than it should be. In #829, the _check_schema_compatible check is relaxed.
Would #829 fix your issue above?

hey @kevinjqliu
I tried your PR it do not fix the insert of UUID

I see, I also verified that _check_schema_compatible errors.
Heres an example to repro:

def test_schema_uuid() -> None:
    import polars as pl

    iceberg_schema = Schema(
        NestedField(1, "id", UUIDType(), required=True),
    )

    id_to_write = uuid.uuid4()
    df = pl.DataFrame({}).with_columns([pl.lit(id_to_write.bytes).alias("id")])
    df = df.to_arrow()
    df = df.cast(target_schema=iceberg_schema.as_arrow())

    _check_schema_compatible(iceberg_schema, df.schema)

Looks like @Fokko opened an issue regarding UUID for arrow
https://github.com/apache/arrow/issues/15058
@Fokko can you chime in here on writing UUID data type?

Thanks for pinging me here. So there is some progress on the Arrow side. There has been a vote to adopt the UUID type, and it has been added to the format.
Thanks for the example code @kevinjqliu:

And I would say that they are equivalent. So if we know that the field in the Iceberg table is a UUID, just writing a Fixed[16] is okay and should pass the compatibility check.

Hi @raphaelauv thank you for raising this issue. https://github.com/apache/iceberg-python/pull/921 should fix this issue. Would you like to give it a try?
I've added a test including UUIDType to demonstrate that the fix will work

Fixed in #921
Specifically, tested here
https://github.com/apache/iceberg-python/pull/921/files#diff-e52e4ddd58b7ef887ab03c04116e676f6280b824ab7469d5d3080e5cba4f2128R2535
https://github.com/apache/iceberg-python/pull/921/files#diff-7f3dd1244d08ce27c003cd091da10aa049f7bb0c7d5397acb4ec69767036accdR1044


ML : Fake News Classification (ML-Projects)

📌 Issues for Week 9 - Basic Projects of Machine Learning
🔴 Project Title : Fake News Classification
🔴 Aim of the Project : Machine learning model to predict if the news is real of fake.
🔴 Dataset : https://www.kaggle.com/c/fake-news
🔴 Domain : Machine Learning
🔴 Special Credit : Try to implement more than three machine learning algorithms and make a comparison between them, then conclude about the best fit algorithm to create the model. All the algorithms must be checked through the accuracy scores to determine the best fitted model
Welcome to 'ML' Team, good to see you here, in this week we'll be creating several basic projects of this Machine Learning Domain.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.
A Demo Project has been created to guide you about the whole structure of presenting the Project in this repository. Here's the link of the Demo Project - https://github.com/girlscript/winter-of-contributing/tree/Machine_Learning/Machine_Learning/Basic_Projects_of_Machine_Learning/Demo_Project

Take the Reference from these two projects attached here,

https://github.com/prathimacode-hub/ML-ProjectKart/tree/main/Airbnb Price Prediction
https://github.com/prathimacode-hub/ML-ProjectKart/tree/main/Bike Crash Analysis

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Changes should be made inside the Machine Learning/Machine_Learning/Basic_Projects_of_Machine_Learning Branch.
Follow Contributing Guidelines & Code of Conduct before start Contributing.
This issue is only for 'GWOC' contributors of 'Machine Learning' domain.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
Batch Number :
GitHub Profile Link :
Approach for this Project :
Are you a participant of GWoC21?

[ ] YES
[ ]  No

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎
Domain
Machine Learning
Type of Contribution
Basic Projects of Machine Learning
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

ASL Manasa
Batch - 1
https://github.com/ASLManasa
Project

@ASLManasa Progress?

will surely do it by EOD.

@abhisheks008 done kindly check and merge!

@abhisheks008  when the next set of questions will be released ?

@abhisheks008 when the next set of questions will be released ?

All the issues have been created, no further issues will be released from our side, as we have completed the roadmap.
@kishlayaug15


java8 LocalDateTime is dropping 00 seconds value when parsing date string

Currently, I'm experiencing an issue with LocalDateTime conversion.
I saw the latest changes in circe-0.12.2 here: Commit
This change is leading to break everything related to LocalDateTime now in my company.
I also read a similar problem on Stackoverflow and this is considered as a future. Here: SO Answer
You can see a live example here

Thanks for the report. I'll publish an 0.12.3 this week (probably tomorrow).


options.exportAssetMap writes assets/assetMap-HASH.js

and adds assetMap.js to asset map, for asset rewrite
usage: <script src="assets/assetMap.js"> in html source
This allows client side JS to use versioned assets via window.ASSET_MAP.

:+1:

I think this should be in its own module. You can use the generateAssetMap option and then consume it however you would like. I can link to your module from the README.

This option is comparable to generateRailsManifest in that it produces a version of the asset manifest which is useful in certain environments. What is different about this feature that makes you want to keep it separate?

Because rails is a defined spec that a lot of people use. This is something that is specific to your build process.
To be honest, I am going to refactor this soon to reduce the amount of options being passed into the module. I will most likely land on just having one export option, which can then be transformed as needed to how you need it in your build.

I'm going to close this for now. Do you think you could try and see if you can use generateAssetMap and consume that somehow since it is just json?


AutoUpdate is bad for Modpacks

Forcing an autoupdate mod which could also update any number of other mods that also use Vanguard is a very bad idea for modpacks. If users want to use Vanguard you should link to it, instead of jar in jar'ing it. We would have liked to include this, but you can't have mods auto updating in a modpack, and it could prevent players from accessing the server. This mod obviously is not going to affect that, but by including Vanguard you are enabling Auto Updates for any mod that supports it.

apologies if i have grammar issues. I will push a commit here in a second that will un-jnj vanguard. I really didn't know that nesting vanguard into my mod is such a bad idea.


Typo fix: KEY_STENGTH -> KEY_STRENGTH

dist/ca, dist/certificate, source/ca.py, source/certificate.py:
Typo fix: KEY_STENGTH -> KEY_STRENGTH

Thank you @SunTsu


FEAT[#942]:Fork, Commit, Merge - Easy Issue (YAML)

Pull Request Type
What kind of change does this PR introduce?
[x ] Solved an issue/task(✅)
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:
What is the current behavior?

There is no configuration file for the hypothetical application.
Issue Number: #942
What is the new behavior?

This PR adds a YAML configuration file for the hypothetical application. The configuration file contains all of the required information, including the application name, version, host, port, and database configurations.

Other information

This PR also includes a code review and tests to ensure that the changes are correct and working as expected.

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


Methods to read into a buffer should take an uninitialized buffer

Methods like blocking::i2c::Read::read should take &mut [MaybeUninit<u8>] instead of &mut [u8] to allow for uninitialized buffers to be used.
For example:
pub trait Read<A: AddressMode = SevenBitAddress> {
    type Error;
    fn read(&mut self, address: A, buffer: &mut [u8]) -> Result<(), Self::Error>;
}

should become
pub trait Read<A: AddressMode = SevenBitAddress> {
    type Error;
    fn read<'a>(&mut self, address: A, buffer: &'a mut [MaybeUninit<u8>]) -> Result<&'a [u8], Self::Error>;
}

Since slices of maybe uninit can only be converted to slices of normal types through unsafe, the methods should return the initiated slice.
Issues raised in #286 apply, namely that the returned slice may refer to a subslice of the input buffer. If that's a safety issue, the traits should be made unsafe to enforce that invariant.

Methods like blocking::i2c::Read::read should take &mut [MaybeUninit] instead of &mut [u8] to allow for uninitialized buffers to be used.

i am not sure i understand the benefits of this approach? it would seem to push a bunch of use of unsafe onto hal consumers, practically you can initialise an array once and reuse it anyway, and it appears you could achieve the equivalent by transmuting a MaybeUninit yourself if you did need to repeatedly use a new uninitialized array and were convinced in your application that it was okay to do so.

I agree with @ryankurte here. MaybeUninit would make very few uses more explicit and there is already a way to do the same manually which would keep the unsafe portion well confined. Pushing unsafe everywhere to the user would be very cumbersome and mostly unnecessary.

@ryankurte I might be misunderstanding you, but you cannot transmute an uninit array to an initialized array. It will result in undefined behavior and the compiler will do weird things.
The point of returning the initialized array would mean that users wouldn't have to use unsafe.

The point of returning the initialized array would mean that users wouldn't have to use unsafe.

Absence of unsafe in user code does not outweigh the complexity of your solution.
In usual I'd prefer just use initialized array.
If I have MaybeUninit::uninit(), I can just use as_mut_ptr() with unsafe. No problem with this.
But most importantly I can reuse one array for multiple write. How I can do this if fn read require [MaybeUninit]?
Just create other ReadUninit trait if you need it so much. Don't break existent.

I do not think the embedded-hal traits are the right place for this kind of API.  The traits are supposed to fit the common usecase as best as possible to allow for code reuse across the ecosystem.  Using uninitialized arrays is a specialized optimization and not something most users of the traits will care about.
Thus, I believe, the right place for such an API would be the HAL crates themselves.  I would assume that anyone who is optimizing to this extend is most likely not using generic drivers anyway - instead they would want to interact with the hardware as directly as possible, to have full control over the performance of the code.
If it does turn out to be a common requirement, I think introducing a separate, special ReadUninit trait as @burrbull suggested, is a much better alternative.


Common interface --> warn on checkflag

Cherrypicks of https://github.com/JuliaDiffEq/Sundials.jl/pull/114 to separate it from the other https://github.com/JuliaDiffEq/Sundials.jl/pull/113

Coverage increased (+0.2%) to 18.402% when pulling 7d513fadcebfb945e37cf225ebe5b9b54386c20a on common_warn2 into 2022a4b6d69d6a3eedb61944f98d7c07bdf4f56f on master.

Coverage increased (+0.2%) to 18.402% when pulling 7d513fadcebfb945e37cf225ebe5b9b54386c20a on common_warn2 into 2022a4b6d69d6a3eedb61944f98d7c07bdf4f56f on master.

Coverage increased (+0.2%) to 18.402% when pulling 7d513fadcebfb945e37cf225ebe5b9b54386c20a on common_warn2 into 2022a4b6d69d6a3eedb61944f98d7c07bdf4f56f on master.


Problem in linking of Contiguous Sub array.

The link which was provided in the Contiguous sub array of C++ Section was Broken, so I just corrected it.

Closed - superseded by another PR.


Proper confidence scores for memoization and fallback policies

Suggestion:
we could have policy.priority with default values as they are now or smth. predict methods will still predict with normal probabilities, but ensemble will multiply this probabilities by policy.priority

if i were to implement priority as a property of the Policy class, what should default values of the other policies that aren't in the default_config look like?
I'm thinking of keeping track of the priority separately in probabilities_using_best_policy()from the max_confidence so that we can compare the priorities if max_confidence is the same (i.e. 1.0)

Implemented in #1735


[ja] Translate kops.md into Japanese

This PR translates the kops.md file into Japanese as per the issue #47683. Please review the translation, and feel free to provide feedback.

It is somewhat difficult to determine whether to proceed with 47810, but since someone else has already created a PR, you should not open a new one.
If you are resolving this issue, please review 47810, thanks.
/close

I understand.
Thank you for teaching.


Use file-watching mechanism

I managed to get a shake watch working with this:
import Control.Concurrent (newChan, readChan)
import Control.Exception (SomeAsyncException(..), fromException, throwIO, try)
import Data.Functor (void)
import Development.Shake
import System.Directory (getCurrentDirectory)
import System.Environment (getArgs, getEnvironment, withArgs)
import System.FSNotify (eventPath, watchTreeChan, withManager)

import qualified Data.Set as Set

main :: IO ()
main =
  -- Get the command line args before shake sees them. This is not ideal because
  -- you must run e.g.
  --
  --   shake watch -j2
  --
  -- as opposed to
  --
  --   shake -j2 watch
  --
  getArgs >>= \case
    "watch":args ->
      -- Strip off the "watch" arg for the real shake script.
      withArgs args $ do
        -- Run the real main under 'try', ignoring synchronous exceptions
        -- because we don't care if the build fails - we want to watch & rebuild
        -- regardless. Re-throw async exceptions.
        try realMain >>= \case
          Left (fromException -> Just (SomeAsyncException ex)) -> throwIO ex
          _ -> pure ()

        -- Get the list of files that shake considers to be alive. This assumes
        -- we've set
        --
        --   shakeLiveFiles = [".shake/live"]
        --
        cwd <- getCurrentDirectory
        files <- Set.fromList . map (cwd </>) . lines <$> readFile ".shake/live"

        -- Start watching the filesystem, and rebuild once any of these files
        -- changes.
        withManager $ \manager -> do
          chan <- newChan
          void (watchTreeChan manager "." ((`elem` files) . eventPath) chan)
          void (readChan chan) -- We block here

        -- Loop. Here my compiled shakefile is itself a build target, so I exec
        -- it rather than loop here, to get the latest & greatest shake
        -- executable.
        env <- getEnvironment
        executeFile "bin/Shakefile" False ("watch":args) (Just env)

    _ ->
      realMain

It works okay, but I really don't want to keep writing this code :)
Should/could something like this live inside shake? shake --watch?

Yes/no/maybe... Yes, I'd love to include something like that. No, I don't want to incur a file watch dependency because it complicates efforts such as the GHC Hadrian work. Maybe, because if we do, I want it to be a lot smarter and "know" what files Shake really cares about. Thoughts about how we solve the "No"?

Oh, interesting. Sounds like this feature belongs in some higher-level package built on shake that could be more liberal with its dependency footprint. Boilerplate language-specific rules could go in there, too (for example, to build Haskell projects, I have been using //*.hs for finding relevant source files, but this could be made a lot more accurate by parsing the .cabal file to identify the modules that are actually part of the package).
And re: "maybe" - do you mean that shakeLiveFiles isn't quite sufficient for this use-case? If so, I think I agree. For example, my snippet above won't trigger a re-build if a new file that matches some existing glob is added.

Yep, seems like a higher-level package is the way to go. It could also provide profiling without having the source files available, the TemplateHaskell snippet in https://hackage.haskell.org/package/shake-0.16.3/docs/Development-Shake.html#v:getHashedShakeVersion etc.
I think shakeLiveFiles is a crude approximation, and it gets written to a file, so I think you want an API entry point rather than a batch mode as we have now.

Any progress on that? I would love to use watch mode in my builds.

Progress is being made. There is Development.Shake.Database a few weeks ago with shakeLiveFilesDatabase, so you now probably have enough that you can write something robust on the outside. If someone does write shake-watch or similar I'll certainly add a link to it.

Merging this issue with #580. Possibly makes sense to provide integration with Watchman as the file watching mechanism: https://facebook.github.io/watchman/

Possibly makes sense to provide integration with Watchman as the file watching mechanism: https://facebook.github.io/watchman/

Why watchman instead of plain ol' fsnotify? Is the latter not fast enough for ghc code tree?

@srid I'm not fussed either way. I suspect whoever does the work will end up setting the direction here. I suspect both are workable solutions.

I'm implementing file watching in https://github.com/ndmitchell/shake/pull/839


Check if network address in "swarm join" is a valid network interface

This pull request addresses https://github.com/docker/swarm/issues/692
I am re-stating the problem here:
Here is my setup:
host1: <IP_ADDRESS>, host2: <IP_ADDRESS>, host3: <IP_ADDRESS>
If by mistake I join host2 with host1's IP into my swarm cluster with swarm join --addr=<IP_ADDRESS>:2375 token://4432db3c4617b18655632bf091d9dfc7 (I used host1's address in host2), there is no error in host2 to indicate that I have started my swarm join with a wrong IP address nor there is any log in the master node to indicate this error.
When docker or swarm manage is started with such misconfig, the agent catches this error. However swarm join doesnt catch this error. This PR checks if the IP (currently only IPv4, since in IPv6 it doesn't check for IPs like ::1/128) is a valid network interface in the host. Kindly let me know if this works.

I like the idea, @abronan @aluzzardi ?

@vieux I added some concerns on #692.
Could you take a look over there?

Closing this PR. Please  refer to https://github.com/docker/swarm/issues/692 for conclusion


不能加载resnet50预训练文件

代码里的'./initmodel/resnet50_v2.pth'没有给出，加载官方的pth文件报错
RuntimeError: Error(s) in loading state_dict for ResNet:
Missing key(s) in state_dict: "conv2.weight", "bn2.weight", "bn2.bias", "bn2.running_mean", "bn2.running_var", "conv3.weight", "bn3.weight", "bn3.bias", "bn3.running_mean", "bn3.running_var".
size mismatch for conv1.weight: copying a param with shape torch.Size([64, 3, 7, 7]) from checkpoint, the shape in current model is torch.Size([64, 3, 3, 3]).
size mismatch for layer1.0.conv1.weight: copying a param with shape torch.Size([64, 64, 1, 1]) from checkpoint, the shape in current model is torch.Size([64, 128, 1, 1]).
size mismatch for layer1.0.downsample.0.weight: copying a param with shape torch.Size([256, 64, 1, 1]) from checkpoint, the shape in current model is torch.Size([256, 128, 1, 1]).

本文1.3节给出了resnet50_v2.pth下载路径（initmodel目录包含该文件）。

非常谢谢，已经找到了！
------------------ 原始邮件 ------------------
发件人:                                                                                "hszhao/semseg"                                                                                @.>;
发送时间: 2021年3月24日(星期三) 下午3:58
@.>;
<EMAIL_ADDRESS>主题: Re: [hszhao/semseg] 不能加载resnet50预训练文件 (#73)
本文1.3节给出了resnet50_v2.pth下载路径（initmodel目录包含该文件）。
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

本文1.3节给出了resnet50_v2.pth下载路径（initmodel目录包含该文件）。

Thanks very much! I also encountered this problem when I was doing pspnet!

Hi
Could you please post the downloaded model from that link here? I cannot register without appropriate phone number to download model, because I'm from Ukraine.

https://drive.google.com/drive/folders/1Hrz1wOxOZm4nIIS7UMJeL79AQrdvpj6v

本文1.3节给出了resnet50_v2.pth下载路径（initmodel目录包含该文件）。

Thanks very much! I also encountered this problem when I was doing pspnet!

Hi Could you please post the downloaded model from that link here? I cannot register without appropriate phone number to download model, because I'm from Ukraine.

https://drive.google.com/drive/folders/1Hrz1wOxOZm4nIIS7UMJeL79AQrdvpj6v


Two threads, output is our of order

Information

OS: Windows
Version: 10
Terminal: cmd

Describe the bug
When I use 2 or more async threads, and then wait for them to complete, output is not always in the order that I expect
To Reproduce
Repro code in comment
Expected behavior
"The All done. Again?  prompt should be after the other lines, since it occurs in the code after them.
But the actual behavior is not deterministic.
Screenshots

in .csproj file:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Spectre.Console" Version="0.47.0" />
  </ItemGroup>
</Project>

in Program.cs
using System;
using System.Threading;
using System.Threading.Tasks;
using Spectre.Console;

async Task DummyProcess(string name)
{
    const int max = 25;

    for (int i = 0; i < max; i++)
    {
        var delayMillis = 150 + Random.Shared.Next(250);
        await Task.Delay(delayMillis);

        AnsiConsole.MarkupLine($"{name}: [Green]{i+1}[/] of [Green]{max}[/]");
    }
}

Task StartDummyProcess(string name) =>
    Task.Factory.StartNew(
        async () => await DummyProcess(name),
        CancellationToken.None, TaskCreationOptions.LongRunning, TaskScheduler.Default);

// main

AnsiConsole.MarkupLine("[Red]Starting app[/]");
var done = false;

while (!done)
{
    var task1 = DummyProcess("direct");
    var task2 = StartDummyProcess("indirect 1");
    await Task.WhenAll(task1, task2);

    var again = AnsiConsole.Confirm("All done. Again?", false);
    done = !again;
}

AnsiConsole.MarkupLine("[Green]Done app[/]");

This is worse with
    var task1 = StartDummyProcess("indirect 1");
    var task2 = StartDummyProcess("indirect 2");
``

Which suggests that it is a task monitoring issue more than a console issue.

Corrected code as follows:
Task<Task> StartDummyProcess(string name) =>
    Task.Factory.StartNew(
        async () => await DummyProcess(name),
        CancellationToken.None, TaskCreationOptions.LongRunning, TaskScheduler.Default);

// main

AnsiConsole.MarkupLine("[Red]Starting app[/]");
var done = false;

while (!done)
{
    var task1 = await StartDummyProcess("direct 1");
    var task2 = await StartDummyProcess("indirect 1");
    await Task.WhenAll(task1, task2);

    var again = AnsiConsole.Confirm("All done. Again?", false);
    done = !again;
}

AnsiConsole.MarkupLine("[Green]Done app[/]");


Have no "publish" selection on console project

Have no "publish" selection on console project

@adsioj Can you tell us what page in our documentation that you are referring to? Thanks in advance for your help.

@adsioj Without further information from you, we cannot address the documentation issue that you've logged. So, we're closing this issue now.
If you'd like to provide us with more information — and in specific, the name of or a link to the page that you'd like us to fix — then please feel free to create a new issue and we'll address the documentation feedback. However, if you are looking to provide feedback on a product issue instead, please see our Visual Studio feedback options page for more information on how best to do so.


Fixed copy

Fixed #30
The latest version of chrome returns a window with empty default functions from inside the iframe. This caused the fallback to not trigger.
Tested on the latest version of chrome(Version 72.0.3626.109 (Official Build) (64-bit)) and Firefox(65.0 (64-bit)).

Released a fix as 3.0.0.


chore(publishing): add nugget publishing on master branch

Technically this should work :P

LGTM

Wait before merging, it should have built here ands not published but it hasnt, checking why


[google_maps_flutter] Added LatLngBounds constructor from list of LatLng

I added LatLngBounds.fromLatLngList() constructor from list of LatLng.
Usage:
List<LatLng> list = List<LatLng>();
list.add(LatLng(-20.10, 57.56);
list.add(LatLng(-20.12, 57.59);
list.add(LatLng(-20.15, 57.52);
LatLngBounds latlngbounds = LatLngBounds.fromLatLngList(list);
mapController
          .animateCamera(CameraUpdate.newLatLngBounds(LatLngBounds.fromLatLngList(list), 50.0));

I signed it!

I did it in a slightly different way here: https://github.com/flutter/plugins/pull/981 It was a while ago though. :D

Thanks for the contribution! However, I'm closing this as a duplicate of https://github.com/flutter/plugins/pull/981 as we don't need two PRs for the same functionality.


Project 8: Add Devise.

Remove current_user method in ApplicationController, devise will provide us with one.

Install and setup devise.
Can register a new user.
User logs in with a combination of email and password.
Hashed password should be stored in the database.
Ask for confirmation of email.
Can reset password.

Modify the views in devise for registration and login to match the wireframes and your styling.

Note
We use a mailcatcher to confirm the email if you not already install it. mailcatcher
This is our last change so be kind 🙏🏼
this were our last PR and reviews https://github.com/tiagorahal/blog-app/pull/11 but we decided to creat a new PR from different Repo

Hello dear reviewer.
The dashboard is with some problem updating my status with one of my coding partners regarding the project status, this milestone I did with him as you can see in this print(below).
I would like to ask you to mark as completed this milestone for me so I can continue with the project on my side, as the only milestone where this happened was this one.
Thank you so much for your consideration.


A filterError will be thrown if limit is string

Description:
The Panosc API accepts the limit filter to be a string therefore this is a valid query:
https://federated.scicat.ess.eu/api/documents?filter={"query":"diffraction","limit":"50"}

However, the current implementation does not accept limit to be a string (which I find safer but incompatible with the current PANOSC implementation) and:
/search-api/datasets?filter={"limit":"3"}

returns
{
  "error": {
    "message": "'>=' not supported between instances of 'str' and 'int'",
    "name": "FilterError",
    "statusCode": 400
  }
}

Sorry, multi-task problem, I wrote the issue with another github account


fix: prevent multiple chained graphql queries from cobbling context of All Documents resolver

When multiple concurrent graphQL requests are being executed by Prime, the cursor connection of the "All Documents" resolver gets clobbered by prototype pollution.
This causes the query results to either crash or fail to properly map the property fields of the returned Schema.
As a simplified example, given schemas Category(id,name,slug) and Article(id,title):
query MyQuery {
  categories: allCategory {
    edges {
      node {
        name
        slug
      }
    }
  }
  latestArticles: allArticle(first: 3)  {
    edges {
      node {
        id
        title
      }
    }
  }
}

The above query will return nulls for name/slug field of the allCategory resolver. If you inverse the blocks, then the title field of the Article schema will be nulled.

This seems caused by prototype pollution of the FindAllConnection (from typeorm-cursor-connection). The attached PR replaces the prototype replacement with an assignment on the instance of the connection, preventing the prototype from being clobbered.
NOTE This is still a huge hack! A PR should be submitted to typeorm-cursor-connection to fix the typing of the resolveNode function so it matches it's parent (MaybePromise<T>).

Fantastic @bbeausej, thank you!


feat: created the custom 500 page

Description
Adds a custom 500 page to the project. I removed the DEV cards that the custom 404 page has because if there are issues with the site, we don't want the error page to crash.
I went with this copy. Feel free to slice and dice.
uh oh! looks like there's an issue with the pizza oven
What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Related Tickets & Documents
Closes #2819
Mobile & Desktop Screenshots/Recordings

Steps to QA

Visit https://deploy-preview-2969--oss-insights.netlify.app/workspaces/foo to confirm the 500 page.

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

@nickytonline can we center the text since we won't have dev cards?

@nickytonline can we center the text since we won't have dev cards?

Any preference for which one @open-sauced/engineering @isabensusan?

I'm kind of partial to the second one, but not a hill I need to die on. 😅

I'm kind of partial to the second one, but not a hill I need to die on. 😅

The second makes it clearer there is a 500 and the message stands out. Having it centered makes me automatically not pay attention to the "uh oh"

I pushed the second option for now. If we're good with that, I can go ahead and merge after approval.


update dependencies, fix clippy warnings, bump to 0.11.0

Signed-off-by: stevelr<EMAIL_ADDRESS>

Unless we are in a rush to finalize 0.11, I'd recommend we wait until the bugfix release of oci-distribution is released: https://github.com/krustlet/oci-distribution/pull/37

Unless we are in a rush to finalize 0.11, I'd recommend we wait until the bugfix release of oci-distribution is released: krustlet/oci-distribution#37. This would make it so we don't have to cut another release

@thomastaylor312 BTW, this PR https://github.com/wasmCloud/wash/pull/269 already resolved what that bugfix ends up fixing, it'll be a slight internal refactor on our side but won't require a semver bump


Add TypeScript definitions

Original issue: https://github.com/reactjs/redux/issues/1401

Do we want somebody else to review these too, or is this good to merge?

I'd suggest adding tests for typings (like in DT)
Please take a look at my proposition -> https://gist.github.com/ulfryk/69981ccfb488647b6ee3 .

for example
export function createStore<S>(reducer: Reducer<S>, initialState?: S, enhancer?: StoreEnhancer): Store<S>;

does not give strict rules of use, look at this instead:
interface IStoreCreator extends Function {
    <S>(reducer: IReducer<S>): Store<S>;
    <S>(reducer: IReducer<S>, enhancer: IStoreEnhancer<S>): Store<S>;
    <S>(reducer: IReducer<S>, initialState: S): Store<S>;
    <S>(reducer: IReducer<S>, initialState: S, enhancer: IStoreEnhancer<S>): Store<S>;
}
…
interface IStoreEnhancer<S> extends Function {
    (createStore: IStoreCreator): IStoreCreator;
}
…
const createStore: IStoreCreator;

etc. etc.
Of course I'm not talking about naming convention (ignore I prefix if you want). What is the most useful in my proposition - it's the strict set of rules how  createStore() can be used.

If we can add tests for these, we should add tests.

@ulfryk As far as I can see from createStore source, enhanced store creator has only one signature:
https://github.com/reactjs/redux/blob/master/src%2FcreateStore.js#L49
return enhancer(createStore)(reducer, initialState)

But you are right about original createStore signatures. I'll make a fix.
You are also right about type constraint on action argument for Reducer.
But Dispatch can accept argument of any type, not only Action, if user uses some middleware.
@gaearon DefinitelyTyped uses TypeScript code to see if it compiles correctly against definitions. I've added tests for original PR: https://github.com/aikoven/DefinitelyTyped/blob/redux/redux/redux-tests.ts. But I'll need to figure out how to actually run them here.
Will do it tomorrow.

@aikoven
Enhanced creator
You're right - enhancer has only one signature. But its signature (of course without <S>) is reusable:
interface IStoreEnhancer extends Function {
    (createStore: IStoreCreator): IStoreCreator;
}

here:
function applyMiddleware<S>(...middlewares: IMiddleware<S>[]): IStoreEnhancer;

and here:
interface IStoreCreator extends Function {
    <S, A>(reducer: Reducer<S, A>): Store<S>;
    <S, A>(reducer: Reducer<S, A>, enhancer: IStoreEnhancer): Store<S>;
    <S, A>(reducer: Reducer<S, A>, initialState: S): Store<S>;
    <S, A>(reducer: Reducer<S, A>, initialState: S, enhancer: IStoreEnhancer): Store<S>;
}

Reducer
It can be still a generic type:
interface Reducer<S, A> extends Function {
    <S, A>(state: S, action: A): S;
}

interface IStoreCreator extends Function {
    <S, A>(reducer: Reducer<S, A>): Store<S>;
   …

so anyone who uses some middleware and need many types of action-like-things can use
const rootReducer = (state: MyState, a: any): MyState => {…};
const myStore = createStore(rootReducer);

Has this PR been compared to what has already been submitted to typings/registry?
Which one takes precedence if someone does "typings search redux" not realizing a definition file exists in Redux repo?  I can see it bringing confusion, and in turn, issues opened on Redux repo.

@mikekidder I guess once this PR gets merged it will become official typings for Redux and Typings registry should point to it.

Added some tests using https://github.com/adamcarr/typescript-definition-tester.
For now it requires to add typescript and chai to devDependencies, until this is resolved: https://github.com/adamcarr/typescript-definition-tester/issues/1

@aikoven @ulfryk
I added you both to collaborators with write access and leave this one to you :wink: . Please work it out between yourselves how/whether you’d like to collaborate, and merge this when you think it’s good enough. I also trust you to maintain these and will ping you if we introduce any changes to the API.
Thanks!

@gaearon - Thank you very much for trust :) We'll try to do our best!

@ulfryk Updated typings. Please also see comments for outdated diffs.
I have one concern for Action type yet. It's clear that user will have to extend Action to describe shape of actions in their app. So if we have
interface Action {
  type: string;
}

then user can have e.g. FSA like this:
interface MyAction<P> extends Action {
  payload: P;
}

or free-shape action:
interface MyAction extends Action {
  [key: string]: any;
}

If you want to constraint type property:
type ActionType = 'A' | 'B' | 'C';

interface MyAction extends Action {
  type: ActionType;
  // ...
}

Although if ActionType was enum, this wouldn't compile, because String Enums aren't supported yet. We could loosen constraint for type to be any, but I'm not sure if we should: values of enum are integers, which would make it hard to analyze action log with DevTools.
Still Redux docs don't enforce type to be string:

Types should typically be defined as string constants.

cc @gaearon

@aikoven - about Action interface - we have 2 possibilities:
Strict
interface Action<T> {
    type: T;
}
// So user will always have to specify type of `type` property

then user can have e.g. FSA like this:
interface MyAction<P> extends Action<string> {
  payload: P;
}

// or

interface MyAction<P, T> extends Action<T> {
  payload: P;
}

or free-shape action:
interface MyAction extends Action<string> {
  [key: string]: any;
}

If you want to constraint type property:
type ActionType = 'A' | 'B' | 'C';

interface MyAction extends Action<ActionType> {
  // ...
}

and TS enums will also work:
type ActionType = { A, B, C }

interface MyAction extends Action<ActionType> {
  // ...
}

or
Elastic
interface Action {
    type: any;
}

It works in all your examples plus TS enums, but User always have to define his own interface/type for actions if he want's stricter mode.
Conclusion
IMO stricter version is much better:
interface Action<T> {
    type: T;
}

@ulfryk Pushed the changes and added tests, please review.
Also we have to take care of typings for other Redux-related libs to make them consistent with these.

Note that Travis build fails on Node 5.

IMO, the action interface shouldn't be generic. type should always be a string.
This is the best alternative to me
interface Action {
  type: string;
}

This is great! Thank you for doing this. I'm on my phone but i can try it on my project to see if everything is working.

@luisrudge I think so too. However, it isn't stated anywhere that action type must be string.

I use enums for action types which translate to numbers:
https://github.com/contacts-mvc/redux-react/blob/master/constants/ActionTypes.ts#L1

@luisrudge - I myself use typescript enums for action types so such definition would make all these typings useless for me and many other ( like @mohsen1 ). Some may use  e.g. Symbol for that…
Type definitions that @aikoven builds here step-by-step with care and love should reflect real situation. And real situation is highly complicated because JS is dynamically typed and it will accept anything here. So generic type (overloaded to meet real life expectations) is the one reflecting real situation.

@luisrudge @mohsen1 @ulfryk How about we add
interface ActionBase<T> {
  type: T;
}

for advanced usage and
interface Action extends ActionBase<string> {
}

for standard string types?

In my opinion it's overkill. Anyone can jest define his own:
type MyAction = Action<string>;

@aikoven - I feel that we are almost there. I'll read it through once more tomorrow and probably thumbs up will go :)

It would be nice if other folks reviewed this as well. @wbuchwalter @xogeny

I will post the link on Twitter.

We may also want to wait until https://github.com/adamcarr/typescript-definition-tester/pull/2 gets merged to keep devDependencies clean.

I'm very happy with that PR. Big improvements over the current definitions at DefinitlyTyped, so :+1:

This current iteration looks good.  Ship it!  Thanks to @aikoven and @ulfryk for all the effort on this.

If you add JSDoc style comments to the types you get awesome autocomplete/intellisense in VS Code and others editors. Great for people diving into redux.

These type definitions look :sparkles: to me.

can we use union types here?
interface Action {
  type: string | Number;
}

FYI, I'm digging into this.  I'm converting one of my open source projects to use this version.
Main sticking point was Action.  I swear I read somewhere that type had to be a string but it seems I was wrong.
As I see it, there are two important uses for Action.  The first is to say that the reducer takes an Action as an argument.  In this case, it is clear that the argument type needs to be Action<any> since the reducer needs to be able to accept all actions in the application and we cannot know a priori what type type will have for those.
The other important use is for implying a type constraint on our actions (i.e., the Actions we create ourselves).
I think it would be clearer to delineate these two as different types.  Honestly, redux really only uses Action<any>.  It neither uses nor cares about the type of type.  So specifying a type constraint on type is only helpful to people writing their own actions.  Said another way, having a type parameter on Action doesn't add any real type safety because redux doesn't specify the type of type.
So, I would propose that we leave Action as:
interface Action {
  type: any;
}

Since that accurately expresses reduxs definition of what an action is (no more, no less).  But also include:
interface TypedAction<T> extends Action {
  type: T;
}

That allows people to impose type constraints on their actions when defining them but avoids lots of Action<any> all over their reducer definitions.  Of course, users can simply do stuff like this (without needing TypedAction):
interface MyAction<T,P> extends Action {
  type: T;
  payload: P;
}

Now they get the type constraints on type and any others they wish to specify as well.  So TypedAction might be good for being more explicit, but I don't think it is super important.
To add one final point, in my migration most changes were to Action<any>.  Only in a few cases, did I actually need to use Action<string>.  My case might be unusual in that I'm extending from Action (in one place) to define an Operation type.

I swear I read somewhere that type had to be a string but it seems I was wrong.

We only require that it isn’t undefined. Although we definitely recommend strings.

As a completely anecdotal point of reference, I checked and I changed Action to Action<any> 15 times in the code I just converted (to use this PR) and to Action<string> only 2 times.  Both times I used Action<string>, I was defining a type so I could have used either a TypedAction definition or simply inlined the specification of type into my type.  So I'm inclined to drop the type parameter from Action.

Added a small note on ActionCreator and type safety.
https://github.com/reactjs/redux/pull/1413#discussion_r53500086
I don't want this to be a blocker, but would appreciate any ideas to help with safety.

@luisrudge - Current proposition covers this union type. Just do:
type SomeAction = Action<string | number>;

@xogeny - I think that:
interface Action {
  type: any;
}

is elastic but does not encourage type safety… JS is flexible. Static typing adds lot of safety. Flexibility is the cost. I think that parametrised Action<T> type is best solution for most cases:
You can define one interface/type type AnyAction = Action<any> and use it in all places where you had to change Action to Action<any>

@ulfryk First, I totally agree that static typing adds a lot.  You will not get any argument out of me on that.
My point, just to reiterate, is that redux itself imposes no type constraints.  The type of action recognized by a reducer is not included in the reducer type (nor should it, because of the way reducers  that take potentially different types of actions are composed).  As such, knowing the type of type gives no benefit because the Reducer type is generic (with respect to action type).
I actually thought about the type AnyAction = Action<any> approach.  But then every instance of Action in index.d.ts would be changed to AnyAction and it would be really confusing because Action would then be effectively gone (as far as the redux API is concerned).  That's why I think it is better to make Action include type: any and have an alternate interface (e.g., TypedAction) for cases where it makes sense to impose type constraints.  Then Action is used consistently in the description of the API but more strongly typed actions can still be defined.
As I mentioned before, in migrating to these type definition, almost all my work was in changing Action to Action<any>.  That is a lot of work with no static typing benefit.  In the cases where I could benefit from static typing, I used it.  But I don't think it is good "marketing" to force people to do all the work of specifying a type parameter when it doesn't given any benefit (especially when what I'm proposing doesn't preclude providing typing information when useful).

I totally agree with @xogeny, why should Redux care for what types you use in your application?
As far as Redux is concerned, the type is not generic (Redux doesn't know what that is) and the type of the type property is any as there are no way to disallow undefined in the Typescript type system.
If you define an Action type in your program with a specific type for the type property it would also fulfill the Redux Action type, you don't need to extend it or anything like that. Typescript isn't a classical language, it doesn't need an inheritance chain to fulfill an interface.

@xogeny , @Pajn  - I think I understand your point of view now. And I tend to agree.
@aikoven - what do you say?

Personally I'mt not a fan of <A, B>(action: A) => B, it gives exactly the same type safety as (action) => any. And if you want to type it afterwards all you have done is moving the type casts into the generic type parameters.

Please don't force me to use string to differentiate Action types.  Ideally, I can differentiate my types using typescript classes and check which type using instanceof.

Hey guys please consider adding short summaries in JSDoc format. i.e.
export interface Store<S> {
   /**
    * Adds a change listener. It will be called any time an action is dispatched, and some part of the
    * state tree may potentially have changed. You may then call getState() to read the current state tree
    * inside the callback.
    *
    * To unsubscribe the change listener, invoke the function returned by subscribe.
    */
    subscribe(listener: () => void) : Unsubscribe;
}

@mikemorton - Can you elaborate?

@Pajn - of course we can extend type to:
export interface Dispatch {
    (action: any): any;
    <A>(action: A): A;
    <A, B>(action: A): B;
}

So it's useful for you and useful for me ;)

@ulfryk - But how is it useful.  If you have <A,B>(action: A): B, how would you use it.  As far as I can tell, you'd have to do something like ret = <MyAction,MyReturn>dispatch(action).  I think @Pajn's point is then you might as well do ret = dispatch(action) as MyReturn.  It is shorter and doesn't complicate the definition of Dispatch.  The issue is that <A,B>(action: A): B doesn't enforce any type safety because you just specify A and B yourself...nothing gets inferred so there are no real type constraints here.  At least as far as I can see.

Ideally, I can differentiate my types using typescript classes and check which type using instanceof.

This is something we discourage although I know TypeScript community feels different. We want actions to be plain objects because then you can serialize them, record and replay them. If you rely on instanceof both serialization and hot reloading would break. This is why we only allow plain objects as actions.

Please don't force me to use string to differentiate Action types.

This is right, types don’t have to be strings. For example some people like to have Symbol types, although this is also problematic for serialization.

@xogeny

The issue is that <A,B>(action: A): B doesn't enforce any type safety because you just specify A and B yourself...nothing gets inferred so there are no real type constraints here.

Actually seems that you are right.
At first we dropped (action: any): any; and replaced it with much stricter <A>(action: A): A; (which is true for basic dispatch in redux implementation). But then it appeared that it may be false after applying middleware so things complicated and we needed <A,B>(action: A): B. @Pajn pointed out that that the second one actually is equal to (action: any): any;.
You are also right - it is safe enough to use ret = dispatch(action) as MyReturn or classic ret = <MyReturn>dispatch(action). And it for sure makes both parametrised overloads redundant here.
What do yo say @aikoven ? Should we go back to:
type Dispatch = (action: any) => any;

?

w.r.t. Dispatch, my opinion is that a Store should have a dispatch method with the signature (action: Action) => Action.
Yes, I know that application of middleware can wrap the Store in such a way that the dispatch method can become something else (e.g., (action: Action) => Promise<T>).  But it is my contention that the result is no longer a Store, but something else.
The reason I think this is important it that a Store introduces a type constraint (that dispatch returns something with the same type as its argument).  Other "types" of stores might support other type constraints.  It is useful to enforce that type constraint (for static type checking reasons).  Making it (action: any) => any doesn't provide any useful type constraint.  For that matter, neither does <A,B>(action: A) => B since the type constraint being expressed isn't coming from the store, but is just being arbitrarily imposed.
The only way to retain a meaningful type constraint (that I can see) is to actually have the type constraint reflected in the store itself.  That means that applying middleware should fundamentally change the type of the store (because, after all, it does).

I tend to agree with @xogeny comment: typings should reflect constraints that are imposed by Redux API, nothing more.
E. g. reducer action argument must have type property; state argument and return value must have the same type.
Considering dispatch overloads: I first thought that by type-safety @ulfryk meant using dispatch like this:
store.dispatch<MyStrictAction>(action)

which would keep us from accidentally passing wrong argument. Although I would not use this approach myself and would let compiler do all the inference.
@xogeny I've experimented with Store having default dispatch signature (action: Action) => Action and letting StoreEnhancer provide extra dispatch signatures, see https://github.com/reactjs/redux/pull/1413#discussion_r53141654
Although it gets really complicated when extra dispatch signature have to reference final dispatch, e.g.:
type Thunk<S, O> = (dispatch: FinalDispatch, getState?: () => S) => O;
type ThunkDispatch = <S, O>(thunk: Thunk<S, O>) => O;

type FinalDispatch = DefaultDispatch | ThunkDispatch;

We get recursive types that aren't easy to build.

While I would like to keep the types should be kept the way Redux uses them, it would be just impossible to use Redux with Typescript without casting the store to different things all the time.
Why?
Because the ecosystem is just too diverse an built around composing and replacing which is great concept but doesn't play very well with types. For example nearly all applications will include some kind of middleware to do async actions, may it be using thunks or promises (or something else). By doing that basic thing which most users will do, they will get false negatives if the dispatch is typed as (action: Action) => Action.
With both (action: Action) => Action and (action) => any most applications would need to modify that type both to get type saftey and to get away from false type errors. However with (action) => any all applications would just work and the users who need or want better type safety can still specify a stricter type in their application (which they would need to do anyway).
Getting trickery with StoreEnchancer doesn't help very much as a middleware can change that type as well so that trickery would need to allow types to flow from the middlewares, getting unioned and flow into the store enhancers and finally flow into the dispatch method. And even if that would be possible to type with some insanely complex type definition all middleware and store enhancer would need to be typed as well, otherwise we would end up with (action) => any anyway.

As Typescript automatically discovers the typings file, having to strict typings would be a breaking change requiring a new major version as otherwise everyone would start to get compilation failures.

It's probably worth pointing out that if you want more type safety than the official Redux definitions give you, it's relatively easy to write a set of wrapping functions with stricter type definitions. For example:
interface MyAction {
    type: "INCREMENT" | "DECREMENT";
}

function myDispatch(action:MyAction) {
    dispatch(action);
}

So I did more experimenting with StoreEnhancer being able to extend Store type.
My latest approach was based on adding type parameter to StoreCreator that specifies type of Store extension:
export interface StoreCreator<E extends {}> {
  <S>(reducer: Reducer<S>): Store<S> & E;
  // ...
}

export const createStore: StoreCreator<{}>;  // no extension for default store creator

In turn, StoreEnhancer can extend StoreCreator extension:
export type StoreEnhancer<E extends {}> =
  <F extends {}>(next: StoreCreator<F>) => StoreCreator<E & F>;

Middleware is able to add new dispatch signature:
export function applyMiddleware<D extends Dispatch>(
  middleware: Middleware<D>
): StoreEnhancer<{dispatch: D}>;

However, subsequent experimenting failed, because enhanced Store gives:
const store = createStore<S>(reducer, applyMiddleware(middleware));

typeof store ==  Store<S> & {dispatch: D};
typeof store.dispatch == ((action: Action) => Action) & D;

but correct dispatch type should be
typeof store.dispatch == ((action: Action) => Action) | D;

Conclusion
We should probably stick with simplest dispatch type:
type Dispatch = (action: any) => any;

It seems to reflect reality. :+1:

What about combineReducers and bindActionCreators? Should we drop extra type parameters there as well?

combineReducers
We currently have two overloads for combineReducers.
First overload
export function combineReducers<S>(reducers: ReducersMapObject): Reducer<S>;

But without type parameter this
const reducer = combineReducers<MyState>(reducers)

becomes this:
const reducer: Reducer<MyState> = combineReducers(reducers)

which is more verbose. So I'd leave type parameter here.
Second overload
export function combineReducers<S, M extends ReducersMapObject>(
  reducers: M
): Reducer<S>;

With second type parameter:
const reducer = combineReducers<MyState, MyReducers>(reducers)

Without:
const reducer = combineReducers<MyState>(<MyReducers>reducers)

which has almost same verbosity. So I'd drop this overload.
bindActionCreators
export function bindActionCreators<A extends ActionCreator<any>>(
  actionCreator: A, dispatch: Dispatch
): A;

export function bindActionCreators<
  A extends ActionCreator<any>,
  B extends ActionCreator<any>
>(actionCreator: A, dispatch: Dispatch): B;

Not sure if we can drop one of these, because they describe different cases: first is when dispatch returns its argument, and second is when dispatch returns something else, e.g. Thunk case.

:+1:  for dropping 2nd overload in combineReducers

bindActionCreators
have 4 overloads actually:
export function bindActionCreators<A extends ActionCreator<any>>(
  actionCreator: A, dispatch: Dispatch
): A;

export function bindActionCreators<
  A extends ActionCreator<any>,
  B extends ActionCreator<any>
>(actionCreator: A, dispatch: Dispatch): B;

export function bindActionCreators<M extends ActionCreatorsMapObject>(
  actionCreators: M, dispatch: Dispatch
): M;

export function bindActionCreators<
  M extends ActionCreatorsMapObject,
  N extends ActionCreatorsMapObject
>(actionCreators: M, dispatch: Dispatch): N;

And I think that 1st and 3rd are really useful for all situations where dispatch returns what it gets.
2nd and 4th are a little verbose, but dropping them in favour of bindActionCreators(ac: any, d: Dispatch): any will lead to situation in which 1st and 3rd become useless. So I'm for keeping all for overloads here.

Updated PR. This update removes redundant type parameters, fixes compose definitions and adds JSDoc.

I don't use combineReducers or bindActionCreators, so I don't have a strong opinion there.  But I just grabbed the latest index.d.ts and dropped it in with some of my code, and it worked perfectly.  So :+1: for the current definitions of Action, Reducer and Store.
@aikoven I applaud your effort to try and formulate a clever type system based approach for gradually widening the type for stores.  Too bad it didn't work, but thanks for trying.
Finally, big thanks to @gaearon for agreeing to bundle these bindings!  I'm super excited about having these bindings in the NPM module. :clap:
From my perspective, this is good to merge.  Everything I need/use looks good!

I also tested new typings in my app and all I can say is :+1: and kudos to @aikoven

@Pajn @wbuchwalter Could you guys please review it one last time?

:+1:
I also tested the new defs with my different projects, everything looks good!

Sorry for not being active recently. I think the current one looks great, very nice to get the documentation too!

Nice job! Please release this in a major version.

:clap: :clap:
Very excited to see this merged. Thanks everyone.

:cake:

Will we need to bump a major for this? This can potentially break people, right?

I also don't think that bumping major is necessary. Things can break because some of DefinitelyTyped typings dependent on Redux may become incompatible. But bumping major won't help here because DefinitelyTyped isn't good at versioning anyway.
I will run DT tests against these new typings in a couple of days to see which ones should be updated.
Also I think that maybe we should make official typings for them as well instead of updating DT.

I’m confused :sob:

But bumping major won't help here because DefinitelyTyped isn't good at versioning anyway.

If we release this as a minor version and npm install can break people’s builds because of that, then we must bump major. If they have problems after npm install redux@latest it’s fine because we can say it’s a breaking change. The most important part for me is that people have have "redux": "^3.0.0" in their package.json are not going to have broken builds on npm install after we release this.
So do we need to bump major or not? (There are a few more things I will get into Redux 4 anyway so it’s not a big deal.)

@gaeron Yes, this can break people's builds if they are using a community type definition or a custom definition of their own. I vote for bumping major.

That’s what I wanted to know. We’ll get this into Redux 4 then.

@joshuacc Really?
In my tests TS takes the community one before the one in the package so should only break if the user removes the community one (which would break anyway as there are no typings in that case)

@Pajn I believe so, but am away from my computer for the weekend, so can't verify with 100% certainty. It may be different depending on whether using ambient or external typings.

As far as I can tell, ambient modules should take precedence over external ones.
See section 11.3.1 of TypeScript specifications:

If the import declaration specifies a top-level module name and the program contains an
AmbientModuleDeclaration (section 12.2) with a string literal that specifies that exact name, then
the import declaration references that ambient module.

If the import declaration specifies a top-level module name and the program contains no
AmbientModuleDeclaration (section 12.2) with a string literal that specifies that exact name, the
name is resolved in a host dependent manner (for example by considering the name relative to a
module name space root). If a matching module cannot be found an error occurs.

So this should not break anyone.

I didn't know ambient module take precedences. If that's the case it shouldn't be breaking changes for my case.

Umm, what are these: https://github.com/andrew-w-ross/typings-redux the "typings" (the official replacement of tsd which is now deprecated) installed these. I don't know what is the tsdm @Pajn is referring to, it probably is some fork and not preferred?

@Ciantic tsdm is a tool for using type definitions from npm https://github.com/shyiko/tsdm
I much prefer using npm than other solutions that are not as refined, however it's not the "official typescript way".

@Pajn but if tsd says its deprecated and redirects all of it's users to typings, that be becomes standard on which all typings must be available. I gather the redux typing is available from typings once they become released?

@Pajn also, typings is partly to blame for the confusing user experience. It does not say whose typings it installs:
typings install redux --save
? Found redux typings for NPM. Continue? (Y/n) Y
Installing<EMAIL_ADDRESS>(NPM)...
└── (No dependencies)

It says its coming from some npm, but not which, when one looks at the typings.json however it says:
{
...
"redux": "github:andrew-w-ross/typings-redux#2e0b57e18c6240d17fde045573d74e649762437b"
...
}

which clearly points to someone elses NPM.

@Ciantic This is about the Redux typings beeing avalible in the actual redux module so that you can use it without installing any typings at all.

@Pajn I know, but once they become available, people still run "typings install package" blindly  because they are accustomed to do so, it should give or somehow install the same official typings and not some unofficial ones.

I opened an issue to typings: https://github.com/typings/typings/issues/320 I think it should be more clear whose typings it installs, I could have thought from it's output it installed some sort of official typings from NPM.

Please note #1526

This too #1537

For everyone concerned with stronger typings for dispatch, please see @Igorbek's proposal: #1537.
It's based on module/interface augmentation introduced in TS 1.8. So to add dispatch signature for e.g. redux-thunk, you would do:
// redux-thunk.d.ts

declare module "redux" {
    export interface Dispatch<S> {
        <R>(asyncAction: (dispatch: Dispatch<S>, getState: () => S) => R): R;
    }
}

This looks like a decent solution to me, but I'd like to hear from others before merging.

@aikoven
Sorry I haven’t been maintaining Redux closely for the past couple of months.
What’s up with these? Are we good to cut a minor release with this, or shall we wait for more changes?

@gaearon IMO we should wait at least for #1537.
Also there's a discussion #1526 considering StoreEnhancer/StoreCreator types.

Would it be impossible to throw the contents of these: https://github.com/reactjs/redux/blob/master/index.d.ts to inside the declare namespace in here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/redux/redux.d.ts
I had to do it manually couple of times already.
Currently most people are getting their types from there, at least it would match the official types in upcoming release this way.

@aikoven OK. Ping me here or, if I miss it, on Twitter, when you’re ready to cut it.

@Ciantic We'll probably have to copy these typings to DT, because it seems there's no other way to treat other typings in DT that are dependent on Redux.

@gaearon We're good to go

@aikoven What’s the latest consensus, is doing this in a minor bump okay?

I've tested for my build: DT typings take precedence over these, so they don't break anything. New Redux typings seem to be ignored unless user takes some steps i.e. manually unlink other dependent libraries' typings from old DT Redux typings so that TS compiler could resolve imports from redux to new ones.
So yes, it is safe to release this as a minor.

What if the user had no typings at all? Is this possible in TypeScript?

@gaearon if user hadn't DT typings, the typing shipped with the module would be resolved. That said, a user that just installed 'redux' module can start using TypeScript without need to install DT or other external typings.

Then this is a breaking change.

User has no typings
We add typings in a minor version
Their build process fails

Is this correct?

I don't think it will fail. If user had no typings it wouldn't be able to use any explicit redux types.

Anyway, I might misunderstand and if it's possible to break a build somehow, it's a breaking change that needs major.

Can we then bump major without waiting until other issues from 4.0 milestone are resolved? There's increasing number of people who want this released asap. How about RC version?

Personally, I'm pretty sure that adding typing bindings is a non-breaking change that theoretically might break build in very synthetic case. Anyway, I'm not insisting.

User has no typings
We add typings in a minor version
Their build process fails

Then the user is not using TypeScript, because it's not possible to go past point number one on this list.
Because you can't use TypeScript without typings, they get big honking error message if they try to use redux without typings. It just doesn't compile until there is some error message and they have to either write any declaration themselves or install them from DT.
Though, most of the people using TS has to deal with wildly changing typings anyway, so if there is some hypothethical case where someone has used redux without typings, and if typings entry appears it suddenly uses TS, it's a weird one.

I 100% agree with @Ciantic

@gaearon I guess the consensus so far is that bumping major is not necessary here.

Out in 3.4.0.


Slower Calls After Update

Hi, I have been using SimpleGraphQL package for one of the games I am developing and recently when I update to the latest version I noticed a bit of a lag when making requests. Not sure where the problem is but the lag is noticeable. The package version I was using before is 1.1.3 and I have updated to version 1.2.0.

Hi, I have been using SimpleGraphQL package for one of the games I am developing and recently when I update to the latest version I noticed a bit of a lag when making requests. Not sure where the problem is but the lag is noticeable. The package version I was using before is 1.1.3 and I have updated to version 1.2.0.

Is it possible for you to provide a test project or some test code? This type of problem is really hard to debug without additional information because it could really be anything causing it.

        Thanks for the reply, I will provide you with some test code first thing on monday.Rafael PloutarchouSoftware Developer Phone: +357 22255604Mobile: +357 99955085Email<EMAIL_ADDRESS>www.spectrum.games   ---- On Fri, 20 Aug 2021 22:23:04 +0300  Navid<EMAIL_ADDRESS>wrote ----

Hi, I have been using SimpleGraphQL package for one of the games I am developing and recently when I update to the latest version I noticed a bit of a lag when making requests. Not sure where the problem is but the lag is noticeable. The package version I was using before is 1.1.3 and I have updated to version 1.2.0.
Is it possible for you to provide a test project or some test code? This type of problem is really hard to debug without additional information because it could really be anything causing it.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.

Hi again I have attached two files one showing the older version and one showing the newer version. I use this code to get data from the server with the SimpleGraphQL package and then deserialize the data with Newtosoft.JSON and add them to an instantiated object on me scene usually on a scroll view. The delay occurs when unity is processing/is waiting on the query and while on the older version the object instantiation was almost instant on the newer version their is a noticeable lag on this part. I am not sure whether this is a problem with this particular package or with the newer version of unity but I would appreciate it If you take a look at it. The scripts I have attached are abstract versions of the scripts I am using In most of my app. Thanks again for the reply.
OldVersion.txt
NewVersion.txt

Hi again I have attached two files one showing the older version and one showing the newer version. I use this code to get data from the server with the SimpleGraphQL package and then deserialize the data with Newtosoft.JSON and add them to an instantiated object on me scene usually on a scroll view. The delay occurs when unity is processing/is waiting on the query and while on the older version the object instantiation was almost instant on the newer version their is a noticeable lag on this part. I am not sure whether this is a problem with this particular package or with the newer version of unity but I would appreciate it If you take a look at it. The scripts I have attached are abstract versions of the scripts I am using In most of my app. Thanks again for the reply.
OldVersion.txt
NewVersion.txt

So I reduced your test cases to just testing the queries with a stopwatch and I was unable to find any significant difference between the package versions. The only difference is the ".ToRequest()" extension method in query.ToRequest(). I've attached my files in case you want to try them out:
SimpleGraphQLTest.zip
If you do try it out and find significant differences in the actual query calling, it may be a platform issue or another deeply ingrained problem.
Please note that the first connection will always be slower than the others because of the WebSocket initialization handshake process. Subsequent calls will reuse the same WebSocket so they are much faster. (All GraphQLClient instances use the same WebSocket too.)
As for your issue, I believe that you are noticing lag possibly because of NewtonsoftJSON's deserialization. It's just an educated guess, but you can try using JSONUtility instead and seeing if that helps. I believe your data structure is simple enough to work. Do let me know how it works out. It may just be a problem with either the deserialization or the gameObject instantiation itself, rather than the actual networking.
I used Unity 2021.1.16f1 and got on average ~12 ms stopwatch time on both versions (located on the East Coast of the US).

Thanks for the quick response, I will try using switching from Newtonsoft to JSONUtility to check if there is any difference and let you know.

Closing for inactivity.


Escape horizontal ellipsis with HTML entity

Hi @mishunov, thank you for your pull request! Unfortunately this change it outside the scope of this module, which is only to escape string for use in HTML, i.e. the only characters actually escaped are the ones that have a special meaning in HTML.


CASSCF Convergence Issue

I'm performing a CASSCF calculation with a Mn atom (6o, 7e) at high spin state (S^2 = 8.75) using csf_solver as the fcisolver.
The output file is attached, the system no longer appears to change after 18 macro cycles, yet is not converged after 150 macro cycles.
out.txt

The input is missing

Apologies, please see input.txt.
The original output file was truncated from a series of calculations; the following output is the problematic(?) system alone.
out.txt

Small note:
solver = csf_solver(mol, smult=6)
solver.spin=5

I would set smult appropriately and not bother changing spin. This won't affect your final convergence though.
I have run into this problem before and I believe it is a bug in the csf_solver due to the stepsize going to zero before convergence is reached. You can see in your output that |maxRot[o]| = 0.0000 eventually, meaning that it cannot take any step (despite not reaching convergence). @MatthewRHermes would know better how to solve this.

With that spin, in that active space, the wave function is effectively single-determinantal - there are multiple configurations, but they're all expressible as |211111> after an orbital rotation. The csf_solver is actually unnecessary here, because spin contamination is impossible.
There may be some subtle interaction here between csf_solver and the mcscf kernel that's undesirable. But the real underlying problem is that one active orbital is 100% occupied, so the energy is 100% insensitive with respect to rotation between that active orbital and the inactive orbitals. This means that there is a redundant degree of freedom in the orbital optimization subproblem. Redundant degrees of freedom reliably spoil convergence. But for the same reason, the (5o,5e) active space would yield strictly exactly the same wave function (it's really just a ROHF wave function). Why not try to optimize the (5o,5e) case instead?

An alternative is to increase the size of the active space by adding a virtual orbital which correlates to the doubly-occupied active orbital - 5s to correlate with 4s, in this case. Doing this would remove the redundancy by permitting the occupancy of the 4s orbital to deviate from exactly 2, and would also reintroduce some risk of spin contamination (which csf_solver would obviate).

Adding an extra 5s orbital solved the issue, thank you so much!


Hardly audible FIFO channels in Yu-Gi-Oh! Dungeondice Monsters (GBA)

Music tracks sound different, and some sound effects are either muted or not properly played.
I've run the game on mGBA, manually unchecked the FIFO channel (the A one, not B), and got the exact "incomplete" audio.
However when checking SkyEmu's stats, there is an audio "output" from FIFO A, but it is extremely weak.
Using an official GBA bios on SkyEmu does not change anything unfortunately. FIFO channels are active during the GBA jingle, but happen to be still exceedingly low in the game.
Finally, I've noticed that after playing the game for a little while, the FIFO channel B increased its audio activity, as if trying to properly play sound effects (dice unfolding sounds, monster roars, etc.).
I will be providing additional info such as screenshots, screen record eventually, save file if needed, etc.; however, the bug requires nothing for it to occur, the FIFO channels are just super low from the start.

I've noticed that a certain attack causes an output spike in FIFO B, but the sound effect sounds like the crispy creaking of a wooden door, funnily enough.

This audio issue is exclusive to the US and European versions of the game; for a reason, the Japanese version's audio makes perfect use of both of its FIFO channels.


test how trading page and portfolio pages behave on actual mobile devices

How? It's possible to point you mobile phone to sneakpreview.augur.net, I'm I understanding the reason for this tix?

yea. you can use a simulator or going to sneakpeak


SOLR-15561: Write escaped strings in JsonTextWriter to a StringBuilder before the writer.

SOLR-15561 Write escaped strings in SolrJSONWriter to a StringBuilder before the writer.

This seems like a reasonable change. I merged main to this branch and PR is ready to review.

I dunno... if a benchmark shows its faster then cool but I think it's dubious -- probably a needless level of buffering on something that likely already has a buffer.


How to hide table header?

Overview of the problem
There doesn't appear to be an easy way to hide the Table header.
Buefy version: 0.5.2
Vuejs version: 2.4.2
OS/Browser: Linux/Chrome
Description
I've tried leaving the label attribute for all columns as a blank string, adding an empty custom header slot and manually hiding thead via css however I'm still left with a gap at the top of the table where the header would be.
I basically want all of the table functionality just without the column headings.

@proehlen By css you can hide thead .table thead { display: none; } (that example apply for all
Anyway you should set customKey prop for all columns if they have empty label prop.

@jtommy Thanks a lot.  I was still getting the blank header area with your CSS but then on a hunch I also added :has-modal-cards="false" and it went away.  Thanks again for your help.

@proehlen By css you can hide thead, for example .table thead { display: none; } but surely you know that sorting will be lost.
Anyway you should set custom-key prop for all columns if they have empty label prop.

To anyone trying this solution, be aware that .table thead { display: none; } will also break the width property (i.e., width="40" will no longer work)


Allow source file selection in task drop-down

My understanding is that currently the source XML and XSLT files that are fed to Saxon are specified in the tasks.json file in the .vscode subfolder of the project.  I'm prone to typos, so manually specifying the file is a challenge.
I've used the Tasks Shell Input extension (https://github.com/augustocdias/vscode-shell-command) to augment my tasks.json file so I can select the relevant files from a dropdown list in the command palette:
{ 	"version": "2.0.0", 	"tasks": [ 		{ 			"type": "xslt", 			"label": "xslt: Saxon Transform (New)", 			"saxonJar": "${config:XSLT.tasks.saxonJar}", 			"xsltFile": "${input:xsltFile}", 			"xmlSource": "${input:xmlFile}", 			"resultPath": "${workspaceFolder}/xslt-out/result1.xml", 			"allowSyntaxExtensions40": "off", 			"group": { 				"kind": "build" 			}, 			"problemMatcher": [ 				"$saxon-xslt" 			] 		} 	], 	"inputs":[ 		{ 			"id":"xmlFile", 			"type":"command", 			"command":"shellCommand.execute", 			"args":{ 				"command":"dir /b \"${workspaceFolder}\\*.xml\"" 			} 		}, 		{ 			"id":"xsltFile", 			"type":"command", 			"command":"shellCommand.execute", 			"args":{ 				"command":"dir /b \"${workspaceFolder}\\*.xsl?\"" 			} 		} 	] }
This is a windows-specific hack.  It uses the dir command, it relies on another extension, and it doesn't have any drill-down to get to XML and XSLT files in workspace subfolders.  Even still, it's a labor-saver for me.
It would be cool if you could augment your extension with easy file selection capabilities.

Your understanding is correct and thanks for this feature request. I have been pondering simplifying file-path entry into the tasks.json file for some time.
I will investigate options for file selection. My first instinct is (if possible) to add two menu items to the VSCode File Explorer. This is inspired by the existing Select for Compare and Compare with Selected context menu options on the File Explorer. The two commands might be something like:

Select Src XSLT task
New XSLT task with Selected (using the current file as the XML source)

Hopefully commands can be set for the File Explorer in this way, if not there will probably need to be a standalone command that invokes a pick-list for selection of the XML input and the XSLT source files.

XSLT task properties can now reference new commands that allow file-selection via a file-explorer or a 'recently used' file list. These commands are documented in: Running XSLT
In the screenshot below you are prompted to either select a recently used file or select 'Pick File' that will show a File Explorer:


Magellan Default Documentation Incorrect

The documentation for magellan states the following are the default values:

data-animation-easing: ease-in-out
data-deep-linking: true
data-bar-offset: 25

However, based on the code (below), it appears as though those are example values and the values are in fact:

data-animation-easing: 'linear'
data-deep-linking: false
data-bar-offset: 0

/**
 * Default settings for plugin
 */
Magellan.defaults = {
  /**
   * Amount of time, in ms, the animated scrolling should take between locations.
   * @option
   * @example 500
   */
  animationDuration: 500,
  /**
   * Animation style to use when scrolling between locations.
   * @option
   * @example 'ease-in-out'
   */
  animationEasing: 'linear',
  /**
   * Number of pixels to use as a marker for location changes.
   * @option
   * @example 50
   */
  threshold: 50,
  /**
   * Class applied to the active locations link on the magellan container.
   * @option
   * @example 'active'
   */
  activeClass: 'active',
  /**
   * Allows the script to manipulate the url of the current page, and if supported, alter the history.
   * @option
   * @example true
   */
  deepLinking: false,
  /**
   * Number of pixels to offset the scroll of the page on item click if using a sticky nav bar.
   * @option
   * @example 25
   */
  barOffset: 0
}

Can someone please give some feedback on this? Also, how could I actually make ease-in-out happen??

@phifa You can set the data attribute to "ease-in-out" - "linear" is what's happening by default.  The docs are not incorrect in capturing how the functionality works, just what the default values are set to.

actually not true for me. when i set ease-in-out, i get a console error:
jquery.js:6369 Uncaught TypeError: jQuery.easing[this.easing] is not a function
Without it, it works, but only linear - not looking so nice. I am on Foundation 6, downloaded yesterday.

For anyone having trouble with magellan, I found this on Zurb's building block's library. It was the most straightforward approach, worked right away and probably should be added to the docs.
http://zurb.com/building-blocks/sicky-sidebar-using-magellan


feat(lint-style): lint on the plain string 'Adaptation note:'

ask to use #adaptation_note instead.
This command is a unified place to annotate all commands, and avoids typos.

[ ] depends on: #13665 for rewriting the existing 63 occurrences

bors d+

bors r+


WIP: Docs process

Codecov Report

Merging #126 (dff69da) into beta (171b403) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             beta     #126   +/-   ##
=======================================
  Coverage   17.37%   17.37%
=======================================
  Files          19       19
  Lines         213      213
  Branches       49       49
=======================================
  Hits           37       37
  Misses        166      166
  Partials       10       10

Help us with your feedback. Take ten seconds to tell us how you rate us.

Reminder: add licence choice description