proposal: cmd/go: go mod: limit version resolution to packages that are consumed

go modules resolve the minimum required version of dependencies based on the go.mod of modules used by a project. This works well for small modules where the list of dependencies in go.mod is representative for the code, but is problematic for larger modules that provide many packages.
Let's illustrate with an example.
Example: project "foobar"
This is our "foobar" project. It uses logrus to print "Hello foobar":
mkdir foobar && cd foobar

cat > main.go <<EOF
package main

import (
    "github.com/sirupsen/logrus"
)

func main() {
    logrus.Info("Hello foobar")
}
EOF

go mod init foobar

Project foobar requires logrus 1.7.0 - it can't currently use a newer version of this dependency, because it has change in behavior that causes foobar to break (of course, SemVer should guard us against breaking changes, but the world isn't perfect, so we specify we want v1.7.0):
go mod edit -require<EMAIL_ADDRESS>go mod tidy

cat go.mod
module foobar

go 1.18

require github.com/sirupsen/logrus v1.7.0

require golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 // indirect

No project would be complete without an AppArmor check, and containerd provides an implementation for this. It's a small package, and pkg/apparmor has no dependencies, other than Go stdlib (apparmor.go, apparmor_linux.go, apparmor_unsupported.go).
cat > main.go <<EOF
package main

import (
    "github.com/containerd/containerd/pkg/apparmor"
    "github.com/sirupsen/logrus"
)

func main() {
    if apparmor.HostSupports() {
        logrus.Infof("Running Foobar Deluxe, with AppArmor")
    } else {
        logrus.Infof("Running Foobar Basic")
    }
}
EOF

So we add the containerd v1.6.2 dependency:
go mod edit -require<EMAIL_ADDRESS>go mod tidy

However, checking our go.mod;
Adding containerd as a dependency forced us to also updates the logrus dependency to a newer (for us "incompatible") version (as well as updates the golang.org/x/sys dependency), even though none of the files in containerd's pkg/apparmor package use this dependency
$ cat go.mod
module foobar

go 1.18

require github.com/sirupsen/logrus v1.8.1

require (
	github.com/containerd/containerd v1.6.2
	golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)

While the project "foobar" example is of course just to illustrate the problem, this issue is problematic for many real-life situations (some more details below).
Current "solutions"
There are various "solutions" for this problem, but they're not for the faint of heart.
A. Use replace rules
Projects can add a replace rule to force go modules to use a fixed version. While this helps "us" (the "foobar project" maintainers) build and ship our project, it's a different story for consumers of the "foobar" module; replace rules are not transitional, and because of this, all projects depending on our module will (out of the box) be "forced" to use the newer version, unless they copy the replace rules.
Various (sometimes "high profile") projects currently use replace rules (read them, and weep! 😭😭😭), e.g.:  containerd and kubernetes. Worst of all, using replace rules (especially when use to the extend as the kubernetes example) throws out one of the biggest advantages of go modules; version resolution / management.
B. Separate modules (multi-module repository)
We can ask the containerd maintainers to provide pkg/apparmor as a separate module. While this may be an option in some cases, maintaining a multi-module repository gets complicated fast;

modules become separate entities (need to be tested separately)
if there's dependencies between packages (now separate modules), replace rules may be needed to make sure code it tested against the version in the repository (not the latest released version of the module)
if these modules are expected to be used externally, each of them has to be tagged/released separately
which, in combination with "inter-module dependencies" also means tagging and releasing MUST be performed in the correct order (to make sure all modules use the latest release)

In short; unless "you're Google", or have a dedicated team of engineers to set up automation to perform these actions (e.g., the complicated release procedures for the kubernetes project), maintaining a multi-module repository is complicated, and in many a heavy burden for project maintainers.
C. Separate modules (multiple repositories)
We can ask the containerd maintainers to provide pkg/apparmor as a separate module in a separate repository.
While this gives a clearer separation between the modules, it shares the same (if not more) problems as the previous solution. Maintaining a separate repository can add significant overhead for project maintainers (and in some cases may be restricted due to (company) policies). In addition, not all packages may be suitable to become a module / project of their own (let's not encourage creating another "leftpad").
D. Just copy the code! (It's open source, y'all!)
Unfortunately, this solution has been chosen on many occasions. I don't think this needs explaining why this should not be a preferred solution.
What did you expect to see? (proposed solution)
I'd like to see go modules to only consider version resolution based on the packages that are actually consumed from a module. Go modules conflates all packages in a repository, resulting in the (main) go module / go.mod to become a collection of all possible dependencies that may be needed (depending on which packages are consumed from the module).
While go modules won't use dependencies if they're not used by any code, version resolution is still be influenced by them (see the example above). I'm not very familiar with the internals of go module's tooling, but I think go has all the "building blocks" available to make this possible;
It's able to provide which imports a package needs:
go list -json ./pkg/apparmor/ | jq .Imports
[
  "os",
  "sync"
]

With that information, it could;

take all dependencies listed in the module's go.mod
remove all direct dependencies that are not used by the packages that are consumed
use the remaining dependencies to perform version resolution

And, if in future containerd's pkg/apparmor would introduce a new dependency, that's the moment it gets its "right to vote" in the version-resolution for that dependency.

/cc @dims @kzys @dmcgowan @tonistiigi @cpuguy83 @tianon (had this idea as a "draft" / "note" let me know if this idea makes sense to you 😅)

cc @liggitt @thockin (our veteran go module wranglers)
@thaJeztah I love this! frankly ANYTHING other than status quo would be very welcome change. Thanks for taking the time and drafting this as a proposal

Various (sometimes "high profile") projects currently use replace rules (read them, and weep! 😭😭😭), e.g.: containerd and kubernetes. Worst of all, using replace rules (especially when use to the extend as the kubernetes example) throws out one of the biggest advantages of go modules; version resolution / management.

not to detract from the main point of the issue, but kubernetes/kubernetes does not use replace directives to force downlevel versions. This is enforced in presubmit, and there are no replace directives that select versions other than the require versions in the submodules published out of kubernetes that are consumed as libraries (for example, client-go).

This sounds like it would make version resolution dramatically slower (everything from go get/list/tidy), requiring downloading and scanning the source code for every potential dependency revision.

This sounds like it would make version resolution dramatically slower (everything from go get/list/tidy), requiring downloading and scanning the source code for every potential dependency revision.

I guess that's something to look into, if it's possible to optimize. (As mentioned, I'm not deeply familiar with who all version resolution is performed); I can imagine this being mostly an issue when adding / removing / updating the list of dependencies in go.mod. After that's done, the resolved versions are "fixated", so a go get of the main module would already have performed all resolution.
Perhaps there's other solutions possible, and I'm definitely open to alternatives. I opened this proposal because there's a real issue that quite some projects that I'm (directly/indirectly) involved in struggle with this on a daily base, and I'd like to see if we can improve the status quo, without such projects digging themselves in further with hacks and workarounds trying to fix issues with go modules.

there are no replace directives that select versions other than the require versions in the submodules published out of kubernetes that are consumed as libraries (for example, client-go).

😅 perhaps it was a bad example; even then, I wonder if kubernetes would've needed the "please, don't use kubernetes/kubernetes as a module" situation (where modules are extracted from the main repository) if things were different? Also, if (e.g.) go mod (tidy|vendor) --recursive and/or tooling was available to manage multi-module repositories (updating inter-module versions), to not having to script all of that.
(but going way off-topic now 😂)

To my understanding, module graph pruning helps with transitive dependencies, but not with the issues described in this ticket (I may be wrong though), which is why I was hoping this could trigger a conversation on how to solve this.

Ah, I see. You actually do depend on containerd, and that module has a direct dependency on logrus.
Right, so module graph pruning doesn't help there, but there also isn't an inexpensive alternative. If we restricted the analysis to the specific packages imported by your module, we would have to load the entire package import graph just to know which dependencies to use. With the Go 1.17 module graph pruning, we don't need to do that — all of the upfront analysis is based purely on go.mod files, and there are typically far fewer of those than .go source files for packages.
(It took a fair amount of thinking for us to come up with a design with that property! It's important for efficiency, and the graph-pruning invariants are designed very carefully to support it — it isn't something we can discard lightly. 😅)

So, in general you have two options.
One is to avoid upgrading containerd until you have identified and fixed the logrus incompatibility (either by upstreaming a fix to logrus itself, or by upstreaming a fix to whatever other dependency is not compatible with the current logrus release).
The other is to apply exclude (not replace!) directives to notch out the dependencies that you know to be spurious. For example:
exclude github.com/sirupsen/logrus v1.8.1

would notch out the transitive dependency from containerd, essentially asserting “yeah, it's required by my dependencies but I know it isn't relevant”. Due to module graph pruning, your own exclude directive would also prune out that dependency for users who depend on your module, although of course they could still end up with it in their own dependency graphs (for example, if they end up transitively importing containerd).
IMO exclude is best used only temporarily, to buy you some time for the aforementioned upstream fixes. At some point, there isn't really a viable alternative to maintaining compatibility with the latest releases of your dependencies.

Thanks for taking the time to write up those options (very much appreciated!)

Right, so module graph pruning doesn't help there, but there also isn't an inexpensive alternative

I appreciate "performance". That said (as I mentioned above); version resolution only is needed when updating a dependency. It's a "one-time" performance penalty. On projects where a single run of CI can take hours (or literally days in total compute time), I think that's acceptable.
The "logrus" and "containerd" situation is of course "fictive". In projects with a large dependency tree, things are usually more complicated (a more practical example could be cobra, which through 3 levels of indirection also depends on grpc, and etcd, and, well, "the world").
These issues often can arise from some indirect dependency deep in the dependency tree. More often than not, some small module that's (e.g.) following "best practice", and enables dependabot to always keep its dependencies on the most current version. That module itself may not be affected at all by new updates (it may only be using a small bit of it, or perhaps only as part of a tools.go (those are fun!)). But as a result, that tiny dependency forces the whole dependency chain to update to the latest version (effectively nullifying the "minimal version selection" of go modules).
Now, these things can be solved in "my project" (say, containerd); we can add an exclude rule (probably those will be "many" if one is needed for each version you don't want?) or use a replace rule (pin it to a specific version), but besides having to maintain the list of exclude (which can be potentially fun job), none of those help any of the consumers of my module. Effectively, it's kicking the can down the road, making it "whoever's next's problem".
In the ideal situation, things "explode", and their code fails to build, helping them notify "something's wrong!". Often, things are more subtle than that, and consumers may be living on a ticking timebomb (not theoretical; this  happened on more than one occasion, sometimes even resulting in security issues).
If replace and/or exclude rules would be transitive, that would somewhat help (preventing to kick things down the road), but a "smarter" version resolution, even at the cost of a performance penalty (at time of version resolution) would be great.
I realise this is a tough problem to solve, and (to some extend), go modules may not have been designed for large projects, but it's the situation we're in, so trying to find what options are possible. As mentioned; some of these problems can be "solved" or hacked/worked around by large projects themselves, but these projects also have a responsibility for their respective consumers (of which there may be many), so I'm also trying to explore if there's a solution that would address that side.

version resolution only is needed when updating a dependency. It's a "one-time" performance penalty

I thought it ran on pretty much every go invocation (run, test, build, list, etc, etc)

version resolution only is needed when updating a dependency. It's a "one-time" performance penalty
I thought it ran on pretty much every go invocation (run, test, build, list, etc, etc)

When lazy module loading is in effect (that is, if the main module is at go 1.17 or higher), we only load the full dependency graph when the dependency isn't found directly in the go.mod file (such as when running go test on some transitively imported package).
So, pretty much every go invocation can trigger a full load, but at 1.17 and above it's not as pervasive as it used to be.

I thought it ran on pretty much every go invocation (run, test, build, list, etc, etc)
When lazy module loading is in effect (that is, if the main module is at go 1.17 or higher), ...

Thx! Yes, so this is what I had in mind when I wrote that (but I'm sure there's gonna be situations I missed, where the performance impact can be an issue - let's see what/if we can come to something that works and satisfies most use-cases).

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Thanks @rsc !
FWIW, if you or the other maintainers think it may be useful to have a synchronous call with some project maintainers to brainstorm, let me know: happy to reach out to them to make that happen.

Hi @bcmills

The other is to apply exclude (not replace!) directives to notch out the dependencies that you know to be spurious. For example:
exclude github.com/sirupsen/logrus v1.8.1
would notch out the transitive dependency from containerd, essentially asserting “yeah, it's required by my dependencies but I know it isn't relevant”. Due to module graph pruning, your own exclude directive would also prune out that dependency for users who depend on your module, although of course they could still end up with it in their own dependency graphs (for example, if they end up transitively importing containerd).

I think this might be implied by your last parenthetical, but just to make it explicit -- my understanding is that would not help the original example here?
In other words, for the foobar example in the first comment above, I suspect that if the foobar author added exclusions for the "bad" versions of logrus, it would not immediately help any clients of foobar avoid those "bad" versions?
FWIW, I put together a quick example here, including to possibly help the conversation with something more concrete:
https://github.com/thepudds/test-go-mod-52296-a/releases/tag/v0.3.0
The foobar module there has exclusions of the "bad" logrus versions, but a client still ends up with a "bad" logrus version.

There might be multiple reasons for that, but I suspect part of it might be (from go mod ref):

If all imported packages can be found without loading the module graph, the go command then loads the go.mod files for only the modules containing those packages, and their requirements are checked against the requirements of the main module to ensure that they are locally consistent. (Inconsistencies can arise due to version-control merges, hand-edits, and changes in modules that have been replaced using local filesystem paths.)

... where the client of foobar has loaded the go.mod of containerd and seen the logrus v1.8.1 requirement in the v1.6.2 containerd go.mod, and hence ends up with the "bad" logrus v1.8.1.
And related (ref):

At go 1.17 and above, the go command adds an indirect requirement for each module that provides any package imported (even indirectly) by a package or test in the main module

Sorry if any of this is off base.
Finally, that's not to say exclude never helps downstream consumers -- rather, it doesn't seem to help the original example.

Hi @thaJeztah

we can add an exclude rule (probably those will be "many" if one is needed for each version you don't want?) or use a replace rule (pin it to a specific version), but besides having to maintain the list of exclude (which can be potentially fun job), none of those help any of the consumers of my module. Effectively, it's kicking the can down the road, making it "whoever's next's problem".

I suspect that is not quite right.
FWIW, I also put together another hypothetical with a different package-level import graph compared to your original example above:
https://github.com/thepudds/test-go-mod-52296-a/releases/tag/v0.4.0
In short:

apparmor from containerd is still in the module-level graph, but not necessarily in the package-level import graph.
foobar excludes the undesirable versions of logrus in the foobar go.mod.
a new client that does not have apparmor in its package-level import graph avoids the undesirable versions of logrus.

In other words, it is an example where exclude is helpful to the consumers in a Go 1.17+ world.
There are more details in that link.

probably those will be "many" [excludes] if one is needed for each version you don't want?

FWIW, I think that's right, which is what I did in that example.

@thaJeztah

But as a result, that tiny dependency forces the whole dependency chain to update to the latest version

That is correct, and it is an intentional property of the design. (See the section titled Upgrade Speed in the original MVS blog post.)
As a counterbalance, though, note that you don't have to upgrade that tiny dependency in your own module until you are ready.

In principle it would be possible to load only the parts of the module graph corresponding to the main module's import graph, and that could indeed avoid a few unwanted upgrades. That's a benefit.
But we would need to trade that benefit against the costs, and the costs as I see them are numerous:

go mod why and go mod graph would become more complex to use and interpret. (They would have to report not only the module graph, but the reasons for the module graph containing — and excluding — the nodes that it does.)

The implementations of the module loader and package loader would become much more tightly coupled. (They're already quite complex, but at least today we can have the package loader call into the module graph and not the other way 'round.)

Several operations that are fairly inexpensive today (such as running go test on a package imported by the main module) would become approximately as expensive as running go mod tidy.

I just don't see the cost/benefit tradeoff working out — those are significant costs, and the marginal benefit of putting off upgrades of dependencies just doesn't seem that high in comparison, especially given the available workarounds. (If your project is large enough to have a lot of dependencies, you'll probably have to upgrade them eventually anyway!)

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@thaJeztah wrote::

These issues often can arise from some indirect dependency deep in the dependency tree. More often than not, some small module that's (e.g.) following "best practice", and enables dependabot to always keep its dependencies on the most current version. That module itself may not be affected at all by new updates (it may only be using a small bit of it, or perhaps only as part of a tools.go (those are fun!)). But as a result, that tiny dependency forces the whole dependency chain to update to the latest version

FYI, if anyone is still following this issue, there is some related conversation in https://github.com/golang/go/issues/48429#issuecomment-1613696750 and in other comments in that "cmd/go: track tool dependencies in go.mod" proposal.


Temporary assets no longer listed in order of type

Describe the bug

not a regression. i think the temporary image assets used to be listed after the named image assets, instead of after everything?

Curious, what does the word "temporary" mean? That it will disappear when I leave? What does the "Danger!" icon mean above? If they both mean the sprite hasn't been named, perhaps we can find a better way to communicate this ... right now it feels like there is something dangerously wrong!

yep, "temporary" is the same as unnamed! behavior-wise, the difference is:
unnamed:

if you delete the block containing an unnamed asset, that image will be gone forever
if you duplicate the block containing an unnamed asset, and edit the new image, you will have two different images

named:

if you delete the block containing a named asset, the image is still present in the "My Assets" tab
if you duplicate the block containing a named asset and edit the new image, the image in BOTH blocks will be changed

it would be great to communicate this visually somehow in the blocks themselves (as well as the asset editor)... kiki has an issue here about how the concept of "temporary" vs named assets is confusing: https://github.com/microsoft/pxt-arcade/issues/3481


Include AWS jars in HBase image

This allows using ExportSnapshot to copy snapshots directly to S3.
These JARs are required in the HBase image:

/stackable/hadoop/share/hadoop/tools/lib/aws-java-sdk-bundle-1.12.262.jar
/stackable/hadoop/share/hadoop/tools/lib/hadoop-aws-3.3.4.jar

Just for the record: Please document them the same way as spark does it: https://github.com/stackabletech/docker-images/blob/a05caee2e504d1eeab2d079b969891d48539db9b/conf.py#L252-L253

Thank you, I'll take a look!


[admin] merge to live

Docs Build status updates of commit 2c568dd:
:warning: Validation status: warnings

File
Status
Preview URL
Details

Skype/WebSDK/docs/troubleshooting/auth/AADAuth-DelegatePermissions.md
:warning:Warning

Details

Skype/WebSDK/docs/troubleshooting/auth/AADAuth-IECORSRedirectURI.md
:warning:Warning

Details

Skype/WebSDK/docs/troubleshooting/auth/AADAuth-ReplyURLs.md
:warning:Warning

Details

Skype/WebSDK/docs/troubleshooting/auth/AADAuthFailures.md
:warning:Warning

Details

Skype/UCMA/media-guidelines.md
:white_check_mark:Succeeded

Skype/UCMA/transferring-a-call.md
:white_check_mark:Succeeded

Skype/UCMA/ucma-5-0-general-reference.md
:white_check_mark:Succeeded

Skype/UCMA/unified-communications-managed-api-ucma-5-0-sdk-documentation.md
:white_check_mark:Succeeded

Skype/WebSDK/docs/troubleshooting/auth/AADAuth-DelegatePermissions.md

Line 1, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 1, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

Skype/WebSDK/docs/troubleshooting/auth/AADAuth-IECORSRedirectURI.md

Line 1, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 1, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

Skype/WebSDK/docs/troubleshooting/auth/AADAuth-ReplyURLs.md

Line 1, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 1, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

Skype/WebSDK/docs/troubleshooting/auth/AADAuthFailures.md

Line 1, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 1, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Activate travis

Sets up build testing on travis.  This branch is tested, for example, here: https://travis-ci.org/wence-/cofs/builds/96775578
Also pytestifies some of the tests using fixtures.
The travis testing framework uses travis caching to mean that we don't have to reinstall firedrake every time (also the FFC kernel cache is cached, so only the first run should require building the kernels).  These need to be manually invalidated if the dependencies are upgraded (but this is a one-click thing on the travis website).
I didn't activate code linting, because most of the source tree fails it!

Currently not passing. Tester is being killed, maybe OOM?

OOM is possible, the 3d tests require quite a lot of memory. How much memory is available? We could try to reduce memory footprint by allocating only the functions that are used in each test instead of the whole 3d model. Also the high order functions used to compute L2 errors hog a lot of memory.

How can I test for lint? Is it just pylint?

The basic lint infrastructure is in https://github.com/tkarna/cofs/tree/lint

Builders have max 4GB of RAM.  Running the continuity3d tests uses a peak of ~8GB on my local machine, so that is probably the issue.

OK, makes sense. I'll try to reduce the memory footprint of continuity3d test.

We can also mark some of the tests as not to be run on travis (I will push a commit for this momentarily)

This looks good to me. If the current fixture runs we can merge.

It's getting there slowly.  I think I have fixed the timeout problems, am waiting for a green travis light.

This version e6ca0f033dd797b82c61d5faa30b25f90563d6bd of continuity3d test consumes "only" 2.7GB and might run on travis.

I spotted another memory leak problem (that is really only an issue running the test suite, rather than individual runs).  The complicated forms that we build lead to huuuuge Kernels (their in memory pickled representation can easily be 40MB).  These stick around until the end of time (end of the python process) in memory.  And every test makes more of them.  I suspect this is one of the reasons travis is unhappy.  My most recent commit hackily works around this.  Hopefully it will green-light! (https://travis-ci.org/wence-/cofs/builds/97280058)

Ok, that build ran through fine in a little under an hour. One convergence failure in tracerEq/test_steady_adv_diff_mms.py which could I guess be an actual problem. Unless it only happens in my branch and I borked something.

OK great! tracerEq/test_steady_adv_diff_mms.py passes on master, so something may be broken. Nevertheless I'd suggest that you skip that test so we can merge this. I'll go through the failing tests separately.

Ah, I see what I did.  I moved the clearing of the linProblemCache and tmpFunctionCache to a teardown method that is run once per test.  But it seems that for the convergence tests they still need to be cleared in the refinement. I've put that back in and things now pass.
I'll clean this up, then I think it's good to go.

OK, I think this is now fine.  I have some test failures, but I see those on master too, AFAICT.

Ah, that makes sense. OK, I'll go ahead then and merge.

To actually get testing running, you need to manually add the appropriate travis web hook.

Thanks, travis appears to be up and running.  ( ^_^) b


How to know which type of OS is used

What is your question?
Hello, I want to know if by using lua, we can recognise if the player is using windows 7, 10, or 11. Could we, and if yes, how can we do that ??

You definitely can't do that in Lua but I'm not sure about .hx, it can check the os of the client

Alright, thanks anyway


Added several comments to the exported types

Added several comments to the exported types (https://github.com/golang/go/wiki/CodeReviewComments)
Nothing important.

Very helpful. Thank you.


about train

how to generate text file(like 00.txt) of train?

We randomly sample the positive pairs (e.g. <3m) and negative pairs (e.g. >20m) by a ratio (e.g. 1:100) for training. And for evaluation, we remove the easy positive pairs (e.g. <3m & timestamps < 30s). You can refer to the old version code  or this repo.
Note that the ratio really matters when compared with other methods (Fig.6 in IROS'21 paper). Please keep all methods compared strictly on the same data distribution.


expose new scalar to change the visual density of fog

Description

Add a new property to adjust the visual density of fog relative to the "actual" density which also affects culling
change the default visual scalar from 0.15 to 0.4 which should make the densest fog possible right around where tiles are culled

Old default 0.15
New default 0.4

Density function details

These graphs show the density function values. The y value between 0 and 1 is used to determine the percentage for mixing the original color and the fog color. mix(originalColor, fogColor, percent)
ie. closer to 1 means more fog color
Any tile with a value greater than 1 is culled and thus not rendered
Any tile or model with a value less than 0.001 does not get any fog color at all to aid in performance, the fog would be negligible.
The red line is the "true" fog function that is calculated without any scalar. This is the one used for culling
The purple line is the fog function with the modifier included. The purple area is where fog is actually being displayed
This is the before value with a modifier of 0.15

This is the same functions with a modifier of 0.4. As you can see the fog (purple) much closer matches reaching 1 around the same time the red fog function does. This means it's visually most dense at around the same distance tiles are culled.

The density is cranked up way higher than normal to make seeing the curves clearer
Desmos link if you want to play with the values yourself
(the v value is there to exaggerate the graphs visually so you can still see the curves even if you stretch the density out really far)

Issue number and link
Part of https://github.com/CesiumGS/cesium/issues/12126

Testing plan

Open the updated Fog sandcastle and play around with the visual density scalar value

Modify the actual density with different scalar values to see how they affect each other.

Author checklist

[ ] I have submitted a Contributor License Agreement
[ ] I have added my name to CONTRIBUTORS.md
[ ] I have updated CHANGES.md with a short summary of my change
[ ] I have added or updated unit tests to ensure consistent code coverage
[ ] I have updated the inline documentation, and included code examples where relevant
[ ] I have performed a self-review of my code

This is the same functions with a modifier of 0.4. As you can see the fog (purple) much closer matches reaching 1 around the same time the red fog function does. This means it's visually most dense at around the same distance tiles are culled.

Good explanation! So for the default, we wouldn't want to go any less that 0.4 from the sound of it.
I was playing around with GE as a point of comparison, and their fog appears much denser, even than visual density equivalent of 1.0 in our system (which I think is the maximum, based on the function visualizations). What are your thoughts?

I was playing around with GE as a point of comparison, and their fog appears much denser, even than visual density equivalent of 1.0 in our system (which I think is the maximum, based on the function visualizations). What are your thoughts?

I actually think the density of our fog is about the same. But ours is much darker. Maybe this has to do with some of the atmosphere values?
This is approximately the same location in CesiumJS (with 0.4) and Google Earth. (I just noticed GE seems to put a touch of a fish eye effect on the fov?)

This is that same view with the visualDensityScalar set to 1.0. I think this looks much more dense than GE's so i'm surprised to hear you say the opposite. does this match with what you saw?

I did just notice our fog seems inconsistently applied as we zoom in and out and very close to the ground it's not applied at all which I think might be the cause of your previous comment about it not being as dense as GE. They seem to apply fog consistently across all zoom levels. Not sure the cause for this.

Yes, I was looking at a horizon few similar to this one. This is what prompted my question. I agree that from your more "aerial" screenshots, the density does read correctly at a value of 0.4.
My guess for what is causing this may be the atmosphere scattering code returning transparent colors for fog when close to the ground. Perhaps try stubbing out the atmosphere color function with one that returns a solid color for the sake of debugging. Once we identify the cause, we can figure out an implementation plan, and if it's scope.
If that's not the case, my shot in the dark is that this may be related to https://github.com/CesiumGS/cesium/issues/11922. The horizon angle is what's jumping out to me as similar.

But ours is much darker. Maybe this has to do with some of the atmosphere values?

I agree. I assume that will be out of scope for this PR. I believe the reasons for this are documented in https://github.com/CesiumGS/cesium/issues/11717#issuecomment-1889894826.

@ggetz I fixed up the couple docs issues and moved the fog sandcastle as discussed offline.
That said I'm still confused what's causing the fog to be basically non-existant close to the ground and have such a massive spike in density at a certain height. I tried swapping the fog color out for a static magenta 1, 0, 1 instead of the atmosphere color and still observe the same issues. I'm thinking it might have something to do with the depth/distance calculations? I made a slightly modified sandcastle to easily reproduce the zoom.
https://github.com/user-attachments/assets/8a65c731-5a20-4773-89f7-04e54770f58f

That said I'm still confused what's causing the fog to be basically non-existant close to the ground and have such a massive spike in density at a certain height. I tried swapping the fog color out for a static magenta 1, 0, 1 instead of the atmosphere color and still observe the same issues. I'm thinking it might have something to do with the depth/distance calculations?

Hmm, I see it as well. I wonder if we need to scale based on the camera height. For instance, here's an exponential decay function based on camera height which seems to be producing decent results:
const float maxHeight = 10000.0;
const float minHeight = 500.0;
float height = (czm_eyeHeight - minHeight) / (maxHeight - minHeight);
float heightModifier = 1.0 + exp(-decay * height);

const float modifier = 0.4;
finalColor = vec4(czm_fog(v_distance * heightModifier, finalColor.rgb, fogColor.rgb, modifier), finalColor.a);

@ggetz thank you for the pair programming on this. recapping a little here.

Ever since fog was initially implemented it's used an internal table of heights and densities at those heights that seems to be somewhat arbitrary. These were not a fully smooth curve and were the cause of the weird "spikes" in density and practically no fog near the ground that we were observing.
Those tables have been replaced with a smooth power function that somewhat closely matches the previous values.
The "magic numbers" in that new function have been exposed as a set of new properties on the Fog class to allow customization. We should have good defaults so they don't normally have to be altered but the option is there.
With this latest change I also updated the visualDensityScalar up to 1 from 0.4 which seems to have a nicer effect. We may even want to default to slightly higher.

I think the function and implementation is good now. The sandcastle has been updated with the new properties. Please play with them a little and see if you think there's a better set of default values, changing the numbers is easy.

@jjspace I did some quick network testing:

On average, the current settings are using around 1.5MB network for horizon views at various heights
To get the same network usage as in main, I used the following settings:

viewer.scene.fog.density = 0.001;
viewer.scene.fog.heightFalloff = 0.65;

What do you think of splitting the difference? This is, on average, using 0.4MB more network, and I'm still seeing increased resolution at the mid-range and closer to the camera.

viewer.scene.fog.density = 0.0006;
viewer.scene.fog.heightFalloff = 0.59;

@ggetz I think I'm fine with those values, especially if it helps with the network cost.
I was also thinking of switching the visualDensityScalar back down to 0.5 or 0.6 instead of 1 as I think 1 gets a bit too aggressivly dense at higher altitudes. Thoughts?
I'm still working through the tests, mostly value checking which these numbers but that should just be a simple value update.

I was also thinking of switching the visualDensityScalar back down to 0.5 or 0.6 instead of 1 as I think 1 gets a bit too aggressively dense at higher altitudes. Thoughts?

I did some digging into why fog is so dark, and I think that the opacity of the ground atmosphere color is not being correctly handled. If we go with something similar to the fix I have there, I think 1 works, as the fog closer to the camera will actually be pretty thin and therefor the color more transparent.  However, I doubt we could get that fix in before the next release.
If possible, I'd like to avoid breaking changes for this default. Maybe a weird idea, but what do you think of marking this value as experimental for the first release in case we want to adjust it after the fact?

@ggetz I've added tests and marked the new scalar as experimental. I think that's fine for now but I also thought that if we want to update this in the future we could switch it back to 0.15 like it was before this PR to minimize impact until we get your other fix in?

I think that's fine for now but I also thought that if we want to update this in the future we could switch it back to 0.15 like it was before this PR to minimize impact until we get your other fix in?

Sure, please change it to whatever the equivalent was for the previous behavior.

@ggetz I believe this should now have all your comments addressed

Looks good! Thanks @jjspace!


tufte-memo:0.1.1

I am submitting

[ ] a new package
[x] an update for a package

Description: In #713 a reviewer asked that I rename a variable in the template, but I failed to rename all instances of that variable leading to an error when attempting to use the template. This PR (for tufte-memo:0.1.1) addresses that mistake.

[x] ensured that my package is licensed such that users can use and distribute the contents of its template directory without restriction, after modifying them through normal use.

Thank you, and sorry to not have double-checked that everything was correctly renamed in the previous PR.


[deltalake_aws] Allow configuring separate endpoints for S3 and DynamoDB clients.

Description
aws_config supports the use of custom endpoints. This is currently exposed via the AWS_ENDPOINT_URL option and appears to be used for both DynamoDB and S3 clients.
It would be helpful if I could provide separate endpoints for DynamoDB and S3. Ideally, I would be able to pass in a DynamoDB client and an S3 client or object store directly, instead of interacting through the options hashmap full of strings.
Use Case
In my test environment, separate processes mock S3 and DynamoDB, and listen on different ports, so I cannot provide a single endpoint that does both.
Related Issue(s)

Hi @adamfaulkner-at , I am taking a look

Thank you so much!


Your server is down and the app is broken

@hkchengrex The model download URL is broken. See https://databank.illinois.edu/datafiles/i1pd9/download
Which means nothing is working with the app right now. Relevant part of the code https://github.com/hkchengrex/MMAudio/blob/main/mmaudio/utils/download_utils.py#L34
BTW I am curious why you guys are hosting this on the university server instead of a reliable and free huggingface. I think you should move to huggingface completely.

Thank you for reporting this. I've changed the links to huggingface's.
The reason is that the university guarantees long-term storage, but huggingface does not.

@hkchengrex just tried and can confirm it's fixed. Thank you!


Moved executor script capture to before artifact collection

Closes #1472

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@searsaw Pls sign the cla and cloud you provide a test case in code

Adding wontfix as there has been no activity for 6 months.

No activity in 6 months - closing.


feat: add common service with version endpoint to expose version and other info of the server

The purpose of this service is to act as a common way to expose version and build info of our services.
This will also house other common endpoints such as one to get server configurations.

@ravisuhag @AkarshSatija are we ok with service and package name common here ?

@ravisuhag @AkarshSatija are we ok with service and package name common here ?

Another one would be core?

LGTM 👍
I'll prefer common over core. core keyword looks a little restrictive and internal to the system and common looks like a utility package that is welcoming to all.


fix(menu): add marginBottom: 0 for list items

Description
Some CSS libraries/UI kits add a bottom margin to list items by default (I know it's a bad practice).
Set this up so the menu items don't look wonky when using it with those libraries, to aid users who are migrating off other UI kits.
Scope

[X] Patch: Bug Fix

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

thanks @chrisirhc !


Update OperationChainLimiter.java

Codecov Report

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

@@            Coverage Diff             @@
##             develop    #1232   +/-   ##
==========================================
  Coverage           ?   64.86%
  Complexity         ?     1453
==========================================
  Files              ?      649
  Lines              ?    20413
  Branches           ?     2510
==========================================
  Hits               ?    13240
  Misses             ?     6115
  Partials           ?     1058

Impacted Files
Coverage Δ
Complexity Δ

.../gchq/gaffer/graph/hook/OperationChainLimiter.java
94.44% <ø> (ø)
0 <0> (?)

Continue to review full report at Codecov.

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


v0.2.0-RC1 / SBUS is not working (only PPM works) / ESP32 (non mini)

Hello folks,
first of all that is an outstanding project thanks!
Currently I'm not able to use SBUS, however PPM is working, but I want to use SBUS :(.
My setup:
*Flysky FS-i6x + FSIA10B
*ESP32 (non mini)
*I changed on the remote Flysky FS-i6x & Betaflight UI to SBUS & changed the wiring of the receiver FSIA10B accordingly for SBUS

Hi @ghehssalto , can you show me the ports and receiver tabs? Which pin are you using to connect receiver? It must not be the same as ppm. You have to use serial rx pin of selected port. You can check pin assignments using cli command 'get pin'.

Hello now it's working THX!
But I have e new issue:
Every now and then it hangs completely and I have to reconnect and

then this message comes up

@ghehssalto on which port did you set the serial rx option? is this problem on reveiver tab only or all? are you able to connect to CLI? if yes, type reboot and paste result here.

@ghehssalto I forgot to mention, there are some quirks in connection to BF configurator. Usually it is impossible to connect right after flashing board. Powe cycle is required. Also if you enter CLI mode, you have to connect disconnect twice to leave. This issues shoud be eventually resolved in configurator, but it is not part of this project. Also similar issues might appear in connection of specific USB/UART chips or theirs drivers, especially when saving configuration that forces reboot.
In general I recommend:

disable auto-connect option in top of application window
disable autocomplete in configurator options

will try thx for your great support!


feat: update to drawio-desktop 21.6.5

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


Using AWS Organization + Accounts

We run multiple accounts in AWS, one is a sandbox, others serve their own purposes. Is there some way to specify which account I want terraforming to use?
I have assume_role policies set up for the key/secret key I'm sourcing in my env, so the credentials work across any of the accounts.
I'm just trying to figure out what param to feed terraforming (if it supports it) so that it knows which account's resources to hit.

Put the keys in your credentials file in ~/.aws/credentials under a profile name and use the --profile switch when calling terraform commands.

First, please know how grateful I am that a tool like this exists out there. It has been very, very useful for me for many, many years. I think I first forked this project nearly two years ago. I've been a fan ever since.
Main account ID w/ AssumeRole user:<PHONE_NUMBER>00
Managed account ID where I can AssumeRole into AccountAdministrator:<PHONE_NUMBER>11
Confirmed working:

Main account is where "myuser" is created in IAM
Set up "Trust Relationship" in Managed account
Give the AssumeRole in Managed account full Admin privileges
Successfully AssumeRole into ManagedAccount through AWS Console and administer all resources (IAM, EC2, etc)

Steps to reproduce:
Using the AWS CLI instead of Terraforming, I have a  ~/.aws/config file where I stored "myuser" AWS keys (from IAM credentials provided in the Main account. It looks like this:
[profile default]
aws_access_key_id = <REDACTED>         #myuser credential from IAM in Main account
aws_secret_access_key = <REDACTED>     #myuser credential from IAM in Main account

[profile dev-east]
role_arn = arn:aws:iam::111111111111:role/OrganizationAccountAccessRole
source_profile = default
aws_region = us-east-1

When I run the AWS CLI, it works:
╰─ aws iam list-users --profile dev-east
{
    "Users": [
        {
            "UserName": "something1",
            "Path": "/",
            "PasswordLastUsed": BLEEP,
            "CreateDate": BLEEP,
            "UserId": "BLEEP",
            "Arn": "arn:aws:iam::111111111111:user/something1"
        },
        {
            "UserName": "something2",
            "Path": "/",
            "PasswordLastUsed": BLEEP,
            "CreateDate": BLEEP,
            "UserId": "BLEEP",
            "Arn": "arn:aws:iam::111111111111:user/something2"
        }
    ]
}

I set up an identical profile in my  ~/.aws/credentials file which looks like this:
[default]
aws_access_key_id = <REDACTED>         #myuser credential from IAM in Main account
aws_secret_access_key = <REDACTED>     #myuser credential from IAM in Main account

[dev-east]
aws_access_key_id = <REDACTED>         #myuser credential from IAM in Main account
aws_secret_access_key = <REDACTED>     #myuser credential from IAM in Main account
role_arn = arn:aws:iam::111111111111:role/OrganizationAccountAccessRole
source_profile = default
aws_region = us-east-1

When I run terraforming, here's what I get:
╰─ terraforming iamu --profile dev-east
/Users/armenr/.rvm/gems/ruby-2.4.0/gems/aws-sdk-core-
2.10.28/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call': User:
arn:aws:iam::000000000000:user/myuser is not authorized to perform: iam:ListUsers on resource:
arn:aws:iam::000000000000:user/ (Aws::IAM::Errors::AccessDenied)

The really troubling part is:
arn:aws:iam::000000000000:user/myuser is not authorized to perform: iam:ListUsers on resource:
arn:aws:iam::000000000000:user/ (Aws::IAM::Errors::AccessDenied)

I get the same issue with any other type of resource - ec2, rds, etc...
It seems terraforming/AWS RubySDK is running listUsers on the<PHONE_NUMBER>00 account, instead of  assuming the role in account<PHONE_NUMBER>11, and running IAM listUsers on that account...but I don't have that problem wit the AWS CLI version of the same command.
Moreover, it seems like it's a known issue elsewhere with the way in which the AWS Client is first constructed in the RubySDK. I'm also parsing through your code and can't seem to find anything in the repo regarding Aws::STS::Client.new (creating STS client to acquire temporary AssumeRole credentials) or Aws::SharedCredentials.net (building shared credentials profile objects).
For example, in your iam_user.rb, all I see is:
      def self.tf(client: Aws::IAM::Client.new)
        self.new(client).tf
      end

      def self.tfstate(client: Aws::IAM::Client.new)
        self.new(client).tfstate
      end

I guess we'd have to build a wrapper that would initialize all user profiles by parsing ~/.aws/credentials and construct profile objects first, using a tool like:
https://github.com/a2ikm/aws_config

Then, we'd have to create an STS client

Then, we'd have to construct a credentials object

Then, we'd have to create an IAM client, passing in the credentials object.

Please forgive the code below, I'm doing most of this off of a tablet, while in transit, so it's probably totally messed up -
module Terraforming
  module Resource
    class IAMUser
      include Terraforming::Util

      def self.sts(sts_client: Aws::STS::Client.new(profile: 'dev-east')
        self.new(sts_client).tf
      end

      def self.credentials(Aws::AssumeRoleCredentials.new(
        client: client,
        role_arn: role_arn,
        role_session_name: "some_session",
        token_code: token_code
      ))
        self.new(credentials)
      end

      def

      def self.tf(client: Aws::IAM::Client.new(credentials: self.credentials))
        self.new(client).tf
      end

      def self.tfstate(client: Aws::IAM::Client.new(credentials: self.credentials))
        self.new(client).tfstate
      end

      def initialize(client)
        @client = client
      end

Basically, I'm wondering if terraforming is capable of supporting a way to AssumeRole to other account resources, in order to list them?
IF not, is it cool if I open a PR to try to work that out?

@armenr we have multiple accounts and had same issue ... see if this works for you  https://github.com/cmedley/terraforming/tree/support-assume-role  (if it does, will open PR)

@cmedley --> Thanks for that! This is clearly more elegant than any Ruby I was going to be able to hack together.
I'm gonna take this for a test drive and see how it fares. Definitely glad someone around these parts forked and wrote it before I had the chance to mutilate the code.
Thank you!

@cmedley version is not working for me using --assume

I can confirm that I was able to get it working back in August/September when he shared it to me.
I can try to test again and let you know...maybe help to repro the issue.

I will test as well and update over weekend ... need to remove the
options[:client] from cli.rb and update the tests  (but that wouldn't stop
it from working)
On Fri, Oct 13, 2017 at 9:18 PM, Armen Rostamian<EMAIL_ADDRESS>wrote:

I can confirm that I was able to get it working back in August/September
when he shared it to me.
I can try to test again and let you know...maybe help to repro the issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dtan4/terraforming/issues/356#issuecomment-336599642,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMSY38EUk4py5o68DPUD4xQChcfjcAQks5ssAvJgaJpZM4O74eh
.

@varunchandak  @armenr  created a new pull request for assume role support ... https://github.com/dtan4/terraforming/pull/379

+1

It's been 2+ years, and you guys are still helping/supporting this feature and issue. So incredibly cool to see.
//end gushy pointless post.

@dimisjim  got a PR https://github.com/dtan4/terraforming/pull/463 that adds MFA support to assume role.  Should work using terraforming s3 --profile=<your_profile> --assume=<role_arn> --mfa-serial=<mfa_arn> --token-code=<mfa_token>

@cmedley Awesome! How can I test this?

@dimisjim  can test this way
 $ git clone https://github.com/dtan4/terraforming.git
 $ cd terraforming
 $ git fetch origin pull/463/head:assume-role-with-mfa-support
 $ git checkout assume-role-with-mfa-support
 $ bundle exec rake install
 $ terraforming s3 --profile=<your_profile> --assume=<role_arn> --mfa-serial=<mfa_arn> --token-code=<mfa_token> --region=<region>

@cmedley
Ok, having some "require" difficulties with running the produced binary in terraforming/bin, I did the following:
Assuming your instructions up to the bundle exec command (+ having ran the scripts/setup prior to that) and by also editing after it:

in /path/to/terraforming/lib/terraforming.rb:

all require lines to require_relative that reference paths like terraforming/util, terraforming/version, etc.
Added Terraforming::CLI.start(ARGV) at the end of the file.

Then, having my ~/.aws/credentials file containing my default mfa profile that links to all the other accounts that it can assume a role there, I ran the command you proposed by omitting the --profile flag:
ruby /path/to/terraforming/lib/terraforming.rb s3 --assume=arn:aws:sts::<AccountIdThatDefaultAccountCanAssumeItsRole>:role/<RoleName> --mfa-serial=arn:aws:iam::<AccountIdOfDefaultAccount>:mfa/<Username> --token-code=<code> --region=<region>

This worked beautifully!
Can we proceed with merging the relevant PR #463 ?


drag-enter class isn't removed from the dragged element after the drag ends.

+1 on this, this bug appear in this example

fixed in latest


(PUP-5697) Inline file permissions to the static catalog

Inlines owner, group, and mode permissions when
source_permissions is use. Not inlined when it's ignore, and
raises an error if use_when_creating is requested.
For Windows, modified how we assert that source_permissions => use
will not be used on Windows so it's still checked for the static
catalog. Check is done client-side, as the master usually doesn't care
what OS the client is.
Also added a maint change to always set :ensure and :checksum to prompt discussion.

Should be ready, I think I've fixed the specs.

Updated. Also added confirmation of absence of warnings, and found a mistake comparing string to symbol.

:+1: for warning text

Looks good, always setting ensure to the metadata.ftype (when not using present) and warning if it doesn't match makes sense. Also setting the checksum type based on metadata seems more correct. Just have the quoting comments and then ready to merge.

Updated to quote everything.

I'm wrong about the requirement to quote owner/group. We require mode to be quoted in manifests to disambiguate mode => 755, as the language will interpret the mode as decimal (due to absence of leading 0), and that can cause surprising behavior, e.g. PUP-2156. And we removed support for non-quoted modes in PUP-2350.


Cannot open file, path = '<>/artifacts/engine/darwin-x64/vm_isolate_snapshot.bin' (OS Error: No such file or directory, errno = 2)

Flutter crash report; please file at https://github.com/flutter/flutter/issues.
command
flutter build bundle --suppress-analytics --target /Users/louisevans/StudioProjects/test_flutter/lib/main.dart --verbose --filesystem-scheme org-dartlang-root --compilation-trace-file compilation.txt --depfile /Users/louisevans/StudioProjects/test_flutter/build/app/intermediates/flutter/debug/snapshot_blob.bin.d --asset-dir /Users/louisevans/StudioProjects/test_flutter/build/app/intermediates/flutter/debug/flutter_assets --debug
exception
FileSystemException: FileSystemException: Cannot open file, path = '/Users/louisevans/Desktop/Flutter/flutter/bin/cache/artifacts/engine/darwin-x64/vm_isolate_snapshot.bin' (OS Error: No such file or directory, errno = 2)
#0      _File.open.<anonymous closure> (dart:io/file_impl.dart:364:9)
#1      _rootRunUnary (dart:async/zone.dart:1132:38)
#2      _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#3      _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#4      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#5      Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#6      Future._completeWithValue (dart:async/future_impl.dart:483:5)
#7      Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:513:7)
#8      _rootRun (dart:async/zone.dart:1124:13)
#9      _CustomZone.run (dart:async/zone.dart:1021:19)
#10     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:947:23)
#11     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#12     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#13     _runPendingImmediateCallback (dart:isolate/runtime/libisolate_patch.dart:115:13)
#14     _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:172:5)

flutter doctor
[✓] Flutter (Channel stable, v1.2.1, on Mac OS X 10.13.6 17G65, locale en-GB)
    • Flutter version 1.2.1 at /Users/louisevans/Desktop/Flutter/flutter
    • Framework revision 8661d8aecd (7 weeks ago), 2019-02-14 19:19:53 -0800
    • Engine revision 3757390fa4
    • Dart version 2.1.2 (build 2.1.2-dev.0.0 0a7dcf17eb)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/louisevans/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.1, Build version 10B61
    • ios-deploy 1.9.4
    • CocoaPods version 1.6.1

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 31.3.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[!] IntelliJ IDEA Community Edition (version 2018.2.4)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • For information about installing plugins, see
      https://flutter.io/intellij-setup/#installing-the-plugins

[✓] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 9 (API 28) (emulator)

! Doctor found issues in 1 category.

@LouisEvans are you still in this state?

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.

same problem here....

@Zheng7426 Can we get the output of flutter doctor -v?

@Zheng7426 Can we get the output of flutter doctor -v?

Hey mate, this problem has been solved. Turned out I had two paths in the $PATH file.

@Zheng7426 Can we get the output of flutter doctor -v?

@jmagman Hello, this problem has been solved. Turned out I had two paths in the $PATH file.

How did you exactly fiexd it. I'm having the exact same problem. I have built and App - > Release after that i can't even RUN the project again in Android Studio.
I get this
Launching lib/main.dart on Android SDK built for x86 in debug mode...
Running Gradle task 'assembleDebug'...
Target debug_android_application failed: FileSystemException: Cannot copy file to '/Users/eduard/Desktop/sudapp/build/app/intermediates/flutter/debug/flutter_assets/isolate_snapshot_data', path = '/Users/eduard/Desktop/flutter/bin/cache/artifacts/engine/darwin-x64/isolate_snapshot.bin' (OS Error: No such file or directory, errno = 2)
build failed.
FAILURE: Build failed with an exception.

Where:
Script '/Users/eduard/Desktop/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 882

What went wrong:
Execution failed for task ':app:compileFlutterBuildDebug'.

Process 'command '/Users/eduard/Desktop/flutter/bin/flutter'' finished with non-zero exit value 1

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 5s
Exception: Gradle task assembleDebug failed with exit code 1
Any idea ?


Fix spoiler in HW1 readme

Current dependencies on/for this PR:

main

PR #7   👈

This comment was auto-generated by Graphite.


http: rfc7230: Support slash character '/'

Some http headers like Accept[1] have a format that includes a slash
character, example: MIME_type/MIME_subtype;q=factor.
Add support to treat this slash as a regular character.
1: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept

Is this change intending only to affect the algorithms in rfc7230.hpp?

Is this change intending only to affect the algorithms in rfc7230.hpp?

Yeah, I want to parse the http Accept header, and the most straight forward iterator is to use ext_list, but none of the http iterators (ext_list, param_list, etc), handle the '/', instead they stop processing the string when they encounter one.
I noticed there's a "is_text()" function that's not currently being used. Would that be something that could be used during the string processing instead of relying just in "is_token_char()"?

Maybe the question is, could this be supported:
boost::beast::http::ext_list{"*/*,text/plain;q=1,text/html;q=0.8"}

If yes, what would be the recommended changes?
If not, which parser would you suggest, since the advantage of an ext_list is that it automatically separates the types (/,) from the factor (;q=1) so the Accept types can easily be compared to see which format the caller expects, without doing additional parsing like using boost::contains.

could this be supported:

I thought I already implemented that, but if I didn't - yes, it would be nice to have. However, you cannot change detail::is_token_char because the HTTP parser uses that, and the RFC does not allow a slash for the places where is_token_char is called from the parser. You would need to make your own function, e.g. is_ext_token_char and use that instead.


Jest test example from Chapter 15 does not work

Hi, unfortunately unit test example from chapter 15 (section Adding the test) does not work. This is the error:
TypeError: Cannot read property 'mockReturnValue' of undefined

How is importing auth from auth-helper expected to work if mocked authorization object is also defined as const auth:
import auth from './../auth/auth-helper.js' and const auth = dummyAuthObject. Doesnt this make two variables called auth?

Why isnt onRemove function passed as a prop when it is required in Post component?

Hey @90sidort,

You are right. The line const auth = dummyAuthObject does contain an error, the variable should be renamed or this line can be omitted and dummyAuthObject used directly in the example test.
The onRemove prop can be added and passed an empty function, but it's presence or lack thereof doesn't affect the specific test case. Though adding the prop would be wiser to at least clean up the test console.
There seems to be one more issue not indicated in the book about testing the Post component without the Comments section. For the version of Material-UI used in the book examples, the Textarea does not play well with react-test-renderer, so for this test code example to run you would have to comment out the Comments component present in the Post component.

You can find the working example that takes all of these into consideration, here: https://github.com/shamahoque/mern-social/commit/335ed8bfbfd5080323d578191a4562e017f03270
Thank you for taking the time and going through the example code, and pointing out these issues! This will help us add an errata for other readers.

Thank you @shamahoque for quick and detailed response. Now it works perfectly.


[ergoCubSN002] Add missing amc2c boards in network.ergoCubSN002.xml

See https://github.com/robotology/icub-firmware-build/issues/176#issuecomment-2514964433 for details. I am not sure this is the correct solution, but I guess opening a PR with a concrete proposal for a change would make it easier to discuss about this.
@valegagge @marcoaccame @AntonioConsilvio @MSECode @S-Dafarra

Hi @traversaro
It seems that this PR is somehow already subsumed by #692 for what regards the mtb4c.
Nonetheless, #692 says nothing about amc vs. am2c.

Discussing with @AntonioConsilvio, it turned out we had to use both fw, since the board is dual core. We had to flash both of them one after the other

Hi @S-Dafarra
What does this mean in terms of XML files? That we have to give it a run first with amc in the XML and then replace it with amc2c?

Hi guys,
from the works done here by Davide Tome, it seems that we need to specify both the core in order to update both.
In any case, I leave the floor to @marcoaccame, the expert of AMC board. 😺

I will edit the PR accordingly.

Actually the files were already correct! As the mtb4c changes are actually already contained in the other PR as reported in https://github.com/robotology/robots-configuration/pull/693#issuecomment-2515074257, I think we can close the PR. The only doubt is that at this point why the update of the amc boards failed in https://github.com/robotology/icub-firmware-build/issues/176#issuecomment-2514964433, ideally we should try again now, but the whole process is a bit long so that may not be immediate, thanks!

Hi @traversaro , thanks!
I just realized that I opened an issue to take trace of this issue. see please here: https://github.com/icub-tech-iit/sw-management/issues/172.
I also added the reference to this PR, and we'll take care of this task as soon as possible.

Ok, to sum up, we will stick to #692, which should be merged before 2024.11.0 is out.


HTTP endpoints, HTTP triggers and new sidebar

This is a monster Pull Request because it includes the new app sidebar as well as the HTTP endpoint/trigger work.
HTTP endpoints & HTTP triggers
Sometimes you want to subscribe to changes from an API, and we don't have an Integration for it yet. That's when you can use defineHttpEndpoint to receive webhooks, verify them, and create an HTTP Trigger.
//create an HTTP endpoint
const caldotcom = client.defineHttpEndpoint({
  id: "cal.com",
  source: "cal.com",
  icon: "caldotcom",
  verify: async (request) => {
    //this helper function makes verifying most webhooks easy
    return await verifyRequestSignature({
      request,
      headerName: "X-Cal-Signature-256",
      secret: process.env.CALDOTCOM_SECRET!,
      algorithm: "sha256",
    });
  },
});

client.defineJob({
  id: "http-caldotcom",
  name: "HTTP Cal.com",
  version: "1.0.0",
  enabled: true,
  //create a Trigger from the HTTP endpoint above. The filter is optional.
  trigger: caldotcom.onRequest({ filter: { body: { triggerEvent: ["BOOKING_CANCELLED"] } } }),
  run: async (request, io, ctx) => {
    //note that when using HTTP endpoints, the first parameter is the request
    //you need to get the body, usually it will be json so you do:
    const body = await request.json();
    await io.logger.info(`Body`, body);
  },
});

There's new sections of the dashboard that relate to this, as well as some new abilities like being able to link to Triggers from Job pages – currently only used by the HTTP trigger.
New sidebar
This change has a massive blast radius because it involved moving and renaming quite a lot of files, which then impacts the related imports. Generally it's simpler now because we ditched the dropdown breadcrumb menus, which had some nasty queries in weird routes.
Todo
Docs

[x] Merge main in
[x] Add top-level concept for HTTP Endpoint
[x] Add trigger
[ ] References

[ ] TriggerClient define
[ ] TriggerHttpEndpoint

Haven't had  the pleasure to look at this Lovecraftian work in depth yet, but wanted to suggest we squash those Prisma migrations before merging. I recall a recent issue when we didn't.


fix: added missing CSS unit when positioning the window offset to top

Description
This PR simply adds the missing px unit to the calculation of how much to offset from top. Without this, certain browsers will simply interpret the value as 0 which makes the page scroll to the top.

On mobile iOS it does not attach top property on body element. This causes the scroll is not returned back to its previous position after scroll is enabled.


Extending an Option-field

This concerns using an enum extension to extend an Option-field. Cf. https://github.com/microsoft/AL/issues/4559.
There is support for enums and enum extensions in AL as described here: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-extensible-enums. Hoewever, contrary to the answer in the issue above, as far as I see this is not of any help in extending an Option-field in e.g. the Sales Line table (table 37). An enum is an object and not just a datatype. It is quite different from an Option in this regard.
To migrate our solution from C/SIDE to AL we need to extend the Option-field 'Type' in the Sales Line with several of our own members. This would be possible if this Option-field was replaced with an enum that we could extend.
Am I right in asserting that it is not possible to extend an Option-field with an enum extension? If so: what other solutions are available to extend an Option-field? If I am wrong: how do I build an enum extension for an Option-field? I do not find any description of this in the documentation.

You can only build enum extension for enum field. Please wait until we will be able to convert selected options into enums. You can also create your Enum Requests if this is not yet requested by others


Has the new version of apache2.4 modified the configuration (application/x-httpd-php) method?

Has the new version of apache2.4 modified the configuration (application/x-httpd-php) method?
I follow https://www.php.net/manual/en/security.hiding.php
But failed, a few friends also failed

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

to ask a question, check with stackoverflow or email<EMAIL_ADDRESS>We do not check on github.


utt2spk_to_spk2utt.pl: Command not found when running toolkits/kaldi/gigaspeech_data_prep.sh

Hi, I got
toolkits/kaldi/gigaspeech_data_prep.sh: line 112: utt2spk_to_spk2utt.pl: Command not found
toolkits/kaldi/gigaspeech_data_prep.sh: utt2spk to spk2utt

when running toolkits/kaldi/gigaspeech_data_prep.sh, can you fix it?

I export the gigaspeech/s5/utils in kaldi and it works.

I export gigaspeech/s5/utils in kaldi and it works.


Try removing the declaration of '_locale'.dart(unused_element)

while this is just a hint but i think it won't cost much time developing converting this:
/// `en`
  String get _locale {
    return Intl.message(
      'en',
      name: '_locale',
      desc: '',
      args: [],
    );
  }

to
/// `en`
  /// ignore: unused_element
  String get _locale {
    return Intl.message(
      'en',
      name: '_locale',
      desc: '',
      args: [],
    );
  }

instead of manually modifying it  every time we generate the files.

Hi @OverLoadedBurden
I am not sure get it, can you give more info?
This looks like your own string key getter, generated from ARB file, not some base l10n code.

Hi @OverLoadedBurden
I am not sure get it, can you give more info?
This looks like your own string key getter, generated from ARB file, not some base l10n code.

if i run flutter pub run intl_utils:generate without "_locale":"my_locale_name" i get this warning
INFO: No @@locale or _locale field found in intl_my_locale_name, assuming 'my_locale_name' based on the file name.

but because the required field name starting with _ the dart lang will consider it a private variable.
So we as the dev's can't use it and the flutter analyze tool going to throw a warning because of it. So i suggest adding the
  /// ignore: unused_element

hint before the _locale field to prevent this warning from showing up.

If you name your ARB files as intl_en.arb (recommended) it will automatically conclude the locale from the file name and you can ignore the warning in such a case.
If you don't follow that naming convention, you should add the following key-value pair into ARB files:
"@@locale": "en"

However, if you use Flutter Intl plugin for Android Studio or VS Code and create ARB files through its commands, it will create file names as expected.

didn't know that @@locale is the same as _locale thanks.


User guide

Initial pass of the userguide for C++ specific API information. This could probably stand for a review from someone who hasn't been working exclusively on MDIO to catch important missing concepts and lacking explanations.
Also links to #8 as a placeholder until the issue is resolved.

A user guide will always be a WIP, but this is a great start!


BROKEN examples/demo-site

System Info
A lot of basic stuff is not working in v3 that worked in v2. My own summarization code broke on v3 so I went to see sample code and found the same issues.
A great example of this is the basic test example demo-site.
I made the following change in examples/demo-site/package.json:
"@xenova/transformers": "^2.0.0-alpha.3" ==> "@huggingface/transformers": "^3.2.4",

And then used "@huggingface/transformers" in examples/demo-site/src/worker.js
Broken:

Summarization w/ distilbart-cnn-6-6 -- results are blank (errors in console)
Translation w/ t5-small -- results are blank (errors in console)
Text generation w/ distilgpt2
Question answering w/ distilbert-base-uncased-distilled-squad
Code completion w/ Salesforce/codegen-350M-mono
Speech to text w/ whisper-tiny.en
Image to text w/ vit-gpt2-image-captioning
Zero-shot image classification w/ openai/clip-vit-base-patch16

Works:

Masked language modelling w/ bert-base-cased
Text classification w/ bert-base-multilingual-uncased-sentiment (warnings in console, but still works)
Zero-shot classification w/ typeform/distilbert-base-uncased-mnli (warnings in console)
Image classification w/ google/vit-base-patch16-224
Object detection w/ facebook/detr-resnet-50 (but only after multiple tries)

Who can help?
@xenova
Information

[X] The official example scripts
[X] My own modified scripts

Tasks

[X] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction
See above.
Expected behavior
To work like v2, or just to work at all.

Hi there 👋 Indeed, the demo site is relatively out-of-date. For up-to-date Transformers.js v3 demos, check out https://github.com/huggingface/transformers.js-examples.
The main reason for these demos not working is that we removed the non-standard callback_function from v2. It has since been replaced by the TextStreamer class (also present in the python transformers library).

Ah! A "breaking changes" in the announcement blog post or at least the docs would be a great addition.
I'll move the callback inside the streamer. Thanks.
Is it worth updating this example?

Oh, also the examples in the docs are wrong then.
For example: https://huggingface.co/docs/transformers.js/en/tutorials/react
    callback_function: x => {
          self.postMessage({
              status: 'update',
              output: translator.tokenizer.decode(x[0].output_token_ids, { skip_special_tokens: true })
          });
      }

Also, the new callback function seems to get text not beams, so no decode step is required.
Though I seemingly get a stop token of sorts </s>. Is this intentional?

Also, Xenova/distilgpt2 does not have d8 quant. How to just get the one name with quantized?

See https://github.com/huggingface/transformers.js/pull/1128

See #1129


chore(api): api call to get basics statistics from db

API call to get DB columns sizes
{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "dag_block_period": 50417076,
    "dag_blocks":<PHONE_NUMBER>,
    "dag_blocks_index": 75370346,
    "dag_blocks_state": 455590,
    "dag_finalized_blocks": 36878919,
    "default": 0,
    "dpos_proposal_period_levels_status": 4107,
    "final_chain_blk_by_number": 11199779,
    "final_chain_blk_hash_by_number": 1149502,
    "final_chain_blk_number_by_hash": 1146428,
    "final_chain_log_blooms_index": 6429167,
    "final_chain_meta": 4047,
    "final_chain_receipt_by_trx_hash": 306110845,
    "final_chain_replay_protection": 0,
    "final_chain_transaction_count_by_blk_number": 602068,
    "final_chain_transaction_hashes_by_blk_number": 187411265,
    "final_chain_transaction_location_by_hash": 274505932,
    "next_votes": 31135,
    "pbft_block_period": 1144615,
    "pbft_cert_voted_block": 0,
    "pbft_head": 1150,
    "pbft_mgr_round_step": 1672,
    "pbft_mgr_status": 855,
    "pbft_mgr_voted_value": 930,
    "pbft_round_2t_plus_1": 36688,
    "period_data":<PHONE_NUMBER>,
    "proposal_period_levels_map": 677467,
    "soft_votes": 20404,
    "status": 924,
    "transactions": 942920501,
    "trx_status": 280990396,
    "unverified_votes": 4960354,
    "verified_votes": 280335
  }
}

prnet cleaned-up successfully


[FEATURE] Dataloader to have a progress bar

Description
Dataloader to show a progress bar will be useful for larger dataset.
Expected behavior with the suggested feature
Whenever call data_set_name.load_pandas/spark_df, shows the progress bar

Ha this is a great idea 💯

I have an example of this in the context of the lightgbm work easily enough if we are ok with adding another dependency such as tqdm. https://pypi.org/project/tqdm/ (see the urlretrieve example on that page).

eh - that leaves a lot to be desired in a notebook. Really need a widget instead.

hmmm... databricks is a really cool tool, but at the same time it is not very seamless experience when moving from jupyter notebooks even they both look the same...

Fixed in https://github.com/Microsoft/Recommenders/pull/642


google maps links in the info windows

Hi,
is it possible to remove the Google maps links in the Standard info Windows?
Or can i disale them somehow?
Greetings and thanks

I have been searching for a similar thing, and the latest Google Experimental API does allow suppression of the info windows.
Link to Google Experimental API reference
I guess MapOptions would need to be updated to allow setting of the clickableIcons property IF this feature makes into the next stable API release.
See this discussion on StackOverflow for more info.

@GeoffCapper @rterp  This issue can now be closed as the fix has been merged.

Any chance we can get a release, that includes this fix? Clicking on the View on Google Maps links in the Info Windows, causes all kinds of problems, and so it would be nice to disable them.

@vewert The repo is basically abandoned by the owner now it seems, but as it has been fixed in master you could compile the jar from source and include that in your project instead of using the official maven release.

@jackodsteel Thanks for the info (and for your fix)! That's too bad that this repo has been abandoned. I'll give your suggestion about compiling my own jar a try.


Title: Implement Redis-backed Circuit Breaker

Overview
This pull request introduces a Redis-backed implementation of our circuit breaker pattern. The new RedisCircuitBreaker extends the existing CircuitBreaker functionality by storing state information in Redis, allowing for distributed state management across multiple instances of an application.
Key Changes:

Added RedisCircuitBreaker struct that embeds the original CircuitBreaker.
Implemented RedisClientInterface for Redis operations abstraction.
Created RedisSettings to configure the Redis-backed circuit breaker.
Implemented RedisState struct to represent the circuit breaker state in Redis.
Added helper methods for Redis state retrieval and updates.

This implementation allows for:

Distributed state management across multiple application instances.
Fallback to in-memory state if Redis is unavailable.
Consistent circuit breaker behavior in distributed environments.

Testing:

Unit tests have been added to verify the Redis-backed functionality.
Integration tests with a Redis instance are included to ensure proper state management.

Performance Considerations:

Redis operations are performed for each state check and update, which may introduce some latency.
Caching mechanisms could be considered in the future to optimize performance if needed.

Next Steps:

Review the implementation for any potential race conditions or edge cases.
Evaluate the need for additional configuration options, such as Redis connection pooling or timeout settings.

This feature enhances our circuit breaker implementation by providing a distributed state management option, making it more suitable for use in distributed systems and microservices architectures.

Thank you for your PR.
The latest implementation is under v2 directory. Could you move this change to v2?

@YoshiyukiMineo I have move the implementation under v2. Could you please review it?

Hi reviewers, I've addressed the previous feedback. Would appreciate another look when you have a chance. Thanks!

Thanks. I have merged your PR into distributed branch temporarily. I will merge it into master after some slight change.

Could you please add the tag as well? So that we can download the implementation through go modules.


Consider make path_to_c and os_str_to_c public

https://github.com/gtk-rs/glib/blob/master/src/translate.rs#L422-L486
cc @GuillaumeGomez, @sdroege

:+1:

Maybe this actually unneeded.
In case https://github.com/gtk-rs/cairo/pull/294 it will be not usable as it can unneeded non-optional dependence (https://github.com/gtk-rs/cairo/pull/294#issuecomment-561648241),
and if glib is used, user can just get Option<Stash<xx,GString>> with to_glib_none

Indeed, what I had in mind was more about letting users having access to it. But it'd be pretty useless in itself...

Users already have access to it via FromGlibPtr on Path/etc :)


Support ingame names as a parameter for !join

Hello,
it would be great if the Bot would support an optional ingame name for a queue.
It would be perfekt if that option could be enforced per queue so thats not possible to join without the arguement.
Greets
cpuesser

Certainly seems like an interesting feature. I'll take it on board and see how it turns out after some design iterations.

I've implemented and closed this. I think it turned out pretty neat. You can check the updated manual in the README.
I haven't made the setting to enforce it though, we'll see if we need it.


Problem logging with non ascii characters in the password

also see this: https://code.google.com/p/connectbot/issues/detail?id=516

Adding description, since Google code URL is no longer valid.
What steps will reproduce the problem?

Change your password the one that includes non-ASCII characters, like é,   ł, đ, etc.
Try to log in with password authentication.
You'll get a password failed message.
What is the expected output?
What do you see instead?
You should be able to log in with a correct password, even if it contains   non-ASCII characters. Instead, you get a password failed message in   ConnectBot and in the security log of the host.
What version of the product are you using (you can see this by using Menu -> About in the Host List)?
v1.7.1 2010.10.08 It's the most recent version from the Market as far as I know.
What type of system are you trying to connect to? I tried to connect to Ubuntu 11.04 and Fedora 15. These systems use UTF-8 encoding, just like ConnectBot.

Looking at the sources, it looks like a problem in   src/com/trilead/ssh2/packets/PacketUserauthRequestPassword.java line 62,   tw.writeString() is not using whatever the current code page is set to.   Same for the username. In general it is utf-8 but let's not assume that. The problem is in src/com/trilead/ssh2/packets/TypesWriter.java line 139,   it's assuming ISO-8859-1 all the time. I guess PacketUserauthRequestPassword should be constructed with the   connection's encoding and encodes the string in the correct code page   itself. Does this makes sense?

I found that the problem was with the locale on the remote machine. Setting LANG to en_ US.UTF-8 (or any other utf8 locale I suppose) fixed my issue.


CLI: Add NTs/NFTs/Aliases/Foundries to addresses overview

Description
Add NTs/NFTs/Aliases/Foundries to addresses overview
https://github.com/iotaledger/iota-sdk/pull/259#discussion_r1166529957
Probably should reuse something from the account.balance() method
Motivation
Better visibility of what belongs to which address
Open questions (optional)
Do we want to have the full balance object for every address or is that too large?
Are you planning to do it yourself in a pull request?
No.

Closed by https://github.com/iotaledger/iota-sdk/pull/1179


Unexpected token error using Browserify with standard HTML element as tag

I'm experimenting with standard elements, but browserify (running riotify and babelify transforms) fails to build when I include the tag in the build. I have a file menu-user.tag which contains

Running browserify, I get:
Error: Parsing file C:\Github\MetaMap\src\tags\menu-user.tag: Unexpected token (2:0)
    at Deps.parseDeps (C:\Github\MetaMap\node_modules\browserify\node_modules\module-deps\index.js:437:28)
    at fromSource (C:\Github\MetaMap\node_modules\browserify\node_modules\module-deps\index.js:376:44)
    at C:\Github\MetaMap\node_modules\browserify\node_modules\module-deps\index.js:370:17
    at ConcatStream.<anonymous> (C:\Github\MetaMap\node_modules\browserify\node_modules\concat-stream\index.js:36:43)
    at ConcatStream.emit (events.js:129:20)
    at finishMaybe (C:\Github\MetaMap\node_modules\browserify\node_modules\readable-stream\lib\_stream_writable.js:460:14)
    at endWritable (C:\Github\MetaMap\node_modules\browserify\node_modules\readable-stream\lib\_stream_writable.js:469:3)
    at ConcatStream.Writable.end (C:\Github\MetaMap\node_modules\browserify\node_modules\readable-stream\lib\_stream_writable.js:436:5)
    at DuplexWrapper.onend (C:\Github\MetaMap\node_modules\browserify\node_modules\readable-stream\lib\_stream_readable.js:537:10)
    at DuplexWrapper.g (events.js:199:16)

Removing riot-tag="menu-user" allows browserify to succeed, but obviously I cannot mount it.
I'm using the latest versions of all packages as of the time of this writing. Since this isn't a browser issue, jsFiddle isn't suitable for demonstrating a simplified test case--but I'm happy to provide one wherever it's most convenient for you.

I updated to Riot 2.1.0 today, and the error I reported above is no longer reproducible. I can successfully compile the above example.

Ok awesome thanks


Check box disappears while navigating pages in Apex Tabular form 12192:61

Just saw the checkboxes on the left most column disappears when I click on the pagination..
Initial Page load

After clicking on page 2

not sure if that's the functionality

It's a bug, thank you for logging an issue. I'll look into it.


Update draft.lua to version 0.16.0

Version 0.16.0 of Draft was realeased, please update it to be able to install it using GoFish.

Looks like the windows checksum verification failed: https://ci.appveyor.com/project/bacongobbler/fish-food/build/171
Mind taking a look into that? Thanks!

@bacongobbler it looks like they are linking the wrong sha256 and wrong version in the releases page, I updated now to the correct one :+1:

I just noticed that and fixed the typo. I'm one of the Draft maintainers ;)
Thanks!

Nice! :) Thank you!