LuaSnip custom snippets from add_snippets does not show up on completion list

Make sure you have done the following

[X] I have updated to the latest version of blink.cmp
[X] I have read the README

Bug Description
LuaSnip require("luasnip").add_snippets(filetype, snippets) did not show up on completion list. Can reproduce by the configuration below with lazy.nvim.

Relevant configuration
  {
    'saghen/blink.cmp',
    lazy = false,
    {
      "L3MON4D3/LuaSnip",
      version = "v2.*",
      config = function()
        local ls = require("luasnip")
        local t = ls.text_node
        local i = ls.insert_node
        local s = ls.snippet

        -- custom snippets
        ls.add_snippets("markdown", {
          s("figure", {
            t({
              "
",
              '',
              "
",
              "",
            }),
            i(1, "Lorem"),
            t({
              "",
              "
",
              "
",
            }),
          }),
        })
      end,
    },

    version = 'v0.*',

    ---@module 'blink.cmp'
    ---@type blink.cmp.Config
    opts = {
      keymap = { preset = 'enter' },
      snippets = {
        expand = function(snippet) require('luasnip').lsp_expand(snippet) end,
        active = function(filter)
          if filter and filter.direction then
            return require('luasnip').jumpable(filter.direction)
          end
          return require('luasnip').in_snippet()
        end,
        jump = function(direction) require('luasnip').jump(direction) end,
      },
      appearance = {
        use_nvim_cmp_as_default = false,
        nerd_font_variant = 'mono'
      },
      sources = {
        default = { 'luasnip' },
      },
    },
    opts_extend = { "sources.default" }
  },

neovim version
NVIM v0.11.0-dev-1357+gcc38630d39 Build type: RelWithDebInfo LuaJIT 2.1.1732813678
blink.cmp version: branch, tag, or commit
v0.7.6

Fixed on main, not sure when :)

It seems that in order to activate completion sources the right option syntax is
 sources = {
      completion = {
        enabled_providers = { 'lsp', 'path', 'luasnip', 'buffer' },
      },
    },

and not
sources = {
      default = { 'lsp', 'path', 'luasnip', 'buffer' },
    },

as stated in the README, or am I wrong? I have been seeing the same problem and have accidentally come across this issue where the above configuration was mentioned.

Click the note at the top of the readme to go to the latest release. The configurations for sources was moved on main, but it hasn't been released yet


Created a 3D regression tutorial.

Fixes # .
Description
Created a simple 3D regression tutorial.
Checks

[x] Avoid including large-size files in the PR.
[x] Clean up long text outputs from code cells in the notebook.
[x] For security purposes, please check the contents and remove any sensitive info such as user names and private key.
[x] Ensure (1) hyperlinks and markdown anchors are working (2) use relative paths for tutorial repo files (3) put figure and graphs in the ./figure folder
[x] Notebook runs automatically ./runner.sh -t <path to .ipynb file>

Need to make some changes.

Hi @paul-reiners I recommend that you reopen this PR and continue your work here. Anything you push to your fork will track in this PR so there's no need to close if you need to do more work. This avoids having too many closed PRs in the repo history. Thanks!

Hi Eric,
Sure.  I can do that.
Paul
On Sun, Jun 23, 2024 at 2:47 PM Eric Kerfoot @.***>
wrote:

Hi @paul-reiners https://github.com/paul-reiners I recommend that you
reopen this PR and continue your work here. Anything you push to your fork
will track in this PR so there's no need to close if you need to do more
work. This avoids having too many closed PRs in the repo history. Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/Project-MONAI/tutorials/pull/1735#issuecomment-2185287895,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALSTKYHILHEICYMPUQH4B3ZI4Q6TAVCNFSM6AAAAABJXXKYNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBVGI4DOOBZGU
.
You are receiving this because you were mentioned.Message ID:
@.***>


Already exists https://redis-py.readthedocs.io/en/latest/#redis.StrictRedis.flushall

@andymccurdy Please close this. Issue is resolved


Missing parentheses in  tag when collection is empty

MyBatis version
3.5.1
Database vendor and version
MySQL 5.7.19
Test case or example project
SELECT a.id, a.name, a.oid
    FROM A a
        INNER JOIN B b on a.id = b.aid
        INNER JOIN C c on b.did = c.did
    WHERE
        c.uid = #{uid}
        AND a.flag = 1
    <if test="dids != null">
        AND c.did IN
        <foreach collection="dids" item="did" separator="," open="(" close=")">
            #{did}
        </foreach>
    </if>

    # complex search
    <if test="keyword != null">
        AND (a.name LIKE CONCAT('%', #{keyword},'%')
        <if test="searchingIds != null">
            OR a.id IN
            <foreach collection="searchingIds" item="searchingId" separator="," open="(" close=")">
                #{searchingId}
            </foreach>
        </if>
        )
    </if>
    <if test="keyword == null and searchingIds != null">
        AND a.id IN
        <foreach collection="searchingIds" item="searchingId" separator="," open="(" close=")">
            #{searchingId}
        </foreach>
    </if>

    # whitelist
    <if test="allowedIds != null">
        AND a.id IN
        <foreach collection="allowedIds" item="allowedId" separator="," open="(" close=")">
            #{allowedId}
        </foreach>
    </if>

    # blacklist
    <if test="deniedIds != null">
        AND a.id NOT IN
        <foreach collection="deniedIds" item="deniedId" separator="," open="(" close=")">
            #{deniedId}
        </foreach>
    </if>

Well someone would say, "Hey check if it's empty before call the SQL". In fact empty condition is normal case. I don't think it's always a good practice to check it in business code. I have to write it out of the <foreach> tag instead of using open="(" close=")"
Steps to reproduce
When any of the collections above is empty, there will be sql error. Generated sql has no parentheses after IN.
Expected result
...
AND a.id IN ()
AND a.id NOT IN ()

Actual result
...
AND a.id IN
AND a.id NOT IN

Why don't you...
IN (
    <foreach collection="dids" item="did" separator=",">
        #{did}
    </foreach>
)

...?

Hi, @CodeInDreams :
Why don't you...
<if test="dids != null">
    AND c.did IN (
        <foreach collection="dids" item="did" separator=",">
            #{did}
        </foreach>
    )
</if>

...?

Hi, @CodeInDreams :
Why don't you...
<if test="dids != null">
    AND c.did IN (
        <foreach collection="dids" item="did" separator=",">
            #{did}
        </foreach>
    )
</if>

...?

Yes right now I'm using it exactly this way (also I had mentioned this workaround above). Thank you!
But <foreach> has issue anyway. Accept it and fix it pleaaase.

Hi, @CodeInDreams :
I'm not a MyBatis developer, so I cannot accept nor "fix" this. Just came here to check something else and answered your issue to alleviate the MyBatis team.
Anyway, what you are proposing is not a bugfix, but a breaking behaviour change (any application currently using foreach tag may break).
Consider these currently legit pieces of code:
<foreach collection="conditions" index="column" item="value" open="WHERE " separator=" AND ">
    ${column} = #{value}
</foreach>

<foreach collection="sort" item="s" open="ORDER BY " separator=",">
    ${s}
</foreach>

If the proposed behaviour were accepted, all applications upgrading to a newer MyBatis version with the new behaviour should review (and potentially change) all their foreach constructions. And the proposed behaviour, when undesired like in those two examples, requires a noisy <trim...><foreach...> construction that leads to a less readable code than the current behaviour / workaround.

Hi, @CodeInDreams :
I'm not a MyBatis developer, so I cannot accept nor "fix" this. Just came here to check something else and answered your issue to alleviate the MyBatis team.
Anyway, what you are proposing is not a bugfix, but a breaking behaviour change (any application currently using foreach tag may break).
Consider these currently legit pieces of code:
<foreach collection="conditions" index="column" item="value" open="WHERE " separator=" AND ">
    ${column} = #{value}
</foreach>

<foreach collection="sort" item="s" open="ORDER BY " separator=",">
    ${s}
</foreach>

If the proposed behaviour were accepted, all applications upgrading to a newer MyBatis version with the new behaviour should review (and potentially change) all their foreach constructions. And the proposed behaviour, when undesired like in those two examples, requires a noisy <trim...><foreach...> construction that leads to a less readable code than the current behaviour / workaround.

Thanks for help again. Parden me I did't memtion you are 'developer of mybatis'. No one is reponsible to 'fix' it.
I don't think <foreach> is designed for something like open="ORDER BY ". It's a little tricky and hard to understand for others. If everyone have to use
(
        <foreach collection="dids" item="did" separator=",">
            #{did}
        </foreach>
)

or java code check to avoid a sql error. Then why not make it easier and clear to use. We can even use plan jdbc but here we are. This is only a small difference but many a little makes a mickle. Right?
I accept your example pattern but I'll use this instead:
<if test="sort != null and sort.size() > 0">
    <foreach collection="sort" item="s" separator=",">
        ${s}
    </foreach>
</if>

Another is the same.

Thanks for help again. Parden me I did't memtion you are 'developer of mybatis'. No one is reponsible to 'fix' it.

No problem :) I just wanted to clarify that, despite I'm answering the issue, I'm not a MyBatis developer and my opinion shouldn't be considered more than a particular opinion.

I don't think <foreach> is designed for something like open="ORDER BY ". It's a little tricky and hard to understand for others.

How is that different than open="(" close=")" ?

If everyone have to use <snippet omitted>

Not everyone "has to"... I provided you two counter-examples.

Then why not make it easier and clear to use. (...) This is only a small difference but many a little makes a mickle. Right?

There are two scenarios: 1. then open/close is required even if no items (your IN ()), and 2. the open/close should not be present if there are no items (my WHERE or ORDER BY).
I think the current behaviour favours 2, and there is an easy and clear workaround to achieve 1 (it is just a matter of writing the open/close clauses outside the foreach tag).
On the other hand, the proposed behaviour favours 1, but requires a more complex construction to achieve 2 (involving if or trim clauses). And, again, it is a breaking change that would force applications to stay in the latest version without the change, or review all their mappers for foreach usages.

Hello @CodeInDreams ,
As @nsanchob pointed out, current behavior may be more flexible.
Besides, both syntax (with and without parentheses) are invalid, aren't they?
If you want to omit the condition when the collection is empty, you should just write the AND xxx IN part in open.
<foreach collection="dids" item="did" separator=","
    open="AND c.did IN (" close=")">
  #{did}
</foreach>

This example also shows the current behavior's superiority.

@harawata I get the point. But I still think write the main sql statement as part of the xml tag is bad practice. If you meant that's designed on purpose (should be used  this way), then I'll close the issue and use my ugly way.
btw, make and did in is not equal to write parentheses outside the tag.


fix StrictRedisCluster.from_url issue when skip_full_coverage_check p…

The method( StrictRedisCluster.from_url) runs wrong when redis cluster does't support "CONFIG" command.
Detail info:

Traceback (most recent call last):
File "from_url_password_protected.py", line 8, in
rc = StrictRedisCluster.from_url(url, skip_full_coverage_check=True)
File "./rediscluster/client.py", line 214, in from_url
connection_pool = ClusterConnectionPool.from_url(url, db=db,**kwargs)
File "/usr/lib/python2.7/dist-packages/redis/connection.py", line 844, in from_url
return cls(**kwargs)
File "./rediscluster/connection.py", line 141, in init
self.nodes.initialize()
File "./rediscluster/nodemanager.py", line 228, in initialize
need_full_slots_coverage = self.cluster_require_full_coverage(nodes_cache)
File "./rediscluster/nodemanager.py", line 270, in cluster_require_full_coverage
return any(node_require_full_coverage(node) for node in nodes.values())
File "./rediscluster/nodemanager.py", line 270, in
return any(node_require_full_coverage(node) for node in nodes.values())
File "./rediscluster/nodemanager.py", line 267, in node_require_full_coverage
return "yes" in r_node.config_get("cluster-require-full-coverage").values()
File "/usr/lib/python2.7/dist-packages/redis/client.py", line 620, in config_get
return self.execute_command('CONFIG GET', pattern)
File "/usr/lib/python2.7/dist-packages/redis/client.py", line 573, in execute_command
return self.parse_response(connection, command_name, **options)
File "/usr/lib/python2.7/dist-packages/redis/client.py", line 585, in parse_response
response = connection.read_response()
File "/usr/lib/python2.7/dist-packages/redis/connection.py", line 582, in read_response
raise response
redis.exceptions.ResponseError: unknown command 'CONFIG'

Coverage increased (+0.09%) to 84.391% when pulling e55f609b46b317bc7d9d1039250d382179254485 on armersong:unstable into 007b2d39f5f228a129f91edda30ad3c90bed827a on Grokzen:unstable.

Coverage increased (+0.09%) to 84.391% when pulling e55f609b46b317bc7d9d1039250d382179254485 on armersong:unstable into 007b2d39f5f228a129f91edda30ad3c90bed827a on Grokzen:unstable.

Coverage increased (+0.09%) to 84.391% when pulling e55f609b46b317bc7d9d1039250d382179254485 on armersong:unstable into 007b2d39f5f228a129f91edda30ad3c90bed827a on Grokzen:unstable.

@Grokzen This is biting us right now. Is there any timeframe on when the next release will be cut?


Monorepo

It is nice that snapdragon as well as micromatch are nicely separated into small pieces, but I really think that having all of them in separate repositories make maintaining them a big pain, especially when making a breaking change in one of them that other rely one and then trying to update the whole ecosystem.
I'm also maintaining some projects that use monorepos with yarn workspaces and lerna and it gives you the ability to have small packages, but makes bigger changes super easy as they are all in one repository and one PR. So in my opinion setting up a monorepo would be a nice addition for snapdragon and micromatch.
So I wonder what your opinions are on this? And also for the micromatch org.
I don't want to come into a new project and change everything :) but I think it could make things a lot easier for everyone.

lol, this is so coincidental. Honestly, earlier today I was wondering if someone would ask this.

I don't want to come into a new project and change everything :) but I think it could make things a lot easier for everyone.

Don't worry about that, the feedback is great. I want to have this dialog because I feel that I'm missing something about monorepos, and (if you hadn't created this issue) I was going to tweet to ask someone for feedback about it. I've tried working with monorepos, but I'm having a hard time seeing the benefits everyone describes, and I see many disadvantages that seem unimportant to others, and perhaps shouldn't really matter to me either.
If you're willing to share your experience with monorepos, can you explain a little more about the advantages and disadvantages you've seen?
First I'll give you my impression of monrepos so you can dispell any misunderstanding I might have.
My experience has been that once a monorepo is created, it ends up coupling the projects together completely. Even if that's not the original intent, it just happens over time. The individual projects often no longer have their own documention, etc. Converselely, I think that may people expect the snapdragon and micromatch projects to be completely coupled, but I don't understand that perspective, as it's an anti-pattern when the goal is publishing self-encapsulated modules. IMHO, it seems like the only projects that would make sense for the monorepo format are ones that have dependencies that are not intended to be used (or can't pragmatically be used) as standalone projects. For example, these pug projects would be a good candidate for a monorepo. But in this situation, isn't the packages directory just a way of versioning all of the parts of the library that could have been in a lib or src folder? If, in a perfect universe, the individual packages were still documented and usable as standalone libraries, then I can see how the monorepo format would make sense. But rarely seems to be the case.
To that end, I can see how snapdragon might be a good candidate, but I don't see how micromatch would make sense as a monorepo. Each of the libraries in the micromatch org is a completely separate project that should stand on its own. They don't "exist for micromatch" specifically.
Thoughts?
I'd like to get @doowb's thoughts on this as well.

Agree with both. Snapdragon is perfect candidate for monorepo, but not the micromatch - as Jon said, projects there are completely decoupled standalone and can be used separately, and micromatch just combines them.
As about @snapdragon, yes it may have benefits, but the thing that i don't like about monorepos is navigating through code and docs, also that it have single issue tracker.
I also tried to create monorepos few times, but ended up that i don't like it and it won't give me much - it will be more discomfortable to be than it gives some comfort. So i'm interested in hearing some thoughts from you @danez too.

I also agree with @jonschlinkert and @olstenlarck and I think it's mostly because of Jon's last comment which was added as an edit. We've built tools that make maintenance easier and keeping the separation isn't too bad.
To go along with @olstenlarck comment about documentation, there have been many times when I get an error in a module or want to look at the readme for a module and I type npm repo some-module and it goes to the root of a monorepo. When looking at the packages folder, I see this (not picking on babel, but this was my experience 😁):

Also, from my observations when making a change in a subpackage and publishing, the monorepos seem to require publishing all of the packages in the monorepo.
I think that monorepos are harder for new contributors to get involved. For someone that's making changes across many projects in the same dependency tree, I can see how monorepos can be an advantage but also see how it tends to couple the dependencies together. Because of these reasons, I think each package should have self-contained maintenance tools that can be run by new contributors, as well as, "power contributors". I think of this as like a vscode workspace or sublime text project. The IDE is the tool that a maintainer chooses to use to work on the code and group projects together. Then from some root directly where the projects are cloned into, they could choose to run a tool that executes the maintenance tools inside the projects.
Those are my 2¢

I'm currently trying to update snapdragon in micromatch, so that bundling works with webpack. That's where my idea about monorepos came from, because it is tedious work to go through all dependencies, update snapdragon, make everything work, release a new version got to next dependency and do the same thing again. Same thing seems to happen in snapdragon when someone would attempt to update snapdragon-node in snapdragon, which requires some other packages (capture, captureSet) to be update first. And as soon as that would be done we can update snapdragon in micromatch repos again too :)
In this case a monorepo would show it's advantage as I could do everything at once without having to manually link projects together or releasing projects just to be able to be able to update it in other projects.

My experience has been that once a monorepo is created, it ends up coupling the projects together completely. Even if that's not the original intent, it just happens over time. The individual projects often no longer have their own documentation, etc.

Monorepos in general do not force any specific structure in the project or if versions of the packages should be independent or synced. The main focus of a monorepo is usually to make maintenance and development easier, which usually also includes removing development tools from each single package and moving it into the root of the monorepo. This makes it easier to make changes to these tools by updating their configs or updating to a newer version in one place. But it is still up to the maintainers to choose how to layout everything and if for example documentation should be in one place or separate in each package.
The improved maintainance workflow and being able to make breaking changes to one package and immediately seeing the impact on the other packages, is one of the reasons babel moves nearly everything into the monorepo. For example when babel still had its parser (which is also used a lot standalone btw) in a separate repository, new syntax additions would always required making a PR there, waiting till it is merged, waiting till a new version is released and then create PRs in the babel repo to update the parser version and support the new syntax their. Sometimes we lost contributors in the middle of the process and then we had half done stuff lying around. By moving it into the monorepo contributors can simply add one PR and do everything in there.
The biggest downside I see is that the issue trackers are not split by package, especially when there ~5 new issues per day it is not practical anymore to watch the repository and get email notifications for everything. This could potentially be solved with code owners, but I haven't tried that. (https://blog.github.com/2017-07-06-introducing-code-owners/)
I guess both models have disadvantages and advantages.

This could potentially be solved with code owners, but I haven't tried that.

how did I not know about that?! that's interesting! thanks for sharing it.
Based on your comments, I'm tempted to try the monorepo format for snapdragon. Give me some time to think about it, I'd like to play around with the monorepo tools and see what would change for us. Honestly, even if it's not my own personal preference, I see a pattern emerging around monorepos and big "ecosystem" projects, and I'd be remiss to ignore it.

and thank you for sharing your thoughts, I really appreciate it!

@danez, @jonschlinkert and I were talking about this and we'd like to get your feedback on how we could approach a monorepo that will allow us to do the following:

keep the code in their own packages: the lexer, parser, compiler, etc...
use the code in snapdragon without requiring the dependencies. Basically, require them in to use them like normal, but inline the code so the published version of snapdragon doesn't have any dependencies.

Then I think we would do something similar with the micromatch organization where there's a monorepo for many of those projects but the code ends up being published as only having one dependency (snapdragon).
I hope this makes sense and I'd appreciate any feedback you have. Also, @jonschlinkert if there's something I left out or got wrong, please correct me.

@doowb I guess out of the box this is not really doable. Splitting packages in smaller ones comes with the cost of having more dependencies.
To work around this, snapdragon could be bundled with for example rollup into a single file. In the rollup config you can then define which dependencies should be inlined and which should be keept as is. This would then also make it necessary though to patch package.json on publish to remove the dependencies that are now inlined, because even though code lives in the same repository in a monorepo, the individual packages are still separated from each other and have to have proper dependencies on each other in the package.json in order to work.

Okay, @doowb and I have talked about this a lot. We're going to try doing something similar to what you're suggesting @danez. I'll update here when we have something to show.


Date based queries

Hi, first of all thank you for this script.
I was looking around and couldn't find any information on how to make date based queries, something that I'm very interested on.
The use case would be
Return all flights between date 01 and date 02 for airport X.
I'm not looking for the number of flights but the flight details, such as airline, that occured between those dates.
Is this possible to do with your script?
Thank you in advance!

It is not possible to filter flights or any other information by date or time through this API yet.

It is not possible to filter flights or any other information by date or time through this API yet.

Is this something you are going to implement any time soon, or is it a problem that lies with FlightRadar?

It is not possible for the API to filter flights in this way yet because this feature is not freely available on the FlightRadar24 website.

@JeanExtreme002 thank you for your time. Closing the issue.


Rcon problem

I thought your project was wonderful
But I'm having a problem when I run the command
!players
I get this error

and when I try to kick someone I get this error

I'm currently using Windows, but it seems that the rcon command is trying to execute some files that I don't have

Yeah sorry it's hardcoded. I have an update that will download rcon for Windows and deploy with it.
It's a little bit of a mess right now.
Here's the rcon I used: https://github.com/gorcon/rcon-cli

Update this line for now:
https://github.com/Woovie/palworld-server-helper/blob/63ae65e111c9a5e6e7827e64294a0c45b8af2cab/bot.py#L27

I was getting this error "RuntimeWarning: coroutine 'perform_rcon_command' was never awaited"
when using the kick and ban command
I needed to change the lines
result = perform_rcon_command(f"KickPlayer {steamid}")
result = perform_rcon_command(f"BanPlayer {steamid}")

for that:
result = await perform_rcon_command(f"KickPlayer {steamid}")
result = await perform_rcon_command(f"BanPlayer {steamid}")

Now it appears to be working fine

I reviewed my code, cleaned up a few things, and pushed it here: https://github.com/Woovie/palworld-server-helper/commit/99b1afe9e3a99116ed26b89f5872cb2da7c010ce
I've set up a channel in my Discord if you want to discuss the script faster and get help or possibly add features.
https://discord.gg/ccyGETpetwf
The issues mentioned here should be fixed, but it still needs more testing in a pure Windows environment, I mostly wrote this in WSL. Please let me know if you still see issues.

Okay I had more time, I went ahead and fully tested this in Windows. You do now need the Visual C++ Build Tools to run it, but everything works great. I'll update README with instructions on that.


workbench.action.reopenClosedEditor should work with preview editors

VSCode Version: Code - Insiders 1.18.0-insider (098bb776d2e5fdf3cc9ea27a233754acf4309857, 2017-11-04T04:43:03.436Z)
OS Version: Windows_NT x64 10.0.16299
Extensions:

Extension
Author (truncated)
Version

vscode-svgviewer
css
1.4.3

EditorConfig
Edi
0.11.1

tslint
eg2
1.0.14

git-project-manager
fel
1.4.0

vscode-scss
mrm
0.6.2

seti-icons
qin
0.1.3

lorem-ipsum
Tyr
1.1.0

(1 theme extensions excluded)

Repro:

Single click a file in the explorer so it opens as a preview tab
ctrl+w to close editor
ctrl+shift+t to restore editor, the preview editor does not restore

I guess the issue here is that I do not distinguish between a preview editor closing because of another editor opening at the same spot and the actual Ctrl+W interaction.

@bpasero Looks like the reopened editor is no longer a preview editor. Is it intentional?

I think thats fine given the explicit nature of this action.


Web ui omitted manifests changes not synced.

On PipeCD Application detail page on  web ui ( like https://xxx/applications/xxx ) , we can check manifests not synced, but when an application has many changes, the page shows ... (omitted X other changed manifests.
So we can not check the all changes.

What would you like to be added: Enable to show all changes.
Why is this needed: There is no way to check all changes which are omitted.

the max change number is here.
https://github.com/pipe-cd/pipecd/blob/e23412307b27b8a4c3741171db555958a8e70d0a/pkg/app/piped/driftdetector/kubernetes/detector.go#L388


chore: rename generate cmd file name

Overview

Checklist

[ ] New and updated code has appropriate documentation
[ ] New and updated code has new and/or updated testing
[ ] Required CI checks are passing
[ ] Visual proof for any user facing features like CLI or documentation updates
[ ] Linked issues closed with keywords

CI will be fixed by: https://github.com/celestiaorg/orchestrator-relayer/pull/263


ajardin:synchro image

Thanks for this tool, it looks really helpful. Just one question.
What is the purpose of ajardin/synchro image and what does it contain?
I didn't found more info in https://github.com/ajardin/docker-images neither https://hub.docker.com/r/ajardin/synchro/

Hello and thanks for your message!
This is my custom image used for the Mutagen synchronization. Basically, I created a container and a volume called synchro to share the source code from the OS to the Docker environments. The volume is then filled by Mutagen, allowing to share the source code to the nginx and php containers.
This image does not contain anything fancy, here is the associated Dockerfile.
FROM alpine:latest

LABEL org.opencontainers.image.authors="Alexandre Jardin<EMAIL_ADDRESS>LABEL org.opencontainers.image.title="Image with a new user/group to be used with Mutagen."
LABEL org.opencontainers.image.description=""
LABEL org.opencontainers.image.source="https://github.com/ajardin/docker-images/blob/master/common/synchro/Dockerfile"

# Create a new user/group with the same ID than in "nginx" and "php" services
RUN \
    addgroup -g 1000 -S synchro && \
    adduser -u 1000 -D -S -G synchro synchro

CMD ["tail", "-f", "/dev/null"]

Why is it no longer present in my dedicated repository?.. Well, because I forgot to put it back! 😅
To be completely honest, Mutagen allows for better file sharing performance, but it makes day-to-day management more complex and sometimes leads to other problems such as excessive consumption of host system resources. That's why I removed it at one point and continue to challenge it to see if there is a more appropriate solution.
If you don't mind, could you tell me what kind of environment you are using on which OS?

Thanks for your answer.
I'm trying to setup orocommerce on Ubuntu and want it to work on mac too.
For me mutagen is a big plus, without it my dockerized setup is unusable on mac. But I can imagine the hassle of managing the sessions. Mutagen has some improvement including yaml config file - worth to look at https://mutagen.io/documentation/orchestration

Mutagen (or something similar) is indeed mandatory when working on macOS with projects containing many files, unfortunately... 😞
I've already done some testing with the new Docker Compose integration, which still requires using the beta version. But we encountered several issues (e.g. https://github.com/mutagen-io/mutagen/issues/243) that finally led me to go back to the manual management of Mutagen sessions.


Can't do more than one http call on a program

Hi, when I try to do a sequential call for login to get a Token and then do a request with the token in the cookie header on my API, it seems that mito are not running the second http request:
mito -use http,collections,json -insecure=True getlogsfromapi.cel
failed eval: ERROR: <input>:16:5: no such key: Body
 | ).as(token,
 | ....^

bytes(
    request("POST",
        "https://mysite/api/login",
        {"username":"myusername", "password":"mypassword"}}}.encode_json()
    ).Body
).as(token,
    request("GET",
        "https://mysite/api/queryendpoint?query-filter=and(ge(timeStamp,'2024-04-30T7'))"
    ).with(
        {"Header":{"Cookie": ["Login="+string(token)],}}
        ).as(resp,
            bytes(resp.Body).decode_json().as(logs,
                {"logs": logs}
            )
        )
)

Oh hey, thanks for the answer... it's different depending on position and chain... and no "so clear" when to use do_request() looking at the snippets. I was able to see the full chain with the code bellow (On the code I've also needed to mess it up with decode_json_stream() to be able to convert my json first response in a map compatible with the collate() function to filter out the session token.)
request("POST",
    "https://myinstance/api/aaaLogin.json",
    {"aaaUser":{"attributes":{"name":"myuser", "pwd":"mypwd"}}}.encode_json()
).do_request().as(resp_token,
    bytes(resp_token.Body).decode_json_stream().as(token,
        request("GET",
            "https://myinstance/api/node/class/acllogDropL3Pkt.json?query-target-filter=and(ge(acllogDropL3Pkt.timeStamp,\"2024-05-08T7\"))"
        ).with({"Header":{"Cookie": ["APIC-cookie="+string(token.collate("imdata.aaaLogin.attributes.token")[0])],}}).do_request().as(resp,
            bytes(resp.Body).decode_json().as(logs,
                {"logs": logs}
            )
        )
    )
)

And as a little feedback, I probably going to drop mito and Custom API with Cel Integration for now. First, the time library don't got Add time functions and don't got the custom formating for the needs of my case (Cisco's crazy stuff), and from the current state of the docs (Integrations site, Filebeat and the API here), it's really too much of a steep learning curve for me right now. (FYI: In my scenario I used a Custom API pointing to a localhost FastAPI app to do the auth for elastic and keep the time filter right).
Thank you again for the help and I'll keep looking for updates on the integration and on this project.

First, the time library don't got Add time functions

Time values support arithmetic operations, so t + d behaves as you would expect; add the duration d to the time t.

don't got the custom formating for the needs of my case

String concatenation will allow you to format arbitrary string values and JSON can be constructed using extensions that we provide.

About the "position and chain" that I told before, is because the first request inside bytes automatically triggers the do_request(), and the examples on request.txt don't use the do_request https://github.com/elastic/mito/blob/dev/testdata/request.txt#L5-L14
After some work and try I found a complete answer for my case, which I share bellow:
request("POST",
    state.url+"/aaaLogin.json",
    {"aaaUser":{"attributes":{"name":"USER", "pwd":"PASSWD"}}}.encode_json()
).do_request().as(resp_token,
    bytes(resp_token.Body).decode_json_stream().as(token,
        request("GET",
            state.url+"/node/class/acllogDropL3Pkt.json?query-target-filter=and(ge(acllogDropL3Pkt.timeStamp,\""+string(now()-duration('1h')).split(':')[0]+"\"))"
        ).with({"Header":{"Cookie": ["APIC-cookie="+string(token.collate("imdata.aaaLogin.attributes.token")[0])],}}).do_request().as(resp,
            bytes(resp.Body).as(logs,
                {"events": logs.decode_json_stream().collate("imdata.acllogDropL3Pkt.attributes")}
            )
        )
    )
)

Thx for all the help.

I recommend using now rather than now(). The difference is that now is the time that the evaluation started and will be the same for all evaluations for each run, while now() is evaluated at the call site. In the situation that you are using it, this will not be different since it's only being called once, but if you are ever doing something where time stamps must agree (for example in some authentication protocols), this will cause problems. So, not a problem here, but something to be aware of.


SHARMAN-3044: Sky Hub is not fragmenting fragments

Reason for change: The IPv4 default route MTU needs to be 28 bytes lower than the IPv6 MTU for the MAP-T DMR prefix route. Decrease IPv4 default route MTU down to 1472 bytes.
Test Procedure: NA
Priority:P1
Risks:Low

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Suresh babu Palamangalam seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Scanning Helm Repositories

Description
As suggested here, we need to create a service which watches HelmRepositories scans for Profiles and caches the result and services the result via the defined APIs.
Scope

This applies to Profiles only.
The Cache needs not persist beyond the lifecycle of the container unless configured otherwise
Allow the user to specify the cache dir
We need to cache the values.yaml file

Acceptance Criteria
As a developer
I want to scan for profiles and
I want to cache the result on the file system
So that I prevent the same profile downloaded multiple times
Techincal Notes

Nice discussion here

LGTM.

As part of caching we can also consider reducing the cost of interacting with the charts- https://github.com/weaveworks/weave-gitops/pull/1148#discussion_r759540336

Atm, we don't watch ~multiple~ any Helm repository.  The caching mechanism should be implemented keeping in mind that in the future multiple repositories will be watched and we'd cache all of them.

Caching details:
Some detail about the cache, how it works, and what it caches including the watcher's job in all of this.
The Watcher ( who watches the watcher? )
The watcher runs as a controller similar to helm-controller. It watches HelmRepositories for changes or creation events. The difference between this and the helm-controller is that we will use the cache and this watcher to notify people about a new version being available for a profile. And we cache the results from the watch. The Watcher is the one fetching the index file and downloading the values file. It does that only when there is a change in the Revision section of the HelmRepository's Artifact field. This will prevent us from continuously downloading the same thing over and over again on each request. ( In the tone of Borat ): Is very nice.
What we cache
We only cache profile related information. That is this thing:
type Profile struct {
	state         protoimpl.MessageState
	sizeCache     protoimpl.SizeCache
	unknownFields protoimpl.UnknownFields

	// The name of the Profile
	Name string `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
	// The URL to a relevant project page, git repo, or contact person
	Home string `protobuf:"bytes,2,opt,name=home,proto3" json:"home,omitempty"`
	// A list of URLs to the source code of this chart
	Sources []string `protobuf:"bytes,3,rep,name=sources,proto3" json:"sources,omitempty"`
	// A one-sentence description of the Profile
	Description string `protobuf:"bytes,4,opt,name=description,proto3" json:"description,omitempty"`
	// A list of string keywords
	Keywords []string `protobuf:"bytes,5,rep,name=keywords,proto3" json:"keywords,omitempty"`
	// A list of Maintainers
	Maintainers []*Maintainer `protobuf:"bytes,6,rep,name=maintainers,proto3" json:"maintainers,omitempty"`
	// The URL to an icon file
	Icon string `protobuf:"bytes,7,opt,name=icon,proto3" json:"icon,omitempty"`
	// A map of annotations
	Annotations map[string]string `protobuf:"bytes,8,rep,name=annotations,proto3" json:"annotations,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
	// The Kubernetes version
	KubeVersion string `protobuf:"bytes,9,opt,name=kube_version,json=kubeVersion,proto3" json:"kube_version,omitempty"`
	// The Flux HelmRepository
	HelmRepository *HelmRepository `protobuf:"bytes,10,opt,name=helm_repository,json=helmRepository,proto3" json:"helm_repository,omitempty"`
	// A list of available versions
	AvailableVersions []string `protobuf:"bytes,11,rep,name=available_versions,json=availableVersions,proto3" json:"available_versions,omitempty"`
	// The layer of the profile
	Layer string `protobuf:"bytes,12,opt,name=layer,proto3" json:"layer,omitempty"`
}

And values. We cache the raw values file which was the thing returned previously by GetValuesFile in charts.
When do we cache
When the watcher's reconcile loop is triggered. In that instance we ALWAYS download and do our thing. We don't check if it has been done already. Why? Because the reconcile is only called in two instances. Create or Update. In either case, we need to do our thing. The reconcile and Kubernetes will take care of detecting changes or new creations. The cache or the reconcile loop doesn't have to worry about that.
What is given back
Since profiles data is cached, that is what is returned plus values if requested.
Why disk based cache
Values can be really large. We don't want an in memory cache which could potentially take up megabytes of memory increasing the load on the server pod.
Invalidating the cache
This doesn't really matter as the cache is constantly updated when there is new data available. We don't ever invalidate manually. The cache basically never expires.
Architecture of the cache
Cache replaced whatever the profiles endpoint was calling. Which is things in under helm the charts.* methods. Those methods have been all shifted to the Watcher. The watcher is notified on creation and update events regarding ALL HelmRepository objects. Through the Predicate, it's determined if it's a create or an update event. In case of an update if the revision doesn't match, we reconcile.
In case of create we only run the the reconcile if the helmrepository has an artifact. In which case, we do the same thing that has been done before. We call GetCharts with the profiles predicate and the values.
Once that's done, this information is cached. The cache is always recent. It might be that there is a brief period where some information for a profile can't be found if there is no cache for it yet, but in that case the user just refreshes. Chances are that the cache is filled up earlier than the user requesting information about said object.
The following folder structure is used to cache items:
➜  helm-cache tree
.
├── cache.lock
└── wego-system
    └── podinfo
        ├── podinfo
        │   └── 6.0.1
        │       └── values.yaml
        └── profiles.yaml

The cache.lock is global and not helmnamespace/helmname because there is a scenario where if we are checking that the folder exists before creating, another process creates it, it returns false, and tries to create it and overwrites whatever has been put there. To ensure that it's recent, we always lock. We could use optimistic locking and versioning, but I doubt that, that is needed here.
The top folder is helm-namespace and under it is helm-name. Then followed by a profiles.yaml file which is the yaml marshalled profile information:
- available_versions:
  - 6.0.0
  - 6.0.1
  description: Podinfo Helm chart for Kubernetes
  home: https://github.com/stefanprodan/podinfo
  kube_version: '>=1.19.0-0'
  maintainers:
  - email<EMAIL_ADDRESS>    name: stefanprodan
  name: podinfo
  sources:
  - https://github.com/stefanprodan/podinfo

This information is usually small data, so it can sit in a single file. The values is the bigger fish. We save values according to the name of the profile ( which should be unique per helmRepository ( I HOPE ) ) and under that we have folders of versions. And in those versions we'll have a values.yaml file if there are values for that version.
The values file contains whatever was returned before. Which is the full raw value including comments. We already parse that correctly.


BUG GH9057

Have DataFrame.to_hdf() raise an error when using pytables with non-string
column types
closes #9057

I'm definitely open to moving this logic to the most appropriate place, and will rely on your judgement as to where that is. As far as I can tell, though, the code path through to_hdf() doesn't ever get to validate_col() prior to the error that we're trying to prevent/mask with this patch.
The calls to validate happen after table_creation (i.e. where the original error comes from).
For example:
james@basalt ~/code/git/pandas/pandas $ git --no-pager diff | tail
     if append:
         f = lambda store: store.append(key, value, **kwargs)
@@ -1569,6 +1569,7 @@ class IndexCol(StringMixin):

     def validate_col(self, itemsize=None):
         """ validate this column: return the compared against itemsize """
+        raise Exception("We'll never make it here")

         # validate this column for string truncation (or reset to the max size)
         if _ensure_decoded(self.kind) == u('string'):

(testenv)james@basalt ~/code/git/pandas $ nosetests -v pandas/io/tests/test_pytables.py:TestHDFStore.test_to_hdf_with_integer_column_names
test_to_hdf_with_integer_column_names (pandas.io.tests.test_pytables.TestHDFStore) ... ERROR

======================================================================
ERROR: test_to_hdf_with_integer_column_names (pandas.io.tests.test_pytables.TestHDFStore)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/james/code/git/pandas/pandas/io/tests/test_pytables.py", line 4625, in test_to_hdf_with_integer_column_names
    self.assertRaises(ValueError, df.to_hdf, path, 'df', format='table', data_columns=True)
  File "/home/james/code/git/pandas/pandas/util/testing.py", line 1576, in assertRaises
    _callable(*args, **kwargs)
  File "/home/james/code/git/pandas/pandas/core/generic.py", line 918, in to_hdf
    return pytables.to_hdf(path_or_buf, key, self, **kwargs)
  File "/home/james/code/git/pandas/pandas/io/pytables.py", line 292, in to_hdf
    f(store)
  File "/home/james/code/git/pandas/pandas/io/pytables.py", line 287, in <lambda>
    f = lambda store: store.put(key, value, **kwargs)
  File "/home/james/code/git/pandas/pandas/io/pytables.py", line 835, in put
    self._write_to_group(key, value, append=append, **kwargs)
  File "/home/james/code/git/pandas/pandas/io/pytables.py", line 1284, in _write_to_group
    s.write(obj=value, append=append, complib=complib, **kwargs)
  File "/home/james/code/git/pandas/pandas/io/pytables.py", line 3792, in write
    table = self._handle.create_table(self.group, **options)
  File "/home/james/miniconda3/envs/testenv/lib/python3.4/site-packages/tables/file.py", line 1060, in create_table
    chunkshape=chunkshape, byteorder=byteorder)
  File "/home/james/miniconda3/envs/testenv/lib/python3.4/site-packages/tables/table.py", line 811, in __init__
    self.description = Description(description)
  File "/home/james/miniconda3/envs/testenv/lib/python3.4/site-packages/tables/description.py", line 466, in __init__
    if name.startswith('_v_'):
AttributeError: 'numpy.int64' object has no attribute 'startswith'

----------------------------------------------------------------------
Ran 1 test in 0.010s

FAILED (errors=1)

Should there be a separate validation call somewhere higher in write()? Or am I missing something obvious here?

Try something like this
diff --git a/pandas/io/pytables.py b/pandas/io/pytables.py
index 458a245..aea9336 100644
--- a/pandas/io/pytables.py
+++ b/pandas/io/pytables.py
@@ -1535,6 +1535,12 @@ class IndexCol(StringMixin):
                 self.typ = _tables(
                 ).StringCol(itemsize=min_itemsize, pos=self.pos)

+    def validate(self, handler, append, **kwargs):
+        self.validate_names()
+
+    def validate_names(self):
+        pass
+
     def validate_and_set(self, handler, append, **kwargs):
         self.set_table(handler.table)
         self.validate_col()
@@ -2080,6 +2086,10 @@ class DataIndexableCol(DataCol):
     """ represent a data column that can be indexed """
     is_data_indexable = True

+    def validate_names(self):
+        if not Index(self.values).is_object():
+            raise ValueError("cannot have a non-object label DataIndexableCol")
+
     def get_atom_string(self, block, itemsize):
         return _tables().StringCol(itemsize=itemsize)

@@ -3752,6 +3762,9 @@ class AppendableTable(LegacyTable):
                          min_itemsize=min_itemsize,
                          **kwargs)

+        for a in self.axes:
+            a.validate(self, append)
+
         if not self.is_exists:

Hmm, yeah, that works. Can I ask, what's the expected behaviour when a user tries to use unicode column name? Is this test actually testing for the right behaviour or is it irrelevant?

@jameshiebert

can you comprehensively test for the this a bit more (e.g. make datetimes the actual names of the columns for example), I think we can only allow string-likes.
I think your unicode test is good. best to prob go thru all of the index types and make sure that ONLY the string-like ones work.

e.g.
for i in [tm.makeIntegerIndex(),tm.makeUnicodeIndex()......]:
    # test that these raise

@jreback Thanks for the suggestions. I used your pytables.py code straight-up, but as for the test, I think that what I pushed covers all of the index types. If I missed anything, please let me know.

pls add a release note in v0.17.0.txt

can you rebase and squash, contributing docs are here if you need help

@jreback It should be good to go.

ok, why don't you rebase; ping when green.

@jreback This PR should be good to go once again.

thanks!


Add GitHub Action for publishing on PyPI

Now we need to set the PYPI_API_TOKEN secret, I don't have the permissions to do that.

Thanks! Now I updated your permission as OWNER of the rpm-py-installer. Can you get it?
Now please still don't tag the new version yet. I have things to do before the release.
As I said I want to upgrade setup.py and I also actually am reviving the CentOS 6 case using https://vault.centos.org/6.10/ on CI now.

Ah I see. It was a permission of this GitHub repository. Just moment. I will take a look at it.

As I said I want to upgrade setup.py and I also actually am reviving the CentOS 6 case using https://vault.centos.org/6.10/ on CI now.

Don't worry, I won't.

I created the token from https://pypi.org/manage/project/rpm-py-installer/settings/ - API tokens - "Create a token for rpm-py-installer". Then I did set it on Settings - Secrets - Actions - Repository secrets.

Ok, thanks, that should be enough for this action to work.


compile target tools in agent/src/ebpf failed

Expected Behavior
compile success
Actual Behavior
$ cargo b
   Compiling deepflow-agent v0.1.0 (/home/harris/projects/deepflow/agent)
error: failed to run custom build command for `deepflow-agent v0.1.0 (/home/harris/projects/deepflow/agent)`

Caused by:
  process didn't exit successfully: `/home/harris/projects/deepflow/agent/target/debug/build/deepflow-agent-8bd3745c2a70d140/build-script-build` (exit status: 101)
  --- stdout
  cargo:rustc-env=AGENT_NAME=deepflow-agent-ce
  cargo:rustc-env=REV_COUNT=6196

  cargo:rustc-env=COMMIT_DATE=2022-08-04

  cargo:rustc-env=REVISION=f259d72b9a5c2c91756be98a271f7879c120cc84

  cargo:rustc-env=RUSTC_VERSION=rustc 1.62.1 (e092d0b6b 2022-07-16)

  --- stderr
  tools/ebpftobuffer.c: In function ‘main’:
  tools/ebpftobuffer.c:83:13: warning: implicit declaration of function ‘write’; did you mean ‘fwrite’? [-Wimplicit-function-declaration]
     83 |         if (write(target_fd, data_buf, data_len) != data_len) {
        |             ^~~~~
        |             fwrite
  tools/ebpftobuffer.c:98:9: warning: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Wimplicit-function-declaration]
     98 |         close(target_fd);
        |         ^~~~~
        |         pclose
  user/probe.c: In function ‘bpf_attach_probe.constprop’:
  user/probe.c:223:47: warning: ‘/id’ directive output may be truncated writing 3 bytes into a region of size between 1 and 4096 [-Wformat-truncation=]
    223 |                 snprintf(buf, sizeof(buf), "%s/id", event_path);
        |                                               ^~~
  In function ‘bpf_attach_tracing_event’,
      inlined from ‘bpf_attach_probe.constprop’ at user/probe.c:352:6:
  user/probe.c:223:17: note: ‘snprintf’ output between 4 and 4099 bytes into a destination of size 4096
    223 |                 snprintf(buf, sizeof(buf), "%s/id", event_path);
        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  user/tracer.c: In function ‘tracer_sockopt_get’:
  user/tracer.c:1091:32: warning: taking address of packed member of ‘struct bpf_tracer_param’ may result in an unaligned pointer value [-Waddress-of-packed-member]
   1091 |                         rx_q = &btp->rx_queues[j];
        |                                ^~~~~~~~~~~~~~~~~~
  user/tracer.c: In function ‘dispatch_worker’:
  user/tracer.c:999:49: warning: ‘-ring-’ directive output may be truncated writing 6 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
    999 |                 snprintf(name, sizeof(name), "%s-ring-%d", tracer->name, i);
        |                                                 ^~~~~~
  user/tracer.c:999:46: note: directive argument in the range [0, 256]
    999 |                 snprintf(name, sizeof(name), "%s-ring-%d", tracer->name, i);
        |                                              ^~~~~~~~~~~~
  user/tracer.c:999:17: note: ‘snprintf’ output between 8 and 73 bytes into a destination of size 64
    999 |                 snprintf(name, sizeof(name), "%s-ring-%d", tracer->name, i);
        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In function ‘sockopt_init’,
      inlined from ‘ctrl_init’ at user/ctrl.c:123:12:
  user/ctrl.c:99:9: warning: ‘strncpy’ output may be truncated copying 107 bytes from a string of length 255 [-Wstringop-truncation]
     99 |         strncpy(srv_addr.sun_path, ipc_unix_domain,
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    100 |                 sizeof(srv_addr.sun_path) - 1);
        |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  user/ctrl_tracer.c: In function ‘tracer_dump’:
  user/ctrl_tracer.c:108:24: warning: taking address of packed member of ‘struct bpf_tracer_param’ may result in an unaligned pointer value [-Waddress-of-packed-member]
    108 |                 rx_q = &btp->rx_queues[j];
        |                        ^~~~~~~~~~~~~~~~~~
  In function ‘sockopt_init’,
      inlined from ‘ctrl_init’ at user/ctrl.c:123:12:
  user/ctrl.c:99:9: warning: ‘strncpy’ output may be truncated copying 107 bytes from a string of length 255 [-Wstringop-truncation]
     99 |         strncpy(srv_addr.sun_path, ipc_unix_domain,
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    100 |                 sizeof(srv_addr.sun_path) - 1);
        |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /usr/bin/ld: cannot find -lelf
  /usr/bin/ld: cannot find -lz
  /usr/bin/ld: cannot find -lc
  collect2: error: ld returned 1 exit status
  make: *** [Makefile:100: tools] Error 1

  thread 'main' panicked at 'compile libebpf.a error!', build.rs:68:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Then, I use make in agent/src/ebpf, it succeed. But when I use make tools to compile target tools, it failed:
$ make tools
  TOOLS    deepflow-ebpfctl
user/ctrl_tracer.c: In function ‘tracer_dump’:
user/ctrl_tracer.c:108:24: warning: taking address of packed member of ‘struct bpf_tracer_param’ may result in an unaligned pointer value [-Waddress-of-packed-member]
  108 |                 rx_q = &btp->rx_queues[j];
      |                        ^~~~~~~~~~~~~~~~~~
In function ‘sockopt_init’,
    inlined from ‘ctrl_init’ at user/ctrl.c:123:12:
user/ctrl.c:99:9: warning: ‘strncpy’ output may be truncated copying 107 bytes from a string of length 255 [-Wstringop-truncation]
   99 |         strncpy(srv_addr.sun_path, ipc_unix_domain,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  100 |                 sizeof(srv_addr.sun_path) - 1);
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/ld: cannot find -lelf
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [Makefile:100: tools] Error 1

I noticed a static link in Makefile:
tools: $(LIBBPF_DIR) $(LIBTRACE)
        $(call msg,TOOLS,deepflow-ebpfctl)
        $(Q)$(CC) $(CFLAGS) --static -g -O2 user/ctrl_tracer.c user/ctrl.c libebpf.a -o deepflow-ebpfctl -lelf -lz -lpthread

BUT, static link libc is a good idea^1? And when I removed static link it compile success.
OS
Operating System: Fedora Linux 36 (Server Edition)
     CPE OS Name: cpe:/o:fedoraproject:fedora:36
          Kernel: Linux 5.18.13-200.fc36.x86_64
    Architecture: x86-64

The main reason for this problem is the lack of the following static link libraries:

libelf.a
libz.a
libc.a

Fedora does not seem to have a statically linked repo except libc, so it needs to be compiled by yourself. The following are my compilation environment and steps:
environment:
OS:       Fedora Linux 36 (Server Edition)
Kernel:  Linux fedora 5.17.5-300.fc36.x86_64 #1 SMP PREEMPT Thu Apr 28 15:51:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
clang version: clang version 11.0.0 (Fedora 11.0.0-3.fc33)
llvm version:   llvm11-11.1.0-6.fc35
rust version:    rustc 1.62.1
compile libelf.a :
git clone https://github.com/WolfgangSt/libelf.git
cd libelf
./configure
make
cp ./lib/libelf.a /usr/lib64

Compile libz.a :
git clone https://github.com/madler/zlib.git
cd zlib
./configure
make
cp libz.a /usr/lib64

Install libc.a:
dnf install glibc-static-$(rpm -qa | gawk 'match($0, "glibc-([0-9]+\.[0-9]+-[0-9]+).*",a) {print a[1]}').fc36.x86_64

And try to run cargo b again.
On local machine, you can use dynamic link for simplicity, and static linking is used by default for better portability.


Mark that a dependency should never be a query parameter.

This is a side-effect of the change in 1.3.9 and the way that I've structured the consumption of dependencies in the example app.
The __init__() method of the repository looks like this:
    def __init__(
        self,
        limit_offset: LimitOffset | None = None,
        updated_filter: BeforeAfter | None = None,
    ) -> None:
        ...
        if limit_offset is not None:
            self.apply_limit_offset_pagination(limit_offset)
        if updated_filter is not None:
            self.filter_on_datetime_field(updated_filter)

If the repository is included as a dependency and if the the limit_offset and updated_filter dependencies are available those dependencies get consumed by the repository, and their dependencies end up documented as query params. However, for routes where the limit_offset and updated_filter dependencies aren't available to the route, they themselves are shown as query params:

The reason I use this pattern is that without it, every list route, e.g., /users or /users/{user_id}/items has to do something like this:
    @get(
        dependencies={
            "limit_offset": Provide(limit_offset_pagination),
            "updated_filter": Provide(filter_for_updated),
        }
    )
    async def get(
        self,
        repository: UserRepository,
        is_active: bool = Parameter(query="is-active", default=True),
        limit_offset: LimitOffset,
        updated_filter: BeforeAfter,
    ) -> list[UserModel]:
        repository.apply_limit_offset_pagination(limit_offset)
        repository.filter_on_datetime_field(updated_filter)
        return await repository.get_many(is_active=is_active)

which reduces down to this if the repository can be left to optionally consume the dependency if it is available:
    @get(
        dependencies={
            "limit_offset": Provide(limit_offset_pagination),
            "updated_filter": Provide(filter_for_updated),
        }
    )
    async def get(
        self,
        repository: UserRepository,
        is_active: bool = Parameter(query="is-active", default=True),
    ) -> list[UserModel]:
        return await repository.get_many(is_active=is_active)

What about a user-land configuration that is similar to the RESERVED_KWARGS constant, and if a field name appears in there, it is ignored for doc-generation purposes?
def create_parameters(...) -> List[Parameter]:
    ...
    for f_name, field in handler_fields.items():
        ...
        if f_name not in RESERVED_KWARGS and f_name not in <collection of names declared by user to be excluded from docs>:
            ...

The collection of names could be configurable at each level of the app hierarchy and resolved for the handler similar to dependencies.
I'm not sure what such a configuration should be named, which is why I've used that awkward placeholder in the example above.

Hm this indeed seems like a bit of a tougher issue to resolve. It effectively comes down to telling apart an unsatisfied dependency from an optional query/header/cookie parameter.
As it is I don't think we can, an optional type with a None value is the same between those two cases, so maybe an approach here would be to explicitly mark dependencies that can be unsatisfied/optional, like you suggest above.
Imho keeping track of dependencies in an extra dict is a bit cumbersome and not that intuitive, so I was kind of thinking about marking these occurences in some other way such that most of the overhead could be transferred away from the developer (who has to manually maintain these dicts) and to Starlite, which can then figure things out automatically.
To this end I'd propose a solution based on type hints, in which we introduce a dummy-type Dependency (name TBD) with which we mark dependencies where needed. This type information can then be used to make decisions on when to include/exclude parameters in specific circumstances.
Example app:
from starlite import Starlite, get, Provide, Dependency
from starlite.app import DEFAULT_OPENAPI_CONFIG

class LimitOffset:
    def __init__(
        self,
        limit: str,
        offset: str,
    ):
        ...

class Repo:
    def __init__(
        self,
        limit_offset: Dependency[LimitOffset] | None,
    ) -> None:
        ...

# Repo has unsatisfied dependencies: Transitive dependency *should not* show up in OpenAPI
@get("/test1", dependencies={"a": Provide(Repo)})
def handler1(a: int) -> str:
    return "OK"

# Repo has satisfied dependencies: Transitive dependency *should* show up in OpenAPI
@get(
    "/test2",
    dependencies={
        "a": Provide(Repo),
        "limit_offset": Provide(LimitOffset),
    },
)
def handler2(a: int) -> str:
    return "OK"

app = Starlite(
    route_handlers=[
        handler1,
        handler2,
    ],
    openapi_config=DEFAULT_OPENAPI_CONFIG,
)

This app has two handlers which exhibit the problem you laid out above, as far as I understood. test1 has the issue, test2 is a "valid" configuration.
By marking limit_offset: Dependency[LimitOffset] | None, in the Repo dependency we are then able to tweak the create_parameters method by adding a check for this at the start of the loop over the handler fields:
for f_name, field in handler_fields.items():
    if field.type_ == Dependency and f_name not in dependencies:
        if field.allow_none:
            continue
        else:
            raise Exception(
                f"{f_name} dependency not satisfied and not optional in handlers {', '.join(route_handler.paths)}"
            )
    # rest of the loop as before

The Dependency type is incredibly simple:
class Dependency(Generic[T]):
    def __class_getitem__(cls, item):
        return cls

This will accomplish two things at once where, if a parameter representing a dependency anywhere in a dependency chain is...

optional and the dependency is not available, it is skipped and will not appear in the schema.
not optional and the dependency is not available, an exception is raised because the dependency can not be satisfied, which is probably an error.

The second part can of course be omitted if it's too strict. I'm not 100% certain how Starlite currently handles unsatisfied dependencies in other contexts, so it'd probably be best to emulate whatever it does there.
Let me know your thoughts on this. I'm relatively new to this so I'm bound to simply not know about a couple edge cases, I'm sure, but to me this seems like a somewhat workable approach at first glance.

That's a good clarification of the issue, thanks.
LMK if I'm off the mark anywhere.
Dependencies have a few properties that are interesting to the problem:

dependencies are either allowed to be parameters or not (will be marked at injection point with type annotation)
dependencies are either required to be provided via the injection mechanism, or not (marked at injection point with a default value or Optional type, or both)
dependencies are either provided somewhere in the handler's resolvable path, or not.

We will use the Dependency type annotation via model field in create_parameters() as a marker to differentiate between the "allowed to be parameter or not" property of the dependency when generating docs. This lets us bail early if the dependency has a default provided, and should not be a documented parameter.
Then also that there is an error state that occurs when:

the dependency is not allowed to be a parameter (marked by using Dependency[T] at injection point).
the dependency is not optional (again marked at injection point)
dependency is not declared somewhere in the handler's resolvable path.

Have I got that right? I really like where you are going and definitely better to not force the developer to book-keep the solution themselves.
I have some points/clarifications:

Does the way you use __class_getitem__(cls...): return cls mean that type checkers will assume the value of that parameter to be of the same type as the type parameter to the generic class? Are there any edge-cases to this we'd need to be wary of?
starlite.kwargs.Dependency already exists, would it make sense to make that generic and use it as the type? Otherwise I think we should use a different name.
for the case where the dep is not allowed to be a parameter, and is not "provided" should we be raising an error from the doc generation layer? I agree, there should be an exception for the case somewhere. At the moment if an injected dependency isn't provided we return a 400, e.g.,: "Missing required parameter user_repository for url http://localhost:8000/v1/users/c11f5e35-99d0-409b-bddd-7c136b81d306/items". I think your solution here is fine given that it is not already an error from the application but it is a change in runtime behavior, so I wonder how @Goldziher feels about that WRT semantic releases. We do have the option of just ignoring the case for doc generation and looking at the runtime validation of the dependencies as a separate issue and scheduling it into a more major release (even if the exception still ends up right here where you have it).
Should we look at field.default instead of, or in combination with field.allow_none in create_parameters()? If we choose to just ignore the error case for now then this isn't an immediate issue.

Docs and tests will be important for this, too.
I'd prefer to rebase #129 on this work so I'd be happy to chip in with working on any part of it.
So I suppose we need to get a nod from @Goldziher that he'd be happy with the api design, then we can press forward with impl, tests and docs, or reassess if need be.

Hi guys, great to see this kind of process here finally 😀.
I see no issue with going for a minor version (1.4.0) rather than a patch version (1.3.10). The change here is also not a backwards breaking change really, although it might cause some exceptions raised in update. It's just important to ensure that the exception communicates the solution clearly, but that's easy to do.

Does the way you use class_getitem(cls...): return cls mean that type checkers will assume the value of that parameter to be of the same type as the type parameter to the generic class? Are there any edge-cases to this we'd need to be wary of?

To be honest, my knowledge of advanced type hinting is still somewhat lacking, so I'm not 100% sure on the ramifications of this. I'm sure there's a cleaner way to implement a dummy-type of sorts like this, I just don't know of it yet. Suggestions on how to handle this better a definitely welcome. The only requirement for this annotation is that we'll be able to tell it apart from the class it wraps at analysis time.

starlite.kwargs.Dependency already exists, would it make sense to make that generic and use it as the type? Otherwise I think we should use a different name.

That could make sense, since internally it's already creating a graph of these objects anyway, so using it as a type annotation as well could work. It'd certainly reduce the need to create another type to worry about. My one question here would be whether this would be mixing concerns too much (depending on what this class already does), so that should probably be figured out.

for the case where the dep is not allowed to be a parameter, and is not "provided" should we be raising an error from the doc generation layer?

I suppose it depends on what kind of error this is. Can the application run properly with an unsatisfied dependency or will this lead to undefined/unexpected behavior? If it's the latter, imho it should be an actual exception at startup to prevent a situation where things look like they're working, but in some cases they actually don't. If it's fine to have unsatisfied dependencies then I agree it should not be a hard failure but rather a warning/error in the docs or at runtime.

Should we look at field.default instead of, or in combination with field.allow_none in create_parameters()? If we choose to just ignore the error case for now then this isn't an immediate issue.

We can rely on self.required is False and default_value is None as well since those two together form the value for allow_none. This largely came from me digging through the pydantic source code for a useable property for this example, so I'm not terribly attached to it in any case. Originally I figured this field would contain additional info about the type hinting here but that turned out to be false, so it doesn't add any more info than just using those two fields instead.

So I just ran this little test:
from typing import Any, Generic, TypeVar

T = TypeVar("T")

class Dependency(Generic[T]):
    def __class_getitem__(cls, item):
        return cls

def fn(param: Dependency[int]) -> None:
    param += 3

and mypy complains:
src/app/__init__.py:12: error: Unsupported operand types for + ("Dependency[int]" and "int")  [operator]
src/app/__init__.py:12: error: Incompatible types in assignment (expression has type "int", variable has type "Dependency[int]")  [assignment]
Found 2 errors in 1 file (checked 1 source file)
ERROR: 1

If we lose the actual type of the dependency where it is injected it is less than ideal.
I wonder if it could work if we follow the pattern that is already used by the Parameter function, e.g.:
class Repo:
    def __init__(
        self,
        limit_offset: LimitOffset | None = NonParameter(default=None),
    ) -> None:
        ...

(I'm not necessarily advocating for the name NonParameter but I think it needs to be different from Dependency to avoid the name collision with kwargs.Dependency.)
In Parameter, kwargs like header, parameter and cookie are written to FieldInfo.extra which is then inspected in the create_parameter() function to determine where the parameter should be documented. Maybe we could limit the kwargs that the NonParameter could accept to a subset that makes sense, have it create a FieldInfo object that represents the dependency and put a value like non_parameter=True into extra and then inspect for that in create_parameters().
It's late here now so I haven't tested that idea out at all. I'll try to put some time into it tomorrow morning.

Wouldn't it be simpler to add an exclude option to route handlers that allow excluding specific keys from the openapi docs?
From my PoV the fact that the Repo has these parameters declared and is in the dependency chain mean that the parsing is correct. We cannot know in advance where these will be required or not.
I would therefore propose something along these lines:
   @get(
        dependencies={
            "limit_offset": Provide(limit_offset_pagination),
            "updated_filter": Provide(filter_for_updated),
        },
        exclude_from_docs=["limit_offset", "updated_filter"]
    )
    async def get(
        self,
        repository: UserRepository,
        is_active: bool = Parameter(query="is-active", default=True),
    ) -> list[UserModel]:
        return await repository.get_many(is_active=is_active)

Would that work for the pattern where limit_offset may be defined at an arbitrary depth up the dependency tree above the handler method in your example? I.e. it might only be defined at the controller level. Should the exclude list affect things beyond its own scope? In such a case, the handler method would affect dependencies on the controller, at least for schema generation.
Imho the parsing is not quite working correctly when unsatisfied dependencies show up in the docs by default.

Would that work for the pattern where limit_offset may be defined at an arbitrary depth up the dependency tree above the handler method in your example? I.e. it might only be defined at the controller level. Should the exclude list affect things beyond its own scope? In such a case, the handler method would affect dependencies on the controller, at least for schema generation.
Imho the parsing is not quite working correctly when unsatisfied dependencies show up in the docs by default.

We cannot know in advance where these will be required or not.

To this point: With the stuff outlined above, we could, so it's definitely possible.

You'd use exclude only on route handlers, which are the "root" level as far as schema generation is concerned, so yes, I think it will resolve the issue. Or perhaps I don't understand it in full.

Wouldn't it be simpler to add an exclude option to route handlers that allow excluding specific keys from the openapi docs?

In example you've used, it is redundant to exclude those dependencies at the handler level as they are provided for that route and so get resolved to their underlying parameters correctly. The issue is for routes where the dependencies are not provided. E.g.,
@post(exclude_from_docs=["limit_offset", "updated_filter"])
async def post(self, ...) -> UserModel:
    ...

That would have to be repeated for every other route that needs to exclude them.
However, My initial instinct was along these lines too - although I did agree with @timwedde that a solution that took the book-keeping away from the programmer would be nice, and that is what has sent us down this path of looking at alternatives.
@Goldziher Is there any reason this exclude_from_docs couldn't be declared at any level? E.g., in  the case of limit_offset in the example app, I'd be tempted to define it at the application level so that it never shows in docs. We'd then resolve the exclude_from_docs for the handler at doc generation time pulling in exclusions from every node on the handlers path up to the app.
In summary, we have come up with 3 ways to go about this:

Exclude by name

@post(exclude_from_docs=["limit_offset", "updated_filter"])
async def post(self, ...) -> UserModel:
    ...

No doubt the simplest approach, and if can be done at any level of the app, would at least solve my use-case in example app.

Exclude by type

class Repo:
    def __init__(
        self,
        limit_offset: Dependency[LimitOffset | None],
    ) -> None:
        ...

Has the benefit of being declared non-parameter at the point of injection (which is similar in utility to being able to define exclude_from_docs in higher up levels of the app structure - I.e., no repetition needed to always exclude). However (AFAICT), we lose the type of the underlying dependency in the function where it is injected.

Exclude by value

class Repo:
    def __init__(
        self,
        limit_offset: LimitOffset | None = NonParameter(default=None),
    ) -> None:
        ...

Same benefits as Exclude by Type but we retain the typing info. There's a precedent for the pattern with Parameter and this would also open up the use of default_factory for non-parameter dependencies defaults. I'm not sold on NonParameter name though.
Personally, I give 1 vote to #1 for simplicity, and 1 vote to #3 for the ergonomics. Losing the typing info rules out #2 IMO.

Yeah, if there's no way to keep the type then 2 is indeed not really workable. I did toy around with distinct None type unions like I edited in my previous post but that's likely too hacky in any case.
The exclude by value (3) is getting somewhat close to FastAPI's way of resolving dependencies where you simply declare a Depends(method) every time you need to inject something as a dependency. This would resolve the problem in transitive dependencies and is similar to having to add a NonParameter(something), but the approach here would be simpler.
Personally I'd much prefer tackling the problem at the root by marking the optional dependency somehow versus patching the symptoms at the other end via an exclude dict, but I can see arguments for both.
In my case my vote would go towards 3 since I think it's a nicer pattern overall than 1 would be. As far as the name goes, it could maybe be something like OptionalDependency(something) instead of NonParameter since it's likely better to declare what something is versus what something is not.

Yeah, if there's no way to keep the type then 2 is indeed not really workable.

Just for interest's sake, I'd love to know if there is a solution for this type of thing, even if we don't use it. Perhaps it could be solved with a plugin to override the type within the scope of the function, but after reading the status update from SQLAlchemy on Mypy / Pep-484 Support for ORM Mappings, I'm not sure supporting a plugin is a can of worms I'm keen to open for myself. I think that part of the ecosystem needs time to develop - hopefully it gets to a point where there is a standard API for type checker plugins so that they worked for all the different type checkers, not just mypy.

I'd much prefer tackling the problem at the root by marking the optional dependency somehow versus patching the symptoms at the other end via an exclude dict

I'm coming down here too.

As far as the name goes, it could maybe be something like OptionalDependency(something)

Works for me. It is a dependency that doesn't need to be provided, so optional in that sense.

explicitly

Yes explicit declarative nature of 3 is a +.
I also like that we'd be making some of the functionality of Field available to these dependencies. E.g., runtime validation of the dependency value, the default factories, etc, that would otherwise only  be available to explicit parameters with Parameter (or by using Field directly, I suppose that would work?).
But devil is always in the detail. I've just started work for the day so should have some time later tonight to put some work in to this. So I'd probably say I'm 0.5 for 1. and 1.5 for 3. with my uncertainty based on seeing how the implementation unfolds.

On the topic of where, if at all we should raise that exception we've discussed, if a dependency is duplicated it raises out of handlers.base.validate_dependency_is_unique():
/usr/local/lib/python3.10/site-packages/starlite/handlers/base.py:115: in validate_dependency_is_unique
    raise ImproperlyConfiguredException(
E   starlite.exceptions.ImproperlyConfiguredException: Provider for key entity_mappings_repository is already defined under the different key repository. If you wish to override a provider, it must have the same key.

So respective of what you guys wrote above about options 1,2,3.
Option 3 is possible, it's basically equivalent to the pydantic UnDefined type. Mind you, it's going to be annoying to type and from my PoV it's not actually more ergonomic - I dislike parameter bloat. Still, if you guys feel strongly about it, it's fine by me - I don't think there is right or wrong here.
Option 1 is simplest and to me easiest to grasp, and I in general follow the notion of "simple is better than complex". You could have this parameter declared on any level, and the add logic to resolve it. But to me a degree of repetition is not so bad- DRY is not a religion 😜.
So in summary, you guys go ahead and decide how to proceed here.
Please make sure to update the documentation as well 😁

I've done a quick and dirty implementation of each approach in my fork, and also a branch applying each approach in the example app.
Exclude by name approach
Starlite: https://github.com/starlite-api/starlite/compare/main...peterschutt:exclude-by-name
Example app: https://github.com/starlite-api/starlite-pg-redis-docker/compare/main...peterschutt:with-exclude-by-name
Exclude by value approach
Starlite: https://github.com/starlite-api/starlite/compare/main...peterschutt:exclude-by-value
Example app: https://github.com/starlite-api/starlite-pg-redis-docker/compare/main...peterschutt:with-exclude-by-value

OK I'm pretty sure I know where I sit on this now.
TL;DR
I propose adding a Dependency function that sits alongside Parameter and Body. I think it fits, and that Dependency deserves to be a front-line name in the starlite api, not buried inside the kwargs module with a narrow, mostly internal scope of usage.
My reasoning follows.
Thinking about the app at runtime from an information flow point of view. Any handler can use information provided by the client or developer.
Client info comes from parameters (wherever they originate) and payload/body/form data, and developer information can quite literally come from anywhere else, but we have a specific system for developers to provide information to handlers, which is dependency injection. Dependencies themselves can either source their information from the client, or from the developer, and so on recursively forever.
Default behavior is that we infer any function parameter in the tree of handler function parameters down through recursive dependency function parameters to be a developer provided dependency if a dependency is "provided" to the handler with the same key or name as the function parameter. Anything else, we assume comes from the client as a query parameter, unless we are told different via reserved kwargs, or the Parameter function.
Any function parameter in the dependency graph, be it a dependency or parameter can have a default value, and so not be required to be provided if sensible defaults can be deduced by the developer. That works for both dependencies and parameters with no change to plain typed python function declaration syntax, but breaks down for doc generation where dependencies have default values that do not need to be sourced from the parameter.
In the minimal case, we can do a very good job of inferring the source of function parameters, and generating minimal docs from that information for the typical case, which allows keeping parameter bloat to a minimum. But at some point, we need more information from the developer about each of the information types to be able to offer a richer experience/documentation.
For client provided information, we have the Parameter and Body functions through which the developer can give more information to Starlite about how they should be documented and validated, but there is no analogy to that for the developer provided information.
This is where I think a Dependency function truly fits in. And, I actually think it should be called Dependency, not OptionalDependency like we've discussed earlier. I think the current kwargs.Dependency name, is too far away from the front-line user interface, and it's usage too internal for us to worry about it crowding the developer interaction API. Whether that means we do a breaking change and change the name of kwargs.Dependency to something else, or let them coexist (perhaps through a deprecation period) is a decision we have to make. Having the name Dependency alongside Parameter and Body just seems "right".
It would also allow us to make it an error condition where a function parameter is explicitly declared a developer provided value, has no default, and isn't provided to the handler, and I think that should arise out of handlers.base like other ImproperlyConfiguredException cases.
If interested in how I see the implementation looking (it really is no different to Parameter and Body) see https://github.com/starlite-api/starlite/compare/main...peterschutt:exclude-by-value.
I'll leave this for a day or two before I get started in case there is anything that needs to be looked at that I haven't considered, or if anyone would really like to push back on my reasoning.
Cheers!

I already looked at both. As I wrote earlier, both solutions are fine by me. If you feel this is the better solution, go ahead .

Yep cool, I know you were on board but I just want to be very clear about what I'm doing and why, especially given that you only threw me the keys a couple of days ago.
So especially, I just want to know you are on board with me taking the name "Dependency", and that there'll be another possible startup exception case, both of which are new to the conversation. So I'll now press ahead.
Thanks!

I am 💯 onboard

That does make sense to me, since the argument is effectively exactly the same as for the Parameter stuff that already exists in Starlite, so it's probably the most sensible way forward since it's the most similar approach we can likely come up with.

Thanks for feedback guys.

[ ] Implement Dependency function - consider the params that we expose from Field.

test use of Field.default_factory
some in/out tests that test that the custom stuff we put in FieldInfo.extra is there.

[ ] Implement skip declared dependencies for parameter documentation if the dependency not provided.

test declared optional type and undefined default, e.g., dep: int | None = Dependency()
test non-optional type with

[ ] Build logic for checking that all declared dependencies are either provided or have a default value.
[ ] Docs for Dependency, include example.

Test cases:

[ ] In/out tests for Dependency function that tests the stuff we rely on in extra is there.
[ ] declared optional type and undefined default, e.g., dep: int | None = Dependency()
[ ] non-optional type and defined default, e.g., dep: int = Dependency(default=30)
[ ] error case, e.g., dep: int = Dependency() and dep not provided
[ ] test that parameters for dependencies reach the docs if the dependency is provided.
[ ] test that the default values reach the dependency if not provided.
[ ] some tests of validation Field parameters.

Closed in #137


Prevent using same remediator multiple times

Using the same remediator multiple times doesn't work today, because we can't create remediation CRs of the same kind with the same name. Until we find a better solution, prevent creating such NHC CRs.
ECOPROJECT-1478

/test 4.14-openshift-e2e

/lgtm

/lgtm


add node 10 support

Pull Request Test Coverage Report for Build 843408738

0 of 9 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 843015604:
0.0%

Covered Lines:
115

Relevant Lines:
115

💛  - Coveralls

Pull Request Test Coverage Report for Build 843408738

9 of 9 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 843015604:
0.0%

Covered Lines:
115

Relevant Lines:
115

💛  - Coveralls


[WIP] I76 authentication components

Change Summary
[Briefly summarise the changes that you made. Just high-level stuff]
Change Form
Fill this up (NA if not available). If a certain criteria is not met, can you please give a reason.

[x] The pull request title has an issue number
[ ] The change works by "Smoke testing" or quick testing
[ ] The change has tests
[ ] The change has documentation

Other Information
[Is there anything in particular in the review that I should be aware of?]

Resolves #29
Resolves #98

Codecov Report

Merging #95 (5a70be6) into main (ccf6bbb) will decrease coverage by 26.19%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##             main      #95       +/-   ##
===========================================
- Coverage   42.85%   16.66%   -26.20%
===========================================
  Files           7       13        +6
  Lines           7       18       +11
  Branches        1        5        +4
===========================================
  Hits            3        3
- Misses          4       15       +11

Flag
Coverage Δ

frontend
16.66% <0.00%> (-26.20%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/components/AuthFooter.vue
0.00% <0.00%> (ø)

client/components/AuthHeader.vue
0.00% <0.00%> (ø)

client/components/Form/AuthForm.vue
0.00% <0.00%> (ø)

client/components/Form/InputField.vue
0.00% <0.00%> (ø)

client/components/Form/TextBox.vue
0.00% <0.00%> (ø)

client/components/Input/ButtonElement.vue
100.00% <ø> (ø)

client/components/Section/NavBar.vue
0.00% <ø> (ø)

client/components/Section/PageFooter.vue
100.00% <ø> (ø)

client/pages/signup.vue
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

@otta8634 told me to.

Mistake, someone please delete the review

@codersforcauses/elucidate Does anyone know what's happening with this branch? Is this branch going to be merged eventually or just exists to share components?

Temporarily closed branch pending requirements


Fix incorrect field name, detected with atdgen 2.3.x

The atd annotation was misplaced. The JSON field name is now "type" rather than "label_type". Atdgen 2.3.3 (soon to be released) detects this.

Thanks @mjambon


Updated CONTRIBUITING.md file

resolves #706
Description
Added git commands in the contribution guidlines.
Type of PR

[ ] Bug fix
[ ] Feature enhancement
[ x] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes]

Checklist:

[x ] I have performed a self-review of my code
[x ] I have read and followed the Contribution Guidelines.
[x ] I have tested the changes thoroughly before submitting this pull request.
[x ] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x ] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

There have some issues check it once

@arghadipmanna101 All checks have passed. Please check and add gssoc label as well as the level to it. Merge it if approved. Thankyou.


Regex don't work's in Chrome browser

Hi.
I have a textfield where i put a pattern to validate a date:
<input type="text" name="form.dataDascimento" pattern="^(((0[1-9]|1[0-9]|2[0-8])[\/](0[1-9]|1[012]))|((29|30|31)[\/](0[13578]|1[02]))|((29|30)[\/](0[4,6,9]|11)))[\/](19|[2-9][0-9])\d\d$)|(^29[\/]02[\/](19|[2-9][0-9])(00|04|08|12|16|20|24|28|32|36|40|44|48|52|56|60|64|68|72|76|80|84|88|92|96)$" id="textfieldDataNascimento" class="form-control input-sm" tabindex="6"/>
This work's in firefox but, in Chrome (desktop or small device) don't.
Is a problem of compatibility?

The pattern attribute doesn't need ^ and $ because they are already assumed (the pattern regex needs to match the entire string). Maybe that's the issue?

I tested now and removing ^ and $ but don't work's

I think your parentheses are not balanced, and you also still have a couple ^$ in your subexpressions.


How to get device disconnect event

I want to know device disconnect callback or event but not getting any callback.

Sorry, I don't really understand what you are looking for. Nothing in the application connects to anything, so there will not be any disconnect events.

Adding to Soren's comment.  Remote ID is only 1 way broadcasts sent by the unmanned aircraft.  The receiver simply "listens" to the broadcasts to show the aircraft.  Since there are no actual (2-way) "connections".
The only way to handle an aircraft out of range is that the receiver is no longer getting the broadcasts.

Maybe related to this, there are already these feature requests open: #4 and #27.


feat(s2n-quic-qns): quic-attack fuzz testing

Description of changes:
This change (from @camshaft) adds the ability to havoc tx and rx payloads and the remote port to the QNS apps.
It can be used by setting the --havoc-rx and --havoc-tx flags in the perf app:
s2n-quic-qns perf server --havoc-tx --havoc-rx

Testing:
Local testing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hmm why are all of the windows builds trying to build with s2n-tls enabled now?


Add C++ compatibility

Just add extern "C { ... } for better C++ #include support

Sweet. Thanks!


[5.3] Added Container::getFactory() method

Without the BC change that https://github.com/laravel/framework/pull/15414 proposed.

This doesn't avoid the fact that this interface would really need to be added to the contract
We can add it later. There's plenty of implementation code without the proper contract in the rest of the framework. I even made a PR about that a gazillion years ago.

I'll amend with the CS fixes.

There's plenty of implementation code without the proper contract in the rest of the framework.

Yeh, I know. That's really unfortunate. I'm just trying to avoid making things worse. :)

@GrahamCampbell if this is merged, I can PR the BC change in the Container contract to master :smile:

Thanks for making those changes. I'd personally rather it only went to master, but I can see arguments for it going to 5.3 in this way too. Ultimately, Taylor will decide if he wants to merge this PR. :)

Awesome!
I feel this could be a starting point for decoupling other components from the container. I don't have a strong opinion on 5.3 or 5.4 other than a more immediate availability on projects.


5.1 Auto filtering

Basic filtering for plain strings. As Predix developer I can ask grid to present search field that is used to basic filtering of values. API hooks to get this working also on remote data source added.
UI should be implemented accordingly to provided design specs:

Generic auto filtering field is there. It's challenge will be local data.
The column autofiltering is not done yet, but with it actual filtering should be easier (as long as vaadin-grid handles value as wanted).

See Pull Request: https://github.com/vaadin/px-data-grid/pull/81

This works, I will do separate issue for look'n feel adjustments

This part of the specs isn't done, reopening

That part is excluded.


Stuck in init DB module

I tried installing Ghidra today to do some CTF's and I couln't get it to run on my Manjaro Linux Machine. It always got stuck on the "init DB module" screen. I installed JDK11 and tried downloading it via git and pacman. If someone can help me getting it to start that would be awesome. If there are any logs that I should share so that it makes it easier to see what might be wrong with it then please tell me.
Thanks Sol

You can check the application log in `{user home}/.ghidra/.ghidra_version/application.log.
Even better, the next time it is in that state, run these 2 commands from a console:
jps
jstack {Ghidra pid from the last command}

@sol-real Did you get your Ghidra working?

I just retried it and yes it works, but I don't know why. I haven't changed anything. Anyway thanks for the tips. If it happens again I will do what @dragonmacher recommended. Thanks for the helps everyone.


Add automountServiceAccountToken: true to fullstack OA serviceAccount

Description
Ticket: TBD
Incase the LogMonitoring feature is enabled within the fullstack OneAgent, then the fullstack OneAgent DaemonSet will need the kubernetes API-token (like the standalone LogMonitoring DaemonSet).

So we enable the automountServiceAccountToken setting on the fullstack's ServiceAccount, if logMonitoring can be configured

How can this be tested?
Play around with the rbac.logMonitoring.create value in helm
rbac.logMonitoring.create: true ==> automountServiceAccountToken: true
rbac.logMonitoring.create: false ==> automountServiceAccountToken: false

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 64.56%. Comparing base (2d2f1d9) to head (ba2842f).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##           release-1.4    #4175   +/-   ##
============================================
  Coverage        64.56%   64.56%
============================================
  Files              400      400
  Lines            26813    26813
============================================
  Hits             17311    17311
  Misses            8141     8141
  Partials          1361     1361

Flag
Coverage Δ

unittests
64.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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