Idea: Quick-Actions

A couple of times I've run into a need to quickly enumerate cloned prefabs. I don't like the (#) pattern that Unity uses. As you can see in the gif this is actually a bit time consuming to set up, thanks to the fact that the first prefab doesn't have any symbols or numbers.

Maybe this not a common use case, but I imagine there may be a few very common tasks people use. If those tasks require multiple steps like this one, it might be helpful to have some quick actions perhaps as a separate menu item. Maybe we can use this issue to track some of the most frequently performed renames?

Been debating about saving configs. Does that solve this? You'd add these
rename ops, configure the values, then say "Save" and give it a name. It
would default the window to the last used setting (per user). These would
be stored per user.
On Wed, Jul 12, 2017 at 5:34 PM Lucas Rowe<EMAIL_ADDRESS>wrote:

A couple of times I've run into a need to quickly enumerate cloned
prefabs. I don't like the (#) pattern that Unity uses. As you can see in
the gif this is actually a bit time consuming to set up, thanks to the fact
that the first prefab doesn't have any symbols or numbers.
[image: fast-enumerate]
https://user-images.githubusercontent.com/398359/28140884-375ae3bc-6728-11e7-9208-0f01598436ff.gif
Maybe this not a common use case, but I imagine there may be a few very
common tasks people use. If those tasks require multiple steps like this
one, it might be helpful to have some quick actions perhaps as a separate
menu item. Maybe we can use this issue to track some of the most frequently
performed renames?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/redbluegames/unity-bulk-rename/issues/89, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAYUKeB0RmrJhHlb3LC5GX04ZO1YkazUks5sNTvigaJpZM4OWPAx
.

--
Edward Rowe
Developer and Co-founder
Red Blue Games

Yeah I think that would solve it. Sounds like a lot of work though. Definitely a flexible solution. Might want a "use as default" checkbox or something for the configuration. Just to be clear, this isn't a pain point for me and I'd want to see this thing used in the wild before doing something like custom configs.

Well if you want a quick solution, for the case you are talking about you can use a regex with a capture group ^^.

But that 0 element might be tricky since it doesn't have a number to capture. Probably doable, though.
Can you explain your Quick Actions suggestion a bit better? I figure I could provide them a few sample Configs which they could delete. But that's not the best. Another option, if Regex works, is to use Regex Presets.

I was thinking it could be under a right-click menu. Not sure what other use cases would go under it...
Would it be possible to put the saved options under this "Quick Rename / Custom Rename" menu?

Right Click
RB Tools

Bulk Rename
Quick Rename / Custom Rename

Enumerate

Certainly possible, but not super user friendly. It'd have to generate code and recompile when you save a preset. That does seem pretty convenient, but in general I kind of hate menu items. The nice thing is here the user is in control.
Another thought is to make the window dockable. And also stop having it close when things rename (I want to do that anyway). With the aforementioned presets you could just keep an instance docked. It'd be pretty easy that way.

Hi, I have been thought about this few days ago.
New version of UBR make me nervous. In most cases I simply add absolute new name with numbers or delete some symbols. Right now I must add everything what I want from menu. It's take a while. I thought about buttons on top of window to add functionalities. These functionalities group in categories.
Other thought - why change so many time look of window. Window could have some builtin layouts. Like in windows calkulator. For example - basic - for fast renaming, advanced etc. It will be simpler then thinking about what is more user friendly or more useful. What do you think?

Hmmm that seems like a pretty nice good-enough solution.
Yet another pretty easy idea is to remember your last config setup in EditorPrefs. So if you want the layout we used to have you could just add them all in at once.
(I think your question @uvivagabond was rhetorical but I'm gonna answer it - the intent behind the new window is to make it more approachable to people who don't know how to use the tool or its more advanced features. It also clears up the Order of Operations issues with the last one a bit better (ie. Does Trim happen before Find and Replace or After? - now you add them manually and can resort them to make it less ambiguous))

So I went with the quick fix here and save the last used ops into EditorPrefs. To finish this out it should be extended to allow for managing configurations which includes:

Save config
Load config
Delete config

I'm not quite sure what the best UI for this is yet. Probably showing another header at the top of the RenameOperations panel that says "Preset: X" and has [Save], [Delete], and maybe [Load] buttons.
If anyone outside @redbluegames/employees wants to tackle this it'd probably save time to submit a mockup here before starting significant work. Or show screenshots of your implementation if that's faster.

I've made all the operations serializable, which allows me to now persist all property changes in addition to rename operation types when reopening the window.
Next I need to add a system for saving, loading, and managing (deleting and editing) presets.


AttributeError: module 'crunchyroll' has no attribute 'Crunchyroll'

Traceback (most recent call last):
  File "./__main__.py", line 16, in <module>
    class Main():
  File "./__main__.py", line 73, in Main
    logger=logger, episode_range=args.range)
  File "/root/project/anime-dl/anime_dl/Anime_dl.py", line 28, in __init__
    sites.crunchyroll.Crunchyroll(
AttributeError: module 'crunchyroll' has no attribute 'Crunchyroll'

Hey, can you please mention what is your operating system? And also, the python version.

I have the same problem

Got it. The imports will be different for python 3. This should still work for Python 2. I think I'll just port it to Python 3.

ImportError: No module named anime_d

Wow, WTH! My Pycharm has been lying to me. I'll check this out and push an update in a while then. Sorry for the mess, folks.

Well, we are waiting, but thanks for the work anyway.
(I don't know English, sorry)


Creating toolbar and portfolio first part

Created navigation bar
Created body of the presentation and social media links.
Using lintern to avoid mistakes.

Hi @edgardsoza,
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.

Invalid Code Review Request

Please make sure all the main headings are present in your Readme file. Currently, there is no Future Features section, also there should be at least one Feature.

Please remove the instructions like below on each section targeting you and fill them with your project info.

Kindly add your license file as a separate file. Check this example, MIT link goes to the MIT file.

Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.

@huseyinbiyik just one observation, future feature request is not marked as needed in the README template, that is why I did not include it. I would have appreciated that you review my code instead of looking for a reason to invalidate the request. I already fixed the README issues and I appreciate you for helping with observations, but all of those recommendations and what to put in the README are not included in the curricula, so it is hard to guess what to put there.


Add performance benchmark

Signed-off-by: Daniel González Lopes<EMAIL_ADDRESS>Added performance benchmark for the scan stage as said on #130. Is the startTimeMeasurement() on the proper place?
On the other side, I had to use an external monotonic [0] package as monotonic it's only avaliable on Python 3.3+ [1].
[0] https://github.com/atdt/monotonic
[1] https://docs.python.org/3/library/time.html

@dgzlopes Is there a reason why this needs to be integrated into the main package?
I'm thinking an adhoc script should suffice, because this is more for package testing, rather than end user consumption.

Makes sense, I'd agree with that.

@domanchi I thought that maybe integrating the base benchmarking functionality, would make easier to add in the future the per detector benchmarks proposed in https://github.com/Yelp/detect-secrets/issues/130#issuecomment-473468049. Also for the users, may be interesting to know the time elapsed if they run detect-secrets on an automated way.
On the other hand, following the ad-hoc way I understand that It would be a small script that starts the timer, runs detect-secrets and then returns the elapsed time. But if we just want this, maybe it is better to follow the Unix principles and rely on the time command [0] (or in windows the Measure-Command) so there is no need for some project-specific script.
[0] https://linux.die.net/man/1/time

We could do that too.
When I think of performance bench-marking, I think of the following questions:

Which file takes the longest to run?
Which plugin is the slowest?
Have these timings changed drastically after my changes?
What does a "good" timing look like?

There's no caching, so speed should remain relatively consistent between consecutive runs. Furthermore, because this tool is somewhat fast, I doubt there will be much information if we do a complete file speed breakdown (because the majority of files are small, and therefore, won't produce any reasonable timings to work with).
With these questions in mind, these are the objectives I envision for minimal performance bench-marking:

[ ] Able to measure how long a single run takes, per plugin
[ ] Able to customize which files to test (so we can easily test for known edge cases)
[ ] Able to integrate in "manual" testing flow for other developers (automated tests won't work due to its heuristic nature)

scripts/ would be a good place for putting this.
With these objectives, we could do the time command (and write shell script to iterate over all plugins, and disable all of them in turn), or we can still use this library in a more adhoc manner (without introducing it into the core code).
Apologies for not being clearer in the original issue. Hopefully this provides more direction for this added testing capabilities. Thanks for helping empower the community to be able to make better changes by having a scientific way to measure the impact on performance!

First, thanks for the time and the nice writeup @domanchi ! Now I know I was missing the point with the first PR. I have updated the PR today adding a new benchmark script (and cleaned the past additions) and would love If you have some time for giving it a spin. I want to note that this is just an update and It's still a WIP (missing some testing, comments and I'm sure that more things!) and It has just some basic functionality included:

Running just python bech.py runs the benchmark inside de detect-secrets project root. Any detect-secrets compatible argument is accepted (from files to flags) too e.g. python bech.py ../../powerfulseal --all-files or python bech.py myfilename.js.
It's able to benchmark with all plugins at the same time. Also, It's able to benchmark one plugin at a time (with the other ones excluded).
Takes the PluginOptions disable_flag_text value from core.usage so we don't have to maintain another list of plugins.
Uses monotonic for the elapsed time.
Works with all the Python versions included in tox.ini! But as I note I don't really like the subprocess32 dependency  (even if it's just on the developer environment) so this might change.
As an example, this is the output for python bench.py:

vagrant@ubuntu-xenial:~/detect-secrets/scripts$ python bench.py
Scanning: ['../.']
------------------------------------------
benchmark                           time
------------------------------------------
all-plugins                  3.779828449s
hex-string-scan              1.293300869s
base64-string-scan           1.832755461s
private-key-scan          0.987097253001s
basic-auth-scan              0.772286352s
keyword-scan                 1.026593331s
aws-key-scan                 0.800705507s
slack-scan                   0.721169404s

Squashed all the commits for a cleaner git log!


Trash and FileSystemProvider

Today, when you delete a file you can asked if you want to move the file to trash. On remote file systems that must not exist and by default we should confirm permanent deletion.

@jrieken Makes sense.
I can look at the uri and only if it is a file scheme to offer to go to trash
An alternative is to look into some central place to see what FileSystemProvider is responsible for my uri and then check if that FileSystemProvider is remote. Is there some place like that?

We could have something on IFileService, contributed providers have the notion of capabilities and we could that in some form.

Yeah a capability makes sense. Assigning this to May to fix once we decide on the capabilites strategy

this issue seems to be good first issue.

shall i work on it ?
any other plans?
@isidorn @jrieken

We were focused on grid this milestone, next week I am on vacation, this is not for endgame -> June

@isidorn i vaguely tried even though you had plans.
please review #50114
i'm happy to close

Pushing this to July
@jrieken I could add a new capability, something like supportsTrash.
When would a FileSystem specify this, also on registration like isReadonly?

Yeah, maybe a capability but we don't really know where the trash can of a provider is...

Yeah the issue is if he supports it...

Now more implementations of FileSystemProvider are appearing please can this issue be addressed soon? As things stand, users are given a false sense of security by being told their deleted file will be recoverable from the Recycle Bin.

@isidorn @jrieken this is coming up in my file service rework. I feel like the "trash" should not be part of a file system provider at all and thus should move out of the file service world. The only real possible trash implementation is for files on disk imho and that is what our UI implies also.
As of today there are only 2 users of the trash:

the "Delete" action in the file explorer
the bulk edit service

"Delete" Action: this action should move into electron-browser and directly use electron API to access the trash if and only if the file has a file:// scheme
Bulk Edit Service: imho this one should not move things to trash. I find it weird that an automated thing that runs fills stuff into the trash without user notice.
Moving to March for consideration.

The only real possible trash implementation is for files on disk imho and that is what our UI implies also.

Not so sure about that. Think of a file system that simply exposes my *nix-user account over sftp. The concept of a trash-can exists there and exposing that makes sense. In the end, trash is just a special folder into which files get moved instead of deleted.

I am fine either way, but I feel like we need to do a change at least that the dialog does not wrongly imply we move to the trash when we cannot.

Yeah, 💯. We should only show the dialog like that when there actually is support for trash

I can move the delete action into electron-browser and use electron API.
However the explorer is depending on that action, and that could have consequences that parts of the explore need to be moved back to electron-browser which does not make sense. So we should also fix how this action is contributed, that we can simply contributed from a .contribution file to the explorer menu.

@isidorn @jrieken I think having the capability is OK, I added it via https://github.com/Microsoft/vscode/commit/8288794f50dfd08e9fa23e950a57a61c0ff0c0e7 (FileSystemProviderCapabilities.Trash = 1 << 12)
This means that we now clearly tell the user that moving to trash does not work if the file system does not support it, which is better than before. Still, the full fix is to surface this in the UI, e.g. by not even showing the normal "Delete" action but "Delete Permanently" if the provider for the resource does not provide that.
I also added IFileService.hasCapability(resource, capability) to ask for a capability given a resource. This currently returns a Promise<boolean> because of the activation of the provider which probably makes it less ideal for the action in the explorer. We can also change the method to a sync variant, though that might return wrong results if the provider is not activated yet...
I left the bulk edit service to use the trash and check for it, though I still think it should bypass the trash always.

Not for endgame. Will do it in debt week -> april

@bpasero yes, let's fix this nicely with context keys. I suggest:

You make the hasCapability sync so I can nicely use it. Returning wrongs results if it is not activated yet is fine for my use case I believe
I will add a context key "explorerResourceCanBeMovedToTrash". This context key will get updated as the explorer focus changes
I will properly contribute the commands based on this context key so we always show the correct one

@bpasero I have changed the hasCapability to be sync. And I have introduced the context key "explorerResourceMoveableToTrash". So we do not show the move to trash command when it is not applicable.
I tried it out and works decent. Check it out and let me know what you think. Thanks

@isidorn you cannot really make a statement about a provider capability without awaiting to resolve it, do you? Now, if someone manages to ask for a capability before the provider has been activated, the code would make a wrong assumption, no?

@bpasero yes. If you ask a provider if it has a capability and it is not activated it would return false.
From a logical perspective this is not so contradictory since it is not activiated he has not capabilities currently for anything.
Otherwise the method should be called activateAndCheckCapability.
If this makes zero sense to you let me know and I can return it to be promise based and try to fix this on the explorer side.

@isidorn let's leave it and see if there is any issue 👍


Specification for Ethereum Oracles

In order to be ready for Q2 2022 development we need to agree upon the scope for the engineering team to deliver in this time period.
We require a spec for Ethereum Oracles
Related to: Notion Board
How do we know when we are done:

[ ] The spec has been updated to indicate what are the requirements for flexible oracles and basic combinators
[ ] The specification contains acceptance criteria with IDs that reflect the scope of the work required for Q2 2022
[ ] The engineering team has reviewed the specifications and understand the scope
[ ] The spec is merged into the specs repo before engineering start development/test work

@vegaprotocol/research
https://drive.google.com/drive/folders/1W2CqlSV96QFOIrJNFe5DUBj3SetkfyvL?usp=share_link
This has the initial finding from the investigation for the Oracles and some (wip) sample code for @C0deMunk33


Questions (not issue)

My apologies for reaching out this way. I did not know any other way to ask my questions. Your product is amazing, and thank you for that! (I'm not very familiar with Github and how to contact contributors)
I just downloaded (cloned) this yesterday. I got it to work but I have just 2 questions:

Based on the documentation in the READ ME regarding "options":

-d  - Change the download location
-h or --headless - Use headless mode, which hides the UI.
-p  - Change the pitch of the downloaded tracks (-1 to go down half step, 1 to go up half step, etc)
--count-in - Include the intro precount on all tracks
--debug - Enable debug logging (in case something goes wrong this helps give more detail)
I thought I could control headless mode, and hide the UI but I could not get it to work. Perhaps I am misunderstanding what it is meant to do.
Also having trouble doing the transpose or pitch change with option eg. "-1", I tried everything and it doesn't recognize it. Actually the trouble with transpose for me is trying to go down 1 or 2, to go up is fine all you do is
kv_downloader download --transpose "1" "https://www.karaoke-version.com/custombackingtrack/maroon-5/sunday-morning.html"
if I try the following for going down in pitch, it fails as it doesn't recognize it.
kv_downloader download --transpose "-1" "https://www.karaoke-version.com/custombackingtrack/maroon-5/sunday-morning.html"
Also, not sure if --headless works. When I include that option I don't see a difference, I still get the headless browser op up and I can see the automation.
If anyone could copy an example of the full command text with the count in, the headless, and the path, and the transpose/pitch (that was tested first) - I would appreciate it

Perhaps this is out of scope but I wanted to bring it to your attention: I used a bash file to automated the download of 3 files ( hoping to use it for 40 songs eventually) and it only downloads 2 songs and never goes beyond 2. I tried about 6 times with different songs.Any idea?

No worries, this is actually the best place to discuss the project. Headless is supposed to allow you to do the entire process without a chromium window popping up and stealing your focus. Though in practice it doesn't always work (and it's notoriously hard to find out why). I just ran a quick test and headless was able to drive the whole experience, but the downloads didn't go anywhere. Still need to dig into why.
I just pushed a fix for passing negative values for --transpose, it was interpreting this as another argument because of the hyphen.
For (2), I'm assuming that the script encountered an error and exited with a non-zero status code, which will (typically) halt scripts. Can you run it with --debug to see more detail?

Thanks for getting back to me.
I will try running with --debug
I was able to use --transpose=-1  thanks to ChatGPT ;-)

Oh by the way, --count-in it will turn it on if it is not already on, but if it is already on and we do not use --count-in, it does not turn it off. It would be nice to have it toggle.

And the download_path is not working.

Thanks, Ben.
In the end I decided to try your previous version (puppeteer) and I found it worked better for my needs. I just tweaked some durations for sleep added some args to stop some popups to give the browser time to do whatever. My goal was to run a bash file that can run for 25 songs in sequence of course. I know about the concern for the TOS for KV but reading through it I concluded it is not an issue. So, puppeteer version seemed to be more robust in running for more than 3 songs. I have about 400 songs to download. Puppeteer can do about 23-25 songs before Chromium sends a popup with choice to Quit or Continue Download. This interrupts the automation, but at least I get 20 songs without attending to it.
Thanks to you I don't have to do it manually.


#69: Created slim version of exaslct for MacOsX

I think, we need to link from the script-languages repo to the MacOS X limitations.


Compile pcap with all features for docs and remove docs-rs feature to…

Closes https://github.com/rust-pcap/pcap/issues/205 and Closes https://github.com/rust-pcap/pcap/pull/206

honestly this lint sux https://rust-lang.github.io/rust-clippy/master/index.html#redundant_pattern_matching

I've marked the changes as approved, but I'm hesitating, because the CI pipeline has not been triggered. Is there a way to check if the workflow file is okay?

Oops, I accidentally now pushed to main

I don't understand why action didn't run. It's maybe because you request change. You can run one manually https://docs.github.com/en/github-ae@latest/actions/managing-workflow-runs/manually-running-a-workflow

I know why - I think it's because of renaming of the default branch

See #215


feat: remove many IsMarkovKernel and IsProbabilityMeasure assumptions

These follow from independence assumptions that are made in the statements.

bors r+


Dynamic fees

Code ACK. Seems it needs BWS 0.0.45 to be published to Travis to pass.

Thanks, updated.


Copy the script on start and run the same copied version in the children processes

At the moment, when the script starts, it may stash (#1) changes or switch the branch for the repository containing script itself. This results in running different version of the script in the children processes compared to the parent process.
To avoid this, both configuration and script itself should be copied and child processes should run the copy to make sure the same version is used.

The issue was closed by #3.


chore(Tactic/Linter): do not import TextBased linter

Mathlib.Tactic.Linter.TextBased is only used by the script lake exe lint-style and therefore does not to be imported by Mathlib.

A future PR might factor this out to live completely outside Mathlib/, but I don't want to do that until the text-based unicode linter PRs (starting with #17129) are approved.

bors merge


Generics g.Map performance

Hi, thank you for the library!
I have been using gomponents to render views of large custom kubernetes resources and noticed that g.Map can be quite inefficient in these scenarios. The issue is that the generics version of g.Map copies every element upon calling the user's callback, which can be quite costly.
I wrote a benchmark to evaluate the performance impact of g.Map against a similar implementation that does not copy elements:
goos: linux
goarch: amd64
pkg: github.com/cezarguimaraes/bla
cpu: 12th Gen Intel(R) Core(TM) i7-12700KF
Benchmark_MapRef_BigStruct10x-20            	   46530	     25108 ns/op	  100135 B/op	    1012 allocs/op
Benchmark_MapRef_BigStruct-20               	   47163	     24908 ns/op	   98586 B/op	    1012 allocs/op
Benchmark_gMap_BigStruct10x-20              	     237	   4806597 ns/op	  435981 B/op	    1012 allocs/op
Benchmark_gMap_BigStruct-20                 	    6391	    210963 ns/op	   99668 B/op	    1012 allocs/op
PASS
ok  	github.com/cezarguimaraes/bla	13.882s

Notice how g.Map performance gets worse when mapping over large elements (8KB and 80KB per element). In particular, a no-copy version of g.Map performed ~200 times better for lists of 80KB elements and ~8 times better for 8KB elements.

Benchmarking code (which also compares performance when preallocating the []g.Node result) available here https://github.com/cezarguimaraes/gomponents_map_bench
Pre allocating the resulting []g.Node also leads to ~25% better performance for ptr Map versions.

It's also worth noting that the previous non-generics version does not have this issue.

Another issue with the copying version of g.Map is that it is not suitable for structs that should not be copied, i.e any struct containing a sync object such as a Mutex, or user-defined values marked noCopy. Attempting to g.Map over these values can lead to subtle bugs, and will cause go vet to fail:
./main.go:59:42: func passes lock by value: github.com/cezarguimaraes/bla.NoCopyElement contains sync.Mutex

To conclude, I don't think the library can choose the best performing version for the user while maintaining type safety. However we could support both by either:

Adding a func MapRef func(ts []T, cb(*T) g.Node) function that doesn't copy the elements
Extending g.Map to support both pointer and value callbacks:

// type appoximations (~) are deliberately ignored
// so Map can be implemented without reflection
type NodeMapper[T any] interface {
	func(T) g.Node | func(*T) g.Node
}

func Map2[Y NodeMapper[T], T any](ts []T, cb Y) []g.Node {
	nodes := make([]g.Node, 0, len(ts))
	switch f := interface{}(cb).(type) {
	case func(T) g.Node:
		for _, t := range ts {
			nodes = append(nodes, f(t))
		}
		return nodes
	case func(*T) g.Node:
		for i := range ts {
			// &ts[i] is also deliberate as calling cb(&t)
			// destroys performance, possibly due to `t` escaping
			// to the heap
			nodes = append(nodes, f(&ts[i]))
		}
		return nodes
	}
	panic("unreachable")
}

In either case, I think there should also be a warning on Map  docs regarding poor performance when copying large objects.

Hi @cezarguimaraes, thank you for the detailed issue! You raise some interesting points. I'm currently on paternity leave and will get back to this after. Stay tuned. 😊

To make things faster, you can also avoid the append call:
func MapPreAlloc[T any](ts []T, cb func(T) g.Node) []g.Node {
	nodes := make([]g.Node, len(ts))
	for i := range ts {
		nodes[i] = cb(ts[i])
	}
	return nodes
}

I don't thing there's nothing wrong with the generic Map. If you want to avoid the copy of your objects, just hold an array of pointers instead and Map should perform just fine on it.

If you want to avoid the copy of your objects, just hold an array of pointers in the first place instead and Map should perform just fine on it

It's valid point but in my case and in some common scenarios one does not control the type when rendering a view over:

imported API types (in my case, custom k8s objects)
generated types such as protobuf messages

As such one would need to maintain an almost identical type to these 3rd party types. If that is maintenance cost one is willing to pay, this workaround still requires creating N pointers on possibly every render, creating extra unnecessary workload for the GC.
At the very least Map godoc should warn users of the implicit copy.

in some common scenarios one does not control the type when rendering a view over

In those cases, going with a new MapRef function seems like a good idea to me to make things more explicit.

Hi @cezarguimaraes . Thank you for your patience. 😊
Could you give an example where using a large struct type you don't control cannot be passed to Map as a slice of pointers to instances of that type?
For me, it's clear from the method signature that structs will be copied if you don't pass a pointer type, since that's how all functions in Go work. In your opinion, how does this function differ? (I'm not opposed to the idea of documenting this, I'm just trying to understand your thought process.)

Hi @markuswustenberg ,

Could you give an example where using a large struct type you don't control cannot be passed to Map as a slice of pointers to instances of that type?

One can always map over the original slice to a slice of pointers, it's just worse DX in my opinion to have to do so everytime I have to call map with large structs (or noCopy elements in the structs). It is also less efficient as we might be creating thousands of new objects for go's GC to take care of every render.
The example I mentioned are types like this: https://github.com/tektoncd/pipeline/blob/fd4cb4621960715439bf0c0757f5be9cad390568/pkg/apis/pipeline/v1/pipelinerun_types.go#L606. List types that are autogenerated for kubernetes resources and returned by kubeapi calls.

For me, it's clear from the method signature that structs will be copied if you don't pass a pointer type, since that's how all functions in Go work. In your opinion, how does this function differ?

I admit it should be apparent for anyone familiar with Go that a copy happens in Map. I just think it shouldn't and it couldn't in the non-generic Map implementation: https://github.com/maragudk/gomponents/blob/d81de8319f83a4f62ae33f9ada8da267aa9197fd/gomponents_non_generic.go#L7-L13

@cezarguimaraes ,
I agree that it's worse DX, but I think that's okay since I don't think passing large/uncopyable structs into the view layer is a very common use case. I would rather keep things simple in the library. In your case, you could create helper functions to create your pointers to the large structs and use those everywhere in your view package. You might want to do that anyway, since you're already copying your large structs around between packages, no? Or are you creating them in the view layer?
And yes, the non-generic version worked differently, because the more intuitive generic version wasn't possible then. But as stated above, it's perfectly possible for you to just use pointers in the generic Map implementation, and I think that's definitely the least surprising and most intuitive behaviour.
In conclusion, I'm leaning towards not making any changes here.


Show_pw

This branch includes changes made to allow (un)masking the password input elements by clicking a "Show password" checkbox.  Note that there are two additional commits in this branch that were part of changes submitted for fixing bug #1923 (.gitignore and results.html).  Not sure why these are showing up since I have not made any additional changes to these files.  Perhaps it's because I don't have a full grasp of using git yet.  If they should get pulled in nothing will break.
The remaining commits in this branch all address (un)masking password using a "Show password" checkbox.

This pull request has been superseded by PR Show_PW #2145.


Edits to Remote Development Docs

Made docs more coherent by adding explanatory details and reordering sections.

Automated message from Dropbox CLA bot
@tonynater, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here.

Automated message from Dropbox CLA bot
@tonynater, thanks for signing the CLA!

Awesome, thanks for working on this @tonynater!  I merged this, after tweaking the commit messages to match the standard Git style we use.  Check out the Zulip commit message guidelines for more details: https://zulip.readthedocs.io/en/latest/version-control.html#commit-messages
Thanks for coming to the hackathon yesterday!


Tile map fixes/enhancements

Cleaned up selections (clicking and selecting tiles) to take care of special characters in names
Added a bool option to freeze/unfreeze tooltips. This way user can decide when to freeze the tooltips or when to make them follow the mouse

@kaiayoung


Update Automatic's state.job_count with the total number of images to get a proper progress bar

The script isn't updating the job count with the total number of images it generates, so Auto1 only shows progress for the first image generated. To fix this you just have to edit two lines in infinity_grid.py,

Import the state object from modules.shared: from modules.shared import opts, state
In a1111_grid_runner_pre_run_hook, set the job count: state.job_count = grid_runner.total_run

Edit: I found that the total step count didn't include hires steps, and also that Automatic was overriding the value we give it, so I made a PR. The total progress bar should be correct now.

#93 pulled


Feature/navbar

Pull Request Template
Summary
This PR introduces a set of UI enhancements, focusing on navigation components and typography updates for better user experience.
Changes Location

[ ] Server
[x] Client

Change Type

[ ] Bug fix 🐞
[x] New feature ✨
[x] New Component 🆕
[ ] Documentation update 📚
[ ] Other (please specify):

Changes Made

🖋 Imported a font-family style: Added a new font to improve the overall look and feel.
🚀 Created a Navbar component: Designed a reusable navigation bar for consistent page structure.
📦 Exported the Navbar component: Made the navbar available for use across the application.
🔗 Created and exported a Link component: Built a link component for easy navigation handling and exported it for use.
📌 Integrated Navbar into TestArea: Added the navbar to the TestArea for navigation testing and user interaction.

Checklist

[x] Code follows style guidelines (2 spaces indentation) ✔
[x] Self-reviewed my code 🔍
[ ] Updated documentation (if needed) 📄
[ ] No new warnings introduced ⚠
[ ] Added tests (if applicable) ✅
[x] All tests passed 🏁

@Ahm3dHa Good Job Ahmed 👍
everything is working as indented, now we can proceed to the next feature 🥳


Sencha and Bryntum missing

Sencha and Bryntum have grids to:
https://www.sencha.com/grid/
https://www.bryntum.com/products/grid/

Thanks! I'll take a look at these.


setup ibc script not working

Describe the bug
its failing to create rollapp keys for the relayer with error "Error: failed to add key: prefix cannot be empty"
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

the problem comes from the prefix env variable changed from BECH32_PREFIX to BECH32 in the readme and in the script, and if not setting it correct before running the script, because following the readme of main, while using older versions of the scripts, it will fail. but the script is already updated.


Kernel for EigenOp

We need a kernel for DaphneIR's EigenOp, which calculates both the eigen values and the eigen vectors of the given matrix.

Currently, we need it for the DaphneDSL script scripts/algorithms/pca.daph (line 72).

Ι took a thorough look on the issue and I have some comments.
Let me firstly comment, that I am not an expert on the field, I conducted however some research.
In my understanding based on the deliverables we would like to work mostly with blas/lapack as a third party library for the linear algebra operations.
Though I think a cpp library called eigen  (https://eigen.tuxfamily.org/index.php?title=Main_Page) would be a better fit for extracting the eigen values and eigen vectors of a given matrix.
Firstly, I think because lapack is written in Fortran its API is very FORTRAN-like and thus more demanding in terms of coding.
Many users adress this issue and that the learning curve is large. (although there is the lapack++ implementation which users suggest to be somehow more cpp user-friendly).
Eigen has also some crucial advantages over lapack such as:

Eigen handles fixed-size matrices and vectors, which are very widely used.
Eigen has built-in support for sparse matrices and vectors.
Eigen provides a lot of convenience features (see Geometry module, Array module, etc), which are also very widely used.

Finally in terms of performance, eigen is proven to outperform blas/lapack.
It takes advantage of cpp advanced features to optimize one's code and make most things compile-time and SIMD/vectorized.
I repeat I am not an expert on the field, nor I have ever coded using eigen or blas or blas/lapack.
But I think this would be the best way to go.
I would like some comments before procceding in coding, that's why I am sharing my thoughs here.
PS: After our Wp4-Wp5 meeting, today at 29-06-2022 I checked about eigen's license.
It's MPL 2.0 (Mozilla Public License).

Imho using Eigen is fine. Currently we use OpenBLAS as our CPU BLAS/LAPACK implementation. From the quick read on Eigen's documentation, their library can make use of OpenBLAS (and other implementations like Intel's MKL). So I guess it's fine to add Eigen as a dependency if they provide a solid implementation. Our dependency compile time is already quite long anyway :D Just make sure that the compile time dependency is reasonably contained.
I'm no expert on the license issue tbh. I hope MPL is ok.

Hello,
working with the Eigen library in order to construct the kernel, during testing I encountered some tricky corner cases.
The main issue is that eigen values, can be complex numbers.
The problem is that Daphne does not support complex value types.
Although this issue can easily be bypassed, if we use the eigen kernel strictly for the PCA algorithm, as the PCA uses the covariance matrix, which is a real symmetric matrix, so its eigenvalues should be real.
Some suggest that sometimes the numerical eigen algorithms, might return small imaginary components due to roundoff error. And that these imaginary components, can be ignored.
If that's the case I can make sure that the eigen kernel will return only the real part of the eigen values.
Shall i proceed like that?

Good catch @KostasBitsakos! At the moment, DAPHNE does not support complex numbers as a value type, but we plan to add that later via the means for extensibility we are currently working on.
For now, I suggest circumventing this problem. I've also just read that up again: the eigenvalues and eigenvectors of a real and symmetric matrix are always real (not complex). So let's assume that the input matrix of eigen() is symmetric (we should update this in the documentation of the DaphneDSL built-in functions). So yes, please proceed by ignoring the imaginary components returned by the eigen library.
Side-note: DaphneDSL's built-in functions are strongly inspired by those of SystemDS's DML. Futhermore, we plan to automatically translate many of the higher-level ML algorithms of SystemDS to DaphneDSL automatically (#197), to get a large library of such algorithms without having to reimplement them. SystemDS's built-in function eigen() also assumes a symmetric input matrix. So even by making this assumption, we will still be able to execute all algorithms translated from SystemDS, which is quite a lot. If need be, we will support non-symmetric inputs to eigen() once we support complex numbers.


TypeError: Object.getPrototypeOf called on non-object

I am getting this error when trying to use this module. The error line is:
#41 -  " var scopePrototype = Object.getPrototypeOf($rootScope);"
The "getRootScope()" method seems to be returning a non-object.
This line: " var scopeEl = document.querySelector('.ng-scope');"  seems to be failing. My "ng-app" is on the body tag. I tried putting it on the HTML tag with same results.

I'm going to close this. Let me know if you still have issues with it.

Getting this error when I am using with ionic. I create a directive that calls the function
        showAngularStats(
          position: "topleft"
          digestTimeThreshold: 16
          autoload: true
          logDigest: true
          logWatches: true
        )

And put it under index.html
All of the above test returns null. And i'm pretty sure angular loads.

I'm using angular 1.3.x
Could it be the problem with newer angular?

No, it works fine with my apps on 1.3.x. The code you have there is
invalid... Are you sure you're passing an object to the function? Don't
forget the curly braces...

Kent C. Dodds

(Sent from my mobile device, please forgive typos or brevity)
I'm using angular 1.3.x
Could it be the problem with newer angular?
—
Reply to this email directly or view it on GitHub
https://github.com/kentcdodds/ng-stats/issues/3#issuecomment-73400404.

Oh, forgot to clarify that the code is in Coffeescript so no need for comma and curly braces :)

I'm not sure what to tell you without additional information. You may need to step into the script to see what's going on to give me more info. It works fine on any site I use it on.

Oh, one thing that you'll need to make sure of is that debug info is enabled: https://docs.angularjs.org/guide/production reenable it with: angular.reloadWithDebugInfo();

@pencilcheck The issue is related to ionic implementation, they remove the ng-scope and ng-isolate-scope. In this line: https://github.com/driftyco/ionic/blob/v1.0.0-rc.0/release/js/ionic-angular.js#L279

Ah, very interesting! Ping @adamdbradley, @ajoslin, @mhartington, and @mlynch (sorry, don't know which of you is best for this question). I'm very curious to know why this was necessary :-) Seems to me it would just be better to let the user specify $compileProvider.debugInfoEnabled(false); when they want to get that perf win.

I've sent a pull request which adds basic Ionic support here:
https://github.com/kentcdodds/ng-stats/pull/44


feat: print rule dependency tree in debug log level

This change is

Here is an example of the log output using the default configuration:
2022-06-10 11:59:36,080 DEBUG 3893   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : ------------------------------------------------------------
2022-06-10 11:59:36,080 DEBUG 3893   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : Rule Dependency-Tree
2022-06-10 11:59:36,080 DEBUG 3893   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : ------------------------------------------------------------
2022-06-10 11:59:36,081 DEBUG 3894   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_apacheclient_http_metric
2022-06-10 11:59:36,082 DEBUG 3895   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_apacheclient_extract_details
2022-06-10 11:59:36,082 DEBUG 3895   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,082 DEBUG 3895   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    |    +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,083 DEBUG 3896   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_apacheclient_detect_entry
2022-06-10 11:59:36,083 DEBUG 3896   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_client_record_metric_on_method
2022-06-10 11:59:36,083 DEBUG 3896   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_http_client_record_metric
2022-06-10 11:59:36,083 DEBUG 3896   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_http_capture_method_duration
2022-06-10 11:59:36,084 DEBUG 3897   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |              +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,084 DEBUG 3897   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |                   +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,084 DEBUG 3897   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_apacheclient_propagation
2022-06-10 11:59:36,085 DEBUG 3898   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_apacheclient_detect_entry
2022-06-10 11:59:36,085 DEBUG 3898   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_apacheclient_servicegraph_propagation
2022-06-10 11:59:36,085 DEBUG 3898   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_prepare_down_propagation
2022-06-10 11:59:36,085 DEBUG 3898   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_apacheclient_servicegraph_record
2022-06-10 11:59:36,086 DEBUG 3899   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_apacheclient_extract_details
2022-06-10 11:59:36,086 DEBUG 3899   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,086 DEBUG 3899   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    |    +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,086 DEBUG 3899   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_apacheclient_detect_entry
2022-06-10 11:59:36,086 DEBUG 3899   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_outbound_record_method
2022-06-10 11:59:36,087 DEBUG 3900   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_servicegraph_outbound_record_metric
2022-06-10 11:59:36,087 DEBUG 3900   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_servicegraph_capture_method_duration
2022-06-10 11:59:36,087 DEBUG 3900   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,087 DEBUG 3900   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |              +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,088 DEBUG 3901   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_apacheclient_detect_entry
2022-06-10 11:59:36,088 DEBUG 3901   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_apacheclient_tracing
2022-06-10 11:59:36,088 DEBUG 3901   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_apacheclient_extract_details
2022-06-10 11:59:36,089 DEBUG 3902   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,089 DEBUG 3902   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    |    +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,089 DEBUG 3902   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_apacheclient_detect_entry
2022-06-10 11:59:36,089 DEBUG 3902   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_tracing_span_name_default
2022-06-10 11:59:36,090 DEBUG 3903   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_client_tracing_default_attributes
2022-06-10 11:59:36,090 DEBUG 3903   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_http_tracing_default_attributes
2022-06-10 11:59:36,090 DEBUG 3903   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |              +--- r_tracing_global_attributes
2022-06-10 11:59:36,090 DEBUG 3903   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |                   +--- r_tracing_exception_attributes
2022-06-10 11:59:36,090 DEBUG 3903   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |                   +--- r_tracing_fqn_attribute
2022-06-10 11:59:36,091 DEBUG 3904   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_down_propagation
2022-06-10 11:59:36,091 DEBUG 3904   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,091 DEBUG 3904   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_http_metric
2022-06-10 11:59:36,091 DEBUG 3904   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_client_record_metric
2022-06-10 11:59:36,092 DEBUG 3905   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,092 DEBUG 3905   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,092 DEBUG 3905   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_extract_details
2022-06-10 11:59:36,092 DEBUG 3905   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_httpurlconnection_extract_request_details
2022-06-10 11:59:36,092 DEBUG 3905   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,093 DEBUG 3906   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,093 DEBUG 3906   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    |         +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,093 DEBUG 3906   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_httpurlconnection_extract_response_details
2022-06-10 11:59:36,093 DEBUG 3906   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,094 DEBUG 3907   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_detect_end
2022-06-10 11:59:36,094 DEBUG 3907   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,094 DEBUG 3907   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_servicegraph_propagation
2022-06-10 11:59:36,094 DEBUG 3907   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_prepare_down_propagation
2022-06-10 11:59:36,094 DEBUG 3907   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_servicegraph_record
2022-06-10 11:59:36,095 DEBUG 3908   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_outbound_record_method
2022-06-10 11:59:36,095 DEBUG 3908   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_servicegraph_outbound_record_metric
2022-06-10 11:59:36,095 DEBUG 3908   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_servicegraph_capture_method_duration
2022-06-10 11:59:36,095 DEBUG 3908   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,095 DEBUG 3908   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |              +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,095 DEBUG 3908   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_extract_request_details
2022-06-10 11:59:36,096 DEBUG 3909   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,096 DEBUG 3909   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,096 DEBUG 3909   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,096 DEBUG 3909   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_detect_end
2022-06-10 11:59:36,096 DEBUG 3909   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,097 DEBUG 3910   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_tracing_end
2022-06-10 11:59:36,097 DEBUG 3910   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_tracing_span_name_default
2022-06-10 11:59:36,097 DEBUG 3910   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_extract_request_details
2022-06-10 11:59:36,097 DEBUG 3910   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,097 DEBUG 3910   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_detect_end
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_client_tracing_default_attributes
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_tracing_default_attributes
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_tracing_global_attributes
2022-06-10 11:59:36,098 DEBUG 3911   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |              +--- r_tracing_exception_attributes
2022-06-10 11:59:36,099 DEBUG 3912   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |              +--- r_tracing_fqn_attribute
2022-06-10 11:59:36,099 DEBUG 3912   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_extract_response_details
2022-06-10 11:59:36,099 DEBUG 3912   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,099 DEBUG 3912   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_tracing_start
2022-06-10 11:59:36,100 DEBUG 3913   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_tracing_span_name_default
2022-06-10 11:59:36,100 DEBUG 3913   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_extract_request_details
2022-06-10 11:59:36,100 DEBUG 3913   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,101 DEBUG 3914   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_parametrize_path
2022-06-10 11:59:36,101 DEBUG 3914   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,101 DEBUG 3914   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_detect_start
2022-06-10 11:59:36,101 DEBUG 3914   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,101 DEBUG 3914   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_httpurlconnection_up_propagation
2022-06-10 11:59:36,101 DEBUG 3914   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_httpurlconnection_detect_entry
2022-06-10 11:59:36,102 DEBUG 3915   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_prepared_sql_stop_propagation
2022-06-10 11:59:36,102 DEBUG 3915   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,102 DEBUG 3915   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_query_metric_preparedstatement
2022-06-10 11:59:36,102 DEBUG 3915   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_query_metric_defaults
2022-06-10 11:59:36,103 DEBUG 3916   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,103 DEBUG 3916   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,103 DEBUG 3916   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_extract_url
2022-06-10 11:59:36,104 DEBUG 3917   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,104 DEBUG 3917   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_detect_entry
2022-06-10 11:59:36,104 DEBUG 3917   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_query_metric_statement_execute
2022-06-10 11:59:36,104 DEBUG 3917   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_query_metric_defaults
2022-06-10 11:59:36,105 DEBUG 3918   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,105 DEBUG 3918   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,105 DEBUG 3918   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_extract_url
2022-06-10 11:59:36,105 DEBUG 3918   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,105 DEBUG 3918   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_detect_entry
2022-06-10 11:59:36,106 DEBUG 3919   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_query_metric_statement_executeBatch
2022-06-10 11:59:36,106 DEBUG 3919   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_query_metric_defaults
2022-06-10 11:59:36,106 DEBUG 3919   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,106 DEBUG 3919   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,106 DEBUG 3919   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_extract_url
2022-06-10 11:59:36,107 DEBUG 3920   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,107 DEBUG 3920   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_detect_entry
2022-06-10 11:59:36,107 DEBUG 3920   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_servicegraph_record
2022-06-10 11:59:36,107 DEBUG 3920   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_outbound_record_method
2022-06-10 11:59:36,108 DEBUG 3921   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_servicegraph_outbound_record_metric
2022-06-10 11:59:36,108 DEBUG 3921   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_servicegraph_capture_method_duration
2022-06-10 11:59:36,108 DEBUG 3921   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,108 DEBUG 3921   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |              +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,109 DEBUG 3922   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_extract_url
2022-06-10 11:59:36,109 DEBUG 3922   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,109 DEBUG 3922   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,109 DEBUG 3922   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_tracing_preparedstatement
2022-06-10 11:59:36,110 DEBUG 3923   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_tracing_defaults
2022-06-10 11:59:36,110 DEBUG 3923   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_tracing_global_attributes
2022-06-10 11:59:36,110 DEBUG 3923   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_tracing_exception_attributes
2022-06-10 11:59:36,110 DEBUG 3923   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_tracing_fqn_attribute
2022-06-10 11:59:36,110 DEBUG 3923   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_extract_url
2022-06-10 11:59:36,111 DEBUG 3924   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,111 DEBUG 3924   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_detect_entry
2022-06-10 11:59:36,111 DEBUG 3924   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_tracing_statement_execute
2022-06-10 11:59:36,111 DEBUG 3924   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_tracing_defaults
2022-06-10 11:59:36,111 DEBUG 3924   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_tracing_global_attributes
2022-06-10 11:59:36,111 DEBUG 3924   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_tracing_exception_attributes
2022-06-10 11:59:36,112 DEBUG 3925   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_tracing_fqn_attribute
2022-06-10 11:59:36,112 DEBUG 3925   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_extract_url
2022-06-10 11:59:36,112 DEBUG 3925   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,112 DEBUG 3925   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_detect_entry
2022-06-10 11:59:36,112 DEBUG 3925   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_jdbc_tracing_statement_executeBatch
2022-06-10 11:59:36,113 DEBUG 3926   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_jdbc_tracing_defaults
2022-06-10 11:59:36,113 DEBUG 3926   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_tracing_global_attributes
2022-06-10 11:59:36,113 DEBUG 3926   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_tracing_exception_attributes
2022-06-10 11:59:36,113 DEBUG 3926   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_tracing_fqn_attribute
2022-06-10 11:59:36,113 DEBUG 3926   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_extract_url
2022-06-10 11:59:36,114 DEBUG 3927   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         |    +--- r_jdbc_detect_entry
2022-06-10 11:59:36,114 DEBUG 3927   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_jdbc_detect_entry
2022-06-10 11:59:36,114 DEBUG 3927   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_downPropagation
2022-06-10 11:59:36,114 DEBUG 3927   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servletapi_detect_entry
2022-06-10 11:59:36,115 DEBUG 3928   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_http_metric
2022-06-10 11:59:36,115 DEBUG 3928   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_http_server_record_metric_on_method
2022-06-10 11:59:36,115 DEBUG 3928   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_server_record_metric
2022-06-10 11:59:36,115 DEBUG 3928   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |    +--- r_http_capture_method_duration
2022-06-10 11:59:36,115 DEBUG 3928   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,115 DEBUG 3928   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    |              +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,116 DEBUG 3929   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servletapi_extract_details
2022-06-10 11:59:36,116 DEBUG 3929   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_servletapi_detect_entry
2022-06-10 11:59:36,116 DEBUG 3929   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_http_parametrize_path
2022-06-10 11:59:36,116 DEBUG 3929   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |              +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,116 DEBUG 3929   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_servicegraph_propagation
2022-06-10 11:59:36,116 DEBUG 3929   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_prepare_up_propagation
2022-06-10 11:59:36,117 DEBUG 3930   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_servicegraph_record
2022-06-10 11:59:36,117 DEBUG 3930   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |    +--- r_servicegraph_inbound_record_method
2022-06-10 11:59:36,117 DEBUG 3930   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_servicegraph_inbound_record_metric
2022-06-10 11:59:36,117 DEBUG 3930   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |         +--- r_servicegraph_capture_method_duration
2022-06-10 11:59:36,118 DEBUG 3931   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |              +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,118 DEBUG 3931   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : |                   +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,118 DEBUG 3931   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_servlet_filter_upPropagation
2022-06-10 11:59:36,118 DEBUG 3931   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_servletresponse_upPropagation
2022-06-10 11:59:36,118 DEBUG 3931   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- r_servletapi_tracing
2022-06-10 11:59:36,118 DEBUG 3931   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_http_tracing_span_name_default
2022-06-10 11:59:36,119 DEBUG 3932   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_http_server_tracing_default_attributes
2022-06-10 11:59:36,119 DEBUG 3932   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |    +--- r_http_tracing_default_attributes
2022-06-10 11:59:36,119 DEBUG 3932   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |         +--- r_tracing_global_attributes
2022-06-10 11:59:36,119 DEBUG 3932   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |              +--- r_tracing_exception_attributes
2022-06-10 11:59:36,119 DEBUG 3932   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |              +--- r_tracing_fqn_attribute
2022-06-10 11:59:36,119 DEBUG 3932   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_custom_rule
2022-06-10 11:59:36,120 DEBUG 3933   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_servletapi_extract_details
2022-06-10 11:59:36,120 DEBUG 3933   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :           +--- r_servletapi_detect_entry
2022-06-10 11:59:36,120 DEBUG 3933   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :           +--- r_http_parametrize_path
2022-06-10 11:59:36,120 DEBUG 3933   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :                +--- r_http_parametrize_path_remove_ids
2022-06-10 11:59:36,121 DEBUG 3934   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver : +--- <unused rules>
2022-06-10 11:59:36,122 DEBUG 3935   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_capture_method_duration
2022-06-10 11:59:36,122 DEBUG 3935   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |    +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,122 DEBUG 3935   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |         +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,122 DEBUG 3935   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_method_metric
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |    +--- r_capture_method_duration
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |         +--- r_capture_method_duration_conditional
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      |              +--- r_capture_method_entry_timestamp_conditional
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :      +--- r_trace_method
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :           +--- r_tracing_global_attributes
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :                +--- r_tracing_exception_attributes
2022-06-10 11:59:36,123 DEBUG 3936   --- [inspectIT] [       Thread-0] i.c.InstrumentationConfigurationResolver :                +--- r_tracing_fqn_attribute


"No ALSA Devices Found" with pimixer on 1.3.0b1

When I try launching "Audio Device Settings" (aka pimixer) on 1.3.0b1 I get a pop up dialog stating "No ALSA Devices Found". However, Jamulus works fine with my audio interface, the Audient iD4.
Not sure what to do to help debug this but happy to help provide further diagnostics if needed.

Thanks for reporting.  I'm not familiar with Audient iD4.  Glad it works with Jamulus, that might be all you need.
Others have reported problems with that interface under linux.
These threads makes reference to firmware versions, and USB hub possibly causing issues:
https://linuxmusicians.com/viewtopic.php?t=20310
https://www.spinics.net/linux/fedora/alsa-user/msg14755.html
FYI there is a kernel installed on Jambox 1.3.0b1 which is not used by default, which has a patch set applied that deals with certain USB issues.  However I was not able to really test it, and I doubt it will help your issue.  If you feel like trying it, in the kernels section at the bottom of /boot/config.txt, change the [none] filter (5.16 kernel name has usb in it)  to [pi4] and vice versa, then reboot.  If it doesn't help, change it back.

I'm guessing maybe alsa doesn't have profiles for audient devices...  heres a link to someone who's adding an alsamixer profile for an audient EVO.....  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/397/diffs
The changes are in rules and conf files, not compiled code, so if might be possible to add something for id4, if that's what it needs...

So I had the same results with my Yamaha MG10XU, but it still works fine with Jamulus. Some light digging shows that pimixer uses gstreamer to find mixers attached to the system and shows this error message when it does not find any. Perhaps adding an alsa profile here will help as you suggest. However, I don't think either of these devices have any controls for the mixer to show anyhow as I don't have any mixer-type controls when using these devices on macOS.
Going to close this since it is clearly out of the hands of jambox. Perhaps you could wrap pimixer in a script that detects this situation and shows a better error message!

@skrul If you need to change a specific internal setting, you might be able to view & change it with the "amixer" command.  It would take some trial and error, but if you can find the magic amixer command for the setting you want, you can put that command into /etc/jackdrc.conf and it will get executed when jack restarts.
See this discussion:
https://github.com/kdoren/jambox-pi-gen/discussions/25

@skrul the raspberry pi alsa libs and utils are pretty old.
I built newer versions and put them in my repo.
I don't know if this will help pimixer.
It looks painful to get pimixer to build with an updated grstreamer (1.15 vs 0.10.36),
You can install the updates alsa packages with:
sudo apt update && sudo apt install libasound2

This will update a number of alsa-related things, including alsamixer.
Please try it and see if that makes any difference.
Reopening for the time being so others can see this and try if they want.

@skrul I have the same issue and I'm using a Focusrite Scarlett 2i2 2nd gen

Many USB devices have internal level controls and switches that are unique to that device.  Usually you can get to them with the "amixer" command line utility, but it's very painful to use amixer to figure out what level or switch to set, then figure out what exact command to use to set it, then put the command in the jamulus_start.conf file to run at startup.
Pimixer is the friendliest tool for this, so you should try it first.  All devices are different,  Your device might have switches (check boxes) for "boost" or "agc" that could give you a lot more input gain.
The internal settings of USB audio devices can be confusing.  For example, there might be more than on "mic slider", and one of them might be in the playback section and control the mic monitor level, not affecting the level sent to Jamulus.  for that there might be a separate mic level in the capture section.  Usually I expect to see a capture mic level, but I suppose it's possible that yours only has AGC.
Pimixer itself doesn't know about your device's controls, it gets that information from gstreamer0.10 which gets it from ALSA.  Pimixer is a deprecated tool because it uses the mixer functions of gstreamer0.10 which have been removed from later gstreamer versions.  So it's possible that there exists an internal control for what you want, but it's missing somewhere in the chain, and pimixer simply can't you do what you want.  In that case, amixer might help if you are willing to go through the pain
(see below).
Also be aware the the jambox "CAPTURE_LEVEL" setting (default 80%, used only at jamulus startup time) might override something you set with pimixer or amixer.  If you can get your headset working the way you like with pimixer or amixer, you can disable CAPTURE_LEVEL setting by commenting it out in jamulus_start.conf.
Below is some amixer info from another discussion topic.  in this example "-c 1" is for "card 1", you'll probably need to use "-c 0".
Even the cheapest USB Audio Interfaces can have internal controls and switches that might be useful (sometimes a bewildering array of them) They're not necessarily exposed through any GUI, but you might be able to get to them via the "amixer" command.
For example, it might be possible to disable AGC. Here's a cheap one (Sabrent I think, card 1 in this case) that has AGC:
# look for a control with "Auto" in the name
pi@jambox:~ $ amixer -c 1 | grep Auto
Simple mixer control 'Auto Gain Control',0

# get the value of mixer control "Auto Gain Control
pi@jambox:~ $ amixer -c 1 cget iface=MIXER,name='Auto Gain Control'
numid=9,iface=MIXER,name='Auto Gain Control'
  ; type=BOOLEAN,access=rw------,values=1
  : values=on

# set "Auto Gain Control" off
pi@jambox:~ $ amixer -c 1 cset iface=MIXER,name='Auto Gain Control' 0
numid=9,iface=MIXER,name='Auto Gain Control'
  ; type=BOOLEAN,access=rw------,values=1
  : values=off

If you find the magic command that disables AGC, you could put it in /etc/jackdrc.conf (that file is sourced so any commands in it are executed). Then it will get executed whenever Jamulus starts or jack is restarted.

Thanks. Together with the amixer manpage your post helped me a lot to understand amixer and pimixer settings. Perfect match to my requirements.

Jambox 1.4.0-b.1 and later have "QasMixer" installed on the desktop by default.  In most cases this will be preferable to pimixer ("Audio Device Settings"), which I have also left on the desktop because some people are already familiar with it.


Treating package version not found warnings as errors.

Addresses https://github.com/NuGet/Engineering/issues/5665 in this repo.

@agr
There're build errors.

Need to do something about Test.Utility dependency. Will get back to it at later time.


[RFE] Extend Nebraska's responses to include non-package data

Current situation
Omaha v3 defines a number of elements in requests and responses but it's tailored towards having responses as a "URL" in which the client will find the returned packages and actions.
Impact
If we want to respond with data in the context of e.g. a container image new version, the above format is not adequate.
Fortunately, the protocol does mention that server and clients should be resilient to unknown elements in the requests/responses. This means that we can extend the protocol for more custom use-cases.
Ideal future situation
As a proof of concept, connected with #419 , we should explore supporting responses that respresent a payload identified by a type.
Examples of types are: application/container-image, git/ref, gzip...
It is up to the client, as usual, to then install/deploy/use the payload, and it's true that payload types shouldn't differ for a same channel or even application, but having this extra information about the type may be helpful for abstracting logic like the proposal in #419 .
**Implementation options
Let's add a custom element called _payload as part of the <updatecheck> response. This payload element should have a type subelement as a string, and more elements depending on what's needed for this type.
As a concrete example, let's aim for supporting container image updates managed by Nebraska. In this case we can have:
<_payload>
  <type>application/container-image</type>
  <image>gchr.io/kinvolk/headlamp</image>
  <tag>latest</tag>
  <policy>always-pull</policy>
</_payload>

(The policy above it's just an example of other members we may add)
As for how to implement this in Nebraska's database, possibly the quickest (but also dirtiest) way is to have a new package type in Nebraska (data-payload) and add a new field called data or so, where we'll just encode the _payload element and contents. This way we can also reuse it for other response types later (small binary data for example... :man_shrugging: ).

<digest> is the focus. I would almost not use <tag> at all.
Instead of <image> as a name, I would call this field something like <registryRef>

the <type> definition could reference examples like https://github.com/opencontainers/image-spec/blob/main/manifest.md.

Done in the proof-of-concept branch.


Fix duplication of headers when nesting property drawers.

This will be fixed in 1.1.1 for 2021+ versions.


Add binding redirect for RuntimeInformation facade

Add binding redirect for RuntimeInformation facade
Not specifying this binding redirect was causing ngen issues with a
future version of .NET was installed.
Internal tracking bug: 467584

@dotnet-bot test this please

@dotnet-bot test CI please

@dotnet-bot help

@jeffkl I wasn't planing on squashing so it will be a different commit.

@dotnet-bot test CI please

@mmitche CI is not working for this branch. Does it take some time to pick the branch up, or do we need to do something extra to register the branch?

@cdmihai Need to add an entry in the repo list.  Added for you. https://github.com/dotnet/dotnet-ci/commit/be4d1dfb4106656b52aa0808b44535a5795e61d8


Maximize is too large - to entire height of Grid Component

Hi @drcmda - Thanks so much for all your work on this.  It looks really awesome. I'm trying to get this running on a website so that I can use it as a gallery.  I've dropped your simple demo from https://codesandbox.io/embed/z6ly40071p into my project and haven't altered anything yet.
The issue I'm having is that when the cell is maximized, it opens to 100% width and height of the entire Grid component.  This ends up placing the contents of the maximized cell far off the screen.
In each of your demos, it appears that the cell is only opening to 100vh - which is what I would like.
To sum it up:
My Issue: maximize is opening far taller than what is visible on the screen
My Goal: Maximize opens cell/content to 100vh and 100vw
Any Ideas?
Thank you in advance for any guidance you might have.
Thank you for your time.

Could you make a sandbox to demonstrate this behaviour? PRs also welcome, the grid is just a small-ish class easy to manipulate.

I was able to recreate here: https://codesandbox.io/s/w29o7r7zol
I'll have a deeper look at it and see what I can come up with or if a PR is necessary.  Since this is working properly in your demos, I may be overlooking something.

I added these two classes:
.App {
  height: 100%;
  display: grid;
  grid-template-rows: auto auto 1fr;
}

.grid {
  height: unset !important;
}

The first one makes sure the grid gets an actual chunk of the screen because it's suppose to scroll inside the grid container, not outside (the would involve some more complex changes). The second i chalk up to css being weird or i don't know enough about it, but works ...

Thanks @drcmda - Interestingly enough, just setting the .grid class to any height desired with !important solves the largest issue for me.
I'd like to take a stab at altering to the way I like - I didn't see a start script in your package.json.  How do i run it?
Thanks Again!
I'll close this out after, as I think this addresses the lions share of my issue.

There’s none atm, I just copy the component out to test and evolve it for now.


Cannot use existing infrastructureResourceGroup when creating a new Consumption + Dedicated managed environment

This issue is a: (mark with an x)

[X] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
When creating a Consumption + Dedicated managed environment I am required to provide a resource group that will be used for hosting infrastructure resources; if this resource group already exists I get an error stating as such. The alternative is to provide a name that doesn't exist and let Azure create the resource group but that doesn't work in my case as my company has an Azure policy in place requiring certain tags and so the resource group create gets rejected by policy.
Steps to reproduce

In the portal, begin creating a new container app and choose to create a new environment.
For the new new environment, choose Consumption and Dedicated workload profile.
In the networking tab, choose a resource group that already exists for for "Infrastructure resource group".
Complete setup of the container app.
Upon deploy, get an error indicating the infrastructure resource group already exists.

Expected behavior [What you expected to happen.]
The existing resource group is used by the managed environment.
Actual behavior [What actually happened.]
Error when deploying the managed environment.
Screenshots
Choose an existing resource group.

Error when using an existing resource group.

Additional context
Ex. Did this issue occur in the CLI or the Portal?

Hi, you can't use an existing resource group. It must be created empty and managed by ACA.

...but that doesn't work in my case as my company has an Azure policy in place requiring certain tags and so the resource group create gets rejected by policy.

What's the recommendation for the case I mentioned where a policy causes the managed resource group create to fail? As far as I can tell there's no way to pass those tags in. The only workaround I can think of is to temporarily disable that policy or put some sort of exception in place based upon maybe a naming convention; neither one seem like a very user friendly solution.

If it's just tags propagation then you should have these options in the create flow. The environment tags will propagate to the managed resource group.

That doesn't seem to be working either:
When creating a container app opt to create a new environment, Consumption + Dedicated, and specify the infrastructure resource group.

Continue creating the container app and specify the required tags:

The infrastructure resource group gets rejected by policy, you can see here one of the tags it's complaining about which is added in the above screenshot.

sending me you subscription id and correlation id to acasupport at microsoft dot com. The on call engineer will take a look.

@jlosenicky, we found the bug a fixed it. The fix will be deployed in the upcoming two weeks.

Has the 'Infrastructure Resource Group' input been removed? Or is not yet available in UKSouth?

I'm populating it in my Bicep script but it is ignored.

Related question:
If I don't populate infrastructureResourceGroup, then will/should it be populated in my Bicep script once the CAE is created?

This works correctly as described by @torosent. Might be worth articulating the propagation of tags in the documentation. It's not intuitive that a resource group is a "child" of the environment.
The error you currently see is also confusing - it implies you might be able to nominate an existing resource group if it's "unassigned".

The resource group  /subscriptions/.../resourceGroups/... already exists or is assigned to another managed environment


Getting error in Auth.php during authentication

Hi I got this error
{"message":"Call to undefined method Closure::authenticate()","code":1,"status_code":500,"debug":{"line":82,"file":"C:\\xampp\\htdocs\\library-api\\vendor\\dingo\\api\\src\\Auth\\Auth.php","class":"Symfony\\Component\\Debug\\Exception\\FatalErrorException","trace":["#0 {main}"]}}
how do I resolve this? in line 82, $providers->authenticate method is not found.

Just open one issue. :smile:

how did you solve it


[Issue] Hooks should state that powershell 7 is required

I believe pwsh is a PowerShell 7 feature/alias.  On a new machine I didn't have Powershell 7 installed and got a generic pwsh not found error.  Detection would be great.

We can document this as a fit-n-finish item. If possible, we can also adjust code for detecting and erring.
This could also be related to the external template dependencies which someone would want to express and get handled cc @Austinauth

Can we get the docs enhanced with PowerShell 7 requirement for pwsh scripts?
https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/azd-extensibility


docs: migrates jsdoc to i18n for common libraries

Overview
Migrates jsdoc to i18n(.md) for some common libraries.(korean first)
PR Checklist

[x] I read and included theses actions below

I have read the Contributing Guide
I have written documents and tests, if needed.

TODO:

Adds both .ko.md and .en.md for all common libraries
Fixes temporary .en.md docs in:

date
utility-types
utils


[BUG] Pathological failure of "Integration with Unreleased OpenSearch (1.x)"

What is the bug?
The "Integration with Unreleased OpenSearch (1.x)" job is consistently failing with "Hosted Agent lost communication with the server" or "The runner has received a shutdown signal". Failure appears to happen during compilation of yaml_test_runner, it does not appear to ever reach the actual running of the tests.
How can one reproduce the bug?
Run the "Integration with Unreleased OpenSearch" workflow, by pushing code or triggering a re-run of a failed run.
What is the expected behavior?
The job to complete successfully, as the tests do pass on local machine.
What is your host/environment?
GitHub Actions
Do you have any screenshots?

or

Do you have any additional context?
This run still fails even after 6 attempts:
https://github.com/opensearch-project/opensearch-rs/actions/runs/3790230286/jobs/6458455887

Tests against unreleased 1.x have now been re-enabled


Support exclusions in inputs

Description

Support exclusion globs (!some-glob) in inputs specifications
Modify file hashing for a package to only consider git status in the case where we aren't using inputs. inputs already uses git hash-object which operates on the state of the working tree, as opposed to git ls-tree which operates on a particular commit. This additionally fixes an issue where a dirty file not included in inputs could get included in the hash.
Fix manual file hashing to use the correct prefix on globs (and to support exclusions)
Modify globby to allow excluding individual files, not just directories

We have behavior to force excludes in globby to apply to directories, but AFAICT we don't document this behavior. Our existing documentation of excludes in outputs uses **. My preference would be to drop it so that we have a unified globbing syntax. However, my code here special-cases user input that ends in ** to maintain both behaviors.
Testing Instructions
A new integration test uses inputs with an exclusion to exclude a file from the hash. The excluded file is modified in the test, then hash matching and full turbo are verified.
Globby has a new test as well for excluding a single file, vs a directory.
taskhash_test.go has an additional edge case to handle excluding files in inputs specifications that fall back to manual file hashing.
Fixes #1407

I've updated the PR to maintain the current behavior while also allowing for excluding files. So there is no longer a change to the globby test, just the addition of single files to it.
I continue to think we should fix the special case for exclusions, since it's odd to support two different globbing syntaxes, especially in the same config field, but I will leave that for a separate PR.


VCI not loading

My VCI pages and dashboard are not loading. I get the continuing loading wheel. I have tried restarting my computer but nothing has changed. The links I have tried are below:
https://curation.clinicalgenome.org/dashboard/
https://curation.clinicalgenome.org/variant-central/2613fc72-cf41-4968-8128-9371c6536a4d/
Here is a screenshot of what it looks like.

Hi @msingerb, thanks for reporting this issue. Please try clearing your browser cache and logging back in, it could be the browser as I am having success loading those links. Let me know if it still is not working and we will investigate further.

Hi Mark. I tried clearing my cache and now im getting an error signing in


[WIP] Another attempt at idtoken

I've removed https://github.com/grafeas/voucher/pull/54 as a dependency of this PR, and tidied the iamcredentials API usage a bit in https://github.com/grafeas/voucher/pull/57 .  Thanks for the algorithm, yoink!


Add an embeddable version of the default viewer

Please add an embeddable version of the default viewer or a viewer with comparable functionality and deploy it with npm. With embeddable I mean that the viewer is some <div> that you can include using your favorite template engine.
I am well aware of the reasoning in #5609. I don't think that this applies to an embedded viewer as it is still clearly part of a website and not of firefox or chrome. Various websites are using the default viewer anyway as there's no real alternative. Even projects as big as nextcloud include the default viewer instead of creating their own viewer.
Due to the lack of an official embedable viewer most sites vendor the package from the website. This means every update is manual extra work and a lot of outdated viewers, which is clearly undesirable. There is even a project which attempts to deploy an embeddable version themselves, but it seems to be abandoned.
For those reasons I think it is desirable for pdf.js to deploy an easily embeddable default viewer or a comparable viewer.

I don't think that this applies to an embedded viewer as it is still clearly part of a website and not of firefox or chrome.

It very much applies here, since it's essentially impossible for a "regular" user to tell if what they're seeing in an <iframe> is the Firefox built-in PDF Viewer or rather a version of the default viewer hosted by the web-site itself; please see http://mozilla.github.io/pdf.js/getting_started/#introduction (emphasis mine):

The viewer is built on the display layer and is the UI for PDF viewer in Firefox and the other browser extensions within the project. It can be a good starting point for building your own viewer. However, we do ask if you plan to embed the viewer in your own site, that it not just be an unmodified version. Please re-skin it or build upon it.

Given that there's the viewer components examples, and that the default viewer isn't really intended to be used as-is any way (as mentioned above), should this issue simply be closed as WONTFIX?

Yes, I would agree with the reasoning above. If there is any way to improve the existing examples to make usage easier, feel free to open an issue with a suggestion or create a pull request; we'll be happy to review those.