Intl: Multiple Translations

If in your application you import a package, which is translated
and in your application create a translation, you get:
Duplicated library name 'messages_all'.
library messages_all;
when using the generate_from_arb functionality.
This applies also to the library in the translated files, e.g. messages_es
The cause is that in generate_localized.dart, the library name(s) are hardcoded.
generate_from_arb.dart allows to specify a file prefix, e.g.
--generated-file-prefix=base-
I suggest to use the file prefix also for the library names.
(originally filed directly: https://github.com/dart-lang/intl/issues/9)

Having the issue on the intl package is the right place to start.


Getting ECONNREFUSED at first try of running snap-tweet

Bug description

What did you do? (Provide code in next section)
I tried to take a screensnap of a tweet.
What did you expect to happen?
For snap-tweet to take a snap of a tweet.
What happened instead?
Got a ECONNREFUSED error message.
Do you have an error stack-trace?
Don't know what this is, but I can get it if it can be explained to me ;)
Reproduction

snap-tweet https://twitter.com/elonmusk/status/1492227328386154509
How do I do this?
:

C:\>snap-tweet https://twitter.com/elonmusk/status/1492227328386154509
[snap-tweet] Error: connect ECONNREFUSED ::1:53221
× connect ECONNREFUSED ::1:53221: https://twitter.com/elonmusk/status/1492227328386154509

Environment

snap-tweet version: snap-tweet/1.2.1 win32-x64 node-v17.5.0
Operating System: Windows 10
Node version: node-v17.5.0
Package manager (npm/yarn/pnpm) and version: npm 8.5.0

I'm not too familiar with Windows environments but I'll try to help debug.

Do you have Chrome installed? If so, what version?
Based on searching the chrome-launcher and chrome-remote-interface repos, the immediate issues are related to Node v17. Can you see if using a different version helps?

https://github.com/cyrus-and/chrome-remote-interface/issues?q=is%3Aissue+ECONNREFUSED
https://github.com/GoogleChrome/chrome-launcher/issues?q=is%3Aissue+ECONNREFUSED

Awesome! Any help is always welcome!

Yes. Version 98.0.4758.102 (Official Build) (64-bit)
You hit it on the nail! The problem was with Node v17.5.0. I uninstalled it and installed Node v16.14.0 LTS and set up everything again.

Now it's working! Tyvm!
Now there's a minor thing I noticed that's working differently but I'll open another ticket for that and keep everything tidy.
Thx again!

And how about to run snap-tweet in a headless environment (like a virtual machine)? Is there some way to do this?
My environment:

Debian Linux 5.2.9-2 VM
Node version 16.15.0
Google Chrome version 102.0.5005.61

I'm getting:
[snap-tweet] Error: connect ECONNREFUSED <IP_ADDRESS>:40353
✖ connect ECONNREFUSED <IP_ADDRESS>:40353:
  https://twitter.com/telegram/status/1507356.......

And how about to run snap-tweet in a headless environment (like a virtual machine)? Is there some way to do this?
My environment:

Debian Linux 5.2.9-2 VM
Node version 16.15.0
Google Chrome version 102.0.5005.61

I'm getting:
[snap-tweet] Error: connect ECONNREFUSED <IP_ADDRESS>:40353
✖ connect ECONNREFUSED <IP_ADDRESS>:40353:
  https://twitter.com/telegram/status/1507356.......

I know that google-chrome have some flags to run headless: --headless --disable-gpu

I have same problem. Did you find a solution for this?

I have same problem......


Fixed segfault when terminal small enough to cause label cutoff and refactored drawing code

There is currently a bug in progressbar where it will crash if resized too small when using a label that is a string literal (and thus modifiable memory). Really though, even though this bug is caused by using a string literal for the label, it shows a problem with how the progressbar views the label string. It either needs to take ownership of it, meaning that is responsible for memory management of it once the user has provided it (which requires the user to pass a malloc'd string and not a literal...), or it needs to leave the memory management of the label up to the caller.
The second approach seems more reasonable so that we can avoid unnecessary copying of strings or putting a burden on the user, but this means that the amount of the string that should be rendered must be either computed or stored in the bar. In other words, we can't str[idx] = 0 a string we don't own.
To this end, I started reworking how the progressbar handles rendering of the label, and I might have gotten a bit carried away and ended up refactoring most of the drawing code.
Technical changes:

progressbar no longer modifies the given label at all. Also, it is now explicitly documented that the user is responsible for ensuring that the label continues to exist throughout the existence of the progressbar.
progressbar no longer stores the terminal type. That's an implementation detail of rendering, and struct progressbar is responsible for modeling a progressbar.
step and steps are no longer stored on the progressbar. Again, they're artifacts of rendering, and they do not belong in the progressbar object. They are now calculated during rendering.
Some #define macros were converted to be enum-style constants. This allows for better typesafety and a higher likelihood that the symbols will have names in a debugger.
The format of the ETA string along with some magic constants (amount of whitespace, bar border width, etc) have been converted to constants.
progressbar_draw is no longer exposed in the header or exported in the source. This is a backward compatibility breaking change. Anyone who used the progressbar_draw method will have to alter their code to be compatible with new versions of progressbar if this PR is accepted. However, the method does not make much sense to call directly anyway, and it's documented as internal, so I'm hoping this is acceptable.
progressbar_draw no longer takes in an ETA but rather calculates it itself. This allowed for removing a lot of replicated code at various calling sites to calculate elapsed time, items remaining, etc.
The actual bar component of the progressbar no longer requires a buffer to render. Instead, it is rendered straight to stderr.
Width calculations have been broken out to be a bit clearer and more contained.

Improvements in functionality:

The bar no longer segfaults when sized below a certain width.
The bar now resizes instead of sticking to the size of the terminal when the bar first rendered. Currently it only resizes when the bar is redrawn, but it should be trivial to add a listener for the terminal resizing and redraw appropriately if someone were so inclined.
The bar is now the full width of the terminal instead of having two trailing blank spaces (I believe there was a bug with the width calculations where the ETA was given more space than it needed).

Nice!
On Friday, September 4, 2015, Corbin<EMAIL_ADDRESS>wrote:

There is currently a bug in progressbar where it will crash if resized too
small when using a label that is a string literal (and thus modifiable
memory). Really though, even though this bug is caused by using a string
literal for the label, it shows a problem with how the progressbar views
the label string. It either needs to take ownership of it, meaning that is
responsible for memory management of it once the user has provided it
(which requires the user to pass a malloc'd string and not a literal...),
or it needs to leave the memory management of the label up to the caller.
The second approach seems more reasonable so that we can avoid unnecessary
copying of strings or putting a burden on the user, but this means that the
amount of the string that should be rendered must be either computed or
stored in the bar. In other words, we can't str[idx] = 0 a string we
don't own.
To this end, I started reworking how the progressbar handles rendering of
the label, and I might have gotten a bit carried away and ended up
refactoring most of the drawing code.
Technical changes:

progressbar no longer modifies the given label at all. Also, it is
now explicitly documented that the user is responsible for ensuring that
the label continues to exist throughout the existence of the progressbar.
progressbar no longer stores the terminal type. That's an
implementation detail of rendering, and struct progressbar is
responsible for modeling a progressbar.
step and steps are no longer stored on the progressbar. Again,
they're artifacts of rendering, and they do not belong in the
progressbar object. They are now calculated during rendering.
Some #define macros were converted to be enum-style constants. This
allows for better typesafety and a higher likelihood that the symbols will
have names in a debugger.
The format of the ETA string along with some magic constants (amount
of whitespace, bar border width, etc) have been converted to constants.
progressbar_draw is no longer exposed in the header or exported in
the source. This is a backward compatibility breaking change. Anyone
who used the progressbar_draw method will have to alter their code to
be compatible with new versions of progressbar if this PR is accepted.
However, the method does not make much sense to call directly anyway, and
it's documented as internal, so I'm hoping this is acceptable.
progressbar_draw no longer takes in an ETA but rather calculates it
itself. This allowed for removing a lot of replicated code at various
calling sites to calculate elapsed time, items remaining, etc.
The actual bar component of the progressbar no longer requires a
buffer to render. Instead, it is rendered straight to stderr.
Width calculations have been broken out to be a bit clearer and more
contained.

Improvements in functionality:

The bar no longer segfaults when sized below a certain width.
The bar now resizes instead of sticking to the size of the terminal
when the bar first rendered. Currently it only resizes when the bar is
redrawn, but it should be trivial to add a listener for the terminal
resizing and redraw appropriately if someone were so inclined.
The bar is now the full width of the terminal instead of having two
trailing blank spaces (I believe there was a bug with the width
calculations where the ETA was given more space than it needed).

You can view, comment on, or merge this pull request online at:
https://github.com/doches/progressbar/pull/17
Commit Summary

Fixed segfault when terminal small enough to cause label cutoff and
refactored drawing code.

File Changes

M include/progressbar.h
https://github.com/doches/progressbar/pull/17/files#diff-0 (48)
M lib/progressbar.c
https://github.com/doches/progressbar/pull/17/files#diff-1 (212)

Patch Links:

https://github.com/doches/progressbar/pull/17.patch
https://github.com/doches/progressbar/pull/17.diff

—
Reply to this email directly or view it on GitHub
https://github.com/doches/progressbar/pull/17.

This looks great, and is a fantastic refactor. Thanks for this!


MCA Reborn incompatible with Numismatic Overhaul

Describe the bug
Mod, "Numismatic Overhaul" which changes currency from Emeralds to a 3 Coin System much like terraria's coin system is not compatible with MCA Reborn
To Reproduce
Steps to reproduce the behavior:

Install both MCA and Numismatic Overhaul
Attempt to launch game, console open.
Get error
Caused by: org.spongepowered.asm.mixin.injection.throwables.InjectionError: Critical injection failure: Variable modifier method removeDivisor(I)I in numismatic-overhaul.mixins.json:MCAVillageMixin from mod numismatic-overhaul failed injection check, (0/1) succeeded. Scanned 1 target(s). Using refmap numismatic-overhaul-refmap.json
Look at it, and understand what is happening.

Version
7.5.2-1.19.2, 1.19.2, Fabric 0.14.21
MCA Version, Minecraft version, Modloader
Numismatic ver 0.2.8+1.19
Latest.log
latest.log
Linked Issue

Duplicate of #78


fix(pfNotificationDrawer): Do not add #0 to URL on close or expand

Description
Remove the #0 from the href for the close and expand links in the drawer header. This required commenting out some tests but those are pretty simple and unlikely to break.
Fixes #641

I'm not entirely sure if we should comment out the unit tests. I think it provides more of a patch.

@spadgett do you have any input on this?

well, angular supports href="" but there is a karma known issue with it. I don't think these tests are testing anything that would break on a change that didn't expect to change this and would be tested manually.

Agreed. It looks like @cdcabrera broke this down here https://github.com/patternfly/angular-patternfly/pull/621
Could upgrades to karma solve this?

There is no karma fix and they don't plan on fixing it.

Yes, in #621 we agreed to go with #0. What we didn't realize at the time was what @spadgett found, it changes the URL and breaks the browser history. Given the choices, skipping the automated test of very simple functionality seems to be the most reasonable solution.

I ran back threw and removed the eventFire piece and went with a regular JS click and that seems to do the trick.

//eventFire(closeButton[0], 'click');
 closeButton[0].click();
 $scope.$digest();

 expect($scope.closed).toBe(true);

//eventFire(expandToggle[0], 'click');
 expandToggle[0].click();
 $scope.$digest();

 expandedDrawer = element.find('.drawer-pf.drawer-pf-expanded');
 expect(expandedDrawer.length).toBe(1);

what is the point?

Thanks @amarie401 , updated.


ui: change createAccount to use post

Description
Fixes https://github.com/apache/cloudstack/issues/4558
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

Screenshots (if appropriate):

@blueorangutan ui

@blueorangutan ui

@davidjumani a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress. [S]

UI build: :heavy_check_mark:
Live QA URL: http://qa.cloudstack.cloud:8080/client/pr/4812 (SL-JID-22)


Value tuple incorrect names

Describe the bug
A value tuple within a value tuple has invalid names
Reproducibility
Always

Total: 1h 42m


[HOLD for payment 2024-11-14] [$250] iOS Search - Rename page opens twice when renaming search and opening Rename page again

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.41-3
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause - Internal Team
Action Performed:
Precondition:

User has saved search

Launch New Expensify app
Go to Search
Tap on the dropdown
Tap 3-dot menu next to the saved search
Tap Rename
Rename and save it
Tap on the dropdown
Tap 3-dot menu next to the saved search
Tap Rename

Expected Result:
Rename page will open once
Actual Result:
Rename page opens twice. Another one is in the background of the current Rename page
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/user-attachments/assets/22d7969e-157b-401a-af1a-4d8b5495ac08
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021852037932647375330
Upwork Job ID:<PHONE_NUMBER>647375330
Last Price Increase: 2024-10-31
Automatic offers:

dukenv0307 | Reviewer | 104702512
Nodebrute | Contributor | 104702515

Issue OwnerCurrent Issue Owner: @muttmuure

@muttmuure  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

We think that this bug might be related to #wave-control

Proposal
Please re-state the problem that we are trying to solve in this issue.
What is the root cause of that problem?
What changes do you think we should make in order to solve the problem?
Add Navigation.dismissModal(); in
https://github.com/Expensify/App/blob/main/src/pages/Search/SavedSearchRenamePage.tsx#L27-L34
What alternative solutions did you explore? (Optional)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Proposal
Please re-state the problem that we are trying to solve in this issue.
Rename page opens twice. Another one is in the background of the current Rename page
What is the root cause of that problem?
We navigate to the new query search page without dismissing the rename page.
https://github.com/Expensify/App/blob/6763f1a114817c059426c7304b605e1e31cdaa10/src/pages/Search/SavedSearchRenamePage.tsx#L28
Another problem is the old search page with the old query name still appears if we click on back button twice after renaming a saved search.
What changes do you think we should make in order to solve the problem?

We should dismiss the modal before navigating to the search page with the new query name

Navigation.dismissModal();

https://github.com/Expensify/App/blob/6763f1a114817c059426c7304b605e1e31cdaa10/src/pages/Search/SavedSearchRenamePage.tsx#L28

If the current viewing search is the renaming search we should navigate with type UP to remove the old search page from the navigation stack.

We need to introduce a new param isViewingSearch for the route of SavedSearchRenamePage

the same param for getOverflowMenu function here and pass this to getRoute function

Navigation.navigate(ROUTES.SEARCH_SAVED_SEARCH_RENAME.getRoute({name: encodeURIComponent(itemName), jsonQuery: inputQuery, isViewingSearch}));

https://github.com/Expensify/App/blob/6763f1a114817c059426c7304b605e1e31cdaa10/src/libs/SearchUIUtils.ts#L485

Pass isViewingSearch param to getOverflowMenu function here

menuItems={SearchUIUtils.getOverflowMenu(
    item.title ?? '',
    Number(item.hash ?? ''),
    item.query ?? '',
    showDeleteModal,
    true,
    closeMenu,
    currentSavedSearch?.hash === item.hash,
)}

https://github.com/Expensify/App/blob/6763f1a114817c059426c7304b605e1e31cdaa10/src/pages/Search/SearchTypeMenuNarrow.tsx#L144

Navigate to the search page with type UP if isViewingSearch param is true

Navigation.navigate(
    ROUTES.SEARCH_CENTRAL_PANE.getRoute({
        query: q,
        name: newName?.trim(),
    }),
    isViewingSearch === 'true' ? CONST.NAVIGATION.TYPE.UP : undefined
);

https://github.com/Expensify/App/blob/6763f1a114817c059426c7304b605e1e31cdaa10/src/pages/Search/SavedSearchRenamePage.tsx#L28
What alternative solutions did you explore? (Optional)

We already had a test suite for saved searches so I added new steps for that test (internal tracking issue: https://github.com/Expensify/Expensify/issues/445936)
This is ready for payment @muttmuure

@Nodebrute - paid $250 for C
@dukenv0307 - $250 for C+

$250 approved for @dukenv0307


rnfirebase messaging().getToken(); | [messaging/unknown] The operation couldn’t be completed. (com.firebase.iid error 1001.)

Hello! I've already done all the settings for firebase and Apple, Keys, .p8 certificate ... Two days ago the notifications were arriving correctly and I was also able to recover the token, however, it stopped working and the return of the .getToken () function is the following error:
[messaging / unknown] The operation couldn’t be completed. (com.firebase.iid error 1001.)
I am attentive to the forums, however none of the solutions provided solved my situation or that of others.

Yes, I am using a real device, it is not via emulator.

async getTokenIOS() {
        const authStatus = await messaging().requestPermission();

        if (authStatus) {
            try {
                console.log('Inicio TRYCATCH')

                const token = await messaging().getToken();
                console.log('token: ' + token)

                AsyncStorage.setItem('token', '' + token);
            } catch (err) {
                console.log('err: ' + err)
            }
        }
    }

1001 is defined here and indicates InstanceID wasn't able to receive a device token. Can you implement the APNs token handler and confirm you're getting and APNs token from iOS?

Apparently to get back to work, I had to upload a version for TestFlight. After testing "officially" getToken () also worked again in debug mode (Developer).
The reason is unknown, perhaps some key authorization bug from Apple and Firebase

Thanks for sharing the results of your investigation!


Test 230 and 140 fail consistently

Just the only test case I've seen failing repeatedly across job runs. Need a proper way to fix it.

Test 140 has the same issue.

updated

I believe this is happening because we have a variable shadowing problem in the drift detection block:
https://github.com/weaveworks/tf-controller/blob/eb1bd17016516d061657adf5a0a63e84eeff8de1/controllers/terraform_controller.go#L582-L606
If we want to keep these variables names it should read:
if r.shouldDetectDrift(terraform, revision) {
	var driftDetectionErr error // declared here to avoid shadowing on terraform variable
	terraform, driftDetectionErr = r.detectDrift(ctx, terraform, tfInstance, runnerClient, revision)
...

If we passed a pointer to the detectDrift method then we would also avoid this issue; that would involve changing the code in quite a few areas but might be worth it.
Any thoughts @chanwit?

This is making sense because it's happening only with tests related to the drift detection.


put the service in debug mode

It's almost impossible to figure out chat failures without having debug mode on the service.
cc @patrickxb

It's fine with me, but I guess we can see if it makes it to hard to work with


IOS Client prompts for password / auth half of the time it is opened.

Submit feature requests to http://www.mattermost.org/feature-requests/. File non-security related bugs here in the following format:
Summary
Mattermost client for IOS forgets it's auth when opening every other time it's opened.  Session settings are set to 365 days, session time set to 10 minutes in MM server.  Re-opening the application connects you back most of the time.
Basically every other time it opens it prompts with login.
This is on two different Mattermost instances.
Environment Information

Device Name: iPhone 7
OS Version: IOS 11.4
Mattermost App Version: 1.9.0 (Beta) and 1.9.0 (stable build 112)
Mattermost Server Version:

This happens on two of my servers only recently in the last IOS client updates.

4.10.1 (standalone team edition, Mattermost Auth, CentOS7, Apache reverse proxy)

4.9.1 (Gitlab CE bundled, Gitlab Auth, CentOS7, Apache reverse proxy)

Steps to reproduce
Connect to Mattermost with either the Beta IOS app or stable, 1/2 the time you get prompted for password or authentication.
Expected behavior
IOS app should not prompt for password then work again when closing and opening again.
Observed behavior
Possible fixes
This seems to happen every other time.  Swiping the app closed and running it again connects usually.

Additional note here:  Bouncing my 4.9.1 (Gitlab CE) server this seems to have gone away, same with the 4.10.1 (standalone).  I've also upgraded my 4.10.1 to 5.0.0 to see if that makes a difference.
I didn't see anything in logs but this has happened for multiple people on IOS only.

Hi @sadsfae! Thank you for reporting this.
We just published a v1.9.1 dot release which includes a fix for this issue. Would you like to help upgrade, and then let us know if you still experience the same issue?

@amyblais thanks for the response, I did indeed just see that update and it hasn't occurred since.  I'm closing this issue now.


OS versions supported on Azure to use Nested Virtualization

There is nowhere under the Nested Virtualization documents which OS version of Windows is supported to use Nested Virtualization.
Can we add a pre requisits tab before the example to state that the OS Versions are the following ones:

Windows Server 2016
*Windows Server 2019

-> Not supported for Windows Client versions

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7ffa9c12-4fdc-118a-4e84-624cbcc3f4c8
Version Independent ID: 6c5b1d1f-78a1-2c79-b37d-0367d76269da
Content: How to enable nested virtualization in Azure Virtual Machines - Azure Virtual Machines
Content Source: articles/virtual-machines/windows/nested-virtualization.md
Service: virtual-machines-windows
GitHub Login: @cynthn
Microsoft Alias: cynthn

@pumpkinclarinet
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.We will update you accordingly.

@cynthn
Can you please check and add your comments on this doc update request as applicable

@pumpkinclarinet Thank you for the feedback. I've made some changes to the article that should go live next week.
#sign-off

#please-close


URL in README gives config with old variable names

In the Persist Log Data section of the README, the wget command for downloading graylog.conf gives an older version of the config not compatible with Graylog 2.4 e.g. contains elasticsearch_network_host instead of elasticsearch_hosts. I think the correct URL is:
https://raw.githubusercontent.com/Graylog2/graylog-docker/2.4/config/graylog.conf

@nmertins Good catch. Thanks for reporting this!


test(systest): add fail-fast for systests

Motivation
systests appear to continue execution of all tests regardless if one of them failed.
Description
This change might be debatable, because we might want to keep the configuration as is and avoid the fail-fast. One might argue that it doesn't matter if one test failed or all of them and it is better to just know earlier that the flow failed rather than having to wait for a full hour to get the signal.
If the systests weren't flaky I'd say it might be better to know which of the tests failed (maybe multiple, maybe just one out of all). But I'm not sure that right now this is actually of any use and maybe having a faster workflow is better for everyone.
Example can be seen here: https://github.com/spacemeshos/go-spacemesh/actions/runs/10014040215/job/27682907862 (look for fail: in the logs).
Opening to discussion and happy to close this if there's resistance.
Test Plan
TODO

[ ] Explain motivation or link existing issue(s)
[ ] Test changes and document test plan
[ ] Update documentation as needed
[ ] Update changelog as needed

I'd make it an option which we may set to true in CI but still leave a possibility to run systests in non-failfast mode via make without editing the Makefile

We do use failfast on unit tests as well, so I don't see why we shouldn't do it also for systests.

bors try

bors merge

bors merge

bors merge


add support of python debugger

I really enjoy the experience with streamsync. The tech feel awesome. Only think that keep me back was missing the python debugger. I think it can be done easily by doing a simple change.
I have replace the function _execute_user_code in AppProcess to validate if it works, by the one below.
def _execute_user_code(self) -> None:
  """
  Executes the user code and captures standard output.
  """

  import streamsync
  from contextlib import redirect_stdout
  import io

  streamsyncuserapp = sys.modules.get("streamsyncuserapp")
  if streamsyncuserapp is None:
      raise ValueError("Couldn't find app module (streamsyncuserapp).")

  with redirect_stdout(io.StringIO()) as f:
      script_path = os.path.join(self.app_path, "main.py")
      code_block = compile(open(script_path).read(), script_path, 'exec')
      exec(code_block, streamsyncuserapp.__dict__)

  captured_stdout = f.getvalue()

  if captured_stdout:
      streamsync.initial_state.add_log_entry(
          "info", "Stdout message during initialisation", captured_stdout)

The debugger is triggered

Is there any way to contact you (discord ??? mine is fabien7751) to discusson on how I could make this work properly with your design ?

Hi,
I also have trouble profiling the app code, I think making the debugger work will solve the problem with profiling ?

@PasVegan Could you tell me which tool you are using for profiling ? or do you have a snippet you are using ? I can try to reproduce with the snippet I have changed.

Hi Fabien, thanks for bringing attention to this and finding a solution.
If I understand correctly, the issue was that executing a string doesn't link the reference back to the file so the debugger can't work. By replacing the execute by a real file and not a string, this allows it to work. Can you please confirm my understanding is correct?
Initially, Streamsync allowed you to run code without executing it, but this has been deprecated and hidden. It was confusing. So right now the change you made makes sense. I'd like to clean up the AppRunner a bit to remove the references to "run_code" and implement this. I'm guessing this will also improve the stack traces which currently read e.g. " line 181".
If you want, feel free to submit a PR against the "dev" branch with this and I'll do a bit of cleanup afterwards.
We do have a very new Discord server, I see you that found it!

Yes, that's something like that. The compile function return a data structure, blockcode, that will maintains the binding during exec invocation. We can see that as the sourcemap in js.
I will prepare a PR.

@PasVegan Could you tell me which tool you are using for profiling ? or do you have a snippet you are using ? I can try to reproduce with the snippet I have changed.

I use cProfile and yappi

I did a test by doing inline profiling on the function that runs on the Timer window of the demo application. It works with the current implementation.
def handle_timer_tick(state: StreamsyncState):
    with cProfile.Profile() as pr:
        df = state["random_df"]

        for i in range(5):
            df[f'pgcf_{i+1}'] = np.around(np.random.rand(10, 1), decimals=9)
        state["random_df"] = df

    pr.print_stats()

cprofile invoked directly by pycharm does not capture the application code, even with my implementation. Yappi doesn't seem to either.

I think the problem is that yappi and cprofile do not support the profiling of a subprocess started by the main application.
py-spy allows you to do this type of profiling and represents the results in the form of a flamegraph.
py-spy record -s streamsync edit apps/hello


[Godot 4] Fix Popup Bugs

Incrementally removing bugs from the godot4 branch:

prevents polling for input actions in Game.cs when a popup is visible
fixes behaviour when the build city popup is open and esc. is pressed: before it would close the popup and show the exit game popup at the same time. now, the first esc. press will only close the current popup

discovered https://github.com/C7-Game/Prototype/issues/424 while cleaning up this change

Getting back into this and not very familiar with all the SDKs involved, but the code changes still make sense to me.

Reviewed code, the changes make sense, and should prevent the multi-popup issue generally.  Approved and merging.


Add ability to customize shelf/book/chapter names

My organization would love if we were able to change the name of shelves to "Departments", books to "Teams", etc. Would this be a feature which you would consider adding?

Hi @CorruptComputer
Thank you for the feature request. The fundamental feature requested here is already open under #406 therefore I'm going to close this to cut down on duplicates. Please add a thumbs-up on the main issue #406 to show your support.


Remove addition related code from SGVector

The first commit passes all tests.
However for the second commit, some unit tests are failing and I am unable to find out why.

It seems like you delete the GPL submodule and undid some changes on data?

It seems like you delete the GPL submodule and undid some changes on data?

That was intentional. Sorry, I'm going to undo the changes and push again.

Yes, I undid those changes. Is there something wrong with the code? the unit tests are still failing.

@gf712 Any suggestions as to what I should change?

This looks ok from my side, but CI seems not happy?
@Hephaestus12 would be good to make this one happen some time soon as well. It would count as a meta-example PR  ...


Draco mesh/point compression extension for glTF

See https://github.com/KhronosGroup/glTF/pull/874
@fanzhanggoogle if you are able to contribute this or start a prototype, it would be very much appreciated.  Here's some tips:

glTF loader/renderer is here: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/Model.js
Unit tests are here: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Specs/Scene/ModelSpec.js
glTF example app is here: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Apps/Sandcastle/gallery/3D Models.html
General contributor guide is here: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/CONTRIBUTING.md#opening-a-pull-request

Let us know if you need more help.
Part of #3241, #4678, and https://github.com/AnalyticalGraphicsInc/3d-tiles/issues/188

Also, instead of branching off of master, use this branch that is being updated to support glTF 2.0 (and still 1.0 by converting to 2.0 on the fly): https://github.com/AnalyticalGraphicsInc/cesium/pull/4808

That sounds a good plan to validate Draco extension and a good way to promo it :)
I'm working COLLADATOGLTF2.0 + Draco extension now. Will start this after that's done.

Sounds great @fanzhanggoogle!  Ping @lasalvavida if you have any questions about the COLLADA2GLTF code.

Draco sample models: https://github.com/KhronosGroup/glTF-Sample-Models/pull/116

@lilleyse can you please connect with @AnimatedRNG to come up with a detailed Draco roadmap and to show him the relevant parts of Cesium's glTF loading code?  High-level roadmap is something like:

[ ] Implement glTF Draco extension loading in Cesium using existing sample models
[ ] Profile.  Move Draco decompression to a web worker.  Profile.  Maybe improve web worker architecture.  Profile.  #2655, #1487
[ ] Update some sample models used in Sandcastle to be Draco compressed
[ ] Tweaks to 3D Tiles' b3dm and i3dm tile format specs for Draco extension.  Add unit tests; 3D Tiles with Draco should just work once Cesium's glTF loader supports it
[ ] Add Draco to 3D Tiles pnts tile format: update the Cesium loader and spec
[ ] Perhaps help finish Draco in gltf-pipeline: https://github.com/fanzhanggoogle/gltf-pipeline/tree/2.0_mesh_compression
[ ] Potentially update cesiumjs.org/convertmodel.html
[ ] Potentially contribute to 3D Tiling Pipeline

Please open incremental pull requests into the draco-master branch.
Resources

glTF extension spec: https://github.com/KhronosGroup/glTF/pull/874
glTF sample models using Draco compression: https://github.com/KhronosGroup/glTF-Sample-Models/pull/116
BabylonJS glTF Draco loader by @bghgary: babylon.dracoCompression.ts and KHR_draco_mesh_compression.ts
Three.js glTF Draco loader by @ondys and @fanzhanggoogle: DRACOLoader.js
Draco repo (use version 1.1.0): https://github.com/google/draco
3D Tiles spec
gltf-pipeline 2.0 branch with Draco compression by @fanzhanggoogle: https://github.com/fanzhanggoogle/gltf-pipeline/tree/2.0_mesh_compression

@AnimatedRNG - here's some notes about glTF and some ideas for getting Draco support into Cesium:
The general structure for a glTF is:
scene -> node -> mesh -> primitive -> attributes -> accessors -> buffer view -> buffer
A scene contains a list of nodes. A node contain a model matrix and a reference to a mesh. A mesh contains a list of primitives, where each primitive is defined by a material, vertex attributes, and indices. Each attribute points to an accessor, which is an object that defines how to interpret buffer data for that vertex attribute (maps to the concept of glVertexAttribPointer). The accessor points to a buffer view which is some range within a buffer.
In Cesium, a DrawCommand is created for each primitive.
The Draco extension is also defined per-primitive. When the extension is present, ignore any data that might be pointed to by the primitive's attributes and indices. Instead the attribute and indices are contained within a chunk of data referenced in the extension's bufferView property. After decoding the compressed chunk we can get the final vertex attributes and indices for the mesh.
I think the easiest approach for getting this into Cesium will be:
Add a function after: processPbrMetallicRoughness(this.gltf, options); called parseDraco(this.gltf)
That function should check if the extension exists. If it does, loop over each mesh and each of its primitives (use ForEach.mesh and ForEach.meshPrimitive). When the extension is encountered in a primitive, run the third party Draco decoder on the bufferView. It will probably want a typed array of the data, so give it gltf.bufferViews[bufferView].extras._pipeline.source (this is where gltf-pipeline will have stored a typed array of the buffer view's contents). The decoder will probably return a typed array containing the decompressed index and vertex data. We are now done with the compressed bufferView, so it would be good to delete it since we don't want it parsed in parseBufferViews. Just remove the buffer view from the bufferViews section of the glTF.
Now edit the glTF so that everything points to the decoded data correctly. First add a new buffer for the decoded data to gltf.buffers. Set the buffer's extras._pipeline.source to the decoded data (this is a bit unclean, but it is the best approach so that addBuffersToLoadResources right below works). Then add a bufferView for each of the the decoded vertex attributes and for the decoded indices. Each of these will point to the buffer that was just created. Now for every accessor referenced by the primitive that used the Draco extension, set its bufferView property to the new buffer view created for it. With all this in place Cesium should be able to load everything correctly.
This approach could also be its own self-contained stage in gltf-pipeline. But for now keeping the code in Cesium is fine.

Add to https://github.com/AnalyticalGraphicsInc/cesium/issues/5120#issuecomment-330348890:

[ ] To save GPU memory, evaluate recompressing with (or with something like) WEB3D_quantized_attributes and oct-encoded normals and textures

@lilleyse as you sure about your approach?  It makes sense for gltf-pipeline, but we should not make a habit of doing a lot of glTF JSON object modification as part of our runtime loading.  Instead, we should strive to get data into Cesium's data structures - even intermediate data structures that are used to aid loading - and then process.  Don't you agree?  Is that hard in this case?  If so, why?

I see your point. It shouldn't be too hard to use intermediate data structures instead.

We are now done with the compressed bufferView, so it would be good to delete it since we don't want it parsed in parseBufferViews. Just remove the buffer view from the bufferViews section of the glTF.

After looking closer I noticed this step isn't needed. The draco buffer view target will not be marked as ARRAY_BUFFER so it will not be uploaded to the GPU like I thought. So ignore this.

Now edit the glTF so that everything points to the decoded data correctly.

Instead of this approach, we can probably circumvent most of the gltf asynchronous loading code and just create vertex and index buffers directly from the decoded data. Look at the createVertexBuffer/createIndexBuffer function. You will probably want something similar that takes a typedArray instead of a bufferViewId. The buffers should still be added to model._rendererResources.buffers, its key being model._rendererResources.buffers.length just so it doesn't overwrite anything.
The last step is making sure createVertexArrays works correctly. If an accessor is one of the Draco accessors, it will not have a bufferView, byteOffset, or byteStride which are required. That information will need to be stored somewhere (not on the glTF like I had suggested) and fetched in createVertexArrays.
@AnimatedRNG let me know if anything is unclear. There may be some edge cases I haven't forseen.

Having just recently added morph targets to my glTF generation, I'm suddenly noticing that they're absent from Draco considerations. It's likely out of scope and in any case too late to add this to the initial release of the extension, but may I propose it for future versions or add-on extensions?
Sparse accessors salvage morph targets from extreme bloat, but they're still likely to take up a disproportionate amount of space when all the other static geometry has been compressed.
As a corollary, I know the Draco team is at least thinking about the temporaral dimensions viz. animations, and so it's worth noticing here that the 'weights' target for animations is likely very compressible.

Updated the task list. Extension loading in Cesium added in https://github.com/AnalyticalGraphicsInc/cesium/pull/6191


Mark agent_test tests skipped, as they are failing in CircleCI.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: wattli
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pkg/OWNERS [wattli]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ozevren: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
42cbed308476f8d7bf88e9faf253ca95b1c272d4
link
/test e2e-bookInfo-envoyv2-v1alpha3

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


Support for defaultLocale at runtime/nuxtRuntimeConfig in combination with a Docker Container

We are currently using one Docker image and are now trying to use that very same container to deploy to multiple domains.
Locales - en_US, nl_NL, pl_PL, de_DE and so on.
The problem is that the Docker image is being built with the mandatory defaultLocale which is part of the IndexPage.vue.
This means we do have one Docker image where the defaultLocale is already set (fixed at build time) to (for example) en_US but on the Netherlands (nl_NL) domain when I access the homepage it results in loading the content in en_US.
We don't want to build multiple Docker containers for each domain as they will consume a lot of space.
With v7.15.1 the support to override the defaultLocale has been added but I assume this only refers to the build time.
Please correct me if I am wrong but I found no way to get this working on my side and the documentation for the new FSXA_LOCALE has not been updated.

Hey Samo,
Thank you for sharing this issue with us.
In our tests we were able to set the FSXA_LOCALE at buildtime of a dockerimage. Meaning, you would need a dockerimage for a deployment each. So our tests confirm your issue with the nuxt-module. While this is fine for most of our customers we understand that it won't fit your requirments.
If creating CI plans for each deployment is no viable solution for you, it sounds like a good feature request, that you can send to our Customer Support team.
sincerely,
Nico

Hi Nico,
Creating CI plans for each rollout is not a viable solution.
With around 30 projects (steadily increasing in the future) the storage could cause an issue for us.
But we asked the Support to create a Feature Request for us.
Greetings,
Sebastian

Hi Nico,
we currently use a workaround for the issue and check if path is "/" (which means homepage directly without locale supplied).
The workaround works by adding code in a middleware to redirect the homepage using the fsxa navigation and the FSXA_LOCALE which we set during startup (for each project individually).
const locale : string = process.env.FSXA_LOCALE || ''
if (locale.length !== 5) return '' // assuming locale is made up like this: en_US e.g.

const navigationResponse : NavigationData | null = await api.fetchNavigation({ locale, initialPath: '/' })
return navigationResponse?.pages.index || ''

Greetings,
Sebastian


Missing class org.commonmark.ext.gfm.strikethrough.Strikethrough

Markwon version: 4.6.2

Please specify expected/actual behavior

Warning shown for release build type
Missing class org.commonmark.ext.gfm.strikethrough.Strikethrough (referenced from: java.lang.Object io.noties.markwon.html.tag.StrikeHandler.getMarkdownSpans(io.noties.markwon.MarkwonVisitor))

Please specify conditions/steps to reproduce (layout, code, markdown used, etc)

Running gradle task to build the apps with release build types

Hello @mochadwi ,
this warning is shown by HTML plugin when you have no strike-through dependency added. HTML plugin by default tries to load it first and only after that fallbacks to own implementation. There is no action needed if you are satisfied with the result

I'd like to reopen this issue, because of some of the breaking changes made on Android Gradle Plugin 8.0.
Right now, the previous warning is treated as error if a rule for a missing class does not exist on main project or imported library. Android Gradle Plugin 8.0 Release Notes: Enforced build option values

HTML plugin by default tries to load it first and only after that fallbacks to own implementation.

If this still applies, it seems that it's just needed to add this rule for the library:
-dontwarn org.commonmark.ext.gfm.strikethrough.Strikethrough
The setting for gradle.properties to opt-out this new behavior is shown on the screenshot above, but maybe this shouldn't be needed.


API Extensions

There are multiple attempts to add Android specific API extensions to the MV Android Client.

Google Play Games Functionality - Achievements https://github.com/AltimitSystems/mv-android-client/pull/1
https://github.com/AltimitSystems/mv-android-client/tree/android-api

My thoughts right now is that it would be best to create a mechanism that makes it simpler and clearer on how to add API extensions to the MV Android Client.

The intention for the android-api is to start the (long and painful) journey of implementing node.js API equivalents in Android. I expect this would be a standard API for mv-android-client, so I will modify this branch to create a standard API Extensions mechanism, so features such as Google Play Services can be added in a more modular way.
Perhaps what we can do is make it so these API Extensions are their own libraries (https://developer.android.com/studio/projects/android-library.html) that come bundled with the MV Android Client, but they need to be added to the base project and activated for them to be included in the build itself. The app build.gradle file could be used as a way for listing out what API Extensions should be included in the project.
This moves potentially large dependencies such as Google Play Services out of the main project and also gives a clear, clean place to put all this code. The Javascript binding could also be stored in this library project.
The MV Android Client base code could detect the requested extensions, then add them through the use of reflection (to avoid the need to add imports for each of the libraries). The extensions would be given a context to use (from the activity, so extensions can retrieve the calling activity if desired) and they could optionally provide some Javascript code to run (similar to a standard MV Plugin) and a Javascript interface to bind (again, optional).
We would need to forward some Activity methods, such as onActivityResult for Google Play Services.

Thoughts, please?

At the very least, yeah, moving things off into their own libraries sounds like a good idea. I would, however, be a bit more interested in seeing the reflection idea go somewhere if it makes things easier in the long run.
Could you possibly explain more about the providing Js/JsInterface bit at the end there? I just want to make sure I'm on the same page with that as what I'm thinking is that the extention dev can provide a plugin that essentially acts as a bridge for the interfaces within the app but keeps that kind of config within MV and keeps editing of the android studio project minimal

The JavascriptInterface system would be a mechanism for the extension to say "here's my JavascriptInterfaces, here's the names you should give them" and then the MV Android Client binds them when it needs to.
Perhaps the extensions will have a method that returns a mapping of JavascriptInterface names and objects - so the MV Android Client would call extension.getJavascriptInterfaces()

Later on, the MV Android Client will then query the loaded extensions for any Javascript code that needs to be ran - perhaps this is code that adds JS classes that utilise the JavascriptInterfaces.
There's an example of this in the current work done on the Android API branch: https://github.com/AltimitSystems/mv-android-client/blob/6601e0dc8409fc46f357d19ac314deed3bde015d/app/src/main/res/values/values_internal.xml#L43 - this Javascript wraps the JavascriptInterface methods in a style that mimics the Node.JS require function. The JavascriptInterface is bound as "__a_client" earlier on.
Ideally, this Javascript code would not be in XML files like this. I think it should be moved out into .JS files, to make developing extensions a little easier. This would work perfectly fine (no qualms) if extensions were handled as their own libraries, so I think that would be the route to go down.
Perhaps the Javascript code would be queried from the Javascript interface objects themselves - javascriptInterface.getJavascript() or maybe the extension could also provide this method as extension.getJavascript() - or the extension could provide zero Javascript at all and its entire behaviour is handled by the names provided by the JavascriptInterface mapping.
The Javascript could just package up the JavascriptInterface into a handy library, to be used by MV Plugins, or it could be an MV Plugin itself - adding the Android functionality into the MV game (although I imagine this would be a bad idea as it would introduce Plugin compatibility issues - we should probably leave Plugin development for Plugin authors and only provide library interfaces for accessing Android features).

If you have your own ideas on how this mechanism can be designed, then I'd be glad to hear them. These are all ideas at the moment, no concrete plans (but I may start implementing some of these ideas to get a feel of their effectiveness).

Yeah, I'll agree that Js shouldn't be floating around in some XML; I'm already having a bit of a fit just imagining having to constaly format things like \' just to not break things.
I don't think us providing MV plugins would break things or bring compatability issues with anything as we'd only be interfacing with our stuff but, yeah, I guess leaving it to people who'd know what they're doing and the do's and don'ts would better ensure it doesn't happen. I agree that, at the very least, extensions should provide their own interfaces (and possibly documentation of some kind) for the authors to use
What you've got going in that XML sample looks fine, to be honest, and that looks the way to go. I do have a feeling that offloading stuff into Js files would mean having to do some file IO on the extension side to load the scripts in and then parse them before the webview launches (unless I'm wrong). If that's the case, then a standard location for extension Js files should probably be established so we're not having to worry about special file paths nor are we cluttering things up on the system.

When I say breaking Plugin compatibility, I am imagining a scenario where - as a hypothetical example - we add Google Sign In capability and create a Plugin that adds this as a menu option in the Scene_Title - however the end user has decided to use a custom Scene_Title implementation that does not conform to the expected vanilla implementation (which is entirely fair on their part), and thus compatibility is broken.
By drawing a line in the sand and saying "we provide the JS library, Plugin authors write the implementation" we're moving the responsibility of maintaining Plugin compatibility to 'someone else'. It may be slightly frustrating for users to require an additional Plugin to access Android specific features, but at that point it is no longer our problem to solve.

The WebView will load as normal, the RPG Maker engine will load, then the JS is injected.
The JS code would be read into memory before the WebView has loaded, just to make sure it's ready to be injected and won't cause a stall at a more annoying time.
I don't think a standard location is actually needed. If the extension simply provides JS source code, then the extension could load that code from wherever it wants - be it a file, an XML string, a Java String or a JS file pulled from an online server.
That being said, for the sake of consistency I think all the bundled extensions should store their JS sources in the same way. Probably in the individual extension res/raw/ folder.

I'll get to modifying the android-api branch today to implement some of these ideas we've discussed.

I've made a preliminary version of the Extension API:
https://github.com/AltimitSystems/mv-android-client/tree/android-api
This comes with an example extension "Android API" which adds requireAndroid.
I think all the built-in extensions should have "lib" in their starting name.
There are some "gotchas" to look out for:

Library Module name must be the same as the last component of the package name (see how the package name for libandroidapi ends)
Extensions must be under the systems.altimit package name

It should be possible to remove these limitations by adding some extra complexity (users would need to enter in two strings for an Extension, the module name and package name). I haven't bothered with this yet as this is preliminary.
Extensions must have a top-level class named "Extension" - this is the mechanism that will register it with the MV Android Client.
The signature of this class is as such:
public class Extension {
    public Extension(Context context) {
    }

    public Map<String, Object> getJavascriptInterfaces() {
        ...
    }

    public String[] getJavascriptSources() {
        ...
    }

    public int[] getRequestCodes() {
        ...
    }

    public void onActivityResult(int requestCode, int resultCode, Intent data) {
        ...
    }
}

These methods are all optional, however onActivityResult depends on the request code being in the array returned by getRequestCodes.
The mapping returned by getJavascriptInterfaces is the name of the Javascript interface + the object itself. This is used literally as: addJavascriptInterface( mapping.key, mapping.value )
The String array returned by getJavascriptSources is executed sequentially - so make sure your dependencies are in the right order.
The extension can then be activated by adding it to the list of extensions in the build.gradle (app) file:
/**
 * Extensions
 */
def EXTENSIONS = [ 'libandroidapi', 'libawesome' ]

This example inserts the dependencies into gradle as :libandroidapi and :libawesome and adds systems.altimit.libandroidapi.Extension and systems.altimit.libawesome.Extension as Extension searches.
The way Javascript source files are handled is decided by the extension, however I think the official extensions should store them all in res/raw/ for consistency.

Sorry for the wait, been busy this weekend
I think I slightly easier way to go about this would to use an Interface that all extensions must implement so you can just call methods directly instead of using getMethod() as all implementations must have those methods defined in one way or another. The methods that aren't needed can still be left blank in the extension.
This might also mean no longer having to make use of
 public boolean respondsToRequestCode(int activityRequestCode)

as either the extension makes use of the requestCode (with its own switch-case or set of if-statements on its end if it uses multiple) or wont and does nothing with it anyways; as it stands it would just be adding another set of if-statements on top of others should this idea go through.
The classes could be loaded in a similar fashion as this StackOverflow answer provides and then perhaps just have the classes take on their library names (ie libandroidapi would rest in libandroidapi.java/.class). That second bit is just personal preference as I'd rather not have a bunch of Extension.java/.class floating about in various packages but ends up getting the same result anyways.
So I think this may speed up execution as we're no longer having to do a bunch of method lookups as the ones we want are guaranteed to exist if we force an Interface or Abstract Class and the only exception handling we'd most likely have to worry about is where you load the class in from the BuildConfig. We just need all extensions to extend something like
public abstract AbstractExtention {
    public AbstractExtention(Context context) {
        ...
    }

    /* Maybe use this to init instead of constructor */
    public void initContext(Context context) {
        ...
    }

    /* Perhaps keep the context in this parent class and use this method for the children */
    protected final Context getParentContext() {
        ...
    }

    public abstract Map<String, Object> getJavascriptInterfaces() {
        ...
    }

    public abstract String[] getJavascriptSources() {
        ...
    }

    public abstract int[] getRequestCodes() {
        ...
    }

    public abstract void onActivityResult(int requestCode, int resultCode, Intent data) {
        ...
    }
}

and we'd be good to go. Idk, just some thoughts to help streamline things on our end

My original attempt was with interfaces, however that meant creating an extra dependency project between the client and the extensions, otherwise there'd be a cyclic dependency.
I also tried with abstract classes to allow some of the methods to be optional, which then led to the current implementation.
I wanted to avoid adding another module to the project, but I will make a new version with the API library dependency and see how that feels.
Personally, I don't mind the use of reflection in the client, so long as the extension developer does not need to use it.

Personally, I think it's alright if the extensions have a dependency from the main app as, after all, they're extending from it, but yeah that's up to you; either one works in the end and the extension dev is gonna be calling the same methods the same way anyways. I was just looking at code and thought 'hey it's basically  but with some extra', didn't know it had evolved from straight from that.
Part of me also prefers force having the method and it do nothing (just returns or w/e) vs ignoring thrown exceptions, but that could also be my bad habit of premature optimization coming back out (which could probably be said about a lot of recommendations/ideas I come up with) since not having it in try-catches would really only be slightly faster in the case of this app while creating a bit of coupling where there currently isnt any
I also realized, while trying to sleep, that having the needed classes called Extension (as per how you load them in) is going to be the way to go. Well, unless you feel like figuring out regular expressions/regex to pull, say, LibAndroidApi from libandroidapi but I also have no idea if that'll even work without creating a bunch of problems/making a mess
/end_rambling

I have one idea that avoids the classes being named Extension (and being top-level). The app build.gradle extensions list is not very flexible and has those caveats I mentioned in an earlier post above - the solution I have in mind for these caveats is to force the end user to actually write out the package name and the module name as pairs in the extension list - this could be changed so rather than the package name, the full class name is required.
def EXTENSIONS = [
    ['libandroidapi', 'systems.altimit.libandroidapi.Extension'],
    ['libawesome', 'package.custom.awesome.AwesomeExt']
]

Certainly a bit more typing required, more stuff to potentially get messed up by the end user, but it removes the caveats and provides a way to avoid naming the classes Extension.
The reflection API isn't good enough to search packages for classes; that was my other idea to have the package search for a classes with a particular annotation (from the shared library API). Not going to happen.
I wasn't concerned about performance as I made sure the reflection is mostly used to query on startup. The only area where performance of reflection is potentially a problem is the onActivityResult call, however you have other - more serious - performance issues if that is getting called multiple times in a short time-frame. These try blocks are also within the areas where the code is only called once (or is onActivityResult related).
I once again like the idea of using interfaces because it conforms to what Java developers expect. Using reflection this way is usually done by massive 3rd party libraries inside their black-box (the big Android 3rd party libs do this), not by a core run-time where you can modify the source code directly (this project). Actually, by using interfaces we can call the methods directly rather than cache their result (the current implementation) - so we could use that performance gain for something.

The extensions won't have a dependency on the main app as that causes a cyclic dependency issue (main app depends on extensions, which each depend on the main app). The main app and extensions will have to depend on a separate API module - this is what I wanted to avoid but I think I was just trying to oversimplify.
The API module will probably be called something like clientapi. So we have app depending on clientapi and any extensions, then each extension also depending on clientapi.

I did also consider going about this via a more "Androidy" way - with Services and Broadcasts - but that requires a heck of a lot more code for writing Extensions. I believe the reflection system we have is far nicer to deal with.

I've gone ahead and made the changes discussed. There is now a clientapi module, that Extensions must depend on to be recognised by the run-time.
Extensions must extend the abstract class "AbstractExtension". There is a constructor that expects a non-null context, this is to force implementations to create a constructor that expects a valid context - which is what reflection expects. onActivityResult is an optional override, however getJavascriptInterfaces and getJavascriptSources are now mandatory. getRequestCodes is completely removed - "don't be a dolt: return early from onActivityResult".
The app build.gradle extensions list now looks like this:
/**
 * Extensions
 */
def EXTENSIONS = [
        [ module: 'libandroidapi', extension: 'systems.altimit.libandroidapi.AndroidAPI' ],
        [ module: 'libawesome', extension: 'package.custom.awesome.AwesomeExt' ],
]

Hopefully it's obvious enough on how it should be used. If any extensions are included, then a dependency for the clientapi project is automagically added to the main app.

On a side note, JavascriptInterface is very slow to call, I've had issues with it being incredibly slow before, so I've added a really dumb key mapping system to store the results of the example libandroidapi calls. This should probably be changed to a smarter caching system that cleans itself up when it needs to.
Extension developers should avoid JavascriptInterface calls as much as possible (yeah that means everyone needs to write more Javascript).

Would it be possible for the DEFs (or something) that hold lib name/package-dirs to be in the extension build.gradles and it still be read by the main app? Basically, a way to where the extension dev just has to worry about adding the name/package-dir to their build.gradle and not have to worry about what's in others? Googling leads me to believe we could just call something like
EXTENSIONS.add(["libsausage", "butcher.shop.meatpatties.Sausage"])

in our gradle files, but I'd like to be sure
Beyond that, I dont think I've any other questions/concerns as far as where the codebase is concerned

Yeah, even looking at Messengers, which seem to be the easiest way to implement a Bound Service, it still looks like a good bit of extra work to get it set up and going. It also doesn't keep things as decoupled as they currently are as something like this
public void sayHello(View v) {
        if (!mBound) return;
        // Create and send a message to the service, using a supported 'what' value
        Message msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);
        try {
            mService.send(msg);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }

would probably need one of the following done

require either importing the extension in the main (hell on earth)
the main app having to hold more data that could be ever expanding as more expansions are added (also bad because now we might have data that doesn't get used depending on what extensions are active)
the extension + main app importing some class holding the enum (still has the same problem as the one before and introduces another coupling point, which the current implementation pretty much avoids entirely)
or just passing around raw integers (magic numbers, but at least no extra data nor coupling to extension classes).

None of which I find appealing. I also don't have much of an idea on how you would even load them in unless you'd also be able to use the existing DEF for that one
The upside, though? Being able to send Objects down to the extension should it be desired (maybe as a way of delivering any needed data)

I like the idea of the libraries registering their classes with the list of EXTENSIONS automatically when the dependency is added, that would simplify things a lot. I'll investigate if this is possible, my first thoughts are "no" because gradle is pretty restrictive when it comes to cross module communication (which I thoroughly investigated when attempting to add CrossWalk compatibility - hopefully I missed something).
The problem with CrossWalk's JavascriptInterface annotation is that supporting it means adding crosswalk as a dependency for extensions, which means a massive amount of bloat added to APKs - even if they don't use CrossWalk. If possible, I'd have the clientapi be the module that holds the webview/crosswalk switch so libs and main app can detect if CrossWalk is available and switch their build files accordingly.
I really do miss compile-time macros right now.

The caching requirement is not on the Java side of the code, it's on the Javascript side of the code, so no Java library will help here. I already investigated caching on Java and it didn't help at all - it's definitely the JavascriptInterface bridge that causes the big performance hit, which makes sense as it needs to halt the WebView entirely while it does whatever it needs to in single-threaded Java.

I'll give the def idea another shot with extensions, if I'm unsuccessful then what we have in the current android-api tree is what we'll likely stick with.

Alrighty, I investigated a bit more. I'm confident there's not going to be an easy way to have the EXTENSIONS def modified by the libraries when they are included in the app module. Global variables work nicely on build, but for some reason as soon as you launch/debug/whatever gradle will change the build order and ruin everything...Soooo close to it working, yet gradle just doesn't want to play ball.
I also tested out manually having CrossWalk switches for the libs (which involves a load of bloat written in the lib gradle files), which actually worked out quite well (libs will swap flavors to whatever is selected on the parent - if there is a matching name) - that is, up until the JavascriptInterface annotations were needed. There's no way to inherit an annotation, so I can't make a shared annotation that Extension methods could use. Basically; CrossWalk must be added as a dependency. It's definitely a thing that would be easily solved by C style compile time macros...

Ah man, well RIP in peace.

Android API branch is now merged into master.

Alrighty, I'll get to hammerin

Yes I did expect something like a requirement for onResume/onPause/onStart/onStop to crop up eventually. Could you please implement all three of these callbacks in the same way that onActivityResult is implemented? I think having all available as optional overrides is ideal. Perhaps may be worth having onDestroy & onRestart too.
I don't think a lib should depend on another lib if it can be avoided. Let Plugin developers handle dependency woes. Implement storage in a way that makes sense for your system. It is my understanding that Google Play Achievements handles offline achievements itself, so you shouldn't need to worry about keeping an offline ledger JSON; you should be able to query achievement state regardless of connectivity - AchievementsClient.load gets a buffer of all the achievements and their states for the current player, you should be able to avoid storage with this.

Alrighty, I'll get the rest of those things implemented.
And I wasn't sure if GPlay handled it on it's own as the examples they keep pointing me towards has a sort of 'outbox' implemented to handle it. Bleh, I'll let it be and see what issues crop up, if any, but will take a look at that load method you mention

Yes that looks like an acceptable way for the extension to be laid out.
I believe gradle allows having dangling commas in array items, so you can move the commas to the end of the entries, rather than after the comment (makes more sense in English grammar).
def EXTENSIONS = [
    [ module: 'libandroidapi', extension: 'systems.altimit.libandroidapi.AndroidAPI' ],
    // [ module: 'libgoogleplay', extension: 'systems.altimit.libgoogleplay.GooglePlay' ],
]

I would have expected Google to store achievements on the device immediately when they're unlocked and synchronise in its own time, rather than depend on the game not being closed by the user. Even when I type that out it still sounds like the behaviour that should logically be happening.
Do the Google official guides mention anything about having to write local achievement storage? To me it sounds weird to require a local storage format that duplicates the data that the Google account should already be handling.
I also spot what looks like a small attempt at cloud save files? now this would be a great feature, however it may be worth doing what I did with the local Android file system storage in the Android API and just make it generic "cloud storage" and let Plugin authors implement it for save files.
Very excited by what you're adding here.

I was not aware Gradle could do that.. that certainly makes things cleaner
The google account handles it, yes, but only if the player has signed in or has signed in before losing network connectivity. The user not being signed in is where I can't seem to find anything. If they haven't signed in at least once, though, then none of it matters; nothing will be populated on that end (and shows me that I forgot to check and see if my caches are empty before querying their contents.. whoops)
The Google official stuff doesn't mention anything about handling things if a user has signed out, either, but some (read: one or two) SO answers say that the way it's currently implemented (via 'cacheAchievements' method) is more-or-less how it should be kept until the user can sign in again. It goes comletely dark, however, on what should be done if the user doesn't sign back in and the app is killed which is why I feel falling back to a local file would be a safty net of sorts.
TL;DR It's basically for those who signed in at least once before signing out, as then GPlay doesn't keep track of stuff for them at that point I think.. Doesn't quite say.
And yeah, I'm poking at cloud saves. I haven't gone through the Google stuff completely on that one so I can't say what'd be required on that end outside of permissions. I don't think I can quite genericize Snapshots, though, as it's a part of GPlay used specifically for game saves. Though I can probably have a method that just hands of a list/array of Snapshot objects for an author to work with as far as working them into a native MV UI as it also has a 'load' method

@Lakaroth please create a new issue with your problem

@felixjones do it.
Sorry it's my first post on github

I've made the executive decision to remove the extensions system entirely. Extensions should now be handled by their own AAR libraries by Plugin authors. 741198303a7f77037d9031a82cc9e228687448f9
Any new mechanism for similar behaviour should be made as a new issue of discussion.


Return non-zero exit code and do not create empty file for wal-fetch

The same problem as here https://github.com/wal-e/wal-e/pull/144
I just copy this part from wal_prefetch method.
When you recovery from backup and use standby_mode=off in recovery.conf, it waits to non zero exit code to move recovery.conf to recovery.done and start cluster.
But if wal-e creates zero lenght wal file, pg just shutdown with error.

Sorry, this doesn`t help
wal_e.blobstore.s3.s3_util WARNING  MSG: could no longer locate object while performing wal restore
DETAIL: The absolute URI that could not be located is s3://my-db-backups/db03.myhost.com/wal_005/00000001000000120000005F.lzo.
HINT: This can be normal when Postgres is trying to detect what timelines are available during restoration.
STRUCTURED: time=2015-03-06T13:08:49.191749-00 pid=27624
Failed to prefetch<PHONE_NUMBER>0000120000005F
2015-03-06 13:08:49 UTC FATAL:  archive file "00000001000000120000005F" has wrong size: 0 instead of 16777216


refactor(occupancy_grid_map): add occupancy_grid_map method/param var to launcher

add occupancy_grid_map method/param var to launcher and use those ones in autoware_launch by default
Description
Just like other packages I changed the auoware_launch to refer to launcher param file.
Related links
universe PR: https://github.com/autowarefoundation/autoware.universe/pull/3393
Tests performed
Psim works as before.
Interface changes
None
Effects on system behavior
None
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[X] I've confirmed the contribution guidelines.
[X] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[X] The PR follows the pull request guidelines.
[X] The PR has been properly tested.
[X] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[X] There are no open discussions or they are tracked via tickets.
[X] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

Lsim also worked 👍


cannot delete user "Associated data exists, please delete them first"

When trying to delete a user, the error message "Associated data exists, please delete them first" appears. All charts and dashboards created by that account have been deleted. I have also set the user as inactive and deleted its role setting. I am able to edit the user but not delete it.
I found the following similar issue which was marked as stale with no response: https://github.com/apache/superset/issues/8752
Expected results
Successful deletion of a user
Actual results
"Associated data exists, please delete them first" error message
Logs when navigating to user list and trying to delete user (domain has been replaced with deploymentlink.com):
<IP_ADDRESS> - - [25/Feb/2021:19:48:28 +0000] "GET /users/list/ HTTP/1.1" 200 26741 "deploymentlink.com/superset/welcome" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36"
<IP_ADDRESS> - - [25/Feb/2021:19:48:34 +0000] "POST /users/delete/3 HTTP/1.1" 302 299 "deploymentlink.com/users/list" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36"
<IP_ADDRESS> - - [25/Feb/2021:19:48:34 +0000] "GET /users/list/ HTTP/1.1" 200 26786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36"
Screenshots

How to reproduce the bug

Go to 'List Users'
Navigate to user row
Click on 'Delete' icon
See error

Environment
(please complete the following information):

superset version: superset version: Superset 0.999.0dev
python version: python --version: 3.7.9
node.js version: node -v: couldn't find

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
none

Any update?

no updates from my end

Thanks for the quick reply @maddyobrienjones
I encountered the same error a couple of days ago. I don't know what I will do because I can't remove the user although all charts and dashboards created by that user have been deleted.
By the way, the reason that I want for the user removal is the following situation.

I don't know again what I will do and I wanted to delete&add the user again. It will be greatly appreciated if anyone knows a solution to this strange situation.

My second problem is solved by @nytai He told me that any user who wants to add a chart to any dashboard may have to add himself/herself as an owner of the dashboard.
The other error 'Associated data exists, please delete them first' is still ongoing.

Any update here?

no updates from me. this is low priority in my backlog of tasks.

I think there's also a logs table. Tbh deleting a user if quite difficult since cascade hasn't been set on a lot of the foreign key relationships, so you’ll have to find them and delete the records manually.
If possible, just mark the user as inactive and change all the fields that might cause issues with unique constraints if the same user is trying to sign up again

Also this stackoverflow post mentions a query you can run to find all the foreign key constraints on ab_users.id

I tried to delete a user I just made, and it doesn't work giving this error. How does a new user own anything, and how can I find and delete it?

Same problem here. Really need something to be able to delete a user

I think there's also a logs table. Tbh deleting a user if quite difficult since cascade hasn't been set on a lot of the foreign key relationships, so you’ll have to find them and delete the records manually.
If possible, just mark the user as inactive and change all the fields that might cause issues with unique constraints if the same user is trying to sign up again

@nytai , it's great! it works for me. When i tried to delete a user,  it took a long time and timed out(log info, [CRITICAL] WORKER TIMEOUT (pid:5783)). So i deleted the records of the logs table, and the user can be deleted normally.

Has anything been done for this for 2.0.0?
Deletion should just work, after a warning everything should just automatically be removed, one shouldn't have to manually go through tabs or cleaning up records in a database (to be able to) delete a user.

Hey guys,
The version 2.0.0 has the same problem ⚠
We were able to reproduce the problem after a user ran a query, and then we were unable to remove this user.
It was necessary to remove the user data in this case from two tables:

logs
query

puting this here for future use:
-- user to be deleted is id XXX
delete from favstar where user_id=XXX;
delete from key_value where changed_by_fk=XXX;
delete from key_value where created_by_fk=XXX;
delete from logs where user_id=XXX;
delete from ab_user where id=XXX;

Still having this issue. The user im trying to delete has never created a chart or dashboard

If you're using the latest version it may be possible that there are new tables.
Run the above script and check what the error message is for the last line. Modify the script accordingly and post it here.
I come grab this snippet whenever I need to delete a user.

just want to save time for who don't know how to do as C-monC above,
if you run superset by docker, the default metadata of superset is from the container name 'superset_db' and the image is prosgre. This database is already connected on Superset UI as example database when you load the examples. However you cannot delete records in this database when you haven't eddited its setting and allow DML.
After that, just go to sqllab, find the userid you want to delete, run 'delete from ab_user where id = 5' , it will show you which table have data associated with this user_id. Then run delete query of all those related table and run 'delete from ab_user where id = 5' again, you can now remove that user.

I ran into the same problem. I can't delete any user even though the use was recently created and doesn't own any chart, board or dataset.
How could it be that the user deletion doesn't cascade through every data like e.g. logs?
Appreciate some solutions (two years after initial report) for how to solve this bug.

Someone else reported a solution here that you might want to try: https://github.com/apache/superset/issues/2318

Airflow v2.6.0
Just had the same problem - following worked for me -

delete  from dag_run_note where user_id='<userid>;
delete from ab_user_role where user_id='<userid>';
delete  from ab_user where username='<username>';

Not a fan of force deleting but this is a fundamental bug that needs fixing.

Same bug for me on 3.1.0. I have no access to the SuperSet database so I will set the user as inactive. But it should really be fixed.

This is driving me nuts as well. I do not feel comfortable doing deletes outside of the ORM, as it might wreck stuff and make upgrades fail

Hello,
I have already create and delete users without problem.
We ca consider the cascade delete is existing but for an unknown reason, I have also this issue on superset v3.

The message should detail the data to remove.
I will test :

puting this here for future use:
-- user to be deleted is id XXX
delete from favstar where user_id=XXX;
delete from key_value where changed_by_fk=XXX;
delete from key_value where created_by_fk=XXX;
delete from logs where user_id=XXX;
delete from ab_user where id=XXX;

Hello,
I systematically reproduce the problem "impossible to delete a user : Associated data exists, please delete them first".
I have identified the cause: This only concerns users who have created elements in Superset. Despite the deletion of elements created by a user from the graphical user interface, the deletion of the user is impossible because the "key_value" table is not cleaned at the time of deletion, this creates an integrity constraint preventing the deletion of the user.
The other tables (logs, slices, slice_user) are correctly updated.
The “key_value” table has a relationship only with the “ab_user” table.

It is possible to work around the problem by executing a delete query on the key_value table :
delete from public.key_value where created_by_fk = <id_user_to_delete>
Testing the workaround :
"Deleted Row" 👍
The following tables are well updated:
• ab_user.sql
◦ Deletion of the line relating to the user
• ab_user_role.sql
◦ Deletion of the line relating to the user
• logs.sql
◦ Lines mentioning   now mention user = None (like a user deleted without objects created)
Best regards

Interesting, thanks for the context. @michael-s-molina or @villebro would know best about the intricacies of deleting key_value and whether it's preferable to remove them along with the user, or leave them orphaned (i.e. if they're needed by other users in other contexts, like sharing a URL with someone)

@rusackas @michael-s-molina @xavier-GitHub76 IMO orphaning the rows is definitely the right course of action here, as permalinks etc should continue existing after a user record is deleted. And for other temporary key value pairs, there's usually an expiration date attached to them, which will ensure that the records disappear in due course.

So the best practice would be to wait until the expiration date has passed before being able to delete the user ?
If so, several questions arise:

How can an administrator find out about this date ?
What is the mechanism that deletes keys that have become obsolete ?
Is it possible to speed up this deletion ?

Thank you for any details you can provide us.

puting this here for future use:
-- user to be deleted is id XXX
delete from favstar where user_id=XXX;
delete from key_value where changed_by_fk=XXX;
delete from key_value where created_by_fk=XXX;
delete from logs where user_id=XXX;
delete from ab_user where id=XXX;

I would like to know what the key_value table actually does

The alert message "Associated data exists, please delete them first" could be replaced by a more appropriate message.
It is requested to delete the elements preventing deletion but the user cannot identify them or even cannot act (eg: key_value)
The message could be :
"Unable to delete this user
Traces concerning him are present (e.g. creation of elements on his part)
Please use account deactivation"


Android has the KSOAP Framework for Handling SOAP Protocol for WebService interface.How does Flutter handle the SOAP protocol ？

Android has the KSOAP Framework for Handling SOAP Protocol for WebService interface.How does Flutter handle the SOAP protocol ？

Hi @gionchat,
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this. You may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


Push notifications not sending

I set icon to notification after that push notifications not working it returns log modified register token

Sorry for this very late answer.
you should update the token with the new one that you just received


Add Swagger UI Integration

Add Swagger UI Application so that APIs can be analyzed and tested in a friendly manner.
How it works:

For each client API Package, a REST endpoint is added, which just retrieves the specification file of the client package.
This endpoint is added as a Swagger Resource in the SwaggerUI, so it can be rendered and used by Swagger UI

Declining


Rails 5 compatability

Its time to be compatible with Rails 5. I started a upgrade-rails branch using the Appraisals gem to generate Gemfiles for Rails 4 (4.2) and Rails 5 (5.0).
Rails 4 tests passed as usual. However Rails 5 tests locally fails with 9 errors and 30 deprecation warnings I need to fix.
In pushing to Travis, I realized Rails 5 depends on the newest Rack version. The newest Rack version requires Ruby 2.2.2 or higher. It seems I will need to dropout support for Anything less.

Currently leaving Travis config to use only 2.2.6 Ruby. Seems to be an issue if I use 2.3 (on Travis's side).

I've decided to move it completely to Rails 5. Its difficult to support both 4 and 5 at same time due to some breaking changes in 5. I'd rather not have if statements to handle actions between 4 and 5.
Theres currently an issue with friendly_id as well where it does not pick up on ActiveRecord 5 to overwrite the finder method. It is fixed in master branch for friendly_id but not released, and no roadmap ahead. I'm debating on moving all finders to use find_by_slug instead of find or waiting for the 5.2 release.

As of now ALL tests pass IF friendly_id master is used. Right now I have to wait for friendly_id to release 5.2 before I can release new one :(

Switched all finders to use friendly_id's direct friendly finder method. All tests now pass.

Solved with #7


[BEAM-9051] BigQueryUtils toBeamRow support the Avro timestamp-millis logical type

This change allows users with Avro GenericRecords that utilize non-microsecond timestamp values to utilize BigQueryUtils.toBeamRow to convert those GenericRecords into Beam Rows. This functionality was required for our implementation, as were generating GenericRecords from Scala case classes and didn't have direct access to the implementation which chose the precision of the timestamp value to be generated based on Instant fields (these Instant fields were converted to milliseconds in our case). Testing shows that the functionality works for nested rows and arrays. The implementation should not affect any existing use cases as it preserves the original API.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

R: @lukecwik

@lukecwik looks like you're the owner of this component; should I reach out to anyone else for a review?

R: @kennknowles
Blame shows that Kenn reviewed/changed this code and would be a more appropriate reviewer.

I can take a look at this

@TheNeuralBit looks like AvroUtils.toBeamRowStrict can replace BigQueryUtils.toBeamRow in our use case; and the implementation of logical types in Beam schemas makes sense. I'm going to close this PR and the associated tickets which add features to BigQueryUtils.toBeamRow. Sounds like we should get some more info from @kennknowles about whether the avro support in BigQueryUtils should be deprecated? Having the two implementations (with the BigQueryUtils implementation not supporting as many Avro types as AvroUtils) can be misleading.


Support password protected Pocket feeds

I would love to have the option to pass my authorization data to Pocket in order to get links from private and password protected feed.
Here is the setting: https://getpocket.com/privacy_controls/
If option is on - Pocket requires authorization, but Bookmark Archiver appears doesn`t support that.

You can get pocket links from a private account using their export feature here: https://getpocket.com/export
We wont be able to get the live feed unless we do a full on API integration with Pocket API keys and a backend running somewhere, so I cant promise we'll get around to that anytime soon.

Related to #528.

This should work now in >=v0.5.4 thanks to @mAAdhaTTah, give it a try @ghost and comment back here if you have any troubles.

This should work now in >=v0.5.4 thanks to @mAAdhaTTah, give it a try @ghost and comment back here if you have any troubles.


Channels with the same tag name are difficult to distinguish

On the campaign routing screen, channels only display their tag name, not their tag pool. This makes distinguishing channels with the same tag name difficult:

@justinvdm I've taken a very simple approach here (i.e. changed the label returned by the API) and arguably that's useful to all API users, but perhaps I should fix this in the UI rather. Thoughts?

@hodgestar A little worried about cases where the name gets too long. I think those cases are already quite common, so if we add the tagpool name quite a few names will go outside of their boxes. Maybe we should do your suggestion of fixing this in the UI rather? It seems like the better approach anyways, since this is a presentation thing rather than an API thing.


docs(MIGRATION): add Observable.of

Merged with 0976d7a, cool thing to catch this, Thanks @milkisevil !


Add configurable validation level support

Currently the check_cert plugin and lscert CLI tool requires that:

at least one cert is present
any certs present in the chain are not expired
that the expiration thresholds have not been crossed (implicit or explicit)
that the hostname matches

see also the dns-name flag

These validation options are currently not implemented:

name constraints

e.g., don't allow a leaf cert to claim a name that the intermediate did not authorize

valid chain from leaf to root (GH-2)
?

Not sure of the final form, but it may be useful to offer a one-stop flag to control which validation settings are applied.

Validations (some repeated):

cert chain ordering
hostname
expiration
duplicates
has root cert
has multiple intermediates
missing intermediates
missing root

I plan to turn to this soon and implement configurable validation first using already enabled validation for hostname and cert expiration. I will try to keep the current behavior as the default.

Not sure of the final form, but it may be useful to offer a one-stop flag to control which validation settings are applied.

I was considering using a single flag with a comma-separated keywords approach, but I'm not sure how that will mix with flags like --age-warning and --age-critical. Looking at curl and wget as inspiration, I'm considering just going with multiple individual enable or disable variants for each validation option. I'm thinking of just offering disable variants for situations where a default enable behavior is already applied such as cert expiration date.
The same would likely hold true for hostname verification, which currently requires using the --dns-name flag to work around using a non-matching FQDN or IP Address for the --server flag.

For blocks like this one:
https://github.com/atc0005/check-cert/blob/99cffdaacdd553a78e85bdaa15b270a284350d3d/cmd/check_cert/main.go#L250-L284
The plan would be to setup a separate validation function that returns an error and useful details to replicate the current results:

nagios.ExitState
zerolog.Event

Depending on where this is implemented it would involve setting up a dependency on both of atc0005/go-nagios and rs/zerolog, so that's something to consider.

Depending on where this is implemented it would involve setting up a dependency on both of atc0005/go-nagios and rs/zerolog, so that's something to consider.

The dependency on atc0005/go-nagios is already set for internal/certs.

The current line of thought is that the checks can be standardized so that the return value (new type) provides enough information to easily construct the desired nagios.ExitState value. I can see extending the atc0005/go-nagios package to provide a new constructor to build a fully populated nagios.ExitState value from this new type.
Or, perhaps the check can return an already constructed nagios.ExitState value along with a zerolog.Event as previously noted. This sets up a tighter dependency, but would likely greatly simplify the amount of code within the main func currently dedicated to populating the nagiosExitState variable.
Or, perhaps things stay roughly the same and I use getter methods to determine whether specific checks run. Doubtful this is the best route, but further consideration/tinkering is needed to clarify.

While prototyping changes I adjusted the behavior of SANs list validation.
Since there are flags added to explicitly enable SANs list validation, I thought it might be useful to use the value of the dns-name flag as the sole entry of the sans-entries list if no values are specified by the sysadmin.
This works fine in some cases, but fails for several others:

where the DNS Name is not in the SANs list

found one case where example.com was included in the Common Name, but not the SANs list (FAIL)
found another where google.com is in the SANs list, but so are 129 others which are flagged as "unexpected" (FAIL)

I'll need to wind that change back and give it some further thought.


Fix(DeprecationWarning): Work around in testRunner

DeprecationWarning: "Runner(suite: Suite, delay: boolean)" is deprecated. Use "Runner(suite: Suite, {delay: boolean})" instead.
fixes #44922
@sandersn
Signed-off-by: Benjamin Vincent (Luxcium<EMAIL_ADDRESS>Please verify that:

[ ] There is an associated issue in the Backlog milestone (required)
[X] Code is up-to-date with the main branch
[X] You've successfully run gulp runtests locally
[X] You've successfully run gulp tests & gulp runtests-parallel --light=false locally
[ ] There are new or updated unit tests validating the change
[X] fixes #44922

@sandersn

There is NO associated issue in the Backlog milestone (required)...
I do not think it is expected to have test suit for the test suit runner...

How hard would it be to update mocha's types to 9.0? There are almost 3,000 lines of types, so it might be prohibitively difficult. On the other hand, maybe { delay: boolean } is in 8.* too?

I have annotated both Mocha constructor and the type library in my review of my PR...

In Mocha the constructor was updated here
From function Runner(suite, delay) to function Runner(suite, opts)
which was around version 7.1.0
Therefore as @sandersn  suggested this is something that should be first fixed in the type definition... and then this issue could be resolved without using a « workaround »
Originally posted by @Luxcium in https://github.com/microsoft/TypeScript/issues/44922#issuecomment-877556902