TODO 2018/07

07/02 - 05

[x] https://github.com/rstudio/rticles/issues/178

07/06

[ ] Add icons for external links, e.g. https://rmarkdown.rstudio.com/formats.html
[ ] 雪宁 R 书序
[ ] Build TinyTeX for Windows/Ubuntu/macOS on the cloud.
[ ] Use TinyTeX on Travis for macOS: https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script/r.rb
[ ] An RStudio addin for bookdown to manage section IDs.
[ ] https://github.com/rstudio/bookdown/issues/544
[ ] Announce tinytex in RStudio blog.
[ ] Typora

07/11

[ ] 雪宁 R 书序
[ ] Build TinyTeX for Windows/Ubuntu/macOS on the cloud.
[ ] Use TinyTeX on Travis for macOS: https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script/r.rb
[ ] An RStudio addin for bookdown to manage section IDs.
[ ] https://github.com/rstudio/bookdown/issues/544
[ ] Announce tinytex in RStudio blog.
[ ] Typora

07/13

[ ] Announce the R Markdown book in the blog.
[ ] 雪宁 R 书序

07/16

[ ] New bookdown.org website based on blogdown
[ ] Build TinyTeX for Windows/Ubuntu/macOS on the cloud.
[ ] Use TinyTeX on Travis for macOS: https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script/r.rb
[ ] An RStudio addin for bookdown to manage section IDs.
[ ] https://github.com/rstudio/bookdown/issues/544
[ ] Announce tinytex in RStudio blog.
[ ] Typora

07/24

[ ] Improve animation support in knitr https://github.com/yihui/knitr/issues/762
[ ] Build TinyTeX for Windows/Ubuntu/macOS on the cloud.
[ ] Use TinyTeX on Travis for macOS: https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script/r.rb
[ ] An RStudio addin for bookdown to manage section IDs.
[ ] https://github.com/rstudio/bookdown/issues/544
[ ] Announce tinytex in RStudio blog.
[ ] Typora

07/27

[ ] Improve animation support in knitr https://github.com/yihui/knitr/issues/762 https://github.com/yihui/animation/issues/118 https://github.com/thomasp85/gganimate
[ ] Build TinyTeX for Windows/Ubuntu/macOS on the cloud.
[ ] Use TinyTeX on Travis for macOS: https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script/r.rb
[ ] An RStudio addin for bookdown to manage section IDs.
[ ] https://github.com/rstudio/bookdown/issues/544
[ ] Announce tinytex in RStudio blog.
[ ] Typora


How to reproduce the result of verification from the analyzer using only the predictor from it?

Hi! First of all, thank you for your work, it looks great.
I encountered some problems with reproducing results of face verification using it out of the pipeline that is implemented in the analyzer class.
The reason why I want to use only the predictor but not the whole pipeline is that I have already implemented the face detector and I want to verify faces between each other, so I don't need most of the functionality that is present in the analyzer.
And the problem is that scores of cosine similarity of output from the analyzer and single predictor are different, and it breaks the verification.
Here is the code that I use:
`    test_img = cv2.imread('./database/17/17_01-00-399.jpg')
test_img_2 = cv2.imread('./database/13/13_00-09-199.jpg')
# #13/13_00-09-199.jpg

device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")

path_img_input='./database/17/17_01-00-399.jpg'
path_img_input_2 = './database/13/13_00-09-199.jpg'
path_img_output="/test_output.jpg"
path_config="gpu.config.yml"

test_img = np.transpose(test_img, (2,0,1))
test_img = np.expand_dims(test_img,axis=0)
test_torch = torch.Tensor(test_img)
test_torch = test_torch.to(device=device, dtype=torch.float32)
test_torch_r = test_torch
test_torch = test_torch/255

test_img_2 = np.transpose(test_img_2,(2,0,1))
test_img_2 = np.expand_dims(test_img_2, axis=0)
test_torch_2 = torch.Tensor(test_img_2)
test_torch_2 = test_torch_2.to(device=device, dtype=torch.float32)
test_torch_2 = test_torch_2/255

cfg = OmegaConf.load(path_config)

predictor = instantiate(cfg['analyzer']['predictor']['verify'])
analyzer = FaceAnalyzer(cfg.analyzer)

responce_a = analyzer.run(path_image=path_img_input,
    batch_size=cfg.batch_size,
    fix_img_size=cfg.fix_img_size,
    return_img_data=True,
    include_tensors=True,
    path_output=path_img_output,)
responce_a2 = analyzer.run(path_image=path_img_input_2,
    batch_size=cfg.batch_size,
    fix_img_size=cfg.fix_img_size,
    return_img_data=True,
    include_tensors=True,
    path_output=path_img_output,)

responce = predictor.run(test_torch)[0].logits
responce_2 = predictor.run(test_torch_2)[0].logits

vec_1  = responce_a.faces[0].preds['verify'].logits
vec_2 = responce_a2.faces[0].preds['verify'].logits

sim = cosine_similarity(vec_1, vec_2, dim=0)
sim_3 = cosine_similarity(responce, responce_2, dim=0)

print(sim)
print(sim_3)

`
And as result i get
tensor(0.3768, device='cuda:0')
tensor(0.0573, device='cuda:0')
So predictor by itself doesn't work.
Thank you in advance.

Hi, I had a quick look at the code you provided and I think that the problem might be in the order of colors. Cv2 imread returns a BGR image array while the face verification model works with RGB. Try to change the order of channels in your test_torch tensors using the rgb2bgr function from facetorch.utils module (it also works for bgr2rgb) and let me know if that provides the correct results.

Thank you for your response.
I have tried to change the order of channels. But it didn't help.
Here is the new results:

tensor(0.1691) result of analyzer
tensor(0.6214) result of predictor

Result of analyzer is different, because i have picked different photos.

Alright, thanks for trying to change the order of colors. I have some additional questions that could help me say what the issue is:
Which result makes more sense to you? Are the faces from the two images one person or different people?
Do the images contain single cropped-out faces? What's the resolution of these images?

FaceAnalyzer resizes the input images to 1080 x 1080 resolution using the ImageReader. The results might be different if your input image is much smaller, which might be true for cropped-out faces.
Change the size of the ImageReader Resize transform in /conf/analyzer/reader/default.yaml to the length of the longer side of the specific input image.

path_config="gpu.config.yml"

Hello, how did you write the configuration file? Can you tell me about it? Thank you

path_config="gpu.config.yml"

Hello, how did you write this config file? Could you please tell me about it? Thank you very much！

You can use the merged config file  or its GPU version located in the same directory.


Adjust significant figures for max depth and clarity

For lake_metadata.csv file, from Sam:

There are 4 sig figs in max_depth – too many?
There are a lot of sig figs in clarity – too many?

I am comfortable with 3 for max_depth and 4 for clarity
library(tidyverse)
metadata <- read_csv("out_data/lake_metadata.csv")

max_depth_vals <- sort(metadata$max_depth)
max_depth_low <- head(max_depth_vals, 3)
max_depth_high <- tail(max_depth_vals, 3)

kw_vals <- sort(metadata$clarity)
kw_low <- head(kw_vals, 3)
kw_high <- tail(kw_vals, 3)

# What would happen to the high max_depth values?
> max_depth_high
[1] 140.0000 141.4272 148.0000

> signif(max_depth_high , 4)
[1] 140.0 141.4 148.0

# What would happen to the low max_depth values?
> max_depth_low
[1] 0.004863743 0.015110260 0.017341048

> signif(max_depth_low , 4)
[1] 0.004864 0.015110 0.017340

# What would happen to the high clarity values?
> kw_high
[1]  24.54118  28.33333 112.42847
> signif(kw_high, 4)
[1]  24.54  28.33 112.40

# What would happen to the low clarity values?
> kw_low
[1] 0.1574074 0.2221881 0.2266667

> signif(kw_low, 4)
[1] 0.1574 0.2222 0.2267


Pagination bug: blog-list template pagination counts all markdown pages instead only blog-post ones.

To reproduce an issue:
In the gatsby-node.js change the "postsPerPage" to a smaller value, e.g. 4.
Then after rebuild go to the blog-list page (/blog) and you'll see that the last page in pagination is empty.

Thank you @t-fan-slavik, we have merged your pull request 👍


Library src and dist improvements

dist shouldn't be published to source-code in github
src shouldn't be published with npm package
module is not a recognized property in package.json specs

References:

<EMAIL_ADDRESS>https://docs.npmjs.com/files/package.json

Hi there,
Actually, module is respected by Webpack and Rollup. It's the entry point for ES modules, which enhances tree shaking.
And I'm storing the dist directory in git simply for quick access of compiled byte size. Since I've "marketed" lightweightedness, this is my proof.
Thanks for taking the time to address these though! =) The first is fairly new and the second is simply a per-module preference.

Thanks for you interesting notes. I'll check them :wink:


Consider an alternative way to bring "AlwaysIncludeClaimInIdToken" feature back

I think adding a list to the client with the claims (or maybe scopes?) to include is the MVP.


python312Packages.google-cloud-resource-manager: 1.12.5 -> 1.13.0

Changelog: https://github.com/googleapis/google-cloud-python/blob/google-cloud-resource-manager-v1.13.0/packages/google-cloud-resource-manager/CHANGELOG.md

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 351382

x86_64-linux

:white_check_mark: 4 packages built:

python311Packages.google-cloud-resource-manager
python311Packages.google-cloud-resource-manager.dist
python312Packages.google-cloud-resource-manager
python312Packages.google-cloud-resource-manager.dist


update to SvelteKit 330

This PR is auto-generated by a nightly GitHub action.  It should automatically be merged if tests pass.

@georgeoffley this dependency update broke swyxkit - there is no longer any /blog page for some reason. mind taking a look if you are free?

@sw-yx I got a mention about broken deps from this PR. Was that something you already took care of?

yes george! i went and fixed it myself since i had some time

yes george! i went and fixed it myself since i had some time

Awesome, thanks for letting me know!


change models for visualizations

This pull request changes models for visualizations based on feedback.

@tcnichol
Should we change "vizconfig" in 29 in isualization_config.py to "visualization_config" may be?

Could you resolve merge conflict?


Design: Card headline misalignment

Inconsistent use of "tags" within a cluster of cards results in the visual misalignment of headline links.
Acceptance criteria:

[ ] Card tag position doesn't cause visual misalignment of headline links
[ ] Card dimensions to use new desktop and mobile grid

Can this be done as part of a Card v2? The "misalignment" is not an actual issue but a visual preference.


AminaG. Create a valid Israel ID

AminaG. Create a valid Israel ID.
I have create the function, and the tests.
You can also test it here:
http://www.flex.co.il/Calculators/מחשבון-ספרת-ביקורת-תעודת-זהות.aspx

I am fixing the Failed test (missing semicolons)

This is ready to be merged.
Thank you :)

I wonder if we should take this opportunity to create a more robust method.
For example, instead of: israelID, cpf, ssn, sin, rut...
Have chance.citizenshipID({"country":"IL"});

I think that we don't have enough countries yet. Let's merge this, and when we have at least 4 countries we can make the chance.citizenshipID metho.

Thanks!!
As I've mentioned in other issues, we need a better localization strategy both for getting data (like @somejeff suggests) and for making the library small for the browser when a developer doesn't need all of these localized I'd generators and just wants lightweight Chance.


Fix gradients for onesLikes / zerosLike

Fixes https://github.com/tensorflow/tfjs/issues/1398
BUG

This change is

FYI I am on vacation this week, this fix is fine for now but we should really fix this properly by stopping gradient propagation when we have null gradients @dsmilkov

https://github.com/tensorflow/tfjs/issues/619 tracks the special "null" for gradients.


Add contraction path cache in batch_tensor_contraction, support cotengra

Looks good, this will be very helpful.
One thing we could try is moving the set of commands in the CI for installing AutoHOOT and cotengra into a file deps/build.jl, which Julia will run as a build step when the ITensorNetworkAD gets installed. Similar to the discussions here:
https://discourse.julialang.org/t/pycall-pre-installing-a-python-package-required-by-a-julia-package/3316
https://gist.github.com/Luthaf/368a23981c8ec095c3eb
This would make it easier for people to test out the package. We can leave that for a future issue.


Prevent dropdown from opening when disabled

Currently when the dropdown gets the disabled prop it sets the disabled class. The default disabled styling in SUI-css has the rule pointer-events: none which prevents the dropdown from opening by preventing mouse events. However this has two downsides:

You can't use a Popup on a disabled dropdown because the Popup depends on mouse events to trigger.
This only prevents opening on mouse events. The dropdown still opens when tab-focused (screenshot of disabled but open via focus):

Here's the example on codepen: http://codepen.io/jeffcarbs/pen/yVLgJv?editors=0010
We should prevent the dropdown from opening when in the disabled state in the component itself. FWIW, SUI-core handles this correctly: https://github.com/Semantic-Org/Semantic-UI/blob/master/src/definitions/modules/dropdown.js#L3144-L3146
Some thoughts in terms of how to handle this:

Preventing the open state from being set to true will be tough, if not impossible, given it's an auto controlled component.
We could just prevent the menu from opening by changing const menuClasses = open ? 'visible' : '' to const menuClasses = (open && !disabled) ? 'visible' : ''.

There's a lot of logic happening that's purely dependent on the open state.
It would be weird for state to be open and the menu to not be open.
Not sure why someone would want to, but you wouldn't be able to manually set open AND disabled at the same time. I guess I could see displaying a disabled notifcation in-menu or something.

I'm kinda leaning 1, with the idea that SUI-react (in the uncontrolled usage) won't set state to open if disabled. However, we won't prevent the user from setting it to open in the controlled state if they choose to.
Thoughts?
cc @levithomason  @layershifter

We should prevent the dropdown from opening when in the disabled state in the component itself.
...
I'm kinda leaning 1, with the idea that SUI-react (in the uncontrolled usage) won't set state to open if disabled. However, we won't prevent the user from setting it to open in the controlled state if they choose to.

Agreed.
As a side note, the menu should really have its own active or open prop as well.  Currently, we're passing classNames down which is against our props API.


chore: Update Alpine download mirror

This PR updates the Alpine Linux mirror from nl.alpinelinux.org to dl-4.alpinelinux.org due to inconsistency issues in the package index that causes builds to fail.  This new site is officially listed in the mirror list at https://mirrors.alpinelinux.org/#mirror3 while the old one no longer is.
Signed-off-by: Bryon Nevis<EMAIL_ADDRESS>PR Checklist
Please check if your PR fulfills the following requirements:

[X] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[X] I am not introducing a new dependency (add notes below if you are)
[ ] I have added unit tests for the new feature or bug fix (if not, why?) N/A
[ ] I have fully tested (add details below) this the new feature or bug fix (if not, why?) N/A
[ ] I have opened a PR for the related docs change (if not, why?) N/A

Testing Instructions
make docker
New Dependency Instructions (If applicable)

Approving based on approval by @AlexCuse to address PRs failing.


Android Webview supports H2 on V50.

Fixed by https://bugs.chromium.org/p/chromium/issues/detail?id=329681 upstream.

Thanks!


Split off cli into separate binaries

This changeset splits the cli into 3 different executables to improve test coverage and allows to have featureset composable.
WIP as needs docs , samples and manual QA still

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@11158a1). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #37   +/-   ##
=========================================
  Coverage          ?   12.80%
=========================================
  Files             ?       14
  Lines             ?      937
  Branches          ?        0
=========================================
  Hits              ?      120
  Misses            ?      799
  Partials          ?       18

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 11158a1...2fe8b2f. Read the comment docs.

manual QA is ok, missing docs/examples, but can be done likely in a follow-up


resetChunksCorrupt calls hSetFileSize on closed handle

I'm upgrading shake and got this error:
11:09:41 Shake database version changed (either shake library version, or shakeVersion):
11:09:41   File:         _make/linux.gcc.release.x86_64/.shake/.shake.database
11:09:41   Old version:  E-DATABASE-11-2.1
11:09:41   New version:  SHAKE-DATABASE-14-linux-x86_64-2.1
11:09:41 All rules will be rebuilt
11:09:41
11:09:41 x: x/.shake/.shake.database: hSetFileSize: illegal operation (handle is closed)

It looks like resetChunksCorrupt doesn't use the intended handle when doing its work.

@ndmitchell can we get a release with this fix in?

0.19.7 now released with this change in (sorry it took so long)


Update translations.js

Added Russian translate

Looks like I missed this, thank you for your contribution! :)


Example generic listener

As per program.cs;
    /// <summary>
    /// GenericListener is an example of using Brighter with C# generics to reduce the boilerplate
    /// code required to listen to messages (usually events) in a system. One usage of this might be to
    /// capture all events in a system and feed into a backing store such as EventStore to then perform
    /// Complex Event Processing (CEP).
    ///
    /// Typically for each message a Brighter solution will require;
    ///     DataType POCO
    ///     DataType Handler
    ///     DataType MessageMapper
    ///
    /// If you are aiming to listen to (for example) 60 events in your system this effectively means
    /// 180 C# class files, and potentially each with custom mapping code.
    ///
    /// Taking the notion that any backing store - such as EventStore - will store in a schemaless JSON
    /// it is redundant to deserialize a messsage off a qeueue into a POCO, only to serialize back into
    /// JSON. As such it is possible to imagine you can have a generic mapper and/or handler that can
    /// deal with the majority of event objects.
    ///
    /// In the instance where a custom version of a mapper and/or handler is required for a particular
    /// object type, or type for which it's derived from, this solution somewhat cruedly aims to hoist
    /// those accordingly.
    ///
    /// public class MyEvent : Event(StoredEvent) {}
    /// public class MySuperEvent : MyEvent {}
    /// public class MyDuperEvent : MyEvent {}
    ///
    /// For example;
    ///
    /// RegisterGenericHandlersFor<MyEvent>(config);
    ///
    /// The above will look for all derived types of MyEvent and select handlers and/or mappers based on;
    ///
    /// 1. Match Type implementing IAmMessageMapper<MySuperEvent>
    /// 2. Create Type of MyEventMapper<T> implementing IAmMessageMapper<T> where T is MySuperEvent
    /// 3. Create Type of GenericMapper<T> implementing IamMessageMapper<T> where T is MySuperEvent
    /// 4. .. do the same for IHandlerRequests<>.
    ///
    /// Thus to listen to an additional event;
    ///
    /// 1. Add connection to <serviceActivatorConnections /> with DataType (e.g. MySuperEvent)
    /// 2. Add class in an inheritence chain that suits (e.g. public class MySuperEvent : MyEvent {})
    /// 3. Optionally add MyEventMapper<T> (if not exists) or MySuperEventMapper : IAmMessageMapper<MySuperEvent> {}
    /// 4. Optionally add MyEventHandler<T> (if not exists) or MySuperEventHandler : IHandleRequests<MySuperEvent> {}
    /// </summary>

@iancooper @holytshirt Ready for review, can happily squash these down and merge in manually if you give the go-ahead!


[wip] Add ownership reconciliation based on labels

[x] Given specific labels of objects controlled by hive, ensure that the
controller owner of the object is correctly set.

[x] If an object's owner doesn't exist, add it.
[x] If an object's owner is set incorrectly, fix it.
[x] If an object's owner is set correctly, do nothing.

[x] Manually test the above scenarios
[x] Check that calls match up with documented unique labels
[ ] Add unit tests

Add ownership reconciliation based on labels

What are your thoughts on adding watches to controllers for the owned resources? For example, if there is a change to the merged pull secret, then it would be nice if the clusterdeployment were resynced. This is probably not too important for an owner that is updated often like clusterdeployment, but may be more important from something like clusterprovision.

I like the idea of immediate reconciliation of owner references.
We previously shied away from watching secrets because it would balloon our cache. Not sure if we're watching secrets now or not, but I know we discussed and rejected the idea in the past.  @dgoodwin what are your thoughts on this?
At any rate, @staebler if we decide to do that, would you mind if we do that as a separate PR / card? I feel this PR / card is already late. :)

I don't think we watch Secrets today, at least not anywhere I can find in a quick grep, and there are 6-8k in some of our envs. Definitely something we'd have to tread lightly with.

I am good with postponed any additional changes to add watches.
As for caching, the controller-runtime caches every type that you Get or List already. So even if we are not explicitly watching, there is an implicit watch that is already being done.

As for caching, the controller-runtime caches every type that you Get or List already. So even if we are not explicitly watching, there is an implicit watch that is already being done.

For posterity, we discussed this in stand up today and if we can confirm that we're already caching all secrets because of our Get calls on secrets, then the team is ok with watching secrets.
However there were multiple anecdotal experiences on the team where watching secrets caused the memory of other controllers to balloon and cause problems.

As for caching, the controller-runtime caches every type that you Get or List already. So even if we are not explicitly watching, there is an implicit watch that is already being done.

For posterity, we discussed this in stand up today and if we can confirm that we're already caching all secrets because of our Get calls on secrets, then the team is ok with watching secrets.
However there were multiple anecdotal experiences on the team where watching secrets caused the memory of other controllers to balloon and cause problems.

FWIW, I don't remember specifically that cloud-cred-operator needed its memory allowance increased b/c of watching secrets. It could very well be that the increased memory was just as much a result of doing Get()s on secrets.

@staebler feedback addressed. PTAL

Let me know if you feel strongly about this and I'll revisit it.

Nope. I don't feel strongly about it. Leave it as is.


Typhoon + Carthage => "Typhoon.Framework/Typhoon does not contain bitcode."

Cartfile:
github "appsquickly/Typhoon"

Cartfile.resolved:
# ...
github "appsquickly/Typhoon" "3.4.5"

When archiving with Release configuration:
<< PROJECT DIR >>/ Typhoon.framework/Typhoon' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

I'm working around this right now with
github "appquickly/Typhoon" "master"


plot_acf_pacf, public schema

Hello,
method plot_acf_pacftemporary create temporary view in public schema, but we don't have access to this schema.

can you add parameter schema for this method to write temporary object?
Regards,
Alexandre

Hi Alexandr,
The vdf used as input can include the "writing schema".
vdf.set_schema_writing("my_schema")
plot_acf_pacf(vdf)

I think, we should add a general variable to solve this problem. We will add an extra parameter to the "set_option" function for v0.9.0.
Badr

Hello,
We could consider the following scenario:
• By default, the function looks at the vDataFrame passed as a parameter, and retrieves:
o The schema of the associated table OR the schema of the set_schema_writing parameter
o They can be potentially different: if the set_schema_writing is specified, it is priority
o Problem, this is not enough here, because on some functions you can directly pass a table and not a vDataFrame, you would then have to retrieve the schema linked to the table in question
• Then, if set_option is defined, then it takes the given schema
o This is then applied to all the functions, and replaces/overwrites the other possibilities
It's ok for you?
Alexandre

Hi Alexandre,
Is it not enough to set the temporary schema at the beginning of the notebook?
set_option("temp_schema", "my_temp_schema")

Badr

hello,
We think it would be nice to be able to do without set_option in cases where temporary tables can be written in the same schema as our table. it avoids having to use another function to use this function.
Alexandre


Development scripts don't work on VSCode if using WSL workspace

Logging this in case others run into the same problem. Not only does it not work but it'll add unwanted extensions to your VSCode installation, so it's best to avoid. The root cause is that --extension-dir is ignored when running VSCode via WSL (it logs Ignoring option 'extensions-dir': not supported for code.). Neither "Run Extension" or "Extension Tests" work, presumably due to this.
The workaround is straightforward: install the native Windows version of Node.js and use a non-WSL workspace. Everything works fine through Powershell.
I'm happy to add a quick note to the documentation to help others avoid this, perhaps on Step 2 here:
https://www.cursorless.org/docs/contributing/

Yikes.
I'd be inclined to do two things:

Add to the docs, as suggested.
Detect the missing support for --extensions-dir somehow. I'm not sure how hard this would be.


Could you share pretrain model on imagenet?

Thanks for reimplement senet in tensorflow. Could you please share pretrained model on imagenet? I have no gpu to do it

I have no plans to put pretrained model yet, maybe in the future, but I cannot guarantee.
I suggest you to use Google colab which support free GPU.


Implement Retry Mechanism and Concurrency Control for Jobs

Overview
This pull request introduces two major enhancements to NCronJob:

Retry Mechanism: To improve the robustness of job executions, especially in cases of transient failures.
Supports Concurrency Attribute: To provide fine-grained control over the concurrency behavior of individual jobs.

Details

Retry Mechanism

Purpose: Increases reliability by automatically retrying jobs that fail due to transient issues.
Implementation: Implemented using the Polly library with an exponential backoff strategy, allowing recoverable failures to be retried.
Configuration: Customizable per job, enabling specific settings for retry counts and backoff intervals.

Supports Concurrency Attribute

Purpose: Adds control over job concurrency to prevent issues from multiple simultaneous instances of the same job type.
Implementation: New SupportsConcurrency attribute introduced to mark job classes that can run concurrently.
Default Behavior: Jobs are assumed to be non-concurrent by default. Scheduler checks this attribute before starting a new instance.
Impact: Prevents simultaneous execution of non-concurrent jobs, reducing potential conflicts or resource issues.

Justification

Retry Mechanism: Enhances resilience against common transient failures in distributed environments.
Concurrency Control: Ensures job execution integrity by preventing duplicate runs of critical or resource-intensive tasks or tasks that work on shared resources.

In your current implementation retry is "always-on" without an option to opt-out. In general I would argue making this feature opt-in is the more sensible choice. That is how many of the .NET objects work and what I would expect as well.

I agree with you about the defaults, I did not integrate configuration bindings as this was more of an initial concept. However most orchestration systems default to retries because they assume the system is deterministic and Jobs are idempotent. Since neither of those are ensured here we can opt-in instead.

That is an interesting take, because my gut feeling would also go the opposite direction. Make every job concurrent by default and opt-out of this feature. And here I lean towards the same argumentation as above, it feels more natural (to me).
Many jobs, like generating reports or even sending e-mails (given not the identical receiver and message) should work in a concurrent setup just fine.

I understand the natural concurrency for tasks like generating reports or sending e-mails, but this is more about risk-mitigation. The default non-concurrent setting is a safer approach in a non-deterministic environment where shared resources or external states are involved. This reduces the risks of race conditions and unintended side effects. Ensuring that concurrency is only enabled after a developer explicitly verifies it helps prevent complex debugging issues, making the system more robust and easier to maintain. Funny enough the reason I added this to this PR was actually because I hit debugging issues while testing the cancellation support and having many of the same type Jobs running in parallel.

I understand the natural concurrency for tasks like generating reports or sending e-mails, but this is more about risk-mitigation. The default non-concurrent setting is a safer approach in a non-deterministic environment where shared resources or external states are involved. This reduces the risks of race conditions and unintended side effects. Ensuring that concurrency is only enabled after a developer explicitly verifies it helps prevent complex debugging issues, making the system more robust and easier to maintain. Funny enough the reason I added this to this PR was actually because I hit debugging issues while testing the cancellation support and having many of the same type Jobs running in parallel.

That is a fair point. Let's go with your approach and if we see that the usage is way different, we can still flip it in the next major version.

That is a fair point. Let's go with your approach and if we see that the usage is way different, we can still flip it in the next major version.

If you prefer I can add a global optIn optOut approach. For example:
services.AddNCronJob(builder =>
{
    // Use this if you assume most jobs are safe to run concurrently and exceptions are explicitly handled
    builder.OptInConcurrency();
});

services.AddNCronJob(builder =>
{
    // Use this if you assume most jobs should not run concurrently and only specific jobs are safe to handle it
    builder.OptOutConcurrency();
});

or
services.AddNCronJob(builder =>
{
    ...
}).OptOutConcurrency();

But this would have a minor breaking change since AddNCronJob would not return an IServiceCollection. But do you really want to give people the option to chain service registrations off of AddNCronJob?
Then decorate the Job according to how you set your global:
[SupportsConcurrency(true)]
public class ConcurrentJob : IJob
{
    // Implementation allowing concurrency
}

[SupportsConcurrency(false)]
public class NonConcurrentJob : IJob
{
    // Implementation disallowing concurrency
}

So if you use OptInConcurrency then all Jobs are assumed to support concurrency and you would have to explicitly add [SupportsConcurrency(false)] as a way to switch that off just for that Job, and vice-versa.

I do prefer the attribute (without any boolean flag) over the other given approaches.
That gives granularity and a much better API experience.
We can think of configuring this via the configuration builder:
Services.AddNCronJob(o =>
{
 o.AddJob<MySampleJob>().WithCronExpression("...").AllowMultipleInstances();
});

I do prefer the attribute (without any boolean flag) over the other given approaches. That gives granularity and a much better API experience.
We can think of configuring this via the configuration builder:
Services.AddNCronJob(o =>
{
 o.AddJob<MySampleJob>().WithCronExpression("...").AllowMultipleInstances();
});

@linkdotnet The challenge with that approach is that the dev can easily do the following (because you're not making the concurrency support inherently a part of the Job):
builder.Services.AddNCronJob(o =>
{
    o.AddJob<MySampleJob>().WithCronExpression("*/10 * * * *").AllowMultipleInstances();
    o.AddJob<MySampleJob>().WithCronExpression("*/25 * * * *");
});

It's the same MySampleJob Job type but one describes support for concurrency while the other does not. I think this leads to confusion and having us explain which one takes precedence. Or just asking devs not to do that, which is not an ideal API experience.

@linkdotnet The challenge with that approach is that the dev can easily do the following (because you're not making the concurrency support inherently a part of the Job):
builder.Services.AddNCronJob(o =>
{
    o.AddJob<MySampleJob>().WithCronExpression("*/10 * * * *").AllowMultipleInstances();
    o.AddJob<MySampleJob>().WithCronExpression("*/25 * * * *");
});

It's the same MySampleJob Job type but one describes support for concurrency while the other does not. I think this leads to confusion and having us explain which one takes precedence. Or just asking devs not to do that, which is not an ideal API experience.

That is fair. Given that we already settled on the attribute, I'd propose utilizing this to control the concurrency level:
[SupportsConcurrency(MaxDegreeOfParallelism = 3)]
public class MyJob : IJob

That would also remove the need for the ConcurrencyConfig as this can be checked once at the beginning of the scheduler.

[SupportsConcurrency(MaxDegreeOfParallelism = 3)]
public class MyJob : IJob

That would also remove the need for the ConcurrencyConfig as this can be checked once at the beginning of the scheduler.

I think you're mixing the global concurrency with the Job specific concurrency  (basically it's 1 job with many triggers). Your suggestion of putting it in the attribute means it is specific only to that job. However the way I had coded the ConcurrencyConfig.MaxDegreeOfParallelism was to manage the concurrency of the Scheduler within the application, not the Job.
Either way I think properly supporting concurrency for both individual Jobs and globally can be a little challenging, but I think I have something you can test.

I think you're mixing the global concurrency with the Job specific concurrency

Indeed I did - thanks for the clarification.

All in all, this PR goes in a really good direction - I really appreciate your work and discussion, @falvarez1 !
My open ToDo's for now:

The retry policy might be configurable as well and not set by default. To be consistent it could be an attribute just like SupportConcurrency is. So you can annotate a job with RetryPolicy(RetryCount = 3)
Some cleanup in the sample because it should show only the bare minimum without confusing someone that is new to the library
Some unit tests for the new behavior (which I can also do once it is merged).

Also thanks for keeping the API stable so we don't have to do a major version bump. If you have time you can also extend the CHANGELOG.md. This file is used for creating the release notes. If not, I can pick this up as well.

The retry policy might be configurable as well and not set by default. To be consistent it could be an attribute just like SupportConcurrency is. So you can annotate a job with RetryPolicy(RetryCount = 3)

Glad you said that because I already had that in mind to submit once this was approved ;-)  I'll include it in this one instead.

Some cleanup in the sample because it should show only the bare minimum without confusing someone that is new to the library

I agree. I don't know the best way to isolate each use case as a separate example without literally creating a separate sample project. I'll clean it up as best I can but open to suggestions.

Some unit tests for the new behavior (which I can also do once it is merged).

Certainly, just waiting to finalize the design first. Don't want to keep changing them while it's in flux.

Updating the README.md to showcase the new capabilities.

I'll give it shot (both README and CHANGELOG).

Also thanks for keeping the API stable so we don't have to do a major version bump.

No worries. I do have other ideas but they may require changes to the API definition. Can discuss separately.

I agree. I don't know the best way to isolate each use case as a separate example without literally creating a separate sample project. I'll clean it up as best I can but open to suggestions.

I do agree - it might be tricky. I do think we need a separate documentation page.
It is almost impossible to showcase all the things the library can do, but keep it very simple and minimalistic.

Certainly, just waiting to finalize the design first. Don't want to keep changing them while it's in flux.

That makes absolutely sense - quite frankly I do think we are almost there.

No worries. I do have other ideas but they may require changes to the API definition. Can discuss separately.

Keep it coming ;) - anyway thanks again for the hard work!

Introduced support for a RetryPolicy attribute to enhance job error handling. The implementation is designed to be extensible, allowing for customization of retry policies while providing simple, sensible defaults. All related code has been organized into the RetryPolicies folder, with thorough documentation included.

Moved the responsibility for retrying failed job executions from the CronScheduler to the JobExecutor. This change justifies that retries should be managed by the executor, especially to support retries triggered by instant job runs and not just scheduled ones. This adjustment makes retry functionalities more broadly applicable.

Priority Queue Enhancement:

Tweaked the priority queue algorithm to accommodate a new JobPriority enum, enhancing our job scheduling capabilities.
Currently, all jobs default to Normal priority, but the system now supports prioritization adjustments as needed. This change is internal and does not affect the external API, preserving backward compatibility and easing future integrations.

Added a default parameter value to the SupportsConcurrency attribute, simplifying the configuration process for anyone who "just wants concurrency" without overthinking it.

@linkdotnet I've managed to get all the tests working and have added a few new ones. However, I still need to write additional tests to cover the concurrency and retries features effectively. To facilitate this, I plan to introduce a JobExecutionCount property to track the number of executions for each job. This property will not only be important for verifying that both concurrent executions and retries are handled correctly but will also enhance observability on the execution of jobs.
I have also addressed issues with the newly added test ThrowIfJobWithDependenciesIsNotRegistered(). There were incompatibilities introduced by the updates in this PR that affected this test, but these have now been resolved.
On a side note, I encountered some difficulties with the TimeProvider integration. Initially, using the TimeProviderFactory.GetTimeProvider() method from the TimeProviderExtensions library resulted in very inconsistent results. After switching to Microsoft's FakeTimeProvider, the issue was resolved, and everything started working as expected.
I aim to finish the tests and will update the PR as soon as these enhancements are implemented.

Really good job!

Initially, using the TimeProviderFactory.GetTimeProvider() method from the TimeProviderExtensions library resulted in very inconsistent results.

Using ManualTimeProvider was a very deliberate choice.
Mainly because of this behavior:

VS

It seemed counter-intuitive to me that if you advance multiple times only that the last result will be invoked n-times.
To be fair, we don't care differentiate between those facts given in the picture.

I aim to finish the tests soon and will update the PR as soon as they are completed.

Awesome! Let me know if I can help you!

I added a couple tests for retries and cleaned up some code. Can you review the tests and see if they behave correctly. I could use some help here if you get a chance. Thanks

By the way the tests using Polly are conducted in actual time, I couldn't figure out how to get it to work with FAke Time, then I found this https://github.com/dotnet/extensions/issues/4912

By the way the tests using Polly are conducted in actual time, I couldn't figure out how to get it to work with fake Time, then I found this dotnet/extensions#4912

Interesting - have to check out the code later.

@falvarez1 looks really good. My main two points would be

Documentation
If possible, squash the commits to something "more meaningful"

I guess besides that we would be go to go (or merge in that case).

Really good work on this one and thanks for taking the time.

I'd directly release a preview version for folks to test.

I agree, I think this needs a little more user testing. I also want to note that some other features I plan to contribute build upon this work, so figuring out a clear path forward would be beneficial for everyone. I suggest creating a develop branch that serves as a staging area for preview features before they're merged into main. This would allow any new PRs that build upon the preview features to be targeted against the develop branch, keeping the main branch stable while allowing more streamlined development of new features. What do you think about this approach?

There are small ordering things inside the README.md I'd like to move around (Migration not in between features for example) - but nothing that blocks merging.

Would it also help to put a ToC at the top that links to the sections?

@falvarez1 I would merge the changes into main - or do you have any open points?
Big thanks to you for the awesome work - really appreciated, that you took the time and effort!


x remove button for each item

New design(ver 1.4.0) is great, but I want x button back.
I have used the previous version of better-onetab,

Ctrl + click several items
Remove opened items by clicking x button

Now, I need to do right click and select 'remove' to remove an item. if you save lot tabs in tab list, in order to remove several tabs,

Ctrl + click several items
Select opened items
Scroll up to the top of the tab list
Click menu and select 'remove'

So, I want x button back, or an option to display x button to each item in tab list. Come to think of it, implementing shortcuts for tab list page is a great addition.

+1 for "display x button to each item in tab list"


Build failure: vinegar

Steps To Reproduce
Steps to reproduce the behavior:

build vinegar

Build log
https://pastes.dev/YQDuwH1ACG
Notify maintainers
@nyabinary
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.7.6, NixOS, 24.05 (Uakari), 24.05.20240228.9099616`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/store/cbbsvzjcqvzlylq9s7p6d2gyxh64q88p-source`

Add a :+1: reaction to issues you find important.

related: #291815

Can confirm same is happening here, using nixpkgs-unstable
building the system configuration...
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
error: builder for '/nix/store/gi5dg85cvp8cn2lm57kiw7kb4i4fypiq-wine64-staging-9.5.drv' failed with exit code 1;
       last 10 log lines:
       > Hunk #9 succeeded at 2828 with fuzz 1 (offset 262 lines).
       > Hunk #10 succeeded at 2893 (offset 264 lines).
       > Hunk #11 succeeded at 2912 (offset 264 lines).
       > Hunk #12 succeeded at 3030 (offset 271 lines).
       > Hunk #13 succeeded at 3057 with fuzz 1 (offset 277 lines).
       > Hunk #14 succeeded at 3075 (offset 277 lines).
       > Hunk #15 succeeded at 3148 (offset 277 lines).
       > Hunk #16 succeeded at 3196 (offset 277 lines).
       > Hunk #17 succeeded at 3220 (offset 277 lines).
       > Hunk #18 succeeded at 3228 (offset 277 lines).

Hunk #2 FAILED at 3278.
Hunk #3 FAILED at 3618.
Hunk #4 FAILED at 3639.
Hunk #5 succeeded at 3957 (offset -446 lines).
3 out of 5 hunks FAILED -- saving rejects to file dlls/ntdll/tests/exception.c.rej
patching file dlls/ntdll/unix/signal_x86_64.c
Hunk #1 succeeded at 423 with fuzz 2 (offset 10 lines).
Hunk #2 succeeded at 826 (offset 13 lines).
Hunk #3 succeeded at 865 (offset 13 lines).
Hunk #4 succeeded at 897 (offset 13 lines).
Hunk #5 succeeded at 1067 (offset 10 lines).
Hunk #6 succeeded at 1138 (offset 5 lines).
Hunk #7 succeeded at 1371 (offset 1 line).
Hunk #8 succeeded at 2808 (offset 260 lines).
Hunk #9 succeeded at 2828 with fuzz 1 (offset 262 lines).
Hunk #10 succeeded at 2893 (offset 264 lines).
Hunk #11 succeeded at 2912 (offset 264 lines).
Hunk #12 succeeded at 3030 (offset 271 lines).
Hunk #13 succeeded at 3057 with fuzz 1 (offset 277 lines).
Hunk #14 succeeded at 3075 (offset 277 lines).
Hunk #15 succeeded at 3148 (offset 277 lines).
Hunk #16 succeeded at 3196 (offset 277 lines).
Hunk #17 succeeded at 3220 (offset 277 lines).
Hunk #18 succeeded at 3228 (offset 277 lines).

Fixed by #305099


Mipatera 2022 06 01 batch management

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? 2022-06-01
When do you expect to publish the swagger? May 2022
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[x] SDK of Python
[x] SDK of Java
[x] SDK of Js
[x] SDK of Go
[x] PowerShell
[x] CLI
[x] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

      "200": {

remove

Refers to: specification/batch/resource-manager/Microsoft.Batch/stable/2022-06-01/BatchManagement.json:2018 in 4181875. [](commit_id = 41818751eda2fe4586173117a5177fcfcc3fa689, deletion_comment = False)

        "Cancelled"

Canceled

Refers to: specification/batch/resource-manager/Microsoft.Batch/stable/2022-06-01/BatchManagement.json:3862 in 4181875. [](commit_id = 41818751eda2fe4586173117a5177fcfcc3fa689, deletion_comment = False)

            "value": "Cancelled",

Canceled

Refers to: specification/batch/resource-manager/Microsoft.Batch/stable/2022-06-01/BatchManagement.json:3889 in 4181875. [](commit_id = 41818751eda2fe4586173117a5177fcfcc3fa689, deletion_comment = False)

I removed the 200 response

We already have used Cancelled in other parts of the swagger such as in "BatchAccountProperties" , "provisioningState".  "cancelled" is the common spelling outside the US and since we already have other enums spelled this way we should probably keep it consistent.

Hi @paterasMSFT Would you please resolve the 'ModelValidation' and 'API Readiness check' failure? Thanks

@chunyu3 I think we're good to go now. The azure-sdk-for-net error is expected.


GuiContentProfile is not defined

Hey guys,
Just a minor thing I stumbled upon while debugging C#, this profile: GuiContentProfile doesn't seem to be defined anywhere, but it's referred to in the scripts about 14 places. Like in art/gui/CameraGui.gui
Should it be replaced with another profile? Or just fall back to GuiDefaultProfile as it does now?

Since it already just falls back to GuiDefaultProfile, it'd probably make the most sense to just use that, really.


Use /tmp for GIT_SSH_COMMAND on MacOS to avoid path too long errors

Fixes #1896
RELEASE_NOTES=[BUGFIX] Use /tmp for GIT_SSH_COMMAND on Mac
Signed-off-by: Dominik Schulz<EMAIL_ADDRESS>

Persistent connections speed up subsequent gopass sync invocations notably.
Many applications use /tmp for their control sockets. If the files are created with sane defaults (i.e. 0700) then we should be good.
The sticky bit should stop attacks trying to replace the control socket.


Support missing required information for protocols in a Parameter table

IP is set to do a shallow walk through of Strateos’s information by collecting information that are 2 levels deep.
Information listed below are required Strateos's information that needs to be generated when first creating a parameter table from IP's drop down menu item. However, these required information are nested 3 levels deep and as result, gets ignored by IP when generating these required default values. This issue will need to be fixed by having IP iterate through all levels of information to ensure that no "required" information is dropped when generating default parameters.
Protocol ID
Induction culture volume 10 microliter
Induction media volume 1000 microliter
Induction sample read solvent volume 80 microliter
Induction sampling read culture volume 20 microliter
Induction sampline read solvent PBS
Induction sampling flow culture volume 200 microliter
Induction sampling flow solvent volume 0 microliter
Induction sampling flow solvent PBS
Induction sampling strain before flow None

Above parameters are not detected in :

Growth Curve protocol
Obstacle Course protocol

The only Strateos protocol currently supported in IP with those desired fields is the time series protocol. However, below are fields that were detected as optional fields and not required field as mentioned from above:

Induction sampline read solvent
Induction sampling flow solvent
Induction sampling strain before flow


keybinding of terminal.findNext cannot be removed

VSCode Version: 1.49.0
OS Version: MacOS 10.14.6 (18G6020)

Steps to Reproduce:

Preference -> Keyboard shortcuts -> search "terminal.find next" -> Remove Keybinding -> doesn't work

Does this issue occur when all extensions are disabled?: Yes

Also affects Windows. It's a regression, it used to work with 1.48.
keybindings.json testcase:
    {
        "key": "ctrl+f",
        "command": "-workbench.action.terminal.focusFind",
        "when": "terminalFocus"
    }

@spasche Hi Spasche, I found this bug with the 1.49.
It used to work with the 1.48 on MacOS as well.

It seems it's not possible to remove other keybindings as well. None of these work to remove ctrl+f when in the terminal:
// Place your key bindings in this file to overwrite the defaults

[
  {
    "key": "ctrl+k f",
    "command": "workbench.action.terminal.focusFind",
    "when": "terminalFindFocused && terminalProcessSupported || terminalFocus && terminalProcessSupported"
  },
  {
    "key": "ctrl+f",
    "command": "-workbench.action.terminal.focusFind",
    "when": "terminalFindFocused && terminalProcessSupported || terminalFocus && terminalProcessSupported"
  },
  {
    "key": "ctrl+f",
    "command": "-actions.find"
    // "when": "terminalFocus && terminalProcessSupported"
  }
]

This works:
{ "key": "ctrl+f", "command": "-workbench.action.terminal.focusFind" }

I'm guessing the issue is that && and || don't work when you're removing keybindings.

Testcase on https://github.com/microsoft/vscode/issues/106524#issuecomment-691658426 also doesn't work and doesn't contain && or || in the when condition.
So the issue may not be related to && or || (or not only).

@spasche good point, tested and I can see that too. Updated title.

Yup, this does not work:
    {
        "key": "ctrl+f",
        "command": "-workbench.action.terminal.focusFind",
        "when": "terminalFocus"
    }

This does:
    {
        "key": "ctrl+f",
        "command": "-workbench.action.terminal.focusFind"
    }

This is a problem limited for now to the terminal actions and it has to do with the way the default keybindings are constructed in code by using AND between the precondition and the when context. So the registration of workbench.action.terminal.focusFind leads to a when expression looking like:
(terminalFindFocused || terminalFocus) && terminalProcessSupported.
But the context keys do not support parentheses in their serialized form (that is intentional), so we distribute the AND against the OR to create:
terminalFindFocused && terminalProcessSupported || terminalFocus && terminalProcessSupported.
Unfortunately there is a bug in that code path where the normalized form is not fully equal to the deserialized form. The normalized form contains an extra AND expression with a single operand which should be removed:

The workaround is to remove the keybindings without a "when" clause.


fixed tests and a small bug with create

Fixes broken tests as described in https://github.com/micro-fan/aiozk/issues/84
In aiozk.transaction.Transaction.commit I think we should also check for the reply to be of type Create2Response (which I added), otherwise result evaluates to False and the context manager test which only calls Transaction.create() never succeeds.
I also added missing pytest.mark.asyncio decorators to test functions & pytest_asyncio.fixture decorators to async fixtures to correctly handle async tests.
Additionally updated base images to help with docker builds, albeit those images also seems to be based on outdated Ubuntu versions.
Nevertheless, my local tox runs now succeed with the changes in this PR

@cybergrind , please take a look. Thanks!

Probably we could make it smaller if use auto mode, could you please check if it do the trick?
# pytest.ini
[pytest]
asyncio_mode = auto

Nice, thanks! I've reduced the PR further and tests pass.

@sy-be thank you! <3 merged

Awesome, thanks! 🎉


Unannounced breaking change in renaming falcon.api_helpers

The falcon.api_helpers module used to contain several semi-public (not documented, but not underscored either) utilities, that people may be relying on.
During the 3.0 release cycle, falcon.api_helpers was renamed to falcon.app_helpers in order to reflect the API :arrow_right: App renaming.
However, the old name disappeared without any deprecation notice, and without any information in the 3.0 changelog notes. This is a bug.
In the spirit of SemVer, we cannot afford marking the change as deprecation in 3.0.1 either.
Let us make the name available as-is in 3.0.1, and mark as deprecated in 3.1; remove in 4.0.

This is used by Sentry's Falcon integration plugin, so we need to make sure the coming fix re-enables that plugin at least on the import level.


Can't unset constrainedAxis in typescript without casting

Attempting to set camera.constrainedAxis = undefined; in typescript results in a compilation error. Since this is the documented approach to creating an unconstrained axis, the type of camera.constrainedAxis should probably be Cartesian3 | undefined.
Note that the workaround is fairly easy, if undesireable:
camera.constrainedAxis = undefined as any;

Thanks @mbmccoy! Would you be able to submit the fix as a Pull Request?
See CONTRIBUTING.md for how to get started.

I'll pick this up, I don't see any PR for it.

Regex-searching for
@type \{.*\}
   \* @default undefined

brings up many places (83 with a first shot) where the type is meant to be something specific, but the default value is undefined. I'm tempted to blindy do a bulk pass here and add that  | undefined everywhere, unless someone has doubts that this is the right thing to do here.

This can probably be closed, with the more generic question about the other places that show this pattern being tracked in https://github.com/CesiumGS/cesium/issues/11749#issuecomment-1950184016

Closing in favor of https://github.com/CesiumGS/cesium/issues/11749#issuecomment-1950184016.


Services from a deleted application are recreated

Service Fabric Runtime Version: 7.2.445.9590
Environment: Azure
Description:
I deleted a SF application to essentially reset my dev environment. I've done this literally hundreds of times. I screwed up some code today, and normally when I do this, I simply publish an update, and the cluster will recover. Today when the update was deployed I noticed a lot of services, which should have been deleted, were still hanging around, and were causing a lot of exceptions (we create / delete services every few minutes.) So, I figured, I'll just reset. So I deleted the app, and kicked off a fresh deploy from devops. After a bit, I came back, and I see that the app has deployed, and there are lots of services, some of which had existed prior to the delete. I thought I was losing my mind, so I deleted everything again, redeployed the app, and once again they're back. There is zero possibility that my code recreated the services, so I suspect there's a major problem with the 7.2.445.9590 release.
Observed behavior: Delete app, deploy app, old services be back.
Expected Behavior: Delete app, deploy app, old services be gone.
OS(Windows/Linux): Windows

Assignees: /cc @microsoft/service-fabric-triage

If you haven't already resolved this or opened a case I'd highly suggest you do at this time so we can get some eyes on what you are seeing so we aren't missing a possible bug.
See guidance here https://github.com/microsoft/service-fabric/blob/master/CONTRIBUTING.md#support-channels
thanks!

If you haven't already resolved this or opened a case I'd highly suggest you do at this time so we can get some eyes on what you are seeing so we aren't missing a possible bug.
See guidance here https://github.com/microsoft/service-fabric/blob/master/CONTRIBUTING.md#support-channels
thanks!


Always on Top's highlight persists even though the application has been closed

Microsoft PowerToys version
0.76.2
Installation method
PowerToys auto-update
Running as admin
None
Area(s) with issue?
Always on Top
Steps to reproduce

Turn on PowerToys
Turn on "Sticky Note"
Use Always on Top function on a "Sticky Note" window
Close the "Sticky Note" window

✔ Expected Behavior
Expecting the highlight around the "Sticky Note" to disappear with the closed window.
❌ Actual Behavior
Highlight continues to persist where the window was.
Other Software
No response

I can't reproduce this. What version of Sticky Notes do you have? And does this also happen with PowerToys 0.77?
/needinfo

Hi,
The Sticky Notes version was <IP_ADDRESS>
And PowerToys v0.76.2
On Tue, Jan 30, 2024 at 1:00 AM Aaron Junker-Wildi @.***>
wrote:

I can't reproduce this. What version of Sticky Notes do you have? And does
this also happen with PowerToys 0.77?
/needinfo
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/31167#issuecomment-1915012825,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH7LVBBZQMWWG2WCPP7QPH3YQ7BRRAVCNFSM6AAAAABCO7EC6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVGAYTEOBSGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

probably a duplicate of #28120
but a /bugreport would be helpful here


A single failure in toHaveBeenCalledWith() when using expect.stringContaining() will show other expected results  as failed

🐛 Bug Report
A single failure in toHaveBeenCalledWith() when using expect.stringContaining() will show other successful results as failed. See the reproduction case below!
To Reproduce
      it.only("Test", () => {
        var createChatRoomMock = jest.fn();

        createChatRoomMock({
            "chatRoomUuid": "chatRoom_a",
            "creatorId": "user_b",
            "somethingElse": "bad"
        });

        expect(createChatRoomMock).toHaveBeenCalledWith({
          creatorId: expect.stringContaining("user_"),
          chatRoomUuid: expect.stringContaining("chatRoom_"),
          somethingElse: expect.stringContaining("good")
        });
      });

Expected behavior
    expect(jest.fn()).toHaveBeenCalledWith(...expected)

    - Expected
    + Received

      Object {
    -   "somethingElse": StringContaining "good",
    +   "somethingElse": "bad",
      },

Actual behaviour
    expect(jest.fn()).toHaveBeenCalledWith(...expected)

    - Expected
    + Received

      Object {
    -   "chatRoomUuid": StringContaining "chatRoom_",
    -   "creatorId": StringContaining "user_",
    -   "somethingElse": StringContaining "good",
    +   "chatRoomUuid": "chatRoom_a",
    +   "creatorId": "user_b",
    +   "somethingElse": "bad",
      },

Link to repl or repo (highly encouraged)
https://repl.it/repls/ImpishTerrificOperation
envinfo
  System:
    OS: Linux 4.19 Ubuntu 20.04 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
  Binaries:
    Node: 10.20.1 - /usr/bin/node
    npm: 6.14.4 - /usr/bin/npm
  npmPackages:
    jest: ^25.5.3 => 25.5.3

Note: originally repl.it failed with:

Oh No! The IDE is having a bit of trouble.

So there wasn't a repl link. It's been added now, so the Needs Repro badge can be removed.

This sounds like what #9257 was supposed to fix... Maybe it's just missing for this matcher?

any news on this ? i'm on 27.0.6

Feel free to send a PR 🙂

@SimenB Since its been 2 years, i was just asking some news if this is been fixed ?

You could try out using the latest version of Jest yourself. Seeing as you say it still reproduces on 27.0.6 it seems unlikely to have been fixed

Check it with the latest version. Seems to still be there. Did not fix itself (;

i used a workaround by making a custom matcher , extending it in jest. Sorry i don't have much time to spend to help you guyz.

I want to test socket.io its io.to(room).emit(event, data) if had been call and check its args , so I do this way:
my mock:
// ../server is where I export io
jest.mock("../server", () => {
  const original =
    jest.requireActual<typeof import("../server")>("../server.ts");

  return {
    redis: new Redis(process.env.REDIS_URL!),
    io: {
      to: jest.fn().mockImplementation((room: string) => {
        return {
          emit: jest
            .fn()
            .mockImplementation((event: string, data: NotifyPopupContent) => {
              console.log(`emit to ${room} at event :${event} success!`);
            }),
        };
      }),
    },
  };
});

my test:
it's just work fine with to: jest.fn , but not ok with to().emit:
expect(io.to).toHaveBeenCalledWith(user2ToBeNotifySocketId) // it pass
const mockEmit = io.to(user2ToBeNotifySocketId).emit as jest.Mock;
expect(mockEmit).toHaveBeenCalledWith("notify", notificationContent); // it get error

error:
expect(jest.fn()).toHaveBeenCalledWith(...expected)
 Expected: "notify", {"avatar": "avatar", "createdAt": "2022-11-17T14:07:07.353Z", "id": "6376400baa977167871a8c8a", "main": "newTweet", "name": "user1", "type": "tweet", "userId": "6376400baa977167871a8c89"}

That's weird.
It should can work but not...
Any Idea?


Make PersonPicture initials display centered

Description
PersonPicture initials can look slightly off-center. For instance, on my 125% display scale screen, letters look a little bit to the left. However, even a 100% display scale factor can still look off.
Motivation and Context
This improves the visual appearance of PersonPicture when initials or an icon is shown.
How Has This Been Tested?
Visually—see below.
Screenshots (if appropriate):
These screenshots are at 125% scale.
With no image or initials/name:

With initials:

Zoomed in so you can see how the antialiasing affects the visual perception of centered-ness.

This screenshot is at 100% scale:

There is one side affect that may or may not be desirable. In the current behavior, text that is clipped with the center in focus. In this PR, if text goes over, it starts at the left.

This is a PersonPicture with Initials="PersonPicture". This is not a particularly realistic use case, but I figured it was worth mentioning in case the current behavior is deliberate.

I will also note that TextAlignment is used instead of the newer HorizontalTextAlignment (which does the same thing anyway) due to a need to work on 15063 (RS2), as is done elsewhere in this repo.

@BreeceW Could you please update the failing visual verification test? The instructions are here: https://github.com/microsoft/microsoft-ui-xaml/blob/fa28e62c2ddffe03c620524e1719b0dd1d246b91/docs/developer_guide.md#update-visual-tree-verification-files

@BreeceW Could you please update the failing visual verification test? The instructions are here: https://github.com/microsoft/microsoft-ui-xaml/blob/fa28e62c2ddffe03c620524e1719b0dd1d246b91/docs/developer_guide.md#update-visual-tree-verification-files

OK, I have done this.

/azp run

Thank you for submitting this PR, the current focus of the team is to assist our users in moving from WinUI 2 to WinUI 3. We are closing this PR as it does not address resolving a critical issue for WinUI 2 or WinUI 3.


Registration form validations

Description
Fixes:

Validate username from server and show error notification
Length validations for registration form fields
Password field validations
Generic Network Error

Why was the change made?
We want to tell the user to edit invalid fields sending the form. We also want to explain why. This improves user experience.
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Unittest
[x] Cypress e2e -tests

Caveats?
Does this introduce new warnings or are linter rules suppressed? Why? Is only manual testing applicable for this feature? Is there something special that the reviewer should take into account?
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

The user with takenUsername is now created in the test suite. I also updated the Readme instructions for running the tests locally (clearing the db before running the suite again).
I'll take this into account in the future, now I just want this PR over with. :D
Updated!
I don't think it will be that bad. We'll just have all the different language text options in the html file and have a function that switches which ones we show when pressing some "change language" button.


CAMEL-14744: fix camel-salesforce lazy-login

This PR is an attempt to fix the lazy-login bug in the camel-salesforce component, which was logged in CAMEL-14744.
I would like some feedback on the chosen approach :

Passing around SalesforceLoginConfig instead of a boolean value indicating lazyLogin
"JIT" login in the SalesforceProducer#process method

This fix was tested against an actual Salesforce instance, via the DefaultRestClient implementation. I am unable to verify the other ApiClient implementations and things like the SubscriptionHelper, AbstractSalesforceMojo.

[x] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[x] Each commit in the pull request should have a meaningful subject line and body.
[x] If you're unsure, you can format the pull request title like [CAMEL-XXX] Fixes bug in camel-file component, where you replace CAMEL-XXX with the appropriate JIRA issue.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Run mvn clean install -Psourcecheck in your module with source check enabled to make sure basic checks pass and there are no checkstyle violations. A more thorough check will be performed on your pull request automatically.
Below are the contribution guidelines:
https://github.com/apache/camel/blob/master/CONTRIBUTING.md

LGTM
@zregvart if you are around wonder if you could take 2 min to take a look.


iOS 14 differences

In iOS 14, the fake “light sensor” is no longer available as a favorite, which means I can no longer quickly glance in control center on my phone to get the price. The only way to see the price now is in the Home app, and going to the specific page for its assigned room. The value is actually rounded up and in the status area, and you have to tap it to see the full details. I’m hoping there is a good workaround to get it back into the favorites section or somewhere where it can easily be seen.

Aww, that’s no fun.  Thanks for the heads-up though

On Sep 16, 2020, at 11:43 AM, Superevr<EMAIL_ADDRESS>wrote:

In iOS 14, the fake “light sensor” is no longer available as a favorite, which means I can no longer quickly glance in control center on my phone to get the price. The only way to see the price now is in the Home app, and going to the specific page for its assigned room. The value is actually rounded up and in the status area, and you have to tap it to see the full details. I’m hoping there is a good workaround to get it back into the favorites section or somewhere where it can easily be seen.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


feat: add async getProjectId method

BREAKING CHANGE: The Datastore.projectId property has been removed, and replaced with an asynchronous getProjectid() method.  The projectId cannot be determined synchronously, so the previous approach was to use a {{projectId}} string placeholder if the projectId had not yet been acquired.  This made it difficult to know exactly when the property would be defined.
As an added bonus, the @google-cloud/projectify dependency has been removed. Adding @crwilcox because this would be a breaking change (we're about to ship one).

There are a couple places I think need to be handled:

DatastoreRequest.projectId: https://github.com/googleapis/nodejs-datastore/blob/a2099149ed83af023e6b8d2b0b950d460fd91243/src/request.ts#L1351
Transaction.projectId: https://github.com/googleapis/nodejs-datastore/blob/a2099149ed83af023e6b8d2b0b950d460fd91243/src/transaction.ts#L70

Thanks @stephenplusplus!
For datastoreRequest.projectId: I looked pretty closely at this one.  The projectId was set higher in the function like you called out, but then after auth.getProjectId it is set again here:
https://github.com/googleapis/nodejs-datastore/pull/657/files#diff-31b74031f3c83e9e883fd930aaf87f54R1389
As far as I can tell, the reqOpts weren't passed into anything before that.  It's a little hard to explain without checkout the branch and looking at that whole function for sure.
For transaction.ts that one was also a little weird.  There was no compiler error for the dangling datastore.projectId because the types appear to allow [index: string]: Entity, which is aliased to any 😬  I'll look into that another day.  For now, I removed the errant property, though it looks like it wasn't being used anywhere.

How does this compare to the other node.js client interfaces?

Good question!  This makes Datastore consistent with the GAPIC libraries, and moves away from what Bigtable, Storage, PubSub, and BigQuery are doing.  The goal would be to make this change for those libraries as well.
It's impossible for me to know how much users rely on the projectId property in its current state, so I don't know how bad of a breaking change this really is.  My hunch is that a property that starts as {{projectId}} and then magically at some point has the right value is less valuable than an async method that always returns the right value.

I am okay with taking this. Will let @BenWhitehead lgtm though.

Conceptually I'm okay with this, but I also don't have any idea around how this might be in the path for folks. (And I don't know NodeJS well enough to be able to speculate).
@schmidt-sebastian Do you have ideas here or know someone who might?

Note that I haven’t looked at the changes on this PR (and am also not going to voice an opinion on Datastore). In Firestore, we were able to this without a breaking change by kicking off Project ID detection just before we serialized requests, which always happened as part of an async call.

👋 speaking from the perspective of other gapic libraries, you are able to get projectID via:
await client.getProjectId()

So this approach is consistent. As @JustinBeckwith points out, Datastore.projectId can't work in GCP environments, when fetching projectID via the metadata server.


[Feature Request] clearCache + keepCookies

Environment
Flutter version: 3.13.9
Plugin version:  flutter_inappwebview: ^5.8.0
Android version:  all
iOS version: all
Xcode version: 15
Device information:  all
Description
What you'd like to happen:
Could it be a good idea to create a feature to disable cache and keep cookies ?
For example, my app contain a webview which is not always visible (it's a page). I would like to ensure that my user see the latest version of the web page every time (so no cache). The webview display some popups based on cookie choices. If I use today the 'cacheEnabled: false', cookie are deleted every times so the popups are displayed every times.
A new option to clear the cache and keep the cookies could be a good idea ?
Alternatives you've considered:
Images:

Thanks for the request, I will add this feature to the new plugin version 6 as soon as possible.

@pichillilorenzo
I maybe miss see something. This feature seems to be already 'implemented'. But i didn't understand how :').
When i launch a webview with cacheEnabled: false, cookie are well persisted on Android and iOS.

I think I need to refactor this feature in a better way.
I will reopen this issue to keep track about it, thanks.

Released new version 6.0.0-beta.32:

Deprecated InAppWebViewController.clearCache method and InAppWebViewSettings.clearCache property. Use InAppWebViewController.clearAllCache static method instead

InAppWebViewController.clearAllCache will clear only cache.


Indexer events

Change Summary
Refactored path_helper.py and updated indexer lambda to handle two event sources. Will update batch job event handler in upcoming PR.
Overview
Main changes are in indexer.py and path_helper.py
Updated Files

sds_data_manager/lambda_code/SDSCode/database/models.py

updated status enum and changed job definition can be null

sds_data_manager/lambda_code/SDSCode/indexer.py

updated indexer to handle s3 and custom event.

sds_data_manager/lambda_code/SDSCode/path_helper.py

updated path_helper to use functions instead of class as @greglucas was suggesting last time. It makes sense now.

Minor updates to these two files:

sds_data_manager/lambda_code/SDSCode/upload_api.py
sds_data_manager/stacks/indexer_lambda_stack.py

Testing

tests/lambda_endpoints/test_indexer_lambda.py
tests/lambda_endpoints/test_path_helper.py

closing temporarily to rework path_helper.py

pre-commit.ci autofix


Could we have F1 Score and F-Scores in TF 2.0?

Please make sure that this is a feature request. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template
System information

TensorFlow version (you are using): TF 2.0 alpha
Are you willing to contribute it (Yes/No): Unlikely. I am going to try to build a workaround, but I've never contributed to TF and probably wouldn't be able to figure out the right way to put together code you'd want in master...I will post any useful code I come up with though if allowed.

Describe the feature and the current behavior/state.
I would like to be able to do 'model.compile(..., metrics=['F1'])
Or even 'model.compile(..., metrics=['FX']) for an arbitrary float X.
I'm guessing we don't currently have it because it's not in Keras?
Will this change the current api? How?
No
Who will benefit with this feature?
F1 score and F-scores are relatively common in evaluating classification algorithms.
Any Other info.
I see a related request, seemingly for TF 1.x, in
https://github.com/tensorflow/tensorflow/issues/28207
but I don't know if it went anywhere.
https://en.wikipedia.org/wiki/F1_score

OK. I built a couple Metric classes on top of Precision and Recall. It should at least allow
metrics=[metrics.FScore(F=2)...].
Since this issue arose from work I have to go through a paperwork chain before I'm allowed to post anything. Should take about a month. If this is not irrelevant by then I'll comment back to ask:

What branch to do a pull request on (Just r2.0?)
Whether this can go in metrics.py, or if it would have to live somewhere else by account of not being part of Keras.

Could you share your implementation for the F1 score?

As I said...it will be hopefully about a month.

just a quick glimpse, since f1 == dice according to (https://en.wikipedia.org/wiki/F1_score)
And the computation cost for compute dice is less compared with f1.
So a base sample code of f1 score for img segmentation:
@tf.function
def f1(y_true, y_pred):
    y_true = K.flatten(y_true)
    y_pred = K.flatten(y_pred)
    return 2 * (K.sum(y_true * y_pred)+ K.epsilon()) / (K.sum(y_true) + K.sum(y_pred) + K.epsilon())

Here is an implementation for tf 1.13
from tensorflow.python.keras import metrics

class F1Score(metrics.Metric):
  """Computes the f1_score of the predictions with respect to the labels.

  For example, if `y_true` is [0, 1, 1, 1] and `y_pred` is [1, 0, 1, 1]
  then the f1_score value is 0.66. If the weights were specified as
  [0, 0, 1, 0] then the precision value would be 1.

  The metric creates three local variables, `true_positives`, `false_positives` and
  `false_negatives` that are used to compute the f1 score.
  This value is ultimately returned as `f1_score`, an operation that
  simply divides computes 2* `precision`*`recall` /(`precision` + `recall`).
  Where `precision` is ...
  and `recall` is ...

  If `sample_weight` is `None`, weights default to 1.
  Use `sample_weight` of 0 to mask values.

  Usage: ...
  """

  def __init__(self, thresholds=None, name=None, dtype=None):
    """Creates a `F1Score` instance.

    Args:
      thresholds: (Optional) Defaults to 0.5. A float value or a python
        list/tuple of float threshold values in [0, 1]. A threshold is compared
        with prediction values to determine the truth value of predictions
        (i.e., above the threshold is `true`, below is `false`). One metric
        value is generated for each threshold value.
      name: (Optional) string name of the metric instance.
      dtype: (Optional) data type of the metric result.
    """
    super(F1Score, self).__init__(name=name, dtype=dtype)
    self.thresholds = metrics._parse_init_thresholds(
        thresholds, default_threshold=0.5)
    self.tp = self.add_weight(
        'true_positives',
        shape=(len(self.thresholds),),
        initializer=metrics.init_ops.zeros_initializer)
    self.fp = self.add_weight(
        'false_positives',
        shape=(len(self.thresholds),),
        initializer=metrics.init_ops.zeros_initializer)
    self.fn = self.add_weight(
        'false_negatives',
        shape=(len(self.thresholds),),
        initializer=metrics.init_ops.zeros_initializer)

  def update_state(self, y_true, y_pred, sample_weight=None):
    """Accumulates true positive, false positive and false negative statistics.

    Args:
      y_true: The ground truth values.
      y_pred: The predicted values.
      sample_weight: Optional weighting of each example. Defaults to 1. Can be a
        `Tensor` whose rank is either 0, or the same rank as `y_true`, and must
        be broadcastable to `y_true`.

    Returns:
      Update op.
    """
    return metrics._update_confusion_matrix_variables({
        metrics._ConfusionMatrix.TRUE_POSITIVES: self.tp,
        metrics._ConfusionMatrix.FALSE_POSITIVES: self.fp,
        metrics._ConfusionMatrix.FALSE_NEGATIVES: self.fn
    }, y_true, y_pred, self.thresholds, sample_weight)

  def result(self):
    precision = math_ops.div_no_nan(self.tp, self.tp + self.fp)
    recall = math_ops.div_no_nan(self.tp, self.tp + self.fn)
    numerator = math_ops.multiply(precision, recall)
    denominator = math_ops.add(precision, recall)
    frac = math_ops.div_no_nan(numerator, denominator)
    result = math_ops.multiply(tf.constant(2.), frac)

    return result[0] if len(self.thresholds) == 1 else result

  def reset_states(self):
    num_thresholds = len(to_list(self.thresholds))
    for v in self.variables:
      K.set_value(v, np.zeros((num_thresholds,)))

Metrics have changed a bit, there are now top_k and class_id parameters that would have to be implemented, and theres also the method get_config to implement.
I can free some time and make a pull request if the approach in the code above is validated.

This would be a good candidate for the AddOns repository (https://github.com/tensorflow/addons) and based on how widely it is being used we can move it to TensorFlow core.

Please feel free to send a PR to the add ons repository.

This "kind of" works for me (I wanted to have class_id in f1)
But it throws a warning that I don't know how to parse:

WARNING: Entity <bound method F1Score.update_state of <INS_model.F1Score object at 0x00000181D733C588>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, export AUTOGRAPH_VERBOSITY=10) and attach the full output. Cause: converting <bound method F1Score.update_state of <INS_model.F1Score object at 0x00000181D733C588>>: AttributeError: module 'gast' has no attribute 'Str'

from tensorflow.python.ops import init_ops
from tensorflow.python.ops import math_ops
from tensorflow.python.keras.metrics import Metric
from tensorflow.python.keras.utils import metrics_utils
from tensorflow.python.keras.utils.generic_utils import to_list
from tensorflow.python.keras import backend as K
class F1Score(Metric):
  """Computes the F1 of the predictions with respect to the labels.
  The metric creates two local variables, `true_positives` and `false_positives`
  that are used to compute the precision. This value is ultimately returned as
  `precision`, an idempotent operation that simply divides `true_positives`
  by the sum of `true_positives` and `false_positives`.
  If `sample_weight` is `None`, weights default to 1.
  Use `sample_weight` of 0 to mask values.
  If `top_k` is set, we'll calculate precision as how often on average a class
  among the top-k classes with the highest predicted values of a batch entry is
  correct and can be found in the label for that entry.
  If `class_id` is specified, we calculate precision by considering only the
  entries in the batch for which `class_id` is above the threshold and/or in the
  top-k highest predictions, and computing the fraction of them for which
  `class_id` is indeed a correct label.
  Usage:
  ```python
  m = tf.keras.metrics.F1Score()
  m.update_state([0, 1, 1, 1], [1, 0, 1, 1])
  print('Final result: ', m.result().numpy())

Usage with tf.keras API:
model = tf.keras.Model(inputs, outputs)
model.compile('sgd', loss='mse', metrics=[tf.keras.metrics.F1Score()])

"""
def init(self,
thresholds=None,
top_k=None,
class_id=None,
name=None,
dtype=None):
"""Creates a F1Score instance.
Args:
thresholds: (Optional) A float value or a python list/tuple of float
threshold values in [0, 1]. A threshold is compared with prediction
values to determine the truth value of predictions (i.e., above the
threshold is true, below is false). One metric value is generated
for each threshold value. If neither thresholds nor top_k are set, the
default is to calculate precision with thresholds=0.5.
top_k: (Optional) Unset by default. An int value specifying the top-k
predictions to consider when calculating precision.
class_id: (Optional) Integer class ID for which we want binary metrics.
This must be in the half-open interval [0, num_classes), where
num_classes is the last dimension of predictions.
name: (Optional) string name of the metric instance.
dtype: (Optional) data type of the metric result.
"""
super(F1Score, self).init(name=name, dtype=dtype)
self.init_thresholds = thresholds
self.top_k = top_k
self.class_id = class_id
default_threshold = 0.5 if top_k is None else metrics_utils.NEG_INF
self.thresholds = metrics_utils.parse_init_thresholds(
    thresholds, default_threshold=default_threshold)
self.true_positives = self.add_weight(
    'true_positives',
    shape=(len(self.thresholds),),
    initializer=init_ops.zeros_initializer)
self.false_positives = self.add_weight(
    'false_positives',
    shape=(len(self.thresholds),),
    initializer=init_ops.zeros_initializer)
self.false_negatives = self.add_weight(
    'false_negatives',
    shape=(len(self.thresholds),),
    initializer=init_ops.zeros_initializer)

def update_state(self, y_true, y_pred, sample_weight=None):
"""Accumulates true positive and false positive statistics.
Args:
y_true: The ground truth values, with the same dimensions as y_pred.
Will be cast to bool.
y_pred: The predicted values. Each element must be in the range [0, 1].
sample_weight: Optional weighting of each example. Defaults to 1. Can be a
Tensor whose rank is either 0, or the same rank as y_true, and must
be broadcastable to y_true.
Returns:
Update op.
"""
metrics_utils.update_confusion_matrix_variables(
{
metrics_utils.ConfusionMatrix.TRUE_POSITIVES: self.true_positives,
metrics_utils.ConfusionMatrix.FALSE_POSITIVES: self.false_positives,
metrics_utils.ConfusionMatrix.FALSE_NEGATIVES: self.false_negatives
},
y_true,
y_pred,
thresholds=self.thresholds,
top_k=self.top_k,
class_id=self.class_id,
sample_weight=sample_weight)
def result(self):
precision = math_ops.div_no_nan(self.true_positives,
self.true_positives + self.false_positives)
recall = math_ops.div_no_nan(self.true_positives,
self.true_positives + self.false_negatives)
result = 2*math_ops.div_no_nan(math_ops.multiply(precision, recall),
math_ops.add(precision, recall))
return result[0] if len(self.thresholds) == 1 else result
def reset_states(self):
num_thresholds = len(to_list(self.thresholds))
K.batch_set_value(
[(v, np.zeros((num_thresholds,))) for v in self.variables])
def get_config(self):
config = {
'thresholds': self.init_thresholds,
'top_k': self.top_k,
'class_id': self.class_id
}
base_config = super(F1Score, self).get_config()
return dict(list(base_config.items()) + list(config.items()))

My solution is very outdated.
F1 score has been implemented in the AddOns repository (https://github.com/tensorflow/addons).
Have a look at tensorflow_addons.metrics.F1Score

F1 in addons seems to have an ugly bug: https://github.com/tensorflow/addons/issues/825


fix: non-silent toggle keybind

Keymap for toggle_keybind displays the following unnecessary message by default every time. This fix removes it :))

Oh nice. Good fix. Thanks a lot.


first example of multiagent Nevergrad

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

How Has This Been Tested (if it applies)

Checklist

[ ] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
[x] All tests passed, and additional code has been covered with new tests.

Hmm, maybe I should not use random.

Closed; done again in another PR.


[CLI] Added TERM as leaking env vars in pure shell

Summary
Added $TERM to the list of env vars that leak to pure shell. Reason being, Pure shell doesn't allow colorful text in prompt because TERM variable is unset.
Adding the TERM allows pure shell to know if terminal supports color and enable it.
Addresses #1200
How was it tested?

compile
./devbox shell --pure
ls -a
ls -a --color
confirm directories and executables show in different colors when --color is passed.

Are HOME, PATH, and TERM the only env vars that we let leak in pure mode? I think we need to allow quite a few more to prevent things from breaking. This is the list of environment variables we would allow back when Devbox's shell was originally pure by default...

@gcurtis you might be right, but I'd rather go down the path of least number of leaked env vars as much as possible. Unless we have user issues, or cases an env var not leaking breaks things.

I was just mentioning it because a lot of these did break users before. We could say that if you're choosing pure mode you need to set these yourself, but I'm not sure if most users will know that. There are also some that are user-specific (i.e., they can't be added to devbox.json). Some of the issues we saw before were:

NIX_SSL_CERT_FILE not being set will break some Nix packages that use HTTPS
Not setting locales (LC_*) can break text encoding.
LOGNAME is required by POSIX so a lot of things might assume it's set.

I think we're going to end up repeating a lot of the same bugs if we don't go through and see which need to be set.

@gcurtis what if we add this list to the docs page explaining that excluding these env vars (aka using pure mode) might cause these known side effects.


How to synchronize on enterText?

In a test, a text that contains a non-Latin characters is entered into a TextArea by using fxter.clickOn(xxx).enterText(" non latin character goes here"). Just after the text is entered, a screen shot is taken. In most times, the entered text is not present in the screen shot taken.
Experiments show that the entered text will be present in the screen shot after some (millis)seconds  between moments of entering the text and taking the screen shot.
What would be the approach to synchronize on the moment when the entered text is finally become visible on a form?
Unfortunately, waitForFxEvents() does not help here.

I would do what waitForFxEvents() does... if that doesn't help, I would try something more intrusive such as FXApp.doInFXThreadBlocking( () -> { } ) (in Groovy just remove the Java-lambda () -> prefix).
This guarantees that any code after this line runs after enterText() has run. If this also doesn't help, you've got a screen update delay in your machine... I would have to suggest enterText( "hi" ).pause( millis ) to let the screen update after a delay.
A more sophisticated approach would be to use waitForCondition(), form the tempus-fugit library I suggest in the README page to deal with timing issues... but that would require you know of a way to confirm the text is actually visible in the screen with code.
By the way, don't you want to submit a PR with the code for taking screenshots? If you just add the code that does it, I can connect it with Automaton's error handling so you get the snapshot after a error is detected...

Thank you for your suggestions! Did not have a chance too try them, hope this week.
Regarding the PR you mentioned, let me think what I can do regarding the PR.


OAuth Middleware

I'm currently having an issue with the following scenario: I want to have access to the currently authenticated-user (via an access token header) in a controller method, but I don't want that route to have the REQUIREMENT of having an access token.
This is problematic, because the only way to get access to the currently logged in user is to apply the "oauth" middleware to the route. But if I do that, ONLY anonymous users can see the route (it errors if you don't pass an access token and have the oauth middleware applied).
For example, let's say I have an application like Instagram, with an endpoint for getting a users followers:
/users/id/followers
Now, I want this to be a public endpoint, but I also have some code in my controller that checks if the user is private, and if they are, it checks that the authenticated-user is an approved follower of that user. So, I need access to the currently authenticated user, but the only way I can do that is to apply the "oauth" middleware. But if I do that, the endpoint errors out if the user is just an anonymous user that doesn't have an access token.
Any tips for handling this?

How can I give you the current authenticated user without giving me his access token?!

@OmarElGabry Well, you can't of course. My question was more around the idea of "what do you do when you only sometimes need to get the currently authenticated user inside of a controller method?" As in, you don't want the request to fail if there's no access token, but if there is an access token, you want to be able to grab the resource owner id. Currently, you can only get the resource owner id if you have the oauth middleware applied to the route, but if you do that then the request fails without an access token, leading to my issue.
Nonetheless, I think my problem actually stems from my own misunderstanding of the situation. I guess the truth is that in this case, you should never have a request without an access token. Because anything that consumes the API should get an access token (whether it's a user with a login/pass or just a web client, or something else entirely).

Aha, I guess using this package you can't. But, in the real world situations, you can. For example, when I open a Facebook page, and I'm not logged in, I can see everything just fine, and whenever I log in, Now, the application can get my current name, email, ...etc.
Actually, In APIs, you can have a route path that doesn't need an access token; user doesn't need to be authorized, like in vk.com.


[FIX] Detect dynamic dependencies also when newer APIs are used

So far, dynamic dependencies only had been detected for calls to
jQuery.sap.require. Now, calls to sap.ui.require and sap.ui.requireSync
are also checked.

Coverage increased (+0.2%) to 90.735% when pulling d0b2c3f3e01e90f979d8123ca65f29e1d120e2bd on improve-recognition-of-dynamic-dependencies into b0ff7b8c0a46f39397126b368f7490c6cb342ce5 on master.