Initial iteration on EPIC implementation

Hi @ejnnr @anshradh thank you both for your comments! It would be nice to have a discussion about this over a call. I also tried to think about how to make the implementation as general as possible for future distance metrics. My goal is that this could once become the go-to package to measure distances between rew fns for people doing reward learning, with a range of distance metrics, integrations, and robust sampling algorithms with convergence guarantees.

Yeah I should have mentioned that this was a very clean and easy to follow implementation, so hats off to you @Rocamonde!
I'm going to be working on extending this for divergence-free reward distances, so I think most of mine and Erik's comments were towards that aim. Honestly the PR mostly lgtm already and I can also add/refactor things as needed as I do my implementation (which I've started on a branch based off of this current one), so it may just be better to leave the PR mostly as is and for me to make the modifications as needed. Happy to talk more about this some time though!


Auto Migrate removes data from tables that haven't been edited

When running auto migrate, all data is destroyed. Why is this necessary? If auto migrate works as if each table starts from scratch, just drop and create the tables that have been edited.
The development process for auto:upgrades isn't flawless. In fact, most of the schema changes I make with auto upgrade fail. I then have to run auto migrate and all my data is destroyed.

We're working to improve autoupgrade so it handles all possible use cases. Eventually it'll be rock-solid in DM 2.0. automigrate is a destructive process and it'll remain this way.

Thanks! Can't wait for DM 2.0. I'm a Django guy, but DM makes Rails more than tolerable :)

@dlo haha thanks! good to know :)


feat(connect):  df.show

depends on https://github.com/Eventual-Inc/Daft/pull/3554
see here for proper diff

fyi if you make your PRs inside the repository and set the right branch to merge into, you should be able to make the PR only show files changed from that branch


temp: human readable summaries for relative access time compared to absolute

With testing the new eviction order there is a problem of all of the (currently rare) disk usage based evictions being rare and unique; this PR adds a human readable summary of what absolute order would had done and what the relative order does. Assumption is that these loggings will make the few evictions runs in staging more useful.
Cc: #5304 for allowing testing in the staging

ok - is the plan to git revert 9006241f1dca05921ed0048534822c5342ad8552 before the next release?

Yes, partially or completely: I think the select_victims is useful refactoring, but I can just pick it in a separate PR.


Migrate db columns containing json to the json type in mysql

Possibly better optimised storage
validates json
adds ability to query on the json and to mutate it via sql
should avoid charset issues in the CLI
easier tweaking of docs via the CLI
https://dev.mysql.com/doc/refman/8.0/en/json.html#json-partial-updates
Assumes stroom is mysql 8 as a min.

With the doc table we probably ought to normalise it into multiple tables, i.e. make doc the parent table (removing ext and data) then have three child tables for text data, binary data and json data.  Child table would be (doc_id, ext, data) where data is text|binary|json respectively.  This would require a change to the Map<String, byte[]> that gets passed down to DBPersistence so that the store can say what type each extension is.
This would also mean we wouldn't need the distinct on most of the doc queries and would allow us to store the data in a more appropriate way for the datatype in question.


[WIP] generic S-parameter JAX interpolator

Addresses #1054 #653
Work in progress on automating N-D input to M-D output S-parameter interpolation for circuit and variability simulations. Feedback welcomed!
Currently only the EME sub-simulator is interfaced, but most of the work is done in a generic parent class.
Usage is designed to be very simple:
(1) user parametrizes a Component, and provides a LayerStack
(2) user calls a child of the Model class, specifying simulation parameters and which parameters are swept across what range. Parameters can be Component arguments, LayerStack thicknesses, and others (like wavelength is simulation depends on it)
(3) simulations are run and an interpolator is returned that can give S-parameters within the ND input range
Example:
    import gdsfactory as gf
    from gdsfactory.cross_section import rib, strip
    from gdsfactory.simulation.sax.parameter import LayerStackThickness, NamedParameter
    from gdsfactory.tech import LayerStack

"""Define component"""

    c = gf.components.taper_cross_section_linear(
        cross_section1=rib(width=2), cross_section2=rib(width=0.5)
    )
    c.show()

"""Define LayerStack"""

    layerstack = gf.tech.get_layer_stack_generic()
    filtered_layerstack = LayerStack(
        layers={
            k: layerstack.layers[k]
            for k in (
                "slab90",
                "core",
                "box",
                "clad",
            )
        }
    )

"""Parametrize component: here, we fix one width, and make length and the other width changeable:"""

    trainable_strip_strip_taper = (
        lambda parameters: gf.components.taper_cross_section_linear(
            length=parameters["length"],
            cross_section1=strip(width=0.5),
            cross_section2=strip(width=parameters["width2"]),
        )
    )

"""Create a model object, which defines simulator to use and which variable to sweep and in what range"""
    strip_strip_taper_model = MeowEMEModel(
        component=trainable_strip_strip_taper,
        layerstack=filtered_layerstack,
        simulation_settings={
            "mode_res": 100,
            "cell_length": 0.5,
            "num_eme_modes": 4,
            "spacing_x": 1,
            "spacing_y": -3,
            "overwrite": False,
        },
        trainable_parameters={
            "length": NamedParameter(min_value=5,
                                        max_value=6,
                                        nominal_value=6,
                                        step=1
                                        ),
            "width2": NamedParameter(
                min_value=1.0,
                max_value=1.0,
                nominal_value=1.0,
                step=1.0
            ),
            "wavelength": NamedParameter(
                min_value=1.545,
                max_value=1.555,
                nominal_value=1.55,
                step=0.005
            ),
            "core_thickness": LayerStackThickness(
                layerstack=filtered_layerstack,
                min_value=0.19,
                max_value=0.25,
                nominal_value=0.22,
                layername="core",
                step=0.3,
            ),
        },
        num_modes=2,
    )

"""Get the interpolator"""
    # input_vectors, output_vectors = strip_strip_taper_model.get_data()
    interpolator = strip_strip_taper_model.get_nd_nd_interp()

    import jax.numpy as jnp

"""Evaluate the interpolator"""
    params = jnp.stack(
        jnp.broadcast_arrays(
            jnp.asarray([6.0, 6.0, 6.0]),
            jnp.asarray([1.0, 1.0, 1.0]),
            jnp.asarray([1.55, 1.5, 1.55]),
            jnp.asarray([0.22, 0.22, 0.19]),
        ),
        0,
    )
    print(interpolator["o1@0,o2@0"](params))

Output:
Getting examples: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 6/6 [00:00<00:00,  6.61it/s]

[0.9993654+2.4627744e-25j 0.9993654-2.4463871e-25j
 0.9993654+2.4627744e-25j]

TODO:

[ ] Wrap the interpolator in a Dict to make its inputs directly compatible with SAX SDicts
[ ] More consistent use of JAX/JIT
[ ] Add tests
[ ] Add waveguide sub-simulator for interpolation
[ ] Add 2.5D FDTD sub-simulator for interpolation
[ ] Show JAX differentiability
[ ] Notebook example
[ ] Nice GIF showing component optimization at circuit level

Maybe:

[ ] Neural net interpolation (I've made it work, but it requires lots of simulations, does not seem worth it over NDinterp so far)
[ ] Neural net interpolation for optical modes like EMEpy, could speed EME up

looks great Simon!
@flaport
@SkandanC

Simon, can we merge this?
we can create an issue to track the different subtasks

I've been playing with it let me make a new PR


[overlay] add overlay/assert to assert on value of selected item

might be useful for testing by writing "desired" end result and running against overlays.

available in 0.26.0+


More configurable requests

This allows to use a different URL and HTTP method for closing incidents. Also included is a fix for sending the close notifications as they don't work in master.

This looks great, thank you! Can you update the wiki pages for configuration with the appropriate changes?

Wiki updated. Have a nice day!


TypeError: expected string or buffer

Hi,
I'm trying to run this code:
import pyglet

display = pyglet.canvas.get_display()
screens = display.get_screens()
window = pyglet.window.Window(fullscreen=True, screen=screens[1])

pyglet.app.run()

and I get this error:

Traceback (most recent call last): File "/home/pi/netcomShopTV/idk.py", line 5, in window = pyglet.window.Window() File "/usr/local/lib/python2.7/dist-packages/pyglet/init.py", line 359, in getattr import(import_name) File "/usr/local/lib/python2.7/dist-packages/pyglet/window/init.py", line 1890, in gl._create_shadow_window() File "/usr/local/lib/python2.7/dist-packages/pyglet/gl/init.py", line 209, in _create_shadow_window _shadow_window = Window(width=1, height=1, visible=False) File "/usr/local/lib/python2.7/dist-packages/pyglet/window/xlib/init.py", line 171, in init super(XlibWindow, self).init(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/pyglet/window/init.py", line 642, in init self._create() File "/usr/local/lib/python2.7/dist-packages/pyglet/window/xlib/init.py", line 265, in _create self.context.set_vsync(self._vsync) # XXX ? File "/usr/local/lib/python2.7/dist-packages/pyglet/gl/xlib.py", line 265, in set_vsync warnings.warn(e) TypeError: expected string or buffer

Thanks for opening the ticket.
Can you give me more information on your system?

Thanks for opening the ticket.
Can you give me more information on your system?

Device: Raspberry pi 4
OS: Raspbian Buster, version September 2019
Pyglet Version: 1.4.8
Python: 2.7

This is an exception for a Raspberry Pi specific issue. It's supposed to raise a warning, and pass without crashing. If possible, could you try editing line 265 in /usr/local/lib/python2.7/dist-packages/pyglet/gl/xlib.py, and changing:
warnings.warn(e)
to
warnings.warn(e.message) or warnings.warn(e.args)
Also, could you give it a try on Python 3 and see if you get the same crash?

This is an exception for a Raspberry Pi specific issue. It's supposed to raise a warning, and pass without crashing. If possible, could you try editing line 265 in /usr/local/lib/python2.7/dist-packages/pyglet/gl/xlib.py, and changing:
warnings.warn(e)
to
warnings.warn(e.message) or warnings.warn(e.args)
Also, could you give it a try on Python 3 and see if you get the same crash?

I changed it to warnings.warn(e.message) and it worked.
Thanks!

Thanks for confirming. I'll get that fix into the next release.
If you have python 3 on your Raspberry Pi, could you also confirm that as well?

I tried to run the code on python3. It works, but when I try to close the window, I get this error:

/usr/local/lib/python2.7/dist-packages/pyglet/gl/xlib.py:265: UserWarning: glXSwapIntervalMESA is not exported by the available OpenGL driver.  MESA_swap_control is required for this functionality

It has something to do with graphic... But I don't have this problem with python 2.7!

Thanks for confirming. I'll get this change into the next release.
The "UserWarning" is expected.
The reason is that the OpenGL driver on Raspberry Pis advertise that they support vsync, but the function is not there. Instead of crashing, we want to continue and print a warning.


fix: add missing Nav export

:tada: This PR is included in version 0.3.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Removed unnecessary constraints on ALSA's buffer

This may correct issues #14 and #26, and does at least fix an issue I was having while using the following /etc/asound.conf:
pcm.!default {
    type plug
    slave.pcm "asymed"
}

pcm.asymed {
    type asym
    playback.pcm "dmixer"
    capture.pcm "dsnoop"
}

pcm.dmixer  {
   type dmix
   ipc_key 1024
   slave {
      pcm "hw:Audio"
      format S32_LE
      period_time 0     # 20000
      period_size 1024  # 20000
      buffer_size 8192  # 80000

      rate 96000
   }
   bindings {
      0 0
      1 1
   }
}

ctl.dmixer {
   type plughw
   card Audio
}

Using this config, Skype would not play sound work under apulse, and the following would be spit into the console:
[apulse] [error] do_connect_pcm, snd_pcm_hw_params_get_period_size, Invalid argument
[apulse] [error] do_connect_pcm, snd_pcm_hw_params_get_period_size, Invalid argument

However, if the commented-out values for period_time, period_size, and buffer_size were used, everything would run fine, since these were equal to the hard-coded values.
Regardless, if I've understood ALSA's documentation correctly, this tweak shouldn't cause any other changes to the program's functionality, and should run fine on other machines.

Just throwing that code out doesn't seem to be right.
I was at first also relying on default buffer size, but there are could be insane drivers with weird settings. For example, I found that PulseAudio plugin for ALSA eats up to about 4 megabytes of data, completely ruining apps that use ALSA as a timer. Given that the issue is there for years, I can guess that most of the applications are setting period and buffer sizes. That in turn could result in non-conformant drivers which does work for existing apps, but fail is someone doesn't set correct buffer size.

From reading descriptions I can guess snd_pcm_hw_params_get_period_size can return negative values, but that doesn't imply an error. Just audio adapter happen to have no valid period sizes. So it worth to check that at run time and omit buffer size related changes only in that case.
How about https://github.com/i-rinat/apulse/compare/optional-buffer-size ? Does it work?

It does, actually, fix the problem! However, I realized I had made a slight mistake in my first commit after looking into this more, as the code still runs fine even if I use snd_pcm_hw_params_set_buffer_time_near. The actual issue was likely that period_size was left zeroed or uninitialized, and was passed to snd_pcm_sw_params_set_avail_min as zero, causing the buffer to be dumped too quickly, leading to no sound.
Personally, I think that leaving the code out would be better, because (correct me if I'm wrong) the workaround can interfere with other audio streams. It should be up to the user to implement this workaround, if they choose to do so, in /etc/asound.conf or by other means, instead of it being forced upon them. Again, I could be very wrong about my assumptions here!
On a side note, for functions similar to snd_pcm_hw_params_get_period_size, I believe the sole purpose of the dir argument is to provide an output, and as far as I can tell, it doesn't actually need to be assigned a value in this code.

I think that leaving the code out would be better

Sorry, can't parse it for sure. Do you mean, to remove that code, or to keep it there? What code are you talking about, the previous version, or code you are proposing?

interfere

Should not, if you are talking about 5a07c3b94f5de1454e3ac98e3fa635fb23ef7b28. Look, code there checks return value of snd_pcm_hw_params_get_period_size() and only change buffer size related settings if that call was successful. So on your machine it will do the same as your patch do, but on others, where get_period_size() actually returns value, it will keep old behavior.

By "leaving the code out", I meant to put in my commit, fb97df6725c2a28508dd2bb8754067689f2fadc8.
I think that my commit would be better, because if a user has "insane drivers with weird settings", then this user should implement this workaround using asound.conf (or by other means) instead of this workaround being forced upon them whenever running apulse, since some users might not want this workaround.
Also, while your commit fixes my issue, I could still be affected by "insane drivers with weird settings", because it effectively disables the workaround for me. So, if it is decided that apulse should actually use this workaround, then we should find a way for it to always work, no matter the value of snd_pcm_hw_params_get_period_size().
But I still think that apulse shouldn't be using the workaround in the first place, because if these "insane drivers ruin apps that use ALSA as a timer", there ought to be another way to fix the issue, but I'm not an expert on how ALSA works by any means whatsoever. For example, instead of calling snd_pcm_hw_params_set_buffer_time_near, we can set pcm.dmixer.slave.buffer_time to an appropriate value. I'm not sure how the same can be done for snd_pcm_sw_params_set_avail_min.
Let me know if I can clarify anything!

we can set pcm.dmixer.slave.buffer_time to an appropriate value

Yeah... But official tutorial proposes to set buffer and period sizes. And Mplayer, mpv, ffmpeg, all set buffer size. So they will work, and apulse won't.
I personally prefer something that would work "out of the box", if possible.

So, if it is decided that apulse should actually use this workaround, then we should find a way for it to always work, no matter the value of snd_pcm_hw_params_get_period_size().

Small correction: not a value returned by snd_pcm_hw_params_get_period_size(), but an error code it returns. If it fails, that means audio adapter doesn't care about period size, so all related configuration should be skipped.

You're right, I suppose that is the right way to do it. I'll correct my commit once I get back to my test machine, so that it works in either case.

By the documentation, I'm not absolutely certain if it is true to say that if get_period_size returns a negative error code, then get_period_size_min will always return zero. When the documentation says that get_period_size returns "0 otherwise a negative error code if the configuration space does not contain a single value", it's not clear if get_period_size returning less than zero means the configuration space does not contain a value, contain a range of values (which can be fetched by get_period_size_min), or both.
In any case, this code works for me, and it also conforms with the official example implementation, no matter the return value of get_period_size.

Oh, forgot about this.
I remove snd_pcm_hw_params_get_period_size call in 555d336b890c7b567804f6ea357b9bff2ea8a3d6. It's not required, since period size can be calculated explicitly.


Allow putting pixi/bin/ in a global location

Problem description
I'd like to be able to put pixi and the global installs outside of the user profile directory tree.
For example C:\apps\pixi on windows.
Reading the related #172 it seems this is also wanted for other global items,

This would indeed be linked to the global config feature!

This can now be set with the PIXI_HOME env variable


SSL_write succeeds and does not report cert verification errors with TLS 1.3 (may result in data loss)

Hello,
I have a one-way protocol where the client only uses the SSL_write method and never calls SSL_read. This setup works really well with TLSv1.2 (and older), however with TLSv1.3 the client is unable to detect error cases.
By browsing the already opened issues I have found similar, but not identical cases. They include session tickets, mid communication key renewal, partial messages in the buffers, etc. The answers in those cases are suggesting: "Assuming two way protocols, SSL_read will report the problem."
By inserting read methods into my code[1] - I can confirm the errors are reported immediately! However I think there is a chance for data loss even in case of two-way protocols, if the client is the one who sends data first. This is the reason I am opening this issue.
Please help me identify if this is a bug, or TLSv1.3 requires a fundamentally different architecture. In case it's not considered as a bug, I think it would be important to add something to the documentation that explains what to do when implementing one-way protocols/upgrading an existing implementation to TLSv1.3 (OpenSSL 1.1).
Envrionment
$ openssl version -a
OpenSSL 1.1.1  11 Sep 2018
built on: Wed Dec  2 14:54:45 2020 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-WsH1Tl/openssl-1.1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

$ uname -a
Linux tp 5.4.0-62-generic #70~18.04.1-Ubuntu SMP Tue Jan 12 17:18:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Reproduction code
https://github.com/szemere/openssl-missingcert-test/blob/master/ssl_write_test.c
I was able to reproduce the issue with any case where the server provides the "SSL routines:tls_process_client_certificate:certificate verify failed" error message. So far I tested:

expired certificates
omitting the client certificate
providing invalid certificate

https://github.com/szemere/openssl-missingcert-test/blob/master/ssl_server_for_testing.c
First, I tested with openssl s_server, which gives the same result. But in order to turn off session tickets[2] I provided a simple "read everything" server so the reproduction is self contained.
Reproduction steps

Generate proper certificates for the server.
Start the provided example or the openssl s_server (my options: [3])
Start the provided client.

Output on the server side reports the issue with the certificate properly and closes the connection:
140681764807104:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed:../ssl/statem/statem_srvr.c:3668:

Output on the client side suggests successful data transer:
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: -1 EAGAIN
SSL_write returned: 512 SUCCESS

My client exits if SSL_write returns any value bigger than 0.

Any following SSL_write also succeeds, reporting succesful data transfer. (I tested it with an infinite loop around the try_sending_512bytes method.)
The first SSL_read properly reports the problem, as stated above. [4]
SSL_write already reported successful data transer, so data loss is already possible.
The following SSL_shutdown method reports 0.

Notes
[1] Inserting read methods requires a protocol change.
[2] As a workaround to: https://github.com/openssl/openssl/issues/7948
[3] Server command: openssl s_server -Verify 42 -verify_return_error -tls1_3 -cert /tmp/server.crt -key /tmp/server.key -verifyCApath /tmp/CAdir/
[4] Of course, in order to call SSL_read before the first SSL_write, it is required to call SSL_connect explicitly. Unfortunately SSL_connect also reports success.
I only tested the setup with a certificate error during the handshake process. At this moment I am unaware of any other connection error which causes the same effect.

I think you're using TLS wrong.  The protocol messages need to flow in two directions.  They always did.

I think you're using TLS wrong.  The protocol messages need to flow in two directions.  They always did.

A TLSv1.3 handshake looks like this (from RFC 8446):
       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                            + pre_shared_key*  v
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

Each peer considers the handshake to be complete when it has both sent and successfully received/validated a "Finished" message. You can see from the above diagram that by the time the client sends its "Finished" message it has already received and validated the server one. Therefore the client considers the handshake complete immediately after it has sent its Finished. The server meanwhile is still waiting on the final flight from the client, and therefore the server hasn't finished yet.
The error you are talking about occurs at the point in the protocol after the client believes it is done, but the server is still processing the handshake.
This is just the way TLSv1.3 works. If you have a "one way protocol" then the client reallly must not assume everything is successful until a full 2-way shutdown has been performed (meaning that it has both sent and received a close_notify alert). From an API perspective this means you must continue calling SSL_shutdown until it has returned 1 (or indicates an error).
https://www.openssl.org/docs/man1.1.1/man3/SSL_shutdown.html
Note, that this problem also exists in TLSv1.2 when using session resumption so it is not new to TLSv1.3. The main difference is that it occurs in TLSv1.3 for non-resumed sessions too.

A TLSv1.3 handshake looks like this (from RFC 8446):
       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                            + pre_shared_key*  v
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

Each peer considers the handshake to be complete when it has both sent and successfully received/validated a "Finished" message. You can see from the above diagram that by the time the client sends its "Finished" message it has already received and validated the server one. Therefore the client considers the handshake complete immediately after it has sent its Finished. The server meanwhile is still waiting on the final flight from the client, and therefore the server hasn't finished yet.
The error you are talking about occurs at the point in the protocol after the client believes it is done, but the server is still processing the handshake.
This is just the way TLSv1.3 works. If you have a "one way protocol" then the client reallly must not assume everything is successful until a full 2-way shutdown has been performed (meaning that it has both sent and received a close_notify alert). From an API perspective this means you must continue calling SSL_shutdown until it has returned 1 (or indicates an error).
https://www.openssl.org/docs/man1.1.1/man3/SSL_shutdown.html
Note, that this problem also exists in TLSv1.2 when using session resumption so it is not new to TLSv1.3. The main difference is that it occurs in TLSv1.3 for non-resumed sessions too.

Hello @mattcaswell,
Thanks for the detailed answer.
One of the mentioned "one-way protocols" is RFC5425.
If I understand you correctly, due to the "async" nature of the TLS 1.3 handshake, it is now possible to lose all of the
application-level payload in RFC5425, because clients never read data (AFAIK the same is true for FTPS data channels).
The only thing an implementation of this can do is calling SSL_shutdown() until both close_notifys are delivered/received.
Well, SSL_shutdown() is too late for us, as we'd like to detect message loss as soon as possible (which is difficult with a protocol without application-level acks), but as a workaround, can we call SSL_read() to read 0 "application-level bytes" to detect the cert verification failure reliably? (This seems like a very odd workaround. i.e.: SSL_write() states that calling with num=0 is an undefined behaviour.)
(Sorry if it's out-of-scope, I just want to make sure I understood everything well.)

Hello @mattcaswell,
Thanks for the detailed answer.
One of the mentioned "one-way protocols" is RFC5425.
If I understand you correctly, due to the "async" nature of the TLS 1.3 handshake, it is now possible to lose all of the
application-level payload in RFC5425, because clients never read data (AFAIK the same is true for FTPS data channels).
The only thing an implementation of this can do is calling SSL_shutdown() until both close_notifys are delivered/received.
Well, SSL_shutdown() is too late for us, as we'd like to detect message loss as soon as possible (which is difficult with a protocol without application-level acks), but as a workaround, can we call SSL_read() to read 0 "application-level bytes" to detect the cert verification failure reliably? (This seems like a very odd workaround. i.e.: SSL_write() states that calling with num=0 is an undefined behaviour.)
(Sorry if it's out-of-scope, I just want to make sure I understood everything well.)

It has always been the case with TLS that to avoid truncation of the data stream (or "data loss" as you put it), either the application layer protocol needs to indicate message sizes and successful completion, or you have to get and process the "close_notify" alerts in both directions.  Since a one-way application protocol inherently can't report back completion in the other direction, that means you have to use the "close_notify" procedure, which in OpenSSL is implemented via the SSL_shutdown() routine.  I'm sorry that this was not clear from the documentation, but it doesn't change the reality that this risk has always been present in your software.

It has always been the case with TLS that to avoid truncation of the data stream (or "data loss" as you put it), either the application layer protocol needs to indicate message sizes and successful completion, or you have to get and process the "close_notify" alerts in both directions.  Since a one-way application protocol inherently can't report back completion in the other direction, that means you have to use the "close_notify" procedure, which in OpenSSL is implemented via the SSL_shutdown() routine.  I'm sorry that this was not clear from the documentation, but it doesn't change the reality that this risk has always been present in your software.

Hi @kaduk,
Thank you for your response.
I agree, it's a fact that RFC5425 has no per-message delivery guarantees due to the simplicity of the protocol, so truncation is possible without processing both close_notifys (as stated in 4.4.  Closure).
After reading https://github.com/openssl/openssl/issues/13998#issuecomment-769082091, we were just wondering if it was possible to detect the certificate verification failure earlier than the end of the connection without reading actual app-level data.

Hi @kaduk,
Thank you for your response.
I agree, it's a fact that RFC5425 has no per-message delivery guarantees due to the simplicity of the protocol, so truncation is possible without processing both close_notifys (as stated in 4.4.  Closure).
After reading https://github.com/openssl/openssl/issues/13998#issuecomment-769082091, we were just wondering if it was possible to detect the certificate verification failure earlier than the end of the connection without reading actual app-level data.

After reading #13998 (comment), we were just wondering if it was possible to detect the certificate verification failure earlier than the end of the connection, without reading actual app-level data.

You can attempt to call SSL_read() and you can do so with a buffer larger than 0. Since you're not actually expecting a reply the buffer will never be filled in anyway (and presumably it would be an error in your protocol if you did get such a reply). Calling SSL_read() when you're not actually expecting a reply will result in one of two things:

Non fatal error (SSL_ERROR_WANT_READ)
Some fatal error e.g. SSL_ERROR_SSL/SSL_ERROR_SYSCALL

In the case of (2) you know that the server has failed (possibly because of the cert verify failure but it could be for some other reason). In the case of (1) you don't know whether the server has failed, or is going to fail and just hasn't go around to telling you yet, or whether all is good.
So, calling SSL_read(), might tell you about the failure earlier than you would otherwise know via SSL_shutdown, but there is no guarantee and no response cannot be interpreted as "all is good".

After reading #13998 (comment), we were just wondering if it was possible to detect the certificate verification failure earlier than the end of the connection, without reading actual app-level data.

You can attempt to call SSL_read() and you can do so with a buffer larger than 0. Since you're not actually expecting a reply the buffer will never be filled in anyway (and presumably it would be an error in your protocol if you did get such a reply). Calling SSL_read() when you're not actually expecting a reply will result in one of two things:

Non fatal error (SSL_ERROR_WANT_READ)
Some fatal error e.g. SSL_ERROR_SSL/SSL_ERROR_SYSCALL

In the case of (2) you know that the server has failed (possibly because of the cert verify failure but it could be for some other reason). In the case of (1) you don't know whether the server has failed, or is going to fail and just hasn't go around to telling you yet, or whether all is good.
So, calling SSL_read(), might tell you about the failure earlier than you would otherwise know via SSL_shutdown, but there is no guarantee and no response cannot be interpreted as "all is good".


Range 不支持 step

How would you tag this issue?

Bug

Describe your issue:

Range 组件不支持 step，导致不支持小数滑动

麻烦给个codesandbox链接


auro-datetime: allow for additional custom date assignment

Alaska Airlines Pull Request
Version supported creating new date objects based on today and creating full date objects off of UTC or string data. This PR adds additional support for creating individual day, weekday, month, year, and time.
This PR also refactored the number of multiple functions and reduced the amount of logic needed switch between the individual functions.
Options added
<auro-datetime type="time" utc="2020-09-22T01:38:22Z"></auro-datetime>
<auro-datetime type="time" setdate="August 19, 1975 23:15:30"></auro-datetime>
<auro-datetime type="year" setdate="August 19, 1975 23:15:30"></auro-datetime>
<auro-datetime type="year" utc="1920-09-22T01:38:22Z"></auro-datetime>
<auro-datetime type="month" utc="1920-04-22T01:38:22Z"></auro-datetime>
<auro-datetime type="month" setdate="July 19, 1975 23:15:30"></auro-datetime>
<auro-datetime type="weekday" utc="1920-04-22T01:38:22Z"></auro-datetime>
<auro-datetime type="weekday" setdate="July 19, 1975 23:15:30"></auro-datetime>
<auro-datetime type="day" utc="1920-04-22T01:38:22Z"></auro-datetime>
<auro-datetime type="day" setdate="July 19, 1975 23:15:30"></auro-datetime>

Type of change:
Please delete options that are not relevant.

[x] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


@font-face not working in pdf format

Hi
i want to using a persian font and it works fine in html but when converting to pdf the font does not working , i think it can not read the local saved font
@font-face {
  font-family: Shabnam;
  src: url('Shabnam.ttf') format('truetype');
}

what should i do?

Experiencing the same issue. the difference is I'm using
@font-face{
font-family: 'Code128bWin';
src: url('/fonts/Code128bWin.eot');
src: url('/fonts/Code128bWin.eot?iefix') format('eot'),
url('/fonts/Code128bWin.woff') format('woff'),
url('/fonts/Code128bWin.ttf') format('truetype'),
url('/fonts/Code128bWin.svg#webfont') format('svg');
}

@marcbachmann can you help us please

If you like to load the assets from the local file system, you'll need to use an absolute path to your file: file:///absolute/path/to/asset
There's also a base option to set that by default.
https://github.com/marcbachmann/node-html-pdf/blob/d7ae2439ef8082475a80f3045ddfa6dce7c5054e/bin/index.js#L27

@marcbachmann thanks for the help! I used http host to load the fonts.
@font-face{
font-family: 'Code128bWin';
src: url('https://testurl.com/test/fonts/Code128bWin.eot');
src: url('https://testurl.com/test/fonts/Code128bWin.eot?iefix') format('eot'),
url('https://testurl.com/test/fonts/Code128bWin.woff') format('woff'),
url('https://testurl.com/test/fonts/Code128bWin.ttf') format('truetype'),
url('https://testurl.com/test/fonts/Code128bWin.svg#webfont') format('svg');
}

I had the same problem, previous solutions with file:/// didn't work for me, so I managed to fix this including the file using a base64 encoded string in order to load the font:
  fontPath = fs.readFileSync(path.resolve(__dirname, '../templates/pdf/font/Roboto-Regular.ttf'));
  const fontRoboto = fontPath.toString('base64');

and then in the template:
      @font-face {
        font-family: 'Roboto';
        src: url('data:font/truetype;charset=utf-8;base64,{{this.fontRoboto}}');
        font-weight: normal;
        font-style: normal;
      }


[RFC] var_dump/dump fixer

This RFC is for var_dump/dump removal fixer. While a lot of devs debug via var_dump(or via  Symfony/VarDumper dump), it is dangerous to have it in code, especially if it appears in production . So, why not to introduce these functions removal? What do you think?

Hi and thanks for your suggestion :)
How about var_export or the CURLOPT_VERBOSE flag?
The thing is that we would not be fixing code style, but modifying the way some code works. This is not always a bad thing IMO. However in this case we cannot determine if the var_dump is indeed a forgotten debug statement (and the function is not overloaded) or is part of the logic that is essential to the application.
Therefor I would not add it to the core of the application because it is out of scope and risky. However such a fixer is relatively easy to write and can exists as a custom fixer for your needs.
But lets see what the community thinks :)

@SpacePossum thank you for your feedback.
I agree with you that such a functionality might be out of scope of the project.
Right now I can't judge what is more risky for developer - keeping statements in the code, which are commonly used for debugging, or use the fixer as such.
However, I think that contrib fixers are usually enabled explicitly by developer, which means that one understands all the consequences of it.
Anyway, the reason why I've created the issue is that I've already done this fixer for private purposes. If community wants to have that, I will be more than happy to contribute to an awesome tool. If there is no need/it is our of scope of the project, I will just use my fork.

Also consider that those debug statements, especially var_export($var, true) could be used to save debug data / traces in production whenever an unexpected error occurs.

Short summary from PR discussion - too risky to have it in core. For those, who want to have that - https://github.com/akovalyov/DebugStatementsFixers.


Added ability to override close button div class

Added to toaster-config to allow for default configuration for a given toaster-container
Added to toast to allow for individual overrides on a pop
Retained absolute default of 'toast-close-button'
Added a couple more .gitignore entries based local build elements.

Looks great! @karclouds what do you think about merging this into master and publishing on npm?


Set up Junit XML output from Puppeteer tests (etc.)

We've recently made two majors changes to our testing infrastructure:

Migrating to GitHub Actions from CircleCI as our primary CI infrastructure
Replacing Casper with Puppeteer, which as a side effect caused us to no longer have tooling that generics Junit XML files.

We should look at using junit.xml files (the ~standard format for communicating which tests failed, though maybe there's a better format now?) for improving the output in the GItHub checks section to show which test failed without clicking all the way into things.
https://github.com/marketplace/actions/junit-report-to-annotations seems potentially relevant, if we can get Puppeteer to do what we want (maybe by running it inside Jest/Jasmine?  I think we're hoping to use Jest for the node tests, in case that's relevant).

Replacing Casper with Puppeteer, which as a side effect caused us to no longer

caused us to no longer...? Is some info missing here?

Oops, fixed -- basically we'd configured Casper to generate Junit XML output, and haven't done so with puppeteer.

For migrating to Jest, https://github.com/zulip/zulip/pull/13374 is the PR -- currently blocked on performance issues with Jest.
It's worth doing a bit more research for this issue; now that we've moved from CircleCI to GitHub Actions, there may be new options available for how to achieve our actual end goal (Having the "checks" output show what failed).


Using Continuous Query with thin client causing OutOfMemoryError

Using continuous query with thin clients(Java ignite version 2.14.0), resulted in OutOfMemoryError when one of the thin clients becomes slow.
Tried to set SlowClientQueueLimit to 100 and MessageQueueLimit to 200, but seems it is not taking effect. The queue in GridSelectorNioSessionImpl continues to grow until run out of memory

Continuous Query guarantees exactly-once delivery. It can't just drop some events from the queue because the client is slow.
If the client performance can't be fixed, you have to come up with a different mechanism to receive updates (e.g. polling by "last_updated" or something like that).

Also check the answer here on continuous query buffer size tuning:
[Ignite keeps crashing with OOM](https://stackoverflow.com/questions/75442184/ignite-keeps-crashing-with-oom)

Also check the answer here on continuous query buffer size tuning (IGNITE_CONTINUOUS_QUERY_PENDING_BUFF_SIZE, IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE):
Ignite keeps crashing with OOM

In debugging my issue, these two parameters (IGNITE_CONTINUOUS_QUERY_PENDING_BUFF_SIZE, IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE) never went above 1. So they are not the cause and limiting them would not solve our problem

SlowClientQueueLimit and MessageQueueLimit are working mechanism to deal with slow clients problem (drop them when they hung and stop processing messages):
https://stackoverflow.com/questions/51092741/ignite-tcpcommunicationspi-can-slowclientqueuelimit-be-set-to-same-value-as-me
However, I think they are working only for thick clients, (but not for thin clients).
The code is In the last two lines of GridNioServer.send0() method, where there is a check by msgQueueLsnr.apply(), which will call the GridNioServerWrapper.checkClientQueueSize(), which will drop the slow client if queue exceeds limit.
Could we make the same mechanism working for thin client connections as well?

think they are working only for thick clients, (but not for thin clients).

That is correct. For now we don't have plans to adopt this mechanism for thin clients.

@hongchen2000 The thin client outbound  message queue limit was introduced in IGNITE-20424 which is included in Ignite 2.16 release.
Thank you for filing this issue.


feat: stewardship for feeds

⚠ Support requests in an issue-format will be closed immediately. For support, go to Swarm's Discord.
Context
it's not possible to validate that (indexed) feed chunks are available in the network. it would be good to be able to check that feed chunks are available up to a certain index.
something like:
curl http://localhost:1633/stewardship/feed/ae5b5991481f3e14c60e082d71e43dd3ffe7cdac326b844cda412e9986e9eb4d?index=10

[{index: "0", "isRetrievable":true},...,{index: "0", "isRetrievable":true}]

it would be best if all the chunks are checked independent of each other to highlight situations where there are chunks missing from the middle of the sequence.

there was some discussion that the best approach may be to polyfil our needs using js for now, but the issue should probably remain as it represents one of the gaps in the bee api that should be filled when priorities allow


The integrated source control (Git) is very very slow in the latest version (1.78.x)

Type: Performance Issue
Before, the integrated source control (Git) in VSC is very fast but now it is very very slow. I'm not sure but this seems to happen after I update my VSC to the latest version (1.78.x). I thought that the problem is at my installed "git for Windows" (it worked well before I updated VSC) and updated it to the latest version but nothing changed, I think this is a problem of the latest version of VSC, or maybe at 1 of git extensions I installed but I'm not sure.
Note: If I use git through Git Bash, everything is still fine (fast as it should be)
Here are some log in the git output inside VSC:
2023-05-23 16:46:35.054 [info] > git add -A -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [27846ms]
2023-05-23 16:48:39.228 [info] > git ls-files --stage -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [2601ms]
2023-05-23 16:48:39.231 [info] > git ls-tree -l HEAD -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [2608ms]
2023-05-23 16:48:39.239 [info] > git ls-files --stage -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [2529ms]
2023-05-23 16:50:24.957 [info] > git ls-tree -l HEAD -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [105697ms]
2023-05-23 16:50:24.958 [info] > git ls-tree -l HEAD -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [105701ms]
2023-05-23 16:50:27.984 [info] > git ls-files --stage -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [65005ms]
2023-05-23 16:50:27.987 [info] > git ls-files --stage -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.json [65011ms]
2023-05-23 16:52:58.511 [info] > git add -A -- D:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees\appsettings.Development.json [29306ms]
2023-05-23 16:53:44.880 [info] > git fetch [16761ms]
2023-05-23 16:55:37.421 [info] > git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file - [100953ms]
2023-05-23 16:55:43.820 [info] > git show --textconv :CompanyEmployees/appsettings.json [2493ms]
2023-05-23 16:55:43.820 [info] > git show --textconv :CompanyEmployees/appsettings.Development.json [2479ms]
2023-05-23 16:56:12.377 [info] > git pull --tags origin main [31072ms]
2023-05-23 16:56:35.825 [info] > git push origin main:main [23445ms]
Do not know why it took so much time for the basic operations (files in my repo are quite small, nothing big/huge at all)
VS Code version: Code 1.78.2 (b3e4e68a0bc097f0ae7907b217c1119af9e03435, 2023-05-10T14:39:26.248Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: Yes

System Info

Item
Value

CPUs
12th Gen Intel(R) Core(TM) i5-12400F (12 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
31.84GB (13.95GB free)

Process Argv
--crash-reporter-id e283a491-24a6-4982-a709-f965337f0fd8

Screen Reader
no

VM
0%

Process Info
CPU %	Mem MB	   PID	Process
    0	    96	 25844	code main
    0	    91	  4200	shared-process
    0	    71	 14160	     ptyHost
    0	     7	 23176	       console-window-host (Windows internal process)
    0	     5	 25972	       "C:\Program Files\Git\bin\bash.exe"
    0	    11	 33292	         "C:\Program Files\Git\bin\..\usr\bin\bash.exe"
    0	   382	 18912	extensionHost [1]
    0	    76	  1904	     electron-nodejs ("D:\Program Files\Microsoft VS Code\Code.exe" --ms-enable-electron-run-as-node "d:\Program Files\Microsoft VS Code\resources\app\extensions\markdown-language-features\server\dist\node\workerMain" --node-ipc --clientProcessId=18912)
    0	    78	  4436	     electron-nodejs ("D:\Program Files\Microsoft VS Code\Code.exe" --ms-enable-electron-run-as-node "d:\Program Files\Microsoft VS Code\resources\app\extensions\json-language-features\server\dist\node\jsonServerMain" --node-ipc --clientProcessId=18912)
    0	    78	  9060	     electron-nodejs ("D:\Program Files\Microsoft VS Code\Code.exe" --ms-enable-electron-run-as-node "c:\Users\Luat Nguyen\.vscode\extensions\formulahendry.auto-rename-tag-0.1.10\packages\server\dist\serverMain.js" --node-ipc --clientProcessId=18912)
    0	   125	 28156	     electron-nodejs ("D:\Program Files\Microsoft VS Code\Code.exe" --ms-enable-electron-run-as-node "c:\Users\Luat Nguyen\.vscode\extensions\streetsidesoftware.code-spell-checker-2.20.4\packages\_server\dist\main.js" --node-ipc --clientProcessId=18912)
    0	    25	 31636	     "C:\Program Files\Microsoft\jdk-<IP_ADDRESS>-hotspot\bin\java" -DwatchParentProcess=false -XX:+ExitOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError "-XX:HeapDumpPath=c:\Users\Luat Nguyen\AppData\Roaming\Code\User\globalStorage\redhat.vscode-xml" -Xmx64M -cp "c:\Users\Luat Nguyen\.vscode\extensions\redhat.vscode-xml-0.25.0-win32-x64\server\org.eclipse.lemminx-0.25.0-uber.jar" org.eclipse.lemminx.XMLServerLauncher
    0	     6	 31916	       console-window-host (Windows internal process)
    0	   556	 33392	     dotnet.exe "c:\Users\Luat Nguyen\.vscode\extensions\ms-dotnettools.csharp-1.25.7-win32-x64\.omnisharp\1.39.6-net6.0\OmniSharp.dll" -z -s d:\src\zero\main\ASPdotNET-Web-BE-Zero\CompanyEmployees.sln --hostPID 18912 DotNet:enablePackageRestore=false --encoding utf-8 --loglevel information --plugin "c:\Users\Luat Nguyen\.vscode\extensions\ms-dotnettools.csharp-1.25.7-win32-x64\.razor\OmniSharpPlugin\Microsoft.AspNetCore.Razor.OmniSharpPlugin.dll" FileOptions:SystemExcludeSearchPatterns:0=**/.git FileOptions:SystemExcludeSearchPatterns:1=**/.svn FileOptions:SystemExcludeSearchPatterns:2=**/.hg FileOptions:SystemExcludeSearchPatterns:3=**/CVS FileOptions:SystemExcludeSearchPatterns:4=**/.DS_Store FileOptions:SystemExcludeSearchPatterns:5=**/Thumbs.db FileOptions:SystemExcludeSearchPatterns:6=**/.classpath FileOptions:SystemExcludeSearchPatterns:7=**/.project FileOptions:SystemExcludeSearchPatterns:8=**/.settings FileOptions:SystemExcludeSearchPatterns:9=**/.factorypath FormattingOptions:EnableEditorConfigSupport=true Sdk:IncludePrereleases=true formattingOptions:useTabs=false formattingOptions:tabSize=2 formattingOptions:indentationSize=2
    0	     6	  4804	       console-window-host (Windows internal process)
    0	    40	 24088	   utility-network-service
    0	   293	 24300	window [1] (MAIN-ZERO-ASPdotNET-Web-BE (Workspace))
    0	   114	 24460	   gpu-process
    0	    80	 26432	fileWatcher [1]
    0	    25	 26516	   crashpad-handler
    0	   100	 30084	window [2] (Issue Reporter)

Workspace Info
|  Window (MAIN-ZERO-ASPdotNET-Web-BE (Workspace))
|    Folder (ASPdotNET-Web-BE-Zero): 355 files
|      File types: cs(129) cache(36) json(22) csproj(9) props(9) targets(9)
|                  txt(9) editorconfig(9) v2(2) vsidx(2)
|      Conf files: csproj(9) sln(1);

Extensions (52)

Extension
Author (truncated)
Version

better-comments
aar
3.0.2

Bookmarks
ale
13.3.1

copy-relative-path
ale
0.0.2

All-Autocomplete
Ati
0.0.26

compare-view
che
0.13.0

vscode-better-align
cho
1.4.2

path-intellisense
chr
2.8.4

bracket-select
chu
2.0.2

vscode-structurizr
cia
0.0.9

gitignore
cod
0.9.0

csharp-grammar-extended
dan
1.1.1

githistory
don
0.6.20

xml
Dot
2.5.1

gitlens
eam
13.6.0

LogFileHighlighter
emi
2.16.0

json-tools
eri
1.0.2

auto-close-tag
for
0.5.14

auto-rename-tag
for
0.1.10

auto-using
Fud
0.7.15

copilot
Git
1.86.82

todo-tree
Gru
0.0.226

output-colorizer
IBM
0.1.2

open-file-from-path
jac
1.3.4

vscode-text-pastry
jkj
1.3.1

vscode-peacock
joh
4.2.2

workspace-cacheclean
Mam
0.0.2

render-crlf
med
1.6.1

vscode-filesize
mkx
3.1.0

csharp
ms-
1.25.7

vscode-dotnet-pack
ms-
1.0.12

remote-explorer
ms-
0.4.0

indent-rainbow
ode
8.3.1

material-icon-theme
PKi
4.27.0

vscode-thunder-client
ran
2.7.1

vscode-xml
red
0.25.0

partial-diff
ryu
1.4.3

bracket-jumper
sas
1.1.8

trailing-spaces
sha
0.4.1

svg-preview
Sim
2.8.3

cucumber
ste
0.14.0

code-spell-checker
str
2.20.4

ASPNETCore-VSCode-Extensions
Syn
21.2.3

Blazor-VSCode-Extensions
Syn
21.2.3

c4-dsl-extension
sys
3.4.1

bracket-padder
via
0.3.0

highlight-matching-tag
vin
0.11.0

intellicode-api-usage-examples
Vis
0.2.7

vscodeintellicode
Vis
1.2.30

vscodeintellicode-completions
Vis
1.0.22

vscode-todo-highlight
way
1.0.5

markdown-all-in-one
yzh
3.5.1

json
Zai
2.0.2

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30610678
2e4cg342:30602488
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
showlangstatbar:30737416
vsctsb:30748421
pythonms35:30701012
j16hj152:30706079
ecj1e332:30736112
pythonfmttext:30731395
fixshowwlkth:30730052
pythongtdpathcf:30739705

Additional info: I downgraded VSC to v1.77.3 ("GitLens" extension is downgraded to 13.5.0 also because its latest version is not compatible with VSC v1.77.3) and everything is much better. Sometimes staging and un-staging files are still slow a little bit but acceptable.

Same thing happened to me, a simple git diff was taking ~10 seconds with the new version. I downgraded to v1.77.3 and it also fixed my issue

I pulled some Ansible galaxy collections into my workspace (which changed a few hundred files) and the whole computer froze for several minutes. Never had this issue with previous versions of VSCode.
Using Fedora Linux 38.

I am not sure whether this is related, but GitLens started taking %100 CPU recently. I tracked the issue down to GitLens after removing all plugins and reinstalling them. Finally, I was able to discover that simply disabling/enabling GitLens was removing/reintroducing the CPU spike issue. My installation clean (since I tried to do a clean uninstall while trying to fix the issue). I am on Linux (Fedora) and I don't have Mcafee anti-virus. If it helps here is the offending process on my machine:
rafid      98244  4.3  0.1<PHONE_NUMBER> 174984 ?   Sl   12:56   0:13 /usr/share/code/code --type=utility --utility-sub-type=node.mojom.NodeService --lang=en-US --service-sandbox-type=none --enable-crash-reporter=8e552b7c-bb79-42bc-a9b4-fb0b1b3eefec,no_channel --user-data-dir=/home/rafid/.config/Code --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,11251309795413797203,11639842389012394509,131072 --disable-features=CalculateNativeWinOcclusion,SpareRendererForSitePerProcess

hi @gjsjohnmurray
I have the same issue and I also using Mcafee and have gitlens(who doesn't)

I'm not sure what the root cause of this is but this is what I observed in the last time:

After I switched back to 1.77.3, everything is much better (compare to v1.78.x, but not as fast as I experienced in the past)
After several days, things related to the source control are slow again, even when I disable GitLens extension
I updated VSC to 1.78.x again, not enable GitLens -> not consistent, in some workspaces it's fast, in some others, it's slow
I enabled GitLens again (in VSC 1.78.x) -> still the same (not consistent)
I updated VSC to 1.79, with GitLens enabled -> everything is fast again (as it should be and as I experienced before), now using source control in VSC is a joy (again) to me :)

Note: in VSC 1.79, staging multiple modified files is still slow a little bit (but still good enough and acceptable, just as before) -> it would be nice if it can be as fast as when I use git bash :)

@chriscarreau @ChristianCiach @rafidka , maybe you should try updating VSC to the latest version (1.79) to check if the issue is resolved or not. If all of us are okay with the latest update of VSC, we can close this ticket :)

I have just updated to 1.80 and source control takes a minute or two to load up. Whenever we open vs code before, it used to be almost instant. Although it's still better than the previous 1.78 and/or 1.79.

The source Control tab is very slow for me. When I click to view the changed file in the tab. Happen with both MacOS and Windows. I doubt it is related to the network, but why if I use in command line it is very fast.
https://github.com/microsoft/vscode/assets/300961/57c441c5-a38c-4125-85d7-f1b5968179cb

I'm trying to figure this out, too. I think (at least in my case) that it might relate to the number of open files. It's running a "git ls-files --stage -- " and a "git show --textconv " for each file, along with a bunch of "git cat-file -s ". After each of these operations, it's displaying millisecond counts in the 10000 range.
Cutting and pasting these commands into a terminal window results in fairly quick execution, so there must be something else going on (processing the output?). The commands might make sense after a sync, though why it would go through all the files that were not touched in the pull/fetch is not clear.

I noticed if the folder opened in vscode consists of a bunch of sub git folders, the git version control will be much slower than a folder with only 1 git repository/folder.

Hey @lszomoru, this issue might need further attention.
@gh-egs-vividcloud, you can help us out by closing this issue if the problem no longer exists, or adding more information.

I confirm that this issue is still occurring.
Info:
$ code --version
1.83.1
f1b07bd25dfad64b0167beb15359ae573aecd2cc
x64

$ uname -r
5.15.0-86-generic

I am also seeing this issue on Windows 11 Home 22H2 (build 22621.2283).
$ code --version
1.83.1
f1b07bd25dfad64b0167beb15359ae573aecd2cc
x64

I have the same problem
Version: 1.83.1 (user setup)
Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
Date: 2023-10-10T23:48:05.904Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621

This is an example from my Git output, certain commands are taking a very long time.
git push origin master:master [69043ms]

I'm having these problems as well in 1.84.0

I'm having this issue in win10 pro 19045.3696, with feature experience pack 1000.19053.1000.0
$ code --version
1.82.3
fdb98833154679dbaa7af67a5a29fe19e55c2b73
x64

Running VSCode 1.84.2 on Ubuntu and seeing the same thing - source control features are ridiculously slow recently. This includes the built-in git features (staging, unstaging, committing, pushing, etc. As well as extensions that tie into the git environment, like gitlens.
Version: 1.84.2
Commit: 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
Date: 2023-11-09T10:50:47.800Z
Electron: 25.9.2
ElectronBuildId: 24603566
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.2.0-36-generic snap

I'm also experiencing this - terminal windows are very slow to open since the last update, though they appear to work nicely enough once they've loaded.

code --version
1.84.2
1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
x64
it's unusably slow for me.  CLI is nice and speedy but anything through the UI is worthless.

code --version 1.84.2 1a5daa3 x64
it's unusably slow for me. CLI is nice and speedy but anything through the UI is worthless.

I have a same issue on Macbook M1

Same issue here on Mac Sonoma with M1 Pro. Did you find any solution?

I have a same issue on Windows 11
Is there any solution?
code --version
1.85.1
x64
git version 2.43.0.windows.1
Edition	Windows 11 Pro
Version	23H2
OS build	22631.2861
Experience	Windows Feature Experience Pack 1000.22681.1000.0

I've been running into the same thing on Windows 11.
1.85.1
0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
x64
Since a couple of people mentioned that they saw issues connected to GitLens I tried disabling it and things work much faster. It's a shame because the GitLens adds some useful features but that seems to be what's slowing everything down. Seems like that's the place to look for the performance issues.

I am noticing a similar issue. I am running WSL2 on Windows 10 Enterprise Version 21H2
$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy

$ code --version
1.86.2
903b1
x64

I have uninstalled GitLens v14.8.2.
When I change a file in the editor and save it the integrated Git doesn't track the file unless I click the refresh button.

I am noticing a similar issue. I am running WSL2 on Windows 10 Enterprise Version 21H2
$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy

$ code --version
1.86.2
903b1
x64

I have uninstalled GitLens v14.8.2.
When I change a file in the editor and save it the integrated Git doesn't track the file unless I click the refresh button.

Sorry! After uninstalling GitLens I forgot to restart VSCode. This fixed my similar issue.

Hi,
Still experiencing this problem on Code 1.87 and git 2.44.0. Reverting Code to 1.77.3 makes integrated version control fast again.
If there's anything I can do to help, let me know.

I recently started seeing this about a month ago. I'm currently using WSL Ubuntu 22.04 and VS Code 1.87.0. Integrated GIT control takes a bout 3 minutes to startup when opening a new VS Code window, but once it finishes starting up it works perfectly.

I'm not based in the US and have this problem as well.  Definitely related to source control.  Downgrading to v1.77.3 seems to have solved it for now.

I solved this by disabling IPv6 in the network adapter settings on Windows. This also fixed npm which was also really slow/not working.
Control Panel -> Network and Internet -> Network and Sharing Centre -> Change adapter settings -> Right click on the network adapter (Ethernet in my case) -> Properties -> Uncheck the box for Internet Protocol Version 6 (TCP/IPv6).

Same issue here:
Visual Studio Code

Version: 1.87.2 (Universal)
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
Date: 2024-03-08T15:21:31.043Z (2 wks ago)
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 23.3.0

MacBook Air

M2, 2022
16 GB
14.3.1 (23D60) (Sonoma)

Git

git version 2.39.3 (Apple Git-145)
OR
git version 2.44.0 (Homebrew)

Same for me since over a week:
Some git operations lasts above 10 seconds:

2024-03-27 17:06:15.593 [info] > git status -z -uall [45ms]
2024-03-27 17:06:42.206 [info] > git config --get commit.template [10106ms]
2024-03-27 17:06:42.209 [info] > git ls-tree -l HEAD -- C:\DocDD\Inrae\airGR_galaxy\02-Sources\airGRiwrm\tests\testthat\test-RunModel_Ungauged.R [10111ms]
2024-03-27 17:06:42.212 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) --ignore-case refs/heads/130-ungauged-node-diversion-to-reservoir-crashes-calibration refs/remotes/130-ungauged-node-diversion-to-reservoir-crashes-calibration [10108ms]
2024-03-27 17:06:42.258 [info] > git status -z -uall [43ms]

Version: 1.87.2 (user setup)
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
Date: 2024-03-08T15:20:17.278Z
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19045

Same issue here:
Visual Studio Code

Version: 1.87.2 (Universal)
Commit: 863d258
Date: 2024-03-08T15:21:31.043Z (2 wks ago)
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 23.3.0

MacBook Air

M2, 2022
16 GB
14.3.1 (23D60) (Sonoma)

Git

git version 2.39.3 (Apple Git-145)
OR
git version 2.44.0 (Homebrew)

It seems this issue has been fixed with:
Version: 1.88.0 (Universal)
Commit: 5c3e652f63e798a5ac2f31ffd0d863669328dc4c
Date: 2024-04-03T13:28:18.899Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.3.0
I do not experience the sluggishness like in the previous comment.

Been experiencing the same issue for a while, currently running 1.88.1 and still experience it.
Remove the GitLens extension last Friday and source control view went back to being near instant - but today it's very very slow again, so suspect the extension isn't the cause but might exacerbate it.
Running VSCode in Win11 connected to Ubuntu 22.04 instance in WSL.

For me, uninstalling GitLens made things faster.

same issue after upgrade. I had to switch to web storm for smooth workflow. Waiting for the fix 🤞🏻

I am also facing this same issue in:
Version: 1.90.0
Commit: 89de5a8d4d6205e5b11647eb6a74844ca23d2573
OS: Windows_NT x64
I switched about 4 days ago
other terminal like PowerShell are working smoothly on the integrated environment however, git bash is slow. However, only running the git bash (not on vs code ) seems to be working smoothly

I reinstalled Git Bash from Get site on Windows. Opening the terminal via the context menu in the folder opens normally. But in OUR Code, it runs for 3-5 seconds. And after each command, after they are executed, you have to wait for 5 seconds. Yesterday I was working on a project, and the terminal was open for several hours. After these few hours of work, the waiting time increased to 10-15 seconds. I also deleted it .bash_profile and .bash_history, nothing helped. How can I use Git bash terminal in VS Code without delays, as it was before? Just the other day, the waiting time began to exceed 3 seconds, which makes it impossible to continue development. (((

There is a known performance issue with git bash in 1.90. See the currently pinned issue. A fix is expected in 1.90.1.

Additionally to above:

I just saw that settings "terminal.integrated.shellIntegration.enabled" to false fix the issue. This settings seem to impact other issue related to other terminal too
#214386

In my case it fixed performance issues mentioned in this topic. Also with source control tab.

just disabled shell integration terminal may fix the issued it work for me

For my case, "terminal.integrated.shellIntegration.enabled" not work as expected. Performance has improved, but not totally same as before.

Setting terminal.integrated.shellIntegration.enabled to false fixes this issue as mentioned in #212090 and #214407 .

Same here. Impossible to work with. We're getting 33426 ms and more response times.
It is only during initialisation. After waiting approximately 15 minutes all is fine.
During that period there is a lot of network traffic on the interface. Around 2.5 Gbit (3Mbit/second).
Native git-client in Windows 11 acts fine.
git count-objects -vH
count: 391
size: 611.57 KiB
in-pack: 13883
packs: 1
size-pack: 3.22 MiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes

2024-07-08 17:35:58.410 [info] > git symbolic-ref --short refs/remotes/origin/HEAD [417ms]
2024-07-08 17:35:58.410 [info] fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
2024-07-08 17:35:58.410 [info] GitHistoryProvider:resolveHistoryItemGroupBase - Failed to resolve history item group base for 'refs/heads/develop'
2024-07-08 17:35:58.410 [info] GitHistoryProvider:resolveHistoryItemGroupCommonAncestor - Failed to resolve history item group base for 'refs/heads/develop'
2024-07-08 17:35:58.676 [info] > git cat-file -s 16f10ef654440266051f93847f83b08c6d67cc71 [1350ms]
2024-07-08 17:35:59.547 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) --ignore-case refs/heads/develop [1110ms]
2024-07-08 17:36:00.475 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) --ignore-case refs/heads/develop [925ms]
2024-07-08 17:36:02.606 [info] > git config --local branch.develop.vscode-merge-base [2064ms]
2024-07-08 17:36:02.606 [warning] git config failed: Failed to execute git
2024-07-08 17:36:03.402 [info] > git status -z -uall [33426ms]
2024-07-08 17:36:05.519 [info] > git reflog refs/heads/develop --grep-reflog=branch: Created from *. [2766ms]
2024-07-08 17:36:08.803 [info] > git reflog HEAD --grep-reflog=checkout: moving from .* to develop [3136ms]

Version: 1.90.2 (user setup)
Commit: 5437499feb04f7a586f677b155b039bc2b3669eb
Date: 2024-06-18T22:34:26.404Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Windows_NT x64 10.0.22631

I was having a similar issue here. VSCode's called git.exe  process was eating up all system resources and taking ages to complete -- only to then be called again.
In my case I could notice only the git reflog command was taking long time and resources (and memory) to run.
VSCode Git Console log
2024-08-21 19:41:02.457 [info] > git status -z -uall [98ms]
2024-08-21 19:41:02.540 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) --ignore-case refs/heads/master refs/remotes/master [72ms]
2024-08-21 19:41:02.628 [info] > git config --local branch.master.vscode-merge-base [80ms]
2024-08-21 19:41:02.628 [warning] [Git][config] git config failed: Failed to execute git
2024-08-21 19:43:35.516 [info] > git reflog master --grep-reflog=branch: Created from *. [166808ms]
2024-08-21 19:43:35.547 [info] > git reflog master --grep-reflog=branch: Created from *. [167047ms]
2024-08-21 19:43:35.621 [info] > git symbolic-ref --short refs/remotes/origin/HEAD [96ms]
2024-08-21 19:43:35.621 [info] fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
2024-08-21 19:43:35.649 [info] > git symbolic-ref --short refs/remotes/origin/HEAD [93ms]
2024-08-21 19:43:35.649 [info] fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
2024-08-21 19:43:35.726 [info] > git merge-base refs/heads/master refs/remotes/origin/master [96ms]
2024-08-21 19:43:35.810 [info] > git -c core.longpaths=true rev-list --count --left-right refs/heads/master...refs/remotes/origin/master [74ms]
2024-08-21 19:43:35.882 [info] > git diff --name-status -z --diff-filter=ADMR c39d29fb60ea50d5dfe4ec65fd99cc6ab47d394b...refs/remotes/origin/master [64ms]
2024-08-21 19:43:48.197 [info] > git reflog master --grep-reflog=branch: Created from *. [165559ms]
2024-08-21 19:43:48.277 [info] > git symbolic-ref --short refs/remotes/origin/HEAD [71ms]
2024-08-21 19:43:48.277 [info] fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
2024-08-21 19:49:50.672 [info] > git config --get commit.template [90ms]

Turns out my repo's .git/logs/refs/heads/master file was 2GB big, such like
$ du -sh .git
2.1G    .git
# (...) dig thru the directory structure (...)
$ du -sh logs/refs/heads/*
2.1G    logs/refs/heads/master

That was a brand new repository, 2MB worth of data, 3 commits total to its single master branch, no big bloat-cleaning commits. So, there was no reason the repo had a 2GB big log. I then found this issue and tried to disable git. Of course it fixed the CPU load. terminal.integrated.shellIntegration.enabled=false didn't help, as I still saw git reflog commands run.
Then I realized, as all that log was bloat, all I needed to do was
git gc
And voila
$ du -sh .git
618K    .git

And VSCode was back to speed. In case anybody else face this issue and, like me, ends up in this GitHub Issue, git-gc was the solution. I still have no idea why the repo log grew up so much in so little time (repo created today).
My VSCode version info:
VS Code version: Code 1.92.2 (fee1edb8d6d72a0ddff41e5f71a671c23ed924b9, 2024-08-14T17:29:30.058Z)
OS version: Windows_NT x64 10.0.19045

I'm on 1.93.0 and just started to experience these slowdowns for the past two days when working with Rust and Burn. git gc did not solve the issue for me, but removing the Trunk extension or editing the default .gitignore in the .trunk folder within the project did. The extension locks up certain aspects of my VSC like git when the project directory contains a ton of training and validation logs from Burn.

I'm still experiencing the issue with the latest version 1.94.1.
Beside what was already mentioned here, I'm also not able to see the difference of my changed files for ages. Sometimes after 20 Minutes or so, it will suddenly show me the differences, but in such a state it's very much unusable for productive work.

Setting terminal.integrated.shellIntegration.enabled to false fixes this issue as mentioned in #212090 and #214407 .

Thanks! This fixes it. I think more people should see it.

I am having same issue in latest version 1.94 and Insider version 1.95.
if you open multiple files from diff then it reproducible.

I'm experiencing this issue on  the latest release version of vscode(1.95), it has taken upwards of 20 minutes to commit to the main branch and is still committing.

the same 1.95.2

Same for me:
Version: 1.95.3 (Universal)
It happens every time I compile (webpack.mix). Closing VS Code is the only solution to release CPU and allow the task to pursue.
Quite annoying in prod.

When I run du -sh .git, I get 6 GB, before and after running git gc.  However, after running git gc, this problem is 100% fixed for me, and git is fast again from the lastest version (1.95.3) of vscode in WSL2 on Windows 11.


Incorrect indentation of Handlebars inline partials

Input
The code looked like this before beautification:
{{#*inline "MyInlinePartial"}}
{{MyIdentifier}}
{{/inline}}

Expected Output
The code should have looked like this after beautification:
{{#*inline "MyInlinePartial"}}
    {{MyIdentifier}}
{{/inline}}

Actual Output
The  code actually looked like this after beautification:
    {{#*inline "MyInlinePartial"}}
        {{MyIdentifier}}
        {{/inline}}

Steps to Reproduce
Settings
Example:
{
    "indent_handlebars": true
}

Inline Partials: https://handlebarsjs.com/guide/partials.html#inline-partials
This pattern recognizer is looking for {{# or {{^ which is fine...
https://github.com/beautify-web/js-beautify/blob/ae3e9e6b1c47487c72f92951333b2944dd5160b0/js/src/html/beautifier.js#L608-L609
but this this line thinks the name of the tag is *inline when it is actually inline.
https://github.com/beautify-web/js-beautify/blob/ae3e9e6b1c47487c72f92951333b2944dd5160b0/js/src/html/beautifier.js#L618
Should someone have time to fix this, they'll need to add a check for * and then add tests.


Brick without input fields does not have a save button

when a brick model has the method
def user_can_save?
  true
end

and the _edit.html.haml partial is empty (does not have any input fields)
then the save button is not shown in the backend.
This makes it impossible to save custom styles.

PR


Scavengers: Add Recycled Hunts functionality

This adds a database of recycled hunts that Scavengers room staff can start and also auto-queue for times when the room is slow. This has been discussed with appropriate room staff.
The database itself is just JSON that is loaded and worked with in memory. Any changes that are made are immediately written back out to the JSON file.
The main way to interact with the database is through a new master command /recycledhunts. It is possible to add hunts, remove hunts, add hints, remove hints, and to enable/disable the auto-queue functionality through this command.
The existing queue and create commands were also updated to work with recycled hunts. Staff are able to queue and create either a random or specific recycled hunt from the database.
I think I updated and created all appropriate help text as well.
As always, let me know if anything needs changing and I'll take care of it.

@xfix, changes done.


max identifier length changed to 63

[x ] Do only one thing
[ x] Non breaking API changes
[ x] Tested

What did this pull request do?
default max identifier length changed to 63

See issue here
It adds max Identifier Length in Naming strategy which can be overridden by individual drivers of gorm.
User Case Description

@jinzhu once these changes are merged i will create pull request in all drivers to support this change.
Thanks

Hi @alidevhere
Thank you for the max length support, but maybe we should keep the old configuration by default to make sure old applications not using Postgres don't break.

Hi @alidevhere
Thank you for the max length support, but maybe we should keep the old configuration by default to make sure old applications not using Postgres don't break.

Should we change default max length identifier to old 64 instead of 63 ?

Hi @alidevhere
Thank you for the max length support, but maybe we should keep the old configuration by default to make sure old applications not using Postgres don't break.

@jinzhu Should we change default max length identifier to old 64 instead of 63 ?

Better to keep the current setting to keep compatibility.

Hi @alidevhere
Thank you for the max length support, but maybe we should keep the old configuration by default to make sure old applications not using Postgres don't break.

@jinzhu Should we change default max length identifier to old 64 instead of 63 ?

Better to keep the current setting to keep compatibility.

@jinzhu  Changes reverted to current settings. Ready for review


firebase_analytics not reporting in streaming on setCurrentScreen

If I run the setCurrentScreen in the example app in flutter it doesn't show up in the StreamView of Firebase Analytics.  However, if I run setCurrentScreen and then I run test standard event types I get all the event types logged and I get the setCurrentScreen event.  Is this expected behaviour?  Should I be seeing the setCurrentScreen event in the StreamView after I click the button?

@RoughIndustries
The issue at https://github.com/flutter/flutter/issues/26432 has been closed and moved here. Future collaboration on this issue will be done here.

Hi @RoughIndustries
If you are still experiencing this issue
with the latest version of Flutter and FlutterFire plugin
can you please provide your updated  flutter doctor -v
and your and your flutter run --verbose/flutter build --verbose ?
Also, to better address the issue, would be helpful
if you could post a self contained app on github
or the steps to reproduce it.
Thank you

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of 'flutter doctor -v'  please.
All system setups can be slightly different so its always better to open new issues and reference related issues.


Images stretched incorrectly

From http://dev.blog.stackexchange.com/2015/06/stack-overflow-in-portuguese-now-with-less-beta/

Some width and height attributes remained from the port that's screwing up the CSS. Fixed with https://github.com/StackExchange/blog/commit/87bc640bd6100b28a1062986f5972e34df08dc9a


Bump version to 2.5.0

We haven't had a release for the past 3 months :shipit:
2.5.0 (2021-09-21)

Declare autocorrect as unsafe for ExpectChange. ([@francois-ferrandis][])
Fix each example for RSpec/HookArgument. ([@lokhi][])
Exclude unrelated Rails directories from RSpec/DescribeClass. ([@MothOnMars][])
Add RSpec/ExcessiveDocstringSpacing cop. ([@G-Rath][])
Add RSpec/SubjectDeclaration cop. ([@dswij][])
Fix excessive whitespace removal in RSpec/EmptyHook autocorrection. ([@pirj][])
Bump RuboCop requirement to v1.19.0. ([@pirj][])
Fix false positive in RSpec/IteratedExpectation when there is single, non-expectation statement in the block body. ([@Darhazer][])

Thank you @Darhazer! :tada: :smile:


Add support for this in function definitions

Please do not update the README or Change Log, we will do this when we merge your PR.
This PR

Adds a new feature into TS Parser
Fixes an issue #4669

Describe the changes below:

Add support for generating function typescript definitions with this param
It is now possible to generate functions like this:type FunctionType = (this: SomeObject, param1: number) => void;

Try this functionality by fixing #4669

👍


Some questions about Android & iOS (lockScreen, open app directly since lockScreen, ask password, ...)

Hello,
Thx for the lib :D
On Android :
I have a small problem, when I receive a push notification on Android (android 9 - redmi note 5) in lockscreen... the fullscreen appears less than a second and after, it is replaced by a notification (in the list of visible notifications) that sounds (as if the phone was already in use)
What could make the fullscreen not stay all the time (instead of being replaced by a notification) ?
On the DEMO application, with the launch 7sec later, it works correctly.
On iOS :
It's the opposite, i always have the fullscreen, even when the application is launched (instead of having the alert mode).
On the DEMO, I have the same behavior (no alert mode)
### UPDATE :
On Android :
Now i have the fullscreen ring call :) i think my id on 'id param' won't regenerate so i keeping with the same id ... now i re-generate every call and fullscreen appears and stay !
But i have another bug on Android, if i accept the phone call fullscreen disappears but i stay in lockscreen (phone don't ask password ...), and if i unlock manually the apps will launch as expected.
If i disable my password, le fullscreen phone call AND alert notification will pop .... BUT if i accept call, the application will launch automatically as expected :)
I think it's a bug here (specific to Xiaomi phone ?)

Hello,
thx for the response and new version.
I use only physical devices (redmi note 5 -> Android 9 | 2 iphones 7 -> iOS 13.1.2 & iOS 15.2).
I also test demo app in physical iPhone. This morning (bonjour la France), i run in my personal iPhone (iOS 15.2) and alert box call pop when app running or in homescreen iPhone, and in lockscreen mode it's fullscreen ! So it's work's in iOS 15.
Yesterday, i test in iOS 13 and it's only fullscreen phone call available. I do little searchs and i found this :
https://www.iphonetricks.org/how-to-use-the-new-phone-calls-user-interface/
I think "Incoming call Banner" was only available on iOS14+, do you confirm ?
I have a question on iOS (version 1.0.1+1 / 1.0.1+2) :
When i use password (or touch ID) to unlock iPhone and i receive incoming call, if i accept the call, the screen change with time, mute/switch micro/ etc buttons appears and app switch button too (use to navigate to the app).
=> It's possible to navigate DIRECTLY to the app when i accept the call in lockScreen fullscreen incoming call ?

In Android on versions 1.0.1+2 :
i update (demo app & my app) and impossible to run, i have this on compilation
Launching lib/main.dart on Redmi Note 5 in debug mode...
Running Gradle task 'assembleDebug'...
e: /Users/kevinmoreau/.pub-cache/hosted/pub.dartlang.org/flutter_callkit_incoming-1.0.1+2/android/src/main/kotlin/com/hiennv/flutter_callkit_incoming/CallkitNotificationManager.kt: (189, 58): Unresolved reference: CATEGORY_MISSED_CALL
e: /Users/kevinmoreau/.pub-cache/hosted/pub.dartlang.org/flutter_callkit_incoming-1.0.1+2/android/src/main/kotlin/com/hiennv/flutter_callkit_incoming/CallkitSoundPlayerService.kt: (47, 70): Unresolved reference: S
e: /Users/kevinmoreau/.pub-cache/hosted/pub.dartlang.org/flutter_callkit_incoming-1.0.1+2/android/src/main/kotlin/com/hiennv/flutter_callkit_incoming/CallkitSoundPlayerService.kt: (48, 66): Unresolved reference: VIBRATOR_MANAGER_SERVICE
e: /Users/kevinmoreau/.pub-cache/hosted/pub.dartlang.org/flutter_callkit_incoming-1.0.1+2/android/src/main/kotlin/com/hiennv/flutter_callkit_incoming/CallkitSoundPlayerService.kt: (48, 95): Unresolved reference: VibratorManager

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':flutter_callkit_incoming:compileDebugKotlin'.
> Compilation error. See log for more details

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 30s
Exception: Gradle task assembleDebug failed with exit code 1

So for my question (on android in my last post), i couldn't check if the problem is resolved :/

For iOS,
can only navigae directly into the app when using type: 1 (video call)
for Audio, you can only switch to the app with the button switch app.

For android, please make sure build version min 31.
https://github.com/hiennguyen92/flutter_callkit_incoming/blob/ebe1e7d1472a331c23236a9450294de392ffa7d0/example/android/app/build.gradle#L29

For iOS, can only navigae directly into the app when using type: 1 (video call) for Audio, you can only switch to the app with the button switch app.

I put "1" on type in my dart file & appDelegate swift but it's always stay on phone call screen with button switch app...
Maybe i miss something else ???
DART side :
this._currentUuid = _uuid.v4();       var params = <String, dynamic>{         'id': _currentUuid,         'nameCaller': 'Hien Nguyen',         'appName': 'Callkit',         'avatar': 'https://i.pravatar.cc/100',         'handle': '0123456789',         'type': 1,         'duration': 30000,         'extra': <String, dynamic>{'userId': '1a2b3c4d'},         'headers': <String, dynamic>{           'apiKey': 'Abc@123!',           'platform': 'flutter'         },         'android': <String, dynamic>{           'isCustomNotification': true,           'isShowLogo': false,           'ringtonePath': 'system_ringtone_default',           'backgroundColor': '#0955fa',           'background': 'https://i.pravatar.cc/500',           'actionColor': '#4CAF50'         },         'ios': <String, dynamic>{           'iconName': 'CallKitLogo',           'handleType': '',           'supportsVideo': true,           'maximumCallGroups': 2,           'maximumCallsPerCallGroup': 1,           'audioSessionMode': 'default',           'audioSessionActive': true,           'audioSessionPreferredSampleRate': 44100.0,           'audioSessionPreferredIOBufferDuration': 0.005,           'supportsDTMF': true,           'supportsHolding': true,           'supportsGrouping': false,           'supportsUngrouping': false,           'ringtonePath': 'system_ringtone_default'         }       };       await FlutterCallkitIncoming.showCallkitIncoming(params);
iOS swift side :
`func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) {
    guard type == .voIP else { return }

    let id = payload.dictionaryPayload["id"] as? String ?? ""
    let nameCaller = payload.dictionaryPayload["nameCaller"] as? String ?? ""
    let handle = payload.dictionaryPayload["handle"] as? String ?? ""
    let isVideo = payload.dictionaryPayload["isVideo"] as? Bool ?? false

    let data = flutter_callkit_incoming.Data(id: id, nameCaller: nameCaller, handle: handle, type: 1)
    SwiftFlutterCallkitIncomingPlugin.sharedInstance?.showCallkitIncoming(data, fromPushKit: true)
}`

https://raw.githubusercontent.com/hiennguyen92/flutter_callkit_incoming/master/images/image1.png
you swipe to answer and then will ask for password/touch id/face id and then will open main app.

I have the swiper to answer but no password asking ... only 2nd screen with options buttons in screen

https://user-images.githubusercontent.com/3755347/155556340-a3bd08b8-4a11-4fa5-8202-f1f4da5b6916.mp4

I just edit my post, but i re-post this here :
i have this case ONLY on iOS 13 ! It's work fine on iOS 15.
I will check with emulator iOS 14 if i have this case

Simulator is not working with callkit, so can only test with real device

What is your iOS version ?

https://user-images.githubusercontent.com/3755347/155557821-92806458-11dc-44fb-b17b-1d2bfe1e2f41.mp4
it seems to be related to the iOS version
Working with iOS 15
Not working with iOS 12, 13

and iOS 14 ? Same as iOS 15 ?

I don't have iOS14 to test it.

Ok, i will looking for an iOS14 and i will notice you !
I test 1.0.1+2 version on Android (after refacto in my project because it didn't compile on compileSdkVersion 31) and it's work good (no more bug on silent mode with ringtone ;) )

@hiennguyen92 @kmoreau quick question, when the screen in locked and the app is completely terminated, when I accept a call on android, I don't a prompt to unlock my device. This works fine when the app is open in the background and not terminated though. Any suggestions?

Error requesting transaction: Error Domain=com.apple.CallKit.error.requesttransaction Code=4 "(null)"
Received data: {
error =     {
id = "";
message = "Token not found";
};
success = 0;
}
Received data: {
error =     {
id = "";
message = "Token not found";
};
success = 0;
}

Please make sure using real device(not simulator)


Crop widget interaction sticks

Steps:

Load volume, use crop widget, mouse drag one corner to execute a crop.
Stop mouse drag, crop occurs.

Problem: though the mouse drag has stopped, the widget still behaves as though the mouse is down. Sometimes it takes several clicks to get out of this state.

I've noticed that as well sometime.
I was wondering if the listener I put to activate the view on click was eating the event.
Didn't get a chance to investigate

:tada: This issue has been resolved in version 2.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[TW#26873] How does ESP32 get gateway IP in STA mode？

How does ESP32 get gateway IP in STA mode？Is there a relevant API to use？

Hi @ChampOnBon you can call tcpip_adapter_get_ip_info() to get the IP address

@ChampOnBon Could you help share if any updates for this issue? Thanks.


Update build such that dist/docs is not updated every time

This will require that when a release is done, the grunt task ngdocs:publish is run and the doc changes are pushed at that point.

LGTM. Much cleaner code reviews

So I downloaded this repo/branch and ran 'grunt build' who's 'grunt clean:all' deletes the 'dist/docs' dir, so now my unstaged git changes shows all the missing 'dist/docs' dir.
Think we need to replace the 'clean:all' with more target dist cleans, leave the dist/docs as is until 'grunt ngdocs:publish' updates 'dist/docs'.

This seemed to do it:
clean: {
...
...
all: ['dist/*', '!dist/docs']
},

Might want to add a 'clean:distdocs' to the ngdocs:publish task so that we start with a clean dist/docs dir before copying in all files from 'docs'.

@dtaylor113 I have addressed both concerns

LGTM


Add Hindi glossary entry for "logging"

Add Hindi glossary entry for "logging"
Description
#Fixes Localizes content/en/docs/reference/glossary/logging.md to Hindi content/hi/docs/reference/glossary/logging.md

Thank You for the PR
Changes look Good to me

/assign @dipesh-rawat  Pls approve. If any more changes required pls suggest. Thanks!!


Allow vertical resizing of container for any component

WIP, will continue this later - need access to element inner rects as in https://github.com/mui/mui-toolpad/pull/814

Outdated, and not sure if we would use this approach for vertical resizing in the future, so closing.


fix: adjust the size of badge images (resolves #413)

[X] This pull request has been linted by running npm run lint without errors
[X] This pull request has been tested by running npm run start and reviewing affected routes
[X] This pull request has been built by running npm run build without errors
[X] This isn't a duplicate of an existing pull request

Description
Badge images should be smaller and displayed in proportion.
Steps to test

Go to the Badges page

Expected behavior:
The size of badges images are good.
@uttaraghodke, can you take a look at badge images in the deploy preview and let me know if they look better? Thanks.

Looks good to Uttara.


Use base class for Online and Offline

The Simvue function which chooses between offline and online versions of the core functionality now selects between two classes which inherit from a common base class.
This has the advantage of ensuring that methods are present in both and the Simvue client requires no knowledge of which it is using calling the inherited methods.
The code for these changes can be found within the simvue/factory sub-directory.
simvue.factory
class SimvueBaseClass(abc.ABC):
    @abc.abstractmethod
    def __init__(self, name: str, uniq_id: uuid.UUID, suppress_errors: bool) -> None:
        self._logger = logging.getLogger(f"simvue.{self.__class__.__name__}")
        self._suppress_errors: bool = suppress_errors
        self._uuid: str = uniq_id
        self._name: str = name
        self._id: typing.Optional[int] = None
        self._aborted: bool = False

    def _error(self, message: str) -> None:
        """
        Raise an exception if necessary and log error
        """
        if not self._suppress_errors:
            raise RuntimeError(message)
        else:
            self._logger.error(message)
            self._aborted = True

    @abc.abstractmethod
    def create_run(self, data: dict[str, typing.Any]) -> typing.Optional[dict[str, typing.Any]]:
        pass

    ...

There is extensive use of skip_if_failed in simvue/factory/remote.py but skip_if_failed isn't actually defined:
  File "/Users/andrewlahiff/Work/Observability/client_check_151_v2/client/simvue/run.py", line 17, in <module>
    from .factory import Simvue
  File "/Users/andrewlahiff/Work/Observability/client_check_151_v2/client/simvue/factory/__init__.py", line 1, in <module>
    from .remote import Remote
  File "/Users/andrewlahiff/Work/Observability/client_check_151_v2/client/simvue/factory/remote.py", line 6, in <module>
    from simvue.utilities import (
ImportError: cannot import name 'skip_if_failed' from 'simvue.utilities'

There is extensive use of skip_if_failed in simvue/factory/remote.py but skip_if_failed isn't actually defined:
  File "/Users/andrewlahiff/Work/Observability/client_check_151_v2/client/simvue/run.py", line 17, in <module>
    from .factory import Simvue
  File "/Users/andrewlahiff/Work/Observability/client_check_151_v2/client/simvue/factory/__init__.py", line 1, in <module>
    from .remote import Remote
  File "/Users/andrewlahiff/Work/Observability/client_check_151_v2/client/simvue/factory/remote.py", line 6, in <module>
    from simvue.utilities import (
ImportError: cannot import name 'skip_if_failed' from 'simvue.utilities'

I have re-added the missing function

References to get_server_version in simvue/factory/remote.py need to be removed as get_server_version no longer exists:
diff --git a/simvue/factory/remote.py b/simvue/factory/remote.py
index 711fd64..7f6470c 100644
--- a/simvue/factory/remote.py
+++ b/simvue/factory/remote.py
@@ -7,7 +7,6 @@ from simvue.utilities import (
     get_auth,
     get_expiry,
     prepare_for_api,
-    get_server_version,
     skip_if_failed,
 )
 from simvue.factory.base import SimvueBaseClass
@@ -34,7 +33,6 @@ class Remote(SimvueBaseClass):
         self._headers_mp: dict[str, str] = self._headers | {
             "Content-Type": "application/msgpack"
         }
-        self._version: typing.Optional[int] = get_server_version()
         super().__init__(name, uniq_id, suppress_errors)

     @skip_if_failed("_aborted", "_suppress_errors", (None, None))

There's an argument to Remote missing in simvue/sender.py:
diff --git a/simvue/sender.py b/simvue/sender.py
index 101ca89..7375607 100644
--- a/simvue/sender.py
+++ b/simvue/sender.py
@@ -103,7 +103,7 @@ def sender():
         else:
             logger.info('Considering run with no name yet and id %s', id)

-        remote = Remote(run_init['name'], id, suppress_errors=True)
+        remote = Remote(run_init['name'], id, "offline", suppress_errors=True)

         # Check token
         remote.check_token()