fix(Button): live demo fixes

Closes https://github.com/carbon-design-system/carbon/issues/11267
rel: https://github.com/carbon-design-system/carbon/issues/11157
rel: https://github.com/carbon-design-system/carbon/pull/11227
rel: https://github.com/carbon-design-system/carbon-website/pull/2899
rel: https://github.com/carbon-design-system/carbon/pull/11164
Changelog

overrides docgen sizes for Button live demo
temporarily removes IconButton knobs bc there's no docgen for it (need to figure out how to rebuild docgen or manually add it)
temporarily adds iconOnly className to IconButton live demo (these styles are off in React. I have a PR up to fix so this can be removed when the fix is released). Rel: https://github.com/carbon-design-system/carbon/pull/11352
temporarily adds overriding styles for button tokens

Testing
Test the button live demo in both the Usage tab and Code tab for the following:

working IconButton
working size knobs
working g90/g100 themes for: secondary, tertiary, ghost, danger & disabled btn (previously tokens weren't updating so color was off)

Looks great! Only thing I noticed was the text color in the disabled state on dark themes:

Is this covered by this PR or is that in a separate issue?

@joshblack update the PR 👍🏽


errors: json and ES errors

Adds error handlers for wrong json data and
wrong ES request
closes https://github.com/inveniosoftware/invenio-rdm-records/issues/497

Just a tiny wording issues


Link to Slack in contributing.md not working.

Hi, new to open collective and would like to learn how I can start contributing.
I headed over to the contributing guide page and noticed that the link to slack (at the bottom) isn't working. I'm not sure if that slack.opencollective.com was a custom third level domain that redirects to your slack page or if there was a mistake instead of it being opencollective.slack.com .
I'd be more than happy to change that for you if that is the case.

Absolutely my bad, even the link you used in your comment isn't working for me. Strange, so switched to my phone and the link is working. So probably something to do with my browser/computer's connection? My apologies.

@brymut If it happens to to you, it might happen to others, let us know if you understand better the cause.

Alright, I'll have a look and re-open if I spot something.

okay, link works when I disconnect from the VPN I use (NordVPN). No clue why 🤷♂


Validation of the input payload (RP Server App)

A proposal to solve issue #15

Hi @emersonmello,
Thank you so much for your continuous contributions! I really appreciate it!
I've added couple of comments on your latest commit. Please, let me know your thoughts on this.
Thanks,
Neb.

Hi @npesic , yes! your suggestion is much more elegant ;-). I modified the PR.
Thank you!


Fix typo in CHANGELOG.md

I've fixed the other cases I could find. The blame says it was generated with cargo changelog --write, so it appears this must be an issue with that command.

Thank you! I've opened up https://github.com/Byron/gitoxide/issues/513, so hopefully we won't have this issue in the future.


docker: fix missing raven binaries in docker image

Also add instructions in the docker-compose.yml on how to test a local build of the docker image.

@huard New warnings from docker image built from this PR.
/opt/conda/envs/wps/lib/python3.8/site-packages/ravenpy/utilities/gis.py:257: RuntimeWarning: Sequential read of iterator was interrupted. Resetting i
terator. This can negatively impact the performance.
  for _ in coll.filter(bbox=bbox):
/opt/wps/raven/processes/wps_hydrobasins_shape_selection.py:105: RuntimeWarning: Sequential read of iterator was interrupted. Resetting iterator. This
 can negatively impact the performance.
  feat = next(iter(src))
/opt/conda/envs/wps/lib/python3.8/site-packages/pyproj/crs/crs.py:280: FutureWarning: '+init=<authority>:<code>' syntax is deprecated. '<authority>:<c
ode>' is the preferred initialization method. When making the change, be mindful of axis order changes: https://pyproj4.github.io/pyproj/stable/gotcha
s.html#axis-order-changes-in-proj-6
  projstring = _prepare_from_string(projparams)

@cjauvin Confirmed ravenpy 0.2.3 fixes all "missing binaries" errors from notebooks tests.

@tlvu actually 0.2.3 should fix errors about RAVENPY_TESTDATA_PATH :thinking:

@tlvu actually 0.2.3 should fix errors about RAVENPY_TESTDATA_PATH thinking

@cjauvin yes that's what I meant.  My brain is mixed up with too many permutations of errors right now.

@huard New warnings from docker image built from this PR.
/opt/conda/envs/wps/lib/python3.8/site-packages/ravenpy/utilities/gis.py:257: RuntimeWarning: Sequential read of iterator was interrupted. Resetting i
terator. This can negatively impact the performance.
  for _ in coll.filter(bbox=bbox):
/opt/wps/raven/processes/wps_hydrobasins_shape_selection.py:105: RuntimeWarning: Sequential read of iterator was interrupted. Resetting iterator. This
 can negatively impact the performance.
  feat = next(iter(src))
/opt/conda/envs/wps/lib/python3.8/site-packages/pyproj/crs/crs.py:280: FutureWarning: '+init=<authority>:<code>' syntax is deprecated. '<authority>:<c
ode>' is the preferred initialization method. When making the change, be mindful of axis order changes: https://pyproj4.github.io/pyproj/stable/gotcha
s.html#axis-order-changes-in-proj-6
  projstring = _prepare_from_string(projparams)

@cjauvin Confirmed ravenpy 0.2.3 fixes all "missing binaries" errors from notebooks tests.

@tlvu I'm currently updating the GIS-side of RAVEN/RavenPy. pyproj has been simplified quite a bit, so I'll hopefully be able to remove these new warning in https://github.com/Ouranosinc/raven/pull/335 and https://github.com/CSHS-CWRA/RavenPy/pull/39


Add sharding + threading

Maybe split index into shards. Threading filter/query on each index, merge results.

Maybe distribute tokenization between threads.


feat: cache Axiom SRS (trusted setup)

I'm going to publish this under alpha version.

Note: I don't know how this will work in browser.

closing since we have merged this instead: https://github.com/axiom-crypto/halo2-browser/pull/55


[fluent-bit] create image

I've created an image of Fluent Bit with a plugin that's useful for working with AWS.

https://hub.docker.com/repository/docker/chatwork/fluent-bit
I have created a repository and set up permissions.


Reverted Cleaned Up Arrow Implementation (commit d489b5df5c77...)

This reverts the commit "Cleaned Up Arrow Implementation (d489b5df5c77...), which introduced a bug in the CurvedArrow constructor (https://github.com/3b1b/manim/issues/446).  I had to fix one conflict in the imports, making sure to import both libraries rather than only one.
Please ensure that your pull request works with the latest version of manim.
Done with
git merge upstream/master

The motivation for making this change (or link the relevant issues)

https://github.com/3b1b/manim/issues/446
Since I did not see an obvious fix and no one had addressed the bug in several days, I created a rollback now rather than risk more conflicts as other commits are made on top of the bug.

How you tested the new behavior (e.g. a minimal working example, before/after
screenshots, gifs, commands, etc.) This is rather informal at the moment, but
the goal is to show us how you know the pull request works as intended.

I used https://github.com/zimmermant/manim_tutorial/blob/master/manim_tutorial_P37.py
BEFORE (at head):
python3 -m manim manim_tutorial_P37.py MoreShapes -pl

AttributeError: 'CurvedArrow' object has no attribute 'get_length'
AFTER (after revert):
python3 -m manim manim_tutorial_P37.py MoreShapes -pl

I don't have the time to check this PR now, but as a heads-up the tests currently don't matter at all.

Do you have time to check this pull request?  It's a very straightforward change generated by
git revert d489b5df5c77a597a71c4fd89597e3d48d5b4d9a
And then merging a line in imports so that both imports still happened.
By "test" I think you mean the travis build, which has been broken for a while: https://travis-ci.org/3b1b/manim/builds
I just synced to head because I saw there were a few more commits and confirmed this still works:
python3 -m manim manim_tutorial_P37.py MoreShapes -pl
That's my version of "tests."

Sorry for being so slow on this. It's unsafe to revert a commit without knowing its motivation, as it likely causes some desired behavior in addition to the bug. It'd be safest to find a way to fix the bug without reverting the entire commit.

Thanks for taking a look.
We got lucky-- while typing up how I had tried and failed to fix the bug, I saw a simple fix-- moving the get_length() method to the base class.  Please take a look.
I tested it with the tutorial I mentioned before, which generates several shapes, and they all seemed fine:
python3 -m manim manim_tutorial_P37.py Shapes -pl
python3 -m manim manim_tutorial_P37.py MoreShapes -pl
P.S. I don't actually use CurvedArrow in anything I do, so if this request doesn't work out, I'm done.

This looks good. Thanks!

Thanks for updating the title after the changes.  I deleted the branch but will keep my fork for future bug fixes.


Tolerate non-compliant status line responses

original fix is from daeon: https://github.com/daeon/http-parser/
"Tolerate web servers which do not return a status message in the
return response.
I have noticed this usse on several websites such downloads from
mediafire.com"

original pull request: https://github.com/nodejs/http-parser/pull/254

i merely added the status_cb_called unit test check, there already
is a test that triggers this without the patch (a 301 without a
reason phrase).

fixed the indentation, i'll rebase the change once #366 was merged

@fake666 thank you for your patience. #366 has just been merged.

rebased and good to go :)

Landed in 3b0da34d83e4eace29cc49e3b659bf630537b94c, thank you! (Sorry for very long delay)


wip:feat: cast etherscan --flatten

initial attempt at https://github.com/foundry-rs/foundry/issues/7352
perhaps there's an easier way because already know the entire input set and don't even need the target? @klkvr

We'd still need explicit target as flattener logic is built around a concept of a single target with multiple dependencies.
I think we can use this - https://github.com/foundry-rs/block-explorers/blob/main/src/contract.rs#L128 as target_contract: String.


use ref sugar(take 2) $ref in typescript show 'Cannot find name '$ref'.ts(2304)' but the grammar is all right

Duplicate of #521

ok


Add awesome-manifestos

https://github.com/imsky/awesome-manifestos - a list of software manifestos/principles like The Twelve-Factor App

Thanks for the PR Ivan! Could you please move the list into the awesome-* section?

done @jnv

Excellent, thank you!


Example: Pushing boxes to the goal. (from Sokoban Plus)

How to play your game?

Example  : Press WASD to move, J to restart and K to toggle trails, Get A boxes (cyan) to A goals (green), Get B boxes (magenta) to B goals (red), Get normal boxes (gray) to either goal. (from Sokoban plus)

Code
Check off the items that are true.

[x] The game was made using the Sprig editor.
[x] The game is placed in the in the /games directory.
[x] The code is significantly different from all other games in the Sprig gallery (except for games labeled "demo").
[x] The game runs without errors.
[x] The name of the file/game contains only alphanumeric characters, -s, or _s.
[x] The game name is not the same as the others from gallery

Image (If an image is used)

[x] The image is in the /games/img directory.
[x] The name of the image matches the name of your file. Example: sokoban_plus.js -> sokoban_plus.png.

Thanks for PR!

game

good

it's interesting....

Thanks for PR! which of the two versions is the current one?

Is UNTITLED (3).js supposed to be there?

@SamDev-7 we comment at the same time haha

@GANESH-46  I am closing this PR.  You are free to reopen this PR yourself (or reach out to me directly!) and continue advocating for this code landing, but it seems that it hasn't been acted upon for 3 months.


Set RBAC for VM/addvolume and VM/removevolume

Signed-off-by: Alexander Wels<EMAIL_ADDRESS>
What this PR does / why we need it:
The admin/edit user had vmi/addvolume and vmi/removevolume but for the 'persistent' version vm/addvolume and vm/removevolume the permissions were missing.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

BugFix: Fixed RBAC for admin/edit user to allow virtualmachine/addvolume and removevolume. This allows for persistent disks

/lgtm

/lgtm
/approve

/hold
have to double check the operator permissions, so it can grant the rbac to the users.

/hold cancel found the code that automatically aggregates roles to the operator if new permissions are added to components or users.

/hold cancel
found the code that automatically aggregates roles to the operator if new permissions are added to components or users.

/hold

/hold cancel

/lgtm

/test pull-kubevirt-unit-test
/test pull-kubevirt-e2e-k8s-1.23-sig-network

/test pull-kubevirt-unit-test

/test pull-kubevirt-e2e-k8s-1.23-sig-network-nonroot

/cherry-pick release-0.44


Treating one pixel width lines differently gives wrong results when the canvas is scaled.

Godot version:

3.2.2
OS/device including version:

Windows, GLES2, GLES3.
Issue description:

Drawing 1 pixel thick lines gives wrong results both in tool mode in the editor and when in game. They are not scaled accordingly with the 2D view, they are literally 1 "native resolution" pixel thick because an exception is made when the thickness is <= 1.0 and only two vertices are used instead of four. If line thickness is set to 1.001, for example, then it works as expected.
Current behavior:

Expected behavior (after modifying the line drawing code so as to not make an exception):

I'm attaching a minimal project showing the problem.
line_width_1.zip
This project draws 7 vertical lines using widths 0.12, 0.25, 0.50, 1.0, 1.01, 2.0 and 3.0:
tool
extends Node2D

func _draw():

    draw_line(Vector2(10, 0), Vector2(10, 1000), Color.white, 0.12, false) ;
    draw_line(Vector2(15, 0), Vector2(15, 1000), Color.white, 0.25, false) ;
    draw_line(Vector2(20, 0), Vector2(20, 1000), Color.white, 0.50, false) ;
    draw_line(Vector2(25, 0), Vector2(25, 1000), Color.white, 1.00, false) ;
    draw_line(Vector2(30, 0), Vector2(30, 1000), Color.white, 1.01, false) ;
    draw_line(Vector2(35, 0), Vector2(35, 1000), Color.white, 2.00, false) ;
    draw_line(Vector2(40, 0), Vector2(40, 1000), Color.white, 3.00, false) ;

Current behavior:

Expected behavior (after modifying the line drawing code so as to not make an exception):

I'm fairly sure this was done by design so you can work with more precision at high zoom levels.

The overlap is expected as the origin and destination are the same and I was drawing with alpha :-)
I think it makes sense to have "high precision" lines and that's why I didn't want to remove the code but place it inside the preprocessor directives. Anyway in this case the behavior seems unexpected to me. It's basically ignoring the requested width.

@m6502 Your contribution to the project is welcome, but let's go step by step through the proper process to make sure we find a solution that's compatible with the way the engine and editor currently work.
About the issue itself:
Please add a short description of your use case so others will have a better idea about what you're trying to achieve, and if it's editor-specific or when the game is played too.
Also, a minimal project would help a lot too for quickly testing your use case.
This will help figuring out if a simple script solution exists for this problem.
About the PRs:
Changes with preprocessor directives are probably not the best approach, as most users don't build their custom version. In case there's a need for an option in the engine, project settings are usually the best direction:
https://docs.godotengine.org/en/stable/classes/class_projectsettings.html
These PRs are not valid in their current state, so I think you can close them for now until there's a better assessment about the proper solution.
If you intend to share some code you've made for testing purpose, you can just link your commit directly like this:
https://github.com/godotengine/godot/pull/41177/commits/4a2c8e3bc29ed1f7abc88fcaaf8f4fe40617f2d6
Here are some general rules about how to setup and format PRs properly:

The commit message, PR title and PR description need to specifically explain what the changes in code are.
You need to make sure you target the proper branch for the PR to work properly. If you see too many file changes while you're setting it up it means you're targeting the wrong one.
You can setup your PR as draft when it's still work in progress so it doesn't trigger reviews automatically.

@pouleyKetchoupp fair enough, thanks for taking the time to write such an informative reply. I'll improve the issue report this afternoon (morning here now).

OK, I edited the issue to include a small test project, along with the code as a snippet for convenience, and two screenshots showing before and after applying the patch.

@clayjohn @lawnjelly Would it make sense to add an option in project settings or an extra argument to draw_line in order to allow sub-pixel line width? I don't see any easy workaround for this issue otherwise.

The issue is not really about sub-pixel but about zooming the view. A sub-pixel line may be many pixels thick if you get close enough.
Maybe the parameter should be about using world or screen space width. Or have a separate draw function. I clearly see the need for being able to draw in the two ways.

I agree with @Calinou I see it as an established convention. Perhaps not ideal in retrospect, but changing it would lead to compatibility breakage. Certainly changing it for 3.x would be a controversial idea.
It is not super obvious, but the reason for the difference is sound - there is a hardware accelerated path for single pixel lines, but not necessarily for wide lines.
It could potentially be changed for 4.x, having e.g. a different function that guarantees a single pixel line that could be used from e.g. the IDE code no matter what the scaling, and then changing the existing one to switch to a scaling solution if the scale was not 1. This would be considerably more involved than the PRs so far though, involving a new render types, functions etc.
Personally I'm not convinced it will be worth it in terms of the extra code and bug surface, versus the existing quirk of setting line width to e.g. 1.01 if you want a scaling line. But it is doable. Someone who wanted to change should probably ask @reduz his opinion before doing any changes in this area, because he might be happy with the situation as is.
Another simpler alternative is to hard code e.g. gdscript etc to override and use 1.01 width when you try to select 1 width, then add another function to the language APIs to hard code single pixel width line. There might be other ways of doing it, these are just top of my head.

Maybe a negative size (and a constant with a meaningful name) could be a pixel perfect line?

@lawnjelly As mentioned by @m6502 the current use case is more a problem of drawing lines with width <=1 on a zoomed canvas, where the final rendering would normally be actually more than one pixel. You can also reproduce it when running the game. With a scale of 10 on the canvas, it currently draws a line of width 0.5 as a 1 pixel line, rather than 5 pixels, but it draws a line of width 2 with 20 pixels.

Maybe a negative size (and a constant with a meaningful name) could be a pixel perfect line?

Yes potentially, that is a good idea .. I'm not familiar with the API side (only the bit in the render backend). Setting the default to this. It still has a small risk, because anyone specifying a width of 1 will get drastically lower performance.

@lawnjelly As mentioned by @m6502 the current use case is more a problem of drawing lines with width <=1 on a zoomed canvas, where the final rendering would normally be actually more than one pixel. You can also reproduce it when running the game. With a scale of 10 on the canvas, it currently draws a line of width 0.5 as a 1 pixel line, rather than 5 pixels, but it draws a line of width 2 with 20 pixels.

Sorry, I only edited my post to add this shortly before you replied. Agree that this could be better.

Maybe it should go in godot proposals? With pros and cons of different approaches so juan can have a look, as he will probably make the final decision on this as it will affect vulkan too.

Agreed, this discussion seems more involved than just deciding of a fix or a small change in code.
@m6502 Please open a ticket in there and follow the template:
https://github.com/godotengine/godot-proposals
Also for info:
In 4.0, the 1-pixel rule is handled in the server directly, so it seems that it would be easier to allow scaled lines with width <= 1, by adding an extra argument or handling negative values in a special way:
https://github.com/godotengine/godot/blob/d3b5c0948c943b3fbcb4b5322262c59c92abfa83/servers/rendering/rendering_server_canvas.cpp#L465-L487

Duplicate of #

Duplicate of #

Really? I searched for it before opening the issue. In any case I'll open the proposal as I think it's worth it.

Looks like it might be this issue: #19844
But yeah a proposal would be better for this discussion anyway, and I don't see any on the topic.

Not sure how could I overlook that! Maybe I did the search with the draw_rect() function instead, as that's how I found the issue. Well then, closing this issue and let's continue later when I write the proposal, thanks everyone for the comments.


[Enhancement?] Growing End Grass types by checking a 3x3x3 box?

I use Fabric v.1.11.1 on MC 1.16.5 and API v.0.30.3, and mod version is v.0.9.1-pre-1.16.4/5
One thing i noticed about growing End Grass types (all of them) is that it's pretty limited: while growing vanilla Nylium is omni-directional and checks for near Nylium blocks in a 3x3x3 blocks area, while the End Grasses only checks if there is one next to it in the same x or z coordinate.
I'm posting images in order to show what i am trying to explain:
Vanilla Nylium;
All End Grass.
The green circles indicates where bone meal can be used, and the red crosses indicate where it cannot be used
Is it possible to apply the bone meal growth logic of vanilla Nylium to all End Grass types? I was doing something crazy and turning a Mushroom Fields biome into one of these End biomes, but without the Nylium logic this is going to be unpractical (having to grow grass and use Silk Touch to place them manually might be a nightmare, while vanilla Nylium doesn't need this)

Piggybacking off your post a little to ask a question, sorry!
Are you able to grow/spread The End biome grass/moss/phylium/what-have-you? I thought it would be possible but it seems I can't use bonemeal at all, implying the biome tiles are a finite resource that can only be retrieved by silk touch. They're so pretty, so it's a bit of a bummer.

@Fabrieze, the answer is directly in the suggestion - you can grow End grasses with bonemeal

@Fabrieze, the answer is directly in the suggestion - you can grow End grasses with bonemeal

Yup! I see that. But it doesn't work for me, so I was asking rather if there was something I'm doing wrong. I set up end stone next to an end block as OP had done, but it doesn't do anything.

If you're talking about "phylium", you're probably talking about BYG (Oh the Biomes you'll go) blocks! Because "phylium" is a thing from BYG, and yeah, the "phylium" blocks from BYG do not indeed work at all (like most things in that mod). If you press F3+H, you'll see the block ID, and you will also see what mod that block is part of. If you're not using BYG, then you should update BetterEnd.

Added in 0.9.2


chore: use managed-gitops CR to deploy AppStudio Components in e2e

These changes add managed-gitops objects to deploy the component image:

Create the GitOpsDeployment CR
Check if the image generated by pipelines previously was deployed
Check deployment status, routes, services
API rest request to the backend to ensure the component is working properly

:test_tube:

/lgtm
verified against my cluster

Merged main branch after: https://github.com/redhat-appstudio/e2e-tests/pull/62
Feel free to merge

/retest


Add support for SSS groups

Suggested by Adrian here:
https://forum.appleseedhq.net/t/does-appleseed-support-a-shader-with-sss-grouping/218?u=franz
The idea is to be able to treat multiple intersecting/overlapping closed objects with the same SSS material as a single object. That means ignoring interior intersections when doing subsurface sampling (a stack would be needed to keep track of enter/leave events and only keep the last event).

There is also the invert: Use multiple groups (generically named trace set) to separate SSS (or reflection) from two objects.
We relied on this a lot for almost everything on Ballerina (sss, reflection, indirect diffuse, etc.).
http://guerillarender.com/doc/1.4/User Guide_Scene Graph_Set.html
http://guerillarender.com/doc/1.4/User Guide_Rendering_Trace Linking.html
https://support.solidangle.com/display/ARP/Using+Trace+Sets


Allow re-signing of IS locks when performing retroactive signing

This PR implements re-signing of IS locks, which however is only performed when a non-locked TX appears in a new block. This is required to make retroactive signing work in cases where parts of the network has already seen the TX via mempool and other parts only see it first via a block.
In such cases, the first part of the network (via mempool) might have run into a timeout for the signing sessions, which causes the session to never be completed even if the other part of the network does the signing when it finally receives the TX via a block.
With this PR, the first part of the network will re-sign the TX when necessary at the time it receives the block. This ensures that all necessary signature shares can be collected and the IS lock be formed.
This PR also implements a set of tests for retroactive signing. The tests performed in test_single_node_session_timeout are the ones that test the new behavior. All other tests are testing already existing behavior.

It looks like a similar patch with an early reconnection would have to be added to other places after #3221 but that would be incompatible with the logic in these tests I think. So I have a new idea now :) pls see #3222 + 253ba29853714c7143a9ddbc973288dbe8dc1750 + e514ad16c0b0078683f5a716334867bf8628fddf

I pushed a fix for the failures on Gitlab. I have a loop of this test running since an hour and it didn't fail so far. @UdjinM6 You came to late with your changes :P But I'm looking into it now, looks like you found a better way to simulate mempool inconsistencies

@UdjinM6 fyi, your fix is running on my machine since about 45 minutes without failure. I tend to throw away my fix and use yours instead

Rebased on develop after merging in the other small fixes

I cleaned up and squashed the PR so that it doesn't contain all the "fix" commits


add warning await within()

Motivation/Description of the PR

Description of this PR, which problem it solves
We ran into issues using the within() function. It seems that when running with Selenoid, the within() step would never complete and need to be aborted manually. However this was fixed easily by adding an await to our within function call (we were using async Webdriver methods inside the within call). I thought adding a line about this to the existing warning about within in the docs might help, though I'm open to other ways of doing this!

Resolves #issueId (if applicable).
None I think
Applicable helpers:

[x] WebDriver

[ ] Puppeteer

[ ] Nightmare

[ ] REST

[ ] FileHelper

[ ] Appium

[ ] Protractor

[ ] TestCafe

[ ] Playwright

Applicable plugins:

[ ] allure
[ ] autoDelay
[ ] autoLogin
[ ] customLocator
[ ] pauseOnFail
[ ] puppeteerCoverage
[ ] retryFailedStep
[ ] screenshotOnFail
[ ] selenoid
[ ] stepByStepReport
[ ] wdio

Type of change

[ ] :fire: Breaking changes
[ ] :rocket: New functionality
[ ] :bug: Bug fix
[x] :clipboard: Documentation changes/updates
[ ] :hotsprings: Hot fix
[x] :hammer: Markdown files fix - not related to source code
[ ] :nail_care: Polish code

Checklist:

[ ] Tests have been added
[ ] Documentation has been added (Run npm run docs)
[ ] Lint checking (Run npm run lint)
[ ] Local tests are passed (Run npm test)

Thanks! Important remark


TypeScripts Type System is Turing Complete

This is not really a bug report and I certainly don't  want TypeScripts type system being restricted due to this issue. However, I noticed that the type system in its current form (version 2.2) is turing complete.
Turing completeness is being achieved by combining mapped types, recursive type definitions, accessing member types through index types and the fact that one can create types of arbitrary size.
In particular, the following device enables turing completeness:
type MyFunc<TArg> = {
  "true": TrueExpr<MyFunction, TArg>,
  "false": FalseExpr<MyFunc, TArg>
}[Test<MyFunc, TArg>];

with TrueExpr, FalseExpr and Test being suitable types.
Even though I didn't formally prove (edit: in the meantime, I did - see below) that the mentioned device makes TypeScript turing complete, it should be obvious by looking at the following code example that tests whether a given type represents a prime number:
type StringBool = "true"|"false";

interface AnyNumber { prev?: any, isZero: StringBool };
interface PositiveNumber { prev: any, isZero: "false" };

type IsZero<TNumber extends AnyNumber> = TNumber["isZero"];
type Next<TNumber extends AnyNumber> = { prev: TNumber, isZero: "false" };
type Prev<TNumber extends PositiveNumber> = TNumber["prev"];

type Add<T1 extends AnyNumber, T2> = { "true": T2, "false": Next<Add<Prev<T1>, T2>> }[IsZero<T1>];

// Computes T1 * T2
type Mult<T1 extends AnyNumber, T2 extends AnyNumber> = MultAcc<T1, T2, _0>;
type MultAcc<T1 extends AnyNumber, T2, TAcc extends AnyNumber> =
		{ "true": TAcc, "false": MultAcc<Prev<T1>, T2, Add<TAcc, T2>> }[IsZero<T1>];

// Computes max(T1 - T2, 0).
type Subt<T1 extends AnyNumber, T2 extends AnyNumber> =
		{ "true": T1, "false": Subt<Prev<T1>, Prev<T2>> }[IsZero<T2>];

interface SubtResult<TIsOverflow extends StringBool, TResult extends AnyNumber> {
	isOverflowing: TIsOverflow;
	result: TResult;
}

// Returns a SubtResult that has the result of max(T1 - T2, 0) and indicates whether there was an overflow (T2 > T1).
type SafeSubt<T1 extends AnyNumber, T2 extends AnyNumber> =
		{
			"true": SubtResult<"false", T1>,
            "false": {
                "true": SubtResult<"true", T1>,
                "false": SafeSubt<Prev<T1>, Prev<T2>>
            }[IsZero<T1>]
		}[IsZero<T2>];

type _0 = { isZero: "true" };
type _1 = Next<_0>;
type _2 = Next<_1>;
type _3 = Next<_2>;
type _4 = Next<_3>;
type _5 = Next<_4>;
type _6 = Next<_5>;
type _7 = Next<_6>;
type _8 = Next<_7>;
type _9 = Next<_8>;

type Digits = { 0: _0, 1: _1, 2: _2, 3: _3, 4: _4, 5: _5, 6: _6, 7: _7, 8: _8, 9: _9 };
type Digit = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9;
type NumberToType<TNumber extends Digit> = Digits[TNumber]; // I don't know why typescript complains here.

type _10 = Next<_9>;
type _100 = Mult<_10, _10>;

type Dec2<T2 extends Digit, T1 extends Digit>
	= Add<Mult<_10, NumberToType<T2>>, NumberToType<T1>>;

function forceEquality<T1, T2 extends T1>() {}
function forceTrue<T extends "true">() { }

//forceTrue<Equals<  Dec2<0,3>,  Subt<Mult<Dec2<2,0>, _3>, Dec2<5,7>>   >>();
//forceTrue<Equals<  Dec2<0,2>,  Subt<Mult<Dec2<2,0>, _3>, Dec2<5,7>>   >>();

type Mod<TNumber extends AnyNumber, TModNumber extends AnyNumber> =
    {
        "true": _0,
        "false": Mod2<TNumber, TModNumber, SafeSubt<TNumber, TModNumber>>
    }[IsZero<TNumber>];
type Mod2<TNumber extends AnyNumber, TModNumber extends AnyNumber, TSubtResult extends SubtResult<any, any>> =
    {
        "true": TNumber,
        "false": Mod<TSubtResult["result"], TModNumber>
    }[TSubtResult["isOverflowing"]];

type Equals<TNumber1 extends AnyNumber, TNumber2 extends AnyNumber>
    = Equals2<TNumber1, TNumber2, SafeSubt<TNumber1, TNumber2>>;
type Equals2<TNumber1 extends AnyNumber, TNumber2 extends AnyNumber, TSubtResult extends SubtResult<any, any>> =
    {
        "true": "false",
        "false": IsZero<TSubtResult["result"]>
    }[TSubtResult["isOverflowing"]];

type IsPrime<TNumber extends PositiveNumber> = IsPrimeAcc<TNumber, _2, Prev<Prev<TNumber>>>;

type IsPrimeAcc<TNumber, TCurrentDivisor, TCounter extends AnyNumber> =
    {
        "false": {
            "true": "false",
            "false": IsPrimeAcc<TNumber, Next<TCurrentDivisor>, Prev<TCounter>>
        }[IsZero<Mod<TNumber, TCurrentDivisor>>],
        "true": "true"
    }[IsZero<TCounter>];

forceTrue< IsPrime<Dec2<1,0>> >();
forceTrue< IsPrime<Dec2<1,1>> >();
forceTrue< IsPrime<Dec2<1,2>> >();
forceTrue< IsPrime<Dec2<1,3>> >();
forceTrue< IsPrime<Dec2<1,4>>>();
forceTrue< IsPrime<Dec2<1,5>> >();
forceTrue< IsPrime<Dec2<1,6>> >();
forceTrue< IsPrime<Dec2<1,7>> >();

Besides (and a necessary consequence of being turing complete), it is possible to create an endless recursion:
type Foo<T extends "true", B> = { "true": Foo<T, Foo<T, B>> }[T];
let f: Foo<"true", {}> = null!;

Turing completeness could be disabled, if it is checked that a type cannot use itself in its definition (or in a definition of an referenced type) in any way, not just directly as it is tested currently. This would make recursion impossible.
//edit:
A proof of its turing completeness can be found here

😆  Just a pedantic tip, we might need to implement a minimal language to prove TypeScript is turing complete.
http://stackoverflow.com/questions/449014/what-are-practical-guidelines-for-evaluating-a-languages-turing-completeness
https://sdleffler.github.io/RustTypeSystemTuringComplete/

That's pretty interesting.
Have you looked into using this recursion so as to say iterate over an array for the purpose of e.g. doing a type-level reduce operation? I'd wanted to look into that before to type a bunch more operations that so far did not seem doable, and your idea here already seems half-way there.
The idea of doing array iteration using type-level recursion is raising a few questions which I'm not sure how to handle at the type level yet, e.g.:

arr.length: obtaining type-level array length to judge when iteration might have finished handling the entire array.
destructuring: how to destructure arrays at the type level so as to separate their first type from the rest. getting the first one is easy ([0]), destructuring such as to get the rest into a new array, not so sure...

So, TS can prove False? (as in Curry-Howard)

I think stacks a typed length and with each item having an individual type should be possible by adding an additional type parameter and field to the numbers from my example above and storing the item in the number. Two stacks are half the way to proving formal turing completeness, the missing half is to implement a finite automata on top of that.
However, this is a complex and time consuming task and the typical reason why people want to disprove turing completeness in typesystems is that they don't want the compiler to solve the halting problem since that could take forever. This would make life much harder for tooling as you can see in cpp. As I already demonstrated, endless recursions are already possible, so proving actual turing completeness is not that important anymore.

@be5invis What do you mean with that?
@HerringtonDarkholme
I've implemented a turing machine interpreter: https://gist.github.com/hediet/63f4844acf5ac330804801084f87a6d4

@hediet: Yeah, good point that in the absence of a way to infer type-level tuple length, we might get around that by manually supplying it. I suppose that'd also answer the destructuring question, as essentially you'd just keep picking out arr[i] at each iteration, using it to calculate an update reduce() accumulator. It'd no longer be very composable if the length could not be read on the fly, but it's still something -- and perhaps this would be relatively trivial to improve on, anyway.
I suppose that still leaves another question to actually pull off the array iteration though. It's coming down to the traditional for (var i = 0; i < arr.length; i++) {} logic, and we've already side-stepped the .length bit, while the assignment is trivial, and you've demonstrated a way to pull off addition on the type level as well, though not nearly as trivial.
The remaining question for me would be how to deal with the iteration check, whether as i < arr.length or, if reversed, i == 0. It'd be nice if one could just use member access to distinguish the cases, e.g. { 0: ZeroCase, [rest: number]: ElseCase }[i], but this fails as it requires ZeroCase to sub-type ElseCase.
It feels like you've covered exactly these kind of binary checks in your Test<MyFunc, TArg> case. but it seems to imply a type-level function (MyFunc) that could do the checks (returning true / false or your string equivalents). I'm not sure if we have a type-level == (or <) though, do we?
Disclaimer: my understanding of the general mechanisms here may not be as far yet.

So I think where this would get more interesting is if we could do operations on regular type-level values (e.g. type-level 1 + 1, 3 > 0, or true && false). Inspired by @hediet's accomplishment, I tried exploring this a bit more here.
Results:

Spoiler: I haven't pulled off array iteration.
I think I've figured out boolean operations (be it using 0/1, like string here) except Eq.
I think type checks (type-level InstanceOf, Matches, TypesEq) could be done if #6606 lands (alternatives?).
I'm not sure how to go about number/array operators without more to go by. Array (= vector/tuple) iteration seems doable given a way to increment numbers -- or a structure like @hediet used, if it could be construed from the array. Conversely, number operations could maybe be construed given operations on bit vectors and a way to convert those back and forth... tl;dr kinda stumped.

These puzzles probably won't find solutions anytime soon, but if anything, this does seem like one thread where others might have better insights...

I made some progress, having tried to adapt the arithmetic operators laid out in the OP so as to work with number literals instead of special types. Skipped prime number stuff, but did add those operators like > etc.
The downside is I'm storing a hard-coded list of +1 increments, making it scale less well to higher numbers. Or negatives. Or fractions.
I mainly wanted to use them for that array iteration/manipulation though. Iteration works, and array manipulation, well, we can 'concatenate' tuple types by constructing a numeric object representing the result (with length to satisfy the ArrayLike interface if desired).
I'm honestly amazed we got this far with so few operators. I dunno much about Turing completeness, but I guess functions seem like the next frontier now.

@be5invis You're thinking of an unsound type system. Turing completeness merely makes type checking undecidable. So, you can't prove false, but you can write something that is impossible to prove or disprove.

@aij TypeScript has its fair share of unsoundness too: https://github.com/Microsoft/TypeScript/issues/8459

This is like c++ metaprogramming ?

@iamandrewluca From what I understand -- yes.

Turing completeness could be disabled, if it is checked that a type cannot use itself in its definition (or in a definition of an referenced type) in any way, not just directly as it is tested currently. This would make recursion impossible.

Possible relevant tickets:

https://github.com/Microsoft/TypeScript/issues/6230
https://github.com/Microsoft/TypeScript/issues/3496#issuecomment-128553540

so we can we write an undecidable type in ts, cant we?

so we can we write an undecidable type in ts, cant we?

Yes.
If indeed TypeScript spec is Turing complete, for any TS compiler, there is a program that the compiler could not correctly type check.
Whether this matters practically is an entirely different story. There are already programs you could not compile, due to limited stack space, memory, etc. on your computer.

@pauldraper:

Whether this matters practically is an entirely different story. There are already programs you could not compile, due to limited stack space, memory, etc. on your computer.

If you try to take idiomatic functional programming concepts from JS to TS (generics, currying, composition, point-free function application), type inference breaks down pretty much immediately. The run-time JS though runs fine. Hardware isn't the bottleneck there.

@pauldraper

For any TS compiler, there would be a program that the compiler could not correctly type check.

This is true regardless of whether the type system itself is Turing-complete.
function dec(n: number): boolean {
    return n === 0 ? true : dec(n - 1);
}
let x: boolean = dec(10) ? true : 42;

TypeScript can't typecheck this program, even though it doesn't evaluate to an error.

TypeScript can't typecheck this program, even though it doesn't evaluate to an error.

What do you mean? The TS compiler checks that program just fine and properly finds the type-error?

@paldepind The point is that the else clause of the ternary is unreachable so the program should in fact pass the type checker (but it does not); i.e., dec(10) returns true (and 10 is a compile time constant/literal).

@johanatan Just because the else clause is never taken doesn't make the program well-typed. Generally how code is actually run during execution does not affect whether or not a program is well-typed. If you look at the specification it states that the type of a conditional expression is the union of the types of the two expressions (i.e. the if and the else case). Thus, dec(10) ? true : 42; has the type boolean | number and hence you example is ill-typed. That error is correctly reported by the TS compiler.

@paldepind
The meaning of being well-typed is fundamentally linked to run-time behavior. Milner [1] coined the phrase well-typed programs cannot 'go wrong', where going 'wrong' has a specific definition.
A type system is sound if any well-typed program cannot go wrong. A type system is complete if any program that cannot go wrong is well-typed.
The example program does not go wrong and therefore TypeScript is giving a false-positive by reporting a type error.
[1] A theory of type polymorphism in programming (1978)

@jack-williams
That is a good quote. But, I think there's a difference between saying "well-typed programs cannot 'go wrong'" and saying "programs that don't 'go wrong' are well-typed". The implication is in different directions. The first statement is valid (Milner said it) but I don't think the second is.
The example program doesn't go wrong. But that does not make it well-typed. A program is well-typed if it satisfies the typing rules of the given language. The example program does not satisfy the typing rules of TypeScript and thus it is not well-typed.
@johanatan wrote that "the program should, in fact, pass the type checker" because the program doesn't go wrong. But, that is not the criteria that decide if a program should pass a type-checker. A program should pass a type-checker if it satisfies the typing rules of a language. And the program in question does not.
Soundness and completeness are properties of the type system. Whether or not a program is well-typed is a property of the program in relation to the type system. These things are unrelated. As an example simply typed lambda calculus it both sound and complete. But, still it is easy to write a program in lambda calculus that doesn't 'go wrong' at run-time but which would still not be well-typed according to the simply typed lambda calculus type-system. That is an example of "doesn't go wrong does not imply well-typed".
Anyway, it is possible that I may have gotten something wrong. In that case, please correct me 😄

But, I think there's a difference between saying "well-typed programs cannot 'go wrong'" and saying "programs that don't 'go wrong' are well-typed". The implication is in different directions.

Yes this is exactly right; though I wasn't suggesting that they were the same.

A program is well-typed if it satisfies the typing rules of the given language. The example program does not satisfy the typing rules of TypeScript and thus it is not well-typed.

I'm not saying that the definition of being well-typed is not going wrong. You're free to define it as you say. However that definition alone tells us very little; we can say that something satisfies the rules but what does that mean? How would we compare one checker for JavaScript with another? I could come up with a set of ad-hoc rules that let you write buggy programs that are technically well-typed, but my notion of being well-typed is inferior to TypeScript's.
So it's helpful to have an external notion, which has long been the class of 'safe' programs that don't get stuck during evaluation. With that I can talk to someone about my system and tell them what it means to be well-typed in my system, without depending on the specific rules of my system.
While we expect most systems to be sound with respect to this notion of 'safe programs', programmers have happily lived with the fact that we can't have completeness. Programmers wont be able to write programs they know to be safe because the type-checker will get in the way.
Adding Turing Completeness to the type system isn't such a big deal because the undecidability can be exchanged for incompleteness by bounding the checker, and programmers have already been living with incompleteness. That was my only real point!

I completely agree with what @jack-williams stated above and, yes, according to the rules of the TypeScript type system, what I stated was incorrect.
However, the line between "compile-time" and "run-time" is quite blurred these days via several techniques: multi-stage programming & refinement types to name a couple. In the former, one can think of runtime as merely the final "stage" (and clearly from a human perspective we can reason at any number of meta- levels).

@RyanCavanaugh Gödel's incompleteness theorems still apply here, via the Curry–Howard isomorphism.
{Complete, Sound, Decidable}: Pick two. (or fewer)

@jack-williams @johanatan I fully agree with both of your latest comments. So it seems that we agree :smile:
@aij

{Complete, Sound, Decidable}: Pick two. (or fewer)

That is not the entire story though. You can have completeness, soundness, and decidability at the same time. Simply typed lambda calculus is a case in point. Then you have to forego Turing completeness. Sometimes that is the appropriate tradeoff. For instance in languages like Coq and Idris.
You probably know that but I just wanted to point it out.

https://github.com/zuozijian3720/24game

Came up a way to concatenate tuples in typescript@next, it's not practical, but I think it helps for people  investing fun. Expecting typescript type system being better.
type ToTuple<T> = T extends any[] ? T : any[];

type Head<Tuple extends any[]> = Tuple extends [infer H, ...any[]] ? H : never;
type Tail<Tuple extends any[]> = ((...t: Tuple) => void) extends ((h: any, ...rest: infer R) => void) ? R : never;
type Unshift<Tuple extends any[], Element> = ((h: Element, ...t: Tuple) => void) extends (...t: infer R) => void ? R : never;
type Push<Tuple extends any[], Element, R = Reverse<Tuple>, T extends any[]= ToTuple<R>> = Reverse<Unshift<T, Element>>;

type Reverse<Tuple extends any[]> = Reverse_<Tuple, []>;
type Reverse_<Tuple extends any[], Result extends any[]> = {
    1: Result,
    0: Reverse_<Tail<Tuple>, Unshift<Result, Head<Tuple>>>
}[Tuple extends [] ? 1 : 0];

type Concat<Tuple1 extends any[], Tuple2 extends any[], R = Reverse<Tuple1>, T extends any[]= ToTuple<R>> = Concat_<T, Tuple2>;
type Concat_<Tuple1 extends any[], Tuple2 extends any[]> = {
    1: Reverse<Tuple1>,
    0: Concat_<Unshift<Tuple1, Head<Tuple2>>, Tail<Tuple2>>,
}[Tuple2 extends [] ? 1 : 0];

type x = Concat<[1, 2, 3], [4, 5, 6]>; // [1, 2, 3, 4, 5, 6]

You can do math relatively efficiently if you instead use a LUT and do it digit-by-digit:
https://github.com/aman-tiwari/shape-types/blob/master/index.ts

@jack-williams

For any TS compiler, there would be a program that the compiler could not correctly type check.

This is true regardless of whether the type system itself is Turing-complete.

"Correct type check" means verify types according to the language specification*. If you take "correct type check" to be "verify there are no runtime errors" ... then yes, no compiler of TS, Java, Lisp, COBOL or any other programming language can provide those assurances.
It's such a meaningless interpretation as to be irrelevant. Type checking is performed according to the language specification, period.

https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md Though it's really out of date right now.

I wanted to see how far can I push it and built a Bracket Expression verifier using @fightingcat 's Tuples and @hediet 's awesome example and automata.
https://github.com/Crypto-Punkers/labs/blob/master/metaprogramming/src/brackets.ts
One interesting thing I've noticed is that it's easy to lose typing information with Tuples, as the TSC will happy convert them into more general forms when for example passing it inside generics.
type Tail<Tuple extends any[]> = ((...t: Tuple) => void) extends ((
  h: any,
  ...rest: infer R
) => void)
  ? R
  : never;
type IsEmpty<Tuple extends any[]> = {
  true: "true";
  false: "false";
}[Tuple extends [] ? "true" : "false"];

type Next<Tuple extends any[], TState extends State<any>> = {
  value: Tail<TState["value"]>;
};

type SpecificTuple = [1, 2, 3];
type State<Tuple extends any[]> = { value: Tuple };
type Result = Next<SpecificTuple, State<SpecificTuple>>;

//Actual result:
// type Result = {
//   value: any[];
// };

//Favourable result:
// type Result = {
//   value: [2, 3];
// };

type Next<Tuple extends any[], TState extends State<any>> = {
  value: Tail<TState extends State<infer R> ? R : never>;
};

@ritave You can change your Next to like this.

A way to convert union to tuple, we have ability to iterate properties now.

@fightingcat nice, does this make a custom implemented Merge type possible?

@hediet No need for that, there is already a trick doing the union to intertection

@hediet No need for this, there is already a trick doing the union to intertection

Type-level addition, using tuples for natural numbers and 0|1|2|3|4|5|6|7|8|9 for digits.
type PopFront<TupleT extends any[]> = (
    ((...tuple : TupleT) => void) extends ((head : any, ...tail : infer TailT) => void) ?
    TailT :
    never
);
type PushFront<TailT extends any[], FrontT> = (
    ((front : FrontT, ...tail : TailT) => void) extends ((...tuple : infer TupleT) => void) ?
    TupleT :
    never
);
type ReverseImpl<InputT extends any[], OutputT extends any[]> = {
    0 : OutputT,
    1 : ReverseImpl<PopFront<InputT>, PushFront<OutputT, InputT[0]>>
}[
    InputT["length"] extends 0 ?
    0 :
    1
];
type Reverse<InputT extends any[]> = (
    ReverseImpl<InputT, []> extends infer X ?
    (
        X extends any[] ?
        X :
        never
    ) :
    never
);
type LeftPadImpl<TupleT extends any[], ElementT extends any, LengthT extends number> = {
    0 : TupleT,
    1 : LeftPad<PushFront<TupleT, ElementT>, ElementT, LengthT>
}[
    TupleT["length"] extends LengthT ?
    0 :
    1
];
type LeftPad<TupleT extends any[], ElementT extends any, LengthT extends number> = (
    LeftPadImpl<TupleT, ElementT, LengthT> extends infer X ?
    (
        X extends any[] ?
        X :
        never
    ) :
    never
);
type LongerTuple<A extends any[], B extends any[]> = (
    keyof A extends keyof B ?
    B :
    A
);

///////////////////////////////////////////////////////
type Digit = 0|1|2|3|4|5|6|7|8|9;
/**
 * A non-empty tuple of digits
 */
type NaturalNumber = Digit[];

/**
 * 6 - 1 = 5
 */
type SubOne<D extends Digit> = {
    0 : never,
    1 : 0,
    2 : 1,
    3 : 2,
    4 : 3,
    5 : 4,
    6 : 5,
    7 : 6,
    8 : 7,
    9 : 8,
}[D];
/**
 *
 * 9 + 1 = 10
 *
 * The ones place of `10` is `0`
 */
type AddOne_OnesPlace<D extends Digit> = {
    0 : 1,
    1 : 2,
    2 : 3,
    3 : 4,
    4 : 5,
    5 : 6,
    6 : 7,
    7 : 8,
    8 : 9,
    9 : 0
}[D];
/**
 *
 * 7 + 8 = 15
 *
 * The ones place of `15` is `5`
 */
type AddDigit_OnesPlace<A extends Digit, B extends Digit> = {
    0 : B,
    1 : AddDigit_OnesPlace<SubOne<A>, AddOne_OnesPlace<B>>
}[
    A extends 0 ?
    0 :
    1
];

//4
type addDigit_OnesPlace_0 = AddDigit_OnesPlace<6, 8>;
//6
type addDigit_OnesPlace_1 = AddDigit_OnesPlace<8, 8>;
//0
type addDigit_OnesPlace_2 = AddDigit_OnesPlace<9, 1>;

/**
 * 7 + 8 = 15
 *
 * Since it is `15 >= 10`, we have a carry
 */
type AddDigit_Carry<A extends Digit, B extends Digit> = {
    0 : false,
    1 : (
        AddOne_OnesPlace<B> extends 0 ?
        true :
        AddDigit_Carry<SubOne<A>, AddOne_OnesPlace<B>>
    )
}[
    A extends 0 ?
    0 :
    1
];
/*
type AddDigit_Carry<A extends Digit, B extends Digit> = (
    LtDigit<
        AddDigit_OnesPlace<A, B>,
        A
    >
);
*/

//true
type addDigit_carry_0 = AddDigit_Carry<7, 8>;
//true
type addDigit_carry_1 = AddDigit_Carry<9, 1>;
//false
type addDigit_carry_2 = AddDigit_Carry<8, 1>;

type AddDigitWithCarry_OnesPlace<A extends Digit, B extends Digit, CarryT extends boolean> = (
    CarryT extends true ?
    (
        B extends 9 ?
        (
            A extends 9 ?
            (
                //9+9+1 = 19
                9
            ) :
            (AddDigit_OnesPlace<AddOne_OnesPlace<A>, B>)
        ) :
        (AddDigit_OnesPlace<A, AddOne_OnesPlace<B>>)
    ) :
    AddDigit_OnesPlace<A, B>
);
type AddDigitWithCarry_Carry<A extends Digit, B extends Digit, CarryT extends boolean> = (
    CarryT extends true ?
    (
        B extends 9 ?
        (
            A extends 9 ?
            (
                //9+9+1 = 19
                true
            ) :
            (AddDigit_Carry<AddOne_OnesPlace<A>, B>)
        ) :
        (AddDigit_Carry<A, AddOne_OnesPlace<B>>)
    ) :
    AddDigit_Carry<A, B>
);

/**
 * + Assumes `A` and `B` have the same length.
 * + Assumes `A` and `B` have been reversed.
 *   So, `A[0]` is actually the **LAST** digit of the number.
 */
type AddNaturalNumberImpl<
    A extends NaturalNumber,
    B extends NaturalNumber,
    ResultT extends NaturalNumber,
    CarryT extends boolean
> = {
    0 : (
        AddDigitWithCarry_Carry<A[0], B[0], CarryT> extends true ?
        PushFront<
            PushFront<
                ResultT,
                AddDigitWithCarry_OnesPlace<
                    A[0],
                    B[0],
                    CarryT
                >
            >,
            1
        > :
        PushFront<
            ResultT,
            AddDigitWithCarry_OnesPlace<
                A[0],
                B[0],
                CarryT
            >
        >
    ),
    1 : (
        /**
         * This conditional type required so we do not hit the max instantiation depth
         */
        AddDigitWithCarry_Carry<A[0], B[0], CarryT> extends true ?
        AddNaturalNumberImpl<
            PopFront<A>,
            PopFront<B>,
            PushFront<
                ResultT,
                AddDigitWithCarry_OnesPlace<
                    A[0],
                    B[0],
                    CarryT
                >
            >,
            true
        > :
        AddNaturalNumberImpl<
            PopFront<A>,
            PopFront<B>,
            PushFront<
                ResultT,
                AddDigitWithCarry_OnesPlace<
                    A[0],
                    B[0],
                    CarryT
                >
            >,
            false
        >
    )
}[
    A["length"] extends 1 ?
    0 :
    1
];
type AddNaturalNumber<
    A extends NaturalNumber,
    B extends NaturalNumber
> = (
    AddNaturalNumberImpl<
        Reverse<LeftPad<A, 0, LongerTuple<A, B>["length"]>>,
        Reverse<LeftPad<B, 0, LongerTuple<A, B>["length"]>>,
        [],
        false
    >
);

//101264
export type addNaturalNumber_0 = AddNaturalNumber<
    [5,2,3,4,1],
    [4,8,9,2,3]
>;
//49446
export type addNaturalNumber_1 = AddNaturalNumber<
    [5,2,3],
    [4,8,9,2,3]
>;
//49446
export type addNaturalNumber_2 = AddNaturalNumber<
    [4,8,9,2,3],
    [5,2,3]
>;
//980
export type addNaturalNumber_3 = AddNaturalNumber<
    [5,7],
    [9,2,3]
>;

Playground

Just leaving this here by @acutmore
https://gist.github.com/acutmore/9d2ce837f019608f26ff54e0b1c23d6e

thanks @AnyhowStep - this issue thread was what originally inspired that gist :)
One challenge I kept hitting was 'Type instantiation is excessively deep and possibly infinite'. Thankfully turns out can use a good old fashioned trampoline to increase the limit. I had to put one trampoline inside another to get the limit high enough. Might be useful to someone else:
type Prepend<V extends any, Arr extends any[]> =
  ((v: V,...a: Arr) => any) extends (...a: infer Args) => any
    ? Args
    : [];

// Normal NTuple
type NTuple<N extends number, __accumulator extends any[] = []> = {
  0: NTuple<N, Prepend<any, __accumulator>>
  1: __accumulator
}[__accumulator["length"] extends N ? 1 : 0];

type Tuple5 = NTuple<5>; // [any, any, any, any, any]
type Tuple49 = NTuple<43>; // Err! Type instantiation is excessively deep and possibly infinite.

// NTuple again with a trampoline
type NTupleTrampoline<
  N extends number,
  __bounce extends any = Trampoline<N, [], []>
> = {
  0: NTupleTrampoline<N, Trampoline<N, __bounce['state'], []>>
  1: __bounce['state']
}[__bounce["tag"] extends 'done' ? 1 : 0];

type Trampoline<
  N extends number,
  Accumulator extends any[],
  NumberOfBounces extends any[]
> = {
  0: Trampoline<N, Prepend<any, Accumulator>,  Prepend<any, Accumulator>>;
  1: { tag: 'done', state: Accumulator }
  2: { tag: 'bounce', state: Accumulator }
}[Accumulator["length"] extends N
  ? 1
  : NumberOfBounces["length"] extends 30
    ? 2
    : 0];

type Tuple5Bounced = NTupleTrampoline<60>; // No Error,  [any * 60]

@acutmore check this out
up to 288 elements with less boilerplates.

Just add Unshift32 and get more

slightly refactored the code :)

We need a typescript backend that targets this 4 bit VM :D
How does your interpreted time correlate with interpretion time, @acutmore? For my turing machine implementation it sadly wasn't linear.

Good news everyone, I'm working on an interpreted language with typescript type system, parser implemented, I'll update  once everything is complete.

@fightingcat my goodness. I thought the round-trip might have been a bamboozle, but nope...

@RyanCavanaugh I'm almost done, have implemented parser and arithmetics, right now there is a working expression evaluator, (I've pushed to the repo)[https://github.com/fightingcat/sits].

I'm taking a few days off, then I'll finish statements evaluator, and module declarations. I'm afraid loop statement and variable assignment may cause TS2589 easily, but better than not implementing it.

wow @fightingcat! The whole 'sits' repo is a gem to read.
Still trying to grok how your division works, looks much more robust that than my naive "keep subtracting in a recursive type loop" implementation.

@fightingcat This is very impressive work. Keep going!
It might be interesting to implement Presburger arithmetic in TS. Unlike multiplication and division, (i.e. Peano arithmetic), addition, subtraction and comparison are all decidable operations.

My contribution: the problem "That's a Lot of Fish" from PlaidCTF 2020, a TypeScript reverse-engineering challenge.  When unmangled, it turns out to be a VM that runs completely in the type system.  I might have needed to relax some checks in tsc.js to make it work, though... 😅
The VM supports (arbitrary-precision) addition and multiplication, several bitwise operations, comparison, branching, and function calls.  It also has a section of memory that's made up entirely of leftist heaps and supports pushing and polling them as primitive operations.
For the problem, I wrote a little program that checks if the user's input is a minimum-weight Manhattan TSP solution for a graph that's hardcoded in memory, which only typechecks (and outputs out the flag) if the input is correct.  When given the correct input, it takes about three and a half minutes to typecheck, which is much faster than I was expecting.  (Though I did have to give it 16GB of heap and 8GB of stack to make it not crash.)

I could have sworn there was a repo full of awesome TS work like this, could anyone help me find it again? I know it had things like a solution to a Tower of Hanoi problem, prime number detection, subtraction, addition, etc

I wrote a text adventure in the typescript type system:

Blog Post: https://ricklove.me/typescript-type-system-adventure
Repo: https://github.com/ricklove/rick-love-master/tree/master/code/typescript-type-system-adventure

I could have sworn there was a repo full of awesome TS work like this, could anyone help me find it again? I know it had things like a solution to a Tower of Hanoi problem, prime number detection, subtraction, addition, etc

@crutchcorn Is this what you were looking for? https://github.com/ronami/meta-typing

@nimajneb YES! Thank you!

This is fascinating, but why is it an open issue? Is Turing completeness somehow a problem?
Might be time to enable that fancy new Discussions tab where things like this can take place. 😉

@mindplay-dk  By being Turing Complete, the type system is inconsistent and has situations where contradictions occur and/or certain types can not be resolved. A related post might be informative.

why is it an open issue

given there are currently ~5000 open issues, one more doesn't hurt 😉

A related post might be informative.

It's worth noting that due to the instantiation limit we do know that TypeScript's Type System will always halt.
// checker.ts
if (instantiationDepth === 50 || instantiationCount >= 5000000) {
  // We have reached 50 recursive type instantiations and there is a very high likelyhood we're dealing
  // with a combination of infinite generic types that perpetually generate new type identities. We stop
  // the recursion here by yielding the error type.
  tracing?.instant(tracing.Phase.CheckTypes, "instantiateType_DepthLimit", { typeId: type.id, instantiationDepth, instantiationCount });
  error(currentNode, Diagnostics.Type_instantiation_is_excessively_deep_and_possibly_infinite);
  return errorType;
}
totalInstantiationCount++;
instantiationCount++;
instantiationDepth++;

👾 Sokoban Game in Pure TypeScript Type System
https://github.com/fc01/type_game
demo

@sno2 that is an absolute delight, thank you

Turing completeness meaning all can describe computable problems can be solved.

Since 4.8 you can now make complex calculus :

You can check complete implementation here :
https://github.com/ecyrbe/ts-calc

@ecyrbe what does the n mean in those numbers? I’ve never seen that.

It's the JavaScript Bigint notation for numbers that are too Big to be represented by a number:
https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/BigInt

A little over a year ago, I decided I liked TypeScript.
In fact, I decided liked it so much, I didn't just want it to be stuck in my editor— I wanted to use the same syntax to validate my data at runtime! And what better way to achieve that than to use TypeScript's own type system to parse its own syntax.
Much to my surprise, what I ended up with was not a toy, but a remarkably performant static parser that allows definitions built from arbitrarily parenthesized and nested TS operators like |, &, [] etc. to be syntactically and semantically validated as you type, inferred by TypeScript, and reused by JS to validate runtime data.
At this point, it can handle hundreds of cyclic types seamlessly and import between scopes. As far as I'm aware,  ArkType is the most advanced application of TypeScript's type system to date:
https://user-images.githubusercontent.com/10645823/222860770-396e4062-522e-490f-bb95-7fab0187dc85.mp4

This is what it looks like to interact with a scope of 100 cyclic types:
https://user-images.githubusercontent.com/10645823/222860863-eed49730-3c5a-4a4d-a986-123497561821.mp4

Props to the TypeScript team- it's genuinely incredible that TS is so well-built that it can literally parse itself in real-time without being remotely optimized for it.

Considering this I think TS might as well implement a way for users to run arbitrary procedural code to destruct and construct types at compile time.  There are numerous situations where you end up writing some type mapping magic that's doing O(n^2) or worse computation when procedural code could do it in O(n).

okay this thread is crazy.

Considering this I think TS might as well implement a way for users to run arbitrary procedural code to destruct and construct types at compile time. There are numerous situations where you end up writing some type mapping magic that's doing O(n^2) or worse computation because you have to do something in a roundabout way when straightforward procedural code could do it in O(n).

not to mention the fact that only Functional Programming Galaxy Brains™ can figure out how to do much more with the type system than generics and maybe mapped types.
the type system is effectively a functional programming language, weaved into a multi-paradigm language, with a completely different syntax - it resembles C# on the surface, and it obviously resembles JS below the surface, but it's extremely foreign (even hostile at times) to people coming from either of those languages.
I love TS despite this glaring design problem, and front-end development at any real scale would be unbearable without it - but unless at some point there's a reckoning, I'm starting to think tides will eventually turn and TS won't last. 😥
I wish they would discuss possible avenues such as #41577 to break free of this.

If you like types, then you'd love runtime types.
https://deepkit.io/library/type
Deepkit Runtime Types support very complex types such as the following
https://github.com/deepkit/deepkit-framework/commit/934192c85a4afc435b521bee6d0329b1bc42a805

Considering this I think TS might as well implement a way for users to run arbitrary procedural code to destruct and construct types at compile time. There are numerous situations where you end up writing some type mapping magic that's doing O(n^2) or worse computation because you have to do something in a roundabout way when straightforward procedural code could do it in O(n).

not to mention the fact that only Functional Programming Galaxy Brains™ can figure out how to do much more with the type system than generics and maybe mapped types.
the type system is effectively a functional programming language, weaved into a multi-paradigm language, with a completely different syntax - it resembles C# on the surface, and it obviously resembles JS below the surface, but it's extremely foreign (even hostile at times) to people coming from either of those languages.
I love TS despite this glaring design problem, and front-end development at any real scale would be unbearable without it - but unless at some point there's a reckoning, I'm starting to think tides will eventually turn and TS won't last. 😥
I wish they would discuss possible avenues such as #41577 to break free of this.

Considering this I think TS might as well implement a way for users to run arbitrary procedural code to destruct and construct types at compile time. There are numerous situations where you end up writing some type mapping magic that's doing O(n^2) or worse computation because you have to do something in a roundabout way when straightforward procedural code could do it in O(n).

not to mention the fact that only Functional Programming Galaxy Brains™ can figure out how to do much more with the type system than generics and maybe mapped types.
the type system is effectively a functional programming language, weaved into a multi-paradigm language, with a completely different syntax - it resembles C# on the surface, and it obviously resembles JS below the surface, but it's extremely foreign (even hostile at times) to people coming from either of those languages.
I love TS despite this glaring design problem, and front-end development at any real scale would be unbearable without it - but unless at some point there's a reckoning, I'm starting to think tides will eventually turn and TS won't last. 😥
I wish they would discuss possible avenues such as #41577 to break free of this.

I'd recommend having a look at Deepkit Runtime Types

@marcus-sa Deepkit is a very cool project, but it is not built within TypeScript's type system.
Rather it parses native TS types externally and adds runtime metadata, so it's orthogonal to this thread.

Two years ago I wrote a toy language interpreter using typescript's type system in order to learn typescript's type gymnastics.
Here's the repository, here's the playground, and after that I didn't go any further...

I've been curious about writing types to parse GraphQL queries at type time, and, together with generated types from the schema, determine the query data and variables types.
I found a medium article where one dev tried this and ran into a lot of recursion depth limits.
This is one example of a case where it would be better if we could just use loops, stacks, and other procedural constructs at type time, rather than trying to use declarative constructs to accomplish the same thing.

We're really of the opinion that code to generate types from a source artifact should run once (when the source artifact changes), not once per keystroke (what happens if you do it in the type system via whatever means).

@jedwards1211 I actually agree both with you in that there's room for better abstractions here and @RyanCavanaugh that they shouldn't be a part of the language itself.
I mentioned ArkType earlier in the thread if you're interested in a highly-optimized type-level string parsing strategy.
Currently, the runtime and type-level implementation parsers are implemented in parallel by hand:

We've tossed around the idea a bit of creating a package that would provide an API for defining a parser that could generate optimized types and a runtime implementation from a single definition.
Probably not our top-priority, but if you're interested in contributing, I'd love to help facilitate making those strategies more reusable! Feel free to reach out on our community Discord.

@RyanCavanaugh

not once per keystroke

I don't understand, doesn't the language server already re-evaluate as you type?

@ssalbdivad even though ArkType is highly optimized, the size of strings it can parse must be limited by TS recursion depth, right?

@jedwards1211 Yes, but you could make a very practical gql parser within those limitations.
Character limit is 1001:

Expressions can have up to 46 operands:

And that is with arbitrary grouping, syntactic semantic validation (type-level error messages) etc.:

If it's possible to represent a definition while leveraging JS's built-in structures (object and tuple literals), yes there is a performance advantage to doing so, in addition to other benefits like better highlighting and formatting.
That said, with the right approach the type system will take you quite far, even with pure strings.

IMO a 1001 character limit isn't acceptable for this GraphQL use case in a production project, no one would use a compiler with such a severe limit.

@jedwards1211 What you have to consider is the boundary between a "type" (ideally something that can be compared to other types and tested for assignability) and arbitrary linting/static analysis.
What you're describing sounds much more like the second category, so maybe an extension to facilitate the DX you want would be ideal. I do understand the appeal of being able to ship something like that through native TS but it's pretty firmly outside the realm of "types" at that point.

@ssalbdivad I'm not sure what kind of linting you think I mean, I really am just talking about computing the input and output types for a GraphQL query.  And a type is a type, whether it's created by codegen-ing TS or by using TS type magic.

@jedwards1211 What I mean is that the arguments you pass to a generic type are themselves types.
They might happen to mirror a literal value, but that will not always be the case.
When you talk about loops, stacks, and other procedural constructs at type time, I assume you mean writing something like arbitrary imperative logic, which operates on values or terms, not types.
If you want them to be limited to a similar set of operations as can be expressed today via conditionals and mapped types, then sure, loops might be a mild syntactic convenience, but what you really want is perf optimizations and an increased recursion depth limit.
TS is already extremely performant in terms of how it handles this kind of parsing, so the increased limit is probably the more reasonable request of the two.
That said, I'd be surprised if there's not a way to split up a well-structured query such that it could fit within those limits.
Maybe I'm misunderstanding and I'm definitely rusty when it comes to GraphQL, but to me, 1000 characters for a single query sounds like a nightmare.

@ssalbdivad no I'm talking about a bold idea (probably too bold, but I always want more powerful capabilities) for a syntax/API for declaring functions that are passed API representations of the types, kind of like the API for inspecting types that you can access in ts-morph.
For example:
// new syntax, like a type alias but the code inside runs at type time
type function GreaterThan(A extends number, B extends number) {
  const aValue = A instanceof TS.NumberLiteral
    ? A.value
    : A instanceof TS.Union && A.options.every(opt => opt instanceof TS.NumberLiteral)
    ? Math.min(...A.options.map(opt => opt.value)
    : undefined
  const bValue = ... // likewise, but get max value of union

  return aValue == null || bValue == null ? TS.factory.never() : aValue > bValue ? TS.factory.true() : TS.factory.false()
}

// and voila, now it works for number literals of any magnitude:
type Test = GreaterThan<72374812, 8600200> // true

And then for something like parsing ArkType, if the function received a string literal type, it would parse it into an AST using procedural code that isn't limited by the size of the stack, and convert the AST into these TS type representations.
One thing about this TS maintainers would probably not like is, it would be hard to guarantee these type functions are pure and deterministic.  With great power comes great responsibility I guess...
If not for that then I wish TS were capable of instantiating tail-recursive types without nested invocations, so that we'd no longer be bound by these limits, and type decls would work more like actual functional programming languages.
And no, 1000 characters in a single GraphQL query isn't uncommon or a nightmare by any means.  There are three such queries in the production app I'm working on; here is one example.

Maybe this belongs in #41577 instead?

not once per keystroke
I don't understand, doesn't the language server already re-evaluate as you type?

If you have something like
// In file stuff.ts
interface Stuff {
  foo: string;
  bar: string;
}

// In the edited file
const p: Stuff = { foo: "hello", <- user is in the process of typing this

At each keystroke, the type of Stuff is getting recomputed, but this work is extremely minimal since it's all statically defined. The AST isn't changing, the symbol maps aren't changing, it's very very cheap.
If instead you had
// In file stuff.ts
type Stuff = ParseMyCoolDSL<"[[foo], string], [[bar], string]]">

// In the edited file
const p: Stuff = { foo: "hello", <- user is in the process of typing this

Similarly here, ParseMyCoolDSL is being re-evaluated every time, but this is a lot more work, and it's work (we as humans who know what the dependency tree is) that always results in the exact same shape. All the work of breaking apart the string, creating the temporary types, etc, creates work for the GC, and is just more work.
Even if we moved ParseMyCoolDSL into some "Just write code to make types" (JWCTMT) system then we have basically the same problem; the same work is being redone over and over and over again to produce the exact same result.
If we ever come up with a way to re-use type computations between program versions (still a great goal and still very much plausible IMO), then the non-code-based version of ParseMyCoolDSL is maybe something that could be identified to be "pure" (e.g. not dependent on inputs present in the file being edited), but the JWCTMT system is not going to work for that because we wouldn't be able to plausibly identify what inputs arbitrary code is depending on. JWCTMT sacrifices all possible future gain for some convenience today and I think it's the wrong thing to be asking for.

What @RyanCavanaugh describes is also a huge part of the reason that reusing native structures when representing shapes makes a lot of sense- incremental results, syntax highlighting, formatting.
Personally, I'd much rather read a giant gql query like the one you linked with each layer of the query defined individually rather than having everything in-lined. It's more reusable, and allows you to name various key sets based on how they're designed to be used which makes the intent of queries like that clearer compared to a single root name.
Again, definite caveat that I have little familiarity with "best practices" for these scenarios in GraphQL, but those concepts in engineering seem to be pretty universal.
If any change has the potential to create a great API for something like this, IMO it would be this one:
https://github.com/microsoft/TypeScript/pull/49552
Being able to compose your queries together naturally like that could offer an amazing DX while allowing you to break up your definitions into clear, composable units.

@ssalbdivad happy to take this discussion elsewhere if you have an idea where, but even if I broke the query text up into interpolated variables, magic TS types would still have to parse just as many characters, right?

@ssalbdivad IMO a 1001 character limit isn't acceptable for this GraphQL use case in a production project, in general no one would want a compiler to have such a severe limit. I will just continue to wish that more were possible.

There are posibilities, I had done some...things long time ago, but I abandoned it shamefully...That's why I never shared it here because of this embrassing fact. Here's the magic.
Take a try of parsing some long javascript-like code with it, it should compiled into a weired opcode (I did intend to write a vm for that...). Basically it takes advantage of LR parsing, and use some tricks to break throught the limits.
Luckily, a friend had translated my thoughts into English, hope it can be helpful.


multipart send/recv

Hiya! Just a couple methods I found useful—I need to work with multipart messages, which seems like it'd be a good addition to the Swifty library.
Let me know if this is useful to you too—no obligation to merge it! :)
Have a nice day,
Tim

Awesome. Just a couple of comments for it to get merged. Please add a defer { } block to zmq_msg_close after creation to handle failures and prevent memory leaks.

@tjvr  Any update on this one?

@azawawi Like this? :)

Thanks 👍

Cheers! :)


Measurement for Signify LCT026 (Hue Go 2.0)

Added measure for Hue Go 2.0 (and a couple of minor standby-usage re-measurements).

Nice one. Thanks!


Feature Request: Adding continuations to charm++ futures

Can we an additional feature within charm++ futures of adding continuations like future_object.then(<lambda or function or function object>)?
Need
Consider the following case:
Within a chare entry method (chare A), you create a future object 'F' and pass F to another chare's entry method (chare B). The entry method of chare B does some computation and calls set on F. At chare A, you want to execute code 'C' that relies on the result 'R' that arriving in F. Doing a get on F will block the executing thread until R has been set F. Calling probe will return a bool and notify if R has been set or not. While this is helpful, the placement of probe is crucial to ensure that it always returns true so that we can execute C. To mitigate this, I propose attaching continuations using .then.
Expected behavior
The continuation to a future is an asynchronous (non-blocking) call which ensures that C is executed as soon as F is ready.

The feature is fine to add. The use-case described can be much easily handled by avoiding future and just using entry method communication. Chare B does some computation, and invokes a method in A that contains code C.  If you want to insulate B from knowing about A, you can pass a callback from A to B (and possibly use simple implementation inheritance).


[C++] Arrow fails to build with python 3.12

Describe the bug, including details regarding any error messages, version, and platform.
Specifically, I am trying to build pyarrow but hit the following error:
  -- Found Python3: /pkg/main/dev-lang.python.core.3.12.2/bin/python3 (found version "3.12.2") found components: Interpreter Development.Module NumPy
  CMake Error at cmake_modules/FindPython3Alt.cmake:77 (message):
    Python 3 config failure:

    Traceback (most recent call last):

      File "<string>", line 1, in <module>

    ModuleNotFoundError: No module named 'distutils'

  Call Stack (most recent call first):
    CMakeLists.txt:262 (find_package)

  -- Configuring incomplete, errors occurred!

This is due to the code at https://github.com/apache/arrow/blob/main/cpp/cmake_modules/FindPython3Alt.cmake#L70 which uses distutils to obtain EXT_SUFFIX which is not valid on python 3.12.
I would suggest using this code instead:
  "import importlib.util; sysconfig = importlib.import_module('distutils.sysconfig') if importlib.util.find_spec('distutils') else importlib.import_module('sysconfig'); print(sysconfig.get_config_var('EXT_SUFFIX'))"

This will automatically import the right package depending on the availability of distutils and return the right value.
Component(s)
C++, Python

Thanks for opening the issue, I think there is actually a PR open for this, I will link it :)

Issue resolved by pull request 40322
https://github.com/apache/arrow/pull/40322


block timestamp wrong on development chain

with embark 0.8.6 on the development blockchain:
 geth attach ipc://tmp/embark/geth.ipc
instance: Geth/v1.1.0/darwin/go1.5
 datadir: /tmp/embark
coinbase: 0x1fd8dca4c80e43b66e07853f625a0759f8ffe424
at block: 4 (Thu, 01 Jan 1970 01:00:04 CET)
modules: admin:1.0 db:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 shh:1.0 txpool:1.0 web3:1.0
> web3.eth.getBlock(web3.eth.blockNumber).timestamp;
4

the block timestamp of mined blocks doesn't seem to reflect the current time:
$ date -u
Tue Aug 25 19:50:58 UTC 2015
$ date +%s
1440532282

This turned out to be a side effect of the geth bug / vulnerability https://blog.ethereum.org/2015/09/03/security-alert-implementation-bug-in-go-clients-causing-increase-in-difficulty-fixed-miners-check-and-update-go-clients-if-necessary/
on updating the block timestamps by miners; fixed in https://github.com/ethereum/go-ethereum/commit/fc3941d1fdfdea1b6c6e3053dea05979be3555e4 and geth 1.1.2


Write integration guide for GitHub Actions

Started work on this in #5239 but it's missing caching due to some outstanding work determining efficient cache setup in CI.

Not directly GitHub actions related, however keen on some recommendations for handling UV cache in a CI environment such as GitHub / Jenkins etc.
There's a statement in the docs clearly documenting it's not safe to modify the cache manually

Note that it's not safe to modify the uv cache directly (e.g., uv cache clean) while other uv commands are running, and never safe to modify the cache directly (e.g., by removing a file or directory).

However often in CI environments we might not want to have an infinitely growing cache, using cleanup configurations such as max cache sizes / keep by last used etc. However reading the above, worried that policies such as these might corrupt the cache / cause issues.
How would we cleanup caches safely in a CI environment, without having to drop the whole cache?
I.e. clean all artifacts not used in the last week, etc.
Do let me know if this should be tracked under a separate issue.

Let's chat over in https://github.com/astral-sh/uv/issues/5409 since I technically wrote this integration guide


Applied facet did not result in an "x" icon to dismiss it

That's against this data https://data.sfgov.org/City-Management-and-Ethics/Supplier-Contracts/cqi5-hm2d imported using https://datasette.io/plugins/datasette-socrata
It's for Contract Type of Non-Purchasing Contract (Rents, etc.) - so possible that some of the spaces or punctuation in either the name of the value tripped up the code that decides if the X icon should be displayed.

I think this is the relevant code:
https://github.com/simonw/datasette/blob/0b4a28691468b5c758df74fa1d72a823813c96bf/datasette/facets.py#L260-L268


Does the WinAppDriver UI Recorder support windows server 2016?

I'm interested in this question too.
I'm thinking installing a Terminal Server Machine with 10 users, and control parallel testing execution using Jenkins slave nodes.
Any experience in this?


[branch-2.0](migrate disk) fix migrate disk lost data during publish version #29887

pick: #29887
Tablet migrate disk may cause lost data. For example, suppose the old tablet's version is 10, it's just publish txn on version 11. At then comes a migrate disk task. After the old tablet just finish publish txn 11, but before it add rowset( version = 11). For the migrating task, the old tablet had no txn now, so the new tablet will copy the old tablet's data(old tablet's version is still 10). After copying, it will delete the old tablet, and replace it with the new tablet.
So data whose version is 11 will be lost.
Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


Strange main window and log behavior on <IP_ADDRESS>h, errors in log console

I'm having some strange behavior with version <IP_ADDRESS>h. (I made sure it was reproducible on my machine before reporting this, but knowing how bugs work, this will somehow magically solve itself on its own later lol.)
After some time using the program, the main window appears to get out of sync with the logs, and slowly moves to the more recent lines over time (without any new inputs) instead of staying in sync. At the same time this is occuring, the script-match drop down completely stops working on new lines in the log until the program is rebooted. The lines from before the glitch starts still work though. If I wait until it completely catches up, the drop down starts to work for a short time, then it stops again as new lines come in.
To my untrained eye, it almost looks like it is script-matching at the exact moment the OCR line comes in, even before the main window has a chance to update. Maybe it's matching so fast that the internal logic breaks somehow, forming some kind of loop? Just wildly speculating here, I'm likely quite wrong about that one. (this only started after updating to a version since regional matching was added, have been on a slightly older build until now.)
But in any case, every time this happens it throws this error in chrome's console in the log page (specifically the first one, included the second since it may be relevant despite only happening once. I haven't touched the anki part in this install.):

(Additional info: This is a clean install, aside from the game script. The only non-UI setting I have changed is "match_limit" from the default of 5 down to 2.)

I haven't checked yet, but there could a race condition issue with script match updating the main window while the OCR goes in, or it could be a completely different issue.

Are you able to recreate this issue with minimal amount of matching?

Yes. I can force it to happen by trying to match very quickly using a game script. I have it on a hotkey with a preset scan region, with that setup if I just scan the same line as fast as I see it pop into the log, it happens within thirty seconds to a minute every time. This is still happening on <IP_ADDRESS>i. It's making it hard to use this program, since every time it happens I have to reboot it.
(Pardon the late reply, have been away for the last couple days.)

Had some free time to poke around at this some more, and it seems that it was introduced in version <IP_ADDRESS>e, since I can't make this bug happen on builds 9d and older. Even mashing the hotkey more than 20 times as fast as I could didn't faze it at all.
Not completely sure where this build lines up here on github, but 9d was the first build that had the log limit and min match feature.


Allow glob pattern in routeRules

Environment
nitro v2.9.6
node v22.0.0
npm v10.5.1
Reproduction
Try to create a redirect or something for certain type of files
Describe the bug
So this is what I have in my config:
routeRules: {
  '/somewhere.js': {
    redirect: '/somewhere-else',
  },
},

This works fine, when I visit "somewhere.js" I got redirected. But If I want it to make it global, like this:
routeRules: {
  '/**.js': {
    redirect: '/somewhere-else',
  },
},

It simply doesn't work. What I tried: /**.js, /*.js, **.js, *.js, **/**.js. I also tried to add \ and \\ in front of the dot, but same results.
What kind of glob is used in the pattern? I didn't find in the docs information how to make custom routes for assets.
Additional context
No response
Logs
No response

also have a problem with -3 symbs
redirect to root route:
instead
'/demos/**': { redirect: { statusCode: 301, to: '/**' } }
need write
'/demos/**': { redirect: { statusCode: 301, to: '//**' } }


Queue RemoveValue() Crash

Issue details
Calling Queue#removeValue() causes a crash when removeLast() is called beforehand.
Reproduction steps/code
Queue<Integer> queue = new Queue<>();
queue.addFirst(1);
queue.addFirst(2);
queue.removeLast();
queue.removeValue(2, false);

This may also cause crashes in other scenarios. I believe the error is related to indexOf() returning the wrong value, e.g. 14 when it should be 0 in this case.
Version of LibGDX and/or relevant dependencies
1.9.9
Stacktrace
java.lang.IndexOutOfBoundsException: index can't be >= size: 14 >= 1
	at com.badlogic.gdx.utils.Queue.removeIndex(Queue.java:220)
	at com.badlogic.gdx.utils.Queue.removeValue(Queue.java:213)

Please select the affected platforms

[ ] Android
[ ] iOS (robovm)
[ ] iOS (MOE)
[ ] HTML/GWT
[ ] Windows
[X] Linux
[ ] MacOS

Confirmed issue on MacOS as well.

I believe that this is the expected result.  If you add two items to the queue and perform removeLast(), your left with only one item in the queue.  RemoveValue(2, false) would be removing an item that doesn't exist.

@slebed That is not the case. Printing the queue's contents before removal reveals that 2 is the only item in the queue.
After calling addFirst with 1 and 2, I get the queue [1 2]. Calling removeLast removes the tail, or 1.
Even if 2 wasn't in the queue, documentation states that @return true if value was found and removed, false otherwise. A crash should not occur in any scenario.

Closed by #5472.


Fix getDerivationPathFor

I suggest to also add "addressIndex" as an optional parameter for getDerivationPathFor, as i just ran into the problem not being able to get the correct derivation path for a Hardware-Wallet:  (addressIndex was "1", but the function assumes addressIndex is always "0")
Case:
chain: Chain.Bitcoin
index: 0
type: nativeSegwitMiddleAccount
Returns: .............. [84, 0, 0, 0, 0]
Desired Result: ... [84, 0, 0, 0, 1]

lgtm

@BlockJayn thanks! Will include update in next version 😅


How to select first value of options when focus is blurred or in on_detach method because i am getting here only the value not object of option ?

Hey @kritansh, I'm not sure I understand what ou are trying to do. Can you setup a fiddle / codepen / plunker with an example of you are trying to achevie?

Hi @hakib, Sorry for delay in replay, This is my plunker example https://plnkr.co/edit/uudMXk9f9ySM7FnsEO0H?p=preview, Please look in to on_detach method when

auto_select_first = true
Actually here i want to auto select first item of autocomplete option when selection is void and action is blurred. Could you suggest me how can i get object  just like in on_select function when option is selected into on_detach method so that i can fulfill my requirement. I looked into your code where you are only passing value to on_detach method.

Hey @kritansh,
In the on_detach hook you are getting the value of the model (not the object).

If you need the last selected value you can use the last value sent to on_select. In you plunker you got this at $scope.value.
If for some reason you need to rely on the value sent to on_detach you can search the suggestion list for the object with that value.

Hope this helps :)

thanks @hakib


does it work for parallel builds?

does it work for parallel builds?

Not really. You could probably write rules that spawned async processes, but I suspect it'd be hard to get it to operate sensibly.
Sorry! This project is more of a "proof of concept" than a mature product.


oapply errors when called on empty wiring diagram.

I think that this code should create a trivial OpenGraph.
using Catlab.CategoricalAlgebra, Catlab.Programs, Catlab.Graphs, Catlab.WiringDiagrams

const _, OpenGraph = OpenCSetTypes(Graph, :V)

wd = @relation () begin
end

oapply(wd, OpenGraph[])

Instead, it throws an error:
MethodError: no method matching colimit(::Type{Tuple{Any, Any}}, ::Catlab.CategoricalAlgebra.FreeDiagrams.BasicBipartiteFreeDiagram{Any, Any})

A classic genre of bug that tends to happen when Julia fails to propagate types through maps over empty lists.


chore(release): v1.3.3 🎉

:robot: I have created a release beep boop
1.3.3 (2024-06-26)
Bug Fixes

practs: upgrade to latest best (#13) (63a10cd)
tests: enable s3 cicd tests (#12) (6015abd)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ehmpathy/simple-on-disk-cache/releases/tag/v1.3.3 :sunflower:


unable connect to server

Samsung A34 5G
(SM-A346E/DSN)
Android v14
One UI v6.1
Frigoligo v1.2.0 (2035)

Hi, get “Invalid API response” when trying to get the app to connect to the nextcloud server.
I have tried both 'https://kim.nl.tab.digital' (the actual url of my server) and the short iteration 'kim.nl.tab.digital' to the same result seen below:

Are you sure about the address? I does not look like a wallabag server.


Provide old 0.21.0 version as noarch

Provide old 0.21.0 version as noarch, as packages like prefect 2 need an older version be available on many platforms. The griffe package was only made noarch beginning from version 0.22.0. This PR is targeting the main-0.21.0 branch (derived from current main branch) instead of the main branch, to not confuse the regro-bot, which proposes updates.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Works for me - a new branch is the way to go for updates like this 🔥


[security] Secure unix socket by checking peer credential on the server side

What does this PR do?
Secure unix socket by checking peer credential on the server side
Motivation
Checking the peer user/group is possible with unix socket
To avoid potential abuse and mistake (packaging issue, permissions errors)
Just to be on the safe side
Extra security could be added as we know the client pid (ucred.pid) and can check (ex: process name)
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

Changed milestone as the PR is not yet ready to be merged, and it does not seem critical to 7.45

note : reverting trace api unix socket credential check as it make no much sense

Does this PR make it so that we can run process events without elevated privileges?

The macos build is broken, please fix before merging

Can you add to the PR description qa-steps and to explain how the old sudo curl --unix /opt/datadog-agent/run/sysprobe.sock http://unix/network_tracer/debug/http_monitoring will work from now own?