Integrate new EvmEnvProvider in RPC

Describe the feature
ref #1525
new trait for fetching Envs needs to be added to EthApi and integrated into rpc builder pipeline
Additional context
No response

I can take this.

This essentially requires adding an additional trait bound everywhere to Client


Add API Reference Documentation using Quartodoc

See https://machow.github.io/quartodoc/get-started/overview.html

#157 is a start. We probably also want to add CI/CD and host multiple versions of the docs.

@tdstein are we calling this done now?

Yes - the initial work is done!


Extractor Fails with maven 3.9.0

I tried to run this dependency in my mavan-plugin-plugin 3.9.0 project and get the following build: error
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor (default-descriptor) on project ...:
The API of the mojo scanner is not compatible with this plugin version.
Please check the plugin dependencies configured in the POM and ensure the versions match.:
Receiver class com.github.gantsign.maven.tools.plugin.extractor.kotlin.KotlinMojoDescriptorExtractor does not define
or inherit an implementation of the
resolved method 'abstract org.apache.maven.tools.plugin.extractor.GroupKey getGroupKey()'
of interface org.apache.maven.tools.plugin.extractor.MojoDescriptorExtractor. -> [Help 1]

@freemanjp , any chance to get an updated release for Maven 3.9.x?
Is there anything we can help with (Maven 3.9 integration test PR, ...)?
As mentioned above, Maven Plugin Tools release 3.7.0 introduced a breaking change in MPLUGIN-378) of new method MojoDescriptorExtractor#getGroupKey()

I tried to apply a fix to overcome this issue. Upgraded all libraries and implemented new interface. Currently failing on integration tests for help-mojo. So a bit stuck, if someone wants to take the patch forward and submit a pull reques.
Upgrade_dependencies_and_implement_new_interface.patch


Refactoring

Thanks for cleaning up our codebase, investing in making our code easy to navigate pays dividends in the future!
I have a (weak) aesthetic preference for smaller refactors where possible (aka commit-by-commit instead of a single large PR like this). Partly that's just general arguments in favor of small-cls (revertability, easier to read diffs, fewer mistakes) and partly refactoring specifically generates a lot of commit churn, where it's harder to follow the git history.

Thanks for cleaning up our codebase, investing in making our code easy to navigate pays dividends in the future!
I have a (weak) aesthetic preference for smaller refactors where possible (aka commit-by-commit instead of a single large PR like this). Partly that's just general arguments in favor of small-cls (revertability, easier to read diffs, fewer mistakes) and partly refactoring specifically generates a lot of commit churn, where it's harder to follow the git history.

I see, I guess you're right. Just saw this. May do so going forward!


Standardize base images

It would be nice to standardize the base images.
Shall we build a custom image based upon Debian testing, with oracle java 8 and go ?

What's the problem this will solve>
What if vendors offer their own images?

What's the problem this will solve?
What if vendors offer their own images?

What's the problem this will solve?

It would simplify maintainability, and as minor positive side-effect save space on disc.

What if vendors offer their own images?

This would be up for discussion. I believe we may migrate them anyway.

I see,
why Debian and not Alpine then?

If we can get them all on Alpine it would be even better..
but I am not sure about the libs availability (I've no much experience with that distro).
We may try, but I would stop if it comes to build libs by hand.
What do you think?

I think it makes sense, but is not a priority.
We can go directly with Debian, e have Alpine has a possible improvement for later versions


Add Plotters

https://github.com/beardicus/awesome-plotters
"A curated list of code and resources for pen plotters and other robots that draw." I'd love to see more art, design, and creative coding lists out there!
This passes awesome-lint, I've reviewed #1284 and #1524, and I have triple-checked the requirements below.
By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

✅ You have to review at least 2 other open pull requests. Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. I've reviewed #1284 and #1524.
✅ I have read and understood the instructions for creating a list.
✅ This pull request has a descriptive title in the format Add Name of List (Example: Add Swift), not Update readme.md or Add awesome list.
✅ The entry in the Awesome list should:

✅ Include a short description about the project/theme of the list. It should not describe the list itself.Example: - [Fish](…) - User-friendly shell., not - [Fish](…) - Resources for Fish..
✅ Be added at the bottom of the appropriate category.

✅ The list I'm submitting complies with the below requirements.

Requirements for your Awesome list

✅ Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
✅ It's the result of hard work and the best I could possibly produce.
✅ Non-generated Markdown file in a GitHub repo.
✅ Includes a succinct description of the project/theme at the top of the readme. (Example)
✅ The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
✅ Not a duplicate.
✅ Only has awesome items. Awesome lists are curations of the best, not everything.
Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

✅ Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
✅ Includes the Awesome badge.

✅ Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

✅ Should link back to this list.

✅ Has a Table of Contents section.

✅ Should be named Contents, not Table of Contents.
✅ Should be the first section in the list.
✅ Should only have one level of nested lists, preferably none.

✅ Has an appropriate license.

✅ That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
WTFPL and Unlicense are not acceptable licenses.
✅ If you use a license badge, it should be SVG, not PNG.

✅ Has contribution guidelines.

✅ The file should be named contributing.md. Casing is up to you.

✅ Has consistent formatting and proper spelling/grammar.

✅ The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
✅ The description starts with an uppercase character and ends with a period.
✅ Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

✅ Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.

✅ Go to the top and read it again.

Looks like this passes the basic lint checks:
✔ Linting
I didn't see any outstanding issues.

➜  ~ awesome-lint https://github.com/beardicus/awesome-plotters
✖ Linting

  README.md:30:3
  ✖  30:3  Link to http://learn.makeblock.com/en/xy-plotter-robot-kit is dead  remark-lint:no-dead-urls

  1 error

I checked the provided link and http://learn.makeblock.com but it doesn't work

http://learn.makeblock.com is slow but it does work.

Includes a succinct description of the project/theme at the top of the readme. (Example)

This should explain what a "pen plotter" is.

http://learn.makeblock.com is slow but it does work.

Checked again on another computer and yes it does work.

updated description to:

Computer-controlled drawing machines and other visual art robots.

@beardicus The description looks good. Can you also include that description at the top of your readme?

Tweet: https://twitter.com/awesome__re/status/1102449096898445312


Unit tests ?

Hi @dhiltgen
Thanks for the nice driver.
Just wondering why we don't have unit tests so far?
Happy to contribute 😄

Tests would be great!
If you'd like to help, what I'd suggest is start with a very basic/simple hello-world test just to flesh out the test rigging, get a PR posted for that, then once it looks good, you (and others) can flesh out more test scenarios.


Websocket drops initial message

This is a fix for https://github.com/PurpleKingdomGames/tyrian/issues/149, largely based on the solution @gvolpe came up with for the FEDA trading app.
The difference between the two solutions is only that I've created a new stream sub constructor that allows you to include additional clean up tasks directly, meaning we can clear the event listeners when the stream is cancelled.
Seems to work just fine for me... any chance you could try it out @gvolpe? :sweat_smile:

Awesome Dave! I need to run now, but tomorrow I'll have time to properly test it on the trading application and get back to you :)


How to access well-known symbols from C?

I'm trying to create a native object and set its [Symbol.iterator] so that the object can be enumerated using for...of, but all I can find in the API is JsCreateSymbol() which creates a new, unique symbol.

Can you use JsGetPropertyIdFromSymbol? @MSLaguana did something similar recently in https://github.com/nodejs/node-chakracore/pull/375/ - maybe he can confirm?

JsGetPropertyIdFromSymbol() will work, but I need a JsValueRef for Symbol.iterator first.  I can only create unique symbols with the API, it seems like.

It's a little convoluted, but you can fetch the global object, then from that get the Symbol object, then from that get the value of Symbol.iterator, and then JsGetPropertyIdFromSymbol from that, something like
JsValueRef global, symbol, symbolIterator;
JsPropertyIdRef symbolPropertyId, iteratorPropertyId, iteratorSymbolPropertyId;

const WCHAR * symbolString = L"Symbol";
const WCHAR * iteratorString = L"iterator";

JsGetPropertyIdFromName(symbolString, &symbolPropertyId);
JsGetPropertyIdFromName(iteratorString, &iteratorPropertyId);

JsGetGlobalObject(&global);
JsGetProperty(global, symbolPropertyId, &symbol);
JsGetProperty(symbol, iteratorPropertyId, &symbolIterator);
JsGetPropertyIdFromSymbol(symbolIterator, iteratorSymbolPropertyId);

It might be nice to expose the symbols mentioned in the spec through a nicer interface in the JSRT though.

@curtisman @liminzhu thoughts on whether this merits a new API? Given the multiple steps involved here, I would tend to agree with @MSLaguana that having something like JsGetWellKnownSymbol could be useful.

@MSLaguana's solution also won't work correctly if a script assigns something else to Symbol.iterator for some reason.  That's not an issue in my case since this is done on initialization with a virgin context, but in general it might be a problem.

I don't think that's the case for the standard symbols: Symbol.iterator is a non-writable non-configurable (non-enumerable, but that's less relevant) property. However, it is true that global.Symbol is not protected in the same way, so someone could replace Symbol wholesale.

@digitalinfinity honestly I don't think @MSLaguana 's solution is too complicated and user can easily define a helper on top of what we already have. I'm fine with creating a new API, but I'm more towards leaving it given the current solution and that the API interface tends to focus on offering small building blocks, unless the new API can get us some perf gains on common scenarios.

@MSLaguana's solution also won't work correctly if a script assigns something else to Symbol.iterator for some reason.

Thought well-known symbols are non-writable?

May be a more generalize way to get "built-ins" might be the way to go?  I think a lot of integrators would like to get the default "built-ins" before the script mess with it on the global.

Speaking about code complexity, I think a lot of that stems from having to go through the propertyId middleman when dealing with name/symbol properties. I almost always define the below helper when playing with jsrt, which is a bit unfortunate. But with that (or something similar for symbols), code can be simplified and shortened.
void setProperty(JsValueRef object, const wchar_t *propertyName, JsValueRef property)
{
	JsPropertyIdRef propertyId;
	JsGetPropertyIdFromName(propertyName, &propertyId);
	JsSetProperty(object, propertyId, property, true);
}

I think of built-ins are just a special case where you get a property from global, which requires one extra step of calling JsGetGlobalObject.
Good point though on giving embedders the ability to use default built-ins without worrying about user overriding them. That also means whatever API that comes out of this enables a new capability current APIs cannot achieve, which I am all in for 😄.

I think a lot of integrators would like to get the default "built-ins" before the script mess with it on the global.

Myself included. 😄

I think a lot of integrators would like to get the default "built-ins" before the script mess with it on the global.

Should we make a work item for this and close this question?

@dilijev No objection from me.


Don't Merge! PR real time test for webhook case

Docs Build status updates of commit 7b7049f:
:clock10: Pending: waiting for processors (27 builds ahead of you)
:warning: Docs Build is busy, currently there are 27 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 7b7049f:
:clock10: Full build: the average full build time is 7 min(s) 25 sec(s), this is based on the last 30 build(s) for this repository.

Docs Build status updates of commit 7b7049f:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-conceptual/testing.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/testing.md

[Warning] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Warning] Missing attribute: title.
[Warning] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Warning] Missing attribute: title.
[Warning] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Warning] Missing attribute: title.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[Pie Charts] Destroying chart while the chart is animating causes null error.

c3 v0.4.17:
d3 3.5.17:
Chrome:
Mac OSX:

When .destroy() is called on a pie chart while it is animating (you have to be lucky and time this one accurately), you can get a null pointer exception. Because .destroy() sets every property of $$ to null, near-future calls to stuff like $$.data.targets or $$.config.data_types will throw a null error since $$.data and $$.config are set to null.

The Cockpit tests reproduce this crash reliably, both in CI and locally. So I'm happy to test a potential fix for this.

This is still not fixed. I think it's unacceptable. You can check this snippet here to reproduce: https://codesandbox.io/s/smoosh-wind-ogn4y


tutorial on Pano advanced ipynb is incomplete

The notebook relating to build the panorama using seam carve technique is incomplete. Instead of producing pano image, resultant only projects first image on to second image plane. Remaining look blank. This might be due to labelling issue in above part.

Can you please post your notebook with outputs to https://gist.github.com so that we can investigate further?


Hardcode "aws" as Default Partition?

I'm guessing the majority of users would deploy their infrastructure on AWS partition. So does it make sense to make it the default partition? The challenge is that it's a breaking change.
The benefit is that the generated document becomes much more readable without all Joins and Refs.
And if I want to add it manually, since the partition comes at the end in the list of method arguments, I have to put everything including account and region.
What if we provide something like onAwsFoo methods?
Happy to help if needed.

I think I don't understand the problem.
Are you writing about the .on* methods, e.g. Sts.onRole(). In iam-floyd the default partion actually is aws, in cdk-iam-floyd the default partion is the partition of the CFN Stack (Aws.PARTITION from the CDK lib).
Doesn't this work for you?

Let's say if you want to give permission to execute a lambda, you'd write:
new stmts.Lambda()
    .onFunction("Foo-Function")
    .onFunction("Bar-Function");

Now the above generates:
{
  "Action": "lambda:InvokeFunction",
  "Effect": "Allow",
  "Resource": [
    {
      "Fn::Join": [
        "",
        [
          "arn:",
          {
            "Ref": "AWS::Partition"
          },
          ":lambda:*:*:function:Foo-Function"
        ]
      ]
    },
    {
      "Fn::Join": [
        "",
        [
          "arn:",
          {
            "Ref": "AWS::Partition"
          },
          ":lambda:*:*:function:Bar-Function"
        ]
      ]
    }
  ]
}

But if you set the partition, then it'd be like this:
{
  "Action": "lambda:InvokeFunction",
  "Effect": "Allow",
  "Resource": [
    "arn:aws:lambda:*:*:function:Foo-Function",
    "arn:aws:lambda:*:*:function:Bar-Function"
  ]
}

Which is much more readable. It also makes diff and review operation a lot easier since the diff command shows the actual text diff which is cleaner for the later case.
Now the challenge is that, to get above version, I have to specify not only the partition, but also account and region:
new stmts.Lambda()
    .onFunction("Foo-Function", "*", "*", "aws")
    .onFunction("Bar-Function", "*", "*", "aws");

I'm trying to find a solution for not having to type , "*", "*", "aws" part.
As for the method name suggestion (assuming we don't want to have a breaking change), I was thinking if it makes sense to have an overload method like:
new stmts.Lambda()
    .onAwsFunction("Foo-Function") // equivalent to .onFunction("Foo-Function", "*", "*", "aws")

Does that make sense?

Ah I see, it's about the generated template, not the outcome when deploying.
I'm not entirely sure it's possible, but I think we could implement a single method to set the default partition, e.g.
new stmts.Lambda()
    .setDefaultPartition('aws')
    .onFunction("Foo-Function")
    .onFunction("Bar-Function";

Or alternatively put it in the constructor
new stmts.Lambda(undefined, 'aws')
    .onFunction("Foo-Function")
    .onFunction("Bar-Function";

(First constructor argument is the sid of the statement)
Or make the first constructor argument optionally an object, so we can extend it later with other statement setting
new stmts.Lambda({defaultPartition: "aws"})
    .onFunction("Foo-Function")
    .onFunction("Bar-Function";

new stmts.Lambda({sid: "foo"})
    .onFunction("Foo-Function")
    .onFunction("Bar-Function";

new stmts.Lambda({defaultPartition: "aws", sid: "foo"})
    .onFunction("Foo-Function")
    .onFunction("Bar-Function";

new stmts.Lambda("foo") // backwards compatible, when string then it's the sid
    .onFunction("Foo-Function")
    .onFunction("Bar-Function";

I think I like the last option best. What do you think?

Just for the fun of it, I created a factory that you could use without any changes on the package:
import * as statement from 'cdk-iam-floyd/lib/generated';

type InstantiableClass = new (...args: any[]) => any;

function awsStatement<T extends keyof typeof statement>(className: T): InstanceType<typeof statement[T]> {
  const Class = class extends (statement[className] as InstantiableClass) {
    constructor() {
      super();
    }
    freeze() {
      if (!this.frozen) {
        this.floydResources = this.floydResources.map((r: any) => {
          return r.replace(/arn:[^:]+:/g, 'arn:aws:');
        });
      }
      console.log(this.floydResources);
      return super.freeze();
    }
  } as InstantiableClass;

  const instance = new Class();
  return instance as InstanceType<typeof statement[T]>;
}

...

awsStatement('Lambda')
  .onFunction("Foo-Function")
  .onFunction("Bar-Function");

The freeze method is called by the CDK when its generating the template. In there we can override the arns of all recorded resources.

Right, it's just the generated template. I also like the latter more. Could potentially help with other extensions (for example, default account, or region maybe?). Sounds like a clean solution. The only minor comment is how to make it shorter and more concise? (e.g. defaultPartition is a bit too long, considering the value of the feature.) But I guess that just implementation details. You know what I mean?
Another random idea; what is the purpose of "@aws-cdk/core:target-partitions": ["aws"], in cdk.json? Do you think if we can make use of cdk.json for externalizing such configuration? This has the benefit of reusing the same code for different partition yet having cleaner templates. Not a huge win, but still.

On that note, a quick question: why the output when account and region are missing is *. Is that enforced by CDK or is it your decision?

Hm, the in* methods idea is neat, but considering the fact that the majority of cases will be the account/region of the stack, I'm not sure it'll be enough. I think your second point is more interesting:

The defauls are in floyd code. I would actualy like to change that to the account/region of the stack. But that certainly is a breaking change, most people would't catch in their renovate/dependabot/... automation. I know I wouldn't. :)

And agree with the point that people probably won't notice it (tho I personally check 😁). Not sure what to do. On one hand the lib is not GA yet, so theoretically breaking changes are allowed. On the other hand it's a nasty change.
Did you notice the new (don't remember since when) feature of CDK which give warning about important changes? Maybe you can use the same feature? (random idea: print a warning asking people to set the account and region explicitly if they want them to be *, with a heads up that on release v1.0 the default behavior would be "in stack account/region").

Technically you're right... Though I would like to avoid to break all apps. But I have an idea. For other features I have planned, I need to change the exports of the package. I will do this at the same time. Then the app will fail to build and all users need to update their imports and hopefully will see the ARN change in the changelog.


Cancellable effect

Proposed Changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to IcedTasks?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] Build and tests pass locally
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

Fun ideas but idk if I care enough to ship this. Someone can send a PR in the future if they do.


Added a production CDN link

To make life a bit easier for developers. The project is auto-updated as well.
More info:
https://hacks.mozilla.org/2014/03/jsdelivr-the-advanced-open-source-public-cdn/

:+1: Thanks @jimaek


openjfx.io site: wrong link to reference documentation on "Getting Started" page

Hello,
The link titled "detailed reference documentation for JavaFX" on the page https://openjfx.io/openjfx-docs/ points to https://docs.oracle.com/javase/8/javase-clienttechnologies.htm instead of wherever it should be pointing to.

Thanks for reporting.
I discussed this with a number of people, and the main issue is that the "wherever it should be pointing to" doesn't exist. The old overview (JavaFX 8 based) on the Oracle site is still, from a conceptual point, a good overview.
However, many internal parts need to be updated, but we don't have access to the old site.
It would make sense to have an updated version of that 8-based webpage, and we're looking for contributors who want to help with that.

Closing as this is not an issue.


Resolve syncing conflicts from repo_sync_working_branch to live

Pull request opened by Docs to resolve syncing conflicts from repo_sync_working_branch to live.

This is a system generated-PR. Please do not update, edit, etc.


Bump gateway api to 0.8.0

@jwendell: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-multicluster_istio
73bcba72bdb816d471acc451b5c340cd0404dbce
link
true
/test integ-pilot-multicluster

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

Do we need to cherry-pick this?

If feasible it would be nice so we are not on an RC release.
On Wed, Aug 30, 2023 at 2:13 PM Keith Mattix II @.***>
wrote:

Do we need to cherry-pick this?
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/46773#issuecomment-1699850879, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXNWIJ2AZ2NJXFPAAQLXX6UHRANCNFSM6AAAAAA4E4QKQA
.
You are receiving this because your review was requested.Message ID:
@.***>

Do we need to cherry-pick this?

I have a PR that already was doing rc2 so updating with these changes: https://github.com/istio/istio/pull/46677


Demo For CreateView

Hi,
How do I create nested-formset with CreateView? I tried your example. But that code does not show Employee's form. Am I missing something? Thanks
Here are my models
class Employee(models.Model):
    name = models.CharField(max_length=100)

class Salary(models.Model):
    salary = models.IntegerField()
    employee = models.ForeignKey(Employee)

class SalaryDivision(models.Model):
    salary = models.ForeignKey(Salary)
    percentage = models.IntegerField()

My View
class EmployeeCreateView(CreateView):
    model = Employee

    def get_form_class(self):

        return nestedformset_factory(
            Employee,
            Salary,
            extra=1,
            nested_formset=inlineformset_factory(
                Salary,
                SalaryDivision,
                extra=2,
                fields = '__all__'
            )
        )

So a couple things come to mind.
First, you don't describe your template, but nested formset doesn't "magically" work like a normal form -- you have to iterate on over the nested forms. See nested-formset/demo/blocks/templates/blocks/building_form.html for an example of that in an update form.
Second (and probably more importantly for you), I don't believe that nested formsets don't support creating the "root" object along with children and grandchildren all in one go. Looking at the tests, they all start with a root object created ahead of time. My recollection is that the thing that's missing is attaching the ID of the newly created root object to its children at save time.
I'm not actively working on nested formsets these days, but I'd be happy to review a PR with tests if you wanted to add this.


fix(docker): Disable latest tag for distroless variants

Tested on https://github.com/grzesuav/metacontroller/runs/1736882334?check_suite_focus=true

:tada: This PR is included in version 1.2.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Eirgar (Dark Vampire Lord) Missing?

Name is blank.  Not sure if/how the stats are handled/skills are optimized.

I've added him in source, but haven't pushed out an update in a while.
His skills are in the registry, so he'll be available next release.


Video Block: Unable to drag videos in

It is not possible to drag across videos into the video block eg vimeo. It is however possible to paste the URL as a workaround

Looks like we need to update how the block mixins work and ditch the draggable option for this kind of block. This was discussed at the last ST contributor meeting.

Any updates on this?
Has someone done it yet, or may I do it myself and push a PR?
Cheers

@rafaelbeckel no update on this yet sorry :disappointed:. Feel free to do a PR. I'll bring it up at the next contributor meeting

Maybe as a workaround, while we do not have a solution, just remove the "Drag video here" message and give only the URL option.
Backend code for videos are a bit harder too. Uploads for big videos can take hours to complete. We need to send a unique ID back, so ST can check the status and display a status bar with an image fallback (while upload is not complete).


Bower package outdated/wrong version

Currently the Bower package has some versioning issues: it's still at version 1.0.0 (against current 1.0.3).
Furthermore, despite being marked as version 1.0.0, the bundled dist files are from version 0.23.4.

Thanks for reporting. I'm investigating.

I have just released a new version v1.0.3. I also updated NuGet and NPM packages.


Setup travisci

We're starting to see more contributors and we have some tests. Let's set up TravisCI to automatically run tests on PRs, reduces the need to ask if they've ran unit tests, can instead focus on what manual verification was done.
@edmundmok, as the repository owner, can you enable TravisCI? From this stackoverflow post, I can do the rest of the setup via travis.yml file.

I've enabled it here.

I'm not going to lie, part of my motivation for doing this is to collect all the badges for the README. Because everyone loves badges lol.

We do need more colors in the README!


Migrate to PureScript 0.14

This PR makes necessary changes for migrating to PureScript 0.14 and repoints packages.dhall to psc-0.14.0 package set.

Hi @fsoikin,
Thank you very much for the PR. I'm also really sorry that it stays here for so long - I don't use purs-0.14 yet. I promise (😮) to do this merge during this weekend.

Not super urgent @paluh, we're just using my branch added as extra-dep right now. Still, would be nice to have everything nice and in the package set.

@fsoikin - sorry for a small delay. I hope I've done everything correctly - here is my package-set PR with new version: https://github.com/purescript/package-sets/pull/907
Once again thanks!

Thank you very much!


include should (be able to) load files as a relative part

It is useful when i don't want to write a big module into a single file.

On Wed, Aug 31, 2016 at 07:06:36AM -0700, Fabio Krapohl wrote:

It is useful when i don't want to write a big module into a single file.

This should be possible already via the "include" form:
user@host:~$ cat mymod.dt
(module mymod)

(include "part1.dt")
(include "part2.dt")
user@host:~$ cat part1.dt
(def n (var extern int 10))
user@host:~$ cat part2.dt
(def m (var extern int 25))
user@host:~$ ./dalec -I. -c mymod.dt
user@host:~$ cat test.dt
(import mymod)
(import cstdio)

(def main (fn extern-c int (void)
  (printf "%d %d\n" n m)
  0))
user@host:~$ ./dalec test.dt
user@host:~$ ./a.out
10 25
user@host:~$

I get errors like this:
test5.dt:2:10: error: /usr/local/include/dale/part1.dt: No such file or directory
It doesn't search in the local directory but in the dale directory.

On Sat, Sep 10, 2016 at 06:42:19AM -0700, Fabio Krapohl wrote:

I get errors like this:
test5.dt:2:10: error: /usr/local/include/dale/part1.dt: No such file or directory
It doesn't search in the local directory but in the dale directory.

'.' is not an include directory by default, so it has to be specified
explicitly by way of the -I flag.

I thought include is just like adding the content of the specified file into the current file, but it works like import, and only imports extern symbols

On Tue, Sep 13, 2016 at 02:19:28AM -0700, Fabio Krapohl wrote:

I thought include is just like adding the content of the specified file into the current file, but it works like import, and only imports extern symbols

Thanks, this has been fixed.


GestureAnalyser class returned don't correct  the swipe direction

How to reproduce bug:
Step 1:
Put finger in View and swipe to up.
Step 2:
Without lifting finger now keep down.
Method calcGesture in object GestureAnalyser - returned  SWIPE_1_UP, but now your swipe down.
Method calcGesture in object GestureAnalyser -returned correct value when your finger down below start point(where your finger put first time)

this bug is solved?


CNF-11932: IBU: Add rollbackAvailabilityExpiration status field

From the original stateroot point of view, a rollback is effectively just a recovery from having the node out-of-service for a possibly extended period of time. Especially when running an IBU within the first 24 hours of deploying a cluster, this means the control plane certificates for the original release may be expired when the rollback is triggered, requiring a manual procedure in order to renew them and recover the cluster.
This update adds a new field to the IBU CR to provide the user with indication of when a rollback can be performed before the original release certificates have expired:
.status.rollbackAvailabilityExpiration

/hold for a final retest after rebasing

/lgtm

/lgtm

/retest

/test ibu-e2e-flow

/hold

/lgtm

/approve


How to get index value when selected pop over item value

You don't.
Provide action hander on PopoverItem when you initialize it.


Add max-width/height options

I am showcasing images optimized for retina displays (@2x) which are 2400px width, forced to display at 1200px.
When I refernce those images inside lightbox, setting the "width" option to a size SMALLER than the image file has no effect.  It only works for EXPANDING original image files, but larger files are not scaled down.
What I really would want is to have a 'max-width/max-height' option that will allow for the modal to be as small as needed and grow no further than XXX pixels, to keep image display to its best.
Thanks,
Rafa.

Sounds like adding two new data-* attributes is the best thing to do, and then in the _resize method check that the attribute value is < maxHeight and width and use which ever is most appropriate.

Yeap, I have done this already in a pull request, also improving a bit some padding / aspect ratio issues.


File not found (ios)

Added in the Assets directory inside ios, and there it placed the .riv files, but the files are not found

In the case of android it works correctly.
In the simulator I have the following error:

In the case of android, place the raw folder in the following directory

I just identified that it was missing in ios for the .riv files to be displayed, when dragging the files you have to select the following according to the project, both the option: create folder references, and the name of the project (in this case larvia).


about pytorch to onnx

hi, i used your codes to train my own dataset, and i got this result.

is it the correct result? and i also wonder how can i change it to onnx model, in order to use your team's rangenet_lib codes.
looking forward to your reply! thx!!!

Have you found a way to change it to onnx model?

Have you found a way to change it to onnx model?

sry, not yet. I'm in confusion

Anyone knows the answer?@Andres Milioto, @Jens Behley, @Ignacio Vizzo, @Cyrill Stachniss


Fix #87.

When I log a json very long, and it has some Chinese words or other multi-bytes UTF-8 charset, logcat will show some charset like '???'. So it fixed it, and I found an old issue that have same problem with me, it's #87.
After I fixed it, I found a new bug, if once print with lines too mach, will lost some logs, I thought it's Android System's bug or feature. You can reappear it with run this:
for (int i = 0; i <= 100000; i++) {
  Log.println(6, "max limit", i + "");
}

Then, it won't print 100000.

@orhanobut


Unwanted gap on the right of homepage

Bug Description
There is a gap on the right on the homepage for screens with a

width less than ~1180px.
width more than ~1023px.

Steps to Reproduce
Steps to reproduce the behavior:

Go to https://4c.rocks
Open the chrome devtools (F12)
Check the responsiveness on width less 1180px.

Expected behavior
There should not be any gap on the right of the homepage.
Actual behavior
There is a gap on the right of the homepage.
Screenshots/Recordings

OS and Browser

OS: Windows 11
Browser: Brave

Additional context
The cause is probably the discord widget taking up more width.

Thanks for finding this issue and doing the fix as well. Since your PR is merged, closing this one.

@ayushhagarwal the merged PR #140 fixes the issue for screens with a width less than 380px but this issue is for width between 1180px - 1023px. This is not the same issue.

reopening as the widget disappears for width < 1180px

now the widget doesn't disappear

solved by #143


FGA plot skipping function cannot be executed

Preparation

[X] I tested the latest release
[X] I looked at other issues (even the closed ones)
[X] I read the Troubleshooting Guide

FGO server
CN
FGA build number
1951
Describe the bug
I have activated the skip episode feature of the program, but when I go to the episode page, the program stays unresponsive. The program play button is located at the bottom left. All other functions execute normally.
Video
https://user-images.githubusercontent.com/55449372/229271503-0d0a3d22-cad3-4773-a9c4-c6181b81c6b6.mp4
Device model
NOX  <IP_ADDRESS>
Android version
9
Screen size
1280*720
RAM
4GB

If I'm remembering correctly I believe that feature was disabled because it was causing with skills being used at the wrong time

Duplicate of #1282
But I'll probably remove the feature instead. It's too unreliable.


Resolved issue that made  notifications get stacked if you use notifications in more …

…than one page
Pull Request template
If you want to make a contribution to the project's source code, follow the guide:

Make sure to make changes to one file per pr.
Make sure it passes all linter checks of the ci. To more about the linter rules go here
Be precise as to what are you trying to correct in your title and/or comment.
Make sure to open a pr to the correct branch.
Try to make as little changes as possible to make the diff more readable.
Respect the coding guidelines as mentioned in the linter guide.

thanks for the pr @juanmendez90 I'll take a look at it

@juanmendez90 thanks for the PR it really help out a great deal keep em coming! 🥂


There is no Certmgr.exe file, only Certmgr.msc

I searched a Windows 7 SP1 and a Windows 10 1803 machine for file "Certmgr.exe". It does not exist. There is only "Certmgr.msc" which can be executed by just typing "certmgr" into the command prompt.

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

ID: 523af9f6-2f00-c0d3-d8d8-b84407d7f00e
Version Independent ID: 759aa8d8-1a2c-ed63-3009-a8d1965865cd
Content: Certmgr.exe (Certificate Manager Tool)
Content Source: docs/framework/tools/certmgr-exe-certificate-manager-tool.md
Product: dotnet-framework
GitHub Login: @rpetrusha
Microsoft Alias: ronpet

OK, I can run certmgr.exe from the Visual Studio 2017 Command Prompt but when I use file search in Windows Explorer then it won't find anything even though it's part of the Windows SDK: C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86


[BEAM-11935] Appends SDK Harness ID to Java container staging path to prevent dependency conflicts

Dataflow is unable to start multiple Java SDK Harnesses per worker VM without this.
This should not have an affect on other runners other than artifact staging path being slightly different.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.


Snake case props support.

Somewhat related to #1000
I think there should be - probably in global Vue config - an option to replace camel case with snake case. Working with Vue props in coffee script isn't consistent with it's variable naming convention.
Making it a global option shouldn't add any visible performance overhead and would be a great thing to make Vue coffee compatible again, as it was before introducing props concept.

You can still use snake-case when declaring props. But in templates you have to use camelCase to refer to them because {{a-b}} will be parsed as a minus operation.

Actually i meant something like that, in fact:
SomeComponent = Vue.extend {

  props: ['some_value']

  # or

  props: {
    some_value: {
      type: String
    }
  }

}

And then in html:
<some-component some-value="Just an example." inline-template>

  {{ some_value }}

</some-component>

Here the underscore snake_case is perfectly aligned with coffeescript conventions, and declaring props in html mark-up using snake-case="value" is totally acceptable.
The only difference here is that Vue would have to parse some-value="value" html attribute to some_value variable instead of someValue, based on some optional config option.

Can't you use some_value="value" in HTML?

Right, somehow didn't thought about that. Looks like quite nice work-around for my issue. Anyway that's on the other hand isn't aligned with html conventions, at least it's a bit uncommon.
So i still think it would be a nice feature to have in Vue, but your solution makes me happy :smile:
Thanks a lot.

I would like to reopen this. We are working both in web and server, so we demand snake_case coding convention which is not supported by Vue props. @yyx990803 could I propose a global config to do this?

@yyx990803 what's your opinion on this?

This would be in line with ruby/rails conventions as well. A global config would be a plus.

@bradlis7, I don't think we are interested in "being in line" with any back-end technology. I personally see no benefit in adding support for even more casing, existing camelCase & kebab-case is more than enough for most use cases. Adding another one "because I like it" is not a valid reason.

Well, how about coffeescript then? It's not really "because I like it". It's the ruby/rails/coffeescript coding standard.
It probably wouldn't be too hard for Vue to look at the props available, and determine if the prop is defined variableName or variable_name, and assigning it as it finds it.

@bradlis7, I am sorry if that sounded rude, I didn't mean it to, it's just that we are following HTML and JavaScipt coding standards because that's waht Vue is all about and we don't follow any other coding standards since we are not affiliated to them.

What about people with reading difficulties. I prefer snake_case because It makes a difference in my ability to visually parse the page.
what about supporting snake case as an accessibility feature?

I have often wondered why I couldn't just do away with camelCase and kebab-case, and just use snake_case for everything - both for JS and HTML.  It seems pretty confusing for Vue to be converting back and forth between camelCase and kebab-case.  As far as I can tell, the only advantage of camelCase is that it provides a way to distinguish between class definitions and ordinary functions.  Class definitions use something like MyClass, which is camelCase, but with the first word capitalized.  I don't plan to ever use classes in my web pages, so I can get away with using snake_case everywhere.  But people who come from the world of Angular are used to making everything a class, so doing away with classes would probably be uncomfortable for them.


Fix library export path

os.path.join under windows uses a '' to join, but it can break the names if they contains special characters as '%'
Using '/' for join fixes the issue, and xbmc.makeLegalFilename will translate '/' to '' for pure windows folders
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] I have read the CONTRIBUTING document.

All Submissions:

[X] Have you followed the guidelines in our Contributing document?
[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

[X] Have you added an explanation of what your changes do and why you'd like us to include them?
[X] Have you successfully ran tests with your changes locally?

Screenshots (if appropriate):
[You can erase any parts of this template not applicable to your Pull Request.]

Forgot a test. Have to check more before opening it or changing it.

Checks done, fix confirmed


not working :net::ERR_ABORTED 504 (Outdated Optimize Dep)

GET http://localhost:5173/node_modules/.vite/deps/v-phone-input.js?v=2add29de net::ERR_ABORTED 504 (Outdated Optimize Dep)

Hi @ahmadkashami,
Thank you for your issue. Without any further details, I cannot investigate the issue.
Could you provide a reproduction repo please?

Thank you for your quick response, this problem no longer appears when the server is restarted


Fixed error message so that if it is a string and not an object, it p…

…rints out the string and not undefined

 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.cahrens 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.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@975b237). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #270   +/-   ##
=========================================
  Coverage          ?   97.31%
=========================================
  Files             ?       31
  Lines             ?      970
  Branches          ?        0
=========================================
  Hits              ?      944
  Misses            ?       26
  Partials          ?        0

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 975b237...c148f01. Read the comment docs.


Ignore convert to 300 if original shader is glsl300

Please check if the PR fulfills these requirements
Fix #2047

[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:

Completed supplementary inspection：

Babylon.js don't have this bug


Bug in crawler?

See the GH actions run here: https://github.com/joelostblom/viz-oer/actions/runs/10729466334/job/29756120813#step:9:179
I've asked @joelostblom to provide the old/new websites that caused that error, and will report back here once I figure out what the underlying issue is.

One can reproduce the bug by checking out

and running
website_diff --old . --new pull24 --diff diff24

The bug is due to an <a> tag with the form
<a aria-controls="quarto-sidebar" aria-expanded="false" aria-label="Toggle sidebar navigation" class="flex-grow-1" data-bs-target=".quarto-sidebar-collapse-item" data-bs-toggle="collapse" onclick="if (window.quartoToggleHeadroom) { window.quartoToggleHeadroom(); }" role="navigation">
</a>

There is no href property, so line 46 in crawler.py gets the href property, which returns none, and then the code fails to extract the anchor from a None object.
Solution is to just avoid None objects after trying to get an href.


Add Getting Started Guide

This PR updates the documentation-generating dependencies to avoid issues with the latest versions of Elixir. It also introduces a new guide page, Getting Started, that condenses the setup steps into a single page on Hexdocs. The goal is to provide a focused guide for getting set up with this library.
If this is merged, the maintainers might wish to include a link to the getting started towards the top of the Readme file. Also note that the readme will now be the primary page on Hexdocs (as opposed to the API reference).
Please feel free to make changes and comment as appropriate. Thank you for your work on this project!

Coverage remained the same at 91.319% when pulling 4201a831550e1a39540422ffc57d5dc252d373bd on aj-foster:guides into e4d0e9c471a8fdbee1af8a81fc7338dbc7a506a0 on edgurgel:master.

That's amazing! Thank you so much!


SNMP switch fix integer support

Description:
Fix integer payload support in the switch from the snmp component after #27422
Related issue (if applicable): fixes #28371
Pull request with documentation for home-assistant.io (if applicable):
Not applicable.
Example entry for configuration.yaml (if applicable):
No changes in configuration syntax.
switch:
  - platform: snmp
    name: APC PDU port 1
    host: apcpdu.local
    community: private
    baseoid: <IP_ADDRESS>.4.1.3<IP_ADDRESS>.<IP_ADDRESS>.4.1
    payload_on: 1
    payload_off: 2

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Hi @rfpronk,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!


new version of api design, also incorporated directly into site docum…

…entation

I have merged this to feature/430_horizon_lang for deploy to test


Easegress Logger initialization problem and rotation feature

1、In some cases，we need to use logger in init function like this:
func init() {
	logger.Infof("Register adapter %s",xxx)
}

This will report errorpanic: runtime error: invalid memory address or nil pointer dereference， because at this time point，Easegress logger is initialized in main entrypoint.  Perhaps for standard out console logger，it should initialize in init not in main.
Or is there are any better way to solve this problem.
2、Easegress implement writer logic for performance internally and should support Logger rotation feature as following：
w := zapcore.AddSync(&lumberjack.Logger{
  Filename:   "/var/log/myapp/foo.log",
  MaxSize:    500, // megabytes
  MaxBackups: 3,
  MaxAge:     28, // days
})
core := zapcore.NewCore(
  zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig()),
  w,
  zap.InfoLevel,
)
logger := zap.New(core)

we can only know the logger configuration after entering the main function, so I don't think we can initialize the logger in init functions. for your case, I propose to use the fmt.Print to write the log messages (even we use the logger, we can only write the message to standard output before initializing the logger), and I also think you can omit the log, because init functions cannot return an error, which means it should always succeed and should panic if it does fail.
Easegress support log rotate, this can be done via using the logrotate command of the OS, below is an example configuration:

/opt/easegress/log/*.log {
    daily
    rotate 10
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
    postrotate
        /usr/bin/killall -HUP easegress-server
    endscript
}

@localvar Thanks, I'm unfamiliar with logrotate  command of OS，that means we should custom Easegress Dockerfile by adding apt-get install -y logrotate Anyway，I don't think it's a google way especially in distributed environments having a lot of node instances.

@jthann , for containers, the solution should be to output all logs to stdout/stderr by default instead of support log rotation directly, this has been discussed in #34 , and we will work on this.

@localvar I do agree k8s container should output all logs to stdout just a 12factor put it. We need this feature not because it is a best practice，but for history reason and compatibility.  I've already solve this by using lumberjack integrated with uber-go/zap.


Better IP bind/listen flow

while working on #1121 I found out that on my setup the listen fails because it binds each IP separately, leading to ListenAlreadyExists error and killing the layer.
I am sending a PR that ignores this error, but we need in bind call to check if address is not already bound to preserve normal behavior (return error in that case instead of ignoring it)
Edit:
We should hook all the functions that help resolve the local stack (ip, subnet, ports) so app want to listen on "localhost" it will then resolve to the real remote ip and will be able to bind on that ip, so getsockname would return also the remote ip even before accepting any connection.

Can you provide a little more insight on this one. Thanks

Can you provide a little more insight on this one. Thanks

Sure. It's a bit complex issue so feel free to ask more questions.
mirrord hooks calls to bind/listen, so instead of actually binding/listening the given ports we randomize a port then pass the data to the agent so it can know what connections to steal/mirror for us.
Due to the IP being different between local/remote, we currently just ignore cases where the same port is bound twice. We ignore it because to preserve "proper" behavior we need to check if IP:PORT combination is bound, and then error in that case instead of returning success. Right now we don't preserve the bounded IP, only port so in order to support apps that bound each IP.
After writing this, I think maybe we should consider the IP specified in bind to be passed to the remote agent, but for it to work we need to also make sure that the local applications is able to obtain the remote's IPs to bind those.

While investigating #1054 we've found out that bind has to be more "correct" than what we have right now.
When running the flask test, the server address stays as some <IP_ADDRESS> (initial address), even though internally the requests are being handled in <IP_ADDRESS>.

Some logs to give a bit more information:

# first call to `getsockname`
stderr 2023-03-02T20:04:08.775908614Z 62732: 2023-03-02T20:04:08.775887Z DEBUG ThreadId(01) getsockname: mirrord_layer::socket::ops: getsockname -> local_address <IP_ADDRESS>:33839 sockfd=10

(...)

# correct address
stderr 2023-03-02T20:04:08.787741559Z 62732: 2023-03-02T20:04:08.787718Z DEBUG ThreadId(01) getsockname: mirrord_layer::socket::ops: getsockname -> local_address <IP_ADDRESS>:80 sockfd=11

(...)

# value from `request.server` should be `<IP_ADDRESS>`
stdout 2023-03-02T20:04:08.788315678Z 62732: ('<IP_ADDRESS>', 33839): Server value
stdout 2023-03-02T20:04:08.788342282Z 62732: HttpMethod.GET: Request completed

Questions asked by @meowjesty on Discord:
Which address should we bind (and where)?

We should bind the remote address (the pod address)?
A random address in the agent?
A random address in the remote's network namespace?
User specified address in the agent?
User specified address in the remote's network namespace?
Think we have to keep the bound socket alive (the one we use to detect valid bind in the agent), otherwise we could have a race condition of a layer thinking that the address is safe to bind, but something else binds + starts listenning on it before.

The bind / listen restrictions should happen on layer only. There is no meaning to double binding a mirrored port for example. The objective is to not change/modify local app behavior and hide bugs (double bind for example)
This means that we should return error on bind itself if it happens twice on same (address, port)

so getsockname would return also the remote ip even before accepting any connection.

This means that on bind for localhost:XX (and equivalents), we retrieve the actual remote address of the service?

An example:

User impersonates pod "Bear" which has a service:

$ kubectl get service
NAME                   TYPE            CLUSTER-IP      EXTERNAL-IP   PORT(S)            AGE
bear-service       NodePort    <IP_ADDRESS>               <none>             80:1234/TCP   1d

User calls bind("localhost:80");
mirrord does our normal bind magic, but also retrieves the address <IP_ADDRESS>:80 as if this was the user's requested address;
getsockname(user_socket) returns the <IP_ADDRESS>:80 address (same for other similar functions);
Proceed as normal;

Yes. Exactly.
There might be an issue if you bind localhost:3770 when 3770 is an ignored port and it will fail on bypass since <IP_ADDRESS> isn't really available on the system. Maybe we should have a struct like this:
struct Host {
 remote_ip: SocketAddr,
 local_ip: SocketAddr
}

Host{remote_ip: "<IP_ADDRESS>", local_ip: "<IP_ADDRESS>"}

then when we do the actual bind we check if we want remote or local and use the appropriate?
We can probably first finish the more naive implementation, then add this logic (since we already resolve the remote by default)

PR #1371 addresses only the double bind issue, but we still have an IP mismatch when the user binds localhost:80, and when they start listenning.
I think the following steps would help to solve this:

[ ] Retrieve the impersonated pod IP;

the easiest point to retrieve this is in from_pod, and we could "bubble up" it in the RuntimeData struct;
we want the pod IP, not the service IP, kubectl get pod -o wide shows the address you want;

[ ] Pass this IP to the layer at start up, or have a message that allows the layer to retrieve it from our wrap_raw_connection;
[ ] Check if the user is requesting a localhost address (<IP_ADDRESS>, <IP_ADDRESS>) for bind, and if so, use the impersonated pod's address as the requested_address instead (of localhost);

this would solve getsockname initially giving out a localhost address, and later on changing to the pod address;

I did something like this, but ended up with a different port when a message came through the TCP sniffer (don't know why yet).

PR #1371 addresses only the double bind issue, but we still have an IP mismatch when the user binds localhost:80, and when they start listenning.
I think the following steps would help to solve this:

[ ] Retrieve the impersonated pod IP;

the easiest point to retrieve this is in from_pod, and we could "bubble up" it in the RuntimeData struct;

we want the pod IP, not the service IP, kubectl get pod -o wide shows the address you want;

[ ] Pass this IP to the layer at start up, or have a message that allows the layer to retrieve it from our wrap_raw_connection;

[ ] Check if the user is requesting a localhost address (<IP_ADDRESS>, <IP_ADDRESS>) for bind, and if so, use the impersonated pod's address as the requested_address instead (of localhost);

this would solve getsockname initially giving out a localhost address, and later on changing to the pod address;

I did something like this, but ended up with a different port when a message came through the TCP sniffer (don't know why yet).

Not sure why we need that.
User can't bind localhost as it's a DNS and needs to use IP.
To solve the mentioned issue we just need to store the bound IP and return it for an unconnected socket on getsockname

Not sure why we need that.

You mean why we need this part?

Check if the user is requesting a localhost address (<IP_ADDRESS>, <IP_ADDRESS>) for bind (...)

We could save it as Bound::pod_address and return it from getsockname when the socket state is Bound, thus solving #1054 right?

We're already returning the requested address:
                SocketState::Bound(bound) => Detour::Success(bound.requested_address.into()),

if we want to get in the way somewhere, we need to change the way it decides what IPs are available for it.
AFAIK it users dns resolving for that (gethostname then resolve it) so we should be okay on that too.
There might be use of other libc functions but usually they'd get you the "internal" (NAT, firewall, etc) which isn't so useful

I think we achieved what we want for now :)


Improve the init command

Improve documentation of the init command.
Add and option to exit with non-zero status in case any pyproject.toml is created or modified.

Codecov Report

Merging #10 (91bae2c) into main (93b411c) will decrease coverage by 0.47%.
The diff coverage is 35.29%.

@@            Coverage Diff             @@
##             main      #10      +/-   ##
==========================================
- Coverage   74.76%   74.29%   -0.47%
==========================================
  Files           7        7
  Lines         210      214       +4
  Branches       32       33       +1
==========================================
+ Hits          157      159       +2
- Misses         47       51       +4
+ Partials        6        4       -2

Files
Coverage Δ

src/whool/cli.py
0.00% <0.00%> (ø)

src/whool/init.py
69.69% <50.00%> (+4.07%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Support JSDoc parameters with properties using @param

This is a suggestion/feature request for the @ts-check feature.
When using // @ts-check in a JavaScript file, TypeScript-check should be able to identify object properties types using JSDoc.
For example:
// @ts-check
/*
 * @param {Object} bar The bar object
 * @param {Number} bar.id The id of the bar object
 * @param {Object} bar.foo The foo object
 * @param {Number} bar.foo.id The id of the foo object
 */
export function Foo(bar) {
  console.log(bar.id); // TypeScript: "Holy moly it is a number"
  console.log(bar.foo.id); // TypeScript: "OMG another one"
}

Also described on JSDoc.
I hope you get the idea :)
Keep up the good work!

Looks like a duplicate of https://github.com/Microsoft/TypeScript/issues/11597

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


test(website): add unit test for isOnCorrectChain

@ariesjia we dont need to change the chainIDs/RPC urls for the defaults. Please revert those changes, and we can merge in just the test. Thank you!

Thank you!


Move to github org

This is a community project, it should have its own org. Unless anyone has any reasonable objections, I'd like to move it to https://github.com/EventEmitter2/EventEmitter2.
cc @RangerMauve

I'm all for it! :D

Could I get a higher level of access to add potential collaborators when they come up?

@RangerMauve of course! Ok, then I will move it.