Package Homer

Project description

A dead simple static HOMepage for your servER to keep your services on hand, from a simple yaml configuration file.

Homer is a homepage to link to other hosted services.
As the configuration is all done in YAML, it shouldn't be too hard to represent in a Nix derivation.
Metadata

homepage URL: https://github.com/bastienwirtz/homer
source URL: https://github.com/bastienwirtz/homer
license: Apache-2.0
platforms: linux, maybe unix & darwin

I managed to package it, the only issue is, that it's just a static site basically?
It doesn't have a binary or anything. What would you like to do with it? I can send the expression for it if you want.

I was thinking about trying out homer too. Please post if you don't mind 👍

Again, it is just a static site with html/js/css, you can get it already built from homer's releases on github. It does not have a binary.  Take a look at this: https://github.com/pborzenkov/nix-config/blob/master/nixos/machines/rock/dashboard.nix

Oh I thought you had to "build" it with your custom yaml file. Is that yaml file read at runtime?

I believe it is, yes.

Oh... lol. Since fetchzip exists so we'll consider this "packaged" already.
@hacker1024 please feel free to ping if you need a hand running this at all.

i agree, that using fetchzip is simple, but on the other hand the application has to be updated by yourself manually every now and then.

i would welcome this as a package in nixpkgs. Therefore I will reopen it.

Does anyone have any advice on how to get this working? I looked at the linked repo but I had trouble replicating their setup: I am new to nixos and haven't messed around much with custom derivations yet so I assume I am missing some crucial step (I could not get around a "the option 'pkgs' does not exist" error.)
@aanderse are you still offering help with this?

Perfect timing @estaroc - I just got round to setting this up yesterday. This is my WIP Homer derivation and setup. Once I'm happy with it, I'll submit a PR to Nixpkgs, but I'm not 100% I like the API yet. Regardless, it should be enough to get you started now.
First, the Homer derivation. Unlike other solutions online, this uses symlinkJoin for adding assets, allowing the base Homer derivation to remain unmodified during use.
pkgs/homer.nix
{ lib, fetchzip, writeTextFile, runCommandLocal, symlinkJoin }:

let
  homer = fetchzip rec {
    pname = "homer";
    version = "22.11.2";
    url =
      "https://github.com/bastienwirtz/${pname}/releases/download/v${version}/${pname}.zip";
    hash = "sha256-kqD7hm4W51MTSxiYd+6O8Dbnf3c3E60av7x0HYVcAPQ=";
    stripRoot = false;

    passthru = {
      withAssets = { name ? null, config, extraAssets ? [ ] }:
        let nameSuffix = lib.optionalString (name != null) "-${name}";
        in symlinkJoin {
          name = "homer-root${nameSuffix}";
          paths = [
            homer
            (writeTextFile {
              name = "homer-configuration${nameSuffix}";
              text = builtins.toJSON config;
              destination = "/assets/config.yml";
            })
          ] ++ lib.optional (extraAssets != [ ])
            (runCommandLocal "homer-assets${nameSuffix}" { }
              (builtins.concatStringsSep "\n" (map (asset: ''
                mkdir -p $out/assets/${dirOf asset}
                ln -s ${asset} $out/assets/${asset}
              '') extraAssets)));
        };
    };
  };
in homer

Next, the derivation can be added in a Nixpkgs overlay, like so:
configuration.nix
{
  nixpkgs.overlays = [
    (self: super: {
      homer = super.callPackage ./homer { };
    })
  ];
}

Finally, you can create a customized Homer derivation like so. This can then be used as a directory root for a Web server.
pkgs.homer.withAssets {
  name = "homelab";
  config = {
    /* https://github.com/bastienwirtz/homer/blob/main/docs/configuration.md */
  };
  extraAssets = [
    /* Any extra assets (such as icons) to include.
    /* These can be referenced through "assets/" in the Homer configuration. */
  ];
}

for the config it might be nice to have the options with something like:
https://github.com/Stunkymonkey/nixos/blob/master/modules/services/homer/config.nix

Oh... lol. Since fetchzip exists so we'll consider this "packaged" already.

It would be nice to build this properly from source, to allow easy modifications. This is tricky at the moment, though, as it's a non-binary Yarn project and there's not much support for this in Nixpkgs.

Just tried this myself. For anybody else, Homer has recently switched to pnpm, and so you'll want a script like this:
{ lib
, fetchFromGitHub
, pnpm
, nodejs
, pkgs
, config ? {}
}:

let
  formatYaml = pkgs.formats.yaml { };
  yaml-conf = formatYaml.generate "config.yml" config;
in pkgs.stdenv.mkDerivation rec {
  pname = "homer";
  version = "24.10.1";
  src = fetchFromGitHub {
    owner = "bastienwirtz";
    repo = "homer";
    rev = "v${version}";
    hash = "sha256-9OuX32p9eEmyR7af8rIRYUvc1wmmgrYfJXsmChV9D+k=";
  };

  pnpmDeps = pnpm.fetchDeps {
    inherit pname version src patches;
    hash = "sha256-5unoY8lPaX9sZAJEBICpxSddwLV8liK1tbamB2ulvew=";
  };

  patches = [ ./sass-embedded.patch ];

  nativeBuildInputs = with pkgs; [
    nodejs
    dart-sass
    pnpm.configHook
  ];

  buildPhase = ''
    runHook preBuild
    export SASS_EMBEDDED_BIN_PATH="${pkgs.dart-sass}/bin/sass"
    pnpm build
    runHook postBuild
  '';

  installPhase = ''
    runHook preInstall
    mkdir -p $out
    cp -R dist/* $out/
    cp -r ${yaml-conf} $out/assets/config.yml
    runHook postInstall
  '';
}

sass-embedded.patch

diff --git a/package.json b/package.json
index f121431..97f1b11 100644
--- a/package.json
+++ b/package.json
@@ -28,5 +28,10 @@
     "vite-plugin-pwa": "^0.20.5"
   },
   "license": "Apache-2.0",
-  "packageManager"<EMAIL_ADDRESS>+  "packageManager"<EMAIL_ADDRESS>+  "pnpm": {
+    "patchedDependencies": {
+      "sass-embedded": "patches/sass-embedded.patch"
+    }
+  }
 }
diff --git a/patches/sass-embedded.patch b/patches/sass-embedded.patch
new file mode 100644
index 0000000..f941a8e
--- /dev/null
+++ b/patches/sass-embedded.patch
@@ -0,0 +1,15 @@
+diff --git a/dist/lib/src/compiler-path.js b/dist/lib/src/compiler-path.js
+index ae33aa3028e1a120d9e84b043bb19a71f1083b96..7a49d16a54982312ad638632d6750d7bec670f02 100644
+--- a/dist/lib/src/compiler-path.js
++++ b/dist/lib/src/compiler-path.js
+@@ -24,6 +24,10 @@ function isLinuxMusl(path) {
+ }
+ /** The full command for the embedded compiler executable. */
+ exports.compilerCommand = (() => {
++    const binPath = process.env.SASS_EMBEDDED_BIN_PATH;
++    if (binPath) {
++        return [binPath];
++    }
+     const platform = process.platform === 'linux' && isLinuxMusl(process.execPath)
+         ? 'linux-musl'
+         : process.platform;
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index 4c4267a..fd278e1 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -4,6 +4,11 @@ settings:
   autoInstallPeers: true
   excludeLinksFromLockfile: false

+patchedDependencies:
+  sass-embedded:
+    hash: 6wjvcsryx2tfkpottp4wf5nbzi
+    path: patches/sass-embedded.patch
+
 importers:

   .:
@@ -26,7 +31,7 @@ importers:
     devDependencies:
       '@vitejs/plugin-vue':
         specifier: ^5.1.4
-        version: 5.1.4(vite@5.4.9(sass-embedded@1.79.5)(sass@1.79.5)(terser<EMAIL_ADDRESS>+        version: 5.1.4(vite@5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass@1.79.5)(terser<EMAIL_ADDRESS>       '@vue/eslint-config-prettier':
         specifier: ^10.0.0
         version: 10.0.0(eslint<EMAIL_ADDRESS>@@ -44,13 +49,13 @@ importers:
         version: 3.3.3
       sass-embedded:
         specifier: ^1.79.5
-        version: 1.79.5
+        version: 1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi)
       vite:
         specifier: ^5.4.9
-        version: 5.4.9(sass-embedded@1.79.5)(sass<EMAIL_ADDRESS>+        version: 5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass<EMAIL_ADDRESS>       vite-plugin-pwa:
         specifier: ^0.20.5
-        version: 0.20.5(vite@5.4.9(sass-embedded@1.79.5)(sass@1.79.5)(terser@5.35.0))(workbox-build<EMAIL_ADDRESS>+        version: 0.20.5(vite@5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass@1.79.5)(terser@5.35.0))(workbox-build<EMAIL_ADDRESS>
 packages:

@@ -3516,9 +3521,9 @@ snapshots:

   '<EMAIL_ADDRESS>{}

-  '@vitejs/plugin-vue@5.1.4(vite@5.4.9(sass-embedded@1.79.5)(sass@1.79.5)(terser@5.35.0))(vue@3.5.12)':
+  '@vitejs/plugin-vue@5.1.4(vite@5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass@1.79.5)(terser@5.35.0))(vue@3.5.12)':
     dependencies:
-      vite: 5.4.9(sass-embedded@1.79.5)(sass<EMAIL_ADDRESS>+      vite: 5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass<EMAIL_ADDRESS>       vue: 3.5.12

   '<EMAIL_ADDRESS>@@ -4693,7 +4698,7 @@ snapshots:
<EMAIL_ADDRESS>     optional: true

-<EMAIL_ADDRESS>+  sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi):
     dependencies:
       '@bufbuild/protobuf': 2.2.0
       buffer-builder: 0.2.0
@@ -4975,18 +4980,18 @@ snapshots:

<EMAIL_ADDRESS>{}

-  vite-plugin-pwa@0.20.5(vite@5.4.9(sass-embedded@1.79.5)(sass@1.79.5)(terser@5.35.0))(workbox-build@7.1.0)(workbox-window@7.1.0):
+  vite-plugin-pwa@0.20.5(vite@5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass@1.79.5)(terser@5.35.0))(workbox-build@7.1.0)(workbox-window@7.1.0):
     dependencies:
       debug: 4.3.7
       pretty-bytes: 6.1.1
       tinyglobby: 0.2.9
-      vite: 5.4.9(sass-embedded@1.79.5)(sass<EMAIL_ADDRESS>+      vite: 5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass<EMAIL_ADDRESS>       workbox-build: 7.1.0
       workbox-window: 7.1.0
     transitivePeerDependencies:
       - supports-color

-  vite@5.4.9(sass-embedded@1.79.5)(sass@1.79.5)(terser@5.35.0):
+  vite@5.4.9(sass-embedded@1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi))(sass@1.79.5)(terser@5.35.0):
     dependencies:
       esbuild: 0.21.5
       postcss: 8.4.47
@@ -4994,7 +4999,7 @@ snapshots:
     optionalDependencies:
       fsevents: 2.3.3
       sass: 1.79.5
-      sass-embedded: 1.79.5
+      sass-embedded: 1.79.5(patch_hash=6wjvcsryx2tfkpottp4wf5nbzi)
       terser: 5.35.0

   vue-eslint-parser@9.4.3(eslint@9.12.0):
--
2.47.0

can someone please look at #368594. and evaluate if this might help others.


Update README.md

Added Awesome Mainframe Hacking

how to hack Facebook code

Cony Zacariaz

Hola que asíendo flakita es rmosa linda bonita

Thank you for the contribution !

Always, I will have to get on my desktop tomorrow to update my readme. Goodnight everyone


ensure no confirmed tx in mempool data

Fixes issue where confirmed and unconfirmed balance overlaps and reports incorrectly.

ref: https://github.com/KomodoPlatform/atomicDEX-API/issues/1254#issuecomment-1100747092

What this PR does is compare the unspent & confirmed tx for a scripthash against the electrum mempool data so that no confirmed tx are counted in the cunconfirmed balance (there seems to be some delay or race condition which means after a block is mined, sometimes a tx from within that block is still temporarily seen as being in the mempool by electrum.
This works fine for incoming funds. After further testing, there is still an issue with outgoing funds, because while they might lag in the mempool, they are no longer visible in the scripthash's confirmed & unspent txids (because, they were spent!).
Isolating these tx are not so simple, so this PR is only a partial fix. Works for incoming, not for outgoing.

@cipig would you consider this partial fix worth merging, with a more complete fix to be addressed in a future PR?

@cipig would you consider this partial fix worth merging, with a more complete fix to be addressed in a future PR?

sure, i already use this change on the electrum servers ;-)


Improvement In HexCodeGenerator.

I'm looking to improve the designing system of Hex-Code UI as currently with present code. While clicking on the gradient button it card container suddenly getting increased.
Refer this attachment for what I have changed.

My Update changes

go for it @Kumar-Ankit56 👍

Can you assign it to me under SWOC 23


Finalize onWill|DidCreate|Rename|DeleteFile apis

This PR fixes #43768

@mjbvz This API has already been discussed but please give it a quick read and thought


Reexport parser::Pointer at the crate's top level

Fixes #248
r? @philipc

Coverage remained the same at 0.0% when pulling df69be32275fb240c34f42c8b7c87caa8cdd6030 on fitzgen:expose-pointer into 9fd128d3b762ef3885d18539b9d9438d6c82a3b9 on gimli-rs:master.


Better Subnets support

Here some ideas to improve Subnets support (in addition to #1097)

When adding a network, we probably don’t need the check box "This is a subnet" since this information can be obtained on the already called /v2/info endpoint if there is a property parent_network_id

We might want a united way to pass networks to the URL, for example:

this work:
/txid/ST2P8G9R5DQGCSVAQ5YTZ2XGC7X1421W8NC6VB26A.parfait-nft?api=https://api.testnet.hiro.so/
this doesn't:
/txid/ST2P8G9R5DQGCSVAQ5YTZ2XGC7X1421W8NC6VB26A.parfait-nft?api=https://api.subnets.testnet.hiro.so/

Thanks Hugo, lets close this one for now and reopen it if subnets became more relevant


feat: add repository provider

Adds a new provider to get information about the used repository.
Required for a replacement of bazebuild/rules_k8s.
See https://github.com/realtimetodie/rules_k8s, a (possible) candidate for bazel-contrib/rules_k8s 🎉
Related

https://github.com/bazelbuild/rules_k8s/issues/722
https://github.com/bazelbuild/rules_k8s/issues/723

is there a way to do this without using providers? I don't see us adding providers as we don't depend on them anywhere. It also expands the surface we must worry about when making changes.

One way I see this could be placed is a common target that stamps out the repository information which in turn can be passed to oci_push and some other rule that depends on this information.

Everything that enables access to the repository information is fine 👍

Everything that enables access to the repository information is fine 👍

you can do this today by simply doing;
stamping_rule(
  name = "repository",
  repository = "..."
)

oci_push(
  repository = ":repository"
)

some_other_rule(
  repository = ":repository"
)

I understand, but a Kubernetes manifest can contain multiple images that can point to different registries.
Example
load("@rules_k8s//k8s:defs.bzl", "kubectl_apply")
load("@rules_oci//oci:defs.bzl", "oci_image", "oci_push")

oci_image(
    name = "image",
    architecture = "amd64",
    entrypoint = ["/example"],
    os = "linux",
)

oci_push(
    name = "push_image1",
    image = ":image",
    remote_tags = ["v1"],
    repository = "index.docker.io:9899/janedoe/awesomeapp",
)

kubectl_apply(
    name = "pod",
    images = [":push_image"],
    manifest = "pod.yaml",
)

I see. oci_push prints the reference of the pushed image to stdout. you can get the information that way too.

This will not work because the oci_push rule is never run. The Bazel run command is used to build and run a single target. Unlike previously, the new rules_k8s does not run multiple actions sequentially. It only executes the kubectl tool for communicating with a Kubernetes cluster's control plane.

This will not work because the oci_push rule is never run. The Bazel run command is used to build and run a single target. Unlike previously, the new rules_k8s does not run multiple actions sequentially. It only executes the kubectl tool for communicating with a Kubernetes cluster's control plane.

then why do you need oci_push targets at all? if they are never run. How do you make sure that the image is pushed upstream and safe to pull?

then why do you need oci_push targets at all? if they are never run. How do you make sure that the image is pushed upstream and safe to pull?
also, what would be the purpose of this provider if all you need is a repository string which can be shared between targets?

I understand and this is a valid point. The weird thing about bazebuild/rules_k8s was, that it pushed images independently from rules_docker. It was a seperate implementation. This is bad design in my opinion.
https://github.com/bazelbuild/rules_k8s/blob/fee80eb69e1921c076167ebebcf5eea3d2e9c707/k8s/go/pkg/resolver/resolver.go#L286
The new rules_k8s should not maintain a separate implementation of the rules_oci push rule. What if we make the implementation of the rules_oci push rule public and convert it so that it uses ctx.action.run instead of returning DefaultInfo? Let me know what you think (dummy code)
load("@rules_oci//oci:defs.bzl", "push_image_impl")

def _kubectl_apply_impl(ctx):
    ...
    for image in images:
        files = push_image_impl(ctx)
        runfiles = runfiles.merge(files)
    ...

However, I want to point out that making the rules_oci push rule implementation public will not solve the problem of the missing repository information. The repository information is required to construct the registry URL in the manifest. This is how it worked before and would like to keep this API as it is very convenient
Source manifest
image: janedoe/awesomeapp

Resolved manifest
image: index.docker.io:9899/janedoe/awesomeapp

The new rules_k8s should not maintain a separate implementation of the rules_oci push rule. What if we make the implementation of the rules_oci push rule public and convert it so that it uses ctx.action.run instead of returning DefaultInfo

there's no difference between getting files from DefaultInfo of oci_push versus calling the implementation function, which would require you to declare the attributes in your rule.
I still don't get why you need to run oci_push yourself as an action as part of the _kubectl_apply rule?  what you need is a full reference to the image repo@digest which is already provided when you run oci_push which _kubectl_apply rule can do there.

image: index.docker.io:9899/janedoe/awesomeapp

don't you need at least :tag or @digest here?

don't you need at least :tag or @digest here?

I thought about using crane's digest command, but this would require information about the image's repository too
https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_digest.md
What do you think? I'm not sure how to run the rules_oci push rule from within the kubectl_apply rule

as far as I can tell what you need is;
# object.yaml
- kind: somek8s/kind
   template:
      image: image/repository@to_be_replaced

kubectl_apply(
   template = "object.yaml",
   substitutions = {
      ":label_to_oci_push": "image/repository@to_be_replaced"
   }
)

at analysis time

construct runfiles by including every oci_push target in the substitutions attribute

at runtime

run every oci_push target and collect the digest printed to stdout but keep a map of which digest belongs to which substitution
apply the substitution to the object.yaml file
kubectl apply the resulting yaml file.

I'm not sure how to run the rules_oci push rule

here's one of our tests which runs oci_push target in another bash script. https://github.com/bazel-contrib/rules_oci/blob/main/examples/push/test.bash

@realtimetodie does that answer your question?

@realtimetodie does that answer your question?

The substitution idea is ugly and I don't like it. What I want to achieve is a lightweight re-implementation of bazelbuild/rules_k8s with the same convenient API, but without the fat gopher tools. Are there any stronger arguments against the provider other than that it expands the surface? Providers are a common way to mutually exchange data between Bazel rulesets.
Alternatively, we could also expand the provider and make it more universal. My suggested implementation only covers the requirements of the new rules_k8s. To make it clear, the ultimate goal is to make rules_oci and the new rules_k8s work with Tilt again
https://docs.tilt.dev/integrating_bazel_with_tilt.html

@alexeagle

Are there any stronger arguments against the provider other than that it expands the surface? Providers are a common way to mutually exchange data between Bazel rulesets.

Not expanding the API surface is a good enough argument for not introducing a new provider as a "convenience".  It's also worth mentioning that the repository attribute is string now but it will become an attr.label once we introduce stamping for it too.  If I add this provider now, then I will have to worry about too many things once we do it.
you can already do this and you do not need a new provider to do it. I am not trying to give you a hard time here but I don't think I'll agree to adding this.

@thesayyn I still don't understand why this was rejected. There is no logic behind the reasoning. Now I have to maintain multiple forks for clients with a patched version of rules_oci. It's so tiresome. Sad.

The logic was pretty clear from what I can tell: we want to have a bare minimum in this repo, so if something is possible already, the preference is not to add anything.
There is a case to be made for convenience features over time, especially as we get more mature so there is less chance of churn. I'll reopen this so we can keep discussing.

That said, it's better to start with an issue than a PR, to focus discussion on the problem rather than one proposed solution, and come to agreement that the problem even exists.

I'll explain why this is not needed and not the right thing to do again;
1- repository information is provided when you run the oci_push as part of another rule; eg run oci_push wrapper and capture the stdout which only contains full reference to the image.
2- repository attribute is a string for now but soon we'll make it stampable too, when that happens it'll become a label and we'll have to worry about how to make that file available and wait for downstream dependents to change their implementation or simply forced to make a breaking change warn users about that. hence my concern about expanding the public API. this is one of the goals of rules_oci here; https://github.com/bazel-contrib/rules_oci#bazel-rules-for-oci-containers
3- you mentioned that you don't want to run oci_push targets, but how do you propose making sure that the repository string that you are depending on is already pushed upstream? original rules_k8s has been done by having a go binary that pushes the image.  However, you don't need to use the same approach here; it can just be a simple bash script invoking oci_push target and doing some replacements over the k8s manifest.
all that said; if i am willing to contribute to your effort directly, to demonstrate how this can be done without relying on complex go pushers, simply with a bash script using yq.

@realtimetodie I'm going to close this as I don't think we'll merge as is - but I don't mean to discourage you at all! We'd love to have a path for rules_k8s users that doesn't rely on rules_docker and happy to have your contributions here.
Let's start with an issue thread about the design problem next time.

Hey all,
Sorry @alexeagle to reopen the thread, I did not want to create an issue specific for my comment..
I am migrating rules_helm to use rules_oci. So far, i have successfully used the oci_push run target as mentioned by @thesayyn in helm_install rule. So far so good :)
But for helm_package.. it's about "building" a archive containing manifests with images descriptors not yet pushed
So how it is possible to make a bazel build //my-awesome-helm-chart that will contains the potentially not yet pushed images descriptors ? Images that might be pushed later via oci_push (or via the rule helm_install as explained before)
Thanks
Olivier

going to close as not planned and there are feasible ways to do this already.

One missing piece is that it should be possible to render that reference without actually performing the push, which implementations on top of oci_push might want to leverage in order to avoid pushing more than necessary, or depending on specific contexts.

reference without actually performing the push

Nothing will be sent over the wire if the image is already pushed. That said, you still need to make sure the image is available on the remote in order to produce a correct manifest.

That said, you still need to make sure the image is available on the remote in order to produce a correct manifest.

No I don't need : let me take an example
I can deploy a new manifest with a not yet available image. It will ends up with an imagePullBackOff and that's OK : because during this time the old pod can still running, in order to not stop the business behind. Then when the new image is available, the new pod will start smoothly, and we can stop the old one.
So, it's perfectly fine to build a manifest, without having having the image pushed yet.

Could you please explain how ‘imagePullBackOff’ is okay?

Now you see, we are talking about an edge case rather than a common case. If you don't want the images to be pushed in order to get a reproducible reference with a digest then you can always pass the repository information down to the other rule directly instead of making oci_image relay/reexport this information.
A few ways to do this since you are not concerned about the existence of the image;
1- use a starlark variable
REPOSITORY="myrepo"
oci_push(repository = REPOSITORY)
whatever_rule(repository=REPOSITORY)

2- use a file and pass the label to both rules.
write_file(name = "repository", content  = "myrepo")
oci_push(repository = ":repository")
whatever_rule(repository=":repository")

3- add a repository-aware push rule to the downstream ruleset and replace oci_push with that.
# exports ImageRepositoryInfo alongside DefaultInfo
 oci_noop_push()

I'll reiterate what I said earlier and some more.
1- our approach with rules_oci is to keep it stupid simple and I can't do that if I am adding "convenience" features all over the place. my goal is to avoid that.
2- I believe I have given enough examples that cover both common and edge cases but I'll I hear people insisting that we add another way to get a piece of information that is already accessible in multiple ways.
3- "rules_oci" is a barebones ruleset meaning you can always extend on top of it. you can always a wrapper rule in whatever ruleset to add this provider.
As far as rules_oci is concerned, this is an implementation detail of a downstream ruleset, and should not be carried responsibility for rules_oci.
NOTE: my main priority is to not add something new here.

I don't want to convince you to accept this pull request, i would not accept it like you do.. because as you explained, it's a behaviour we can implement by extending the rule, and I have migrated helm_install from the rules_helm project thanks to your advice already.
My question was not about if it is possible or not, but more when in the bazel process we can achieve this : basically to get the digest during the build phase in order to keep the same behaviour as it is currently in rules_helm with the helm_chart rule.
I see is that the oci_image rule is building a index.json containing the digest to grab, so i will invest in this direction.
Thanks for your support, you challenged and that helped me.

Great. I am on Bazel Slack if you'd like to chat about it more. For now, I am going to lock this discussion to prevent further conversation here. Please file an issue if you'd still like to discuss further.


[Feature Request]: Adding GSAP animation to the navbar and body for better UI engagement

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Problem  : Current  Website does not have any landing animation
i will add some sliding or popup animation with proper timeline using GSAP which will ultimately enhance the user engagement of website
Use Case
Suppose When a user hovers over the navbar items, subtle animations like scaling or fading will occur, making the navigation feel more interactive. Similarly, as users scroll through the page, body elements like book covers or text will smoothly animate into view, improving the overall user experience.
Benefits
This feature will make the site feel more modern, polished, and visually engaging, encouraging users to explore more content and stay on the platform longer.
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Please Assign this issue to me under Gssoc-extd and hacktoberfest

@Hamza1821 Since our project is not having hacktoberfest topic for now, the label won't count. Assiging this to your under gssoc-ext. Good luck !

No problem

Please add level 3 tag..it will be helpful to me for my gssoc-extd

Please add level 3 tag..it will be helpful to me for my gssoc-extd

I'd let @Trisha-tech  decide that


new client capability: defer calculation additionalTextEdit until comletionItem/resolve

original discussion in https://github.com/microsoft/vscode/issues/96779
Up to now in LSP v3.15, textEdit/additionalTextEdits are calculated in textDocument/completion, and are not allowed to change during comepltionItem/resolve. This leads to a performance issue of Java language server, because it takes time to calculate additionalTextEdits like "import" statements.
Now in vscode, it offers a pragmatic solution, that additionalTextEdits can be calculated during  comepltionItem/resolve, as mentioned in https://github.com/microsoft/vscode/issues/96779#issuecomment-630289141 . Then come the problem, how does the language server know if the client supports the "pragmatic solution", i.e., lazy-loading addtionalTextEdits. So I think a corresponding client capability should be introduced for it.

Why there is no flag for the server support?

@yyoncho what would that flag do?

@yyoncho what would that flag do?

ATM the clients don't know if the server has deferred the population of additionalTextEdits. In case they are nil and the server does not support this deferred additionalTextEdits calculation the client will have do one redundant call.

This is already the case today for the other properties on the completion item that can be deferred. So we decided to not add this. In addition a single global property will not help since this can be different for every completion item (some will have additional text edits, some don't). So to avoid the second round trip we would need to have a property on every completion item which we decided for now not to do.
The additional round trip will not cause any delays in inserting the completion item or block typing in any way.

This is already the case today for the other properties on the completion item that can be deferred.

That is not true. At this point, all properties required for inserting the completion itself are resolved - even more, check your response here - https://github.com/microsoft/language-server-protocol/issues/924#issuecomment-588154729 .

So to avoid the second round trip we would need to have a property on every completion item which we decided for now not to do.

Again, the property will state if the server supports the new client capability - it is a global property. Without it, the clients that are not VScode will have to perform resolve no matter if the server does not support this new feature.

That is not true. At this point, all properties required for inserting the completion itself are present in textDocument/completion response

And that will stay the same if the client doesn't opt into allow lazy additional text edits.
If a client has support for the resolve (it opts into it) why is it difficult for the client to send the resolve request even if the server doesn't fill in any edits. The only advantage of a server property will be to avoid a second roundtrip. It will not ease the implementation side for clients.

The only advantage of a server property will be to avoid a second roundtrip.

Yes - this is the advantage I am looking for.

Just to be clear. The second roundtrip will very likely happen anyways because of other lazy attributes like detail and documentation. If they are not set clients will call resolve when an item is selected.

The second roundtrip will very likely happen anyways because of other lazy attributes like detail and documentation.

this depends on client implementation. On our side(Emacs), we call resolve only for documentation(detail apparently is prepopulated by all(?) of the servers) which can be performed even without blocking. This is not the case with additionalTextEdits - after this change, we will be forced block and resolve additionalTextEdits when the item is not resolved for no reason. The server might not support additionalTextEdits at all but we still should call resolve and block. All this could be easily avoided by adding the server capability flag.

@yyoncho now I understand it. IMO you shouldn't force block the resolving of additional text edits. This will result in a bad user experience. In VS Code we do the following: we capture the edit state before the resolve and if the provided text edits don't conflict with what the user has types in the meantime we insert them. In case of a conflict we drop them and let the user know
In general a conflict is VERY unlikely since additional text edits should only modify text unrelated to the cursor position (https://github.com/microsoft/vscode-languageserver-node/blob/master/types/src/main.ts#L1636)

@dbaeumer thank you, we implemented your suggestion on Emacs side and it works fine.

Great to hear that.


Webpack and HMR 4

This pull-request upgrades webpack and hot-module-reload respectively to the major version 4.

Webpack 4.1.0
Hot Module Reload 4.0.0
Happypack 5.0.1-beta (Beta... well it just changes how the internal plugin api is called, so really nothing has changed)
Remove webpack-md5-hash (Irrelevant now)
Add json extension to modernizerrc (Json loader ships by default and it must have the ext).

When this has been validated and merged, we can continue to add and benefit from new features in Webpack 4 that we currently don't have enabled.

@birkir This is awesome, thank you for getting this started. Just a question -  With the new production mode, can't we also take out a lot of the isProduction code in the configFactory, like the minimizing and uglifying the code?
And if we upgrade to Babel 7, we would be all caught up and with simplified config!

@birkir, hi.
I'm gettting stuck after this:
WEBPACK: Creating a development bundle configuration for the "client"
(node:8645) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead

@oyeanuj That was the plan!
@newsiberian This is just a warning. Inevitable we still have to use HappyPack for multi-threaded bundling. Everything works fine.

Awesome! Thanks so much for this!

Hi, @birkir, @ctrlplusb, once again I want to return to this. Are you don't using react-async-component? Because I still have many errors related with it. One of them described here and here

Also getting this many times:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added. Use emitter.setMaxListeners() to increase limit
Catched here

I think all of your reported errors are not related to this PR.
We could definitely do some work on async things, like use import() for native webpack code splitting etc. But step 1 is getting webpack 4 in, then get feedback so we can incrementally get closer.
Thanks

👏

@birkir @sergiokopplin Is code splitting still working for you after this PR? If yes, could you share the config that you have for chunking?

hey @oyeanuj, i need testing first, i`m not using that yet


please add license

MIT or Apache2 is good. Anyone can create a PR for that, I will appreciate it.


J_regressor_wham.npy  where down it?

python demo.py --video dance.mp4 --visualize
2024-03-04 19:44:25.282 | INFO     | main::27 - DPVO is not properly installed. Only estimate in local coordinates !
2024-03-04 19:44:25.316 | INFO     | main::209 - GPU name -> NVIDIA GeForce RTX 2060
2024-03-04 19:44:25.316 | INFO     | main::210 - GPU feat -> CudaDeviceProperties(name='NVIDIA GeForce RTX 2060', major=7, minor=5, total_memory=12287MB, multi_processor_count=34)
Traceback (most recent call last):
File "C:\ia\wham\WHAM\demo.py", line 214, in
smpl = build_body_model(cfg.DEVICE, smpl_batch_size)
File "C:\ia\wham\WHAM\lib\models_init.py", line 12, in build_body_model
body_model = SMPL(
File "C:\ia\wham\WHAM\lib\models\smpl.py", line 25, in init
J_regressor_wham = np.load(_C.BMODEL.JOINTS_REGRESSOR_WHAM)
File "C:\Users\ultim\miniconda3\envs\wham\lib\site-packages\numpy\lib\npyio.py", line 427, in load
fid = stack.enter_context(open(os_fspath(file), "rb"))
FileNotFoundError: [Errno 2] No such file or directory: 'dataset/body_models/J_regressor_wham.npy'
any idea?

All SMPL-related auxiliary data can be downloaded from the Google Drive. You will get everything downloaded by running
bash ./fetch_demo_data.sh

All SMPL-related auxiliary data can be downloaded from the Google Drive. You will get everything downloaded by running
bash ./fetch_demo_data.sh

Hi Soyong Shin,
Thanks for your patience and detailed tutorial.
I‘ve noticed that the current version of fetch_demo_data.sh doesn't contain the download addresses of files like J_regressor_wham.npy, and the two dependecy files smpl_mean_params.npz and smpl_faces.npy haven't been metioned yet.
May I ask if the fetch script is missing some of the dependency files?
Best regrads,
Qijun Ying


themes and classes

Would it be possible to allow a dynamic class to be applied to the tooltip, rather than the hard-coded one? In my app, we use different tooltip styles depending on the context.

Implemented in 1.1.0


fix deprecations on Julia 0.7

Codecov Report

Merging #50 into master will increase coverage by 0.56%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
+ Coverage   95.26%   95.83%   +0.56%
==========================================
  Files           7        7
  Lines         676      672       -4
==========================================
  Hits          644      644
+ Misses         32       28       -4

Impacted Files
Coverage Δ

src/streamreader.jl
95.91% <ø> (ø)
:arrow_up:

src/EzXML.jl
5.55% <0%> (+1.01%)
:arrow_up:

src/node.jl
99.18% <0%> (ø)
:arrow_up:

src/error.jl
96.15% <100%> (ø)
:arrow_up:

src/document.jl
99.13% <50%> (ø)
:arrow_up:

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 e6ca4cd...07f5114. Read the comment docs.


is this package registered?

(test) pkg> st
Status `~/.julia/dev/test/Project.toml` (empty project)

(test) pkg> add StaticArrayInterface
ERROR: The following package names could not be resolved:
 * StaticArrayInterface (not found in project, manifest or registry)

https://github.com/JuliaRegistries/General/pull/77961


Allow to expose a subset of unsafe RPCs

Closes https://github.com/paritytech/substrate/issues/2303
Introduces machinery which allows us to deny/allow certain "unsafe" RPCs if we're exposing it to the network. The last bits (configuration) are fairly easy to add; in the meantime, I'd like to get some feedback on the initial implementation.
The aim is to provide a very simple filtering out-of-box and recommend using something like https://github.com/tomusdrw/jsonrpc-proxy for anything more complicated. We decided against a separate blacklist/whitelist with @tomusdrw since this would make things unnecessarily more scattered and harder to navigate.
Unresolved/To do:

[ ] Should the configuration leverage existing --unsafe-{rpc,ws}-external flags?
[ ] Should the setting be separate for HTTP and WS servers?
[ ] Make sure every "unsafe" RPC is included and checked here
[ ] Should tests be added for each API modified?

Is it possible for rpc_methods to exclude unsafe rpc endpoints when they are disabled? so client can easily detect if a given RPC is truly supported.
Also please make sure we have an updated list of unsafe RPCs somewhere, https://github.com/paritytech/substrate/wiki/Public-RPC is outdated already.
Is author_submitExtrinsic safe or unsafe?
For the RPC node that I would like to have, it should deny all unsafe RPC endpoints but accept author_submitExtrinsic so public can connect to it and submit transactions via frontend.

@tomusdrw / @jacogr might have opinion about this, I don't know all context in which rpc is used

What is the status of this pr?

This is rebased against the current master and catches up with some CLI updates; I'll add macros to remove some error boilerplate and will need to think about safe way to inspect supported RPC calls.

Rebased, added a macro (in system) to reduce some repetition when checking if a given RPC is safe. Let's see what CI says and this should be good to go :+1:

@Xanewok needs resolving.

Rebased, everything is green now.

This makes CLI super confusing.
We have --unsafe-rpc-external, which is "unsafe" "rpc-external" and now
--unsafe-rpc-expose, which is "unsafe-rpc" "expose", not "unsafe" "rpc-expose"
I suggest rename it.


immersive portals tells me to use sodium to avoid crash even though sodium crashes. what to do?

using 1.20.1 fabric

I think you installed wrong Sodium version (when you tried).
Versions that work :

Sodium : 0.5.8
Iris : 1.7.0


Fix the example app to be compatible with Koa 2, not 1

thanks for calling this out and for the fix!


misplaced alert

Hi guys!
When I launch the alert appears scrolling down the page…
Any idea?
Thanks in advance.
Regards

Sounds like Bootstrap, CSS or JQuery dependency issue.
Dale
Sent from my iPhone
On Jun 22, 2016, at 4:47 PM, jonaygalvan <notifications<EMAIL_ADDRESS>wrote:
Hi guys!
When I launch the alert appears scrolling down the page…
Any idea?
Thanks in advance.
Regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/craftpip/jquery-confirm/issues/121, or mute the threadhttps://github.com/notifications/unsubscribe/AQw9yHSEvm1XqqcE9rbztAdjmjifAiw4ks5qOZ93gaJpZM4I8NGx.

Yeah! I am using bootstrap.
It id a common issue?
Regards
On Wednesday, 22 June 2016, dvmobley<EMAIL_ADDRESS>wrote:

Sounds like Bootstrap, CSS or JQuery dependency issue.
Dale
Sent from my iPhone
On Jun 22, 2016, at 4:47 PM, jonaygalvan<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');><mailto:
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>> wrote:
Hi guys!
When I launch the alert appears scrolling down the page…
Any idea?
Thanks in advance.
Regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://github.com/craftpip/jquery-confirm/issues/121>, or mute the
thread<
https://github.com/notifications/unsubscribe/AQw9yHSEvm1XqqcE9rbztAdjmjifAiw4ks5qOZ93gaJpZM4I8NGx

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/craftpip/jquery-confirm/issues/121#issuecomment-227899484,
or mute the thread
https://github.com/notifications/unsubscribe/ATKsbyLbybVe2Kp7FazzIGaMbIkXrIW1ks5qObpQgaJpZM4I8NGx
.

--
--
Jonay Galván
about me:
http://about.me/jonaygs

Check version dependencies.
Dale
Sent from my iPhone
On Jun 22, 2016, at 7:14 PM, jonaygalvan <notifications<EMAIL_ADDRESS>wrote:
Yeah! I am using bootstrap.
It id a common issue?
Regards
On Wednesday, 22 June 2016, dvmobley <notifications<EMAIL_ADDRESS>wrote:

Sounds like Bootstrap, CSS or JQuery dependency issue.
Dale
Sent from my iPhone
On Jun 22, 2016, at 4:47 PM, jonaygalvan <notifications<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.commailto:notifications@github.com');><mailto:
notifications<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.commailto:notifications@github.com');>>> wrote:
Hi guys!
When I launch the alert appears scrolling down the page…
Any idea?
Thanks in advance.
Regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://github.com/craftpip/jquery-confirm/issues/121>, or mute the
thread<
https://github.com/notifications/unsubscribe/AQw9yHSEvm1XqqcE9rbztAdjmjifAiw4ks5qOZ93gaJpZM4I8NGx

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/craftpip/jquery-confirm/issues/121#issuecomment-227899484,
or mute the thread
https://github.com/notifications/unsubscribe/ATKsbyLbybVe2Kp7FazzIGaMbIkXrIW1ks5qObpQgaJpZM4I8NGx
.

--
--
Jonay Galván
about me:
http://about.me/jonaygs
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/craftpip/jquery-confirm/issues/121#issuecomment-227905061, or mute the threadhttps://github.com/notifications/unsubscribe/AQw9yGZffHvIn6OwYDwEzY6zSZVLVljpks5qOcGzgaJpZM4I8NGx.


Asserting validaton rule image fails on image/avif mime type.

Laravel Version
10.21.1
PHP Version
8.3.2
Database Driver & Version
MariaDB 10.6
Description
When attempting to upload an image that uses the 'image' validation rule, with a .AVIF filetype, you will encounter a validation error that returns 422 Unprocessable Entity.

        ]
    }
}

Steps To Reproduce

Create a new Request (php artisan make:request)
Attempt to set validation rule of "image"
Attempt to upload a .avif image.

Here is the related code:
https://github.com/laravel/framework/blob/443ec4438c48923c9caa9c2b409a12b84a10033f/src/Illuminate/Validation/Concerns/ValidatesAttributes.php#L1313-L1316
You may use mimes validation rule manually instead. Or send a PR to add avif.

@hafezdivandari Thanks for the reply and pointing it out, I'm happy to make the PR.
If possible for the Laravel developers/maintainers, I'd like to open the discussion and inquire why we're using specifically designated MIMEs rather than asserting the condition on the family. It seems like it would make more sense to handle things that way.

asserting the condition on the family

@Elycin You mean something like this?
- return $this->validateMimes($attribute, $value, ['jpg', 'jpeg', 'png', 'gif', 'bmp', 'svg', 'webp']);
+ return $this->validateMimetypes($attribute, $value, 'image/*');

You should target master branch then, as it would be a breaking change.

Right now this type isn't part of the image rule. There's no specific reason. You could attempt a PR to add if if you like.


Logging support.

See:
https://github.com/coreos/coreos-kubernetes/issues/320
https://github.com/kubernetes/kubernetes/tree/release-1.3/cluster/addons/fluentd-elasticsearch
https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/fluentd-es/fluentd-es.yaml

the only issue I have with this is that the images used seemed to be unmaintained and there are better ways to run elasticsearch once you are using 2.0 like using this the kubernetes cloud plugin that uses the Kubernetes API for unicast discovery.

unmaintained? last commit is from 14 days ago, only that seems quite old is kibana one.
This is just what kubernetes does by default when setting elastic for logging and coreos-kube will be using that as well by default as per https://github.com/coreos/coreos-kubernetes/issues/320
There's probably better ways but we need a logging solution and this is a working one


Config from readme gives "path is not defined"

Specifically, this line:
$ gulp
webpack.config.js:31
            modernizr$: path.resolve(__dirname, ".modernizrrc")
                        ^

ReferenceError: path is not defined
    at Object.<anonymous> (webpack.config.js:31:25)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (gulpfile.js:63:23)
    at Module._compile (module.js:570:32)

Do I need to add an import/require? If so, perhaps this could be included in the readme as well.

If you want to use the path module, you need to require it in the file you're using it.
const path = require('path');

// ...

I'll update the README file as well.

Thanks.


update version to 10.42

I noticed there are many changes in the conda-forge recipe, including making this a multi-output recipe that creates several conda packages. However this is the simple change to update only the version # and hash. Dependencies etc. need to be checked.

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_8dn45ud91g/clone/recipe/meta.yaml:77: http_url: http://www.pcre.org/current/doc/html/ is not https
ERROR: /tmp/abs_8dn45ud91g/clone/recipe/meta.yaml:77: http_url: http://www.pcre.org/ is not https
Errors were found


Some readibility nits.  A spelling error

Change "has to" to "must".

Change "intermidiate" to "intermediate".

Wording.

@edburns : Thanks for your contribution! The author(s) have been notified to review your proposed change. @amsriva

#sign-off

@vhorne: I'm sorry - only the author of this article, @amsriva, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Pods do not terminate gracefully and do not scale

Given a running configuration
NAME                                 READY   STATUS    RESTARTS   AGE
distributor-7f7769c8f6-7wxhx         1/1     Running   0          24m
distributor-dapr-w968l               1/1     Running   0          24m
receiver-express-69c989476f-5w854    1/1     Running   0          9m2s
receiver-express-dapr-vlbp9          1/1     Running   0          9m
receiver-standard-69d6797586-rspx8   1/1     Running   0          9m2s
receiver-standard-dapr-vrv5v         1/1     Running   0          8m59s

after changing the workload and redeploying, previous pods stay in Terminating
NAME                                 READY   STATUS        RESTARTS   AGE
distributor-7f7769c8f6-7wxhx         1/1     Running       0          29m
distributor-dapr-w968l               1/1     Running       0          29m
receiver-express-69c989476f-5w854    1/1     Terminating   0          14m
receiver-express-dapr-vlbp9          1/1     Running       0          14m
receiver-express-fb667dd79-tnn9g     1/1     Running       0          3m22s
receiver-standard-69d6797586-rspx8   1/1     Terminating   0          14m
receiver-standard-c8b8577b4-49c8j    1/1     Running       0          3m22s
receiver-standard-dapr-vrv5v         1/1     Running       0          14m

related issue : https://github.com/containerd/runwasi/issues/418

additionally, when I try to scale
$ kubectl scale deployment distributor --replicas 3

pods get stuck in ContainerCreating
NAME                                READY   STATUS              RESTARTS   AGE
distributor-6765d649b5-77444        0/1     ContainerCreating   0          3m15s
distributor-6765d649b5-g6k8w        1/1     Running             0          115m
distributor-6765d649b5-m4mlr        0/1     ContainerCreating   0          3m15s
distributor-dapr-x4spd              1/1     Running             0          115m

events e.g. for first pod:
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  81s   default-scheduler  Successfully assigned default/distributor-6765d649b5-77444 to aks-npspin-84373721-vmss000000

What version of the Spin shim are you using? Could you gather containerd logs related to the pods that are stuck in container creating?

(side note: you can refer to this issue for accessing containerd logs in your cluster https://github.com/deislabs/containerd-wasm-shims/issues/197)

What version of the Spin shim are you using? Could you gather containerd logs related to the pods that are stuck in container creating?

I am currently using kwasm-node-installer main branch and that copies Spin : /deislabs/containerd-wasm-shims/releases/download/v0.10.0/containerd-wasm-shims-v2-spin-linux-$(uname -m).tar.gz
I think I found the kubelet / containerd logs on the AKS node. I will redeploy with single pods to get rid of noice in the logs to make analysis easier.

@devigned @Mossaka I hope this journalctl -u kubelet of the WASM-shimed AKS node helps: aks-kubelet.txt

It would be great to see containerd logs

It would be great to see containerd logs

All of the details about the shim starting and possibly failing will be contained at the containerd level. The Kubelet is a little too high level to provide the detail required to diagnose the issue.

It would be great to see containerd logs

All of the details about the shim starting and possibly failing will be contained at the containerd level. The Kubelet is a little too high level to provide the detail required to diagnose the issue.

Do you have any pointers for me where I could find containerd logs on an AKS node?

Can you try journalctl -u containerd?

thanks @Mossaka - that worked ... but + @devigned - since I switched to kwasm-node-installer this behavior seems to be gone
$ k scale deployment --replicas 8 distributor
deployment.apps/distributor scaled
$ k get pod
NAME                                READY   STATUS        RESTARTS      AGE
distributor-54576c4fd5-9srhk        1/1     Running       0             14m
distributor-54576c4fd5-crpfn        1/1     Running       0             14m
distributor-54576c4fd5-fx86x        1/1     Running       0             19m
distributor-54576c4fd5-hjcgk        1/1     Running       0             14m
distributor-54576c4fd5-hn52r        1/1     Running       0             19m
distributor-54576c4fd5-jz42v        1/1     Running       0             14m
distributor-54576c4fd5-ldqs9        1/1     Terminating   0             14m
distributor-54576c4fd5-vxddt        1/1     Running       0             19m
distributor-54576c4fd5-zbwh5        1/1     Running       0             14m
distributor-dapr-5cd8c7cb9b-9w8mc   1/1     Running       0             19m
distributor-dapr-5cd8c7cb9b-rwkk6   1/1     Running       0             14m
distributor-dapr-5cd8c7cb9b-xgdgf   1/1     Running       1 (19m ago)   19m
kwasm-debug-bdq4l                   1/1     Running       0             5m54s
kwasm-initializer-9sr5q             1/1     Running       0             22m
... after a few seconds ...
$ k get pod
NAME                                READY   STATUS    RESTARTS      AGE
distributor-54576c4fd5-9srhk        1/1     Running   0             15m
distributor-54576c4fd5-crpfn        1/1     Running   0             15m
distributor-54576c4fd5-fx86x        1/1     Running   0             20m
distributor-54576c4fd5-hjcgk        1/1     Running   0             15m
distributor-54576c4fd5-hn52r        1/1     Running   0             20m
distributor-54576c4fd5-jz42v        1/1     Running   0             15m
distributor-54576c4fd5-vxddt        1/1     Running   0             20m
distributor-54576c4fd5-zbwh5        1/1     Running   0             15m
distributor-dapr-5cd8c7cb9b-9w8mc   1/1     Running   0             20m
distributor-dapr-5cd8c7cb9b-rwkk6   1/1     Running   0             15m
distributor-dapr-5cd8c7cb9b-xgdgf   1/1     Running   1 (20m ago)   20m
kwasm-debug-bdq4l                   1/1     Running   0             7m8s
kwasm-initializer-9sr5q             1/1     Running   0             23m


[Bug]: Tried to use http:// protocol, but puppeteer switched to https:// since version 20.0.0

Minimal, reproducible example
import puppeteer from "puppeteer";

async function getPage(options, url) {
  const browser = await puppeteer.launch(options);
  const page = await browser.newPage();
  await page.goto(url);
  await page.waitForSelector("body");
  const res = await page.url();
  await browser.close();
  return res;
}

async function main() {
  const url = "http://ip-api.com/json";
  const headlessUrl = await getPage({ headless: true }, url);
  if (headlessUrl != url) {
    throw new Error("headlessUrl should be equal to url");
  }
  const newHeadlessUrl = await getPage({ headless: "new" }, url);
  if (newHeadlessUrl != url) {
    throw new Error("newHeadlessUrl should be equal to url");
  }
}

main().catch(console.error);

Error string
newHeadlessUrl should be equal to url
Bug behavior

[ ] Flaky
[ ] PDF

Background
The problem is that protocol changed from http to https in headful and new headless mode.
Te bug appears in the version 20.0.0 and still exists. Version 19 works fine.
Expectation
it should return the original url
Reality
It heturns url with protocol changed to https (from http)
Puppeteer configuration file (if used)
nothing special

Puppeteer version
20.9.0
Node version
18.16.1
Package manager
yarn
Package manager version
1.22.19
Operating system
macOS

I don't think it's a bug, it's just the default browser behaviour. Note that the old headless does not match the regular browser behaviour here as it is technically a custom browser implementation https://developer.chrome.com/articles/new-headless/ You can still use the old headless if you need that custom behaviour.

The fix is to start Chrome with the option:
--disable-features=HttpsUpgrades


No 'Access-Control-Allow-Origin' header is present on the requested resource.

Is there a way to set the access control headers for tileserver?
I am getting these errors:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

There isn't at the moment, no. We usually have another server in front of tileserver that always adds those headers into the response. Is it possible for you to add nginx in front to add those headers in?

We've added a cors configuration option to the config file. Can you try the master branch with cors: true configured at the top level?

Thanks! Works now.


Module not found: Can't resolve 'react/jsx-runtime.js'

Happy to submit a PR for this, affects versions 7-8 at least, node 14+. You can see it when running yarn site in
What you did:
Set up next.js + mdx-bundler.
What happened:

error - ../../node_modules/mdx-bundler/dist/client.js:11:0
Module not found: Can't resolve 'react/jsx-runtime.js'

Import trace for requested module:
./../../node_modules/mdx-bundler/client/index.js
./pages/docs/intro/[slug].tsx

Reproduction repository:
https://github.com/tamagui/tamagui
yarn install
yarn site

# navigate to the docs page

Problem description:
Importing the .js fully specified seems to mess up webpack. I must be using some version that is weird somewhere - whether React or Webpack..
Suggested solution:
I think just changing the import from react/jsx-runtime.js to react/jsx-runtime would make this a bit more compatible, happy to submit a PR.

There's a workaround by aliasing react/jsx-runtime.js to preact/compat/jsx-runtime in next.config.js.
You can find an example here https://github.com/kentcdodds/mdx-bundler/issues/140#issuecomment-1013928307 on a similar issue I opened recently.

After a few tries for whatever reason the alias works now:
const jsxRuntime = require.resolve('react/jsx-runtime.js')

webpackConfig.resolve.alias = {
    'react/jsx-runtime.js': jsxRuntime,
    'react/jsx-runtime': jsxRuntime,
}


TV Arena: Capstone Project

Hi,
We implemented the capstone project, having the project requirements listed here.
Here is the link to the live version.
And here is the link to the video presenting the features of the project we have built.
Thank you.

Hi,
We have re-recorded the video, presenting some of the interesting parts of the project.
Here is the link to the video.


CompareAttribute ignored with OnValidSubmit EditForm

Using an EditForm in Blazor client side
I have a model with compare attribute.
The error message does show when the password and confirm password are not the same but does not prevent form submission for some reason. Once the form is submitted the error message is removed.
Expected behavior
Prevent form submission and keep the error message

To get around this, i used the following code using OnSubmit and EditContext
public void Submit()     {         var isValid = !_editContext.GetValidationMessages().Any();         if (isValid)             Vm.ResetPassword();     }

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimalistic repro project that illustrates the problem.

If, however, you believe this was an issue on your end, please close the issue. Thanks!

@mkArtakMSFT
Please check this repository
https://github.com/smartprogrammer93/CompareTest

Thanks @smartprogrammer93.
We'll look into this in the near future.

@mkArtakMSFT Can you please remove the question Label so the issue will be considered later for Backlog

I found that this occurs when the EditContextDataAnnotationsExtensions.ValidateModel method does not add the field to the "messages" collection. The method does not include this because ValidationResult has no items in the "MemberNames" array when the Compare attribute is used.
See code with comment:
private static void ValidateModel(EditContext editContext, ValidationMessageStore messages)
{

  // <removed code>

   foreach (var validationResult in validationResults)
   {

     **// CompareAttribute will not generate MemberNames, messages will not be updated.**
     foreach (var memberName in validationResult.MemberNames)
     {
        messages.Add(editContext.Field(memberName), validationResult.ErrorMessage);
     }
   }

 // <removed code>

}

To work around this problem, I suggest changing the implementation of the CompareAttribute.IsValid method to include the validated property name in the method return.
Original version

protected override ValidationResult IsValid(object value, ValidationContext validationContext) {

   PropertyInfo otherPropertyInfo = validationContext.ObjectType.GetProperty(OtherProperty);

   if (otherPropertyInfo == null) {
      return new ValidationResult(String.Format(CultureInfo.CurrentCulture, DataAnnotationsResources.CompareAttribute_UnknownProperty, OtherProperty));
   }

   object otherPropertyValue = otherPropertyInfo.GetValue(validationContext.ObjectInstance, null);

   if (!Equals(value, otherPropertyValue)) {
      if (OtherPropertyDisplayName == null) {
         OtherPropertyDisplayName = GetDisplayNameForProperty(validationContext.ObjectType, OtherProperty);
      }
      return new ValidationResult(FormatErrorMessage(validationContext.DisplayName));
   }

   return null;

}

Suggested version:

protected override ValidationResult IsValid(object value, ValidationContext validationContext) {

  PropertyInfo otherPropertyInfo = validationContext.ObjectType.GetProperty(OtherProperty);

  if (otherPropertyInfo == null) {
     // SUGGESTED CHANGE
     var msg = String.Format(CultureInfo.CurrentCulture, DataAnnotationsResources.CompareAttribute_UnknownProperty, OtherProperty);
     return new ValidationResult(msg, new[] { validationContext.MemberName });
  }

  object otherPropertyValue = otherPropertyInfo.GetValue(validationContext.ObjectInstance, null);

  if (!Equals(value, otherPropertyValue)) {
     if (OtherPropertyDisplayName == null) {
        OtherPropertyDisplayName = GetDisplayNameForProperty(validationContext.ObjectType, OtherProperty);
     }
     // SUGGESTED CHANGE
     var msg = FormatErrorMessage(validationContext.DisplayName);
     return new ValidationResult(msg, new[] { validationContext.MemberName });
  }

  return null;

}

I'm running into the same issue. I was trying to use the compare validator to make an experience similar to GitHub's delete where the user must type a matching name to confirm deletion.
@page "/post/delete/{PostId:int}"
@inject BloggingContext dbContext

Delete Post

@if (deleted > 0)
{

        Your post was deleted.

}

<EditForm Model="DeleteConfirmation" OnValidSubmit="HandleValidDelete">
    <DataAnnotationsValidator />
    <ValidationSummary />

            Type the Post Title <span<EMAIL_ADDRESS>and click to delete this item.

        <InputText class="form-control" @bind-Value="DeleteConfirmation.CompareInput" />

    <button class="btn btn-danger" type="submit">Delete</button>
</EditForm>

@code {

    [Parameter] public int PostId { get; set; }

    [Parameter] public DeleteConfirmationModel DeleteConfirmation { get; set; }

    int deleted = 0;
    Post post;

    protected override async Task OnInitializedAsync()
    {
        post = await dbContext.Posts.FirstAsync(p => p.PostId == PostId);
        DeleteConfirmation = new DeleteConfirmationModel
        {
            CompareValue = post.Title
        };
    }

    async Task HandleValidDelete()
    {
        // Compare validator doesn't block submission
            dbContext.Posts.Remove(post);
            deleted = await dbContext.SaveChangesAsync();
   }
}
    public class DeleteConfirmationModel
    {
        public string CompareValue { get; set; }

        [Compare(otherProperty: nameof(DeleteConfirmationModel.CompareValue),
            ErrorMessage = "Value did not match reference")]
        [Required]
        public string CompareInput { get; set; }
    }

My bad i pressed the close button by mistake

As noted in https://github.com/aspnet/AspNetCore/issues/10643#issuecomment-520236208, on a form submit Blazor's DataAnnotationsValidator fails to record validation results that are not associated with a member. CompareAttribute does this which results in the buggy behavior you're seeing here.
In 3.1, we're doing a couple of things to address this:

Validation results without members now get associated with the model instance. In addition we've added support to ValidationSummary to print error messages that are specifically associating with the model. You should be able to do something along the liens of

<EditForm Model="myModel" OnValidSubmit="OnSubmit">
    <DataAnnotationsValidator />
    <InputText Name="Password" /> <ValidationMessage For=@(() => myModel.Password)" />
    <InputText Name="ConfirmPassword" /> <ValidationMessage For=@(() => myModel.ConfirmPassword)" />

    <ValidationSummary Model="myModel" />
    <button class="btn btn-danger" type="submit">Submit</button>
</EditForm>

The ValidationSummary would additionally display messages produced from models implementing IValidatableObject or using custom ValidationAttribute \ CustomValidationAttribute.
In addition, for the 3.1.0-preview2 release, we plan on introducing an experimental package - Microsoft.AspNetCore.Components.DataAnnotations.Validation - with an ComparePropertyAttribute that behaves like a CompareAttribute but produces a valid MemberName. It should be a drop in replacement to CompareAttribute. Users in 3.0 should be able to copy the type in to their app to resolve the error they're seeing here. Here's the source: https://github.com/aspnet/AspNetCore/blob/c298c94fe1113b64474a3d5fcdef487f02c74991/src/Components/Blazor/Validation/src/ComparePropertyAttribute.cs
This package is marked experimental since our plan is to roll these changes in to CoreFx as part of the 5.0 milestone. Hope this helps.


feat: Added a keybind for quickly setting quantity or price

Added a configurable keybind to quickly set the copilot suggested price or quantity of an item.
I also had to shuffle around the methods in OfferEditor and moved them to a own handler called OfferHandler

There is a side effect that if you bind it to "Enter" it will first set the value and then submit it. Not sure if Jagex likes that it does 2 actions with same keypress

There is a side effect that if you bind it to "Enter" it will first set the value and then submit it. Not sure if Jagex likes that it does 2 actions with same keypress

Looks good overall, although the "Enter" problem does need to be addressed. As you say, this could break Jagex rules and result in the plugin being removed from the plugin hub.

There is a side effect that if you bind it to "Enter" it will first set the value and then submit it. Not sure if Jagex likes that it does 2 actions with same keypress

Looks good overall, although the "Enter" problem does need to be addressed. As you say, this could break Jagex rules and result in the plugin being removed from the plugin hub.

I'll just disable "Enter" keybinds


Navigate compatibility

@nornil
@AdvancedImagingUTSW and @annie-xd-wang, very excited you're interested in trying out ExEngine!
Here's a guide for what I think a good roadmap is in order of benefits to Navigate / effort required. For most of these things, you may be the first to look over the documentation I've written, so please ask questions early and often so that I know what needs improvement!
I think (1) will be not so hard and offers immediate obvious benefits to Navigate. (2) will be a bit more involved but provides the threading benefits of ExEngine to Navigate. (3-5) are essentially refactoring Navigate to be as if you were building it on ExEngine from the start. This will offer immediate benefits to the wider community, because it would modularize and standardize your components to make them more easily reusable, and it should allow others to contribute fixes and improvements to components you rely on. In the long run, as people build more things on top of ExEngine, it will also give the benefit that you should be various types of smart microscopy/networked-based control on your hardware with minimal additional work.
1) Try out ExEngine with the Micro-Manager device backend
This will give you a feel for how ExEngine's device abstraction works, and it should save you the effort of having to make compatibility for other MM devices yourself. I think you can add exengine as a dependency to your project with only the micromanager device backend, and this may not even add any additional dependencies to Navigate.
More instructions here
2) Implement your devices as ExEngine devices
This would give you the immediate benefits of the executor/threading for your devices
Based on seeing your code, it seems like the simplest thing to try first would be to have your MicroscopeModel inherit from exengine.base_classes.Device. After testing that, the better approach would be to do this at the level of individual devices within your MicroscopeModel, as that would give you more fine-grained control over threading, and open up the possibility of others using your devices.
(Edit: I a writeup of the threading features we talked about)
3) Refactor your higher level code in terms of ExEngine device APIs
Next, you could try to make your devices inherit from ExEngine's device base classes. You should be able to do this without breaking any higher level code that currently calls your devices by just trying to implement these abstract methods in terms of your existing APIs. Note that ExEngine's device APIs are in early days. There are definitely more devices needed, and if existing APIs don't work for your devices, it would be great to know that so they could possibly be changed.
Next, you could consider adding Navigate devices as a new device backend, which would allow all users of ExEngine to make use of them
4) Investigate making features into events
I think your concept of "Features" is very similar, if not the exact same thing as events. If you were able to implement them as ExecutorEvents and have them take only Exengine device types in constructors they could made to work with all backends.
5) Storage backends
I see that Navigate has a lot of great options for storage backends. Can these be broken out into individual libraries for reading and writing? If so, you could make these into storage backends in ExEngine, which could open them up for use by a much bigger audience.
I would not be surprised if the ExEngine storage API needs expansion to accommodate some of the light sheet-specific features, and I'd be quite curious to know what these are.
Please feel free to ask any questions or share your thoughts as you look into this!

@henrypinkard - I just wanted to let you know that this is on my radar and I will look into it once things settle down on my side.  Thanks...


Node Keyboard Navigation

Add the ability to navigate the nodes using the keyboard. This might only apply for some layouts.
https://observablehq.com/@d3/hierarchy-traversal-animated

I think this is probably not possible, going to close as its not important.


Need more language options~

:D

add 日本語: https://github.com/imknown/KeyFingerprintLooker/commit/2d3c49b9025c7a01872f8dd4ca15560998e243a2


Fix Model / Remove 0W Bones breaks on some models

I've tried to use some of the CATS tools but they seem to not function properly on some rigs, not sure why.
All 3 of these appear to be bugged:
Fix Model, Remove 0 Weight Bones, Merge To Parent/Active.
Before:
https://i.gyazo.com/7c2ae58e014ccc436f33756b7b3e1eb3
After:
https://i.gyazo.com/db1ffe35d995c69e0bb9afdf658de09b

there are no errors at all in console and if u would like 2 see the model I can send it PW locked

Thanks for the report! This is caused by a visual bug in Blender 2.80 and I added a workaround in cats 0.15.0

https://puu.sh/EkOxV/3a3aa32533.png
still appears to happen unfortunately, just upgraded CATS
https://puu.sh/EkOyU/d1ca4fb577.png
and there was some weird 'decoding the byte' or whatever error when i had Connect Bones turned on


Check for non-existent fileDependencies to fix angular AOT

It appears that builds which use angular AOT compilation add additional non-existent file paths to the fileDependencies collection, while still also including all real file paths.  This PR simply adds a check that the file exists before calling lstat on it in order to avoid an error.

I will try that soon. Thanks

I will try that soon. Thanks

@rpokorny
Unfortunately, that's not enough. We have two requirements:

handle the exception or is file condition
copy also all renamed source files (for example: file-name.js does not exists, so we copy all file-name.* files)

see here: https://github.com/sonatype-nexus-community/copy-modules-webpack-plugin/pull/26/files

@rpokorny
Unfortunately, that's not enough. We have two requirements:

handle the exception or is file condition
copy also all renamed source files (for example: file-name.js does not exists, so we copy all file-name.* files)

see here: https://github.com/sonatype-nexus-community/copy-modules-webpack-plugin/pull/26/files

@deleonio in my investigation of the issue, I found that all actual files which were included in the build were present in fileDependencies, along with the made-up ones.  Are you seeing something different? Given that all of the files we need to copy are present there, there is no need to go hunting for similarly-named files as your PR does.  Additionally your solution is problematic in terms of the basic purpose of this plugin: the copying of only those source files which are included in the build.  Your solution has the plugin also copying nearby similarly-named files, even if they are not actually included in the build.  I would consider that a bug.

@deleonio in my investigation of the issue, I found that all actual files which were included in the build were present in fileDependencies, along with the made-up ones.  Are you seeing something different? Given that all of the files we need to copy are present there, there is no need to go hunting for similarly-named files as your PR does.  Additionally your solution is problematic in terms of the basic purpose of this plugin: the copying of only those source files which are included in the build.  Your solution has the plugin also copying nearby similarly-named files, even if they are not actually included in the build.  I would consider that a bug.

@rpokorny
I understand your argumentation. Actually I does not understand why the @ngtools/webpack rename the source meta data.
In our source folder there are only TS files. And in the dependency file list are only JS files.
We will see https://github.com/angular/angular-cli/tree/master/packages/ngtools/webpack

@rpokorny
I understand your argumentation. Actually I does not understand why the @ngtools/webpack rename the source meta data.
In our source folder there are only TS files. And in the dependency file list are only JS files.
We will see https://github.com/angular/angular-cli/tree/master/packages/ngtools/webpack

In our source folder there are only TS files. And in the dependency file list are only JS files.

OK, so it sounds like you are seeing something different than what I'm seeing.  In the demo project that I am tweaking to test this, there is a main.ts file (among other ts files) in the source tree which is present in the fileDependencies array.  I am actually not seeing any main.js file in fileDependencies, though I am seeing  various other non-existent file paths (for instance, app.component.less.shim.ngstyle.js alongside app.component.less).
What version of angular are you using? That demo project is on angular 6.  It's possible the behavior is different in different versions

In our source folder there are only TS files. And in the dependency file list are only JS files.

OK, so it sounds like you are seeing something different than what I'm seeing.  In the demo project that I am tweaking to test this, there is a main.ts file (among other ts files) in the source tree which is present in the fileDependencies array.  I am actually not seeing any main.js file in fileDependencies, though I am seeing  various other non-existent file paths (for instance, app.component.less.shim.ngstyle.js alongside app.component.less).
What version of angular are you using? That demo project is on angular 6.  It's possible the behavior is different in different versions

I work with angular 11.1 today.
I've thought about it again and I find that this solution makes the most sense.
Because ...

We catch an error situation
We do not solve problems in another module

I work with angular 11.1 today.
I've thought about it again and I find that this solution makes the most sense.
Because ...

We catch an error situation
We do not solve problems in another module


Experiment with declaring a set of extensions?

There were some threads about introducing a -XHaskell2016 or -XGlasgow2016, or perhaps a new language.
https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/
hpack seems like a great place to experiment with this.  What if something like this was added as a feature of hpack?  To avoid confusion and make it clear it's an experiment, could have something like language: hpack2016.
IMHO, ideally we'd carve out something that can be the seed of a new standard, and so should only include extensions that we expect to make it in to the standard. I think the following are good guidelines:

Widely used with few unexpected consequences.  We can use the poll results for this
Avoid things that have a bunch of complexity, particularly if there are known unresolved loose ends.  Avoid complex things that haven't been around for a long time and are fully proven.
Avoid extensions that can cause some code to not compile when enabled.  I have accumulated a list of these in the stack ghci code, to inform the user when they are loading multiple packages that have potentially conflicting extensions: https://github.com/commercialhaskell/stack/blob/master/src/Stack/Ghci.hs#L408

Here are the most popular "safe" extensions:
LambdaCase (71)
GADTSyntax (70)
RankNTypes (70)
ScopedTypeVariables (69)
DeriveGeneric (66)
TupleSections (59)
BangPatterns (59)
MultiParamTypeClasses (56)
FlexibleInstances (33)
FlexibleContexts (31)
MultiWayIf (31)
TypeFamilies, TypeOperators (29)
DuplicateRecordFields (17)
FunctionalDependencies (15)
DisambiguateRecordFields (14)
MonadComprehensions (12)
BinaryLiterals (11)
RecursiveDo (10)
Other safe extensions (there was no feedback against having them on by default):
ParallelListComp (7)
PartialTypeSignatures (6)
TypeApplications (4)
RecordWildCards (4)
PatternSynonyms (4)
EmptyCase (3)
InstanceSigs (3)
KindSignatures (3)

I would exclude the following:

TypeApplications - too new
DisambiguateRecordFields + DuplicateRecordFields - too new
PatternSynonyms - too new
TypeFamilies - as much as I like them, they seem too new.  At once, they are popular and effective.
KindSignatures - perhaps this is too stringent, but it seemed to me like we aren't really sure what the kind syntax will be (* vs Type).  Has this been decided for sure?

Not sure:

MonadComprehensions - seems like it could cause type ambiguity for code copied from somewhere that doesn't expect it.
PartialTypeSignatures is new, but this is mostly a dev feature so it seems reasonable for its behavior to change a bit.  Seems like something we will for sure want.
DeriveGeneric - I'm not sure we want to codify this just yet.  This one is really popular, though
RankNTypes - complex to support
RecordWildCards - it's nice at times, but not sure we want to codify something that makes local scope resolution require datatype reification.

So, without the ones I want to exclude and the ones I'm not so sure about, we get:
LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns, MultiParamTypeClasses,
FlexibleInstances, FlexibleContexts, MultiWayIf, TypeOperators, FunctionalDependencies,
BinaryLiterals, RecursiveDo, ParallelListComp, PartialTypeSignatures, EmptyCase, InstanceSigs

Here, winterkoninkje mentions that FlexibleInstances may also be a little ill defined with regard to how liberal it is https://www.reddit.com/r/haskell/comments/4gtb73/ann_haskell_prime_2020_committee_has_formed/d2mmz58

EmptyCase might not be a good default extension, could allow nonsense code if warnings aren't on (exhaustiveness checking)

Also not sure about TupleSections, like EmptyCase,  this extension can turn syntax errors into more confusing type errors (or, with sufficient polymorphism, incorrect code).

From Richard Eisenburg https://mail.haskell.org/pipermail/haskell-prime/2016-May/004097.html

MultiParamTypeClasses: Can't these be used to create incoherence? I seem to recall hearing this once. I'm in general in favor of including these, but would want to reflect on the coherence question a bit.

I'm also not sure about RecursiveDo.  Currently the type errors you can get with it are really poor.  You can't really tell which recursive bind is the issue.  I usually use mfix directly instead.

I'd like to see this included as well, even though this problem is largely solved for me by custom stack templates. Perhaps we should try to define a seriously hamstrung list of popular extensions that 99% of Haskell programmers turn on? Like, OverloadedStrings-level popularity. Then, at least, the feature would be in the codebase and could be added to relatively easily.
Here's my list:

[ ] OverloadedStrings
[ ] LambdaCase
[ ] TupleSections
[ ] InstanceSigs // not a lot of people use this, but I always do
[ ] RecordWildCards

What's the problem we're trying to solve?
I'm using megarepos, and instead of this approach, I'd like to say "use the same extensions as that package".
The problem I need to solve is bloat in the files.

There are two possible problems to solve:

Pick a set of extensions that are good for a GHC spec.  This would be a conservative core of "blessed extensions".  It's with this attitude that I started the issue.

Pick a set of extensions that most people would reasonably want to use with their project.  This can be a less conservative set.

@alexanderkjeldaas Your use case is addressed by imports (see Not repeating yourself).

@mgsloan @mitchellwrosen Sorry for being silent on this one for so long.  One reason is a lack of cycles on my side.  But in this particular case I also just didn't know what to say.
I kind of like the idea, but I don't want to be the "standardizing" body.  Most extensions are at least somewhat controversial, e.g. while I like RecordWildCards and use it liberally, @soenkehahn has some valid concerns against its usage.
After giving this a thorough thought, I'm not in favor of defining any lists of "recommended" language extensions in hpack itself. BUT: I would love to offer some extension mechanism that allowsjjjjj third-parties to define such lists.
One rough idea on how to do this would be:
Extension provider
A third-party who wants to provide a list of extensions does the following steps:

Create a github repository named hpack-template, e.g. commercialhaskell/hpack-template
Create a file in that repository called language.yaml that specifies a list of default-extensions, e.g.# language.yaml
default-extensions:
  - OverloadedStrings
  - InstanceSigs

Commit, tag and push, e.g.$ git tag 2017 && git push --tags

User
The user can use a set of language extensions by specifying a GitHub user/organization and a tag name.  For our running example that would be:
language: commercialhaskell-2017

Hpack
When hpack sees a language field, it downloads the corresponding language.yaml (and cache it for future use).  For our running example it downloads
https://raw.githubusercontent.com/commercialhaskell/hpack-template/2017/language.yaml

It then merges all the fields in that file with what is specified in package.yaml, using the same merging logic we already have for CommonOptions.  There is technically no need to restrict the content of that file to default-extensions, anything that is part of CommonOptions can be supported.

Why require the extension provider to git tag?  A specific list of extensions should be immutable, and Git tags are "immutable by convention".

One limitation of the above approach is that tag names can not contain dashes, but I would be ok with that.
An other cost for hpack would be that we need to depend on http-client, but again I'm willing to do that.

Now I'm actually quite excited about this.  I'm willing to implement it if there is at least one person/party that wants to provide/maintain a list of extensions.

I really like the idea of allowing the community to come up with multiple competing sets of language extensions.
I would change hpack-template to something that doesn't mention hpack. Because other tools (e.g. stack, cabal or some IDE) might at some point use this information as well.

I would have said putting them in stack.yaml makes more sense - then a single team with multiple projects can share them easily. Unfortunately, that's not very easy with Stack: https://github.com/commercialhaskell/stack/issues/3137

@ndmitchell Hey, thanks for taking the time to leave feedback on this.  I see how this would be convenient.  My only requirement: hpack is currently not tied exclusively to stack, and for the sake of allowing future innovations I would like to keep it that way.  So I'm ok to make this mechanism work with local files.  We could try to design it in a way so that it indeed works with stack.yaml, but I'm not willing to hard-code stack.yaml.

The "best" workaround I've found is to use hpack specifications with !include in the package.yaml files, but it feels messy.

Yes, that is probably the best you can do today + I agree that it feels a bit messy.

@sol to clarify my remarks, I'm suggesting that actually having a shared listed of extensions between multiple projects doesn't make sense in hpack - I think it should live only in stack. I'm not suggesting hpack tie itself to stack at all.

@ndmitchell Hey! Thanks for clarifying!  Makes more sense now!

@sol A recent discussion caused be to revisit this issue.  I'd be willing to maintain such a list of extensions, and the results of question 21 of this survey will be quite informative.
Perhaps this is jamming too much stuff into one thing, but I'd also like

A tricky thing here is that baking these into hpack itself is potentially a poor user experience, because it means that picking a particular extension set forces usage of newer versions of hpack / stack.

Yes, absolutely, I would not want to bake this in.

Not sure how to handle this without adding stack-like downloading of the extensions from somewhere.  Maybe that'd be ok?

Are you ok with downloading from GitHub as I described above?

Are you ok with downloading from GitHub as I described above?

Yes, that seems good!  I don't think I like having it use different branches, though.  How about emulating stack templates and having a file per extension set: https://github.com/commercialhaskell/stack-templates
Maybe store them under github.com/sol/hpack-data/tree/master/extension-sets/ orso.  Good to have a top level extension-sets folder I think.

I don't think I like having it use different branches, though.

I propose to use tags (by convention).

How about emulating stack templates and having a file per extension set: https://github.com/commercialhaskell/stack-templates

Not sure if I understand correctly. Would that mean that one specific extension set is mutable?  What about build reproducibility?

A very quick and dirty proof of concept is at branch defaults-extension.
Example usage:
name: hello
defaults: sol-2017

library:
  ..

Which will use defaults from https://raw.githubusercontent.com/sol/hpack-template/2017/defaults.yaml.  All common options are supported.  No caching is done yet.  Error handling is rudimentary.  Warnings are not properly handled yet.  defaults only works top-level, section level not supported yet.
But I hope it is good enough to test and start developing extension sets (for better or worse any git ref can be used, which is convenient during development of extension sets, but for production you really only want to use a tag or a rev).
@mgsloan Can you give this a try and give feedback?

@sol Awesome, looks great!  I should be able to get around to trying it out in the next few days

@mgsloan Yes, please give it a try.  This will still require some major work before it will land on master (specifically, we want to allow defaults within sections and conditionals, which will require some major refactoring first).

I don't think I like having it use different branches, though.

I'm not too happy with the naming scheme myself and open to discuss it later on.  We may want to go for something very general first, e.g.:
defaults:
 github: hspec/hspec
 ref: 2.4.4
 path: .hpack/defaults.yaml

and then later on introduce some syntactic sugar for the common cases, e.g. we could use
defaults<EMAIL_ADDRESS>
as a shorthand for the above.
We could also consider making ref optional (defaulting to master) and creating a freeze file with the used rev for reproducibility.

A first version that accepts defaults in the form of
defaults:
 github: <user>/<repo>
 ref: <tag>
 path: <file>

is on master and will be included with the next release.
Follow up stories:

Add shorthand syntax (#241)
Accept defaults on a per section basis (#242)
Accept defaults recursively (we will probably get this for free with #242, but we might want to detect cycles)
Freeze ref if it is not a tag (or disallow everything but tags) (#243)

Hey @sol, sorry for dropping the ball on this!  I will try it with some real projects soon, now that I'm on vacation.


Stabilizing benchmark results

At the moment, gemm_bench.py passes --benchmark_repetitions=3 to stabilize benchmark results. Then the bench_summary_process function defined in bench_utils.py is returning the mean time (according to local variable names; I'm trusting that it's correct).
In my experience, when benchmarking on AMD GPU, the single most effective step to take to stabilize results is something like --benchmark_min_warmup_time=0.1 to run warm-up iterations that are discarded. Just 0.1 second seems to be more than enough.
If, after doing that, we still want to run multiple iterations to further reduce noise, then I would suggest taking either the min or the median of the iteration latencies, not the mean. The problem with the mean as an estimator is that if there is noise in the input N values, then there is still 1/N of that noise in the mean. The noise doesn't decrease fast was N increases, it only decreases in 1/N.  By contrast, if we run 3 repetition, then the median will be unaffected by one bad repetition, and the min will be unaffected by two bad repetitions.
Ideally, these mechanisms should be shared around bench_utils.py, not local to each benchmark such as gemm_bench.py.
WDYT @saienduri, @kuhar ?

+1. I think we can start small by adding this to all benchmarks and then start working towards sharing the implementation across these three harnesses. Would be also nice to start adding tests to the repo as it's starting to outgrow the initial simplicity that comes with short scripts.


The script doesn't seem to check "Global Admin" right

Created an installation user account with "User" right of their tenant directory (without Global Admin). Then executed the validation script on the following url.
https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-validate-identity
The script output was OK.
I think that this script doesn't check "Global Admin" right.

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

ID: b75ad79b-75e8-a40d-4bf8-7478eaacf2d4
Version Independent ID: 11ca6128-3947-55e9-7f1a-474e9dd1f116
Content: Validate Azure Identity for Azure Stack
Content Source: articles/azure-stack/azure-stack-validate-identity.md
Service: azure-stack
GitHub Login: @sethmanheim
Microsoft Alias: sethm

@ksekimoto Thank you for your feedback! We will review and provide an update as appropriate.


Feat/migrate scaffolder backend module utils to new backend

:heavy_check_mark: Checklist

[ ] Added tests for new functionality and regression tests for bug fixes
[x] Added changeset (run yarn changeset in the root)
[ ] Screenshots of before and after attached (for UI changes)
[x] Added or updated documentation (if applicable)

#1325

@punkle or @Xantier - Any chance one of you has a moment to review these plugin enhancements for the new backend?


User testing notes

Some configurations seem to take time to setup, so setting up then immediately playing a note doesn't work.
Running this all in one go will not play a chime:
alles.reset()
alles.send(wave=alles.SINE,ratio=0.2,amp=0.1,osc=0,bp0_target=alles.TARGET_AMP,bp0="1000,0,0,0")
alles.send(wave=alles.SINE,ratio=1,amp=1,osc=1)
alles.send(wave=alles.ALGO,algorithm=0,algo_source="-1,-1,-1,-1,1,0",osc=2)
alles.send(osc=2, note=60, vel=3)

But a delay before the last command will work. Or adding ..., note=60, vel=3) to play that note in the second to last command.
Setting an oscillator vel to 0 doesn't seem to work. Start a sine:
alles.send(osc=0, wave=alles.SINE, freq=220, amp=1)
alles.send(osc=0, vel=1)

Then try to turn it off with alles.send(osc=0, vel=0) and nothing happens. Using vel=0.01 effectively turns it off.
deb_menu.midi in the Max patch is missing from the repo. Not that I'm ready to send raw commands to Alles yet :) But I would be curious to see Max working. It looks like I have to paste in the broadcast address too, while import alles already detects it automatically.

thanks @kylemcdonald ! I think for your first issue, try adding retries=2 to alles.send. I think your wifi router may be dropping UDP packets. to confirm, try alles.sync() and report back here the reliability.
for your second issue, I can see that here too. I'll dig in. should be a quick fix and not intended
for the max examples, I'll clean those up asap and report back here

firmware fix for the second issue committed, apologies.

max patch updated & fixed in 6c87024 . added the deb_menu.mid file as well.

re:

It looks like I have to paste in the broadcast address too, while import alles already detects it automatically.

I don't think that's right. the broadcast address is the same on any network -- <IP_ADDRESS>. That's all that udpsend needs in Max. What you're seeing when you import alles or run the desktop ./alles speaker is the source multicast interface. By default, it's the first routable IP address in your system, and for most people is the only one you care about. But, if you are booting a separate router just for Alles but want to keep another interface around for internet or another network, you'll want to change this source IF, either via alles.connect(OTHER_SOURCE_IP) or using ./alles -I OTHER_SOURCE_IP. Unfortunately I haven't been able to figure out a way to force Max to use a secondary source interface. It always chooses the highest priority one in the macOS network preference pane. Not a problem for most use cases I'd wager


Pass Client Details as Arguments to Program

Can you implement passing client details such as user agent, ip address, etc to program?
Thank you

Duplicate of #108.


Does this mod conflict with the no telemetry mod?

By this I mean if I can use them both, if i need to remove the no telemetry one and how the implementation is done (is it just copy pasted from the other mod? is it a rewrite? is there any difference on how much it's blocked?)

You don't need to use them both, this one has an anti telemetry measure implemented.
View the implementation Here


sriov 搭配 calico时，sriov网卡的默认路由会被跳过创建

What happend:
sriov的bug：创建默认路由时，如果已经存在了则跳过创建。需要允许创建多条默认路由
https://github.com/k8snetworkplumbingwg/sriov-cni/pull/227
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
image path and image ID (from 'docker images')

Kubernetes version (use kubectl version):
Primary CNI for Kubernetes cluster:
NetworkAttachment info (use kubectl get net-attach-def -o yaml)
Target pod yaml info (with annotation, use kubectl get pod <podname> -o yaml)

/close due to https://github.com/k8snetworkplumbingwg/sriov-cni/pull/227 merged

/close