Support for Resident Evil 2 High Quality Music & Sound ver. 2018 SourceNext?

RE2's room files don't validate when using lexas87's Resident Evil 2 High Quality Music & Sound ver. 2018 SourceNext pack.

Do you know why they modify the RDT files?

Do you know why they modify the RDT files?

No idea. However, Classic Rebirth's RE2 page links directly to the mod.

Description from the author:

.SAP Music & Sound taken from GameCube 99.99% OST 00.01%
.SAP Voice taken from PSX 100%

3. .RDT fixed sound balance the sound evenly in both speakers 50/50

.EXE Official 1.1.0 patch by SourceNext
.DLL RE2 Classic REbirth v1.0.9 (16.10.2020) by Gemini

Solution:
Problem is point no. 3. Solution is just dont copy the RDT folders in Pl0 and Pl1 to the game folder. So your room data stay untouched and you dont get this error in biorand.
The RDT files are not mandatory for better music and sound because its only the sound balance what were edited.


Calculator: Lorentz Force Calculator  added

Fixes Issue🛠

issue : #1432
Closes #
Description👨💻

The Lorentz Force Calculator computes the force exerted on a charged particle moving through a magnetic field, allowing users to input magnetic field strength, charge, velocity, and angle. It provides a user-friendly interface with unit customization options and responsive design for seamless use on various devices.
Type of Change📄

[ ] Bug fix (non-breaking change which fixes a bug)
[X] New feature (non-breaking change which adds functionality)
[ ] Style (non-breaking change which improves website style or formatting)
[ ] Documentation (non-breaking change which updates or adds documentation)
[ ] Responsiveness (non-breaking change which improves UI/UX on different screen sizes)

Checklist✅

[X] I am an Open Source contributor
[X] I have performed a self-review of my code
[X] My code follows the style guidelines of this project
[X] I have commented on my code, particularly in hard-to-understand areas

Screenshots/GIF📷

@Rakesh9100 , please check my changes and merge the changes to project to make contribution sir.
Thank you

@GAVINESHWAR Please add your calculator in main index.html file in correct alphabetical order.

@GAVINESHWAR Please add your calculator in main index.html file in correct alphabetical order.

@Nihal4777 , I am resolved the issue please go through the  changes and merge the changes.
Thank you


Parsing CL arguments, signal handling and tool buttons design

Preserved the Suche Geräte button output on Terminal
Added interrupting signal handler for ctrl+c
Handled flag -l / --ls to output devices UUID merely
Handled flag -c to output all devices data
Handled flag -o to pipe all devices data into an existing .csv file
Handled flag -t to output all devices data during a given time
Arranged the size of buttons start, stop, Fortsetzen and Zurücksetzen to fit other tool buttons' size, and more ...

I am sorry for the confusion, but the Commandline-Tool should be in a separate Repository.

Isn't the feature meant to work with the OmniView project, please?

It is meant to work with the project. But it is supposed to be a standalone CLI application, that can be used to debug a scope, find all attached scopes and measure a waveform with a specific scope that is attached

That sounds great.
Tried to make enough changes in relevant files to get parsing command line arguments - the way wanted in the task - to work well, and it did on my side.
So the pr is not going to be merged but to be used as, say, a base in a separate repo for general use, right, please?


xDisk fails in Test-TargetResource with error about BlockSize

Cannot compare
@{BlockSize=4096} to 0 because the objects are not the same type or the object "@{BlockSize=4096}" does not implement "IComparable"

Hello,
Is this bug fixed? Im using latest version on my Azure VM and I still see this issue.
Best,
Kaido

The latest released version or the latest dev version.  The dev version is fixed.  It has not been released.

There are instructions in install developement builds here.

Im using the production release.
Best,
Kaido


Documentation MAVEN dependency fixed

This fixes #273.

Codecov Report

Merging #274 into master will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #274     +/-   ##
=========================================
- Coverage   80.33%   80.24%   -0.1%
=========================================
  Files         128      128
  Lines        3331     3331
  Branches      135      135
=========================================
- Hits         2676     2673      -3
- Misses        655      658      +3

Impacted Files
Coverage Δ

...e/akka/actor/process_index/ProcessIndexProto.scala
96.93% <0%> (-2.56%)
:arrow_down:

...rotomappings/SensoryEventStatusMappingHelper.scala
92.3% <0%> (+15.38%)
: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 6ed1237...b5f840f. Read the comment docs.

Cool thanks :D


Lua logging for debug purposes

https://github.com/29988122/Fate-Grand-Order_Lua/issues/115
https://github.com/29988122/Fate-Grand-Order_Lua/issues/118
Bugs, unintended behavior like this keep reappearing, so a proper debugging model's needed I guess.
I found this, but of course, this is not yet determined.
http://neopallium.github.io/lualogging/manual.html

I have looked into getting that implemented before I even tried the resolution scaling and I couldn't get it to work because it uses functions that are not inherently available in the Ankulua framework. So we may need to implement the function being asked for ourselves or find the one it tries to implement.


DnD 5e Version 3.0.1 compatibility?

Hi! I love your mod but sadly it doesn't work with the recent update of the DnD system to 3.0.0. and 3.0.1 anymore.
Are you planning on updating Items with spells for the new versions? That would be really great

I am not, no.


Upgrade Licensor dependency to version 1.24.3

Issues closed in this version https://github.com/xwikisas/application-licensing/milestone/39?closed=1

Closed with https://github.com/xwikisas/application-admintools/pull/27


Merging Jesse's PR

Codecov Report

Merging #18 (c2803a5) into main (0bc8831) will decrease coverage by 0.47%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #18      +/-   ##
==========================================
- Coverage   48.05%   47.57%   -0.48%
==========================================
  Files          11       11
  Lines         437      433       -4
==========================================
- Hits          210      206       -4
  Misses        227      227

Flag
Coverage Δ

unittests
47.57% <ø> (-0.48%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

ocean_model_skill_assessor/accessor.py
41.93% <0.00%> (-6.64%)
:arrow_down:

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 0bc8831...c2803a5. Read the comment docs.


fix storage version not as expected

Codecov Report
Base: 63.17% // Head: 63.17% // Decreases project coverage by -0.00% :warning:

Coverage data is based on head (00df335) compared to base (94b86c5).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #351      +/-   ##
==========================================
- Coverage   63.17%   63.17%   -0.01%
==========================================
  Files          75       75
  Lines       21322    21323       +1
==========================================
  Hits        13470    13470
- Misses       7852     7853       +1

Impacted Files
Coverage Δ

pallets/elections-phragmen/src/lib.rs
91.99% <0.00%> (-0.04%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Light Target-execute macro on powered down as well

Either rewrite powered on/powered off macros to be one macro with a powered state as an argument, or create two different macros.

The sensor will execute the macro when the number of lights changes, so that will happen from one to zero as well.


Simplify condition

I signed it!

Thanks for contributing! I'm not a fan of throwing the error at the end, since it obscured the correct code path.  What about:
var text = [];
if (selection) {
  ...
}
if (!text.length) throw new Error(...);
return text;

I think that pattern makes it clearer what the function is supposed to do, vs what is the anomaly.

Thank you! I agree with that.
Updated!

Awesome, thanks again!


more composable/interoperable protos

Hello! I'm working on tooling to generate clients, and it seems that juno doesn't do what others are doing for storing the proto files.
For example,

./proto/stargaze
./proto/osmosis
./proto/akash
./proto/cosmos

To make this more interoperable, can we move ./proto/mint/ so it's ./proto/juno/mint?
It looks like a pretty small change, but would be HUGE in terms of interoperability.

@faddat @JakeHartnell should be small change? I already tested in my local client and works great if we do something like this https://github.com/pyramation/protobufs/commit/53394ed2d9654b36cee4263de7c5b8e972680e69

I would be delighted to take care of this right now :-)

LGTM - consistency is super important

That it is.
I'm working on adding a formal protobufs generation process to juno, it is based on this PR:
https://github.com/osmosis-labs/osmosis/pull/1455/
I'd rather use buf

I've got some go-protobuf to typescript d.ts scripts laying around -
is anything like this already implemented, yet ?

https://github.com/faddat/archlinux-docker/actions/runs/2350303058
That's the new development environment being built, which includes buf

I've got some go-protobuf to typescript d.ts scripts laying around - is anything like this already implemented, yet ?

yea telescope is what I'm referencing for this issue, it codegens a TS library with clients loaded with types and amino messages,  https://github.com/osmosis-labs/telescope

https://github.com/cosmos/cosmos-sdk/issues/12150


allow process shell to use json by default

This is a small change that makes the assumption that external process types are always using json over their stdout.  If that's not true, use the --not-json-default flag.
The change means the --format flag is now optional if the process uses stdout, the following are equivalent:
bewest@hither:~/Documents/foo$ openaps use  oref0  shell calculate-iob monitor/pump-history.json 02.diyps/profile.json monitor/clock.json
{
  "bolusiob": 0,
  "iob": 0,
  "activity": 0
}

bewest@hither:~/Documents/foo$ openaps use --format text oref0  shell calculate-iob monitor/pump-history.json 02.diyps/profile.json monitor/clock.json
{"iob":0,"activity":0,"bolusiob":0}
bewest@hither:~/Documents/foo$

To restore previous behavior:
$ openaps use  oref0  shell --not-json-default calculate-iob monitor/pump-history.json 02.diyps/profile.json monitor/clock.json
"{\"iob\":0,\"activity\":0,\"bolusiob\":0}\n"bewest@hither:~/Documents/foo$


Improve fish#Indent().

This PR addresses some problems with the current fish#indent() function:

Fix: multiline strings should not be modified.
Fix: "end" is always decreased by one.
Fix: "case" and "else" are always decreased by one.
Fix: continued lines are not treated differently.
Fix: "if", "while", etc followed by "begin" should increment next line
by two instead of by one.
Fix: "case" should be one more than "switch".
Fix: multiline strings and continued lines are considered in the
calculations for the next line.

In this gist you can compare the results of using gg=G in a really bad indented fish file with the current and the proposed fish#indent().

May I ask what your improvement is? There aren't any comments and the code isn't that self documenting.

My bad, I was too tired when I finished it and created the PR. I have added some text to the PR comment.

I'm trying to work through the PR queue but this is a bit much for me to review at the moment (not having touched vim scripting for years and not having vim, git, fish or vim-fish currently set up).
However, if I remember correctly the idea was you use gq to format larger blocks of code, which will use the native fish_indent program that should probably handle every case correctly. fish#Indent() is meant to handle manual line-by-line input efficiently; is that working for you?

See also the comments on #20. Does your changes work with endwise?

@dag I tested this, and it works with endwise.  Can you merge this?  The indent functionality on master is broken and this PR works awesomely.

@dag Is there any way this could get merged?  I tested with endwise and it seems to work.  The indent functionality on master is broken for me and this fixes it.

Could this be merged if @Raimondi rebased on master?  Having the end living its own life is a bit annoying.


Ability to set a selector to a specific button

Hello,
This picture is a good example:

Good idea, I'll try to implement this when I have a bit of time

This will rely on this issue being fixed: https://github.com/afollestad/material-dialogs/issues/191

This is now available in release 0.6.1: https://github.com/afollestad/material-dialogs/releases/tag/v0.6.1
See the 'Themed' dialog in the sample for an example of how it's done.


Pose Inference Runtime Error

Hi, I am facing the runtime error issue while running the infer-pose.py.
command to export the yolo-nano model:
yolo export model=runs/pose/train13/weights/nano_club_pose_model.pt format=onnx simplify=True opset=11
ONNX to TensorRT conversion command:
/opt/tensorrt/bin/trtexec --onnx=../runs/pose/train13/weights/nano_club_pose_model.onnx --saveEngine=yolov-pose-fp16.engine --fp16
Here is the Nvidia docker container version nvcr.io/nvidia/tensorrt:23.01-py3
TensorRT: <IP_ADDRESS>
CUDA: 12.0.1
I used this command for inference:
python3 infer-pose.py --engine yolo-pose-fp16.engine --imgs ../images/ --out-dir outputs --device cuda:0
Traceback (most recent call last):
  File "infer-pose.py", line 112, in <module>
    main(args)
  File "infer-pose.py", line 37, in main
    bboxes, scores, kpts = pose_postprocess(data, args.conf_thres,
  File "/app/saim/YOLOv8-TensorRT/models/torch_utils.py", line 48, in pose_postprocess
    bboxes, scores, kpts = outputs.split([4, 1, 51], 1)
  File "/usr/local/lib/python3.8/dist-packages/torch/_tensor.py", line 791, in split
    return torch._VF.split_with_sizes(self, split_size, dim)
RuntimeError: split_with_sizes expects split_sizes to sum exactly to 17 (input tensor's size at dimension 1), but got split_sizes=[4, 1, 51]

You should use export-pose.py for export onnx and then build engine.

thanks @triple-Mu, I did that but still faced the same error. I resolve it by replacing outputs.split([4, 1, 51], 1) with outputs.split([4, 1, 12], 1). Now it's working fine. But I got FPS with Preprocessing:  81.73004150509558 | FPS without Preprocessing:<PHONE_NUMBER>949751 (image size =1280x1280, GPU=RTX-4090)
Any suggestion to speedup pre-processing part?

Maybe you can try cuda warp affine

I am use yolov8s-pose-p6.engine,
its size (12801280), if image is 12801280, it work fine.
But my image size is (1280720), the output can not detect any keypoint.
how I can use yolov8s-pose-p6.engine to detect my image (1280720)?
Thanks.

I am use yolov8s-pose-p6.engine,
its size (1280, 1280), if image is (1280, 1280), it work fine.
But my image size is (1280, 720), the output can not detect any keypoints.
how I can use yolov8s-pose-p6.engine to detect my image (1280, 720)?
Thanks.

I am use yolov8s-pose-p6.engine, its size (1280, 1280), if image is (1280, 1280), it work fine. But my image size is (1280, 720), the output can not detect any keypoints. how I can use yolov8s-pose-p6.engine to detect my image (1280, 720)? Thanks.
You shoud modify the expport script for exporting 1280x720.
And modify the cpp code for image height and width

Thanks 從我的iPhone傳送triple Mu @.***> 於 2024年3月1日 晚上11:09 寫道：
I am use yolov8s-pose-p6.engine, its size (1280, 1280), if image is (1280, 1280), it work fine. But my image size is (1280, 720), the output can not detect any keypoints. how I can use yolov8s-pose-p6.engine to detect my image (1280, 720)? Thanks.
You shoud modify the expport script for exporting 1280x720.
And modify the cpp code for image height and width
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

Thanks 從我的iPhone傳送triple Mu @.> 於 2024年3月1日 晚上11:09 寫道： I am use yolov8s-pose-p6.engine, its size (1280, 1280), if image is (1280, 1280), it work fine. But my image size is (1280, 720), the output can not detect any keypoints. how I can use yolov8s-pose-p6.engine to detect my image (1280, 720)? Thanks. You shoud modify the expport script for exporting 1280x720. And modify the cpp code for image height and width —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.>

Hi @tuteming, your both dimensions should be divisible by 32. For 1280x1280 case, your both dimensions were divisible by 32, that's why its working fine. Moreover, we can say that its the loophole of YOLO, it works only dimensions, which are divisible by 32.

Thanks從我的iPhone傳送saim212 @.***> 於 2024年3月4日 下午3:32 寫道：
Thanks 從我的iPhone傳送triple Mu @.> 於 2024年3月1日 晚上11:09 寫道： I am use yolov8s-pose-p6.engine, its size (1280, 1280), if image is (1280, 1280), it work fine. But my image size is (1280, 720), the output can not detect any keypoints. how I can use yolov8s-pose-p6.engine to detect my image (1280, 720)? Thanks. You shoud modify the expport script for exporting 1280x720. And modify the cpp code for image height and width —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.>
Hi @tuteming, your both dimensions should be divisible by 32. For 1280x1280 case, your both dimensions were divisible by 32, that's why its working fine. Moreover, we can say that its the loophole of YOLO, it works only dimensions, which are divisible by 32.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


Bubble_Sort

🚀 Feature
it is a simple sorting algorithm that repeatedly steps through the list, compares adjacent elements and swaps them if they are in the wrong order
Language
C++
Pitch
bubble sort in c++ is not in the list

Update the README


Unable to migrate on ubuntu 20.04

OS: Ubuntu 20.04 x86_64
Using version 2.0.1 to migrate:
log:
node:internal/modules/cjs/loader:1602
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /root/kill-the-newsletter/kill-the-newsletter/_/node_modules/better-sqlite3/build/Release/better_sqlite3.node)
    at Module._extensions..node (node:internal/modules/cjs/loader:1602:18)
    at Module.load (node:internal/modules/cjs/loader:1287:32)
    at Module._load (node:internal/modules/cjs/loader:1103:12)
    at Module.require (node:internal/modules/cjs/loader:1310:19)
    at require (node:internal/modules/helpers:179:18)
    at bindings (/root/kill-the-newsletter/kill-the-newsletter/_/node_modules/bindings/bindings.js:112:48)
    at new Database (/root/kill-the-newsletter/kill-the-newsletter/_/node_modules/better-sqlite3/lib/database.js:48:64)
    at new Database (file:///root/kill-the-newsletter/kill-the-newsletter/_/node_modules/@radically-straightforward/sqlite/build/index.mjs:104:9)
    at file:///root/kill-the-newsletter/kill-the-newsletter/_/build/index.mjs:44:24 {
  code: 'ERR_DLOPEN_FAILED'
}

Node.js v22.1.0

The bounded better-sqlite3 actually needs GLIBC_2.33, that is ubuntu 22.04, as it's builded on top of the 22.04 runner of Github. But maybe we can build it on ubuntu-20.04 in the Github Action, which will fix the problem.

I'm pleased to report that building on Ubuntu 20.04 has successfully resolved the issue!
I made some adjustments to the workflow, as the code in version 2.0.1 doesn't compile with the latest Node.js version (v23). To ensure compatibility, I locked the Node.js version to 22.1.0, which matches the version used in your releases.  You can see my successful build run at: https://github.com/Ovler-Young/kill-the-newsletter/actions/runs/11599220752
With these changes, the build process now works smoothly.
One minor hiccup I encountered was that my previous failed attempt had generated a malformed database. I had to remove this incorrect database to allow the migration to proceed correctly.

Hi @Ovler-Young,
Thanks for reaching out.
I’m glad you found a solution to the situation. You’re right in noticing that I tend to support and test on the latest versions. Speaking of which, what went wrong in building with Node.js 23? We better fix that 😅

Building with Node.js 23 failed because the better_sqlite3 failed. Again.
Error log can be found here.
After some check I found all runs in Node.js 22.x works fine, so I switched, and it works fine then.
It sees that better_sqlite3 had already fixed this problem in v11.5.0, and is fixed in radically-straightforward in commit https://github.com/radically-straightforward/radically-straightforward/commit/91b7ea0b9da7574059a5f6a8fa42a20a6fdea4ac !
There shouldn't have any problem on Node.js 23 now I believe.

It should be a matter of releasing a new version, then. I’ll get to it 🙂↕


Fix: Stray Memory Usage & Logging

The stray pile would grow and grow, often leading to providers attempting to claim strays that are long gone. This resets the stray pile every round and improves the logging for those strays.

#48 is being attacked more than one way in this PR so let's hope it's all good haha


Add pre-commit hook along with it's setup script for other Developers

Signed-off-by: Omar Khasawneh<EMAIL_ADDRESS>Description
The pre-commit hook will check style of Python code before a dev can commit. Purpose is to maintain good style of code.
Issues Resolved
Closes [#52]
Is this a backport? If so, please add backport PR # and/or commits #
Testing
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List

[ ] New functionality includes testing

[ ] All tests pass, including unit test, integration test and doctest

[X] New functionality has been documented
[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #53 (a4c642d) into main (8f639ca) will decrease coverage by 8.99%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #53      +/-   ##
==========================================
- Coverage   88.27%   79.27%   -9.00%
==========================================
  Files          19       29      +10
  Lines         580      941     +361
  Branches       50       87      +37
==========================================
+ Hits          512      746     +234
- Misses         62      184     +122
- Partials        6       11       +5

Impacted Files
Coverage Δ

...esting_framework/steps/step_test_source_cluster.py
23.80% <0.00%> (-47.62%)
:arrow_down:

...grade_testing_framework/cluster_management/node.py
89.18% <0.00%> (-10.82%)
:arrow_down:

...de_testing_framework/core/test_config_wrangling.py
94.04% <0.00%> (-5.96%)
:arrow_down:

...de_testing_framework/cluster_management/cluster.py
90.76% <0.00%> (-5.39%)
:arrow_down:

...e_testing_framework/steps/step_load_test_config.py
33.33% <0.00%> (-5.13%)
:arrow_down:

...work/cluster_management/docker_framework_client.py
96.96% <0.00%> (-1.90%)
:arrow_down:

...sting_framework/steps/step_start_source_cluster.py
22.22% <0.00%> (-1.31%)
:arrow_down:

...e_testing_framework/steps/step_bootstrap_docker.py
16.12% <0.00%> (-0.54%)
:arrow_down:

...grades/upgrade_testing_framework/core/constants.py
100.00% <0.00%> (ø)

...grades/upgrade_testing_framework/steps/__init__.py
100.00% <0.00%> (ø)

... and 12 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Feature request: Make syntax highlighting configurable

Brackets tries to guess the correct mode for syntax highlighting (probably from the file name). If the editor can not infer the file type, no syntax highlighting is done.
In my case for instance, shell scripts are not highlighted, if the extension is .zsh, but highlighting works if it is .sh.
Most other editors provide a possibility to let the user specify, which syntax highlighting should be applied. This can be done by letting the user specify, which file extensions should be associated to a certain file type. Other editors (jEdit, Emacs, ...) look for a specially formatted mode line in the first few lines of a file.
No matter how this is done, there should be a similar feature available for Brackets too.

Hi @rovf!
You can change the syntax highlighting applied in the bottom pane:

This persist during the session (at least). I have done some work towards making this persistent across sessions, but the feature is not quite ready yet.
If you want to permanently associate some filetypes with some language, that is possible too but requires some work. Brackets uses CodeMirror as the code editor, which provides the language support too. You can override, add or remove the languages as you wish, usually by creating extensions. For more information see this document: https://github.com/adobe/brackets/wiki/Language-Support

Thanks for the information. To create a .brackets.json file looks - to me, at least - cumbersome for doing such a simple task. Maybe I'm spoiled here, because nearly every highlighting editor I know, allows a dialogue in the preferences where one can change the mapping between file extensions and file type.
If you think that my feature request does have a chance to be implemented, i.e. by providing a nicer user interface for this type of configuration than hacking json files, we could maybe leave this issue open. If you think that this likely won't be implemented, because it is difficult to do or against the basic concepts of brackets, please close the issue.


Showing an AnnotatedString is O(length_string * num_annotations)

There are many cases where the function at https://github.com/JuliaLang/julia/blob/c6732a79494f604e0f320ea451856a1c10511659/base/strings/annotated.jl#L396-L401 gets called a number of times proportional to the length of the string (leading to quadratic behavior).
https://github.com/JuliaLang/StyledStrings.jl/blob/f7af623e050b537ab2188d38a3e28025ba1cbab7/src/regioniterator.jl#L52 is one such place.
When you iterate an AnnotatedString character by character (as e.g. escape_string does in Base) it also shows up.
I think it would be good to:

do some pre processing of the annotations so that there is no need to do this type of random access lookup of them
provide a better iterator over an AnnotatedString that uses something similar to eachregion instead of having to do everything from scratch for every character.

Printing a somewhat long string to stdout is noticeably quite slow.

Some code to generate a long string:
using Random

function generate_annot_string(n)
    colors = [:yellow, :green, :blue, :red]
    offset = 1
    annotations = Tuple{UnitRange{Int64}, Pair{Symbol, Any}}[]
    while true
        col = rand(1:length(colors))
        l = rand(1:10)
        offset + l > n && break
        push!(annotations, (offset:(offset+l), :face => colors[col]))
        offset += l
    end
    s = randstring(n)
    return Base.AnnotatedString(s, annotations)
end

str = generate_annot_string(100000)

Yea, @LilithHafner and I talked about this a while ago that resulted in https://github.com/JuliaLang/julia/pull/54289. It used to be a sorted list so searchsortedfirst could be used and came to the conclusion that this made the semantics worse and we should remove ordering assumptions, with sorting being something that could be done on-demand as a preprocessing step when needed.
Using the example you provided, @time show(stdout, MIME("text/plain"), str) gives a whopping 2.2s on my machine. The current (unoptimised) eachregion-backed @time println(str) gives a butter but still unimpressive time of 0.4s.
I've just had a go at optimising eachregion by pre-sorting the annotations. With my changes, @time println(str) is O(n log n) and takes 0.015s. Much better!
That doesn't help with show being char-by-char and still O(n m), but I think it shows a path to acceptable performance.

I wonder why the string limiting doesn't apply?
julia> show(IOContext(stdout, :limit => true), MIME("text/plain"), String(str))
"XE0ooPvnGBs4ubRE2c8UdJki4UpbI3t2SGnqaAgVLPUba8ZJHjJe4PRfu6x1Z1OnMQcTI95jhn8DMSe507ei272QIsAnBLV5dFGzgb390kkd9ywVQ6z0PXPtIT1s685CeqkHqnIMLzQKhQjEoCcvNQXXydm16VMRmiaW5e3JkkjiJkALdpRj74eq7yHPZgueh88h3yJkxxM8mfEx61iKs5kKdLf3MyfCYZcmRs8EuQV2aGjrAazmMKevtDIf5Cp4tYeGMEBuwC1zZ0Pn7pL8TSKsZTRL73ed9gt9BIf7t2Njf8HxeerwtBZwZTMpa3oFCWRIoov2s7470AlR" ⋯ 99328 bytes ⋯ "9i3zXHswaDfMcXuZExW7dxsXPJj75Mz3ymckh3USUj84YDg3QBiFMLCFQaGJMXAzIrHBA8B0nK3eegTXHBWsJTVuN4KRo3bPjqoLSD103T8MXgncZbt9AdqctEYCtKbHgVLg7Gig3n4r14E8iYYE0wV1EmD43IOLqzKCtKZCu3xdKLMvrG9Ri22TfZMtKJeGQMFfCea9OMa5908TJQ9knjmd68MWN11pxkCAKJgTba3BT6wNBOkSg1gxkm1nlAzx44lPARaWnI14Wkw0wgk8a4XkANjKQkFfrK9BHSrdSMvqLy4215Xc6PZz7S7y1WqnWOxkbS6Az5AW4trX"
julia> show(IOContext(stdout, :limit => true), MIME("text/plain"), str)
# The entire string shows, with no truncation

Ok, that deserves it's own investigation, but I've just discovered why show is so much slower than print: While an optimized escape_string is defined, Base.escape_string isn't imported :facepalm: (I suppose this is another argument for #69).
With an added Base., I now see:
juila> @time show(stdout, MIME("text/plain"), str)
"... lots of output..."
 0.037248 seconds (552.72 k allocations: 26.695 MiB, 35.34% gc time)

So, as of #74 original issue raised here will be fixed.


args: default negatable to false

This issue was originally filed by @seaneagan

I can't prove this, but I feel like non-negatable is more common.
For example, --help, --verbose, --quiet, --version are all non-negatable.  Also, since flags should generally default to false, specifying --no-foo is redundant.  I would prefer to explicitly ask for this feature when I need it, but I'm not sure when that would be.

This issue has been moved to dart-lang/args#26.


Add XSD schema to phpunit.xml.dist config

added XSD schema, so it can be validated (and PHPStorm provides
auto-completion)
dropped backupGlobals option, because false is the default value

I was unaware of the XSD schema for phpunit.xml. Thanks!


":join" truncates a comments "<!--" in xml files

Steps to reproduce
Create any xml file with content:
<?xml version="1.0" encoding="UTF-8"?>
<foo>
  <bar/>
  <!-- comment -->
</foo>

Open this file with vim -u NORC
Move the cursor to the third line
Press "J"
Note: :join command works correct with vim -u NONE.

I tried it and it works as it should with both NORC and NONE.

On 2017-12-24, AvianY wrote:

I tried it and it works as it should with both NORC and NONE.

For me, with NONE and with
vim -u NORC --cmd "set rtp=/usr/local/share/vim/vim80" comment.xml

it works fine.  (My plugin dependencies prevent me from using just
NORC.)  However, if I run just vim with no options and execute the
:join on line 3, I get this:
 comment -->
So there is something common between Dmitrii's configuration and
mine that causes this, but I don't know what.  I also tried this,
vim -u NORC --cmd "set rtp=/usr/local/share/vim/vim80" --cmd "filetype plugin indent on" --cmd "syntax on" comment.xml

but it also worked fine.  Is a puzzlement.  I'll poke around some
more.
Regards,
Gary

On 2017-12-24, Gary Johnson wrote:

On 2017-12-24, AvianY wrote:

I tried it and it works as it should with both NORC and NONE.

For me, with NONE and with
vim -u NORC --cmd "set rtp=/usr/local/share/vim/vim80" comment.xml

it works fine.  (My plugin dependencies prevent me from using just
NORC.)  However, if I run just vim with no options and execute the
:join on line 3, I get this:
 comment -->
So there is something common between Dmitrii's configuration and
mine that causes this, but I don't know what.  I also tried this,
vim -u NORC --cmd "set rtp=/usr/local/share/vim/vim80" --cmd "filetype plugin indent on" --cmd "syntax on" comment.xml

but it also worked fine.  Is a puzzlement.  I'll poke around some
more.

It happens when 'comments' is set to
s:<!--,m:     ,e:-->

as it is for XML files, and 'formatoptions' includes 'j'.
You can reproduce the problem this way:
$ vim -u NONE comment.xml
:let comments = "s:<!--,m:     ,e:-->"
:set fo+=j
:3join

where comment.xml contains Dmitrii's example.
Regards,
Gary

I confirm the bug.
With my usual settings, where 'formatoptions' is set to croql (and with the default settings from ftplugin/xml.vim) the comment is moved to after <bar/> with its <!-- leader and one intervening space. If I undo this change, then :setl fo+=j and hit J again, the comment loses its <!-- leader and there is one space between the ending > of <bar/> and the c of comment.
Using gvim 8.0.1424 (Huge) with GTK2-GNOME GUI.
Best regards,
Tony.

The j in 'formatoptions' means «When it makes sense, remove a comment leader when joining lines.» The question, of course, is «When does it make sense?» The examples in the help are for full-line // comments in C++ and IMHO, there, as well as e.g. " comments in vimscript, removing the comment leader when joined to a previous line which is also a comment makes sense. But in the case presented above by Dimitri, the comment is joined to a previous line which is not a comment (and does not end in a comment), and IMHO, here is doesn't "make sense" to remove a comment leader, regardless of the presence of j in `'formatoptions'
Best regards,
Tony.

On 2017-12-24, Gary Johnson wrote:

On 2017-12-24, Gary Johnson wrote:

On 2017-12-24, AvianY wrote:

I tried it and it works as it should with both NORC and NONE.

For me, with NONE and with
vim -u NORC --cmd "set rtp=/usr/local/share/vim/vim80" comment.xml

it works fine.  (My plugin dependencies prevent me from using just
NORC.)  However, if I run just vim with no options and execute the
:join on line 3, I get this:
 comment -->
So there is something common between Dmitrii's configuration and
mine that causes this, but I don't know what.  I also tried this,
vim -u NORC --cmd "set rtp=/usr/local/share/vim/vim80" --cmd "filetype plugin indent on" --cmd "syntax on" comment.xml

but it also worked fine.  Is a puzzlement.  I'll poke around some
more.

It happens when 'comments' is set to
s:<!--,m:     ,e:-->

as it is for XML files, and 'formatoptions' includes 'j'.
You can reproduce the problem this way:
$ vim -u NONE comment.xml
:let comments = "s:<!--,m:     ,e:-->"
:set fo+=j
:3join

where comment.xml contains Dmitrii's example.

The problem seems to be that get_last_leader_offset(), called at the
start of skip_comment(), sees the leading spaces in line 3 as the
middle part of the three-part comment defined in 'comments' and
identifies line 3 as a comment.  Consequently, when line 4 is joined
to line 3, the comment leader of line 4 is removed.
The html filetype has the same 'comments' value and suffers the
same problem.  I also discovered that the problem occurs when the
line on which the join is executed contains spaces anywhere, not
just at the start.
I don't understand the code and all the issues involved with
handling three-part comments well enough to have a solution, though.
Regards,
Gary

I suppose that, ideally, a line headed by a middle-part comment header should not be regarded as a comment unless the (joined or not) line before that is either a first-part comment or (recursively) a middle-part comment preceded by etc. Also, a first- part comment header ought not to be suppressed unless it is joined to a preceding end- (not middle-) part comment line (whose end trailer is then also suppressed).
But I don't know if it is possible or worthwhile to program all this into "a simple (sic) text editor which is not a word processor".
Best regards,
Tony.


cronjob main server

versionen der pakete?

updated packages flexdashboard and plotly from conda-forge (along with almost everything else?), then it worked...


When my bootstrap is upgraded from 5.2.0 to 5.2.1, there will be a problem when the button is active.

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
when version is 5.2.0,.btn:active attribute is overridden.

But when version is 5.2.1,btn:first-child:active attribute cant overridden.

How should this problem be solved?
Reduced test cases
none
What operating system(s) are you seeing the problem on?
macOS
What browser(s) are you seeing the problem on?
Chrome
What version of Bootstrap are you using?
5.2.0 to 5.2.1

This is caused by the weight of the selector, but the weight of many button selectors in the project needs to be re-modified after the upgrade.

These selectors were changed back in v5.2.2, please upgrade.


Ignore git-ignored files when running pre-commit hooks

Closes #9046

BTW I think we should get rid of the reformat package, similarly to this PR in the snarky repo: https://github.com/o1-labs/snarky/pull/589

BTW I think we should get rid of the reformat package, similarly to this PR in the snarky repo: o1-labs/snarky#589

Agreed.
Also, many of the remaining ignored paths should really be local, and not committed, much like .git/info/exclude.
If this is to be deprecated, there should be an ocamlformat equivalent for local exclusion.
Otherwise, I'd suggest that we transition to local git exclude lists, instead of polluting the codebase with unnecessary excludes.

What do you mean by local excludes?

What do you mean by local excludes?
One might specify files to be excluded from git in their .git/info/exclude, which is by default ignored by git.
This allows one to maintain custom files that are tracked, without needing to modify the .gitignore.

see https://git-scm.com/docs/gitignore

Old and stale, closing.


Inventory Move Event

Would need to change the MoveItem function in PlayerInventory to public then this could be possible :]would be needed for more complex things down the road

Will be added.

http://forum.pluton-team.org/threads/hooks-wishlist.362/#post-2074


Kcl/tunnelendpoints write connection status

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #(issue)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[ ] Test A
[ ] Test B

Hi @alacuku. Thanks for your PR!
I am @adamjensenbot.
You can interact with me issuing a slash command in the first line of a comment.
Currently, I understand the following commands:

/rebase:            Rebase this PR onto the master branch (You can add the option test=true to launch the tests
when the rebase operation is completed)
/merge:             Merge this PR into the master branch
/build              Build Liqo components
/test               Launch the E2E and Unit tests
/doc-build          Trigger the build of the Liqo documentation

Make sure this PR appears in the liqo changelog, adding one of the following labels:

kind/breaking:      :boom: Breaking Change
kind/feature:       :rocket: New Feature
kind/bug:           :bug: Bug Fix
kind/cleanup:       :broom: Code Refactoring
kind/docs:          :memo: Documentation

/build

/build

/build

/build

/build

/test

/test

/test

The generated artifacts appear to be out-of-date.
Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:
make generate

Here it is an excerpt of the diff:
diff --git a/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go b/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go
index 9ee0de2..29b13fa 100644
--- a/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go
+++ b/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go
@@ -17,7 +17,6 @@ package foreignclusteroperator
import (
  "context"
  "fmt"
-	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
  "net/http"
  "sync"
  "time"
@@ -27,6 +26,7 @@ import (
  metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
  "k8s.io/apimachinery/pkg/runtime"
  "k8s.io/apimachinery/pkg/types"
+	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
  "k8s.io/klog/v2"
  "k8s.io/utils/trace"
  ctrl "sigs.k8s.io/controller-runtime"

/test

The generated artifacts appear to be out-of-date.
Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:
make generate

Here it is an excerpt of the diff:
diff --git a/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go b/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go
index bfa9ad4..ee4688c 100644
--- a/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go
+++ b/pkg/liqo-controller-manager/foreign-cluster-operator/foreign-cluster-controller.go
@@ -17,7 +17,6 @@ package foreignclusteroperator
import (
  "context"
  "fmt"
-	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
  "net/http"
  "sync"
  "time"
@@ -27,6 +26,7 @@ import (
  metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
  "k8s.io/apimachinery/pkg/runtime"
  "k8s.io/apimachinery/pkg/types"
+	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
  "k8s.io/klog/v2"
  "k8s.io/utils/trace"
  ctrl "sigs.k8s.io/controller-runtime"

/test

The generated artifacts appear to be out-of-date.
Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:
make generate

Here it is an excerpt of the diff:
diff --git a/pkg/liqo-controller-manager/foreign-cluster-operator/auth.go b/pkg/liqo-controller-manager/foreign-cluster-operator/auth.go
index 7111cb3..e48944b 100644
--- a/pkg/liqo-controller-manager/foreign-cluster-operator/auth.go
+++ b/pkg/liqo-controller-manager/foreign-cluster-operator/auth.go
@@ -21,11 +21,11 @@ import (
  "errors"
  "fmt"
  "io"
-	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
  "net/http"

  kerrors "k8s.io/apimachinery/pkg/api/errors"
  metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
  "k8s.io/klog/v2"
  "sigs.k8s.io/controller-runtime/pkg/predicate"


Hero section Improvement

What would you like to share or ask?

Adding beautiful graphic can make website look more good. Wish to work under GSSoC'23
Additional information
No response

please assign me this issue i will solve under GSSOC'23


Update sbt to 1.3.0-RC3

Updates org.scala-sbt:sbt from 1.3.0-RC2 to 1.3.0-RC3.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a fantastic day writing Scala!

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

labels: semver-pre-release

Codecov Report

Merging #37 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #37   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines           3      3
=====================================
  Hits            3      3

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 3b349ac...6b13f5f. Read the comment docs.


HADOOP-16579. Upgrade to Curator 4.2.0 and ZooKeeper 3.5.5

In this PR we upgraded the Apache Curator to 4.0.2 and Apache ZooKeeper to 3.5.5.
While the new ZooKeeper is backward-compatible with the old one, we encountered a few minor issues still. So far the following changes have been made:

I added a static initializer for the unit tests using ZooKeeper to enable the four-letter-words diagnostic telnet commands. This is an interface that become disabled by default due to security concerns. (see https://issues.apache.org/jira/browse/ZOOKEEPER-2693) To keep the ZooKeeper 3.4.x behaviour, we enabled it for the tests. Some tests in Hadoop (or other projects using Hadoop-Common) might actually use this feature e.g. to verify the status of ZooKeeper.
I also fixed ZKFailoverController to look for relevant fail-over ActiveAttempt records. The new ZooKeeper seems to respond quicker during the fail-over tests than the old ZooKeeper, so we made sure to catch all the relevant records by adding a new parameter to ZKFailoverontroller.waitForActiveAttempt().

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
84
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

0
mvndep
23
Maven dependency ordering for branch

+1
mvninstall
1209
trunk passed

+1
compile
1129
trunk passed

+1
checkstyle
182
trunk passed

+1
mvnsite
104
trunk passed

+1
shadedclient
1151
branch has no errors when building and testing our client artifacts.

+1
javadoc
111
trunk passed

0
spotbugs
137
Used deprecated FindBugs config; considering switching to SpotBugs.

0
findbugs
32
branch/hadoop-project no findbugs output file (findbugsXml.xml)

_ Patch Compile Tests _

0
mvndep
25
Maven dependency ordering for patch

+1
mvninstall
61
the patch passed

+1
compile
1045
the patch passed

-1
javac
1045
root generated 12 new + 1845 unchanged - 0 fixed = 1857 total (was 1845)

-0
checkstyle
188
root: The patch generated 9 new + 381 unchanged - 0 fixed = 390 total (was 381)

+1
mvnsite
115
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
826
patch has no errors when building and testing our client artifacts.

+1
javadoc
124
the patch passed

0
findbugs
26
hadoop-project has no data from findbugs

_ Other Tests _

+1
unit
26
hadoop-project in the patch passed.

+1
unit
637
hadoop-common in the patch passed.

+1
asflicense
48
The patch does not generate ASF License warnings.

7434

Subsystem
Report/Notes

Docker
Client=19.03.3 Server=19.03.3 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1656

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 1cc9f1ca945b 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 5cc7873

Default Java
1.8.0_222

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/1/artifact/out/diff-compile-javac-root.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/1/artifact/out/diff-checkstyle-root.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/1/testReport/

Max. process+thread count
1348 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-common-project/hadoop-common U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
39
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
68
Maven dependency ordering for branch

+1
mvninstall
1065
trunk passed

+1
compile
1013
trunk passed

+1
checkstyle
167
trunk passed

+1
mvnsite
266
trunk passed

+1
shadedclient
1219
branch has no errors when building and testing our client artifacts.

+1
javadoc
252
trunk passed

0
spotbugs
111
Used deprecated FindBugs config; considering switching to SpotBugs.

0
findbugs
34
branch/hadoop-project no findbugs output file (findbugsXml.xml)

_ Patch Compile Tests _

0
mvndep
30
Maven dependency ordering for patch

+1
mvninstall
157
the patch passed

+1
compile
969
the patch passed

+1
javac
969
the patch passed

-0
checkstyle
171
root: The patch generated 10 new + 531 unchanged - 3 fixed = 541 total (was 534)

+1
mvnsite
264
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
748
patch has no errors when building and testing our client artifacts.

+1
javadoc
251
the patch passed

0
findbugs
34
hadoop-project has no data from findbugs

_ Other Tests _

+1
unit
33
hadoop-project in the patch passed.

+1
unit
200
hadoop-auth in the patch passed.

+1
unit
555
hadoop-common in the patch passed.

-1
unit
523
hadoop-registry in the patch failed.

-1
unit
5008
hadoop-yarn-server-resourcemanager in the patch failed.

+1
asflicense
55
The patch does not generate ASF License warnings.

13711

Reason
Tests

Failed junit tests
hadoop.registry.cli.TestRegistryCli

hadoop.registry.secure.TestSecureRegistry

hadoop.registry.client.impl.TestCuratorService

hadoop.registry.operations.TestRegistryOperations

hadoop.yarn.server.resourcemanager.scheduler.fair.TestFairSchedulerPreemption

Subsystem
Report/Notes

Docker
Client=19.03.3 Server=19.03.3 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1656

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 336abbd

Default Java
1.8.0_222

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/2/artifact/out/diff-checkstyle-root.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/2/artifact/out/patch-unit-hadoop-common-project_hadoop-registry.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/2/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/2/testReport/

Max. process+thread count
5413 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common hadoop-common-project/hadoop-registry hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
41
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

0
mvndep
68
Maven dependency ordering for branch

+1
mvninstall
1119
trunk passed

+1
compile
1032
trunk passed

+1
checkstyle
169
trunk passed

+1
mvnsite
317
trunk passed

+1
shadedclient
1308
branch has no errors when building and testing our client artifacts.

+1
javadoc
281
trunk passed

0
spotbugs
108
Used deprecated FindBugs config; considering switching to SpotBugs.

0
findbugs
32
branch/hadoop-project no findbugs output file (findbugsXml.xml)

_ Patch Compile Tests _

0
mvndep
26
Maven dependency ordering for patch

+1
mvninstall
193
the patch passed

+1
compile
1031
the patch passed

+1
javac
1031
the patch passed

-0
checkstyle
165
root: The patch generated 26 new + 553 unchanged - 6 fixed = 579 total (was 559)

+1
mvnsite
309
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
756
patch has no errors when building and testing our client artifacts.

+1
javadoc
282
the patch passed

0
findbugs
30
hadoop-project has no data from findbugs

_ Other Tests _

+1
unit
33
hadoop-project in the patch passed.

+1
unit
197
hadoop-auth in the patch passed.

+1
unit
569
hadoop-common in the patch passed.

+1
unit
77
hadoop-registry in the patch passed.

+1
unit
169
hadoop-yarn-server-common in the patch passed.

+1
unit
5021
hadoop-yarn-server-resourcemanager in the patch passed.

+1
asflicense
57
The patch does not generate ASF License warnings.

14000

Subsystem
Report/Notes

Docker
Client=19.03.3 Server=19.03.3 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1656

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / bbcf0b9

Default Java
1.8.0_222

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/3/artifact/out/diff-checkstyle-root.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/3/testReport/

Max. process+thread count
1382 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common hadoop-common-project/hadoop-registry hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

LGTM

ZooKeeper 3.5.6 just got released, I gave it a try. If something goes wrong, I will revert.
I don't think the official announcement has been made, but the new ZooKeeper is already available on Maven Central. It contains some minor fixes and improvements, plus some CVE fixes. See the release note: https://github.com/apache/zookeeper/blob/branch-3.5.6/zookeeper-docs/src/main/resources/markdown/releasenotes.md

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
44
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

0
mvndep
75
Maven dependency ordering for branch

+1
mvninstall
1100
trunk passed

+1
compile
1077
trunk passed

+1
checkstyle
170
trunk passed

+1
mvnsite
319
trunk passed

+1
shadedclient
1283
branch has no errors when building and testing our client artifacts.

+1
javadoc
275
trunk passed

0
spotbugs
114
Used deprecated FindBugs config; considering switching to SpotBugs.

0
findbugs
35
branch/hadoop-project no findbugs output file (findbugsXml.xml)

-1
findbugs
112
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager in trunk has 1 extant findbugs warnings.

_ Patch Compile Tests _

0
mvndep
34
Maven dependency ordering for patch

+1
mvninstall
198
the patch passed

+1
compile
1021
the patch passed

+1
javac
1021
the patch passed

-0
checkstyle
173
root: The patch generated 26 new + 553 unchanged - 6 fixed = 579 total (was 559)

+1
mvnsite
313
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
761
patch has no errors when building and testing our client artifacts.

+1
javadoc
287
the patch passed

0
findbugs
32
hadoop-project has no data from findbugs

_ Other Tests _

+1
unit
30
hadoop-project in the patch passed.

+1
unit
201
hadoop-auth in the patch passed.

+1
unit
575
hadoop-common in the patch passed.

+1
unit
82
hadoop-registry in the patch passed.

+1
unit
168
hadoop-yarn-server-common in the patch passed.

+1
unit
5025
hadoop-yarn-server-resourcemanager in the patch passed.

+1
asflicense
53
The patch does not generate ASF License warnings.

14072

Subsystem
Report/Notes

Docker
Client=19.03.3 Server=19.03.3 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1656

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 3990ffa

Default Java
1.8.0_222

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/4/artifact/out/branch-findbugs-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager-warnings.html

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/4/artifact/out/diff-checkstyle-root.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/4/testReport/

Max. process+thread count
1395 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-common-project/hadoop-auth hadoop-common-project/hadoop-common hadoop-common-project/hadoop-registry hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1656/4/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Looks like the build succeeded (the only Findbugs issue was introduced by an independent recent commit of YARN-9773)

+1

Quick q: I'm seeing TestZKFailoverController failures on hadoop-common test runs on a jenkins server.  Does this change it or are the failures there all on our side?

do you see this test to fail on the current apache trunk branch?
I also saw it failing after upgrading ZooKeeper in Hadoop, and I had to add a small fix to the ZKFailoverController. After this fix the TestZKFailoverController was passing for me locally and also didn't fail on Yetus.

think this is a branch without that patch in; I'll look more closely. thanks


[UI] Programmer mode: BIN number may be displayed incorrectly

[UI] Programmer mode: BIN number may be displayed incorrectly (colored in red):

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

I think this issue is already been resolved.


Fix some syntax issues in the readme

This PR adds some clarified wording to the readme and fixes some syntax errors.
For brevity I only edited the Readme.md file.

Thanks


fix: remove employee consent attachment limit

Description :sparkles:
Allow more than 1 employee consent attachment. This caused issues in editing application. Remove the artificial limit. In applicant mode, the UI does not allow for more than one upload so this does not really change anything there.

APPLICANT branch is deployed to platta: https://helsinkilisa-ui-pr3221.dev.hel.ninja :rocket::rocket::rocket:

API branch is deployed to platta: https://helsinkilisa-pr3221.api.dev.hel.ninja/healthz :rocket::rocket::rocket:

HANDLER branch is deployed to platta: https://helsinkilisa-ui-handler-pr3221.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://helsinkilisa-ui-handler-pr3221.dev.hel.ninja :laughing::tada::tada::tada:

TestCafe result is success for https://helsinkilisa-ui-pr3221.dev.hel.ninja :laughing::tada::tada::tada:


chore: Update libOSCORE dependency to published version

Description
As libOSCORE is now fixed to also work from crates.io again, we can go to a released version. (We already were at the released code, using the tagged git rev, but it failed to build when checked out via crates.io).
Issues/PRs references
Works around https://gitlab.com/oscore/liboscore/-/issues/62 on "there's a confusing git submodule skipped line in our build output" by not even using git.

[x] I have followed the Coding Conventions.
[x] I have performed a self-review of my own code.
[x] I have made corresponding changes to the documentation.

Thanks!


nyc exit with code 1 and spawn EACCESS, no stack trace

Link to bug demonstration repository

consider a single project file: test.js.
The file content:
console.log("OK")

When I run
$ nyc test.js

Expected Behavior
should run and report 100% coverage.
Observed Behavior
spawn EACCESS

Troubleshooting steps
The run succeeds only after:

chmod +x test.js
and
adding shebang to the file

#!/usr/bin/env node

I encountered the problem when I tried to add nyc to a project that does not use a test runner, but wrote it's own test module as ./test/index.js that is run in CI like note test.
Environment Information

  System:
    OS: Linux 5.3 Ubuntu 18.04.4 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
    Memory: 433.68 MB / 15.40 GB
  Binaries:
    Node: 8.16.1 - ~/.nodenv/versions/carbon/bin/node
    npm: 6.13.4 - ~/.nodenv/versions/carbon/bin/npm
  npmPackages:
    nyc: ^15.0.0 => 15.0.0

This is the expected behavior.  You must either make index.js executable (chmod +x index.js and add shebang) or use nyc node index.js to execute.

The run succeeds only after:

chmod +x test.js
and
adding shebang to the file

#!/usr/bin/env node

I encountered the problem when I tried to add nyc to a project that does not use a test runner, but wrote it's own test module as ./test/index.js that is run in CI like note test.

ah. gotcha.

I don't know what note is?

heh. lol. you got me there ... it meant node test...


Add e2e test for Azure Storage Topic using Workload Identity

Proposal
We need to add e2e test coverage for the scenario
Use-Case
No response
Anything else?
No response

I will manage this

@mknet3 , do you have any update? are you still interested on helping with this?

Hey @mknet3
I tackle this as part of https://github.com/kedacore/keda/pull/4200


Doc on mock inconsistent with actual behavior

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
__mocks__ are not loaded by default.
$> git clone https://github.com/facebook/jest.git
$> cd examples/manual_mocks
$> yarn

Edit the __tests__/FileSummarizer-test.js and comment line 5 (jest.mock('fs')).
$> yarn test

And it fails.
What is the expected behavior?
The mock is loaded properly as stated in the documentation.
This is the sentence I'm referring to in particular: However, manual mocks will take precedence over node modules even if jest.mock('moduleName') is not called.
Or am I understanding something wrong?

This doesn't happen for core modules, like fs. You have to manually call jest.mock('fs') on them.

@cpojer I set up a small repo so you can try this with a non-core module here and I beg to differ.

Besides :

This doesn't happen for core modules, like fs. You have to manually call jest.mock('fs') on them.

The documentation doesn't state that.

@cpojer Sorry to ping you again but can you please take a look at https://github.com/Shahor/jest-error-example ?

@cpojer The documentation should state that __mocks__ works only with node_modules, it would be less misleading I think. Because @Shahor tried to use it to mock relative module in his example which definitely doesn't work. Also the documentation doesn't state in the manual mocks page that core modules are not mocked by default and that you should use jest.mock(). I think that this note should be added to it, since not everyone is going there. It could save a lot of time to people that are new to Jest.

They don't exclusively work for node modules. They also work for haste modules which is Facebook's custom module system.

Well, mocking relative modules definitely works but you have to be explicit about it.
Which the documentation only implies, and that's where the confusion arises (at least to me).
Different parts of the doc seem to indicate different things.
If you have this fs tree :
.
├── models
│   ├── __mocks__
│   │   └── user.js
│   └── user.js
└── specs
    └── models
        └── user.spec.js

4 directories, 3 files

Then in your `specs/models/user.spec.js' you can use the mock by doing the following:
// models/__mocks__/user.js
module.exports = 'MOCKED'

// models/user.js
module.exports = 'NOT MOCKED'

// specs/models/user.spec.js

const modelPath = '../../models/user'
jest.mock(modelPath)

const User = require(modelPath)

describe('some test', () => {
   it('does something', () => {
      expect(User).toEqual('MOCKED') // whatever
   })
})


work around macros that end with a line comment

well ok but who would end a macro with a comment :stuck_out_tongue:

it broke some of Symon/xdy's macros XD

github appears to be bugging out

source and target of the MR look right...
I hope it just works later in the day. it's also not like it'd be hard to do the work again if needed.

Closing but will give you credit. ;)


Time data for node and edge creation

Added support for automatic enforcement of creationDate and lastUpdateDate fields to nodes and edges upon request from other projects.
Also allows automatic definition of the DateTime scalar if requested/needed.
Some of the older tests seems to give errors (complains about object not having args)?
The change to add_edge_objects is not the neatest, but it gets the job done.

Looks good. I will merge this PR.


Do not invoke hooks if missing

During compilation if compiler does not have any hooks, the javascript throws an exception.
If the compiler.hooks is not mandatory can we wrap the compiler.hooks methods in a if (compiler.hooks) ?

I was under the impression compiler.hooks always existed. In what scenario is it null?


AVRO-1493: Java: Schema fingerprint vary by locale

fixes https://issues.apache.org/jira/browse/AVRO-1493

@krschultz, we're still interested in getting this in. It was just automatically closed by moving the project to git from SVN. You should be able to reopen it or submit a new one to get this change in. Thanks!

Rebased against the latest and re-opened it as #69


Serverless eventually locks up when running for a while

Actual Behaviour
Launching serverless-offline with serverless-dynamodb-local will always lock up after some seemingly random period of time. The terminal becomes unresponsive and there is no error or crash report.
Expected Behaviour
Run indefinitely.
Steps to reproduce it
I created a repo with a minimal project that has this behavior. https://github.com/robpc/dynamodb-local-test
If you follow the instructions in the example repo above and run the test script, the api will eventually will become unresponsive. Sometime it's been as early as 21 seconds in and sometimes it's as late as 10 minutes in. There appear to be periods of long delays (30-60 seconds) leading up to this point, but eventually it will be locked up and control-c has no effect. In my experience, it locks up the OS so badly a restart is required.
LogCat for the issue
No actual logs are shown, the process and serverless api lock up and are unresponsive.
Example output from the test linked above:
23:51 ✔ $ ./test.sh

Setup -- {"id":"1234","date":"4/11/2019, 10:52:18 PM"}

Press Q to exit.

  0 Days, 00:00:21 -- #47 -- {"date":"4/11/2019, 10:52:18 PM","id":"1234"}

Example serverless-offline output from the project above
23:43 ✔ $ npm run start

><EMAIL_ADDRESS>start /mnt/c/Users/Admin/projects/dunlin/dynamodb-test
> serverless offline start --migrate

Dynamodb Local Started, Visit: http://localhost:8000/shell
Serverless: DynamoDB - created table robpc-dynamodb-test-dev
Serverless: Starting Offline: dev/us-east-1.

Follow up with some things I tried after posting this issue:

I commented out the calls to dynamodb and was able to run the test for 6+hours, so that ruled out serverless in general.
I saw the DynamodbLocal.jar was running Oracle JDK 8 so I switched to that and still saw the issue.

Being suspicious of my own code I also updated the test code to remove some helpers I pulled from another project, but still had the issue.

Can confirm I'm also having this issue. The time it takes until it freezes appears to be getting progressively worse for me each time.


Meta Data import issue

It looks like the https://github.com/resolvetosavelives/healthicons/blob/main/public/icons/meta-data.json file is empty after 5b3aeb5.
Not sure why yet, but it is resulting in the tags being missing from the icon details, and the filename being used in place of the Title.

I figured it out (and fixed it for now).
@dburka When the Figma page was renamed from Export to Export (Be Careful), the import script broke.
I've renamed the page back to Export. It should be a trivial change for a dev to gracefully ignore the  (Be Careful) part of the page title.

How do we force the live site to rebuild based on the Figma file?

How do we force the live site to rebuild based on the Figma file?

Got it. Live site is fixed, but I'll leave this issue open until we make the import script a bit more robust.

Thanks. Sorry, I'm the one who renamed the page (obviously not realizing there were downstream consequences). Sorry!

A @dburka noted on Slack: "I think it's ok that this is a little fragile."


Remove limit of 75 custom fields on the Payment object to use Payment Mapping from the NPSP Settings page

If an instance has more than 75 custom fields on the Payment object, no Payment fields will appear available for mapping in NPSP Settings. This apparently is a limit that is no longer needed and should be considered for change. In the meantime, organizations can manually create Payment Mapping Settings records via Custom Settings in Setup, using the API names of the Opportunity and Payment fields they wish to map and unique Name fields (CustomMapping0, CustomMapping1, etc)

*lurch: add

**lurch: add

Tracking W-020975


New ECORR signal models

I'm starting this PR, again, so we can take a look at how things are progressing. It still needs tests and some cleanup related to Issue #90. Some of the new code is pretty cool, IMHO. To deal with ECORR in the N matrix we need to make it play nice with the standard N "vector" (i.e. the diagonal part of a diagonal matrix) that we use for EFAC, and EQUAD. In order to do this I've created three special data types: ndarray_alt, csc_matrix_alt, and ShermanMorrison. They all have their own __add__ methods so that they know how to add to one another (note that csc_matrix_alt cannot be added to ShermanMorrison at the moment but I don't know if you would ever want to do that anyway). They also have their own solve methods that have the same API for all so that the Likelihood doesn't need to know which kind of N you are using.
Here is how it works: the EFAC and EQUAD signals return ndarray_alt arrays (basically numpy arrays with special __add__ and solve methods), ECORR (sparse) signals return csc_matrix_alt arrays (which, again, are a special type of spicy.sparse.csc matrix with __add__ and solve methods), and ECORR (sherman-morrison) signals return a ShermanMorrison array. This way when computing the total N in SignalCollection using the sum function we return the correct type. For example ndarray_alt + csc_matrix_alt returns a csc_matrix_alt type array where we can then call solve in the likelihood. The same is true for ndarray_alt + ShermanMorrison where it returns a ShermanMorrison type array. I have done tests and all of this works smoothly but there are still a few more checks to do.
Here is how to use the solve method (for any of the three types mentioned above):
To solve Y^T N^{-1} X, where X and Y can be either vectors or matrices of the correct shape you can do N.solve(X, left_array=Y).
Lastly, in terms of the ECORR signal factories themselves I have defined EcorrKernelNoise which implements the sparse matrix version and have sub-classed that to create EcorrKernelNoiseSM which implements the Sherman-Morrison version. I would still like to clean these up a bit and make them easier to subclass but they are working now.
Timings (model m is EFAC + ECORR(sherman morrison) + timing model, model m2 is the same but with ECORR (sparse)) for J1909-3744:
T = m.get_basis()
N1 = m.get_ndiag(params)
N2 = m2.get_ndiag(params)
%timeit -n5 m.get_ndiag(params)
%timeit -n5 m2.get_ndiag(params)
%timeit -n5 N1.solve(psr.residuals, left_array=T, logdet=True)
%timeit -n5 N2.solve(psr.residuals, left_array=T, logdet=True)
%timeit -n5 N1.solve(T, left_array=T)
%timeit -n5 N2.solve(T, left_array=T)

returns :
5 loops, best of 3: 159 µs per loop
5 loops, best of 3: 99.7 ms per loop
5 loops, best of 3: 10.5 ms per loop
5 loops, best of 3: 29.9 ms per loop
5 loops, best of 3: 86 ms per loop
5 loops, best of 3: 96.6 ms per loop

So the solve method is fairly similar for the two methods but constructing N for the sparse case is very slow...

Ok, I've added new type for ECORR, BlockMatrix. It is similar to ShermanMorrison but takes a list of blocks (i.e., the small arrays that make up the block diagonal) and solves systems by just inverting the individual blocks. This way it is generic enough to handle blocks that cannot be written as the outer product of two vectors (a requirement for ShermanMorrison).  Oddly enough it is actually faster than the sparse matrix version overall.
Overall it still works but I'm not quite happy with how I've organized this. Right now there are three separate class factories for the three different methods of doing ECORR. This may not be the right thing to do as the signals are identical it is just the method that changes. Doing things this way does avoid having a bunch of if statements in the class if we were to try to include the method as an argument but maybe that is preferable in this case.
Thoughts?

I think this is ready to merge.

Ok, now I think we are good. After talking with @vallis, we've decided it is cleaner to just have one class factory with a method argument. It does involve a few internal methods and some if-statements but it is much clearer overall and makes more sense since these are not different signals, merely different methods of constructing the same signal.
So the signal is initialized as follows
# method can be sherman-morrison, block, or sparse
ec = EcorrKernelNoise(log10_ecorr=Uniform(-10, -5), selection=selection, method='sherman-morrison')

# initialize efac (ecorr cannot really act on its own so we always need efac even if fixed to 1)
ef = MeasurementNoise(efac=Uniform(0.5,1.5),  selection=selection)

s = ef + ec
model = s(psr)

# then the signal collection knows how to handle block-diagonal N-matrices for any of the three methods
N = model.get_ndiag(params)

# matrix operations are done with the following

# T^T N^{-1} T
TNT = N.solve(T, left_array=T)

# T^T N^{-1} \delta t
TNr = N.solve(psr.residuals, left_array=T)

# \delta t^T N^{-1} \delta_t
rNr = N.solve(psr.residuals, left_array=psr.residuals)

# the solve method also takes a boolean logdet option to return the log-determinant

Ok, for whatever reason there is some black magic happening when using .. math:: in the travis tests. For now I have just removed an equation from the docstrings. We can deal with this more when we finalize the documentation.
Merging now.


Fixed Data.Avro.Schema.extractBindings.

The old implementation had some odd bugs with nested type definitions, including missing types defined inside arrays and maps. This PR has a new implementation of extractBindings that fixes all the problems as well as a test case which covers a bunch of edge cases for extracting types from a schema.

This addresses #61.

Assuming this implementation is actually correct—I believe it is—I recommend back-porting this to older versions of the package with bug fix releases (ie <IP_ADDRESS>, <IP_ADDRESS> and so on).

Thanks!
The extractBindings functionality is fairly new. Do think it is a problem if we don't create bugfix releases, and instead assume that people can upgrade to the newest version?

It's not ideal. There have been some breaking changes recently, so upgrading isn't entirely trivial—I know it would require some extra updates/refactoring on one of my projects at work, for example. At the same time, the fix is pretty self-contained, so back-porting it should be straightforward.

OK, I'll try to find time to do it this weekend.

I looked at versions 0.3.4.x and 0.3.5.x and have found that extractBindings isn't a part of these versions. It has been first  introduced in <IP_ADDRESS> so perhaps retro-fix isn't needed for previous versions.

@AlexeyRaga sorry, I didn't explain the full context here.
extractBindings was only extracted to a top-level function recently, but before that the same logic was part of buildTypeEnvironment. The older implementations of buildTypeEnvironment still have the same bug, at least with types defined inside maps.  The retro fix may or may not define a top-level extractBindings, but it should fix the bug with buildTypeEnvironment.
By the way, I'm happy to write the code for fixing 0.3.4.x and 0.3.5.x, but I'm not sure how to organize it on GitHub. What can I open a PR against?

@TikhonJelvis I have created branches release-0.3.4, release-0.3.5 and release-0.3.6
If you make PRs into these branches then we'll be able to release patched versions for 0.3.4 and 0.3.5

@AlexeyRaga Awesome, thanks! I opened PRs against release-0.3.4 and release-0.3.5. The release-0.3.6 branch already has the correct behavior.


Factor forums models to remove redundancy

We had four types:
DiscussionThread, DiscussionComment, DiscussionResponse, DiscussionPost
Plus an enum DiscussionPostItem which was DiscussionPost +
DiscussionResponse.
Further, these types weirdly conflated fields from both threads and
comments.
Based on the types we actually get back, what we actually needed was just:
DiscussionThread and DiscussionComment.
This rips out those unneeded types and removes the redundant information
from the thread being shoved into a response.
There is more renaming that really wants to happen here, but this was
already getting long.

@mikekatz please review

@mikekatz pssst

sorry, this got lost in my noise last week. :+1:

:+1:

+1


Renamed 'Zend\Expressive\FinalHandler' to 'Zend\Stratigility\FinalHandler'

I'm not actually in a position to run the tests at the moment. I'm creating this as a PR because it's a bit more helpful than creating an issue and I'm hoping a bot will tell me if the tests pass when I submit!
Essentially, 'Zend\Expressive\FinalHandler' doesn't exist, and as such violates the service naming convention suggested in the docs. The actual path is 'Zend\Stratigility\FinalHandler'.

it's not, already right as @weierophinney  said in #18

That's very confusing!
If Zend Expressive will provide it's own final handler before the first stable release, then it makes sense to keep using it as a service name. Otherwise I struggle to see the logic.
In it's current form, it stands out as a glaring inconsistency. If the service name should be a class path that tells us something about the service, then it should reference a class path that actually exists. I don't think using callables as a final handler is a violation of this - the actual class path still tells us information about what the service does.
If it is the case that the final handler service requires different treatment than the other services, why use such a confusing service name? If the naming convention does not apply here, a service name should be used that makes it clear that we are not following the previous convention. In it's current form it makes us think that it is using the convention defined in the documentation, when actually it has no attachment to it at all.

If Zend Expressive will provide it's own final handler before the first stable release, then it makes sense to keep using it as a service name.

We already do. We have two different versions:

TemplatedErrorHandler, which is intended for production, and
WhoopsErrorHandler, which is intended for development.

Regarding this statement:

If the service name should be a class path that tells us something about the service

I'd argue that service names should reference interfaces whenever possible, to hint to the capabilities a service provides. That leaves us with a quandary, however: Stratigilty does not define an interface for "final handlers"; essentially, anything implementing the $next() contract of function (ServerRequestInterface $request, ResponseInterface $response, $error = null) can be used as a final handler. Zend\Stratigility\FinalHandler is simply a concrete implementation of it. (Stratigility does not define an interface for it, as it allows any callable to be used; the callable should, of course, accept that signature, but requiring an interface limits interoperability here.)
The two implementations I indicate above also follow the signature, and are specific to Expressive. I specifically did not use the name Zend\Stratigility\FInalHandler as I wanted to indicate that final handlers should provide better/more capabilities than that component provides.
Zend\Stratigility\FinalHandler can be used here, of course, but I do not want to specify an inheritance tree; neither of the implementations we provide in Expressive extend that class.
As such, the service name is correct as-is, and will not change at this time.

Respectfully disagree.
I can see from your explanation why you are not using 'Zend\Stratigility\FinalHandler' as the service name - but I do not think that implies that switching 'Stratigility' for 'Expressive' makes the service name sensible.
I'd just re-quote my last point:
"If it is the case that the final handler service requires different treatment than the other services, why use such a confusing service name? If the naming convention does not apply here, a service name should be used that makes it clear that we are not following the previous convention. In it's current form it makes us think that it is using the convention defined in the documentation, when actually it has no attachment to it at all."
As middleware that does not implement an interface will be quite common - this is actually a really good opportunity to introduce a new naming convention for these types of services.
"@final_handler"
"@final-handler"
"final_handler"
"final-handler"
etc...
As long as it can't be confused as following the previous convention.

I'd just like to add that I'm happy to submit a different PR for this which includes an explanation in the documentation if you agree?


Inaccurate value of Authentihash

the value of Authentihash is different from virustotal. and Value overflow occurred which cause panic.

Hello Wanglei,
Can you please provide me with a hash so I can test it.

panic:
filemd5：2c766f87b1fbd4623f8cd3f4d7e4d077；filename<EMAIL_ADDRESS>errors:
panic: runtime error: slice bounds out of range [651776:648704]
goroutine 1 [running]:
github.com/saferwall/pe.(*File).Authentihash(0xc0000003c0)
/home/mamba/go/pkg/mod/github.com/saferwall/pe@v1.2.1/security.go:193 +0x49a
main.main()
/mnt/c/Users/86187/code/cloud_av/engine/cmd/auth/main.go:21 +0x138
and some value is incorrect：
md5 :5b7f9a8a54b40f6f082eb6dbc97815ea
saferwall/pe: 3a7de06d59963b427aeb0092354fd778f6f501ab76440560eb6898b0f1919407 virustotal:fecdc011fcb33c0ee0e2d493060fda809c07de54643c5dddd6171b27838e6f98

Thanks to @wanglei-coder , this issue is now solved.


Deleting a local blueprint does not delete the thumbnail

Planbuild 0.9.0
When I delete a local blueprint, the .png file stays on disk.

Can't reproduce that unfortunately. Can you provide steps you did when that happened?

sorry for my late answer. I can not reproduce this error (anymore)


Clicking and dragging on a scrollbar of a dropdown moves the whole element

Clicking and dragging on a scrollbar of a dropdown inside a vector editor moves the whole element. When there are many columns, I am unable to scroll down to the last column. Scrolling with a mouse moves with the whole scene instead of the dropdown widget.
Screencast from 2023-06-08 18-37-57.webm

May be similar (even duplicate of) #6823

Closing as duplicate of #6823.


Create Ilmastoprofiilikysely page

[x] Create the page itself
[x] Link to it from front page
[x] Created separate join group component
[x] placeholder for climaterole accordion
[x] UI/UX
[ ] Cypress tests

Check, if there is need for more cypress tests than the ones that were created and modified from Kyselyt page.


Update address documentation [TwineHealth/TwineClient#4015]

Adds documentation for address state and country.

On hold since we're not going to release validation yet.


Addons imgpkgBundle.images need to be rebuilt on addon changes

Feedback
When updating an addon (contents, etc....) the imgpkgBundle.image needs to be rebuilt to have the latests contents.
Currently, it's pointing to projects.registry.vmware.com/tce/EXTENSION_NAME-extension-templates:dev, and if the image is not rebuilt, you won't get the new addon contents. Probably there needs to be defined some versioning on addon definition changes, but since we're moving to Package definitions, I'll leave it sleep until then.
Details
TCE build version: v0.1.0

Let's reopen if it's verified to not be completed.


Refactor statusapiv1 to trait and implement for ease of creation of these objects when we implement our own parser

This changes the statusapiv1 classes to be a trait and creates an impl classes for the same. This change in itself seems to achieve nothing. But this is in preparation for rewriting the eventlogparsing code to be implemented using our custom listeners and create the objects from that.  The previous classes with val were hard to create as it required to have all the data before creating the objects. the new impl classes have var members which will make it easy to set data.

Hi @shankar37, I think the PR is missing a commit renaming API classes to *Impl.
The PR seems to be missing a bit of context. Do you plan to make the JSON parsing streaming?

@shankar37 From this PR, it is difficult to understand the motivation of the change, and therefore it's difficult to review. Can you please share the design of the eventlogparsing code.

Here is hopefully the context.
Currently, the event log parsing happens in two ways. For the SparkFetcher, it streams the json event log and looks for EnvironmentUpdate Event only. This code is in SparkLogClient.scala.  This does not use the spark's replaybus and uses only the public apis of Spark. In addition, the SparkFetcher uses the SparkRestClient to get the rest of the data from REST APIs and deserializes them directly into the objects of statusapiv1.
The other one is in SparkFSFetcher, which uses replaybus and sparklistners's to parse the event log. Then it uses the LegacyDataConverter to convert the data read into the statusapiv1. There are a couple of problems with this. First, this doesn't parse all the data from the event log and some of the data we might require is not present. Second, in light of SPARK-18085 and this commit (https://github.com/apache/spark/commit/561e9cc390b429e4252f59f00a7ca4f6f8c853f8), these replaybus and these listeners are deprecated. Hence, we need to change the parsing of event log for FS Fetcher to use our own parser.
What I am planning to do is to write a generic EventLogParser which will take a stream and parse the event log json. It will parse it like SparkLogClient but for all events that we care for and will produce the StatusApiV1 data in its completely. Then both the SparkFSFetcher and SparkLogClient will be made to use. It will take boolean flags to indicate which part of the data needs to be parsed to avoid parsing stuff the client dont need. When we do that the EventLogParser needs to read one event at a time, store some intermediate data and convert it into statusapiv1 structure. I am trying to avoid create a lot of intermediate data and field by field copy to statusapiv1 like for legacydataconverter does. Instead, I want to create the statusapiv1 Impl objects, fill and modify data as I parse and calculate them and then just return it asInstanceOf statusapiv1 trait. This PR is the first step towards that. It makes the SparkAppliationData contain only traits. So, readers( heuristics and metricsAggregator) will continue to get read only data. But writers can create the Impl objects and write to individual fields. The problem with have a class with only Val is that you have to create it only when all the fields are available. And that is difficult to do  when you are parsing event logs one line at a time.

Thanks @shankar37 for providing this detail.
I completely agree that using Spark replaybus and listeners is not a good idea. We are also facing the issue that some of the Spark listeners have changed from Spark 1.6 to 2.1, which makes Dr Elephant incompatible against Spark 2.1 enetlogs.
I strongly believe that we should completely eliminate the dependency on Spark, and therefore I like the motivation for this PR.
I just looked into SparkLogClient, and it has the logic to parse eventlog. However, it still depends on a couple of Spark classes, SparkListenerEnvironmentUpdate and SparkListenerEvent. Are you planning to remove those dependencies as well in the proposed eventlog parser?
Please let me know if I can help in this change.

I am planning to move that code into the new eventlogparser and expand on that. I will continue to rely on SparkListenerEvent and its derived classes as I didnt find any good way to remove that dependency. Do you have any ideas on how to not depend on that ?

I don't have any ideas either no how to remove these dependencies. Maybe we should think about it when you submit the PR. As of now, I think the goal should be to have the minimum dependency on Spark.

This change LGTM.
Thanks @shankar37

These traits are returned as part of HadoopApplicationData interface. If we
just use the classes with vars then the reader can potentially change the
values and wont be read only. So, to keep the interface clean, we need the
traits.
On Fri, May 19, 2017 at 3:56 AM, Shekhar Gupta<EMAIL_ADDRESS>wrote:

@shkhrgpt commented on this pull request.
In app/com/linkedin/drelephant/spark/fetchers/statusapiv1/
statusapiv1.scala
https://github.com/linkedin/dr-elephant/pull/248#discussion_r117368406:

val description: Option[String],

val submissionTime: Option[Date],
val completionTime: Option[Date],
val stageIds: Seq[Int],
val jobGroup: Option[String],
val status: JobExecutionStatus,
val numTasks: Int,
val numActiveTasks: Int,
val numCompletedTasks: Int,
val numSkippedTasks: Int,
val numFailedTasks: Int,
val numActiveStages: Int,
val numCompletedStages: Int,
val numSkippedStages: Int,
val numFailedStages: Int)
+trait ApplicationInfo {

@shankar37 https://github.com/shankar37
Why do we have these traits? Why can't we just have simple classes with
var arguments?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/linkedin/dr-elephant/pull/248#pullrequestreview-39072060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMlRI_lJAexf6SgqpdvlVkEE6F8fF-uZks5r7MWGgaJpZM4NbF6R
.

Shekhar,
I am planning to merge this so that the next PR is a clean diff of the
parsing changes alone. Let me know by EOD if you have any further comments.
thanks
shankar
On Mon, May 22, 2017 at 10:28 AM, Shankar M<EMAIL_ADDRESS>wrote:

These traits are returned as part of HadoopApplicationData interface. If
we just use the classes with vars then the reader can potentially change
the values and wont be read only. So, to keep the interface clean, we need
the traits.
On Fri, May 19, 2017 at 3:56 AM, Shekhar Gupta<EMAIL_ADDRESS>wrote:

@shkhrgpt commented on this pull request.
In app/com/linkedin/drelephant/spark/fetchers/statusapiv1/statu
sapiv1.scala
https://github.com/linkedin/dr-elephant/pull/248#discussion_r117368406:

val description: Option[String],

val submissionTime: Option[Date],
val completionTime: Option[Date],
val stageIds: Seq[Int],
val jobGroup: Option[String],
val status: JobExecutionStatus,
val numTasks: Int,
val numActiveTasks: Int,
val numCompletedTasks: Int,
val numSkippedTasks: Int,
val numFailedTasks: Int,
val numActiveStages: Int,
val numCompletedStages: Int,
val numSkippedStages: Int,
val numFailedStages: Int)
+trait ApplicationInfo {

@shankar37 https://github.com/shankar37
Why do we have these traits? Why can't we just have simple classes with
var arguments?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/linkedin/dr-elephant/pull/248#pullrequestreview-39072060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMlRI_lJAexf6SgqpdvlVkEE6F8fF-uZks5r7MWGgaJpZM4NbF6R
.

@shankar37 LGTM.
Please merge this change.
Thank you.


Finding updated intrinsic values when using On-Chip Calibration

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D400

Firmware Version
<IP_ADDRESS>

Operating System & Version
Linux (Ubuntu 18.04)

Kernel Version (Linux Only)
5.4.0

Platform
PC

SDK Version
2.45.0

Language
python

Issue Description
Hi there,
I've been utilizing the On-Chip calibration feature and its been working great. I keep getting good feedback from the health check (<.25). However I'm interested in exactly what fields are changed within the calibration table, but when I check the table within realsense viewer it doesn't seem to update. So I switched to the depth_auto_calibration_example.py script in the SDK. I'm still getting a good health check but the array outputted by the get_calibration_table() function still doesn't change between calibrations. Am I missing a change that affects the health check but isn't stored in the calibration table? Is there a simple way to find the updated intrinsic fields and their new values?
Thanks.

Hi @OiCata44  Once you have performed a calibration and are satisfied with the result, are you saving it to the calibration table stored inside the camera hardware, please?  In the Viewer's on-chip calibration, that would be done with the Apply Now option.

You can check the calibration information in the Viewer with the Calibration Data option of the 'More' menu.  Is this the method that you used to check the table in the Viewer?

My understanding is that the above table represents the calibration table values that are updated by an On-Chip depth calibration.
The SDK's Dynamic Calibration tool - an alternative to the On-Chip calibration method - provides a simlar list of calibration parameters in its documentation, with the addition of parameters for the rotation and translation of the RGB sensor (as the Dyamic Calibration tool can calibrate both depth and RGB sensors).

@MartyG-RealSense This was super helpful! Looks like the calibration changes were so small it wasn't appearing within the default three decimal places on the Realsense Viewer GUI. After comparing the differences in saved calibration tables through CLI all the pieces fit. I can easily see which Intrinsic values were updated now, thanks for your help!

Excellent news @OiCata44 that you were able to confirm that the intrinsics were changing after calibration.  Thanks very much for the update!

Hi @OiCata44  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


Metadata for downloaded data

Currently, we can download the data, but there is no accompanying information about how it was generated, the internal parameters used, or the meanings of the different columns. It would be helpful to have a separate file containing this metadata along with the data.

I used the following command and only .csv file is downloaded. There might be a bug.
spacebench nn binary 10 --output_path $PWD

@atrisovic can you look into this? if the metada is not downloaded the whole thing will crash.

@atrisovic, @mauriciogtec,  this issue has already been resolved. Correct?

Yes. Closing. :)