Ensure deterministic error code generation

Description
Different locale settings can affect the order that error code is generated (specifically relating to how periods are ordered compared with letters). Forcing LC_ALL=C creates a consistent approach.
The problem lies in the order grep finds files. On my system, it was finding pk.h after pkcs5.h, which created a difference between my view of the world and the Travis view.
Status
READY
Requires Backporting
NO
Migrations
NO
Additional comments
NO
Steps to reproduce
To reproduce the original problem, try running the check-generated-files.sh test under a British locale:
LC_ALL="en_GB.UTF-8" ./tests/scripts/check-generated-files.sh

This will generate the error file in a different order, causing the script to fail.
With my updated script, the above test would pass.

Hi @dmjones500
Thank you for your fix!
For the record, information on LC_ALL can be found here

Do we have other scripts that would be made more deterministic by setting LC_ALL=C?
(I think there is no need to delay this PR for this, but we might still want to either check other scripts, or just set LC_ALL=C in all of them preventively.)

@mpg I agree, and created an issue in https://github.com/ARMmbed/mbedtls/issues/1057

@gilles-peskine-arm Seems like this PR is ready for merge. An issue has been created to consider similar changes on other scripts, meanwhile we can merge this PR as it has been already demonstrated helpful in certain cases.

Thanks you for this, it was indeed a lack in the script. However I prefer the approach in #1134 which bypasses the problem altogether. Since #1134 is <nudge> almost ready to merge, I'd rather take #1134 instead.

This change looks good to me. However, I think the mechanism used by the script is slightly fragile. This is the reason why #1134 was created.

Hi @dmjones500
Thanks for your PR! We've merged a fix for this issue via #1134. I'll close this PR now that #1134 is merged.
Thanks!


View goes blank on clicking the settings button for any group

I made a bunch of groups and a custom layout for my home space in the 9.2 version. Just upgraded to 9.3 and on clicking the dots button for any group makes the obsidian view go blank and leaves obsidian unusable. Please see images

Same problem here...

This should be patched in the version released earlier tofay
Get Outlook for iOShttps://aka.ms/o0ukef

From: Chris @.>
Sent: Sunday, February 25, 2024 8:51:48 AM
To: Make-md/makemd @.>
Cc: Subscribed @.***>
Subject: Re: [Make-md/makemd] View goes blank on clicking the settings button for any group (Issue #282)
Same problem here...
—
Reply to this email directly, view it on GitHubhttps://github.com/Make-md/makemd/issues/282#issuecomment-1962947756, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAFHKNRDSSIG6GTS7ABXEXTYVM6XJAVCNFSM6AAAAABDXV7RUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRSHE2DONZVGY.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Unfortunately, it's still happening. Please see the error logs from the console below. There are 3 separate errors logs. I am running Windows 11. Thanks for looking into it.
Error 1
The above error occurred in the  component:
at input
at InputDrag (plugin:make-md:72585:10)
at div
at StepSetter (plugin:make-md:72711:24)
at ContentSubmenu (plugin:make-md:72776:55)
at div
at FrameNodeEditor (plugin:make-md:73700:11)
at div
at FrameNodeEditorContainer (plugin:make-md:74625:45)
at FrameEditorNodeView (plugin:make-md:77245:38)
at FrameEditorInner2 (plugin:make-md:77190:23)
at div
at FrameEditorNodeView (plugin:make-md:77245:38)
at FrameEditorInner2 (plugin:make-md:77190:23)
at div
at FrameEditorNodeView (plugin:make-md:77245:38)
at FrameEditorInner2 (plugin:make-md:77190:23)
at div
at FrameEditorNodeView (plugin:make-md:77245:38)
at div
at FrameEditorInstance (plugin:make-md:77646:56)
at FrameInstanceProvider (plugin:make-md:71940:65)
at div
at eval (plugin:make-md:74137:73)
at div
at SpaceInner (plugin:make-md:86361:43)
at FrameEditorProvider (plugin:make-md:71503:55)
at SpaceRoot (plugin:make-md:74023:55)
at FrameSelectionProvider (plugin:make-md:72082:37)
at FramesMDBProvider (plugin:make-md:61484:61)
at SpaceProvider (plugin:make-md:61121:55)
at PathProvider (plugin:make-md:60710:18)
at SpaceView (plugin:make-md:74005:23)
at div
at WindowProvider (plugin:make-md:69249:58)
at DndContext2 (plugin:make-md:43724:9)
at WindowManager (plugin:make-md:97474:5)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.
logCapturedError @ plugin:make-md:15462
Error 2
plugin:make-md:4444 Uncaught Error: input is a void element tag and must neither have children nor use dangerouslySetInnerHTML.
at assertValidProps (plugin:make-md:4444:21)
at setInitialProperties (plugin:make-md:9094:11)
at finalizeInitialChildren (plugin:make-md:9842:11)
at completeWork (plugin:make-md:17667:23)
at completeUnitOfWork (plugin:make-md:20561:24)
at performUnitOfWork (plugin:make-md:20546:13)
at workLoopSync (plugin:make-md:20477:13)
at renderRootSync (plugin:make-md:20456:15)
at recoverFromConcurrentError (plugin:make-md:20078:28)
at performSyncWorkOnRoot (plugin:make-md:20220:28)
at flushSyncCallbacks (plugin:make-md:10621:30)
at eval (plugin:make-md:19969:21)
at node:internal/process/task_queues:140:7
at AsyncResource.runInAsyncScope (node:async_hooks:204:9)
at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)
** Error 3**
5 plugin:make-md:77426 Uncaught TypeError: Cannot read properties of null (reading 'getBoundingClientRect')
at ResizeObserver.eval (plugin:make-md:77426:24)

It also happens if I try to change the style of any item in a space (e.g. a label)

The fix will be in today's patch, thanks for the help tracking it down

It's still happening but when adding a new linked note


Added attribute for expire-callback function

Added an attribute for assigning the expire-callback function.

Thanks @ryanblanks! Please check comment.

Yes, good point.  I'll get that fixed and update.

Undefined check has been added.  Thanks.


feat: Colombia Universidad added

Universidad Nacional Abierta y a Distancia

@CristianRiosP I am sorry, the domain unadvirtual.edu.co is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


SPDM 1.2 need handle data_transfer_size and max_spdm_msg_size capability

Missing 1.2 feature, after https://github.com/DMTF/libspdm/pull/477
For chunk, ref https://github.com/DMTF/libspdm/issues/504

1/10/2022 - not sure how to use two fields without chunking. Maybe add them together with chunking.

I will check this

This issue can only handle data_transfer_size.
max_spdm_msg_size  can be done in #504


Adds readinessProbe and livenessProbe to prometheus-adapter jsonnet

Description
Problem: Currently the prometheus-adapter pods are restarted at the same
time even though the deployment is configured with strategy RollingUpdate.
This happens because the kubelet does not know when the prometheus-adapter
pods are ready to start receiving requests.
Solution: Add both readinessProbe and livenessProbe to the
prometheus-adapter, this way the kubelet will know when either the pod
stoped working and should be restarted or simply when it ready to start
receiving requests.
Issue: https://bugzilla.redhat.com/show_bug.cgi?id=2048333
Type of change
What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

[ ] CHANGE (fix or feature that would cause existing functionality to not work as expected)
[ ] FEATURE (non-breaking change which adds functionality)
[ ] BUGFIX (non-breaking change which fixes an issue)
[x] ENHANCEMENT (non-breaking change which improves existing functionality)
[ ] NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry
Please put a one-line changelog entry below. Later this will be copied to the changelog file.

Adds readinessProbe and livenessProbe to prometheus-adapter

@dosmanak thank you! https://github.com/prometheus-operator/kube-prometheus/pull/1701


Truncated symbols

I have truncated symbols.
https://www.dropbox.com/s/xx3dp4tiza6h7tu/Screenshot 2017-02-02 14.41.25.png?dl=0&raw=1
Do you know what might be causing this?

I'm not sure, I thought it was caused by your terminal

I'm using macvim. I guess it might cause the issue.


Error in DGIdb Conversion

Traceback (most recent call last):
  File "/home/ubuntu/kg2-code/dgidb_tsv_to_kg_jsonl.py", line 167, in <module>
    make_kg2_graph(input_file_name, nodes_output, edges_output, test_mode)
  File "/home/ubuntu/kg2-code/dgidb_tsv_to_kg_jsonl.py", line 83, in make_kg2_graph
    PMIDs] = fields
ValueError: too many values to unpack (expected 11)

The old fields in our conversion dgidb_tsv_to_kg_jsonl.py are
[gene_name,
             gene_claim_name,
             entrez_id,
             interaction_claim_source,
             interaction_types,
             drug_claim_name,
             drug_claim_primary_name,
             drug_name,
             drug_concept_id,
             _, #12.5.2020 new field in tsv: interaction group score
             PMIDs] = fields

but it looks like DGIdb changed their structure recently and now the available fields in interactions.tsv are:
gene_claim_name
gene_concept_id
gene_name
interaction_source_db_name
interaction_source_db_version
interaction_type
interaction_score
drug_claim_name
drug_concept_id
drug_name
approved
immunotherapy
anti_neoplastic

Per Slack DM thread, the current plan is to use the May 2021 release of DGIdb for the purpose of the KG2.9.0pre build.
Then we'll update the DGIdb ETL script for RTX-KG2, so going forward in the subsequent builds, we can use the latest DGIdb release.


Table sidebar menu for creating data bar formatting from the UI.

https://github.com/deephaven/web-client-ui/issues/1152


Reuse folding component from NFT item detail to collection description

I guess let's show only the first row from the description and replace the old one
Make default folded
@roiLeo was right on this one 😇

how it looks like at item detail

random comment to trigger bot delete me later

@yangwao I'll do this


(RE-13304) add apt-transport-https to debian

the puppet-release package is now setting the url for apt puppet-agent repo to https transport. On the default Debian installation < 10 apt-transport-https is not provided causing the installation of puppet-agent to fail.
This PR adds apt-transport-https to the provisioning phase of beaker.

beaker provision on debian-8:
[redacted] (debian8-64-1) 11:28:20$ dpkg -s apt-transport-https
  Package: apt-transport-https
  Status: install ok installed
  Priority: optional
  Section: admin
  Installed-Size: 190

Debian 9:
[redacted](debian9-64-1) 11:36:31$ apt-get install --force-yes  -y apt-transport-https
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following NEW packages will be installed:
    apt-transport-https
  0 upgraded, 1 newly installed, 0 to remove and 176 not upgraded.
  Need to get 171 kB of archives.

Debian 10:
[redacted] (debian10-64-1) 11:42:08$ apt-get install --force-yes  -y apt-transport-https
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following NEW packages will be installed:
    apt-transport-https
  0 upgraded, 1 newly installed, 0 to remove and 84 not upgraded.

Ubuntu 14.04 - already installed
root@[redacted]:~# apt list --installed | grep apt-transport-https

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

apt-transport-https/now 1.0.1ubuntu2.6 amd64 [installed,upgradable to: 1.0.1ubuntu2.18]

Ubuntu 16.04 - already installed
root@willing-culprit:~# apt list --installed | grep apt-transport-https

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

apt-transport-https/xenial-updates,now 1.2.27 amd64 [installed]

Ubuntu 18.04 - not installed and not needed, since it knows how to handle https repos.

This is blocking puppetserver's pipelines too, when installing PuppetDB, from this function https://github.com/puppetlabs/beaker-puppet/blob/master/lib/beaker-puppet/install_utils/foss_utils.rb#L1062-L1064. However, I wasn't seeing the problem go away there when I added the contents to my local beaker.

@Magisus that's correct, the packages will be installed by using beaker provision command.

Thanks, I'll look into adding that for our jobs!


Support passing pg-promise initialization options during the library's initialization

It would be nice to be able to pass initialization options or a configuration object directly to pg-promise.
This could be fairly easily be possible if you

Allow either a PgPromise.IDatabase or a string directly to be passed to the PostgresDatabase constructor.
Export PostgresDatabase from index (should also maybe export MysqlDatabase too)

In general, it might be worth double checking to see if there are other useful classes/functions that should be exported too.

I think allowing the constructor to be extended with options is a good choice. Please make a pull request and let's look at it together. Also could you elaborate on what you want to build on top of schemats, I'm very curious?

Also could you elaborate on what you want to build on top of schemats, I'm very curious.

My sentiment exactly, what options of pg-promise is he planning to use that would be beneficial here?

@xiamx I actually have (at least for now) decided that this is a bit heavy for me to implement/use (for now, at least), and I can't really devote time to make a pull request currently, sorry.
I was planning to use this to generate types during build/development. The project I work on has some special logic for getting the database configuration, and use that as a configuration object for pg-promise in the main source.
I didn't have a specific idea for initialization options though.
As I said, I won't be using this right now, so feel free to close this issue if you don't think it's needed.

Cool so I changed the title to a more descriptive one. We will keep this one open for some visibility.

@xiamx It's nice, but I don't see it being of any use, because this library is only used for generating code, and all the options in pg-promise relate to the run-time only, nothing to do with the code generation.


MsalAuthenticationTemplate is rendering children despite having logged out in other tab

Core Library
MSAL.js v2 (@azure/msal-browser)
Core Library Version
2.16.1
Wrapper Library
MSAL React (@azure/msal-react)
Wrapper Library Version
1.0.1
Description
MsalAuthenticationTemplate does not get reevaluated upon reoping the browser tab containing that component.
This is a problem for NextJS applications using the SWR-Library with an MSAL-Access-Token to fetch data, as data is refetched upon focus.
Error Message
No response
Msal Logs
No response
MSAL Configuration
{
  auth: {
    clientId: `${process.env.NEXT_PUBLIC_AUTH_CLIENT_ID}`,
    authority: MSAL_AUTHORITY_SIGNIN_SIGNUP,
    knownAuthorities: [`${process.env.NEXT_PUBLIC_AUTH_TENANT_URL}`],
    redirectUri: process.env.NEXT_PUBLIC_AUTH_REDIRECT_URL,
    navigateToLoginRequestUrl: true,
  },
  cache: {
    cacheLocation: 'localStorage',
  },
};

Relevant Code Snippets
<MsalAuthenticationTemplate
    interactionType={InteractionType.Redirect}
    authenticationRequest={{
        scopes: SCOPES,
        redirectUri: MSAL_CONFIG.auth.redirectUri,
        extraQueryParameters: { ui_locales: locale },
        prompt: 'select_account',
    }}
    errorComponent={x}
    loadingComponent={y}
>
    {children}
</MsalAuthenticationTemplate>

Reproduction Steps
Given a React or Next.JS Application similar to the sample https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-react-samples/nextjs-sample
1.) Open the browser
2.) Open a page / route containing MsalAuthenticationTemplate using InteractionType.Redirect
3.) Login & await Login to be successful
4.) Open a new tab and open the same page / route as in the first tab
=> You are immediately logged in in the second tab due to cacheLocation: 'localStorage'
5.) Logout in tab 2 & await Logout to be completed
6.) Switch to tab 1
=> MsalAuthenticationTemplate is still rendering the child
=> useIsAuthenticated() hook is still returning true
Expected Behavior
=> The children of MsalAuthenticationTemplate are not rendered as user logged out in tab 2 and access token is shared through local storage.
=> useIsAuthenticated() hook returns false
Identity Provider
Azure B2C Custom Policy
Browsers Affected (Select all that apply)
Chrome
Regression
No response
Source
External (Customer)

In step 6, are you refreshing the page?

@jasonnutter: No, I just open the browser tab without conditional or explicit page reload / refresh.
Due to the nature of how SWR works (in its default configuration), it will revalidate all data requested by child components upon focus (eg. when opening a browser tab with a page where those child components are rendered in). This then fails when it wants to try to get an access token, as there is obviously none because the user has logged out in the other tab before.
I would like to try to avoid to create my own wrapper component where I listen on the visiblitychange event of the window and read out the msalInstance.getActiveAccount() to identify if the children may still be rendered or not.

@mleimer The components we provide are meant to cover the most common use cases and may not meet all your requirements. The logic you describe is something you will likely need to implement yourself. What is the desired behavior when tab 1 is refocused? If MsalAuthenticationTemplate thinks no user is signed in it will auto redirect back to the login screen to attempt to sign a user in. That sounds undesirable after just logging out, no?

@tnorling May I ask how I can implement said logic myself. Is it sufficient just to check whether there is at least 1 account or an active account and/or should I also try to fetch an access token to identify if a user is still authorized or not?
Actually, the redirect to the login screen upon opening tab 1 again is desired in our use case. I understand that other teams might want to have special behaviors like forwarding the user to a special logout screen or alike. However, I disbelief that the common scenario should be to pretend that the user is logged in when he has logged out from another tab.
Kindly note that the issue also exists the other way round. E.g. if I am logged out in tab 1 and 2; When I log in in tab 2; the useIsAuthenticated-Hook in tab 1 still returns "false" because it does not get refreshed either upon opening tab 1.
Maybe this could be considered for a future improvement to fully support multiple tabs?

@mleimer

May I ask how I can implement said logic myself. Is it sufficient just to check whether there is at least 1 account or an active account and/or should I also try to fetch an access token to identify if a user is still authorized or not?

Checking if there is 1 account or an active account should be sufficient to tell you whether or not you need to "login". When you need a token the pattern should always be to call acquireTokenSilent and if that fails call acquireTokenRedirect or acquireTokenPopup.

Kindly note that the issue also exists the other way round. E.g. if I am logged out in tab 1 and 2; When I log in in tab 2; the useIsAuthenticated-Hook in tab 1 still returns "false" because it does not get refreshed either upon opening tab 1.
Maybe this could be considered for a future improvement to fully support multiple tabs?

I agree this does sound like a reasonable request. I'll mark this as an enhancement and see what can be done on our end to better support these scenarios.


bug(material/menu): EventListeners are not working when using getter for obtaining iterable

Reproduction
https://stackblitz.com/edit/angular-u6zmcr?file=src%2Fapp%2Fapp.component.ts
Steps to reproduce:

Just click on button
Click on an menu item
nothing will be logged to console

Expected Behavior
Menu Items should be clickable. (click listener should receive events)
Actual Behavior
Menu Items are not clickable.
Environment

Angular:
CDK/Material: 9.2.1
Browser(s): Chrome 81
Operating System (e.g. Windows, macOS, Ubuntu):  Windows

That's because you're returning a new array on every change detection. This means that as soon as you put your pointer down, you actually get a completely new button element which will interrupt the click event. In general this is a bad practice, because it leads to excessive change detection and memory leaks.

Thank you for your explanation


Remove unused ThirdParty/es5-shim

Not used since 339be2c

Thanks.

@mramato can you update CHANGES.md in master since some of our users track our third-party libraries?

Will do, but we should probably think about tweaking license.md to better differentiate between "end-user dependencies" and "development dependencies"   The es5-shim was only used for tests.


How can I set the indent line thinner?

My tab is 2 and the indent line will look very crowded and I want to set it thinner, my size set now is 1

let g:indent_guides_guide_size = 1 is the thinnest that this plugin can go. If you want thinner and you're using NeoVim, I would suggest https://github.com/lukas-reineke/indent-blankline.nvim, which can use  a character as the indent guide, e.g. |.


[app-state] Feature request: graceful MigrationManager error behavior

It seems like a common case to want MigrationManager to fall back to the default state if it runs into any issues. Is there a nice way that could be supported without having to make a custom subclass?
Maybe any real use case will want a custom subclass anyway - not sure if it's really worth it. But while prototyping and slowly increasing the stability of an app it seems useful to slap in a default to a [PersistentStore](https://github.com/simontonsoftware/s-libs/issues/67) that silently starts fresh when I change the schema. Almost like a NonMigrationManager 🙂.
Maybe this could be a feature specifically of PersistedStore. The migration manager could be optional, and if there isn't one we use this behavior.

This will be in the next release


Add schemas/com.snowplowanalytics.kinesistee.config/Configuration/avro/1-1-0

This schema is needed for https://github.com/snowplow/kinesis-tee/pull/32, which solves https://github.com/snowplow/kinesis-tee/issues/31.

@kazjote has signed the Software Grant and Corporate Contributor License Agreement. Thanks so much


The integration does not load (TAPO C420).

Description
When Home Assistant starts, the integration struggles to load, showing "initializing" for a certain period of time (indefinitely long).
Also, if the startup is successful, you can see that many camera and hub entities are no longer available.

Reproduction Steps
=/=
Expected behavior
=/=
If applicable, add error logs.
home-assistant_tapo_control_2024-07-07T15-09-15.196Z.log
Device Firmware
1.2.17 Build 20240305 rel.75572 (cameras) - 1.3.3 Build 20240604 rel.61598 (hub)
Integration Version
5.4.26
Using stream component
No
Does camera work via official integrations?
N/A
Camera has all attributes filled out in developer tools
No
HASS Environment
Hassio on Raspberry Pi4
Search for similar issues
Yes
Additional information
No response

Did this start happening after an update? If so, which one? I do not have these hub cameras so I cannot verify them myself.

Did this start happening after an update? If so, which one? I do not have these hub cameras so I cannot verify them myself.

Yes, it most likely happened after the latest core and supervisor updates.

Did it happen after integration version update? Could you rollback and note down the versions where it worked?

Podemos volver a la versión anterior 5.4.25?
Gracias

Could you please manually remove following parts from your code on the latest version one by one and after each time see if it helps:
https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/compare/5.4.25...5.4.26
First remove this green part in switch.py

Then remove these:

Finally if it still does not work, replace these greens with red:

Fixed in https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/releases/tag/5.4.27


Add multisig_control to the bridge instead of calling out to get it

Per our slack chat we are going to keep this the way it is so that there can never be a security mismatch.


Missing Files - Humble

There are some moveit2 files missing in the GitHub which is needed to run the moveit2 command with ROS2
The screenshot below is the proof where moveit2 is not working but moveit is working.

@Koushikraj-2005
Thank you for your patience. We've newly updated moveit2 feature in ros2 humble.
Please check new version to doosan moveit2 .

The servo is turned on and off for the first time. Further continuous connection doesn't apply any action. There are no action.
Also there is an error noticed where the controller is failed to load.
Model: A0912

The MoveJ service is getting enabled. Need a method to solve this issue. @song-ms


"Service host failed to activate" When running Windows containers on local cluster

On a local one-node cluster I am trying to run a Service Fabric application with four stateless services, all of them running containers whose images are using servercore:ltsc2019 as the parent image. When running the application, the containers do get created but they never start. After a few minutes the containers are removed and re-created, and this process keeps repeating without the containers ever starting. This is the error I'm observing in the explorer:

Resetting Docker to factory defaults fixes the issue, but if I create a new cluster, the problem returns. In either situation, I am able to run containers for these images directly using Docker or Docker Compose.
Here is a link to the Service Fabric logs demonstrating this issue.
From the event logs: Failed to start Container. ContainerName=sf-0-308f1943-2246-4c35-af1c-94c162a1de77_724ed3aa-9540-4e81-874e-8079e6c9dc70, ApplicationId=SearchType_App0, ApplicationName=fabric:/Search.System.Fabric.FabricException: Docker operation timed out. RequestUri=http://docker_engine/containers/sf-0-308f1943-2246-4c35-af1c-94c162a1de77_724ed3aa-9540-4e81-874e-8079e6c9dc70/start    at Microsoft.ServiceFabric.ContainerServiceClient.ContainerServiceClient.<MakeRequestPrivateAsync>d__42.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at Microsoft.ServiceFabric.ContainerServiceClient.ContainerServiceClient.<MakeRequestAsync>d__39.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at Microsoft.ServiceFabric.ContainerServiceClient.ContainerOperation.<StartContainerAsync>d__5.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at Hosting.ContainerActivatorService.Utility.<>c__DisplayClass14_0.<<ExecuteWithRetryOnTimeoutAsync>b__0>d.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()    at Hosting.ContainerActivatorService.Utility.<ExecuteWithRetryOnTimeoutAsync>d__15 1.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at Hosting.ContainerActivatorService.ActivateContainerOperation.<StartContainerAsync>d__20.MoveNext()
Additionally, looking at the Windows application logs for Docker events, this sequence of events is happening several times per minute:
debug: Calling GET /v1.40/volumes/C
debug: Probing all drivers for volume with name: c
Post http://<IP_ADDRESS>:48081/Plugin.Activate: dial tcp <IP_ADDRESS>:48081: connectex: No connection could be made because the target machine actively refused it.
Unable to connect to plugin: <IP_ADDRESS>:48081/Plugin.Activate: Post http://<IP_ADDRESS>:48081/Plugin.Activate: dial tcp <IP_ADDRESS>:48081: connectex: No connection could be made because the target ma...

@JRRJ how do you get to those logs/event saying "Failed to start container"? Scanning SF Logs to find it, unsuccessfully. I have the same problem, wondering which diagnostic sources to look at.


💄(homepage) enable PersonPlugin on homepage sections

Purpose
Homepage misses a "Persons" section like for Organizations, Courses,
etc..
Proposal
This add some new styles on highlight section to correctly include
PersonPlugin and "create_demo_site" has been changed to include some
PersonPlugin in a section on homepage.
Also include a little fix on "create_demo_site" that did not published again
homepage after adding section and plugins.


Some letters are being cutoff in headers with overflow: hidden

https://jsfiddle.net/t3n7x8fh/

see also: http://stackoverflow.com/questions/10182336/text-cropping-when-using-overflow-hidden
try:
h1, h2, h3, h4, h5, h6 {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  line-height: normal;
}

:dancer: :+1:

Alternatively try specifying overflow-x: hidden and that might help.

@mdo overflow-x: hidden is not working https://jsfiddle.net/gr81L1gx/
@cvrebert I think it's more of an issue for an existing mixin.. https://github.com/twbs/bootstrap/blob/master/less/mixins/text-overflow.less and maybe the line height should be fixed in general as it looks like it's smaller and maybe the problem is not visible without the overflow..

@mdo overflow-x: hidden is not working https://jsfiddle.net/gr81L1gx/
@cvrebert I think it's more of an issue for an existing mixin.. https://github.com/twbs/bootstrap/blob/master/less/mixins/text-overflow.less and maybe the line height should be fixed in general as it looks like it's smaller and maybe the problem is not visible without the overflow..

however, it's generally considered good practice for headings to reduce line height, as it's otherwise too excessive by default...

however, it's generally considered good practice for headings to reduce line height, as it's otherwise too excessive by default...


Change the color of :class:~.NumberLine to WHITE from LIGHT_GREY.

Overview: What does this pull request change?

Removes explictly set colour in NumberLine to force it to use the default.

Motivation and Explanation: Why and how do your changes improve the library?

Switching the colour to the default (WHITE) from LIGHT_GREY makes the Axes look more visually appealing, supported by a brief informal vote in discord. Also, allows VMobject.set_default(color=BLACK) to work for coordsys mobs.
Before:

After

Before:

After:

Before:

After:

Links to added or changed documentation pages

https://manimce--2139.org.readthedocs.build/en/2139/reference/manim.mobject.coordinate_systems.CoordinateSystem.html#manim.mobject.coordinate_systems.CoordinateSystem
Further Information and Comments

More tests than necessary were changed since I rewrote all the tests in the problem files out of convience. Shouldn't cause any probelms (I hope 😅)

Reviewer Checklist

[ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
[ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
[ ] If applicable: newly added functions and classes are tested

If I recall correctly there was some agreement on Discord to do this, but to make sure that this is preferred can you start a poll in #polls?


feat(sdk/go): Implement spin-http for TinyGo

TinyGo bindings of the spin-http wit.
https://github.com/fermyon/spin/blob/14603bb71f9592fbfe3d10f5deb961fddb89f58c/wit/ephemeral/spin-http.wit

Do you want to update the docs with this PR as well, or with a follow-up PR?
This looks great, thanks!


[Panpress] global roadmap for a first stable version

At first, Panpress was only created for the fullweb.dev website. There still is a lot to do to offer a ready to use and satisfying static website generator for everyone.
For the list of what features I think would be required for a first stable release, see:  https://github.com/fullwebdev/fullwebdev/projects/1

Deprecated in favor of Daucus (soon to be released)

Deprecated in favor of Daucus (soon to be released)


Downloadable docs

I'd like to integrate docs.rs inside Dash.
To achieve this, I need a way to download the docs for a package as HTML files. Please consider supporting this.
edit(@jyn514): see https://github.com/rust-lang/docs.rs/issues/174#issuecomment-926885213 for mentoring instructions.

How about just sharing the database dump, like a backup.torrent or whatever. Crates.io for sure have a backup, this way some users will co-host it for free.

That's not an acceptable solution - note that @Kapeli isn't just asking for tossing the database over the wall, they specific want to integrate docs.rs into a offline documentation viewer so that users can download the documentation for specific crates as needed. The docset format isn't exclusive to Dash, either - other projects such as Zeal also make use of it.

One note: I'm not asking for docs.rs to generate docsets. I'm asking for it to provide downloadable docs.

I am really looking forward this integration.

Can't wait for both integration and Rust syntax coloring support for Dash snippets :)

is there any progress or any new plan?

It'd also be nice to get the nightly rustc docs without having to build the rustc.

https://github.com/Robzz/cargo-docset was recently released, maybe that's enough for some people here or maybe the some of the code can be reused and integrated into docs.rs somehow

Any update on this?

It's not too practical to generate a downloadable archive of a crate's documentation, as each file is stored individually on S3.
We'd need to fetch all the files individually and generate an archive of that on the fly, which is not practical for large crates. Preparing an archive at build time and storing it separately would increase our storage costs, and due to the unbounded nature of docs.rs we should try avoiding that.
If y'all have better implementation ideas I'd love to read them.

Could we prepare an archive at build time but only for crates that are opted in to this using some notion of "important to the community"? For example I'd love to see docs.rs provide a docset for tokei that Dash can keep automatically up-to-date. I don't know who'd provide that curation though. There could be some way to nominate crates and leave it up to the docs.rs maintainers to approve it, or maybe it could be based on traffic to a particular crate's documentation.

Could the archive be generated only when requested and have a fixed-size cache where older archives get removed?
Would the archives really be that big though? Docs are generally just text, which compresses very well. You could have a separate archive for the common resources (CSS, images, fonts and so on) and then the docs archives would just be compressed HTML files.

Could the archive be generated only when requested and have a fixed-size cache where older archives get removed?

That's not really feasible, as some crates (like stm32f0) have ~200k HTML files in them. They're all stored on S3, and just listing them took awscli 2 minutes and 43 seconds from the docs.rs server.

Would the archives really be that big though? Docs are generally just text, which compresses very well. You could have a separate archive for the common resources (CSS, images, fonts and so on) and then the docs archives would just be compressed HTML files.

Resources are already deduplicated on S3, and all files will be compressed soontm. Once we do that storing the prebuilt archives will double our storage requirements. Today we can afford that, but thinking long term we'll want to avoid using too much storage.

just listing them took awscli 2 minutes and 43 seconds from the docs.rs server

Taking a long time is fine. For API access you can return a message saying the docs archive isn't ready yet and to try again later, for users trying to download the docs from their browser, show a page saying the same thing, maybe a bit nicer with automatic refresh and so on. With a big enough cache size, you could optimise both CPU and disk space needs.

Dash support for docs.rs would be extremely useful. What's the status on this? Is there anything I can do to help get this to happen?
In the meantime I'm going to look into using that wget trick to download docs for individual Rust packages, if I can find it again (the one with like 10 lines worth of flags).

It'd also be nice to get the nightly rustc docs without having to build the rustc

@nhynes this is out of scope for docs.rs, we only build user documentation. I'm not sure the right place to open a new issue, maybe https://github.com/rust-lang/www.rust-lang.org/issues ?

We discussed this internally and this probably won't see action at least until Rust All Hands in March.
Personally, I would like to see #379 implemented and #532 merged before we make any decisions, which would let us see how much storage we'll be using the future.

Not directly related, but it'd be great to turn docs.rs into an offline-first PWA (Progressive Web App). So the user would still be able to browse the docs they have already visited before even when offline, without having to use a separate website or app.

That can be achieved with cargo doc to build local crates and rustup doc for the book, std, and everything else on doc.rustlang.org

Unfortunately, that's not the best UX. As a user, I want to be able to keep using the familiar links I've already visited before from my browser history, and have them work while offline.

I opened https://github.com/rust-lang/docs.rs/issues/845 since this is not related to downloadable docs.

As a long-time Dash user, I would like to reawaken this thread. I've recently come to working in Rust after three years of working in Elixir. The Elixir community managed to solve exactly this problem. The integration with Dash and third-party libraries is IMHO part of the delight of working in that language environment.
I recently completed the Rust 2021 survey and this was my #1 complaint about transitioning into Rust work. I hope the Rust community will take this more seriously.

Don't worry, we haven't forgotten about it. This is currently blocked on https://github.com/rust-lang/docs.rs/issues/1004; if you're interested in helping out, that would be a good place to start.

Random thought: I know the compression stuff is in the works... What about generating a single-file-per-crate compressed archive anyway/separately and storing that for everything going forward? That would be a relatively simple change to the doc build process, would it not? (e.g. last build step: tar+zstd all of the built files; save archive somewhere, s3?)
Even if the needs of the compression project change and/or evolve, the data would still be there and could be easily converted to whatever format is required - most probably much more easily converted than retrieving millions of individual files from s3.
Doing this would:

Provide an option right now to allow easy access to documentation (e.g. offline/airplane use)
Make access/conversion much easier in the future by having several thousand files to download (and extract locally) instead of millions.
Be easy to delete - if there is an alternate process developed, the compressed archives could easily be deleted.
Possibly make diagnosing problems w/build output easier (like how CI tools archive build artifacts/logs)

Side note:
From experience, even using random access capable compressed tar archives, the size is usually much larger (i.e. worse compression ratios). https://github.com/martinellimarco/t2sz does indeed work well but since it has to make each file a ZSTD block in order to make the archive random seekable, the compression is (essentially) the same as using zstd on each individual file and then making a tar of the individual compressed files.
(One anecdotal example: 48 JSON files each ~4-6MB - total uncompressed size ~260MB. Compressed with zstd -19 --long=31 the tar.zst is ~1.9MB. Compressed with t2sz (indexed tar) it's ~16MB. That's a pretty big difference.)

Given that https://github.com/rust-lang/docs.rs/pull/1342 is almost done and would help with things besides downloadable docs, I don't think it makes sense to store both archived and unarchived files for the same crates.

Since #1342 is progressing slowly, but continuously, I started thinking about downloadable docs again.
From what I see and understand from the code (please correct me if I'm wrong):

The archives we will create with #1342 will only contain the exact same files as would be in the S3 storage right now.
because we build the docs with --static-root-path=/, the references to CSS/JS files would be absolute paths starting with /, not relative paths, the default.
since we serve toolchain-shared or unversioned-shared files separately, we exclude them from the doc-output, so they will be missing in the current archive.
Are changes needed related to intra-doc-links?

So, the current archives probably won't be usable for downloadable/offline docs, without

merging the nightly-specific CSS/JS files into them (which probably wouldn't be too hard), or still include the toolchain files into our archives though we're not using them.
rewriting all the CSS/JS href in the HTML files from absolute URL paths to relative local paths (which is not possible synchronously).
fix more things?

So to have actually useable downloadable docs, wouldn't we have to run a second, clean, doc-build we would put into another archive for download? To me that does seem to be less effort and more clean than rewriting HTML and re-compressing/merging archives, does it?

So to have actually useable downloadable docs, wouldn't we have to run a second, clean, doc-build we would put into another archive for download? To me that does seem to be less effort and more clean than rewriting HTML and re-compressing/merging archives, does it?

The problem is that it uses the twice the CPU and storage, which doesn't seem like a great use of resources when all we want to do is change some of the links to point elsewhere.

Are changes needed related to intra-doc-links?

Hmm, most likely yes. @Kapeli how would you expect relative links to other crate to work? Currently they'd point to https://docs.rs, which seems to defeat the point of downloadable docs.
I think it might also be fine to make this the responsibility of whatever tool is packaging the docs into docsets; it's not that hard to parse HTML, there are lots of libraries for it.

since we serve toolchain-shared or unversioned-shared files separately, we exclude them from the doc-output, so they will be missing in the current archive.

It doesn't seem too hard to add them into the archive - there are many fewer shared files than per-crate files, it seems ok to do a bit of preprocessing for them on the docs.rs server. Alternatively, we could expose an API for "all shared files" and make it the responsibility of the client to combine them properly.

rewriting all the CSS/JS href in the HTML files from absolute URL paths to relative local paths (which is not possible synchronously).

What do you mean by synchronously? I don't think it would be unreasonable to do this at the time we download the archive.

So to have actually useable downloadable docs, wouldn't we have to run a second, clean, doc-build we would put into another archive for download? To me that does seem to be less effort and more clean than rewriting HTML and re-compressing/merging archives, does it?

The problem is that it uses the twice the CPU and storage, which doesn't seem like a great use of resources when all we want to do is change some of the links to point elsewhere.

It that's the only thing, probably true. But for all the logic specific to docs.rs someone would have to maintain the reverse-logic, right? ( for example changing the links to be relative, re-adding the shared files)

Are changes needed related to intra-doc-links?

Hmm, most likely yes. @Kapeli how would you expect relative links to other crates to work? Currently they'd point to https://docs.rs, which seems to defeat the point of downloadable docs.
I think it might also be fine to make this the responsibility of whatever tool is packaging the docs into docsets; it's not that hard to parse HTML, there are lots of libraries for it.

If the only use-case are offline docs, perhaps that could work, of course when we make more changes in how docs are generated for docs.rs, this additional revert-logic has to be adapted too, right?
If the use-case is also downloadable docs for everyone, that would be a high burden for everyone.

since we serve toolchain-shared or unversioned-shared files separately, we exclude them from the doc-output, so they will be missing in the current archive.

It doesn't seem too hard to add them into the archive - there are many fewer shared files than per-crate files, it seems ok to do a bit of preprocessing for them on the docs.rs server. Alternatively, we could expose an API for "all shared files" and make it the responsibility of the client to combine them properly.

👍

rewriting all the CSS/JS href in the HTML files from absolute URL paths to relative local paths (which is not possible synchronously).

What do you mean by synchronously? I don't think it would be unreasonable to do this at the time we download the archive.

Exactly :) Thinking about merging the archive I was initially thinking about a synchronous approach.

If the use-case is also downloadable docs for everyone, that would be a high burden for everyone.

Hmm, I don't understand the distinction you're drawing between "offline docs" and "downloadable docs for everyone". Are you expecting people to run curl docs.rs/some/api and use the archive without further changes? I don't really know why you would do that - for me personally, running cargo doc --no-deps would be easier than messing with curl.

It that's the only thing, probably true. But for all the logic specific to docs.rs someone would have to maintain the reverse-logic, right? ( for example changing the links to be relative, re-adding the shared files)

Another alternative I suppose is to still only upload one archive when the crate is first built, but when rewriting/adding shared files the first time it's downloaded, also reupload that cached archive so it's faster next time. That saves space for crates whose docs never get downloaded, without making it too slow to rewrite things, and also lets us delete the cache after a while if we don't need it. On the other hand, it seems complicated (since we'd have to deal with multiple requests at a time trying to download the same archive).

It that's the only thing, probably true. But for all the logic specific to docs.rs someone would have to maintain the reverse-logic, right? ( for example changing the links to be relative, re-adding the shared files)

Another alternative I suppose is to still only upload one archive when the crate is first built, but when rewriting/adding shared files the first time it's downloaded, also reupload that cached archive so it's faster next time. That saves space for crates whose docs never get downloaded, without making it too slow to rewrite things, and also lets us delete the cache after a while if we don't need it. On the other hand, it seems complicated (since we'd have to deal with multiple requests at a time trying to download the same archive).

I'll probably give the general rewrite-approach a try and then we can decide on when we do it. Right now rewriting and re-compressing feels like too much load to do in a request, especially for bigger crates, on top of handling parallel requests to the same release. On the other side we don't know how many of the crates are actually requested, so how much CPU would be wasted when we rewrite every release.

If the use-case is also downloadable docs for everyone, that would be a high burden for everyone.

Hmm, I don't understand the distinction you're drawing between "offline docs" and "downloadable docs for everyone". Are you expecting people to run curl docs.rs/some/api and use the archive without further changes? I don't really know why you would do that - for me personally, running cargo doc --no-deps would be easier than messing with curl.

I see your point, ok

Hmm, most likely yes. @Kapeli how would you expect relative links to other crates to work? Currently they'd point to https://docs.rs, which seems to defeat the point of downloadable docs.
I think it might also be fine to make this the responsibility of whatever tool is packaging the docs into docsets; it's not that hard to parse HTML, there are lots of libraries for it.

Coming back to this, I'm not sure how the other official integrations look like with @Kapeli .
Since there is a custom search-index and table of contents in the docsets, there probably will be an additional processing step in any case. If that includes HTML rewrites, the JS/CSS paths could be fixed there, though that doesn't feel like a thing that I would officially serve from the pages as "downloadable docs" since it's broken on its own :)

for me personally, running cargo doc --no-deps would be easier than messing with curl.

And that works great if you're on a computer with a GUI (as opposed to SSHed into a terminal w/o X-forwarding) and have a reasonably powerful computer (and the space to build the docs)
One issue I have personally with the entire Rust language documentation ecosystem is that it's entirely based on the premise that you're doing development on a system with a GUI and a web browser. The output is HTML, graphical, and there isn't (AFAIK) even an option to output to something that is text-mode friendly. (Using a text mode web browser is a hack-y solution.) This is in stark contrast to documentation systems for other languages like Sphinx for Python which will happily generate -using built-in builders- HTML (both single page and individual files), Plain Text, LaTeX, EPUB, PDF (through LaTeX), Texinfo (for GNU info), etc... This is also very different in the Python world because you often don't even need the generated documentation (which is usually made from the docstrings in the source) ... If you're in a Python REPL (regular python, ipython, jupyter, etc.), you can access the documentation quite easily with a simple call to help(numpy.array) or from the command line: pydoc numpy.array
I recognize that Rust's overall documentation system design is well beyond the scope here... But I do raise it to highlight what appears to be an assumption made in the design of the Rust ecosystem: That developers using Rust are working on (1) powerful systems (2) with GUIs and [without downloadable documentation] (3) are always connected to the internet.
On a related note, as I'm sure you're aware, there are many developers in other-than-the-richest-countries that might not have constant, continuous, and reliable internet. Beyond the (comparatively) luxurious issue of not being able to access the documentation when working on a laptop in an airplane without wifi, there are those who need to download things because they might have to go to a Cafe or other central point for internet access. Assuming someone has internet all the time as a design decision would tend to make it very difficult for people in that situation.
I don't want to come off as overly critical -- not my intention at all. (Maybe more of a "Hey, have you thought about this other aspect....") And I might be totally off here - I don't know... What are your thoughts?

@danieldjewell IMHO this is outside of the context of this issue, since it's about downloadable HTML docs.
I believe what you want can be covered when the json output for rustdoc is stable, at which point much tooling (including docs.rs) can just use the JSON output to generate any format.

Are changes needed related to intra-doc-links?

Hmm, most likely yes. @Kapeli how would you expect relative links to other crates to work? Currently they'd point to https://docs.rs, which seems to defeat the point of downloadable docs.

I'd prefer them to point to https://docs.rs and I can make Dash check if the other crate is installed locally before actually going to https://docs.rs.

I think it might also be fine to make this the responsibility of whatever tool is packaging the docs into docsets; it's not that hard to parse HTML, there are lots of libraries for it.

I prefer it if you just archive what you have now and I'll fix/rewrite/clean any issues I encounter.

since we serve toolchain-shared or unversioned-shared files separately, we exclude them from the doc-output, so they will be missing in the current archive.

It doesn't seem too hard to add them into the archive - there are many fewer shared files than per-crate files, it seems ok to do a bit of preprocessing for them on the docs.rs server. Alternatively, we could expose an API for "all shared files" and make it the responsibility of the client to combine them properly.

@jyn514 so adding these into the archive would be the first step? Then the only thing needed is rewriting the HTML.

I think it might also be fine to make this the responsibility of whatever tool is packaging the docs into docsets; it's not that hard to parse HTML, there are lots of libraries for it.

I prefer it if you just archive what you have now and I'll fix/rewrite/clean any issues I encounter.

That's good to hear @Kapeli !
@jyn514 what's your take on having the archive download in a (probably private) endpoint before having downloadable docs for everyone?

what's your take on having the archive download in a (probably private) endpoint before having downloadable docs for everyone?

What would be the purpose? If you just want a couple example archives to test and make sure they can be converted to docsets, I can grab them off S3 manually.

so adding these into the archive would be the first step?

I prefer it if you just archive what you have now and I'll fix/rewrite/clean any issues I encounter.

I think the archives should work fine as is - they still link to the shared files on docs.rs, the shared files just aren't in the archives themselves. But there's few enough shared files it's possible to download them one by one (around 10 for each nightly toolchain).
Hmm, I wonder if it makes sense to have a separate archive that has all the shared files at once, so you only have to make one request instead of ~15000.

I think it boils down to a use-case question:

should this be more or less access to the internal build result (the archive)? Any user of this archive would have to rewrite all references to shared CSS or JS files and download these too. The links currently point to /, so rewriting is needed even when someone would want to use our hosted CSS/JS files.
Or should the archive be more self-contained and directly usable? Then anyhow could curl the archive, extract it and open it locally.

For the case of Dash/Kapeli I assume that rewriting could be done by them, while fetching the static files is additional logic while already rewriting HTML.

Hmm, I wonder if it makes sense to have a separate archive that has all the shared files at once, so you only have to make one request instead of ~15000.

As I understand the use-case the archives are downloaded and converted one-by-one, not all at once, so putting all shared static into one archive doesn't make much sense.
@jyn514 how did you see the feature / the use-case?

@syphar I was imaging this is only for Dash (or other tools that want to preprocess it). Recall we discussed this above (https://github.com/rust-lang/docs.rs/issues/174#issuecomment-917683422).

Hmm, I wonder if it makes sense to have a separate archive that has all the shared files at once, so you only have to make one request instead of ~15000.

As I understand the use-case the archives are downloaded and converted one-by-one, not all at once, so putting all shared static into one archive doesn't make much sense.

So there are three options here:

Put the shared files into each archive. This duplicates the files for every release, and specifically so that downloadable docs are more convenient; docs.rs doesn't need them in the archives.
Don't archive the shared files at all; require them to be downloaded one at a time. This is the current situation. This works well for viewing a single crate, but if you're downloading the shared files in bulk then you need to make quite a lot of requests.
Have a single archive for all shared archives; this allows downloading multiple shared files at once. This helps docs.rs too because it can cache the whole archive locally, which means many fewer requests to S3 (recall shared files are necessary on every single rustdoc page).

I'm ok with either 2 or 3. I don't think 1. makes sense given that Dash is preprocessing the files anyway.

After the discussion in discord we'll start with (2):

a download-endpoint per release, probably raising 404 (or 410?) when the release doesn't have an archive
we just return the current archive, which is missing toolchain-shared and unversioned/shared files. These would have to be downloaded one-by-one from docs.rs. The caller can cache these by file-name, so all releases on a certain day share these files.

(3) having the single archive for static files would mean we have to update the archive every day, and re-upload it with the whole history. Also the performance-improvement would be very small since these static files are cached in the CDN anyways.

or 410

not 410, we plan to backfill the archives at some point

Mentoring instructions: add a new rustdoc_page route to https://github.com/rust-lang/docs.rs/blob/8e35ec47e4c46bea13fb33ada4d25887de93bdc3/src/web/routes.rs#L10 which matches /:crate/:version.zip and fetches the relevant file from S3, using fetch_archive_file (see the example in https://github.com/rust-lang/docs.rs/blob/8e35ec47e4c46bea13fb33ada4d25887de93bdc3/src/web/rustdoc.rs#L350).

Mentoring instructions: add a new rustdoc_page route to
https://github.com/rust-lang/docs.rs/blob/8e35ec47e4c46bea13fb33ada4d25887de93bdc3/src/web/routes.rs#L10
which matches /:crate/:version.zip and fetches the relevant file from S3, using storage.get_from_archive (see the example in

Small correction here:

which matches /:crate/:version.zip and fetches the relevant file from S3, using storage.get_from_archive (see the example in

it's actually storage.get, since we don't want to get something from inside archive, but the archive itself.
Plus, since archives might be gigabytes in size it would be good to stream them to the client, and not loading the whole archive into memory on the server.

https://github.com/rust-lang/docs.rs/blob/8e35ec47e4c46bea13fb33ada4d25887de93bdc3/src/web/rustdoc.rs#L350
).

In this part we will see which archive to fetch (the rustdoc one).

any updates? this is a trivial issue ongoing for 4 years now...

(3) having the single archive for static files would mean we have to update the archive every day, and re-upload it with the whole history. Also the performance-improvement would be very small since these static files are cached in the CDN anyways.

Is the goal of downloadable docs to improve performance, or to ensure docs are available when offline? I'm assuming the latter.
In that case, it's important for tools that want to download docs to be able to enumerate all the static files that might be needed by a bundle of docs. It's not trivial to enumerate these just by processing HTML, because some are loaded by JS (e.g. search-index).
I think we probably need to start recording a mapping of rustdoc release -> list of static files, and provide that listing as part of the bundle for crate docs built with that release.

Is the goal of downloadable docs to improve performance, or to ensure docs are available when offline? I'm assuming the latter.

yes, the latter. More specifically this issue here is about offline doc readers that have to process the docs anyways to make them usable in their docsets.

In that case, it's important for tools that want to download docs to be able to enumerate all the static files that might be needed by a bundle of docs. It's not trivial to enumerate these just by processing HTML, because some are loaded by JS (e.g. search-index).

Since processing and HTML rewriting is needed anyways right now

Ah, I misspoke about search-index. Good catch. But the problem exists for settings.js, settings.css, and search.js. They are loaded at runtime by other JS that uses rustdoc-vars to figure out their paths. Perhaps it's true that these pieces of functionality aren't needed by offline doc readers, but it seems like a potential source of fragility / worrying future bug.
For other, more typical <script> and <link> tags: do we know it's definitely the case that Dash and other offline doc readers will process all downloaded files to find such files and predownload them?

Ah, I misspoke about search-index. Good catch. But the problem exists for settings.js, settings.css, and search.js. They are loaded at runtime by other JS that uses rustdoc-vars to figure out their paths. Perhaps it's true that these pieces of functionality aren't needed by offline doc readers, but it seems like a potential source of fragility / worrying future bug.

The idea is to start simple, following the comment from above by Kapeli:

I prefer it if you just archive what you have now and I'll fix/rewrite/clean any issues I encounter.

Currently we're "just" exposing the internal archive for everyone that want to work with the build output in a programmatic matter.
When we have the first actual consumers we will see what's missing and if it's even possible to expose for us.

@jsha your point around assets that are not referenced directly in HTML sounds of course like a valid one, but I don't know enough about how the docsets would be processed to know what is actually needed.
IMO any more sophisticated approach would be based on this archive, so this is a valid first step.
Further steps could be to provide archives for the toolchain specific static files in a sensible way.

Can you provide info on how to access archives for other crates? For example, I'm not able to get the archive for the sql crate at https://static.docs.rs/rustdoc/sql/0.4.3.zip

Can you provide info on how to access archives for other crates? For example, I'm not able to get the archive for the sql crate at https://static.docs.rs/rustdoc/sql/0.4.3.zip

This will be possible after #1865 is deployed, via the endpoint directly on docs.rs. It will give you a redirect to static.docs.rs while taking care of the necessary permissions.

And please don't depend on static.docs.rs directly, there are some changes that may require that to change (e.g. if we do #1853).

While this is merged, closed & deployed, there are some open permissions that need to be set.
I'll update you all here when that's fine

This change is live & deployed right now.
https://docs.rs/about/download

Is there any crawling policy for these downloads? For example would it be ok to download all docs with 1 request per second speed?

@malaire we haven't yet made a policy, but I'm curious why would want to do that? It's several terabytes of data, mostly for crates that have been used less than a dozen times or aren't the latest version.

I didn't realize it's that much data.
I don't want to rely on internet and want to keep important data locally, but as I already have all crates downloaded, in this case
it probably makes more sense to just generate docs locally as-needed instead of storing everything I might someday need.

I didn't realize it's that much data.
I don't want to rely on internet and want to keep important data locally, but as I already have all crates downloaded, in this case it probably makes more sense to just generate docs locally as-needed instead of storing everything I might someday need.

The main point of the downloadable docs archive  is to give offline docs-readers like Dash the data to process so they can generate the docsets, which then can be used by Dash or Zeal (on linux).
So if you wait a little longer, you'll have it.

Thanks a lot for your work on this @syphar.
I'll integrate it into Dash ASAP.

@Kapeli do you have any estimate when it will be available? Dash without docs for packages on crates.io is not much useful and this is an amazing app <3

@syphar I'm almost done adding support for this in Dash.
I've found a crate for which downloadable docs are not available: cfg-if: https://docs.rs/crate/cfg-if/1.0.0/download is a 404. Is this intentional (i.e. archived docs are not available for some crates yet and I should throw an error when this happens)?

@Kapeli

To keep in mind: The archive only exists for all releases built since #1342 (sep 2021). Only looking at the latest version you will have an archive for ~40k crates out of ~92k. We're planning a rebuild for older releases (see #464 ), but this needs some infrastructure work we're also working on.

@syphar I'm almost done adding support for this in Dash.

this is awesome!

I've found a crate for which downloadable docs are not available: cfg-if: https://docs.rs/crate/cfg-if/1.0.0/download is a 404. Is this intentional (i.e. archived docs are not available for some crates yet and I should throw an error when this happens)?

I didn't check this specific release, but see my comment from above:

To keep in mind: The archive only exists for all releases built since #1342 (sep 2021). Only looking at the latest version you will have an archive for ~40k crates out of ~92k. We're planning a rebuild for older releases (see #464 ), but this needs some infrastructure work we're also working on.
IMO most popular crates will be fine, and I hope this will be added to Dash anyways.

So yes, for now this is expected.

archived docs are not available for some crates yet and I should throw an error when this happens)?

Yes, the most simple solution would be to show an error stating that the archive is not available or something like that. Crate authors always can request a rebuild with us if they want.
When back home I can also check our database and see if we proactively trigger a rebuild for all latest releases with >1k downloads or something like that, this depends on the numbers. But we still need the error message for the user.
I assume you mostly (only?) show latest versions?

Thanks for the clarification. I'll add the error message.

I assume you mostly (only?) show latest versions?

Pressing the Download button installs the latest stable version, but users can also install older versions by opening the popover.

Has this been added to Dash yet? I don't see the Rust Docsets Third-party source in my app.

Has this been added to Dash yet? I don't see the Rust Docsets Third-party source in my app.

To my knowledge there is nothing released.

I'm sorry, I've been having some health issues, mostly due to burnout. I'm currently working on Dash 7, which will include Rust Docsets support. It's almost done, it just needs some polish, but I'm not sure when I'll actually release it.

@Kapeli Thank you for the update. I hope you find the rest you need.


Dev Doc drawer playground temporary drawer causes a softlock

Describe the bug
In drawer playground, temporary drawers cannot be dismissed
What are the steps to reproduce?

Go to https://brightlayer-ui-components.github.io/react-dev/components/drawer/playground
Change variant to "temporary"
now you cannot get out of this state.

fixed at some PR in the past 24 hr


Main page should allow choice of problems displayed

There should be a file selector on the page to switch the problems on the page.

we can keep 9 equations on a single page, but one of the options should be to provide all user-inputted math problems

Completed.


TestErrorsTemporary fails with "can't assign requested address"

Your environment.

Version: 38e39e4
Browser: n/a

What did you do?
Ran unit tests on my mac:
% sw_vers
ProductName:		macOS
ProductVersion:		14.2.1
BuildVersion:		23C71

What did you expect?
All tests under pion/dtls to pass.
What happened?
=== RUN   TestErrorsTemporary
    /Users/ytakeda/Projects/pion/dtls/errors_errno_test.go:26: Unexpected error: dial udp <IP_ADDRESS>:0: connect: can't assign requested address
--- FAIL: TestErrorsTemporary (0.00s)
FAIL
FAIL	github.com/pion/dtls/v2	0.203s

@at-wat do you remember what the purpose of this test was? I feel this test should just be removed...

That error seems to come from DialUDP. That really should never fail, for something with port 0 as that's just "give me a free port on this machine". The test doesn't fail for me locally, and I've never seen it fail in CI. I don't think we should just scrap the test without understanding what's causing this.

@at-wat do you remember what the purpose of this test was? I feel this test should just be removed...

This tests netError() which wraps raw errors by the typed errors.
https://github.com/pion/dtls/blob/9e8c93ee311499a813046d51bf50ffe5f4df9ad7/errors.go#L79-L99
Raw errors from network operations may have Temporary() and Timeout() interface which must be inherited to the typed errors.

@at-wat
I see! I did not notice it. So, this test needs to create a case where "connected" (bound to a specific remote transport) UDP socket but the server is not listening, and expecting to receive a TemporaryError from conn.Read.
@daenney

That really should never fail, for something with port 0 as that's just "give me a free port on this machine".

That is true for local port in my understanding. I believe the error is about remote port set to 0. "hey, connect me to any port!" does not make sense to me, but it landed on master, it must have passed the test, but not on my mac...
To create the intended setup, I think we should use net.ListenUDP on <IP_ADDRESS>:0, get its local address, then close it right away.  Then, use the address as the remote adder (no one is listening) for the DialUDP...
Thoughts?


Options in the FIlter Settings Dropdowns for LD are duplicated

Only matrix table had few duplicate entries. I have removed those from the database table.


Query: investigate/fix failures in FiltersInheritanceInMemoryTest test suite

These tests work for relational providers but InMemory has issues - investigate and fix

Closed in favor of #16963


daemon.CopyOnBuild from daemon/archive.go should use go-winio on Windows

The docker daemon uses the archiver package in CopyOnBuild to in order to get files into a container as part of an ADD command in a build.  Unfortunately, this means that Windows specific alternate data streams are lost, as the regular archiver implementation does not capture these.
To better support Windows file attributes and alternate data streams, the files should be copied using backup-streaming semantics introduces in https://github.com/Microsoft/go-winio package.  This is already in use for docker commit, and could be extended into the archiver package so that Windows specific files are handled properly.
For an example of the alternate data streams being lost, use "dir /r" on a file that was downloaded from the internet (it will have a Zone.Identifier alternate data stream identifying where it was downloaded from).
On the host:
dir /r \test\simple*
Volume in drive C has no label.
Volume Serial Number is 3622-361C
Directory of C:\test
02/10/2016  11:17 AM            67,646 simple_icon_50.ico
26 simple_icon_50.ico:Zone.Identifier:$DATA
1 File(s)         67,646 bytes
0 Dir(s)  11,712,167,936 bytes free
In the container after ADDing that file:
Step 3 : RUN dir /r \simple*
---> Running in 94b92d329f78
Volume in drive C has no label.
Volume Serial Number is ECAB-5980
Directory of C:\
02/10/2016  11:17 AM            67,646 simple_icon_50.ico
1 File(s)         67,646 bytes
0 Dir(s)  21,269,565,440 bytes free

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@swernli @jhowardmsft is this still an issue? Is this still needed?

@thaJeztah The problem still repros for me.  When files are copied into a container, they lose their alternate data streams, which means metadata (like where the file was downloaded from) are gone.  Using go-winio as suggested about should be able to resolve this issue, but may be @jstarks can comment more.

I suppose it won't fix the issue, as the client context is first built into a tar archive (which have no notion of alternate data stream IIRC).
If we want to support those, we would need to use another kind of archive.


version 0.6.0

As soon as 0.5 is done, I will start working on these:

Improve the documentation generator; it's not very useful currently.
ncurses bindings; I want at least some basic user interfacing
Improve evaluator performance; there's a lot that can be done and I'm not satisfied currently.
Complete testcases for the prelude

make docs will now create HTML documentation in the doc subdir.

The changes I made today have improved the evaluator performance by almost 20%, according to my (simple) benchmarks.


PyTAG + Action Spaces

This is a large PR with various changes to the framework. The 2 main changes are coming from the ActionSpaces that allow altering the action space computation, the other big change is PyTAG which implements a Reinforcement Learning interface in JAVA which serves as the main entry point for RL agents.
PyTAG's main entry point is in core.PyTAG
PyTAG requires the implementation of 2 interfaces

IOrderedAction: which generates a tree structure with the available actions in a fixed order
IVectorisable: extracts the state representation from the game state either as a vector or as a JSON object

Also - Catan fails the ForwardModel Tests (tests.games.fmtester), as copying the game state changes the hashcode (which it shouldn't):
Running Game 1 of Catan with seed -1280492308 at Wed Jun 21 17:45:00 BST 2023
Problem on state copy - orig/copy hashcodes are -433429348/-2028848153
Orig: games.catan.CatanGameState@e62a649c
Copy: games.catan.CatanGameState@87123be7

The OMATests fail because chunks of the setup have been removed? Everything in test.players.mcts.OMATests

Also - Catan fails the ForwardModel Tests (tests.games.fmtester), as copying the game state changes the hashcode (which it shouldn't): Running Game 1 of Catan with seed -1280492308 at Wed Jun 21 17:45:00 BST 2023 Problem on state copy - orig/copy hashcodes are -433429348/-2028848153 Orig: games.catan.CatanGameState@e62a649c Copy: games.catan.CatanGameState@87123be7

Fixed this, the random number generator slipped into the hashcode, without it it's fine. Not sure about the OMATests though


Adds MAUI extension steps : head projects, templates, project property transforms, source code updates

Looking for feedback on the code I added to handle the Multiple TFms that get added to a .NET MAUI head project. I added a component check + log warning to the IUpgradeReadyCheck to allow MAUI projects only
I also added a new MSBuild property called ProjectPropertyElements, implementation can be found here. This is for the unevaluated project properties (of which there are many in legacy Xamarin projects). These properties have new mappings or have new values which is why I needed to add this. I followed the interface pattern. I wasn't sure how to explicitly add a test for this, if someone could let me know, I can add that.
Fixed a small typo in this message: https://github.com/dotnet/upgrade-assistant/blob/swsat/maui-tmpts-source/src/extensions/default/Microsoft.DotNet.UpgradeAssistant.Steps.Solution/CurrentProjectSelectionStep.cs#L234
For DevOps, I added this file, @twsouthwick  made a good point to add a ReadME to explain what is going on and maybe some troubleshoot steps for the future. What would be the best place to add this information? A readme in that eng folder?
All other changes are isolated to the maui-extension project and updates to the E2E test data files to reflect the new steps added!
Fixes:
https://github.com/dotnet/upgrade-assistant/issues/551
https://github.com/dotnet/upgrade-assistant/issues/552
https://github.com/dotnet/upgrade-assistant/issues/587
https://github.com/dotnet/upgrade-assistant/issues/590
https://github.com/dotnet/upgrade-assistant/issues/589
https://github.com/dotnet/upgrade-assistant/issues/755
https://github.com/dotnet/upgrade-assistant/issues/588

@mjrousos @sunandabalu @KSchlobohm  could I also ask for your feedback on the points Taylor raised :

this comment to get around MultiTargets https://github.com/dotnet/upgrade-assistant/pull/790#discussion_r687268903

Context, MAUI Head projects (post migration, head Xamarin forms project does not have multi-target) as part of migration process, get a new TargetFrameworks added into them. I handle setting the frameworks in the extension TFM filter, and only change I made was to this IUpgradeReadyCheck to stop the error being logged in the UI

For the Roslyn Analyzer, I need to update the naming to UAXXX, is there a full list I can verify what the last number was so I can update my analyzers with the correct values?

Issue to discuss the Multitarget Project Flow : https://github.com/dotnet/upgrade-assistant/issues/797


Firewall - live view contains a link to jump to the edit dialog of triggered rule

It would be a good feature regarding to the usability of opnsense, if the detailed log entry contains a link to the triggered rule.
For the purpose of faster and better editing rules or jumping to the triggered rule, I am missing a solution that will show a link to the triggered rule in the detail dialog of an entry in firewall live view dialog."
Describe the solution you like
If i am at the detailed information dialog "Detailed rule info" there will be a link to edit the triggered rule, which was responsible for that entry. The link can also be shown on the "FIREWALL: LOG FILES: LIVE VIEW"-table view.

Like suggested, created a new one: https://github.com/opnsense/core/issues/6840


Add andrewstucki to CODEOWNERS

Adding myself to the CODEOWNERS file so that I can get auto-added to reviews.

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

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


Feature/detox

You don't have to merge this in if you don't want to yet, still trying to figure out the best way to do this
Install the global Detox requirements as stated here, which are below this anyways.
Install Detox command line tools (detox-cli)
npm install -g detox-cli

Install applesimutils (iOS)
brew tap wix/brew
brew install applesimutils

Choosing Devices
You need to set the iOS simulator and Android emulator you want to use for testing. I made a file called devices.js where you can edit these devices. You can like Android emulators with emulator -list-avds. It looks something like this:
module.exports = {
    ios: 'iPhone 12 Pro Max',
    android: 'Pixel_3a_API_30_1'
};

Runnings Tests
I made a simple scroll up and down test for collectionview so far. I made a script called e2e/run-tests.js which will easily run for any platform or framework. If you run ./e2e/run-tests.js --help to see all the options.
I aliased that script to an npm script, so you can run npm run e2e --help for that same command, and I added ones for just building for all platforms and running on all platforms.
By default (for this repo), Angular, Vue, Svelte, and React tests will run.

Love it!


Support for private repositories

I'd love to get your fancy notifications when private repos push new releases !

Hi @pyatyispyatil. I wanted to work on this if you do not mind.
I see that this bot works with one static GitHub token. As private repos are individual for each user, we should take GitHub token from user as well. But with current implementation I am not sure if it is possible.
So I wanted to move repo data inside users in this case it will be individual for each of them. The disadvantage is that it same repos will be fetch multiple times.
What do you think about it?

@doniyor2109 I think it would be preferable to add the ability to add a separate token through the bot UI in Telegram using a separate button. Well, also add an alert when adding a new repository, if it is suddenly private and the user does not have an individual token.
IMHO, the main use of the bot should be with the main github token so that users don't think too much about it.
For the rest, I'm glad you decided to take on this task.)


Add custom welcome message for new users

Use the team_join event to send new user's a PM with lots of info from @tmarconi
Example for reference - https://api.slack.com/best-practices/blueprints/new-user-notification
Example for DM'ing a user w/ ruby - https://github.com/slack-ruby/slack-ruby-bot/issues/112#issuecomment-279061006
More comprehensive ruby example - https://github.com/slackapi/Slack-Ruby-Onboarding-Tutorial/blob/master/README.md#building-an-onboarding-bot-in-ruby-using-slacks-events-api
team_join payload https://github.com/slackapi/Slack-Ruby-Onboarding-Tutorial/blob/master/Section-3.md#add-the-other-event-handlers

[x] Get copy from Tim
[x] Figure out a test strategy (how we can create new users to test this properly?)
[x] Write code, test, ship, 💰

Fixed via #61


[PINOT-3248] First round check-in for re-factoring segment name code.

Added classes that encapsulate segment names of all styles known so far.
Kept the old code for now, will remove once I can add tests to prove equivalence.

lgtm otherwise

[Current coverage][cc-pull] is 38.10%

Merging [#216][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.42%

@@             master       #216   diff @@
==========================================
  Files           711        714     +3
  Lines         39050      38153   -897
  Methods           0          0
  Messages          0          0
  Branches       6260       6160   -100
==========================================
- Hits          15045      14537   -508
+ Misses        22771      22392   -379
+ Partials       1234       1224    -10

Powered by Codecov. Last updated by [98b4ed8...055d78b][cc-compare]
[cc-base-branch]: https://codecov.io/gh/linkedin/pinot/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/linkedin/pinot/compare/98b4ed8c3dfdfe8c898cf4a6375543874766a873...055d78bc978b43c9d28beebb64453234105dbf7f
[cc-pull]: https://codecov.io/gh/linkedin/pinot/pull/216?src=pr

Thanks for cleaning this. Is it possible to add a method that returns the type given segment name.
Lgtm

@kishoreg All in good time. I need to get this out now so that it unblocks us for continuing the low-level consumer work. Further re-factors will come soon to a PR near you :-)


Remove the testify dependency

testify is great, but tf doesn't really need have it as a dependency. Instead just use the build in reflect.DeepEqual, as testify does.

Yes, that's a great idea! Fancy putting in a PR? 😄

Now after merging #11


Support veto from all user

When a disputed result in "abstained from voting", we should let people cancel the claim that will veto it under the hood.
DOD :

UI should tell the user that the dispute has not been ruled (the jury abstained from voting)
GovernQueue contract "Resolve" method should redirect to "Veto" method in this case (the jury abstained from voting)
The veto state should be displayed as cancelled


Reload should preserve maximized panel

Refs: #79845

Maximize the panel
Reload
Panel is not maximized 🐛

Marking as a feature request since we never had this feature since panel could never be full height.
The ugly part about this flow is that we forget the previous size of the panel before the user maximized it (so he can not go back with a click)

Also instread of reload you can toggle panel visibility via ctrl/cmd + j. That should aslo preserve the maximized panel

Agree that the panel in a not almost maximized state never makes sense since the user looses the previous unmaximized state.
However I would still prefer that the panel remains maximized. Since the user can always click on the editor in the explorer / open editors view / quick pick and to get out of this mode. And you handle it already very nicely. So I am not worried about user being stuck at all.
Though I would love to hear the opinion from @tyriar since he is very passionate about this

@isidorn I see your points. I went store the editor state and use it on launch but because of other eventing, the editor area gets restored anyway. I need to look more deeply to get the right fix for this. In the interim, I have pushed a fix that stores the editor visibility and uses that to set the panel back to its pre-maximized state.

@sbatten thanks. That's fair. I do not think this is urgent for August. We can always look into it next milestone when we have more time.

Though I would love to hear the opinion from @Tyriar since he is very passionate about this

I think the main users this would help right now are those that want to use a window as a dedicated terminal window which isn't me. However, it would be very useful when we get into the business of restoring terminals across sessions if they are the same size. Even better if the panel is correctly positioned right from the beginning before the terminal starts up.

Also instread of reload you can toggle panel visibility via ctrl/cmd + j. That should aslo preserve the maximized panel

It doesn't preserve the original panel's size😔

This bug is very annoying because I use the shortcut cmd-j very often.