Feature Request: Terminal should listen for the WM_SETTINGCHANGE for environment variable updates

Summary of the new feature/enhancement
When I install an app that updates the path or I update the path manually, it isn't enough to kill an individual tab in the Terminal and start a new one.  The new tab still inherits the old, unchanged environment variable values. This means I have to kill/restart the Terminal and lose all my tabs.
Proposed technical implementation details (optional)
Add a Windows message handler for WM_SETTINGCHANGE and update the Terminal process's environment block so that any new tabs get the updated environment variables.

Related discussion in ConEmu. https://github.com/Maximus5/ConEmu/issues/468

Opening a new tab should definitely inherit from the current system environment.

<This was a kind of unfocused train of thought, though I'm happy with the conclusion at the bottom. leaving my own notes so I can remember whenever I get back to this>
Huh, this might be a bit trickier than I thought. WM_SETTINGCHANGE doesn't tell you which variable changed, only that the "Environment" changed. If we call GetEnvironmentStrings, we're still going to just get our launch environment variables.
We could call CreateEnvironmentBlock with nullptr as the hToken to get a fresh system environment block, but that's probably wrong, since we want the user's environment block. That involves also calling LogonUser. That's presumably doable.
Though, if the user launched the Terminal from one process with some extra variables set, and expected it to inherit variables from the parent process, then we probably shouldn't blow away the env vars for the first tab that's created. I suppose we could only do this refreshing of the environment block when we do get a WM_SETTINGCHANGE. Subsequent tabs would all use the user's default env block, not the one inherited from the parent. That's a little funky - it sorta creates scenarios that aren't totally expected, because sometimes the parent's values would persist to subsequent tabs.
I guess the most unified solution would be to just use a fresh environment block for all connections created after startup. That would at least be consistent behavior. We'd probably want to wait for #4023 to merge first, and set some internal flag to use a fresh env block, only after all the startup actions are processed. Then we wouldn't even need to use WM_SETTINGCHANGE, we'd just assume that you wanted a fresh one.

Opening a new tab should definitely inherit from the current system environment.

nit: I would suggest the current user environment. explorer.exe does this correctly when launching new processes, so I hope it's not too complicated.

Make sure when we reload this, we also reload settings. That'll probably fix the keyboard issue in 4735.

My experience with this issue, see #5477 details, is that restarting windows terminal app doesn't resolve the issue, at least in the case of the windows system and user path environment variable that i was focused on.  In my case i had to visit win+s | apps & features | search = windows terminal | advanced options and select "reset" which also wipes my customized profile.json that i then have to manually copy backup of it back into place.  A lot of work just to have new terminal tabs pickup system and user path updates.

If this one is solved by loading a new environment block on each new tab creation, then we'll still need separately to handle WM_SETTINGCHANGE to rectify the currently-closed-as-duplicate-of-this #4735.

Perhaps wt could "just use a fresh environment block for all connections created after startup" as previously suggested, but let the command line or settings.json list some environment variables that need to be copied from the environment of the wt process instead. Deliberately running wt with environment variables that differ from the user's defaults is a niche scenario. I don't think a three-way diff should be implemented.

The environment variables bit of this was addressed in #7243; I'm leaving it open for the other environment settings.

The environment variables bit of this was addressed in #7243; I'm leaving this issue open for the other environment settings.

I think it makes more sense to have a new ticket for WM_SETTINGCHANGE handling, the vast majority of tickets duplicated to this, and discussion on this ticket, were about env-vars specifically. They were mostly $ENV:PATH in fact.
I think it's only #1230, and #4735 that were interested in other uses of WM_SETTINGCHANGE. And #6491, but that's a super-set of #1230.

Add a Windows message handler for WM_SETTINGCHANGE and update the Terminal process's environment block so that any new tabs get the updated environment variables.

Windows API allows to create new process with custom env block. So there is no need to handle events. PowerShell does this in some scenarios.

That's the approach used in #7243, but it caused problems and had to be reverted; see #7418 and e.g., 616a71dd23e8fff717919c20c382edeaf59f433a

That's the approach used in #7243, but it caused problems and had to be reverted; see #7418 and e.g., 616a71d

@TBBle Thanks for pointing #7418. I leave a comment there. I guess there was a wrong implementation :-(

Windows API allows to create new process with custom env block. So there is no need to handle events. PowerShell does this in some scenarios.

The environment should only be reloaded when some process in the session requests a reload by broadcasting WM_SETTINGCHANGE for an "Environment" update, which is when Explorer reloads its environment. It should not be reloaded for every new tab. It should change in lock step with Explorer.
The major problem is getting access to a public API that updates the environment using the same sequence as the shell API's private RegenerateUserEnvironment() function. There's a need for a public version of RegenerateUserEnvironment(), or CreateEnvironmentBlock2().

For those of you who can follow along, I've filed MSFT-37424054 to track documenting and making available RegenerateUserEnvironment. Right now it's an unanswered ask on the team that owns shell32. :smile:

Please, just check for new environment variables when a new tab is created.

Please, just check for new environment variables when a new tab is created.

I thought the point was to behave like running a console application from Explorer, which inherits its environment from Explorer.
If a user or application modifies environment variables in the registry without broadcasting WM_SETTINGCHANGE "Environment", then it's not meant for the current session. Otherwise, for the past 25 years or so, the shell API would also have called RegenerateUserEnvironment() when spawning a new process.

@ErykSun Pending us getting RegenerateUserEnvironment documented/publicly available, do you have any thoughts on whether Terminal should try to maintain environment variables it inherited that were different from the user environment?
There have been a couple reports that WT Preview no longer supports e.g. FOO_BAR=1 wt cmd ... echo %FOO_BAR%.
It seems like we'd be playing with fire, trying to reconstitute what the user wants in that case. I'm failing to think of a better thing for us to do, unless we just want to say "plz don't do that, just accept that you can't inherit environment variables."
After all, inheritance becomes ~ ~ strange ~ ~ when one Terminal window can act as the destination for any number of wt commands from any number of sources.
Maybe that's my answer.

@miniksa is looking at some of our options here and will report back.

Just so we have this all in one place

original issue: #1125
Original PR: #7243
PowerShell Issue that made it apparent that CreateEnvironmentBlock was insufficient: #7418
Internal tracking RegenerateUserEnvironment: MSFT:37424054
Implement env vars in settings (like in VScode) (original request: #2785, PR: #9287)
maybe related: #11777

@zadjii-msft, note my comment in https://github.com/microsoft/terminal/issues/12157#issuecomment-1012606082. When Terminal is run from the start menu or "Open in Windows Terminal", a system service does the work of spawning the process. The service creates a new environment block for the user via CreateEnvironmentBlock(). So Terminal's initial environment may not be expanded the same as Explorer's. I think it should immediately call RegenerateUserEnvironment(), or something equivalent to that. Don't wait for a WM_SETTINGCHANGE message.
When using just CreateEnvironmentBlock(), a second expansion of the environment block using RtlExpandEnvironmentStrings() may help if a REG_EXPAND_SZ variable wasn't expanded completely when the environment was created. This is what the "appinfo" service does when Terminal is run from the start menu.
For example, a system REG_EXPAND_SZ variable can't depend on system variables that CreateEnvironmentBlock() hasn't set yet, such as "COMPUTERNAME", "ProgramFiles" and "CommonProgramFiles", but these variables should be defined the second time around.  Similarly a user REG_EXPAND_SZ variable can't rely on volatile user variables that CreateEnvironmentBlock() hasn't set yet, such as "USERNAME", "HOMEDRIVE", and "HOMEPATH", but they should be defined when the environment is expanded the second time.
A second expansion does not guarantee, however, that REG_EXPAND_SZ variables can arbitrarily reference other REG_EXPAND_SZ variables that are defined in the same "Environment" key. For example, assume that REG_EXPAND_SZ variable "X" is defined as "%Y%"; REG_EXPAND_SZ variable "Y" is defined as "%Z"; and REG_SZ variable "Z" is defined as "spam". When the environment is created, if "X" is set before "Y" is set (based on the arbitrary enumeration order of the registry key), the value of "X" won't be expanded, but for sure the value of variable "Y" will be expanded to "spam" since REG_SZ "Z" is loaded first. In this case, a second expansion fixes the value of "X". On the other hand, say these are system variables, and the raw value of "Y" is changed to "%ProgramFiles%". In this case, "Y" will never be expanded when the environment is created since CreateEnvironmentBlock() doesn't set "ProgramFiles" in the environment block until after the system "Environment" key is loaded. Thus a second expansion sets the value of "X" to "%ProgramFiles%", which will require a third expansion.

@eryksun I'm working on this here if you want to peek: https://github.com/microsoft/terminal/blob/dev/miniksa/env/src/inc/til/env.h
I can't say I've addressed all your concerns yet, but I have tried to replicate the spirit of how the OS and Explorer work behind the RegenerateUserEnvironment() function. It should be pretty close.

@miniksa, Windows uses reserved environment variables with names that begin with "=", which effectively makes them hidden variables in most cases. This isn't a problem in practice, given an empty name is disallowed in "name=value" entries. CMD uses a hidden "=ExitCode" variable. The most common use is to store the working directory on a drive. For example, to resolve "Z:spam", the Windows API checks for an "=Z:" environment variable. The CMD shell's CHDIR command sets these variables, as does the C runtime's _[w]chdir().
You can set and check hidden variables directly via WinAPI SetEnvironmentVariableW() and GetEnvironmentVariableW(), or by examining the PEB with a debugger (e.g. the  !peb command). CMD has a well-known bug when executing set " or set "" that displays them.
Defining hidden environment variables in an "Environment" key is not supported. They're documented as reserved names: "[equals] must not be used in the name". They can't be defined or modified conventionally as persistent variables -- not via the GUI editor, "setx.exe", or  .NET SetEnvironmentVariable(variable, value, target). One would have to modify the registry directly.
That said, RegenerateUserEnvironment() loads any 'hidden' environment variables defined in the "Environment" keys. If you're looking to match the behavior of RegenerateUserEnvironment() as close as possible, then your code should retain them. At the least, I think an intentional choice should be made. If you want to support hidden environment variables that are defined in the registry, then the find_first_of() call in parse() should be modified to start at index 1. If you instead want to filter out all hidden variables, the loop should be modified to skip the entry when pos is 0.  The current code keeps the first such entry that's found.

@miniksa
In PT Run I have recreated the behavior of the os nearly exactly including removing and renaming variables.
You find the code here and many helpful informations here.

(Regarding hidden env vars I am not sure where the use case should be.)

It's a matter of which behaviors of RegenerateUserEnvironment() should be intentionally preserved or rejected, instead of letting something slip through as undefined behavior. The current code stores the first 'hidden' variable to the mapping, and ignores the rest. I think ignoring them all is perfectly acceptable behavior. It's a small change to the code.
I just wanted to explain the details, in case people are unfamiliar with such variables. They are illegal environment variable names in the .NET and C runtime (though the C runtime itself sets them), and often they aren't displayed (e.g. Process Explorer doesn't show them), so I'd venture that some developers aren't even aware of their existence.
If someone happened across the existence of 'hidden' environment variables (e.g. set "" in CMD) and decided to define one in the registry, it's better for it to not be defined at all under Windows Terminal, instead of letting just that one variable slip through.

In PT Run I have recreated the behavior of the os nearly exactly including removing and renaming variables.

RegenerateUserEnvironment() and CreateEnvironmentBlock() have to load almost every environment variable from the registry or API calls. RegenerateUserEnvironment() starts with an already loaded environment for the current user, so it can selectively re-use more, but it's not much more. It still loads most variables from the registry and API. Refer to Michael's code.

@miniksa, Windows uses reserved environment variables with names that begin with "=", which effectively makes them hidden variables in most cases. This isn't a problem in practice, given an empty name is disallowed in "name=value" entries. CMD uses a hidden "=ExitCode" variable. The most common use is to store the working directory on a drive. For example, to resolve "Z:spam", the Windows API checks for an "=Z:" environment variable. The CMD shell's CHDIR command sets these variables, as does the C runtime's _[w]chdir().
You can set and check hidden variables directly via WinAPI SetEnvironmentVariableW() and GetEnvironmentVariableW(), or by examining the PEB with a debugger (e.g. the !peb command). CMD has a well-known bug when executing set " or set "" that displays them.
Defining hidden environment variables in an "Environment" key is not supported. They're documented as reserved names: "[equals] must not be used in the name". They can't be defined or modified conventionally as persistent variables -- not via the GUI editor, "setx.exe", or .NET SetEnvironmentVariable(variable, value, target). One would have to modify the registry directly.
That said, RegenerateUserEnvironment() loads any 'hidden' environment variables defined in the "Environment" keys. If you're looking to match the behavior of RegenerateUserEnvironment() as close as possible, then your code should retain them. At the least, I think an intentional choice should be made. If you want to support hidden environment variables that are defined in the registry, then the find_first_of() call in parse() should be modified to start at index 1. If you instead want to filter out all hidden variables, the loop should be modified to skip the entry when pos is 0. The current code keeps the first such entry that's found.

I did notice the allowance for the leading = in the underlying code, but I wasn't really aware of the impacts or usages of them. I don't think I excluded them on purpose. It could be that I misread some of what is behind RegenerateUserEnvironment() and still need to work it out. My goal is this operates the same as that.
I do also know I still need to handle the recursive processing aspect of later variables being able to have things substituted in from earlier ones.

When I faced the issue yesterday and wondered whether it was already tracked here, I had no idea this was being discussed for more than 2 years...
I understand there are many corner cases, but couldn't the base use cases (user or app installer updates the user or system env vars) be addressed as a temporary solution?

Funny enough, we had a temporary solution! We only recently backed it out because it caused more problems than it fixed. :)

Being a "late joiner", I wonder if there is a solution for windows-terminal to reload updated PATH environment variable.
I just noticed that after I updated the PATH environment variable, it was not updated in an existing command prompt in windows-terminal, nor was it updated it new command prompt tabs
However, when I opened a new window of windows-terminal, the PATH was up to date
Is there a "reload environment" command in windows-terminal?

No, which is why this issue is still open. The closest workaround I have is to run
$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")

after you update the PATH.
Source

I observe the same behavior. I installed the package via winget that updated PATH variable, but it is not reflected in terminal

the opening new tab in terminal does NOT help, I need to reload the terminal. Very uncomfortable and inconvenient.

I need to reload the terminal. Very uncomfortable and inconvenient.

That's especially inconvenient when one has long-running workloads in existing tabs. You just can't stop and reload the terminal. And I don't know how to start another terminal instance.

$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")

I had almost filed a bug with Node.js, then almost filed a bug with PowerShell, until I finally found this ticket. I had found the same workaround that @dexeonify mentioned.
Yes, I can see putting that workaround my PowerShell $PROFILE so that every time I start PowerShell I know I'm getting the "one true path" (although I don't like the way that sounds, now that I think about it); but … really? Am I misreading things, or has this ticket been unresolved for over three years?!
Is this on any team's schedule to address? I think most people here would agree that just reloading Path would be a major step forward. The current situation is only furthering Windows' reputation that "I have to reboot after the slightest change for things to work properly".

I've read most of the comments here, and I still don't get why closing the entire Microsoft Terminal instance and restarting it doesn't result in the latest Path environment variable being loaded. Surely Microsoft Terminal doesn't keep running in the background, does it?

It does
Sent from Ninehttp://www.9folders.com/

From: Garret Wilson @.***>
Sent: Saturday, October 1, 2022 19:54
To: microsoft/terminal
Cc: Bruno Brant; Manual
Subject: Re: [microsoft/terminal] Feature Request: Terminal should listen for the WM_SETTINGCHANGE for environment variable updates (#1125)
I've read most of the comments here, and I still don't get why closing the entire Microsoft Terminal instance and restarting it doesn't result in the latest Path environment variable being loaded. Surely Microsoft Terminal doesn't keep running in the background, does it?
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/terminal/issues/1125#issuecomment-1264500395, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAONUVAKB4PL62LMEJOJW7DWBC6LNANCNFSM4HSSQSKA.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

It does

It sure shouldn't be. There might be a lasting RuntimeBroker.exe, but I don't think that should have anything to do with it. Closing all the Terminal windows (s.t. there are no windowsterminal.exe's running) should cause the next Terminal launch to have a fresh env block.

Closing all the Terminal windows (s.t. there are no windowsterminal.exe's running) should cause the next Terminal launch to have a fresh env block.

But alas … it doth not. 😒

Now this problem more seriously.
Because of this program add a feature that can merge new window to existing window, so that I can't use Run command to create a new task to reload environment variable.

I can start a new cmd from windows start menu and my user PATH is loaded
If i do the same ( same cmd and params) via terminal it doesn't reflect the PATH changes.
I can open a dozens new terminal windows cmd windows from the same running terminal parent instance - issue still remains.
It seems to recover when i completly terminate the terminal parent and create a new and a new cmd window . so its terminal app caching the context. Do you use some cached state of context?
How to enforce REAL (re)loadind onf env?
My workaround is now to use choco's "refreshenv" .. but5 hey this is definitely a bug in the terminal application so please reopen this issue.

so please reopen this issue.

Thanks for the feedback! As you'll notice, this issue is currently open. We've got an idea how to solve this with the work being done in #12516, now we just need to book some time to polish that out.
If anyone is interested in helping out, I'd be more than happy to help give an outline of what I was planning on doing with that thread. It'll unfortunately be a few months before I can loop back on that, so if folks want this sooner than that, I'd appreciate the help ☺

Okay, if I was gonna do this, here's how I'd approach this. I'd make it two PRs. One to finish building the helper class, and one to actually integrate it into the Teminal

[ ] Finish the til::env PR, #12516.

This was intended to be a helper that would generate an env block similar to the way that the Windows shell does when launching new processes from explorer.exe.
I honestly don't know what's missing from the PR. Fortunately, @miniksa is still a close friend of the team, so I think he'd be more than willing to give some pointers.

[ ] Generate fresh environment blocks for every connection (tab, pane, etc)

[ ] Use a til::env to generate the new env block.
[ ] TerminalPage::_CreateConnectionFromSettings (in TerminalPage.cpp) is the method responsible for creating new ConptyConnections (which is what's used to hook the Terminal up to a cmd.exe or other commandline process)

In that method, we're already injecting a couple env varsStringMap envMap{};
envMap.Insert(L"WT_PROFILE_ID", guidWString);
envMap.Insert(L"WSLENV", L"WT_PROFILE_ID");

So that seems like about the right place to make changes to me.

[ ] We should also add a global setting to allow folks to opt-out of this behavior (in case we break someone's workflow)

[ ] This should be stored in the Global settings, so you could add a bool to the MTSM_GLOBAL_SETTINGS x-macro in MTSMSettings.h.
[ ] Name it something like experimental.reloadEnvironmentVariables, and default it to true.

I honestly think that's it. That should just work. We shouldn't need to listen for env var updates, because we should just get a fresh block everytime.
And then we can handle ourselves the follow-up of merging #9287 with the code written to solve this issue.

AFAIK, it was pretty much done except for me updating the spell check and perhaps adding more tests. It probably just needs a spit shine then check it in and call anything else a bug, @zadjii-msft.

Ah, plus me imploring you to "please stop inheriting from std::map"


Corrected typos in README.md

Hi!
I stumbled upon a typo, so I read through the readme and corrected a few more.
Thanks for a great package, I hope to be able to use this in production soon! :+1:

thx


Add input sanitization and validation

Aside from input sanitization and validation, the callbacks folder was also refactored for better modularization:

Each page/view corresponds to one folder inside callbacks
This folder contains two files callbacks.py and util.py to isolate callback from utility methods

Phoebe (@pbong), kindly review/accept this pull request before proceeding to session implementation.


STDOUT usage

I'm using Composer in somehow interesting way.
Long story short: it works under mod_php/php-fpm, not in CLI mode.
But with this plugin it causes an issue:
  [ErrorException]
  Use of undefined constant STDOUT - assumed 'STDOUT'

Exception trace:
 () at /web/cscms.org/www/storage/Composer/tmp/vendor/hirak/prestissimo/src/CurlRemoteFilesystem.php:77
 Composer\Util\ErrorHandler::handle() at /web/cscms.org/www/storage/Composer/tmp/vendor/hirak/prestissimo/src/CurlRemoteFilesystem.php:77
 Hirak\Prestissimo\CurlRemoteFilesystem->Hirak\Prestissimo\{closure}() at /web/cscms.org/www/storage/Composer/tmp/vendor/hirak/prestissimo/src/CurlRemoteFilesystem.php:146
 Hirak\Prestissimo\CurlRemoteFilesystem->fetch() at /web/cscms.org/www/storage/Composer/tmp/vendor/hirak/prestissimo/src/CurlRemoteFilesystem.php:84
 Hirak\Prestissimo\CurlRemoteFilesystem->copy() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Downloader/FileDownloader.php:139
 Composer\Downloader\FileDownloader->doDownload() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Downloader/FileDownloader.php:91
 Composer\Downloader\FileDownloader->download() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Downloader/ArchiveDownloader.php:36
 Composer\Downloader\ArchiveDownloader->download() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Downloader/ZipDownloader.php:65
 Composer\Downloader\ZipDownloader->download() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Downloader/DownloadManager.php:213
 Composer\Downloader\DownloadManager->download() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer/LibraryInstaller.php:176
 Composer\Installer\LibraryInstaller->installCode() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer/LibraryInstaller.php:90
 Composer\Installer\LibraryInstaller->install() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer/PluginInstaller.php:61
 Composer\Installer\PluginInstaller->install() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer/InstallationManager.php:152
 Composer\Installer\InstallationManager->install() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer/InstallationManager.php:139
 Composer\Installer\InstallationManager->execute() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer.php:568
 Composer\Installer->doInstall() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Installer.php:228
 Composer\Installer->run() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Command/UpdateCommand.php:173
 Composer\Command\UpdateCommand->execute() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/vendor/symfony/console/Command/Command.php:259
 Symfony\Component\Console\Command\Command->run() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/vendor/symfony/console/Application.php:844
 Symfony\Component\Console\Application->doRunCommand() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/vendor/symfony/console/Application.php:192
 Symfony\Component\Console\Application->doRun() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Console/Application.php:181
 Composer\Console\Application->doRun() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/vendor/symfony/console/Application.php:123
 Symfony\Component\Console\Application->run() at phar:///web/cscms.org/www/components/modules/Composer/composer.phar/src/Composer/Console/Application.php:99
 Composer\Console\Application->run() at /web/cscms.org/www/components/modules/Composer/Composer.php:127

Can you get rid of using STDOUT directly or use something else if it is not available? Composer itself provides an abstraction on top of that using Symfony's components, maybe you can use it?

@nazar-pc That file deleted in prestissimo-0.2.x. Please try update.
$ composer global remove hirak/prestissimo --no-plugins
$ composer self-update
$ composer global require hirak/prestissimo


TabularGrid on frontend / PageController

Is it possible to use TabularGrid directly in PageController? As I see (getCompatLayer() method), controller with form should extend LeftAndMain (Silverstripe's or Admini's).
I need CRUD dataobjects on frontend. I created Form with TabularGrid in PageController, I can see list of items, but editing causes error because getCompatLayer returns null in such usecase.
Thanks for help.

i've never tried so far but it should work as long as you provide the compatLayer to set icons, button styles etc
just extend the CompatLayerInterface and you should be good to go
let me know if you find any issue


Feature/linesep slim

Contributor checklist

[ ] Provided the tests for the changes.
[ ] Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

[ ] Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
[ ] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

I'm a -1 on this because I'm only impacted by pip-compile producing incorrect line separators when it's run misconfigured. Eg the user forgot to run my shim wrapper or apply pre-commit

I'm a -1 on this because I'm only impacted by pip-compile producing incorrect line separators when it's run misconfigured. Eg the user forgot to run my shim wrapper that emits normal newlines or apply pre-commit

This doesn't address that problem?

Ah right, I see it, the code still defaults to adopt the existing linesep if possible

@ssbarnea I understand you don't really want this in any form, but if it does happen in this (single flag) form, would you like to suggest a better flag name?

I think that this change was obsoleted by #1652 so closing. If not, please rebase and reopen.


No support for Scheduling jobs at exact time

I want to schedule job at a particular time, instead of giving the execution window.
evernote's android-job library provides this feature.
sample code to trigger exact jobs in evernote android-job library
int jobId = new JobRequest.Builder(DemoSyncJob.TAG)             .setExact(20_000L)             .build()             .schedule();
Can you please add the same feature in firebaseJobDispatcher also ?

yes its not triggering jobs at exact time

That's your whole answer, not it will be fixed on a certain date, but yes it's happening, lol, I don't think I'll be using this job dispatcher, job scheduler didn't work either, it drained the battery immensely and it included a bunch of stuff I never need but this is a mockery. Can you please hire some experts to get this thing done right?

When can we expect all these issues to be fixed? I'd very much like to use your library but I can't due to all the unresolved issues.

You should be using WorkManager API.
WorkManagerApi is an replacement for FirebaseJobDispatcher API.  I think
FirebaseJobDispatcher is deprecated
On Thu, May 2, 2019 at 11:35 AM emailsubjekt<EMAIL_ADDRESS>wrote:

When can we expect all these issues to be fixed? I'd very much like to use
your library but I can't due to all the unresolved issues.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-jobdispatcher-android/issues/265#issuecomment-488561818,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD6AXULHA5W7ZNIHKM2TQSDPTKABFANCNFSM4FREBOEQ
.

closing as this will not be added to FJD given the deprecation.


multiple lines added to a stack bar chart also stack

Bug report
When adding multiple lines to an existing stack bar chart, the lines are also stacked rather than being expressed independently. That is, where line series 1 has a value of 10 and line series 2 has a value of 5 series 2 will be plotted at 15, not 5.
A secondary issue for lines is where there is not a value for a data point the line chart is unable to connect to the next data point requiring the addition of an intermediary data point (which is incorrect for the purpose of the chart). It would be preferable to be able to in/exclude connections where null values exist (refer dashed line in CodePen).
I suspect the ability to specify the type and subtype (i.e. stacked, continuous line, etc) at the series level is the answer.

I'm trying to add non stacked lines to a stacked bar chart. A single line is fine, however the addition of a second line stacks rather than being drawn

What is happening instead?
The line series of the chart are also being stacked (note that the chart is globally designated as being stacked) and the line series cannot be made to have a continuous line where there is a null value.

What error message are you getting?
No error message as it works as designed. This can be worked around by calculating the line series values to achieve the placement, however the tooltips will be incorrect.

This issue is still present. #907


Very good interactive effect, can I use Android to achieve it?

Very good interactive effect, can I use Android to achieve it?

Thanks for interest in our work. We are not implementing components for android and not planning to do that in nearest future.
P.S. Of course you can port this effect by yourself


internalloglevel parsed to late (XML config)

When reading the XML config, we set internalloglevel to late.
if we set <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"          internalLogLevel="Off" >
then we still logging to file, until we parse 'internalLogLevel'

solution: move 'internalLogLevel' to the top

fixed by https://github.com/NLog/NLog/commit/04944f6637f5979627113bc6f1eed23de00784bc

Fixed and confirmed by appveyor


CallBack if Text-to-Speech finished reading

Is there any callBack method which will inform us regarding the Text-to-speech has finished reading? or it is canceled?

I would recommend using Xamarin.Essentials: https://docs.microsoft.com/en-us/xamarin/essentials/text-to-speech
When you "await" or "ContinueWith" then that is when it is done. There is also a cancellation token approach to cancel it easily.


Update to support gulp4

I wanted to use this package in my gulp pipeline, unfortunately it doesn't appear to work with gulp 4.
Steps to reproduce:
download this repository, in package.json change the gulp dependency to the following:
"gulp": "gulpjs/gulp#v4.0.0"
run ./node_modules/.bin/gulp
and get the following error:
AssertionError [ERR_ASSERTION]: Task function must be specified
    at Gulp.set [as _setTask] (/Users/keneucker/Downloads/gulp-jsdoc3-master/node_modules/undertaker/lib/set-task.js:10:3)
    at Gulp.task (/Users/keneucker/Downloads/gulp-jsdoc3-master/node_modules/undertaker/lib/task.js:13:8)
    at Object.<anonymous> (/Users/keneucker/Downloads/gulp-jsdoc3-master/gulpfile.js:63:6)

Thanks for your bug report Ken. This has not been tested with gulp4. Would you be open to making a merge request for support?

@mlucool sure sure. I have not yet upgraded a package from gulp3 to gulp4 yet but I will take a shot at it.

@mlucool hmm. It suppose I might be wrong about the package not working with gulp4. I updated the gulpfile with the following flag and method:
const runningGulp4 = gulp.series ? true : false;

...

const addGulpTask = function (taskName, task, dependencies = []) {
	if (runningGulp4) {
		gulp.task(taskName, gulp.series(...dependencies, task));
	} else {
		gulp.task(taskName, task);
	}
};

...

if (runningGulp4) {
	gulp.task('default', gulp.series('copy', 'build', 'doc'));
} else {
	addGulpTask('default', function (cb) {

		let runSequence = require('run-sequence');
		runSequence('copy', 'build', 'doc', cb);
	});
}

This allows the code in this repository to run using either gulp3 or gulp4 depending on whether or not gulp.series exists ( a run-sequence alternative method built into gulp4 ). I was able to test that this continues to function with both versions now. However, I am still running into the same issue when using this package in my gulp pipeline:
config.opts.readme = 'README.md';
config.source.include = ['./scripts/**/*.js'];

return gulp.src([config.opts.readme, config.source.include], { read: false })
	.pipe(jsdoc(config));

So the issue may not be gulp4 related like I had originally thought, unfortunately. Let me know if you'd still like a pull request with the modifications to the gulpfile making it work with gulp3 and gulp4. If I am able to determine what is causing the issue and it pertains to this package I will report back to this issue.

I've continued to dig around and have a little more information, but am not closer to a working solution.
I believe what is happening is that the gulp.src call ends before the jsdoc task succeeds, so my pipeline may be ending and thus the jsdoc task cannot complete. I haven't been able to completely confirm this suspicion, but I do think that this may be a root cause of my problem.
I can use the same configuration and run jsdoc from the command line and it works fine.

I haven't been able to fully determine why I can't get jsdoc to work with my project, but I also don't like that gulp-jsdoc uses child exec to run jsdoc and would prefer that gulp packages in my application use code within the same process. I've now discovered that there is a programmable API for jsdoc:
https://github.com/jsdoc2md/jsdoc-api
I am going to switch to the jsdoc-api as an alternative. Cheers,


add AppCfg.Net, a configuration framework for .NET developers

Tools/AppCfg.Net - AppCfg.Net
Add AppCfg.Net - A mini but powerful configuration framework for .NET developers
Support:

AppSetting datasource
MSSQL Database datasource
It also support multi-tenancy.
Besides, AppCfg.Net also support immutable setting. This help us avoid changing setting value at runtime

Sorry, @minhhungit,
This entry isn't going to make the list for the following reason(s):

Too new

Too small

No of response from the community suggested the previous statements were false

Don't let this setback cause you to lose heart, and we look forward to your next contribution.
Thanks, Pleb


Regexp fix - match until first semicolon

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/14144/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14144/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14144/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/14144/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/14144/merge
https://gui.babylonjs.com/?snapshot=refs/pull/14144/merge
https://nme.babylonjs.com/?snapshot=refs/pull/14144/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/14144/merge#BCU1XR#0

closing for a sec.

Visualization tests for webgl1 have failed. If some tests failed because the snapshots do not match, the report can be found at
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14144/merge/testResults/webgl1/index.html
If tests were successful afterwards, this report might not be available anymore.

Visualization tests for webgl2 have failed. If some tests failed because the snapshots do not match, the report can be found at
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14144/merge/testResults/webgl2/index.html
If tests were successful afterwards, this report might not be available anymore.


Bump cosmos-sdk and tendermint package version

Bump Cosmos-SDK to v0.46.0 and tendermint to v0.34.20


Re-order and add 18.04 Ubuntu guide

After creating your pull request, tick these boxes if they are applicable to you.

[ ] I have tested my changes against the review branch (the latest developmental version), and this pull request is targeting that branch as a base
[ ] I have tested my changes on Python 3.5/3.6

Description
Re-orders the Ubuntu versions from 18.04 to 14.04 and adds an 18.04 guide.

I'd usually merge this, but I'm just wondering... maybe there's a way we can make it so that we don't have to make a guide for every Ubuntu version? Or at least, a better way of having them on a page rather than having the instructions all crammed all over the place in ubuntu.md. Any ideas?

I mentioned in the VIP channel on the help server that i wanted to use dropdowns instead to reduce the clutter, but codeblocks won't work in them on the site @ https://aleanaa.github.io/MusicBot/installing/ubuntu/

@jaydenkieran Out of curiosity, is the 14.04 guide still needed? 14.04 is End of Life early next year, and I feel like just having guides for the latest two LTS releases in ubuntu.md would be fine.

My two cents is no, it's not. However, as long as the bot works on 14.04 we should mark it as unsupported in the guides instead for those who may have legacy systems

Hmm... So possibly a Legacy tab in the guides list? This would work for things such as CentOS as well for whenever CentOS 6 is EOL, and 8 is released.

+1 for marking 14.04 guide as unsupported/legacy

This won't work:
ppa:mc3man/xerus-media
Cannot add PPA: ''This PPA does not support bionic''.
I just used debian guide to run the thing. Btw I'm running Linux Mint 19 (based on Ubuntu 18.04)


[UI] Consolidate similar items in transaction details dialog

Fixes #11419
The diff is big because of white space changes so for easy review please hide whitespace changes: https://github.com/WalletWasabi/WalletWasabi/pull/13379/files?w=1
This PR makes the transaction details dialog less crowded by removing the block hash item, and consolidating the status and block height items like this:

Status
Confirmed at block height 789798 (4825 confirmations)

Note that the copy button copies the block height when the transaction is confirmed, and copies 0 when it is pending.

cc @Kruwed

Sorry, this PR is too cluttered. We can work together on a redesign if you want

I don't see this PR really making the UI more cluttered than it is already.
It actually declutters the UI by removing the block hash which is not necessary at all.
Maybe it can be improved further by changing this:
Confirmed at block height 789798 (4825 confirmations) to
Confirmed at block 789798 (4825 confirmations)
Redesigning would take more effort than necessary, unless we want to spend more time on redoing the whole transaction details dialog which is not a priority now.

Sorry, this PR makes the UI is too cluttered. We can work together on a redesign if you want

At this point I'm in favor of just completely eliminating the block hash and block height lines and not replacing that information anywhere else. No one needs it.


Optimize the embedded SVG's attributes order.

On hold until we have the SVG escape function and do this properly.
I'd like to do the same for v4-dev later.

BTW that dropdown checkmark SVG is currently unused. I will fix it in one of the other PRs that tackle the docs navbar issues.


Storybook 8 compatibility

Hi @geometricpanda,
I have updated dependencies to support Storybook 8 (see issue #20).
Also, all deps were updated to the latest versions.

Ooh awesome. I'll review this later today
I've been talking with Storyblok about some changes to better work with Storyblok 8, but this also sounds great.

Hello @geometricpanda, any update on this?
Thanks for this useful addon, and thanks @evg4b for the contribution!

Hey, I've just merged

Hi @geometricpanda Thanks for merging!
Seems like it was an error on the package creating and the npm package wasn't release

I saw, it's on my todo list for today

Any updates on that version? 👁

Awesome thanks,

Odd, I am not sure why that didn't publish. I tested this in my fork and it worked as-is, all I did was add an NPM_TOKEN to my action secrets.

Not sure why that didn't publish. Tried to debug it more in my fork but it works every time I push to the main branch.
Possible issue with the NPM_TOKEN perhaps? Or maybe you need to re-run the workflow so it's not executed from a user besides yourself?


annotations files not complete?

Hi, I want to evalute your pretrained model. I download "minival annotation" file and "Person detection results in COCO Minival" file from your link, but it seems that some images are missing. Here are my test codes:
val = json.load(open('./MSCOCO/annotations/person_keypoints_minival2014.json', 'r'))
train = json.load(open('./MSCOCO/annotations/person_keypoints_trainvalminusminival2014.json', 'r'))
det = json.load(open('./dets/person_detection_minival411_human553.json', 'r'))

det_image_ids = set([i['image_id'] for i in det])
val_image_ids = set([i['id'] for i in val['images']])
val_annot_ids = set([i['id'] for i in val['annotations']])
val_annot_img_ids = set([i['image_id'] for i in val['annotations']])

print(len(val_image_ids & val_annot_img_ids))
print(len(det_image_ids & val_annot_img_ids))

output is
2693
2692

it seems that many annotatated images(ground truth) do not exist in your detection result file and your minival. What is the reason? Thanks.

There is no person in the rest of images.

thx

Softnms has been applied in the detection result.

I see, so, we only need to filter low score person and run pretrained CPN on those filtered images?

It’s OK. You should use nms to filter the detection boxes anyway. The code is without nms by default.

thx


CDI-499 Async events

First draft for Async events proposal

This proposal lacks certain parts:

invocation context definition for async delivery
thread-safety guarantees for events and observers
does not deal with possibly multiple exceptions being thrown in async event delivery

Yes @jharting, aspect are missing. That's why it's a draft. Now the true challenge is to bring proposal for these lacking aspects ;).
Regarding Exception, CompletionStage provides handle and exceptionally methods. That's why I wrote:

Exception can be handled with standard CompletionStage methods.

I could have mentioned handle and exceptionally in my text. But beyond that I don't think useful to reinvent exception handling in async operation unless we don't use JDK 8 API...

@antoinesd yes, not doubts about that. My point was that the this proposal, unless I misinterpret it, allows multiple observers resolved for a particular event to be notified of this event in parallel threads. In such case it may happen that these parallel executions yield more than one exception. The proposal however only talks about a single exception as if the observers were invoked sequentially. It IMHO misses the case of more than one exception.

Ok I get it @jharting. Using handle will only treat the first exception happening in the pipeline. We should have an handle() after each thenApply(). I see 2 solutions to deal with that:

add a signature for fireAsync() allowing to pass a consumer method provided by user. This method will be used internally to handle() each observer execution. Something like thenApply().handle().thenApply()... (or exceptionally) internally

provide a hook (via extension?) to event bus allowing addition of these handle methods. Seems a lot more complex and fuzzy than 1...

How can an extension-provided observer method identify itself as sync/async?

@jharting, thanks for the precise feedback. I'm adding a isAsync method to ObserverMethod. I probably have other points to add to spi chapter.

Hello guys,
This feature is going to be released only in CDI 2.0?

Hi Nykolas,
Yes, for 2 reasons:

In Java EE new features are never back ported in earlier version
this feature rely on Java 8 and other CDI version are but on Java 6 and 7.

Why this question ?
Antoine

Le 21 juil. 2015 à 18:16, Nykolas Laurentino de Lima<EMAIL_ADDRESS>a écrit :
Hello guys,
This feature is going to be released only in CDI 2.0?
—
Reply to this email directly or view it on GitHub https://github.com/cdi-spec/cdi/pull/250#issuecomment-123389689.

I'm developing a new feature in my system and async events would help a lot. There is a expected release date for it?


dynamically change public path in vue js

Version
2.6.7
Steps to reproduce
when you want create dynamicaly public path
What is expected?
dynamic  set for base url
What is actually happening?
static base url

i want put my vue js project in ipfs . and because of that i have to change my baseuri or public path to be :
/ipfs/[hash string which i get after file added to ipfs]

but i cant do that
means i want to set public path be dynamically depends on real url
somethink like this :
 module.exports = {
publicPath: process.env.NODE_ENV === 'production' ?
    '/ipfs/[hash string which i get after file added to ipfs]/' : '/'
}

whats your idea to solve this problem?

I believe it's not related to Vue. You'd better consult webpack for a solution for this.


Support for CancellationToken

Hi Erik,
Thanks for this nice and handy utility!
I have a feature request... I would like the CancellationToken that is passed into the StartAsync and StopAsync methods of the IHostedService to have its IsCancellationRequested property set to true when the service is stopped, so that I can cancel long running jobs and wait for them to finish.
I am more than happy to submit a PR if you like.

I'm glad you like it. I think the purpose of the CancellationTokens is to cancel the start/stop processes - not the longrunning service. Have a look here
https://docs.microsoft.com/sv-se/dotnet/api/microsoft.extensions.hosting.ihostedservice.startasync?view=aspnetcore-2.2#Microsoft_Extensions_Hosting_IHostedService_StartAsync_System_Threading_CancellationToken_
and here
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-2.2


TROPO-11219-record-transcription

C# webapi library transcription url property should NOT be "uri"

Change Typo uri to url.


setup cloud front for caching

https://www.serverless.com/framework/docs/providers/aws/events/cloudfront

endpoints:
GET - https://s74wgr2orc.execute-api.ap-northeast-2.amazonaws.com/
GET - https://s74wgr2orc.execute-api.ap-northeast-2.amazonaws.com/asosmin/{datetime}
functions:
hello: wl-backend-functions-dev-hello (1.6 MB)
asosmin: wl-backend-functions-dev-asosmin (1.6 MB)

error
resources:
Resources:
CloudFrontDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Comment: WL Backend Functions CloudFront Distribution
Origins:
- Id: WLBackendFunctionsOrigin
DomainName:
Fn::Join:
- ''
- - Ref: HttpApi
- '.execute-api.'
- '${self:provider.region}'
- '.amazonaws.com'
OriginPath: /
CustomOriginConfig:
OriginProtocolPolicy: https-only
Enabled: true
DefaultCacheBehavior:
TargetOriginId: WLBackendFunctionsOrigin
AllowedMethods:
- GET
- HEAD
ViewerProtocolPolicy: 'redirect-to-https'
DefaultTTL: 30
ForwardedValues:
QueryString: false
Compress: 'true'

fixed
resources:
Resources:
CloudFrontDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Comment: WL Backend Functions CloudFront Distribution
Origins:
- Id: WLBackendFunctionsOrigin
DomainName:
Fn::Join:
- ''
- - Ref: HttpApi
- '.execute-api.'
- '${self:provider.region}'
- '.amazonaws.com'
OriginPath: '/${self:provider.stage}'
CustomOriginConfig:
OriginProtocolPolicy: https-only
Enabled: true
DefaultCacheBehavior:
TargetOriginId: WLBackendFunctionsOrigin
AllowedMethods:
- GET
- HEAD
ViewerProtocolPolicy: 'redirect-to-https'
DefaultTTL: 30
ForwardedValues:
QueryString: false
Compress: 'true'

Unable to connect cloud front and api gateway

Try to make rules  manually, and update rules after checking the operation.

It needs to time for deploying


Mouse Stutter when Dragging if mouse mode is MOUSE_MODE_CONFINED

Godot version
4.1.1 stable
System information
Godot v4.1.1.stable - macOS 13.0.1 - Vulkan (Compatibility) - Intel(R) Iris(TM) Plus Graphics OpenGL Engine - Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz (8 Threads)
Issue description
Setting the Input.mouse_mode to Input.MOUSE_MODE_CONFINED will, holding down the Left Mouse Button and dragging, make the mouse stutter.
https://youtu.be/8jQ8h0L1JU0
Steps to reproduce
Make a new Scene
Add a Script to that Scene
In that Script, in _ready() set the Input.mouse_mode to Input.MOUSE_MODE_CONFINED
Play the Scene
Hold down Left Click
Move the Mouse around
Minimal reproduction project
N/A (See above, very trivial)

Are you using a built-in trackpad or external mouse? Trackpads may have palm click prevention which can impede playing games.
I'd recommend checking whether this occurs with an external mouse if you're using a trackpad.

@Calinou  Trackpad, I sadly don’t have any Bluetooth mouses

NVM, borrowed a friends, I can now verify that it does not work on an Apple Magic Mouse either

I'm also experiencing this issue in 4.2.1 stable in MacOS 14.5 with the trackpad.
Confirmed it works fine with a regular mouse.

This is not a case for me in 4.3
Specs:
Godot Engine v4.3.stable.official.77dcf97d8 - https://godotengine.org
Vulkan 1.3.274 - Forward+ - Using Device #0: Intel - Intel(R) HD Graphics 620 (KBL GT2)

I have other issues, but it does not stutter when holding left mouse button and dragging whilie mode is MOUSE_MODE_CONFINED.
I have a linux laptop with trackpad, but tried with regular mouse as well

Cannot reproduce on my MacBook Pro on macOS Sequoia 15.0.1
Godot v4.4.dev (17fca1a62) - macOS 15.0.1 - Multi-window, 1 monitor - Metal (Forward+) - integrated Apple M3 Max (Apple9) - Apple M3 Max (16 threads)


Mash#to_hash: seems it needs to return symbol keys

#to_hash is Ruby's implicit conversion operator.
Here's imporant case:
def test(**options)
  p options
end

h = {one: 1, two: 2}
test(h)
# prints: {:one=>1, :two=>2}
test(**h)
# prints: {:one=>1, :two=>2}

h = Hashie::Mash.new(one: 1, two: 2)
test(h)
# ArgumentError: wrong number of arguments (1 for 0)

test(**h)
# TypeError: wrong argument type String (expected Symbol)

This is almost the ONLY reasonable case of #to_hash usage in entire Ruby :(
Hashie::Mash is very convenient to construct options hash—but then, you have no means to pass it to methods waiting for this hash.

This is definitely something we should fix.

Ok, I'll do it on weekend.
What about #to_h?

option 1: preserve implementation (#to_h is not defined explicitly, and returns what #to_hash returns);
option 2: preserve behavior (#to_h continues to return string keys).

IMO, option 2 is more reasonable, though I can justify any of them...
WDYT?

Lets find out first whether specs break with option 1? If nothing breaks that means nobody should rely on it and we can change the behavior.

Accepted.

Please look at: https://github.com/zverok/hashie/commit/c4eb68d6b16f61af04dd0e02df2249382d411104
Most reasonable solution turned out to change internal Mash keys storage from strings to symbols entirely.
There's two questions left (and that's why I'm not proposing a PR):

this test: https://github.com/zverok/hashie/commit/c4eb68d6b16f61af04dd0e02df2249382d411104#diff-a351d9f0497eba6d279202565db07edfR534 -- I'm not quite sure what it expected to demonstrate, and therefore can't fix it (because don't understand what fix is reasonable);
I think I should add some simple test to demonstrate/check behavior from initial ticket text (implicit #to_hash call with method call on ** args deconstruction), WDYT?

(Also, it seems method_missing/respond_to_missing? fixes were unnecessary, I just stumbled upon the problem from https://github.com/intridea/hashie/pull/285 somehow, with isolated test of spec/hashie/mash_spec.rb:354—you can try it yourself, even for current master branch works on Ruby 1.9.3 but breaks on Ruby 2.2.0 if called like rspec spec/hashie/mash_spec.rb:354)

Added some implicit splat tests: https://github.com/zverok/hashie/commit/4bc56e18bcef4b58a70ce579c4030c5cefb17bd1
Still waiting an answer about question 1 above.

I think you should PR it and see what others say.
The biggest issue I see with symbols is that they aren't garbage collected until Ruby 2.2, so this would be a change that potentially very significantly affects people using Mash.

Ok than, here we go, then: https://github.com/intridea/hashie/pull/342
I haven't think about symbols garbage collection, yup :(
Though, as far as I can see from the code, there would be hard to implement another approach (keys stored as strings but returned as hashes).

Closing in favor of https://github.com/intridea/hashie/pull/412, a Hashie extension that performs this.


Social media share not disappearing on mobile

The social media share option isn't disappearing on mobile, even though the media query specifies #share as {display: none;}.

Fixed as of 1f50039161bfd48a9d9974be6d3dfb9b7e79c35b


Issue when parsing lident

it looks in some sitatations when parsers try to parse an identifier ignores some illegal tokens.
examples:
let x as 'y = ()

(~???x) => x

Thanks for the report.
It seems that we don't report errors and just skip tokens. Will look into this.

I submitted a fix i'm not sure if it's correct fix feel free to close or guide toward correct fix

Sorry for the delay, merged your PR, solid work!
Fixed in https://github.com/rescript-lang/syntax/pull/448


Use go1.12 and go modules

Remove Gopkg.toml and Gopkg.lock
Add go.mod and go.sum
Update Dockerfile to use go1.12
Update Travis to use go modules

This is done mainly to resolve vulnerabilities that affects Janus which are fixed on go 1.12.8

+1

+1


adust watcher mem for increased prod-rh01 load

related to the recent remote-resolver and re-enablement of OSP pruning
rh-pre-commit.version: 2.3.0
rh-pre-commit.check-secrets: ENABLED

managed to get to it @enarha


Add support for calculating average of arbitrary number of angles

I came across a need for this function and thought it might have a nice home in your package. Cheers!

Nice! Thanks for the contribution :)

Glad you like! I just noticed your comment about providing tests and such. I just did the implementation in the main angles.js file so tests are lacking. I also did not include a minified version.

If you could add some tests, it would be nice. I will minify the file with the next release.

BTW, I've seen your MLX90363 repo. Is this sensor worthwhile? According to the DSP sketch, it only calculates the angles for you. Are there any other benefits of using that sensor?

I'll try to write some tests tonight.
What do you think the result should be when someone asks for the average of the angles [0, Math.PI]? NaN? Something else?
I like the sensor. The SPI interface is a little weird, which is why I wrote my library for AVRs. I'm not sure what you mean by "DSP sketch". The sensor reports either a single angle, two angles, or all 3 component axes at up to ~1kHz. Melexis has other sensors that are faster. Competitors make very similar sensors as well. If you'd like to discuss this more, we should move this discussion to that project. ;)

I tend to return null in such cases - NaN is also ok. But beware, JavaScript does some magic: Math.atan2(0,0) == 0 for whatever reason and Math.atan2(Math.sin(0)+Math.sin(Math.PI), Math.cos(0)+Math.cos(Math.PI)) == Math.PI for whatever reason, so you have to explicitly catch that case.
Sorry that was a bit vague. With DSP sketch I meant the diagram of the signal processor on page 52. Okay, I come over ;)

I'll defer to your standard. As long as it is documented, should be good!
Math.atan2(0,0) should be NaN or null imho but whatever, that's the implementation they went with.
Look like Math.atan2(Math.sin(0)+Math.sin(Math.PI), Math.cos(0)+Math.cos(Math.PI)) == Math.PI is true because Math.cos(0) == 1, Math.cos(Math.PI) == -1, and Math.sin(0) == 0 but Math.sin(Math.PI) != 0 for some reason. It's apparently less than Number.EPSILON but greater than 0! Ha!
> Math.sin(Math.PI)
1.2246467991473532e-16
> Number.EPSILON
2.220446049250313e-16
> Math.sin(Math.PI) < Number.EPSILON
true

Note the fix I'm suggesting would take care of this degenerate case.
My apologies for not getting back to you sooner. I've been swamped with work recently and need to focus on that until next weekend. Wheee!


HBASE-26462 Should persist restoreAcl flag in the procedure state for CloneSnapshotProcedure and RestoreSnapshotProcedure

https://issues.apache.org/jira/browse/HBASE-26462

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 26s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  3s
master passed

+1 :green_heart:
compile
4m 42s
master passed

+1 :green_heart:
checkstyle
1m 16s
master passed

+1 :green_heart:
spotbugs
6m  8s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 49s
the patch passed

+1 :green_heart:
compile
4m 41s
the patch passed

+1 :green_heart:
cc
4m 41s
the patch passed

+1 :green_heart:
javac
4m 41s
the patch passed

+1 :green_heart:
checkstyle
1m 15s
the patch passed

-0 :warning:
whitespace
0m  0s
The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
hadoopcheck
19m 31s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
hbaseprotoc
1m 43s
the patch passed

+1 :green_heart:
spotbugs
6m 23s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 29s
The patch does not generate ASF License warnings.

63m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3921

Optional Tests
dupname asflicense cc hbaseprotoc prototool javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 1bc50771ac77 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / dcd622d702

Default Java
AdoptOpenJDK-1.8.0_282-b08

whitespace
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/artifact/yetus-general-check/output/whitespace-eol.txt

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
3m 55s
Docker mode activated.

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 40s
master passed

+1 :green_heart:
compile
2m 13s
master passed

+1 :green_heart:
shadedjars
8m 24s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 28s
the patch passed

+1 :green_heart:
compile
2m 12s
the patch passed

+1 :green_heart:
javac
2m 12s
the patch passed

+1 :green_heart:
shadedjars
8m 15s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 56s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 59s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
141m  9s
hbase-server in the patch passed.

181m  2s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3921

Optional Tests
unit javac javadoc shadedjars compile

uname
Linux 12485cab12ec 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / dcd622d702

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/testReport/

Max. process+thread count
4634 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
6m 52s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 29s
master passed

+1 :green_heart:
compile
1m 54s
master passed

+1 :green_heart:
shadedjars
9m  5s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 51s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 38s
the patch passed

+1 :green_heart:
compile
2m 17s
the patch passed

+1 :green_heart:
javac
2m 17s
the patch passed

+1 :green_heart:
shadedjars
10m  9s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 55s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 51s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
228m 36s
hbase-server in the patch passed.

273m 22s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3921

Optional Tests
unit javac javadoc shadedjars compile

uname
Linux e1db9722097f 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / dcd622d702

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/testReport/

Max. process+thread count
2787 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 26s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  1s
master passed

+1 :green_heart:
compile
4m 46s
master passed

+1 :green_heart:
checkstyle
1m 16s
master passed

+1 :green_heart:
spotbugs
6m  2s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 48s
the patch passed

+1 :green_heart:
compile
4m 37s
the patch passed

+1 :green_heart:
cc
4m 37s
the patch passed

+1 :green_heart:
javac
4m 37s
the patch passed

+1 :green_heart:
checkstyle
1m 13s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
19m 18s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
hbaseprotoc
1m 41s
the patch passed

+1 :green_heart:
spotbugs
6m 32s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 28s
The patch does not generate ASF License warnings.

63m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3921

Optional Tests
dupname asflicense cc hbaseprotoc prototool javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 9367fec04bb2 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / dcd622d702

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 32s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 11s
master passed

+1 :green_heart:
compile
1m 55s
master passed

+1 :green_heart:
shadedjars
8m 43s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 52s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  0s
the patch passed

+1 :green_heart:
compile
1m 46s
the patch passed

+1 :green_heart:
javac
1m 46s
the patch passed

+1 :green_heart:
shadedjars
8m 33s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 52s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 49s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
148m 12s
hbase-server in the patch passed.

183m 18s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3921

Optional Tests
unit javac javadoc shadedjars compile

uname
Linux 7751904e3a27 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / dcd622d702

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/testReport/

Max. process+thread count
4488 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 17s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 14s
master passed

+1 :green_heart:
compile
2m 22s
master passed

+1 :green_heart:
shadedjars
9m  9s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m  4s
the patch passed

+1 :green_heart:
compile
2m 22s
the patch passed

+1 :green_heart:
javac
2m 22s
the patch passed

+1 :green_heart:
shadedjars
9m 19s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 56s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m  5s
hbase-protocol-shaded in the patch passed.

-1 :x:
unit
206m 50s
hbase-server in the patch failed.

247m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3921

Optional Tests
unit javac javadoc shadedjars compile

uname
Linux d4b7d2cce171 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / dcd622d702

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/testReport/

Max. process+thread count
3299 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3921/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Hi, @Apache9  , the UT TestProcedureAdmin#testGetProcedure failed. This UT does not seem to have anything to do with my modification, and in my HBase compile environment, it can be executed successfully. Is this an unstable UT?


didnt ban if some one "show champion"

didnt ban if some one wanna play on that champion.

I assume it did and you want it to not? "Don't*?"

my ban is "yasuo" and every 6 games my teammate wanna play on yas

I assume it did and you want it to not? "Don't*?"

ah i got u, ye i mean dont


Use new Sokol logging mechanism

Sokol has a new style for logging stuff, would be nice if Sokol GP follows it.

Does it currently route to the bound logger in the sg_desc? I'm binding the logging there to an external function so want to make sure I'm getting gp errors.

Does it currently route to the bound logger in the sg_desc? I'm binding the logging there to an external function so want to make sure I'm getting gp errors.

No, currently it follows the following logic:
#ifndef SOKOL_LOG
    #ifdef SOKOL_DEBUG
        #include <stdio.h>
        #define SOKOL_LOG(s) { SOKOL_ASSERT(s); puts(s); }
    #else
        #define SOKOL_LOG(s)
    #endif
#endif

But you can define SOKOL_LOG to override this behavior.


Veraison verification plugin for Parsec (TPM) evidence

Add a verification plugin to Veraison to handle Parsec (TPM) evidence.

The work associated to this activity was completed via Pull Request:
https://github.com/veraison/services/pull/140


WIP: Improving status propagation code in pipelines

We don't seem to allow for the pipeline to have a null status, which the API tells us is possible when calling getResult().
I've patched this logic gap and added some better logging to aid future debugging.

Issue here: https://github.com/adoptium/ci-jenkins-pipelines/issues/750
Test run here: https://ci.adoptium.net/job/build-scripts/job/openjdk11-pipeline/2438/

The pipeline above didn't work because it was using the wrong branch, as the ci-jenkins-pipeline branch that the pipeline itself uses is hard-coded in the job config. I temporarily overrode the pipelines branch in the job config and launched this: https://ci.adoptium.net/job/build-scripts/job/openjdk11-pipeline/2440/
The end state of both builds in the pipeline was "unstable", and the pipeline status reflects this. Removing the WIP state of this PR, and we can worry about merging it after the release.

/thaw


Error PlayerDeathEvent

Sorry for my english i'm french
Hello,
Here is my problem every time one of my players dies there is this big mistake that happens in my logs
https://pastebin.com/HRHBqd6V
Thx !

CE has not yet been updated to 1.13 and world guards 7.0


not working after update <IP_ADDRESS>

Olivier, thank you for your code, made my work and my teaching a lot easier over zoom :-)
A couple of days ago I updated my remarkable2 (firmware <IP_ADDRESS>) and ... panic ! goMarkableStream is not working...
on the client I get the following
./goMarkableClient
listening on :8080, registered /video
Error when calling GetImage: rpc error: code = Unknown desc = read /proc/218/mem: input/output error
On the remarkable I tried this
reMarkable: ~/ pid=pidof xochitl
reMarkable: ~/ addr=dd if=/proc/$pid/mem bs=1 count=4 skip=4387048  2>/dev/null | hexdump | awk '{print $3$2}'
reMarkable: ~/ skipbytes=printf "%d" $((16#$addr))
reMarkable: ~/ dd if=/proc/$pid/mem bs=1 count=2628288 skip=$skipbytes > out.data
--> dd: /proc/218/mem: Input/output error
and I get the message above...
there are more remarkable2's in the family, all with the previous system -I told them to reject this update- and they all work fine with the same goMarkableStream installation. Is anyone having the same issue ?
Thank you very much
Joao Costeira

Hi!
Thank you for reaching out.
I just uploaded a new version that should work with FW 2.6
Tell me if it works for you.
Olivier

Dear Olivier,
What can I say ? Thank you very, very much...me and my students are very
grateful :-)
best regards
Joao
On Fri, Mar 26, 2021 at 5:30 PM Olivier Wulveryck @.***>
wrote:

Hi!
Thank you for reaching out.
I just uploaded a new version that should work with FW 2.6
Tell me if it works for you.
Olivier
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/owulveryck/goMarkableStream/issues/9#issuecomment-808396779,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALLDVRUMECORG7TDFKTXFSTTFTADZANCNFSM4Z3ZLNSA
.

I am using v0.2.1 on ubuntu 20.10 and i see the same error. the server log shows "New connection from:  <IP_ADDRESS>:58688"


Be able to tell which object wrapped which object in Move execution

Today when you wrap an object to another (by embedding it as a field), we know that the object is being wrapped, but we don't know which object it's being wrapped into. This creates all sorts of problems, like there is no way to authenticate objects owned by the wrapped object in future transactions.
We could, inspect the content of each output object from every transaction (like reflection), and look for the wrapped object (based on type and ID). And then we can get the information we needed.

Is this still an issue?

We probably never need this? I am not sure.


Redesign, again

Compared to #1 this one does a bit less but it also does a bit more. I'll just describe all that's changed.

First of all the way the glyphs database is structured has changed. I'm aware of the fact that when you previously asked about a possible JSON endpoint for Uiua's functions no one answered. I joined the server recently and asked a similar question, and Kaikalii responded by creating a Rust program that does exactly what you're looking for. I forked it and added more stuff -- namely, including class information in the glyph data as well as creating an automated batch script that does the job for you of generating the JSON array, converting it to a JavaScript file, and copying it into a directory of your choosing. You'll probably want to run this whenever Uiua updates.
This noticeably allows you to 1. get the glyphs even if the website introduces a breaking change that makes the current method of scanning Uiuapad obsolete, and 2. get any given glyph's description or any other value if you know how to get to it in Rust. So, hovering over a glyph now shows its one-line description of what it does.
Also I changed the event listeners for the buttons again. I'm not sure why they're implemented in the way that they are and I think what additional overhead and unnecessary complication it introduces, regardless of how small it is, should be changed to make it... better, maybe. It's entirely up to you whether you want to keep these changes to the event listeners if there's a specific reason they're used in the way that they're currently used.
Also, glyph colors are no longer hardcoded. They're determined by their classes instead, like in Uiuapad. If the suggestion at #2 tickles your fancy then changing code-font to use Uiua386 might be worth doing, but right now it still uses the default font for the keypad. Additionally glyph buttons have transparent backgrounds until hovered once again. This is just a preference thing, if you want it changed you can tell me.
That's pretty much it. If there's any changes you need made, let me know.

Hi @thekifake :)
This looks great. I will likely get a chance later this evening to merge.
However I think we need to take it a step further, I had a look at uiua-gen-functions-json and to me it looks like it it could be included in this repo then either

built into a web assembly and included directly in the webview (I'll have to check if wasm is supported by vscode... dont see why not) OR
copied into this repo and run as part of .vscode/tasks.json

The later option is probably a safer bet in terms of extension install size... my experience with wasm so far is that it generates crazy big files. I wonder if this opens up the ability to add other constants and built-in functions?

Also just noticed in your screenshot I cant see the cursor behaviour tickbox.. is it just hidden off the bottom?
I was thinking, maybe it can be replaced by listening to a modifier key.
Holding "Shift" then clicking could insert to the left of the cursor. What do you think?
There could be a little help icon somewhere that makes a popup to explain or something...
Maybe it is just the way my brain works but I always seem to end up writing uiua code form right to left and using left arrow a lot.

copied into this repo and run as part of the extention build process in .vscode/tasks.json

I'd rather do this than the former. The only issue is that this will probably waste a lot of time when making updates. The reason having it generated whenever updates to Uiua are made, rather than as the user runs the extension, works better is because having the list of glyphs when the user wants them is more performant and more consistent than generating the whole thing on demand which takes a lot more time than just fetching a JSON array that's already been created for you. What I'm saying is, this kind of data isn't something we need as the extension updates; rather, it's something we need as Uiua itself updates, which isn't something we can really check for and run a script from automatically (but if there's a will there's a way).

I wonder if this opens up the ability to add other constants and built-in functions?

This does allow us to include system functions in the keypad. I've just intentionally excluded them in the fork because they're not something that you need a special keyboard to type. You can add them to your code as long as your keyboard has Latin characters and an ampersand, which I think... everyone has by now. It's more so a matter of memorization of what those system functions are... it's worth considering if we want to give the user some sort of list or set of buttons for system functions so that they won't have to memorize it or constantly reference the Uiua documentation.
Or— we can embed the system functions into Intellisense, which would be killer, if it's within the scope of this extension. I don't think the official Uiua extension pulls up a list of system functions when you type in an ampersand so this might be worth implementing if it's worth the effort and, again, if it's within the scope of this extension... because I'm not sure if that idea entirely fits within the realm of this extension at the moment.

Also just noticed in your screenshot I cant see the cursor behaviour tickbox.. is it just hidden off the bottom?

Yes, the screenshot is cropped. It still shows up in the window.

Holding "Shift" then clicking could insert to the left of the cursor. What do you think?

This would probably work better. I also usually work on Uiua code from right to left so this seems like the better option rather than having a big checkbox.


News web template

The user can check the Breaking News provided by the News Hour. Staff’s Detail information is also provided on Website.
I'm a gssoc'22 participant.

/assign


Possible vfsStream and DOMDocument issue

I wanted to write a testcase for loading XSD-files with DOMDocument (for more info, see https://github.com/goetas/xsd-reader/pull/10). To cover that specific case I need a directory path with a space character. Using vfsStream I got an error: PHP Warning:  DOMDocument::load(): I/O warning : failed to load external entity "vfs://root/foo%20bar/schema.xsd"
When I use a directorypath in vfsStream without space, the Xsd is loaded without problems. I have not figured out what causes this issue, so it could be this is actually not an issue for vfsStream.
For reproducing, see this gist: https://gist.github.com/qrazi/7789c1b1331336019bf7

Tried to look into this. Found an old bug-report for DOMDocument. Found in IETF RFC 2396 that in an URI, a space-character should be escaped by using percentage-encoding.
Tried to understand whats going on in php-src\ext\dom\document.c, especially functions dom_document_parser and _dom_get_valid_file_path.
There seems to be some stuff going on specifically for file://-based XML, so perhaps this is indeed not vfsStream's problem?

Sorry for coming to this late, was away for some time.
Probably vfsStream must be able to handle encoded URLs properly, it might be that a stat call with an encoded URL returns that the URL doesn't exist, leading to this error message.


Change login behaviour using FBLoginMock

Is it possible to change the login behaviour to native when using a solution based on FBLoginMock? Currently the button will only open Facebook within the browser, even though Facebook is installed on the device.

Maybe I should rephrase the question: is it possible to change the behaviour when only using FBLoginManager and not FBLogin? Both for Android and iOS.

for android this feature is in a PR waiting to be merged
#105
you can test it there
IOS should follow as well.

just to note that this issue is similar to issue #103

this should now be possible with the inclusion of #130


I write "g_id", but when I generate, it changes to "gId", what happen?

#Json:
[{"id":"1","imgUrl":null,"g_id":"11"}]

#Generate:
……
private String gId;
……
/**
*
* @return
* The gId
*/
public String getGId() {
return gId;
}

/**
*
* @param gId
* The g_id
*/
public void setGId(String gId) {
this.gId = gId;
}

jsonschema2pojo recognises delimiters like spaces, hyphens and underscores. This means you can have json properties that look like this_is_my_property and these can be represented in java like thisIsMyProperty. The annotations in the code will ensure that the json produced from your types still produces the correct name.
If you don't want this to happen, try emptying out the propertyWordDelimiters value (or setting it to some other value like #).

OK, Thank you.


2/3 PG units stuck in waiting/idle state, not moving to active/idle

Steps to reproduce

a. I do not have a firm reproducer, but I ran into this issue upgrading from rev 429 to rev 468 in a charmed landscape deployment. I originally encountered the issue in rev 429, and based on a prior bug, expected refreshing to 468 would fix the issue. However, I still see my pg units not starting, in a "awaiting for member to start" state.
b. I did not encounter this issue on another cluster in an identical environment, so it seems somewhat random. The machines in the juju model are manual machines in Azure.

Essentially, 2/3 postgres units stay stuck in a "awaiting for member to start" state. They cycle through different waiting and executing states, but the PG units never actually start.

Expected behavior
I expect the other 2 units to start and enter a active/idle state. They have been in this state for >48 hours.
Actual behavior

see logs below, but the machines cycle through waiting/executing states, but never enter active/idle as expected.
Versions

Operating system:  22.04.4

Juju CLI: 3.5.4

Juju agent: 3.5.4

Charm revision: 468

LXD: n/a
Log output

juju debug log: https://paste.ubuntu.com/p/FzXnjMpNYz/
snap logs from one unit failing to start: https://paste.ubuntu.com/p/St8WZNn4GT/ (restart at the end of the log file)
snap logs from other unit failing to start: https://paste.ubuntu.com/p/BH3RXfZrTW/
snap logs from healthy unit: https://paste.ubuntu.com/p/b6bgSVZKYm/
pg snap services config: https://paste.ubuntu.com/p/xJJq6ktXm9/
Happy to provide more logs, details or access to the environment. Thanks.

Hi, @ethanmye-rs, it seems like Patroni's health endpoint is failing, likely due to the rejecting connections in the snap logs. This seems to be caused by Patroni calling pg_isready failing with exit code 1. Can you check if you have any Postgresql logs on the failing units from around the time they failed? They should be located in /var/snap/charmed-postgresql/common/var/log/postgresql/. There may be more details in the Patroni logs located in /var/snap/charmed-postgresql/common/var/log/patroni/

Pulled the logs for the two failed units, located in google drive here. Not sure if there is anything sensitive in them (they are about ~200MB total, uncompressed) so I've made them Canonical internal. I will also pull the logs for the active/idle unit, but they are much larger, about 2.4G uncompressed.

Thanks @marceloneppel very much for the help. Core issue was missing pg_wal data, which prevented the other two units from moving past starting state. A few misc things:
The core reason the replica machines could not start was missing pg_wal data. The data is missing because at an earlier point, postgres actually exhausted the 64GB vm disk and I was forced to restart the machine. This is probably why the replicas are missing pg_wal data. I believe pg clears the pg_wal data on reboot. However, the main database is not very large, maybe 6-7GB based on the data in /var/snap/charmed-postgresql/common/var/lib/postgresql/, so it is suprising that pg_wal is so large. It would be nice to set a charm limit on pg_wal to avoid getting into this issue.
Based on the logs, it seems like if upgrading from 429 -> 468, you will still see superfluous log entries for the charmed-postgresql.pgbackrest-service and similar failing to start.
It would also be nice to surface as a warning (either in juju or COS) is one of the patroni members is in anything but a streaming or running state. Having machines stuck in starting surfaced no errors.
For future reference, this is how we checked the patroni status:
curl :8008/cluster
and for reiniting the followers, to be run on one of the follower machines:
sudo -H -u snap_daemon charmed-postgresql.patronictl -c /var/snap/charmed-postgresql/current/etc/patroni/patroni.yaml reinit postgresql
You can query the state by looking at either the cluster/ endpoint or catting /var/snap/charmed-postgresql/common/var/log/patroni/patroni.log


Ap 3678 remove passported permissions

What
Link to story
Removed seeds for passported and non-passported permissions, as these are now both defaults.
Updated code and tests to remove dependencies on these permissions.
Removed redundant use_ccms_arbiter class.
Removed redundant permissions_updater task helper class.
Checklist
Before you ask people to review this PR:

Tests and rubocop should be passing: bundle exec rake
Github should not be reporting conflicts; you should have recently run git rebase main.
There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
The PR description should say what you changed and why, with a link to the JIRA story.
You should have looked at the diff against main and ensured that nothing unexpected is included in your changes.
You should have checked that the commit messages say why the change was made.

@kmahern from the sentry alerts on UAT I am thinking that this alert will no longer need to be captured. I guess on production the firms will still have the passported and non-passported permissions in any event and so would not be raised there but that raise the question of whether we are going to have a follow up PR or bit of work to remove existing firm permissions that is no longer required.

@kmahern from the sentry alerts on UAT (example) I am thinking that this alert will no longer need to be captured. I guess on production the firms will still have the passported and non-passported permissions in any event and so would not be raised there but that raises the question of whether we are going to have a follow up PR or bit of work to remove existing firm permissions that is no longer required.

@jsugarman thanks for spotting this, I have removed the alert. FYI @colinbruce has created a tidy function in db/seeds/permissions.rb as part of an earlier pr that will remove unused permissions from providers - which is why it was alerting in UAT as the default is now that a provider will have no permissions.