text:
Updates the permissions block to be minimal

And adds a permissions block to the README.
Fixes #464.
Merge / deployment checklist

[x] Confirm this change is backwards compatible with existing workflows.
[x] Confirm the readme has been updated if necessary.
[x] Confirm the changelog has been updated if necessary.

From our last internal discussion about this, I believe that actions: read is (only) needed if you are analyzing a private repository, and security-events: write is (only) needed if you are not analyzing a pull request. And I think we need at least contents: read (or pull-requests: read for PRs). The overlapping scopes for PRs make this a bit confusing.
So perhaps let's go with the recommendation of actions: read, contents: read, security-events: write? If it turns out that's not entirely minimal, we can refine it again later.

Sure, and I can add some comments on when different scopes may not be needed.

Here are the API calls we are making (just doing a code search for .request:

GET /repos/:owner/:repo/actions/runs/:run_id (actions: read)
GET /repos/:owner/:repo/actions/workflows (actions: read)
PUT /repos/:owner/:repo/code-scanning/analysis/status (security-events: write)
GET /enterprise/code-scanning/codeql-bundle/find/{tag} (security-events: read)
GET /enterprise/code-scanning/codeql-bundle/download/{asset_id} (security-events: read)
GET /repos/:owner/:repo/code-scanning/codeql/databases (security-events: read)
PUT /repos/:owner/:repo/code-scanning/codeql/databases/:language (security-events: write)
PUT /repos/:owner/:repo/code-scanning/analysis (security-events: write)

Unless I've missed something, we only need security-events: write and actions: read.

Plus you need enough permission to check out the repo itself in the workflow (but not in the Action), which I believe is either contents: read or pull_requests: read.

Ah..yes. Again, only for private repos, it seems. So, contents: read guards the GET /repos/:owner/:repo/contents/:path endpoint. I don't see anything about pull requests, though. This would only be for things like editing the PR itself, or adding comments, etc.

Here are the API calls we are making (just doing a code search for .request:

GET /repos/:owner/:repo/actions/runs/:run_id (actions: read)
GET /repos/:owner/:repo/actions/workflows (actions: read)
PUT /repos/:owner/:repo/code-scanning/analysis/status (security-events: write)
GET /enterprise/code-scanning/codeql-bundle/find/{tag} (security-events: read)
GET /enterprise/code-scanning/codeql-bundle/download/{asset_id} (security-events: read)
GET /repos/:owner/:repo/code-scanning/codeql/databases (security-events: read)
PUT /repos/:owner/:repo/code-scanning/codeql/databases/:language (security-events: write)
PUT /repos/:owner/:repo/code-scanning/analysis (security-events: write)

Unless I've missed something, we only need security-events: write and actions: read. And the latter is only for private repos.

@aeisenberg  I am trying to figure out the required permissions for any GitHub Action. What is the process to get all the necessary permission? Thanks

There's no principled way of doing this that I can think of. An action can make any arbitrary request to the github api. And it can make requests in many ways (since they are just fundamentally REST requests): curl, gh, octokit, etc.
You could try setting very restrictive permissions, and slowly loosen them until you get your workflow passing. Alternatively, you can try to eyeball the code, which could be tricky if the action is doing non-standard things.

There's no principled way of doing this that I can think of. An action can make any arbitrary request to the github api. And it can make requests in many ways (since they are just fundamentally REST requests): curl, gh, octokit, etc.
You could try setting very restrictive permissions, and slowly loosen them until you get your workflow passing. Alternatively, you can try to eyeball the code, which could be tricky if the action is doing non-standard things.

Thank you!

repo: github/codeql-action


text:
Use chromium for karma tests

What am I trying to accomplish
Provide a Chromium binary for front-end projects to run karma tests with when running in Codespaces or other environments where chrome browser is not necessarily installed.
Part of https://github.com/github/web-systems/issues/162 (see that issue for more info)
What approach did I take?
I installed and configured the chromium npm package for use with karma tests.

Note tests currently failing running chromium in Codespaces

source: gharchive/pull-request

repo: github/details-dialog-element

license: MIT

license_type: permissive

license_source: github-api


text:
Support dark mode.

What is the current behavior?
The https://docs.github.com website does not support dark mode.
Browser: Microsoft Edge 88.0.705.63
What changes are you suggesting?
Hope to add support for dark mode.
Additional information
Microsoft Edge supports dark mode CSS media queries.

@simpsoka FYI!

Thanks for opening this issue about dark mode for docs!
This has come up in the past, and we're actually in the middle of a site re-design, so we're rolling that out first and then we can look into supporting dark mode so that we get it to support the new design (not the old one).
With the new design, we're also looking at modular CSS - which will also help with adding darkmode. So I'm going to close this out for now and then we can get it on our backlog!

source: gharchive/issue

authors: chiedo lc6464 simpsoka

repo: github/docs


text:
Got allows a redirect to a UNIX socket

The got package before 11.8.5 and 12.1.0 for Node.js allows a redirect to a UNIX socket.
creating a security update to fix got in package-lock.json.
Or, manually upgrade got to version 11.8.5 or later. For example:
"dependencies": {
  "got": ">=11.8.5"
}

"devDependencies": {
  "got": ">=11.8.5"
}

@imhunterand thanks for opening a PR! ⚡
We can't accept these types of changes. Please take a look at our help wanted section to find open issues you can work on. 💛
Thank you for your interest in improving GitHub Docs! ✨


text:
Fix type of strategy context's properties

Why:
Closes #20689

What's being changed (if available, include any code snippets, screenshots, or gifs):

Types of strategy context object in the table are corrected.
Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

I confirmed changes: https://docs-20690-cfb666.preview.ghdocs.com/en/actions/learn-github-actions/contexts#strategy-context

@rhysd Thanks for opening a PR and linking it to your issue! ✨
I'll get this triaged for review. ⚡


text:
Update learn-to-code/index.md

Thank you for contributing! Please confirm this pull request meets the following requirements:

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md
[x] I have no affiliation with the project I am suggesting (as a maintainer, creator, contractor, or employee).

Which change are you proposing?

[x] Suggesting edits to an existing topic or collection
[ ] Curating a new topic or collection

Editing an existing topic or collection
I'm suggesting these edits to an existing topic or collection:

[ ] Image (and my file is *.png, square, dimensions 288x288)
[x] Content (and my changes are in index.md)

30 seconds of code is a great learning resource for JS developers.

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

Thanks so much for your contribution! Without people like you submitting PRs we couldn't run this project. You rock, @reptonian6!

repo: github/explore


text:
Fetch spec requires non-omit credentials mode to set cookies too.

HTTP Network or cache fetch step 13 gates on the credentials flag.

Sorry for the merge commit :/

Yeah, this sounds right.

If credentials flag is set and response's header list contains one or more headers named Set-Cookie, run these substeps:

Could @annevk confirm?
There would be a bug in Chrome Canary in this case cause it does pass here when it shouldn't. @nikhilm could you write an extra test that asserts that Set-Cookie is ignored in the credentials omit case.

Thanks @nikhilm!

Confirmed, cookies should only be set if the request allowed credentials. Otherwise e.g. a CORS preflight could result in cookies being set.

Thanks @annevk!

authors: annevk josh nikhilm

repo: github/fetch

license: mit

license_source: bigquery


text:
~/.config/hub file missing

I have just downloaded and tested Hub.
I have configured my github host according to the documentation and tried a simple command.
$ hub pr list
github.myorganization.net username: gobater
github.myorganization.net password for gobater (never stored): ******
Must authenticate to access this API.

after that, I would expect as stated in the documentation that my username would be stored in the config file ~/.config/hub. However, the file has not been created.
$ ls -l ~/.config
total 0
drwxr-xr-x 0 Q296039 1049089 0 Nov 25  2019 git

Basically I am willing to know the format of the file to store my github token there (instead of providing it via environment variable) but I have not been able to find any documentation on the config file.
I have also tried to set the environment variable HUB_CONFIG, but it does not help. The file is emply after executing the command.
I am using hub in windows.
$ hub version
git version 2.26.1.windows.1
hub version 2.14.2

Thanks to https://github.com/github/hub/issues/1488 I found out how to solve my issue. However, there is still a bug since the file has not been created/updated

@gobater This line of output makes me think that the authentication was not successful:
Must authenticate to access this API.

When authentication is not successful, no token will be stored in ~/.config/hub.
Anyway, I think you've found the format of ~/.config/hub by now, so I'm going to close this out. 🙇

authors: gobater mislav

repo: github/hub


text:
Move commitLogs declaration inside multiple commits block

This makes it clearer that commits are only added as a commented section in the case when there are multiple commits on a branch.
I'm a very new go developer, so apologies if this is a non-idiomatic change.

This is ready for review again. Thanks!


text:
Update jekyll-commonmark-ghpages.rb

Close the
 tag for use in xhtml pages

This should hopefully fix issue #3

I suspect you misunderstand the code here; it adds the
s only to remove them after remove them when done. The code change as you've made it is also a syntax error — note the unescaped forward slash in /
/.
Would you mind adding a test that demonstrates the outcome you're trying to achieve?

I am not sure I understand this. Why adding them then?

It's done in order to preserve the newlines correctly across the syntax highlighting process.

What I am trying to achieve is for it to work as before. I did not change anything on my side, but it seems that the
 are now added. It is something new that is not generated with kramdown (locally) but that breaks the generated xhtml when generated on the github server.

Without a test case it's hard to know exactly what you're referring to here, but do try and we'll see if we can get something working.

This now works with xhtml pages by adding valid xml
.

Have you tested this change? It simply won't do what you want it to. The
s are being added elsewhere; possibly in the highlighter itself (rouge), or by commonmarker.

We are changing \n to
 so we can preserve newlines without them being mangled by commonmarker. After rendering the CommonMark (with highlighted syntax embedded as HTML) to HTML, we return those to \ns. Are you bypassing the normal rendering process? You should never see
 in your final output.

I am not bypassing the normal rendering process. The
 do appear in the output generated on the github server (see http://www.verovio.org/command-line.xhtml generated from https://github.com/rism-ch/verovio/blob/gh-pages/command-line.xhtml#L42-L44)
I tested the change submitted and it works. (But the
 are still in the output)

Huh, I'm a bit lost. I looked at your repo, and your _config.yml has the following:
markdown: kramdown

How is it you're using jekyll-commonmark-ghpages/testing changes to it? I'd like to set up a reproduction locally so I can try to debug why the
s are appearing in output. We shouldn't be seeing them at all, basically.

I tested locally by changing the config to markdown: CommonMarkGhPages, and then installing the plugin locally where I was able to test the modification. The output has
in it.
Now of course I also do not understand why CommonMarkGhPages is used when the config says kramdown, but this is obviously something on the GitHub side which I cannot investigate.

I've found the source of the bug — this code is being executed even for non-CommonMark pages; a fix will be forthcoming.

Tested fix locally, verified working. I'll let you know when it's published to Pages live, then a rebuild will fix this.

This should now be fixed. If you push a new commit to restart the build, you should find the command-line.xhtml is rendering correctly 👍

(I've triggered a manual build from our side, and it's now looking good: http://www.verovio.org/command-line.xhtml)

Great! Many thanks for taking care of this

authors: kivikakk lpugin

repo: github/jekyll-commonmark-ghpages


text:
Sqlite

This branch experiments with sqlite as backend database. It's an ongoing effort in looking for the incompatibilities between MySQL and sqlite.
I'm meanwhile pursuing, brute-force, the transparent transformations of MySQL dialect into sqlite dialect, so as to find out the real changes in semantics and behavior.

The build will currently fail, as I haven't integrated the go-sqlite3 package inside the source tree.

@shlomi-noach This is going to be great, thanks for this. Let me know if you need an extra hand to test this. I am more than happy if I can help.

At this time orchestrator works with sqlite backend. I took the brute-force approach for converting MySQL dialect into sqlite3 dialect via regular expressions; I had to rewrite many queries where this was not achievable.
Many of these queries have now been simplified (which is good), and some have been broken into app logic (which is a pity).
The changes in no way suggest a generic translation mysql->sqlite. I just wanted to get warmed up to start testing functionality.
I'm proceeding to back-test that the rewrites work with mysql (I tested each individually, but haven't run a comprehensive check).

Will certainly need better testing method for this.
Next on this PR: somehow make the integration tests work on sqlite.

I've been spending far too many hours on this. Perhaps someone can come up with a magic solution?
This PR is using https://github.com/mattn/go-sqlite3: sqlite wrapping for golang. The package contains a C file which compiles via cgo and is slow to compile (adds some 20-25 seconds compilation time).
A quick local win is to run go install github.com/mattn/go-sqlite3 ; subsequent runs will just use the package found on $GOPATH/pkg/darwin_amd64/github.com/mattn/go-sqlite3.a.
However the problem is this: I wish to incorporate this package under the vendor/ directory of this repository; such that anyone who clones github.com/github/orchestrator gets sqlite3 automatically, no external dependencies.
That also works -- with the problem that go now insists to compile the sqlite3 package every time I issue a go run.... I'm unable to tell go to use a .a package file within my own repository.
I tried:

Adding pkg/darwin_amd64/github.com/mattn/go-sqlite3.a in repo path, using go build -pkgdir=pkg/
Adding pkg/... under vendor/, under vendor/github.com/mattn/go-sqlite3, under practically any folder I thought would make sense
Using binary-only packages

I realize the .a package depends on the exact golang version that compiled it -- it's fine that I would need to compile via cgo once , and that any user would have to do the same once, but having these extra 20-25 seconds for every compilation/run is too painful.
Does anyone have any suggestion?

merged https://github.com/github/orchestrator/pull/75 which solves dependency issue

status:

deploys and runs well on MySQL backend (changed queries seem legit; no duplicate indexes; all indexes in place)
have not run with sqlite backend in production. Anyhow this requires group communication, which is the topic for a different PR

todo:

[ ] documentation

authors: shlomi-noach theTibi

repo: github/orchestrator


text:
Parental consent. We need that for the kids.

1. What's the name of the policy?
Age
2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.
It's this part
3. Did you already open a pull request? If so, please include a link to the PR in the GitHub Docs repo.
No.
4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.
Kids need "parental consent" meaning that parents take responsibility for their child's actions.
5. Why do you think this section or language needs improvement?
Because parental consent is always nice.

This is legal stuff isn't really GitHub's choice, and there isn't a good way of verifying parental consent. You yourself are underaged (see this, then this), so please stop pushing for ways to stay on the platform. Also, you did open a PR.

You yourself are underaged

bruh I'm 13 and held back

authors: CluckCluckChicken Timed-kitty-cat

repo: github/site-policy


text:
[Proposal] Extension API for automating GitHub Actions workflow creation

Transferred from https://github.com/cschleiden/vscode-github-actions/issues/160
Description
Deployment of "cloud native" components is becoming an integral component of the development process. GitHub (the website) provides a set of "starter" templates for GitHub Actions workflows, for various deployment scenarios, but there is no current means for this extension (or others) to reuse them. Furthermore, those templates often require additional user action before they can properly function, such as setting repository secrets and/or replacing tokens in the template content.
VS Code extensions have need to provide its users the ability to create deployment assets and automate their configuration. Some extensions will simply want to reuse the GitHub Actions workflow templates as-is, some will want to further automate their configuration, and some will want to offer completely new workflows.
The proposal is to have this extension offer its users (1) the direct means to create GitHub Actions workflows (e.g. via the command palette), both the existing GitHub Actions templates as well as any proffered by 3rd-party extensions, (2) the ability for 3rd-party extensions to further automate the creation of existing GitHub Actions templates, and (3) the ability for 3rd-party extensions to proffer their own workflow templates.
Goals

Allow users to create a GitHub Actions workflow by choosing from a list of both "starter" and contributed workflows
Allow 3rd-party extensions to initiate creation of a specific workflow, both "starter" GitHub Actions workflows and workflows contributed by other 3rd-party extensions
Allow 3rd-party extensions to "claim ownership" of the "starter" GitHub Actions workflows in order to further automate its configuration
Allow 3rd-party extensions to contribute additional GitHub Actions workflows and provide a simplified means to perform common template customizations (e.g. setting repository secrets)

Non-goals

Providing general APIs for managing repository content and settings

Extension API
This extension will export a versioned API to be used by 3rd-party extensions, both for initiating the creation of a specific workflow as well as to register itself as a contributor of workflow templates (or augmentor of existing "starter" workflow templates).
import * as vscode from "vscode";

/**
 * Context provided to the GitHub workflow provider when asked to create a workflow.
 */
export interface WorkflowCreationContext {
    /**
     * Optional and opaque context provided by the caller when creating the workflow.
     */
    readonly callerContext?: never;

    /**
     * Initial content (if any) for a new workflow. Populated, for example, when creating a starter workflow.
     */
    readonly content?: string;

    /**
     * Initial name for a new workflow file. Populated, for example, when creating a starter workflow.
     */
    readonly suggestedFileName?: string;

    /**
     * The type of workflow being created. This can be useful when the same handler is used for multiple workflow types.
     */
    readonly type: string;

    /**
     * The URI for the workspace in which the workflow will be created.
     */
    readonly workspaceUri: vscode.Uri;

    /**
     * Creates a new workflow file.
     *
     * @param suggestedFileName The suggested file name for a new workflow.
     * @param content The content of the workflow.
     *
     * @returns The actual URI of the created workflow.
     */
    createWorkflowFile(suggestedFileName: string, content: string): Promise<vscode.Uri | undefined>;

    /**
     * Creates or updates an actions secret in the GitHub repository.
     *
     * @param suggestedName The suggested name for the secret.
     * @param value The new value of the secret.
     *
     * @returns The actual name of the created/updated secret.
     */
    setSecret(suggestedName: string, value: string): Promise<string | undefined>;
}

export interface GitHubWorkflowProvider {
    createWorkflow(context: WorkflowCreationContext): Promise<void>;
}

/**
 * The current (v1) GitHub Actions extension API.
 */
export interface GitHubActionsApi {
    /**
     * Creates a new workflow.
     *
     * @param type The type of workflow to create. If omitted or undefined, the user will be prompted to select a workflow.
     * @param callerContext An optional, opaque object provided to the workflow provider.
     *
     * @returns The URIs of all created workflow files.
     */
    createWorkflow(type?: string, callerContext?: never): Promise<vscode.Uri[]>;

    /**
     * Registers a provider of a specific workflow type.
     *
     * @param type The type of workflow associated with the provider.
     * @param provider The provider that will handle creating workflows of the specified type.
     *
     * @returns A disposable that will unregister the provider.
     */
    registerWorkflowProvider(type: string, provider: GitHubWorkflowProvider): vscode.Disposable;
}

/**
 * Exported object of the GitHub Actions extension.
 */
export interface GitHubActionsApiManager {

    /**
     * Gets a specific version of the GitHub Actions extension API.
     *
     * @typeparam T The type of the API.
     * @param version The version of the API to return. Defaults to the latest version.
     *
     * @returns The requested API or undefined, if not available.
     */
    getApi<T>(version: 1): T | undefined
}

Package Configuration
3rd-party extensions contributing workflows declare them in package.json in one of two ways, depending on whether they are augmenting the existing "starter" workflows or creating their own.
Augmenting "Starter" Workflows
Workflow contributions should include the following properties:
workflow: The name of the starter workflow, which follows the <directory>/file[.yml] in the actions/starter-workflows repository (i.e. omitting the .yml).
{
    "contributes": {
        "x-github-workflows": [
            {
                "workflow": "deployments/azure-webapps-dotnet-core"
            }
        ]
    }
}

Custom Workflows
Custom workflow contributions should include the following properties:

workflow: A unique name for the workflow type
title: The title of the workflow shown to users in a list
description: The description of the workflow shown to users in a list
group: The label under which the template should be grouped or, to be grouped with other templates, use one of ci, deployments, automation, or code-scanning

{
    "contributes": {
        "x-github-workflows": [
            {
                "workflow": "my-deployment-workflow-type",
                "title": "My Deployment Workflow",
                "description": "A workflow to automate deployment of my service type",
                "group": "deployments"
            }
        ]
    }
}

Usage
Creating workflows
import * as vscode from 'vscode';
import { GitHubActionsApi, GitHubActionsApiManager } from 'vscode-github-actions-api';

export function activate(context) {
  context.subscriptions.push(
    vscode.commands.registerCommand(
      "my-extension.workflow.create",
      async () => {
        const gitHubActionsExtension = vscode.extensions.getExtension('cschleiden.vscode-github-actions');

        if (gitHubActionsExtension) {
          await gitHubActionsExtension.activate();

          const manager: GitHubActionsApiManager | undefined = gitHubActionsExtension.exports as GitHubActionsApiManager;

          if (manager) {
            const api: GitHubActionsApi | undefined = manager.getApi(1);

            if (api) {
              const workflowFiles = await api.createWorkflow(`deployments/azure-webapps-dotnet-core`);

              // Open all created workflow files...
              await Promise.all(workflowFiles.map(file => vscode.window.showTextDocument(file)));
            }
          }
      }));
}

Registering workflows
import * as vscode from 'vscode';
import { GitHubActionsApi, GitHubActionsApiManager } from 'vscode-github-actions-api';

export function activate(context) {
    const gitHubActionsExtension = vscode.extensions.getExtension('cschleiden.vscode-github-actions');

    if (gitHubActionsExtension) {
        await gitHubActionsExtension.activate();

        const manager: GitHubActionsApiManager | undefined = gitHubActionsExtension.exports as GitHubActionsApiManager;

        if (manager) {
            const api: GitHubActionsApi | undefined = manager.getApi(1);

            if (api) {
                context.subscriptions.push(
                  api.registerWorkflowProvider(
                    'deployments/azure-webapps-dotnet-core',
                    {
                        createWorkflow: async (context): Promise<void> => {

                        const xml: string = // Get Azure publish profile XML...

                        await context.setSecret('AZURE_WEBAPP_PUBLISH_PROFILE', xml);

                        let content = context.content;

                        // Transform content (e.g. replace `your-app-name` with application name)...

                        await context.createWorkflowFile(context.suggestedFileName ?? 'azure-webapps-dotnet-core.yml', content);
                    }));
            }
         }
      }
}

Concerns and Open Questions
Extension API Definition
What will be the best way for 3rd-party extensions to acquire the TypeScript definitions of this extension's API? Potential options are:

Require developers to copy definitions from this extension's repository
Contribute definitions to a separate types aggregator like DefinitelyTyped
Create and publish a separate vscode-github-actions-api NPM package

"Starter" workflow template ownership
The proposal assumes that each contributed workflow type is owned by a single extension and this seems reasonable for unique workflow contributions. The proposal allows extensions to also augment the "starter" workflow templates; the proposal assumes (perhaps naively) that each template naturally maps to a single extension. In cases where that doesn't hold, where multiple extensions register providers for the same type of workflow, what should this extension do?
Potential options are:

Last registered wins
First registered wins
Neither registered wins
Have an explicit map of workflow types to extension owners
Explicitly allow multiple registered providers per type (i.e. each is given an opportunity to further augment workflow)
Prompt user to select which extension wins during creation (and, related, allow extension-invoked workflow creation to designate an owner independent of the owners)
Allow extensions to augment certain extension-invoked workflow creation without first requiring registration (i.e. one-off augmentation)

Extension Activation
Because workflow contributions are declarative, this extension need not activate extensions contributing workflows unless and until immediately before their workflows are actually created. However, extensions which contribute workflows need access to this extension's API for registration during their activation. This implies that this extension's activation time will directly contribute to the overall activation time of contributing extensions. That is, care will need to minimize this extension's activation time.
Prototype Branch
https://github.com/philliphoff/vscode-github-actions/tree/philliphoff-create-workflow

Good 👍

Run

Transferred from https://github.com/cschleiden/vscode-github-actions/issues/160
Description
Deployment of "cloud native" components is becoming an integral component of the development process. GitHub (the website) provides a set of "starter" templates for GitHub Actions workflows, for various deployment scenarios, but there is no current means for this extension (or others) to reuse them. Furthermore, those templates often require additional user action before they can properly function, such as setting repository secrets and/or replacing tokens in the template content.
VS Code extensions have need to provide its users the ability to create deployment assets and automate their configuration. Some extensions will simply want to reuse the GitHub Actions workflow templates as-is, some will want to further automate their configuration, and some will want to offer completely new workflows.
The proposal is to have this extension offer its users (1) the direct means to create GitHub Actions workflows (e.g. via the command palette), both the existing GitHub Actions templates as well as any proffered by 3rd-party extensions, (2) the ability for 3rd-party extensions to further automate the creation of existing GitHub Actions templates, and (3) the ability for 3rd-party extensions to proffer their own workflow templates.
Goals

Allow users to create a GitHub Actions workflow by choosing from a list of both "starter" and contributed workflows
Allow 3rd-party extensions to initiate creation of a specific workflow, both "starter" GitHub Actions workflows and workflows contributed by other 3rd-party extensions
Allow 3rd-party extensions to "claim ownership" of the "starter" GitHub Actions workflows in order to further automate its configuration
Allow 3rd-party extensions to contribute additional GitHub Actions workflows and provide a simplified means to perform common template customizations (e.g. setting repository secrets)

Non-goals

Providing general APIs for managing repository content and settings

Extension API
This extension will export a versioned API to be used by 3rd-party extensions, both for initiating the creation of a specific workflow as well as to register itself as a contributor of workflow templates (or augmentor of existing "starter" workflow templates).
import * as vscode from "vscode";

/**
 * Context provided to the GitHub workflow provider when asked to create a workflow.
 */
export interface WorkflowCreationContext {
    /**
     * Optional and opaque context provided by the caller when creating the workflow.
     */
    readonly callerContext?: never;

    /**
     * Initial content (if any) for a new workflow. Populated, for example, when creating a starter workflow.
     */
    readonly content?: string;

    /**
     * Initial name for a new workflow file. Populated, for example, when creating a starter workflow.
     */
    readonly suggestedFileName?: string;

    /**
     * The type of workflow being created. This can be useful when the same handler is used for multiple workflow types.
     */
    readonly type: string;

    /**
     * The URI for the workspace in which the workflow will be created.
     */
    readonly workspaceUri: vscode.Uri;

    /**
     * Creates a new workflow file.
     *
     * @param suggestedFileName The suggested file name for a new workflow.
     * @param content The content of the workflow.
     *
     * @returns The actual URI of the created workflow.
     */
    createWorkflowFile(suggestedFileName: string, content: string): Promise<vscode.Uri | undefined>;

    /**
     * Creates or updates an actions secret in the GitHub repository.
     *
     * @param suggestedName The suggested name for the secret.
     * @param value The new value of the secret.
     *
     * @returns The actual name of the created/updated secret.
     */
    setSecret(suggestedName: string, value: string): Promise<string | undefined>;
}

export interface GitHubWorkflowProvider {
    createWorkflow(context: WorkflowCreationContext): Promise<void>;
}

/**
 * The current (v1) GitHub Actions extension API.
 */
export interface GitHubActionsApi {
    /**
     * Creates a new workflow.
     *
     * @param type The type of workflow to create. If omitted or undefined, the user will be prompted to select a workflow.
     * @param callerContext An optional, opaque object provided to the workflow provider.
     *
     * @returns The URIs of all created workflow files.
     */
    createWorkflow(type?: string, callerContext?: never): Promise<vscode.Uri[]>;

    /**
     * Registers a provider of a specific workflow type.
     *
     * @param type The type of workflow associated with the provider.
     * @param provider The provider that will handle creating workflows of the specified type.
     *
     * @returns A disposable that will unregister the provider.
     */
    registerWorkflowProvider(type: string, provider: GitHubWorkflowProvider): vscode.Disposable;
}

/**
 * Exported object of the GitHub Actions extension.
 */
export interface GitHubActionsApiManager {

    /**
     * Gets a specific version of the GitHub Actions extension API.
     *
     * @typeparam T The type of the API.
     * @param version The version of the API to return. Defaults to the latest version.
     *
     * @returns The requested API or undefined, if not available.
     */
    getApi<T>(version: 1): T | undefined
}

Package Configuration
3rd-party extensions contributing workflows declare them in package.json in one of two ways, depending on whether they are augmenting the existing "starter" workflows or creating their own.
Augmenting "Starter" Workflows
Workflow contributions should include the following properties:
workflow: The name of the starter workflow, which follows the <directory>/file[.yml] in the actions/starter-workflows repository (i.e. omitting the .yml).
{
    "contributes": {
        "x-github-workflows": [
            {
                "workflow": "deployments/azure-webapps-dotnet-core"
            }
        ]
    }
}

Custom Workflows
Custom workflow contributions should include the following properties:

workflow: A unique name for the workflow type
title: The title of the workflow shown to users in a list
description: The description of the workflow shown to users in a list
group: The label under which the template should be grouped or, to be grouped with other templates, use one of ci, deployments, automation, or code-scanning

{
    "contributes": {
        "x-github-workflows": [
            {
                "workflow": "my-deployment-workflow-type",
                "title": "My Deployment Workflow",
                "description": "A workflow to automate deployment of my service type",
                "group": "deployments"
            }
        ]
    }
}

Usage
Creating workflows
import * as vscode from 'vscode';
import { GitHubActionsApi, GitHubActionsApiManager } from 'vscode-github-actions-api';

export function activate(context) {
  context.subscriptions.push(
    vscode.commands.registerCommand(
      "my-extension.workflow.create",
      async () => {
        const gitHubActionsExtension = vscode.extensions.getExtension('cschleiden.vscode-github-actions');

        if (gitHubActionsExtension) {
          await gitHubActionsExtension.activate();

          const manager: GitHubActionsApiManager | undefined = gitHubActionsExtension.exports as GitHubActionsApiManager;

          if (manager) {
            const api: GitHubActionsApi | undefined = manager.getApi(1);

            if (api) {
              const workflowFiles = await api.createWorkflow(`deployments/azure-webapps-dotnet-core`);

              // Open all created workflow files...
              await Promise.all(workflowFiles.map(file => vscode.window.showTextDocument(file)));
            }
          }
      }));
}

Registering workflows
import * as vscode from 'vscode';
import { GitHubActionsApi, GitHubActionsApiManager } from 'vscode-github-actions-api';

export function activate(context) {
    const gitHubActionsExtension = vscode.extensions.getExtension('cschleiden.vscode-github-actions');

    if (gitHubActionsExtension) {
        await gitHubActionsExtension.activate();

        const manager: GitHubActionsApiManager | undefined = gitHubActionsExtension.exports as GitHubActionsApiManager;

        if (manager) {
            const api: GitHubActionsApi | undefined = manager.getApi(1);

            if (api) {
                context.subscriptions.push(
                  api.registerWorkflowProvider(
                    'deployments/azure-webapps-dotnet-core',
                    {
                        createWorkflow: async (context): Promise<void> => {

                        const xml: string = // Get Azure publish profile XML...

                        await context.setSecret('AZURE_WEBAPP_PUBLISH_PROFILE', xml);

                        let content = context.content;

                        // Transform content (e.g. replace `your-app-name` with application name)...

                        await context.createWorkflowFile(context.suggestedFileName ?? 'azure-webapps-dotnet-core.yml', content);
                    }));
            }
         }
      }
}

Concerns and Open Questions
Extension API Definition
What will be the best way for 3rd-party extensions to acquire the TypeScript definitions of this extension's API? Potential options are:

Require developers to copy definitions from this extension's repository
Contribute definitions to a separate types aggregator like DefinitelyTyped
Create and publish a separate vscode-github-actions-api NPM package

"Starter" workflow template ownership
The proposal assumes that each contributed workflow type is owned by a single extension and this seems reasonable for unique workflow contributions. The proposal allows extensions to also augment the "starter" workflow templates; the proposal assumes (perhaps naively) that each template naturally maps to a single extension. In cases where that doesn't hold, where multiple extensions register providers for the same type of workflow, what should this extension do?
Potential options are:

Last registered wins
First registered wins
Neither registered wins
Have an explicit map of workflow types to extension owners
Explicitly allow multiple registered providers per type (i.e. each is given an opportunity to further augment workflow)
Prompt user to select which extension wins during creation (and, related, allow extension-invoked workflow creation to designate an owner independent of the owners)
Allow extensions to augment certain extension-invoked workflow creation without first requiring registration (i.e. one-off augmentation)

Extension Activation
Because workflow contributions are declarative, this extension need not activate extensions contributing workflows unless and until immediately before their workflows are actually created. However, extensions which contribute workflows need access to this extension's API for registration during their activation. This implies that this extension's activation time will directly contribute to the overall activation time of contributing extensions. That is, care will need to minimize this extension's activation time.
Prototype Branch
https://github.com/philliphoff/vscode-github-actions/tree/philliphoff-create-workflow

repo: github/vscode-github-actions


text:
[sdcc_asm_optimizer] statement 规则歧义过多，影响程序执行时间

https://github.com/github0null/eide_tools/blob/a5def625657fc879ec0256700767c4c3298d7bbf/sdcc_asm_optimizer/lib/SdAsm.g4#L74-L79
两条规则存在相同的匹配，有歧义，可合并为一个

已优化：https://github.com/github0null/eide_tools/commit/ae7d99be263c82669652a79b8fe2587841c5ef02


text:
🛑 MSP-002 is down

In 12a873c, MSP-002 (https://msp-portal.gw002.oneitfarm.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MSP-002 is back up in 634f7a0.

repo: gitsrc/upptime


text:
🛑 MSP-103 is down

In 0d686a1, MSP-103 (https://msp-portal.gw103.oneitfarm.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MSP-103 is back up in b11486c.


text:
🛑 Address Geocoder is down

In 064125c, Address Geocoder (https://geocoder.api.gov.bc.ca/addresses.json?addressString=525 Superior Street%2C Victoria%2C BC) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Address Geocoder is back up in fd24dab.

repo: gjlawran/apsmon


text:
Chinese Translation Suppport

Chinese Translation By @AimerNeige & @Gaein_nidb

All files mentioned in #71 should be updated but never locally tested.

Hey, this looks great! Thanks so much!

authors: aimerneige gjtorikian


text:
test 3

I think, it fixes:
https://github.com/gkz/LiveScript/issues/349

Because the compiler optimization, as well as the for loop, could give different result than while using .slice, my idea is to use .slice only in 2 easy to remember cases:

variable[a til b]
variable[a to b]

where a and b could be a literal, an expression or be empty.
That way it could still use .slice, while not being a cognitive burden.

Hey, @vendethiel does it take long for approval? Or how this works) and, I'll maybe move to another bug issue from this..

Hey @determin1st, thanks for jumping in!
The first thing to get straight is whether or not this change is even desired. From my cursory review of #349, I'm not convinced that any proposed change is obviously right. I do think that the issue originally reported is something that merits fixing, so something should be done, but I don't have an opinion on what yet. Convince me you're right, or resume the conversation in #349 to get more of a consensus.
The second thing is, and I don't mean to discourage you, but this and #1086 are both terrible PRs for at least the following reasons:

Their names and descriptions. A good PR should explain why I should bother to even look at it; otherwise, I won't.
They include unrelated changes—both PRs include a commit that edits .gitignore, for example, which has nothing whatsoever to do with the main purpose of the PR. This PR seems to include commits from #1086, which I already rejected. I'm going to give you the benefit of the doubt and assume that this is because you are inexperienced with how Git and/or pull requests work, and not that you're trying to sneak something in and hoping I don't notice. But even so, if you want any contributions you make here to be accepted, you're going to have to do better.
Work should be broken into commits that represent entire units of work, with clear and descriptive commit messages. (‘rev’ is, I shouldn't have to say, not a clear and descriptive commit message.) For fixing #349, unless something unusual comes up, one commit would be the correct number of commits.
This PR touches a lot of characters that it doesn't need to. Changing indentation, reformatting otherwise unchanged lines, and renaming variables are all things that make the diff bigger and make it harder for me to review what you actually changed. A hard-to-review PR is an ignored PR. Please try to copy the existing style of the LS code as well as you can, and make the smallest possible changes to achieve the desired effect.
Whenever possible, PRs that make observable changes to how code is compiled must include a test of the functionality being changed.

There may be other issues with the implementation here; I don't know, because I don't think it's worth my time to review this PR in this state. Get consensus on the desired effect, fix the above glaring issues, and then we can start talking about approval.
The above may sound harsh, but I'm not trying to push you away. Please believe me when I say that I would love for you to be making quality contributions to LiveScript's code; and once you start doing so, I will be happy to review and accept them. But there is either a learning or an effort gap that you need to cross in order to get there, and I won't compromise on that. If you're new to contributing to GitHub projects, you might want to look around on the web for resources in your native language about how to submit good pull requests. You should also be or get familiar enough with Git that you can rebase and amend commits to polish them up into an acceptable state.

Well, thanks for explanation.
My concern, that Issues with "Bug" label are hard to traverse. Some of them have no decisions or no good examples to start from.. How to find some ready-for-implementation thing?
Changes in this PR may be reduced to 4 lines:
1 line:
https://github.com/gkz/LiveScript/pull/1088/files#diff-94df39e39af97137ba55977f88dd23a4R1259
and
https://github.com/gkz/LiveScript/pull/1088/files#diff-94df39e39af97137ba55977f88dd23a4R1323-R1326
with some comments inserted, i hope, it's clear what they do.
Other reformattings were done because.. hmm.. territorial marking thing. I feel that code becomes my code and it helps me better understand the logic involved.. So, it can't be totally undone in a long run.
I'm okay with rewinding and throwing away first commit, no problem. Tests? Fully agree, is a must for such a project (they showed that my first attempt failed and required a revision).
As you won't compromize, lets pause/cancel this until either, I adapt or You trade. :handshake:

repo: gkz/LiveScript


text:
Fix sshfs bug

FUSE Creation (O_CREAT, O_EXCL, O_NOCTTY) flags will be filtered out
and handled by the kernel.
Re: https://libfuse.github.io/doxygen/structfuse__operations.html#a14b98c3f7ab97cc2ef8f9b1d9dc0709d
So assume create always.
Hacky... but fixes the bug. See forked commit here: https://github.com/jessfraz/sshfs/commit/c985e1312f080244577a15213977f5e9e83cec7d#diff-a0a498b859a2c8d3c48c2ad49582821bR2525

wait now this isnt working...

Holy crap, you're a friggen wizard

authors: jessfraz progrium

repo: gl-prototypes/cmd-localfs


text:
Merging the latest changes from the MCP fork

Bringing there two forks in line should let us merge the changes easier in the future.

Everything seems alright to me!

repo: gla-rad/ServiceRegistry


text:
feat(ui): display latest version in package overview

Closes #330
Fixes #330
📑 Description
This shows the LatestVersion and the Current version (if installed) on the package overview page
Images :

When a Package is installed

When a Package is not installed

✅ Checks

[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required

ℹ Additional Information

I can try this, can you give me some more information on this. And what's the actual purpose it solves.

Also I forgot the path which sends all the data to the template. Could you please guide me to the file. (Data : Manifests, Status, Package etc. In the package-detail page)

Also I can't find the path which sends all the data to the template. Could you please guide me to the file. (Data : Manifests, Status, Package etc. In the package-detail page)

I think what you're looking for is the packageDetail function in internal/web/server.go.

what's the actual purpose it solves.

I think, as a user I don't really care what the latest version is if I'm already using it and especially if I am using a version that is newer than the latest version (the latest version is not necessarily the highest available, it's the one that was tested and reviewed).

I can try this, can you give me some more information on this.

If you have any more specific questions I can try to answer them! :slightly_smiling_face:

Well from your explaination I understood :

Adding a IsUpgrade in the templatesFunc
Looking something like this:

"IsUpgradeble": semver.IsUpgradable,

After performing this I added the htmx code as :

            {{ if IsUpgradable .Package.Status.Version .LatestVersion }}
               Latest Version: {{ .LatestVersion }}
            {{ end }}

            {{ if ne .Status nil }}
               Current Version: {{ .Package.Status.Version }}
            {{ end }}

Is this something we are looking for?
Here I have a small doubt. If I apply this code then we wont be able to see the latest version in the package which is not installed.

That looks like it might work. I think IsUpgradable returns true if one of the versions is empty so we should be fine here.

What about showing LatestVersion on packages which are not installed?

What about showing LatestVersion on packages which are not installed?

In this case, the latest version should be shown. But I think your code already does this.

Hey here I made a few mistakes before in the commits but fixed it in the next commit. But still the checks have not passed as it shows the error of the past commit too. Is there any way to fix it.

git fetch origin && git rebase origin/main
… then test your changes, then …
git push --force-with-lease

repo: glasskube/glasskube


text:
🛑 Schoelcher is down

In 47455ca, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in f7ff634.

repo: glefait/martinique-public-websites


text:
🛑 Schoelcher is down

In dff2822, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 199e8c3.


text:
🛑 Le Robert is down

In 5d632e1, Le Robert (https://www.ville-robert.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Le Robert is back up in 88448e3 after 12 minutes.


text:
🛑 Schoelcher is down

In 83ac173, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 8a0e55b.


text:
🛑 Schoelcher is down

In b151a26, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in e802e7a.


text:
🛑 Schoelcher is down

In 0a4d341, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 0499166.


text:
🛑 Schoelcher is down

In 4109e6a, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in bfb7340.


text:
🛑 Schoelcher is down

In 1a65778, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 497e362.


text:
🛑 Schoelcher is down

In 37b4412, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 475e349.


text:
🛑 Schoelcher is down

In 2f0fbea, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in f72b0ef.


text:
Unhandled error while compiling all files. Error message: Cannot read property 'map' of undefined

Hi, i just installed the extension and when i click on watch sass here is the message i get.
Live Sass Compiler: Unhandled error while compiling all files. Error message: Cannot read property 'map' of undefined
any known fix ?

Sorry to hear you have had this problem.
Can you please follow the below steps? I can then find the problem and apply a fix.

Save all the files so you get the error notification pop up
Run liveSass.command.createIssue, this will copy some data into your clipboard
Ignore the pop-up (it's just a link to create a new issue, which isn't necessary)
Come back here and paste the info

Can I also see a screengrab of your folder structure and have a copy of your settings?

@TeKGameR950, did you get my last comment?

Closing as info required - with no reply


text:
Cannot read property 'number' of undefined

Installing this package as well as the collapsible dependency fails to run.
I tried adding either react-collapsible 1.3.0 or the latest.

Anyupdates on this?

Have the same issue

I found this answer https://stackoverflow.com/questions/47494375/react-responsive-accordion-getting-uncaught-typeerror-cannot-read-property
Maybe this helps

so I figured out a way to do it. I will try to create a pull request.
So there are actually two updates needed.

The update of the new prop type for higher react version. https://www.npmjs.com/package/prop-types

The update of react class. Read here for more info. https://teamtreehouse.com/community/i-get-this-error-react2defaultcreateclass-is-not-a-function-and-reactproptypes-is-undefined
and here is how you rewrite the code.

After these two updates and change the code according to the tutorial. My app worked. Note, I just downloaded the source file and edit the file my self.
So here are the steps for a fix for now:

npm install --save prop-types for the newest prop type

npm install create-react-class --save for the newest create class

download the accordion.js file in /src. and replace the imports and the first line to be.
`import React from 'react';
import Collapsible from 'react-collapsible';
import PropTypes from 'prop-types';
var createReactClass = require('create-react-class');

var Accordion = createReactClass({`

import the accordion.js file by import Accordion from './Accordion.js'

Use it like how the example uses it. That's it :D

Can we have a new bundled version published instead? The src code already uses the updated prop-types so we should just publish a new release to the registry to get this solved.

I had to also change all the React.PropTypes to jsut PropTypes in the Accordion.js file.  Also in the component I changed var ResponsiveAccord = React.createClass({  to a component class.
I use accordions often and this is the only one that simply handles nested accordions.  Is this still being maintained?

@NYCJacob since the last push to master was over 1 year ago, I think this is no longer relevant

authors: NYCJacob armand1m kailashvele noashka vaske vladnicula xiaofanwu


text:
Automatically open and close the signature window

Is your feature request related to a problem? Please describe.
Currently the signature window has to be triggered manually, which is a pain.
If not triggered manually e.g. using CompleteDone or CursorHold it will appear and disappear constantly which looks like a flicker and is annoying to try to read.
Whilst using coc or completion-nvim (historically) this would open at the right time and close at the right time without the user having to manage it or remembering to press it. Recently a plugin that implements this was created -> https://github.com/ray-x/lsp_signature.nvim. Unfortunately it doesn't integrate with lspsaga which I use for my other lsp related windows.
Describe the solution you'd like
It would be great to get similar functionality as that plugin provides natively in lspsaga. The code it uses is essentially cut out of completion.nvim which provides this functionality and I think can more or less copied and adapted here.
Describe alternatives you've considered
I considered using that plugin and that is still an option if it doesn't fit with lspsaga but that won't integrate with this plugin and would mean overriding if possible it's handling of the signature window. Also this isn't something that can be implemented elsewhere since nvim-compe will not support it and completion-nvim is defunct. But more importantly if it was implemented elsewhere the signature wouldn't match the rest of the lsp UI.

@akinsho  I had think about this. need talk with nvim-compe author. If it can provide a hook will be easy to do that.

relate https://github.com/hrsh7th/nvim-compe/issues/267

Any updates on this @glepnir?

Would really like seeing this implemented

Did anyone try:

install  both lspsaga and lsp_signature
hook the callback of signature help to lspsaga (not lsp_signature).
Insert your function
I think in this case it should show saga signature. The only thing I am not sure is will it be auto-close or not.

I managed to implement this by shamelessly borrowing some things from lsp_signature.nvim. I created a file called lspsaga_config.lua in my lua folder with the following code:
local M = {}

require('lspsaga').init_lsp_saga()

function M.check_trigger_char(line_to_cursor, trigger_character)
  if trigger_character == nil then
    return false
  end
  for _, ch in ipairs(trigger_character) do
    local current_char = string.sub(line_to_cursor, #line_to_cursor - #ch + 1, #line_to_cursor)
    if current_char == ch then
      return true
    end
    if current_char == " " and #line_to_cursor > #ch + 1 then
      local pre_char = string.sub(line_to_cursor, #line_to_cursor - #ch, #line_to_cursor - 1)
      if pre_char == ch then
        return true
      end
    end
  end
  return false
end

function M.lspsaga_open_signature_help()
	local clients = vim.lsp.buf_get_clients(0)
	if clients == nil or clients == {} then return end

	local triggered = false
	for _, client in pairs(clients) do
		local triggers = client.server_capabilities.signatureHelpProvider.triggerCharacters

		local pos = vim.api.nvim_win_get_cursor(0)
		local line = vim.api.nvim_get_current_line()
		local line_to_cursor = line:sub(1, pos[2])

		if triggered == false then
			triggered = M.check_trigger_char(line_to_cursor, triggers)
		end
	end

	if triggered then
		require('lspsaga.signaturehelp').signature_help()
	end
end

vim.cmd "augroup Signature"
vim.cmd "autocmd! * <buffer>"
vim.cmd "autocmd InsertCharPre * lua require'lspsaga_config'.lspsaga_open_signature_help()"
vim.cmd "augroup end"

return M

And then calling require('lspsaga_config') in my init.lua.
I'm still testing it out, but I could create a PR to implement this into the plugin itself if @glepnir's fine with it.

@matbme  I had to make a small change since I got an error that signatureHelpProvider was a nil value, but it works fine otherwise. I'd love for this to be merged into the plugin.

@matbme,
Thank you for the signature config. I got it to work yesterday, but I'm getting this error now.
Error detected while processing InsertCharPre Autocommands for "*":
E5108: Error executing lua /home/henri/.config/nvim/lua/lspsaga_config.lua:30: attempt to index field 'signatureHelpProvider' (a nil value)

Not sure if anyone experienced the same problem.

@Vanderscycle I was facing that error. I just had to check if signatureHelpProvider was nil.
Try this
function M.lspsaga_open_signature_help()
  local clients = vim.lsp.buf_get_clients(0)
  if clients == nil or clients == {} then
    return
  end

  local triggered = false
  for _, client in pairs(clients) do
    if (client.server_capabilities.signatureHelpProvider) then
      local triggers = client.server_capabilities.signatureHelpProvider.triggerCharacters

      local pos = vim.api.nvim_win_get_cursor(0)
      local line = vim.api.nvim_get_current_line()
      local line_to_cursor = line:sub(1, pos[2])

      if triggered == false then
        triggered = M.check_trigger_char(line_to_cursor, triggers)
      end
    end
  end

  if triggered then
    require('lspsaga.signaturehelp').signature_help()
  end
end

authors: MonstrousOgre Vanderscycle akinsho danielnehrig glepnir matbme ray-x seblj


text:
Bumblebee/Primusrun does not work on GLFW 3.3.9

On Debian 12, laptop with Intel and NVIDIA 4060 graphics cards, Bumblebee/Primusrun has previously worked. With the latest 3.3.9 build, primusrun does not work and the application still uses Intel graphics. Reverting to version 3.3.8 fixed the issue.
Attached is output of glxinfo. Please let me know if any further information would help.
glxinfo.txt

Could you provide some more information about how you are testing this (how you get & compile GLFW, what application are you running, have you tested with a GLFW example or test program, etc.)? See the contributing guide for more information on how to report a bug.

This may be caused by 3.3.9 having switched to preferring glvnd libGLX where available. There seem to be issues with the interaction between Bumblebee, glvnd and the closed-source Nvidia driver.

Hello Doug, here I will post all the relevant information to reproduce this. GLFW was built using the standard instructions from the website, with cmake and make.
OS: Debian 12
GPU: NVIDIA Geforce RTX 4060
GLFW version: bumblebee does not work on 3.3.9, works fine on 3.3.8 and earlier versions I tested by building.
Minimal program main.cu:
#include "imgui.h"
#include "imgui_impl_glfw.h"
#include "imgui_impl_opengl3.h"

#include <glad/glad.h>
#include <GLFW/glfw3.h>

#include <cuda_runtime.h>
#include <cuda_gl_interop.h>
#include <helper_functions.h>
#include <helper_cuda.h>
#include <vector_types.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <cstdio>
#include <string>
#include <fstream>
#include <sstream>
#include <iostream>

#define BLOCKDIM_X 16
#define BLOCKDIM_Y 16

#define WIDTH 800
#define HEIGHT 600

#define BUFFER_DATA(i) ((char *)0 + i)

class Shader
{
public:
    unsigned int ID;
    // constructor generates the shader on the fly
    // ------------------------------------------------------------------------
    Shader(const char* vertexPath, const char* fragmentPath)
    {
        // 1. retrieve the vertex/fragment source code from filePath
        std::string vertexCode;
        std::string fragmentCode;
        std::ifstream vShaderFile;
        std::ifstream fShaderFile;
        // ensure ifstream objects can throw exceptions:
        vShaderFile.exceptions (std::ifstream::failbit | std::ifstream::badbit);
        fShaderFile.exceptions (std::ifstream::failbit | std::ifstream::badbit);
        try
        {
            // open files
            vShaderFile.open(vertexPath);
            fShaderFile.open(fragmentPath);
            std::stringstream vShaderStream, fShaderStream;
            // read file's buffer contents into streams
            vShaderStream << vShaderFile.rdbuf();
            fShaderStream << fShaderFile.rdbuf();
            // close file handlers
            vShaderFile.close();
            fShaderFile.close();
            // convert stream into string
            vertexCode   = vShaderStream.str();
            fragmentCode = fShaderStream.str();
        }
        catch (std::ifstream::failure& e)
        {
            std::cout << "ERROR::SHADER::FILE_NOT_SUCCESSFULLY_READ: " << e.what() << std::endl;
        }
        const char* vShaderCode = vertexCode.c_str();
        const char * fShaderCode = fragmentCode.c_str();
        // 2. compile shaders
        unsigned int vertex, fragment;
        // vertex shader
        vertex = glCreateShader(GL_VERTEX_SHADER);
        glShaderSource(vertex, 1, &vShaderCode, NULL);
        glCompileShader(vertex);
        checkCompileErrors(vertex, "VERTEX");
        // fragment Shader
        fragment = glCreateShader(GL_FRAGMENT_SHADER);
        glShaderSource(fragment, 1, &fShaderCode, NULL);
        glCompileShader(fragment);
        checkCompileErrors(fragment, "FRAGMENT");
        // shader Program
        ID = glCreateProgram();
        glAttachShader(ID, vertex);
        glAttachShader(ID, fragment);
        glLinkProgram(ID);
        checkCompileErrors(ID, "PROGRAM");
        // delete the shaders as they're linked into our program now and no longer necessary
        glDeleteShader(vertex);
        glDeleteShader(fragment);
    }
    // activate the shader
    // ------------------------------------------------------------------------
    void use()
    {
        glUseProgram(ID);
    }
    // utility uniform functions
    // ------------------------------------------------------------------------
    void setBool(const std::string &name, bool value) const
    {
        glUniform1i(glGetUniformLocation(ID, name.c_str()), (int)value);
    }
    // ------------------------------------------------------------------------
    void setInt(const std::string &name, int value) const
    {
        glUniform1i(glGetUniformLocation(ID, name.c_str()), value);
    }
    // ------------------------------------------------------------------------
    void setFloat(const std::string &name, float value) const
    {
        glUniform1f(glGetUniformLocation(ID, name.c_str()), value);
    }

private:
    // utility function for checking shader compilation/linking errors.
    // ------------------------------------------------------------------------
    void checkCompileErrors(unsigned int shader, std::string type)
    {
        int success;
        char infoLog[1024];
        if (type != "PROGRAM")
        {
            glGetShaderiv(shader, GL_COMPILE_STATUS, &success);
            if (!success)
            {
                glGetShaderInfoLog(shader, 1024, NULL, infoLog);
                std::cout << "ERROR::SHADER_COMPILATION_ERROR of type: " << type << "\n" << infoLog << "\n -- --------------------------------------------------- -- " << std::endl;
            }
        }
        else
        {
            glGetProgramiv(shader, GL_LINK_STATUS, &success);
            if (!success)
            {
                glGetProgramInfoLog(shader, 1024, NULL, infoLog);
                std::cout << "ERROR::PROGRAM_LINKING_ERROR of type: " << type << "\n" << infoLog << "\n -- --------------------------------------------------- -- " << std::endl;
            }
        }
    }
};

__global__ void kernel(unsigned char *dst, const int gridWidth, const int numBlocks) {
  // loop until all blocks completed
  for (unsigned int blockIndex = blockIdx.x; blockIndex < numBlocks; blockIndex += gridDim.x) {
    const unsigned int blockX = blockIndex % gridWidth;
    const unsigned int blockY = blockIndex / gridWidth;

    // process this block
    const int ix = blockDim.x * blockX + threadIdx.x;
    const int iy = blockDim.y * blockY + threadIdx.y;

    if ((ix < WIDTH) && (iy < HEIGHT)) {
      int idx = (WIDTH * iy + ix)* 4;
      dst[idx + 0] = ix % 255;
      dst[idx + 1] = iy % 255;
      dst[idx + 2] = 0;
    }
  }
}

// Increase the grid size by 1 if the image width or height does not divide
// evenly by the thread block dimensions
inline int iDivUp(int a, int b) {
  return ((a % b) != 0) ? (a / b + 1) : (a / b);
}

extern "C" void thread_spawner(unsigned char *dst, const int numSMs) {
  dim3 threads(BLOCKDIM_X, BLOCKDIM_Y);
  dim3 grid(iDivUp(WIDTH, BLOCKDIM_X), iDivUp(HEIGHT, BLOCKDIM_Y));

  const int numWorkerBlocks = numSMs;
  kernel<<<numWorkerBlocks, threads>>>(dst, grid.x, grid.x * grid.y);

  getLastCudaError("Mandelbrot0 kernel execution failed.\n");
}

// process all input: query GLFW whether relevant keys are pressed/released this frame and react accordingly
// ---------------------------------------------------------------------------------------------------------
void processInput(GLFWwindow *window)
{
    if (glfwGetKey(window, GLFW_KEY_Q) == GLFW_PRESS)
        glfwSetWindowShouldClose(window, true);
}

// glfw: whenever the window size changed (by OS or user resize) this callback function executes
// ---------------------------------------------------------------------------------------------
void framebuffer_size_callback(GLFWwindow* window, int width, int height)
{
    // // from GLUT:
    // glViewport(0, 0, w, h);
    // glMatrixMode(GL_MODELVIEW);
    // glLoadIdentity();
    // glMatrixMode(GL_PROJECTION);
    // glLoadIdentity();
    // glOrtho(0.0, 1.0, 0.0, 1.0, 0.0, 1.0);
    // // Do not call when window is minimized that is when
    // // width && height == 0
    // if (w != 0 && h != 0) initOpenGLBuffers(w, h);
    // glutPostRedisplay();

    // make sure the viewport matches the new window dimensions; note that width and
    // height will be significantly larger than specified on retina displays.
    glViewport(0, 0, width, height);
}

static void glfw_error_callback(int error, const char* description)
{
    fprintf(stderr, "GLFW Error %d: %s\n", error, description);
}

// settings
const unsigned int SCR_WIDTH = 800;
const unsigned int SCR_HEIGHT = 600;

int main()
{
    // GLFW
    if (!glfwInit()) return 1;
    GLFWwindow* window = glfwCreateWindow(SCR_WIDTH, SCR_HEIGHT, "soy", NULL, NULL);
    if (!window) { glfwTerminate(); return -1;}
    glfwMakeContextCurrent(window);
    glfwSetErrorCallback(glfw_error_callback);
    glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);
    // glfwSwapInterval(1); // Enable vsync

    // IMGUI
    const char* glsl_version = "#version 130";
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
    IMGUI_CHECKVERSION();
    ImGui::CreateContext();
    ImGuiIO& io = ImGui::GetIO(); (void)io;
    io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard;     // Enable Keyboard Controls
    io.ConfigFlags |= ImGuiConfigFlags_NavEnableGamepad;      // Enable Gamepad Controls
    ImGui::StyleColorsDark();
    ImGui_ImplGlfw_InitForOpenGL(window, true);
    ImGui_ImplOpenGL3_Init(glsl_version);

    // glad: load all OpenGL function pointers
    // ---------------------------------------
    if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))
    {
        std::cout << "Failed to initialize GLAD" << std::endl;
        return -1;
    }

    // build and compile our shader zprogram
    // ------------------------------------
    Shader ourShader("4.1.texture.vs", "4.1.texture.fs");

    // set up vertex data (and buffer(s)) and configure vertex attributes
    // ------------------------------------------------------------------
    float vertices[] = {
        // positions         // texture coords
         1.0f,  1.0f, 0.0f,  1.0f, 1.0f, // top right
         1.0f, -1.0f, 0.0f,  1.0f, 0.0f, // bottom right
        -1.0f, -1.0f, 0.0f,  0.0f, 0.0f, // bottom left
        -1.0f,  1.0f, 0.0f,  0.0f, 1.0f  // top left
    };
    unsigned int indices[] = {
        0, 1, 3, // first triangle
        1, 2, 3  // second triangle
    };
    unsigned int VBO, VAO, EBO;
    glGenVertexArrays(1, &VAO);
    glGenBuffers(1, &VBO);
    glGenBuffers(1, &EBO);

    glBindVertexArray(VAO);

    glBindBuffer(GL_ARRAY_BUFFER, VBO);
    glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);

    // position attribute
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 5 * sizeof(float), (void*)0);
    glEnableVertexAttribArray(0);
    // texture coord attribute
    glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, 5 * sizeof(float), (void*)(3 * sizeof(float)));
    glEnableVertexAttribArray(1);

    setenv("DISPLAY", ":0", 0);
    cudaDeviceProp deviceProp;
    checkCudaErrors(cudaGetDeviceProperties(&deviceProp, 0));
    int numSMs = deviceProp.multiProcessorCount; // number of multiprocessors
    std::cout << "num SMs:" << numSMs << std::endl;

    // create GL texture
    GLuint gl_Tex, gl_PBO; // OpenGL PBO and texture "names"
    struct cudaGraphicsResource *cuda_pbo_resource;  // handles OpenGL-CUDA exchange
    unsigned char *d_dst = NULL;  // Destination image on the GPU side
    glEnable(GL_TEXTURE_2D);
    glGenTextures(1, &gl_Tex);
    glBindTexture(GL_TEXTURE_2D, gl_Tex); // all upcoming GL_TEXTURE_2D operations now have effect on this texture object
    // set the texture wrapping parameters
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);	// set texture wrapping to GL_REPEAT (default wrapping method)
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
    // set texture filtering parameters
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    unsigned char* h_Src = (unsigned char*)malloc(SCR_WIDTH * SCR_HEIGHT * 4 * sizeof(unsigned char)); // Source image on the host side
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, SCR_WIDTH, SCR_HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, h_Src);

    // create PBO
    glGenBuffers(1, &gl_PBO);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, gl_PBO);
    glBufferData(GL_PIXEL_UNPACK_BUFFER, WIDTH * HEIGHT * 4, h_Src, GL_STREAM_COPY);
    // While a PBO is registered to CUDA, it can't be used
    // as the destination for OpenGL drawing calls.
    // But in our particular case OpenGL is only used
    // to display the content of the PBO, specified by CUDA kernels,
    // so we need to register/unregister it only once.
    checkCudaErrors(cudaGraphicsGLRegisterBuffer(&cuda_pbo_resource, gl_PBO, cudaGraphicsMapFlagsWriteDiscard));

    printf("OpenGL Version: %s\n", glGetString(GL_VERSION));
    printf("OpenGL Renderer: %s\n", glGetString(GL_RENDERER));
    printf("OpenGL Vendor: %s\n", glGetString(GL_VENDOR));
    printf("GLSL Version: %s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));

    ourShader.use();
    glBindVertexArray(VAO);

    while (!glfwWindowShouldClose(window))
    {
        // CUDA rendering
        checkCudaErrors(cudaGraphicsMapResources(1, &cuda_pbo_resource, 0));
        size_t num_bytes;
        checkCudaErrors(cudaGraphicsResourceGetMappedPointer((void **)&d_dst, &num_bytes, cuda_pbo_resource));
        thread_spawner(d_dst, numSMs);
        checkCudaErrors(cudaGraphicsUnmapResources(1, &cuda_pbo_resource, 0));
        // load texture from PBO
        glBindBuffer(GL_PIXEL_UNPACK_BUFFER, gl_PBO);
        glBindTexture(GL_TEXTURE_2D, gl_Tex);
        glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, WIDTH, HEIGHT, GL_RGBA, GL_UNSIGNED_BYTE, BUFFER_DATA(0));
        glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);

        // OpenGL triangles
        glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);

        // Start the Dear ImGui frame
        ImGui_ImplOpenGL3_NewFrame();
        ImGui_ImplGlfw_NewFrame();
        ImGui::NewFrame();
        static bool myCheckbox = false;
        ImGui::Checkbox("Check me!", &myCheckbox);
        // Rendering
        ImGui::Render();
        int display_w, display_h;
        glfwGetFramebufferSize(window, &display_w, &display_h);
        glViewport(0, 0, display_w, display_h);
        ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());

        // glfw: swap buffers and poll IO events (keys pressed/released, mouse moved etc.)
        // -------------------------------------------------------------------------------
        processInput(window);
        glfwSwapBuffers(window);
        glfwPollEvents();
    }

    if (h_Src) {
        free(h_Src);
        h_Src = 0;
    }
    if (gl_Tex) {
        glDeleteTextures(1, &gl_Tex);
        gl_Tex = 0;
    }
    if (gl_PBO) {
        checkCudaErrors(cudaGraphicsUnregisterResource(cuda_pbo_resource));
        glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
        glDeleteBuffers(1, &gl_PBO);
        gl_PBO = 0;
    }

    glDeleteVertexArrays(1, &VAO);
    glDeleteBuffers(1, &VBO);
    glDeleteBuffers(1, &EBO);
    ImGui_ImplOpenGL3_Shutdown();
    ImGui_ImplGlfw_Shutdown();
    ImGui::DestroyContext();
    glfwDestroyWindow(window);
    glfwTerminate();
    return 0;
}

shaders: 4.1.texture.fs:
#version 330 core
out vec4 FragColor;

in vec2 TexCoord;

// texture sampler
uniform sampler2D texture1;

void main()
{
	FragColor = texture(texture1, TexCoord);
}

shader: 4.1.texture.vs:
#version 330 core
layout (location = 0) in vec3 aPos;
layout (location = 1) in vec2 aTexCoord;

out vec2 TexCoord;

void main()
{
	gl_Position = vec4(aPos, 1.0);
	TexCoord = vec2(aTexCoord.x, aTexCoord.y);
}

makefile:

NVCC          := /usr/local/cuda/bin/nvcc -ccbin g++

ALL_CCFLAGS := -m64 # add -g -G for debug here
ALL_LDFLAGS := $(ALL_CCFLAGS)
ALL_CCFLAGS += --threads 0 --std=c++11

# Common includes and paths for CUDA
INCLUDES  := -I/home/chad/Desktop/_backups/notes/.ignore/cuda-samples-12.3/Common # cuda toolkit samples common
INCLUDES  += -Iusr/lib/x86_64-linux-gnu
INCLUDES  += -I../Common/vendor -I../Common/vendor/imgui
LIBRARIES := -L/usr/lib64/nvidia
LIBRARIES += -L../Common/lib
LIBRARIES += -lX11 -lXrandr -lXinerama -lXcursor -lXi -lXxf86vm -lGL -lglfw3 # -lGLU

# Gencode arguments
SMS ?= 50 52 60 61 70 75 80 86 89 90
# Generate SASS code for each SM architecture listed in $(SMS)
$(foreach sm,$(SMS),$(eval GENCODE_FLAGS += -gencode arch=compute_$(sm),code=sm_$(sm)))
# Generate PTX code from the highest SM architecture in $(SMS) to guarantee forward-compatibility
HIGHEST_SM := 90
GENCODE_FLAGS += -gencode arch=compute_$(HIGHEST_SM),code=compute_$(HIGHEST_SM)

# Define OBJ Directory
OBJ_DIR := ../Common/obj

# # ImGui source files
IMGUI_DIR := ../Common/vendor/imgui
IMGUI_SOURCES := $(IMGUI_DIR)/imgui.cpp $(IMGUI_DIR)/imgui_demo.cpp $(IMGUI_DIR)/imgui_draw.cpp $(IMGUI_DIR)/imgui_tables.cpp
IMGUI_SOURCES += $(IMGUI_DIR)/imgui_widgets.cpp $(IMGUI_DIR)/imgui_impl_glfw.cpp $(IMGUI_DIR)/imgui_impl_opengl3.cpp

# Convert .cpp files in IMGUI_SOURCES to .o files in OBJ_DIR
IMGUI_OBJECTS := $(patsubst $(IMGUI_DIR)/%.cpp,$(OBJ_DIR)/%.o,$(IMGUI_SOURCES))

all: main

$(OBJ_DIR)/glad.o: ../Common/vendor/glad/glad.c
	$(EXEC) $(NVCC) $(INCLUDES) $(ALL_CCFLAGS) $(GENCODE_FLAGS) -o $@ -c $<

# for ImGui
$(OBJ_DIR)/%.o: $(IMGUI_DIR)/%.cpp | $(OBJ_DIR)
	$(EXEC) $(NVCC) $(INCLUDES) $(ALL_CCFLAGS) $(GENCODE_FLAGS) -o $@ -c $<

main.o: main.cu
	$(EXEC) $(NVCC) $(INCLUDES) $(ALL_CCFLAGS) $(GENCODE_FLAGS) -o $@ -c $<

main: main.o ../Common/obj/glad.o $(IMGUI_OBJECTS)
	$(EXEC) $(NVCC) $(ALL_LDFLAGS) $(GENCODE_FLAGS) -o $@ $+ $(LIBRARIES)
	rm -f *.o

run: main
	$(EXEC) primusrun ./main

nvidia-smi:
Mon Jan  8 15:23:35 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 4060 ...    On  | 00000000:01:00.0 Off |                  N/A |
| N/A   42C    P3             588W /  35W |      2MiB /  8188MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

authors: ConsciousMachines dougbinks elmindreda

repo: glfw/glfw

license: Zlib


text:
Workaround for EL7 PyJWT generating bytes instead of str

There is a bug in older PyJWT versions, like the one in EL7. jwt.encode() is returning bytes instead of str.
Here I'm adding a workaround to protect against it and work with both new and older versions of PyJWT
Here is the PyJWT issue: https://github.com/jpadilla/pyjwt/issues/391
This was fixed in PyJWT v2.0.0, https://github.com/jpadilla/pyjwt/pull/513

To Patch an existing EL7 installation, replace /usr/lib/python3.6/site-packages/glideinwms/lib/token_util.py  with the one form this PR,  https://raw.githubusercontent.com/mambelli/glideinwms/v310/pyjwt_encode_bug_workaround/lib/token_util.py and restart the Frontend with systemctl restart gwms-frontend

repo: glideinWMS/glideinwms


text:
Cannot register services within the same docker network only

What version of docker are you running?
18.09.6, build 481bc77
What version of registrator are you running?
v7
Did you build a custom version of registrator? If so, what is that image?
No
What is the exact command you are running registrator with?

registrator -internal \
    -retry-attemps=10 \
    -retry-interval=1000 \
    consul://consul-ip:8500

What is the exact command you are running your container with?

docker run -d --rm \
    -v /var/run/docker.sock:/tmp/docker.sock \
    --network my_net_1
    gliderlabs/registrator:v7 -internal \
               -retry-attempts=10 \
               -retry-interval=1000 \
               consul://consul-ip:8500 \

Description of the problem:

When I run 2 registrator containers in different docker network, a registrator process will detect and register a service from another network.

Steps to Reproduce:

Run 2 registrator containers in different docker network, along with 2 different consul-server in each. Start a flask or redis service and check consul server at v1/catalog/service/redis

Actual Results:
The redis record is available in both consul instances.
Expected Results:
The redis record only appears in the consul server under the same docker network
I'm not sure if that's the intended way of using registrator, but if someone can help me with this, or show me a workaround for this issue I'd really appreciate

I modified registrator a bit to work as I want. If anyone's interested you can see this version
https://github.com/trungams/registrator/commit/959e5d69f9fb4e16457bbcd0c22f99792a14fae2

repo: gliderlabs/registrator


text:
Python 3.7 support

Now that opencv-python supports Python 3.7, we should add it to the appveyor/travis config for test cases.

Merged with v0.7.3.

repo: glitchassassin/lackey


text:
🛑 Redmine is down

In f30f701, Redmine ($SITE_3) was down:

HTTP code: 503
Response time: 327 ms

Resolved: Redmine is back up in 8b66e59.

repo: glo-markoaular/status-navigate


text:
Unsupported rules: additionalRules

When my repo is open (https://github.com/zaggino/brackets-git) I get a lot of these errors:
JSCS failed to initialize: Error: Unsupported rules: additionalRules, forbiddenFunctions main.js:58
JSCS failed to initialize: Error: Unsupported rules: additionalRules, forbiddenFunctions main.js:58
JSCS failed to initialize: Error: Unsupported rules: additionalRules, forbiddenFunctions main.js:58
JSCS failed to initialize: Error: Unsupported rules: additionalRules, forbiddenFunctions main.js:58

The latest 0.6.0 release should fix this. However, note that 0.6.0 requires that you have JSCS installed globally via:
npm install -g  jscs

authors: globexdesigns zaggino

repo: globexdesigns/brackets-jscs


text:
Application error

erroe message
web
Application error
Rails application failed to start properly
It was along the same error occurs.
Please contact what to proceed with the installation again in any part .
help...

@moondal can you please provide more information? (Such as the steps to reproduce, stack trace).

hi If you proceed with the test it does not respond .  this is "httpd.conf" <VirtualHost *:80>    ServerName ansible0101    DocumentRoot /home/globodns/globodns/public    <Directory /home/globodns/globodns/public>      AllowOverride all      Options -MultiViews
------ Original Message ------
Date: Thursday, Apr 21, 2016 03:21:40 AM
From: "Marcelo Boeira" notifications@github.com
To: "globocom/GloboDNS" GloboDNS@noreply.github.com
Cc: "moondal" mdhzzangu@nate.com, "Mention" mention@noreply.github.com
Subject: Re: [globocom/GloboDNS] Application error (#9)
@moondal can you please provide more information? (Such as the steps to reproduce, stack trace).
—You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

httpd error log is
(2)No such file or directory: exec of '/home/globodns/globodns/public/dispatch.cgi' failed
Premature end of script headers: dispatch.cgi

Have you followed all steps in https://github.com/globocom/GloboDNS/blob/master/doc/setup.md ?
I guess you are only using apache to run the application. This doesn't work. You'll need to run an application server such as unicorn (recommended) or passenger.
Your VHost should look like this:
<VirtualHost *:80>
    ServerName yourdomain.example

    # Tell Apache and Passenger where your app's 'public' directory is
    DocumentRoot /path-to-your-application/public

    RewriteEngine On

    <Proxy balancer://unicornservers>
      BalancerMember http://127.0.0.1:8080
    </Proxy>
    # Redirect all non-static requests to thin
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ balancer://unicornservers%{REQUEST_URI} [P,QSA,L]

   # NOTE Uncomment if you want Unicorn to serve static content
   # ProxyPass / balancer://unicornservers/
   # ProxyPassReverse / balancer://unicornservers/
   # ProxyPreserveHost on

    <Proxy *>
      Order deny,allow
      Allow from all
    </Proxy>

</VirtualHost>

@moondal it worked?

authors: anacarolinacastro ernestothorp marceloboeira moondal

repo: globocom/GloboDNS


text:
Source.text is naïve and not configurable

The conversion method to string uses the text method from clldutils. That method is quite naïve and not extensible, and it makes sense that it is like that. However, here https://github.com/glottobank/pycldf/blob/aef54564b980006222e8814266ecf46cec680668/pycldf/sources.py#L36
we have already imported pybtex, and if I understand its docs correctly, there is some way to use that package to nicely format bib entries.
I don't understand how to do it, but I would suggest that pycldf.sources.Source should overload the text method, giving it an optional argument which is some description of a bibliography style and formatting this source accordingly.

The text serialization of BibTeX records implemented in clldutils is supposed to follow the rules proposed by @haspelmath here https://www.frank-m-richter.de/freescienceblog/2015/03/18/how-to-make-linguistics-publication-more-efficient-use-discipline-wide-style-rules/
You are right that once pybtex is in the picture, formatting according to any BibTeX style is possible. But I'm not really sure this is something either pycldf or clld should provide support for. I rather hope, people use tools like Zotero, which will give them access to even more formatting styles, not limited to what's implemented for BibTeX.

(1) There is a Bib style for the “Unified Style Sheet for Linguistics”, which should then be the default value for that optional argument.
(2) I may want to fiddle with the bibstyle to make it (not some other piece of the chain, because it's fine for everything else) deal with sources of the “fieldnotes” genre. This is more transparent with an explicit style (which would even inherit most of its formatting from the ussl) than with overloading a method.

I don't really understand where exactly you'd want to serialize BibTeX records differently. Is this within a pure python toolchain, without the option to "shell out" to Zotero for custom serialization? I'm a bit worried by functionality which depends on both

BibTeX style files and
pybtex

because for both it's somewhat unclear how long they will be around - and re-implementing any of what they do now is clearly out of scope for pycldf.

I working on the CLDF-to-CLLD import for lexirumah.
I think that an object like Keraf, 1978 or Holton, 2010: Kiraman should display its reference in the usual human-readable format, following USSL.
I am happy to use any reasonable way to do it. Given that you say BibTeX+pybtex is not reasonable, I'm happy to not use that. I am not sure whether
Choi, Hannah. 2015. Field notes on Sawila. https://hdl.handle.net/1839/00-0000-0000-001E-2E27-4@view (The Language Archive). (Accessed on 2017-11-01)
is actually a good specification for field notes available through TLA (that one isn't yet, the link leads somewhere else).
I would much prefer if

the URL was stored somewhere explicitly, without noise; in the example above,  (The Language Archive) would be part of the howpublished field, other solutions would need tricksing with other fields not meant to contain URLs.
there was some space to list some other data points. I will look for existing standards and talk to people to see what's actually useful here. But I might like to specify the lects concerned or people involved (informants, transcribers or such) – the former could go into the (sub)title, fair enough, but in my very personal and not well-founded opinion the people involved deserve credit and should get that in a similar fashion to authors, editors and translators.

I will use the existing .text() for now, because some of the ideas I have cannot be fulfilled by our current state of bibliography anyway. But I intend to come back to this to resolve this one way another.

Ok. I see. But this use case would be better addressed by fleshing out the USSL support in clldutils, because it seems you'd only need to override to add "better" formatting, not to provide alternative formatting, right?

In principle yes – Would you not consider it an issue then that the clldutils implementation of USSL will behave differently for those items than other implementations?

Which other implementations?
Am 01.11.2017 17:31 schrieb "Gereon Kaiping" notifications@github.com:

In principle yes – Would you not consider it an issue then that the
clldutils implementation of USSL will behave differently for those items
than other implementations?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/glottobank/pycldf/issues/47#issuecomment-341160286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA1HKEp1z_64kLdd1DdYAUcdrc3pFdqyks5syJzLgaJpZM4QN8I2
.

https://www.linguisticsociety.org/celxj has the Bibstyle linked above and a CSL version for Zotero etc.

I see. But why would your desired behaviour differ? I assumed clldutils was
just incomplete for most entry types.
Am 01.11.2017 17:34 schrieb "Gereon Kaiping" notifications@github.com:
https://www.linguisticsociety.org/celxj has the Bibstyle linked above and a
CSL version for Zotero etc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/glottobank/pycldf/issues/47#issuecomment-341161330,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA1HKEfg3asDe1X0nlkcHnfKJoqiov2Vks5syJ2SgaJpZM4QN8I2
.

@Anaphory I think it would make more sense to add this functionality to clldutils, directly - even if this means adding pybtex as dependency. After all, the Unified Style Sheet is something specific to Linguistics, and clldutils is supposed to provide python utils for Linguistics.

@Anaphory Just tried to replace Source.text with the output of pybtex run with unified.bst. Unfortunately the result is not simply a string linearization of the citation, but a full-blown LaTeX bibliography:
E           AssertionError: assert '\\begin{theb...bliography}\n' == 'Dayley, Jon P...fornia Press.'
E             + Dayley, Jon P. 1985. Tzutujil Grammar. (University of California Publications in Linguistics, 107.) Berkeley: University of California Press.
E             - \begin{thebibliography}{1}
E             - \providecommand{\natexlab}[1]{#1}
E             - \providecommand{\url}[1]{#1}
E             - \providecommand{\urlprefix}{}
E             - \expandafter\ifx\csname urlstyle\endcsname\relax
E             -   \providecommand{\doi}[1]{doi:\discretionary{}{}{}#1}\else
E             -   \providecommand{\doi}{doi:\discretionary{}{}{}\begingroup
E             -   \urlstyle{rm}\Url}\fi
E             -
E             - \bibitem[{Dayley(1985)}]{Dayley-1985}
E             - Dayley, Jon~P. 1985.
E             - \newblock \emph{Tzutujil grammar}, vol. 107 University of California
E             -   Publications in Linguistics.
E             - \newblock Berkeley: University of California Press.
E             -
E             - \end{thebibliography}

So using pybtex would require postprocessing its output, which I'd consider out-of-scope for both, pycldf and clldutils.

Makes sense!

authors: Anaphory xrotwang

repo: glottobank/pycldf


text:
fix f64 eq

see https://rust-lang.github.io/rust-clippy/master/#float_cmp

Codecov Report

Merging #585 (d7da07d) into main (232fcc0) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #585   +/-   ##
=======================================
  Coverage   93.61%   93.61%
=======================================
  Files         178      178
  Lines       12293    12293
=======================================
  Hits        11508    11508
  Misses        785      785

Impacted Files
Coverage Δ

core/src/data/value/binary_op/f64.rs
97.66% <100.00%> (ø)

core/src/data/value/binary_op/i64.rs
95.01% <100.00%> (ø)

core/src/data/value/binary_op/i8.rs
96.03% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 232fcc0...d7da07d. Read the comment docs.

authors: codecov-commenter earney

repo: gluesql/gluesql


text:
@gluestack-style/animation-plugin@0.1.12  cause Error: Check the render method of Styled(Component)

Description
@gluestack-style/animation-plugin@0.1.12  cause Error: Element type is invalid: expected a string ... Check the render method of Styled(Component)
CodeSandbox/Snack link
No response
Steps to reproduce
yarn install @gluestack-style/animation-plugin@latest
yarn start --web
Failed to start web app in chrome.
Error: Element type is invalid: expected a string ... Check the render method of Styled(Component) when using Image component
Roll back to 0.1.7, everything return to ok immediately.
gluestack-ui Version
animation-plugin@0.1.12
Platform

[X] Expo
[ ] React Native CLI
[X] Next
[ ] Web
[ ] Android
[ ] iOS

Other Platform
No response
Additional Information
Failed to start web app in chrome.
version snapshot

Thanks for reporting. We will fix this on priority.

Hey @jasonz1360, Please can you please try with our new version of @gluestack-ui/themed and @gluestack-style/react.
Also we have deprecated @gluestack-style/animation-plugin. for more info please refer this following docs link:

https://gluestack.io/style/docs/plugins/animation-plugin.
https://gluestack.io/ui/docs/advanced/animations.

repo: gluestack/gluestack-ui


text:
Unpacking equations term by term

@jkingslake
Plotting equations term by term yields these initial plots:
Initial steady state condition:

Final steady state after perturbation to A leading to retreat of grounding line:

Plotting initial and final against each other (legends are a bit messy, need to think of how to better display):

This plot below shows how the advection term is largely ineffective until near the terminus.

I think the most interesting plot here is how the dN/dx term and the effective pressure interact to balance to define the f(Q,S) term

OK, nice. Are all these dimensional variables?
I see a bit of a blip at the place the ice-flow grid changes. Any ideas what is causing that?
Agreed the bottom-left plots are really interesting.

Yeah these variables are dimensional. I'm trying to think of how to best label the y axis - should I just use the units for the equations?
The blip I believe is due to errors coming from interpolating grids and also taking the gradient of the grids. Here is grad(x):

Here is grad(hu):

Using 10% of the grid being at a finer resolution (with 300 data points in the fine domain, 100 data points in coarse domain). We can see that the overall shapes of the curves remain the same whilst the interpolation errors move further up the glacier. There is some weird oscillations in the bottom left plot - I think these are some artifacts coming out of the solver, which solved "with potential inaccuracies". Will continue trying additional simulations at finer resolutions

How long did the simulation take?

This one with 900 grid points (800 on fine resolution for 25% of the grid) took 77 minutes. Overall it has the same observed behavior as the other resolution simulations, except the advection term effect becomes even smaller. I'd trust this one more than my initial run of 100 on fine resolution for 3% (even though the resolution becomes a bit worse in fine domain for this new one) because in that first run, the discontinuity happens right in the same area where the advection term becomes important

Looks good. I think the final versions of these runs may need to use a uniform resolution. This blip at the junction between the two gross is not very satisfactory.  But continue using a lower resolution for now and then increase later for the final versions. Also it will be important to do that convergence analysis we have talked about, where you record some metric of the model (like GL position) for many simulations using increasingly fine resolution.
Do you have the accompanying plot of the variables for this simulation?

I think it could be useful for the discussion to describe three or four different regions, based on what the dominant terms are.

Here are variables for this simulation. And sure, I can do this convergence analysis with the steady state solutions. Yeah, the change between the two grids is pretty annoying, and I think it's mostly in instances where we have grad(variable)/grad(grid) for the term. I'll try playing around with ways of getting rid of this blip
I'll also try to describe these regions

authors: glugeorge jkingslake


text:
🛑 入口網站 is down

In 702bbbb, 入口網站 (https://nportal.ntut.edu.tw/index.do) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 入口網站 is back up in 39996bf.

repo: gnehs/ntut-uptime


text:
fix: PropertiesPanel.setWidth and Height not allowing negative values

we can now set width and height to negative values from properties Panel
refactored the ugly Gizmo.canflip style of preventing shape flip
refactored PanelProperties.updateDisplay
refactored selectTools.selectShapesUnderRectangle to use overlayLayout to draw rectangle as opposed using div and html body

The features were already accepted in another PR.


text:
Feature/1.1.0 final release changes

Added space b/w Num and TokenName in last modal confirmation
Added Gas_Station links in Globals
Added store to check network in estimateGas + dynamic URL + clean

Travis automatic deployment:
https://pr392--dxreact.review.gnosisdev.com

Travis automatic deployment:
https://pr392--dxreact.review.gnosisdev.com

repo: gnosis/dx-react