Can't successfuly run the slcp-snle

Hi Simon,
I am trying to run the example of SCLP using surjective layers, actually the file slcp-snle.
y_obs = jnp.array([[
-0.9707123,
-2.9461224,
-0.4494722,
-3.4231849,
-0.13285634,
-3.364017,
-0.85367596,
-2.4271638,
]])
fns = prior_fn, simulator_fn
neural_network = make_maf(8, n_layer_dimensions=[8, 8, 5, 5, 5])
snl = NLE(fns, neural_network)
optimizer = optax.adam(1e-4)
data, _ = snl.simulate_data(jr.PRNGKey(0), n_simulations=10_000)
params_t, losses = snl.fit(
jr.PRNGKey(0), data=data, n_early_stopping_patience=100, optimizer=optimizer, n_iter=1000
)
Unfortunately, I got an error: ValueError: Incompatible shapes for broadcasting: shapes=[(100, 5), (8,)]
If I design all layers to be bijective, such as n_layer_dimensions=[8, 8, 8, 8, 8]. the implementation works well. So I guess the issue resulted from  the use of surjective layer. I tried many times to modify the codes, but the error still persisted, can you give me some ideas?
Thanks!
I also tried another nerual network: MaskedCouplingInferenceFunnel below:
def _make_maf(
n_dimension,
n_layer_dimensions,
hidden_sizes,
activation,
):
def _bijector_fn(params):
print(params.shape)
means, log_scales = unstack(params, -1) #jnp.split(params, 2, -1) #
    return distrax.ScalarAffine(means, jnp.exp(log_scales))

def _decoder_fn(dims):
    def fn(z):
        params = surjectors_mlp(dims, activation=activation)(z)
        mu, log_scale = jnp.split(params, 2, -1)
        return distrax.Independent(distrax.Normal(mu, jnp.exp(log_scale)))
    return fn

def _conditioner(n_dim):
    return hk.Sequential(
        [
            surjectors_mlp(
                list(hidden_sizes) + [2 * n_dim],
                activation=activation,
            ),
            hk.Reshape((n_dim, 2)),
        ]
    )

@hk.transform
def _flow(method, **kwargs):
    layers = []
    order = jnp.arange(n_dimension)
    curr_dim = n_dimension
    for i, n_dim_curr_layer in enumerate(n_layer_dimensions):
        # layer is dimensionality preserving
        if n_dim_curr_layer == curr_dim:

            layer = MaskedCoupling(
                mask=make_alternating_binary_mask(curr_dim, i % 2 == 0),
                conditioner=_conditioner(curr_dim),
                bijector_fn=_bijector_fn,
            )

            order = order[::-1]

        elif n_dim_curr_layer < curr_dim:

            n_latent = n_dim_curr_layer
            layer = MaskedCouplingInferenceFunnel(
                n_keep=n_latent,
                decoder=_decoder_fn(
                    list(hidden_sizes) + [2 * (curr_dim - n_latent)]
                ),
                conditioner=surjectors_mlp(
                    list(hidden_sizes) + [2 * curr_dim],
                    activation=activation,
                ),
                bijector_fn=_bijector_fn,
            )
            curr_dim = n_latent

            order = order[::-1]
            order = order[:curr_dim] - jnp.min(order[:curr_dim])
        else:
            raise ValueError(
                f"n_dimension at layer {i} is layer than the dimension of"
                f" the following layer {i + 1}"
            )
        layers.append(layer)
        layers.append(Permutation(order, 1))
    chain = Chain(layers[:-1]) #Chain(layers[:-1])

    base_distribution = distrax.Independent(
        distrax.Normal(jnp.zeros(n_dimension), jnp.ones(n_dimension)),
        1,
    )
    td = TransformedDistribution(base_distribution, chain)
    return td(method, **kwargs)

return _flow

I got error of ValueError: too many values to unpack (expected 2).
Thanks for the contribution to the library and looking forward to your reply.

Hi,
Yes, you are right. When refactoring the package for the submission, I introduced an error in make_maf. I push a fix later. This should be
    base_distribution = distrax.Independent(
        distrax.Normal(jnp.zeros(curr_dim), jnp.ones(curr_dim)),
        1,
    )

and not n_dimension.
Cheers,
Simon

Yes, it works after I changed n_dimension into curr_dim. I also tried to implement different surjective layer, such as MaskedCouplingInferenceFunnel, as you see the codes I pasted in the issue.  Even I modified n_dimension into curr_dim, I still got error:
75     def _bijector_fn(params):
76 #        print(params.shape)
---> 77         means, log_scales = unstack(params, -1)
80         return distrax.ScalarAffine(means, jnp.exp(log_scales))
ValueError: too many values to unpack (expected 2)
Do you have any idea for implementing MaskedCouplingInferenceFunnel?

The issue here is that a MADE network outputs different paramater shapes than a MLP. I think in the case, you need to use the following bijector
def bijector_fn(params):
    shift, log_scale = jnp.split(params, 2, axis=-1)
    return distrax.ScalarAffine(shift, jnp.exp(log_scale))

Thanks for reporting all this! I need to put all that in the docu

The issue here is that a MADE network outputs different paramater shapes than a MLP. I think in the case, you need to use the following bijector
def bijector_fn(params):
    shift, log_scale = jnp.split(params, 2, axis=-1)
    return distrax.ScalarAffine(shift, jnp.exp(log_scale))

Hi Dirmeier,
I think I misled you. The original make_maf works well after changing n_dimension into curr_dim. The function of make_maf uses MaskedAutoregressive as bijective layer, and AffineMaskedAutoregressiveInferenceFunnel as surjective layer. The     def _bijector_fn(params):         means, log_scales = unstack(params, -1)         return distrax.ScalarAffine(means, jnp.exp(log_scales)) also works well.
My issue is that I tried to implement affine (surjective) masked coupling flow, with bijective layer  of MaskedCoupling and surjective layer of MaskedCouplingInferenceFunnel, I open another issue to avoid confusion for other readers.


Can this library be build without having to link OpenCV?

I believe that #478 added a dependency to OpenCV through ortextensions. Is there any way to build this without depending on OpenCV?
Undefined symbols for architecture x86_64:
  "cv::copyMakeBorder(cv::_InputArray const&, cv::_OutputArray const&, int, int, int, int, int, cv::Scalar_<double> const&)", referenced from:
      padding_336(cv::Mat const&) in xxx.rlib[211](image_processor.cc.o)
  "cv::Mat::Mat(std::__1::vector<int, std::__1::allocator<int>> const&, int, void*, unsigned long const*)", referenced from:
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
  "cv::Mat::Mat(int, int, int, void*, unsigned long)", referenced from:
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
  "cv::Mat::Mat()", referenced from:
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      hd_transform(cv::Mat const&, int) in xxx.rlib[211](image_processor.cc.o)
      padding_336(cv::Mat const&) in xxx.rlib[211](image_processor.cc.o)
  "cv::Mat::~Mat()", referenced from:
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      ...
  "cv::resize(cv::_InputArray const&, cv::_OutputArray const&, cv::Size_<int>, double, double, int)", referenced from:
      phi3_hd_transform(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<float>&, Ort::Custom::Tensor<long long>&, Ort::Custom::Tensor<long long>&) in xxx.rlib[211](image_processor.cc.o)
      hd_transform(cv::Mat const&, int) in xxx.rlib[211](image_processor.cc.o)
  "cv::imdecode(cv::_InputArray const&, int)", referenced from:
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
  "cv::Mat::total() const", referenced from:
      image_decoder(Ort::Custom::Tensor<unsigned char> const&, Ort::Custom::Tensor<unsigned char>&) in xxx.rlib[211](image_processor.cc.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Would you please share a little more on your request? Is OpenCV not buildable for your machine/platform?
Could you share your build command? You shouldn't be seeing this error since we pull and build OpenCV from scratch.

Does your application depend on OpenCV outside of onnxruntime-genai/onnxruntime-extensions?

My apologies, this ticket is indeed lacking quite some context:)
I'm building a static library of onnxruntime-genai while specifying a static build of onnxruntime like so:
python3 build.py --ort_home ../onnxruntime-build/output/static_lib --parallel --config Release --skip_wheel --skip_csharp
(I also had to disable the shared library target in the CMakeList.txt as I only supply a static build of onnxruntime)
When I then use the libonnxruntime-genai-static.a in my application, while building I am facing the linking error that I copied. (It's a rust application, but I don't think that's important here).
I can work around this by adding the following static libraries: liblibjpeg-turbo.a, libopencv_core.a, libopencv_imgproc.a, libopencv_imgcodecs.a, liblibpng.a, libz.a.
However, I don't need any of those libraries in my application, neither do I need image models, so I was wondering if I could somehow build a static version of your library that does not depend on OpenCV, as that would reduce the number of dependencies quite a bit for me.

Thank you for the context. We do not have plans as of now to add conditional building for different type of models. We only generate an all-in-one package right now.
I have not tried building an example against the ort-genai static lib, but I would assume that we do not need to link against these libs since the ort-genai static lib already has linked against these static libs. Our python cmake file links against the static lib but does not need to link against the other libs you mentioned. And it builds fine. So, I am not sure where the linker error comes from.


Update File for new version of toxiclibs

Sharing

[ ] I would be happy to have my project shared on The Coding Train's social media, because I updated the project for the new version of toxiclibs, 22.

Thanks @TamsP. Looks good!


feat(vue): add vue 3 support

I added support for the new Vue 3 compiler, it seems to work on my project.
How I kept v2 compatibility:

I changed the compiler option to string | undefined (it's undefined by default);
When undefined, I try to load @vue/compiler-sfc (v3) and if it doesn't work I try vue-template-compiler (v2). If the option is set to a string, I just go for that string;
Then I had to adapt compiler usage to account for slight changes in the public API. Basically I'm testing the presence of each api that differs (everything is fully typed).

⚠ I have one unrelated error in TypeScriptIssueFactory.ts, with the DiagnosticMessageChain.next.  being an array rather than just the next instance. Maybe this field type changed in a recent release (I was using TS 3.7.5, which is not the one in yarn.lock). Just a heads up, you may have breakage coming your way.

I see the CI fails because yarn.lock was not updated (I added @vue/compiler-sfc to the list of dev deps)... sorry I don't use yarn, if you can update it.

Thanks for the PR @jods4!
What are your thoughts @piotr-oles? Supporting Vue 3 is great. The alpha-ness of it makes me wonder if this might be too soon. Not sure though...

I would agree it's to early for an official release, but maybe add Vue 3 support to preview releases for now? Like a 4.1-alpha.1?
I doubt this API will change in major ways before release but we can adapt if required.
The major snag right now is precisely that the ecosystem is lacking v3 support, so it'd be nice to have this. It will provide tooling so that others (e.g. libs) can get onboard and prepare for the v3 release.

To update yarn.lock, please just run yarn install command - it will update the file automatically :) We can release it on the alpha channel.

@piotr-oles I don't have yarn on my machine, just using the plain ol' npm, could you do it please?
Also, I'm afraid of what's gonna happen next time you install dependencies: I think there was a breaking change in TS apis.

@piotr-oles I don't have yarn on my machine, just using the plain ol' npm

It's not high cost to install; instructions are here: https://classic.yarnpkg.com/en/docs/install
It's literally seconds of work 🥰

Vue 3 is now in beta!
Would love to see this merged.

Solved in the #423


[Badges][Color Picker] Expose and use color wheel feature

Description
Color Picker

Bump dependencies
Expose Color Wheel ability through Raycast Cross-Extension Conventions
Update API documentation

Badges - shields.io

Bump dependencies
Use color wheel for picking colors

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hey! Thanks for your PR!
Do you mind making different PRs for each extension? That would make it easier for testing and separating concerns.
Cheers!

Sorry, I don't think so. Those changes are important for each other. I have many this kind of PRs before. And Per all approved and merged.

Sure. I can still review, it just a matter of making things easier and cleaner. I will come back to this.


Recoloring icon image

Question about an existing feature
Hello, I'm trying to understand how to recolor an icon image with a transparent background. Our icons are simple:

We only need to change the foreground color
We can assume the input foreground color of all of our icons is black
We can make all of our input icons PNG or SVG, no preference

What are you trying to achieve?
Change this:

To this (or any other hex/rgba color we want to use):

When you searched for similar issues, what did you find that might be related?
I couldn't find an issue that was as specific as mine. I did find the following potentially-related topics but the solutions proposed didn't work:
https://github.com/lovell/sharp/issues/2576
https://github.com/lovell/sharp/issues/1798

Are you able to provide an example of the input as an SVG? If you control this then it might be possible to set the path colour.

@lovell yep here's the SVG:
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M19 9L12 16L5 9" stroke="black" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
</svg>

Thanks, have you tried changing the value of stroke="black" to the colour you need?
 <svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
-<path d="M19 9L12 16L5 9" stroke="black" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
+<path d="M19 9L12 16L5 9" stroke="#f00" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
 </svg>

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


Modulo operator error

Not sure if this is the correct place to report this or even if this is a known issue, but the modulo operator seems to have a problem. It works as expected when used with powers of two, but returns 1 when used with other numbers. This doesn't happen when running on my laptop. The following code demonstrates the issue on the Arduino Uno:
#![no_std]
#![no_main]
#![feature(abi_avr_interrupt)]

extern crate panic_halt;

use arduino_uno::prelude::*;

const PWM_PERIOD: i32 = 200;

#[arduino_uno::entry]
fn main() -> ! {
    let dp = arduino_uno::Peripherals::take().unwrap();

    let mut pins = arduino_uno::Pins::new(dp.PORTB, dp.PORTC, dp.PORTD);

    let mut serial = arduino_uno::Serial::new(
        dp.USART0,
        pins.d0,
        pins.d1.into_output(&mut pins.ddr),
        57600.into_baudrate(),
    );

    let mut val: i32 = 0;

    loop {
        ufmt::uwriteln!(&mut serial, "{}\r", (val % PWM_PERIOD)).void_unwrap();
        val += PWM_PERIOD / 2;
        arduino_uno::delay_ms(100);
    }
}

Let me know if this should be reported somewhere else.

Hey!
This is probably related to https://github.com/rust-lang/rust/issues/82242 ...

Great, thanks. I'll watch that issue for updates. And thanks for your work implementing this package!


Why does azcopy jobs list show Completed status but azcopy jobs show <jobid> show InProgress?

Which version of the AzCopy was used?
10.15.0
Which platform are you using? (ex: Windows, Mac, Linux)
Linux
What command did you run?
azcopy jobs show <jobid>
What problem was encountered?
Output shows Final Job Status: InProgress but Completed status is expected
How can we reproduce the problem in the simplest way?
Not sure how to do that, i was following https://learn.microsoft.com/en-us/training/modules/copy-blobs-from-command-line-and-code/6-exercise-move-blobs-using-azcopy
Have you found a mitigation/solution?
No

I have verified from the portal and cli that the copy was completed

Hi there! I have tried to repro and when I do azcopy jobs show <> for a Completed job, it appears as Completed in the info as well. Please try the latest AzCopy version and let us know if this issue still persists!


Restructure module stdio

There have been a few recent issues and PRs around the ways stdio is managed for WASI modules:

#431
#438
#449
#482
#513 (includes changes to "follow logs" config)

The current state of the code is somewhat confusing, requiring coordination between the configuration passed in ExecutionContextConfiguration and the trigger executor implementation. Also, the options for stdio handling are limited to capturing to memory, capturing to files, and a follow flag that only works with the "capturing to memory" path.
There a few interrelated requirements to detangle here:

Some trigger executors need mandatory control over some of stdio (e.g. stdin/stdout for WAGI)
Some spin embedders want to intercept stdio (https://github.com/fermyon/spin/issues/438#issuecomment-1119068691)
Where stdout/err aren't processed by a trigger executor or intercepted by an embedding, we (usually?) want the default behavior to log them to files and/or the console

I think we can restructure to simplify the code while maintaining these features:

Collapse the ExecutionContextConfiguration IO-related fields into a single io field typed like:
struct IoDefaults {
  stdout: IoOutputBehavior,
  stderr: IoOutputBehavior,
}
enum IoOutputBehavior {
  Null,
  Log,
  Pipe(WritePipe),
}

Update ExecutionContext::prepare_component's io arg to take a type something like:
struct IoOverrides {
  stdin: Option<ReadPipe>,
  stdout: Option<WritePipe>,
  stderr: Option<WritePipe>,
}

Update existing redirect_to_mem_buffer usage to use WritePipe::new_in_memory

There is a minor subtlety where a component can be writing to stdout/stderr as well as to a buffer for logging.  We represent this as a Write implementation so it's not hard but it does need to be represented somehow.
The way I envisaged this working was similar to you: it has to be driven from the outside in, with an opportunity for executor code to override.  My original thought was that the host would actually compose what you call the IoOverrides - typically using helper methods, but it could be completely custom - and pass that into the trigger (the trigger being a good "unit of hosting").  Using an enum is probably more intention-revealing, though, and thus will likely work more clearly with any future non-monolithic architecture.
In any case, I completely agree about simplifying and streamlining the whole area!

We should pick up #514 as part of this.

I'm also wondering if we can store the redirect as part of the component object.  This puts it in a natural location as part of the component config, which already flows through to the executor, and allows components to be set up differently without the executor having to check a "follow' setting.  Components are kept in the manifest object, though, and the loader currently tends to avoid mixing command line settings into that.  Might give it an explore though.

This is pretty much subsumed by #763


Taking over change history

OS: Arch Linux
(Neo)Vim version: 0.4.0
vim-clap version: current HEAD

Sometime since I last updated vim-plugins (up to a month perhaps?), the behavior of vim-clap has regressed.
A common workflow for me is to open a file, search for some next, make a change, then use vim-clap with a grep or files provider to load up another file with related content. My expectation is that I should be able to use n without further ado to find the next instance from my previous search, then . to repeat the fix.
At some point vim-clap has started registering things typed into the search (for example using the files provider) as an action in VIM's command history. Now when I get a new buffer open n works to find the next instance of my last search, but when I try to repeat the last action using . I get whatever fuzzy string I typed into the files provider inserted in my file.

It can be helpful if you bisect the commit that introduces this change.

Yes, and if I did that I could probably fix it myself too. Trouble is I don't have the bandwidth today or in the next couple days. I may get to it eventually if nobody else does first.


Make it clear that the environment inherits from the base configuration

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/3040
Originally created by @tayloramurphy on 2021-11-03 15:42:13

View 2 previous comments from the original issue on GitLab


windows

Description of the issue. Please be specific.
What's the simplest set of steps to reproduce this issue? Please provide an example project, if possible.
Version information
IdeaUltimate: 2021.2.2
Platform: Windows 10 10.0
Bazel plugin: 2<IP_ADDRESS>.0-api-version-212
Bazel: 4.2.1

We are closing this issue due to inadequate details! Please reopen if you can update with complete reproduce steps!


Suggest a compliance level for RFC 8932

How about this?

Operators are advised to apply all "Threat mitigations" from RFC 8932 "Recommendations for DNS Privacy Service Operators" (thereby meeting its level of "minimally compliant") and additionally apply the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.


Add a sensible default for theme app extension template

WHY are these changes introduced?
When you run shopify generate extension --type=theme_app_extension we generate an extension which is basically empty AND not deployable (the user has to manually remove all .gitkeep files).
Also fixes https://github.com/Shopify/internal-cli-foundations/issues/493
WHAT is this pull request doing?

Provide a sensible template for theme app extensions with:

1 block
1 snippet
1 locale
1 asset

it also uses metafields for fun
now the generated theme app extension can be deployed

How to test your changes?

bin/create-test-app.js -e theme
press p and install the app in your dev store
wait for theme app extension to show you three links
click on the first one and click "Enable"
click on the theme editor and add a new section with your theme app extension
open http://localhost:9292 to see the preview
if you make a change in the source you should see it reflected

Post-release steps

change https://shopify.dev/docs/apps/online-store/theme-app-extensions/getting-started

Measuring impact
How do we know this change was effective? Please choose one:

[x] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[ ] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[x] I've considered possible documentation changes
[x] I've made sure that any changes to dev or deploy have been reflected in the internal flowchart.

could it make sense to include a README about how to use the template?

Create the concrete metafield
Configure the products
.....


Create codeql-analysis.yml

Codecov Report

Merging #82 (bacf0d2) into devel (9f1e357) will decrease coverage by 0.21%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##            devel      #82      +/-   ##
==========================================
- Coverage   77.66%   77.45%   -0.22%
==========================================
  Files          46       46
  Lines        3801     3792       -9
==========================================
- Hits         2952     2937      -15
- Misses        849      855       +6

Impacted Files
Coverage Δ

transifex/native/django/management/utils/base.py
27.84% <0.00%> (-3.80%)
:arrow_down:

transifex/_version.py
41.93% <0.00%> (-3.23%)
:arrow_down:

...fex/native/django/tools/migrations/templatetags.py
97.56% <0.00%> (-0.49%)
:arrow_down:

transifex/native/django/templatetags/transifex.py
94.59% <0.00%> (-0.05%)
:arrow_down:

transifex/native/parsing.py
94.65% <0.00%> (-0.03%)
:arrow_down:

.../native/django/management/utils/try_templatetag.py
18.71% <0.00%> (+0.10%)
:arrow_up:

transifex/native/tools/migrations/execution.py
75.71% <0.00%> (+0.53%)
:arrow_up:

transifex/native/tools/migrations/review.py
44.50% <0.00%> (+0.65%)
:arrow_up:

transifex/api/__init__.py
84.18% <0.00%> (+0.94%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Back-end sometimes stops sending ACKs

The device suddenly stopped receiving ACKs consistently. It was recovered by restarting the staging environment.
The device is a mDot that was very close to the gateway. Then, quite often, exactly the packet is received twice by the same gateway.
router-us_1 |  DEBUG Handle PUSH_DATA                         GatewayID=008000000000B16E adapter=gateway-semtech
router-us_1 |  DEBUG Handle rxpk                              GatewayID=008000000000B16E adapter=gateway-semtech
router-us_1 |  DEBUG Handle uplink data                       GatewayID=008000000000B16E adapter=gateway-semtech
router-us_1 |  DEBUG Set duty cycles                          Frequency=912.9 GatewayID=008000000000B16E Rx1=0 Rx2=0
router-us_1 |  DEBUG Inject Metadata                          DevAddr=1D8A57AF GatewayID=008000000000B16E Metadata=Region:"us" Frequency:912.9 DataRate:"SF8BW125" CodingRate:"4/5" Timestamp:325855204 Rssi:-67 Lsnr:10 PayloadSize:15 Time:"2016-04-05T00:39:32.0474Z" RFChain:1 CRCStatus:1 Modulation:"LORA"
router-us_1 |  DEBUG Send to known brokers                    DevAddr=1D8A57AF
broker_1    |  DEBUG Handle uplink                            DevAddr=1D8A57AF
broker_1    |  DEBUG MIC check succeeded                      DevAddr=1D8A57AF DevEUI=008000000000AF02 Handler=handler:1882
broker_1    |  DEBUG Handle uplink                            DevAddr=1D8A57AF
broker_1    |  DEBUG MIC check succeeded                      DevAddr=1D8A57AF DevEUI=008000000000AF02 Handler=handler:1882
handler_1   |  DEBUG Handle Uplink                            AppEUI=0102030405060708 DevEUI=008000000000AF02
handler_1   |  DEBUG Define new bundle                        AppEUI=0102030405060708 BundleID=1-0102030405060708-008000000000AF02-00000007 DevEUI=008000000000AF02
handler_1   |  DEBUG Start buffering                          BundleID=1-0102030405060708-008000000000AF02-00000007 goroutine=set consumer
handler_1   |  DEBUG Handle Uplink                            AppEUI=0102030405060708 DevEUI=008000000000AF02
handler_1   |  DEBUG Define new bundle                        AppEUI=0102030405060708 BundleID=1-0102030405060708-008000000000AF02-00000007 DevEUI=008000000000AF02
handler_1   |  DEBUG End buffering                            BundleID=1-0102030405060708-008000000000AF02-00000007 goroutine=set consumer
handler_1   |  DEBUG Consume bundle                           BundleID=1-0102030405060708-008000000000AF02-00000007 goroutine=bundle consumer
handler_1   |  DEBUG Publishing Uplink                        AppEUI=0102030405060708 DevEUI=008000000000AF02 adapter=app-adapter
handler_1   |  DEBUG No response to send                      AppEUI=0102030405060708 DevEUI=008000000000AF02
handler_1   |  DEBUG Sending downlink packet as response      AppEUI=0102030405060708 DevEUI=008000000000AF02
broker_1    |  DEBUG Handle downlink response                 DevAddr=1D8A57AF DevEUI=008000000000AF02 Handler=handler:1882
broker_1    |  DEBUG No downlink response                     DevAddr=1D8A57AF DevEUI=008000000000AF02 Handler=handler:1882
router-us_1 |   WARN Failed forward to broker                 DevAddr=1D8A57AF error=Wrong behavior or result: Too many positive answers
router-us_1 |  DEBUG rxpk not processed                       GatewayID=008000000000B16E adapter=gateway-semtech error=Invalid operation: Too many positive answers
router-us_1 |  DEBUG Handle PULL_DATA                         GatewayID=008000000000B16E adapter=gateway-semtech
router-us_1 |  DEBUG Handle PULL_DATA                         GatewayID=0000B827EB5D8D35 adapter=gateway-semtech

Closing this issue because I can't reproduce the problem. Please reopen if it happens again.

Fixed


Padding for titlebar when app is running in full screen mode

In iOS 8 (and likely previous versions) you may place a shortcut to the web app on the home screen.  When you do this and you launch from the home screen the webpage will show up without any browser chrome (which is awesome BTW)
Problem is that there is no padding at the top of the webview to accomodate for the device statusbar which means the webpage bleeds into it.
Is anyone aware of a way to detect that the app is running full screen so the appropriate padding can be added?

I found a link detailing stuff.  It appears as though you are able to tell if the app has been launched in full screen or not.  Looks like:
if (window.navigator.standalone) {
// The app is running in standalone mode so you may need 20 pixels of padding
}
Looks like you only need the padding if you have a meta tag of "apple-mobile-web-app-status-bar-style" set to "black-translucent" (like the touchstone demo app is).  I just changed mine to "black" and it doesnt bleed into the titlebar like before (alas I have a black titlebar now)
Details here: http://blog.teamtreehouse.com/optimizing-mobile-web-apps-ios

Hi @anthonywebb, thanks for your contribution.
Would you mind submitting a pull request?

We're focusing on the app experience for now. Perhaps this will be revisited in the future


Creating/Removing cells is broken

Cannot create new cells or remove them (I don't have repro steps; it usually stops working after first time creating a new cell)
https://github.com/microsoft/vscode/assets/16353531/f9c08dd1-d64d-45f0-88c9-e6970b1bb604
Version: 1.90.0-insider
Commit: 29aeab1cbb350107a7bd5962b5e7efe745e0a3ec
Date: 2024-05-13T05:59:57.400Z
Electron: 29.3.1
ElectronBuildId: 9464424
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 23.4.0

repro:

create an empty cell in a notebook and execute it
create a new code cell, clicking + code or using keybindings a/b
:bug: no new cell is added, existing cell's editor is focused


Helm does not work properly with --wait flag and Pods completed below 2s

Output of helm version:
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+$Format:%h$", GitCommit:"10ecc6db83fd47a93eb0940e2e4434f2b0a5c3ec", GitTreeState:"clean", BuildDate:"2018-08-15T21:23:47Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4", GitCommit:"f49fa022dbe63faafd0da106ef7e05a29721d3f1", GitTreeState:"clean", BuildDate:"2018-12-14T06:59:37Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
not-related
Description
When we installing/updating the Helm chart with --wait flag and this chart contains the Pods definition and those Pods are completed very quickly (below 2s) then installation is timeouted.
It happens when Pods restart policy is set to Never and Pod finishing they job below 2s, so poll logic missed the Ready state and we had to wait until the installation timeout.
source code: https://github.com/helm/helm/blob/v2.12.1/pkg/kube/wait.go#L52
We cannot use the Job kind because the Helm wait functionality support waiting for them only on hooks.
The possible solution is to use the "Hollywood Principle – Don't Call Us, We'll Call You", and rewrite the wait logic to use Informers instead of polling logic.
Expected result
Helm handles correctly waiting for Kubernetes resources.
Actual result
When flag --wait is specified then Helm timeouts the installation when release contains Pod which is finished very fast (below 2s).

closing as inactive.


Could not update weather

Hi, great job for our old k4 !
Perfect installation, files edited as described, but it starts with 'initializing...' and freezes 30s later with 'could not update  weather'. Tried the two weather providers.
Best regards

That message means the file /extensions/weather-stand/bin/weather-generator.sh cannot be executed correctly.
It could be an error when the python script generates the weather svg file, or it has something to do with the png conversion. My money is on python setup.  Don't forget there're several API keys need to be filled-in as well.
As the README.md said, you should test out various scripts via SSH first before running it through KUAL.  If you haven't setup WiFi connection correctly, the device will run into infinite loop. If that happens, try to force reboot by press the power button to wake it up, release, and hold down the button for ~15 seconds until you see the Kindle boot screen.

Big thanks for your prompt answer!
Prerequiste checker was ok . I find python for K4 here:
https://www.mobileread.com/forums/showthread.php?t=88004
''Don't forget there're several API keys need to be filled-in as well.'' I just see 1 field in weather-generator-darksky and weather-generator-openweathermaps, right? I tried the complete https address (with my api key, location, etc) in my web browser and it runs fine.
I will try the ssh way and try to see what's wrong with my install.
Thanks a lot, have a good day.

I suggest that you manually run each commands in weather-generator.sh and try to identify any error.
I’ll close this issue for now, if you have further request, please feel free to reopen.

Hi x-magic,
Foud this:

@aprex83 Thanks for showing the error message. I think you are not alone. I guess I need some time to figure out why the prerequisite checker doesn't install pytz correctly. I have opened #4 for this error.


Fill in imprint from environment variables

Just in case someone wants to deploy it on their own server, it shouldn't have my imprint in there :sweat_smile:

Could this also be done via a second config file?

It would need to be a mechanism that can be configured during CI and not checked into version control. Right now, environment variables are the only thing I could think of...

Couldn't the rakefile write the additional config based on env vars?

or maybe we can modify this simple GEM
https://github.com/iBug/jekyll-environment-variables/blob/master/lib/jekyll-environment-variables.rb
to override site config via env vars following the pattern:
contact:
  name: Your Name

export JEKYLL_CONFIG_CONTACT_NAME=My Name

That does sound like a plan, yes. I'll look into it 👍


upgrade: changed pinned message from Error to Warning

This commit https://github.com/Homebrew/brew/commit/3a2e6b82fd008974c47b87a98c6c7bbf1dcdcea7#diff-aa6192b25b5254b9e0d4b95005b69a44R65 changed the message type from oh1 to onoe. I think that having pinned packages that don't upgrade it's not an error (onoe), instead I would give the user just a warning (opoo).

I disagree, I do consider this an error. @ilovezfs, thoughts?

@MikeMcQuaid why do you consider it as an error?
If I'm pinning one package, it's because I don't want it to be upgraded.
It's not an error if it doesn't get upgraded, it's just the expected behavior.
I would put just a warning to remind users that they have pinned packages, nothing more.
that said, I'm open to discussions and to change my idea if you give me valid a explanation.

why do you consider it as an error?

Let's say in Homebrew/homebrew-core we upgrade ruby in such a way that vim's linkage to ruby is broken unless you also rebuild vim against the new ruby. We will have upgraded ruby and revision bumped vim (which brew then treats as an upgrade) in the same pull request, and if you run brew upgrade without any pins in place, then nothing will break. Ruby will be upgraded to the new version, vim will be upgraded to the rebuilt bottle that links against the new ruby, and all linkage is fine.
If, however, you've pinned vim, then you will now have a broken vim installation as it's still linked against the old ruby, and the fact that you pinned vim will in no way have stopped brew upgrade from upgrading ruby, nor will any magic kick in to rebuild the old pinned version of vim against the new ruby. Your vim is now toast and you will likely end up filing an issue on our issue tracker unless you happen to understand what happened and how to fix it.
So there is a good reason to consider brew upgrade in the face of pins to be a failed command regardless of whether it has behaved "as expected."
That said, I'm not sure it's the most useful behavior because it becomes impossible to use, for example, brew upgrade && do something if you have any pins at all, and brew upgrade; do something is not the same thing, and may not be what you want to happen if any of the unpinned formulae failed to upgrade.

I agree with @ilovezfs. Sorry, passing on this.

As a workaround,
brew upgrade $(brew outdated | grep -v -f <(brew list --pinned))

probably does what you want.

Actually, despite printing the error, currently it looks like brew upgrade does exit 0 contrary to my assumption:
Josephs-MacBook-Pro:~ joe$ brew upgrade
==> No packages to upgrade
Error: Not upgrading 3 pinned packages:
bash 4.4.19, fd 6.3.0, ripgrep 0.8.0
Josephs-MacBook-Pro:~ joe$ echo $?
0

I hate to see in the output the Error word, when instead, in this (my) case is not an error at all.
If "broken dependencies" is your concern, print the error only if/when this happens.
I also spoke with other people and they all agree with me.
I'll create an alias/function and sed out the word if I match the Not upgrading $n pinned packages string, or maybe, it's time to keep using my own (brew) fork.

it's time to keep using my own (brew) fork.

Feel free, our license permits it.


SyntaxError: Cannot use import statement outside a module on Nextjs 13.5.6

/node_modules/pushy-sdk-web/src/lib/pushy.js:4
import api from '../util/api';
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at internalCompileFunction (node:internal/vm:77:18)
    at wrapSafe (node:internal/modules/cjs/loader:1288:20)
    at Module._compile (node:internal/modules/cjs/loader:1340:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at Module.load (node:internal/modules/cjs/loader:1207:32)
    at Module._load (node:internal/modules/cjs/loader:1023:12)
    at Module.require (node:internal/modules/cjs/loader:1235:19)

"next": "13.5.6",
"pushy-sdk-web": "^1.0.18",
node v20.11.1
anyone know this issue, need help

Hi @teukurijal,
Thanks for reporting this issue. We'd be glad to assist.
We've just released version 1.0.19 of the Pushy Web SDK with a fix for this issue.
Please update by running the following command:
npm install pushy-sdk-web@latest --save

Then, rerun your code and let us know if the issue is indeed resolved.

hi @pushy,
I have installed new version 1.0.19
and update service-worker.js file
// Import Pushy Service Worker 1.0.19
importScripts('https://sdk.pushy.me/web/1.0.19/pushy-service-worker.js');

still not work and got new error

Hi @teukurijal,
Apologies for that!
We've just released version 20 of the Pushy Web SDK which fully adds support for Next.js. We've tested it out and it works perfectly.
Please update by running the following command:
npm install pushy-sdk-web@latest --save

Then, rerun your code and let us know if the issue is indeed resolved.

Hi @teukurijal,
Apologies for that!
We've just released version 1.0.21 of the Pushy Web SDK which fully adds support for Next.js. We've tested it out and it works perfectly.
Please update by running the following command:
npm install pushy-sdk-web@latest --save

Make sure to import and execute the pushy-sdk-web package inside React.useEffect() to avoid Next.js Server Side Rendering as follows:
import * as React from 'react';

React.useEffect(() => {
    async function exec() {
      // Import Pushy SDK
      const Pushy = (await import('pushy-sdk-web')).default

      // Register device
      Pushy.register({ appId: 'PUSHY_APP_ID' }).then(function (deviceToken) {
        // Print device token to console
        alert('Pushy device token: ' + deviceToken);

        // Send the token to your backend server via an HTTP GET request
        //fetch('https://your.api.hostname/register/device?token=' + deviceToken);

        // Succeeded, optionally do something to alert the user
      }).catch(function (err) {
        // Notify user of failure
        alert('Registration failed: ' + err.message);
      });
    }
    exec();
  }, []);

Then, rerun your code and let us know if the issue is indeed resolved.

it's work on nextjs 13.5.6, thanks a lot @pushy


Spaceship app analytics

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context
https://github.com/fastlane/fastlane/issues/12638
Description
Adds App Analytics support to Spaceship.  For example:
app = Spaceship::Tunes::Application.find("")
app_analytics = app.analytics
time = Time.now
past = time - (60 * 60 * 24)
end_t   = time.strftime("%Y-%m-%dT00:00:00Z")
start_t = past.strftime("%Y-%m-%dT00:00:00Z")
app_crashes = app_analytics.app_crashes_interval(start_t, end_t)
pp app_crashes

Run the bot again.

Run the bot again.

https://github.com/fastlane-old/spaceship/pull/190

@joshdholtz It's working for me, but maybe I'm initializing the app variable differently.  I'm doing this:
Spaceship::Tunes.login(ENV['FASTLANE_USERNAME'], ENV['FASTLANE_PASSWORD'])
app = Spaceship::Tunes::Application.find("com.tripadvisor.LocalPicks")
app_analytics = app.analytics
puts "app_views: #{app_analytics.app_views}"
Are you doing something different?

@pajato1 Fun fact! That app I was testing it on hasn't been released yet so it didn't have any stats 😉 Can you add a fix to handle that? 😇

@joshdholtz I added the requested fix.

@joshdholtz Can I get a code review, please?

@joshdholtz I added the requested change.

@joshdholtz I added the requested changes.

@joshdholtz The tests are passing again.  The problem was the stubs had hard coded dates, so the tests started failing the next day.  Rookie mistake.

@joshdholtz It turns out the "X-Requested-By" header is required.  I've added it back in.


Newsletter 40: November 2022

Newsletter 40: November 2022
tags: newsletter
Editors: @ozkriff, @AngelOnFira, and @17cupsofcoffee
Another month has gone by, so it's time to put together the Rust Gamedev newsletter with TODO's news!
Current Schedule
The soft deadline for all section PRs is 4 Dec.
We may still accept PRs that are submitted later than this, as long as they're ready before the newsletter's release, but this isn't guaranteed. If you want your section to be included, don't leave it till the last minute!
How to Contribute
If you want to help writing the newsletter:

Read CONTRIBUTING.md.
Choose one or more of the "🆓 free" sections listed below, and leave a comment letting us know you want to work on them.

The links in brackets (like "1, 2, 3") are suggestions of links to include in the section. Feel free to add more!
The username listed next to the section (like "@ozkriff?") is a suggestion of who may want to pick up the work (usually the project's developer, or someone who has expressed interest in the past).
You are not obligated to write a section if you're tagged or your project is listed! You're welcome to ask someone else to write the section, or to ask for your project to be excluded from this month's post.
Extra sections not listed in the plan are welcomed - just leave a comment and open a PR!

Write a short overview in the newsletter's Markdown file, making sure to follow the style guidelines (see below).
Send a PR to the source branch (example: #336).
Mention this issue in your PR's description to link it all together.

Style Guidelines
The full style guide is in CONTRIBUTING.md, but here are the most important rules:

Write in third-person perspective.
Each line must be 80 characters or less, for ease of reviewing/diffing.
Only one image per section is allowed.

The maximum size is 300kb for static images and 2.5mb for GIFs.
The image should come before the text, and must have alt text for accessibility.
Prefer static images to GIFs, to keep the page load times down.

Each section should be under 1000 characters, and under 6 paragraphs.

This only applies to the rendered text, not the markup.

Keep formatting minimal - no bold/italics/etc.
Avoid long/nested bullet point lists - no changelogs!

Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]

![alt text](img)
_optional image label_

[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.

{An overview of the recent updates with links to more details}.

_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_

[Game name]: http://example.com

Articles/blog posts/videos/etc:
### [Article name]

![alt text](img)
_optional image label_

[@nickname] published an [article] about...
{overview what the resource is about}.

_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_

[Article name]: http://example.com

Current Structure & Status
Below is our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhaustive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!

Announcements

[ ] Rust Gamedev meetup - 🚧 WIP by @AngelOnFira

Game Updates

[ ] Veloren (1) - 🚧 WIP by @AngelOnFira
[ ] Yomi Hustle (1) - 🆓 free (@uzkbwza?)
[ ] Tantan’s Voxel Project (1, 2) - 🆓 free (@TanTanDev?)
[ ] Combine And Conquer (1, 2, 3, 4) - 🆓 free (@I3ck?)
[ ] Crispy's Automation RL (1) - 🆓 free (@0crispy?)
[ ] Idu (1, 2) - 🆓 free (@johann2?)
[ ] vange.rs (1) - 🆓 free (@kvark?)
[ ] gssa-rs (1, 2, 3) - 🆓 free (@devildahu?)
[ ] Scummstreets (1, 2) - 🆓 free (@dooskington?)
[ ] 8bit-duels (1, 2) - 🚧 WIP by @ThousandthStar
[ ] Space Frontiers (1, 2) - 🚧 WIP by @starwolfy
[ ] Timely Defuse (1) - 🚧 WIP by @Enet4
[ ] Jumpy - 🚧 WIP by @zicklag
[x] Rusty Vangers - ✔ done by @kvark

Learning Material Updates

[ ] Render Pipelines in wgpu (1, 2) - 🆓 free (@whoisryosuke?)
[ ] Embark: Evaluating health&quality of crates (1, 2) - 🆓 free (@repi?)
[ ] bevy+rapier (1) - 🆓 free (@mwbryant?)

Engine Updates

[ ] Bevy v0.9 (1, 2, 3) - 🆓 free (@cart?)
[ ] Hotham (1) - 🆓 free (@leetvr?)
[ ] emerald (1) - 🆓 free (@Bombfuse?)
[ ] fyrox (1, 2, 3) - 🆓 free (@mrDIMAS?)
[ ] godot-rust (1) - 🚧 WIP by @Bromeon
[ ] Alkahest (1, 2, 3) - 🆓 free (@AnthonyUtt?)
[x] pixel (1) - ✔ done by @maix0
[ ] defold-rs (1) - 🆓 free (@JustAPotota?)
[ ] Eldiron (1, 2) - 🆓 free (@markusmoenig?)

Tooling Updates

[ ] Blackjack (1, 2) - 🆓 free (@setzer22?)
[ ] EuriHerasme's Terrain Gen (1) - 🆓 free (@eurigilberto?)
[x] boytacean (1, 2) - ✔ done by @joamag

Library Updates

[ ] Iced (1) - 🆓 free (@hecrj?)
[ ] dynec (1) - 🆓 free (@SOF3?)
[ ] kopi (1) - 🆓 free (@hasenbanck?)
[ ] guiedit (1) - 🆓 free (@aleokdev?)
[ ] Sparsey (1) - 🆓 free (@LechintanTudor?)
[ ] Bevy Tweening (1) - 🆓 free (@djeedai?)
[ ] dungeon-generator (1, 2) - 🆓 free (@MoutonSanglant?)
[ ] seldom_pixel (1, 2) - 🚧 WIP by @Seldom-SE
[ ] bevy_quickmenu (1, 2) - 🆓 free (@terhechte?)
[ ] Notan (1) - 🆓 free (@Nazariglez?)
[ ] Taffy (1) - 🆓 free (@alice-i-cecile?)
[ ] bevy-hikari (1) - 🆓 free (@cryscan?)
[ ] kayak_ui (1) - 🆓 free (@StarArawn?)
[ ] leafwing_input_playback (1) - 🆓 free (@alice-i-cecile?)
[x] bevy-sequential-actions (1) - ✔ done by @hikikones
[x] bevy_atmosphere (1) - ✔ done by @JonahPlusPlus

Other News

[ ] Bullet points of any interesting news that doesn't have its own section - 🆓 free (@ozkriff?)

Discussions

[ ] "Which graphics crate do you use?" (1)
[ ] "WASM For Core Game Loop & Mods (1)

Jobs

[ ] Dims (1) - 🆓 free (@philpax?)

Publishing Steps

[ ] Final review - by everyone
[ ] Publish - by @ozkriff
[ ] Post on /r/rust, /r/rust_gamedev, /r/gamedev, URLO, twitter.com/rust_gamedev - by @ozkriff
[ ] Pin thread on Twitter - by @ozkriff
[ ] Add comment links - by @ozkriff
[ ] Add a draft of next month's newsletter - by @ozkriff

I'll gladly do godot-rust! 🤖🦀

I'm releasing bevy_atmosphere 0.5 today. Would it be fine to add it to November's newsletter?

@JonahPlusPlus sure, added to the plan

I am interested in writing about my GitHub GameOff 2022 submission, Timely Defuse. If it's OK, I should hopefully send a PR within the soft deadline.

I wrote a little section about my engine (pixel engine) , feel free to add things/change the way it is written.

@ozkriff I've just added a small description of Boytacean to the tools section.

I'll take Jumpy.

I'll take 8bit-duels

I can do bevy-sequential-actions 🙂

I'll take Sparsey 👋

Found https://github.com/torsteingrindvik/bevy-vfx-bag yesterday. Looks pretty neat. Do you want to add a section for that @torsteingrindvik?

Found https://github.com/torsteingrindvik/bevy-vfx-bag yesterday. Looks pretty neat. Do you want to add a section for that @torsteingrindvik?

Sure, thanks! I'll do it within a few hours.

I'll write up the Dims job ad when I'm at work tomorrow!

I'll do bevy_quickmenu today :)

I'm happy to take bevy-hikari.

Added a section for bevy: #1224

I'll do scummstreets tomorrow :)

Just saw this thread, beginning work now on the section for Graphite if there's still time. (Don't hold the presses for me though.) Is there any way to get included in the template each month?

It's out, sorry for another delay!
:tada: https://gamedev.rs/news/040 (/r/rust_gamedev, Twitter, Mastodon)
And as always huge thanks to all editors, contributors, and reviewers! :crab::crab:


Create gsp-critical PriorityClass

And get cluster-autoscaler to use it.
I've tested this by snowflaking in sandbox.
I think there may be a race condition here when spinning up a new
cluster: I don't know how to ensure the PriorityClass gets created
before the things that use it.
This is a proof of concept; we should have a conversation about which
things should run with this priority class (gatekeeper, the istio
sidecar injector, ...?).

If we really wanted, we could get gatekeeper to stop tenants from using this priorityclass.. but that seems like a bit much


Fails to install

Using macos, 13.1 and rakudo 2022.07.
===> Searching for: shorten-sub-commands
===> Searching for missing dependencies: as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>
===> Testing: as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>
===> Testing [OK] for as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>
===> Testing: shorten-sub-commands:ver<0.0.6>:auth<zef:lizmat>
[shorten-sub-commands] # Failed test 'does foo give foozle?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: 'foozle'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb
[shorten-sub-commands] 774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (
[shorten-sub-commands] shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<3253930520464>
[shorten-sub-commands] #     Comp
[shorten-sub-commands] Unit::Repository::NQP<3253967667976>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<3253967668016>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate:4'
[shorten-sub-commands] # Failed test 'does bar give barabas?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: 'barabas'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4f
[shorten-sub-commands] b774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod
[shorten-sub-commands] (shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<4474156445584>
[shorten-sub-commands] #     Com
[shorten-sub-commands] pUnit::Repository::NQP<4474073924360>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<4474073924400>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate:4'
[shorten-sub-commands] # Failed test 'does baz give bazzie?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: 'bazzie'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb
[shorten-sub-commands] 774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (
[shorten-sub-commands] shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<5116604477328>
[shorten-sub-commands] #     Comp
[shorten-sub-commands] Unit::Repository::NQP<5116641297160>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<5116641297200>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate:4'
[shorten-sub-commands] # Failed test 'does fnok give 'fnok' is not recognized as sub-command:
[shorten-sub-commands] # # Known sub-commands: barabas bazzie foozle?'
[shorten-sub-commands] # at t/0
[shorten-sub-commands] 1-basic.rakutest line 11
[shorten-sub-commands] # expected: ''fnok' is not recognized as sub-command:
[shorten-sub-commands] # Known sub-commands: barabas bazzie foozle'
[shorten-sub-commands] #      got: '===SOR
[shorten-sub-commands] RY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb
[shorten-sub-commands] 615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share
[shorten-sub-commands] /perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<3250575404944>
[shorten-sub-commands] #     CompUnit::Repository::NQP<3250612224776>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<3250612224816>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate:4'
[shorten-sub-commands] # Failed test 'does ba give 'ba' is ambiguous, matches: barabas bazzie?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: ''ba' is ambiguous, matches: barabas bazzie'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Use
[shorten-sub-commands] rs/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.
[shorten-sub-commands] 6/lib/shorten-sub-commands.rakumod (shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::Ab
[shorten-sub-commands] solutePath<3787446382480>
[shorten-sub-commands] #     CompUnit::Repository::NQP<3787483136776>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<3787483136816>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/frobnicate:4'
[shorten-sub-commands] # Failed test 'does s give 's' recurses into 'search'?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: ''s' recurses into 'search''
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tm
[shorten-sub-commands] p/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/regurgitate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-s
[shorten-sub-commands] ub-commands.rakumod (shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<5685
[shorten-sub-commands] 485989776>
[shorten-sub-commands] #     CompUnit::Repository::NQP<5685523137288>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<5685523137328>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/regurgitate:2'
[shorten-sub-commands] # Failed test 'does search give 'search' recurses?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: ''search' recurses'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276dd
[shorten-sub-commands] ac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/regurgitate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-comman
[shorten-sub-commands] ds.rakumod (shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<4062041042832
[shorten-sub-commands] >
[shorten-sub-commands] #     CompUnit::Repository::NQP<4061958390536>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<4061958390576>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/regurgitate:2'
[shorten-sub-commands] # Failed test 'does f give foo?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: 'foo'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774
[shorten-sub-commands] b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (short
[shorten-sub-commands] en-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<3897303592848>
[shorten-sub-commands] #     CompUnit:
[shorten-sub-commands] :Repository::NQP<3897340347144>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<3897340347184>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate:3'
[shorten-sub-commands] # Failed test 'does foo give foo?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: 'foo'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774
[shorten-sub-commands] b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (short
[shorten-sub-commands] en-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<5818965520272>
[shorten-sub-commands] #     CompUnit:
[shorten-sub-commands] :Repository::NQP<5819002667784>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<5819002667824>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate:3'
[shorten-sub-commands] # Failed test 'does 4 give 42?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: '42'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b
[shorten-sub-commands] 89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorte
[shorten-sub-commands] n-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<3079688187792>
[shorten-sub-commands] #     CompUnit::
[shorten-sub-commands] Repository::NQP<3079685948168>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<3079685948208>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate:3'
[shorten-sub-commands] # Failed test 'does 42 give 42?'
[shorten-sub-commands] # at t/01-basic.rakutest line 11
[shorten-sub-commands] # expected: '42'
[shorten-sub-commands] #      got: '===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b
[shorten-sub-commands] 89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorte
[shorten-sub-commands] n-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #     CompUnit::Repository::AbsolutePath<3586119790480>
[shorten-sub-commands] #     CompUnit::
[shorten-sub-commands] Repository::NQP<3586156544776>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<3586156544816>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate:3'
[shorten-sub-commands] # Failed test 'does 423 give '423' is not recognized as sub-command:
[shorten-sub-commands] # # Known sub-commands: 42 foo?'
[shorten-sub-commands] # at t/01-basic.rakutest
[shorten-sub-commands] line 11
[shorten-sub-commands] # expected: ''423' is not recognized as sub-command:
[shorten-sub-commands] # Known sub-commands: 42 foo'
[shorten-sub-commands] #      got: '===SORRY!===
[shorten-sub-commands] Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate
[shorten-sub-commands] # ===SORRY!=== Error while compiling /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/s
[shorten-sub-commands] horten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands)
[shorten-sub-commands] # Could not find as-cli-arguments:ver<0.0.4>:auth<zef:lizmat> in:
[shorten-sub-commands] #     /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6
[shorten-sub-commands] #     /Users/steve/.raku
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/site
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
[shorten-sub-commands] #     /Users/steve/.rakubrew/versions/moar-2022.07/install/share/perl6/core
[shorten-sub-commands] #
[shorten-sub-commands] CompUnit::Repository::AbsolutePath<6472068722576>
[shorten-sub-commands] #     CompUnit::Repository::NQP<6472106132232>
[shorten-sub-commands] #     CompUnit::Repository::Perl5<6472106132272>
[shorten-sub-commands] #
[shorten-sub-commands] # Please note that a 'META6.json' file was found in '.', of which the 'provides' section was used to determine if a dependency is available or not.  Perhaps you need to add 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' in the <provides> section of that file?  Or need to specify a directory that does *not* have a 'META6.json' file?
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/lib/shorten-sub-commands.rakumod (shorten-sub-commands):1
[shorten-sub-commands] #
[shorten-sub-commands] # at /Users/steve/.zef/tmp/90276ddac89406c4fb774b89d12b5eb615763afb.tar.gz/shorten-sub-commands-0.0.6/t/numicate:3'
[shorten-sub-commands] # You failed 12 tests of 12
===> Testing [FAIL]: shorten-sub-commands:ver<0.0.6>:auth<zef:lizmat>

OK, manually installing zef install 'as-cli-arguments:ver<0.0.4>:auth<zef:lizmat>' did the trick.

Thanks for the headsup.  Will look at this soon!

Sadly, I cannot reproduce this on 2022.12+
I assume it was either an issue with the zef that you used, or with 2022.07, or something else.
I'm leaning towards closing this issue.


Any way to handle special permissions?

Is it currently possible to have special permissions granted using this library.
Special permissions such as:

Notification Access

Draw over other apps

Modify system settings..

Please let me know if it isn't possible, I will try my best to implement it

As these require you to go to a separate screen they can't be used with SlideBuilder. However you can probably subclass it and implement the permission request process by yourself.

Pretty much what I ended up doing.
I though about creating a PR that would make this process seamless using this library, but I found that there are a lot of issues with special permissions, for example, apparently MIUI required users to grant draw over other apps permission manually using their own API to do so, so the default API for Android M+ might not work on all of their devices.
This is just an example, my point is that it wouldn't be the best idea to try and implement this feature into a library.
Thanks for your response


Added Samanage to the showcase

Added the Samanage iOS React Native app to the showcase.

Please add the app to the apps array.
See the explanation here: http://facebook.github.io/react-native/showcase.html

@mkonicek How can I get our app on the featured list?

@eyaleizenberg I believe @brentvatne mantains that list :)
@facebook-github-bot shipit

In general we should probably add every app to the apps list and only later move apps to featured apps.


Builds better schema rules from Dry::Struct (StructClassBuilder)

Struct Extensions (Dry::Validation.load_extensions(:struct))
Dry::Struct can be used in schema validation with the .schema(, .filled( method to define a nested structure that should validate (satisfy) a predefined Dry::Struct.
The issue addressed here is that there are some assumptions baked into the StructClassBuilder that has several unintuitive behaviors:
https://github.com/dry-rb/dry-validation/blob/88cb4fb38add9abecfee4a5bae09d2a07fd90e80/lib/dry/validation/extensions/struct.rb#L6-L16

all keys are declared as required, which ignores the meta[:omittable] metadata declared on the struct field type
all keys' values are assumed as .filled, which may not be the case and ignores the Struct field's Type coercible and optional settings
Structs with Array-type fields don't validate the array members properly, as noted in #396 (https://github.com/dry-rb/dry-validation/pull/396)
Structs with Array-type fields aren't allowed to be empty, which a Struct allows.

I'm in agreement about not using structs to validate, but it seems like this functionality was at least somewhat intended as the extension exists today. If this is unwanted there's already a workaround--define your schema validation separately from your struct. Doing so means
a good deal of duplicating the type information between the schema and the struct.
This modifies the StructClassBuilder to build a schema more intelligently, by respecting omittable and handling arrays of types and other nested structs. The time complexity seems similar in that this
is as recursive as the previous implementation, with the exception that this has a few easy conditionals.

Closing because there seems to be no activity here.


Maybe consider donating to the github.com/HDL organization?

The HDL GitHub organization is trying to build a critical mass around providing open source EDA tooling (like the open source FPGA tooling) in a number of different ways like static binaries, conda, docker and including "native" solutions like homebrew. The idea is bringing these different styles of packaging together under one GitHub organization so people can share tips around how to get things auto-building on CI, workarounds for common issues, how to test the tools are working, etc. There is quite a long document put together by the GHDL / V-Unit community about the various asks of things here.
I'm sure if you moved the repository over there would be a strong incentive to add things like GHDL and demonstrate things like mixed-synthesis support. The community did that recently for the Fomu Workshop! See https://workshop.fomu.im/en/latest/vhdl.html and https://workshop.fomu.im/en/latest/mixed-hdl.html

I'm definitely open to this. Would more immediately be involved beyond a change in namespace?

I'm definitely open to this. Would more immediately be involved beyond a change in namespace?

Hi @ktemkin! No more involvement neither now nor in the foreseeable future.
As @mithro said, the main target is to bring people from several camps of the open source hardware community into a meeting point. The idea is that watching what others are doing can help reduce the fragmentation and/or to explain to newcomers where is the fragmentation and why.
The first point to start with is ensuring that all users can get the tools. Since these are all very rapidly moving targets, system package managers on most distros are too slow, so the community has proposed several solutions which are apparently conflicting. However, some are focused on Verilog, others on VHDL, some are for synthesis, some for simulation... There are very few projects which cover an "acceptable" spectrum of tools because typically each of us is focused on our area of expertise. We hope that we can achieve a wider knowledge and coordination.
Yet, none of the projects in the HDL organisation is the main project of any of the contributors. Therefore, no need to rush. The idea is, before you do something, think whether it fits in one of the existing repos, or whether creating a repo in that organisation makes sense. Then, go ahead with the agenda you had. Do not force yourself to make more than you had planned to, but neither constraint the descriptions to what you will implement yourself only.
See, for instance, https://hdl.github.io/MINGW-packages/#_packagestools. Some of those tools were packaged by others (unrelated to HDL org), some of them were packaged by me (with feedback/help from project maintainers) and some are not going to be packaged in the near future, but they are on the radar.
There are also containers (https://hdl.github.io/containers/) and Bazel rules (https://github.com/hdl/bazel_rules_hdl) in the org. Moreover, there are sibling projects which are maintained independently, but which are tightly related (https://github.com/hdl/smoke-tests/blob/main/CONTEXT.md). There is communication and collaboration with open-tool-forge/fpga-toolchain and also with the Conda/Python work being done in Antmicro/SymbiFlow.
NOTE: https://github.com/hdl/packages was created a few days ago, so we will probably move CONTEXT.md from smoke-tests into there, and use it as the index for referencing other repos (in or out of the org). Probably include a table shown which tools are available in each environment.
smoke-tests itself is an attempt at gathering minimal and atomic tests for the most common tools. Regardless of the procedure used for building and installing the tools, if a bash shell is available, those tests should pass. That provides a minimal reference about where each packaging approach is.
There are repos not specifically related to packaging because the HDL org is not constrained to that (it's just the first step in the way).
constraints gathers board, device and memory constraints which are required in any FPGA design. Again, that information exists in many places using different file types and syntaxes. However, data is the same. We started with gathering constraint files as used by tools, but there is interest in closing the gap with litex-boards and similar proposals.
awesome was the original reason for creating the organisation. It is an awesome list on steroids, where each tool is defined in a different markdown file with a frontmatter. In all my packaging repos, I ref the tools to their awesome page. That allows to use a single URL in docs of packaging repos, but have several references (repo, website, docs, youtube, twitter, etc.) in the corresponding awesome page. Most awesome pages are placeholders yet, tho, since I prioritised containers and MSYS2 packaging.

Hi @ktemkin! No more involvement neither now nor in the foreseeable future.
As @mithro said, the main target is to bring people from several camps of the open source hardware community into a meeting point. The idea is that watching what others are doing can help reduce the fragmentation and/or to explain to newcomers where is the fragmentation and why.
The first point to start with is ensuring that all users can get the tools. Since these are all very rapidly moving targets, system package managers on most distros are too slow, so the community has proposed several solutions which are apparently conflicting. However, some are focused on Verilog, others on VHDL, some are for synthesis, some for simulation... There are very few projects which cover an "acceptable" spectrum of tools because typically each of us is focused on our area of expertise. We hope that we can achieve a wider knowledge and coordination.
Yet, none of the projects in the HDL organisation is the main project of any of the contributors. Therefore, no need to rush. The idea is, before you do something, think whether it fits in one of the existing repos, or whether creating a repo in that organisation makes sense. Then, go ahead with the agenda you had. Do not force yourself to make more than you had planned to, but neither constraint the descriptions to what you will implement yourself only.
See, for instance, https://hdl.github.io/MINGW-packages/#_packagestools. Some of those tools were packaged by others (unrelated to HDL org), some of them were packaged by me (with feedback/help from project maintainers) and some are not going to be packaged in the near future, but they are on the radar.
There are also containers (https://hdl.github.io/containers/) and Bazel rules (https://github.com/hdl/bazel_rules_hdl) in the org. Moreover, there are sibling projects which are maintained independently, but which are tightly related (https://github.com/hdl/smoke-tests/blob/main/CONTEXT.md). There is communication and collaboration with open-tool-forge/fpga-toolchain and also with the Conda/Python work being done in Antmicro/SymbiFlow.
NOTE: https://github.com/hdl/packages was created a few days ago, so we will probably move CONTEXT.md from smoke-tests into there, and use it as the index for referencing other repos (in or out of the org). Probably include a table shown which tools are available in each environment.
smoke-tests itself is an attempt at gathering minimal and atomic tests for the most common tools. Regardless of the procedure used for building and installing the tools, if a bash shell is available, those tests should pass. That provides a minimal reference about where each packaging approach is.
There are repos not specifically related to packaging because the HDL org is not constrained to that (it's just the first step in the way).
constraints gathers board, device and memory constraints which are required in any FPGA design. Again, that information exists in many places using different file types and syntaxes. However, data is the same. We started with gathering constraint files as used by tools, but there is interest in closing the gap with litex-boards and similar proposals.
awesome was the original reason for creating the organisation. It is an awesome list on steroids, where each tool is defined in a different markdown file with a frontmatter. In all my packaging repos, I ref the tools to their awesome page. That allows to use a single URL in docs of packaging repos, but have several references (repo, website, docs, youtube, twitter, etc.) in the corresponding awesome page. Most awesome pages are placeholders yet, tho, since I prioritised containers and MSYS2 packaging.


test: poc an e2e test for CodyChat command

Adds a test that do a full roundtrip with a real token, testing the entire process. It's now in an different test suite, and runs in its own job.
If the tests are run with SG_NVIM_E2E=true, the runner will expect SRC_ACCESS_TOKEN to be defined, and it will be used for making real requests against s2.
To ensure the tests are stable, the e2e tests uses https://github.com/sourcegraph/e2e-sg.nvim/tree/main which is a duplicate of sourcegraph/conc, that we fully control. The readme of that repo reflects that.

@tjdevries the e2e tests are not removing the temp folder created when the tests are executed, as the few available helpers from busted do not include teardown. I think it's perfectly fine in CI, as the whole thing gets discarded, but it'd be better if we did, as we'll most probably run those tests locally as well.
I haven't found yet how to do it, if you know on top of your head how to do it, I'm happy to fix it.


HPA: Remove controller.autoscaling.apiVersion, use capabilites instead.

Tests on workload clusters (not always required)
For changes in the chart, chart templates, and ingress controller container images, I executed the following tests
to verify them working in live enviromnents:

Test / Provider
AWS
Azure
KVM

Upgrade from previous version
✔

Existing Ingress resources are reconciled correctly
✔

Fresh install
✔

Fresh Ingress resources are reconciled correctly
✔

Testing was done using hello-world-app.
Hint for KVM:
kubectl port-forward -n kube-system svc/nginx-ingress-controller-app 8080:80
ingress_domain=host.configured.in.ingress; curl --connect-to "$ingress_domain:80:<IP_ADDRESS>:8080" "http://$ingress_domain" -v

I tested this on AWS 18.1.1 and AWS 17.4.4. So both Kubernetes version, 1.22 and 1.23.

Gonna release app version v2.22.1 after this got merged.


I tis difficult to understand content in "notes"

Can you please explain the content of "note" in the middle page:
I don't even understand what it will tell me, can you find other way to express it more easy to understand?
"When an application requires assignment, user consent for that application isn't allowed. This is true even if users consent for that app would have otherwise been allowed. Be sure to grant tenant-wide admin consent to apps that require assignment."

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

ID: 505a457a-6fd3-7fac-942f-f975883a495a
Version Independent ID: 97bc6852-8ce4-261d-473c-89949c152478
Content: Manage access to apps - Azure AD
Content Source: articles/active-directory/manage-apps/what-is-access-management.md
Service: active-directory
Sub-service: app-mgmt
GitHub Login: @eringreenlee
Microsoft Alias: ergreenl

@byguo2018  Thanks for the question! We are investigating and will update you shortly.

@byguo2018  I have included links to the required documents to understand the statement.
If you have Configured user consent settings to allow standard users to consent and also configured App role assignment, standard users will no longer be able to consent. you will need to Grant tenant-wide admin consent to an application in that case.

@byguo2018  closing out the issue.


Fix game object memory leak

When calling destroy directly on a game object, the shutdown event for this game object on the scene never gets turned off, thus leading to a memory leak. I wasn't 100% sure if this is where/how this should be done, but it seems to be working for us in our testing.

So, it turns out there is an issue with this. After deploying this, we discovered that there were random lag spikes, which turned out to be when several dozen game objects were destroyed in a single frame. Is there any reason this is using events for shutdown instead of just looping through the list when shutting the scene down? Seems like that would be much more efficient (for example, our main scene has 4-5k game objects, and even though most of them are inactive, this still causes thousands of idle events to be setup).

The original issue (not clearing the shutdown event list) has been resolved in the master branch.
The follow-up comment sounds more like a re-structuring / feature request, so best opened as such as an issue, rather than lost to time in a PR comment.


0.4.0

Also need to bump time machine

I saw that timemachine and remote didn't have any changes since last release, so I left them out. Should I still bump?


Multilanguage?

Hi
This is more a question than an issue. Do you have any best practice suggestions in regards to multilanguage support? Should we just create a dynamics-nav-app folder for every language and translate the content?
Best regards
Džoka Mitrov

Hello again,
No, we have language-specific repos in GitHub. You can fork those as well - or create your own if you want a language that we don't currently support like Catalan, for example. Take a look at the German repo here:
https://github.com/MicrosoftDocs/nav-content.de-DE

The folder https://github.com/MicrosoftDocs/nav-content.de-de/tree/master/dynamics-nav-app
looks quite empty :-)
From https://github.com/MicrosoftDocs/nav-content.de-de/pull/1 I can see that the filenames of the markdown files are in english but the content is in german. Good to know.

Sorry, I forgot to say that you have to switch to the live branch in the localization repos: https://github.com/MicrosoftDocs/nav-content.de-de/tree/live/dynamics-nav-app
And yes, the filenames are the same across all languages, but the content is not.


Multi files upload

Description
Context here on Slack
Video is here.

Risk

Deploy Plan

PMRW, happy to fix ASAP if something is wrong.
But tested it well and reviewed it carefully, so I think it's very low risk to merge.
cc @spolu since you are the reviewer.