Let's move PSModulePath out of the documents folder

Summary of the new feature/enhancement
The documents folder has always been where modules user-scoped are kept, and that's always been ok, but I recently discovered some problems with this as I've been getting more familiar with Azure and my work laptop maps Documents to OneDrive. This can be problematic for a few reasons, such as OneDrive not syncing correctly or trying to restore a bunch of files from a module I just uninstalled. This is particularly an issue with larger modules (or groups of modules) such as Az.*
We can certainly wish OneDrive was better at its job, but really these files shouldn't be there - they are not documents. The user is not expected to edit them or look at them. They are more akin to application files or application data. There's no value to them being in OneDrive other than to transfer them to another machine, and that can be better achieved by having a script in OneDrive that calls PSDepend or PowerShellGet to install modules on that other machine.
I have updated my profile script to remove this path but it reappears after running install-module.
Proposed technical implementation details (optional)

Remove Documents\PowerShell\Modules from the $env:PSModulePath default. Select a new default path such as ~\PowerShell\Modules or $env:localappdata\PowerShell\Modules
Offer a cmdlet or documentation to move the existing modules to the new location, and optionally update the value of the environment variable.
Additionally, offer to move the existing modules and update the value of the environment variable during the install. (That way the user has the choice to make the install take care of it or do it later at a time of their choosing).

A few extra things to consider when putting this up for triage:

When I install a module on one machine and I am later at a different PC, OneDrive updates the modules folder... but Upgrade-Moduile doesn't work anymore, because it says the module wasn't installed with Install-Module ... (which it was, just not at the machine I'm working on.)
If your module folder is big loading PowerShell can take a (very) long time because it will wait until OneDrive has pulled all the files to your machine.

I think this change should happen... hopefully soon. I think storage for these modules should be in the %userpfile%\AppData\Local folder, this is the place for things that should not get synced with other machines.
PS: I create PowerShell modules... I have a lot of them... and they are all on my OneDrive now. 😒

@jeroenlandheer Do you mean Update-Module? If so you couls discuss in PowerShellGet repository.

@iSazonov Would the PowerShellGet guys be able to change the default value of $env:PSModulePath and update the installer to optionally update it on upgrade?
Though there should probably be a second issue in PowerShellGet to respect the value, not overwrite it.

@JohnLudlow Any changes related to PSModulePath are breaking changes. We need to keep backward compatibility.

@iSazonov Sorry, that was a typo. This should indeed go there too, but don't you think they will choose the location of the modules where they install them... based on whatever this teams says it should be?  (AFAIK there's no way to customize this with settings, but that's something for another day.)
If paths for loading the modules is the primary function of PSModulePath, this issue can be solved quite easily:

Designate a folder somewhere in %LocalAppData%\...
Tell others that installing modules in this folder is best practice.
Put both paths in PSModulePath (i.e. %LocalAppData%\..  and %userprofile%\Documents\...)
Ensure the new location is added to new installations in the PSModulePath environment variable.

No need to move stuff around, new things get installed in %LocalAppData%\.. and old modules that are still in the user's documents folder keep working. Maybe this doesn't even require a code change in PowerShell, just some changes in the installer.
And now we're on this subject, in Windows installations, modules which are installed on the local machine are installed by default in the Program files\PowerShell\Modules folder. I think the correct place for this should be %AllUsersProfile%\... (often called C:\ProgramData)
AFAIK the functionality of PSModulePath itself doesn't change with all of this, so this is technically not a breaking change.
Hope this helps.

@jeroenlandheer Indeed, and if I do want to move the older modules to the new folder (I probably would, in my case), there are some options:

Offer to do that in the installer
Offer a tool (such as a cmdlet) to do it post-install
Offer documentation that says "you can copy everything from <old location> to <new location>"

Any of those would work for me, but some people may appreciate it being done for them.
And you're absolutely correct IMHO about the Windows Modules. The only modules that should be there are ones that are installed as part of PowerShell and shouldn't be removed.

AFAIK the functionality of PSModulePath itself doesn't change with all of this, so this is technically not a breaking change.

While I agree that it would be hard to claim this is explicitly a breaking change of an API, it would still be disruptive.  There has never been a supported way of determining the module paths of different scopes, e.g. no PSModuleInfo.AllUsersModuleRepository or similar.  Any tools looking to interact with the module directories explicitly has been required to hard code the path, so any location change here will break these tools.
(Note that I'm not necessarily advocating against it, but it's something that needs to be considered)

Related: https://github.com/PowerShell/PowerShell/issues/7082#issuecomment-397710807

Previously discussed in #8069 too

So we reviewed this on the @PowerShell/powershell-committee today, but also this is something I've personally done some thinking on in the past.
The mangling on particular locations on the PSModulePath is something we've seen users impacted by repeatedly. For example: https://github.com/PowerShell/vscode-powershell/issues/2824#issuecomment-667355371.
Another important point is that the CurrentUser and AllUsers module paths are actually configurable in the powershell.config.json:
https://github.com/PowerShell/PowerShell/blob/e2c23fc5bd035251bed71413ad7c467c99dafd76/src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs#L1304-L1305
So there is a concept of both the default CurrentUser module path and the actual one.
However, there's currently no way to communicate the actual one, so the default is the implicit contract between PowerShell's module system (Import-Module/Get-Module/command lookup) and PowerShellGet. I was hoping to improve that in #7082, but even without that the contact being implicit means there's room to get it wrong.
Today it seems that both PowerShell 7 and PowerShellGet agree that the default CurrentUser module path lies under the MyDocuments path, but evidence suggests that this wasn't always the case.
The big issue now is that OneDrive configurations override the MyDocuments folder and cause this unexpected migration.
But additionally, the actual CurrentUsers module path could be overridden with a configuration. And this is something that things like the PowerShell Azure Functions worker would want to do given the radically different environment in which it operates. Except that there's no way for PowerShellGet to pick this up.
In terms of changing the default PSModulePath, there have been a lot of proposals to fix PSModulePath in various ways. Changing the CurrentUser path away from MyDocuments is going to break PowerShellGet, since it depends on the same location being used. However, the MyDocuments path clearly presents problems, and both the proposed alternatives ($env:LOCALAPPDATA\PowerShell\Modules and $HOME\PowerShell\Modules) make sense.
So in terms of recommendations:

The Engine Working Group has also been asked to review this, to go into a bit more technical depth.
An API of some kind that gives both the default and actual module path components is probably a good direction to go in.
In terms of backward compatibility, tooling can look for this API and fall back to the traditional defaults.
The committee didn't decide on whether or not the default path should be changed. We want a chance for the Engine WG to discuss this, and also want to talk to the OneDrive team to understand things a bit better here.

@rjmholt That's a great summary. Thanks.
We'll see what the Engine Working Group say

With behavior of OneDrive the WG agrees that we need to come up with a proper solution, however the scenarios have a high level of complexity which is exacerbated by the need that other PS tools also need to be able to use whatever solution is made available.
The WG proposes that PS should provide an API which allows tools to query for the default location of modules.  The tool chain also needs to be able to query PS so the values are consistent.
We propose that an RFC is needed to define the behaviors, not only for PowerShell proper but for tools like PowerShellGet.
We think at least the following requirements need to be addressed in the RFC:

where is the default location for PSModulePath (system and/or user)
how may this default location be modified
how is the API used by PS and the other tools
how are misconfigurations handled (non-existing paths, multiple paths, etc)

@mikhey Changing PSModulePath works until you do Install-Module which breaks it again
A ~/.pswh folder (or whatever it gets called) would work, just as long as it's not somewhere OneDrive will try and mess with it

Would a dot folder work here possibly?

As @rkeithhill said, those dot folders pollute $HOME, and even though they're not displayed, they still need to be processed by programs that examine the Home directory, creating a sort of tragedy-of-the-commons problem where more and more applications putting their configurations and data in a directory based in the Home directory adds up to slower filesystem performance for unrelated tasks.
PowerShell actually already conforms to the XDG base directory specification on *nix, which is a standard intended to solve this problem. PowerShell data files, including modules, are stored in $env:XDG_DATA_HOME/powershell, which defaults to $HOME/.local/share/powershell.
The issue then is that Windows doesn't really offer a clear answer here, because its philosophy is to separate users from configurers/application installers.
Worth noting is that the XDG standard is configurable with a sensible default, and I imagine we want the same, we just need to weigh configurability against complexity (mainly for anyone developing against our decision) and performance.

@rkeithhill and dot files are supposed to also be hidden, but Windows is not linux so dot files are left always visible.
So I'd like to add my voice here in asking to please respect the platform conventions on Windows and use the appropriate AppData folder the same way Linux is using XDG.
As for accessibility for profile editing, I think that's already covered by using <editor of choice> $PROFILE which will work regardless of platform.
At most adding a $PROFILEHOME as an alias for (Get-ChildItem $PROFILE).Directory.FullName if the user wants to open the folder for any reason?

I'm just stopping by to express my frustration with how things are today. I'm happy to read about positive discussions for change, though!
Trying to update PSModulePath in your profile or via registry (like the docs suggest) is pointless, because as previously mentioned, as soon as you use Install-Module, the env var is clobbered again with the undesired OneDrive Documents folder. You'll also notice that Install-Module seems to ignore PSModulePath, too, as it wants to always search in MyDocuments\[Windows]PowerShell:

To workaround this, you need to update your MyDocuments (aka 'Personal') folder to no longer be in the OneDrive folder. This seems to work well for me:

Right-click My Documents (on the desktop), and then click Properties.
In the Target box, type the new path to the My Documents folder, or click Move to browse to the folder and if needed, create a new My Documents folder. If the path you type does not exist, you are prompted to confirm that you want to create a new folder.
Click ~Yes to move files from the old My Documents location to the new location, or~ click No if you do not want to move these files. Note that if you click No, the files in the old location are not deleted, but they are no longer visible from My Documents after the change.

Figured I'd share this in case anyone needed it /shrug

Just to plus one on the pain and urgency here. I just lost half a day trying to figure out exactly the issue @jeroenlandheer mentioned back on June last year, namely trying to Update-Module on a machine fails because I installed the module on a difference machine, and both are sync'ing my documents via OneDrive.
Beside the issue above this causes, I'm now syncing over 900MB of PowerShell files to my OneDrive account, and I only have two modules installed! (The 'Az' and the 'Microsoft.Graph' modules - which I suspect are in common usage).
I'm probably just going to stop using OneDrive or install for AllUsers, but it was time consuming and frustrating to figure this out.

I want to bring this problem to the attention of @PowerShell-Committee and @Area-PowerShellGet group.
I think it is good time to make the breaking change, preserve Document folder for module searching but install in new and more appropriate folder in user profile. The some for all user folder (machine-wide) - c:\ProgramData as right place. Also it makes sense to review where we place user profile (and, specially, profiles and config files of  host applications).
Maybe create RFC?
/cc @SteveL-MSFT

The C:\ProgramData was recently dropped by Git for Windows team due to the amount of confusion it creates: https://github.com/git-for-windows/git/pull/2358 Let's forget about this directory once for all.

There are a number of teams at Microsoft that I'm sure have a ton of research and failures to learn from in this space. Nuget, npm, VS Code extensions, etc. seem to have solved similar problems on Windows in a cross-platform ecosystem. Folks like @zkat have a wealth of experience they might be able to share (or point us to people who can) to come to the best solution for PowerShell.

I want to add another reason to make this change.
If you have Controlled Folder Access enabled then PowerShell is no longer able to install or update modules that reside in the default modules folder in the current user scope e.g., C:\Users[user]\Documents\PowerShell or C:\Users[user]\Documents\WindowsPowerShell.
The only way to fix this issue is to enable PowerShell for Controlled Folder Access bypass but doing that is explicitly against Microsoft's configuration recommend, and for good reason.

I'm hitting this issue with Controlled Folder Access as well.  Our IT Apps department wants to start migrating things from legacy systems to newer PowerShell scripts, but they can't install the modules needed because Defender gets in the way, and they don't have admin access on their systems (only IT Operations have that).  I'd rather not blanket exclude powershell.exe / pwsh.exe from controlled folder access, as that sounds like a Very Bad Idea (tm).  I suppose I could deploy scripts via Intune that would install modules in AllUser scope, but that'd then require me to manage their module updates as well, and ideally the user should be able to manage their own modules.

Let's make a decision here! Snooze!
The Windows standard (AppData\Local) is fine. And makes sense. While I like dot paths, they're a *nix convention so can understand why the PowerShell team wouldn't apply this UNLESS they're not wanting a Windows-specific code change. This (I assume) is the same reason .dotnet and other teams have used dot paths.

@PowerShell/powershell-committee has re-discussed this recently.  The ideal solution is:

expose a public API in SMA.dll for apps to discover the system, shared, and user module paths.  Even our own modules like PowerShellGet are currently hardcoded to Documents (on Windows anyways)
ideally, $env:PSModulePath is JUST an env var and pwsh.exe doesn't manipulate it trying to infer user intentions (this was inherited behavior form powershell.exe), however, this would be a breaking change.  Basically, if certain system, shared, and user paths are not in the env var, PowerShell assumes this was a mistake and adds them except for some specific conditions
the actual location would probably be AppData on Windows.  On non-Windows, it's already outside of Documents.  Do we need a migration story for users with PS7 already installed?  A clean install is easy, but an existing PS7 means modules are likely already in Documents.  Seems to me a cmdlet to explicitly migrate may be best solution to avoid any surprises to the user.

Open to ideas/thoughts on this.

Since we say about fundamental behavior for years I think we need to put this in RFC.
We have no need to change system module path
There is a problem in how PowerShell process x86 and non-x86 paths for shared module paths. We should make this consistent. I think we have no need a migration path for the case (only if a experimental feature)
This change may be most sensitive for user module paths. Migration options:
4.1 Experimental feature
4.2 Installer warning
4.3 Compatibility mode with chaining new path then old path.

Agree with the rest of the commenters that AppData makes the most sense on Windows. This also clears things up with module location path as well, given that OneDrive Known Folder Move's Documents redirection only applies at the explorer level.

Given that PowerShell already uses $env:XDG_DATA_HOME/powershell which defaults to $HOME/.local/share/powershell on Linux  ...
Can we just let PowerShell on Windows support $env:XDG_DATA_HOME too?
PowerShell could just silently fall back to the current location if it's not set.
Then users could choose to set $env:XDG_DATA_HOME to $Home or $env:LOCALAPPDATA ... or $env:APPDATA 😨 ... or even the current default $Home\Documents or $Home\OneDrive - MyCompany\Documents 😆
There's no reason this should be a breaking change
Frankly, it can be done purely in PowerShellGet, because only users who set $env:XDG_DATA_HOME would need to also add $env:XDG_DATA_HOME\.local\share\powershell\modules to their $env:PSModulePath

Engine WG discussed this issue today
Points raised by the committee
We fully agree that SMA.dll should offer better insights into module path preferences through its public API surface - it's currently too opaque, and .
We also generally agree that PowerShell should, long-term, move towards $env:LOCALAPPDATA as the preferred root for user-specific application data (modules included) on Windows, but certainly not as a breaking change.
Instead, we recommend a "slow march" approach - establish and introduce a new path root, switch official host application logic defaults gradually, and continue supporting both paths for module discovery in parallel.
Given the scope and expected impact of introducing a change like this (however carefully), the proposal should indeed be published as an RFC, and evaluated in the larger context of the ecosystem around PowerShell (tooling with hardcoded module paths, etc.). We don't have capacity to commit to producing the initial draft, but welcome additional input from the community and the committee.
XDG_DATA_HOME
We further discussed @Jaykul's suggestion to support $env:XDG_DATA_HOME for establishing a user-defined path root for PowerShell-specific user data.
We agree on its potential usefulness, but recommend not implementing support for $env:XDG_DATA_HOME in isolation. Instead, we would like to evaluate the XDG Base Directory Specification holistically, and then give a more comprehensive recommendation on whether (and how) to support it consistently on Windows - please create a separate issue for this if that sounds valuable @Jaykul, we're happy to re-review it :)

If I read all of this it seems that everyone is in agreement that the "My Documents" folder was a poor choice and that on Windows the AppData folder is preferred... but I notice one other thing.
Why does this have to take more than a year to make a decision? Software engineers and administrators deal with breaking changes often enough, if something breaks we can handle it... it's not the end of the world. Anoyances like these are causing us more headaches (and time.)
I look forward to a preview/beta/rc to get this is resolved... soon? 😉

One question, what will be the best practice if I want to use a single path for all the module installations (both Core and Windows Powershell) . As an organization we have multiple agent servers configured in DevOps tool (Octopus) and we have installed a set of PS commands in all the servers, so that Developers can use it while they deploy their code. And all the code deployment are running using Octopus service account which is admin in above mentioned Agent servers, so this will open the developers to install the new PS modules as and when needed and that may loosen the control over the installation path of PS modules. So what will be the best method if we want to control the module path (at least make it  2 paths- one for pwsh and another for windows ps) ?

@MHA1981 Please open question in Discussions.

Ok sure

This is a big enough change that it won't make it into 7.3 which is headed towards RC and we would not want to take such a impactful change at that time.  We should try to get something in early for 7.4 previews.

do it! Otherwise I'll need to hack around on my box just so I don't have to wait for stuff to download from ODB

@SteveL-MSFT Is there a timeframe for 7.4 previews?

@JohnLudlow the first previews of 7.4 will be coming soon, but this feature won't show up til later

I'd like to share the workaround we're implementing: junctions. OneDrive does not follow them, but they are transparent to most use cases.
IIUC, if you do New-Item -ItemType Junction ~\Documents\PowerShell\Modules -Value ~\SomeOtherFolder\Modules, you're good.
We are junctioning individual module folders within Modules, and that breaks PowerShellGet's update functionality in PSv5 due to Get-ChildItem -Recurse in PackageManagement\Get-Package, because gci doesn't traverse junctions within the provided path with -Recurse. (PSv7 does.) To work around that, we copy the PSGetModuleInfo.xml files back. PackageManagement then finds the XML files and uses the InstalledLocation property, which is junction-agnostic.
We didn't use symbolic links because they require admin to create on Windows.

This is how I do it today for 7+:

Change my powershell.config.json PSModulePath to point to %LocalAppData%/powershell/Modules. This is the path on Linux/MacOS and puts it all in the same place everywhere.
Delete/migrate the modules folder from both "documents" folders for WinPS and PS and symlink (if I have admin) or ntfs junction (if I don't) to the localappdata folder.

This preserves functionality for PSGetv2/PSGetv3 to install modules. ModuleFast defaults to the localappdata location so it's not an issue there.
A low impact way to improve this situation I have proposed here: https://github.com/PowerShell/PowerShell/issues/18613 that would not change the default but at least make it configurable and exposed in a way that package managers can tie in. Once this is done both PSGetv3 and ModuleFast could detect this and utilize it (no hope for PSGetv2 since it is on life support tho)

Having modules roam between machines is really nice functionality - it reduces friction switching between machines a lot.
Now I understand the existing mechanism is causing problems for some - luckily it's always worked for me.

Has the OneDrive team could be contacted to work out if there's changes that could be made on either side to make it more reliable?
I couldn't find any issue for a replacement roaming experience. eg. some sort of placeholder file, etc. although not all modules are available from the gallery, so quite a bit of design required there. Would this be welcome

On changing the path, please engage caution when breaking existing workflows by disabling/altering the currently enabled-by-default feature.
(requested repost from https://github.com/PowerShell/PowerShellGet/issues/627#issuecomment-1322555942)

Has the OneDrive team could be contacted to work out if there's changes that could be made on either side to make it more reliable?

Depends on the specific issues you were having. The biggest thing I'd recommend if you're trying to sync using a cloud provider is to ensure that your modules directory is considered "Pinned". Different providers call it different things, but for OneDrive you right click the folder and click this:

I couldn't find any issue for a replacement roaming experience. eg. some sort of placeholder file, etc. although not all modules are available from the gallery, so quite a bit of design required there. Would this be welcome?

One potential option is to symlink the old location back to a folder in OneDrive

is there already a way to move the Microsoft.PowerShell_profile.ps1 file out of documents too?
I managed to get most out of my documents via the junctions suggestion, but I can't seem to move the profile file so I still end up with a PowerShell directory in my directory.

Can we include the scripts folder in this discussion too?
I think it should be treated separatly from the modules folder, at least have the ability to.
Maybe it could have it's own environmental variable, at least optionally?

PSScriptPath?
Default to PSModulePath\..\Scripts if PSScriptPath isn't set?

Related: https://github.com/PowerShell/PowerShell/issues/13815
I support adding a runtime API to retrieve the preferred configuration directory, instead of just changing the default value to $env:LOCALAPPDATA. This would bring PowerShell one step closer to having configurable data/module/cache directories and encapsulated portable installs.

I am here because I installed a big module pack (Azure PowerShell) and it crashed powershell because the modules directory is in an ultra slow UNC path network location. All morning to figure out what caused the slowdown. Now hacking PSModulePath to point elsewhere, but I will probably regret fiddling with it.

@thehappycheese
Been there. Tip from one that have wasted hours on the same thing: PowerShellGet and PackageManagement does not deal with PSModulePath; path given scope is hard coded. But "Import-Module" works with PSModulePath.
So use PackageManagement Save-Package with -Path to override where to install modules to.

@o-l-a-v  and @thehappycheese
Just remember that, in doing that, the modules are not technically "installed", only "saved", so you can't use Update-Module or Uninstall-Module to work with them. That's the (only?) drawback of using Save-Module over Install-Module.

@johnwmnolan
Yup, good you pointed that out. I handle that with my own logic outside PowerShellGet and PackageManagement.

@o-l-a-v and @thehappycheese
Just remember that, in doing that, the modules are not technically "installed", only "saved", so you can't use Update-Module or Uninstall-Module to work with them. That's the (only?) drawback of using Save-Module over Install-Module.

The difference here is just an XML manifest file that gets dropped in the folder that's basically a CLIXML output. They're pretty easy to "fake" and make a module "installed" in PSGetv2 terms. PSGetv3 doesn't use this anymore.

Just an FYI -- Symlinks and Junctions (at least on Windows) do sync via OneDrive, so using the symlink workaround doesn't work.

While waiting for using the specifications: XDG on linux and programdata on Windows, a step by step workaround:
#example of modules
$paquets="Plaster,Pester,InvokeBuild,PowerShellGet,ModuleBuilder"
#setup
$paquets -split ',' |%{Install-Module $_ -Scope AllUsers -verbose  -force}
#option1: first line of PSModulePath
$paquets -split ',' |%{Find-Package  $_ | Save-Module -Path  $([Environment]::GetEnvironmentVariable("PSModulePath") -split $([System.IO.Path]::PathSeparator))[0] -verbose}
#option2: otherwise
$paquets -split ',' |%{Find-Package  $_ | Save-Module -Path "$env:ProgramData\Microsoft\PowerShell\modules\" -verbose}

#check
$paquets -split ',' |%{(gmo -l $_).path}
    # C:\ProgramData\Microsoft\Powershell\Modules\Plaster\1.1.4\Plaster.psd1
    # C:\ProgramData\Microsoft\Powershell\Modules\Pester\5.5.0\Pester.psd1
    # C:\ProgramData\Microsoft\Powershell\Modules\InvokeBuild\5.10.4\InvokeBuild.psd1
    # C:\ProgramData\Microsoft\Powershell\Modules\PowerShellGet\2.2.5\PowerShellGet.psd1
    # C:\ProgramData\Microsoft\Powershell\Modules\ModuleBuilder\3.0.0\ModuleBuilder.psd1

#if there are recalcitrants, do this before the setup
#simple uninstall
$paquets -split ',' |%{Get-InstalledModule $_ -AllVersions |Uninstall-Module -Verbose -Force}
#force uninstall
$m='C:\Program Files (x86)\WindowsPowerShell\Modules\Pester'
takeown /F $m /A /R
icacls $m /reset
icacls $m /grant "*S-1-5-32-544:F" /inheritance:d /T
Remove-Item -Path $m -Recurse -Force -Confirm:$false

@SteveL-MSFT since this didn't make 7.4, is it on deck for evaluation for 7.5? Looking forward to the roadmap :)

Or %LocalAppData%\PowerShell.

Can we include the scripts folder in this discussion too?
I think it should be treated separatly from the modules folder, at least have the ability to.
Maybe it could have it's own environmental variable, at least optionally?

PSScriptPath?
Default to PSModulePath\..\Scripts if PSScriptPath isn't set?

Without this, Controlled Folder Access would still block the installation of all modules that make use of that folder (for example, https://github.com/PowerShell/SecretManagement).

@bwilsonms of course, that would be just one of many reasons why this would be desirable.

It's now 2024.
@SteveL-MSFT, @JohnLudlow, @iSazonov, @rkeithhill, Et al. How do we keep this moving forward? It's been almost 3 years and while there seems to be consensus on the need, there does not seem to be any tangible progress toward fixing the problem.
This issue was tagged with milestone, 7.4 but that has passed. There were also several past comments about needing an RFC, but I never saw where one was started (What does RFC even mean in the context of a PowerShell setting?), and if it did can some point the way to where that work is being done?
I know this a considered a breaking change, but it can also alleviate a previous breaking change introduced by Controlled Folder Access (see post here) that many of us are having to work around on a daily basis.
We need this in 2024 and ideally in 7.5.

As a workaround, ModuleFast installs to your LocalAppData by default and automatically sets up everything for you to make it work.
https://github.com/justingrote/modulefast

As it stands now I consider this a breaking experience as it is. We have our Documents folders redirected and scripts take forever to finish because of the constant searching for modules in our network folders. Other than scripts I specifically need it for I'll continue to use the older versions of Powershell that I don't see this issue with. As for keeping modules in the Documents folder...for the life of me I can't see how modules are considered Documents or how the Documents folder is an appropriate location for them. And not giving an option to change this behavior? This makes it a deal breaker in my opinion.

It comes from very old decision way back in old PowerShell before OneDrive was even a concept. Can't predict the future :)

I think this is some sort of Microsoft sickness. Some decision is made early on (place stuff in "system32" folder). Then things change, or this is no longer a great idea (stuff should be in "system64" logically). But since other developers didn't actually read Microsoft's best practice guide, they hardcode the value. Then Microsoft for some reason goes out of their way to retain compatibility with all Windows versions ever released, making things ever more unintuitive.

Just make the change when it's needed.
Maybe get some guys from the Microsoft naming department, they seem to like making changes? Though then you'll probably run in to the "path to long" problem...

As it stands now I consider this a breaking experience as it is. We have our Documents folders redirected and scripts take forever to finish because of the constant searching for modules in our network folders. Other than scripts I specifically need it for I'll continue to use the older versions of Powershell that I don't see this issue with. As for keeping modules in the Documents folder...for the life of me I can't see how modules are considered Documents or how the Documents folder is an appropriate location for them. And not giving an option to change this behavior? This makes it a deal breaker in my opinion.

It comes from very old decision way back in old PowerShell before OneDrive was even a concept. Can't predict the future :)

Which is why it is so important to stick to the OS guidelines and put that stuff in LOCAL APP DATA, instead of dreaming up new locations that WILL break things when new features are introduced, like OneDrive.

Is there a way for a user to opt-out of OneDrive being added to PSModulesPath every time? Can we add a setting somewhere? It should be easy to add a setting and keep the old behavior by default.

It's not OneDrive that gets added, it's the Documents folder path that onedrive is redirecting. The "simple" solution is to not redirect your My Documents to OneDrive, and just use OneDrive separately as a separate folder, there aren't any "good" alternatives that don't result in a lot of errors and I've tried a lot (symlinking, hardlinking, regedits, excludes, you name it).

Can we add an option that adds a custom user-specified directory instead of Documents?

That already exists, unfortunately it has to be done in a powershell.config.json file at startup in the same directory as pwsh.exe and cannot be configured at runtime.
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_config?view=powershell-7.4#psmodulepath
I requested that path be exposable but that was closed in favor of this issue:
https://github.com/PowerShell/PowerShell/issues/18613
And PowerShellGet Install-Module and Install-PSResource are hard-coded still to install to Documents despite this setting, those have to be updated to do it as well.
My ModuleFast module installs to localappdata by default and updates your PowerShell path and profile accordingly, so it is an alternative option in the meantime:
https://github.com/justingrote/modulefast

is there a bug to support this setting in Install-Module?

is there a bug to support this setting in Install-Module?

https://github.com/PowerShell/PSResourceGet/issues/1494

I have successfully used symlinks to solve OneDrive for hundreds of users.
Documents was redirected to OneDrive by policy. We created a folder in the user profile, moved modules there incrementally, and symlinked modules individually into Docs/blah/Modules. Modules can be moved on the fly, even if there are locked DLLs, with [IO.File]::Move (or Move-Item in PSv7). You also need to update the InstalledLocation in PSGetModuleInfo.xml if you want Update-Module to work.

@fsackur pretty sure onedrive still complains of a sync conflict when you do this and there was no way even with exclusions to suppress it, unless something's been updated since I last attempted.

@rkeithhill I agree it becomes an issue for users that don't have the setting to see hidden folders.  That said the %LOCALAPPDATA% can be used in the File Explorer address bar and should work (in theory™).
I'm liking the ~/AppData/Local or ~/AppData/Roaming folders as it may line up with the ~/.local folder on Linux machines essentially.  Ultimately, the sooner this can be configurable either via environment variable and/or config file would be fantastic!

OneDrive follows symlinks/junctions without errors on the latest versions (tested on MSIT Fast, Insider, and prod), but the status on files/folders is syncing even when sync has completed. I've been storing PowerShell and WindowsPowerShell on a Dev Drive using junctions for a few months.
There's a new setting to exclude folders by name and ADMX/ADMLs, but it doesn't activate even when using the example values. The file-based exclusion setting works with similar values. ProcMon shows OneDrive.exe loading EnableODIgnoreFolderListFromGPO values at startup, and I can see the codepath when decompiled, but symbols aren't available so I haven't debugged any further.

@rkeithhill I agree it becomes an issue for users that don't have the setting to see hidden folders. That said the %LOCALAPPDATA% can be used in the File Explorer address bar and should work (in theory™).
I'm liking the ~/AppData/Local or ~/AppData/Roaming folders as it may line up with the ~/.local folder on Linux machines essentially. Ultimately, the sooner this can be configurable either via environment variable and/or config file would be fantastic!

I would argue ideally users don't need to ever see this folder except for advanced troubleshooting, similar to the registry, and only interface with it using the install/update/uninstall commands indirectly.

OneDrive follows symlinks/junctions without errors on the latest versions (tested on MSIT Fast, Insider, and prod), but the status on files/folders is syncing even when sync has completed. I've been storing PowerShell and WindowsPowerShell on a Dev Drive using junctions for a few months.

@pl4nty  Can you please elaborate? Which Windows/OneDrive version are you using?

I would argue ideally users don't need to ever see the modules folder except for advanced troubleshooting, similar to the registry, and only interface with it using the install/update/uninstall commands indirectly.

Factually incorrect. AppData is and has been the location to store application data and configuration (besides the registry) for over 20 years. It's only today that more and more inexperienced Windows developers starting abusing the profile folder to place configuration data, because they're used to macOs or Linux.

AppData: "The directory that serves as a common repository for application-specific data for the current […] user."

https://learn.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0#system-environment-specialfolder-applicationdata
Furthermore:

https://learn.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0

Factually incorrect. AppData is and has been the location to store application data and configuration (besides the registry) for over 30 years.

Powershell is an application. Modules are application data. Therefore that's where modules should go instead of documents. Maybe you misunderstood what I was saying?

@pl4nty Well, ive tried and I'm still seeing "The 'ExampleFolderJunction' in Documents is junction point ..." error which prevents me from syncing Documents folder. Same for latest insider. Thanks for help anyway, I won't nagg you about this anymore.

I just came by this thread, because I'm experiencing the issue where OneDrive syncs modules, which interferes with the Install-Module / Update-Module commands.
With Microsoft now promoting a Dev Drive, I'd love to store all modules there, like I moved all NuGet, npm, ... sources there as well.

As it stands now I consider this a breaking experience as it is. We have our Documents folders redirected and scripts take forever to finish because of the constant searching for modules in our network folders. Other than scripts I specifically need it for I'll continue to use the older versions of Powershell that I don't see this issue with. As for keeping modules in the Documents folder...for the life of me I can't see how modules are considered Documents or how the Documents folder is an appropriate location for them. And not giving an option to change this behavior? This makes it a deal breaker in my opinion.

It comes from very old decision way back in old PowerShell before OneDrive was even a concept. Can't predict the future :)

Before I start my rant....I want to call BS on this.  How is it that Powershell 5.1 doesn't have any reference to document or onedrive folders but Powershell 7+ does (event after I try to remove them).  If it wasn't for the memory limitations in 5.1 that essentially break the use the MSGraph, I wouldn't even be looking at newer versions.

Before I start my rant....I want to call BS on this. How is it that Powershell 5.1 doesn't have any reference to document or onedrive folders but Powershell 7+ does (event after I try to remove them). If it wasn't for the memory limitations in 5.1 that essentially break the use the MSGraph, I wouldn't even be looking at newer versions.

Not sure what you mean, there's no explicit reference in either PSResourceGet or the PowerShell engine to Onedrive paths as far as I know, everything references documents. https://github.com/search?q=repo%3APowerShell%2FPowerShell onedrive&type=code https://github.com/search?q=repo%3APowerShell%2FPowerShellGet onedrive&type=code

That is exactly what I mean.  Everything references Documents.  Which means if the documents folder is redirected, it references the redirection which means it searches the redirection (and causes everything to be extremely slow).  I don't see any references to the Documents folder in the documentation: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_psmodulepath?view=powershell-7.4
Of course, I'm not sure exactly what its referring to when it talks about the "inherited PSModulePath".
Since this thread is over 3 years old I've given up home on a fix or a way to remove the Documents references but I did find a workaround.  I created a Profile.ps1 file that parses the PSModulePath and removes all entries with the string "Documents".  Using this I was able run a time consuming script in about 1/2 the time it used to take because it wasn't constantly checking my redirected Documents folder for modules.

**about PSModulePath - PowerShell**The PSModulePath environment variable contains a list of folder locations that are searched to find modules and resources.

Yep that's a similar workaround I do as well, and I utilize the ModuleFast module installer I wrote which defaults to a non-Documents path. https://github.com/JustinGrote/ModuleFast

Sad to see this is still being discussed after 3 years. PS modules really don't belong in OneDrive. If you install/upgrade on one machine, the new versions will show on some other machines, but you can't "upgrade-module" on those machines. You also end up syncing everything on a new machine setup with OneDrive, including all old versions that may have been synced and not removed.
There are many ideas that have been suggested that have much merit and would allow for PowerShell to still function without needing to use the OneDrive sync.
Semi-related, I was bit by this with "Offline Files" and the modules being in My Documents. But the "Offline Files" sync was absolutely horrible and I had no idea what version(s) I would be working with at any given time. That experience was so bad I moved everything off of my Documents that was resulting in lag.  There, the Modules took forever to load if I was connected via VPN because I had to round-trip to the offline files server to pull the modules. That was a poor experience because the modules were placed in a location that doesn't make sense for app modules.

Since it wasn't mentioned here yet: There an experimental feature available since PowerShell 7.4 that is related to this topic:
PSModuleAutoLoadSkipOfflineFiles

With this feature enabled, if a user's PSModulePath contains a folder from a cloud provider, such as OneDrive, PowerShell no longer triggers the download of all files contained within that folder. Any file marked as not downloaded are skipped. Users who use cloud providers to sync their modules between machines should mark the module folder as Pinned or the equivalent status for providers other than OneDrive. Marking the module folder as Pinned ensures that the files are always kept on disk.

I don't think it will really help, it is cosmetics, but at least something is happening that shows someone is paying attention to the topic as such.

I don't understand why people are still pinging this issue. Rob Holt gave the answer 3 years ago that this is in the configuration.
In modern PowerShell (7.4 as of this writing) you can stop PowerShell from searching your Documents folder for modules by creating or modifying the powershell.config.json in your Documents\PowerShell folder to add a PSModulePath value like this:
{
  "PSModulePath":"%LOCALAPPDATA%/powershell/Modules",
}

Now PowerShell will use that instead of your Documents\PowerShell\Modules location.
I feel like I need to add: please do not forget the original reason these modules were in your Documents is because you were expected to read them. Even now that Microsoft is hosting the PowerShell Gallery, there is no real review or audit of the PowerShell modules in that gallery. There is not (yet) a public source of safe first-party modules like the MCR is for Microsoft container images.

I don't understand why people are still pinging this issue. Rob Holt gave the answer 3 years ago that this is in the configuration, and that works, right?

The big problem is that this requires a pwsh restart, and it also includes access to where pwsh.exe lives. If this is in Program Files, then you need admin rights to do this. So, not userspace enough.

No....
The path people want to change isn't the ALL USERS path (which would require editing the config file next to pwsh.exe) it's the CURRENT USER path, which is controlled by the config file next to your personal profile.ps1

I don't understand why people are still pinging this issue. Rob Holt gave the answer 3 years ago that this is in the configuration, and that works, right?

The big problem is that this requires a pwsh restart to implement, and it also requires access to the same directory where pwsh.exe lives. If this is in Program Files, then you need admin rights to do this. So, not userspace enough.
Fine if it's your desktop and you own it, but in VDI/Server/etc. scenarios, it's not great.

@jaykul my apologies, I was not aware there was a per-user config.json that lives in your $PROFILE.CurrentUserCurrentHost directory.
In that regard, yeah it seems like publishing a simple module command like  Set-ModulePath or something to simplify the creation/editing of the json seems like the simplest path to resolve this, and then agreed it's just a matter of getting PSResourceGet/etc. to respect that path once set so you don't have to use Save-Module constantly

Just to add to one of the issues that OneDrive introduces when the Documents folder is included in the sync, and that is retention policies. My organisation defines a OneDrive retention policy of 5 years since Last modified. This means that large chunks of the PS Module path get deleted at odd times, resulting in incomplete module packages which have to be recovered from the OneDrive Recycle bin.
Moving user level modules out of Documents is a critical need when OneDrive retention is in the mix.

I made a function that uses some private methods on the config and merges them with the API from #19422 to demonstrate what I think the actual public API should look like/behave as so that tools such as PowerShellGet and ModuleFast can all use the same relevant implicit installed modules path if not specified otherwise.

#Fetches the module path for the current user or all users
function Get-PSModulePath ([Switch]$AllUsers) {
	$scopeType = [Management.Automation.Configuration.ConfigScope]
	$pscType = $scopeType.
	Assembly.
	GetType('System.Management.Automation.Configuration.PowerShellConfig')

	$pscInstance = $pscType.
	GetField('Instance', [Reflection.BindingFlags]'Static,NonPublic').
	GetValue($null)

	$getModulePathMethod = $pscType.GetMethod('GetModulePath', [Reflection.BindingFlags]'Instance,NonPublic')

	if ($AllUsers) {
		$getModulePathMethod.Invoke($pscInstance, $scopeType::AllUsers) ?? [Management.Automation.ModuleIntrinsics]::GetPSModulePath('BuiltIn')
	} else {
		$getModulePathMethod.Invoke($pscInstance, $scopeType::CurrentUser) ?? [Management.Automation.ModuleIntrinsics]::GetPSModulePath('User')
	}
}

Honestly, I expected [Management.Automation.ModuleIntrinsics]::GetPSModulePath to return the path after accounting for configuration. I guess I should file a bug for that...
I can't imagine any scenario where it's useful for this method to return a path that's not actually in the PSModulePath!
I mean, given that my user powershell.config specifies a %LocalAppData% path, the Documents based path will not be in PowerShell's PSModulePath ...

I have created a Module to simplify the editing of the powershell.config.json file as well as including my function for getting the current "primary" PSModulePath
https://github.com/JustinGrote/ModulePath

Just to add to one of the issues that OneDrive introduces when the Documents folder is included in the sync, and that is retention policies. My organisation defines a OneDrive retention policy of 5 years since Last modified. This means that large chunks of the PS Module path get deleted at odd times, resulting in incomplete module packages which have to be recovered from the OneDrive Recycle bin.
Moving user level modules out of Documents is a critical need when OneDrive retention is in the mix.

My organisational policies prevent me from excluding any paths from OneDrive sync those excluding me from one of the possible work-arounds. I really need the modules to be stored somewhere other than OneDrive for al the reasons discussed here.
I blogged about this in 2021 and frustrating that it's still an issue. Especially when switching between different machines.
https://rohancragg.co.uk/misc/ps-module-paths/

My organisational policies prevent me from excluding any paths from OneDrive sync thus excluding me from one of the possible work-arounds.
Why would it exclude you from the workaround of placing it at a separate path and adjusting your profile to include that as a PSModulePath folder? This doesn't fix PSGet/PSGetv3 and you need to use Save-Module instead of Install-Module but otherwise that should still be a valid workaround until a resolution moves forward.
If you can use PowerShell 7 this is also already fixable, and I made a module for it called ModulePath, again still need to use ModuleFast or Save-PSModule/Resource with an alternate path.


Error when debugging javascript

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.77.3
OS Version: 10.0.22624.1616

Steps to Reproduce:

Debug Javascript code by Launch Edge
Error running browserasd: connect ECONNREFUSED <IP_ADDRESS>:53709

Duplicates https://github.com/microsoft/vscode-js-debug/issues/1603


docs(Translation.md): English-Uzbek tech list

Great  But U have two suggestions.

I think you mean that add russian version. Ok, i will add russian column.

I think you mean that add russian version. Ok, i will add russian column.
Nope
These two:
https://github.com/reactjs/uz.reactjs.org/pull/2#pullrequestreview-201921988
https://github.com/reactjs/uz.reactjs.org/pull/2#pullrequestreview-201922125

I think you mean that add russian version. Ok, i will add russian column.

Nope
These two:
#2 (review)
#2 (review)

Done Umid. You should merge this PR, right?

@turdiyev lgtm

@umidbekkarimov left a some suggestions

@rustamwin please discuss this with PR author - @turdiyev

@umidbekkarimov left a some suggestions

suggestions? for what? Could you please clarify what do you mean?


Hide priority levels in g2 namespace or give them G2 specific names.

Since you're trying to make logger more useful for the general public, here is one suggestion base on a change I've had to make to use your library.
Use slightly less generic names for the priority levels, especially since they're in the global namespace and can easily collide with names from other code.
This could be accomplished by just putting those levels in the g2 namespace, or prefixing them with G2.  (e.g. G2INFO, G2DEBUG).
This is partially addressed with CHANGE_G3LOG_DEBUG_TO_DBUG.  but I think the namespace or G2 prefix would be a clearer solution.
P.S. Also, maybe change all the g2 references to g3?

I haven't precisely solved this yet. I have however added the possibility to, at initialization, add custom logging levels.  The standard ones are still there but now you can add both your non-fatal level as well as fatal level.
From what I have heard only DEBUG has caused issues, which should be taken care of with DBUG.
I am hesistant in changing the levels to G3DEBUG, G3INFO, G3WARNING ... etc due to that would have lots of consequences for coders out there.
If INFO, WARNING, FATAL etc causes issues I hope people will tell me about it and I might reconsider.
Sounds good Will?

Yeah, it's not an essential change, and it's easy enough to just change those level names yourself if necessary.


feat(pagination): Add force-ellipses option to display ellipses when rotate is true

When we have more pages than can be shown and we're rotating, ellipses can be shown. Example:
Previous, ..., 3, 4, 5, 6, 7, ..., Next
Based off https://github.com/angular-ui/bootstrap/pull/3035 and makes that an opt-in feature
Addresses issue https://github.com/angular-ui/bootstrap/issues/2924

Added this functionality to referenced pr.


[FEATURE] Weapon/Armor Levelling System

Weapon and Armor Leveling will provide XP based on mob kills, with different XP amounts for different types of mobs.

XP Distribution: Passive mobs grant 10 XP, and bosses grant 50 XP. This base XP can be adjusted based on the mob's level. For instance, a level 48 passive mob could have its XP multiplied accordingly.

Weapon Leveling: Each weapon level increases damage by 0.1.

Armor Leveling: Each armor level increases armor by 0.1 and boosts damage reduction based on a predefined maximum. For example, if the config sets a maximum damage reduction of 75% and each level grants 1% reduction, you would reach the max reduction well before hitting 500 levels. Beyond that, damage reduction would cap at 75%, but armor would continue to increase, reaching +50 armor at level 500.

TODO

[ ] Make XP goals from mobs as described above and add XP scaling for each level on both armor and weapons.
[ ] Specify what each level gives to both armor and weapons EX. Each level gives 0.1 attack damage to weapons and 0.1 armor and a percentage of damage reduction to armor.
[ ] Add configs to allow users to specify how much each mob type gives in terms of XP, how much armor and damage reduction each level gives, how much attack damage each level gives, what the max level should be, and the level scaling like the amount of XP between each level, and to turn off the feature.
[ ] Make it so weapons in the wild have random weapon levels, and so does armor. Make it a range of levels per specified dimension. EX. Overworld Range 1-50, Nether Range 70-90, etc
[ ] Make it compatible with Simple Discord RPC to show weapon/armor levels on the RPC

I will work on this :D

MY TODO LIST

[ ] Make XP goals from mobs as described above and add XP scaling for each level on both armor and weapons.
[ ] Specify what each level gives to both armor and weapons EX. Each level gives 0.1 attack damage to weapons and 0.1 armor and a percentage of damage reduction to armor.
[ ] Add configs to allow users to specify how much each mob type gives in terms of XP, how much armor and damage reduction each level gives, how much attack damage each level gives, what the max level should be, and the level scaling like the amount of XP between each level, and to turn off the feature.
[ ] Make it so weapons in the wild have random weapon levels, and so does armor. Make it a range of levels per specified dimension. EX. Overworld Range 1-50, Nether Range 70-90, etc
[ ] Make it compatible with Simple Discord RPC to show weapon/armor levels on the RPC


Insert the right link for the "Add Your Tech Community" button

The link for the button "Add Your Tech Community" currently leads to /register
It should lead to /signup

This has been merged


Add function to calculate "Calculated values" for general user EXPORT files

The AWUDS EXPORT files that the general WSC user will be using do not have calculated values (total withdrawals, coefficients, etc.).
This function would use one of the files from Todd that has the equations for all of the calculated values.  Todd's table may have the data element names with hyphens in them.  These may need to be changed to periods??

Not sure what all the calculated values are. But would there be categorical totals that could be readily displayed in a (stacked) bar chart by year?  Just thinking of ways reviewers could quickly spot a problem area - as well as to generate possible report products. Maybe this was mentioned elsewhere...
Here's an example breakdown for categorical and GW/SW for INKY in 2010:

If the state annual categorical totals will be available, these might be displayed in clustered or stacked bar charts.  Here's the IN data from NWISWeb for the national compilations, for example.
(First converted from wide to long format.)
#reformat the data to year, category, and value
categories <- c("PS", "DO", "IN", "TE",  "MI", "LS", "IR", "AQ")
library(tidyr)
test<-gather_(INWU, "TYPE", "VALUE", c(categories), na.rm = FALSE,
convert = TRUE, factor_key = FALSE)
ggplot(test) + geom_bar(aes_string(x = "YEAR", y = "VALUE", fill = "TYPE"),
position = "dodge", stat="identity")
ggplot(test) + geom_bar(aes_string(x = "YEAR", y = "VALUE", fill = "TYPE"),
position = "stack", stat="identity")
Output:

Will close this issue, but open a new one for the stacked bar chart functionality.


Merge b tags

I tried it the editor on this text: Lorem ipsum.
I wanted to bold ipsum, but I mistakenly only selected psum and bolded it. Then I saw I didn't bold i, hence I selected it and bolded it.
However, I ended up with the following html code:
Lorem ipsum

The non HTML specialist users would think that he finally bolded the whole word. However, this is not what the markup reflects.
How to automatically merge these b tags?

Sorry, Squire does not automatically merge inline tags like this. If you would like to submit a PR to do this, I'm happy to review it.


img with 0 width and 0 height

Hi, I install your modules, everything ok but when I'm looking on the website I have the img into a carousel with 0px width and 0px height.
Do you know why?

Hi there,
This would be because the first item is not getting active class with the JQuery added in my module. Make sure you have the JQuery script tag at the bottom of your body and it should work fine. I have tested this just now as well and replicated the issue

Hi, I checked and jquery is there

Do I have to change the version?

Hi there,
I have tested this using all 3 versions of JQuery from the google hosted libraries and it has worked using all of them.
Please confirm the following:

You have added the following to between your head tag
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">

You have added the following before your the closing body tag
`

`

You have added the following line in the template file that you wish to display the carousel on
<% include CarouselImages %>

You have enabled a carousel on the page from the admin section and added images

As long as you have done the above it should work. It would be hard to figure out what is causing your issue without seeing your actual files from here. This module has been used many times without issue - therefore we can rule out any problems with the module - there must be something in the setup of the module in your project causing the issue. Please review your setup of this module.
Thanks,
Sajan

I did everything and I update jQuery to 3 but I have this error

and this is the link: http://costruzioni.squaladesign.it/

Hi there,
can you please add the following just before your closing body tag and after the JQuery script
<script type="text/javascript">
	$(document).ready(function() {
		$('#carousel').find('.item').first().addClass('active');
		$('#carousel').find('.indicator-pos').first().addClass('active');
	});
</script>

The other way is to add your script tags in your head tags and this should work

I insert jquery into the head...it's ok now
thanks


Add regz/uf2 release build option

Added the ability to run zig build release-regz and zig build release-uf2 which will generate the platform binaries for the respective tools.
This is planned to be used in some CI improvement where regz and uf2 will also be published.

I implemented the release in the root build.zon file, but I can also move it to the per-project build file if that is what makes more sense.


Allow descriptor set to be build from shader reflection

Instead of explicitly defining descriptor sets and vertex input assembly formats when creating a pipeline layout, the builder could instead load the required information from an shader reflection interface. This would simplify setting up render pipelines, but can also cause issues, since the application buffer format is not that obvious.
Some references:

Vulkan: https://github.com/chaoticbob/SPIRV-Reflect
DX12: https://docs.microsoft.com/en-us/windows/win32/direct3d12/d3d12-graphics-reference-shader-interfaces

Building the input assembler state from shader reflection is not possible. The only thing that can be read is the vertex buffer layout. However, given the fact that vertex buffers are quite easy to define, I will remove this requirement for now. If at a later point, this becomes requested, we can link this issue.


[KOGITO-498] - Kogito CLI to read from KUBECONFIG before the home dir

See:
https://issues.jboss.org/browse/KOGITO-498
In this PR we read from the KUBECONFIG env var first before trying the default path, which is $HOME/.kube/config.
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Your feature/bug fix has a unit test that verifies it
[ ] You've tested the new feature/bug fix in an actual OpenShift cluster

Binaries available for the next 24 hours.
Linux:
https://a.uguu.se/xJEdJrgvtaFU_kogito-c35786c52-linux-amd64.tar.gz
Mac:
https://a.uguu.se/ZzTVrTC0LSdz_kogito-c35786c52-darwin-amd64.tar.gz

Tested! Everything worked.
$ kogito --version
kogito 0.6.0
$ kogito use-project cloud-operations
Project set to 'cloud-operations'
$ echo $KUBECONFIG
/home/mmagnani/Workspace/redhat/engineering/kogito/ocp/install/auth/kubeconfig
$ ls -la /home/mmagnani/.kube/
drwxrwxr-x.  4 mmagnani mmagnani  4096 Oct 29 15:52 .
drwx------. 31 mmagnani mmagnani  4096 Oct 28 16:51 ..
drwxr-xr-x.  3 mmagnani mmagnani  4096 Oct 17 19:04 cache
drwxrwxr-x.  3 mmagnani mmagnani 20480 Oct 29 13:33 http-cache


Compatibility with other laptops

I wanted to fork and try it out on my old  Acer V3 371 (i5, 32Gb Ram, 1TB ssd), but im not sure if it going to work. What if i took a pen and and draw apple, would your code consider it as a macbook? Is my four year specs enough to run this code?

In the demo video, we’re running it on a 2013 MacBook Pro, so I’m pretty sure it’ll run fine on your computer.

On Apr 7, 2018, at 5:45 PM, Kirill Berezin<EMAIL_ADDRESS>wrote:
I wanted to fork and try it out on my old Acer V3 371 (i5, 32Gb Ram, 1TB ssd), but im not sure if it going to work. What if i took a pen and and draw apple, would your code consider it as a macbook? Is my four year specs enough to run this code?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I think all the APIs we use for clicking etc are Mac specific - so you'd have to rewrite most of simulate.py at the very least.

I think it would be incredible to have Sistine work on e-ink screens with single board computers like the raspberry pi. It would definitely put this project under the spotlight :)


doc: check and update user guide

[ ] installation @chadcwilliams
[ ] theorists @chadcwilliams
[ ] experimentalists @chadcwilliams
[ ] experiment runners @chadcwilliams
[ ] Workflow @younesStrittmatter
[ ] Online "Behavioral" Experiments @younesStrittmatter

[ ] make sure everything is aligned with new terminology: https://docs.google.com/presentation/d/1OdP4M2ByW8GKTFvcCgDG5HDzUwHKdFEhj1ddH4ClvEw/edit#slide=id.g27e19158dea_1_0
[ ] make sure it works
[ ] no more pooler/sampler distinction
[ ] make sure it conforms with the state logic (if it is relevant for the corresponding section)


add equivalent

https://github.com/LeCoupa/awesome-cheatsheets/blob/016c07af6495f3929824e8727cc4d9e7b4080133/languages/bash.sh#L194
${varname:word}                       is equivalent to                       ${varname:-word}

Can you PR?


Fix git push error for protected CLA branch

The pull request is created from master636875813011825296 to master to fix git push error for protected CLA branch

@opbld16 : Thanks for your contribution! The author, @mikeblome, has been notified to review your proposed change.


Fix activity correlator to continue using same GUID for connection activity

I learnt about this issue internally that Activity Id Correlation was not working properly, and Activity Id GUID was not being reused when connecting to Azure SQL with 'redirection', as that is expected for the same connection activity.
Activity Id should be retained for the physical connection as is also the case with the ODBC driver with sequence increments.
Below code can be used to test the bug and verify the fix:
// EXPECTED: When pooling is disabled, 2 physical connections are made, activity Id should be different
// for both connections but should be same within the redirect flow when performing 2 prelogin handshakes.
// conn1: ClientConnectionID 804265c3-79b1-4c6c-8392-678226b4ec46, ActivityID 1aadd57b-c181-489f-a0d4-5ae9c3f50c86:1
// conn2: ClientConnectionID d535123b-a74b-4731-a08d-abe098dea191, ActivityID 25c04c57-d9b5-4720-ade7-dc6a9dbd3852:1
// conn1: ClientConnectionID fa1f0881-6eaa-4688-9d66-6d22dafbf1c0, ActivityID 1aadd57b-c181-489f-a0d4-5ae9c3f50c86:2
// conn2: ClientConnectionID 58309c6d-56d3-4d35-9cd0-0b1f01347985, ActivityID 25c04c57-d9b5-4720-ade7-dc6a9dbd3852:2

// EXPECTED: When pooling is enabled, 1 physical connection is made, activity Id is same for all prelogin handshakes.
// conn1: ClientConnectionID 04ca1d05-039b-4318-b852-1404edf8c9dc, ActivityID 7fe62ff5-82bd-4c5f-8773-652e3e3e2ccb:1
// conn1: ClientConnectionID e8da8405-0fd7-4b4a-81c1-d4f142c0a3e7, ActivityID 7fe62ff5-82bd-4c5f-8773-652e3e3e2ccb:2
// conn2: ClientConnectionID e3c8823e-077e-498d-83e3-aa1f4f54518e, ActivityID 7fe62ff5-82bd-4c5f-8773-652e3e3e2ccb:3
// conn2: ClientConnectionID 09e83e05-c442-4a3f-b0b3-ea5501606edb, ActivityID 7fe62ff5-82bd-4c5f-8773-652e3e3e2ccb:4

const string CONN_STRING= "Server=*****.database.windows.net; Initial Catalog=***; UID=***; PWD=***; Pooling=false;";

static async Task Main(string[] args)
{
    using SqlClientListener listener = new();
    await RunTest(); // conn1
    await RunTest(); // conn2
}

static async Task RunTest()
{
    using SqlConnection conn1 = new(CONN_STRING);
    await conn1.OpenAsync();
}

public class SqlClientListener : EventListener
{
    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        // Only enable events from SqlClientEventSource.
        if (eventSource.Name.Equals("Microsoft.Data.SqlClient.EventSource"))
        {
            EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All);
        }
    }

    /// <summary>
    /// This callback runs whenever an event is written by SqlClientEventSource.
    /// </summary>
    /// <param name="eventData">Event data captured.</param>
    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        if (eventData.Payload == null)
        {
            return;
        }
        foreach (object payload in eventData.Payload)
        {
            if (payload != null)
            {
                Console.WriteLine(payload.ToString());
            }
        }
    }
}

When looking into traces, notice the activity Id associated with <sc.TdsParser.SendPreLoginHandshake|INFO> event.
Capturing activity Id correlated with connection activity is helpful for troubleshooting purposes.

/azurepipelines run


Update st dependency [fix #4]

This updates the st dependency to address a security vulnerability.
Resolves: #4

I think the build failed for other reasons (addressed in PR #6).

Fix published to npm<EMAIL_ADDRESS>


Client: maybe add a "health" icon, that displays things like battery voltage, last seen, etc

Done as a dropdown on the name of the node, and hidden LED and battery under it.

See also #56


[Android] Xamarin Forms InAppBillingPlugin PurchaseAsync exeption

Bug Information
Version Number of Plugin: 2.0.0
Device Tested On: Android (Fail)
Simulator Tested On:
Version of VS: Visual Studio 2017
Version of Xamarin: <IP_ADDRESS>7729
I need some support regarding InAppBillingPlugin for Xamarin.Forms. First of all I did configuration according to documnetation: https://jamesmontemagno.github.io/InAppBillingPlugin/
application, Google Console (managed products) and iTunes Connect site.
Here is my application code.
private async Task TryInAppPurchace(string androidProductId, string iOSProductId="")
{
if (!CrossInAppBilling.IsSupported)
return;
//Android
var products = new string[] { androidProductId };

if(Device.RuntimePlatform == Device.iOS)
    products = new string[] { iOSProductId };

var billing = CrossInAppBilling.Current;
//billing.InTestingMode = true;

try
{
    var connected = await billing.ConnectAsync(ItemType.InAppPurchase);

    if (!connected)
    {
        await Application.Current.MainPage.DisplayAlert("Connectivity Error", "Unable to connect to the internet.", "OK");
        return;
    }

    var items = await billing.GetProductInfoAsync(ItemType.InAppPurchase, products);
    var item = items.ToList().First();

    //try to purchase item
    var purchase = await billing.PurchaseAsync(item.ProductId, ItemType.InAppPurchase, item.ProductId);

    //possibility that a null came through.
    if (purchase == null)
    {
        await Application.Current.MainPage.DisplayAlert("Purchase Error", "You are unable to buy this product.", "OK");
        return;
    }
    else
    {
        await _pageService.DisplayAlert("Purchased", "Consumable product.", "OK");

        if (Device.RuntimePlatform == Device.iOS)
            return;

        var consumedItem = await CrossInAppBilling.Current.ConsumePurchaseAsync(purchase.ProductId, purchase.PurchaseToken);

        if (consumedItem != null)
        {
            await Application.Current.MainPage.DisplayAlert("New Package added", "Successfully added new package", "OK");
        }
    }
}
catch (InAppBillingPurchaseException purchaseEx)
{
    var message = string.Empty;
    await Application.Current.MainPage.DisplayAlert("Exeption", purchaseEx.Message, "OK");
    switch (purchaseEx.PurchaseError)
    {
        case PurchaseError.BillingUnavailable:
            message = "BillingUnavailable";
            break;
        case PurchaseError.DeveloperError:
            message = "DeveloperError";
            break;
        case PurchaseError.ItemUnavailable:
            message = "ItemUnavailable";
            break;
        case PurchaseError.GeneralError:
            message = "GeneralError";
            break;
        case PurchaseError.UserCancelled:
            message = "UserCancelled.";
            break;
        case PurchaseError.AppStoreUnavailable:
            message = "AppStoreUnavailable.";
            break;
        case PurchaseError.PaymentNotAllowed:
            message = "PaymentNotAllowed.";
            break;
        case PurchaseError.PaymentInvalid:
            message = "PaymentInvalid";
            break;
        case PurchaseError.InvalidProduct:
            message = "InvalidProduct";
            break;
        case PurchaseError.ProductRequestFailed:
            message = "ProductRequestFailed";
            break;
        case PurchaseError.RestoreFailed:
            message = "RestoreFailed";
            break;
        case PurchaseError.ServiceUnavailable:
            message = "ServiceUnavailable";
            break;
    }
}
catch (Exception ex)
{
    //Something else has gone wrong, log it
    await Application.Current.MainPage.DisplayAlert("Exeption", ex.Message, "OK");
}
finally
{
    await billing.DisconnectAsync();
}

}
My problem is that I am not able to buy the same product again and I am getting exeption from Google Play:
{Plugin.InAppBilling.Abstractions.InAppBillingPurchaseException: Unable to process purchase. at Plugin.InAppBilling.InAppBillingImplementation+d__33.MoveNext () [0x00116] in C:\projects\inappbillingplugin\src\Plugin.InAppBilling.Android\InAppBillingImplementation.cs:324
--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in :0 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0003e] in :0 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in :0 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in :0 at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in :0 at Plugin.InAppBilling.InAppBillingImplementation+d__32.MoveNext () [0x00090] in C:\projects\inappbillingplugin\src\Plugin.InAppBilling.Android\InAppBillingImplementation.cs:264
--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in :0 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0003e] in :0 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in :0 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in :0 at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in :0 at DrivingCourse_app.ViewModels.AccessPageViewModel+d__18.MoveNext () [0x0025c] in C:\Projects\GIT-REPO\DrivingCourse_DE\DrivingCourse_app\DrivingCourse_app\DrivingCourse_app\ViewModels\AccessPageViewModel.cs:136 }
Is something wrong with my code? This code is working for every fist purchase of the product, so configuration itself and the general process works.
Any ideas?

Is your purchase a consumable? If not, you can only purchase it once and if you try again, you'll get an InAppBillingPurchaseException with PurchaseError == PurchaseError.AlreadyOwned, which you should handle.

Ok, thanx. Everything seems to fo fine now. It was type of products.

Hello,
Seems I missed first time in my project this line as I want to allow users to purchase many times:
var consumedItem = await CrossInAppBilling.Current.ConsumePurchaseAsync(purchase.ProductId, purchase.PurchaseToken);
First time purchase was successful, but by trying the next time, error is received.
{Plugin.InAppBilling.Abstractions.InAppBillingPurchaseException: Unable to process purchase
Is it possible to fix this so that same users could make a purchase again?
Thanks


Display basic account information of interest:

How much being made per hour on your peer.
How much you are spending per hour on other people's peers.
Who else is using your peer.
Need to receive this data from HUB.

10.03.2016 waiting for HUB.


Fixed ISymbol equality comparisons

Fixes the broken tests mentioned in https://github.com/DotNetAnalyzers/StyleCopAnalyzers/pull/2758.

@sharwell Ready for review.


Single image: white gap at bottom in Safari iOS

I have an issue when using a single Vegas background: when you scroll, a white gap appears at the bottom.The problem only occurs in portrait view and doesn't occur when testing with Adobe Inspect (which uses UIWebView). You can replicate the issue by using a single image:
  $.vegas({
    src:'img/bkg.jpg'
  });

...and by adding an element with enough content to cause scrolling of the page.
Screenshot: https://dl.dropboxusercontent.com/u/5837624/VegasWhiteGapBug.jpg
Anyone know a workaround?

Hi,
I'm seeing this issue now on Firefox 35.0.1 Desktop browser (more apparent on Windows than Mac) - quite frequently. I've also set fade to 0 and it's more visible.
Thanks,
JP

Update:
somehow it gets fixed if I remove the fade option and set the overlay. if I do not set the overlay, then it is quite visible. I also then added fade at 1000 rate and it does work but still you can see the issue on some pictures initially - however when overlay kicks in immediately, it fixes it.
Just thought I should update you on it...
So I set the overlay to 2.png and fade at 1000.
Thanks,
JP

Thanks for the info.


What is the Right way to use discofuse dataset??

Click here for Dataset link
Below is the following way, as per my understanding , Is it correct :question: :question:
The columns/features from DiscoFuse dataset that will be the input to the encoder and decoder are:
Click here for Dataset link

coherent_first_sentence

coherent_second_sentence

incoherent_first_sentence

incoherent_second_sentence

Click here for Dataset link
The encoder will take these four columns as input and encode them into a sequence of hidden states. The decoder will then take these hidden states as input and decode them into a new sentence that fuses the two original sentences together.
The discourse type, connective_string, has_coref_type_pronoun, and has_coref_type_nominal columns will not be used as input to the encoder or decoder. These columns are used to provide additional information about the dataset, but they are not necessary for the task of sentence fusion.
Please correct me if I am wrong; otherwise, if this understanding is right, how shall I implement this task practically?

Thanks for opening https://huggingface.co/datasets/discofuse/discussions/3, let's continue the discussion over there if you don't mind


(#921) add autogenerated cake-version.yml

fixes #921

@Jericho I've added the cake-version.yml to the project.
(I now read the version from there and inject it into msbuild.)


Add scala 2.11.8 and 2.12.3 to .travis.yml

I was trying to reproduce a problem of compiling a project using scala 2.11, so I've created a variation in travis. In the end it didn't help in my case, but maybe you'll find it useful to have this travis configuration in guardrail.
But I'm not sure if there is any value added since guardrail is already cross compiled to both 2.11 and 2.12.
Contributing to Twilio

All third party contributors acknowledge that any contributions they provide will be made under the same open source license that the open source project is provided under.

[x] I acknowledge that all my contributions will be made under the project's license.

I've just seen https://github.com/twilio/guardrail/issues/280, so I'm closing this PR


Add updated BBEs

Purpose

$title.

Codecov Report

Merging #21831 into stage will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            stage   #21831   +/-   ##
=======================================
  Coverage   14.67%   14.67%
=======================================
  Files          51       51
  Lines        1404     1404
  Branches      216      216
=======================================
  Hits          206      206
  Misses       1182     1182
  Partials       16       16

Continue to review full report at Codecov.

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

Language related changes look good to me.

Changes for the security related BBEs are LGTM.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 7 committers have signed the CLA.:x: ldclakmal:x: daneshk:x: chamil321:x: rdhananjaya:x: pubudu91:x: sameerajayasoma:x: shafreenAnfarYou have signed the CLA already but the status is still pending? Let us recheck it.


fix: release workflow

:tada: This PR is included in version 1.1.1 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


[seata-java] insert on duplicate 无法处理一些自增主键的情况

refer: https://github.com/apache/incubator-seata/pull/5075
What happened:
针对主键自增且没有唯一索引值的insert on duplicate语句，由于主键自增值依赖驱动版本情况，需要再测试（https://github.com/apache/incubator-seata/issues/5065），1.6版本先进行拦截。后面的版本再考虑合入（https://github.com/seata/seata/pull/5044）
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:

https://github.com/apache/incubator-seata-go/issues/645 重复 新版本未复现


Manage falco config and rules dependency

Motivation
The Falco configuration and rules files are now statically copied from the current Falco's master version.
Feature
A smarter dependency management solution is needed.
Alternatives
A non-smart but rapid solution could be to point out the user to the available versions of Falco's default configuration and rules files.
Additional context
As for this PR the configuration and rules files are copied only as a temporary solution to the first PR since the integrations were initially intended to be part of the Falco project (and repo).

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/reopen
This is still an issue, IMHO.

/reopen
This is still an issue, IMHO.

@leogr: Reopened this issue.

In response to this:

/reopen
This is still an issue, IMHO.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@leogr: Reopened this issue.

In response to this:

/reopen
This is still an issue, IMHO.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Add ability to move a skills between Skill Groups and/or Subjects

Add the ability to move a skill out of an existing skill group or subject without having to delete and re-create the skill.

PR: https://github.com/NationalSecurityAgency/skills-service/pull/1519

:+1:


Remove public methods from IdNumber that are not intended to be directly called

Describe the bug
It's rather a design issue, not a bug.
I don't like the fact that class net.datafaker.providers.base.IdNumber has all these public methods:

validSvSeSsn()
validEnZaSsn()
inValidEnZaSsn()
invalidSvSeSsn()
validEsMXSsn()
invalidEsMXSsn()
validEstonianPersonalCode()
invalidEstonianPersonalCode()
validAlbanianPersonalCode()
invalidAlbanianPersonalCode()
validMoldovaPersonalCode()
invalidMoldovaPersonalCode()
validBulgarianPersonalCode()
invalidBulgarianPersonalCode()

Problem 1:
I assume they are NOT intended to be explicitly called from client's code.
Instead, clients should generate corresponding ID numbers using locale/country:
  Faker faker = new Faker(new Locale("et", "EE"));
  String code = faker.idNumbers().valid();

Problem 2:
Having these methods as public makes it impossible to extend functionality of DataFaker. Like, when user adds a custom JAR to classpath that implements yet another language/country.
Expected behavior
It should be possible to add "yet another country" without adding any new public methods.
It should be enough just to add file "LANG.yml" and probably some (package-private) classes like BulgarianIdNumber.
Versions:

Faker Version: 2.2.2

@bodiam @snuyanzin thoughts?

If that's the intent then I'm in agreement. I haven't been working on the project long enough to know.

Makes sense. I don't think we have a super clear agreement about what is our public api vs our more internal. What would you propose to limit the visibility of these methods? Make them package protected? Or something else?

I think we don't need these methods at all.
What I suggest:

Remove public methods from IdNumber class:

public String validMacedonianPersonalCode()
public String invalidMacedonianPersonalCode()
etc.

Load all classes like MacedonianIdNumber as service providers (a built-in mechanism in Java). Every provider knows what country it's responsible for.

I can submit a minimal pull request to demonstrate this approach.

yes that probably makes sense
why it was done in current way - probably nobody knows since it was done in javafaker first and those contributors are not active in both communities...
The only thing to note since they are public for a long time then first need to mark as deprecated and then remove later

@asolntsev may be for future: I would suggest squashing commits while merging since it will simplify navigation through commits history
All the highlights could be done in commit message

@snuyanzin Thanks. Yes, in this case I should squash all commits.
But generally it's not always a good idea. Independent changes should stay in separate commits.

yep, in generic case it depends on the context

For my two cents it's the overall contribution that matters to the project not the individual bits of work/correction. So I'm in favour of squash and merge or using amending commits.


About using Prettier in tslint-eslint-rules

Can we use Prettier for formatting TypeScript code in tslint-eslint-rules?
Prettier is an opinionated code formatter. It removes all original styling and ensures that all outputted code conforms to a consistent style.
We recently started using Prettier for private projects, and life has been better. We don't worry/argue about formatting any more 😊
Of course there was initial oppositions to some of the decisions taken by Prettier (like lack of parenthesis around single param arrow functions), but we got used to it with time. [Update: Prettier 1.9 now has support for arrowParens]
For Open Source projects which don't use Prettier, I manually run Prettier CLI for the files which I'm editing. I believe developers will be more productive if we use formatters like Prettier in tslint-eslint-rules. What do you think?

Sure thing! I love Prettier :)

👍
I'll raise a PR with Prettier once my other PRs are merged to master https://github.com/buzinas/tslint-eslint-rules/pulls

FYI, we do lint our code in an opinionated way using the rules we create: https://github.com/buzinas/tslint-eslint-rules/blob/master/tslint_eslint_rules.json
This is ran everytime we use npm test as well as the rules from tslint.json.

Sure, I'll remove tslint-eslint-rules used in this project which are conflicting with Prettier formatting rules.

Closing as TSLint is going to deprecated some time in 2019 (announcement)


Cannot specify which device to use

Hello.
I ran into an issue trying to compile a pytorch model. I have a node with multiple GPUs and I was using device cuda:1. There was nothing running on the GPU and the VRAM was not utilized. My model failed to compile due to a CUDA OOM error and threw an error on this line.
https://github.com/triton-lang/triton/blob/a5b3783491a42a61ed5b8cb32a1178eb08e7b085/python/triton/testing.py#L114-L117
It looks like the code does not use the device on which the model is, but always uses cuda, which defaults to cuda:0 device. In my case, devive cuda:0 was being used and its memory was totally full, which led to an OOM error.
It would be good if the testing code here used the device used by the model or you could specify it in a way.
Best regards,
Andrej

use torch.cuda.set_device to change the default cuda device or parse 'cuda:1' instead of cuda

use torch.cuda.set_device to change the default cuda device or purse 'cuda:1' instead of cuda


Listener is not listened, rfxvmt.dll not helping on Windows 10 x64 Home One Language 10.0.16299

I get rfxvmt.dll from Windows 10 x64 Pro then copy it to C:\Windows\System32\rfxvmt.dll
Then fix Security for Trusted Installer
rfxvmt.dll SHA1 - 81D4AD81A92177C2116C5589609A9A08A5CCD0F2, MD5 - E3E4492E2C871F65B5CEA8F1A14164E2
But it is not helping. I also try reboot many times with and without fix for Trusted Installer but nothing helped.

RDPWrap prints version 10.0.16299.15
ver prints version Microsoft Windows [Version 10.0.16299.98]

Did you tried reinstalling RDP Wrap after you copied that file?

Yes. I tried Install, copy rfxvmt.dll, reinstall
I tried also - reboot, uninstall, reboot, install, update, reboot
But nothing helped.
System is Asus All-In-One PC Windows 10 x64 Home One Language.
May be there is a difference between Home and Home One Language?
I have 3 computers with Windows 10 x64 Pro and 1 with Windows 10 x64 Home One Language.
Also, I found that, when RDPWrap is running, I cannot delete rfxvmt.dll, so this library is used, but nothing happened

Also, on one computer with Windows 10 x64 Pro I found that rfxvmt.dll in System32 and in SysWOW64 are different. But when I copy rfxvmt.dll on my Home system it automatically changed in System32 and in SysWOW64

But when I copy rfxvmt.dll on my Home system it automatically changed in System32 and in SysWOW64

Probably, that's the reason of your problem. Try monitoring what changes this file.

If you use 32-bit application to copy file
MS File System Redirector can be a cause
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx

You should use native version of DLL file (if your system is 64-bit, you must use 64-bit DLL and place it in system32).

Problem was: I used 32-bit Total Commander to copy files.
When I use 64-bit all back to normal
I attached new rfxvmt.dll from Windows 10 x64 Pro 10.0.16299.15 from latest update
dlls.zip
Now all is working fine. This is interesting, I don't knew that copy operations to C:\Windows\system32 are redirected for 32-bit process

I don't knew that copy operations to C:\Windows\system32 are redirected for 32-bit process

That's WOW64 file redirection at work.

I think, that description of copy operation in 32/64-bit process must be added to readme :-)
In 64-bit OS user must use 64-bit file manager for copy rfxvmt.dll's to system32 & SysWOW64
After it this issue can be marked as solved.

seems like after latest updates to this day the Dll fix isn't working anymore for Home version

Hi,
Fixed! The problem is the incorrect "rfxvmt.dll" privileges. See this post:
http://github.com/stascorp/rdpwrap/issues/194#issuecomment-353029623
Please, close this issue!

Closed as duplicate of #194.


Upgrade to latest release 0.94i

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender.

@isuruf Any chance we can switch to the upstream versioning scheme 0.94i instead of 094i?

Hm…we're essentially at version 94 now:
>>> from conda.resolve import normalized_version
>>> A=normalized_version('094h')
>>> A.version
[[0], [94, 'h']]
>>> B=normalized_version('0.94i')
>>> B.version
[[0], [0], [94, 'i']]

@conda-forge-admin, please rerender.

@conda-forge-admin, please update circle

@isuruf If you know some trick to get CircleCI back online that would be great :)

@conda-forge-admin, please rerender


fix incorrect email address

Description
change lbryio to lbry.com and added . to this email

Thanks @ykris45 !


documentation bug: long names of subscription-send options start with lowercase character

Bug Description
The long names of subscription-send options are expected to start with a lowercase character.
In the DS CRIS 2023.01 documentation (page 78) the long names start with an uppercase character instead.

Thank you for reporting it, it has been fixed and will be included in next release's documentation