Regression: .NET editor build 4.2-beta2 is leaking resources at exit

Godot version
4.2-beta2_mono (official build downloaded from the website)
System information
Godot v4.2.beta2.mono - Arch Linux #1 SMP PREEMPT_DYNAMIC Wed, 13 Sep 2023 08:37:40 +0000 - X11 - Vulkan (Forward+) - dedicated AMD Radeon RX 6600 (amdgpu) - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)
Issue description
Upon exiting the editor, the following is printed to the console:
ERROR: Condition "!EditorSettings::get_singleton() || !EditorSettings::get_singleton()->has_setting(p_setting)" is true. Returning: Variant()
   at: _EDITOR_GET (editor/editor_settings.cpp:1140)
ERROR: 2 RID allocations of type 'N10RendererRD12LightStorage11ShadowAtlasE' were leaked at exit.
ERROR: 2 RID allocations of type 'N10RendererRD14TextureStorage12RenderTargetE' were leaked at exit.
ERROR: 7 RID allocations of type 'N10RendererRD14TextureStorage7TextureE' were leaked at exit.
ERROR: 14 RID allocations of type 'N18RendererCanvasCull4ItemE' were leaked at exit.
ERROR: 2 RID allocations of type 'N18RendererCanvasCull6CanvasE' were leaked at exit.
ERROR: 2 RID allocations of type 'N16RendererViewport8ViewportE' were leaked at exit.
WARNING: 14 RIDs of type "Texture" were leaked.
     at: finalize (drivers/vulkan/rendering_device_vulkan.cpp:9623)
ERROR: 14 RID allocations of type 'PN18TextServerAdvanced22ShapedTextDataAdvancedE' were leaked at exit.
ERROR: 1 RID allocations of type 'PN18TextServerAdvanced12FontAdvancedE' were leaked at exit.
WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
     at: cleanup (core/object/object.cpp:2207)

This doesn't happen in 4.2-beta2 without mono, and it doesn't happen in 4.1.2 stable with mono.
Running with --verbose doesn't provide much more useful info:
EditorSettings: Save OK!
Unloading: Disposing tracked instances...
ERROR: Condition "!EditorSettings::get_singleton() || !EditorSettings::get_singleton()->has_setting(p_setting)" is true. Returning: Variant()
   at: _EDITOR_GET (editor/editor_settings.cpp:1140)
Unloading: Finished disposing tracked instances.
XR: Clearing primary interface
XR: Removed interfaceNative mobile
XR: Removed interfaceOpenXR
PulseAudio: context terminated
ERROR: 2 RID allocations of type 'N10RendererRD12LightStorage11ShadowAtlasE' were leaked at exit.
ERROR: 2 RID allocations of type 'N10RendererRD14TextureStorage12RenderTargetE' were leaked at exit.
ERROR: 7 RID allocations of type 'N10RendererRD14TextureStorage7TextureE' were leaked at exit.
ERROR: 14 RID allocations of type 'N18RendererCanvasCull4ItemE' were leaked at exit.
ERROR: 2 RID allocations of type 'N18RendererCanvasCull6CanvasE' were leaked at exit.
ERROR: 2 RID allocations of type 'N16RendererViewport8ViewportE' were leaked at exit.
WARNING: 14 RIDs of type "Texture" were leaked.
     at: finalize (drivers/vulkan/rendering_device_vulkan.cpp:9623)
ERROR: 14 RID allocations of type 'PN18TextServerAdvanced22ShapedTextDataAdvancedE' were leaked at exit.
ERROR: 1 RID allocations of type 'PN18TextServerAdvanced12FontAdvancedE' were leaked at exit.
WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
     at: cleanup (core/object/object.cpp:2207)
Leaked instance: ImageTexture:-9222664501122301707 - Resource path:
Leaked instance: ImageTexture:-9222662851854860006 - Resource path:
Leaked instance: ImageTexture:-9222654605517651640 - Resource path:
Leaked instance: StyleBoxFlat:-9222557848494407328 - Resource path:
Leaked instance: FontFile:-9222680444040904284 - Resource path:
Leaked instance: StyleBoxFlat:-9222557298738592657 - Resource path:
Leaked instance: StyleBoxFlat:-9222556748982778768 - Resource path:
Leaked instance: StyleBoxFlat:-9222556199226964879 - Resource path:
Leaked instance: StyleBoxFlat:-9222555649471150990 - Resource path:
Leaked instance: StyleBoxFlat:-9222555099715337101 - Resource path:
Leaked instance: StyleBoxEmpty:-9222547952889756544 - Resource path:
Leaked instance: StyleBoxFlat:-9222539156796734320 - Resource path:
Leaked instance: StyleBoxFlat:-9222538607040920431 - Resource path:
Leaked instance: StyleBoxFlat:-9222538057285106542 - Resource path:
Leaked instance: StyleBoxFlat:-9222514417785109315 - Resource path:
Leaked instance: AcceptDialog:36904558030544093 - Node name:
Leaked instance: World2D:-9186466929068417826 - Resource path:
Leaked instance: ViewportTexture:-9186465279800976161 - Resource path:
Leaked instance: Object:36907306809613536
Leaked instance: Panel:36907856565427425 - Node name: @Panel@17151
Leaked instance: Object:36908406321241314
Leaked instance: HBoxContainer:36908956077055203 - Node name: @HBoxContainer@17153
Leaked instance: Object:36909505832869092
Leaked instance: Label:36910055588682981 - Node name: @Label@17152
Leaked instance: Object:36910605344496870
Leaked instance: Control:36911155100310759 - Node name: @Control@17154
Leaked instance: Object:36911704856124648
Leaked instance: Button:36912254611938537 - Node name: @Button@17155
Leaked instance: Object:36912804367752426
Leaked instance: TextParagraph:-9186458682731209493
Leaked instance: Control:36913903879380204 - Node name: @Control@17156
Leaked instance: Object:36914453635194093
Leaked instance: ConfirmationDialog:36915003391007982 - Node name:
Leaked instance: World2D:-9186456483707953937 - Resource path:
Leaked instance: ViewportTexture:-9186454834440512272 - Resource path:
Leaked instance: Object:36917752170077425
Leaked instance: Panel:36918301925891314 - Node name: @Panel@17157
Leaked instance: Object:36918851681705203
Leaked instance: HBoxContainer:36919401437519092 - Node name: @HBoxContainer@17159
Leaked instance: Object:36919951193332981
Leaked instance: Label:36920500949146870 - Node name: @Label@17158
Leaked instance: Object:36921050704960759
Leaked instance: Control:36921600460774648 - Node name: @Control@17160
Leaked instance: Object:36922150216588537
Leaked instance: Button:36922699972402426 - Node name: @Button@17161
Leaked instance: Object:36923249728216315
Leaked instance: TextParagraph:-9186448237370745604
Leaked instance: Control:36924349239844093 - Node name: @Control@17162
Leaked instance: Object:36924898995657982
Leaked instance: Button:36925448751471871 - Node name: @Button@17163
Leaked instance: Object:36925998507285760
Leaked instance: TextParagraph:-9186445488591676159
Leaked instance: Control:36927098018913538 - Node name: @Control@17164
Leaked instance: Object:36927647774727427
Leaked instance: TextLine:-9174431125034966658
Leaked instance: TextLine:-9174431674790780545
Leaked instance: TextLine:-9174430575279152768
Leaked instance: TextLine:-9174430025523338879
Hint: Leaked instances typically happen when nodes are removed from the scene tree (with `remove_child()`) but not freed (with `free()` or `queue_free()`).
Orphan StringName: ... [lots of these]
StringName: 117 unclaimed string names at exit.

Steps to reproduce
Open an empty project in the editor. Using the Forward+ renderer, not sure if it matters. Then exit the editor.
Minimal reproduction project
Simply running mkdir repro && cd repro && touch project.godot is enough.

Possible duplicate of #83247

I don't think it's a dupe. This one consistently happens, not only sometimes; it happens in the editor, rather than the running game; and it didn't happen in 4.1.2; and the types of leaked resources are different.

It seems to be a regression from https://github.com/godotengine/godot/pull/82683. I unparented the dialogs and now they are not freed with the scene when exiting the editor.

I opened https://github.com/godotengine/godot/pull/83809 to fix it.


rsz: Enable pin swapping 3+ input standard cells

Waiting on https://github.com/The-OpenROAD-Project/OpenROAD/pull/4673 to be merged.

If you want to see what's required check out https://github.com/The-OpenROAD-Project/OpenROAD/pull/4681/commits/fdc3ef7d534eb028bdb0c5d0b0c75a7cfbe32eb8

@maliberty any way to look at this change through the fancy graph thing?

What is "the fancy graph thing"?  I'm hoping to land your dependent PR tomorrow (secure CI is running tonight).

The website with the PPA graphs you guys have shown me before

The website with the PPA graphs you guys have shown me before

https://dashboard.theopenroadproject.org/

secure CI started


raise error on duplicate ports passed to patch

Issue
the service patch silently fails if you pass duplicate ports to it, say
                ports=[
                    ServicePort(name="svc1", port=1234, protocol="TCP"),
                    ServicePort(name="svc2", port=1234, protocol="TCP"),
                ],

Solution
catch that and raise an exception as that's user error
Context
this would have saved me a couple of hours of debugging this week

Since we're moving to using the ops facility for this, the change is no longer needed. We should instead look to deprecate this library.


[HELP] Coordinates of Checkpoints

Where the coordinates of checkpoints are stored?
Looking could not find.

Theme closed, I found.


Give names to anonymous structs (VS2013 fix)

Give names to anonymous structs because VS2013 does not support in-class initializers of sub-structs (it silently ignored them without error or warning!)
	struct Options
	{
		int version = 450;
		struct
		{
			bool flip_vert_y = false;
		} vertex;
	};
	Options opts;
	printf("version: %d\n", opts.version);
	printf("flip_vert_y: %d\n", opts.vertex.flip_vert_y);

The code above prints
version: 450
flip_vert_y: 204

in VS2013 debug builds, adding a name to the inner struct fixes it.

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


Move from using openapi-gen

Upstream kube has dropped openapi-gen from 1.30.
We should look into using something else. It should no longer be needed.

We are using the following code:
	$(PROJECT_DIR)/bin/openapi-gen --go-header-file hack/boilerplate.go.txt -i sigs.k8s.io/jobset/api/jobset/v1alpha2 -p sigs.k8s.io/jobset/api/jobset/v1alpha2 --alsologtostderr
	if [ $(GOPATH)/src/sigs.k8s.io/jobset/api/jobset/v1alpha2/openapi_generated.go != $(PROJECT_DIR)/api/jobset/v1alpha2/openapi_generated.go ]; then \
		mv $(GOPATH)/src/sigs.k8s.io/jobset/api/jobset/v1alpha2/openapi_generated.go $(PROJECT_DIR)/api/jobset/v1alpha2/openapi_generated.go; \
	fi

We should be able to swap k8s.io/code-generator/openapi-gen for k8s.io/kube-openapi/openapi-gen.
Going to investigate this.


Rate Limit By Applying Backpressure and Buffering

Some consumers have a limited ability to handle incoming requests. For example 20 request/second. We would like to be able to protect these consumers from traffic spikes, thus, rate limiting DQD and applying backpressure.
We would like to have the ability to control how many requests are consumed and processed per time unit, while buffering the events.
This use case is intended to handle traffic spikes only.
If the producer is producing a higher rate of events regularly (for example 40requests/second), the buffer will never finish. Using this feature requires monitoring on the source.
Points to consider: multiple DQD instances that need to share the load, persisting the state (handling restarts and such).

A concrete use case is: events coming in batches via queue and we want to pipe them to an http endpoint which is rate limited. So we want to consume messages from the queue at a specified rate (e.g. 20 per second).

There's a support for fixed rate:
https://github.com/livecycle/livecycle/pull/552/files#diff-aeb443fba691a4915192e3ca86eb3b82b489c99dff60bd84eee8a1726cd94abb
It limits the amount of concurrency for maximum amount of processing units. (for example, only one processing unit).
Of course, it won't solve the problem if even a single processing unit is too fast.
In that case, it can be slowed by better error back off policy (which can be error based, like for 503), or alternatively, set minimum time to processing job (which is similar to rps per processing unit)

Another way to implement it, is creating input/output source that does rate-limiting and create a more complex pipe, but scaling processing unit can be a bit tricky

I updated the proposed solution  to  fixed rate consumption.


Update 4153

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.
Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

❌ The recipe is not parsable by any of the known recipe parsers (['conda-forge-tick (the bot)', 'conda-recipe-manager', 'conda-souschef (grayskull)']). Please check the logs for more information and ensure your recipe can be parsed.

For recipe/meta.yaml:

ℹ The recipe is not parsable by parser conda-forge-tick (the bot). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.
ℹ The recipe is not parsable by parser conda-souschef (grayskull). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.
ℹ The recipe is not parsable by parser conda-recipe-manager. Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11973541275. Examine the logs at this URL for more detail.

Issues left are:

Windows + CUDA. Running out a memory (help needed)
ARM + CUDA + Linux. nvcc getting stuck on neon header that needs intrinsics. Upstream PR: https://github.com/ggerganov/ggml/pull/1028

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender


Missing properties/fields

I really like to write a code generator with this library but your parser does not read the fields yet with it :/ With your package it would be possible to use php only to work with plantuml files. I watch this repo and maybe I can switch from xmi to this package :)

@JoshuaBehrens
I'm glad you like it! We are thinking of supporting properties and fields as well.
I'll let you know via this issue when it's ready.

@JoshuaBehrens
Parsing of properties is now supported.

https://github.com/tasuku43/puml-parser-php/pull/7

However, we have not yet been able to support the type information specified for properties.
I plan to support the above in the future:)

Woop woop :) thank you very much. I will try it right away. Previously I was writing code based upon xmi but this was really missing with me as this is still experimental in plantuml. I can share later how I work with your library


Some Video are not playing

Player shows video preview but when i click on play it says This video is unavailable
Specifically i am trying to show video with ID "Bw0tjdBgKBY".

@gilesvangruisen , @owenworley  , @thomasvalera , @1nput0utput ,
@krzd , @ymkjp  , @NSMyself PLEASE LOOK INTO THE ISSUE

“PLEASE LOOK INTO THE ISSUE”
Why don’t you look into it and open a PR? This is open source, leave your self entitlement at the door please.
Also before randomly tagging everyone that has touched this repo why don’t you look at when it was last updated? (Years ago).
This is really not the way to ask for help.

@owenworley , I admit that my way of asking help is wrong, and i am apologizing for that. I promise that wouldn't happen again.
My intentions were not wrong, i just want to inform all contributors. So that we get the solution as quick as possible.
And i will surely do my best and try to solve this issue.
And thanks for letting me know my mistake.

Where you able to solve this?

Hi, i've got exactly the same problem, I checked and status.embeddable is true.
Video is https://www.youtube.com/watch?v=nZ-ieJUckOg
It's looks there is a decoding error.

Hi, Any one find the solutions for this issues, It's been years still the issue is open. If anyone find the solution please help us here.

Hi anyone found any solutions for this problem?

There is a property baseURL, set it like this:
youTubePlayerView.baseURL = "https://www.youtube.com"

Nice anwser. I have set this config and amazing --> video run well.

Hi there,
This pr contains the fix. Please review it.

Hi there,
This pr contains the fix. Please review it.

Up, please review the fix


cr-config: calculating the hash-id if needed

Hi,
When adding a server via the old traffic ops, the xmpp_id field is saved to be the host_name.
This field is used later on as an hashId, as part of cr-config,
However, when using the API (and therefore portal v2) this field is not created, causing the hashId to be empty and interfere with content affinity.
The suggested change comes to fix the issues for existing caches:

Caches added by the old UI: no change in hashId
Caches  added by the portal: hashId is calculated in the same way as by the old OPs, but now during the cr-config creation

I believe that as this is a "calculated" field and not provided by the user, the approach of calculating it each time is better then fixing it in the DB, as it allows future changes in the algorithem.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/991/
Test PASSed.

@elsloo - whatcha think?

Looks good to me.

As far as I tested, empty string is "false".
Nir
On Feb 8, 2018 7:40 PM, "Jeremy Mitchell"<EMAIL_ADDRESS>wrote:

@mitchell852 commented on this pull request.
In traffic_ops/app/lib/UI/Topology.pm
https://github.com/apache/incubator-trafficcontrol/pull/1859#discussion_r167013045
:

@@ -264,7 +264,7 @@ sub gen_crconfig_json {
$data_obj->{'contentServers'}->{ $row->host_name }->{'ip6'}           = ( $row->ip6_address || "" );
$data_obj->{'contentServers'}->{ $row->host_name }->{'profile'}       = $row->profile->name;
$data_obj->{'contentServers'}->{ $row->host_name }->{'type'}          = $row->type->name;

       $data_obj->{'contentServers'}->{ $row->host_name }->{'hashId'}        = $row->xmpp_id;

       $data_obj->{'contentServers'}->{ $row->host_name }->{'hashId'}        = $row->xmpp_id ? $row->xmpp_id : $row->host_name;

would this allow an xmpp_id = "" which would probably not be a good thing.
do we need a better test like isDefined and neq empty string?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-trafficcontrol/pull/1859#pullrequestreview-95167041,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXGkYGJv9rq3-f5LYh8robfST7KruxYBks5tSzGVgaJpZM4R9evn
.


Moved model out of herb_description

Now the tests can be run without having herb_description installed. The urdf file for testing is stored in or_urdf/test_data/robots. It's okay to have the urdfs with the package right? Or should the data be elsewhere?

The bh280 model still references a lot of meshes from herb_description. I think it would be best to remove this geometry entirely so OpenRAVE doesn't try to load it (and, presumably, fail).

Updated. Does not depend on herbpy and does not give URDF parsing errors any more.


problem with create_target_space_from_image() function

Hi,
Thank you so much for developing this useful package. I am keen to apply it to our single cell data. I would like to use a circle instead of the default square grid as a target tissue space so I have followed your advice to create a png image of a black circle on white background and used the create_target_space_from_image() function to read it. However I get the following error:

File "/usr/local/lib/python3.6/site-packages/novosparc/geometry/_geometry.py", line 42, in create_target_space_from_image
locations = np.array([(x, y) for x in range(img_width) for y in range(img_height)
File "/usr/local/lib/python3.6/site-packages/novosparc/geometry/_geometry.py", line 43, in
if sum(img[y, x, :] == np.array([0, 0, 0]))])
TypeError: 'bool' object is not iterable
I have also attached the image file I used. Would you be able to help look into it to see what may be wrong please?
Many thanks,
Tram

Hi Tram,
I cannot reproduce this, your image reads fine when I read it with the function.
Could you check with the following environment:
novosparc v.0.3.9
numpy v.1.16.1
matplotlib v.2.2.2

Thank you for getting back to me. I found out that the error I got was due to using a different image file to the one I attached here in which the black circle touches the border of the image (ie. the black circle was not entirely surrounded with white background). A silly mistake on my part.
I have another question I hope you can help with. How can I specify the number of locations to be equals to the number of single cells I have ?

Typically the target space you create will have many more locations than cells (actually depends on your image size). You can therefore randomly downsample the number of locations to any number you like. See also the tutorial I just pushed in the repo.

Hi,
Sorry to interrupt a closed thread. I had the same error and could not solve by myself.
Here is the image (a sketch of lymph node) I used for function nc.geometry.create_target_space_from_image().

And the package versions

novosparc v0.3.10
numpy v1.16.1
matplotlib v2.2.2

Could you please help to check this?
Many thanks!

Hi,
Sorry to interrupt a closed thread. I had the same error and could not solve by myself.
Here is the image (a sketch of lymph node) I used for function nc.geometry.create_target_space_from_image().

And the package versions

novosparc v0.3.10
numpy v1.16.1
matplotlib v2.2.2

Could you please help to check this?
Many thanks!

Hi
I also meet the same problem, I cant't solve it by myself.
Did you have solved this problem?
Many thanks！


NoMethodError: undefined method `maxmind' for #Geocoder::ConfigurationHash:0x000000059fefc0

View details in Rollbar: https://rollbar.com/trystant/BOW/items/716/

NoMethodError: undefined method `maxmind' for #<Geocoder::ConfigurationHash:0x000000059fefc0>
  File<EMAIL_ADDRESS>line 8, in method_missing
  File<EMAIL_ADDRESS>line 75, in service_name
  File<EMAIL_ADDRESS>line 79, in field_names
  File<EMAIL_ADDRESS>line 128, in respond_to?
  File<EMAIL_ADDRESS>line 63, in try
  File<EMAIL_ADDRESS>line 9, in country
  File<EMAIL_ADDRESS>line 15, in country
  File<EMAIL_ADDRESS>line 23, in []
  File<EMAIL_ADDRESS>line 70, in block in set_visit_properties
  File<EMAIL_ADDRESS>line 69, in each
  File<EMAIL_ADDRESS>line 69, in set_visit_properties
  File<EMAIL_ADDRESS>line 13, in track_visit
  File<EMAIL_ADDRESS>line 43, in track_visit
  File<EMAIL_ADDRESS>line 4, in create
  File<EMAIL_ADDRESS>line 4, in send_action
  File<EMAIL_ADDRESS>line 198, in process_action
  File<EMAIL_ADDRESS>line 10, in process_action
  File<EMAIL_ADDRESS>line 20, in block in process_action
  File<EMAIL_ADDRESS>line 117, in call
  File<EMAIL_ADDRESS>line 555, in block (2 levels) in compile
  File<EMAIL_ADDRESS>line 505, in call
  File<EMAIL_ADDRESS>line 92, in __run_callbacks__
  File<EMAIL_ADDRESS>line 778, in _run_process_action_callbacks
  File<EMAIL_ADDRESS>line 81, in run_callbacks
  File<EMAIL_ADDRESS>line 19, in process_action
  File<EMAIL_ADDRESS>line 29, in process_action
  File<EMAIL_ADDRESS>line 32, in block in process_action
  File<EMAIL_ADDRESS>line 164, in block in instrument
  File<EMAIL_ADDRESS>line 20, in instrument
  File<EMAIL_ADDRESS>line 164, in instrument
  File<EMAIL_ADDRESS>line 30, in process_action
  File<EMAIL_ADDRESS>line 250, in process_action
  File<EMAIL_ADDRESS>line 153, in process_action
  File<EMAIL_ADDRESS>line 18, in process_action
  File<EMAIL_ADDRESS>line 137, in process
  File<EMAIL_ADDRESS>line 30, in process
  File<EMAIL_ADDRESS>line 196, in dispatch
  File<EMAIL_ADDRESS>line 13, in dispatch
  File<EMAIL_ADDRESS>line 237, in block in action
  File<EMAIL_ADDRESS>line 74, in dispatch
  File<EMAIL_ADDRESS>line 43, in serve
  File<EMAIL_ADDRESS>line 43, in block in serve
  File<EMAIL_ADDRESS>line 30, in each
  File<EMAIL_ADDRESS>line 30, in serve
  File<EMAIL_ADDRESS>line 817, in call
  File<EMAIL_ADDRESS>line 518, in call
  File<EMAIL_ADDRESS>line 194, in public_send
  File<EMAIL_ADDRESS>line 194, in method_missing
  File<EMAIL_ADDRESS>line 51, in serve
  File<EMAIL_ADDRESS>line 43,

Dev error; can close.


Add SteelSeries Arctis 1 Wireless Support

I have the Steelseries Arctis 1 (Xbox Edition) and I would like to get a support from this app.
Here is the information the developer needs:

Ive added this device into the latest release :) https://github.com/craigster1991/arctis-battery-win-app/releases/tag/v0.2.1


LDO PEX simulations and process_extracted.py edits

This PR includes PEX simulations for the LDO while keeping prePEX simulations. The default run is PEX simulations. Let me know if there are any issues.
Additionally I made edits to the process_extracted.py to improve on the code changes the @lulu9312 made. In the future, try to use the script just by the described interface (described in the comments) and if we need more functionality we should add as generically as possible. For example, (after this PR) depending on which configuration variables you unset (set=None) process_extracted_pins.py will ignore certain functions.

Right now this PR looks good to me. This PR have some changes made to simulations.py and also the spice template file. I working on my PR so I need to make the changes to the file  accordingly.

A question - is ldo-gen has only two parameters - vin and imax?

@saicharan0112 yes, currently the LDO has two specifications. On your second comment: Ok this is good idea will keep in mind for the future.
@lulu9312 if you are working on integrating the automation scripts you wrote, you can see at the bottom of ldo-gen.py how I made a list variable called "filestocopy". Append to that list any files you want to add (follow the directions in the comments ldo-gen.py). You append a tuple (wheretocopy, filename, stringdata).

@alibillalhammoud good. So can't we give those two as arguments to the ldo python script itself? Just like how ninv and nhead are given to tempsense?

@saicharan0112 Yes I like this idea much more than editing a JSON file. We should also add the module name as an argument and then we can completely discard the JSON file. Does anyone have a specific reason why we should keep the JSON spec file vs directly passing args?

@alibillalhammoud I think we can shift to python script instead of JSON file. If this is already done in temp-sense-gen we should follow the same structure here as well.

I like the idea of adding the specifications of the DLDO as an argument in the python script and module name.


Why is iter used here during training iterations instead of directly using the dataloader?

https://github.com/gmberton/CosPlace/blob/cea7de243abe1a59c69f1087b1b8001d01262c59/train.py#L114

 dataloader = commons.InfiniteDataLoader(groups[current_group_num], num_workers=args.num_workers,
                                            batch_size=args.batch_size, shuffle=True,
                                            pin_memory=(args.device == "cuda"), drop_last=True)

    dataloader_iterator = iter(dataloader)
    model = model.train()

    epoch_losses = np.zeros((0, 1), dtype=np.float32)
    for iteration in tqdm(range(args.iterations_per_epoch), ncols=100):
           images, targets, _ = next(dataloader_iterator)

Why not do it directly like this?

dataloader = commons.InfiniteDataLoader(groups[current_group_num], num_workers=args.num_workers,
                                            batch_size=args.batch_size, shuffle=True,
                                            pin_memory=(args.device == "cuda"), drop_last=True)

       model = model.train()

    epoch_losses = np.zeros((0, 1), dtype=np.float32)
    for images, targets, _ in tqdm(dataloader, ncols=100):

https://github.com/gmberton/CosPlace/blob/804fc8c65871cab81f8efbc2c0cff04f1ab78534/train.py#L106
Why not use torch.utils.data.dataloader directly?

It is also okay to use the standard DataLoader class, but using an InfiniteDataLoader ensures that if there are not enough samples the __iter__ will not raise a StopIteration. This could happen when changing the parameters within the code (e.g. using higher values for parameters --iterations_per_epoch, --batch_size, --L, --N might lead to this issue when using a standard DataLoader)

dataloader_iterator = iter(dataloader)
for iteration in tqdm(range(args.iterations_per_epoch), ncols=100):
       images, targets, _ = next(dataloader_iterator)

What you mean is that with this approach, you can train on a portion of the data in each epoch without having to train on all the data, and only need to go through args.iterations_per_epoch iterations?
https://github.com/gmberton/CosPlace/blob/543eaa5995c64d7e2ddbe2d8a1587ec4b2964728/train.py#L106
dataloader = commons.InfiniteDataLoader(groups[current_group_num], num_workers=args.num_workers,
                                            batch_size=args.batch_size, shuffle=True,
                                            pin_memory=(args.device == "cuda"), drop_last=True)

    dataloader_iterator = iter(dataloader)

When I use the small dataset, it has only one group containing 5,965 classes. If args.batch_size is set to 8, there will be 745 BatchSamplers in the dataloader, meaning the dataloader can iterate 745 times to train on all the data. The statement "images, targets, _ = next(dataloader_iterator)" can only iterate 745 times as well. However, in the training loop, args.iterations_per_epoch is set to 10,000, indicating 10,000 iterations are expected, but in reality, only 745 iterations are possible because the statement "images, targets, _ = next(dataloader_iterator)" cannot iterate further after 745 iterations. If this is the case, your intention to train on only a portion of data in each epoch may not be achieved.

class InfiniteDataLoader(torch.utils.data.DataLoader):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.dataset_iterator = super().__iter__()

    def __iter__(self):
        return self

    def __next__(self):
        try:
            batch = next(self.dataset_iterator)
        except StopIteration:
            self.dataset_iterator = super().__iter__()
            batch = next(self.dataset_iterator)
        return batch

using an InfiniteDataLoader ensures that if there are not enough samples the iter will not raise a StopIteration.
When all samples are used up, the __iter__ will start iterating from the first batch again. Is that correct?
When args.iterations_per_epoch=10,000 and the DataLoader has 800 BatchSamplers, after completing the iteration of the 800th batch, the statement "images, targets, _ = next(dataloader_iterator)" in the for loop will start iterating from the first batch again. In this case, a single for training loop will train on the data multiple times, and eventually, one epoch will complete 10,000 iterations of training.
When args.iterations_per_epoch=10,000 and the DataLoader has 20,000 BatchSamplers, in this case, a single for training loop will only perform 10,000 iterations of training, training only a portion of the data.
This ensures that regardless of whether the number of BatchSamplers is greater than args.iterations_per_epoch, the for training loop in one epoch will always iterate args.iterations_per_epoch times.
Right？

Based on this setup, training on 8 groups of the processed dataset can lead to CosPlace achieving state-of-the-art performance?

All your assumptions are correct, and the answer to all your questions is yes.

Think you  for your help


WFLY-4493 UrlScanner does not close ZipFiles

The UrlScanner class creates ZipFile instances without invoking #close
on them. This is not as bad as it sounds because ZipFile does have a
finalizer but it's still suboptimal.
I did use Java 7 try-with-resources. Let me know if this is an issue.
Issue: WFLY-4493
https://issues.jboss.org/browse/WFLY-4493

Linux with security manager Build 1171 is now running using a merge of c40ba04f7b1a0a255f03fb6e3a43ed8f1be64f46

Windows Build 1307 is now running using a merge of c40ba04f7b1a0a255f03fb6e3a43ed8f1be64f46

Linux Build 6195 is now running using a merge of c40ba04f7b1a0a255f03fb6e3a43ed8f1be64f46

Linux with security manager Build 1171 outcome was SUCCESS using a merge of c40ba04f7b1a0a255f03fb6e3a43ed8f1be64f46
Summary: Tests passed: 819, ignored: 356 Build time: 0:06:29

Windows Build 1307 outcome was SUCCESS using a merge of c40ba04f7b1a0a255f03fb6e3a43ed8f1be64f46
Summary: Tests passed: 2838, ignored: 416 Build time: 0:50:27

Linux Build 6195 outcome was SUCCESS using a merge of c40ba04f7b1a0a255f03fb6e3a43ed8f1be64f46
Summary: Tests passed: 2837, ignored: 416, muted: 1 Build time: 0:51:55


subscribers: Remove fetching subscribers from server.

Now that we have awesome new hotkeys for navigating the streams overlay (see #4255), we should fix the fact that we do a fairly large unnecessary data fetch (to get the subscribers data) every time you navigate to a new subscription row.
I believe we actually have all the data necessary to rewrite show_subscription_settings to just not do that fetch at all, and instead just render off of sub.subscribers.

@zulipbot claim


handle response with a code of error as HTTPError instance

In some cases, some response error comes without HTTPError instance like https://github.com/pump-io/pump.io/blob/master/routes/web.js#L247 and web client shows: [Object Object].
So this PR extends the error handler to convert the generic error response to HTTPError instance.
Before change:

After change:

Coverage decreased (-0.08%) to 73.906% when pulling 9e07947e0388928a36e11857dc96aae434b86bdf on vxcamiloxv:fix-handle-response-error into 3637b31c7b3159d9c5e8c02448ad87363eae9eab on pump-io:master.

@strugee I don't sure if exist a unit test for the remote request in web ui, if you accept this change tell me and will add the unit test.


flutter_tts-3.8.5/lib/flutter_tts_web.dart:3:8: Error: Dart library 'dart:js' is not available on this platform.

/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:3:8: Error: Dart library 'dart:js' is not available on this platform.
import 'dart:js' as js;
^
Context: The unavailable library 'dart:js' is imported through these packages:
package:myapp=> package:flutter_tts => dart:js

Detailed import paths for (some of) the these imports:
package:the_easy_way_to_speak_irish/main.dart => package:myapp/view/home_page.dart => package:myapp/view/home.dart => package:myapp/components/book_card.dart => package:myapp/view/book_search_screen.dart => package:myapp/view/book_phrase_card.dart => package:flutter_tts/flutter_tts_web.dart => dart:js

/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:34:8: Error: Type 'js.JsObject' not found.
late js.JsObject synth;
^^^^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:35:8: Error: Type 'js.JsObject' not found.
late js.JsObject utterance;
^^^^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:34:11: Error: 'JsObject' isn't a type.
late js.JsObject synth;
^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:35:11: Error: 'JsObject' isn't a type.
late js.JsObject utterance;
^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:44:14: Error: Undefined name 'context'.
js.context["SpeechSynthesisUtterance"] as js.JsFunction, [""]);
^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:44:56: Error: 'JsFunction' isn't a type.
js.context["SpeechSynthesisUtterance"] as js.JsFunction, [""]);
^^^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:43:26: Error: Couldn't find constructor 'JsObject'.
utterance = new js.JsObject(
^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:46:14: Error: Undefined name 'context'.
js.context["speechSynthesis"] as js.JsObject);
^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:46:47: Error: 'JsObject' isn't a type.
js.context["speechSynthesis"] as js.JsObject);
^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:45:22: Error: Couldn't find constructor 'JsObject'.
synth = new js.JsObject.fromBrowserObject(
^^^^^^^^
/C:/Users/pc/AppData/Local/Pub/Cache/hosted/pub.dev/flutter_tts-3.8.5/lib/flutter_tts_web.dart:96:26: Error: Couldn't find constructor 'JsObject'.
var event = new js.JsObject.fromBrowserObject(e);
  [√] Flutter (Channel stable, 3.16.2, on Microsoft Windows [Version 10.0.19045.3693], locale en-US)
• Flutter version 3.16.2 on channel stable at E:\Software\flutter_windows_v1.12.13+hotfix.7-stable\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 9e1c857886 (4 days ago), 2023-11-30 11:51:18 -0600
• Engine revision cf7a9d0800
• Dart version 3.2.2
• DevTools version 2.28.3

  Hello Guys,
  I'm having issues with our package.
  Please help me with this.
  Thanks in advance.

How do you create these errors? Which command do you run to compile the program?
If your code is importing package:flutter_tts/flutter_tts_web.dart, then it can only be compiled with a compiler targeting the web (dart compile web ...).

Just don't import package:flutter_tts_web use package:flutter_tts instead

Did you get the solution? Facing same issue!


Update to Node.js v14 runtime for v1 of this Action

See #111 for background and context

Closing this as Node.js v14 is not a valid runtime for GitHub Actions. This was discovered in #139 through the end-to-end tests, which throw the following exception with runs.using: "node14":

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter ''using: node14' is not supported, use 'docker', 'node12' or 'node16' instead.')


ME AI Sentiment Analysis CSharp

Executed build pipeline:
https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/6766481308

Execute builld pipeline:
https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/6979064312


docs: Update spaces-sdks-docker-tabby.md

Remove center tag as they're not properly rendered in huggingface docs

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Pyright needs to be added to 'dev-install' make instruction.

Unsure how one would go about this, but the NPM package pyright needs to be added to the dev-install Makefile instruction. Simply doing npm install -g pyright will not suffice as Mac and Linux users require sudo, and it would be unknown whether or not the user has npm installed to begin with.
My best guess is documenting this is the best way around this. Opening issue as a form of discussion.

actually pyrights is only needed for CI in our case:
https://github.com/aliev/aioauth/blob/master/.github/workflows/python-package.yml#L38
If you are using vscode, it will already be installed after installing the official Python extension from Microsoft. so no need to run make lint from command line.
We can also think about removing pyright from make lint and add it only to CI.
Documenting is also good idea, i think for type checking locally someone might prefer mypy.

actually pyrights is only needed for CI in our case:
https://github.com/aliev/aioauth/blob/master/.github/workflows/python-package.yml#L38

Roger that.

If you are using vscode, it will already be installed after installing the official Python extension from Microsoft. so no need to run make lint from command line.

I have it installed, but it was causing some unwarranted issues on my Mac due to it not being globally installed. Was just documenting the case on Issues so I didn't forget.

We can also think about removing pyright from make lint and add it only to CI.

That's a design choice that is up to you. :)

Documenting is also good idea, i think for type checking locally someone might prefer mypy.

For sure- I'll be sure to add it on #21 under Contributing.

@synchronizing I'm closing this issue since I migrated project to mypy :)


Specify list of required metadata for the viewer to function correctly

For OHIF Version 3
When loading instances via the dicomjson method, all metadata must be prepared in advance and fed to the viewer by means of a URL to a JSON file.
Please make clear what are the minimum / recommended scopes of required metadata for each modality.
For example, by trial and error only,  these observations were made:

When displaying color doppler ultrasound instances, 'PlanarConfiguration' must be specified in the metadata, while other metadata fields which are relevant for other modalities, such as 'WindowCenter' and 'WindowWidth' must be removed in order to achieve a correct display (even if those redundant tags are empty).

Adding the 'NumberOfFrames' tag to the metadata breaks the display of multiframe ultrasound images (only the first frame is displayed).

Frames are zero-indexed (to get frame 1 need to pass &frame=0)

#1500 listed metadata for version 2, but was not updated for version 3. It would be beneficial to post the minimum set of fields required for the most common types of modalities (CT/US/PT/DX) and instance types (for example single frame vs. multi frame).
Thanks you for this amazing project.

I think that is reasonable ask. We will do it

Seems like these are necessary, but I will investigate which feature requires which metadata
PatientID,
PatientName,
PatientSex,
PatientAge,
PatientBirthDate,
PatientSize,
PatientWeight,
StudyInstanceUID,
SeriesInstanceUID,
SOPInstanceUID,
SOPClassUID,
Modality,
NumberOfFrames,
Rows,
Columns,
SamplesPerPixel,
PhotometricInterpretation,
PlanarConfiguration,
BitsAllocated,
BitsStored,
HighBit,
PixelRepresentation,
PixelAspectRatio,
InstanceNumber,
SeriesDate,
SeriesTime,
FrameTime,
ImagePositionPatient,
ImageOrientationPatient,
ImageType,
PixelSpacing,
StudyDescription,
SeriesNumber,
SeriesDescription,

Hi @sedghi , I've added all those DICOM Tags that you've suggested, but it still doesn't seem to work. When I open the study, it is unable to open any PTs but it can load everything else. Do you know which tags I may be missing?

Oh interesting, so for PT, it should be able to show you something but if you you want scaled PT to generate PT SUV then you need these I assume
extensions/default/src/getPTImageIdInstanceMetadata.ts

Let me clarify some more my issue:
I'm using Orthanc's DicomWeb in conjunction with the OHIF viewer. Everything functions correctly when Orthanc is set to use Full Dicom Tags.
In order to optimize loading speeds, I've configured Orthanc to use only MainDicomTags, but the behavior makes it seem like some tags are still missing.
With MainDicomTags and ExtraMainDicomTags (that include your list above), when I access the study list and open a study, I'm unable to see any PT-related series, and only CT or other series. They don't appear in the Series Panel on the left, nor is it available in the hanging protocol / viewing area.

First, how do you configure Orthanc to only send main tags?
I want to spend time in fixing this issue and documenting it once and for all.
Can you maybe create reproducible steps to the issue for me?
Should I run the orthanc in docker?

We just release the OHIF 3.8, you can find more details here https://ohif.org/release-notes/3p8/
If you still encounter this issue in 3.8, please re-open this.


Accidental clicks when scrolling

With momentum based scrolling, the user will often stop scrolling by "grabbing" the page to hold it in place and read something. However, in Ionic, their "grab" is counted as a "click". In a scrollview with lots of links (e.g. a Twitter feed), this causes lots of unintentional clicks. Most native apps (Twitter, Facebook, etc) ignore any clicks while the page is moving. Ionic should do the same.
If there is a way disable these clicks manually (e.g. by checking if the scrollview is moving, then ignoring clicks), that could be a temporary solution.

Duplicate of https://github.com/driftyco/ionic/issues/1438


Exceptions which fire within Response.Send() cause entire app to exit

e.g. changing the code to this:
WriteStream(listenerResponse.OutputStream)
.Subscribe(s =>
{
	try
	{
		s.Close();

		throw new System.Net.Sockets.SocketException();

will cause the entire app to exit. Would be nice to pass any exceptions back up the chain for handling via the app itself.

Since Anna is based on Rx, it assumes that you repect the Rx ways of doing things. You should not do any "heavy lifting" inside the Subscribe method. Instead, you should handle such cases upward in the observable chain so that exceptions get sent in the error channel. You can take a look at how this can be done here: https://github.com/FurryBuilder/FluffIt.System.Reactive/blob/master/FluffIt.System.Reactive/ObservableExtensions.cs#L98


acl: 2.2.52 -> 2.2.53

Motivation for this change
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build acl

Should go to staging.

Sure, updated.


Merge codegen with compile phases

Purpose
This PR will merge the codegen with compile phases and now codegen will run as the final phase in the compile frontend.
Fixes #21977

Codecov Report

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

@@           Coverage Diff           @@
##           master   #23624   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1411     1411
  Branches      219      219
=======================================
  Hits          206      206
  Misses       1189     1189
  Partials       16       16

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 6e06a7c...cc056cd. Read the comment docs.


lfw accuracy

@foamliu Hi, thanks for your great work.
I have run lfw_eval.py with BEST_checkpoint_r101.tar and get these results:
Accuracy: 95.89999999999999%, threshold: 74.7915117227299
Visualizing data/angles.txt...
threshold: 74.7915117227299
mu_0: 84.83895336439484
sigma_0: 5.012717086396831
mu_1: 58.131685076850644
sigma_1: 10.471143670704363
error analysis...
len(fp): 90
len(fn): 156
this results different from your report, what should I do to get the same results?

Have you renamed BEST_checkpoint_r101.tar to BEST_checkpoint.tar before LFW evaluation?

i change 'BEST_checkpoint.tar' to 'BEST_checkpoint_r101.tar' in this line:
https://github.com/foamliu/InsightFace-v2/blob/094fb8d0741bc3aceb42e129b8b5ecd2cfc7f37c/lfw_eval.py#L325

Please pull latest code and try again, seems the low accuracy is related with one of my recent experiments.

Hello,
I run with your checkpoint https://github.com/foamliu/InsightFace-v2/releases/download/v1.0/BEST_checkpoint_r101.tar.
Accuracy: 99.61666666666666%, threshold: 75.49033778039826
Different with your report, why ?


Broken releases due(?) to broken maven setup (RoaringBitmapParent artifact)

I used to issue releases by going to the main RoaringBitmap repository and typing mvn release:clean && mvn release:prepare && mvn release:perform. Since PR https://github.com/RoaringBitmap/RoaringBitmap/pull/181 this no longer works. Sadly, CI does not check that releases are possible, so I did not catch the issue.
As I recall the point of the release was to move to a "classic maven project" described as follow:

Cannot we do a classic maven project by moving RoaringBitmap actual source to a specific submodule, and leaving all other submodules where they are?

Technically, I can issue the commands, but it does not generate an actual release and the result is a broken repository. I left the broken commits on purpose, so you can see the result...
https://github.com/RoaringBitmap/RoaringBitmap/commits/master
Note that to be able to do this in a sane way, I had to make a small change to the pom file so that jmh is excluded as a submodule by default, because otherwise, we run the full jmh unit test which takes 3 hours on my machine, and fails for an unclear reason (it looks like -DBITMAP_TYPES=ROARING_ONLY has no effect when doing mvn perform), with The forked VM terminated without saying properly goodbye.
Anyhow, the broken aspect of the release with mvn release:clean && mvn release:prepare && mvn release:perform has to do with the fact that this attempts to release an artifact RoaringBitmapParent. I am not sure what that is, and I am not sure that it is correct. Yet this seems to have been deliberate, see the pom file: https://github.com/RoaringBitmap/RoaringBitmap/blob/master/pom.xml#L5
To still be able to issue releases, I did a deploy instead from within the roaringbitmap subdirectory, hoping it would save us from RoaringBitmapParent artifact nonesense...
  cd roaringbitmap
  mvn versions:set -DnewVersion=0.6.53
  mvn clean deploy
  git commit -a
  git tag -a v0.6.53 -m "version 0.6.53"
  git push --tags
  # go to https://oss.sonatype.org/#nexus-search;quick~roaringbitmap and initial the release manually

Sadly, this result in something that is broken as well as you can see from a report on the mailing list:

I'm having some problems pulling the latest release from maven central via Leiningen:
[~/repos/streaming-lda] $ lein deps
Retrieving org/roaringbitmap/RoaringBitmap/0.6.53/RoaringBitmap-0.6.53.pom from central
Could not find artifact org.roaringbitmap:RoaringBitmapParent:pom:0.6.53 in central > (https://repo1.maven.org/maven2/)
This could be due to a typo in :dependencies or network issues.
You can see it's looking for a artifact with "RoaringBitmapParent" in the name.  Leiningen doesn't do this when I try to pull down any other version, it just grabs the pom and jar having the usual names, like this:
[~/repos/streaming-lda] $ lein deps
Retrieving org/roaringbitmap/RoaringBitmap/0.6.49/RoaringBitmap-0.6.49.pom from central
Retrieving org/roaringbitmap/RoaringBitmap/0.6.49/RoaringBitmap-0.6.49.jar from central
I can see from the history your pom file that this is some sort of intentional change.  My maven knowledge is fairly low, but I'm suspicious that this is something Leiningen either doesn't support requires some workaround for.  Do you know anything more about this than I do?

Anyhow, it seems clear that either the maven project is broken or else, I am lacking the right release instructions.
I think that this is an urgent problem.

c.c. @blasd @Kineolyan @gssiyankai
Please help! ;-)

I could try to fix it and probably succeed, but I don't know why a RoaringBitmapParent artifact was introduced. For all I know, this is what is desired... but I don't understand why...

I'm having a look

In a few words: RoaringBitmapParent has been introduced to ensure all sub-modules relies on the same version of RoaringBitmap: https://github.com/RoaringBitmap/RoaringBitmap/issues/178
About deployments, we expect the parent pom to be deployed to sonatype: it is definitely not deployed for now: http://central.maven.org/maven2/org/roaringbitmap/ . This parent pom is actually made required by https://github.com/RoaringBitmap/RoaringBitmap/pull/181 as the core jar have a pom with a parent.
Right now, the pom.xml in master are in 0.6.53, which seems weird as I expect them to be in 0.6.54-SNAPSHOT
Regarding jmh and other modules: You want them to be part of the release process as you want their pom to be updated accordingly. However, if you do not want to run tests, you have to make this skipping explicit (and ensure the run of JMH tests happens only if another flag is explicitely added).
Let's say you want to skip all test in your release process, you guess you could go with:
mvn release:clean && mvn release:prepare -Darguments="-Dmaven.test.skip" && mvn release:perform -Darguments="-Dmaven.test.skip"

What is the issue when you run mvn release:clean && mvn release:prepare && mvn release:perform from the root? (except from JMH slowness).

To push the parent pom in 0.6.53, you may
checkout the proper sha1
remove sub-modules from the root pom.xml
you may need to to a fake commit but I do not believe so
ensure you are in the root folder
run mvn deploy
It should not conflict with existing deployed artifacts and should then succeed. Not having proper rights, I can not propose to do it myself.

Also, if you want some additionals env variables to your mvn commands during a mvn perform, they have to be added is -Darguments="...".
Then, to properly add -DBITMAP_TYPES=ROARING_ONLY in mvn perform:
mvn release:perform -Darguments="-DBITMAP_TYPES=ROARING_ONLY"

Thanks. Regarding the lack of a snapshot, it is not mysterious, please see the commands I did enter: I changed the version manually.

Sorry, mistook the close button with the cancel usually found in PRs :disappointed:

I am looking at it. But so far, I agree with @blasd that the root parent should be kept, for it provides a BOM for other projects.

I offer you this PR that should solve your issue.
As stated in my comment, I kept the release of the parent pom, as it is not really a pain and acts as BOM for other projects and is needed for the code project.
In a nutshell, the PR makes the historical command line works and restores the old tag name.
Cheers :smiley:

@blasd

Also, if you want some additionals env variables to your mvn commands during a mvn perform, they have to be added is -Darguments="...".

If you run this command...
mvn release:clean && mvn release:prepare -Darguments="-Dmaven.test.skip" && mvn release:perform -Darguments="-Dmaven.test.skip"

It will most certainly run all tests. Twice. The fact that it runs the tests is not so bad, but I never understood why the release process involved running all tests twice. What is more, even if just one test fails, it still runs everything to completion...

@blasd
I merged @Kineolyan's PR and issue the command he recommended. Our CI is going to indicate a failure, I suspect. Here is what I got:
$ mvn release:clean release:prepare release:perform
(... skipping about a million lines...)
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git commit --verbose -F /var/folders/y8/nl_pprtd12x78vqkv3px0bp40000gn/T/maven-scm-1811012865.commit pom.xml roaringbitmap/pom.xml real-roaring-dataset/pom.xml jmh/pom.xml memory/pom.xml
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git symbolic-ref HEAD
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git push git@github.com:RoaringBitmap/RoaringBitmap.git refs/heads/master:refs/heads/master
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Tagging release with the label RoaringBitmap-0.6.54...
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git tag -F /var/folders/y8/nl_pprtd12x78vqkv3px0bp40000gn/T/maven-scm-1746834451.commit RoaringBitmap-0.6.54
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git push git@github.com:RoaringBitmap/RoaringBitmap.git refs/tags/RoaringBitmap-0.6.54
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git ls-files
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Transforming 'RoaringBitmapParent'...
[INFO] Transforming 'RoaringBitmap'...
[INFO] Transforming 'Real Roaring Dataset'...
[INFO] Transforming 'JMH benchmark : RoaringBitmap'...
[INFO]   Ignoring artifact version update for expression ${project.version}
[INFO]   Ignoring artifact version update for expression ${project.version}
[INFO] Transforming 'Memory benchmark : RoaringBitmap'...
[INFO]   Ignoring artifact version update for expression ${project.version}
[INFO]   Ignoring artifact version update for expression ${project.version}
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git add -- pom.xml roaringbitmap/pom.xml real-roaring-dataset/pom.xml jmh/pom.xml memory/pom.xml
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git rev-parse --show-toplevel
[INFO] Working directory: /Users/lemire/CVS/github/RoaringBitmap
[INFO] Executing: /bin/sh -c cd /Users/lemire/CVS/github/RoaringBitmap && git status --porcelain .

[INFO]
[INFO] --- maven-release-plugin:2.5.3:perform (default-cli) @ RoaringBitmapParent ---
[INFO] Checking out the project to perform the release ...

[WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective model for org.roaringbitmap:RoaringBitmap:bundle:0.6.54
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin is missing. @ org.roaringbitmap:RoaringBitmap:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/roaringbitmap/pom.xml
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective model for org.roaringbitmap:real-roaring-dataset:jar:0.6.54
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ org.roaringbitmap:real-roaring-dataset:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/real-roaring-dataset/pom.xml
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. @ org.roaringbitmap:real-roaring-dataset:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/real-roaring-dataset/pom.xml
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin is missing. @ org.roaringbitmap:real-roaring-dataset:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/real-roaring-dataset/pom.xml
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective model for org.roaringbitmap:jmh:jar:0.6.54
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ org.roaringbitmap:jmh:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/jmh/pom.xml
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. @ org.roaringbitmap:jmh:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/jmh/pom.xml
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin is missing. @ org.roaringbitmap:jmh:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/jmh/pom.xml
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective model for org.roaringbitmap:memory:jar:0.6.54
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ org.roaringbitmap:memory:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/memory/pom.xml
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. @ org.roaringbitmap:memory:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/memory/pom.xml
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin is missing. @ org.roaringbitmap:memory:[unknown-version], /Users/lemire/CVS/github/RoaringBitmap/target/checkout/memory/pom.xml
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective model for org.roaringbitmap:RoaringBitmapParent:pom:0.6.54
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing.
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing.
[INFO] [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-deploy-plugin is missing.
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[INFO] [WARNING]
[INFO] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[INFO] [WARNING]
[INFO] [INFO] Inspecting build with total of 5 modules...

[INFO] Audit done.

[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] RoaringBitmapParent ................................ FAILURE [  7.752 s]
[INFO] [INFO] RoaringBitmap ...................................... SKIPPED
[INFO] [INFO] Real Roaring Dataset ............................... SKIPPED
[INFO] [INFO] JMH benchmark : RoaringBitmap ...................... SKIPPED
[INFO] [INFO] Memory benchmark : RoaringBitmap ................... SKIPPED
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 9.510 s
[INFO] [INFO] Finished at: 2017-12-18T16:58:28-05:00
[INFO] [INFO] Final Memory: 30M/166M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy (injected-nexus-deploy) on project RoaringBitmapParent: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy failed: Server credentials with ID "ossrh" not found! -> [Help 1]
[INFO] [ERROR]
[INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
[INFO] [ERROR]
[INFO] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[INFO] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] RoaringBitmapParent ................................ FAILURE [07:12 min]
[INFO] RoaringBitmap ...................................... SKIPPED
[INFO] Real Roaring Dataset ............................... SKIPPED
[INFO] JMH benchmark : RoaringBitmap ...................... SKIPPED
[INFO] Memory benchmark : RoaringBitmap ................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 07:13 min
[INFO] Finished at: 2017-12-18T16:58:34-05:00
[INFO] Final Memory: 14M/102M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on project RoaringBitmapParent: Maven execution failed, exit code: '1' -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

The error seems to be:
[INFO] [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy (injected-nexus-deploy) on project RoaringBitmapParent: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy failed: Server credentials with ID "ossrh" not found! -> [Help 1]

The ossrh value which seems (?) to be causing the problem was introduced in this PR:
https://github.com/RoaringBitmap/RoaringBitmap/commit/1b1f2817c103be21e6fbf46d6ad73d3327d8b36e#diff-600376dffeb79835ede4a0b285078036
We had...
  <parent>
     <groupId>org.sonatype.oss</groupId>
     <artifactId>oss-parent</artifactId>
     <version>5</version>
   </parent>

It was replaced by...
        <configuration>
           <serverId>ossrh</serverId>
           <nexusUrl>https://oss.sonatype.org/</nexusUrl>
           <autoReleaseAfterClose>true</autoReleaseAfterClose>
         </configuration>

It looks like this ossrh serverId was introduced there... I am not sure what it means and why the old config was changed.

@blasd
My empirical observation is that release:prepare and release:perform ignore all flags, no matter how you write them. I'd be happy to learn that I am wrong... because running the tests twice is really annoying.

@Kineolyan @blasd
I understand that RoaringBitmapParent was introduced to synchronize the version numbers of the modules.
But we don't want to release RoaringBitmapParent. It seems to be what the code is trying to do. That's a bug. On the maven repository, we want to publish only the RoaringBitmap artifact and this should have minimal dependencies.

Ok. I solved part of the problem by adding the staging profile ID which seems necessary...
https://github.com/RoaringBitmap/RoaringBitmap/commit/c5120dcf6559196b47ecda09407d42f5b70e4dd5

Now I get...
[INFO]
[INFO] Tests run: 1243, Failures: 0, Errors: 0, Skipped: 1
[INFO]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] RoaringBitmapParent ................................ SUCCESS [  2.785 s]
[INFO] [INFO] RoaringBitmap ...................................... FAILURE [15:43 min]
[INFO] [INFO] Real Roaring Dataset ............................... SKIPPED
[INFO] [INFO] JMH benchmark : RoaringBitmap ...................... SKIPPED
[INFO] [INFO] Memory benchmark : RoaringBitmap ................... SKIPPED
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 15:47 min
[INFO] [INFO] Finished at: 2017-12-18T19:39:12-05:00
[INFO] [INFO] Final Memory: 22M/152M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project RoaringBitmap: ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

Tried again on a different machine, and the previous problem reoccurs...
(...)
[INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @ RoaringBitmapParent ---
[INFO] [INFO] Installing /home/dlemire/CVS/github/RoaringBitmap/target/checkout/pom.xml to /home/dlemire/.m2/repository/org/roaringbitmap/RoaringBitmapParent/0.6.56/RoaringBitmapParent-0.6.56.pom
[INFO] [INFO] Installing /home/dlemire/CVS/github/RoaringBitmap/target/checkout/target/RoaringBitmapParent-0.6.56.pom.asc to /home/dlemire/.m2/repository/org/roaringbitmap/RoaringBitmapParent/0.6.56/RoaringBitmapParent-0.6.56.pom.asc
[INFO] [INFO]
[INFO] [INFO] --- nexus-staging-maven-plugin:1.6.8:deploy (injected-nexus-deploy) @ RoaringBitmapParent ---
[INFO] [INFO] Performing local staging (local stagingDirectory="/home/dlemire/CVS/github/RoaringBitmap/target/checkout/target/nexus-staging/staging")...
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] RoaringBitmapParent ................................ FAILURE [  2.806 s]
[INFO] [INFO] RoaringBitmap ...................................... SKIPPED
[INFO] [INFO] Real Roaring Dataset ............................... SKIPPED
[INFO] [INFO] JMH benchmark : RoaringBitmap ...................... SKIPPED
[INFO] [INFO] Memory benchmark : RoaringBitmap ................... SKIPPED
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 3.898 s
[INFO] [INFO] Finished at: 2017-12-18T20:09:23-05:00
[INFO] [INFO] Final Memory: 35M/598M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy (injected-nexus-deploy) on project RoaringBitmapParent: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy failed: Server credentials with ID "ossrh" not found! -> [Help 1]
[INFO] [ERROR]
[INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
[INFO] [ERROR]
[INFO] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[INFO] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] RoaringBitmapParent ................................ FAILURE [03:47 min]
[INFO] RoaringBitmap ...................................... SKIPPED
[INFO] Real Roaring Dataset ............................... SKIPPED
[INFO] JMH benchmark : RoaringBitmap ...................... SKIPPED
[INFO] Memory benchmark : RoaringBitmap ................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:48 min
[INFO] Finished at: 2017-12-18T20:09:23-05:00
[INFO] Final Memory: 19M/605M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on project RoaringBitmapParent: Maven execution failed, exit code: '1' -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

(I am documenting my attempts so that you can see how frustrating this is.)

Ok. I think I solved the problem after tweaking quite a bit. The key point is that you must specify a staging profile ID.

Thanks guys.
And if anyone finds out how to cut down on the redundant testing, I am eager for anything flag that gets the job done. As I wrote above, I think that there is no way to affect the testing of release:prepare, release:perform using command line flags (despite abundant documentation to the contrary).

I think that the failure with the VM exiting is real but it cannot be reproduced consistently.

@blasd
Note that RoaringBitmapParent is now being released...
http://central.maven.org/maven2/org/roaringbitmap/
I still think it is a bug because no user should ever need an empty dependency, but there are more important things to fix.

For future reference... the sonatype documentation briefly mentions the need for the stagingProfileId.

To deploy this file system repository with the goal, you have to provide the path to this repository with the repositoryDirectory parameter as well as nexusUrl, serverId and stagingProfileId.

In our case, we need this line...
 <stagingProfileId>3a809bf4297e26</stagingProfileId>

Why this is needed in beyond me. There is precious little documentation.

The changes in 1b1f281#diff-600376dffeb79835ede4a0b285078036 follows the recommandations in http://central.sonatype.org/pages/apache-maven.html

Deprecated oss-parent
In the past all the plugin configuration and other setup was managed by a Maven parent POM with the latest coordinates of org.sonatype.oss:oss-parent:9. This project leaked SCM, URL and other details and its usage is discouraged. Maintenance of the project has stopped and it no longer works with latest tooling such as Maven versions or Java versions. If desired, please manage your own organization-level POM in a similar manner.

It seems the old configuration based on  https://github.com/sonatype/oss-parents/blob/master/oss-parent/pom.xml rely on the serverId

sonatype-nexus-staging

. I guess your sonatype credentials in settings.xml are associated to sonatype-nexus-staging instead of

ossrh

(as described in http://central.sonatype.org/pages/apache-maven.html ).
It seems to be the same serverId in version 9 of oss pom: http://central.maven.org/maven2/org/sonatype/oss/oss-parent/9/oss-parent-9.pom
Moving to the recommanded OSS configuration was paired with the usage of recommanded sonatype deploy plugin:
<build>
<plugins>
...
<plugin>
  <groupId>org.sonatype.plugins</groupId>
  <artifactId>nexus-staging-maven-plugin</artifactId>
  <version>1.6.7</version>
  <extensions>true</extensions>
  <configuration>
     <serverId>ossrh</serverId>
     <nexusUrl>https://oss.sonatype.org/</nexusUrl>
     <autoReleaseAfterClose>true</autoReleaseAfterClose>
  </configuration>
</plugin>

Given your latest insights, I guess the fix was simply to change <serverId>ossrh</serverId> to <serverId>sonatype-nexus-staging</serverId>. This should have fixed [INFO] [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy (injected-nexus-deploy) on project RoaringBitmapParent: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy failed: Server credentials with ID "ossrh" not found! -> [Help 1].
This channge of serverId is also descrtibed in https://help.sonatype.com/display/NXRM2/Configuring+Your+Project+for+Deployment (but here, it is <serverId>nexus</serverId>, Thanks Sonatype for being consistant).
stagingProfileId is required for more complex cases, or usage, or Maven2.
Having a parent pom.xml deployed with the main jar seems a requirement as long a we want a parent pom in RoaringBitmap into local maven modules. I do not see this an an issue (and many people do it like this (e.g. http://central.maven.org/maven2/com/google/guava/guava-parent/)).
About having additional parameters, I ensure you mvn release:clean release:prepare -Darguments="-Dmaven.test.skip" and mvn release:perform -Darguments="-Dmaven.test.skip" would skip tests (as you seem not to have any other special piece of configuration inside surefire/failsafe/release plugins). However, it does not work with latest PR towards release fix https://github.com/RoaringBitmap/RoaringBitmap/pull/198 because<arguments>-Prelease</arguments> in
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.5.3</version>
            <configuration>
                <goals>deploy</goals>
                <releaseProfiles>release</releaseProfiles>
                <arguments>-Prelease</arguments>
<EMAIL_ADDRESS>            </configuration>
        </plugin>

superseeds -Darguments="-Dmaven.test.skip". However it should have worked before the PR. I checked locally by removing <arguments>-Prelease</arguments>.
We are all spending quite some time on this issue, but the three of us are going into different directions.
@lemire, what is your target ? Keep Sonatype legacy configuration or move to the recommanded one?

In short, I would be happy to help with a PR, but I would need feedback. As you have reverted most changes, I do not know if you want to keep the legacy behavior or complete the move to the recommanded configuration.

@blasd

About having additional parameters, I ensure you mvn release:clean release:prepare -Darguments="-Dmaven.test.skip" and mvn release:perform -Darguments="-Dmaven.test.skip" would skip tests (as you seem not to have any other special piece of configuration inside surefire/failsafe/release plugins). However, it does not work with latest PR towards release fix https://github.com/RoaringBitmap/RoaringBitmap/pull/198 because-Prelease

Interesting. I like this explanation.
I would expect maven to warn me when command line parameters are superseded... Maven is not shy about dumping megabytes of text in my console, but there seems to be nothing about dropping the command-line parameters on the floor.

@lemire would now be the wrong time to suggest Gradle?

@blasd

We are all spending quite some time on this issue

I appreciate this and though I am visibly impatient, please trust that my impatience is with the tool, not you. You are being generous. So is @Kineolyan.
  I'd be a much happier camper. As it is, this is a very fragile process where I have to go through the whole thing... wait >15mins, and then watch a failure...

Having a parent pom.xml deployed with the main jar seems a requirement as long a we want a parent pom in RoaringBitmap into local maven modules.

Ok.
What would be more natural, I think, would be to have RoaringBitmap to be the main artifact (parent) and have other artifacts depend on it. It is unclear why, conceptually, we need to introduce a fake parent, when everything clearly depends on RoaringBitmap. I recognize, however, that it is how maven works, possibly.

I guess your sonatype credentials in settings.xml are associated to sonatype-nexus-staging instead of ossrh

As hinted in the comments of the pom.xml file as it stands now, I had modified my settings.xml so that it contains the following...
   <servers>
    <server>
      <id>sonatype-nexus-snapshots</id>
      <username>lemire</username>
      <password>XXXXX</password>
    </server>
    <server>
      <id>sonatype-nexus-staging</id>
      <username>lemire</username>
      <password>XXXXX</password>
    <server>
      <id>ossrh</id>
      <username>lemire</username>
      <password>XXXX</password>
    </server>
   </servers>

It is kind of hack in the sense that I just copied over my username and password and added <id>ossrh</id>. Maybe I am supposed to get whole new credentials. Maybe I am supposed to remove the old server?
Sadly, again, though Maven is incredibly verbose, when things go wrong, it gives you very little information to figure out what is wrong.
I am not sure how to test these credentials other than by trying to do whole releases.

stagingProfileId is required for more complex cases, or usage, or Maven2.

Empirically, it seems like it was needed to get a viable release. I cannot test this out without issuing a new commit, running the whole thing for ~15 mins, with tests and everything... and then going to sonatype to delete the artifact. So I am not eager to explore because of all the garbage it generates. If there was a way to explore without generating a trail of garbage... I'd be happier.
That is, I am working experimentally, trying to run as few experiments as possible. Not ideal.

As you have reverted most changes, I do not know if you want to keep the legacy behavior or complete the move to the recommanded configuration.

Wait? What? No. No. What did I revert?
Let us be clear... my intention was to keep what you and @Kineolyan contributed, and only change as little as I could so that I could issue a release. I hacked things out until it worked, changing as little as I could. If I changed too much, I am quite willing to revert things... but my condition is that we need to be able to issue releases.
It seems like what you contributed was a parent artifact. This is mostly certainly there. If I broke something else, please let us fix it.
In an ideal world, that would be part of CI... so that when you propose a change, we could check whether releases are still possible (I used to rely on flags like -B -DdryRun=true). As it is, we have this fragile process whereas if you propose a change... I have to do the whole release:prepare release:perform thing to see whether things work.
Ok. So let us look at the differences between pom.xml between your early PR and the current setting...
$ git diff   c304f92b3c31b37cc2961053ed37d2591165bcba   b000aff28bb622c8e2fedae7614e1df7beda7988   pom.xml
diff --git a/pom.xml b/pom.xml
index 553002d1..dd19ccb9 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1,18 +1,40 @@
-<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
     <modelVersion>4.0.0</modelVersion>
     <groupId>org.roaringbitmap</groupId>
     <artifactId>RoaringBitmapParent</artifactId>
-    <version>0.6.52-SNAPSHOT</version>
+    <version>0.6.60-SNAPSHOT</version>

     <packaging>pom</packaging>

     <modules>
         <module>roaringbitmap</module>
+        <module>real-roaring-dataset</module>
         <module>jmh</module>
         <module>memory</module>
-        <module>real-roaring-dataset</module>
     </modules>
+    <profiles>
+        <profile>
+            <id>release</id>
+            <build>
+                <plugins>
+                    <plugin>
+                        <groupId>org.apache.maven.plugins</groupId>
+                        <artifactId>maven-gpg-plugin</artifactId>
+                        <version>1.6</version>
+                        <executions>
+                            <execution>
+                                <id>sign-artifacts</id>
+                                <phase>verify</phase>
+                                <goals>
+                                    <goal>sign</goal>
+                                </goals>
+                            </execution>
+                        </executions>
+                    </plugin>
+                </plugins>
+            </build>
+        </profile>
+    </profiles>

     <properties>
         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
@@ -28,7 +50,36 @@
         <developerConnection>scm:git:git@github.com:RoaringBitmap/RoaringBitmap.git</developerConnection>
         <tag>HEAD</tag>
     </scm>
+<!--
+The settings.xml file should contain:

+<settings>
+  <servers>
+    <server>
+      <id>ossrh</id>
+      <username>your-jira-id</username>
+      <password>your-jira-pwd</password>
+    </server>
+  </servers>
+</settings>
+
+
+-->
+<!--<distributionManagement>
+  <snapshotRepository>
+    <id>ossrh</id>
+    <url>https://oss.sonatype.org/content/repositories/snapshots</url>
+  </snapshotRepository>
+  <repository>
+    <id>ossrh</id>
+    <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
+  </repository>
+</distributionManagement>-->
+  <parent>
+    <groupId>org.sonatype.oss</groupId>
+    <artifactId>oss-parent</artifactId>
+    <version>9</version>
+  </parent>
     <build>
         <plugins>
             <plugin>
@@ -94,33 +145,30 @@
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-release-plugin</artifactId>
                 <version>2.5.3</version>
-                <executions>
-                    <execution>
-                        <id>default</id>
-                        <configuration>
-                            <goals>deploy</goals>
-
-                            <!-- https://stackoverflow.com/questions/10694139/maven-3-0s-mvn-releaseperform-doesnt-like-a-pom-xml-that-isnt-in-its-git-r -->
-                            <!-- <pomFileName>parent/pom.xml</pomFileName> -->
-                        </configuration>
-                    </execution>
-                </executions>
+                <configuration>
+                    <goals>deploy</goals>
+                    <releaseProfiles>release</releaseProfiles>
+                    <arguments>-Prelease</arguments>
+<EMAIL_ADDRESS>+                </configuration>
             </plugin>

             <!-- https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin -->
             <!-- http://www.sonatype.org/nexus/2014/10/08/distribute-project-artifacts-in-maven-central-with-nexus-oss/ -->
-            <plugin>
+            <!-- https://mvnrepository.com/artifact/org.sonatype.plugins/nexus-staging-maven-plugin -->
+
+            <!-- <plugin>
                 <groupId>org.sonatype.plugins</groupId>
                 <artifactId>nexus-staging-maven-plugin</artifactId>
-                <!-- https://mvnrepository.com/artifact/org.sonatype.plugins/nexus-staging-maven-plugin -->
                 <version>1.6.8</version>
                 <extensions>true</extensions>
                 <configuration>
                     <serverId>ossrh</serverId>
                     <nexusUrl>https://oss.sonatype.org/</nexusUrl>
+                    <stagingProfileId>3a809bf4297e26</stagingProfileId>
                     <autoReleaseAfterClose>true</autoReleaseAfterClose>
                 </configuration>
-            </plugin>
+            </plugin>-->
             <plugin>
                 <groupId>org.jacoco</groupId>
                 <artifactId>jacoco-maven-plugin</artifactId>
@@ -167,46 +215,6 @@
             </plugin>
             <plugin>
                 <groupId>org.apache.maven.plugins</groupId>
-                <artifactId>maven-gpg-plugin</artifactId>
-                <version>1.6</version>
-                <executions>
-                    <execution>
-                        <id>sign-artifacts</id>
-                        <phase>verify</phase>
-                        <goals>
-                            <goal>sign</goal>
-                        </goals>
-                    </execution>
-                </executions>
-            </plugin>
-            <plugin>
-                <groupId>org.apache.maven.plugins</groupId>
-                <artifactId>maven-javadoc-plugin</artifactId>
-                <version>2.10.4</version>
-                <executions>
-                    <execution>
-                        <id>attach-javadocs</id>
-                        <goals>
-                            <goal>jar</goal>
-                        </goals>
-                    </execution>
-                </executions>
-            </plugin>
-            <plugin>
-                <groupId>org.apache.maven.plugins</groupId>
-                <artifactId>maven-source-plugin</artifactId>
-                <version>3.0.1</version>
-                <executions>
-                    <execution>
-                        <id>attach-sources</id>
-                        <goals>
-                            <goal>jar</goal>
-                        </goals>
-                    </execution>
-                </executions>
-            </plugin>
-            <plugin>
-                <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-jar-plugin</artifactId>
                 <version>3.0.2</version>
                 <configuration>
@@ -222,6 +230,27 @@
         </plugins>
     </build>

+    <dependencyManagement>
+        <dependencies>
+            <dependency>
+                <groupId>junit</groupId>
+                <artifactId>junit</artifactId>
+                <version>4.12</version>
+                <scope>test</scope>
+            </dependency>
+            <dependency>
+                <groupId>com.google.guava</groupId>
+                <artifactId>guava</artifactId>
+                <!-- 21 relies on for Java8 -->
+                <version>20.0</version>
+            </dependency>
+            <dependency>
+                <groupId>org.apache.commons</groupId>
+                <artifactId>commons-lang3</artifactId>
+                <version>3.4</version>
+            </dependency>
+        </dependencies>
+    </dependencyManagement>
     <reporting>
         <plugins>
             <plugin>

Only part of these changes were my changes... I think that others should be attributed to @Kineolyan (e.g., I don't recall throwing an org.apache.commons dependency in there). And there are commented out things. So what I did, it seems, is to go back to parent/groupId thingy.
<parent>
   <groupId>org.sonatype.oss</groupId>
   <artifactId>oss-parent</artifactId>
   <version>9</version>
 </parent>

which I guess, from your analysis, relies on the sonatype-nexus-staging credentials. Is any of this supposed to be intuitive?
Anyhow... is this what you mean by "you have reverted most changes"?
From my point of view, I just hacked things until I could get what appears to be a working release... doing as few iterations as possible and working with what I consider to be really poor documentation.

@richardstartin

would now be the wrong time to suggest Gradle?

(sounds of Daniel grinding his teeth)
Gradle? Ok...
https://gradle.org/maven-vs-gradle/

Maven provides a very rigid model that makes customization tedious and sometimes impossible
These and more performance features make Gradle at least twice as fast for nearly every scenario (100x faster for large builds using the build cache)
Gradle provides a modern CLI that has discoverability features like gradle tasks, as well as improved logging and command-line completion.
Gradle provides an interactive web-based UI for debugging and optimizing builds: build scans.
Maven has few, built-in dependency scopes, which forces awkward module architectures in common scenarios

Hello @lemire,
As pointed in my comment, I think I can easily tune something not to run tests during the deploy phase of the release process. It only add more elements to the poms.
Regarding the release of RoaringBitmapParent, I am pretty sure but not certain that it must be released, because our dear RoaringBitmapParent marks it as its parent. If not present, all builds will fail for this pom cannot be downloaded. But again, as I did not deploy on a real Maven repository, I cannot be sure.
About @richardstartin proposal of migrating to Gradle, it is an option I consider for various projects. In our case, I am not sure it would change much. It is just the trendy tool wrt Maven.
Cheers

@Kineolyan
I don't think he was serious. I am not considering Gradle. Someone would have to build a case for it and do the legwork.
I'll add that tools like Maven is what turn people off to command line tools. You really, really want to go back and hide in an IDE. I'm a command-like guy and I cringe when I have to issue maven commands... because it is going to be slow and fragile... I mean... like us get serious... what is this -Darguments="-DskipTests" shit? And how does it differ from -Darguments="-Dmaven.test.skip"? It is just insane.
Fortunately, we don't have to program using maven... most of the time.

As pointed in my comment, I think I can easily tune something not to run tests during the deploy phase of the release process. It only add more elements to the poms.

That would be a nice contribution. We should run tests on release:prepare or release:perform, not both. It would be fine to run tests on jmh, but not the whole tests, we need to pass the BITMAP_TYPES=ROARING_ONLY and make extra sure it applies.

But again, as I did not deploy on a real Maven repository, I cannot be sure.

That's a problem. I get it that one trusted person should issue releases because you don't want the Russian mafia or the CIA to be releasing versions of our library... But I view it as a problem that I am the sole one able to make releases. It is not very robust.
What if I go mad after hitting too many problems with Maven (joke)?
Any sane and secure way that we could use to extend the set of people able to issue releases?
I'm fine with issuing the releases, but I'd be happy to share this "power".

@blasd
If my credentials were/are wrong, how was I able to release 0.6.53 with mvn deploy? You'd think that if your credentials are wrong, you wouldn't be able to release anything?
That is, the ossrh error did not occur when typing mvn deploy, which suggests to me that it did pick the ossrh  credentials... or am I wrong in this assumption?

The share conf, we need a maven parent module. A maven parent module has to have packaging=pom. This explains why we have this additional parent pom.xml . Not having it would requiring weird additional configuration.
If you consider adding release rights to others, I guess this would go through another Sonatype Jira ticket: https://issues.sonatype.org/browse/OSSRH-8958?jql=text ~ "roaringbitmap"
Commenting out nexus-staging-maven-plugin and introducing back oss-parent was what made be mis-interpreted as your will to revert to the legacy configuration.
About, the duplication of servers with different ids but same credentials is the way to go (i.e. sonatype-nexus-staging for oss-parent). I will change ossrh to sonatype-nexus-staging in my next PR. None of this would have happened if I had foresee this change of underlying serverId...
<servers>
<server>
  <id>sonatype-nexus-snapshots</id>
  <username>lemire</username>
  <password>XXXXX</password>
</server>
<server>
  <id>sonatype-nexus-staging</id>
  <username>lemire</username>
  <password>XXXXX</password>
</server>
<server>
  <id>ossrh</id>
  <username>lemire</username>
  <password>XXXX</password>
</server>

I removed stagingProfileId, as it seems very suspicious, and I've never needed it for other artifacts deployed to sonatype/central repo. The config looks now to:
       <plugin>
            <groupId>org.sonatype.plugins</groupId>
            <artifactId>nexus-staging-maven-plugin</artifactId>
            <version>1.6.8</version>
            <extensions>true</extensions>
            <configuration>
                <serverId>sonatype-nexus-staging</serverId>
                <nexusUrl>https://oss.sonatype.org/</nexusUrl>
                <autoReleaseAfterClose>true</autoReleaseAfterClose>
            </configuration>
        </plugin>

I unsure how to cleanly apply test during mvn prepare but not mvn perform. @Kineolyan ?
@lemire , you confirm you want to keep tests into the release process, but it must add '-DBITMAP_TYPES=ROARING_ONLY' to prevent JMH to be too slow? (The simpler being to skip all tests into the release process).

About 0.6.53 half-deployed, I am not sure on which version you have done it.
But https://github.com/RoaringBitmap/RoaringBitmap/commit/d333e418789fa104b5d31fbc6803d05d680a22cc is in 0.6.43 and you added a dependencyManagement referring ossrh: if in this situation you have done
cd roaringbitmap
mvn deploy

it should have suceeded deploying roaringbitmap jar in 0.6.53 with ossrh credentials. But it is a plain guess

@blasd

as your will to revert to the legacy configuration

I would try hard to discuss it with you before willingly reverting a contribution you made.
You'd have a right to be upset if I did such a thing. I try not to upset people deliberately.
Maven is not a person, however... so I swear at it... a lot...

I'm very sorry @lemire . I seems my words do not express correctly my state of mind.
I feel it would be very legitimate if you wished to go back to previous configuration. I just tried to express my confusion if you would rather going back to previous way of doing things (which was certainly working smoothly), or if you were ready to spend more energy forward. I advise going forward, but I feel responsible for this as I've pushed these refactorings and they appear not side-effects-proof.
Anyway, I open a PR which tries to take the best of all this. As you have added relevant config in settings.xml (which was the main issue here, next to unexpected JMH tests taking too long). I'm currently checking only the relevant tests are conducted during the release. @Kineolyan may have more ideas how to run tests only during mvn prepare but not during mvn perform.

@blasd
You are not at fault. What you did is reasonable.
I think that the way forward is for me to run fake releases whenever the pom is changed... instead of waiting. This will create more releases than I’d like... but we’ll catch problems early.