extend the list of phase filters

At present this is what we have

I would prefer if we can specify
mitotic interphase and meiotic interphase instead of  'interphase'
mitotic G1 phase and meiotic G1 phase instead of  G1 phase
mitotic S phase and premeiotic S phase instead of   S phase
meiotic M phase  mitotic M phase instead of   S phase
and the same for prophase, metaphase, anaphase, telophase.
I'm hoping we always provide the specificity, but if not this needs to be fixed (It should always be possible to specify)
I guess the first question is have we ever used the none mitotic or meiotic terms in extensions?

I had a quick reccy and I don't think we use the parents at all in GO annotation. It is possible that we have used these in gene expression though (which use the same filters) so we would need to check both.
so the question is do we have any during
interphase
G1 phase
S phase
M phase
prophase
metaphase
anaphase
telophase.

I would prefer if we can specify

The menu might end up a bit long.  Is that OK?

premeiotic S phase

I can't find that term.  Should it be "meiotic S phase"?

so the question is do we have any "during" extensions using:
interphase GO:0051325
G1 phase GO:0051318
S phase GO:0051320
M phase GO:0000279
prophase GO:0051324
metaphase GO:0051323
anaphase GO:0051322
telophase GO:0051326

I can't see any annotation that have any during extensions using those terms.

I think it is OK that the menu is a bit long. It won't get any longer.... It might be useful to put the mitotic terms to the top as they are used the most (for most use cases most terms will be greyed out)

I get this list:

meiotic G1 phase
meiotic M phase
meiotic S phase
meiotic anaphase
meiotic interphase
meiotic metaphase
meiotic prophase
meiotic telophase
mitotic G1 phase
mitotic M phase
mitotic S phase
mitotic anaphase
mitotic interphase
mitotic metaphase
mitotic prophase
mitotic telophase

but I can't find these terms in GO:

meiotic metaphase
meiotic anaphase
meiotic telophase
meiotic prophase

GO has: "meiotic metaphase I", "meiotic metaphase II" etc.
Also: what order should they be in?  Currently it's alphabetical but maybe it should be something more biologically sensible?

yes sorry
GO:0007132    meiotic metaphase I
GO:0007137    meiotic metaphase II
GO:0007133    meiotic anaphase I
GO:0007138    meiotic anaphase II
GO:0007134    meiotic telophase I
GO:0007139    meiotic telophase II
GO:0007128    meiotic prophase I
GO:0007136    meiotic prophase II

Also add
mitotic G2 phase GO:0000085
the order should be:
mitotic interphase
mitotic G1 phase
mitotic S phase
mitotic G2 phase
mitotic M phase
mitotic prophase
mitotic metaphase
mitotic anaphase
mitotic telophase
~meiotic G1 phase~ https://github.com/geneontology/go-ontology/issues/22451
meiotic S phase
meiotic M phase
meiotic interphase
meiotic prophase I
meiotic metaphase I
meiotic anaphase I
meiotic telophase I
meiotic prophase II
meiotic metaphase II
meiotic anaphase II
meiotic telophase II

I think this list and this order is OK.
if it looks too long in the dropdown it would be useful to get a count of how many times each extension is used. That would allow me to decide if we should use some superclasses instead for the meiosis phases.

the order should be:
mitotic interphase
mitotic G1 phase
mitotic S phase
mitotic G2 phase

Is "mitotic interphase" needed?  It's a part_of parent of the next three in the list by the looks of it.
Same with meiotic interphase.

In kept the interphase and M phase grouping terms  in addition to the specific ones.
I suspect mitotic interphase and mitotic M phase will be the most popular options, but on some pages, like cdc2 you really need the more specific ones.

OK, thanks.  I've change the terms in the filter in time for the current load.
The load is running a bit late because I needed to restart it.  GitHub had an outage at an awkward moment during the load but it's back in action now.
It will be finished at 11am-ish.

The load is running a bit late because I needed to restart it.

And then it failed because I forgot to commit all the PECO to FYECO SVN changes.  I'll check on Monday morning.

I think is (mostly) worked: http://dev.pombase.kmr.nz/term/FYECO:0000268
There 94 fewer annotations then the previous successful load so I'm going to investigate that before updating the main site.

The filters are updated on the main site.  Could you have a look are see if it looks OK?
I update GO and the gene expression section filters.  Does that make sense?

I updated GO and the gene expression section filters. Does that make sense?

That makes sense.
The menu length is fine too.
It seems to be working for MF and BP but not CC (I tried on the cdc2 page)

It seems to be working for MF and BP but not CC

Whoops!  The filtering was tripping over the "at origin_of_replication" extension on one of the CC annotations.  I've fixed it so that correctly ignores extensions that aren't "during" extensions.
It should be working in the morning.

Oh one other thing that I ommitted to mention. This filter should be ontology aware. So a filter on mitotic M-phase should retrieve
mitotic M-phase,  mitotic metaphase, mitotic anaphase, etc
and a search on mitotic interphase should retrieve mitotic G1 phase/mitotic G2 phase/mitotic Sphase.
This is quite important because  a lot of changes are really about the switch between interphase and M-phase, but are observed at the sub-phases.
I think this could be really useful.

This filter should be ontology aware.

It should be doing that already.  If it's not can you give me an example?

It does seem to be working. I don't know what I was doing wrong.

Reopening temporarily. Kim could you add a news item (edited if necessary)? I will announce to list (or you can!)
News
We have migrated the Gene Ontology annotation filter for 'during’ a specific cell cycle phase from the   “Summary”  view to the “Details” view to make it more visible. We have also added additional phases to cover all annotation, and added some useful grouping terms. This filter is  ‘ontology aware’ (so a search on interphase will also display G1/S/G2 phase annotation). This filter is very useful on pages like cdc2 that display increasing volume of phase-specific curation.
The revised phase filter options are also available in/on? the gene expression section.

I've added a news item about this.  I haven't sent a message to the mailing list.

Announce p-list


Add ability to set the tooltip text of a TreeItem button

Closes: godotengine/godot-proposals#7104

Thanks!


[BANDWIDTH_THROTTLING] Update Chargeable interface to align it with QuotaChargeCallback and updated QuotaManager behavior.

And just a thought: we are only using QuotaChargeCallback because we need RestRequest object and we only expecting 1: Account 2 Container 3 Method from RestRequest. It seems like we can. easily get these three pieces of information from router. We have blob id passed to every operations so we can get account id and container id thus we can get Account and Container and in each operation we know the method, GetBlobOperation means it's QuoteMethod.Read, PutOperation means it's QuotaMethod.Write. In this way, we can probably get rid of QuotaChargeCallback so the code becomes more clear.


svtplay-dl: 4.28.1 -> 4.69

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/svtplay-dl/versions.
meta.description for svtplay-dl is: Command-line tool to download videos from svtplay.se and other sites
meta.homepage for svtplay-dl is: https://github.com/spaam/svtplay-dl
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.69 in filename of file in /nix/store/24aq8yvsygawak1ac44fb821nmd732b9-svtplay-dl-4.69

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
svtplay-dl

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/24aq8yvsygawak1ac44fb821nmd732b9-svtplay-dl-4.69 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A svtplay-dl https://github.com/r-ryantm/nixpkgs/archive/1f543dc893b79aa292e40a4d85cf2c0c08d134e7.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1f543dc893b79aa292e40a4d85cf2c0c08d134e7#svtplay-dl

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/24aq8yvsygawak1ac44fb821nmd732b9-svtplay-dl-4.69
ls -la /nix/store/24aq8yvsygawak1ac44fb821nmd732b9-svtplay-dl-4.69/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

svtplay-dl

Maintainer pings

Already on staging-next.


Include of non modular header

I am trying to use the library via cocoa pods,
pod  'AZSClient'
ran pod install and everything went well
but when I try to use it in the project
import AZSClient
Project doesn't build

I am using in a swift project
Any help much appreciated

I have exactly the same problem, any progress on this?

I cleared Header Search Path in the Pods project build settings. That got rid og this error, but now I have another one. 'libxml/xmlwriter.h' file not found. Thought I'd post this in case it would help you along...

I found that this was due to the #include <asl.h> at the top of AZSOperationContext.h but still looking for a solution to the problem.

Ok, well I have succeeded in using this framework, but dropped the pod. Just downloaded the sourcecode and compiled it, included it to the project and made a bridging-header. Works like a charm, but then updating it later may become a more manual job. I simply did not have time to make this pod system work.

@vineethvijayan @Ruthberg @damienpontifex
Really sorry for the late reply!
If you are still encountering this issue, I think that it might be because you are using the "use_frameworks!" option with Xcode 7. I've tested the latest version 0.2.3 with "use_frameworks!" in Xcode 8, and it works fine. To avoid this problem, you could either switch to Xcode 8, or drop the "use_frameworks!" option and create a bridging header instead (please refer to Readme for instructions).
Please reopen this issue if you're still seeing this problem.


Fixed On-Paste Title CSS

Issue that this pull request solves
Closes: #470
Proposed changes
Added an 'onpaste' event on the id 'cb-title' element and then retrieving on the plain text part from the copied clipboard text and then executing command 'insertText' to paste the text in the element.
Types of changes
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Put an x in the boxes that apply

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] My changes does not break the current system and it passes all the current test cases.

Screenshots
https://user-images.githubusercontent.com/71957423/147415284-7479a826-4720-479d-a3b0-0ed9ab094c53.mp4

@goliakshay357 I have made the changes.

LGTM!
Thanks for the enhancement, @Aniket-508!


How can I allow users to click on the active option in version 4+?

I asked this question on Stack Overflow at the end of last month: Handle select2:select event on active option. Unfortunately there has been very little attention to it and I've still not got an answer.
I'm basically wanting to let users click repeatedly on the same option. Select2 doesn't re-trigger the select2:select or select2:selecting events if the option clicked is the currently active one.
Is there anything I can do to enable this behaviour?

Discussion of this issue is now focused in #4472.


draft-ietf-6man-pio-pflag-11 File Error

Describe the issue
Version 11 of the draft was uploaded this morning (08:30 UTC) but cannot be accessed.
Error message: "Error; cannot read 'draft-ietf-6man-pio-pflag-11.txt'"
HTML version also inaccessible and the compare tool fails for  similar reason.

Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

Thank you for reporting this, I came to file exactly this issue...
Providing we (the authors) are waiting for the IESG approval for the draft publication, the timing is very unfortunate...

BTW at least two other drafts have been submitted after  draft-ietf-6man-pio-pflag-11  (one individual doc and one WG doc):
https://datatracker.ietf.org/doc/recent
Both are OK, so it seems to be smth wrong with draft-ietf-6man-pio-pflag-11 (though https://author-tools.ietf.org/ renders that document into HTML just fine)

Thanks for the report. This is fixed and the underlying issue tracked in #8016.

Just so it's clear, there was no problem with the submitted files. They rendered correctly but were not moved into place. Sorry for the inconvenience.


Updated Subdomain List

Added loads more sub domains to review

Hi there, thanks for the PR. I think I will stick to the current wordlist as I feel it has a good balance between coverage and not taking ages to go through. I will however look into implementing an option to aquatone-discover to specify other wordlists than the built-in one.

version 0.4.0 now supports giving a custom wordlist.


ui: Adding success message for DomainActionForm

How Has This Been Tested?

Description
Fixes https://github.com/apache/cloudstack/issues/4984#event-4674704031
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

Screenshots (if appropriate):

@blueorangutan ui

@davidjumani a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

UI build: :heavy_check_mark:
Live QA URL: http://qa.cloudstack.cloud:8080/client/pr/4987 (SL-JID-121)


Inconsistent behavior between vmap and pmap keeping track of axes inside of scan

out_axes behaves differently in pmap vs vmap inside of a scan:
The following snippet
import jax
from jax import lax
import jax.numpy as jnp

def f(x):
  def body(carry, _):
    return lax.psum(carry, 'i'), None
  return lax.scan(body, x, xs=None, length=5)

jax.vmap(f, out_axes=None, axis_name='i')(jnp.ones(8))

results in:
ValueError: vmap has mapped output but out_axes is None

On the other hand, it works with jax.pmap.
In offline discussion, @mattjj suggested that the scan should throw a type check error because its input is mapped but output is unmapped. We would then need pbroadcast to get a mapped value out of the scan.

This difference results from:

vmap propagates mapping using the batching rules; for scan, that involves a fixed point that forces the carry to have the same batching status in the inputs and outputs
pmap doesn't actually propagate mapping at all: everything inside the pmap is assumed by most parts of the system to be mapped, while everything can be treated (unsafely) as unmapped using out_axes=None

Adopting avals-with-names without other changes will actually cause pmap to behave like vmap here (the mapping propagation logic/fixed point will move from batch of scan to partial/abstract eval of scan, and will get invoked during pmap tracing).
What you're asking for is essentially a separate change (an optimization) for mapping propagation in scan/loops, that would allow the batching status of the carry to be unmapped (if it's produced by a collective like psum) even if the init is mapped (and only if the loop is known to have length > 0). I think that change might be worth it if we can find a more compelling example—your example here should just start with an unmapped init.


⚠ Avatar API Endpoint has degraded performance

In e79f975, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 1137 ms

Resolved: Avatar API Endpoint performance has improved in d17900b after 9 minutes.


Add snippet to change column flow

Your idea:
The following snippet of code is often used to change the way elements flow within columns in user's brews - commonly due to their browser not supporting column flow in the same way or extent that Chrome does (e.g. Firefox).
Adding this snippet would allow us to redirect users having these issues to an "trusted and official" Style snippet, rather than "copy and paste this code into your document" which should only carry all the trust one would normally associate with talking to a stranger over the Internet.
.page .columnWrapper {
  column-fill: auto;
 }

Is there any way we could just build in the correct behavior so Firefox users don't need this in the first place?

@-moz-document url-prefix() { [...] } is apparently a universal Mozilla detector media query, so we could change add the following to the default page styling:
@-moz-document url-prefix() {
    .page .columnWrapper {
        column-fill: auto;
    }
}


HDDS-3689. Add various profiles to MiniOzoneChaosCluster to run different modes.

What changes were proposed in this pull request?
This change add datanode, OM and a mix of both as a chaos mode. The chaos tests have helped in finding multiple issues in Ozone.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-3689
How was this patch tested?
Ran MiniOzoneChaosCluster.

/pending on green build + small description fix

/ready

@elek I have addressed the comment in the lastest patch, please have a look.

Merged, thanks the patch @mukul1987


Typecheck multiple module formats at once

(The other side of #15833)
Search Terms
typecheck multiple module formats
Suggestion
For projects that compile to multiple output formats - e.g. different module outputs - it would be useful to have typechecking able to emit errors for multiple formats at once.
The reason that duplicate typechecking is needed is that typechecking is slightly different based on the module - e.g. for commonjs / AMD, export = and import foo = require(...) are both legal, whereas in ESNext they are not; ESNext has import.meta and in some cases, top level await, that AMD/Commonjs don't support.  So no single module target has the strictest typechecking.
The benefits are:

save CPU time
no need for running typecheck multiple times and get most errors duplicated between them

On it's own, I'm not sure it'll make a ton of sense - e.g. in compilerOptions the module field could take an array of modules, or we could use a new field for this; though together with emit for multiple module types (#15833) we could keep the invariant that tsc typechecks with the same module(s) that it emits.
Use Cases
If I compile my code to both AMD and ESNext, typechecking only as AMD or only as ESNext, does not guarantee my code is valid for the other module format - an export = will fail ESNext typechecking, whereas an import.meta will fail AMD typechecking; so there's no single strictest typecheck mode; as is to guarantee correctness, I need to typecheck against all the module formats we emit, and then any type errors in e.g. function bodies would get repeated in both typechecks.  Deduping these errors would be the main benefit.

Following up on my comment here and given the following configuration:
{
  "compilerOptions": {
    "outDir": "./dist",
    "emit": [
      { "module": "CommonJS", "declaration": true },
      { "module": "ESNext", "extension": "mjs" },
    ]
  }
}

One could theoretically run tsc --noEmit and the TS compiler would still have to use the emit compiler option to see which types to check.
I think that makes a lot of sense.

Visiting this issue from the tweet
In AWS SDK for JavaScript (v3), we have three targets right now: commonjs (for Node.js), es5 (for browsers) and types (for TypeScript users).
We're planning to add three more targets: esm (for Node.js ESM), modern-web (for modern browsers) and debug (contains sourcemaps for debugging).
As per current setup, we'll have to write six different TSConfigs and run typescript with each of those configs.
If the emit option is provided, we'll be able to emit all artifacts with single TSConfig.


matcher.bind does not work inside of repeat with checkboxes

I'm submitting a bug report

Library Version:
1.12.0

Please tell us about your environment:

Operating System:
Windows 10

Node Version:
10.16.0

NPM Version:
3.8.9

JSPM OR Webpack AND Version
webpack 4.39.3

Browser:
Chrome

Language:
TypeScript 3.6.2

Current behavior:
The matcher does not work inside of repeat.for when using checkboxes and arrays of objects.
The example below (from the Aurelia docs) does work, as the matcher gets called, but it doesn't use repeat.for.
https://aurelia.io/docs/binding/checkboxes#array-of-objects-with-matcher
If you remove the three checkboxes in the example above, and replace them with a repeat.for, the matcher no longer gets called.
Expected/desired behavior:
Demo: https://codesandbox.io/s/objects-s7lec?fontsize=14&module=%2Fsrc%2Fapp.ts
The call to console.log() in the above demo shows that the matcher never gets called. Also,ticking the checkboxes results in duplicates being added to the selected list.

What is the expected behavior?
The matcher works inside of repeat when using checkboxes and arrays of objects.

I think Codesandbox has some issues with dependencies, as you can see from this example: https://codesandbox.io/s/httpsgithubcomaureliatemplating-resourcesissues388-ftszo
It comes with latest version of templating-resources, and is working fine.
Can you make sure your project has latest version of this module and try again?

As you said, it does now work in Codesandbox, but I cannot get it to work on my machine. I have created a brand new Aurelia project using the latest aurelia-cli and then updated to the latest version of this module:
npm install aurelia-templating-resources@latest

It does not work though. The matcher never gets called. Is there another Aurelia library that also needs to be updated for this to work? Can you try creating a new Aurelia project to see if you get the same behaviour?
Thanks.

@pkozul Sorry for the false information. Can you try the following:
import {Repeat} from 'aurelia-templating-resources';

Repeat.useInnerMatcher = false;

The reason is without static field useInnerMatcher, it would have been a breaking changes. So we made it an opt-in fix.

@bigopon Yes, that did the trick! Now works. Thank you.
I see it's documented in the Aurelia docs, but I would never have found it myself :-)
https://aurelia.io/docs/api/templating-resources/class/Repeat/property/useInnerMatcher/


Fix database config

Fixes Issue
Closes #1607
Changes proposed
I have updated the url and resources to correct values in data.ts which were causing issue previously.
Screenshots

Note to reviewers

Hi @Anmol-Baranwal previously the value for url was /youtube-testing and for  resources it was DB.youtubeTesting, which was causing the issue.

@shreedhar37
Change the value to something more unique. Because we already have a similar name testing for backend. You can check here.

Ahh totally missed that @Anmol-Baranwal. Thanks for bringing that up. But I am confused now, there are some values inside databases/youtube/testing.json which are already present inside databases/backend/testing.json. Should I keep only unique values or is it okay to have the same values in both files ?

Ahh totally missed that @Anmol-Baranwal. Thanks for bringing that up. But I am confused now, there are some values inside databases/youtube/testing.json which are already present inside databases/backend/testing.json. Should I keep only unique values or is it okay to have the same values in both files ?

No worries, I will let you know soon.
Please don't make any new changes, until we are sure what to do.

Thanks @Anmol-Baranwal @rupali-codes @CBID2  this is my first open source contribution in life.

Thanks @Anmol-Baranwal @rupali-codes @CBID2 this is my first open source contribution in life.

Nice :)
Wishing you the best on your open-source journey.

Thanks @Anmol-Baranwal @rupali-codes @CBID2 this is my first open source contribution in life.
glad to know.
Happy open-sourceing!!!


Builds fail with setuptools > 66

We use a template in our build system to fill the version based on the tag:
https://github.com/AllSpiceIO/py-allspice/blob/main/setup.py#L8
Since we don't render the template when installing (e.g. with pip install --editable .), setuptools throws an exception because of https://github.com/pypa/setuptools/issues/2497. This means that e.g. during the dev workflow we have to change the version to a valid PEP440 version and change it back to the template when we're pushing a new release.

The template in setup.py was removed in #73. Can this be closed?

Yep


How is the neighbor hood limit calculated

Hi @HuguesTHOMAS ,
Hope you are doing great.
I am trying to create DALES dataset with KPConv. I completed training and testing with the same model as in S3DIS and I am trying to run testing on some added modules to the model. These added modules works well with ModelNet40 without any errors, also training and validation works well, only testing is giving me error.
I do not think that this change should affect the neighborhood limit, but it does, for some reason I am getting the following output
Check batch limit dictionary
"potentials_15.000_0.250_2": 18901
Check neighbors limit dictionary
"0.250_0.625": 25
"0.500_1.250": 37
"1.000_5.000": 0
"2.000_10.000": 213
"4.000_20.000": 118

You can see that the 3rd line "1.000_5.000": 0 , is giving me zero and this creates error for me.
Can you explain how the neighborhood limit is calculated in the calibration function and also if possible let me know what's going wrong.
Interestingly, when I run in windows I get the following:
"0.250_0.625": 24
"0.500_1.250": 38
"1.000_5.000": 304
"2.000_10.000": 232
"4.000_20.000": 89

which is weird (I will check the files differences. but I do not think its so)
Thanks,
Arjun.

In the dataset class file, we define the sampler calibration function. In this function we compute a histogram of the number of neighbor for each layer here:
https://github.com/HuguesTHOMAS/KPConv-PyTorch/blob/94b1d87e17ec339e2aad049ce5d5d175b9cd0db1/datasets/ModelNet40.py#L570-L580
The batches are computed by looping the dataloader, exactly like when a network is trained, and we save. USe the verbose option of the calibration function to see the computed neighborhood histograms for each layer and the limits chosen.

Hi @HuguesTHOMAS,
thanks a lot for your code, it gives an impressive result of analysis of ALS point clouds. I have a question regarding the calibration procedure which was mentioned in this issue: do you know if it's possible to find somewhere a description of this converging process? Does this algorithm have any specific name? I'd like to find a better understanding of what parameters like Kp, low_pass_T and target_b are)
Best regards
Dmitry

It is basically a simple low-pass filter. This is a commonly used filter in signal processing. You can see it as a similar thing to moving-averages.


[Bug]: Constant reconnecting - mail spam from panasonic

The problem

Hey, I've already received a thousand emails from Panasonic. That thanks for connecting. A few emails per minute.
I understand that this is a problem on our side and there are many reconnections every few seconds?
What version of Home Assistant Core are you running?
latest
What type of installation are you running?
Home Assistant Container
What version of the integration are you running?
latest
Device description
heat pump, one zone
Is the integration loading?
Yes
Is the adapter able to connect to the Aquarea Smart Cloud with a stable internet connection?
Yes
Are you able to perform the action you're trying to with the Aquarea Smart Cloud Site/App?
Yes
Area of the issue
No response
Anything in the logs?
No response
Additional information
No response

Im facing the same issue. It started around 2h ago.

Same here, tried upgrade of the integration (was still at 0.70, reset the app and now not able to authenticate with Panasonic.

I have the same, I enter the correct password in HA and I get the information - unknown error.

Same here

same problem here.
Panasonic changed again the authentification ?

same problem

In my case, after 256 emails :P''' and the automation inexplicably stopped working, I entered the link and authenticated. Magically it has come back to life. Panasonic has made the mistake of touching something that works, it seems. (this is the first degree in computer science)

Same here, I deactivated the integration to stop reciving emails. I loged in with my computer, reactivated the integration and it's working again... I'm thinking to migrate to heishamon to avoid all this random problems.

Logging in at aquarea-smart.panasonic.com actually resolved the issue for me, too.

Maybe we shouldnt make something out of nothing here guys? Just as @jaypikay stated above the problem is solved by login to aquarea-smart.panasonic.com and accepting the new user agreement.
Until further notice I would suggest that this issue is considered solved with the above solution.

It looks Panasonic was having a problem, I did login on the website earlier today, and this did not fix it.
Now it works again, so this issue can be closed!

for me it's working too now. Email spam continues, but luckily not at that very high rate..

Thanks everyone for the reports. It looked indeed an issue on the Aquarea platform/Panasonic Auth Service.


Investigate changes and support for Visual Studio Docker tooling

We integrate with publish well, but the story for inner-loop development (especially f5 debugging) probably needs some improvement. We should interface with the team and determine what they need from us in order to integrate.

Closing as our partner team has launched their support for our tech!

Do you have details like link to relevant issues or documentation about what will be/is supported here?

VS Code supports building and running (with debugging) inside a container using our tech just by pressing F5 - you can read more about that in this blog post. VS is on track to implement the same.

I am looking more precisely for VS, especially if there is anything possible while keeping their support for docker-compose too


Recursive cloning

I'm receiving a 'permission denied' error from github when checking out pixSfM with the public key:
git clone https://github.com/cvg/pixel-perfect-sfm --recursive
Cloning without the --recursive switch executes fine. The shell output is below:
Cloning into 'pixel-perfect-sfm'...
remote: Enumerating objects: 258, done.
remote: Counting objects: 100% (258/258), done.
remote: Compressing objects: 100% (212/212), done.
remote: Total 258 (delta 44), reused 245 (delta 39), pack-reused 0
Receiving objects: 100% (258/258), 9.13 MiB | 1.30 MiB/s, done.
Resolving deltas: 100% (44/44), done.
Submodule 'third-party/HighFive' (git@github.com:Phil26AT/HighFive.git) registered for path 'third-party/HighFive'
Submodule 'third-party/pybind11' (git@github.com:pybind/pybind11.git) registered for path 'third-party/pybind11'
Cloning into '/home/kevin/pixel-perfect-sfm/third-party/HighFive'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@github.com:Phil26AT/HighFive.git' into submodule path '/home/kevin/pixel-perfect-sfm/third-party/HighFive' failed
Failed to clone 'third-party/HighFive'. Retry scheduled
Cloning into '/home/kevin/pixel-perfect-sfm/third-party/pybind11'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@github.com:pybind/pybind11.git' into submodule path '/home/kevin/pixel-perfect-sfm/third-party/pybind11' failed
Failed to clone 'third-party/pybind11'. Retry scheduled
Cloning into '/home/kevin/pixel-perfect-sfm/third-party/HighFive'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@github.com:Phil26AT/HighFive.git' into submodule path '/home/kevin/pixel-perfect-sfm/third-party/HighFive' failed
Failed to clone 'third-party/HighFive' a second time, aborting

I regenerated my ssh key associated with my gitHub account, and was able to check out the submodule paths recursively using the above line.

Hi @KevinCain, thanks for bringing this up. PR https://github.com/cvg/pixel-perfect-sfm/pull/6 should fix the issue.


cloud-hypervisor: 0.14.1 -> 15.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/cloud-hypervisor/cloud-hypervisor/releases.
meta.description for cloud-hypervisor is: "Open source Virtual Machine Monitor (VMM) that runs on top of KVM"
meta.homepage for cloud-hypervisor is: "https://github.com/cloud-hypervisor/cloud-hypervisor"
meta.changelog for cloud-hypervisor is: "https://github.com/cloud-hypervisor/cloud-hypervisor/releases/tag/v15.0"
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0/bin/ch-remote passed the binary check.

/nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0/bin/cloud-hypervisor passed the binary check.

2 of 2 passed binary check by having a zero exit code.

0 of 2 passed binary check by having the new version present in output.

found 15.0 with grep in /nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0

found 15.0 in filename of file in /nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0

directory tree listing: https://gist.github.com/4b70b9ed545b18584d31f066d4560109

du listing: https://gist.github.com/7aa915a26d5871a1b4c37328ff2e0e11

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
cloud-hypervisor

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A cloud-hypervisor https://github.com/r-ryantm/nixpkgs/archive/16603a1d98d9d79c6648db9a2ea9038485257940.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0
ls -la /nix/store/am82k1mnv8wjg1rsrqsyzfr8psblk32i-cloud-hypervisor-15.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

cloud-hypervisor

Maintainer pings
cc @offlinehacker @alyssais for testing.

Whoops, I didn't notice this when I opened #121348.


Flutter web integration tests fail after the "All tests passed!" message is received

I was noticing some strange behavior with flutter web integration tests where the test failed even though the logs show that "All tests passed". Example log output is in this comment on this PR: https://github.com/flutter/devtools/pull/5919#discussion_r1230247126. This seems like it might be a bug in the test runner.

For more details, see https://github.com/flutter/flutter/issues/150358

Steps to reproduce this issue can be found here: https://github.com/flutter/flutter/issues/146763

In my experience, this occurs whenever a setup step results in an exception

Steps to reproduce

Create new flutter app: flutter create e2e_test_ex
Set up integration tests to run on web following the docs here (https://docs.flutter.dev/testing/integration-tests#running-in-a-browser) and add a setup step that will throw an exception along with a test that will fail.
a. mkdir integration_test test_driver
b. touch integration_test/main_test.dart test_driver/integration_test.dart
c. Open integration_test/main_test.dart and test_driver/integration_test.dart and add the following code snippets

// test_driver/integration_test.dart
import 'package:integration_test/integration_test_driver.dart';

Future<void> main() => integrationDriver();

import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';

void main() {
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();

  group('e2e', () {
    setUpAll(() {
      throw Exception('fail');
    });
    testWidgets('should fail', (_) async {
      expect(true, isFalse);
    });

    testWidgets('should pass', (_) async {
      expect(true, true);
    });
  });
}

Run the tests following the instructions from the previously mentioned docs:

flutter drive \
   --driver=test_driver/integration_test.dart \
   --target=integration_test/main_test.dart \
   -d web-server

    Open the debug session in a browser and open the browser's console
    Observe that the browsers console shows that the test fails The output will look similar to the output below.

00:00 +0: should fail

00:10 +0: should fail [E]
  Expected: false
    Actual: <true>

    Observe that the output in the terminal indicates that all the tests pass.

All tests passed.
Application finished.

Expected results
If an integration test fails, the test output in the terminal should indicate that a test failed.
Actual results
When a setup step throws an exception and an integration test fails, the test output in the terminal indicates that all tests have passed.


merge this code to support blade template

Hi, there is hack which adds the support for Laravel's blade template, it works good but the hack need to edit js-beautify source code.
Check this out:
https://gist.github.com/mpryvkin/0c46e2493b450f92492e8e9a46ad5d97

Moving to #845

Moving to #845

Moving to #845

Closing

moved to #845


Properties missing?

For some reasons I'm not able to find the property "copyright license"

I thought that this one should appear:
https://www.wikidata.org/wiki/Property:P275
Am I doing something wrong?

I cannot also find P27 "country", not even ordering by ID

Is there a problem with every property that starts with "27"? :thinking: lol

Try the right property identifier?  P17 and not P27 ?  Do feel bad, we all do it sometimes. :-)

Cannot reproduce 🤔 lol


linkifiers pattern URL should not be required to end in substitution

From this conversation: https://chat.zulip.org/#narrow/stream/9-issues/topic/linkification.20invalid.20URL.20format.20string
Currently, linkifiers must end in a substitution. Attempting to save a linkifier that has a pattern that ends in a string (e.g. https://server.example.com/%(id)s/detail/) results in an error message Failed: Invalid URL format string.
Note that you can insert strings into other parts of the URL -- see "Generic GitHub" example
Linkifiers should be allowed to end in a string.

Cannot be reproduced on master, it appears to have been resolved in dc2aa031f6566f897c94accd9ff4fc4f6c5d4ca6 and 0f2d7a354f85ffd88db86d3a285509d1632806e3.

Great, I'd thought we'd fix this class of issue :)


releaseChannel Not working in Eas build

Build/Submit details page URL
https://expo.dev/accounts/playmore/builds/5e759b6f-133b-4633-b95f-e4c8f2f76e55
Summary
releaseChannel Not working in Eas build
Managed or bare?
Managed
Environment
{
"build": {
"prod": {
"releaseChannel": "1.1.0"
},
"production": {}
}
}
Error output
releaseChannel Not working in Eas build
Reproducible demo or steps to reproduce from a blank project
releaseChannel Not working in Eas build

you specified releaseChannel in prod profile, but build you linked is on production profile


HF Transformers Weights

Hey @akashmjn!
Firstly, thank you for creating such an awesome project for the Whisper community! Very excited to try out these checkpoints.
I understand from your README that you used HF Transformers + Datasets to fine-tune the model? It would be super cool to push the resulting HF checkpoints to the Hub, such that all HF users can call your fine-tuned checkpoint using .from_pretrained.
This can be done directly from the model repository (which is a standard Git repo):
git add . && git commit -m "Add weights and training results" && git push

Or, you can do it Pythonically using the huggingface_hub package (installed with Transformers): https://huggingface.co/docs/huggingface_hub/guides/upload
Note that we're already getting feature requests for these checkpoints in Transformers (see issue), so there's demand from the community!

Hey @sanchit-gandhi - thanks for reaching out! Ack - will look into this later in the week.
Meanwhile, worth calling out that you'll also need small edits to inference code so that the extra token is not suppressed.
For an example, see https://github.com/akashmjn/tinydiarize/pull/4 https://github.com/akashmjn/tinydiarize/pull/11 (edits on this python repo) or https://github.com/ggerganov/whisper.cpp/pull/1058 (for what was done in cpp)

For the first PR #4 - I think it'll be possible to do something similar in HF transformers without any code changes by simply updating the EOS token to be the speaker turn token (model.generation_config.eos_token=...). For the second PR #11, this might require some more involvement to make sure it works with the transformers batching algorithm, however I think first we can try simply updating the EOS token and running generation to see what the quality is like.

Hi @sanchit-gandhi!
Sorry about the silence here. I just posted a project update on https://github.com/akashmjn/tinydiarize/issues/14 that I want to make sure I brought to your attention.
While releasing Transformers weights is conceptually equal to what's already released, given the wider public use TBH I'm playing it safe here for now 😅 . Feel free to DM me (@ akashmjn) or email if you'd like to discuss further.
Great job with Distil-Whisper!  (given that, pretty sure you should be able to replicate this too 😉 )

Hey @akashmjn - sorry to hear about the complications with open-sourcing more artefacts. We'd love to facilitate this project and more open-sourcing of checkpoints + code when possible (as @Vaibhavs10 suggested we can provide some compute if required). It's awesome to see what you've built so far here and I hope you can continue contributing!


Add example configuration for k3s and rke2 to download the sysext files and place them properly

Thanks, maybe a note that sysupdate is not use in the snippet, i.e., no updates - which I think makes even sense because updating the kubelet doesn't work without manual hand-holding across major versions.

Thanks, maybe add a note that sysupdate is not used in the snippet, i.e., no updates - which I think makes even sense because updating the kubelet doesn't work without manual hand-holding across major versions.

Done.


[HANDS-ON BUG] Unit 3 error while running "virtual_display = Display(visible=0, size=(1400, 900))"

Describe the bug
A clear and concise description of what the bug is.
Please share your notebook link so that we can reproduce the error
virtual_display = Display(visible=0, size=(1400, 900))
================================
An error below occurred while running script above

FileNotFoundError                         Traceback (most recent call last)
 in <cell line: 4>()
2 from pyvirtualdisplay import Display
3
----> 4 virtual_display = Display(visible=0, size=(1400, 900))
5 virtual_display.start()
5 frames
/usr/lib/python3.10/subprocess.py in _execute_child(self, args, executable, preexec_fn, close_fds, pass_fds, cwd, env, startupinfo, creationflags, shell, p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite, restore_signals, gid, gids, uid, umask, start_new_session)
1861                     if errno_num != 0:
1862                         err_msg = os.strerror(errno_num)
-> 1863                     raise child_exception_type(errno_num, err_msg, err_filename)
1864                 raise child_exception_type(err_msg)
1865
FileNotFoundError: [Errno 2] No such file or directory: 'Xvfb'
Material

Did you use Google Colab? yes, unit 3

If not:

Your Operating system (OS)
Version of your OS

I was experiencing this issue as well. It looks to be an issue with repo and collab updates.
I found this post helped as a temporary work around (https://github.com/tensorflow/agents/issues/314):
updating apt with !sudo apt-get update before installing xvfb and python-opengl

Yes unfortunately that's a usual bug with Xvfb in colab. The solution provided by @ztchir is one of the solution for now.


feat: reject conditions in models and tuples

Description
For the upcoming v1.3.8 release we want to push ABAC code but without official support for ABAC for this specific release. OpenFGA should continue to operate as it always has, but it will be with the ABAC code changes in place.
The v1.3.8 release will not allow ABAC models or tuples, but it will contain the ABAC code. The purpose of this ticket is to add the code changes to enforce  behavior.
< HTTP/1.1 404 Not Found
< Content-Type: application/json
< Openfga-Store-Id: 01HG8S8A7PXD6Q8NF15DR0S7T6
< Vary: Origin
< X-Request-Id: c403158f-32b1-41eb-996f-916ee2fe4ceb
< Date: Mon, 27 Nov 2023 16:31:12 GMT
< Content-Length: 62
<
{"code":"unimplemented","message":"conditions not supported"}

References
https://github.com/openfga/openfga/pull/1038
Review Checklist

[ ] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[ ] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Can you post a cURL command showing how the error looks from a client perspective? I'm interested in the HTTP status code

@miparnisari its a 404
< HTTP/1.1 404 Not Found
< Content-Type: application/json
< Openfga-Store-Id: 01HG8S8A7PXD6Q8NF15DR0S7T6
< Vary: Origin
< X-Request-Id: c403158f-32b1-41eb-996f-916ee2fe4ceb
< Date: Mon, 27 Nov 2023 16:31:12 GMT
< Content-Length: 62
<
{"code":"unimplemented","message":"conditions not supported"}


Client lighting values and rendering occasionally bug out.

First noticed this in Forge, but replicated both in Forge and Fabric. Essentially, stuff like this happens occasionally:

Please note the Client light level as compared to the Server light level. Especially when walking in light in this video:
https://youtu.be/g7BwniLR1Dk
Despite standing in visibly lit areas, client light level is still listed as 0, as well as listed as 0 in the buggily-lit areas.
This is in a 'clean' instance with just Minecraft 1.16.4, Fabric API 0.28.4 (I was told by Minecraft Player on Discord to not use anything higher than this), Immersive Portals v0.60 for Fabric, and REI.
-- System Details --
Details:
	Minecraft Version: 1.16.4
	Minecraft Version ID: 1.16.4
	Operating System: Windows 10 (amd64) version 10.0
	Java Version: 14.0.2, AdoptOpenJDK
	Java VM Version: OpenJDK 64-Bit Server VM (mixed mode, sharing), AdoptOpenJDK
	Memory:<PHONE_NUMBER> bytes (4521 MB) /<PHONE_NUMBER> bytes (6144 MB) up to<PHONE_NUMBER> bytes (6144 MB)
	CPUs: 8
	JVM Flags: 10 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx6144m -Xms6144m -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M
	Fabric Mods:
		autoconfig1u: Auto Config v1 Updated 3.3.1
		cloth-basic-math: Cloth Basic Math 0.5.1
		cloth-client-events-v0: Cloth Client Events v0 1.4.5
		cloth-config2: Cloth Config v4 4.8.3
		fabric: Fabric API 0.28.4+1.16
		fabric-api-base: Fabric API Base 0.2.0+ab87788d3a
		fabric-biome-api-v1: Fabric Biome API (v1) 3.1.0+2e23b97c3a
		fabric-blockrenderlayer-v1: Fabric BlockRenderLayer Registration (v1) 1.1.4+6a2618f53a
		fabric-command-api-v1: Fabric Command API (v1) 1.0.9+6a2618f53a
		fabric-commands-v0: Fabric Commands (v0) 0.2.0+6a2618f53a
		fabric-containers-v0: Fabric Containers (v0) 0.1.9+a03e98793a
		fabric-content-registries-v0: Fabric Content Registries (v0) 0.2.0+e77439c73a
		fabric-crash-report-info-v1: Fabric Crash Report Info (v1) 0.1.2+b7f9825d3a
		fabric-dimensions-v1: fabric-dimensions-v1 2.0.1+9a6c75813a
		fabric-events-interaction-v0: Fabric Events Interaction (v0) 0.4.1+6a2618f53a
		fabric-events-lifecycle-v0: Fabric Events Lifecycle (v0) 0.2.0+6a2618f53a
		fabric-game-rule-api-v1: Fabric Game Rule API (v1) 1.0.3+a4467d2a3a
		fabric-item-api-v1: Fabric Item API (v1) 1.2.0+6a2618f53a
		fabric-item-groups-v0: Fabric Item Groups (v0) 0.2.1+6a2618f53a
		fabric-key-binding-api-v1: Fabric Key Binding API (v1) 1.0.1+730711c63a
		fabric-keybindings-v0: Fabric Key Bindings (v0) 0.2.0+6a2618f53a
		fabric-lifecycle-events-v1: Fabric Lifecycle Events (v1) 1.2.0+ffb68a873a
		fabric-loot-tables-v1: Fabric Loot Tables (v1) 1.0.1+6a2618f53a
		fabric-mining-levels-v0: Fabric Mining Levels (v0) 0.1.2+6a2618f53a
		fabric-models-v0: Fabric Models (v0) 0.1.1+6a2618f53a
		fabric-networking-api-v1: Fabric Networking API (v1) 1.0.0+4358fbc63a
		fabric-networking-blockentity-v0: Fabric Networking Block Entity (v0) 0.2.7+a03e98793a
		fabric-networking-v0: Fabric Networking (v0) 0.3.1+2a4333d33a
		fabric-object-builder-api-v1: Fabric Object Builder API (v1) 1.9.2+6a2618f53a
		fabric-object-builders-v0: Fabric Object Builders (v0) 0.7.1+6a2618f53a
		fabric-particles-v1: fabric-particles-v1 0.2.2+6a2618f53a
		fabric-registry-sync-v0: Fabric Registry Sync (v0) 0.7.3+be155ae23a
		fabric-renderer-api-v1: Fabric Renderer API (v1) 0.3.3+6a2618f53a
		fabric-renderer-indigo: Fabric Renderer - Indigo 0.4.3+6a2618f53a
		fabric-renderer-registries-v1: Fabric Renderer Registries (v1) 2.2.0+6a2618f53a
		fabric-rendering-data-attachment-v1: Fabric Rendering Data Attachment (v1) 0.1.4+6a2618f53a
		fabric-rendering-fluids-v1: Fabric Rendering Fluids (v1) 0.1.12+6a2618f53a
		fabric-rendering-v0: Fabric Rendering (v0) 1.1.1+6a2618f53a
		fabric-rendering-v1: Fabric Rendering (v1) 1.4.0+6a2618f53a
		fabric-resource-loader-v0: Fabric Resource Loader (v0) 0.4.0+552549d53a
		fabric-screen-handler-api-v1: Fabric Screen Handler API (v1) 1.1.0+6a2618f53a
		fabric-structure-api-v1: Fabric Structure API (v1) 1.1.1+f1d8af063a
		fabric-tag-extensions-v0: Fabric Tag Extensions (v0) 1.1.0+e77439c73a
		fabric-textures-v0: Fabric Textures (v0) 1.0.5+6a2618f53a
		fabric-tool-attribute-api-v1: Fabric Tool Attribute API (v1) 1.2.5+6a2618f53a
		fabricloader: Fabric Loader 0.11.0
		imm_ptl_core: Immersive Portals Core 0.60
		immersive_portals: Immersive Portals 0.60
		java: OpenJDK 64-Bit Server VM 14
		minecraft: Minecraft 1.16.4
		modmenu: Mod Menu 1.14.6+build.31
		roughlyenoughitems: Roughly Enough Items 5.8.10
		roughlyenoughitems-api: REI (API) 5.8.10
		roughlyenoughitems-default-plugin: REI (Default Plugin) 5.8.10
		roughlyenoughitems-runtime: REI (Runtime) 5.8.10
	Launched Version: 1.16.4
	Backend library: LWJGL version 3.2.2 build 10
	Backend API: GeForce RTX 2070/PCIe/SSE2 GL version 4.6.0 NVIDIA 461.09, NVIDIA Corporation
	GL Caps: Using framebuffer using OpenGL 3.0
	Using VBOs: Yes
	Is Modded: Definitely; Client brand changed to 'fabric'
	Type: Client (map_client.txt)
	Graphics mode: fancy
	Resource Packs: Fabric Mods
	Current Language: English (US)
	CPU: 8x Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

As near as I can tell (and this is probably no more than a vaguely educated guess), it seems to be tied to rapidly turning to face the portal before or as you're stepping through it.
latest - turning fast.log
During my many attempts at replication, I got the vague sense that this might only occur if the portal was near a northern chunk border, but that could be dumb luck.

I cannot reproduce this issue.
Try to use the command /immersive_portals_debug smooth_unload_disable and then can you reproduce this?

I cannot reproduce this issue.
Try to use the command /immersive_portals_debug smooth_unload_disable and then can you reproduce this?

The command /immersive_portals_debug smooth_unload_disable was unknown, so I'm guessing you may have meant whatever command it was that I found that was similar to that. So I ran /immersive_portals_debug smooth_chunk_unload_disable. Hopefully that was the command you wanted me to run?
latest - Debug Smooth Disable.log
https://youtu.be/aa9WnL-iry8

The command /immersive_portals_debug smooth_unload_disable was unknown, so I'm guessing you may have meant whatever command it was that I found that was similar to that. So I ran /immersive_portals_debug smooth_chunk_unload_disable. Hopefully that was the command you wanted me to run?
latest - Debug Smooth Disable.log
https://youtu.be/aa9WnL-iry8

If you put a torch in the wrong light area, will the light around it become normal?

If you put a torch in the wrong light area, will the light around it become normal?

If it does not, it probably means that the client light data of that section is not enabled.

If it does not, it probably means that the client light data of that section is not enabled.

Do you get this issue in this version? https://github.com/qouteall/ImmersivePortalsMod/releases/tag/v0.61-1.16
If the issue still exists, try to place a torch in the wrong light area, will the light around it become normal?

Do you get this issue in this version? https://github.com/qouteall/ImmersivePortalsMod/releases/tag/v0.61-1.16
If the issue still exists, try to place a torch in the wrong light area, will the light around it become normal?

https://youtu.be/rKEIiCcm7CE
As you can see, the light immediately around the torch becomes normal, both when placing the torch and breaking it, but other areas within the same chunk that are not increased by the torch's light remain broken.

https://youtu.be/rKEIiCcm7CE
As you can see, the light immediately around the torch becomes normal, both when placing the torch and breaking it, but other areas within the same chunk that are not increased by the torch's light remain broken.

Upload the world. Maybe I can reproduce it in that world

Upload the world. Maybe I can reproduce it in that world

immersive-portals-0.62-mc1.16.4-fabric.zip
Try to use this version to reproduce the issue and upload the log. You don't need to show video this time.
After reproducing the bug, disable the last server side configuration "increase loading range gradually" and check whether the bug manifests with that that config disabled

immersive-portals-0.62-mc1.16.4-fabric.zip
Try to use this version to reproduce the issue and upload the log. You don't need to show video this time.
After reproducing the bug, disable the last server side configuration "increase loading range gradually" and check whether the bug manifests with that that config disabled

You can also use this to check https://github.com/qouteall/ImmersivePortalsModForForge/releases/tag/v0.13-1.16

You can also use this to check https://github.com/qouteall/ImmersivePortalsModForForge/releases/tag/v0.13-1.16

In Fabric with 0.62, bug reproduced: latest - Lighting 0.62 Fabric.log
Changing graduallyIncreaseLoadingRange to false to test again.

In Fabric with 0.62, bug reproduced: latest - Lighting 0.62 Fabric.log
Changing graduallyIncreaseLoadingRange to false to test again.

After flipping that config, reproducing the bug resulted in the most stunning reproduction of the bug yet.

So I know you said I didn't need video, but this video has a bit of an interesting thing: Placing torches would sometimes repair the lighting for where it was placed, but not always. Included for demonstrative purposes.
https://youtu.be/ibRjlxrlw4s
latest 0.62 after config change.log

After flipping that config, reproducing the bug resulted in the most stunning reproduction of the bug yet.

So I know you said I didn't need video, but this video has a bit of an interesting thing: Placing torches would sometimes repair the lighting for where it was placed, but not always. Included for demonstrative purposes.
https://youtu.be/ibRjlxrlw4s
latest 0.62 after config change.log

The log does not say any error, it's weird.

The log does not say any error, it's weird.

Since you weren't getting anything useful in the Fabric log, I decided I'd try the Forge build you provided to see if that did anything different. The linked issue above shows the result of that attempt.

Since you weren't getting anything useful in the Fabric log, I decided I'd try the Forge build you provided to see if that did anything different. The linked issue above shows the result of that attempt.

debug.log
Recreation of the issue in Forge with IPv0.13.
I don't see anything useful, but maybe you will.

debug.log
Recreation of the issue in Forge with IPv0.13.
I don't see anything useful, but maybe you will.

immersive-portals-0.64-mc1.16.4-fabric.zip
Here is a new version to test.

Check can you reproduce the bug in that version
If you still can reproduce, then quit to main menu, enter the world, use command /immersive_portals_debug light_logging_enable
Reproduce again and upload the log.

immersive-portals-0.64-mc1.16.4-fabric.zip
Here is a new version to test.

Check can you reproduce the bug in that version
If you still can reproduce, then quit to main menu, enter the world, use command /immersive_portals_debug light_logging_enable
Reproduce again and upload the log.

latest.log
https://youtu.be/MyBCPewI5hw

latest.log
https://youtu.be/MyBCPewI5hw

After turning the chunk visibility update interval shorter, I can reproduce this issue now.

After turning the chunk visibility update interval shorter, I can reproduce this issue now.

Probably fixed https://github.com/qouteall/ImmersivePortalsMod/releases/tag/v0.65-1.16
It's because that, if a chunk unloads the client light system will mark its section positions as to-be-removed, but it will actually be removed during the light update. However if the player is not in overworld and no portal to overworld is being rendered the overworld lighting will not be updated. When the overworld chunk get reloaded that sections' positions are still marked removed so the lighting data get wrongly removed. I made it to always update the light regardless of portal rendering.

Probably fixed https://github.com/qouteall/ImmersivePortalsMod/releases/tag/v0.65-1.16
It's because that, if a chunk unloads the client light system will mark its section positions as to-be-removed, but it will actually be removed during the light update. However if the player is not in overworld and no portal to overworld is being rendered the overworld lighting will not be updated. When the overworld chunk get reloaded that sections' positions are still marked removed so the lighting data get wrongly removed. I made it to always update the light regardless of portal rendering.

I'm struggling to reproduce the bug in 0.65. I don't promise that means it's fixed, since it'd usually take me a few tries to reproduce it and maybe I'm just unlucky, but you might have killed the bug.

I'm struggling to reproduce the bug in 0.65. I don't promise that means it's fixed, since it'd usually take me a few tries to reproduce it and maybe I'm just unlucky, but you might have killed the bug.

It's deemed fixed.

It's deemed fixed.


fix formatting issue of links

Contributor Checklist

[x] Did you add Scaladoc to every public function/method?
[x] Did you add at least one test demonstrating the PR?
[x] Did you delete any extraneous printlns/debugging code?
[x] Did you specify the type of improvement?
[x] Did you add appropriate documentation in docs/src?
[x] Did you state the API impact?
[x] Did you specify the code generation impact?
[x] Did you request a desired merge strategy?
[x] Did you add text to be included in the Release Notes for this change?

Type of Improvement
Documentation
API Impact
No impact
Backend Code Generation Impact
No impact
Desired Merge Strategy
Squash: The PR will be squashed and merged
Release Notes
Fix formatting issue of links in the "Experimental Features" part of the docs/website
Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (3.2.x, 3.3.x, 3.4.0, 3.5.0) ?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

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


Add data source for log fields to use with cloudflare_logpush_job

Current Terraform and Cloudflare provider version
terraform -v
Terraform v1.3.3
Description
We would like to push all log fields. Instead of having a list of log fields that is manually updated and passed to logpull_options parameter on the cloudflare_logpush_job, it would be good if there was a data source which could be used to reference when setting up a log push job. Or just a way to just enable all fields.
Looking at the docs I can see that the following endpoint is available for fetching all fields available for a dataset and zone id:
https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/logpush/datasets/<DATASET>/fields
Ideally the data source would be able to query the above fetching a set of all the fields.
Currently we are manually maintaining a list and doing the following:
locals {
  http_requests_fields = [
    "BotDetectionIDs",
    "BotScore",
    "BotScoreSrc",
    "BotTags",
    "CacheCacheStatus",
    "CacheReserveUsed",
    "CacheResponseBytes",
    "CacheTieredFill",
    ...
  ]
}

resource "cloudflare_logpush_job" "http_requests" {
  logpull_options     = "fields=${join(",", local.http_requests_fields)}&timestamps=rfc3339"
  dataset             = "http_requests"
}

Use cases
Populating logpull_options with all fields.
Potential Terraform configuration
data "cloudflare_log_fields" "http_requests" {
  zone_id  = var.zone_id
  dataset = "http_requests"
}

References
No response

duplicate of #1005.


ARROW-1328: [Python] Set correct Arrow type when coercing to milliseconds and passing explicit type

cc @fjetter
I'm planning to deprecate the timestamps_to_ms argument but it needs a patch in parquet-cpp first (so that nanoseconds/microseconds can be casted on the fly to milliseconds), so let's handle this fix first

+1


How does terragrunt track with terraform 13 beta

My thinking is there is a chance that not much has to change, per how your software is built, but wanted to know if there are any specifics.  I'd like to beta test, but don't want to go away from terragrunt....so being lazy.
Thanks

You should be able to start testing terragrunt with terraform 0.13 by using something like tfenv to install it alongside terragrunt. Alternatively, you can install terraform 0.13 under a different name (e.g. terraform13) and point terragrunt to it (either using --terragrunt-tfpath or terraform_binary).
Note that any new (or updates to existing) functions introduced in tf13 won't be available until we rebuild terragrunt.
If you find any issues, report back and happy to take a look!

Doesn't work with beta releases, due to
https://github.com/gruntwork-io/terragrunt/blob/master/cli/version_check.go#L16

Ah missed that. Thanks for pointing that out and the PR: https://github.com/gruntwork-io/terragrunt/pull/1227

Closing, as Terragrunt has supported 0.13 for a while. https://terragrunt.gruntwork.io/docs/getting-started/supported-terraform-versions/


How to generate README.md with codeblocks?

Firstly, really nice job on scaffdog. I really like how you use the markdown scaffolding files. It is clever.
I have a question (maybe I'm doing something wrong). How do I scaffold a markdown file that has code backticks?
Expected Behavior
I want to generate a markdown file with code examples (triple-backticks). Is there some way to escape the ``` such that the escapes are removed on generation? Unfortunately, I need to include images because, well, backticks.
Actual Behavior
The README.md file gets truncated.
Steps to Reproduce (including precondition)
{Please write here}
Screenshot on This Problem (if possible)
Source

Generated

Your Environment

OS: {Please write here}
scaffdog version: {Please write here}

Hi @wickedest, Thank you for using scaffdog :dog: :heart:
scaffdog uses GitHub flavored markdown. To view further code blocks within a code block, the following documentation may be helpful :point_down:

To display triple backticks in a fenced code block, wrap them inside quadruple backticks.
```
Look! You can see my backticks.
```

Document:
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#fenced-code-blocks

I have verified that the scaffdog playground produces the expected output :+1:

Playground: (Please click the Generate button!)
https://scaff.dog/playground?code=H4sIAAAAAAAAA1NWSAhydXTxddXLTUng4koAgtzEouyU%2FPI8LmWF6mqFzLyC0pJivbzE3FSF2louLmVlBc%2B84pLEnJzEksz8PLCWpMTiDC4VhYLMAqBysBwWnUB1YOO5AIzZB%2BtzAAAA&input=H4sIAAAAAAAAA4uuVspOrVSyUspLzE1V0lEqS8wpTQVyi5MT09JS8tOVamMBz%2B0iZCMAAAA%3D

@wadackel , I somehow missed the four-backtick fence example. worked perfectly - tyvm, and keep up the good work!


Update training YAMLs with new defaults

FSDP new defaults:

mixed_precision: PURE
activation_checkpointing_reentrant: false
limit_all_gathers: true

MosaicGPT new defaults:

attn_impl='triton'
param_init_fn='kaiming_normal_'
init_nonlinearity='relu'
low_precision_layernorm=True

Training loop new defaults

eval_first: false just to expose that this an option

also are we skipping low_precision_layernorm: true?
I put this in the default MosaicGPTConfig now, so it should be true by default.


Added Anime API

🎯 Anime API (Issue No. 281)
Closes #281
🗒 Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x]  I have gone through rules of when PR will get merged.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md
[x] I have followed proper file structure.
[x] I have gone through CONTRIBUTING GUIDELINES.md.

Hey @tanyagupta01, Thank you for creating PR! We will review it super soon. 😇❣
As we continue to evolve and innovate, we encourage you to share your ideas, feedback, and code to help us push the boundaries of what's possible in the world of APIs🚀.
We hope you have followed CONTRIBUTING GUIDELINES.
Thank you for being an essential part of our community. Together, we'll keep building amazing things!
Don’t forget to ⭐ our repository!
Happy Coding!✨
Will See you soon❣

@tanyagupta01

index.html is empty file.

@tanyagupta01 ,I wanted to reach out and let you know that we have decided to close your pull request.🙇
In case of any issues, you can contact us on Discord.
Thank you! ❣
Happy Coding! ✨
Will See you soon❣

@dishamodi0910 please reopen this. I will add the index.html file. This was a mistake.
I will make another commit adding the index.html file.


Enhancement: Should transcribe-to-docx be an AWS Batch job?

Per https://github.iu.edu/IUBSSRC/automated-transcription-service/issues/78 we ran into the 15 minute limitation for json to docx translation. We made tweaks to lower the chance of hitting the limit. However, it seems with large files (approximately 4+ hours?) we would eventually still hit the limit. Does it makes sense to convert this to an AWS Batch job? What is the effort? Should it dynamically branch to optimize cost savings, if any? How often would we hit the limit? The only option when hitting the limit would be running the json through command line conversion.
ref: https://github.iu.edu/IUBSSRC/automated-transcription-service/issues/78#issuecomment-48414

For future reference: This might be the point at which we pivot to using an AWS step function for ATS. That would allow us to very easily create branching logic that could choose between Lamba/Batch based on the length of the transcription (audio).


Roadmap for experimental TypeScript support

Intro
Since the previous discussion was successful in gathering feedback from the community, and I believe there is some consensus that this feature is something that the project wants to add, I want to summarize what are going to be the next steps and some technical solutions.
To be honest I'm very glad for the amount of feedback I received, it helped me to change my view on some aspects that I previously ignored.
Before I go into technical implementation, this is what the goals of this feature should be in my opinion:

[!CAUTION]
These are long term goals and next steps, they might not reflect the current status.

Make sure Node.js can support TypeScript with the stability guarantees that has always offered.
Avoid breaking the ecosystem, this means creating a new "flavor" that only works on Node.js.
Performance.
Keeping it simple, we don't support everything, we want to user land tools to work in sync with Node, we provide the foundations to build on top.
Type stripping is the way to go.

Step 1: Initial implementation

[x] https://github.com/nodejs/node/pull/53725

The initial implementation is the proof of concept that I have created to gather feedback and consensus from the project collaborators.
It's very far from being perfect but it establishes some of the points we want to move forward with.
Current limitations:

No support  forTypeScript features that require transformation (Enums, namespace, etc...).
No .js extension for .ts files.
No running TypeScript in node_modules.
No source maps, but not needed because we perform whitespacing (replace removed code with white space).

[!IMPORTANT]
Why no support for TypeScript features such as enums, namespaces, decorators, etc...?????

In the initial implementation I decided to start with the smallest subset possible.
Adding transformation means supporting source-maps so is more work.
Supporting features means adding more instability to the TypeScript syntax we support, without having a way to stay up to date with new features. As a general rule of thumb, the more you support the more likely to have breaking changes. This is a great challenge to overcome because we need to support transformations and new features but respect Node stability guarantees

Step 2: Decoupling

[ ] TBD

There is already a precedent for something that Node.js support, that can be upgraded seperately, its NPM.
Node bundles a version of npm that can upgraded separately, we could do the same with our TypeScript transpiler.
We could create a package that we bundle but that can also be downloaded from NPM, keep a stable version in core, but if TypeScript releases new features that we don't support or breaking changes, or users want to use the new shiny experimental feature, they can upgrade it separately.
This ensures that users are not locked, but also provides support for a TypeScript version for the whole 3 years of the lifetime of Node.js release.
Getting started
Create a new package called amaro that wraps swc with the current implementation. This package, which is released on npm, offers the same api that is currently used by Node, and it can be upgraded separately. The first challenge would be setup the project, make sure it can be upgraded by running npm install -g<EMAIL_ADDRESS>Increase features

Enable support for TypeScript features that require transformation (Enums, mamespaces), now that we are decoupled we can expand on the amount of feature we support.
Enable running TypeScript files in node_modules

[!CAUTION]
Currently there is no consensus whether Node.js should run TypeScript files inside `node_modules.
Currently it is not supported to avoid package maintainers to release TS only package.
I'm personally in favor of supporting it.

Thanks @joyeecheung and @legendecas for the idea 💡
Step 3: Make it fast

[ ] TBD

With the project up and running, we can now start thinking about performance.
We could vendor SWC in Rust, build our own wasm, or compile it to static libraries that we could use in core, c++ rust FFI, etc...
I'm not a performance expert, but I think it is possible to optimize the interaction between Node and SWC and make it performant, without impacting the Node build process.
This is the phase where we measure the performance and make it usable in production without performance penalties.
Step 4: Add more features

[ ] TBD

The @node/ts-loader in the current state does not offer much to users, it's released as an external package but it's pretty much useless other than as an internal.
In this phase we could add extra features that are not used in core, but provide utilities to users to reduce some of the pain that our restriction might have cause.
Example:

Offer a loader api that allows transformation .js => .ts that can be enabled with a flag or as an external loader.
Offer more configuration, tsconfig support etc...

Wont Fix

I strongly believe  we should not support .js extension for .ts files.
The reason is that the compiler/bundler should be responsible to resolve the correct extension at compile time.
At runtime, the extension must be correct, it doesn't make sense to add overhead in production when it can be solved during development. Discussion happening here: https://github.com/nodejs/loaders/issues/214
Support tsconfig directly
This would mean to run with typescript to support the latest flavors etc... Compilation and type checking should be done by user land tools during development.

I think this looks great; can we just replace the contents of the .md file in https://github.com/nodejs/loaders/pull/210 with what you’ve written here? And then we can land that PR.

No support forTypeScript features that require transformation (Enums, namespace, etc...).

Is there a definitive list of features that are not supported here?

No support forTypeScript features that require transformation (Enums, namespace, etc...).

Is there a definitive list of features that are not supported here? I'm looking to adapt my eslint config to match.

it's documented here https://github.com/nodejs/node/blob/main/doc/api/typescript.md but you should expect it to change in the future

There's a Getting Started article on the Node.js website — Node.js with TypeScript (source) — that might benefit from an update including information about this feature (once the time is right). I suppose a linked issue should be created in that repository, but wasn't sure whether it should be included somewhere in the list here, too.

Enable running TypeScript files in node_modules

Caution
Currently there is no consensus whether Node.js should run TypeScript files inside `node_modules. Currently it is not supported to avoid package maintainers to release TS only package. I'm personally in favor of supporting it.

I understand the argument against encouraging package maintainers from releasing TS only packages. However, one additional thing to consider here is how node operates with internal packages in a monorepo. I'm not familiar with how other package managers work in this regard today, but pnpm will make links for internal workspace protocol packages as node_modules references in the dependent package. If node_modules support is not available, that would still then require a build step for any internal dependencies. I'm not sure how you could differentiate between these internal dependencies versus published packages, but being able to bypass a build step for internal packages would be extremely beneficial for monorepos structured this way.

I'm not sure how you could differentiate between these internal dependencies versus published packages, but being able to bypass a build step for internal packages would be extremely beneficial for monorepos structured this way.

I would think that this detail wouldn't matter because the realpath of these paths would leave node_modules. However, I'm not 100% certain how one would set up a monorepo with TS support via this flag anyway; you'd need to point things like export maps to TS files, making those export maps broken if packages are ever published, unless you go the "live types" route with a monorepo-local custom condition.

I would think that this detail wouldn't matter because the realpath of these paths would leave node_modules

This might just work out of the box then. I haven't tested with the new experimental flag yet, but it would be awesome if it just worked without any other considerations. 👍

However, I'm not 100% certain how one would set up a monorepo with TS support via this flag anyway; you'd need to point things like export maps to TS files, making those export maps broken if packages are ever published, unless you go the "live types" route with a monorepo-local custom condition.

In my use case, I wasn't thinking of publishing because the repo in question isn't published but is our backend runtime. With respect to things like export maps, converting them at build-time is actually how we make these internal packages work today. The exports and/or main properties in package.json are referencing the .ts files in the source. This allows for internal type checking to use the dependencies' .ts files and for ts-node to operate against the source file even in the dependencies. At build time, the exports and/or main properties are converted from src/*.ts to dist/*.js so the dependent packages are then using the transpiled JS.
I'm unsure if this is a common use case in the rest of the world, but I'm optimistic based on the realpath comment above that this might just work without any additional overhead.

Is the idea to eventually support other typing systems (for example, Flow, Hegel, or whatever comes next after TypeScript) like https://github.com/tc39/proposal-type-annotations proposes, or is this feature focused solely on TypeScript?
If it's only going to be for TypeScript, wouldn't it be better for the --experimental-strip-types flag to include typescript or ts in its name?

My understanding is that the inclusion of TypeScript support in Nodejs is to simplify the development cycle - where distributed code should still be transpiled to JavaScript before consumption (npm, production, etc).
Nodejs-valid TypeScript requires the .ts extension to be listed in the import specifier. The issue is that there is no easy way to transpile imports with .ts extensions to .js.
The official TypeScript compiler does not support transforming imports due to the difficulty of handling dynamic imports.
SWC has a plugin that can rewrite import extensions, but it skips dynamic imports and is annoying to set up. Ideally, this additional tooling would be avoided as it defeats the purpose of using built-in TS support.
Can we get guidance on how to properly transpile Nodejs-valid TypeScript to valid JavaScript for distribution?

Some discussion going on here https://github.com/nodejs/loaders/issues/214.
I think we still need to figure out with @nodejs/typescript
1 - A recomended tsconfig
2 - How to solve the extension resolution
3 - add to a amaro a way to perform the extension resolution wheh used as external loader

Nodejs-valid TypeScript requires the .ts extension to be supplied in the import specifier. The issue is that there is no easy way to transpile imports with .ts extensions to .js.

The extension requirement comes from ESM support in Node which has always required a extension. I think it's a good requirement because it eliminates ambiguity when both .ts and .js files exist with the same name and it makes the file loading faster. Imho people should find some codemod tool to adds the extension to their imports.

Imho people should find some codemod tool to adds the extension to their imports.

I'm working on creating one. I'll post once it's ready. I plan for it to correct bad file extensions (ex .js when the file is actually .ts and there is no such JS file) and when the file extension is altogether missing in the specifier.

The extension requirement comes from ESM support in Node which has always required a extension. I think it's a good requirement because it eliminates ambiguity when multiple files exist with the same name and it makes the module resolution faster. Imho people should find some codemod tool to adds the extension to their imports.

I 100% agree with this take. I think it was a good call to use explicit file paths as it avoids confusion and simplifies resolution.

Codemod is WIP: https://github.com/JakobJingleheimer/correct-ts-specifiers currently struggling with jscodeshift, which seems to be the biggest yet is almost completely undocumented (as is codemod itself 😢).

currently struggling with jscodeshift, which seems to be the biggest yet is almost completely undocumented

@JakobJingleheimer  It's being worked on :smile:  We (jscodeshift maintainers) launched a new docs site launched recently, but is still a work-in-progress: https://jscodeshift.com/build/api-reference/

Codemod is WIP: https://github.com/JakobJingleheimer/correct-ts-specifiers currently struggling with jscodeshift, which seems to be the biggest yet is almost completely undocumented (as is codemod itself 😢).

@JakobJingleheimer, founder of Codemod here (also maintaining jscodeshift, thanks @Daniel15 for the mention)
would love to connect and help with any codemod questions, tooling, or documentation you need. feel free to ping me on X or in our community: https://go.codemod.com/community

Nodejs-valid TypeScript requires the .ts extension to be supplied in the import specifier. The issue is that there is no easy way to transpile imports with .ts extensions to .js.

The extension requirement comes from ESM support in Node which has always required a extension. I think it's a good requirement because it eliminates ambiguity when multiple files exist with the same name and it makes the module resolution faster. Imho people should find some codemod tool to adds the extension to their imports.

@silverwind the problem isn't that the strip-types MVP requires an extension (that makes perfect sense), but specifically that it requires the .ts extension while tsc requires the .js extension for a TS file. So, as it stands strip-types is incompatible with tsc in an annoying way.
This could be resolved by using a codemod tool either before running tsc or node, but that almost makes strip-types useless, as the whole point AFAIU was to make TS transpilation built into Nodejs, which it isn't if we need yet another tool to make it work. (See more discussion here)
It could also be resolved on the tsc side, by rewriting .ts imports, which would be even nicer (.ts imports are more natural for TS files). But then again, tsc is the established tool and strip-types is the experimental newcomer, so I think there's an argument that strip-types should ensure compatibility anyway.

So, as it stands strip-types is incompatible with tsc in an annoying way.

Maybe splitting hairs a bit, but it's the other way around: tsc is incompatible with standards in an annoying way.
The codemod is almost ready: https://github.com/JakobJingleheimer/correct-ts-specifiers
@marco-ippolito is this codemod something we might want to make official? (Eg putting it under the @nodejs or @pkg namespace in npm)

there's an argument that strip-types should ensure compatibility anyway

Being first and wrong is still being wrong. That's not an argument in favour of changing our implementation (valid new arguments are welcome of course 🙂).

The codemod is a one-and-done step to fix issues in source-code, very similar to a migration; thereafter, just write the source-code properly and no extra tools are required.

@JakobJingleheimer there's a misunderstanding here. I agree it's no big deal to migrate an existing codebase from .js to .ts, I'd probably do that with find-and-replace.
However, that's not the issue that I was trying to bring up. The issue is in code bases that want to continue using tsc to compile their TS to JS, and therefore use .js. strip-types is incompatible with that flow.
(In case you wondered: no, I don't want to use a third-party tool instead of tsc to transpile the TS source, to get .ts imports to work; tsc has more compatibility with tsconfig options and various TS versions than any other tool; also, what's the point of strip-types if I need a third-party transpiler in my toolchain anyway)

Being first and wrong is still being wrong. That's not an argument in favour of changing our implementation (valid new arguments are welcome of course 🙂).

Ok! Then my argument is that changing the your implementation would make strip-types more useful, and therefore more widely adopted.

@mitschabaude its clear there is incompatibility between tools.
From my point of view Node should not support guessing the extension.
I believe typescript is working to add a flag to emit import with '.ts' extension.

Also, this is an experimental feature, at an early stage, so its fair that is not fully compatible with existing tooling 🙂

Definitely and I didn't want to suggest that it should. I think the direction taken with strip-types is great, congrats on the work so far  🙌🏻
I'm really just talking about the roadmap for this feature. Currently the roadmap has the issue listed as "wontfix". I'd love for that to change. I'm also willing to help make strip-types work with js imports. My intuition is that this should be possible at no additional cost to currently supported use cases.

I don't always want to use a third-party tool instead of tsc to transpile the TS source, to get .ts imports to work; tsc has more compatibility with tsconfig options and various TS versions than any other tool

Is there a specific and compelling tsconfig option that only tsc supports? If so, that could be persuasive. I've used esbuild as my transpiler for quite some time though, and I've never encountered anything it couldn't handle.
Wince everyone seems to agree TS's behaviour is wrong, I'm still inclined to say regardless that that would be TypeScript's problem, and you're asking us instead of them to change something because we actually consider feedback 🙃 (which is a little funny as I've so far basically been saying "no" 😅)
Buuuut as Marco pointed out, this may be moot if tsc is soon to handle proper file extensions.

I'm also willing to help make strip-types work with js imports.

Very appreciate that you're willing to contribute—contributions generally super welcome! However, there is significant opposition to this particular item within node, not to mention it would violate spec; baring a very unexpected persuasive argument (I'm not so arrogant to say I'm right no matter what 😉), I would block this. It is already possible and very easy to do this within node with tools that already exist: a resolve hook. I even wrote such a hook that will do what you want.

Should this be moved to a separate issue/discussion? I think this is getting a bit too specific for this general roadmap issue.

I love absolutely everything that's going on here, so thank you to everyone who has been involved in it.  I'm particularly impressed to see the communication and coordination going on between the node and TypeScript teams.
Here's a question from the peanut gallery: --experimental-strip-types has been released as part of v22.6.0.  Will --experimental-transform-types land in some v22 release soon as well?  It would be lovely to see this packaged in Fedora so that we can start playing around with it in earnest.

I love absolutely everything that's going on here, so thank you to everyone who has been involved in it. I'm particularly impressed to see the communication and coordination going on between the node and TypeScript teams.
Here's a question from the peanut gallery: --experimental-strip-types has been released as part of v22.6.0. Will --experimental-transform-types land in some v22 release soon as well? It would be lovely to see this packaged in Fedora so that we can start playing around with it in earnest.

As I understand it, everything that's on main branch until the v22 LTS is forked on 2024-10-29 will be included in a upcoming v22 release.

Should this be moved to a separate issue/discussion? I think this is getting a bit too specific for this general roadmap issue.

Agree, answered here: https://github.com/nodejs/loaders/issues/214#issuecomment-2301736577

@allisonkarlitskaya yes, --experimental-transform-types is going to be released in v22.7.0 which is scheduled for today/tomorrow

@marco-ippolito can't find proper info on the following, please let me know if I'm repeating a known issue:

How will it behave with dynamic imports? Will the flag be applied also to dynamically imported modules?
How will it deal with node_modules? Will it strips recursively?

I guess authors will have to compile/transpile the code because recursively stripping the imported files could result in breakage due to enums/namespace/decorators. Correct?

@marco-ippolito can't find proper info on the following, please let me know if I'm repeating a known issue:

How will it behave with dynamic imports? Will the flag be applied also to dynamically imported modules?
How will it deal with node_modules? Will it strips recursively?

I guess authors will have to compile/transpile the code because recursively stripping the imported files could result in breakage due to enums/namespace/decorators. Correct?

please refer to the documentation https://nodejs.org/docs/latest/api/typescript.html#type-stripping

Just gonna drop this here, for anyone looking to run node --experimental-strip-types and still have their .js imports work as expected.
https://www.npmjs.com/package/node-resolve-ts

Will there be some discussion / meeting agenda items to come back around to TS type stripping support in node_modules?
The last agenda item I could find about this was these meeting notes from 2024-07-24:
https://github.com/nodejs/TSC/blob/3f3606df0f44ac07a582128f068b3d699866a00d/meetings/2024-07-24.md?plain=1#L70-L83
As a user, it would be great to also have this ability that other runtimes like Bun have.
Looking to enable executable scripts in node_modules like this (to avoid a compile step for packages written in TypeScript which happen to be in node_modules):
bin/index.ts
#!/usr/bin/env -S node --experimental-strip-types

const a: number = 1;
console.log(a);

There have been serious concerns raised by the TypeScript team about doing so.
I 100% agree with them, and I don't expect it to ship without a contested TSC vote.

@karlhorky I think there is consensus both from Node and from TypeScript that running ts in node_modules should NOT be supported. So I doubt that there will be discussion unless someone comes up with a very good reason. I will update the issue.

There have been serious concerns raised by the TypeScript team about doing so.
I 100% agree with them, and I don't expect it to ship without a contested TSC vote.

Could you please link to that?

Does the lack of node_module support break workspaces? Consuming sources within a workspace is a valid use case that would be a deal breaker for many projects

The TypeScript team is concerned about the ecosystem consequences of users publishing TypeScript source files to the npm registry, and one way to discourage such an outcome has been to prevent type stripping support for files under node_modules. We would love to find a solution that allows type stripping to be used with monorepos and npm workspaces while avoiding encouraging users to publish TypeScript sources to the npm registry.

I know that as a user I won't have much sway here, but I think I'm not alone in thinking that files in node_modules should also be allowed type stripping.
A few thoughts:
1) Node.js Alone Won't Prevent TS npm Publishing
There is a lot of movement in the "execute TypeScript, don't build it" ecosystem already, for example with the advent of many ecosystem projects such as:

TypeScript execution CLIs like ts-node, tsm, tsx
TypeScript-native runtimes like Bun and Deno
modern TS-native registries like JSR

Publishing .ts files to npm and other registries is already a growing pattern, which drastically reduces the effort and complexity of publishing a TypeScript package.
I think as these projects evolve and more people get to know about this possibility, there will be a greatly increased interest in this possibility.
It's my opinion that this banning of node_modules/*/*.ts in Node.js alone won't be able to hold back the energy in the ecosystem, especially with working alternatives. (not to mention users circumventing this by using any of the other projects, which do not have this limitation)
2) User Experience
My first experience with node --experimental-strip-types was creating an internal checking tool which was its own package, without a build step.
I immediately fell flat on my face with this, because of the banning of node_modules/*/*.ts files.
Even though I was already somewhat aware of the discussions and objections behind this, for my use case it felt like an arbitrary limitation imposed on my project.
I imagine that as type stripping becomes more widespread, this will be a common complaint from users.
3) Node.js Features Available Everywhere
@GeoffreyBooth wrote about supporting a Node.js feature everywhere:

If we support a file type, we support it everywhere. Just as module detection needs to apply within node_modules so that a package that works locally continues to work when published to npm, the same applies to TypeScript. We shouldn't be limiting our functionality to try to encourage best practices.

This resonates with me - it seems like supporting a Node.js feature in as many places as possible will be the best for users and cause the least amount of support complaints.
Banning node_modules/*/*.ts to try to avoid a pattern which the ecosystem may adopt seems like a weak reason. (not to mention that the ecosystem may end up adopting this pattern anyway by finding cowpaths around this)
4) Identifying and Addressing Downsides
Downsides as mentioned by Ryan and Daniel on the TypeScript team and vocal node_modules/*/*.ts opponents such as Matteo are important and should be considered.
But it feels like also:

Each problem should be carefully thought through, examined, clearly enumerated and documented (also asked for by Geoffrey)
Once clearly enumerated and documented, solutions should be also thought through, with each solution's tradeoffs being also enumerated and documented

This being done with a dispassionate, neutral stance, not trying to prove any one viewpoint.
In reading through the publicly-available documents, I don't think this has been done yet.
5) At Least Allow Users to Choose
Even if careful enumeration of problems and solutions leads to the final conclusion that the tradeoff is not worth it for Node.js, I think it would be good to allow users to disable this node_modules/*/*.ts banning with a flag, eg:
node --experimental-strip-types-in-dependencies

6) Similarities to .ts Rewriting Limitation
Oh one more thing, more related of a feeling than fact-based:
This node_modules/*/*.ts banning feels like it has a similar vibe to the .ts -> .js rewriting decision in TypeScript, which was overturned after years of doubling-down on .js imports (ironically heavily inspired by Node.js type stripping).

Hello @karlhorky - thanks for the thoughtful input.  @marco-ippolito mentioned in the most recent Node TS meeting that we haven't received much feedback on --experimental-strip-types yet, so your real-life experience is useful to hear.
Whilst this restriction is trivial to lift in terms of code changes in Node, the implications and opinions on doing so are significant. I'd suggest re-posting it as a dedicated issue on the https://github.com/nodejs/typescript repo to avoid thread-explosion here.

@robpalme thanks for the feedback! Copied to a dedicated issue here and edited my posts above:

https://github.com/nodejs/typescript/issues/14

Sorry for bumping an old ticket, but in light of monorepo support currently only available through third party loaders (like tsx), it would be super helpful if Nodejs Workers would inherit --loader loaders from the parent process. This is a problem I am currently facing

Hello @karlhorky - thanks for the thoughtful input. @marco-ippolito mentioned in the most recent Node TS meeting that we haven't received much feedback on --experimental-strip-types yet, so your real-life experience is useful to hear.

Is there somewhere where feedback is being solicited?  I've played around with it a bit and found it to be a great replacement for tsx in the projects where we use it.  The only downside, honestly, is the big scary warning and our concerns about depending on "too new" of a node version for our users.

@allisonkarlitskaya feedback is being received through issues/discussion is the nodejs/typescript repo