Room - Member avatar changes after being invited to the room

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

Version Number: 1.4.21-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Issue found when executing PR https://github.com/Expensify/App/pull/33077
Action Performed:

Go to FAB > Start chat > Room
Create a room
Open room chat > Click room header
Click Members > Invite
Invite a few users with default avatar

Expected Result:
The member avatar will not change after being invited to the room
Actual Result:
The member avatar changes after being invited to the room
Each member shares the same default avatar after being invited to the room
Workaround:
Unknown
Platforms:

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

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

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/0af2bc63-0658-4bb9-ad53-12381d521ef2
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~018d16ed2710b34987
Upwork Job ID:<PHONE_NUMBER>455277568
Last Price Increase: 2024-01-26

Oh yeah, this does happen.

I think this can be part of vip-vsp.
I'm going ooo next week so adding a BZ teammate to monitor this while I'm gone.
Status- we need to review proposals.

I think we're still waiting on proposals - @ntdiary should we raise the bounty?

Thanks, @ntdiary! I'll loop in an internal engineer

Hey @grgia can you take a peek at this when you have a moment? https://github.com/Expensify/App/issues/34000#issuecomment-1894001332

I think I have an idea as to what's causing this, looking into it now

working on proposals/investigating the root of this

Adding a note that we're working on this for Melvin

this is already internal and we're working on a solution

Looks like you've got this issue sorted, @Christinadobrzyn. Please rope me back in if you need someone to take it over!

hi @grgia do you have an update by chance?

I should be able to fix this next week so I'm leaving daily, but this is more weekly-level priority

hi @grgia do you have an update on this by chance?

We're working on the fix Melvin!

hi @grgia do you have an update about this?

We're working on this - @grgia feel free to lave more of an update if needed!

we're working on this!

we're working on this! @grgia let us know if this should be moved to weekly.

yes @Christinadobrzyn moving to weekly!

Sorry for the delay here- here's my thoughts
We can probably solve some of these if we

start storing the avatar in the avatar field regardless of default or not (right now, we only store custom avatars for newdot)

The main problem I see is that because we now use accountIDs, something that we cannot predict for a new user- any user that is invited that doesn't have an account will not use the correct avatar. This is partially why I used emails to hash in the original design.
With the privacy issue, storing the default avatar in known users would solve this problem- but I'm not sure what we would do about "guessing" a user's default avatar that doesn't exist yet. Maybe we should go back to using fallback avatar for any users that you don't know?
What do you think @puneetlath @Beamanator (accountIDs/privacy perspective) and @shawnborton / @dannymcclain / @dubielzyk-expensify (design perspective)
Please let me know if you need any clarification

Ooo yeah that's a tricky one, but I quite like Danny's suggestion.

Agree that I like what D-man has suggested here

I like @dannymcclain's suggestion. So we'd use that fallback avatar whenever we have user with an optimistic accountID. But replace it whenever we have a real accountID.

whenever we have user with an optimistic accountID
@puneetlath how do we calculate/set optimistic accountIDs?

One question I have, do we care on a privacy level if users know whether or not you have an account? Is it better to have a mismatched avatar temporarily, but every account appears "created". Versus distinguishing to users between accounts that do and don't exist
https://github.com/Expensify/App/assets/38015950/fd9fe303-d25a-4c6b-952e-d2fdbe70b9ff

I think the above video looks good, and I can actually see the ability to distinguish between the two being beneficial for users—but I didn't consider any privacy concerns, so I want to let someone else weigh in on that point too.

Hmm great question - I say bring that one to Slack for others to weigh in, as I'm not sure what the best answer is.

hi! Just checking on this, is there anything I can do to help? It looks like we're working on a PR - https://github.com/Expensify/Expensify/issues/386515#issuecomment-2058089105

PR - https://github.com/Expensify/App/pull/38674 is closed  - I'll retest tomorrow

Testing again, I think this is fixed. Going to ask QA to test. https://expensify.slack.com/archives/C9YU7BX5M/p1718242220561929

@Christinadobrzyn bug is fixed.
https://github.com/Expensify/App/assets/43996225/b46c88b8-4f1c-4ed0-8b38-a872545c7c6e

Awesome! I'll close this since the bug is fixed. @grgia let me know if you feel otherwise and we can reopen.


added a small precision about auth

That has already made me waste a lot of time twice, mainly because i forgot to turn my brain on, but it can happen to others ;)

That's a good point !
Admin auth and http auth do not need to have the same password and are set separately in the settings.js.
This may not be obvious to everyone, thank you for the precision 😄


Mariadb ci updates

Updates to MariaDB server version and the latest MariaDB Connector J.
Also simplify the wait until start.

Thanks!


Add subtechniques to Navigation and Technique lists

As a user of the ATT&CK website, I want to be able to see subtechniques in the navigation elements.
Add subtechniques to the techniques sidenavs under their parent technique, and in the master techniques list nested under their parent technique.
Technique List Mockups
Note: using fake data for names, IDs and descriptions.
Option 1 (full rows)
1.1

1.2

Option 2 (indented rows)
2.1

2.2

Option 3 (nested rows)
3.1

3.2

Closing because it has been implemented on the subtechniques branch.


bug: converting sprite to mesh2dInstance

Godot version:

3.1
OS/device including version:

ubuntu18.04 and windows10
nvidia 1080ti
Issue description:

some kind of sprite cannot be generate correct mesh 2d.
for example,
0000001
0000011
0000111
0001111
0011111
0111111
In this function,
Vector BitMap::_march_square(const Rect2i &rect, const Point2i &start) const
if I change from
Rect2i fixed_rect = Rect2i(rect.position, rect.size - Size2i(2, 2));
to
Rect2i fixed_rect = Rect2i(rect.position, rect.size);
then, the bug is fixed.
Steps to reproduce:
Minimal reproduction project:

Note: the traced image has to be padded for march square algorithm to work here in all cases, this is why Size2i(2, 2) is there I think. Sprite's image most likely has to be padded by 1 pixel instead of limiting marching area by fixed_rect. so that all area can be traversed. Alternatively, necessary checks are needed to prevent march square algorithm from going outside of sprite's bounds.

Do you mean sprite image size should have 1 pixel padding every line?
I thought usual sprite files do not have padding...

As a workaround, your image should be padded by a frame of 1 pixel indeed, but ideally you don't have to add 1 pixel padding to each sprite you import yourself, this should be done within engine, but it creates additional overhead since the engine would have to pad the image anyway, possibly by making an additional copy of it. Having bounds check on every march step would also work but that would be wasteful (don't need to check inner pixels).

Actually I use the function via gdscript not godot engine tool.
I created sprite dynamically from gdscript and tried converting mesh2dInstance.
For 1 pixel padding case,  the problem is still exist.
For 2 pixel padding case, the bug is fixed.


Chams materials

Describe the bug
The material on the chams only give me the error material
Screenshots

Will investigate when I have some free time

You can make it keyvalues3
Which also means you can make some nice materials. I'm no pro though

You can make it keyvalues3 Which also means you can make some nice materials. I'm no pro though

crashes when i try

cant even inject tf

Fixed with the latest update
https://github.com/maecry/asphyxia-cs2/commit/cd8667895c984c9f0ac8066e25ff56ce6c65fde7


Add support for custom ellipsoids

Currently, Cesium for Unreal is hardcoded to use the WGS84 ellipsoid. This change adds support for specifying other ellipsoids by creating assets for them and assigning them to georeferences.
One main issue that needs to be fixed before this can be merged in is that changing the ellipsoid of a georeference should cause all of its associated tilesets to be reloaded.

One main issue that needs to be fixed before this can be merged in is that changing the ellipsoid of a georeference should cause all of its associated tilesets to be reloaded.

@azrogers , just double checking, is this still an issue?
(you've marked this PR as ready, yet I saw this comment in the description)

Found a crash, I think it's valid?
Was just playing around with the Unreal Editor Details window and ellipsoid options. Debug build, UE 5.4.1

Found another crash, but in UE 5.2 (still debug build).
Opened up the 01 sample level, then in the Outliner window, find "Edit DynamicPawn", then click it.
Obviously not directly related to ellipsoids, but triggers a related UI refresh I'm guessing...

@csciguy8 Addressed your review comments. Fixed crashes related to the UCesiumGlobeAnchorComponent details editor and added a bunch more checks so that you should get errors logged instead of crashes.

Thanks @azrogers for the changes.
Two comments remain that got lost in the shuffle...

Is the issue mentioned in the description still an issue that needs to be addressed?
(the ellipsoid of a georeference should cause all of its associated tilesets to be reloaded)

GetNativeEllipsoid is still returning a TSharedPtr even though we don't use shared pointer functionality.

In response to the point in my original post, that should be fixed. The tileset should be reloaded when the ellipsoid is changed.
I've removed the usage of TSharedPtr. Let me know if there's any final things you need me to take care of @csciguy8

Oh, I should also mention at some point that this PR will close #366.

Did some testing and good news, no crashes!
Looks pretty much done, but I did find 2 issues with the tilesets refreshing...

When changing which ellipsoid is used through the "Details" window, I noticed that the globe shape updated, but the tiles didn't look to reload. If I hit the "Refresh Button" on the tileset manually, things do what I expect. I even set a breakpoint in ACesium3DTileset::HandleOnGeoreferenceEllipsoidChanged and noticed it wasn't getting trigged.

Similarly, if I make a new ellipsoid, edit it in its new Details window, then save, I'm not seeing the tileset refresh.

@csciguy8 Made GetNativeEllipsoid return a const ref, made UCesiumEllipsoid store a TOptional instead of a TUniquePtr, fixed the OnEllipsoidChanged event (apparently the handler needs to be marked with "CallInEditor"), and added a method that reloads any georeferences using an ellipsoid asset when that ellipsoid asset is saved. Should be good to go!


Support onetrueliteral (and new width specifier).

This should be merged when ucb-bar/chisel3#372 is merged.

It seems there's still a few deprecated methods in use. Try compiling with deprecation warnings by adding
scalacOptions := Seq("-deprecation")
to build.sbt. I think the regex replacements can automatically fix many of the remaining deprecations.
Also note that the width specifier is new so none of this can be used until the corresponding chisel3 branch is merged.

Right. I think it would be a good idea to add the width specifier to
chisel3 master first, so we can migrate code while the old methods still
exist.
On Fri, Nov 18, 2016 at 11:07 AM, Richard Lin<EMAIL_ADDRESS>wrote:

It seems there's still a few deprecated methods in use. Try compiling with
deprecation warnings by adding
scalacOptions := Seq("-deprecation")
to build.sbt. I think the regex replacements can automatically fix many of
the remaining deprecations.
Also note that the width specifier is new so none of this can be used
until the corresponding chisel3 branch is merged.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel-testers/pull/64#issuecomment-261614779,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGh1wFW6Pbz7pdcbz3y59DT2ucxUYVm8ks5q_feJgaJpZM4K2wtv
.

lgtm


Delete extraneous H1 title

- What I did
Removed the hard-coded H1 title, because our doc build generates the title from metadata.
- How I did it
Deleted H1 text.
- How to verify it
View page at https://docs.docker.com/engine/extend/legacy_plugins/.
- Description for the changelog
Removed the hard-coded H1 title, because our doc build generates titles from metadata.
- A picture of a cute animal (not mandatory but encouraged)

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "delete-h1" git@github.com:JimGalasyn/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

PTAL @mstanleyjones @thaJeztah

Thanks @JimGalasyn!


Offical pull request to merge test01 yaml file

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


[Fix-5808][Server]  When we try to transfer data using datax between  different types of data sources, the worker will exit with ClassCastException

Purpose of the pull request
Fix #5808
Close #5808
Brief change log
This problem comes after #5116 , the improvement is great, but the source dataType and target dataType  was't  used correctly.
Verify this pull request
Manually verified the change by testing locally.

cc @ruanwenjun

Codecov Report

Merging #5809 (7a752d3) into dev (16986c3) will decrease coverage by 0.02%.
The diff coverage is 80.00%.

@@             Coverage Diff              @@
##                dev    #5809      +/-   ##
============================================
- Coverage     45.42%   45.39%   -0.03%
+ Complexity     3694     3690       -4
============================================
  Files           607      607
  Lines         24872    24879       +7
  Branches       2834     2833       -1
============================================
- Hits          11299    11295       -4
- Misses        12484    12496      +12
+ Partials       1089     1088       -1

Impacted Files
Coverage Δ

...nscheduler/server/worker/task/datax/DataxTask.java
55.08% <80.00%> (ø)

...he/dolphinscheduler/common/enums/SqoopJobType.java
0.00% <0.00%> (-88.89%)
:arrow_down:

...er/master/dispatch/host/assign/RandomSelector.java
77.77% <0.00%> (-5.56%)
:arrow_down:

...hinscheduler/server/worker/task/http/HttpTask.java
2.58% <0.00%> (-0.05%)
:arrow_down:

...inscheduler/common/task/sqoop/SqoopParameters.java
74.00% <0.00%> (ø)

...pache/dolphinscheduler/common/utils/DateUtils.java
81.75% <0.00%> (+0.69%)
: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 16986c3...7a752d3. Read the comment docs.

ping
@CalvinKirs


Surface::clear doesn't clear sub-rects correctly on Frame.

If you look at line 1131 in lib.rs you'll see that the rectargument of clear isn't even used, and a None is passed to the corresponding parameter in ops::clear. Is this intended, or an oversight? It appears that other implementations of clear do pass through the rect argument through correctly, instead of ignoring it.

Oh, right that's a bug.


How to get char positions of changed text in the original text

I want to get char positions of changed text along with change tuples. Please help if anyone implemented this?
Example in Python:
import diff_match_patch as dmp_module

dmp = dmp_module.diff_match_patch()
diff = dmp.diff_main("Hello World.", "Goodbye World.")
# Result: [(-1, "Hell"), (1, "G"), (0, "o"), (1, "odbye"), (0, " World.")]
#Desired Result:[(-1,"Hell",0,3,x,x),(0,"o",4,4,1,1),(1,"odbye",x,x,2,6),(0," World",6,11,7,13)]

Here in Desired Result  "x" means don't care in "delete" and "insertion" operations.
One way I thought about this is, get the changed text from tuple and find index from original text(this will be starting position") and add length of the changed text to index found, but i think this will fail in case of repeated substring. If implementation is available in other languages also will be helpful for me.
Thanks.

@sathk882 can you explain what each value in your example tuples mean? It's not clear what you are asking for. Are you asking for the ranges in the original text and also in the final text of where the characters in the current diff are to be found?
If that's the case then we really just need to think about what we do with each chunk and how it impacts a running pointer into the source strings.
d = [(-1, "Hell"), (1, "G"), (0, "o"), (1, "odbye"), (0, " World.")]

def step( last_a, last_b, next ):
    op, s = next
    l = len(s)

    if -1 == op:
        return ((op, s, (last_a, last_a + l), None), (last_a + l, last_b))

    if 0 == op:
        return ((op, s, (last_a, last_a + l), (last_b, last_b + l)), (last_a + l, last_b+l))

    if 1 == op:
        return ((op, s, None, (last_b, last_b + l)), (last_a, last_b+l))

o = []
last_a = 0
last_b = 0
for chunk in d:
    next, (next_a, next_b) = step(last_a, last_b, chunk)
    last_a = next_a
    last_b = next_b
    o.append(next)

print(o)

[(-1, 'Hell', (0, 4), None), (1, 'G', None, (0, 1)), (0, 'o', (4, 5), (1, 2)), (1, 'odbye', None, (2, 7)), (0, ' World.', (5, 12), (7, 14))]

i think this will fail in case of repeated substring

Can you explain this more?


[Bug]: auto form doesn't work with Nuxt when SSR is turned off

Reproduction
https://github.com/HuakunShen/shadcn-auto-form-debug
Describe the bug
When ssr: false, in Nuxt, I get error.
The requested module '/_nuxt/node_modules/.pnpm/@vue+devtools-api<EMAIL_ADDRESS>does not provide an export named 'setupDevtoolsPlugin'

ssr: true may also cause error
System Info
System:
    OS: macOS 15.0
    CPU: (10) arm64 Apple M1 Pro
    Memory: 1.20 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.4.1 - /opt/homebrew/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 10.8.1 - /opt/homebrew/bin/npm
    pnpm: 9.6.0 - /usr/local/bin/pnpm
    bun: 1.1.21 - ~/.bun/bin/bun
  Browsers:
    Chrome: 124.0.6367.119
    Edge: 127.0.2651.74
    Safari: 18.0
  npmPackages:
    @vueuse/core: ^10.11.0 => 10.11.0
    nuxt: ^3.12.4 => 3.12.4
    radix-vue: ^1.9.2 => 1.9.2
    shadcn-nuxt: ^0.10.4 => 0.10.4
    vue: latest => 3.4.35

Contributes

[ ] I am willing to submit a PR to fix this issue
[ ] I am willing to submit a PR with failing tests

This seems to be a pnpm-only problem. When I use npm, it works.
Error may come from vee-velidate.
https://github.com/nuxt/nuxt/issues/27544
Add @vue/devtools-api fix the error.


Revised editor-inspect-transform.asciidoc

Proposed rewrite

Awesome, but there appear to be conflicts with other files.

Hi all,
Yep, those conflicts with the master branch have to be solved somehow. I can't help out during this week, so I'd suggest moving to another tutorials meanwhile.
There're some instructions at https://github.com/apache/incubator-netbeans-website/pull/319 about git usage, that can be of help.
Cheers,
Antonio

Jeremy, please try to create a PR for each tutorial, otherwise we'll be piling up changes of top of a single PR!

Yes, please do one tutorial per PR.

Closing after more than one month of inactivity. @JeremyCavanagh please feel free to create a new PR with per/tutorial modifications. Thanks!.


[qt] Cross-compiled build results in "moc" tool targeting the host architecture

Describe the bug
For one of the projects I maintain we have an M1 Mac Mini that is solely used for macOS-related tasks, mostly development and testing.
Our current workflow when drafting a new release consists in:

Updating our vcpkg fork.
Building and exporting a vcpkg environment for the platforms we provide official binaries for.
Downloading the environment on a CI agent and using it to build the release.

Unfortunately Azure Pipelines doesn't provide ARM64 macOS agents yet, resulting in a build failure in case for whatever reason one of the tools in the environment is not compiled for x64.
This appears to be the case for Qt's moc tool.
Environment

OS: macOS
Compiler: 15.0.0 (clang-15<IP_ADDRESS>)

To Reproduce
Steps to reproduce the behavior:

./vcpkg install qtbase:x64-osx-release from an ARM64 machine.
Export the installed package.
Copy the exported environment onto an x64 machine.
Observe the resulting error when building a Qt project using CMake and said environment.

Expected behavior
Tools that are used to build Qt itself are compiled for the host architecture, which is perfectly fine.
However, moc is also used for dependent projects. I believe the correct binary should be chosen based on the current host architecture and not the one that was used to build the vcpkg environment.
Failure logs

CMake build log
-- The C compiler identification is AppleClang <IP_ADDRESS>00029
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python interpreter version 3.11.8
-- Performing Test COMPILER_HAS_MBIG_OBJ
-- Performing Test COMPILER_HAS_MBIG_OBJ - Failed
-- Using (among others) the following compiler flags: -Werror;-Wall;-Wpedantic;-Wextra;-Wconversion;-Wsign-conversion;-fsigned-char;-O3
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- ##################################################
-- Mumble version:              1.6.0
-- Architecture:                x64
-- Build type:                  Release
-- Using LTO in release builds: ON
-- ##################################################
--
-- These are the paths the different components will be installed to:
-- Executables:         "/usr/local"
-- Libraries:           "/usr/local/lib/mumble"
-- Plugins:             "/usr/local/lib/mumble/plugins"
-- Scripts:             "/usr/local/bin"
-- Man-files:           "/usr/local/share/man/man1"
-- Documentation:       "/usr/local/share/doc/mumble"
-- Licenses:            "/usr/local/share/doc/mumble"
-- Config files:        "/usr/local/etc/mumble"
-- Metadata files:      "/usr/local/share/metainfo"
-- Application files:   "/usr/local/share/applications"
-- Service files:       "/usr/local/services"
-- Sysusers files:      "/usr/local/sysusers"
-- Tmpfiles files:      "/usr/local/tmpfiles"
-- Shared client files: "/usr/local/share/mumble"
-- Shared server files: "/usr/local/share/mumble-server"
--
-- Found ZLIB: /Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libz.a (found version "1.3.1")
-- Found WrapSystemZLIB: TRUE (found version "1.3.1")
-- Using system ZLIB.
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Checking for module 'libb2'
--   Found libb2, version 0.98.1
-- Found WrapSystemPCRE2: TRUE (found version "10.43.0")
-- Using system PCRE2.

-- Found BZip2: /Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libbz2.a (found version "1.0.8")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- Found PNG: /Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libpng16.a (found version "1.6.43")
-- Found WrapSystemHarfbuzz: TRUE
-- Using system Harfbuzz.
-- Found WrapSystemFreetype: /Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libfreetype.a;/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libz.a;/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libbz2.a;/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libpng16.a;/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libz.a;/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libbrotlidec.a;/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libbrotlicommon.a (found version "2.13.2")
-- Using system Freetype.
-- Found WrapSystemJpeg: /Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/x64-osx-release/lib/libjpeg.a (found version "62")
-- Using system Jpeg.
-- Qt6 component found: Svg | Version: 6.7.2
-- Qt6 component found: Widgets | Version: 6.7.2
-- Poco component found: XML | Version: 1.13.3
-- Poco component found: Zip | Version: 1.13.3
-- Using the multi-header code from /Users/runner/work/1/s/3rdparty/nlohmann_json/include/
-- SndFile found | Version: 1.2.2
-- opus found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- speexdsp: Variable sized arrays supported: TRUE
-- speexdsp: alloca available: TRUE
-- speexdsp: SSE available: TRUE
-- speexdsp: SSE2 available: TRUE
-- Disabling warnings for targets: speexdsp
-- ===
--     Building ReNameNoise Release
--     RENAMENOISE_DEMO_EXECUTABLE is OFF
--     RENAMENOISE_BENCHMARK_EXECUTABLE is OFF
--     CLFAGS = '-fvisibility=hidden;-gfull;-gdwarf-2;-Werror;-Wall;-Wpedantic;-Wextra;-Wconversion;-Wsign-conversion;-fsigned-char;-O3;-Wall;-Wextra;-Wpedantic;-O3'
-- ===
-- Disabling warnings for targets: renamenoise
-- Qt6 component found: LinguistTools | Version: 6.7.2
-- Bundling Qt translations from ""
-- Found Python interpreter version 3.11.8
   > Bundling Qt translation "/Users/runner/work/1/b/src/mumble/qttranslations/qt_it.qm"
   > Bundling Qt translation "/Users/runner/work/1/b/src/mumble/qttranslations/qt_nl.qm"
   > Bundling Qt translation "/Users/runner/work/1/b/src/mumble/qttranslations/qt_tr.qm"
   > Bundling Qt overwrite translation "/Users/runner/work/1/b/src/mumble/qttranslations/qt_zh_CN.qm"
-- Qt6 component found: Sql | Version: 6.7.2
-- File: /Users/runner/work/1/b/src/murmur/murmur_autogen
-- Ice component found: Ice | Version: 3.7.3
-- Ice component found: IceSSL | Version: 3.7.3
-- Ice optional component found: IceDiscovery | Version: 3.7.3
-- Ice optional component found: IceLocatorDiscovery | Version: 3.7.3
-- Ice optional component found: IceUtil | Version: 3.7.3
-- Qt6 component found: Test | Version: 6.7.2
-- Using system PNG.
-- Using system Harfbuzz.
-- Using system Freetype.
-- Using system Jpeg.
-- Qt6 component found: Widgets | Version: 6.7.2
-- Found Python interpreter version 3.11.8
-- Omitting online tests - Testing can be performed without an active internet connection
-- Configuring done (29.2s)
CMake Error: AUTOMOC for target shared: Test run of "moc" executable "/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/arm64-osx/tools/Qt6/bin/moc" failed.
/Users/runner/hostedtoolcache/MumbleBuild/mumble_env.x64-osx-release.2024-07-23.9ad0398d8/installed/arm64-osx/tools/Qt6/bin/moc -h

Unknown system error -86
CMake Generate step failed.  Build files cannot be regenerated correctly.

Additional context
While exporting the x64 vcpkg packages I noticed ARM64 ones being included as well. This may be an indication that the environment assuming an ARM64 host is on purpose and not a bug.
Is there perhaps a way to tell vcpkg to treat the host machine as an x64 one?

However, moc is also used for dependent projects. I believe the correct binary should be chosen based on the current host architecture and not the one that was used to build the vcpkg environment.

When building the port, it requires to run some custom program, which will be build or passed in from variables by determine CMAKE_CROSSCOMPILING. It seems that it does not build tools such as moc when CMAKE_CROSSCOMPILING is ON.
But I'm not sure whether this part is determined by the upstream(qtbase) or the portfile.cmake, it require further investigation.
Fortunately, currently there is a method that seems to be the simplest, like you said:

Is there perhaps a way to tell vcpkg to treat the host machine as an x64 one?

Yes.

I think vcpkg has no immediate solution for the desired scenario. vcpkg has only "host" and "target" triplet. You can ask to build packages
to target x64-osx from arm64-osx.
But the requested scenario is what elsewhere takes three triplet (build, host, target). You ask for packages
to target x64-osx from x64-osx, built on arm64-osx.

If the port does not depend on CMAKE_CROSSCOMPILING and depend independent tools port or provide options, then the original issue could be easily solved:
Just add both host and target tools.

${CURRENT_HOST_INSTALLED_DIR} will point to the correct host program.
The additional target-triplet tools are available to users

Just like -DPKG_CONFIG_EXECUTABLE=${PKGCONFIG}.
Some ports do not provide options, and builds many internal tools in-place, it could be better handled by upstream for that difference behavior of cross-compiling.


Make library more open for extension

When using the library in a more advanced way to dynamically update the ButtonBar labels the library is currently to closed. The proposed changes allow the library user more possibilities and follow the open/close principle in OOP. Structs in swift are not extensible, so the IndicatorInfo struct was replaced by a class.

Hey @vonox7 why don't use a protocol instead of the struct as protocol method return type, by doing that we can change the struct type and even return a class. Either way the developer must cast it (IndicatorInfo) to the concrete type before access custom properties.

You are right, it is a design decision whether we want an IndicatorInfoable protocol or just a IndicatorInfo base class. I decided to use a class, to make with this pull request a minimal impact to the existing design.
Casting to the concrete type is of course necessary, but that is how OOP works. And it is the job of the application developer and not of the library developer to make sure extensions made by the application developer work correctly.

Closed due to inactivity of reviewer.

Closed due to inactivity of reviewer.


zonneplan one fails to start

Logger: homeassistant.loader
Source: custom_components/zonneplan_one/coordinator.py:18
Integration: Zonneplan ONE (documentation, issues)
First occurred: 14:21:58 (1 occurrences)
Last logged: 14:21:58
Unexpected exception importing component custom_components.zonneplan_one
Traceback (most recent call last):
File "/home/homeassistant/lib/python3.9/site-packages/homeassistant/loader.py", line 725, in get_component
cache[self.domain] = importlib.import_module(self.pkg_path)
File "/usr/lib/python3.9/importlib/init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 790, in exec_module
File "", line 228, in _call_with_frames_removed
File "/home/homeassistant/.homeassistant/custom_components/zonneplan_one/init.py", line 13, in
from .coordinator import ZonneplanUpdateCoordinator
File "/home/homeassistant/.homeassistant/custom_components/zonneplan_one/coordinator.py", line 18, in
def getGasPriceFromSummary(summary) -> int | None:
TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

Looks like this uses a python 3.10 feature... while i'm on 3.9

3.9 is no longer supported by Home Assistant

Yeah, looks like i'm running 2023.1.7 ... but the fix is a simple one... So would be nice if this could be merged anyway

Especially since python 3.9 is the default in debian (and 3.8 is the default in centos/rhel/ubuntu 20.04)


Final unittest_runner cleanup #173

fixes #173, connected to #173

@mriehl looks good? I'm happy with a release after that.

ugh! xmlrunner dies with 3.2...

:+1:
As for 3.2 let's consider dropping support for it. There are so many issues with 3.2 it's not even funny and I honestly do not see the use case of having 3.2 but being unable to upgrade to 3.3 or 3.4

@mriehl the fewer Python versions we have to support - the better


ahkpm: Add version 0.5.0

ahkpm is a new package manager for autohotkey, this PR adds a manifest for version 0.5.0

[x] I have read the Contributing Guide.

/verify


feat: add logging for RPC HTTP requests: command, user, http-code, time of running

note for review: it depends on https://github.com/dashpay/dash/pull/6045 - to be merged after
Issue being fixed or feature implemented
Currently there is no way to gather stats for http rpc in dash core. This PR aim to change it.
What was done?
Implemented some basic stats for each RPC request:

rpc command
flag "is external"
http status
time to serve query (rpc time, not http time)

How Has This Been Tested?
See new logs:
[httpworker.0] [httprpc.cpp:100] [~RpcHttpRequest] -- HTTP RPC request handled: user=platform-user command=getbestblockhash is_external=false status=200 elapsed_time_ms=0
[httpworker.2] [httprpc.cpp:100] [~RpcHttpRequest] -- HTTP RPC request handled: user=platform-user command=quorum is_external=false status=500 elapsed_time_ms=0
[httpworker.3] [httprpc.cpp:100] [~RpcHttpRequest] -- HTTP RPC request handled: user=platform-user command= is_external=false status=401 elapsed_time_ms=0
[httpworker.3] [httprpc.cpp:100] [~RpcHttpRequest] -- HTTP RPC request handled: user=platform-user command=getbestblockhash is_external=true status=200 elapsed_time_ms=28
[httpworker.0] [httprpc.cpp:100] [~RpcHttpRequest] -- HTTP RPC request handled: user=operator command=getbestblockhash is_external=false status=200 elapsed_time_ms=0

Breaking Changes
N/A
It doesn't change behavior of rpc server and http server.
Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation
[x] I have assigned this pull request to a milestone

Guix Automation has began to build this PR tagged as v21.0.0-devpr6073.6477bfde. A new comment will be made when the image is pushed.

Guix Automation has completed; a release should be present here: https://github.com/dashpay/dash-dev-branches/releases/tag/v21.0.0-devpr6073.6477bfde. The image should be on dockerhub soon.

@knst knst force-pushed the http-stats branch from 6477bfd to 63e8396

rebased due to conflicts

Have you been able to do any benchmarking and see if this slows down any rpc processing? I wouldn't really expect it to, but maybe it does?

back ported in #6115


BO: Fixed an order confirmation message in German in 3.15.1

It says "Ihre Bestellung wird sehr kahl gesendet." instead of "Ihre Bestellung wird sehr bald gesendet." It just doesn't make sense and might have been some kind of automated typo correction problem.

Hello,
thank you for your PR.
We will add it the v3.15.1 of the module that will be available on prestashop addons this month.
Have a nice day !
Regards,
Tetiana


Feature Request: Support TFS Version Control

VS Code should support TFS Version Control.  Part of the primary reason for choosing Microsoft for products is that they work well together.
Not supporting TFS Version Control is a slap in the face for every customer that bought TFS from Microsoft.

Have you tried this extension: https://marketplace.visualstudio.com/items?itemName=ms-vsts.team
It adds support for Team Foundation Version Control

My bad.  I did not see that.  I am still on TFS 2013, so I can't use it.  But the support is there if I could convince people at my company to upgrade.


Middleware fixes

Adds new Raven-instance-oriented middleware-returning-methods:
var Raven = require('raven');
Raven.config(dsn).install();
...
app.use(Raven.requestHandler());
...
app.use(Raven.errorHandler());

Also BC-ifies old raven.middleware.express.* interface to delegate to these after ensuring existence of client instance.
/cc @MaxBittker @benvinegar

We're not de-duping clients in the BC patchwork, only in the new way to do things, so not really.


User-assigned Managed Identity for VMs

Added additional User-assigned Managed Identity for AMA deployment Policy, to be deployed along with other bootstrap managed identities.
This additional identity is required when setting up the AMA deployment initiative.

@Garth-CD there is already a second managed identity for use with Azure Policy, so why do we need a third? The PR comment above does not explain it effectively.
Note that Azure Policy's Deploy If Not Exists effect is configured with an array of roleDefinitionIds. You need a privileged role for policy assignments because it is capable of assigning roles on the fly when remediating. By default the policy managed identity has no RBAC permissions.
Your additional vm management identity repeats the comment for the policy identity and it is unclear why it is needed especially as it has no RBAC role assignments. Remember this repo is public so the commenting needs to be full and accurate.

@richeney The AMA agent requires a User or System Assigned identity in order to function. We make use of the User Assigned identity policies as that allows mapping one single identity to multiple workloads instead of having each VM with a System Assigned identity which clogs up Entra ID with all of these Managed Identities
The AMA User identity policies need an identity to remediate resources. This is the id-cdmonitoring-policy-prod-uksouth-001 identity which is currently deployed via the Terraform Bootstrap.
The new proposed identity would be the identity that is assigned to VMs themselves which has no permissions. There are 2 problems this new VM identity would solve:

The policy initiatives have the option of creating and assigning a built-in User Identity which is created by the policy. If we use the default built-in identity that the policy can assign that might not work due to other deny policies in the target environment which are enforcing tags. naming conventions etc

If we use the policy identity for both the policy itself as well as the VMs then that means the VMs have an identity assigned which has a whole bunch of potentially privileged permissions which we don't want

@richeney Done.


Wrong Project Repo Link in Marketplace?

Installed product versions

Visual Studio: N/A
This extension: N/A

Description
https://marketplace.visualstudio.com/items?itemName=YannDuran.ExtensibilityLogs

Steps to recreate

Go to the marketplace

Current behavior
Current link is to the developer-news repo
Expected behavior
Link to this repo

I'm so sorry Michael. I don't know how I missed this.
I really appreciate you taking the time to let me know about this. I've fixed it now.
Thanks again!

I don't know how I missed this

No worries, it happens 😀

I really appreciate you taking the time to let me know about this. I've fixed it now.

You're welcome and awesome! 👏

looks good 👍


Selecting a test with no output hides the entire bottom panel

If the Output tab in the Bottom Panel is currently open and a test with no output is selected - the entire panel will be hidden. I have to manually restore it or select a test with an output. Quite annoying iyam. Why not just show empty Output?

Also notice how after I first switch to Terminal it automatically switches to Output if I select a test but then, after the Panel autocloses and is restored the same action doesn't switch to Output and keeps Terminal active and the entire Panel open.

Why not just show empty Output?

Because it hides part of the source code with an empty panel - personally I prefer the panel to disappear when it doesn't have any information to show. I could make this configurable though.

the same action doesn't switch to Output and keeps Terminal active and the entire Panel open.

That is VS Code's decision - I just call OutputChannel#hide(). But in my opinion it makes sense: if an extension asks an OutputChannel to be hidden that isn't currently shown anyway, then there is nothing to do. After all, the extension only asked for that single OutputChannel to be hidden, not the entire panel.
Perhaps it would be nicer if calling OutputChannel#hide() while the OutputChannel is shown would restore the bottom panel's state to what it was before the OutputChannel appeared, but I can't influence that (VS Code doesn't give much information about the current state of the bottom panel and very little control over it).

I could make this configurable though.

That would be nice. I need to see test's Output panel only occasionally. But I always need Debug and Terminal. So in my case a feature that I rarely use disables features that I need often and forces me to do additional steps to restore them.
Thank you.

You can now use "testExplorer.hideEmptyLog": false to stop the automatic hiding of the bottom panel.


HAWQ-1199. guc enable_prefer_list_to_rm does not work.

Good to have the fix. +1

LGTM +1

Merged. Closing.


Add dialog icon not responsive for mobile view

Add dialog icon not responsive for mobile view

@Mgranfie @mindreeper2420 In mobile view can you share the position for Add WorkItem Button

@SMahil @Mgranfie the position should not differ from the desktop view - it should stay on the right side, overlaying the menu and the list. Similar to the tooltip question, think of it as a FAB from Material Design. It is a fixed position element.

@mindreeper2420 i guess we need to make header responsive for this.... Its not button which is breaking.. its header which is breaking on mobile and desktop view

@SMahil yes, I would say that the header is definitely broken, going off of the screenshot. Fixing that to be a hamburger menu (which is built into PatternFly) and then have the FAB in the upper right area would fix the alignments and give the list more room.

@SMahil Here is the horizontal navigation that utilizes the responsive methodology: http://www.patternfly.org/pattern-library/navigation/horizontal-navigation/#_code. In the code, there is a <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse-1"> that should help to remedy the navigation issue.

For Header Responsive behaviour I have raised the PR : #597


Rule suggestion: unnecessary-else

Rule Suggestion
Is your rule for a general problem or is it specific to your development style?
General problem
What does your suggested rule do?
If an if block contains a return, throw, continue or break statement, the else block becomes unnecessary. Its contents can be placed outside of the block.
List several examples where your rule could be used
Instead of:
if (foo) {
    throw new Error();
} else {
    // ...
}

Prefer:
if (foo) {
    throw new Error();
}

// ...

See https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/no-unnecessary-else.md
Additional context
Spinning off of #2040: moving some rules of tslint-consistent-codestyle to tslint core.
Note that as ajafff mentioned, copied code without substantial changes needs to retain the original license.

@JoshuaKGoldberg Could you kindly review this PR and tell me where am I going wrong ? :)


Winget cannot differentiate between Windows Terminal Stable and Windows Terminal Preview

Brief description of your issue
While attempting to install Windows Terminal stable, Winget is stuck saying that a more refined input is required.
Steps to reproduce
Attempt to install Winget:
$ winget install --id Microsoft.WindowsTerminal
Multiple apps found matching input criteria. Please refine the input.
Name                     Id                               Version
--------------------------------------------------------------------
Windows Terminal         Microsoft.WindowsTerminal        1.0.1811.0
Windows Terminal Preview Microsoft.WindowsTerminalPreview 1.1.1812.0

Notice how the ID filter was already being used. Now proceed and specify the version:
$ winget install --id Microsoft.WindowsTerminal --version 1.0.1811.0
Multiple apps found matching input criteria. Please refine the input.
Name                     Id                               Version
--------------------------------------------------------------------
Windows Terminal         Microsoft.WindowsTerminal        1.0.1811.0
Windows Terminal Preview Microsoft.WindowsTerminalPreview 1.1.1812.0

Screenshot:

Expected behavior
Winget can differentiate between Windows Terminal and Windows Terminal Preview, while respecting the version and id filters.
Actual behavior
Winget cannot differentiate the packages and does not allow installation.
Environment
Windows Package Manager v0.1.41821 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.388
Package: Microsoft.DesktopAppInstaller v1.0.41821.0

Oh well, seems like this affects most packages so I'm closing as I'm assuming this is intended behavior.


Document "not enough disk space" suggestions for customer documentation

https://teams.microsoft.com/l/message/19:276707cdcf5d431caaa8792b29bd832d@thread.skype/1686775516622?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=147df318-61de-4f04-8f7b-ecd328c256bb&parentMessageId=1686775516622&teamName=.NET Eng Services&channelName=FR Internal&createdTime=1686775516622
Would probably be a good thing for our chatbot to be able to report on, too :)

Release Note Category

[ ] Feature changes/additions
[ ] Bug fixes
[ ] Internal Infrastructure Improvements

Release Note Description

I have updated our customer facing wiki - https://dev.azure.com/dnceng-public/public/_wiki/wikis/DNCEng Services Public Wiki/4/Home - with information about what action to take when space issues are experienced.


Update SDHI SMS and Strobe-O-Matic for KSP 1.1.3

You guys can merge this whenever the dependencies check out.

LGTM. Merging with thanks!


feat: add open ai custom base url

https://github.com/devoxx/DevoxxGenieIDEAPlugin/issues/294

Looks like you've renamed OpenAIChatModelFactoryTest to OpenAIChatModelFactory instead of updating OpenAIChatModelFactory in the source directory.

Looks like you've renamed OpenAIChatModelFactoryTest to OpenAIChatModelFactory instead of updating OpenAIChatModelFactory in the source directory.

Ops, fixing it


⚠ Bofrost.lu has degraded performance

In f88063c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1450 ms

Resolved: Bofrost.lu performance has improved in a8e667d after 18 minutes.


Questions???

I've recently been user request-promise, and have a few questions.

I've noticed it depends on lodash,  but lodash is a bit of a monster module and looking at your code it might be nicer to use the module based lodash..  eg.. lodash.foreach  etc..
I've also noticed you hack the require.cache so you can get an unaltered request instance, is there a reason you can't just do  new request() here?

Regarding Lodash: I am glad you asked. Finally someone who appreciates my obsession with details. ;) Actually, the full lodash library gets installed but never fully required with require('lodash'). The code always only requires single functions, e.g. require('lodash/isObjectLike') or require('lodash/isString'). We could use the packages lodash.isObjectLike or lodash.isString but if you look as isString's code you find the isObjectLike function included there as well. Many Lodash function have a lot of overlap. Using the independent packages for each function would introduce loading duplicated code. And since many users use Webpack or Browserify this adds unnecessary weight. Additionally, it is also relevant which Lodash function to choose. For example, to check if a variable is an object we have isPlainObject, isObject, and isObjectLike. The safest way would be to use isPlainObject but if you look at the code you see that it is huge. However, the use case actually allow a less stringent checking so I chose isObjectLike with the smallest footprint.

Regarding require.cache: If a project used request for a long time and they want to start using request-promise they would need to migrate the whole codebase including all their libraries to request-promise if the require.cache technique wasn't in place. They couldn't just introduce request-promise for parts of their codebase. To ease the migration this technique is used. Btw, nowadays the logic is extracted into the stealthy-require package. The reason why this problem arises is that request-promise is not a wrapper of request because a wrapper would have a hard time replicating the whole API that request exposes. To guarantee that request's full API is also available to request-promise users, request-promise extends request's prototype. However, to not interfere with the codebase that is using request directly, request-promise needs its own separate copy of request and that is only possible using the require.cache technique.

I hope this answers your questions.

isObjectLike function included there as well. Many Lodash function have a lot of overlap.

I think the overlap is deliberate, and actually is helpful to webpack.
In your example they would be no saving on such a small function, eg.
var isObjectLike = __webpack_require__(10), is nearly as long as function isObjectLike(value) { return !!value && typeof value == 'object';}   And after uglifying could be taken out totally and get a performance boost as it could then be inlined.  I don't believe webpack would inline _webpack_require's as it would not be local scope.
Other advantages of npm modules, is if say 1 function got updated, you only have to npm update this one, and not the whole lodash lib.
The only reason I spotted this lodash monster lib, was I created a simple directory sync using request-promise, and after one of my work mates npm install'ed it, I thought what the monkey's is it installing, the application I created was very simple one, didn't expect that.

The reason why this problem arises is that request-promise is not a wrapper of request because a wrapper would have a hard time replicating the whole API that request exposes.

I'm not sure using a wrapper would require too much replicating.
Below is a simple example, here I've applied the promise functions & you still have pipe etc.  I think the defaults function would need re-implementing, as it would end up returning old class.  But apart from that, not sure what else.
var
    bluebird = require('bluebird');

function MyRequest(options) {
    var r = request.call(this, options, callback),
        _resolve, _reject;
    function callback(error, response, body) {
        if (error) _reject(error);
        else _resolve(response);
    }
    var Prom = new bluebird(function (resolve, reject) {
        _resolve = resolve;
        _reject = reject;
    });
    r.then = Prom.then.bind(Prom);
    r.finally = Prom.finally.bind(Prom);
    r.catch = Prom.catch.bind(Prom);
    return r;
}

Regarding lodash: Well, it does use approx. 4MB out of the 10MB you need to save on disk for request + request-promise. However, is there a practical reason where you need to reduce the disk usage?

Regarding the wrapper approach: Unfortunately, it is not as straight forward. Back in November 2014 we decided to switch from the wrapper approach to the one we still have today. Not only because it is easier to implement while guaranteeing full compatibility but also to easily keep up with any new features request might release. Fyi, this approach will retire in the foreseeable future. The next version of request  is designed from the ground up to allow to be extended. There is an alpha version in case you want to take a look.

Hey @KpjComp , how are you doing? I think we have one loose end in our discussion in regard to the disk space usage of lodash. If you can share your arguments why having less disk space usage is very important I am happy to look closer at disk space usage vs. module bundler output size.

Hi, @analog-nico,
I think it's mainly me been old school  :),  having any redundant code makes me feel un-easy.
But were size / number of files can have an impact is say with embedded OS's, or USB install's etc.
And say I created lots of shrink wrapped utility function's, each small utility then has this overhead.
Going forward, if the new 'request` lib is going to be modular, it would seem both issues,  would become mute anyway.  So is probably best left as is.

disk space usage vs. module bundler output size.

I'm not 100% sure that one, effects the other in a big way.  Eg. like I mentioned with the option of inlining, and the webpack_require overhead.  I'm assuming the functions lodash used internal were picked because of this balance.  I've not looked at everything in the lodash source, but do you know of any large duplicated functions in lodash.xyz?
An interesting point here,.  Looking at NPM there are a lots of modules that use lodash.XYZ, and other's that use the lodash and might then be using lodash/XYZ,.  In some respect's I wish lodash had chosen only one option :), As if I now do bundle the chances are I'm going to get duplicated code for this reason. IOW: It's become fragmented.

Alright, I leave it as it is. request-promise-core requires the full lodash but accesses each function specifically. This way we get the lowest possible size when using a module bundler.


[Bug]: unable to set up multiprocessing

What happened?
Beam - 2.39.0
Python - 3.8.13
Win10
Runner - Direct
I was following this page for setting some parrallelism (threading in this case):
https://beam.apache.org/documentation/runners/direct/
However, regardless of how I pass the required parameters to PipelineOptions instance, I get the error below. This error is really obscure, and I have no idea how to fix it (as you might've guessed, googling didn't help much).
Mind you, I have no issues when those parameters are set to defaults.
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function annotate_downstream_side_inputs at 0x000001B6F91B8AF0> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function fix_side_input_pcoll_coders at 0x000001B6F91B8C10> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function pack_combiners at 0x000001B6F91B9160> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function lift_combiners at 0x000001B6F91B91F0> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function expand_sdf at 0x000001B6F91B93A0> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function expand_gbk at 0x000001B6F91B9430> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function sink_flattens at 0x000001B6F91B9550> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function greedily_fuse at 0x000001B6F91B95E0> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function read_to_impulse at 0x000001B6F91B9670> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function impulse_to_input at 0x000001B6F91B9700> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function sort_stages at 0x000001B6F91B9940> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function add_impulse_to_dangling_transforms at 0x000001B6F91B9A60> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function setup_timer_mapping at 0x000001B6F91B98B0> ====================
INFO:apache_beam.runners.portability.fn_api_runner.translations:==================== <function populate_data_channel_coders at 0x000001B6F91B99D0> ====================
INFO:apache_beam.runners.portability.fn_api_runner.worker_handlers:starting control server on port 49986
INFO:apache_beam.runners.portability.fn_api_runner.worker_handlers:starting data server on port 49987
INFO:apache_beam.runners.portability.fn_api_runner.worker_handlers:starting state server on port 49988
INFO:apache_beam.runners.portability.fn_api_runner.worker_handlers:starting logging server on port 49989
INFO:apache_beam.runners.portability.fn_api_runner.worker_handlers:Created Worker handler <apache_beam.runners.portability.fn_api_runner.worker_handlers.EmbeddedGrpcWorkerHandler object at 0x000001B6FB280820> for environment ref_Environment_default_environment_1 (beam:env:embedded_python_grpc:v1, b'{}')
INFO:apache_beam.runners.worker.statecache:Creating state cache with size 100
INFO:apache_beam.runners.worker.sdk_worker:Creating insecure control channel for localhost:49986.
INFO:apache_beam.runners.worker.sdk_worker:Control channel established.
INFO:apache_beam.runners.worker.sdk_worker:Initializing SDKHarness with unbounded number of workers.
INFO:apache_beam.runners.portability.fn_api_runner.worker_handlers:Created Worker handler <apache_beam.runners.portability.fn_api_runner.worker_handlers.EmbeddedGrpcWorkerHandler object at 0x000001B6FBCE0D90> for environment ref_Environment_default_environment_1 (beam:env:embedded_python_grpc:v1, b'{}')
INFO:apache_beam.runners.worker.statecache:Creating state cache with size 100
INFO:apache_beam.runners.worker.sdk_worker:Creating insecure control channel for localhost:49986.
INFO:apache_beam.runners.worker.sdk_worker:Control channel established.
INFO:apache_beam.runners.worker.sdk_worker:Initializing SDKHarness with unbounded number of workers.
INFO:apache_beam.runners.worker.sdk_worker:Creating insecure state channel for localhost:49988.
INFO:apache_beam.runners.worker.sdk_worker:State channel established.
INFO:apache_beam.runners.worker.data_plane:Creating client data channel for localhost:49987
INFO:apache_beam.runners.worker.sdk_worker:Creating insecure state channel for localhost:49988.
INFO:apache_beam.runners.worker.sdk_worker:State channel established.
INFO:apache_beam.runners.worker.data_plane:Creating client data channel for localhost:49987
INFO:apache_beam.runners.worker.sdk_worker:No more requests from control plane
INFO:apache_beam.runners.worker.sdk_worker:SDK Harness waiting for in-flight requests to complete
INFO:apache_beam.runners.worker.data_plane:Closing all cached grpc data channels.
INFO:apache_beam.runners.worker.sdk_worker:Closing all cached gRPC state handlers.
INFO:apache_beam.runners.worker.sdk_worker:Done consuming work.
INFO:apache_beam.runners.worker.sdk_worker:No more requests from control plane
INFO:apache_beam.runners.worker.sdk_worker:SDK Harness waiting for in-flight requests to complete
INFO:apache_beam.runners.worker.data_plane:Closing all cached grpc data channels.
INFO:apache_beam.runners.worker.sdk_worker:Closing all cached gRPC state handlers.
INFO:apache_beam.runners.worker.sdk_worker:Done consuming work.
Traceback (most recent call last):
  File "T:/nvme1/akutergin/OCR/beam_pipelines/main.py", line 132, in <module>
    ocrd = p_markup.run(decoded, models_and_libs, templates)
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\pipeline.py", line 596, in __exit__
    self.result = self.run()
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\pipeline.py", line 573, in run
    return self.runner.run_pipeline(self, self._options)
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\direct\direct_runner.py", line 131, in run_pipeline
    return runner.run_pipeline(pipeline, options)
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\portability\fn_api_runner\fn_runner.py", line 199, in run_pipeline
    self._latest_run_result = self.run_via_runner_api(
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\portability\fn_api_runner\fn_runner.py", line 208, in run_via_runner_api
    return self.run_stages(stage_context, stages)
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\portability\fn_api_runner\fn_runner.py", line 408, in run_stages
    bundle_results = self._execute_bundle(
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\portability\fn_api_runner\fn_runner.py", line 736, in _execute_bundle
    self._run_bundle(
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\portability\fn_api_runner\fn_runner.py", line 965, in _run_bundle
    result, splits = bundle_manager.process_bundle(
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\runners\portability\fn_api_runner\fn_runner.py", line 1388, in process_bundle
    process_bundle=beam_fn_api_pb2.ProcessBundleResponse(
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\metrics\monitoring_infos.py", line 421, in consolidate
    yield reduce(merge, values)
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\metrics\monitoring_infos.py", line 419, in merge
    payload=combiner(a.payload, b.payload))
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\metrics\monitoring_infos.py", line 384, in distribution_payload_combiner
    (count_a, sum_a, min_a, max_a) = _decode_distribution(coder, payload_a)
  File "C:\Anaconda3\envs\ML-5\lib\site-packages\apache_beam\metrics\monitoring_infos.py", line 451, in _decode_distribution
    value_coder.decode_from_stream(stream, True),
  File "apache_beam\coders\coder_impl.py", line 914, in apache_beam.coders.coder_impl.VarIntCoderImpl.decode_from_stream
  File "apache_beam\coders\coder_impl.py", line 916, in apache_beam.coders.coder_impl.VarIntCoderImpl.decode_from_stream
  File "apache_beam\coders\stream.pyx", line 195, in apache_beam.coders.stream.InputStream.read_var_int64
RuntimeError: VarLong too long.

Issue Priority
Priority: 0
Issue Component
Component: runner-direct

The Exception triggers on this snippet:
import apache_beam as beam
from apache_beam.runners.direct.direct_runner import DirectRunner
from apache_beam.options.pipeline_options import DirectOptions, PipelineOptions

if __name__ == '__main__':
    pipeline_options = PipelineOptions()

    runner = DirectRunner()

    # Tried passing those to PipelineOptions as well, same result
    pipeline_options.view_as(DirectOptions).direct_running_mode = 'multi_threading'
    pipeline_options.view_as(DirectOptions).direct_num_workers = 0

    with beam.Pipeline(runner=runner, options=pipeline_options) as p:
        inputs = p | 'Create' >> beam.Create([{'foo': 'bar'}, {'spam': 'eggs'}])```

(see https://beam.apache.org/contribute/issue-priorities/ for P0 vs P2 meaning)

(see https://beam.apache.org/contribute/issue-priorities/ for P0 vs P2 meaning)

Well, I'm sorry for mislabeling, and thank you for the correction, but honestly, I'd rather have an actual answer to my question.

duplicates #20633

I'm not using Cython, btw, just vanilla CPython. Although, the error might happen there as well.

The PyPI releases come with cythonized modules. The issue is fixed in #22107 and should be available in next release

Tested that --direct_running_mode=multi_threading now works for beam v2.14.0rc1, but --direct_running_mode=multi_processing still not working:
Exception in thread run_worker:
Traceback (most recent call last):
  File "C:\Python38\lib\threading.py", line 932, in _bootstrap_inner
    self.run()
  File "C:\Python38\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "F:\Py\beampy38\lib\site-packages\apache_beam\runners\portability\local_job_service.py", line 220, in run
    p = subprocess.Popen(self._worker_command_line, shell=True, env=env_dict)
  File "C:\Python38\lib\subprocess.py", line 858, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Python38\lib\subprocess.py", line 1243, in _execute_child
    raise TypeError('bytes args is not allowed on Windows')
TypeError: bytes args is not allowed on Windows

Keep the issue open.

I haven't tried it recently, but it should be working. The windows issues discussed here should have been resolved as of 2.42.0. It is possible that some other issue were introduced since then, so feel free to open another issue with more details.
For more information see: https://beam.apache.org/documentation/runners/direct/#setting-parallelism


For contributor use:

[ ] Unit tests written
[ ] Added test to CI if applicable
[ ] Updated CHANGELOG_PENDING.md
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Updated relevant documentation (docs/) and code comments
[ ] Re-reviewed Files changed in the Github PR explorer

Codecov Report

Merging #299 into master will increase coverage by 23.3%.
The diff coverage is 61.9%.

@@            Coverage Diff            @@
##           master    #299      +/-   ##
=========================================
+ Coverage    13.6%   37.0%   +23.3%
=========================================
  Files          69     120      +51
  Lines        3752    7789    +4037
  Branches     1374    2786    +1412
=========================================
+ Hits          513    2887    +2374
- Misses       2618    4588    +1970
+ Partials      621     314     -307

Impacted Files
Coverage Δ

modules/src/events.rs
0.0% <0.0%> (ø)

modules/src/ics02_client/events.rs
0.0% <ø> (ø)

modules/src/ics02_client/raw.rs
0.0% <0.0%> (ø)

modules/src/ics03_connection/context.rs
0.0% <0.0%> (ø)

modules/src/ics03_connection/error.rs
16.6% <0.0%> (-16.7%)
:arrow_down:

modules/src/ics04_channel/error.rs
75.0% <ø> (+50.0%)
:arrow_up:

modules/src/ics04_channel/packet.rs
0.0% <0.0%> (ø)

modules/src/ics07_tendermint/client_def.rs
0.0% <0.0%> (ø)

modules/src/ics07_tendermint/error.rs
75.0% <ø> (+75.0%)
:arrow_up:

modules/src/ics18_relayer/error.rs
0.0% <0.0%> (ø)

... and 218 more

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 6fe7366...ece606f. Read the comment docs.

We'll make the Height type conversions smoother in a subsequent PR, tracked here: https://github.com/informalsystems/ibc-rs/issues/300


feat: impl sign url

What this PR does:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

1.2.0


bug: error in :Huez after adding preselection index in the picker

@axzilla reference #45 and #15

FYI, this works fine:
vim.keymap.set("n", "<leader>tt", ":Huez<CR>", { desc = "Color Themes" })

But this not:
local pickers = require("huez.pickers")
vim.keymap.set("n", "<leader>tt", pickers.themes, { desc = "Color Themes" })

FYI, this works fine:
vim.keymap.set("n", "<leader>tt", ":Huez<CR>", { desc = "Color Themes" })

But this not:
local pickers = require("huez.pickers")
vim.keymap.set("n", "<leader>tt", pickers.themes, { desc = "Color Themes" })

@axzilla let me know if it works now, the function should set opts to nil as of #51 if no arg was passed, also feel free to try out the other pickers by calling the function instead of the command and let me know if you get the behavior?

@axzilla let me know if it works now, the function should set opts to nil as of https://github.com/vague2k/huez.nvim/pull/51 > if no arg was passed, also feel free to try out the other pickers by calling the function instead of the command and let me > know if you get the behavior?

Works great now, as do the other pickers. Thanks for that!


Inaccessible web3 git pinned by package.json

"web3": "git://github.com/elaineo/web3.js#develop"

This ensures that any bugs caused during development in the underlying library will be inherited by your software and break, for some users, until that under development branch is fixed.
Additionally, npm install didn't have enough permissions by default for new users to actually get the code. I did a git clone and as a workaround:
"web3": "file:local_modules/web3"
Never pin the development/master version of another git.

k, feel free to submit the fix as a PR.


[SPARK-35045][SQL][FOLLOW-UP] Add a configuration for CSV input buffer size

What changes were proposed in this pull request?
This PR makes the input buffer configurable (as an internal configuration). This is mainly to work around the regression in uniVocity/univocity-parsers#449.
This is particularly useful for SQL workloads that requires to rewrite the CREATE TABLE with options.
Why are the changes needed?
To work around uniVocity/univocity-parsers#449.
Does this PR introduce any user-facing change?
No, it's only internal option.
How was this patch tested?
Manually tested by modifying the unittest added in https://github.com/apache/spark/pull/31858 as below:
diff --git a/sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/csv/CSVSuite.scala b/sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/csv/CSVSuite.scala
index fd25a79619d..705f38dbfbd 100644
--- a/sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/csv/CSVSuite.scala
+++ b/sql/core/src/test/scala/org/apache/spark/sql/execution/datasources/csv/CSVSuite.scala
@@ -2456,6 +2456,7 @@ abstract class CSVSuite
   test("SPARK-34768: counting a long record with ignoreTrailingWhiteSpace set to true") {
     val bufSize = 128
     val line = "X" * (bufSize - 1) + "| |"
+    spark.conf.set("spark.sql.csv.parser.inputBufferSize", 128)
     withTempPath { path =>
       Seq(line).toDF.write.text(path.getAbsolutePath)
       assert(spark.read.format("csv")

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42147/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42147/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42147/

Merged to master, branch-3.1 and branch-3.0.
Note that the issue was fixed. I will upgrade univocity, and remove these hacks in master branch.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/137616/


Shitty app make crash

me crash

@RRethy Thank you for your feedback! As i'm sure you're aware, this project is currently in early alpha stages. I'll be sure to let you know when I have a stable version available for testing :)


_site is still being built by GH

The site is still being built by GH on commit - we need to add a .nojeckyll file to prevent it.

This is now fixed: the source for the site is now in main, the site itself is now in gh-pages and GH no longer builds it - it hs to be built locally and committed.


Stone_paper.py

What type of PR is this? (check all applicable)

[ ] 🚀 Added Name
[ ] ✨ Feature
[ ] 🌟 stared the repo
[ ] 🐛 Grammatical Error
[ ] 📝 Documentation Update
[ ] 🚩 Other

Description
Stone paper game
Add Link of GitHub Profile
https://github.com/Nikhil3389

I have completed the issue if you want any changes let me know


Concurrency bug

I have a build with 20+ maven modules where about a dozen contain rest controllers.
If i run with mvn clean install all is good
But we normally run the build in parallel for significant speed savings with mvn clean install -T1C
Then we hit this issue non-deterministically
if(referenceDataObject == null) {
// Investigation on a rare bug where the reference is not found.
throw new RuntimeException(
	"Writing schema but could not find a reference for class " + dataObject.getJavaClass().getSimpleName());
}

I suspect the issue is in ApiResourceScanner, where a static reference to the TagLibrary gets overwritten.
public TagLibrary scanRestControllers() throws MojoFailureException {

final TagLibrary library = new TagLibrary();
TagLibraryHolder.INSTANCE.setTagLibrary(library);

Thank you @dantheperson, I think you are right. Fun fact: after almost 2 years of utilisation, someone in my company reported me this issue yesterday. 😮
This will require me a bit of work since it is not the only "not thread safe" logic.


fix(clerk-js): Add margin for clerk tag and refactor the modal close button

Type of change

[x] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[x] @clerk/clerk-js
[ ] @clerk/clerk-react
[ ] @clerk/nextjs
[ ] @clerk/remix
[ ] @clerk/types
[ ] @clerk/themes
[ ] @clerk/localizations
[ ] @clerk/clerk-expo
[ ] @clerk/backend
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/fastify
[ ] gatsby-plugin-clerk
[ ] build/tooling/chore

Description

[x] npm test runs as expected.
[x] npm run build runs as expected.

Add a new ModalContext that contains information about the most recent modal opened. We can close the modal using the hook.
Place the close modal button inside the BaseCard and only show it if we can find the ModalContext. It toggles the modal upon click(retrieves the toggle function from the context).

@nikosdouvlis A typescript error pops up on the toggle function from the ModalContext as a result of the DeepPartial type (when using the unsafe hook). Can we make that type a bit better?

A typescript error pops up on the toggle function from the ModalContext as a result of the DeepPartial type (when using the unsafe hook). Can we make that type a bit better?

Ive made a small adjustment and it should now work as expected


Rename pointwise ops

For clarity on kernel names found when profiling. The new names are set to the order of the ops being compiled. For example: add + relu = add_relu_kernel.

This should be based on #1125.

I think it would be better to just have a function to iterator over operators rather than do this in the generator:
std::vector<std::string> get_op_names(module& m)
{
    std::vector<std::string> result;
    for(auto& ins:m)
    {
        if (starts_with(ins->name(), "@"))
            continue;
        result.push_back(ins->name());
    }
    return result;
}

we are doing more profiling lately.  I feel this will help.  You should push to get this in

we are doing more profiling lately. I feel this will help. You should push to get this in

Noted. Will prioritize and open for review soon.

I think it would be better to just have a function to iterator over operators in a module rather than do this in the generator:
std::vector<std::string> get_op_names(module& m)
{
    std::vector<std::string> result;
    for(auto& ins:m)
    {
        if (starts_with(ins->name(), "@"))
            continue;
        result.push_back(ins->name());
    }
    return result;
}

changed


Update Azure OpenAI to 2024-04-01-preview.

[ ] The purpose of this PR is explained in this or a referenced issue.
[ ] The PR does not update generated files.

These files are managed by the codegen framework at Azure/autorest.go.

[ ] Tests are included and/or updated for code changes.
[ ] Updates to module CHANGELOG.md are included.
[ ] MIT license headers are included in each file.

/azp run go - azopenai

/azp run go - azopenai

/azp run go - azopenai


"Azure Machine Learning" service is not available

Suggesting to make the text consistent with what the user should do. There is no "Azure Machine Learning" service name, and the screenshot below shows "virtual machines".

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

#label:"aq-pr-triaged"

@sdgilley for review
Thanks.

#sign-off

fixes https://github.com/MicrosoftDocs/azure-docs/issues/85095#issuecomment-990896903


Missing/incorrect files for preprocessing

Hi,
Thanks for this great repository.
I downloaded the AWS Last-Mile Challenge dataset (step 2; via aws s3 sync --no-sign-request s3://amazon-last-mile-challenges/almrrc2021/ ./data/), and am now trying to preprocess the data (step 3). However, it seems that some file names are missing/inconsistent when I tried to run the script below:
train_data_dir=almrrc2021-data-training
eval_data_dir=almrrc2021-data-evaluation

# generate package information in Parquet (training)
python preprocessing.py --act gen_route --data_dir  data/${train_data_dir}
# generate travel time matrix for all stops in a route (training)
python preprocessing.py --act gen_dist_mat --data_dir  data/${train_data_dir}
# generate zone information for each stop (training)
python preprocessing.py --act gen_zone_list --data_dir  data/${train_data_dir}
# generate ground-truth zone sequence for each route
python preprocessing.py --act gen_actual_zone --data_dir  data/${train_data_dir}
# generate package information in Parquet (evaluation)
python preprocessing.py --act gen_route --data_dir  data/${eval_data_dir}
# generate travel time matrix for all stops in a route (evaluation)
python preprocessing.py --act gen_dist_mat --data_dir  data/${eval_data_dir}
# generate zone information for each stop (evaluation)
python preprocessing.py --act gen_zone_list --data_dir  data/${eval_data_dir}

I noticed that the JSON files under almrrc2021-data-training folder are slightly different from those under almrrc2021-data-evaluation, e.g., almrrc2021-data-training/model_score_inputs/new_actual_sequences.json  vs. almrrc2021-data-evaluation/model_score_inputs/eval_actual_sequences.json.
Would it be appropriate to rename the former to eval_actual_sequences.json in this case? Or is it better to handle this in preprocessing.py, e.g., the LMC_ACTUAL_FN variable?

It seems that we also need to manually create data and distance_matrix subfolders. Would be good to handle this in preprocessing.py as well.
Nevertheless, after doing the above, I still see this error:
Traceback (most recent call last):
  File "preprocessing.py", line 459, in <module>
    raise Exception('Missing the name of the parquet file (e.g. lmc_route_full_1637316909.parquet) generated by the gen_route action')

Hi @oentaryorj , thank you very much for reporting the issue. Can you please git pull the latest from the main branch?
I have fixed the file naming issues in the code, so depends on the --mode argument, it will change the file name (in fact sub-directory name) accordingly.
I have also added the auto-creation of sub-folder distance_matrix and zone_list. The sub-folder data is not auto-created only because it is possible the this folder is outside of the git repository (depends where the dataset is downloaded to). So you could use the argument --data_dir to tell the preprocessing script where the train or eval dataset is
The second error was due to the missing parameter --pkfn, and I have added that in the README.md instruction. This file is only generated after you run the python preprocessing.py --act gen_route
Please let me know if you see any other problems. Thanks again for your help.


Add MSRV check to CI

Currently, changes can bump the MSRV without noticing. Would be good to have this documented and stable for #51.
Noticed from #104 bumping MSRV without any failing CI

FWIW, I’ve recently written down my current thoughts on MSRV here: https://github.com/matklad/once_cell/issues/201

Hmm, I completely understand the viewpoint, and maybe we make no guarantees about bumping msrv during minor/patch versions, but is it not still beneficial to have this msrv controlled and visible?
Feel free to close, I don't have an actual opinion on this

Crates should document their MSRV policy, and, if the policy is different from "latest stable" it should be tested on CI.
I am not entirely sure what's the right MSRV policy for borsh, the following makes sense to me:

MSRV is not breaking
MSRV is six months at least
explicit non-support for debian stable and such
newer compilers can be used if required by a feature (cosnt-generics) or via feacher-checking in build.rs (eg, via rustc-version or autocfg crates).

If we have abundance of resources, 2 year MSRV would also make sense to me
If we are very short on resources, I think declaring "latest stable" won't be catastrophic either.


Added doy adjustments to indices using percentiles

Please check if the PR fulfills these requirements

[x] This PR addresses an already opened issue (for bug fixes / features)
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, etc.)

Use adjust_doy_calendar in indices using percentile values.

Created infer_doy_max and interpolate_doy_calendar to split the logic in adjust_doy_calendar.

Does this PR introduce a breaking change? (Has there been an API change?)
No.

Fixes #101

@Zeitsperre It seems the build does not pick the xarray version with the CFTimeIndex resampling. Ideas ?

@huard I found out the hard way this morning that the latest stable release of xarray does not integrate the work done by @jwenfai allowing for resampling with CF-Time calendars yet. An easy fix is to re-add the git URL for pydata/xarray@master to the setup.py requirements if you want passing tests for the time being.

I'm hoping that his work will be in the next stable release.

Haven't be able to do that in the setup.py using
'xarray>0.11.3',
and
dependency_links=['http://github.com/pydata/xarray/tarball/master#egg=xarray-0.11.4'],
Skipping test for now.

Pull Request Test Coverage Report for Build 483

23 of 25 (92.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 85.954%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

xclim/utils.py
21
23
91.3%

Totals

Change from base Build 474:
0.08%

Covered Lines:
716

Relevant Lines:
833

💛  - Coveralls

Pull Request Test Coverage Report for Build 483

23 of 25 (92.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 85.954%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

xclim/utils.py
21
23
91.3%

Totals

Change from base Build 474:
0.08%

Covered Lines:
716

Relevant Lines:
833

💛  - Coveralls

Pull Request Test Coverage Report for Build 483

23 of 25 (92.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 85.954%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

xclim/utils.py
21
23
91.3%

Totals

Change from base Build 474:
0.08%

Covered Lines:
716

Relevant Lines:
833

💛  - Coveralls

The dependency link approach is deprecated as of 2016. The approach I just tried that seems to work well is adding the following to requirements in setupy.py:
'xarray @ https://api.github.com/repos/pydata/xarray/tarball/master'
Unfortunately, the current master is incompatible with Python2.7. Quite the headache.

Je trouve qu'avoir interpolate_doy_calendar et adjust_doy_calendar c'est un peu mélangeant et je suggère de les unir sous le nom adjust_doy_calendar.  Présentement adjust_doy_calendarne fait pas grand chose. Ceci dit, ce n'est qu'une suggestion.

Je trouvais que splitter en deux facilitait les tests. Ceci dit on pourrait renommer interpolate.. vers _interpolate.. pour éviter de contaminer le name space avec des fonctions qui se ressemblent trop.

Ça me va. Pour le reste, ça me semble ok.


Explore JDI Dark's ability to use on real projects

what is missing
what is not convenient to use

Done in case of creating rest-assured-like tests.


server: upgrade github.com/moov-io/base to v0.10.0

Codecov Report

Merging #594 into master will not change coverage.
The diff coverage is 73.91%.

@@           Coverage Diff           @@
##           master     #594   +/-   ##
=======================================
  Coverage   92.22%   92.22%
=======================================
  Files          64       64
  Lines        5388     5388
=======================================
  Hits         4969     4969
  Misses        274      274
  Partials      145      145


Add new DNS-over-HTTPS propagation check for ACME DNS01 challenges

What this PR does / why we need it:
If cert-manger is run behind proxy it often cannot do direct
DNS requests to authoritative servers. It is also not uncommon
for internal networks to have different DNS view of the same
domain (aka DNS split horizon setup) in which case changes made
to public DNS provider wont be visible from the inside and
DNS solver propagation check never succeeds.
This change adds new way to check for DNS propagation with
the help over DNS over HTTPS resolvers. In the current form it
uses Cloudflare DNS server with JSON format described in
https://developers.cloudflare.com/<IP_ADDRESS>/dns-over-https/json-format/
DNS check method to be used is controlled with
--acme-dns01-check-method=[dnslookup,dns-over-https] command line flag.
It keeps using DNS lookup as a default method.
Release note:
--acme-dns01-check-method=[dnslookup,dns-over-https] command line flag to switch DNS challenge propagation check from DNS lookup to DNS over HTTPS

@redbaron I believe that the same problem you describe could instead be solved outside of cert-manager by using the Kubernetes 1.10 feature of dnsConfig to set the nameservers to a public dns server, or an in-cluster dns server that can resolve public ips.
It could be used to do dns-over-https for traffic outside the cluster by having a dns resolver in-cluster that uses dns-over-https instead.
I think it may be better for the feature of configuring cert-manager's dns resolver to live in K8s since it's already implemented there and seems like a more generic solution.

AFAIK dns-over-https capable resolvers are not common yet, require careful  setup as they must continue to be resolving kubernetes.default.svc.cluster.local (for kube API requests) in addition to public DNS over https
kube version 1.10 is not minimally supported version by cert-manager yet and hopefully not going to be anytime soon
cert-manager not only talks to local resolver, it also connects to authoritative servers directly using local resolver just to discover them, so if outbound DNS connectivity is restricted as it often happens in constrained environments having a local DNS-over-HTTPS capable resolver wont help much

/ok-to-test

I'll throw out a couple other alternatives that come to mind for the case of outbound dns being restricted:

Allow a "sleep" method of propagation checking. That is, have an option like --acme-dns01-propogation-time=60s which would just result in cert-manager sleeping and assuming dns has updated.
Allow a "use local resolver" override for propagation checking. The local resolver already has to be able to resolve letsencrypt's api (and probably a dns01 provider's api) so it clearly has some access to resolve domains on the public internet. It'll be slower than talking to the nameserver, but it should still work I think.

Each of the above may also makes sense to be best configurable at the issuer level rather than as a global flag, especially propagation time since that may vary by domain or issuer.
I'm not really happy with either of these two options, I merely wanted to mention them for completeness.
The obvious slippery slope here is having a "dns propagation plugin system" where the user can just plug in an arbitrary check, but since dns servers are already kinda that sort of plugin system it seems like really just letting the dns server be configured covers that well enough.

May I suggest:
--acme-dns01-check-method=[ dnslookup, dns-over-https, none ]
Actually turning this check off would be a nice option to save messing around configuring custom resolvers

I don't think we should introduce a 'none' method - I'm fairly sure we should ensure DNS propagation has completed successfully, else LE may start invalidating orders before records have properly updated.
@cpu is this something that other ACME clients allow?

@munnerz , None should work too. ACME spec :

Clients SHOULD NOT respond to challenges until they believe that the
server's queries will succeed.  If a server's initial validation
query fails, the server SHOULD retry the query after some time.
While the server is still trying, the status of the challenge remains
"pending"; it is only marked "invalid" once the server has given up.

That is a valid assumption, that creating a DNS entry should be enough for Acme server to be able to retrieve challenge result. Checking propagation is just being extra nice, but creating entry and letting ACME server to start polling is just fine too

@redbaron I've added some thoughts over here: https://github.com/jetstack/cert-manager/issues/506#issuecomment-394351865
Clients SHOULD NOT respond to challenges until they believe that the
server's queries will succeed.

Allowing 'none' would be in violation of this statement, surely? Although it does say 'SHOULD NOT' (as opposed to 'MUST NOT'), it seems like we can do a better job of allowing us to check from the perspective of the ACME server than simply allowing a user to violate this part of the spec.

@cpu is this something that other ACME clients allow?

@munnerz I believe some clients support something like what is being described but I can't recall off-hand which. Typically I think a feature like this is added to support users that are running a split-horizon DNS where the server running the ACME client is on a privileged network and may receive different DNS records during a "self-validation" than would be received by the Let's Encrypt validation authority from an external network vantage point.
In general I think checking the DNS records ahead of POSTing the DNS-01 challenge is the correct thing to do for the vast majority of users. Doing otherwise is likely to cause users to hit the failed authorizations rate limit.

@munnerz some client CANNOT check that the DNS propagation has been completes successfully (airgapped or proxied environments with split horizon DNS)
the none rule should be actually timeout meaning that the challenge will be responded after a sufficient (configurable) amount of time.
The until they believe that the server's queries will succeed. will still be satisfied as the server will believe that waiting that amount of time is sufficient for the dns to be propagated.
believe is different from it's sure.
This is the only viable solution for airgapped environment that only have access to letsencrypt and dns apis (aws route53) like mine.
While obviously the default verification should be dns checks and the timeout or none should have a big warning notifying of the risk to reach rate limit, I don't see the point of limiting a valid option, required in many private networks.

@redbaron sorry for this going a bit quiet.
A few quick Qs - from what I understand, enabling this mode would require all authoritative nameservers up to the root NS supporting HTTP based DNS queries, as we directly query these instead of relying on a recursive NS (i.e. cloudflare).
I'd imagine 99% of these nameservers won't support HTTP based DNS queries, so I'm unsure how this will work for them unless they are hosting all their DNS using Cloudflare (which presumably supports HTTP based lookups on their authoritative NS).
Any thoughts on this? Seems like we may struggle to implement such a change given we don't only require on recursive NS for these lookups 😕

We've struggled to find a good solution to issue certs through cert-manager in a private network that contacts internet only through http proxies. We've workaround the issues by aliasing each NS in the pod definition.
DNS over HTTP seems to be a better solution that we've tested and it solved the issues in our case. For the propagation problem I don't quite understand why contacting each name server is required. solutions like https://github.com/certbot/certbot actually gives us a wait time to the DNS propagate should we use this along side with DNS-over-HTTPS as a prevention for rate-limiting let's encrypt?
Another potential solution would be request another component/service to validate the propagation, this component can be deployed in another network.

/remove-lifecycle stale
On Sun, 21 Oct 2018, 04:05 retest-bot<EMAIL_ADDRESS>wrote:

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually
close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack https://github.com/jetstack.
/lifecycle stale
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jetstack/cert-manager/pull/446#issuecomment-431635045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABA8OP4bencfnrbNKgqvLfkEymiRJ2_ks5um-R7gaJpZM4TOQkO
.

The simplest solution here is to follow eff's lead. Their reference client (certbot) doesn't check dns at all. It waits for a configurable amount of time (typically 30 seconds) and then goes on with its business. cert manager is completely unusable in my infrastructure and there is no way to remedy this so long as it's checking for propagation. The timeout could even be set arbitrarily high... But I think that's the right solution to this problem.

/remove-lifecycle stale

/remove-lifecycle rotten

/remove-lifecycle stale

@redbaron I would like to get in touch with you regarding this - as I plan working on it.
May I reach out to you somehow? :)
Best!


APT whitelist request for libspeexdsp-dev in Trusty

Same as https://github.com/travis-ci/apt-package-whitelist/issues/3508, which was erroneously closed as duplicate of travis-ci/apt-package-whitelist#3506. The two are for trusty and precise respectively.

@BanzaiMan some issues are getting closed due to bot thinking they are duplicates, like #3508 (and maybe this one soon). It's not the case, as the commit pointed out by the bot is for precise, not for trusty. Could you check?

See https://github.com/travis-ci/apt-whitelist-checker/pull/3


Add files to Git index by dragging and dropping

feature request

It will be amazing if files can be added to git index (as what git add command does) by dragging and dropping.
Sometimes the “plus” symbol is just not so easy to locate and click on.

/duplicate #23596


Understanding of train.py to find winning ticket

Hello, thank you for your excellent work!
I am confused about the use of train.py. It seems like the train.py only train the network on some certain dataset without any pruning. I am not sure how can I get a winning ticket initialization from that.

Hi @Flaick
train.py helps in getting the winning ticket initialization. The paper, uses late resetting of 1, hence the winning initialization is the weights of the network after it is trained for 1 epoch. train.py logs the weights of the model for the first 5 epochs. We use the weights logged after the first epoch as the --init-path argument in iterative_pruning.py, which perform the pruning.


use canonical json for all marshalling of TUF data

Related to #366.
It's safe to change serialization because all deserialization is done AFTER checking hashes and sizes.
Signed-off-by: David Lawrence<EMAIL_ADDRESS>(github: endophage)

LGTM!  Thanks for catching this!  And the require as assert should make the test output much easier to read.  :)
The only other non-test place I see json.Marshal being used is in tuf/encrypted/encrypted.go which I don't think is used anywhere.

LGTM!


Upstreaming ?

I wonder what the chances are for dtbocfg making its way into upstream. As far as I understand things, there currently doesn't seem to be a way to load PL with what's in the plain vanilla kernel, and you either need dtbocfg or the Xilinx fork to do that. Would be nice to have that available directly in mainline.

Thank you for the issue
I also want configfs to be introduced into the Linux Kernel mainline.
However, in December 2014, a similar patch was posted to the Linux Kernel by Pantelis Antoniou, but it had no effect.
https://lkml.org/lkml/2014/10/28/1022
https://lkml.org/lkml/2014/11/26/185
If everyone makes a request now, it may come true.

Great, thanks ! I'm not so sure about configfs itself (not on technical grounds, but having yet another layer of kernel bureaucracy added ... there's already plenty of that), but the underlying question would be how people use the PL loader today. As far as I understand it, there is no way without some kernel changes or out-of-tree modules, which in turn makes me wonder how much use this loader mechanism is actually seeing, and why it has been left in such a seemingly unfinished state.

This is great! Perhaps you could give it a try and mainline it? The attempt you point to above happened 6 years ago...


The port used differs from the docs

I have just spun up a fresh instance and spent a while digging to figure out that the port used is 8080, which is different to 8154 shown in the readme. Not a big issue but it's surely likely to trip someone else up.

Hey, what do you mean exactly? Port '8154' mentioned in the documentation is just a suggestion. You have the flexibility to configure it however you prefer, as long as it's mapped to the internal port '80'.