Commutative multiplication and addition

I was surprised to learn that the implementation of core::ops::{Add, Mul} (keywords: addition, multiplication) is not automatically (and exclusively) commutative. This is often not a problem for cases where it is possible to both impl Mul<X> for Y and impl Mul<Y> for X, but this is not an option when generics are involved.
For example, this implementation of Mul allows multiplying Size by any basic number type (from num_traits), as in Size(12) * 2 or Size(42) * 1.0:
impl<T, U> Mul<U> for &Size<T>
where
    T: ToPrimitive,
    U: ToPrimitive
{
    type Output = Size<u64>;

    fn mul(self, other: U) -> Self::Output {
        // omitted
    }
}

but it is not possible to define an ergonomic and efficient inverse to support the commutative variant of the same operations (2 * Size(12) or 3.0 * Size(7)), because the following is illegal:
impl<T> Mul<Size<T>> for ToPrimitive
where
    T: ToPrimitive,
{
    type Output = Size<u64>;

    fn mul(self, other: Size<T>) -> Self::Output {
        Size::Bytes((self as u64 * other.bytes()) as u64)
    }
}

as the self parameter to the mul function results in an attempt to define a non-generic parameter with unknown size.
I would like to use this issue to sound out ideas to support commutative operations, at the very least for operations that are typically (read: mathematically) commutative, but would appreciate any insight or commentary that sheds light on anything I'm missing here first.

I kind of got lost drafting the post, I think the point that I was trying to make is that no matter which way you approach it, it's not going to work due to language/design constraints. Your example would work great if ToPrimitive were defined in the same crate, but not in the case where it isn't.
I guess my real question is if there is (as a thought experiment) an alternative way that select operators could be implemented that wouldn't end up running into the restrictions on trait implementations.

I believe  #2451  explains why everything works fine.

I would like to use this issue to sound out ideas to support commutative operations, at the very least for operations that are typically (read: mathematically) commutative,

Two words: Matrix multiplication.

Eight more words: string concatenation in the standard library, no less.

But more in the spirit of the thread, I think the closest one can get to making something like this work is by using a proc-macro to implement a DSL; You can replace all + and * operations in an expression with calls to a different trait that is implemented symmetrically for the types in a crate.
Alternative two: A newtype can be used:
pub struct Scale<T>(pub T);

impl Mul<MyType<U>> for Scale<T>
where MyType<U>: Mul<Scale<T>> {
    ...
}

This second alternative scales just a bit better for cross-crate usage, but unfortunately I'm not certain that the ergonomical cost of using either of these workarounds offsets the benefits to the user.

Right, there is no problem with
impl<T> Mul<Size<T>> for u64
where T: ToPrimitive,

but if you replace the u64 with a U: ToPrimitive then you get an "error[E0210]: type parameter U must be used as the type parameter for some local type (e.g. MyStruct<U>)".
I think #2451 fixes this.

@ExpHP Exactly, and I think it's clear to everyone that the ergonomics of your distinct Scale type are not exactly ideal.

Why can't there be a RevMul trait corresponding to an implementation of multiplication with the reverse handedness, similar to how Python uses __mul__ and __rmul__ to handle both commutative and non-commutative multiplication in a generic fashion? If Mul is implemented for two types, this is used; otherwise, the compiler searches for a RevMul implementation. This gets around the issue entirely, by making both hands generically implementable, but not requiring commutativity.

Commutative multiplication would look like this:
struct MyStruct ...;

impl Mul<isize> for MyStruct {
    type Output = Self;
    fn mul(self, rhs: isize) -> Self::Output {
        ...
    }
}
impl RevMul<isize> for MyStruct {
    type Output = Self;
    fn rev_mul(self, lhs: isize) -> Self::Output {
        self.mul(lhs)
    }
}

isize doesn't need to know about MyStruct. It shouldn't need to know about it to implement commutative multiplication.

How would you desugar a * b to calls to mul or rev_mul without making it a breaking change to add an implementation of either Mul or RevMul? For context, currently a * b desugars to something like Mul::mul(a, b).

I'm pretty new to Rust so I'll ask another question rather than directly answer yours: Is it not doable for the compiler to desugar differently based on context? It seems like something as fundamental as operator overloading should be worthy of some special treatment from the language.

It is possible to desugar things based on context, but I don't think anything besides closures do this. (and given how pervasive closures are, this is justified). In this case the danger is something like this:
// crate A:
struct Foo;

// crate B:
struct Bar;

impl RevMul<crate_a::Foo> for Bar { ... }

// crate C

fn main() {
    let _ = crate_a::Foo * crate_b::Bar;
    // desugars to
    let _ = ::core::ops::RevMul::rev_mul(crate_a::Foo, crate_b::Bar);
}

Now, let's say that we desugar by precedence: first, we try Mul, then RevMul.
Now, crate_a implements Mul:
// crate A

// snip ...

impl<T> Mul<T> for Foo { ... }

// crate C

fn main() {
    let _ = crate_a::Foo * crate_b::Bar;
    // desugars to
    let _ = ::core::ops::Mul::mul(crate_a::Foo, crate_b::Bar);
}

Note that the desugaring changed! This is a breaking change, especially if Mul::Output != RevMul::Output. Similar problems happen in reverse if we change the order of precedence.
So if not precedence how should you decide which of Mul::mul or RevMul::rev_mul to use?
Keeping in mind:

We don't want to make it a breaking change to implement Mul
that if you really wanted to, you could create a proc_macro
use methods and side step this issue entirely
and that sugar doesn't need to cover 100% of cases. just the majority of actually used cases

We don't want to make it a breaking change to implement Mul

If a use statement was required for the multiplication operator to take effect, adding an implementation for Mul wouldn't be a breaking change, would it? And then downstream users could use whichever implementation they preferred, or even switch them up on a scope-by-scope basis if the need arose. Of course, that has the drawback that it would make the compiler cease to be backwards compatible, meaning it couldn't be implemented until the next major version was released.

If a use statement was required for the multiplication operator to take effect, adding an implementation for Mul wouldn't be a breaking change, would it?

If that were true, yes it wouldn't be a breaking change, however you don't need to use std::ops::Mul; to use the operator sugar: playground

Of course, that has the drawback that it would make the compiler cease to be backwards compatible, meaning it couldn't be implemented until the next major version was released.

More egregiously, it would mean adding a Mul or RevMul implementation would be a breaking change. There are only a handful of traits that are like this now, and most are nightly only. The only one on stable that I'm aware of is Drop, but Drop is very special, in ways that are undesirable for operators.

I know we don't want to add more special traits, but I just want to throw it out there that a UnRevMul trait that is assumed opt-in for all types in all crates <= Edition2018 would prevent a hypothetical RevMul from being a breaking change.

I wonder if we can have a phantom marker that indicates a type opts out of a default implementation , eg
struct Foo {
    x: i32,
    _revmult: core::phantom::PhantomRevMul,
}

This would forbid an impl of Mul where Mul::Output != Self allowing the single Mul impl to provide both directions (or else just allowing the otherwise potentially conflicting Mul<Output=T> to be implemented).
This would prevent breaking backwards compatibility since changes to a type, including adding a phantom member, are breaking. It would mean an extra compiler-internal special trait (like Unsize) but it’s really more of an implementation detail than anything else. It does introduce a new paradigm for opting out of (or into) a behavior via composition rather than impl but again, it is influencing language-level rather than lib-level behavior (sugaring) so that doesn’t seem too egregious to me.
(Whether this particular behavior is a default opt-in for a future edition or not is a different story.)
Personally, I think the problem is with making Output an associated type. I think the cleaner solution would have been  a Mul<X, Y> trait that would desugar only in case of no ambiguous impl, otherwise requiring explicit trait typecasting to use.

Associated Output types simplify type inference considerably.  It's obviously unacceptable for expressions like (a * b) * c to so slow down compilation.
In practice, rust code should bless a specific primitive type around which it optimizes performance, not be polymorphic over primitive types.  As a rule, one should prefer distinguished scalar types like the Scale proposed above too over operations with primitive types too, so maybe pub struct Scale(pub u32); or whatever.
All this seems moot now but..
Rust could've placed the LHS and RHS on eaual footing by defining Mul and Add to take roughly a 2-tuple, like
pub trait Mul {
    type Output;
    fn mul(self) -> Self::Output;
}

Rust could've even made * create some specially typed tuple before invoking this method, like
pub struct MulOp<LHS,RHS> {
    lhs: LHS,
    rhs: RHS
}


Material Theme Builder exports a theme ignoring Neutral and Neutral variant passed colors

Describe the bug
My theme setup is like this:

settings in Figma:

The theme produces contains backgrounds and sufraces which are all whiteish with primary color tints (light themes) and greyish with primary color tints (dark themes).
The Netural and Neutral variant colors i try to force generation upon, are most probably ignored. I dont uderstand why I cant get the result i see in the setup
To Reproduce
Steps to reproduce the behavior:

Use colors and settings from above screenshot
Generate JSON theme

Expected behavior
I would expect my backgrounds to be dark blue, with primary peach color elements on it.
Screenshots
attached in description
Desktop (please complete the following information):

OS: MacOS
Browser Chrome
Version Chrome 125.0.6422.142 (Official Build) (arm64)

Additional context

I have a similar issue with the Color Styles in Figma.
Even after changing them, the generated neutral and neutral-variant color styles remain the default colors.


Fix URL link on CONTRIBUTING

Replace old faster_kubernetes/reviews.md_ with the new one.

LGTM

LGTM


[Python] No limit pushdown for scanning Parquet on Azure

Describe the bug, including details regarding any error messages, version, and platform.
I am accessing a Parquet file on Azure data lake with the following code.
(to make the example reproducible, the example has a file publicly accessible on Azure)
import pyarrow.dataset as ds
from adlfs import AzureBlobFileSystem

abfs_public = AzureBlobFileSystem(
    account_name="azureopendatastorage")

dataset_public = ds.dataset('az://nyctlc/yellow/puYear=2010/puMonth=1/part-00000-tid-8898858832658823408-a1de80bd-eed3-4d11-b9d4-fa74bfbd47bc-426339-18.c000.snappy.parquet', filesystem=abfs_public)

The processing time is the same for accessing the full file or only the first 5 rows:
dataset_public.head(5)
# 5min 11s

dataset_public.to_table()
# 5min 30s

dataset_public.scanner().head(5)
# 5min 43s

I would expect the time to be less for 5 rows. I am not sure about the difference between .scanner().head() and .head().
Regarding reducing the number of columns:
reducing the number of columns retrieved speeds up the query, but the reduction seems small. For example, filtering to only 2 columns out of 21 reduces the query to 2min 7:
dataset_public.scanner(columns=['vendorID','passengerCount']).to_table()
# 2min 7s

I would have expected that collecting 10% of the columns ( 2 columns instead of 21 columns) to reduce the time by more than half. Unless there is an overhead to the query for collecting from Azure?
Sources for the code:

Apache Arrow website: https://arrow.apache.org/docs/python/parquet.html#reading-from-cloud-storage
ADLFS Github page: https://github.com/fsspec/adlfs

Thank you for the outstanding job on the Arrow library
Component(s)
Python

I can't remember especially clearly but I think I have had some success using limit on Azure before. One thing to bear in mind is that I think arrow will only read entire row groups. So depending on the row group layout of your parquet file that might explain things.
Additionally I have found that adlfs does some kind of prefetching thing which personally I've found to be counter-productive. When I tested this I was using a native arrow filesystem implementation, which is very close to being available officially in pyarrow. The native filesystem should also be generally faster and more reliable.


Add Vercel deployment badge

Add a deployment badge for both preview and production to the readme file.

Fixed in d7f2b21c41cc36ee9c8d99f13d3e079d65e517d7


No execution feedback with multiple tabs

For example. I have two tabs with result set and second tab is active and pinned. When i execute query (Ctrl + Enter), then i don't have feedback about execution because, it is executing hidden on first tab.
Same situation is with "Server output console". It's little confusing.

First problem (with pinned tab) is a bug. It will be fixed in the next version, thanks for the bug report.
Server output console is different. It was made on purpose - sometimes you need to execute queries and monitor server output they produce. Auto-switching to results tab will make this very inconvenient. just hide output if you don't need it.


Error while connecting LimeSDR : "usbip client not correctly installed"

Hello,
I'm trying to connect the LimeSDR to my computer as it's explained in the following section of install.md :
(https://github.com/LELEC210X/LELEC210X/blob/main/INSTALL.md#only-for-wsl-users-connect-the-limesdr-to-the-wsl-via-usb-pass-through)
I've run the two intall commands, but when I run "usbipd wsl attach --busid ", I have an error "usbip client not correctly installed".
I've also tried what it's explained here below, but I still have the error.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdorssel%2Fusbipd-win%2Fissues%2F251%23issuecomment-1079961293&data=05%7C01%7Caudrey.vermeulen%40student.uclouvain.be%7C5aae251c392840f630f808dbd895bf5f%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C638341909893354174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dwIq%2FE4PYxAEDyPa1WcM7SMOnLJMUFeVdWC2g8i4FRY%3D&reserved=0
Does anyone can help me ?

Hello @AudreyVermeulen, can you please add a screenshot of the error message in the terminal?
Can also fix the second link, it does not work :-)
And did you check on the internet about the warning that was emitting when running usbipd? It was about a compatibility issue if I remember correctly.


neomutt: 20200619 -> 20200626

Motivation for this change

Changelog
enable on darwin (via enabling elinks on darwin)

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

The update is already done in da1b17fd35d544f6902b61d9fcf00c6d0c4e69d0, enabling elinks on darwin for neomutt support on darwin seems fine to me, please rebase your branch onto latest master.

Rebased.

@GrahamcOfBorg build neomutt

FYI elinks is now insecure because it depends on spidermonkey_37 which is insecure now (ever since https://github.com/NixOS/nixpkgs/commit/5ad43894f2af987ac02ea2a6c8bb9e5f4e49068d ). Switch to w3m should be no problem at all and produce almost identical results (either lynx, w3m or elinks are used for generating manual.txt out of manual.html). PR: https://github.com/NixOS/nixpkgs/pull/99497


Generate license/notice/dependencies

A patch to add mandatory LICENSE/NOTICE/DISCLAIMER and recommended DEPENDENCIES files to the zip distributions (source and binary). Also tweaks several of the -license.txt files to get better cleaner results. Only tested for "cluster.config=platform" for now.

Looks great and exactly what's needed.


the information of "tfReplicaStatuses" is none when tfjob is in In termination state

I usually use "tfReplicaStatuses" to judge the state of a tfjob. but after I deployed kubeflow 0.3.3, the information of "tfReplicaStatuses" is none, I can't get any useful information at all. The situation is as follows

When tfjob runs successfully

"tfReplicaStatuses":{
"PS":{},
"Worker": {}
}

When tfjob fails

"tfReplicaStatuses":{
"Chief": {}
"Master": {}
"PS":{},
"Worker": {}
}
In addition, I would like to ask if there is any way to get the status of a tfjob directly, instead of judging by the information in "tfReplicaStatuses".

/cc @richardsliu @gaocegege

Is it possible this has already been fixed in 0.4?

@jokerwenxiao Another option is to look at the Conditions field: https://github.com/kubeflow/tf-operator/blob/v0.3-branch/pkg/apis/tensorflow/v1alpha2/types.go#L141
The last condition should be one of the following values: https://github.com/kubeflow/tf-operator/blob/v0.3-branch/pkg/apis/tensorflow/v1alpha2/types.go#L194
I will take a look at why the tf replica status is missing.

Looks like we are reinitializing the TF replica status after TFJob completes: https://github.com/kubeflow/tf-operator/blob/master/pkg/controller.v2/tensorflow/controller.go#L374
So after a TFJob completes (either success or fail), the replica statuses are reset.
@gaocegege What is the reason for this?

I think it is a bug, while there is something we need to care about: how to show the result if we delete pods after finished.
In the current design, we get the status of all pods, then set in the TFReplicaStatuses field. After the job is finished, we cannot get the result anymore.

Do we still need to reconcile pod status after the job is done?

If there is no need, I think we could just remove the code about initialization, then it should work. WDYT @richardsliu @johnugeorge
Personally, I think there is no need although there may be some PS/workers after finished.

Few questions

What is the real significance of tfReplicaStatus field currently?  Can we treat it as an internal field which should not be used by developers?

Wrt @gaocegege's last comment, what is the  extra information that we provide with the status of the previous workers/ps.? Doesn't JobCondition suffice our needs?

If we need to expose it,  we have to note down the expected values of tfReplicaStatus field for various replica types.

What should be status of PS when job is completed and PS pods are deleted due to CleanPodPolicyRunning?
Currently PS workers are always active.
eg:  When I ran https://github.com/kubeflow/tf-operator/blob/master/examples/v1beta1/dist-mnist/tf_job_mnist.yaml  (with reconcile code removed after job is done) , I got the following result
replicaStatuses:
PS:
active: 2
Worker:
active: 1
succeeded: 3
This is also a confusing as PS pods are missing but status shows that they are active

TfReplicaStatus is being used internally to determine status of the TFJob: https://github.com/kubeflow/tf-operator/blob/master/pkg/controller.v1beta1/tensorflow/status.go#L46
I think it makes sense to keep the usage internal. JobCondition should suffice for identifying the job status.


Update loader-utils to 1.4.2

Description
Update loader-utils to 1.4.2. For some reason, it looks like 2.0.4 got backported but this version didn't. Fixes that.
Check List

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[x] All tests pass

[x] yarn lint
[x] yarn test-unit

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@BSFishy Do we also want to add a resolution as well?

@BSFishy Do we also want to add a resolution as well?

I don't think we need to. This (hopefully) should work in the future as the version is compatible with the version spec and I'd like to avoid resolutions as much as possible


[Bug] Sidebar left/right setting doesn't seem to work

This still puzzles me: The Sidebar-Left / Sidebar-Right buttons in 8Vim don't seem to do anything. I feel like they used to, but now it seems somewhat random whether they do something.
I suggest, that upon button-press, the keyboard should IMMEDIATELY be restructured.
If other settings have a similar delayed effect, also make them immediately effect the keyboard.

duplicate of #36

As a temporary workaround until #36 is fixed, you could display a toast message when the sidebar-left or sidebar-right button is pressed. That way, users will know that something changed.


Parsing date string raises an exception since 0.14.1

before 0.14.1 (including 0.14.0)
iex(1)> "2015-06-23 17:23:52.233+0000" |> Timex.DateFormat.parse!("{ISO}")
%Timex.DateTime{calendar: :gregorian, day: 23, hour: 17, minute: 23, month: 6,
 ms: 233, second: 52,
 timezone: %Timex.TimezoneInfo{dst_abbreviation: "UTC", dst_end_day: :undef,
  dst_end_time: {0, 0}, dst_name: "UTC", dst_start_day: :undef,
  dst_start_time: {0, 0}, full_name: "UTC", gmt_offset_dst: 0,
  gmt_offset_std: 0, standard_abbreviation: "UTC", standard_name: "UTC"},
 year: 2015}

since 0.14.1
iex(1)> "2015-06-23 17:23:52.233+0000" |> Timex.DateFormat.parse!("{ISO}")
[error] Error in process <0.604.0> with exit value: {badarg,[{erlang,byte_size,[[{message,<<35 bytes>>}]],[]},{'Elixir.Exception',format_banner,3,[{file,"lib/exception.ex"},{line,106}]},{'Elixir.IEx.Evaluator',print_error,3,[{file,"lib/iex/evaluator.ex"},{line,158}]},{'Elixir.IEx.Evaluator',eval...

** (EXIT from #PID<0.604.0>) an exception was raised:
    ** (ArgumentError) argument error
        :erlang.byte_size([message: "Input string does not match format!"])
        (elixir) lib/exception.ex:106: Exception.format_banner/3
        (iex) lib/iex/evaluator.ex:158: IEx.Evaluator.print_error/3
        (iex) lib/iex/evaluator.ex:95: IEx.Evaluator.eval/2
        (iex) lib/iex/evaluator.ex:29: IEx.Evaluator.loop/1
        (iex) lib/iex/evaluator.ex:19: IEx.Evaluator.start/2

We're retrieving those values from a database which can't be parsed with newer versions

Seems like https://github.com/bitwalker/timex/commit/e4767a85197a6234a1d29b7e563660819a018af5 is introducing that behaviour

I'll take a look ASAP

@hamann This is because your input string is not a valid ISO 8601 string. It is permitted to omit the T delimiter between the date and time, but in the spec this is by mutual agreement. The {ISO} token is there as a shortcut for "{ISOdate}T{ISOtime}{Z}", so in your case you should use "{ISOdate} {ISOtime}{Z}" to parse the given input string.
Parsing datetime strings is more strict now, as previously the only thing the parser cared about in the input was the tokens and the order they occur, and now the parser expects the input to match the format string exactly, so unfortunately some issues like this will crop up.

@bitwalker thanks for clarification! Didn't know that those shortcut exist and it works as suggested.
Just one small wish - please don't make backward incompatible changes in patch version updates ;)

@hamann Definitely, sorry about that, I try to be careful about following semver guidance, but I slipped up on this one. I'm in the process of revamping all the Timex documentation too, so the formatting/parsing stuff in the future should be a lot more clear.


Adding documentation

Motivation
An Integration Guide was needed to provide reference for developers working with the SDK.
In this PR

Adding documentation.

Future Work

adding external/cross-docs links as needed

closing this PR to sort out Gitbook


Renaming the winpe file

this is per @anhou's comment

:+1: Thanks @tannoa2

test this please

:+1:


refactor: CI

Changes

Merge GitHub Actions manifests into one for Lint & Unit Tests jobs
Update supported env list to [3.8, 3.9, 3.10, 3.11]
Add Pre-commit File - Run pre-commit install to setup your hooks

Fixes https://github.com/kayak/pypika/issues/748, https://github.com/kayak/pypika/issues/747

Good job Gavin. Could you also update the checkout Github Action actions/checkout@v1 since there is already v4 out there?

coverage: 98.423% (+0.002%) from 98.421% when pulling 31ea4718dcebc49cf183f3705cef1ca0bfa21081 on gavindsouza:refactor-ci into 30574f997c80851f7e940ad09a63e14a98871dd3 on kayak:master.

Hey @AzisK, is there anything else I can do to help get this merged?

@gavindsouza it looks good but before that could you look at my last comments about pypy and black target version and tox envlist?

@gavindsouza it looks good but before that could you look at my last comments about pypy and black target version and tox envlist?

I can't find anything regarding those yet to be addressed. (Did you add comments that are in a Pending state? If so, you are yet to submit your review)

Meanwhile, since black is moved to pre-commit, I think removing it from dev-requirements tracking is best.

@gavindsouza
RE: Meanwhile, since black is moved to pre-commit, I think removing it from dev-requirements tracking is best.
I agree
RE: I can't find anything regarding those yet to be addressed. (Did you add comments that are in a Pending state? If so, you are yet to submit your review)
Yes, they have been in a pending state, sorry about that and thanks for the notice

Everything looks good, thanks! I will merge the pull request but version bump and release will happen a little bit later. However, this mostly concerns the CI, so I believe the version is not even very important in this case


Issues about proxy task

Hello! Thanks for your constructive work！I have some issues about the proxy task. How can I generate proxy_data folder. It seems that the class ProxyPredictor is not provided in the original code, which made "from inference.ProxyPredictor import ProxyPredictor" unable to work in run_inference_proxy.py. Could you kindly provide some explanation? Thanks for your helpful work again.

Hi, thank you for your interest in this work and pointing out the issue. I will clean up the repo and provide the details on how to run the uncertainty-based and diversity-based methods. The script 'run_inference_proxy' was actually depreciated. To run the AL methods, you will need to run 'run_uncertainty_estimation' and 'run_feature_extraction'.


Lab 2 Import Regex

I am having to import "introtodeeplearning_labs". Has anyone have the same problem?

I noticed this problem yesterday, it seems like it is a new problem on Colab since the newest version doesn't have regex installed by default.
You can fix the problem by running !pip install regex in the cell above.


Add pEachSeries.stop

Fixes: #3

Did you see https://github.com/sindresorhus/p-map/issues/31 ? Any thoughts?


READY FOR REVIEW: renamed binding to link everywhere

all binding references were renamed to link.

Same as with the other PR, I think it makes sense to wait until #14 is done and then re-apply this change to main rather than attempting the merge conflict resolution since that PR basically makes changes everywhere.

@mikezupper if you want you can try and resolve the conflicts here, or I can just try and do a by-hand merge offline. I tried to get git to do this for me automatically and it laughed at my weakness.

i will recreate a new PR with these changes. Too many files have been renamed or altered beyond GITs ability to reconcile the differences.


Does not work on ios react-native version 0.60.x

I hope you will support react native 0. 60. x soon. I am looking forward to the update 0. 0.6 from you or manual installation instructions on ios manual.

I have the same problem

I hope you will support react native 0. 60. x soon. I am looking forward to the update 0. 0.6 from you or manual installation instructions on ios manual.

Any solution?

same for me, any solution ?

same for me, any solution ?

You have to add de pod file manually.
https://github.com/januslo/react-native-bluetooth-escpos-printer/pull/76
It´s working for me and i am using 0.61.2

I have tried to install it via npm, and in that case also got the same error.
When installed with:  npm install https://github.com/januslo/react-native-bluetooth-escpos-printer.git --save It worked.

Just merged, but not release yet.
发自我的iPhone

在 2020年2月13日，上午3:51，fabicsp<EMAIL_ADDRESS>写道：

I have tried to install it via npm, and in that case also got the same error.
When installed with: npm install https://github.com/januslo/react-native-bluetooth-escpos-printer.git --save It worked.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I'm also having problem running with ReactNative 0.6. I did fresh install project (without Expo), install this plugin, but BluetoothManager is always null. I have tried using const { BluetoothManager } = NativeModuels  but no luck. I think I miss something on cocoapods procedure but don't know exactly how. Could you please provide the steps? (cc: @JuanCamilo0809)

"react-native-bluetooth-escpos-printer": "https://github.com/januslo/react-native-bluetooth-escpos-printer.git",

@afrakhan123 Yup, I installed plugin via github with "npm install https://github.com/januslo/react-native-bluetooth-escpos-printer.git --save" instead and it's working, but I got this further error:

Please advice.

@JuanCamilo0809 Hi, have u experienced this issue?

@afrakhan123 Yup, I installed plugin via github with "npm install https://github.com/januslo/react-native-bluetooth-escpos-printer.git --save" instead and it's working, but I got this further error on 'Scan' tapped:

Please advice.

Never mind. In the end I reinstalled project with React Native v0.59.8. Great plugin though, thanks.

@JuanCamilo0809 Hi, have u experienced this issue?

@afrakhan123 Yup, I installed plugin via github with "npm install https://github.com/januslo/react-native-bluetooth-escpos-printer.git --save" instead and it's working, but I got this further error on 'Scan' tapped:

Please advice.

Yes, but it was because the bluetooth is off, try On and it´s ok.


breaking query execution into a child page

@ljsinclair another iteration if you have internet. If not, i'll be merging in and go for another iteration tomorrow. Feel free to look at last PR.

Merging in, so I can iterate


Setup global types for requirements

Summary
Move requirement types into a global typedef file, so that they can be used everywhere without import. This is used to unblock final setup to add requirements into global store.
Depends on #290.
Test Plan
This is mostly a type only change, so check everything still type checks.
I also migrated more components to avoid using Vue.component('...', Component). We can check it works by ensuring every part of the app still loads without error.

LGTM! I found a bug that's on this PR's staging site and on master's as well. I don't think it's related to #290 or #291 since it's on master so I would be ok with approving this PR as it seems mostly type changes anyway.
I observe the following buggy behavior for CALS and A&S credits but not for other subreqs. I haven't tried other colleges but I wonder if it has to do with college credits. Do you have any guesses?
Screen.Recording.2021-02-15.at.4.38.50.PM.mov

This looks like the subreq courses is a little buggy...


Add support for Python 2

A user should be able to choose to launch Jupyter with either Python 2 or Python 3.
module load python/2.7

Requested in SN Ticket: INC0315978

Pinged OSC Sci Apps about their thoughts on adding a Python 2 kernel to our current implementation of Jupyter that uses Python 3.
SN Ticket: INC0316002

Just to follow-up a bit on this, based on Kevin's comments in SN I've added this to our Ingest list in Asana.

Turns out there is a method that user's themselves can do to add Python 2 to their Jupyter Notebook. From Heechang:

I confirm that we can add any python kernel to Jupyter by local installation.
After we load the python, we can create a local python version by
conda create -n {local python name} python={version} anaconda

I did for mypython3 and py2.7, and both are appeared on Jupyter.
I attached a screen shot of it.

So I am marking this done.


Fix nightly functional tests failures for datascience

For #6384

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR)
[x] Title summarizes what is changing
[] Has a news entry file (remember to thank yourself!)
[ ] Appropriate comments and documentation strings in the code
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[x] Unit tests & system/integration tests are added/updated
[ ] Test plan is updated as appropriate
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed)
[ ] The wiki is updated with any design decisions/details.

The last nightly run passed for all of our stuff, but failed in the multiWorkspace test (not related to our code)


[ZEPPELIN-1210] Run interpreter per user

What is this PR for?
Enabling each user to run same interpreter.
What type of PR is it?
[Improvement]
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-1210
How should this be tested?

Enable shiro to use authentication mode
Check per user in your interpreter tab
Run different paragraphs with different users
Run %spark sc.version, you will see the two res0: ... in your paragraphs

Screenshots (if appropriate)
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Quickly went through the changes, but not sure to get it.
In which way is this related to the various intepreter modes we already have?
In which way is this related to ZEPPELIN-1000 (Multiple simultaneous users on a single WEB server)?

@echarles For now, Zeppelin supports per note option but doesn't do per user. If two different users log in Zeppelin and want to use same spark interpreter with same note, they cannot run a paragraph simultaneously. This PR enable that feature. Concerning ZEPPELIN-1000, I don't know the meaning of the management of single user exactly. AFAIK, Zeppelin manages multiple users at the same time. Could you please describe in details? I think you'd better answer the moon's statement.

https://travis-ci.org/apache/zeppelin/builds/150661771

@jongyoul this looks very interesting! Could you plz help me to understand - does this changes mean for Zeepelin to run a new separate interpreter process for every user and schedulle only his jobs to be executed there?

@jongyoul  Does that mean the login user is the process owner ? Because it matters for security reason.
e.g.

For spark interpreter, it would be better to launch the yarn app as the user who login in zeppelin.
For shell interpreter, it would be better to launch the shell as the user who login in zeppelin. Otherwise it is pretty dangerous. The user can delete all the files owner by others.

@bzz If different users run a same interpreter with 'isolated', Zeppelin runs multiple process for that interpreters, and with 'scoped', Zeppelin runs a single process for it but the users feel like a separate process because Zeppelin interpreter use different class loader per user. For instance, if some users use SparkInterpreter with 'isolated' and 'scoped', all users look like running each SparkInterpreter.

@zjffdu This is a first step for resolving security issues. For the next step, I'll pass some properties for identifying user. BTW, InterpreterContext includes user information, actually, thus it might not be a big change. :-)

@jongyoul
I suggest while we enable this feature we also enable that user can access only the data what he/she is authorized to.
For example if there is a folder/table in HDFS/FileServer/Hive which user is trying to access he/she should not be able to access that unless he/she is authorized for the same.
To enable this, while starting the spark-submit, Zepplein needs to ensure that it is started with the current user mode (the Shiro user).
Regards,
Sourav

@sourav-mazumder 's suggestion is about another point of multiple user support, this is might not be a trivial task to implement in this PR.  I think we have a discussion about the multiple-user support for zeppelin in the mail list recently.  There's lots of works to do, I will create a umbrella ticket for that so that we can have a more clear whole picture of that.

Create umbrella ticket for multiple user support.
https://issues.apache.org/jira/browse/ZEPPELIN-1337

Merging if there's no more discussion

@jongyoul Thanks for the great work. I tested this PR a bit and it works as expected. However, when i remove a Note, (with "perNote" checked), i think removal of Interpreter Process (isolated mode) or Interpreter Instance (scoped mode) related to that Note is expected. However this PR does not remove them.
The same interpreter process/instance removal should happen when user unbind interpreter setting from Note.
Could you check these case?

@Leemoonsoo Thanks for the review. I'll check that.

@Leemoonsoo I've fixed it. Check it please. This is because remoteProcess doesn't destroy correctly.

@jongyoul  I don't see the per user in the interpreter page. Do I miss anything ?

It looks looks like a browser cache issue. Can you clean cache and try it
again?
On Friday, 2 September 2016, Jeff Zhang<EMAIL_ADDRESS>wrote:

@jongyoul https://github.com/jongyoul I don't see the per user in the
interpreter page. Do I miss anything ?
[image: image]
https://cloud.githubusercontent.com/assets/164491/18191192/03daf4ba-70fb-11e6-9753-03a81a4bbd75.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/zeppelin/pull/1265#issuecomment-244270004, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADcfltXnJyMjMfmsoNqDPfBlE5pOO4Z3ks5ql470gaJpZM4Jauiv
.

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Thanks @jongyoul  after clean cache, I can see the per user.  But unfortunately, two users still share the same interpreter. Here's what I see. I use yarn-client mode and only see one yarn app is launched.

Besides I have other 2 concerns.

I am a little confused about the combination of the interpreter options. There's so many combinations (223=12), I am not sure whether users are comfortable with that.

Is it necessary to apply this feature globally ? For now it seems spark interpreter is the only one that needs it as we want each user has his own SparkContext. I don't see the necessary that other interpreter needs that. (At least it is not necessary for livy, as livy interpreter will create spark session per user)

About the first comment you should set scoped or isolated, not
shared. And growth of complexity is to remain backward compatibility. I
also agree that interpreter setting become too many. But if we may break
the current behaviour, we should discuss first and then change it. To make
that setting global is more easier than now, but we should try to reduce
the change when users upgrade Zeppelin.
On Friday, 2 September 2016, Jeff Zhang<EMAIL_ADDRESS>wrote:

Besides I have other 2 concerns.

I am a little confused about the combination of the interpreter
options. There's so many combinations (223=12), I am not sure
whether users are comfortable with that.
[image: image]
https://cloud.githubusercontent.com/assets/164491/18192968/84a5d8ca-710b-11e6-8a29-10109bd3692b.png
Is it necessary to apply this feature globally ? For now it seems
spark interpreter is the only one that needs it as we want each user has
his own SparkContext. I don't see the necessary that other interpreter
needs that. (At least it is not necessary for livy, as livy interpreter
will create spark session per user)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/zeppelin/pull/1265#issuecomment-244283197, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADcflrRQnTCuZY6YnoSzlp_XR8OCEmulks5ql6xngaJpZM4Jauiv
.

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

@jongyoul Can you make a quick recap on the difference between all of those options?
(perUser, perNote, shared, scopes, isolated)

Thanks @jongyoul , change it to isolated works.
Regarding the option complexity, I still have concern on that.  So now there's 2 dimensions for interpreter (user/note) IIUC. Before 0.6, zeppelin don't support shiro and it makes sense to take note as the dimension.  I guess the reason we introduce shared, scopes, isolated is because at that time we don't have shiro, but we want to control whether to share or isolate SparkContext between users. so we introduce shared, scopes, isolated to achieve that.  But after 0.6, zeppelin support shiro, I think it is more proper to take user as the first dimension (maybe remove note dimension later).
By default each user should run his own interpreter, I think this is the most often used scenarios.  For the scenario of collaborative analysis, I would suggest user to create a new interpreter with option shared and set permission on that interpreter to control who can share this interpreter across users.
Overall, my concern is to reduce complexity. Since zeppelin is a tool and bridge between user and spark(other interpreter). The goal of zeppelin is to make the life of analyst easier, we should add less complexity as possible on the user facing UI. I know break compatibility is bad for user, but complexity is also very bad to users,  we should balance them.
Besides, I think we should think more deeply on the relationship between note, user and interpreter.

Concerning those modes, AFAIK, before Zeppelin 0.6.0, Zeppelin has only shared mode, but most of users want to run a interpreter with their own, Zeppelin add two modes called scoped and isolated. The main difference between them is where that interpreter is launched. scoped mode launches an interpreter with same process and different thread with its own class loader. Otherwise, isolated launches different process. per user and per note are dimensions to support those modes.
@zjffdu I also agree we should try to reduce complexity, but we should try to keep user experience equally. Zeppelin's users are not only individuals but also enterprise. We should consider all of users' experience. And I already argued that issue with @Leemoonsoo, and we conclude that keeping current users' behaviour is more important than making them simple. I suggest we will start to discuss the breaking changes. As you mentioned the above, we should think of the relationship of those components.

Since I don't know much about how the interpreter part works, Its still quite confusing.
And I think that having both checkbox and a dropdown might not be helping.
First of all, is there a possibility that by setting 'Per User' or 'Per Note', some of the previous settings (isolated or scoped) become meaningless?
Otherwise, I think this could be a good improvement:

First drop down (globally, per user, per note)
Second drop down (shared, scoped, isolated)
Would the 'Connect to existing process' option be part of that second dropdown? or is it not related?

@corneadoug Yes, I agree that it's quite confusing. I like your suggestion. Let me try it. And 'Connection...' is not related to this setting.

@corneadoug 's suggestion seems more intuitive.

If i add more after @corneadoug 's suggestion,
when "globally" is selected from the first dropdown, only possible selection in the second dropdown is "shared".
when one of "per user" or "per note" is selected, then only "scoped", "isolated" could be option in the second dropdown.
I think there should be one more option "per user and per note". Which is more complicated, because it can work have some combinations
     per user : Scoped ( )  Isolated ( )
     per note : Scoped ( )  Isolated ( )

For example, user may want to run spark interpreter "per user and per note" and make a interpreter process per user, but interpreter instance per note in the process.
What do you think? shell we have this combination supported in very intuitive UI/UX?

@Leemoonsoo Agree
I will commit the changes to the UI with backward compatibility:
Previous [shared] -> [globally][shared]
Previous [scoped] -> [per note][scoped]
Previous [isolated] -> [per note][isolated]
Regarding the per user + per note combination, I think it will be better to take care of that once we start handling per user interpreter config and list. (Right now, the config and interpreters are global to the instance)

How about

When "globally" is selected, "shared" mode is preselected and can not be changed
When either "per note" or "per user" is selected, "scoped" or "isolated" is shown in the next stop down. And "+" button at the end.
When "+" button is clicked, more drop boxes are shown to do combination of per note and per user.

what do you guys think?
Regarding per user interpreter config, i'm not sure how useful it is compare to complexity it will bring.
Complexities per user interpreter config will bring are,

Some interpreter in 'scoped' mode might not able to support per user interpreter config. For example, current spark interpreter in 'scoped' mode shares single SparkContext. So there's no way to apply per user config which related to SparkContext creation.
Interpreter authorization will be more complicated to take care individual configuration's permission.
Interpreter configuration itself becomes complicated. For example, there're per user interpreter config created. When a user (devops, admin) want to change a property of all users's interpreter config at once, it's difficult to do that.

I think the same goal of per user interpreter config can be achieved by improving interpreter authorization (permission), without much complexity.
If interpreter authorization can control
a. who can create/clone new interpreter config
b. who can edit interpreter config
c. who can see and use interpreter config
Then it can provide the exactly same thing that per user interpreter config trying to do.

@Leemoonsoo this brings a lot of possible configurations, and there will need to be some limitations because they don't all make sense. Would the server be able to handle them correctly and manage the order?
[Per user] - [isolated] and [Per note] - [scoped]
[Per user] - [isolated] and [Per note] - [isolated]
[Per user] - [isolated] and [Per user] - [isolated] Obviously shouldn't be possible
[Per user] - [isolated] and [Per user] - [scoped] Obviously shouldn't be possible
[Per user] - [scoped] and [Per note] - [scoped]
[Per user] - [scoped] and [Per note] - [isolated]
[Per user] - [scoped] and [Per user] - [isolated] Obviously shouldn't be possible
[Per user] - [scoped] and [Per user] - [scoped] Obviously shouldn't be possible
[Per note] - [scoped] and [Per user] - [isolated]
[Per note] - [scoped] and [Per user] - [scoped]
[Per note] - [scoped] and [Per note] - [isolated]  Obviously shouldn't be possible
[Per note] - [scoped] and [Per note] - [scoped]  Obviously shouldn't be possible
[Per note] - [isolated] and [Per user] - [isolated]
[Per note] - [isolated] and [Per user] - [scoped]
[Per note] - [isolated] and [Per note] - [isolated] Obviously shouldn't be possible
[Per note] - [isolated] and [Per note] - [scoped] Obviously shouldn't be possible

First, I just feel this expression is a kind of thinking of zeppelin developer (The interpreter will be in instantiated ... ) rather than at the standpoint of users. I think what user care about is how to share the interpreter across notes/users. So we may change it to

The interpreter is shared across ....

Regarding the scope of sharing, I think there's following 3 kinds:
-  Across users
-  Across notes under one single user
-  No sharing  ('isolated') (one Interpreter in one JVM for each note)

And regarding sharing method,  I think there's 2 ways to share:
-  One JVM One Interpreter `shared` (same interpreter namespace, everything is shared)
-  One JVM Multiple Interpreter `scoped` (different interpreter namespace, only resource pool is shared, e.g. SparkContext)

Now, let's think about the first scenario. Assume we have enable shiro, and logging as user A. So user A want to change the setting of interpreter spark. Here's what he can choose
-  Nothing shared across notes
-  Shared everything across notes
-  Only share resource pool across notes

He should not have permission to control whether this interpreter can be shared across users. Only the administrator can do that.
Now, let's take a look at the second scenario, we log in as administrator.  He can create a new interpreter to make it shared across users. Here's what he can choose.
- Share everything across users  ( One Interpreter instance)
- Only share resource pool across users (One Interpreter instance per note )
- Share resource pool across users and share everything across notes under one user (One Interpreter instance per user)

Actually I think the first scenario is the common case, the second scenario is very rare.
Of course we have the third scenario, shiro is not enabled. Actually this is the same as the first scenario, as we don't have user here. Everything is under user anonymous.

Second, Regarding per user interpreter config, I think it is necessary. As I think individual user development under zeppelin is the most common case. Although we may want to share across users, but I think it is very rare.  So I think by default everyone can has his own interpreter setting and interpreter can be instantiated with this setting.  If user want to share the interpreter across users, then admin can create another interpreter to make it shared across users.  Regarding the implementation, we can have one parent interpreter setting which is controlled by admin, and each user level setting can override the parent setting.

@zjffdu Thanks for sharing your idea and cases. I agree with you what you told about common case. But the main reason to make a config complicated is for keeping backward compatibility which is the most important thing for some users. Then we should think of keeping current behaviour.
Concerning per user interpreter config, I think we must support that feature in order to make Zeppelin fitted in enterprise environment. AFAIK, Another PR proceeds for supporting it.

Thus my idea to handle issues about multi-tenancy is dealt with separately and then will combine them together after finishing them. How about it?

This is because small changes are easy to review and intuitive, thus I always try to make my PR as small as I can.

Agree on we should make PR keep small for review. Otherwise we should make subtask.

@corneadoug I summarize all of unique combination. I think 'Per user' is the first criteria and 'Per note' is the second priority. And I also have a question. Can front-end know if shiro is enabled or not? If it's possible, I have another request that if shiro is disabled, hide 'Per user' option. It's actually useless without shiro and reduces the confusion. thus I appreciate you will make UI support only for the below:
[Per user] - [isolated] and [Per note] - [scoped]
[Per user] - [isolated] and [Per note] - [isolated]
[Per user] - [scoped] and [Per note] - [scoped]
I also thought about the modes above if it's possible or not, and I've figure out the above are possible. And I think that [Per user] - [scoped] and [Per note] - [isolated] doesn't makes sense and I want to disable to set the option like that.
Thanks for your help!!

@jongyoul Yes I think hiding "per user"  make sense, and it can be a fair assumption if user == "anonymous" then shiro is not enabled.

@jongyoul Could you try rebasing this PR?

@corneadoug I'm fixing some conflicts during rebasing it.

@corneadoug Done. :-)

@khalidhuseynov Actually, I'm not sure that Shiro figure out the user information from SecurityUtils. Are you sure that fromMessage->principal has correct information?

@jongyoul I've checked now and SecurityUtils didn't have correct information, and normally message should be having the correct information since routine for authorization based on principal and ticket from fromMessage. Here's the sample logs I got from backend when logged in as admin:
 INFO [2016-10-13 17:00:07,800] ({qtp1620303253-19} NotebookServer.java[getEditorSetting]:1604) - getEditor settings user from SecurityUtils : anonymous
 INFO [2016-10-13 17:00:07,801] ({qtp1620303253-19} NotebookServer.java[getEditorSetting]:1605) - getEditor settings user from message : admin

@jongyoul I can see the perUser on interpreter setting page and shiro is enabled, but there's no response when I click it, do I miss anything ?

@khalidhuseynov Thanks for testing it. I'll change it to get user information from fromMessage.

@zjffdu I have no idea in your case. Are you still suffering from it?

Thank you @cloverhearts for the UI work. Can you share your screenshot for this feature? It can help everyone understand your awesome work!!

Thank you @jongyoul
ui - screenshot.
shiro off (anonymous user)

shiro on (per user)

case
1 You use the shiro on a per-user basis.
2. Set a specific interpreter to per user.
3. Delete the user settings of shiro, it will recover in the anonymous mode.
At this time, Interpreter set to "per user" is converted to all "per note".
"Globally" is, there is no change.

Tested.
I was tested for spark, jdbc, markdown, file and other interpreters.
It's working well.

@jongyoul I still have the issue, not sure why I would hit this weird issue. I can see the perUser/perNote checkbox, but just could not select it.

@jongyoul my mistake, it works now.

@cloverhearts Thank you!!

CI become green and @cloverhearts tested allmost cases. Merging if there's no more discussion.


Logging causes CPU spikes

The debugger logs all WS messages to the console. When messages come in very high numbers and data inside is big, that becomes a performance problem.

Yeah, that was there only for debugging purposes, removing it now.


An error dialog pops up when clicking 'Manage Access Control lists…' for one ADLS Gen2 blob container

Storage Explorer Version: 1.17.0
Build Number: 20210128.6
Branch: main
Platform/OS: ia32/x64
Architecture: Windows 10/ Linux Ubuntu 18.04/ MacOS Catalina
Regression From: Previous build (20210128.3)
Steps to Reproduce

Expand one ADLS Gen2 storage account -> Blob Containers.
Create a blob container -> Right click the blob container.
Click 'Manage Access Control Lists...'.
Check whether the 'Manage Access' dialog pops up.

Expected Experience
The 'Manage Access' dialog pops up.
Actual Experience
An error dialog pops up.

Verified this issue on build 20210129.2. Fixed.

Verified this issue on build 20210129.2. Fixed.


Re-exporting a sub-module

Hello,
I was trying to have my utility functions along with the library function, so I have created a barrel file (index ) to export everything from the files I had and a sub-module of this library, like Record.
When I use TypeScript, there is no type error but I cannot get it work if I have the following setup:
// index.ts file in utility functions folder for Record structures

export * from './some-func-file'
export * from './another-func-file'

// The following does not have any type error
// but does not work when it is compiled
export * from 'fp-ts-std/Record'

We use this exact same pattern at work without issue. What bundler/environment are you using?

We use this exact same pattern at work without issue. What bundler/environment are you using?

I get this error when I want to use these with Jest (ts-jest more accurately).
I'll provide you my configurations now maybe that helps.
tsconfig.json
{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "es2017",
    "sourceMap": true,
    "incremental": true,
    "skipLibCheck": true,
    "noImplicitOverride": true,
    "rootDir": "./",
    "outDir": "./dist",
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false,
    "strict": true,
    "declarationMap": true,
    "moduleResolution": "node",
    "typeRoots": [
      "node_modules/@types",
      "../@types"
    ],
    "paths": {
      "@core": [
        "."
      ],
      "@core/*": [
        "./*"
      ]
    }
  },
  "exclude": [
    "node_modules",
    "dist"
  ]
}

package.json, "jest" section:
"jest": {
    "testEnvironment": "node",
    "setupFilesAfterEnv": [
      "@relmify/jest-fp-ts",
      "jest-extended/all"
    ],
    "moduleFileExtensions": [
      "js",
      "ts",
      "json"
    ],
    "moduleNameMapper": {
      "^@core(.*)": "<rootDir>/..$1"
    },
    "moduleDirectories": [
      "node_modules",
      "<rootDir>"
    ],
    "rootDir": "test",
    "testRegex": ".*\\.test\\.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage"
  }

So I have this configuration and with these, when I try to re-export from the record/index.ts file, along with my additional utility functions, that export is not usable in this way, of course it should work as also there is no type error but I would like to know your ideas about this as well.
This information might be useful:

My project is consisting of two sub-projects, so one is referencing the other (the @core path mapping is because of this).
My jest tests are located in test folder as you can also see in the configuration,

Is this the issue perhaps?: https://github.com/samhh/fp-ts-std/issues/89

#89

Seems so yeah


After updating scoop's Google Chrome it went nuts

Mainly 40+ tabs went into the wild - not saved in history or opened after closing, updating and starting the browser
Next time please test the apps BEFORE added to scoop's ecosystem. Thank you very much

Now more on the problem. If you set
D:\scoop\apps\googlechrome\current\chrome.exe --user-data-dir=d:\scoop\apps\googlechrome\**current**\User
it's ok to expect that scoop will MOVE User subdir from symlinked chromeversiondirname as current to the newer one chromeNEWERversiondirname, not leaving it in the old and waiting chrome to create a new one. In this case scoop MUST move the User dir from 77.0.3865.75 dir to 77.0.3865.90

If you want a portable chrome by setting D:\scoop\apps\googlechrome\current\chrome.exe --user-data-dir=d:\scoop\apps\googlechrome\current\User , please create a new manifest googlechrome-porable or something else. Scoop does not know there is a User directory which need to be persist unless you tell it by persist .

Portable settings configured with parameter are pain for many reason, but main is the obvious one, which will make it unusable.
You cannot set parameter to Window's Default Apps. This will make it junk.

If you open it from start menu / cmd, it will work with parameter.
If some application will spawn & url.url (how all application spawn browser) browser will be opened without parameter, which will result in completely different profile located in AppData
If you set it as open with, then again you have no parameter.

As I already told you in issue before. Chrome is using AppData. This indicates it is not portable by default. You created your own problem, which has no solution, which will fit most users use cases. Create custom manifest in custom bucker for portable chrome, but it will not work as you want.

Already fixed the problem but I'm too lazy to add parameters to the shortcut in C:\Users\UserName\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Scoop Apps :)

https://github.com/lukesampson/scoop/issues/3657#issuecomment-533855636
informative post.
github should have a " informative" reaction.

The final fix to make Chrome somewhat portable in scoop is to associate http and https urls when opened from your mail client or any app that opens them or files with the DEFAULT browser in the system. Just open in the registry HKEY_CLASSES_ROOT\http\shell\open and change the registry at HKEY_CLASSES_ROOT\ChromeHTML.QLSDFSVFTHARQA4CM4IU7I35SY\shell\open\command to be

"yourdrivename:\scoopdirectory\apps\googlechrome\current\chrome.exe" "%1" "--user-data-dir=yourdrivename:\scoopdirectory\apps\googlechrome\yourUserDataDirectory"

instead of

"yourdrivename:\scoop\apps\googlechrome\current\chrome.exe" -- "%1"

https://github.com/lukesampson/scoop/issues/3657#issuecomment-533850089

from https://github.com/lukesampson/scoop/issues/3657#issuecomment-533855636

You cannot set parameter to Window's Default Apps

this applies only if user tries to make google-chrome work in portable mode?

If I remember correctly if you need chrome to output to stdout you must enable logging with a switch after the exe:
chrome.exe --enable-logging --v=1

you must enable logging with a switch

good to know. but i'm talking about what curl.exe -hwould do.

There's no /help or /? switches implemented for chrome.exe


[flutter_tools] Reland: Stage web tests

Description
Enable web tool integration tests: expression evaluation, stepping, and basic hot restart

Had to be temporarily reverted due to an update in the output of the expression compiler


chore(release): 29.0.2

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.6%) to 94.452%

Totals

Change from base Build<PHONE_NUMBER>:
-1.6%

Covered Lines:
3926

Relevant Lines:
4090

💛  - Coveralls


Compute the BuiltinInfo for a builtin call to IRGenSIL; NFC.

The intention here is to make it easier to do specialized lowering for specific builtin arguments.

@swift-ci Please smoke test and merge.


Update Docs for cloud-based EV code signing

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem description
The docs haven't been updated for a year now regarding windows code signing, electron's own docs have however and make reference to windowsSign in forge, but I would love to have examples of how to use windowsSign on forge in combination with MakerSquirrel, as I seem unable to get it working with ssl.com's cloud signing after several months of stumbling in and out of trying 🤡
Proposed solution
Update the docs with examples for;

Certum EV code signing certificate
DigiCert EV code signing certificate
Entrust EV code signing certificate
GlobalSign EV code signing certificate
IdenTrust EV code signing certificate
Sectigo (formerly Comodo) EV code signing certificate
SSL.com EV code signing certificate

Alternatives considered
I tried Electron Forge SSL Code Sign Plugin but it runs too late and doesn't update the RELEASES file, meaning no updates are installed on Windows due to a checksum mismatch.
Additional information
No response

Here's mine that works for SSL.com;
const forgeConfig: ForgeConfig = {
  packagerConfig: {
    // invalid according to typescript... but this is the only place it works
    signToolPath: path.resolve(
      "C:\\Users\\circleci\\project\\CodeSignTool.bat",
    ),
    signWithParams: [
      `-override="true"`,
      `-credential_id="${process.env.WINDOWS_CERT_CREDENTIAL_ID}"`,
      `-username="${process.env.WINDOWS_CERT_USER_NAME}"`,
      `-password="${process.env.WINDOWS_CERT_PASSWORD}"`,
      `-totp_secret="${process.env.WINDOWS_CERT_USER_TOTP}"`,
    ],
  },
};

export default forgeConfig;

I've been trying to use the WindowsSign options with MakerWix. According to the code, the config is just passed directly into MSICreator (https://github.com/electron/forge/blob/main/packages/maker/wix/src/MakerWix.ts#L40) which supports the option (https://github.com/electron-userland/electron-wix-msi/blob/master/src/creator.ts#L74) so maybe it's as simple as updating the MakerWixConfig interface (https://github.com/electron/forge/blob/main/packages/maker/wix/src/Config.ts#L3)?

as my last code snippet said, even though typescript reports it as invalid, i found this the only place to put the signing config that actually picks up the options; packagerConfig

I am also running into a similar situation using an SSL EV certificate and the @electron-forge/maker-squirrel.
I set up the SSL eSigner CKA using the SSL guide to automate with signtool.exe and got it working on its own outside of Forge.
Unfortunately, I need to use the SSL CodeSignTool pre-signing malware scan as well, but I'm not sure how to use it within the Forge build config.

I've also been trying all day to get Squirrel to actually use the windowsSign config that is described in the docs, with no luck.  I'm definitely misunderstanding something here.
Running in the package step is going to cause squirrel's various generated binaries to go unsigned, which isn't going to work for us.


combine efforts?

I somehow didn't see this module on npm before I started working on my own... which are quite similar actually! Do you think you will keep working on this module?  I've been looking for possible alternatives.


Fix USD OutputProcessor errors on USD export in Houdini 20.5+

Changelog Description

Fix beginSave arguments for Houdini 20.5.182+ with added stage_variables argument to OutputProcessor.beginSave method
Additional info

Fixes #53
I tested in Houdini 20.5.278 and 20.0.724; worked for me in both.
Testing notes:

Publish a USD instance from Houdini
No error pop-up should show in Houdini 20.5+ (nor should an error occur in older versions)

No error in 19.5.773


Updated README.md

Push request for first lambda sprint challenge.

Minimum Viable Product
Your finished project must include all of the following requirements:
Homepage

[x] Build the HTML and CSS to create the missing navigation and header.
[x] Link the About navigation item to the about.html page

You will also notice there are 10 boxes on the home page that need background colors.  Use this list below to correctly style each box:

[x] box1: teal
[x] box2: gold
[x] box3: cadetblue
[x] box4: coral
[x] box5: crimson
[x] box6: forestgreen
[x] box7: darkorchid
[x] box8: hotpink
[x] box9: indigo
[x] box10: dodgerblue

About Page
Review the provided design file for the about page. You have been provided the HTML wrapper, footer, and page content for the about page. Create the rest of the missing HTML and CSS to match the design file.

[x] Copy and paste your home page navigation and header into the about page
[x] Update the header image with the about page image
[x] Link the Home navigation item back to the index.html page.
[X] Build the rest of the about page layout to match the design

Stretch Problems
After finishing your required elements, you can push your work further. These goals may or may not be things you have learned in this module but they build on the material you just studied. Time allowing, stretch your limits and see if you can deliver on the following optional goals:

[ ] Build a page of your choosing from the navigation items.  Come up with content and images that fit the theme.
[ ] Introduce CSS animations to your site.
[ ] Build a contact page and create a form with several inputs of your choosing
[ ] Add responsive breakpoints to your code by using media queries

What Looks Great

Great job reaching MVP!
Code is organized, well commented and easy to read.
Commit history is fantastic

Suggested Improvements

Good work completing the project, keep pushing yourself, you're going to do great with this program

Rating
2


Add IFHY by Tyler, the Creator

Song Name
IFHY
Artist Name
Tyler, the Creator
Source
Youtube
Youtube Link
OZ9IELefyeQ
Direct File Link
No response
Song ID
2
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 138

reject
the main level songs are too popular to be replaced by an unrelated nong


can you support Tabbar

although I'm able to get the image on the tabbar i have issues when selected to change the image.

I also have questions about Tabbar usage , how can I use SwiftBarButtonItem instead of UITabBarItem  ?
Thanks!

I'm working on this issue.

SwiftIconFonts support UITTabbar selected image!
Please check Example project or  0x73@295c07f648867fa0f0652ba28e65763169f0ee6b
@IBInspectable var SelectedIcon: String?
@IBInspectable var SelectedIconFontSize: CGFloat = 20.0
@IBInspectable var SelectedIconImageSize: CGSize = CGSize(width: 20, height: 20)
@IBInspectable var SelectedIconColor: UIColor = UIColor.black```


pre-commit: run all pre-commit autoformatting hooks

This is a followup, running the autoformatting hooks defined in .pre-commit-config which was introduced in #1381.
It also includes a .git-blame-ignore-revs file with inline comments of what that is about as suggested by @manics:

When you run pre-commit can you add a .git-blame-ignore-revs too? It's feature in Git that GitHub now supports, and should mean the repo-wide auto-formatting commits are skipped in the blame view:
https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

+1 from me, only comment is that maybe we should use isort instead, since @minrk liked that one for the jupyterhub repo?

sure I don't have strong opinions, just feel like if we're going to go with an autoformatter standard, we should at least standardize on the autoformatter we use haha. These PRs tend to be somewhat disruptive since they often invalidate other open PRs, which is why I thought it might be worth quickly agreeing on something if it was going to be quick. But if you think this will require more conversation then I agree we should just merge this. @consideRatio what do you think?

+1 to merge, with or without isort. There aren't so many files here so the difference should be small.
If you do add isort, you need to add
[tool.isort]
profile = "black"

to pyproject.toml for isort to play nice with black.

Reviewed the blame output with the ignore-refs config. Pretty cool!

Ping @manics @minrk @choldgraf sorry for the noise but I'd love to see this merged so I can take this off my radar.

isort is now used instead of reorder-python-imports
I added a pre-commit hook to use the local script that updates a values.yaml file entry with code from binderspawner_mixin.py
I used that pre-commit hook to generate another commit instead of doing it manually
I've updated .git-black-ignore-revs to mention these commits as commits to ignore when considering git blame.

Yesssss Erik you're awesome 😎


Added https at 8443

Certificate generated using OpenSSL for a year, pass phrase is 'alcoding'. Browser detects as 'Not secure'. Test using the endpoints but point to port 8443.

 Configure HTTPS for the server


Headless clients and kill counts

Basic Information
Mission version: v0.954
Map used:  Tanoa
Mods used: 17:
Enhanced Movement
CBA_A3
BWMod
ace
Suppress
KP Ranks
JSRS SoundMod
JSRS Soundmod - Additional Weapon Handling and Reloading Sounds
Immerse
FA-18 Super Hornet
ATLAS Mod: LHD PLUS
Advanced Urban Rappelling
Advanced Towing
Advanced Sling Loading
Advanced Rappelling
ACEX
ACE3 - BWMOD Compatibility
Dedicated or local game?  Dedicated with 3 Headless clients
GitHub or Workshop mission file?   GitHub
Individual Things
Did you edit anything within the mission files?
I have not made any changes to the mission files
If yes, what did you edit exactly?
Short Issue Description
     (Main Issue:)
     We play every night the kill counts do not seem to be accurate.

     (Side note:)
     Also We would love an option to place greater load onto the headless clients in the server options
     screen as it seems most of the vehicles (400+) get controlled via the server along with a bunch of
     AI, if we could push some more AI onto the Headless clients via the server options menu that
     would be sweet.

Expected Behaviour
    Accurate Kill counts

Steps to Reproduce the Issue
    Playing

Screenshots, Serverlog or any other helpful Information
     Let me know what you would like for information for this issue.

Thanks,
love the mission!

A serverlog would be good concerning your thoughts.
For the behaviour and scripted handling of HCs in Liberation:
The server will run all calculation scripts for production, logistic, saving, FOB data, sector data, etc.
If a HC is connected the HC get's all AI units transfered on the spawn of the units. (except blufor units, which will always be local to the machine of the player who selected the Platoon Leader role)
Example:
https://github.com/Wyqer/kp_liberation/blob/master/Missionframework/scripts/server/patrols/manage_one_patrol.sqf
At line 53
The count which is labeled as "vehicles" (should maybe rename it to prevent confusion like this) isn't the count of "enemy vehicles" or similar. It's the count of vehicles, which is basicly everything which isn't a map object. For example all parts of preplaced military bases on maps (walls, decoration, buildings, etc.).
Real AI is the units counter at the FPS information markers in the bottom left of the map. If you directly start playing with HCs connected, this counter should be much higher at the HCs as on the server (mostly the server state 0 Units).
The server.rpt should show you diagnostics beginning with [KP LIBERATION] [STATS] Source: Server
The HC logs will give you also informations like that in their logs.
With how many players do you play by the way? 3 HCs is very much and mostly not needed. Also concerning HCs "more is better" won't be true. For example we're playing on our international sessions (30-40 players, so we also expanded the playable units count) with one HC and don't have any issues concerning drops or strange behaviour. The event take 5 hours. So if you're not playing with more (which isn't possible as you didn't made edits) you would never need 3 HCs running. Wouldn't improve anything, mostly it'll be worse than running without HC or maybe one HC.
 Do you mean the "player score"? That can be caused (also if you mean the statistics which will be shown after you finished a campaign) by the different locality of units in an MP environment. This isn't anything I've touched since I take over the development but will be optimized during the work on 0.96.
I'm wondering by the way, why you're playing with the ATLAS mod?
And as a heads up -> You can update to 0.955 without loosing any progress, as the savegame is compatible between each 0.95x version. And as you didn't edited anything you could just replace the pbo with the actual one.

you rock sir! so right now its maybe 10 people a night playing at one time, Hope for more in the future :) The dedicated is on a 2012 server with dual quad xeons (x8) at 3.12GHZ along with 1 HC all on 15k drives. I then have a 2nd 2012 server with dual quad xeons (x8) at 3GHZ with the other two HC on 7200 rpm drives running through an IPSEC tunnel to the main host both sites of which have full 1GIG up and down for bandwidth. the HCs are at 4 for a ping so I didn't think this to be a lag issue.
Thanks for explaining the vehicles count, that makes more sense now.
I find if I set the "Maximum amount of AI units" to 150 - 200% the unit cap does not get hit so often and the server then can spawn in more AI as we fly over towns and such. (could be wrong about this)
it is indeed the "player score" that people are having the issue with, they want to see how good they are doing :)
I thought ATLAS was required, but I just went back and see:
"Replaced: ATLAS LHD with USS Freedom. Thanks to Applejakerie for the immersive clutter on the carrier"
so maybe its not needed?
Thanks again for your work on this

No you don't need the Atlas LHD at all anymore. The USS Freedom is free content from BIS so it's better to use that (although we all might agree the USS is worse if it is the final version) instead of require a mod dependency or waste land for a "Chimera" base. :)) I also +1 for a working player score, I've noticed it "misses" a lot of kills too but can happily wait for 0.96 for improvements there.
If you want to use Atlas or Nimitz for example, it's a pretty simple change but that mod will become dependent for the mission to run properly, that's dependent for every client joining too. Happy playing. :))

So for 10 people and 150-200% enemy count I would recommend using one HC on the same machine. (so you shouldn't need the two HCs from the other root) Bandwitdh isn't a problem than, yeah. I would guess that's quite enough to handle a 10 player game with a highter enemy count very good. As long as the FPS of the server and HCs stay in average at about 30, it's totally fine. Even >20 is fine.
But back to the player score topic:
You're running ACE and I guess with medical and cookoff features enabled.
If you don't set the medical functionality will only apply to players and also AI could be unconcious and is affected by the ACE medical system, then you can have problems with the player score concerning Infantry kills. As then sometimes you're not the one who really killed the soldier as it was a script which finally end it.
The cookoff feature from ACE (which is really good in my opinion) is basicly the same as for the infantry with affected ace medical. You shoot an APC, then the fire comes out and shortly after that it explodes. Same here, that the "finishing kill" is made by a script and not by a player.
Here is also a old issue on the ACE GitHub, which is about that:
https://github.com/acemod/ACE3/issues/3111
And maybe you want to try this one than:
https://github.com/acemod/ACEX/tree/master/addons/killtracker


lightning: Updates for pytorch_lightning>=1.6

Closes https://github.com/iterative/dvclive/issues/234

Codecov Report

Merging #256 (98c501b) into main (9602d7f) will increase coverage by 0.15%.
The diff coverage is 100.00%.

:exclamation: Current head 98c501b differs from pull request most recent head d88c8ee. Consider uploading reports for the commit d88c8ee to get more accurate results

@@            Coverage Diff             @@
##             main     #256      +/-   ##
==========================================
+ Coverage   90.27%   90.42%   +0.15%
==========================================
  Files          20       20
  Lines         699      700       +1
==========================================
+ Hits          631      633       +2
+ Misses         68       67       -1

Impacted Files
Coverage Δ

dvclive/lightning.py
92.68% <100.00%> (+0.37%)
:arrow_up:

dvclive/dvc.py
20.00% <0.00%> (+0.64%)
:arrow_up:

Continue to review full report at Codecov.

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


error: unknown option `--disablePrivateOrInternalSupport'

As of https://github.com/compodoc/compodoc/commit/9e4222edc3b9385697f14c603239ab4a9fac70ea
option disablePrivateOrInternalSupport where splitted in
provide flags : --disablePrivate , --disableProtected, --disableInternal, --disableLifeCycleHooks

PR https://github.com/trekhleb/angular-library-seed/pull/15


build login url based on response of login session

the url to the login server is being build based on the response of the login session request

If anyone can confirm this fix is working I can merge it now. Otherwise is has to wait until tomorrow.


feat: implement mockRestoreInitialImplementation and restoreAllInitialMockImplementations

Summary
This is an attempt to cover a commen use case (for me) that I think needs improvement:

There's a bunch of tests in one file
Most tests use the same set of mock implementations
One of the tests needs a custom mock implementation

I would currently solve this in one of two ways:

Use mockImplementationOnce and cross my fingers that the mock is called exactly once
Use a beforeEach that overwrite each implementation one by one. This takes up a lot of space and doesn't work very well with manual mocks.

This PR causes each mock to remember it's initial implementation, and provides a way to restore it, so that:

Initial mock implementations can be used as the "default" implementations throughout a test file.
Individual tests can override one or more implementations if necessary.
The initial implementation can be restored by either:

Restoring each individual mock directly with mock.mockRestoreInitialImplementation()*.
Restoring all mocks with jest.restoreAllInitialMockImplementations()* (possibly in a beforeEach/afterEach hook)

* I'm not 100% happy about these long method names, I would prefer something shorter but still precise.
I don't know for sure if the current commit is enough for jest.mock (and manual mocks) to work, if not, point me in the right direction and I'll do my best to make it work.
Update: This works with jest.mock, and also with manual mocks if they are jest functions - which makes a lot of sense since you would otherwise not be able to override one for a single spec.
I'll be happy to add documentation, additional tests etc. should you decide to like the idea.
Test plan
I added a tests for the two added methods mockRestoreInitialImplementation and restoreAllInitialMockImplementations.

Hi @jeppester, thanks a lot for the PR! I've also come across this case a lot. What I've usually done is to move the initial implementation from the mock declaration into a beforeEach hook as you mentioned.
Pro:

Makes sure the test cases all start with the same mocking behavior, no test case can forget to mockRestoreInitialImplementation
Con:
Slightly more verbose
Does not work for mocks coming from __mocks__

Regarding the pro: I would very much like to preserve that and not encourage a structure where it is easy for one test case to mess everything up. However it's not a deal breaker for me if there are significant upsides to the new approach.
Regarding the second con: Closing this gap might be a significant upside of mockRestoreInitialImplementation. However, I'm wondering how often it would actually be needed, because defining mock implementation in __mocks__ is usually something you do to avoid repeating yourself everywhere for mocks that will always behave the same - if a mock is supposed to have different behaviors it'll likely not be extracted into __mocks__.
Thoughts @SimenB @thymikee @jeppester?

Codecov Report

Merging #9270 into master will increase coverage by 0.05%.
The diff coverage is 80%.

@@            Coverage Diff             @@
##           master    #9270      +/-   ##
==========================================
+ Coverage   64.93%   64.99%   +0.05%
==========================================
  Files         278      278
  Lines       11905    11895      -10
  Branches     2935     2927       -8
==========================================
  Hits         7731     7731
+ Misses       3544     3535       -9
+ Partials      630      629       -1

Impacted Files
Coverage Δ

packages/jest-mock/src/index.ts
77.68% <100%> (+0.59%)
:arrow_up:

packages/jest-runtime/src/index.ts
66.91% <25%> (-0.43%)
:arrow_down:

packages/jest-environment-node/src/index.ts
50% <0%> (-1.17%)
:arrow_down:

packages/jest-snapshot/src/utils.ts
95.29% <0%> (-0.32%)
:arrow_down:

packages/expect/src/index.ts
84.92% <0%> (-0.24%)
:arrow_down:

...ackages/jest-jasmine2/src/assertionErrorMessage.ts
0% <0%> (ø)
:arrow_up:

packages/jest-snapshot/src/State.ts
0% <0%> (ø)
:arrow_up:

packages/jest-circus/src/formatNodeAssertErrors.ts
12.96% <0%> (+1.09%)
:arrow_up:

packages/jest-snapshot/src/inline_snapshots.ts
81.81% <0%> (+1.42%)
:arrow_up:

Continue to review full report at Codecov.

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

Hi @jeysal.
Thank you for the quick feedback!
After having tested the code with a manual mock, I'm not sure that there's a gap for close there. It appears to be working just fine - If you have some specific issue in your mind, please let me know, and I'll add a test for that.
Here's how I've tested it (added to transform/multipleTransformers - since I wanted a setup with react):
In src/Test.js:
import React from 'react';

export default () =>
Real
;

In src/__mocks__/Test.js:
import React from 'react';

export default jest.fn(() =>
Mock!
);

In __tests__/manual-mocks.test.js:
jest.mock('../src/Test');

import Test from '../src/Test';

describe('mockRestoreInitialImplementation', () => {
  beforeEach(() => {
    Test.mockRestoreInitialImplementation();
  });

  it('allows a test to override the manual mock', () => {
    Test.mockImplementation(() => Changed for a single spec!);

    const tree = renderer.create(<Test />).toJSON();
    expect(tree.children).toEqual(['Changed for a single spec!']);
  });

  it('allows a following test to still have the manual mock', () => {
    const tree = renderer.create(<Test />).toJSON();

    expect(tree.children).toEqual(['Mock!']);
  });
});

transform/multipleTransformers is obviously not the right place for this tests, but I'm not entirely sure where to put it, since there's currently no folders for manual-mocks  in the e2e-folder.
Should I add a new e2e test folder or is there already a fitting place for such a test?

Sorry if my message was not ideally structured, "Pro" and "Con" referred to the "what I've usually done" here

Sorry if my message was not ideally structured, "Pro" and "Con" referred to the "what I've usually done" here

Now I understand your feedback much better :smile: - thank you for clarifying.
The pro you've mentioned is definitely a good thing, I do however not agree that it's better than having a beforeEach with restoreAllInitialMockImplementations. And the latter will additionally save you many lines.
I think a lot of people currently start out with a bunch of mocks using jest.mock('path/to/module', () => jest.fn(someImplementation))).
If you start out that way, and you at some point discover that someModule.mockImplementation is permanent, then I don't think it's more obvious to move all implementations to a beforeEach, than I think it is to add a beforeEach with restoreAllInitialMockImplementations, especially if you've already been using clearAllMocks/resetAllMocks/restoreAllMocks.
At least it wasn't obvious to me, and my search for a way to rewind my test-local mock changes is what eventually lead to this PR.
In regards to manual mocks, I haven't used them enough to make a good judgement on how often you would need this feature.
I do however think it's really nice if this feature will prevent manual mocks from having an annoying downside that you might not discover until you have a test where it makes a lot of sense to replace a mock implementation.

I think you've convinced me, especially with the starting out and later discovering you need to restructure thing that I can very much relate to :smile:
To mitigate the potential problem of forgetting to restore the initial impl at the end of a test, maybe we can just write docs that encourage a beforeEach pattern not susceptible to this.
Would be interested what other maintainers think about the API in general before getting into detail review @SimenB @thymikee

Just to clarify how this will improve the current state of things.
Say you have the following code somewhere near the top of your file:
jest.mock('./module1', mockImplementation1)
jest.mock('./module2', mockImplementation2)
jest.mock('./module3', mockImplementation3)
jest.mock('./module4', mockImplementation4)

Now you want to change module3 for a single test.
Currently you have the following options:

If you want to save a few lines:

jest.mock('./module1', mockImplementation1)
jest.mock('./module2', mockImplementation2) implemenation
jest.mock('./module3')
jest.mock('./module4', mockImplementation4) //

import module3 from './module3'
import module4 from './module4'

beforeEach(() => {
  module3.mockImplementation(mockImplementation3)
})

If you want to keep all your implementations close to each other:

jest.mock('./module1')
jest.mock('./module2')
jest.mock('./module3')
jest.mock('./module4')

import module1 from './module1'
import module2 from './module2'
import module3 from './module3'
import module4 from './module4'

beforeEach(() => {
  module1.mockImplementation(mockImplementation1)
  module2.mockImplementation(mockImplementation2)
  module3.mockImplementation(mockImplementation3)
  module4.mockImplementation(mockImplementation4)
})

With restoreAllInitialMockImplementations you can instead have:
jest.mock('./module1', mockImplementation1)
jest.mock('./module2', mockImplementation2)
jest.mock('./module3', mockImplementation3)
jest.mock('./module4', mockImplementation4)

beforeEach(() => {
  jest.restoreAllInitialMockImplementations()
})

This PR has been waiting for feedback for soon 3 years.
I believe that the issue I was trying to solve is still in jest, I don't think this PR is less relevant today that when it was made.
It would be nice if someone would finally have a look at it.
What are you thoughts @SimenB and @thymikee? (If you are still maintainers)

I'm a bit reluctant to add more APIs here as I don't see a big advantage to it, and our reset, clear and restore APIs already confuse people (including myself). Specifically the one "current way" you point out is what I think the correct solution to your use case is:

Use mockImplementationOnce and cross my fingers that the mock is called exactly once

You don't have to cross your fingers, you can just use expect(myMock).toHaveBeenCalledTimes(1) (or however many times you call mockImplementationOnce as they stack until exhausted) at the end of your test.

our reset, clear and restore APIs already confuse people (including myself)

I'm absolutely with you here. It's the one part of jest that I just can't get right 100% of the time.
I can see why those names where chosen -for simplicity, but more verbose names would help a lot, like for instance "resetCalls" and "clearImplementation".
For that reason I was never 100% happy about my own suggestions here, as they might at another layer of confusion.

they stack until exhausted) at the end of your test.

While this is useful it adds a layer of often unnecessary complexity when testing something that might call the mock a number of times, especially if the number of times is hardly relevant to the test. That the method has built-in stacking is also counterintuitive in my opinion.
How would you feel about an API on that mock that would set af specific implementation, then run a callback, and finally reset the mock to whatever it was.
Something like ```js
mock.withImplementation(implementation, () =>
{
Logic using the temporary implementation
})

I'm not entirely sure that this idea i perfect (for instance how it would fare with multiple mocks -maybe well with decorators?). Ab API like that would however be very intuitive IMO, and not add to the reset/clear/restore confusion at all.

What are your thoughts?

It'd have to be async I guess, but other than that I think I like it! As you say it'd probably not work too well with multiple mocks, but then again, you can probably nest them within each other?

It'd have to be async I guess, but other than that I think I like it! As you say it'd probably not work too well with multiple mocks, but then again, you can probably nest them within each other?

It's the nesting that might become a little bit too much indenting, but I'll give the idea a go and make a new PR.
I would prefer to keep this open until I have another one ready - hopefully already some time this week.

@SimenB
I've created a new PR for withImplementation https://github.com/facebook/jest/pull/13281
I'll close this PR as I believe withImplementation solves same issue as this PR, but (in most cases) in a better way.


Toggle per api rate limiting option does not work in Operation Governance for resources

Description:
After clicking the "Toggle per api rate limiting", it does not perform any action.

Affected Product Version:
API-M 4.0.0 Alpha

'Toggle per api rate limiting' button will scroll the page to the top (Scroll to the Operations Configuration section) where the user can manually select API Level.

There are a few UX issues for this feature.

Toggle per api rate limiting wording is incorrect it should change to 'Change Rate Limiting Level'
When Operation level is selected there is no additional action needed in the Rate limiting policy selection hence this option  is only needed at when API Level is selected
In order to make the experience better we can focus the operation level  radio option


plugin gauge java not recognized after installation

After performing the installation of java plugin, the gauge is not recognizing it , following images :

Configuration:
Ubuntu 14.04.3 LTS
Java version "1.8.0_66"
Gauge version: 0.2.1
Please , any suggestions?
Thank you !

Welcome to Gauge!
Sorry to hear about the issue. Could you please confirm if java folder is present in the ~/.gauge/plugins/ directory?

Thank you and congratulations on the excellent work in the gauge !
So, yes the older is present.

The presence of this folder indicates Gauge java plugin is installed. Could you please try running the command gauge -v once more and check?

Strange ... now the plugin was displayed !!!

When I open a new section of the terminal, the gauge continues to inform that the plugin was not installed :-(

Any possible suggestion for the random behavior ?!!?!

That's strange.
Could you please logout and login once? This will ensure that Gauge related environment variables are set across all shells.

did not work :-(

Hi @israel-santiago-praxis,
Gauge can be installed globally across the system by doing sudo ./install.sh. But Gauge plugins are installed in user's home directory.
If you have installed plugins via some other user or by using sudo, you won't be able to access them by doing gauge -v. Could you please ensure that you are installing plugins and running Gauge from the same user (without sudo)?
P.S. You don't need to use sudo for installing plugins.

I had the same issue. Removing the directory, re-installing without sudo, and then restarting my terminal session resolved it.

As @xmeltrut mentioned, you can hit this issue if you use different users to install the plugins and run gauge. Using sudo uses the root user's settings, so it will try to look for .gauge/ dir in the home directory of root.
I'm closing this for now. Please reopen if you have further concerns.

Problem resolved ! Thanks a lot !


[Datagrid] Filter panel state does not update after changing filters with setAllFilters function

What package(s) are you using?

[x] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)
[ ] Legacy/CDAI
[ ] Legacy/Security

Detailed description

Describe in detail the issue you're having.

After manually updating the filters via setAllFilters from https://react-table-v7.tanstack.com/docs/api/useFilters#instance-properties, the internal filter state is update within datagrid but the filter panel does not reflect those changes. Filters show previous state.

Is this issue related to a specific component?

Datagrid, filter panel

What did you expect to happen? What happened instead? What would you like to
see changed?

Exception is that the filter panel re-renders with the updated state after changing the filters with setAllFilters.
The <FilterSummary/> component reflects the changes correctly.

What browser are you working in?

Chrome

What version of the @carbon/ibm-products (or @carbon/ibm-cloud-cognitive)
package are you using?

1.51.0

What offering/product do you work on? Any pressing ship or release dates we
should be aware of?

CP4WAIOps
Steps to reproduce the issue

Render a table with the filter panel enabled
Apply filters
Attempt to pragmatically change the filters using setAllFilters
Notice that datagridstate.state.filters and <FilterSummary/> update accordingly while the filter panel keeps the previous selections. (i.e. previous checkboxes checked etc.)

Additional information

Screenshots or code
Notes

Re-opening of https://github.com/carbon-design-system/ibm-cloud-cognitive/issues/2913 based on discussion with @AlexanderMelox

@xmannyxfreshx1 Can you let us know if we’re able to close this issue? Hoping the current release resolves this. 🙏

@elycheea This was resolved in #3024 #3042


@azure/storage-blob generateSasUrl  Invalid permission: [

Package Name:  @azure/storage-blob
Package Version: 12.9.0
Operating system :windows
[x] nodejs : true

version: 14

[ ] browser: chrome

name/version: Version 100.0.4896.75 (Official Build) (64-bit)

[x] typescript: true

version:4.3.5

Is the bug related to documentation in

[ ] README.md
[ ] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

Describe the bug
When trying to use generateSasUrl in getting an exception: Invalid permission: [
To Reproduce
Steps to reproduce the behavior:

create an azure container
upload file to that container
create a permission object for generateSasUrl function.
try to create generateSasUrl to generate the URL to that file.

The above bug accrues because somewhere in your code you try to use toString on the permission object that needs to be sent to generateSasUrl
Expected behavior
creating a URL to that file
Screenshots

Additional context

@amitShimon1983 are you passing a simple object to as the permission? The SDK expects an instance of the class BlobSASPermission, not just any objects.  We have this issue to track the improvement in this scenario https://github.com/Azure/azure-sdk-for-js/issues/18799


The current data loading method poses a risk of memory leakage

Currently, the data loading method, as shown in the following line, may pose a risk of memory leakage:
https://github.com/autonomousvision/LaRa/blob/c32ae7704faee3423634ba226eefc4dda644f8f5/dataLoader/gobjverse.py#L129
When I use a similar approach, i.e., obtaining the handle of the HDF5 file during dataset initialization and loading data iteratively, I noticed that my memory usage keeps increasing. I analyzed that this is because the handle is not closed, causing the data to remain in memory. Using the with statement to load data can resolve this issue.

Thanks for pointing out this, it would be very helpful if you could submit a pull request, thank you!