Modules: replace root in dagger.json with source

Currently, by default the engine loads the directory tree at a module's dagger.json and nothing else. However, to support cases where there are files/dirs the module relies on that are outside that directory tree (i.e. a go.mod, package.json, another dependency module that exists relative to the module, etc.) there exists a root field in dagger.json that allows you to specify a parent directory that the engine will load instead.
This technically works but is inherently very confusing, both in behavior and terminology.
We discussed a better approach in this discord thread: https://discord.com/channels/707636530424053791/1182712578154180648
Full details are TBD as part of this issue, but the gist of the idea is to "invert control" such that rather than having a dagger.json that can point to parent dirs to load, dagger.json has the ability to point to module source that is present in child dirs.

There's a many variations on this general idea possible.
For the sake of having a concrete example, here's one possibility. The directory tree in a monorepo containing two go sdk modules that share a go.mod at the root of the repo would look like:
├── dagger.json
├── go.mod
├── go.sum
├── other-subdir
│   └── depmod
└── subdir
    └── mymod

In this case, the module at subdir/mymod is a module that depends on the module at other-subdir/depmod.
The contents of dagger.json would look something like this:
[
  {
    "name": "mymod",
    "source": "./subdir/mymod",
    "sdk": "go",
    "dependencies": ["./other-subdir/depmod"]
  },
  {
    "name": "depmod",
    "source": "./other-subdir/depmod",
    "sdk": "go",
    "dependencies": []
  },
]

This would be a slightly altered format of dagger.json that allows multiple modules to be specified rather than only one (hence the list of objects on the top level).
The resulting behavior would be that if you ran dagger call (or other module-aware cli commands) in the ./subdir/mymod directory then we'd find the parent dagger.json (or error out if one wasn't found in the current git repo) and use that to know where the source of that mymod module is and also where the source of the depmod module is.
That can all be used to load the module as efficiently as possible (where it's from a local checkout or purely from git), as described in this and subsequent comments on a related issue.
Support for exclude/include on each module should also fit in pretty well with this sort of approach.

@sipsma continuing the discussion thread we started on #6386 and f2f:

I like your proposal and think we should do it. I am excited for this increased flexibility in configuring my Dagger modules :)
At this time I don't have specific changes to suggest
However I do have a few questions
My goal is to remove myself as blocker as quickly as possible

Question 1: how do we keep it simple?
I love the simplicity of this formula: module = directory + dagger.json. I worry about losing it. It also has cool corollaries, like "my sub-modules = my sub-directories with dagger.json".
We don't have to keep the formula, necessarily. But we must keep the simplicity. What new formula would come with your proposed design, and is it simple enough? It now, can we make it simpler?
Question 2: how does introspection work?
Modules often call host().directory() for introspection. Usually it's to load data packaged with the module source.

In your design, what does host().directory() map to? The module's source directory, or the directory holding its dagger.json?
Should I always use one directory or the other for introspection? Or does it depend on the use case? What is the rule?
While we're at it, can we deprecate host().directory() for this purpose, and encode the answers above into an API?

Question 3: can I use dagger.json to configure my home directory?
The title says it all :) I have a dream of configuring Dagger in my home directory, to unlock various goodies. See #6323. Will the dagger.json from your design also be used to configure my home directory? Or do we prefer to design a different format for a different config file at the home directory?
Random idea
Below are new ideas coming to me as I write this. Disclaimer, I may change my mind at any time :)
Maybe that's the answer? If dagger.json becomes a complete engine configuration, instead of module configuration, then perhaps that answers my other questions? The formula would become: configuration = dagger.json, context = directory + configuration.
My home directory could have a dagger.json, making it a context directory for running the engine. My configuration would determine what the engine can see and do in that context: what modules to load; from where; with what default arguments 😇 ; etc.
In this scenario, an individual module would typically not have its own dagger.json: rather it would be commonly found at the root of the repo. For example my github.com/shykes/daggerverse would have a dagger.json at its root, listing all my modules. If a module is not listed in that file, it does not exist in the daggerverse, and loading it should fail (even if there is a subdirectory at that name). This goes beyond what your current PR does, I think, by removing the role of the filesystem completely as module addressing. In the end I don't care so much about the module tree living in the filesystem, or in JSON - I just don't want it to straddle both. That's key to the simplicity, I think.
Impact on sub-modules
If modules don't have their own config file, but are configured by a parent configuration, then the tree of sub-modules is centralized in the engine config, instead of being decentralized in each module's directory.
Impact on dependencies
This would impact where the dependency tree lives. A module's dependencies would live in the module's entry in the parent configuration.
Hopefully this section makes sense at least partially :) Thanks for reading this far.

@shykes

I love the simplicity of this formula: module = directory + dagger.json. I worry about losing it. It also has cool corollaries, like "my sub-modules = my sub-directories with dagger.json".

This is only true today (i.e. before the PR) if you aren't using root.
If you are using root then the formula is more like module = directory + dagger.json + some parent directory. And my sub-modules = sub-directories of the directory pointed to by root that contain their own dagger.json
This is just worth noting because the intention around all this is to simplify that case by replacing root with source, but while also leaving the very simple default case where root isn't being used today alone and as simple as it was before.

We don't have to keep the formula, necessarily. But we must keep the simplicity. What new formula would come with your proposed design, and is it simple enough? It now, can we make it simpler?

I'd actually say that the formula is just module = directory tree containing dagger.json + subpath.
To explain, it might actually help to make a comparison with how golang modules work.
Say you in your go code import a package like github.com/dagger/dagger/some/pkg:

The go.mod for that package may be in some/pkg or any of the parent directories, up to the root of the repo.

The go tooling handles doing the "findup" for you though, you just specify the git repo + subpath

So essentially the formula there is go module = directory tree containing go.mod + subpath

Our behavior is essentially the same, just replace go.mod with dagger.json.
e.g. if you run dagger functions -m github.com/shykes/daggerverse/mymod, then:

The dagger.json for that module may be in mymod or any of the parent directories, up to the root of the repo.

The dagger tooling handles doing the "findup" for you though, you just specify the git repo + subpath in your module ref

In your design, what does host().directory() map to? The module's source directory, or the directory holding its dagger.json?

The workdir of a module starts at the module's source directory; this is unchanged from the previous behavior.
The directory up to dagger.json is available too, just at parent paths (also same behavior as before, except it was instead "the directory up to where root pointed to).
There's been discussion about this a few times and while it's not 100% clear cut, each time so far we've come to the conclusion that it's probably better to have the workdir set to the source code directory since it allows you to reference paths in your module's source code that are actually relative to the source code file you are authoring.

e.g. in your module source code if you wrote host().directory("./some/path") then ./some/path is relative to the file you are actually authoring, no mental path arithmetic needed.

This is similar to other tools like go test that have the same behavior of making the workdir of code being executed set to the dir containing the source file (cc @vito who made that very nice comparison).

Should I always use one directory or the other for introspection? Or does it depend on the use case? What is the rule?

If I understand the question, it just depends on the layout of your repo and where the files you want to load are located. That is more of a factor of the user's particular use case and the existing structure of their monorepo. The main thing is that you can reference those paths relative to the module's source code file (as described above).

While we're at it, can we deprecate host().directory() for this purpose, and encode the answers above into an API?

It's certainly possible, but we'd end up essentially just renaming the API, with the behavior otherwise being the same.
I.e. assuming we rename Host->Local, then calls that introspect would look like:
dag.Local().File("../dir/somefile.txt")
// or
dag.Local().Directory("./some/subdir")

Those look pretty reasonable to me, so I'm not sure if we get much out of changing the API names more than that.

can I use dagger.json to configure my home directory?

I have been imagining that dagger.json is reserved for "static author-specified" configuration, and that support for "runtime caller-specified" configuration would just be a different file+mechanism.
I see the appeal of unifying the two if feasible, trying to imagine how the details would work out though.
If you have a dagger.json in your home directory with some module named foo specified and pointing to github.com/org/daggerverse/foo, then would you run:

dagger call -m foo (with configuration to your call in ~/dagger.json applied) ?
dagger call -m github.com/org/daggerverse/foo (with configuration to your call in ~/dagger.json applied)?

What happens if you there's configuration in both a ~/dagger.json and the dagger.json in the root of a git repo for a module you execute? Are both applied? Overlayed? Etc.
I don't have a fully formed opinion yet here, just asking more questions to clarify what you were imagining for now.

I love the simplicity of this formula: module = directory + dagger.json [...]

This is only true today (i.e. before the PR) if you aren't using root [...]

Yes, you're right.

To explain, it might actually help to make a comparison with how golang modules work [...]
Our behavior is essentially the same, just replace go.mod with dagger.json.

The dagger tooling handles doing the "findup" for you [...]

Yes, I do like the "auto-findup" behavior, I agree we should do that.
There is one notable difference though: Go has both module and package, but Dagger only has module, which sort of combines both concepts.

The workdir of a module starts at the module's source directory; this is unchanged from the previous behavior.
The directory up to dagger.json is available too, just at parent paths (also same behavior as before, except it was instead "the directory up to where root pointed to).
There's been discussion about this a few times and while it's not 100% clear cut, each time so far we've come to the conclusion that it's probably better to have the workdir set to the source code directory since it allows you to reference paths in your module's source code that are actually relative to the source code file you are authoring.

Granted I was in a noisy cafe last time I heard this discussed, and couldn't properly share my thoughts, but for the record I still strongly believe this should be changed before launch.

e.g. in your module source code if you wrote host().directory("./some/path") then ./some/path is relative to the file you are actually authoring, no mental path arithmetic needed.

I propose module().source().directory("./some/path") which 1) doesn't require mental path arithmetic either, and 2) makes it clear and explicit what you are getting: the module's source directory.

This is similar to other tools like go test that have the same behavior of making the workdir of code being executed set to the dir containing the source file (cc @vito who made that very nice comparison).

I understand the appeal (make also comes to mind, its workdir is set to the directory containing the Makefile). But I think our situation is different than go test and make in one important way: a Dagger module has both a source directory and context directory, and the module may need to introspect both.

it just depends on the layout of your repo and where the files you want to load are located. That is more of a factor of the user's particular use case and the existing structure of their monorepo. The main thing is that you can reference those paths relative to the module's source code file (as described above).

I think that  can be distilled into these two rules:

To access your module source, for example to read a template or script used by your code, open host().directory(".")
To access your module "context" (the directory containing dagger.json), open host().directory(REVERSE_MODULE_PATH), where REVERSE_MODULE_PATH is something like ../../..: the path from the module source up to the enclosing dagger.json.

A few problems with this:

What the module can access, and at what relative path, depends on where its source code lives in the enclosing context dir. That feels brittle and opaque to me. It's a very common feature of artisanal build scripts, and I can't say I miss it.
The module source and its context directory may not always be authored by the same people (eg. team-specific modules in a multi-team monorepo). This amplifies the brittleness of accessing context directory by relative path to source.
If context and source directories are different, it's not intuitive that host().directory(".") would point to one vs. the other. For example if my app repo has a dagger.json configuring a module at ./ci, it would be equally reasonable IMO, to expect host().directory(".") to return the either the repo root, or ./ci.
host().directory(".") now mean very different things inside and outside a Dagger function; which adds a pebble in the shoe of devs porting their custom client to functions.

While we're at it, can we deprecate host().directory() for this purpose, and encode the answers above into an API?

It's certainly possible, but we'd end up essentially just renaming the API, with the behavior otherwise being the same.

To clarify, I am not talking about deprecating host.directory() (poor choice of words on my part). I'm talking about not using it for the purpose of introspecting module source code. Whether we deprecate or rename that particular host API call, is orthogonal.

can I use dagger.json to configure my home directory?

I have been imagining that dagger.json is reserved for "static author-specified" configuration, and that support for "runtime caller-specified" configuration would just be a different file+mechanism.

That was my assumption also, but this thread is pulling me in a different direction at the moment 😁

I see the appeal of unifying the two if feasible, trying to imagine how the details would work out though.
If you have a dagger.json in your home directory with some module named foo specified and pointing to github.com/org/daggerverse/foo, then would you run:

dagger call -m foo (with configuration to your call in ~/dagger.json applied) ?
dagger call -m github.com/org/daggerverse/foo (with configuration to your call in ~/dagger.json applied)?

I think both would work.

I love that this would enable configurable short names, that would be very convenient.
In both cases, both ~/dagger.json and github.com/org/daggerverse/dagger.json would be applied, per the usual find-up system.

What happens if you there's configuration in both a ~/dagger.json and the dagger.json in the root of a git repo for a module you execute? Are both applied? Overlayed? Etc.

I think they would be overlayed, to allow 1) publishers to configure their modules, and 2) consumers to override them locally.

I don't have a fully formed opinion yet here, just asking more questions to clarify what you were imagining for now.

And it's very appreciated :)

(just getting back on one point to start)

I propose module().source().directory("./some/path") which 1) doesn't require mental path arithmetic either, and 2) makes it clear and explicit what you are getting: the module's source directory.

Working through what this (and the related suggestions) would look like concretely so I can be 100% sure we're on the same page (please bear with the pedantic minutia):
├── .git/
└── subdir
    ├── dagger.json
    ├── go.mod
    ├── go.sum
    └── otherdir
        └── foo.txt
    └── mymod
        └── main.go
        └── modsubdir
            └── bar.txt

In that case the "context dir" is subdir and the "source dir" is subdir/mymod (relative to the context dir, it is ./mymod).
When the module executes, the container it runs in mounts the context dir to /mnt (noting so I can be maximally concrete below).

(technically the dir we use today is /src, but avoiding that because the name is confusing in this discussion and the name doesn't fundamentally matter, could be /fjfkdla for all we care.)

So in the container it would look like:
/
└── mnt
    ├── dagger.json
    ├── go.mod
    ├── go.sum
    └── otherdir
        └── foo.txt
    └── mymod
        └── main.go
        └── modsubdir
            └── bar.txt

In what you're proposing (iiuc), the process's cwd (i.e. ".") would be the context dir, so absolute path /mnt. And the module source directory would be available at ./mymod.
Thus dag.Host() would have the following behavior

Context directory:

dag.Host().Directory(".")

Source directory

dag.Host().Directory("./mymod")

foo.txt

dag.Host().File("./otherdir/foo.txt")

bar.txt

dag.Host().File("./mymod/modsubdir/bar.txt")

You're additionally suggesting that there would also be a dag.Module().Source() API, such that:

Context directory:

N/A

Source directory

dag.Module().Source().Directory(".")

foo.txt

N/A

bar.txt

dag.Module().Source().File("./modsubdir/bar.txt")

Is this accurate in terms of your suggestion?

If so, my main hesitation is that it just feels asymmetric that for the context dir you use dag.Host and the source dir you use dag.Module().Source.
What would you think about these tweaks:

dag.CurrentModule().Context().Directory(".") - refer to the context directory
dag.CurrentModule().Source().Directory(".") - refer to the source directory

(I switched to CurrentModule because that's an api that already exists for a module to refer to itself).
In this scenario, .Context() and .Source() would refer to the "frozen" snapshot of the respective dirs as they were loaded into the engine.
Given the above, I'd also be okay with the module process's current working directory changing to be the context directory since it becomes less relevant.
The last wrinkle in all of this is the question around whether dag.Host().Directory even needs to exist at all anymore if we go with the above.
The technical difference is that dag.Host().Directory by its nature refers not to the frozen snapshot but to the actual live filesystem in the container, including any changes that may have been made to it during module function execution.
On one hand, it's extremely appealing to just disregard this and say that a module can never refer to files created during execution. That would actually allow us to potentially just remove dag.Host() from the API presented to modules entirely and solve a bunch of problems at once.
The counter-argument is that there are pretty compelling use cases for being able to create/modify files in function code directly and then use them in the dagger API.

Instead, you can just import the library and use it directly in the function. And now that functionality is magically available to any dagger CLI user or dagger module author in any other language.

So my preference would be that:

dag.CurrentModule().Context() and dag.CurrentModule().Source() are the "goto" simple APIs typically needed for any of these use cases.
dag.Host().Directory() is still available, but only needed in more advanced cases where function really wants to refer to live changes made in the container
The process's current working directory can just be the context dir (though I am not strongly opinionated on this in particular, it becomes more arbitrary to me now, could even just be some scratch dir)

I'd also not strongly object if others have a preference for ignoring the dag.Host().Directory use-case in the short term since this is one thing we can backwards-compatibly add in the future.
I'll stop ranting here to checkpoint, let me know what you think.

RE: consolidating runtime+author configuration into dagger.json
Know you have some more ideas here we're gonna sync up on, just working through the idea in detail myself ahead of time.

(I'm gonna be adding details here for the sake of getting the point across, not fully coherent)
Say there's a module at github.com/org/daggerverse/hugo that has functions for building static hugo-based websites based on a caller-provided directory of the website's source code.
The layout of the github.com/org/daggerverse is:
├── assets
│   └── sample-site
├── dagger.json
└── hugo
    └── main.go

Sketch of that module's code at ./hugo/main.go:
package main

func New(
	// the source code of the website to build with hugo
	// +optional
	websiteSource *Directory,
	// some api key we need for some reason
	apiKey *Secret,
) Hugo {
	if websiteSource == nil {
		websiteSource = dag.CurrentModule().Context().Directory("./assets/sample-site")
	}
	return Hugo{
		WebsiteSource: websiteSource,
		APIKey:        apiKey,
	}
}

type Hugo struct {
	WebsiteSource *Directory
	APIKey        *Secret
}

// the directory containing the built site assets
func (m *Hugo) Built() *Directory {
	// do things with m.WebsiteSource ...
}

// the directory containing the built site assets
func (m *Hugo) Container() *Container {
	// put Built into a container with a webserver or whatever
}

// etc.

dagger.json has contents:
{
  "modules": [
    {
      "name": "hugo",
      "sdk": "go",
      "source": "./hugo"
    }
  ]
}

Now let's say that I'm a caller of that module. On my local machine ~/dagger.json has contents:
{
  "modules": [
    {
      "name": "hugo",
      "source": "github.com/org/daggerverse/hugo",
      "defaultArgs": {
        "website-source": "/home/me/my-cool-site",
        "api-key": "file:/home/me/.hugo-api-key"
      }
    }
  ]
}

Now I can run things like this for example:

dagger call -m hugo -o /tmp/site built

get the built site assets locally at /tmp/site

dagger call -m hugo container publish docker.io/me/my-site

build the site into a container and publish it to that registry

dagger call -m hugo container up

serve the website on my localhost

The behavior is such that:

I specified -m hugo and am not locally in a module subdirectory, so the CLI defaults to ~/dagger.json and finds a module named hugo, uses the source there, etc.
The defaultArgs key in dagger.json applies to module constructors
defaultArgs has the same semantics as the CLI in terms of conveniences like providing args of type Directory as a local path, secrets as file:..., etc.

I also like that this could probably give us a path to:

Support default values read from env vars for any string

Though we'd need to be sure that they don't allow remote modules to magically get access to caller env vars, if defaultArgs is set in the dagger.json of a module in a git module.
Also not entirely sure what the syntax would be here, but can save this for a separate thread, point is maybe there's a path now.

Configuring SDKs w/ config settings like GOPROXY, various secrets that might be needed, etc. which comes up from enterprise use-cases all the time.

Overall I really like many aspects of this, a few places of minor concern/questions:
defaultArgs on module dagger.json configs
I purposely left out defaultArgs from the dagger.json of hugo in the github.com/org/daggerverse repo.
The reason is that modules already have a way of specifying/handling default arg values in the code itself. While it certainly could be logically coherent to have defaultArgs in the dagger.json of the hugo module, I don't love that it would mean there's now multiple different ways for a module to define defaults.

Not a dealbreaker at all, but all else being equal it's always nice when there's only one way to do things.

If we did support defaultArgs on the dagger.json of modules like hugo, then we'd also need to decide how to handle default values of secrets without compromising security (either don't allow it or go full blown trust model).

I highly suspect we could deal with those in an intuitive way for 99.9% of cases, just something we'll need to be careful about.
And actually now that I type this out loud, those ambiguities exist to an extent in the also dumb corner case of github.com/org/repo/module referring to a git repo or a local dir that happens to be named that. So not actually a new problem overall.

So my preference would be that:

dag.CurrentModule().Context() and dag.CurrentModule().Source() are the "goto" simple APIs typically needed for any of these use cases.
dag.Host().Directory() is still available, but only needed in more advanced cases where function really wants to refer to live changes made in the container

That looks golden to me! 👍
Even though you can get source from a subdir of context, you don’t have to rely on a relative path that can change. However, some times you do need to have that information, many times statically (e.g., in a go.mod), but I’d like to have a way for the API to tell me the relative path between them. Could be just .Source().Path(ctx) (or .Source().Directory().Name(ctx)).

The process's current working directory can just be the context dir (though I am not strongly opinionated on this in particular, it becomes more arbitrary to me now, could even just be some scratch dir)

I prefer it to be the context dir, thinking of the times I’d want to use dag.Host() instead of the other ones. It also makes you rely more on .CurrentModule.Source() when that’s what you need.

I'd also not strongly object if others have a preference for ignoring the dag.Host().Directory use-case in the short term since this is one thing we can backwards-compatibly add in the future.

Rather than deprecating it only on modules, I say leave it to documentation. It may ease transition too, especially if the context is the workdir (assuming lots of usage for calling on a subdir like dagger run go run ./ci/main.go).
The worry is that people will leave that part instead of changing, but if the docs overwhelmingly show using CurrentModule().Context(), CurrentModule().Source() and Directory as an arg, I’m hopeful that it’ll catch on.
Of course there’s the renaming to .Local() idea that deprecates .Host() (still allowing smoother transition), but letting the user know this should be changed, so now you make a choice.

I also like that this could probably give us a path to:

Support default values read from env vars for any string

Though we'd need to be sure that they don't allow remote modules to magically get access to caller env vars, if defaultArgs is set in the dagger.json of a module in a git module.
Also not entirely sure what the syntax would be here, but can save this for a separate thread, point is maybe there's a path now.

Configuring SDKs w/ config settings like GOPROXY, various secrets that might be needed, etc. which comes up from enterprise use-cases all the time.

🙌
Can also be used for global excludes, since everyone uses different tools that leave all sorts of files around.
The global config file could also be used for engine wide configs, like passing on proxy env vars to the engine itself. They could be two different files though.
Can be managed with dagger config. There’s lots of tools that do this. Git comes to mind (global and local configs). Hatch, which is the project manager we use on the Python SDK, also has this kind of project specific defaults in the global configuration.

defaultArgs on module dagger.json configs
I purposely left out defaultArgs from the dagger.json of hugo in the github.com/org/daggerverse repo.

Yeah, whenever I talk about a config file to make the CLI calls simpler, it’s always a runtime thing, not authoring.
However, for project specific configs I usually think about a file placed where the user most likely makes the dagger calls from (the “app", not the module), that can be committed to git for sharing, and it includes all args and flags (using viper for this). But both can work, so the CLI can use global defaults (e.g., excludes, secrets, env vars to pass to the runtime container), project specific defaults in git (e.g., default args) and still be able to override with CLI args (again, viper makes this easy, including accessing nested keys matching the call chain).

We discussed this live with @sipsma today, and made some good progress. Here is a summary below:

dag.Host().Directory(".") should stay, but map to a scratch directory.
[Follow-up note]: maybe we sandbox this to only the scratch directory, ie. / and . would both return the scratch. This avoids leaking internal details about the runtime container, which feels "dirty" to me. From there, maybe it becomes dag.Workdir().Directory(")", just saying :)
dag.CurrentModule().Source().Directory("."): works great. SH note: I want to bikeshed the exact API here, to make it shorter :) But that can wait
dag.CurrentModule().Context(): not a thing, we cut it. Rationale: there is no clear use case for a module author to introspect that directory. And it opens a backdoor to a "shadow API", if the module is loaded from a monorepo that also contains app source code, and the module relies on that as a default value, for example. No strong benefit + clear strong downsides = cut it.
However SDKs do need to receive the context directory where a module was configured, and the path of the source directory within that. That way, the Go SDK can honor shared go.mod, etc. This is done as proposed by Erik, using a source field etc. But only exposed to SDKs, not to functions for introspection (see previous point)
We discussed the idea of "codeless modules": what if you could dagger install modules without having to write code? This would add pinned dependencies in dagger.json the usual way, but the sdk and source fields would not be set. dagger call would support looking up dependencies by short name. So dagger install github.com/shykes/daggerverse/tailscale would install a pinned version of that module to the current dagger.json (which could be in my home directory or app repo), then dagger call -m tailscale would call the exact pinned version I installed. Later, if I want to add code to my module, I add the sdk field (command TBD here), and my same dependencies are codegened the usual way. This makes for a smoother learning curve.
In this scenario, I worry that having dependencies + modules creates confusion: there are sub-modules, and there are dependencies, they are similar but different. But maybe I am overthinking it - we ran out of time and couldn't resolve that. It feels like we're really close though
I also pitched an alternative to default args for fixing the "end-user convenience" problem. One design for solving auth convenience; and another for solving "implicit workdir access". I will write this down elsewhere :)

@sipsma let me know if I missed anything

Yeah I'm very happy with where we landed in terms of Context dir not being a thing except to SDKs, considering that whole side of things to be closed 🙂

We discussed the idea of "codeless modules": what if you could dagger install modules without having to write code? This would add pinned dependencies in dagger.json the usual way, but the sdk and source fields would not be set. dagger call would support looking up dependencies by short name. So dagger install github.com/shykes/daggerverse/tailscale would install a pinned version of that module to the current dagger.json (which could be in my home directory or app repo), then dagger call -m tailscale would call the exact pinned version I installed. Later, if I want to add code to my module, I add the sdk field (command TBD here), and my same dependencies are codegened the usual way. This makes for a smoother learning curve.
In this scenario, I worry that having dependencies + modules creates confusion: there are sub-modules, and there are dependencies, they are similar but different. But maybe I am overthinking it - we ran out of time and couldn't resolve that. It feels like we're really close though

Been wracking my brain over this for a while trying to get the pieces to fit together... trying out something:
User runs dagger mod init (no args). A dagger.json is created that is empty, i.e. {}.
User runs dagger mod install<EMAIL_ADDRESS>dagger.json is updated to:
{
  "dependencies": [
    {
       "name": "tailscale",
       "source"<EMAIL_ADDRESS>    }
  ]
}

User can now run dagger call -m tailscale ....
User now wants to write module code using the current dependencies in the dagger.json. They run dagger mod update --name mymod --sdk go, dagger.json now looks like:
{
  "name": "mymod",
  "sdk": "go",
  "source": ".",
  "dependencies": [
    {
       "name": "tailscale",
       "source"<EMAIL_ADDRESS>    }
  ]
}

And the module source code (i.e. main.go and codegen) is placed in the same dir as the dagger.json.
Now you can do dagger call -m mymod ... to call your own functions. dagger call -m tailscale ... still works too though.
Now to get to a more complicated but totally valid use case, say you want to add another local module that's in a subdir and used by mymod.

E.g. maybe in this context you are in a local git repo checkout that you intend to push and need multiple modules in it.
Or e.g. maybe this dagger.json is in your home dir but you want to add a new module just on your machine and use it, etc.

This would be done via dagger mod init -m ./some/subdir --sdk go --name othermod. dagger.json is updated to look like:
{
  "name": "mymod",
  "sdk": "go",
  "source": ".",
  "dependencies": [
    {
       "name": "tailscale",
       "source"<EMAIL_ADDRESS>    },
    {
       "name": "othermod",
       "sdk": go",
       "source": "./some/subdir"
    }
  ]
}

Now say othermod needs some other dependency, you could run dagger mod install -m othermod<EMAIL_ADDRESS>-m othermod indicates you are adding a dep specifically to othermod. dagger.json now looks like:
{
  "name": "mymod",
  "sdk": "go",
  "source": ".",
  "dependencies": [
    {
       "name": "tailscale",
       "source"<EMAIL_ADDRESS>    },
    {
       "name": "othermod",
       "sdk": go",
       "source": "./some/subdir",
       "dependencies": [
         {
            "name": "hugo",
            "source"<EMAIL_ADDRESS>         }
       ]
    }
  ]
}

Basically, the idea is that dependencies is the same struct "all the way down", if that makes any sense.
The important property that's retained with this sort of approach is that each module can have its own list of dependencies. In the "monorepo of many modules" use case, I think this is important. You don't necessarily want each module to have the same set of dependencies just because they are in the same dagger.json. They might not need the same deps or may even need some overlapping set of deps but at different versions.
There are warts remaining in this, namely:

It's not clear that it would be possible to dagger call -m hugo .... Basically, dagger call -m would be limited to "top-level" modules in the dagger.json (i.e. mymod, tailscale and othermod in the example above)

I honestly think this is probably okay, we're reaching the point of obscurity here. If we really really wanted to figure out a syntax to support this, it's probably possible though, just dubious in terms of benefits.

We want some sort of recursion limit on how deep nested dependencies could go. I can imagine how it would be implemented to arbitrary depth, but it would allow our users to get into situations that are so confusing it might be safer to just stop it early.

Here's one alternative that I'm considering that trades the "recursive dependencies key" for separate dagger.json files.
The idea is that you'd have local modules like othermod always get their own dagger.json separate from the "parent" one, with the parent one just pointing to the child one and relying on "find-up" behavior from there.
So in that case, the "top-level" dagger.json would look like:
{
  "name": "mymod",
  "sdk": "go",
  "source": ".",
  "dependencies": [
    {
       "name": "tailscale",
       "source"<EMAIL_ADDRESS>    },
    {
       "name": "othermod",
       "source": "./some/subdir"
    }
  ]
}

And there would also be a dagger.json in ./some/subdir that looks like:
{
  "name": "othermod",
  "sdk": "go",
  "source": ".",
  "dependencies": [
     {
        "name": "hugo",
        "source"<EMAIL_ADDRESS>     }
   ]
}

The CLI+engine would handle all the complication around the "find-up" behavior, so I believe it could be hidden from users for the most part, but the tradeoff being more dagger.jsons.
Honestly, now that I type this out, I might like this one a little bit better surprisingly? It feels a little more cohesive. The recursive dependencies is kind of a scary wart in the other approach, though the extent to which it actually complicates things in practice is not entirely clear to me yet.
I'll pause here though for a checkpoint.

Honestly, now that I type this out, I might like this one a little bit better surprisingly? It feels a little more cohesive. The recursive dependencies is kind of a scary wart in the other approach, though the extent to which it actually complicates things in practice is not entirely clear to me yet.

Yes I agree.

EDIT: I just remembered that this greatly complicates the case where the module in a subdir has deps on other modules in the repo... 🤦♂ Essentially brings us back to root or close equivalents. So maybe not....

:( Can you elaborate on how it complicates it?

Throwing this at the wall: an example of a repo with many modules, that need to share the same go.mod for policy reasons.
{
 "dependencies": [
  {
    "source": "./go"
    "context": "."
  },
  {
   "source": "./tailscale",
   "context": "."
  },
 ]
}

The point is that the parent can specify an optional context directory to be passed to each dependency's SDK, in the manner that we already discussed. This way, no path ever needs to include ... And, we no longer need a distinct modules key: everything can be under dependencies, and every module can have its own dagger.json without breaking the model.

:( Can you elaborate on how it complicates it?

I'll run through concrete examples again to try to explain (and maybe see if there's a way to make it work):
Use case here is say you are daggerizing an existing monorepo and will be adding multiple modules to it and those modules have deps
User runs dagger mod init (no args) in the root of a repo (as checked out to their local machine). A dagger.json is created that is empty, i.e. {}.
User runs dagger mod init -m ./somedir/modA --name=mod-a --sdk=go.
The top-level dagger.json is updated to be:
{
  "dependencies": [
    {
       "name": "mod-a",
       "source": "./somedir/modA"
    }
  ]
}

And another dagger.json is created in ./somedir/modA with:
{
  "name": "mod-a",
  "sdk": "go",
  "source": "."
}

Now they do the same thing but for modB, so they run dagger mod init -m ./otherdir/modB --name=mod-b --sdk=python.
The top-level dagger.json is updated to be:
{
  "dependencies": [
    {
       "name": "mod-a",
       "source": "./somedir/modA"
    },
    {
       "name": "mod-b",
       "source": "./otherdir/modB"
    }
  ]
}

And another dagger.json is created in ./otherdir/modB with:
{
  "name": "mod-b",
  "sdk": "python",
  "source": "."
}

Now let's say that the user wants modA to depend on modB. The syntax could be dagger install -m modA modB (idea being that -m modA says you are operating on modA and you specifically are installing modB).
What caused me to hesitate is what the dagger.json updates would be. I specifically don't like the idea of ./somedir/modA/dagger.json now looking like:
{
  "name": "mod-a",
  "sdk": "go",
  "source": ".",
  "dependencies": [
     {
       "name": "mod-b",
       "source": "../../otherdir/modB"
     }
  ]
}

But... I suppose it's not quite as bad as root because the path arithmetic can be entirely hidden from the end user at least 🤷♂ It'd all be automated in the CLI and engine. And we can continue enforce that any paths never escape a .git root to avoid security problems of an e.g. maliciously crafted dagger.json.
And I suppose another option would be that ./somedir/modA/dagger.json could be unchanged, and instead dagger.json in the root of the repo is instead updates like this:
{
  "dependencies": [
    {
       "name": "mod-a",
       "source": "./somedir/modA",
       "dependencies": [
         {
           "name": "mod-b",
           "source": "./otherdir/modB"
         }
       ]
    },
    {
       "name": "mod-b",
       "source": "./otherdir/modB"
    }
  ]
}

That would avoid a need for any paths to ever have ../ elements.
The implementation and behavior of that approach in particular is a bit hard to fully piece together though. My instinct would be that in order to fully determine the configuration of a given module, you need to "find-up" not just once but through multiple dagger.jsons.
That's not awful, though there would still be corner cases, like what if I had dagger.json in my home directory and the local checkout of the repo happened to be a subdir of my homedir? I want dagger install -m modA modB to specifically update the dagger.json of the git repo checkout root, not my homedir (at least in this case).

Maybe we could just enforce the rule that we stop the find-up at a .git dir
Or you could have an explicit flag for which config dir to stop at, e.g. dagger install --config-dir . -m modA modB

Discussed more with @shykes, landed here (gonna use the same example as my last comment to save time):
Use case here is say you are daggerizing an existing monorepo and will be adding multiple modules to it and those modules have deps
User runs dagger mod init (no args) in the root of a repo (as checked out to their local machine). A dagger.json is created that is empty, i.e. {}.
User runs dagger mod init -m ./somedir/modA --name=mod-a --sdk=go.
The top-level dagger.json is updated to be:
{
  "root-for": ["./somedir/modA"]
}

And another dagger.json is created in ./somedir/modA with:
{
  "name": "mod-a",
  "sdk": "go",
  "source": "."
}

Now they do the same thing but for modB, so they run dagger mod init -m ./otherdir/modB --name=mod-b --sdk=python.
The top-level dagger.json is updated to be:
{
  "root-for": ["./somedir/modA", "./otherdir/modB"]
}

And another dagger.json is created in ./otherdir/modB with:
{
  "name": "mod-b",
  "sdk": "python",
  "source": "."
}

Now the user runs dagger install -m modA modB. Top-level dagger.json is unchanged. ./somedir/modA/dagger.json is updated to:
{
  "name": "mod-a",
  "sdk": "go",
  "source": ".",
  "dependencies": [
     {
       "name": "mod-b",
       "source": "../../otherdir/modB"
     }
  ]
}

Find-up logic in the engine is implemented such that the context dir of a module is the dagger.json that contains the root-for key for the module (or, if there is no such dagger.json, then the context dir is implicitly just the module's source dir). It also handles making sure any .. paths don't escape the context dir.
For completeness, say you wanted the top-level module to be an actual sdk-full mod. You could do dagger mod config --sdk=go --name=top-level. Top-level dagger.json now looks like:
{
  "name": "top-level",
  "sdk": "go",
  "source": ".",
  "root-for": ["./somedir/modA", "./otherdir/modB"]
}

And then if you wanted to add a dep on one of the submodules, you'd run dagger mod install -m top-level ./somedir/modA and it would be updated to look like:
{
  "name": "top-level",
  "sdk": "go",
  "source": ".",
  "dependencies": [
     {
       "name": "mod-a",
       "source": "./somedir/modA"
     }
  ]
  "root-for": ["./somedir/modA", "./otherdir/modB"]
}

Thanks for the writeup! I really like this design.
Adding some polish bikeshedding as promised:

dagger init: Initialize a module
dagger install: Install a module
dagger doc: Print a module's API documentation
dagger call: Call one or more functions
dagger run: Run a script that can call functions
dagger develop [--sdk go|python|ts]: install or update an SDK
dagger serve: Run an http server that can call functions


Can't open pages that contain multiple words in their filename

Most PKM tools (e.g. Obsidian, Logseq, Foam) support files that contain multiple words and some special characters (e.g. " ", "-", "_").
Currently I am getting an error if I try to open a file that has space inside of its name. (e.g. "Digital Garden").
I would like to import my Obsidian vault and having to rename all my atomic notes to not have space in their file name is would something I would like to avoid.
Is there something I'm doing wrong?
Here are some screenshots to clarify the issue:

Sample library I would like to import and eventualy sync with Obsidian:

Thank you for posting this issue, I didn't pay attension to this for all my own notes' names are lowercase-with-hyphen.
I will try to fix this.

This is fixed in<EMAIL_ADDRESS>

Thank you ❤ I just pulled the latest changes and the work as expcted!


Using ManagedDatasource from CivModCore 1.5.0

This is a paired PR with CivModCore adddb PR.
Please review for any inaccuracies or missing changes.
Bungee, note, does not extend CivModCore and does not use the ManagedDatasource. Instead, I moved the generic "Database" handler that also uses HikariCP into Bungee-project and removed the dependency on Namelayer-Spigot from Namelayer-Bungee.
I also updated the plugin and bungee.yml's in this PR to have the release version instead of just 1.0.0.

@Maxopoly been polishing this as I had energy today. I'll review your PR tomorrow and see about integrating the two; easier though for folks to review this un-integrated.

Looks good overall, usage of the CivModCore stuff seems pretty straight forward. Nice job.

Address all reviews, including making properties.releaseVersion the only thing needing updating on new version increment.

ok to test

Any objection to my merging this in? I'll work on integrating it in to your PR @Maxopoly

No objections


Additional Section for Adding Roles, or Policies

This documentation was very helpful.  The page suggests that we have full access to configure Identity Server as we see fit.  In looking at the overloads for .AddIdentityServer and .AddApiAuthorization in the server project's Startup class, that does seem to be true; however, it would be helpful to provide another section where you demonstrate how to configure an app to support roles or policies -- to support [Authorize(Roles="...")], [Authorize(Policy="...")], <AuthorizeView Roles="...">, <AuthorizeView Policy="...">.  Also, it would be helpful to discuss (even at a high-level) how the pattern could be adapted to support a single Blazor WebAssembly app that uses multiple APIs with a single login and multiple Blazor WebAssembly applications that each use a common API.

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

ID: 17515ff7-32a6-c6f7-0425-535775cd6e28
Version Independent ID: 1416abd7-0b23-ca93-62e7-59d2532d4275
Content: Secure an ASP.NET Core Blazor WebAssembly hosted app with Identity Server
Content Source: aspnetcore/security/blazor/webassembly/hosted-with-identity-server.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @guardrex
Microsoft Alias: riande

Hello @denmitchell ... Thanks for the feedback. This was the one topic that I didn't get a chance to personally test here (the technical aspects were published directly from engineering), so I'm glad to hear that your experience was good.

another section where you demonstrate

Covered as overview-level concepts ...

For the [Authroize] attribute, we cross-link to the main doc set :point_right: https://docs.microsoft.com/aspnet/core/security/blazor/#authorization
For <AuthorizeView {Roles or Policy}="..."> :point_right: https://docs.microsoft.com/aspnet/core/security/blazor/#role-based-and-policy-based-authorization

discuss (even at a high-level) how the pattern could be adapted to support a single Blazor WebAssembly app that uses multiple APIs with a single login and multiple Blazor WebAssembly applications that each use a common API.

For that, we'll see if management is interested. They usually look at these on Fridays, so you should hear back on Friday, the 20th or the 27th.

If you are trying to use roles in the Auth API, see this (aka they don't work without some manual hack): https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles?view=aspnetcore-3.1

One way to make roles work is the following:

Add roles as claims. The traditional
await _userManager.AddToRoleAsync(user, roleName);
is not sufficient. One needs to use:
await _userManager.AddClaimAsync(user, new Claim(ClaimTypes.Role, roleName));
where 'roleName' is a string with the name of the role (e.g. "Administrator").

Implement the 'IProfileService' interface (See: http://docs.identityserver.io/en/latest/reference/profileservice.html). Specifically, in the 'GetProfileDataAsync' of the implementation, map the roles added as claims to Identity to the roles used in the generation of the JWT.

...
// Create a System.Security.Claims.ClaimsPrincipal for the user (get the user from UserManager as usual)
System.Security.Claims.ClaimsPrincipal claimsPrincipal = await
    _claimsPrincipalFactory.CreateAsync(user);

// Recover the existing claims
List<System.Security.Claims.Claim> claimList = claimsPrincipal.Claims.ToList();

// Recover user claims from Identity
var userClaimList = await _userManager.GetClaimsAsync(user);

// Map role claims in identity to role claims in the JWT
foreach (var claim in userClaimList)
{
    if (claim.Type == ClaimTypes.Role)
    {
        claimList.Add(new Claim(JwtClaimTypes.Role, claim.Value));
    }
    else
     {
         claimList.Add(claim);
     }
}

context.IssuedClaims = claimList;

In Startup.cs add roles to Identity, modify:

services.AddDefaultIdentity<ApplicationUser>(
    options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

to
services.AddDefaultIdentity<ApplicationUser>(
    options => options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Always in Startup.cs, add the IndentityProfuleService implementation to IdentityServer:

services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>()
    .AddProfileService<IdentityProfileService>();

This should work and checking the user's claims should list roles.

Related to https://github.com/dotnet/AspNetCore.Docs/issues/17649. Work these together.


chore: Use ubuntu-latest in CI

Had to pin it to 22.04 in #217, let's try to bump it back up now.

coverage: 94.925%. remained the same
when pulling f2b3423dd2636a03a48404c1ad0ea03efecfba78 on back-ubuntu-latest
into f407f364a8974ceb56d489998f242623b6b3d709 on master.


Tests: v1.12+ required for Ships with path.

Part of #1257 and #1243.
Can be happily merged even before v1.12 has been released, since we can start writing metadata for v1.12 now. :)

LGTM (I should've looked at this sooner, didn't realize it's essentially a copy+paste of the other if statements)

@plague006 I missed this one sorry! Indeed looks correct.


Pass variable from template.twig to base.twig to include.twig

I have a navigation that requires a different class depending on the template. I want to be able to set this in the template or page.twig and then pass it back down to and include.twig that is included in base.twig.
Can this be done?

Why don't you create the variable at add_to_context?  This way the variable is accessible in all twig files.

@marciojc i'm new to twig and php, could you show me an example please of how and where to do this?

@marciojc i've tried that way and it doesn't work, here is my setup
functions.php
function add_to_context( $context ) {
		$context['navColorClass'] = "c-navbar--light";

		return $context;
	}

base.twig
{% block html_head_container %}

{% include 'html-header.twig' %}
	{% block head %}
	{% endblock %}

{% endblock %}

    {% include 'navigation.twig' %}

        	    {% block content %}

        		{% endblock %}

                {% include 'footer.twig' %}

         {% include 'globaljs.twig' %}
        {% block javascript %}{% endblock %}
        {{ function('wp_footer') }}

navigation.twig

Insights.php which is custom page
<?php

/*
* Template Name: Insights
 * Description: List of article, ebooks, and quickviews
*/

$context['navColorClass'] = "sauce";
$context = Timber::get_context();
$context['post'] = new TimberPost();

$args = array(
    'paged' => 1,
    'post_status' => 'publish',
    'posts_per_page' => 11,
    'post_type' => array(
        'article',
        'ebook',
        'quickviews'
    ),
    'orderby' => 'date',
    'order' => 'DESC'
);

$totalargs = array(
    'post_status' => 'publish',
    'posts_per_page' => -1,
    'post_type' => array(
        'article',
        'ebook',
        'quickviews'
    ),
    'orderby' => 'date',
    'order' => 'DESC'
);

$context['articles'] = Timber::get_posts($args);
$context['total'] = Timber::get_posts($totalargs);

// get values from ACF options page
$context['options'] = get_fields('options');

Timber::render('insights.twig', $context);

?>

I want to be able to set navColorClass in insights.php and that update the value in the navigation.twig

Hi @adamwright32, since this is a support question I'd recommend posting your question to StackOverflow:
[https://stackoverflow.com/questions/tagged/timber(https://stackoverflow.com/questions/tagged/timber)
but Insights you are overwriting the context variable, change the order.
$context = Timber::get_context(); $context['navColorClass'] = "sauce";

@marciojc yes i am, i want to change the value in insights and want that value to show in navigation.twig

@adamwright32 if you want to change the value, change the order as my example.

Alright, let’s break this down. You have a function like this, where you add the navColorClass to the context:
function add_to_context( $context ) {
    $context['navColorClass'] = "c-navbar--light";

    return $context;
}

But you also need to use add_filter, so that the function will be called at the right time:
add_filter( 'timber/context', 'add_to_context' );

Be aware, that when you use this filter, you will set navColorClass for all your template files where you call Timber::get_context() before rendering it through a Twig file.
You say that you want to set navColorClass in insights.php only, so the timber/context filter might not be what you’re looking for.
You also tried it a different way, by setting navColorClass in insights.php. This doesn’t work because when you first do
$context['navColorClass'] = "sauce";

and then right after that you’ll do
$context = Timber::get_context();

then $context will always be the default context. Your value navColorclasswill be overwritten. Before you do anything to context in a template file, you should always initialize it with Timber::get_context().
I know, getting the concept of a "Context" might be a little confusing at first. Basically it’s an array of values that you pass to your Twig files to display. Timber::get_context() sets a lot of useful variables for you, so you don’t have to set them all by yourself.
I hope this clears things up. Good luck!

Thanks. got it working. in the navigation controller i was callingTimber::get_context() in the navigation.php which was overriding my navColorClass from my template files.

Great that you figured it out. I’m going to close this then.


Conda install failing - "Cannot link a source that does not exist"

Hello,
I'm fairly new to Python and am having trouble installing this umap module through conda. I have a fresh Windows install and fresh install of Anaconda. Every time I try to conda install umap-learn (conda install -c conda-forge umap-learn) I get the following message:
ERROR conda.core.link:_execute(502): An error occurred while installing package 'conda-forge::automat-0.7.0-py_1'.
CondaError: Cannot link a source that does not exist. C:\Anaconda3\Scripts\conda.exe
Running conda clean --packages may resolve your problem.
Attempting to roll back.
I have tried many things - the suggested conda clean, updating conda, etc. Does anyone have any ideas?

I'm not very good at these things, but did you install anaconda for you (your user) only or for all users? If you type conda in command line, does it work ? Do you have a conda.exe file in the following folder C:\Anaconda3\Scripts\?
Did you also try to install umap with pip ?
pip install umap-learn

Thanks for your reply. I did install this for all users, it's on my personal computer and I'm the only one on there. I set the environment paths for both C:\Anaconda3 and C:\Anaconda3\Scripts. I do know I have conda in C:\Anaconda3\Scripts. I'll make sure I can call conda from the command line when I return and will see if pip works as well.

Never did get the conda install to work, but pip install solved the problem - thanks!


Preserve modification time snapshot upload

Issue summary

When executing chmod here:
https://github.com/ChainSafe/forest-iac/blob/58610c1fcb0de4964958a9da5540170d1ac18423/scripts/daily_snapshot/upload_snapshot.sh#L18
we bump the modification time. It's related perhaps to s3 or mounting itself as chmod on a regular filesystem does not change the modification time.
This gets troublesome as in
https://github.com/ChainSafe/forest-iac/blob/58610c1fcb0de4964958a9da5540170d1ac18423/scripts/daily_snapshot/snapshots_prune.rb#L57
and in Forest
https://github.com/ChainSafe/forest/blob/9e9813489ff443df5667a5ff0cf4df00ca70e0e4/forest/shared/src/cli/snapshot_fetch.rs#L210
we sort by modification time. As a result in the latter, forest-cli --chain calibnet snapshot fetch will get us more or less a random snapshot if none was uploaded recently.
We should either figure out how to perform the operation without modifying permissions or do it in a way that preserves the modification time. We could always save the modification times before chmod and apply them once it's done - it's more of a workaround, though.
Other information and links

Just got an idea, perhaps changing chmod -R +rw "$BASE_FOLDER/s3/$CHAIN_NAME"  to chmod +rw "$BASE_FOLDER/s3/$CHAIN_NAME"  will do the trick


Support to set the component's value programmatically

Problem description
Is there any easy way to set the component value programmatically (eg SelectField) from outside the component?
We are using Material-UI in a Rails app, and writing the acceptance test via selenium capybara. But it's very hard to set the value for Material components from the testing scripts.
Thanks
Steps to reproduce
Versions

Material-UI:  0.15.0
React: 15.0
Browser:  Chrome

https://github.com/callemall/material-ui/blob/master/CONTRIBUTING.md#asking-questions


"possible EventEmitter memory leak" warning on adding 11th torrent

Let's silence this nonsense.

I guess it's about adding this.setMaxListeners(0) at https://github.com/feross/torrent-discovery/blob/master/index.js#L18 but not 100% sure without the uncut stacktrace.

This was actually caused by the way we reuse a single DHT instance for all torrents. The fix is actually to
dht.setMaxListeners(0) inside of webtorrent/index.js which I will do now.


Bumped production RELEASE for 1.20-10

Bumped production RELEASE for 1.20-10
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/unhold


Force cell editing via API

Is there are any legal way to start cell editing via JS? Like click first row cell and start editing of first editable cell in a row?

added API for startEditing(), will be in next release.


Solve SF 7 deprecation

Hi @damienalexandre @lyrixx,
I'm getting the following deprecation with SF 7
The "Symfony\Component\HttpKernel\DependencyInjection\Extension" class is considered internal since Symfony 7.1, to be deprecated in 8.1; use Symfony\Component\DependencyInjection\Extension\Extension instead. It may change without further notice. You should not use it from "JoliCode\Elastically\Bridge\Symfony\DependencyInjection\ElasticallyExtension".

This PR fix it.

Thanks a lot!

You're welcome, could you consider a patch release @damienalexandre ?
Thanks

Yes here it is: https://github.com/jolicode/elastically/releases/tag/v1.9.2


Twitter Sentiment Analysis

💥 Proposal
My name is Mehak. I am a third year student studying BS in Data Science and Applications at Indian Institute of Technology, Madras. I am a GSSOC contributor. I want to work on a project related to natural language processing. I want to classify tweets.

Hello , I am Priyanka Deshmukh, Final year Student of Mathematics and Computing at Madhav Institute of Technology and Science Gwalior. I am GSSOC contributor and I implemented Sentiment analysis in one of my  twitter Clone Project . I want to solve this issue. Please assign it to me .
Thank you for considering this proposal.

Hi , I would like to work on this issue.

Hi, we have a similar issue. Hence, we cannot assign you this issue.


Make Bin great (again)

Right now, there are some architectural integrity flaws in the system that I want to fix to make the Bin subsystem more centralized:

[ ] A PackageRegistry instance needs to be fed into a runner if the runner intends to use it (this is simply incorrect). Most runners will need to know information about files, which includes file locations.
[ ] Graph objects are constructed manually, outside the scripting environment
[ ] The idea of 'modules' hasn't been fleshed out. One of the next steps is to be able to add modules, which include their own scripting environment. However, it'd be even better if they were sandboxed to their own global tables, and then parent (outer?) modules that included those sub-modules could access that child module's global table as a simple returned table. That'd be amazing. EDIT this is entirely possible.
[ ] Environment is a misnomer; ideally, configuration files should be their own modules and all modules should belong to a single environment; currently, Environment is a single scripting instance.
[ ] There is no coupling between Graph::addInput()/Graph::addOutput() and the PackageRegistry object. This is a problem.
[ ] There are no checks for file existence upon adding them as source inputs
[ ] There are no checks to see if the intended outputs were generated
[ ] The Git subsystem that will ultimately enable fetching plugins has not even been looked at
[ ] Runners require that they are casted to Runner* in order to have the full interface. Super annoying; is that helper method even necessary?..
[ ] Tasks are simply strings. They have no inclination as to where they came from nor do they support any meta-data.

Some things that are intended (at least for now):

There is a PackageRegistry for every Environment (see above for the note about the name Environment) - realistically, a PackageRegistry for each Module. This is intended because all modules register their packages relative to their module root, and thus need to have a clean registry that can be tacked on to the parent registry via PackageRegistry::addPackage(..., ..., PackageRegistry).

I'm sure I'll be adding more to this, but these didn't warrant their own issues as these are the things I envisioned for Bin from the start and hence intend for them to be completely functional in v1.

re coupling registry with graph and making modules:
Going to make a super-interface Registry that the existing PackageRegistry will implement. Then, there will be a subclass of Registry called NestedRegistry that is a proxy wrapper around another Registry that tacks on a base package string.
Then, Graph will be modified to use a Registry object that checks to see if a package has been registered upon a label being added to either inputs/outputs.
Further, this will help with sub-module architecture; a nested module is run with its own script state and its own package Registry (which is really a NestedRegistry). When it adds packages, those will be forwarded up the chain to ultimately be adding the fully qualified packages.

re Environment misnomer:
Changing it to ScriptGlobals will help.

Closing in lieu of breaking these out into their own tickets.


Users need to be able to upload a corpus to S3

Best left to other software. Keep TAP focused on analytics (functional in style)


Merge HIFLD data in with DH and HCRIS

This PR builds on the matching logic in #81 and refactors the matching algorithm to allow for N-way matching where N>2. This allows us to introduce HIFLD as the authoritative data source for hospital facilities, and match all of DH and HCRIS to it.
TODO:

[x] Make the output ordering deterministic - currently sequential runs of the matching notebook will produce datasets in a different order.
[x] Integrate HCRIS 2017/2018 data found in this project to create a more accurate HCRIS dataset, and generate new matches with that HCRIS data.
[x] Integrate the new matches into the downstream workflows, particularly notebook 04 which will have to change logic around what data is assigned to account for HIFLD data and facilities lacking DH data.
[x] Generate a new hscap dataset to be integrated into the visualization.

After the above TODO's we should be set to do the next data release.

I added the section to 02_Process_HCRIS_Data.ipynb that updates the hcris2018 geojson with data from jsfenfen at https://github.com/jsfenfen/covid_hospitals_demographics/blob/master/data/processed/hospital_data.csv
This currently only includes jsfenfen data updates to facilities already present in our HCRIS2018 reporting. This means some ~200 rows of facility data from jsfenfen's file is dropped. I think this is okay for now, pending a larger revamp of the HCRIS processing notebook that actually runs through jsfenfen's workflow to get data from multiple years of HCRIS reports.

Preview's looking pretty good! Noticed a couple of things we need to fix:

[ ] manual override seems to be adding rows, not replacing/overriding the existing row correctly. For example, now there are 2 'LAGUNA HONDA HOSPITAL AND REHABILITATION CENTER' and 2 'ST. FRANCIS MEMORIAL HOSPITAL'. There are also 3 'ARKANSAS VALLEY REGIONAL MEDICAL CENTER' entries (including the original with the 520 ICU beds) - which means one of these duplicates (the lower cased name one) probably got into the data on an earlier processing run?
[ ] I think we should drop the HIFLD STATUS = CLOSED facilities before computing the aggregates and generating the viz. These closed facilities represent 33542 total licensed beds, 2935 staffed beds (not sure how these would be staffed if closed?), 177  staffed ICU beds from 435 facilities
[ ] it looks like the state-level color breaks were not regenerated or updated in the viz?


[Event Request] Table 18 "Customer", OnValidate Field "No.", OnBeforeNoSeriesTestManual

Please add an event OnBeforeNoSeriesTestManual with an IsHandled Boolean.
We use multiple No. Series on Table 18. We need to be able, to test a diffrent no. series then the one in sales setup.

Thank you.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Added emotion detection feature based on text input

Issue #346
Added emotion detection based on text input
I have read the Contributing Guidelines
I'm a GSSOC'24 contributor

@Saniya-BZ merged!

Can my sisters directly add issue on GitHub?
Only 2 days left. Please
On Thu, 8 Aug, 2024, 11:51 am github-actions[bot], @.***>
wrote:

🎉 Your pull request has been successfully merged! 🎉 Thank you for your
valuable contribution to our project. Your efforts are greatly appreciated.
Feel free to reach out if you have any more contributions or if there's
anything else we can assist you with. Keep up the fantastic work! 🚀
—
Reply to this email directly, view it on GitHub
https://github.com/TAHIR0110/ThereForYou/pull/349#issuecomment-2275039352,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCCLZBRJTL6D7KT5MXPRNZDZQME6JAVCNFSM6AAAAABMCWS6JSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZVGAZTSMZVGI
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add MessagePack

Is there any chance of adding MessagePack as a library?
MessagePack is, from their website:

It's like JSON.
but fast and small.
MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it's faster and smaller. Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves.

We'd be happy to accept a PR for messagepack!

Added in #769

Thanks, @Mixaill!


Updated World, UnsafeWorldCell Resource methods to use Res, ResMut

Objective

Fixes #9926

Solution

Updated UnsafeWorldCell Resource methods to return either Res or ResMut where appropriate, using get_resource_with_ticks to obtain the relevant data.
Updated associated methods in World
Cascaded changes across Bevy as required.

Changelog

Updated UnsafeWorldCell::get_resource(_mut) to return Res/ResMut
Updated World::(get_)resource(_mut) to return Res/ResMut
Updated World::resource_scope to use ResMut

Migration Guide
Simply use into_inner() to retrieve the inner reference for &R being replaced with Res, and into for Mut and ResMut.

I don't see much reason to change Mut<> to ResMut<>. They do the same thing -- the only reason that ResMut exists is because with SystemParam, you have to distinguish between components and resources via the type itself. Here, we're able to use the method's name to distinguish between components and resources, making ResMut unnecessary. We already treat Mut as the "canonical" change detection smart pointer: ResMut::reborrow returns Mut, for example.

the only reason that ResMut exists is because with SystemParam [...] We already treat Mut as the "canonical" change detection smart pointer: ResMut::reborrow returns Mut, for example.

Between that, and this comment from @cart, I'm going to switch this PR to draft and make some fairly major changes.

Going to close this out since we're likely going to move in the direction described in #11825


directpath integration should enable grpclb

While testing directpath, I noticed that setting GOOGLE_CLOUD_ENABLE_DIRECT_PATH=my-service is not enough because grpc does not enable grpclb by default and requires the system property io.grpc.internal.DnsNameResolverProvider.enable_grpclb=true. Otherwise all of the requests will fail with an INTERNAL error code

Also of note: the value of the system property is read only once when the class DnsNameResolver is loaded which will make it hard to tie it to GOOGLE_CLOUD_ENABLE_DIRECT_PATH

@igorbernstein2 Do you suggest that setting GOOGLE_CLOUD_ENABLE_DIRECT_PATH should automatically set io.grpc.internal.DnsNameResolverProvider.enable_grpclb=true? I guess it is not going to be possible (due to the fact you mention in the comment). I guess the situation is even more weird on grpc side. Grpc seems like having different default values for the system property in different parts of the codebase:
grpclb/SecretGrpclbNameResolverProvider assumes that the default value is true, while:
core/DnsNameResolverProvider assumes that it is false.
I don't have context here, but it seems like having both env variable and system property is redundant here (just one would be enough). Also since the system property is read only once in static variable in grpc internals and this happens on very early stage (class loading) it may happen before any of the gax-java code is loaded/executed. So it is impossible to provide any guarantee about value of io.grpc.internal.DnsNameResolverProvider.enable_grpclb from gax code.
Does it sound reasonable? I guess the only thing we can do in gax-java is to check the system property when the env variable is checked and if they don't match throw some sort human readable error/warning describing the situation for the user and saying what should be done (i.e. that both env variable and system property must be set). Will that be enough?

As off grpc 1.25.0, this is no longer needed ... the grpclb property is enabled by default


_multimap_base_phrases.conf c&p mistakes

base_phrases_m_de {
  type = "content";
  filter = "oneline";
  regexp = true;
  map = "https://raw.githubusercontent.com/martinschaible/rspamd-rules/main/maps.d/_base_phrases_l_de.map";
  score = 5.0;
  symbol = "BASE_PHRASES_M_DE";
  description = "Base: Phrases, Score MID, german";
}

fix:  map = "https://raw.githubusercontent.com/martinschaible/rspamd-rules/main/maps.d/_base_phrases_m_de.map";
base_phrases_l_de {
  type = "content";
  filter = "oneline";
  regexp = true;
  map = "https://raw.githubusercontent.com/martinschaible/rspamd-rules/main/maps.d/_base_phrases_l_en.map";
  score = 1;
  symbol = "BASE_PHRASES_L_EN";
  description = "Base: Phrases, Score LOW, english";
}

fix: base_phrases_l_en

Thanks! It's fixed


[Feature Request] support for path variables

Would be nice to have a support for path variables:
/users/{userId}/numbers
Currently we can only use an environment variable in that case. But this is a very inconvenient way and inflexible because this parameter may change for each request and is environment independent.

Thanks for the request @pklopotowski! This is probably a duplicate of #203

@gschier Definitely, this is the same type of requirements. I was searching for [Feature Request] marker, but #203 is marked as [Proposal], my inattention.
But let's focus on the problem. As you wrote, it may be done by placeholders. This gives us flexibility and shows a changeable/configurable part of a request.

Exactly, meaning it can work for other things besides URL path variables. 😄

Closing this one, as #203 seems like an appropriate solution.

ok, thx. I will be waiting for this feature

Any chance that #203 gets added to this roadmap?
It has a lot of up-votes and a glaringly missing feature of Insomnia.

Note that #203 proposes to use a special kind of template syntax such as {% my_variable %} within the URL. When importing Open API specifications, the URL will contain {my_variable} (as the OP suggests). So this might not be the exactly same use case.

Note that #203 proposes to use a special kind of template syntax such as {% my_variable %} within the URL. When importing Open API specifications, the URL will contain {my_variable} (as the OP suggests). So this might not be the exactly same use case.

this should not be closed
insomnia should support open api path parameters {my_variable} and allow to set them the same way as query parameters.
Postman does the exact same thing

Hi! Any progress here?

why is this closed? lol

Any update on this?

This is so sad, someone has even done this for them, and they choose to ignore him.


DrawingManager . Not working in react-google-maps^9.4.5

DrawingManager not working at all....

Did you include "libraries=drawing" in the URL?

so.. did you?


All units but harvesters animate when moving

Fixes #166 in a hacky way, but we can make this more abstract later.

Coverage increased (+0.4%) to 82.285% when pulling 53bb31e443b73fe260b05d4aa6d455504ef2e3e4 on bugfix/166-fix-animations into 5761b89ab2ff76e7b74c3e5d0049598673aae63f on master.


[MM-39106] Fix emoji size in post menu for one-click reactions

Summary
Fix the size of the one-click reaction emojis.
Ticket Link
https://mattermost.atlassian.net/browse/MM-39106
Release Note
NONE

@isacikgoz can we try ~16pt size for emojis? 18pt seems still too big

Hmm, interesting.. I only changed css file.

@emilyacook please can you create the QA hacktoberfestissue? I want to QA it.

Thanks @alauregaillard for testing. I'll merge shortly.

When you click on "Add reaction" emoji size is bigger. May be to be improved in another issue?

This PR only reduces the size of recently used emoji in the post menu, we are not changing the existing emoji size in the emoji picker.
Hope that answers your question.
Thank you again for your contribution! 🙂

Cherry pick is scheduled.


Add parameter for source

Use parameter to set packages source
Also use newer gpgtools

Hi @kytomaki instead of making the whole url the parameter, why not just the release version?
For example
# Install GPGTools.
class gpgtools (
  $version = '2015.03-b6',
) {
  package { 'GPGTools':
    name     => 'GPGTools.pkg',
    provider => 'pkgdmg',
    source   => "https://releases.gpgtools.org/GPG_Suite-${version}.dmg",
  }
}

That's an excellent idea. I'll update the pull-request in a minute.

Hello @tarebyte I rebased the pull-request into a single commit.

:sparkles:


Typo in gcm_regress.j script

I think the gcm_regress.j script has a typo:
https://github.com/GEOS-ESM/GEOSgcm_App/blob/develop/gcm_regress.j#L931
I think should be $status, not status
This also appears at another spot in the code

Ah. Probably never caught it because it was commented out?


What are we doing with this contexts list?

@ujjwalaananth
https://github.com/kevinscaria/PolyMATH/blob/6c8a625ff67557701a1c4af591211ae872980dad/scripts/annotation_utils.py#L31

# Extract all screenshots into respective lists
    files = [os.path.basename(p) for p in glob.glob(os.path.join(paper_path, qdir,'*.png'))]
    contexts = [os.path.basename(p) for p in glob.glob(os.path.join(paper_path, cdir,'*.png')) \
                if os.path.basename(p)[0]=='c']
    questions = pd.Series([p.split('_')[0] for p in files if p[0]=='q']).unique()

Looks like it is getting overridden in line 39. So what is the point of the iteration in line 31

good catch - 31 is unnecessary since we add more flexible logic in lines 57-60. this can be dropped.

Perfect. Will revise it in next revision


Is this okay? Or should I allow certain exceptions to not halt the worker loop?

What about catching the exception, handling as unhandled exception (logged warning), wait 30 seconds, restart worker process loop?


need to update release notes

need to update release notes, keep saying nov....

VS Code 1.30 (the latest stable build) is the November release of VS Code


Update 1.composables.md

🔗 Linked issue

❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

📝 Checklist

[ ] I have linked an issue or discussion.
[x] I have updated the documentation accordingly.

nuxi is correct in this context, although nuxt is also an alias. Was it not working for you?


CORS support

In the old 4.5 library there was support for CORS configuration.  I don't see that here.  I know that OWIN/WebAPI has support now, but it seems to not support static files where the old IdentityModel.4.5 seemed to.  So the question is twofold:

Will the CORS support from 4.5 be added here?
Is there an alternative way to enable static files CORS support in WebAPI?

Thanks in advance

No, we removed the CORS feature in favor or Web API and Katana's implementation. Read here for the Web API implementation:
https://msdn.microsoft.com/en-us/magazine/dn532203.aspx

so is there someway to allow static files using the Web API & Katana?

The CORS support in Web API is a different one than Katana. If you want support for static files, then look at the Katana implementation. Don't forget to enable RAMMFAR.

we are already using the Katana implementation and we are using both of the following
        app.UseStaticFiles();
        app.UseFileServer();

You'd have to get docs from Microsoft for the Katana middleware (or read the source code, which is what I'd do to use it).

Thanks for the help Brock.  In case anyone else has the issue this is what I did
app.UseStaticFiles(new StaticFileOptions
        {
            OnPrepareResponse = context => context.OwinContext.Response.Headers.Set("Access-Control-Allow-Origin",
                context.OwinContext.Request.Headers.Get("Origin"))
        });

Plus RAMMFAR


Revert "Create  cp-aibus-dox-custom-schema.md"

Reverts SAPDocuments/Tutorials#7148

Pending approval ...


Long delay and rendering problems in IE9/IE11

The following one-page PDF...
http://www.well.ucr.edu/docs/party_enforcement.pdf
...takes 40 seconds to display in IE11, and is rendered correctly. Desktop PDF viewers (E.g. Evince) take 2-3 seconds.
In IE9 it takes the same amount of time and then is rendered as this,

Note that this reproducible in Microsoft's provided testing VMs from http://modern.ie/
This delay is present in PDF.js beta 1.0.1040 (stable), 1.0.907, as well as the demo page running 1.0.1149.

I download this PDF and see blank page in IE.
While it is OK in Firefox.

Closing IE11/Edge (non-Chromium-based) issues in response to #11211. Please note that, as outlined in https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support, only bugs which completely prevent the library and/or the default viewer from running will be accepted.


Double-clicking custom title bar rarely maximizes / restores

Testing #199023
Double-clicking custom title bar rarely maximizes / restores. It only sometimes works. Both main and floating windows. Testing on Linux.

@chrmarti curious if you could test with stable to see if this is always like that for you. Also please state if you are using native or custom title.

Indeed, same in 1.84.2.

@chrmarti I did not reproduce this. Are you clicking in a specific location or using a VM?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Added support for the = CIGAR operator.

@fairliereese I just started working with TALON but I have some data from an aligner that produces = CIGAR operators.
Here's a patch to make TALON support the = operator.

@fairliereese Any thoughts on this?  I've added tests and it works for my larger dataset.

Thanks a lot for reminding me of this! I appreciate the thorough work you've done :)

No prob!  I figured you're like me and saw it, then never got back to it 😄


Changelog dates since 0.2.11 seem wrong

Unless you have a time machine and your personal timeline is now situated a year in the past (in which case I have some bets I'd like you to place), I believe the changelog has incorrect dates starting with version 0.2.11.

Oscar,
Wow, you are so right!  The wonders of copy and paste.  Thanks, I'll fix them the next time I push stuff up.
Thanks again -- Kim

On Feb 2, 2017, at 3:44 PM, Oscar Marshall<EMAIL_ADDRESS>wrote:
Unless you have a time machine and your personal timeline is now situated a year in the past (in which case I have some bets I'd like you to place), I believe the changelog has incorrect dates starting with version 0.2.11.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I finally fixed this in some past release, and just now remembered to close the issue.


RTL Flag isn't work

RTL Flag isn't work. in Init function.......
init({
rtl: true;
})
i try to add this also shouldUseNativeEvents but not any change has shown
what is the previous action should i do before this configuration

Hello @mahmoudjhonny, thanks for getting in touch.
Could you please provide some example code snippets of how you are trying to approach this?
#96 is the PR where this functionality was added and it has been tested both internally and externally without issues, so I am unsure what problem you might be facing.
Let us know and we can try to help you out if there's any issues in our library.

Hello @mahmoudjhonny,
Thanks for reaching out.
Based on the functionality you're describing, the rtl flag in the init function does not directly alter the layout/UI. Instead, it changes the navigation system and how focus is calculated. To modify the layout, you will need to manually change the document’s direction by setting dir="rtl" in your main HTML structure. Once this is done, the RTL navigation should work as expected.
Additionally, we have an updateRTL method (Documentation) that allows you to dynamically switch between RTL and LTR navigation without needing to reinitialize the norigin-spatial-navigation service (i.e., no need to call init again). This makes it easy to toggle navigation systems on the fly.
I hope this clarifies your doubt! If you still face issues or need further assistance, please share more details (including code snippets), and we’ll be happy to help.


Allow automatic posting to discord webook every tick

After a tick has happened for the BGS, automaticly post your BGS activity to the discord webhook you've set up. If EDMC is not open, then post to the discord webhook as soon as EDMC opens, and a tick has occured.

Thank you for taking time to post this suggestion, but it is a duplicate of #61 so closing this one.


Auto-Presence from browser.idle events

Pàdé has permission to monitor desktop activity via the browser.idle events. Use this to generate XMPP presence broadcasts when the user

locks the desktop
unlock the desktop
is idle for configured period
resumes desktop activity

Set presence show accordingly and set status to "was last seen at %s"

Done. Now available in version 0.8.12


javax.net.ssl.SSLException: Unable to create application data

Caused by javax.net.ssl.SSLException: Unable to create application data
at com.android.org.conscrypt.NativeCrypto.SSL_new(NativeCrypto.java)
at com.android.org.conscrypt.SslWrapper.newInstance(SslWrapper.java:58)
at com.android.org.conscrypt.ConscryptFileDescriptorSocket.newSsl(ConscryptFileDescriptorSocket.java:159)
at com.android.org.conscrypt.ConscryptFileDescriptorSocket.(ConscryptFileDescriptorSocket.java:152)
at com.android.org.conscrypt.OpenSSLSocketFactoryImpl.createSocket(OpenSSLSocketFactoryImpl.java:149)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:308)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:283)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:168)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:257)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:254)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:200)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
model:ONEPLUS A5000
android version:8.1
okhttp version:3.12.1

@jaydenyuhy did u fix it? i meet same bug

same bug +1

You can raise with the conscrypt project. Or stackoverflow. But there are also similar reports. It’s likely a handshake failure or simple resource limit problem in native code. But not really for me to guess.

解决了吗？

Facing the same issue. bug +1

oh my god,I have meet this same bug. Who did solve this problem? thanks.

Facing same issue

Same

same

same

oh my god,I have meet this same bug. Who did solve this problem? thanks.

oh my god,I have meet this same bug. Who did solve this problem? thanks.

you can try extend the number of FD(file description)  in your device.   you should  solve this problem. Now I don't meet this bug.


Fix the unexpected error that occurs when an empty control block is used.

Fixes： https://github.com/sqlalchemy/mako/issues/146
When the first control block is empty or comment, the correct result will now be rendered.
from mako.template import Template
template = r"""
% if False:
% elif False:
% else:
    test
% endif
"""

t = Template(template)
print(t.render())

Result:

    test

cool.
can we add changelog files to these patches?    Dont worry about getting them perfect I can fix them up later
example
https://github.com/sqlalchemy/mako/commit/1d6c58e7124653bc11b0a4f153bdbaab41622854#diff-22252f506a8da7ab5343802f53f7c35770390f669fe0f73a9e2345f0914ebb98

New Gerrit review created for change d0a0981a379ac7a2b8a8e7db6344ed82425ae5b2: https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/5148

Patchset 571a73a1d84ee922b38ce5817a5822fbe0268cd0 added to existing Gerrit review https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/5148

Thanks so much for your help! Everything's been updated now.

Gerrit review https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/5148 has been merged. Congratulations! :)


Swap Helvetica medium for bold behind toggle

☝
before (body is light and part of is medium)

after (body is regular and part of is bold)

Are we using this as a test? Or is it just for people internally to see it?

Where's the toggle?

It's an update to the pre-existing helveticaRegular toggle.


Run minimized on login

I wonder what proportion of applications that want "run on startup" behavior would be satisfied with a "run minimized on startup" mode which did not launch a new browsing context but did ensure that the browser has been started so that it is ready to receive push notifications, run periodic background tasks, etc. in behalf of the application.

For reference, this is regarding the "Run on Login" explainer:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/RunOnLogin/Explainer.md
(Multiple explainers in the same repo, so disambiguating for future readers.)

This is a great ask coming consistently from partners and we are going to modify the explainer to account for this. Agree 100%.

@reillyeon, we added an option to get the app start minimized in our updated explainer. Also, I left a comment in the referenced issue in the web app manifest repo above. Thanks for having provided the context there.


⚠ ClamAV has degraded performance

In 40de05e, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 111 ms

Resolved: ClamAV performance has improved in 1859c26.


Selected item on drop down does not show in box after animation of label goes on top

I can't get the selected value to show where the label is after the animation happens.  It shows the proper selected color if you open the drop down again but does not populate where the label once was. Any idea what's going on here?

facing same problem

https://github.com/n4kz/react-native-material-dropdown/issues/64
This is the solution.. spent a lot of time looking for this.


Kemi store front

Implemented the storefront page (mobile and screen)

@juliet-karpah This is the right images

added note in slack for mobile view


Occasional reconciler error

k8gb_gslb_error_total metric revealed , an unexpected error generated inside the controller runtime. From my observation, the error is not critical to the functioning of k8gb, it just messes up the metrics.
Find out what in k8gb is causing this error and make the necessary changes.
the error occurs very little and appears after a while of running on localhosts
+ k8gb-56c6795669-8l4kn › k8gb
k8gb-56c6795669-8l4kn k8gb 2021-08-19T13:31:30Z ERR workspace/controllers/logging/logr.go:60 > gslb: Reconciler error {"name":"test-gslb-failover","namespace":"test-gslb","reconciler group":"k8gb.absa.oss","reconciler kind":"Gslb"} error="Operation cannot be fulfilled on gslbs.k8gb.absa.oss \"test-gslb-failover\": the object has been modified; please apply your changes to the latest version and try again"
k8gb-56c6795669-8l4kn k8gb 2021-08-19T13:31:44Z ERR workspace/controllers/logging/logr.go:60 > gslb: Reconciler error {"name":"test-gslb","namespace":"test-gslb","reconciler group":"k8gb.absa.oss","reconciler kind":"Gslb"} error="Operation cannot be fulfilled on gslbs.k8gb.absa.oss \"test-gslb\": the object has been modified; please apply your changes to the latest version and try again"
k8gb-56c6795669-8l4kn k8gb 2021-08-19T13:31:44Z ERR workspace/controllers/logging/logr.go:60 > gslb: Reconciler error {"name":"test-gslb","namespace":"test-gslb","reconciler group":"k8gb.absa.oss","reconciler kind":"Gslb"} error="Operation cannot be fulfilled on gslbs.k8gb.absa.oss \"test-gslb\": the object has been modified; please apply your changes to the latest version and try again"

@kuritka is this still the issue?

Hi @somaritane,  just checked locally. Yes, the Reconciler error still ocurs.

@kuritka it very frequent situation for k8s based projects. Please see how it was handled by crossplane runtime https://github.com/crossplane/crossplane-runtime/pull/498 . TL;DR : let's just move such events to debug log level of minimal importance

@kuritka I think it's not the case anymore and will close the issue. Feel free to reopen if it is still valid


fixes cross browser boilerplate styles / adds support for Enter key

The labels on the boilerplate pages were positioned weirdly on all browsers but Chrome (http://infinitered.d.pr/n7T2). The first commit fixes that issue.
The second commit adds an event listener for the Enter key on the boilerplate pages. Since the pages don't have a <form> element, you can't "submit" the inputs just by pressing enter. I added a function to detect the event and trigger a click which is what your code already handles.

I think i have to propagate these changes to the example_app as well. Working on that....

Should be good to go now.

Oh, that looked hideous! Thanks for this and for the Enter key binding 👍


403 clicking "fix credit card" in email when not logged in

My credit card expired and I got the email reminding me to fix payment info. I clicked the "fix credit card" button in the email and was taken to a 403 Forbidden page. Would expect to be taken to login form when I'm not already logged in. Thanks!

I think the behavior should be something like https://gratipay.com/new when a ~user is not logged in.

Solution to copy: https://github.com/gratipay/gratipay.com/blob/master/emails/charge_failed.spt#L15https://github.com/gratipay/gratipay.com/blob/master/www/new.spt#L8
Link in email: https://github.com/gratipay/gratipay.com/blob/master/emails/charge_failed.spt#L15
To change: https://github.com/gratipay/gratipay.com/blob/master/www/~/%25username/routes/credit-card.spt#L40

@mattbk, sorry for delay. That would be better, but could the styling for the 401 page be customized to put the emphasis on login rather than the HTTP status code? End users aren't concerned with the 401 status, they just want to be presented with the login form as soon as possible.

Probably. Glad you're paying attention--I don't even look at anything in the header anymore.

Not as complicated as https://github.com/gratipay/gratipay.com/issues/4040#issuecomment-220634087 lays out. There was no 403.spt file, so no special page was shown.

Shouldn't we be raising 401 in this case instead of 403?
401 = not logged in
403 = already logged in but still not allowed

401 = not logged in
403 = already logged in but still not allowed

Then why do I get 403 when not logged in, for pages like this?

Because we're doing it wrong? :)
Unless we're not, but I think we are ...
https://httpstatuses.com/401
https://httpstatuses.com/403


fix: update tf code and add latest version

what

update new github/workflows.
update variables.
remove unnecessary files.
add terraform and azure latest version.

Implemented in PR raised by @Rupalgw
https://github.com/clouddrove/terraform-azure-vnet-peering/pull/26/files#diff-a0aba5a2bd30b2f80a3a18aa24ce43670b1320ca0a8b9c103bb3bc971ae30a85