Setting firewall rules using icmp_type=0 or icmp_code=0 is broken / Statefiles are not usable with newest version

Description
When firewall rules using icmp_type, and icmp_code attributes are being managed through the ionoscloud terraform provider it stopped working in version 5.0.4 because of changes introduced in https://github.com/ionos-cloud/terraform-provider-ionoscloud/commit/9b3c28607adea9851c675e65a83ceb4f38f46c71 as those attributes were partly changed in their type.
Now the transformation to TypeInt has been continued in https://github.com/ionos-cloud/terraform-provider-ionoscloud/commit/2672a7031bff254d35928bd25e6e66698ed77b70 but unfortunately no state migration mechanism has been introduced.
How are statefiles supposed to be migrated to work with new versions?
Additionally when introducing the changes, the properties are being queried using d.GetOk instead of d.GetOkExists (see https://github.com/ionos-cloud/terraform-provider-ionoscloud/blob/master/ionoscloud/resource_firewall.go#L352-L361) which is not handling 0 type values. This causes resources being created with icmp_type or icmp_code set to 0 being rendered broken with no values being set.

Expected behavior
Old statefiles created with TypeString are being migrated to TypeInt and icmp firewall rules are successfully applied via the API.
This is what it looks like when resources are being applied with version 5.0.4.

Environment
Terraform version:
❯ terraform version
Terraform v0.15.3
on linux_amd64
+ provider registry.terraform.io/ionos-cloud/ionoscloud v5.2.18

Your version of Terraform is out of date! The latest version
is 1.0.10. You can update by downloading from https://www.terraform.io/downloads.html

Provider version:
❯ terraform providers

Providers required by configuration:
.
└── provider[registry.terraform.io/ionos-cloud/ionoscloud] 5.2.18

Providers required by state:

    provider[registry.terraform.io/ionos-cloud/ionoscloud]

OS:
❯ cat /etc/issue
Debian GNU/Linux 11 \n \l

Configuration Files
terraform {
  required_providers {
    ionoscloud = {
      source = "ionos-cloud/ionoscloud"
      #version = "5.0.4"
      version = "5.2.18"
    }
  }
}

variable "username" {}
variable "password" {
  sensitive = true
}

provider "ionoscloud" {
  username = var.username
  password = var.password
}

resource "ionoscloud_datacenter" "main" {
  name     = "test icmp"
  location = "us/las"
}

resource "ionoscloud_lan" "main" {
  datacenter_id = ionoscloud_datacenter.main.id
  public        = true
}

resource "ionoscloud_server" "main" {
  name           = "test-icmp"
  datacenter_id  = ionoscloud_datacenter.main.id
  cores          = 1
  ram            = 1024
  image_password = "password123test"
  # ssh_key_path      = var.private_key_path
  image_name        = "debian:10"
  availability_zone = "AUTO"

  volume {
    name      = "test-icmp"
    size      = 5
    disk_type = "SSD"
  }

  nic {
    lan             = ionoscloud_lan.main.id
    dhcp            = true
    firewall_active = true
  }
}

resource "ionoscloud_firewall" "audio_icmp" {
  datacenter_id = ionoscloud_datacenter.main.id
  server_id     = ionoscloud_server.main.id
  nic_id        = ionoscloud_server.main.primary_nic
  protocol      = "ICMP"
  name          = "ICMP"
  icmp_type     = 0
}

How to Reproduce
Applying the test resource from above.
Statefile issue

apply with version 5.0.4 (the one working before partly transitioning to TypeInt)
try to a terraform plan with version 5.2.18 with the existing statefile.

❯ terraform plan --var "username=$your-username" --var "password=$(command-to-get-password)"
ionoscloud_datacenter.main: Refreshing state... [id=3fcd870b-18b7-4ba5-a72e-20cdd527c626]
ionoscloud_lan.main: Refreshing state... [id=1]
ionoscloud_server.main: Refreshing state... [id=2309c2c0-49f7-4464-9f60-6d61bf4b2616]
╷
│ Error: a number is required
│
│   with ionoscloud_firewall.audio_icmp,
│   on main.tf line 56, in resource "ionoscloud_firewall" "audio_icmp":
│   56: resource "ionoscloud_firewall" "audio_icmp" {
│
╵

default-type issue with GetOk

apply the resource
check in DCD which resource has been created

Error and Debug Output
Already attached above
Additional Notes
References

https://www.terraform.io/docs/extend/resources/state-migration.html
https://github.com/hashicorp/terraform/issues/5694

Hi @Z3po thank you for raising this issue. We are currently investigating these changes and we'll get back to you shortly.

Hi @omungureanu is there anything we can help with?
Does it help if we're preparing a Pull Request to this for doing the state migration?

Hi @Z3po very nice bug description btw, we actually have a fix for this, but we want to go the route of actually reverting the Int fields back to string.  This is because Terraform has a problem with unsetting integer variables that can have valid '0' values. Even GetOkExists will just set '0' when removing a field, instead of setting it to empty(null). There are workarounds, like using '-1' to specify unsetting the value, but we think they're an ugly workaround.
One question, would you need a state migration function for this(int -> string) or is it enough to just revert the fields to String?

Hi @cristiGuranIonos,
thanks for your fast reply!
We weren't able to use the int type module because of our existing statefiles, therefore we don't need an int to string migration. Reverting the fields solves it for us.

Hi, please try with release v5.2.19 and let us know if the problem is fixed.
Thanks!

I've tried it with version 5.2.19 and I still get the following Error when running a plan:
Error: a number is required

I didn't take a deeper look yet of what's causing this...

Will look to see what might be the problem. Thanks!

Ah I think I found it...it's not at all with the icmp_code setting.
The problem seems to be the missing state migration for port_range_start and port_range_end values. These have been initialized in 5.0.4 as "string" and have since been changed to "int" therefore they are "not a number" when reading the statefile.

Port_range_start and port_range_end did not change recently. Only the documentation for the resource was wrong, they had been ints all along.
Is it defined inside a server resource, or separately? Can you attach the firewall rule that fails?
Thanks!

Oh I'm Sorry...I confused these actually...you're right the type hasn't been changed.
If I'm creating resources using my example definition from above and change the server definition to contain a tcp firewall rule:
resource "ionoscloud_server" "main" {
  name           = "test-icmp"
  datacenter_id  = ionoscloud_datacenter.main.id
  cores          = 1
  ram            = 1024
  image_password = "password123test"
  # ssh_key_path      = var.private_key_path
  image_name        = "debian:10"
  availability_zone = "AUTO"

  volume {
    name      = "test-icmp"
    size      = 5
    disk_type = "SSD"
  }

  nic {
    lan             = ionoscloud_lan.main.id
    dhcp            = true
    firewall_active = true

    firewall {
      protocol         = "TCP"
      name             = "SSH"
      port_range_start = 22
      port_range_end   = 22
    }
  }
}

Render it with the 5.0.4 version and then try to plan it with the 5.2.19 version I get this error.

Ok further digging this is still related to icmp_type and icmp_code not changed back to String everywhere. The default non-set value for icmp_code and icmp_type gets written as "" in the statefile and therefore it's not readable for the newest version.
When changing these to e.g. "null" in the statefile it works like expected.
I guess you found that as well already as you specifically asked for the inline :)

Yes, exactly overlooked changing back in inline resources. We will have a fix for this hopefully today or tomorrow at the latest.

So this will be included int he next release, right?
Do you have a timeframe so we can test if the issue has been really solved then?

Hi, yes the new release should be published on the terraform registry(5.20.21) right now. The pull request automatically closed the issue. I will re-open and you can close it if it is fixed.

@cristiGuranIonos we just tested your latest release and it was able to read our "old" statefile successfully.
plan and apply are working as expected.
Thanks for your help!


There is no "Create Storage Account.../Create Storage Account... (Advanced)" action in the context menu of the "Storage accounts" node

OS: Win10
Build Version: 20220825.16
Regression: Previous build (20220822.1)
Repro Steps:

Make sure resource groups by Resource Type.
Navigate to Azure view -> Expand the subscription -> Right click the "Storage accounts" node.
Check whether there are three actions in the context menu.

Expect:
There are three actions in the context menu.

Actual:
There is no "Create Storage Account.../Create Storage Account... (Advanced)" action in the context menu.

This is caused by https://github.com/microsoft/vscode-azurestorage/commit/0495143d28a102d069a710e13c0ecf15b6c33743 and is fixed by https://github.com/microsoft/vscode-azureresourcegroups/pull/337. However, we'll have to either release RGs before releasing Storage, or revert/update https://github.com/microsoft/vscode-azurestorage/commit/0495143d28a102d069a710e13c0ecf15b6c33743.
I'm sorta leaning towards releasing RGs, the changes are pretty small.


[2.x] Autotools build can detect the wrong libjpeg

To reproduce
$ podman pull registry.gitlab.steamos.cloud/steamrt/scout/sdk:beta
$ podman run --rm -it registry.gitlab.steamos.cloud/steamrt/scout/sdk:beta
# cd
# git clone -bSDL2 https://github.com/libsdl-org/SDL_image
# cd SDL_image
  (optionally apply #432 to fix #429)
# autoreconf -fi
# ./configure --enable-tests --disable-stb-image
  (AVIF and JXL libraries are not found, this is OK)
# make
# make check VERBOSE=1

Note that in the scout SDK, /usr/include/jpeglib.h and /usr/lib/x86_64-linux-gnu/libjpeg.so are provided by libjpeg-turbo8-dev (libjpeg-turbo built to be compatible with the ABI of IJG libjpeg 8), but /usr/lib/x86_64-linux-gnu/ contains both:
/usr/lib/x86_64-linux-gnu/libjpeg.so -> libjpeg.so.8.0.2
/usr/lib/x86_64-linux-gnu/libjpeg.so.8 -> libjpeg.so.8.0.2

and
/usr/lib/x86_64-linux-gnu/libjpeg.so.62 -> libjpeg.so.62.0.0

where the latter is provided by IJG libjpeg version 6b.
Expected result
All tests pass.
Actual result
ERROR: 03/11/24 17:37:23: Assert 'Load .../test/sample.jpg (JPEG loading error)': Failed

A CMake build from the same sources succeeds.
Looking at the build log, one thing that jumps out at me is:
-- dynamic libjpeg -> libjpeg.so.62

This means that the libjpeg whose headers we #include (libjpeg-turbo, SONAME libjpeg.so.8) is not the same as the libjpeg that we dlopen (IJG libjpeg, SONAME libjpeg.so.62). libjpeg is sufficiently fault-tolerant that it manages to detect this incompatibility and report a recoverable error, rather than just crashing.
I think this is the root cause for why I experienced #428 and #429, which can only happen in an error-handling code path.
Workarounds

Compile SDL_image on a system that only has one libjpeg. Production versions of the Steam Runtime are built on an Open Build Service instance in a minimal chroot, which does not exhibit this bug; but development builds are done in the non-minimal SDK environment, which does.
Or, build with CMake. Some distros like Arch have switched to building the SDL family with CMake, although as far as I know, the SDL team still recommends Autotools for building SDL 2.x.
Or, build with --disable-jpg-shared so that the chosen flavour of libjpeg is a hard dependency. We do this in Debian, Ubuntu, and the container-based Steam Runtime ≥ 2 branches; but we do not currently do this in Steam Runtime 1, so that the Steam Runtime 1 binary of SDL_image can be copied and pasted into games' portable non-Steam binary builds.
Or, build without --disable-stb-image so that stb_image is used instead of libjpeg (untested, but should work).

I tried to simulate this by putting libjpeg-turbo and ijg libraries in the same place, like:
$ ls -l ~/x2/lib/*
total 1200
lrwxrwxrwx. 1 ozkan ozkan     16 Mar 11 21:26 libjpeg.so -> libjpeg.so.9.6.0
lrwxrwxrwx. 1 ozkan ozkan     17 Mar 11 21:28 libjpeg.so.62 -> libjpeg.so.62.0.0
-rwxr-xr-x. 1 ozkan ozkan 291256 Dec 10  2013 libjpeg.so.62.0.0
lrwxrwxrwx. 1 ozkan ozkan     16 Mar 11 21:26 libjpeg.so.9 -> libjpeg.so.9.6.0
-rwxr-xr-x. 1 ozkan ozkan 929643 Mar 11 21:26 libjpeg.so.9.6.0
drwxrwxr-x. 2 ozkan ozkan   4096 Mar 11 21:26 pkgconfig

.. and then, configuring SDL_image like LDFLAGS=-L~/x2/lib ../configure --disable-stb-image
gives me -- dynamic libjpeg -> libjpeg.so.62
When both are present:

Which one do the headers actually belong?
Which one does configure pick for you? and ..
which one do you really want?

Linking a project with -ljpeg will select libjpeg.so -> libjpeg.so.9.6.0. So the headers (should) belong to 9.6.0.
CMake selects the correct library by following the symbolic links and then looking in the same directory for other files linking to libjpeg.so.9.6.0, of which it selects libjpeg.so.62.
libjpeg.so -> libjpeg.so.9.6.0 -> libjpeg.so.9.

* [To] Which one do the headers actually belong?

In my reproducer, libjpeg.so.8.

* Which one does configure pick for you?

libjpeg.so.62 (I think because 62 is more than 8, even though actually it's a strange way of writing 6b and is semantically more like 6.2)

* which one do you really want?

Whichever one the headers and the libjpeg.so symlink belong to, which in my case is libjpeg.so.8.

That's a fundamental deficiency of find_lib. Do we not have a way of following lib*.so symlinks by common shell tools?

For my use-case, it would be enough to have a configure option or an AC_ARG_VAR that lets me say "don't auto-detect, I'll tell you the right answer: it is libjpeg.so.8".

For my use-case, it would be enough to have a configure option or an AC_ARG_VAR that lets me say "don't auto-detect, I'll tell you the right answer: it is libjpeg.so.8".

That actually sounds like a good solution to me

Do we not have a way of following lib*.so symlinks by common shell tools?

Messing with readlink result might help with this?

Messing with readlink result might help with this?

It might be better not to make this critical-path for SDL 2.8.x.

Let's go with your AC_ARG_WITH solution then (but we should make it for every lib-to-be-detected in there.) Do you have a patch?

#434 does this for libjpeg, by overloading --enable-jpg-shared to take three classes of value:

literal no: link libjpeg in the normal way (not using dlopen), as is done in e.g. Debian
literal yes: auto-detect what to dlopen
anything else: dlopen that SONAME

In practice, I think libjpeg is the only one of the libraries we link that has multiple competing implementations, and also the only one where the highest number is not necessarily the "best".
We could extend the same treatment to avif, jxl, png, tif relatively easily.
We cannot easily do the same thing for webp, because webp dlopens two libraries, not just one - so we'd have to invent a new --enable-webpdemux-shared=SONAME or something. I'd prefer not to get into that for 2.x, and certainly not for 2.8.x.
For 3.x, Autotools has gone away completely, which is part of why I don't think it's necessarily worth investing a whole lot of effort in it.


Implement delta image creation function

As discussed in #27 and #28, there will need to be some way to compare the two images (the baseline and the newly generated one), and confirm that the image is the same image.
This issue covers the implementation of the delta image creation as well as verification that the screenshots match.
Originally I thought it might be best to have the plugins handle the logic for verification themselves, but now I think it might be wiser to let the VisualParityValidation object handle that since it will be shared across all storage methods, Instead, the plugins can be supplied with only the baselineID of the image and then they will return the image itself. The above tickets will be edited to reflect this.
Ideally, the number of dependencies added to the project to enable this should be 0, but it might be wise to use an image processing library to compare the images and to produce the delta. If that is the case, the Pillow library (https://python-pillow.org/) might be useful

Pillow is a library with no other dependencies, which as far as things go is pretty good. It also uses C++ code to do all the image processing, it seems, which might be a smarter plan than trying to do it on my own


Add a pass to convert dense constant on vectors to tensors.

Just in case if @qedawkins or @Groverkss need this


Datepicker doesn't position correctly horizontally

When the component is nested in a positioned element, such as a bootstrap column, it positions the picker widget incorrectly. Currently, it looks like it attempts to calculate a horizontal position, but it doesn't use the calculation and fixes the style to right: 40 in the onClick function.

Putting style={{positon:relative}} on the wrapping div in DateTimeField.js seems to fix things.
Although, to take it a step further, is there a reason not to make DateTimePicker the root node? I've experimented with eliminating the wrapping div and making DateTimePicker the root node and putting the input and span elements as its children. That seems to make it more flexible with other html elements.
For example:
<div className="form-group">
    <label htmlFor="datepicker-end-date" className="control-label">End Date </label>
    <DateTimeField   id="datepicker-end-date" />
</div>

will not work display inline out of the box because the wrapping div will cause a line break.

import 'react-bootstrap-datetimepicker/css/bootstrap-datetimepicker.min.css';
you will get all properly


Create networkpolicys to talk to operator

You could argue that this is out of scope for the operator but I want a discussion around it.
If we deploy grafana instances in namespaces that isn't the same as the grafana-operator we will get issues with networkpolicy assuming that the cluster admins have set good default settings.
This will create issues.
From a user point of view it would be nice to setup a networkpolicy that enables the operator to talk to the instance that it creates.
On the other hand this operator already got sooo much rbac access, giving it access to networkpolicy might be a step to long.
I'm leaning a bit that we shouldn't add this feature, instead provide example networkpolicies that you could use but nothing more then that.

Discussed and decided that this is best handled as an example rather than a behaviour of the operator.


Code in documents does not work

https://redux.js.org/introduction/getting-started#create-a-react-redux-app
It says I can create a react example project using
npx degit reduxjs/redux-templates/packages/vite-template-redux my-app

I executed that command with homebrew nodejs 16.X, and the my-app folder is not even created.

Redux has no relation to React. Please report this to Redux.

Understood.


Add some proper diagnostics to the API digester

Currently, errors in the JSON input data for swift-api-digester cause assertions to fail. Naturally, these errors don't indicate the source location of the problem or any other useful data about it. This PR makes us able to properly diagnose errors using DiagnosticEngine and adds errors for five stringly-typed fields, such as object keys and DeclKinds.
This definitely needs to be reviewed before it gets merged, because I'm not sure I'm going about this the right way—some parts of APIContext here end up duplicating the functionality of ASTContext, so it might make more sense to use an ASTContext instead, even for subcommands which don't need to manipulate an actual AST. Suggestions are welcome.
(I know that swift-api-digester is intended to be a test tool, but even test tools can benefit from a little polish sometimes—one of these errors made updating stdlib-stable.json after a rebase much easier.)

@swift-ci please smoke test


Add squarey_runs_away_from_the_fireball

I'm submitting on behalf of Jack Mole (my cousin who is too young to have a GitHub account). We visited over the CNY break and built this game together.
Your checklist for this pull request
About your game
This game is a two-player game where the fire needs to catch "Squarey" (a character in my cousin's cinematic universe). WASD controls Squarey and IJKL controls the fire.
After 30 seconds, press any key to restart. You win if you survive 30 seconds.
Code
Check off the items that are true.

[x] The game was made using the Sprig editor.
[x] The game is placed in the in the /games directory.
[x] The code is significantly different from all other games in the Sprig gallery (except for games labeled "demo").
[x] The game runs without errors.
[x] The name of the file/game contains only alphanumeric characters, -s, or _s.
[x] The game name is not the same as the others from gallery

Thanks for PR!

how old is your cousin? 👀

how old is your cousin? 👀

he's in Year 5 (Grade 5) at school!

Good game! Should the timer continue after Squarey's death?

Done!

how old is your cousin? 👀

he's in Year 5 (Grade 5) at school!

WOW!


Add ec test command that mimics conftest test & supports the appstudio output format

The new ec test command acts like plain conftest, but supports an additional output format appstudio which creates a TEST_OUTPUT style json for use in a Tekton result.
HACBS-2376

Latest revision has suggestions from @robnester-rh included, but so far it's sticks with the viper dependency and the flag verbatim flag parsing from Conftest .

A followup might be adding support for restricting capabilities of OPA.

Let's merge.


PC cold boots during MNIST example on GPU (GF980Ti); PSU problem; reduce load?

After getting Tensorflow to work at all, now I've got another issue: I can run through the 20.000 training steps (within about 1 second; holy sh... that thing's fast) of the Deep MNIST example (code below). But after the last step my PC does a cold reboot. It just turns off hard without shutdown and reboots after a few seconds.
It appears to be caused by an undersized PSU. Gaming on the GPU however works fine so far...
So, is there any way that I can reduce the load on the GPU during usage of Tensorflow? I'd be fine if the MNIST example took 2 seconds instead of 1 if only my PC wouldn't reboot.
At the moment unfortunately I cannot afford a new PSU, spent my whole available budget on the GF980Ti.
Any ideas?

Oops, forgot the code. Here you go, the code I use to test my Tensorflow setup: http://pastebin.com/Wad9eRBE
It's not my own code. I'm not sure where I got it but at first glance it looked pretty much like the Deep MNIST example from the tutorials. Strange thing is: it converges to an accuracy of about 0.9, whereas the actual Deep MNIST example from the tutorials converges to about 0.99.
Anyway... I was, again, able to kind of solve it myself by throttling the GPU maximum power using the command
~$ nvidia-smi -pl 220

which, if I got it right, limits the power consumption of the GPU to 220 watts.

@HWiese1980
I have been encountering reboot problems like yours. However, reboot happens sometimes as early as importing tensorflow (loading *.so), and sometimes after running a few iterations of training. In this case do you this it's a PSU problem like yours? Since I have tested out loading Theano and the same problem occurs on loading Theano.

@stmharry Yes, I'd still say it's a PSU problem. The evidence is pretty much the same. Definitely sounds like an undersized PSU. I bought a Corsair HX750i several weeks ago and since then never again experienced these sudden reboots. So I highly recommend upgrading your PSU to something around at least 700 watts.


Make it possible to configure session authentication strategy

Add configuring SessionAuthenticationStrategy in the SSOConfigurer which is passed to the SAMLProcessingFilter. This is useful for example defining a SessionFixationProtectionStrategy which is used for changing the session id after saml login is done.

@ulisesbocchio would you have time to take a look at this?

@ulisesbocchio is this possible to merge here or do we have to fork the repo?

Looks good, gotta fix Travis ci config and will merge

@ulisesbocchio CI config should be okay now, oraclejdk8 did not work in xenial but with dist: trusty should be ok.

Thanks!

Thanks for merging! Are you planning to create a new release sometime soon?

We would appreciate the new release so we don't have to fork the repo.


changes.md: no longer needed

Ref #126
Signed-off-by: Vincent Batts<EMAIL_ADDRESS>

LGTM

LGTM


Extension of quacc: Adding Defect Generation and Processing Capabilities

[x] I have read the Developer Guide.
[ ] I have added unit tests to cover my changes.
[ ] I have updated the documentation and CHANGELOG.md file accordingly.

This pull request introduces two additions to the quacc package, specifically to support defect generation and calculations:
In quacc/recipes/emt/defects.py, we introduce the bulk_to_defects_flow function. This function provides a workflow to create and relax defects. The function allows users to specify the defect generator, the charge state of the defects, the methods used for relaxation and static calculations, and additional arguments for these processes.
In quacc/util/defects.py, two utility functions are added: get_defect_entry_from_defect and make_defects_from_bulk. get_defect_entry_from_defect is a helper function that creates a DefectEntry object from a Defect object, capturing information about a defect in a specific supercell structure. On the other hand, make_defects_from_bulk generates a list of defects. The function prepares a supercell for each defect, applies distortions using ShakeNBreak, and returns the defects as ASE Atoms objects.

@rwexler --- thank you for opening this PR! How can I help get this to the finish line? Are you looking for guidance on the code itself, suggestions of how to write unit tests, or none of the above? Let me know!

@arosen93, thanks for writing this code; I'm excited to contribute.
I would say that my goals are as follows:

Get this code to work remotely on my server (can you confirm that this worked on yours?)
Get feedback on the code and suggestions for writing unit tests
Extend to calculations with VASP


Add event generation when create/delete of balancers fails.

Closes #8760

Partial fix for #8760

Two nits if events are considered part of our contract (i.e. difficult to change).  LGTM though.
Thank you for fixing - I was looking at fixing as part of #8892, but then saw you had implemented this already :-)

@justinsb comments addressed, please re-check.
Thanks!
--brendan

LGTM - thanks again!


[Design Proposal] Modular Parameters

Modular Parameters Design Proposal
As a Bicep developer, I want to be able to import parameters from other bicepparam files, so that I can reuse parameters across multiple deployments.
In most deployment scenarios, there are parameters that are common across multiple deployments. For example, a location parameter is often used in multiple deployments. It would be useful to be able to define the location parameter in a single file, and import it into other .bicepparam files.
Also it would be useful to be able to define parameters in environment specific files, and import them into the main.bicepparam file. For example, a location parameter can be defined in dev.bicepparam and prod.bicepparam files, and the main.bicepparam file can import the location parameter from the dev.bicepparam file when deploying to the dev environment, and import the location parameter from the prod.bicepparam file when deploying to the prod environment.
Goals

I can import parameter files into others with an import directive

Parent GitHub Issue: Bicep Parameters Upcoming Features #10777
Design Considerations

All parameters are exported by default

No special syntax is needed to export parameters

Able to import .bicepparam files (more than one import is possible)

This is to avoid having to define all parameters in a single file

No circular imports

This is to avoid infinite loops

No duplicate parameters, name collision will result in an error

This is to avoid ambiguity

No import all parameters from a file, only able to import specific parameters

This is to avoid importing parameters that are not needed, to avoid name collisions, and avoid failing deployments because of future changes to the imported file

Able to import parameters from a file that is not in the same directory as the importing file

This is to avoid having to define all parameters in a single directory, so parameters can be grouped by functionality and split into different directories

Able to import parameters from a file that is resolved using readEnvironmentVariable() function

This is to allow importing parameters from environment specific files

Proposed Solution
Syntax
import { <param_name_1>, <param_name_2>, <param_name_3> as alias_name } from '<path_to_bicepparam_file>'

Scenario 1
Combine parameters from the main.bicepparam, and two different .bicepparam files;
// shared.bicepparam
param location = 'eastus'
param sqlPwd = 'p@55w0rd!'

// module_specific.bicepparam
param location = 'westeurope'
param storageName = 'importantstorage'

// main.bicepparam
using './main.bicep'
import { sqlPwd } from './shared.bicepparam'
import { storageName } from './module_specific.bicepparam'
param location = 'westus'
param name = 'bicep'

// compiled.json
{
  location: 'westus'
  sqlPwd: 'p@55w0rd!'
  storageName: 'importantstorage'
  name: 'bicep'
}

Scenario 2
main.bicepparam file imports parameters and alias one of the parameters, so it'll be renamed.
// shared.bicepparam
param appName = 'app_1'
param sqlPwd = 'p@55w0rd!'
param sqlServerName = 'sqlServer'

// main.bicepparam
import { appName, sqlPwd as sqlPassword } from './shared.bicepparam'
param name = 'bicep'

// compiled.json
{
  appName: 'app_1'
  sqlPassword: 'p@55w0rd!'
  name: 'bicep'
}

Scenario 3
Import parameters from a .bicepparam file, resolving the path of the .bicepparam using readEnvironmentVariable() function
// .env
env='dev'

// ./global/dev.bicepparam
param appName = 'app_1'
param sqlPwd = 'p@55w0rd!'

// main.bicepparam
import { appName, sqlPwd } from './global/${readEnvironmentVariable('env')}.bicepparam'

// compiled.json
{
  appName: 'app_1'
  sqlPwd: 'p@55w0rd!'
}

Scenario 4
Import parameters from multiuple .bicepparam file, resolving the path of the .bicepparam using readEnvironmentVariable() function
// .env
env='dev'

// ./global/dev.bicepparam
param appName = 'app_1'
param sqlPwd = 'p@55w0rd!'

// shared.bicepparam
param location = 'westus'
param name = 'bicep'

// main.dev.bicepparam
import { location, name } from './shared.bicepparam'
import { appName, sqlPwd } from './global.${readEnvironmentVariable('env', 'dev')}.bicepparam'

// compiled.json
{
  location: 'westus'
  name: 'bicep'
  appName: 'app_1'
  sqlPwd: 'p@55w0rd!'
}

Will there by a specific syntax for importing all param values from a file?

I like these ideas
Perhaps something a little cleaner
param location = import(location, ./foo.bicepparam) // This imports a single value
import(./bar.bicepparam) // This imports all values

The env variable idea could be done by extending the current var usage to the above
var env = 'dev'

param location = import(location, ./foo${env}.bicepparam)
import(./bar${env}.bicepparam}) // This imports all values

I'm not sure the named import would be needed with the above approach as any imported param should just be able to be referenced from the .bicep file.
Alternatively perhaps an include in the .bicep file pointing to any required bicepparam files would be a better approach?

I would like to see both a wildcard import to import all parameters from a given file in addition to selecting specific params.
How would name conflicts be handled between files? Personally, I'd prefer a preference towards specificity (e.g. import the specifically named import over a wildcard, but show a squiggly line and build warning indicating the conflict).

I would like to see both a wildcard import to import all parameters from a given file in addition to selecting specific params.
How would name conflicts be handled between files? Personally, I'd prefer a preference towards specificity (e.g. import the specifically named import over a wildcard, but show a squiggly line and build warning indicating the conflict).

Expanding on this, seen customers where they like the generate a parameter file for an entire environment which will support multiple deployments. Was wondering if we could then do selective filtering based on an initial import of parameters.
Rough code example of this idea
allParams = import { * } from './global/${readEnvironmentVariable('env')}.bicepparam
import { location, name } from allParams

I like these ideas Perhaps something a little cleaner
param location = import(location, ./foo.bicepparam) // This imports a single value
import(./bar.bicepparam) // This imports all values

in different places in bicep, we already have import syntax. it'd be better to reuse that syntax, so developers (especially the ones who are learning bicep) don't have to learn and remember two similar import syntax.

will this support shadow param?
for exmaple
default.bicep
param a int = 1
param b int = 2

eastus.bicep
import * from default.bicep

param a int = 3

eastus.json would be
{
a : 3
b : 2
}

we intentionally won't support everything syntax, the main reason is, eastus.bicepparam in your example can get new parameter definitions over time, to support "other" deployments, but it could fail the deployments, that uses eastus.bicepparam
I also mentioned this issue here; https://github.com/Azure/bicep/issues/12019#issuecomment-1781834468

I would like to see both a wildcard import to import all parameters from a given file in addition to selecting specific params.

Wildcard imports could be dangerous and can make the deployments that have no change, fail. (as mentioned here; https://github.com/Azure/bicep/issues/12019#issuecomment-1781834468)
I'd like to understand better, what's the use-case of a wildcard import, if there is an editor support and you can easily import required parameters?
I see wildcard import syntax is to make importing several parameters easily. is it still the case, if the editor helps you to import required parameters easily?

How would name conflicts be handled between files? Personally, I'd prefer a preference towards specificity (e.g. import the specifically named import over a wildcard, but show a squiggly line and build warning indicating the conflict).

bicep (vscode and vs extensions, language server, cli, etc.) parse bicep and bicepparam files not order-dependent ( at least, so far 😄 )
and we're not going to support wildcard import syntax.
so, developers should import parameters by their names, and if there is a conflict, developer should resolve the conflict.
alias syntax ( import { appName as name } from 'foo.bicepparam' ) can be used to resolve this kind of issues

Expanding on this, seen customers where they like the generate a parameter file for an entire environment which will support multiple deployments. Was wondering if we could then do selective filtering based on an initial import of parameters.
Rough code example of this idea
allParams = import { * } from './global/${readEnvironmentVariable('env')}.bicepparam
import { location, name } from allParams

I think it's a very interesting idea. Although how much I like the idea, I don't see better developer experience between these two code blocks;
allParams = import { * } from './global/${readEnvironmentVariable('env')}.bicepparam
import { location, name } from allParams

import { location, name } from './global/${readEnvironmentVariable('env')}.bicepparam

in fact, the first proposal seems more complex, and, longer to type 😄
two import syntax does two different things (import but don't add parameters to context, and import and add parameters to context) could be confusing, too.

I'd like to understand better, what's the use-case of a wildcard import, if there is an editor support and you can easily import required parameters?

Bicep is already subject to a wall of parameters with their comments and decorators, and large multi-line object declarations due to its aversion to commas. I'd really rather avoid further polluting the top of my file with additional lengthy imports that would effectively do the same thing as a wildcard import.

User-defined data types support wildcard imports and a mix/match style. It doesn't feel like a great future developer experience to have different (but near-identical-looking) import syntaxes based on what's being imported.

More to the point, developers have been spoiled and are fairly used to having the option of wildcard imports. They're extremely common in other languages. I've got to imagine there'd be a sizable number of issues over time of new Bicep developers inquiring as to what they're doing wrong in that their wildcard import statements don't work for parameters, but they do for user-defined types.

If I'm dropping all my parameters in some file to avoid some typing, I'd like to save myself additional time and just insert an import * from '../my.params at the top of all of my files. It seems like an unnecessarily ceremonial step to narrow the imports from all to a select few.

Even with some editor support, it's a poor experience in Resharper already when I drop in a wall of new types into a class and inevitably have to go one by one through the new types to have it locate and add the correct using statement for each. Given the opportunity, I'd rather avoid a repeat of that poor UX here as well.

We'd like to have a conservative approach here

That seems more opinionated than conservative. Why go out of the way to deliberately take away the choice from developers and make the language less consistent?
Without wildcard, adding a shared parameter results in modifying all parameter files that use it. Whether I have editor support or not, every file needs to be modified, every file is changed in git, and every file needs to be reviewed. And probably doing the change without editor help will be quicker.

Just catching up on the community calls. Are you still looking for feedback?
Is this work already underway?

Would love to see this feature. There is so much copy and paste params across my .bicepparam files

Is this far from finishing? This would finally let me move away from having to use CUE lang for parameters...

I believe we are getting close to getting this done and released as an experimental feature. @stephaniezyen / @polatengin can provide a more precise ETA.

we have a draft PR is up (https://github.com/Azure/bicep/pull/13900)
our plan is to make it to the next release, behind a feature flag.

Some comments here: https://github.com/Azure/Bicep/pull/13900/#issuecomment-2091058063

Are we any closer to this being merged in yet?
I have been eagerly watching the releases and its not appeared yet :(

@ryancolley Unfortunately, we've had a longer delay than anticipated due to design decisions and changes. However, we're hoping to have it out as an experimental feature by the end of this month (hopefully)!

I think this new design change i a breakaway from the traditional way of thinking about defining parameters, and i think it will be worse because of it.
I am a huge fan of any input being explicit for any deployment, so when you look at a bicep + pram file you can se what actual input parameter is being used and what is still missing.. or optionals being set/not set.
with this you now have:
a: several param files
b: value set in a 'shared' param file will be set at deploytime, even if you didn't want to set it.
from my experience you should be able to extend the definition of a thing, but not the invocation/implementation (class can be expanded using inheritance or extended in js/typescript, but once you call that class you have to provide all required arguments)
now i'm not against having a shared param structure that can set commonly defined values, however this should be a "opt in", like you already do in "import":
// base.bicepparam
using none

param foo = 'foo'
param bar = 'bar'

// main.bicepparam
using 'main.bicep'

import * as shared from 'base.bicepparam'

param foo = 'bar'
param baz = foo
param bar = shared.bar
param other = shared.foo

// compiled.json
{
  foo: 'bar'
  bar: 'bar'
  baz: 'bar'
  other:'foo'
}

this way it is no question as to what param is being used where.

@WithHolm isn't the capability you're asking for already supported today?

main.bicepparamusing 'main.bicep'

import * as shared from './shared.bicep'

param foo = 'bar'
param baz = foo
param bar = shared.bar
param other = shared.foo

main.bicepparam foo string
param baz string
param bar string
param other string

shared.bicep@export()
var foo = 'foo'

@export()
var bar = 'bar'

To answer some of the concerns you raised:

a: several param files

True, but it's a choice - only if the user wants to structure their code this way. IMO the following semantics are important to avoid surprise:

Overriding should require an explicit opt-in; accidental overriding would result in an error.
Extraneous parameters (supplied, but not used in .bicep) should result in an error.
Missing parameters should result in an error.

b: value set in a 'shared' param file will be set at deploytime, even if you didn't want to set it.

Given the above semantics, I can only see this causing a problem in the case where the user wants to rely on the parameter default value in the .bicep file, but has accidentally overridden it in the shared.bicepparam file - all other cases would result in an error or an explicit opt-in.
In this example, the behavior doesn't feel particularly surprising to me. If the user has opted in to using default values, they have already opted to move away from explicitly setting parameter values in their .bicepparam file, and have moved values into a different file (the .bicep file).

My feedback from the pull request:
I find the proposed design very limited. As far as I understood from the meeting the following things are not possible:

Intelisense for shared bicep parameters files
multiple extends statements
ability to nest shared bicep parameters files
ability to merge (union) parameters of type object and array. Merge tags scenarios
support for variables

I think better approach would be to have something like:
// shared.bicepparam
using 'shared'
using 'main1.bicep'
using 'main2.bicep'

In this scenario you are clearly defining that this is shared bicep parameters file. Also additionally you provide two (or more if you want, these are optional statements) bicep files to serve as intelisense for the shared file. In this scenario when you define that this is shared bicep parameters files any errors related to required parameters are turned off. In VSC you can still see from intelisense if specific parameter is required or not. You can also see the description for those parameters. In case main1.bicep and main2.bicep contains the same parameter let's say location and that contains two different descriptions upon hovering the parameter when added you can see the description for both. In summary you still get intelisense and other information like description, allowed values, etc, but without the errors you would get in regular bicep parameters files.
With that said I would like to see support for the rest of the missing features as well:

multiple extends statements
ability to nest shared bicep parameters files
ability to merge (union) parameters of type object and array. Merge tags scenarios
support for variables

Would also be nice that if you can declare which parameters from extends statement you would like to add instead of adding everything. Similar to how it is in import statements.
With the support for variables would be good to see their value when you use them on other parameters when you hover over the variable.
It would really make sense if all these features are released at once otherwise it is best to be preview feature until every feature is added.

@slavizh - thank you for sharing your thoughts! @stephaniezyen is going to work on organizing all feedback we're receiving on this new capability, and use this to prioritize further changes.

@slavizh - Hi Stan, I've opened issues for each of the features you listed - like Anthony said, we're planning on putting together feedback on improvements we want to make for Extendable Param Files as well as .bicepparam files as a whole.
I failed to mention in the community call, so that's my mistake, but this is an experimental feature for now! We want to receive all feedback on usage and any improvements we may want to make before making it a public feature like you mentioned.

@stephaniezyen Thanks Stephanie!


Bug: self.warn is not a function

I don't see anywhere where self.warn should be defined, and I don't see it coming from companion core.
According to sentry this error has been logged 72k times in 2 days

That'll explain why I wasn't getting any errors.

Fixed by #5


Update index.html

Explanation of the Additions:
Smooth Scroll for "Go to Top" Button:
Added a script to smoothly scroll to the top when the "Go to Top" button is clicked. The button visibility toggles based on the scroll position. Dynamic Footer Loading:
Added a script to fetch and insert the footer content dynamically. Voiceflow Chat Widget Configuration Options:
The existing script is kept but more configurations can be added as needed. Conditional Loading of Scripts:
Added a script to conditionally load email.js only if a certain condition is met.
Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state "None”]
Description
[Please include a brief description of the changes or features added]
Type of PR

[ ] Bug fix
[ ] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes]
Checklist:

[ ] I have performed a self-review of my code
[ ] I have read and followed the Contribution Guidelines.
[ ] I have tested the changes thoroughly before submitting this pull request.
[ ] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[ ] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

Conflict issue


Wrong platform specific VSIX installed by marketplace if not all are yet validated

We just published 1.8.1 (prerelease) of the C/C++ extension to the marketplace.  I watched my local VS Code instance pick up the updated version, which promptly failed to execute properly.  I noticed the following within it's .vsixmanifest:
<Identity Language="en-US" Id="cpptools" Version="1.8.1" Publisher="ms-vscode" TargetPlatform="win32-arm64"/>

This was on x64 Windows 11, yet the ARM64 VSIX was installed.
I actually encountered what was undoubtedly the same issue the last time we published, but was unable to reproduce it.  It looks like the marketplace is updating clients to mismatching platform-specific VSIX's if the matching VSIX has not yet completed 'validation'.  This issue only occurs for a brief window of time after we publish our VSIX's.  But, I believe any user encountering this issue will need to delete the extension from their system (as Uninstall and reinstalling will reuse the cached extension folder).

Version: 1.63.2 (user setup)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:40:02.816Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.22000

@Colengms
When you said you noticed different target platform property in.vsixmanifest  is it in the vsix downloaded by VS Code? If so, may I know the name of the VSIX? We generally have the target platform in the name of the vsix.

@sandy081 This is with the C/C++ Extension.  We also include the name of the platform in the VSIX name, so in this case I was expecting cpptools-win64.vsix and received cpptools-win-arm64.vsix.  However, I did not see the name of the downloaded VSIX itself, only the uncompressed contents in the extensions directory (including its .vsixmanifest), as it was downloaded and installed (upgraded to) by VS Code itself, not me.  (That is the bug).
As we publish (updates for) each of our platform-specific VSIX's (with separate command lines), there is a window of time in which the marketplace is "validating" each one, during which time VS Code appears to download and install (upgrade to) an incorrect VSIX, undoubtedly because it incorrectly identifies an update (for another platform) while the updated VSIX for the appropriate platform was still in "Validating" state.
Not sure how much more info I can give.  To reproduce the issue, it's necessary to publish a new version of multiple platform-specific VSIXs (of equal versions) to the marketplace and reload VS Code while some VSIX's are still indicated as "Validating" on the marketplace web site.  This reproduces auto-update to an incorrect VSIX each time that we do this.

@Colengms I am bit confused because, even though MP provides win32-arm64 vsix VS Code does not install it on win32-x64 platform, because it fails the compatibility check. I confirmed this behavior by having a test extension that supports win32-x64 and win32-arm64 platforms and publishing an update only for win32-arm64 platform. Hence I am wondering if VS Code is really installing win32-arm64 vsix on win32-x64 platform or the MP is returning it wrongly. If you are able to reproduce, can you please help me in providing following information?

Open CachedExtensionVSIXs folder and remove all VSIXs - You can find this folder in the parent folder of your user settings file.
Open Shared Process Developer Tools (F1 > Toggle Shared Process) and go to network tab
Try to reproduce the issue
In the network tab, share the URLs used to download the VSIX from the MP. For eg: https://sandy081.gallerycdn.vsassets.io/extensions/sandy081/999-pse-win/0.0.1/1631284756630/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-x64
Share the name of the VSIX downloaded in CachedExtensionVSIXs folder

Hi @sandy.  I've repro'ed this multiple times.  Once we publish our next version, I can possibly repro it again by upgrading (reloading the window) right after we publish, but it's a matter of getting the timing right (or wrong).  I can assure you that there is an issue here.  At no point did I attempt to install an arm64 VSIX on this x64 machine.  As I mentioned, that incorrect TargetPlatform content was present in the .vsixmanifest in the installed extension directory, which indicates that the wrong VSIX was extracted.
We have added an error message that will be displayed to users when the wrong VSIX gets installed.  I suspect we will get confirmation of this issue from users (if their timing is unfortunate) - possibly a small number of users each time we release an update.  We will route those users to this issue for further investigation.

I repro'ed a similar issue on an ARM64 Windows PC.  It downloaded the same x86 VSIX instead of the ARM64 one.  I suspect our x86 VSIX completed 'validation' prior to the other VSIX's,

I reproed the bug on Windows arm64 (latest Insiders, 1.65.0). CachedExtensionsVSIX has ms-vscode.cpptools-1.9.1-win32-ia32, url is "https://ms-vscode.gallerycdn.vsassets.io/extensions/ms-vscode/cpptools/1.9.1/1645748050823/Microsoft.VisualStudio.Code.Manifest?targetPlatform=win32-ia32". The expected result is win32-arm64. (Windows x64 didn't repro for me, i.e. it was correct)

@Colengms and @sean-mcmanus Thanks for sharing the information. It seems VS Code is installing

win32-ia32 vsix on win32-x64 platform
win32-ia32 vsix on win32-arm64 platform

This can be totally possible and I have to say VS Code is doing right thing here. As @Colengms said MP is returning available target platforms as soon as they are available.
@joaomoreno @prashantvc @SaiKanth007 @isidorn
I think we discussed this concern and I do not remember the outcome or recommendation we ended upon. To summarise, C++ extension is publishing platform specific extension for each target using CI (I suppose). It seems win32-ia32 target VSIX is being published & validated & available first and when user is on win32-x64 or win32-arm64 platforms, this VSIX is getting installed/updated.

Does MP has to stream line this and make them available all at once?
Shall we recommend extension authors to publish win32-ia32 vsix at the end?

@Colengms One thing which is not clear for me is following scenario

VS Code installing win32-arm64 vsix on win32-x64 platform

Meanwhile we discuss about first problem, can you please confirm if you are seeing the second problem and if so please share the logs as I requested.
Thanks

@sandy081 I think it would hard for the MP to figure out how long to wait until to make them all available at once.
Is the only corner case win32-ia32 or can this happen in other cases as well?
If this is the only corner case, then we can do a "tactical fix" in vsce that we always upload that one last.

We didn't repro the arm64 on x64 bug this time.
We can change our release pipeline to publish in order arm64 -> x64 -> x86 to see if that fixes it.

@sandy081 @isidorn  I think it would be fairly straightforward for you to create a repro of this without our assistance (so we did not have to tie the investigation of this issue with the releases of the C/C++ extension).  I believe it's entirely coincidental that the win32-ia32 build completed validated first this time around and deployed to mismatching platforms.  When we previously released, it was the win32-arm64 build that was deployed to my x64 machine, which is clearly incompatible.
I don't understand how it could not be an issue that platform-specific (emphasis on specific) VSIXs are deployed to platforms that do not specifically match the VSIX.  It would seem implicit that this should be the case, regardless of whether or not the VSIX happens to also be compatible with the target system.  IMHO, the correct behavior here would be for VS Code to not update the extension on any platform/architecture to using any VSIX that was not an exact match for that system.

@Colengms I'm guessing some extensions may not build an "exact" match vsix, but it seems like VS Code could check the current version's platform to determine that (i.e. if the current version is arm64 don't update to x64).

The documentaton here states:

When publishing platform-specific extensions, a separate package needs to be published for each and every platform that an extension supports. If no package has been published for a platform, the user will see the extension appear as disabled and it can not be installed.

And goes on to indiciate that each 'platform' is an os/architecture pair.

If it is not an issue when compatible but mismatching versions of VSIXs are installed, could someone point me to how that compatibility is determined?  We need similar logic for displaying an error (or warning) when the VSIX does not match or is incompatible.
x64 emulation on arm64 is available only on (a certain minimum version of) Windows 11, and not Windows 10.  Currently, I'm using semver.gte(os.release(), "10.0.22000"), but that does not take into consideration versions prior to support being added.
On macOS, x64 can be emulated on arm64 only if the emulation components are installed.  Do you do a check for x64 emulation in order to allow x64 builds to deploy on arm64 macOS?
Whether or not x64 or x86 is supported on Linux is complicated, due to arbitrary combinations of 32 and 64 bits userlands and kernels.  Have you devised a check for this such that x86 VSIXs can be deployed to x64 Linux systems?
Intentionally supporting non-matching but compatible VSIX auto-updating is actually very complex, on all platforms.  IMHO, it would seem a lot less problematic to require that platform-specific VSIX's match platforms exactly.  Or, perhaps allow multiple platforms to be specified in the same VSIX.

That seems fine to me...we can try it out for our next release in a day or so.

@isidorn Can you please update the platform specific extension publishing docs about this?

@sandy081 sure, I will update the docs. I do not want to make the docs too complex, so I will try to summarise this in one-two sentences. Thanks for tackling this.

Covered via https://github.com/microsoft/vscode-docs/commit/77e247e85bd8be3f61ffea45eb0ac299978f6fa3


Export that great node !

Is your feature request related to a problem? Please describe.
My problem is that I'm only interested in 1 node lol
Describe the solution you'd like
I'd like to install the Get Resolution node nothing else
Describe alternatives you've considered
I considered asking Claude or chatGPT how to do it, actually I did and it almost worked... I was so close x)
What did I miss ? Can you help please I tried but I think it's best to ask to a real coder !
Additional context
But I failed

crystools_get_image_resolution.zip

this has two parts, python and web you need to make changes on both :)

this has two parts, python and web you need to make changes on both :)

Do you mean... I will have to deal with Javascript stuff ? Oh no~~ haha okay thank you very much ^^
I'm guessing that's the part responsible for displaying or refreshing nodes, I tried to make a custom node before (completely different thing, not related to crystools) and I failed to implement the web... Now I know I need to investigate more.


bug: /usr/bin/imds fails with printf format in user-data

What happened:
I use /usr/bin/imds latest/user-data to get the instance user-data and get the error /usr/bin/imds: line 40: printf: `D': invalid format character at some point.
My user-data contains an URL with the sequence %3D ("=") which get interpreted by the "printf" command in the imds script and then fails.
What you expected to happen:
No error and the full user-data returned.
How to reproduce it (as minimally and precisely as possible):

Create an instance with user-data containing "%D"  (I use karpenter)
On the instance, run imds latest/user-data
See error

Environment:

AWS Region: N/A
Instance Type(s): N/A
Cluster Kubernetes version: N/A
Node Kubernetes version: 1.30
AMI Version: Amazon Linux 2023.6.20241111

I do not think that calling printf "$(cat $OUTPUT_FILE)\n" with no additional arguments is needed. A simple cat $OUTPUT_FILE; echo should be sufficient.
https://github.com/awslabs/amazon-eks-ami/blob/e297621e85ad0d6545a8d0d82db688f123976a32/templates/shared/runtime/bin/imds#L40
This is not blocking as I can read the user-data from the cloud-init command or file directly.

@vflaux thanks for the report! Should be fixed 👍


Fix rustup-init sha256sum check

Description:
sha256sum rustup-init.sha256sum expects there to be a file name rustup-init in the same directory as  rustup-init.sha256sum
Instead of messing with the original download path, I just copy the binary to the path where the sha256sum is placed, check it and then delete it. There might be a more efficient way with pipes or similar.
Tests passing on my machine
Test Passed!
🧪 Executing duplicate test for feature 'rust'...
⚠ Skipping duplicate test for rust because '/home/bstrausser/Git/features/test/rust/duplicate.sh' does not exist.
🧹 Cleaning up 2 test containers...
🧹 Removing container a7c1a0e866f3...
🧹 Removing container 01a2b8770ce2...

  ================== TEST REPORT ==================
✅ Passed:      'rust'
✅ Passed:      'rust_at_pinned_version'

closes: https://github.com/devcontainers/features/issues/961

@samruddhikhandale Addressed your comments.

@microsoft-github-policy-service agree


Crash on empty projection

The following query causes SIGABRT:
{
  "rels": [
    {
      "id": "0",
      "relOp": "EnumerableTableScan",
      "fieldNames": [
        "a",
        "b",
        "c",
        "d",
        "e",
        "rowid"
      ],
      "table": [
        "hdk",
        "frame_0b2323aca30249ef89a5575862d9d966"
      ],
      "inputs": []
    },
    {
      "id": "1",
      "relOp": "LogicalProject",
      "fields": [],
      "exprs": []
    }
  ]
}

We generally don't expect empty projections because SQL doesn't have any construction to select 0 columns. We also don't allow to select 0 columns through PyHDK proj interface. So, we can fix this issue by throwing an appropriate exception. But would that be good enough for you? What behavior do you expect?

An appropriate exception would be ok. Definitely, it is much better than a crash, because in case of a crash, the root cause is not clear.


Any plans for a new release version?

I realized the docs in master mention stuff that isn't published yet, is there any plan for a release soon?

I believe https://github.com/bwmarrin/discordgo/issues/944#issuecomment-847232482 still applies for the time being, until Discord finishes solidifying interactions.

Thanks for the update, I'll subscribe to that issue instead :+1:


Local development: how to set up on simulator?

Thanks for the great library. There is a lot going on here, trying to understand all the pieces that are necessary!

[ ] Works on simulator

Simulator is logged into iCloud, passwork keychain is enabled, biometrics are enrolled
Same configuration is available as release for associated domains/webcredentials (with ?mode=developer at the end)

[x] Works on a release build

Desperately trying to integrate this locally (on iOS simulator), and keep running into the same issue: "An unknown error occurred". Despite this, if I create a release build I am able to use the library.
Mac Console has some interesting messages from the simulator:
ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)"
Could not perform authorization: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)"
Device not configured for passkey requests: Error Domain=com.apple.LocalAuthentication Code=-7 "(null)"

Hi there!
Just to clarify:
The release build is working in the simulator, but the debug build is not?
What iOS Version are you running on the simulator?
I'm not able to reproduce this on a simulator running iOS 16.4, so a couple more details would be appreciated.
Error code 1004 usually indicates a domain issue so I would also recommend double checking your associated domain configuration (Try removing the ?mode=developer, should work fine without).

Thanks for the response and apologies yes, let me clarify.
Simulator has not worked in any configuration with-or-without mode=developer, with-or-without associated domain config. I have tried running localhost/.well-known/apple-site-association on http/https, various ports as well.
Release build on real devices works. Being able to try development against only "real" builds is just a painfully slower experience, as you might imagine. Would love to get a simulator flow working!
If you saying that you're able to successfully trigger passkey workflow on the simulator, would love to know any and all configuration that you set up. Xcode version? iCloud signed in or out? FaceID enrolled or not? Any additional configuration flags thrown on launch. Any help is appreciated!

Sure thing. I'm running Xcode 14.3, Simulator is on 16.4 as mentioned above. FaceID/TouchID is enrolled (AFAIK it has to be enrolled for passkeys to work anyways), not signed in to iCloud. Also not using any additional flags, just the debug build scheme.
You've mentioned running the associated domain endpoint on localhost. In my tests this was causing a lot of problems, which is why I switched to ngrok, might want to give it a shot and see if that helps.
Are you trying to run the example app from this repo or your own implementation?

@f-23 solid suggestion.
Went back to basics, looks like my debug and release builds differed in team ID, which stopped it cold. Thanks again!


Blocks do not drop when broken

The only block with a loot table currently is the Broken Spawner, so all other blocks in this mod do not drop as an item when you break them.

As this mod is a Tech Reborn addon, you should use Tech Reborn's wrench to pickup Industrial Reborn machines. Simply right-click while shifting to destroy the machine.

Tech Reborn machines can be mined with a pickaxe. If this mod aims stay in line with the expected behavior of TR machines, then your machines should also be breakable with a pickaxe.

https://github.com/Dmunch04/IndustrialReborn/assets/1904331/4c084dbe-955e-4f1b-b35d-cec2689facbb

You are indeed right. Loot tables for machines will be added in next update


Does Yi-1.5-Chat model use the standard CHATML template?

@richardllin @panyx0718 @Imccccc Hi all, could you please give some advice for this issue?
Does Yi-1.5-Chat model use the standard CHATML template? Is the bos_token <|im_start|> or <|startoftext|>? Is the eos_token <|im_end|> or <|endoftext|>?
Yi-1.5-34B-Chat-16K/config.json is not consistent with Yi-1.5-34B-Chat-16K/tokenizer_config.json.
When model generating or training, will the bos_token be added at the front of prompt?
As shown in Yi-1.5-34B-Chat-16K/config.json：
"bos_token_id": 1,
"eos_token_id": 2,

As shown in Yi-1.5-34B-Chat-16K/tokenizer_config.json：
"bos_token": "<|startoftext|>",
"eos_token": "<|im_end|>",

"1": {
"content": "<|startoftext|>",
"lstrip": false,
"normalized": false,
"rstrip": false,
"single_word": false,
"special": true
},
"2": {
"content": "<|endoftext|>",
"lstrip": false,
"normalized": false,
"rstrip": false,
"single_word": false,
"special": true
},
"7": {
"content": "<|im_end|>",
"lstrip": false,
"normalized": false,
"rstrip": false,
"single_word": false,
"special": true
}

Using standard chatml templates, bos_token and eos_token mainly depend on the tokenizer_config.json file and are not related to config.json.  Besides, during SFT, |im_start| will be added by default by template，such as here


[libsecp256k1] illegal argument: secp256k1_ecmult_gen_context_is_built(&ctx->ecmult_gen_ctx)

Hello brother. When i try to get my address from PK using the below code, it returns an error of [libsecp256k1] illegal argument: secp256k1_ecmult_gen_context_is_built(&ctx->ecmult_gen_ctx)
the coed is
#include <ethc/account.h>
#include <ethc/hex.h>
#include <ethc/keccak256.h>
#include <iostream>

using namespace std;

void test_eth_account_address_get()
{
    struct eth_account account;
    uint8_t privkey[32] = {0xdc, 0xdf, 0x91, 0xb7, 0xb2, 0x9c, 0x4c, 0x06,
                           0x77, 0x33, 0x1b, 0x65, 0x5c, 0x0c, 0x6c, 0xf4,
                           0xe7, 0x1b, 0x6f, 0x87, 0x19, 0x27, 0x3a, 0x11,
                           0x2e, 0xe6, 0x5b, 0x63, 0x9b, 0x88, 0x8f, 0xfa};
    char out[40];
    eth_account_from_privkey(&account, privkey);
    eth_account_address_get(out, &account);
    cout << out << endl;
}
int main()
{
    test_eth_account_address_get();
}

@mhw0 any result?

Hello. Interesting, I can't reproduce this on Mac. Is this random thing or happens every time?

It runs just fine on my machine. I think I'll need some linux machine to test this.

I've run into this issue as well. In my project, libsecp256k1 was introduced as a third party, and I'm not sure if it was the build issue that caused this problem.
So I modified the eth_ecdsa_pubkey_get function in ecdsa.c:
int eth_ecdsa_pubkey_get(uint8_t *dest, const uint8_t *privkey) {
  secp256k1_context *secp_ctx;
  // ....

  // secp_ctx = secp256k1_context_create(SECP256K1_CONTEXT_NONE);
  secp_ctx = secp256k1_context_create(SECP256K1_CONTEXT_SIGN |
                                      SECP256K1_CONTEXT_VERIFY);
  // ...
}

using this workaround the error is gone.
Later I built libsecp256k1 and the sample code separately trying to figure out why, but the issue just didn't occur. I didn't investigate further because of the time

Just commenting here as a clue

Hey @zzzzzzch thank you for the investigation! I'll take a look myself. Again, thank you.


[Transporter Error Output]: description length:10240931

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
Hello everyone, I finished my app make with Expo and now I want to upload to the AppStore (this is my first time doing this). I'm trying send to iTunes Connect but everytime i get this error, I already try:

https://github.com/fastlane/fastlane/issues/2294
https://github.com/fastlane/fastlane/issues/10196
And three differents networks

My Fastfile is this:

lane :beta do
ENV["DELIVER_ITMSTRANSPORTER_ADDITIONAL_UPLOAD_PARAMETERS"] = "-t DAV"
pilot(
ipa<EMAIL_ADDRESS>)
end

And taking advantage of the opportunity, and for those who have already published an app made with the expo the correct procedure is exactly the one to publish in the AppStore?

Generates the IPA
Send to iTunes Connect
And from there send to the AppStore

I've read all the expo documentation, but that part is not so clear.
Complete output when running fastlane, including the stack trace and command used

Captured Output
Command Used: beta
Output/Log

+------+--------+-------------+
|      fastlane summary       |
+------+--------+-------------+
| Step | Action | Time (in s) |
+------+--------+-------------+
| 💥   | pilot  | 0           |
+------+--------+-------------+

✅ fastlane environment ✅
Stack

Key
Value

OS
10.13.1

Ruby
2.3.3

Bundler?
false

Git
git version 2.13.2

Installation Source
/usr/local/bin/fastlane

Host
Mac OS X 10.13.1 (17B1003)

Ruby Lib Dir
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib

OpenSSL Version
LibreSSL 2.2.7

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
9.1

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE

fastlane files:
`./fastlane/Fastfile`
lane :beta do
  ENV["DELIVER_ITMSTRANSPORTER_ADDITIONAL_UPLOAD_PARAMETERS"] = "-t DAV"
  pilot(
    ipa<EMAIL_ADDRESS>    )
end

No Appfile found
fastlane gems

Gem
Version
Update-Status

fastlane
2.69.2
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

did_you_mean
1.0.0

slack-notifier
1.5.1

CFPropertyList
2.3.6

claide
1.0.2

colored2
3.1.2

nanaimo
0.2.3

xcodeproj
1.5.3

rouge
2.0.7

xcpretty
0.2.8

terminal-notifier
1.8.0

unicode-display_width
1.3.0

terminal-table
1.8.0

plist
3.4.0

public_suffix
2.0.5

addressable
2.5.2

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.6.3

babosa
1.0.2

colored
1.2

highline
1.7.10

commander-fastlane
4.4.5

excon
0.59.0

faraday
0.13.1

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20170404

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

fastimage
2.1.0

gh_inspector
1.0.3

json
1.8.3

mini_magick
4.5.1

multi_json
1.12.2

multi_xml
0.6.0

rubyzip
1.2.1

security
0.1.3

xcpretty-travis-formatter
1.0.0

dotenv
2.2.1

bundler
1.16.0

faraday_middleware
0.12.2

uber
0.1.0

declarative
0.0.10

declarative-option
0.1.0

representable
3.0.4

retriable
3.1.1

mime-types-data
3.2016.0521

mime-types
3.1

little-plugger
1.1.4

logging
2.2.2

jwt
2.1.0

memoist
0.16.0

os
0.9.6

signet
0.8.1

googleauth
0.6.2

httpclient
2.8.3

google-api-client
0.13.6

io-console
0.4.5

libxml-ruby
2.9.0

generated on: 2017-12-14

Same here, when trying to upload to iTunes Connect for Testflight.

Same here.

Same here,and I can't fine the new beta build in Apple TextFlight for a long time.I've tried several times.

I was able to upload successfully. But I still getting error [Transporter Error Output]: description length:2866414
15:05:15]: Going to upload updated app to iTunes Connect
[15:05:15]: This might take a few minutes. Please don't interrupt the script.
[15:05:42]: [Transporter Error Output]: description length:2866414
[15:06:27]: iTunes Transporter successfully finished its job
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main> DBG-X: Apple's web service operation return value:
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main> DBG-X:   parameter Success = true
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main> DBG-X: Unlocking token at path /Users/XXXXXXX_9112315.itmsp.token
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main> DBG-X: Releasing token file lock
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main> DBG-X: Removing token at path /Users/XXXXXXX_9112315.itmsp.token
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main>  INFO: Done performing uploadDone notification to Apple.
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main>  INFO: The package: /var/folders/lp/8hwt8lcx4695p3b1wm8_qj4c0000gn/T/d20171219-5483-1g11y85/9112315.itmsp has been successfully uploaded.
[15:06:27]: [iTMSTransporter]
[15:06:27]: [iTMSTransporter]
[15:06:27]: [iTMSTransporter]
[15:06:27]: [iTMSTransporter] Package Summary:
[15:06:27]: [iTMSTransporter]
[15:06:27]: [iTMSTransporter] 1 packages were uploaded successfully:
[15:06:27]: [iTMSTransporter] 	/var/folders/lp/8hwt8lcx4695p3b1wm8_qj4c0000gn/T/d20171219-5483-1g11y85/9112315.itmsp
[15:06:27]: [iTMSTransporter] [2017-12-19 15:06:27 EST] <main> DBG-X: Returning 0
[15:06:27]: iTunes Transporter output above ^
[15:06:27]: description length:2866414
[15:06:27]: Although errors occurred during execution of iTMSTransporter, it returned success status.```

I have been battling this error for a few hours over 2 days now and finally got a breaktrough after noticing the itmsTransporter command that is executed has not only the "-t DAV" parameter supplied by DELIVER_ITMSTRANSPORTER_ADDITIONAL_UPLOAD_PARAMETERS, but also "-t Signiant".
Manually executing the command line that includes "-t DAV -t Signiant" produces the error while executing the command without "-t Signiant" succeeds.

Mh, it doesn't look like it's a fastlane issue, but some server issues on Apple's side. Does this also happen when you use Xcode or the iTunes Transporter app to upload?

It's doesn't happen when I upload new build via Xcode. I'm using Xcode 9.2

For me this appears if I haven't filled out the external BETA required fields.

Got the same issue, partially solved it by disabling the firewall on macOS.
I say partially because I still get the error [Transporter Error Output]: description length:1656206, but the uploads are successful.

Any updates? We got our builds in i-tunes connect through pilot, but the error is very annoying :(

I'm also having this issue with XCode 9.2

Same here, see logs:
[10:55:06]: Login to iTunes Connect (****)
[10:55:10]: Login successful
[10:55:11]: Ready to upload new build to TestFlight (App: ***)...
[10:55:11]: Going to upload updated app to iTunes Connect
[10:55:11]: This might take a few minutes. Please don't interrupt the script.
[10:55:46]: [Transporter Error Output]: description length:416878

[10:56:47]: iTunes Transporter successfully finished its job
[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main> DBG-X:   parameter Success = true

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main> DBG-X:   parameter StreamingSettings = {LogStreamingEnabled=true, MultipartUploadsEnabled=true, AssetDescriptionStreamingEnabled=false}

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main> DBG-X: Unlocking token at path /Users/anka/.itmstransporter/UploadTokens/vm-ios-build.*****.itmsp.token

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main> DBG-X: Releasing token file lock

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main> DBG-X: Removing token at path /Users/anka/.itmstransporter/UploadTokens/vm-ios-build.*****.itmsp.token

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main>  INFO: Done performing uploadDone notification to Apple.

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main>  INFO: The package: /var/folders/8w/cxh_1fg96vld5bg4l6g4_0yh0000gn/T/d20180423-7367-1chud3m/1216841464.itmsp has been successfully uploaded.

[10:56:47]: [iTMSTransporter]

[10:56:47]: [iTMSTransporter]

[10:56:47]: [iTMSTransporter]

[10:56:47]: [iTMSTransporter] Package Summary:

[10:56:47]: [iTMSTransporter]

[10:56:47]: [iTMSTransporter] 1 packages were uploaded successfully:

[10:56:47]: [iTMSTransporter] 	/var/folders/8w/cxh_1fg96vld5bg4l6g4_0yh0000gn/T/d20180423-7367-1chud3m/1216841464.itmsp

[10:56:47]: [iTMSTransporter] [2018-04-23 10:56:47 CEST] <main> DBG-X: Returning 0

[10:56:47]: iTunes Transporter output above ^
[10:56:47]: description length:416878

I too get this error


fix: enumerable

Hmm I had a quick look over your PR and I think without any comment what the problem is and how your change solves this this will never be merged 🤷


Adding /bin to the PATH in ktest

so test work even if the user didn't update his environment.
@dwightguth please review.

did you try a fresh installation on a machine without a changed PATH?

No.

Tested without the path, and it works as expected. Can we merge this?

Thanks! You can merge.

Ah, I will create a new pull request in just a sec.


[Feature flags] Narrow down iterations and create final designs

Acceptance criteria

Now that we have a couple solid different directions of where to take this work, the goal of this issue is to thoroughly explore these directions and play them back to decide on some final design outcomes.

1. General guidance
Overview > Components tab
Tags in image cards:

[x] Mock up how to display the Feature flag tag in the cards.

Suggestion: Try putting them at the bottom of the card. Does there need to be a rule divider to separate the image from the content? Does the aspect ratio of the card need to change to account for that? How would multiple tags look in this scenario (like adding an AI tag)? Try using a smaller height tag.

Overview > Feature flag tab

[x] Mock up what this would look like from what Scott said in Slack.

Help > FAQs page

[x] Mock up how the content should be rewritten here to make the experimental information more clear while also referencing what feature flags are.

2. Component usage tab guidance

[x] Omit the following ideas for now: Accordions, Tags in anchor links, UI shell left panel tags.
[x] See what feature flags we currently have and show how the feature flag sections would play out on these pages within a full page flow. You could do multiple for the different versions you had of how to display these sections/notifications.
- Suggestion: Seems like Structured list and Tile would be good ones to start with.

Playback 1

[x] Playback explorations to designers, devs, and a11y on a call.
[x] Receive feedback and consolidate iterations

Playback 2

[x] Playback explorations to designers, devs, and a11y on a call.
[x] Make final outcomes.

Final specs: Figma file


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.7 to before v5.15.20",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=84f9bd12d46dbe8ac7d4b650a8fbb4c49657a38b",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dffeeca9268b221063c7a5a75719299b324c1acf"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "84f9bd12d46dbe8ac7d4b650a8fbb4c49657a38b",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "dffeeca9268b221063c7a5a75719299b324c1acf",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "net: ipa: prevent concurrent replenish\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15.20 by commit dffeeca9268b221063c7a5a75719299b324c1acf, it was introduced in version v5.7 by commit 84f9bd12d46dbe8ac7d4b650a8fbb4c49657a38b. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000270


Error using Makie: overwrites AbstractPlotting definition?

julia> using Makie
[ Info: Precompiling Makie [ee78f7c6-11fb-53f2-987a-cfe4a2b5a57a]
WARNING: Method definition contour() in module AbstractPlotting at /Users/anshul/.julia/packages/AbstractPlotting/NOT5R/src/recipes.jl:164 overwritten in module Makie at /Users/anshul/.julia/packages/AbstractPlotting/NOT5R/src/recipes.jl:164.
ERROR: LoadError: LoadError: cannot assign variable AbstractPlotting.Contour from module Makie
Stacktrace:
 [1] top-level scope at /Users/anshul/.julia/packages/AbstractPlotting/NOT5R/src/recipes.jl:165
 [2] include at ./boot.jl:326 [inlined]
 [3] include_relative(::Module, ::String) at ./loading.jl:1038
 [4] include at ./sysimg.jl:29 [inlined]
 [5] include(::String) at /Users/anshul/.julia/packages/Makie/YPDAk/src/Makie.jl:1
 [6] top-level scope at none:0
 [7] include at ./boot.jl:326 [inlined]
 [8] include_relative(::Module, ::String) at ./loading.jl:1038
 [9] include(::Module, ::String) at ./sysimg.jl:29
 [10] top-level scope at none:2
 [11] eval at ./boot.jl:328 [inlined]
 [12] eval(::Expr) at ./client.jl:404
 [13] top-level scope at ./none:3
in expression starting at /Users/anshul/.julia/packages/Makie/YPDAk/src/makie_recipes.jl:1
in expression starting at /Users/anshul/.julia/packages/Makie/YPDAk/src/Makie.jl:67
ERROR: Failed to precompile Makie [ee78f7c6-11fb-53f2-987a-cfe4a2b5a57a] to /Users/anshul/.julia/compiled/v1.1/Makie/iZ1Bl.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] compilecache(::Base.PkgId, ::String) at ./loading.jl:1197
 [3] _require(::Base.PkgId) at ./loading.jl:960
 [4] require(::Base.PkgId) at ./loading.jl:858
 [5] require(::Module, ::Symbol) at ./loading.jl:853

Nevermind, this is a version incompatibility between Makie 0.9.0 (no idea why that was in my packages but it was) and the latest AbstractPlotting.  It's not actually an issue :)

Resolved as Pkg or user weirdness.

That looks like Makie was downgraded by Pkg, but not AbstractPlotting... Since I've introduced strict versions on GLMakie & AbstractPlotting in Makie, downgrading may happen -.-

Makes sense...guess I'll have to watch out for that


Add more documentation to cubeb-api

Over at https://github.com/orottier/web-audio-api-rs/pull/186 we're adding support for cubeb.
I noticed the rust bindings are not documented very extensively, so I made a small start for the cubeb-api crate.
If this is something you are willing to merge, I could do the same for cubeb-core.
Most of the doc strings are taken from https://github.com/mozilla/cubeb/blob/master/include/cubeb/cubeb.h

Looks good, thanks!


Multi-language root auto refresh

I'm having an issue:
Hello, I'm trying to root my application with multilingual support for seo. I automatically create my root objs in an array by returning them. An element of the array:
routers: [
  {
    name: 'home',
    action: function (params, queryParams) {
      this.render('publicLayoutDefault', { page: 'publicPageHome' });
    },
    paths: {
      en: {
        router: '/home',
        title: '',
        meta: {

        }
      },

      tr: {
        router: '/ana-sayfa',
        title: '',
        meta: {
        }
      }
    }
  },
]

The function that runs the array;

import { FlowRouter } from 'meteor/ostrio:flow-router-extra';
import { FlowRouterMeta, FlowRouterTitle } from 'meteor/ostrio:flow-router-meta';

RouterUtil.routers.forEach(router => {
  const { name, action, globalTriggersEnter, paths } = router;

  Object.keys(paths).forEach(key => {

    const path = paths[key];

    const { router, title, meta } = path;

    const obj = {
      name: `${key}.${name}`,
      action: action,
      triggersEnter: [] // ChangeLang
    }

    if (globalTriggersEnter) {
      obj.triggersEnter.push(...globalTriggersEnter);
    }

    switch (key) {
      case 'en':
        obj.triggersEnter.push(SetLocaleEn);
        break;
      case 'tr':
        obj.triggersEnter.push(SetLocaleTr);
        break;
    }

    if (title) {
      obj.title = title;
    }

    if (meta) {
      obj.meta = meta;
    }

    console.log(router);
    FlowRouter.route(router, obj);
  });
});

FlowRouter.route('*', {
  action: function (params, queryParams) {
    const lang = LocaleShort.get() // en or tr
    console.log('<===Not Found===> ');
    FlowRouter.go(`${lang}.home`, {});
  }
});

new FlowRouterMeta(FlowRouter);
new FlowRouterTitle(FlowRouter);

Although my local works very well, it constantly reloads the page when I load it on the machine. I managed to index by language with prerender.io. I guess the reason is because it always goes into the notFound function. I defined these roots as normal and got the same problem. Normally defined roots without multilingual support work normally.
Finally, I get an error like this. If I don't set the meta data, it doesn't come.
-Edit-
When the keywords parameters that I defined in the meta are more than 113 characters, I get the error below.

Flowrouter data

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Meteor 2.2
Chrome, Firefox, Safari, etc
Win, Linux

@Sergeant61 your issue caused by passing an object as a first argument to .route method. And I believe you overcomplexified your solution.
I'd go with a single route for all "homes" routes, for example:
FlowRouter.route('/:lang/:slug/home', {/*...*/});

Hello, thank you very much for your answer. But adding additional parameters to root means sending it wherever I call it. I found this useless. I already know the language as I define tr.home as en.home when defining roote. Maybe it's a bit too much to do here, but it provides metadata with multi-language support very quickly.
As for the problem, I made a small mistake while adding the google tag credential data to the site, which was constantly putting the site into the notFound function.
Thanks again for your interest, it will be an example for those who will use something like this. 😂


Button

For the story, the tests are not passing on my machine.
but it's not only my branch, main also fails on the same errors.
So I am creating this PR to see it test on vercel.

[ ] d070a2f
[ ] 4bd379a
[ ] fd808aa
[ ] edb7edd
[ ] 7701e0e
[ ] 72f4ca0
[ ] 5edcf15
[ ] cf8b0d2
[ ] 8af8b68
[ ] 426b44a
[ ] 33e1cc9
[ ] e7bb963
[ ] fed20b2
[ ] a01cf17
[ ] 6f2d959
[ ] 34e6af1
[ ] facae85
[ ] e4b1f2b
[ ] 9ba7a0a

d070a2f

I replaced klass with class="{buttonClass} {$$props.class}" and removed original {...$$props}.
Justifications:

Button doesn't need readonly and checked.
Using Svelte's attribute is more natural.
Doesn't break @orefalo 's codes.
@orefalo added disabled param.

fd808aa

Removed yarn.lock
Since Spinner has only one page, I will move the default.md to index.md later.


Added a check on the sdpMid's default value in RTCPeerConnection.js

If sdpMid doesn't exist，NoSuchKeyException will affect connection.

Hi @lightning-zgc
thanks for your PR.
I think if these params are mandatory, then instead modify it in native side, this sort of things like default key/value or pre-check stuff, would be easier to maintain if we do it in js side. like RTCConfiguration.
you might put these check in https://github.com/oney/react-native-webrtc/blob/master/RTCPeerConnection.js#L183
something like we do in https://github.com/oney/react-native-webrtc/blob/master/RTCPeerConnection.js#L119
then we solid ios as well.
thanks!

Thank you for your suggestion.The change has been moved to JS code side.

I don't understand why the plugin needs to care about this. If the user if passing a broken ICE candidate it's the user's problem,not this library's IMHO.

I'm not sure what it would happen if sdpmid is empty.
it seems doc says:

if candidate is empty, indicate the end of remote candidates.
both sdpMid and sdpMLineIndex is nullable (https://www.w3.org/TR/webrtc/#dom-rtcicecandidate-sdpmid)
If candidate is not null and both sdpMid and sdpMLineIndex are null, return a promise rejected with a newly created TypeError. (https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addicecandidate())

https://www.w3.org/TR/webrtc/#dom-rtcicecandidate-sdpmid

@ sdpMid of type DOMString, readonly , nullable
If not null, this contains the identifier of the "media stream identification" as defined in [RFC5888] for the media component this candidate is associated with.
@sdpMLineIndex of type unsigned short, readonly , nullable
If not null, this indicates the index (starting at zero) of the media description in the SDP this candidate is associated with.

https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addicecandidate()

If candidate.sdpMid is not null, run the following steps:
If candidate.sdpMid is not equal to the mid of any media description in remoteDescription , reject p with a newly created OperationError and abort these steps.
Else, if candidate.sdpMLineIndex is not null, run the following steps:
If candidate.sdpMLineIndex is equal to or larger than the number of media descriptions in remoteDescription , reject p with a newly created OperationError and abort these steps.

I'm not exactly sure, but educated guessing that:

one of sdpMid and sdpMLineIndex should present. the other one can be nullable.
if sdpMid is not null, use it first.
otherwise, use sdpMLineIndex

correct me if I'm wrong :pray:
for my personal preference, in most situations, I would prefer warning than crash. because the user on the app store comments cruelly :scream:

@lightning-zgc
if the review discussion finally passed. please rebase/squash your commit into one. or the old commit will still shows in the code base

@zxcpoiu I think this doesn't fix anything. The user can pass whatever they want: a number, an object with whatever properties, undefined / null, etc. If we want to go the full nine yards and check the object has the required properties that's one thing, but the current fix is a corner case, probably specific to the user's code.
I would not merge this, but I leave it up to you.

@saghul
yes, you are right.
this probably specific to user's code.
@lightning-zgc
I noticed this probably wont's happen because our RTCIceCandidate in RTCIceCandidate.js always has these keys.
you might need to use the following way to invoke addIceCandidate
pc.addIceCandidate(new RTCIceCandidate(data.candidate));
and thus, the key should present.
I'm going to close this

@lightning-zgc thanks anyway for letting me notice the doc.
for future alignment with spec noted above, PR is still welcome :)
thanks for double check and review @saghul

Thank you for your enthusiasm and concern, I will pay more attention to the need to submit.This problem is really due to my inadequate view, I found the problem in the use of the peerjs framework calls this framework under React Native. Now, I think it's peerjs's issue.Thank you again for your attention and serious.


[css][html] SVG language support

Currently, we have no SVG support:

In HTML, SVG tags don't receive auto completion
In CSS, SVG attributes don't receive auto completion
Syntax highlighting are problematic for both SVG tags/attributes in HTML/CSS
Emmet do not get SVG completions

However, with custom tag/property support in HTML/CSS, we should be able to trivially write a SVG package that describes the set of tags/attributes for SVG, and let HTML/CSS language services do the support work.

https://github.com/Microsoft/vscode/issues/62976
https://github.com/Microsoft/vscode/issues/64164

Since SVG is an XML variant, would support for XML be included? Or would that have to be a request under Atom's XML package?

Would be nice to have standard emmet abbreviation completion.

<style> tags inside SVG files also have no CSS syntax highlighting or autocompletion, but do in HTML files.

any progress? It would be great to support emmet syntax in svg. By using following setting, I can get emmet suggestion, but can't get svg specific tag suggestion
"emmet.includeLanguages": {
        "svg": "html"
 },

I am not sure how much of this is implemented in jock's brilliant SVG extension, but at a cursory glance I noticed a huge number of the features you've all requested. We need to start comparing and figure out what features are missing.

Related: #124901 (SVG previewing)

@4086606 Thanks.

@4086606 I think we all could collaborate and create better separate extension for that. Thanks anyway.

The SCM textual diff view for SVGs is nigh useless unless you're minifying a diff.
https://github.com/PKief/vscode-material-icon-theme/pull/1139/commits/cda3339
The text view is meaningless here while the rich diff preview is much much more useful

Note: Related on Stack Overflow: How can I get IntelliSense for SVG in HTML, CSS, and JS in VS Code?

= Syntax highlighting for SVG =
Technically SVG is also valid HTML.
    But the HTML linter in current case doesn't work well enough.
Sample file:
    https://github.com/MasterInQuestion/Markup/blob/main/Junkyard Tornado.svg?short_path=1
Related:
    https://www.google.com/search?hl=en&gl=ca&num=100&filter=0&q=site:github.com/microsoft/vscode/issues+intitle:SVG+intitle:syntax|intitle:language
    https://github.com/microsoft/vscode/issues?q=in:title+SVG+syntax
    https://github.com/microsoft/vscode/issues?q=in:title+SVG+language


Binding observable to an action

I quickly skimmed through the code, and it seems that Observable cannot be bind to an Action, I couldn't find related issues as well.
It would be useful, e.g. when using Observable.combineLatest to bind Observable to Action. Simple example to illustrate that.
        let disposeBag = DisposeBag()
        let exampleAction: Action<(Int, Int, Int), (Int, Int, Int)> = Action { (a, b, c) in Observable.just((a+1, b+1, c+1)) }
        Observable.just((1, 2, 3)).bind(to: exampleAction).disposed(by: disposeBag)

It is not difficult to write extension for ObservatleType to allow such use-case.
extension ObservableType {
    func bind<T>(to action: Action<Element, T>) -> Disposable {
        return subscribe { e in
            switch e {
            case let .next(element):
                action.execute(element)
            case let .error(error):
                print("Binding error to action: \(error)")
            case .completed:
                break
            }
        }
    }
}

Are there any reasons for this not being possible out-of-box?

This is supported out of the box, like so:
 let exampleAction: Action<(Int, Int, Int), (Int, Int, Int)> = Action { (a, b, c) in Observable.just((a+1, b+1, c+1)) }
        Observable.just((1, 2, 3)).bind(to: exampleAction2.inputs).disposed(by: disposeBag)

Thank you, that's very clean way of doing it. 👍 I will migrate to this solution in my code.