Explicitly state that default files don't appear in the file browser or git history

The added wording comes from https://github.blog/changelog/2019-02-21-organization-wide-community-health-files/

Why:
This tripped up my team - the documentation as written seemed to imply that the files would be visible in the GitHub file browser. It was only after adding the default files that we learned this wasn't the case. Hopefully having this explicitly stated will help others avoid this misunderstanding.
Closes: #26242

What's being changed (if available, include any code snippets, screenshots, or gifs):
Adding an explicit declaration that default health files aren't viewable in individual repositories' file browser or git history to the "Managing Community Health Files...." documentation

Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

@spicycode

@GuySartorelli 👋 Thanks for adding this to our Docs!


auto-deploy when installing an app is blocked by warnings in the preflight checks

there are two proposals for handling this:
1-  just ignore any warning level checks and only block on errors
2- allow a flag to bypass, for example --ignore-preflight-warnings

IMHO, warnings should not block unattended installations. I was surprised when we blocked web installations for warnings, but understand the decision since it's just a confirmation away. But with unattended, the same is not true. I'm against adding a flag to bypass since then we teach users to just bypass warnings anyway, and at some point there will be a real warning they shouldn't have ignored. If we had a way to ignore specific warnings, that would be different, but that's a lot more complicated of a solution that isn't worth it.
@marccampbell pointed out that our docs to explicitly mention passing:

Once this has completed, visiting http://localhost:8800 will show the configured application dashboard, assuming all required config items were set and any included preflight checks passed.

But looking at the docs, in colloquial English, warnings are passed. In GitLab, for example, CI jobs show as “passed with warnings”. If I were running a CLI, the exit code for a command would be “success” even if there were warnings.

In our case, i.e automated deployment on AKS via azure marketplace, I want the deployment to fail if the preflight checks failed or if they are any warnings, but if the deployment failed due to warning / failures, I should be able to fetch those warnings/failures so that I can accordingly display the same to end user to fix the same

BTW, instead of returning the warnings after the installation has failed , there should an additional option exposed, --check-warnings or --dry-run which will not deploy but it will check if there are any warnings or errors if yes, it should return a json which contain the status (failure/success) mentioned against each check.
The installation flow should be like this,
Step1:  with "--deploy=false" it should just setup KotsAdmin but should not actually trigger the first deployment , for backward compatibility "--deploy" will be set to true
kubectl kots install aif-core/oneboxinstaller --license-file akstest.yaml --shared-password Admin@123! --namespace aifabric --port-forward=false --deploy=false
Step2: with "--deploy=false --dry-run=true" , preflight checks has to be validated and a json has to be returned mentioning the status (Success/fail) of each preflight check and and an aggregated status check
kubectl kots install aif-core/oneboxinstaller --license-file akstest.yaml --shared-password Admin@123! --namespace aifabric --port-forward=false --deploy=false --dry-run=true
response: {
"status": "Failed",
{
"Ram Requirements" : "Pass",
"Total CPU cores should be at-least 16": "Failed",
"Disk Requirements": "Pass"
}
}
Step 3: with "--deploy=true" , the first deployment should kick in
kubectl kots install aif-core/oneboxinstaller --license-file akstest.yaml --shared-password Admin@123! --namespace aifabric --port-forward=false --deploy=true

We should consider allowing the same capability on errors as well (e.g., --ignore-preflight-errors).


A member of type RequestPageExtension with name 'RequestPageExtension' is already defined in ReportExtension (AL0155)

1. Describe the bug
I have three apps, M1, M2, and M3 with dependencies as follows

M2 -> M1
M3 -> M1
M3 -> M2

Report and extensions:

M1 defines Report1 with a RequestPage
M2 extends Report1 and also the RequestPage
M3 extends Report1 and also the RequestPage

In this setup I get the following following problem reported on the RequestPage of the report extention in M3:
A member of type RequestPageExtension with name 'RequestPageExtension' is already defined in ReportExtension 'Report1Extension' by the extension 'M2 by Statical (<IP_ADDRESS>)'.AL(AL0155)

Additionally, I get a compilation error when the request page in M3 references a control in the requestpage of M2:
The control 'Label2' is not found in the target 'RequestOptionsPage'

2. To Reproduce
Steps to reproduce the behavior:

Unzip repro.zip
Open workspace file with VS Code
Compile

3. Expected behavior
I would expect no errors reported and compilation to succeed. For normal pages, it is possible to extend and extended page, so it seems to be a bug that the same cannot be done for request pages.
4. Actual behavior
Compilation error:
Microsoft (R) AL Compiler version <IP_ADDRESS>380
Copyright (C) Microsoft Corporation. All rights reserved

Compilation started for project 'M2' containing '1' files at '9:49:28.72'.

c:\tmp\repro\M2\M2-code.al(8,22): error AL0270: The control 'Label1' is not found in the target 'RequestOptionsPage'

Compilation ended at '9:49:28.104'.

Error: The package could not be created.

Also compilation error:
The control 'Label2' is not found in the target 'RequestOptionsPage'

5. Versions:

AL Language: v7.1.441584
Visual Studio Code:
Version: 1.55.2 (system setup)
Business Central: 18
List of Visual Studio Code extensions that you have installed:

AZ AL Dev Tools/AL Code Outline
Marddown PDF
vscode-position
waldo's CRS AL Language Extension

Final Checklist
Please remember to do the following:

[x] Search the issue repository to ensure you are reporting a new issue

[x] Reproduce the issue after disabling all extensions except the AL Language extension

[x] Simplify your code around the issue to better isolate the problem

This is a known bug with workspaces that's on our radar, which addresses the duplicate request page issue.
I suspect the same underlying workspace issue to also be at fault for the label issue. If I compile the apps separately, publish, and download symbols it works.

The issue is fixed and the bugfix will be available with the next minor.


Transfer executor

Move pyiron_contrib.executors and associated tests into pyiron_workflow. This is anyhow only a temporary measure until pympipool can be used directly (right now it seems to be causing tests to hang)

ModuleNotFoundError: No module named 'pyiron_contrib'

I just missed updating the path in the init file

======================================================================
ERROR: test_workflow (unittest.loader._FailedTest.test_workflow)
----------------------------------------------------------------------
ImportError: Failed to import test module: test_workflow
Traceback (most recent call last):
  File "/usr/share/miniconda3/envs/my-env/lib/python3.11/unittest/loader.py", line 419, in _find_test_path
    module = self._get_module_from_name(name)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/miniconda3/envs/my-env/lib/python3.11/unittest/loader.py", line 362, in _get_module_from_name
    __import__(name)
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/tests/unit/test_workflow.py", line 5, in <module>
    from pyiron_workflow.channels import NotData
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/pyiron_workflow/__init__.py", line 1, in <module>
    from pyiron_workflow.workflow import Workflow
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/pyiron_workflow/workflow.py", line 11, in <module>
    from pyiron_workflow.composite import Composite
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/pyiron_workflow/composite.py", line 14, in <module>
    from pyiron_workflow.interfaces import Creator, Wrappers
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/pyiron_workflow/interfaces.py", line 13, in <module>
    from pyiron_workflow.executors import CloudpickleProcessPoolExecutor as Executor
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/pyiron_workflow/executors/__init__.py", line 5, in <module>
    from pyiron_workflow.executors.cloudpickleprocesspool import (
  File "/home/runner/work/pyiron_workflow/pyiron_workflow/pyiron_workflow/executors/cloudpickleprocesspool.py", line 5, in <module>
    import cloudpickle
  File "/usr/share/miniconda3/envs/my-env/lib/python3.11/site-packages/cloudpickle/__init__.py", line 3, in <module>
    from cloudpickle.cloudpickle import *
  File "/usr/share/miniconda3/envs/my-env/lib/python3.11/site-packages/cloudpickle/cloudpickle.py", line 145, in <module>
    _cell_set_template_code = _make_cell_set_template_code()
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/miniconda3/envs/my-env/lib/python3.11/site-packages/cloudpickle/cloudpickle.py", line 126, in _make_cell_set_template_code
    return types.CodeType(
           ^^^^^^^^^^^^^^^
TypeError: code expected at least 16 arguments, got 15

This error gets repeated a few times. On first glance it looks like an incompatibility between cloudpickle and types versions

This error gets repeated a few times. On first glance it looks like an incompatibility between cloudpickle and types versions

Ah yeah, that's because I screwed up pinning the "most recent" version of cloudpickle: It's 2.2.1. I have no idea where I pulled 0.4.0 from. Ooohhh, I see, I just accidentally read off the outdated architecture-specifc version instead of noarch


Remove old docs that are now in sphinx

Point people to the RTD site from the main README.

Current coverage is 58.36% (diff: 100%)

Merging #425 into master will not change coverage

@@             master       #425   diff @@
==========================================
  Files            26         26
  Lines           711        711
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            415        415
  Misses          296        296
  Partials          0          0

Powered by Codecov. Last update 39a90f2...850f59b


test_cifar10 fails in CI master build

Description
test_cifar10 fails in CI master build.
 Also, how could I look for last time this test failed?
Tested it on CPU..
Python environment:
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Test runs:
(env) :/incubator-mxnet# MXNET_TEST_COUNT=30000 nosetests --logging-level=DEBUG --verbose -s  tests/python/train/test_dtype.py:test_cifar10
test_dtype.test_cifar10 ... [00:15:56] src/io/iter_image_recordio_2.cc:170: ImageRecordIOParser2: data/cifar/train.rec, use 1 threads for decoding..
[00:15:56] src/io/iter_image_recordio_2.cc:228: Load mean image from data/cifar/mean.bin
[00:15:56] src/io/iter_image_recordio_2.cc:246: Load mean image from data/cifar/mean.bin completed
[00:15:57] src/io/iter_image_recordio_2.cc:170: ImageRecordIOParser2: data/cifar/test.rec, use 1 threads for decoding..
[00:15:57] src/io/iter_image_recordio_2.cc:228: Load mean image from data/cifar/mean.bin
[00:15:57] src/io/iter_image_recordio_2.cc:246: Load mean image from data/cifar/mean.bin completed
/incubator-mxnet/incubator-mxnet/python/mxnet/model.py:1004: DeprecationWarning: mxnet.model.FeedForward has been deprecated. Please use mxnet.mod.Module instead.
optimizer=optimizer, initializer=initializer, **kwargs)
/incubator-mxnet/incubator-mxnet/python/mxnet/model.py:591: DeprecationWarning: Calling initializer with init(str, NDArray) has been deprecated.please use init(mx.init.InitDesc(...), NDArray) instead.
self.initializer(k, v)
Start training with [cpu(0)]
Epoch[0] Batch [50]	Speed: 2353.29 samples/sec	accuracy=0.169531
Epoch[0] Batch [100]	Speed: 3413.73 samples/sec	accuracy=0.270000
Epoch[0] Batch [150]	Speed: 3929.30 samples/sec	accuracy=0.323906
Epoch[0] Batch [200]	Speed: 5827.04 samples/sec	accuracy=0.347656
Epoch[0] Batch [250]	Speed: 8605.79 samples/sec	accuracy=0.368750
Epoch[0] Batch [300]	Speed: 7193.14 samples/sec	accuracy=0.380000
Epoch[0] Batch [350]	Speed: 9871.67 samples/sec	accuracy=0.400156
Epoch[0] Resetting Data Iterator
Epoch[0] Time cost=10.354
Epoch[0] Validation-accuracy=0.409019
final accuracy = 0.409019
Epoch[0] Batch [50]	Speed: 6709.95 samples/sec	accuracy=0.183517
Epoch[0] Batch [100]	Speed: 2762.11 samples/sec	accuracy=0.256094
Epoch[0] Batch [150]	Speed: 2599.24 samples/sec	accuracy=0.316719
Epoch[0] Batch [200]	Speed: 4019.71 samples/sec	accuracy=0.352344
Epoch[0] Batch [250]	Speed: 4482.44 samples/sec	accuracy=0.362969
Epoch[0] Batch [300]	Speed: 2311.78 samples/sec	accuracy=0.378125
^[Epoch[0] Batch [350]	Speed: 6287.10 samples/sec	accuracy=0.394375
Epoch[0] Train-accuracy=0.390039
Epoch[0] Time cost=13.991
Epoch[0] Validation-accuracy=0.415843
final accuracy = 0.415565
Start training with [cpu(0)]
Epoch[0] Batch [50]	Speed: 4131.70 samples/sec	accuracy=0.158438
Epoch[0] Batch [100]	Speed: 3603.14 samples/sec	accuracy=0.255469
Epoch[0] Batch [150]	Speed: 3880.94 samples/sec	accuracy=0.309688
Epoch[0] Batch [200]	Speed: 3466.17 samples/sec	accuracy=0.346719
Epoch[0] Batch [250]	Speed: 1907.85 samples/sec	accuracy=0.365625
Epoch[0] Batch [300]	Speed: 13460.59 samples/sec	accuracy=0.377344
Epoch[0] Batch [350]	Speed: 3278.69 samples/sec	accuracy=0.395781
Epoch[0] Resetting Data Iterator
Epoch[0] Time cost=13.526
Epoch[0] Validation-accuracy=0.420985
final accuracy = 0.420985
Epoch[0] Batch [50]	Speed: 2937.12 samples/sec	accuracy=0.171722
Epoch[0] Batch [100]	Speed: 3230.27 samples/sec	accuracy=0.271875
Epoch[0] Batch [150]	Speed: 7009.35 samples/sec	accuracy=0.319844
Epoch[0] Batch [200]	Speed: 7694.27 samples/sec	accuracy=0.345938
Epoch[0] Batch [250]	Speed: 5635.28 samples/sec	accuracy=0.365000
Epoch[0] Batch [300]	Speed: 3673.31 samples/sec	accuracy=0.387344
Epoch[0] Batch [350]	Speed: 1934.83 samples/sec	accuracy=0.399219
Epoch[0] Train-accuracy=0.394531
Epoch[0] Time cost=13.540
Epoch[0] Validation-accuracy=0.419600
final accuracy = 0.418570
[00:17:02] src/io/iter_image_recordio_2.cc:170: ImageRecordIOParser2: data/cifar/train.rec, use 1 threads for decoding..
[00:17:03] src/io/iter_image_recordio_2.cc:170: ImageRecordIOParser2: data/cifar/test.rec, use 1 threads for decoding..
Start training with [cpu(0)]
Epoch[0] Batch [50]	Speed: 6886.05 samples/sec	accuracy=0.157344
Epoch[0] Batch [100]	Speed: 2879.89 samples/sec	accuracy=0.242969
Epoch[0] Batch [150]	Speed: 2601.20 samples/sec	accuracy=0.255469
Epoch[0] Batch [200]	Speed: 3848.15 samples/sec	accuracy=0.284531
Epoch[0] Batch [250]	Speed: 5992.76 samples/sec	accuracy=0.293438
Epoch[0] Batch [300]	Speed: 3103.23 samples/sec	accuracy=0.314219
Epoch[0] Batch [350]	Speed: 6909.95 samples/sec	accuracy=0.332344
Epoch[0] Resetting Data Iterator
Epoch[0] Time cost=13.161
Epoch[0] Validation-accuracy=0.352848
final accuracy = 0.352848
Epoch[0] Batch [50]	Speed: 7453.44 samples/sec	accuracy=0.161612
Epoch[0] Batch [100]	Speed: 4445.21 samples/sec	accuracy=0.235469
Epoch[0] Batch [150]	Speed: 3297.28 samples/sec	accuracy=0.266719
Epoch[0] Batch [200]	Speed: 6435.73 samples/sec	accuracy=0.292500
Epoch[0] Batch [250]	Speed: 9299.93 samples/sec	accuracy=0.310625
Epoch[0] Batch [300]	Speed: 2478.55 samples/sec	accuracy=0.323594
Epoch[0] Batch [350]	Speed: 4273.77 samples/sec	accuracy=0.324844
Epoch[0] Train-accuracy=0.309180
Epoch[0] Time cost=10.967
Epoch[0] Validation-accuracy=0.358683
final accuracy = 0.358474
ok

Ran 1 test in 96.476s
OK

@indhub @marcoabreu  : Do you have any further suggestions to reproduce this issue?

I can't find a record of this test failing in the last weeks, sorry (the data is currently not publicly accessible). I think we can close this for now, considering we got no additional data, it's from the old CI system, from October 2017 and your run succeeded 30000 times.
@indhub wdyt?

Given it hasn't failed on the current CI in the last weeks, I agree we can close this.


Link to the formula itself in the formula page

Currently a formula page only has a link to the actual software's homepage, but there's no link to the formula itself (e.g. https://github.com/Homebrew/homebrew-core/blob/master/Formula/formula-foo.rb).
It would be nice to provide this link as well so users could inspect the code of the formulas.

(commit 1b1f110 seems to be related, but I'm not sure)

Thanks, sounds like a good idea.
PS: Commit 1b1f11003e74f2eaa267e4fce2dcb4b3e7d6347e is not related to the front-end, it is related to symlinking during the import process.


AspNetCoreToOpenApi. No service for type 'NSwag.Generation.IOpenApiDocumentGenerator' with .NET 8

Hi!
We use NSwag to generate TypeScript clients for our internal controller-based APIs. This works well with NSwag.MSBuild 13.20.0 and .NET 7.
During the .NET 8 upgrade, I have made the following changes:

Upgrade to NSwag.MSBuild 14.0.0-preview012.
Change to use Net80 as runtime in nswag.json.
Change the NSwag invocation to use NSwagExe_Net80.

When I build, I get:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.InvalidOperationException: No service for type 'NSwag.Generation.IOpenApiDocumentGenerator' has been registered.
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiCommand.GenerateDocumentWithDocumentProviderAsync(IServiceProvider serviceProvider) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiCommand.cs:line 244
   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiCommand.GenerateDocumentAsync(IServiceProvider serviceProvider, String currentWorkingDirectory) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiCommand.cs:line 239
   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiGeneratorCommandEntryPoint.Process(String commandContent, String outputFile, String applicationName) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiGeneratorCommandEntryPoint.cs:line 29
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
   --- End of inner exception stack trace ---
   at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
   at System.Reflection.MethodBaseInvoker.InvokeWithFewArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at NSwag.AspNetCore.Launcher.Program.Main(String[] args) in /_/src/NSwag.AspNetCore.Launcher/Program.cs:line 132
System.InvalidOperationException: Swagger generation failed with non-zero exit code '1'.
   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiCommand.RunAsync(CommandLineProcessor processor, IConsoleHost host) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiCommand.cs:line 195
   at NSwag.Commands.NSwagDocumentBase.GenerateSwaggerDocumentAsync() in /_/src/NSwag.Commands/NSwagDocumentBase.cs:line 270
   at NSwag.Commands.NSwagDocument.ExecuteAsync() in /_/src/NSwag.Commands/NSwagDocument.cs:line 67
   at NSwag.Commands.Document.ExecuteDocumentCommand.ExecuteDocumentAsync(IConsoleHost host, String filePath) in /_/src/NSwag.Commands/Commands/Document/ExecuteDocumentCommand.cs:line 76
   at NSwag.Commands.Document.ExecuteDocumentCommand.RunAsync(CommandLineProcessor processor, IConsoleHost host) in /_/src/NSwag.Commands/Commands/Document/ExecuteDocumentCommand.cs:line 33
   at NConsole.CommandLineProcessor.ProcessSingleAsync(String[] args, Object input)
   at NConsole.CommandLineProcessor.ProcessAsync(String[] args, Object input)
   at NSwag.Commands.NSwagCommandProcessor.ProcessAsync(String[] args) in /_/src/NSwag.Commands/NSwagCommandProcessor.cs:line 62

I include NSwag.MSBuild like this:
    <PackageReference Include="NSwag.MSBuild" Version="14.0.0-preview012">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>

And I generate TS clients like this:
  <Target Name="NSwag" BeforeTargets="AfterBuild">
    <Exec ConsoleToMSBuild="true" ContinueOnError="true" Command="$(NSwagExe_Net80) run nswag.json /variables:Configuration=$(Configuration),TypescriptOutputPath=../../WebApp/app/generated">
      <Output TaskParameter="ExitCode" PropertyName="NSwagExitCode" />
      <Output TaskParameter="ConsoleOutput" PropertyName="NSwagOutput" />
    </Exec>

    <Message Text="$(NSwagOutput)" Condition="'$(NSwagExitCode)' == '0'" Importance="low" />
    <Error Text="$(NSwagOutput)" Condition="'$(NSwagExitCode)' != '0'" />
  </Target>

I have checked other issues such as https://github.com/RicoSuter/NSwag/issues/2387, but services.AddOpenApiDocument() doesn't compile (presumably because of how I reference NSwag.MSBuild), and it wasn't needed with .NET 7 anyway.

Did you find any solution @provegard ?

Since I don't want to generate an OpenAPI document (I already have that via another library), I added NSwag.Generation.AspNetCore version 14.0.0-preview012, then this:
    services.AddSingleton<IOpenApiDocumentGenerator, GeneratorWrapper>();
    ...

    private class GeneratorWrapper(IServiceProvider serviceProvider) : IOpenApiDocumentGenerator
    {
        public async Task<OpenApiDocument> GenerateAsync(string documentName)
        {
            var generator = new AspNetCoreOpenApiDocumentGenerator(new AspNetCoreOpenApiDocumentGeneratorSettings());
            return await generator.GenerateAsync(serviceProvider);
        }
    }

@RicoSuter
it is a breaking changes and problem

Hi! @RicoSuter
I have the same problems when updating from version .NET 7 to .NET 8 (NSwag.MSBuild and NSwag.AspNetCore 13.20.0 to 14.0.2). The same behavior is observed on .NET 7 if updating NSwag.MSBuild and NSwag.AspNetCore from version 13.20.0 to 14.0.2.

If I add the AddOpenApiDocument to the startup.cs file, then as a result of generating clients I get them for each controller, although in the aspNetCoreToOpenApi section in the apiGroupNames setting I have a group ["Sample"]. On version 13.20.0 everything worked without calling AddOpenApiDocument, and the generated clients corresponded to the "Sample" group. Attached is an example of the config
apinswag.txt
I understand that I can configure AddOpenApiDocument(settings => settings.ApiGroupNames = new[] { "Sample" }) in this way, but in the final product I have many such nswag configs, and many client groups. I need this to be configured at the config level, and not at the code level, as was the case in version 13.20.0.

If you use the ApiVersionNeutral attribute on the controller, generation fails with an error

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
12> ---> System.InvalidOperationException: The method 'get' on path '/api/application/InternalVersion' is registered multiple times.
12>   at NSwag.Generation.AspNetCore.AspNetCoreOpenApiDocumentGenerator.AddOperationDescriptionsToDocument(OpenApiDocument document, Type controllerType, List`1 operations, OpenApiDocumentGenerator swaggerGenerator, OpenApiSchemaResolver schemaResolver)
12>   at NSwag.Generation.AspNetCore.AspNetCoreOpenApiDocumentGenerator.GenerateApiGroups(OpenApiDocumentGenerator generator, OpenApiDocument document, IGrouping`2[] apiGroups, OpenApiSchemaResolver schemaResolver)
12>   at NSwag.Generation.AspNetCore.AspNetCoreOpenApiDocumentGenerator.GenerateAsync(ApiDescriptionGroupCollection apiDescriptionGroups)
12>   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiCommand.GenerateDocumentWithDocumentProviderAsync(IServiceProvider serviceProvider) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiCommand.cs:line 245
12>   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiCommand.GenerateDocumentAsync(IServiceProvider serviceProvider, String currentWorkingDirectory) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiCommand.cs:line 239
12>   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiGeneratorCommandEntryPoint.Process(String commandContent, String outputFile, String applicationName) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiGeneratorCommandEntryPoint.cs:line 29
12>   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
12>   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
12>   --- End of inner exception stack trace ---
12>   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
12>   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
12>   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
12>   at NSwag.AspNetCore.Launcher.Program.Main(String[] args) in /_/src/NSwag.AspNetCore.Launcher/Program.cs:line 132
12>System.InvalidOperationException: Swagger generation failed with non-zero exit code '1'.
12>   at NSwag.Commands.Generation.AspNetCore.AspNetCoreToOpenApiCommand.RunAsync(CommandLineProcessor processor, IConsoleHost host) in /_/src/NSwag.Commands/Commands/Generation/AspNetCore/AspNetCoreToOpenApiCommand.cs:line 195
12>   at NSwag.Commands.NSwagDocumentBase.GenerateSwaggerDocumentAsync() in /_/src/NSwag.Commands/NSwagDocumentBase.cs:line 270
12>   at NSwag.Commands.NSwagDocument.ExecuteAsync() in /_/src/NSwag.Commands/NSwagDocument.cs:line 67
12>   at NSwag.Commands.Document.ExecuteDocumentCommand.ExecuteDocumentAsync(IConsoleHost host, String filePath) in /_/src/NSwag.Commands/Commands/Document/ExecuteDocumentCommand.cs:line 76
12>   at NSwag.Commands.Document.ExecuteDocumentCommand.RunAsync(CommandLineProcessor processor, IConsoleHost host) in /_/src/NSwag.Commands/Commands/Document/ExecuteDocumentCommand.cs:line 33
12>   at NConsole.CommandLineProcessor.ProcessSingleAsync(String[] args, Object input)
12>   at NConsole.CommandLineProcessor.ProcessAsync(String[] args, Object input)
12>   at NSwag.Commands.NSwagCommandProcessor.ProcessAsync(String[] args) in /_/src/NSwag.Commands/NSwagCommandProcessor.cs:line 62

Controller example
namespace DotNet.WebApi.Controllers
{
    using System.Threading.Tasks;
    using Microsoft.AspNetCore.Mvc;

    [ApiController]
    [ApiVersionNeutral]
    [Route("api/application/[controller]")]
    public class InternalVersionController : ControllerBase
    {
        [HttpGet]
        public Task Get() => Task.CompletedTask;
    }
}

In the same project I have other controllers with
controllers.txt
With custom attributes and customized versioning.
Again, this worked on version 13.20.0.
I attach the generated swagger/index.html on version 13.20.0
Api_13.txt
How can I achieve the desired behavior without changing the code?

I have got the error:

<PackageReference Include="NSwag.MSBuild" Version="14.0.3" PrivateAssets="All" />

Since I don't want to generate an OpenAPI document (I already have that via another library), I added NSwag.Generation.AspNetCore version 14.0.0-preview012, then this:
    services.AddSingleton<IOpenApiDocumentGenerator, GeneratorWrapper>();
    ...

    private class GeneratorWrapper(IServiceProvider serviceProvider) : IOpenApiDocumentGenerator
    {
        public async Task<OpenApiDocument> GenerateAsync(string documentName)
        {
            var generator = new AspNetCoreOpenApiDocumentGenerator(new AspNetCoreOpenApiDocumentGeneratorSettings());
            return await generator.GenerateAsync(serviceProvider);
        }
    }

This solution worked for me. But because I used Swashbuckle.AspNetCore for the Minimal API, I only want to use NSwag to generate swagger.json. In the past (.NET 6), I only need to ref to NSwag.MSBuild, and run RunPostBuildEvent to generate swagger file. I don't know if this behaviour of the new version of NSwag.MSBuild is a bug.

Is this still not resolved? @RicoSuter

@priestlydevcounty the issue is open (see the status at the top) so you can expect it still to be... open.

@priestlydevcounty the issue is open (see the status at the top) so you can expect it still to be... open.

It was more of a question regarding any updates on the issue. It has been 6 months and several users have posted questions that have gone unanswered for a while. Looks like a serious breaking change to me.
Any message from the repo maintainer would be nice to know that he is aware of it and prioritising it accordingly. More worryingly, I read in another opened issue that this happens on every major version?

It was more of a question regarding any updates on the issue. It has been 6 months and several users have posted questions that have gone unanswered for a while. Looks like a serious breaking change to me.

The updates to this issue (and others) can be seen here in the GitHub issue thread, there's no secret society or forum that updates the status behind the scenes.

We also had this issue when we had this in our startup code:

changing that to:

solved the issue.


disable a test that leaks memory

This PR disables one sub-test that leaks memory.
The reason for the leak is that ExecutionNode::clone() called with the withProperties flag set, and the source and target plans are identical.
This will clone the plan's variables and register them in the same plan. Because variables are tracked by id, and the id will not change by cloning, this produces a leak.
The place that tracks the variables has no idea about what an ExecutionPlan is, so it cannot detect that source and target plan are identical.
There are two ways to go on from here:

adjust the test so that the target plan is not the same as the source plan
remove the test

I leave it up to you to decide what's best.

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr-linux/754/


fix: Fix UI selection issues

Fixes https://github.com/argoproj/argo/issues/3923
~I want to wait until #3805 is merged so I can write unit tests for this before merging~ Tests to come separately as part of the UI epic

Backported to 2.10 and 2.11


Question: Scale Calculation Accelerometer

"Accelerometer": {
"Name": "Accelerometer",
"Data": "[Vector3 { x: 2523, y: 1871, z: 4855 }, Vector3 { x: 1787, y: 1191, z: 4347 }, Vector3 { x: 807, y: -11, z: 2759 }, Vector3 { x:
"Unit": "m/s\u00b2",
"Matrix": "[[0.0, 0.0, 1.0, 0.0, -1.0, 0.0, 1.0, 0.0, 0.0]]",
"Scale": "418",
"Count": "231",
"Orientation": "ZyX",
"OrientationIn": "YxZ",
"OrientationOut": "ZXY"
},
Hi bit of a dumb question but I need clarification on the following point,
How does scale relate to the values in data ? ie how to get z in ms/^2 ?
I am using a gopro
Cheers

I'll need more details about what you're trying to do, but in general you take the value (eg 2523) an divide by scale (418) to get the unit (m/s2)

Sweet as, thats what I wanted to know cheers


Generated Timestmap column type - struggling to actually set a value

Hello - I have a timestamp column in postgres, and I am just having the hardest of time trying to understand why i can't actually use the Generated type definition with this while assigning a value. I do admit i am a bit of a typescript noob, so i hope i'm just missing something silly.
In the given scenario, I only need to update this specific date column (as a patch), so it's a pretty paired down version of Updateable.
Migration
  await db.schema
    .createTable('accounts').ifNotExists()
    .addColumn('id', 'integer', col => col.primaryKey().generatedByDefaultAsIdentity())
    .addColumn('login_last', 'timestamp')
    .execute();

Type Definitions
export type Generated<T> = T extends ColumnType<infer S, infer I, infer U>
  ? ColumnType<S, I | undefined, U>
  : ColumnType<T, T | undefined, T>;

export type Timestamp = ColumnType<Date, Date | string, Date | string>;

Account Table Types
export interface AccountTable {
  id: Generated<number>;
  login_last: Generated<Timestamp> | null;
};

export type AccountSelectable = Selectable<AccountTable>;
export type AccountInsertable = Insertable<AccountTable>;
export type AccountUpdateable = Updateable<AccountTable>;

Usage
const updateLastLogin = async ({
  id,
  login_last
}: Pick<AccountUpdateable, 'id' | 'login_last'>): Promise<void> => {

  const query = await db
    .updateTable('accounts')
    .set({ login_last})
    .where('id', '=', id)
    .executeTakeFirstOrThrow();
}

Call the query
updateLastLogin({
  id: 5,
  login_last: new Date()
});

I am now getting a Type 'Date' is missing the following properties from type 'Timestamp': __select__, __insert__, __update__ts(2739)

Or if trying with a string...
Call the query
updateLastLogin({
  id: 5,
  login_last: new Date().toISOString()
});

Type 'string' is not assignable to type 'Timestamp'.

Any thoughts here? I just really want to update a column in a database table with the current time stamp, but i am stumped here.

Just get rid of that weird extra Generated type and use the internal types. Also move | null inside the Column type helper instead of outside.

The weird Generated type came from kysely-codegen. Shall I raise the issue over there?

Don't since your example works perfectly
https://kyse.link/ICg6p


fix: switch to new waterpoints dataset AB#9112

the old waterpoints dataset is inaccessible so I switched to a new waterpoints dataset. Tested on Uganda, Zambia, Ethiopia, Kenya and Zimbabwe as per layer-metadata.json. It's slow on Uganda because it's loading 95k+ waterpoints, it's fine for the other countries.

@gulfaraz don't forget to put the item to done on devops after you've merged it (and checked that it works on test-vm).


AWS Lambda Semantic conventions spec does not provide mechanism for properly propagating context using SQS

Describe the bug
There exists OTel semantic conventions that define how to represent information related to spans representing the processing of SQS events in AWS Lambda.
As of now, there is no way to properly trace events that happens asynchronously in set of services that communicate using SQS messages. Every lambda invocation will create a new trace context (new trace id) for the SQS Event. If we have xray sampling enabled, that means that each hop in this set of services will have the probability of emitting a new trace or not emitting it. This creates a problem because you will not have the full path of events.
Customers could work around this limitation by using specific xray sampling rules for each hop in the chain of services, but this is not ideal and represents a mismatch with the behavior observed in synchronous http lambda invocations.
What did you expect to see?
We should provide alternatives for customers to use the parent context propagated in the message instead of creating a new trace context on every lambda invocation for an SQS Event.
Additional context

Lambda events can contain batches of messages https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html
Context is propagated in SQS in the message, not in the SQS Event, meaning that you can have multiple messages, each with a different trace context, in the same SQS Event. https://docs.aws.amazon.com/xray/latest/devguide/xray-services-sqs.html#xray-services-sqs-retrieving
Related issue: https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/5167

Right now we don't have a good solution that is originated from the spec. In fact, there is also this upstream issue https://github.com/open-telemetry/opentelemetry-specification/issues/2709


error occured when following the Compiling CUDA operators step.

Hello, when I try to run sh ./make.sh by following the Compiling CUDA operators it always show the error,
Traceback (most recent call last):
File "setup.py", line 69, in
ext_modules=get_extensions(),
File "setup.py", line 47, in get_extensions
raise NotImplementedError('Cuda is not availabel')
NotImplementedError: Cuda is not availabel
Any idea why this happens? Thanks!

Fixed it.

Hey @ruizhaoz, what was the fix? Having similar issues


Next doc

Pull Request Test Coverage Report for Build 3b7e3825be729ee39a848c35d1a1817bc32d63b6-PR-29
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.607%

Totals

Change from base Build 23018f87a1f1e2b539d99f85259eef553b312145:
0.0%

Covered Lines:
173

Relevant Lines:
182

💛  - Coveralls


[Syntax Review] Additional types of SampleGen code samples

Follow-up code review PR –

To evaluate the readiness of ☕ Java's GAPIC sample generator for use on cloud.google.com,
this provides a full set of samples which demonstrate the basic features of generated samples.

The .yaml sample config files for these samples can all be found here: .yaml sample configs

The first review Pull Request contained samples to show the basic structure as well as LRO samples.
This contains samples demonstrating those features and a few more use-cases for review –

Sample
Description

samplegen_basics
Shows basic structure/anatomy of Java samples

samplegen_no_config
Minimal sample example (zero configuration)

samplegen_no_response
API method which returns Empty

samplegen_paged
Paged API method (iterates over pages of results)

samplegen_resource_path
Sample which requires user's Google Project ID

samplegen_map_field_access
Access map value by key and enumerate keys/values

samplegen_read_and_write_files
Read binary file into bytes & write string to local file

samplegen_repeated_fields
Repeated request field & show loop/access by index

samplegen_write_bytes_to_file
Write bytes field in response to local file

samplegen_lro
Call long-running operation API endpoint

This Pull Request is focused on feedback collection & a similar PR is being sent to all languages.
Once you've completed your review and left comments, you may feel free to close the PR!

We will scope out making all of the requested changes and reach out to language team offline.

🙏 Thanks in advance for your review!

P.S. Nits welcome! We'd like to get these as polished as possible for usage on cloud.google.com.

Please feel free to note in comments whether something is:  🛑 Blocker -vs- 📌 Nit

🔍 Known Issues

Switch commented out placeholder variables => provide an overload with defaults
❓ Possible to add link to available types for enums?
When using resources, add a comment with try block explaining importance
❓ Exception handling – can we show something better than catch (Exception)?
Remove “DO NOT EDIT” / soften language so that developers are the target audience

📑 (internal)

Hello Java friends ☕
Follow-up PR, as promised!
@kurtisvg @averikitsch @lesv @chingor13 @googleapis/samplegen

Note: pulling this together required generating samples from a variety of different APIs, hence PR being sent to google-cloud-java rather than to the individual java-* repos


Example on Description: 5.2 ParameterizedSize should be SizeReference

File: BioImage Model Zoo Example notebook

yes, correct!

In 5.4, torchscript_weights_src is not defined.

Hey @FynnBe, instead of fixing all bugs in the existing example, can I just upload a notebook for packaging Cellpose models and a notebook for downloading PlantSeg models? I think these working real world notebooks might be more helpful and these are almost ready to be used as examples/tutorials.

sure, feel free to open a PR with a new example! 👍

"SizeReference instead of ParameterizeSize" and "torchscript_weights_src is not defined are fixed in the current notebook version


🐛 BUG: PDF doesn't render in Browser Rendering API

Which Cloudflare product(s) does this pertain to?
Workers Runtime
What version(s) of the tool(s) are you using?
3.60.3
What version of Node are you using?
No response
What operating system and version are you using?
Mac Sequoia 15.1
Describe the Bug
Using the Browser Rendering API to create a new page, go to the URL of a PDF, and then return a screenshot doesn't seem to be able to load the PDF itself, any suggestions or is this simply not one of those use cases the Browser Rendering API should be used for?
Observed behavior
PDF does not render. If it's not the blank screenshot attached, it's a timeout due to exceeding the 30s navigation timeout.
Expected behavior
PDF is rendered and it doesn't timeout rendering a PDF.
Steps to reproduce
const browser = await puppeteer.launch(env.BROWSER);
const page = await browser.newPage();

// This is a PDF I found on GitHub to test with here
await page.goto('https://usbtemp.s3.amazonaws.com/terms.pdf', {
  waitUntil: 'networkidle0',
});

const img = (await page.screenshot()) as Buffer;

// Here I upload to R2/handle, return a response, etc.

Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
No response

Unfortunately this is an upstream limitation in headless Chromium browsers, so there is not much we can do from our side :/
there are related issues like this that have workarounds that you could try.


Not-working

it does not work anymore

What does not work?
Login gives error #2  as expressed in the README, so the functions that depend on it do not work.
The rest runs fine for me.
What error does python main.py -u instagram give you?

Hey, thank you for your quick response.
It was working fine yesterday, but today it stopped working. I think USER-AGENT is broken. I'm running this on a ubuntu 18.04 server.
https://prnt.sc/4GmRS8o4GDnG

Hi,
I don't know why that happens. The sample command runs fine for me.
I got the USER-AGENT from https://stackoverflow.com/a/72553878/13829542 It's the only one that has worked for me.
What value does response have after response = get_json(URL_USER.format(username=username))?

response;
https://justpaste.it/cgyjq


Package discovery support for Laravel 5.5

Adds config in composer.json used by Laravel 5.5 to auto install the
service provider & alias/facade.

@DougSisk thanks for your collaboration.


Invalid ES5 emitted if class has reserved word as method name

Describe the bug
SWC emits a function let() {} which causes an error in strict mode stating 'let' is a reserved word (and thus cannot be used as a function name) if a class has a method called let. I would imagine this is also the case with other reserved words.
Input code
class Foo {
    let() {}
}

outputs:
function _classCallCheck(instance, Constructor) {
    if (!(instance instanceof Constructor)) {
        throw new TypeError("Cannot call a class as a function");
    }
}
function _defineProperties(target, props) {
    for(var i = 0; i < props.length; i++){
        var descriptor = props[i];
        descriptor.enumerable = descriptor.enumerable || false;
        descriptor.configurable = true;
        if ("value" in descriptor) descriptor.writable = true;
        Object.defineProperty(target, descriptor.key, descriptor);
    }
}
function _createClass(Constructor, protoProps, staticProps) {
    if (protoProps) _defineProperties(Constructor.prototype, protoProps);
    if (staticProps) _defineProperties(Constructor, staticProps);
    return Constructor;
}
var Foo = /*#__PURE__*/ function() {
    "use strict";
    function Foo() {
        _classCallCheck(this, Foo);
    }
    _createClass(Foo, [
        {
            key: "let",
            value: function let() {        // <--- INVALID JAVASCRIPT
            }
        }
    ]);
    return Foo;
}();
;

In firefox 89.0.1, this error is thrown:
Uncaught SyntaxError: let is a reserved identifier

Config
N/A - no config, just running straight swc:
$ swc test.js -o test.es5.js

Expected behavior
Either function let_ or something of the sort, or simply don't name those functions anything.
Version
The version of @swc/core: 1.2.61
Additional context
None.

This is a little bit complicated as let is only reserved in strict mode per mdn, @kdy1 what's your opinion? Maybe add an option for strict mode and one for module(which indicates the former)?

I don't think let being transpiled to _let is a big problem.
So... simply renaming with reserved-keywords pass would be enough.

Awesome! What's the release schedule like? :)

I started publishing of new version.
Github action will publish it soon.

Thanks so much!


Fix folder structure when page title contains /

related: https://github.com/gergelykalman/confluence-markdown-exporter/issues/10

This is not an issue on HEAD

@gergelykalman unfortunatelly it is not fixed in HEAD of https://github.com/gergelykalman/confluence-markdown-exporter neither HEAD of https://github.com/zzaakiirr/confluence-markdown-exporter

The slashes in titles was never an issue on my HEAD branch. What was an issue is when a parent of a page contained slashes.
I fixed this issue in my branch. I think your fix might work well, but I opted to filter the entire parents list as soon as I can in __dump_page()


proposal: Go 2: allow else err after function calls

Proposal Details
In Go, a map lookup, a type assertion and a channel receive operation will report success or failure in a second result value of type bool , if requested so for by assignment. This value is false if the operation failed and true if succeeded.
Functions and methods report failure in a in similar way by returning a last (and possibly only) value of type error. If this value is not nil, the function failed and the caller should handle the failure appropriately by logging, returning a decorated error, panicking, ignoring, etc. There are  exceptions, such as fmt.Errorf, where returning an error is not a failure, but these are mostly obvious.
As such the following constructs are ubiquitous in Go code:
// Current syntax for detecting/handling failure

// map key lookup
val, ok := m[key]
if !ok {
	// key is not found in the map
}

// type assertions
rw, ok := r.(io.ReadWriter)
if !ok {
	//  r does not satisfy io.ReadWriter
}

// channel receiving
val, ok := <-ch
if !ok {
	// channel closed
}

// file opening
f, err := os.Open("readme")
if err != nil {
 //	...
}

This proposal contains an idea to syntactically handle these kinds of failure reporting using the else keyword.
This is would works as follows.
Map lookup, type assertion and channel receive operations can optionally be followed by the else keyword and a code block. If so, the ensuing code block is executed if the operation failed (ie. ok in the examples above would be false). When used in an assignment, the assignment (or short variable declaration) takes place before executing the else block.
Example:
// Proposed new syntax

// map lookup failure handling
x := m["domain"] else {
	x = "localhost"
}

// type assertion failure handling
rw := r.(io.ReadWriter) else {
	return fmt.Errorf(...)
}

// channel receive failure handling
val := <- ch else {
	panic("channel unexpectally closed")
}

For sake of clarity, the map lookup the example above is identical to following current syntax
var x string
{
	var ok bool
	x, ok = m["domain"]
	if !ok {
		x = "localhost"
	}
}

and in a similar way for type assertions and channel receive operations.
For function and method calls, if the last return argument of the function is of type error, the call can also optionally be followed by the else keyword. In this case else must be followed by both an identifier and a code block. The identifier is used to create a variable in the code block capturing the error value which is removed from the call's returned argument list. The else-block is executed if the error value is not nil.  The identifier cannot be omitted but is allowed to be _.
This would look as follows:
// Proposed new syntax

f := os.Open("readme.txt") else err {
	return fmt.Errorf("uhoh: %w", err)
}

f.Close() else err {
	log.Println("warning: error closing file: %s", err.Error())
	return
}

// ignore error by assigning it to `_`
f.Close() else _ {
	panic("how checks closing errors anyway")
}

Note that the err variable is lifted to a separate scope (and ok variables are elided completely).
If the result of the call is used in an assignment, the assignment (or short variable declaration) of all other values take place before executing the ensuing else code block.
// set a default value on error
// (notice that val is visible in else-block because
// assignment happense before the else-block is executed)
val := parse(input) else err {
		log.Printf("...")
		val = "Go"  // ok
}

// here val is not visible because the short variable
// declaration is not part of the else construct.
val := toUpper(parse(input) else err {
		log.Printf("...")
		val = "Go"  // error: "val" is not defined
})

This is the full proposal. What follows is some motivation for this proposal and a discussion of some open ends.
Motivation
In current Go, variables that are needed to handle failures, often named err and ok , are almost always part of the same scope as the result variables.  As a consequence, they are visible long after their (intended) usage even though they are no longer needed. A typical symptom of this situation is having to change err :=  into err = (or back again) when reorganising code, or having to use err =  instead of err := because err was used earlier in the scope somewhere already, handling an error that is no longer relevant.
This is resolved using the proposed syntax (if the programmer chooses so), because ok variables are now elided completely
and err variables are now scoped to the block that handles the error. As a result, the "happy path"  of the code stays free from the variables that deal with the "therapy path" (failure / error path).
Some bugs in Go code appear to be a result of how Go currently deals with error handling syntactically:
str := "Go"
println(str)

if foo() {
str, err := parse(...)
	if err != if {
		return fmt.Errorf("...", err)
	}
	log.Println("found str: ", str)
}

// BUG: str is here still "Go", while the result of
// parse() is expected if foo() is true

It is likely that this type of bug occurs less with the new syntax, because := is no longer used with a mix of existing and new (error) variables:
str := "Go"
println(str)
if foo() {
	str = parse(...) else err {
		return fmt.Errorf("...", err)
	}
	log.Println("found str: ", str)
}

Notice that error handling syntax becomes smoother with the proposal. The overwhelmingly common error handling case of the form
// current Go
f, err := SomeFunc()
if err != nil {
	// handle error (do nothing, return, decorate, panic, log, etc)
}

can now be written as
// proposed Go
f := SomeFunc() else err {
	// ...
}

while still allowing handling the error exactly as before (i.e. by means of logging, returning, panicking, ignoring etc). This is a reduction 25% in terms of lines, but also reduces err != nil to err which saves some additional typing.   Of course, the current way of handling errors is still perfectly valid.
Finally, using this construct it becomes possible to use functions that return both a value and error (T, error) in chain calls and as argument to other calls without using intermediate variables. Of course, readability should  always prevail, but this allows "inline" error handling just like it is allowed to e.g. "inline" define a function:
func foo(r io.Reader) (string, error) {}

// "inline" error handling
s := foo(io.Open("readme") else err {
	panic(err)
})

type Bar struct{}

func (b Bar) DoA() (Bar, error)
func (b Bar) DoB() (Bar, error)
func (b Bar) DoS() (string, error)

var b Bar

// Chain calling functions that return (T, error)
s := b.DoA() else err {
	panic("a")
}.DoB() else err {
	panic("b")
} else err {
	panic("s")
}

Discussion
I do not expect that this proposal is water-tight on arrival. What follows are some open ends. Also, it might turn out that the proposal is completely unusable because I oversaw some syntax ambiguities that arises when using else this way. However, it seemed to me that using the else keyword to handle failure is worth investigating (maybe even in a different form if this proposal doesn't work) as it does not introduce new keywords and feels somewhat natural to use in this regard.
Custom error types
In this proposal, handling errors with else the function must return a last argument of type error and not a type that merely satisfies error.  I chose this for simplicity but the idea could possibly be extended to allow for custom error types requiring only that the error interface is satisfied.
type MyError struct{}
func (m *MyError) Error {}

func foo() *MyError {
  // ...
}

foo() else err {  // allowed?

}

Custom map types
Likewise, it can be expected that container types will mimic map behaviour by exposing methods such as:
type CustomMap[Key comparable, Value Any] struct{}

func (c *CustomMap[Key, Value]) Lookup(k Key) (Value, bool) {

}

These methods cannot be used with the syntax proposed here, although it could possibly be extended to work with function having a last argument of bool instead of error as well. However, it is unclear if this does not interfere with if syntax too much so I left it out.
Interference with if
Finally, it is easy to come up with examples that look a little weird when combined with if. For example:
// possibly funny looking construct on first sight
if strconv.ParseBool(input) else err {
	return fmt.Errorf("expected 'true' or 'false'")
} {
	println("got true")
}

Of course, handling errors using else is complimentary to current failure handling so if confusion arises it might be better to use the current way of error handling.

doesn't seem very different from #41908 #56895

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

also #32848 #37243

What happens if the else block completes normally?
x := m["domain"] else {
	x = "localhost"
}

The scope of variable x starts after this complete statement, so you can't assign to it from the 'else' block. Are you proposing to change the scope rules too?
This doesn't seem to add anything not already rejected by prior proposals (thanks @seankhliao for the links).

What happens if the else block completes normally?

Nothing special.

x := m["domain"] else {

	x = "localhost"

}

The scope of variable x starts after this complete statement, so you can't assign to it from the 'else' block. Are you proposing to change the scope rules too?

In my proposal any assignment happens just before the else scope is excuted (if so). So x can indeed be accessed in the else block. I've included an example of how it would translate to current syntax in the proposal.

This doesn't seem to add anything not already rejected in prior proposals (thanks @seankhliao for the links)

I would say see #31442, but I think you're familiar with it. 😄

What happens if the else block completes normally?

Nothing special.

Well, something must happen because the postfix else {...}operator changed the type of its operand (the call) so that it no longer has an error. So where did the error go? Was it silently discarded, causing the program to press on into uncharted states?

I think this proposal, as well as many other similar ones was based on the assumption that the error returning format v, err := call() is something special to the language. But maybe it's not the case in reality.
Currently, returning the error by err, v := call() worked equally well. To the language, the returned err is just another return value, nothing special.
So I guess in order for proposal like this to be successful, the v, err := call() format must be "formalized" to the language spec. But then that may in turn introduce some inconvenient limit to the language.

The original writeup compares an existing supported pattern of an declaration/assignment followed by an if statement to a new proposal that combines the two into a single statement.
I think it's also interesting to compare the new proposal to the other currently-supported form where the declaration/assignment is embedded in the if statement:
// map key lookup
if val, ok := m[key]; !ok {
	// key is not found in the map
}

// type assertions
if rw, ok := r.(io.ReadWriter); !ok {
	//  r does not satisfy io.ReadWriter
}

// channel receiving
if val, ok := <-ch; !ok {
	// channel closed
}

// file opening
if f, err := os.Open("readme"); err != nil {
	// ...
}

This shorthand has a similar "weight on the page" as the proposed new grammar. In this case the if condition must still be written out explicitly -- there is no assumption about what the final return value might represent -- but the ability to bundle it into the if statement header makes it collapse visually into that header, where it's easier to ignore while scanning. (The fact that it's harder to scan is actually why I often don't use this style, but for the sake of this comparison I'm assuming that having fewer lines is more important, since that seems to be a goal of the proposal.)
Comparing these two, the most significant difference seems to be that of scoping: when embedding a declaration in an if statement header, all of the declarations attach to the nested block rather than to the containing block. That means that val, rw, val, and f in the above are dropped once the if statement is done, which tends to encourage a less idiomatic style where both cases are indented:
if f, err := os.Open("readme"); err == nil {
	// do something with f
} else {
	// do something with err
}

If the primary concerns of this proposal are conciseness and scoping, I wonder if there's a smaller change in finding a way to place f in the containing block while keeping err limited to the nested block, while otherwise keeping this still as a familiar if statement that doesn't make any assumptions about what the condition might be.

A strawman follows. I don't particularly love this specific syntax but I'm including it to illustrate what I mean by making only a small adjustment to the existing construct:
if ^f, err := os.Open("readme"); err != nil {
	// do something with err
}
// do something with f

Strawman specification: For declarations that appear in the header of an if, for, or switch statement (and no others), the symbol ^ before a symbol declares that it should be exported into the block that contains the statement.
I realize this is essentially a competing proposal, but for the moment I'm just mentioning it to see what @markusheukelom proposer thinks about whether this still achieves similar goals despite being a smaller language change.
(I also have a feeling that something like this was already proposed before, but I wasn't able to guess what to search for to find it, if so.)

@apparentlymart Your strawman seems similar to the guard statement in Swift. See my comment on the old issue: https://github.com/golang/go/issues/31442#issuecomment-502132447

That does seem similar indeed! I think the notable difference is that I intended that only f would be declared into the parent block, while err would be limited only to the nested block.
It seems that guard makes it an all-or-nothing decision: all of the symbols go either in the parent block or the nested block. The err symbol being available for later use in the function (when there's no error) seemed to be one of the points of contention that this proposal was aiming to address.

if ^f, err := os.Open("readme"); err != nil {
	// do something with err
}
// do something with f

Strawman specification: For declarations that appear in the header of an if, for, or switch statement (and no others), the symbol ^ before a symbol declares that it should be exported into the block that contains the statement.

@apparentlymart Yes, this is also an idea to keep the main scope "clean" from err and ok variables. I wrote a proposal for this here. The drawback is that a new operator must be created, or an existing one overloaded. I still like the idea, maybe .. would possibly a better choice as it resembles a similar operation in filesystem access.
if ..f, err := os.Open("readme"); err != nil {
 	// do something with err
}

But it seemed that people just didn't like the idea (judging on the downvotes), maybe the syntax is too ugly or maybe there's other problems with it that I don't realise. I do think that the if-statement does become a bit noisy.

Hah... I guess it was your earlier proposal that I was remembering. 🤦♂ Sorry for proposing your own idea back to you.
FWIW, I prefer the smaller change of just allowing some more flexibility in how these symbols are scoped when using the existing constructs over adding an entirely new construct, especially because the smaller change is also more general and doesn't make any assumptions about error handling in particular. But perhaps I'm in the minority on that viewpoint. 🤷🏻♂

I think this proposal, as well as many others were based on the assumption that the error returning format v, err := call() is something special to the language. But maybe it's not the case in reality.

(Just for completeness, that was not my assumption; I did realise that it is mere a convention and not a language feature. Of course, error itself is special to the language.)

Currently, returning the error by err, v := call() worked equally well. To the language, the returned err is just another return value, nothing special.
So I guess in order for proposal like this to be successful, the v, err := call() format must be "formalized" to the language spec. But then that may in turn introduce some inconvenient limit to the language.

@nirui
Yes, this is a drawback of this proposal, but note that in e.g. the range-iterator proposal, functions with special signature are also becoming part of the language specification. Is that significantly different?
Note that the syntax could be made non-error aware by requiring a condition:
f := os.Open("readme") else err; err != nil {

}

Would that make such a proposal more likely to be of interest?  I decided to keep the proposal as simple as possible, but I do understand your point.

Hi @markusheukelom, what if a function returned multiple errors?
In my program, I have a function which does v, err1, err2 := call(). err1 and err2 leads to different handling pathways, similar to:
v, err1, err2 := function(...)
if err1 != nil {
    // reset the reader and continue
}
if err2 != nil {
    return err2
}
// make use of `v`
....

Note: the pathway re-joins after the handling of err1. Otherwise the code can simply be written as:
if v, err1, err2 := function(); err1 != nil {
    // handle err1
} else if err2 != nil {
    // handle err2
} else {
    // make use of `v`
}

I can't write it in v, err := function(...) because err1 and err2 might return the same error value (io.EOF etc), and creating a type-identifier-wrapper error is too expensive for the use case.
It could be helpful if your proposal can cover this use case too.

@nirui
I am afraid my proposal cannot (or even should) handle your case elegantly, as the proposal is meant for situations that have a single error variable. I am certainly not saying that your case isn't valid of course, it's just a use case that is a bit rare and for which the current way of returning multiple values can be used. I am not sure it's worthwhile to try an support these cases as for example Go also does not have a do {} while construct even though its easy to think of use-cases for do-while.
There are other error-reporting constructs that cannot be handled by my proposal, for example see my note on custom error types (although an extension can be imagined). If custom error types are to be supported and you are able to change the function signature then of course you code do something like
type ErrPair struct {
	Err1, Err2 error
}

func (e ErrPair) Error() string {}

v := function() else err {
	if v.Err1 != nil {
		// reset the reader and continue
	}
	if v.Err2 != nil {
    	    return err2
	}
}

// make use of `v`
....

This would work in the current proposal as well if the function returns function() (Value, error) but then you need a type assertion in your error handling block (which I assumed is too expensive as you mentioned).

This is a lot like the recent #65579, with different syntax.

Based on the discussion, this is a likely decline.  Leaving open for four weeks for final commens.

@ianlancetaylor

This is a lot like the recent #65579, with different syntax.

Yes there is certainly some resemblance. However, this proposal does not introduce a new operator or keyword and is more general in that is also handles map lookup, type assertion, channel receive failure. (There are other proposals using the else keyword, btw).
Understand/agree it is a likely decline.
I hope that you've read my "Motivation" section. It outlines an issue with current error handling besides verbosity of syntax which I think is not so explicitly expressed elsewhere (i.e. having err, ok ok in scope long after they are needed), at least to my knowledge. Maybe this can add to other ideas/proposals wrt error handling.

No change in consensus.


Support the single provider journey through the invite provider user wizard

Context
The latest design has different conditional rendering logic for the scenario where an inviting user belongs to one provider organisation.

Changes proposed in this pull request
Adds conditional rendering logic for scenario where inviting user belongs to one provider organisation.

Guidance to review

Link to Trello card
https://trello.com/c/gH5jrsuu/2532-support-the-single-provider-journey-through-the-invite-provider-user-wizard

Things to check

[x] This code doesn't rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] API release notes have been updated if necessary
[x] New environment variables have been added to the Azure config

I've just realised we could simplify more by making single_provider dynamic - then we could lose the postback to update_details
    def edit_details
      # set a provider if there is only one to set
      wizard_setup_options = if available_providers.count == 1
                               { providers: available_providers.map(&:id) }
                             else
                               {}
                             end
      @wizard = wizard_for(wizard_setup_options.merge(current_step: 'details'))
      @wizard.save_state!
    end


replace standard editor with lvlibp

load time is horrible, lvlibp is easy to try and might help

doesn't seem to help, lv spends as much time recompiling links in the ppl as it does loading the classes normally


Watch does not seem to work in Visual Studio 2015

TypeScript Version:  2.6.0-dev.20171015
Using watch in typescript with Visual Studio 2015 is broken in version 2.6. Running the command
tsc --watch

If the file is open in another editor the compilation will work as expected, even when changed in VS2015
Expected behavior:
Any code change will be compiled and the files updated.
Actual behavior:
Compilation is triggered but no files are compiled.

What version of tsc are you using? Visual Studio has no interactions with tsc --watch, so do you see the same when you edit the file in any other editor? does this happen on all your projects or a specific project? if so can you share your config file?

I just tested this with 2.6.0-dev.20171017 and the same happens.
I've tried in multiple other editors and they all work as expected. The biggest difference from VS2015 to the other editors is that, when updated by VS the time from change detection to compilation is less than a second while the other editors it's usually 2-5 seconds.
I've also tried fresh projects to make sure and the problem remained.
This is my config, as requested:
{
  "compilerOptions": {
    "target": "es5",
    "module": "none",
    "lib": [ "es2015", "dom" ],
    "allowJs": true,
    "strict": false,
    "outDir": "Static/scripts/"
  },
  "include": [
    "Scripts/**/*"
  ],
  "exclude": [
    "node_modules"
  ]
}

I've tried in multiple other editors and they all work as expected. The biggest difference from VS2015 to the other editors is that, when updated by VS the time from change detection to compilation is less than a second while the other editors it's usually 2-5 seconds.

I am not sure i understand this statement. the editor has nothing to do with tsc --watch, watch listens on file writes on your file system, and not the editor. can you share a project for us to look at?

I meant that updating the files in VS would lead to a compilation time of less than a second while updating it in other editors had a compilation time of around 2-5 seconds. I understand that watch does not depend on the editor, I was just reporting what happens currently.
This seems to happen to any project I create. I've created a new MVC Web project and compiled every file inside the generated Scripts folder and the result is the same.

Looks like all the files are .js files in this project.

You're right. Those are just the files that are included in new projects. I updated it with a typescript and javascript file. With both filetypes the result is the same:
TSTest.zip

@Nashuim please give tomorrow's typescript@next a try.

Just tested it and it works fine now.
Thanks for the help!

thanks for confirming!


ba692ca2-f7a3-4b39-b7b5-f95b828ad6d2

this is for automated testing

db4a17a9-00b3-4a13-b482-c7fe0841c8a6


Register ICA module for ICA Host keeper

Closes: #1710
What is the purpose of the change

Add a description of the overall background and high level changes that this PR introduces

Register the ICA module basics in order to complete the ICA host integration to Osmosis, that is currently not working properly, as described in issue #1710
Brief Changelog

Register ICA module basics

Testing and Verifying
This change is a trivial rework / code cleanup without any test coverage.
Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior changes? no
Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? no
How is the feature or change documented? not applicable

Can you investigate go test failures?

Can you investigate go test failures?

What I found: by adding the ICA module app basics to the osmosis app, it enables the ICA module InitGenesis function for the init chain sequence, which Binds the ICA port.
While running the upgrade later, the ICA module InitModule function is called, which tries to bind the same port.
Should the upgrade tests run the InitGenesis sequence in the first place? I am trying to understand if it is an issue in the testing, or in the app.

Can you investigate go test failures?

What I found: by adding the ICA module app basics to the osmosis app, it enables the ICA module InitGenesis function for the init chain sequence, which Binds the ICA port. While running the upgrade later, the ICA module InitModule function is called, which tries to bind the same port.
Should the upgrade tests run the InitGenesis sequence in the first place? I am trying to understand if it is an issue in the testing, or in the app.

I think we need to check if the port is not already bound before calling InitModule

Can you investigate go test failures?

What I found: by adding the ICA module app basics to the osmosis app, it enables the ICA module InitGenesis function for the init chain sequence, which Binds the ICA port. While running the upgrade later, the ICA module InitModule function is called, which tries to bind the same port.
Should the upgrade tests run the InitGenesis sequence in the first place? I am trying to understand if it is an issue in the testing, or in the app.

I think we need to check if the port is not already bound before calling InitModule

I can do that, however I read here that InitGenesis should not run, or the ICA module InitGenesis is clearly being called when running the upgrade test.
Any help would be appreciated here! Thanks

Ah those are different, init genesis will still run at chain genesis, but not at the upgrade time
Anything we need to do to make init genesis work? (I haven't been looking at tests)
This is viable to get into v10 if its sufficiently simple.

Ah those are different, init genesis will still run at chain genesis, but not at the upgrade time
Anything we need to do to make init genesis work? (I haven't been looking at tests)
This is viable to get into v10 if its sufficiently simple.

I believe that the issue is either the Upgrade tests are running the InitGenesis while they shouldn't OR we need to call the ICA InitModule, only if it has not been initialized first (meaning checking if the ICA port is already bound).

Ah interesting, because our app setup calls InitGenesis for the entire chain, not the v8-only modules. That makes sense.
This is unfortunate that theres not a clean way to keep this test around. I agree with the conclusion that for now we can comment the test out. We should make a backlog item for coming back and understanding how to re-instate it though, as this is an error we can get for testing addition of any new module in the future.

Can you take a look at #1825? Fixes the test failure as well


feat: environment-level configuration variables

In a workflow for deleting deployments, it is also currently difficult or impossible to determine the target GitHub environment (i.e., the jobs.<job_id>.environment key value) and get its environment-level configuration variables.

Relates #268

see #289


Add custom tags

This is the same pr as https://github.com/DataDog/uwsgi-dogstatsd/pull/13
Fixes failing tests because of race condition in the bash script, bumps uwsgi to the latest version, build tests from source instead from github

@DataDog
Any update on this?
I want to use this feature too.

Hello @helmus
Thanks for your contribution and sorry for the very late reply.
I've merged #17  which contains custom tags support on top of various other additions. Unfortunately, it won't use the same field name for the configuration, I hope it won't be a problem for you if you switch to use the master branch of uwsgi-dogstatsd. The field name in master is: dogstatsd-extra-tags and tags are comma-separated.
However, I've cherry-picked your commit (to have you as an author of a contribution in the git log) about the tests fix + uwsgi upgrade 👍
Once again, thank you.


ERR_PNPM_FETCH_404

pnpm add @vant/nuxt -D

GET https://registry.npmmirror.com/@vant%2Fnuxt: Not Found - 404
vant/nuxt is not in the npm registry, or you have no permission to fetch it.

Wait for the release of npm package

@tolking I have released the initial 1.0.0-beta.0 version and sent you the invitation of vant npm org.
So you can decide when to publish a stable version of @vant/nuxt. ^_^

ok👌


Update bower.json

Match the dependency to bootstrap that is in the docs.  Since this supports bootstrap 2 and 3 we shouldn't have a dependency requiring 3 to be used.

Thanks @jstoup111!


[crosswalk-17][webapi] Add baseline for bdd tests on Nexus7

ARM-Nexus7:
Impacted TCs num(approved): New 0, Update 7, Delete 0
Unit test Platform: Crosswalk Project for Android 17.46.448.0
Unit test result summary: Pass 0, Fail 0, Blocked 0

Merge as-is.


Private Projects with Member-Only View and Edit

Hi! Great tool that me and some folks would love using. We require though that only users that are assigned to projects can see and edit any project related details. The project overview page should be limited to members that have been invited by the creator of the project.

Hi @oerlex ; I finally managed to complete a first iteration of this. I have introduced the concept of project visibility. Public projects can be seen by anyone, whereas private ones can only be seen by their members (and admins). This is combination with user roles allows you to have people on projects that can only view/modify their properties.
Closing this for now but please open other issues if you have other requests. Thanks!


Scope cleanup

Just a little cleanup. The edition scopes should live in the Edition model and renamed the methods to be a little clearer.

Makes sense, yep.


Unable to  start spotify_player connect closed via error

Describe the bug
I'm unable to start the spotify_player with error
Error: Failed to initialize the Spotify data

Caused by:
    http error: request: error sending request for url (https://api.spotify.com/v1/me/player): error trying to connect: connection closed via error

Expected behaviour
unable to start the spotify_player . But the spotify web can access.
Log and backtrace

log file content

2024-02-17T03:44:14.963469Z  INFO spotify_player::state::data: Loading Playlists data from /Users/xbunax/.cache/spotify-player/Playlists_cache.json...
2024-02-17T03:44:14.964591Z  INFO spotify_player::state::data: Successfully loaded Playlists data!
2024-02-17T03:44:14.964607Z  INFO spotify_player::state::data: Loading FollowedArtists data from /Users/xbunax/.cache/spotify-player/FollowedArtists_cache.json...
2024-02-17T03:44:14.989362Z  INFO spotify_player::state::data: Successfully loaded FollowedArtists data!
2024-02-17T03:44:14.989379Z  INFO spotify_player::state::data: Loading SavedAlbums data from /Users/xbunax/.cache/spotify-player/SavedAlbums_cache.json...
2024-02-17T03:44:15.108036Z  INFO spotify_player::state::data: Successfully loaded SavedAlbums data!
2024-02-17T03:44:15.108065Z  INFO spotify_player::state::data: Loading SavedTracks data from /Users/xbunax/.cache/spotify-player/SavedTracks_cache.json...
2024-02-17T03:44:15.540637Z  INFO spotify_player::state::data: Successfully loaded SavedTracks data!
2024-02-17T03:44:18.076120Z  INFO spotify_player::auth: Successfully used the cached credentials to create a new session!
2024-02-17T03:44:18.086704Z  INFO spotify_player::token: Getting new authentication token...

nothing in the backtrace file

Please refer to this URL for more details.
Screenshots

Environment

OS: macOS 14.2
Application version: 0.16.3
Application features: Install from brew

Additional context

@xbunax Does it happen every time you opened the app? Do you have a VPN turned on or any network setting that may block API access to Spotify server?

@xbunax Does it happen every time you opened the app? Do you have a VPN turned on or any network setting that may block API access to Spotify server?

The web and app are both can be access. And other devices don't have this problem at the same network enviroment. I also change the client ID to my own ,but the problem is still. what' more , I go to the error url https://api.spotify.com/v1/me/player and it push back error status:401 message: no token provide

And other devices don't have this problem at the same network enviroment

Does this mean you can run spotify_player in other devices?

And other devices don't have this problem at the same network enviroment

Does this mean you can run spotify_player in other devices?

yes,I can use it in powershell and wsl2.

And other devices don't have this problem at the same network enviroment

Does this mean you can run spotify_player in other devices?

I find that I open the surge's tun mode ,spotify_player can work well, Finally. Thanks a lot.

And other devices don't have this problem at the same network enviroment

Does this mean you can run spotify_player in other devices?

I find that I open the surge's tun mode ,spotify_player can work well, Finally. Thanks a lot.

Glad to hear that. So it was because of a network block setting like I initially suspected