Chrome Profile?

How can i start chrome with arguments ? or create a chrome profile?

How to use Firefox profile?

Hi @zhongguo168a - this is currently not supported IIRC. It's been a while since I dealt with this package ...

Whoops, I closed the wrong bug (even though this one went off to talk about Firefox profiles). Chrome profiles are next.

ChromeDriver doesn't permit setting the profile directly, but the chrome.Capabilities type now allows you to set preferences, local state, and extentions (among others) directly.

Has anyone been able to successfully set the Chrome profile?


Add example to README

Adding a small example to the README for people browsing and trying to find out what this does.
P.S. Would love to see any improvements to this, it was super useful to me!

This change is

This isn't really compete yet. In fact, it's stalled and may be removed. Take a look at https://github.com/webcomponents/react-integration instead.


Add Orthogonal Projection Generator

A new generator for orthogonal projection problems in $R^2$

Example
Answer

Find the orthogonal projection of $[2, 3]$ onto $[4, -7]$
$[\frac{-4}{5}, \frac{7}{5}]$

Very nice. Works perfectly. Thanks!


feature/path-varible-regonize

Hello @Bidaya0! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file dongtai_engine/signals/handlers/vul_handler.py:

Line 124:1: E305 expected 2 blank lines after class or function definition, found 1


seems to be incompatible with plasma 6, black screen on boot

changing sddm theme to breeze solved it

Most likely because it needs to be ported to be compatible with Plasma 6. See here: https://develop.kde.org/docs/plasma/theme/theme-porting-to-plasma6/#changes-for-sddm-login-themes

Currently looking into the changes that need to be made. Hopefully i can get this out within the next 2 weeks.


Feature request: show day difference for extra clocks

When using multiple clocks, an indicator of +1 day or -1 day would be nice if the calendar day is different than the one of the primary clock.

Good idea, thank you! Question for you though, would you like something that says +1 or -1, or would it be better for you if each clock had it's own date as well?

I use iOS's clock app with many clocks, and I find its treatment great. It shows +/-1 day as well as the hour offset for each timezone:

Thanks for the screenshot! Great idea, I'll definitely look into this.

I implemented this feature, but it's based on branch where I worked on linting for the project. It'd be great if the linting could be merged first if you like the work, otherwise I will rebase my changes and send a different PR for them.
https://github.com/ssorallen/carettab/commit/4c5d42f9fa6c78f7126694d31257bcdb88263163

Very much appreciate the efforts, it does look great!
Unfortunately I won't be merging this in necessarily. I am currently rewriting carettab from scratch in a separate temporary github repo so a lot of things will change, but I will definitely use your changes when I get to this part in the new version :) I apologize though, I'll admit I don't know how to use github the best, and am still learning JavaScript (if that wasn't obvious from my code lol) so the fact I am in the works to rewrite this is not obvious. Again, will definitely use this, just not via a merge.
Thanks very much!

If you'd like any help setting up the project, I am quite comfortable getting a project like this configured. You could move dependencies into the package.json's "dependencies", configure linting, run a build on Travis for each pull request, and whatever else you might like.
If you want to put your code on GitHub, you can create a new branch and push it to this repo. Then we would be able to work on the same branch.
$ git checkout -b new-branch-name # Create a new branch called "new-branch-name"
$ git push -u origin new-branch-name # Push "new-branch-name" to this GitHub repo

Thanks @ssorallen for now I'm just trying to figure out some basic configuration, don't have a whole lot of time to commit to this now so it's slow going. Once I settle on a path, I'll put it back here as a new branch though. I'm currently using a framework that compiles the extension for different browsers automatically, so with that I got a better npm setup. Don't know about Travis, I'll look into that though.

This has been completed in CaretTab v3 which is currently in Beta at the moment, so I'll be closing this as fixed. If you would like to check it out, you can sign up for the beta here: https://github.com/bluecaret/carettab/issues/104


Fix deploy

Codecov Report

Merging #183 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #183   +/-   ##
=======================================
  Coverage   35.29%   35.29%
=======================================
  Files         186      186
  Lines        3017     3017
  Branches      229      229
=======================================
  Hits         1065     1065
  Misses       1842     1842
  Partials      110      110

Continue to review full report at Codecov.

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


Implement Standards Repo outstanding Checks

Background
In the github-repository-standards there are checks that have not been implemented but the API allows these checks to be implemented.

delete branch on merge: API offers the check, so can be implemented.
have non-empty description (shouldn’t be null or “”): API offers the check, so can be implemented.
be MIT Licensed: API offers the check, so can be implemented.
have recent activity (pushedAt < ?): API offers the check, so can be implemented.
have at least one team with admin access: REST API offers the check, so can be implemented.
have Dependabot enabled: REST API offers the check, so can be implemented.

Out of date. Replaced by #1135


Unique point matrices in NCMesh::NCList [nc-point-mat-index-dev]

Currently, each NCMesh::Slave holds a  DenseMatrix point_matrix. These matrices often repeat, since typically many coarse-fine situations are geometrically similar.
This PR replaces the per-slave matrix with an index into an array of unique point matrices (NCMesh::NCList::point_matrices). This has two advantages:

Some memory is saved, for example when refining inline-hex.mesh randomly 6 times, one obtains a mesh with ~429100 elements, and the RAM taken by NCMesh::face_list and NCMesh::edge_list goes from 242 MB to 91MB (this is rather extreme due to the randomness).
More importantly, slave faces/edges are now basically split into classes based on their position and orientation within the master entity. This can be useful when batching the assembly of DG fluxes (cc: @YohannDudouit)

@YohannDudouit please let me know if this is sufficient for you. One thing that may be missing here is that Mesh::NCFaceInfo doesn't specify the matrix index and at the same time some of the faces get a differently oriented matrix (see the end of ParNCMesh::GetFaceNeighbors).

@rw-anderson can you please review?

I left one more question about docs for edge_flags.  Other than that looks good.

@v-dobrev, this should be good to go.

@v-dobrev, this is good to go into next...

LGTM

Merged in next for testing...

The internal autotests showed that the following two sample runs fail:
ex15 -m ../data/escher.mesh -r 2 -tf 0.3 -no-vis
mpirun -np 4 ex15p -m ../data/escher.mesh -r 2 -tf 0.3 -no-vis

Running in debug mode triggers an assert failure which should help with tracking down the issue.

Re-merged in next.


FileAttachment.arquero

Ref. https://github.com/observablehq/framework/pull/1506#pullrequestreview-2167443702

A question would be, should the .arquero method also work on a JSON or CSV file (or even a "fixed" file, for aq.loadFixed)?

Okay, I added support for CSV, TSV, and JSON.

I've added a bit of documentation.
I this this raises another question: if we want to generalize this approach, shouldn't we have a duckdb method as well, e.g. FileAttachment("data.csv").duckdb()?

We certainly could add a DuckDB method, but I don’t think that should block this PR, and I think it makes slightly less sense in the DuckDB case because typically a database has multiple tables and so you don’t want to give the file attachment primacy (i.e., it’s better to use DuckDBClient.of to accommodate multiple tables than FileAttachment.duckdb which is limited to a single table).

Added support for Apache Parquet files (and preloading which is a bit tricky because we only need to additionally preload parquet-wasm when using an Apache Parquet file with Arquero). Made the Arquero loader detection a bit more robust considering the file extension when the MIME type isn’t sufficient. Also tweaked the documentation a bit.
PTAL @Fil thank you!


Mismatched array length between critical load and load equation error

Describe the bug
-If critical load array length does not match load array length when crit_load_type is switched to 'Use time series critical load data', a equation error occurs.
-Array length cannot be changed unitl crit_load_type is set to 1, so error will always occur if load is different length than default hourly critical load time series
-Occurs when load data is set before grid outages (low priority)
To Reproduce
Steps to reproduce the behavior:

Go to PV Battery Commercial
Choose 15 minute weather file
Set load increment to 15 minutes on Electric Load page
Go to Grid Outage, select 'Use time series critical load data'
See equation error (line 51 of Electric Load Data)

Expected behavior
Somehow avoiding an equation error popping up would be preferred

I fixed the UI issue in https://github.com/NREL/SAM/tree/critical-load-ui-callback so that a message box is displayed when the load and critical load data have different time steps.
However, the simulation runs under this condition. @brtietz, should SSC throw a simulation error when the load and crit_load arrays have different lengths?

I fixed the UI issue in https://github.com/NREL/SAM/tree/critical-load-ui-callback so that a message box is displayed when the load and critical load data have different time steps.
However, the simulation runs under this condition. @brtietz, should SSC throw a simulation error when the load and crit_load arrays have different lengths?

We don't support lifetime load at the moment, right? I could imagine a valid case where someone specified 25 years of load, but used an escalation factor for critical load. However, it seems like currently different array lengths would indicated different timesteps, which seems like it should throw a simulation error.

I fixed the UI issue in https://github.com/NREL/SAM/tree/critical-load-ui-callback so that a message box is displayed when the load and critical load data have different time steps.
However, the simulation runs under this condition. @brtietz, should SSC throw a simulation error when the load and crit_load arrays have different lengths?

We don't support lifetime load at the moment, right? I could imagine a valid case where someone specified 25 years of load, but used an escalation factor for critical load. However, it seems like currently different array lengths would indicated different timesteps, which seems like it should throw a simulation error.

Right, I wasn't clear -- I meant that SSC seems to run when the critical load and load have different time steps. (There is an SSC check that the grid outage time step is correct, but not one for critical load.) The SAM UI is supposed to do a pre-check before running the simulation that is broken -- the UI callback error prevents the simulation from running when load and crit_load have different time steps, so you can't test this condition in the release version, but in my branch that fixes the UI callback error, it is possible for crit_load and load to have different lengths and SSC doesn't complain. We can rely on the SAM UI to prevent that, but I think an SSC check would be good for SDK/PySAM users.


How to forcefully reduce sharp's cpu usage and accept appropriate reduction in running speed?

Question about an existing feature
At present, I use k8s to deploy a pod containing sharp, but when the input image is too large (about 10mb), the top command to view the cpu utilization even exceeds 100%, which may cause the container to restart. This is not what I want. I It is hoped that the container will not restart the order to accept the slowdown. I tried using the command but it didn't work.
      process.env.UV_THREADPOOL_SIZE =1;       sharp.concurrency(0.4);
The following is the cpu configuration of the pod：
cpu: "0.5" memory: 2Gi
What are you trying to achieve?
How can I limit the cpu usage to prevent the container from restarting constantly?

When you searched for similar issues, what did you find that might be related?

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this question

Please provide sample image(s) that help explain this question

sharp.concurrency(0.4);

This should be an integral value, and if not will default to the number of cores, either virtual or physical (which one depends on various things), so you probably want to use sharp.concurrency(1);
You've not provided any information about the formats you're using. For anything that is relatively CPU-heavy such as AVIF then you may need to give it more CPU time as cpu: "0.5" may not be appropriate for a CPU-bound task.

sharp.concurrency(0.4);

This should be an integral value, and if not will default to the number of cores, either virtual or physical (which one depends on various things), so you probably want to use sharp.concurrency(1);
You've not provided any information about the formats you're using. For anything that is relatively CPU-heavy such as AVIF then you may need to give it more CPU time as cpu: "0.5" may not be appropriate for a CPU-bound task.

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


Idea to port this for v0.10.33

Just interested what do you guys how taught would be to port Regiment to work on Node 0.1 & express 3?

We don't have any interest in doing it but pull requests are welcome.
It would have to continue to support the current version of node/express as well.


Question: Filter with basic list

Hi, I'm using the library a long time and is excellent.
I need to make a list (like the basic list), but with a filter (on a EDITTEXT).
I wonder how this can be done using what the library offers.
Thanks.

You can use a custom layout for this, just put an EditText above a ListView in a LinearLayout, and use it as the dialog custom view. You'll need a custom adapter set to the ListView, obviously.

yes, I imagined that was the way, but ask just in case...
I thought it was possible to add a control to the basic list, and use the adapter from the list that the library offers.

Sorry, no, you'll have to use a custom view. I can't add too many small pre-made dialog types to the library.

Thanks, you can close this issue...


Support git partial clones with sparse checkouts (take 2)

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Continuing #13232 since it got closed for going stale. Sorry for vanishing and not finishing this off last time round!
The first five commits on this branch are the same as the commits in #13232, but rebased onto master to ensure they still work with changes made since I originally opened the #13232.
The following two commits (b11df3bef825417b4d67ed9b5639f206e20851bf and 2d68e27d7b1f15f52e88909280777a38ec287d75) rename only_paths to only_path (and make it a string rather than an array), which means we can automatically apply the only_path prefix to artifact sources (as discussed).
The final commit documents installing cask artifacts via git repositories.

Huge thanks for your guidance and help getting this over the line! When I have time I'll update the fonts repos to switch over from svn to this.


Provide images to match Node.js 20.x LTS - 'Iron' (minimum 20.9.0)

Node.js transitioned version 18.x to maintenance status and version 20.x to LTS status on October 24, 2023 (see Node.js release schedule).
v20.9.0 is tagged as the Node.js 20.x LTS.
The most recent cypress/base version published is 20.6.1.
This is an enhancement request for Cypress Docker images (base / browsers / included) to be released covering the Node.js 20.x minimum version 20.9.0.
Edit: The LTS version is 20.9.0, not 20.8.1, however there are no functional changes between the two releases. v20.9.0 is simply the declaration of LTS status and the assignment of the Iron name to this release.
Related

https://github.com/cypress-io/cypress-docker-images/pull/951

PR https://github.com/cypress-io/cypress-docker-images/pull/951 potentially resolves this issue, however publication has not yet been successful in CircleCI.

Resolved through PR #987


abap-environment-abapgit: update urls

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

ohem, okay, I have no idea about the SAP brand names, note that I am an external contributor, not affiliated with SAP
is there an overview of the old vs new tags?

@larshp We appreciate your good intentions, thank you. Please note that only the authors make changes to their tutorials. If you encounter errors or issues with one of our tutorials, please use the "provide feedback" feature in that particular tutorial.

@larshp We have reopened the PR and assigned to the author, who will handle when returning from a short leave. Can I ask you what is your relationship to this tutorial, that is, why did the author reference your GitHub account/repo? Should we have referred to the ABAPgit account or is that something new?

the URL moved to abapGit/abapGit in September 2020, https://twitter.com/LarsHvam/status/1309057808298631169, just updating to reflect the change
Note that the old url still works, but redirects to the new

Hi all,
Thanks Lars for your info.
@MichaelCzcz should I create a new PR with these changes and update Tags too?

@niloofar-flothkoetter  I will merge this PR, but please make the changes in QA version and update the tags, and create a new PR for those. Thanks.


Hover effect in the list component does not work

I have the problem that when I move my mouse over a list item, the hover effect is not visible. In your example everything works. I also copied your code and unfortunately it doesn't work either. Have I forgotten something or is this a bug?

actually this is a bug in our latest flow version, the list item should only have a hover effect if it has an "onAction" or "href" property. it will be fixed with https://github.com/mittwald/flow/pull/999


Calculate rubocop_checksum by caculating a crc32 for each file rather than using mtime

Fixes #8629.
File.mtime is faster, but inconsistent in CI, because in each CI build the mtime changes, which means that the rubocop cache implicitly cannot be used as-is. It's obviously slower to calculate a hash for each file, but this is still more performant (both in memory consumption and iterations per second) than the original.
I wrote a benchmark to test memory and IPS: https://gist.github.com/dvandersluis/0ddbc936fc858fbbec9cf8fb796ec9a2
Calculating -------------------------------------
            original     1.770M memsize (   622.000  retained)
                       587.000  objects (     3.000  retained)
                        50.000  strings (     2.000  retained)
               mtime    27.343k memsize (     0.000  retained)
                       482.000  objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
           file hash     1.586M memsize (     0.000  retained)
                       668.000  objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
               crc32   940.981k memsize (     0.000  retained)
                       480.000  objects (     0.000  retained)
                        50.000  strings (     0.000  retained)

Comparison:
               mtime:      27343 allocated
               crc32:     940981 allocated - 34.41x more
           file hash:    1585783 allocated - 58.00x more
            original:    1769735 allocated - 64.72x more
Warming up --------------------------------------
            original    19.000  i/100ms
               mtime    66.000  i/100ms
           file hash    21.000  i/100ms
               crc32    37.000  i/100ms
Calculating -------------------------------------
            original    246.123  (± 5.3%) i/s -      1.235k in   5.033696s
               mtime      1.143k (± 2.7%) i/s -      5.742k in   5.026275s
           file hash    276.138  (± 2.9%) i/s -      1.386k in   5.023864s
               crc32    406.651  (± 3.2%) i/s -      2.035k in   5.009418s

Comparison:
               mtime:     1143.3 i/s
               crc32:      406.7 i/s - 2.81x  slower
           file hash:      276.1 i/s - 4.14x  slower
            original:      246.1 i/s - 4.65x  slower

Obviously just accessing a file stat is going to be best, but that doesn't help when the results are inconsistent. I also tested some other options, such as other non-cryptographic hashes that are supposed to be fast (like mumble hash) and got worse results than using crc32 (plus those involve adding a gem which I think is better to avoid).
If this is too slow still, a thought I had would be to switch how to calculate the checksum based on ENV['CI']. Please let me know if you'd like me to make that change, or if there's another strategy to try.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

I'm on the fence about this, as I'm always wary to willingly impact the performance. I'm thinking that one middle ground would be to be able to specify the caching strategy with a command-line flag or a configuration option. How does this sound? //cc @p0deje

@bbatsov I totally agree about purposely making things less performant, but I think the tradeoff currently is real in that we're talking about milliseconds to calculate the checksum vs minutes to run without a cache. Obviously that's specific to my personal case, but I think it's still a valid point.
A command line flag sounds good to me, that's something that can be set up easily in CI without having to affect local development.
Also good with @marcandre's suggestions! Anything that simplifies the check here works well with me. I'm not 100% sure if I understand how to implement what you're suggesting (particularly how to determine what to check on $LOADED_PATH) so if you can give me some pointers I'm happy to try!

I want to second @dvandersluis's point that the cache build performance hit matters less than the very real performance hit of running Rubocop in CI without a cache.

Here's what I'd do as an easy way to shave a bit of time:
# lib/rubocop.rb
require 'English'
before_us = $LOADED_FEATURES.dup
#...  rest of the gazillion requires
if we_are_a_gem
  RuboCop::ResultCache.rubocop_required_features = $LOADED_FEATURES - before_us
end

# lib/rubocop/result_cache.rb
         # add a `rubocop_required_features` singleton class read write attribute, `@api private`, initialized with `[]`
         # ...
         source_files = $LOADED_FEATURES  + Find.find(exe_root) - ResultCache.rubocop_required_features
         digest << RuboCop::Version::STRING << RuboCop::AST::Version::STRING

That should save going through more than 900 files...
Not sure what's the best we_are_a_gem test, maybe simply the presence of Gemfile?

BTW, on my "memory-choked-and-not-getting-any-younger" 2013 macbook air, the crc32 takes ~0.06 seconds (including RuboCop's own source)

@marcandre yeah if you have an idea of how to fix this, go for it! I was playing around with Bundler::LockfileParser but it looks like you don't even need to go that way.

@marcandre yeah if you have an idea of how to fix this, go for it! I was playing around with Bundler::LockfileParser but it looks like you don't even need to go that way.

Yeah, my initial idea was overly complex. Let me whip up a PR then.

#8643 should be merged soon.
I think this present PR should be merged (although a Changelog entry would be nice).

@marcandre great! Updated with a changelog entry.

@bbatsov still on the fence?

Guess not. :smile: Might be a good idea to add some comment around the code about the CI impact, so someone wouldn't optimize it again in the future. :-)

Guess not. 😄 Might be a good idea to add some comment around the code about the CI impact, so someone wouldn't optimize it again in the future. :-)

Sure, I added a small comment 👍

Thanks!

Thanks guys! 🙌


Warn on chain selection error.

At least for Polkadot, this should not result in spam and a warning will
very likely indicate some serious issue.

bot merge

bot merge


Moved IFileDownloadService to new assembly and updated references acr…

…oss solution.
Still need to update AssemblyInfo.cs with appropriate information.

Closing PR, going to complete again against new branch


ctll\grammars.hpp(86): error C1075:  '{': no matching token found

include\ctll\grammars.hpp(86): error C1075:  '{': no matching token found
In this line:
template <auto V, typename = std::enable_if_t<!(Set == V) || ... || false)>> constexpr inline neg_set(term) noexcept;
using MSVC 16.1.0 Preview 3

Thank you.

Sorry, this was overlook on my side.


Inheritance diagrams need a dark theme

I just noticed the dark theme building some docs, and it's awesome 😄 . It looks like inheritance diagrams need a theme applying to them though, otherwise the arrows between boxes aren't visible against the background:

It's possible to get a nice result by setting the following in conf.py. Given the diagrams are static .png files, I'm not sure how to change this on the fly for the dark theme though, or if that's even possible...
inheritance_edge_attrs = {'color': 'white'}
inheritance_node_attrs = {'style': 'filled',
                          'color': 'white',
                          'fillcolor': 'black',
                          'fontcolor': 'white'}

I think the easiest approach would just be to add a CSS style that adds a white background to inheritance diagrams PNGs...that way you can still read the arrows etc, even if it would contrast a bit with the dark theme.

For PNGs the white background is the simplest solution.
One can have SVG inheritance diagrams, which might be possible to style. However, they currently have other problems https://github.com/sphinx-doc/sphinx/issues/3176.

I don't know when this came in, but with 0.10.1 we have a light background:

So, good enough for now.

If this is removed for general images. You could still consider keeping it for inheritance diagrams by limiting the selector to img.graphviz.

This seems to be one of the cases where folks are pleased by the result, but some users are not wanting this so TBD if that rule sticks around in 0.11 🤷🏻

In #914 I added a css helper (.dark-light) for the specific images that are compatible with both light and dark theme. So my guess is that the current behaviour is going to stick around in 0.11

@dstansby is the light grey background solving your issue ?

I'll close this issue for now as images (including inheritance diagram) have now a light grey background by default in the dark theme

FWIW this is the CSS code that I got SVGs from the inheritance diagram to look good in dark mode:
/* Flip the colours on graphviz graphs on dark mode */
html[data-theme="dark"] div.graphviz > object.inheritance {
    filter: brightness(0.8) invert(0.82) contrast(1.2);
    color-scheme: normal;
}```


VP_STATIC_START in docs

Describe the bug
On https://vitejs.dev/guide/ssr.html it shows __VP_STATIC_START__ at the top

Reproduction

System Info
-

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I had the same problem using vitepress, the fix is simple just adding the frontmatter title on the md file.

Thanks for reporting this. I think the page no longer shows __VP_STATIC_START__ now.


docs: extend example for kafka with x509 security

this is driven by https://github.com/asyncapi/nodejs-template/pull/103/files PR where I had to add customized asyncapi file just with one tiny change, could be better to extend official example and use it in test instead of custom version
I think we still have this unwritten rule that best if templates work with official examples, if only possible

@dalelane thanks for the review, I update example by following your advice

@fmvilas need your approval mate
@dalelane 🙇🏼

/rtm

Forget about the last comment saying it was released in version 2.5.0-next-major-spec.1. I made a mistake and it created this version but it should actually be 3.0.0-next-major-spec.1. There's a notice in the release. Apologies for the noise.

Recent comments about the release from the bot were added by mistake. More details in https://github.com/asyncapi/spec/issues/899


Get Tag Commit Date

Added a function to get the commit date for the commit associated with a tag. Bumped the version to 0.1.8.

Version number not properly set, closing with the intent of creating a new one soon.


Research possibility to conduct our Thai tokenizer

Research the possibility to conduct the model of Thai tokenizer by considering model architecture, data sourcing

I will work on this.

Please find summary of my research:

Syllable tokenizer shows good result in variouse senario. It should be an candidate for tokenizer test.
From many tokenization papers (eq. WANGCHANBERTA), we can evaluated variouse  tokenizer to find the best one.


[SE-5115] merge annoto master

Like last time (https://github.com/annoto-campus/xblock-in-video-collaboration/pull/7), we're bringing the new changes that happened at https://github.com/Annoto/xblock-in-video-collaboration, into this branch, used by Campus.
Dependencies: None
Testing and deployment procedure:
This is what I plan to do.

We already saw that the code changes are small. But they need to be tested in practice
Build PRs to update the olive-secure variables, to point to my branch here, so that Campus stage starts using the new blocks
(I'll add other changes that are required on Campus stage)
Deploy Campus stage
Campus will test it there. They'll need a course using Annoto. See links at [the last PR|https://github.com/annoto-campus/xblock-in-video-collaboration/pull/7], maybe it can still be used
Ask to merge this PR
Update the olive-secure settings to point to the new commit (the merge) and use it in production and stage
Deploy Campus production

Author notes and concerns
Some of the changes are about changing positions (left to right). We'll need to test that things still look fine.
Others
See document.
Reviewers

@gabor-boros
Campus

@annoto-campus This has already been tested on Campus stage and it works. Could you please merge it?

(We already deployed it at https://github.com/edx-olive/olive-secure/pull/202, to go faster, but this PR still needs to be merged).


chore: replace esno with tsx

Since esno is an alias by now

Thank you for the great work on esno!

Also fixed scripts/size.ts (had top-level await)

What's the benefit of it? While esno is now an alias of tsx, it's not deprecated. They are served to different preferences. I personally prefer to use esno as it reads more related to node.

As a developer, one less alias to know eases my life. That's why I prefer tsx. But I get your point. 🙂


Support TTL for RBuckets.set

Currently RBucket supports set with TTL https://github.com/redisson/redisson/blob/master/redisson/src/main/java/org/redisson/api/RBucket.java#L134
This is a request for similar support in RBuckets for setting multiple key values with specified TTL.
Possible api signature:
 void set(Map<String, ?> buckets, long timeToLive, TimeUnit timeUnit);

thank you.

Please use RBatch object for this purpose.


implicit function declaration fails

03651fd0718
I hate implicit function declarations, but it turns out bash doesn't even know what they are if they come after "then", so I made it explicit.
f91c470119
Also, My personal, pimped-up, thinned-down prompt.

@seefood want to clean up this PR?

woah, 2013. I forgot I ever opened that. good night PR.


WRITE_MULTIPLE: Illegal Argument: Two operations have different major paths" error

I'm trying to use the putMany (or writeMany, same problem) function to write more than 1 object row to the table.
SDK version 5.2.  Running on Oracle Cloud Infrastructure NoSQL table called "users", with 50 RU and 5 WU capability.  Permissions set up to manage tables for the user running the script.
I can .put a record OK.  I can .putMany so long as the array is exactly of length 1.  Any more, and it fails with this error:
NoSQLArgumentError: [ILLEGAL_ARGUMENT] WRITE_MULTIPLE: Illegal Argument: Two operations have different major paths, first: /rP%C2%90/¨000%C2%94 other: /rP%C2%90/¨001x
Example code:

const NoSQLClient = require('oracle-nosqldb').NoSQLClient;
const ServiceType = require('oracle-nosqldb').ServiceType;
const Region = require('oracle-nosqldb').Region;
const Consistency = require('oracle-nosqldb').Consistency;

const main = async() => {

    const client = new NoSQLClient({
        region: Region.UK_LONDON_1,
        serviceType: ServiceType.CLOUD,
        compartment: 'ocid1.compartment......zzz',
        auth: {
            iam: {
                tenantId: 'ocid1.tenancy....ttt',
                userId: 'ocid1.user.uuu',
                fingerprint: '<finbgerprint>',
                privateKeyFile: '<path to pem file>',
                passphrase: '<passphrase here>',
            }
        }
    });

    try {
        const res = await client.putMany('users', [
            {
                user_id: 1,
                name: {
                    first: 'Fred',
                    last: 'Bloggs'
                },
                contact: {
                    email<EMAIL_ADDRESS>                }
            },
            {
                user_id: 2,
                name: {
                    first: 'John',
                    last: 'Smith'
                },
                contact: {
                    email<EMAIL_ADDRESS>                }
            }
        ]);
        console.log('res from putMany is ', res);
    } catch (err) {
        console.log("ERROR is ", err);
    }

}

main();

Appreciate any help here.  The only reference I can find to "Two operations have different major paths" is in this Java file: https://github.com/bantudb/kv/blob/master/src/oracle/kv/impl/api/KVStoreImpl.java
If I comment out the user_id=2 entry, it will run and insert that single entry into the table OK (so I know permissions are OK) but any more than 1 entry and it will generate this error.
Any clues?  Table definition, for reference is show here:

WriteMany operation requires all records to have the same shard key.  Can you provide your table definition here?  If user_id is your primary key and you didn't specify the shard key when creating the table, I believe that the shard key will be the same as primary key, thus the error.  If records have different shard keys they cannot be inserted in an atomic operation.  Please lookup documentation on shard keys and primary keys.

Closing the issue due to inactivity.


python-dateutil is mandatory

Sounds like python-dateutil is mandatory now
If that's really the case, it would be better to put it in the requirements by default.
Traceback (most recent call last):
  File "/nobackup/lvalls1/valls/workspace/silx.git/./bootstrap.py", line 295, in <module>
    main(sys.argv)
  File "/nobackup/lvalls1/valls/workspace/silx.git/./bootstrap.py", line 239, in main
    run_file(target, argv)
  File "/nobackup/lvalls1/valls/workspace/silx.git/./bootstrap.py", line 102, in run_file
    execfile(filename, module_globals, module_globals)
  File "/nobackup/lvalls1/valls/workspace/silx.git/./bootstrap.py", line 75, in execfile
    exec(code, globals, locals)
  File "/nobackup/lvalls1/valls/workspace/silx.git/examples/plotWidget.py", line 44, in <module>
    from silx.gui.plot import PlotWidget
  File "/nobackup/lvalls1/valls/workspace/silx.git/build/lib.linux-x86_64-3.9/silx/gui/plot/__init__.py", line 62, in <module>
    from .PlotWidget import PlotWidget  # noqa
  File "/nobackup/lvalls1/valls/workspace/silx.git/build/lib.linux-x86_64-3.9/silx/gui/plot/PlotWidget.py", line 61, in <module>
    from . import PlotInteraction
  File "/nobackup/lvalls1/valls/workspace/silx.git/build/lib.linux-x86_64-3.9/silx/gui/plot/PlotInteraction.py", line 41, in <module>
    from . import items
  File "/nobackup/lvalls1/valls/workspace/silx.git/build/lib.linux-x86_64-3.9/silx/gui/plot/items/__init__.py", line 63, in <module>
    from .image_aggregated import ImageDataAggregated  # noqa
  File "/nobackup/lvalls1/valls/workspace/silx.git/build/lib.linux-x86_64-3.9/silx/gui/plot/items/image_aggregated.py", line 40, in <module>
    from .axis import Axis
  File "/nobackup/lvalls1/valls/workspace/silx.git/build/lib.linux-x86_64-3.9/silx/gui/plot/items/axis.py", line 37, in <module>
    import dateutil.tz
ModuleNotFoundError: No module named 'dateutil'

ah ok, everything is optional... well, lets dig into the stuff...


Separate consistency check of entries from maintenance

The consistency check should be executed before each commit. The maintenance recreates the data.json files/ statistics. Separate it a bit.

Related to #203

I will separate the maintenance and the production output and make it even modular and controllable via a small GUI.

There is a small GUI now, but no check that runs before each commit. Basically the check should have warnings and errors.


Add option to enable case-sensitive URLs.

Addresses https://github.com/tipsy/javalin/issues/314

bug.


Error compiling long string litteral  (many   on many lines)

Version
2.6.10
Reproduction link
https://codesandbox.io/embed/vue-template-ysl83
Steps to reproduce
Just click the link and you see the error and start editing.

It says that the string literal is not correct, but its because it loads just a piece of it.
What is expected?
No compilation error
What is actually happening?
A compilation error

I has written
Error compiling long string litteral (many + on many lines)
and not
Error compiling long string litteral (many on many lines)

it seems that the </script> string makes the SFC parser stop earlier than it should.
As a workaround you can escape the slash <\/script>


right-to-left language support

Per https://github.com/capitalone/react-native-pathjs-charts/issues/181 it seems there is an issue with rendering right-to-left languages (at least on Android). Specifically in Persian, words are backwards and letters are not cursive-joined.
Here is an example that reproduces the issue:
import Svg,{ G, Path, Text } from 'react-native-svg'
...
render(){
    let persianText = "الفبای فارسی";
    return (
      <View>
        <Svg width={200} height={200}><G><Text>{persianText}</Text></G></Svg>
      </View>
    )
}

Proper text chunk handling and the Unicode BiDi algorithm is missing.
http://unicode.org/reports/tr9/
The relevant attributes:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/writing-mode
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/direction
https://www.w3.org/TR/SVG2/text.html#DirectionProperty
The node icu-bidi package binds to the ICU (55.1) library in order to provide an implementation of the Unicode BiDi algorithm.
https://www.npmjs.com/package/icu-bidi
This possibly makes sense to implement in javascript, just reorder the characters such that it becomes only left-to-right text, and rearrange any char dependent attribute value lists to take this into consideration (x, y, dx, dy, rotate attributes). Otherwise:
Servo has an implementation in Rust:
https://github.com/servo/unicode-bidi
Java also has one:
https://docs.oracle.com/javase/7/docs/api/java/text/Bidi.html
And Apple, Windows etc. have ther own.

i have this issue too

@hotmanhh Would you be interested in attempting to implement it?

Yes I would
On Mon, 2 Jul 2018, 10:48 Mikael Sand<EMAIL_ADDRESS>wrote:

@hotmanhh https://github.com/hotmanhh Would you be interested in
attempting to implement it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/react-native-community/react-native-svg/issues/439#issuecomment-401683002,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ala3RdHt923m8PWu5hDj7GaFXSq-MbZQks5uCbsXgaJpZM4PH7gN
.

@hotmanhh I've done some initial work here: https://github.com/react-native-community/react-native-svg/pull/724
But have barely any insight into any right-to-left or top-to-bottom script and language systems. So I'm very much in need of assistance from native speakers/writers to get this further. What languages are you in need of? Persian/Farsi as well? Could you test and see if its good enough? And try to find the correct font feature settings to get the ligatures/cursive joins working as they should.

https://docs.microsoft.com/en-us/typography/script-development/arabic
https://en.wikipedia.org/wiki/List_of_typographic_features
https://www.w3.org/TR/SVG2/text.html#DirectionProperty

A workaround to fix this issue for Persian texts (probably Arabic texts too).
use this tool:
awebfont.ir/convert

Any update on this issue?! I've been searching a lot and I found lang scripts for arabic and persian texts.
I tried font features here but non worked!
https://docs.microsoft.com/en-us/typography/script-development/arabic

A workaround to fix this issue for Persian texts (probably Arabic texts too).
use this tool:
awebfont.ir/convert

What about dynamic data?!

any one can tell what awebfont.ir/convert is exactly doing to the passed text. if we find out then we can find a util for it to do it for us to use it for dynamic data as well as static ones

any one can tell what awebfont.ir/convert is exactly doing to the passed text. if we find out then we can find a util for it to do it for us to use it for dynamic data as well as static ones

Exactly what I am looking for!!!

If the normal react-native Text element is working correctly, then it might be a good idea to take inspiration from how it's handled there, and adapt the logic to the text rendering algorithm here.

any one can tell what awebfont.ir/convert is exactly doing to the passed text. if we find out then we can find a util for it to do it for us to use it for dynamic data as well as static ones

Exactly what I am looking for!!!

it is a Persian Glyphs Converter. couldn't use any of the packages that i found to fix it.

If the normal react-native Text element is working correctly, then it might be a good idea to take inspiration from how it's handled there, and adapt the logic to the text rendering algorithm here.

i haven't seen the text part of react-native for android but i assume that it should use the android default native text without doing anything special to it. not sure.

Perhaps you can use the relatively recently implemented inlineSize attribute then:
import * as React from "react";
import { View, Text } from "react-native";
import { Svg, G, Text as SvgText, TSpan } from "react-native-svg";

let persianText = "الفبای فارسی";

export default () => (
  <View>
    <Text>{persianText}</Text>
    <Svg
      width="100%"
      height="100%"
      style={{ borderWidth: 1, borderColor: "black" }}
    >
      <SvgText>
        <TSpan y={15} fontSize={14} inlineSize="100%" textAnchor="start" >
          {persianText}
        </TSpan>
        <TSpan y={30} fontSize={14} inlineSize="100%" textAnchor="middle" >
          {persianText}
        </TSpan>
        <TSpan y={45} fontSize={14} inlineSize="100%" textAnchor="end" >
          {persianText}
        </TSpan>
      </SvgText>
    </Svg>
  </View>
);

inlineSize also does line-breaking, so you can have multiple lines of text without having to position the lines manually

When I set inlineSize on a TSpan I lose the fill color specified. Is this a known bug?

I haven't noticed that no, thanks for reporting

did anyone find a solution to this issue

This issue is not resolved!

same issue!

anyone who wants a package which acts like awebfont.ir/convert to handle dynamic texts can use this repo https://github.com/font-store/persian-reshaper

anyone who wants a package which acts like awebfont.ir/convert to handle dynamic texts can use this repo https://github.com/font-store/persian-reshaper

its works as a workaround


Tracking: need for a new release

There are a lot of fixes to existing issues that aren't on PyPI because there hasn't been a release in a long time.
I am thinking I want to clean up and finish all the actionable issues, do a test of all functionality on latest versions, maybe write new tests if anything is broken, and then push out a new release. There are also some outstanding documentation issues that need to be taken care of.
The Python version bump to 3.10 is considerable and is part of the reason releases have been stalled for a while. 3.10+ is available in Ubuntu LTS (jammy), Debian stable (bookworm), Raspbian stable (bookworm), and Anaconda's mainline, which are my usual yardsticks of whether it's acceptable to bump. I don't imagine there won't be a bit of pushback, but I think the version has been out for long enough.
Python 3.12 is only about a month away, so I might hold on until right after its release, but the related cleanup work should be done before then.

2.6.0 has now been released. I didn't do as much of the cleanup as I had hoped, but it's about time most of these changes get field tested anyway.


Memcached backend support

Adds support for memcached as a backend.
Major differences are:

key are expired automatically by memcached
there is no concept of limits, keys are automatically deleted when cache spills (LRU)

@kenshinx any interest in merging this?

Hi @dbalan
I am sorry did not noticed this PR before. Memcache is make sense absolutely and i will merge this PR after the review.
Thanks for your great wrok.

@kenshinx I've changed them back. Thanks for the project!


Cherry pick saas mode removal into 2.13 stable stream

no need, I have merged 3scale-2.13-stable with master

@eguzki doesn't that also add the async-pool update to the 2.13.1 release, meaning one more issue for QE to verify ?

in on-prem, async mode is not enabled. It does not affect in any way.


Add Box<> to some types to eliminate move cost

Feature Request
Some types' size is large, e.g. mysql::Time has a size of about 50 bytes. When variables in these types are moved, it costs a lot. Additionally, Datum is an enum including a mysql::Time so that Datum becomes this large as well!
By wrapping such type in a Box we may eliminate some moving cost.
Notice that we should only do this in performance critical path.

I finished first version. Should I create new benchmark for this task or use existing one for measurement?

Yes, please.


create logo for Sii taxi

maybe someone has an idea for a combination of Sii logo and word TakSii?

why has this been closed?

mistake ;)


Linux: Nvenc set in to encode one surface at a time

the name isn't actually descriptive on what it actually does, it actually means how many surfaces to encode at a time

I would ad a comment explaining this


Add 0 day TARs and April 1 TP

Adding time at risk intervals that include 0 day and one target population (anchored on April 1st)

@aostropolets - thanks for these changes! I'm going to put these into a branch for now so that I can do some testing and do a formal release into the master branch!


[Amendment] Disallow setting an account's regular key to match its master key

(You'll want to ignore white space in the diff to read the new tests and test changes.)
What should we name the amendment? I defaulted to fix1721 based on a pattern among some of the other names, naming it after our internal JIRA issue, but I would prefer a name that (1) tries to describe the change and (2) is not tied to an issue number (given that our issue platform may change).
Fixes JIRA-1721.

Maybe something like "fixUniqueMasterKey"? It is more or less an edge case and likely unintended, so I'd keep the "fix" part in front (compared to pure feature amendments like SHAmap_v2).
Alternatively maybe "fixRegularNeqMasterKey".

Jenkins Build Summary
Built from this commit
Built at 20190305 - 20:46:26
Test Results

Build Type
Log
Result
Status

msvc.Debug
logfile
1149 cases, 0 failed, t: 634s
PASS :white_check_mark:

gcc.Release -Dassert=ON, MANUAL_TESTS=true
logfile
915 cases, 0 failed, t: 6m7s
PASS :white_check_mark:

docs, TARGET=docs
logfile
1 cases, 0 failed, t: 0m1s
PASS :white_check_mark:

rpm
logfile
1152 cases, 0 failed, t: n/a
PASS :white_check_mark:

msvc.Debug, NINJA_BUILD=true
logfile
1149 cases, 0 failed, t: 655s
PASS :white_check_mark:

clang.Debug
logfile
1152 cases, 0 failed, t: 3m14s
PASS :white_check_mark:

gcc.Debug -Dcoverage=ON, TARGET=coverage_report, SKIP_TESTS=true
logfile
1152 cases, 0 failed, t: 17m17s
PASS :white_check_mark:

gcc.Debug
logfile
1152 cases, 0 failed, t: 3m30s
PASS :white_check_mark:

clang.Debug -Dunity=OFF
logfile
1152 cases, 0 failed, t: 9m35s
PASS :white_check_mark:

msvc.Debug -Dunity=OFF
logfile
1149 cases, 0 failed, t: 1294s
PASS :white_check_mark:

clang.Release -Dassert=ON
logfile
1152 cases, 0 failed, t: 5m42s
PASS :white_check_mark:

gcc.Debug -Dunity=OFF
logfile
1152 cases, 0 failed, t: 10m20s
PASS :white_check_mark:

msvc.Release
logfile
1149 cases, 0 failed, t: 418s
PASS :white_check_mark:

gcc.Release -Dassert=ON
logfile
1152 cases, 0 failed, t: 6m8s
PASS :white_check_mark:

gcc.Debug -Dstatic=OFF
logfile
1152 cases, 0 failed, t: 3m30s
PASS :white_check_mark:

gcc.Debug -Dstatic=OFF -DBUILD_SHARED_LIBS=ON
logfile
1152 cases, 0 failed, t: 3m30s
PASS :white_check_mark:

gcc.Debug, NINJA_BUILD=true
logfile
1152 cases, 0 failed, t: 3m5s
PASS :white_check_mark:

clang.Debug -Dunity=OFF -Dsan=address, PARALLEL_TESTS=false, DEBUGGER=false
logfile
1152 cases, 0 failed, t: 10m19s
PASS :white_check_mark:

clang.Debug -Dunity=OFF -Dsan=undefined, PARALLEL_TESTS=false
logfile
1152 cases, 0 failed, t: 12m43s
PASS :white_check_mark:

Should we also change the behavior for any existing accounts whose master key matches their regular key? Perhaps in the code where we reject a transaction because it's signed with the master key and the master key was disabled, check if the regular key and master keys are identical and, if so, allow the transaction to execute.
I realize this changes the behavior of existing accounts, but I doubt anyone intentionally rendered an account unusable by setting the regular key to the master key and disabling the master key.

How many accounts are currently affected by this anyways?

We've discussed reversing the checks for "does the signing key match the master key and the master key is not disabled" and "does the signing key match the regular key", which would unlock currently locked accounts (there are only around 20). That could go in this change (I think it requires an amendment anyway).

As far as I know, at least one person in Japan has created an account for this problem. This problem is serious given the frozen assets of that purse. About 1.4 million XRP.

I will write something that everyone already knows, by the way.
This bug will kill the master key first, or even if you set a regular key from Bob or Charlie to Alice's address, the first thing I've identified is the reverse procedure of Alice setting to Alice's public address also success, this is of course not an error code in the process of disable_master flag after this.
So I think the nature of the problem is this: return a ERR_duplicate_key, or at the time of error recovery code such as RPE_duplicated_key is appropriate.
Recently I am good report here to the owner of the wallet.

The problem is as trivial as a mosquito bite, and it won't even be an exploit.
Still, if you care about this boring and tedious tweak, we should know this word.
The really beautiful code is simple and powerful. the same is true for the name.

:+1: - will need squashing together, once we're ready to merge this.

It is surprising that this problem has been neglected for two months.
I feel a lack of technology in logic circuits.

“Neglected”? The PR has been merged and will go out with the 1.3.0 release.

It'll still need to be activated, but that's up to the validators, not the people that write the code here. In code, the issue is solved already.


[AUTOPATCHER] Patches CVE-2021-38199 for kernel

        Patches CVE-2021-38199 for kernel.
        This patch and PR was automatically generated and needs human verification before merging.

Closing Autopatch of Kernel.  Tooling error.


Network connection of extension list - proxy issue?

Hello dear VS code team!
Unfortunately I have an connection issue with vscode. I am behind a corporate proxy on Ubuntu 18.10. I have installed vs code via the .deb package.
My proxy settings are configured in the gui of Ubuntu, in the environment settings and I have also tried to set the proxy via command line argument and in the settings .json of vscode. Furthermore the proxy has its own certificates, but these are also installed in the os.
Strange is, that the list of extensions does load, but no icons of the extensions as well as the descriptions do not load. Trying to install the extension also ends up in an error (screen shot of the share process window:

I have a second computer running on windows 10, having no issues with the proxy!

VSCode Version: 1.32.3
OS Version: Ubuntu 18.10

Does this issue occur when all extensions are disabled?: Yes
EDIT: I also tried --ignore-certificate-errors without any changes.
Installing via console with code --install extension does work.
Thank you for your support!

I was able to fix the issue. The solution was to install chromium, import certificates there, and then connection in vscode worked. Hope this will help someone!


http request: add msg.requestTimeout parameter

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Proposed changes
This adds a msg.requestTimeout option to the http request node to override the global httpRequestTimeout parameter per message.
Checklist

[x] I have read the contribution guidelines
[x] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[x] I have added suitable unit tests to cover the new/changed functionality

Coverage increased (+0.01%) to 76.878% when pulling 30c1d31a99f77b4b67af38ea835521830651ef46 on natcl:httpTimeoutPerMsg into 2353f12cd6fd6da48a1ce076322b856392f6bc4d on node-red:dev.


Add a --strictNaNChecks option, and a NaN / integer / float type to avoid runtime NaN errors

I have read the FAQ and looked for duplicate issues.
Search Terms

NaN
NaN type
Integer type

Related Issues

#21279: strictNullChecks safeguards against null and undefined, but not NaN
#15135: NaN, Infinity and -Infinity not accepted in number literal types

#15351: Infinity/NaN literal type (dup)

#195: Suggestion: int type
#4639: Proposal: int types

BigInt is scheduled for TS 3.0 - #15096 - Support for TC39 "BigInt: Arbitrary precision integers in JavaScript" proposal

Suggestion
NaN has been a big source of errors in my code. I was under the impression that TypeScript (and Flow) could help to prevent these errors, but this is not really true.
TypeScript can prevent some NaN errors, because you cannot add a number to an object, for example. But there are many math operations that can return NaN. These NaN values often propagate through the code silently and crash in some random place that was expecting an integer or a float. It can be extremely difficult to backtrack through the code and try to figure out where the NaN came from.
I would like TypeScript to provide a better way of preventing runtime NaN errors, by ensuring that an unhandled NaN value cannot propagate throughout the code. This would be a compile-time check in TypeScript. Other solutions might be a run-time check added with a Babel plugin, or a way for JS engines to throw an error instead of returning NaN (but these are outside the scope of this issue.)
Use Cases / Examples
const testFunction = (a: number, b: number) => {
  if (a > b) {
    return;
  } else if (a < b) {
    return;
  } else if (a === b) {
    return;
  } else {
    throw new Error("Unreachable code");
  }
}

testFunction(1, 2);

testFunction(1, 0 / 0);

testFunction(1, Math.log(-1));

testFunction(1, Math.sqrt(-2));

testFunction(1, Math.pow(99999999, 99999999));

testFunction(1, parseFloat('string'));

A programmer might assume that the Unreachable code error could never be thrown, because the conditions appear to be exhaustive, and the types of a and b are number. It is very easy to forget that NaN breaks all the rules of comparison and equality checks.
It would be really helpful if TypeScript could warn about the possibility of NaN with a more fine-grained type system, so that the programmer was forced to handle these cases.
Possible Solutions
TypeScript could add a --strictNaNChecks option. To implement this, I think TS might need to add some more fine-grained number types that can be used to exclude NaN. The return types of built-in JavaScript functions and operations would be updated to show which functions can return NaN, and which ones can never return NaN. A call to !isNaN(a) would narrow down the type and remove the possibility of NaN.
Here are some possible types that would make this possible:
type integer
type float
type NaN
type Infinity

type number = integer | float | NaN | Infinity   // Backwards compatible
type realNumber = integer | float   // NaN and Infinity are not valid values

(I don't know if realNumber is a good name, but hopefully it gets the point across.)
Here are some examples of what this new type system might look like:
const testFunction = (a: integer, b: integer) => {
  if (a > b || a < b || a === b) {
    return;
  } else {
    throw new Error("Unreachable code");
  }
}

// Ok
testFunction(1, 2);

// Type error. TypeScript knows that a division might produce a NaN or a float
testFunction(1, 0 / 0);

const a: integer = 1;
const b: integer = 0;

const c = a + b;  // inferred type is `integer`. Adding two integers cannot produce NaN or Infinity.
testFunction(1, c); // Ok

const d = a / b;   // inferred type is `number`, which includes NaN and Infinity.
testFunction(1, d); // Type error (number is not integer)

const e = -2;   // integer
const f = Math.sqrt(e);    // inferred type is: integer | float | NaN    (sqrt of an integer cannot return Infinity)

const g: number = 2;
const h = Math.sqrt(g);    // inferred type is number (sqrt of Infinity is Infinity)

testFunction(1, h);  // Type error. `number` is not compatible with `integer`.

if (!isNaN(h)) {
  // The type of h has been narrowed down to integer | float | Infinity
  testFunction(1, h);  // Still a type error. integer | float | Infinity is not compatible with integer.
}

if (Number.isInteger(h)) {
  // The type of h has been narrowed down to integer
  testFunction(1, h);  // Ok
}

When the --strictNaNChecks option is disabled (default), then the integer and float types would also include NaN and Infinity:
type integer      // Integers plus NaN and Infinity
type float        // Floats plus NaN and Infinity

type number = integer | float    // Backwards compatible
type realNumber = number         // Just an alias, for forwards-compatibility.

I would personally be in favor of making this the default behavior, because NaN errors have caused me a lot of pain in the past. They even made me lose trust in the type system, because I didn't realize that it was still possible to run into them. I would really love to prevent errors like this at compile-time:

This error is from a fully-typed Flow app, although I'm switching to TypeScript for any future projects. It's one of the very few crashes that I've seen in my app, but I just gave up because I have no idea where it was coming from. I actually thought it was a bug in Flow, but now I understand that type checking didn't protect me against NaN errors. It would be really awesome if it did!
(Sorry for the Flow example, but this is a real-world example where a NaN type check would have saved me a huge amount of time.)
Number Literal Types
It would be annoying if you had to call isNaN() after every division. When the programmer calls a / 2, there is no need to warn about NaN (unless a is a number type that could potentially be NaN.) NaN is only possible for 0 / 0. So if either the dividend or the divisor are non-zero numbers, then the NaN type can be excluded in the return type. And actually zero can be excluded as well, if both dividend and divisor are non-zero.
Maybe this can be done with the Exclude conditional type? Something like:
type nonZeroNumber = Exclude<number, 0>
type nonZeroRealNumber = Exclude<realNumber, 0>
type nonZeroInteger = Exclude<integer, 0>
type nonZeroFloat = Exclude<float, 0>

If the dividend and divisor type both match nonZeroInteger, then the return type would be nonZeroFloat. So you could test any numeric literal types against these non-zero types. e.g.:
const a = 2;     // Type is numeric literal "2"

// "a" matches the "nonZeroInteger" type, so the return type is "nonZeroFloat"
// (this excludes Infinity as well.)
// (Technically it could be "nonZeroInteger", or even "2" if TypeScript did
// constant propagation. But that's way outside the scope of this issue.)
const b = 4 / a;

Checklist
My suggestion meets these guidelines:

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[X] This feature would agree with the rest of TypeScript's Design Goals.

It would actually be great to have integer type. As discussed in #195 and #4639, it might help to force developers to do strict conversions and checks when you expect to get an integer value, eg. with math operations:
let x: integer = 1; // you expect it's value to always be an integer
x = 5 / 2; // compile error
x = Math.floor(5 / 2); // ok

I think dividing number into integer and float is enough, while dealing with NaN and Infinity you need to look into the values for operators like /, while dealing with integer-float, you need only types.

Shouldn't the terminology be double and not float?
I believe JS numbers are actually double precision.
Nitpick aside, an integer type that is backed by number and not bigint would have proven immensely useful for my use case.

My use case is outlined in the below link,
https://github.com/AnyhowStep/tsql/blob/adbfcf666ef71be4b6c03567a8d14a88ab699d7c/doc/00-getting-started/01-data-types.md#signed-integer
Basically, SQL has SMALLINT,INT,BIGINT types that correspond to 2,4,8 byte signed integers.
The 2 and 4 byte signed integers could have been represented by an integer type backed by number.
However, I wanted to eliminate a large class of errors where floating-point values are used instead of integer values.
So, I had no choice but to also represent 2 and 4 byte signed integers with bigint.

This could have been solved with branding.
However, I'm strongly of the opinion that branding should be a last resort.
Which is why I like this proposal and the range-type proposals so much.
Being able to express what we want with only built-in types reduces dependencies on external libraries for complex branding.
If a brand is used, it increases the chance of downstream users having to use multiple differing brands that mean the same thing. (Library A might use {int : void} as the integer brand, library B might use {integer : void} as the integer brand, etc)

I like the idea of having an integer type backed by number but I disagree with how the OP wants the type to be defined.
I would prefer,
//Infinity is now a literal type
declare const inf : Infinity;

//-Infinity is now a literal type
declare const negInf : -Infinity;

//NaN is now a literal type
declare const nan : NaN;

//No change to this type
type number;

type finiteNumber = number & (not (Infinity|-Infinity|NaN));

type integer; //All **finite numbers** where Math.floor(x) === x

I do not like the idea of Infinity, -Infinity, and NaN being part of the integer type. It is very unintuitive and usually not what I (and I assume others) would want.
If someone wants the original proposal, they can just create their own type alias,
type PotentiallyNonFiniteInteger = integer|Infinity|-Infinity|NaN;

It will be great also suggest replace x === NaN to Number.isNaN(x) or isNaN(x) during diagnostics because x === NaN always false and 100% is mistake.

Has this issue been picked up by the maintainers? It's surprising to me that a type-checking compiler for JavaScript wouldn't try to prevent one of the most notorious type issues prevented by nearly every other language, dividing by zero (not sure if TS would need zero and non-zero subtypes in order to be able to typeguard a valid division).

It would be greate to see this new rule in TypeScript 4.0

Since there is a function called Number.isFinite(), I suggest use finite instead of realNumber as the name of the type for real numbers.

When I started really learning TS, I expected that at least NaN and Infinity would have their own types, but alas no, they do not, they are simply of the type number.
Also, arrays really ought to be Array<T> = { [key: integer]: T }.
We can all agree this is great, totally bug-free cde, right?
const temp: string = ["temporary value"][Infinity];

console.log(temp);

Who could have expected undefined!?

n.b. Integer types have already been decided as out of scope (especially now that BigInt is a thing), so what follows only refers to NaN typing. We discussed this at length and couldn't come up with any plausible design where the complexity introduced here would provide sufficient value in most use cases.
The only reasonably common way to get a NaN with "normal" inputs is to divide by zero; programs that do standard arithmetic should be on guard for this and add appropriate checks the same way you would for handling file existence, lack of network connectivity, etc (i.e. things that are common errors but not enforced by a type system). Once a well-formed program correctly guards its division, any NaN checking that follows is mostly going to be noise. For example, if you write Math.log(arr.length), this can never return NaN, but we only know this because arr.length can't be negative. Many other functions work in a similar way - to provide these NaNs in useful places we'd have to encode a large amount of data about possible values for numbers (integers, positive, nonnegative, less than 2^32, etc) all over the type system, which is a ton of work that everyone would have to reason about from that point forward for the sake of the relatively small number of programs that encounter unexpected NaNs due to logic errors.

Well, it's an all-or-therewillalwaysbeshenanigans choice.
I was hoping TS might aim for complete correctness by doing all of the above; perhaps the answer is "not now", then?
Easy comes with complications; simple comes with complexity.

At the very least, NaN, Infinity and -Infinity should be valid and correctly handled in type positions, since TypeScript can and will emit Infinity and ‑Infinity in type positions: https://github.com/microsoft/TypeScript/issues/42905.

This would also make it possible for TypeScript to produce an error for code like the following:
declare var foo: number;

// @ts-expect-error
if (foo === NaN) {
	// ...
}

Then TypeScript warns that === NaN will always return false and !== NaN will always return true.

Similarly, Number.isNaN could then be defined as:
interface NumberConstructor {
	isNaN(number: unknown): number is NaN;
}

There’s also real world code that relies on returning NaN in a catch clause: https://github.com/engine262/engine262/blob/ab4baf1b1faeae35da022aea6c60a6a824822167/src/abstract-ops/type-conversion.mjs#L404-L415, because the error is handled elsewhere: https://github.com/engine262/engine262/blob/ab4baf1b1faeae35da022aea6c60a6a824822167/src/abstract-ops/type-conversion.mjs#L386-L394.

We need this in order to specify a function that has to return NaN on purpose in specific cases. If we returned another number, like 0, we could declare it as:
function example(): string | 0 {
...

but sadly we can currently not declare the function as returning:
function example(): string | 0 {
...

@c-dinkel Are there any particular reasons that you're using NaN for that value? Could you elaborate on what your function actually does, And in what case it is returning NaN? Is it your function or just a type definition for an arbitrary JS function? Would you be willing to consider string | null instead?

I have encountered code like @c-dinkel’s in the wild as well, so having a NaN type would help.

While I don't think it is good to implement such fundamental language features on an as-needed basis[1], the question @CrimsonCodes0 asks does deserve a proper answer, which was not given in the reply above.

It is useful to be able to prove that a function does not return NaN. I think that needs no justification but here it is for completeness: this would allow to avoid (compile-time) hard-to-debug crashes initially due to a division by zero (or other) that produces NaN, and causes a confusing error very far away from the code that creates this NaN value initially.

It is useful to be able to tell the compiler we do want a function that can return NaN, exactly when we want to handle it later, not here, in a function whose type is exactly one that disallows NaN as a return value.

Errare humanum est. Without strict checks, Murphy's law reigns!
[1] This is because all code written before the availability of basic features in the language will have to use workarounds or be unsafe, and will need to be rewritten when the language fixes that flaw, which it now needs to do with some amount of backwards compatibility with the workarounds in question. All that code working around missing language features will not be refactored using the new feature right away, or at all, because that has a cost. All in all, introducing language features as the need arises creates technical debt orders of magnitude higher, as well as "good practices" that will be obsoleted by introducing the language features proper.

@c-dinkel Are there any particular reasons that you're using NaN for that value? Could you elaborate on what your function actually does, and in what case it is returning NaN? Is it your function or just a type definition for an arbitrary JS function? Would you be willing to consider string | null instead, or throwing an exception?

While in this particular case a value is needed that compares falsely to itself, there are other cases where NaN is necessary for other reasons. Imagine, for example, a numeric calculation that returns 0 | 1 | 2 | 3 | NaN , I'd really want to be able to express that.

I can't believe this has not been implemented yet. NaN is one of the most runtime-error-prone thing in JS, which could (and must) be avoided by static typing. That's the very purpose of TypeScript, isn't that?

@yuhr perhaps the typescript developers need help with this because it's too hard to do? Or financial support if microsoft doesn't provide enough?
More realistically, most likely it's precisely because corporate priorities are orthogonal to software quality that this is not on the roadmap. Many such projects (this includes Rust) tend to forget/tone down their initial goals like this: instead of failing the compile if the program isn't provably safe, which was the initial objective, TS is becoming more of a linter which catches what it can and lets potential errors fly when it doesn't know.
While we would want it to (at least have an option to) never accept programs that may crash, it is out of ignorance that more novice developers do not care, and simply relay what management asks for: do dangerous things and deal with the consequences later.
Of course, wise developers would rather make sure, at compile time, that no errors are ever possible.
Novice developers, managers and the former under the influence of the latter think that a compromise is possible to reap a lot of benefits with minimum risk; and that's why modern technology is plagued with bugs.

It seems to have been that no compelling scenarios were mentioned in https://github.com/microsoft/TypeScript/issues/9407 when this issue first came up. Since there have been several compelling scenarios mentioned here, maybe the following original decision might be revised?

@weswigham Unless someone has a compelling scenario, I'm strongly inclined not to include NaN and Infinity as literal types. Literal types intended for scenarios where you pick a (small) set of specific values to match on in type guards and overloads, and I simply can't imagine meaningful uses of NaN or Infinity as a discriminant values or literal values for overloading.

Yes, 1, 0x1, 1.0, and 1e0 are all the same type, but the canonical representation is always used when displaying types (i.e. the string you get by converting the number to text using "" + value).

I'll look at poaching some tests.

Originally posted by @ahejlsberg in https://github.com/microsoft/TypeScript/issues/9407#issuecomment-229721835

[I will be very incisive here, not because I like to, but because I believe it is unfortunately necessary.]
@c-dinkel there are two important things to respond to the "no compelling scenario" argument / decision method:

It is fundamentally a bug-promoting mentality. Waiting for a compelling scenario to appear before trying to get a fundamental aspect of the language right… flies in the face of the sanity of the language. It's exactly saying "let's wait for unfinished foundations to cause the practical problems they were bound to, before we consider taking action".
It is, technically, willful ignorance of how much practical benefit ensues from mathematical elegance. For these reasons, I call its past users to please reconsider before using that argument / decision method.

I am most confused that the lead architect of TypeScript either:

could not think of division by zero (even considering such a thing is bordering on insulting), or
thinks it's not an issue in practice (because, unsurprisingly, it is), or
thinks TS is fine as a linter, as in: it doesn't necessarily need to (have the ability to) limit itself to accepting programs that can't crash at run time.

I may have missed something but I don't see how having "bigint" helps in any way in differentiating integers vs floating point numbers? 🤷♂
As far as I know, bigint is for (very) large numbers (MDN: "represent whole numbers larger than 2^53 - 1").
Bigint values are fully incompatible with both numbers and Math functions, cannot be included in JSON, and probably more caveats that I don't know of.

Appart from that, Number.isInteger has been part of the language since ... I don't know, but quite some time now.
It seems fair that typescript would be able to tell the difference between a number and an integer.
I understand that it may be a lot of work, but integers are a thing.
How can people even be ok with the idea of using "number" to type durations, quantities, indexes, or any whole number. 😕
Claiming that developers can handle the thing themselves (but without typescript) sounds wrong to me.

I may have missed something but I don't see how having "bigint" helps in any way in differentiating integers vs floating point numbers? 🤷♂
As far as I know, bigint is for (very) large numbers (MDN: "represent whole numbers larger than 2^53 - 1").
Bigint values are fully incompatible with both numbers and Math functions, cannot be included in JSON, and probably more caveats that I don't know of.

Appart from that, Number.isInteger has been part of the language since ... I don't know, but quite some time now.
It seems fair that typescript would be able to tell the difference between a number and an integer.
I understand that it may be a lot of work, but integers are a thing.
How can people even be ok with the idea of using "number" to type durations, quantities, indexes, or any whole number. 😕
Claiming that developers can handle the thing themselves (but without typescript) sounds wrong to me.

// x should be `0 | NaN`

And also -0 should be there 😆
The only thing that distiguishes -0 from 0 (i.e. +0) is SameValue equality, which is leveraged only in Object.is, so I'm actually not sure it can be supported in TS (or worth it), but then we can't say it's completely "strict" number type checking if we don't support -0.

Regardless of whether an integer type is added, I don't think this form of NaN checking, where two operands known to not be NaN produces a non-NaN number, would be perfect. For example, adding two integers doesn't necessarily produce another integer:
const int: number = 1e308
if (Number.isInteger(int)) { // This is true
  // int: integer
  const sum: integer = int + int // At runtime, Infinity
  const difference: integer = sum - sum // At runtime, NaN
}

I think it's not a big enough deal though since TypeScript is already unsound—['a'][1].length has no type errors but throws a TypeError because having undefined checks for array access is annoying—and the type systems of most other languages such as Rust don't check for integer overflows, so there's not really a need to require checks on the programmer's side for large floating point integers
Also, using the name float or double to mean "not NaN nor an Infinity" might be misleading because NaN and the Infinities are valid floating point values in other programming languages. I'm not really sure what values would be a realNumber but not a float, but I think using realNumber/real or finite would probably be a better name for a such a set of numbers

I believe this would help solve #47347 / #15135.
@yuhr also, 1 / -0 !== 1 / 0. -0 exists in JS, it's a thing.

@c-dinkel Are there any particular reasons that you're using NaN for that value? Could you elaborate on what your function actually does, and in what case it is returning NaN? Is it your function or just a type definition for an arbitrary JS function? Would you be willing to consider string | null instead, or throwing an exception?

@CrimsonCodes0 you asked all these clarification questions about our use case last year, were they all answered in my comment above? Have you been satisfied by my explanation? If so, what is your suggestion in our case?

@SheepTester made an excellent point above... there's no sound way to have an integer type or finite type without checking nearly every operation and/or doing sophisticated range analysis. The four main binary floating-point operations can over- or underflow; the only practicable operations to check are those which cast to signed 32-bit.
Despite this limitation, I would really like to see NaN as a type literal, just as an annotation. NaNs are quite useful signaling tools in numeric code.

@anematode well there are two objectives; I'll concentrate on avoiding runtime type errors caused by NaN. Checking every operation is necessary, and this is exactly what TypeScript does by construction: operations (operators) are functions, and TS checks that function signatures match their calls. That's actually already the main selling point of TS.
Thankfully, new compiler features like range analysis can remain out of the picture to do this.
This can be implemented only by introducing a more stringent number type or compiler option and adding a few signatures, which will in turn make TS reject programs that lack the proper guard conditions before potentially dividing by zero and so on.
The only reason I can imagine TS maintainers getting cold feet at the idea, is that at first glance they might think it will result in several operation modes and break backwards compatibility, but with new types it doesn't have to!

I don't like to have to do const foo: number | null = null, because typeof null === 'object'.  I'd much rather do const foo: number | NaN = NaN.  And treating NaN as a numerical null makes a lot of sense:  In Angular directives, it's not uncommon to do parseFloat and get NaN because the user inputted some non-numerical value.  If parseFloat had a return type of number | NaN, our more-junior developers wouldn't be able to forget to check for null.

Since numbers are out of scope of TS, here's a playground with a potential workaround. I'm currently writing a library to .d.ts polyfill all the methods that can potentially return NaN, along with Number.isNaN() and the global isNaN().

I think this is pretty broken atm,
type Falsy = 0 | '' | false | null | undefined | -0 | 0n // | typeof NaN <-- doesn't work

typeof NaN resolves to type number but it is not a number,
Also, to guard against truthy values, I had to create the Falsy type alias (which doesn't work, cause NaN isn't literally typeable)
export function assertFalsy(value: unknown): asserts value is Falsy {
  if (value) throw new AssertionError('Expected falsy value')
}

Can't we just write asserts not value or asserts !value?

Is this anywhere close to being fixed?

Is this anywhere close to being fixed?

Nope, after lots of time and many issues this is apparently not considered an actual issue by the maintainers. If you absolutely need this fixed, consider forking TypeScript.

I think this is unsolvable, as a+a is infinity and (a+a)-(a+a) is NaN when a = Number.MAX_VALUE (which is an integer). So NaNs and infinities can creep up into any ordinary integer-only code. You couldn't call a function passing an arithmetic expression to an integer parameter without casting, so you'd have to do things like f((i+1) as integer), which kinda defeats the purpose of types.
Alternatively, you could define types of arithmetic operations to be unsound (i.e. return integer for integers and ignore overflows), but I don't think Typescript needs any more unsoundness.
The only things that could be safely done are:

a type named NotFraction, which would contain integers, infinities and NaNs – preserved by +, -, ++, --, *, |, &, ^, ~,
a type named NonnegativeNumber, which would contain nonnegative finite numbers (including -0) and positive infinity – preserved by + and ++ (in particular, not preserved by *, / or **, as 0*Infinity, 0/0 and 1**Infinity are NaN),
analogous NonpositiveNumber (including +0), preserved by + and --,
a type named PositiveNumber, which would contain positive finite numbers (excluding +0) and positive infinity – preserved by +, ++ and * (in particular, not preserved by **, as 1**Infinity is NaN),
analogous NegativeNumber (excluding -0), preserved by + and --, and with NegativeNumber * NegativeNumber = PositiveNumber,
NonnegativeNotFraction = NotFraction & NonnegativeNumber, etc.
a type named NaN containing NaN, just so Falsy could be defined.

Note there's no way to guarantee lack of infinity, and no way to have subtraction, division or modulo without NaNs.
Also, I don't think those types should ever be inferred.
Of course I could have made some mistakes above, this is not a serious proposal, as I don't think those types would be very useful.

You can actually do even more than that: there's int32 which is closed on &, |, ~, ^, <<, and >>, and uint32 which is closed on <<< and >>>. These are totally NaN- and Infinity-safe: NaN << NaN is 0 and 1 << Infinity is 1.

I just want to be able when I write 1.0 and its not suppossed to be float to get an error in typescript and i want if the type is float to have to make it 1.0. Is that not possible?

I just want to be able when I write 1.0 and its not suppossed to be float to get an error in typescript and i want if the type is float to have to make it 1.0. Is that not possible?

It's idiomatic in JavaScript to just use 1 instead of 1.0 even in cases where it's used as a real number rather than an integer (e.g. setting image quality, media volume, canvas shapes, etc). Having to use 1.0 for floats is an idiom from some other programming languages that shouldn't be forced onto TypeScript users for no good reason. We already have special syntax for bigints, anyways

If --strictNaNChecks would throw an type on the following:
const age: number = NaN

I am all for it. And would like to see it as the default behavior.

Having to use 1.0 for floats is an idiom from some other programming languages that shouldn't be forced onto TypeScript users for no good reason.

The "good reason" is allowing users to take advantage of a type system.
A frequent problem I'm running into is that, with WASM, there's no way to signal to consumers in JS whether an interface accepts signed/unsigned integers, floats, etc. Users have to read the source or guess and check as TS can't provide any useful info beyond "it's a number of some sort", which is a shame. Being able to specify, precisely, what kind of number is allowed is really important as TS branches out to describe interfaces beyond plain JS.

Being able to specify, precisely, what kind of number is allowed is really important as TS branches out to describe interfaces beyond plain JS.

I wonder if the type system is the right place for that though. Constraining WASM interfaces is a complex problem, not fitting the weird JS type system. As previously said, you cannot have an integer type that doesn't immediately dissolve into nonsense.
So what about: compile-time preconditions for function parameters, which can reject incorrect constant arguments? This would allow for many other compile-time checks, like "require a prime number", "require a list of length divisible by 4", "require two fields of the object to be different" and so on.
Extend function types with another component: precondition, which is an arbitrary TS expression. Only a reasonable subset of TS needs to be supported, and its environment contains only the parameters and the standard library. When typechecking a call to a function with a precondition, plug all the parameters into the expression, assuming unknown value for non-constant parameters, and evaluate it taking into account interactions between known and unknown values (so it cannot be just a simple JS eval). If the result is a falsy constant, report compilation failure:
// WARNING: REALLY SILLY NOT-ACTUALLY-A-PROPOSAL FOLLOWS:
declare function requires_i32(i:number, j:number):void havingPrecondition (i === (i|0) && j === (j|0)) ;
export let not_a_constant = 1.2;
requires_i32(0, 0); // ok
requires_i32(0, not_a_constant); // ok, because who knows what's inside that variable
                                 // true && unknown_value is unknown_value according to the precondition evaluator,
                                 // which is not a falsy constant, therefore it compiles fine
requires_i32(0, 3.14); // definitely not ok
requires_i32(not_a_constant, 3.14); // definitely not ok – even if we cannot evaluate the precondition like normal code,
                                    // unknown_value && false is still false according to the precondition evaluator

Just a throw-away idea, I think it's a bit too complicated to implement.

This would help a lot to see parseInt problems on code, as we just managed to create bug on our code as developers still expecting parseInt actually throw Type error if not valid (or expect undefined). Of course we can build custom parseInt function to handle this, but on large codebase actual NaN return type would already help to identify those issues.

As previously said, you cannot have an integer type that doesn't immediately dissolve into nonsense.

Even if they cannot be implemented on most of build in operators, they are more than useful in libraries and custom utilities. Even an ability for it to understand that integer is assignable to float and float is assignable to number is a huge improvement so you don't need to make a branded types yourself and cast each time you write const a = 5 as integer to pass it into function. isSafeInteger, isInteger, isFinite, isNaN will work like a typeguard, Math.floor, also in place where NaN can be, you can use NaN || 0.
Also ++ and -- won't go into infinity.

Also it will be good to restrain from using numbers out of the Date range, out of Radix range, out of toFixed argument range and array range and safeNumber range, at least on a level of constants, because simple for loop with increment can turn into infinite loop

havingPrecondition

Refinement types would be amazing (actually, more than just "amazing").
But (as previously mentioned) the predicate language must be a subset of TS, to forbid Turing-Completeness (we already have it #14833), or at least remove some "useless" functions and operator semantics (for basic sanity). Or maybe the predicate-lang could be a different lang altogether (other langs did something similar with macros)


[FLINK-18488][python] Added additional params to CsvTableSource constructor

What is the purpose of the change
CsvTableSource exists in the Python API, however the Python constructor is missing the optional params available in the overloaded constructors from the Java/Scala APIs.  Here's links to the docs:

https://ci.apache.org/projects/flink/flink-docs-master/api/python/pyflink.table.html#pyflink.table.CsvTableSource
https://ci.apache.org/projects/flink/flink-docs-master/api/java/org/apache/flink/table/sources/CsvTableSource.html

In particular, the current Python constructor is missing the following params that are available in the Java constructor:

fieldDelim. The field delimiter.
lineDelim. The row delimiter.
quoteCharacter. An optional quote character for String values.
ignoreFirstLine. Flag to ignore the first line.
ignoreComments. An optional prefix to indicate comments.
lenient. Flag to skip records with parse error instead to fail.

Brief change log

Added additional parameters to CsvTableSource in Python API

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): yes (pyflink)
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@BryceCicada Good catch! Thanks a lot for the contribution. Just left a few minor comments. Should we also support emptyColumnAsNull? Besides, there are checkstyle issues which should be addressed.

@BryceCicada Thanks for the update. There are check style issues in the first commit which failed the tests. It seems that it's not addressed in the latest PR. I guess you missed this comment. :)

@dianfu Thanks.

Should we also support emptyColumnAsNull?

Yeah... from the Java side, I think some small mismatch between the CsvTableSource constructor and builder has crept in:

The builder allows emptyColumnAsNull, but the constructors do not.
There's one constructor that allows selectedFields, but the builder does not.

If I add this, it'll make the Python constructor match none of the Java constructors. My initial thoughts were that it would be a little jarring.  On the other-hand, without it we're depriving python users of the feature.  So yeah, I agree... we should add it here.
I'll raise another Jira ticket describing the Java constructor/builder thing and request it's assigned to me.  Once that's implemented, the Python and Java constructors should match.

Besides, there are checkstyle issues which should be addressed.

Thanks, I've just seen how to run these and I see what you mean.  Will fix.


Update Docs: Positive y lowers element

Update wording in docs to reflect that a positive 'y' number lowers the element.
So y: 100 is 100px below 0, y: -100 is 100px above 0.

Thanks 🙏


fix typo of occured for logging messages and notification

fixed typo flagged up in issue 7076
https://github.com/OrchardCMS/Orchard/issues/7076

Hi @adrianbooth, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

@adrianbooth, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, DNFBOT;

:+1:


feat: poap manager bindings

This PR adds the type definionts for the POAP Manager contract available here and provides a set of utility scripts to interact with it.

This PR  depends on https://github.com/desmos-labs/desmos-contracts/pull/48

Everything looks good to me. While looking at the schema files I got an idea, what about having a script that update them with the latest version? This might be useful cause it avoid the necessity of doing it by hand each time contracts msgs/queries get updated

@bragaz I can work on that.


The Bomberman Game

Problem link: https://www.hackerrank.com/challenges/bomber-man/problem
Difficulty: Medium
I want to solve this problem in C++.
Please assign me the problem.

i'll do it in python

I want to do this in JAVA

I'll do it in python

I am done with the folder correction think. I was thinking of making a fresh pull request. Please assign me again.

I have made a new pull request, hope everything is correct this time.
@adityabisoi please review.
Sorry for the delay.


Can CLIP extract only the encode_text part of the model and save this piece？

Has anyone done this before？

Closing as duplicate of #113


chore: update CI credentials

Minor patch, updated repo secrets with fresh credentials for deployment to new cluster (europe-west1). Should be merged after DNS settings are updated.

Preview is WIP
DNS is yet to be changed after deployment is merged.


Calcium model requires variable conductance for Na and K

While trying to reproduce the results from Sarah's thesis with calcium_model from #333 , I noticed that more channels than just calcium were updated:

Considering we did not have access to the thesis while working on this PR it's a pretty understandable mistake. I'll open a PR soon trying to resolve these issues.

indeed, I seem to have seen this figure. Is the thesis online?

Indeed the entire L5 pyramidal neuron biophysics should be swapped out. This is a link to instructions for doing this in HNN-GUI on the website, that links to Carmen's GitHub page where the new L5 parameter neuron and a description of the updates are detailed. https://github.com/kohl-carmen/HNN-AEF. I will email you a copy of Sarah's thesis. Some of her most recent results are not included but she is responsive through email and will meet when necessary.


ARC upgrade error

The app errored during latest upgrade.
Logs
Initializing upgrade
[1016] Checking if upgrade is required.
[1016] Deleting new databases if exists.
Maximum IPC message size exceeded.
UnknownError: Maximum IPC message size exceeded.

Versions
App: <IP_ADDRESS>5-stable
Chrome: 54.0.2840.87
Platform: Windows (10)

Hi, Thank you for the issue report. I'm on it right now and expect fix very soon.
The app will work with old setup. Sorry for the upgrade screen enabling itself every time when you open the app. I'll fix that too.
And I'm closing it as a duplicate of #830. But thank you again for the report.


[1.9.4] - java.lang.IllegalStateException: Not building!

When trying to configure a fluid pipe with the Mekanism configurator, a render crash occurred:
https://gist.github.com/Lazarix/19f634e11fc638f4d42603d244700e17
This is with build from June 22nd

related to #3422 i believe. Will test with new build

Yes, this should be fixed, I'm not reproducing on the client.