We shouldn't evict images from the cache when they're on the screen

It just causes us to immediately refetch them.

(I have a case where I have two images, both of which slightly more than the maximum cache size. Every time the screen is updated, one gets evicted and immediately refetched from the network, then when it comes in the other gets evicted and immediately refetched from the network, and this continues forever.)

This seems to do the trick:
diff --git a/packages/flutter/lib/src/painting/image_cache.dart b/packages/flutter/lib/src/painting/image_cache.dart
index 8beb77b..f80b847 100644
--- a/packages/flutter/lib/src/painting/image_cache.dart
+++ b/packages/flutter/lib/src/painting/image_cache.dart
@@ -183,28 +183,35 @@ class ImageCache {
       _checkCacheSize();
     }
     if (maximumSize > 0 && maximumSizeBytes > 0) {
       _pendingImages[key] = _PendingImage(result, listener);
       result.addListener(listener);
     }
     return result;
   }

   // Remove images from the cache until both the length and bytes are below
-  // maximum, or the cache is empty.
+  // maximum, or the cache is empty (or contains only images that cannot be
+  // evicted).
   void _checkCacheSize() {
-    while (_currentSizeBytes > _maximumSizeBytes || _cache.length > _maximumSize) {
-      final Object key = _cache.keys.first;
-      final _CachedImage image = _cache[key];
-      _currentSizeBytes -= image.sizeBytes;
+    int index = 0;
+    final List<Object> keys = _cache.keys.toList();
+    while (index < keys.length &&
+           (_currentSizeBytes > _maximumSizeBytes || _cache.length > _maximumSize)) {
+      final Object key = keys[index];
+      final _CachedImage entry = _cache[key];
+      if (!entry.completer.preventEviction) {
+        _currentSizeBytes -= entry.sizeBytes;
         _cache.remove(key);
       }
+      index += 1;
+    }
     assert(_currentSizeBytes >= 0);
     assert(_cache.length <= maximumSize);
     assert(_currentSizeBytes <= maximumSizeBytes);
   }
 }

 class _CachedImage {
   _CachedImage(this.completer, this.sizeBytes);

   final ImageStreamCompleter completer;
diff --git a/packages/flutter/lib/src/painting/image_stream.dart b/packages/flutter/lib/src/painting/image_stream.dart
index 335f1d0..8e2c5a4 100644
--- a/packages/flutter/lib/src/painting/image_stream.dart
+++ b/packages/flutter/lib/src/painting/image_stream.dart
@@ -246,20 +246,34 @@ abstract class ImageStreamCompleter extends Diagnosticable {
   ///
   /// Typically this is used by overriding [addListener], checking if
   /// [hasListeners] is false before calling `super.addListener()`, and if so,
   /// starting whatever work is needed to determine when to call
   /// [notifyListeners]; and similarly, by overriding [removeListener], checking
   /// if [hasListeners] is false after calling `super.removeListener()`, and if
   /// so, stopping that same work.
   @protected
   bool get hasListeners => _listeners.isNotEmpty;

+  /// Whether the image should be pinned in the cache even if the cache is over-
+  /// subscribed.
+  ///
+  /// This returns true if the completer has any listeners, on the assumption
+  /// that images that have listeners are actively being used (e.g. displayed
+  /// on the screen).
+  ///
+  /// If an image is on the screen, then it should not be evicted from the
+  /// cache, because otherwise it would need to be refetched (possibly over the
+  /// network) as soon as the screen is updated (since the image wouldn't be
+  /// found in the cache). Even if this happens quickly, it can still cause
+  /// flickering.
+  bool get preventEviction => hasListeners;
+
   /// Adds a listener callback that is called whenever a new concrete [ImageInfo]
   /// object is available or an error is reported. If a concrete image is
   /// already available, or if an error has been already reported, this object
   /// will call the listener or error listener synchronously.
   ///
   /// If the [ImageStreamCompleter] completes multiple images over its lifetime,
   /// this listener will fire multiple times.
   ///
   /// The listener will be passed a flag indicating whether a synchronous call
   /// occurred. If the listener is added within a render object paint function,

cc @iskakaushik

We shouldn't cause images to be reloaded, but I disagree that we shouldn't be evicting them. Rather, we should be sure that the image widgets reference to the ui.Image is destroyed on eviction as well.
The cache needs to be more reliable, otherwise it will remain trivial to create scenarios where loading multiple high resolution images can crash applications. See: numerous bugs on image memory leaks

This was fixed in a different way by #51249  - although that is temporarily reverted while I continue to figure out why it's breaking google tests. I also ended up tracking the images with listeners in a different bucket so we could more easily deal with clearing them without disrupting the rest of the cache.


Future dates

What do you think about future dates, something like 2 days from now?

Might be useful but it highly depends on the functionality. What do you like to do with future dates?

For example a system where you schedule salesmen visits: your next appointment is in 2 hours from now  or a billing system your next payment must be done in 2 days.

That's good idea. Do you have anything in your mind what is the best way how to do that?


remove gorm library

Is your feature request related to a problem? Please describe.
Currently we are using GORM for:

ORM
Database Migration

It works fine at the moment, but right now we are depending on GORM auto migrate for db migration and if in the future we want to change our postgres client, it would harder to switch, especially if we have lots of table to migrate.
Describe the solution you'd like
For Database MIgration, we can use https://github.com/golang-migrate/migrate
For ORM, we can use simple https://github.com/lib/pq as it is a dedicated postgres client

In addition to that, GORM is good but there are some edge cases that it does not cover yet. Since our use cases are still evolving, it is better for us to use the more flexible DB library.


Struct constructors are invoked with the new operator, but that does not imply that memory is being allocated.

It is stated as title.
Is it right? Need some clarification or source for explanation.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 071b082e-a4aa-00af-1f03-9f6f7205c0bc
Version Independent ID: cbd67b7f-8aae-2d43-a1dc-26a8b870389e
Content: C# structs - A tour of the C# language
Content Source: docs/csharp/tour-of-csharp/structs.md
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

@BillWagner I think I understand what @xamarin-volkan is talking about. It says "but that does not imply that memory is being allocated." when you use the new keyword with a struct. Isn't any/all memory allocated in some form? Perhaps it would be better to word that whole paragraph as:
bold is my change to the paragraph

Struct constructors are invoked with the new operator, similar to an object constructor. But, instead of dynamically allocating an object and returning a reference to it, a struct constructor simply returns the struct value itself (typically in a temporary location on the stack), and this value is then copied as necessary.

@Thraka I like that. I'll suggest one more clarification:

Struct constructors are invoked with the new operator, similar to a class constructor. But, instead of dynamically allocating an object on the managed heap and returning a reference to it, a struct constructor simply returns the struct value itself (typically in a temporary location on the stack), and this value is then copied as necessary.

bold is my addition
Adding the "up for grabs" label, and adding this to the community contribution project.


Remove a broken hawktracer annotation

Some change seems to have occurred which causes this specific hawktracer
annotation to fail to compile. For the time being, remove it so that
hawktracer support can compile again.

What is the error?

I wish there was a fix for it instead, but I think the issue is related to the fact that we use &mut self inside of the different threads in that function. So I think the only way to keep this annotation would be to completely rewrite how we thread things in this function, which probably requires reducing the threading effectiveness.


Feat/controller redeem procedure

:tada: This PR is included in version 2.0.1-beta.74 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[pytorch] Adds IValue Dict(str, IValue) support

Change-Id: I277ff2f07383d6389c6865ba0e3e77aef3190d0a
Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report

Merging #1765 (6bc9c63) into master (bb5073f) will decrease coverage by 1.45%.
The diff coverage is 70.47%.

@@             Coverage Diff              @@
##             master    #1765      +/-   ##
============================================
- Coverage     72.08%   70.63%   -1.46%
- Complexity     5126     5573     +447
============================================
  Files           473      527      +54
  Lines         21970    24737    +2767
  Branches       2351     2681     +330
============================================
+ Hits          15838    17474    +1636
- Misses         4925     5934    +1009
- Partials       1207     1329     +122

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...main/java/ai/djl/modality/cv/output/Rectangle.java
72.41% <0.00%> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <ø> (-5.24%)
:arrow_down:

...odality/cv/translator/BigGANTranslatorFactory.java
33.33% <0.00%> (+8.33%)
:arrow_up:

...nslator/InstanceSegmentationTranslatorFactory.java
14.28% <0.00%> (-3.90%)
:arrow_down:

.../cv/translator/StyleTransferTranslatorFactory.java
40.00% <ø> (ø)

.../ai/djl/modality/cv/translator/YoloTranslator.java
8.33% <0.00%> (-0.50%)
:arrow_down:

... and 411 more

Continue to review full report at Codecov.

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


Makefile: separate repository dependencies from system dependencies

Now you can call make repo-deps to avoid doing any of the user-wide ocaml stuff, and make system-deps if you want to do the system-wide ocaml stuff.
I've switched over the Jenkins CI to use repo-deps instead of deps, so that we avoid the race condition we've been having with the mantis vs normal test-suites with locking the user-wide ocaml directories.

@MrChico you also expressed interest in this separation. Now instead of make deps, I recommend using make repo-deps. You still need to do make deps at least once on the machine to setup OCaml stuff if you want concrete execution.

Jenkins: test mantis

Jenkins: test mantis

Jenkins: test mantis

Jenkins: test mantis

Jenkins: test mantis

@dwightguth looks like the tests will pass on this one, ready for review.


[Feature Request] support opening webm files

I came here for the same thing, and it seems that in the front page, where there are CLI examples, WEBM is used, so the app must actually support WEBM. Is it a GUI bug that it says "Couldn't open that file" when I try to open a WEBM in the GUI?
WEBM is the default format of Gnome's screen recording, which I often need to convert to GIF, because web forums only allow basic image formats, not WEBM.


Null comparisons in kdb

pyq.versions()
PyQ 4.1.3
NumPy 1.14.3
KDB+ 3.5 (2018.04.25) l64
Python 3.6.5 |Anaconda, Inc.| (default, Apr 29 2018, 16:17:00)
[GCC 7.2.0]

Generic null comparisons:
None from python should be converted to the kdb generic null which is ::
However, the comparison
K(None)==q(‘::’)
returns False.
>>> from pyq import q,K
>>> q('null a:(::)')
k('1b’)
>>> q.a
k('::')
>>> q.a.null
k('1b')
>>> q.b=K(None)
>>> q.b
k('::')
>>> q('a=b')
k('1b')
>>> q('null a')
k('1b')
>>> q('null b')
k('0b’)
>>> q.b.null
k(‘0b')

>>> q.null(None)
k('0b')

(should be 1b)
will be fixed in the next release.
The reason for the strange behavior is that q's null only recognizes a singleton :: as null and
>>> K(None)._id() != q('::')._id()
True


Waiting for healthy container when HEALTCHECK is defined

What does this PR do?
Adds the ability to wait till the container is in healthy state reported through health status.
Why is it important?
In some situations, the container is in a running state, but the containerized application is not ready. HEALTHCHECK probe can be used to detect the state when application is ready - the healthy state.
How to test this PR
Tests have been added to verify the behaviour.

The build is failing because of
Expected: SortedSet<String> ["Dockerfile", "setup/setup.sh"]
Actual:   SortedSet<String> ["Dockerfile", "healthWaitStrategy/fail/.dockerignore", "healthWaitStrategy/fail/Dockerfile", "healthWaitStrategy/fail/empty_loop.sh", "healthWaitStrategy/ok/.dockerignore", ...]
  Stack Trace:
     at DotNet.Testcontainers.Tests.Unit.ImageFromDockerfileTest.DockerfileArchiveTar() in /home/runner/work/testcontainers-dotnet/testcontainers-dotnet/tests/Testcontainers.Tests/Unit/Images/ImageFromDockerfileTest.cs:line 39

How can I fix that?

The build is failing because of
Expected: SortedSet<String> ["Dockerfile", "setup/setup.sh"]
Actual:   SortedSet<String> ["Dockerfile", "healthWaitStrategy/fail/.dockerignore", "healthWaitStrategy/fail/Dockerfile", "healthWaitStrategy/fail/empty_loop.sh", "healthWaitStrategy/ok/.dockerignore", ...]
  Stack Trace:
     at DotNet.Testcontainers.Tests.Unit.ImageFromDockerfileTest.DockerfileArchiveTar() in /home/runner/work/testcontainers-dotnet/testcontainers-dotnet/tests/Testcontainers.Tests/Unit/Images/ImageFromDockerfileTest.cs:line 39

How can I fix that? The additional files are part of tests involving health check. Thanks

Either we add healthWaitStrategy to .dockerignore or move it into a subdirectory as you did with healthWaitStrategy.

The pipeline is not running the test report publishing step when previous step fails.


🛃 Ensure the correct packages are installed

If the version of osbuild in Fedora's repositories is newer than the one
that builds during the mock build step of the CI pipeline, this can
cause the wrong version of osbuild to be installed.
Download the RPMs from the mock build repository and install them from
a local directory to ensure they are always correct.
Fixes #824. 🥰
Signed-off-by: Major Hayden<EMAIL_ADDRESS>

The F31 integration test failed due to a failed download from the Fedora internal mirror, but that mirror is being removed in #826. Everything else in CI looks ok.

Why doesn't the repo priorities work? Seems important

From what I can tell, dnf is selecting the newest osbuild version from Fedora's repositories since it's newer than the one in the mock build repo.
 If I allow dnf to use all repos on the system, it chooses the newest osbuild from Fedora's repositories.
I'm still trying to figure out how that is happening.


URL preview rule support?

Describe the bug
I created a rule to re write https://xxx.com/abc to https://xxx.com/ using an If condition with uri_path and a Then condition of URL (Preview) and set with the URL path (I found this as an example on a Microsoft tutorial).
It seems to work fine, created through UI, but subsequent deployments of other applications that would add backends seem to fail.    Logs on ingress-azure-* indicate:
worker.go:62] Error processing event.network.ApplicationGatewaysClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="ApplicationGatewayRewriteRuleSetActionSetInRewriteRuleCannotBeEmpty" Message="ActionSet is a required field in a RewriteRule." Details=[]
It seems to me that it is not liking that preview rule and just stopping.  It doesn't add backends or anything subsequently.
To Reproduce
After deploying an application, add a rule as described above.
Ingress Controller details
worker.go:62] Error processing event.network.ApplicationGatewaysClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="ApplicationGatewayRewriteRuleSetActionSetInRewriteRuleCannotBeEmpty" Message="ActionSet is a required field in a RewriteRule." Details=[]
All I want to do is a simple nginx re-write rule:
Equivalent of:
nginx.ingress.kubernetes.io/rewrite-target: /$1
path: /some-path(.*)
Maybe there is another way to do this without the URL (Preview), but I'm having a hard time finding this.
Is there another way to create the above re-write rule?

For what it's worth to anyone else, I found out how to do this.
annotations:
appgw.ingress.kubernetes.io/appgw-ssl-certificate:
appgw.ingress.kubernetes.io/backend-path-prefix: /
kubernetes.io/ingress.class: azure/application-gateway
name:
namespace: default
spec:
rules:

host:
http:
paths:

backend:
serviceName:
servicePort: http
path: /*

If, for example, came in as https://myawesomeapp.com/accounts
It would redirect to the backend as https://myawesomeapp.com/
or
If, for example, came in as https://myawesomeapp.com/accounts/names
It would redirect to the backend as https://myawesomeapp.com/names
e.g. Preserves subsequent part of URL.
https://docs.microsoft.com/en-us/azure/application-gateway/ingress-controller-annotations


按照步骤走到运行docker这里卡住了，运行第一段build命令没反应，是不是docker的path什么问题？还是单纯因为arm不支持的问题？

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

docker 里运行的并不是arm 架构的程序。
没有具体的问题描述我很难解决你的问题。
docker 门槛高的话，可以不用，本地源码build即可，源码跟电脑是什么架构无关。


Attempt to use a CSV file failed

»cat resources.csv
Id,Region,Business Unit,Project,Owner,ApplicationService,environment
i-11111111111111111,eu-west-1,Commercial-and-Marketing,Loyalty,,Container,
i-22222222222222222,eu-west-2,Commercial-and-Marketing,Loyalty,,Container,
i-3333333333333333,eu-west-3,Commercial-and-Marketing,Loyalty,,Container,
» aws-tagger --csv resources.csv
Traceback (most recent call last):
File "/usr/local/bin/aws-tagger", line 11, in
load_entry_point('aws-tagger==0.6.1', 'console_scripts', 'aws-tagger')()
File "/Library/Python/2.7/site-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/Library/Python/2.7/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/Library/Python/2.7/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/Library/Python/2.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Library/Python/2.7/site-packages/tagger/cli.py", line 22, in cli
tagger.tag(csv)
File "/Library/Python/2.7/site-packages/tagger/tagger.py", line 151, in tag
self._tag_resource(tag_index, row)
File "/Library/Python/2.7/site-packages/tagger/tagger.py", line 161, in _tag_resource
resource_id = row[tag_index[self.resource_id_column]]
KeyError: 'Id'

This is likely due to the BOM if you exported this from Excel.. https://stackoverflow.com/a/17912811/407954

Created #6


[Feature][Connector-V2] StarRocks Source & Sink connector

Purpose of this pull request
add StarRocks Connector
https://github.com/apache/incubator-seatunnel/issues/3018
Description
The MySQL Jdbc connector is reused. StarRocks uses the MySQL protocol syntax.
added all datetype in e2e , refer to https://docs.starrocks.io/zh-cn/2.2/sql-reference/sql-statements/data-types/BIGINT

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[x] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

BTW, Usually, if it uses MySQL's protocol, then we don't need to add any IT or UT for this, it doesn't make much sense.

BTW, Usually, if it uses MySQL's protocol, then we don't need to add any IT or UT for this, it doesn't make much sense.

thinks，agree with you.


IndexDB filesystem provider does not support file watching

It looks like the IndexDB file system provider is not able to support watching:
https://github.com/microsoft/vscode/blob/f1d92e789602f9389114760636f21c1b6b91ec32/src/vs/platform/files/browser/indexedDBFileSystemProvider.ts#L229-L231
As a consequence, the storage implementation in the browser is unable to detect changes from other windows targeting global scope because it is using file watching for that purpose.
If we cannot support detecting changes from a different browser tab to the same IndexDB instance, then I think we have to close this "as designed".
//cc @sandy081

/duplicate
duplicate of https://github.com/microsoft/vscode/issues/107854

More info:
It seems IndexedDB is not having an API to listen to changes done in other tabs -
Open Issue: https://github.com/w3c/IndexedDB/issues/51
We need to have a workaround in our code to trigger changes.


How to I get round trip times in milli-seconds?

Hi friend,  You are done awesome job.
I want a info from you. How to get round trip times Minimum, Maximum and Average in milli-seconds

Currently this isn't implemented in the library but you can easily modify how you call the library to achieve this as follows:
    // Perform an asynchronous ping
    Ping.onAddress(ipAddress).setTimeOutMillis(1000).setTimes(5).doPing(new Ping.PingListener() {

      long noPings = 0;
      long totalPingTimeMillis = 0;
      long minPingTimeMillis = -1;
      long maxPingTimeMillis = -1;

      @Override
      public void onResult(PingResult pingResult) {

        if (!pingResult.hasError()){

          long timeTakenMillis = (long) (pingResult.getTimeTaken() * 1000);

          if (maxPingTimeMillis == - 1 || timeTakenMillis > maxPingTimeMillis) maxPingTimeMillis = timeTakenMillis;
          if (minPingTimeMillis == - 1 || timeTakenMillis < minPingTimeMillis) minPingTimeMillis = timeTakenMillis;

          totalPingTimeMillis += timeTakenMillis;
        }

      }

      @Override
      public void onFinished() {

        long averageTimeMillis = totalPingTimeMillis / noPings;
        // minPingTimeMillis;
        // maxPingTimeMillis;
      }
    });

In the next release I will add these ping statistics to the onFinished call

Thanks a lot for your immediate awesome response and it's working correctly.
And sorry for this disturb, I have another one request  :
Can I able to calculate Lost Packets in percentage?
Send and Received packets are I can get from .setTimes(5) method. 5 is may send and received packets. But calculate lost packets?

From the above example you'd just keep track the number of times the ping has an error. If we use the same code from the example above it would become:
// Perform an asynchronous ping
Ping.onAddress(ipAddress).setTimeOutMillis(1000).setTimes(5).doPing(new Ping.PingListener() {

  long noPings = 0;
  long noLostPackets = 0;
  long totalPingTimeMillis = 0;
  long minPingTimeMillis = -1;
  long maxPingTimeMillis = -1;

  @Override
  public void onResult(PingResult pingResult) {

    noPings++;

    if (!pingResult.hasError()){

      long timeTakenMillis = (long) (pingResult.getTimeTaken() * 1000);

      if (maxPingTimeMillis == - 1 || timeTakenMillis > maxPingTimeMillis) maxPingTimeMillis = timeTakenMillis;
      if (minPingTimeMillis == - 1 || timeTakenMillis < minPingTimeMillis) minPingTimeMillis = timeTakenMillis;

      totalPingTimeMillis += timeTakenMillis;
    }
    else{
      noLostPackets++;
    }

  }

  @Override
  public void onFinished() {

    long averageTimeMillis = totalPingTimeMillis / noPings;
    // minPingTimeMillis;
    // maxPingTimeMillis;
    // noLostPackets;
   // Example calculation of packet loss in percent
    float packetLossPercent = (100.0 * noLostPackets ) / noPings
  }
});

Note that it keeps track of the number of pings inside the PingListener rather than just using the value set in setTimes(..). This is in case you call cancel while the ping command is running and onFinished is called before achieving the number of pings requested.
Thanks

I tried to convert long values to two digit milliseconds But it not working. I tried many ways to get two digit like 23.34 ms. please help me to convert this.
long minPingTimeMillis;   long maxPingTimeMillis;
String.format("%.2f ms",minPingTimeMillis)

A long doesn't have any decimal places, which is probably why you are struggling.
String.format("%d ms",minPingTimeMillis)
If you want decimal places, I'd suggest using a double instead.

sorry for this late thanks,  And I never forgot your immediate response of my questions. Thanks and God Bless

tks


Write ERD for multiple registry support

Create an ERD to cover the following workflows

Supporting multiple registries and the user experience
Upgrade process of charts between two registries
Migration from current registry to new registry
Airgap use cases

@PennyScissors Please check with @aiyengar2 for any issues you face while handling this and also with @rosskirkpat if you have questions with how he plans to add new “product registry” that apps/charts can use


Consider separating as-cell-summaries by laterality

If we end up slicing by scenegraph node, laterality would be taken car of as part of that (the laterality is part of the node's name)

For indexing/querying purposes, would it be better to have an additional, explicit field with the laterality? Might be hard to find/parse if it is embedded in a string.

Maybe, but you should be able to do a graph query to go from the scenegraph node (which could be the URI of the Spatial Entity) and then get the laterality from the reference organ it's part of.


Nessus error

Nessus server returned error code: 500
Message: Can't connect to <IP_ADDRESS>:8834 (certificate verify failed)
SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/share/perl5/vendor_perl/LWP/Protocol/http.pm line 46.
3 retries left
Sleeping for 30 seconds before retring
Nessus server returned error code: 500
Message: Can't connect to <IP_ADDRESS>:8834 (certificate verify failed)
SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/share/perl5/vendor_perl/LWP/Protocol/http.pm line 46.
2 retries left
Sleeping for 30 seconds before retring
Nessus server returned error code: 500
Message: Can't connect to <IP_ADDRESS>:8834 (certificate verify failed)
SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/share/perl5/vendor_perl/LWP/Protocol/http.pm line 46.
1 retries left
Sleeping for 30 seconds before retring
Nessus server returned error code: 500
Message: Can't connect to <IP_ADDRESS>:8834 (certificate verify failed)
SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/share/perl5/vendor_perl/LWP/Protocol/http.pm line 46.

what is the issue?
I cant start nessus with seccubus. Everytim if i run the scan, i get this message

What OS are you using? This seems to be an OS specific thing.

@seccubus i use Fedora

@seccubus do you have an idea?

Seen that too on Debian, despite --nosslverify was specified.

@seccubus  @arkenoi yes i try it with --nosslverify too, the message is just the same.

O.K. this took quite a bit of digging, but here comes the explanation:

The fact that setting $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} completely disabled SSL checking was actually a bug,and it should just have disabled host name mismatches.
Now operating systems are picking up a 'repaired' version of the library and thus the behaviour changed.
Instead I should be setting ssl_opts => { SSL_verify_mode = 0 } when creating the user agent object

Kudo's to https://bugs.launchpad.net/ubuntu/+source/libwww-perl/+bug/1408331 and negative kudo's to all the wrong answers that come out of Google.


ECONNRESET ErroNo -4077 or incorrect processinf

Recently setup Tuya IoT app and now get one of two results on restarting the service.
result 1
all devices are dumped in the debug log but the main log in homebridge says it can’t find devices.
results 2 (more common)
I see an ECONNRESET error with an axios connection dump. On examination it’s clear the result json is empty.
in setting this up I’ve experiencing the same issue as others, the video guide and text guides show a different set of services in the Tuya cloud config. Rather than adding device management as a services I’m having to add IoT Core. That service only has a 30 days trial, rather than the q year quoted.
I’m disappointed that the official docs don’t seem to be getting updated to reflect how this should be configured and that there’s nothing more than an axios dump and no meaningful analysis of the response.

@Mojinxo have you managed to solve the issue? Experiencing something similar at the moment.

Sadly Not. I had to just abandon it.DreOn 22 May 2023, at 22:37, Aleksei Chernov @.***> wrote:
@Mojinxo have you managed to solve the issue? Experiencing something similar at the moment.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Figured it out, it seems like my ISP is blocked by Tuya API for some reason.
Tried to connect over VPN and it works now.


unexpected reconnect & socket closed event

[2020-05-15T11:44:09.042Z][DEBUG][Dinocord] [WSClient@**] RECV::OP::ACK
[2020-05-15T11:44:40.657Z][DEBUG][Dinocord] [WSClient@**] RECV::OP::DISPATCH::PRESENCE_UPDATE
[2020-05-15T11:44:40.659Z][DEBUG][Dinocord] [Client@vdk#1255] ___UNHANDLED___DISPATCH::PRESENCE_UPDATE
[2020-05-15T11:44:50.164Z][DEBUG][Dinocord] [WSClient@**] SEND::OP::HEARTBEAT
[2020-05-15T11:44:50.289Z][DEBUG][Dinocord] [WSClient@**] RECV::OP::ACK
[2020-05-15T11:45:10.778Z][DEBUG][Dinocord] [WSClient@**] ___UNHANDLED___RECV::OP::RECONNECT
[2020-05-15T11:45:20.785Z][INFO][Dinocord] [WSClient@**] Socket closed.

Happens randomly, without any errors or anything. Service stays up, but bot goes offline.
Do i need to implement reconnect or is it going to be handled here?

Dinocord doesn't attempt a reconnect at this stage of the project. As for the process continuing to run, that's an issue with my async code.


ResourceManager -> ObjectManager

The ResourceManager type is split into an interface (ObjectManager) and implementing struct (UpdatingObjectManager).
Backwards compatibility is preserved with a number of deprecations, including:

ResourceManager is deprecated in favor of ObjectManager for a generic type, or UpdatingObjectManager.
AggregateReconciler.{HarmonizeImmutableFields, MergeBeforeUpdate, Sanitize} are deprecated in favor of AggregateReconciler. AggregateObjectManager.
ChildReconciler.{Finalizer, HarmonizeImmutableFields, MergeBeforeUpdate, Sanitize, SetResourceManager} are deprecated in favor of ChildReconciler.ChildObjectManager.
ChildSetReconciler.{HarmonizeImmutableFields, MergeBeforeUpdate, Sanitize} are deprecated in favor of ChildSetReconciler. ChildObjectManager.

Other strategies can be provided in the future, like replacing Update() calls with server-side apply.

@mamachanko ready for review. Keeping as draft until I can test with more existing controllers to ensure compatibility.


Implement closePlayerGame in contract

Description

Let the user "close" a game by removing it from the gamesOfPlayers[player] list, but only if the game is not currently running. A game is running if it has two players and no draw/checkmate occurred.

+ Changed structure of gamesOfPlayers to a "stack" (like openGames).
Related Issue

#82 Implement closePlayerGame contract function
How Has This Been Tested?

I provide multiple tests
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist contributor:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Checklist reviewer:

[x] The code has been peer-reviewed by @graup

Looks good.


Support datetime.date type as valid timestamp in datastore

Closing this given our ndb plans. This is really something at the ORM level.


Document say "Enterprise Read-Only Domain Controllers" group is replicated Forest Wide, is this correct?

Hello
I always thought objects in the Domain Naming Context (default naming context) were replicated Domain Wide only. However I see the document says the Group "Enterprise Read-Only Domain Controllers" is replicated Forest Wide, how does this work, if the group in contained within the Domain partition?
If it is replicated Forest wide and you have a Forest which contained 3 Domains. each domain had its own "Enterprise Read-Only Domain Controllers" ? then would this group in each domain contain the RODCs from the other Domains in the forest?
Or is there only one "Enterprise Read-Only Domain Controllers" in the Root Domain and all other Domains in the Forest do Not contain the a group named "Enterprise Read-Only Domain Controllers" ?
Can you please clarify this for me as it is a bit confusion
Thanks
CAshtones

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 08d36e64-91bd-e204-c1ff-2ba5848a71af
Version Independent ID: 7b7d6e29-a96e-1ed8-2d04-0fedde78f68a
Content: Appendix B - Privileged Accounts and Groups in Active Directory
Content Source: WindowsServerDocs/identity/ad-ds/plan/security-best-practices/Appendix-B--Privileged-Accounts-and-Groups-in-Active-Directory.md
Product: windows-server-threshold
GitHub Login: @billmath
Microsoft Alias: billmath

Sending note to PG for feedback

#in-progress

From the product group...
Because ERODC is a universal group, it is allowed to have accounts from any domain in the forest as members of the group.    The actual RODC accounts themselves still live in their respective domain NCs.

#please-close


Android emulator after MacOS wakes up

Steps to Reproduce
Android emulator looks great, then I put the screen to sleep and walk away. When I return, it looks as you see it. It has forgotten size/scale.

I don't think this is a Flutter rendering issue. Even system UI elements are resized. Are you on a retina display maybe (though I don't see how we can do anything about it)?
@741g might have thoughts on this.

Have we been able to reproduce this?

it also happens to me. if you want to know other step to reproduce, you can unplug external monitor and those scaling issues will occur.

There isn't much we can do in the Flutter engine as this is an Android emulator issue. I found https://developer.android.com/studio/report-bugs#emulator-bugs that has instructions to file bugs against that tracker.


Add the NuGet package name into the text

Add the NuGet package name into the text to avoid the need to click through to get the package name :-)

Great idea, thanks!


Deploying Issue

Can't deploy the page. White page that reflects the content of the README section.

Issue has been resolved through the removal of the main: index.html in package.json


fix(dialogs): themeing support for Teams dark and hc

Warnings

:warning:
There are no updates provided to CHANGELOG. Ensure there are no publicly visible changes introduced by this PR.

  Generated by :no_entry_sign: dangerJS


typia/zod support

any chance?

I have this consideration I have previously with Zod/io-ts/typia.
For one, I want to put out as fast as possible while still balancing with Quality of Life, Typia introduce has 2 mature problems that make me not support Typia (at least for now).

It shouldn't only just check the type, the reason I pick TypeBox is that it also supports OpenAPI Schema which is important to make a standard production-grade REST API server, and the ability to specify server specs and generated documentation of fly.

Many have asked why Elysia uses type box instead.

Typebox is built around OpenAPI which made the Swagger plug-in possible.

Typia requires an additional setup step and forces the developer to go TypeScript-only.

The cost of adding an extra union type to support End-to-End type safety is likely very high and complex, for one to make this full type-safety work, Elysia is using depends on LocalHandler, LocalHook, ElysiaRoute TypeRouteToEden, and CreateEden which is highly a complex type consist of over 600 loc for typing only, at the moment the type inference isn't as fast as it should be but if we manage to add one more union type for Typia, it's likely to have a problem with the performance of type inference.

And in regard to performance, seems like TypeBox is experimenting with AoT compile to improve performance
Summary
We may support Typia someday or might not support Typia at all (depending on the situation that may on fold in the future), but for now we have no interest or priority to support Typia at moment, and if we have to support 2nd validation library one day, it's likely that Zod will be our priority next.
Will leave this issues open for a week, feels free to ask more question if the answer is not cleared or if you have more questions want to ask, feels free.

very satisfying answer, thanks @SaltyAom !
I also wasn't thrilled with the ttsc business and very much enjoyed my approach to typebox and zod.
thanks for all your work and generosity!

Whilst Typebox for OpenAPI support is a nice 'feature', these days in terms full stack javascript development (elysia is node.js) it's not always needed given the focus on server actions which use typescript types, so adding validation to exsting types using typia I feel is a nice good solution.
I don't really see that big a difference DX wise from Typebox to Zod.

@SaltyAom  I've found the interesting repo: https://github.com/decs/typeschema for Universal adapter for TypeScript schema validation.
They support various type of data validation. It might be help.

I don't really see that big a difference DX wise from Typebox to Zod.

Unfortunately, there is a difference in DX... The TypeBox does nothing more than the JSON SCHEMA allows itself to do
Zod has excellent chainable validators/transformers, which greatly simplifies development

By the way, there is an interesting alternative to Zod - Valibot (Site, Github)

FWIW Zod type-checking performance has historically been pretty poor as projects increase in complexity. However, I have not checked on a real-world project lately. Most recent deep dive I've found -> https://dev.to/nicklucas/typescript-runtime-validators-and-dx-a-type-checking-performance-analysis-of-zodsuperstructyuptypebox-5416

It's impressive! But we need to make sure that we don't lose anything from integrating this
and what if elysia has its own contribution to the type system
t.Object({
    avatar: t.File({
        type: "image",
    }),
}),

I'm not ready to give it up! It's too convenient

I don't really see that big a difference DX wise from Typebox to Zod.

Two things that "jump out" at me are:

branded types

const NonEmptyString = z.string().min(1).brand("NonEmptyString");
type NonEmptyString = z.infer<typeof NonEmptyString>;

const greet = (s: NonEmptyString) => z.string().min(1);

This sort of approach is handy for protecting your system from invalid data at the type level.

ubiquity... Not to say that this alone should be a deciding factor, but a tool's popularity can be a benefit

Saw the trpc plugin and decided to give elysia a go, sure enough spotted the "compile" import in the example only after hitting a type error passing zod schemas to the procedures. Definitely a non-starter, would have been an instant switch from fastify otherwise. Even for a greenfield project like this, many folks already have their big bag of zod tools and patterns they would like to slingshot a new project with. For example https://github.com/chrishoermann/zod-prisma-types is alone responsible for dozens if not hundreds of hours saved during prototyping phase. The switch over to a proprietary type is a tall ask and definitely stunts this project.
Sorry, I know how this probably reads, but I've a good feeling that many people are not bothering to say anything and instead have just gone to use something else.

@medv 's sentiment:

Definitely a non-starter, would have been an instant switch from fastify otherwise.

This is an anecdotal scenario of why ubiquity can be meaningful.

(not to mention react-hook-form and its zodResolver on the other side).
To their point... what's stopping this from being an extensible interface? (besides the obnoxiousness that might come from some additional generic typing)

https://github.com/turkerdev/fastify-type-provider-zod
Can this be of any help?
This package can create swagger docs using all Zod schemas and Fastify, would an implementation like this solve the issue of generating the open API schema?

https://typia.io/docs/setup/#unplugin-typia
https://github.com/ryoppippi/unplugin-typia/tree/main/examples/bun-build
Typia can now be used in Next.js and Bun environments.
While supporting extra union types for End-to-End type safety is challenging, validation can be done before the request.

Closing as not planned at the moment, however feels free to continue to discussion or open a new discussion in the discussion tab.
Thanks.

@SaltyAom the reason I'm keen for Zod support is being able to do cross-field validation.
Is there any possible way to do the following in Elysia atm?
t.Object({
  max: t.Number(),
  min: t.Number({ minimum: 0 }),
})

validate that minimum is less than maximum and that maximum is less than minimum at runtime?

Ahh I just saw beforeHandle in the docs 👍🏼

Here it remains only to use the type box or write your own validator/serializer, which will be completely covered by types and JsonSchema last draft(2020-12) + OpenAPI 3.1.0 support.

In a framework that works like magic, it's sad to write validations manually. It's even sadder that by far the most upvoted issue is marked as wontfix.
Hono has Typia support but OpenAPI support is not sufficient. I don't know what to do 🤷♂

It shouldn't only just check the type, the reason I pick TypeBox is that it also supports OpenAPI Schema which is important to make a standard production-grade REST API server, and the ability to specify server specs and generate documentation of fly.

I can't say anything about other reasons, you're probably right, but I should specify that Typia has a JSON Schema generation feature: https://typia.io/docs/json/schema/
It can even derive descriptions and rules from interfaces directly.

The creator of Zod has proposed a Standard Schema API for libraries to support instead of a single validation library.
Currently, Arktype, Valibot, and Zod support the Standard Schema, but nothing is stopping others from adopting it.
List of current libraries consuming it: https://github.com/standard-schema/standard-schema?tab=readme-ov-file#ecosystem

The creator of Zod has proposed a Standard Schema API for libraries to support instead of a single validation library.
Currently, Arktype, Valibot, and Zod support the Standard Schema, but nothing is stopping others from adopting it.
List of current libraries consuming it: https://github.com/standard-schema/standard-schema?tab=readme-ov-file#ecosystem

Seems interesting

Issues like this one make me feel like TypeBox is just not at all designed for UX, instead it focuses solely on performance whilst checking and parsing data.
Most use cases for me and anyone working on web apps will be form validation with custom error messages and i18n. I really think that Zod should be considered for a project like Elysia, since it's mature and well designed for custom error messages and form validation.
Looks like someone worked on a branch to try this out https://github.com/Savolus/elysia-with-zod

Issues like this one make me feel like TypeBox is just not at all designed for UX, instead it focuses solely on performance whilst checking and parsing data.
Most use cases for me and anyone working on web apps will be form validation with custom error messages and i18n. I really think that Zod should be considered for a project like Elysia, since it's mature and well designed for custom error messages and form validation.
Looks like someone worked on a branch to try this out https://github.com/Savolus/elysia-with-zod

Typebox designed for perfomance and JSON Schema Builder
I guess our community can create new one validator that aims DX and perfomance
a lot of things of DX can be JIT'ed to improve perfomance

need this!

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

Try passing in a raw TypeBox schema not built with t.

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

Try passing in a raw TypeBox schema not built with t.

it is because elysia uses -1 major of typebox)

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

Try passing in a raw TypeBox schema not built with t.

it is because elysia uses -1 major of typebox)

I'm...not following? My point was that I would need to import { t } from "elysia" everywhere in my application in order to build Elysia-compatible TypeBox schemas. If this is incorrect, then please show me where I'm mistaken. I want to be mistaken. TypeBox is great in it of itself because it's generic. Can work with any web framework―I can make it work with Express, Fastify, Hono, etc. Elysia.t is exclusive to Elysia. I would be coupling my entire codebase to Elysia.

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

I would rather use @sinclair/typebox as the dependency in my code and then use the schemas defined with @sinclair/typebox with Elysia. NOT the other way around.

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

I would rather use @sinclair/typebox as the dependency in my code and then use the schemas defined with @sinclair/typebox with Elysia. NOT the other way around.

Override typebox version in elysia

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

I would rather use @sinclair/typebox as the dependency in my code and then use the schemas defined with @sinclair/typebox with Elysia. NOT the other way around.

Override typebox version in elysia

… Can you elaborate be more specific? As I said in my original comment, I tried to make this work and I tried various things. It’s not so trivial.

@enriquecaballero-agx @enriquecaballero @kravetsone @jasperdunn @rjzheng

I hope a Zod to Elysia.t adapter becomes available at some point.

A new TypeBox project is now available, allowing you to integrate Zod and Valibot into Elysia. This project transforms Zod and Valibot types into TypeBox-compatible schematics (i.e., JSON Schema), enabling acceleration by the TypeBox compiler (matching TypeBox's speed) and compatibility with OpenAPI/Swagger.
Project: https://github.com/sinclairzx81/typebox-remix

Example
The following creates an Elysia route and configures parameters using TypeBox, Zod and Valibot. Type inference is preserved.
TypeScript Link Here
import { Box } from '@sinclair/typebox-remix'

import { Elysia, t } from 'elysia'
import z from 'zod'
import v from 'valibot'

new Elysia()
  .get('/remix', ({ params, query, body }) => {
    const { x, y, z } = params // from TypeBox
    const { a, b, c } = query  // from Zod
    const { s, t, u } = body   // from Valibot
  }, {
    params: t.Object({
      x: t.String(),
      y: t.Number(),
      z: t.Boolean()
    }),

    query: Box(z.object({
      a: z.string(),
      b: z.number(),
      c: z.boolean()
    })),

    body: Box(v.object({
      s: v.string(),
      t: v.number(),
      u: v.boolean()
    })),
  })
  .listen(3000)

This project is ongoing, with work continuing through 2025. I anticipate additional updates will be required when Zod 4 is released, and there are considerations to include other libraries like EffectTS in the future. If you use this project, feel free to submit issues or provide general feedback.
Hope this helps
S

@enriquecaballero-agx @enriquecaballero @kravetsone @jasperdunn @rjzheng

I hope a Zod to Elysia.t adapter becomes available at some point.

A new TypeBox project is now available, allowing you to integrate Zod and Valibot into Elysia. This project transforms Zod and Valibot types into TypeBox-compatible schematics (i.e., JSON Schema), enabling acceleration by the TypeBox compiler (matching TypeBox's speed) and compatibility with OpenAPI/Swagger.
Project: https://github.com/sinclairzx81/typebox-remix
Example
The following creates an Elysia route and configures parameters using TypeBox, Zod and Valibot. Type inference is preserved.
TypeScript Link Here
import { Box } from '@sinclair/typebox-remix'

import { Elysia, t } from 'elysia'
import z from 'zod'
import v from 'valibot'

new Elysia()
  .get('/remix', ({ params, query, body }) => {
    const { x, y, z } = params // from TypeBox
    const { a, b, c } = query  // from Zod
    const { s, t, u } = body   // from Valibot
  }, {
    params: t.Object({
      x: t.String(),
      y: t.Number(),
      z: t.Boolean()
    }),

    query: Box(z.object({
      a: z.string(),
      b: z.number(),
      c: z.boolean()
    })),

    body: Box(v.object({
      s: v.string(),
      t: v.number(),
      u: v.boolean()
    })),
  })
  .listen(3000)

This project is ongoing, with work continuing through 2025. I anticipate additional updates will be required when Zod 4 is released, and there are considerations to include other libraries like EffectTS in the future. If you use this project, feel free to submit issues or provide general feedback.
Hope this helps S

Fine! But i guess remix not so good name because react-remix))
also did u want to work on new validation library? Like Typebox but with more DX and JITed
Like Zod but really faster (for example compile string().maxLength(8, "error").trim() to a function)
JSON schema needed but can be generated by remappers from internal

@sinclairzx81 Do you think there will be a chance to add Typia support in the future?

typia support is hard
because it AOT with builder plugin

I’m currently converting schema() function output (which is JSON schema) to Typebox schema. But the lack of first-party support bothers me.

@kravetsone Hi,

Fine! But i guess remix not so good name because react-remix))

I agree. Remix was the working title used during development, but I guess it's not as descriptive as it could be. I have republished under a the more formal name @sinclair/typebox-adapter.
github: https://github.com/sinclairzx81/typebox-adapter
npm: https://www.npmjs.com/package/@sinclair/typebox-adapter
Thanks for the feedback :)

@kravetsone Hi,

Fine! But i guess remix not so good name because react-remix))

I agree. Remix was the working title used during development, but I guess it's not as descriptive as it could be. I have republished under a the more formal name @sinclair/typebox-adapter.
github: https://github.com/sinclairzx81/typebox-adapter
npm: https://www.npmjs.com/package/@sinclair/typebox-adapter
Thanks for the feedback :)

Great!


.github/workflows/release.yml

Fixed grammatical errors

@Tienisto I fixed some grammatical errors but the branch has some conflicts.

You need to rebase on the latest main commit


Not all sections of exported console file are ANSI-encoded

When pytest --fold is run, the output (just like with regular pytest output) is color-coded depending on if tests are pass/fail/etc. But when the output from a --fold run is examined (filename: console_output.fold), the only sections that are ANSI-encoded are the individual failed test cases details, and the final line of the output.

Fixed in f5a5809..99ffe40  main -> main


Asking for input async

Use case:

User calls (call center)
We redirect him to one of our customer agents (with dial, list of agents is given)
Just before we redirect him we say "press 1 if you are waiting too long, and want to leave a message"
Either the dial connects (and we ignore any 1 presses afterward)
Either the user presses 1 during the dial. We want the dial to stop immediately and start recording
Either the dial times out, we ignore any 1 presses and just continue the controller.

Currently, this seems not possible as both dial and menu/ask are synchronous and don't seem to have any callback methods to implement this. Unless I am missing something
Is this possible to implement somehow with the current infrastructure, or would adhearsion need to be changed?

This sounds like a great use case for Matrioska (https://github.com/adhearsion/matrioska) -- it adds in the asynchronous components you're searching for and should allow you to achieve all the above described states.

I think it is possible to do this but you have to go a little lower level. If you look at what the dial and menu/ask actually do, you'll see that they are actually asynchronous under the hood.


SAM macro with workspaces

This is a draft change to use NPM Workspaces and hopefully simplify the monorepo tooling and challenges with building the serverless plugin and CloudFormation macro (with SAM).
I would recommend removing all node_modules directories before npm installing and building or deploying.
Because SAM copies only the based directory and not sibling directories (required for workspace dependencies), SAM has to be run from the root folder with:
sam build --base-dir . --template-file cf-macro/template.yaml

Changes:

Use NPM workspaces
Remove lerna usage and tooling
Ignore node_modules/ in Docker in case SAM uses Docker (--use-container)
Remove unnecessary slic-watch-core dependency in root
Install workspace dependencies with:

npm install slic-watch-core --workspace=serverless-slic-watch-plugin --save
npm install slic-watch-core --workspace=cf-macro --save

Coverage remained the same at 100.0% when pulling 5c006469b0c1bd32477d8a2f0e81e98dcd2f53d7 on sam-macro-with-workspaces into 45904989a7e1951db79d6677faa17fb03222dc44 on main.


API request client-side throttling

What happened?
After installing and running provider-aws alongside Crossplane the API start throttling and slowing down the requests
and showing:
I1210 12:45:57.240716   71637 request.go:665] Waited for 1.196258171s due to client-side throttling, not priority and fairness, request: GET:https://api.k8s.<redacted>.io/apis/cloudwatchlogs.aws.crossplane.io/v1alpha1?timeout=32s

How can we reproduce it?
It happens by just installing provider-aws in a cluster. It immediately goes aways once the provider is remove it.
What environment did it happen in?
Crossplane version: v1.5.0
Provider-aws: v0.21.2
Kubernetes: 1.20.11
Any ideas on how we could solve this?

Related to https://github.com/crossplane/crossplane/issues/2649 and https://github.com/crossplane/provider-aws/pull/1076

in general an Kubernetes issue - please Check references Crossplane issues for enhancements with the beginning of Kubernetes 1.23

Hi users,
Any idea how to resolve this issue ? I am getting the same error running on EKS 1.21 with Crossplane v1.9.0
Kind regards,

Same. Degradation on EKS API across all the clusters. Not happening when crossplane is removed

Still facing the issue

Seeing this in RKE2 1.26 and even in some pods in-cluster that have to make api requests


Crash on savegame load

Hi,
Two days ago I downloaded the latest version of ME3 from Origin, that I bought four years ago ( Deluxe Edition ), and I was trying to install this patch in order to get some ASI loaded. Although when I am trying to start the game, I get a KernelBase.dll crash.
This is the stack trace I can get from the Windows Event Collector:
<EventData>
  <Data>MassEffect3.exe</Data>
  <Data>1.5.5427.124</Data>
  <Data>50d4cab0</Data>
  <Data>KERNELBASE.dll</Data>
  <Data>10.0.14393.321</Data>
  <Data>57f4c291</Data>
  <Data>e06d7363</Data>
  <Data>000da6f2</Data>
  <Data>24e4</Data>
  <Data>01d249cb5e4e9c94</Data>
  <Data>G\Origin Games\Mass Effect 3\binaries\Win32\MassEffect3.exe</Data>
  <Data>C:\WINDOWS\System32\KERNELBASE.dll</Data>
  <Data>8d5b31e7-f6f9-4b09-bd8e-b0f515381af0</Data>
  <Data />
  <Data />
  </EventData>

I googled already online to see if this is not related to this project, but maybe some other environment conditions: many pointed to Drivers issues, other to compatibility ( I tested Windows XP compatibility but crashes exactly in the same point ) and so on. Anyway nothing helped so far.
What I tested until now is loading my last save state ( finished 100% ) and this crash happen. While if you start a new game everything is working fine. Do you have any experience about this that can maybe help me to better understand what is happening?
I also tried to use WinDbg for debugging after crash, but it's basically the same stack-trace that you can get from Windows Log Collector. So I have no more ideas on how to go far with this.
Thank you in advance,
Julian

So... is it related to binkw32 patch or not? Does the game load the save file without crashing while using the original binkw32.dll?

What I discovered until now:

NON-ORIGIN game, with the patch and my savegame files works totally fine

ORIGIN game, with the patch and my savegame files DOES NOT work.

It seems that something is not being well patched on Origin? I'm not really sure. I'm still doing some more proper testing. Any idea how can I enable more verbose logging on why the crash is happening?

Nevermind, I found the issue: the DLC I was having in the folder did not support the Italian language. If I set the game in English, then it works.
Sorry for the false alarm :)


fix reservable autocluster cleanup on undo

Testing found an issue with the cleanup of a reservable autocluster created during CreateAppInst, if the AppInst create failed. The problem was that the AppInst API finished before the cluster was fully deleted. This caused subsequent tests to fail.
The problem stemmed from the streamObj handling. When the AppInst create fails, it sets the undo flag on the context and calls deleteClusterInstInternal. The undo flag triggers streamStart() to try to reuse the existing stream, but this process did not carry over the crmMsgCh. Without the crmMsgCh, the call to WaitForCloudletInfo in deleteClusterInstInternal returns early, instead of waiting until the clusterinst is deleted.
Using the Undo flag is tricky, because in this case, the stream is technically not resuable by deleteClusterInstInternal, because we are actually undoing the AppInst create. The stream used by createClusterInstInternal to create the autocluster was already finished, and the only stream present is the AppInst stream. So, we now track streams by their streamKey on the CallContext. This allows stream reuse to trigger off the presence of the stream to reuse, rather than the undo flag.
Because crmMsgCh is not really optional to the WaitFor funcs (there's no point in calling it if the channel is nil), I've made it a required parameter instead of optional.

Yeah it was a bit annoying to debug...but a slew of debug prints always works :)


Update audio_waveform.dart

fix bug

@alireza-hnzpv Could you please provide details on the bug this change fixes?

When the music ends, the present time of the music is equal to the end time of the music. That's why it shows an error when the music ends.


Some inter-/extrapolation rules are not processed

Inter-/extrapolation rules specified in syssettings are not processed.

Need to address #83


Am I able to put a gif in the panorama scenery? - Question

Much like how we are able to put images in as custom hotspots, can we put Gifs in and have them in motion? As in playing but not moving along with the viewport?

I'm not really sure what you're asking. Your can set a custom hot spot to be a GIF the same way you can make it a still image.

Hi again!
It seems as though the way I was referencing the gif was totally wrong, and the size of the gif asset needs to be readjusted. Thanks for the response though.
Malcolm


Update request: vcv-rack 2.4.0 → 2.4.1

Package name: vcv-rack
Latest released version: 2.4.1
Current version on the unstable channel: 2.4.0
Current version on the stable/release channel: 2.3.0
[X] Checked the nixpkgs pull requests

Notify maintainers
@nathyong
@jpotier
@ddelabru
https://github.com/VCVRack/Rack/blob/v2/CHANGELOG.md#241-2023-08-24

Note for maintainers: Please tag this issue in your PR.
Priorities
Add a :+1: reaction to issues you find important.

@Kranzes may be trying something with https://github.com/NixOS/nixpkgs/pull/270241 so I'll wait a bit

Honestly I have no idea what vcv-rack is, I just looked for a package I can update to test out a new feature for `nix-update. If you can, take this from from, feel free to update it.

Not sure if I'll have time in the next few weeks, so this is free to pick


Wrong "use in Transformers" wigdet for models with remote code

As seen in this model, the widget that shows how to use the model in Transformers has some wrong code. This seems to be the case for any model with remote code.
For those models, the architecture field will show the name the user picked for their model and should probably be replaced by what can be found in the auto_map key of the config, which will contain the right auto class. Additionally, trust_remote_code=True should be added in the snippet of code (otherwise an exception will be raised by Transformers).

This is fixed now


Automate the Config Creation Process

After some trial and error, I have begun a workflow which will automatically create a PR for new config files after someone files the templated issue form to create them.
Steps:

deployer fills out a templated issue
creation/update of issue launches workflow that:

converts the issue to a json file
submits a PR to add the json file to our repo

TBD workflow for ensuring the PR is valid
We check the PR for validity and merge into repo

check that it is a valid deployment (not an attack)
check for associated "promised" files like onboarding survey, labels, or trip survey
may need to do some work by hand for some custom nitty gritty (still working out form templating for trip survey or custom reminder scheme cases)

This is in an early draft stage, as I still have things to work out:

[x] make sure the workflow only goes when the templated issue is filed, not a normal issue
[x] ask about config fields I was unsure about
[ ] handle custom trip surveys
[ ] handle custom reminder schemes
[ ] set up validation (currently some degree by nature of the parsing process (won't work if things are missing), but I want to investigate testing it out)
[ ] write documentation for workflow and potential need to update the workflow

Related Issue

More form updates as I practice using this in my local repo:

[ ] set a default of false to trip end notifications
[ ] set autogen and token_generate to both use the value of autogen (these need to match)

Note that issues were not enabled on this repo, and I had to enable them to (hopefully) get this to work.

Seems to work now - I can at least create an issue...

For the actions to run, I think you'll need to make sure that workflows are enabled and that they have permission to create pull requests

I am pretty sure that workflows are enabled.
wrt enabling creation of pull requests, I think you can use the `GitHub actions token" and enable pull requests on it
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
Do you want to create a test issue and see what it does?

It works! But is overzealous with the commits, I'll include a fix for that in my cleanup.
see the PR here


Team Issue

Theo
Haseeb
Ananya
Samarth
Ava
Alexa

https://github.com/h4seeb-cmd/turtle/issues/33
the style thing


complement the definition of '#'

in pattern rules, the definition of '#' applies to the whole list of nodes that are declared in the supvisors section of the supervisor configuration file.
it could be considered to apply '#'to a subset of these nodes by declaring something like:
#, subnode1, subnode2

fixed in dev-0.5 branch


Feature idea/improvement: allow dev server and build script to run in presence of TypeScript errors

This isn't a bug report, but rather an idea to make CRA's TypeScript setup more user-friendly, and more aligned with what I understand to be the "spirit" of TypeScript.
Currently, for projects built with npx create-react-app <app> --typescript, or migrated to TypeScript as per the docs, both npm start and npm build fail in the presence of TypeScript type errors.
The dev server refuses to serve the app if non-fatal type errors are present. The build script builds it just fine, but exits with a non-zero status. In other words, npm build outputs valid code to /build that can deployed to a production server, even as it tells the user that the app "Failed to compile".
Devs migrating a moderately sized CRA app to TypeScript may literally be faced with thousands of type errors initially. None of these prevents the app from running, either locally or in production, but devs have to correct or ignore every last error (not that easy, given the limitations of @ts-ignore)  before they can continue developing the app.
IMO this goes against TypeScript's philosophy of making the migration path from JS -> TS as easy as possible, and allowing devs to "progressively" add type annotations to their code.
TypeScript devs already have many options at their disposal to prevent deployment of code that has type errors, if they want to impose this constraint on themselves. CRA definitely shouldn't impose it on them.
At the very least, I think there should be an option to enable or disable this constraint. I understand that CRA's philosophy is to avoid config wherever possible. If adding an env var, e.g. TSC_COMPILE_ON_ERROR, is not desirable because it means more config, then I think the default behavior should be for CRA to function normally in the presence of type errors, while printing them as warnings to the terminal/browser console.
I opened a PR with changes that do exactly this. Looking forward to hear what people think!

Couldn't this be solved by setting your tsconfig with a more passive setting (like allowing compile on errors) and doing the compile before the build?
I haven't used TS w/CRA yet, but I'd imagine they are building from JS, rather than building from TS then compiling, but I could be wrong.

in which case you don't actually have your latest code in your build yet...

I definitely do.
You can write code that has type errors, save the code, and even see the updated app in the browser momentarily before the "Failed to compile" screen takes over.
And no, this isn't something that can be avoided by modifying tsconfig.json. Check out the PR if you want to, you'll see there's code, for example in react-dev-utils/WebpackDevServerUtils.js, that intercepts type errors and shows the "Failed to compile" screen if any are present.
If one changes this code to not show the "Failed to compile" screen, you can still see the type errors, but the code compiles just fine.

in which case you don't actually have your latest code in your build yet...

I definitely do.
You can write code that has type errors, save the code, and even see the updated app in the browser momentarily before the "Failed to compile" screen takes over.
And no, this isn't something that can be avoided by modifying tsconfig.json. Check out the PR if you want to, you'll see there's code, for example in react-dev-utils/WebpackDevServerUtils.js, that intercepts type errors and shows the "Failed to compile" screen if any are present.
If you change this code to not show the "Failed to compile" screen, you can still see the type errors, but the code compiles just fine (which means the "Failed to compile" message isn't really accurate anyway, but that's another, much less important issue).

I'm going to try this myself, just because I'm curious, but have you actually tried this by creating a new app using the command in the docs, instead of npx create-react-app cra-typescript --typescript?
The recommended method is npx create-react-app my-app --typescript.
https://facebook.github.io/create-react-app/docs/adding-typescript#docsNav

I would like to express my support for some more user-friendly way to deal with ts compilation errors. We have a very large typescript codebase so the experience we have right now is:

cra compiles js and app loads
10-15 seconds later, the screen gets covered by a non-dismissible overlay that shows a type error that could be as trivial as "unused import"
We fix the issue and have to wait for recompilation.

In addition to that scenario, we also get the issue of type errors that have already been fixed appearing as errors because the compiler is behind.
Any method to either allow the overlay to be dismissible or disable compilation failure on type error would be really great

I agree with most of this, in theory, but I question this approach (from the PR):
//  package.json
{
...
    "start": "echo 'REACT_APP_ENV=dev\nTSC_COMPILE_ON_ERROR=true' > .env && react-scripts start",
    "build": "echo 'REACT_APP_ENV=prod\nTSC_COMPILE_ON_ERROR=true' > .env && react-scripts build",
    "build-stg": "echo 'REACT_APP_ENV=stg\nTSC_COMPILE_ON_ERROR=true' > .env && react-scripts build",
...
}

Your command relies on bash (we can't assume someone won't be using sh or csh and echo doesn't always have the same behavior in different shells) and it also rewrites the .env file every time that command is run.
Writing echo > anything will overwrite the entire file with just anything, so each time you're rewriting the entire file, which means destroying what is there.
Since it's not appending (or checking if the .env parameter already exists), and because there is always a possibility of additional config in a user's environment being overwritten, I feel like that's a non-starter as its destructive and unpredictable.
Generally, that type of a command shouldn't be associated with a startup script. If it's not your intention to include that as a prereq to the PR, maybe that should be clarified in the PR.
I'd like to see an approach that's as simple as npm start --ts-ignore-errors that doesn't require modifications to the .env to run on a per-case basis, and maybe allows a modification to .env to make "permanent".  A simple flag argument shouldn't require modifying the .env, much less a destructive file write.

@methodbox
The code you put in your comment above is obviously not "from the PR".
It's from a comment in the discussion thread. Right before said code, the comment says this:

To test it out, you can just create a bare TypeScript app with npx create-react-app cra-typescript --typescript, then change the react-scripts dep as follows.

Sounds like it's a way to test the code in the PR.
As for "permanently" modifying .env, you could always create your own .env file, add TSC_COMPILE_ON_ERROR=true to it, then run npm start.

@kylebebak
There’s no need to be a jerk when also arguing semantics.
I was clearly referring to the “PR” including the comments.
My suggestion is that if you intend to make a change that requires an edit to the .env then:

This particular case seems like it would be a good place for a command line arg.

Maybe give that example of editing the .env in your PR COMMENTS (just want to be clear here) instead of the current PR COMMENTS which, while an example of how to test this, still include bad and possibly destructive practice.

This is really needed. Trying to migrate a .js app to .ts is a hard as it is, and cra overwrites compilerOptions is tsconfig.json if you try to edit them, so there is no solution going that way.

Personally I'd rather it did not ignore the error, unless I had acknowledged it and chosen to do so

That's what the option would do. We are acknowledging the errors are there. Our editors still show them, the console output will still show them, but we will be able to develop our apps. Developing is not a road without errors, forcing the overlay and preventing the build without an option to not do so is not helpful.

@cristianfraser
Just to clarify, the PR linked to in this issue doesn't ignore any errors. It does what you suggest -- it prints the errors to the terminal and to the browser console, but doesn't prevent the dev server from serving the app in the presence of TypeScript errors.

and cra overwrites compilerOptions is tsconfig.json if you try to edit them, so there is no solution going that way.

Also worth clarifying: even if CRA didn't overwrite compilerOptions, you wouldn't be able to solve this problem by writing your own.
There's nothing in CRA's compilerOptions that prevents TypeScript from compiling your TS files to JS. It compiles the files just fine, it just refuses to serve them. If you make a change to your source code and save it, you can even see the updated app in the browser momentarily before the "Failed to compile" screen takes over.
To solve this problem, you have to modify react-dev-utils/WebpackDevServerUtils.js, which is what is done in the PR.

2. 10-15 seconds later, the screen gets covered by a non-dismissible overlay that shows a type error that could be as trivial as "unused import"

This is the annoying part. You might want 'noImplicitAny' or 'noUnusedImports' to be strictly enforced during prod builds or code reviews, but having it show the error overlay with no way to dismiss it despite it being perfectly valid emitted javascript is frustrating.
It seems like the error overlay used to be dismissible at some point, or maybe its just not dismissible for typescript errors, but its a pain point either way.
The errors are already being printed in the terminal and the browser console, so having the option to dismiss or opt out of the overlay errors would be awesome.

@methodbox
It would be great to get some insight from a contributor on what the current thought process is for not making errors dismissible and what would be required to change that.

@jineshshah36
I’m a contributor but I’m certainly not a maintainer or owner of this package, but I’ll give my two cents, though I don’t think you’ll like it ;).
I’m wondering how exactly the process would go, just in matter of order of processing, to build the app but also have type errors.
The JS that is used for the build is first compiled from the associated TS files.
If you’re just writing TS (not inside a CRA project) and have the watch TS build task running, essentially what happens in CRA, you don’t get any JS files if your TS fails type checking unless you’ve configured your tsconfig in such a way to allow it. Even then, you don’t always get it to compile depending on the error.
My thought would be (as I said before) relaxing the tsconfig, and on the CRA side allowing certain errors, but the tsc or babel compilers aren’t going to care what CRA wants; they are going to fail to compile in instances where the would fail otherwise, unless excepted by tsconfig or some argument on the CLI.
CRA ultimately fails because files required to make the build, the JS not the TS fail to be generated, which is up to the compiler.
I’m still not clear why the OP would not be able to see TS errors before compile, since they are linted in the TS already; it would be obvious this is going to fail to compile.
The argument that migrating a project to TS is going to result in, basically, a lot of work fixing type errors begs the question why you would want to build the app from that instance vs the JS instance when you haven’t fixed any of the type issues?
In my experience, moving an app from JS to TS, the most common occurrence of type errors stems from two things: you haven’t installed the applicable @types package(s) and/or you haven’t imported the necessary types from those packages (less common as it’s usually detected.
I just migrated 8 screens and an API from RN to TS and these are the only issues I faced beyond some ambiguity which is (and shouldn’t be) allowed in JS and not in TS.

I'm not sure @jineshshah36 and I have the same concern as the OP actually.
Let's say you quickly prototype some function: const func = (x) => doThing(x) and then save. After a few seconds, CRA will have emitted the new perfectly valid javascript bundles. Now you're trying to test out the new function in the browser after your live-reload kicks in. Imagine you're clicking around on the page, and you're about to get to the point where you do whatever is necessary to trigger your function - you've already invested some time and effort. Suddenly the error overlay appears out of nowhere to complain that x in your function is implicitly typed as any (because the async type-checking process has just finished). The critical issue here is that there is no way to dismiss the error overlay.
The error overlay says "This error occurred during the build time and cannot be dismissed.", but it didn't occur during build time (since babel just strips the types before compiling/handing off to webpack - it actually happens during the async type checking), and it clearly can be dismissed (you can delete the overlay iframe using devtools, and the app would work fine in this case).
It's easy to say "just give x a type", but there are plenty of situations where its just not that simple (or you might come back to add types later after sanity testing your prototype).
IMO the overlay should only be non-dismissible if the actual babel compilation / webpack bundling process fails.

@methodbox I appreciate the thorough response! And yes, @MattMorrisDev is correct that is essentially the gist of the problem. We literally just want an "x" in the corner. If you think it makes more sense to open a separate issue and explain that, I'm more then happy to do that

I'm not sure @jineshshah36 and I have the same concern as the OP actually.
Let's say you quickly prototype some function: const func = (x) => doThing(x) and then save. After a few seconds, CRA will have emitted the new perfectly valid javascript bundles. Now you're trying to test out the new function in the browser after your live-reload kicks in. Imagine you're clicking around on the page, and you're about to get to the point where you do whatever is necessary to trigger your function - you've already invested some time and effort. Suddenly the error overlay appears out of nowhere to complain that x in your function is implicitly typed as any (because the async type-checking process has just finished). The critical issue here is that there is no way to dismiss the error overlay.
The error overlay says "This error occurred during the build time and cannot be dismissed.", but it didn't occur during build time (since babel just strips the types before compiling/handing off to webpack - it actually happens during the async type checking), and it clearly can be dismissed (you can delete the overlay iframe using devtools, and the app would work fine in this case).
It's easy to say "just give x a type", but there are plenty of situations where its just not that simple (or you might come back to add types later after sanity testing your prototype).
IMO the overlay should only be non-dismissible if the actual babel compilation / webpack bundling process fails.

Maybe the question should be (or the solution): should the in-browser errors even contain non-breaking TS compile errors at all?
I.E. if the page otherwise loads and the build is complete, should those errors ever bubble up to the on-page error, or should they be restricted to linting/problems log?
I know this is kind of what the OP is getting at, but I mean it really is a fundamental question of how CRA is handling errors in general; eslint errors that aren't breaking don't necessarily cause this kind of an issue.
On the other hand, the any type warning should be seen in-editor before you ever build. If you truly want to ignore this, isn't that the responsibility of your tsconfig?
I'm not sure exact what kind of error handling system CRA is using to push those errors to the browser, but I'd bet it's more all-encompassing than pick-and-chose, so the OP's approach of making it optional seems reasonable, assuming it doesn't break anything else.
I wouldn't use it (I'd rather see the error) but then I don't think I've experienced exactly what you guys are describing - are you not seeing the error in the editor?

(I'd rather see the error) but then I don't think I've experienced exactly what you guys are describing - are you not seeing the error in the editor?

I can see the typescript errors in my editor. They also show in the terminal and the browser console. There's three places already displaying the error, which is why it would be nice to make the fourth one dismissible (or avoidable 😀) since it blocks usage of the page.
I added some css to my project (for dev builds only) to hide the error iframe as a short term solution, but it seems like the dev experience for TS+CRA could be polished slightly in regards to the error overlay.

We are seeing the error in the editor, but the problem is specifically that even after we have fixed the error, we get an overlay because the ts compilation lags behind.

This has been an extreme pain point for us as well. We're trying to add TypeScript support to a medium sized project and I'm unclear on a path forward for migration. The project builds and works normally with standard JS, but as expected there are a plethora of errors that need to be addressed when TypeScript is introduced. We do not have the time or resources to go through each and every one of these immediately. As it stands I haven't discovered a way to get the project to build without fixing everything.
I would expect there'd be some ability to log these "errors" as warnings and continue on with the build process so that code can be migrated incrementally as time allows. Have others found a suitable approach? The cleanest thing I have come up with is to use a mix of .js[x] and .ts[x] files in the interim rather than renaming everything all in one go.

Guys, I've been testing this all week and I think that it's actually a bug.
While the OP's PR certainly has merit, I think there is also a bug, maybe related to eslint-config-react-app - this seems to be causing some major headaches as it's fighting with VS Code ( I think) and the TS Lint extension.
I haven't been able to troubleshoot it long enough to know for sure, but removing this package after starting with npm start seems to alleviate the issue, however it won't start again after as CRA relies on this and checks for it at start.
If/when I narrow it down, I'll post a PR if I think I can fix it and/or a bug report.

I would expect there'd be some ability to log these "errors" as warnings and continue on with the build process so that code can be migrated incrementally as time allows. Have others found a suitable approach?

You could replace "react-scripts": "<VERSION>", with "react-scripts": "fortana-co/react-scripts#master", in package.json.
You would be using the version of react-scripts from my PR, which prints the TS errors to the terminal and the browser console, but doesn't prevent the app from loading.
This is what I'm doing with my projects until the PR or something similar gets merged. And yeah, I agree, this is a major pain.

This is a major pain point for me as well. My main use-case for CRA is quickly trying out ideas/hacking something together. I still want Typescript in this situation, but I'm not worried about most errors to start with – I'll gradually fix it up as I go. As it is, CRA is unusable for this, which is a shame.
Instead, I recommend using Parcel bundler, which actually isn't that much more work and could easily be wrapped in a script:
mkdir my-project
cd my-project
yarn init -y
yarn add parcel typescript react react-dom @types/react @types/react-dom
mkdir public

edit public/index.html so it has, at a minimum, <script src='../src/index.tsx'></script>
0 edit src/index.tsx so it renders whatever you want
add a package.json script to run parcel public/index.html

@tomduncalf Would you mind sharing the tsconfig you’re using along with Parcel?

When I'm doing a quick prototype I don't usually use one @methodbox, it has a default which seems to work okay

Currently it is very difficult and frustrating to develop CRA app with typescript because of this problem. I think that OP approach with adding optional env var is just fine. I even think that be default TS compilation errors should be warnings.

It'd be be really helpful and great if this feature was implemented

Guys, how is it going? I'm looking forward to use CRA without any hacking. The inability to start compiling forces me to write my own unmaintainable hacks every time again and again. I throw myself on your mercy.)

Could you please please fix it?

Our team now really need way to start server if we have TypeScript errors. This improvement will help us. I think way using some argument flag will be useful, something like --ignore-typescript-errors

CRA is not ready to work with TS until this issue not solved, it upsets me :c

I encountered a similar problem. I have some JS codebase I want translate to TS, but I cant do this step by step - I have to translate WHOLE component before I can see results on my screen. I think it is nice to have an option to ignore TS errors on translate period.

Still a problem :/

Fixed here https://github.com/facebook/create-react-app/pull/6421

+1

Why it still does not fix? Error overlay for types error in development mode is an awful idea!

This issue can now easily be fixed. Let's imagine you don't want an overlay to show for unused variables. Do the following:

Set noUnusedLocals to false in tsconfig.json
Create a custom eslint config that looks like the following:

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json",
    "sourceType": "module",
    "jsx": true,
    "ecmaFeatures": { "jsx": true }
  },
  "extends": ["react-app"],
  "rules": {
    "no-unused-vars": ["warn"],
  },
  "overrides": [
    {
      "files": ["**/*.ts?(x)"],
      "plugins": ["@typescript-eslint"],
      "extends": [
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended",
      ],
      "rules": {
        "@typescript-eslint/no-unused-vars": [
          "warn",
          {
            "ignoreRestSiblings": true,
            "varsIgnorePattern": "^_",
            "argsIgnorePattern": "^_",
            "caughtErrors": "all"
          }
        ]
      }
    }
  ]
}

You will no longer get an overlay but will get a warning in the console. You can also set it to off if you don't want to see the console warning.


feature Add cloud tablet schema definition

Proposed changes
Issue Number: close #xxx

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

run buildall