Fix issues with the bold (unread) status on Workspace Item

Details

Fix issues with old phantom reports incorrectly being shown as unread in the workspace switcher.
Fixed Issues

$ https://github.com/Expensify/App/issues/35682
Tests

Log into an old account, best to use one that had already been affected with this incorrect bold issue.
Press on the workspace switcher in the top left corner of the screen.
Confirm that the bold styling is correct for both the Everything section and also for user-created workspaces
If it's bold, there should be an unread report listed in it. If not, there shouldn't be any.

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/88325488/c654ed06-bf74-4a3d-9453-530b25401fa7

Android: mWeb Chrome
https://github.com/Expensify/App/assets/88325488/c2bbff5e-6a79-4018-adf4-80a8c48101bb

iOS: Native
https://github.com/Expensify/App/assets/88325488/af92512f-5256-4d76-ba8b-1cfbeaf88420

iOS: mWeb Safari
https://github.com/Expensify/App/assets/88325488/6dcf1fdb-14e5-436a-813a-93b0fbd6a710

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/88325488/a9ee29f7-d558-420d-959a-b07febc01156

MacOS: Desktop
https://github.com/Expensify/App/assets/88325488/77914a7b-4275-4600-8215-ded8f2e106e8

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

https://github.com/Expensify/App/actions/runs/8145545820
@trjExpensify the ad hoc build is being built above ⬆
when the QA codes and links are posted in this PR, please them test the original bug. 🙇

Boom! It's not bold anymore:

For some reports, "Mark as unread" doesn't work. This also happens on main.
https://github.com/Expensify/App/assets/108292595/7f6690f5-66d0-4eaa-a5c2-7c52f7ea1b3d

2 bugs (or expected?) in this video

unread transaction thread is hidden in LHN
selected workspace is hidden in workspace switcher (this happens only on specific workspace)

https://github.com/Expensify/App/assets/108292595/24789e4d-9327-4a70-bcb4-eb26d1836578

I am not sure this should be fixed here. There are still mysterious unread reports hidden in LHN.
https://github.com/Expensify/App/assets/108292595/e3503b30-da92-4216-b823-a29454b33f72

@hayata-suenaga here's summary of existing bugs:

some reports are never marked as unread
some selected workspaces disappear from workspace switcher
no unread reports in LHN (some unread reports are hidden) but that workspace is still bolded in switcher, which makes user confused

@situchan thank you so much for checking for bugs 🙇

some reports are never marked as unread

Thank you for the screen recording of this issue. In the recording, it appears that you're attempting to mark a report (i.e., chat) with an error as unread. Does the "Mark as unread" function not work for reports with errors? Or does it fail for most reports, without a clear distinction between the ones it works for and those it doesn't?

some selected workspaces disappear from workspace switcher

I don't think a selected workspace should be hidden under any condition. Would you mind creating a GH ticket for this bug? @situchan 🙇

no unread reports in LHN (some unread reports are hidden) but that workspace is still bolded in switcher, which makes user confused

Thank you for reporting this issue. Are these reports are hidden because you're using the focus mode? Or are they hidden for no good reason?

@situchan done, ready to re-test!

@situchan if any phantom reports persist, please add the following code into WorkspaceSettingsUtils.ts at the end of the file into getWorkspacesUnreadStatuses() and paste the console.log results here, it will help me with debugging since I can't replicate any of that on my accounts:
if(ReportUtils.isUnread(report) && !!report.lastActorAccountID) {     console.log(report); }

some reports are never marked as unread

Thank you for the screen recording of this issue. In the recording, it appears that you're attempting to mark a report (i.e., chat) with an error as unread. Does the "Mark as unread" function not work for reports with errors? Or does it fail for most reports, without a clear distinction between the ones it works for and those it doesn't?

I am not sure but I think it's related to whisper message.
If last message is whisper action, 100% fails.
This also happens on main so out of scope

some selected workspaces disappear from workspace switcher

I don't think a selected workspace should be hidden under any condition. Would you mind creating a GH ticket for this bug? @situchan 🙇

This seems not happening on latest main

no unread reports in LHN (some unread reports are hidden) but that workspace is still bolded in switcher, which makes user confused

Thank you for reporting this issue. Are these reports are hidden because you're using the focus mode? Or are they hidden for no good reason?

They are hidden for no good reason.

@cdOut here's console log as you requested:

The root cause is that this condition is perfectly met: lastReadTime < lastVisibleActionCreated

I think I know why that happens.
Unpinned transaction detail report is always hidden in LHN no matter unread or not.

@cdOut bump ^
Please let us know whether my concerns above are out of scope so we can merge, or you'll fix here.
I am fine either as this change doesn't cause any regressions, though bug not fully fixed yet due to unrelated root cause.

@situchan So the fix for this issue would be changing the requirements for when we display a report in the LHN, which is not what I was mostly focusing on fixing in this PR (this was focused on workspace switcher requirements), so it does seem out of scope for this one.
However, if I were provided with the account on which the bug persists, I could work on fixing the issue in this PR. It's incredibly difficult to debug without an account with the bugged data and all my accounts have since been cleared of the phantom issues while I was debugging.
In short, it does seem a little out of scope for this PR, but I will be able to fix it in this one if you could provide me with the email address used for the account where you encountered it, you could let me log in through magic link so I don't need to access the email account itself.

If it's not constantly reproducible, not mandatory to fix it in the scope of this PR.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


ignored_content pattern didn't work if the pattern also match file ended with .md

So, I have this line in the config.toml
ignored_content = [".*"]

Which I expect to make gutenberg ignore file that starts with dot in it's name. Since usually my editor creates such file for autosave purpose.
But it seems that if the file ended with .md for example, .foo.md, gutenberg won't ignore it.

ignored_content is checked after loading the .md files for finding section/page assets. I think is it behaving as intended
cc @PhilipDaniels who implemented it

I believe it can be considered bug.
My case is like this:

I'm running gutenberg serve
Then editing file simple.md
My editor (Emacs) create the file .#simple.md for autobackup purpose
gutenberg detect new file and compile the .#simple.md into public.
I save the simple.md file
The editor deleting the backup file since it's no longer needed
gutenberg complaining that .#simple.md didn't exist and stopped further compilation

-> Content changed .../content/.#simple.md
Failed to build the site
Error: Failed to open '".../content/.#simple.md"'
Reason: No such file or directory (os error 2)

In the first place, .#simple.md should not be compiled since it's only a temporary file created by the editor. Hence thinking that's the case, I put ignored_content = [".*"] on config.toml
Currently, my hacky solution is by not running gutenberg serve if there's a file being edited. And running it if I'm sure all file that being edited already saved into the disk.

I think a markdown file starting by . should never be loaded as a page in the first place, I can't think of a valid usecase for that. That would solve the issue at hand but still needs to think if it wouldn't be better to check the markdown filename against the glob of ignored content.
There is some temp file detection in gutenberg serve https://github.com/Keats/gutenberg/blob/master/src/cmd/serve.rs#L295-L319 but I didn't think emacs would start with a ., I guess I need to update it?

I think a markdown file starting by . should never be loaded as a page in the first place, I can't think of a valid usecase for that.

I'm with you on this.

[...] but I didn't think emacs backup files would start with a ., I guess I need to update it?

After researching some more, here the list of temp file created by Emacs:

#file# for autosave purpose
file~ for backup purpose (file.~1~, file.~2~, file.~3~, etc for numbered backup)
.#file for locking purpose

All temp file above created in the same directory as the original (unless the default setting changed).

I pushed 2 commits for the next branch: one for ignoring the .#kind files and another one to not look at markdown files starting with ..


Intermittent communication failures running on Github.

https://github.com/cicada-mpc/cicada-mpc/actions/runs/1482002135/attempts/1
https://github.com/cicada-mpc/cicada-mpc/actions/runs/1482002135/attempts/2

Fixed with SocketCommunicator.


iOS 14.2 Public Beta 2: error EN-Code 2

Since days I got error message EN-Code 2, even after 3 app updates from the apple App Store.
I’m using iOS 14.2 Public beta 2, iPhone 11

Dear @MichaelScherf
Thank you for your contribution. This issue has been raised previously and has been fixed in iOS 14.2 Beta 4, see here: https://github.com/corona-warn-app/cwa-app-ios/issues/1339#issuecomment-713407878 . Please update to the latest iOS release.
I will close this issue as a duplicate and I would like to ask you to continue any further discussion in the main issue thread https://github.com/corona-warn-app/cwa-app-ios/issues/1339 .
Best wishes,
DS
Corona-Warn-App Open Source Team

Duplicate of  https://github.com/corona-warn-app/cwa-app-ios/issues/1339


ng new  --viewEncapsulation Native|None|ShadowDom do nothing

🐞 Bug report
Command (mark with an x)
- [x] new

Description
Hi,
I try to start new project with default viewEncapsulation set to ShadowDom.
According to ng new documentation, i use --viewEncapsulation flag.
But once the project is generated and served, app-root does not have #shadow-root.
I tried all the other encapsulation but I do not see any result.
What is the expected result for this flag?
Set default shematic with "viewEncapsulation": "ShadowDom" in angular.json and generate app.component.ts with encapsulation: ViewEncapsulation.ShadowDom
OR
Add to main.ts :
bootstrapModule(AppModule, {
  defaultEncapsulation: ViewEncapsulation.ShadowDom
})

Currently it does neither of the two.
🔬 Minimal Reproduction
ng new view-test --skip-git --skip-install --viewEncapsulation ShadowDom
or
ng new view-test --skipGit --skipInstall --view-encapsulation Native
or
ng new view-test --skipGit --skipInstall --viewEncapsulation None

🌍 Your Environment
<EMAIL_ADDRESS>
Windows 10 64bit

Hi, thanks for reporting this. The problem seems to be that encapsulation Is not being set in the component.

What is the reason of this choice ? Why we don't set option globally in main.ts ?


Tooltip and OverflowMenuItem breaking entire js page, saying FloatingMenu TypeError

Detailed description
Breaks the entire javascript

was working on v6.4.2

Describe in detail the issue you're having.

Is this a feature request (new component, new icon), a bug, or a general issue?
bug

Is this issue related to a specific component?
Tooltip and OverflowMenuItem

What did you expect to happen? What happened instead? What would you like to see changed?

What browser are you working in?
Chrome

What version of the Carbon Design System are you using?
v6.10.0

What offering/product do you work on? Any pressing ship or release dates we should be aware of?
IBM Cloud

Steps to reproduce the issue

try hover over it

Step one
Step two
Step three
etc.

Additional information

Screenshots or code
Notes

Hi @nicoxxie any chance you are using React 15-? I'm asking because carbon-components-react 9.x supports React 16.4+ only. Thanks!

Hi @asudoh we are using v16.2.0, that might be reason why, I'm going to try upgrade node and give it a try, thanks!

Verified issue is fixed in node v16.4.1


Question selection feature

Fixed Issues
#20915
Files Changed
tests-module.ts - Lint Errors Solevd/TestQuestionComponent added to Declaration
tests-service.ts - Lint Errors Solevd
test-dashboard.ts-  Lint Errors Solevd
test-dashboard.pipe.ts - Lint Errors Solevd
test-dashboard.html - Lint Errors Solevd
test-model.ts - Lint Errors Solevd
test-routing.ts - Lint Errors Solevd
TestRepositoryTest.cs - ReturnType Task is Added
Checks

[X] Naming Conventions
[X] Server side code comments (proper English, grammar and no spelling mistakes)
[X] Client side code comments (proper English, grammar and no spelling mistakes)
[X] Unused variables, methods, blank spaces and name spaces.
[X] Optimal Code and code formatting
[X] Commit History is proper, no merge is done.
[X] Commit/pull request messages should be proper to justify your feature
[X] All test cases are executed provided by tester.

Known Issues
-#20915

#21129

Comments
All Lint Errors Resolved

pull request name is not proper.


Interrupt handling

Presumably, this supersedes #162 and fixes #152, changes are:

Add child_events handler to unshare which is similar to reap_zombies but also allows to trap stops. It looks much more clear than handling children in TtyGuard
Always use make_group_leader when starting process where needed, instead of making itself a leader in TtyGuard
TtyGuard knows whether stdio is a tty by probing, without external setup, and it's transparent for the user
TtyGuard also detects whether one of stdout or stderr is a tty, even if stdin is not

Other things changed:

SIGTTIN and SIGTTOU are masked out rather than ignored. It's a matter of preference, though (I just use less code)
All commands which may consume input run from vagga build must be run with run_and_wait. Skipping it, unfortunately, results into hanging processes (and I have not checked all the places)
Processes become group leaders even when run not on the tty. Shouldn't be a problem, right?

Probably we need to use /dev/null for stdin in build process so that (2) from above doesn't get triggered.
Some more polishing might be needed:

Vagga is less responsive to Ctrl+C with this patch. Probably a signal is handled by the application and vagga continues to work after application has shut down. Perhaps previously vagga sometimes just dropped the container without proper waiting for exit.
I'm also not sure that we need to propagate a signal by hand to the children processes.

Now Ctrl+C is sent to vagga, not child process. So for example ipython can't handle SIGINT.

We should also send SIGINT signal to the child process group.

Now Ctrl+C is sent to vagga, not child process. So for example ipython can't handle SIGINT.

This scenario is tested and worked for me

We should also send SIGINT signal to the child process group.

Ah, well, fair enough. But the code to do that is still in the pull request.


HomeLab/Articles: K3 vs K8

Is your feature request related to a problem? Please describe.
Another resource
Describe the solution you'd like
| K3s vs K8s: The Best Kubernetes Home Lab Distribution - Virtualization Howto |
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

#1874 closes #1873


Remove note 3 from Chrome/Edge 110+

As according to this page, there're zero Operating Systems supported by Chrome 110+ that do not support COLR font rendering.

Thanks!


tox-poetry-installer crashes due to import error

Hey,
we released poetry1.2.0 and poetry-core 1.1.0 today :tada: Unfortunately this breaks tox-poetry-installer due to changed import paths.
Most of them can be fixed easily:
https://github.com/enpaul/tox-poetry-installer/blob/b3a5e869acf3fc63cb45bec42d34e36137f073b2/tox_poetry_installer/installer.py#L12
from poetry.core.packages.package import Package as PoetryPackage

and
https://github.com/enpaul/tox-poetry-installer/blob/b3a5e869acf3fc63cb45bec42d34e36137f073b2/tox_poetry_installer/utilities.py#L13-L14
from poetry.core.packages.dependency import Dependency as PoetryDependency
from poetry.core.packages.package import Package as PoetryPackage

But I'm  not sure what's the best way to fix https://github.com/enpaul/tox-poetry-installer/blob/b3a5e869acf3fc63cb45bec42d34e36137f073b2/tox_poetry_installer/_poetry.py#L33
This is not available anymore in poetry 1.2.0. Instead it's available in the most recent version of cleo:
from cleo.io.null_io import NullIO

While the easy changes are compatible with poetry < 1.2, the change of NullIO import isn't. Maybe just put another try/except in here to find put what's available?
fin swimmer

Thanks for the report @finswimmer
I've just released version 0.8.5 which pins the Poetry requirement at less than 1.2 to back stop this issue in the immediate time frame. @Callek has a PR up to add support for Poetry 1.2 that I'll be looking at next to hopefully get this functionality added soon

Thanks for the report @finswimmer
I've just released version 0.8.5 which pins the Poetry requirement at less than 1.2 to back stop this issue in the immediate time frame. @Callek has a PR up to add support for Poetry 1.2 that I'll be looking at next to hopefully get this functionality added soon

My pr pins to an alpha of poetry 1.2, but happy to bump that to the final release depending on Ethan's opinion here.
Mostly just blocked on his time

This issue should now be resolved by #70 , thanks to @Callek


Expect minimum deposit for proposals to be higher than the minimum

Expect minimum deposit for proposals to be higher than the minimum instead of equal. This allows a proposal to leave more funds than necessary. This could be used to draw greater attention to important proposals in the event of a DOS attack - frontends could use a rank by deposit size mechanism.

It is an interesting solution. There is unfortunately a major issue with this proposal that we in Ledger can foresee.
If tooling were to rank proposals by the deposit, that would give significant advantage to proposers who have a lot of funds at their disposal. A whale could easily spam the network with many irrelevant proposals and then create one proposal of interest with a very high deposit, which would put that whale's proposal at the very top.
In any case, if I am wrong about this scenario, we are pretty late in the game to make serious changes like that. If you believe that this is a real issue, I would recommend submitting a CIP and we would be able to tackle it for the next era.


Update specs2-core to 4.14.1

Updates org.specs2:specs2-core from 4.12.12 to 4.14.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.specs2", artifactId = "specs2-core" } ]

labels: test-library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #135.


Doesn't seem to work on WP8

It seems that drawing does not work on WP8 (or that I'm missing something during the installation :) ). I have created a Xamarin.Forms Portable project, installed NControl via NuGet for all four projects in the solution, and changed the default code as follows:
			MainPage = new ContentPage
			{
				Content = new StackLayout
				{
					VerticalOptions = LayoutOptions.Center,
					Children = {
						new Label {
							XAlign = TextAlignment.Center,
							Text = "Welcome to Xamarin Forms!"
						},
						new NControlView()
						{
							DrawingFunction = (canvas, rect) => {
								canvas.DrawEllipse(rect, Pens.Red, Brushes.Green);
							},
							WidthRequest = 200, HeightRequest = 200
						}
					}
				}
			};

This works perfectly fine on Android, but does not seem to work for the Windows Phone project. I also tried retargetting the WP project to Windows Phone Silverlight 8.1, but still nothing happens. Is this an issue or am I simply missing something?

We'll check this and see if we can find a solution - it seems to be working here.

If you need further information or a sample project, do not hesitate to ask for it :) Btw, I've had the chance to work with NControl for a bit (using Android) and it's really great! Keep up the good work :+1:

Sorry, mistake on my part: I forgot to call NControl.WP80.NControlViewRenderer.Init(); in MainPage.xaml.cs...


Teams Mode

In Teams Mode it chases down smaller cells which are in the same team as you!
Also it runs away from bigger cells which are same team as you!
Please I really want you to fix this and I had this problem for a while now. Pretty please? :cake: :C

Bot is not for team mode.

I would think team mode would be simple to implement right?

Woah, I thought only the developer (Apostolique) can reply to issues? Kosti1, that's none of your business, why do you waste your time reading issues on a Agar.io bot's code in github?

It is fun to read issues and help people!

Apostolique, please reply?? ;-;

Other people can respond, it doesn't matter as I had already responded to this exact same thing before. And no, team mode isn't easier to code as allies can block you and you can block them.

What do you mean they can block you? Like you can't go through them?

No, you can't. When the mode first came out, people on the same team would hide inside their biggest team mate becoming "invincible".

You were talking about making viruses an "obstacle" rather than an enemy, why not make people on your own team obstacles too?

It hasn't been coded yet. When it's done then yes it will be easy.


webxr example is broken with 'no method named xr found for struct Navigator in the current scope'

Describe the Bug
Hi, while trying to run the webxr example with RUSTFLAGS=--cfg=web_sys_unstable_apis npm run serve I ran into this issue:
error[E0599]: no method named `xr` found for struct `Navigator` in the current scope
  --> examples/webxr/src/lib.rs:81:28
   |
81 |         let xr = navigator.xr();
   |                            ^^ method not found in `Navigator`

Steps to Reproduce

Checkout wasm-bindgen commit 4caa98165c65984e3eba3dd7825f3bf44955d127
cd into examples/webxr
Run npm install
Run RUSTFLAGS=--cfg=web_sys_unstable_apis npm run serve
Get the above error

I found a fix; it looks like a XrSystem feature flag was not generated. This gets the code to run:
diff --git a/crates/web-sys/Cargo.toml b/crates/web-sys/Cargo.toml
index 19f804a0..77a01baa 100644
--- a/crates/web-sys/Cargo.toml
+++ b/crates/web-sys/Cargo.toml
@@ -1484,6 +1484,7 @@ XrSessionEventInit = []
 XrSessionInit = []
 XrSessionMode = []
 XrSpace = ["EventTarget"]
+XrSystem = []
 XrTargetRayMode = []
 XrView = []
 XrViewerPose = ["XrPose"]
diff --git a/examples/webxr/Cargo.toml b/examples/webxr/Cargo.toml
index 4127ec5e..1d90d11c 100644
--- a/examples/webxr/Cargo.toml
+++ b/examples/webxr/Cargo.toml
@@ -54,6 +54,7 @@ features = [
   'XrSessionInit',
   'XrSessionMode',
   'XrSpace',
+  "XrSystem",
   'XrTargetRayMode',
   'XrView',
   'XrViewerPose',

Solved by #2863.


Can't get this working

Hi, think I have everything set up correctly, but I can't get anything to autocomplete.
Racer works fine from the CLI, I've set the paths up in the config, and I have language-rust installed. Not sure where I'm going wrong.
Config:
  racer:
    racerBinPath: "/usr/bin/racer"
    rustSrcPath: "/usr/src/rust/src/"

Some racer output:
/usr/bin/racer complete std::io::Br
MATCH Broadcast,628,11,/usr/src/rust/src/libstd/io/mod.rs,Struct,pub struct Broadcast<T, U> {
MATCH Broadcast,628,11,./libstd/io/mod.rs,Struct,pub struct Broadcast<T, U> {

Source dir;
ls -l
total 232
-rw-r--r-- 1 tom tom 37519 May 13 21:03 AUTHORS.txt
-rwxr--r-- 1 tom tom 40449 May 13 21:03 configure*
-rw-r--r-- 1 tom tom  6100 May 13 21:03 CONTRIBUTING.md
-rw-r--r-- 1 tom tom 16809 May 13 21:03 COPYRIGHT
-rw-r--r-- 1 tom tom 10847 May 13 21:03 LICENSE-APACHE
-rw-r--r-- 1 tom tom  1071 May 13 21:03 LICENSE-MIT
-rw-r--r-- 1 tom tom 10059 May 13 21:03 Makefile.in
drwxr-xr-x 1 tom tom    32 May 13 21:03 man/
drwxr-xr-x 1 tom tom   380 May 14 07:25 mk/
-rw-r--r-- 1 tom tom  4355 May 13 21:03 README.md
-rw-r--r-- 1 tom tom 86070 May 13 21:03 RELEASES.md
drwxr-xr-x 1 tom tom   920 May 14 07:25 src/

Sorry, our bad.
We broke something during the last update ;(
New version will be pushed shortly.

Meanwhile, if you're in a hurry and wanna fix it for yourself, you can open your:
~/.atom/packages/racer/lib/racer.coffee
and replace (around line 47):
provideAutocompletion: @getRacerProvider

by
provideAutocompletion: ->
  @getRacerProvider()

then force Atom to reload by opening the command palette (ctrl+shift+p/cmd+shift+p) and searching for Window:Reload

No need for manual fixing finally, @edubkendo is damn quick :)


Handle on hold state change for application bubble

MOB-2057
Changes overview:

Handle on hold state change for application bubble
Remove VisitorMediaStateListener for global bubble from onDestroy() (is not related to bug, I just noticed that it was missing)

!merge


fix: STONE-825 Change URL for Webhook

Description
Changing URL for webhook - smee.io is under maintenance
Issue ticket number and link
Type of change

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/test all

/test all

The pipeline has been triggered and results uploaded in internal instance.


[tls] Handle initialization for pthread-style tls variables

The previous emulation layer was not handling non-zero initialized TLS variables.
In order to do so we'd need to either consume another pthread key per thread, or introduce an allocation per thread (using nullptr as 'unset' and allocated as otherwise).
This change opts for the latter.

CC @tamird

Are you sure we need an extra key? Instead of storing T in the TLS keys, couldn't we store struct { T t; set bool; }? That gives us roughly std::optional semantics and likely won't eat another key (and would require much less code to change here).

I think most of our thread locals are pointer sized, so that would inadvertently eat twice the pthread keys.
This is a larger change admittedly, but it's far simpler in practice, and I think that's going to be overall better for us for this legacy use case.

Well, I adedd the pointer specialization 🤷♂


Seafile: service and refactor

Motivation for this change
Seafile service, running a full seafile server.

To build the seafile server, i had to change the existing seafile-shared package and renamed it to one seafile package.
I updated all versions to 5.1.2-server tag, seafile-client (version 5.0.7) builds fine
added a bunch of django python packages for seahub

Service file could use some more options:

all databases are sqlite (seafile defaults)
configured to run in fastcgi mode behind Nginx/Apache (see http://manual.seafile.com/deploy/deploy_with_nginx.html)

Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Just skimmed across the diff. See inline annotations.

@Cornu can you make separate commits for each package.
With the Python packages you will most likely have to explicitly disable tests with doCheck = false; because Django packages often don't come with tests, and when they do, they typically don't run out of the box and are hard to set up.

@FRidh do you mean for each Python package?
I will push new commits this weekend, i'm a little busy right now.

Indeed, for each Python package.

I started writing a test for this module in https://github.com/Cornu/nixpkgs/pull/1

@cornu Any updates on this?

@uwap Hey, i'm not running seafile at the moment, so won't work on this anytime soon.
I would however merge pull requests and help with improvements, so feel free to help.
@kampfschlaefer Thanks for the module test
So open issues are:

update to current version of seafile
split python packages into seperate commits

Having a Seafile service in NixOS would be superb; thanks for this work!

Closing this for now, doesn't look like this will get finished anytime soon.


[typescript-resolvers] Add meta field to typescript-resolvers plugin's output

Description
Currently, we don't know easily what has been generated from the run without parsing through the output's content.
This PR adds a new optional meta to allow plugins to report certain things about the run.
This PR also makes @graphql-codegen/typescript-resolvers report generated resolver type names - after applying namingConvention - to meta. This allows plugins/presets (e.g. Server Preset) that relies on @graphql-codegen/typescript-resolvers plugin to import the generated resolver types without trying to match the namingConvention logic manually.
Type of change
Please delete options that are not relevant.

[x] New interal feature

How Has This Been Tested?

[x] Unit test

Hi @saihaj , the intention is that meta will not be printed to any generated files, therefore users won't see any difference in their artifacts.
The main use for these is to report metadata of the run for advanced use cases. For example, server preset needs to know the name of generated types so it can generate its import statements. Here's an example generated file from server preset:
import type { UserResolvers } from './../../types.generated';
export const User: UserResolvers = {
  /* Implement User resolver logic here */
};

If user applies namingConvention to change generated type to snake case though, the above would fail as we need to import user_resolvers instead of UserResolvers. One option is for server preset to implement the same namingConvention logic, which is cumbersome. With the meta field, server preset can just look to see the generated type names to generate the imports line:
import type { user_resolvers } from './../../types.generated'; // Server Preset can look into the `meta` field to know `user_resolvers` is the name of the generated type
export const User: user_resolvers = {
  /* Implement User resolver logic here */
};


Canvas::set_target is actually unsound

cc @nrxus
I made an article last week about our experience trying to refactor SDL2's render part, which you can see here. The article was very well, however a certain Ralf sent me an email with a very interesting statement:

However, I am slightly concerned about your with_target at the end of the post.  It seems to me like this suffers from the same problem that thread::scoped already ran into, namely -- Rust does not prevent memory leaks, and as a result, the destructor is not guaranteed to run. Specifically, what happens if someone calls mem::forget(canvas.with_target(tex))? Maybe I am missing something, but it seems to me like this would leave the canvas in a bad state.
https://github.com/rust-lang/rust/issues/24292
https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md

And he was totally right: if you mem::forget the TextureCanvas, the old canvas will render to a Texture instead of a Window... this would have been a minor problem if it was actually sound, but it isn't; now that TextureCanvas is dropped, the texture can be used freely again, including being able to render on itself (never tried, but sound like a terrible idea), and being dropped itself, leading to the texture being targeted by the Canvas internally actually being freed, but still being targeted for draws and such.
The solution here is to actually give a closure as a parameter of with_target, allowing us to control in 100% of the cases when to reset the target. The inconvenient part is that it would be more annoying to use, but it's the price to pay for safety, unfortunately.

Seems I was too slow to open this issue myself. Whatever, the fix looks good :)


EKS Storage Volume Support

I see that this Chart is tested against GKE. I work at Nike and we are using EKS.
According to the Helm Chart documentation, I believe the only thing I need to change in the values.yaml file is the storageClassName: "standard" variable to storageClassName: "gp2"
I have verified that the cluster does, in fact, have a storage class set up. However, when I go to deploy the Chart and I describe my master elasticsearch nodes, I am getting this error message:
pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
I believe that I am still missing some configuration setting having to do with Storage. Please let me know if you need any additional information. Any help is appreciated.

I work at Nike and we are using EKS.

While we don't have any automated testing yet for EKS it has been manually confirmed to work. As long as the Kubernetes provider has some kind of persistent storage (which EKS does) it's going to work just fine.
Have you been able to run other statefulsets with the same volumeClaimTemplate configuration?
Could you give me the following to help debug:

Your values.yaml configuration (mostly interested in the volumeClaimTemplate settings).
Output of the following commands:

kubectl get sc
kubectl get pvc
kubectl get events
kubectl get sts elasticsearch-master -o yaml # (or whatever your deployment is called)
kubectl describe pod elasticsearch-master-0

output.txt
Thank you for getting back to me! It is much appreciated. We tried a workaround that fixed the original error message.  I have also attached the requested output. The output is from the current configuration which is not encountering the original error message.
Again, here is the original error message:
pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
The steps taken for the "workaround" are here:
We created a new storage class on the cluster named "elasticsearch" of type "gp2".
Her is the yaml:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: elasticsearch
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

In the values.yaml file we changed the storageClassName: "standard" variable to storageClassName: "elasticsearch".
Here is the volumeClaimTemplate section taken from loading the vaules.yalm  variables into the statefulset.yaml template:
volumeClaimTemplates:
  - metadata:
      name: elasticsearch-master
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 30Gi
      storageClassName: elasticsearch

Deploying this configuration via Helm worked. We then deleted the resources from the "workaround" configuration and tried going back to our "original" configuration - IE we changed the values.yaml file storageClassName: "standard" variable to storageClassName: "gp2" . and deployed again via Helm and this also worked.
Here is the volumeClaimTemplate we currently have in the cluster:
volumeClaimTemplates:
  - metadata:
      name: elasticsearch-master
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 30Gi
      storageClassName: gp2

We are going to continue testing this for a proof of concept. Thank you for your help. Please let me know if you have any questions or require additional information.

I am going to close the issue seeing how we are not encountering the original error message. Again, please let me know if you have any follow up questions or require additional information.


first round of face related api fixes

drishti/FaceTracker.hpp updates

fix index and resize output arrays
make drishti::sdk::Face a lightweight struct (eyes + landmarks) w/ public Array<>
add public <-> private face model conversion for Face

don’t wait on scene in FaceFinder::~FaceFinder() destructor if optimized pipeline is not used
core/convert.cpp: fix bounds access in unpack()
move private headers out of DRISHTI_DRISHTI_HDRS_PUBLIC
disable experimental flow in public FaceTracker API
Add a public SDK wrapper for SensorModel class
disable shared lib by default for hunter packaging
DRISHTI_BUILD_EXAMPLES=ON
For default repository builds it is desirable to build the console apps and examples with DRISHTI_BUILD_EXAMPLES=ON — we can disable these explicitly for hunter lib only package use.
add DRISHTI_INSTALL option, skip installation stage if off (default on)
wrap add_subdirectory(app) w/ DRISHTI_BUILD_EXAMPLES
set DRISHTI_BUILD_EXAMPLES=ON (be explicit) for CI builds
remove legacy DRISHTI_USE_TEXT_ARCHIVES from build-appveyor.cmd
remove “.” from option descriptions
DRISHTI_BUILD_{TESTS,BENCHMARKS}=OFF by default
Enable tests in CI configs explicitly
update packages in Config.cmake.in (Eigen -> Eigen3)
add public API layer for Sensor model
add a handful of getters/setters for FaceTracker configurations
add a Matrix<T,int,int> API type

There seems to be some gcc + lto strangeness.  Maybe this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808

https://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries

Should not be the reason. gcc-ranlib and gcc-ar set by CMake.

https://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries

Looks like this one is fixed in GCC 4.9+

I do notice these BFD  ... plugin needed to handle lto object warnings when building the static libs.  My sense is that this issue is related to the untested LTO + static configuration.  A small tests case is needed.  I might have to take a look this weekend.
BFD: /Users/dhirvonen/devel/drishti_hunter_test/src/3rdparty/drishti/_builds/android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections-lto-MinSizeRel/src/lib/drishti/st13drPy/Eye.cpp.o: plugin needed to handle lto object
BFD: /Users/dhirvonen/devel/drishti_hunter_test/src/3rdparty/drishti/_builds/android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections-lto-MinSizeRel/src/lib/drishti/st13drPy/EyeIO.cpp.o: plugin needed to handle lto object

While investigating this, I was reminded that the surrogate internal-static-library-as-replacement-for-object-library structure used for the versioned shared public api layer doesn't feel right for the final static build configuration.  I guess if hunter is used, the additional internal private library layer should be fairly transparent.  We could either rebuild the files needed in the public api using sources collect by sugar or we could potentially use the static merge feature.  I think it needs more thought.

[ 82%] Linking CXX executable test-drishti-drishti-face

cd /Users/travis/build/elucideye/drishti/_builds/android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections-lto-MinSizeRel/src/lib/drishti/drishti/ut && /Users/travis/build/elucideye/drishti/_ci/cmake/bin/cmake -E cmake_link_script CMakeFiles/test-drishti-drishti-face.dir/link.txt --verbose=1

/Users/travis/build/elucideye/drishti/_ci/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++ --sysroot=/Users/travis/build/elucideye/drishti/_ci/android-ndk-r10e/platforms/android-19/arch-arm  -fvisibility-inlines-hidden -fvisibility=hidden -fdata-sections -ffunction-sections -std=c++11   -march=armv7-a -marm -mfpu=neon -mfloat-abi=softfp -funwind-tables -no-canonical-prefixes -fexceptions -frtti -Wno-c++11-narrowing -Wno-unused-parameter -Wno-unused-local-typedefs -Wno-unknown-attributes -Wno-shorten-64-to-32 -fopenmp -Os -DNDEBUG -flto -fno-fat-lto-objects  -Wl,--fix-cortex-a8  -fPIE -pie -Wl,--gc-sections -Wl,-z,nocopyreloc  CMakeFiles/test-drishti-drishti-face.dir/test-FaceTracker.cpp.o  -o test-drishti-drishti-face ../../libdrishti-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/sdk/native/libs/armeabi-v7a/libopencv_world-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libgtest-MinSizeRel.a ../../libdrishtisdk-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libaglet-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libgauze-MinSizeRel.a ../../libdrishti_world-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libcvmatio-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/sdk/native/libs/armeabi-v7a/libopencv_world-MinSizeRel.a -ldl -llog /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libpng-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libz-MinSizeRel.a /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libxgboost-MinSizeRel.a -lm /Users/travis/.hunter/_Base/4b72d50/5449f57/0e66ba9/Install/lib/libogles_gpgpu-MinSizeRel.a ../../../../../../../_ci/android-ndk-r10e/platforms/android-19/arch-arm/usr/lib/liblog.so ../../../../../../../_ci/android-ndk-r10e/platforms/android-19/arch-arm/usr/lib/libandroid.so ../../../../../../../_ci/android-ndk-r10e/platforms/android-19/arch-arm/usr/lib/libEGL.so ../../../../../../../_ci/android-ndk-r10e/platforms/android-19/arch-arm/usr/lib/libGLESv2.so  "/Users/travis/build/elucideye/drishti/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a"

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/iostream:62:0: warning: type of 'cerr' does not match original declaration

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/iostream:62:18: warning: type of 'cerr' does not match original declaration

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/iostream:62:0: note: previously declared here

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/sstream:387:11: warning: type 'struct basic_ostringstream' violates one definition rule

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/sstream:387:11: note: a type with the same name but different layout is defined in another translation unit

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/ostream:58:11: warning: type 'struct basic_ostream' violates one definition rule

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/ostream:58:0: note: a type with the same name but different layout is defined in another translation unit

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/bits/basic_ios.h:66:11: warning: type 'struct basic_ios' violates one definition rule

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/bits/basic_ios.h:66:11: note: a type with the same name but different layout is defined in another translation unit

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/istream:58:11: warning: type 'struct basic_istream' violates one definition rule

/Users/travis/build/elucideye/drishti-upload/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/istream:58:11: note: a type with the same name but different layout is defined in another translation unit

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans0.ltrans.o:ccRRA3ox.ltrans0.o:function (anonymous namespace)::FaceTest_RunSimpleTest_Test::TestBody() [clone .lto_priv.993]: error: undefined reference to 'drishti::sdk::FaceTracker::good() const'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans0.ltrans.o:ccRRA3ox.ltrans0.o:function (anonymous namespace)::FaceTest_RunSimpleTest_Test::TestBody() [clone .lto_priv.993]: error: undefined reference to 'drishti::sdk::FaceTracker::operator()(drishti::sdk::VideoFrame const&)'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function std::_Sp_counted_ptr_inplace<drishti::sdk::FaceTracker, std::allocator<drishti::sdk::FaceTracker>, (__gnu_cxx::_Lock_policy)2>::_M_dispose(): error: undefined reference to 'drishti::sdk::FaceTracker::~FaceTracker()'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::SensorModel::Intrinsic::Intrinsic(drishti::sdk::Vec<float, 2> const&, float, drishti::sdk::Vec<int, 2> const&)'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::SensorModel::Extrinsic::Extrinsic(drishti::sdk::Matrix<float, 3, 3> const&)'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::SensorModel::SensorModel(drishti::sdk::SensorModel::Intrinsic const&, drishti::sdk::SensorModel::Extrinsic const&)'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::Context::Context(drishti::sdk::SensorModel&)'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::FaceTracker::FaceTracker(drishti::sdk::Context*, drishti::sdk::FaceTracker::Resources&)'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::Context::~Context()'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::SensorModel::~SensorModel()'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::Context::~Context()'

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T//ccRRA3ox.ltrans1.ltrans.o:ccRRA3ox.ltrans1.o:function (anonymous namespace)::FaceTest::create(cv::Size_<int> const&, int, bool) [clone .isra.276] [clone .lto_priv.1050]: error: undefined reference to 'drishti::sdk::SensorModel::~SensorModel()'

https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ
Creating an archive with gcc-ar works as expected:
 gcc -c -flto a.c
 gcc-ar cr a.a a.o
 gcc -flto b.c a.a

If you use a version of ar that doesn't load the liblto_plugin, you'll get linker errors:
 gcc -c -flto a.c
 ar cr a.a a.o
 gcc -flto b.c a.a

/tmp/ccncHnsT.ltrans0.ltrans.o:ccncHnsT.ltrans0.o:function foo1: error: undefined reference to 'foo3'
/tmp/ccncHnsT.ltrans0.ltrans.o:ccncHnsT.ltrans0.o:function main: error: undefined reference to 'foo2'
collect2: error: ld returned 1 exit status

I think we've hit this issue before, no? Something about inappropriate usage of ranlib. If we are using Hunter to manage Drishti library we don't need "merge-everything-into-big-static-library" step. All dependent libraries will be linked automatically, user can just use Drishti::drishti or something.

I think we've hit this issue before, no? Something about inappropriate usage of ranlib

That sound familiar.  Another lto SO issue
Here are the current CMake tools  w/ the active Android toolchain.
CMAKE_RANLIB /android/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-ranlib
CMAKE_AR /android/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-ar
CMAKE_NM /android/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm
CMAKE_CXX_ARCHIVE_CREATE <CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_CXX_ARCHIVE_FINISH <CMAKE_RANLIB> <TARGET>

Should not be the reason. gcc-ranlib and gcc-ar set by CMake.

That could be the issue.  I will take a look.

It turned out all of the lto problems were really due to a strip as part of creating resymbolicification friendly releases with shared library builds.
https://github.com/elucideye/drishti/pull/558/commits/1e389f983924e1d302433c006e170dbff952ef55#r136215175

All dependent libraries will be linked automatically, user can just use Drishti::drishti or something.

Yes, but I think the drishtisdk layer could be removed and isn't really needed with drishti_world (which could be renamed).  This was originally a target for fusing object libs: drishti->drishtisdk->drishti_{world|eye,face,*}.


Feat/profile menu

Related Ticket(s)
Develop MyIBM profile menu
Description
Adds static profile menu to masthead

Changelog
New

Profile menu [388059f]

Removed

"More info" Storybook button [5022b03]

@jeffchew Fixed!


IOS safari doesn't connect to a room.

SDK verion: 0.17.1
LiveKit server version: 15.5
IOS version: 15.3
Only in IOS safari the client can't connect to a room. If the client connects without publishing any media stream then after some time the connection happens. But if there is at least one publishing media stream, then seems like the client can't finish the connection.

Are you able to reproduce with the sample JS client?

@davidzhao Yeah, same behavior. The log window says "could not connect after timeout".

The first screenshot were taken from a PC, and the second from an iphone.

Ah I see the issue, you are loading the sample app over insecure HTTP. Mobile Safari does not allow media capture when it's running over an insecure connection.
Can you try going to https://example.livekit.io ?

Unfortunately, it is still the same.  Also, the previous connection was working over HTTPS as well. Just out of curiosity, what made you think it was insecure?

Your initial screenshot shows Safari's address bar showing Not secure

Ahh, I am sorry, I was wrong. But anyway with the example.livekit.io it didn't work as well :(

interesting.. it's working well for me against our server. Can you share any debugging logs from mobile safari?  here are instructions on how you could accomplish that.

[Log] connecting to – "wss://livekit.test.appercode.com/rtc?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NDk1MTY0MzksImlzcyI6IkFQSTlrRjNnQkNoaXRxV…" (2.972e1033.chunk.js, line 2)
"wss://livekit.test.appercode.com/rtc?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NDk1MTY0MzksImlzcyI6IkFQSTlrRjNnQkNoaXRxViIsImp0aSI6IlVzZXIgMSIsIm5iZiI6MTY0NjkyNDQzOSwic3ViIjoiVXNlciAxIiwidmlkZW8iOnsicm9vbSI6InJvb20xIiwicm9vbUpvaW4iOnRydWV9fQ.wJTg9gdoWYf8a9Orv6RRfDCl1QtcWGbr33l5Y0IkobM&sdk=js&version=0.17.1&protocol=6"
[Log] connected to Livekit Server version: 0.15.5, region:  (2.972e1033.chunk.js, line 2)
[Log] room event – "stateChanged" – "connected" (2.972e1033.chunk.js, line 2)
[Log] received server offer – "offer" – "stable" (2.972e1033.chunk.js, line 2)
[Log] sending answer (2.972e1033.chunk.js, line 2)

That's it,the UI shows the error ("could not connect after timeout"). Might it be because the timeout too small and somehow it takes more time in safari to establish the connection?

Having the same issue, but in every browser. It seems like some network issue for me. One of my coworkers also facing this issue(he is in other country, using other OS).
But v0.15.4 and below is working.
I have checked the differences and found that in client-sdk-js since v0.15.4 in RCTEngine.ts file event handler RTCPeerConnection.oniceconnectionstatechange replaced with RTCPeerConnection.onconnectionstatechange.
The issue is gone when I replaced onconnectionstatechange with oniceconnectionstatechange on my local environment in the latest sdk version for testing purpose(and all connectionState checks with iceConnectionState).
Can you tell me why this event handlers have been changed after v0.15.4?

closing issue as it's stale. please file a new issue if problem persists.


Update create-placement-policy.md

Corrected VMware product names.

@rvandenbedem : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"


Compilation Error with sgx_ucrypto and sgx_tcrypto packages

Dear Team,
While trying to do the sgx-keyvault deployment from a freshly downloaded repo as instructed in the installation instruction, I am facing the following error with the native static library - 'sgx__tcrypto' and sgx_ucrypto`
Compiling rand_os v0.1.3
Compiling rand v0.4.6
Compiling jobserver v0.1.22
Compiling which v4.1.0
error: could not find native static library sgx_tcrypto, perhaps an -L flag is missing?
error: aborting due to previous error
error: could not compile sgx_ucrypto
To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:179: bin/ternoa-client] Error 101

Could you provide more information about your building environment? Are you building within our docker, or somewhere else?


keyboard not visible after dialog close

Hi @mmazzarolo,
I am using react-native-modal v4.1.1 and RN v0.52.
I looked at issue #53 but I still having issues.
I am using Android (in iOS it works fine without onModalHide): When my modal dialog is shown the keyboard is hidden - which is the behavior I want.
When the dialog is closed the keyboard never shows up again, even though I am staying in the same screen.
my component that contain the modal dialog looks like this:
class ComponentA extends Component {
    constructor(props) {
        super(props);

        this.state = {
            isErrorDialogVisible: false,
        };
    }

    componentWillReceiveProps = (nextProps) => {
        is (nextProps.error) {
            this.setState({
                isErrorDialogVisible: true,
            });
        }
    }

    closeDialog = {
        this.setState({
            isErrorDialogVisible: false,
        })
    }

    render() {
        return(
            <View>
                <TextInput
                    .....
                />
                <Modal
                    isModalVisible={this.state.isErrorDialogVisible}
                    handleClick={this.closeDialog}
                />
            </View>
        )
    }
}

and my modal dialog component is something like:
export default class ModalDialog extends Component {

    onButtonClick = () => {
        this.props.handleClick();
    }

    render() {
        return(
            <View>
                <Modal
                    isVisible={this.props.isModalVisible}
                >
                    <View>
                        .....
                        <TouchableOpacity onPress={this.onButtonClick}>
                                ....
                        </TouchableOpacity>
                    </View>
                </Modal>
            </View>
        )
    }
}

After the dialog closes, I can see that closeDialog is called but the keyboard never pops up again?
I tried to tried to regain focusthis.textInput.focus(); in componentWillUpdate method but with no luck.
using onModalHide method?
Is there a way to call onButtonClick  after onModalHide is called?

Hey @assafb81, did you already try calling this.textInput.focus() in the onModalHide callback?
I don't see any reason for it to not work 🤔 (also, make sure the focus() works correctly)

@mmazzarolo
yep, I tried that
the calling to modal dialog in my component is this:

<ModalDialog
  isModalVisible={this.state.isErrorDialogVisible}
  handleClick={this.onDialogClose}
  onModalHide={Platform.OS === 'android' ? this.keyboardFocus : undefined}
/>

keyboardFocus method is:
keyboardFocus = () => {
  setTimeout(() => {
    this.textInput.focus();
  }, 100);
}

I tried also without setTimeout, and also this.textInput.blur() inside that method.
and in my modal dialog the code is:
onModalHide = () => {
  if (this.props.onModalHide) {
    this.props.onModalHide();
  }
}

and inside the modal:
<Modal
  isVisible={this.props.isModalVisible}
  animationOutTiming={hideDuration}
  onModalHide={this.onModalHide}
>

And it did not do the trick

Thanks for the feedback, could you try swapping react-native-modal with the react-native original modal to see if the issue persists?

@mmazzarolo its involving too much code change
will make me consider not using react-native-modal

will make me consider not using react-native-modal

🤔

please see revise comment

@assafb81 ...why did you delete your posts?

@mmazzarolo
A big advantage to use the this package is the onModalHide.
I solved the issue:
As follows:
class ComponentA extends Component {
    constructor(props) {
        super(props);

        this.state = {
            isErrorDialogVisible: false,
        };
    }

    componentWillReceiveProps = (nextProps) => {
        is (nextProps.error) {
            this.setState({
                isErrorDialogVisible: true,
            });
            this.textInput.blur();
        }
    }

    closeDialog = {
        this.setState({
            isErrorDialogVisible: false,
        })
    }

    // method called only in Android
    keyboardFocus = () => {
        setTimeout(() => {
            this.textInput.focus();
        }, 100);
    }

    render() {
        return(
            <View>
                <TextInput
                    .....
                />
                <Modal
                    isModalVisible={this.state.isErrorDialogVisible}
                    handleClick={this.closeDialog}
                    onModalHide={Platform.OS === 'android' ? this.keyboardFocus : undefined}
                />
            </View>
        )
    }
}

and my modal dialog component is something like:
export default class ModalDialog extends Component {

    onModalHide = () => {
        if (this.props.onModalHide) {
            this.props.onModalHide();
        }
    }

    onButtonClick = () => {
        this.props.handleClick();
    }

    render() {
        return(
            <View>
                <Modal
                    isVisible={this.props.isModalVisible}
                    onModalHide={this.onModalHide}
                >
                    <View>
                        .....
                        <TouchableOpacity onPress={this.onButtonClick}>
                                ....
                        </TouchableOpacity>
                    </View>
                </Modal>
            </View>
        )
    }
}

I removed bad/wrong comments

I'm having the same issue, I can't focus on an input after closing the modal

This isn't directly related to react-native-modal, but the way Modal works in RN. It seems you cannot have the keyboard out for an input focused behind a modal. And while the modal is closing, the modal isn't closed yet, it animates and then close.
You have to wrap your focus function into a setTimeout and wait for the animation to finish (check the value of the animationOutTiming) + a few milliseconds before focusing on the input.
The best I could do is to delay the moment we call onModalHide to the very last moment. We cannot inside the library wrap it into a setTimeout, this would just patch a few use cases and we would have to carry this fix around while it's not supposed to be our problem.
This is addressed in https://github.com/react-native-community/react-native-modal/commit/a032d4d061a2a3d73092e7b42d295e64bf80efa4 and will be shipped in the next release.

There’s a better workaround. Run InteractionManager.runAfterInteractions(()=>{}) and inside it will be your focus event

On Mar 22, 2019, at 4:43 PM, Anthony Cyrille<EMAIL_ADDRESS>wrote:
This isn't directly related to react-native-modal, but the way Modal works in RN. It seems you cannot have the keyboard out for an input focused behind a modal. And while the modal is closing, the modal isn't closed yet, it animates and then close.
You have to wrap your focus function into a setTimeout and wait for the animation to finish (check the value of the animationOutTiming) + a few milliseconds before focusing on the input.
The best I could do is to delay the moment we call onModalHide to the very last moment. We cannot inside the library wrap it into a setTimeout, this would just patch a few use cases and we would have to carry this fix around while it's not supposed to be our problem.
This is addressed in a032d4d and will be shipped in the next release.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

UPDATE: That workaround does not work in all cases. This is still a big issue. I'm having to implement my own modal with Animated.View to get around this


Consider the mandatory DCAT-AP spatial codelists

Consider the mandatory DCAT-AP spatial codelists for Continents, Countries, Places and Geonames.

This is being solved by #80


BUG|| Order Status is wrong if box is closed in QA

In Order Signing, If document is uploaded and modal box is closed, then Status is shown as signed.
Attaching video for reference.
qa order signed issue.webm

hi @bhuvanyuguru changes are done, pls check
cc : @rajeshcherukumalli

Resolved in QA


How to use components without provider?

How to use the components without <Provider>  (like  office-ui-fabric-react does) ?
When test some components with fluent-ui-react, it will show errors with a Provider.
It's unfriendly and ugly to wrap all components with a Provider in all tests.

Closing, duplicate of #1594


[ACR] Prepare release

Need to ship a release with customer issues fixed soon.

API change check
API changes are not detected in this pull request.


SINOWEALTH Game Mouse (marvo G930)

No devices available.
Initializing libratbag
ratbag debug: New device: SINOWEALTH Game Mouse
ratbag debug: Using data directory '/usr/share/libratbag'
ratbag debug: device assigned driver sinowealth
ratbag debug: hidraw info: bus 0x03 vendor 0x258a product 0x1007
ratbag debug: SINOWEALTH Game Mouse is device '/dev/hidraw0'.
ratbag debug: Parsing HID report descriptor
ratbag debug: Parsing HID report descriptor
ratbag debug: hidraw info: bus 0x03 vendor 0x258a product 0x1007
ratbag debug: SINOWEALTH Game Mouse is device '/dev/hidraw1'.
ratbag debug: Parsing HID report descriptor
ratbag debug: Parsing HID report descriptor
ratbag debug: - HID report ID 01
ratbag debug: - HID report ID 02
ratbag debug: - HID report ID 04
ratbag debug: - HID report ID 06
ratbag debug: - HID report ID 07
ratbag debug: - HID report ID 05
ratbag raw: feature set:   05 01 00 00 00 00
ratbag error: Error while sending read firmware version command: -110
ratbag debug: New device: SINOWEALTH Game Mouse
ratbag debug: Using data directory '/usr/share/libratbag'
ratbag debug: device assigned driver sinowealth
ratbag debug: hidraw info: bus 0x03 vendor 0x258a product 0x1007
ratbag debug: SINOWEALTH Game Mouse is device '/dev/hidraw0'.
ratbag debug: Parsing HID report descriptor
ratbag debug: Parsing HID report descriptor
ratbag debug: hidraw info: bus 0x03 vendor 0x258a product 0x1007
ratbag debug: SINOWEALTH Game Mouse is device '/dev/hidraw1'.
ratbag debug: Parsing HID report descriptor
ratbag debug: Parsing HID report descriptor
ratbag debug: - HID report ID 01
ratbag debug: - HID report ID 02
ratbag debug: - HID report ID 04
ratbag debug: - HID report ID 06
ratbag debug: - HID report ID 07
ratbag debug: - HID report ID 05
ratbag raw: feature set:   05 01 00 00 00 00
ratbag error: Error while sending read firmware version command: -110
DBus server ready
Exiting after idle
marvo G930; SINOWEALTH in Linux Fedora 37
Is this wirded mouse not supported?

Hi, this mouse seems to be the different kind of sinowealth devices from what we currently support.
#1359 doesn't mention Marvo G930, but they are most likely the same thing.


[OrderedSet] Add missing uniqueness check

OrderedSet.insert(_:at:) and .updateOrInsert(_:at:) accidentally violate value semantics by failing to check for uniqueness before updating the hash table. (OrderedDictionary is also affected, as it builds upon OrderedSet.)
Add the missing _ensureUnique() call and improve unit test coverage in this area.
Resolves #104.
Huge thanks to @KaiOelfke for providing a sample project that led to isolating the issue! 💙

@swift-ci test


Suddenly unable to access our self-hosted documents

We have self-hosted Grist since its availability on docker.
One or two weeks ago, it has become impossible for us to connect to our Grist server; the error is something we had encountered at the very inception of Grist:
Something went wrong
There was an error: cannot find user.

I have changed nothing to the docker-compose.yml file:
version: "3"

services:
  grist-kuq:
    image: gristlabs/grist
    container_name: grist
    restart: unless-stopped
    volumes:
      - /home/stsinc/dkr/gsk/dta:/persist
    ports:
      - 8484:8484
    environment:
      - APP_DOC_URL=https://grist.[our-internal-domain, has not changed]
      - APP_HOME_URL=https://[our-internal-domain, has not changed]
      - DEBUG=0
      - GRIST_EXPERIMENTAL_PLUGINS=true
      - GRIST_FORWARD_AUTH_LOGOUT_PATH=/signed-out
      - GRIST_HIDE_UI_ELEMENTS=helpCenter,billing,templates,multiSite,multiAccounts
      - GRIST_HOST=<IP_ADDRESS>
      - GRIST_ORG_IN_PATH=false
      - GRIST_PAGE_TITLE_SUFFIX=_blank
      - GRIST_PROXY_AUTH_HEADER=Remote-Email
      - GRIST_SANDBOX_FLAVOR=unsandboxed
      - GRIST_SESSION_SECRET=[the secret , has not changed]
      - GRIST_SINGLE_ORG=docs
      - GRIST_SUPPORT_ANON=false
      - TYPEORM_DATABASE=[database name, has not changed]
      - TYPEORM_HOST=[the URL to the database, has not changed]
      - TYPEORM_PASSWORD=[database password, has not changed]
      - TYPEORM_PORT=5432
      - TYPEORM_TYPE=postgres
      - TYPEORM_USERNAME=docker
      - TZ=America/New_York
    labels:
      - "com.centurylinklabs.watchtower.enable=true"

# For SWAG
networks:
  default:
    name: lsio
    external: true

Here is what the container log says during the session:
Welcome to Grist.
In quiet mode, see http://localhost:8484 to use.
For full logs, re-run with DEBUG=1
Setting up database...
Database setup complete.
2023-11-30 11:18:34.847 - info: == Grist version is 1.1.8 (commit unknown)
2023-11-30 11:18:34.850 - debug: skipping incomplete language ar (set GRIST_OFFER_ALL_LANGUAGES if you want it)
2023-11-30 11:18:34.850 - debug: skipping incomplete language cs (set GRIST_OFFER_ALL_LANGUAGES if you want it)
2023-11-30 11:18:34.854 - debug: skipping incomplete language fa (set GRIST_OFFER_ALL_LANGUAGES if you want it)
2023-11-30 11:18:34.858 - debug: skipping incomplete language ja (set GRIST_OFFER_ALL_LANGUAGES if you want it)
2023-11-30 11:18:34.859 - debug: skipping incomplete language nl (set GRIST_OFFER_ALL_LANGUAGES if you want it)
2023-11-30 11:18:34.864 - debug: skipping incomplete language th (set GRIST_OFFER_ALL_LANGUAGES if you want it)
2023-11-30 11:18:34.870 - info: Loading empty config because /persist/config.json missing
2023-11-30 11:18:34.870 - warn: GRIST_PROXY_AUTH_HEADER is deprecated; interpreted as a synonym of GRIST_FORWARD_AUTH_HEADER
2023-11-30 11:18:34.887 - warn: did not find an appropriately named example workspace in deployment
2023-11-30 11:18:34.891 - info: No plugins found in directory: /grist/.grist/plugins
2023-11-30 11:18:34.895 - info: Found 2 valid plugins on the system
2023-11-30 11:18:34.895 - debug: PLUGIN builtIn/core -- /grist/plugins/core
2023-11-30 11:18:34.896 - debug: PLUGIN bundled/grist-bundled -- /grist/node_modules/@gristlabs/grist-widget/dist/plugins/grist-bundled
2023-11-30 11:18:34.899 - info: Server timeouts: keepAliveTimeout 305000 headersTimeout 306000
2023-11-30 11:18:34.901 - info: server(home,docs,static) available at <IP_ADDRESS>:8484
2023-11-30 11:18:34.908 - warn: Failed to create GoogleAuth endpoint: GOOGLE_CLIENT_SECRET is not defined
2023-11-30 11:18:34.912 - info: Server timeouts: keepAliveTimeout 305000 headersTimeout 306000
2023-11-30 11:18:34.912 - info: pluginServer available at <IP_ADDRESS>:45205
2023-11-30 11:18:34.913 - info: == appRoot: /grist
2023-11-30 11:18:34.913 - info: == i18:namespace: client,server
2023-11-30 11:18:34.913 - info: == docsRoot: /persist/docs
2023-11-30 11:18:34.913 - info: == defaultBaseDomain: grist.[our-domain]
2023-11-30 11:18:34.913 - info: == instanceRoot: /persist
2023-11-30 11:18:34.913 - info: == tag: unknown
2023-11-30 11:18:34.914 - info: == database: postgres://[ip of Postgres server]:5432/grist
2023-11-30 11:18:34.914 - info: == userRoot: /grist/.grist
2023-11-30 11:18:34.914 - info: == bundledRoot: /grist/node_modules/@gristlabs/grist-widget/dist
2023-11-30 11:18:34.914 - info: == loginMiddlewareComment: forward-auth
2023-11-30 11:18:34.914 - info: == docWorkerId: testDocWorkerId_8484
2023-11-30 11:18:34.914 - info: == pluginUrl: http://<IP_ADDRESS>:45205/
2023-11-30 11:18:34.914 - info: == willServePlugins: true
2023-11-30 11:18:34.914 - info: == grist.access.supportEmail<EMAIL_ADDRESS>[default] [GRIST_SUPPORT_EMAIL]
2023-11-30 11:18:34.914 - info: == grist.access.listPublicSites: false [default] [GRIST_LIST_PUBLIC_SITES]
2023-11-30 11:18:34.914 - info: == grist.integrations.sql.timeout: 1000 [default] [GRIST_SQL_TIMEOUT_MSEC]
2023-11-30 11:18:34.914 - info: == grist.integrations.allowedWebhookDomains: - [ALLOWED_WEBHOOK_DOMAINS]
2023-11-30 11:18:34.914 - info: == grist.integrations.proxy: - [GRIST_HTTPS_PROXY]
2023-11-30 11:18:34.914 - info: == grist.locale.offerAllLanguages: - [GRIST_OFFER_ALL_LANGUAGES]
2023-11-30 11:18:34.914 - info: == grist.login.system.forwardAuth.header: Remote-Email [GRIST_PROXY_AUTH_HEADER]
2023-11-30 11:18:34.914 - info: == grist.login.system.forwardAuth.active: true
2023-11-30 11:18:34.914 - info: == grist.login.system.forwardAuth.logoutPath: /signed-out [GRIST_FORWARD_AUTH_LOGOUT_PATH]
2023-11-30 11:18:34.914 - info: == grist.login.system.forwardAuth.loginPath: /auth/login [default] [GRIST_FORWARD_AUTH_LOGIN_PATH]
2023-11-30 11:18:34.914 - info: == grist.login.skipSession: - [GRIST_IGNORE_SESSION]
2023-11-30 11:18:34.914 - info: == grist.login.forced: - [GRIST_FORCE_LOGIN]
2023-11-30 11:18:34.914 - info: == grist.externalStorage.minio.bucket: - [GRIST_DOCS_MINIO_BUCKET]
2023-11-30 11:18:34.914 - info: == grist.externalStorage.disable: - [GRIST_DISABLE_S3]
2023-11-30 11:18:34.914 - info: == grist.externalStorage.active: false
2023-11-30 11:18:34.915 - info: activity docCount=15, orgCount=1, orgInGoodStandingCount=1, userCount=6, userWithLoginCount=6
2023-11-30 11:19:26.739 - debug: Auth[GET]: grist.[our-domain] / customHostSession=, method=GET, host=grist.[our-domain], path=/, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:26.861 - debug: Auth[GET]: grist.[our-domain] / customHostSession=, method=GET, host=grist.[our-domain], path=/, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=wxcyoLWymz7fKJ8hnVricQ
2023-11-30 11:19:26.873 - debug: Auth[GET]: grist.[our-domain] /session/access/active customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/active, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:26.877 - debug: Auth[GET]: grist.[our-domain] /session/access/all customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/all, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:26.929 - debug: Auth[GET]: grist.[our-domain] /orgs/0/workspaces customHostSession=, method=GET, host=grist.[our-domain], path=/orgs/0/workspaces, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:31.016 - debug: Auth[GET]: grist.[our-domain] /session/access/all customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/all, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:31.028 - debug: Auth[GET]: grist.[our-domain] /session/access/active customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/active, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:32.973 - debug: Auth[GET]: grist.[our-domain] / customHostSession=, method=GET, host=grist.[our-domain], path=/, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:33.050 - debug: Auth[GET]: grist.[our-domain] /session/access/all customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/all, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:33.052 - debug: Auth[GET]: grist.[our-domain] /session/access/active customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/active, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:19:33.088 - debug: Auth[GET]: grist.[our-domain] /orgs/0/workspaces customHostSession=, method=GET, host=grist.[our-domain], path=/orgs/0/workspaces, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:42.445 - debug: Auth[GET]: grist.[our-domain] /welcome/home customHostSession=, method=GET, host=grist.[our-domain], path=/welcome/home, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:42.466 - debug: Auth[GET]: grist.[our-domain] / customHostSession=, method=GET, host=grist.[our-domain], path=/, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:42.566 - debug: Auth[GET]: grist.[our-domain] /session/access/all customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/all, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:42.569 - debug: Auth[GET]: grist.[our-domain] /session/access/active customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/active, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:42.614 - debug: Auth[GET]: grist.[our-domain] /orgs/0/workspaces customHostSession=, method=GET, host=grist.[our-domain], path=/orgs/0/workspaces, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:57.164 - debug: Auth[GET]: grist.[our-domain] /session/access/all customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/all, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]
2023-11-30 11:20:57.173 - debug: Auth[GET]: grist.[our-domain] /session/access/active customHostSession=, method=GET, host=grist.[our-domain], path=/session/access/active, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=[session ID]

What have I done wrong or is it a regression?

Loading chunk 966 failed means there's a file the browser is failing to load somehow, looks to be https://..../v/unknown/966.bundle.js
You could try clearing your cache again or using a different browser just to be sure it isn't a cached problem.

Do users sign in using Basic Auth? With the addition of GRIST_IGNORE_SESSION=1, version 1.1.7 should work too, and more sensibly.
It is important that your setup controls the Remote-Email header for all requests that go to Grist, i.e. your server should not pass through this header (if present in the original request) to any Grist endpoint, but should set its own value. (This is from the issue that @paulfitz linked to, https://github.com/gristlabs/grist-core/issues/750#issuecomment-1811082115.)
For a bit more info: before 1.1.7, one visit with Basic Auth would save a session cookie and keep you signed in. But with Basic Auth, there is no good way to sign out, except clearing cookies AND making the browser forget its Basic Auth credentials. Starting with 1.1.7, Grist will only set a session cookie if you configure GRIST_FORWARD_AUTH_LOGIN_PATH. For a setup like Basic Auth, session cookies are not needed and make things worse, so it requires setting GRIST_IGNORE_SESSION=1.
Both options are explained a bit better here: https://github.com/gristlabs/grist-core#forward-authentication-variables.

I am having the same issue. I get the following error:

2023-12-06 12:25:42.536 - debug: Auth[GET]: grist.15shady.net /session/access/all customHostSession=, method=GET, host=grist.15shady.net, path=/session/access/all, org=docs<EMAIL_ADDRESS>userId=1, altSessionId=undefined

I am using traefik-forward-auth, and am setting GRIST_PROXY_AUTH_HEADER=X-Forwarded-User. Here's the snippet of my grist environment from docker compose:
environment:
      - DEBUG=1
      - GRIST_DATA_DIR=/docs
      - APP_DOC_INTERNAL_URL=https://localhost:8484
      - APP_DOC_URL=https://grist.$DOMAINNAME_CLOUD_SERVER
      - APP_HOME_URL=https://grist.$DOMAINNAME_CLOUD_SERVER
      - GRIST_SINGLE_ORG=docs
      - GRIST_ORG_IN_PATH=false
      - GRIST_SUPPORT_ANON=false
      - GRIST_IGNORE_SESSION=1
      - GRIST_DOMAIN=https://grist.$DOMAINNAME_CLOUD_SERVER
      - GRIST_FORWARD_AUTH_HEADER=X-Forwarded-User
      - GRIST_FORCE_LOGIN=true
      #- GRIST_FORWARD_AUTH_LOGIN_PATH=/_oauth
      #- GRIST_FORWARD_AUTH_LOGOUT_PATH=/_oauth/logout
      - GRIST_DEFAULT_EMAIL=$MY_EMAIL
      - GRIST_SESSION_COOKIE=grist.$DOMAINNAME_CLOUD_SERVER


Adapt code to overcome differences of twinBASIC with VBA

Hi @cristianbuse ,
Latest changes from LibMemory, adding the TWINBASIC compiler flag, made using it from twinBASIC quite pointless, as it falls to use slower calls, specially in Win32 office, to the RtlMoveMemory API everywhere.

Adapted MemByte, MemInt, MemLong, MemLongLong and MemLongPtr to use the built-in methods provided by twinBASIC in the VBA namespace instead of calling the RtlMoveMemory API, which is slower.

Added some "changes" to the MemCopy/CopyBytes methods to make them work in twinBASIC. But I wrapped them all within #If TWINBASIC Then ... instead of changing the existing code, avoiding to introduce any new bug to existing code bases, despite that that code works for both VBA and twinBASIC, with no noticeable drops in performance.

MemZero/MemFill seem to properly work in twinBASIC, removed TWINBASIC from the conditional compilation flags.

It's not yet ready to be merged as it needs more testing but at least it makes it usable in twinBASIC just the same way as in VBA.

Hi @Theadd ,
This was a problem as well. Once these 2 issues are sorted then no MemCopy should run fine.

Hi @cristianbuse ,
My apologies for my absence these days.
Thank you =)


Progressive Web App

Will Shynet support PWA (Progressive Web App)? So that it can be installed to home screen as a lite app on mobile devices.

Think this shouldn't be too hard to implement. Add a manifest.json file and a service worker that caches a 'offline' page and displays that when offline. Don't think there's alot more to it than that, I could take a look at doing that maybe

Thanks for reply.
It is easy to add a manifest.json file. But it is not convenient as I'm using official docker images. I need to edit shynet_main:/usr/src/shynet/dashboard/templates/base.html in container everytime.

To be honest, I’m not sure this is something that Shynet would benefit from having.
The Shynet web interface is not implemented as a single page app—it is very much an “old school” web app in many senses. (Which is only to say that the approach it takes is tried and true!)
Trying to mold it to fit into a PWA is probably more trouble than it’s worth, and comes with complexity and maintenance costs that I’m not sure are justified. Let me know if I’m off base here.

Being an SPA would indeed deliver a more streamlined experience like you would expect from a PWA, but I don't think it's a requirement for it to be useful. Shynet's UI is already pretty mobile friendly which is what matters most in my opinion. Adding a manifest file would allow users to 'install' it and run it a seperate 'instance' other than a browser tab, which is already an improvement for the mobile experience.

Thanks for reply.
It is easy to add a manifest.json file. But it is not convenient as I'm using official docker images. I need to edit shynet_main:/usr/src/shynet/dashboard/templates/base.html in container everytime.

If it would be added trough a PR you wouldn't have to do that :)

I think @milesmcc is right. This functionality doesn't fit the current implementation.
On the other hand I don't see any problem to add a small separated django app with PWA dashboard only.
It will take more time and require more javascript. It can be done with pure js but there are some useful libraries like Alpine.js.
The most important advantage of this solution is separation. It won't increase complexity of existing code. There won't be any problem to remove it in case of maintenance problems.

@haaavk the problem with that is when it comes time to build new features, both dashboards need to be updated. I've been thinking about a dashboard overhaul recently, and that would just add a lot of maintenance cost. I really think we should prioritize having "one" main dashboard, unless I'm misunderstanding something fundamental here.

I think about second dashboard as a different slim client. It may contain only sessions chart.
I considered making small android app but here is no API right now. PWA can just cover this case.
Main dashboard should be a priority.


MacOS 1.9.0 cache problem

After update to 1.9.0 tlrc stopped working for me with error: page not found. Try running 'tldr --update'.
Update didn't work, and I tried to clean cache to force update, and after that things become strange:
> tldr --clean-cache
info: cleaning the cache directory...
> tldr --update
info: downloading 'tldr.sha256sums'... 3.27 KiB
info: there is nothing to do. Run 'tldr --clean-cache' if you want to force an update.

It thinks that there is nothing to do on clean/empty cache and did not download any pages.
> tldr tldr
info: cache is empty, downloading...
info: downloading 'tldr.sha256sums'... 3.27 KiB
info: there is nothing to do. Run 'tldr --clean-cache' if you want to force an update.
error: No such file or directory (os error 2)

After some investigation, I made it work with manually downloaded cache and explicitly set language via command line argument.
> tldr --language en tldr
  Display simple help pages for command-line tools from the tldr-pages project.
  ...

My setup:
MacBook pro m1
MacOS Ventura 13.6.3
fish shell
tlrc 1.9.0 via homebrew
ENV:
LANG=ru_RU.UTF-8
LANGUAGE=

config.toml:
[cache]
dir = "/Users/dvkubatkin/Library/Caches/tlrc"
auto_update = true
max_age = 336
languages = []

This is a bug with language detection - an empty language config causes weird behavior, because en and languages from env vars were not added automatically. Should be fixed with https://github.com/tldr-pages/tlrc/commit/7f30db5ddb7db0a2ecb99571fdee121951f44237 - I'll create a patch release to address this. For now, you can set languages = ["ru", "en"] as a workaround.


Save association throug ZF2 and cotrain

Hi,
Is there any example fo save data multiple into tables using association with the help of ZF2 and doctrine?

Looks like a cross-post of https://github.com/doctrine/doctrine2/issues/5917. Please ask for help on IRC, the mailing list or stackoverflow first. Also, remember to provide extensive information of what you need, since the question presented here is incomplete and hard to comprehend as-is.


Extending a goss.yaml, but gossfile is always relative

From the file /example/goss.yaml
gossfile:
  /differentexample/extendme.yaml: {}

Produces:
File error: open /example/differentexample/extendme.yaml: no such file or directory
Expected: extendme.yaml would be picked up from the /differentexample folder

Marking this as a duplicate of #137, the issue has been resolved by #138 and should be released by the end of the week.
I'll update/close this issue when it's released.

Fixed in v0.2.4


Consume PHP dependency from the dep-server

Per https://github.com/paketo-buildpacks/dep-server/issues/45, we should start consuming the PHP dependency from the dep-server (https://api.deps.paketo.io/v1/dependency?name=<dependency>) instead of the https://buildpacks.cloudfoundry.org/dependencies/<dependency>/... location we currently get the dependencies from.
This will make the dependency publishing/consumption process more transparent than the process we use for the dependencies available via the dependency-builds pipeline.
We have already done this switch-over in the Node Engine and Yarn Buildpacks. The outline of what this work will entail can be found in the dep-server issue linked at the top.

Should we hold off on this until https://github.com/paketo-buildpacks/dep-server/issues/30 is implemented?