id_method_name not respected with polymorphic association

Version: 1.5
Without polymorphic association, I can do:
  belongs_to(
    :event,
    id_method_name: :event_uuid,
  )

It correctly uses event_uuid as the method to get the id of the association.
With polymorphic though:
  belongs_to(
    :resource,
    id_method_name: :resource_uuid,
    polymorphic: true
  )

id_method_name has no effect, it always uses resource_id as the id. I think this is a bug?

Can verify, also think this is a bug.

If this is a dealbreaker for someone I think you can work around it like this:

Use record_type: { Image: :image, etc }, this allows to use id_method_name and sets types correctly
Create a single serializer for the polymorphic association. E.g. ResourceSerializer
In ResourceSerializer use conditional attributes based on type, like so:

attributes :widht, :height, if: proc { |record, _params|
  record.class == Image
}

I'm not sure how/if relationships would work in this case.

This is still a bug and makes the use of polymorphic serialization difficult.


JSX tag with className attribute render a dom node with both class and className attribute

The following example illustrates the issue:
const Button = ({label}) =>
  <button className="my-button">{label}</button>
;

const view = () =>
  <div>
    <Button label="Click me" />
  </div>
;

The rendered output (in Chrome, macOS High Sierra)
<button class="my-button" classname="my-button">Click me</button>

If I use class instead of className it renders correctly.
const Button = ({label}) =>
  <button class="my-button">{label}</button>
;

@leifoolsen We'll definitely fix this!
See also: https://github.com/picodom/picodom/pull/70

@leifoolsen The solution proposed above creates more problems and I decided to remove it from core. The suggestion I can give you is to not use className. There is no reason to use className since class works just as well and we do not intend to be compatible with React.

I agree. Using "class" is better.

Any idea why/how this broke SVG? Can we fix it?
class is not the only thing affected - for example, form elements get unnecessary value and checked attributes etc... Duplicating all property/attribute updates also sounds like unnecessary overhead - it's a bit of a hack.
Other engines manage to do property updates without duplicating everything, and all support SVG, so there must be an answer.

@mindplay-dk Sure, it's fixable, but it's a lot of code, and I don't consider this to be an important issue.

The difference was 20 bytes, as I recall? I don't think that's "a lot of code".
It seems haphazard to just litter DOM objects both with useless properties and meaningless attributes - I wish you wouldn't prioritize byte-savings over getting this right, but I don't know what else to say to make you change your mind.
To me, it's critical that the core component managing all the DOM updates of my UI code is making only exactly the expected, required, correct DOM changes. It's critical that the code is simple, readable, easy to understand, and fairly small.
Given that most networks can't even ship packets smaller than ~1.6 KB, it's much less critical to me whether or not we stay under some magical 1 KB limit - and especially when that constraint imposes any sort of trade-off against any of the critical priorities.
I'm very much in favor of artistic limitations when those inspire to making a better product - but I'm very much opposed to such limitations becoming dogma and inspiring to any qualitative trade-offs.

@mindplay-dk I am happy to reconsider, but your solution didn't take into account SVG, and yes, properly written, it was a lot of code, so I decided to keep the current, simpler approach.
You keep talking about "littering the DOM", but have provided little evidence to show this is actually a problem here; className and forms with value or checked attributes is a petty issue.
I would prefer if, instead of philosophizing, we could address what are the critical limitations of the current approach. That would lead to understanding, and understanding would lead to making a better-informed decision.


DO NOT MERGE! Fast Forward stable to 5e54cea6a5bf4f62abf51dcea0c25de77faee783.

This PR will be merged automatically once checks are successful.

Jenkins job manager/postsubmit passed


Revert "feat: add flag country code dropdown to profile form"

Reverts artsy/force#8393

@ashleyjelks - mind adding a reason for the revert in the PR description? 🙏

This PR was reverted because when it was QA'd on staging we found a bug that shouldn't be deployed. Will send a fix out today.

Sorry @ashleyjelks, meaning: what bug did you see? If something is reverted its usually from a bug, but that doesn't provide much info to other devs. Since reverts can be ambiguous and red-herring-ish its best to treat them like regular PRs with a properly fleshed out description.


Group Query Params in struct

Is it possible to group Query params within a struct but preserve the query param view in the ui?
I've implemented the ParseFromParameter Trait for my parameter:
pagination: Query<Pagination>

but this mess up the ui.

not supported yet 🙂

Thanks for raising this issue, I was searching for this thing for a while, and I wasn't finding anything about how to document parameters. And I see now, that I can use Query separately for the fields, without a struct.

Thanks for raising this issue, I was searching for this thing for a while, and I wasn't finding anything about how to document parameters. And I see now, that I can use Query separately for the fields, without a struct.

Check the examples, there you'll find everything available for most of the features

This would be a very useful feature, I don't think FastAPI supports this either https://github.com/tiangolo/fastapi/issues/3163


WidgetNode is missing ExportMixin types

The latest version 1.37.0 with pull request #81 have added WidgetNode types, but is missing ExportMixin as mentioned in docs https://www.figma.com/plugin-docs/api/WidgetNode/#export-related-properties

Ah sorry this is a bug with our docs.. the exportAsync method isn't available on WidgetNodes. Thanks for the report! Will fix the docs

Cool,
but typescript gives error though I have filtered only Framenode as shown above in image
const imageDataArray = figma.currentPage.children
  .filter((x) => x.type === "FRAME")
  .map((x) => {
    const frame = x as FrameNode;        <-------
    return frame
      .exportAsync({
        format: "PNG",
        constraint:
          x.width < x.height
            ? { type: "WIDTH", value: 34 }
            : { type: "HEIGHT", value: 34 },
      })

So I have to explicitly mention the type. Is there any better method that can implicitly make type to FrameNode

Here's a helpful post about this limitation in typescript: https://stackoverflow.com/questions/47994460/minimal-type-annotation-for-array-prototype-filter-and-discriminated-union
I also wrote out some options for you here that you might find helpful! https://www.typescriptlang.org/play?#code/C4TwDgpgBAYgTgQwLYQHIHsAm0C8UDeAUFCVKJAFxQDkAZoitcafchAPIB2ANiALIRgACyxUAFAEooOAHxQAbugCWmQgF9ChctHbCIcDNmkFmJbVWro9cJhq3hoAFUO5YDNFmgAfKLqH6XAG5NQgBjdE4AZ2AoTk9IqmdPAG0AXWM0zQB6LKgAUTg4dDhCOOxIgDpaJW5gfTEAD2k5BortaRw8OndqCSrivIRQoUbmqFbWFC5eAWEsSQls3PYAawQQKgBJHiVOJwcoAHMAVwQ4VTKISura+saJKialSLc2FzHW9s6uyYhe-rgg2Go1k4yq7mm-EEIkwCyWvjWGygAAkINxIHAoI4DiczqpaMdOKFgEoIlBnvA3p4xJdEi4HrFPOSXpSUO8iKQoHBBMc4JxGdg2gdvjRfrZNJdrjU6nAxBT3PSAUCRk1QRMITwoXNYRJFoQgA


Improving autocompletion for users and channels

Summary
Improving autocompletion for users and channels. Mainly handling the blur event
in the users input field.
Ticket Link
MM-17330

The changes will be tested as part of 5.16 release Guest Account feature. Removing the QA Review label.

@jespino, I'm having trouble understanding exactly what this PR is about. The linked JIRA is ambiguous as well. Could you post before and after screenshots to help explain?

@lieut-data Yes, I updated the description with the real definition of the new behavior.

Sorry to be a nuisance @jespino, but I'm finding myself really digging through the linked JIRA issues and the Invision diagrams to understand what this change is about. I think it would be really useful if the description of all PRs is self-contained.
If I understand correctly, the commend on this PR could be:

The guest accounts feature includes an autocomplete input field to simplify finding a user to invite. Sometimes there is no match, but the implementation was incorrectly discarding that part of the input when the element lost focus. Fix this to preserve the input, so we can surface the potential mistake on the next screen of the modal.

Is this accurate? Can you update the description accordingly?


Problem if code_artifact_domain contains dashes

Summary
If a dash is contained in the user's aws domain name, partifact has trouble parsing the url correctly.
Steps to Reproduce
Put this in pyproject.toml file:
[[tool.poetry.source]]
name = "aws"
url = "https://my-domain-123456789012.d.codeartifact.us-west-2.amazonaws.com/pypi/my-repo/simple/"
default = true

Then run this command:
partifact login aws
> botocore.errorfactory.ValidationException: An error occurred (ValidationException) when calling the GetAuthorizationToken operation: 2 validation errors detected: Value 'domain-123456789012' at 'domainOwner' failed to satisfy constraint: Member must have length less than or equal to 12; Value 'domain-123456789012' at 'domainOwner' failed to satisfy constraint: Member must satisfy regular expression pattern: [0-9]{12}

In this scenario, the rules that are parsing the source url are parsing the code_artifact_domain as my (instead of my-domain), and the aws_account as domain-123456789012 (instead of<PHONE_NUMBER>12)
Expected behavior:
The following url would be parsed as such:
url = "https://my-domain-123456789012.d.codeartifact.us-west-2.amazonaws.com/pypi/my-repo/simple/"

code_artifact_domain = my-domain
aws_account =<PHONE_NUMBER>12
code_artifact_repository = my-repo

Actual Behavior:
The following url is parsed as such:
url = "https://my-domain-123456789012.d.codeartifact.us-west-2.amazonaws.com/pypi/my-repo/simple/"

code_artifact_domain = my
aws_account = domain-123456789012
code_artifact_repository = my-repo

Proposed code changes to resolve this issue.

Amazing! Thank you so much!

That's done, your fix is in 0.1.6.


[BUG] Tests breaking due to a error in protobuf dependency

Description

Protobuf made a new release https://pypi.org/project/protobuf/#history
on Nov 27, 2024. It's breaking the tests.
    File "/home/runner/work/recommenders/recommenders/tests/ci/azureml_tests/post_pytest.py", line 75, in <module>
      runs = mlflow.search_runs(
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/fluent.py", line 2069, in search_runs
      experiment_by_name = get_experiment_by_name(n)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/fluent.py", line 1671, in get_experiment_by_name
      return MlflowClient().get_experiment_by_name(name)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/client.py", line 134, in __init__
      self._tracking_client = TrackingServiceClient(final_tracking_uri)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/_tracking_service/client.py", line 83, in __init__
      self.store
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/_tracking_service/client.py", line 87, in store
      return utils._get_store(self.tracking_uri)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/_tracking_service/utils.py", line 208, in _get_store
      return _tracking_store_registry.get_store(store_uri, artifact_uri)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/_tracking_service/registry.py", line 45, in get_store
      return self._get_store_with_resolved_uri(resolved_store_uri, artifact_uri)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/mlflow/tracking/_tracking_service/registry.py", line 56, in _get_store_with_resolved_uri
      return builder(store_uri=resolved_store_uri, artifact_uri=artifact_uri)
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/azureml/mlflow/entry_point_loaders.py", line 33, in azureml_store_builder
      from azureml.mlflow._store.tracking.store import AzureMLRestStore
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/azureml/mlflow/_store/tracking/store.py", line 17, in <module>
      from azureml.mlflow._protos.aml_service_pb2 import (
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/azureml/mlflow/_protos/aml_service_pb2.py", line 10, in <module>
      from google.protobuf import service as _service
    File "/opt/hostedtoolcache/Python/3.10.15/x64/lib/python3.10/site-packages/google/protobuf/service.py", line 78
      raise NotImplementedError
                               ^
  IndentationError: unindent does not match any outer indentation level
  Error: Process completed with exit code 1.

In which platform does it happen?

How do we replicate the issue?

https://github.com/recommenders-team/recommenders/actions/runs/12100479486/job/33739131547
Expected behavior (i.e. solution)

I expect Google to test their libraries before making a release.
Willingness to contribute

[ ] Yes, I can contribute for this issue independently.
[ ] Yes, I can contribute for this issue with guidance from Recommenders community.
[ ] No, I cannot contribute at this time.

Other Comments

Confirmed other people got the same error: https://github.com/protocolbuffers/protobuf/issues/19430

Update: @imatiach-msft and I talked with the AzureML dev team and they are going to remove the code that caused the error.
FYI @SimonYansenZhao @anargyri

Protobuf 5.29.0 was finally yanked: https://pypi.org/project/protobuf/5.29.0/

The yank of the version fixed the problem. See https://github.com/recommenders-team/recommenders/actions/runs/12168238375
The AzureML team is expected to update the deprecated dependency.
Closing this.


Stop peaton

Coverage remained the same at 69.278% when pulling 93e5f603b8ec3f8761d661faefe455135207d08b on eatonphil:stop-peaton into 8f37b789f518d48bb0fc7dc16449a5a0c445b5a6 on linode:develop.


added support for pelican-dynamic plugin

Like the author of the pelican-dynamic plugin, I also like the possibility of embedding D3 visualizations (in my case not only to posts---e.g. articles---but pages as well). I also love your bootstrap plugin. Here are my two cents, adding support for pelican-dynamic to both articles and pages.

Please only submit pull-requests with 1 feature each, as is clearly stated in the Contributing Guidelines. The way to do this, is to put changes for different PRs on different branches.
On a sidenote, the sortorder fix is not necessary anymore, now that Pelican already supports custom sorting.
Could you resubmit the PR for the pelican-dynamic plugin?

Oops, sorry about that (not much experience with pull requests). I just created a new pull request, as you suggested. Thanks for the pointer to the pelican sorting support!


feat(sms): Add SMS plugin

This PR adds the plugin for sending SMS with the CLI.
In order to test, have a working local copy of the cli, and use bin/run plugins:link ./packages/sms and run tests with npx lerna run test --scope=@vonage/cli-plugin-sms`

@pardel Can you also approve - I'd like to get these changes published. Thanks!


Feature/authors

Proposed changes

Types of changes
New Authors added

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x ] Refactor (changes to code, which do not change application behavior)

Checklist

[ ] I have filled out this PR template
[ ] I have read the CONTRIBUTING doc
[ ] I have added automated tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (README.md, inline comments, etc.)
[ ] I have updated the CHANGELOG.md under a ## next release, with a short summary of my changes

Relevant Links

Further comments

extra file added. placing a new PR.


Unable to Reproduce Results on Flowers102 and PartImageNet OOD

Hi,
First of all, thank you for this research—I'm really enjoying working with it.
I successfully reproduced the results on the CUB dataset, but I am facing issues with reproducing the results on Flowers102 and PartImageNet OOD datasets. Could you please provide an example command that works for these datasets?
 Additionally, any insights or recommendations for the PartImageNet OOD would be highly appreciated.
Thank you!

Hi, thanks for raising the issue.
The only difference in terms of training hyper-parameters for training on CUB (or NABirds) vs the other datasets is the input image size which changes from (518, 518) to (224, 224). From what I can see, you have already made this change in your provided commands.
Can you let me know exactly how much deviation you see with the results or if there are other issues with running the code?
In my own experiments I used a batch size of 128 for these two datasets (with learning rate set to 2.828e-6). If possible can you try that as well?

Hi, just an update, I think the issue is with the batch size.
Batch sizes of 128 and above should work (and have been tested).
If you're unable to do that, an alternative is to set the weight decay to a value of 0.05 (from the AdamW paper). I'll update the training instructions to include this. Thanks for letting me know about the issue!
By the way the "--dataset" flag in your partimagenet ood training should be set to "part_imagenet_ood".
I have tested batch sizes of 128 and up for this dataset as well.
Let me know if this helps!
In case you just want to use the models as is, use the torch hub code in the model zoo file.

I've added new instructions for training per dataset and included information about recommended batch sizes.
Feel free to re-open this issue if you still need help!


add a ~/.invokeai file the first time we load

If there is not already a .invokeai file in the user's home directory the first time invoke.py runs, it will create an empty one with comments showing how to customize it.
The file looks like this:

# InvokeAI initialization file
# Put frequently-used startup commands here, one or more per line
# Examples:
# --web --host=<IP_ADDRESS>
# --steps 20
# -Ak_euler_a -C10.0

Works as advertised on Windows. Created .invokeai in the users directory. Finds the file
# Put frequently-used startup commands here, one or more per line
# Examples:
# --web --host=<IP_ADDRESS>
# --steps 20
# -Ak_euler_a -C10.0

Tested with adding sampler and config file path to it. Works as expected.

It processes something for a second or two after finding files. Is this expected?


Remove root schedule: nodes on suggested YML config

I got no cron / every / at / in / interval found for schedule (schedule) - skipping following the starting guide.
This trips new people as the recommended initializer will parse the YML expecting to find the individual job configs right away (relevant line).

Same here. Should really be updated in the README.

Thanks to @jsamos for fixing the README

There are still references to :schedule: in the Readme, this tripped me up today.

Still an issue... this also caused confusion with me today...

:schedule: is the key to attach the schedule within sidekiq.yml config file: https://github.com/moove-it/sidekiq-scheduler#usage
If you are directly setting the schedule, or if you have the schedule in a different yml file: https://github.com/moove-it/sidekiq-scheduler#load-the-schedule-from-a-different-file
References to :schedule: in the Readme are in the context of sidekiq.yml file.
Feel free to re-open the issue if you think it's appropriate.


Why use nginx in Caddy configuration?

In the Caddy AIO script linked here: https://piped-docs.kavin.rocks/docs/self-hosting/
The backend is reversed proxied by nginx, then Caddy.
Is there any particular reason to put nginx in the middle?

Yes, because afaik caddy can't cache as a reverse proxy. (We'll been a build with xcaddy I think)

Thank you for the explanation!


[Feature request] Chained closure formatting

Today, chained closure are formatted like this:
let closure = |a| {
    |b| {
        println!("{a}{b}");
    }
};

I personally find it less readable than:
let closure = |a| |b| {
    println!("{a}{b}");
};

Could it be an option for this formatting?

Thanks for reaching out. I think this is a change that could be made, and it seems that the proposed formatting aligns with the style guide rules for closure expression. Specifically:

Use closures without the enclosing {}, if possible.

Any change to the existing formatting would need to be version gated.
The reason why we wrap this in an additional block is because it doesn't fit on a single line, however we allow other block-like expressions to be written without the extra blocks, so the proposed formatting seems to align with what we're already doing for match, loop, structs, etc.
For anyone interested in working on this you'll likely want to make adjustments to allow_multi_line here:
https://github.com/rust-lang/rustfmt/blob/5391847ea5a12262704657a0708b1674fb344403/src/closures.rs#L180-L219

@calebcartwright I was also thinking the style team would want to weigh in on this. I just wasn't sure if I should tag them in this issue.


python3Packages.vulkan: init at 1.3.275.1

Description of changes
Upscaler seems to have some inexplicable crashes when selecting files, I need to look into that a bit more, but this module seems to work just fine
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg build python3Packages.vulkan


Handle connection closed errors in backend logic

This pull request adds error handling for connection closed errors in the backend logic. Previously, when a connection closed error occurred, the error was not properly handled, leading to potential issues. With this change, the code now checks for connection closed errors and handles them appropriately. This improves the reliability and stability of the backend logic.

Codecov Report
Attention: Patch coverage is 42.85714% with 8 lines in your changes missing coverage. Please review.

Project coverage is 91.54%. Comparing base (adaf9a0) to head (40ba8b8).

Files
Patch %
Lines

backend/http.go
16.66%
4 Missing and 1 partial :warning:

backend/queue.go
62.50%
2 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
- Coverage   92.28%   91.54%   -0.74%
==========================================
  Files          24       24
  Lines         959      970      +11
==========================================
+ Hits          885      888       +3
- Misses         53       59       +6
- Partials       21       23       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Can't build  on ubantu

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

An error occurred when I executed the './bootstrap.sh 'command using ubantu build.

I looked on the Internet and didn't install the ruby environment but when I did, I still had this problem.

Please help me thank you

@AiTaiShan We'd be happy to look into this for you. Kindly file a support ticket here
https://forms.gle/zVGLP7GATPsDHdkH9

@Chukwulawrence Thank you very much for helping me. I can't open your link address

You need to install ruby as your prompt suggest, please let me know if u have any other questions

need to install ruby as your prompt suggest, please let me know if u have any other qu

Hi, I am one of team members with @AiTaiShan, and could you let me know what version of ruby should we use? Actually we met lots of blolking issues when we built it on ubuntu, so we worry that ruby version may matter. Thanks.

need to install ruby as your prompt suggest, please let me know if u have any other qu

Hi, I am one of team members with @AiTaiShan, and could you let me know what version of ruby should we use? Actually we met lots of blolking issues when we built it on ubuntu, so we worry that ruby version may matter. Thanks.

The prerequisited for linux are there: https://developer.trustwallet.com/wallet-core/developing-the-library/building#prerequisites-on-linux - you should be fine by following those instructions

I ran the command 'sudo apt-get install ruby-full' in ubantu version 22.04 and downloaded Ruby-3.0.2p107. I don't know if this version meets the requirements.

@LiWang-555 I ran the command 'sudo apt-get install ruby-full' in ubantu version 22.04 and downloaded Ruby-3.0.2p107. I don't know if this version meets the requirements.

it does

Thank you for answering my question, but the problem was not solved. I tried to download ruby by executing the 'sudo apt-get install ruby-full' command.

Then the same error occurs when executing the './bootstrap.sh 'command.

I hope you can tell me if this error is caused by the ruby version or other reasons.

Thank you for answering my question, but the problem was not solved. I tried to download ruby by executing the 'sudo apt-get install ruby-full' command.  Then the same error occurs when executing the './bootstrap.sh 'command.  I hope you can tell me if this error is caused by the ruby version or other reasons.

It's seems that ur computer is configured with CRLF instead of LF https://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf-and-cr-line-break-types - Can you double check locally and let us know if it works with LF file ending?

I downloaded the source code from github and opened it with vim in real dos format. I ran cat -A to see what the terminator looked like.

It doesn't work and then I modify it with vim 'set ff=unix' and it works and then I run 'cat -A' and I get the following result.

Do all files need 'set ff=unix'? That would be a lot of work.

I downloaded the source code from github and opened it with vim in real dos format. I ran cat -A to see what the terminator looked like.  It doesn't work and then I modify it with vim 'set ff=unix' and it works and then I run 'cat -A' and I get the following result.  Do all files need 'set ff=unix'? That would be a lot of work.

On my computer if I clone a new repo all the file endings are Unix, as I've said this means you've smth missconfigured somewhere that turn everyfile in CRLF format - you can also recursively run: dos2unix -D filename

it's up to you, I just want to sync my crypto on etherscan , bsc
automatically
Pada tanggal Sel, 21 Feb 2023 20.33, Sztergbaum Roman <
@.***> menulis:

I downloaded the source code from github and opened it with vim in real
dos format. I ran cat -A to see what the terminator looked like. [image:
1676984546470]
https://user-images.githubusercontent.com/125786180/220353900-f8d4bfcb-c982-474e-9fc3-670600b177d9.jpg
It doesn't work and then I modify it with vim 'set ff=unix' and it works
and then I run 'cat -A' and I get the following result. [image:
1676984618765]
https://user-images.githubusercontent.com/125786180/220354729-2b9ba88e-27d0-412d-91e7-a1568174e4a7.jpg
Do all files need 'set ff=unix'? That would be a lot of work.
On my computer if I clone a new repo all the file endings are Unix, as
I've said this means you've smth missconfigured somewhere that turn
everyfile in CRLF format - you can also recursively run: dos2unix -D
filename
—
Reply to this email directly, view it on GitHub
https://github.com/trustwallet/wallet-core/issues/2940#issuecomment-1438500373,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5BVVYGWZE36TCJGXLES2N3WYS73LANCNFSM6AAAAAAVAY2TL4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thank you. I think I found the reason. I downloaded the code to windows first and then transferred it to the virtual machine,But I ran into a new problem, need to install Xcode on ubantu?


Clean up the networking server & add bootnode peer discovery

Description
This PR is part of a bigger refactor effort on the networking package.
Contained in this PR:

Separated out services for discovery and identity
Completely mockable and unit testable discovery and identity
Cleaned up code in the base networking server
Simplified logic for networking service initialization
Fixed bugs in connection management
Added unit tests for modified / added functionality

Bootnode peer discovery
A new mechanism was added to the discovery service, where bootnodes are dialed temporarily for their peers, and their peers are then dialed for handshaking / permanent connecting.
Changes include

[x] Bugfix (non-breaking change that solves an issue)
[x] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)

Checklist

[x] I have assigned this PR to myself
[x] I have added at least 1 reviewer
[x] I have tested this code
[ ] I have updated the README and other relevant documents (guides...)
[x] I have added sufficient documentation both in code, as well as in the READMEs

Additional Comments
Fixes EDGE-65

I have read the CLA Document and I hereby sign the CLA

recheck

 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.

Why not create network/e2e package?

@zivkovicmilos I faced a failing test when running tests locally today.

...
?       github.com/0xPolygon/polygon-edge/licenses      [no test files]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x4abbda6]

goroutine 25932 [running]:
github.com/0xPolygon/polygon-edge/network.(*PeerConnInfo).addProtocolStream(...)
        /Users/kourin/go/src/github.com/0xPolygon/polygon-edge/network/server.go:232
github.com/0xPolygon/polygon-edge/network.(*Server).NewDiscoveryClient(0xc0001c7c20, 0xc006f0e2a0, 0x27, 0x10, 0x5e01878, 0x10, 0xc004a42090)
        /Users/kourin/go/src/github.com/0xPolygon/polygon-edge/network/server.go:873 +0x186
github.com/0xPolygon/polygon-edge/network/discovery.(*DiscoveryService).findPeersCall(0xc0089e91d0, 0xc006f0e2a0, 0x27, 0xc003904100, 0x2, 0x2, 0x0, 0x0, 0x0)
        /Users/kourin/go/src/github.com/0xPolygon/polygon-edge/network/discovery/discovery.go:240 +0x62
github.com/0xPolygon/polygon-edge/network/discovery.(*DiscoveryService).attemptToFindPeers(0xc0089e91d0, 0xc006f0e2a0, 0x27, 0xc000cb4080, 0x4fe6e20)
        /Users/kourin/go/src/github.com/0xPolygon/polygon-edge/network/discovery/discovery.go:223 +0x10a
github.com/0xPolygon/polygon-edge/network/discovery.(*DiscoveryService).regularPeerDiscovery(0xc0089e91d0)
        /Users/kourin/go/src/github.com/0xPolygon/polygon-edge/network/discovery/discovery.go:307 +0x95
created by github.com/0xPolygon/polygon-edge/network/discovery.(*DiscoveryService).startDiscovery
        /Users/kourin/go/src/github.com/0xPolygon/polygon-edge/network/discovery/discovery.go:282 +0x150
FAIL    github.com/0xPolygon/polygon-edge/network       72.716s
...

@Kourin1996
I've narrowed down the problem:

Peer A and Peer B are connected
Peer B closes the connection to Peer A
Before Peer A registers that the connection is closed (DisconnectedF callback is called (removePeer), it runs the discovery service to query new peers
It gets a random peer (from the outdated list) A (this is the discovery service)
It opens a connection for discovery
It attempts to save a reference to the stream, but the connection info for Peer A is nil
Panic 🙂

The problem is that the discovery service assumes that the connections are already there (because of identity), but that doesn't have to always be the case.
I've resolved this problem and wrote up a unit test that makes sure this sort of thing doesn't happen:
39a87a9


trailing slash/whitespace in path dependency causes problems

pubspec.yaml:
name: my_package
description: foobar
dependencies:
  polymer:
    path: /dgrove/repo/dart-bleeding/dart/pkg/polymer/
causes this error (note the /ib/ in the path) when I do this:
$ pub run polymer:new_entry web/index2.html
[RewriteImport]:
FileSystemException: Cannot open file, path = '/dgrove/repo/dart-bleeding/dart/pkg/polymer/ib/click_counter.dart' (OS Error: No such file or directory, errno = 2)

This issue has been moved to dart-lang/pub#1104.


Different version, edition and productname in status request and capabilities request

Describe the bug
When requesting the capabilities endpoint and the stauts.php endpoints, we get different values for version, edition and product name
Steps to reproduce

On capabilities request

❯ curl https://localhost:9200/ocs/v2.php/cloud/capabilities -k -u admin:admin | xmllint --format -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2480    0  2480    0     0  77500      0 --:--:-- --:--:-- --:--:-- 77500
<?xml version="1.0" encoding="UTF-8"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>200</statuscode>
    <message>OK</message>
  </meta>
  <data>
    <capabilities>
      <core>
        <pollinterval>60</pollinterval>
        <webdav-root>remote.php/webdav</webdav-root>
        <status>
          <installed>1</installed>
          <maintenance>0</maintenance>
          <needsDbUpgrade>0</needsDbUpgrade>
          <version><IP_ADDRESS></version>
          <versionstring>10.0.11</versionstring>
          <edition>community</edition>
          <productname>reva</productname>
        </status>
        <support-url-signing>1</support-url-signing>
      </core>
...
  </data>
</ocs>

From status.php

❯ curl https://localhost:9200/status.php -k
{
    "installed": true,
    "maintenance": false,
    "needsDbUpgrade": false,
    "version": "<IP_ADDRESS>",
    "versionstring": "10.0.9",
    "edition": "community",
    "productname": "ownCloud"
}%

Setup
Please describe how you started the server and provide a list of relevant environment variables.

OCIS_VERSION=git
BRANCH=master
STORAGE_FRONTEND_UPLOAD_DISABLE_TUS=false

Additional context
Add any other context about the problem here.

Fixed with PR #3231 which pulled in https://github.com/cs3org/reva/pull/2581 - the values now match each other.
There is a separate issue about actually advertising a changing version numb er, using semver etc.


ModelScale

Parameter "ModelScale" in file settings_NAME.txt not working!

Thank you for your report.
It worked fine with my settings, so it's possible you misconfigured somewhere.
Does the NAME parameter in settings_NAME.txt exactly match the name of the player in Valheim?
Or have you edited the comments?
Or have you placed settings_NAME.txt in the correct path?

I did not correct the comment, everything is clear with the syntax.
I correct the value for example: "Default=1.5" or "Default=1.8" (without quotes).
Nothing will work.
Additional question. In the game, when I put on the armor, it is not visible - this is how it should be, ok. But when I put on the belt (additional weight), it is displayed on the character model in the chest area in an enlarged view ...
Anyway, thanks for the mod, I wish you success.

OK,
Please check ver1.0.3 as I have just updated the settings related.
The problem with the belt being displayed has also been fixed.
https://github.com/yoship1639/ValheimVRM/releases/tag/ver1.0.3

OK,
Please check ver1.0.3 as I have just updated the settings related.
The problem with the belt being displayed has also been fixed.
https://github.com/yoship1639/ValheimVRM/releases/tag/ver1.0.3

Everything is fine. GJ!


Feature Request: Use postcss-calc to simplify calc expresssion

They will simplify a few css calc() on .col-form-label

Closing this since we only use calc in like 2 places.
We might reconsider in the future if needed.


[DOC] - Add next steps to getting started

Preliminary Checks

[X] This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/nebari-dev/nebari/discussions

Summary
There is a need to include some next steps instructions to the end user once Nebari is fully installed, directing the user on how to access Nebari and use its services
Steps to Resolve this Issue

Add end note to each cloud provider with proper link and information

...

done.


OCM/ACM integration

Support to injecting faults into Open Cluster Management (OCM) and Red Hat Advanced Cluster Management for Kubernetes (ACM) (not tested) managed clusters through ManagedCluster Scenarios.
ManagedCluster scenarios leverage ManifestWorks to inject faults into the managed clusters.
Example of a complete run with the following configuration:
managedcluster_scenarios:
  - actions:                                                        # ManagedCluster chaos scenarios to be injected
    - managedcluster_stop_start_scenario
    managedcluster_name: cluster1                                   # ManagedCluster on which scenario has to be injected; can set multiple names separated by comma
    # label_selector:                                               # When managedcluster_name is not specified, a ManagedCluster with matching label_selector is selected for ManagedCluster chaos scenario injection
    instance_count: 1                                               # Number of managedcluster to perform action/select that match the label selector
    runs: 1                                                         # Number of times to inject each scenario under actions (will perform on same ManagedCluster each time)
    timeout: 420                                                    # Duration to wait for completion of ManagedCluster scenario injection
                                                                    # For OCM to detect a ManagedCluster as unavailable, have to wait 5*leaseDurationSeconds
                                                                    # (default leaseDurationSeconds = 60 sec)
  - actions:
    - stop_start_klusterlet_scenario
    managedcluster_name: cluster1
    # label_selector:
    instance_count: 1
    runs: 1
    timeout: 60

% kind get clusters
cluster1
hub

% kubectx
kind-cluster1
kind-hub   <=======

% kubectl get managedclusters
NAME       HUB ACCEPTED   MANAGED CLUSTER URLS                  JOINED   AVAILABLE   AGE
cluster1   true           https://cluster1-control-plane:6443   True     True        4h59m

% python3 run_kraken.py --config config/config_kubernetes.yaml
:0: UserWarning: You do not have a working installation of the service_identity module: 'No module named 'service_identity''.  Please install it from <https://pypi.python.org/pypi/service_identity> and make sure all of its dependencies are satisfied.  Without the service_identity module, Twisted can perform only rudimentary TLS client hostname verification.  Many valid certificate/hostname mappings may be rejected.
 _              _
| | ___ __ __ _| | _____ _ __
| |/ / '__/ _` | |/ / _ \ '_ \
|   <| | | (_| |   <  __/ | | |
|_|\_\_|  \__,_|_|\_\___|_| |_|

2022-12-06 16:11:32,274 [INFO] Starting kraken
2022-12-06 16:11:32,282 [INFO] Initializing client to talk to the Kubernetes cluster
2022-12-06 16:11:32,430 [INFO] Publishing kraken status at http://<IP_ADDRESS>:8081
2022-12-06 16:11:32,430 [INFO] Publishing kraken status at http://<IP_ADDRESS>:8081
2022-12-06 16:11:32,433 [INFO] Starting http server at http://<IP_ADDRESS>:8081
2022-12-06 16:11:32,433 [INFO] Fetching cluster info
2022-12-06 16:11:32,440 [INFO] Cluster version CRD not detected, skipping
2022-12-06 16:11:32,441 [INFO] Server URL: https://<IP_ADDRESS>:56860
2022-12-06 16:11:32,441 [INFO] Generated a uuid for the run: c05cdfc3-f97d-4f3c-a4a3-a7c8ec89494c
2022-12-06 16:11:32,441 [INFO] Daemon mode not enabled, will run through 1 iterations
2022-12-06 16:11:32,441 [INFO] Executing scenarios for iteration 0
2022-12-06 16:11:32,441 [INFO] connection set up
<IP_ADDRESS> - - [06/Dec/2022 16:11:32] "GET / HTTP/1.1" 200 -
2022-12-06 16:11:32,442 [INFO] response RUN
2022-12-06 16:11:32,442 [INFO] Running managedcluster scenarios
2022-12-06 16:11:32,448 [INFO] Starting managedcluster_stop_start_scenario injection
2022-12-06 16:11:32,448 [INFO] Starting managedcluster_stop_scenario injection
2022-12-06 16:11:32,478 [INFO] managedcluster_stop_scenario has been successfully injected!
2022-12-06 16:11:32,478 [INFO] Waiting for the specified timeout: 420
2022-12-06 16:12:50,748 [INFO] Status of managedcluster cluster1: Unavailable
2022-12-06 16:12:50,749 [INFO] Deleting manifestworks
2022-12-06 16:13:00,759 [INFO] Starting managedcluster_start_scenario injection
2022-12-06 16:13:00,788 [INFO] managedcluster_start_scenario has been successfully injected!
2022-12-06 16:13:00,788 [INFO] Waiting for the specified timeout: 420
2022-12-06 16:13:06,815 [INFO] Status of managedcluster cluster1: Available
2022-12-06 16:13:06,815 [INFO] Deleting manifestworks
2022-12-06 16:13:06,822 [INFO] managedcluster_stop_start_scenario has been successfully injected!
2022-12-06 16:13:06,822 [INFO] Waiting for the specified duration: 60
2022-12-06 16:16:07,193 [INFO] Starting stop_start_klusterlet_scenario injection
2022-12-06 16:16:07,193 [INFO] Starting stop_klusterlet_scenario injection
2022-12-06 16:16:07,216 [INFO] stop_klusterlet_scenario has been successfully injected!
2022-12-06 16:16:37,217 [INFO] Deleting manifestworks
2022-12-06 16:16:47,226 [INFO] Starting start_klusterlet_scenario injection
2022-12-06 16:16:47,247 [INFO] start_klusterlet_scenario has been successfully injected!
2022-12-06 16:17:17,249 [INFO] Deleting manifestworks
2022-12-06 16:17:17,261 [INFO] stop_start_klusterlet_scenario has been successfully injected!
2022-12-06 16:17:17,261 [INFO] Waiting for the specified duration: 60
2022-12-06 16:18:06,854 [INFO] Successfully finished running Kraken. UUID for the run: c05cdfc3-f97d-4f3c-a4a3-a7c8ec89494c. Report generated at /Users/jlema/krkn/kraken.report. Exiting

Done @chaitanyaenr


Add support for youtube list view

Add client side endpoint for fetching list of youtube video's via the youtube API.
Secret already added in secrets.

Merged. Need to verify the secrets and client send controller for the next phase on the dashboard widget.


Error on swagger with Typescript 5.5.2 installed by typia setup

Our latest deployment pipeline failed due to the fact that typia setup ( yarn typia setup --manager yarn --project tsconfig.json) installed<EMAIL_ADDRESS>The execution of yarn nestia swagger _app_  ends with:
Analyzing reflections
  - controllers: #16
  - paths: #59
  - routes: #59
Analyzing source codes
Error: target is a string value; tsconfig JSON must be parsed with parseJsonSourceFileConfigFileContent or getParsedCommandLineOfConfigFile before passing to createProgram
    at Proxy.originalCreateProgram (/wsl2development/uze/uze-platform/node_modules/typescript/lib/typescript.js:124700:25)
    at Object.createProgram (/wsl2development/uze/uze-platform/node_modules/typescript/lib/typescript.js:579:28)
    at Object.createProgram (/wsl2development/uze/uze-platform/node_modules/typescript/lib/typescript.js:124691:41)
    at NestiaSdkApplication.<anonymous> (/wsl2development/uze/uze-platform/node_modules/@nestia/sdk/src/NestiaSdkApplication.ts:156:36)
    at Generator.next (<anonymous>)
    at fulfilled (/wsl2development/uze/uze-platform/node_modules/@nestia/sdk/lib/NestiaSdkApplication.js:5:58)

I've tried to update typescript to 5.5.4 with the same results. I rolled back to 5.4.2 and its working again. Im not sure if this is a Nestia or a Typia problem but i decided to post it here because it might only indirectly a Typia issue

We always use latest, but i see my mistake, we should use nestia setup instead of typia setup in our pipeline. Nestia installs 5.4.2 and Typia 5.5.2


Diurnal cycle climatology

This PR is to add diurnal cycle phase map:

TRMM 0.25 degree data is pre-processed for monthly diurnal cycle and added.
*Default regions include: "CONUS", "20S20N", "W_Pacific", "Amazon","global","50S50N"
*example results: https://portal.nersc.gov/cfs/e3sm/zhang40/tests/diurnal_cycle_climo/viewer/diurnal_cycle/index.html
updated results with normalize_test_amp = False: https://portal.nersc.gov/cfs/e3sm/zhang40/tests/diurnal_cycle_climo_no_scale_test/viewer/

To post-process model output files to create monthly diurnal cycle that E3SM Diags could read, use the new NCO sub-monthly capability. Example scripts on Cori:
#!/bin/bash

source /global/cfs/cdirs/e3sm/software/anaconda_envs/load_latest_e3sm_unified.sh

# Low-res Cori simulations
drc_in=/global/cfs/cdirs/e3smpub/E3SM_simulations/20180215.DECKv1b_H1.ne30_oEC.edison/archive/atm/hist

drc_out=/global/cfs/cdirs/e3sm/zhang40/nco_scripts/results/diurnal_climo/native
drc_rgr=/global/cfs/cdirs/e3sm/zhang40/nco_scripts/results/diurnal_climo/rgr
caseid=20180215.DECKv1b_H1.ne30_oEC.edison.cam.h4

#cd ${drc_in};ls ${caseid}*.nc | ncclimo --var=PRECT --clm_md=hfc --caseid=$caseid --ypf=1 --yr_srt=2000 --yr_end=2004 --drc_out=${drc_out} -O $drc_rgr --map=/global/homes/z/zender/data/maps/map_ne30np4_to_cmip6_180x360_aave.20181001.nc
cd ${drc_in};ls ${caseid}*200*.nc | ncclimo --clm_md=hfc --caseid=$caseid --ypf=1 --yr_srt=2000 --yr_end=2009 --drc_out=${drc_out} -O $drc_rgr --map=/global/homes/z/zender/data/maps/map_ne30np4_to_cmip6_180x360_aave.20181001.nc

Notes here for improvements:
Use same scale for test and ref data, and to make a parameter so that user can choose to use different scales for test and ref.
The CONUS domain range needs to be revised.

A new parameter, normalize_test_amp (default setting is True) has been added so that an option to plot test and ref on different scales are allowed. The CONUS range is extended.
Note, this PR is to support climo diurnal cycle files, time series support will be in a future PR. Test will be added once we figure out a way to host test data.

I should have included the updated figures: updated results with normalize_test_amp = False: https://portal.nersc.gov/cfs/e3sm/zhang40/tests/diurnal_cycle_climo_no_scale_test/viewer/

I should have included the updated figures: updated results with normalize_test_amp = False: https://portal.nersc.gov/cfs/e3sm/zhang40/tests/diurnal_cycle_climo_no_scale_test/viewer/
The default output that normalizes test data amplitude: https://portal.nersc.gov/cfs/e3sm/zhang40/tests/diurnal_cycle_climo_scale_test/viewer/

@golaz Hi Chris, I'm about merging the diurnal cycle PR which supports climatology diurnal cycle files. It would be helpful if you can visual check the results from above link to see if any changes are desired.
@forsyth2 I should have addressed most of the review comments and added comments on code blocks to add clarity. Let me know if they look okay.

@chengzhuzhang Thanks for the updated plots. Those look better.
Did you push your latest changes to GitHub? The last commit I see is from before I reviewed.

@forsyth2 It's now pushed in...


add want_bytes

Originally reported by: Thomas Waldmann (Bitbucket: thomaswaldmann, GitHub: thomaswaldmann)

Sometimes it is useful for APIs to accept unicode as well as bytes (e.g. if it usually is just some simply ascii text or hex number and you don't want to force your users to use b'...' for giving a value, but also accept '...').
See there why I needed it and for an implementation:
https://github.com/ThomasWaldmann/itsdangerous/blob/modernize/itsdangerous.py#L42
Feel free to change the name if you have a better idea.

Bitbucket: https://bitbucket.org/gutworth/six/issue/27

Is ensure_binary() good enough to close this issue or not?


Glue config not working

👓 What did you see?
.feature:

setdefs.js

Both user and workspace settings:

File structure:

The autocomplete is not working. I saw that, by default, the .js files are not inside the glue property, so I change it, but it still doesn't work. When I run cucumber the test pass successfully.
✅ What did you expect to see?
The autocomplete working.
📦 Which tool/library version are you using?
package.json
{
  "name": "cucumber-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "cucumber-js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@cucumber/cucumber": "^8.9.0"
  },
  "dependencies": {
    "chai": "^4.3.7"
  }
}

Extension is 1.6.0
VS is 1.73.1
🔬 How could we reproduce it?
Steps to reproduce the behavior:

Create a feature with a step
Create a step to that feature with .js
Add to the setting:

   "cucumber.glue": [
         "features/**/*.js"
   ]

Support for JavaScript was released in 1.7.0


Supporting glob-style operations

OK this one has bugged me for long enough that I decided to try and actually implement a fix.
This PR adds support for glob-module-style pattern matching, so you should be able to do --ignore **/*ignore*.txt or --ignore **/ignore and it should just work.
I added a test that I think checks the edge-cases here, but welcome to have thoughts on how to improve.

closes https://github.com/executablebooks/sphinx-autobuild/issues/112
closes https://github.com/executablebooks/sphinx-autobuild/issues/117
might be a fix for https://github.com/executablebooks/sphinx-autobuild/issues/120

maybe @asmeurer or @consideRatio would be willing to give a look? I think both of you have gotten bitten by this one before as well :-)
Note that I also ran pre-commit autoupdate and ran it on all our files, because I think an outdated version was causing pre-commit to fail.

I'm not currently using autosummary, so it's not easy for me to test that use-case.
However, I have had an issue with sphinx-autobuild ignores in general, which may or may not be related. In the SymPy docs, we have a lot of plots that are generated by the matplotlib directive. Sometimes, sphinx-autobuild gets stuck in a loop thinking that every single one of these files is updated, like
[sphinx-autobuild] Detected change: /Users/aaronmeurer/Documents/Python/sympy/sympy/doc/_build/plot_directive/modules/plotting-35.pdf

This happens even if I do --ignore=_build/ (I tested it and it happens in this branch too).
If you want to reproduce this in the SymPy docs, you can install the dependencies from doc/requirements.txt then, from the doc/ directory run
make livehtml # Runs sphinx-autobuild

then in another terminal
make clean

(the docs take a couple of minutes to build from scratch)
The infinite loop honestly wouldn't be so bad, except the webserver gets blocked by it, meaning if you try to click a link in the live webpage, it tries to wait for the build to finish before it loads the page, and thus never loads. Making the webserver not block like this in general would be helpful.
Happy to open a separate issue for this if you'd like.

This sort of looping also happens whenever I checkout a new branch, one at a time for every file in the source repo that was changed. So I guess there are three problems here:

sphinx-autobuild is not ignoring _build/, even when told to do so with --ignore
The webserver blocks while a build is happening. This is particularly annoying when this looping happens, but it's also annoying in general. Could it be made asynchronous?
 It ought to be able to detect changes in a batch to avoid unnecessary duplicate rebuilds.

Hmm - I'm not sure why your build folder isn't being ignored ..indeed I would have expected this PR to fix it. I can try to take another look and see if i may have missed something.
For the async and batch blocking stuff unfortunately i have no idea how that stuff works, and also have no real knowledge of this codebase other than what I learned while making this PR, so i think we should just open an issue to track it over time. (We also need to find a way to make a release, this repository got moved into executable books without transferring the ability to upload to pypi)

Another quick thought: can you double check that the path to your _build folder is correct when you pass the --ignore argument? I didn't see --ignore in your makefile. What was the specific call that you use when using --ignore?
I opened two issues to track two of your requests above:

#124
#125

For the "_build" folder issue, I couldn't replicate it locally in a toy site I put together. I made a little Sphinx site with this structure:

docs
build
And a noxfile.py to run sphinx-autobuild

I then set conf.py in docs to generate a folder with 10 files in it in build/tmp at build time.
I then used this invocation of sphinx-autobuild:
sphinx-autobuild -b html docs/ build/html --ignore build --port 0

and it correctly ignored the build folder. So I'm not sure why you aren't getting that behavior.

Yes, I never actually committed --ignore to the sympy Makefile because it never seemed to actually work. If you're testing this, add --ignore=_build/ (and anyway, shouldn't the build folder be ignored automatically?). Here's the full line I am using to test this in the SymPy Makefile
sphinx-autobuild --open-browser --ignore=_build/ --watch .. --host $(LIVEHOST) --port $(LIVEPORT) -b html $(ALLSPHINXOPTS) $(SOURCEDIR) $(BUILDDIR)/html

I spent a while trying to get the sympy docs to build this morning but could never figure it out. I got a string of error messages that I had to resolve by installing certain system libraries etc, but the last one I ran into I didn't know how to debug AttributeError: module 'unicodedata2' has no attribute 'ucnhash_CAPI' and I ran out of time to work on this.
I am not sure why this doesn't work for you, but I think this PR at least solves some of the edge-cases that have been mentioned. I can remove the "closes" for your glob issue in case that is not resolved, but I'd suggest that we merge this one as an iterative improvement so that we can get it in before I go on paternity leave in a few days.

I've seen that error before. I'll have to see if I can remember what causes it.

And anyway, feel free to just open an issue for my problem. It's already a problem for me and this PR didn't seem to make it worse. Although I admit I didn't actually test the actual globbing nature of this PR.

What are the chances this getting approved? This is much needed!  I can try to get back to this at some point but am on paternity leave for the time being

By the way, the repeated rebuilding issue doesn't just happen on SymPy. It seems to happen on any repo that uses autodoc with lots of Python files. Here's a simpler repo where I've also seen the issue that you can test https://github.com/quansight-labs/ndindex.

@choldgraf Thank you for the PR. It would be fantastic if it could be merged.

Hey all - I don't have time to work on this. I recommend somebody else picks up this PR. Feel free to fork and open a new one, or just take over this one

Thank you for the answer.
I already picked it up and created a new PR which is rebased here https://github.com/sphinx-doc/sphinx-autobuild/pull/171
You can close this PR.

Done! For anybody else that comes across this PR, please check out its successor here:

https://github.com/sphinx-doc/sphinx-autobuild/pull/171

Thanks @jhgoebbert !


Where can I find the raw picture?

Did the raw picutres have been put into the dataset folder? Thx

Due to a license issue, we do not include the stimulus images in the dataset. Instead, you can request the images via https://forms.gle/ujvA34948Xg49jdn9.


foxy-items-form adding sub_modify and sub_restart at the item (not the cart) level

Related to #11, possibly https://github.com/Foxy/foxy-elements/pull/12/commits/d2fd62c901306e293cd4e7dfa865c87f86bd99a6
Currently, when working with subscription items, every item gets the sub_modify=replace and sub_restart=auto options added, prefixed with the digit. These params need to be passed to /cart just once, without any prefixes. So currently if you inspect the POST in the dev tools, you'll see something like this:
10:name: Fancy Widget
10:code: 1003
10:price: 27.94
10:image: https://foo.tld/bar.png
10:quantity: 1
10:sub_frequency: 30d
10:sub_modify: replace
10:sub_restart: auto
// ...
11:sub_modify: replace
11:sub_restart: auto
// etc, these params added per item
cart: checkout

That should look like this:
sub_modify: replace
sub_restart: auto
cart: checkout

Is it correct to say that the same is valid for sub_frequency, sub_startdate, sub_enddate, sub_token?


[feat] Legacy JS support (fixes #12)

Brief
A feature-complete zero-configuration (JS output) legacy support of SvelteKit, by being compatible with the (potential) output of @vitejs/plugin-legacy.
Additionally, it applies legacy configurations and fixes some JS compatibility issues of kit.svelte.dev with legacy browser, so the official website wouldn't be totally unsupported by legacy browsers.
Online Demo
Please test in your legacy browsers and share the experience/bugs you have.
Def: legacy browser := any browser that doesn't fully supports the ES modules. (according to the vite legacy plugin)
closes #12
(Initiated by and) an alternative to #2745
A more robust alternative to PR #5417, thought I didn't cancel here the introduced changes by this external PR.
Probably closes the old sveltejs/svelte#3388.
Manual Testing
On the simple demo & the kit.svelte.dev website that will be described later:

IE11 - Works well (except minor styling issues in the simple demo, but bigger ones in kit.svelte.dev)
Chrome 15 (yes, that's old) - Works assuming you're willing to give up on the following Svelte features:

svelte/animation - The flip animation requires that the style will have the property transformOrigin, which isn't suppported (see caniuseit. We can try to patch Svelte to use webkit- prefix, but is it worth it?)
svelte/transition - For some reason I have encountered some "DOM Exception type 12" errors, don't know (and not sure I want to know) how to fix it except not using transitions at all.
svelte/motion - Before chrome 24, there is no support both for window.requestanimationframe() and window.performance.now(). There are polyfills for both of them, but the latter use the precision of Date.now() that is awful (for example the counter component on the simple demo uses svelte/motion.spring, and because the precision it's jumping crazy). For reference, the two polyfills are available here and here (the second one is actually ponyfill, meaning you'll need to overwrite window.performance to be the value of the exported object there by yourself, see the manual there).

I would like that other people here test the following demos on their machines and share their experience.
Demo
Notice: both of the demos are using postcss-preset-env for a limited support of CSS variables in legacy browsers.
Simple
A simple demo is available at this repository, together with an online preview in cloudflare pages (the same demo in the brief section). This demo also include some "patched css" to avoid forcing using CSS variables, when there isn't support, and additionally define and uses some polyfills.
After cloning, to run the demo, execute pnpm install && pnpm build && pnpm preview, and you can see the results both in modern browsers and in legacy ones (I used IE11 for testing).
Automated Testing: It is automatically get tested using Selenium both in IE11(legacy) and Edge(modern), simulating a real E2E usage of the demo.
If you like the demo, you can star it 🌟
kit.svelte.dev

Pull/Clone/degit this PR.
Navigate in this repo to sites\kit.svelte.dev.
Run pnpm install && pnpm build && pnpm preview.
Check the result in any legacy/modern browser you'd like.

Automated Testing: It is automatically get tested using Playwright and a custom HTTP middleware that replaces the <script> tags to simulate legacy browsers behavior (with similarity to Vite plugin-legacy internal tests). Didn't want to introduce here a new&heavy Selenium dependency thought, so I left this heavy tool for the simple demo.
Issue of Vite
Update: Only one open issue about web workers legacy support, that we can leave with right now in my opinion, together with the rest of the Vite community:
vitejs/vite#10383 - Web workers aren't being built well for legacy. This means for example that on legacy browsers that supports web workers (e.g. IE11), the search bar on kit.svelte.dev won't work, see the discussion on the review here https://github.com/sveltejs/kit/pull/6265#discussion_r989304840 for more details.
Inner Details
This PR enable legacy support without any new configuration of SvelteKit, it is just make things to be compatible with vite legacy plugin if the user uses it in vite.config.js.
The way it works is by looking at the generated Vite manifest, and check the following legacy assets that the vite legacy plugin might output:

legacy entry (the legacy version of start.js)
legacy polyfills
modern polyfills

Then, on server side HTML rendering, it inject the correct HTML script tags, according to what that is available, in a similar fashion to the injection of the vite legacy plugin. (Vite legacy plugin inject the scripts to the output HTML, but the output HTML is getting wiped up by SvelteKit, so this PR (hopefully) injects the correct script tags in all use cases).
This PR also solves some minor legacy compatibility issues in SvelteKit client-side routing, that cannot be fixed by polyfills.
Notice: No legacy support for dev mode. It was a decision of the creators of the vite legacy plugin.
As you can see in the demos, I suggest for end users to use the following Vite configuration with this additional polyfills, that are needed to make SvelteKit to work:
import { sveltekit } from '@sveltejs/kit/vite';
import legacy from '@vitejs/plugin-legacy';

/** @type {import('vite').UserConfig} */
const config = {
	plugins: [
		sveltekit(),
		legacy({
			// For complete list of available options, see:
			// https://www.npmjs.com/package/@vitejs/plugin-legacy#Options
			targets: ['ie >= 11'],
			additionalLegacyPolyfills: [
				'custom-event-polyfill',
				'core-js/modules/es.promise.js',
				'whatwg-fetch',
				// 'global-this' should be used so 'regenerator-runtime' wouldn't do CSP issues
				'core-js/proposals/global-this',
				'regenerator-runtime/runtime',
				'unorm',
				'path-composedpath-polyfill',
				'proxy-polyfill/proxy.min.js'
			]
		}),
	]
};

export default config;

and add also the following code at the head of script of the root +layout.svelte file:
// Loading first polyfills that are shared between for legacy&modern browsers.
import 'abortcontroller-polyfill';

Important: You'll need to have this additional legacy polyfills installed as dev dependancies, as Vite plugin-legacy compiles them internally with an import directive. In this case, these additional legacy polyfills can be installed via (assuming you use pnpm):
pnpm install -D custom-event-polyfill whatwg-fetch regenerator-runtime unorm path-composedpath-polyfill proxy-polyfill abortcontroller-polyfill
As said above, I also fixed some JS issues on legacy browsers, to make kit.svelte.dev to work (no work where done to fix legacy CSS issues). You might want to accept this PR without the changes to this site, but I don't recommend to.
Personal Experience and Opinions
It was a long journey to start understanding 3rd parties logic and bugs.
I think legacy support is crucial for many users (including me), especially by the extreme definition of legacy I gave above (not fully supporting ES modules), even if you decide to "give up on IE11". The lack of legacy support in SvelteKit made me actually use only Sapper (until now!), since I love Svelte.
The reason I believe this feature is more important than other ones (such as i18n), is because the latter can be implemented by the end user or 3rd library, but legacy is (almost) impossible.
I'm very glad that the code change that is needed for legacy support is relatively minor, since the vite legacy plugin do all the hard work, although it was hard to figure out how to connect to its output correctly, and to fix 3rd party issue.
Automatic Notes (Yey! All done!)
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[X] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[X] This message body should clearly illustrate what problems it solves.
[X] Ideally, include a test that fails without this PR but passes with it.

Tests

[X] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[X] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

Update:
There is an issue on legacy that not happen on modern browsers: while navigating(actually, when preloading) from one page to the other, Vite doesn't load the CSS files needed for the page.
I have filled an issue on Vite: vitejs/vite#9902.

I would really want this merged 😃 I need it to make my SvelteKit app to run on IE1
Despite what Microsoft declares as a defunct browser and unsupported there are surprisingly yet many instances in 2022 where IE11 is the only browser available or is a requirement that your app to function on it.

I would really want this merged 😃 I need it to make my SvelteKit app to run on IE11
Despite what Microsoft declares as a defunct browser and unsupported there are surprisingly yet many instances in 2022 where IE11 is the only browser available or is a requirement that your app to function on it.

Thank you!
Not only this, but also earlier version of Edge (< 18, before chromium integration) are also problematic, as well as some other legacy browsers that are newer than IE11.
I just viewed IE11 as "the worst case scenario"(and the only one available in my machine), but I would like anyone else who have other legacy browser (i.e. not fully supporting ESModules browsers, e.g. old IPhones/Mac) to give it a try!

I would really want this merged 😃 I need it to make my SvelteKit app to run on IE11
Despite what Microsoft declares as a defunct browser and unsupported there are surprisingly yet many instances in 2022 where IE11 is the only browser available or is a requirement that your app to function on it.

Thank you! Not only this, but also earlier version of Edge (< 18, before chromium integration) are also problematic, as well as some other legacy browsers that are newer than IE11. I just viewed IE11 as "the worst case scenario"(and the only one available in my machine), but I would like anyone else who have other legacy browser (i.e. not fully supporting ESModules browsers, e.g. old IPhones/Mac) to give it a try!

Yes, basically IE11 is the lowest denominator, there are problems with other legacy browsers also, but if it works on IE11 it will work on anything 😄

I would love to see this merged! We've been holding off building apps for older but still relatively new Tizen OS devices (mostly smart televisions, digital signage, narrowcasting displays) because they have very unreliable native browsers (random forks of chromium with limited browser API support).

This would be a great PR to see merged, removing a big blocker to using Svelte Kit in contexts where legacy browser support is still necessary.

@dummdidumm is there any reason why you put it as draft? As far for me, this is a complete PR.
Yes of course I'm waiting for review, but this is not draft.

This was just a precaution during launch day to not accidentally merge anything

Thank you for making this PR; I'll freely confess that I haven't paid much attention to it since it wasn't considered as part of 1.0. I didn't realise you were constantly keeping it up to date, and I want to acknowledge that there's a lot of work involved.
That said, I'm rather uncomfortable with the complexity this adds. It's a bunch of extra stuff to maintain (and a whole new test app, which will slow down every test run) for the sake of browsers that people just don't use any more. It feels to me like we'd be better off trying to make this work outside the framework core, like we do with @sveltejs/amp. Though I'd probably go so far as to say that in cases where it's truly necessary to support ancient browsers, progressive enhancement provides a more realistic approach.

While I agree that progressive enhancement is usually the better way to go, sometimes you need an app to work completely on older browsers. For example, I worked on a website for a federal program here in Canada. The website needed to support IE11 as well as be accessible. I decided to use Sapper with a couple polyfills, which worked very well. I needed interactivity in the website, to display 3 different components depending on inputs (see the page in question). I know the example isn't very complex, but it didn't work in Sapper without polyfills and (back then), it didn't work at all in SvelteKit.
Maybe that wasn't the best way to do it, but I also had the requirement that the website be a static one (I used the sapper export functionality). I haven't tested SvelteKit on IE11 recently (I did back then, but it was very early), but I seem to remember that it didn't degrade very gracefully. If parts of it worked it would've been okay, but I think it was completely broken, even with the polyfills I added. It worked fine for Sapper though.
Now, I was much less experienced back then (the difference ~2 years can make), and I probably did some stuff the wrong way, which probably didn't help. But I still feel like it should be possible to preserve functionality in legacy browsers. Though I do agree that it should probably be a separate module (maybe @sveltejs/legacy).

Thank you for making this PR; I'll freely confess that I haven't paid much attention to it since it wasn't considered as part of 1.0. I didn't realise you were constantly keeping it up to date, and I want to acknowledge that there's a lot of work involved.
That said, I'm rather uncomfortable with the complexity this adds. It's a bunch of extra stuff to maintain (and a whole new test app, which will slow down every test run) for the sake of browsers that people just don't use any more. It feels to me like we'd be better off trying to make this work outside the framework core, like we do with @sveltejs/amp.

What I realized in my "legacy research" is that legacy support is not that hard to make, especially not within the Vite ecosystem that is very much legacy friendly. If you did into the PR implementation, the code changes that are needed for supporting legacy browsers is very minimal comparing to the gain, since the Vite legacy plugin do the whole work, and the SvelteKit job is basically just to:

Load the correct entry file for modern/legacy, together with the polyfill file. Thought Vite legacy plugin is doing this, it is needed since SvelteKit ignores Vite HTML output.
Don't interfere with legacy support, i.e. don't program in the JS code something that will be very terrible for legacy browsers support by Vite and external polyfills.
An optional requirement I didn't implement, is to avoid the request from the end user to load many polyfills (OK, maybe except some very classical ones, e.g. for the support of custom-event and fetch), and instead just implement them internally(i.e. ponyfills). This is however very questionable.

As I said before, the problem is not only about very old browsers like IE11, even other, much more modern(relatively) ones suffer from this issue.
For the tests maintaining issues, I did two levels of tests:

Basic ones that "simulates" older browsers behaviour in modern ones, they are basically a slightly improved ripoff of the Vite legacy plugin automated tests, and are part of this PR.
Real selenium automated test on the "SvelteKit legacy demo" repo, for both IE11 and the modern Edge browsers.

I think that maintaing the test suite in (1) is painless, and is very good (the Vite maintainers are satisfied while they having only this one).
The test suite in (2) is only optional, and should be maintained in a seperate repository, for the reasons you specified. If you want to go more seriously/optimized on legacy support, there are two things you can do: (I spell them out for completeness, even though I'm impressed by you that you're not going in my direction)
a. To have an external repo that run SvelteKit tests, in the same repo/fashion of https://github.com/vitejs/vite-ecosystem-ci .
b. To ask for support of BrowserStack, they are good on real browsers automation, and they are happy to give their full suit for open source software (e.g. they support the caniuseit tool).
I and also many others think it's crucial that a giant thing like SvelteKit will support legacy browsers, or at least will have a limited support that will make the dream of people who wish to implement legacy support possible (i.e. "experimental support"?).
Bottom line: I don't have to have a full legacy support, I just don't want to fight SvelteKit and try to hack it, just give me (and the rest of the people who requested it) some hope.

Though I'd probably go so far as to say that in cases where it's truly necessary to support ancient browsers, progressive enhancement provides a more realistic approach.

This just make a huge disadvantage for people to use Svelte in big scales, and turns the favor for all the major alternative that do support the legacy browsers. I know Svelte metra is not about industry adoption, but the problem I said is wider.

Neither the standard example app nor your legacy example app work on Windows PCs used by some German administration (Firefox 93, but also Chrome and Edge don't work).
As far as I can see it: The click event does not fire.
There is no error in the console, which makes debugging really complicated :)
Any ideas what I could try to find the problem?

Neither the standard example app nor your legacy example app work on Windows PCs used by some German administration (Firefox 93, but also Chrome and Edge don't work).
As far as I can see it: The click event does not fire. There is no error in the console, which makes debugging really complicated :)
Any ideas what I could try to find the problem?

It must be bacuase of some weird reason...
The simple demo is manually tested by me with:

IE11
chrome 15
latest firefox

And additionally, it is being tested automatically by Selenium on IE11 and the latest Edge, see the latest Github action excecution .
In addition, Firefox 93 is way so modern, so the regular Svelte demo should work out of the box.
The only thing I can think about is some network restriction, e.g. from loading JS files, or even worse - manipulating their content in a middleware.
Can you check the network console of the browser to see that the scripts with the "nomodule" attribute in the generated HTML, are being loaded on the legacy browsers?
Can you also give a more careful reproduction? Can you test all the following:

Regular SvelteKit demo by local build and preview
My simple legacy demo by local build and preview
The cloudflare online link to my online hosted legacy demo.

You probably understand this - but on the first two, don't run pnpm dev, but rather run pnpm build && pnpm preview.

Thank you, I will see what I can do. Since I have no direct access to the PCs that have the problem, I am very limited
So don't wait for my feedback.
:-(

@Rich-Harris It not only "for the sake of browsers that people just don't use any more". There's a big segment of embedded browsers, for example in Connected TVs, where browser updates are rare or non-existent. Svelte would be a good fit for that segment considering performance, since those devices often are inherently slow, but many of them require legacy support.

@Rich-Harris It not only "for the sake of browsers that people just don't use any more". There's a big segment of embedded browsers, for example in Connected TVs, where browser updates are rare or non-existent. Svelte would be a good fit for that segment considering performance, since those devices often are inherently slow, but many of them require legacy support.

Not only this - but SvelteKit isn't nice to "not so legacy browsers" as IE11 as well!
I think it's give also some confident to know which browsers should work with SvelteKit, no matter if you like legacy or not. I believe that asking for BrowserStack support is a valid option, as I mentioned (that they like to support open source repos manual/auto test).

Update: I used eslint-plugin-compat (which uses caniuseit) to verify that all the JS code of the kit package is using an expected JS features, to check that the user legacy builds won't break when modifying SvelteKit code.

@Tal500

some network restriction, e.g. from loading JS files

This is the problem. They think that Svelte is including some web-tracking-scripts, so they block them. 0 javascript is delivered to the browser.

@Rich-Harris It not only "for the sake of browsers that people just don't use any more". There's a big segment of embedded browsers, for example in Connected TVs, where browser updates are rare or non-existent. Svelte would be a good fit for that segment considering performance, since those devices often are inherently slow, but many of them require legacy support.

I can 100% echo this. Sveltekit is a perfect fit for Smart TVs thanks to code performance. But legacy browser support is a key feature since the their Web Engines are very old and never updated.  Was surprised Sveltekit don't support it.

Hello,
I would like to add an opinion here that I hope could accelerate a decision regarding this PR.
At RadioFrance (radiofrance.fr) we have been using Svelte and Sveltekit (and before that, Sapper) for over two years now. And we are sincerely happy to promote this framework on a site with 8 million visits every month, 7 different radios that broadcast live and podcasts continuously, and thousands of new press articles each month.
This week, and after a lot of hard work, we moved to v1.x.x (thanks @Rich-Harris for the migration post which helped us a lot, and congratulations again for all the work done by all the maintainers); however we noticed today that our site is no longer available for many users with old devices.
Maybe by habit it is easy to consider that legacy is always < 1% but for us, less than 1% is still tens of thousands of people who write to us to report that they haven’t been able to listen to their favorite show since Monday.
Plus, being a public service, it is quite important to us that our site remains as accessible as possible, even if it means supporting ancient browsers.

The progressive enhancement option would be possible, but would require months of refactoring, as the webapp was not built with this in mind from the start.
We think that we are left with (and it’s a shame, today) having to take such a drastic decision as a rollback (even if we hope it’s only temporary) since @vite/legacy-plugin doesn’t work with SvelteKit.
Maybe there is another solution that we missed, if so we would love to hear from you 🙏

@Rich-Harris It not only "for the sake of browsers that people just don't use any more". There's a big segment of embedded browsers, for example in Connected TVs, where browser updates are rare or non-existent. Svelte would be a good fit for that segment considering performance, since those devices often are inherently slow, but many of them require legacy support.

I can 100% echo this. Sveltekit is a perfect fit for Smart TVs thanks to code performance. But legacy browser support is a key feature since the their Web Engines are very old and never updated. Was surprised Sveltekit don't support it.

Hello!
First, in my own project, I'm using this fork of thus PR, which gives a full legacy compatibility, as far as I know, see the details in the head description.
Secondly, I would wish that "less than 1%" will be accurate! Here are the details:

The total amount of browsers usages that doesn't support fully ESModules is way more than 1%, acoording to "caniuseit" at least.
SvelteKit uses many advanced standard features that are not supported only in "mid-legacy" browsers, say Firefox < 84 if I remember correctly. The current moto of the development as far as I can tell, following the automated Playwrite E2E testing, is supporting only the latest browsers available.

@Rich-Harris It's a bunch of extra stuff to maintain [...] for the sake of browsers that people just don't use any more

@7antra but for us, less than 1% is still tens of thousands of people

I'm not fully aware of all the technical constraints that justify this is not merged yet, but "tens of thousands of people" is a great deal of users.
I love that the Svelte way is to help enforce web accessibility as much as possible (especially when you're terrible at it, like me), and I believe that old browsers compatibility is accessibility ("old" to some extent of course, which could be debated).
I strongly believe that the compatibility of @vitejs/plugin-legacy should be included, in one way or another. Whether it's inside or outside the framework core, I do not have the knowledge or skills to have a strong opinion about it.

I've created tvkit a proxy server that transforms a vite dev server into something that can be processed by older browsers.
Start your dev server normally and then run:
npx tvkit@latest serve

Now you're able to access your SvelteKit website in an older browsers on http://localhost:3000/
If your building using the adapter-static, tvkit also has a build command to process the generated static build:
npx tvkit@latest build ./build --out ./dist

On 07/02/23 18:13, Andreas Dahlström @.***> wrote:

I've created tvkit <https://github.com/bfanger/tvkit> a proxy server
that transforms a vite dev server into something that can be
processed by older browsers.

Start your dev server normally and then run:

npx<EMAIL_ADDRESS>serve

Now you're able to access your SvelteKit website in an older
browsers on http://localhost:3000/ <http://localhost:3000/>

If your building using the adapter-static
<https://github.com/sveltejs/kit/tree/master/packages/adapter-static>, tvkit also has a build command to process the generated static build:

npx<EMAIL_ADDRESS>build ./build --out ./dist

If I have a site on Vercel, how do I use TVKit?

Try too keep this GitHub thread about the @vitejs/legacy PR.
For questions and issues about TVKit use the https://github.com/bfanger/tvkit/issues page.

Why hasn't it been merged yet?

See https://github.com/sveltejs/kit/pull/6265#issuecomment-1373821833, hope that it will be merged (or will be implemented in a different way).

Any updates on this PR? It is really frustrating to not be able to support legacy browsers.

Any new on this?

Intro
Hi,
I am part of the frontend dev team of the radiofrance website, we have tried in the past to support this issue being merged (through various likes, messages or approvals) without success, so I would like to make a more detailed case. Apologies in advance for the wall of text.
Context
We had last week to rollback our migration to SvelteKit 2.x, probably due to this issue https://github.com/sveltejs/kit/issues/11658 - the OP is another team member at radiofrance
While those two issued are unrelated technically, this has renewed internal discussion about backwards compatibility, which leads back to this issue, which came to light for us when migrating to SK 1.x, where we had to drop support for some OS/browsers (more below)
Stakes
At radiofrance we have been early adopters of Svelte (Sapper days), and some of the key factors (apart from the sweet DX) was the light bundle size and general lightness of the app; because of those
Environmental responsibility
We are a heavy traffic website

~25m monthly visits
~9m monthly unique users
so lightness is of importance.

The key point here though is that another main lever of environmental impact is when devices become incompatible with what the users want to access, they have to replace them thus creating electronic waste.
Losing backwards compatibility for a small fraction of users may translate in non-trivial devices becoming unusable to access our service.
Social responsibility
As a Public Service Broadcaster, it is our responsibility and duty to provide access to our information and other programmes to the highest proportion of the population as possible. Remote areas with low bandwidth, people who can't afford to upgrade their devices frequently or use second hand devices, people who are environmentally conscious and limit as much as they can their consumption of devices, non-tech-fluent people who tend to stick with the basic computer/browser they know how to use, etc.
Challenges
On our side we are also confronted with legacy compatibility in general, not only directly about this issue but also any other design/tech choices we make. This is always an on-going conversation, of having to find the right balance of legacy compatibility vs effort needed to do so vs impact on code length or available features: we are aware of the tradeoffs that these questions require.
Impact
For us, this has meant losing support for Safari 13.x when migrating to SK 1.x. We have strongly considered rolling back, judging that a 2019 browser should still be supported on our end. Due to Apple's policy, some devices can't upgrade higher to a certain MacOS version, which in turn means a maximum Safari version. Hence the device impact mentioned above.
We were hoping for this fix to be merged so has to regain compatibility before fully using our users.
Moving forward
We reckon that those are issues that the Svelte team cares about as well, for the same or other reasons. We are regularly checking out if this issue (or related) moves forward, e.g. this https://github.com/sveltejs/kit/issues/11643 that for different reasons is supporting the current PR to be merged.
Quoting part of this reply https://github.com/sveltejs/kit/issues/11643#issuecomment-1892527997 from @antony

The effort of supporting abandoned / non-compliant browsers is monumental, and too time consuming to maintain for this small team. We simply can't afford to pay the ongoing price for somebody else's failures.

As said above, we understand that maintaining full compatibility with legacy OS/browser is a sizeable task, but in this matter we do feel that the trade-off is favorable, with @vitejs/plugin-legacy doing the brunt of the work, maintaining SvelteKit's compatibility with it is good return in effort invested for the gains in compatibility.
Our case is surely not the only one, but already with our footprint I hope you'll look favorably into moving this PR forward, and help us and others keep our environmental footprint in check. :)
Thanks for reading, cheers!

Intro
Hi,
I am part of the frontend dev team of the radiofrance website, we have tried in the past to support this issue being merged (through various likes, messages or approvals) without success, so I would like to make a more detailed case. Apologies in advance for the wall of text.
Context
We had last week to rollback our migration to SvelteKit 2.x, probably due to this issue #11658 - the OP is another team member at radiofrance
While those two issues are unrelated technically, this has renewed internal discussion about backwards compatibility, which leads back to this issue, which came to light for us when migrating to SK 1.x, where we had to drop support for some OS/browsers (more below)
Stakes
At radiofrance we have been early adopters of Svelte (Sapper days), and some of the key factors (apart from the sweet DX) was the light bundle size and general lightness of the app; because of the following:
Environmental responsibility
We are a heavy traffic website
* ~25m monthly visits

* ~9m monthly unique users

so lightness is of importance.
The key point here though is that another main lever of environmental impact is when devices become incompatible with what the users want to access, they have to replace them thus creating electronic waste. Losing backwards compatibility for a small fraction of our users may translate to a non-trivial number of devices becoming unusable to access our service.
Social responsibility
As a Public Service Broadcaster, it is our responsibility and duty to provide access to our information and other programmes to the highest proportion of the population as possible. Remote areas with low bandwidth, people who can't afford to upgrade their devices frequently or use second hand devices, people who are environmentally conscious and limit as much as they can their consumption of devices, non-tech-fluent people who tend to stick with the basic computer/browser they know how to use, etc.
Challenges
On our side we are also confronted with legacy compatibility in general, not only directly about this issue but also any other design/tech choices we make. This is always an on-going conversation, of having to find the right balance of legacy compatibility vs effort needed to do so vs impact on code length or available features: we are aware of the tradeoffs that these questions require.
Impact
For us, this open issue has meant losing support for Safari 13.x when migrating to SK 1.x. We have strongly considered rolling back, judging that a 2019 browser should still be supported on our end. Due to Apple's policy, some devices can't upgrade higher to a certain MacOS version, which in turn means a maximum Safari version. Hence the device impact mentioned above.
We were hoping for this fix to be merged so as to regain compatibility before fully losing our users.
Moving forward
We reckon that those are issues that the Svelte team cares about as well, for the same or other reasons. We are regularly checking out if this issue (or related) moves forward, e.g. this #11643 that for different reasons is supporting the current PR to be merged.
Quoting part of this reply #11643 (comment) from @antony

The effort of supporting abandoned / non-compliant browsers is monumental, and too time consuming to maintain for this small team. We simply can't afford to pay the ongoing price for somebody else's failures.

As said above, we understand that maintaining full compatibility with legacy OS/browser is a sizeable task, but in this matter we do feel that the trade-off is favorable, with @vitejs/plugin-legacy doing the brunt of the work, maintaining SvelteKit's compatibility with it is good return in effort invested for the gains in compatibility.
Our case is surely not the only one, but already with our footprint I hope you'll look favorably into moving this PR forward, and help us and others keep our environmental footprint in check. :)
Thanks for reading, cheers!

Hi @nostrorom, thanks for the interest!
I am sadly don't have time to keep upgrading this PR and resolve conflicts, but I would like any support from everyone possible.
Specifically, until Svelte team will eventually support this issue(exactly like Vue that have a support for legacy), I can take and merge PR to my own proposed Github fork (that this PR is linked to).
I think have basically created a year ago good automatic system for testing and coverage for this - both by basic unit tests quering only via HTTP and full e2e test on IE11 and old Chromes on Selenium(thanks BrowserStack for their full support to free open-source softwares).
I might add you as a team member in my Github fork if needed.

Hi @Tal500 !
Thanks for the offer; feel free to add me as a team member. I don't have much availability in the very near future to work on this, but I will definitely want to help tackle the matter if the Svelte team don't :(

I needed to shim a polyfill for Array.prototype.at on older iPad devices. Unfortunately I ran into the problem this PR aims to solve in regards to using @vitejs/plugin-legacy with the latest version of Svelte.
For now I have added the following to my app.html which is working well:
<script src="https://polyfill.io/v3/polyfill.min.js?features=Array.prototype.at"></script>

Just wanted to comment here in case https://polyfill.io/ helps anyone else out until this gets merged.


Make docker-push "latest" suffix configurable & support arbitrary docker tag versions

We don't use latest normally, so we needed to make this script more flexible, supporting a configurable latest tag version, as well as allowing the caller to specify all additional tag versions that should be pushed.
All behavior is backwards compatible.

Hi @matthewadams! Thanks for the contribution and I think it's a great one! I'll be reviewing this now.

ok now?

@matthewadams This looks awesome! Thanks for the perseverance and follow-through! I'm going to merge this into v7.21.0-branch which will be released fairly shortly.

👍🏼


Improve distinct type id calculation for type-inclusions and intersection types

Purpose
$title and add lang.typedesc:typeIds function.
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/30490
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/30779
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Closing in favor of https://github.com/ballerina-platform/ballerina-lang/pull/30896


[BUG]: unexpected value for parameter

Using the biomodel955, I created a new config and set beta to change over time with values as seen in screenshot.

However, when charting the parameter after simulation, the initial value of beta is way up for some reason.

Hey @pascaleproulx Just wondering what would be expected in for the initial value here?  It looks like when defining the value over time it started at timestep 1 meaning the timestep 0 was never defined.  The simulation looks like it uses numbers between 0-1 if it is not defined for each sample (value is different for each sample).

I tried with timestep 0 being defined and got a better looking initial value (it was the set value 0 for every sample):


failed to initialize project: failed to get the import path

Using Ubuntu 19.04 and the provided install method I am not able to init a project:
failed to initialize project: failed to get the import path

refer: https://github.com/izumin5210/grapi/issues/264


Highlight the current module in the TOC

Assign a special CSS class to the current module link in the table of contents and set it to a different style (bold? different color? different background? border? different font?) so it's clear which module we're in even on narrow screens.

Fixed by f2c7daf14e47a02d75215455362ebfed0ffb52be


Bug: forge fmt removes source code comments

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
No response
What command(s) is the bug in?
forge fmt
Operating System
macOS (Intel)
Describe the bug
running forge fmt removes comments entirely
it also reformats comments from using // to /** */
This is unexpected behavior
here is a test suite where forge fmt is ran against and you can see the changes
https://github.com/sambacha/solidity-testfiles/commit/182237f83a273a6de64ab11ea439564ec9feb276#diff-ea3c7fe83d00c3d353f5fa2fd6c2e163f71d75d6e44e33afa79a2234d855cd32

Here is one such change:
https://github.com/sambacha/solidity-testfiles/commit/182237f83a273a6de64ab11ea439564ec9feb276#diff-064c0e0eb043c19d49b171bfb6a5fc67426256f9e4ddcccb02c08b1e642169ffL1-R7
removal of a line comment:
https://github.com/sambacha/solidity-testfiles/commit/182237f83a273a6de64ab11ea439564ec9feb276#diff-956c284bbecd008b02f47f00bd0c2f47eb8d8bbf0b87a046df9246120913447bL3
here is a change of pure external to external pure  (style should be documented)
https://github.com/sambacha/solidity-testfiles/commit/182237f83a273a6de64ab11ea439564ec9feb276#diff-2a09eecf6d2344e2259ad929171184fa9f162414b48730326e0d134e1933e7d0L2-R2

This is not a bug as such, it's a missing/incomplete feature. fmt is not ready yet. Please see the tracking issues:

https://github.com/foundry-rs/foundry/issues/781
https://github.com/foundry-rs/foundry/issues/780

Additionally it seems that some nodes are missing for comments but this is known: https://github.com/foundry-rs/foundry/pull/1833#pullrequestreview-1003482148


Change internal include  to use double quote

Hello
I changed the include <> to include "" for internal include that is in the same folder.
It fix the requirement to add an include directory in the makefile when we embed the file in an other object.
Thanks

Can you rebase dev branch?

The commit typo can be decoupled from this pull request, and it would be more straightforward for code reviewing.

Thanks @bmalrat for the PR; however, most includes are good because both mimalloc-override.h and mimalloc-new-delete.h are meant for users of mimalloc to include (and should use < >).  I fixed the one  in mimalloc-types.h as that should indeed use double quotes. Thanks again!


Add Github CI Runner

Run tests after every push

I've added a simple test run on push, might need more late

good enough for now, let's add new issues if we want something else