Check if a file or directory exists

Problem
The Dagger API does not support checking if a file exists. There is an SDK-specific workaround (maybe? not documented) which is to 1) call any function that requires the file to exist, like Sync or Contents, 2) check for error, and 3) check for the error message returned when the file doesn't exist. This possibly can be wrapped in a convenience type by the SDK (again hard to tell as it is not documented).
This makes for a bad DX.
Solution
Add a new core function to the File and Directory types:
type Directory {
 "Returns true if the directory exists"
 exists: Bool!
}

type File {
 "Returns true if the file exists"
 exists: Bool!
}

I think there’s an issue for this already. Maybe via a Stat field.

This should also only return an error if something actually went wrong. If the file/directory doesn't exist, this should return False and not error
Maybe stating the obvious, but for the sake of being super clear 😂

Related (maybe dupe, maybe not): https://github.com/dagger/dagger/issues/3764

What I do is call dir.Entries(ctx) and then check if the file is in the list.

Related (maybe dupe, maybe not): #3764

Stat would have to return an error if a file doesn't exist (custom NotExistError, like ExecError). We can definitely do that, but also cool with an .Exists() convenience that returns a bool.

Related (maybe dupe, maybe not): #3764

Stat would have to return an error if a file doesn't exist (custom NotExistError, like ExecError). We can definitely do that, but also cool with an .Exists() convenience that returns a bool.

That would fit definetely, also as mentioned in #3764 the required function is already in the core library.
Not sure how difficult is to ship that method to the sdk so we can reuse it.
For instance I had to implement a workaround to check if a path is a file or not just because I do not have stat functionality available:
func (m *DaggerStructureTest) IsDir(ctx context.Context, container *Container, path string) (bool, error) {

	_, isNotDirErr := container.Directory(path).Sync(ctx)

	// If it is a directory do not keep further checking
	if isNotDirErr == nil {
		return true, nil
	}

	_, isNotFileErr := container.File(path).Sync(ctx)

	if isNotFileErr == nil {
		return false, nil
	}

	// At this point we know that the path does not exist or a graphql error occurred
	// We also assume that isNotDirErr and isNotFileErr are the same error
	return false, isNotFileErr
}

Adding an exists field to Directory doesn't work without a path. Consider this:
exists, err := ctr.Directory(path).Exists(ctx)

These fields already validate if the directory/file exists and if it's a directory/file:

Container.directory
Directory.directory
Container.file
Directory.file

So the above snippet fails on ctr.Directory(path), before reaching .Exists(ctx).
This behavior is appropriate because on most operations you want the early error, rather than a possibly more confusing one later due to an inexistent directory/file.
I suggest adding a path argument instead:
type Container {
    exists(path: String!): Boolean!
}

type Directory {
    exists(path: String!): Boolean!
}

Then in code it becomes:
- exists, err := ctr.Directory(path).Exists(ctx)
+ exists, err := ctr.Exists(ctx, path)

However you can't tell if it's a directory or a file this way because path could be either, unless you have specific:

Container.existsDirectory
Container.existsFile
Directory.existsDirectory
Directory.existsFile

But I think I prefer relying on [Stat](https://github.com/dagger/dagger/issues/3764) for that instead of the above fields. We can also create a custom error like dagger.ExecError (e.g., dagger.NotExistsError) so Stat can serve both purposes, but that's best in a separate issue. Doesn't mean we don't do both.
We can add the following as well:
type File {
    exists: Boolean!
}

But I'm not sure about its value since things that return a File usually validate if it exists already. We just need the custom error to check in code, rather than looking at the error message.
Does anyone know a use case where you have a File instance that may not exist? dir.File("not-exists") doesn't count because no method on that File will work since Directory.file will return an error before that.

I definetely love the idea of having both Stat and Exists methods, they would complement each other perfectly. Code may end being a bit more verbose but it gives more fine grain control over the checks you want to pass.
@helderco I can think of a possible scenario. We are using a container that renders some output files in a directory and then we pass that resulting directory to another container where we extract some of these rendered files. However, if there was some sort of error or bug in the rendering process may cause the file not existing in the directory. Would be great to be able to check if the file exists to allow some error handling instead of just panicking the process.

It makes more sense to me to resolve file/directory existence lazily, and keep File.Exists() and Directory.Exists() as proposed, without path. It's the most intuitive and doesn't break any existing use cases.

This behavior is appropriate because on most operations you want the early error, rather than a possibly more confusing one later due to an inexistent directory/file.

This doesn't make sense to me. As a dev I call ctr.Directory(foo) without having to check for error, which tells me the directory object is lazy and may not exist. If you just add a Exists function to that lazy object, I can cleanly find out, and everyone is happy.

I'm against Stat because it's a posix relic that is unnecessary when you already have first class support for structured data in the core API. In a C syscall API you need a shorthand to check for existence + get a struct with various information about a filesystem entry all at once. But we don't have the constraints of C: we have  Directory a File types which can be queried as structs directly. We don't need the stat hack. Let it die in peace :)

It makes more sense to me to resolve file/directory existence lazily, and keep File.Exists() and Directory.Exists() as proposed, without path. It's the most intuitive and doesn't break any existing use cases.

I knew using Go examples would be confusing. 🙂 I tried explaining that this happens while processing the pipeline server side, not on the client. I can make it clearer.
I agree that it would be more intuitive but when you do this:
dir := dag.Container().From("alpine").Directory("not-exists")
// ...
exists, err := dir.Exists(ctx)

It means Directory() is indeed lazy, until you reach the leaf Exists(), which forces the query to be built and executed:
query {
  container {
    from(address: "alpine") {
      directory(path: "not-exists") {
        exists
      }
    }
  }
}

At this point, the server resolves these steps sequentially: container → directory resolver → exists resolver.
🔀 Flowchart
flowchart TB
    subgraph D ["directory(path: #quot;not-exists#quot;)"]
        DE{Does it exist?}
        DE --> DEY[Yes]
        DE --> DEN[No]
        DEY -->DD{Is it a directory?}
        DD --> DDY[Yes]
        DD --> DDN[No]
    end
    subgraph E ["exists"]
        EE{Does it exist?} --> EEY[Yes]
        EE --> EEN[No]
    end
    C(container) --> D
    DEN & DDN --> RE[Return Error]
    DDY --> E
    EEY -->|true| R[Return boolean]
    EEN -.->|false ❌| R

As you can see in the flowchart, this validation already happens in Container.directory so the request returns an error at that location:
{
  "errors": [
    {
      "message": "resolve: lstat /not-exists: no such file or directory",
      "path": [
        "container",
        "from",
        "directory"
      ]
    }
  ],
  "data": null
}

It doesn’t get the chance to reach the logic in the exists resolver. You certainly can’t catch the error from the directory resolver inside the exists resolver.
As I mentioned, this validation already happens in the following fields:

Container.directory
Directory.directory
Container.file
Directory.file

This behavior is appropriate because on most operations you want the early error, rather than a possibly more confusing one later due to an inexistent directory/file.

This doesn't make sense to me. As a dev I call ctr.Directory(foo) without having to check for error, which tells me the directory object is lazy and may not exist. If you just add a Exists function to that lazy object, I can cleanly find out, and everyone is happy.

By “this behavior is appropriate” I’m talking about the validation that happens in the directory() resolver. To make exists work the way you propose, I’d have to remove this validation from the fields above, but it was added for a reason: better error message in every use case beside exists.
Remember that we had a similar issue with ExitCode. It never returned a false value because it would exit early with an error. The solution there was to make a custom error that you can catch (ExecError).
However, we can keep the validation in those fields and still have an exists, but you need to call it from a Directory that you know should exist, and pass it the path that you’re unsure about.

However, we can keep the validation in those fields and still have an exists, but you need to call it from a Directory that you know should exist, and pass it the path that you’re unsure about. Unfortunately this doesn't distinguish between files or directories unless you make specific existsDirectory and existsFile fields.

The other alternative is a custom error, as I said before:

dir, err := dag.Container().From("alpine").Directory("not-exists").Sync(ctx)
var e *dagger.NotExistsError
if errors.As(err, &e) {
    // ...
}

We could make a convenience in the SDK (dir.Exists(ctx)), but it’s best if we can find a rule to encode it in codegen[^1] (like sync), potentially covering other similar kinds of errors, rather than being an isolated thing.
[^1]: With the centralized codegen work.

You were clear the first time, I do understand how the request is processed. The resolver for eg. Container.directory, Directory.directory is not lazy. I'm saying, OK just make it lazy then :) It will match the current developer expectation, and will solve the problem at hand in a simple and elegant way.
You mentioned that making those resolvers lazy would make error messages less useful, but I don't understand how. Can you give an example?

You mentioned that making those resolvers lazy would make error messages less useful, but I don't understand how. Can you give an example?

This validation kind of makes sense to me in how it can improve error messages:
https://github.com/dagger/dagger/blob/de39db1dac4728888a65e05ee131b121f958e298/core/container.go#L735-L740
One example that’s not directly related to this, but is similar, was when I was adding the global connection to Python and started with making the connection lazy. If there was an error in that connection, it would happen in the first field that needed to make a request, usually an obscure id that the SDK hides from you. Took me a while to realize what was happening because the error was very obscure so I decided not to push for lazy connections after that.
Just saying that to explain kind of why the validation makes sense to me, but this is different so let’s question the validation here because it does force it to unlazy in the resolver and that has it’s own downsides.
I tracked it down to this comment from @sipsma in:

https://github.com/dagger/dagger/pull/3217#discussion_r987475016

If you provide a dir that doesn't exist, this won't fail, right? It would only fail at some later time when you tried to do something with the Directory.
If so: it's tempting to add a check here that the dir actually exists (via gateway ReadDir or similar). There technically is a downside to that in that it will cause some buildkit refs to be "unlazied" (i.e. buildkit defers pulling an image until its really needed locally, same for calculating mergeops).
I'm inclined to not care about that performance optimization at the moment because the surprise factor of the error messages you might later get if the dir provided here doesn't exist is probably quite high.

That was on Oct 5, 2022 (when we were getting ready to release the Go SDK) which was a long time ago and seems like more a precaution.
I can remove the validation but it'll take me time to hunt down various ways where it can fail in order to compare how it affects the user experience. Could be negligible in some cases, a breaking change in others, or just more confusing. It’s not something we can take back as the .Exists field seizes to work so that’s why I’m a bit cautious.
I can confirm that dag.Directory().Directory("/foo").Sync(ctx) doesn’t return an error but I can add the validation to sync. I’ll try it for size when I can (soon).
@sipsma and @vito, do you have anything to add?

I have started to look at this issue. could we assign this to me please. thank you.

@rajatjindal can do - I would probably start with https://github.com/dagger/dagger/issues/3764 to familiarize yourself with the file API, but up to you.
Probably also worth discussing with @helderco before starting, just to check what the desired outcome looks like, I'm not sure if anything has changed in the last few months that might change what we want.

Hi @jedevc, sure, I will take a look at that first. thank you for your suggestion.

Hi @helderco, I am currently going through the comments here and on #3764 (and related tickets) to build context on what needs to change and where.
I have a question regarding your comment above:

I can confirm that dag.Directory().Directory("/foo").Sync(ctx) doesn’t return an error, for example, but I can add the validation to sync in this case.

I tried adding a small testcase for verifying current laziness of Directory, and noticed that it fails in above stated scenario as well:
func (DirectorySuite) TestDirectoryLaziness(ctx context.Context, t *testctx.T) {
	c := connect(ctx, t)

	_, err := c.Directory().Directory("/dont-exist").Sync(ctx)
	require.Error(t, err)

	_, err = c.Container().Directory("/dont-exist").Sync(ctx)
	require.Error(t, err)

	_, err = c.Container().Directory("/dont-exist").Entries(ctx)
	require.Error(t, err)
}

all the above functions calls return /dont-exist: no such file or directory error.
could you please help me confirm if that is expected or I am doing something incorrectly here.
thanks

Hi @helderco, I am currently going through the comments here and on #3764 (and related tickets) to build context on what needs to change and where.

I don't think we'll want to move forward with:

#3764

This Directory.exists and File.exists supercedes the need for it. Whatever else that Stat could provide can intead be its own field in Directory or  File. See this comment above: https://github.com/dagger/dagger/issues/6713#issuecomment-2094536129.

I have a question regarding your comment above:

I can confirm that dag.Directory().Directory("/foo").Sync(ctx) doesn’t return an error, for example, but I can add the validation to sync in this case.

[...]
all the above functions calls return /dont-exist: no such file or directory error.
could you please help me confirm if that is expected or I am doing something incorrectly here.

Yes, the current behavior is that Directory("/foo") is validating the existence of the directory, not even getting a chance to execute sync. In the client, the call to Sync(ctx) just produces a query and makes the request, but in the server side, that function doesn't even run.
The point was, for you to create a new dag.Directory().Directory("/foo").Exists(ctx), it'll fall under the same problem where Exists doesn't get a chance to run in the server because of the same validation in Directory("/foo").
So first thing you need to do is to remove that validation in Directory (see snippet in https://github.com/dagger/dagger/issues/6713#issuecomment-2097115794). Now, if you do dag.Directory().Directory("/foo").Sync(ctx), it shouldn't fail. That's because sync evaluates the pipeline, but there's nothing that needs to use the dag.Directory().Directory("/foo") directory, and so without that validation in place, it won't fail.
The implication here is that it can break users that may rely on this early validation that exists today in similar cases, so they'll have to explicitly use .Exists(ctx) in those situations. In most cases, the implication is that it can make the error message more confusing for debugging purposes, since the error should happen when the Directory is used (as an input to another function), rather than when it's evaluated. However, the early validation does break laziness, so it's expected that fixing that may improve performance in some cases.
In conclusion, it's useful to try and move that validation from Directory.directory (etc) into Directory.exists and evaluate how it affects the user experience. The hope is that the benefit of an explicit Directory.exists outweighs the early validation in Directory.directory.

Hi @helderco , I have started work on this and started making some changes in a [WIP] branch here.
I have a couple of questions:

could you please let me know what would be the expected result in following pipeline. with the lazyness changes, it returns an ID (because we removed validation from Directory function). If we want this to return an error, could you please point me to where I would need to make change for making validation work during an ID function:

id, err := c.Container().
            From("alpine:latest").
            Directory("/dont-exist").ID(ctx)

similarly for following scenario, it currently does not return any error because in Evaluate function, we return nil without any error if dir.LLB is nil.

Most of the other TestDirectory and TestContainer tests work beside these two scenarios.
Thanks
Rajat Jindal

could you please let me know what would be the expected result in following pipeline. with the lazyness changes, it returns an ID (because we removed validation from Directory function). If we want this to return an error, could you please point me to where I would need to make change for making validation work during an ID function:

id, err := c.Container().
            From("alpine:latest").
            Directory("/dont-exist").ID(ctx)

To preserve the lazyiness you don't validate on ID. It should either error where it's used or you explicitly call Exists to validate.
I can see users needing a lot of Exists in all sorts of places though because of this. There must be a better way.

similarly for following scenario, it currently does not return any error because in Evaluate function, we return nil without any error if dir.LLB is nil.

_, err := c.Directory().Directory("/foo").Sync(ctx)
require.Error(t, err)
require.Contains(t, err.Error(), "no such file or directory")

This is probably the same as ID, however I wonder if it could validate implicitly.
Let's see, what if you use it to validate an ID?
dir, err := c.Directory().Directory("/doesnt-exist").Sync(ctx)
if err != nil {
    return err
}
ctr.WithDirectory("/sub", dir)  // The SDK requests the ID here before making the query

Isn't this almost the same (needs error handling)?
dir := c.Directory().Directory("/doesnt-exist")
ok, err := dir.Exists(ctx)
if err != nil {
    return err
}
if !ok {
    return fmt.Errorf("my own error message")
}
ctr.WithDirectory("/sub", dir)

Small benefit, but still a convenience. Perhaps it would be better to do this instead:
dir := c.Directory().WithNewFile("/a/b/my-file", "")

ok, err := dir.Directory("/a").Exists(ctx)
if err != nil {
    return err
}
if !ok {
    return fmt.Errorf("no cookie")
}

ctr.WithDirectory(
    "/sub",
    dir.Directory("/a/c", DirectoryDirectoryOpts{
        Check: true,  // equivalent to today, just explicitly enabled
    }),
)

Or even better, flip the default. Basically disable if you need Exists for more advanced logic, but default to validating:
dir := c.Directory().WithNewFile("/a/b/my-file", "")

ok, err := dir.
    Directory("/a", DirectoryDirectoryOpts{
        SkipValidation: true,
    }).
    Exists(ctx)
if err != nil {
    return err
}
if !ok {
    return fmt.Errorf("no cookie")
}

ctr.WithDirectory(
    "/sub",
    dir.Directory("/a/c"),  // works like today, fails at this point in the pipeline
)

I think the last example is the better UX because if you need to rely on Exists, user pipelines will become much more verbose. So it allows the fine grained control when needed but still allows the simplest default for most cases.
However, the downside is that a user may attempt this:
ok, err := dir.Directory("/a").Exists(ctx)
if err != nil {
    return err
}
if !ok {
    return fmt.Errorf("no cookie")  // ❌ never happens!
}

And not realize that it won’t work without the SkipValidation: true option.
TL;DR
In light of this, I think the most sensible thing is to add the Check: true option. This way it also validates on ID, Sync, etc… if you want simple validation without having to call Exists.

Can someone please give me a concrete example of how making the existence check lazy actually makes the DX worse? I see that assumption being made everywhere, with lots of discussions on how to mitigate it. But are we sure there is really something to mitigate? Concrete examples would really help here.

Yeah, I think part of the work here is exploring just that, in order to compare the DX. See what error messages you get when you use a directory as input in several different cases.

Hi @shykes, @helderco
Following are some of the testcases for checking laziness error.
The testcases works as expected on main branch because we have validation in directory.Directory and container.Directory methods. But it fails with different errors once we remove validation from both these functions.

func (DirectorySuite) TestDirectoryLazinessError(ctx context.Context, t *testctx.T) {
	c := connect(ctx, t)

	t.Run("container", func(ctx context.Context, t *testctx.T) {
		t.Run("tc1", func(ctx context.Context, t *testctx.T) {
			// without validation, it return error "input: container.from.directory.asModule.initialize resolve: module name and SDK must be set\n"
			err := c.Container().From("alpine:latest").Directory("/doesnt-exist").AsModule().Initialize().Serve(ctx)
			require.ErrorContains(t, err, "lstat /doesnt-exist: no such file or directory")
		})

		t.Run("tc2", func(ctx context.Context, t *testctx.T) {
			// without validation, it returns "input: container.from.directory.diff.entries resolve: resolve : lstat /tmp/buildkit-mount2166899413/doesnt-exist: no such file or directory\n"
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Diff(c.Directory().Directory("/doesnt-exist")).Entries(ctx)
			require.ErrorContains(t, err, "/doesnt-exist: no such file or directory")
		})

		t.Run("tc3", func(ctx context.Context, t *testctx.T) {
			c := connect(ctx, t)
			// without validation, it returns "input: container.from.directory.file resolve: lstat /doesnt-exist/foo.txt: no such file or directory\n"
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").File("foo.txt").Contents(ctx)
			require.ErrorContains(t, err, "lstat /doesnt-exist: no such file or directory")
		})

		t.Run("tc4", func(ctx context.Context, t *testctx.T) {
			// without validation, it returns "input: container.from.directory.entries resolve: resolve : lstat /tmp/buildkit-mount3306785835/doesnt-exist: no such file or directory\n"
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Entries(ctx)
			require.ErrorContains(t, err, "lstat /doesnt-exist: no such file or directory")
		})

		t.Run("tc5", func(ctx context.Context, t *testctx.T) {
			// without validation, this does not return any error
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Sync(ctx)
			require.ErrorContains(t, err, "lstat /doesnt-exist: no such file or directory")
		})

		t.Run("tc6", func(ctx context.Context, t *testctx.T) {
			// without validation, it returns error -> "input: container.from.directory.glob resolve: resolve : lstat /tmp/buildkit-mount2890696365/doesnt-exist: no such file or directory\n"
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Glob(ctx, "*.*")
			require.ErrorContains(t, err, "lstat /doesnt-exist: no such file or directory")
		})
	})
}

It does feel like removing the validation by default will return error msgs which are not user friendly. and may also result in unexpected results for already published modules. e.g. tc6 in above list does not return any error after validation is removed.
Please let me know what you think and how we should proceed on this.

Oh, I suppose the require.ErrorContains is the "before" error, and the comments are the "after".

There's no examples with WithDirectory, for example. Would also be helpful to diversify a bit more and look into more use cases.

Hi @helderco,
following is the updated list with WithDirectory example. Few things to note:

I have captured the complete error msg now
The enabled assertion is what happens when validation is enabled
The commented out assertion is what happens when validations is disabled.
This is the output with disabling validations only in Directory.Directory and Container.Directory functions and no other changes done elsewhere.
These changes are pushed in a WIP branch here

I will continue to add more testcases to this list to cover more usecases tomorrow.

func (DirectorySuite) TestDirectoryLazinessError(ctx context.Context, t *testctx.T) {
	c := connect(ctx, t)

	t.Run("container", func(ctx context.Context, t *testctx.T) {
		t.Run("tc1", func(ctx context.Context, t *testctx.T) {
			err := c.Container().From("alpine:latest").Directory("/doesnt-exist").AsModule().Initialize().Serve(ctx)
			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.directory.asModule.initialize resolve: module name and SDK must be set\n")
		})

		t.Run("tc2", func(ctx context.Context, t *testctx.T) {
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Diff(c.Directory().Directory("/doesnt-exist")).Entries(ctx)
			require.EqualError(t, err, "input: directory.directory resolve: /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.directory.diff.entries resolve: resolve : lstat /tmp/buildkit-mount3884148634/doesnt-exist: no such file or directory\n"
		})

		t.Run("tc3", func(ctx context.Context, t *testctx.T) {
			c := connect(ctx, t)
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").File("foo.txt").Contents(ctx)
			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.directory.file resolve: lstat /doesnt-exist/foo.txt: no such file or directory\n")
		})

		t.Run("tc4", func(ctx context.Context, t *testctx.T) {
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Entries(ctx)
			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.directory.entries resolve: resolve : lstat /tmp/buildkit-mount3859364930/doesnt-exist: no such file or directory\n")
		})

		t.Run("tc5", func(ctx context.Context, t *testctx.T) {
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Sync(ctx)
			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.NoError(t, err)
		})

		t.Run("tc6", func(ctx context.Context, t *testctx.T) {
			_, err := c.Container().From("alpine:latest").Directory("/doesnt-exist").Glob(ctx, "*.*")
			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.directory.glob resolve: resolve : lstat /tmp/buildkit-mount426363861/doesnt-exist: no such file or directory\n")
		})

		t.Run("tc7", func(ctx context.Context, t *testctx.T) {
			dir := c.Container().From("alpine:latest").Directory("/doesnt-exist")

			_, err := c.
				Container().
				From("alpine:latest").
				WithDirectory("/mounted-foo", dir).
				Directory("/mounted-foo").
				Glob(ctx, "*.*")

			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.withDirectory.directory.glob resolve: failed to compute cache key: failed to calculate checksum of ref n9lagq287siw2a6os7nzr7ix7::hnrt1bom67rf2upvpvhamp6xb: \"/doesnt-exist\": not found\n")
		})

		t.Run("tc8", func(ctx context.Context, t *testctx.T) {
			_, err := c.
				Container().
				From("alpine:latest").
				WithDirectory("/mounted-foo", c.Container().From("alpine:latest").Directory("/doesnt-exist")).
				Directory("/mounted-foo").
				Glob(ctx, "*.*")

			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.withDirectory.directory.glob resolve: failed to compute cache key: failed to calculate checksum of ref n9lagq287siw2a6os7nzr7ix7::hnrt1bom67rf2upvpvhamp6xb: \"/doesnt-exist\": not found\n")
		})

		t.Run("tc9", func(ctx context.Context, t *testctx.T) {
			_, err := c.
				Container().
				From("alpine:latest").
				WithMountedDirectory("/mounted-foo", c.Container().From("alpine:latest").Directory("/doesnt-exist")).
				Directory("/mounted-foo").
				Glob(ctx, "*.*")

			require.EqualError(t, err, "input: container.from.directory resolve: lstat /doesnt-exist: no such file or directory\n")
			// require.EqualError(t, err, "input: container.from.withMountedDirectory.directory.glob resolve: resolve : lstat /tmp/buildkit-mount1338184602/doesnt-exist: no such file or directory\n")
		})
	})
}

Hi @helderco, in context of removing validation from container.Directory and directory.Directory, is there any additional testcase you would like to consider? I added a couple more scenarios, but it seems like I am repeating the testcases now.

@rajatjindal thanks for sharing the error messages before/after the change, that is helpful. It's true that some of those messages are less clear if we make the change. Most of them still have the directory name + some variation of "this doesn't exist" so it might be OK. But it's definitely a downgrade in terms of error message clarity and brevity.
With that in mind, maybe we should consider either:

@helderco 's suggestion of making the new behavior opt-in (CheckExists optional argument or equivalent)
Change approach completely and add a path argument to Exists, eg. Directory.Exists("./not-exist")
Go even further in that direction and implement a Stat which would be a more general version of that.

I realize some of these options have been suggested before :) This all hinges on how bad we think the error message downgrade will be. Which is why getting real-world examples is so important.


RKE2 cluster never becomes healthy with certain machine pool names

2.6.1-rc5
To Reproduce

Create a RKE2 cluster with any node driver (including Harvester)
Name the cluster test-do
Configure a single machine pool using the following machine pool name:  harvester-v.0.3.0-rc1-creds-pool1

Result
The cluster remains unhealthy. Opening cluster explorer fails with error 500.
All cluster nodes are provisioned with conflicting (= identical) node names: test-do-harvester-v0
Screenshots

Root cause
Cluster node names are not correctly sanitizied and truncated, resulting in node names that are neither unique nor satisfy Kubernetes' requirement of meeting DNS label naming standard (RFC 1123). See https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

This isn't a problem with Kubernetes. It is a problem with cloud-init setting the hostname of the machine to something other than what we want.

For reference: https://github.com/canonical/cloud-init/blob/392c3262dcb4108b42f09e1369d9072502302361/cloudinit/util.py#L1014-L1018

Root cause
The issue is caused in RKE2 provisioning when creating a node pool with a . in the name.
What was fixed, or what changes have occurred
Now, Rancher will replace . with - when creating the nodes in the cloud provider. This is because cloud-init will split the name on . and set the node's hostname to the first chunk. This would result in all nodes in a node pool having the same name in Kubernetes, which is bad.
Areas or cases that should be tested
Provisioning an RKE2 cluster from Rancher
What areas could experience regressions?
Only RKE2 provisioning.
Are the repro steps accurate/minimal?
Yes:

Create an RKE2 cluster with a . in the name of its node pool(s)
The cluster will provision and go into an error state.
With this fix, the cluster will provision and not go into an error state and all nodes will have the . in their names changed to -.
NOTE: the node pools will still have the same names (with . in them). Only the nodes in the downstream Kubernetes cluster will have names with . changed to -.

In v2.6.1-rc5 and using the steps as provided, my attempt to repro results in different behavior. I get no errors as described in the original bug, but I DO end up with clusters that are unusable and never finish Provisioning.
In  v2.6-0716b8536337edc5c9294cf1b04cc2b023692e65-head the cluster in DO deploys...but fails healthchecks occasionally. When that happens i get the same 500 Service Error. The behavior is proving inconsistent from cluster to cluster, so I'll update more when I have consistent repros.


Refactor/datatable button link improvments

Sorry for the changes in bread/contrib/workflows, I forgot to switch branches when working on that part.


improve Travis tests

NOTE:
Travis is not free, 3 concurrent jobs will eat your balance up to 3 times faster. Maybe you decide to remove/comment some job to save your money.
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
This build has three jobs, running in parallel.

python3.7-postgresql-9.4-bionic, nothing changed
python3.7-postgresql-10-bionic, run tests with postgresql 10, because it is default version of postgresql  for bionic
python3.8-postgresql-12-focal,   run tests with postgresql 12 and python 3.8, because it is default versions for focal

Test added to Travis:

make test-js  to make sure javascript build successfully

Other changes:

minor changes in gulp/build.js and gulp/karma.conf.js. Sorry for the code styling noising, because files formatted and a few lint errors fixed. Important changes in gulp/build.js;

before:

gulp.task('test', function (done) {
  // returning the promise
  return new karma.Server({
    configFile: __dirname + '/karma.conf.js',
    singleRun: true
  }, function() {
    done();
  }).start();
});

after:

gulp.task('test', function (done) {
    new karma.Server({
        configFile: __dirname + '/karma.conf.js',
        singleRun: true
    }, function (err) {
        if (err === 0) {
            done();
        } else {
            // if karma server failed to start raise error
            done(new gutil.PluginError('karma', {
                message: 'Karma Tests failed'
            }));
        }
    }).start();
});

some javascript deps updated because Travis

I also changed Nodejs version to 10 because in fact lemur required at least this version to build successfully.
close #3387
P.S.
I'm not very experience with Travis, so any suggestions are welcome and appreciated.
P.P.S.
@charhate, sorry for code styling noising again, might be this feature help you to code review:

Coverage increased (+0.02%) to 60.685% when pulling 7f16d44b4863cbb223b3a5cc7dab06d2288c69f7 on sergerdn:feature/travis-python38 into 6eeafcf56b60bf78429952c31b37d305b3f85c80 on Netflix:master.

Coverage increased (+0.02%) to 60.685% when pulling 7f16d44b4863cbb223b3a5cc7dab06d2288c69f7 on sergerdn:feature/travis-python38 into 6eeafcf56b60bf78429952c31b37d305b3f85c80 on Netflix:master.

Thanks @sergerdn for extensive changes including upgrade of karma. Much appreciated.
I went ahead and matched formatting to earlier style of tabs, now it shows fewer changes. Hope that's okay with you.


Upgrade to SA v1.2.0 API spec

The changes in this PR reflect a new requirement that is imposed by the SpecialAgent that mandates an explicit declaration of a plugin's name. The name is intended to distinguish the plugins inside SpecialAgent with a short, concise, and intuitive name.

@jam01, the Travis build is failing, but it should not be. Could you trigger a rebuild for this PR?

@jam01, SpecialAgent v1.2.0 is released. Since there is an API change, the current version of your plugin is not compatible with SpecialAgent. Please let me know when you merge and release the changes in this PR, and I will re-add this plugin into SpecialAgent. I hope to release SpecialAgent 1.2.1, with this plugin, next week on 6/7/2019.

I think the SA version just wasn't available just yet, all good now.


feat(route53resolver): added ResolverRuleAssociation

Signed-off-by: haarchri<EMAIL_ADDRESS>
Description of your changes
this feature fits for DNS management in a multi-account environment with Route 53 Resolver

dns zone example.com lives in central dns aws-account
subdomain zones like test.example.com lives in other aws-account(s) and needs resolver_rule_association to dns aws-account resolver rule (shared via ram)
good documentation: https://aws.amazon.com/de/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/
added route53_resolver_rule_association like terraform https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route53_resolver_rule_association
this resource is not generated with code-gen because we need the option to associate individual vpc with shared (ram) resolver rule

I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
kubectl apply -f examples/route53resolver/associateresolverrule/associateresolverrule.yaml
NAME                                                                                READY   SYNCED   AGE
resolverruleassociation.route53resolver.aws.crossplane.io/sample-associateresolverrule   True    True     2m19s

kubectl describe resolverruleassociation.route53resolver.aws.crossplane.io/sample-associateresolverrule
Name:         sample-associateresolverrule
Namespace:
Labels:       <none>
Annotations:  crossplane.io/external-create-pending: 2022-01-29T12:46:09+01:00
              crossplane.io/external-create-succeeded: 2022-01-29T12:46:09+01:00
              crossplane.io/external-name: rslvr-rrassoc-5666ff000b4044d58
API Version:  route53resolver.aws.crossplane.io/v1alpha1
Kind:         ResolverRuleAssociation
Metadata:
  Creation Timestamp:  2022-01-29T11:46:08Z
  Finalizers:
    finalizer.managedresource.crossplane.io
  Generation:  1
  Resource Version:  1483042
  UID:               2d1500c7-0612-4076-a10d-aea2507251cf
Spec:
  Deletion Policy:  Delete
  For Provider:
    Region:            eu-central-1
    Resolver Rule Id:  rslvr-rr-57432f045f54666aa
    Vpc Id:            vpc-33096b59
  Provider Config Ref:
    Name:  sandbox
Status:
  At Provider:
  Conditions:
    Last Transition Time:  2022-01-29T11:48:11Z
    Reason:                Available
    Status:                True
    Type:                  Ready
    Last Transition Time:  2022-01-29T11:46:09Z
    Reason:                ReconcileSuccess
    Status:                True
    Type:                  Synced
Events:
  Type    Reason                   Age    From                                                               Message
  ----    ------                   ----   ----                                                               -------
  Normal  CreatedExternalResource  2m51s  managed/resolverruleassociation.route53resolver.aws.crossplane.io  Successfully requested creation of external resource

#679 we have one open PR adress this resource

fixed all suggestions, rebased & tested again


vertical spacing between input fields seems off

The vertical spacing for UE nodes looks different than all the other nodes.

Not a big deal obviously, but would be nice to have it consistent.

It's just the Anything Everywhere?  nodes... I've been trying to fix it! But not a priority 😀

Seems to be, I have some larger workflows with hundreds of nodes and only UE stands out. Not a priority ofc :D

I agree this should not be a priority.
But if you have time to work on this, try to fix it in a way that can also solve other related issues.
For instance, when a UE? node changes size, due to parameters being converted to input, it can introduce some minor visual artifacts.


EFU-891 Create component: Templates Card

Codecov Report

Merging #31 (3f1112f) into main (2a17bb1) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #31   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            7        10    +3
  Lines           27        64   +37
  Branches         5        11    +6
=========================================
+ Hits            27        64   +37

Impacted Files
Coverage Δ

packages/cards/src/AddNewItemCard.tsx
100.00% <ø> (ø)

packages/buttons/src/MenuButton.tsx
100.00% <100.00%> (ø)

packages/buttons/src/index.ts
100.00% <100.00%> (ø)

packages/cards/src/TemplateCard.tsx
100.00% <100.00%> (ø)

packages/cards/src/index.ts
100.00% <100.00%> (ø)

packages/cards/src/utils/StateDot.tsx
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

I have added some thoughts that I have found. They are not blockers, but wanted to mention them.


FlushAsync() does not always set context.Response.HasStarted to true

We are writing a test for a special exception handling middleware which should (in contrast to ASP.NET Core's default one) write output to the response in case of exceptions EVEN if the response has already been started.
To test this, we have the following view code:

Render some text

@await FlushAsync();
@{ throw new Exception("Trigger exception handling middlware"); }

However, instead of our exception handling middleware, sometimes the default one is triggered. I.e., on the thread where the default exception handling middlware runs context.Response.HasStarted is still false. How is that possible after awaiting FlushAsync()?
(we're using ASP.NET Core 1.1.x)

We found the problem on our side, sorry for any inconveniences.


added documentation for IO#printf method

Issue: https://github.com/crystal-lang/crystal/issues/3124
As suggested per @asterite on this previous PR  I have used Ruby's sprintf documentation as a template.
The previous examples are using this pattern
io = IO::Memory.new
io.puts "hello\n"
io.puts "world"
io.to_s # => "hello\nworld\n"

but I think that adding all those steps for all the examples I wrote would be just too much.
If you have a better approach, please let me know.
As a side note I would like to mention that, while I was working on the different samples, I noticed that the # option is being processed  but actually never used so I wrote a question mark there.

This is still formatted wrong, please use make crystal and bin/crystal tool format. Also did you miss my comment about documenting ::sprintf instead?

@RX14 still working on this.
Here is the TODO list I have so far

[ ] run crystal formatter tool
[ ] move documentation block to :sprintf and update the samples.
[ ] wrap the samples in blocks and label them with a valid description

You should check the resulting HTML output produced by your API docs.


How to choose release build?

Hi, i try to build from source, but due openssl dependencies error. i want to use stable release which one should i choose?
Currently running void linux, thanks :smile:

I recommend using the release in the releases list. If you're feeling spicy you can try running a release from the most recent main branch build here: https://github.com/Kethku/neovide/actions but theres a fair bit of churn (especially right now)

I recommend using the release in the releases list. If you're feeling spicy you can try running a release from the most recent main branch build here: https://github.com/Kethku/neovide/actions but theres a fair bit of churn (especially right now)

It should be working relatively well if you don't enable multigrid though in the main branch

It should be working relatively well if you don't enable multigrid though in the main branch

i download neovide from release, and try to run it got nothing:
chmod +x ./neovide
./neovide

zsh: command not found: neovide

is there any dependencies to install first?

i download neovide from release, and try to run it got nothing:
chmod +x ./neovide
./neovide

zsh: command not found: neovide

is there any dependencies to install first?

hmmm... I'm not super familiar with linux... Looks like our linux build is building on ubuntu. THe instructions for it are here: https://github.com/Kethku/neovide/blob/main/.github/workflows/build.yml#L88-L123
I don't know if this build would suffice for your use cases? Maybe you need a different kind of build? I'm sure we could add another type of build if it can be cross built on ubuntu?

hmmm... I'm not super familiar with linux... Looks like our linux build is building on ubuntu. THe instructions for it are here: https://github.com/Kethku/neovide/blob/main/.github/workflows/build.yml#L88-L123
I don't know if this build would suffice for your use cases? Maybe you need a different kind of build? I'm sure we could add another type of build if it can be cross built on ubuntu?

well, i did try build with cargo earlier but got error while some dependencies require openssl, i using void linux that use libressl by default. i've read issues with build with void and seems issues was closed.

well, i did try build with cargo earlier but got error while some dependencies require openssl, i using void linux that use libressl by default. i've read issues with build with void and seems issues was closed.

try looking at skia-rs github repo, someone suggesting install libcurl-devel and i try build again with --release or with  --target=x86_64-unknown-linux-musl still can't build skia-bindings
error: failed to run custom build command for `skia-bindings v0.32.1`

Caused by:
  process didn't exit successfully: `/home/gasacchi/xxx/.dev/clone/neovide/target/release/build/skia-bindings-9eeb30d52802e4e0/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)

try looking at skia-rs github repo, someone suggesting install libcurl-devel and i try build again with --release or with  --target=x86_64-unknown-linux-musl still can't build skia-bindings
error: failed to run custom build command for `skia-bindings v0.32.1`

Caused by:
  process didn't exit successfully: `/home/gasacchi/xxx/.dev/clone/neovide/target/release/build/skia-bindings-9eeb30d52802e4e0/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)

Hmmm. Do you get the same issue when building the skia-safe examples https://github.com/rust-skia/rust-skia#example-applications? If so I might make an issue there.

I think this has been fixed in main. Please reopen if you come back to this and the issue remains.


ArrayIndexOutOfBoundsException if number of outputs greater than number of inputs

The assert on line 596 should use getOutputType rather than getInputType.
https://github.com/spring-cloud/spring-cloud-stream/blob/ac0bc4595a85fab5404cce25ffbb92df3c8c433d/spring-cloud-stream/src/main/java/org/springframework/cloud/stream/function/FunctionConfiguration.java#L594-L600
I guess, this has been refactored on the main branch but it would be great to have this fixed on 3.0.x as well.

Resolved with https://github.com/olegz/spring-cloud-stream/commit/b53f2ccbea13dec78978c6fc405fe35c41efe5aa


Allow calling of untyped code from typed code

Would it be possible to allow calling of untyped code? I see in the implementation that this is disallowed, so I'm mostly asking if you are philosophically opposed to this or if this is a current implementation detail.
One thing we did for hack was had an annotation in the file saying if it was strict and in those files they wouldn't allow outbound calls to unchecked code, but for non-strict files you could call untyped code and it would do inference as best it could and mark as Any when it can't.

+1 I'm struggling with this right now.  Gradual typing is OK, but when you need to call out to untyped code it breaks everything.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_a0c58zk4l1/clone/recipe/meta.yaml:15: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_a0c58zk4l1/clone/recipe/meta.yaml:20: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_a0c58zk4l1/clone/recipe/meta.yaml:33: missing_pip_check: For pypi packages, pip check should be present in the test commands
Errors were found


Choice menu for all the registered commands

Description
When we build console programs we often want to invoke them with direct commands and parameters from a commandline, as well as to run them interactively from some kind of menu system to select a command from that you want to run. To achieve this I added a default command "Menu" that shows a numbered list of all the commands and uses a selectionprompt to chose the command. I know the menu system wouldn't handle the command arguments, however we use appsettings a lot.
Describe the solution you'd like
It would be nice to have such a command OOB, and if that is a to specific request to have at least the possibility to have somewhere a list of the registered commands available in the context in a way we can also Run them.
Describe alternatives you've considered
An awfull solution I quickly put together, however it works for me.
It was (at least to my understanding) rather difficult to achieve this currently and I had to do a lot of workaround to make it work, the execute method of the default Menu command:
public override int Execute(CommandContext context)
{
var type = GetType().Assembly.GetName();
_con.MarkupLine($"[yellow]{type.Name} v.{type.Version.Major}.{type.Version.Minor}[/] dotnetcore REST Client");
_con.MarkupLine("[blue]--help for info[/]");
    var commandAppService = _provider.GetService(typeof(Spectre.Console.Cli.ICommandApp));
    var commandApp = commandAppService.GetType().GetField("_app", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance).GetValue(commandAppService);
    var configurator = commandApp.GetType().GetField("_configurator", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance).GetValue(commandApp);
    var commands = configurator.GetType().GetProperty("Commands").GetValue(configurator) as IList;

    var prompt = new SelectionPrompt<SelectionCommandItem>() { SearchEnabled = true }
        .Title("Select command to run:")
        .PageSize(20)
        .MoreChoicesText("[yellow][[more]][/]");
    prompt.Converter = item => { return $"[[{item.Sequence + 1:000}]] - {item.CommandTitle}"; };

    string commandTitle;
    for (byte count = 0; count < commands.Count - 1; count++)
    {
        var configuredCommandType = commands[count].GetType();
        var commandType = configuredCommandType.GetProperty("CommandType").GetValue(commands[count]) as Type;
        var executeType = (commandType.BaseType.Name?.StartsWith("Async") == true) ? "Async" : string.Empty;
        var settingsType = configuredCommandType.GetProperty("SettingsType").GetValue(commands[count]) as Type;
        commandTitle = configuredCommandType.GetProperty("Name").GetValue(commands[count]) as string;
        prompt.AddChoice(new SelectionCommandItem(count, commandTitle, commandType, settingsType, executeType));
    }

    prompt.AddChoice(new SelectionCommandItem(commands.Count, "QUIT", null, null, null));

    var selection = _con.Prompt(prompt);

    if (selection.CommandTitle.Equals("QUIT"))
        return 0;

    _con.MarkupLine($"Executing command: [yellow]{selection.CommandTitle}[/]");

    var command = ActivatorUtilities.CreateInstance(_provider, selection.CommandType);
    var settings = ActivatorUtilities.CreateInstance(_provider, selection.SettingsType);

    selection.CommandType.InvokeMember($"Execute{selection.ExecuteType}", BindingFlags.InvokeMethod, null, command, [context, settings]);

    return 0;
}

and
public sealed class SelectionCommandItem(byte sequence, string commandTitle, Type commandType, Type settingsType, string executeType)
{
public byte Sequence { get; } = sequence;
public string CommandTitle { get; } = commandTitle;
public Type CommandType { get; } = commandType;
public Type SettingsType { get; } = settingsType;
public string ExecuteType { get; } = executeType;
}

Please upvote :+1: this issue if you are interested in it.

An interesting idea.

Although interesting, I think this is outside the scope of the project, and probably more suited as an external extension to Spectre.Console.

Yes, indeed. We still need to think about what other wigets may qualify for it too, and see how a new project/NuGet package for them might be setup.

An external extension would be fine, however it would mean that some of the sealed classes need to become public to be able to achieve this ?

@flupkede What classes would that be?

@patriksvensson , to my understanding which might be wrong.
I used public sealed class CommandApp to get the configurator
I used internal sealed class CommandConfigurator to get the registered commands.

A recent discussion about this idea FYI, see: https://github.com/spectreconsole/spectre.console/discussions/1610

@flupkede, @patriksvensson - I would be keen to investigate this further, as the idea of future community extensions is of personal interest to me. However @flupkede, I probably won't have spare capacity for another 4 weeks until my current CLI work is complete. Don't hesitate to ping me around that time to ensure this hasn't slipped my mind.

@FrankRay78 I would be more then happy to collaborate on this project, however I will require some of your guidance and direction.

@FrankRay78 I would be more then happy to collaborate on this project, however I will require some of your guidance and direction.

@flupkede I've got a proposal for you, which I will write up shortly for your consideration. My support comes free 😉

Hello @flupkede, apologies for the delay - I had a few things to finish off first. So, I'm not entirely sure why, but I'm personally interested in the idea of extensibility points and enabling community plugins (perhaps more so than other maintainers... 😉). I extended the help provider to make it pluggable, see here, a worthy labour of love. It's not yet entirely done in my eyes, but the foundation has been set.
There is a long-standing, not to be broken, design decision within Spectre.Console that internal, sealed classes will never be exposed. However, as per the help provider above, exposing necessary functionality through interfaces and DI is allowable, if well reasoned. I've spoken with the other maintainers, and whilst there is no guarantee of merging, I've got the greenlight to proceed with investigating this further, and potentially making the case for exposing necessary interfaces for your Choice menu.
The most mature community extension we currently have is Spectre.Console AutoCompletion, however, that's been implemented without input from the core maintainer team, so the author 'liberated' internal classes (in a similar way to your use of Reflection). Access modifiers were basically turned off on a blanket basis ie:
<PackageReference Include="IgnoresAccessChecksToGenerator" Version="0.6.0" PrivateAssets="All" />

See here.
My proposal to you, and the same I put to the other maintainers, is you could create a repo somewhere for your Choice widget, reference Spectre.Console and turn off access checks by including the above in your project file. Author the widget to a good professional standard, and once done, we'd remove the line from the project file, enforcing access checks to show exactly where the project fails to compile. We would then have a clear understanding of what classes need to be exposed, and could look to POC that through interfaces on a branch.
Baring an unforeseen act of god, I can commit to supporting you with this, up to the point where the Spectre.Console team make their decision. I'd be happy to 'present' the findings of this piece of work, so it doesn't end up ignored. Have a think about it and let me know your thoughts.

Really interesting timing running across this.  I've started building another dotnet global tool and naturally Spectre is my first choice as I've used it in the past and have enjoyed it (Thanks!!)
In this new console app, I was searching if there was an existing way to have the app be able to pivot between specifying the full command / branches and options without requiring any interactivity, but I'd also like to have the app intelligent enough to prompt for the information that's required but not specified...
So for instance I'm working on an app to help synchronize dev certificates and profiles for mobile apps...
I might have a command like gizmo create apple certificate --type=Development --common-name="Acme".  I'd also like the user to be able to invoke the app with gizmo create apple or gizmo create or gizmo and have it prompt for branching selections based on how the CommandApp is composed.  So if I start with gizmo create I get a list of choices (eg: Apple, Google, Token, etc) and as I make choices I navigate the branches.
Similarly I'd like to be able to 'fill in' Command Settings for those not specified.  So, prompt for --type and as an enum, give me the list of choices.  If it's text/numeric/etc input, parse out the input from a prompt.  The command option description and name could be displayed during this interactive set of prompts.  The information is all basically here, we just need a way to drive the experience :)
Unfortunately I won't have any time to help contribute myself, so I'm merely adding a +1 request and some thoughts for how I'd like to use something like this, and will again express my gratitude to everyone who's put effort into this project as I've enjoyed using it.

Hello @Redth, thank you for taking the time to comment above — It's useful context and helps us to gauge community needs. If the app you are working on is open source, would you be kind enough to share the repo URL here? The choice functionality, can of course, be implemented generically, however it would be great to see at least one real world app that's an intended consumer.


AB#169199: Update kerberos-protocol-registry-kdc-configuration-keys.md

Clarifying where the time difference is permitted.
Add additional information RE: impact of SkewTime on kerberos ticket reuse

Learn Build status updates of commit d69e292:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

support/windows-server/windows-security/kerberos-protocol-registry-kdc-configuration-keys.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@WAftring Thanks for your contribution. We will review the changes.


[Sensors] Fix:avoid calling setState() when mounted is false.

It is an error to call [setState] unless [mounted] is true.
Description
The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback. Another solution is to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is retaining a reference to this State object after it has been removed from the tree. To avoid memory leaks, consider breaking the reference to this object during dispose().
#0      State.setState. (package:flutter/src/widgets/framework.dart:1105:9)
#1      State.setState (package:flutter/src/widgets/framework.dart:1140:6)
#2      SnakeState.initState. (package:.../qy_sensors/snake.dart:77:7) // setState()
#3      _rootRunUnary (dart:async/zone.dart:1132:38)
#4      _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#5      _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
#6      _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:336:11)
#7      _BufferingStreamSubscription._add (dart:async/stream_impl.dart:263:7)
#8      _ForwardingStreamSubscription._add (dart:async/stream_pipe.dart:132:11)
#9      _MapStream._handleData (dart:async/stream_pipe.dart:232:10)
#10     _ForwardingStreamSubscription._handleData (dart:async/stream_pipe.dart:164:13)
#11     _rootRunUnary (dart:async/zone.dart:1132:38)
#12     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#13     _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
#14     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:336:11)
#15     _DelayedData.perform (dart:async/stream_impl.dart:591:14)
#16     _StreamImplEvents.handleNext (dart:async/stream_impl.dart:707:11)
#17     _PendingEvents.schedule. (dart:async/stream_impl.dart:667:7)
#18     _rootRun (dart:async/zone.dart:1120:38)
#19     _CustomZone.run (dart:async/zone.dart:1021:19)
#20     _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#21     _CustomZone.bindCallbackGuarded. (dart:async/zone.dart:963:23)
#22     _rootRun (dart:async/zone.dart:1124:13)
#23     _CustomZone.run (dart:async/zone.dart:1021:19)
#24     _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#25     _CustomZone.bindCallbackGuarded. (dart:async/zone.dart:963:23)
#26     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#27     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)

Closing due to lack of updates.


Fix issue with Testing package in Xcode version 16.0 beta (16A5171c)

Using Swift 6 (swiftlang-<IP_ADDRESS>.300 clang-16<IP_ADDRESS>)

Hi @bradhowes, the 16A5171c build of Xcode was beta 1, and Swift's Testing framework has gone through a lot of changes since then. We currently only support the newest version of the framework, and it's not really feasible to support older versions. There's no way for us to conditionally provide code depending on the beta of Xcode being used.
If you update to a newer beta things should compile just fine.
Since this isn't an issue with the library I am going to convert this to a discussion. Please feel free to continue the conversation over there.

Sorry. My fault on that. Thanks!


incomplete ParsingOptions/WritingOptions interface in Typescript in index.d.ts

When trying to read an excel xml file generated in ag-grid, I stumbled upon encoding problem.
Then I noticed, that the problem is fixed, when I read workbook with options  { type: 'string' } in browser console.
However typescript is not letting me to build such a code, because types description clearly states only following allowed options:
 /** Options for read and readFile */
 export interface ParsingOptions extends CommonOptions {
     /** Input data encoding */
   type?: 'base64' | 'binary' | 'buffer' | 'file' | 'array';

Here is the description for the options:
https://www.npmjs.com/package/xlsx#input-type
The same goes for both WritingOptions options as well as ParsingOptions options

Here's my pull request with the following issue fixed:
Pull request #1027


Unable to get accuracy on tesseract 4.0 for engraved or stamped metal plate recognition

Hi,
please find attached images to OCR stamped or engraved VIN images.

Environment

Tesseract Version: <IP_ADDRESS>90314

Platform: Windows, 10 64-bit

Current Behavior: Not getting accuracy for recognition of engraved metal plate
Expected Behavior: need to recognize all VIN number.
Suggested Fix:
how to achieve to recognise all VIN or engine number stamped characters.
Also suggeest how to convert it like printed text on white paper.

Please respect guidelines for posting issue: use tesseract user forum for asking questions/support.

@zdenop sir please help me on pre-processing of images so that we can easily recognise image .

bro did u solved this issues please reply

I am also having same issues if u find out please reply that will help me.
how to solve this issue

i have also same question if you have solution please help me


Wrong in-book reference in Muwatta Malik

Asselamu Aleykum,
The "in-book reference"  in Muwatta Malik is everywhere the "hadithnumber". Example:
"hadiths": [ 		{ 			"hadithnumber": 1020, 			"arabicnumber": 1020, 			"text": "Yahya related to me ....", 			"grades": [ 				{ 					"name": "Salim al-Hilali", 					"grade": "Sahih" 				} 			], 			"reference": { 				"book": 22, 				"hadith": 1020 			} 		} 	]
Instead of "Book 22, Hadith 1020" it should be "Book 22, Hadith 8"

This is fixed now


Self params & type

This implements type inference for self, so field completion for methods taking self works now.

rename IMPL_ITEM to IMPL_BLOCK -- rustc calls the methods etc. inside an impl ImplItems, and the impl itself doesn't define an item, so I thought this name was clearer.
add HIR for impl blocks -- we collect all impls in a crate at once, so we can go from methods to containing impls, and since we will later also need to find all impls for a certain type (which may be anywhere in the crate, I think?). We could be more lazy here, but I don't know if it's worth the complexity.
resolve self and Self during type inference
refactor a bit in ty.rs as well

rename IMPL_ITEM to IMPL_BLOCK -

Good name! I remember being confused a lot by the fact that libsyntax parser has both parse_impl_item and parse_item_impl methods :)

@flodiebold when rebasing this, could you send e7eff8047165638994c51ebcaa5b36f89b2d24a6 as a separate PR first? I think that's the commit that's going to cause large number of conflicts, so it's better to merge is separately.

@matklad Done! And I'll do the impls-per-module now.

@matklad impls are now collected per module (so there's one arena per module). I didn't even implement the second step (collecting all the impls in a crate) now, since it wasn't necessary anymore for this.

bors r+
:tada:


Error with seed of enviroment

Hello, I was trying to reproduce your results with the instructions you gave, but when I run the first experiment I get the next error. Sorry, I'm a little newbie, could you help me?

multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\multiprocessing\pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\multiprocessing\pool.py", line 48, in mapstar
return list(map(*args))
File "C:\Users\xxxx\xxxx\OfflineRL-master\ex_01.py", line 33, in create_ds
train_online(experiment=experiment, agent_type=behavioral, discount=discount, envid=env,
File "C:\Users\xxxx\xxxx\OfflineRL-master\source\train_online.py", line 43, in train_online
env.seed(seed)
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\site-packages\gym\core.py", line 241, in getattr
return getattr(self.env, name)
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\site-packages\gym\core.py", line 241, in getattr
return getattr(self.env, name)
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\site-packages\gym\core.py", line 241, in getattr
return getattr(self.env, name)
AttributeError: 'CartPoleEnv' object has no attribute 'seed'
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "ex_01.py", line 106, in
p.map(create_ds, range(1, multiple_useruns + 1))
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\multiprocessing\pool.py", line 364, in map
return self._map_async(func, iterable, mapstar, chunksize).get()
File "C:\ProgramData\Anaconda3\envs\offline_rl\lib\multiprocessing\pool.py", line 771, in get
raise self._value
AttributeError: 'CartPoleEnv' object has no attribute 'seed'

The issue seems to be a wrong gym version, the one used throughout the experiments is 0.19.
I uploaded a dump of the environment used throughout the experiments for reference.


chicken causing crashes

https://mclo.gs/Pqjyi5O

this mod is not being correctly maintained,bruh


Don't set next_state until finish for Wait state

By setting the next_state in Wait#start we were bypassing the Wait#finish step because the next_state was already set.  This caused missing entries in the context for the state completion.
Before:
$ bundle exec exe/floe --podman --workflow examples/wait.asl --input '{"foo": 1}'
I, [2024-02-14T11:19:44.894906 #87255]  INFO -- : checking 1 workflows...
I, [2024-02-14T11:19:44.895029 #87255]  INFO -- : Running state: [FirstState] with input [{"foo"=>1}]...
D, [2024-02-14T11:19:44.895117 #87255] DEBUG -- : Running podman run --detach -e foo\=1 --name floe-sleep-4f985a02 localhost/sleep:latest
I, [2024-02-14T11:19:59.828972 #87255]  INFO -- : Running state: [FirstState] with input [{"foo"=>1}]...Complete - next state: [WaitState] output: [{"foo"=>1}]
I, [2024-02-14T11:20:00.035521 #87255]  INFO -- : Running state: [WaitState] with input [{"foo"=>1}]...
I, [2024-02-14T11:20:05.000492 #87255]  INFO -- : Running state: [SuccessState] with input [{"foo"=>1}]...
I, [2024-02-14T11:20:05.000658 #87255]  INFO -- : Running state: [SuccessState] with input [{"foo"=>1}]...Complete - next state: [] output: [{"foo"=>1}]
I, [2024-02-14T11:20:05.000713 #87255]  INFO -- : checking 1 workflows...Complete - 1 ready
{"foo"=>1}

Notice there is no Running state: [WaitState] with input [{"foo"=>1}]...Complete log line

@kbrock yeah exactly, Wait and Task are the only two currently which aren't ready? immediately, and Task already set next_state in #finish

Would it make sense to put finish into everything and put the next_state change into fail, pass, succeed, task?
(maybe choice?)

Would it make sense to put finish into everything and put the next_state change into fail, pass, and succeed even though they are ready immediately.

I think that's what I've done, every state that has Next sets next_state in finish now.  Task is a little different as you mentioned which is why I clear the next state in the failure case.


Refs #31026 -- Updated TemplatesSetting docs to refer to forms.

Noticed when reivewing #15223. I think this section of the docs needs to be generalised to refer to both forms and widgets.

@smithdc1 Thanks :+1:


DBZ-705: Postgres alpine images

Build Alpine Linux versions of the postgres images.
These images are much smaller than the default Debian-based images.

Thanks, @csdev! Could you file a JIRA issue and reference its number in the commit message?

@jpechane I think it's a good addition. Once it's merged we also should set up jobs for testing on CI.

Hey @csdev, just to let you know that this PR is not forgotten. We're in the process of releasing 0.8.0.Beta1 and this requires quite some changes to the release process (as we have a new separate repo now with incubating connectors). So we'll get back to this one once the dust has settled. Sorry for the delay, it's definitely a good change and I'd like to publish these images eventually.

@csdev, Applied, thanks, images should be now built automatically

@csdev I am sorry but I've to remove the PR, I got this error later on on of the systems
WARNING: This apk-tools is OLD! Some packages might not function properly.
(1/1) Installing json-c (0.13.1-r0)
OK: 28 MiB in 34 packages
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
WARNING: This apk-tools is OLD! Some packages might not function properly.
ERROR: unsatisfiable constraints:
  so:libcrypto.so.43 (missing):
    required by:
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
                 gdal-2.3.0-r0[so:libcrypto.so.43]
The command '/bin/sh -c if [ "$USE_POSTGIS" != "false" ]; then         apk add --no-cache --repository 'http://dl-cdn.alpinelinux.org/alpine/edge/main' json-c         && apk add --no-cache --repository 'http://dl-cdn.alpinelinux.org/alpine/edge/testing'             postgis-dev proj4-dev;     fi' returned a non-zero code: 4

@jpechane Some of the packages required for postgis support are only available on alpine edge, and it looks like that branch is too unreliable right now. I'll try to find a way to make this build more reproducible, but if that doesn't work, we may want to wait for the next stable alpine release.


有什么途径可提高输出质量？(Phi2 参考)

MNN 的输出和 Sample Code 比起来，有区别. Prompt 是 "Einstein said"
Sample code:

'Einstein said that the universe is like a giant machine, and that everything in it is connected. He believed that the universe was made up of tiny particles called atoms, which were constantly moving and interacting with each other.\n\nEinstein's theory of relativity also helped us understand how gravity works. He believed that gravity was not a force, but rather a cuin the fabric of space-time. This means that objects with mass create a "dent" in space-time, which causes other objects to move towards them.\n\nEinstein's work has had a huge impact on our understanding of the universe. His theories'

Phi2 (下载的参数):

, the most important thing is to "do the right thing" and that the most important thing is to "do the right thing" and to "do the right thing" and to "do the right thing" and to "do the right thing" and to "do the^C

Phi2 自己编 8-bit:

, "God does not play dice with the universe."
The universe is a complex system. It is not a random process.
The universe is a complex system. It is not a random process. It is a complex system. It is a complex system. It is a complex^C

8-bit 明显比 4-bit 好, 但还是比不上 Sample Code 的质量。

譬如说，我先跑 AutoGPTQ 制造一个 checkpoint，之后能 convert 成 MNN 吗 （不需要再quant)。

I dont think GPTQ is supported on MNN. Every New Quantization needs its own Dequantize Kernel or logic to dequantize weights in the Operator kernels.

譬如说，我先跑 AutoGPTQ 制造一个 checkpoint，之后能 convert 成 MNN 吗 （不需要再quant)。

如 @Nick-infinity 所说，目前确实还不支持GPTQ格式的量化；这个需要增加kernel的实现。我们在考虑这个问题了，之后会支持多种量化方式。
目前来看增加精度的一些方法如下：

使用int8非对称量化转换模型；
在模型运行时将precision从Precision_Low修改为Precision_Normal

谢各位大佬！


Make the "Picking this aura will change CPS by..." tooltip conform to selected format for large numbers

When changing from one aura to another there is a tooltip that shows how CPS will change, but the number is not shown in the notation used throughout the rest of Cookie Clicker, which makes it very difficult to read.
I propose that the change in CPS should be reflected here in the same format as the change from buying an upgrade. It should match the notation for large numbers selected in Options.

This is related to #734


UnicodeDecodeError

I have encountered the following error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfd in position 1: invalid start byte thrown on line 236 of torrent_parser.py
Your tests might not have encountered this due to a small sample size, since I use your library to processes a thousands of torrents in an hour. Thats how I found it.
I have temporarily fixed this by adding the ignore flag on the byte string decode function like so.
string = raw.decode(encoding, "ignore")
It would be lovely if you could add this to the upstream directory.
A test file I used is attached:
auratorrent.torrent.zip
The PR request is #5
This is covered here: https://docs.python.org/3/howto/unicode.html

I just merged your PR #5, but I came up with some ideas just now, and want to discuss them with you (and others).

I notice the error happened because there is a field magnet-info.hash_info, which doesn't seem to be a string, instead, it's a piece of hash value. I'm wondering if I should/need add it to the field list whose member will be treat as hash automatically. (see line 108 and 189)

The decoding error handler will become an option of TorrentFileParser class and parse_torrent_file shortcut function. It's default behavior will not change, that is, default value of it will be strict. You can use ignore or replace to avoid exception if you wish. But if I added hash_info to that list, your error will disappear automatically. So I think use "strict" as error handler and add try catch to bypass REAL invalid torrent is the best way.

I can add an method to TorrentFileParser and TorrentFileCreator to let user add their own hash value field to that list. But I'm wondering if it is worth to do.

I already change string decoding error handler to an argument in dev branch by commit ee3128b32bc9542568c356ce91ecea6d7978eb57.

Yes. Maybe the field was created by an obscure client or private torrent index.

For general use I think your suggestions of passing 'strict' to .decode() errors argument is okay.
But for my use case, giving me the option to pass my own argument would be perfect. Fault tolerance is a desirable quality in a crawler. I need the 'ignore' or 'replace' flag as I wish to collect as many files as possible.
Given the scale of my operation such errors are bound to happen, and I might lose out on thousands of potentialy working torrents. I have 87 torrents with the same magnet-info.hash_info issue right now. As long as the torrent works at the minimum, I add it.

Yes it might be useful to a small percentage of users. If it is not too much work, add it and document it.

To conclude, I think if you add many different options for achieving many different goals(as long as you write good tests and documentation), your library will appeal to a broader audience.
Don't lock out a subset of users.  If you need help tag your Kanban board with help wanted
Thank you.

Thanks for your idea.
I will finish the customize hash fields API tomorrow and release a new version.
Due to the break change and so may thing be added, It will be 0.3.0.
(And yes, in 0.x.x break change don't need add the major version... I'm still considering when to reach the 1.0 :hourglass:)

No problem take your time

v0.3.0 just released.
In this version, there are many way to deal with this problem:
import torrent_parser as tp

file = 'tests/test_files/utf8.encoding.error.torrent'

# way 1

data = tp.parse_torrent_file(file, errors='ignore')
print(data['magnet-info']['info_hash'])

data = tp.parse_torrent_file(file, errors='replace')
print(data['magnet-info']['info_hash'])

# way 2

data = tp.parse_torrent_file(file, hash_fields={'info_hash': (20, False)})
print(data['magnet-info']['info_hash'])

# way 3

data = tp.parse_torrent_file(file, hash_fields={'info_hash': (20, False)}, hash_raw=True)
print(data['magnet-info']['info_hash'])

# If you don't use any above option

try:
    data = tp.parse_torrent_file(file)
except tp.InvalidTorrentDataException as e:
    print(e)

the output:
jysL
�j��y�sL�
36fd06b595119b380df46ab2f2a0b579b1734ca8
b'6\xfd\x06\xb5\x95\x11\x9b8\r\xf4j\xb2\xf2\xa0\xb5y\xb1sL\xa8'
Fail to decode string at pos 16436 using encoding utf-8 when parser field "info_hash", maybe it is an hash field. You can use self.hash_field("info_hash") to let it be treated as hash value, so this error may disappear

the hash_field("info_hash") is added to the class:
with open(file, 'rb') as f:
    data = tp.TorrentFileParser(f).hash_field('info_hash').parse()
    print(data['magnet-info']['info_hash'])
    # 36fd06b595119b380df46ab2f2a0b579b1734ca8

with open(file, 'rb') as f:
    data = tp.BDecoder(f.read()).hash_field('info_hash').decode()
    print(data['magnet-info']['info_hash'])
    # 36fd06b595119b380df46ab2f2a0b579b1734ca8


Import of CSV files into a GraphCool Project

I am trying to import a backup of data that I got from the graph cool (Prisma) team into a different project on the Graph Cool framework.   I don't see anywhere in the documentation on how to import CVS files via the command line.
I've tried the following commands view the command line inside of my local graph cool project to import the data into my new project:
graphcool import --data test.zip --target dev
graphcool import -d test.zip -t dev
and this is the response i get:
Unknown flag —data
I also tried graphcool import --source test.zip --target dev and get the following:
Invalid signature: 0x80014
Any solutions/help on importing CSV files into a GraphCool project would be greatly appreciated.
Thank you!

@kdipaolo : Can you validate that the CSV is in valid NDF format?
If no, we might have to convert it to NDF shape and import to work properly.

@divyenduz I don't believe it is a valid NDF format, they are just plain CSV files.  How can I convert it to a valid NDF Shape?


Prototype persistent directories

Description:
Is this change user facing?
NO

References (if applicable):

Addressed in #1028


Smarter state machine to use internal vbatt when CAN not connected

Need to be checked on F103 board with no Vbatt divider added to PA5.
Floating input can be readed as non-zero and cause unpredictable Vbatt reading.
Should we enable pull-down on PA5? Will this affect Vbatt measurement accuracy?

Should we enable pull-down on PA5? Will this affect Vbatt measurement accuracy?

Dunno. What's the rough pulldown value on an F1?

Pull-down is in range 30 .. 50 K.
And it is not possible to enable pull-up or pull-down while gpio is in analog mode.
@rusefillc said that there is no users of F103 wideband rev 0.


Move to newer VPP version

Coverage decreased (-0.06%) to 76.292% when pulling d164da27165e53763a9e5f743d424ece786f4421 on rastislavszabo:master into 50714dc73b58a891247e3ceff91565569e8bc3df on contiv:master.


Add fake oauth.Client implementation

Move existing fakes out of oauth_test.go and into its own package for
consumption by other tests.

Fixes https://github.com/AzureAD/microsoft-authentication-library-for-go/issues/156


from_ir does not seem to support input parameters

Describe the bug
Unable to create Circuit class using from_ir when the source program contains parameters
To reproduce
from braket.circuits import Circuit

parametric_source = "OPENQASM 3.0; input angle alpha; qubit[2] q; bit[2] c; rx(alpha*2) q[0]; rz(alpha) q[1]; c = measure q;"
Circuit.from_ir(parametric_source, inputs={"alpha": 0.1})

Expected behavior
I expect to get back an instance of the Circuit object like when the source does not contain an input parameter
Screenshots or logs
Error when I try the program above:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/circuits/circuit.py", line 1148, in from_ir
    return Interpreter(BraketProgramContext()).build_circuit(
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 135, in build_circuit
    self.visit(program)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 169, in _
    self.visit(node.statements)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 165, in _
    return [n for n in [self.visit(node) for node in node_list] if n is not None]
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 165, in <listcomp>
    return [n for n in [self.visit(node) for node in node_list] if n is not None]
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 194, in _
    self.visit(declaration)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 176, in _
    init_value = cast_to(node.type, init_expression)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 889, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/_helpers/casting.py", line 41, in cast_to
    raise TypeError(f"Cannot cast {type(variable).__name__} into {into.__name__}.")
AttributeError: 'AngleType' object has no attribute '__name__'. Did you mean: '__ne__'?

When I try to skip providing a value for the input parameter, I see a different error:
Circuit.from_ir(parametric_source)

Error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/circuits/circuit.py", line 1148, in from_ir
    return Interpreter(BraketProgramContext()).build_circuit(
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 135, in build_circuit
    self.visit(program)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 169, in _
    self.visit(node.statements)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 165, in _
    return [n for n in [self.visit(node) for node in node_list] if n is not None]
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 165, in <listcomp>
    return [n for n in [self.visit(node) for node in node_list] if n is not None]
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/functools.py", line 926, in _method
    return method.__get__(obj, cls)(*args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/Braket/lib/python3.10/site-packages/braket/default_simulator/openqasm/interpreter.py", line 191, in _
    raise NameError(f"Missing input variable '{node.identifier.name}'.")
NameError: Missing input variable 'alpha'.

System information
A description of your system. Please provide:

Amazon Braket Python SDK version: 1.49.1
Amazon Braket Python Schemas version: 1.19.0
Amazon Braket Python Default Simulator version: 1.18.2
Python version: 3.10.12

Additional context
N/A

Hello @rchilaka-amzn, thank you for raising this issue. I shall have a look at this and work on a fix.

Should be fixed as of v1.52.0

@krneta ro validate that this issue can be closed.

This is still an issue.
The work around is to not use "angle", but to instead use "float".
Supporting "angle" would require some work and would need to be added to our backlog. Adding Zia to determine the priority.

angle support fixed in the linked PR to the default simulator.

angle is supported as of v1.53.1


Analyzing divided into two parts

At present, some responsibilities for analyzing (e.g. recognizing context) takes place on the vim side and the other on PHPCD. What do you think about this partition?
For example, what idea on completion of available local variables in given context (like from get_defined_vars() in running code) do you have? Do you want to burden vim side to achieve it?
/** YCM's identifier based completion is not context sensitive and, even worse, does not distinguish between variable and another string. I have disabled it because of showing lots of unneeded items. **/

Actually the phpcomplete.vim has some feature like this. However, it's not as better as YCM does, so I droped them at c24c0a09210cb345bcf1b7ce35bab03d9952a64d . FYI.

The idea that using get_defined_vars() to make context sensitive completion is amazing, but it seems not easy to implement.

I mentioned about get_defined_vars() only for comparison, not for using, because it this would probably imply code evaluation, which is very insecure.

Transfer the whole parsing logic to the PHPCD side seems to be revolutionary idea that require a lot of work, but it seems to be more clear. For comparison, eclim client sends to server the file name and byte offset of cursor (something about line2byte('.')+col('.')-2)
 [-editor, vim, -command, php_complete, -p, phpcdFixtures, -f, PHPCD/A/Alpha.php, -o, 503, -e, utf-8]

byte offset won't work on unsaved buffer

...unless there is a way to use unsaved buffers to pretend their physical equivalents.

BetterReflection can parse code passed as string, i wonder if it can be used for that.


Updated C++ Section

Issue fixed #68

@astha2412 please share a video or some ss

@Snehaa1203 please review this PR

hey, I am quite unwell.
Give me some time, I will review all these.
On Wed, Jan 5, 2022 at 8:02 PM Kumari Astha Rani @.***>
wrote:

[image: Screenshot (344)]
https://user-images.githubusercontent.com/87020129/148234282-ba086271-f2e3-4d4b-8864-9bdd51215203.png
[image: Screenshot (345)]
https://user-images.githubusercontent.com/87020129/148234321-a72dee6f-1f48-4832-a649-c42e5dab4f99.png
[image: Screenshot (346)]
https://user-images.githubusercontent.com/87020129/148234347-475fff06-f8de-497b-b60a-ce7cfbdf275a.png
—
Reply to this email directly, view it on GitHub
https://github.com/arpit456jain/CodingEasy/pull/87#issuecomment-1005736273,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASL2QG4UEC6TACAEMW5VB2DUURJAXANCNFSM5LJ7DZDA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Looks fine, possible to add some colors to the text?
Black white looks quite dull!

Looks fine, possible to add some colors to the text? Black white looks quite dull!

create a issue for that @Snehaa1203 and add label for SWOC
good idea


Linear Line of Sight not producing any output

Repro:
[insert a new map in pro]

remove the topographic basemap from your map
add elevation data, in my case i was using "ElevationUTM_Zone10" from the military tools test data gdb, this is available from the github repo.
open the visibility pane
click on the llos tab
use the observer map point tool to select one or many input observers
use the target map point tool to select one or many targets
leave the defaults
click OK
get a warning message "LLOS computations did not complete correctly. Please try again by selecting the 'OK' button."
click ok to close the message
click ok on the visibility pane again
this time Pro just hangs  just hangs (no windows based program is unresponsive message though)

@mfunk

@dfoll, I cannot reproduce this with the steps provided.  All works fine for me on the current build.
@topowright could you test this on your end and see if you can reproduce it?  I tested with the latest build at \redarchive2\disl\Development\Commercial\MilitaryToolsForArcGIS_current\ArcGISPro\Addins

I am not able to reproduce this issue either. This could be a relic of a previous add-in. I would blow away all Pro directories in the profile directories and uninstall the add-in and reinstall the single add-in and see if you get the same results.

@dfoll can you verify

this was user error, i did not have 3d analyst licensed


[CI] CI Functionality Check for v1.6.x Branch

Description
As title. Check the CI functionality for #17959.

@mxnet-bot run ci [unix-gpu]

Close this as #17959 was merged into v1.6.x branch.


Handle keypad digit presses

Keypad numbers are named "NumPad0" - "NumPad9" instead of "D0" - "D9"

Attempt to fix the AV-on-exit caused by failure to detach the keyboard hook.


feat(vm): implement improved error handling

Summary of changes
Changes introduced in this pull request:

Introduce an ActorError and use rust error handling when doing VM invocations.

I just realized, we can get rid of the manual runtime.abort and call that outside when an error is encountered.

I just realized, we can get rid of the manual runtime.abort and call that outside when an error is encountered.

The reason errors aren't handled here is for one to future proof for when there can be custom execution not to allow a state transition to crash the node. The plan was to have the vm execution wrapped in a catch_unwind so that no matter what inputs or code is executed, the state transition cannot crash the node.
Let me know if you think this assumption is bad or that this should and can be handled without catching the panic and handling aborts that way through the runtime.

Yeah, we shouldn't panic and catch it when it unwinds... That's not.. natural lol

thought it had approved this and posted that comment already, guess i misclicked... classic

Yeah, we shouldn't panic and catch it when it unwinds... That's not.. natural lol

Yeah the point is this is supposed to be a VM that is future proofed to run custom code, seems weird to handle errors in specific scenarios, force any code in future to handle errors, and allow the execution to crash the program potentially. I agree this is better for now, but I don't see the big aversion to this or why you didn't say something before

Regarding catching panics, I would say that all errors that are expected should be handled using regular rust error handling, but that the actual call to apply the message likely should be wrapped into a panic catcher, to ensure that if there is some unexpected behaviour or simply bugs in the implmentation here, they are caught and do not crash the node. This is last measure of defense, and should not be used as the default way of handling errors.

Regarding catching panics, I would say that all errors that are expected should be handled using regular rust error handling, but that the actual call to apply the message likely should be wrapped into a panic catcher, to ensure that if there is some unexpected behaviour or simply bugs in the implmentation here, they are caught and do not crash the node. This is last measure of defense, and should not be used as the default way of handling errors.

I agree, but the idea of when custom code is allowed, it isn't written in the spec to use an error type that is serialized consistently for use in multiple language clients, also because the go version handles it with panic. But in any case we agree now this is the best way to handle it, thanks again for the contribution :)

but the idea of when custom code is allowed,

I expect that when we go to that level this will have to be redone from scratch anyway.


Linux kernel updates 2024-11-08

Draft until all tests are done.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This has the io_uring stall fix, so we want to fast-track this.

Fixes #353709