apache-tomcat-8.0.26 does'not work

in the conf/context.xml file
Uncomment this to disable session persistence across Tomcat restarts
<Manager pathname="" />

when i Uncomment  it,  springreload does not work

Look at devtools.
From: liuxianbing<EMAIL_ADDRESS>Sent: Thursday, February 18, 2016 11:28 PM
To: spring-projects/spring-loaded
Subject: [spring-loaded] apache-tomcat-8.0.26 does'not work (#167)
in the conf/context.xml file
when i Uncomment it, springreload does not work
—
Reply to this email directly or view it on GitHubhttps://github.com/spring-projects/spring-loaded/issues/167.
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

in the conf/context.xml file
Uncomment this to disable session persistence across Tomcat restarts

when i Uncomment it, springreload does not work


document lock mismatch state for ensure

What does this do / why do we need it?
It adds documentation to the readme regarding the mismatch lock state in dep status
What should your reviewer look out for in this PR?
Do you need help or clarification on anything?
@carolynvs mentioned in the issue that modifying the Gopkg.toml should also generate the same message when you run dep ensure, but I tried and I did not get such message. Only when I added the import. Should I report it as a bug?
Which issue(s) does this PR fix?
Fixes #876

Just tweaking the white-space or changing metadata isn't enough to make dep want to rewrite the lock (which is what a lock mismatch is). One example of a change that will trigger a mismatch would be adding a new required package:
required = ["github.com/pkg/errors"]

So you should be fine, the message is the same regardless of how the mismatch was triggered.

@carolynvs done!


Add Email/Password authentication

Description
Some hackathon projects will want to be able to use their own login system. Our example app should support users signing up and logging on using typical email/password credentials. This was not included originally with the starter kit because (IMHO) it adds unneeded complexity to applications to support custom logins. However, our starter kit should probably be more flexible.

I want to work on this issue

I want to work on this issue


Clarify Readme : Client-password should be API-key (Unauthorized error)

Hello,
May I suggest you clarify the documentation on the readme file, as I have been spending a few hours trying to make the SDK example work but could not until I figured out that I should enter the API-Key as the Client-password and not my client password ^^
I was getting an 401 Unauthorized error.

Hello @Nicolas-Bouteille and thans for your feedback.
#279 + a readme update will make this clearer, sorry for your lost of time !


WIP: Split create runtime server endpoint

Endpoint 1: Create the runtime, make the container hang
Endpoint 2: Use the hanging container to execute the use custom command using sh -c
Kill the build runtime when finished or if failed.
This would help us in segregating the user errors during build stage from other server failures.

Closing this PR for now as it would require a major refactor.


006 Additional Material Characteristics

https://github.com/uwlib-cams/MARC2RDA/blob/main/Working Documents/00X.csv

@lake44me @dchen077
Much of the 006 mapping mirrors the 008 mapping. Are these manifestation values also mapped to the original manifestation in the case of reproductions, or do they all map to the reproduction manifestation?

I am not aware that 006 have any reproduction conditions so I would assume they map to reproduction manifestation, though I would wait for Laura to confirm it.


couple subdomains

Coupling domains defined on different meshes by an InterfaceMesh1D is demonstrated in ex04, but since a boundary value problem can be solved in a subdomain #159 #160, can problems on subdomains be coupled too?
What are the relative advantages of multiple subdomains and multiple domains?

It might be simpler to construct the mesh and bases on the interface between subdomains.

An InterfaceMesh1D requires a rule: Callable[[float, float], bool] which might be awkward for more complicated shapes.

Multiple domains needn't have matching meshes.  This is particularly important for problems with large deformation.
The ease of either solving ‘monolithically’ versus ‘partitioned’, ‘staggered’, ‘segregrated’ (see, e.g. Piperno & Farhat 2001 for the terminology) is probably about the same for subdomains and domains, given the flexibility of scikit-fem; e.g. ex04 demonstrates the use of scipy.sparse.bmat for monolithic solution across mismatched meshes.

This issue is to demonstrate the possibility of coupling subdomains; comparison can follow.
An obvious choice for a first example is one following the insulated wire ex17 #89 #90 and the solution for the wire with the coating kept cold ex26 #159 #160, extending the latter with a Laplace equation in the annulus to recover the solution of the former.  This belongs to the class of Poisson problems with discontinuous coefficients treated by Gustafsson, Stenberg, & Videman (2018).
The motivation is multiphysics like conjugate heat transfer, in which different subdomains are governed by different partial differential equations; however, this doesn't intrinsically distinguish between multiple subdomains and multiple domains, the difference will come down to practical implementation details, which is what is to be explored here.

Monolithic conjugate heat transfer is demonstrated in #218.

ex04 is broken without InterfaceMesh1D #215.

I'm now convinced that the simplest way to do this is to use a global Lagrange multiplier together with a stabilized method. I'll try to make an example at some point because I want to try out this approach.


Minor bugfixes

Version 2.0.0
Improvements
Moved log check to be less than 100 lines into a log function in Processing script.
Bugfix

Added remove trigger line in controller
Bugfix of external event deregistering in Processing script

Following tasks were checked

[x] Module is coded and structured according to the "Developing guideline for modules" described within the CSK documentation
[x] All functions/events/parameters are documented within the manifest documentation
[x] The manifest description of the main CROWN includes main information about the purpose of the module and how to use it in general
[x] API docu based on the manifest was created and stored within the "docu"-folder of the repository
[x] Internal LUA code documentation exists for variables and non served functions
[x] All relevant infos are logged via the SharedLogger 'ModuleLogger'
[x] Module supports persistent data feature based on 'CSK_Module_PersistentData'
[x] Module supports user management based on 'CSK_Module_UserManagement'
[x] No open "ToDos" within the code or at least clearly explained comments why they exist...
[x] "Version" key in app manifest was updated following semantic versioning (and use '0.x.y' for test / experimental modules which are not yet ready to be officially released)
[x] Meaningful IDs used for UI elements
[x] Module was tested on an AppSpace device (at least on SICK AppEngine) with no error message
[x] README.md is up to date (incl. info of device + firmware the module was tested with)
[x] CHANGELOG.md is up to date

Thx for the review!


Transition to SBT

Think it'll be good to use SBT cause it's more popular amongst Scala programmers.
SBT is having trouble finding org.apache.spark.sql.QueryTest and import org.apache.spark.sql.test.SharedSparkSession.

What needs to be added to the build.sbt file to access those classes?

let me try fix that and bring CI alive

lgtm. merged to master

libraryDependencies += "org.apache.spark" %% "spark-core" % sparkVersion % "test" classifier "tests"
libraryDependencies +=
  "org.apache.spark" %% "spark-catalyst" % sparkVersion % "test" classifier "tests"
libraryDependencies += "org.apache.spark" %% "spark-sql" % sparkVersion % "test" classifier "tests"
libraryDependencies += "org.apache.spark" %% "spark-hive" % sparkVersion % "test" classifier "tests"

is missing


[release-4.4] Bug 1817318: Fix bug in strategy name validation

This backports a critical fix from https://github.com/openshift/cluster-kube-descheduler-operator/pull/100, which allows the documented upstream strategy names to be set in the operator.
It also includes the update from https://github.com/openshift/cluster-kube-descheduler-operator/pull/102, which is a minor change but switches the default operand image to v0.10.0, which also includes some critical bugfixes.

/bugzilla refresh

/bugzilla refresh

/assign @ingvagabund
please lgtm

/lgtm


front-camera mirroring

   Hello thanks for the library, it works just fine.  I can open a PR if you are open to contributions. Thank you

hi, thanks for your interest.
sure I am open


[Sample Onboard Request] Ingest custom API data into Microsoft 365 with a Microsoft Graph connector

Owner:
@waldekmastykarz @garrytrinder
ID:
gc-nodejs-typescript-food-catalog
Title:
Ingest custom API data into Microsoft 365 with a Microsoft Graph connector
Description:
This sample project uses Teams Toolkit for Visual Studio Code to simplify the process of creating a Microsoft Graph connector that ingests data from a custom API to Microsoft Graph. It provides an end to end example of creating the connector, ingesting content and refreshing the ingested content on a schedule. It also includes the simplified admin experience which means that admins can toggle the connector on and off from the Microsoft Teams admin center.
 We will get this merged by next Monday. @tecton

@MuyangAmigo @garrytrinder I've created a test ticket to verify the README of the sample. We'll update the progress in this issue.

Thanks @garrytrinder , the README file looks good to me, @tecton will help you merge and config this sample.

Thanks for the comments @hellyzh apologies for the inconvenience.

azure-functions-core-tools is in the package.json as a dev dependency so should be available on first run as the very first task is npm install. Did you have the core tools package installed globally before running the sample?
We think that this is a regression in the API as we are sending a result type template to Graph in the API call to create the connection, but we noticed that recently the result type was not being created. For context, the API call to create a connection is on the beta endpoint so is suspect to changes without warning. We will update the instructions to handle the new behaviour seen.
This is related to above, with no result type template being created, search uses a default template.
Yes this is correct. The app created by the sample is uploaded to the Teams Organisational App Store during F5, this is a requirement for the connector, therefore we don't side load the app for the developer.

Hi @garrytrinder, I've confirmed with @hellyzh that he can successfully run "F5" after installing "Azure Functions" extension. So, I would suggest adding it as a prerequisite. For point 2 and 3, please update the instructions in README or codes.
I'll continue the onboarding process.

Hi @garrytrinder, I've confirmed with @hellyzh that he can successfully run "F5" after installing "Azure Functions" extension. So, I would suggest adding it as a prerequisite. For point 2 and 3, please update the instructions in README or codes.
I'll continue the onboarding process.

Thanks for the update, good to know that there is a dependency on the extension. We have it listed in the extensions.json file, but will add to the pre-reqs.

@garrytrinder @MuyangAmigo @summzhan this sample has been added to the sample gallery of Teams Toolkit prerelease version.

Great news! Thank you for the update @tecton 👍

the sample onboarded successfully to TTK prerelease version, close the ticket.


Factor out linking rooms into it's own file

We currently create links in AccountServices.js, TimelineHander.js, HashtagHandler.js and Provisioner.js. The code to do so is near identical. This would really be suited to it's own file.

I stupidly left this on my PC which I won't have access to for 3 weeks, which means this will get delayed :weary:


SliverPersistentHeaderDelegate.build() overlapsContent - wrong value

The app below is just a CustomScrollView with three slivers:
1 - A pinned fixed height header defined with  _SliverStatusBarPaddingDelegate
2 - A pinned header defined with _SliverAppBarDelegate. Turns red when overlapsContent=true
3 - A SliverToBoxAdapter that contains a fixed height=1200 sized box.
During scrolling I expected sliver 2 to only be red when the sliver 3 scrolled behind it. It's always red because overlapsContent is almost always true. But it shouldn't be? The parameter isn't documented so I'm just guessing its meaning based on the way it's used by AppBar.
During scrolling the following exception appears intermittently. I'm afraid it can be difficult to reproduce.
I/flutter (31217): ══╡ EXCEPTION CAUGHT BY RENDERING LIBRARY ╞═════════════════════════════════════════════════════════
I/flutter (31217): The following assertion was thrown during performLayout():
I/flutter (31217): SliverGeometry has a layoutExtent that exceeds its paintExtent.
I/flutter (31217): The paintExtent is<PHONE_NUMBER>371303, but the layoutExtent is<PHONE_NUMBER>371304. Maybe you have
I/flutter (31217): fallen prey to floating point rounding errors, and should explicitly apply the min() or max()
I/flutter (31217): functions, or the clamp() method, to the layoutExtent?
I/flutter (31217): When the exception was thrown, this was the stack:
I/flutter (31217): #0      SliverGeometry.debugAssertIsValid.<anonymous closure> (package:flutter/src/rendering/sliver.dart:461:9)
I/flutter (31217): #2      SliverGeometry.debugAssertIsValid (package:flutter/src/rendering/sliver.dart:459:12)
I/flutter (31217): #3      RenderSliver.debugAssertDoesMeetConstraints (package:flutter/src/rendering/sliver.dart:693:21)
I/flutter (31217): #4      RenderObject.layout.<anonymous closure> (package:flutter/src/rendering/object.dart:1750:19)
I/flutter (31217): #6      RenderObject.layout (package:flutter/src/rendering/object.dart:1750:14)
I/flutter (31217): #7      RenderViewportBase2.layoutOneSide (package:flutter/src/rendering/sliver.dart:1223:13)
I/flutter (31217): #8      RenderViewport2._attemptLayout (package:flutter/src/rendering/sliver.dart:1712:12)
I/flutter (31217): #9      RenderViewport2.performLayout (package:flutter/src/rendering/sliver.dart:1641:20)
I/flutter (31217): #10     RenderObject._layoutWithoutResize (package:flutter/src/rendering/object.dart:1624:7)
I/flutter (31217): #11     PipelineOwner.flushLayout (package:flutter/src/rendering/object.dart:953:18)
I/flutter (31217): #12     BindingBase&SchedulerBinding&GestureBinding&ServicesBinding&RendererBinding.beginFrame (package:flutter/src/rendering/binding.dart:223:19)
I/flutter (31217): #13     BindingBase&SchedulerBinding&GestureBinding&ServicesBinding&RendererBinding&WidgetsBinding.beginFrame (package:flutter/src/widgets/binding.dart:333:23)
I/flutter (31217): #14     BindingBase&SchedulerBinding&GestureBinding&ServicesBinding&RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:168:5)
I/flutter (31217): #15     BindingBase&SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:676:15)
I/flutter (31217): #16     BindingBase&SchedulerBinding.handleBeginFrame (package:flutter/src/scheduler/binding.dart:611:9)
I/flutter (31217): #17     _beginFrame (file:///b/build/slave/Linux_Engine/build/src/flutter/lib/ui/hooks.dart:83)
I/flutter (31217): (elided 2 frames from class _AssertionError)
I/flutter (31217): The following RenderObject was being processed when the exception was fired:
I/flutter (31217):   _RenderSliverPinnedPersistentHeaderForWidgets relayoutBoundary=up1
I/flutter (31217):   creator: _SliverPinnedPersistentHeader ← SliverPersistentHeader ← Viewport2 ←
I/flutter (31217):   IgnorePointer-[GlobalKey 703668342] ← Listener ← _GestureSemantics ←
I/flutter (31217):   RawGestureDetector-[LabeledGlobalKey<RawGestureDetectorState> 323752371] ← RepaintBoundary ←
I/flutter (31217):   CustomPaint ← RepaintBoundary ← NotificationListener<ScrollNotification2> ←
I/flutter (31217):   GlowingOverscrollIndicator ← ⋯
I/flutter (31217):   parentData: paintOffset=Offset(0.0, 0.0)
I/flutter (31217):   constraints: SliverConstraints(AxisDirection.down, GrowthDirection.forward,
I/flutter (31217):   ScrollDirection.reverse, scrollOffset: 36.6, remainingPaintExtent: 592.0, overlap: 25.0,
I/flutter (31217):   crossAxisExtent: 360.0viewportMainAxisExtent: 592.0)
I/flutter (31217):   geometry: SliverGeometry(scrollExtent: 567.0, paintExtent: 530.4, layoutExtent: 530.4,
I/flutter (31217):   maxPaintExtent: 592.0, hasVisualOverflow: true, scrollOffsetCorrection: 0.0)
I/flutter (31217):   maxExtent: 567.0
I/flutter (31217):   child position: 25.0
I/flutter (31217): This RenderObject had the following descendants (showing up to depth 5):
I/flutter (31217):   RenderConstrainedBox relayoutBoundary=up2
I/flutter (31217):     RenderDecoratedBox
I/flutter (31217):       RenderPadding
I/flutter (31217):         RenderCustomPaint
I/flutter (31217): ════════════════════════════════════════════════════════════════════════════════════════════════════
I/flutter (31217): Another exception was thrown: SliverGeometry has a layoutExtent that exceeds its paintExtent.
I/flutter (31217): Another exception was thrown: SliverGeometry has a layoutExtent that exceeds its paintExtent.
I/flutter (31217): Another exception was thrown: SliverGeometry has a layoutExtent that exceeds its paintExtent.

import 'dart:math' as math;

import 'package:flutter/material.dart';

class PlaceholderPainter extends CustomPainter {
  void paint(Canvas canvas, Size size) {
    Paint paint = new Paint()
      ..color = Colors.white
      ..style = PaintingStyle.stroke
      ..strokeWidth = 1.0;
    canvas.drawLine(Point.origin, new Point(size.width, size.height), paint);
    canvas.drawLine(new Point(size.width, 0.0), new Point(0.0, size.height), paint);
  }

  bool shouldRepaint(_) => false;
}

// Renders a colored bordered box with an X that extends to the corners.
class Placeholder extends StatelessWidget {
  Placeholder({ @required this.colors }) {
    assert(colors != null);
  }

  final Map<int, Color> colors;

  @override
  Widget build(BuildContext context) {
    return new Container (
      decoration: new BoxDecoration(
        backgroundColor: colors[400],
        border: new Border.all(color: colors[200], width: 3.0),
      ),
      child: new CustomPaint(painter: new PlaceholderPainter()),
    );
  }
}

class _SliverStatusBarPaddingDelegate extends SliverPersistentHeaderDelegate {
  _SliverStatusBarPaddingDelegate({ @required this.height });

  final double height;

  @override double get minExtent => height;
  @override double get maxExtent => height;

  @override
  Widget build(BuildContext context, double shrinkOffset, bool overlapsContent) {
    return new SizedBox.expand(
      child: new Placeholder(colors: Colors.orange),
    );
  }

  @override
  bool shouldRebuild(@checked _SliverStatusBarPaddingDelegate oldDelegate) {
    return height != oldDelegate.height;
  }
}

class _SliverAppBarDelegate extends SliverPersistentHeaderDelegate {
  _SliverAppBarDelegate({
    @required this.collapsedHeight,
    @required this.expandedHeight,
  });

  final double expandedHeight;
  final double collapsedHeight;

  @override double get minExtent => collapsedHeight;
  @override double get maxExtent => math.max(expandedHeight, minExtent);

  @override
  Widget build(BuildContext context, double shrinkOffset, bool overlapsContent) {
    return new SizedBox.expand(
      child: new Placeholder(colors: overlapsContent ? Colors.red : Colors.teal),
    );
  }

  @override
  bool shouldRebuild(@checked _SliverAppBarDelegate oldDelegate) {
    return expandedHeight != oldDelegate.expandedHeight
        || collapsedHeight != oldDelegate.collapsedHeight;
  }
}

class SliverIssue extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final MediaQueryData mediaQueryData = MediaQuery.of(context);
    final double statusBarHeight = mediaQueryData.padding.top;
    final double screenHeight = mediaQueryData.size.height;

    return new CustomScrollView(
      slivers: <Widget>[
        new SliverPersistentHeader(
          pinned: true,
          delegate: new _SliverStatusBarPaddingDelegate(
            height: statusBarHeight,
          ),
        ),
        new SliverPersistentHeader(
          pinned: true,
          delegate: new _SliverAppBarDelegate(
            expandedHeight: screenHeight - statusBarHeight,
            collapsedHeight: 200.0,
          ),
        ),
        new SliverToBoxAdapter(
          child: new SizedBox(
            height: 1200.0,
            child: new Placeholder(colors: Colors.blue),
          ),
        ),
      ],
    );
  }
}

void main() {
  runApp(new MaterialApp(home: new SliverIssue()));
}

I recommend trying to make a unit test that reproduces the error reliably, and then reducing it until it's got the fewest slivers needed for reproduction.

Moving this out to beyond m3 since it doesn't currently fit our priorities, but it is something we will fix in due course. Please let us know if this is a priority for you and you can't work around it.

/cc @chunhtai Did you by any chance fix this with one of your floating point fixes?

I cannot reproduce, it is probably fixed


Error when building for armv6

Forwarding this issue. Original is here: https://github.com/purpleprotocol/mimalloc_rust/issues/91
This is the build error:
#0 331.7 error: linking with `arm-linux-gnueabihf-ld` failed: exit status: 1
#0 331.7   |
#0 331.7   = note: LC_ALL="C" PATH="/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/self-contained:/usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "arm-linux-gnueabihf-ld" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crti.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtbegin.o" "/tmp/rustcTnL0FL/symbols.o" "/build/target/arm-unknown-linux-musleabihf/release_optimized/deps/atrium-9d7c42d4a7254134.atrium.436a5141-cgu.0.rcgu.o" "--as-needed" "-L" "/build/target/arm-unknown-linux-musleabihf/release_optimized/deps" "-L" "/build/target/release_optimized/deps" "-L" "/build/target/arm-unknown-linux-musleabihf/release_optimized/build/ring-f953b60540da6b61/out" "-L" "/build/target/arm-unknown-linux-musleabihf/release_optimized/build/libmimalloc-sys-7044e007f4223565/out" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-Bstatic" "/tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib" "/tmp/rustcTnL0FL/libring-61e880a3b28c0c72.rlib" "-lunwind" "-lc" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcompiler_builtins-eb461ae3a10c4720.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained" "-o" "/build/target/arm-unknown-linux-musleabihf/release_optimized/deps/atrium-9d7c42d4a7254134" "--gc-sections" "-static" "-zrelro" "-znow" "-O1" "--strip-all" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtend.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtn.o"
#0 331.7   = note: arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `mi_stat_add.constprop.0':
#0 331.7           static.c:(.text.mi_stat_add.constprop.0+0x3c): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_stat_add.constprop.0+0x4c): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_stat_add.constprop.0+0x5c): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_stat_add.constprop.0+0x6c): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `mi_stats_add.constprop.0':
#0 331.7           static.c:(.text.mi_stats_add.constprop.0+0xe4): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o):static.c:(.text.mi_stats_add.constprop.0+0xf4): more undefined references to `__atomic_fetch_add_8' follow
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `_mi_stat_increase':
#0 331.7           static.c:(.text._mi_stat_increase+0xc0): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text._mi_stat_increase+0xec): undefined reference to `__atomic_compare_exchange_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text._mi_stat_increase+0x108): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `_mi_stat_decrease':
#0 331.7           static.c:(.text._mi_stat_decrease+0xa8): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text._mi_stat_decrease+0xd0): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text._mi_stat_decrease+0xfc): undefined reference to `__atomic_compare_exchange_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text._mi_stat_decrease+0x118): undefined reference to `__atomic_fetch_add_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `mi_process_info':
#0 331.7           static.c:(.text.mi_process_info+0x60): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_process_info+0x70): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `mi_segment_cache_purge.constprop.0':
#0 331.7           static.c:(.text.mi_segment_cache_purge.constprop.0+0xc4): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_segment_cache_purge.constprop.0+0x128): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_segment_cache_purge.constprop.0+0x17c): undefined reference to `__atomic_store_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `mi_segment_cache_purge.constprop.1':
#0 331.7           static.c:(.text.mi_segment_cache_purge.constprop.1+0x70): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_segment_cache_purge.constprop.1+0xc0): undefined reference to `__atomic_load_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text.mi_segment_cache_purge.constprop.1+0x110): undefined reference to `__atomic_store_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `mi_segment_cache_pop_ex':
#0 331.7           static.c:(.text.mi_segment_cache_pop_ex+0x118): undefined reference to `__atomic_store_8'
#0 331.7           arm-linux-gnueabihf-ld: /tmp/rustcTnL0FL/liblibmimalloc_sys-868a4ff9e7af301d.rlib(static.o): in function `_mi_segment_cache_push':
#0 331.7           static.c:(.text._mi_segment_cache_push+0xec): undefined reference to `__atomic_store_8'
#0 331.7           arm-linux-gnueabihf-ld: static.c:(.text._mi_segment_cache_push+0x23c): undefined reference to `__atomic_store_8'
#0 331.7
#0 331.7   = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
#0 331.7   = note: use the `-l` flag to specify native libraries to link
#0 331.7   = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

Ah, it looks like it cannot find the atomic functions?
Can you try to use the -DMI_USE_LIBATOMIC=ON flag to cmake to see if this solves the issue?
(the cmake should detect automatically if -latomic is needed but it seems to fail here? is it due to musl ?)

@nicolaspernoud

I can try, where do I need to put the flag ? Somewhere un the cargo build command ?

if you mean the libmimalloc-sys/build.rs then yes.

Well, that is very strange, as trying to isolate the problem gives another error... both for armv6 and arm64 (arm64 used to work).
Using that Dockerfile :
FROM rust:1.68
RUN rustup target add arm-unknown-linux-musleabihf
RUN apt update && apt install -y musl-tools musl-dev binutils-arm-linux-gnueabihf gcc-arm-linux-gnueabihf gcc-aarch64-linux-gnu libcap2-bin
RUN ln -s /usr/bin/arm-linux-gnueabihf-gcc /usr/bin/arm-linux-musleabihf-gcc
RUN ln -s /usr/bin/aarch64-linux-gnu-gcc /usr/bin/aarch64-linux-musl-gcc

WORKDIR /build

COPY . .

RUN cargo build --release --target arm-unknown-linux-musleabihf

It works when building the Mimalloc Rust crate directly, but not when building the simplest example application with :

Cargo.toml :

[package]
name = "mimalloc_test"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
mimalloc = "0.1"

main.rs :

use mimalloc::MiMalloc;

#[global_allocator]
static GLOBAL: MiMalloc = MiMalloc;

fn main() {
    let _s = String::from("TEST");
    println!("Hello, world!");
}

The error is then :
 > [8/8] RUN cargo build --release --target arm-unknown-linux-musleabihf:
#0 0.662     Updating crates.io index
#0 60.34  Downloading crates ...
#0 60.53   Downloaded mimalloc v0.1.36
#0 60.54   Downloaded cc v1.0.79
#0 60.55   Downloaded libc v0.2.141
#0 60.61   Downloaded libmimalloc-sys v0.1.32
#0 60.73    Compiling cc v1.0.79
#0 60.73    Compiling libc v0.2.141
#0 61.49    Compiling libmimalloc-sys v0.1.32
#0 64.25    Compiling mimalloc v0.1.36
#0 64.37    Compiling mimalloc_test v0.1.0 (/build)
#0 64.53 error: linking with `cc` failed: exit status: 1
#0 64.53   |
#0 64.53   = note: LC_ALL="C" PATH="/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/self-contained:/usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "cc" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crti.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtbegin.o" "/tmp/rustcDVTz23/symbols.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.0.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.1.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.2.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.3.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.4.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.5.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.6.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.mimalloc_test.ec68869b-cgu.7.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567.5f9bw7r2pmjbtmj8.rcgu.o" "-Wl,--as-needed" "-L" "/build/target/arm-unknown-linux-musleabihf/release/deps" "-L" "/build/target/release/deps" "-L" "/build/target/arm-unknown-linux-musleabihf/release/build/libmimalloc-sys-b7fd4f6c2fed1648/out" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-Wl,-Bstatic" "/build/target/arm-unknown-linux-musleabihf/release/deps/libmimalloc-42b3f935fd55b22f.rlib" "/build/target/arm-unknown-linux-musleabihf/release/deps/liblibmimalloc_sys-f583ddf93b4852e5.rlib" "/build/target/arm-unknown-linux-musleabihf/release/deps/liblibc-8cbac95de92d3f8a.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libstd-156f4170e33b8df4.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libpanic_unwind-e270422b4fca28e3.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libobject-49cd4b382f505f9d.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libmemchr-eed355165f4866e0.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libaddr2line-7e4a417a98d3e1fb.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libgimli-19ab14456ef67ec3.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_demangle-94668fbad859bad0.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libstd_detect-ddbf1f9293a44a9c.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libhashbrown-fac09f5d7f857f6b.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libminiz_oxide-f840348d8fb3422c.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libadler-f7fa56e66eb13c9f.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_std_workspace_alloc-9cb6dfec2a561167.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libunwind-b9f2e553466d47cf.rlib" "-lunwind" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcfg_if-fc80282540c648fb.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/liblibc-9f5698308f331dfe.rlib" "-lc" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/liballoc-5cb9b7f1b32dd35b.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_std_workspace_core-b2b48d67f7264a3c.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcore-21361f74a01c8c9e.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcompiler_builtins-eb461ae3a10c4720.rlib" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-nostartfiles" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained" "-o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-1028ca129bacc567" "-Wl,--gc-sections" "-static" "-no-pie" "-Wl,-zrelro,-znow" "-Wl,-O1" "-nodefaultlibs" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtend.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtn.o"
#0 64.53   = note: /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 64.53           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: error adding symbols: file in wrong format
#0 64.53           collect2: error: ld returned 1 exit status
#0 64.53
#0 64.53
#0 64.53 error: could not compile `mimalloc_test` due to previous error
------
Dockerfile:11
--------------------
   9 |     COPY . .
  10 |
  11 | >>> RUN cargo build --release --target arm-unknown-linux-musleabihf
--------------------
ERROR: failed to solve: process "/bin/sh -c cargo build --release --target arm-unknown-linux-musleabihf" did not complete successfully: exit code: 101

ah, that looks like a strange error; not sure if this comes from mimalloc?
It may have been resolved with pr  #724 which may have caused a link error?  (latest dev/dev-slice include this patch).

Well, with forcing mimalloc to latest dev-slice, that gives the following error :
 > [8/8] RUN cargo build --release --target arm-unknown-linux-musleabihf:
#0 0.603     Updating crates.io index
#0 33.13  Downloading crates ...
#0 33.46   Downloaded cc v1.0.79
#0 33.96   Downloaded libc v0.2.141
#0 34.24    Compiling libc v0.2.141
#0 34.24    Compiling cc v1.0.79
#0 35.06    Compiling libmimalloc-sys v0.1.32 (/build/mimalloc_rust/libmimalloc-sys)
#0 38.03 warning: In file included from c_src/mimalloc/src/static.c:17:
#0 38.03 warning: c_src/mimalloc/include/mimalloc/internal.h: In function '_mi_ptr_segment':
#0 38.03 warning: c_src/mimalloc/include/mimalloc/internal.h:405:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#0 38.03 warning:   405 |   return (mi_segment_t*)(((uintptr_t)p - 1) & ~MI_SEGMENT_MASK);
#0 38.03 warning:       |          ^
#0 38.03 warning: In file included from c_src/mimalloc/src/static.c:34:
#0 38.03 warning: c_src/mimalloc/src/segment.c: In function 'mi_tagged_segment_ptr':
#0 38.03 warning: c_src/mimalloc/src/segment.c:1093:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#0 38.03 warning:  1093 |   return (mi_segment_t*)(ts & ~MI_TAGGED_MASK);
#0 38.03 warning:       |          ^
#0 38.08    Compiling mimalloc v0.1.36 (/build/mimalloc_rust)
#0 38.18    Compiling mimalloc_test v0.1.0 (/build)
#0 38.29 error: linking with `cc` failed: exit status: 1
#0 38.29   |
#0 38.29   = note: LC_ALL="C" PATH="/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/self-contained:/usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "cc" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crti.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtbegin.o" "/tmp/rustc0SWveE/symbols.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.0.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.1.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.2.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.3.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.4.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.5.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.6.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.mimalloc_test.739a7403-cgu.7.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550.2i187zytaey0c0xg.rcgu.o" "-Wl,--as-needed" "-L" "/build/target/arm-unknown-linux-musleabihf/release/deps" "-L" "/build/target/release/deps" "-L" "/build/target/arm-unknown-linux-musleabihf/release/build/libmimalloc-sys-48f2dfc53239e631/out" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-Wl,-Bstatic" "/build/target/arm-unknown-linux-musleabihf/release/deps/libmimalloc-fc3b7fa423938021.rlib" "/build/target/arm-unknown-linux-musleabihf/release/deps/liblibmimalloc_sys-58b883546b14cc14.rlib" "/build/target/arm-unknown-linux-musleabihf/release/deps/liblibc-8cbac95de92d3f8a.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libstd-156f4170e33b8df4.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libpanic_unwind-e270422b4fca28e3.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libobject-49cd4b382f505f9d.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libmemchr-eed355165f4866e0.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libaddr2line-7e4a417a98d3e1fb.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libgimli-19ab14456ef67ec3.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_demangle-94668fbad859bad0.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libstd_detect-ddbf1f9293a44a9c.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libhashbrown-fac09f5d7f857f6b.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libminiz_oxide-f840348d8fb3422c.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libadler-f7fa56e66eb13c9f.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_std_workspace_alloc-9cb6dfec2a561167.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libunwind-b9f2e553466d47cf.rlib" "-lunwind" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcfg_if-fc80282540c648fb.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/liblibc-9f5698308f331dfe.rlib" "-lc" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/liballoc-5cb9b7f1b32dd35b.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_std_workspace_core-b2b48d67f7264a3c.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcore-21361f74a01c8c9e.rlib" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcompiler_builtins-eb461ae3a10c4720.rlib" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-nostartfiles" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-L" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained" "-o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-15d4fed50dc5c550" "-Wl,--gc-sections" "-static" "-no-pie" "-Wl,-zrelro,-znow" "-Wl,-O1" "-nodefaultlibs" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtend.o" "/usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtn.o"
#0 38.29   = note: /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 38.29           /usr/bin/ld: /usr/local/rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: error adding symbols: file in wrong format
#0 38.29           collect2: error: ld returned 1 exit status
#0 38.29
#0 38.29
#0 38.30 error: could not compile `mimalloc_test` due to previous error

@daanx Rust uses the C abi and C++ is always invoked through a C layer so cmake is not used. The native gcc compiler is invoked through the build file

Does the latest release fix the build issue?

@daanx Compiles on musl: https://github.com/purpleprotocol/purplecoin/actions/runs/4801721022/jobs/8544297845

Using mimalloc = "0.1.37", I still have the linking issue :
 > [8/8] RUN cargo build --release --target arm-unknown-linux-musleabihf:
#0 6.479     Updating crates.io index
#0 84.56  Downloading crates ...
#0 85.10   Downloaded libc v0.2.141
#0 85.18   Downloaded mimalloc v0.1.37
#0 85.18   Downloaded libmimalloc-sys v0.1.33
#0 85.40   Downloaded cc v1.0.79
#0 85.58    Compiling libc v0.2.141
#0 85.58    Compiling cc v1.0.79
#0 87.28    Compiling libmimalloc-sys v0.1.33
#0 92.96    Compiling mimalloc v0.1.37
#0 93.12    Compiling mimalloc_test v0.1.0 (/build)
#0 93.31 error: linking with `cc` failed: exit status: 1
#0 93.31   |
#0 93.31   = note: LC_ALL="C" PATH="/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/self-contained:/usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "cc" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crti.o" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtbegin.o" "/tmp/rustcwBHKjU/symbols.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.0.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.1.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.2.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.3.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.4.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.5.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.6.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.mimalloc_test.20080a45-cgu.7.rcgu.o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581.ssojj11ycp7gnke.rcgu.o" "-Wl,--as-needed" "-L" "/build/target/arm-unknown-linux-musleabihf/release/deps" "-L" "/build/target/release/deps" "-L" "/build/target/arm-unknown-linux-musleabihf/release/build/libmimalloc-sys-a0485197edb752df/out" "-L" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-Wl,-Bstatic" "/build/target/arm-unknown-linux-musleabihf/release/deps/libmimalloc-ea0159e9580ea75a.rlib" "/build/target/arm-unknown-linux-musleabihf/release/deps/liblibmimalloc_sys-e3ce8485e44d8658.rlib" "/build/target/arm-unknown-linux-musleabihf/release/deps/liblibc-1d35e53f1586ef64.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libstd-fbbd886251fe1a89.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libpanic_unwind-1bd35c941b382326.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libobject-20ab481ab8e3f957.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libmemchr-6d5fa66af62812db.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libaddr2line-c5d7090aa83583f0.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libgimli-e7814b2b78a60b29.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_demangle-f416c52974a5b58b.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libstd_detect-36d61d6924dae007.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libhashbrown-75360821ed2ae48e.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libminiz_oxide-01f71d17d25e0689.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libadler-07396f3249a0ab27.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_std_workspace_alloc-1023e934ee76baba.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libunwind-69a54df3a7ca128a.rlib" "-lunwind" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcfg_if-0f0cb69d8bf032e0.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/liblibc-eb499cd33737ec75.rlib" "-lc" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/liballoc-04652832e0f93b15.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/librustc_std_workspace_core-43de1fa801649533.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcore-9688301b6972aad9.rlib" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/libcompiler_builtins-8de29b66878012ac.rlib" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-nostartfiles" "-L" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib" "-L" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained" "-o" "/build/target/arm-unknown-linux-musleabihf/release/deps/mimalloc_test-0dd013925a891581" "-Wl,--gc-sections" "-static" "-no-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtend.o" "/usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crtn.o"
#0 93.31   = note: /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: relocations in generic ELF (EM: 40)
#0 93.31           /usr/bin/ld: /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: error adding symbols: file in wrong format
#0 93.31           collect2: error: ld returned 1 exit status
#0 93.31
#0 93.31
#0 93.33 error: could not compile `mimalloc_test` due to previous error

Ah strange. But given the error I believe this is not a mimalloc issue. If we see this post it seems a cross compilation issue to me in the build files. I see the build command invokes "cc" for example, shouldn't that be "$CC" ?   I am guessing one of the .o files has been compiled not for armv6 or musl  (but x86_64 or glibc) and that causes trouble later on. Maybe it is found in one of the paths, likes /usr/local before it looks at /usr/sbin or something?   Maybe you can use obj dump or nm to see if any of the linked .o/.a files has been build for another platform?

I just made a gist with the code : . It is possible to git clone it with git clone https://gist.github.com/a1400af7d11ae4fd52d2de23b49e07bd.git and to run test.sh  to get the results.
objdump gives the following result with /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o:
file format elf32-little
architecture: UNKNOWN!, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
It seems that it is ARM !?

I just made a gist with the code : . It is possible to git clone it with git clone https://gist.github.com/a1400af7d11ae4fd52d2de23b49e07bd.git and to run test.sh to get the results.
objdump gives the following result with /usr/local/rustup/toolchains/1.69.0-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-musleabihf/lib/self-contained/crt1.o: file format elf32-little architecture: UNKNOWN!, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000
It seems that it is ARM !?

The error message makes it pretty clear that it is attempting to link using ld. ld is not able to link for any architecture other than the one it is built for. If you want to actually link ARMv6 objects on x86_64, you will have to use a cross-compiled ld or simply the LLVM lld, which is able to handle all architectures that LLVM supports.
To use a linker capable of handling ARMv6, you can e.g. just tell it to use your gcc by adding .cargo/config.toml:
[target.arm-unknown-linux-musleabihf]
linker = "arm-linux-musleabihf-gcc"

Which will make it compile further and fail with the same atomic errors.


cmd/compile, cmd/cgo: cgo callback fails with MSAN when passing aggregate args with paddings

What version of Go are you using (go version)?
tip (e8de596f04)
Does this issue reproduce with the latest release?
No. This starts to happen since cgo callback changes (CL 258938).
What operating system and processor architecture are you using (go env)?
linux/amd64
What did you do?
Build the following program using MSAN, where it calls from C to Go passing a C struct with padding.
x.go
package main

// Test passing C struct to exported Go function.

/*
#include <stdint.h>

typedef struct { uintptr_t x, y; char b; } T;

void CF(int x);
*/
import "C"

//export F
func F(t C.T) { println(t.x, t.y, t.b) }

func main() {
	C.CF(C.int(0))
}

x.c
#include <stdint.h>
#include <stdlib.h>

typedef struct { uintptr_t x, y; char b; } T;

extern void F(T);

void CF(int x) {
	T *t = malloc(sizeof(T));
	t->x = x;
	t->y = x;
	t->b = (char)x;
	F(*t);
}

What did you expect to see?
Program runs okay, prints 0 0 0.
What did you see instead?
$ CC=clang go build -msan .
$ ./x
Uninitialized bytes in __msan_check_mem_is_initialized at offset 17 inside [0x7fff51f33f00, 24)
==893435==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4f5368 in msancall /usr/local/google/home/cherryyz/src/go-tip/src/runtime/msan_amd64.s:78

SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/google/home/cherryyz/src/go-tip/src/runtime/msan_amd64.s:78 in msancall
Exiting

Marking as a release blocker because this is a regression from 1.15.


AbstractMemoryHttpData performance issue when using composite buffer

Buffers appended to the AbstractMemoryHttpData are appended to a CompositeBuffer using "extendWith" method.
But it seems there is a performance issue with extendsWith method. Maybe the CompositeBuffer API is not used appropriately or maybe there is room for optimisation in the CompositeBuffer implementation, I don't know for the moment.
I'm attaching a benchmark which is reproducing the performance issue:
buffer.composite.benchmark.tgz
here are the results, where we can observe the performance issue:
Benchmark                               Mode  Cnt       Score   Error  Units
MyBenchmark.compositeBufferBenchmark   thrpt            14116.317          ops/s
MyBenchmark.compositeByteBufBenchmark  thrpt       153964.596          ops/s

we should check if the recent netty issue is fixing the performance issue when using composite extendWith method (see netty PR #12759).


Feat: back up entire way to backdrop BlueBackPixel.java

Just changed code so robot approaches backboard backwards, probable time save

@gwarby  this branch & Pull Request now includes changes from later during Tuesday's meeting.  Most of it are little tweaks to avoid the truss or not run over the pixel.  But notably, on BlueBack, we had to go back to dropping the pixel on the ground.  The in-air drop was keeping both pixels a majority of the time.


Add rate limit for s3 proxy

What changes are proposed in this pull request?
Add read limit for s3 proxy when getObject return files.
Why are the changes needed?
We use NVME to speed up reading algorithm model, but we find that the reading speed of alluxio is too fast and k8s container will consume a lot of network card resources, and then affect other containers of the same host, so we need to limit the reading speed.
Does this PR introduce any user facing changes?
Add two properties:

alluxio.proxy.s3.global.read.rate.limit.mb to limit all connections rate;
alluxio.proxy.s3.single.connection.read.rate.limit.mb to limit single connection rate.

Is there any command to rerun CI here?

can u also double check and make sure all integration tests all pass plz?

can u also double check and make sure all integration tests all pass plz?

Test failures are not related to my code, but I do not know how to rerun checks.

@jiacheliu3 can you help merge it?

alluxio-bot, merge this please


thread safety issue

https://github.com/capnm/godot4/actions/runs/6007026606/job/16292529462
See: https://github.com/thorvg/thorvg/pull/1622

Excerpt from current CI run https://github.com/capnm/godot4/actions/runs/6008956646/job/16297572488 :
WARNING: ThreadSanitizer: data race (pid=7060)
  Read of size 8 at 0x7b1000013b88 by thread T2:
    #0 std::vector<std::thread, std::allocator<std::thread> >::size() const /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40 (godot.linuxbsd.editor.dev.x86_64.llvm.san+0x56b1969)
    #1 tvg::TaskSchedulerImpl::run(unsigned int) /home/runner/work/godot4/godot4/thirdparty/thorvg/src/renderer/tvgTaskScheduler.cpp:134:46

https://github.com/thorvg/thorvg/blame/main/src/renderer/tvgTaskScheduler.cpp#L134

  Previous write of size 8 at 0x7b1000013b88 by main thread:
    #0 std::thread& std::vector<std::thread, std::allocator<std::thread> >::emplace_back<tvg::TaskSchedulerImpl::TaskSchedulerImpl(unsigned int)::'lambda'()>(tvg::TaskSchedulerImpl::TaskSchedulerImpl(unsigned int)::'lambda'()&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/vector.tcc:117:6 (godot.linuxbsd.editor.dev.x86_64.llvm.san+0x6f0b1d6)
    #1 tvg::TaskSchedulerImpl::TaskSchedulerImpl(unsigned int) /home/runner/work/godot4/godot4/thirdparty/thorvg/src/renderer/tvgTaskScheduler.cpp:117:21

https://github.com/thorvg/thorvg/blob/main/src/renderer/tvgTaskScheduler.cpp#L117

I couldn't trigger thread related issues running the Godot app.
TODO:

Godot gets  an error: ImageLoaderSVG: Couldn't draw ThorVG pictures on canvas
somewhere between 0.10.2 good  – 0.10.3  bad
https://github.com/thorvg/thorvg/compare/v0.10.2...v0.10.3

ThreadSanitizer data race in std::vector
77de62068ccfc2e1480888c1173258c5c71d7750 commit?
is it related to thread changes in 4.2?
See Multi-threaded Scene Processing in Godot 4.1+

I guess this patch could cause the problem.
77daecc764a0a8d59394fac7b3302b4ba53c80d4 (in v0.10.3)
Could you please revert only that patch and test?

Thanks for information.
I guess this patch could cause the problem.
77daecc764a0a8d59394fac7b3302b4ba53c80d4 (in v0.10.3)

    renderer task-scheduler: ++thread safety

    Currently, tasks are expected to be triggered from the main thread.
    This ensures preventing the popping of a thread from a worker thread.

    Previously, there was a potential deadlock problem...

Could you please revert only that patch?

Could you please revert only that patch?

Branch with 77daecc764a0a8d59394fac7b3302b4ba53c80d4 was deleted?

Oh ok. I found it also in main 8f9bdebd35ed269d305ccc9c0bd119f95ceaa585

https://github.com/thorvg/thorvg/commit/77de62068ccfc2e1480888c1173258c5c71d7750 obvisouly problem and i reverted. thanks!


GUI should scale in docs

Currently the GUI doesn't scale properly in the docs:

either it should be scaled or should occupy a wider area of the screen ... so users don't have to scroll to see the full GUI

I'm labeling issues @chenghuzi for the GUI so you can get to them when you are bored with writing the tutorial

This is due to the constraint in the notebook level. Not sure if we can bypass this but I'll try

If you can scale it according to the space available (instead of hardcoding pixel size), would it work? You can even have a visualization layout option that has only one plot ... and it can be the default


Post does not inherit proper Subreddit when made

Steps to Reproduce:
1, Get a Subreddit object via RedditSharp.GetSubredditAsync(), assign to sub
2. Create a post using sub.SubmitPostAsync(), assign to post
3. Set the post flair using post.SetFlairAsync().
Expected Result: The post should be flaired.
Actual Result: The post is not flaired due to a web exception.
This last step will 404, here's a Fiddler screenshot which shows why:

It appears the SubredditName field is not set based on line 25 in Post.cs.

I think this is due to what data is actually returned from the API. Probably an enhancement to add that info in from the previous call after populating the Post object.

I figured this was the case after looking at the JSON response from Reddit. I could potentially add this myself, however what would be the best way to implement this that still conforms to the style that has been set up? Would it be too messy to change the Init() for a post to include an (optional) Subreddit parameter and then edit the Subreddit's SubmitAsync methods to pass this to Init?

I wouldn't pass it as a parameter to the init, I'd just change it in the Subreddit's SubmitAsync method to modify the Post object before it is returned.

This bug still exists. I worked around it in the past by setting the subreddit name manually in the Post object. But you can't do that anymore because the SubredditName property in the Post object is private set. I am working around it by building my own RS and making the set public.


translation for gear up for success challenge

closes #4541

@MEXshredder why did you open a new PR?Seems you've fixed all suggestions here https://github.com/FreeCodeCamp/FreeCodeCamp/pull/4984.

OK, your PRs are identical so I'll merge this one, thanks!.
If you need to correct something in your PR you can read about that in this article: How To Create A Pull Request for Free Code Camp.


Update text in 'Add volume', 'Edit volume metadata' modals

📝 Description
Update various texts in Add volume, Edit volume metadata modals:
In Add volume modal, accessible from both Bootable volumes list and Catalog > InstanceTypes, change the following:

Clone existing PVC checkbox popover text to: "This will create a cloned copy of the PVC in the destination project."
add HelpIcon with popover text to Volume metadata: "Set the volume metadata to use the volume as a bootable image."
update Preference popover text by adding "Read more" external link to:
https://kubevirt.io/user-guide/virtual_machines/instancetypes/#virtualmachinepreference

In Edit volume metadata accessible from Bootable volumes list, change the following:

update Preference popover text to "The preferred VirtualMachine attribute values required to run a given workload."
and add "Read more" external link (same as in Add volume modal)
change Default InstanceType popover text to: "The default InstanceType for this volume."

Also update the text of Delete button (accessible from Bootable volumes list) to:
"Only the bootable metadata will be deleted"
Make these all updates according to the last design changes and consistency reasons.
Related design docs:
https://docs.google.com/document/d/1HTF6_H2WDXwlVy7RnrHH28dzFlhNIa15Hhpeoyg2R0Q/edit#heading=h.xt31tt3xq1x
https://docs.google.com/document/d/15Cv54978AZKeukkurvkFN1YEx_kBsm_3XcmLey_cgZY/edit#heading=h.5tnevt9lwj7z
🎥 Screenshots
Before:
Clone existing PVC checkbox popover text:

Preference popover text and no any popover text or "?" icon for Volume metadata:

Edit volume metadata modal:

Delete button in Bootable volumes list:

After:
Clone existing PVC checkbox popover text:

Updated  Preference popover text:

Added popover text with "?" icon for Volume metadata:

Edit volume metadata modal:

Delete button in Bootable volumes list:

@avivtur @metalice @pcbailey @upalatucci @vojtechszocs please review

/lgtm

/hold cancel

/lgtm


How to add edge features to the model DMoN?

Dear Mr. @eladeban, I would like to follow your unsupervised algorithm DMoN from the Repo, but found that it only supports node feature inputs. Does the model support modification to support input of edge features for learning. As from our data perspective, both edge and node features are critical. Really appreciate your work!

Hi Jo,
This is actually not my code, my name there only appears for
technical reasons. Please refer to this
https://github.com/google-research/google-research/tree/master/graph_embedding/dmon#readme
page for authors .
Elad
On Wed, Apr 21, 2021 at 2:41 AM Jo Richards✅ @.***>
wrote:

Dear Mr. @eladeban https://github.com/eladeban, I would like to follow
your unsupervised algorithm DMoN from the Repo
https://github.com/google-research/google-research/tree/master/graph_embedding/dmon,
but found that it only supports node feature inputs. Does the model support
modification to support input of edge features for learning. As from
our data perspective, both edge and node features are critical. Really
appreciate your work!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google-research/google-research/issues/678, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AJTI4NRTGGFFHIXSJHXXLGLTJ2MTRANCNFSM43J7UIUQ
.

--
Elad Eban  |  Research Scientist  |  @.*** |  go/reModel

Thank you all the same.


Figure out why Dot Highlight on DataSources page isn't working

So when we select the dots in the violin plots in the FeatureSets page it works fine, for some reason not working on DataSources page.

Turned out to be an issue with the log throttle, fixed.


Out of Memory Error

Describe the bug
Caveat- This may or may not be a bug but please read
I constantly get an out of memory error and cannot find anyway to reduce batch size. I have an RTX 4090 with 24GB of GPU memory. The task manager is saying it is using all of the memory, which is why I say this may not be a bug. However, I am using Ubuntu in WSL2, which could be causing it to not understand how much ram is available to allocate. Hard to debug without being able to change batch sizes.
Code:
from super_image import EdsrModel, ImageLoader
from PIL import Image
from PIL import Image
import requests
import torch
device = torch.device("cuda")
print(torch.cuda.is_available()) #It is True
img = Image.open('./IMG_5195.jpeg') #this is a 2.4MB jpeg
model = EdsrModel.from_pretrained('eugenesiow/edsr-base', scale=2)
model = model.to(device)
inputs = ImageLoader.load_image(img)
preds = model(inputs.to(device))
Screenshots

Image 5195 that I'm trying to upscale

Python version: [3.10.12]
OS: Ubuntu on WSL2

Not a bug. Image size was too large. Used GIMP to slice it into pieces and it worked


Edit Row does not maintain alignment.

CSS styles bug.
When values are set to not editable they become center aligned during an edit operation instead of maintaining the alignment set by the field type. It's unavoidable for the form items to be left aligned but non-editable fields should maintain alignment.
Example: https://www.evernote.com/l/AlgFDoiOxg1HNIbs0NRHF_A7TIZRH6KSaOE

I see the issue, but have no idea how it could be improved.
Currently, all fields in edit row are aligned at the center. This makes inputs/selects nicely centered.
If we will provide the align from the data cell to edit cell, inputs/selects will be aligned not at center (possible right or left). This won't look good. Moreover it's a breaking change, which will break the appearance after jsgrid update. So the problem is: no way to distinguish an edit cell with input inside and just a plain text.
Do you have any idea how it could be fixed?

I see the issue, but have no idea how it could be improved.
Currently, all fields in edit row are aligned at the center. This makes inputs/selects nicely centered.
If we will provide the align from the data cell to edit cell, inputs/selects will be aligned not at center (possible right or left). This won't look good. Moreover it's a breaking change, which will break the appearance after jsgrid update. So the problem is: no way to distinguish an edit cell with input inside and just a plain text.
Do you have any idea how it could be fixed?


3D Slicer RVXLiverSegmentation plug-in questions

I am trying to use your 3D Slicer RVXLiverSegmentation plug-in (Windows 10), but I have some problems:
i) I specified all portal vein nodes. Why does the button "Extract Vessels from node tree" continue in gray color without activating it?
ii) When I was trying to specify the nodes of the vessels, I tried to view the "node position help window". But, that window appears completely white color. Without any tree vessels. Why?
Sincerely,
Gonzalo Rojas Costa

Hi @grojasy,
Thank you for using our plugin.
i) Regarding your questions, the Extract Vessels from node tree is grayed out unless every point in the tree is positionned in the 2D / 3D view.
If one point or more is not placed in 3D then the button will remain locked.
If one node can't be placed in the liver (for instance one of the optional branches) then you should remove it from the tree by clicking on the trash bin icon.
When every point is placed, the tree should look like this :

ii) Thank you for noticing this problem. It appears the help files are not properly packaged in the module at the moment. I will fix this issue right away.

Ok:
i) I will test it. But, I loaded the data in 3D Slicer, but I will have to specify the points again because the module did not detect them. Why?
ii) When can I download the fixed version?
Sincerely,
Gonzalo Rojas Costa

@grojasy I'm not entirely sure what you mean by loading the detecting the points.
At the moment, the plugin doesn't support reloading previous annotations generated by the plugin.
You can view the results exported using conventionnal 3D Slicer tools (segmentations, markups and volumes)
For the points, you need to click on the name on the point in the branch node name widget before placing the point in the views. It will switch on the placement for the associated markups node and the name in the tree will switch to PLACING.
If you try placing points using a markup directly, the plugin will have no way to know which point you are currently placing so this feature is also not supported.

I specified the node positions of portal veins. Then I pressed the button "Extract vessels from node tree".  I got a large error window. Why?

@grojasy thank you for your feedback on this.
It appears you are using a preview version of 3D Slicer.
I tried the plugin on this version and there are a numbers of changes to the libraries we use including the image processing.
We will have to investigate further to fixe this issue for the coming 3D Slicer version and the current one.
In the meantime, you can use the plugin in the official 5.0.3 3D Slicer release.
I will keep you posted in this thread when the problem is resolved for version 5.1+
Please note also that the fix to the help icons has been solved and is now deployed in 3D Slicer's extension manager.

Hello Thibault,
it seems that I have the same problem as @grojasy. I specified all node points of the portal tree, but the "Extract vessels from node tree" remains grey (not activated).

Is there any help for this problem?
Best regards and thanks for this great plug-in,
Felix

Yes. I had a similar problem. The solution is that you must specify all the nodes, or you must delete it by pressing the trash icon. You should not leave any node undefined.

@Flex8786 thank you for your feedback on the plugin and @grojasy thank you for your assistance on this subject.
As @grojasy said, all the nodes need to be specified before extracting the vessels from the tree.
This behavior seems to be unexpected and not self explanatory so we may adapt how this information is reported or change how the vessels are extracted from partial tree definition in the future.
If removing or specifying the nodes doesn't resolve your problem, don't hesitate to reach out to us.

@grojasy and @Thibault-Pelletier
Thanks for your response. However, as can be seen in the screenshot, I defined all nodes and deleted the optional ones. Nonetheless, the "Extract vessels from node tree" still remains grey.
 However, when I tried to extract the vessels from node tree, an error occurred. Unfortunately, I did not make a screenshot of the error.


Built in validators accept functions for arguments

I am serializing my MVC validations for use in my Vue ViewModels. This often includes things like minLength, etc. I also created a custom decorator so that I can just add @Validation({blah...}) to my model properties and the validation is automatically added.
This works great except when I want to use a serialized parameter for my validation. For the length of minLength. That validation only accepts a number. It would be nice if it could also accept a function returning a number and evaluate the function at run time. This would allow me to supply the the length from the server.
I'm sure that this is an edge case, but I sure hit it. My setup is this (and I'm sure this is one of the only setups that hit it, but it's a nice to have):

Vue-Class-Component
Vue-Property-Decorator
Custom Validate decorator
Typescript

You could slightly invert your problem: just treat the whole validations object as a function and provide the validation parameters as variables.
validations () {
  return {
    myValue: {
      minLength: minLength(this.lengthFromServer)
    }
  }
}

You can also use more complex logic to generate the whole object.
The other solution would be to wrap the validator into your own function:
const lazyMinLength = fn => function (...args) { return minLength(fn(this))(...args) }

...

validations: {
  myValue: {
    minLength: lazyMinLength(vm => vm.lengthFromServer)
  }
}


Add json example for nested object in the doc

Describe the feature
A new feature has been added that provides the ability to pass broker.properties through a json secret.
ActiveMQArtemisSecurity is now a deprecated resource and it's now recommanded to provide configuration with spec.brokerProperties. I would like to implement what it is described here : providing-additional-brokerproperties-configuration-from-a-secret).
How to write nested object and what to escape as characters?
How to translate the yaml below into a json secret?
securitySettings:
    broker:
      - match: "app.europe.#"
        permissions:
          - operationType: createNonDurableQueue
            roles: ["admin"]
          - operationType: deleteNonDurableQueue
            roles: ["admin"]
          - operationType: createDurableQueue
            roles: ["admin"]
          - operationType: deleteDurableQueue
            roles: ["admin"]
          - operationType: createAddress
            roles: ["admin"]
          - operationType: deleteAddress
            roles: ["admin"]
          - operationType: createAddress
            roles: ["admin"]
          - operationType: consume
            roles: ["admin", "guest"]
          - operationType: send
            roles: ["admin"]

I would like to complete the documentation with more complex examples.

[!TIP]
Vote this issue reacting with :+1: or :-1:

@zodd3131 you can convert security settings of ActiveMQArtemisSecurity CR to broker properties ActiveMQArtemis CR, .i.e.
apiVersion: broker.amq.io/v1beta1
kind: ActiveMQArtemis
metadata:
  name: artemis-broker
spec:
  brokerProperties:
    - 'securityRoles."app.europe.#".admin.createNonDurableQueue=true'
    - 'securityRoles."app.europe.#".admin.deleteNonDurableQueue=true'
    - 'securityRoles."app.europe.#".admin.createDurableQueue=true'
    - 'securityRoles."app.europe.#".admin.deleteDurableQueue=false'
    - 'securityRoles."app.europe.#".admin.createAddress=false'
    - 'securityRoles."app.europe.#".admin.deleteAddress=false'
    - 'securityRoles."app.europe.#".admin.consume=false'
    - 'securityRoles."app.europe.#".admin.send=false'

Thank you for the reply @brusdev
May I ask you where did you find the documentation about securityRoles instead of  security-settings. I was looking here
Maybe  can I add more explanation in the documentation below ?
https://artemiscloud.io/docs/help/operator/#providing-additional-brokerproperties-configuration-from-a-secret

@zodd3131 in the Apache ActiveMQ Artemis project there is a doc section and a test class for broker properties:
https://activemq.apache.org/components/artemis/documentation/latest/configuration-index.html#broker-properties
The configuration properties are low level, lower level than xml, however it is very powerful; any accessible attribute of the internal org.apache.activemq.artemis.core.config.impl.ConfigurationImpl objects can be modified.

https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/test/java/org/apache/activemq/artemis/core/config/impl/ConfigurationImplTest.java#L1688

Maybe can I add more explanation in the documentation below ?
Any contributes is always welcome but I think that should be a contribute for the Apache ActiveMQ Artemis project doc.


Add attribute to capture horizontal position

MEI already has @loc and @ploc attributes for recording the vertical position of some items. Adding @hloc would provide a method for recording the horizontal position of an item as measured from the left margin of the page (ala' SCORE).  [Note: the name @loc should be changed to @vloc] These attributes (@hloc and @vloc) can be used to provide explicit rendering information. Their values can be ignored by processors that impose their own layout, say for display on the web.  When  @hloc and @vloc are present, @ho and @vo can be defined as offsets from their values. When @hloc and @vloc are not present, @ho and @vo can retain their current definition as offsets from programatically-determined positions.

I was thinking about these positioning attributes the other day. Despite not being very useful for dynamic display, I can see that @hloc could be useful to capture positioning information in the horizontal axis from a printed source.
Regarding @vo and @ho attributes, I am not really sure what they are useful in the first place, for 'programatically-determined position' is practically an undefined position. (Unless they are meant to be used in a context-specific way, e.g. exporting from a particular software would use these attributes to relate to the positions calculated by that particular program. In my view, such encodings should be as short-lived as possible...)

@facs already defines a zone on a surface, so if you wanted to align with an image of a digitized printed source you would use the @facs/zone/surface functionality.
@hloc would have to be confined to 'dynamic' (i.e., engraved) presentation, perhaps as a way of "locking" elements at a specific spot on the staff.

As is many times the case, perhaps it's the definition ("programatically-determined position") that's problematic, not the thing itself.  This phrase was an attempt to convey the idea that the position of the thing bearing @ho and/or @vo is not absolute.  For example, <note ho=".5"/> is meant to be a way to say "place this note slightly to the right of where it would otherwise have been located".  The place where it "would otherwise have been located" is in fact determined by the layout engine in use.

Yes, @hloc is intended to "lock" elements at a particular horizontal location.
I hope to be able to support files that "lock" items to particular locations as well as completely dynamic layout.  One probably would not employ both methods simultaneously, however.

@loc is currently defined with respect to the staff lines. So @loc=1 would be something that is located on staff line 1.
What would the unit be for @hloc? Is it @hloc=5 which would be 5 staff-line height measurements? or @hloc=5mm which would lock it 5 mm from the edge of the staff?

Not completely determined yet, but I think the reference point has to be related to something that doesn't move, something related to the page, not the staff.  SCORE uses the left edge of the page (or the left page margin, I can't remember which). The values would follow the pattern of other measurements; that is, (\+)?\d+(\.\d+)?(cm|mm|in|pt|pc|px|vu)?
Just for consistency's sake, it might be good to rename @loc to @vloc.

If the left edge of the page were chosen as the reference point, one could never use negative values for @hloc.  If the left page margin were used, then both positive and negative values have to be allowed.  I don't see any reason to prefer one over the other, but I'm willing to be convinced otherwise.

What if there is no page?

I'm not sure what you mean.  The notation has to be displayed on a page/surface/view port, whatever you want to call it, that has dimensions.  So, there's always a page in some sense.

If the notation is intended for display, that is.

Of course @hloc has to be optional, for the case when "fully automatic" layout is desired.  Even when present, renderers could choose to ignore it.  But doing so would "mess up" the layout intended by the encoder, so it might be a good idea for software to ask before throwing away any positional stuff in the file.

It does have dimensions, but they're not always satisfactory dimensions to work in. Pixels, SVG units, etc. are all rendering-level measurements, but it seems unsatisfactory to specify 'locations' in terms of absolute units.
Just like @loc, these are expressed in 'musical' units (location on a line). Other parts of MEI use the half-staff-line height as another 'musical' unit that is independent of the physical medium being displayed.
I guess what I'm trying to say is that if you're looking to fix an object's horizontal position on the page, pixels or millimeters are poor units to do it in since screens don't do millimeters well, and paper doesn't do pixels well. If you're looking at fixing it in musical terms then that would be better from a proportional point of view ("symbol X is always y half-staff-height units from somewhere.")
But neither of those seems satisfactory. In a computer graphics sense the 'origin' is simply a convenient starting point. I can have a fixed Origin that actually means nothing to the music display. For example, I could want to draw some controls on the same canvas that I'm rendering the music on. So the "0" origin, and the "horizontal position from the 0 origin where the application starts drawing music" is defined at an application-specific level and actually has little bearing on any notion of where the "page" edge is. The page edge in this case is virtual. So setting something to be "x" pixels from the origin means nothing. Even if you were to 'assume' a margin, an application might actually draw music with a hard edge on the margin and simply "fake" a page margin. Saying a symbol is 10mm from the page edge is meaningless in this case. Even saying something is 10 "units" from the edge is meaningless, because the distance between the edge of the surface and the edge of the music (i.e., the staff) will be different in every application.
So, in sum: If we're going to go this way, it would be better to come up with some device-independent means of measuring @hloc that does not depend on measured units, nor an actual page edge.

@loc is currently defined with respect to the staff lines. So @loc=1 would be something that is located on staff line 1.

For the record @loc is defined in half-staffspace units with bottom staff line being 0.

OK, thanks for clarifying!

Agreeing with all the points Andrew made,

I support to keep on the path of using musical units, i.e. spaces or half-spaces.
I strongly suggest defining the origin well, or provide a generic mechanism to define the origin well.

Margins, "programatically determined" or positions where things "normally" would be, aren't very useful for processing, staves are much better.

I'm not sure if @ahankinson will find this satisfactory, but how about adding @page.origin attribute sound, where "page" is defined much like <surface>; that is, "a writing surface [defined] in terms of a rectangular coordinate space"?  This definition permits a "page" to be a physical, printed page or a non-physical display space, i.e. a "view port".
@page.origin is intended to take one of the following values: topleft, topright, botleft, botright.  So-called "absolute" values, like those in @x and @y, could be expressed relative to this point (0,0).  The attributes @page.height, @page.width, etc. can stay as they are; that is, their values can be given in several units, "(cm|mm|in|pt|pc|px|vu)".  Of course, conversion between the various units hinges on the existence of @vu.height or the selection of a reasonable default in its absence.
Transformation between encodings using different values for @page.origin is possible as long as some origin is specified.  This argues for either making @page.origin mandatory or providing a default/conventional value.  We probably should make the default origin be whatever point Verovio is using.
I think this gives us a way to more precisely record absolute, page-based location info.  Relative positioning is addressed elsewhere, #357 for example.

@music-encoding/core-contributors, @craigsapp, Are we good to move forward on this?

It is tricky, so I will complain after you make a specification :-)
The closest way to do SCORE's system for @hloc would be as a percentage value between the left/right margins of the music.  SCORE uses the range for 0-200 instead of 0 to 1 or 0 to 100, mostly because this makes horizontal vu's close to vertical vu's at the default scaling (the ratio between the two is 7/6 with the horizontal units slightly longer at 100% scaling, and exactly equal at 87.5% scaling). 0 is the left system barline position, not including brackets or accolades occurring to the left of the system barline.
Mostly how you describe hpos will depend on what you want to space on the page with it: work titles, page numbers, composer's names, footnotes are the things that I can think of that would need to use this attribute.
This system is not aware of the page size or page margins, so not really page specific, although it can be used to approximate page-level positioning.  For example, if you want a page number centered on the page, then it could be centered at 50% of the musical width (or at hpos 100 in SCORE).  As long as the musical content is full-width on the page with equal margins on both sides of the music, the page number would be centered.  If you have unequal margins to allow for a gutter margin (extra space to allow for binding), then this system is superior, since you want the page number centered above the music, not centered on the page which includes a gutter margin.
Likewise the composer's name is often left-justified at 100% to the right above the music (200 units in SCORE).  The size of the page or the margins of the page do not need to be known if the percentage system is used.
Using vu for horizontal positions would not work, since it would be impossible to "lock" anything at a horizontal position when changing the scaling or width of the music.

The closest way to do SCORE's system for @hloc would be as a percentage value between the left/right margins of the music. ... This system is not aware of the page size or page margins, so not really page specific, although it can be used to approximate page-level positioning.

I'm confused -- how can @hloc be a percentage of the distance between the left/right music margins, if the page margins (which I assume are the basis for the music margins) aren't known?
I've been using a mental model of a page that looks like this --

where the page/screen/viewport size and the margins are specified.  The remaining space is for the content.
This seems like a reasonable model to me.  Is it not?  If not, why not?  If so, can we use this as the basis for discussion of page-based placement?

might be related to page-based discussions, in which context this will come up again.


Hare: remove ed25519 key extraction and replace with canonical ed25519

Motivation
This updates the last bits of our codebase that still use key extraction and replaces them with canonical ed25519 signature verification
Changes

Hare Malfeasance has been updated to not use key extraction
CertifyMessage has been updated to include SmesherID and not use key extraction

Test Plan
existing tests pass
TODO

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

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors try

bors merge


mgmt, update sdk script to load suffix

We did this change in https://github.com/Azure/azure-sdk-for-java/pull/20922, but I forgot the reason. Should not be something important.
Now since we had valid suffix configure, we now need it.
paloaltonetworks:
  suffix: ngfw

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

/check-enforcer override