text:
Added new xWebConfigProperty & xWebConfigPropertyCollection resources (Addresses #249)

Created 2 new resources that build upon the capabilities provided by the xWebConfigKeyValue resource to support a much wider range of scenarios (essentially any property in the web.config file).
The xWebConfigProperty resource supports setting an individual property, for example if you wanted to set the system.webServer/directoryBrowse element's enabled attribute to false.
The xWebConfigPropertyCollection resource is essentially a direct replacement for the xWebConfigKeyValue resource, except that it supports setting properties in any collection element in the web.config file, for example I've used it to ensure the system.webServer/security/requestFiltering section's verbs collection has an add element to disallow the TRACE verb, i.e.:
<verbs>   <add verb="TRACE" allowed="false" /> </verbs>
Examples, tests & docs are included.
Fixes #338
Fixes #249
Fixes #344

This change is

 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.

For reviewers: As per https://github.com/PowerShell/xWebAdministration/issues/302 & https://github.com/PowerShell/xWebAdministration/issues/314, it appears the failing tests for xWebsite & xWebApplication are due to an issue with WMF 5.1, not any changes I have made. I can comment out the affected tests just so that AppVeyor will pass, but not really sure that is the best approach. Please let me know what you'd prefer.

Reviewed 13 of 15 files at r1, 2 of 2 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

@turkeys-united Sorry that you had to wait for so long getting this PR review. If you add the fix in issue #314 will the test pass? I can't merge with failing tests, and it is not appropriate to remove the tests that are failing either. So only solution is to resolve the test, and I would appreciate it extremely if you could help out with this.

Closing and reopening this PR to kick of the tests again since issue #302 and #314 was resolved.

@turkeys-united are you able to work on this PR?

@turkeys-united impressive work on this one! I did a quick review of this i found the biggest items. I will make a more detailed review once you can work on this one.

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.schema.mof, line 7 at r2 (raw file):

    [Key, Description("Filter used to locate property to update.")] String Filter;
    [Key, Description("Name of the property to update.")] String PropertyName;
    [Write, ValueMap{"Present","Absent"}, Values{"Present","Absent"}] String Ensure;

We should have a description on this property too.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.schema.mof, line 12 at r2 (raw file):

    [Key, Description("Name of the property of the property collection item to update.")] String ItemPropertyName;
    [Write, Description("Value of the property of the property collection item to update.")] String ItemPropertyValue;
    [Write, ValueMap{"Present","Absent"}, Values{"Present","Absent"}] String Ensure;

We should have a description on this property too.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 43 at r2 (raw file):

    $env:xWebConfigPropertyPropertyName = 'enabled'

    Describe "$($script:DSCResourceName)_Integration" {

The other integration tests in this resource module backups the configuration before the tests start, and restores them in the finally-block. We should do the same here.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 136 at r2 (raw file):

finally
{
    if (Get-Module -Name 'MockWebAdministrationWindowsFeature')

This should not be necessary in the integration tests? Throughout the integration tests.

Tests/Integration/MSFT_xWebConfigPropertyCollection.Integration.Tests.ps1, line 31 at r2 (raw file):

# Using try/finally to always cleanup.
try

The other integration tests in this resource module backups the configuration before the tests start, and restores them in the finally-block. We should do the same here.

Comments from Reviewable

@johlju Yes, should be able to find some time in the next few days to address the review comments, thanks!

@turkeys-united Awesome! The PR needs a rebase too since there are merge conflicts from a recent merged.

Codecov Report

Merging #330 into dev will increase coverage by <1%.
The diff coverage is 96%.

@@         Coverage Diff          @@
##            dev   #330    +/-   ##
====================================
+ Coverage    89%    89%   +<1%
====================================
  Files        14     16     +2
  Lines      2171   2300   +129
====================================
+ Hits       1944   2069   +125
- Misses      227    231     +4

@turkeys-united sorry I missed going back to this one. :/ Could you make sure the tests are passing. A file has the wrong encoding? https://ci.appveyor.com/project/PowerShell/xwebadministration/build/1.17.1028.0?fullLog=true#L35

Hi @johlju encoding corrected, tests now passing, thanks for getting back to it!

Review status: 10 of 18 files reviewed at latest revision, 5 unresolved discussions.

README.md, line 283 at r5 (raw file):

## Versions

### Unreleased

The README.md have not the latest changes. Could you please rebase against branch dev using git rebase (not by using git pull or git merge). If you don't know how to rebase, please look at this link (this is the same as resolving merge conflicts); https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md#resolve-merge-conflicts

Comments from Reviewable

Great work on this! I review a bit more, but have the tests left. and will run through it once more when these review comments are resolved.

Reviewed 4 of 15 files at r1, 3 of 7 files at r3, 2 of 2 files at r5, 1 of 1 files at r7.
Review status: 16 of 18 files reviewed at latest revision, all discussions resolved.

a discussion (no related file):
Please add submit an issue that the old deprecated resource should be removed in a future release.

README.md, line 3 at r7 (raw file):

# xWebAdministration

The **xWebAdministration** module contains the **xIISModule**, **xIISLogging**, **xWebAppPool**, **xWebsite**, **xWebApplication**, **xWebVirtualDirectory**, **xSSLSettings** and **xWebConfigKeyValue** DSC resources for creating and configuring various IIS artifacts.

Please add the new resources here.

README.md, line 220 at r7 (raw file):

* **Ensure**: Ensures if the virtual directory is **Present** or **Absent**.

### xWebConfigKeyValue

These two new resources deprecate this one? If so, we should add a note under this section saying that this resource is deprecated an reference the new resources.

README.md, line 237 at r7 (raw file):

* **PropertyName**: Name of the property to update.
* **Value**: Value of the property to update.
* **Ensure**: Ensures if the property is **Present** or **Absent**.

Can we change this to Indicates if the property and value should be present or absent. Defaults to 'Present'. { *Present* | Absent }

README.md, line 251 at r7 (raw file):

* **ItemPropertyName**: Name of the property of the property collection item to update.
* **ItemPropertyValue**: Value of the property of the property collection item to update.
* **Ensure**: Ensures if the property is **Present** or **Absent**.

Can we change this to Indicates if the property and value should be present or absent. Defaults to 'Present'. { *Present* | Absent }

.vscode/launch.json, line 0 at r7 (raw file):
Is there a reason this file was removed?

.vscode/RunGlobalTests.ps1, line 0 at r7 (raw file):
Is there a reason this file was removed?

.vscode/RunPesterTests.ps1, line 0 at r7 (raw file):
Is there a reason this file was removed?

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 2 at r7 (raw file):

SuppressMessageAttribute

We should not need these two rows? This and the next row.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 13 at r7 (raw file):

    ConvertFrom-StringData -StringData @'
    VerboseGetTargetCheckingTarget    = Checking for the existence of property "{0}" using filter "{1}" located at "{2}".
    VerboseGetTargetAttributeCheck    = Checking if property "{0}" is an attribute.

Can't find this being used?

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 17 at r7 (raw file):

    VerboseGetTargetPropertyFound     = Property "{0}" has been found.
    VerboseSetTargetCheckingProperty  = Checking for existence of property "{0}".
    VerboseSetTargetAddItem           = Property "{0}" does not exist, adding property.

Can't find this being used?

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 18 at r7 (raw file):

    VerboseSetTargetCheckingProperty  = Checking for existence of property "{0}".
    VerboseSetTargetAddItem           = Property "{0}" does not exist, adding property.
    VerboseSetTargetEditItem          = Property "{0}" exists, editing property.

Can't find this being used?

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 20 at r7 (raw file):

    VerboseSetTargetEditItem          = Property "{0}" exists, editing property.
    VerboseSetTargetRemoveItem        = Property "{0}" exists, removing property.
    VerboseTestTargetCheckingTarget   = Checking for the existence of property "{0}" using filter "{1}" located at "{2}".

This text is exactly like VerboseGetTargetCheckingTarget. Can we reuse that? Or maybe this will be removed when changing logic it Test-fuction to use Get-function (see other review comment)

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 60 at r7 (raw file):

process

We should need a process-block. It can be removed. Throughout all functions.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 77 at r7 (raw file):

                -Message ($LocalizedData.VerboseGetTargetPropertyNotFound -f $PropertyName )

             return @{

Instead of returning here, could we only return at the end of the function?
We could initialize the hash table in a variable at the top of the function with the 'Absent' values, and if the the item is found we just change values.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 88 at r7 (raw file):

            -Message ($LocalizedData.VerboseGetTargetPropertyFound -f $PropertyName )

        return @{

This hash table should return all properties in the schema.mof.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 118 at r7 (raw file):

{
    # ShouldProcess not implemented for custom DSC resource.
    [Diagnostics.CodeAnalysis.SuppressMessageAttribute("PSUseShouldProcessForStateChangingFunctions", "")]

We should not need this.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 152 at r7 (raw file):

            # Property needs to be updated.
            Write-Verbose `
                -Message ($LocalizedData.VerboseSetTargetCheckingProperty -f $PropertyName )

This localized message seems wrong?

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 230 at r7 (raw file):

            -Message ($LocalizedData.VerboseTestTargetCheckingTarget -f $PropertyName, $Filter, $WebsitePath )

        $existingValue = Get-ItemValue `

This seems like duplicated code of Get-TargetResource. Can we call Get-TargetResource instead an use the values returned in the hash table?

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 258 at r7 (raw file):

        }

        Write-Verbose `

This Verbose message should not be here?  Seems it's already written above?

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 2 at r7 (raw file):

SuppressMessageAttribute

We should not need this. This row and the one below.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 16 at r7 (raw file):

    VerboseGetTargetPropertyNotFound       = Property "{0}" has not been found.
    VerboseGetTargetPropertyFound          = Property "{0}" has been found.
    VerboseSetTargetCheckingTarget         = Checking for the existence of property "{0}" in collection item "{1}/{2}" with key "{3}={4}" using filter "{5}" located at "{6}".

This text is exactly like VerboseGetTargetCheckingTarget. Can we reuse that? Or maybe this will be removed when changing logic it Test-fuction to use Get-function (see other review comment)

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 17 at r7 (raw file):

    VerboseGetTargetPropertyFound          = Property "{0}" has been found.
    VerboseSetTargetCheckingTarget         = Checking for the existence of property "{0}" in collection item "{1}/{2}" with key "{3}={4}" using filter "{5}" located at "{6}".
    VerboseSetTargetAddItem                = Collection item "{0}/{1}" with key "{2}={3}" does not exist, adding with property "{4}".

Can't find this being used?

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 20 at r7 (raw file):

    VerboseSetTargetEditItem               = Collection item "{0}/{1}" with key "{2}={3}" exists, editing property "{4}".
    VerboseSetTargetRemoveItem             = Property "{0}" exists, removing property.
    VerboseTestTargetCheckingTarget        = Checking for the existence of property "{0}" in collection item "{1}/{2}" with key "{3}={4}" using filter "{5}" located at "{6}".

This text is exactly like VerboseGetTargetCheckingTarget. Can we reuse that? Or maybe this will be removed when changing logic it Test-fuction to use Get-function (see other review comment)

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 123 at r7 (raw file):

                -Message ($LocalizedData.VerboseGetTargetItemNotFound -f $CollectionName, $ItemName, $ItemKeyName, $ItemKeyValue )

            return $result + @{

Same as in the previous resource. Could we just return once at the end of the function?

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 187 at r7 (raw file):

{
    # ShouldProcess not implemented for custom DSC resource.
    [Diagnostics.CodeAnalysis.SuppressMessageAttribute("PSUseShouldProcessForStateChangingFunctions", "")]

We should not need this.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 243 at r7 (raw file):

                -Message ($LocalizedData.VerboseSetTargetCheckingTarget -f $ItemPropertyName, $CollectionName, $ItemName, $ItemKeyName, $ItemKeyValue, $Filter, $WebsitePath )

            $existingItem = Get-ItemValues `

This seems like duplicated code of Get-TargetResource. Can we call Get-TargetResource instead an use the values in the returned hash table?

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 383 at r7 (raw file):

            -Message ($LocalizedData.VerboseTestTargetCheckingTarget -f $ItemPropertyName, $CollectionName, $ItemName, $ItemKeyName, $ItemKeyValue, $Filter, $WebsitePath )

        $existingItem = Get-ItemValues `

This seems like duplicated code of Get-TargetResource. Can we call Get-TargetResource instead an use the returned hash table? Then we could skip most of the verbose messages in this function too maybe?

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 469 at r7 (raw file):

{
    # Evaluated, choose not to.
    [Diagnostics.CodeAnalysis.SuppressMessageAttribute("PSUseSingularNouns", "")]

We should need this row.

Examples/Sample_xWebConfigProperty_Add.ps1, line 15 at r7 (raw file):

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Examples/Sample_xWebConfigProperty_Add.ps1, line 29 at r7 (raw file):

            Filter = 'system.webServer/directoryBrowse'
            PropertyName = 'enabled'
            Value='false'

Please add spaces around the equal sign.

Examples/Sample_xWebConfigProperty_Remove.ps1, line 14 at r7 (raw file):

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Examples/Sample_xWebConfigPropertyCollection_Add.ps1, line 14 at r7 (raw file):

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Examples/Sample_xWebConfigPropertyCollection_Add.ps1, line 24 at r7 (raw file):

    Node $NodeName
    {
        # Disables the HTTP TRACE method at the server level.

We don't need this comment, since that is in the SYNOPSIS.

Examples/Sample_xWebConfigPropertyCollection_Remove.ps1, line 14 at r7 (raw file):

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Examples/Sample_xWebConfigPropertyCollection_Remove.ps1, line 24 at r7 (raw file):

    Node $NodeName
    {
        # Removes disabling the HTTP TRACE method at the server level.

We don't need this comment, since that is in the SYNOPSIS.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 5 at r7 (raw file):

$script:DSCResourceName = 'MSFT_xWebConfigProperty'

#region HEADER

Could we update this to the latest integration test template? For both integration tests.
https://github.com/PowerShell/DscResources/blob/master/Tests.Template/integration_template.ps1

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 43 at r7 (raw file):

    # Constants for Tests
    $websiteName = New-Guid
    $env:xWebConfigPropertyWebsitePath  = "IIS:\Sites\$($websiteName)"

Instead of using environment variable, could we use ConfigurationData and passing that? Then the values used for the integration tests are in the sam file as the config.
See example here: https://github.com/PowerShell/SqlServerDsc/blob/dev/Tests/Integration/MSFT_SqlServerDatabaseMail.Integration.Tests.ps1
And the accompanying config: https://github.com/PowerShell/SqlServerDsc/blob/dev/Tests/Integration/MSFT_SqlServerDatabaseMail.config.ps1

Comments from Reviewable

Thanks @johlju I'll do my best to make time for these in the next few weeks.

Review status: 16 of 18 files reviewed at latest revision, 38 unresolved discussions.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 154 at r7 (raw file):
Quoted 6 lines of code…

            Set-WebConfigurationProperty `
                -Filter $Filter `
                -PSPath $WebsitePath `
                -Name $PropertyName `
                -Value $Value `
                -WarningAction Stop

Some configuration property values are strings and some are integers, but we can only have one datatype for $value in the mof.  We should add a helper function to convert it to integer if needed.  Something like this, but perhaps there is a better way:
$checkvalue = Get-WebConfigurationProperty -PSPath $WebsitePath -Filter $Filter -Name $PropertyName

if ($checkvalue -isnot [System.String])
{
    $propertyType = $value.TypeName
}

if ($propertyType -eq "system.int64")
{
    [int]$value = [convert]::ToInt64($value, 10)
}

For example, this filter"system.webServer/security/requestFiltering/requestLimits" and this property maxAllowedContentLength, has a integer value.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 282 at r7 (raw file):

function Get-ItemValue
{
    param

We should use the CmdletBinding attribute on every function and also define the OutputType Attribute for all functions with output.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 49 at r7 (raw file):

    Describe "$($script:DSCResourceName)_Integration" {
        # Ensure the WinRM service required by DSC is running.
        Get-Service -Name 'WinRM' | Where-Object { $_.Status -ne 'Running' } | Start-Service

This is probably not needed.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 73 at r7 (raw file):

#& "$($script:DSCResourceName)_Add" -OutputPath $TestDrive

This commented out line is actually the recommended way to do this versus the Invoke-Expression above.  There's a PSSA rule for this (PSAvoidUsingInvokeExpression) that this repo isn't opted into yet.

Tests/Unit/MSFT_xWebConfigProperty.tests.ps1, line 91 at r7 (raw file):
Quoted 7 lines of code…

                $parameters = @{
                    WebsitePath  = 'MACHINE/WEBROOT/APPHOST'
                    Filter       = 'system.webServer/advancedLogging/server'
                    PropertyName = 'enabled'
                    Value        = 'true'
                    Ensure       = 'Present'
                }

This code is repeated several times and can be initialized above the describe block for re-use throughout the script.

Tests/Unit/MSFT_xWebConfigProperty.tests.ps1, line 223 at r7 (raw file):

$result = Set-TargetResource @parameters

This function doesn't output anything, so no need to store it in a variable.

Tests/Unit/MSFT_xWebConfigPropertyCollection.tests.ps1, line 39 at r7 (raw file):
Quoted 9 lines of code…

                $parameters = @{
                    WebsitePath      = 'MACHINE/WEBROOT/APPHOST'
                    Filter           = 'system.webServer/advancedLogging/server'
                    CollectionName   = 'verbs'
                    ItemName         = 'add'
                    ItemKeyName      = 'verb'
                    ItemKeyValue     = 'TRACE'
                    ItemPropertyName = 'allowed'
                }

This hash table is repeated throughout, but should be initialized once in the beginning of the script

Tests/Unit/MSFT_xWebConfigPropertyCollection.tests.ps1, line 55 at r7 (raw file):

It 'Should return the correct values' {

Since the same comparison values are referenced several times throughout the script, they can be referenced as $parameters.websitePath and $parameters.Filter. for example, instead of hard-coding each time.  Would make for easier updating in the future.

Comments from Reviewable

Review status: 16 of 18 files reviewed at latest revision, 46 unresolved discussions.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 154 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…

            Set-WebConfigurationProperty `
                -Filter $Filter `
                -PSPath $WebsitePath `
                -Name $PropertyName `
                -Value $Value `
                -WarningAction Stop

Some configuration property values are strings and some are integers, but we can only have one datatype for $value in the mof.  We should add a helper function to convert it to integer if needed.  Something like this, but perhaps there is a better way:
$checkvalue = Get-WebConfigurationProperty -PSPath $WebsitePath -Filter $Filter -Name $PropertyName

if ($checkvalue -isnot [System.String])
{
    $propertyType = $value.TypeName
}

if ($propertyType -eq "system.int64")
{
    [int]$value = [convert]::ToInt64($value, 10)
}

For example, this filter"system.webServer/security/requestFiltering/requestLimits" and this property maxAllowedContentLength, has a integer value.

On second thought, my example assumes that the property exists.  If the property is $null then Get-WebConfigurationProperty wouldn't be able to return a TypeName.  However, with the same filterGet-WebConfiguration can, even if the property is null.  This would apply to the WebConfigPropertyCollection as well.

Comments from Reviewable

Review status: 10 of 15 files reviewed, 46 unresolved discussions (waiting on @mavratar, @johlju, @turkeys-united, and @regedit32)

README.md, line 3 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please add the new resources here.

Done.

README.md, line 220 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
These two new resources deprecate this one? If so, we should add a note under this section saying that this resource is deprecated an reference the new resources.

Done.

README.md, line 237 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Can we change this to Indicates if the property and value should be present or absent. Defaults to 'Present'. { *Present* | Absent }

Done.

README.md, line 251 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Can we change this to Indicates if the property and value should be present or absent. Defaults to 'Present'. { *Present* | Absent }

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 2 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

SuppressMessageAttribute

We should not need these two rows? This and the next row.

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 13 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Can't find this being used?

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 17 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Can't find this being used?

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 18 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Can't find this being used?

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 20 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This text is exactly like VerboseGetTargetCheckingTarget. Can we reuse that? Or maybe this will be removed when changing logic it Test-fuction to use Get-function (see other review comment)

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 60 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

process

We should need a process-block. It can be removed. Throughout all functions.

Done. Stylistically I prefer process blocks in PowerShell, but I appreciate that for consistency with other resources these need to be removed & so have removed them.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 118 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
We should not need this.

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 152 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This localized message seems wrong?

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 258 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This Verbose message should not be here?  Seems it's already written above?

OK. It is written above, but in a different context, i.e, when written above it's in the context of Test-TargetResource returning false because the target resource isn't in the desired state (it's expected to be absent but is actually present), whereas this final Write-Verbose is for the case where the target resource is already in the desired state.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 282 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…
We should use the CmdletBinding attribute on every function and also define the OutputType Attribute for all functions with output.

Done.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 2 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

SuppressMessageAttribute

We should not need this. This row and the one below.

Done.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 16 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This text is exactly like VerboseGetTargetCheckingTarget. Can we reuse that? Or maybe this will be removed when changing logic it Test-fuction to use Get-function (see other review comment)

Done.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 17 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Can't find this being used?

It's used in Set-TargetResource.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 20 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This text is exactly like VerboseGetTargetCheckingTarget. Can we reuse that? Or maybe this will be removed when changing logic it Test-fuction to use Get-function (see other review comment)

Done.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 187 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
We should not need this.

Done.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 469 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
We should need this row.

Done.

.vscode/launch.json, line  at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Is there a reason this file was removed?

Done.

.vscode/RunGlobalTests.ps1, line  at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Is there a reason this file was removed?

Done.

.vscode/RunPesterTests.ps1, line  at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Is there a reason this file was removed?

Done.

Comments from Reviewable

Great work so far on this! Acknowledge all resolved or answered review comments. Added a few, and wait for the others to be answered or resolved. Thanks!

Reviewed 5 of 15 files at r1, 2 of 7 files at r3, 6 of 6 files at r8.
Review status: all files reviewed, 25 unresolved discussions (waiting on @turkeys-united and @regedit32)

README.md, line 220 at r8 (raw file):

### xWebConfigKeyValue

Can we add deprecated to this section header?
### xWebConfigKeyValue (DEPRECATED)

README.md, line 229 at r8 (raw file):

NOTE: The **xWebConfigKeyValue** resource is deprecated and has been replaced by the **xWebConfigProperty** and **xWebConfigPropertyCollection** resources.
It may be removed in a future release.

Can we move this between the resource name section and the parameters, so it is the first the user sees? Also can we add it as a markdown quote, like this?
>**NOTE:** The **xWebConfigKeyValue** resource is deprecated and has been
>replaced by the **xWebConfigProperty** and **xWebConfigPropertyCollection**
>resources. It may be removed in a future release.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 77 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Instead of returning here, could we only return at the end of the function?
We could initialize the hash table in a variable at the top of the function with the 'Absent' values, and if the the item is found we just change values.

If this is kept as -is, then we should return all the properties in the schema.mof.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 258 at r7 (raw file):
Previously, turkeys-united wrote…
OK. It is written above, but in a different context, i.e, when written above it's in the context of Test-TargetResource returning false because the target resource isn't in the desired state (it's expected to be absent but is actually present), whereas this final Write-Verbose is for the case where the target resource is already in the desired state.

Ah, I'm following now. Good as-is.

Comments from Reviewable

I've addressed most of the review changes. There are a few I'll have to come back to re: integration test template updates. I'm wondering if we can get the initial PR merged in so others can start using these resources & I can come back to the updates to the integration test template? Given the integration tests are functional, they just don't use the latest template.

Review status: 4 of 15 files reviewed, 25 unresolved discussions (waiting on @johlju, @mavratar, @turkeys-united, and @regedit32)

a discussion (no related file):
Previously, johlju (Johan Ljunggren) wrote…
Please add submit an issue that the old deprecated resource should be removed in a future release.

Done.

README.md, line 220 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

### xWebConfigKeyValue

Can we add deprecated to this section header?
### xWebConfigKeyValue (DEPRECATED)

Done.

README.md, line 229 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

NOTE: The **xWebConfigKeyValue** resource is deprecated and has been replaced by the **xWebConfigProperty** and **xWebConfigPropertyCollection** resources.
It may be removed in a future release.

Can we move this between the resource name section and the parameters, so it is the first the user sees? Also can we add it as a markdown quote, like this?
>**NOTE:** The **xWebConfigKeyValue** resource is deprecated and has been
>replaced by the **xWebConfigProperty** and **xWebConfigPropertyCollection**
>resources. It may be removed in a future release.

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 77 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
If this is kept as -is, then we should return all the properties in the schema.mof.

OK. Did both.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 88 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This hash table should return all properties in the schema.mof.

Done.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 154 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…
On second thought, my example assumes that the property exists.  If the property is $null then Get-WebConfigurationProperty wouldn't be able to return a TypeName.  However, with the same filterGet-WebConfiguration can, even if the property is null.  This would apply to the WebConfigPropertyCollection as well.

This is a great idea, unfortunately I don't have time to address it at the moment, & not sure if this should hold up completing this PR or whether it can be added in the future. As you've probably observed by how long it's taking me to get through these review comments, my time is becoming increasingly scarce, & I'm keen to get this resource into active use, even if it still has a few niceties to be added later.

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 230 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This seems like duplicated code of Get-TargetResource. Can we call Get-TargetResource instead an use the values returned in the hash table?

Done.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 243 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This seems like duplicated code of Get-TargetResource. Can we call Get-TargetResource instead an use the values in the returned hash table?

I'd prefer to leave this as-is, as (particularly for the following Test-TargetResource) there are quite a few conditions to test for.

DSCResources/MSFT_xWebConfigPropertyCollection/MSFT_xWebConfigPropertyCollection.psm1, line 383 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
This seems like duplicated code of Get-TargetResource. Can we call Get-TargetResource instead an use the returned hash table? Then we could skip most of the verbose messages in this function too maybe?

As above, would prefer to leave as-is.

Examples/Sample_xWebConfigProperty_Add.ps1, line 15 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Done.

Examples/Sample_xWebConfigProperty_Add.ps1, line 29 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Please add spaces around the equal sign.

Done.

Examples/Sample_xWebConfigProperty_Remove.ps1, line 14 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Done.

Examples/Sample_xWebConfigPropertyCollection_Add.ps1, line 14 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Done.

Examples/Sample_xWebConfigPropertyCollection_Add.ps1, line 24 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
We don't need this comment, since that is in the SYNOPSIS.

Done.

Examples/Sample_xWebConfigPropertyCollection_Remove.ps1, line 14 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Mandatory = $true

Should not have mandatory here if it defaults to a value. Please keep [Parameter()].

Done.

Examples/Sample_xWebConfigPropertyCollection_Remove.ps1, line 24 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
We don't need this comment, since that is in the SYNOPSIS.

Done.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 5 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Could we update this to the latest integration test template? For both integration tests.
https://github.com/PowerShell/DscResources/blob/master/Tests.Template/integration_template.ps1

Started, won't get back to this for a while as it looks like a reasonably significant change, will do when I can.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 43 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Instead of using environment variable, could we use ConfigurationData and passing that? Then the values used for the integration tests are in the sam file as the config.
See example here: https://github.com/PowerShell/SqlServerDsc/blob/dev/Tests/Integration/MSFT_SqlServerDatabaseMail.Integration.Tests.ps1
And the accompanying config: https://github.com/PowerShell/SqlServerDsc/blob/dev/Tests/Integration/MSFT_SqlServerDatabaseMail.config.ps1

As above.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 49 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…
This is probably not needed.

I agree that in a healthy DSC environment this shouldn't be necessary. In the environment I'm developing & testing this in however there is a Group Policy that regularly stops the WinRM service. I'd prefer to leave it there so these tests will run in such environments.

Tests/Integration/MSFT_xWebConfigProperty.Integration.Tests.ps1, line 73 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…

#& "$($script:DSCResourceName)_Add" -OutputPath $TestDrive

This commented out line is actually the recommended way to do this versus the Invoke-Expression above.  There's a PSSA rule for this (PSAvoidUsingInvokeExpression) that this repo isn't opted into yet.

Will have to come back to this.

Tests/Unit/MSFT_xWebConfigProperty.tests.ps1, line 91 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…

                $parameters = @{
                    WebsitePath  = 'MACHINE/WEBROOT/APPHOST'
                    Filter       = 'system.webServer/advancedLogging/server'
                    PropertyName = 'enabled'
                    Value        = 'true'
                    Ensure       = 'Present'
                }

This code is repeated several times and can be initialized above the describe block for re-use throughout the script.

Done.

Tests/Unit/MSFT_xWebConfigProperty.tests.ps1, line 223 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…

$result = Set-TargetResource @parameters

This function doesn't output anything, so no need to store it in a variable.

Done.

Tests/Unit/MSFT_xWebConfigPropertyCollection.tests.ps1, line 39 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…

                $parameters = @{
                    WebsitePath      = 'MACHINE/WEBROOT/APPHOST'
                    Filter           = 'system.webServer/advancedLogging/server'
                    CollectionName   = 'verbs'
                    ItemName         = 'add'
                    ItemKeyName      = 'verb'
                    ItemKeyValue     = 'TRACE'
                    ItemPropertyName = 'allowed'
                }

This hash table is repeated throughout, but should be initialized once in the beginning of the script

Done.

Tests/Unit/MSFT_xWebConfigPropertyCollection.tests.ps1, line 55 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…

It 'Should return the correct values' {

Since the same comparison values are referenced several times throughout the script, they can be referenced as $parameters.websitePath and $parameters.Filter. for example, instead of hard-coding each time.  Would make for easier updating in the future.

Done.

Comments from Reviewable

Review status: all files reviewed, 2 unresolved discussions (waiting on @turkeys-united)

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 154 at r7 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
@turkeys-united I'm okay with you just submitting an issue so this can be tracked. It can be resolved in another PR since it sounds like it will not be a breaking change.
@regedit32 Are you okay with that?

ok, better to have a resource that works on 90% or configuration paths then none at all.  I have the fix already for one of resources.  Once the issue is open, I should be able to fix it before next release.

Comments from Reviewable

Review status: :shipit: complete! all files reviewed, all discussions resolved

DSCResources/MSFT_xWebConfigProperty/MSFT_xWebConfigProperty.psm1, line 154 at r7 (raw file):
Previously, regedit32 (Reggie Gibson) wrote…
ok, better to have a resource that works on 90% or configuration paths then none at all.  I have the fix already for one of resources.  Once the issue is open, I should be able to fix it before next release.

Submitted issue #374 and #375.

Comments from Reviewable

Seems all review comments got solved! Merging this one. 😃

authors: codecov-io johlju mavratar msftclas regedit32 turkeys-united

repo: PowerShell/xWebAdministration


text:
Добавить логирование вызовов скриптов SikuliX в ЖР.

Добавить логирование вызовов скриптов SikuliX в ЖР.
Для упрощения расследования проблем.

Решено в 1.2.035
https://github.com/Pr-Mex/vanessa-automation/releases/tag/1.2.035

source: gharchive/issue

repo: Pr-Mex/vanessa-automation

license_type: permissive

license_source: github-api


text:
RSS Feed

Some people prefer to get notified about updates in their RSS reader.
Assign this to me.

please go ahead!

license: MIT


text:
Percent Unit?

In the upcoming plootly_js/HTML formatter I already happily reuse our newly created unit formatting methods (well I don't scale to microseconds because Erlang doesn't like that cause it apparently can't UTF8 but wel'll see about that) and then noticed that it'd be great to have same formatting for percent units (e.g. the ratio of the standard deviation) as in the console formatter.
Right now it's a private method on the console formatter, we could make it public, but that feels wrong. My idea was to create a Percent or Ratio or something unit that then encapsulates the formatting of this unit much like Count and Duration do. The weird thing would be, that I don't see any scaling happening there. We'd just always scale to percent (for now).
I still think it sort of fits into the concept of a unit... @wasnotrice what do you think? Would love to get your input here!

Ah yes I think that would be nice to add Percent. But now you make me think about naming, and about how Count and Duration aren't actually units, but really just collections of functions for converting/scaling/formatting values that represent counts or durations. That makes me want to do something like
conversion
├── count.ex
├── duration.ex
├── format.ex
├── percent.ex
└── scale.ex

This violates the parity between directories/modules that you were after in #37, but it seems a little clearer, since Percent makes sense as a conversion, but not as a unit. Unit would get split out into Scale and Format behaviours. Count and Duration would adopt Scale and Format behaviours, while Percent would adopt only Format.
What do you think?

Love it :+1:

@PragTob reorganized "Conversion" code as discussed above. Should make Percent easy. Will break plotlyjs formatter, since you were using the Common module. But now you can just use those functions on Scale/Format.

@wasnotrice will upgrade plotly_js with pleasure :)

authors: PragTob wasnotrice

repo: PragTob/benchee

license: mit

license_source: bigquery


text:
Blocks Support: Create prefect_block resource - Tests + Docs

https://www.notion.so/prefect/Design-Block-support-in-the-Terraform-Provider-ae2ea25a18864de9b51b8aa06af9486b?pvs=4
resource "prefect_block" "datadog_api_key" {
	name = "datadog-api-key"
	type = "secret"
	data = jsonencode({
		value = var.datadog_api_key
	})
}

Located in internal/provider/resources/block.go
Also, be sure to include acceptance tests and docs

/internal/provider/resources/block_test.go
/examples/resources/prefect_block

I'll pick this up for now as I'd like to learn how this part works, but feel free to reassign if needed.

ah @mitchnielsen i just saw you grabbed it, sorry man. in https://github.com/PrefectHQ/terraform-provider-prefect/pull/196 i added some foundations for a block_test.go file, so there should be some stuff for us to look at for followup PRs
i couldn't quite get this to work, i think we might be missing some logic to gracefully handle the different URL schemas between open source and cloud https://github.com/PrefectHQ/terraform-provider-prefect/issues/192

No worries at all, sounds good! And good to know.

authors: mitchnielsen parkedwards

repo: PrefectHQ/terraform-provider-prefect


text:
Added sort by bestsellers

This change improves the ps_facetedsearch module by adding the popularity sort order on categories.
Fixes https://github.com/PrestaShop/PrestaShop/issues/17136

This change is

Great !! My first PR approved.
I think is a great feature to have for the customers

Great !! My first PR approved.
I think is a great feature to have for the customers

Totally agree, if you want to go further, you can create an issue in the main repository and tells you already create a pull request https://github.com/PrestaShop/PrestaShop/issues/new?template=2_feature_request.md :)

Thanks @dgonzalez360 & @sarahdib

@dgonzalez360 , @PierreRambaud
It works very nice, but this option is not available in BO. So it is impossible to set the default sort by Bestsellers.
This is an absolutely fundamental thread now. This great functionality must be present in the backoffice as well.

This doesn't work anymore and debug mode shows the db query gets built wrongly:
[PrestaShopDatabaseException] Unknown column 'p.sales' in 'field list'

SELECT p.id_product FROM (SELECT p.id_product, p.id_manufacturer, SUM(sa.quantity) as quantity, p.condition, p.weight, p.price, p.sales FROM ps_product p LEFT JOIN ps_product_attribute pa ON (p.id_product = pa.id_product) LEFT JOIN ps_product_attribute_combination pac ON (pa.id_product_attribute = pac.id_product_attribute) LEFT JOIN ps_stock_available sa ON (p.id_product = sa.id_product AND IFNULL(pac.id_product_attribute, 0) = sa.id_product_attribute AND sa.id_shop = 1 AND sa.id_shop_group = 0 ) INNER JOIN ps_category_product cp ON (p.id_product = cp.id_product) INNER JOIN ps_category c ON (cp.id_category = c.id_category AND c.active=1) INNER JOIN ps_product_shop ps ON (p.id_product = ps.id_product AND ps.id_shop = 1 AND ps.active = TRUE) WHERE p.visibility IN ('both', 'catalog') AND c.nleft>=3 AND c.nright<=4 AND ps.id_shop='1' GROUP BY p.id_product) p GROUP BY p.id_product ORDER BY p.sales DESC LIMIT 0, 24
 at line 769 in file classes/db/Db.php
It doesn't use ps_product_sale but tries to get sales from ps_product

This doesn't work anymore and debug mode shows the db query gets built wrongly:
[PrestaShopDatabaseException] Unknown column 'p.sales' in 'field list'

SELECT p.id_product FROM (SELECT p.id_product, p.id_manufacturer, SUM(sa.quantity) as quantity, p.condition, p.weight, p.price, p.sales FROM ps_product p LEFT JOIN ps_product_attribute pa ON (p.id_product = pa.id_product) LEFT JOIN ps_product_attribute_combination pac ON (pa.id_product_attribute = pac.id_product_attribute) LEFT JOIN ps_stock_available sa ON (p.id_product = sa.id_product AND IFNULL(pac.id_product_attribute, 0) = sa.id_product_attribute AND sa.id_shop = 1 AND sa.id_shop_group = 0 ) INNER JOIN ps_category_product cp ON (p.id_product = cp.id_product) INNER JOIN ps_category c ON (cp.id_category = c.id_category AND c.active=1) INNER JOIN ps_product_shop ps ON (p.id_product = ps.id_product AND ps.id_shop = 1 AND ps.active = TRUE) WHERE p.visibility IN ('both', 'catalog') AND c.nleft>=3 AND c.nright<=4 AND ps.id_shop='1' GROUP BY p.id_product) p GROUP BY p.id_product ORDER BY p.sales DESC LIMIT 0, 24
 at line 769 in file classes/db/Db.php
It doesn't use ps_product_sale but tries to get sales from ps_product

source: gharchive/pull-request


text:
how to install Primal

Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce
Steps to reproduce the behavior.
Expected behavior
A clear and concise description of what you expected to happen.
Environment

Details that you think may affect.

Additional context
Add any other context about the problem here.

I trief to install Primal through Alby, and did not succeed.
i can write notes and can search for notes of others. However i cannot use the 'follow button' (is inactive, network problem); cannot remove my notes; cannot correct my notes;
In this way it is not useable

i tried

repo: PrimalHQ/primal-web-app


text:
Inventory Crafting & JEI

The plus button when viewing a recipe doesn't input the ingredients into the crafting grid.

Yep, i just saw this happen.
Well, if you shift click the output slot, the crafting does actually occur.  But for some reason they are invisible. Ill see if theres anything i can do

Thanks

Ill try to make sure this gets fixed now, shouldnt have closed it. Related to #107

I had to rebuild this screen, but now it has full working JEI support and more features . download and screenshot at https://minecraft.curseforge.com/projects/cyclic/files/2333207

Thanks

repo: PrinceOfAmber/Cyclic


text:
QA group

Factors in a QA variable group and puts common solr configs in that group

I had been reluctant in case solr_admin_url and solr_url varied, but I don't see any sense that will be the case, so they're now built via jina2 variables.
Thank you for catching the staging error, absolutely needed to be defined in staging group since the production value isn't defined.


text:
Display branches in the tree in the planned order; update leaf colors to separate similar shades

in this pr:

updates the tree so leaves are organized by branch in planned sequence from left to right
revises colors so that similar colors are further apart
place labels directly on top of the leaves instead of treating them as separate nodes within the network

This layout still needs some more refining (some leaves are going off the edges), but I think it's a lot more successful and we're heading in the right direction. In particular, the branches and centuries are much more accurate right now.
implementation details:

I added a x-coordinate force to draw leaves to their branch location; right now I'm using a vertical line with an increasing force based on century (earlier leaves are less strongly drawn); we could revise to an angled line if necessary
I'm drawing vertical lines on the debug mode so that you can see where the center of each branch is
labels are now placed directly over the leaves, per Gissoo's suggestion; this simplified the code substantially

testing notes
@jhimpele please review on render site for this pr https://lenape-timetree-dev-pr-123.onrender.com/

[x] confirm that leaves are more clearly separated by branch
[x] confirm that color separation is better with this branch and color order
[ ] confirm that branch order follows the desired sequence left to right

The original had a different sequence of branches...Please switch the university and resistance and resurgence sequence. But when we meet, we may want to consider the overall shape, which is less-tree like and flatter now. Switching the university and RR makes the tree flatter in the middle, where one would expect it to be tallest!
(Also, there are ghost labels visible. Is that expected?)

Here's a screenshot of https://lenape-timetree-dev-pr-123.onrender.com
on Safari....

@rlskoeser this looks great!! Everything is so much more readable (except the problem Jeff has mentioned on Safari)

updated as follows:

revised branch order agreed on in the meeting
update branch color order to match the new sequence
rename "Lands and Waters" branch to "Lands + Waters"
move 2006 Lawsuit leaf from Lands + Waters to Resistance + Resurgence
fix leaf text shadow so it is not broken on Safari (there's a Safari bug, doesn't support multiple text shadows)
adjust size of leaf glow effect

@gissoo a few items:

I think I got all the colors switched, but would appreciate a quick check through the various states to confirm
Safari has a bug, it only supports one text shadow, so I revised what I had (zero offset, larger blur); let me know if you want me to make any adjustments
The leaf glow effect was for your 40x width but we resized to half that for implementation, so I just halved all of the numbers on the drop-shadow effect  - does that sound right? does it look ok?

authors: gissoo jhimpele rlskoeser

repo: Princeton-CDH/lenape-timetree


text:
Use pipe attribute selector

Currently, Prism uses selectors like [class*="lang-"]. It works but it also selects classes like foolang-css.
That doesn’t usually matter, but there’s more correct selector which looks like this: [class|="lang"]. It selects the class lang-css but not foolang-css or even foo-lang-css!
Could we use it?

That won't work with Prism because there may be any number of classes before the lang-xxxx (or language-xxxx) class. With [class|="lang-"], elements like

 will not be selected.

authors: RunDevelopment valtlai

repo: PrismJS/prism


text:
Improved Haskell and PureScript

I made changes to PureScript according to #3006. I also made improvements to Haskell all of which trickle down to PureScript.
Haskell changes:

. is now highlighted as punctuation inside import statements, hvariables, and constants.
Hvariables and constants can now end with a '. The \b at the end of both patterns previously prevented this.
I split the operator regex into 3 regexes to make it easier to understand. I also simplified the ASCII operator regex (3).

PureScript changes:

. is now highlighted as punctuation inside import statements.
Improved ASCII operators as discussed here.
Support all UTF16 Unicode operators. This means that all Unicode operators symbols in the BMP are supported. Symbols in the astral planes are not supported because they aren't commonly used and increase the file size by a lot.

This resolves #3006.

PureScript gains a bit of weight but it's still smaller than Haskell, so it should be alright.
@toastal, this should solve your issue, right?

lgtm :+1:

authors: RunDevelopment toastal


text:
ProDOS 2.5.0a5 date and time issues

ProDOS 2.5.0a5 date and time issues

BUG

2.5
Description

This is a continuation of bug ticket #20.  Now using 2.5.0 alpha 5.
Running my test code filedate /h1/prodos gives the same result as on 2.5.0a4:
ProDOS Version 25

Creation:     d=$242d t=$0909
Modification: d=$2432 t=$0700
Legacy ProDOS 1.0 to 2.4.2 date and time:
Creation:     18-01-13 09:09
Modification: 18-01-18 07:00
ProDOS 2.5.0 date and time:
Creation:     1069-01-01 08:09
Modification: 1074-01-00 56:00

Expected Behavior

The ProDOS date and time format should be the new format.
Actual Behavior

However, we are still seeing the old format.  The output above decodes the date using the old and the new formats.  The values should for the old format are correct, the new ones are garbage.
Possible Fix

ProDOS 2.5.0 should be returning dates in the new format in this case.
Steps to Reproduce

You can run the attached filedate program within the Aztec C shell.
Run it passing in a filename on the command-line filedate foo
Compare the time and date values with those shown by CATALOG for example.

Context

Alpha testing the new 2.5.0a5 to see if the date conversion code could cause other issues.
Your Environment

Hardware:

Apple IIe Enhanced 128K
Disk ][ in slot 6
MicroDrive/Turbo in slot 7.
ProDOS8 version:
2.5.0 alpha 5
Non-Operating System release software being used:
Aztec C65 3.2

Will upload the attachment in a few moments . . .

Here is the filedate code, as a ZIPed ShrinkIt file (!)
filedate.shk.zip

Confirmed in the P8 Exerciser app that issuing ProDOS MLI $C4 GetFileInfo on legacy-date files does not auto-convert to new-date format

Fixed in 2.5.0a6

authors: JohnMBrooks bobbimanners


text:
Add search engine

It should work like #10 but for specified location.

#51

repo: Problematy/goodmap-frontend


text:
Equivalent concepts in ARCore?

Not related to this repo, but figured I might get some guidance here --  Is there any equivalent technique for placing AR objects on lat / lon coordinates in ARCore? I'm hoping to experiment with this concept but have an Android device.

Please join our slack channel for these kinds of questions =)

Can you please mention the slack channel? I need some guidance on implementing the lat/lon distance calculations using AR Core.

^^^^@MattSich @mickdee

@ProjectDent

authors: MattSich mickdee mulukalaabhisek

repo: ProjectDent/ARKit-CoreLocation


text:
More preview testing

Not working after https://github.com/ProjectPythia/cookbook-actions/pull/57

After https://github.com/ProjectPythia/cookbook-actions/pull/59 it's working!


text:
Bind Ctrl-a and Ctrl-e on macOS

FIX: Add a workaround for a bug on macOS where Ctrl-a and
Ctrl-e getting stuck at the edge of inline nodes.
Issue https://discuss.prosemirror.net/t/shortcut-ctrl-a-ctrl-e-dont-work-on-macos-with-inline-node

I didn't bind these two commands to Home and End in pcBaseKeymap because the browsers on Windows don't seem to have this bug.
(Test environment: Windows Server 2019 version 1809, Chrome 97, Firefox 96)
I'm not sure if these commands should be exported as public APIs, so I only exported them for testing.

Merged this, with some changes to export the commands and make them do the right thing inside inline nodes.

Thanks!

authors: marijnh ocavue

repo: ProseMirror/prosemirror-commands


text:
Some tweaks for usability and test

Extend wildcard search to all kinds of search targets
Add tests for wildcard search
Revert some unwanted code formatting changes inflicted by the Visual Studio dialog editor

thanks for the extra changes!
should I open a new PR?

thanks for the extra changes!
should I open a new PR?

You can merge my stuff into your branch if you like.

authors: bspratt meowcat

repo: ProteoWizard/pwiz


text:
Fix outputting retention time in Sciex scheduled transition lists

Fixed "retention time is always zero" in exported scheduled Sciex transition list (reported by Jeff)
Based on this support request:
https://skyline.ms/announcements/home/support/thread.view?rowId=63103
This was my best guess about how to fix this one.

I think this will mess up the method export logic. I would rather do
            else   // CSV
            {
                return string.Format(@",{0},{1},{2}",
                    dp,
                    ce,
                    rt);
            }

in GetOptionalColumns method. Do you know if RT has to be the second column in the csv file?

in GetOptionalColumns method. Do you know if RT has to be the second column in the csv file?

That's a good question. I must confess I don't know anything about how this works (or even how to test this). Can you fix this?

I think this will mess up the method export logic. I would rather do
            else   // CSV
            {
                return string.Format(@",{0},{1},{2}",
                    dp,
                    ce,
                    rt);
            }

in GetOptionalColumns method. Do you know if RT has to be the second column in the csv file?

Rita, this definitely fixes the old transition list export support. I don't see that it would break method export. Though, I think you need to fix the comment where you switched the code from using the "dwell" column for for retention time when the method is scheduled to using a new RT column.
            // If the ScheduledMethod flag was set assume that the Dwell time column in the
            // transition list file has retention time.
            if (ScheduledMethod)

               retentionTime = transition.Dwell;

               retentionTime = transition.Rt ?? 0;

Are you positive that this is now always correct? It seems like this fix would again make it possible to use transition.Dwell. It is also never correct to use zero for RT when it is a scheduled method.
So, I think more attention is needed here. When exactly would transition.Rt be null?

So maybe:
        // If the ScheduledMethod flag was set assume that the Dwell time column in the
        // transition list file has retention time.
        if (ScheduledMethod)
            retentionTime = transition.Rt ?? transition.Dwell;

authors: brendanx67 nickshulman rita-gwen


text:
re-enabled TestDdaSearchMsFraggerBadFasta

re-enabled TestDdaSearchMsFraggerBadFasta as I think I fixed the reliability problems
discovered that GetSystemResourceString leaks heap memory even when all resources are disposed correctly; I wasn't able to fix that so I just set the test to have its leak ignored for now; maybe a better solution would be to run GetSystemString in a separate process

Discussing this with Brendan gave me one more idea to try: caching the result of GetString. When even that didn't stop the leak, I just commented out the usage of GetSystemResourceString() in the test (so the test is short circuited without checking the error message). It still leaked, so (/facepalm) it was never GetSystemResourceString() that was the problem. Something about short circuiting this test is causing a memory leak but my dotMemory-fu is not up to the task to quickly track it down and I've spent enough time on this. Knowing it's not GetSystemResourceString() is actually comforting because it means other tests can use it without them starting to leak as well.
I can come back to it later, but @brendanx67 do you want me to leave the test disabled, or go ahead with this workaround to mute the memory leak for this test?

Should I expect to see this test leaking in some way now? Or is it completely fixed? If so, did you remove the code to silence its leak testing? I am not seeing the leak with the current branch.

I can get it to leak reliably when run in an infinite loop in pass1:
TestRunner test=TestDdaSearchMsFraggerBadFasta pass1=on pass2=off loop=0 language=en
But it eventually stabilizes after a couple dozen runs and stops leaking. This is with the GetSystemResourceString() call commented out so that can't be the cause. The leak seems to go away entirely if I use language=all - it looks like you were testing that way? Can you try with just language=en?

Ignore the bit about languages. I see it's always running all languages during pass1. So I'm only getting leaks detected intermittently in the first couple dozen runs, and it always eventually stabilizes to "no leaks".
Here's one run:
Run with some leaks

# Pass 1: Run tests multiple times to detect memory leaks.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 3.51/17.41/71.5 MB, 68/497 handles, 3 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.33/17.48/72.0 MB, 69/498 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.34/17.53/72.6 MB, 69/498 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.43/17.60/72.3 MB, 72/500 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/17.66/72.5 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/17.68/72.6 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/17.71/72.6 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/17.74/72.7 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/17.78/72.7 MB, 75/503 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/17.81/72.8 MB, 75/503 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/17.83/72.8 MB, 75/498 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/17.85/72.8 MB, 75/498 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/17.80/72.8 MB, 75/500 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (13): managed = 0.3 KB, heap = 17.5 KB, memory = 23.4 KB, user-gdi = 0, total = -1.4
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/17.84/72.9 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/17.87/72.9 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/17.91/73.0 MB, 75/500 handles, 1 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/17.96/73.0 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/17.99/73.0 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.03/73.0 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.06/73.1 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.10/73.1 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.13/73.2 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.15/73.2 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.19/73.2 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.22/73.3 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.26/73.3 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.25/73.3 MB, 75/499 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.28/73.3 MB, 75/499 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.32/73.4 MB, 75/499 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.34/73.3 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.38/73.4 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.43/73.4 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.46/73.4 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.50/73.5 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.53/73.5 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.57/73.5 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.60/73.5 MB, 75/497 handles, 2 sec.
!!! TestDdaSearchMsFraggerBadFasta LEAKED 28080 Heap bytes
# TestDdaSearchMsFraggerBadFasta deltas (25): managed = -0.1 KB, heap = 27.4 KB, memory = 21.1 KB, user-gdi = 0, total = -0.4
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.63/73.6 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.65/73.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.64/73.7 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.69/73.8 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.72/73.8 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.78/73.9 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.81/73.9 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.84/73.9 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.88/74.1 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.91/74.0 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.94/74.1 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.99/74.1 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.02/74.1 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.04/74.1 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.08/74.1 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.11/74.2 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.07/74.3 MB, 75/499 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.11/74.2 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.17/74.3 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.20/74.4 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.23/74.4 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.27/74.4 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.30/74.4 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.33/74.5 MB, 75/497 handles, 2 sec.
!!! TestDdaSearchMsFraggerBadFasta LEAKED 23945.1 Heap bytes
# TestDdaSearchMsFraggerBadFasta deltas (25): managed = -0.1 KB, heap = 23.4 KB, memory = 21.1 KB, user-gdi = 0, total = -0.3
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.37/74.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.40/74.5 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.43/74.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.47/74.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.50/74.7 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.47/74.7 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.53/74.7 MB, 75/497 handles, 1 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.56/74.7 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.60/74.8 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.66/74.9 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.69/74.9 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.72/74.9 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.77/75.0 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.80/75.1 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.84/75.1 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.87/75.1 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.90/75.2 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.92/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.95/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.91/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.95/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.01/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.05/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/20.05/75.4 MB, 75/497 handles, 2 sec.
!!! TestDdaSearchMsFraggerBadFasta LEAKED 20987.4 Heap bytes
# TestDdaSearchMsFraggerBadFasta deltas (25): managed = -0.1 KB, heap = 20.5 KB, memory = 20 KB, user-gdi = 0, total = 0
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.05/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.05/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.04/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/20.04/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/20.02/75.3 MB, 75/495 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.06/75.3 MB, 75/495 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.06/75.4 MB, 75/495 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.07/75.5 MB, 75/495 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 3 KB, memory = 8.6 KB, user-gdi = 0, total = -0.3
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.04/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.03/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.04/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/20.05/75.6 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/20.05/75.6 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.09/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.09/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.09/75.5 MB, 75/495 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 7.4 KB, memory = 4.6 KB, user-gdi = 0, total = 0

Run without leaks

# Pass 1: Run tests multiple times to detect memory leaks.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 3.51/17.41/71.2 MB, 69/497 handles, 3 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.31/17.52/71.8 MB, 70/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.33/17.57/71.7 MB, 70/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.40/17.63/72.0 MB, 73/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.48/17.70/72.2 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/17.74/72.3 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/17.78/72.3 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/17.81/72.3 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/17.83/72.4 MB, 76/503 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/17.86/72.4 MB, 76/503 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/17.86/72.4 MB, 76/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/17.89/72.5 MB, 76/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/17.84/72.5 MB, 76/500 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (13): managed = 0.3 KB, heap = 15.4 KB, memory = 32 KB, user-gdi = 0, total = -1.4
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/17.88/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/17.93/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/17.98/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.01/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.04/72.7 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.8 MB, 76/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.09/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.09/72.8 MB, 75/500 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (10): managed = 0 KB, heap = 17.1 KB, memory = 27.4 KB, user-gdi = -0.1, total = 0
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.09/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.04/72.7 MB, 75/499 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.06/72.7 MB, 75/499 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.07/72.7 MB, 75/499 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.07/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = -1.8 KB, memory = -25.1 KB, user-gdi = 0, total = -0.4
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.05/72.7 MB, 75/497 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = -4.5 KB, memory = 4.6 KB, user-gdi = 0, total = 0
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.09/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 3.7 KB, memory = 1.1 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.11/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.11/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.06/72.7 MB, 75/499 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.06/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.07/72.7 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = -6.3 KB, memory = -5.1 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 1.2 KB, memory = -1.1 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.09/72.7 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.05/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.06/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.07/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.8 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 0 KB, memory = 4.6 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 1 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 1 sec.

Annoying!


text:
Add script to handle response data

I wrote a script, and integrated atlantis, I hope that when making a network request on the iPhone, the data seen in the response-body of the proxyman is processed by the script, what should I do?

@UknowHui when you're using Atlantis, it's for previewing data, not for debugging tool.
If you want to modify the request/response, it's better to not use Atlantis, and follow the proxy-approach: Here is the guide: https://docs.proxyman.io/debug-devices/ios-device

I tried this and it worked
But this is not the result I want. In my program, there is already a script that handles response. If it is handled through the proxy script in the proxyman, it is actually wrong in my program.
What I want is that when I preview the data in Atlantis, I see the beautification after the script processing

authors: NghiaTranUIT UknowHui

repo: ProxymanApp/atlantis


text:
Should I add Wikipedia

Btw which category?

To be honest - I don't know. I'm just a regular Wikipedia user when I'm searching in my SearXNG for it. Does it have a dark theme though?

White theme
reading theme
dark theme
black theme
image dimming

Hmm, sure? I'm thinking about just ## Wikipedia section, because everyone knows what Wikipedia is.

authors: Psyhackological XXDRD

repo: Psyhackological/AAA


text:
DB migration fails upgrading from v0.5.0 Pre-Release #3 to latest develop

Product
Please check the corresponding boxes below for which products this is about.

[x] Panel
[ ] Daemon
[ ] Dockerfile(s) [Please list if so: __ ]

Type

[x] Bug or Issue
[ ] Feature Request
[ ] Enhancement
[ ] Other

What Happens

DB migration fails when upgrading from v0.5.0 Pre-Release #3 to latest develop (51c07bf1f2ec29b7c12ee5b4d8d33f9e154efcfa)
How to Reproduce

Use setup with version v0.5.0 pre3
git pull origin develop
php artisan pterodactyl:clear-services
php artisan migrate

Error Logs

  [Illuminate\Database\QueryException]
  SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'deleted_at' (SQL: alter table `servers` add `deleted_at` timestamp null)

  [Doctrine\DBAL\Driver\PDOException]
  SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'deleted_at'

  [PDOException]
  SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'deleted_at'

Currently these migrations exist on the system (database/migrations):
2016_01_23_195641_add_allocations_table.php     2016_01_23_202943_add_services.php                        2016_08_30_213301_modify_ip_storage_method.php    2016_10_23_181719_update_misnamed_bungee.php
2016_01_23_195851_add_api_keys.php              2016_01_23_203119_create_settings_table.php               2016_09_01_193520_add_suspension_for_servers.php  2016_10_23_193810_add_foreign_keys_servers.php
2016_01_23_200044_add_api_permissions.php       2016_01_23_203150_add_subusers.php                        2016_09_01_211924_remove_active_column.php        2016_10_23_201624_add_foreign_allocations.php
2016_01_23_200159_add_downloads.php             2016_01_23_203159_add_users.php                           2016_09_02_190647_add_sftp_password_storage.php   2016_10_23_202222_add_foreign_api_keys.php
2016_01_23_200421_create_failed_jobs_table.php  2016_01_23_203947_create_sessions_table.php               2016_09_04_171338_update_jobs_tables.php          2016_10_23_202703_add_foreign_api_permissions.php
2016_01_23_200440_create_jobs_table.php         2016_01_25_234418_rename_permissions_column.php           2016_09_04_172028_update_failed_jobs_table.php    2016_10_23_202953_add_foreign_database_servers.php
2016_01_23_200528_add_locations.php             2016_02_07_172148_add_databases_tables.php                2016_09_04_182835_create_notifications_table.php  2016_10_23_203105_add_foreign_databases.php
2016_01_23_200648_add_nodes.php                 2016_02_07_181319_add_database_servers_table.php          2016_09_07_163017_add_unique_identifier.php       2016_10_23_203335_add_foreign_nodes.php
2016_01_23_201433_add_password_resets.php       2016_02_13_154306_add_service_option_default_startup.php  2016_09_14_145945_allow_longer_regex_field.php    2016_10_23_203522_add_foreign_permissions.php
2016_01_23_201531_add_permissions.php           2016_02_20_155318_add_unique_service_field.php            2016_09_17_194246_add_docker_image_column.php     2016_10_23_203857_add_foreign_server_variables.php
2016_01_23_201649_add_server_variables.php      2016_02_27_163411_add_tasks_table.php                     2016_09_21_165554_update_servers_column_name.php  2016_10_23_204157_add_foreign_service_options.php
2016_01_23_201748_add_servers.php               2016_02_27_163447_add_tasks_log_table.php                 2016_09_29_213518_rename_double_insurgency.php    2016_10_23_204321_add_foreign_service_variables.php
2016_01_23_202544_add_service_options.php       2016_03_18_155649_add_nullable_field_lastrun.php          2016_10_07_152117_build_api_log_table.php         2016_10_23_204454_add_foreign_subusers.php
2016_01_23_202731_add_service_varibles.php      2016_08_30_212718_add_ip_alias.php                        2016_10_14_164802_update_api_keys.php             2016_10_23_204610_add_foreign_tasks.php

System Information
Output of uname -a:
Linux HOSTNAME 4.7.0-040700-generic #201608021801 SMP Tue Aug 2 22:03:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Output of php -v (if Panel):
PHP 7.0.12-1+deb.sury.org~xenial+1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.12-1+deb.sury.org~xenial+1, Copyright (c) 1999-2016, by Zend Technologies

Is this reproduceable?
I just went through
on 0.5.0-pre.3
composer setup
php artisan migrate
php artisan seed

On develop
composer update
php artisan migrate

without any issues.

After additional testing this appears to be a very isolated incidence, and not something that has happened to other testers on both empty and non-empty databases.
We'll keep working on getting this fixed in Discord, and if it does end up being a code issue I'll re-open this issue.

authors: DaneEveritt ET-Bent schrej

repo: Pterodactyl/Panel


text:
Changing servers per page

I was curious as to how I would go about changing the amount of servers displayed per page. I know some basic PHP and JavaScript so if you point me in the right direction I should be able to figure it out myself.

I have not read the code, but I bet it's SQL-side 'limit', so you should
look for that query.
śr., 15.03.2017, 07:08 użytkownik Ethan Gallant notifications@github.com
napisał:

I was curious as to how I would go about changing the amount of servers
displayed per page. I know some basic PHP and JavaScript so if you point me
in the right direction I should be able to figure it out myself.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Pterodactyl/Panel/issues/349, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFWMcJwoizIhOFWGYMTT5ScfROPoI6-Qks5rl4BZgaJpZM4Mdhh9
.

Here you go.

You actually want this unless you're on a pre release.

Thanks!

authors: Chomiciak DaneEveritt Volxz schrej


text:
[Feature Request] Add OpenSUSE/SLES support

CentOS "is dead" and I jumped ship to SUSE.
What I'm asking for: the title sums it up, but I want to be able to zypper install pufferpanel (install from OpenSUSE package manager) instead of building from source or other workarounds.
I would be willing to contribute to the new documentation/test an install if this gains traction.
Some things to be accomplished:

Add SUSE-compatible repo for OpenSUSE Leap and whatever that entails (rpm is signed with GPG key?..)
Add documentation on "install" page in the PufferPanel docs.

Thank you for your time.

You should just be able to take the RPM file we include in the release and install using that, without having to build from source. I'll consider adding openSUSE, but it slows down the pipeline and I have to specify exact versions. I guess it's 15.2 and 15.3 once it's not in alpha.

If someone could provide me the spec file for the currently distributed CentOS RPMs, then I would work on changing the specfile so that it fits openSUSE and put it in Factory on build.opensuse.org

authors: KaratekHD LordRalex bitrot-alpha

repo: PufferPanel/PufferPanel


text:
How to deploy your macos web with vercel =(

You can use npx pnpm install to install the packages, and then npx vite --host to start the server.

Check this https://vercel.com/changelog/projects-using-pnpm-can-now-be-deployed-with-zero-configuration

repo: PuruVJ/macos-web


text:
🛑 ArchiveBox is down

In e4b8560, ArchiveBox (https://archivebox.pxlbuzzard.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ArchiveBox is back up in da03eab.

repo: PxlBuzzard/upptime


text:
Add ffmpeg version info

I'm not sure how you feel about this, but I can't really keep track of all the different version of ffmpeg internal libraries. the "friendly name" is really useful to know.
Let me know what you think.

For ffmpeg 6.1.2. this returns "6.1.2"
For ffmpeg 7(.0.0) this returns "7.0"
For ffmpeg 7.0.2 this returns "7.0.2"
For ffmpeg 7.1(.0) this returns "7.1"

I find the alignment with the branding much easier to communicate across developers.

Wow thanks for the quick review!

repo: PyAV-Org/PyAV


text:
yaml_load should not be B5xx cryptography group

Describe the bug
The yaml_load plugin has bandit ID B506.  The 5xx group according to [1] is defined as the group for cryptography.  This plugin would be more appropriate as a type of injection B6xx
To Reproduce
n/a
Expected behavior
n/a
Bandit version

bandit 1.4.0

Additional context
Add any other context about the problem here.

I created the issue #293 for add on README the explanation for each code,
I think this could improve the new codes for contributors.

authors: ehooo ericwb

repo: PyCQA/bandit


text:
문법 오류 교정

라이선스 동의
변경해주시는 내용에 BSD 3항 라이선스가 적용됨을 동의해주셔야 합니다.
더 자세한 내용은 기여하기 문서를 참고해주세요.
동의하시면 아래 [ ]를 [x]로 만들어주세요.

[x] 기여하기 문서를 확인하였으며, 본 PR 내용에 BSD 3항 라이선스가 적용됨에 동의합니다.

관련 이슈 번호
이 Pull Request와 관련있는 이슈 번호를 적어주세요.
이슈 또는 PR 번호 앞에 #을 붙이시면 제목을 바로 확인하실 수 있습니다. (예. #999 )

이슈 번호: #446

PR 종류
이 PR에 해당되는 종류 앞의 [ ]을 [x]로 변경해주세요.

[x] 오탈자를 수정하거나 번역을 개선하는 기여
[ ] 번역되지 않은 튜토리얼을 번역하는 기여
[ ] 공식 튜토리얼 내용을 반영하는 기여
[ ] 위 종류에 포함되지 않는 기여

PR 설명
이 PR로 무엇이 달라지는지 대략적으로 알려주세요.
문법 오류를 수정헸습니다.

looks good to me

이 PR이 적용된 빌드( https://github.com/PyTorchKorea/tutorials-kr/commit/0a80f26e01fa3014e647cddb78b461fd0a745071 )가 완료되었습니다.
https://tutorials.pytorch.kr/advanced/cpp_autograd.html 에서 빌드 결과를 확인해보세요. :)

authors: 9bow Jangorithm hyoyoung

repo: PyTorchKorea/tutorials-kr


text:
update setup

allowing to simply install the package + test

@williamFalcon ^^

@williamFalcon mind add the missing files? ^^