Upgrade to HQRM, New Resource, Features and Fixes - Fixes #53

This PR addresses:

Fixes #58
Fixes #57
Fixes #56
Fixes #54
Fixes #53
Fixes #51
Fixes #47
Fixes #35
Fixes #24
Fixes #22
Fixes #20

This PR contains the following changes:

Updated to meet HQRM guidelines.
Moved all strings into localization files.
Fixed examples to import xStorage module.
Fixed Readme.md layout issues.
xWaitForDisk:

Added support for setting DriveLetter parameter with or without colon.
MOF Class version updated to <IP_ADDRESS>.

xWaitForVolume:

Added new resource.

xStorageCommon:

Added helper function module.

xDisk:

Added validation of DriveLetter parameter.
Added support for setting DriveLetter parameter with or without colon.
Removed obfuscation of drive/partition errors by eliminating try/catch block.
Improved code commenting.
Reordered tests so they are in same order as module functions to ease creation.
Added FSFormat parameter to allow disk format to be specified.
Size or AllocationUnitSize mismatches no longer trigger Set-TargetResource because these values can't be changed (yet).
MOF Class version updated to <IP_ADDRESS>.

xMountImage (Breaking Change):

Removed Name parameter (Breaking Change)
Added validation of DriveLetter parameter.
Added support for setting DriveLetter parameter with or without colon.
MOF Class version updated to <IP_ADDRESS>.
Enabled mounting of VHD/VHDx/VHDSet disk images.
Added StorageType and Access parameters to allow mounting VHD and VHDx disks as read/write.

xDiskAccessPath:

Added new resource.

As usual, I apologize in advance to any reviewers for the size of this PR :grin: and also any mistakes I have made (no doubt there are a few).

This change is

Hi @PlagueHO, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

Reviewed 4 of 45 files at r1.
Review status: 4 of 45 files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

README.md, line 16 at r1 (raw file):

the latest version of PowerShell (v4.0,

The latest version is now 5.0

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 38 at r1 (raw file):

if required

Do you mean 'if required' or 'if provided'?
Same in Set

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 78 at r1 (raw file):

-ErrorAction SilentlyContinue

if we continue on error $disk may be $null and then we'll have problems when the return value tries to access $disk.Number. Also, since we are silently continuing there will be no indication of where the problem is coming from.
NOTE: I just realized this is coming from the previous version of the code, so if this is too time consuming to fix now we should open an issue. There are more instances below.

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 213 at r1 (raw file):

            $disk | Initialize-Disk `
                -PartitionStyle "GPT"
        } # "RAW"

add 'break' at the end of each script block so that control flow does not fall into next case.

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 340 at r1 (raw file):
Quoted 5 lines of code…
>                 Write-Verbose -Message ( @(
>                         "$($MyInvocation.MyCommand): "
>                         $($LocalizedData.FileSystemFormatMismatch -f `
>                             $DriveLetter,$fileSystem,$FSFormat)
>                     ) -join '' )

This is more of a wish-list item for future coding: consider writing a utility function to prepend the invocation info to the message.
Not only this would make the code easier to read, but also would make implementing changes to the format of the message a lot easier.

Comments from Reviewable

Reviewed 2 of 45 files at r1.
Review status: 6 of 45 files reviewed at latest revision, 7 unresolved discussions, some commit checks failed.

DSCResources/MSFT_xDisk/en-us/MSFT_xDisk.strings.psd1, line 4 at r1 (raw file):

is
typo(?): remove "is"

DSCResources/MSFT_xDisk/en-us/MSFT_xDisk.strings.psd1, line 21 at r1 (raw file):

initialised
initialized

Comments from Reviewable

Review status: 2 of 45 files reviewed at latest revision, 7 unresolved discussions.

README.md, line 16 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> >  the latest version of PowerShell (v4.0,
>
> The latest version is now 5.0

Oh too true.
I'd actually argue that this whole section doesn't need to be included at all (it isn't in other resources). DSC isn't supported on anything under WMF4.0 anyway. Would you object to the requirements section being removed?

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 38 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > if required
>
> Do you mean 'if required' or 'if provided'?
>
> Same in Set

I did mean 'if required'. But agree this isn't clear. I have changed this to clarify it.

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 78 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> >  -ErrorAction SilentlyContinue
>
> if we continue on error $disk may be $null and then we'll have problems when the return value tries to access $disk.Number. Also, since we are silently continuing there will be no indication of where the problem is coming from.
>
> NOTE: I just realized this is coming from the previous version of the code, so if this is too time consuming to fix now we should open an issue. There are more instances below.

I'll take a look and see what will be required to fix this now. I'll spend a bit of time on this over the weekend.

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 213 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> add 'break' at the end of each script block so that control flow does not fall into next case.

Done. Good catch. Also done in xDiskAccessPath

DSCResources/MSFT_xDisk/MSFT_xDisk.psm1, line 340 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> >                 Write-Verbose -Message ( @(
> >                         "$($MyInvocation.MyCommand): "
> >                         $($LocalizedData.FileSystemFormatMismatch -f `
> >                             $DriveLetter,$fileSystem,$FSFormat)
> >                     ) -join '' )
>
> This is more of a wish-list item for future coding: consider writing a utility function to prepend the invocation info to the message.
>
> Not only this would make the code easier to read, but also would make implementing changes to the format of the message a lot easier.

Very good point! I'll keep this in mind and ensure I include it in future updates.

DSCResources/MSFT_xDisk/en-us/MSFT_xDisk.strings.psd1, line 4 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> >  is
> typo(?): remove "is"

Done.

DSCResources/MSFT_xDisk/en-us/MSFT_xDisk.strings.psd1, line 21 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > initialised
> initialized

Sorry, slipped back into en-nz . Good catch. Fixed.

Comments from Reviewable

Reviewed 3 of 45 files at r1.
Review status: 5 of 45 files reviewed at latest revision, 2 unresolved discussions.

README.md, line 16 at r1 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
> Oh too true.
>
> I'd actually argue that this whole section doesn't need to be included at all (it isn't in other resources). DSC isn't supported on anything under WMF4.0 anyway. Would you object to the requirements section being removed?

Yup, we should remove it. Thanks!

DSCResources/MSFT_xMountImage/MSFT_xMountImage.psm1, line 54 at r1 (raw file):

[Microsoft.PowerShell.Cmdletization.GeneratedTypes.DiskImage.StorageType]

Why is this needed? Thanks!

Comments from Reviewable

Reviewed 7 of 45 files at r1, 3 of 5 files at r2.
Review status: 15 of 45 files reviewed at latest revision, 6 unresolved discussions.

DSCResources/MSFT_xWaitForDisk/en-us/MSFT_xWaitForDisk.strings.psd1, line 10 at r2 (raw file):

Tetting
Testing

DSCResources/StorageCommon/StorageCommon.psm1, line 14 at r2 (raw file):

#region localizeddata
if (Test-Path "${PSScriptRoot}${PSUICulture}")
{

Quoted 4 lines of code…
>     Import-LocalizedData `
>         -BindingVariable LocalizedData `
>         -Filename StorageCommon.strings.psd1 `
>         -BaseDirectory "${PSScriptRoot}\${PSUICulture}"

> }
> else
> {
Quoted 5 lines of code…
>     #fallback to en-US
>     Import-LocalizedData `
>         -BindingVariable LocalizedData `
>         -Filename StorageCommon.strings.psd1 `
>         -BaseDirectory "${PSScriptRoot}\en-US"

> }
> #endregion
Adding to the wish list :) - We should encapsulate this in a common function that can be used by all tests that have localized data

DSCResources/StorageCommon/StorageCommon.psm1, line 97 at r2 (raw file):

Test

Minor: The Test verb usually indicates a boolean return value (instead of throwing or returning a normalized value).
Since this is an internal module (not user visible), this is not the biggest priority

DSCResources/StorageCommon/StorageCommon.psm1, line 112 at r2 (raw file):

^([A-Za-z]{1})[:]?$

Minor: {1} and [] are redundant:  ^([A-Za-z]):?$

Comments from Reviewable

Reviewed 9 of 45 files at r1.
Review status: 23 of 45 files reviewed at latest revision, 10 unresolved discussions.

Tests/Integration/MSFT_xDisk.Integration.Tests.ps1, line 44 at r2 (raw file):

Unsupported OS type for testing

We should output this a verbose message
(same for other integration tests)

Tests/Integration/MSFT_xDisk.Integration.Tests.ps1, line 52 at r2 (raw file):

Break

return?
(same for other integration tests)

Tests/Integration/MSFT_xDisk.Integration.Tests.ps1, line 60 at r2 (raw file):

BeforeAll

Minor - Instead of setting the scenario in BeforeAll, I'd use Context with a brief description of the scenario: Context 'When adding a drive letter to a disk'.
This gives the reader a better idea of what the test is doing and the output of Pester will also give similar info.
(same for other integration tests)

Tests/Integration/MSFT_xDiskAccessPath.Integration.Tests.ps1, line 23 at r2 (raw file):

try
{
    # Ensure that the tests can be performed on this computer

There seems to be a lot of commonality between some integration tests. Consider refactoring it into a common module.

Comments from Reviewable

Reviewed 8 of 45 files at r1.
Review status: 31 of 45 files reviewed at latest revision, 14 unresolved discussions.

Tests/Integration/MSFT_xMountImage_ISO.Integration.Tests.ps1, line 1 at r2 (raw file):

an basic
a basic

Tests/Integration/MSFT_xMountImage_ISO.Integration.Tests.ps1, line 2 at r2 (raw file):

fil emust

file must

Tests/Integration/MSFT_xMountImage_ISO.Integration.Tests.ps1, line 4 at r2 (raw file):

# in the same folder as this file. The ISO fil emust be a valid ISO file that can
# normally be mounted. If the test.iso file is not found the tests will not run.

We should clarify this comment. When I read it I am not sure if this is something I need to do before running the test (no) or if the test sets this up (yes).

Tests/Integration/MSFT_xWaitForVolume.config.ps1, line 1 at r2 (raw file):

[PSObject]

Minor: no need to use PSObject, the hashtable would work as well

Comments from Reviewable

Reviewed 7 of 45 files at r1.
Review status: 32 of 45 files reviewed at latest revision, 14 unresolved discussions.

Comments from Reviewable

I reviewed all files but the new resources, which should be reviewed by @kwirkykat, @TravisEz13, @KarolKaczmarek, @mbreakey3, @HemantMahawar, @grayzu

Review status: 32 of 45 files reviewed at latest revision, 18 unresolved discussions.

DSCResources/MSFT_xDiskAccessPath/MSFT_xDiskAccessPath.psm1, line 85 at r2 (raw file):

    # Prepare the AccessPath used in the CIM/WMI query (replaces '\' with '\\')
    $queryAccessPath = $AccessPath -replace '\\','\\'

does it actually do anything?

DSCResources/MSFT_xDiskAccessPath/MSFT_xDiskAccessPath.psm1, line 240 at r2 (raw file):

                    "$($MyInvocation.MyCommand): "
                    $($LocalizedData.CreatingPartitionMessage `
                        -f $DiskNumber,"$($Size/1kb) kb")

Technically we should display KB since those will be kilobytes, not kilobits.

DSCResources/MSFT_xDiskAccessPath/en-us/MSFT_xDiskAccessPath.strings.psd1, line 23 at r2 (raw file):

    AccessPathNotFoundMessage = A volume assigned to access path '{0}' was not found.
    SizeMismatchMessage = Volume assigned to access path '{0}' has size {1}, which does not match expected size {2}.
    AllocationUnitSizeMismatchMessage = Volume assigned to access path '{0}' has allocation unit size {1} kb does not match expected allocation unit size {2} kb.

KB here as well

Examples/Sample_InitializeDataDiskWithAccessPath.ps1, line 11 at r2 (raw file):

    Node localhost
    {
        xWaitforDisk Disk2

Can we add sample for xWaitForVolume as well?

Comments from Reviewable

@KarolKaczmarek, @narrieta - I think I've addressed everything. But I also made some additional changes and fixes that were picked up in xDisk when I added some additional unit tests.

Review status: 14 of 45 files reviewed at latest revision, 18 unresolved discussions.

README.md, line 16 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> Yup, we should remove it. Thanks!

Done.

DSCResources/MSFT_xDiskAccessPath/MSFT_xDiskAccessPath.psm1, line 85 at r2 (raw file):
Previously, KarolKaczmarek (Karol Kaczmarek) wrote…
> does it actually do anything?

Yes - it does. :smile: The first parameter is a RegEx so the backslash is actually escaped. The second parameter is not a RegEx so does not need to be escaped. So the comment on the previous line is correct (replaces '\' with '\\')

DSCResources/MSFT_xDiskAccessPath/MSFT_xDiskAccessPath.psm1, line 240 at r2 (raw file):
Previously, KarolKaczmarek (Karol Kaczmarek) wrote…
> Technically we should display KB since those will be kilobytes, not kilobits.

Fixed (and all the other occurrences).

DSCResources/MSFT_xDiskAccessPath/en-us/MSFT_xDiskAccessPath.strings.psd1, line 23 at r2 (raw file):
Previously, KarolKaczmarek (Karol Kaczmarek) wrote…
> KB here as well

Done.

DSCResources/MSFT_xMountImage/MSFT_xMountImage.psm1, line 54 at r1 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > [Microsoft.PowerShell.Cmdletization.GeneratedTypes.DiskImage.StorageType]
>
> Why is this needed? Thanks!

It is actually because $diskImage.StorageType contains an integer but casting it to an enum  of type [Microsoft.PowerShell.Cmdletization.GeneratedTypes.DiskImage.StorageType] will cause the enum string to be returned (which is what the Get-TargetResource must return).

DSCResources/MSFT_xWaitForDisk/en-us/MSFT_xWaitForDisk.strings.psd1, line 10 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > Tetting
> Testing

Fixed + all other occurrences of this misspelling.

DSCResources/StorageCommon/StorageCommon.psm1, line 14 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > #region localizeddata
> > if (Test-Path "${PSScriptRoot}\${PSUICulture}")
> > {
> >     Import-LocalizedData `
> >         -BindingVariable LocalizedData `
> >         -Filename StorageCommon.strings.psd1 `
> >         -BaseDirectory "${PSScriptRoot}\${PSUICulture}"
> > }
> > else
> > {
> >     #fallback to en-US
> >     Import-LocalizedData `
> >         -BindingVariable LocalizedData `
> >         -Filename StorageCommon.strings.psd1 `
> >         -BaseDirectory "${PSScriptRoot}\en-US"
> > }
> > #endregion
>
> Adding to the wish list :) - We should encapsulate this in a common function that can be used by all tests that have localized data

Good point. I'll add this to the list of things I'll implement in the next round :smile:

DSCResources/StorageCommon/StorageCommon.psm1, line 97 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > Test
>
> Minor: The Test verb usually indicates a boolean return value (instead of throwing or returning a normalized value).
>
> Since this is an internal module (not user visible), this is not the biggest priority

Good point. I'll raise this as a separate issue to be repaired. Same goes for Test-AssignPath I expect

DSCResources/StorageCommon/StorageCommon.psm1, line 112 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > ^([A-Za-z]{1})[:]?$
>
> Minor: {1} and [] are redundant:  ^([A-Za-z]):?$

Nice catch! Fixed.

Examples/Sample_InitializeDataDiskWithAccessPath.ps1, line 11 at r2 (raw file):
Previously, KarolKaczmarek (Karol Kaczmarek) wrote…
> Can we add sample for xWaitForVolume as well?

There was one already in Sample_xMountImage_MountVHD.ps1. But I've added another to Sample_xMountImage_MountISO.ps1 (I've corrected the name of this file as well).
I didn't think it made much sense as an example in it's own right. But I could add specific xWaitForVolume examples if you think it'll help.

Tests/Integration/MSFT_xDisk.Integration.Tests.ps1, line 44 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > # Unsupported OS type for testing
> We should output this a verbose message
>
> (same for other integration tests)

Good point - done.

Tests/Integration/MSFT_xDisk.Integration.Tests.ps1, line 52 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> >  Break
>
> return?
>
> (same for other integration tests)

In this the break will do the same thing as the return, but I've changed it anyway because a return is much clearer.

Tests/Integration/MSFT_xDisk.Integration.Tests.ps1, line 60 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > BeforeAll
>
> Minor - Instead of setting the scenario in BeforeAll, I'd use Context with a brief description of the scenario: Context 'When adding a drive letter to a disk'.
>
> This gives the reader a better idea of what the test is doing and the output of Pester will also give similar info.
>
> (same for other integration tests)

Good suggestion. Done.

Tests/Integration/MSFT_xDiskAccessPath.Integration.Tests.ps1, line 23 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> There seems to be a lot of commonality between some integration tests. Consider refactoring it into a common module.

Ok. Done.

Tests/Integration/MSFT_xMountImage_ISO.Integration.Tests.ps1, line 1 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > an basic
> a basic

Done.

Tests/Integration/MSFT_xMountImage_ISO.Integration.Tests.ps1, line 2 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > fil emust
>
> file must

Done.

Tests/Integration/MSFT_xMountImage_ISO.Integration.Tests.ps1, line 4 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> We should clarify this comment. When I read it I am not sure if this is something I need to do before running the test (no) or if the test sets this up (yes).

I've tried to clarify this.

Tests/Integration/MSFT_xWaitForVolume.config.ps1, line 1 at r2 (raw file):
Previously, narrieta (Norberto Arrieta) wrote…
> > [PSObject]
>
> Minor: no need to use PSObject, the hashtable would work as well

Good point. Fixed.

Comments from Reviewable

@kwirkykat , @narrieta , @KarolKaczmarek - are you guys waiting on anything from me with this one? 😁
I'm looking at moving on to working through the issues/HQRM on some of the other DSC modules so just trying to get a few of these PR's closed off before I get started. Cheers!

@plagueho : Nothing on my side; I've ack'ed all your replies. Thanks for the update.

Review status: 14 of 46 files reviewed at latest revision, 4 unresolved discussions.

Comments from Reviewable

Reviewed 15 of 48 files at r1, 1 of 5 files at r2, 33 of 33 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

@PlagueHO @kwirkykat Looks good on my side either 👍

Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.

README.md, line 340 at r3 (raw file):

Contributing

Duplicate Contributing section

Comments from Reviewable

Thank you for reviewing! Thanks @KwirkyKat - fixed the Contributing problem.

Review status: 45 of 46 files reviewed at latest revision, 1 unresolved discussion.

README.md, line 340 at r3 (raw file):
Previously, kwirkykat (Katie Keim) wrote…
> Duplicate Contributing section

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Adding CORS parameters

Thanks for the great docker image!
I needed CORS in a deployment so I added HTTP_CORS_ALLOW_ORIGIN & renamed HTTP_CORS_ENABLE -> HTTP_CORS_ENABLED per https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-http.html
I'm not sure about the default values but I tested in google container engine & was able to run CORS requests.

Awesome. Can you update documentation as well?

This will be made available when a new Elasticsearch version is released. Thank you @williamleferrand


What has changed
Long live SSDC.
How to test?
Do the make up thing.
Links
Trello: https://trello.com/c/o4f8qi8O

 Generic Survey - sprint zero work - Clone ExceptionManager & UAC-QID Service Census repos -> SSDC (5)

Looks good to me 👍  There's some mention of census in the README that could probably be removed too?


Cannot start nuxt:  Cannot find module

Hey Teranode, thank you I appreciate your work 🤙
After your recent update, removing pinia I cannot start my nuxt application.
Maybe I'm missing something but I tried with yarn and npm.
Both same error
 Cannot start nuxt:  Cannot find module<EMAIL_ADDRESS>Please verify that the package.json has a valid "main" entry
with yarn i get this error
Cannot start nuxt:  Cannot read properties of undefined (reading 'push')   node_modules/@nuxtjs-alt/auth/dist/module.mjs:614:24

are you using nuxt rc.4 or rc.5?

I was using rc.4

use rc.5 the second error pertains to how the middleware is handled.

thank you :)


Set up GitHub pages for this repository

Setting up GitHub pages in this repository from the main branch and update the description with the proper website link

this have been done, here is the link https://mats481.github.io/homepage/


moving to alpha2

What
Removing all the kpt.dev/alpha1 and replacing them with kpt.dev/alpha2
Testing
unit test and e2e tests executed
Closes #1645

I agree, this doesn't block this PR.
On Fri, Apr 23, 2021, 4:13 PM Mike Borozdin @.***>
wrote:

@.**** commented on this pull request.
In internal/testutil/testdata/updateMergeConflict/Kptfile
https://github.com/GoogleContainerTools/kpt/pull/1803#discussion_r619536760
:

@@ -1,4 +1,4 @@
-apiVersion: kpt.dev/v1alpha1
+apiVersion: kpt.dev/v1alpha2

I want to make sure we understand the scope of what is deleted.
helloworld-set folder is deleted but it seems like there are no tests
failing. That leads me to believe that this test data was not used in any
of the current tests, just something that needed to be cleaned up for a
while.
We might argue that whenever we deleted the test that was using this test
data that we might have lost some coverage, but that's not related to this
change.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/GoogleContainerTools/kpt/pull/1803#discussion_r619536760,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6YIPZDZIKYHIT2NKWMG5TTKH5IRANCNFSM43N2LWZQ
.


Brewery Info does not return all values

According to the docs a request to /v4/brewery/info/BREWERY_ID returns a lot more fields than this library currently supports. I've created a list of the fields implemented vs. the fields currently supported

[x] ID
[x] Name
[x] Slug
[x] Logo
[x] Country
[x] Active
[x] Location
[ ] brewery_in_production
[ ] is_independent
[ ] claimed_status
[ ] beer_count
[x] contact
[x] brewery_type
[x] brewer_type_id
[ ] rating
[ ] brewery_description
[ ] owners
[ ] media
[ ] beer_list

PRs welcome. I don't remember if I didn't add those fields because I didn't need them, or if they weren't present when I started writing this package.

I updated the checklist. Only a few more to go. ;-)

Thank you for your help!


Do you plan to add some DI framework as official module ?

Now, we use the guice or spring is more difficult, and having some compatibility problem. so if official can integrating guice or spring will more effective

No, not in the near future.
This being said, HK2 is already included in Dropwizard due to Jersey.

#2148  maybe will  use guice instad of hk2


Re-organization roadmap for OSSU CS

Continuing discussion from #421 and #418. Will add my thoughts later.

I just want to offer some feedback. I believe that the Software Construction courses from UBC are severely lacking in effectiveness. The first one varied between good and mediocre. The second is literally one of the worst learning experiences I've ever had. The instructors race through topics and somehow expect students to understand the advanced use cases of the patterns they barely explained. Then to make matters worse, they expect students to have an insane command over Java to complete the final project with requirements nowhere near reflecting that of the poor instruction given. As someone who has programmed for years in many different languages, I have to believe there is a better course offering available.

I appreciate this feedback. I have mixed feelings about UBC Software
Construction.
I will start with the positive: the course exists for a good reason, which
is to expose students to the painful reality of trying to be productive in
an unfamiliar codebase written in an unfamiliar language that favors a
convoluted coding style. Feeling a little overwhelmed is part of that
experience.
What I don't like is that "making students feel overwhelmed" (on purpose)
is not really relevant to a computer science education. It's more like job
training, which should be done by companies, not by us.
What would be relevant is an in depth analysis of (1) the semantics of
object oriented programming; (2) the design process for large-scale
software, where decisions are made about the types needed by the system.
(1) is needed because traditional object-oriented programming is
complicated to describe mathematically, which in practice leads to lots of
indirection and makes it difficult to reason about. But, it is very common
and useful in some scenarios, so it needs to be understood.
(2) is needed because students of CS, regardless of whether they will go on
to be industrial programmers, should develop a robust understanding of how
to scale the systematic design process (learned in the "How to Code"
series) beyond a single module.
The Programming Languages course (mostly Part C, if I remember correctly)
goes into some greater depth on the design process, but still only on the
level of a single module (i.e. the types of functions: parametric
polymorphism vs. subtyping polymorphism). We need the same thing applied to
a system of cooperating modules, discussed explicitly and systematically.
All of this is to say that I want to replace Software Construction, and
there are many options for doing so superficially. At least one of the
alternatives I remember trying out was just as bad (I think it was the UC
San Diego Java course). But if we're just doing a superficial replacement,
it's not clear what the benefit will be.
I have so far not found what I'm looking for. That's why I want us to
design our own courses using publicly available materials (e.g. academic
papers) as sources. But this is a supermassive undertaking...
On Mon, Apr 30, 2018, 11:46 PM Chris Dziewa<EMAIL_ADDRESS>wrote:

I just want to offer some feedback. I believe that the Software
Construction courses from UBC are severely lacking in effectiveness. The
first one varied between good and mediocre. The second is literally one of
the worst learning experiences I've ever had. The instructors race through
topics and somehow expect students to understand the advanced use cases of
the patterns they barely explained. Then to make matters worse, they expect
students to have an insane command over Java to complete the final project
with requirements nowhere near reflecting that of the poor instruction
given. As someone who has programmed for years in many different languages,
I have to believe there is a better course offering available.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ossu/computer-science/issues/422#issuecomment-385592611,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFbnYidY3gFv46N2uALyINF38MCqyjc2ks5tt9qqgaJpZM4PSEb8
.

Thank you for your response! I really wanted to like the courses because I thought the approach was unique and because the subject matter was interesting and important. It seems that the course suffers from poor execution. Perhaps they were a bit overambitious to try to cover so much in such a short time frame.
Having control over course content creation would be awesome. It reminds me of what free code camp has achieved. But yes, definitely a massive undertaking requiring massive support.
Hope to see this project gain more traction because it is awesome so far.

@andrewtcooper I'm enrolled in Software Constructio but I didn't get an email about that, and I can't find any notice within the course about a price increase to $9. Where are you getting that information?

@hanjiexi I should have clarified, the Data Abstraction course is still free (for now) but the Object Oriented Design course is now showing as costing $9 to audit. There are other courses in the OSSU curriculum that are also now showing as costing $9 to audit, but I can't remember which ones off the top of my head.  See screenshot: https://imgur.com/HMKVaos

@hanijiexi
A couple ideas I think should be pursued:

Online and offline: ... students could meet in physical study groups ...
Formal organizational structure
Mentor system
More active, less passive cirriculum (always a good thing)

I also think it's important to increase communication between students on similar pathways. There could be a system designed specifically for the purpose of grouping people together, and prompting their communication.
Even in online courses for actual credit, online chatter can be low unless it's prompted.  I think some icebreakers might be needed :). Anything to rally people together would be a step in the right direction IMO.
On a side note,
I think more programming languages is better than one.  How can you find your favorite musical instrument if you only try one?  Why force everyone to use only a Swiss army knife to build everything?
Metaphors aside, might be more worthwhile to spend time on the other great ideas you have !

Thank you all to your effort that make such thing exist.
I have two question:
1- How can I helping you?
2- When you will to finish the v9?


AC name type formula bad

Under the DNS notion, see http://stackoverflow.com/questions/106179/regular-expression-to-match-dns-hostname-or-ip-address for a reference on matching. Current spec is not a valid match, even if you exclude international extensions.

I don't see it - do you have an example of an invalid name DNS name that
this regex matches?
On Wed, May 6, 2015 at 9:29 AM, Walter Stanish<EMAIL_ADDRESS>wrote:

Under the DNS notion, see
http://stackoverflow.com/questions/106179/regular-expression-to-match-dns-hostname-or-ip-address
for a reference on matching. Current spec is not a valid match, even if you
exclude international extensions.
—
Reply to this email directly or view it on GitHub
https://github.com/appc/spec/issues/384.

Where any part of the domain is over 64 characters?

Yeah, OK.  My opinion is that length validation makes an already complex
regex way more complicated.  Kubernetes does length validation out of band
from regex checking.  But as you point it out, we also don't handle
individual over-long tokens, just total length.  Thanks, will file a bug
On Wed, May 6, 2015 at 10:07 AM, Walter Stanish<EMAIL_ADDRESS>wrote:

Where any part of the domain is over 64 characters?
—
Reply to this email directly or view it on GitHub
https://github.com/appc/spec/issues/384#issuecomment-99539425.

We don't actually say anywhere in the spec that an AC Name Type must be a valid DNS name, it's just recommended that they are for discovery (which is not mandatory). Let's address the length in #341.


How to install a forked version of razzle or HEAD / branch?

I want to use the HEAD of the next branch for our project. But I'm having a really hard time getting it installed. Normally, I would use a a git commit url to install the version I want but this not working. This might be because it uses the concept of workspaces. Anybody have an idea?

@mschipperheyn How about `yarn add https://github.com/jaredpalmer/razzle#master

yarn add https://github.com/jaredpalmer/razzle#next
yarn add v1.10.1
[1/4] 🔍  Resolving packages...
error Can't add undefined: invalid package version undefined.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

@mschipperheyn There's no next branch in razzle git repo.

@revskill10 https://github.com/jaredpalmer/razzle/tree/next Perhaps I'm not getting it


[WFLY-5381] Fix pom.xml jpda profile and add ability to specify additional surefire forked JVM args via command line

JIRA: https://issues.jboss.org/browse/WFLY-5381

Linux with security manager Build 3108 outcome was FAILURE using a merge of abf069ea14463358fb961c3e10a2ad5f26af01a0
Summary: Exit code 1 (new) Build time: 00:00:50

Linux Build 8274 outcome was FAILURE using a merge of abf069ea14463358fb961c3e10a2ad5f26af01a0
Summary: Exit code 1 Build time: 00:01:08

Windows Build 3309 outcome was FAILURE using a merge of abf069ea14463358fb961c3e10a2ad5f26af01a0
Summary: Exit code 1 Build time: 00:01:55


Web-component properties casing are treated like ordinary element attributes

Describe the bug
I'm not sure if this is expected behavior...
I have a web-component that accepts a camelCase property. When consuming the web-component and setting its prop, the generated code lowercases the property.
What I understand is that web-components have different code generation than ordinary elements. By default, the attributes are passed as properties if no directives are provided.
However, I think the property names are being lowercased as if they were ordinary element attributes.
The behavior is also a bit weird with constant props, as they are optimized as attributes in the template string, even though they are being passed to a web-component.
I found out I can pass the property as kebab-case and the output will be transformed to camelCase, but that messes up the component types.
Your Example Website or App
https://playground.solidjs.com/anonymous/1003943b-a363-4e73-b3af-6b1c1e8fdd15
Steps to Reproduce the Bug or Issue

Open playground link.
Check output tab (client side mode)

This code does not really run anything, the point to see the output code.
Expected behavior
I expected that when declaring a web-component in JSX, the properties without directives (regardless if they are constants or expression) would be passed down to the web-component element as if they were properties, not attributes, and that the prop casing would be preserved.
Screenshots or Videos
No response
Platform

OS: Linux
Browser:Chrome
Version: 114

Additional context
No response

Where we landed here was the result of conversations with the community around how to handle this and ultimately came to a place that I'm not sure is the best in hindsight but that we would handle things as as properties but that we would convert dash case to camelCase. Interestingly we using to do straight pass through but I think it caused inconsistencies when output as HTML.
The problem is HTML isn't case sensitive so the choice of passing properties without a prefix is awkward in general. I'm gathering that is why Lit defaults to attributes even if it is sort of not the best default. That being said I'm also not sure how useful the HTML compat is because you'd have to serialize the value to a string in that case anyway and without manual intervention I'm not sure you are going to get what you want.
So sort of awkward place always forcing the prop: prefix. I suppose we could inspect the value or looks at the component prototype and make a decision but that is also a bit inconsistent. I'm open to revisiting this for sure but what you have have witnessed is "by design" currently.


Let's add Berenschot to the Partners section (I suppose non-paying for now)

We may also need to add Berenschot to the reel on etmodel, but I am not sure this is relevant for non-paying partners.
See https://github.com/quintel/etcentral/issues/113

Duplicate of https://github.com/quintel/etcentral/issues/113


Remove duplicate .gitignore lines

Following this checklist to help us incorporate your
contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed
for the change (usually before you start working on it).  Trivial changes like typos do not
require a JIRA issue.  Your pull request should address just this issue, without
pulling in other changes.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [MENFORCER-XXX] - Fixes bug in ApproximateQuantiles,
where you replace MENFORCER-XXX with the appropriate JIRA issue. Best practice
is to use the JIRA issue title in the pull request title and in the first line of the
commit message.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Run mvn clean verify to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

[ ] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

[ ] In any other case, please file an Apache Individual Contributor License Agreement.

Since travis is already removed, I've left what was also in this PR (removing duplicated lines from gitignore)

Since travis is already removed, I've left what was also in this PR (removing duplicated lines from gitignore)


Problem with GetSection().AsEnumerable(). It returns additional element.

I have some records in config like this:
"Option": [ "A", "B"],
Then if i try to get value:
_configuration.GetSection("Option").AsEnumerable()
I receive collection with 3 items, and collection starts with null value element

This is by-design. The first element is the "root", which is currently null. If the root is always empty, then it can be skipped with Skip(1).


Simple authorization support

At the highest level, my goal is for different hologram users to have different access to different roles.
I don't know of the best way to do this, but off the top of my head, we could have a custom LDAP property that lists ARNs of roles the particular user is allowed to assume. Ideally the system would also be group-aware, and a user's access would be the union of the ARNs associated with the user's groups and the user's own special access.
Then, I think I would just type hologram use arn:aws:iam::123456789012:role/mytest (being able to enter full ARNs is nice for cross-account access) and have it just work.
Is anything blatantly wrong with this? Can it be done more cleanly? Does it seem like the sort of thing that belongs in hologram?

Hello Daniel, thank you for reporting these issues and pointing out various ways we can improve Hologram. I actually had a JIRA ticket filed to investigate this, but didn't have the time before we pushed the open-source release out. :smiley_cat:
It's a fantastic idea, and certainly the type of thing that belongs in Hologram, especialy if we want a larger audience for the system. A couple thoughts on this:

The hologram use invocation you mention can be shortened dramatically. hologram use<PHONE_NUMBER>12/mytest would be sufficient for the cross-account use case, and hologram use mytest would continue to work as the default account case. Little use in making people type out full ARNs when only two parts of it matter. Good idea, though.
The LDAP integration for this will be tricky. As Hologram is configured (on recommendation from the IAM team), individual users do not necessarily have IAM accounts associated with them. Indeed, IAM accounts are really only useful for people who also have console access. My planned usage was that the Hologram server would search for accounts with the same name as the user's cn. If found, they would do the user/group union permissions you mention and apply that to the "developer" role you create. I think this would work, too.

Ideally I would like to keep as little information in LDAP as I can, and push functionality to the IAM APIs. LDAP is already hard enough to administer, and AWS has built-in stuff for most of this. Tricky part is getting a nice, user-friendly face on it.
You're definitely onto something. Interested to hear more thoughts.

Sorry for my delayed response!
I definitely agree with your hologram use point, and think that would be nice and fairly easy.
About the authorization/LDAP point, I see where you're coming from but I also find it fairly appealing to manage user access in the LDAP server (where many other permissions for other services can be granted/revoked). For example, I'd love to just be able to add someone to a group in my directory and have them magically gain access to relevant IAM roles as well as anything that group entails on other services. Obviously, removal from that group would revoke their access to the credentials in question. It wouldn't be the end of the world if my workflow involved modifying the directory server and separately creating and permissioning IAM users, but it doesn't feel ideal either. Perhaps in environments with a less pervasive directory infrastructure, that's less compelling.

Ideally I would like to keep as little information in LDAP as I can

Out of curiosity, why did you store sshPublicKey there in the first place? Are you treating an LDAP directory as a stop-gap place to keep sshPublicKey information until Amazon fleshes out its IAM functionality a bit more?
As far as a path forward, I feel fairly confident that I could implement the LDAP-based group authorization scheme I described above without much effort. If I were to implement it, I'd do so in a reasonably generic manner (user objects have a generic way to determine what roles they have access to) that could support an IAM-based alternative. I could submit such a thing in a PR and see if you'd be interested in it, but if you'd rather steer me in a direction more closely aligned with where you want to take it, I'm open to alternatives too! Perhaps the "user information" component (usercache.go I guess) should be easily pluggable and I could put my LDAP group implementation in there :smile:
Anyway, thanks again for the great project!

No worries about delays - life has a way of catching up to us. Sounds from the other issues like you've been busy! :smiley_cat:

Are you treating an LDAP directory as a stop-gap place to keep sshPublicKey information until Amazon fleshes out its IAM functionality a bit more?

Sort of. There's nothing in IAM that really allows us to store the information that we need. Perhaps making a SimpleDB table (something I considered, and am still considering for future improvements) with the username -> ssh key mappings would be a good alternative usercache implementation. LDAP was really just used because it was already present in AdRoll's corporate environment, but key/value store will do the trick.
I've been hesitant to put more info into LDAP because I honestly just couldn't figure out how to make an implementation of it that didn't require an inordinate amount of setup and maintenance when new roles were created, etc. I think I see what you're trying to go for with the groups, though:

User authenticates to Hologram server through hologram me. (I don't think we should use this for hologram use, as it has too much potential to create confusion and the point of that is to exactly emulate production server roles.)
Hologram checks with LDAP to see what groups the user is in (need a timed cache here, I would assume, as you wouldn't want to read every time). These groups have an attribute with an IAM policy document inside.
These policy documents are merged into a single document.
(Optional, but highly worthwhile, I think: merge these permissions with any that the user's IAM account has, if present.)
This document is used as an argument to AssumeRole to union their permissions with the developer role provided by Hologram.

I'll be very interested in seeing the PR for this.

If I were to implement it, I'd do so in a reasonably generic manner (user objects have a generic way to determine what roles they have access to) that could support an IAM-based alternative.

Making that part of the UserCache interface would be great, that way other backing stores could make their own determinations as to what they want to allow.

Anyway, thanks again for the great project!

:heart: Thank you for all the excellent suggestions and helping us make Hologram more useful for more developers!

What do you mean by policy documents?  Why shouldn't it just be a list of roles a user is allowed to assume?

Agh, I didn't think about that when I was reading through. Yes, you would want a list of those. For some reason I thought he wanted more granular permissions from the hologram me level.
Still something worth looking into eventually, but not quite what's being called for here, it looks like.


Only run apply if PR is mergeable

Is it possible to allow the digger apply comment to execute only if the PR is currently mergeable?  (i.e.  approved when approvers are mandatory, and possibly up to date with the base branch when required,  etc..)
In Atlantis:  https://www.runatlantis.io/docs/command-requirements.html#mergeable
Thx @fleroux514 for suggesting this!

@motatoes I can take a look at this

Thanks @fleroux514 I just assigned it to you!


JRuby XML::Reader memory performance is poor

Hi,
In the context of a Rails application, I have to process huge XML documents that are "flat".  I mean, they could just have been CSV documents instead of XML, but the source provides only XML.
While it appears to work well in MRI, with jruby the memory consumption is very high, and at some point the process is stuck (out of memory).
The following stupid script mimics the problem I face:
p = Pathname.new('big.xml')
n = 10_000_000
ping = -> (msg) { puts "#{Time.now}: #{msg}" }

p.open('w') { |f|
    f.puts "<foos>"
    n.times{ f.puts "  <foo>Hello World</foo>" }
    f.puts "</foos>"
}

ping['before']
c = 0
Nokogiri::XML.Reader(p.open).each do |node|
    ping[c] if c % 1_000_000 == 0
    c += 1
end
ping['after']

The documentation is somewhat ambiguous on how XML::Reader works.  It is easy to understand "The Reader parser is good for when you need the speed of a SAX parser, but do not want to write a Document handler." as meaning "this is a SAX parser with a thin interface on top to make it easier than dealing with SAX yourself".
However the first node return by XML::Reader has the whole document as inner_xml, so I am wondering if XML::Reader is really SAX.
What we need in a document that looks like
<foos>
  <foo>...</foo>
  <foo>...</foo>
  <foo>...</foo>
  ...
  <foo>...</foo>
<foos>

is to iterate just on the  entries.  What is the recommendation in such a case?
Thanks a lot for Nokogiri

Hi @akimd, thanks for asking this question.
I want to spend a little bit of time understanding the memory performance of this example in JRuby -- based on your description, it sounds like perhaps there's a memory leak in the JRuby implementation that we might be able to fix.
The Reader class is based on libxml2's xmlreader module. Although libxml2 uses a SAX-ish pasrser at the heart of its implementation, the API is specialized, and it is optimized for the memory pattern of exposing only a "cursor" as it encounters each node.
The JRuby implementation does not have a low-level parser abstraction like libxml2's xmlreader, and so it's emulating that API ... I'm not very familiar with this particular corner of the JRuby implementation (it's had many hands in it over the years, none of them mine) but it looks like it's using the standard SAX parser provided by Xerces, plus some wrapper logic to present a Reader cursor.
I have some ideas on where the issue might be, and it's probably in the JRuby Reader wrapper. I will dig in and see if I can figure it out.
In the meantime, if you are willing to take on the additional complexity of writing SAX parser handlers, you should find the memory performance of the SAX parser acceptable.

Hi Mike,
Thanks a lot for the quick response.  Ok, so you do confirm that with respect to ressource consumption, XML::Reader is definitely expected to behave more like a nice and comfy SAX reader than a DOM one.  That's reassuring.  So that probably means that using something like inner_xml is asking for trouble that fire the parsing of all the remainder of the file (we don't do that in the real case, it's just something I encountered when toying with the artificial example above).
Other team members are currently trying to address this issue using other parsers, but that causes other problems.  I have no idea what the final choice will be, but we will watching change in Nokogiri on this regard.
Thanks again!

with respect to ressource consumption, XML::Reader is definitely expected to behave more like a nice and comfy SAX reader than a DOM one

Correct! If it's not doing that then we should fix it.

I would love some help with this from any of the folks who are familiar with the JRuby implementation.

Hi guys,
FWIW, we have fully converted our tool to using the SAX parser only.
Cheers!

For posterity: this isn't the first issue filed about the memory utilization of Reader in JRuby -- see also #1066.


[BIGTOP-2961] Add Livy packages

Adding Apache Livy (incubating) package to BigTop. The Livy version is 0.6.0-incubating.

Tested on

CentOS 7: https://ci.bigtop.apache.org/view/Packages/job/Manual-build-deploy-smoke-test/13/console
Ubuntu 16.04: https://ci.bigtop.apache.org/view/Packages/job/Manual-build-deploy-smoke-test/15/console

From the error log it seems that packaging livy require higher version of setuptool:
setuptools_scm.version.SetuptoolsOutdatedWarning: your setuptools is too old (<12)
Would you like to fire up another patch that fix the build env requirement as well?
We handle the env stuffs in Bigtop Toolchain: https://github.com/apache/bigtop/tree/master/bigtop_toolchain
Let me know what you think :)

That might be solvable by running
yum install python2-pip
python -m pip install --upgrade pip setuptools wheel
(if jivy is using python2)
It would make sense to include this into bigtop/slave creation for bigtop 1.5.0

I tried something like this:
python -m pip install --upgrade pip setuptools wheel
Is able to pass the setuptool version check, however hit another problem:
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (python-api verify) on project livy-python-api: Command execution failed.: Cannot run program "flake8" (in directory "/bigtop/build/livy/rpm/BUILD/livy-0.6.0/python-api"): error=2, No such file or directory -> [Help 1]
Did not dig into it yet. Anyone have a clue?

@akitanaka Awesome! I saw your patch. Would you please separate the commit 350daf8 out of this PR?
You can create another JIRA and create a new PR containing 350daf8. That way we have a clean view on the commits and also I can try to build images to test out livy.

Hello, I created BIGTOP-3214 and following PR to update setuptools version and install flake8. (https://github.com/apache/bigtop/pull/530)  Please let me know this works on your env. Thank you.


Module 'dlib' has no 'correlation_tracker' member

Expected Behavior
It should track my face from x,y,w, and h variables I've collected. (Or track a object with those inputs)
Current Behavior
I get this error:
Module 'dlib' has no 'correlation_tracker' member

Steps to Reproduce

Import dlib to script

import dlib

add this code to script

tracker = dlib.correlation_tracker()

Version: 19.21.0
Where did you get dlib: From Pip : pip install dlib
Platform: Ubuntu 20.10 64-bit
Compiler: Python 3.8.6

Error checking was false


AYr-845/group-input-type fixes as per accessibility report

Changes in this PR
1 . added  tag with aria-label in date-filters.html as mentioned in the accessibility report.
2. As a different aria-label is required for the consignment view, update browse-consignment.html to pass view_type.
JIRA ticket
AYR - 845
Screenshots of UI changes
Before

After

[ ] Requires env variable(s) to be updated

all e2e tests passed except (visual regression tests)


Redis data remaining after uninstallation

Reported by @Haishi2016 , seems after uninstall and reinstall, the redis data are not cleaned up, so newly created symphony-api still tries to pick up old jobs.

@RemindD to investigate.
@Haishi2016 , can you please help to provide the repro steps to @RemindD ?

We leverage pvc and storage class. And storage class will define the reclaim policy. Example in minikube:
apiVersion: v1
items:
- apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"labels":{"addonmanager.kubernetes.io/mode":"EnsureExists"},"name":"standard"},"provisioner":"k8s.io/minikube-hostpath"}
      storageclass.kubernetes.io/is-default-class: "true"
    creationTimestamp: "2024-10-17T07:06:59Z"
    labels:
      addonmanager.kubernetes.io/mode: EnsureExists
    name: standard
    resourceVersion: "257"
    uid: 6a375d52-4d38-42db-a01c-05d952e80076
  provisioner: k8s.io/minikube-hostpath
  reclaimPolicy: Delete
  volumeBindingMode: Immediate
kind: List
metadata:
  resourceVersion: ""


Refactor stdout logging warning

Reacting to reader feedback to clarify the stdout logging warning in the App Service troubleshooting topic.
Thanks to @oddbear for reporting this! :rocket:

This one is clearer and more understandable. Thank you.

@Rick-Anderson Can u sign-off? It's a minor clarification.


how to input cropped protein for ESM-2 ?

Hi !
I have problem when I use ESM-2 to embedding long protein sequence. For a long protein sequence, it needs to be cropped to a sequence with a length less than 1024, and BOS and EOS tokens are used to signal the beginning and end of a real protein.
My question is how to input a sequence that contains only a BOS or an EOS, or none of them?
Thanks in advance.

You do not always need BOS and EOS tokens, even if you don’t have a transformer decoder. However, if you are fine-tuning ESM-2 for a specific downstream task, where you intend to use BOS and EOS tokens, then you would include them as special tokens.


Create root accounts for AWS LZ2

Describe the issue
AWS needs us to create the root accounts (set up to BC Gov emails) so that they can help us deploy the Government of Canada (GC) Landing Zone (LZ) LZ2 code into that space.
Which Sprint Priority is this issue related to?
The 'Milestone' should clearly list Sprint Priorities - which one is this issue related to?
Additional context

High Priority, should be done early in sprint
AWS Accounts have to a 1:1 email:account relationship with enforced uniqueness

Definition of done

Create new emails or email aliases on the existing mail server
Create another set of AWS accounts just like LZ1's and
Review those accounts with our AWS Solutions Architect

Have already reached out to Shea, he's helping with this before he heads out for holidays

Emails confirmed working


Preference dialogue is broken in a high-DPI system.

I am using XFCE with a high-DPI setting. The preference dialogue looks like this.
http://imgur.com/a/APIB5
The window buttons and contents are clipped out, and I cannot resize the dialogue.

If you are using Qt 5.6 or later [1], I guess the following environment variable needs to be set before Mozc's config dialog is launched, but what is the correct way to fix it really depends on what version of Qt is used in your environment.
export QT_AUTO_SCREEN_SCALE_FACTOR=1

My suggestion would be to consult with someone who is maintaining Qt 5 in your Linux distribution, or to ask this issue in some user forums where your can find someone who is familiar with Hi DPI support in Qt applications in your Linux distribution.
[1]:  High-DPI Support in Qt 5.6

Please let us know if you can still reproduce this issue even with building Mozc with Qt 5.6 or later and QT_AUTO_SCREEN_SCALE_FACTOR=1 is specified.


Add performance tuning for ulimits

This change adds ulimits performance tuning whereby the maximum open file handles is increased by adding riak hard nofile and riak soft nofile in  /etc/security/limits.conf. When running with default values the config file will be modified like so:
riak hard nofile 65536
riak soft nofile 65536
Custom values can be set by the user by passing parameters like this:
class { '::riak':
  ulimits_nofile_soft => 88536,
  ulimits_nofile_hard => 98536,
}

Thanks @Cornellio! This work is great. I'd like @basho-labs/puppet-committers to take a look if either is free.

Thank you @mjbrender, not clear why the Travis CI builds failed. I will look into it. Rechecking Beaker tests on my system and so far they are passing on centos-66-x64 and debian-78-x64.

I've typed them using Integers in this commit here.

Hi @danieldreier,
Regarding the failed Travis CI builds, I'm trying to get this resolved but am at a loss as to why they fail. Would you be able to comment? The local rspec tests also fail when I do bundle exec rake spec. This fails both on my forked and modified repo and the upstream https://github.com/basho-labs/puppet-riak. It's curious that Travis CI tests pass on your upstream repo yet doing rspec tests on the same code fails.
Thank you

Man, Travis CI is being mean. I'm trying to work with it locally as well. @danieldreier, any observations? @haf, you around?

key_source has been removed https://github.com/basho-labs/puppet-riak/blob/master/manifests/repository/debian.pp#L11
Source of Apt::Source https://github.com/puppetlabs/puppetlabs-apt/blob/master/manifests/source.pp#L3

Nice catch @haf. This fixes it in my local rspec tests, yet on travis ci I get mixed results. https://travis-ci.org/Cornellio/puppet-riak/builds/61655691. Some tests pass, some fail, depending on Ruby versions. Not sure what to do.

It seems the future parser barfs on $::puppetversion, see:
https://travis-ci.org/Cornellio/puppet-riak/jobs/61655693#L436
Is it illegal to use global variables now? /cc @hlindberg Or is the version comparison in the Apt module something that makes the type system annoyed?
Ref https://github.com/puppetlabs/puppetlabs-apt/commit/21a2462a58938d126b66985c0b0fa1f8e09f27cd

@haf It is not illegal to lookup global variables - the error is that the variable is not set which means strict variables is turned on. Is the variable in question actually set? It is supposed to come from facter, be a node parameters, and then set as a node/top scope variable. Cannot see type system having anything to do with this problem.

@hlindberg thank you! That helps; means it's probably an integration test-framework error.

I placed a separate PR #67 containing only the removal of key_source, instead of mixing it in here.

Is there a way forward here? Considering we're stuck on an integration testing issue, I don't know what to do. Can we change the tests to in some way?

@Cornellio I'll review tonight, can't during work.

Ah! So it was THAT which failed the tests!

+1, thanks for putting work into this.

Typos are evil :see_no_evil:.
How's everyone feeling with a merge here? I love seeing the "All is well" flag.

With a certain bias, I'm feeling good about it now that tests are passing. I'm not clear what got them to pass though.

I'm fine with this being merged. We should probably decide how we want to do code review on this project, if we want to do one +1 and then somebody else merges, just have somebody else merge, etc.
I think that two +1's (the second one being the merge) is good for code quality but I'm not sure the project is big enough to support it.


bug when using track by $index

Hi guys, thanks for making this very simple and awesome implementation of jquery ui sortable into angular!
These last 2 days I've been working with this code and I realised that when you use item in items track by $index expression for ng-repeat, the sorting behaviour of HTML is acting weird...
see the full example here
http://codepen.io/anon/pen/ECgxb
the example shows that if you add classes or any html attribute directive (see the directive "barFar", which simply adds far or bar based on $index) the item that gets dropped "inherits" the same classes as the item on which it was dropped to, so if your item 1 is red, and item 2 is green (the one that you are dragging) upon dropping it on item 1, it will be come red bordered.
this is solved by using standard "item in items", but sometimes you may have dupes https://docs.angularjs.org/error/ngRepeat/dupes and you need the expression track by $index
I know that in readme it states that the index must match the dom, which essentially in this case is the truth, it just that it weirdly behaves regarding the html rendering

@vertazzar any feedback?
Based on the aforementioned AngularJS comment, I'm closing this for now.
I really think that the models should be representative of the final view.
The code should expect that a complete view relinking/rerendering might happen at any time and should handle that appropriately.
I would suggest you to add an extra property to your model and fill it on the first load, instead of expecting that the DOM elements will stay intact and hold their state.
I would be more comfortable with something like this but I still can't figure out the track by $index issue.
Thanks for the proper reporting and in case you got any extra insight, I would love it if you could share it here.


Support type inference for auto on function arguments for hover & "expand auto type" code tweak

Basic Use case
clangd's hover and "expand auto type" functionality are incredibly useful when working with auto.
However, they don't work for the auto in the following code:
#include <functional>

struct VeryLongAndComplicatedTypeName;

void foo(std::function<void(VeryLongAndComplicatedTypeName*)> callback) {
   callback(/*...*/);
}

void bar() {
   foo([&](auto* x) { });
}

In this case, the auto is just used to avoid typing a long winded name (realistic examples: std::vector<int>::iterator), but the templated lambda is not actually used as a template, i.e. instantiated with multiple different types.
Advance use cases
Some advanced cases which would also be covered by my proposal below:
using Callback1 = std::function<void(VeryLongAndComplicatedTypeName*)>;
using Callback2= void(*)(VeryLongAndComplicatedTypeName*);
using Callback3 = std::function<void(SomeOtherType*)>;

void someFunctionWithCallback1(Callback1);
void someFunctionWithCallback2(Callback2);
void someFunctionWithCallback3(Callback3);

inline void doSomething() {
    someFunctionWithCallback1([](auto* x) { /*,...*/ });
    // In this case, we know for sure, that the template is only instantiated with `VeryLongAndComplicatedTypeName`.
    // We can deduce `auto` to `VeryLongAndComplicatedTypeName` and display it in the hover & offer the tweak.
}

inline void doSomethingElse() {
    auto callback = [](auto* x);
    someFunctionWithCallback1(x);
    someFunctionWithCallback2(x);
    // In this case, we cast `x` into two different callback types (once a std::function, once a raw pointer)
    // But in both cases `auto` is deduced as `VeryLongAndComplicatedTypeName`, so clangd could still
    // offer `VeryLongAndComplicatedTypeName` as the expanded type in the hover & tweak.
}

inline void doSomeThirdThing() {
    auto callback = [](auto* x);
    someFunctionWithCallback1(x);
    someFunctionWithCallback3(x);
    // In this case, the lambda is actually instantiated with two different types.
    // clangd culd display both in the hover of `auto`, but don't offer an "expand auto" tweak anymore
}

Thoughts on implementation
(take those with a grain of salt - I still have little insight into clangd's internals)
The auto in the lambda turns the lambda's operator() into a template, and clangd can't immediately see which type auto will be deduced at by just looking at the lambda itself. However, taking the context of the lambda (it's casted to a std::function which is completely typed), the type of the auto should be clear.
I think, we can solve this the following way:

track all types with which the template gets  instantiated with
if there is only such one type, this is the type we should use for the expanded type in both the hover and the "expand auto type" tweak
if there are multiple types: display all types on hover. It's pretty useful to know which types a template gets instantiated with, even independently of my request (of course, we would truncate at  types; displaying a huge list of more than  types would provide less value but be expensive to compute)

In general, we can't know where a template is instantiated across the code base and need cross-TU information to collect all types for the template instantiation. Afaict, that would require enhancing clangd's index with that information. It would be pretty high-effort.
We should be able to cut down on this cost, and still satisfy my original goal, i.e. "auto" hovers on local lambdas, if we would restrict the "collect all type instantiations" to case where the templates instantiation does not escape from the translation unit, i.e. if:

we are in a cpp file (instead of a header file), or
we are in a hpp file, but we are not at the top-level scope, e.g. inside some function (see example below)

In those cases, we know that all instantiations must be local, and that our list of instantiations collected from the current TU is actually exhaustive.
Example for"not in a top-level scope" :
// inside some header

using Callback1 = std::function<void(VeryLongAndComplicatedTypeName*)>;
using Callback2= void(*)(VeryLongAndComplicatedTypeName*);
using Callback3 = std::function<void(SomeOtherType*)>;

inline void doSomethingElse() {
    auto callback = [](auto* x);
    someFunctionWithCallback1(x);
    someFunctionWithCallback2(x);
    // Yes, we are in a header. But we know for sure, that nobody outside of the `doSomethingElse`
    // function scope could possibly instantiate `callback::operator()`, so we can still figure out all
    // used types for the `auto` without an index, using only local reasoning inside the current header
}

See #493 for a very similar request and some discussion.
If you're interested in contributing enhancements in this area, I'm happy to provide guidance.

This is way less scary than I had previously thought. Sent out https://reviews.llvm.org/D119537


clean up doc

I have a  bunch of new material https://github.com/h4ck3rm1k3/pump.io that I will have to integrate, feel free to comment on the new commits there.

@h4ck3rm1k3 send PRs! :)

Ok rebased and merged.

@h4ck3rm1k3 I commented on the new diff, speak up if you disagree with anything.
Thanks for contributing to Pump!

Also, full disclosure: it's still unclear exactly how the project is going to work now that we've moved to a community-driven model, so it may be a while before this PR is merged. Just FYI.

rebased , squashed and working.

@h4ck3rm1k3 great, I reviewed the new changes. Only small stuff.
If you can send any new documentation changes unrelated to my comments in a separate PR, that'd be awesome. That way we can get this finished up and merged :)

OK, I implemented your suggestions, look all good to me.

@h4ck3rm1k3 I only caught one thing that you missed, after that's fixed this is good to merge for me. Thank you so much for your hard work!!

Oh gotcha! Should be all good now.

rebased on top of master.


[mxnet] Upgrade MXNet to 1.8.0

Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report

Merging #896 (300ac6c) into master (ff762e8) will decrease coverage by 0.04%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #896      +/-   ##
============================================
- Coverage     70.32%   70.28%   -0.05%
  Complexity     5078     5078
============================================
  Files           501      501
  Lines         22423    22432       +9
  Branches       2327     2332       +5
============================================
- Hits          15770    15766       -4
- Misses         5406     5424      +18
+ Partials       1247     1242       -5

Impacted Files
Coverage Δ
Complexity Δ

...ngine/src/main/java/ai/djl/mxnet/jna/LibUtils.java
42.23% <0.00%> (-3.82%)
15.00 <0.00> (ø)

...gine/src/main/java/ai/djl/dlr/engine/DlrModel.java
53.12% <0.00%> (-3.13%)
4.00% <0.00%> (ø%)

api/src/main/java/ai/djl/util/Platform.java
46.51% <0.00%> (-2.33%)
8.00% <0.00%> (ø%)

api/src/main/java/ai/djl/repository/Artifact.java
91.37% <0.00%> (-1.73%)
37.00% <0.00%> (-1.00%)

...g/src/main/java/ai/djl/serving/util/Connector.java
55.40% <0.00%> (-1.36%)
21.00% <0.00%> (ø%)

...rc/main/java/ai/djl/paddlepaddle/jni/LibUtils.java
51.14% <0.00%> (ø)
14.00% <0.00%> (ø%)

api/src/main/java/ai/djl/inference/Predictor.java
90.38% <0.00%> (+2.88%)
24.00% <0.00%> (+1.00%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff762e8...300ac6c. Read the comment docs.


HARP-7517: Performance fix, do not force material update.

Thank you for contributing to harp.gl!
Before requesting a pull request, please remember to check the following documents:

contribution guidelines
coding style

If you are adding new functionality we would highly appreciate if you can describe what is the capability you are adding and even better if you can add some examples. Please also remember to add tests for it.
CI Check
Our bots will check whether your PR can be directly integrated into the mainline. We have some internal integration tests running on the background, our bots will inform you of the next steps and someone from our team will take a look and help if needed!
And please do not forget to sign-off your commit! You can read more about DCO here. But, in short, you just need to use git commit -s or append --signoff when you are committing to the repo.
Happy contributing!

Codecov Report

Merging #1185 into master will increase coverage by 0.15%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1185      +/-   ##
==========================================
+ Coverage   47.57%   47.72%   +0.15%
==========================================
  Files         244      257      +13
  Lines       22683    22934     +251
  Branches     5062     5113      +51
==========================================
+ Hits        10791    10945     +154
- Misses      11892    11989      +97

Impacted Files
Coverage Δ

@here/harp-materials/lib/Utils.ts
78.04% <100%> (-1.96%)
:arrow_down:

@here/harp-mapview/lib/DecodedTileHelpers.ts
50.5% <100%> (-0.17%)
:arrow_down:

@here/harp-materials/lib/IconMaterial.ts
44.44% <0%> (-55.56%)
:arrow_down:

@here/harp-map-controls/lib/Utils.ts
46.15% <0%> (-23.85%)
:arrow_down:

@here/harp-omv-datasource/lib/OmvTiler.ts
50% <0%> (-16.67%)
:arrow_down:

@here/harp-utils/lib/ObjectUtils.ts
83.33% <0%> (-10.22%)
:arrow_down:

@here/harp-utils/lib/UrlUtils.ts
84.09% <0%> (-7.81%)
:arrow_down:

@here/harp-datasource-protocol/lib/Extruder.ts
8.33% <0%> (-5.96%)
:arrow_down:

@here/harp-lines/lib/TriangulateLines.ts
11.9% <0%> (-2.99%)
:arrow_down:

... and 29 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 170151a...fcc0483. Read the comment docs.

GPU tests please

AWS tests please

GPU tests please

Solution replaced with new PR #1186


fix(scylla_repository): Fix link relactable_url_base

After move to new location usage:
$ SCYLLA_VERSION=unstable/master:2021-01-18T15%3A48%3A13Z ./scripts/run_test.sh
failed with error:
 File "/home/abykov/Projects/scylladb-project/scylla-ccm/ccmlib/scylla_repository.py", line 175, in setup
    tmp_download, 'scylla-core-package'))
  File "/home/abykov/Projects/scylladb-project/scylla-ccm/ccmlib/scylla_repository.py", line 289, in download_version
    download_file(url=url, target_path=target,verbose=verbose)
  File "/home/abykov/Projects/scylladb-project/scylla-ccm/ccmlib/utils/download.py", line 110, in download_file
    resp.raise_for_status()
  File "/usr/local/lib/python3.7/site-packages/requests/models.py", line 940, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://s3.amazonaws.com/downloads.scylladb.com/relocatable/unstable/master/2021-01-18T19%3A16%3A39Z/scylla-package.tar.gz

fixed url to support new location

@fruch Done

@fruch Done


addon-info prop type errors on Chrome devtool

Describe the bug
Addon-info throw prop type errors on Chrome devtool
To Reproduce

Start storybook
Open Chrome devtool
Prop type errors displayed on Chrome devtool

Expected behavior
No prop type errors.
Screenshots

Code snippets
.add(
    'Some description',
    () =>
Test
,
    {
      info: `
        ## Purposes
        This example is to override styles to make banner items with full-width of conatiner.

        ## Steps
          - Pass "className" props to Banner, like "full-width-banner"
          - Add styles to make item with full width as container

        ~~~scss
          .full-width-banner {
            &.kk-banner {
              .slider-mask {
                padding: 0;
              }

              .banner-item {
                padding: 0;
              }
            }
          }
        ~~~
      `
    }
  )

System:

OS: MacOS
Device: Macbook Pro 2016
Browser: Chrome
Framework: React
Addons: Addon-info
Version: v5.0.10

Additional context
These errors won't show on v4.x

Possible dupe to #5915

This issue has gone. Close it.


add query parameters to RestoreTMS so it only tries to update status …

…of not-finalized transactions.

shouldn't deleted recoreds be excluded from the restore?


Add support for nicolaslopezj:roles

For this package to work with orion meteor CMS, we need to use the nicolaslopezj:roles package, not alanning:roles.  Unfortunately the orion version doesn't support groups as of right now, so the role checking logic is a little different.  This shouldn't break anyone's current code though.

Yes, I'd love to have this as part of the default ongoworks package, please add!

Same for me! :+1:

@aaronjudd I'm OK with merging this after a fix to my comment.

@macsj200  if you want to update with @aldeed's comment (revert userHasRole to userIsInRole) (per: http://alanning.github.io/meteor-roles/classes/Roles.html ), I can merge and publish today.

@aaronjudd @aldeed All good now?

@macsj200 thanks, published.


invoking rak without any arguments

Hi!
if i do rak without any arguments, it will do something equivalent to a cat call on all the files from the current folder.
IMHO it would be better to throw an error. For example, the rg behaviour:
demanuel@archlinux ~/Downloads> rg
error: The following required arguments were not provided:
    <PATTERN>

USAGE:

    rg [OPTIONS] PATTERN [PATH ...]
    rg [OPTIONS] -e PATTERN ... [PATH ...]
    rg [OPTIONS] -f PATTERNFILE ... [PATH ...]
    rg [OPTIONS] --files [PATH ...]
    rg [OPTIONS] --type-list
    command | rg [OPTIONS] PATTERN
    rg [OPTIONS] --help
    rg [OPTIONS] --version

For more information try --help

demanuel@archlinux ~/Downloads [2]>

I think it would be nice if we have the same kind of behaviour

https://github.com/lizmat/App-Rak/commit/2f65fcca0d fixes this.  Will be in the next release, which will most likely be tomorrow!

Super! Thanks!


Pypi create a sdist release or wheel with none-none

Hi,
we run multiple time into problem as guildai is only releasing wheels and all wheels are pinned to a python interpreter version -> https://pypi.org/project/guildai/0.7.0/#files has no python3-9 wheel
As guildai has no compiled parts (as far i can see it, and uses no interpreter specific code e.g. await async) it not necessary to pin it to a interpreter version.
Thanks

The latest pre-release (0.7.3.dev4) is now provided as pure Python wheel.
https://pypi.org/project/guildai/0.7.3.dev4/#files
I'm going to close this. If there are still any issues please feel free to re-open.
Thanks a lot for the issue. This was a good improvement I think.

thanks @gar1t


Disable feature date

Hi there,
First of all, many thanks for your hard working.
Now, I want to disable feature date, means user can't select any date which is higher than today, only allow to select from today to past, how can I do this?
And how can I change the language to my language?

Dates boundary : use dataSource method -minimumDateForCalendar: and maximumDateForCalendar
language calendar.locale = ...


Does not work st7789 on esp32

Logging this as a new bug (although in a way I suspect it might be my own fault). I apolagize in advance if I am misisng some small thing, and this is more a request for help than a bug report
I do have an ESP32 with the st7789 attached to it. Cirtcuit configuration can be found here: https://raw.githubusercontent.com/Fri3dCamp/badge-2020/master/media/Badge_Block.png
Some (setup) example code with Arduino can be found here https://github.com/Fri3dCamp/Badge2020_arduino/blob/main/Badge2020_TFT.h / https://github.com/Fri3dCamp/Badge2020_arduino
This code example works (just as sanity check that my hardware is working)
I am pretty sure my pin config is correct (5 for CS, 33 for DC and 26 for RST), as configured in example code from before. (Note 26 does not appear on the schema, maybe it does not have RST, but I tried it with st7789_without_rst as well.., also in working arduino code it has been set as wel
In all cases I just get a black screen and I am not sure why as I expect a cleaned red screen
I notice with this I have to configure my own SPI config which is somehow "magically"? handled when using Arduino/Adadruit library so maybe I am doing something wrong here... (I took inspiration from https://github.com/mutantbob/lcd-esp32)
  # Tried both MODE_3 and MODE_0
    let config = <esp_idf_hal::spi::config::Config as Default>::default().data_mode(embedded_hal::spi::MODE_3);
    let spi = esp_idf_hal::spi::Master::<esp_idf_hal::spi::SPI2, _, _, _, esp_idf_hal::gpio::Gpio23<esp_idf_hal::gpio::Unknown>>::new(
        peripherals.spi2,
        esp_idf_hal::spi::Pins {
            sclk: peripherals.pins.gpio18,
            sdo: peripherals.pins.gpio19,
            sdi: Some(peripherals.pins.gpio23),
            cs: None,
        },
        config,
    )
    .unwrap();
    let lcd_dc = peripherals.pins.gpio33.into_output().unwrap();
    let lcd_rst = peripherals.pins.gpio26.into_output().unwrap();
    let lcd_cs = peripherals.pins.gpio5.into_output().unwrap();
    let mut led_bl = peripherals.pins.gpio12.into_output().unwrap();
    led_bl.set_high();
    let di = display_interface_spi::SPIInterface::new(spi, lcd_dc, lcd_cs);
    println!("SPI CONFIG DONE");

    let mut lcd = mipidsi::Display::st7789(di, lcd_rst);
    let mut delay = esp_idf_hal::delay::Ets;
    println!("INIT S");

    lcd.init(
        &mut delay,
        mipidsi::DisplayOptions {
            orientation: mipidsi::Orientation::PortraitInverted(false),
            invert_vertical_refresh: false,
            color_order: Default::default(),
            invert_horizontal_refresh: false,
        },
    ).unwrap();

    println!("INITED");

    lcd.clear(Rgb565::RED);
    println!("CLEAR");

   # I am joining on another thread here to make sure my program does not exit

What is your SPI speed setting (frequency) in both C and Rust code? That's the one thing I don't see mentioned here. It's possible you're running it at too high of a speed. The ST7789 can do up to 60Mhz at times AFAICS but it gets flakey there, depending on the board you use tho.
If not that we could try comparing the init and if you have a logical analyzer capturing the SPI output to see if there's a logical or even a SPI level problem.

"What is your SPI speed setting (frequency) in both C and Rust code?"
C code => I have no idea, in my userland code I am not setting SPI settings, this seems all handled by Adafruit library (and even in there I could not find anything really)
Rust code => I stayed with defaults, so I dont specifically set anything.
At some point I tried "let config = <spi::config::Config as Default>::default().baudrate(24.MHz().into());" but that did not work either...
Note the example rust application esp32 https://github.com/ivmarkov/rust-esp32-std-demo which uses the st7789 driver also doesn't work for ....
It surely looks maybe I am just using wrong pins or something (or some other bad configuration, or both the st7789 driver and this driver have same bug)
Ill try a few more things as well, but if anyone has an idea where to look please let me know

Okay I finally found something
Look in https://gist.github.com/nathansamson/8ff4efbcd11043bcfda6a3e7cf2d01ea for details
There are 3 files in there

Cargo.toml (this is for the st7789 version but can easily be modified by swapping dependencies for mipidsi version)
mipidsi.rs  this version does NOT work, it shows some greyish background on the screen but nothing more
st7789.rs It differs only to the previous version how it initializes the lcd, inthis case via st7789. All drawing or SPI operations are the same. This WORKS (displays blue background with 2 squares, green with a red border, as expected)

So the breaktrough since previous time was that I was usingt he wrong SPI (2 vs 3) and my pins where out of order...
So now I know my config finally works I think this should fall under bug as with same config st7789 library works but this one doesn't (although it claims it should).
Funliy enough it does not seem to be exactly like https://github.com/almindor/mipidsi/issues/22 there using MODE_3 solved the problem, in my case MODE3 with mipidsi gives a blank screen, and with MODE0 a grayish screen (but certainly not the blue with 2 squares as I expect it)...

Okay I finally found something
Look in https://gist.github.com/nathansamson/8ff4efbcd11043bcfda6a3e7cf2d01ea for details
There are 3 files in there
* Cargo.toml (this is for the st7789 version but can easily be modified by swapping dependencies for mipidsi version)

* mipidsi.rs  this version does NOT work, it shows some greyish background on the screen but nothing more

* st7789.rs It differs only to the previous version how it initializes the lcd, inthis case via st7789. All drawing or SPI operations are the same. This WORKS (displays blue background with 2 squares, green with a red border, as expected)

So the breaktrough since previous time was that I was usingt he wrong SPI (2 vs 3) and my pins where out of order...
So now I know my config finally works I think this should fall under bug as with same config st7789 library works but this one doesn't (although it claims it should).
Funliy enough it does not seem to be exactly like #22 there using MODE_3 solved the problem, in my case MODE3 with mipidsi gives a blank screen, and with MODE0 a grayish screen (but certainly not the blue with 2 squares as I expect it)...

Ok so if I understand correctly, using the "proper" SPI instance works with the ST7789 driver, but still fails with the MipiDSI one.
When it comes to ST7789, which MODE works for you? Can you try lowering your SPI clock to something super slow like 100khz (you'll see individual pixels being pushed, should it work out)?
AFAICS the only difference between the inits of those two drivers (I wrote both of them :D) is the MADCL/Rgb-Bgr flip (if using defaults).

Normal Hz (32Mhz)
ST7789 driver

MODE 0 works
MODE 3 works

mipidsi driver

MODE 0 displays a grayish background but no colors are displayed
MODE 3 keeps black screen

Slow Hz (20000.Hz().)
ST7789 driver

MODE 0 works, pixels are drawn slowly from top to bottom, starting on grayish background (same as non working MODE 0 for mipdsi above)
MODE 3 works, same as mode 0

mipidsi driver

MODE 0 displays a grayish background but no colors are displayed
MODE 3 keeps black screen

Recap of initialization (st7789)
    let mut lcd = st7789::ST7789::new(di, lcd_rst, 240, 240);
        lcd.set_orientation(st7789::Orientation::Portrait).unwrap();

        let mut delay = esp_idf_hal::delay::Ets;
        lcd.init(&mut delay).unwrap();

initialization of mdpsi, note the settings that I kind of guessed but for me should worst case result in inverted image and/or wrong colors
let mut lcd = mipidsi::Display::st7789(di, lcd_rst);
    let mut delay = esp_idf_hal::delay::Ets;
    println!("INIT S");

    lcd.init(
        &mut delay,
        mipidsi::DisplayOptions {
            orientation: mipidsi::Orientation::PortraitInverted(false),
            invert_vertical_refresh: false,
            color_order: Default::default(),
            invert_horizontal_refresh: false,
        },
    ).unwrap();

Could you try<EMAIL_ADDRESS>as well? I just want to make sure it still works.
This is really perplexing, the only init difference AFAICS is that mipidsi has a "dynamic" MADCTL based on config (e.g. orientation, color swaps etc.) and "inverts" the RGB by default (which might or might not be needed, it's another odd point).
I'm comparing https://github.com/almindor/st7789/blob/master/src/lib.rs#L127-L151 to this
The only diffs I can see:

let madctl = options.madctl() ^ 0b0000_1000; line which should at worst confuse the colors.
hard_reset being used in all cases with ST7789 while it's a union with sw reset on mipidsi (should be correct that way)
Longer final delay after DISPON in mipidsi

If this is an init issue (without any kind of odd timing or other side-effect problem) then changing these in the mipidsi driver to match should make things work. Everything else is "generic" code that is the same.

I can confirm st7789 v0.7.0 works too
If you prepare a branch with the fixes to match st7789 I am happy to try it out to see if that one works and if indeed thats the cause...
If you don't have tine for that I might try that later (might only be in weekend)

I can confirm st7789 v0.7.0 works too
If you prepare a branch with the fixes to match st7789 I am happy to try it out to see if that one works and if indeed thats the cause... If you don't have tine for that I might try that later (might only be in weekend)

Could you please try with https://github.com/almindor/mipidsi/tree/st7789init ? Use DisplayOptions::default() for the options which should match madctl to 0x0 (same as st7789). This branch unifies everything else with the ST7789 driver, so if it still doesn't work we're probably seeing some deeper issue that might be semi-random.
One other thing that I didn't touch upon is the backlight pin. I suspect you don't use it though.

Ill give it a try later
Backlight pin: that shouldn't matter. As far as I understand its hardlinked with a physical switch (although the example arduino code for my board defines pin 12) -- correction: there has been some activity in that repo which fixes that misconception.
Note I also see some noise about the RST button, so maybe that also has an impact... Ill check it out later

I tried it out.
So couple of things

The main inprovement came from using "DisplayOptions::default()" and not

mipidsi::DisplayOptions {
            orientation: mipidsi::Orientation::PortraitInverted(false),
            invert_vertical_refresh: false,
            color_order: Default::default(),
            invert_horizontal_refresh: false,
        }

Once I used the defaults I could see the 2 small rectangles I was drawing.
Note the background color stayed grey while it should have been Blue lcd.clear(Rgb565::BLUE)

When using the 0.2.1 version with DisplayOptions::default() the colors are wrong though. I see a blue outline with a green background for each rectangle while it should be red outline and green background (Red & Green are switched but that does not fully surprise you so it seems)

So to me it seems 'lcd.clear' is not (properly) implemented?
And in the 0.2.1 version the color initialization is not "correct" (maybe there is no one correct and it really depends on the version you are getting...)
I am not sure  why my original DisplayOptions where incorrect though (I copied them from another example), looks to me worst case it would do drawing in the wrong orientation?

I tried it out.
So couple of things
* The main inprovement came from using "`DisplayOptions::default()`" and not

mipidsi::DisplayOptions {
            orientation: mipidsi::Orientation::PortraitInverted(false),
            invert_vertical_refresh: false,
            color_order: Default::default(),
            invert_horizontal_refresh: false,
        }

Once I used the defaults I could see the 2 small rectangles I was drawing. Note the background color stayed grey while it should have been Blue lcd.clear(Rgb565::BLUE)
* When using the 0.2.1 version with `DisplayOptions::default()` the colors are wrong though. I see a blue outline with a green background for each rectangle while it should be red outline and green background (Red & Green are switched but that does not fully surprise you so it seems)

Yes this is due to the madctl XOR operation I added (wrongly) in mipidsi thinking the ST7789 had the RGB bit wrong for some reason.

So to me it seems 'lcd.clear' is not (properly) implemented? And in the 0.2.1 version the color initialization is not "correct" (maybe there is no one correct and it really depends on the version you are getting...)

I'm not sure why clear doesn't work. It's odd if a rect works, clear should too.

I am not sure why my original DisplayOptions where incorrect though (I copied them from another example), looks to me worst case it would do drawing in the wrong orientation?

Using a different orientation changes the MADCTL register value. I suspect that there either is a bug or that the given setting draws "in the wrong direction" (off display area).
Just to be 100% sure I understand the results here. The background clear doesn't work in either case, but the drawable rect with border is drawn with wrong colors in both the branch and master if you use the default options, with inverted colors in the master branch, correct?

Just to be 100% sure I understand the results here. The background clear doesn't work in either case, but the drawable rect with > border is drawn with wrong colors in both the branch and master if you use the default options, with inverted colors in the master > branch, correct?

0.2.1 has wrong colors, st7789init branch has correct colors. (Both using default drawing options)
Neither of them have a full size background (created with "clear")

Just to be 100% sure I understand the results here. The background clear doesn't work in either case, but the drawable rect with > border is drawn with wrong colors in both the branch and master if you use the default options, with inverted colors in the master > branch, correct?

0.2.1 has wrong colors, st7789init branch has correct colors. (Both using default drawing options) Neither of them have a full size background (created with "clear")

Thanks for all the testing. Could you do one more thing please? Add a delay after your last render, and then call clear again to see if that works. I want to exclude "timing" issues with the clear call.

No that doesnt work either...
So I am initting, clearing (which doesnt do much), drawing 2 rectangles, sleeping 2 seconds, clearing again and still 2 rectangles show
Note using fill_solid works (and rectangle of 240x240)
Note:
fill_solid will basically do a set_pixels(0, 0, 240, 240, array of 240 * 240)
while clear will do a
set_prixes(0, 0, 240, 320, array of 240 * 320) (or set_prixes(0, 0, 320, 240, array of 240 * 320)
and maybe thats the problem that there is problem with set_pixels that its going out of boumds (because wrong orientation)

Yes thats it , when I say that its in Landscape mode clearing works. Note that for me this feels the wrong orientation (my small rectangles are now oriented differently and I feel incorrectly)
My best guess is that clear should be independent from the orientation I want things to be in??? Which in a way makes sense since the orientation is something that is not hardware bound/set (I think), so regardless of how I see my display the clearing should happen the same way?

No that doesnt work either... So I am initting, clearing (which doesnt do much), drawing 2 rectangles, sleeping 2 seconds, clearing again and still 2 rectangles show
Note using fill_solid works (and rectangle of 240x240)
Note: fill_solid will basically do a set_pixels(0, 0, 240, 240, array of 240 * 240) while clear will do a set_pixels(0, 0, 240, 320, array of 240 * 320) (or set_prixes(0, 0, 320, 240, array of 240 * 320)
and maybe thats the problem that there is problem with set_pixels that its going out of boumds (because wrong orientation)
Yes thats it , when I say that its in Landscape mode clearing works. Note that for me this feels the wrong orientation (my small rectangles are now oriented differently and I feel incorrectly)
My best guess is that clear should be independent from the orientation I want things to be in??? Which in a way makes sense since the orientation is something that is not hardware bound/set (I think), so regardless of how I see my display the clearing should happen the same way?

I think you're right. I'll have to go over the orientation MADCTL values vs clear to see where the actual problem lies. I won't be able to do anything until after Sep 10 tho since I'm abroad atm.

@nathansamson if you can please check out #32 to see if this works with those changes now.


pull request for e2e test at 12/20/2016 22:26:22

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Remove duplicated lines from docstrings in geod.py

This PR simply removes what looks like duplicated lines in 2 docstrings of the pyproj.geod module.
I've also noticed that three methods of the Geod class (namely fwd, inv, and npts) seem to be older than the other methods of the class, and don't have docstrings with properly formatted Parameters and Returns sections describing the function signatures.
I can update these docstrings if you want!

Thanks!

I can update these docstrings if you want!

That would be great :+1:


Name of PyFilesystemContentsManager is too long

@timkpaine What's a good shortening? Maybe FSContentsManager?

@telamonian im bad at names but I agree

lets go with FSContentsManager

I took care of this as part of #21. I ended up going with FSManager, a la the notebook server built-in LargeFileManager


chore(docs): update per-language instructions

Related #155, #167

I'm not good with these help-pages, hopefully this looks alright.


What is 8964?

It is possible that you may be referring to the Tiananmen Square protests of 1989, which are also known as the June Fourth Incident (六四事件) or the 1989 Democracy Movement. The protests, which took place in Beijing's Tiananmen Square, were a student-led pro-democracy movement that called for political reform and an end to corruption in the Chinese government. The protests were eventually suppressed by the Chinese government, resulting in a violent crackdown and an unknown number of casualties. The exact number of casualties is not known, but estimates range from several hundred to several thousand. The Chinese government has since censored any mention of the event and has not allowed public discussion or commemoration of the incident.


Fix CG bug - jsonwebtoken

Tasks:
AzurePowerShellV5
AzureResourceGroupDeploymentV2
AzureStaticWebAppV0
AzureTestPlanV0
AzureVmssDeploymentV0
DockerComposeV0
JavaToolInstallerV0
JenkinsDownloadArtifactsV1
KubernetesV0
PackerBuildV1
Description: Update jsonwebtoken subdependency.
Documentation changes required: No
Added unit tests: No
Related issue
Checklist:

[x] Task version was bumped - please check instruction how to do it
[x] Checked that applied changes work as expected

Noticing issues with Statis Web App deployment:
Here is the link:
https://github.com/Azure/static-web-apps/issues/1519


Update blogs.md

I have added "Android For Devs" and "Dev Exchanges" blogs site link.

Thank you @JaldeepAsodariya for sharing blogs. Look forward for your more contribution!

Definitely sir. I will try my best for more contribution to our community.
Thank you sir.