Copy-Item incorrect behavior and also inconsistent results when rerun

Steps to reproduce
Issue
Copy-Item behavior is inconsistent and produces unexpected results
In some cases rerunning the same command produces different results
The results are different than what cmd copy, xcopy, and robocopy would produce
SetUp
For each example the following setup is to start with a clean slate
Before EACH of the tests in EACH example the environment is reset
(so before each Copy-Item, cmd copy tests, xcopy, or robocopy test)
SetUp-PSCopyTest.ps1

    rm -r -force \test
    rm -r -force \test2

    md \test

    echo 'a' > \test\a.txt
    echo 'b' > \test\b.txt
    echo 'c' > \test\c.txt
    echo 'd' > \test\d.txt

    md \test\1

    echo '1d' > \test\1\d.txt

Which produces the following folders and files

    \test\a.txt
    \test\b.txt
    \test\c.txt
    \test\d.txt
    \test\1
    \test\1\d.txt

Example 1  - Destination does not exist and recurse not specified
Setup
SetUp-PSCopyTest.ps1
Test
    Copy-Item test test2

Expected Result
    \test2          directory created
    \test2\a.txt    file copied
    \test2\b.txt    file copied
    \test2\c.txt    file copied
    \test2\d.txt    file copied

Copy-Item Result (UnExpected)
    \test2          directory created but is empty
    No files in \test were copied

Copy-Item ReRun Result (UnExpected AND different)
    \test2\test     directory created
    No files in \test were copied and no files exist in test2 or test2\test

cmd copy test test2 Result (Not desired but expected)
    \test2 FILE created which contains the contents of
        \test\a.txt
        \test\b.txt
        \test\c.txt
        \test\d.txt

    Not the desired result but expected since \test2 directory did not exist

xcopy test test2 Result (Expected)
    The expected results occur if you respond D for directory to the prompt
    asking if test2 is File or Directory

robocopy test test2 Result (Expected)
    The expected results occur

Example 2  - Destination does not exist and recurse was specified
Setup
SetUp-PSCopyTest.ps1
Test
    Copy-Item test test2 -r

Expected Result
    \test2                  directory created
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied
    \test\1                 directory created
    \test\1\d.txt           file copied

Copy-Item Result (Expected)
    The expected results occur

Copy-Item ReRun Result (UnExpected AND different)
    Note when rerun the results are different since the \test2 directory exists
    This makes Copy-Item difficult to use in a script that is scheduled to run
    on a reoccurring basis

    \test2\test             directory created
    \test2\test\a.txt       file copied
    \test2\test\b.txt       file copied
    \test2\test\c.txt       file copied
    \test2\test\d.txt       file copied

    \test2\test\1           directory created
    \test2\test\1\d.txt     file copied

Copy-Item 2nd Rerun Result (UnExpected AND different again from previous 2 runs)
    Error: CopyItem : An item with the specified name \test2\test already exists

    If -Force is specified then the results are the same as the Copy-Item ReRun results,
    however, that demonstrates how Copy-Item cannot be used to produce the same results
    for a rerun command. It also only seems to care when a destination directory
    exists and as other tests show does not care if it would overwrite a file.

cmd copy Result (Not Supported)
    cmd copy does not support recursion so test not applicable

xcopy test test2 /s /e Result (Expected)
    The expected results occur if you respond D for directory to the prompt
    asking if test2 is File or Directory

robocopy test test2 /s /e Result (Expected)
    The expected results occur

Example 3  - Destination exists but is empty and recurse not specified
Setup
SetUp-PSCopyTest.ps1
md \test2
Test
    Copy-Item test test2

Expected Result
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied

Copy-Item Result (UnExpected)
    \test2\test             directory created
    No files in \test were copied

Copy-Item ReRun Result (UnExpected and different)
    Error: copy-item : An item with the specified name \test2\test already exists.

    If -Force is specified then the results are the same as the Copy-Item results

cmd copy test test2 Result (Expected)
    The expected results occur

xcopy test test2 Result (Expected)
    The expected results occur

robocopy test test2 Result (Expected)
    The expected results occur

Example 4  - Destination exists but is empty and recurse was specified
Setup
SetUp-PSCopyTest.ps1
md \test2
Test
    Copy-Item test test2 -r

Expected Result
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied
    \test2\1                directory created
    \test2\1\d.txt          file copied

Copy-Item Result (UnExpected)
    \test2\test\a.txt       file copied
    \test2\test\b.txt       file copied
    \test2\test\c.txt       file copied
    \test2\test\d.txt       file copied
    \test2\test\1           directory created
    \test2\test\1\d.txt     file copied

Copy-Item ReRun Result (UnExpected)
    Error: Copy-Item : An item with the specified name \test2\test already exists.

    If -Force is specified then the results are the same as the Copy-Item results, but
    those are not the expected or desired results

cmd copy Result (Not Supported)
    cmd copy does not support recursion so test not applicable

xcopy test test2 /s /e Result (Expected)
    The expected results occur

robocopy test test2 /s /e Result (Expected)
    The expected results occur

Example 5  - Destination does not exist, using * with the source and recurse not specified
Setup
SetUp-PSCopyTest.ps1
Test
    Copy-Item test\* test2

Expected Result
    \test2                  directory created
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied

Copy-Item Result (Expected)
    The expected results occur

Copy-Item ReRun Result (UnExpected and different)
    \test2\1                directory created and empty

    No confirmation for overwriting files occur

Copy-Item 2nd ReRun Result (UnExpected and different)
    Error: Copy-Item : An item with the specified name \test2\1 already exists.

    Interesting no issue with overwritting the files

    If -Force is specified then the results are the same as the Copy-Item rerun results, but
    those are not the expected or desired results

cmd copy test\* test2 Result (Not desired but expected)
    \test2 FILE created which contains the contents of
        \test\a.txt
        \test\b.txt
        \test\c.txt
        \test\d.txt

    Not the desired result but expected since \test2 directory did not exist

xcopy test\* test2 Result (Expected)
    The expected results occur if you respond D for directory to the prompt
    asking if test2 is File or Directory

robocopy test\* test2 Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 produces the expected results

Example 6  - Destination does not exist, using * with the source and recurse was specified
Setup
SetUp-PSCopyTest.ps1
Test
    Copy-Item test\* test2 -r

Expected Result
    \test2                  directory created
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied
    \test2\1                directory created
    \test2\1\d.txt          file copied

Copy-Item Result (UnExpected)
    \test2                  directory created
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied

    Despite specifying recurse the following were not created
        \test2\1            directory not created
        \test2\1\d.txt      file not copied

Copy-Item ReRun Result (Expected BUT different)
    The expected results occur but this differs from the initial run which shows that
    you cannot run the same command and get the same results.

cmd copy Result (Not Supported)
    cmd copy does not support recursion so test not applicable

xcopy test\* test2 /s /e Result (Expected)
    The expected results occur if you respond D for directory to the prompt
    asking if test2 is File or Directory

robocopy test\* test2 /s /e Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 /s /e produces the expected results

Example 7  - Destination exists, using * with the source and recurse not specified
Setup
SetUp-PSCopyTest.ps1
md \test2
Test
    Copy-Item test\* test2

Expected Result
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied

Copy-Item Result (UnExpected)
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied
    \test2\1                directory created but empty

Copy-Item ReRun Result (UnExpected and different)
    Error: Copy-Item : An item with the specified name \test2\1 already exists.

    Interesting no issue with overwriting the files

    If -Force is specified then the results are the same as the Copy-Item  results, but
    those are not the expected or desired results

cmd copy test\* test2 Result (Expected)
    The expected results occur

xcopy test\* test2 Result (Expected)
    The expected results occur

robocopy test\* test2 Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 produces the expected results

Example 8  - Destination exists, using * with the source and recurse was specified
Setup
SetUp-PSCopyTest.ps1
md \test2
Test
    Copy-Item test\* test2 -r

Expected Result
 \test2\a.txt               file copied
 \test2\b.txt               file copied
 \test2\c.txt               file copied
 \test2\d.txt               file copied
 \test2\1                   directory created
 \test2\1\d.txt             file copied

Copy-Item Result (Expected)
    The expected results occur

Copy-Item ReRun Result (Expected If -Force is also used)
    Error: Copy-Item : An item with the specified name \test2\1 already exists.

    If -Force is specifed then the expected results occur

cmd copy Result (Not Supported)
    cmd copy does not support recursion so test not applicable

xcopy test\* test2 /s /e Result (Expected)
    The expected results occur

robocopy test\* test2 /s /e Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 /s /e produces the expected results

Example 9  - Destination does not exist, using . with the source and recurse not specified
Setup
SetUp-PSCopyTest.ps1
Test
    Copy-Item test\*.* test2

Expected Result
 \test2                     directory created
 \test2\a.txt               file copied
 \test2\b.txt               file copied
 \test2\c.txt               file copied
 \test2\d.txt               file copied

Copy-Item Result (UnExpected but similar to what cmd copy did in prior test)
    test2 FILE created with the contents of \test\d.txt only

Copy-Item ReRun Result (UnExpected)
    Same results as Copy-Item Result, however, interesting that no confirmation prompt
    displayed to overwrite the file

cmd copy test\*.* test2 Result (Not desired but expected)
    \test2 FILE created which contains the contents of
        \test\a.txt
        \test\b.txt
        \test\c.txt
        \test\d.txt

xcopy test\*.* test2 Result (Expected)
    The expected results occur if you respond D for directory to the prompt
    asking if test2 is File or Directory

robocopy test\*.* test2 Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 produces the expected results

Example 10 - Destination does not exist, using . with the source and recurse was specified
Setup
SetUp-PSCopyTest.ps1
Test
    Copy-Item test\*.* test2 -r

Expected Result
    \test2                  directory created
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied
    \test2\1                directory created
    \test2\1\d.txt          file copied

Copy-Item Result (UnExpected but similar to what cmd copy did in prior test)
    \test2 FILE created which contains the contents of \test\d.txt

Copy-Item ReRun Result (UnExpected)
    Same as Copy-Item Result but no overwrite prompt

cmd copy Result (Not Supported)
    cmd copy does not support recursion so test not applicable

xcopy test\*.* test2 /s /e Result (Expected)
    The expected results occur if you respond D for directory to the prompt
    asking if test2 is File or Directory

robocopy test\*.* test2 /s /e Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 /s /e produces the expected results

Example 11 - Destination exists, using . with the source and recurse not specified
Setup
SetUp-PSCopyTest.ps1
md \test2
Test
    Copy-Item test\*.* test2

Expected Result
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied

Copy-Item Result (Expected)
    The expected results occur

Copy-Item ReRun Result (Expected)
    The expected results occur, however, there is no warning about overwritting files

cmd copy test\*.* test2 Result (Expected)
    The expected results occur

xcopy test\*.* test2 Result (Expected)
    The expected results occur

robocopy test\*.* test2 Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 produces the expected results

Example 12 - Destination exists, using . with the source and recurse was specified
Setup
SetUp-PSCopyTest.ps1
md \test2
Test
    Copy-Item test\*.* test2 -r

Expected Result
\test2\a.txt                file copied
\test2\b.txt                file copied
\test2\c.txt                file copied
\test2\d.txt                file copied
\test2\1                    directory created
\test2\1\d.txt              file copied

Copy-Item Result (UnExpected)
    \test2\a.txt            file copied
    \test2\b.txt            file copied
    \test2\c.txt            file copied
    \test2\d.txt            file copied

    Despite specifying recurse the following were not created
        \test2\1            directory not created
        \test2\1\d.txt      file not copied

Copy-Item ReRun Result (UnExpected)
    Same results as Copy-Item, however, there is no warning about overwritting files

    Despite specifying recurse the following were not created
        \test2\1            directory not created
        \test2\1\d.txt      file not copied

cmd copy Result (Not Supported)
    cmd copy does not support recursion so test not applicable

xcopy test\*.* test2 /s /e Result (Expected)
    The expected results occur

robocopy test\*.* test2 /s /e Result (Not supported - but alternative available)
    Robocopy works with directories so this syntax is not valid
    This is not really an issue since robocopy test test2 /s /e produces the expected results

--
-- Comparison of copy method results
Copy-Item
    1   UnExpected result and different results when rerun
    2   Expected result   but different results when rerun
    3   UnExpected result and different results when rerun
    4   UnExpected result and different results when rerun
    5   Expected result   but different results when rerun
    6   UnExpected result initially and Expected Result when rerun
    7   UnExpected result and different results when rerun
    8   Expected result   and same result when rerun if -Force used
    9   UnExpected result and same result when rerun
    10  UnExpected result and same result when rerun
    11  Expected result   and same result when rerun
    12  UnExpected result and same result when rerun

cmd copy
    1   Not desired but expected result
    2   Does not support recursion
    3   Expected result
    4   Does not support recursion
    5   Not desired but expected result
    6   Does not support recursion
    7   Expected result
    8   Does not support recursion
    9   Not desired but expected result
    10  Does not support recursion
    11  Expected result
    12  Does not support recursion

xcopy
    1   Expected result
    2   Expected result
    3   Expected result
    4   Expected result
    5   Expected result
    6   Expected result
    7   Expected result
    8   Expected result
    9   Expected result
    10  Expected result
    11  Expected result
    12  Expected result

robocopy
    1   Expected result
    2   Expected result
    3   Expected result
    4   Expected result
    5   Not Supported but alternative syntax works
    6   Not Supported but alternative syntax works
    7   Not Supported but alternative syntax works
    8   Not Supported but alternative syntax works
    9   Not Supported but alternative syntax works
    10  Not Supported but alternative syntax works
    11  Not Supported but alternative syntax works
    12  Not Supported but alternative syntax works

--
-- Conclusion
When I first started using PowerShell back in the 2.0 days I noticed these and similar issues
but figured they would be addressed as the product matured, therefore I reverted  to using
cmd copy, xcopy, and robocopy, however, I wanted to use Copy-Item since in theory it provided
the capabilites of cmd copy and xcopy all in one.
It is disappointing to see that we have version 7.0 out now in beta and they still have not been
addressed basic functionality.
Copy-Item produces the expected results only 33% of the time and if rerun then it only produces
the same results 16% of the time.
If it was just a matter of learning a different syntax that would be one thing, however,
when considering common use cases (destination exists, destination does not exist, recurse
the source directory tree, don't recurse the source directory tree), there does not appear
to be a syntax which handles all of those cases AND can produce the same results when rerun.
This makes Copy-Item pretty much unusable excpet for all but the most simple types
of copy operations.
Comparing Copy-Item to the other options, cmd copy generally works (with the exception of the
not supporting recursive and a few other cases), xcopy always works, and robocopy always
works OR works with a tweak to the syntax.
Back in the PS 2.0 days I considered writing my own Copy-Item replacement but wanted to use
built in functionality as much as possible so I did not do that.
Are there any plans to address these issues?
There seem to be several key issues:

When the destination does not exist and you are copying more than one item it should
prompt to ask if the destination should or not the destination should be a container.
That covers both use cases where you want to copy multiple items to a single item or
where you want to copy multiple items to a container.

Recurse needs to be fixed so that when you specify recurse it recurses and when you
don't specify recurse it does not create empty containers/folders.

Why does it produce an error if a destination directory exists but not when a destination
file exists?  Based on PowerShell guidelines since overwritting a file is a destructive
operation there should be a confirmation before doing so.  Having the user change their
$ConfirmationPreference from the default of 'High' is not the solution here because
that would cause all sorts of other confirmations that do not currently occur.  Since
this constitutes destructive behavior the cmdlet should be changed to confirm.

I'm sure there are other examples, but those seem to be the key areas causing the problems.
This basic functionality in the product really needs to be fixed so that we do not have
to restore to using external tools to accomplish these basic tasks.
All the above was reproduced on PS 7 Preview 3
Expected behavior

Actual behavior

Environment data

Name                           Value

PSVersion                      7.0.0-preview.3
PSEdition                      Core
GitCommitId                    7.0.0-preview.3
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

@JoeSalmeri Thanks for the in-depth report!
It would be easier for us to move forward if you converted your examples into Pester tests with comments and questions so that we could discuss each one and draw a conclusion. Perhaps we'll need to split this topic into several to facilitate the creation of fixes.

@iSazonov
Thanks for getting back to me, I know that was a lot to digest.
I have heard of Pester but I am not familiar with it and therefore have not used it before.
I understand the importance of preparing a good bug report which is why I spent so much time (way more than I expected) detailing and comparing everything in my original report and why I detailed the expected and actual outcomes in each case.
I also agree that you are correct that my bug report is only dealing with FileSystem provider and I have wondered if the "other" providers might be part of the reason that this problem exists in the first place.   If that turns out to be the case then maybe that means we need Copy-File and/or Copy-Directory cmdlets to provide the basic functionality that exists in cmd.exe / xcopy / robocopy.
While there may be additional items, I think my 3 summary points at the end summarize the key areas that contribute to the problems.
When you consider the following use cases:
Copy-Item dir1 dir2
Copy-Item dir1 dir2 -Recurse
Pretty much every command line environment I have ever worked with (over the last 30+ years) or any of the external tools like xcopy, robocopy, or the many others that have existed over the years all understand and produce the correct results for those command regardless of whether the target directory exists or not and regardless of what layout of files and folders exists under dir1 and dir2 and regardless of whether you want to recurse or not.
The only exception is Copy-Item.  Although I provided 12 different examples, the additional examples that added '' and '.*' to the commands were attempts by me to try to find a syntax for Copy-Item that would produce the results for the above 2 use cases which was the real goal.  I included them so that you could see all the different examples that I tried to accomplish the goal and that would produce results that were repeatable.
In the PowerShell environment, I expect to have to use -Force for a repeat run, but I also expect to get the same results when I rerun, however, Copy-Item pretty much fails in all cases which is why I said that it is unusable in all but the most simple cases.
Because of these issues I have replaced Copy-Item and cp with pointers to cmd.exe copy in my profile because I needed something that worked but I incorrect expected that they would have been addressed long before we reached PS 7 since copy is considered core/basic functionality.
When you also consider that Copy-Item will overwrite files with no warning, I consider it a pretty serious issue and would have expected the cmlet to be using ShouldProcess (which it may be) and have a confirmation level such that destructive actions could not occur without confirmation.
In my opinion, those destructive issues should raise the priority level on these bugs.
Maybe you can get the peopled that wrote xcopy or robocopy involved as they have a handle on exactly what the use cases are and the expected results?
I hope you can move forward with what I provided as my plate is pretty full right now and I'm not sure I have time install, setup, and learn pester and then recreate everything that I already provided.
Is it possible for you to move forward with the details I have provided as I have already documented the use cases, expected results, and also provided a script and the commands that you can use to recreate each of the examples demonstrated?
Thanks!

@JoeSalmeri  Thanks again for your investigations!

Is it possible for you to move forward with the details I have provided

Oh, the provider code is very large, complex and sensitive. Over the past two years no one dared to do this work, although we already have many such issues.
We are close to 7.0 release and I don't expect that something will be fixed in the area. :-(
I have plans to improve globbing and then the provider code but we already have over 60 opened PRs and MSFT team does not manage to process this flow of requests.

@iSazonov
Yeah, I didn't expect it would make the 7.0 release, however, I hope that after that occurs it is given some priority since we are talking about core functionality and also considering that the confirmation levels are not correct for destructive actions and files are overwritten without warning.
Having code that is so large and complex, which has serious issues and that no one wants to touch does not really seem like a great way to move forward.... :-)
If the provider code is that large and complex, possibly that indicates that all the different providers code should be split out into something that is more manageable and also provides the ability to add future enhancements?
Some of the issues discussed also exist with other cmdlets.   They also existed years ago for Get-ChildItem but those for the most part seem to be addressed now.
I really hope that MS spends time to address core functionality issues more instead of just adding more features and enhancements.
Thanks!

I really hope that MS spends time to address core functionality issues more instead of just adding more features and enhancements.

@joeyaiello @SteveL-MSFT Perhaps it will surprise you as well as me. :-)
I know that MSFT team is very conservative in changing the engine, but still there is an community expectation that we need to move in this direction too.

@iSazonov
I appreciate your response and it would make sense if I was requesting some new features, but I am not talking about new features, I'm talking about bugs in existing features.
It's one thing if a developer has to use a non-PowerShell solution when no PowerShell feature exists and another when the PowerShell feature exists but cannot be used because of the bugs.
Surely no one would argue that a command that does not produce the same results or one that has destructive behavior with no warning would not be working as it was designed or intended too?

@JoeSalmeri I see your point and agree that features "must works right". Really developers (specially MSFT team) split resources and balance between new features, bug fixes and performance improvements. Every day I see how little they do, but when I look at how many PRs have been merged per month, I see a huge amount of work they done!

@iSazonov
Sounds like we are on the same page.  I appreciate all the hard work of the developers, I just want to seem more emphasis on the core / basics over additional features.

First, we have fixed a large number of bugs and not just focused on features.  They are all listed in the Release Notes and you can see them yourself.
Second, the behaviors you're describing have existed since the FileSystemProvider existed and the challenge here is to not break somebody by making a change in behavior.  I agree that the results are not what you expect, but they are consistent with how the provider works.
If https://github.com/PowerShell/PowerShell/issues/5785 ever gets done (which is a feature), we can make breaking changes with that.

@SteveL-MSFT
I don't dispute that the team has fixed a lot of bugs and I certainly appreciate that; I just stated my preference of wanting to see more emphasis on the core features over additional features.   Especially since these bugs have existed since the beginning.
Your second statement seems to say, "Since this behavior has existed since the beginning of time we don't want to change it and break existing code".
So a bug (or even a bad design decision) that has existed since the beginning of time will never be fixed because it would break existing code?   IMHO, that does not seem like a very good business decision to me.
The issue is not a matter of getting results different than would be expected (expectations can be changed) or different than the behavior of pretty much every other copy type utility out there, the issue is that it does not produce consistent results as demonstrated by my examples.
As a developer, you are well aware that intermittent bugs which produce inconsistent results are some of the most challenging ones to debug and fix.
Why would anyone want to write important production quality code which uses functionality which does not produce consistent results?
We both know the answer to that.....They wouldn't.
When PS was first released I immediately found those bugs (and reported them to MS) and figured that they'd be fixed quickly so I delayed using the PS for anything important to wait for it to mature some more.
When they were not fixed in subsequent releases and I wanted to start using PS, I did what probably many others have done.  I used PS but avoided using those built in features that did not work properly or in a reliable way and instead used external functionality which worked properly, however, I certainly did not expect that 7 major versions later this situation would not have been addressed.
When there are cracks in the foundation or the core building blocks it seems prudent to focus on those areas to strength the product so that users are not forced to look for external solutions that should be covered by internal functionality.
It is troubling to see this not being treated as the serious bug that it is

Something to consider -
I don't think this is  abug.  The Copy-Item has some behaviors that have to be digested due to the way folders are seen especially when the trailing backslash is used or not used.  Also the current folder needs to be explicit as well as the target aggregator.  These variations seem to be expected and seem to inherit from the behavior for the old Windows CMD.EXE "copy" command.
Is it possible that the behavior of Core on different platforms also inherits some aspects from the OS it is running on?

The filesystemprovider was written way before I was on the PowerShell team.  It's possible at that time it's working as designed (I can see how current behavior could be designed that way).  I would also agree as a user that it's a bit unexpected.  However, @JoeSalmeri we have to take breaking changes seriously.  We can't simply change the behavior and have years of scripts break because they expected some behavior to work a certain way.  This is the reason I opened the issue on FileSystemProvider v2 as there are other changes I'd like to see and this would allow a breaking change (where users can still opt into v1 for current behavior).

@SteveL-MSFT
Sorry, I did not mean to imply that the problem was your doing or something you created and I
certainly do appreciate all you have done since joining the team!
My issue is with the answers provided regarding the problem.
I have been in the field for 32 years and have programmed in at least 25 different programming
languages during my career.
In all cases there is one common theme and answer to the question, "Why do we write programs?"
We program so that we can automate processes and produce reliable, consistent, and repeatable results.
There are very few cases or reason why we would want to write code which produced results which were not repeatable or consistent (a random number generator comes to mind) as that would defeat the purpose of automating tasks.
If we were discussing what the expected behavior was versus what the actual behavior was that
is something that could be addressed (but maybe not desired) by changing your/my expectations
to match the actual behavior.
That is NOT the case here.  The same code run multiple times does not produce the same results.
Before taking the time to write up that bug and all the various situations, I spent CONSIDERABLE
time trying various syntax (trailing slashes, *, ., and others) to try and find a single syntax
that would produce a consistent result and did not find any for the uses cases described.
A good developer is not going to write new code using existing code which does not produce repeatable results because then their code also becomes unreliable.
I'll bet that most PS developers have taken the route that I have which is to use external tools to
perform that functionality in their code so that they can get consistent repeatable results.
I take breaking code issues quite seriously too, however, when the original code is broke in the first
place, it makes sense to fix it regardless of whether it would break "other" code.
Imagine if the existing Copy-Item had a bug where it deleted the file after it copied it.  Using the
answer you provided, that would not be addressed because it might break existing code that depended on that bug.  I cannot imagine anyone considering that a good reason or answer.
It's been a while since I wrote all that up and reviewed it, however, there were also examples where
data loss occurs because there was no warning or confirmation.   That certainly goes against the
basic PS design principles of not doing harm without a warning.
While I appreciate that you opened the issue for FileSystemProvider V2, I am quite skeptical that it will ever occur based on your response here, your comment about "if #5785 ever gets done", and the fact that these issues have gone unaddressed pretty much since the beginning of PS.
Regardless of whether the existing code is fixed or whether a V2 is created, there should still
be a desire to provide this basic functionality in the product, especially one that is marketed
as the replacement for all of the other shells.
I really hope that someone take up the task of addressing this.

@iSazonov @SteveL-MSFT
Any progress on FileSystem V2?   Was hoping to hear some news as it's been 3 years.
If FileSystem V2 ever going to happen?


Cannot find the API to create and manipulate SPDX v2.3 documents.

Hi team,
I was reading the README for this project and could not find out a way to create SPDX file.
The feature said: "API to create and manipulate SPDX v2.3 documents". Is this feature existed in current version?
Could you guide me how to create a SPDX file from our source codes? I could only find validator and converter cli tools, but not creator for SPDX files.
Thank you so much!

Hi @astroneurosan! You can use the tools-python as a library to create and change SPDX files. So install it via pip and import the classes or methods you need. For more information on how to use it, see the files in the examples directory.. In particular, the file write_tv.py contains some example code on how you would create a new document from scratch. If you want to manipulate a given document, you would first need to use the corresponding parsing method to get the corresponding document and could then change the values in the parsed document. Hope this helps.

Hi @meretp, thanks for the response! We would like to know if this tool can be used to scan our repo and produce SPDX file? or should this write_tv.py be used with other commercial scan tool?

I believe this issue is resolved. If there are further things to discuss, please feel free to reopen it.


why  don't use Android studio

Overview (Required)

Links

Sorry, I'm not sure what you mean.. could you give some more information please?

Let me close.


enforce pragma once in header file

I find my newly added header file not following the style guide Header guards should use #pragma once.
Looks like this is not unique
$ for f in `find include/ source/ test/ -name "*.h"`; do grep "pragma once" $f >/dev/null|| echo $f; done | wc -l
81

I will blindly add the pragma directive to make the future include no-brain.
Do we need a rule formatter to check/fix after the above change?

yeah, looks like it's mostly but not all test code.  It'd definitely be worth adding to the fix format script IMO.

An quick fix is added formatted is not ready.
Also the exceptions are listed below for track

chromium url

source/common/chromium_url/url_parse.h
source/common/chromium_url/url_parse_internal.h
source/common/chromium_url/url_canon_stdstring.h
source/common/chromium_url/url_canon_internal.h
source/common/chromium_url/url_canon.h

test/config/integration/certs

test/config/integration/certs/clientcert_hash.h
...

test/extensions/transport_sockets/tls/test_data/

test/extensions/transport_sockets/tls/test_data/

The source/common/chromium_url should go away soon. I'm not quite certain when deprecation period has started for the code that uses it.

We can close this issue in favor of the merged PR above.


Verify that the cellxgene April 2020 test recommendations have been completed

The April 2020 pentest recommendations for cellxgene were:

Disable HTTP Trace method
Disable all unencrypted connections (force TLS)
Ensure user-facing error messages are non-descript to avoid leaking memory addresses, file paths, or module/software version information

Verify with Bruce that these were actually completed.

@maniarathi - see:

Disable HTTP Trace method
Disable all unencrypted connections (force TLS)
Ensure user-facing error messages are non-descript to avoid leaking memory addresses, file paths, or module/software version information


build(setup.py): Add project_urls for PyPI

Add project_urls to setup.py
For pytest-splinter's PyPI page to get easy links to project pages:

@pytest-dev/pytest-splinter-admin  Anyone willing to approve?

Looks like this won't work, I'm unable to merge, because it waits for non-existent CI.
I don't have admin privs but looks like this could be disabled for now and then fixed with GitHub Actions...

@mpasternak Thank you for the review!
This is a tricky one.  I wonder what the next step is (hopefully this doesn't have to wait until a new CI is up, though that probably needs a PR too)
@pytest-dev/pytest-splinter-admin: Any thoughts on a next step? Anyone have the ability to override? (even if its a future CI PR)


hydrate_FIELD for consistency

Should we add support for hydrate_FIELD for consistency?
Documentation shows dehydrate_FIELD, and you should be able to do the opposite for importing the same file you have exported.

Yes it should be nice to add hydrate_FIELD


Convert to Search UI

The only thing I couldn't carry over support for was the urlFieldTemplate configuration option because it would have required me writing a custom view for the Result component, which I didn't want to do.
Before:

After:

Just to get some context for this - I assume Reference UI was the original progenitor / idea for Search UI, before we made it a reusable library/package? If so - do we at some point in the indeterminable future want to scrap Reference UI in favor of sending people directly to Search UI with an App Search example? 🤔

Just to get some context for this - I assume Reference UI was the original progenitor / idea for Search UI, before we made it a reusable library/package? If so - do we at some point in the indeterminable future want to scrap Reference UI in favor of sending people directly to Search UI with an App Search example? 🤔

Yep, that is exactly what happened.
@constancecchen Well, the idea with Reference UI, is that you can run it and simply control which facets show up, what sort options show up, etc. etc. all through a single configuration file.
One way a user could do this would be to simply clone this repository, create an engine.json file, and then run it.
But the more interesting thing that we do is in the App Search dashboard. We allow users to do the configuration of Reference UI through a dashboard screen, and then also, optionally download it so they can check out the code, run it locally, etc.
I don't know if that answers your question or not.
It would be kind of cool if the "Reference UI" was a separately deployed thing associated with Search UI, so you could play with and configure Search UI without ever having to work with React.

Ahhh gotcha, I see now! My (mistaken) assumption is that this was mostly just being used for source code/reference rather than something downloadable - this makes total sense with that context :+1:


[ellens_alien_game] change "hit" from task 1 to task 2

See forum

I jumped the gun and should have asked the reporter if they're like to file a PR.

I did not read until the end of the thread and also did a PR before I saw yours. We are bad people :D


Random Crashes

[x] I have checked for a similar issue and sure it hasn't been reported before.

Describe the bug
The app crashes randomly but more specifically when using an video/audio call application like slack or google meet. But sometimes i'm just using spotify and it just hangs or crashes all together.
Steps to Reproduce

Run slack (huddle) or google meet
Might stop working in the middle of it or not, depends from time to time

Expected behaviour
To not crash when these things are used.
Setup information:

Macbook Pro M1 speakers
Direct sound from the computer
macOS 13.0
app 1.7.2
ui 4.4.1

Screenshots or Console.app logs
No screenshot since it's a crash
Additional information
Wish i could give you more info
Otherwise, very very good app.

Hi, there is some issues around calling in general, and I would prefer this issue to be tracked here #605. As for crashes, I think the latest version is more stable now, please try it out. If you still have crashing issues, please reply/comment/reopen this issue, thanks!


Doesn't call mocked function from a called function!

Hi all,
I'm new to PHP unit testing so please advise if I'm dong anything wrong. This is the scenario:
In our main code, there is a function (say b) that calls another function (say a). I want to test b() without having to test a() so want to make a mock of a. However in my test call when I can b() it still calls the original a, not my mock. Here is my code:
In my test file:
<?php
namespace AA\BB\CC;
use PHPUnit\Framework\TestCase;
use phpmock\MockBuilder;

class XYZ extends TestCase {
        private $a_mock;

        public function testb() {
                $a_builder    = new MockBuilder();
                $a_builder->setNamespace(__NAMESPACE__)
                        ->setName("a")
                        ->setFunction(
                            function ($str) {
                                return $str;
                            }
                        );

                $this->a_mock = $a_builder->build();
                $this->a_mock->enable();
                $result = b("Hello");
                        // NOTE: If I call a() here, then the mock version is called
                        // but if b() is called, it calls the other a() defined below
                $this->a_mock->disable();
        }
}

In our code base (I don't see any namespaces defined here):
function a($str) {
        // do something
}

function b($str) {
        return a($str);
}

Please note: the problem is still there if both the files have the same namespace!

@asra-baig  Do you have both these function in the one file? If so I think it's not gonna work because you can't overload already loaded function in the namespace.

No they're in different files. Although I'm sure the actual function is
already loaded since the code I'm testing calls it!
On Thu, Mar 22, 2018 at 11:00 AM, Michał Bundyra<EMAIL_ADDRESS>wrote:

@asra-baig https://github.com/asra-baig Do you have both these function
in the one file? If so I think it's not gonna work because you can't
overload already loaded function in the namespace.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/php-mock/php-mock/issues/19#issuecomment-375359989,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AiDe4iS0nPKARPyHHnzbHgptQobXsysHks5tg8q5gaJpZM4SIvpp
.

@asra-baig
I've created that repo to demonstrate how it works:
https://github.com/webimpress/php-mock-test
So basically you can mock only function class in a namespace. If you have a function call in global namespace you can't mock (overload) the function there.
So in your example - function a() is called inside function b() in global namespace, so there is no way to mock it, because it will be always called in context of global namespace.
Please see my examples in test repo I've created (see above) and let me know if all is clear now or you have further questions.

Closing due to inactivity


docs: add more info on conditional keys #195

Issue #, if available: #195
Description of changes:

This PR changes Logger's example where a conditional key was added but not removed if it wasn't present in subsequent invocation - Based on #195, this provides a safer example, and a note as to why it is so.
Checklist

[x] Meet tenets criteria
[ ] Update tests
[x] Update docs
[x] PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Merging as the highlighted portion addresses the original ask in #195


Please add an "abandon 996" badge (not a clause) to support us

What problem does this feature solve?
Chinese software engineers are protesting against the country ’ s 996 work schedule.
An unleagal work schedule (9a.m. ~ 9p.m., 6 days a week) .
Add a badge
Add a badge to your awesome project by pasting this line in your README.md.

What does the proposed API look like?
no API

https://github.com/vuejs/vue/issues/9791#issuecomment-478250030


Experimental Spring/Liberty Stack

Checklist:

[x] Read the Code of Conduct and Contributing Guidelines.

[x] Followed the commit message guidelines.

[x] Stack adheres to Appsody stack structure.

Contributing a new stack:

Describe how application dependencies are managed:
Hybrid of Spring & Microprofile stack, to offer Spring on Liberty.

Explain how Appsody file watcher is utilized:
TBD

Describe other Appsody environment variables defined by the stack image:
n/a

Describe any limitations and known issues:
Tested as far as appsody init and appsody run, more to follow.

Tested and checked:

[x] appsody run

Changes to files picked up in: ~20 seconds.

[x] appsody test
[x] appsody debug
[x] appsody build
[x] appsody deploy
[x] Build script (Lint, list etc.)
[x] README structure
[x] Dockerfile-stack structure


Document filesystem support.

This is related to issue #74 Document COCONUT-SVSM.

I just realized that PR #145 changes the src/fs structure significantly.  If that gets merged, this PR may not be relevant.


React does not recognize the disableScrollLock prop on a DOM element

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
When I use disableScrollLock in Modal, which React Throw warning.
React does not recognize the `disableScrollLock` prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase `disablescrolllock` instead. If you accidentally passed it from a parent component, remove it from the DOM element.

Expected Behavior 🤔
This props can use without Warning.
Steps to Reproduce 🕹

Steps:

Context 🔦

Your Environment 🌎

Tech
Version

@material-ui/core
v4.?.?

@material-ui/pickers
v4.?.?

React

Browser

TypeScript

etc.

update version is no warning.


Fixed compatibility with Nette 2.4.0 again

Coverage remained the same at 100.0% when pulling d0b421f33fd953f7399dee65ad68633b7cde14e1 on kukulich:master into d3890aadfcb7ce63b5ca7ab301708926fbe46ebe on nella:master.


Errors after initial installation

I'm using the editor 2021.3.19f1 with built-in render pipeline as well, but getting the following errors right after package import.. I cant see a Genesis tab in menu, probably because of this?

Good catch, seems like I forgot to add the "com.unity.nuget.newtonsoft-json" package as a dependency. If you add that via the Package Manager, everything should be good. I'll update the package with the missing dependency.

Alright. good luck on the project :)


Sparse dvr

Use the library sparse to represent the sparse u-matrix elements. Since sparse does not yet have an einsum-implementation, all einsum-calls have to be rewritten to tensordot if this is going to work. Is this a feasible and/or desirable task?

Hmm, come to think of it, you need to merge with master first. This pull request looks to be a little behind.

Huh, doesn't github show merge-commits from master?

Lets do the merge! :champagne:


[Speculative Decoding] Fixing hidden states handling in batch expansion

This PR fixes the handling of hidden_states in batch expansion.
Fix #7505

/ready

can you add a test?
what exactly does this fix? were the hidden states applied incorrectly?

can you add a test?
Would an E2E test be sufficient? I can add the example I mentioned in the issue where we see the error.

what exactly does this fix? were the hidden states applied incorrectly?
There was an error in a specific scenario. Consider sequences for which spec. decode is disabled (e.g., when num_tokens + spec_tokens > max_model_len). For such sequences, proposal length is set to 0 and they are handled separately from other sequences. Then when contracting the batch (in BatchExpansionTop1Scorer._contract_batch), we merge spec and non_spec sequences into shape (batch_size, spec_length + 1). While this is done correctly for other tensors, hidden_states were kept unchanged before and only reshaped later on: https://github.com/vllm-project/vllm/blob/fc93e5614374688bddc432279244ba7fbf8169c2/vllm/spec_decode/spec_decode_worker.py#L650

This reshaping works fine if all sequences have proposal length > 0, but if for any sequence spec decode is disabled, it doesn't work. This PR changes batch expansion (mainly BatchExpansionTop1Scorer._contract_batch) such that hidden_states are manipulated and arranged like other tensors like tokens, probs and logprobs. This ensures hidden_states are correctly updated in all cases.

Thanks for the writeup.

Would an E2E test be sufficient? I can add the example I mentioned in the issue where we see the error.

An E2E test is good. I think the issue here is that we should validate an accuracy level, not just that it doesn't crash. For this you can build on this PR https://github.com/vllm-project/vllm/pull/6454 which adds an assertion that draft acceptance rate is 100%.

An E2E test is good. I think the issue here is that we should validate an accuracy level, not just that it doesn't crash. For this you can build on this PR #6454 which adds an assertion that draft acceptance rate is 100%.

Makes sense, but any draft model which uses hidden states can't be identical to the target model. In that case I am not sure if we can get draft acceptance rate of 100%. What do you suggest then?

You can run it for the test prompts and record the accuracy, then assert it doesn’t go below that fixed value plus some epsilon.

@cadedaniel I've added the test along with other MLPSpeculator tests. Can you please review? Thanks!

@cadedaniel you good with this being merged?


tour: Wrong initial code

Context: https://go.dev/tour/basics/3
Hi, I think the initial code for this context is wrong, and line 9 is meant to be
fmt.Println(math.pi)
So the user could execute the code and get an error, before changing it to
fmt.Println(math.Pi)

It is, but if it was changed the modification is remembered in the browser session.


Introduce LIVEBOOK_HOME and LIVEBOOK_DATA_PATH

And move the relevant configurations to settings.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


video fixed 定位才能点击控件

我的布局：video放在slider标签里面，slider外层有两个scroller组件，最外层是横向的scroller标签，外层是竖向的scroller标签。 这样布局无法点击视频原生的播放按钮,但轮播图可以切换。 给视频加上fixed定位，播放按钮可以点击。求各位大佬解答？

@singlehcc  weex 的层级是后者在上的，所以看一下你的布局是否被后者盖住了

This PR/issue doesn't received response since Weex migrated to Apache two years ago and this repository is no longer active yet.
Feel free to ask question in new repository and thanks for your contribution.

This issue is outdated for a long time and will be closed now. You can create a new one if you still have questions.


Idea for new helper method FieldList::dataFieldByType()

I've been playing around with type hinting, and forcing the use of /** @var */ is irksome. I'm keen to see if we can provide mechanisms for avoiding it with dynamic type hinting.
$fields = parent::getCMSFields();

/** @var GridField *./
$grid = $fields->dataFieldByName('Items');
$header = $grid->getConfig()->getComponentByType(GridFieldSortableHeader::class)

I'm wondering in this would be better:
$fields = parent::getCMSFields();
$grid = $fields->dataFieldByType(GridField::class, 'Items');
$header = $grid->getConfig()->getComponentByType(GridFieldSortableHeader::class)

The dataFieldByType() method would do 3 things:

Allow type hinting for VS Code and PHP form to know the return type
Throw an error if the given field was not of the given type, introducing some more type safety
The 2nd argument could be optional, in which case it would just return the first grid field. For stuff like modeladmin customisation this would be handy - there's always a single grid field in a modeladmin, but its class changes.

The implementation would be something like:
function dataFieldByType(string $class, string $name = null)
{
  if ($name  !== null) {
    $field = $this->dataFieldByName($name);
    if (!($field instanced $name)) throw \InvalidArgumentException("Field $name is not of class $class");
    return $field;
  } else {
    foreach ($this->dataFields() as $field) { if ($field instanced $class) { return $field); }
    if (!($field instanced $name)) throw \InvalidArgumentException("No field of class $class found");
  }
}

By adding this as a new method rather than trying to modify the behaviour of existing methods, backward-compat is easy
Before doing a PR I was keen to get feedback on how useful this kind of type-safety-support method would be to others.

From the suggested implementation (I get it's an indication only) I'm not sure I understand how would the dataFieldByType method get the type and how would it be useful for static analysis.

You'd need to populate .phpstorm.meta.php as well (which also works in VS Code) - see #9658. Other static analysers could be configured also, e.g. with a PR to https://github.com/symbiote/silverstripe-phpstan.

Right, so on its own it won't be of much help without other helpers/tooling understanding the mechanism of it.

Yeah basically it makes the configuration of those other helpers possible.

It's also worth noting that you could do something similar with injector, where another method let you define the expected class or interface and throw an error if that was bad.

It looks like phpstan could be amended to work with such methods merely by changing the docblocks https://phpstan.org/blog/generics-in-php-using-phpdocs

What happens if you call $fields->dataFieldByType(TextareaField::class, 'Description') but an extension has changed its type to another type of field?

What happens if you call $fields->dataFieldByType(TextareaField::class, 'Description') but an extension has changed its type to another type of field?

If it's replaced with a subclass of TextareaField then in either case is fine (the check would be an instanceof check which subclasses pass)
If it's a completely different check:

Status quo: your code that expected a TextareaField will run with some different class. Maybe it works, maybe it will break, maybe the break won't be noticed until production, maybe the break will cause data loss

With my proposed change: the code will break immediately saying "TextareaField expected but DropdownField found"

In other words, I'm arguing that an immediate failure is an improvement on the status-quo.

Well, if the current approach stays available too, meaning you'll be able to get a field by its name regardless of its type to for example add a description to it (where you don't care about its type), then all good.
If a dev chooses to have a bit stricter control e.g. to always get a WYSIWYG to apply config to it, this might be a good option.

Yes, dataFieldByName() will remain as an option. If we were to use dataFieldByType() in core code or widely-used modules, this may have an impact to sites that have customised built-in fields. As such I would recommend using dataFieldByType() only in cases where the correct type is necessary for subsequent code to function correctly. In particular, I would advocate using phpstan to identify overly loose type assumptions and fix them with dataFieldByType() to guard against currently unprotected error cases.

the use of /** @var */ is irksome

It is pretty ugly syntax, though that is basically the "proper" way to "declare" a type in PHP.
If you we want to do more type check at runtime, possibly we write a static utility functions somewhere and use that instead of having to change a bunch of function to equivalent functions that also include a type check. e.g.
class MyUtilityThing {
  public static confirmClass($object, $class):void {
    if (!($object instanceof $class)) throw \InvalidArgumentException("Object $object is not of class $class");
  }
}

...
$grid = $fields->dataFieldByName('Items');
MyUtilityThing::confirmClass($grid, GridField::class);

I guess you could do that, but personally I'd prefer a type-aware API. In particular:

it combines the runtime check and static analysis hint into the same construct. (I'm not sure if the assert-style utility method you propose can feed appropriate metadata to PHPStorm)
it makes it harder to forget to do the type (if you call the method, it's a required arg)
it's easier to chain for brevity, where that's of use
static methods on a separate utility class add more cross-subsystem coupling

Less importantly, it adds the edge-case feature of choosing a field without a name (which is basically for getting the grid field in a model admin's root form)
Happy to hear other opinions though, if I'm in the minority here @silverstripe/core-team

I have no problem at all with /** @var TypeHere $varName */ syntax.
Ideally we start implementing more type hints as we built new PHP 7 compatible APIs, then we need less of the PSR-5/19 annotations.

I'm more with Robbie here, I'm used to ugly syntax and I'd prefer to not create a non-native type checking implementation
That said, you could do it this way instead
trait MyTrait
{
    // possibly misleading naming as it's just asserting the type instead of casting it ...
    public function asType(string $type) {
       $thisClass = get_class($this);
        if (!($this instanceof $class)) throw \InvalidArgumentException("Object $thisClass is not of class $class");
        return $this;
    }
}

class DataObject / GridField / DataList ...
  use MyTrait

$grid = $fields->dataFieldByName('Items')->asType(GridField::class)->doSomething();

Possibly you could then do something with MyTrait::asType in .phpstrom.meta.php?
https://github.com/silverstripe/silverstripe-framework/issues/9658

Ideally we start implementing more type hints as we built new PHP 7 compatible APIs, then we need less of the PSR-5/19 annotations.

Yeah, nah, that's not possible without something like what's suggested here. Because dataFieldByName can only be hinted to FormField, but very frequently will be assumed to be, e.g. GridField in the code that follows.
PHP's "real" typing lacks the sophistication for something like dataFieldByType / asType to work, but phpstan and phpstorm both do.
The trait approach is interesting, Steve. I'd probably call it "assertType" at that point, but you could build that trait and add it to FormField.

I'd be happy to add a utility method like this, as I think it has a purpose beyond purely helping out with type hinting, but I'm not completely convinced.
Are we creating more upgrade work for ourselves later if we start specifying types that could be subject to change? SilverStripe hasn't typically been strict with types; is that something we want to move more towards?

If you have written code that fetches a form field and calls ->getConfig()->getComponentByType() on the result, then if the field returned is anything other than a GridField, you're going to have a bad time. So forcing it to be GridField doesn't make things harder.
The point is to use this helper sparingly, only to ensure that the method calls you make align with the type being asserted. Which phpstan or PHPstorm will warn you about if the typing is too loose.

Alternatively we could use this:
$fields = parent::getCMSFields();
$grid = $fields->dataFieldByName('Items');
assert($grid instanceof GridField);
$header = $grid->getConfig()->getComponentByType(GridFieldSortableHeader::class);

Compared to the manual type-hint the code looks similar:
$fields = parent::getCMSFields();
/** @var GridField */
$grid = $fields->dataFieldByName('Items');
$header = $grid->getConfig()->getComponentByType(GridFieldSortableHeader::class);

Key advantage is that it will fail at runtime as well as pick up a type error.

It works in PHPStAn https://phpstan.org/r/9b405a35-5203-45f7-9cd0-2e611d9e2331
It also works in PHPStorm and VS Code type hinting

Since it needs no new code, perhaps that's better? Use assert(... instanceof ...) in favour of @var to get both runtime and lint-time type awareness?

I'm going to close this I think, assert() is less invasive.


VSCode not running discovered PyTest tests when path contains a symlink

Environment data

VS Code version: code --version
1.60.2
7f6ab5485bbc008386c4386d08766667e155244e
x64
Extension version (available under the Extensions sidebar): v2021.9.1246542782
OS and version: Ubuntu 20.04 5.4.0-84-generic
Python version (& distribution if applicable, e.g. Anaconda): 3.8.10
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: Pytest 6.2.5
Relevant/affected Python-related VS Code extensions and their versions: (probably unrelated) Pylance v2021.9.4
Value of the python.languageServer setting: Pylance

Expected behaviour
Run discovered Tests when running all tests.
Actual behaviour
Tests are discovered correctly but doing Run All Tests will turn the icons blue briefly and then return to the state before running them (gray circle with black box in the middle) almost instantly.
Steps to reproduce:

create a folder called e.g. repositories
checkout out any python project containing a test-folder with pytest tests
verify these tests run using the discover tests and run all tests features
move the repository folder to a different path(in my case a path on a different drive)
create a symlink using ln -s /new/path/to/repositories /old/path/to/repositories
verify your symlink is correct by either ls -l or by doing cd /old/path/to/repositories
start vscode with the path containing the symlink so cd /old/path/to/repositories/code_repo && code .
Tests are discovered correctly but doing Run All Tests will turn the icons blue briefly and then return to the state before running them (gray circle with black box in the middle) almost instantly.
Close VSCode and cd into the repo without a symlink in the path(cd /new/path/to/repositories/code_repo && code .
Tests now run again!

Logs
Sadly not output whatsoever, the only indication of clicking on runalltests(or using ctrl+shift+p to do it) is the briefly blue-flashing icons next to the tests.
This is the Output -> Python output but as mentioned above, doesn't seem relevant:
User belongs to experiment group 'pythonaacf'
User belongs to experiment group 'pythonJediLSP'
User belongs to experiment group 'pythonDiscoveryModuleWithoutWatcher'
User belongs to experiment group 'pythonTensorboardExperiment'
User belongs to experiment group 'PythonPyTorchProfiler'
User belongs to experiment group 'pythonDeprecatePythonPath'
User belongs to experiment group 'pythonSortEnvs'
User belongs to experiment group 'pythonRunFailedTestsButtonDisplayed'
User belongs to experiment group 'pythonRefreshTestsButtonDisplayed'
User belongs to experiment group 'pythonRememberDebugConfig'
Python interpreter path: /usr/bin/python3
Starting Pylance language server.

Same issue breaks Pylance as well. This morning, I added a symlink to my home directory on WSL (unrelated to any project repo) and noticed the linter was broken. Found this issue, deleted the symlink, and it starts working again immediately.

Ran into this issue as well. Linting and testing broke if I opened the folder with a symlink in its path.

Consolidating all issues on testing and symlinks to issue https://github.com/microsoft/vscode-python/issues/9347. Let me know if you do not think this other issue is representative of the bug you are facing. Thanks!


Experiencing issue with addPeriodicTimer seemingly just stopping randomly

Hey there! I'm using PAWL which implements reactphp event loop. I'm using it to connect to a websockets server. Once connected, I'm using $loop->addPeriodicTimer() to send a heartbeat back to the websockets server every 15s. This runs pretty solidly but at some point it just stops. No disconnect message from the websockets server. Absolutely no indication of it stopping.
This last time, it got up to heart #769. I am logging the sending of the heartbeat and the response back from the server. I received a response back for the 769th heartbeat, but the periodicTimer never sent another heartbeat.
I'm attaching an image of the logs:

I've attempted adding $loop->addSignal(SIGINT, ....) to capture a system disconnect (assuming that's what this would trigger from), but it never gets triggered. I have $conn->on('close', ...) that never gets triggered at this point either.
It's as if the periodicTimer just stops. I checked the server resources at the same time and everything looks great there too. Only about 20% CPU usage, memory is low, nothing looks out of sorts. I'd just love to know how I can programmatically detect when this disconnect happens so I can reconnect. It's happening just about every day.
Thanks guys!
Matt

@mattmintun Good question, this definitely shouldn't have happened!
We're not aware of any such issues in the event loop or Pawl, I've personally used both in a number of project that have been running for months straight with no issues whatsoever, so this is definitely known to work.
It's a bit hard to diagnose with the input you've provided, perhaps you can gist your code so we can reproduce this locally or see what could be wrong?

I believe this has been answered, so I'm closing this for now. Please come back with more details if this problem persists and we can always reopen this :+1:


Wrong variable used in expression

[version 1.0.3]
In addons/godot_3_to_4_file_conversion/crypt_godot3.gd, func decrypt(), this line:
length_rounded_up = length + 16 - (length_rounded_up % 16)
should be:
length_rounded_up = length + 16 - (length % 16)
This bug does not appear to affect the functionality.

This is fixed in version 1.0.4.


release: v0.8.0

Description
Including the following changes:
- feat: allow configuring the token endpoint (#137)
- feat: add per-HTTP request counter metric (#135)
- refactor: remove SDK version for OpenTelemetry meter name (#134)
- fix: only send SDK method header from SDK wrapper methods (#142)
- fix: unable to pass `retry_params` (#144)
- fix: list users should send contextual tuples as a list (#147)
- fix: handle no models existing in `read_latest_authorization_model` (#147)

References
Generated from https://github.com/openfga/sdk-generator/pull/454
Review Checklist

[x] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[x] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

If you haven't done so yet, we would appreciate it if you could star the OpenFGA repository. :)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 68.77%. Comparing base (041a713) to head (de37e15).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #150   +/-   ##
=======================================
  Coverage   68.77%   68.77%
=======================================
  Files         124      124
  Lines        9914     9914
=======================================
  Hits         6818     6818
  Misses       3096     3096

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


[Error] Trying to run project locally

Hi! I just clone your project and already install all dependencies, but I got this error:

Any workarounds?

Ah my bad, I forgot to create .env


Add configurable time

Porting https://github.com/swift-nav/pings/pull/6 to Rust version

Tested with cargo run -- -v --epoch<PHONE_NUMBER> --url xyz:abc@na.skylark.swiftnav.com:2101/CRS | rtcm3tosbp | sbp2json

Having the time as a more user-friendly timestamp would have been nice. The epochs things was easy and helped me track down a bug quickly, but wasn't very easy to use from the command line.


Adding support for tracking instance hypervisor type in ENI limits pkg

[ upstream commit 2cd83ee6db83d51980f637176becab7fd51dbd0e ]
Signed-off-by: Hemanth Malla<EMAIL_ADDRESS>Signed-off-by: Tom Hadlaw<EMAIL_ADDRESS>Please ensure your pull request adheres to the following guidelines:
Backporting recent update to the eni limits map so that v1.10 has up to date list, as well as recent changes to the limit structure so that we can easily backport these updates in the future.

@tommyp1ckles the CI failure is legitimate.

/test

/test-backport-v1.11

/test-1.22-5.4

/test-1.24-net-next

/test-1.22-5.4

/test-1.24-net-next

/test-backport-1.11

/test-ci-aks-1.11

/ci-aks-1.11

/test-backport-1.11

/test-backport-1.11

/test-1.22-4.19

/test-gke-1.11

/test-gke

/test-gke

/ci-gke-1.11

/test-gke


Can nightmode be improved

When night mode it on it messes certain images and seekbars on websites as shown below.
Night mode on:

Night mode off:

The seekbar is especially the intolerable part because on a lot of websites i can't see it at all so i have to disable night mode when try to watch videos.
Edge has a setting in the flags called "Auto Dark Mode for Web Contents" and it gives you the option "Enabled with selective inversion of non-image elements". This fixes most of the image changes i've seen (except the seekbar problem), but that setting doesn't exist in Kiwi's flags. Could improvements be made to night mode to fix these issues?

Use temporarily unexpire flag fool!

Use temporarily unexpire flag fool!

I don't know what that is/does, asswipe

Would be great if we could just use the official Chrome app's dark theming ("darken websites"). The colours and contrast are absolutely perfect and it doesn't have these issues

Or maybe just use Drake Reader extension?

Or maybe just use Dark Reader extension?

Dark reader slows browsers down. That's been an issue with it for while now. Plus it also has these issues.
Also why download an extension to get an already built in feature? That's literally just addon extra bloat that needlessly uses up more resources. It's probably just a me thing but i absolutely hate having multiple apps/extension/addons/etc that do the same thing and avoid doing so where ever i can, so i'm asking for what's already there to be improved


Feat: Banners should stack

Right now, it's only possible to show one banner. They should instead stack and disappear one after another

If more details about the issue could be provided, that would be helpful, for example, how to reproduce the issue?


refactor: Updated section-list styles to used styled-components

Question
Response

Version?
v1.4.0

Devices tested?
iPhone 7

Bug fix?
yes

New feature?
no

Includes tests?
no

All Tests pass?
yes/no

Related ticket?
#532

Screenshots

Before
After

Description
Converted some of section-list to use Styled-components.

Please advise on how could this be improved, I did find it confusing trying to convert the View for TopHeader, List and ListItem as styled components don't play nicely with react-native-elements.
Thanks.

Coverage increased (+0.2%) to 39.553% when pulling 49cb192574a52b4427d3377f709d5474676051d1 on jamesg1:feature/migrate-sectionlist-styled-comp into 753f60c23a6208894125be15fa17fe0d22cc620b on gitpoint:master.

@chinesedfan I've made those requested changes, Thanks

Coverage increased (+0.2%) to 39.553% when pulling 94672b40d4510fad8453a5f1742e85896df17b77 on jamesg1:feature/migrate-sectionlist-styled-comp into 753f60c23a6208894125be15fa17fe0d22cc620b on gitpoint:master.

Hey @jamesg1! react-native-elements 0.18.1 was published yesterday and I'm working on a PR to upgrade to it and fix all the problems introduced with styled components.
Putting this PR on hold until I'm done, then I'll be happy to help you with this one if needed

@machour @chinesedfan Sorry for the delay updated this PR with some changes 👍

Will update code with style changes and screenshots.

Updated PR with styling changes and screenshots. Thanks 👍

@jamesg1 the screenshots looks weird in the header (time overlapping with your avatar) is that when you're scrolling down?

Yeah its because its scrolled. Good pickup I'll fix them now.

Working as expected on Android 🎉


[native_asset_cli] Trim dry_run of architecture, build_mode, etc.

Addresses the remaining concerns in:

https://github.com/dart-lang/native/issues/51

@HosseinYousefi feel free to postpone reviewing until after https://github.com/dart-lang/native/pull/65 is merged and this rebased to reduce the diff.

Thanks @HosseinYousefi ! 🚀


Create confirmation page

As a program applicant
I want an application received confirmation page
so that I can be sure my application has been received
*this page should be made as a mock-up with no real functionality
AC:

[ ] new page with confirmation of received application
[ ] confirmation number and timeline for re - engagement by gov
[ ] links for new application and to return home
[ ]  screenshot and share on Miro board

Ref #195


Deleting an exercise form a list with swipe gesture deletes the exercise from all lists

Description
When you delete an exercise from the list using the swipe gesture, the exercise is not only deleted from the list but from the "All exercises" list.
Solution
Swiping to delete the exercise in ExerciseListDetailView should only delete the exercise from the list.
Video

@heyjaywilson I'd like to tackle this one if that's ok :)


Update post-1.0 release versioning proposal.

cc @brendandburns @lavalamp @thockin @ghodss @kelseyhightower @zmerlynn @smarterclayton

Please no. See #11495 .. your proposal isn't semver.org compliant.

I have a further pull that actually enacts the tags and the rest of the machinery to enact versioning.md, BTW.

... but it doesn't work until #11676 is fixed by #11622, so I kind of put it on ice and started working on other things.

I think we still want to have beta tags, because we want to make a distinction between API objects in Alpha (no assurances, lots of things may break, don't depend on them) and API objects in Beta (try hard not to break) vs RC (definitely won't break)
The purpose of this (and running alpha and beta at the same time) is that we'd like users to be able to start using API objects that we think are mostly hardened before we get to the RC stage.
I suppose we could also do this by having a v1-beta and v1-alpha API path in the API server, and not worry about it in the versioning...

The API track should be separate from the raw biweekly version track, shouldn't it? (I'd assume we'd create a v1.1alpha1 track or something when there was a need.)

API version shouldn't be tightly coupled to the binary version. We can serve multiple api groups.

Agree with @lavalamp
I proposed eliminating rc track, not beta. We could keep rc, but it should be cut from head, imo

Then I don't quite understand the relevance of https://github.com/GoogleCloudPlatform/kubernetes/pull/11708#issuecomment-123859579 to this conversation.

Oh, I see now. Carry on.

LGTM

So how do we handle new objects that are in flux? How do we indicate that those new objects (that would presumably be added to the v1 api since they do not break backwards compatibility) are changing until a non-alpha/beta release?

They'll go into a experimental api group, and once they're stable and we're
happy, we'll promote to the main api group (if appropriate).
On Wed, Jul 22, 2015 at 2:52 PM, Sam Ghods<EMAIL_ADDRESS>wrote:

So how do we handle new objects that are in flux? How do we indicate
that those new objects (that would presumably be added to the v1 api since
they do not break backwards compatibility) are changing until a
non-alpha/beta release?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11708#issuecomment-123877492
.

Or API plugin, once we have that

We can also have alpha and beta API versions

Waiting on changes in response to @zmerlynn's comments, then this is ready to go, I think.

Updated to address feedback. Will squash after lgtm.

LGTM but defer to others

LGTM  @zmerlynn

LGTM


[v2.2]: Fixed Issue #10204

Issue Reference
Fixed isse #10204
Description
Added check on the product carousel component if the product have atleast 5 products, then the carousel change button will show.
Branch Selection

[ ] Target Branch: 2.2

Checked and found that the crousal issue has been fixed and working fine. Please check the video for reference.
Video
https://github.com/user-attachments/assets/5f6a1549-0357-48ab-bba4-0aeb5138c409


Any working UNET spectator view scene available for download? Able to transform position. Unity 5.6.2f1 preferred.

Overview
Expected Behavior
Actual Behavior
Steps to reproduce
(Links to sample github project preferred)
Unity Editor Version
Mixed Reality Toolkit Release Version

Closed empty issue


Issues with pyepics finding libca

With a 2021-1.2 environment
[tcaswell@xf28id2-srv1 ~]$ conda activate /opt/bluesky/qserver/conda_envs/qserver-collection-2021-1.2/(/opt/bluesky/qserver/conda_envs/qserver-collection-2021-1.2) [tcaswell@xf28id2-srv1 ~]$ conda list | grep -i epic
epics-base                7.0.4                h68659b9_0    nsls2forge
pyepics                   3.4.3                    py37_0    nsls2forge

Trying to import pyepics will eventually fail with:
(/opt/bluesky/qserver/conda_envs/qserver-collection-2021-1.2) [tcaswell@xf28id2-srv1 ~]$ ipython
impPython 3.7.7 (default, Mar 26 2020, 15:48:22)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.21.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import epics.ca

In [2]: epics.ca.find_libca()
---------------------------------------------------------------------------
ChannelAccessException                    Traceback (most recent call last)
<ipython-input-2-476db334b910> in <module>
----> 1 epics.ca.find_libca()

/opt/bluesky/qserver/conda_envs/qserver-collection-2021-1.2/lib/python3.7/site-packages/epics/ca.py in find_libca()
    331
    332 def find_libca():
--> 333     return _find_lib('ca')
    334
    335 def find_libCom():

/opt/bluesky/qserver/conda_envs/qserver-collection-2021-1.2/lib/python3.7/site-packages/epics/ca.py in _find_lib(inp_lib_name)
    327         return dllpath
    328
--> 329     raise ChannelAccessException('cannot find Epics CA DLL')
    330
    331

ChannelAccessException: cannot find Epics CA DLL

Debugging this, the search path for pyepics ad-hoc library search path does not include where the epics libraries actually are (the underlying bug here is that pyepics re-implements library discovery but unfortunately that is not actually fixable upstream).  A work-around is to do
export PYEPICS_LIBCA=/opt/bluesky/qserver/conda_envs/qserver-collection-2021-1.2/epics/lib/linux-x86_64/libca.so

before starting IPython, but this is obviously not a generalizable solution.
It is possible that this will need to be addressed in the CF builds of either pyepics or epics-base.

Thanks for the report, @tacaswell! Is it reproducible on newer conda envs, such as 2021-3.0?
I also wonder if the "DLL" is Windows slang, but I assume it was meant to be "shared object" libraries.

Yeah, the error message is from pyepic's home-grown search logic and has a windows-specific accent.

@tacaswell, do you have a solution for that? I don't think I observed any issues on the floor with the new conda env...


Dependency injection of isReal

@ConradSkelly
he isReal flag is passed into the constructor. However, the checks to see if the robot is real in the constructor and periodic are calling Robot.isReal(). Change these references from the Robot to the this.isReal flag. This allows you to remove the import of frc.robot.Robot.
https://github.com/koibots8230/RumbleBot2024/blob/eef158144149c2a53edf250ccf615ac48a637772/RumbleBot2024/src/main/java/frc/robot/subsystems/Shooter.java#L66

I see that the private final changes were made in the dev branch. I'm not seeing any changes to the use of isReal.
Please use the gitflow branching strategy. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Feature development of the shooter should be on the shooter branch. When it is ready, the code is merged to Dev and the feature branch goes away.
This avoids having bad merges where code just disappears. Been there done that, it is horrible.


[Serialization] Misc prep for the deserialization safety feature

Deserialization safety is a WIP feature to prevent reading internal details, it acts earlier than recovery on issues like XRef errors caused by implementation-only imports.
This is a followup to https://github.com/apple/swift/pull/62886 with general fixes to prepare for enabling the feature by default:

Accept the UnsafeDeserializationError error where we already accept XRefNonLoadedModuleError as the new error should always hide the previous one when the safety feature is enabled.
Update tests expecting to see non-public information to disable the safety feature that would otherwise hide non-public decls.
Update the doc on EnableDeserializationRecovery.

@swift-ci Please smoke test


Custom Domain possible?

how can i use this with a custom domain like i would manually using cloudflare

This is just a python wrapper for cloudflared, so you can use it just like using the cloudflared cli.


No support for Azure DevOps in the Helm Chart

Hi!
The server supports configuration with Azure DevOps but not the Helm Chart.  Is it in the works?  When can we expect parity between the chart and the server features?
Thanks

PR submitted 🎉


Add Orange Cones to YOLO Model

Is this a task that needs tracking? Probably looking for @b1n-ch1kn for comment here...

Yeah this is good. First, we need some data. carpark or track pushing our trolley around with blue, yellow and orange cones setup. I won't be in for the rest of the week, might see about next week or if anyone is in earlier

@b1n-ch1kn to collect more data for this at some point

@Braytho29 to talk to @b1n-ch1kn about making a PR with wieights file


Fixed Windows wildcard tab expansion problem that was reported in #5879

In the dos_expandpath function I have removed code that in case the match was not found, caused the file path match loop to repeat file paths it has already went through,
This is because it is calling FindFirstFileW again which restarts the search, but the FindFirstFile is called with one of the matches (according to the comment above the code it does so to find the long name, but there is no need since what is passed is already a long name) which causes it to pointlessly continue looping over files it already looped through.
I did a couple of tests to see that the expansion still works correctly after my change and that the speed is dramatically improved (I have tested with the example given in #5879 as well and it expands instantly), and it all looks good.

Nir Lichtman wrote:

In the dos_expandpath function I have removed code that in case the
match was not found, caused the file path match loop to repeat file
paths it has already went through,
This is because it is calling FindFirstFileW again which restarts the
search, but the FindFirstFile is called with one of the matches
(according to the comment above the code it does so to find the long
name, but there is no need since what is passed is already a long
name) which causes it to pointlessly continue looping over files it
already looped through.
I did a couple of tests to see that the expansion still works
correctly and that the speed is dramatically improved (I have tested
with the example given in #5879 as well and it expands instantly), and
it all looks good.

Have you tried this on an EXFAT partition (e.g. a memory card) with a
short filename?  That is that the comment mentions.  Expanding something
like "filena~1.txt".
Perhaps the second try can be skipped if "matchname" contains wildcard
characters.
--
You can be stopped by the police for biking over 65 miles per hour.
You are not allowed to walk across a street on your hands.
[real standing laws in Connecticut, United States of America]
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

OK, my bad, I see what you are talking about, when trying to expand a wildcard expression with a short file name in the end (for example :e ~\dir**\hello_~1.txt), my solution here indeed fails, I will update with a fix

I just tested @nir9's fix and confirm it addresses the performance problem. What used to take ~40 seconds now takes < 1 second. Thanks @nir9!

@brammool BTW exFAT is not limited to short 8.3 filenames. Is being able to search for files using a short filename syntax important if the full name is always available?
From Naming Files, Paths, and Namespaces:

On newer file systems, such as NTFS, exFAT, UDFS, and FAT32, Windows stores the long file names on disk in Unicode, which means that the original long file name is always preserved. This is true even if a long file name contains extended characters, regardless of the code page that is active during a disk read or write operation.

@drichardson I guess it is still important since unless you have disabled short file name support, you can still open files in Windows using their short name, therefore although probably rare, people relying on this behavior will not be able to search for short names recursively with my current solution

@nir9 Technically, I understand the point, but as far as anyone actually relying on pre-Windows 95 short names for files they are working with, I do not. Even forgetting about this expand tab issue for a moment, short filenames that conflict uniqued by incrementing a counter. When opening a file, changing in vim, and then saving it in vim, you can easily cause the short filename to change. For example:
C:\Users\doug\test>vim ThisIsATest.txt "+call append(line('$'), strftime('%c')) | wq"

C:\Users\doug\test>vim ThisIsATestTwo.txt "+call append(line('$'), strftime('%c')) | wq"

C:\Users\doug\test>dir /x
 Volume in drive C is SSD
 Volume Serial Number is 7CC7-C9ED

 Directory of C:\Users\doug\test

04/05/20  23:08    <DIR>                       .
04/05/20  23:08    <DIR>                       ..
04/05/20  23:08                19 THISIS~2.TXT ThisIsATest.txt
04/05/20  23:08                19 THISIS~1.TXT ThisIsATestTwo.txt
               2 File(s)             38 bytes
               2 Dir(s)  57,343,758,336 bytes free

C:\Users\doug\test>vim ThisIsATest.txt "+call append(line('$'), strftime('%c')) | wq"

C:\Users\doug\test>dir /x
 Volume in drive C is SSD
 Volume Serial Number is 7CC7-C9ED

 Directory of C:\Users\doug\test

04/05/20  23:08    <DIR>                       .
04/05/20  23:08    <DIR>                       ..
04/05/20  23:08                36 THISIS~3.TXT ThisIsATest.txt
04/05/20  23:08                19 THISIS~1.TXT ThisIsATestTwo.txt
               2 File(s)             55 bytes
               2 Dir(s)  57,343,758,336 bytes free

I don't see the value in implementing expand tab to help people find an file by an unpredictable short name.

@brammool Updated the pull request to handle short names
@drichardson I agree but anyway I updated with a solution that does handle short names and I generally think it's a better solution :)
Tested with a short name in a double wildcard search and with the example provided in #5879 and it work good.
Also checked and confirmed that after my change the wild card search follows directory symlinks (due to the change I have made that it only goes deeper if the entry is a directory).

@brammool Updated the pull request to handle short names

Thanks.

@drichardson I agree but anyway I updated with a solution that does
handle short names and I generally think it's a better solution :)

It is possible that Vim is started on the short name, but then we do
want to use the long name if anyway possible, that's why the expansion
happens.

Tested with a short name in a double wildcard search and with the
example provided in #5879 and it work good.
Also checked and confirmed that after my change the wild card search
follows directory symlinks (due to the change I have made that it only
goes deeper if the entry is a directory).

--
Biting someone with your natural teeth is "simple assault," while biting
someone with your false teeth is "aggravated assault."
[real standing law in Louisana, United States of America]
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Prepare to publish for stable null safety

The latest commit on master is what is published.
https://github.com/dart-lang/intl/compare/dart-lang:b3da438...dart-lang:b3da438

We expect CI to be broken because of a chrome update that hasn't been handled yet - see discussion at #358
Since this has identical content in lib/ it is safe to merge and publish this.

I verified that the failure looks like the chrome update.


DecouplingKit, decoupling between modules in your iOS Project.

DecouplingKit
Project URL
https://github.com/coderyi/DecouplingKit
Description
decoupling between modules in your iOS Project.

          1 Error

:no_entry_sign:
Found 1 link issue

Link issue by awesome_bot

Line
Status
Link

2442
500
https://code.facebook.com/ios/

  Generated by :no_entry_sign: Danger


(isaric_washington): Searching multiple rows for dates

In the Washington dataset, the admission date is on a different row to the visit observations + outcomes.
The dataset is structured so that the outcome date is calculated as admission date + length of hospital stay; but the two fields for this are on different rows with no suitable alternatives. This means all the data has no outcome date. How can we address this?

agreed! sounds good ..
On Wed, Aug 23, 2023 at 8:20 AM Pip Liggins @.***>
wrote:

At this point through creating combined data files I've just copied
admission/outcome dates onto multiple lines for a few datasets - suggest we
do the same here.
—
Reply to this email directly, view it on GitHub
https://github.com/globaldothealth/isaric/issues/131#issuecomment-1690158466,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW7SJCTO3H46EYYNQ2GLVLXWYNSJANCNFSM6AAAAAAXTEX7VU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Closed as Not Planned; data has been modified to include the admission date on every row for each subject, as with other parsers.


ArisFileHeader.fs has a lower-case field name

At least one, that is. Investigate the sources from which the headers are created.

Just not going to change this; let's not break folks' code.


Update writer.py

Description of changes:
If you attempt to create an MDSWriter with an unsupported encoding, at the moment the error message is confusing (just AssertionError) and you have to dig into the source to understand what happened. If we add a good error message, the problem is much easier to understand.
Merge Checklist:
Put an x without space in the boxes that apply. If you are unsure about any checklist, please don't hesitate to ask. We are here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[x] I have read the contributor guidelines
[ ] This is a documentation change or typo fix. If so, skip the rest of this checklist.
[x] I certify that the changes I am introducing will be backward compatible, and I have discussed concerns about this, if any, with the MosaicML team.
[x] I have updated any necessary documentation, including README and API docs (if appropriate).

Tests

[x] I ran pre-commit on my change. (check out the pre-commit section of prerequisites)
[x] I have added tests that prove my fix is effective or that my feature works (if appropriate).
[x] I ran the tests locally to make sure it pass. (check out testing)
[x] I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes.

Can you please also run pre-commit to ensure that it complies with linting by following this guide https://github.com/mosaicml/streaming/blob/main/STYLE_GUIDE.md#12-pre-commit-hooks.


Typo fix and shorten sentence

Thanks for reviewing the PR, @ejc3! A change similar to the one you suggested has been made. Closing this PR.


Standardize Handling of Anchor Tags Across Github.io

This issue tracks the work that comes out of the discussion on this PR.
Essentially. In our markdown, we will define anchor tags that MATCH targeted headers further down in the document. here is a specific example are the bullet points directly below the linked location.
The header is defined as Client: New Releases, but the generated anchor is #client-new-releases. This is a mismatch! In HTML, the anchor ids are case sensitive.
Need to standardize this. Options discussed so far.

Lowercase the anchor targeting in the links WE define in the repo
Add JS to all github.io that can handle these weird casing issues ourselves (like github does)
Insert our own anchors with matching capitalization.

We currently have several places which turn md to html:

Github IO root readme file. (Docfx generated)
Github IO readme of every artifacts (Depends on langs)
Doc.MS (docs.microsoft.com can render markdown file directly from their page)

Currently, #1 and #3 both populate the anchor link id as lowercase connect by -. To make the link direct to the right place, we'd better to use link-verification to do lower-case check.
#2, the anchor link failed to direct the the right place for java no matter what format we are using. We have to fix it by standardize the way of converting markdown to html. Could fix by https://github.com/Azure/azure-sdk-tools/issues/929
The very first step I will preform is to fix the link-verification scripts and fixed the anchor link for each repo.


Google music

Parses Google Music history. SQLite DB has a protobuf field. Could be parsed more efficiently with the newer protobuf implementation. Currently writing blobs out from DB to disk to then parse. Makes me sad.

Sample test data:
GoogleMusicTestData.zip

ok, will take a look shortly.

Going to change the search expression and the names of the artifact. The database does not have the .sqlite extension in the original extraction. This is what happens when I work with provided test data. LOL. Just fyi. Not touching anything else.

Got it. Also what version of android or google music is this? I am not seeing this in any of the images I have.

Changed the name. Is called Playing Now. Got it from Kevin Pagano. Let me
ask him about versions and whatnot.
On Sun, Mar 22, 2020, 2:22 PM Yogesh Khatri (@swiftforensics) <
<EMAIL_ADDRESS>wrote:

Got it. Also what version of android or google music is this? I am not
seeing this in any of the images I have.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/abrignoni/ALEAPP/pull/28#issuecomment-602250818, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AG3DPC4Y5TFQUXN2IJYXRR3RIZJQDANCNFSM4LRF6TTA
.

Android 10, app is Now Playing, built into the Pixel series starting at v2.
It's part of the Ambient Services found here,
https://play.google.com/store/apps/details?id=com.google.intelligence.sense
On Sun, Mar 22, 2020, 2:22 PM Yogesh Khatri (@swiftforensics) <
<EMAIL_ADDRESS>wrote:

Got it. Also what version of android or google music is this? I am not
seeing this in any of the images I have.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/abrignoni/ALEAPP/pull/28#issuecomment-602250818, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AG3DPC4Y5TFQUXN2IJYXRR3RIZJQDANCNFSM4LRF6TTA
.

OK, so its not Google Music at all, but another service that's showing you any music playing nearby, according to their description.

Yes. That is why I changed the name from Music to Playing Now as stated previously.
Interesting the fact about keeping track of any music playing nearby. Did not know about that.