Uncaught Error: Loader has not been hooked

I'm getting the aforementioned error quite a lot and I'm wondering what general stupidity I'm doing in order to get this error?
I can see a unit-test where this is being exercised, but I don't understand enough about the module-loader internals to understand how I get there.
Any help on the issue is greatly appreciated.

Ah, also:
npm version 2.12.0
iojs: 2.2.1
mockery: ^1.4.0


feat: decode base64 encoded placeholders in secrets

Description
Checks if secret placeholders are base64 encoded before replacing.
Fixes: https://github.com/IBM/argocd-vault-plugin/issues/124
Checklist
Please make sure that your PR fulfills the following requirements:

[x] Reviewed the guidelines for contributing to this repository
[x] The commit message follows the Conventional Commits Guidelines.
[x] Tests for the changes have been updated
[ ] Docs have been added / updated

Type of Change

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] New tests
[ ] Build/CI related changes
[ ] Documentation content changes
[ ] Other (please describe)

Other information
I'm open to suggestions on how to document this.

@teejaded thank you for the contribution! Will take a look first thing in the morning

We should add docs for this too on the README, @teejaded feel free to add that here if you want. Otherwise we'll just do it when it's released


Various fixes

Some of them already discussed face to face at some point.

Thank you, Dridi.

Thanks for the review!


Removing / using eslint?

Are we using eslint for anything?  Since we are using prettier, I'm not sure if ES lint is serving any other purpose - I may be wrong though.  If we are not using it that would really clean up our package.json file.

What's there at the moment just came from the initial setup, I was thinking maybe keep it but change to match what is used in create-react-app, they've got a nice baseline that would help keep to a code style especially if we get a lot of contributors?

Ok cool - I'll leave that for you to do then


Add Deco Device as additional attribute for zone-presence information

Instead of querying all connected clients for the complete mesh network, this modification will first query which deco devices exist and then query the clients per deco device.
For each client, we add the deco device name as an additional attribute (deco_device) such that you can use this integration also for room-presence detection.
Per refresh-loop, maybe one call could be removed if somehow we would cache the deco devices instead of requesting them.
This feature is also referred to in issue #17

Looking pretty good, if you can fix the LINT issue and the readme typo then I think we should be good to merge it in.


docs: Code example link directing to 404 Not Found

The following SST.dev pages have links to view code in GitHub for the "Rest API" example:

https://sst.dev/examples/index.html
https://sst.dev/examples/how-to-create-a-rest-api-with-serverless.html

However, in the repo, the example has been created under the name rest-services instead of rest-api. This leads to the user being redirected to GitHub's 404 Page not found.
Proposed solution:

Recreate example as rest-api, replacing rest-services

Thank you!


zint: 2.11.0 -> 2.11.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for zint is: "A barcode generating tool and library"
meta.homepage for zint is: "http://www.zint.org.uk"
meta.changelog for zint is: "https://github.com/woo-j/zint/blob/2.11.1/ChangeLog"
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.11.1 with grep in /nix/store/wwfcccqdr7c55shbg8hayjhaxqb1jgkx-zint-2.11.1
found 2.11.1 in filename of file in /nix/store/wwfcccqdr7c55shbg8hayjhaxqb1jgkx-zint-2.11.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
zint

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/wwfcccqdr7c55shbg8hayjhaxqb1jgkx-zint-2.11.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A zint https://github.com/r-ryantm/nixpkgs/archive/e6434dbde2287807ec2c129366950fac38c62276.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/wwfcccqdr7c55shbg8hayjhaxqb1jgkx-zint-2.11.1
ls -la /nix/store/wwfcccqdr7c55shbg8hayjhaxqb1jgkx-zint-2.11.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

zint

Maintainer pings
cc @azahi for testing.

Handled in #187991


CSS part of Vue app is not rendered on dev server

Describe the bug
The <style> part of  SFC(Single File Component) is not rendered when launching Vue App using SWA CLI via dev server.
To Reproduce
Steps to reproduce the behavior:

Create a new Vue app with npm init vite@latest my-vue-app --template vue
cd my-vue-app && npm i
Type in command swa start http://localhost:3000 --run "npm run dev"
Click on http://localhost:4280
Displaying HTML that does not reflect CSS written in <style> of App.vue (e.g. not centered)

Expected behavior
The HTML with CSS is displayed as if it was started on the native dev server.
Screenshots
Start with SWA CLI (http://localhost:4280')

Start with Vite dev server (http://localhost:3000)

Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version [95.0.4638.69]

Additional context
If run it from static files after build, like swa start dist, it will be rendered correctly.

Hey @k-miyake can you please share a screenshot of the network/console tabs from the browser's devtool?

@manekinekko Here is a screenshot of the network/console tabs.

Looks like this issue is caused by #346

I'm also experiencing this issue using Vite and SvelteKit. Due to another issue described here, I had to temporarily downgrade to 0.8.0 to get to this point. I thought I'd bring it up because it sounds very similar to what's happening here.
I created a repo to recreate the issue: https://github.com/LHousehold/example-issue-azure-swa-sveltekit
The repo's readme describes the issue, but basically it seems like the file with the relevant CSS is not being loaded because Vite uses query params which route to different content.
http://localhost:3000/src/routes/index.svelte?svelte&type=style&lang.css
When accessed directly and working correctly, the above returns different content than the below, as if they are completely different files.
http://localhost:3000/src/routes/index.svelte
But when using the cli with port 4280, these two paths both return only the content from /index.svelte without the query params. I suspect k-miyake is facing a similar issue.

I think the issue @LHousehold reported with SvelteKit is the same issue I'm having, which is caused by Vite's dev server not reading the CSS correctly when started on port 4280 of the SWA CLI.

@manekinekko I have confirmed that this has been fixed in SWA CLI 0.8.2. Thank you for your support.

I'm having the same problem as @k-miyake with version 0.8.3 when using Vite and Vue.

We have fixed this issue in the next release. Will schedule a release soon.


Unable to build metacall in Visual Studio 2019

🐛 Bug Report
When building metacall in MSC 2019, getting the following error
source/detours/funchook_detour/funchook/src/funchook/funchook.lib', needed by 'funchook_detourd.dll
source/tests/src/google-test-depends-build/lib/Debug/gtestd.lib', needed by 'preprocessor-testd.exe', missing and no known rule to make it
Expected Behavior
According to the cmake, funchook should be downloaded using download.bat, but the download is not happening
Gtest is not getting installed
Possible Solution
Maybe can try to replace ExternalProject to FetchContest
Steps to Reproduce
Build metacall in MSC 2019
###Temp solution
Disable fork security
Disable build tests

I think this has been solved or I have been not able to reproduce it anymore.


Include composition losses into the framework

This branch considers the composition losses into the analysis framework. It further fixes some bugs related to the extraction of the galactic longitude / latitude of the GMF lensing in the exposure calculation.
There is a problem when actually performing CI, but this works locally with both cartopy and ligo.skymap installed. Not sure why there is an issue with the coverage report, but I think it's not that big of an issue at this moment.
I am creating a PR into the ta_updates branch for now.

@cescalara Yup, both branches are merged into here 👍

Great, lgtm.


@conda-forge-admin, please add bot automerge

@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/latexcodec-feedstock#8.


'go get' Installation Process Fails

When trying to install the packager using the instruction provided below, the process fails when trying to install the cenkalti/backoff go module. From what I can determine, the cenkalti/backoff module now requires Go 1.18, which has depreciated the use of 'go get' in favor of using 'go install'. I am not super familar with Go, so I am looking for some assistance in make this process work again, as we us this module to build some custom buildpacks for Cloud Foundry.
go get github.com/cloudfoundry/libbuildpack cd ~/go/src/github.com/cloudfoundry/libbuildpack && GO111MODULE=on go mod download cd packager/buildpack-packager &&  GO111MODULE=on go install
`# go get github.com/cloudfoundry/libbuildpack
go: downloading github.com/cloudfoundry/libbuildpack v0.0.0-20231211162543-86d10e150195
go: downloading github.com/blang/semver v3.5.1+incompatible
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading github.com/cenkalti/backoff/v4 v4.2.0
go: downloading github.com/Masterminds/semver v1.5.0
github.com/cenkalti/backoff/v4
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:10:26: syntax error: unexpected any, expecting ]
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:10:38: method has no receiver
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:16:53: syntax error: unexpected [ after top level declaration
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:17:16: method has no receiver
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:17:16: syntax error: unexpected (, expecting name or (
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:42:19: syntax error: unexpected [, expecting (
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:53:25: syntax error: unexpected [, expecting (
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:66:33: syntax error: unexpected [, expecting (
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:70:19: syntax error: unexpected [, expecting (
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:76:2: syntax error: non-declaration statement outside function body
pkg/mod/github.com/cenkalti/backoff/v4@v4.2.0/retry.go:76:2: too many errors
note: module requires Go 1.18`

Instruction for using the Buildpackager Packager are also listed in the Cloud Foundry Docs here: https://docs.cloudfoundry.org/buildpacks/custom.html

Instructions did not work (for me); I had to:
git clone https://github.com/cloudfoundry/libbuildpack.git
cd libbuildpack/packager/buildpack-packager/
GO111MODULE=on go mod download
GOBIN=/tmp/ GO111MODULE=on go install

After what I get a working buildpack-packager, but without some command listed in the documentation:
$ buildpack-packager init --name sidecars-buildpack --path=sidecars-buildpack
Usage: buildpack-packager <flags> <subcommand> <subcommand args>

Subcommands:
        commands         list all command names
        flags            describe all known top-level flags
        help             describe subcommands and their syntax

Subcommands for Custom:
        build            Create a buildpack zipfile from the current directory
        summary          Print out list of dependencies of this buildpack

$ echo $?
2

Just checking to see if someone has looked at this issue. It has broken my teams ability to build and deploy a couple of custom buildpack that we have used for years. If this is not going to be fixed, is there a work around that I can use to continue to build and deploy custom buildpacks?


don't automatically call system pager for help screens

Not sure if you're using a CLI library that doesn't give you a choice about it, but it'd be really awesome if the help screens would just write to STDOUT instead of invoking the pager.

I'm using https://github.com/commander-rb/commander , which does that automatically :(


[video_player] Make video player avfoundation seekTo async

This PR updates the pigeon version that is being used by video_player_avfoundation so it is possible to use [AVPlayer seekTo:completionHandler:] method.
Potentially fixes https://github.com/flutter/flutter/issues/116056 ( Maybe I need some insights from you @stuartmorgan, specially related to this comment https://github.com/flutter/flutter/issues/116056#issuecomment-1342995436 )
This PR follows the step 1 of these instructions https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#changing-federated-plugins
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[ ] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
[x] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Thanks for the contribution! I've left a few comments, and you'll need to fix the unit tests that no longer compile (per the CI failure).
This won't fix the issue you referenced, which is about how position is tracked in the plugin. It doesn't actually have anything to do with the implementation of seekTo.

Thank you for the feedback. Since this is my first contribution, I really appreaciate it.
I will fix all tests. Now, about the github issue. Is it really required to have a issues linked to the PR? If that is the case, I will create one since I could not find any existent one related to this.

Now, about the github issue. Is it really required to have a issues linked to the PR?

Since it's addressing a to-do that didn't have an associated issue it doesn't need one.

All threads resolved.
Please check https://github.com/flutter/plugins/pull/7164/files#diff-ad57f5cf3efac84f7c3c41b77bd4b391d0a37e0f488309dfcf15b08423c71ae8 with care.
I updated that test to be able to properly seek to some part of a video.
I'm also testing that the player position is correct after the seek. So should the test should be renamed?

We've just completed the migration of the plugin code to the flutter/packages repository, as described in https://flutter.dev/go/flutter-plugins-repo-migration, and this repository is now being archived. Unfortunately that means that all in-progress PRs here must be moved to flutter/packages.
Please see our instructions for an explanation of how to move your PR, and if you have any issues moving your PR please don't hesitate to reach out in the #hackers-ecosystem channel in Discord.
Our apologies that your PR was caught in this one-time transition. We're aware that it's disruptive in the short term, and appreciate your help in getting us to a better long-term state!

No problem at all. I am completly in favor of any kind of long term improvements.
I will reopen it in the flutter/packages channel as soon as I find time to work on it.
Thanks for the feedback.


fix: create secrets during upgrades (PROJQUAY-7001)

Hey @harishsurf @dmage sorry for this regression - I'm just wrapping up some local testing for a similar PR that generates facts :
- name: Include vars of the config.yaml into the 'quay_config' variable (2.2).
  ansible.builtin.include_vars:
    file: "{{ quay_root }}/quay-config/config.yaml"
    name: quay_config

Then creates the podman secrets with those - the reason I was thinking of going this route is to protect backwards compatibility. Of course, if the better option is to reset the passwords to what is autogenerated in secret-vars.yaml then I'm all for that, and I'll toss my branch :rofl:

I just submitted https://github.com/quay/mirror-registry/pull/151 with another way - let me know if y'all would prefer to do it another way and I'll close mine!

Replaced by #151.


Add support for command ZREM

Add support for the ZREM command in DiceDB similar to the ZREM command in Redis. Please refer to the following commit in Redis to understand the implementation specifics - source.
Write unit and integration tests for the command referring to the tests written in the Redis codebase 7.2.5. For integration tests, you can refer to the tests folder. Note: they have used TCL for the test suite, and we need to port that to our way of writing integration tests using the relevant helper methods. Please refer to our tests directory.
For the command, benchmark the code and measure the time taken and memory allocs using benchmem and try to keep them to the bare minimum.

Hey @JyotinderSingh, Can I work on this issue?

Hey @JyotinderSingh, Can I work on this issue?

Assigned.

Hello @ankkyprasad,
There has been no activity on this issue for the past 5 days.
It would be awesome if you keep posting updates to this issue so that we know you are actively working on it.
We are really eager to close this issue at the earliest, hence if we continue to see the inactivity, we will have to reassign the issue to someone else. We are doing this to ensure that the project maintains its momentum and others are not blocked on this work.
Just drop a comment with the current status of the work or share any issues you are facing. We can always chip in to help you out.
Thanks again.

Hi @ankkyprasad. Are you still working on this? If not, I can pick this up.
Thanks

Hi @ankkyprasad. Are you still working on this? If not, I can pick this up.
Thanks

Assigned.


1.x

what is this?

Unclear the purpose of this PR. Please re-create if you need something and provide more explanation.

Note: the 1.x branch was created to save a state before moving to https://github.com/mapnik/node-mapnik/blob/master/CHANGELOG.md#300. It is identical to the v1.4.5 tag. So I will delete the 1.x branch now.


fix wrong union generatedName flag and refine templated model naming

All changed packages have been documented.

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/517/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/517/


Add specific thumbnail for NFTs instead of a placeholder image

Currently, the MetadataViews.Display thumbnail of the Moments are a hardcoded url:
https://ipfs.dapperlabs.com/ipfs/Qmbdj1agtbzpPWZ81wCGaDiMKRFaRN3TU6cfztVCu6nh4o, but it should be different between Moments, which limit the display of Moments in other Flow ecosystem projects.
Is there any way to get the thumbnail like collective.xyz?

Or do you have any plan to fix this?

Hello! In the near future we are looking to provide a number of media URLs along with each NFT.
Unfortunately some of the parameters needed to create the media URIs are currently not on chain.
We have in flight an image gateway that will provide somewhat easier to consume URLs and require only on chain data. Once that is in, we will plan to make use of those in our Medias metadata view which you can retrieve via Cadence query.
Please see:
https://www.flow-nft-catalog.com/ for a description of the metadata views we plan to implement)
While I can't give you a definite timeline on this, I can refer you to an WIP progress branch for the feature (note that the pattern for building URIs will change from the helper currently in the branch):
https://github.com/dapperlabs/nba-smart-contracts/tree/feature/core-nft-views
Let me know if you have any further questions or concerns.

@jrkhan Hi! Thank you for your reply! I still have two questions:

Could you make thumbnail available ahead of other media types? It would be nice for the other projects to display the Moments
Or s there any way for other projects to get the thumbnail now like collective.xyz?

Hello!

Unfortunately, there isn't really a great way to make just the thumbnail available ahead of the other types (once we can support one type, we'll be able to support all of them, if that makes sense)
There is a way to get the thumbnail now, but you would need to know the 'play guid '(not currently on chain), along with the 'set visual id' (also not on chain) and the 'set name' in order to build the image url. You might be able to get at these through the nba topshot graphql api though. Do you have a timeline for when you're looking to have the thumbnail?

@jrkhan Hi! Thank you for your response!
I created an application named drizzle(https://drizzle33.app) weeks ago. It's a platform for anyone to create airdrop and NFT raffle, and I'm going to add NBATopshot to it so that the community can create NFT raffle with Moments as rewards. But I found the thumbnail is not displayed as expected, so I came here and asked for details. It would be nice to access to the thumbnails now so that I can finish my integration asap, but it's ok if it is not open to public now, I'll wait for the implementation of Metadaviews. Thank you!

Hello @LanfordCai - wanted to let you know this should be resolved by:
https://github.com/dapperlabs/nba-smart-contracts/pull/161
Which should now be available on mainnet.
You should also find a new medias metadata view that should provide additional images for each moment.

It awesome! Thank you @jrkhan

Hello @jrkhan , I want to know is it allowed to display this thumbnail exposed by TopShot contracts in my Flow projects? Or it will cause some IP issues?


DON'T ENABLE THINGSWITHOUT USER'S PERMISSION FFS

Description of the new feature / enhancement
So only today I realised that double tapping ctrl makes the cursor highlight for no reason.  AND I DIDN'T ENABLE THIS.  Imagine if I broke into your house and started shuffling around your stuff ffs
Scenario when this would be used?
fdsgtrdfhgrtjuh
Supporting information
No response

PowerToys does  after an update always inform the users of the new things added to PowerToys. We try to highlight new tools in the What's new section and in the readme. Mouse cursour is a feature we have since over a year.


Non-deterministic segfault when enabling BACKWARD_HAS_DW and BACKWARD_HAS_BACKTRACE

I am using gcc 9.4 on linux with both BACKWARD_HAS_DW=1 and BACKWARD_HAS_BACKTRACE=1, and use single thread to call backward API, and then I occasionally catch a segfault from libdw. Here is the backtrace from gdb
Thread 7 "partitioning" received signal SIGSEGV, Segmentation fault.
0x00007ffff695f118 in __libdw_alloc_tail () from /scratch2/wwu/anaconda3/envs/py39/lib/libdw.so.1
(gdb) bt
#0  0x00007ffff695f118 in __libdw_alloc_tail () from /scratch2/wwu/anaconda3/envs/py39/lib/libdw.so.1
#1  0x00007ffff69569cd in read_srclines () from /scratch2/wwu/anaconda3/envs/py39/lib/libdw.so.1
#2  0x00007ffff6957d66 in __libdw_getsrclines () from /scratch2/wwu/anaconda3/envs/py39/lib/libdw.so.1
#3  0x00007ffff6957fff in dwarf_getsrclines () from /scratch2/wwu/anaconda3/envs/py39/lib/libdw.so.1
#4  0x00007ffff6958167 in dwarf_getsrc_die () from /scratch2/wwu/anaconda3/envs/py39/lib/libdw.so.1
#5  0x000055555707af65 in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::resolve (this=0x55555bd5b820, trace=...) at /scratch2/wwu/legion-master/runtime/realm/backward.hpp:1908
#6  0x0000555557075760 in Realm::RuntimeImpl::realm_backtrace (signal=6) at /scratch2/wwu/legion-master/runtime/realm/runtime_impl.cc:2934

Any idea about the segfault?

The value from gdb seems to be valid:
(gdb) p cudie
$1 = (Dwarf_Die *) 0x7fffdc184c20
(gdb) p *cudie
$2 = {addr = 0x7fffca6665df, cu = 0x7fffdc6bd6b0, abbrev = 0x7fffdc6ccfd0, padding__ = 0}
(gdb) p/x trace_addr
$3 = 0x5555570755ee
(gdb) p/x mod_bias
$4 = 0x555555554000

Maybe try under valgrind. I wouldn't rule out a bug in libdw. You can also try a different backend, like libbfd to compare.

I tried DBACKWARD_HAS_BACKTRACE_SYMBOL , and it works. I can not get libbfd compiled, because it needs libiberty-dev, which can not be retrieved from conda.
The valgrind is a little bit tricky, because my program is a GASNet program and valgrind complains about GASNet and abort.

Get another backtrace, also segfault:
#6  0x00007f450f40c92a in dwarf_highpc () from /lib/x86_64-linux-gnu/libdw.so.1
#7  0x00007f450f40f868 in dwarf_ranges () from /lib/x86_64-linux-gnu/libdw.so.1
#8  0x000055f99ee3f410 in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::die_has_pc (die=0x55f9a45555e0, pc=28448202) at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2000
#9  0x000055f99ee4180b in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::deep_first_search_by_pc<backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::inliners_search_cb> (parent_die=0x55f9a4555670, pc=28448202, cb=...)
    at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2065
#10 0x000055f99ee417ea in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::deep_first_search_by_pc<backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::inliners_search_cb> (parent_die=0x55f9a4555700, pc=28448202, cb=...)
    at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2062
#11 0x000055f99ee417ea in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::deep_first_search_by_pc<backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::inliners_search_cb> (parent_die=0x7f44f89e81c0, pc=28448202, cb=...)
    at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2062
#12 0x000055f99ee3f022 in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::resolve (this=0x55f9a45558a0, trace=...) at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:1922

Another issue, BACKWARD_HAS_BACKTRACE and BACKWARD_HAS_UNWIND generate different backtrace.
BACKWARD_HAS_BACKTRACE (wrong, see frame 6)
#16   Source "../sysdeps/unix/sysv/linux/x86_64/clone.S", line 97, in __clone
#15   Source "/build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c", line 478, in start_thread
#14   Source "/scratch2/wwu/legion-master/runtime/realm/threads.cc", line 784, in pthread_entry
#13   Source "/scratch2/wwu/legion-master/runtime/realm/threads.inl", line 98, in thread_entry_wrapper<Realm::ThreadedTaskScheduler, &Realm::ThreadedTaskScheduler::scheduler_loop_wlock>
#12   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 1216, in scheduler_loop_wlock
#11   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 1105, in scheduler_loop
#10   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 1367, in execute_task
#9    Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 304, in execute_on_processor
#8    Source "/scratch2/wwu/legion-master/runtime/realm/proc_impl.cc", line 1129, in execute_task
#7    Source "/scratch2/wwu/legion-master/runtime/legion/legion.inl", line 21167, in legion_task_wrapper<daxpy_task>
#6    Source "/scratch2/wwu/legion-master/tutorial/07_partitioning/partitioning.cc", line 278, in check_task
#5    Object "/usr/lib/x86_64-linux-gnu/libc-2.31.so", at 0x7f714c1a8fd6, in
#4  | Source "/build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c", line 970, in get_sysdep_segment_value
      Source "/build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c", line 509, in _nl_load_domain
#3    Source "/build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c", line 81, in abort
#2    Source "../sysdeps/unix/sysv/linux/raise.c", line 51, in raise
#1    Object "/usr/lib/x86_64-linux-gnu/libpthread-2.31.so", at 0x7f714c6eb420, in __restore_rt
#0    Source "/scratch2/wwu/legion-master/runtime/realm/runtime_impl.cc", line 2876, in realm_backtrace
(py39) wwu@g0004:/scratch2/wwu/legion-master/tutorial/07_partitioning$ ./partitioning -ll:cpu 1 -ll:force_kthreads

BACKWARD_HAS_UNWIND (correct, see frame 8)
#19   Object "", at 0xffffffffffffffff, in
#18   Source "../sysdeps/unix/sysv/linux/x86_64/clone.S", line 95, in __clone
#17   Source "/build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c", line 477, in start_thread
#16   Source "/scratch2/wwu/legion-master/runtime/realm/threads.cc", line 781, in pthread_entry
#15   Source "/scratch2/wwu/legion-master/runtime/realm/threads.inl", line 97, in thread_entry_wrapper<Realm::ThreadedTaskScheduler, &Realm::ThreadedTaskScheduler::scheduler_loop_wlock>
#14   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 1217, in scheduler_loop_wlock
#13   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 1105, in scheduler_loop
#12   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 1366, in execute_task
#11   Source "/scratch2/wwu/legion-master/runtime/realm/tasks.cc", line 302, in execute_on_processor
#10   Source "/scratch2/wwu/legion-master/runtime/realm/proc_impl.cc", line 1129, in execute_task
#9    Source "/scratch2/wwu/legion-master/runtime/legion/legion.inl", line 21165, in legion_task_wrapper<daxpy_task>
#8    Source "/scratch2/wwu/legion-master/tutorial/07_partitioning/partitioning.cc", line 256, in daxpy_task
#7    Source "/build/glibc-SzIz7B/glibc-2.31/assert/assert.c", line 101, in __assert_fail
#6    Source "/build/glibc-SzIz7B/glibc-2.31/assert/assert.c", line 92, in __assert_fail_base
#5    Source "/build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c", line 79, in abort
#4    Source "../sysdeps/unix/sysv/linux/raise.c", line 51, in raise
#3    Object "/usr/lib/x86_64-linux-gnu/libpthread-2.31.so", at 0x7f10d256341f, in
#2    Source "/scratch2/wwu/legion-master/runtime/realm/runtime_impl.cc", line 2875, in realm_backtrace
#1    Source "/scratch2/wwu/legion-master/runtime/realm/new_backward.hpp", line 878, in load_here
#0    Source "/scratch2/wwu/legion-master/runtime/realm/new_backward.hpp", line 860, in unwind<backward::StackTraceImpl<backward::system_tag::linux_tag>::callback>

Interesting that Valgrind complains about GASNet. I only learned about GASNet now, and I do not understand what it does that upsets Valgrind.
Note that there is two level of dependencies in backward-cpp. Stack walking, and trace resolving.
Walking the stack find out which functions was traversed. You get the object file and memory address of the machine code. This is what you select with BACKWARD_HAS_UNWIND, BACKWARD_HAS_LIBUNWIND  and BACKWARD_HAS_BACKTRACE (see https://github.com/bombela/backward-cpp/blob/master/backward.hpp#L98).
The second level is one of the library to read the debug symbols from the object files. Which is used to map object file to source file and line numbers.
In your two traces, unwind should give you the correct stack walking as it comes from the compiler itself.

Get another backtrace, also segfault:
#6  0x00007f450f40c92a in dwarf_highpc () from /lib/x86_64-linux-gnu/libdw.so.1
#7  0x00007f450f40f868 in dwarf_ranges () from /lib/x86_64-linux-gnu/libdw.so.1
#8  0x000055f99ee3f410 in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::die_has_pc (die=0x55f9a45555e0, pc=28448202) at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2000
#9  0x000055f99ee4180b in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::deep_first_search_by_pc<backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::inliners_search_cb> (parent_die=0x55f9a4555670, pc=28448202, cb=...)
    at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2065
#10 0x000055f99ee417ea in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::deep_first_search_by_pc<backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::inliners_search_cb> (parent_die=0x55f9a4555700, pc=28448202, cb=...)
    at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2062
#11 0x000055f99ee417ea in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::deep_first_search_by_pc<backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::inliners_search_cb> (parent_die=0x7f44f89e81c0, pc=28448202, cb=...)
    at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:2062
#12 0x000055f99ee3f022 in backward::TraceResolverLinuxImpl<backward::trace_resolver_tag::libdw>::resolve (this=0x55f9a45558a0, trace=...) at /scratch2/wwu/legion-master/runtime/realm/new_backward.hpp:1922

Sometimes your traces are sorted in a different order. Is this intended?
Where are the frames 0 to 5? The segfault should be at frame 0 was it inside the dwarf library?

I figured out the problem. The stack allocated for handling the signal is too small, increasing the stack fixed the problem


Failed to resolve compatible distributions: Sphinx==6.1.3 requires docutils<0.20,>=0.18 but docutils 0.16 was resolved

Hi! I'm trying to build a Pex of an application that has s3 as a dependency. But when I try that, I get the following error:
$ pex ./ -o snapper-backups.pex -e snapper_backups.main
Failed to resolve compatible distributions:
1: Sphinx==6.1.3 requires docutils<0.20,>=0.18 but docutils 0.16 was resolved

The issue can be more easily reproduced by simply trying to Pexify the s3 [1] package:
$ pex s3
Failed to resolve compatible distributions:
1: Sphinx==6.1.3 requires docutils<0.20,>=0.18 but docutils 0.16 was resolved

[1] The version of s3 that is being used here is 3.0.0.
This appears to be a bug with Pex because I can properly install s3 with Pip.

One key principle to keep in mind with Pex is that it does not break you. An unfortunate consequence of this is that new features, even when better, are not the default (this will change on the next breaking release 3.0.0).
So you're missing an option here, which is to use the modern Pip resolver:
$ pex s3 --resolver-version pip-2020-resolver
/tmp/tmp9emh862b/.bootstrap/pex/environment.py:654: PEXWarning: The `pkg_resources` package was loaded from a pex vendored version when declaring namespace packages defined by:

1. sphinxcontrib-devhelp==1.0.2 namespace packages:
  sphinxcontrib

2. sphinxcontrib-jsmath==1.0.1 namespace packages:
  sphinxcontrib

3. sphinxcontrib-serializinghtml==1.1.5 namespace packages:
  sphinxcontrib

4. sphinxcontrib-qthelp==1.0.3 namespace packages:
  sphinxcontrib

These distributions should fix their `install_requires` to include `setuptools`
  pex_warnings.warn(
Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

So that toggles the default of --resolver-version pip-legacy-resolver.

@NiklasRosenstein I'm going to close this as an answered question, but please speak up if you have more that the Pex CLI help doesn't provide enough information for.

Thanks for the explanation @jsirois!
On a side note, I only just realized that s3 is not the package I needed anyway, it's boto3. 😅


Optionally create new figure automatically

Feature request
I think it would be nice to be able to configure (as a runtime option or somesuch) the behavior of the plotting methods if an ax is not passed. In settings like the Jupyter Notebook, I would prefer a new figure to be created automatically. I realize that you can achieve this by passing figure size kwargs like figsize, but it would be nice if you didn't have to.
Or, is there an easy way to runtime patch xarray.plot.utils.get_axis or another function to achieve this?

Sorry this didn't get a response @zmoon, particularly given your contributions to xarray and the broader community.
That said, I think I get this already, unless I'm misunderstanding?

Thanks @max-sixty. I think it was with %matplotlib widget (ipympl) that I got the behavior I described. With %matplotlib inline (default inline backend) the figures get closed[^1] at the end of a cell, so the two plot commands would have to be in the same cell to get an overlay, which is fine. But with ipympl, this is not the case so you have to be more careful.

Example

[^1]: You can disable this behavior with %config InlineBackend.close_figures=False and get an overlay from plot commands in separate cells, but then you have to manually refresh the plot it seems.

I assume this has been resolved then?
If not, feel free to reopen.


Add FormData.entries() support

See: https://developer.mozilla.org/en-US/docs/Web/API/FormData/entries

Many thanks for your contribution - a new snapshot build is available.

@rbri Symbol.iterator is apparently not working - any idea why? My understanding was that ES6Iterator is correctly implementing this.
See:
    public void entriesIterator() throws Exception {
        final String html
            = HtmlPageTest.STANDARDS_MODE_PREFIX_
            + "<title>foo</title>\n"
            + "\n"
            + "\n"
            + "";

        loadPageWithAlerts2(html);
    }

Okay. That seems to be correct if I compare to real browsers.
Seems like an issue on our side and since we're using a different FormData in javascript that apparently implements this. I'm currently working on adding support for this ... nevermind.

Simply provide a test case and i will have a look / try to fix it

I think it's fine. I was having issues since we're overriding the FormData implementation and using a blob in the end to send stuff ... I think the entries() support is okay here for now.


power using recursion

📑 Description

🐞 Related Issue

Closes #452

I made the required changes; please review.


Modified README format to match main RackHD repository

Coverage remained the same at 20.202% when pulling f28135405e97314fb3c4db3018968fb28aca28d6 on readme into f41bfb387d4b7d2ee1aced9762c9b903b69bed71 on master.

Coverage remained the same at 20.202% when pulling f2d1d1cf434adcf79be17217e1e491e665f7ed20 on readme into f41bfb387d4b7d2ee1aced9762c9b903b69bed71 on master.


WorkflowQueue.take takes element from the tail of the queue instead of its head

What was changed
WorkflowQueue.take does not preserve queue semantics by taking elements from the tail of the queue (the most recently added ones) instead of its head (the earliest added ones).
Why?
Let WorkflowQueue maintain the expected queue semantics.
Checklist

Closes -
How was this tested: new unit test
Any docs updates needed? -

Thank you for your contribution!

After more thinking, this probably has to be reversed and tabled till the time when we make backward-incompatible changes. This fix can break workflows replaying that was originally executed on an old version of code.


Remove TSDX

Currently all of the JavaScript repositories are set up with automated eslint and VS code. ( linting errors are fixed on save)
the SDK Is having issues and showing conflicts when trying to save. This task is to remove the dependency of tsdx from the SDK and use eslint/typescript directly. Hopefully this will resolve conflicts with eslint
Definition of done

[ ] No more use of tsdx in the code base, completely removed from package.json
[ ] install a "standard" typescript compile "tsc" with bable
[ ] README.md in SDK and integration updated to not have tsdx as a dependency
[ ] install_prerequisits.sh in the integration repository does not install tsdx

Hint: check what is done in ID and Demo apps

done


This extension does not work on MacBook Pro

macOS High Sierra v 10.13.2
VS Code  Version 1.19.0 (1.19.0)
typescript Version 2.6.2
Node v8.9.3
I clicked the "Go to step definition" and nothing happened:

The setting looks correct to me:

And this is the application:
cucumber-protractor-harness-master.zip

I have the same issue. I am using Ubuntu 17.10. My version of VSCode is as follows:
Version 1.20.0-insider
Commit f2b21097100fc2fc0e84cc34f453c9a85a49a2bb
Date 2018-02-02T06:17:03.200Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

no fix yet? this is 2019 and has been going on for 2 years since this ticket was raised!

Our experts are working on it...

It would be a very useful extension when it will work...


Position is buggy

Position is different for various tokens. Some tokens seem to stick to the last position settings and others update. Position preview illustration also varies despite settings being identical to those of the second to last change. Placement is also illogical - middle placement shows the text above the frame etc.

Can't reproduce most of this aside from

Position is different for various tokens.

And I'm not even sure if it's the same meaning. Just found that non-top positions get affected by the presence of the token's name at the bottom, so if the name is shown inconsistently that would lead to mild inconsistencies as well. Not anything like the rest of the issue though.
If you can provide any more information it would be appreciated.


[web] Migrate selectable_region to static interop.

This CL migrates selectable_region to static interop.

@ditman @eyebrowsoffire ptal. The analyze tests are failing because of dom.dart living in lib/.  Where should the dom shim live?

@eyebrowsoffire I moved dom.dart to lib/src which fixed the analyzer issues, so the question above is resolved.

(putting dom in lib would've made it visible to users in IDEs, which I don't think we'd want).


Special characters in the template name cause a problem in TameMyCerts

While testing something else, I created a template named UserÜöäß/&|(). A certificate request based on the template was denied until I told the CA to no longer use TameMyCerts.
Two events were reported:
04/08/2023 10:52:25 53 Warning          Active Directory Certificate Services denied request xx because The parameter
                                        is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER).  The request was
                                        for xxx\xxx.  Additional information: Denied by Policy Module
04/08/2023 10:52:24 77 Warning          The "TameMyCerts" Policy Module logged the following warning: The Active
                                        Directory connection to xxx has been reestablished to xxx.

Sorry, I have not tested which of the characters /, &, |, ( or ) in the template name cause the problem.
TameMyCerts itself does not log an event.

Hello @PaulBlenderman thanks for your feedback. This is because the template name contains characters that are not valid for file name. Because this is not properly handled, it causes the verification process to crash. I was able to reproduce this and will include a fix in the upcoming version.


can this taf parser be used to parse a dataframe with multiple (1000s) of rows?

Hi,
is your parser capable of taking more than 1 row at the same time?
For instance if you load 1000s of TAFs in pandas, can you apply this function to parse it?
Or any example of how to use this in pyspark?
Thanks!

Hello @JB-data
The parser can only parse a single code at the same time. If you want to parse 100 TAF messages you have to call the method parse 100 times


Errors following Connecting a bot to Twilio

I'm following the connecting to a bot to twilio document

https://docs.microsoft.com/en-us/azure/bot-service/bot-service-channel-connect-twilio?view=azure-bot-service-4.0

I managed to install the Microsoft.Bot.Builder.Adapters.Twilio nuget package however when I try creating the controller this line
await _adapter.ProcessAsync(Request, Response, _bot);
Gives me an error saying
Severity	Code	Description	Project	File	Line	Suppression State Error	CS7036	There is no argument given that corresponds to the required formal parameter 'cancellationToken' of 'TwilioAdapter.ProcessAsync(HttpRequest, HttpResponse, IBot, CancellationToken)'	EchoBot	C:\Users\<username>\Desktop\02.echo-bot\Controllers\BotController.cs	59	Active
Did I do something wrong? Is there a work around?

Thank you for the questions, @BetaLixT
It seems the code snippet in the doc will not work after this commit from November: https://github.com/microsoft/botbuilder-dotnet/commit/1c5b14e84bccbca4ee879053d63aedb22b1bd585
That means it the code snippet is for package versions earlier than 4.7.0. It's unclear if the change should be reverted or if the doc should be updated. @garypretty - Can you comment?
In the meantime, I suspect you will be fine if you follow the code in the samples repo:
await _adapter.ProcessAsync(Request, Response, _bot, default(CancellationToken));

Hi thank you for the reply, I did find this earlier and can confirm that it works as expected

@emgrol - If we want to fix these docs, do we merge into live or live-sync-work?

@BetaLixT Thanks for flagging this issue.  As pointed out above, there were some changes made to the adapter in November and the docs do need updating to reflect this.  Also, another thing to clarify, is that the adapters (Twilio / Facebook / Slack) are currently still in preview.
The 4.8 and 4.9 adapter packages reflected this with a -preview tag, but for some reason it would appear that the 4.7 package did not have this tag.  I wanted to ensure that you were aware of this.
We are not expecting any significant change in the adapters in terms of behavior, but there may be some minor changes between now and bringing them out of preview (hopefully in 4.10). Just something to be aware of as and when you update your packages.


TEXT Layer could not be rendered

PAGE 1 (unnamed), KEY (1, 1) (titled-text), TEXT LINE 2 (content)] Layer could not be rendered
Tried python 3.9 and 3.10
Did anybody had the sam problem and solved it?

Found it, just happens when installing with pip, if I use scripts from here it works.


springfox-data-rest : @Param annotation not supported

Module: springfox-data-rest
Version: 2.6.1
@Param annotation is not supported, you have to add a @RequestParam one in order for the custom query to be interpreted as GET (instead of POST) and for the parameter to be named.
see http://stackoverflow.com/questions/40718680/spring-data-rest-springfox-and-jparepository-custom-finders

Closing this a duplicate of #1623


Hotspot moving when data-pitch not 0

When setting the hotspot position, if the parameter data-pitch is pointing at the bottom, or top of the 360 image/video, when you move the camera left and right, the hotspot is not maintaining the position.
The more data-pitch parameter differ from 0, the more the element is moving when you rotate the camera left and right.
In the example the data-pitch is "-70".
Example:
https://codepen.io/erik-c/pen/vYZjYqq

Hello @ipermediastudio!
Actually, I'm sorry to say but that's not our official feature but only for the demo.
We're planning to add it as our official feature, with the big update of PanoViewer.
I didn't write that code so I don't know everything about it, but I think it should be updated with the part where it calculates hotspot position to use the camera matrix.


Ask / warn user to setup a venv before starting notebooks

As the notebooks are installing several dependencies, it would be great to add a note about creating a python venv before running it.
What do you about it? Is it obvious or nice to have?

this is not obvious ! (not for me at least ! :))

@arthurPignet a good element to add in the package documentation on which you are working with PR #233


Adding 8.3Filename utilities for windows to support space in a path while building Boost with MinGW

…hile building Boost with MinGW

file 'hunter_windows_utils.cmake' adds utilities to convert long path to 8.3Filename and also provides command to set the environment with new paths

Okay so the space issue occurs in following places.

I think when while cmake runs command of external project it exports following extra variable in the environment of the command - CC, CXX, RC (there are more but relevant ones are stated here.) I have noted these by running command 'set > output.txt' in normal and in external project environment. Boost uses variable CC when building with MinGW. To nullify these I have added file hunter_windows_utils which provides function which sets variable CC, CXX and RC to 8.3Filename format. This command must be run before every configure and build command of external project. Hence the new build command becomes "env_cmd" "&&" "configure_cmd". Adding env_cmd with extra 'COMMAND' option does not work as every command runs in a new environment.

url_sha1_boost_library.cmake.in creates a file boost_user_jam in which toolchain options should not contain spaces which can be fixed with 8.3Filename.

Just for the record, previous PR: https://github.com/ruslo/hunter/pull/258

@sumedhghaisas Thanks for the patience, hacking custom schemes is a pain. Hacking Boost scheme is a double pain :) Please apply new changes according to my notes, want to test what we have so far. You can leave set cc=... && cxx=... for now will try to figure out how to improve this nicely.

Also one more idea just came to my mind. What if instead of trying to fix CMAKE_CXX_COMPILER in build scheme do make it in toolchain?
See:

toolchain file for MinGW: https://github.com/ruslo/polly/blob/master/mingw.cmake
picking compiler: https://github.com/ruslo/polly/blob/master/compiler/gcc.cmake

Please pardon my inexperience but I am confused about the role of polly in hunter but I think making the changes in toolchain level is a very good idea as the changes will be done on more basic level. I will first spend some time understanding polly and its role.

Okay I now have sort of very basic understanding of the role of polly. But I think we should also make changes to build because people should be able to use default cmake toolchains right?

I am confused about the role of polly in hunter

It's just a collection of CMake toolchains + some helper tools to simplify their usage. Both Polly and Hunter can be used independently as a stand-alone projects.

But I think we should also make changes to build because people should be able to use default cmake toolchains right?

If we will fix the Boost build it doesn't make sense to introduce any changes in Polly. At least as far as I understand spaces in path to MinGW compiler is a sole Boost issue. My idea was about updating MinGW toolchain in Polly so in can do the "8.3Filename" conversion which will automatically fix Boost build for Hunter (will it? need to test first). And in Hunter we can check that path to MinGW compiler contains spaces and report an error before build. On the wiki page we can add workaround notes:

reinstall MinGW compiler to path with no spaces
use Polly toolchain with 8.3Filename conversion trick

Also general thought that there may be more issues with spaces in other packages which can be fixed by modifying toolchain (instead of modifying several schemes).

Yes, I agree that if we don't come up with a common solution to fix the space problem it won't be worth the effort to fix it for every project. What about this -

Create a macro which reset all environment variables to 8.3Filename and also reset important cmake variables to 8.3Filenames such as CMAKE_C_COMPILER, CXX_COMPILER and etc.
To support 8.3Filename project has to follow separate build, configuration, install cmake files and has to call this macro as the first thing.
Important thing to notice is that build, configuration and install cmake files are run on a separate environment and won't affect the original run.

Let me see if I can get it working. I will create a dedicated pull request on which we can talk about this common solution issue.

Create a macro which reset all environment variables to 8.3Filename

Another pattern I've learned to avoid - no implicit changes :) Let's focus on exact variables CC, CXX, RC. We can always add more if needed.

Let me see if I can get it working. I will create a dedicated pull request on which we can talk about this common solution issue.

Okay, here is my proposal. Do one more "focusing" trick - do this conversion only if there is space in path (you can check it by regex). So condition will be:
if(CMAKE_HOST_WIN32 AND MINGW AND space_in_path_found)
  set(do_8_3_filename_trick TRUE)
else()
  set(do_8_3_filename_trick FALSE)
endif()

if(do_8_3_filename_trick)
  ...
  hunter_windows_to_snf_filename(${CMAKE_AR} CMAKE_AR_snf)
  file(APPEND ${boost_user_jam} "  : \"${boost_compiler_snf}\"\n")
  file(APPEND ${boost_user_jam} "  : <archiver> \"${CMAKE_AR_snf}\"\n")
else()
  # do not call hunter_windows_to_snf_filenames
  ...
endif()

if(do_8_3_filename_trick)
  ...
  hunter_windows_env_command("windows_env_command")
  set(bootstrap_cmd "${windows_env_command}" "&&" "bootstrap.bat")
else()
  # do not call hunter_windows_env_command
  # do not add "&&" to ExternalProject_Add commands to avoid errors
endif()

in this case if something will went wrong user have a workaround way - just install MinGW compiler to another path :) So now we can be sure that "set" "cc=${CMAKE_C_COMPILER_SNF}" "&&" "set" "cxx=${CMAKE_CXX_COMPILER_SNF}" will not broke existing builds and will not lead to some errors that user can't solve. It means that I'm okay with merging work-in-progress version of this pull request (+ see my previous notes). For further improvements let's refer to the exact issues:

Improve internal files layout: https://github.com/ruslo/hunter/issues/288
Separate scripts: https://github.com/ruslo/hunter/issues/290

Yes CC, CXX and RC for environment variables. And rather than changing CMAKE_C_COMPILER and all such important cmake variables we will introduce CMAKE_C_COMPILER_SNF and all. So that user can use both. what do you think?

So that user can use both. what do you think?

Okay, sound good

Seems abandoned. Feel free to reopen on updates.


how to  query data from deep storage through SQL

I am able to query data from June 30th through SQL, and my Druid data retention policy is set to one month. There are segments from April stored in OBS (Object Storage Service). I would like to restore these segments into Druid so that they can be queried via SQL. In other words, I want to be able to query data from deep storage through SQL

Hi @youFireFly , have you gone through https://druid.apache.org/docs/latest/querying/query-deep-storage/ yet?

Hi @youFireFly , have you gone through https://druid.apache.org/docs/latest/querying/query-deep-storage/ yet?

First of all, I want to say thank you. I have read the Edit retention rules: json described in the article, but I did not find it on the ui page. I only found Edit retention rules, but there was no json edit box. Is it because of the version problem


podman run does not support the --mount option

We are getting requiest to add this option to projectatomic docker.  The reason for this is you can not use mount points with that container a ":".
https://bugzilla.redhat.com/show_bug.cgi?id=1539161

Closing in favor of #1192


WIP: bos-tasks-mpxnt: Check for NPM dependency updates

Check for any outstanding update of point version of any outstanding NPM package dependency

[ ] npm-update

npm-update in progress on bos-tasks-mpxnt.
Log: https://<IP_ADDRESS>:8493/logs/npm-update-595-20190316-125151/


NVIDIA GPU

I'm trying to create a dask-cuda-worker and asked different communities which concluded I should ask the microk8s community regarding enabling the GPU.
I have tried two methods of enabling GPUS, but the helm charts are having issues detecting the GPUs.
First method:
After I join all the nodes, On the master, I perform a microk8s enable gpus.
Alternative Methods:
I performed the instructions of installing the nvidia-k8 plugs through helm.
This requires the Docker with NVIDIA container tool kit.
I install the NVIDIA helm chart as follows:
microk8s helm3 repo add nvdp https://nvidia.github.io/k8s-device-plugin
microk8s helm3 repo update
microk8s helm3 install \
    --version=0.6.0 \
    --generate-name \
    nvdp/nvidia-device-plugin

The helm chart I'm trying to install with GPUs is at the following: RAPIDS AI HELM CHART
Can you install in microk8s environment and see if you can get it to work?

Hi @vinhdiesal,
I've installed MicroK8s 1.18/stable on a GPU host.  microk8s enable gpu gives me the device plugin, as expected:
$ sudo microk8s kubectl get all --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   pod/coredns-588fd544bf-hxs2g               1/1     Running   0          113s
kube-system   pod/nvidia-device-plugin-daemonset-9hbm8   1/1     Running   0          108s

NAMESPACE     NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes   ClusterIP   <IP_ADDRESS>    <none>        443/TCP                  2m6s
kube-system   service/kube-dns     ClusterIP   <IP_ADDRESS>   <none>        53/UDP,53/TCP,9153/TCP   113s

NAMESPACE     NAME                                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
kube-system   daemonset.apps/nvidia-device-plugin-daemonset   1         1         1       1            1           <none>          108s

NAMESPACE     NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/coredns   1/1     1            1           113s

NAMESPACE     NAME                                 DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/coredns-588fd544bf   1         1         1       113s

What issue are you seeing from there?

Hi @joedborg ,
I don't have issues enabling GPU on the nodes, but when I install the helm chart, it doesn't recognize any nvidia nodes so the pods doesn't start.
I've asked the dask team, but they referred me to ask here because they think it's an issue with microk8s.
Here is the Helm chart, RAPIDS AI HELM CHART, can you install it can see if you can get the dask cuda workers to run?

Hi @vinhdiesal,
I've quickly tried using the AI helm chart, with both MicroK8s enable GPU and Nvidia helm chart; neither bring the RAPIDS AI pods up.  If I have time later today,  I'll try on a baremetal K8s cluster, but this seems to be an issue with their chart.
Thanks,
Joe

Hi @joedborg, thanks for looking into this and please let me know what you find out. I really hope the helm chart works with microk8s.

Yep @vinhdiesal, this chart doesn't work on bare metal K8s either, so you'll have to go back to the chart author I'm afraid.
NAMESPACE                         NAME                                                          READY   STATUS         RESTARTS   AGE
ingress-nginx-kubernetes-worker   pod/default-http-backend-kubernetes-worker-7f969db96f-4lc95   1/1     Running        0          4h30m
ingress-nginx-kubernetes-worker   pod/nginx-ingress-controller-kubernetes-worker-k4v88          1/1     Running        0          4h30m
kube-system                       pod/coredns-6b59b8bd9f-zx7wp                                  1/1     Running        0          4h30m
kube-system                       pod/kube-state-metrics-69f474f8cb-4m7qs                       1/1     Running        0          4h30m
kube-system                       pod/metrics-server-v0.3.6-74c87686d-q99qq                     2/2     Running        0          4h30m
kube-system                       pod/nvidia-device-plugin-daemonset-4hwcp                      1/1     Running        0          4h29m
kube-system                       pod/tiller-deploy-fc55974f-67qz6                              1/1     Running        0          3m51s
kubernetes-dashboard              pod/dashboard-metrics-scraper-78d587b6b-sw994                 1/1     Running        0          4h30m
kubernetes-dashboard              pod/kubernetes-dashboard-7b76878768-dh9kt                     1/1     Running        0          4h30m
mynamespace                       pod/rapidsai-jupyter-76fc4b96bb-dg7tm                         0/1     Pending        0          60s
mynamespace                       pod/rapidsai-scheduler-7675655dc6-9qxtq                       0/1     ErrImagePull   0          60s
mynamespace                       pod/rapidsai-worker-77c9d9d8cb-6jmlt                          0/1     Evicted        0          60s
mynamespace                       pod/rapidsai-worker-77c9d9d8cb-fjks2                          0/1     Pending        0          60s
mynamespace                       pod/rapidsai-worker-77c9d9d8cb-lngll                          0/1     Pending        0          60s
mynamespace                       pod/rapidsai-worker-77c9d9d8cb-x4ggc                          0/1     Pending        0          20s

can you run kubectl describe pod on the following?
The RAPIDS AI team are asking for the data.
mynamespace                       pod/rapidsai-scheduler-7675655dc6-9qxtq                       0/1     ErrImagePull   0          60s
mynamespace                       pod/rapidsai-worker-77c9d9d8cb-6jmlt                          0/1     Evicted        0          60s


Improve lighthouse config type

I've imported the types for opts and config straight from the lighthouse library so they will be correct and require little maintenance. I've also changed the thresholds type to be more specific that just a Record.

Hang on, one more change incoming

@mikeybinns could you please resolve the conflict and add a commit?

@abhinaba-ghosh done 🙂


Replace invalid unique_ptr copy initialization from a raw pointer with direct initialization

unique_ptr's raw pointer constructor is explicit, so copy initialization will fail. See: C++ Standard [unique.ptr.single.ctor] https://eel.is/c++draft/unique.ptr.single.ctor#lib:unique_ptr,constructor_
Example of the issue: https://godbolt.org/z/3WrEY18T8
This happens with older versions of the Clang library, where ASTUnit::LoadFromCommandLine returns an ASTUnit* instead of a unique_ptr<ASTUnit>.
https://github.com/NVIDIA/numbast/blob/main/ast_canopy/cpp/src/ast_canopy.cpp#L65-L66
I ran into this with Clang 16. In the latest versions of the Clang library, it does return a unique_ptr, so there's no issue.
https://clang.llvm.org/doxygen/classclang_1_1ASTUnit.html#a10bdfe1735fbb62b6c43decedb22c333
Direct initialization works fine for both versions.

/ok to test