[FEAT]VALID EMAIL FORMAT-REGISTRATION FORM

Description
Develop an API endpoint to validate the email format provided during user registration. When a user inputs their email address, it is validated to ensure it meets the standard format (e.g., mailto:example@example.com). The system checks for the presence of the "@" symbol and a valid domain structure. If the email address is correctly formatted, it is accepted. If not, an error message is displayed, prompting the user to correct it. This ensures data integrity, user experience and successful communication.
Acceptance Criteria

The endpoint /api/v1/user/validate-email is accessible via a POST request.
When a valid email format is provided, the endpoint returns a 200 OK status and a message "Email format is valid".
When an invalid email format is provided, the endpoint returns a 400 Bad Request status "Please enter a valid email address in the format<EMAIL_ADDRESS>.
Ensure that all unit tests for the email validation feature are comprehensive, accurate, and verify the functionality correctly.

Purpose
To ensure that users provide a valid email format during registration, enhancing data integrity in the database, ensures authentication is possible and improve user experience.
Requirements

Implement an endpoint to validate email format.
Return appropriate status codes and messages based on the validation result.
Ensure secure and efficient processing of validation requests.

Expected Outcome
An API endpoint that validates the email format during user registration and returns appropriate responses.
Tasks

[ ] Create an endpoint '/api/v1/user/validate-email' to validate email format.
[ ] Implement server-side logic to handle email format validation requests.
[ ] Ensure secure handling of user input data.
[ ] Write unit tests for the email validation endpoint.
[ ] Perform security testing to ensure data protection and compliance.

Endpoint URL
[POST] /api/v1/user/validate-email
Request Body:
{
"email": "string"
}
Successful Response:
Status code: 200 OK
{
"message": "Email format is valid",
"data": {
"email": "string"
}
}
Error Response:
Status code: 400 BAD REQUEST
{
"error": "Please enter a valid email address in the format<EMAIL_ADDRESS>}
Example Request
Validate Email Format:
curl -X POST "https://<base_url>/api/v1/user/validate-email"
-H "Content-Type: application/json"
-d '{
"email"<EMAIL_ADDRESS>}'

This is not an endpoint.

Or a feature sef. it is expected that registration or even frontend handles it


ValueError: Unknown kernel transform "rp"

Hello, thanks for your work!
An error occoured when I run KECOR for PVRCNN Training:
ValueError: Unknown kernel transform "rp"
I noticed another issue about the same problem, how can I fix it?
Thanks again!

Hi,
I will get it fixed tomorrow, sorry for the delay.
Cheers,
Yadan
Yadan Luo
School of Information Technology and Electrical Engineering
University of Queensland
Brisbane, Australia
On Fri, Mar 15, 2024 at 6:31 PM yux326 @.***> wrote:

Hello, thanks for your work!
An error occoured when I run KECOR for PVRCNN Training:
ValueError: Unknown kernel transform "rp"
I noticed another issue about the same problem, how can I fix it?
Thanks again!
—
Reply to this email directly, view it on GitHub
https://github.com/Luoyadan/KECOR-active-3Ddet/issues/2, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEB3WPGOUOS3ERVEQ4HKVJTYYKWVZAVCNFSM6AAAAABEXSDOAGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4DOOJXHEZDGMA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi yux326,
I have updated the NTK lib and it should work now.
Please let me know if there are any questions and happy to help.
Cheers,
Yadan

Hello, I have used the nwew code and it works, thank you so much!
However, I meet another bug with Second model, I have add a new issue(#3 ).
Hope you could help fix it.
Thanks again for your help!
Yux


Recipe App

A recipe app built with HTML, CSS, and JavaScript is a user-friendly web application that allows users to browse, search, and view recipes, here we can also see what are the ingredients needed to make that particular dish.
Screenshot:

Tech stack:  HTML ,css,  Javascript.
Are you contributing under any open source/
Yes, Kharagpur winter of code.

@Paarisha1 Welcome to METAVERSE!!!!!!!
PLEASE GO THROUGH contributing.md before contributing.


Add model bias analysis notebook using bias madlibs and the bias-fuzzed test sets.

I added per-term AUC for the bias madlibs dataset, which appears to confirm that various LGBTQ terms have the worst bias.
One oddity: the lowest per-term AUC score (0.9392 for "queer") is higher than the AUC for the dataset overall (0.922). Not sure why that is?


[Gradle 4.0.1][AntlrTask]Provide some way to specify arguments for antlr

Expected Behavior
I expect AntlrTask provide some way to specify arguments for antlr(e.g. https://github.com/apache/groovy/blob/master/subprojects/parser-antlr4/build.gradle#L33 )
Current Behavior
No way to specify arguments for antlr
Context
We can not specify package name of generated sources.
Steps to Reproduce (for bugs)
https://docs.gradle.org/current/dsl/org.gradle.api.plugins.antlr.AntlrTask.html
We have to use apply plugin: 'me.champeau.gradle.antlr4' instead.
Your Environment
Java 8, Gradle 4.0.1

Would https://docs.gradle.org/nightly/javadoc/org/gradle/api/plugins/antlr/AntlrTask.html#setArguments(java.util.List) work?  This is missing from the DSL docs, but it exists in the Javadoc.
@melix is there anything else that's special about your plugin?

@big-guy Thanks for your quick reply. BTW, How can I use another version of antlr4(e.g. "com.tunnelvisionlabs:antlr4:<IP_ADDRESS>" )?
https://github.com/gradle/gradle/blob/master/subprojects/antlr/src/main/java/org/gradle/api/plugins/antlr/AntlrPlugin.java#L62

https://docs.gradle.org/nightly/userguide/antlr_plugin.html#sec:antlr_dependency_management

I see. Thanks again :)


[Bug]: Can't access the Fragment View's LifecycleOwner when getView() is null i.e., before onCreateView() or after onDestroyView()

Rarely, and not sure how to reproduce it, I get "Can't access the Fragment View's LifecycleOwner when getView() is null i.e., before onCreateView() or after onDestroyView()" on line 63: "val lifecycle = fragment.viewLifecycleOwner.lifecycle".

It's not a bug because you can't access the view before onCreateView and after onDestroyView.
Do the val binding = binding wherever you're using it in lifecycle callbacks and you should be good.

If you're getting this error while collecting flows in a Fragment.
Use this extension function to safely collect them
fun <T> Flow<T>.safeCollection(lifecycleOwner: LifecycleOwner, data: suspend (T) -> Unit) {
    lifecycleOwner.lifecycleScope.launch {
        this@safeCollection.flowWithLifecycle(lifecycleOwner.lifecycle).collect {
            data(it)
        }
    }
}

Further reading:
https://medium.com/androiddevelopers/a-safer-way-to-collect-flows-from-android-uis-23080b1f8bda


What is the "Friends" Plugin used for?

I try to understand why this plugin needs the friends plugin and what I can do there regarding posting as an activitypub-actor.
Can someone help me out?

The short answer: You do not need any plugin besides the ActivityPub plugin, these are simply recommendations :)
The long answer: The ActivityPub plugin does not yet support following users on Mastodon and the fediverse, but the friends plugin do! So if you only want to publish content to the fediverse, you are fine with the ActivityPub plugin. But if you want to follow other blogs and/or fediverse accounts, you can do that using the Friends plugin.

@jaschaurbach I would recommend using the "Discussions" feature of GitHub, to discuss such things.


Define the next release (0.11)

Hi all,
There seems to be some disparity around expectations on what is going to make it into our next release (0.11).
The release will be based on Bitcoin Core 0.10 using our 0.0.10 Omni Core branch as a base - this much is clear.
The following is a list of items in no particular order that various people have requested make it into the next release and their current status.  I'm sure I'm also missing some.  Let's please use this issue to lock in explicitly what we are going to put into 0.11:
Consensus critical requests needing feature activation:

Trading of non-Omni pairs on the MetaDEx   [coding 100% complete, currently in testing]
Fee caching/distribution system & MetaDEx fees   [coding 99% complete, currently in testing]
Allow any property to use DEx phase 1   [coding 0% complete, not currently started]
Allow BTC in property crowdsales   [coding 0% complete, not currently started]

Non consensus critical requests:

Provide trading of non-Omni pairs in the UI   [coding 0% complete, not currently started]
Provide support in the UI for DEx phase 1   [coding 50% complete, work-in-progress stalled]
Provide support for property issuance in the UI   [coding 0% complete, not currently started]

Note:  Just because they're listed here doesn't mean I'm suggesting they should be included in 0.11 - I'm just listing those requests I'm aware of.
Note:  it's assumed that everything we've built & merged already for what was going to be our <IP_ADDRESS> release (so all the bugfixes, stuff like payload creation on RPC etc) will all be included in 0.11 instead.
Please post your feedback and thoughts about exactly what should be included in 0.11.
Thanks all
Z

Allow any property to use DEx phase 1 [coding 0% complete, not currently started]
I’m not in favor of this - I like the idea of OMNI being the way “into” the system.  I’d be ok with a multi-step process that the client handles to get people into OMNI then place trades on the Phase II DEx once the Phase I tx is done… :-)

Allow BTC in property crowdsales [coding 0% complete, not currently started]
while this is a very very nice to have, I don’t think it should make it into 0.11.

Provide trading of non-Omni pairs in the UI [coding 0% complete, not currently started]
Provide support in the UI for DEx phase 1 [coding 50% complete, work-in-progress stalled]
Provide support for property issuance in the UI [coding 0% complete, not currently started]
I am in favor of these features as a priority, but I think only the first one should be included in 0.11 if possible (simple drop-downs for each column).

I’d like for us to get 0.11 with non-Omni pairs live as quickly as possible, and I’d be fine with a 0.11.1 with the additional UI pieces.

OK, so the general feedback I've gathered so far seems to be:
0.11 (release candidate ASAP)

Trading of non-Omni pairs on the MetaDEx [coding 100% complete, currently in testing]
Fee caching/distribution system & MetaDEx fees [coding 99% complete, currently in testing]

0.11.1 (can be released when it's ready before or after activating 0.11 features as not consensus critical)

Provide trading of non-Omni pairs in the UI [coding 0% complete, not currently started]
Provide support in the UI for DEx phase 1 [coding 50% complete, work-in-progress stalled]
Provide support for property issuance in the UI [coding 0% complete, not currently started]

Deferred (will not be included in the 0.11 branch but can be added to next major release - 0.12 - if the consensus is that these features are a good idea)

Allow any property to use DEx phase 1 [coding 0% complete, not currently started]
Allow BTC in property crowdsales [coding 0% complete, not currently started]

Could you please signal if you agree with this approach @dexX7 @CraigSellars @patrickdugan @msgilligan @achamely
Thanks
Z

I'm fine with the MetaDEx changes, but hesitated regarding the UI extensions, given the context of #362.

Yeah I can understand that.  FYI I got the general feeling that it would be desirable to get more DEx capability into the current QT UI, following which people would be open to tabling alternatives.  Would that be your take from the feedback supplied so far also?
So would you agree for 0.11, it's just the UI stuff for 0.11.1 you're not sure about?
Do you have an alternate path you'd prefer dude?  Really my key goal is to get a roadmap set, even if it is just for this next release - something to guide the work - I kind of feel (at least from my own perspective and contributions) that it's very scattered and I find myself doing lots of different things and trialling/prototyping and talking to lots of people and so forth but not really making huge progress from an Omni Core PoV.
In a nutshell I'm just really keen to lock in direction :)

In a nutshell I'm just really keen to lock in direction :)

Thanks for pushing this!

Would that be your take from the feedback supplied so far also?

My understanding was that Sean and Patrick want a DEx v1 integration into the UI, and the general sentiment was "having an Omni UI would be nice". I share the sentiment, but I'm not sure, if it's the best route forward, given the small end user base.

So would you agree for 0.11, it's just the UI stuff for 0.11.1 you're not sure about?

Correct. I'm fine with the consensus changes for 0.11, but split regarding the UI stuff.

Do you have an alternate path you'd prefer dude?

Moving on top of 0.12 is also still an open topic, which could be tackled after the soon-ish 0.10 release.

My understanding was that Sean and Patrick want a DEx v1 integration into the UI, and the general sentiment was "having an Omni UI would be nice"

Craig was also keen on non-Omni pair trading in the UI - from a personal view I'd be more interested in this than I would be in DEx v1 integration, simply because we're releasing that feature now, and I'd rather provide UI support for a feature we're activating now to help it gain traction as opposed to a feature we activated a couple of years ago which is already rarely used.
I'm wondering if I should start in on MetaDEx UI changes in QT while you guys running the OmniJ/Jenkins/Unit Test stuff are working up the testing side of the consensus changes for 0.11.
Alternatively I could use this as an opportunity to get more involved in the testing side of things myself perhaps.

Moving on top of 0.12 is also still an open topic, which could be tackled after the soon-ish 0.10 release.

I'm very keen on moving to 0.12.  The kind of deadlines being requested preclude doing that for 0.11 but I'm definitely supportive of moving to a 0.12 base ASAP after that.  If for nothing else than the substantial reduction in compute (and thus cost) required for users/integrators to run a node (with the move to libsecp256k1).
0.12 also allows pruning with a wallet, which is of interest.  We can't use it directly as we're still required to load blocks in some places, but I wonder whether we can be selective and exclude Omni-containing blocks from the pruning process.  Disk consumption is one of the pain points to using Omni Core (though this is dwarfed by the startup sync time as the most vocal objection).

Hey, given time constraints, I'm inclined to defer all Omnicore UI updates possibly to 0.12.1 and get key features done sooner rather than later.
BTC for crowdsales is nice but I'm about to start doing PARK as a managed smart property, and can receive BTC as a matter of app logic.
So, let's get 0.11 out ASAP and start on 0.12, and budget these nice to have details for later.

Hey, given time constraints, I'm inclined to defer all Omnicore UI updates possibly to 0.12.1 and get key features done sooner rather than later.

To re-iterate my concerns from the meeting, are we not just making exactly the same mistakes over and over and not learning anything?
We continuously build features, and then don't provide any mechanism for people to use them.  The features then go essentially unused.  To back up this assertion you only have to look at:

How many people have actually used STO since we built it and made it live?
How many people have actually used Send-All?
How many people have actually made a trade on the MetaDEx?

On and on it goes, and the answer to all of those questions is essentially zero.
Thus I'm extremely hesitant to continue down this path and once again say "let's not worry about access to our features & instead let's build another new feature (smart contracts) and continue to ignore the fact we have an unsustainably low number of users".
I know this isn't a popular viewpoint, but I care about this project (I've put 3 years of my life into it) and I am just quite disappointed to see us repeatedly doing the same thing that hasn't worked for us in the past.
From my own perspective, one key thing above all else is actually getting users - the ability to exchange value - that's at the core of everything - exchanging value - whether that be sending tokens or trading tokens.  That's what's going to drive "users" and get us the critical mass we need to sustain the project long enough to do advanced stuff like smart contracts properly (ie with a white paper, spec and proper design and implementation).
Thus I really, really wish we could actually focus on the user experience.  The UX for sending tokens is reasonable, and that's why over 99% of our transactions are sending tokens.  The UX for trading tokens is terrible (and non-existent outside Omni Core) and that's why ~0.001% of our transactions are trades.  Other features we spent months building in the past don't even get used at all (ie 0%).
TL:DR; my vote is absolutely to focus on the UX for sending and trading - the bread and butter if you will - in the hopes of bringing some fresh life into the project.
I will go with the consensus as I'm a team player, but I implore consideration and learning from the past before making decisions.  Another bunch of time of building stuff no-one uses I'm sure will hurt the project :(

Note, tone is hard to convey in text - I'm not tring to be standoff-ish guys :) I'm just sharing an opinion which you may or may not want to take on board :)

@zathras-crypto: I generally share your opinion.
Do you have something particular in mind how to improve the UX? And are you referring to Omni Core, Omni Wallet or a new on-ramp for users?

@zathras-crypto: I generally share your opinion.

That's good & thanks dude, I'm glad I'm not the only one who worries about this stuff :)

Do you have something particular in mind how to improve the UX? And are you referring to Omni Core, Omni Wallet or a new on-ramp for users?

I think what we need to do is be realistic and target our efforts towards the audiences that we want.  If I may ramble for a moment...
Omni Core
Our audience here is quite clearly enthusiasts, developers and integrators.  We don't have very many end users on Omni Core because of barriers to entry (like sync times and disk consumption).  I see this platform as our primary and most critical stack, but I also acknowledge the reality on the ground is that end users don't like it and we haven't been successful growing a strong user base with it.
Omni Wallet
This is where I think most non-technical users end up. From a UX PoV I think it's probably the best that we have so far.  But trading is going to be a slow burn to get there I think (just from the vibes I've picked up).  Also on security it's great that it does client side signing but let's be honest, no-one verifies the transactions that are given to the client to sign.  This is not Omni Wallet's fault but also a reality on the ground.  A compromised Omni Wallet server could easily craft the transaction maliciously saying "Send John Doe all the Bitcoins at this address" and an Omni Wallet user would sign it client side just the same.  Thus I think Omni Wallet is great and accessible and I'd love to see trading brought online, but at the end of the day it's still a "web wallet" and a web wallet can't be our only offering to end users.
Exchanges
From various impressions & discussions I've had I think a not insignificant number of users don't use an Omni capable wallet at all.  They buy/sell Omni properties to trade with on exchanges but only withdraw/deposit BTC.  Other folks simply deposit & withdraw Omni properties directly from one exchange to another and don't use their own Omni capable wallet.
OmniPortfolio
If this is something that we can realistically release as a productized wallet in the near term I'm super positive about it.  I haven't been following the development in detail so I'm not sure where it's up to right now.
New on-ramp
This.  Ideally, we'd build a product targeted for end users making sure to address the problems they currently face such as ease of access and availability.  I actually think it's not as big an undertaking as it sounds and could be done relatively quickly if we focused, especially if we fork one of the many existing wallet projects, and doubly-so if this idea of using several API services in tandem to ensure consensus is acceptable (I'm of split minds on that).
Of course I don't have a full roadmap or anything, as at the moment I'm just trying to secure agreement on a direction.  Once we have a direction, we can plot specific steps.
Maybe I'm just making myself unpopular with our leadership haha, but I'm an opinionated dude so what can you do :)

While there are some very good points in this thread, I currently don't see any actionable items we can extract here, so I'm going to close it for now. Please feel free to reopen though. :)


Update some translation in scheduling config page

Update some translations in page scheduling config.
Page updated: https://kubernetes.io/zh/docs/reference/scheduling/config/#scheduling-plugins

/lgtm

/approve


Playback telemetry

Relates to #906.
Log play attempt for each item in playlist separately, instead of doing it only once on player close. Include information about external playbacks.

Will defer to @dcposch to review this.

@dcposch @Flet Is this ready to land? If it's ready, merge it!


[boost-exception] cross-compilation build failure

Operating system
Linux
Compiler
Clang/Clang-CL/Llvm 14
Steps to reproduce the behavior
docker run --name windows -it nemirtingas/windowscross_vcpkg:msvc2019_win10.0.18362.0 bash

cd /
git clone https://github.com/microsoft/vcpkg --branch=master vcpkg_microsoft
cd vcpkg_microsoft
cat >triplets/community/x86-windows-clangcl.cmake <<EOF
set(VCPKG_TARGET_ARCHITECTURE x86)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE static)
if(PORT STREQUAL "portaudio")
    set(VCPKG_LIBRARY_LINKAGE dynamic)
endif()

set(VCPKG_BUILD_TYPE release)

set(ENV{HOST_ARCH} \${VCPKG_TARGET_ARCHITECTURE})

set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE /clang_windows_sdk/clang-cl-msvc.cmake)

set(ENV{VCPKG_TOOLCHAIN} "/vcpkg/scripts/toolchains/windows.cmake")
EOF
./bootstrap-vcpkg.sh
./vcpkg install boost-exception:x86-windows-clangcl

Failure logs
Make Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: /vcpkg/downloads/tools/cmake-3.27.1-linux/cmake-3.27.1-linux-x86_64/bin/cmake --build . --config Release --target install -- -v -j5
    Working Directory: /vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel
    See logs for more information:
      /vcpkg/buildtrees/boost-exception/install-x86-windows-nemirtingas-rel-out.log

Call Stack (most recent call first):
  /build/windows_vcpkg/x64-linux/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
  /build/windows_vcpkg/x64-linux/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
  /build/windows_vcpkg/x64-linux/share/boost-build/boost-modular-build.cmake:139 (vcpkg_cmake_install)
  ports/boost-exception/portfile.cmake:12 (boost_modular_build)
  scripts/ports.cmake:147 (include)

error: building boost-exception:x86-windows-nemirtingas failed with: BUILD_FAILED
Elapsed time to handle boost-exception:x86-windows-nemirtingas: 9.4 s

"/usr/bin/ld" /lib /nologo /machine:X86 /nologo /out:"/vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/boost/build/a073d718535aa9e7a4a3cc23041e3e51/libboost_exception.lib" "/vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/boost/build/a073d718535aa9e7a4a3cc23041e3e51/clone_current_exception_non_intrusive.obj"

/usr/bin/ld: cannot find /lib: file format not recognized
/usr/bin/ld: cannot find /nologo: No such file or directory
/usr/bin/ld: cannot find /machine:X86: No such file or directory
/usr/bin/ld: cannot find /nologo: No such file or directory
/usr/bin/ld: cannot find /out:/vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/boost/build/a073d718535aa9e7a4a3cc23041e3e51/libboost_exception.lib: No such file or directory

...skipped <p/vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/stage/lib>libboost_exception.lib for lack of <p/vcpkg/buildtrees/boost-exception/x86-windows-nemirtingas-rel/boost/build/a073d718535aa9e7a4a3cc23041e3e51>libboost_exception.lib...
...failed updating 1 target...
ninja: build stopped: subcommand failed.

Additional context
For some reason, my custom toolchain's linker is not used for my crosscompilation while the previous version I was using was working.
I was at vcpkg 36fb23307e10cc6ffcec566c46c4bb3f567c82c6 . I will investigate this when I got time.
Seems that its the boost-modular-build-helper port that has an issue since using the boost-modular-build-helper from 36fb23307e10cc6ffcec566c46c4bb3f567c82c6 compiles boost on the latest vcpkg

The culprit is this change : #30836, specificly theses 2 changes : https://github.com/microsoft/vcpkg/pull/30836/files#diff-6114a1d0526c9e9e3477ac321abfe1c9005f46441b01c5b1f5821f64f231721eL146-R177 .
@JavierMatosD @Neumann-A @BillyONeal Any reason why clang-win b2 is added in the check ? That causes the directives
        "    <ranlib>\"${VCPKG_DETECTED_CMAKE_RANLIB}\"\n"
        "    <archiver>\"${VCPKG_DETECTED_CMAKE_AR}\"\n"

To not be used, causing my issue.

If you use clang-cl -> /usr/bin/ld seems to be the wrong linker

Yes, but /usr/bin/ld is used because the if statement is overriding the settings in favor of mingw and running a .bat won't work on any other OS than Windows obviously. What would be the correct fix ?

I'm experiencing the same issue on arm64-linux.
Package<EMAIL_ADDRESS>Host Environment

Host: arm64-linux
Compiler: GNU 10.2.1
vcpkg-tool version: 2999-12-31-unknownhash
vcpkg-scripts version: c8696863d 2023-12-12 (2 weeks ago)

To Reproduce
vcpkg install libmysql:arm64-linux-dynamic --recurse --clean-after-build
Failure logs
-- Using cached boostorg-exception-boost-1.83.0.tar.gz.
-- Extracting source /build/build-unix/vcpkg/downloads/boostorg-exception-boost-1.83.0.tar.gz
-- Using source at /build/build-unix/vcpkg/buildtrees/boost-exception/src/ost-1.83.0-e0db41e4c0.clean
-- Getting CMake variables for arm64-linux
-- Configuring arm64-linux
-- Building arm64-linux-rel
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: /usr/local/lib/python3.9/dist-packages/cmake/data/bin/cmake --build . --config Release --target install -- -v -j11
    Working Directory: /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel
    See logs for more information:
      /build/build-unix/vcpkg/buildtrees/boost-exception/install-arm64-linux-rel-out.log

Call Stack (most recent call first):
  installed/arm64-linux/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
  installed/arm64-linux/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
  installed/arm64-linux/share/boost-build/boost-modular-build.cmake:139 (vcpkg_cmake_install)
  ports/boost-exception/portfile.cmake:12 (boost_modular_build)
  scripts/ports.cmake:170 (include)

/build/build-unix/vcpkg/buildtrees/boost-exception/install-arm64-linux-rel-out.log
Change Dir: '/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel'

Run Build Command(s): /usr/bin/ninja -v -v -j11 install
[1/2] cd /build/build-unix/vcpkg/buildtrees/boost-exception/src/ost-1.83.0-e0db41e4c0.clean/build && /build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build/b2 toolset=gcc --user-config=/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/user-config.jam --stagedir=/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage --build-dir=/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel runtime-link=shared link=static address-model=64 architecture=x86 target-os=linux threadapi=pthread variant=release --layout=system -sICU_PATH="ICU_PATH-NOTFOUND" --with-atomic --with-random --with-date_time --with-filesystem --with-system --with-thread --with-chrono -j 11 -sBOOST_ROOT=/build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build -sBOOST_BUILD_PATH=/build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build --debug-configuration --debug-building --debug-generators --ignore-site-config --hash -q debug-symbols=on -d +2 threading=multi stage
FAILED: CMakeFiles/boost /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/CMakeFiles/boost
cd /build/build-unix/vcpkg/buildtrees/boost-exception/src/ost-1.83.0-e0db41e4c0.clean/build && /build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build/b2 toolset=gcc --user-config=/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/user-config.jam --stagedir=/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage --build-dir=/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel runtime-link=shared link=static address-model=64 architecture=x86 target-os=linux threadapi=pthread variant=release --layout=system -sICU_PATH="ICU_PATH-NOTFOUND" --with-atomic --with-random --with-date_time --with-filesystem --with-system --with-thread --with-chrono -j 11 -sBOOST_ROOT=/build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build -sBOOST_BUILD_PATH=/build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build --debug-configuration --debug-building --debug-generators --ignore-site-config --hash -q debug-symbols=on -d +2 threading=multi stage
notice: loading B2 from /build/build-unix/vcpkg/installed/arm64-linux/tools/boost-build/src/kernel/bootstrap.jam
notice: Site configuration files will be ignored due to the
notice: --ignore-site-config command-line option.
notice: Loading explicitly specified user configuration file:
    /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/user-config.jam
notice: Searching '/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel' for user-config configuration file 'user-config.jam'.
notice: Loading user-config configuration file 'user-config.jam' from '/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel'.
notice: will use '/usr/bin/c++' for gcc, condition <toolset>gcc-10
notice: using gcc libraries :: <toolset>gcc-10 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64
notice: using gcc archiver :: <toolset>gcc-10 :: /usr/bin/ar
warning: toolset gcc initialization: can not find tool windres
warning: initialized from /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/user-config.jam:11
notice: using rc compiler :: <toolset>gcc-10 :: /usr/bin/as

Building target '../build/stage'
     Build request: object(property-set)@269 <address-model>64 <architecture>x86 <debug-symbols>on <link>static <runtime-link>shared <target-os>linux <threadapi>pthread <threading>multi <toolset>gcc <variant>release
     Command line free features:
     Target requirements: <define>BOOST_ALL_NO_LIB=1 <hardcode-dll-paths>false <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <link>static <location>/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage/lib<EMAIL_ADDRESS><EMAIL_ADDRESS>
     Common properties:  <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>false <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <location>/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage/lib <optimization>speed <os>LINUX <pch>on <profiling>off <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc<EMAIL_ADDRESS><user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on

     Building target '../build/boost_exception'
         Build request: object(property-set)@276 <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <exception-handling>on <extern-c-nothrow>off <inlining>full <link>static <optimization>speed <os>LINUX <pch>on <profiling>off <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc <variant>release <vectorize>off <warnings-as-errors>off <warnings>on
         Command line free features:
         Target requirements: <define>BOOST_ALL_NO_LIB=1 <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <link>static<EMAIL_ADDRESS>
         Common properties:  <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <optimization>speed <os>LINUX <pch>on <profiling>off <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc <user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on

         Usage requirements for boost_exception:
         Build properties:  <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <optimization>speed <os>LINUX <pch>on <profiling>off <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc <user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on
     *** construct LIB
         from { clone_current_exception_non_intrusive.cpp.CPP }
         properties: <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <main-target-type>LIB <optimization>speed <os>LINUX <pch>on <profiling>off <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc <user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on
     find-viable-generators target-type= LIB property-set=
     trying type LIB
     there are generators for this type
     trying generator builtin.prebuilt ( -> LIB )
         feature-requirements are not met: <file>
     trying generator builtin.lib-generator ( -> LIB )
       is viable
     trying generator unix.prebuilt ( -> LIB )
         property-requirements are not met: <toolset>unix
     trying generator gcc.prebuilt ( -> LIB )
         feature-requirements are not met: <file>
     ***  1  viable generators
         *** construct STATIC_LIB
             from { clone_current_exception_non_intrusive.cpp.CPP }
             properties: <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <main-target-type>LIB <optimization>speed <os>LINUX <pch>on <profiling>off <relevant>link <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc <user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on
         find-viable-generators target-type= STATIC_LIB property-set= link-static
         trying type STATIC_LIB
         there are generators for this type
         trying generator unix.archive ( OBJ -> STATIC_LIB )
             property-requirements are not met: <toolset>unix
         trying generator gcc.archive ( OBJ -> STATIC_LIB )
           is viable
         ***  1  viable generators
           ** generator gcc.archive
           composing: true
             *** construct OBJ
                 from { clone_current_exception_non_intrusive.cpp.CPP }
                 properties: <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>true <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <main-target-type>LIB <optimization>speed <os>LINUX <pch>on <profiling>off <relevant>link <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc <user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on
             find-viable-generators target-type= OBJ property-set= link-static
             trying type OBJ
             there are generators for this type
             trying generator rc.compile.resource ( RC -> OBJ )
               is viable
             trying generator gcc.compile.c++ ( CPP -> OBJ )
               is viable
             trying generator gcc.compile.c ( C -> OBJ )
               is viable
             trying generator gcc.compile.asm ( ASM_CPP -> OBJ )
               is viable
             trying generator gcc.compile.m ( OBJECTIVE_C -> OBJ )
               is viable
             trying generator gcc.compile.mm ( OBJECTIVE_CPP -> OBJ )
               is viable
             trying generator gcc.compile.fortran ( FORTRAN FORTRAN90 -> OBJ )
               is viable
             ***  7  viable generators
               ** generator 'rc.compile.resource' pruned
               ** generator gcc.compile.c++
               composing:
               SUCCESS:  [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ] { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } }

             returned [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ] { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } }
               generator gcc.compile.c++  spawned
               { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } }
               with usage requirements: [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ]
               ** generator 'gcc.compile.c' pruned
               ** generator 'gcc.compile.asm' pruned
               ** generator 'gcc.compile.m' pruned
               ** generator 'gcc.compile.mm' pruned
               ** generator 'gcc.compile.fortran' pruned
           SUCCESS:  [ <relevant>address-model <relevant>architecture <relevant>archiveflags <relevant>instruction-set <relevant>response-file <relevant>target-os <relevant>toolset <relevant>toolset-gcc:version ] { gcc%gcc.archive-libboost_exception.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } }

         returned [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>archiveflags <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ] { gcc%gcc.archive-libboost_exception.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } }
           generator gcc.archive  spawned
           { gcc%gcc.archive-libboost_exception.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } }
           with usage requirements: [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>archiveflags <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ]
     returned [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>archiveflags <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ] { gcc%gcc.archive-libboost_exception.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } }
       generator builtin.lib-generator  spawned
       { gcc%gcc.archive-libboost_exception.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } }
       with usage requirements: [ <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>archiveflags <relevant>c++-template-depth <relevant>cflags <relevant>coverage <relevant>cxxflags <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>define <relevant>exception-handling <relevant>force-include <relevant>include <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>local-visibility <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>pch-file <relevant>profiling <relevant>response-file <relevant>rtti <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>warnings <relevant>warnings-as-errors ]
         Usage requirements from boost_exception:  <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>coverage <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>deduced-address-model <relevant>deduced-architecture <relevant>exception-handling <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>profiling <relevant>rtti <relevant>segmented-stacks <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>variant <relevant>visibility <relevant>warnings <relevant>warnings-as-errors

     Usage requirements for stage:  <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>coverage <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>deduced-address-model <relevant>deduced-architecture <relevant>exception-handling <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>profiling <relevant>rtti <relevant>segmented-stacks <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>variant <relevant>visibility <relevant>warnings <relevant>warnings-as-errors
     Build properties:  <address-model>64 <architecture>x86 <asynch-exceptions>off <coverage>off <debug-symbols>on <define>BOOST_ALL_NO_LIB=1 <define>NDEBUG <exception-handling>on <extern-c-nothrow>off <hardcode-dll-paths>false <host-os>linux <include>../include&&/build/build-unix/vcpkg/installed/arm64-linux/include <inlining>full <install-dependencies>off <link>static <location>/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage/lib <optimization>speed <os>LINUX <pch>on <profiling>off <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>coverage <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>deduced-address-model <relevant>deduced-architecture <relevant>exception-handling <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>profiling <relevant>rtti <relevant>segmented-stacks <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>variant <relevant>visibility <relevant>warnings <relevant>warnings-as-errors <response-file>auto <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <suppress-import-lib>false <symlink-location>project-relative<EMAIL_ADDRESS><target-os>linux <threadapi>pthread <threading>multi <toolset-gcc:version>10 <toolset>gcc<EMAIL_ADDRESS><user-interface>console <variant>release <vectorize>off <warnings-as-errors>off <warnings>on
     Usage requirements from stage:  <relevant>address-model <relevant>address-sanitizer <relevant>architecture <relevant>c++-template-depth <relevant>coverage <relevant>cxxstd <relevant>cxxstd-dialect <relevant>debug-symbols <relevant>deduced-address-model <relevant>deduced-architecture <relevant>exception-handling <relevant>inlining <relevant>instruction-set <relevant>leak-sanitizer <relevant>link <relevant>lto <relevant>lto-mode <relevant>optimization <relevant>pch <relevant>profiling <relevant>rtti <relevant>segmented-stacks <relevant>stdlib <relevant>target-os <relevant>thread-sanitizer <relevant>threadapi <relevant>threading <relevant>toolset <relevant>toolset-gcc:version <relevant>undefined-sanitizer <relevant>variant <relevant>visibility <relevant>warnings <relevant>warnings-as-errors
common.mkdir /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage

        mkdir -p "/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage"

common.mkdir /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost

        mkdir -p "/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost"

common.mkdir /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage/lib

        mkdir -p "/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/stage/lib"

common.mkdir /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost/build

        mkdir -p "/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost/build"

common.mkdir /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost/build/b8421191efc14ad1df4c6b5e64656875

        mkdir -p "/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost/build/b8421191efc14ad1df4c6b5e64656875"

gcc.compile.c++ /build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost/build/b8421191efc14ad1df4c6b5e64656875/clone_current_exception_non_intrusive.o

    "/usr/bin/c++"   -fPIC -O3 -DNDEBUG -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -g  -DBOOST_ALL_NO_LIB=1 -DNDEBUG   -I"../include" -I"/build/build-unix/vcpkg/installed/arm64-linux/include"  -c -o "/build/build-unix/vcpkg/buildtrees/boost-exception/arm64-linux-rel/boost/build/b8421191efc14ad1df4c6b5e64656875/clone_current_exception_non_intrusive.o" "../src/clone_current_exception_non_intrusive.cpp"

c++: error: unrecognized command-line option ‘-m64’
...failed updating 1 target...
ninja: build stopped: subcommand failed.

In case you have the same issue as me, you can try my branch here : https://github.com/Nemirtingas/vcpkg/tree/fix/boost-crosscompilation

Hi there, just comming back to say its fixed with the new boost build scripts.


Fix Link to Sample Application in Microsoft Document

Fix Link to Sample Application in Microsoft Document
Regarding this document - https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/how-to-localize-an-application
in above document , in Create a Sample Application section
Link to LocBaml Tool Sample does not work

@rpetrusha, please make sure this one gets assigned soon.

I've asked @mohit14mar to file this one. I need to follow up with the product team to see if there's a good replacement for this. It could be https://github.com/Microsoft/WPF-Samples/tree/master/Globalization and Localization/BAML Loc.

Could it be this? https://github.com/Microsoft/WPF-Samples/tree/master/Getting Started/HelloWorld

@SamBent @sachingo can you guys help us find where the LocBaml tool is now located or if it was deleted? Our old link http://go.microsoft.com/fwlink/?LinkID=160016 no longer works.
My guess would be https://github.com/Microsoft/WPF-Samples/tree/master/Globalization and Localization/BAML Loc.

Hi
I found the original source code of the locbaml tool on github. However, I am not sure whether the author published these sources on behalf of Microsoft or “by accident”. I don’t want to get this person into trouble by pointing at him/her. Therefore, just search for “locbaml” in github and you find it.
Is there a license for the locbaml tool? The source files are only annotated with “Copyright (c) Microsoft Corporation.  All rights reserved.“ And no license information seems to be available.

@rabanti-github if you're talking about the one I pointed earlier (https://github.com/Microsoft/WPF-Samples/tree/master/Globalization and Localization/BAML Loc), that repo has an MIT license.
The one I could find on GitHub (https://github.com/JeremyDurnell/locbaml) doesn't seem official.
@SamBent can you confirm which link should we use to replace https://archive.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=wpfsamples&DownloadId=9333? Does my suggestion to point to https://github.com/Microsoft/WPF-Samples/tree/master/Globalization and Localization/BAML Loc sounds good?

The unofficial project seems to be originating from Microsoft. I assume it was the old locBaml sample project mentioned (among others) in: https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/how-to-localize-an-application. All described features in this tutorial seems to be implemented in this unofficial project.
The other project seems however not to be a proper replacement. https://github.com/Microsoft/WPF-Samples/tree/master/Globalization%20and%20Localization/BAML%20Loc/LocApp has almost no content when it comes to code. It is only a WPF window with two text blocks. Localization features are not even implemented there. Is it planned to update this project?
I am a little bit clueless at the moment.

Project A is unofficial and seems to be the six year old sample project from Microsoft but with unclear legal status.
Project B is official but seem not to resemble the purpose of a demonstration of localization or the use of the BamlLocalizer class / locBaml sample.

I'm marking this one as blocked. @vatsan-madhavan could you help us figure out if we published or intend to publish this LocBaml tool sample? Please see issue history for more context.
/cc @OliaG

Sorry for missing this thread for several days.
Would you mind opening an issue for this at https://github.com/dotnet/wpf - asking for LocBaml to be published ?

No worries @vatsan-madhavan. Issue filed: https://github.com/dotnet/wpf/issues/498


Scroll feature in Ubuntu 20.04 LTS terminal for windows

Is your feature request related to a problem? Please describe.
Commands can be viewed till window screen ends, terminal has no scroll feature.
tput -x clear command working same as clear command.
Describe the solution you'd like
Include scroll feature directly from Ubuntu code base and link related commands like tput as well.
Describe alternatives you've considered
Shift + Page UP/DOWN or Ctrl + Arrow Keys could be possible alternate.
Additional context
Like command prompt include function key 'F7' feature 'to list used commands' and switch between them as well.

Make sure "Screen Buffer Size" height is large. This will fix scrolling and history.

Thank you, @DHowett .


[WIP] Adding delay for task scheduling

On execution creation there should be a way to delay the task by a specified amount of time. This PR provides a mechanism to specify in the the delay in milliseconds.

Closing and reopening to kick CI.

On a related note - we definitely need some integration and end to end tests for that (it won't be the must fun thing to write, but still).

On a relate note - once this feature is implemented, we should update / improve retry policy to utilize this status and functionality to make more more robust and restart safe (see #3630).

As mentioned and described on Slack, I pushed some changes:

Fix "missing index" test case failure issue - df0dd0cd7089a650b17fcb6e9f8af05d287267f5

This one took a while to track down. It was related to a missing index because a test method called ``reset()` which drops the collections and deletes the indexes. This would cause any test which runs afterwards and doesn't recreate indexes to fail.
You could say we should re-create indexes for each test method run in every test file. This would indeed be the most robust approach, but it's not a feasible one - creating indexes is very expensive (especially if we create them for all the models before each test method run) and would slow tests down by at least 50-100% (I tried that in the past).
So right now we only create indexes once per test file and in some scenarios, like this one, also before each test method run (but again, if that's not needed we try to avoid it due to the overhead).

Base test class refactor - 68682ad7b6b82cf2c59cac4f9e1f10b087563ead

I moved _wait_on_status and other execution test case related utility method on new base test class.
This way we can only ensure index for ExecutionQueueDB model for test cases which use those methods where that is needed. That speeds things up compared to ensuring index for that model for each test case which uses DbTestCase class.


Cannot read property 'getModeId' of null

Issue Id: 302dc63e-c731-f030-3fdc-1f9732162b69Versions - 1.29.0-insider (10/16/2018 7:32:34 AM)Stack TypeError: Cannot read property 'getModeId' of null/vs/workbench/api/electron-browser/mainThreadComments.ts#64:44    at Array.forEach ()/vs/workbench/api/electron-browser/mainThreadComments.ts#47:18 (call)/vs/base/common/event.ts#145:15 (fire)/vs/workbench/services/editor/browser/editorService.ts#125:36 (call)/vs/base/common/event.ts#145:15 (fire)/vs/workbench/browser/parts/editor/editorGroupView.ts#784:28 (onComplete)/vs/base/common/winjs.base.js#1587:0 (then)/vs/workbench/browser/parts/editor/editorGroupView.ts#780:70 (doShowEditor)/vs/workbench/browser/parts/editor/editorGroupView.ts#770:32 (doOpenEditor)/vs/workbench/browser/parts/editor/editorGroupView.ts#739:14 (openEditor)/vs/workbench/browser/parts/editor/editorGroupView.ts#1010:8 (doCloseActiveEditor)/vs/workbench/browser/parts/editor/editorGroupView.ts#1192:8 (doCloseEditors)/vs/workbench/browser/parts/editor/editorGroupView.ts#1144:8 (onComplete)/vs/base/common/winjs.base.js#1587:0    at t.closeEditors (out/vs/workbench/workbench.main.js

We no longer have such code so the error won't be triggered any more.


Add ability to view-state in deserialized format and not borsh

Borsh is not a self-descriptive format, so you cannot just bring some data blob and deserialize it. Thus, you would need to bring the schema with you. If you have it in Rust, e.g.:
#[derive(BorshSerialize)]
struct MyStruct {
    name: String
}

then you can copy-paste it and write a simple Rust program:
use borsh::{BorshSerialize, BorshDeserialize};

#[derive(BorshSerialize, BorshDeserialize, Debug)] // <----
struct MyStruct {
    name: String
}

fn main() {
    let binary_blob = vec![/* bytes */];
    let my_struct_value = MyStruct::try_from_slice(&binary_blob).expect("unable to deserialize MyStruct");
    println!("{:#?}", my_struct_value);
}

OK, makes sense. The problem for me as a user I'm calling view-state and expect to see something human readable, I have no idea of what the actual state of the contract I'm trying to look the state for is.
Is there a way to implement that logic into the near cli tool without me ever need to think about the state schema?

@chefsale unfortunately it's not possible. In Borsh you are always encoding data with a schema. The structure of the data is not saved in the encoded result (so it becomes smaller!). At the same time, it is not possible to decode this data without the schema that was used during encoding.

There is no way to do that at the moment since near-cli / RPC / nearcore / NEAR protocol only know that the keys and values are binary data. We could try to deserialize those as strings / JSON values, but not borsh. In the general case, contracts actually call storage_write(binary_key, binary_value), and it is near-sdk-rs which provides the magic of serializing Rust structs into those binary values and given that borsh does not have a schema, there is no way to read it without the source code or some explicit dump of the schema, and in the general case, we don't have access to the source code (unless it is open-sourced and easily discoverable, and even in that case, we cannot automatically extract borsh schema out of it).


Azure resource groups added in new pattern

Azure resource groups added as resource in new controller pattern standard.
Signed-off-by: HashedDan<EMAIL_ADDRESS>
Description of your changes:
Which issue is resolved by this Pull Request:
Resolves #
Checklist:

[x] Documentation has been updated, if necessary.
[x] Pending release notes updated with breaking and/or notable changes, if necessary.
[x] Upgrade from previous release is tested and upgrade user guide is updated, if necessary.
[x] Code generation (make generate) has been run to update object specifications, if necessary.
[x] CRD manifests generation (make manifests) has been run to update CRD manifests yaml file specifications, if necessary.
[x] Update dependencies (make vendor) has been run to update Gopkg.lock file, if necessary
[x] RBAC permissions in clusterrole.yaml have been updated to include new types, if necessary
[x] All related commits have been squashed to improve readability.
[x] Comments have been added or updated based on the standards set in CONTRIBUTING.md
[x] New resources are covered by testing

https://sonarcloud.io/project/issues?id=crossplaneio_crossplane&open=AWooHSUqMflNeiYSED2p&pullRequest=391&resolved=false
The above 'code smell' is probably worth fixing too. Sonarcloud is sad about duplicated code and a slight decrease in code coverage, which as far as I can tell is just because NewClient is not covered. I think we need to tweak Sonarcloud's heuristics here - we've hit a few cases in which IMO striving for 80% coverage at the PR scope is not that useful.

Whoops - I probably should have squashed the commits of this PR before merging. My mistake!


ENH: Do not import range from six

Do not import range from six: six is a Python 2 and 3 compatibility library. Since support for Python 2 was dropped following the discussion in https://github.com/demianw/tract_querier/pull/53, this patch set removes six as a dependency of the project.
The built-in Python range() is equivalent to the six.moves.range method, so adopt the former by avoiding to import it from six.moves.
Similarly, use range() instead of xrange(), which is only supported in Python 2. Both are equivalent.
Documentation:
https://pypi.org/project/six/

Not sure why the previous run failed for Python 3.10 minimal:
https://github.com/demianw/tract_querier/actions/runs/12181922510
It is now working. Checked locally as well. Marking this as ready.


Dataframe#sort speed up

In reference to #39

This uses Array#sort_by to replace handmade sort. This has been made possible because Array#sort_by can take multiple attributes to sort the array by.
There's one pitfall though. Whereas earlier it used to be like:
df.sort [:a, :b], by: {a: lambda { |a,b| a.abs <=> b.abs }, b: lambda { |a,b| a.to_i <=> b.to_i }}

Now one is allowed to do it this way only
df.sort [:a, :b], by: {a: lambda { |a| a.abs }, b: lambda { |a| a.to_i }}

This is because Array#sort_by can only accept these sort of blocks.

Is this some sort of error. How can sorting two columns take so much less time than sorting single column?

Don't think it's a mistake. Did you try running that script on your computer?

This is a good fix that can have far reaching implications in speed and usability, but I would like to confirm if it's alright to change the way the blocks are accessed.
@gnilrets @mohawkjohn @dansbits could use your advice here.
Also, @lokeshh, will it be possible maintain backwards compatibility with the original interface to :by? Do research that option too. I think it can be achieved by assuming that the methods users will call on a and b in the block ({|a,b| a.method <=> b.method }) would be the same, so maybe we just call method inside your block on the single block, and thereby not break the interface. An error will be raised if the two methods are different.
Also, will this be extensible enough to allow sorting of missing data too?

I might have gone wrong in the benchmarks while copy-pasting and editing or something.

Wow... there's been some very massive increase. I ran the benchmarks/sorting.rb for original 10,000 vectors and here's the result:
Sort a Vector without any args  0.080000   0.010000   0.090000 (  0.087908)
Sort vector in descending order with custom <=> operator  0.130000   0.000000   0.130000 (  0.182502)
Sort single column of DataFrame  2.190000   0.120000   2.310000 (  3.241833)
Sort two columns of DataFrame  2.390000   0.060000   2.450000 (  3.500302)
Sort two columns with custom operators in different orders of DataFrame  2.400000   0.060000   2.460000 (  3.473831)

Beautiful!

I've avoided sorting dataframes and vectors due to the very poor performance, so anything that makes a dramatic improvement is a great step in the right direction.

@lokeshh you just need to make the tests pass now :)

I've added support for nil's and it can sort dataframes consisting 10^5 rows in 3 seconds.

Tests failures are similar to that in #63

Should I solve them the same way by sorting through index?
On Mar 5, 2016 11:58 AM, "Sameer Deshmukh"<EMAIL_ADDRESS>wrote:

Tests failures are similar to that in #63
https://github.com/v0dro/daru/pull/63
—
Reply to this email directly or view it on GitHub
https://github.com/v0dro/daru/pull/67#issuecomment-192588762.

Yep. Consistency is important.
Also check my comment on the code, I have a feeling it's an edge case.

Done. I now need to arrange the code better so it looks good and understandable. @gnilrets @v0dro If you find some discrepancies meanwhile please let me know.

That edge case I mentioned earlier is not working. I pulled from your branch and tested. Here's the code:
require 'daru'
df = Daru::DataFrame.new({a: ['a', 'aa', nil, 'aaaa'], b: [2,4,5,nil]})
# =>
#<Daru::DataFrame:95207900 @name = 2bf19e45-231d-4468-abd0-4344500e8761 @size = 4>
#                    a          b
#         0          a          2
#         1         aa          4
#         2        nil          5
#         3       aaaa        nil
df.sort([:a, :b], by: { b: lambda {|x| x + 4}})
# NoMethodError: undefined method `+' for nil:NilClass
# from (pry):5:in `block in __pry__'

Oh! I see what you meant earlier now. This is not an edge case I think. I
simply haven't introduced the feature of handling nils automatically when
user provided a block. I assumed user would do that when he will provide
the block.

Then please document that in the method docs. This will be a great daru specific feature, I could't see the other dataframe libraries use it.

What will be a great feature? Are you in favor of keeping the
responsibility of handling nils to the user when he provides the block?

Sorting with the block function even when nils are present.
If handling nils in daru is going to slow down the sorting significantly, then let the user take care of it. But we need to make sure that it's well documented.

If handling nils in daru is going to slow down the sorting significantly, then let the user take care of it. But we need to make sure that it's well documented.

Ok, I will document it. I was thinking that we can also have an option like handle_nils: [true, false] that user can provide to tell whether he wants the nils to be automatically managed when he passes a block or not. Sometimes the user might want to handle the nils in his own way. For example, he might want them to be displayed in the end. In that case the user can handle the nils himself. What do you say?

Can we confirm how much of a slowdown handling nils is going to cost?  Nils are so common in the data I've had to deal with on a daily basis for last 8 years and 3 jobs.  In order to use Daru consistently, I'd probably have to monkey patch Daru or add some other Daru wrapper objects in my projects to handle nils.
I'm not convinced the GC involved with creating Sortable objects every time one has to sort is really going to be an issue.  I'm not sure the best way to test this either.

For this benchmark, handling nils take 1.72 seconds and sorting without handling nils take 1.24 seconds.

I'd probably have to monkey patch Daru or add some other Daru wrapper objects in my projects to handle nils.

@gnilrets As far as this PR goes, Daru is going to handle nils given no block. @v0dro and me were discussing about whether nils should be handled automatically when user provides a block or not.
It's not a big deal to handle nils for the user. For example, if user want to handle nils and have a block like lambda { |a| a.abs }, he just needs to change this block to lambda { |a| [(a.nil?)?0:1, a.abs] }, this will sort with nils at top. On the other hand one can do lambda { |a| [(a.nil?)?1:0, a.abs] } if he wants to have nils at the bottom.
So, I was proposing a solution that user can pass an option to specify whether he wants the nils to be automatically handled given a block or not. Nils will be automatically handled given no block. What do you say?

@lokeshh - I misunderstood.  Thanks for the clarification!

That works. It satisfies needs of both novice and advanced users. Having an option to choose if nils should be handled automatically or not would be great. Make sure you document your effort well. Once you're done, you can update the daru notebooks at sciruby-notebooks to provide further clarification where necessary.

Done. Do I need iRuby to run the sciruby-notebooks?

Yes.

Clone the repo and modify according to what you need.
Run the notebook with a fresh iRuby kernel and make sure the whole notebook works without any errors.
Push changes.

I encountered a problem while modifying one of the notebooks. It's here


allow indexes on nullable attributes (#7754)

Pull request opened by the merge tool on behalf of #7754

Merged into branches iso7 in f636df6172fff8a629780791a8611bcc6b29d4aa


Remove preview for a specific URL in a message

The pull request adds the support to allow a user to remove previews for any URLs in editable messages.
Note: This is based on @punchagan's old PR #12816 with some required updates.
GIF:

I think when rebasing an existing PR from somebody else it's good practice to keep them as the commit authors and add yourself to the commit message as Co-authored-by: name<EMAIL_ADDRESS>(to retain their authorship).
Also please add GIFs.

As an alternative that requires less explicit effort, I wonder if it might work better to make previews for URLs which are alone in a paragraph (and just replace the URL with the preview), but not make previews for URLs in a sentence. Then if someone really wants a preview, they can always just paste it onto its own paragraph. I made an issue for this suggestion here:
https://github.com/zulip/zulip/issues/17070

As an alternative that requires less explicit effort, I wonder if it might work better to make previews for URLs which are alone in a paragraph (and just replace the URL with the preview), but not make previews for URLs in a sentence. Then if someone really wants a preview, they can always just paste it onto its own paragraph. I made an issue for this suggestion here:
https://github.com/zulip/zulip/issues/17070


Remove hash part of URL from request URL and client URL

Problem
Fragment identifiers (the hash part of the URL) are also part of the service worker request URL. This causes problems when using the sw-appcache-behavior AppCache polyfill with Single-Page Applications (SPA) because the URL including the fragment identifier does not match the URL cached from the manifest.
Related
The same problem had already been identified in https://github.com/GoogleChrome/workbox/issues/488 and https://github.com/GoogleChromeLabs/sw-precache/issues/290.
Solution
This pull request proposes a solution that seems to solve the problem in practical tests.
Tests
The sw-appcache-behavior project already contains automated tests. However, they focus on the tricky part of populating the cache correctly from the manifest. There are currently no existing tests that check whether data is correctly retrieved back from the cache by the service worker.
Hence, we were not able to simply derive a test for the new behaviour proposed in the pull request.
Hopefully, the pull request can still help improve the sw-appcache-behavior.

@googlebot I signed it!


Unconnected tf trees

Hello!
Sorry for taking your time. I’m new to ROS and I came across some issues with Rivz display. When the global fixed frame is set to Odom, the marker array shows but other criteria fails to load, when I switch the global fixed frame to base_link, the other criteria works but the marker arrays fails.
I checked and it is possibly caused by the unconnected tf trees between baselink and Odom. The tf tree in my scenario looked like this:
frames.pdf
Does the tf tree looked the same on your side or I’m loading the robot wrong?
Also if I want to connect these two tf trees, which file I could go to so that I can make modifications?
Thank you in advance!

Hi,
Please let me know your system setup and installation steps (ROS, Ubuntu versions, installation steps).
Also, please print out your console log.

Hello!
My system setup was ROS melodic, with Ubuntu 18.04
I followed the exact installation steps in README.md, and it went smoothly.
The training process I had the same issue, however it appears that the robot is trained properly. Looking from Gazebo it was able to navigate to the goal point with an increasing average reward. It might be just some issue with Rviz.

With that said, here is my console log running test_velodyne_td3.py, since I am running it right now.
Please let me know if you need any other information!
$ python3 test_velodyne_td3.py
Roscore launched!
Unable to register with master node [http://localhost:11311]: master may not be running yet. Will keep trying.
... logging to /home/jason/.ros/log/b9287b10-9b3a-11ed-9353-f0b61e7da785/roslaunch-jason-MS-7D30-4320.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://localhost:45155/
ros_comm version 1.14.13
SUMMARY
PARAMETERS

/rosdistro: melodic
/rosversion: 1.14.13

NODES
auto-starting new master
process[master]: started with pid [4356]
ROS_MASTER_URI=http://localhost:11311/
setting /run_id to b9287b10-9b3a-11ed-9353-f0b61e7da785
process[rosout-1]: started with pid [4390]
started core service [/rosout]
Gazebo launched!
... logging to /home/jason/.ros/log/b9287b10-9b3a-11ed-9353-f0b61e7da785/roslaunch-jason-MS-7D30-4399.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
Deprecated: xacro tag 'property' w/o 'xacro:' xml namespace prefix (will be forbidden in Noetic)
when processing file: /home/jason/DRL-robot-navigation/catkin_ws/src/multi_robot_scenario/xacro/p3dx/inertia_tensors.xacro
included from: /home/jason/DRL-robot-navigation/catkin_ws/src/multi_robot_scenario/xacro/p3dx/pioneer3dx_body.xacro
included from: /home/jason/DRL-robot-navigation/catkin_ws/src/multi_robot_scenario/xacro/p3dx/pioneer3dx.xacro
Use the following command to fix incorrect tag usage:
find . -iname "*.xacro" | xargs sed -i 's#<([/]?)(if|unless|include|arg|property|macro|insert_block)#<\1xacro:\2#g'
started roslaunch server http://localhost:32955/
SUMMARY
PARAMETERS

/joint_state_publisher/publish_frequency: 30.0
/robot_description: <?xml version="1....
/robot_state_publisher/publish_frequency: 30.0
/rosdistro: melodic
/rosversion: 1.14.13
/use_sim_time: True

NODES
/
gazebo (gazebo_ros/gzserver)
joint_state_publisher (joint_state_publisher/joint_state_publisher)
robot_state_publisher (robot_state_publisher/robot_state_publisher)
rviz (rviz/rviz)
urdf_spawner (gazebo_ros/spawn_model)
ROS_MASTER_URI=http://localhost:11311/
process[gazebo-1]: started with pid [4465]
process[urdf_spawner-2]: started with pid [4469]
process[robot_state_publisher-3]: started with pid [4471]
process[joint_state_publisher-4]: started with pid [4472]
process[rviz-5]: started with pid [4473]
[ INFO] [1674491204.576754689]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1674491204.577379200]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[INFO] [1674491204.751053, 0.000000]: Loading model XML from ros parameter robot_description
[INFO] [1674491204.756289, 0.000000]: Waiting for service /gazebo/spawn_urdf_model
[ INFO] [1674491204.943357397]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[ INFO] [1674491204.948302227]: Physics dynamic reconfigure ready.
[INFO] [1674491205.058189, 0.000000]: Calling service /gazebo/spawn_urdf_model
[ INFO] [1674491205.294805870, 0.201000000]: Camera Plugin: Using the 'robotNamespace' param: '/'
[ INFO] [1674491205.295870647, 0.201000000]: Camera Plugin (ns = /)  <tf_prefix_>, set to ""
[ INFO] [1674491205.299445810, 0.201000000]: Camera Plugin: The 'robotNamespace' param was empty
[ INFO] [1674491205.300440173, 0.201000000]: Camera Plugin (ns = r1)  <tf_prefix_>, set to "r1"
[ INFO] [1674491205.362810918, 0.201000000]: Laser Plugin: The 'robotNamespace' param was empty
[ INFO] [1674491205.362849321, 0.201000000]: Starting Laser Plugin (ns = r1)
[ INFO] [1674491205.363304670, 0.201000000]: Laser Plugin (ns = r1)  <tf_prefix_>, set to "r1"
[INFO] [1674491205.903600, 0.201000]: Spawn status: SpawnModel: Successfully spawned entity
[ INFO] [1674491205.906843237, 0.201000000]: Velodyne laser plugin missing <min_intensity>, defaults to no clipping
[ INFO] [1674491205.907539781, 0.201000000]: Velodyne laser plugin ready, 16 lasers
[ INFO] [1674491206.007369485, 0.201000000]: Starting plugin DiffDrive(ns = r1/)
[ INFO] [1674491206.007415744, 0.201000000]: DiffDrive(ns = r1/):  = Debug
[ INFO] [1674491206.007616425, 0.201000000]: DiffDrive(ns = r1/): <tf_prefix> = r1
[DEBUG] [1674491206.007638252, 0.201000000]: DiffDrive(ns = r1/):  = cmd_vel
[DEBUG] [1674491206.007643762, 0.201000000]: DiffDrive(ns = r1/):  = odom
[DEBUG] [1674491206.007648809, 0.201000000]: DiffDrive(ns = r1/):  = odom
[DEBUG] [1674491206.007653524, 0.201000000]: DiffDrive(ns = r1/):  = base_link
[DEBUG] [1674491206.007669459, 0.201000000]: DiffDrive(ns = r1/):  = false
[ WARN] [1674491206.007674490, 0.201000000]: DiffDrive(ns = r1/): missing  default is true
[DEBUG] [1674491206.007681544, 0.201000000]: DiffDrive(ns = r1/):  = true
[DEBUG] [1674491206.007706789, 0.201000000]: DiffDrive(ns = r1/):  = 0.29999999999999999
[DEBUG] [1674491206.007723647, 0.201000000]: DiffDrive(ns = r1/):  = 0.17999999999999999
[DEBUG] [1674491206.007730821, 0.201000000]: DiffDrive(ns = r1/):  = 1.8
[DEBUG] [1674491206.007736523, 0.201000000]: DiffDrive(ns = r1/):  = 20
[DEBUG] [1674491206.007741395, 0.201000000]: DiffDrive(ns = r1/):  = 50
[DEBUG] [1674491206.007763367, 0.201000000]: DiffDrive(ns = r1/):  = world := 1
[DEBUG] [1674491206.007774713, 0.201000000]: DiffDrive(ns = r1/):  = left_hub_joint
[DEBUG] [1674491206.007783153, 0.201000000]: DiffDrive(ns = r1/):  = right_hub_joint
[ WARN] [1674491206.007801793, 0.201000000]: GazeboRosDiffDrive Plugin (ns = ) missing , defaults to 1
[ INFO] [1674491206.008049498, 0.201000000]: DiffDrive(ns = r1/): Advertise joint_states
[ INFO] [1674491206.008296666, 0.201000000]: DiffDrive(ns = r1/): Try to subscribe to cmd_vel
[ INFO] [1674491206.008947613, 0.201000000]: DiffDrive(ns = r1/): Subscribe to cmd_vel
[ INFO] [1674491206.009065044, 0.201000000]: DiffDrive(ns = r1/): Advertise odom on odom
[ INFO] [1674491206.011388413, 0.201000000]: GazeboRosJointStatePublisher is going to publish joint: chassis_swivel_joint
[ INFO] [1674491206.011400256, 0.201000000]: GazeboRosJointStatePublisher is going to publish joint: swivel_wheel_joint
[ INFO] [1674491206.011406171, 0.201000000]: GazeboRosJointStatePublisher is going to publish joint: left_hub_joint
[ INFO] [1674491206.011411320, 0.201000000]: GazeboRosJointStatePublisher is going to publish joint: right_hub_joint
[ INFO] [1674491206.011416333, 0.201000000]: Starting GazeboRosJointStatePublisher Plugin (ns = r1/)!, parent name: r1
[DEBUG] [1674491206.014904451, 0.205000000]: Trying to publish message of type [sensor_msgs/Image/060021388200f6f0f447d0fcd9c64743] on a publisher with type [sensor_msgs/Image/060021388200f6f0f447d0fcd9c64743]
[DEBUG] [1674491206.015030639, 0.205000000]: Trying to publish message of type [sensor_msgs/CameraInfo/c9a58c1b0b154e0e6da7578cb991d214] on a publisher with type [sensor_msgs/CameraInfo/c9a58c1b0b154e0e6da7578cb991d214]
[DEBUG] [1674491206.021303348, 0.211000000]: Trying to publish message of type [sensor_msgs/LaserScan/90c7ef2dc6895d81024acba2ac42f369] on a publisher with type [sensor_msgs/LaserScan/90c7ef2dc6895d81024acba2ac42f369]
[DEBUG] [1674491206.032846752, 0.216000000]: Trying to publish message of type [sensor_msgs/PointCloud2/1158d486dd51d683ce2f1be655c3c181] on a publisher with type [sensor_msgs/PointCloud2/1158d486dd51d683ce2f1be655c3c181]
[DEBUG] [1674491206.038860676, 0.222000000]: Trying to publish message of type [nav_msgs/Odometry/cd5e73d190d741a2f92e81eda573aca7] on a publisher with type [nav_msgs/Odometry/cd5e73d190d741a2f92e81eda573aca7]
[DEBUG] [1674491206.038901289, 0.222000000]: Trying to publish message of type [sensor_msgs/JointState/3066dcd76a6cfaef579bd0f34173e9fd] on a publisher with type [sensor_msgs/JointState/3066dcd76a6cfaef579bd0f34173e9fd]
[urdf_spawner-2] process has finished cleanly
log file: /home/jason/.ros/log/b9287b10-9b3a-11ed-9353-f0b61e7da785/urdf_spawner-2*.log
QObject::connect: Cannot queue arguments of type 'QVector'
(Make sure 'QVector' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'QVector'
(Make sure 'QVector' is registered using qRegisterMetaType().)

Hi,
ROS melodic version has a separate branch in this repository. It should still work, however, consider it depreciated. If you installed the main branch, that supports only Noetic version and has issues running in Melodic.
You could however, create a static link between r1/base_link and base_link.
You can check in this file to see how to create static transform publisher:
https://github.com/reiniscimurs/DRL-robot-navigation/blob/9a4d92ca41e370617baa4451f0a784f8ca5239ce/TD3/assets/multi_robot_scenario.launch

Thank you so much for this! I will look more into it and really appreciate your help!

Hello!
I have successfully made everything render in Rviz, with however just one issue.
now that I connected all of the trees, linked below:
frames.pdf

the odometries and marker array is fixed on map, while the laserscan is fixed on the robot.
Is there any way I could fix this?

AFAIK, the base_link should not be directed towards odom. It should be the other way around.
Judging by your first qrt_tree that you showed, your direction of links should be:
r1/odom -> r1/base_link -> base_link -> the rest of the tree
So you would only need to create a link between r1/base_link -> base_link
I would suggest trying that

Yes it worked!
For reference, here is the tf tree working for me:
frames.pdf
by adding these codes to the TD3/assets/multi_robot_scenario.launch

sorry one more question. My GPU and CPU is at around 10~20% when training this model. Is there any parameters I could change to improve the hardware utilization?

Great that it worked out!
The network here isn't particularly heavy, so it shouldn't use a lot of resources. But you could increase the batch size, that would increase the amount of data over which calculations are made in a single pass. This could also increase the speed of convergence but it is not guaranteed.

yes I tried that the convergence seemed faster. Thank you again for all of your help and this amazing project!


Improve user interface

LGTM with or without my hover color request, up to your judgement.
Please add a little more info to this PR's description. Just describe the change in 1-2 sentences.


Create MANIFEST.in

Add the license (and other files) to MANIFEST.in so that it will be included in sdists and other packages.
This came up during packaging of python-slugify for conda-forge.

Coverage decreased (-5.5%) to 82.418% when pulling 88da2775a0d201a32cc51b5b294818a472266e2d on proinsias:patch-1 into 43d8b722ca6e477802dac98d116bfd84ec6b99a2 on un33k:master.


Cannot import name 'Paths' from Norfair Error

I'm coming across with this error on the title, and couldn't fix that. Norfair is installed with pip on Colab, but can't import Paths from it. Thanks in advance!

I think this is probably due to you using Norfair on python 3.6, is this correct? That version of python installs an old version of Norfair, which doesn't work with our demos. We're working to fix this though!

Iam using google colab for running yolov5 demo code .it will also show this same error what i do know?
ImportError: cannot import name 'Paths' from 'norfair' (/usr/local/lib/python3.7/dist-packages/norfair/init.py)

I have the same issue, I cannot import Paths,
ubuntu==20.04.4
python==3.8.12
norfair==0.4.0
error log:
ImportError: cannot import name 'Paths' from 'norfair' (/.../python3.8/site-packages/norfair/__init__.py)
any help will be appreciated?

Hi, thanks for the feedback! We just fixed this issue. The reason for it was that our releases were behind our demos, so not all features used in our demos were released in pypi. The latest Norfair release (v0.4.3) fixed this.

Hi, thanks for the feedback! We just fixed this issue. The reason for it was that our releases were behind our demos, so not all features used in our demos were released in pypi. The latest Norfair release (v0.4.3) fixed this.

thanks @joaqo for solving this issue.


Error: No provider for "framework:jasmine"

i get the following error:
./node_modules/gulp-karma/node_modules/karma/node_modules/di/lib/injector.js:9
      throw error('No provider for "' + name + '"!');
            ^
Error: No provider for "framework:jasmine"! (Resolving: framework:jasmine)
    at error (./node_modules/gulp-karma/node_modules/karma/node_modules/di/lib/injector.js:22:68)
    at Object.parent.get (./node_modules/gulp-karma/node_modules/karma/node_modules/di/lib/injector.js:9:13)
    at get (./node_modules/gulp-karma/node_modules/karma/node_modules/di/lib/injector.js:54:19)
    at ./node_modules/gulp-karma/node_modules/karma/lib/server.js:29:14
    at Array.forEach (native)
    at start (./node_modules/gulp-karma/node_modules/karma/lib/server.js:28:21)
    at invoke (./node_modules/gulp-karma/node_modules/karma/node_modules/di/lib/injector.js:75:15)
    at Object.exports.start (./node_modules/gulp-karma/node_modules/karma/lib/server.js:272:12)
    at Object.<anonymous> (./node_modules/gulp-karma/lib/background.js:3:8)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:901:3

If i start karma from console it works as expected (./node_modules/.bin/karma run).

Sadly this did not fix anything, my devDependencies looks like:
"karma": "^0.12.31",
"karma-chrome-launcher": "^0.1.7",
"karma-htmlfile-reporter": "^0.1.2",
"karma-jasmine": "^0.3.5",
"karma-jasmine-jquery": "^0.1.1",
"karma-phantomjs-launcher": "^0.1.4",
"karma-requirejs": "^0.2.2",```

config:

```frameworks: ['jasmine-jquery', 'requirejs', 'jasmine'],```

but then as soon as I add ```plugins: []``` even with nothing inside, it fails on whatever the first item is in that list:

```Error: No provider for "framework:jasmine-jquery"! (Resolving: framework:jasmine-jquery)```

Any ideas?

hmm having this problem now :(

I'm having this issue, I'm only wanting to run mocha.

i had the issue before,and i solved this problem by install karma concerned modules to global env.it`s a directly way  to run your test modules but not the best way to solve the problem.

I am getting error below error while running karma test. anybody have work around. much appreciated. Thanks
Error: No provider for "framework:jasmine"! (Resolving: framework:jasmine)

here is my karma.config file. any help much appreciated. Thanks
// Karma configuration
// Generated on Thu Oct 13 2016 12:05:23 GMT-0400 (Eastern Daylight Time)
module.exports = function(config) {
config.set({
// base path that will be used to resolve all patterns (eg. files, exclude)
basePath: '',

// frameworks to use
// available frameworks: https://npmjs.org/browse/keyword/karma-adapter
frameworks: ['jasmine'],

// list of files / patterns to load in the browser

// list of files / patterns to load in the browser
files: [
'lib/angular.min.js',
'lib/angular-mocks.js',
'app/.js',
'tests/.js'
],
// list of files to exclude
exclude: [
],

// preprocess matching files before serving them to the browser
// available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
preprocessors: {
},

// test results reporter to use
// possible values: 'dots', 'progress'
// available reporters: https://npmjs.org/browse/keyword/karma-reporter
reporters: ['progress'],

// web server port
port: 9876,

// enable / disable colors in the output (reporters and logs)
colors: true,

// level of logging
// possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
logLevel: config.LOG_INFO,

// enable / disable watching file and executing tests whenever any file changes
autoWatch: true,

// start these browsers
// available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
browsers: ['Chrome'],

// Continuous Integration mode
// if true, Karma captures browsers, runs the tests and exits
singleRun: false,

// Concurrency level
// how many browser should be started simultaneous
concurrency: Infinity

})
}

I struggled with the exact same problem. After investigating I realized that karma was running globally using '/usr/' directory as the base folder.
A solution that worked for me was to replace karma with karma-cli:
    npm remove -g karma
    npm install -g karma-cli


Making message_backward_compatibility.rs tests compile

Added example conversion functions for structs to aide in backward
compatibility.
trying to address backward compatibility

Nice. I'll take a look at what exactly this does :)
Thanks


Tracking: testing, stability, and documentation

In order to set our testnet up for success, we want to expand our existing unit tests, create new integration tests, and better document our code. This issue's purpose is to track all the current tasks related to those goals. We might not be able close all of these by testnet launch, but at least by testnet upgrade.
Expanding Current Testing

[x] https://github.com/celestiaorg/celestia-app/issues/400
[x] https://github.com/celestiaorg/celestia-app/issues/389
[x] https://github.com/celestiaorg/celestia-app/issues/312
[x] https://github.com/celestiaorg/celestia-app/issues/333

New Integration tests

[x] https://github.com/celestiaorg/celestia-app/issues/410

Bugs

[x] https://github.com/celestiaorg/celestia-app/issues/379
[x] https://github.com/celestiaorg/celestia-app/issues/530

Misc

[X] https://github.com/celestiaorg/celestia-app/issues/323
[x] https://github.com/celestiaorg/celestia-app/issues/279
[x] #440
[x] https://github.com/celestiaorg/celestia-app/issues/244
[x] https://github.com/celestiaorg/celestia-app/issues/755

it should be noted that while we could focus on tests like those described in #233, I think we can postpone these until after testnet, as those tests ensure that a malicious validator cannot propose improper blocks, as opposed to simply testing for proper honest functionality first.

moved remaining issue directly to #514 so we can close this


Set up All Contributors bot

Is your feature request related to a problem? Please describe.
Being thankful for contributions is important for a growing community. I saw that the JRelease project uses a nice bot: "All Contributors"
This updates automatically a CONTRIBUTORS.md file.

Describe the solution you'd like
Set up All Contributors bot.

@javahippie You should have received some request of the bot to access the operaton/operaton repository.

Updated README.md as described by https://allcontributors.org/docs/en/bot/installation#3-create-a-readmemd
In a next step I will move the contributors table to its own file as in JReleaser

So far it does not work as expected. I have followed the instructions so far, but the contributors are not updated. I will investigate this later.


redoing last pr pretty much #133

this is for the grammar related stuff.
context: #133
tree im not a web dev :/

pls give commits proper names

well I was about to say make it one commit but ninelore already merged it


Add filenames to dockercompose language to help with proper Seti icon theme mapping

This PR addresses part of https://github.com/microsoft/vscode-docker/issues/2539. All dockercompose documents should now get the pink whale icon that previously only docker-compose.y(a)ml and docker-compose.override.y(a)ml received.
@alexr00 @aeschli @karolz-ms FYI
Supersedes #131650.

I fixed the seti icon by updating the font update script. The changes in this PR is not needed, unless you wanted to switch from filenamePatterns to filenames for other reasons. Please reopen then.


[engine] Investigate Wasm action processor

Is your feature request related to a problem? Please describe.

We want to create some kind of plugin mechanism for the processor, so I want to consider the wasm processor as a means to do this.

Describe the solution you'd like

Investigate how to implement the wasm runtime
Examination of the flow of users actually creating plugins

The engine currently defines a processor called RhaiCaller(cf. rhai.rs), which allows dynamic processing on Feature objects by evaluating Rhai scripts.
However, a plugin utilizing Wasm is desired due to a lack of flexibility, such as the absence of memory spaces.
@miseyu
This is my understanding; please feel free to drop a comment.

@soma00333
Yes, you're absolutely right!


Hotfix order crossing

Refactored crosses method of orders to check that tradables match...this was the partial source of a nasty bug...

Opened PR against the wrong branch!


[C++] Missing FindArrow.cmake in the recent versions

Describe the usage question you have. Please include as many useful details as  possible.
It seems FindArrow.cmake file is removed from releases after 9.0.0. When using the newer Arrow versions (14.0.0), I am getting the following cmake error:
Could not find a package configuration file named "FindArrow.cmake"
  provided by package "Arrow".

  Add the installation prefix of "Arrow" to CMAKE_PREFIX_PATH or set
  "Arrow_DIR" to a directory containing one of the above files.  If "Arrow"
  provides a separate development package or SDK, be sure it has been
  installed.

With versions prior to 9.0.0, this is not a problem, since they are shipped with FindArrow.cmake. Should I simply use the FindArrow.cmake from version 9.0.0 with version 14.0.0?
Component(s)
C++

We provide ArrowConfig.cmake instead of FindArrow.cmake.
find_package(Arrow) uses ArrowConfig.cmake not FindArrow.cmake without configuration. See also: https://cmake.org/cmake/help/latest/command/find_package.html
How do you require FindArrow.cmake?

Thanks Sutou for the response! I wasn't aware that ArrowConfig.cmake was present instead.
Now I am using the following to find Arrow:
message(STATUS "Arrow installed here: " ${ARROW_ROOT}/install)
if (EXISTS "${ARROW_ROOT}/install/lib")
    set(ARROW_LIBRARY_DIR "${ARROW_ROOT}/install/lib")
elseif (EXISTS "${ARROW_ROOT}/install/lib64")
    set(ARROW_LIBRARY_DIR "${ARROW_ROOT}/install/lib64")
else ()
    message(ERROR "Unable to find Arrow lib directory in ${ARROW_ROOT}/install")
endif ()
set(ARROW_INCLUDE_DIR "${ARROW_ROOT}/install/include")
message(STATUS "Arrow libs dir: " ${ARROW_LIBRARY_DIR})
message(STATUS "Arrow include dir: " ${ARROW_INCLUDE_DIR})

# add a path to ArrowConfig.cmake to CMAKE_PREFIX_PATH
list(APPEND CMAKE_PREFIX_PATH "${ARROW_LIBRARY_DIR}/cmake/Arrow")
list(APPEND CMAKE_PREFIX_PATH "${ARROW_LIBRARY_DIR}/cmake/ArrowTesting")

find_package(Arrow REQUIRED)
find_package(ArrowTesting REQUIRED)

Is it the proper way to include it in a cmake project?
Thank you for your help!

This will work:
message(STATUS "Arrow installed here: " ${ARROW_ROOT}/install)
# add a path to lib*/cmake/*/Arrow{,Testing}Config.cmake to CMAKE_PREFIX_PATH
list(PREPEND CMAKE_PREFIX_PATH "${ARROW_ROOT}/install")
find_package(Arrow REQUIRED)
find_package(ArrowTesting REQUIRED)

Great, thanks a lot Sutou, it works now!


Upgrade to nightly-2022-06-25

Closes https://github.com/hermitcore/rusty-hermit/issues/300. :tada:

bors r+