new: owner (leogr)

Signed-off-by: Leonardo Grasso<EMAIL_ADDRESS>
What type of PR is this?
Just adding myself as owner/reviewer.

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind user-interface

/kind content

/kind transalation

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area blog

/area documentation

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign leodido
You can assign the PR to them by writing /assign @leodido in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

/assign @leodido

LGTM label has been added.  Git tree hash: eff05a8bba2b0026b43ba8536717a3999c163be6

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
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:

OWNERS [leodido]

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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fntlnz, leodido
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:

OWNERS [fntlnz,leodido]

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


exa is unmaintained now, should switch to eza

As in the title

Thanks for the update, wasn't aware of that. Check for eza added in 99ed6cfb3e45148d5baf3586dfad7279df317263

README reference to this is missing


Make max upload size configurable

Is your feature request related to a problem? Please describe.
The nginx-ingress controller has a default max upload size of 1MB. This is usually insufficient for both the frontend website and the Studio.
Describe the solution you'd like
The max upload size should be configurable for both the frontend websites/CAEs and the Studio.
Describe alternatives you've considered
The only other alternative is to change the default in the ingress controller configMap.

Closed with https://github.com/T-Systems-MMS/cmcc-operator/commit/8fa3524337e3c2d2351e3860c7d56eb997432000


schema limitation

The scheme requires that at least one parameter is defined for a new contacts_type.  But, it is possible that the exact same potential would be used for all contacts, such that contact-specific parameters are not required.  So, this requirement should be relaxed.

This limitation is relaxed in OpenSMOG.  see commit 16bb587916c3325c2699cd463db8fb7e6a9bd078
But, it is not fully supported by SMOG 2, yet.


Empower user to manage Identity Provider sessions

If I log in with an Identity Provider I can only log in with another Identity Provider if the Service Provider happens to not support that Identity Provider.
In which case I will always log in with THAT Identity Provider.
I propose making this more transparant to the user:
On first encounter with EB you get the discovery screen without any preselected Identity Providers.

You select an IdP and log in. Then you go to a different SP automatically get redirected to:

When you click stop you see:

With a "Previous" and "History" from which you can delete and among which you can delete.
Deleting will give you a warning that if you are still logged into "name of the idp" then you need to close the window (hard to do on mobile) or manually log out there.

Just a check to see whether I understand this correctly: do you propose to build in some sort of delay screen (with a stop button) (the 2nd picture) every time I login to another service while I am already logged in through Single Sign On?

Yup, that was the suggestion to help users select a different Identity Provider after they had already selected one.
Alternative might be to add a checkbox to the WAYF as in:

[ ] Remember for x days.

Though with a checkbox the user is still out of luck if someone checked it for him (CSRF) or if he suddenly needs to log in at a different IdP (for example imagine a professor sitting with a student wanting to show him something).

Ah I see. I think there are only a couple of users that actually have more than 1 IdP so to build in a delay for only 0.01% of the users does not seem like a very good solution...
The second suggestion sounds good, but does not really solve the first problem :) What we are going to fix though is that the "preselected IdP" will always be the one you've selected last time. But that doesn't solve the problem you describe either.

Ah okay if you've measured that it's not really an issue then feel free to close this (power user) issue.
(Also just checked and the form is not vulnerable to CSRF because we require the AuthnRequest ID)

Powerusers can easily use the pornprivate browsing button in their browser.

I suppose there is no way for a user to "disable" SSO and get a WAYF every time? (Similar to ForceAuthn)

Not currently, no.


INT-2130 part 1: upgrade App Dir boilerplate codemod

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Rebasing feature/flow-aggregator branch with master

This PR is used to make sure all the tests are passing after rebasing. This is to make sure that new commits from the master branch are not creating any problems with new commits on the feature/flow-aggregator branch.
We do not merge these commits through this PR. This PR is just a placeholder for testing. We push the code directly from local feature/flow-aggregator branch to remote feature/flow-aggregator branch directly.

/test-all

/test-ipv6-all

/test-all-features-conformance
/test-ipv6-e2e
/test-ipv6-networkpolicy
/test-ipv6-conformance
/test-ipv6-only-e2e
/test-ipv6-only-networkpolicy
/test-ipv6-only-conformance


tests: kernel: Enhance test to validate set thread name to current thread

Enhance test to validate a scenario where k_thread_name_set()
with NULL as thread ID should set thread name to current
thread.
Signed-off-by: Spoorthi K<EMAIL_ADDRESS>

Codecov Report

Merging #10759 into master will increase coverage by 0.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #10759      +/-   ##
==========================================
+ Coverage   55.06%   55.23%   +0.17%
==========================================
  Files         206      206
  Lines       24880    24880
  Branches     5494     5494
==========================================
+ Hits        13700    13743      +43
+ Misses       8876     8828      -48
- Partials     2304     2309       +5

Impacted Files
Coverage Δ

lib/posix/pthread_sched.c
41.66% <0%> (-20.84%)
:arrow_down:

kernel/thread.c
94.8% <0%> (+1.29%)
:arrow_up:

lib/posix/pthread_mutex.c
77.77% <0%> (+1.38%)
:arrow_up:

lib/posix/pthread.c
80.36% <0%> (+12.32%)
:arrow_up:

lib/posix/pthread_cond.c
83.33% <0%> (+20.83%)
:arrow_up:

include/posix/posix_sched.h
100% <0%> (+100%)
:arrow_up:

lib/posix/pthread_barrier.c
100% <0%> (+100%)
:arrow_up:

Continue to review full report at Codecov.

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

recheck

Shippable is failing due to unrelated build error.
@nashif : Would you please help me resolve this issue?

[21/140] Building C object zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj
FAILED: ccache /opt/sdk/zephyr-sdk-0.9.3/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc -DBUILD_VERSION=zephyr-v1.13.0-1241-g624d0240c -DKERNEL -DNRF51 -DNRF51822 -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../../../../../../kernel/include -I../../../../../../arch/arm/include -I../../../../../../soc/arm/nordic_nrf/nrf51 -I../../../../../../soc/arm/nordic_nrf/nrf51/include -I../../../../../../soc/arm/nordic_nrf/include -I../../../../../../boards/arm/bbc_microbit -I../../../../../../include -I../../../../../../include/drivers -Izephyr/include/generated -isystem /opt/sdk/zephyr-sdk-0.9.3/sysroots/x86_64-pokysdk-linux/usr/lib/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/include -isystem /opt/sdk/zephyr-sdk-0.9.3/sysroots/x86_64-pokysdk-linux/usr/lib/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/include-fixed -I../../../../../../lib/libc/minimal/include -I../../../../../../ext/hal/cmsis/Include -I../../../../../../ext/hal/nordic/nrfx -I../../../../../../ext/hal/nordic/nrfx/drivers/include -I../../../../../../ext/hal/nordic/nrfx/hal -I../../../../../../ext/hal/nordic/nrfx/mdk -I../../../../../../ext/hal/nordic/. -I../../../../../../subsys/bluetooth -I../../../../../../tests/include -I../../../../../../tests/ztest/include -I../../../../../../tests/crypto/rand32/app -I../../../../../../tests/crypto/rand32/PRIVATE -Os -g -Wall -Wformat -Wformat-security -Wno-format-zero-length -imacros /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/out-2nd-pass/bbc_microbit/tests/crypto/rand32/crypto.rand32.random_hw_xoroshiro/zephyr/include/generated/autoconf.h -ffreestanding -Wno-main --sysroot /opt/sdk/zephyr-sdk-0.9.3/sysroots/armv5-zephyr-eabi/usr -mthumb -mcpu=cortex-m0 -Werror -Wno-deprecated-declarations -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -Wno-pointer-sign -Wno-unused-but-set-variable -fno-reorder-functions -fno-defer-pop -Werror=implicit-int -Wpointer-arith -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -MD -MT zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj -MF zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj.d -o zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj   -c zephyr/misc/generated/configs.c
In file included from ../../../../../../include/toolchain.h:21:0,
                 from zephyr/misc/generated/configs.c:3:
zephyr/misc/generated/configs.c: In function ‘_ConfigAbsSyms’:
../../../../../../include/toolchain/gcc.h:341:51: error: expected expression before ‘)’ token
   "\n\t.type\t" #name ",%%object" :  : "n"(~(value)))
                                                   ^
zephyr/misc/generated/configs.c:239:1: note: in expansion of macro ‘GEN_ABSOLUTE_SYM’
 GEN_ABSOLUTE_SYM(CONFIG_NET_BUF_LOG_LEVEL, );
 ^~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.

recheck


Layout with vertical is still horizontal

Bug Report
Steps

Open the Layout vertical example.

Expected Result
The Layout should be vertical.
Actual Result
The Layout is horizontal.
Version
0.2.0
Testcase
Use the doc example: http://stardust-ui.github.io/components/layout#types-vertical

Fixed


We couldn't find any screenshot

Expected behaviour
Generate a screenshot for the fragment I want to screenshot test when running ./gradlew executeScreenshotTests -Precord
Actual behaviour
When using an older version of Shot library (for example 5.5.0) I get the following response :
> Task :app:debugExecuteScreenshotTests
💾  Saving screenshots.
🤔 We couldn't find any screenshot. Did you configure Shot properly and added your tests to your project? https://github.com/Karumi/Shot/#getting-started

While when I use the latest version (that is 5.12.1) what I get is :
com.parallel.shots.FragmentScreenshotTest > theActivityIsShownProperly[3.2_HVGA_slider_ADP1_API_28(AVD) - 9] FAILED
        java.lang.IllegalStateException: Fragment FirstFragment{1aedfba} (1eaa1af4-0307-4b25-bf51-ec2dc838aa9a) did not return a View from onCreateView() or this was called before onCreateView().
        at androidx.fragment.app.Fragment.requireView(Fragment.java:2008)
Tests on 3.2_HVGA_slider_ADP1_API_28(AVD) - 9 failed: There was 1 failure(s).

Steps to reproduce
Download the sample project from here
Version of the library
5.5.0 and 5.12.1
I've also downloaded KataScreenshotKotlin and when ran  ./gradlew executeScreenshotTests -Precord works as expected (generates the screenshots) so I guess its not a problem with the emulator.
Do you mind checking the sample project I uploaded and tell me whats wrong ? Most probably I have configured something wrong although I read the getting start guide from the README many times.
Thanks a lot for your time!
Edit: Dont know if it matters but I'm using Android Studio Chipmunk | 2021.2.1 Canary 7

Oh my bad just found out this comment here  which helped resolve my issue. I just had to create a folder project/screenshots/flavour/debug/screenshots-default

Sorry for re-opening the issue but it worked only the first time I tried it, for every subsequent run I keep getting the same error :
com.parallel.shots.FragmentScreenshotTest > theActivityIsShownProperly[3.2_HVGA_slider_ADP1_API_28(AVD) - 9] FAILED
        java.lang.IllegalStateException: Fragment FirstFragment{1aedfba} (c10036c7-9088-4060-ae7e-7068e1299695) did not return a View from onCreateView() or this was called before onCreateView().
        at androidx.fragment.app.Fragment.requireView(Fragment.java:2008)

Hey @codeteo that issue you report seems not to be related with the library but with your fragments' configuration. Could you please remove this line here and execute your test again? If it fails, the issue is not related to shot but the fragments initialized.


Adding tests and deleting old manifest

Changes:

A basic set of tests for getters in tests.
The old manifest.xml file deleted. (before catkin build)

Good start. Thanks!

Actually, please:

Add python and python-nosetest as <test_depend>s in the package.xml file
Register the tests in the CMakeLists.txt file
Restore the manifest.xml file - we will remove that in a separate, atomic pull request

See our unit testing guide for details about (1) and (2).
@Shushman Can you take care of this?

@mkoval I've addressed the changes. Note that to successfully run the tests, the user must source /opt/ros/indigo/setup.bash and the workspace as well. That is supposed to be the case, right?

Thanks @Shushman!

Whoops, I forgot to answer your question:

Note that to successfully run the tests, the user must source /opt/ros/indigo/setup.bash and the workspace as well. That is supposed to be the case, right?

That's fine. Anything in the workspace can safely assume that the user sourced the containing workspace's setup.bash file. Some executables may work despite this, but there are no guarantees.
You should not have to explicitly source /opt/ros/indigo/setup.bash because your workspace is (directly or indirectly) chained from it. To be safe, you should only ever source one setup.bash file per terminal window. This includes the one in /opt/ros/indigo.


Gadget images on ghcr.io are private

Hi @blanquicet,
It seems your images on ghcr.io are private, so only you can use them.
Please go to:

https://github.com/users/blanquicet/packages/container/tcprst-gadget/settings
https://github.com/users/blanquicet/packages/container/tcprst-gadget-without-nf/settings

And check "Change package visibility" at the bottom of the pages.

Done. Thanks!


cant put state list drawable with onitemclick

hey,
i have an item in xml that i put a drawable background selector to it, to change the background color of whole item when its clicked :
android:clickable="true"
android:background="@drawable/back1"

when i add in java fastAdapter.withOnClickListener - it doesn't work , i guess  beacuse of selector in xml :
     fastAdapter.withOnClickListener(new FastAdapter.OnClickListener<AdapterMobyList>() {
            @Override
            public boolean onClick(View v, IAdapter adapter, AdapterMobyList item, int position) {
                return false;
            }
        });

i have also another case of this but only instead of fastAdapter i use fastItemAdapter and it works.. so how i can i fix this ?????

@noam2 I use DrawableStateLists myself and they do not prevent click listeners or anything.
Anything else in your code which might prevent this?

@noam2 please report back. close for now


Use released images for E2E tests

Leverage new switch form setup script https://github.com/syndesisio/syndesis-system-tests/issues/16.

Resolved by #21.

Resolved by #21.


Add sport pitch icons back to the map

Closed with https://github.com/tangrams/tron/commit/b7d8bae2e271eb22eca5545062d6f60cb3221479.


🧹 Clean-ups after #201

Do you plan to impose a restriction on hcom? To ensure there are no empty systems, we'd need to allow hcom A r r' φ only when ¬ ¬ φ is true. hcoms that don't satisfy this could be elaborated to ghcoms.
It's probably fine to just always elaborate a surface hcom A r r' {φ} to the corresponding hcom A r r' {φ ∨ ¬ φ}; in the case that ¬ ¬ φ is already true, we just have φ ∨ ¬ φ ⇔ φ. (That's in contrast to the old ghcom, where treating all surface hcoms as ghcoms would produce a lot of junk.)

Do you plan to impose a restriction on hcom? To ensure there are no empty systems, we'd need to allow hcom A r r' φ only when ¬ ¬ φ is true. hcoms that don't satisfy this could be elaborated to ghcoms.
It's probably fine to just always elaborate a surface hcom A r r' {φ} to the corresponding hcom A r r' {φ ∨ ¬ φ}; in the case that ¬ ¬ φ is already true, we just have φ ∨ ¬ φ ⇔ φ. (That's in contrast to the old ghcom, where treating all surface hcoms as ghcoms would produce a lot of junk.)

Unfortunately the solver needs to be fixed first. :facepalm:

@ecavallo My inclination would be to avoid placing this invariant on hcom for now --- but to use this cool ghcom in the places where our implementation doesn't preserve the non-falseness of cofibrations. Then the user gets exactly what they ask for: they'll get empty systems exactly when they make them.
I would also be open to imposing the invariant globally in the future but frankly it has always made me a little bit "Geometrically" queasy.

Close this now as #200 was not done.


Error when creating a new project

I get the ominous 'Whoops, looks like something went wrong.' message when creatig a new project.
I entered:
Name : 'TinyIssue'
Visibility: 'Public'
Assign users: 'Bug Tracker'
Kanban board
Columns:  Status:Working

There's still something strange here.
I CAN save the project now, but I can neither assign a user, not can I later change the "Default assignee"
The only User this test installation has is a "System" (first name) "Administrator" (last name) - visible: Public.

Thanks and closed.


flash exit on android

1 when i get in vue , connected to ws,and then call App.exit(), it's fine.
2 when i get in my app again later, it just flash exit.
And android keep repeat these two steps, even in emulator.
Android error is:
Trace:
java.lang.NullPointerException:
Attempt to invoke virtual method 'void
com.getcapacitor.PluginCall.successCallback(com.getcapacitor.PluginResult)'on a nulobject reference
at
cn.holmescraft.capacitor.plugins.websocket.client.WebSocket$createConnect$wsClient$1.onFailure(WebSocket.kt:65)
my fix is  annotate the code in line 65 : // bridge.getSavedCall(failureCallId[id]).successCallback(PluginResult(ret))
Can i get a good fix about it?

Can you provide a minimum demo? This will be very helpful for analyzing the problem.

no ws server in my code

no ws server in my code, and address is in .env.production

fine i will be check later

@OrdinarySF any news on a fix?

@Dexus I will be trying to fix it.


Update setup.md

Solution
Just updating a link
Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Infrastructure change (CI configs, etc)
[X] Non-code change (docs, etc)
[ ] None of the above: (explain here)

LGTM! Thanks for the PR.


Update oldextfile header

What is the need for this task.
Extfile header in dflowfm git and hydrolib-core are not aligned and/or up to date.
What is the task?
Extfile header is copied from https://git.deltares.nl/oss/delft3d/-/blob/main/src/engines_gpl/dflowfm/res/example.ext to hydrolib-core so it is also added to the oldextfile. However, the ordering was changed a bit to be in line with the FM kernel by @arthurvd. Later, it was discovered that the keyword nudge_salinity_temperature was not in this file, so this still has to be added. Would be good to also update the example.ext` on the dflowfm git.

Quantity nudge_salinity_temperature was added in PR #536


Support for Non-Touchscreen in Bookmarks

Request to add support for non-touchscreen navigation within Bookmarks page.  Currently, the cursor/ selector does not enter the bookmark area.  It jumps from the top bar to the AA bottom bar, skipping the bookmark area when the car button/ joystick is click.  Thanks.

This is fixed in latest version 1.8.2. Reopen this issue if it hasnt.


Minor updates

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/focus-point-in-unity.md
:white_check_mark:Succeeded
View

mixed-reality-docs/images/VSMRSetup-CPPSelected.PNG
:white_check_mark:Succeeded
View

mixed-reality-docs/images/VSMRSetup-SelectUnityNoPlayer.PNG
:white_check_mark:Succeeded
View

mixed-reality-docs/images/VSMRSetup-UWPSelected.PNG
:white_check_mark:Succeeded
View

mixed-reality-docs/images/vsmrsetup-cppselected-400px.png
:white_check_mark:Succeeded

mixed-reality-docs/images/vsmrsetup-selectunitynoplayer-400px.png
:white_check_mark:Succeeded

mixed-reality-docs/images/vsmrsetup-uwpselected-400px.png
:white_check_mark:Succeeded

mixed-reality-docs/install-the-tools.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


WIP: Features/modal windows

This PR makes our Window.Owner property behave like in WPF.
This means you can set the Owner of a window then call Show or ShowDialog. The Windows will then behave as stated below (source: https://msdn.microsoft.com/en-us/library/system.windows.window.owner(v=vs.110).aspx)
Once this relationship is established, the following behaviors are exhibited:
If an owner window is minimized, all its owned windows are minimized as well.
If an owned window is minimized, its owner is not minimized.
If an owner window is maximized, both the owner window and its owned windows are restored.
An owner window can never cover an owned window.
Owned windows that were not opened using ShowDialog are not modal. The user can still interact with the owner window.
If you close an owner window, its owned windows are also closed.
If an owned window was opened by its owner window using Show, and the owner window is closed, the owned window's Closing event is not raised.

cc: @ffquintella as I believe it was you who was having the problem with dialogs.

Shure it was me. I will clone this as soon as I have some time to test.

@grokys if you get chance to try this, it's almost working except if you open an Owned Modal Window (see window page control catalog) then minimise and restore the main window, we end up with the child window with nothing rendered in there

A quick resize sorts it, iv tried loads of things but cant see why that happens

Ahhh - need to add a reference to Avalonia.ReactiveUI and call UseReactiveUI.

The window appears empty because when it's restored windows is for some reason clearing its content and the renderer assumes that the content is still there.
I don't have time to test it right now, but I notice in https://msdn.microsoft.com/en-us/library/windows/desktop/ms633591(v=vs.85).aspx it says:

You must not call SetWindowLong with the GWL_HWNDPARENT index to change the parent of a child window. Instead, use the SetParent function.

Could this be the reason?

Child Windows seem to be Windows that are contained within the parent window. This is only setting ownership of the window. So I think it's not related to that.

@grokys I didn't see this for some reason

Child Windows seem to be Windows that are contained within the parent window. This is only setting ownership of the window. So I think it's not related to that.

Hmm, ok. The only clue I can give you is that if you remove this call, it works. So that call is changing the behavior of the window to not persist its contents after restore. Is this a documented side-effect of changing the window owner?!

I tested this with the new PR, without change in behavior. If you remove the call it works, but there isn't a relationship between the windows anymore so you loose things like minimizing the MainWindow also minimizing the owned window. Is code in Avalonia able to clear the window, or is Windows somehow doing this without us knowing? BTW why don't we render on wm_paint messages? Out of curiosity

Did you try to return 1 on WM_ERASEBKGND?

Further information: When the parent window is minimized, it receives WM_SIZE, but the owned window doesn't, this causes the parent to redraw.


chore(ci): add informational Codecov status checks

Hi, Tom from Codecov here. I noticed that you were using Codecov but weren't actually getting any notifications on pull requests. I figured it would be useful to get some idea if code being changed is being tested, but also not blocking CI/merging. Let me know if this makes sense or if we can do something that would be helpful.

Hey Tom. I like the idea (and love codecov) but think in practice it would be mostly ignored and would create unnecessary noise in PRs. Thanks for the suggestion though :)


chore(ci): 1.8.1 release post actions

Release Note
NONE

Sorry completely forgot about this. Silly me

No worries, that's everybody's job :)

Blocked by #3064.

Let me try merging this and see if that fixes some the issues from #3064.


decomp: finish the remainder of untouched gameplay code

Putting this up for visibility to reduce duplicate effort

[x] side-kick
[x] target
[x] target2
[x] collide-reaction-racer
[x] target-death

blocked

[x] target-handler

blocked

[x] water
[x] robotboss-weapon
[x] robotboss-misc
[x] robotboss

dass handling this, partially done

[x] sage-finalboss

dass also handling this

[x] target-racer

blocked

[x] racer-states

blocked

[x] target-flut
[x] rolling-lightning-mole

blocked

[x] rolling-robber

blocked

[x] ogreboss

blocked (far label issue)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.004%) to 56.101%

Totals

Change from base Build<PHONE_NUMBER>:
0.004%

Covered Lines:
40389

Relevant Lines:
71993

💛  - Coveralls


Please, add me Spain Hispasat 30W streams

Please, add me Spain Hispasat 30W streams, the frecuencies is: 10917V, 10770H and 10923V. Thank you.

Anyone with a dish on Hispasat 30W?
I don't have one.

You have an dish with Hispasat 30W.

You have an dish with Hispasat 30W

Who is that "you"?

Lelegard have an dish with Hispasat 30W, dish it and now capture me streams.

Lelegard have an dish with Hispasat 30W, dish it and now capture me streams.

Lelegard is me and I do not have a dish on 30W. The fact that I once captured a stream for you on 19.2E means that I have access to a dish on 19.2E, not 30W! The former is over Eastern Europe while the latter is right in the middle of the Atlantic Ocean. Not really the same direction. Please stop assuming things about which you know nothing.
Furthermore, this is the third time you request streams captures in a rather imperious manner. People are here to offer benevolent help to TSDuck users. Please consider that we are not stream capture robots. You seem to have a strong interest in various Spanish streams. If this is for professional reasons, then you should find the right professional resources to achieve your project.


OSSM-1847: fixes for gateway injection template

This is a cherry-pick of #960.

gen-check will fail, because removal of SME must be merged first.


Set up codecov code coverage tool

Set up codecov for code coverage.
To see this branch's coverage, go to https://codecov.io/gh/projecttacoma/cqm-parsers/branch/codecov
Pull requests into cqm-parsers require the following. Submitter and reviewer should :white_check_mark: when done. For items that are not-applicable, note it's not-applicable ("N/A") and :white_check_mark:.
Submitter:

[x] This pull request describes why these changes were made.
[x] Internal ticket for this PR: https://jira.mitre.org/browse/BONNIE-1867
[ ] Internal ticket links to this PR
[x] Code diff has been done and been reviewed
[x] Tests are included and test edge cases
[x] Tests have been run locally and pass

Reviewer 1:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@5d6d2f0). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #17   +/-   ##
=========================================
  Coverage          ?   82.76%
=========================================
  Files             ?       99
  Lines             ?     4665
  Branches          ?        0
=========================================
  Hits              ?     3861
  Misses            ?      804
  Partials          ?        0

Continue to review full report at Codecov.

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


Fix bug #1069 and fix download onceConnected call

Just replacing \ with / on localPath for now.
There seems to be no way to ask the FTP server what the preferred directory separator is, see https://stackoverflow.com/questions/37411642/how-to-get-ftp-servers-file-separator. As noted there, most FTP servers will use / however some do not. Perhaps in the future we should add an option to .ftpconfig to specify the FTP server's preferred directory separator, with / being the default. That way in obscure situations the user can specify whatever separator they want.
I also noticed that it wasn't triggering the download after connecting (if not connected at time of request), so put in a quick fix for that as well

I'm sorry to hang you. Next time, modify the last commit. There are not so many changes that should be justified.

No worries, and thanks! Actually I'm just learning github so commits etc are all very new to me, I didn't know there was a way to modify a commit


native base integration

Has anyone integrated with native-base kitchen sink?? https://github.com/GeekyAnts/NativeBase-KitchenSink
Seems that changes should made in js/AppNavigator.js to work properly.

Hi, this issue is not very detailed. If you have a proposal to change the API, feel free to write it up in another issue!


implementation of add_request_headers and add_response_headers as obj…

Description
This change is to support the map based configuration for add_request_headers and add_response_headers, to support the advanced configuration of the 'append' flag in the virtual host config.
Related Issues
List related issues.
Testing
Haven't tested, only done linting
Todos

[x] Tests
[ ] Documentation

Other

If this is a documentation change, please open the pull request at https://github.com/datawire/ambassador-docs instead.
Code changes should occur against master.

@kflynn Can you tell me why the checks are failed, doesn't seems to be because of my changes, And please review the changes and let me know what all to done to have a merge.

Code looks pretty reasonable, thanks!
We already have tests in t_optiontests.py for these options; if you can extend those, I'll see if I can't figure out a simple way for you to run them in minikube or the like...

(You should also merge master into your branch -- that'll trigger another CI run, and in the process clean up some stuff about CI...)

@kflynn merged from master to my fork, still having a similar error,
Checking 235 url requirements... 2 not ready (http://plain.plain-namespace/ambassador/v0/check_ready: Get http://plain.plain-namespace/ambassador/v0/check_ready: net/http: request canceled (Client.Timeout exceeded while awaiting headers)) sleeping 10s...

Docs PR is also raised against master https://github.com/datawire/ambassador-docs/pull/42


[AB3: Removing Fields] Add git diff for removing address field

Fixes #84
I've added a git diff to compare the changes made when removing the address field.
Currently, the commit is on a branch in my fork of the AB3 repository, as I don't have permission to create a new remote branch on the main repository. It can cherry-picked over later after a branch is created for it and I will update the commit link again after.
Commit link: https://github.com/mfjkri/addressbook-level3/commit/3e658057198ca9e1ff0fce2ce1b353df78e0be86

Hello Fikri, I have looked at the issue and the PR and agree that this would be a useful addition to the guide. In addition, I have tried out your commit and the program seems to be able to compile, execute and run without the address field.
However, just a small nit, as your statement is in the "Tidying Up" section and after talking about removing the address field from the JSON files, it might be clearer to indicate that the git diff is not online for the JSON files but the whole program.
Here is a proposed change for your statement:
"After you've manually removed the address field from each relevant JSON file, you can cross-check your changes with this diff. This link provides a complete overview of all changes made throughout the guide, including the removal of the address field from various parts of ab3."

Hello Fikri, I have looked at the issue and the PR and agree that this would be a useful addition to the guide. In addition, I have tried out your commit and the program seems to be able to compile, execute and run without the address field.
However, just a small nit, as your statement is in the "Tidying Up" section and directly after talking about removing the address field from the JSON files, it might be clearer to indicate that the git diff is not only for the JSON files but the whole program.
Here is a proposed change for your statement: "After you've manually removed the address field from each relevant JSON file, you can cross-check your changes with this diff. This link provides a complete overview of all changes made throughout the guide, including the removal of the address field from various parts of ab3."

Hi Carlin, thank you for the suggestion!
I have made the edit to make it more clear.

Good addition to the guide! Just a suggestion to include a simple description (possibly as a sub-point or dropdown panel) on how you derived the diff file using Git as it may be useful for readers to know and some of them might be curious after seeing it as well.

Good addition to the guide! Just a suggestion to include a simple description (possibly as a sub-point or dropdown panel) on how you derived the diff file using Git as it may be useful for readers to know and some of them might be curious after seeing it as well.

While I think this can be a great addition to have, I am not entirely sure how relevant it would be to include it here in this guide.

Thanks for this PR @mfjkri
I've adapted its content in https://github.com/se-edu/guides/commit/a96248617b5ea94c857a8f057ddee6f93d3e47ca


Download remote images error at specific number of images

View: src/utils/downloadImagesInBatches.ts
Function: downloadImagesInBatches
const batches = Math.ceil(imagesURLs.length / batchSize); // determine the number of batches
for (let i = 0; i < batches; i++) {

    const start = i * batchSize; // calculate the start index of the batch

    const end = Math.min(imagesURLs.length, start + batchSize); // calculate the end index of the batch

    const batchURLs = imagesURLs.slice(start, end); // slice the URLs for the current batch

    const batchFileNames = imageFileNames.slice(start, end); // slice the file names for the current batch

    if (batchFileNames[i].fullPath === undefined) {`

If 231 images, we have 12 batches. Then last patch has only 11 images (index from 0 to 10). Then it throws error at i = 11

Hi @thuatz,
Thanks for the error report. I opened a PR for a fix


Fail to list the function URL after deploying a Python project to Linux Dedicated Plan

OS: Mac\Win10
Build Version: 20190521.1
Repro Steps:

Create a Python project.
Deploy to a Linux function app.
Check the result.

Expect:
Succeed to deploy and there is no error when getting the function URL.
Actual:
Display that succeed to deploy but fail to list the function URL.

More Info:

This issue also reproduces after deploying a C#/JS project to a Linux function app.
This issue DOEN NOT reproduce after deploying a C#/JS project to a Windows function app.

What region was this in? The Azure team fixed a bug related to this a little bit ago, but I thought it was already deployed to all regions: https://github.com/Azure/azure-functions-host/issues/4372

Hi Eric,
We tried to deploy a JS project to Linux function apps with below locations. And this issue also reproduces.

Location
State

East   Asia
Repro

East   US
Repro

West   Europe
Repro

West   US
Repro

@v-dantch can you give me permissions to a function app that this repros on?
You should be able to do this in the portal. Go to "Platform Features -> All Settings"

Then go to "Access Control -> Add role assignment" and add me by email addresss

Hi Eric, sorry for the late notice 🙇.
Done for the permission of function app "test0530-l-python".

Ah didn't realize this was a Linux dedicated plan instead of consumption. I can repro on dedicated

Closing as duplicate of https://github.com/microsoft/vscode-azurefunctions/issues/1374


uneven task completion times in EM step -- suboptimal tuning?

Thanks again for the brilliant package. I am currently using splink with Python 3.7 and Spark 2.4 to deduplicate (publicly-available) campaign contribution data in the U.S. This package has worked very well on data from smaller states (14k rows), completing the task in a few minutes as expected.
On (relatively) larger states, ~ 200k rows, regardless of the number of dataframe partitions or specified spark.sql.shuffle.partitions or spark.default.parallelism, I am unable to overcome uneven task completion times in the EM step.
For example, for anywhere between a few dozen or a few hundred spark.sql.shuffle.partitions, the last few tasks take far longer than the others, resulting in both suboptimal CPU usage and long runtimes (see below, x-axis is time of day in HH:MM -- this last task will drag on for ~ 30 minutes). This issue is far worse when weighting one or more fields by term frequency.

Things I have tried:

More (or fewer) data partitions (from 15 to 1000) [The default behavior reading in my .parquet file is only one partition, so I repartition, specifying no key]
Changing spark.sql.shuffle.partitions and spark.default.parallelism
Replacing nulls in data with empty strings (join problems?)

Exact code (both the slurm script for my cluster job and the python script) -- as well as a log file for a cluster job that was terminated early (the last few tasks will drag on) -- are attached, if it's any help.
I would be grateful for any guidance the authors could provide for Spark parameter tuning, given that I'm not sure how tasks are being allocated in the package. I do suspect that this is is a tuning problem, but I'm not sure what else to try.
job.txt
dedupe_state.txt
slurm-39028725_3.txt

Hiya.  Thanks for the info, and especially providing the code.
This issue is probably with your blocking rules:
"blocking_rules": [
        "(l.contbr_city = r.contbr_city) AND ((l.po_num is null AND r.po_num is null) OR (l.po_num is not null AND r.po_num is not null)) AND ((l.gender = r.gender) OR (l.gender = 'm' AND r.gender = 'u') OR (l.gender = 'u' AND r.gender = 'm') OR (l.gender = 'f' AND r.gender = 'u') OR (l.gender = 'u' AND r.gender = 'f'))",
        "(l.contbr_nm_last = r.contbr_nm_last) AND ((l.po_num is null AND r.po_num is null) OR (l.po_num is not null AND r.po_num is not null)) AND ((l.gender = r.gender) OR (l.gender = 'm' AND r.gender = 'u') OR (l.gender = 'u' AND r.gender = 'm') OR (l.gender = 'f' AND r.gender = 'u') OR (l.gender = 'u' AND r.gender = 'f'))"
    ],

In a nutshell, you can't have OR conditions in blocking rules for large jobs.  This is a result of how Spark performs joins.
Blocking rules are implemented by performing an inner join of the input dataset on itself.
For example, if a blocking rule is 'l.surname = r.surname', then Splink is doing something like:
select *
from df as l
INNER JOIN df AS r
ON l.surname = r.surname

Spark performs the inner join using hash partitioning on the equality condition, which enables effective parallelisation.
Unfortunately, Spark is unable to optimise  (effectively parallelise) OR conditions in an inner join.

If you want to achieve an OR condition, you're better to have multiple blocking rules.

So, for example, if you wanted to achieve `l.surname = r.surname OR l.first_name = r.first_name`, you'd be better with two blocking rules:

blocking_rules = ['l.surname = r.surname', 'l.first_name = r.first_name'].  Both rules now have an equality condition, and it'll run faster


Multirun printing performance degradation

Issue Description
What did you expect to see happen?
linear printing time
What did you see instead?
degradation of printing to csv time
Please attach the input file(s) that generate this error.  The simpler the input, the faster we can find the issue.
   <MultiRun name="MCrun" pauseAtEnd="True">
      <Input          class="DataObjects"   type="PointSet">SET_ARMAprice_in</Input>
      <Input          class="DataObjects"   type="PointSet">SET_dispatch_in</Input>
      <Input          class="DataObjects"   type="PointSet">SET_CashFlowPreP_in</Input>
      <Input          class="DataObjects"   type="PointSet">SET_CashFlow_in</Input>
      <Model          class="Models"        type="EnsembleModel">MyEnsemble</Model>
      <Sampler        class="Samplers"      type="MonteCarlo">DYMOLA_MC</Sampler>
      <Output         class="DataObjects"   type="PointSet">SET_All_out</Output>
      <Output         class="DataObjects"   type="PointSet">SET_IRR_out</Output>
      <Output         class="OutStreams"    type="Print">dumpAll</Output>
    </MultiRun>

For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.

[ ] 1. Is it tagged with a type: defect or improvement?
[ ] 2. Is it tagged with a priority: critical, normal or minor?
[ ] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[ ] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[ ] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.

[ ] 1. If the issue is a defect, is the defect fixed?
[ ] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.)
[ ] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[ ] 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
[ ] 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

This is not really an issue: just print on file using an IO step after having generated the dataObject.

To be fair, it should be reasonably possible for us to append to a CSV with additional points instead of rewriting it entirely each time.  It would make this a more linear printing process.

We generally suggests to use the IOStep to print out the results after the completion of an analysis.
We should identify why the degradation is not linear as we would expect.


[MAIN] Accelerate guess datetime format

Reference
This PR addresses https://github.com/skrub-data/skrub/issues/835
What does this PR implement?

Sample 10 rows to infer the datetime format instead of using the whole array, yielding a 500x speed up on a 1d array of size 100k.
Add some tests using 20 different random_state

Should we use a bit more than 10 rows? For 10 rows the proba of having all days below 12 is ~1/1000 for uniformly spreaded dates, which is small but still large enough for the format detected to change when doing things like hyperparameter optimisation. For 20 days the proba drops to 1e-8.

Let's make it 30

Should we use a bit more than 10 rows? For 10 rows the proba of having all days below 12 is ~1/1000 for uniformly spreaded dates, which is small but still large enough for the format detected to change when doing things like hyperparameter optimisation. For 20 days the proba drops to 1e-8.

Sounds good!

I have weird and seemingly unrelated errors with the GapEncoder

The last version of Polars (0.19.16 at the time of testing) was the source of errors, it has been yanked from Pypi since (replaced with version 0.19.18).
Polars seems to release very frequently and yank packages quite often (see Pypi release history). Maybe we should fix and update the Polars version regularly for testing instead of using the latest. This would limit this kind of error on our CI, WDYT?

Merging since the changes are quite small


[Question]: Execution failed for task ':share_plus:compileReleaseJavaWithJavac'. > error: invalid source release: 17

What is your question?
Execution failed for task ':share_plus:compileReleaseJavaWithJavac'. > error: invalid source release: 17
I got this issue when try to run build
Checklist before submitting a question

[X] I searched issues in this repository and couldn't find such bug/problem
[X] I Google'd a solution and I couldn't find it
[X] I searched on StackOverflow for a solution and I couldn't find it
[X] I read the README.md file of the plugin
[X] I am using the latest version of the plugin
[X] All dependencies are up to date with flutter pub upgrade
[X] I did a flutter clean
[X] I tried running the example project

This has been asked a thousand times already, use the search

Ki

This has been asked a thousand times already, use the search

Can you kindly write a solution or link to that solutions instead

OP selected "I searched issues in this repository and couldn't find such bug/problem" when they didn't do it, asking the same questions without doing some basic research wastes the maintainer team time.
As a reminder, this is a project run by volunteers on our free time.


Is it possible to change opacity of node images?

I am trying to do something similar to the neighbourhood highlight, except all my nodes are images.
Is is possible to, instead of grey them out, change their opacity?

Hi @Tyler-Maclachlan,
this is currently not possible. You can however have images with different opacities and swap them as needed.


Configure VPNKIT IP addresses automatically

WSL2 IP address is not fixed, it can be different after every WSL2 Linux starting. We can get the current VPNKIT IP addresses by "ip route show" and "grep" commands, always.
Further development should be in future that, we need to check VPNKIT_LOWEST_IP and VPNKIT_HIGHEST_IP because they are not allowed to be in conflict with others.

Do not need to merge it.


NTR: Man(5)GlcNac(2)-PP-dolichol ER flippase activity

Please provide as much information as you can:

Suggested term label:

Man(5)GlcNac(2)-PP-dolichol ER floppase activity

Definition (free text)

Catalysis of the movement of a Man(5)GlcNac(2)-PP-dolichol from the cytosolic to the exoplasmic leaftlet of a membrane, using energy from the hydrolysis of ATP.

Reference, in format PMID:#######

PMID: 38886340

Gene product name and ID to be annotated to this term
rft1

pombe https://www.pombase.org/gene/SPBC887.19
human https://www.uniprot.org/uniprotkb/Q96AA3/entry
cerevisiae https://www.yeastgenome.org/locus/S000000116

Parent term(s)

GO:0140327   floppase activity

Synonyms (please specify, EXACT, BROAD, NARROW or RELATED)

M5GN2-PP-Dol flippase activity
Man(5)GlcNAc(2)-PP-dolichol translocator
Man5GlcNac2-PP-Dol ER flippase activity

Other
correct spelling exoplasmic leaflet -> leaflet in flippase and floppase

Maybe that's because offically it is a floppase. Flippase seems to be used generically...
This paper calls it a"flippase"
These data, combined with in vitro results demonstrating substrate selectivity and rft1∆ phenotypes, confirm the molecular identity of Rft1 as the M5GN2-PP-Dol ER flippase.

Woah thats confusing. For organelles, floppases  , from the cytosolic side (inner leaflet) to the lumenal side (outer leaflet).
So these  are floppases...

WRT flippase and floppase: @marcfeuermann and I had looked at this, and the flippase flips the molecule from the exoplasmic to the cytosolic leaftlet of a membrane, while the floppase flips from the cytosolic to the exoplasmic leaftlet of a membrane.
Usage in the literature seems quite inconsistent.

WRT substrate: do we need such a specific substrate? I suppose this is the specificity of the transporter? Currently the human gene is annotated to GO:0034202 glycolipid floppase activity; is this not specific enough?
Thanks, Pascale
glycolipid floppase activity

glycolipid floppase activity

Is there a flippase vs floppase distinction to be observed here (independent of the issue of what specifically is getting flipped / flopped)?

I thought we should,  because of its importance in oligosaccharide and GPI biosynthesis, and according to chat GPT, it is quite distinct  (see below).  For this reason, I did not suggest a glycolipid parent. It also took 20 years to unambiguously locate it. For a while thought it was still not located until I found this paper. confirming that it was, in fact, rft1.  Precise annotation here would have saved me a few hours because I went on a function hunt last night, and made a prediction for an unknown which I now had to retract.
Man(5)GlcNac(2)-PP-dolichol: The structure includes a lipid (dolichol) and a sugar chain (Man(5)GlcNac(2)) linked through a pyrophosphate (PP) group. While it has a lipid and sugar components, its primary role is in transferring the sugar chain to proteins or other lipid molecules rather than functioning as a glycolipid.
In summary, while Man(5)GlcNac(2)-PP-dolichol contains both lipid and carbohydrate components, it is not classified as a glycolipid because its primary function is to act as a glycosyl donor in biosynthesis rather than as a structural component of membranes.

Is there a flippase vs floppase distinction to be observed here (independent of the issue of what specifically is getting flipped / flopped)?

You mean a directionality. I hadn't considered that. I presumed it was only moving the Man(5)GlcNac(2)-PP-dolichol into the ER...will look...

I guess the experiments don't distinguish:
Rft1 protein is required for M5GN2 flipping
Rft1 is specific for M5GN2-PP-Dol translocation
but presumably, only floppase is functionally relevant?

but presumably, only floppase is functionally relevant?

This seems right to me.

You mean a directionality.

Nothing that sophisticated - I was reading out of order and didn't realize that the flippase / floppase distinction had already come up in the thread and been handled. Sorry for the confusion.

Hi Val,
I recently updated human RTF1 in UniProt and at that time the MF was still unclear : "However, the intramembrane lipid transporter activity could not be confirmed in vitro". Once you are done with your update, please let me know. I will check what I can do from my side to better represent current knowledge for these proteins.
Thanks.

Hi @lbreuza great,  this is very recent (June), so I didn't expect it to be annotated yet, I was only pointing out the usefulness of the specificity of the annotation.
The floppase I was actually looking for wasn't  this one. I got confused, I'm looking for  the floppase that transfers dolichol-P-mannose in GPI biosynthesis  if anyone knows the identity of that one. That's the one I haven't been able to locate.

But you are asking for the new term right? RTF1 is currently curated with GO:0034202 | glycolipid floppase activity by Reactome which is maybe sufficient. The term you requested seems very specific.

Hi @lbreuza
Actuially you are correct. When I opened the ticket I was thinking about the "dolichol-P-mannose floppase" which isn't a glycolipid  and is still not known.
This (rft1)  is currently the only example of a glycolipid floppase so we don't need an additional term.
Instead I will add as a synonym.
We can always add specificity  if new classes arise.
Thnaks!

Close?

I wan't to add narrow synonym and fix a couple of typos I spotted, keep open and I'll do it on my next GO day


woah look at this

/evaluate

/evaluate

ooo, I imagine you broke the app with that retrieval mode change! That's likely why the action failed. Thanks for coming to the session!
For your reference, here are my slides:
https://speakerdeck.com/pamelafox/github-universe-evaluating-rag-apps-in-github-actions
And the main repo this was based on:
https://github.com/pamelafox/rag-postgres-openai-python/
with evaluation guide here:
https://github.com/Azure-Samples/rag-postgres-openai-python/blob/main/docs/evaluation.md
To evaluate on Azure,
Azure AI Eval SDK docs are here:
https://learn.microsoft.com/en-us/azure/ai-studio/how-to/develop/evaluate-sdk
And if you're interested in the Azure AI CI/CD private preview, sign up here:
https://aka.ms/genAI-CI-CD-private-preview


Choose random free SSH port for GVPROXY

If the default SSH port 2222 is inaccessible
choose next available port.
See issue #230: when the default port 2222 is inaccessible the service fails to start.
Choosing a random accessible port often helps and improves launch of /app/wsl-vpnkit rig.
Fixes issue #230

Hi everyone,
Take note if you want to use this fix:
If you keep this git repo inside WSL and want to build the distro wsl-vpnkit.tar.gz with ./build.sh <image_name>, you first want to change new line sequences from Windows-style CRLF to Unix-style LF. Otherwise I didn't manage to build.


Cann't build this code on Windows 7 VS2015

Hi
I cann't build this sourcecode on windows 7
get some error  about namespace.

Hi there, could you please include the errors/console output here in this issue?

clip_win.obj : error LNK2005: "public: __thiscall clip::lock::impl::impl(void *)" (??0impl@lock@clip@@QAE@PAX@Z) already defined in clip_none.obj
clip_win.obj : error LNK2005: "public: __thiscall clip::lock::impl::~impl(void)" (??1impl@lock@clip@@QAE@XZ) already defined in clip_none.obj
clip_win.obj : error LNK2005: "public: bool __thiscall clip::lock::impl::clear(void)" (?clear@impl@lock@clip@@QAE_NXZ)already defined in clip_none.obj
.......
........

I am sorry,It's my fault,I use Qtcreator to build on windows We must remove clip_none.cpp,and built it ok on win7 vs2015
thx

No problem, I'm glad to hear that 👍


grpc_interop_tocloud failed to build dart due to closed connection

https://source.cloud.google.com/results/invocations/150572fc-91b8-4908-8eeb-63ea678cd0ab/targets/grpc%2Fcore%2Fpull_request%2Flinux%2Fgrpc_interop_tocloud/log
Downloading watcher 0.9.7+10...
Downloading html 0.13.3+3...
Downloading utf 0.9.0+5...
Downloading csslib 0.14.4...
Connection closed before full header was received
+ EXITCODE=69
+ docker rm -f build_grpc_interop_dart_1ada417c-fdbc-4a7b-84da-c53fde309d3d
build_grpc_interop_dart_1ada417c-fdbc-4a7b-84da-c53fde309d3d
+ exit 69
2018-08-30 23:16:51,389 FAILED: build_docker_dart [ret=69, pid=9204, time=227.3sec]

Similar problem:
+ git branch -f jenkins-docker
++ uuidgen
+ CONTAINER_NAME=build_grpc_interop_dart_1f334385-ee10-42a0-a0cb-a1de08674640
+ docker run --cap-add SYS_PTRACE -e CCACHE_DIR=/tmp/ccache -e 'THIS_IS_REALLY_NEEDED=see https://github.com/docker/docker/issues/14203 for why docker is awful' -e 'THIS_IS_REALLY_NEEDED_ONCE_AGAIN=For issue 4835. See https://github.com/docker/docker/issues/14203 for why docker is awful' -i -v /tmpfs/src/github/grpc:/var/local/jenkins/grpc:ro -v /tmpfs/src/github/grpc-java:/var/local/jenkins/grpc-java:ro -v /tmpfs/src/github/grpc-go:/var/local/jenkins/grpc-go:ro -v /tmpfs/src/github/grpc-dart:/var/local/jenkins/grpc-dart:ro -v /tmpfs/src/github/grpc-node:/var/local/jenkins/grpc-node:ro -v /home/kbuilder/service_account:/var/local/jenkins/service_account:ro -v /tmp/ccache:/tmp/ccache --name=build_grpc_interop_dart_1f334385-ee10-42a0-a0cb-a1de08674640 grpctesting/grpc_interop_dart_16152abc97a05192d2d21c503f961feacf7e3d53 bash -l /var/local/jenkins/grpc/tools/dockerfile/interoptest/grpc_interop_dart/build_interop.sh
stdin: is not a tty
Cloning into '/var/local/git/grpc-dart'...
done.
Resolving dependencies...
The current Dart SDK version is 2.0.0-dev.67.0.
Because interop requires SDK version >=2.0.0 <3.0.0, version solving failed.
+ EXITCODE=1
+ docker rm -f build_grpc_interop_dart_1f334385-ee10-42a0-a0cb-a1de08674640
build_grpc_interop_dart_1f334385-ee10-42a0-a0cb-a1de08674640
+ exit 1
2018-09-21 16:18:43,663 FAILED: build_docker_dart [ret=1, pid=8393, time=216.1sec]

@muxi  the problem you've mentioned is a different thing - it was resolved by https://github.com/grpc/grpc/pull/16581

Stale.


About us page

Suggest some design or create a static about us page
Regarding 2 owners of the company

http://webdeveloperbareilly.in/blog/demo/Bootstrap-About-Us-Page-Design.html

Nice design
I would rather suggest to take 1 row per member entry in that container rather than showing 2 members in 1 row

Static about us page is created
Make it dynamic, create a table in DB and retrieve data from it

Ohk...Boss

About us page made dynamic tested online


v4: inlineRem not working

Describe the bug
Setting inlineRem in withNativeWind has no effect
module.exports = withNativeWind(config, {
  projectRoot,
  input: "./global.css",
  inlineRem: 16,
});

Additional context
The options doesn't seems to be propagated from the metro config up to react-native-css-interop since the parseLength function works correctly.
Applying this temporary fix works for changing the inlineRem.
 function parseLength(length, options) {
-    const { inlineRem = 14 } = options;
+    const { inlineRem = 16 } = options;

Fix the latest alpha


The GitHub page's buttons are redirecting to 404 not found

Hello,
In the GitHub page, there are two buttons: Get Started and Docs on the bottom. They are leading to https://typicode.github.io/mistcss/mistcss/intro and https://typicode.github.io/intro and it looks like not set up properly. It contains mistcss twice in the url, and the other one doesn't contain.

Thanks for the heads up! Should be good. Let me know if you find other issues, I just published the new docs.

Looks good! I am closing the issue.


Sleeping in a Spin app breaks traces

Traces are not properly emitted when a Spin app sleeps.
The commit that introduced this regression is most likely here.
e.g.
use spin_sdk::http::{IntoResponse, Response};
use spin_sdk::http_component;
use spin_sdk::observe;

/// A simple Spin HTTP component.
#[http_component]
async fn hello_world(_req: http::Request<()>) -> anyhow::Result<impl IntoResponse> {
    std::thread::sleep(std::time::Duration::from_millis(500));
    Ok(Response::new(200, "Hello, world!"))
}

(As discovered by @calebschoepp) Disabling metrics fixes this. Seems probable that this is an upstream tracing-opentelemetry or opentelemetry bug.

Potentially related to #2525


Editor ribbon cannot be expanded once collapsed

Clicking the little arrow on the ribbon to collapse the icons works, but clicking it again to expand them fails with a console message. EDIT: introduced in #1092, I think. EDIT: reverting 61e106251 made no difference. Hmm.

There's code that looks like this:
%this.setExtent((29 + 4) * %count + 12, 33);

Which is somehow causing setExtent to set the extent to 33, 33. Um, what? It works if I do this:
%x = (29 + 4) * %count + 12;
%this.setExtent(%x, 33);

And also if I change setExtent to take Strings instead of const char*s. @jamesu could this be one of yours?

I'll have a look and see whats going on

Ok the problem is with these fancy DefineConsole* methods, when it unmarshalls and converts those two values to strings according to the function definition it uses the same buffer (i.e. Con::getReturnBuffer) to store the value, thus each value becomes 33.
Accepting String instead is a reasonable workaround, though really the console code should print these values to a temporary buffer space since quite a few functions seem to use const char* as parameters.
I'll see if I can cook up a good workaround.

Ok I have a fix, just testing and I'll submit a PR.

Awesome, really appreciate it! I submitted the String fix in case you didn't have time to look into it, but we have a couple of other things to do for 3.7 so hopefully we can get the proper fix in. I'm surprised this hasn't turned up as a problem elsewhere.

Pushed fix. Ideally this problem should be resolved in a better way but this will do for now.

Thanks for that. I'm going to test this and revise the other outstanding PRs tomorrow.


sandbox-api.polar.sh refused to connect

Description
I'm integrating the checkout embed into a Next.js app. The script is loading correctly and after clicking the button that opens the checkout i get a loader on the screen but after a second I get a "sandbox-api.polar.sh refused to connect.":

This is the embed used:
<a
  href={`https://sandbox-api.polar.sh/v1/checkout-links/polar_cl_fASA4TcqKZAk4HMD7v_jnD1QWmISiQIfTJGtCQR6-lI/redirect`}
  data-polar-checkout
  data-polar-checkout-theme="dark"
  className={`block w-full px-4 py-2.5 rounded-lg text-sm font-medium transition-all duration-200 text-center ${plan.style.button}`}
  >
  {plan.buttonText}
</a>

Current Behavior

Displays a gray screen saying "sandbox-api.polar.sh refused to connect." when opening the embed.

Expected Behavior

Should display the embed inside the app.

Environment:

Operating System: macOS
Browser (if applicable): Chrome

found the error, it wasn't related to polar. i had headers on my middleware that were blocking access to polar.sh:
  response.headers.set('Cross-Origin-Opener-Policy', 'same-origin')
  response.headers.set('Cross-Origin-Embedder-Policy', 'require-corp')

closing this now!


policy: Add refactor carve out

I have managed to burn out or bore our reviewers/maintainers. Getting two acks is becoming increasingly difficult. I've pestered everyone to the limit that I feel socially comfortable doing so am requesting a carve out to the 2-ACK before merge rule.
The primary justification is that I feel we should have a bit more of BDFL and a bit less total consensus if we are to push forwards.
Example PRs where this change would apply

https://github.com/rust-bitcoin/rust-bitcoin/pull/1925
https://github.com/rust-bitcoin/rust-bitcoin/pull/1854
https://github.com/rust-bitcoin/rust-bitcoin/pull/1862

Good luck getting other ACKs on this :).

In my experience with bitcoin core, if you don't get enough ACKs, it just gets closed instead of merged.  I don't know why rust-bitcoin should be different?

@yancyribbens the main reason to be different is that Bitcoin Core is much more "feature complete" than this library. As far as its role of being a p2p node enforcing the exact consensus rules, it's more-or-less done. With a few big exceptions, like BIP-324, which are self-contained projects that nonetheless take multiple years to spec and implement.
Another reason is that Bitcoin Core, as developer-starved as it is, actually has more active maintainers and contributors than rust-bitcoin.
Finally, despite both these reasons, Core does struggle with a lack of momentum on its non-core functionality. And there's a lot of effort being put into separating out the wallet, GUI, RPC, etc., into separate binaries and eventually even separate repos, so that these other things can move more quickly. It's acknowledged that the Core "most things die on the vine" development model is maybe alright for the core consensus stuff but it's not the right model for less-critical user-facing stuff.
I'd argue that rust-bitcoin doesn't have anything like "core consensus stuff" (maybe the libsecp bindings come close) and that the whole project probably should shift toward a faster-moving model.

Some mentions and further arguments to back up this PR and attempt to get it in:

@stevenroose suggested that we move too fast and that he wants time to NACK, this fits in with that because it gives two weeks for NACKs
@TheBlueMatt mentioned by email that he is too busy so this PR should be ok with him
@sanket1729 mentioned here on github that he is allocating some time to reviews, 2 weeks should be enough for him to see the things he wants to and ignore the things he does not
@RCasatta, IIRC said he is bored of all the refactoring
@Kixunil is on holiday at the moment
@elichai I can't remember if your position on this whole thing :)

I guess this PR needs more than 2 ACKS :)

Yes, I think we should leave this open for 2 weeks to wait for NACKs.

I will email all maintainers to flag this PR, that way any that do not see notifications will not get rugged by this. I sure wish we had a public mailing list so there was public proof that I send the email.

For the reasons @apoelstra mentioned, it makes sense for rust-bitcoin to be more permissive than bitcoin.   However I don't think two acks is very uncommon in my experience with other projects and I don't understand why it's so difficult to get two acks here.  Maybe there needs to be more dedicated maintainers?  I'm not sure what the process is to becoming a maintainer.

I agree this makes sense for refactors ACK 55be538dac10ceca3da5866a3438fa15dda56327

I don't understand why it's so difficult to get two acks here.

You could read over the 600 patches that I did in the last 18 months and see if you are still enthusiastic about reviewing refactor work :)

You could read over the 600 patches that I did in the last 18 months and see if you are still enthusiastic about reviewing refactor work :)

I'm fine to help review.  I'm not a maintainer so my acks don't matter however :)

Yeah I think I can ACK this. I was indeed saying I think a minimim review period would be good. I actually think 2 weeks + 1 ACK is a way saner merge policy than any 2 ACKs (I've seen merge times of less than a day :sweat_smile:)

Ack https://github.com/rust-bitcoin/rust-bitcoin/commit/55be538dac10ceca3da5866a3438fa15dda56327

That is an ack from every maintainer except @Kixunil.

Can we merge this @apoelstra? I believe that the following three PRs are also good examples of minor fixes that no one cares enough about to review and are harmless to merge.

https://github.com/rust-bitcoin/rust-bitcoin/pull/1947
https://github.com/rust-bitcoin/rust-bitcoin/pull/1933
https://github.com/rust-bitcoin/rust-bitcoin/pull/1914

Yes, but I also can't think of a way.
And sure, I'll merge this. We are technically 6 hours short of 2 weeks here :P. But we are only waiting on Kix's approval, and I don't think his absense should override six ACKs.

Awesome, onwards and upwards!


Georeference component refactoring / fixes

Potentially fixes #422, #494, #498
Copying @javagl's notes:

The CesiumGeoreferenceComponent now an ActorComponent, and no longer a SceneComponent. So it does not have a "transform" on its own. (This transform had to be ignored in the old state).
It's now using the Ellipsoid of the GeoRef instead of the fixed WGS84
The representation of the "position" is now solely encoded in the ECEF_X/Y/Z properties. Originally, it had at least 3 (but I think maybe even 5 or 6) representations of "the position", and keeping them consistent was hard.

The goal is to merge into bp-function-library after verifying a) correct behavior of georeferenced objects, and b) backwards compatibility with georeferenced actors created with the old version of this component.
@nithinp7 mentioned some issues with the sun sky, there is another PR #497 which refactors the CesiumSunSky, which will get merged into bp-function-library. Probably best to wait to debug SunSky specific issues until this PR and #497 get merged into bp-function-library.

Thanks for the pull request @xuelongmu!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

@javagl Just did a test with creating a georeference component from the old bp-function-library state, migrating to this branch, and opening it. Seems like UE is crashing on startup, with the attached log.
When running in debug mode, it stops executing on the following method in MulticastDelegateBase.h
	/**
	 * Removes all functions from this multi-cast delegate's invocation list that are bound to the specified UserObject.
	 * Note that the order of the delegates may not be preserved!
	 *
	 * @param InUserObject The object to remove all delegates for.
	 * @return  The number of delegates successfully removed.
	 */
	int32 RemoveAll( const void* InUserObject )
	{
		int32 Result = 0;
		if (InvocationListLockCount > 0) // Stops here
		{
			for (TDelegateBase<UserPolicy>& DelegateBaseRef : InvocationList)
			{
				IDelegateInstance* DelegateInstance = DelegateBaseRef.GetDelegateInstanceProtected();

CesiumDevTest2.log

A general note, for the review process: The ApplyWorldOffset implementation currently is not implemented properly. (I'm trying to figure out a solution there - the function is called before the origin has been changed, so some computations are simply happening on the old origin where they should already use the new one - I hope that this can be fixed easily, but ... finding an easy and clean solution is the hard thing right now...).

The ApplyWorldOffset implementation currently is not implemented properly.

I was actually wondering about this...I think custom logic for ApplyWorldOffset should only be needed if FixTransformOnOriginRebase = true. IIRC the method is only called at runtime when world origin rebasing occurs, and UE4 by default will shift actors' positions during origin rebasing so that they're in the same consistent location after the new origin has been set. FixTransformOnOriginRebase = true takes it a step further by assuming that UE4's default handling is inaccurate due to floating point errors, and "corrects" it with the double precision ECEF position.

Another startup crash when migrating from the old georeference component implementation to the new:
CesiumDevTest2.log
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000540

UE4Editor_CesiumRuntime!glm::operator*<double,0>() [C:\Users\Xuelong\Dev\CesiumDevTest2\Plugins\cesium-unreal\Source\ThirdParty\include\glm\detail\type_mat4x4.inl:568]
UE4Editor_CesiumRuntime!UCesiumGeoreferenceComponent::OnComponentCreated() [C:\Users\Xuelong\Dev\CesiumDevTest2\Plugins\cesium-unreal\Source\CesiumRuntime\Private\CesiumGeoreferenceComponent.cpp:322]
UE4Editor_Engine!USCS_Node::ExecuteNodeOnActor() [D:\Build\++UE4\Sync\Engine\Source\Runtime\Engine\Private\SCS_Node.cpp:116]
UE4Editor_Engine!USimpleConstructionScript::ExecuteScriptOnActor() [D:\Build\++UE4\Sync\Engine\Source\Runtime\Engine\Private\SimpleConstructionScript.cpp:645]
UE4Editor_Engine!AActor::ExecuteConstruction() [D:\Build\++UE4\Sync\Engine\Source\Runtime\Engine\Private\ActorConstruction.cpp:765]

I was also wondering about this, as indicated by the commented-out
  /*
  // TODO GEOREF_REFACTORING Figure out how to handle this...
  if (this->FixTransformOnOriginRebase)
  {
    this->_updateActorTransform();
  }
  */

...
But I just started working on that: I it should be possible to not call _setECEF there at all, because the rebasing should not affect the ECEF, and thus, should not affect the core state of the component (which now is only the ECEF). But I assume that when FixTransformOnOriginRebase==true, the actor position has to be updated with a new "relativePosition" that is computed from the current ECEF and the new world origin.

The new crash looks like a Georeference==null case, but ... it should be initialized directly before that. I'll try to have a look later (focussing on the world offset right now - I have another task, but should be able to figure out a solution a bit later today).

And sometimes, a small "improvement" may lead to hours of debugging. https://github.com/CesiumGS/cesium-unreal/pull/518/commits/7ccd6fa1a31aa1e877828a71b716433a5fdd2562 was not a good idea. The matrices are in absolute space. The conversion functions are in relative space. The fact that
const glm::dvec3 absoluteLocation =  this->Georeference->TransformEcefToUnreal(ecef);

is "wrong" but
const glm::dmat4& ecefToUnreal = this->Georeference->GetEllipsoidCenteredToUnrealWorldTransform();
const glm::dvec3 absoluteLocation = ecefToUnreal * ecef;

is "right" is ... subtle.
Sure, I should have had that on the radar, I'm stupid, and all this is purely my fault. But... we reeeally should get these method names sorted out somehow.
I'm currently trying to clean that up, along with some comments like
  // Do NOT use TransformEcefToUnreal, because it will return the
  // position relative to the current world origin!

to prevent future maintainers from making the same mistake again.

I hope that the wrong change that I mentioned above is properly un-done now, and origin rebasing seems to work according to my basic test: Loading a level that was created in main and hitting "Start" causes the GeoRef'ed Actor to remain at the right position, also when moving around and the unreal-internal origin rebasing messages appear in the console.
I'll do further tests ASAP, try to reproduce the startup crashes, and see whether the "maintain orientation" thing can be done with a glm::rotation (maybe later today, after another task, or early tomorrw).

Based on some discussion, we removed the "high-precision" version functions from the CesiumGeoreference in https://github.com/CesiumGS/cesium-unreal/pull/518/commits/62cc0112873da4bbab976626a0039c5e4c76d3bc .
A quick summary: Before this, most of the functions of the georeference had been offered in two flavors:

one function that operated on glm data structures with double precision
one function that operated on the Unreal data structures (like FVector), with single precision.

The second one was mainly offered so that the functions could be used from Blueprints, being declared as BlueprintCallable. Generally, these functions had the same name, except for the second one being prefixed with Inaccurate - for example:
glm::dvec3 TransformLongitudeLatitudeHeightToEcef(
const glm::dvec3& LongitudeLatitudeHeight) const;
UFUNCTION(BlueprintCallable, Category = "Cesium")
FVector InaccurateTransformLongitudeLatitudeHeightToEcef(
const FVector& LongitudeLatitudeHeight) const;
The actual implementations of the high-precision functions had already been moved to a dedicated class (currently called GeoTransforms -  the reasoning for this is explained in https://github.com/CesiumGS/cesium-unreal/issues/330#issuecomment-859057502 ). So the implementations of these functions had usually been in the pattern of
glm::dvec3 TransformLongitudeLatitudeHeightToEcef(const glm::dvec3& LongitudeLatitudeHeight) const {
return _geoTransforms.TransformLongitudeLatitudeHeightToEcef(LongitudeLatitudeHeight);
}
These functions have been removed now. Somebody who wants to use these high-precision functions via the C++ API can obtain the GeoTransforms instance from the georeference, and call the function directly.

There may be one exception for the removal of the high-precision functions: Some of the functions use the current world origin. Originally, the world origin had been obtained from the GeoRef internally, causing the call to look like
glm::dvec3 ecef = georeference->TransformUeToEcef(relativeUnreal);

But now, the same computation requires something like
const FIntVector& worldOrigin = GetWorld()->OriginLocation;
const glm::dvec3 origin = glm::dvec3(worldOrigin.X, worldOrigin.Y, worldOrigin.Z);
glm::dvec3 ecef = georeference->getGeoTransforms().TransformUnrealToEcef(origin, relativeUnreal);

which is clumsy (also considering that the GetWorld would have to be wrapped into IsValid checks...)
As mentioned above : The fact that TransformEcefToUnreal does something completely different than the matrix that is obtained with GetEllipsoidCenteredToUnrealWorldTransform already caused confusion, and will likely cause confusion in the future, so one could argue about this function in the first place. But I'd at least like to avoid the clumsiness that comes from the world origin part, and offer these functions, maybe renamed to emphasize the difference a bit:
glm::dvec3 ecef = georeference->TransformRelativeUnrealToEcef(relativeUnreal);
//                                       ^ Replace "Ue" with "RelativeUnreal"

Yes, it's verbose, but when there is a (buggy) line like
glm::dvec3 ecef = georeference->TransformRelativeUnrealToEcef(absoluteLocation);

then the terms "relative" and "absolute" appearing in that line might be a valuable hint that something is wrong there...

After some hesitation, I restored several (most of) the high-precision functions that had previously been removed, for the reasons mentioned in the last comment.
Some functions require the world origin and others don't. Some transforms use the absolute Unreal coordiantes and some functions use the relative ones. Sometimes, the conversion between relative and absolute coordinates is done by passing in the relative position and the origin, and doing the rel+origin part (or a abs-origin) at the very end. It's probably not possible to make this totally consistent, but maybe it's possible to somehow limit the confusion that this will cause at the user side.

To keep track of migration steps that might be necessary when the refactoring is merged:

Some functions have essentially just been renamed, to replace the Ue part with Unreal. This refers to functions like TransformUeToEcef  and TransformEcefToUe which are now called TransformUnrealToEcef and TransformEcefToUnreal, respectively.
(I'm still considering to extend that to RelativeUnreal before the merge, to make the crucial distinction between "absolute Unreal world" and "relative Unreal world" clearer...)

The function
UCesiumGeoreferenceComponent::MoveToECEF(
  const glm::dvec3& targetEcef,
  bool maintainRelativeOrientation)

receives a maintainRelativeOrientation parameter (and sometimes this is passed in from other functions, so this will affect the calling functions as well, and which ones these are still has to be listed somewhere). This parameter has not been properly taken into account in all cases. (The exact conditions under which this happened could be analyzed further, but may not be relevant). Some people seem to have anticipated this wrong behavior, and called things like
// Move the pawn.
georeferenceComponent->MoveToECEF(startEcef);

with maintainRelativeOrientation defaulting to true, but then expected the relative orientation to not be maintained. (And "expected" indeed refers to the level of unit tests here...). These call sites will have to call
// Move the pawn.
georeferenceComponent->MoveToECEF(startEcef, false);

explicitly in the future.

Thanks for the valuable insights here @javagl. I agree with the call you made to put high precision functions back into CesiumGeoreference, keeping the user-facing API clean and easy to use would be the priority.

Some callers may have used the functions that have been removed together with the CesiumGeoreferenceable interface

Given that the bounding volume is used rarely, I think that the refactored code is still OK despite its clumsiness.

Great work @javagl! I only had a minor suggestion, otherwise this is ready to merge.
You can hold off on reviewing the cpp-sun-sky branch until this PR is merged, as there are a couple improvements I want to make there based off the CesiumSunSky in this branch.

Thanks @javagl!


Corporate tax

This PR adds a corporate income tax on the representative firm.  This allows for some level of business tax analysis in OG-USA and also helps with the calibration of the fiscal parameters.
A future PR will add differentiation of the firms (e.g. corporate and non-corporate, etc).

Not technically related to these changes, but the previous PR introduced an error when running with small_open=True and budget_balance=False in Line 713 of TPI.py. It's an easy fix - D & G just need to be created earlier. We could include it in this PR or do a separate one.

@salimfurth - thanks for pointing that out.  I'll take a look and fix in this PR.

A more substantive question, @jdebacker: would it be easy to put in a deduction, so that the marginal rate > average rate? That would go a long way toward matching the incentives faced by real world firms.

Yes - we can do that.  Let me open an issue to discuss.


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/eventing-writers lberk
/assign knative-sandbox/eventing-writers lberk
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping k8s.io/client-go b425fb6...97582f2:
  > 97582f2 Update dependencies to v0.23.5 tag
bumping knative.dev/eventing 5df47e1...3890b39:
  > 3890b39 Wathola Tracing for upgrade tests (# 6219)
  > eb2bfff upgrade to latest dependencies (# 6288)
  > 7001b65 upgrade to latest dependencies (# 6286)
  > 4be06cd Feature/keep ports for service (# 6283)
  > 5081edd Drop sendevent tool since there is kn-plugin-event (# 6284)
  > a27ee9e Use env config for tests instead of hardcoded configs (# 6282)
  > 9b9cdee Adding code of conduct to reference knative/community's CoC (# 6281)
bumping k8s.io/api a1613d7...cd271e7:
  > cd271e7 Update dependencies to v0.23.5 tag
  > a6b2207 Merge pull request # 108139 from liggitt/automated-cherry-pick-of-# 108138-upstream-release-1.23
  > 80b93d4 Revert v1beta1 PodDisruptionBudget select patchStrategy
bumping k8s.io/apimachinery 276a8a7...276a8a7:
bumping knative.dev/pkg e6e3cf0...1f7514a:
  > 1f7514a bump k8s deps to v0.23.5 (# 2469)
  > 19a2589 fix coverage settings (# 2471)
  > 2daa86a Electors can provide an initial set of buckets (# 2473)
bumping knative.dev/hack 14f832e...f067737:
  > f067737 Adding code of conduct to reference knative/community's CoC (# 162)

/lgtm
/approve


Change the Git timeout in the Global pane of the plugin settings

Hi !
I've been working on a redmine-githosting migration from redmine 1.2 to redmine 2.5 ; The plugin version used is 0.7.7.
I have a huge repo from my old server that I push to the new server.  In debug mode, the hook display this message :
remote: Notifying Redmine about changes to this repository : 'xxxx' ...
remote: Redmine URL : 'http://server.fqdn.name/githooks/post-receive/redmine/xxxx'
remote: HTTP_ERROR : Timeout::Error
remote: Error contacting Redmine about changes to this repo.

I guess it is related to the git timeout in the global pane. But when I change it to something bigger, the value "comes back" to 10. In redmine, everything seem to be in order ...
For my personnal knowledge, what kind of notifying is done at this level ?

I'm having the same problem now on 1.2.1 (previously 1.1.2). We cannot switch to async mode as we need be sure that the git mirror has been updated once the push is done (needed for reviewboard).
What changed since 1.1.2 that broke this?
Should I simply increase the timeout? (If yes: how?)

I'm having the same problem now on 1.2.1 (previously 1.1.2). We cannot switch to async mode as we need be sure that the git mirror has been updated once the push is done (needed for reviewboard).
What changed since 1.1.2 that broke this?
Should I simply increase the timeout? (If yes: how?)

In order to get rid of HTTP_ERROR : Net::ReadTimeout error, just add a read_timeout in http request ->
--- a/lib/redmine_git_hosting/utils/http.rb
+++ b/lib/redmine_git_hosting/utils/http.rb
@@ -61,6 +61,7 @@ module RedmineGitHosting
def build_http_request(url)
uri  = URI(url)
http = Net::HTTP.new(uri.host, uri.port)

     http.read_timeout = 50000 # in seconds
     if uri.scheme == 'https'
       http.use_ssl = true
       http.verify_mode = OpenSSL::SSL::VERIFY_NONE


[1.12.2-0.0.4] - /profile c 10 returns Could not process command (NPE)

When running /profile c 10, the following error shows up in chat: An Unknown error occurred while attempting to run this command and the following is logged to the server console:
[22:20:54] [Server thread/WARN] [net.minecraft.command.CommandHandler]: Couldn't process command: profile c 10
java.lang.NullPointerException: null
        at org.minimallycorrect.tickprofiler.minecraft.profiling.EntityCountingProfiler.start(EntityCountingProfiler.java:34) ~[EntityCountingProfiler.class:?]
        at org.minimallycorrect.tickprofiler.minecraft.profiling.Profile.start(Profile.java:52) ~[Profile.class:?]
        at org.minimallycorrect.tickprofiler.minecraft.commands.ProfileCommand.process(ProfileCommand.java:71) ~[ProfileCommand.class:?]
        at org.minimallycorrect.tickprofiler.minecraft.commands.ProfileCommand.processCommand(ProfileCommand.java:30) ~[ProfileCommand.class:?]
        at org.minimallycorrect.tickprofiler.minecraft.commands.Command.func_184881_a(Command.java:45) ~[Command.class:?]
        at com.feed_the_beast.ftbutilities.ranks.CommandOverride.func_184881_a(CommandOverride.java:82) ~[CommandOverride.class:?]
        at net.minecraft.command.CommandHandler.func_175786_a(CommandHandler.java:119) [bj.class:?]
        at net.minecraft.command.CommandHandler.func_71556_a(CommandHandler.java:91) [bj.class:?]
        at net.minecraft.network.NetHandlerPlayServer.func_147361_d(NetHandlerPlayServer.java:958) [pa.class:?]
        at net.minecraft.network.NetHandlerPlayServer.func_147354_a(NetHandlerPlayServer.java:937) [pa.class:?]
        at net.minecraft.network.play.client.CPacketChatMessage.func_148833_a(SourceFile:37) [la.class:?]
        at net.minecraft.network.play.client.CPacketChatMessage.func_148833_a(SourceFile:9) [la.class:?]
        at net.minecraft.network.PacketThreadUtil$1.run(SourceFile:13) [hv$1.class:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_171]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_171]
        at net.minecraft.util.Util.func_181617_a(SourceFile:528) [h.class:?]
        at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:723) [MinecraftServer.class:?]
        at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:396) [nz.class:?]
        at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:668) [MinecraftServer.class:?]
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526) [MinecraftServer.class:?]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]

https://github.com/MinimallyCorrect/TickProfiler/blob/8656b0db8c886312ab364ecd013ae62e3f3a970e/src/main/java/org/minimallycorrect/tickprofiler/minecraft/profiling/EntityCountingProfiler.java#L34
world here is null, which shouldn't happen.
What mods are you running? Are you using sponge?

We are NOT using Sponge.  We are running ATM3, v5.9.6b, which has many, many mods in it.

We're using RFTools dimensions and some space mod as well, each of which add dimensions, and I can see from line 33 that world is pulled from worldList.  It is quite possible that there is an entry in worldList that is null, possibly caused by one of these other mods.  I feel that TickProfiler should skip any worlds in the world list that are null.

List of all mods: https://gist.github.com/JaSpr/1bc5e70433c88bb891cb6f95fc80fe5c

Unfortunately, that error was for /profile c 10, and the blank list is for /profile e 10.
When I run /profile e 10 I get the blank response (like in the screenshot in the initial request).  There is absolutely no log saying why it returned empty.
when I run /profile c 10 I get An Unknown error occurred while attempting to run this command, probably because of the NPE in the stack trace.  Should I split this into two separate tickets?

I have updated this ticket to be for the /profile c issue, while the /profile e issue can be found at #101

Interesting - I restarted my server this morning and got this same /profile c "unknown error" / "null pointer" issue. Only change was to remove the Unloader mod. Previously working yesterday while helping someone else diagnose their own server performance issues. Restart has not yet helped.

Any updates on this?
Is there a reason why this wouldn't work with Sponge. I can report this to Sponge.


Editor freezes when modifying FileSystem's filter path when in Split Mode

Tested versions

Reproducible in: v4.2.1.stable.official [b09f793f5]

System information
Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1050 (NVIDIA; <IP_ADDRESS>17) - Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz (8 Threads)
Issue description
While working on my project and navigating through folders in the FileSystem dock, I accidentally discovered a bug that causes Godot to crash. The crash can be triggered by either erasing the contents of the path field and then entering split mode or by erasing the contents while already in split mode and then pressing Enter. Considering the uncommon action of erasing path field content, not sure if worth reporting. New to game development and GitHub contributions.
Steps to reproduce

Open Godot Editor.
Navigate to the FileSystem dock.
Select the path field within the FileSystem dock.
Erase the contents of the path field.
While still in split mode, press the Enter key.
Observe the crash that occurs.

OR

Open Godot Editor.
Navigate to the FileSystem dock.
Select the path field within the FileSystem dock.
Erase the contents of the path field.
Switch to split mode.
Observe the crash that occurs.

Minimal reproduction project (MRP)
N/A

Tested, it's not crashing, it freezes.
Can't reproduce in:

v3.5.3.stable.official [6c814135b]
v3.6.beta3.official [21ab700f2]
v4.0.4.stable.official [fc0b241c9]
v4.1.3.stable.official [f06b6836a]
v4.2.dev3.official [013e8e3af]

Can reproduce in v4.2.dev4.official [549fcce5f] and newer.
It's a regression from #80440. Specifically this is the infinite loop causing the freeze (directory starts as an empty string):
https://github.com/godotengine/godot/blob/74c32faa78b54863f8f25c538083907c2bf71791/editor/filesystem_dock.cpp#L1028-L1040
This preceding part (not a part of #80440) seems problematic:
https://github.com/godotengine/godot/blob/74c32faa78b54863f8f25c538083907c2bf71791/editor/filesystem_dock.cpp#L1012-L1019
because EditorFileSystem::get_filesystem_path seems to resolve an empty path as the project root directory, making efd above be not null and hence not aborting further execution. But directory ends up still being an empty path.

Considering the uncommon action of erasing path field content, not sure if worth reporting. New to game development and GitHub contributions.

Any bug is worth being reported, regardless of its rarity. Crashes/freezes are especially frustrating so this report is definitely wanted, thanks! :slightly_smiling_face:

Did you test 4.3 builds? By this description I think this was fixed already by https://github.com/godotengine/godot/pull/86171

Did you test 4.3 builds?

I've run it with like a week-old master build to see where it's getting stuck at. Not with the latest master though.

Did you test 4.3 builds?

I can confirm it happens at current master.
The whole code here seems to assume the directory is always starts with "res://" instead of empty one.

The problematic field is not a filter path, it's a path to the selected file. It's likely meant to navigate to folders by name or for copying the current path, but there are better ways to do both, so I wonder if anyone is even using this field. We could make it uneditable or even remove it.


ThaliReplicationPeerAction: No activity timeout issue

The current implementation of ThaliReplicationPeerAction treats every action the same whether the BT or WiFi is used. The problem occurs when we use slow radios, such as Bluetooth. Replication doesn't even start or begin properly, because it is already killed by 3s timeout. This timeout is however more than enough if it comes to WiFi.
Because of that we often got into scenario, where we wanted to replicate with larger data, such as image, but we were not able to because replication was killed before it even started. After some additional changes, so additional attempts to start the replication, the data was replicated.
So the proposed solution to that problem could be to make 'No activity timeout' dependent on which radio is used in that particular replication action.

Yup, just make the timeout an argument that can be passed in by the policy manager.

Merged to master.


OpenAPI docs should be hosted somewhere

Forked from #78; it would be awesome to have the OpenAPI docs in master hosted somewhere.

Would love to see this, will make it easier to keep up with the current state of the API

@pmorie should it really be incumbent upon our project to host another project's documentation? I submit, no.

No, but we should our own openapi for the svc cat k8s api
On Mon, Mar 27, 2017 at 6:59 PM Kent Rancourt<EMAIL_ADDRESS>wrote:

@pmorie https://github.com/pmorie should it really be incumbent upon
our project to host another project's documentation? I submit, no.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/service-catalog/issues/453#issuecomment-289516316,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWXmCZD3NbV6i4OJ9nHegLNTLis11hmks5rp-sDgaJpZM4MQGCi
.

@pmorie @jwforres has anyone started on this? I am removing it from a milestone, but happy to re-add if someone is planning on doing the work.

As much as I dislike us checking in our generated code, it seems to me that if we're already doing that, then we could just check-in the openapi docs too and host it via our github repo, no?
I believe that are talks about removing generated code/docs from the main kube repo too and one idea was to remove it from the main repo but still host it some place else - once (if?) they do that we could leverage the same thing.  @spzala what's the status of that work?
If it doesn't look like this will happen soon in the main repo, we could give it a try in ours as a testbed to see how it works.

@duglin hi, I touch based on it little over a week back but didn't hear feed back. I have just added a reminder and mentioned this issue/discussion. Here is the issue that's in discussion in k8s https://github.com/kubernetes/kubernetes/issues/47361 Thanks!

+1

/remove-lifecycle rotten
/lifecycle frozen

This project is being archived, closing open issues and PRs.
Please see this PR for more information: https://github.com/kubernetes/community/pull/6632
/close


[ButterflyAspect] update to new rules

Changes / Comments

fix erfolgsgerade
add healing calculation (mage)
avoid error when healing below 0.5
add new ressource system
format code style with Prettier
remove random player (mage)
add extra damage (mage)
add darkmode
fix some typos

Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[ ] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


Feature: Backup Outline Collection in Repo

I would like to do a plain-text update of Outline collections.
Imagine I have a outline-backup repo on Gitlab. Once a week I want to schedule a CI job that runs something like outline export mycollection ./  so that all of the Outline documents in this collection get exported as markdown files (API supports this) and get committed to the Gitlab repo.

I think this would be done in an internal repo where documents are checked in right @chb-ioki ?

Well, well of course the backup run in an internally repo 😉 but the feature itself (exporting data from outline) should be implement in this repo. And this issue is about that. It's basically for documentation purposes so that everyone knows what to do/what the goal of this cli is at the end. Does it make sense?


Fix clippy warning

Fix this warning:
error: large size difference between variants
  --> pyo3-derive-backend/src/method.rs:56:5
   |
56 |     TryFromPyCell(syn::Type),
   |     ^^^^^^^^^^^^^^^^^^^^^^^^ this variant is 304 bytes
   |
   = note: `-D clippy::large-enum-variant` implied by `-D warnings`
note: and the second-largest variant is 1 bytes:
  --> pyo3-derive-backend/src/method.rs:55:5
   |
55 |     Receiver { mutable: bool },
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
help: consider boxing the large fields to reduce the total size of the enum
   |
56 |     TryFromPyCell(Box<syn::Type>),
   |                   ^^^^^^^^^^^^^^

, though I don't know why this is not detected by CI...

I think there's an issue #365 to add CI and testing for all crates?

No, we run make lint on travis Python3.8 :thinking:


fix(screen): center screen

:tada: This PR is included in version 0.9.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket: