Redo cut/paste not working

Testing #111015

In the vscode repo, select src/vs/nls.build.js in the file explorer
Use Cut from the context menu
in the file explorer select a different folder (e.g. src/vs/workbench/test), paste
from the window menu, run Edit > Undo. Move is undone :heavy_check_mark:
from the window menu, run Edit > Redo. Error message is
Could not redo 'Rename nls.build.js to nls.build.jsW' across all files. The following files have been closed and modified on disk: /home/martin/workspaces/vscode/src/vs/nls.build.js.

Maybe related that this is a js file, as it works for other files (e.g. .editorconfig)

Also seems to be timing dependend. It can work, other times not. Sometimes even the undo fails with the same message

Assigning to November to investigte

This works just fine for me on my macOS. I tried it intensively 10+ times both via keyboard and context menu
Also assigning to @alexdima since the error is coming from the Undo Redo service and he might have ideas

This error usually happens when there was a text buffer edit, then the text buffer was closed (disposed from memory), then the text buffer opened again from disk, but the opened file sha1 is different than the closed file sha1. @aeschli Your steps do not mention any text edits, but I wonder if you did some in your initial repro?

This works for me today, yesterday it failed consistently.
Ok to close. I'll try to reach out if I get this again.


TSConfig 'strict: false' leads to an error

Bug Report
🔎 Search Terms
strict generic strictFunctionTypes
🕗 Version & Regression Information
I tried TS 4.9.4 and 4.8.4 on Playground.
⏯ Playground Link
Playground link with relevant code
I asked the question on Stackoverflow, but nobody answered,
💻 Code
import { of, tap, ignoreElements } from 'rxjs';
export class C {
  private bar: number[] = [];
  public foo() {
    return of([1]).pipe(
      tap((x) => (this.bar = x)),
      ignoreElements()
    );
  }
}

🙁 Actual behavior
The code is fine until you turn off 'strict' mode (to be precise 'strictFunctionTypes'). Uncheck 'strictFunctionTypes' and get errors in line this.bar = x:
Type 'unknown' is not assignable to type 'number[]'.
Type '{}' is missing the following properties from type 'number[]': length, pop, push, concat, and 26 more.

I discovered several ways to remove the errors in 'strict=false' mode:

set explicitly type of arrow function argument x (x: number[]) => ...
add another 'empty' tap() just before ignoreElements()
remove ignoreElements() (removes error, alters behavior)

It seems pipe() signature resolves differently with strict mode on/off.
It's pipe<number[], never>(...) when strict=true
It's pipe<unknown, never>(...) when strict=false
I guess one of the reasons is ignoreElements(): OperatorFunction<unknown, never> signature with non-generic 'unknown'.
So I get error-free code with strict=true but it fails with strict=false.
🙂 Expected behavior
The strict flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.
Usually expect more errors in strict mode, but this error appears only if strict mode off.
Is this TS behavior intended? What is the recommended solution?

strictFunctionTypes doesn't mean that there are some errors that would normally appear and are simply suppressed, or not checked for. It's a fundamental change in how functions are assignable to each other. For any strictness flag like, it's straightforward to construct (on purpose) a program that only errors in the non-strict mode, and is certainly possible to write such a program unintentionally as appears to have happened here.

For any strictness flag like this, it's straightforward to construct (on purpose) a program that only errors in the non-strict mode

Nonetheless this case is intriguing; given what strictFunctionTypes does, I wouldn’t expect it to make any assignments succeed that would have failed otherwise.


Created documentation for Search Options feature

Fix #243

To clarify, my question was about considering "Search options" as a subtopic of "Search", not to move everything down under Search.

Search and filters
-- Search
--- Options
-- Filters
--- Translation status
--- Extra filters
--- Tags


Does the component support a day view?

For some reason I can't seem to see any existing issue or any doco that indicates it does? A day view as in it shows a listing of the times of the day from 12am - 12pm, in half an hour increments, similar to the one in the apple calendar app.

@squaredonut what do you mean by a dayView? Do you have a screen shot of what you are looking for?

Like this
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSkcuvKwvLXZ04-mybSg_PHXxt-ogOUdyDHGL_NCe9t-O1QrNNCsRPp404_Ag

Oh. sorry.
yea, its not able to do this.
When building this library, I didnt think it would be good to put this feature in as I think I can be placed in a separate library.
I believe that it is a totally different library/control/view that can expand in its own way.
What do you think?

@patchthecode yeah definitely sounds like a good idea if it becomes hard to abstract the controls API accomodate, both layouts.
Admittingly I'm not that experienced at all with iOS development, so wouldn't know the exact approach with authoring something similar to this.

@squaredonut yes, Same thing I was saying. I think the 2 controls should be separate. The API would be different, and cramming them both together would seem odd.
I would consider creating a separate control, but this would be some time in the future. Sorry the library could not be of help to you man. But if ever you do start using it, leave a star rating if you like it :)
I'll get to work on that other control some time in the future.


(#319) updated incomplete messages for config profiles

#319

@excelsior fixed not showing information about organization, suppressed nth for now as more likely whole UX need to/will be updated.


Updated POSH Script Examples

Updated syntax of POSH scripts in the article after noticing additional backtick that isn't required.

Hi @MGoedtel, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (magoedte). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

Matt, can you please use the private repo for this?

@MGoedtel Matt, Please submit this through the private repo


gradle project not detected for sub-folder

Extension Name: vscode-gradle
Extension Version: v3.12.1
OS Version: Windows 10
VSCode version: 1.67.2
Describe the bug
I'm not sure if this is a bug, or something that isn't suppported.
I have a root directory (non-gradle), but with sub folder that is a gradle projects, but when on vscode, the gradle project icon/view is not activated.
See sample project for example
Expected behavior
Gradle project view should be activated
Screenshots
This is the view in vscode

Notice the left bar does not include gradle extension icon

Output from "Gradle for Java"
[info] [gradle-server] Server started, listening on 53345
[info] Gradle client connected to server
[info] Build file opened: z:\spring-boot-consumer-driven-contract-demo\scc-provider\build.gradle
[info] Build file changed: z:\spring-boot-consumer-driven-contract-demo\scc-provider\build.gradle

Does the bug still exist if you disable all other extensions?
Yes
Additional context
If I open the individual sub folder as the root project, then the extension will be activated as usual.

Looks like it's caused by the extension does not detect the project in workspace: https://github.com/microsoft/vscode-gradle/blob/9ecf3b73d0dda2af10091dcf1db570750679e0eb/extension/src/Extension.ts#L229


any way to get this to work with the latest version of xcode?

tried getting it to work with the latest version of xcode but cannot get it working

I will look into it these days, thanks for reporting this issue ! @armaandh

AltLayer Airdrop Season One Update

🚀 Exciting Announcement! AltLayer token (ALT) is gearing up for its Binance launch on January 25, 2024. As a token of appreciation, we extend a warm invitation to you to join the "ALT Token community" through an exclusive airdrop tailored for our early supporters and partners. Here's a quick overview:

Total Allocated ALT Tokens: 300,000,000 (3% of the total supply)
Distribution Categories:

Ethereum Mainnet
Binance Mainnet

For a comprehensive breakdown of criteria and further details, refer to the complete announcement Oficial Website.
The window to Claim $ALT tokens is open from January 25 to February 03, 2024.
Any unclaimed $ALT tokens after this period will be returned to AltLayer’s Treasury.
We deeply appreciate your contribution to AltLayer's success! Stay tuned for more exciting developments in Season One.
Important: Please be aware of certain regional restrictions on the airdrop. Review the disclaimer before participating.
shuaishuailiu, @benjaminwhx, @slince, @lioitily, @Redbaron0601, @mniya, @lingtingSir, @cnn911, @1anyway, @onlylemi, @xiong3134, @dequan, @XieChengYi, @aemoe, @ljz779848255, @YanceyHan, @lkun, @kensla, @vueadmin, @zhangmin510


very wide column breaks background

doc/groovy/BigTable.ipynb
run last cell, scroll the table horizontally.
the right part of the cell bkg that was hidden before, when it is revealed, is shaded dark incorrectly.


fusuma: init at 0.10.2

Motivation for this change
In contrast to libinput-gestures fusuma supports repeating commands which for example makes pinch to zoom much more pleasurable.
Things done

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

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

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

cc @teozkr

@GrahamcOfBorg  build fusuma

Success on x86_64-linux (full log)
Attempted: fusuma
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/yqphkpvgw9hrlbv32i3y8v36kl5swhs9-ruby2.5.3-fusuma-0.10.2
patching script interpreter paths in /nix/store/yqphkpvgw9hrlbv32i3y8v36kl5swhs9-ruby2.5.3-fusuma-0.10.2
/nix/store/yqphkpvgw9hrlbv32i3y8v36kl5swhs9-ruby2.5.3-fusuma-0.10.2/lib/ruby/gems/2.5.0/gems/fusuma-0.10.2/exe/fusuma: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/imzyjwl9yv28h02zwsjpdsb2va7s8rqk-ruby-2.5.3/bin/ruby"
/nix/store/yqphkpvgw9hrlbv32i3y8v36kl5swhs9-ruby2.5.3-fusuma-0.10.2/lib/ruby/gems/2.5.0/gems/fusuma-0.10.2/bin/setup: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/r47p5pzx52m3n34vdgqpk5rvqgm0m24m-bash-4.4-p23/bin/bash"
/nix/store/yqphkpvgw9hrlbv32i3y8v36kl5swhs9-ruby2.5.3-fusuma-0.10.2/lib/ruby/gems/2.5.0/gems/fusuma-0.10.2/bin/console: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/imzyjwl9yv28h02zwsjpdsb2va7s8rqk-ruby-2.5.3/bin/ruby"
checking for references to /build in /nix/store/yqphkpvgw9hrlbv32i3y8v36kl5swhs9-ruby2.5.3-fusuma-0.10.2...
building '/nix/store/b83z495ydmdcwvcdx3x7xlzvcran5fjr-fusuma-0.10.2.drv'...
created 9 symlinks in user environment
building '/nix/store/3y0cs5628fk06fcdhb0s32xw2q2vjzir-fusuma-0.10.2.drv'...
/nix/store/9pf124lhvd10iipgrd1s8dfg903xly5v-fusuma-0.10.2

Success on aarch64-linux (full log)
Attempted: fusuma
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/jxkc45y87y9k66zsr8c793i5ahcd2g65-ruby2.5.3-fusuma-0.10.2
patching script interpreter paths in /nix/store/jxkc45y87y9k66zsr8c793i5ahcd2g65-ruby2.5.3-fusuma-0.10.2
/nix/store/jxkc45y87y9k66zsr8c793i5ahcd2g65-ruby2.5.3-fusuma-0.10.2/lib/ruby/gems/2.5.0/gems/fusuma-0.10.2/exe/fusuma: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/51sgjlq650kkxs7iz2wcz33lx74awn57-ruby-2.5.3/bin/ruby"
/nix/store/jxkc45y87y9k66zsr8c793i5ahcd2g65-ruby2.5.3-fusuma-0.10.2/lib/ruby/gems/2.5.0/gems/fusuma-0.10.2/bin/setup: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/dsyc1z7ck08ga7l0b1jcxx35wj69qcii-bash-4.4-p23/bin/bash"
/nix/store/jxkc45y87y9k66zsr8c793i5ahcd2g65-ruby2.5.3-fusuma-0.10.2/lib/ruby/gems/2.5.0/gems/fusuma-0.10.2/bin/console: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/51sgjlq650kkxs7iz2wcz33lx74awn57-ruby-2.5.3/bin/ruby"
checking for references to /build in /nix/store/jxkc45y87y9k66zsr8c793i5ahcd2g65-ruby2.5.3-fusuma-0.10.2...
building '/nix/store/fhr6hy46y355rj2v2r94d7kxj0irfy5x-fusuma-0.10.2.drv'...
created 9 symlinks in user environment
building '/nix/store/3cgf9cnm0xymyaw2nfjyc6hj247zy63a-fusuma-0.10.2.drv'...
/nix/store/mjg68q8j7kp2k4hw06lqfjan953iqwhy-fusuma-0.10.2

Seems to build.
However, this makes me think this might need a nixos module.
Also a systemd service might be useful

Yes, I’ve been thinking about that and will create a module when I find the time. For now I am simply using my DE for autostarting it.

Yes, I did and it works fine.

Ok merging the package then. @jfrankenau please open a new PR once you got the time to write a service module to go with it :)


The pre-filled definition URL in swagger UI is incorrect.

Prerequisites

[X] I have written a descriptive issue title
[X] I have searched existing issues to ensure the bug has not already been reported

Fastify version
4.8.1
Plugin version
1.0.2
Node.js version
16.15.1
Operating system
macOS
Operating system version (i.e. 20.04, 11.3, 10)
12.6
Description

The URL of the definition json pre-filled on the swagger UI is incorrect and has an extra static path component in it.
Pre-filled: http://<IP_ADDRESS>:8080/docs/static/json. Expected: http://<IP_ADDRESS>:8080/docs/json

Steps to Reproduce
await fastify.register(require('@fastify/swagger'), {
    mode: 'dynamic',
    openapi: {
      info: {
        title: 'api.example.io',
        description: 'Example API',
        version: packageJson.version,
      },
      components: {
        securitySchemes: {
          apiKey: {
            description: 'Your API Key',
            type: 'apiKey',
            name: 'Authorization',
            in: 'header',
          },
        },
      },
    },
    hideUntagged: true,
  })

await fastify.register(require('@fastify/swagger-ui'), {
    routePrefix: '/docs',
    uiConfig: {
      deepLinking: true,
      filter: '',
    },
  })

And goto http://<IP_ADDRESS>:8080/docs
Expected Behavior
No response

PR #12 should fix that.


Dead Links in "Implementing your own DDP" documentation

📚 Documentation
In the "Implementing your own DDP section" (https://pytorch-lightning.readthedocs.io/en/stable/multi_gpu.html#implement-your-own-distributed-ddp-training), the text says:

If you need your own way to init PyTorch DDP you can override pytorch_lightning.core.LightningModule.().
If you also need to use your own DDP implementation, override: pytorch_lightning.core.LightningModule.configure_ddp().

Unfortunately, both of those seem to be dead links. I'm not sure what would replace them -- the custom DDP implementation should presumably point to https://pytorch-lightning.readthedocs.io/en/stable/accelerators.html#implement-a-custom-accelerator, but I'm not sure where the "overriding the init Pytorch DDP" should live (from the Git blame, it looks like used to call to a init_ddp_connection function that doesn't seem to exist anymore).

@alanhdu mind send a PR?

@Borda -- what should the updated links point to? Presumably the configure_ddp should point to the custom accelerator docs, but I don't know where the first link ("init Pytorch ddp") should go.

Maybe here:
https://github.com/PyTorchLightning/pytorch-lightning/blob/2c11d96012f629264e57601d68074ef73bb17659/pytorch_lightning/plugins/ddp_plugin.py#L73


[BUG] Multiline with statement

Describe the bug A clear and concise description of what the bug is.
pycln cannot parse a multiline with statement.
To Reproduce Steps to reproduce the behavior:

Take this code snippet:

with (
  mock.patch("m1") as mock_m1,
  mock.patch("m1") as mock_m2,
):
  print(mock_m1)
  print(mock_m2)

Error traceback or unexpected output (if present):

SyntaxError: invalid syntax 'mock.patch("m1") as mock_m1,'

Expected behavior:

Description: Expected no failure message

Environment (please complete the following informations):

Python Version: 3.11
Pycln Version: v2.1.3
OS Type: Linux Redhat Centos 7

Additional context Add any other context about the problem here.

Upgrading to 2.4.0 seems to solve the issue.


Customize/pluggable SDK output

The considerations written below are wonderings of mine about the possibilities this tool could offer. Please let me know if they are out of scope or overthinking.

The current methodology used for code generation is kinda restrained to a fixed output format. Although the current output is actually fine, on bigger problems this could, quickly, get harder to use or augment.
My proposition is parametrization of each (possible) step of the flow from analysis to code generation. This would allow creation of custom plugins to add more powerful features to the final output without too much effort.
Here are some examples of pluggable features:
Runtime validators
Using the definitions extracted from the controllers, create runtime validation helpers to facilitate integration with reactive frontends, providing input errors in realtime without need for calling the API.
Many validation libraries could also be used for this integration.
Empty model generator
Also intending to ease integration with frontends, this would expose a method that could initialize forms with valid empty fields, expanding the objective of remove code repetition, since would've already defined how this object should be.
Random data generator
A plugin could provide decorators to specify methods of generating random (or not) examples of usage of the exposed methods/schemas.
This one could be used on prototypes, automated tests, to extend documentation descriptions, and more.
One example of lib to use in this is faker-js.
Choose data fetcher
Currently nestia uses it's own fetcher, but should be possible to customize or even switch it with another to specify any internal requirement.
Intercept requests/responses
This would be like middlewares for client side, allowing the developer to have more control on error handling strategies, offline behavior, state management, etc.
Prototyping mode
Using the some of the already described above, this one would allow to generate automatic responses on the frontend without even calling the API while working on features that doesn't actually need to persist anything in the backend.
Important
Interceptions
While these features are already possible to implement using service workers, actually doing it isn't trivial, and I think this could be improve the development experience substantially
Separation of concern
All these implementations could be possible, the responsibility of any of them should be on nestia itself, but on independent packages (official or not) that would benefit from exposed options.
Complexity
I agree that this is not an easy thing to implement, and a lot of mental work should yet be made on structuring how this would be possible, but I want to know what the community, and the author, thinks about the development of this idea.
~This issue ended up being bigger than I initially expected, which makes me even more excited about~

Thinking even further, some of these plugins could also benefit the swagger output, or any other format desired by the end developer

@SkyaTura You can turn on runtime validator by configuring nestia.config.ts file like below:
import nestia from "nestia";

export const NEESTIA_CONFIG: nestia.IConfiguration = {
    assert: true
};

When turning on the assert option, SDK functions generated nestia utilizes my another library typescript-json's assertType function to validate parameter types like below code:
import TSON from "typescript-json";

export function store
    (
        connection: IConnection,
        orderId: string,
        goodId: string,
        input: Primitive<store.Input>
    ): Promise<store.Output>
{
    TSON.assertType<typeof orderId>(orderId);
    TSON.assertType<typeof goodId>(goodId);
    TSON.assertType<typeof input>(input);

    return Fetcher.fetch
    (
        connection,
        store.ENCRYPTED,
        store.METHOD,
        store.path(orderId, goodId),
        input
    );
}
export namespace store
{
    export type Input = Primitive<IShoppingOrderGoodRevert.IStore>;
    export type Output = Primitive<IShoppingOrderGoodRevert>;

    export const METHOD = "POST" as const;
    export const PATH: string = "/shoppings/consumers/orders/:orderId/goods/:goodId/revert";
    export const ENCRYPTED: Fetcher.IEncrypted = {
        request: true,
        response: true,
    };

    export function path(orderId: string, goodId: string): string
    {
        return `/shoppings/consumers/orders/${encodeURIComponent(orderId)}/goods/${encodeURIComponent(goodId)}/revert`;
    }
}
```typescript

Also, I'm tending to utilize SDK generated by nestia when implementing test automation program.
During those implementations, I also feel that random generator utilizing the DTO type would be useful. However, nestia only understands primitive type. Therefore, it can generate random literal, string or numeric values, but it can dissapoint developers when special logic random data required.
If you have any good strategy about the random data generator, please tell me.
Also, how do you think about that publishing a new library for the random data generator using TypeScript DT type?

Fetcher & Interceptor
To accomplish this mission, there would be two ways:
The 1st is supporting more options on the IConnection structure, as functional instance. The 2nd is configurating such options in the nestia.config.ts level. Interceptor, 1st option would be suitable for it. About using whether fetcher or axios, 2nd option would be better.
I'll try 1st option with interceptors after #128.

Random data generator
Also, I'm tending to utilize SDK generated by nestia when implementing test automation program.
During those implementations, I also feel that random generator utilizing the DTO type would be useful. However, nestia only understands primitive type. Therefore, it can generate random literal, string or numeric values, but it can dissapoint developers when special logic random data required.
If you have any good strategy about the random data generator, please tell me.
Also, how do you think about that publishing a new library for the random data generator using TypeScript DT type?

I think Decorators would be a useful way to customize how random data could be generated.
I know one of the key points of nestia is the minimum usage of additional artifacts, but I think this is a good trade-off for those who want to take advantage of this feature.
Also, I do in fact think a dedicated lib on that matter would be great.

Runtime validators
@SkyaTura You can turn on runtime validator by configuring nestia.config.ts file like below:
// ...

When turning on the assert option, SDK functions generated nestia utilizes my another library typescript-json's assertType function to validate parameter types like below code:
// ...

What I meant was about more specific validations, like zod and joi.

Runtime validators
@SkyaTura You can turn on runtime validator by configuring nestia.config.ts file like below:
// ...

When turning on the assert option, SDK functions generated nestia utilizes my another library typescript-json's assertType function to validate parameter types like below code:
// ...

What I meant was about more specific validations, like zod and joi.

TSON.assertType() can generate validator function automatically by analyzing DTO in the compilation level. However, zod and joi are not.
In that case, should nestia generate schema of them automatically, through TypeScript Compiler API?

Yes, by using transformers, and pluggable hooks, one could create it's own validation strategy, or random data generators or whatever, not necessarily predefined on nestia core itself.
The value in that would be abstract the complexity of analysing the ASTs and extracting useful information from nestjs patterns and ease those compile-time plugins.
That would be similar to what frameworks like Nuxt do to improve developer experience with Vue.
Since the idea seems to be considered promising, I'll try to draft some examples of inputs and desirable outputs over the weekend, to better illustrate and help us to find the best approach to achieve it.

In addition, I found a great example to inspire for annotating things TS can't provide.
https://github.com/fabien0102/ts-to-zod

@SkyaTura Have studied your suggested libraries zod and joi.
As a result of the study, I won't develop automatic zodand joi schema generators, beacuse they can't support complicated structured union object type. As I'd tried to implement automatic JSON schema (ajv), I know that how such libraries are vulnerable to union types.

ajv, zod and joi, all of them can't retrieve optimal search path and analyze inclusion relationships.

Therefore, if user wants to utilize zod or joi, it would better user to define zod or joi schema by user himself. Instead, I will support format comments like ts-to-zod from typescript-json. I'm sorry for cannot accept your suggestion.

Random generator would be support by two ways: through pure type and decorator.
The pure type based random generator would be supported by https://github.com/samchon/typescript-json/issues/174.
The 2nd would be supported by nestia-helper and its decorator maybe @Random. However, using such decorator function can't assure type safety. Therefore, I'm considering how to make it safey.
Also, not only for the random generator case, supporting client library (nestia generated SDK) through decorator function in server side, it seems really an wonderful idea. I think many helper decorator functions for client developers would be developed continuosuly.

@samchon Unfortunately, I had no time this weekend to think further about these as I intended to.
I hope that I can study on my on as well so that I can help you as much as I can in this process. (I'm literally in love with this project)

Anway, the random generator is only for request body data? or for both request and response body data?

I think both would be ideal, since the most useful use case for this feature would be prototyping and automated tests (both on the server and the project that implements this client)
I can think at least in this two scenarios:

pre fill forms with random data to perform demonstrations
generate random responses without an actual server running to improve both developer experience and frontend automated tests

In sake of organization, what do you think about breaking this subject in a dedicated issue to discuss about the specs and requirements on each feature we consider useful, and another to discuss about the tecnicallyties envolved with making them possible in general?


Increment version for communication releases

Increment package version after release of Azure.Communication.Chat

API change check
API changes are not detected in this pull request.


chore(repo): Fix order of steps and details in release process doc

Based on stuff found in manual release of 3.12.0

Made a couple of additional edits to the release sections that were the same type of thing as what y'all made comments on, so I went ahead and dismissed the approvals and asked for a re-review.
Also, I was trying to figure out what was the core of the difference between the regular release flow and the hotfix flow. It seems like it's only the bit about what you choose to include, but "target the hotfix PRs on this branch" is possibly too vague. Everything else seems to be exactly the same between the two (given that the make bump argument choices are abstracted down to the lerna section). Given that, what do y'all think about merging these two sections, but having a more fleshed out section on deciding what goes into the release branch, with notes for regular releases vs hotfix? @mcous @sfoster1

@btmorr main difference between the release and the hotfix flow (aside from slight make bump usage instruction changes is that a release branch is created from edge, while a hotfix branch is created from master

Yeah, the difference between a hotfix and a regular release is that a hotfix should contain only bugfixes for pressing issues. It's the workflow for creating a release with none of the changes that may have been merged since the release branch was split from edge.


Upgrade to ethers v6

Updates the Ethers dependency to v6 so the Ambient front-end can also use v6.

[x] Tests pass
[ ] Appropriate changes to README are included in PR

Doug has approved this PR.


Enforce max tags on all variable length types

This closes https://github.com/spacemeshos/go-spacemesh/issues/4095
scalegen will now enforce a scale:max=x tag on all types that have variable length. These are []T and string. scalegen will abort code generation when the expected tag is missing and print an error explaining the necessity for the tag.

@fasmat there is also another option that doesn't require doing many changes. we can set MaxElements to lets say 1_000 and do best-effort review of the collections. i think 1_000 will be hard to abuse


[LIGHTNODE] Activated users want their correct GRAINs after #2105 fix

Activated wallet https://paloma.explorers.guru/account/paloma1e7d3u4232hqxrh45wwyxzw0q5u7yf2uhqkg58r wants to know how to get his 50K GRAINs after resolution of #2105 issue.
Question: Will the amount be automatically adjusted in Poloma?

@taariq The amount will not be adjusted by Paloma. The vesting accounts are immutable, we can't change the vesting amounts after creating them. The only way will be to activate a new license.


MVKPixelFormats enables atomic capabilities only when applicable.

Consolidates setting VkFormatProperties, and only sets atomic features in linearTilingFeatures and bufferFeatures for MTLPixelFormatR32Uint and MTLPixelFormatR32Sint.
This setting logic was already being done, but was being done by setting the atomic features in all formats by default, and then stripping them away for everything other than those two formats.
In addition, previously, the two formats allowed atomic operations for optimalTilingFeatures too. This has been move to explicitly set only for linearTilingFeatures now.

@cdavis5e
Your previous update triggered me to do a redesign of the way format properties were being set. In particular, since you identified that only two formats should permit atomic writes, I flipped the logic to assume atomic feature is not set by default, and enable only for those two formats using the same enabling mechanism for the other feature flags.
In addition, your description of how atomics are handled on your previous change indicated that in Metal the atomic feature only applies to linear, and not optimal tiling. But in your original code, it appeared to enable for both linear and optimal for those two formats. I've modified the logic to explicitly enable for only linear tiling now.
Everything should still operate as you described in your previous PR. When you get a chance, can you have a look, test, and verify that I haven't broken your initial logic, please? I can modify the linear/optimal enablement if I've messed it up.
Thanks.


Testing with huge ndjson files may cause tests to crash and sessions to hang

The approach that the test suite currently uses is to load all ndjson files into memory (in scratch), and then in subsequent tests read the resources from memory and perform various tests on them.
This makes the test code very readable and concise, but for systems that want to test very large json files, it may cause the tests to use up all memory allocated to a worker.  It is unclear if a system would ever want to do this during testing,  but it is possible.
We would need to do some testing to see how the production system would handle running out of memory. It is possible that the Inferno system as a whole would handle it gracefully, killing and restarting the worker process that ran out of memory, not causing any issues to other testers.  In this best case, the tester that is running the tests against the large data set would have their session get 'stuck' and it might be unrecoverable.  So that's not great.
It is possible that a worse situation could occur, where the worker process isn't properly restarted, and thus preventing anyone from running any tests on the inferno host.  I think this is unlikely, but we would have to test to find out for sure.
A simple solution to protect the system might be to just put in some guards that check the size of the ndjson file, and if it is too big (e.g. > 10mb), just have the test skip.  There are much more involved solutions as well (e.g. streaming data back and only keeping the latest resource in memory, which we do in our bulk data test kit and our smart scheduling links test kit), but that is much more complex to implement in inferno right now.

Hi, We are trying to test entire manifest file in our locally deployed inferno test app. The test suite hangs when we try to do this. Is there any work around or plans to make the suite handle large sets of data more gracefully without crashing ?


Add a URL fetcher class.

Also convert AsyncLogClient to use it.
Still many things can be improved on it (deadlines, retries, cancellations, etc), but at least it provides a reasonable shell for these features to be added.

Comments addressed.

LGTM


connecting SPP to SC

Coverage increased (+0.05%) to 70.339% when pulling 9aa69a6cc4b2eedfd5422a50b15d7960857c934a on achensetyawati:dev into 0d98c974ada122bc8b16027e289f4510ccd562a1 on danliris:dev.


Missing LICENSE file

There is no license file! Please consider adding one.

Ciao @filippobuletto !
This repo is just a Dockerfile, what should we clarify with the license file?
thanks!

LICENSE file added, thanks for heads up! Closing.


Azure Sign in not working on VSCode-insider build

On my Mac, running vscode-insider, with the Azure Account Extension installed, when I attempt to "Sign In" I get the following message:
"You appear to be offline. Please check your network connection."
If I use the Azure CLI, I can log into my Azure account without a problem. I have also tried the extension on my Windows 10 PC and Debian-based Linux system, with the same results.
On my Mac, I have seen a similar behavior in the normal production VSCode release when the GitHub Copilot is installed along with the Azure Account extension.
To reproduce:

Press F1 to bring up the vscode command window.
In the Window, select "Azure: Sign in"

The offline message will then appear in a popup on the lower right side.
The extension information is
Version v0.11.5
Published 9/6/2017, 13:01:27
Last released 5/16/2023, 15:02:49
Last updated 6/21/2023, 14:13:45
Identifier ms-vscode.azure-account
Running in vscode-insider
Version: 1.80.0-insider (Universal)
Commit: 636dbcff557af8aa088ae118b1a094dce6632ce7
Date: 2023-06-21T08:23:42.803Z
Electron: 22.3.13
ElectronBuildId: 21803499
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 22.1.0
On my Mac
Processor: 2.6 GHz 6-Core Intel Core i7
Memory: 16 GB
macOS: Ventura 13.0
Default Browser:
Edge Version: Version 114.0.1823.55 (Official build) (x86_64)
No VPN in use.
Thanks,
Scott Schwab

Closing as a duplicate of https://github.com/microsoft/vscode-azure-account/issues/819. These repos are managed by the same team, so hopefully Alex can help you on the original issue.


Re-grab devices after reconnection

After a device disconnects and reconnects (via suspend, unplugging, KVM, etc) the service is unaware and is not able to read input from the device.

Fixed in 2.0 branch


Add execution mode option to PyHDK python tests

The PR introduces a --device option to pytests to allow for switching between execution modes. The default behavior remains unchanged.
It also provides a quick simple fix (by disabling L0 compilation context caching with enable-gpu-code-compilation-cache=false) to the following problem:
When HDK components are handled manually and the data manager is reinitialized the compilation cache may outlive the GPU manager (since its lifetime is bound to the data manager's lifetime). The compilation context would then try to access an invalid instance L0Device with a valid device handle (the driver returns the same handle on consequent calls).

Is enable-gpu-code-compilation-cache=false a temporary solution?

Yep. The data manager could reset the cache when it's destroyed, but that would create a cycle dependency with executor now. Flushing the cache on executor destruction also doesn't seem right. I think the right thing to do is get rid of the device pointer in the compilation context. There's a couple questions for such a change though that I'll need to address (for example: if we only use the device id to route execution what happens if the new executor has less devices available).

Also, can we choose a device via pyhdk.init() in test suite setup or in another similar way? It feels wrong that users have to choose an execution device in each run call.

We could, but why would you? I think in the end we will have a default setting that allows any possible offloading scheme. If there's any problem with a particular query (i.e. the cost model is very wrong on the device preference), you can force it to run with a specific setting.
We also do have the cpu-only setting for pyhdk.init already, so this is not how a user would use the API. We have these options present here only to simplify testing and make it explicit.

Yep. The data manager could reset the cache when it's destroyed, but that would create a cycle dependency with executor now.

You can do it by adding a new GpuCodeCache interface that Executor would implement and then clear the executor's cache through this interface to avoid the cycle dep. We've used a similar trick with Executor before.

We also do have the cpu-only setting for pyhdk.init already, so this is not how a user would use the API. We have these options present here only to simplify testing and make it explicit.

I don't feel the testing is more simple if I have to add an additional arg to each test function, each sql call, and each run call. It is just a global testing option, why not set it once somewhere?

You can do it by adding a new GpuCodeCache interface that Executor would implement and then clear the executor's cache through this interface to avoid the cycle dep. We've used a similar trick with Executor before.

https://github.com/intel-ai/hdk/issues/520

I don't feel the testing is more simple if I have to add an additional arg to each test function, each sql call, and each run call. It is just a global testing option, why not set it once somewhere?

It's not "each test function", only those that need the option. It is also not a global testing option. It may seem so now because we currently allow CPU fallbacks. Simplicity should come with explicitness. I'd like to forbid fallbacks in tests later on so that we are sure a query runs on the device we asked for. Some of those we will want to fall back. Having a global setting seems inconvenient for that.
I agree that it would be nice to type less. I initially added the cpu-only as a "parameterize" clause for that very reason. Yet setting cpu-only globally changes data manager behavior (we don't create a gpu manager at all), so it's less flexible and doesn't cover the "have-gpu-manger-but-run-on-cpu" case. It also wouldn't allow running both cases in the same env -- you'd need a reset as we don't expose the config.
There're a couple of more-or-less straightforward ways to set the device type once of course. Is it worth it though?


Issue with Decorator when testing component

I actually got same issue as the paradoxm in closed Issue #81
I have 1 unit test which doesnt raise this issue on the component which is decorated with UntilDestroy(). This component doesnt have any component level providers. Simple
And in another case it breaks with same error mentioned in the original ticket.
The only difference in two tests I noticed - it happens whenever you override components to inject component providers after TestBed.configureTestingModule({}) and before compileComponents().
In other words in case you have component decorated and you inject any providers component-level (services) it doesn't play  nice
Originally posted by @f1ght4fun in https://github.com/ngneat/until-destroy/issues/81#issuecomment-625684644

How do you expect us to help you if you provide any reproducible example? :thinking:
:slightly_smiling_face:

Apologies. I cannot post real example so I was doing a mocking scenario to show you ;)
Working Component and Test:
@UntilDestroy()
@Component({
selector: 'app-working-component',
template: 'banana',
changeDetection: ChangeDetectionStrategy.OnPush
})
export class WorkingTestComponent implements OnInit {
ngOnInit(): void {
interval(1000)
.pipe(
untilDestroyed(this),
take(10),
tap(() => console.log('test'))
)
.subscribe();
}
}
Test:
describe('WorkingTestComponent', () => {
let component: WorkingTestComponent;
let fixture: ComponentFixture;
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [WorkingTestComponent]
}).compileComponents();
fixture = TestBed.createComponent(WorkingTestComponent);
component = fixture.componentInstance;

});
afterEach(() => {
fixture.destroy();
});
it('should create', () => {
fixture.detectChanges();
expect(component).toBeTruthy();
});
});
Not Working Component and Test (including Service as a provider for Component):
Service:
@UntilDestroy()
@Injectable()
export class TestService {
interval$: Observable = interval(1000);
constructor() {
this.interval$.pipe(untilDestroyed(this)).subscribe(() => {
console.log('log from service');
});
}
}
Component:
@UntilDestroy()
@Component({
selector: 'app-not-working-component',
template: 'banana',
providers: [TestService],
changeDetection: ChangeDetectionStrategy.OnPush
})
export class NotWorkingTestComponent implements OnInit {
constructor(private testService: TestService) {}
ngOnInit(): void {
this.testService.interval$
.pipe(
untilDestroyed(this),
take(10),
tap(() => console.log('test'))
)
.subscribe();
}
}
Test NOT WORKING:
@Injectable()
class MockService {
interval$ = interval(3000);
}
describe('NotWorkingTestComponent', () => {
let component: NotWorkingTestComponent;
let fixture: ComponentFixture;
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [NotWorkingTestComponent]
})
.overrideComponent(NotWorkingTestComponent, {
set: {
providers: [{ provide: TestService, useClass: MockService }]
}
})
.compileComponents();
fixture = TestBed.createComponent(NotWorkingTestComponent);
component = fixture.componentInstance;

});
afterEach(() => {
fixture.destroy();
});
it('should create', () => {
fixture.detectChanges();
expect(component).toBeTruthy();
});
});

Sorry, I ain't able to reproduce it. This would be great if you'd have provided a reproducible example (git repo).

okay, that is totally weird. this is the actual code i have and running which gives me this error.
not sure what else i can do and how making a git repo going to help with that since its already not working for you

Weird what? I don't have time to create the project manually, copy-paste that code and try to reproduce it locally. What I would like to see is a link to git repository and instructions:

yarn install
yarn ng test
See the error

This is normal policy. In most projects issues reported without a reproduction are closed immediately, e.g. if you open an issue in Angular's repository.
Since I give of my personal time to work on these issues and I would rather be spending my time fixing issues than chasing down the unreproducible issue. :wink:

Hey,
I do understand it is hard for you to do it w/o reproducible scenario but I wouldn't continue previous ticket or open a new one if it was working =)
It also kinda took some time to make a scenario to reproduce and now the project to run it gracefully. Anyways I am attaching zip with solution ... just npm i and than ng test to see the issue
TestExample.zip

Thanks for reproduction. I was able to reproduce it, this is clearly a bug.

As i was saying it happens only in case you override component with injections having decorator.
In case you unit test just service that is decorated, or just a component that is decorated but without providers - it works fine.
Tried to also debug this if it is of any help and it seems that it actually fails on the component rather than service.
Wild guess is that override component from test suite somehow removes decorator when you override - but needs more investigation

Yes, overrideComponent overrides metadata and component definition, thus it loses everything that UntilDestroy decorator has applied:

Honestly saying don't know what to propose here.
@NetanelBasal do you have any thoughts?

You can invoke it manually:
    TestBed.configureTestingModule({
      declarations: [NotWorkingTestComponent],
    })
      .overrideComponent(NotWorkingTestComponent, {
        set: {
          providers: [{ provide: TestService, useClass: MockService }],
        },
      })
      .compileComponents();

    UntilDestroy()(NotWorkingTestComponent); <======

Thanks,
it is a workable solution to overcome this issue!

Hi, got same issue with spectator. Fixed with UntilDestroy()(MyComponent) before createComponent() invoke.
// my.component.ts
@UntilDestroy()
@Component({...})
export class MyComponent implements OnInit {
  interval$ = interval(1000)

  ngOnInit() {
    this.interval$.pipe(untilDestroyed(this)).subscribe()
  }
}

// my.component.spec.ts
describe('MyComponent test', () => {
  let spectator: Spectator<MyComponent>;
  const createComponent = createComponentFactory(MyComponent);

  beforeEach(() => {
    UntilDestroy()(MyComponent); // <- Here

    spectator = createComponent();
  });

  it('should create', () => {
    expect(spectator.component).toBeDefined();
  });
})


Unable to connect

[MDWamp transportDidFailWithError:] DID FAIL reason received bad response code from server 426
some("received bad response code from server 426")

Hello @VikranthKumar05 ,  426 mean Upgrade Required. I think the server currently support Wamp v1 while the lib working on Wamp v2.

Is there a version of MDWamp which could be used for Wampv1?

Branch v1 does.

I couldn't find a branch with name "v1", I am using cocoapods, since the project is in swift.

Getting this for cocoapod v1.1.0

Check if SocketRocket has been pulled ?

SocketRocket is there. I added the files manually from v1.0.1 and also tried using v1.0.1 but none of the delegate methods is being called.


Remove the custom metrics protobuf now that we think no one is using it

It looks like the last team still using the old int-style metrics from v0.7 of OTLP finally stopped.
I think this means that we could, at long last, remove our unholy custom protobuf for metrics ingest.
There are probably more queries to do that we can use to make sure that there aren't other AWS-related things still dependent on it.

We should also update our docs to say we only accept OTLP v1.0+ (int-based metrics were removed in v0.17).
Note: we won't officially be off the custom OTLP until shepherd is updated with a new release of Husky.

We learned that customers are still using the deprecated labels field from old OTLP

https://honeycomb.quip.com/oE5HAS68Tpwj/OTLP-proto-deprecation-guidance


Loopdefer affects the performance of connection creation

when i used a lot of defer to publish message, new connection cannot be ESTABLISHED,  i tried upgradeAsync and upgradeSync,  How should I solve the problem, can you make some suggestions?Thanks

Do you have a second thread with a loop that just calls publish all the time?

Do you have a second thread with a loop that just calls publish all the time?

 You can look at the Backpressure.js example of the JS repo.

 You can look at the Backpressure.js example of the JS repo.


Add a script to filter clinical papers

The filter_clinical.py script uses the text.csv file from the nqdc extract command and checks if a minimal number of different words from the clinical_vocabulary.txt file is found. It generates a new csv file with a 'pmcid' and a boolean 'clinical' column.

closes #11


zziplib: CVE-2018-17828

(cherry picked from commit f0d386ab9108fba0d0a71b5b323026a8cdf8d7a4)
Motivation for this change
Fixes #61961.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

This reference will be incorrect. Please cherry-pick after it has been merged into master.

Not necessarily, if merging was used, but I decided to amend some problems in the commit directly.  Picked as 152d76dd.


Results count

This PR adds a pathQueryCount method to the InterMine data source and uses it to compute pagination info for queries in place of the finicky summaryPath queries.
I haven't been able to thoroughly test this but I've confirmed it works on all queries that our Web Components are using.

I've glanced over it, looks like the meat of the change was in src/data-sources/intermine/intermine.server.ts and the rest was just updating all the code that was affected, monotonously. I am happy to trust that your testing was more thorough than mine likely would be. But let me know if there's anything in particular you wanted me to look over.

My testing was pretty brief this time around. It compiles and runs, and the queries the Web Components rely on are working, so let's go ahead and merge. FYI the coding wasn't too bad. I used sed to do most of the refactoring ;)


Tweak colors to match new IQX colors

From https://github.com/Qiskit/qiskit-terra/pull/3196#issue-324844793, @nonhermitian says:

Match the upcoming changes to IQX circuit composer styling.

The closed PR #3196 suggests a new set of colors the the MPL circuit drawer. However, the PR got out-of-sync.
Please, use PR #3196 as a reference to set the new colors and run binder (see https://github.com/Qiskit/qiskit-terra/pull/4544 as reference) to create the new reference images.

Hi @1ucian0, can you assign me this one?

Hi @1ucian0 can I work on this?

Feel free to port #3196 to current master (dont forget to keep the original authorship for credit). I assume the color scheme is coming from https://quantum-computing.ibm.com/

@1ucian0 I managed to change the colors for the gate backgrounds. It works fine but in the IQX(White Theme) the classical gates have a white font color whereas all the other gates seem to have a black font. I am not exactly sure how to do this for QuantumCircuit(). I can however do the dark theme of IQX since it only has one font color.

Update So Far:

https://github.com/abhobe/qiskit-terra/blob/fixissue5032/qiskit/visualization/qcstyle.py

https://github.com/abhobe/qiskit-terra/blob/fixissue5032/qiskit/visualization/qcstyle.py

Thank you for the update @abhobe.
I've been working on this after @1ucian0 assigned it to me. There's another thing I wanna ask is if we also need to add letter 'z' to the measurement symbol? Not just changing colors, correct?

Just colors

@galeinston I know you have been assigned to this issue, but I couldn't help but try to solve this myself (Since I have never contributed before) . I am not going to create a PR but wanted to let you know that I have managed to get colors and font colors to work and match IQX.

@abhobe It's too bad that today is the day I'm finalizing the PR. My apologies :(

@abhobe It's too bad that today is the day I'm finalizing the PR. My apologies :(
@galeinston
If it is okay with you, can I create a PR. If not , that's fine with me. I understand :)

@abhobe My PR is waiting for a review. If there is something wrong with my PR that I can't fix it, you are more than welcome make one.

I'm not sure what the rationale for this is. When I started working on the mpl drawer, we had a clear definition for colors, Pauli-green, Clifford-blue, U-gates-red, measure/reset-black, and all else purple. I feel like purple could be split into a 2 or 3 colors, but other than that, this fits functionality with color.
For the IQX colors, first off the only spec we seem to have is the IBM page shown above. This doesn't explain what an mcx with 3 controls, for example, should be colored. What about sx, sxdg, iswap, ccswap, etc.?
For me, the real question is - is Classical, Phase, Hadamard, Quantum a better breakdown for visualizing a circuit? If the consensus is that it is, then we need a complete spec for the colors, or if everything that's not shown is red, it seems there might be an excess of red.

@enavarro51 I tend to agree with you, the current color scheme makes more sense to me and is clearly defined. If we're going to change the color map again, we should define the rules for it so it can be applied consistently to all the gates. IMO it's not an issue if the IQX composer and the mpl drawer backend use a different colormap. I could see it being important for iqx to have a consistent colormap between the composer and mpl drawings in the hosted notebooks, but instead of trying to update the mpl drawer every time there is a design change, I feel like we should facilitate the ability to easily set a per environment default colormap. I'm thinking like adding the ability to set a style sheet via the user config file or something.

@mtreinish @1ucian0  @nonhermitian I like the idea of style sheets. We can have a default color map we supply, but then users can modify it in a way that groups the gates any way they like. Something like the dicts in qcstyle could be a good starting point.
In regards to this PR, do we want to proceed with changing the colors as they were being done in #3196, keeping the current mpl drawer Pauli, Clifford, U-gates, etc. groupings, or do we just stay with the current mpl colors?

I'm also on board with the style sheet.
Quick question in regard to 'cu1' in the current official version, was it intentional to  have the text oddly appeared as indicated in the following picture? (the gate with the text 'u1 pi/2' next to a vertical line)

Update So Far:

Yes, that's the correct way for cu1 and rzz gates.


Add missing default value for moto.ec2.models.VPC.classic_link_dns_su…

…pported
Fixes #2629

Coverage decreased (-0.03%) to 94.139% when pulling f60ef02f9d95cb99e551f442f6c3e83cc1d1bf8f on kislyuk:patch-1 into 4d5bf1c5c6f0fb1e60951635ca70a74cddddb461 on spulec:master.

Can you show me how to do that? The test at https://github.com/spulec/moto/blob/d86852bfa0fd79c62b8a5931d12d2c8a25b47833/tests/test_ec2/test_vpcs.py#L797-L804 seems to already assert this, but the problem is that the response on the wire contains an empty string instead of false. From what I can gather, it looks like moto (or boto3?) does type coercion loosely enough that the empty string gets coerced into False, but the Go SDK (for example) does not.

Sounds good -- as long as an existing test is confirming the change, then all is good.


Builds version 2.7.0 and 2.7.1 have old ontologies

KG2 builds KG2.7.0 and KG2.7.1 were built on kg2steve.rtx.ai, which had ontology files from Sept. 2020 on it.

Fixed by using a brand-new Ubuntu 18.04 instance for the build, as described in detail in #104


How to include data files in non-standalone app

I have a pretty large python application with multiple sub-packages, etc. And I want to create a binary from it. Not a standalone binary, but the one that is intended to be used in the same python environment with all the dependencies installed on the Docker container.
The use-case is as simple as I want to protect my python code, but let anyone use my library as-is.
With your beautiful tool, I can make it, however, there is one major concern. My application has data files, and those, as far as I understand, can be included in a binary only in the standalone/onefile mode.
So my question is: Is it possible to somehow include the data files I have, so I can use the compiled binary as intended?
One possible solution will be to restore the whole project structure and stick to --file-reference-choice=original. But I want to use --file-reference-choice=frozen and not expose any structure to an end-user. Are there other possibilities to resolve the issue?

The Nuitka commercial offering has data hiding and a plugin to include data files inside the binary. It isn't yet advertised here, but will be when get around to updating it: https://nuitka.net/pages/commercial.html


Pr publish imu transform

Added feature to publish the IMU transform to a passed world frame. Both world frame and boolean "publish_imu_transform" added to ros and ros2 launch files for the inertial_stereo_node. Parameters are added to IMU and BridgePublisher constructors so recommend PR for dephai-ros first.

Closing for similar reason mentioned in PR #88  of depthai-ros.


install: Add support for LUKS

install: Drop impl Default for Filesystem
We require this to be configured externally now.

install: Add support for LUKS
This currently requires systemd 253 for
https://github.com/systemd/systemd/commit/03f36e9c0174f983e832c6ced80492ebefd34e46

One thing I'm a bit uncertain about here is that while systemd-cryptenroll is a much nicer replacement for the bash scripts in https://github.com/latchset/clevis it doesn't scope in NBDE/Tang like clevis either.  With my RHEL-families hat on it seems almost certain at least some images will need to support that.
Maybe one thing we end up doing with the install code is having things be more explicitly pluggable, so "tpm2-luks" can be backed by either systemd-cryptenroll or clevis.  It's probably not too hard to also add clevis support and then make this another install config option.

This installs but fails to boot, looks like cryptsetup is refusing to mount because it wants a keyfile or pin.  Tried also injecting luks.options=tpm2-device=auto but no luck.  Going to need to debug the cryptsetup generator I guess.

OK this needed https://github.com/cgwalters/bootc-demo-base-images/commit/ff46f764500e557270b5097a7bdf4b21c154403c


[Android] Gradle APK Sign issues since upgrade to 0.59

🐛 Bug Report
The android signing process seems to be broken since react-native version 0.59.0. I've upgraded from 0.57.8.
After upgrading the project, this did not work anymore. The passwords are getting passed correctly to the gradle taskGraph part. They seem to be overridden or assigned too late in the build process.
My guess is there was some change in gradle, which changed the build order. Thanks for your help.
To Reproduce

Initialize react native project
Configure your project for app signing
Build using the following:./gradlew assembleRelease -PkeyPass=mySecretKey -PkeystorePass=mySecretKeystorePass

Expected Behavior
Signing should work.
Stack Trace
> Task :app:packageRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:packageRelease'.
> com.android.ide.common.signing.KeytoolException: Failed to read key com.foo.app from store "/Users/foo/app/store.keystore.": Keystore was tampered with, or password was incorrect

Code Example
// android/app/build.gradle

gradle.taskGraph.whenReady { taskGraph ->
    if (taskGraph.hasTask(':app:assembleRelease')) {
        android.signingConfigs.release.storePassword = keystorePass
        android.signingConfigs.release.keyPassword = keyPass
    }
}
...
android {
    ...
    signingConfigs {
        release {
            storeFile file(MY_STORE_FILE)
            keyAlias MY_STORE_ALIAS
            storePassword ''
            keyPassword ''
        }
    }
    ...
    buildTypes {
        release {
            ...
            signingConfig signingConfigs.release
            ...
        }
    }
    ...

Environment
  React Native Environment Info:
    System:
      OS: macOS 10.14.2
      CPU: x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
      Memory: 12.72 GB / 32.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 8.12.0 - /usr/local/bin/node
      Yarn: 1.15.2 - /usr/local/bin/yarn
      npm: 6.7.0 - /usr/local/bin/npm
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        Build Tools: 23.0.1, 26.0.2, 26.0.3, 27.0.0, 27.0.2, 27.0.3, 28.0.2, 28.0.3
        API Levels: 14, 21, 23, 25, 26, 27, 28
    IDEs:
      Android Studio: 3.3 AI-182.5<IP_ADDRESS>64788
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.8.3 => 16.8.3
      react-native: ^0.59.1 => 0.59.1
    npmGlobalPackages:
      react-native-cli: 2.0.1
      react-native-create-library: 3.1.2
      react-native-git-upgrade: 0.2.7

Can you create a repro of this issue?
I feel it may be something that is related to your project upgrade process, as I didn't experience a similar issue.

what I found is that gradle.taskGraph.whenReady doesn't work anymore. haven't find the solution yet.

Did you try to see if entering your password directly in build.gradle makes it work? Because we are at 0.59.2 and everything works without any problems. We are using System.getenv calls in signing configuration.

yeah I realized the problem is with android.signingConfigs.release.storePassword = keystorePass, it just doesn't set the value to the release config.

It seems to me that then it's not a react-native issue...?
I'm going to close this since there is no repro, but I'll reopen if there is one 🤗

I had the same issue, the problem was due to gradle cache, I tried to build my app while hard-coding a wrong password in the app gradle file and that password got cached in the gradle build process. So I just cleaned the project from android studio and the new gradle config took affect, which generated a signed apk successfully.
I just ran grep to find out where was the old keystore path saved, as it turned out: in some build folder
grep -r "keystores/release_keystore_3.jks" .

Returned this
./app/build/intermediates/signing_config/release/out/signing-config.json:{"mName":"release","mStoreFile":"/somepath/keystores/release_keystore_3.jks","mStorePassword":"","mKeyAlias":"test","mKeyPassword":"test","mStoreType":"pkcs12","mV1SigningEnabled":true,"mV2SigningEnabled":true}

So try to clean the project from android studio and then run ./gradlew assembleRelease

Any solutions?

I have the same issue in "react-native": "0.59.5".
I had no problem signing the apps in previous versions. double checked everything, created another keystore, but not working

The same problem for me, just updated to a 0.59.8 and my release build doesn't work anymore

Thanks, @abdurahmanadilovic, your solution works!

./gradlew clean in android folder and rebuild

./gradlew clean worked for me


Uncaught (in promise) Error: [vue-clipboards] Invalid value. Please use a valid value.

Since I use v-if in my DOM, vue clipboards will throw an error like this when the copy-text-data haven't ready. Must users use vue-clipboards when the copy-text-data is ready?
Actually, I can make fake data for the vue clipboard to copy inside mounted. But it is not a good way. Could you please handle this situation where the copy data is not ready for vue-clipboards. Thanks!
Btw, the version I am using is 1.2.4

Well, as you can see, our latest release is v0.2.1.
I'm afraid of that I can't help you before we have a v1.2.4 release.

If you have any problem with vue-clipbaords, report it at https://github.com/zhuowenli/vue-clipboards


Local file snapshot generating error.

Describe the bug
Local file snapshot did not generated.
To Reproduce
Steps to reproduce the behavior:

go to data preparation menu
select data flow and data set
click snapshot button
select local and csv

Expected behavior
snapshot should be generated
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Integrated test passed.


packit: Don't attempt to build on f39

It only has go 1.21 while we switched to go 1.22, so gvisor-tap-vsock
fails to build on f39.
I don't expect significant changes to gvisor-tap-vsock during the
remaining f39 lifetime, at worse podman in f39 can keep using an older
gvproxy release.

I added f40, but we can revert this commit once f41 is released.

I added f40, but we can revert this commit once f41 is released.

But even f41 release, f-39 will be EOL but not f-40 so may be we should keep using it until we again update go version which is not built for f-40 :)

I added f40, but we can revert this commit once f41 is released.

But even f41 release, f-39 will be EOL but not f-40 so may be we should keep using it until we again update go version which is not built for f-40 :)

If we revert, we get back to fedora-all, which will be f40, f41 and rawhide (and f42 after branching)


review[template-update]: #35

Finished my review and requested a name change to use correct spelling


Netty 4.1 Proxy

I noticed that when using the Netty 4.1 HttpProxy it will resolve the hostname and set the ip/port as the
PROXY-CONNECT-HOSTNAME http header. A library we are using via netty bootstrap does "doResolveAndConnect" on an InetAddress - so the HttpProxyHandler is always getting a resolved InetAddress.
For example, if I connect to foo.cdn.mydomain.com, the PROXY-CONNECT-HOSTNAME will be the IP address that resolves to.
Unfortunately this breaks many proxy configurations, such as Squid, which use that value for "Allow" configurations to allow traffic through the proxy.  (*.cdn.mydomain.com).  Squid is smart as it attempts to do a reverse lookup, but often times these IP addresses reverse-resolve to a cdn like *.cloudfront.net.
Is there a reason the PROXY-CONNECT-HOSTNAME is pre-resolved instead of allowing the proxy to resolve this itself?
[https://github.com/netty/netty/blob/4.1/handler-proxy/src/main/java/io/netty/handler/proxy/HttpProxyHandler.java#L117]
@randak

/cc @trustin

Am 01.12.2015 um 02:09 schrieb vsabella<EMAIL_ADDRESS>I noticed that when using the Netty 4.1 HttpProxy it will resolve the hostname and set the ip/port as the
PROXY-CONNECT-HOSTNAME http header. A library we are using via netty bootstrap does "doResolveAndConnect" on an InetAddress - so the HttpProxyHandler is always getting a resolved InetAddress.
For example, if I connect to foo.cdn.mydomain.com, the PROXY-CONNECT-HOSTNAME will be the IP address that resolves to.
Unfortunately this breaks many proxy configurations, such as Squid, which use that value for "Allow" configurations to allow traffic through the proxy. (*.cdn.mydomain.com). Squid is smart as it attempts to do a reverse lookup, but often times these IP addresses reverse-resolve to a cdn like *.cloudfront.net.
Is there a reason the PROXY-CONNECT-HOSTNAME is pre-resolved instead of allowing the proxy to resolve this itself?
[https://github.com/netty/netty/blob/4.1/handler-proxy/src/main/java/io/netty/handler/proxy/HttpProxyHandler.java#L117]
@randak
—
Reply to this email directly or view it on GitHub.

@vsabella Perhaps you (or the library you are using) forgot to set the resolver to NoopNameResolverGroup.INSTANCE?
bootstrap.resolver(NoopNameResolverGroup.INSTANCE);
bootstrap.connect(InetSocketAddress.createUnresolved(...));

@trustin Thank you. Yes they didn't :)

Hey @trustin,
I have tried applying this to the aforementioned client library. Unfortunately it results in an UnresolvedAddressException. Any thoughts on how to avoid this? Obviously if we are trying to keep the address from resolving, this exception is not particularly helpful...
[error]    UnresolvedAddressException:   (Net.java:123)
[error] sun.nio.ch.Net.checkAddress(Net.java:123)
[error] sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:621)
[error] io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:210)
[error] io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:207)
[error] io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1208)
[error] io.netty.channel.ChannelHandlerInvokerUtil.invokeConnectNow(ChannelHandlerInvokerUtil.java:117)
[error] io.netty.channel.DefaultChannelHandlerInvoker.invokeConnect(DefaultChannelHandlerInvoker.java:248)
[error] io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:218)
[error] io.netty.handler.ssl.SslHandler.connect(SslHandler.java:442)
[error] io.netty.channel.ChannelHandlerInvokerUtil.invokeConnectNow(ChannelHandlerInvokerUtil.java:117)
[error] io.netty.channel.DefaultChannelHandlerInvoker.invokeConnect(DefaultChannelHandlerInvoker.java:248)
[error] io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:218)
[error] io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47)
[error] io.netty.channel.ChannelHandlerInvokerUtil.invokeConnectNow(ChannelHandlerInvokerUtil.java:117)
[error] io.netty.channel.DefaultChannelHandlerInvoker.invokeConnect(DefaultChannelHandlerInvoker.java:248)
[error] io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:218)
[error] io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:212)
[error] io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:1012)
[error] io.netty.channel.AbstractChannel.connect(AbstractChannel.java:237)
[error] io.netty.bootstrap.Bootstrap$3.run(Bootstrap.java:231)
[error] io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
[error] io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:356)
[error] io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
[error] io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)


Change color of tab_layout ?

@satorufujiwara @cafedeaqua
Hi this is a perfect library and looks wonderful, i appreciate your effort !
i m beginner and m learning to code ! Please help me out with few things ..
how can we change color of tab layout in viewpager layout?
Keeping transparent when not scrolled and changing the color when scrolled up ?
Also if we want to keep the toolbar sticky , how could we do it ?

@satorufujiwara
Hi i figured out the color part, for those who get the same doubt!
Just set the rgb values of the color to what you need in the overlaybehaviour.java class , as simplas that !
Still m wondering how to make the toolbar sticky ?


AQCU-1196: TSS: Make Column headings sortable

This works really well right after I render it in the browser, but after the files are saved locally, it doesn't seem to work anymore. It does retain the sort that you set before saving, though. That could be an improvement task since it's not explicitly called out in acceptance criteria. Not sure how hard that would be to handle?

Hmm I'll look a little bit into having it work after saving it

Coverage remained the same at 98.918% when pulling fe49c8699a965a36bd2c269ed63c7ccde7a6d62d on zmoore-usgs:feature/sortable-tss into 45f6a3d7743a2141601dc88c2aa51e7ccd864273 on USGS-R:master.

@mhines-usgs ^ That should hopefully fix the issue

Coverage remained the same at 98.918% when pulling d2171378adc59c94e8e80e08095c48c11da5c2f9 on zmoore-usgs:feature/sortable-tss into 45f6a3d7743a2141601dc88c2aa51e7ccd864273 on USGS-R:master.

checking it out now!

Excellent! :shipit:

One other observation related to usability is that it's not immediately obvious that the columns are sortable until you click on them. Not sure that's changeable with the theme, though.

Yeah I've been messing around with that a bit to see if I can come up with something that implies they are sortable without implying any ordering since initially everything is sorted by start date and I don't want to imply that the other columns are ordered somehow.
I think if I can set start date as the default selected/sorted column that might help, though it wouldn't necessarily imply that any other column but start date is sortable.

If I could get something similar to this icon that might work: http://fontawesome.io/icon/sort/

Yeah, that would be perfect, if you can figure out how to get it to display. :/

Coverage remained the same at 98.918% when pulling 4e8f59445f0fb77c7c0b1271156a9ed59cfdf680 on zmoore-usgs:feature/sortable-tss into 45f6a3d7743a2141601dc88c2aa51e7ccd864273 on USGS-R:master.

Coverage remained the same at 98.918% when pulling 4e8f59445f0fb77c7c0b1271156a9ed59cfdf680 on zmoore-usgs:feature/sortable-tss into 45f6a3d7743a2141601dc88c2aa51e7ccd864273 on USGS-R:master.

Coverage remained the same at 98.918% when pulling 4e8f59445f0fb77c7c0b1271156a9ed59cfdf680 on zmoore-usgs:feature/sortable-tss into 45f6a3d7743a2141601dc88c2aa51e7ccd864273 on USGS-R:master.

Looks great @zmoore-usgs !


(v3) Use Session API in client

This PR follows up on #330 by integrating the new Session API into the client. It also moves the API client to a webworker (separate thread) to avoiding locking the UI with communication stuff. The robot state redux module is gettting pretty large, so this PR splits what was one index.js into a few different files (actions.js, reducer.js). A later PR will likely split the state module into several.
@opentrons/js please review for general sanity and for any potential cleanup opportunities:

The redux stuff is getting a little boilerplatey, as per usual
We're starting to introduce more containers (other than Root), and I think we should be on the lookout for those oportunities
API client is becoming a little large and will likely need to be split up

LGTM!
Maybe in the future you might want to look at libraries like https://github.com/reduxactions/redux-actions to reduce the redux boilerplate? Since the tests are so low-level, and you're already doing flux standard actions, I feel like it's safe to use a helper like that. I haven't used this one myself, but gradually built my own version of the same thing. There might be others that are better, just linking as an example.


change next to last progress to 95 so it will round up to 100

I like your thoughtful approach to the progress bar here, but because the last setting before the download screen was to 90, it was showing 90% on the My Forms page even though it was completed.

Suggested fix is to increase penultimate progress setting to 95. That way it rounds up to 100 on the My Forms page:

@ekressmiller  This is peculiar. The last progress marker before the download page is progress_done, which is 100 (see first image). This works for the progress bar at the top of the page, correctly setting it to 100 (second image). Do you have any offhand insight on why this wouldn't also work for the My Forms page?

It is a weird quirk, I asked about it on Teams a while back and got this response.
If we set it to 95% or more before the last screen it shows up properly on the My Forms page.

Thanks, @ekressmiller. Quinten's response makes sense. Even though this situation is a little different since I'm using set_progress instead of progress: modifiers, it's probably the same underlying thing happening in the depths of docassemble. I'll merge your change in.


⚠ Bofrost.be has degraded performance

In 8d43f5c, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1477 ms

Resolved: Bofrost.be performance has improved in 978a30e after 6 minutes.


The default Vite Svelte project cannot run

Describe the bug
Try to initialise a vite + sveltejs project on Windows 10. But the default code fails to run.
Reproduction
npm init @vitejs/app
npm i
npm run dev

System Info
System:
    OS: Windows 10 10.0.19041
    CPU: (12) x64 AMD Ryzen 5 2600 Six-Core Processor
    Memory: 11.26 GB / 15.93 GB
  Binaries:
    Node: 12.19.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.14.8 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1023.0), Chromium (91.0.864.59)
    Internet Explorer: 11.0.19041.1

Used Package Manager
npm
Logs
(node:1844) ExperimentalWarning: The ESM module loader is experimental.
failed to load config from C:\Users\chaosprint\dev\bug-test\vite.config.js
error when starting dev server:
file:///C:/Users/chaosprint/dev/bug-test/node_modules/@sveltejs/vite-plugin-svelte/dist/index.js:214
import { createMakeHot } from "svelte-hmr";
         ^^^^^^^^^^^^^
SyntaxError: The requested module 'svelte-hmr' is expected to be of type CommonJS, which does not support named exports. CommonJS modules can be imported by importing the default export.
For example:
import pkg from 'svelte-hmr';
const { createMakeHot } = pkg;
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:97:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:143:20)
    at async Loader.import (internal/modules/esm/loader.js:182:24)
    at async loadConfigFromFile (C:\Users\chaosprint\dev\bug-test\node_modules\vite\dist\node\chunks\dep-0ed4fbc0.js:71977:31)
    at async resolveConfig (C:\Users\chaosprint\dev\bug-test\node_modules\vite\dist\node\chunks\dep-0ed4fbc0.js:71600:28)
    at async createServer (C:\Users\chaosprint\dev\bug-test\node_modules\vite\dist\node\chunks\dep-0ed4fbc0.js:70142:20)
    at async CAC.<anonymous> (C:\Users\chaosprint\dev\bug-test\node_modules\vite\dist\node\cli.js:13892:24)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @0.0.0 dev: `vite`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @0.0.0 dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      C:\Users\chaosprint\AppData\Roaming\npm-cache\_logs\2021-06-28T06_58_22_529Z-debug.log

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

Fixed by updating Node.js version to 14.17.1.


 Also fixed some typos

NOTE: There is another case for the BYDAY clause where you can specify several conditions. This is not implemented.
Every other month on the 1st and last Sunday of the month for 10
occurrences:

  DTSTART;TZID=US-Eastern:19970907T090000
  RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU

  ==> (1997 9:00 AM EDT)September 7,28
      (1997 9:00 AM EST)November 2,30
      (1998 9:00 AM EST)January 4,25;March 1,29
      (1998 9:00 AM EDT)May 3,31

From https://www.kanzaki.com/docs/ical/rrule.html

Can you please check the merge conflict?

Fixed conflict


Trans component [Object object] instead of proper link

I got some error with interpolation in Trans component in next-i18next. Instead of proper link I get [Object object]. When I check the translation value in React Developers Tools I see that everything is ok.
Here is my usage of this component: <Trans>{translation.key}</Trans>
translation.key is already translated value with html tags in it. I tried many solutions but every time give me [Object object]

Please provide a reproducible example. Btw. this is probably not related to next-i18next directly, but to react-i18next: https://github.com/i18next/react-i18next

@chojnackipiotr I got hit in the past by a babel plugin (don't remember if it was emotion css). Without proper repo I can't say, but would check the babel config (or update the nextjs version if using swc / swcMinify). It might disappear


hi mira, i have a few suggestions

Node is amazing. I have a few suggestions:
It would be great if there was a tooler that would allow us to make color changes on PNGs, count the number of colors, control the number of colors, and change the color in the area we mask. Nowadays, there are sites such as "online png tools" on the internet. You can also look at examples there. It would be completely different if the tools that would allow us to count and control the number of colors were on the comfyui screen.

For example: [https://onlinepngtools.com/find-png-color-count]

It sounds like this is a Photoshop thing, can you give some scenarios/examples of why this needs to be done in ComfyUI?

logo work, icon production, pattern work, animatediff work, etc. Also, there is no such functional node on color.

Sorry bro, gradients and semi-transparent are not as easy to replace as you might think. Replacing a particular colour won't help you with compositions where the boundaries are not clear. It is easy to organise the data and to present it, but it is a completely different matter to change the data.
My focus is on the masks, PNG is more of a mid-process preview. You may want to consider using controlnet to remove/change the background.
Thanks for your idea.

I'm excited to see what you come up with next. I appreciate your efforts.


MixinEntityMinecart, purpose?

I know we couldn't bring this over 100% from Sponge as Sponge injects a Forge added method.
We need to either add special Vanilla support or migrate to common

@Zidane Couldn't we look at the Forge method and remake that in common? and try to only use Vanilla methods only?


Reference an existing snapshot across multiple tests in same test suite

🚀 Feature Proposal
Reference an existing snapshot across multiple tests in same test suite. This allows you to write multiple test cases that output the same result.
Motivation
The general feeling I get about snapshot testing at the moment is that a lot of people are unsure how and when to use it. I have found few situations when snapshot matchers add value and I believe this feature would be one of them.
Example
const emptySpan = "empty span";

it("should render an empty span if no previous and current is provided", () => {
  const component = renderer.create(<TrendArrow />);
  expect(component.toJSON()).toMatchSnapshot(emptySpan);
});

it("should render an empty span if only previous is provided", () => {
  const component = renderer.create(<TrendArrow previous={1} />);
  expect(component.toJSON()).toMatchSnapshot(emptySpan);
});

Pitch
The current toMatchSnapshot method accepts a parameter for snapshotName which is not mentioned in the documentation. The current output with the snapshotName is:
exports[`<TrendArrow /> should render an empty span if no previous and current is provided: empty span 1`] =
exports[`<TrendArrow /> should render an empty span if only previous is provided: empty span 1`] =

Instead, I believe the behaviour should be a single export statement as below.
exports[`<TrendArrow /> empty span`] =

No, this is correct and expected behavior that you see. Feel free to adjust the wording in the docs here: https://jestjs.io/docs/en/expect#tomatchsnapshotpropertymatchers-snapshotname if you find it confusing.

@thymikee current behaviour I am seeing is that the snapshotName that is passed in is appended to the test name that is inferred. I think the documentation needs to be updated to reflect that?
However, the request that I am raising is that it would be good to have some way of referencing the same snapshot in different test cases in the same test suite. Perhaps, the example above should have been written as this.
it("should render an empty span if no previous and current is provided", () => {
  const component = renderer.create(<TrendArrow />);
  expect(component.toJSON()).toMatchSnapshotRef("empty span");
});

it("should render an empty span if only previous is provided", () => {
  const component = renderer.create(<TrendArrow previous={1} />);
  expect(component.toJSON()).toMatchSnapshotRef("empty span");
});

Perhaps, a new method called toMatchSnapshotRef() should be added? that will produce only one snapshot for the two tests above.
exports[`<TrendArrow /> empty span`] =

I think what you look for Is https://github.com/jest-community/snapshot-diff

@chekkan thanks for the suggestion, but I think this has very niche use cases. Also, how would you update the snapshot if one usage changes it to value A and another usage to value B...


tiff build failure

Operating system
Windows
Compiler
No response
Steps to reproduce the behavior
The tiff port builds with zstd and lerc features, but not with webp. Specifying this in my project's vcpkg.json results in a non-finishing build.
    "dependencies": [
        { "name": "tiff", "features": [ "zstd", "lerc", "webp" ] },
        "gdal"
    ],

Log excerpt is included below.
Failure logs
In config-x64-windows-out.log:
...
-- Found ZLIB: optimized;C:/vcpkg/installed/x64-windows/lib/zlib.lib;debug;C:/vcpkg/installed/x64-windows/debug/lib/zlibd.lib (found version "1.3.1")
-- Could NOT find Deflate (missing: Deflate_LIBRARY Deflate_INCLUDE_DIR)
-- Found JPEG: optimized;C:/vcpkg/installed/x64-windows/lib/jpeg.lib;debug;C:/vcpkg/installed/x64-windows/debug/lib/jpeg.lib (found version "62")
-- Could NOT find JBIG (missing: JBIG_LIBRARY JBIG_INCLUDE_DIR)
-- Found LERC: C:/vcpkg/installed/x64-windows/lib/Lerc.lib (found version "4.0.0")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Found Threads: TRUE
CMake Error at C:/vcpkg/installed/x64-windows/share/WebP/WebPConfig.cmake:15 (message):
  File or directory C:/vcpkg/installed/include referenced by variable
  WebP_INCLUDE_DIR does not exist !
Call Stack (most recent call first):
  C:/vcpkg/installed/x64-windows/share/WebP/WebPConfig.cmake:38 (set_and_check)
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
  cmake/WebPCodec.cmake:29 (find_package)
  CMakeLists.txt:123 (include)

-- Configuring incomplete, errors occurred!
ninja: build stopped: subcommand failed.

Additional context
@dg0yt I'd try to sort this out myself but I have no Windows computer.

You are stumbling over CMake 3.29.1. Downgrade, and reinstall all ports which were built with that version.
https://github.com/microsoft/vcpkg/issues/37968

Ugh. Thanks for the explanation @dg0yt ! I really do appreciate your work on the GDAL-related packages her 🙏

@dg0yt I'm finding it difficult to downgrade or tell vcpkg to use my downgraded version. The GitHub runners have 3.29.1 and installing cmake 3.28.4 via pip or the lukka/get-cmake action (which I've seen others do) doesn't work. In the tiff build logs I still only see references to 3.29.
cd tiff; grep -R "3.29" .
./config-x64-windows-rel-CMakeCache.txt.log:CMAKE_ROOT:INTERNAL=C:/Program Files/CMake/share/cmake-3.29
./config-x64-windows-dbg-CMakeCache.txt.log:CMAKE_ROOT:INTERNAL=C:/Program Files/CMake/share/cmake-3.29

You can try PR 38017 to see if it can solve your problem.

@sgillies Does it compile normally after you downgrade cmake to 3.29.0 or upgrade to 3.29.2?

@jimwang118 I'm using GitHub Actions, where the runners didn't have 3.29.2 until yesterday, and found it too difficult to convince vcpkg to not use the pre-installed cmake. So I went with an overlay port for vcpkg-cmake-config.

@sgillies Is your issue solved now?

@jimwang118 I don't know. I haven't had the free time to see if my overlay port can be removed. GHA windows-latest runners have cmake 3.29.3 now, so I'll presume the problem is fixed and close this issue. Thanks for the support!


Clearing sessions from a Post request

I wondered how it is possible to clear (pop) the sessions from a Post requests.
I have a situation where a post request comes in from a webhook and I need to clear a token which is stored in the session. I don't seem to have access to the session from a Post request though.
I tried just expiring the emmett cookie using Expires = 0 with simplecookie but it seems the cookie can't be cleared in anyway.

I think the issue here is not the POST request, but the fact an incoming webhook doesn't not contain any cookie, as its not made by a user.
Probably the best way is to store the token somewhere else (database, redis, etc.) and load it with a Pipe on the standard user request flow. Then you can just drop it with the webhook from the storage.

I will try that, thanks gi0baro


MultiOS Compatibility

The main purpose of making Cameradar a library is to make it usable by as many people as possible. Releasing a binary under Linux is not a problem since we can use Docker, but for a library, it's very important to ensure MultiOS compatibility and to maintain it at all times.

For Windows : It might be worth it to consider using https://www.appveyor.com/ along with Travis CI to make sure we keep the Windows compatibility at all times.

I will make the second version of Cameradar in Golang instead of C++, as it's more convenient to use and maintain.


schedule_nif improvements

Re-implemented for the new #[rustler::nif] API (excellent work btw).
Let me know what y'all think! Also open to renaming things if y'all think they make more sense.
Previous discussion: https://github.com/rusterlium/rustler/issues/106 https://github.com/rusterlium/rustler/issues/107

@scrogson @filmor

Hey @sunny-g! Thanks for updating this.
I've got some ideas here that I want to share but I don't have the time to articulate it thoroughly right now. I'll take some time over the next couple days to put a review together.

@scrogson fantastic, looking forward to them!

@sunny-g here's what I'm thinking...
Simplify the Schedule enum to this...
pub enum Schedule<T> {
    Return(T),
    Continue(Nif, Vec<Term>),
}

impl<T> NifReturnable for Schedule<T> where T: NifReturnable {
    ...
}

Then create a macro which builds the correct data structure:
reschedule!(my_nif, a, b, c, ...);

@scrogson As you might remember, I had that in the original PR.
I changed it because the original solution required your NIF to be Env-aware, which was fine with the original rustler macros since all NIFs had to take in an Env, but seemed messier than necessary when the new macros would do the encoding/decoding to/from Terms for you.
Granted, a pseudo-variadic enum isn't really "clean" either, but that's why it implements From<(..)>/Into<(..)> with default type parameters, so you only need to specify the types and args you use.
I think regardless I should change Schedule::Result to Schedule::Return and the others to Continue.
Let me know if this explanation changes anything - if not at all, I'll go with what you suggested. Alternatively, I could split the difference and add a similar macro to what you've suggested that's more ergonomically variadic.

As you might remember, I had that in the original PR.

I went back and looked at the original commits as I didn't remember what it looked like before, and yes it is quite similar to my suggestion.

I changed it because the original solution required your NIF to be Env-aware, which was fine with the original rustler macros since all NIFs had to take in an Env, but seemed messier than necessary when the new macros would do the encoding/decoding to/from Terms for you.

With the new syntax, some things still need an Env anyways, so I don't see any issue with this solution requiring Env in order to work (which reminds me...my reschedule! macro sketch was missing the Env and scheduler flag).

Another thought here is maybe we only need a macro or some function to convert the args? And use:
let args: Vec<Term> = collect_terms!(env, a, b, c, ...);
Schedule::Continue(my_nif, args, DirtyCpu)

#[rustler::nif]
fn scheduled_fac(env: Env, input: u32, result: Option<u32>) -> Schedule<u32> {
    let result = result.unwrap_or(1);
    if input == 0 {
        Schedule::Result(result)
    } else {
        Schedule::Continue(schedule_fac, args!(env, input - 1, result * input), DirtyCpu)
    }
}

2 things:

the last comment looks fine, but one thing to note: are the flags required, or are you specifying it to just highlight that they might differ from the NIF macro definition? If so, the enum would still need work.
can you help me understand the issue you're having with the PR as it is currently? Ergonomics, maintainability, extensibility, or something else? I was attempting something that in the best case would be the minimally unintuitive, and in the worst case, would be verbose but still rust-y.

The schedule flag should be allowed to override the original NIF when needed. I personally haven't found a direct need for this, but I have heard of some instances where depending on the input length you may not need to run something on the dirty schedulers and not pay the extra cost.

Makes sense.

Yes, I think we just add the schedule flag in the 3rd position in the Continue variant.

I meant in the sense that it couldn't be "optional", so the alternative would requiring that you pass a flag, even if it's normal, which maybe isn't that big of a deal.

The 2 things that I'm not happy with are the return type and the various functions to represent different arity. It feels a bit unintuitive to me.

That's understandable, but is also the reason I added the Into conversion, so that you wouldn't have to worry about it at all.

I'm now wondering if an elegant solution could be to generate a reschedule function at compile-time for each NIF?
scheduled_fac::reschedule(env, input - 1, Some(result * input), DirtyCpu)

This would probably allow us to ensure type safety on what's passed in (which I think is part of the why behind your current implementation?)

This is actually the approach I started with on this pass, but had problems with it because inside the function, the Ident of the function's name is scoped to the function itself, not the NIF type that gets created.
I'll try again anyways, and regardless will also add a macro so that you don't have to use any variants.

Can we go forward with this PR? I think convenient rescheduling would be very nice to have. What is missing to bring this forward?

@evnu Lemme take another look at this, I might be able to improve the API a bit. Otherwise it works.

Sorry to bother -- does anyone has the time to tackle this? It's a nice feature.

25 months later -- what's the blocker here? Still sounds like an excellent feature.


Usability issue with creating / picking a SQL Agent schedule

Azure Data Studio Version: 1.13.1

Steps to Reproduce:

Create a new job or edit an existing one.
Go to the Schedules tab.

You should see a Schedules list, but you would need to scroll all the way down to see the Pick Schedule and Remove Schedule buttons. The need to scroll down to see the buttons is not obvious.
Below shows the issue (note that the screenshot is maximized)

After scrolling down:

Closing this as it has been reported in  #6359 .


teleport-if-outside-border breaks with latency

Timings link
No response
Expected behavior
The player teleporting once when going outside border
Observed/Actual behavior
The player teleporting in a loop when going outside border, if the player has high latency
Steps/models to reproduce

Use clumsy to get high ping
Go outside border, such as setting the border close to spawn and using an ender pearl to escape the worldborder
Teleport spam

Purpur version
Current: git-Purpur-1538 (MC: 1.18.1)*
Previous: git-Paper-175 (MC: 1.18.1)

You are 1 version(s) behind
Download the new version at: https://purpurmc.org/downloads

Agreements

[X] I am running the latest version of Purpur available from https://purpurmc.org/downloads.
[X] I have searched for and ensured there isn't already an open issue regarding this.
[X] My version of Minecraft is supported by Purpur.

Other
The fix could be if there's a pending teleport don't teleport the player again.

I'm honestly not sure of a way to fix this. Teleporting the player to spawn when they are outside the border is really just a convenience. They shouldn't be outside it to begin with, so I personally feel if someone intentionally gets themself outside of it and is forcing high latency then they deserve to get stuck in a broken state.
I feel Purpur should continue to teleport the player each tick they are reporting themselves to be outside the border. Not being persistent would open possibilities for abuse.
If this is unacceptable for you, PRs are welcome. Or you could disable the feature and implement your own way in a plugin.


Add axial support

This makes it possible to have a horizontal scrollview that fades on the left and/or right.
I deprecated all the API that referred to vertical-only axis support.

Thanks, this looks great! I'd like to update the README before releasing a new version, but I'll aim to get that done in the next couple of days.

Ace! Makes sense 👍


organize tests using filename and build tag

we should organize tests into files named for unit, integration and topology_integration (names are negotiable!), with build tags so that we can run local, API and API+switch tests as needed.

This has been getting cleaned up naturally as we touch each piece. I no longer think an issue is necessary.


Hackage needs a 7.10 compatible package

While constructing the BuildPlan the following exceptions were encountered:

--  Failure when adding dependencies:
      ghc: needed (>=7.2 && <7.9), 7.10.2 found
    needed for package: haskell-docs-4.2.5

I'm building from source for now.

+1

+1
btw.: it works from source without changing the cabal file, so maybe just the hackage page is not updated

@zsedem because a new release needs to be made; the version here has been patched to work with 7.10.

Oh, let me do that.

Bumped haskell-docs 4.2.6.

Confirmed this builds on GHC 7.10.
# Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2)
resolver: lts-3.7