Problems Syncing with Blueretro Module

Trying to sync with Nintendo Switch and PC work fine, but trying to sync with bluetooth modules that require holding the sync button while turning on the controller do not work. For example, when trying to connect to a blueretro module such as this one (https://www.amazon.com/gp/product/B0BTLVLV4W/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1) I cannot get it to connect. The instructions on the module say to hold the sync button (which works on my other switch controllers) or to reprogram the bluetooth address using a computer for other controllers (such as the PS3).
What would be the best way to connect this controller via bluetooth to the blueretro module if it asks to hold the sync button? Or is there a way to manually type in a bluetooth mac address?

Hey, just got one built. The Pico seems to attempt to auto sync with a BlueRetro without a button when powered on, causing the BlueRetro device to stop blinking it's blue LED, however after a few seconds the Pico seemingly automatically disconnects, and the BlueRetro device resumes blinking. The Pico works with my switch and the BlueRetro works with other controllers, but not with each other unfortunately. Hopefully there will be an update to have it work.

Hi! Could you solve the compatibility between BlueRetro and this project?

Hey, just got one built. The Pico seems to attempt to auto sync with a BlueRetro without a button when powered on, causing the BlueRetro device to stop blinking it's blue LED, however after a few seconds the Pico seemingly automatically disconnects, and the BlueRetro device resumes blinking. The Pico works with my switch and the BlueRetro works with other controllers, but not with each other unfortunately.

what firmwares are you guys using? My picos just brick for any FW after the initial one.


Non-existent import in transpiled source

Summary

Version
8.0.0 & <= 8

Affected OS
All

OS Version
-

Current behavior
When trying to use rollup, because of some wrong imports and exports the file lib/module/
internal/nativeInterface throws an error in the AsyncHookResult because this is a type and not a function or object.
Non-existent export 'AsyncHookResult' is imported from ../../../node_modules/react-native-device-info/lib/module/internal/types.js5: import RNDeviceInfo from './internal/nativeInterface';
Expected behavior
The transpiled source should not contains imports and exports that results in errors.
Wrong line codes:
lib/module/index.js -> Lines 7 and 701
import { AsyncHookResult, DeviceType, LocationProviderInfo, PowerState } from './internal/types';

export { AsyncHookResult, DeviceType, LocationProviderInfo, PowerState };

Interesting... Could you propose a PR that corrects it for you?

Interesting... Could you propose a PR that corrects it for you?

@mikehardy this is the fix for the issue -> https://github.com/react-native-device-info/react-native-device-info/pull/1164

@mikehardy this is the fix for the issue -> https://github.com/react-native-device-info/react-native-device-info/pull/1164


Invalid SubmodelElement Entity in GUI for AAS-Metamodel Version 2

When I add the Bill of Material Submodel to my AAS and want to display the submodel in the GUI, the GUI says "Invalid SubmodelElement!"

Test_AAS.json
docker-image: eclipsebasyx/aas-gui:v230703
docker-compose: https://github.com/eclipse-basyx/basyx-java-examples/tree/main/basyx.docker/simple-deployment-with-gui

This is the expected behaviour of the AAS Web UI in the Basyx V1 version. The Entity-SubmodelElement wasn't implemented there. The newest version of the UI for BaSyx V2 includes the Entity-Element. For a list of supported SubmodelElements for the old version of the UI, hover over the (i) underneath the Invalid SubmodelElement warning.


Support for generate function's json object

For using func_call, hoping there is a parse tool to genenrate a json object of funtion's description. Like that:

Write an utils function with docstring

def foo(a: str, b: int = 0) -> None:
    """"
    Description for funcion

    Args:
        a(str): argument a
        b(int): argument b
    """"

Parse the foo

from openai.xxx import parse

parse(foo)

will get the output
{
  "type": "function",
  "function": {
     "name": "foo",
     "description": "Description for funcion",
     "parameters": {
        "type": "object",
        "properties": {
           "a": {"type": "str", "description": "argument a"},
           "b": {"type": "int", "description": "argument b"},
         },
         "required": ["a"],
      },
    },
}

Maybe can use the inspect to get the argmument name and annotions, use func.__doc__ and re to extract the descriptions of function and argmuents, or even call GPT to do that.
If this is ok, mayby I could try to do it.

@Dragon-GCS  use pydantic (Model.schema) or use something like https://github.com/PrefectHQ/marvin

In case it helps, you can create a JSON schema from a function definition very easily with Pydantic
import json
import inspect

import pydantic

def foo(a: str, b: int = 0) -> None:
    """
    Description for funcion

    Args:
        a(str): argument a
        b(int): argument b
    """

schema = pydantic.TypeAdapter(foo).json_schema()
doc = inspect.getdoc(foo)
if doc:
    schema['description'] = doc
print(json.dumps(schema, indent=2))

In case it helps, you can create a JSON schema from a function definition very easily with Pydantic
import json
import inspect

import pydantic

def foo(a: str, b: int = 0) -> None:
    """
    Description for funcion

    Args:
        a(str): argument a
        b(int): argument b
    """

schema = pydantic.TypeAdapter(foo).json_schema()
doc = inspect.getdoc(foo)
if doc:
    schema['description'] = doc
print(json.dumps(schema, indent=2))

This is helpful for me, thanks. I can close this issue now.


CSS legacyValue is no longer needed

This commit in CSS Color 4 explicitly defines legacy syntaxes for rgb(), rgba(), hsl(), hsla(), which means they do not require to be defined with legacyValue anymore.
However the online specs do not seem to reflect these changes yet, and I expressed my concern about another change in CSS Color 5 that prevents extracting legacy and modern syntaxes from CSS Color 4 + the "advanced" modern syntax from CSS Color 5 (with relative color keyword and missing components in color functions).

Thanks for the heads-up. The logic in Reffy is still needed for the /TR/css-color-4/ spec for now (which may be what you call "online specs"?). At least in theory... In practice, looking into the code and history of extracts more thoroughly, I note that logic actually broke in November last year when we dropped surrounding <> for functions because the code is still looking for <rgb()> and not for rgb().
I'll use this opportunity to drop the custom logic entirely.
Thanks for raising the issue against css-color-5.

I was referring to drafts.csswg.org, as opposed to the Github repository.
Thanks for the quick fix. I guess we are now waiting for the fix in CSS Color 5 before we can close this issue.

I was more waiting for PR #1218 to be merged and released. Now done. That should be all that's needed from Reffy's perspective.
I created an issue on Webref to track the possible creation of a patch to add the legacy syntax if it does not get re-introduced in CSS Color 5.

Yeah, I was wrong saying that Reffy would ignore legacy syntaxes from CSS Color 4. It will only affect the Webref NPM package, if there is a release before. Thanks again. 👍

I guess we are now waiting for the fix in CSS Color 5 before we can close this issue.

I just did those fixes


Make images scale properly in lbry.tv.

Closes #3948
PR Checklist

Please check all that apply to this PR using "x":

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[x] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[ ] Other - Please describe:

Fixes
Issue Number: 3948
What is the current behavior?

What is the new behavior?
The image is scaled to fit in the viewing area.
Other information

hey @jeffslofish , congrats on the first contribution! We'll get a review on this soon. Do you know if smaller images will still scale up with this fix? Seems they were pixelated on the live version.
Can we show you some appreciation for the PR?

Thanks for fixing this!


file type icon and datasetup css features added

In the flatfileupload.tsx component added a csv, excel and Json icon are added with css features. and in the datasetup.css file added some css features for the list of Databases.

I am closing this pull request because I noticed some changes that need to be made before this feature is ready to be merged. I will make the necessary updates and submit a new pull request soon. Thank you for your understanding!


[Question] Simple Custom Live Extension

I am aware of #57, but even after reading through the examples you made, I cannot figure this issue out. I am attempting to replicate ThePrimeagen's git-worktree plugin, namely to port the telescope extension to fzf-lua. The details of the implementation are already finished by him, I just have trouble with generating a simple picker.
I need to filter the command git worktree list into fzf. I need no previews or anything fancy - a simple live picker with my custom actions. My attempt to do so is below, which fails in many aspects - the query doesn't fuzzy find with respect to git worktree list, firstly previews the git history rather than git worktree list, etc. Any help would be appreciated.
function(opts)
    local path = require 'fzf-lua.path'
    local core = require 'fzf-lua.core'
    local config = require 'fzf-lua.config'
    opts = config.normalize_opts(opts, config.globals.git)

    opts.cwd = path.git_root(opts.cwd)
    local cmd = path.git_cwd('git worktree list', opts.cwd)

    -- this gets called every keystroke, setup for this
    -- is done inside 'set_fzf_interactive_cmd(opts)'
    opts._reload_command = function(query)
        return cmd .. (#query > 0 and '-S ' .. vim.fn.shellescape(query) or '')
    end

    opts.exec_empty_query = true
    opts = core.set_fzf_interactive_cmd(opts)

    coroutine.wrap(function()
        local selected = core.fzf(opts)
        if not selected then
            return
        end
        actions.act(opts.actions, selected, opts)
    end)()
end

It's been a while since #57, I now use a different approach for live grep which uses a separate process altogether using nvim --headless (search for multiprocess) for performance reasons, for your relatively simply task I don't think that's required (as it compliates using external modules a bit) so the above is the right approach.
I modified it a bit to be able to support :FzfLua resume properly and also have a basic preview that displays the command and selected item as a baseline for your code, do with it what you please:
function M.test(opts)

  local fzf = require('fzf-lua')
  opts = fzf.config.normalize_opts(opts, fzf.config.globals.git)

  -- not a must, this just checks we're inside a
  -- git repo or prints an error to ':messages'
  if not fzf.path.git_root(opts) then return end

  -- this adds `-C <cwd>` to the command
  local cmd = fzf.path.git_cwd('git worktree list', opts)
  opts.cmd = cmd

  opts._reload_command = function(query)
    print("query", query)
    opts.cmd = cmd .. (#query > 0 and '-S ' .. vim.fn.shellescape(query) or '')
    return opts.cmd
  end

  -- simple preview that displays the command/selected item
  local prev_act = fzf.shell.action(function (args)
    return ("[command]:\t %s\n[selected line]: %s"):format(opts.cmd, args[1])
  end, nil, opts.debug)
  opts.fzf_opts['--preview'] = prev_act

  -- this is for resume to recall the function entirely
  -- which is required when running "live" query types
  opts.__FNCREF__ = opts.__FNCREF__ or fzf.utils.__FNCREF__()
  opts.query = opts.query or fzf.config.__resume_data.last_query

  opts.exec_empty_query = true
  opts = fzf.core.set_fzf_interactive_cmd(opts)

  -- use 'core.fzf_wrap' instead of 'core.fzf' for resume
  -- support, otherwise actions won't work when resuming
  fzf.core.fzf_wrap(opts, opts.fzf_fn, function(selected)

    if not selected then return end
    fzf.actions.act(opts.actions, selected, opts)

  end)()
end

Btw, if you can also "transform" the command output, for exmaple if you wanted to color the output, etc, you can use opts._fn_transform for that, I edited the above comment to reflect that as well by addng a simple prefix before each line.

Thanks for the color info, I was going to ask about that next. With regard to actions, I declare opts.actions as the following inside the picker:
local delete_worktree = function(selected, opts) [[ stuff ]] end
opts.actions = {
    ['ctrl-d'] = { delete_worktree, actions.resume },
}

However, pressing <c-d> when I open the picker seems to do nothing at all.

What happens if you print before actions.act? What does selected contain?

print(selected)

yields whatever input I typed into the prompt a.k.a. the user input (if printed before actions.act).
However, delete_worktree seems to not be called.
Below is how I pass in actions to fzf.actions.act - are you sure this is correct?
fzf.actions.act({
    ['ctrl-d'] = { delete_worktree, actions.resume },
}, selected, opts)

I’ll check the code later when I’m on the computer, can you try setting a default action too?

Default action yields nil and similar behavior. No rush, thanks for the responses. I think the picker setup is fundamentally flawed as it isn't fuzzy finding the output correctly.

Default action yields nil and similar behavior. No rush, thanks for the responses. I think the picker setup is fundamentally flawed as it isn't fuzzy finding the output correctly.

It’s not flawed, this is how “live” query works using fzf’s reload action, every keystroke generates a new command, fuzzy finding is disabled by design, if you need fuzzy finding you need to think of a different design without reloading the query.

Yes sorry, by flawed I meant the approach I wanted to take was flawed. I see what you mean now.

That makes things extra simple:
function M.test(opts)
  local fzf = require('fzf-lua')
  opts = fzf.config.normalize_opts(opts, fzf.config.globals.git)

  if not fzf.path.git_root(opts) then return end
  opts.cmd = fzf.path.git_cwd('git worktree list', opts)

  fzf.core.fzf_wrap(opts, opts.cmd, function(selected)
    if not selected then return end
    fzf.actions.act(opts.actions, selected, opts)
  end)()
end

With actions, (note you need the default action, even it does nothing:
function M.test2(opts)
  local fzf = require('fzf-lua')
  opts = fzf.config.normalize_opts(opts, fzf.config.globals.git)

  if not fzf.path.git_root(opts) then return end
  opts.cmd = fzf.path.git_cwd('git worktree list', opts)

  opts.actions = {
    ["default"] = { function(sel) print("sel", sel[1]) end, fzf.actions.resume },
    ["ctrl-y"]  = { function(sel) print("sel", sel[1]) end, fzf.actions.resume },
  }

  fzf.core.fzf_wrap(opts, opts.cmd, function(selected)
    if not selected then return end
    fzf.actions.act(opts.actions, selected, opts)
  end)()
end

That works perfect. Now I can press <c-d> and a branch is deleted. However, with actions.resume this deletion is not reflected, even though the git worktree has been removed. Just like calling actions.buf_del how can I make the list reflect real-time changes?

That works perfect. Now I can press <c-d> and a branch is deleted. However, with actions.resume this deletion is not reflected, even though the git worktree has been removed. Just like calling actions.buf_del how can I make the list reflect real-time changes and update after keypress?

Can I see your code? it must be a bit different than what I posted, I just tested the code with a simple ls provider and it works as expected, when running resume the command is then executed again and an updated list is shown.

Note that if you update to https://github.com/ibhagwan/fzf-lua/commit/86804f7462301718e83397cc282d95b9f898589d, default action is no longer required.

function M.test(opts)
  local fzf = require('fzf-lua')
  opts = fzf.config.normalize_opts(opts, fzf.config.globals.git)

  opts.cmd = "ls"

  opts.actions = {
    ["ctrl-x"]  = { function(sel)
        print("sel", opts.cwd .."/"..sel[1])
        vim.fn.delete(opts.cwd .."/"..sel[1])
    end, fzf.actions.resume },
  }

  fzf.core.fzf_wrap(opts, opts.cmd, function(selected)
    if not selected then return end
    fzf.actions.act(opts.actions, selected, opts)
  end)()
end

Furthermore, is there a way to access the query? I finished everything (I swear, hah) except one function which needs to parse the typed in query.

The typed query can be accessed with:
:lua print(require'fzf-lua'.config.__resume_data.last_query)

Thanks. By the way I see earlier you talked about opts._fn_transform. I don't see your use of that function actually included in your response where you edited it.

Thanks. By the way I see earlier you talked about opts._fn_transform. I don't see your use of that function actually included in your response where you edited it.

_fn_transform is only used in the “live” commands, the code I posted later simply pipes the command to fzf, I.e. what actually runs is ls | fzf <options>, that’s why I’m confused why your resume won’t update properly as it re-runs the command in the shell and simply displays the output in fzf.
If you wish to manipulate the command and process the output you need to use the livuv command wrapper:
  opts.cmd = libuv.spawn_nvim_fzf_cmd(
    {
      cwd = opts.cwd,
      cmd = 'git worktree list'
    },
    -- this gets called for each output line
    function(x)
      return x
    end)

Ok, got it. Here is my working solution that I will post on the other repository, can you do a quick visual check for any obvious bugs? Thanks.
local fzf = require 'fzf-lua'
local actions = require 'fzf-lua.actions'

-- One of my example actions
local create_worktree = function(_)
    local query = fzf.config.__resume_data.last_query
    if require('utils').empty(query) then
        return
    end

    local path, branch, upstream = unpack(vim.split(vim.trim(query), ' '))
    branch = not branch and vim.fn.fnamemodify(path, ':t') or branch

    require('git-worktree').create_worktree(path, branch, upstream)
end

return {
    git_worktrees = function(opts)
        opts = fzf.config.normalize_opts(opts, fzf.config.globals.git)

        opts.cmd = fzf.path.git_cwd('git worktree list | sed "s|$HOME|~|g"', opts)

        opts.actions = {
            ['default'] = switch_worktree,
            ['ctrl-a'] = { create_worktree, actions.resume },
            ['ctrl-d'] = { delete_worktree, actions.resume },
            -- etc.
        }

        fzf.core.fzf_wrap(opts, opts.cmd, function(selected)
            if not selected then
                return
            end
            actions.act(opts.actions, selected, opts)
        end)()
    end,
}

Also, I'm fine with hardcoding the color strings, but I would like the output to be colored. git worktree list itself doesn't yield colored output - is there a more "neovim-like" method to surround the path and branch strings in the example code above with a highlight?

Ok, got it. Here is my working solution that I will post on the other repository, can you do a quick visual check for any obvious bugs? Thanks.

Looks great!

Also, I'm fine with hardcoding the color strings, but I would like the output to be colored. git worktree list itself doesn't yield colored output - is there a more "neovim-like" method to surround the path and branch strings in the example code above with a highlight?

As mentioned in the previous comment, wrap your opts.cmd with the libuv wrapper (I don't think you need git_cwd since the command would be run inside opts.cwd):
  opts.cmd = fzf.libuv.spawn_nvim_fzf_cmd(
    {
      cwd = opts.cwd,
      cmd = 'git worktree list | sed "s|$HOME|~|g"'
      -- if the above doesn't work with a custom `cwd` you can always use
      -- cmd = fzf.path.git_cwd('git worktree list | sed "s|$HOME|~|g"', opts)
    },
    -- this gets called for each output line
    function(x)
      return fzf.utils.ansi_codes.green(x)
    end)

You can also use utils.ansi_from_hl to construct a terminal color escape sequence from neovim highlight groups but it will require a bit of a workaround since it calls vim functions (synIDattr) that aren't allowed inside a lua coroutine (it will fail with E5560: vimL function must not be called in a lua loop callback).
If you wish to see an example of a terminal RBG escape sequence run:
:lua print(require'fzf-lua'.utils.ansi_from_hl("ErrorMsg", "test"))
-- this wraps the text with the escape sequence based on your current
-- colorscheme highlights, e.g.: ^[[38;2;252;81;78mtest^[[0m

If you really wanted to use utils.ansi_from_hl there are probably many ways to go about it but here's one decntly acceptable "hack" (can add as many highlights as you want):
  local colormap = {
      ["ErrorMsg"] = fzf.utils.ansi_from_hl("ErrorMsg", "<placeholder>")
  }

  opts.cmd = fzf.libuv.spawn_nvim_fzf_cmd(
    {
      cwd = opts.cwd,
      cmd = 'ls'
    },
    -- this gets called for each output line
    function(x)
      return colormap["ErrorMsg"]:gsub("<placeholder>", x)
    end)

@barrett-ruth, I'm working on providing a better API, could simplify your code, see https://github.com/ibhagwan/fzf-lua/wiki/Advanced

@ibhagwan Thanks, the API looks a lot better - even easier than telescope integration which I think is the main draw to that plugin.
However, I'm unable to see how I could translate the following code into using the api because of the following:

How to integrate the fzf.path.git_cwd (a.k.a, run the cmd in the correct directory)
I use  fzf.libuv.spawn_nvim_fzf_cmd and then color this output with an anonymous function using hard-coded string manipulation - however, this seems like an extremely niche use case so it's perfectly reasonable for this not to be included in the API.

        opts.cmd = fzf.libuv.spawn_nvim_fzf_cmd({
            cmd = fzf.path.git_cwd(
                'git worktree list | sed "s|$HOME|~|g"',
                opts
            ),
        }, function(x)
            local parsed = parse_entry(x)

            local first_whitespace = { x:find '%s+' }
            local _, second_whitespace_begin = x:find '.*%S%s'
            local _, second_whitespace_end = x:find '.*%s+'

            local colored = table.concat {
                fzf.utils.ansi_codes.blue(parsed.path),
                x:sub(unpack(first_whitespace)),
                fzf.utils.ansi_codes.yellow(parsed.hash),
                x:sub(second_whitespace_begin, second_whitespace_end),
                fzf.utils.ansi_codes.green('[' .. parsed.branch .. ']'),
            }

            return colored
        end)

git_cwd just returns a string command with, you can still use it just the same instead of contents
It’s not a niche use case IMO, that’s why you have opts.n_transform

Also, I don’t think you even need git_cwd, if you supply cwd as part of the options the command would be run in the context of the supplied folder, your code should look like:

require'fzf-lua'.fzf_exec('git worktree list | sed "s|$HOME|~|g"', {
    fn_transform = function(x)
      local parsed = parse_entry(x)

      local first_whitespace = { x:find '%s+' }
      local _, second_whitespace_begin = x:find '.*%S%s'
      local _, second_whitespace_end = x:find '.*%s+'

      local colored = table.concat {
          fzf.utils.ansi_codes.blue(parsed.path),
          x:sub(unpack(first_whitespace)),
          fzf.utils.ansi_codes.yellow(parsed.hash),
          x:sub(second_whitespace_begin, second_whitespace_end),
          fzf.utils.ansi_codes.green('[' .. parsed.branch .. ']'),
      }

      return colored
    end,
    actions = { … },
    -- can also supply working directory if you wish
    -- cwd = <a working directory>,

  })

Awesome. Works perfectly.

@barrett-ruth I took a look at your worktrees.lua@dotfiles, your git_cwd does nothing, the only reason you’d want to use it is if you want to have an option to run your worktrees on a separate working directory, I.e. worktrees({ cwd = … }) (which you can still do in my example code using. cwd).
As for normalize_options, it’s also not required in this case, all it does is provide default options for your functions that are merged from fzf-lua.config.global.git, if you want a different prompt (or any other options) you can supply it as part of fzf_exec(cmd, { prompt = …, actions = … }).

Hey @ibhagwan , coming back to this way later.
Right now I have below:
local parse_entry = function(entry)
    local parsed = vim.split(entry, '%s+')

    return {
        path = parsed[1],
        hash = parsed[2],
        branch = parsed[3]:sub(2, #parsed[3] - 1),
    }
end

local actions, fzf = require 'fzf-lua.actions', require 'fzf-lua'

return {
    git_worktrees = function()
        local wt = require 'git-worktree'

        fzf.fzf_exec('git worktree list | sed "s|$HOME|~|g"', {
            fn_transform = function(x)
                local parsed = parse_entry(x)

                local first_whitespace = { x:find '%s+' }
                local _, second_whitespace_begin = x:find '.*%S%s'
                local _, second_whitespace_end = x:find '.*%s+'

                local colored = table.concat {
                    fzf.utils.ansi_codes.blue(parsed.path),
                    x:sub(unpack(first_whitespace)),
                    fzf.utils.ansi_codes.yellow(parsed.hash),
                    x:sub(second_whitespace_begin, second_whitespace_end),
                    fzf.utils.ansi_codes.green('[' .. parsed.branch .. ']'),
                }
                return colored
            end,
            actions = {
                ['default'] = function(selected)
                    local parsed = parse_entry(selected[1])

                    wt.switch_worktree(parsed.branch)
                end,
                ['ctrl-a'] = {
                    function()
                        local query = fzf.config.__resume_data.last_query

                        if query == nil or query == '' then
                            return
                        end

                        local path, branch, upstream =
                            unpack(vim.split(vim.trim(query), ' '))
                        branch = not branch and vim.fn.fnamemodify(path, ':t')
                            or branch

                        wt.create_worktree(path, branch, upstream)
                    end,
                    actions.resume,
                },
                ['ctrl-d'] = {
                    function(selected)
                        local parsed = parse_entry(selected[1])

                        wt.delete_worktree(parsed.branch, true)
                    end,
                    actions.resume,
                },
            },
        })
    end,
}

This has worked fine the entire time, but now I have two questions:

Can you point me to a newer extension api that exists (if it is different than the above?)
Whenever I create a worktree, it is properly made and fzf resumes as specified by actions.resume. However, the picker does not update. Obviously, "resume" doesn't re-run the command specified. In this case though I would like to create a new worktree and then be able to switch to it. With the above code I have to create a new corktree with , exit the picker, then fire up fzf-lua again to select it. Is there a way around this? Thanks.

Nothing has changed in fzf_exec, the wiki is still accurate: https://github.com/ibhagwan/fzf-lua/wiki/Advanced

However, the picker does not update. Obviously, "resume" doesn't re-run the command specified

Actually, the string command is the only content that is cached, the command should be run again and your worktree should be updated.
Another option, is the swap the resume call to a recursion and call ‘git_worktrees()again but my preference would be to understand why your list isn’t getting updated properly, you can run this withdebug=true` and look at the underlying fzf command and investigate.

@ibhagwan this actually happens because git-worktree.nvim executes commands (eg delete a git worktree) asychronously so the changes don't seem to come up in time. Any advice for how to fix this?

@ibhagwan this actually happens because git-worktree.nvim executes commands (eg delete a git worktree) asychronously so the changes don't seem to come up in time. Any advice for how to fix this?

In this case you’d need to explore the code of git-worktree.nvim and find out if you can hook into the job callback and run the resume only once the job was finished, alternately you can hack an ugly workaround using vim.schedule with a sufficient enough delay.

@barrett-ruth did you find a fix? Used your plugin, but came to the same problem recently

no actually, causing me to abandon trying to figure this out. - @ibhagwan any insight into how to deal with updating a picker after an asynchronous command?


Table shading and regexp

cannot deal table sharding, there is too many tables, need [only][except] to support regexp

This is a good idea. However, I don't have time to attend to this immediately.
I'll tag this with "Help Wanted" in case someone else can contribute.


[Feature] Add dependencies between actions

  sigh
  cert

or
  ipa
  sigh

should raise an exception, since it's obviously the wrong order of tools. I think there should be a new command, which you can put on the top of the Fastfile, something like
skip_checking_dependencies

which will not raise an exception (in case you have some complex nested calls)
The exception should be raised when running the script and entering the sigh action, which sees, ipa was already run.
Therefore, fastlane should keep a record of executed commands and store it in the lane context.

Maybe commands is not the best idea? Since I could have a custom action that does sigh-like things. But rather, require that actions declare their inputs and outputs, and match those?

Maybe just don't care and let commands run in there order user declared. And let it fail if some inputs incorrect, like user wants to create push certificate, but not created app yet, etc. :imp:

@almassapargali agree, that's possible the easiest and most stable way. Maybe we should close this issue.

@krausefx I agree. I don't think command dependency is necessary. Sounds like it be over engineering at the moment 😁

Okay, I'll close this issue for now.


Fix sel for xarray created from single field

Fixes #554
This PR fix the issue when sel() did not work on Xarray created from a single GRIB field with the "earthkit" Xarray engine.
E.g. the following code previously failed when calling sel():
import earthkit.data
ds = earthkit.data.from_source("ecmwf-open-data",
source='aws',
model='ifs',
param=["2t"],
step=[24],
)
ds_xr_earthkit = ds.to_xarray()
ds_xr_earthkit['2t'].sel(latitude=35, longitude=-90, method='nearest').values

Now it produces a correct output:
array([281.03421021])

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.13%. Comparing base (ed78a5f) to head (6e0bcdf).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #564   +/-   ##
========================================
  Coverage    90.12%   90.13%
========================================
  Files          149      149
  Lines        10950    10960   +10
  Branches       518      518
========================================
+ Hits          9869     9879   +10
  Misses         914      914
  Partials       167      167

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Is it possible to get a Teams User ID using Graph API ?

Is it possible to get a Teams User ID using Graph API ? The one that starts with 29: . I can do it using the Bot APIs but is it possible to do it using Graph API ? I have tried Get User Graph API but it doesn't return Teams ID in response

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c36ddb50-9e44-96e3-2df3-174166efa75d
Version Independent ID: 68ac4b64-6616-2216-3519-e0b33d3a53e4
Content: Bot Framework Connector service REST API reference - Bot Service
Content Source: articles/rest-api/bot-framework-rest-connector-api-reference.md
Service: bot-service
GitHub Login: @JonathanFingold
Microsoft Alias: iawilt

Please let me know if there is any update on this

Hi @Arpita1906
Have you had a chance to check out Microsoft Graph Explorer? it is a tool that lets you make requests to see responses and payload against the Microsoft Graph API.

Hi @ramfattah ..I did but I didn't find anything in Graph API to get the teams ID from the Azure ID

Hmm... this might be more of a Microsoft Graph issue, but if the payload information you're looking for is not available in Graph Explorer, then it may not be possible.

Hi @ramfattah is there any other way I can get the Teams user unique 'id' that starts with 29:

Hi @Arpita1906,
Have you had a chance to read this stackoverflow answer in regards to user's 29 id?
https://stackoverflow.com/questions/61887901/how-to-get-the-teams-unique-id-based-from-list-chats-graph-api-of-the-user-who

Closing due to inactivity. Please reopen with additional information if you're still experiencing an issue.


v2022.4.0 regression: The Python path in your debug configuration is invalid.

Issue Type: Bug

Behaviour
Expected vs. Actual
When launching the debugger, the error "The Python path in your debug configuration is invalid." pops up.
This is a regression in v2022.4.0; the same launch configuration worked correctly in v2022.2.1924087327.
Additionally, sometimes the file .vscode\extensions\ms-python.python-2022.4.0\pythonFiles\get_output_via_markers.py is opened in notepad++ (the default associated editor when double-clicking a .py file on my machine). It seems that whatever is trying to automatically run this script is instead just opening it. I'm not sure if this is related to the failure to launch the debugger.
Steps to reproduce:
This is the launch configuration in question:
        {
            "name": "rfgscript: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "python": "${workspaceFolder}/bin/rfgscript.exe",
            "console": "integratedTerminal"
        },

The file "rfgscript.exe" exists and is a custom application that loads python37.dll at run-time (via LoadLibrary). Note: python37.dll is not in the same directory as the custom .exe. The custom application accepts the same command-line arguments as the usual python.exe.

Diagnostic data

Python version (& distribution if applicable, e.g. Anaconda): 3.10.0
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
Value of the python.languageServer setting: Default

User Settings

defaultLS: {"defaultLSType":"Pylance"}

downloadLanguageServer: true

envFile: "<placeholder>"

venvPath: "<placeholder>"

venvFolders: "<placeholder>"

condaPath: "<placeholder>"

pipenvPath: "<placeholder>"

poetryPath: "<placeholder>"

languageServer: "Pylance"

linting
• enabled: true
• cwd: "<placeholder>"
• Flake8Args: "<placeholder>"
• flake8Enabled: false
• flake8Path: "<placeholder>"
• lintOnSave: true
• banditArgs: "<placeholder>"
• banditEnabled: false
• banditPath: "<placeholder>"
• mypyArgs: "<placeholder>"
• mypyEnabled: false
• mypyPath: "<placeholder>"
• pycodestyleArgs: "<placeholder>"
• pycodestyleEnabled: false
• pycodestylePath: "<placeholder>"
• prospectorArgs: "<placeholder>"
• prospectorEnabled: false
• prospectorPath: "<placeholder>"
• pydocstyleArgs: "<placeholder>"
• pydocstyleEnabled: false
• pydocstylePath: "<placeholder>"
• pylamaArgs: "<placeholder>"
• pylamaEnabled: false
• pylamaPath: "<placeholder>"
• pylintArgs: "<placeholder>"
• pylintPath: "<placeholder>"

sortImports
• args: "<placeholder>"
• path: "<placeholder>"

formatting
• autopep8Args: "<placeholder>"
• autopep8Path: "<placeholder>"
• provider: "black"
• blackArgs: "<placeholder>"
• blackPath: "<placeholder>"
• yapfArgs: "<placeholder>"
• yapfPath: "<placeholder>"

testing
• cwd: "<placeholder>"
• debugPort: 3000
• nosetestArgs: "<placeholder>"
• nosetestsEnabled: undefined
• nosetestPath: "<placeholder>"
• promptToConfigure: true
• pytestArgs: "<placeholder>"
• pytestEnabled: false
• pytestPath: "<placeholder>"
• unittestArgs: "<placeholder>"
• unittestEnabled: false
• autoTestDiscoverOnSaveEnabled: true

terminal
• activateEnvironment: true
• executeInFileDir: "<placeholder>"
• launchArgs: "<placeholder>"

experiments
• enabled: true
• optInto: []
• optOutFrom: []

tensorBoard
• logDirectory: "<placeholder>"

Extension version: 2022.4.0
VS Code version: Code 1.66.0 (e18005f0f1b33c29e81d732535d8c0e47cafb0b5, 2022-03-30T05:50:14.623Z)
OS version: Windows_NT x64 10.0.19044
Restricted Mode: No

System Info

Item
Value

CPUs
AMD Ryzen 7 1800X Eight-Core Processor          (16 x 3600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.95GB (16.50GB free)

Process Argv
--crash-reporter-id 07287267-3737-4a02-8227-6b17bacd3f68

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
vscaac:30438847
pynewfile477:30463512

Duplicate of #18847

Some of my configs had:
"python": "${workspaceFolder}/bin/rfgscript",
It seems that with the new version (v2022.5.11021002) the .exe file extension is required, otherwise I'm still getting the "The Python path in your debug configuration is invalid." error.
This makes it troublesome to reuse the launch config across platforms (Windows/Linux).

Working on adding back support for that with https://github.com/microsoft/vscode-python/pull/18920.

Fix should be out in the pre-release version of the extension in a day, use the following to try it out:

@dgrunwald can you try out the latest prerelease version to see if this is fixed or not? Thanks.


[Enhancement] Add predicate when calculating iceberg table statistics

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

run starrocks_admit_test

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 74 / 123 (60.16%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
0
1
00.00%
[885]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
6
00.00%
[253, 254, 255, 256, 257, 260]

:large_blue_circle:
com/starrocks/sql/optimizer/Utils.java
0
5
00.00%
[388, 389, 390, 392, 394]

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergUtil.java
0
3
00.00%
[141, 142, 145]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergTableStatisticCalculator.java
2
5
40.00%
[60, 68, 217]

:large_blue_circle:
com/starrocks/planner/IcebergScanNode.java
2
5
40.00%
[121, 122, 123]

:large_blue_circle:
com/starrocks/connector/iceberg/ScalarOperatorToIcebergExpr.java
69
97
71.13%
[77, 78, 79, 107, 108, 110, 112, 113, 115, 122, 129, 142, 146, 162, 170, 188, 199, 204, 210, 218, 220, 224, 226, 228, 233, 244, 250, 255]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/InPredicateOperator.java
1
1
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 74 / 124 (59.68%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
0
2
00.00%
[891, 892]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
6
00.00%
[253, 254, 255, 256, 257, 260]

:large_blue_circle:
com/starrocks/sql/optimizer/Utils.java
0
5
00.00%
[388, 389, 390, 392, 394]

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergUtil.java
0
3
00.00%
[141, 142, 145]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergTableStatisticCalculator.java
2
5
40.00%
[60, 68, 217]

:large_blue_circle:
com/starrocks/planner/IcebergScanNode.java
2
5
40.00%
[121, 122, 123]

:large_blue_circle:
com/starrocks/connector/iceberg/ScalarOperatorToIcebergExpr.java
69
97
71.13%
[77, 78, 79, 107, 108, 110, 112, 113, 115, 122, 129, 142, 146, 162, 170, 188, 199, 204, 210, 218, 220, 224, 226, 228, 233, 244, 250, 255]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/InPredicateOperator.java
1
1
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 79 / 129 (61.24%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
0
2
00.00%
[891, 892]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
6
00.00%
[253, 254, 255, 256, 257, 260]

:large_blue_circle:
com/starrocks/sql/optimizer/Utils.java
0
5
00.00%
[388, 389, 390, 392, 394]

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergUtil.java
0
3
00.00%
[141, 142, 145]

:large_blue_circle:
com/starrocks/planner/IcebergScanNode.java
2
5
40.00%
[121, 122, 123]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergTableStatisticCalculator.java
3
6
50.00%
[63, 68, 217]

:large_blue_circle:
com/starrocks/connector/iceberg/ScalarOperatorToIcebergExpr.java
73
101
72.28%
[78, 79, 80, 108, 109, 111, 113, 114, 116, 123, 131, 145, 149, 165, 174, 193, 204, 209, 215, 223, 225, 229, 231, 233, 238, 249, 255, 261]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/InPredicateOperator.java
1
1
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 78 / 127 (61.42%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
0
1
00.00%
[947]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
6
00.00%
[254, 255, 256, 257, 258, 259]

:large_blue_circle:
com/starrocks/sql/optimizer/Utils.java
0
5
00.00%
[388, 389, 390, 392, 394]

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergUtil.java
0
3
00.00%
[141, 142, 145]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergTableStatisticCalculator.java
2
5
40.00%
[58, 66, 215]

:large_blue_circle:
com/starrocks/planner/IcebergScanNode.java
2
5
40.00%
[121, 122, 123]

:large_blue_circle:
com/starrocks/connector/iceberg/ScalarOperatorToIcebergExpr.java
73
101
72.28%
[79, 80, 81, 109, 110, 112, 114, 115, 117, 124, 132, 146, 150, 166, 175, 194, 205, 210, 216, 224, 226, 230, 232, 234, 239, 250, 256, 262]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/InPredicateOperator.java
1
1
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 74 / 126 (58.73%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
0
1
00.00%
[947]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
6
00.00%
[254, 255, 256, 257, 258, 259]

:large_blue_circle:
com/starrocks/sql/optimizer/Utils.java
0
5
00.00%
[361, 362, 363, 365, 367]

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergUtil.java
0
3
00.00%
[141, 142, 145]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergTableStatisticCalculator.java
2
5
40.00%
[58, 66, 215]

:large_blue_circle:
com/starrocks/planner/IcebergScanNode.java
2
5
40.00%
[121, 122, 123]

:large_blue_circle:
com/starrocks/connector/iceberg/ScalarOperatorToIcebergExpr.java
69
100
69.00%
[79, 80, 81, 109, 110, 112, 114, 115, 117, 124, 131, 144, 148, 164, 172, 190, 201, 206, 212, 221, 230, 232, 236, 238, 240, 245, 256, 263, 268, 277, 285]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/InPredicateOperator.java
1
1
100.00%
[]

@Mergifyio backport branch-2.5


Navigation Clean Up

[ ] Deleting Item should return user to item list
[ ] Deleting store should return user to store list
[ ] Renaming item should move user to new item page
[ ] Renaming store should move user to new store page
[ ] Clicking on an item in any list page should take you to item's detail page
[ ] Clicking on a store in any list page should take you store's detail page

duplicate, created by accident


wasm-bindgen feature

For use via wasmi, wasm-bindgen is a problem, would you consider putting it behind a feature? If it's straightforward I could probably even find time to create a PR if you're interested, I have a temporary fix in my fork here

really nice project btw :3

Hey 👋 Could you explain more about why wasm-bindgen is a problem, I'm not aware of the issue!

https://github.com/rustwasm/wasm-bindgen/issues/3421
In my limited understanding, wasm-bindgen is made for the web, as such it requires webassembly functions available only through the browser.
But the work here https://github.com/EpicEricEE/typst-plugins is made to bundle fast_qr as a plugin for typst, hence we don't have browser capabilities.


[Feature Request] distinguish DataPLANT-curated vs. community-contributed templates

Is your feature request related to a problem? Please describe.
With more templates contributed from external (community) data stewards, it would be helpful to distinguish DataPLANT-curated (i.e. those aligned with ER requirements and / or metadata checklists) vs. community-contributed templates (e.g. templates for very specific lab routines).
Describe the solution you'd like

Add appropriate Tags "DataPLANT-curated" and "Community-contributed" to ontology (@Brilator)
Add communities as Instances to ontology (@Brilator and others)
Use these tags in SWATE template metadata tags list. (all template authors)
Implement them in swate search / filter mechanism.

let me know if the visual fits @Brilator @omaus . You can see an example here.

However, for the time being searching, searching the community by tag would suffice.

I too think that is the best solution. If i make a dropdown filter for all communities this could become bloated really fast. Adn adding yet another search field would unnecessarily increase complexity while being redudant to a tag based search.
This will be implemented with the upcoming database update, as this will also affect Swobup.

Now about the "How" to add information about curated vs community to the template metadata.
Any of:

curated and community are standard tags.
Make a special field Curated with true or false input.
Make special field with curated or community input. How should we call such a field to make it descriptive?

@Brilator @omaus @AngelaKranz

Maybe sth. alike to the special ER-Tags? Otherwise, I'd choose 1.

Technically, 2 is probably least and and 3 less error-prone than 1. For 1 it could easily happen, that people add both tags (if they do not understand what they mean).
Along the same lines, I would really call them "DataPLANT-curated" or "DP-curated", not just "curated". Templates coming from the community will likely still be curated (by the associated data steward), but not by DataPLANT (platinum flag ship templates...).
To use solution 1, I would suggest to go one step further.
Since you implemented the proper ontology fields, why not add it to our ontology with a proper definition.
#TAGS list |
-- | --
Tags | DataPLANT-curated
Tags Term Accession Number | NFDI4PSO:1000xxx
Tags Term Source REF | NFDI4PSO
#TAGS list |
-- | --
Tags | community-contributed
Tags Term Accession Number | NFDI4PSO:1000xxx
Tags Term Source REF | NFDI4PSO

I think we really should not use 1. then. If you can give more input on how you want 2. implemented, i can do that.

Simplest solution for (2) would be to squeeze one key "Template source" in:

(example from 1SPL01_plants)
And then only allow "DataPLANT-curated" or "community-contributed" (maybe find better categories, these are too long).
I would not go for TRUE /FALSE, since this is a bit more literal.

Done! This will be implemented in version 0.6.0 🎉


chore: update dependencies

Closes #61

Can't update vitest to 0.12.x because of https://github.com/vitest-dev/vitest/issues/1286


WTM.J2534 - Implement CLI interface

Missing processing of arguments. Should be able to consume:

Baudrate of CAN bus
Name of DLL

Implemented


Build failures on Linux, ambiguous type error.

I wasn't having this issue building on Windows, but trying things out in Ubuntu with the latest commit, there seems to be some conversion issue with the CSteam ID, I assume because it isn't the standard integer that the methods convert it to.  Probably a small fix, but I wasn't sure what the organizational intentions were with the ID getter, or what sort of validations or error handling that might be needed there if the ID given is invalid.
https://github.com/Gramps/GodotSteam/blob/9db71c13324255137f202d58079996adab93b673/godotsteam/godotsteam.cpp#L960
Here are the errors, I've also included the log, it seems to be pouring out a lot of messages, so not sure if that will alleviate when the errors are resolved, or if something else may be off.

modules/godotsteam/godotsteam.cpp: In member function 'void Steam::getPlayerAvatar(int, uint64_t)':
modules/godotsteam/godotsteam.cpp:960:26: error: conversion from 'uint64_t {aka long unsigned int}' to 'CSteamID' is ambiguous
avatarData->m_steamID = steamID;
^~~~~~~

Seems to also affect the line in my recent PR as well.

modules/godotsteam/sdk/public/steam/steamclientpublic.h:568:7: note:   initializing argument 1 of 'constexpr CSteamID& CSteamID::operator=(CSteamID&&)'
class CSteamID
^~~~~~~~
modules/godotsteam/godotsteam.cpp: In member function 'void Steam::_avatar_loaded(AvatarImageLoaded_t*)':
modules/godotsteam/godotsteam.cpp:1763:100: error: conversion from 'uint64 {aka long long unsigned int}' to 'const Variant' is ambiguous
ignal", "avatar_loaded", avatarData->m_steamID.ConvertToUint64(), width, data);

scons.log

OK, so it wants it to be a CSteamID, eh?  I guess it could be cast first:
CSteamID avatarID = (uint64)steamID;
avatarData->m_steamID = avatarID;

That should clear that up.    I won't be able to test them on Linux until tomorrow.  Try adding them to your local copy and see if they work.

I will try it out shortly.

These casts have cleared it up.  Still quite a flurry of warnings on Linux, but it is compiled, going to take a look at it and also see what happens on Windows.

Hmm, can't get the editor to run even the steam .so file is next to it in the folder, keeps saying it can't find the library.  :/   It must require some magic Linux spells.  Will build a windows version and see how that goes.

The windows build on Linux started up, but my project crashes at this line of code:
Steam.getPlayerAvatar(Steam.AVATAR_MEDIUM)
And the only message in the console is:

On Ubuntu (18.04.1 LTS) the scons platform=windows bits=64 tools=yes target=debug build, when running it in Win10 64-bit, it seems the issue is happening here at SteamFriends().
https://github.com/Gramps/GodotSteam/blob/9db71c13324255137f202d58079996adab93b673/godotsteam/godotsteam.cpp#L935
Not sure how to debug it from there.

Huh, well, I'm in Linux currently and will test all this out to see what I get and see if we can get it squared away!

OK, those fixes I posted earlier seem to clear it for me on Linux with no errors.  Everything else seems to work out fine in testing; even passing just Steam.AVATAR_MEDIUM with no Steam ID as second variable.
I'm not sure about cross-compiling for Windows from Linux as I dual-boot and just switch over to do those.  I'm guessing something during that process is a bit wonky.
The Linux issue of not being able to find the libsteam_api.so file should be fixed.  To check those dependencies and libraries, just run:
ldd godot.x11.tools.64
It should contain this line:
libsteam_api.so => ./libsteam_api.so
This means it is looking locally.  If it doesn't say that, then there might be something wrong with the config.py file in your copy of the module.  The line env.Append(RPATH=["."]) should not be commented out like it was before the fix.

And the only message in the console is:

That seems to be pointing to a Unix version of the net_socket which shouldn't be in Windows... right?  If you don't cross-compile, does it all work?

Did a successful rebuild of the latest commits, and there are still lots of warnings in the builds I do on Ubuntu.
My binary folder looks like this, with that being the 64bit .so file.

The ldd command does show:

libsteam_api.so => ./libsteam_api.so (0x00007fde78349000)

The editor does execute now using ./godot.x11.tools.64, but I get this error, and the project doesn't seem to launch.

/New%20Game%20Project --remote-debug <IP_ADDRESS>:6007 --allow_focus_steal_pid 11260 --position 448,240
/home/isokisu/Godot/Source/bin/godot.x11.tools.64: error while loading shared libraries: libsteam_api.so: cannot open shared object file: No such file or directory

I'll start up another Windows cross compile, and test that out again, and let you know.  It may very well be a Godot build system issue in general, or my lack of knowledge into the scons build configurations.
As long as I can get the x11 one working, then I could at least split my build jobs to run on different systems when the multiplayer development part gets more rigorous, and there are things to test.

Hmm, that is mighty weird.  It should be looking for the shared object in the same folder.  Is that libsteam_api.so the one from the /redistributable_bin/linux64/ folder?  Not sure the 32-bit one would give you that error.  But I'm not sure how to fix it since it's looking in the place it should and it is there.
Can you screenshot or pastebin the errors you get during compile?

Sure, which compile?
The Linux -> Windows cross compile again with the netposix when trying to getPlayerAvatar().  It does do the initializations fine though.  Here's the complete code so far.
var delay = 0.2
var cancel_startup = false
func _ready():

	Steam.connect("connection_changed", self, "steam_connection_changed")
	Steam.connect("avatar_loaded", self, "loaded_avatar")

	$Button/Label.text = ""

	if(not Steam.isSteamRunning()):

		$Button/Label.text = "Launching Steam"

		while(not Steam.restartAppIfNecessary(480)):

			if(cancel_startup):
				quit()
				return

			yield(get_tree().create_timer(delay), "timeout")

	$Button/Label.text = "Initializing Steam"

	while(not Steam.steamInit()):

		if(cancel_startup):
			quit()
			return

		yield(get_tree().create_timer(delay), "timeout")

	$Button/Label.text = "Logging on..."

	while(not Steam.loggedOn()):

		if(cancel_startup):
			quit()
			return

		yield(get_tree().create_timer(delay), "timeout")

	$Button/Label.text = "Connected"
	$Button.disabled = true

	Steam.getPlayerAvatar(Steam.AVATAR_MEDIUM)

In the meanwhile, I'll also double check the normal Windows compile, should be fine though.

Win64 to Win64 compile is still working fine, at least up to the point I'm at with my experiments.  👍

You said the Linux version gave you a bunch of errors when compiling, was curious what they were and if they might correlate to the libsteam_api.so issue.
Windows 64 works.  That's good.  Using the same code as you posted above?

Yeah, same code and project.  Only been testing the friends list stuff and tickets/sessions, etc. so far. The windows compile does everything fine so far, the cross compiled version seems to fail somewhere when it does the SteamFriends() call in that avatar function.
The Linux warnings I think may be only happening on a clean build, I'll double check that.  Here's a pastebin of what they are.
https://pastebin.com/mmr6Wpdx
Let me know if there is anything else I can check with the .so linking.

Huh, mostly just callback warnings, eh?  Wonder why I don't see these.  What GCC and G++ versions are you using to compile with?  And this is for Godot 3.0.6?
Hmm, nope, the LDD would point you to where the executable is looking the .so file.  And as long as it matches the 32/64-bit version of the executable, it should be good to go.  I think the warning would be different too.
Same issue when you use a pre-built?

gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
I'm working from the master branch since 3.1 is approaching release.  I'll double check the bits of the library,
I haven't used any of the prebuilds, I have a few more modules that I'll be using.
Would you like me to test one of these?
https://github.com/Gramps/GodotSteam/releases

Ok, so it doesn't seem to be the mismatch of bits.  When I put the 32-bit library next to the binary, the editor won't find it, or start at all.  When it is the 64-bit library from the Steam SDK it launched the editor, but not the project.
I can't imagine why... but would this be some version issue with the SDK lib files?

Oh, OK.  The master branch is currently 2.x though it is moving to 3.1 next week.  However, that shouldn't be too problematic.   I do believe that you have to use GCC / G++ 5 with Godot 2 though.  I'd think it would give you some error when compiling.
You using the 1.42 version of the SDK?

Whoops sorry, that was a vague sentence.  I meant the version of Godot was the master branch, I'm compiling the Godot3 branch for godotsteam.
What version of GCC 5 should I try?
Yep, the SDK I have is 1.42.

Oh, if you're using Godot 3 branch then you're good with GCC / G++ 7.

I downloaded and tested the 3.0.6 linux precompile.  Same issue with finding the .so file when running a new project from inside the editor.  Finds it well enough to launch, but not well enough to launch a project.
Maybe there is something specific to how my OS is set up.  Though I'm too inexperienced in this environment to find much information about this specifically.  Possibly the way that Godot runs in tool mode fails to make the link for some reason.  I might try my luck with an issue report over there.

Hmm, that is very strange.  Not sure why we can't solve that because it's usually pretty simple fix.  And since it's looking in the right place not sure why it doesn't see it.

In the attempts to run it, I didn't even add script yet to it.  Just wanted to see if it would run the startup scene.
Since the precompiled version is having the same issue, I imagine the least that can be ruled out is that nothing in the scons build is going awry.  Very likely it some configuration problem on my end or the way that Godot editor launches itself.  Unless there is more to the story about what in the SDK gets included or excluded in the build process.  Though, I can't imagine why you wouldn't be experiencing it as well if that were the case.
The editor itself launches, but the project can't find it when it runs.  One test I will try shortly is to export the project, and see if it fails to link that way.  My suspicion is that the linking fails because of how the editor relaunches.
The black magic may be around here:  https://github.com/godotengine/godot/blob/942855a9ee376ce6ee30a25674856ba64316b548/editor/editor_run.cpp#L40

I got it working somehow.  Have been doing various apt-get this and that on my OS, and been noticing there are some serious issues.  I can't even install steam or upgrade the OS, connection failures that I haven't been able to resolve.
However, so things moved forward, but no success getting the updates to work in the course of doing various maintenance suggestions.
After all this, I came back to this do the release build test, and it worked.  So to double check, ran it from the editor, and well, it links now.  XD
So this must be something misfiring in this configuration.  Going to format this drive and reinstall everything at some point.  Any recommendations on more reliable versions of Linux for doing Godot build work with?
Sorry for the run around on this, and thanks again for the awesome support on the original issues.  :+1:

OK, that makes more sense that it is the system instead of the compiling and editor.  I actually use Ubuntu 18.04.1 as my Linux environment.  So it should be good to use.
And welcome!  Always willing to help get issues solved!


[VS Code] Joining collaboration session: The specified value isn’t a valid Live Share URL. Please check the link provided by the host and try again.

Error:
Joining collaboration session: The specified value isn’t a valid Live Share URL. Please check the link provided by the host and try again.
Steps to Reproduce:
1.
2.

Version Data

extensionName
VSLS

extensionVersion
1.0.488

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.36.1

platformName
Linux

platformVersion
4.15.0-54-generic

Closing as dupe of 2179.


Dokany 0.8.0

First attempt at Dokany 0.8.0 compatibility, still WIP

Currently not working properly, see https://github.com/PyFilesystem/pyfilesystem/issues/236#issuecomment-169996346

Other thoughts:

I guess if Dokan is supporting arbitrary paths rather than just single drive-letters, maybe it's worth adding support for long path-names, similar to what OSFS does ? (I guess the UNC stuff here isn't relevant to Dokan though). If that's something that Dokan DLL supports, of course ;)
I've not experimented with Dokan, but if mounting to a nested path (rather than just a non-existent drive-letter), does that path need to already exist (like mountpoints on Linux)? And if so, would it be worth checking for that first in the python-side code, or should it just let the error bubble back up from the Dokan DLL?

Good questions... I know dokan can pretend to be a network drive as well, but UNC shouldn't matter; concerning nested paths I'd leave that to the DLL for now. The mirror.exe shipped with dokany does unfortunately still only work with drive letters it seems. Maybe the whole drive-path issue should be moved to a separate branch and getting dokany 0.8.0 to work at all should be prioritized on first...

I moved the drive to path part to https://github.com/zommuter/pyfilesystem/tree/dokany-paths, unfortunately that seems to have deleted our comments on that...

Closing in favour of #256


Access to interactive documents(Swagger UI) request header, date format issues

This is the result of  Request header to access the Swagger UI :
date: Wed05 Aug 2020 04:30:17 GMT
In fact, It may be like this：
date: Wed 05 Aug 2020 04:30:17 GMT
Is there a space missing between 'Wed' and '05'

Sorry, I can't help you if you don't follow the issue template and provide more information.
If you still have problems please create a new issue and follow the template step by step.
Given that, I'm gonna close this one.


archive/tar: overlong linkname and USTAR header, go-1.10 behavioral change/regression

Go version
go version go1.10.1 linux/amd64
(current latest stable release)

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

Any older toolchain (e.g. go1.9) is not affected by this bug.
Bug output/reproducer
Reproducer:
go get github.com/appc/docker2aci
docker2aci -debug docker://docker.elastic.co/kibana/kibana:6.1.3

Error:
Error: conversion error: error generating ACI: archive/tar: cannot encode header:
Format specifies USTAR; and USTAR cannot encode Linkname="rootfs/var/lib/yum/yumdb/a/6f8ba1fc41ecc5f60aac5b4b7aa28d2566c55481-audit-libs-2.7.6-3.el7-x86_64/from_repo"

Additional info
It looks like the archive/tar rework in go-1.10 introduced a regression in header format when an overlong filename/linkname is present.
This affects docker2aci, as rebuilding the same sourcecode with a newer toolchain results in a runtime error. Please note that the consuming code doesn't try to enforce USTAR, and just relies on archive/tar heuristics.
This can be in theory easily workarounded on our side (see https://github.com/appc/docker2aci/pull/260/files), but this behavioral change likely affects other projects as well and addressing it will introduce toolchain-specific codepaths.
I think it should be investigated and possibly addressed in archive/tar itself.
/cc @dsnet @zhsj

Hi, thanks for the report.
The heuristics that archive/tar used to choose which format has always been problematic. Someone may want PAX (and must never use GNU), someone else wants GNU (and must never use PAX). The inability to specify the exact format was the source of other bugs.
The error you are getting seems seems to show that this is working as intended. The header was read in (as USTAR presumably), modified in some way, and written back out. Only the modification happened in such a way that it went beyond the limitations of USTAR, and so the Writer right complains that it can't use USTAR anymore.
As a general rule of thumb, the read-modify-write cycle on a tar.Header is not going to be forwards compatible as a result of different fields that may be added. Starting in Go1.10, we started to document on tar.Header:

For forward compatibility, users that retrieve a Header from Reader.Next, mutate it in some ways, and then pass it back to Writer.WriteHeader should do so by creating a new Header and copying the fields that they are interested in preserving.

However, this observation has held even prior to G1.10 and was documented to encourage more forward compatible uses of tar.

Thanks for the quick response. So the outcome seems to be that this breaking regression is a unfortunate by-product of the package rework, but it is intended to stay and consumers should deploy their own toolchain-dependent fixes, right?
As much as I appreciate the technical rework and I am fine with fixing the consumers, I'd like to point out that this explicitly goes against the Go 1 promise:
"It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification".
If archive/tar is supposed to be iterated on further, perhaps it would be wiser to move it under some x/-repo?

It's here to stay unless there's a clean fix that addresses the problem, but I don't see one.
I don't think it's fair to only quote that part of the Go1 compatibility promise. Below that statement is list of conditions:

Unspecified behavior. The Go specification tries to be explicit about most properties of the language [and libraries], but there are some aspects that are undefined. Programs that depend on such unspecified behavior may break in future releases.
Bugs. If a compiler or library has a bug that violates the specification, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.

The general issue regarding tar output format has been straddling the lines between unspecified behavior and downright buggy behavior. As a result, the inability to specify the desired format has been the source of more bugs. The tar package is going to focus on making sure read-only and write-only works as bug-free as possible. This is the first time I've heard of a read-modify-write use-case in practice, which has never really quite worked properly either. It be nice to have read-modify-write be as backwards compatible too, but not at the expense of compromising writer-only correctness.

That makes sense. Sorry if my comment sounded harsh/unfair, it wasn't meant to. I'm going ahead closing this bug and fixing the consuming code. Thanks for your work and feedback!

That makes sense. Sorry if my comment sounded harsh/unfair, it wasn't meant to.

Sounded respectful to me. Thanks for raising the issue. Knowing that a read-modify-write use-case exists helps guide design decisions in the future.


Suggestion: Rename "Prepared" spell filter to "Available", then change logic of the filter

Originally in GitLab by @zjennings1
In the spellbook on the character sheet, I would propose changing the name of the "Prepared" filter to "Available", or "Able to Cast", or "Available to Cast" or similar. Then include the following in the filter:

All cantrips
All prepared spells (even if they don't have slots, so they can be upcast)
All at-will spells for which the PC has uses remaining
All pact magic spells for which the PC has slots (I have no experience with pact magic. There may be nuances I'm not aware of.)
All innate spellcasting spells

A minor issue that brought me to this suggestion:
At-will spells don't show up in the "prepared" filter unless they are marked as prepared in the spell details.

Closing this in favour of #2905 as it has a bit more discussion.


Hang when evaluating test set

When I attempt to process the test set, the script just hangs.  Here is the output:
GPU available: True, used: False
TPU available: False, using: 0 TPU cores
/home/ed/Documents/DIRTY/env/lib/python3.6/site-packages/pytorch_lightning/utilities/distributed.py:68: UserWarning: GPU available but not used. Set the --gpus flag when calling the script.
  warnings.warn(*args, **kwargs)
/home/ed/Documents/DIRTY/env/lib/python3.6/site-packages/pytorch_lightning/utilities/distributed.py:68: UserWarning: Your `IterableDataset` has `__len__` defined. In combination with multi-processing data loading (e.g. batch size > 1), this can lead to unintended side effects since the samples will be duplicated.
  warnings.warn(*args, **kwargs)
/home/ed/Documents/DIRTY/env/lib/python3.6/site-packages/webdataset/dataset.py:403: UserWarning: num_workers 8 > num_shards 1
  warnings.warn(f"num_workers {num_workers} > num_shards {len(urls)}")
Testing: 0it [00:00, ?it/s]

Still a lot of CPU usage.  I am not using --cuda because I didn't have enough memory.  Maybe I am not being patient enough.

After disabling beam search, I received some output after ~10 minutes.  It's taking 32 seconds per iteration though :(  I guess DIRTY's model is much more complex than DIRE's.


No documentation for MattaMod Camera Module Mount for Prusa i3 MK3S (and BondTech)

I have added the STLs, but not got round to adding documentation. I will also add STEP files.

Hi,
is there an estimated timeframe for adding some documentation? Especially a link to the used camera module would be very appreciated!

Hi! Apologies for the delay in writing up! I will set myself a goal to get documentation up in the next two weeks.
In the meantime - here is a link to the camera module we use with this mount:
https://www.aliexpress.us/item/3256804790797706.html?spm=a2g0o.order_list.order_list_main.11.7b211802XNQjSI&gatewayAdapt=glo2usa4itemAdapt
The 66°, Fixed Focus model is best for the job!


hi, a question, where did the tail_recursion function dissapeared

btw great lib, looks awesome

https://github.com/lstrojny/functional-php/blob/master/src/Functional/TailRecursion.php?


Default timezone issue with DateDt

Hey there,
We had an issue raised by QA for our Android app where changing the device's timezone was also changing the displayed target date for Goals. We use HAPI-FHIR to parse Goals from a JSON FHIR response from the server.
This is not the expected behaviour as Goal target dates include no timezone information according to the FHIR spec. I.e. no assumptions should be made about the timezone in which this date was recorded. (Seems like a questionable design choice but that's another issue... :) )
The display code was formatting the underlying DateDt object by passing its backing Date to a Calendar instance and getting the year/month/day from that. The issue is that this results in a different output when the default timezone changes from what it was when the DateDt was originally parsed from a string.
I've written a failing unit test to demonstrate the issue here: https://github.com/kiwiandroiddev/hapi-fhir/commit/c190bccfb93cac71884188e43c8810c50ba697ca
As a hacky workaround to the the issue in our app, I made use of DateDt.valueAsString to get the original string from the JSON response and re-parsed that, circumventing the underlying default-timezone-parsed Date altogether.
My question is, can DateDt be changed to store and surface its year, month and day in a completely timezone-agnostic way? Basically exposing the information that already happens to be returned from valueAsString, but as integers.
It seems like LocalDate in JSR-310 could be ideal for DateDt's backing data type. There is a backport library available so the dependency on Java 8 can be avoided. I guess a problem with is that it would cause breaking changes to clients of the library as the underlying Date object is available via getValue(). But anyway, keen to hear thoughts on this - maybe there is a much better approach that I'm missing that would avoid this workaround...
Cheers, Matt

@jamesagnew any plans for migrating to java.time.* classes in HAPI FHIR?

In the event convincing is needed: https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-date/

@jamesagnew In case there's interest in moving from java.util.* to java.time.*, I'd be available for working on a pull request. Besides the deprecation that happened with Java 8, the old java.util.Date and related classes are problematic when using Java 17+ due to JEP 403: Strongly Encapsulate JDK Internals. Among the other things, the new strong encapsulation of internal and deprecated classes cause libraries like GSON to fail, which means the HAPI FHIR core classes cannot be used with GSON on Java 17+.


Broken format in intrinsics

Looks like we need to escape the exponential operator ** as \*\* or use backticks ` here.

It seems that the md was mistyped  **sqrt(x**2 + y**2)** which would result into sqrt(x2 + y2), thus the misprinting, Will escape the character for the sqroot  in the PR.
Thanks and Regards,
Henil Shalin Panchal
CC @awvwgk

Added Math jax to the site for mathematical expressions rendering.

I think we already have math rendering via sphinx, there is an extension for myst-markdown to enable it (dollarmath).

@awvwgk should we shift to this type of packages :

This looks really good. This is a rubric directive?
We could also use badges for the tags.

Also, can you check whether it looks better to have the release/version/... images directly below the header?

This is a rubric directive?

No sir, This is a styled div in myst.

We could also use badges for the tags.

I tried implementing it but then we won't be able to get the github data.
This is implementation of below the header , actually both look good , so, i am confused a bit.

I tried implementing it but then we won't be able to get the github data.

Maybe something like this could work?
-Tags: {{j.tags}}
+Tags: {% for tag in j.tags.split() %} {bdg-light}`{{ tag }}` {% endfor %}

Thanks sir @awvwgk , This looks great.


Pathname#add_trailing_separator

I'd like to take on Pathname#add_trailing_separator, as outlined in https://github.com/danielpclark/faster_path/issues/30

[x] Write Rust implementation of Pathname#add_trailing_separator to FasterPath#add_trailing_separator
[x] Write refinements and monkey-patches for Pathname#add_trailing_separator and map implementation to FasterPath#add_trailing_separator
[x] Write tests from existing sources proving FasterPath#add_trailing_separator operates the same as Pathname#add_trailing_separator
There are currently no existing tests for Pathname#add_trailing_separator(!) I'll add some based on the inverse of Pathname#del_trailing_separator, unless anyone has better ideas?
[x] Write benchmarks in test/benches and compare the performance.

https://github.com/danielpclark/faster_path/pull/45


Crash when updating MusyX submodule in marioparty4

When attempting to update the MusyX submodule in mario party 4 I ran into a fairly consistent crash, unfortunately I couldn't get a full backtrace but I was able to get this:
thread 'notify-rs debouncer loop' panicked at core/src/slice/sort/shared/smallsort.rs:865:5:
user-provided comparison function does not correctly implement a total order
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'notify-rs inotify loop' panicked at /home/runner/.cargo/git/checkouts/notify-0d883586d83a0811/128bf62/notify-debouncer-full/src/lib.rs:676:42:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }
thread 'main' panicked at /home/runner/.cargo/git/checkouts/notify-0d883586d83a0811/128bf62/notify/src/inotify.rs:597:51:
called `Result::unwrap()` on an `Err` value: SendError { .. }

To recreate it's a simple matter of getting the latest commit to marioparty 4, going into extern/musyx and updating to latest HEAD on main, that should immediately cause a crash.

I managed to get a backtrace this time, it's definitely related to the fs monitor
2024-12-16T14:49:05.332120Z  INFO eframe: Both the glow and wgpu renderers are available. Using wgpu.
2024-12-16T14:49:05.365058Z  INFO wgpu_hal::gles::egl: Using Wayland platform
2024-12-16T14:49:05.378937Z  WARN wgpu_hal::gles::egl: Re-initializing Gles context due to Wayland window
2024-12-16T14:49:05.386041Z  INFO wgpu_core::instance: Adapter Gl AdapterInfo { name: "AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 18.1.8, DRM 3.59, 6.12.4-arch1-1)", vendor: 4098, device: 0, device_type: Other, driver: "", driver_info: "4.6 (Core Profile) Mesa 24.3.1-arch1.3", backend: Gl }
2024-12-16T14:49:05.386276Z  INFO wgpu_core::instance: Adapter Gl AdapterInfo { name: "AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 18.1.8, DRM 3.59, 6.12.4-arch1-1)", vendor: 4098, device: 0, device_type: Other, driver: "", driver_info: "4.6 (Core Profile) Mesa 24.3.1-arch1.3", backend: Gl }
thread 'notify-rs debouncer loop' panicked at core/src/slice/sort/shared/smallsort.rs:865:5:
user-provided comparison function does not correctly implement a total order
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::sort::shared::smallsort::panic_on_ord_violation
   3: core::slice::sort::stable::quicksort::quicksort
   4: core::slice::sort::stable::quicksort::quicksort
   5: core::slice::sort::stable::driftsort_main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'notify-rs inotify loop' panicked at /home/runner/.cargo/git/checkouts/notify-0d883586d83a0811/128bf62/notify-debouncer-full/src/lib.rs:676:42:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <F as notify::EventHandler>::handle_event
   4: notify::inotify::EventLoop::handle_event
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at /home/runner/.cargo/git/checkouts/notify-0d883586d83a0811/128bf62/notify/src/inotify.rs:597:51:
called `Result::unwrap()` on an `Err` value: SendError { .. }
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <notify::inotify::INotifyWatcher as core::ops::drop::Drop>::drop
   4: core::ptr::drop_in_place<core::option::Option<notify_debouncer_full::Debouncer<notify::inotify::INotifyWatcher,notify_debouncer_full::cache::NoCache>>>
   5: objdiff::app::App::post_update
   6: <objdiff::app::App as eframe::epi::App>::update
   7: eframe::native::epi_integration::EpiIntegration::update
   8: <eframe::native::run::WinitAppWrapper<T> as winit::application::ApplicationHandler<eframe::native::winit_integration::UserEvent>>::window_event
   9: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
  10: winit::platform_impl::linux::wayland::event_loop::EventLoop<T>::pump_events
  11: eframe::native::run::run_wgpu
  12: objdiff::run_eframe
  13: objdiff::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


Add a last synced time and date

There doesn't seem to be any way to tell, in ODK services, when I last synced. This would be a very helpful item to display on the syncing screen so that if, say, you are an enumerator and the field supervisor emails to say "I added new observations at 9am yesterday, please make sure you have synced" you can just pop open the syncing screen and see whether or not you've synced since 9am yesterday. Supervisors could also pop open fieldworkers tablets to make sure everything has synced at the end of day. I am guessing this info already exists somewhere inside Services, so hopefully this would be easy to display!
+1 vote in features on ODK Forum as of July 28 2019: https://forum.opendatakit.org/t/add-a-last-synced-time-and-date-to-odk-services/12756

this seems same as #155 to me, if not can I get some more info on this?

Yes, it's a duplicate of #155. @IAmJaishree thanks for reporting this.


[Feature] Sort repos alphabetically

In the sidebar on the left, in the "Recent" section, it shows all the repos which were recently opened.
Current behaviour
Those repos seem to be sorted by "last opened". That is very useful when working with a few repos.
But when working with many repos (my sidebar has over 20) it is hard to find the one I'm looking for.
Enhancement
It would be nice to sort repos by "last opened" (default, for backward compatibility) or by "name". For a long list, sorting by name is more useful.

When working with many repos, I believe it'll be more efficient to use incremental search

"incremental search" ?

progressively search for and filter through text. As the user types text, one or more possible matches for the text are found and immediately presented to the user. This immediate feedback often allows the user to stop short of typing the entire word or phrase they were looking for. The user may also choose a closely related option from the presented list


index html templates

index html templates footer ?
how to add ?[ Generated in 0.046 seconds, 5 queries executed - Memory usage: 1.11M (Peak: 1.23M) ]

There is no separate footer, there are layouts/main.forkbb.php for almost all pages (but not all).

how to add ?

https://forkbb.ru/topic/63/(_backslash_)app(_backslash_)config(_backslash_)main.php
see 'DEBUG'

ok :)


Query and methods bug fixes and documentation refactoring

Fixed:

Query when built with 1 component and a filter was storing the wrong components, leading to a wrong output.
Multiple functions were lacking attributes.
Remove alias this from Entity, its intended behavior being overshadowed by opEquals making it unused.
Fixed removeIfHas method in EntityManager not safely evaluating an entity.
Refactor entities and components methods in Storage to package visibility.
Added signal module to package.d

Also updated README.md


Related Entities in ICAT Format, not PaNOSC

Description:
Upon sending a request with an include filter, the included entity is returned in the ICAT format. This means the field name is in the ICAT format, as is all the data inside that related field (e.g. createId exists only in ICAT) and the relationship is in the ICAT format (e.g. are the contents of the related field in a list or just a dict).
The following examples demonstrates this:
Request: http://{{datagateway-api}}/search-api/datasets/0-8401-1070-7?filter={"include": [{"relation": "documents"}]}
Response:
{
    "investigation": {
        "summary": "Day purpose item create. Visit hope mean admit. The tonight adult cut foreign would situation fund.\nPurpose study usually gas think. Machine world doctor rise be college treat.",
        "visitId": "4",
        "id": 2,
        "startDate": "2000-06-04 00:00:00+00:00",
        "releaseDate": "2000-02-10 00:00:00+00:00",
        "modId": "user",
        "endDate": "2000-09-14 00:00:00+00:00",
        "createTime": "2004-08-23 02:41:19+00:00",
        "name": "INVESTIGATION 2",
        "title": "Show fly image herself yard challenge by. Past site her number. Not weight half far move. Leader everyone skin still.\nProve begin boy those always dream write inside.",
        "doi": "0-9729806-3-6",
        "modTime": "2016-11-16 19:42:34+00:00",
        "createId": "user"
    },
    "id": 2,
    "description": "Beat professional blue clear style have. Light final summer. Or hour color maybe word side much team.\nMessage weight official learn especially nature. Himself tax west.",
    "startDate": "2000-10-13 00:00:00+00:00",
    "location": "/subject/break.jpeg",
    "modId": "user",
    "complete": true,
    "endDate": "2000-02-10 00:00:00+00:00",
    "name": "DATASET 2",
    "modTime": "2006-08-24 01:28:06+00:00",
    "doi": "0-8401-1070-7",
    "createTime": "2013-04-01 10:56:52+00:00",
    "createId": "user"
}

Note that investigation should actually be documents. Note that the value of that field should be in a list, because there is a 1-many relationship between Dataset and Document. Also note the data inside investigation has just been copied from Python ICAT and is not in PaNOSC format.
It might be easier to tackle this in two steps - sort out the related field name (i.e. get the example to be documents) and get the data into PaNOSC format, then get the cardinality (list/dict) correct as a second step.
Acceptance criteria:

[ ] Related entities should return in PaNOSC format, not in ICAT format
[ ] Unskip relevant tests in test_search_endpoint.py and test_get_entity_by_pid.py

My initial thought was this should not happen as data should only be returned in the format that is described in the pydantic model classes. From the response above, it is not just the included entity (investigation) that is returned in ICAT format but the entity that is being queried (dataset) too. For example, there isn't a createId field in the Dataset PaNOSC entity.
Upon a closer look at the changes pushed to the feature/search-endpoints-#268 branch, I noticed that the problem is inside the get_with_pid helper method
https://github.com/ral-facilities/datagateway-api/blob/12bdde5bdd164a1f7e2c69329c90b084f1f3cb52/datagateway_api/src/search_api/helpers.py#L80-L117
On line 117, icat_query_data is returned instead of being passed to the from_icat methodof the relevant PaNOSC pydantic model which is why the response contains data in the ICAT format. What needs to be done here is what we are actually doing in the get_search method above it - get the ICAT relations for the non-related fields and then pass the data to the from_icat method.
Considering that the changes on the feature/search-endpoints-#268 branch are not yet merged, I believe that this "fix" should be added to that branch rather than in a new one.


Some fixes

2 fixes:

See Semantic-Org/Semantic-UI#6414.
Fixes Semantic-Org/Semantic-UI#6386

I think I'll use this PR for little fixes, that will allow me to not create many branches just for little patches...


Pass correct request body in materialize provider

Fix https://github.com/eclipse-symphony/symphony/issues/155

materialize.go passs InstanceState, TargetState and SolutionState to API request body
catalogprovider.go pass CatalogState to UpsertCatalog function
remove duplicate UpsertTarget function in symphony-api.go (use CreateTarget instead)
Rename SiteManager functions to GetState and ListState
Update multisite scenario using catalog-catalog.yaml

Tests:

Unit tests
Multi-site manual test with catalog synchronization and remote jobs

https://github.com/eclipse-symphony/symphony/blob/f8d82c7f4480ebe54cd2a6554df5cf3ca7841567/api/pkg/apis/v1alpha1/providers/stage/materialize/materialize.go#L164-L165
I think we need to also fix this lines, use catalog, not catalog.Spec in json.Marshal.

@Haishi2016 gentle ping for review.


[security] don't use credentials in examples

it's pretty much never safe to use any kind of secret as an argument as the command line will record it in history, build tools often preserve these in logs too. There are ways to avoid both, but it's too easy to make a mistake.

Thanks for the feedback. In general, I think it is a good example. You can also set parameters through ENV variables. And if you use them only on systems like GH Actions, you can also configure things to use them via -P without being recorded/shown.
I like the example, exactly because of security. Credentials is something you NEED to put in from the outside. There is no other good example I can think of (almost) every build needs.
Because (event though I co-maintain this plugin) I think a good build setup does not have parameters, but models everything in the build through different task configuration. So that when you call Gradle from the command line yourself, the only thing you need to give is one (lifecycle) task. There are complex setups which needs parameters for good reasons (that was one motivation for creating this plugin). But I think a "standard Java build" should not.
That's why I can't think of another good general example from the top of my head.
But you are right that the README right now very prominently shows using -P from the local command line. Will keep this issue open for now to see what we can do.

You should also not set secrets through environment variables. Parameters and environment variables are very bad ideas for credentials. It's very very easy for that data to leak.

@xenoterracide how do you provide credentials for publishing to a repository when the build is running on a CI server? You need some way of supplying the credentials from the environment to the build process.

I was going to suggest environment variables, too. At least then it lets people avoid putting the secrets in the Gradle command. And short of having a secrets manager like Hashicorp Vault or GitHub secrets, envvars are the best solution I can think of. 🤔

It's only safe to provide credentials as files or via some other in memory process like http and something like hashiCorp vault. There any number of articles on the internet that describe why it's not safe to put credentials and environment variables or on the command line. I can do the googling if you'd like.

Hey @xenoterracide, we're happy to accept a PR updating the documentation with a better example.

you know what's funny, still mulling this over. I've rarely wanted to put credentials on the cli because I can usually store them in a config file, and they rarely change. Interestingly enough if they needed to be one off env vars (bad idea, but still) I know how to put those in a single command too.
most of the command line parameters I've ever wanted are actually related to runtime, not the build. Only thing I can really imagine is switching out something like the version of the jvm for test running, or something like that.

another thought might be setting the version, it's not sensitive and yet it's something that in CI you probably want to set dynamically as it changes on each release. Currently I'm trying to decide the best way to deal with it.
I'd rather see if you like a suggested example before writing a PR to change it. Motivation to PR has been low for a long time due to rejections and code "theft".


Updated plugin for support video js 5

This plugin updated for video js 5 and to using this plugin I make same like videojs-youtube

Thanks for the PR, you're awesome! :)


NIFI-6919: Added relationship attribute to DistributeLoad

Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
Adds a FlowFile attribute to the DistributeLoad processor as well as a feature flag controlling whether that attribute is written.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[x] Have you verified that the full build is successful on both JDK 8 and JDK 11?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[x] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

I'm wondering if it really needs a property... I would just add the attribute by default in my opinion, no?

I'm wondering if it really needs a property... I would just add the attribute by default in my opinion, no?

That's okay with me! I wanted to make it as flexible as possible in case there was a scenario this attribute wasn't desired. I can drop the feature flag.

@pvillard31 : Change has been made. Let me know if there are any other changes necessary.

+1 LGTM, made Pierre's change to the attribute description. Thanks for the improvement! Merging to master