Serviceability: need better error message when missing github secret

when building nodejs express through tekton pipeline and the github secret is missing, the build is fail with error could not read Username for 'https://github.ibm.com': No such device or address.  Can we add a message to let users know that they need to create a secret for github?
Below is the full error:
{"level":"warn","ts":1568057939.538,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: \"KO_DATA_PATH\" does not exist or is empty"}
{"level":"error","ts":1568057939.8545134,"logger":"fallback-logger","caller":"git/git.go:35","msg":"Error running git [fetch --depth=1 --recurse-submodules=yes origin fc7fe7fb8d87779dd5419b509dd2c91e63ba87b7]: exit status 128\nfatal: could not read Username for 'https://github.ibm.com': No such device or address\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\t/go/src/github.com/tektoncd/pipeline/pkg/git/git.go:35\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\t/go/src/github.com/tektoncd/pipeline/pkg/git/git.go:88\nmain.main\n\t/go/src/github.com/tektoncd/pipeline/cmd/git-init/main.go:36\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:198"}
{"level":"error","ts":1568057940.1771348,"logger":"fallback-logger","caller":"git/git.go:35","msg":"Error running git [pull --recurse-submodules=yes origin]: exit status 1\nfatal: could not read Username for 'https://github.ibm.com': No such device or address\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\t/go/src/github.com/tektoncd/pipeline/pkg/git/git.go:35\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\t/go/src/github.com/tektoncd/pipeline/pkg/git/git.go:91\nmain.main\n\t/go/src/github.com/tektoncd/pipeline/cmd/git-init/main.go:36\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:198"}
{"level":"warn","ts":1568057940.1772096,"logger":"fallback-logger","caller":"git/git.go:92","msg":"Failed to pull origin : exit status 1"}
{"level":"error","ts":1568057940.1798232,"logger":"fallback-logger","caller":"git/git.go:35","msg":"Error running git [checkout fc7fe7fb8d87779dd5419b509dd2c91e63ba87b7]: exit status 128\nfatal: reference is not a tree: fc7fe7fb8d87779dd5419b509dd2c91e63ba87b7\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\t/go/src/github.com/tektoncd/pipeline/pkg/git/git.go:35\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\t/go/src/github.com/tektoncd/pipeline/pkg/git/git.go:94\nmain.main\n\t/go/src/github.com/tektoncd/pipeline/cmd/git-init/main.go:36\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:198"}
{"level":"fatal","ts":1568057940.179904,"logger":"fallback-logger","caller":"git-init/main.go:37","msg":"Error fetching git repository: exit status 128","stacktrace":"main.main\n\t/go/src/github.com/tektoncd/pipeline/cmd/git-init/main.go:37\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:198"}

Step failed

@tseelbach - this is needed by Epic: https://github.com/kabanero-io/roadmap/issues/67. Add the Epic release value here

We were able to reproduce it when we have our project in github.ibm.com and then it is mandatory to setup a github secret. If user miss to do that you get the error shown in description of this issue.
After investigation we found it comes from Tektoncd code.
Below is the direct link to the Tekton code from where the error is coming which we see after the failure of the pipeline.
https://github.com/tektoncd/pipeline/blob/master/pkg/git/git.go#L35
The problem is the error is not showing clear message that github secret is missing.

Mark is there an open issue in tektoncd to make the message more clear when secret is missing?

Hi @tseelbach there are 194 issues under https://github.com/tektoncd/pipeline/issues. I've looked through them and no, and cannot see that there's an open issue for this.

The following has been added to the Tekton Dashboard README file to help address the issue:
Keep in mind that when running your Tekton Pipelines, if you see a `fatal: could not read Username for *GitHub repository*: No such device or address` message in your failing Task logs, this indicates there is no `tekton.dev/git` annotated GitHub secret in use by the ServiceAccount that launched this PipelineRun. It is advised to create one through the Tekton Dashboard. The annotation will be added and the specified ServiceAccount will be patched.
Consider adding a similar statement to the kabanero-pipelines troubleshooting guide and open an an issue in the tektoncd/pipline to ask for a more helpful error message.

We would open the issue in https://github.com/tektoncd/pipeline/issues as suggested above by @mnuttall . Also we would add the above note in our troubleshooting guide.

@aadeshpa  I've spoken with @mnuttall:

https://github.com/tektoncd/pipeline would be the place to raise it. This type of error can occur for a set of related reasons:

The user has created a secret for github but not patched that secret onto the service account used by the PipelineRun or TaskRun in question, or
The user has not created a secret for github, but has tried to patch the relevant service account, or
The user has not created a secret for github and has not patched the relevant service account

After we open the issue, we should link to this issue; but we should also update our troubleshooting guide in the short term to help customers resolve this issue for usage with Kabanero

@aadeshpa - May you please provide us with the link to the issue that you have opened under https://github.com/tektoncd/pipeline for the Tekton team to have it completed during the next release.  As well, please provide us with the link to the issue that updates the troubleshooting guide that is required for this release.

@marikaj123 : Please find the issue created in the repository: https://github.com/tektoncd/pipeline/issues.
https://github.com/tektoncd/pipeline/issues/1375

Below is the pull request to update the note in our troubleshooting guide.
https://github.com/kabanero-io/kabanero-pipelines/pull/80

The troubleshooting pull request is merged. Closing this issue.
To track the issue we opened :- tektoncd/pipeline#1375
we have created a tracker issue in our pipelines repo as per discussion with @tseelbach .
https://github.com/kabanero-io/kabanero-pipelines/issues/81


Inchoo_PHP7_Helper_Data class not found

When the compilation is on for Mag 1.9, I have getting the fatal error Inchoo_PHP7_Helper_Data class not found and when I didable the compilation from admin System -> tools, it is not showing any error. Can anyone sort this error?

I'm getting the same error.
I have however removed Inchoo PHP7, there is no reference to any of it in our files.
I have cleared all caches, restarted php and varnish.


Feature for set defaults?

Same as Flatpickr.localize(locale) probably need to add feature for Flatpickr.setDefaults({  })?
I tried to set through Flatpickr.defaultConfig.time_24hr = true; but no luck :)

I use flatpickr in a module environment and have no problems with

Flatpickr.defaultConfig.time_24hr = true

But surely a method like that might make things a bit easier, esp. if setting multiple defaults


fix(build): fix broken sourcemaps

The latest version of SystemJS fixed their support for sourcemaps, which caused our production builds to fail since our source maps weren't being generated/copied properly down the build pipeline.
This PR fixes that. Also closes https://github.com/angular/angular-cli/issues/829.

@hansl can you review again please?

Okay that makes more sense :)  LGTM.

Can a release get cut with this change so people not running on master can get it?


WIP: Convert internal representation

Let's use Bitboards, after all!
typedef struct {
    Bitboard whiteKing;
    Bitboard whiteQueens;
    Bitboard whiteRooks;
    Bitboard whiteKnights;
    Bitboard whiteBishops;
    Bitboard whitePawns;

    Bitboard blackKing;
    Bitboard blackQueens;
    Bitboard blackRooks;
    Bitboard blackKnights;
    Bitboard blackBishops;
    Bitboard blackPawns;
} Board;

Closed in favor of #13


Android splash screen followed by gray wave transition into Godot splash screen

Tested versions
4.3.stable.official on Windows; Godot app 4.3 on Android
Only one Android phone tested, though.
System information
Windows 10 - Godot 4.3; Android Pixel 7a, all launchers
Issue description
Somewhat related to https://github.com/godotengine/godot/pull/92965, when a Godot-built APK launches, the android splash screen always plays a swipe cut transition from the top of the screen into the Godot game splash screen. The swipe cut resembles a gray wave. On my app, I discovered this because I wanted to launch into a pure white screen that matches my game's start screen. In my case:

I updated AndroidManifest.xml to make the windowSplashScreenBackground white
I set my game to start at a white screen
I set Godot's splash screen to just the color white

So I expected the app to launch all white, and then the first time I'd see any change was after my game had started. However, there's a very ugly gray, cut-off transition after the white splash screen from Android's launcher, which makes my cool app feel crappy and lame.
You can see this in the Godot 4.3 app as well, when the app launches, which should show that it probably affects all Godot-built Android apps.
Steps to reproduce

Open the official Godot 4.3 app
Observe the brief swooshing wave color
Close the app from Recent Apps to force a cold relaunch

Minimal reproduction project (MRP)
I don't have an MRP. Look at the official Godot app.

Hello,
Could you tell me how you update AndroidManifest.xml to make the windowSplashScreenBackground white ?
Thanks, Ronan


monster

Song Name
monster
Artist Name
yoasobi
Source
Youtube
Youtube Link
hoG_FMUTt4ICzxz1
Direct File Link
No response
Song ID
233860
Start Offset [ms]
2:11
Extra
Created from Auto Nong.
Created for level: 87469594

reject
invalid YouTube link


Leave suggestion on ConstructorOfATypedSvelteComponent

As I've asked in this post, there was no hint or warning that could have lead me to finding SvelteComponentTyped, so I wanted to leave a warning for any other users.

how was I silly enough to make a PR to my own fork


Added default security authorization rules for tweek_editor_user

closes #584

Add auth/@global/* permissions with JPad with default value "allow".
We can add short description in the keys.


landing page: UX review and styling

Change suggestions for the landing page:
Generally

Be consistent with the use of headlines and spacing to create a clear hierarchy.
Font weight (300) is very thin and hard to read, could be 400
Bug?: Font (Lato) is not loading unless it's installed in the local system

Side bar

Move the keywords, DOI, license, upload information, etc. to the side bar as this is key information about the record and should be easy to find.

Export

Change the export selection to dropdown, rather than blue links and download the exported file directly.

Contributors

Group all the contributor-types, and display the groups horizontally instead of vertically to avoid too much whitespace, and to make it easier to go through the related content without scrolling and losing context.
Have only one "show affiliations"-button if they're all showing the same content (it's not necessary to have more than one button for the same thing).
Move "show-affiliations"-button to the very right, bottom of the section to indicate that the extra content is relevant for all the groups, and that it will show up below.

Citation

Change the citation style selection to a dropdown. I found myself hesitating to click the blue links (I was wondering if they would take me somewhere)
Follow the pattern of having the interactive elements all the way to the left if they are interactive with all the content of the section.

Description

Additional descriptions are pulled out from the details section and displayed as subsections of the main description.

Files

Remove the preview button from the file-list. It doesn't seem like it is doing anything? And the preview is already open and easily accessible right above. Instead add a comment rather than a button (e.g. "In preview") to show that this is the file being previewed.

Details section

Reorganise the details-content in the main section to increase the readability. Stacking the text vertically instead of horizontally (especially when there are multiple levels) makes it easier to read and understand. A vertical listing makes sure that the reader don't have to move the eyes around too much to see the related content.

Fixed


Book Maintenance Plugin now works with Roblox Script Injection permissions

The code wasn't designed with the concept that setting the source might not work, so it's currently set to retry forever. trySetSource would be good to keep as-is if we have any intent of taking advantage of its shouldCancel parameter - otherwise its extra functionality should be stripped and it can just become setSource. Do you think yielding 1 second at a time (possibly forever) is okay behaviour, or should we modify the code everywhere setSource is used so that it cancels after a while and ceases whatever it was doing?

Oh, ok.


Move systemd unit file from heredoc to file (Linux packages)

Proposed Change

The current install method for the systemd unit file forces an overwrite. This was acceptable as the user can use a systemd override.
Some users prefer to modify the service file directly, and want to rely on the package manager to determine if the configuration should be upgraded or left alone. We can accomplish this by moving the service file from the post install script to a static file managed by the built package.
Changes

Added systemd unit file as a "config" type to be packaged with nfpm
Post install script will continue to reload systemd

We loose the ability to detect the systemd directory, which might be okay as I tested on the following without issue

centos 7, 8
ubuntu 18, 20, 22
debian 9, 10, 11
sles 12, 15

If I modify the unit file directly, a package upgrade does not replace the file.
Considerations
Supporting pre systemd systems (ubuntu 14) will likely require that we build a second package that excludes systemd and includes an init script. The post install script provided this flexibility but has not been implemented yet.
Checklist

[x] Changes are tested
[ ] CI has passed

I'm REALLY apprehensive about this change. Having the customer able to change the service file directly means we CANNOT change our service configuration in the future (meaning, if we add new flags that need to be used, or add new environment variables that need to be used), because we can't overwrite their file.
Are we 100% sure we are OK with that? I don't think I understand why the customer wants this.

Closing for now. Will re-open if needed.

Tested this on ubuntu 18.04 'cuz I remembered in test kitchen finding that /usr/lib/systemd/system didn't exist by default, but it runs as expected.

Yes, the directory is not there by default but it gets created and functions as expected.
I will make the changes you suggested 👍


[BUG]: UNWANTED SIDEBAR BUTTON ON PAGES 🪲

Description

The bug is about removing the unwanted sidebar button which is present on the other pages of food recipes site like about, our services, gallery, etc.
We want to remove it otherwise it will act as a bloatware on the UI.

Screenshot

Hey there @Anupkjha2601 👋🏻,
Please make sure to assign this issue to me as soon as possible so that i can proceed my progress regarding fixing this issue.
Thank you!


Ajax, infinite scroll while showing post (and eventually followers/following)

Infinite scroll working on index.


x/tools/gopls: support for comment rendering

I propose adding a gopls command that uses doc/comment to render documentation comments of package-level declarations. The intent is that this command would be used by a development environment to render pkgsite-style documentation for workspace packages. This could serve the following purposes:

Viewing documentation for code changes that have not been published yet.
Viewing documentation for private repositories.
Reviewing documentation as I write it, to ensure it is formatted the way I want.
Viewing documentation from within my development environment, without needing to switch to a browser.

I'll grant the first three items can be achieved by running pkgsite locally, but that does not address (4), it is less than convenient, and in my experience does not work well for (3).
I propose:

gopls/internal/lsp/cache/docs, which will locate documentation comments, parse them with doc/comment.Parser, and convert the doc/comment.Doc into marshallable types such that the result can be cached.
gopls/internal/lsp/command.Interface.RenderDocs, which will retrieve doc/comment.Docs from a snapshot and render them:

type RenderDocsParams struct {
	Package        protocol.URI
	Declaration    protocol.Location // location of the declaration to generate docs for, optional, omit to render for the entire package
	Format         string            // comment, html, markdown, or text
	HeadingLevel   int               // doc/comment.Printer.HeadingLevel
	HeadingIdTmpl  string            // template for rendering header IDs with doc/comment.Printer.HeadingID
	DocLinkTmpl    string            // template for rendering document links with doc/comment.Printer.DocLinkURL
	DocLinkBaseURL string            // doc/comment.Printer.DocLinkBaseURL
	TextPrefix     string            // doc/comment.Printer.TextPrefix
	TextCodePrefix string            // doc/comment.Printer.TextCodePrefix
	TextWidth      int               // doc/comment.Printer.TextWidth
}

type RenderDocsResult struct {
	Result string
}

CC @hyangah @adonovan

@gopherbot, please add label FeatureRequest

(4) Viewing documentation from within my development environment, without needing to switch to a browser.
I'll grant the first three items can be achieved by running pkgsite locally, but that does not address (4), it is less than convenient, and in my experience does not work well for (3).

How would this new protocol-level command be used? Would each LSP client need to add custom logic to invoke it?
If you want to see the complete documentation for a symbol in your editor, jump to its declaration. If you want to see the summary, use your editor's LSP hover feature. If you want to see the complete rendered markup as it would appear on pkg.go.dev, running a local server is the right way to do that (though unfortunately that it is not yet possible, but will be soon). I don't really understand what additional value this command would provide.

I don't really understand what additional value this command would provide.

My motivation is that I want an action within VSCode (such as clicking on something) that will bring up an editor view that is basically pkg.go.dev for local packages. I don't want to literally embed pkg.go.dev (or a local version) in a webview - I'd prefer something more seamless. I was thinking a markdown preview. This is something I've wanted for a long time and I keep coming back to. I played around with making my own extension to do this, but I ran into a lot of unpleasantness. I tried using gddo to generate HTML and dump that into a webview, but the code was a mess and the UX was bad. A separate helper process akin to gopls would be better, but I'd basically be recreating a subset of gopls, and a worse version of it. And to make it performant I'd need to reimplement gopls's caching and workspace logic.

How would this new protocol-level command be used? Would each LSP client need to add custom logic to invoke it?

By protocol-level command are you referring to a language server method? I am suggesting a command that would be executed via the workspace/executeCommand LSP method, such as you suggested for #59445, not a new LSP method. Since this is not a standard part of the LSP, yes, each client would need to add custom logic to invoke it. In the case of VSCode, I am imagining some UI element that the user clicks on; then vscode-go executes the command and creates a read-only editor, markdown preview, or webview with the results.

If you want to see the complete documentation for a symbol in your editor, jump to its declaration. [...] If you want to see the complete rendered markup as it would appear on pkg.go.dev, running a local server is the right way to do that (though unfortunately that it is not yet possible, but will be soon).

Personally, I find pkg.go.dev much easier to read than source code when I trying to figure out how to use some package. I've effectively trained myself to go into "How does this code work" whenever I see source code, instead of "How do I call this code" mode, and I find rendered HTML easier to read than comments. Thus I find it much easier to answer "How do I call this code" via pkg.go.dev than via source.
I've tried running pkgsite locally. It works well enough for use cases (1) and (2), but when I run it without any flags it does not work for (3) because once it renders a package, it does not re-render comments if I update them. There's a flag that will change that, but last time I used it things got weird/buggy and I had to restart the process pretty much every time I wanted it to re-render my updates. Regardless/assuming those are bugs and they are fixed, that does not address (4). A big part of my motivation is that I want to see the documentation from within VSCode/without opening a browser, and I want it to feel seamless/fit into VSCode's UX and theming. Hence why I was thinking of using VSCode's markdown preview feature for presentation.
I would be happy to do the work myself, and I'm fine with doing the VSCode/presentation portion in a standalone extension. I opened this issue because doing the work and submitting a CL before discussing it didn't seem like the right move.

I don't want to literally embed pkg.go.dev (or a local version) in a webview - I'd prefer something more seamless.

I see. And I (a stone-age emacs user) thought a webview was the height of integration...

By protocol-level command are you referring to a language server method? I am suggesting a command that would be executed via the workspace/executeCommand LSP method, such as you suggested for #59445, not a new LSP method. Since this is not a standard part of the LSP, yes, each client would need to add custom logic to invoke it.

Got it. From a system design point of view, there's little difference between the two kinds: the client and server both need special logic for each server RPC and for each ad-hoc command.
(I do wish LSP were more composable. For example, I want to implement a new query operation that returns a set of source locations with one-line descriptions, analogous to the output of grep, or a compiler, or a references query, or any other kind of workspace-wide query. It would be nice if there was a way to indicate in the protocol that the result should be displayed using the client's usual UI elements for such things. But instead you get nothing unless you write logic for n different clients...)

Personally, I find pkg.go.dev much easier to read than source code when I trying to figure out how to use some package. I've effectively trained myself to go into "How does this code work" whenever I see source code, instead of "How do I call this code" mode, and I find rendered HTML easier to read than comments. Thus I find it much easier to answer "How do I call this code" via pkg.go.dev than via source.

Yeah, I agree. The API docs provide a clearer overview, and keep you honest about interface vs implementation. They're also useful for previewing how you new code would appear to its users.

I've tried running pkgsite locally. It works well enough for use cases (1) and (2), but when I run it without any flags it does not work for (3) because once it renders a package, it does not re-render comments if I update them. There's a flag that will change that, but last time I used it things got weird/buggy and I had to restart the process pretty much every time I wanted it to re-render my updates. Regardless/assuming those are bugs and they are fixed,

Yep, we will fix all those things this year.

...that does not address (4). A big part of my motivation is that I want to see the documentation from within VSCode/without opening a browser, and I want it to feel seamless/fit into VSCode's UX and theming. Hence why I was thinking of using VSCode's markdown preview feature for presentation.

I see. It still seems to me that the marginal value over a VS Code webview will be rather small, not enough to justify adding support for a new protocol-level request to N editors. It also seems duplicative: rendering Go docs beautifully is pkgsite's job, and this feature would require gopls to know how to do it as well (and lead to a stream of issues when the two tools differ).
I wonder whether this might be something that can be squeezed into the existing protocol, perhaps as the hover response for a "package foo" declaration, which doesn't currently appear to generate any hover text---though I can imagine the complete package doc is too much for a hovering popup.

I would be happy to do the work myself, and I'm fine with doing the VSCode/presentation portion in a standalone extension. I opened this issue because doing the work and submitting a CL before discussing it didn't seem like the right move.

Thanks for the offer, and for discussing this first.

I do wish LSP were more composable.

There have been some discussions related to this. The LSP spec includes a Base protocol specification, which seems like an answer to your desire to a degree. Though extensible != composable, but it's something worth being aware of.

It still seems to me that the marginal value over a VS Code webview will be rather small,

I think this, along with within-vscode vs browser and formatting, is subjective, so the most I can do is explain my own perspective. Having something within VSCode is worth the time I'd invest in this since every time I alt-tab to another window, it disrupts my workflow to a degree (especially if I'm switching between more than two windows). My dissatisfaction with using a webview is similar - embedding a website directly feels clunky, because the UI and styling is quite different, there are UI components that are just extra noise in this context (mainly navigation), links can be tricky, etc. I have tried to resolve those issues by injecting styles and/or scripts and/or modifying the HTML, but that's a mess. Ultimately it means that it's much harder and potentially infeasible to make it feel seamless, and thus more mental overhead to compensate for that dissonance.
With respect to formatting, that's even more of a subjective value judgement. Personally I believe I would be satisfied with some markdown thrown at VSCode's built-in renderer. I do not expect my development environment to be pkgsite-level beautiful. For example, being able to do something like this is far more important to me:

I select a method and execute "Open documentation" (via right click, command pallet, etc).
That opens the documentation for the package the method belongs to and scrolls to the method.
I find some other declaration I want to jump to; e.g. clicking on the return type, or a "see also" link in the method's documentation, or scrolling through the package docs until I find what I want.
I click on the new declaration to jump (within vscode) to its source code, or I right click on it and execute "Find all references".

My point is, nicely formatted documentation is low on my priority list; more important to me are minimizing context switching, distractions, and other dissonance (such as switching between dark-mode code and light-mode pkgsite) and being able to easily jump around, from code to docs, docs to docs, and docs to code (also code to code, but that's already covered).

...not enough to justify adding support for a new protocol-level request to N editors

My immediate response, with my "I'm a user" hat on, is that this is a convenience feature the language server is providing and thus not something that needs to be implemented for every editor. But when I think about it more and put my maintainer hat on, I can see that implementing it for one editor would likely lead to users asking, "Why doesn't <my editor> have this feature" and thus pressure to implement it for all editors.

It also seems duplicative: rendering Go docs beautifully is pkgsite's job, and this feature would require gopls to know how to do it as well (and lead to a stream of issues when the two tools differ).

I'm not proposing adding any rendering code; I want to reuse doc/comment's rendering:
type RenderDocsParams struct {
	Format string // comment, html, markdown, or text
	// ...
}

type RenderDocsResult struct {
	Result []string
}

func RenderDocs(ctx context.Context, params RenderDocsParams) (RenderDocsResult, error) {
	var result RenderDocsResult
	docs, err := retrieveDocs(ctx, params)
	if err != nil {
		return result, err
	}

	printer := configureCommentPrinter(params)
	var render func(*comment.Doc) []byte
	switch params.Format {
	case "comment":
		render = printer.Comment(doc)
	case "html":
		render = printer.HTML(doc)
	case "markdown":
		render = printer.Markdown(doc)
	case "text":
		render = printer.Text(doc)
	default:
		return result, fmt.Errorf("unsupported format %q", params.Format)
	}

	for _, doc := range docs {
		result.Result = append(result.Result, string(render(doc)))
	}
	return result, nil
}

On the vscode-go side, I'm suggesting asking gopls for markdown and letting VSCode handle rendering. I wrote a small essay above about formatting so I won't reiterate here.

I'm suggesting asking gopls for markdown and letting VSCode handle rendering.

This is aligned with what I've been expecting. I agree pkgsite UI isn't a good fit for in-editor viewer. Its use of javascript and pkgsite service oriented design doesn't blend well. Heavy-weight webview is not a recommended best practice in VS Code either.
A custom command (e.g. gopls.render_package) that takes doc URI and optional parameters (e.g. include unexported symbols, include indexes, ...) and returns bytes will be helpful. Not sure about all Format other than markdown or HeadingLevel, HeadingIdTmpl, ... yet but we can expand param as we find more use cases.
I experimented with princjef/gomarkdoc with some modification + vscode markdown renderer and got a pretty promising output.

Update: it seems that vscode's default markdown preview's functionality is quite limited. For example, we will probably want some links to point to files outside the workspace (e.g. file in module cache or stdlib), but the vscode's default markdown preview does not support file:/// uri (https://github.com/microsoft/vscode/issues/182870, ...), nor true relative/absolute paths ( https://github.com/microsoft/vscode/issues/120754, https://github.com/microsoft/vscode/issues/139289, ...). MS VSCode team seems to recommend markdown extensions or custom solution. :-( I think a simple, basic html (without any fancy styling or javascript) is better in this case.

Not sure about all Format other than markdown or HeadingLevel, HeadingIdTmpl, ... yet but we can expand the request message type as we find more use cases.

I was thinking along the lines of exposing most/all of the capabilities of doc/comment.Printer against unknown future needs/clients other than VSCode, but I'm fine with starting small. Though I think allowing customization of doc links is a good idea, since we probably want those to execute VSCode commands.

I experimented with princjef/gomarkdoc

Does that have advantages over go/doc/comment.Printer.Markdown? It looks like it has its own custom templates. My inclination is to use the standard library's markdown generator unless there's a compelling reason to use a third party library.

It seems that vscode's default markdown preview's functionality is quite limited.

That is rather unfortunate :disappointed:. My inclination is to initially live with the limitations of throwing markdown at vscode, and then later work add a custom markdown renderer to vscode-go with more bells and whistles.

Does that have advantages over go/doc/comment.Printer.Markdown?

go/doc/comment.Printer.Markdown itself isn't sufficient to generate a markdown version of package doc.
(princjef/gomarkdoc, go doc, pkgsite, and gopls hover formatting all use go/doc/comment underneath to convert selected comment blocks, but wrap the markdown printer output pieces in templates formulated for their needs). I just used princjef/gomarkdoc just to quickly test markdown output against vscode's markdown previewer and demonstrate why we need better integration than just wrapping pkgsite in webview.


Added key-features to config.json

Added my proposal for the key_features part of config.json. I hope the content strings are not to long and please correct them if necessary, because I'm not a native English speaker :)

LGTM :+1:


User entered number values are being changed after tabbing out of the fields - MaskedEditExtender

The AJAX Control Toolkit \Run time version: 2.0.50727 , File version: 3.0.20820.16598
Note: It happens with all versions of AjaxControlToolkit.
The installation method

Installer

Minimal steps to reproduce the bug
User entered number values are being changed after tabbing out of the fields.
Steps to follow to reproduce the issue:

ASP.Net Web Form code for rendering masked text box
<asp:TextBox ID="txtMainContact" Width="9em" MaxLength="13" runat="server" CssClass="TextboxBorder" />
<cc1:MaskedEditExtender ID="mskMainContact" Mask="(999)999-9999" MaskType="Number" TargetControlID="txtMainContact"
runat="server" Enabled="True" ClearMaskOnLostFocus="true" AutoComplete="false"  />

Compile code and load the page

Enter valid phone number<PHONE_NUMBER>. Mask applies automatically and it becomes<PHONE_NUMBER>

Press 'x' to clear the text box

Enter the number again<PHONE_NUMBER> and tab out from the field.

The number changes to random - example 111112222 ,<PHONE_NUMBER>

Browser(s) used
IE 11 with IE 7 compatibility mode
(the issue reproduces  on IE11 without compatibility as well )
A site deployment method

IIS (The issue reproduces through IIS express as well.)

The current version of the Toolkit is 18.1:

A binary with FileVersion of 3.0.x is very outdated.
I performed the steps you provided but didn't notice the described anomalies.
Screencast: act-issue-449.mp4.zip

Closed due to inactivity.


lums/sc 37627/indexivfflat Group schema

This PR creates a group class ivf_flat_index_group for the ivf_index class that abstracts the TileDB::Group representing an IVF Flat Index.  It also rolls up preceding PRs 131, 149, 153, and 154.  The primary changes for this PR were to add the files ivf_flat_group.h and ivf_flat_metadata.h and to incorporate the revised access to group information into the ivf_flat_index class contained in ivf_flat_index.h.  Also added are unit tests for ivf_flat_group and ivf_flat_metadata.
The group and metadata classes to a fair amount of verification and testing of the data available in the TileDB::group and its associated metadata.
Representing information about the TileDB::Group
The TileDB::Group  always contains the following arrays, which are the minimum necessary to represent an IVF Flat Index:
  partition_centroids
  partition_indexes
  shuffled_vector_ids
  shuffled_vectors

Note that there is a level of indirection between ivf_flat_index_group and these names.  The names may change as TileDB-Vector-Search evolves.  A version number is used to distinguish different versions of the group data.
Other arrays that the Group may contain are:
  input_vectors
  external_ids
  updates

The Group contains another Group
temp_data

Finally, the group contains information about attribute filters, and whether or not it supports time traveling, with the tags
default_attr_filters
support_timetravel

This information is captured by ivf_flat_index_group.  A uniquie_ptr to an ivf_flat_index_group is now part of the ivf_flat_index class.
Index Arrays
The index represented by an ivf_flat_index_group support insertions, deletions, and consolidation.  As a result, the size of the matrix or vector being stored in one of the group arrays will change over time.  To handle this, the domain for each of the arrays is set to  go from zero to std::numeric_limits<type>::max() - 1.  To specify how much of each such array is active and should be read in, we keep information about the index dimension, its overall size (number of vectors and ids), and its number of partitions (equal to number of centroids and one less than the index size).  If time traveling is enabled, this information is updated on each consolidation.  The ivf_flat_index_group class has methods for getting the most recent value of each of these quantities, as well as to append a new value.  Access to arbitrary timestamps will be added as part of implementing time traveling.
Metadata
The group also contains metadata with further information about the Group:
      dataset_type
      index_type
      storage_version
      dtype
      feature_type
      id_type
      indices_type
      base_sizes
      ingestion_timestamps
      partition_history
      temp_size
      index_kind
      dimension
      feature_datatype
      id_datatype
      px_datatype

These metadata are captured by ivf_flat_index_metadata.  An ivf_flat_index_metadata object is a member of the ivf_flat_index_group class.
These metadata are a superset of what is currently defined in the the Python API.  The current ivf_flat_index_group class and ivf_flat_index_metadata class should be able to read an index group created by the Python API.  However, due to the lack of a set of meaningful index group arrays, this conjecture has not been tested.
Time traveling
Note that time traveling is currently not fully implemented in this PR, but will be added as a PR in the very near future.  The necessary infrastructure to support time traveling is part of ivf_flat_index_group and ivf_flat_index_metadata.  Time traveling is intimately related to insertions and deletions to the index.  Partial support for that has been added as well.  A PR in the near future will add this feature.
Unit testing
The ivf_flat_index_group and ivf_flat_index_metadata classes have associated unit tests.  Each class has a compare method to compare self with another object.  These checks have been incorporated into the compare function of ivf_flat_index; tests of ivf_flat_index will now implicitly also check ivf_flat_index_group and ivf_flat_index_metadata.
The primary changes to ivf_flat_index to use ivf_flat_index_group are via calls to the group to obtain information about the sizes of arrays (matrix and vector) that will be read in.
The API for ivf_flat_index did not itself change.  The CLI programs were lightly tested/verified for functionality and correctness, but they were not benchmarked.
The following unit tests are currently known to fail but were not fixed in the interest of getting this PR out:
  unit_vamana_test
  unit_fixed_min_heap_test
  unit_slicing_test

unit_vamana_test will be updated along with future PRs having to do with vamana_index.  The others are lower level and do not impact any active code.  They will be pruned and/or fixed in a future PR.
Misc
Also added was the small fix to tdbPartitionedMatrix that was identified in PR #150.
Compilation and testing was done on MacOS 14.1.2 using Apple clang.  It has not been compiled or tested with g++.

Superseded by #221.


Reduce Error Size from txn_types

Feature Request
There is a missing piece in https://github.com/tikv/tikv/pull/5979 that we recently extracted a new crate called txn_types where basic txn structures relies on. Thus it need to reduce error size as well.

Thanks @silathdiir for your contribution. @breeswish Please confirm whether we can close this issue

@breeswish can we close this issue now?


CMake Debugger hangs "Configuring project: ..." and doesn't open up at configuration error line

Brief Issue Summary
When using the CMake debugger, sometimes it hangs and gets stuck in the configuration phase.
A configure error is reported. When I hit the "Debug" option in the popup when configuration  fails, it hits the same error, and then hangs and is stuck in configuration. If I cancel the session, and try again, it still hangs.

There are also connect ENOENT errors to /tmp/cmake-debugger-pipe-...
CMake Tools Diagnostics
{
  "os": "linux",
  "vscodeVersion": "1.86.1",
  "cmtVersion": "1.16.32",
  "configurations": [
    {
      "folder": "/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue",
      "cmakeVersion": "3.28.2",
      "configured": false,
      "generator": "Ninja",
      "usesPresets": false,
      "compilers": {}
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": false,
    "activeBuildType": "",
    "buildTypesSeen": [],
    "requests": [],
    "responses": [],
    "partialMatches": [],
    "targetCount": 0,
    "executablesCount": 0,
    "librariesCount": 0,
    "targets": []
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": false
    }
  ]
}

Debug Log
[main] Configuring project: costmap_queue
[driver] Removing /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build/CMakeCache.txt
[driver] Removing /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build/CMakeFiles
[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/lib/ccache/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/lib/ccache/g++ -S/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue -B/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-c0578185-d439-4e51-8809-fea162457d57
[cmake] Not searching for unused variables given on the command line.
[cmake] Running with debugger on.
[cmake] Waiting for debugger client to connect...
[debugger] Connecting debugger on named pipe: "/tmp/cmake-debugger-pipe-c0578185-d439-4e51-8809-fea162457d57"
[cmake] Debugger client connected.
[cmake] -- The C compiler identification is GNU 11.4.0
[cmake] -- The CXX compiler identification is GNU 11.4.0
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - done
[cmake] -- Check for working C compiler: /usr/lib/ccache/gcc - skipped
[cmake] -- Detecting C compile features
[cmake] -- Detecting C compile features - done
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: /usr/lib/ccache/g++ - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] -- Found ament_cmake: 2.3.0 (/opt/ros/rolling/share/ament_cmake/cmake)
[cmake] -- Found Python3: /usr/bin/python3.10 (found version "3.10.12") found components: Interpreter
[cmake] -- Found nav2_common: 1.2.0 (/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_common/share/nav2_common/cmake)
[cmake] -- Found nav2_costmap_2d: 1.2.0 (/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_costmap_2d/share/nav2_costmap_2d/cmake)
[cmake] -- Found rosidl_generator_c: 4.4.1 (/opt/ros/rolling/share/rosidl_generator_c/cmake)
[cmake] -- Found rosidl_generator_cpp: 4.4.1 (/opt/ros/rolling/share/rosidl_generator_cpp/cmake)
[cmake] -- Using all available rosidl_typesupport_c: rosidl_typesupport_fastrtps_c;rosidl_typesupport_introspection_c
[cmake] -- Using all available rosidl_typesupport_cpp: rosidl_typesupport_fastrtps_cpp;rosidl_typesupport_introspection_cpp
[cmake] -- Found rmw_implementation_cmake: 7.2.1 (/opt/ros/rolling/share/rmw_implementation_cmake/cmake)
[cmake] -- Found rmw_fastrtps_cpp: 7.6.0 (/opt/ros/rolling/share/rmw_fastrtps_cpp/cmake)
[cmake] -- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "3.0.2")
[cmake] -- Found FastRTPS: /opt/ros/rolling/include
[cmake] -- Using RMW implementation 'rmw_fastrtps_cpp' as default
[cmake] -- Found Eigen3: TRUE (found version "3.4.0")
[cmake] -- Ensuring Eigen3 include directory is part of orocos-kdl CMake target
[cmake] -- Found ament_lint_auto: 0.16.0 (/opt/ros/rolling/share/ament_lint_auto/cmake)
[cmake] -- Found gtest sources under '/opt/ros/rolling/src/gtest_vendor': C++ tests using 'Google Test' will be built
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
[cmake] -- Found Threads: TRUE
[cmake] -- Added test 'cppcheck' to perform static code analysis on C / C++ code
[cmake] -- Configured cppcheck include dirs: /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/include
[cmake] -- Configured cppcheck exclude dirs and/or files:
[cmake] -- Added test 'cpplint' to check C / C++ code against the Google style
[cmake] -- Configured cpplint exclude dirs and/or files:
[cmake] -- Added test 'lint_cmake' to check CMake code style
[cmake] -- Added test 'uncrustify' to check C / C++ code style
[cmake] -- Configured uncrustify additional arguments:
[cmake] -- Added test 'xmllint' to check XML markup files
[cmake] -- Configuring done (3.0s)
[cmake] CMake Error at /opt/ros/rolling/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:146 (target_link_libraries):
[cmake]   Target "costmap_queue" links to:
[cmake]
[cmake]     nav2_costmap_2d::nav2_costmap_2d_markers
[cmake]
[cmake]   but the target was not found.  Possible reasons include:
[cmake]
[cmake]     * There is a typo in the target name.
[cmake]     * A find_package call is missing for an IMPORTED target.
[cmake]     * An ALIAS target is missing.
[cmake]
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:25 (ament_target_dependencies)
[cmake]
[cmake]
[main] Configuring project: costmap_queue
[main] Configuring project: costmap_queue
[extension] [3735] cmake.buildDirectory started
[extension] [3735] cmake.buildDirectory finished (returned "/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build")
[main] Configuring project: costmap_queue
[main] Saving open files before configure/build
[main] Configuring project: costmap_queue
[main] Saving open files before configure/build
[cmake] CMake Error at /opt/ros/rolling/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:146 (target_link_libraries):
[cmake]   Target "mbq_test" links to:
[cmake]
[cmake]     nav2_costmap_2d::nav2_costmap_2d_markers
[cmake]
[cmake]   but the target was not found.  Possible reasons include:
[cmake]
[cmake]     * There is a typo in the target name.
[cmake]     * A find_package call is missing for an IMPORTED target.
[cmake]     * An ALIAS target is missing.
[cmake]
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:38 (ament_target_dependencies)
[cmake]
[cmake]
[cmake] CMake Error at /opt/ros/rolling/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:146 (target_link_libraries):
[cmake]   Target "utest" links to:
[cmake]
[cmake]     nav2_costmap_2d::nav2_costmap_2d_markers
[cmake]
[cmake]   but the target was not found.  Possible reasons include:
[cmake]
[cmake]     * There is a typo in the target name.
[cmake]     * A find_package call is missing for an IMPORTED target.
[cmake]     * An ALIAS target is missing.
[cmake]
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:41 (ament_target_dependencies)
[cmake]
[cmake]
[cmake] CMake Generate step failed.  Build files cannot be regenerated correctly.
[cmake] -- Generating done (111.5s)
[proc] The command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/lib/ccache/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/lib/ccache/g++ -S/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue -B/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-c0578185-d439-4e51-8809-fea162457d57 exited with code: 1
[proc] The command: pgrep -P 1488685 exited with code: 1
[proc] The command: pgrep -P 1488685 exited with code: 1
[proc] The command: pgrep -P 1488685 exited with code: 1
[proc] The command: pgrep -P 1488685 exited with code: 1
[proc] The command: pgrep -P 1488685 exited with code: 1
[main] Starting new CMake driver
[main] Starting CMake driver
[cmakefileapi-driver] Creating instance of CMakeFileApiDriver
[driver] Initializing base driver using kit
[kit] Testing GCC binary: /usr/lib/ccache/gcc
[proc] Executing command: /usr/lib/ccache/gcc -v
[kit] Detected GCC compiler: /usr/lib/ccache/gcc
[driver] CMakeDriver Kit set to GCC 11.4.0 x86_64-linux-gnu
[kit] The environment for kit 'GCC 11.4.0 x86_64-linux-gnu': {
  "AMENT_PREFIX_PATH": "/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_utils:/home/ryan/Dev/nav2_ws/src/navigation2/install/dwb_msgs:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_msgs:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_costmap_2d:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_voxel_grid:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_map_server:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_lifecycle_manager:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_util:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_msgs:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_common:/opt/ros/rolling",
  "CHROME_DESKTOP": "code-url-handler.desktop",
  "CMAKE_PREFIX_PATH": "/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_utils:/home/ryan/Dev/nav2_ws/src/navigation2/install/dwb_msgs:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_msgs:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_costmap_2d:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_voxel_grid:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_map_server:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_lifecycle_manager:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_util:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_msgs:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_common",
  "COLCON_PREFIX_PATH": "/home/ryan/Dev/nav2_ws/src/navigation2/install",
  "COLORTERM": "truecolor",
  "DBUS_SESSION_BUS_ADDRESS": "unix:path=/run/user/1000/bus",
  "DESKTOP_SESSION": "ubuntu",
  "DISPLAY": ":1",
  "ELECTRON_NO_ATTACH_CONSOLE": "1",
  "GDK_BACKEND": "x11",
  "GDK_BACKEND_VSCODE_SNAP_ORIG": "x11",
  "GDK_PIXBUF_MODULEDIR": "/snap/code/151/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders",
  "GDK_PIXBUF_MODULE_FILE": "/home/ryan/snap/code/common/.cache/gdk-pixbuf-loaders.cache",
  "GDMSESSION": "ubuntu",
  "GIO_MODULE_DIR": "/home/ryan/snap/code/common/.cache/gio-modules",
  "GIO_MODULE_DIR_VSCODE_SNAP_ORIG": "/home/ryan/snap/code/common/.cache/gio-modules",
  "GIT_ASKPASS": "/snap/code/151/usr/share/code/resources/app/extensions/git/dist/askpass.sh",
  "GNOME_DESKTOP_SESSION_ID": "this-is-deprecated",
  "GNOME_SHELL_SESSION_MODE": "ubuntu",
  "GNOME_TERMINAL_SCREEN": "/org/gnome/Terminal/screen/46d278ee_e5d2_4e16_8c67_f5c3732732c7",
  "GNOME_TERMINAL_SERVICE": ":1.124",
  "GPG_AGENT_INFO": "/run/user/1000/gnupg/S.gpg-agent:0:1",
  "GSETTINGS_SCHEMA_DIR": "/home/ryan/snap/code/151/.local/share/glib-2.0/schemas",
  "GSETTINGS_SCHEMA_DIR_VSCODE_SNAP_ORIG": "/home/ryan/snap/code/151/.local/share/glib-2.0/schemas",
  "GTK_EXE_PREFIX": "/snap/code/151/usr",
  "GTK_EXE_PREFIX_VSCODE_SNAP_ORIG": "/snap/code/151/usr",
  "GTK_IM_MODULE": "ibus",
  "GTK_IM_MODULE_FILE": "/home/ryan/snap/code/common/.cache/immodules/immodules.cache",
  "GTK_IM_MODULE_FILE_VSCODE_SNAP_ORIG": "/home/ryan/snap/code/common/.cache/immodules/immodules.cache",
  "GTK_MODULES": "gail:atk-bridge",
  "GTK_PATH": "/snap/code/151/usr/lib/x86_64-linux-gnu/gtk-3.0:/snap/code/151/usr/lib/x86_64-linux-gnu/gtk-3.0",
  "GTK_PATH_VSCODE_SNAP_ORIG": "/snap/code/151/usr/lib/x86_64-linux-gnu/gtk-3.0",
  "GZ_SIM_RESOURCE_PATH": "/home/ryan/Dev/ros2_ws/src/ardupilot_gazebo/models:/home/ryan/Dev/ros2_ws/src/ardupilot_gazebo/worlds:/home/ryan/Dev/ros2_ws/src/ardupilot_gazebo/models:/home/ryan/Dev/ros2_ws/src/ardupilot_gazebo/worlds:",
  "GZ_SIM_SYSTEM_PLUGIN_PATH": "/home/ryan/Dev/ros2_ws/src/ardupilot_gazebo/build:/home/ryan/Dev/ros2_ws/src/ardupilot_gazebo/build:",
  "GZ_VERSION": "harmonic",
  "HOME": "/home/ryan",
  "IM_CONFIG_PHASE": "1",
  "LANG": "en_US.UTF-8",
  "LC_ALL": "en_US.UTF-8",
  "LD_LIBRARY_PATH": "/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_utils/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/dwb_msgs/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_msgs/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_costmap_2d/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_voxel_grid/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_map_server/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_lifecycle_manager/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_util/lib:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_msgs/lib:/opt/ros/rolling/opt/rviz_ogre_vendor/lib:/opt/ros/rolling/lib/x86_64-linux-gnu:/opt/ros/rolling/lib",
  "LESSCLOSE": "/usr/bin/lesspipe %s %s",
  "LESSOPEN": "| /usr/bin/lesspipe %s",
  "LIBVIRT_DEFAULT_URI": "qemu:///system",
  "LOCPATH": "/snap/code/151/usr/lib/locale:/snap/code/151/usr/lib/locale",
  "LOCPATH_VSCODE_SNAP_ORIG": "/snap/code/151/usr/lib/locale",
  "LOGNAME": "ryan",
  "LS_COLORS": "rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:",
  "NO_AT_BRIDGE": "1",
  "ORIGINAL_XDG_CURRENT_DESKTOP": "Unity",
  "PATH": "/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_costmap_2d/bin:/opt/ros/rolling/bin:/home/ryan/.pyenv/versions/3.12.0/bin:/opt/gcc-arm-none-eabi-9-2020-q2-update/bin:/home/ryan/.cargo/bin:/usr/lib/ccache:/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/home/ryan/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/home/ryan/.local/bin:/home/ryan/.local/bin:/home/ryan/Dev/ros2_ws/src/Micro-XRCE-DDS-Gen/scripts:/home/ryan/.local/bin:/home/ryan/Dev/ros2_ws/src/Micro-XRCE-DDS-Gen/scripts",
  "PWD": "/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue",
  "PYTHONPATH": "/home/ryan/Dev/nav2_ws/src/navigation2/install/dwb_msgs/lib/python3.10/site-packages:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav_2d_msgs/lib/python3.10/site-packages:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_msgs/lib/python3.10/site-packages:/home/ryan/Dev/nav2_ws/src/navigation2/install/nav2_common/lib/python3.10/site-packages:/opt/ros/rolling/lib/python3.10/site-packages",
  "QT_ACCESSIBILITY": "1",
  "QT_IM_MODULE": "ibus",
  "ROS_AUTOMATIC_DISCOVERY_RANGE": "SUBNET",
  "ROS_DISTRO": "rolling",
  "ROS_PYTHON_VERSION": "3",
  "ROS_VERSION": "2",
  "SESSION_MANAGER": "local/B650-970:@/tmp/.ICE-unix/3293,unix/B650-970:/tmp/.ICE-unix/3293",
  "SHELL": "/bin/bash",
  "SHLVL": "2",
  "SNAP": "/snap/code/151",
  "SNAP_ARCH": "amd64",
  "SNAP_COMMON": "/var/snap/code/common",
  "SNAP_CONTEXT": "XGrSqCT9Myk0pgNIHH_1-Hg53xTWScG8QxV-3-WezeZxvkvJs4bG",
  "SNAP_COOKIE": "XGrSqCT9Myk0pgNIHH_1-Hg53xTWScG8QxV-3-WezeZxvkvJs4bG",
  "SNAP_DATA": "/var/snap/code/151",
  "SNAP_EUID": "1000",
  "SNAP_INSTANCE_NAME": "code",
  "SNAP_LAUNCHER_ARCH_TRIPLET": "x86_64-linux-gnu",
  "SNAP_LIBRARY_PATH": "/var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void",
  "SNAP_NAME": "code",
  "SNAP_REAL_HOME": "/home/ryan",
  "SNAP_REVISION": "151",
  "SNAP_UID": "1000",
  "SNAP_USER_COMMON": "/home/ryan/snap/code/common",
  "SNAP_USER_DATA": "/home/ryan/snap/code/151",
  "SNAP_VERSION": "31c37ee8",
  "SSH_AGENT_LAUNCHER": "gnome-keyring",
  "SSH_AGENT_PID": "7999",
  "SSH_AUTH_SOCK": "/tmp/ssh-XXXXXXCb47BU/agent.7997",
  "SYSTEMD_EXEC_PID": "3510",
  "TERM": "xterm-256color",
  "TERM_PROGRAM": "vscode",
  "TERM_PROGRAM_VERSION": "1.86.1",
  "USER": "ryan",
  "USERNAME": "ryan",
  "VSCODE_AMD_ENTRYPOINT": "vs/workbench/api/node/extensionHostProcess",
  "VSCODE_CLI": "1",
  "VSCODE_CODE_CACHE_PATH": "/home/ryan/.config/Code/CachedData/31c37ee8f63491495ac49e43b8544550fbae4533",
  "VSCODE_CRASH_REPORTER_PROCESS_TYPE": "extensionHost",
  "VSCODE_CWD": "/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue",
  "VSCODE_GIT_ASKPASS_MAIN": "/snap/code/151/usr/share/code/resources/app/extensions/git/dist/askpass-main.js",
  "VSCODE_GIT_ASKPASS_NODE": "/snap/code/151/usr/share/code/code",
  "VSCODE_GIT_IPC_HANDLE": "/run/user/1000/vscode-git-9afd8ac4a1.sock",
  "VSCODE_HANDLES_UNCAUGHT_ERRORS": "true",
  "VSCODE_IPC_HOOK": "/run/user/1000/vscode-01d69257-1.86-main.sock",
  "VSCODE_NLS_CONFIG": "{\"locale\":\"en-us\",\"osLocale\":\"en-us\",\"availableLanguages\":{},\"_languagePackSupport\":true}",
  "VSCODE_PID": "8088",
  "VTE_VERSION": "6800",
  "WINDOWPATH": "2",
  "XAUTHORITY": "/run/user/1000/gdm/Xauthority",
  "XDG_CONFIG_DIRS": "/etc/xdg/xdg-ubuntu:/etc/xdg",
  "XDG_CONFIG_DIRS_VSCODE_SNAP_ORIG": "/etc/xdg/xdg-ubuntu:/etc/xdg",
  "XDG_CURRENT_DESKTOP": "Unity",
  "XDG_DATA_DIRS": "/home/ryan/snap/code/151/.local/share:/home/ryan/snap/code/151:/snap/code/151/usr/share:/home/ryan/snap/code/151/.local/share:/home/ryan/snap/code/151:/snap/code/151/usr/share:/usr/share/ubuntu:/usr/share/gnome:/home/ryan/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop",
  "XDG_DATA_DIRS_VSCODE_SNAP_ORIG": "/home/ryan/snap/code/151/.local/share:/home/ryan/snap/code/151:/snap/code/151/usr/share:/usr/share/ubuntu:/usr/share/gnome:/home/ryan/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop",
  "XDG_MENU_PREFIX": "gnome-",
  "XDG_RUNTIME_DIR": "/run/user/1000",
  "XDG_SESSION_CLASS": "user",
  "XDG_SESSION_DESKTOP": "ubuntu",
  "XDG_SESSION_TYPE": "x11",
  "XMODIFIERS": "@im=ibus",
  "ELECTRON_RUN_AS_NODE": "1",
  "APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL": "1",
  "VSCODE_L10N_BUNDLE_LOCATION": ""
}
[driver] Trying to detect generator supported by system
[extension] [1950] cmake.cleanConfigureWithDebugger finished (returned 1)
[cache] Reading CMake cache file /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build/CMakeCache.txt
[cache] Parsing CMake cache string
[cache] Reading CMake cache file /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build/CMakeCache.txt
[cache] Parsing CMake cache string
[cmakefileapi-parser] Read reply folder: /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build/.cmake/api/v1/reply
[driver] Setting new variant Debug
[cache] Reading CMake cache file /home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build/CMakeCache.txt
[cache] Parsing CMake cache string
[debugger] Connecting debugger on named pipe: "/tmp/cmake-debugger-pipe-c0578185-d439-4e51-8809-fea162457d57"

Additional Information
I run into this error when doing build system work and using the debugger frequently. Perhaps it's caused by trying to configure twice in two different places? There are no pipes for the CMake debugger to connect to - seems to be waiting for a pipe that doesn't exist.
ryan@B650-970:~/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue$ ls /tmp/cmake*
ls: cannot access '/tmp/cmake*': No such file or directory

I can also see a hung process that remains after VSCode is closed:
COMMAND
/usr/bin/cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/lib/ccache/gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/lib/ccache/g++ -S/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue -B/home/ryan/Dev/nav2_ws/src/navigation2/nav2_dwb_controller/costmap_queue/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-d1860702-3043-4d1b-b090-331649df175a

I met this problem too.

@QiuYilin Thank you for your GitHub issues! We are currently trying to reproduce your problem, could you provide a minimal reproduction project and specific reproduction steps so we can investigate further？

@Ryanf55 Is your problem currently recurring? We are currently trying to reproduce your problem, could you provide a minimal reproduction project and specific reproduction steps so we can investigate further？

@Ryanf55 Is your problem currently recurring? We are currently trying to reproduce your problem, could you provide a minimal reproduction project and specific reproduction steps so we can investigate further？

Yep! I just tried the debugger on a current project. I can reproduce it by:

Creating a CMakeLists file that has a problem during the configure phase
Use the VSCOde CMake: Configure with CMake Debugger
The debugger will halt on the line
Hit the restart arrow on the debugger to try again
You will get a connect ENOENT error as posed above

If I get some time, I can try to create a minimum reproducible example.
Version: 1.89.1 (user setup)
Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
Date: 2024-05-07T05:13:33.891Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Windows_NT x64 10.0.19045

@Ryanf55 @gcampbell-msft We can reproduce this issue on latest version, you can get the details below.
ENV:
VSCode: 1.89.1
CMake tools: v1.19.0(pre-release)
C/C++: v1.20.5
Repro steps:

Open this project Test.zip with VSCode
Click F1 to run "CMake: configure" command
Open CMakeLists.txt file and set a breakpoint in it
Click F1 to run "CMake: Configure with CMake Debugger" command
Re-run "CMake: Configure with CMake Debugger" command

Expected result:
It should debug successfully
Actual result:
The debug failed.
Output window:
main] Configuring project: Test
[proc] Executing command: /usr/local/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ --no-warn-unused-cli -S/Users/beyondtest/Desktop/Test -B/Users/beyondtest/Desktop/Test/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1
[cmake] Not searching for unused variables given on the command line.
[cmake] Running with debugger on.
[cmake] Waiting for debugger client to connect...
[debugger] Connecting debugger on named pipe: "/tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1"
[cmake] Debugger client connected.
[cmake] CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
[cmake]   cmake_minimum_required called with unknown argument "version".
[cmake]
[cmake]
[cmake] CMake Warning (dev) at CMakeLists.txt:2 (project):
[cmake]   cmake_minimum_required() should be called prior to this top-level project()
[cmake]   call.  Please see the cmake-commands(7) manual for usage documentation of
[cmake]   both commands.
[cmake] This warning is for project developers.  Use -Wno-dev to suppress it.
[cmake]
[proc] The command: pgrep -P 33473 exited with code: 1
[proc] The command: /usr/local/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ --no-warn-unused-cli -S/Users/beyondtest/Desktop/Test -B/Users/beyondtest/Desktop/Test/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1 exited with code: null and signal: SIGINT
[debugger] Connecting debugger on named pipe: "/tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1"

https://github.com/microsoft/vscode-cmake-tools/assets/101234795/26d51ee5-64cc-4fe0-bd0b-b74b33074b1f

@Ryanf55 @gcampbell-msft We can reproduce this issue on latest version, you can get the details below.
ENV: VSCode: 1.89.1 CMake tools: v1.19.0(pre-release) C/C++: v1.20.5
Repro steps:

Open this project Test.zip with VSCode
Click F1 to run "CMake: configure" command
Open CMakeLists.txt file and set a breakpoint in it
Click F1 to run "CMake: Configure with CMake Debugger" command
Re-run "CMake: Configure with CMake Debugger" command

Expected result: It should debug successfully
Actual result: The debug failed.
Output window:
main] Configuring project: Test
[proc] Executing command: /usr/local/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ --no-warn-unused-cli -S/Users/beyondtest/Desktop/Test -B/Users/beyondtest/Desktop/Test/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1
[cmake] Not searching for unused variables given on the command line.
[cmake] Running with debugger on.
[cmake] Waiting for debugger client to connect...
[debugger] Connecting debugger on named pipe: "/tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1"
[cmake] Debugger client connected.
[cmake] CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
[cmake]   cmake_minimum_required called with unknown argument "version".
[cmake]
[cmake]
[cmake] CMake Warning (dev) at CMakeLists.txt:2 (project):
[cmake]   cmake_minimum_required() should be called prior to this top-level project()
[cmake]   call.  Please see the cmake-commands(7) manual for usage documentation of
[cmake]   both commands.
[cmake] This warning is for project developers.  Use -Wno-dev to suppress it.
[cmake]
[proc] The command: pgrep -P 33473 exited with code: 1
[proc] The command: /usr/local/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ --no-warn-unused-cli -S/Users/beyondtest/Desktop/Test -B/Users/beyondtest/Desktop/Test/build -G Ninja --debugger --debugger-pipe /tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1 exited with code: null and signal: SIGINT
[debugger] Connecting debugger on named pipe: "/tmp/cmake-debugger-pipe-b6afcaa0-c6f1-460a-a1a3-dd1e94b7fbf1"

Screen.Recording.2024-05-31.at.10.15.28.AM.mov

Yep, that's exactly it. Good documentation and video. Hopefully this helps the team trace down a fix!

@Ryanf55 @gcampbell-msft @qarni This issue has been fixed on latest pre-release version v1.19.17, you can get the details below. Thank you!


Consistent member.joined events

Description
In the CF nested calls the backend won't send member.joined for all members.
The list of all members is a combination of emitted member.joined and existing members in call.joined.
To abstract for the final developers, this will  internally emit member.joined events for all existing members in a call.joined event.
PS: This PR is not considering member.left events
Type of change

[x] Internal refactoring
[ ] Bug fix (bugfix - non-breaking)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Code snippets
In case of new feature or breaking changes, please include code snippets.

I am not sure why we need to emit member.joined when we receive the call.joined. In what scenario this might be required considering both of these events have a different meaning?

I am not sure why we need to emit member.joined when we receive the call.joined. In what scenario this might be required considering both of these events have a different meaning?

We need this for a few reasons ATM, but I agree with your point of being distinct events (maybe you have another approach)
Here is why:
1 - CF calls are possibly nested resulting in more than one call.joined event currently mapped to video.room.subscribed
2 - The "subscriberWorker" runs only once per "dial/answer" resulting in a single room.joined (IMO this makes sense and should continue to be the case)
3 - the client doesn't receive member.joined events for existing members previously sent on the call.joined payload.
4 - without emitting new room.joined(with new members) or emitting  member.joined for all members in all nested calls, the client will be missing members.
We could emit other room.joined events but IMO that makes it harder for the application to maintain the member list. On the other hand, if we send member.joined for all member, including the existing ones in the call.joined the application just needs can easily maintain the member list.

@andremartinssw I was discussing this with @iAmmar7 and he made a good point.
Depending on the point of view maybe a memberList.updated is enough and we don't need the to force emit  member.joined events.
What do you think?


Open questions regarding retargeting

I think there may be a misunderstanding to what animation retargeting means in practice: it does not mean applying the same transformations to another node hierarchy. It means applying the same normalized motion to another rig specifying motion ranges.
Recommend reading about Unity's Avatar definitions for humanoid characters, how they're set up, what they store, and how retargeting works there!
I understand for a "simple" extension the goal may be to not allow actual retargeting but just allow applying the same transformations to another hierarchy, but then it should be explicit.

Thanks for the comment.
OK, the term "retargeting" doesn't sound like applying the same animation to models that have the same or similar structured skeleton in general.
Perhaps I should have used "remap" or anything else. Actual "retargeting" is out of scope. I will update to clarify.

Just as an example, here's Unity's Avatar setup window, where one basically defines the range of motion for a character, which is the base for retargeting humanoid animations to it:

Humanoid clips in Unity then animate in that motion range, so it can be retargeted. I don't think it's hugely more complicated to store avatar definitions and avatar animation clips separately (and we plan to do that for Needle Engine in the future), would be great to align on a format for that.

What is the motion range exactly and how does it work?

Even just applying the transforms from a source skeleton to a target skeleton relative to a known rest pose constitutes retargeting, albeit the most basic form. So I don't think it's necessarily wrong to use that term in this context, though I do agree it should be clear what is and isn't covered/supported by this extension.
The tricky thing with retargetting is that there are many ways to fix up the resulting animation. Limiting joint rotations to avoid self-collision is also only part of the whole solution. To have proper contact points with props or the ground you often see a form of IK being used as well.
I don't know how these motion ranges are used in Unity exactly, but I imagine that limiting joint movement is useful even outside of animation retargeting (e.g. procedural animations, IK, rag doll physics). So I think it's worth considering to keep the scope of this extension to describing the humanoid skeleton and make the actual retarget logic non-normative. Any joint constraints can then be defined using a separate extension, which doesn't have to be limited to humanoid skeleton/joints.

Any joint constraints can then be defined using a separate extension

Yes, this is my first option in my mind.

I don't quite agree here; if you have a character with low arm range, you want to see the normalized motion on it, not some full motion but then clamped to the range of that character, two very different results.
Regarding IK, indeed Unity allows adding IK on top of humanoid rigs for more directly specifying hand and feet positions; this could certainly be a separate extension.

I might be missing something, but it feels highly dependant on the animation whether normalized motion makes sense. Clipping the motion looks quite bad, so I can see how normalized motion would yield better looking results. But wouldn't it mess with many movements incorrectly? For example, applying an animation of a character looking perfectly left, when applied to an "owl-like" character with a larger neck motion range, would be looking over its shoulder. Or an animation on a character that can't cross his arms in front of him. Pointing straight forward would be the maximum motion, so when applied to other characters, they would cross their arms.
That being said, an extension for motion range based retargetting that works hand-in-hand with this extension sounds like the best of both worlds. There are many animation sources where motion range information of the source skeleton is simply not present (e.g. Mixamo, motion capture), so I don't think it would be wise to require it for this extension.


Migrations

I also updated our deps beforehand to make sure we have the newest model definitions.

Coverage: 87.382% (+0.01%) from 87.368% when pulling 82b80b45d0584ffade6062c04bef3175f2c0db47 on migrations into 5aa1b9100d9dbc9c88f08124e3b35c0ad74458d2 on main.


Tests: Add vmi options for virtiofs

What this PR does / why we need it:
This PR is adding libvmi.Option for virtiofs.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
NONE

/retest

@maiqueb PTAL

/approve

@xpivarc do you still want this to go in?

@xpivarc do you still want this to go in?

I will definitely revisit this.

Already done


Fixed installation path issue

On Windows, if there is a space in folder name in installatin path, GUI fails to launch daemon child process.
This PR double-quotes the path to daemon to prevent this issue.
Confirmed to work on Windows 10, M1 MacOS.
This fixes this issue https://github.com/Chia-Network/chia-blockchain/issues/17579

@zsolt-dev I changed the baes branch to main since Keep services running background... feature was removed from 2.2.0. Please review this again!


Kubeadm config reference

This PR fixes some type errors found recently.

/sig cluster-lifecycle
some similar comments as https://github.com/kubernetes/website/pull/29094

Page previews:
https://deploy-preview-29095--kubernetes-io-vnext-staging.netlify.app/docs/reference/config-api/kubeadm-config.v1beta3/
https://deploy-preview-29095--kubernetes-io-vnext-staging.netlify.app/docs/reference/config-api/kubeadm-config.v1beta2/

nit: It would be great to review the Markdown code formatting.
The descriptions contain a number of back quotes, for example,
`useHyperKubeImage`

/lgtm
Feel free to remove hold
/hold

This PR is retargeted at fixing the pointer to k8s internal data types and adding BootstrapToken struct which was added in v1beta3 as an API in a separate package.

/assign

/lgtm

since this has been approved and lgtmed a bunch of times, i'll go ahead and merge it
/hold cancel


Serialization error when adding Redshift datasource

What happened:
I am trying to add a Redshift cluster as a datasource to my local Grafana installation. When I enter all the configuration details and click on 'Save and Test', the following error is returned:
error executing query: SerializationError: failed decoding JSON RPC response status code: 200, request id: caused by: invalid character '<' looking for beginning of value
I have tried it with all three available authentication options, with the same outcome.
What you expected to happen:
The datasource should be added correctly if the config is correct. Otherwise, the error should be clear if it is a config issue.
Environment:

Grafana version: v8.3.5
Plugin version: v1.0.2
OS Grafana is installed on: macOS BigSur v11.6
User OS & Browser: OS: macOS BigSur v11.6, Browser: Chrome Version 98.0.4758.80
Others: aws-cli/2.4.17 Python/3.8.8 Darwin/20.6.0 exe/x86_64 prompt/off

hi @aachenmax, it seems that you are getting an error but that is not properly parsed. Are you able to see any other error message either in the browser console or in the Grafana logs?

Hi @andresmgot, thanks a lot for you help. The only thing i can see in the grafana.log is the following:
t=2022-02-10T13:58:33+0100 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/live/ws status=0 remote_addr=[::1] time_ms=3 size=0 referer=
t=2022-02-10T13:58:48+0100 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/datasources/2/health status=400 remote_addr=[::1] time_ms=2737 size=211 referer=http://localhost:3000/datasources/edit/E6wU6J-nk

I can also see the following in the Browser console:

Thanks for the info @aachenmax. It seems that that does not show the root of the cause either. To try to reproduce the issue, what parameters are you using to configure Redshift? (without including sensitive information)

Hi @aachenmax ! Are you still having this issue? If so, what redshift config parameters are you using (without sensitive information)?

We've closed this issue since it needs more information and hasn't had any activity recently. We can re-open it after you you add more information. To avoid having your issue closed in the future, please read our CONTRIBUTING guidelines.
Happy graphing!


Update fs2-core, fs2-io to 3.3.0

Updates

co.fs2:fs2-core
co.fs2:fs2-io

from 3.2.14 to 3.3.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "co.fs2" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "co.fs2" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Codecov Report

Merging #670 (a2184df) into master (e21ed57) will decrease coverage by 0.08%.
The diff coverage is n/a.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


how to fetch the user info ?

As the title,  I want to fetch some user info in node runtime for some validate.  I see the result of npm config list -l , there is null of user info also ,  is there some thing wrong ? thanks.

use userconfig path and ini  to deal with it


W-14658882-reassignexistinguserassets-se

Added option to reassign RPA assets of existing users

Dear SME, please review for completeness and correctness. Thank you.


Camera Follow Pos?

Describe your problem here.
How does this even work? any x and y number I put it literally strafes to the left
idk of that event is useless without source or what because I'm confused
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No

try doing 3 digit numbers
750 x
350 y
That was just an example

i dont think you want to add the x and y to the value. just the number


Update install-agent.sh script to support Alpine (OpenRC)

Thanks, can I close #319 in favor of this one?
I want to test before merging and may not have time to do that until later in the week, after the next release.

Thanks, can I close #319 in favor of this one?
I want to test before merging and may not have time to do that until later in the week, after the next release.

Sure

Merged :+1:
Sorry for the delay. Thanks again for your work on this!


Made the Text property in the lines collections write-able.

I know people can just do it manually.. But why not just implement it ?
At-least people who are converting from old ScintillaNET won't create issues about it.

Sorry, but I'm not going to merge this. See the explanation in Issue #57.
Your code attempts to handle situations where the text contains line breaks, but I can think of several more instances of where it would fail. What about Unicode line breaks? What if this is the last line in the document and doesn't have/need a line break? etc...
The point is Scintilla is a text editor, not a line editor. I rewrote v2 because I wanted v3 to remain true to the native Scintilla component. I understand that some people will disagree with me on this, but that's my opinion.
Now, that's not the end of the story. One of the reasons I like hosting at GitHub is because it makes it very easy for you to maintain your own branch of ScintillaNET for doing things like this. By all means, continue to use that code in your branch. :)


[Issue] Docker buildargs does not support interpolation

[ X ] Make sure you've installed the latest version using instructions in the wiki

Describe the bug
If you have a Static App (like React) and a backend api in ACA, it would be nice if we could take the output of the infra deployment (the url) and pass it as buildArgs in the dockerfile:
For example:
# main.biceps
...
output REACT_APP_BACKEND_URL string = backend.outputs.uri

# azure.yaml - Notice the environment variables!
...
    frontend:
        project: "src/frontend"
        host: containerapp
        language: ts
        dist: build
        docker:
            path: Dockerfile
            buildArgs:
                - REACT_APP_BACKEND_URL=${REACT_APP_BACKEND_URL}

# deploy infra and populate outputs as environment variables
azd provision --environment dev
# utilize environment variables to interpolate the azure.yaml
azd deploy

@vhvb1989 This should work right?

@vhvb1989 This should work right?

No. build-args don't support references to env values.  This is a feature request (which is not that hard).  The only thing to consider is security, as you will want to use --secret instead of --build-arg when referencing a secret from the system environment.

@wbreza FYI


Translate 'map' link.

Coverage remained the same at 61.712% when pulling 123c8abff4446dad8b702f127cc4186a69ef1042 on vnikme:vnik/map into ba6a051b8f78a7ced81e331dbdfec229deb2352c on codecombat:master.

Hi mates!
Could you please tell me if I did this correct? I don't know the best practice on how to open PR, how to invite reviewers and so on.
Thanks in advance.
Vadim.

Thanks. merged.


[SPARK-35351][SQL] Add code-gen for left anti sort merge join

What changes were proposed in this pull request?

As title. This PR is to add code-gen support for LEFT ANTI sort merge join. The main change is to extract loadStreamed in SortMergeJoinExec.doProduce(). That is to set all columns values for streamed row, when the streamed row has no output row.
Example query:
val df1 = spark.range(10).select($"id".as("k1"))
val df2 = spark.range(4).select($"id".as("k2"))
df1.join(df2.hint("SHUFFLE_MERGE"), $"k1" === $"k2", "left_anti")

Example generated code:
== Subtree 5 / 5 (maxMethodCodeSize:296; maxConstantPoolSize:156(0.24% used); numInnerClasses:0) ==
*(5) Project [id#0L AS k1#2L]
+- *(5) SortMergeJoin [id#0L], [k2#6L], LeftAnti
   :- *(2) Sort [id#0L ASC NULLS FIRST], false, 0
   :  +- Exchange hashpartitioning(id#0L, 5), ENSURE_REQUIREMENTS, [id=#27]
   :     +- *(1) Range (0, 10, step=1, splits=2)
   +- *(4) Sort [k2#6L ASC NULLS FIRST], false, 0
      +- Exchange hashpartitioning(k2#6L, 5), ENSURE_REQUIREMENTS, [id=#33]
         +- *(3) Project [id#4L AS k2#6L]
            +- *(3) Range (0, 4, step=1, splits=2)

Generated code:
/* 001 */ public Object generate(Object[] references) {
/* 002 */   return new GeneratedIteratorForCodegenStage5(references);
/* 003 */ }
/* 004 */
/* 005 */ // codegenStageId=5
/* 006 */ final class GeneratedIteratorForCodegenStage5 extends org.apache.spark.sql.execution.BufferedRowIterator {
/* 007 */   private Object[] references;
/* 008 */   private scala.collection.Iterator[] inputs;
/* 009 */   private scala.collection.Iterator smj_streamedInput_0;
/* 010 */   private scala.collection.Iterator smj_bufferedInput_0;
/* 011 */   private InternalRow smj_streamedRow_0;
/* 012 */   private InternalRow smj_bufferedRow_0;
/* 013 */   private long smj_value_2;
/* 014 */   private org.apache.spark.sql.execution.ExternalAppendOnlyUnsafeRowArray smj_matches_0;
/* 015 */   private long smj_value_3;
/* 016 */   private org.apache.spark.sql.catalyst.expressions.codegen.UnsafeRowWriter[] smj_mutableStateArray_0 = new org.apache.spark.sql.catalyst.expressions.codegen.UnsafeRowWriter[2];
/* 017 */
/* 018 */   public GeneratedIteratorForCodegenStage5(Object[] references) {
/* 019 */     this.references = references;
/* 020 */   }
/* 021 */
/* 022 */   public void init(int index, scala.collection.Iterator[] inputs) {
/* 023 */     partitionIndex = index;
/* 024 */     this.inputs = inputs;
/* 025 */     smj_streamedInput_0 = inputs[0];
/* 026 */     smj_bufferedInput_0 = inputs[1];
/* 027 */
/* 028 */     smj_matches_0 = new org.apache.spark.sql.execution.ExternalAppendOnlyUnsafeRowArray(1,<PHONE_NUMBER>);
/* 029 */     smj_mutableStateArray_0[0] = new org.apache.spark.sql.catalyst.expressions.codegen.UnsafeRowWriter(1, 0);
/* 030 */     smj_mutableStateArray_0[1] = new org.apache.spark.sql.catalyst.expressions.codegen.UnsafeRowWriter(1, 0);
/* 031 */
/* 032 */   }
/* 033 */
/* 034 */   private boolean findNextJoinRows(
/* 035 */     scala.collection.Iterator streamedIter,
/* 036 */     scala.collection.Iterator bufferedIter) {
/* 037 */     smj_streamedRow_0 = null;
/* 038 */     int comp = 0;
/* 039 */     while (smj_streamedRow_0 == null) {
/* 040 */       if (!streamedIter.hasNext()) return false;
/* 041 */       smj_streamedRow_0 = (InternalRow) streamedIter.next();
/* 042 */       long smj_value_0 = smj_streamedRow_0.getLong(0);
/* 043 */       if (false) {
/* 044 */         if (!smj_matches_0.isEmpty()) {
/* 045 */           smj_matches_0.clear();
/* 046 */         }
/* 047 */         return false;
/* 048 */
/* 049 */       }
/* 050 */       if (!smj_matches_0.isEmpty()) {
/* 051 */         comp = 0;
/* 052 */         if (comp == 0) {
/* 053 */           comp = (smj_value_0 > smj_value_3 ? 1 : smj_value_0 < smj_value_3 ? -1 : 0);
/* 054 */         }
/* 055 */
/* 056 */         if (comp == 0) {
/* 057 */           return true;
/* 058 */         }
/* 059 */         smj_matches_0.clear();
/* 060 */       }
/* 061 */
/* 062 */       do {
/* 063 */         if (smj_bufferedRow_0 == null) {
/* 064 */           if (!bufferedIter.hasNext()) {
/* 065 */             smj_value_3 = smj_value_0;
/* 066 */             return !smj_matches_0.isEmpty();
/* 067 */           }
/* 068 */           smj_bufferedRow_0 = (InternalRow) bufferedIter.next();
/* 069 */           long smj_value_1 = smj_bufferedRow_0.getLong(0);
/* 070 */           if (false) {
/* 071 */             smj_bufferedRow_0 = null;
/* 072 */             continue;
/* 073 */           }
/* 074 */           smj_value_2 = smj_value_1;
/* 075 */         }
/* 076 */
/* 077 */         comp = 0;
/* 078 */         if (comp == 0) {
/* 079 */           comp = (smj_value_0 > smj_value_2 ? 1 : smj_value_0 < smj_value_2 ? -1 : 0);
/* 080 */         }
/* 081 */
/* 082 */         if (comp > 0) {
/* 083 */           smj_bufferedRow_0 = null;
/* 084 */         } else if (comp < 0) {
/* 085 */           if (!smj_matches_0.isEmpty()) {
/* 086 */             smj_value_3 = smj_value_0;
/* 087 */             return true;
/* 088 */           } else {
/* 089 */             return false;
/* 090 */           }
/* 091 */         } else {
/* 092 */           if (smj_matches_0.isEmpty()) {
/* 093 */             smj_matches_0.add((UnsafeRow) smj_bufferedRow_0);
/* 094 */           }
/* 095 */
/* 096 */           smj_bufferedRow_0 = null;
/* 097 */         }
/* 098 */       } while (smj_streamedRow_0 != null);
/* 099 */     }
/* 100 */     return false; // unreachable
/* 101 */   }
/* 102 */
/* 103 */   protected void processNext() throws java.io.IOException {
/* 104 */     while (smj_streamedInput_0.hasNext()) {
/* 105 */       findNextJoinRows(smj_streamedInput_0, smj_bufferedInput_0);
/* 106 */
/* 107 */       long smj_value_4 = -1L;
/* 108 */       smj_value_4 = smj_streamedRow_0.getLong(0);
/* 109 */       scala.collection.Iterator<UnsafeRow> smj_iterator_0 = smj_matches_0.generateIterator();
/* 110 */
/* 111 */       boolean wholestagecodegen_hasOutputRow_0 = false;
/* 112 */
/* 113 */       while (!wholestagecodegen_hasOutputRow_0 && smj_iterator_0.hasNext()) {
/* 114 */         InternalRow smj_bufferedRow_1 = (InternalRow) smj_iterator_0.next();
/* 115 */
/* 116 */         wholestagecodegen_hasOutputRow_0 = true;
/* 117 */       }
/* 118 */
/* 119 */       if (!wholestagecodegen_hasOutputRow_0) {
/* 120 */         // load all values of streamed row, because the values not in join condition are not
/* 121 */         // loaded yet.
/* 122 */
/* 123 */         ((org.apache.spark.sql.execution.metric.SQLMetric) references[0] /* numOutputRows */).add(1);
/* 124 */
/* 125 */         // common sub-expressions
/* 126 */
/* 127 */         smj_mutableStateArray_0[1].reset();
/* 128 */
/* 129 */         smj_mutableStateArray_0[1].write(0, smj_value_4);
/* 130 */         append((smj_mutableStateArray_0[1].getRow()).copy());
/* 131 */
/* 132 */       }
/* 133 */       if (shouldStop()) return;
/* 134 */     }
/* 135 */     ((org.apache.spark.sql.execution.joins.SortMergeJoinExec) references[1] /* plan */).cleanupResources();
/* 136 */   }
/* 137 */
/* 138 */ }

Why are the changes needed?

Improve the query CPU performance.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Added unit test in WholeStageCodegenSuite.scala, and existed unit test in ExistenceJoinSuite.scala.

cc @cloud-fan and @maropu to take a look when you have time, thanks.

Test build #138547 has started for PR 32547 at commit 53364c9.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43066/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43066/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43066/

Test build #138547 has finished for PR 32547 at commit 53364c9.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138547/

Test build #138554 has started for PR 32547 at commit 06eae6e.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43075/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43075/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43075/

Test build #138554 has finished for PR 32547 at commit 06eae6e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138554/

retest this please

Test build #138566 has started for PR 32547 at commit 06eae6e.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43087/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43087/

Test build #138566 has finished for PR 32547 at commit 06eae6e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138566/

Test build #138646 has started for PR 32547 at commit df70b01.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43166/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43166/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43166/

Test build #138646 has finished for PR 32547 at commit df70b01.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138646/

Thank you, @c21 ~ Merged to master.

Thank you @maropu and @cloud-fan for review!


[s3sync] ModuleNotFoundError: No module named 'six'

docker run -e AWS_ACCESS_KEY_ID=OUR_ACCESS_KEY -e AWS_SECRET_ACCESS_KEY=OUR_SECRET_KEY -e AWS_DEFAULT_REGION=us-west-1 -e S3PATH=s3://OUR_BUCKET/d0 vladgh/s3sync
[2020-07-24T06:07:06+0000 - 1daf22172bb9] Sync 's3://OUR_BUCKET/d0' to '/sync'
Traceback (most recent call last):
  File "/usr/bin/aws", line 19, in <module>
    import awscli.clidriver
  File "/usr/lib/python3.8/site-packages/awscli/clidriver.py", line 17, in <module>
    import botocore.session
  File "/usr/lib/python3.8/site-packages/botocore/session.py", line 28, in <module>
    import botocore.configloader
  File "/usr/lib/python3.8/site-packages/botocore/configloader.py", line 19, in <module>
    from botocore.compat import six
  File "/usr/lib/python3.8/site-packages/botocore/compat.py", line 26, in <module>
    from dateutil.tz import tzlocal
  File "/usr/lib/python3.8/site-packages/dateutil/tz/__init__.py", line 2, in <module>
    from .tz import *
  File "/usr/lib/python3.8/site-packages/dateutil/tz/tz.py", line 19, in <module>
    import six
ModuleNotFoundError: No module named 'six'

aws-cli is available in the alpine repo now.
Fixed by adding aws-cli:
RUN apk --no-cache add aws-cli bash findutils groff less python3 tini inotify-tools
was able to remove the "Install AWS CLI" section

Thanks, I will update the docker image to use the packaged version of aws cli.

Tested and confirmed working. Thank you!


[test/service] Set available port number for service API unittest

Set available port number for service API unittest, rather than
default value

Signed-off-by: Yongjoo Ahn<EMAIL_ADDRESS>Self evaluation:

Build test: [X]Passed [ ]Failed [ ]Skipped
Run test: [X]Passed [ ]Failed [ ]Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #197. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.


[4.0-07-11-2017][interface-gen] Update interface gen for header files to accept Swift compiler args

Explanation: Swift interface generation for an ObjC header file currently accepts the Clang compiler arguments from an associated compilation, and then derives (somewhat inaccurately) Swift compiler arguments to use. We now track header dependencies via the bridging header, however, so have actual Swift compiler arguments to supply. This PR updates interface generation to support taking Swift compiler arguments directly.
Scope of Issue: This is limited to Interface Generation for header files.
Risk: Low. An additional parameter must be in the request to see the new behaviour.
Reviewed By: Argyrios Kyrtzidis
Testing: Added regression test
Radar: rdar://problem/33249361

PR for master: https://github.com/apple/swift/pull/10945

@swift-ci test

@swift-ci test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 9828081a3e75ea263f0566a71031f0b38a2a0fc6
Test requested by - @nathawes

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 9828081a3e75ea263f0566a71031f0b38a2a0fc6
Test requested by - @nathawes