Initialize Maisi readme

Fixes # .
Description
Initialize Maisi readme. This is not final version. It only initialize it to allow parallel contribution.
Checks

[ ] Avoid including large-size files in the PR.
[ ] Clean up long text outputs from code cells in the notebook.
[ ] For security purposes, please check the contents and remove any sensitive info such as user names and private key.
[ ] Ensure (1) hyperlinks and markdown anchors are working (2) use relative paths for tutorial repo files (3) put figure and graphs in the ./figure folder
[ ] Notebook runs automatically ./runner.sh -t <path to .ipynb file>

Hi @Can-Zhao @KumoLiu , shall we rename the generative folder into generative_models or generation in this PR? It seems a good timing as we don't have other active PRs
git mv generative generative_models

Hi @Can-Zhao @KumoLiu , shall we rename the generative folder into generative_models or generation in this PR? It seems a good timing as we don't have other active PRs
git mv generative generative_models

(My comment is only applicable if this PR will be finished in a day or less)

Yes, I agree

Hi @Can-Zhao, please help renamed the generative dir to generation and modify the related "Setup environment" section. Thanks!

Hi @Can-Zhao, please help renamed the generative dir to generation and modify the related "Setup environment" section. Thanks!

I will change it after all other comments are resolved. Or we can open another PR to do it to make it more tractable


Possible to move/adjust UI elements?

This works great on 32:9 but it does make the UI elements stick out a bit more. The minimap is the worst offender. Would it be possible to realign these some way?

Yes it's possible but unless there is a better method then it would involve moving individual UI elements one by one then it would be a rather difficult process. You'd have to shift each part of the UI by specific amounts. So for that reason it's probably not something that would I would take on doing. I will look into it a bit further and see if there's a better way but it may go nowhere.
TL;DR it's possible but unlikely that I would do it for RF5Fix.

Makes sense. It looks fine as is for the most part. I only cringe when I expand the minimap which is only for quick checks so it is definitely not something needed if the effort is a lot of work when it's a feature that is really not needed. I appreciate the update and thanks for doing RF5Fix. It fixed some stuttering issues I was having so definitely enjoying it!

I guess the elements are positioned with x/y coordinates? how aboaut adding an simple offset option for the top left and top right elements. That way we could get them to our position with some try and error :)


addition of rankine conversions in constants

Hello,
I did small additions to the scipy.constants module: I added converting functions from Rankine scale to other temperature scales and vice versa.
This might be useful since many people keep using this scale.

@Gillu13 in principle I'm fine with adding this scale, but I think adding 6 functions is too much. It also makes it even more expensive (in terms of # of funcs) to add more scales - what if someone else needs the Romer scale tomorrow? Therefore I think if this is added, a single function convert_temperature(degrees, scale, newscale) or some such name would be better.
Can you bring this up on the scipy-dev mailing list? That's where we decide on adding new features.

@rgommers sorry I was out of town for a little while. I see your point. OK I'll bring this up on the scipy-dev mailing list.

I just attempted to reply to this issue on the mailing list but unfortunately my reply was again rejected by the mail server.
I agree with Ralf. These are a lot of extra, trivial, functions. Furthermore, functions like C2F don't tell me anything as to what it does. Therefore I would suggest a function name that actually describes what it does, e.g. convert_temperature(value, old_scale, new_scale) as Ralf suggested or perhaps convert_temperature(old_scale, new_scale)(temperature). I like the latter since often you only do one type of conversion and this way you just reuse the converter. Of course you can always achieve this using partial or lambda.

@FRidh did you send your email from a Gmail account? There was just another report of rejected mail here: https://github.com/numpy/numpy/issues/7238


fix(scorecard-page): allow custom base domain

Change description

Description here

This change updates the ScoreCardServicePage.tsx to allow for custom domain names to be used.  Previously if someone had an on-prem instance of Cortex and also had the Backstage plugin, a user who clicks on the View in Cortex link would be sent to https://app.getcortexapp.com instead of their on-prem installation.
Type of change

[ ] Bug fix (fixes an issue)
[X] New feature (adds functionality)
[ ] Improvement (improves codebase without changing functionality)

Related issues
Checklists
Development

[X] Lint rules pass locally
[X] Application changes have been tested thoroughly
[X] Automated tests covering modified code pass

Security

[X] Security impact of change has been considered
[ ] Code follows company security practices and guidelines

Code review

[X] Pull request has a descriptive title and context useful to a reviewer. Screenshots or screencasts are attached as necessary
[ ] "Ready for review" label attached and reviewers assigned
[ ] Changes have been reviewed by at least one other contributor
[ ] Pull request linked to task tracker where applicable

Thanks for the suggestions @FoodProduct. Happy to keep working it if there is additional items required after these three commits go through.

I'm not sure why the yarn.lock got updated when I ran yarn install locally. Are you ok with those changes otherwise I can try to revert the.

@jsundquist Looks like we'll also need to update this call
https://github.com/cortexapps/backstage-plugin/blob/30dfba2dadd17293d73d98fe481feb6620b11533/src/components/Scorecards/ScorecardsServicePage/ScorecardsServiceProgress.tsx#L116
to be
{cortexScorecardPageURL({scorecardId})

I'm not sure why the yarn.lock got updated when I ran yarn install locally. Are you ok with those changes otherwise I can try to revert the.

Thanks for asking -- I forgot to comment on that. I would prefer we revert any yarn lock changes since we're not explicitly trying to change the dependency tree.

We also need to explicitly bump the version in package.json. Since this is technically a "feature" let's aim for 1.3.0.

Looking good so far! I'm just trying to poke at this a little bit locally just in case...

Ah yep looks like each package needs to define its own config schema https://backstage.io/docs/conf/defining

I took the liberty of moving this changeset and fixing all the connecting pieces into https://github.com/cortexapps/backstage-plugin/pull/85. Thank you so much for kicking this off!

Closing in favor of https://github.com/cortexapps/backstage-plugin/pull/85. Thanks again!


AttributeError: module 'tensorflow.python.ops.linalg.linear_operator_util' has no attribute 'matmul_with_broadcast'

I can`t run any magenta commands.
Here is an example  for melody_rnn_generate --config=attention_rnn --bundle_file=attention_rnn.mag --out_dir = ./out/attention --num_outputs=10 --num_steps = 256 --primer_melodi="[60]"
OUTPUT:
WARNING: Logging before flag parsing goes to stderr.
W0619 22:20:26.601500 15344 lazy_loader.py:50]
The TensorFlow contrib module will not be included in TensorFlow 2.0.
For more information, please see:

https://github.com/tensorflow/community/blob/master/rfcs/20180907-contrib-sunset.md
https://github.com/tensorflow/addons
https://github.com/tensorflow/io (for I/O related ops)
If you depend on functionality not listed there, please file an issue.

Traceback (most recent call last):
File "c:\users\dragos\appdata\local\programs\python\python36\lib\runpy.py", line 193, in run_module_as_main
"main", mod_spec)
File "c:\users\dragos\appdata\local\programs\python\python36\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\Dragos\AppData\Local\Programs\Python\Python36\Scripts\melody_rnn_generate.exe_main.py", line 5, in
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\magenta_init.py", line 26, in
import magenta.common.beam_search
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\magenta\common_init_.py", line 20, in
from .nade import Nade
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\magenta\common\nade.py", line 24, in
import tensorflow_probability as tfp
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\tensorflow_probability_init_.py", line 78, in
from tensorflow_probability.python import *  # pylint: disable=wildcard-import
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\tensorflow_probability\python_init_.py", line 22, in
from tensorflow_probability.python import distributions
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\tensorflow_probability\python\distributions_init_.py", line 61, in
from tensorflow_probability.python.distributions.linear_gaussian_ssm import LinearGaussianStateSpaceModel
File "c:\users\dragos\appdata\local\programs\python\python36\lib\site-packages\tensorflow_probability\python\distributions\linear_gaussian_ssm.py", line 41, in
_matmul = linear_operator_util.matmul_with_broadcast
AttributeError: module 'tensorflow.python.ops.linalg.linear_operator_util' has no attribute 'matmul_with_broadcast'

matmul_with_broadcast is not available in TensorFlow 1.14. Use a TensorFlow version between 1.13 and 1.14 excluded.


some problems about code

Sorry to interrupt. When I tried to run the code, it gives me the information below. Could you please tell me the probable reason for this? Thanks in advance.

NotFoundError (see above for traceback): Unsuccessful TensorSliceReader constructor: Failed to find any matching files for inception_v3.ckpt
[[Node: save/RestoreV2_142 = RestoreV2[dtypes=[DT_FLOAT], _device="/job:localhost/replica:0/task:0/cpu:0"](_recv_save/Const_0, save/RestoreV2_142/tensor_names, save/RestoreV2_142/shape_and_slices)]]
[[Node: save/RestoreV2_83/_639 = _Recvclient_terminated=false, recv_device="/job:localhost/replica:0/task:0/gpu:0", send_device="/job:localhost/replica:0/task:0/cpu:0", send_device_incarnation=1, tensor_name="edge_1708_save/RestoreV2_83", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/gpu:0"]]

It seems that the program tried to read info from a file named "inception_v3.ckpt", which I didn't find in the folder... Is there any method to solve this problem?

You need to download the checkpoints at http://ml.cs.tsinghua.edu.cn/~yinpeng/nips17/nontargeted/models.zip.

Thanks a lot for the ckpt files!! This time I run the program with those ckpt files, sadly there still exist some problems... Then it gives me the information below... It seems successfully read in the ckpt infos, however when reading in the png files it met with some encoding problems.. I guess it's the function scipy.misc.imread that result in this but I didn't find how to solve this..

Traceback (most recent call last):
File ".\attack_iter.py", line 244, in
tf.app.run()
File "D:\software\conda\envs\tf_1_1\lib\site-packages\tensorflow\python\platform\app.py", line 48, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File ".\attack_iter.py", line 239, in main
for filenames, images in load_images(FLAGS.input_dir, batch_shape):
File ".\attack_iter.py", line 93, in load_images
image = imread(f, mode='RGB').astype(np.float) / 255.0
File "D:\software\conda\envs\tf_1_1\lib\site-packages\numpy\lib\utils.py", line 101, in newfunc
return func(*args, **kwds)
File "D:\software\conda\envs\tf_1_1\lib\site-packages\scipy\misc\pilutil.py", line 164, in imread
im = Image.open(name)
File "D:\software\conda\envs\tf_1_1\lib\site-packages\PIL\Image.py", line 2887, in open
prefix = fp.read(16)
File "D:\software\conda\envs\tf_1_1\lib\site-packages\tensorflow\python\lib\io\file_io.py", line 122, in read
pywrap_tensorflow.ReadFromStream(self._read_buf, length, status))
File "D:\software\conda\envs\tf_1_1\lib\site-packages\tensorflow\python\lib\io\file_io.py", line 90, in _prepare_value
return compat.as_str_any(val)
File "D:\software\conda\envs\tf_1_1\lib\site-packages\tensorflow\python\util\compat.py", line 106, in as_str_any
return as_str(value)
File "D:\software\conda\envs\tf_1_1\lib\site-packages\tensorflow\python\util\compat.py", line 84, in as_text
return bytes_or_text.decode(encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte

I'm not sure about this problem, maybe due to the scipy.misc versions. I suggest to try other image loading functions, such as PIL.Image, which may be more stable.

I tried PIL.Image, which gives me same error information. Then I tried to rewrite the code in the readin part, and it works well. It seems that in your code, type of f makes f unable to be accepted as parameter of  imread (or Image.open)(in attack_iter.py, line 92). (However, it seems weird that imsave works fine)


portable-ruby: update to track the 2.3 maintenance branch

This is based on a conversation with @JCount. There are security and other bugfixes included in the 2,3 branch past the 2.3.3 release shipped by Apple; it feels better to ship a Ruby without known issues, even if that means deviating from Apple's Ruby a bit.
This PR switches over to building from the 2.3 maintenance branch. As a result, I was able to remove all the patches currently in the formula; they're all already in that branch.

There are security and other bugfixes included in the 2,3 branch past the 2.3.3 release shipped by Apple; it feels better to ship a Ruby without known issues, even if that means deviating from Apple's Ruby a bit.

I very strongly disagree, I'm afraid. The intention of our portable ruby is to avoid supporting multiple Ruby versions so we should distribute as closely identical version to the one Apple does. Additionally, the portable-ruby upgrade process is not particularly nice or smooth and I'd rather avoid any upgrades where not warranted by issues directly affecting Homebrew itself.

https://github.com/mistydemeo/homebrew-portable/blob/b4f38e6fc30c94aa122bb98b1ea28e51f60c1865/Formula/portable-ruby.rb#L112-L120
It's probably worth changing this at some point to a solution that doesn't e.g. set SSL_CERT_FILE if you require "securerandom" as this breaks curl when called by Ruby subprocesses.

The intention of our portable ruby is to avoid supporting multiple Ruby versions so we should distribute as closely identical version to the one Apple does

With that in mind: https://opensource.apple.com/source/ruby/ruby-131/ruby/ may be the best upstream for us to use.

Currently, there are widely known security vulnerabilities in the version of portable-ruby we ship. These issues, among others, have been addressed in trunk and backported to the ruby_2_3 branch. These backports are cherry-picked to maintain both API and ABI compatibility in accordance with ruby's version policy post version 2.1.0, theoretically meaning that Ruby 2.3.5 should be an almost drop-in replacement.
Introducing a semantic versioning scheme and branching policy
Given that we have already switched to essentially requiring users to use our portable-ruby, I cannot see how we can merely match Apple's version, using an outdated, vulnerable TEENY version given:

(3) TEENY version is incremented when functionality is added in a backward-compatible manner.

Being cognizant of these security issues and how at least some of them apply to our use case, I think it would be good to address them, given the ability to do so.

The intention of our portable ruby is to avoid supporting multiple Ruby versions so we should distribute as closely identical version to the one Apple does.

@MikeMcQuaid What do you consider to be closely identical "enough", as in what sort of criteria do you use, and how much and what sort of patching do you think is appropriate?

Currently, there are widely known security vulnerabilities in the version of portable-ruby we ship.

Which vulnerabilities? Please demonstrate an exploit of one of these vulnerabilities through use of Homebrew.

theoretically meaning that Ruby 2.3.5 should be an almost drop-in replacement.

Theoretically is not good enough. Additionally, where there are bugs in the system Ruby that require workarounds: we want to workaround them everywhere.

Given that we have already switched to essentially requiring users to use our portable-ruby

We have not. This is only the case on people not using High Sierra. The number of people using High Sierra will increase over time. In under two years Apple may not have updated the system Ruby again so we may end up with no supported versions using portable-ruby.

Being cognizant of these security issues and how at least some of them apply to our use case, I think it would be good to address them, given the ability to do so.

Again: which security issues and please demonstrate how they are exploitable in Homebrew's case?
Additionally, if these vulnerabilities are present in our Ruby but not in Apple's Ruby: we should apply the same patches Apple has, I agree. If they are present in Apple's Ruby: it's not sufficient to ship a portable Ruby with these issues fixed as some users will still be using the system Ruby.

@MikeMcQuaid What do you consider to be closely identical "enough", as in what sort of criteria do you use, and how much and what sort of patching do you think is appropriate?

I've explained my preferences above but I'll be more explicit in order of decreasing preference:

We leave our Ruby as-is
We ship Apple's Ruby from https://opensource.apple.com/source/ruby/ruby-131/ruby/
We apply patches on top of this existing formula to patch issues that are affecting Homebrew

One of the most important things @mxcl taught me in the early days of this project was that as a maintainer we should not fix bugs speculatively. What was meant by that is we should not be spending our time fixing issues that are not user reported when there are unclosed and unfixed user reported issues and beyond that not fix issues that are not user visible until all user visible issues are fixed. I think it's worth ruminating on that in the context of this discussion.

I respectfully disagree that fixing security issues in a "speculative" manner in Homebrew, which from your above posts would be any time they are not actively being exploited, or explicitly known to be exploitable, to be a waste of time.
I suppose it is a matter of priorities. For me, the existence of widely known security issues, with fixes available, warrants action even if it is not directly known how they might be exploitable in a given use case or do not seem to be particularly dire. This is mainly because I do not personally consider myself to be knowledgable enough, or qualified, to make that call. Hence, I defer to upstream's judgement on the issue when it comes to security fixes, which in the instance included advising all users to update.
However, since it does not seem that we will be making a change, I will drop the matter since the issues do not superficially seem to be critical enough to pick a fight over, and because I have made my opinion on the matter clear.

I've explained my preferences above but I'll be more explicit in order of decreasing preference:

We leave our Ruby as-is
We ship Apple's Ruby from https://opensource.apple.com/source/ruby/ruby-131/ruby/
We apply patches on top of this existing formula to patch issues that are affecting Homebrew

is my preference out of the three, so I'll close this PR.


Modlog: Check for tac availability for modlog

oops forgot BSD

This is unrelated to this pull request, but why do we use execFileSync????

It's just a one-time thing outside of the main thread, so it's easier than writing thread-safe code (and probably faster than incurring async overhead), I'd assume.

Right, forgot it's a separate process. Still, ugh...


Transform blocks into async move for more compatibility

This is effectively #125 with correct drop ordering. I've kept the changes minimal, hence the temporary allow(dead_code, unused_imports), which will be removed once this is approved and I sweep out the now-unused code.
This breaks #45/#97, which from a cursory reading, looks like is a result of hard-coding previous functionality into tracing, though do let me know if there's something I can do here to maintain that compatibility. Otherwise, tracing needs to be aware that self is renamed __self after the block transform rebindings.
I should add: this makes quite a few more impls in Rocket compile without needing to manually expand the async-trait or other hackery. This fixes all of the cases related to #61 in Rocket. My guess, though I haven't tested, is that this fixes #126 as well.

cc @nightmared @hawkw re: #45/#97

A significant fraction of them are broken by this PR, so I will get started on triaging those.

Awesome! Let me know if I can help with triaging some of those!

A lot of things that use self more than once in a function fail with "borrow of moved value". Something like:
use async_trait::async_trait;

#[async_trait]
trait Trait {
    async fn f(self);
}

#[async_trait]
impl Trait for String {
    async fn f(self) {  // same for &mut self
        println!("{} {}", self, self);
    }
}

error[E0382]: borrow of moved value: `self`
  --> src/main.rs:11:27
   |
10 |     async fn f(self) {
   |                ---- value moved here
11 |         println!("{} {}", self, self);
   |                           ^^^^ value borrowed here after move
   |
   = note: move occurs because `self` has type `String`, which does not implement the `Copy` trait

Ah, that one's easy. So the SelfRenamer visitor only looks at Idents to rename all self to __self; the self there are arbitrary tokens in the macro call's token stream, so they're missed by the renamer.
We could visit the tokens in the token stream and rename those self's too.
Alas, I'd hope there was something more clever we could do with self. It's a real bummer to rename self to __self and then have to rename every other self in the block.

We could visit the tokens in the token stream and rename those self's too.

Now that I take a closer look at your original implementation, I see that this is exactly what you used to do.

Here is a "type mismatch" failure that appears to be quite common:
use async_trait::async_trait;

#[async_trait]
pub trait Trait {
    async fn f() -> Box<dyn Stream<Item = ()>> {
        Box::new(Iter(std::iter::empty()))
    }
}

pub struct Iter<I>(I);

pub trait Stream {
    type Item;
}

impl<I: Iterator> Stream for Iter<I> {
    type Item = I::Item;
}

error[E0271]: type mismatch resolving `<impl Future as Future>::Output == Box<(dyn Stream<Item = ()> + 'static)>`
 --> src/main.rs:5:48
  |
5 |       async fn f() -> Box<dyn Stream<Item = ()>> {
  |  ________________________________________________^
6 | |         Box::new(Iter(std::iter::empty()))
7 | |     }
  | |_____^ expected trait object `dyn Stream`, found struct `Iter`
  |
  = note: expected struct `Box<(dyn Stream<Item = ()> + 'static)>`
             found struct `Box<Iter<std::iter::Empty<_>>>`
  = note: required for the cast to the object type `dyn Future<Output = Box<(dyn Stream<Item = ()> + 'static)>> + Send`

I think those are the big two. Will check again after those are fixed. There is a third category which is some logging-related proc macros doing something tracing-like on the inner code but we can get that fixed to recognize Box::pin(async move {...}). As far as I can tell all the failures involve one of these three: self in a macro argument, trait object in return type, or hacky proc macro which is fine to break.

One more thing: this regresses #105 on compilers 1.46 and older, which is this failure in the 1.40 CI job:
error[E0425]: cannot find value `__self` in this scope
   --> tests/test.rs:599:13
    |
599 |             #[async_trait]
    |             ^^^^^^^^^^^^^^ not found in this scope

If it's easy, it would be good to get that worked around again even if new rustc fixed the bug. It was only a 1 line workaround in #105.

I'll take a look at this. I guess the proper course of action would be to support both the old and the new behavior ?
if so, looks like we need to do some working on tracing-attributes :p

I tried the latest commit -- it's regressing some code like this:
use async_trait::async_trait;

#[async_trait]
pub trait Trait: Sized {
    async fn f(self) {
        struct Struct;
        impl Struct {
            fn f(self) {
                let _ = self;
            }
        }
    }
}

error[E0434]: can't capture dynamic environment in a fn item
 --> src/main.rs:9:25
  |
9 |                 let _ = self;
  |                         ^^^^
  |
  = help: use the `|| { ... }` closure form instead

Also this:
#![deny(warnings)]

use async_trait::async_trait;

#[async_trait]
pub trait Trait {
    async fn f() {
        unimplemented!()
    }
}

error: unreachable expression
 --> src/main.rs:7:18
  |
7 |       async fn f() {
  |  __________________^
8 | |         unimplemented!()
  | |         ---------------- any code following this expression is unreachable
9 | |     }
  | |_____^ unreachable expression

Alright, that last commit should handle all of the regressions thus far. As a side effect, some error messages have improved. Feel free to hit me with more regressions.
I've also marked the tracing test should_panic for now.

Oh, perhaps I missed the point of the unreachable example you showed. I see the deny warnings now. Makes sense. Will take a look a bit later.

This looks good to me.
I'll give a little time before merging to give the tracing folks a chance to get an update out.

Awesome. I'll remove all of the unused code then.

On some minor note, it is not so easy to handle arguments that aren't used inside the function: https://github.com/tokio-rs/tracing/pull/1228#issuecomment-774549503.
From what I could gather, async-trait redefines the variable v with a let binding, but in the process of doing so, it introduces an unused variable.
If I'm not mistaken, the logic is the following:
a) async_trait rewrites the body of async fn call(&mut self, v: usize) {} in this fashion:
Box::pin(async move {
  let __ret: () = {
      let mut __self = self;
      let v = v;
  };
  #[allow(unreachable_code)]
  __ret
})

So far, it have the same behavior as an equivalent sync function would have, so the warning is expected, and thus not an issue.
b) instrument then rewrites the body as:
Box::pin(async move {
  XXX // something that uses the `v` variable
  tracing::Instrument::instrument(
      async move {
          {
              let __ret: () = {
                  let mut __self = self;
                  let v = v;
              };
              #[allow(unreachable_code)]
          __ret
        }
      },
      __tracing_attr_span,
    )
    .await
})

In that case, the v variable is now used by code originated from tracing, but there is still the let v = v; binding, which is still an unused variable. Because they have the same span, the compiler reports the error as originating from the function signature:
warning: unused variable: `v`
   --> tracing-attributes/tests/async_fn.rs:176:34
    |
176 |         async fn call(&mut self, v: usize) {}
    |                                  ^ help: if this is intentional, prefix it with an underscore: `_v`
    |
    = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

I'm not really sure about the way to go here. Optimally, we would inject instrument code after async-trait, but I don't think we can force ordering (or this whole story of async-trait/tracing integration would never have been a real deal) of procedural macros.
Any idea?

@nightmared, would it help if we insert some unique distinguishing marker like let __async_trait: (); in between the let statements and the user's original function body?
Box::pin(async move {
    let __ret: #RETURN = {
        let v = v;
        let __async_trait: ();
        #BODY
    };
    #[allow(unreachable_code)]
    __ret
})

You could crawl the macro input and replace that marker with:
Box::pin(async move {
    let __ret: #RETURN = {
        let v = v;
        if false {
            let _ = &(v + 5);  // expr from #[instrument(fields(test=%v+5))]
        }
        #BODY
    };
    #[allow(unreachable_code)]
    __ret
})

Hmm yes, i guess this would work! However that also means we would have to follow variable reassignments like self being renamed to __self. Given I'm not really the one that will bear the burden of maintaining that compatibility in the long run (not being a maintainer, nor even an active contributor :p), I guess the best is to defer that decision to e.g. @hawkw and/or @davidbarsky.
That being said, it would probably be the cleanest way to properly place the code generated by #[instrument], and solve this issue altogether. It's probably fairly easy too: we would just have to wrap all the statements from the position of __async_trait to the end of the block.

I have started to take a look at @dtolnay's solution, but it isn't quite as trivial as I first thought because we need to keep track of variable reassignments (e.g. let __self = self).

To propose a different solution: what if nothing is done about the warning? The warning feels correct to me: the variable is declared and never used in the function body by the written code. Purposefully silencing this warning could result in incorrect code that otherwise would have been caught. It's also easy enough to add an _ should they really intend not to use the variable.

That is a possibility yes. However with some very minimal changes in async-trait (https://github.com/nightmared/async-trait/commit/32b1573a9d237ad3b277f20645e85711c0838cd7) and a bit more work on tracing side, I was able to get this minor nitpick working ;)
We'll see what the maintainers of tracing think of this hack.

@dtolnay I'm continuing to work to improve async-trait in my local branch. When you're ready to merge this, let me know if you'd prefer squashing into fewer commits and/or multiple PRs.

I am getting rather odd build errors with a minimal project with commit 0cda89b somehow:
#[async_trait::async_trait]
pub trait Derp {
    async fn hi();
}

fails to build with internal errors, both latest stable and nightly. Note that I literally just have those 4 lines + a dummy main(): https://gist.github.com/Kiiyya/250dc864682cc1fc256f6ac6135db45e And I have no clue what is going on, but I thought I'd just drop this here in hopes it helps, somehow?
For some reason, using that exact same commit in a way bigger project of mine compiles, I am properly confused about that elusive build error.

@Kiiyya Your larger project is probably enabling features of syn that result in Debug being implemented on those types while async-trait doesn't enable such features. This is was an omission on my part ... to omit the Debug derive. I've pushed a commit that should resolve the issue! Thanks for testing.

Yep works now, that was quick, thank you!

I ended up landing this without the workaround for tracing-attributes because https://github.com/dtolnay/async-trait/pull/143#issuecomment-777964508 / https://github.com/dtolnay/async-trait/pull/143#discussion_r583208853 are compelling to me.


file not uploading getting error:

after pressing upload i am getting the following error
01-29 04:24:11.385 32115-32115/com.example.bikesh.webviewexample I/chromium: [INFO:CONSOLE(12)] "Not allowed to load local resource: file:///android_asset/webkit/android-weberror.png", source: data:text/html,chromewebdata (12)

Thanks for your question!
We need much more information in order to help, of course :)
What are you trying to do? What URL are you loading in the WebView? What Android version did you test this on?
Did you load a http://, https:// or file:/// URL? Can you tell us the URL?
What did you do next? Did you navigate to a specific page by clicking links inside the WebView?
When does the error occur, exactly? When you're trying to upload a file? What is the specific HTML form that you pressed the <input type="file"> control in? Where does the file come from that you're trying to upload?

Thanks for the quick response i fix it by using


Not working

I have a simple setup of this gem in a demo application:
# Gemfile

gem 'sidekiq'
gem 'sidekiq-cron'

# config/initializers/sidekiq.rb

Sidekiq::Cron::Job.load_from_hash YAML.load_file('config/schedule.yml') if Sidekiq.server?

# config/schedule.yml

CronWorker:
  cron: "* * * * *"

# app/jobs/cron_worker.rb

class CronWorker
  include Sidekiq::Worker

  def perform(*args)
    # Do something
    Rails.logger.info "Cron works! #{args.inspect}"
  end
end

The text "Cron works!" never appears in the logs, so the job is never processed...
Note that Sidekiq itself is processing the jobs properly and logs appear for the normal jobs (only cron jobs  don't work).
I don't see anything related in the logs, so I really don't know how to debug this. However you should be able to reproduce the issue using the code above.

After a lot of investigation, I have found that the job is processed properly if I use the following initializer (instead of the initializer reported in the original post):
# config/initializers/sidekiq.rb

Sidekiq::Cron::Job.create(name: 'CronWorker every min', cron: '* * * * *', class: 'CronWorker') if Sidekiq.server?

Basically Sidekiq::Cron::Job.load_from_hash fails silently without any errors or logs and it does not schedule the job.
Also note that adding Sidekiq::Cron::Job.create at the bottom of app/jobs/cron_worker.rb does not work: indeed that file is lazy loaded and if the job is not called from the outside, the file is never processed (you can even enter syntax errors and you won't get any logs / errors).

It seems that Sidekiq::Cron::Job.load_from_hash works if  I use the following:
# config/schedule.yml

my_first_job:
  cron: "* * * * *"
  class: "CronWorker"

I guess that this gem does not infer the class from the job name, and thus it was just ignoring the job because there was no class key...  In any case this is not correct and very dangerous (cron jobs are silently discarded): the gem should at least throw an error of the YAML config is not valid.
Related: https://github.com/ondrejbartas/sidekiq-cron/issues/243 (in my case the YAML is syntactically valid)

Keep open

Keep open

This stale bot is really annoying.... wouldn't it be better to actually fix issues or close them manually in a very small repo like this? Or maybe just increase the "stale" timeout to something more than 2 months?

Hey @collimarco 👋🏼, not really sure what's needed to be fixed here... Could you please try with latest version or prepare a reproducible script (a failing test or a demo app)?

@markets Thanks for the reply. The reproducible steps are described in the original post.

So your proposal, as per your last comment (https://github.com/ondrejbartas/sidekiq-cron/issues/251#issuecomment-502394626) is to raise for invalid arguments right?
We have this section describing the job arguments: https://github.com/ondrejbartas/sidekiq-cron#getting-started, under Job properties. But yeah, I agree, we should raise or warn for invalid arguments.


No cookieOptions in the index.d.ts file

The library support the cookieOptions parameter (thanks for that!) that does not have types in the index.d.ts file.

Would you like to create a PR?

I just created a PR.


Bump snowflake-sdk to 1.6.0

This PR is to bump snowflake-sdk to 1.6.0.
1.6.0 comes with new authenticator methods and supports External Browser SSO, Key Pair and OAuth to connect to snowflake.
Can you please bump the snowflake-sdk version and release a new package to npm? This package is great, used in sqltools-snowflake-driver and the bump would allow the SQL client to use further authentication methods to snowflake.

Is there anything else we need to do to support the new features? I don’t see any additional options documented on https://docs.snowflake.com/en/user-guide/nodejs-driver-use.html#additional-connection-options.


[FEATURE REQ] Add developer setting to generate API listings and update snippets on build

Everybody always forgets to run https://github.com/Azure/azure-sdk-for-net/blob/master/eng/Export-API.ps1 and https://github.com/Azure/azure-sdk-for-net/blob/master/eng/Update-Snippets.ps1 before they submit their PRs.  I've suggested git hooks as a workaround, but it would also be nice to add a setting that does both of these steps automatically when we build.  It could be defaulted to an env var like AZURE_DEV_BUILD_ARTIFACTS so interested parties could amortize the time spent updating PRs with API listings across every single build they do from here on out.

//fyi @pakrym @chidozieononiwu @annelo-msft @kasobol-msft @seanmcc-msft if you want to add any thoughts

Please add this.  It's really non-fun waiting for CI for 10 minutes, just to fail the analyze step over Export-API.ps1.

This might slow down inner dev loop (change-build-test) a lot.

This might slow down inner dev loop (change-build-test) a lot.

Yep - that's why I think we should make it optional.  We could also consider providing default implementations of commit hooks for people use, but I think mirroring what we do for ApiCompat on build already will be less difficult for folks to make use of this.

Would it be possible to have these scripts run in single csproj scope to speed up inner dev lopp?

Yes, but even then build time would be up at least 2x

Yes, but even then build time would be up at least 2x

"at least 2x" feels like a stretch from what I've seen.  These complete pretty quickly when you run them on single projects.

Huh.  I guess time just passes quicker when you get old and anything less than a minute feels fast enough.  :smile:

Fast enough for me. I'll take that instead of minutes of waiting at PR!

@chidozieononiwu git hooks aren't as reliable as we'd like to see for something like this, so let's implement the env var suggestion @tg-msft made AZURE_DEV_BUILD_ARTIFACTS.

I don't like git hooks as they are not reliable as has already been stated. I could get behind a msbuild property (i.e. dotnet build /p:UpdateSource=true) that people could pass to the build that would run these extra steps which would potentially modify the source in the repo.

Please see updated contributing docs for how to use these settings https://github.com/Azure/azure-sdk-for-net/blob/master/CONTRIBUTING.md#updating-source-on-build


I am planning to use some api if any and get files names

How to list installed packages?

Maybe store?

How to make info ?

I am planning to include some thing like # Package Name: <name>

In the sh files of each one , so we can just get first few lines somehow

Implemented list all and installed via GitHub API


"show-on-failure=true" always shows notification card

Since April 22, 2024, (or so) the show-on-failure=true setting no longer works correctly: A notification card is always shown, even if the job is successful.
As it turned out, step.completed_at is apparently no longer set to null for incomplete job steps. Instead, it is set to the start of the epoch (i.e. January 1, 1970, 00:00 UTC). Therefore, also check for step.status to ensure that only completed job steps are taken into account when determining the workflow run status.
Note that according to the REST API documentation, step.status is required to be present, and can only have the values "queued", "in_progress", or "completed". Of these, we are only interested in job steps in the "completed" state.

Thank you for the fix @bernhard-kabelka


feat(@schematics/angular): add no-redundant-jsdoc tslint rule

When building a library, tsickle is used as the annotateForClosureCompiler option is true. tsickle warns when redundant jsdocs are used.
https://github.com/angular/tsickle/blob/d24b139b71a3f86bf25d6eecf4d4dcdad3b379e4/src/jsdoc.ts#L170-L178
These diagnostics are later passed to Angular Compiler and are treated as errors.
Seeing this: https://github.com/angular/angular/issues/19969#issuecomment-343318361 it looks like it is expected that warnings will fail the build.
Closes: #11282

//cc @clydin

Looks good.  Features are blocked until the 6.2 window is open.

@clydin I think we can merge this one now.

@clydin can you tell if this PR is gonna be merged?


Failed to initialise TronWeb

Hi I get the following error when trying to interact with a webpage with TronLink:
[ERROR]: Failed to initialise TronWeb TypeError: Cannot read property 'filter' of undefined  at pageHook.js:44451
This is the line at pageHook.js:44451:
var c = phishingList.filter(function (_ref2) {
`

I think this is a TronLink issue. Open the issue at
https://github.com/TronLink/tronlink-extension/issues


Polyline from_trimmed_polyline and xy_crossings methods

Codecov Report
Base: 78.95% // Head: 78.91% // Decreases project coverage by -0.03% :warning:

Coverage data is based on head (aa8a773) compared to base (9bdb893).
Patch coverage: 12.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #573      +/-   ##
==========================================
- Coverage   78.95%   78.91%   -0.04%
==========================================
  Files         178      178
  Lines       29752    29739      -13
==========================================
- Hits        23490    23468      -22
- Misses       6262     6271       +9

Impacted Files
Coverage Δ

resqpy/lines/_polyline.py
85.71% <12.00%> (-4.53%)
:arrow_down:

resqpy/olio/simple_lines.py
40.16% <0.00%> (-0.49%)
:arrow_down:

resqpy/derived_model/_add_faults.py
91.58% <0.00%> (-0.47%)
:arrow_down:

resqpy/model/_forestry.py
78.74% <0.00%> (-0.22%)
:arrow_down:

resqpy/fault/_gcs_functions.py
62.86% <0.00%> (-0.14%)
:arrow_down:

resqpy/time_series/_from_nexus_summary.py
90.90% <0.00%> (-0.10%)
:arrow_down:

resqpy/grid_surface.py
75.79% <0.00%> (-0.10%)
:arrow_down:

resqpy/olio/factors.py
97.05% <0.00%> (-0.09%)
:arrow_down:

resqpy/olio/vdb.py
55.52% <0.00%> (-0.07%)
:arrow_down:

resqpy/well/well_utils.py
95.06% <0.00%> (-0.07%)
:arrow_down:

... and 17 more

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Payout Wallet Selector

As an owner of a corporate multisig, I need to be able to create collections easily from my EOA but set the payout wallet of a Collection' sales to the company's one.
unleash NFTs again, help publishing collectives.

in seaport orders you can set the recipient of the consideration items to any address, however opensea will enforce it being the "offerer" as part of order validation. if you are taking about creator fees, seaport doesn't have any built in, but in marketplaces like opensea you can set the payout address for a collection to any wallet in the settings of the collection. hope this answered your questions.


Make picture/srcset work

I can't find how to make picture/srcset feature to work with that plugin.
If I paste that code after switching to source editing:
<picture>
  <source srcset="https://interactive-examples.mdn.mozilla.net/media/cc0-images/surfer-240-200.jpg" media="(orientation: portrait)">

</picture>

it's not displayed in view mode and it's replaced by the following code (discovered with developed tools):

I've checked that same example on Full-featured editor and that's working.
I've tried overriding config with the following one (thinking maybe disallow or sanitizeHtml were the culprits), but that's still not working:
globalThis.CKEditorConfig = {
    configs:{
        toolbar:{
            editorConfig:{
              htmlSupport: {
                allow: [
                  {
                    name: /.*/,
                    attributes: true,
                    classes: true,
                    styles: true,
                  },
                ],
                disallow: [],
              },
              htmlEmbed: {
                sanitizeHtml: (inputHtml) => inputHtml
              }
            }
        },
    },
}

I've even tried upgrading to 37.0.0-alpha.0 version of CKEditor as I've found some work was done about that feature in that version, but still no success.
I suspect maybe ckeditor5-easy-image plugin is missing, but I have not bean able to test adding it as I can't find how to do that without having to create a fork of your plugin.

PR https://github.com/nshenderov/strapi-plugin-ckeditor/pull/83 should (partially?) fix this issue.
Indeed, above example code now displays the image in view mode.
Note that, in view mode, the rendered HTML is now the following (seen with developer tool):
<picture>

</picture>

While it displays the image, it's still replacing <source> tag with a  tag with a data-ck-unsafe-element attribute.
This behavior is not happening in Full-feature editor but I don't know why it's behaving differently...

It looks like removing GeneralHtmlSupport makes the source to display correctly.
The culprit is https://github.com/ckeditor/ckeditor5/blob/f59e00c5ea84100da9eec1d032e9957c3f642097/packages/ckeditor5-html-support/src/integrations/customelement.ts#L79 that automatically adds source in the unsafeElements (which is supposed to be a readonly attribute by the way...).
Note that for dependency reasons, Style also has to be removed.

@marob Hi, you can easily remove plugins you don't want for your project via configuration of the plugin. Also, the same is for adding plugins.

Hi @nshenderov.
Thanks for your answer.
I found 2 ways:

using ckeditor.txt, but it requires to override the entire list of plugins, I didn't find how to add/remove just one
using patch-package to "patch" base.js but it doesn't look like a good way to do it

Is there a better and easier way?
Also, do you think adding PictureEditing by default could be a possibility?


Get extensions working for the GUI

Currently, the gui is using just a bare engine without extensions. As a result, many features cannot be used. In particular, it's not possible to load either NUnit or VS projects.
Issue nunit/nunit#1133 deals with this problem on the engine side. We need to find a temporary workaround so that the work continues on the gui and then implement whatever changes are needed after nunit/nunit#1133 is fixed.

One workaround is to copy the entire addins directory from your nunit installation into the bin\Release or bin\Debug directory for the gui. This is a pretty cumbersome workaround but it did allow me to run extensions under the Gui.

dibs

???

I think i have an idea for this. it's based off of using the NuGet core package: example
Make a view and presenter and have it filter for our extensions only. On startup have it create a new background thread to check for updates or new extensions. Notify on updates or new packages.

I assigned this to myself because I intended it to be about the technical underpinnings of accessing extensions after they are installed. It probably involves changes to the engine as well as the nunit-gui projecxt. I think you are talking about adding some sort of interface that allows installing extensions, for which the backend work in the engine would be a pre-requisite.
If I'm understanding you correctly, I suggest creating another issue describing what you want people to be able to do and start working on it.
Specific question on your idea: What do you mean by "filter for our extensions only?"

in the example I tried showing (but messed up the link) the nuget people have the following code
string packageID = "EntityFramework";

//Connect to the official package repository
IPackageRepository repo = PackageRepositoryFactory.Default.CreateRepository("https://packages.nuget.org/api/v2");

//Get the list of all NuGet packages with ID 'EntityFramework'
List<IPackage> packages = repo.FindPackagesById(packageID).ToList();

//Filter the list of packages that are not Release (Stable) versions
packages = packages.Where (item => (item.IsReleaseVersion() == false)).ToList();

//Iterate through the list and print the full name of the pre-release packages to console
foreach (IPackage p in packages)
{
	Console.WriteLine(p.GetFullName());
}

I'm not sure if that would return other results besides Entity, but that would be researched at the time of implementation. Anywho the results of packages coudl be shown in the UI and the user could choose which extensions they wanted to have installed with their GUI (albeit it would be more for the engine than the gui itself)
Sorry about the misunderstanding of the issue and you assigning it. At my job the business person has his name on all the tickets until we pick it up and assign it to ourself, and I figured that's what happened here.

Extensions are now available using the chocolatey packages. See #205.


Old docs?

Problem or feature description
I am using v1.5.4 and I need to reference the old docs for Animate. I can see that the old Resonance site has been updated to be React-Move, but the Animate component has changed and I need to reference the old version. Is that kept anywhere?

https://github.com/react-tools/react-move#documentation


Better loading

Pull Request Test Coverage Report for Build 1738

23 of 28 (82.14%)  changed or added relevant lines in 3 files are covered.
166 unchanged lines in 10 files lost coverage.
Overall coverage decreased (-9.8%) to 84.134%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/browser/sifrr-dom/src/sifrr.dom.js
16
18
88.89%

packages/server/sifrr-server/src/server/baseapp.js
5
8
62.5%

Files with Coverage Reduction
New Missed Lines
%

packages/browser/sifrr-dom/src/dom/updateattribute.js
1
91.3%

packages/browser/sifrr-dom/src/utils/json.js
3
52.94%

packages/browser/sifrr-dom/src/dom/keyed.js
5
92.93%

packages/browser/sifrr-dom/src/dom/repeatref.js
7
25.0%

packages/browser/sifrr-dom/src/dom/creator.js
9
74.32%

packages/browser/sifrr-dom/src/dom/bindings.js
23
13.64%

packages/browser/sifrr-dom/src/dom/element.js
25
44.09%

packages/browser/sifrr-route/src/sifrr.route.js
26
53.93%

packages/browser/sifrr-dom/src/dom/update.js
30
34.78%

packages/browser/sifrr-dom/src/dom/makeequal.js
37
13.43%

Totals

Change from base Build 1732:
-9.8%

Covered Lines:
1453

Relevant Lines:
1727

💛  - Coveralls


Restore support links by default and only hide feedback requests

This restores the support links to the service. The intention was to not solicit feedback in the service as our trial will collect feedback offline - but we should still provide links to the support email in case something goes wrong.
Please check I've updated everything appropriately.

 Restore support email address to prod


Make use of draft service validation errors

After https://github.com/alphagov/digitalmarketplace-api/pull/297 validation errors will come back in API responses when getting a single draft service. This change makes use of them to decide whether or not to show the 'mark as complete' button. This is required because not all of the validation rules can be determined just by whether any required fields are unfilled.

Looks good once the other one is merged :+1:


Prune Unbond entries from global state when the queue for a validator is empty.

At the end of processing all unbond requests we should also prune value under Key::Unbond if length of queue reaches zero. Not doing it means we’ll keep a lot of entries with empty queues, and due to the design we’ll always iterate over empty queues when processing unbonding requests. Pruning also decreases time for fast-sync as it doesn’t need to go through effectively empty values. We’re introducing a new keyspace as part of 1.5 and with pruning we won’t end up with bloat if we do pruning. We should also prune Withdraw entries when copying data into Unbond keyspace.

Unassigning @alsrdn since @mpapierski is back.


[AMBARI-23223] Stack Mpack link broken in stacks api

Fixed the following issues:

/stacks//versions/ has mpack object empty
/mpacks// has version object empty
Remove stackname and stackversion from /mpacks/ API call
/stacks//versions/ has configuration object empty

(Please fill in changes proposed in this fix)
How was this patch tested?
GET http://{ambari_server}:8080/api/v1/stacks//versions/
GET http://{ambari_server}:8080/api/v1/mpacks/
Please review Ambari Contributing Guide before opening a pull request.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1174/
Test FAILed.
Test FAILured.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1202/
Test FAILed.
Test FAILured.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1208/
Test FAILed.
Test FAILured.


Introduce initial implementation

Hello @bterlson, @leobalter, @rwaldron, and @spectranaut. Here is my latest
attempt at the Node.js API for traversing Test262.
I've selected the BSD 3-Clause license in order to ensure compatibility with
test262-harness itself. Note that the licensee is Bocoup LLC because this is
almost entirely new work. One exception is the create-scenarios.js file,
which borrows heavily from a similar file in test262-harness. @bterlson is
this okay with you?
This module does not support file globbing. I think that kind of behavior is
much more high-level and best-provided by a CLI tool. Consumers of this module
who want more fine-grained filtering are free to do so by parsing the
test.file property of each "data" event.
Instead of re-implementing the prelude option as exposed by
test262-harness, I've extended the data model with a insertionIndex
property. Again, I thought this would be more fitting for a lower-level
utility. Instead of providing some static "prelude" string, consumers could
insert different content for each test.
I'd like to bring test262-compiler and test262-parser into this project.
Doing so would

Allow for a more natural mechanism for deriving the insertionIndex (notice
how hacky the current implementation is)
Simplify maintenance (fewer packages to update to get fixes/features into
test262-harness)
Enable an additional option: minimal. This would limit all test
modification to the bare minimum (as of today, just the insertion of a "use
strict" directive). This would be of interest to consumers using Test262 to
validate parsers because all the extra harness code injected into each test
only serves to make parsing take longer
Eliminate some noise in the source (see compile.js where the async,
isATest, and strictMode properties are removed)

To prove all of this out, I've made a demonstration branch of
test262-harness where this implementation has been swapped in to place:
https://github.com/bterlson/test262-harness/compare/master...jugglinmike:test-stream-2?w=1
All the tests pass on that branch.
This project is only the first step in the process. JavaScript parsers will be
able to use this module directly, but it's not really appropriate for projects
that need to execute the code. What I would like to do after this is define a
minimal Node.js API for test262-harness that lets consumers interact with
this stream. In that way, projects like Babel could perform transformations on
the source code and then go on to execute the result in an actual runtime.
Here's what I could use from you folks:

Do you think the design of this project is sound (especially the
considerations described above)?
Does the code itself look good to you?
Do my planned "next steps" seem reasonable?

Thanks!

To help validate the design a little more, I've re-implemented the Babylon
parser's test suite to use this module:
https://github.com/babel/babylon/compare/master...jugglinmike:test262-stream-2

Do you think the design of this project is sound (especially the considerations described above)?

yes, I've been using it already and it's great

Does the code itself look good to you?

Despite some indentation issues that I flagged above, it's really nice.

Do my planned "next steps" seem reasonable?

sure thing.

I've used this module to implement a "draft/sketch" of:

A tool to automatically detect features in test262 tests

This exposed the need for raw test file source

A test runner that does babel transforms on test262 test material before evaluating it in an agent


features: client generator expects singular objects

I was getting this error on my informer. Note FeatureList does not exist, and FeaturesList does. We need to redo the pluralization and update the go-client.
I0305 14:38:13.242898   22751 reflector.go:169] Listing and watching *v1.Features from github.com/openshift/client-go/config/informers/externalversions/factory.go:101
E0305 14:38:13.244280   22751 reflector.go:134] github.com/openshift/client-go/config/informers/externalversions/factory.go:101: Failed to list *v1.Features: no kind "FeatureList" is registered for version "config.openshift.io/v1" in scheme "github.com/openshift/client-go/c
onfig/clientset/versioned/scheme/register.go:14"

/cc @derekwaynecarr @deads2k

@rphillips are we sure this is the issue?
@deads2k not sure if this is how we want to fix it if it is.

@sjenning I'm pretty certain the generator works this way. We can force the pluralization constructs with a comment, but we should probably conform to the defaults.

/hold
No, we need a generator fix.  Maybe it didn't publish

i think we should adhere to the upstream convention for resource naming rather than special-case the code generator.  @deads2k what do you think?

Closing in favor of https://github.com/openshift/kubernetes-code-generator/pull/1


[Hub Generated] Review request for Microsoft.Security to add version stable/2019-08-01

If you are a MSFT employee you can view your work branch via this link.
Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run automation - sdk

@xccc-msft I believe the public.rest-api-specs (BreakingChange) gate failure is a false positive.
The latest version of the swagger results in an error when attempt to generate code using AutoRest.
The issue is that the ruleType field was defined both in CustomAlertRule (the base type) and AllowlistCustomAlertRule (deriving type). Also, it wasn't marked as a discriminator even though it behaved like one.
So the changes in the PR remove the duplicate definition of the property and declare it as a discriminator.
As far as I understand this change has no affect on the API itself, so there should be no reason to update the api-version.
Is that correct?

@NullMDR Can you please advise for the CIs?

@xccc-msft I believe the public.rest-api-specs (BreakingChange) gate failure is a false positive.
The latest version of the swagger results in an error when attempt to generate code using AutoRest.
The issue is that the ruleType field was defined both in CustomAlertRule (the base type) and AllowlistCustomAlertRule (deriving type). Also, it wasn't marked as a discriminator even though it behaved like one.
So the changes in the PR remove the duplicate definition of the property and declare it as a discriminator.
As far as I understand this change has no affect on the API itself, so there should be no reason to update the api-version.
Is that correct?

@jianyexi Could you please help on the breaking change detection in CI?

@NullMDR @jianyexi Hi, any updates on this PR?

@xccc-msft @NullMDR @jianyexi Hi, any updates on this PR?
seems make sense , currently we can go on reviewing , and ask @akning-ms to merge it  at last

Hi @liranc, Seems you are just fix duplicate RuleType issue in this PR. So removed ARM review request. agree it is not breaking change for api. but I am not sure for sdk. can you share me about what language sdk to be released for this PR? I may ask sdk owner to take a look.

Hi @liranc, Seems you are just fix duplicate RuleType issue in this PR. So removed ARM review request. agree it is not breaking change for api. but I am not sure for sdk. can you share me about what language sdk to be released for this PR? I may ask sdk owner to take a look.

@akning-ms The released SDK is C#. The generated code will look a bit different and possibly break existing code, but is this an issue since the NuGet is always published using a different version? (so only those who would upgrade to the new version will need to make these few adjustments).
Thanks!

approved, but @isra-fel for awareness .Net sdk


Supabase guide

#203  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @thisisgoldman and the rest of your teammates on  Graphite

Merge activity

Sep 3, 11:19 PM EDT: @thisisgoldman started a stack merge that includes this pull request via Graphite.


"fullscreen, 2" (ignore gaps)

Description
Intermediate mode for fullscreen that ignores gaps, but keeps bar(s).

Like fullscreen 1 +
master {
    no_gaps_when_only = 1 # single monocle, basically
}

dwindle {
    no_gaps_when_only = 1 # single monocle, basically
}

?
https://github.com/user-attachments/assets/f069b10a-b76f-44c6-8f48-1c38927c5a11

Not sure if I understand what you try to achieve. Try this:
Disable no_gaps_when_only and then use this binding:
bind = $mainMod, F, fullscreen, 1

and these rules:
workspace=f[0],rounding:false,bordersize:0,gapsout:0
workspace=f[1],rounding:false,bordersize:0,gapsout:0

might get what

Good idea!
$HGAP = 200
workspace = r[1-10] w[t1] f[-1], gapsout:0 $HGAP 0 $HGAP
workspace = r[1-10] w[g1] f[-1], gapsout:0 $HGAP 0 $HGAP
workspace = r[1-10] w[t1] f[1], gapsout:0 0 0 0
workspace = r[1-10] w[g1] f[1], gapsout:0 0 0 0
windowrulev2 = noborder, fullscreen:1

Now single tiles are contained, and I can maximize them dropping borders. I guess the initial request is is fulfilled with this construct. Downsides are: no floating windows while maximized, have to unmaximize to see any new windows.
Per-workspace dispatcher variant of no_gaps_when_only would be great.


DCD support?

Just noticed this project, very exciting!
Is there intent to support DCD for autocomplete and co?

Actually there could be options for anything.... I will look into them. You are also free to fork and add any features. I will be glad to add them :+1:

@TurkeyMan I have just noticed DCD. Was looking for something like this. :+1:

Yeah, DCD is probably already installed and running on D developers pc's. It would be really cool if that worked.
I'm surprised there are no GDB plugins appeared yet. I expect debugging would be able to be a separate debugging plugin.

@TurkeyMan I have started investigating on how to add DCD support. I will take as inspiration the atomize-d plugin for atom and this seems to be quite easy. Thanks for your suggestion.

Awesome news, Looking forward to it! Thanks for your work :)

@TurkeyMan you can check out #2 if you need it immediately. I want to merge it surely.

@TurkeyMan if you clone the master branch you can help us testing the support for DCD and DFMT that we have included.


WinAppDriver Only Finding Title Bar in Window

Seeing a problem where WinAppDriver only sees the title bar on a private app. All elements (buttons, input boxes) are selectable using inspect.exe.
wdio conf file capabilities
"ms:experimental-webdriver": true,
"ms:waitForAppLaunch": 3

The window source logged
 <?xml version="1.0" encoding="utf-16"?><Window AcceleratorKey="" AutomationId="" ClassName="ThunderRT6FormDC" FrameworkId="Win32" HasKeyboardFocus="False" IsContentElement="True" IsControlElement="True" IsEnabled="True" IsKeyboardFocusable="True" IsOffscreen="False" IsPassword="False" IsRequiredForForm="False" ItemStatus="" ItemType="" LocalizedControlType="window" Name="REDACTED" Orientation="None" ProcessId="19400" RuntimeId="42.396646" x="0" y="0" width="419" height="401" CanMaximize="False" CanMinimize="False" IsModal="False" WindowVisualState="Normal" WindowInteractionState="ReadyForUserInteraction" IsTopmost="False" CanRotate="False" CanResize="False" CanMove="True" IsAvailable="True">

<TitleBar AcceleratorKey="" AutomationId="" ClassName="" FrameworkId="" HasKeyboardFocus="False" IsContentElement="False" IsControlElement="True" IsEnabled="True" IsKeyboardFocusable="True" IsOffscreen="False" IsPassword="False" IsRequiredForForm="False" ItemStatus="" ItemType="" LocalizedControlType="title bar" Orientation="None" ProcessId="19400" RuntimeId="42.396646.3.-2147483647.396646.-2.0" x="1" y="8" width="417" height="23" />

// more elements should be here

</Window>

Any ideas?

Automation properties are not implemented for the controls. That is the reason you get automation ID as null.

Automation properties are not implemented for the controls. That is the reason you get automation ID as null.

They all have automation id's when using inspect.exe.

Can you share what is shown in inspect

@anunay1 Window is a bit cropped as it's a private app.

Did you figure out the issue on this?

I have the same problem, anyone figured this out? I also tried to use Appium Inspector and Title Bar is all it can see. But I can see the elements in Windows Inspect...

I have the same problem, anyone figured this out? I also tried to use Appium Inspector and Title Bar is all it can see. But I can see the elements in Windows Inspect...

What kind of application is it? Win32, wpf or UWP.

Hello, I figured it out. My app is WPF application. I use Appium server the same way as described here https://github.com/microsoft/WinAppDriver/issues/1692#issuecomment-1066565875, because I had the same problem as in the thread and I could not downgrade Selenium. I saw only title bar in Appium inspector, but what helped was running Appium inspector as administrator. Then I could see all the elements in my app. And similarly, running Appium server as admin, then my test works again (only Actions do not work, for example right click, but I think that is already known issue https://github.com/appium/appium/issues/16268).

Hello, I figured it out. My app is WPF application. I use Appium server the same way as described here https://github.com/microsoft/WinAppDriver/issues/1692#issuecomment-1066565875, because I had the same problem as in the thread and I could not downgrade Selenium. I saw only title bar in Appium inspector, but what helped was running Appium inspector as administrator. Then I could see all the elements in my app. And similarly, running Appium server as admin, then my test works again (only Actions do not work, for example right click, but I think that is already known issue https://github.com/appium/appium/issues/16268).

Hello, I figured it out. My app is WPF application. I use Appium server the same way as described here https://github.com/microsoft/WinAppDriver/issues/1692#issuecomment-1066565875, because I had the same problem as in the thread and I could not downgrade Selenium. I saw only title bar in Appium inspector, but what helped was running Appium inspector as administrator. Then I could see all the elements in my app. And similarly, running Appium server as admin, then my test works again (only Actions do not work, for example right click, but I think that is already known issue https://github.com/appium/appium/issues/16268).

I would prefer to use inspect.exe.

Well it was weird but inspect.exe showed the elements somehow. But only when focus was on them. When I tried to click in the tree of elements, the element was there but its properties were unavailable (aside from title bar). So that was confusing.


MacVim changes default application on installation

Not sure whether it's caused by MacVim, but when I install it via dmg (copy the app folder within dmg to /Applications/) it changes the default application for shell, python, etc., all to MacVim. Before installation, I opened shell using TextEdit and opened python using Sublime Text. Thanks.
macOS version: 10.14.3
MacVim version: 8.1.950 (155)

This looks like a standard way of OS X to handle default apps in general. I don't see any specific logic in Info.plist or anywhere else forcing it to be default editor.
Please, correct me  if I'm wrong.

Thanks for your reply. I recently reinstalled MacVim and this time it did not change the default app. Thus I'm closing this issue.


OutpathBuilder - support (short-)hashes of parameters when building path.

Feature Idea
On A1111-ism I preferred was the ability to build the output path using the shorthash of the prompt/negative prompt/model/etc. This provided a less messy output in some cases. Consider supporting, minimally hashes of the prompt/negative prompt as well as the AutoV3 hash of the primary model in addition to the strings/names.
E.g. my A1111 style paths would, among other parameters, include both the hash of the model and the model filename, but only the hashes of the prompts,
For prompts, many prompts share a significantly long identical preamble and it becomes difficult using the path semantics to bucket them precisely without the hashes.
Other
No response

whaat the heck is a prompt hash

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Features#filenames-format
CW: python excerpts :P
https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/82a973c04367123ae98bd9abdf80d9eda9b910e2/modules/images.py#L400
...
class FilenameGenerator:
    replacements = {
...
        'prompt_hash': lambda self, *args: self.string_hash(self.prompt, *args),
        'negative_prompt_hash': lambda self, *args: self.string_hash(self.p.negative_prompt, *args),
        'full_prompt_hash': lambda self, *args: self.string_hash(f"{self.p.prompt} {self.p.negative_prompt}", *args),  # a space in between to create a unique string
...

    def string_hash(self, text, *args):
        length = int(args[0]) if (args and args[0] != "") else 8
        return hashlib.sha256(text.encode()).hexdigest()[0:length]
...

... so literally a sha256 of random parameter text? that sounds horrible ow

Just the first 8 characters of the sha256 of each of the prompt text(s).

That is an extremely silly feature, but, eh, there ya go


sparkml gets hadoop conf from session state

Upstream SPARK-XXXXX ticket and PR link (if not applicable, explain)
What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)
Please review http://spark.apache.org/contributing.html before opening a pull request.

Thanks for your interest in palantir/spark, @helenyugithub! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Closing in favor of https://github.com/palantir/spark/pull/599


Add --libs-only-L to pkg-config

so we get -L/usr/loca/lib and actually build

I'm having trouble building as well. This looks like it would help.

Released in 2.1.1. @clkao @bcomnes could you check if it works now?

Woot!  Works.

:rocket:


Release 0.6.8

Issue #175 Invalid ingress resources on Kubernetes clusters > 1.18
During resoluton of issue #170 providing support for ingress apiVersion v1,
the necessary ingress yaml fields wearn't updated to relfect that new version.
This is a fix.  The backend definition of the Ingress will now reflect the proper
definition based on a v1 or v1beta1 apiVersion.
Example: If KubeVersion > 1.18
          service:
            name: https
            port:
              number: 443

Example: If KubeVersion <= 1.18
          serviceName: https
          servicePort: 443

Additionally, adding the pathType for all versions as it is now required in
ingress v1.

ok that lint check failed, as this is to create a new release 0.6.8 that I had to backout.


Add "disconnected" event on DTLS shutdown at Transport

great feature,  sometimes  we can not depend on signaling

Is it worth/easy to add establishing/established also?

done, please test it and let me know if there is any issue

On 0.64.0 I get a compile error. Fixed versions 0.64.1 -> 0.64.3 but on run I get an error:
`
dyld: lazy symbol binding failed: Symbol not found: _HMAC_CTX_init
Referenced from: /Users/dave/IdeaProjects/streaming-sfu/node_modules/medooze-media-server/build/Release/medooze-media-server.node
Expected in: flat namespace
dyld: Symbol not found: _HMAC_CTX_init
Referenced from: /Users/dave/IdeaProjects/streaming-sfu/node_modules/medooze-media-server/build/Release/medooze-media-server.node
Expected in: flat namespace
`

can you open a new issue, please?
Also, could you check if you have upgraded node in the meanwhile? I think they have upgraded bundled openssl versions and that may be causing some issues

Urgh sorry - my bad. You were right, I had mismatched node versions. Running now and testing.

I'm seeing connected and closed events. I haven't seen any connecting or failed (not sure in which scenarios they would occur).
If I hang the connection (client doesn't tell us they are going away) I never get the closed event. I presume this is expected and related to #43.

I think that new and connecting are "fired" before the transport obejct is returned, so you will be able to the the state from the object, but not the event. I don't expect to see any failure normally.

In that case I believe all is working as expected from my side :)


vertical (column) header?

Hello,
Is it possible to have implementation for a column header? I have one big dashboard table where my first column is the date and i want to have it always visible.
Best Regards

no


hubToken success verification withdraw

To allow users to withdraw without needing balanced to pay for the request the hubtoken needs to use the withdraw xCall with success verification to release tokens.
xWithdraw(
String _from, // user address as string
BigInteger _amount // amount to withdraw
)
Store Sn for message sent and add extra function to claim funds. this functions checks a sn against xCall then removes it.  Or if possible modify balance function and claim pending onces on transfers.
In the rollback case associate it with an ID and the clear up the pending withdraw in case of failure.

Not doing this for now to keep frontend complexity low


Pressing "End" button while MPV is playing stops MPV playback.

I'm not sure if this is TT9 or MPV. Pressing End while MPV is playing stops playback before going to the home screen. Switching apps and then pressing end does not end playback. Pressing End while phonograph is playing does not end playback on phonograph though, so I'm checking here first.

I am sorry, I have no idea what you are saying. What is this "End" button you are referring to?
Android does support the "End" key of computer keyboards, but I really doubt you have connected one to your phone/tablet/whatever. Besides TT9 does not handle it in a special way, it just passes it through and lets the current application decide what to do.
Or do the mentioned applications have their own "End" key, in the UI (I haven't used them, so I have no idea)? If so, the key response is entirely up to the application. Pressing it does not even make it to TT9.

My bad. Its the "End Call" key, which on my device doubles as a "Home" button and is also the Power Button.

Oh, I see. TT9 ignores that key. It is up to the players what to do when it is pressed.

Thank you, with that information I'll open the issue up on the MPV github page.


Update software naming and Depends/Provides info after review.

Explain what Depends and Provides are in Overview/Artifact chapter.

Adjust description of Artifact names vs software versions.

Use different versioning schemes for rootfs and application examples
to make it easier to visually distinguish the two.

Provide examples for how to see the version information after the
Artifact has been installed. This is still missing screenshots; I
have marked them TODO for now.

Changed "myfs" to "data-partition" to match what is in the
preliminary UI Design (this is not enforced in any way, so it's just
to reduce confusion, both labels are technically correct).

Provide one example for what happens when you have an application on
the root filesystem and you install a rootfs update.

Remove '$' from shell examples so that the copy button works
properly.

At the time of writing, the source for the diagrams can be found in
Northern.tech's Engineering folder:
https://drive.google.com/drive/folders/0B6EXyILUYX54TWR5THZVbUZNR3M
Signed-off-by: Kristian Amlie<EMAIL_ADDRESS>

If this is approved I will create a task to fix the TODOs.

The only risk is that it becomes a little too much to understand for a first-time user of it. They probably just want to get to the command of how to set the version (and name) of the software and how it's reported/shown/used in Mender.

Yes, this is true. But it's hard to trim it down much further without omitting important information about how it works. We could perhaps move the "Advanced usage" header into its own sub-chapter though. Do you think that would help?
Additionally, this is meant as a complete description, but maybe we can add a more trimmed down version somewhere else? How about adding the three arguments to the creation commands in the "Create an Artifact" chapter. We can very briefly describe what they mean, and that they will be reported in the UI, but nothing more. No mechanics or screenshots, just links to read more in this chapter.

We could perhaps move the "Advanced usage" header into its own sub-chapter though. Do you think that would help?

I think this is good.  I also think we should consider having some tutorials documenting specific situations that are likely to be common.  A tutorial could be less formal, ignore irrelevant details for the specific use case, and likely save on support issues.

The only risk is that it becomes a little too much to understand for a first-time user of it. They probably just want to get to the command of how to set the version (and name) of the software and how it's reported/shown/used in Mender.

Yes, this is true. But it's hard to trim it down much further without omitting important information about how it works. We could perhaps move the "Advanced usage" header into its own sub-chapter though. Do you think that would help?

I think maybe it would be trying to cover too much. After thinking a bit more, I think it is best to leave this as an "expert" reference - not for beginners.

Additionally, this is meant as a complete description, but maybe we can add a more trimmed down version somewhere else? How about adding the three arguments to the creation commands in the "Create an Artifact" chapter. We can very briefly describe what they mean, and that they will be reported in the UI, but nothing more. No mechanics or screenshots, just links to read more in this chapter.

Yes, that's a great idea! The Create an Artifact documentation is for beginners, so it would fit very well there.

I moved the Clears Provides documentation into a sub chapter, since it is very advanced, and provided a minimal set of options and a description in the "Create-an-Artifact" section. Only the two latest commits are new. @estenberg: Final ack?

I think this is good. I also think we should consider having some tutorials documenting specific situations that are likely to be common. A tutorial could be less formal, ignore irrelevant details for the specific use case, and likely save on support issues.

Yep! Actually, I think that the "Create-an-Artifact" chapter now serves as the two base use cases. Take a look.
More use cases could also be added, but I think I'll stop here to avoid exploding this task too much. I guess as we see people use this, we will become more aware of what the typical use cases are and where the pain points are.


Enable dism_features script for other languages windows

When you run this script for other languages windows the enable/disable detection didn't work. The /English parameter corrects the problem.
Signed-off-by: Daniel Masarin<EMAIL_ADDRESS>Description
Enable the dism_feature.rb script to run on machine in other languages than english
Check List

[ ] All tests pass. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/TESTING.MD
[x] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable
[x] All commits have been signed for the Developer Certificate of Origin. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/CONTRIBUTING.MD

Tests was realized in Windows 10 x64. I can't test on other systems because I don't have the licenses.

Thanks for the fix


Missing a regression test for a bug

A high priority bug #31792 is closed by reverting a commit, without adding a regression test. Issues should be kept open until regression tests are added.

#31848 has it, fret not.


Re sync fix

Issue: https://github.com/rancher/rancher/issues/46327
Problem

We are generating too many secrets for accessing the downstream cluster, because we are doing this concurrently.
Solution

This adds a mutex per service-account, which will reduce the number of secrets created, but not totally eliminate the problem.
Testing

Engineering Testing
Manual Testing

Automated Testing

Test types added/modified:

Unit
Integration (Go Framework)
Integration (v2prov Framework)
Validation (Go Framework)
Other - Explain: EXPLAIN
None
REMOVE NOT APPLICABLE BULLET POINTS ABOVE

If "None" - Reason: EXPLAIN THE REASON

If "None" - GH Issue/PR: LINK TO GH ISSUE/PR TO ADD TESTS

Summary: TODO
QA Testing Considerations

Regressions Considerations

TODO
Existing / newly added automated tests that provide evidence there are no regressions:

TODO

@jakefhyde , @MbolotSuse: noob question, are you aware of the reasons why we use a generated name instead of a fixed name (depending on the service account)?
https://github.com/rancher/rancher/blob/cfcdd8816eb38f18995696299a98082edcee837d/pkg/serviceaccounttoken/secret.go#L119
From my naive perspective the whole problem here is we are generating too many secrets, where only one should exist (per serviceaccount). Concurrent requests should turn into no-op if the secret exists already.
Am I missing any relevant aspects?

@moio answered offline.

#44347


angular-in-memory-web-api

@johnpapa fyi, I got hung up on the subject dependency for a while. It doesn't appear to be included in the latest version of Node, so doesn't get scaffolded by Angular CLI. Webpack fails to compile when it hits app.module.ts line 6, and the tutorial breaks.
Suggest adding a note/step to the official tutorial to perform a manual npm install of angular-in-memory-web-api to the tour of heroes, node_modules directory created by Angular CLI.

NM - found it in

Appendix: Tour of Heroes in-memory web api


Ensure clients are removed from the list before removing them

Yes. I have setup Redis HA and whenever Redis failover happens, sensu-api crashes. Though sensu-server is able to reconnect to the redis-master.
I am running sensu version 0.19.1
Seems this issue is open since couple of years and the maintenance team should look into this more seriously.
Regards,
Sagar


/bin/alloy: Operation not permitted in Render.com

What's wrong?
When deploying to Render as a private service, Alloy doesn't start and crashes with an obscure message.
root@<host>:~# /bin/alloy
bash: /bin/alloy: Operation not permitted

I debugged the service to try to find more without success:
root@<host>:~# strace -f /bin/alloy
execve("/bin/alloy", ["/bin/alloy"], 0x7ffdec45b6c8 /* 40 vars */) = -1 EPERM (Operation not permitted)
strace: exec: Operation not permitted
+++ exited with 1 +++

I also opened a post at Render.
Steps to reproduce
Deploy Grafana Alloy to Render.com using the next Dockerfile
# syntax = docker/dockerfile:1.2
FROM grafana/alloy:latest
ENTRYPOINT ["/bin/alloy"]
CMD ["run", "--server.http.listen-addr=<IP_ADDRESS>:12345", "/etc/alloy/config.alloy"]

System information
Linux 5.15.0-1052-aws #57-Ubuntu SMP Mon Jan 15 15:24:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Software version
v1.0.0
Configuration
No response
Logs
No response

Thanks for reporting. This sounds like something specific to Render, since I can't reproduce locally. Can you share more about Render's operating environment that would maybe clue us in to what might be going wrong here? (Such as security settings?)

I don't find relevant information, but I know that they provide instances on top of AWS. If they reply, I will pass the information here.
Meanwhile, I will try to deploy it from the source code :+1:

I have successfully deployed Alloy by:

Forking the project and deploy a Golang service from source
Attaching a Disk

Looks like Alloy (differently than Agent) expects to write to disk. Is there an option to disable it?
https://community.render.com/t/unable-to-deploy-grafana-alloy/20716/3?u=aleixmorgadas

Which are the directories that Alloy uses to write files into? I think the issue is that it uses more than one directory like the one passed as parameter --storage.path=/var/lib/alloy/data but other ones.

Which are the directories that Alloy uses to write files into? I think the issue is that it uses more than one directory like the one passed as parameter --storage.path=/var/lib/alloy/data but other ones.

--storage.path should be the only folder Alloy writes into directly; if it's trying to write to other folders by default that's a bug. (The default value for --storage.path is data-alloy/ and unfortunately on-disk storage can't be disabled right now, but can be set to a tmpfs mount).

Not sure if it's related, but I had the above error when running Alloy with a securityContext dropping all capabilities. I had to add the following capabilities to make it work:
      securityContext:
        ...
        capabilities:
          drop:
          - ALL
          add:
          - CHOWN
          - DAC_OVERRIDE
          - FOWNER
          - FSETID
          - KILL
          - SETGID
          - SETUID
          - SETPCAP
          - NET_BIND_SERVICE
          - NET_RAW
          - SYS_CHROOT
          - MKNOD
          - AUDIT_WRITE
          - SETFCAP
          ...

After #726, I think alloy will run with all capabilties dropped.


Custom share button only allows 1 class

Thanks for developing this - it is really helpful.  I found an issue that is not a show-stopper, but I would like to correct:
There does not appear to be a way to pass in more than 1 class into a custom share button. For example here is a custom method I've written:
getTwitterButton(): ShareButton {
let twitterButton = new ShareButton(
ShareProvider.TWITTER,
" Tweet",
'btn btn-primary'
);
return twitterButton;
}
This throws an error:
inline template:17:4 caused by: Failed to execute 'add' on 'DOMTokenList': The token provided ('btn btn-primary') contains HTML space characters, which are not valid in tokens
if I just put 'btn' it works fine.
How do I pass in multiple classes?

Hi @stevewarsa, Thanks for opening the issue, I will fix this and let you know when it's updated

Changes are merged and pushed to npm 1.0.7

Thanks, I'll check it out...


fix(app): fix logo padding with MUI v5 makeStyles

Small change to fix the logo position after we updated the app to MUI v5 (long time ago):
Before:

After:

/cc @ciiay @divyanshiGupta

Tested it , it working fine
[

]
/lgtm


bug in arp_helper

This recent commit  breaks arp_helper
because  the use_port_mac argument has been removed form ARPHelper.init(), but
at line  237 the corresponding member variable / attribute is still referenced.
Thanks

Thanks for reminding. We will fix it later.

Hah, well, the commit message warns it may break code, but I don't think that was what I meant. ;)  It looks like I just forgot to finish it.  I don't have time to test at the moment, but here's a quick pass at fixing it.  If it seems to work for you, I'll just push it.  Otherwise, I can take another crack at it later.

Yes, that code fixes the problem for our very simple test-case.  Thank you.

Fixed in eel and fangtooth.  Thanks for the report and test!

Thanks again.
(Does fangtooth mean that you happened to find time to work on pox once again?  That would be really great news.)

Yeah, POX has been factoring into work again, so it has been getting some attention.  My focus hasn't been OpenFlow type stuff, but even that has been getting some work.  RIP-on-OVS, OVS bundle action, improvements to discovery, a new and much-improved OpenFlow spanning tree component (spanning_forrest), and the little discovery graph, for example.  But I think the mass of stuff is probably not directly OpenFlow-related... GRE, VXLAN, IGMPv3 support in the packet library... config files... lots of improvements/additions to the DHCP and ARP stuff in pox/proto/... a bunch of stuff for working with Linux network interfaces including a revent-based capture API... lots of little fixes and improvements here and there.  (Indeed, some of that stuff is actually about making it useful in non-OpenFlow contexts, e.g., the DHCP client code.)
It's still living in my (public) fork, but I'm planning to shift it over to noxrepo one of these days.
In the slightly longer term, I'm planning to finally mainline the ovsdb support I wrote and the edge apps that @garyachy and I worked on a few years ago (oof), though that probably all needs to be tested against modern OVS first, so it might be a while before I get to it.


YAML formatting in Canada-bot pull requests

When using the form to update the data, the YAML format is still updated for some fields that were not modified.  Example #629
Can we update all YAML to match the format used by Canada-bot?

Recent test: #650

@smellems, It must be the same issue we faced before with PRB0T's fork not having fetched the latest commits. We need to manually delete its fork to force it to update to the most recent changes.

Related to #171


使用 flutter run -d linux 出现了下面的问题

使用 flutter run -d linux 出现了下面的问题
Launching lib/main.dart on Linux in debug mode...
CMake Error: The source directory "/home/mi/hello/build/linux/debug" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
Exception: Unable to generate build files
过程：
1, mkdir hello && cd hello
2, flutter create . && flutter pub get
3, flutter  run -d linux
flutter version:
[✓] Flutter (Channel master, 1.19.0-2.0.pre.83, on Linux, locale zh_CN.UTF-8)
• Flutter version 1.19.0-2.0.pre.83 at /home/mi/flutter
• Framework revision 8abf0a6d8c (5 小时前), 2020-05-16 15:07:34 -0700
• Engine revision aaf9e79f1d
• Dart version 2.9.0 (build 2.9.0-9.0.dev<PHONE_NUMBER>)
• Pub download mirror https://pub.flutter-io.cn
• Flutter download mirror https://storage.flutter-io.cn
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
• Android SDK at /home/mi/Android/Sdk
• Platform android-29, build-tools 29.0.3
• Java binary at: /home/mi/android-studio/jre/bin/java
• Java version OpenJDK Runtime Environment (build
1.8.0_212-release-1586-b4-5784211)
• All Android licenses accepted.
[✓] Linux toolchain - develop for Linux desktop
• clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
• cmake version 3.10.2
• ninja version 1.8.2
[✓] Android Studio (version 3.6)
• Android Studio at /home/mi/android-studio
• Flutter plugin version 45.1.1
• Dart plugin version 192.7761
• Java version OpenJDK Runtime Environment (build
1.8.0_212-release-1586-b4-5784211)
[✓] VS Code (version 1.45.0)
• VS Code at /usr/share/code
• Flutter extension version 3.10.1
[✓] Proxy Configuration
• HTTP_PROXY is set
• NO_PROXY is localhost,<IP_ADDRESS>/8,::1,<IP_ADDRESS>
• NO_PROXY contains <IP_ADDRESS>
• NO_PROXY contains localhost
[✓] Connected device (1 available)
• Linux • Linux • linux-x64 • Linux
• No issues found!

Apparently the -S/-B form of the command I used is not available in 3.10; I was looking at older docs when checking file format details, but didn't check the command invocation syntax. I'll need to switch it to making the build dir and setting that as the working directory.


Scope ist lost on CTRL+C

Hallo,
I am currently facing a weird situation with a container using the AsyncExecutionFlowScopeContext. I have tracked down my issue to the following small example:
using System;
using System.Threading;
using System.Threading.Tasks;
using DryIoc;

IContainer container = new Container(scopeContext: new AsyncExecutionFlowScopeContext());

CancellationTokenSource cts = new();

using (IResolverContext scope = container.OpenScope("MyScope", trackInParent: true))
{
    Console.CancelKeyPress += (sender, args) =>
    {
        Console.WriteLine("Canceling");
        Console.WriteLine(scope.CurrentScope?.ToString() ?? "No scope");

        cts.Cancel();
        args.Cancel = true;
    };

    while (!cts.IsCancellationRequested)
    {
        Console.WriteLine(scope.CurrentScope.ToString());

        await Task.Delay(1000).ConfigureAwait(false);
    }
}

Console.WriteLine("Scope disposed");

While the application is running it prints out
{Name=MyScope}
{Name=MyScope}
...
as expected. But when I now hit CTRL+C the following output comes
Canceling
No scope
Scope disposed
I would have expected the scope to stay as long the using block was not left.
Is this a bug or am I doing something wrong here?

I have created a custom (very simple) implementation of IScopeContext that solves my problem:
internal sealed class ScopeContext : IScopeContext
{
    private static IScope scope;

    public IScope GetCurrentOrDefault() => scope;

    public IScope SetCurrent(SetCurrentScopeHandler changeCurrentScope) => scope = changeCurrentScope(GetCurrentOrDefault());

    public void Dispose()
    {
    }
}

@WolfBublitz Interesting.. It probably relates to the behavior of AsyncLocal in your case.
I am glad that you went on implementing you context. At least having the interface payed it bill here.

Yes the interface saved my day ;-).

@WolfBublitz, Hi here
AsyncExecutionFlowScopeContext is supposed to flow the current scope across the await call boundaries, e.g. in the case of web request int ASP.NET. So the scope is preserved ain a new a possibly new pooled thread after calling the
await Task.Delay(1000).ConfigureAwait(false);
The cancel event however happens in the initial thread and this thread doesn't have the scope anymore, it was moved to the new thread with async/await flow. That's why you see the "No scope" output.
So if you want a static scope context to make scope shared between all threads, then you did right by introducing your own IScopeContext with the static IScope scope.


fix(package.json): added webpack.

:tada: This PR is included in version 1.8.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update issue templates

Is your feature request related to a problem? Please describe.
Issue templates and github settings in this repo are outdated.
Describe the solution you'd like
Update the repo's ISSUE TEMPLATES to the new standard as set by the generator.

update:   .github/ISSUE_TEMPLATE/bug_report.md
update:   .github/ISSUE_TEMPLATE/feature_request.md
update:   .github/ISSUE_TEMPLATE/general-support.md
update:   .github/settings.yml
delete:    .github/ISSUE_TEMPLATE/develop-design-story.md
delete:    .github/ISSUE_TEMPLATE/audit.md
delete:    .github/ISSUE_TEMPLATE/new_wc.md
delete:    .github/ISSUE_TEMPLATE/parent-design-story.md
delete:    .github/ISSUE_TEMPLATE/review-design-story.md
delete:    .github/ISSUE_TEMPLATE/symbol-design-story.md
delete:    .github/ISSUE_TEMPLATE/user-story.md

Exit criteria
This issue can be closed once the issue templates match the content from the generator repo.

This issue was copied from #38 by @blackfalcon.

/duplicate