Enhance JAX for the Impatient doc (Flax)

A few small suggestions to improve the JAX for the Impatient doc:

Provide a few minor fixes (grammar, syntax, spelling, capitalization (e.g. JVP) etc).
At the beginning of the Gradients and autodiff section:

Spell out the JAX "docs" - the Autodiff Cookbook - for better UX.
Add "automatic differentiation system".

"For a full overview of JAX's automatic differentiation system, you can check the Autodiff Cookbook."

Define VJPs and JVPs (Vector-Jacobian/Jacobian-Vector products) at the first mention.

Refer to them as reverse/forward-mode autodiff for less experienced users who haven't read the Autodiff Cookbook.
Provide specific links to VJP and JVP sections in the Cookbook, so the users don't have to scroll down to find them.
Capitalize "JVP", "VJP", "Jacobian-Vector" (as per the JAX glossary: https://jax.readthedocs.io/en/latest/glossary.html?highlight=JVP#term-JVP)

Even though, theoretically, a VJP (Vector-Jacobian product - reverse autodiff) and a JVP (Jacobian-Vector product - forward-mode autodiff) are similar—they compute a product of a Jacobian and a vector—they differ by the computational complexity of the operation. In short, when you have a large number of parameters (hence a wide matrix), a JVP is less efficient computationally than a VJP, and conversely JVP is more efficient when the Jacobian matrix is a tall matrix. You can read more in the JAX cookbook notebook mentioned above."

LMKWYT, thanks! @avital @marcvanzee @levskaya

The second warning in the pytest refers to the deprecated module, doesn't it?
WARNING: [autosummary] failed to import 'flax.linen.dot_product_attention_weights': no module named flax.linen.dot_product_attention_weights
11
WARNING: [autosummary] failed to import 'flax.optim.AdaFactor': no module named flax.optim.AdaFactor
12


GetContentType

It would be helpful to indicate that you can also pass this function ALIAS as STRING as well as ID

Whoops... that's a gotcha. I thought I was on version 7 documentation, but seeing as I'm not, I'll close this.


Error in : Install-Package BlockchainAPI

PM> Install-Package BlockchainAPI
Install-Package : An error occurred while loading packages from'https://nuget.org/api/v2/': The underlying connection was closed: An unexp
ected error occurred on a send.
At line:1 char:16

Install-Package <<<<  BlockchainAPI

CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand

Please give me solution of this error
:+1:
PM> Install-Package BlockchainAPI
Install-Package : An error occurred while loading packages from'https://nuget.org/api/v2/': The underlying connection was closed: An unexp
ected error occurred on a send.
At line:1 char:16

Install-Package <<<<  BlockchainAPI

CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand

This error does not seem to be specific to the Blockchain api client. Can you look at the solutions here
https://nuget.codeplex.com/discussions/275537
and let me know if that solved the issue?


Different user id for different users

I have published my bot on Azzure using DrectLine (C#) app but in different machine is the same userid how can I change that ID to be unique in different machines?
Thanks in Advance

 BotChat.App({         directLine: {             secret: key,             conversationId: conversationId,         },         user: {             id: <User Id field>,         },         bot: { id: bot },         resize: 'detect'     }, document.getElementById("DirectLineChat"));
Above implementation is using directline

Since this is a question about functionality and not a bug report of feature request, please ask it on Stack Overflow (with tag botframework) so that others can benefit from the answer. If you'll post a link to your question here I'll answer it there!


Atomic Components Implementation v4 (Tablet)

Atomic Components v4 (Tablet)
Existing Components - Modifications

[ ] [wip] UserAvatar > SingleUser - https://www.figma.com/file/CS01VVLR7ArQl0afYFkNj3/Web-App?node-id=4913%3A478

New size md (50px).
Requires UserAvatar > SingleUser ✅

Don't add any margin around the components.
Put your component in kibbeh/src/ui and create a story in kibbeh/src/stories
Use tailwind for styling (see the tailwind config for theme info).
You have to use TypeScript.
Work on the staging branch.
Please comment below if you start to work on a component, but only claim a component if you plan to work on it right away so it doesn't block other people.

All the icons are already available under src/icons. Some of them will need to be 20px wide/tall (check on Figma), so you can pass width={20} height={20} as props to the icon component for it to scale to the desired size.

Mockup & grid: https://www.figma.com/file/CS01VVLR7ArQl0afYFkNj3/Web-App?node-id=4911%3A0
If you have any questions ask Ben or @ ajb on Discord.

I'm going to work on the UserAvatar component.

Close this now since it has been done?


feat: wire the create kafka instance dialog to its state machine

I wrote a state machine to support the create Kafka instance dialog @suyash-naithani recently refactored.
I surely missed some state, could you check the stories?

The updates you made to the Loading Data state, with showing the skeleton in the form and the info section, are really nice!
There are some missing messages or messages that should have different alert variants used, primarily related to the API checks we make after opening the modal vs on submit. We make similar API calls for each user action because it's possible that our info on loading the form has become stale. And we could get similar info for each different user action, but the message we display and how we display it will differ:

On loading the form, any messages that communicate why a user can't create an instance display as a warning alert, full width of the modal.
On submitting the form, any messages that communicate why a user can't create an instance display as an error alert, spanning the width of the form only.

Between cases 1 and 2, the message text will also change slightly

If the organization reached it's quota limit, these messages display:

on form load, a warning alert displays: Kafka instances are unavailable for creation / Your organization reached the limit of Kafka instances available for creation.
on form submit, an error alert displays: Kafka instance can't be created / Your organization reached the limit of Kafka instances available for creation.

If trial instances are unavailable, these messages display:

on form load, a warning alert displays: Kafka instances are unavailable for creation / Kafka instances might become available later, so check back in a few hours.
on form submit, an error alert displays: Kafka instance can't be created / Kafka instances are no longer available. Try again in a few hours.

Given these extra variations, it might help to update the story names to include whether the check is on form load or on form submit. This is an example of what that list could be:

Over quota on form load
Over quota on form submit
Trial unavailable on form load
Trial unavailable on form submit
Trial used on form load (I guess in theory the user could create a trial instance in the CLI while simultaneously using the UI, but we never designed for that use case)

Given all the various messages that can display and when, I tried to capture details about message text, alert variant, etc... in a diagram in these slides. I also double-checked these slides to confirm they are correct, and made some updates today while reviewing your PR so this should be up-to-date with the latest text strings and color-coded to convey alert variant.
Let me know if you need more specific information about what message and alert variant display for each state. I'm happy to outline all the expected details for the stories I listed above if that makes it easier to reference.
Aside from that, here are a couple more things I noticed:

There is a difference between what I had noted in the design document vs what we have currently implemented regarding when the submit button is disabled. For example, in the Ready to create... stories, my expectation is that the Create instance button would be enabled, but that isn't what we have implemented in the product today. My reason for keeping it enabled even when there are empty fields is that it might not be obvious to the user why the button is disabled if there is nothing flagged in the form. If the Create instance button in enabled, then they can click it and see a form-level error that explains why they can’t proceed along with field-level errors that highlight the things in the form they need to address.  I'm totally fine with revisiting this as a separate discussion/issue, thought.
In the Generic error story, the success state displays for Name and Cloud region. We don't have this in the Create instance modal today, but I have seen these used in some of our other modals in production and we should eventually refactor these to not have them. This success indicator should only be used when additional confirmation/validation is needed for the value provided by the user.

Thank you Jenn, this is extremely useful. I updated the PR with the help of @suyash-naithani to cleanup the messages and reorganize the stories as you suggested. I still need to do the changes to support the always enabled Create button.
I have a question about this bit:

We make similar API calls for each user action

This took me by surprise. Checking the existing implementation, I don't see API calls performed when say, the user selects a region. We load the data once when loading the modal, and then invoke the creation action which will either be successful or not.
Should we call the API more often? Maybe even poll for the data every X seconds?

We make similar API calls for each user action

What I meant was that we make API calls when the user opens the modal, and again when the user submits the form. Now that you mention it, your description sounds more accurate that how I describe it though.  I forgot that the on submit action is actually requesting a new Kafka, and we just present any errors from that action in the modal.

This should be done now and it's ready to be reviewed (again).

Form submit is always enabled
Extended stories to show support for multiple providers
Extended stories to show support for tweaking the defaults and the available options for the AZ

You new set of stories look really good! I went through all of them and listed some miscellaneous things I noticed below.
Earlier today you asked about whether the required indicator is needed for Cloud provider, even when there's a default selection and you can't select it. I shared this question with other designers, and the consensus was that it should include the red *.
Name Taken - Today the error message for name that you show in this example displays only after the user submits the form. In our current implementation, an additional inline error alert like you have for Form Errors would also display.
Example of Name Taken in the latest storybook:

Example of current implementation:

Trial Unavailable On Form Load and Trial Unavailable On Form Submit - Both of these should include the "Duration / 48 hours" under Instance information:

Only Single AZ Enabled With Right Tooltip - I'm not sure if this use case will ever be needed, but I would expect this to be similar to our use case today of only multi availability zones being supported
This is how it displays on load:

And then I can click the Single option to select it:

I think this just needs to have Single selected by default. The same tooltip should also display for the disabled Multi option.
No Defaults Mark Provider As Required - Both options are enabled, but the tooltip still displays. In this case when no options are disabled, then the tooltip shouldn't display.

Earlier today you asked about whether the required indicator is needed for Cloud provider, even when there's a default selection and you can't select it. I shared this question with other designers, and the consensus was that it should include the red *.

Perfect, it's now on in all scenarios.

Name Taken - Today the error message for name that you show in this example displays only after the user submits the form. In our current implementation, an additional inline error alert like you have for Form Errors would also display.

Updated to work as expected.

Trial Unavailable On Form Load and Trial Unavailable On Form Submit - Both of these should include the "Duration / 48 hours" under Instance information:

Good catch, I had the stories set up wrongly. They should work as expected now. Doing this I noticed that in the on Form Submit state we will show two alerts, the top one relative to the instance lasting 48h and the form one to inform of the temporary unavailability of trial instances. I think this is correct, WDYT?

Only Single AZ Enabled With Right Tooltip - I'm not sure if this use case will ever be needed, but I would expect this to be similar to our use case today of only multi availability zones being supported
I think this just needs to have Single selected by default. The same tooltip should also display for the disabled Multi option.

Exactly, I forgot to set the right default.

No Defaults Mark Provider As Required - Both options are enabled, but the tooltip still displays. In this case when no options are disabled, then the tooltip shouldn't display.

Good catch, there were a few issues with the way I was dealing with this. I also noticed that both the Region and the AZ options were enabled even without a provider selected. They are now disabled until you select a provider. As you said, it's not something we expect to happen but it's good to have it covered.

:tada: This PR is included in version 1.12.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


uninstall process

i would love to use your voyager package on a ongoing project.
but when i tried to install it, i got the error, that the post table already exists.
second trouble was the uninstall process, i saw quite a lot migrations and seed files, would love to see a uninstall task / process...

+1
Need an uninstall.

how we can uninstall voyager ?

Hare are the steps to remove voyager. I also installed the voyager front-end.

composer remove pvtl/voyager-frontend

composer remove tcg/voyager

Remove these routes from web.php file
Route::group(['prefix' => 'admin'], function () {
Voyager::routes();
});

Remove the parent class from app/User.php file and extend it from "Authenticatable". Below is the example how the user.php file look like.

use Illuminate\Foundation\Auth\User as Authenticatable;
class User extends Authenticatable

I believe you'll also wanna remove the hook repo from composer.json that gets added with Voyager:
        "hooks": {
            "type": "composer",
            "url": "https://larapack.io"
        }

This will be implemented in Version 2.0 👍 Adding it to the 2.0 planning project: https://github.com/the-control-group/voyager/projects/6


[stable/aws-s3-proxy]: Support k8s 1.19 Ingress

Description
Ingress of aws-s3-proxy only support networking.k8s.io/v1beta1 and extensions/v1beta1, so it cannot be deployed over k8s 1.22 versions. (networking.k8s.io/v1 is supported starting with k8s 1.19.)
https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122
So, add if-else statements to support networking.k8s.io/v1 apiVersion. This change is compatible to k8s 1.19 under version, so don't worry :)
Checklist

[x] Title of the PR starts with chart name (e.g. [stable/mychartname])
[ ] I have read the contribution instructions, bumped chart version and regenerated the docs
[ ] Github actions are passing

Oh, I didn't bumped chart version! I will bump it to 0.1.4 :pray:


Improve stackoverflow

Improve Stackoverflow startup time.

Remove move of existing ldf (from 7zp)
Added ATTACH_REBUILD_LOG to the SQL script

Looks good, even if the performance isn't what we hoped 💯

It went from +10min to 2min it's awesome already 🤗

haha wait, i thought it was still the same-ish! Great news! My bad 🤗

At least comparing our sql server error log for the before/after


feat(adapter/alibaba-cloud-fc3): add alibaba cloud function compute 3.0 adapater support

The author should do the following, if applicable

[x] Add tests
[x] Run tests
[x] bun run format:fix && bun run lint:fix to format the code
[x] Add TSDoc/JSDoc to document the code

Docs
https://www.alibabacloud.com/help/en/functioncompute/fc-3-0/
Tests

Unit test at src/adapter/aliyun-fc3/handler.test.ts
Verified basic functionality with real-world testing on GitHub Actions. https://github.com/rwv/hono/actions/runs/11718662874

Differences with Hono's Getting Started with Aliyun Function Compute
The primary difference between this adapter and the setup described in Hono's official documentation lies in the deployment method for Alibaba Cloud Function Compute (FC).

Debian Docker Container (Hono Documentation): The official guide provides a setup using a Debian-based Docker container to deploy Hono applications on Aliyun FC. This approach involves creating a custom Docker environment that packages and runs the application, offering flexibility with OS-level configurations.

Native Node.js Environment (This Adapter): In contrast, this adapter uses Alibaba Cloud's Node.js runtime environment directly, similar to AWS Lambda. It leverages Alibaba Cloud FC's built-in Node.js support, bypassing the need for a custom Docker container. This approach simplifies deployment by focusing on function code rather than container management, making it faster to set up and closer in experience to other serverless platforms like AWS Lambda.

The renaming and runtime test are complete. Could you please review and let me know if there’s anything else that needs to be adjusted? Thanks!

Hi @rwv
It's hard to decide if we should accept this PR because it's possible that no one can maintain this adapter. At least, I don't know much about Aliyun Function Compute. You may be able to maintain it, but that may not be possible in the future, and it will be hard for me to maintain it.

Hi,
Thank you for considering this PR. I understand the concern regarding long-term maintenance, especially since Aliyun Function Compute might not be widely familiar to the core team. I’d be glad to help maintain this adapter for as long as possible. Additionally, I’ve achieved 100% test coverage on this adapter, which should help with ensuring stability and making future maintenance easier. I can also provide documentation and implementation details to further support the team. If there are any specific concerns or suggestions, please let me know, and I’d be happy to address them.

I maintain the Alibaba Cloud FC3 adapter in a separate repository: rwv/hono-alibaba-cloud-fc3-adapter. Perhaps we could mention this in the documentation as an external resource, so users have access without adding maintenance overhead to the core repository.
Let me know your thoughts!

@rwv
Thanks! Is it a good idea to update this doc? https://hono.dev/docs/getting-started/ali-function-compute

Updated doc @ https://github.com/honojs/website/pull/544


Create ES3 specific lib.d.ts

By targeting to ES3, the following code (within a class definition):
        setOptionDisable(option: HTMLOptionElement, operation: EnumOperations) {
            ko.applyBindingsToNode(option,
                {
                    disable: BI_OP.has(operation)? this.selectedNumbers().length >= 2 : true
                }, item);
        }

compiles, but the item variable is not defined. Does really item exists in a ES3 standard browser? I wasn't able to find it, so I treated this as a bug.

You'll need to post more repro code. Simply using an undefined name like that in a small snippet is clearly an error. If there's actually a bug in the compiler or your code it's more involved than just that function definition.

On the lib.d.ts file is defined the following function:
declare function item(index: any): any;

But as seeing @ http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262, 3rd edition, December 1999.pdf 15.1.1 Value Properties of the Global Object (page 77) and W3C http://www.w3schools.com/jsref/jsref_obj_global.asp , there isn't any item global function.
This misstake causes that if I use a non-defined ítem variable on my code, which of course doesn't exists, it will compile ok, but it shouldn't!
For example:
item();// must throw a compilation error. Instead, it is getting a runtime one on the browser because  it is not defined.

Same with msClearImmediate, btoa, atob, etc.
I think I can explain it better... :S

Ah, we could consider an ES3 specific lib.d.ts. In the meantime you should just remove those members from the copy of lib.d.ts you're building against or polyfill the implementation if you're targeting both ES3 and ES5 and want that functionality everywhere. We already see most people targeting ES5+ and that's only going to increase so this isn't likely to be super high priority to fix right now.

Would probably accept a PR on a good es3.lib.d.ts

This is very interesting at Enterprise environments that works with legacy browsers.

related to https://github.com/Microsoft/TypeScript/issues/6974

I understand that this is a relatively old Issue, but I would like to toss in a use-case for providing an es3-specific declaration lib. I find myself working with the [admittedly aging] ExtendScript language, one that is primarily used for creating extensions to Adobe products. The language itself is ECMAScript 3-based.
It appears to be possible to write TypeScript such that compiled JavaScript can work with this language:

Specify the "es5" lib in the compiler options (or whatever you wish to write in).

Omit the "dom" lib.

Set the target compiler option to "es3".
Provide declaration files for other ExtendScript types.

However, it is not possible to write type-annotated ExtendScript in a TypeScript enabled environment. With a lib.es3.d.ts declaration file option, this would be possible with very little change to the above configuration:

Specify the "es3" lib in the compiler options. [<-- Missing!]
Provide declaration files for other ExtendScript types.

As it stands, we can get most of the way by specifying "es5". The obvious pitfall with this strategy is that some features/APIs suggested with type completion will be erroneous/not supported by the target language.
Would be nice to have an "es3" lib option...

Would be nice to have an "es3" lib option...

it sure would be. and this issue is tracking it. we would be happy to accept a PR for lib.es3.d.ts

Speaking for myself, I have no clue as to how the existing lib declaration files were built. Suggestions on how to quickly create a lib.es3.d.ts file (perhaps by modifying the existing es5 version?) would be instructive. Furthermore, what would you suggest to use for the target spec? This? If so, what portions are most important? I would guess that Chapter 15 - Native ECMAScript Objects would be the primary focus. Are there any other important sections? Anything important to capture in Chapter 8 - Types or Chapter 9 - Type Conversion? Or are those things handled intrinsically by TypeScript already?

I would start by lib.es5.d.ts, and go through he spec remove/update declarations as necessary.

Out of curiosity, does lib.es5.d.ts correspond to version 5.0 or 5.1?

5.1

@mhegazy Is there a resource that describes how the lib files are structured and why they are structured in the manner that they are? For example, why are all built-in types declared as interfaces with equivalently named global constants rather than classes?
This seems to make some kind of sense for static-like classes (e.g. Math). However, what about the basic Object class? Why split it up into an Object interface and an ObjectConstructor interface? It looks like this is . There doesn't appear to be a good description for this at the top of the lib file itself, nor in the declaration file documentation. Some googling led me to "construct signatures", which is somewhat covered in the "Difference between the static and instance sides of classes" section of the TypeScript Interface documentation. What's somewhat confusing is that TypeScript classes can have static methods/fields. So why not just use those?
One drawback(?) that I'm seeing with the interface method being employed is that [when using JavaScript, at least] the global namespace is filled not with classes as one might expect, but interfaces. I understand that JavaScript classes are not "real" classes, per se, but it is also somewhat surprising to see autocomplete turn up ObjectConstructor as a valid completion target.
Basically, why this:
// Instance-side.
interface Blah {
    num: number;
}

// Static-side.
interface BlahConstructor {
    val: object;
    new (): Blah;
}

declare const Blah: BlahConstructor;

instead of this:
declare class Blah {
    constructor();
    static val: object;
    num: number;
}

Convention? Or some deeper reason...?
(Please let me know if there is a better place to ask such questions. I ask them here to help anyone else considering taking on the task of creating the "es5" lib who may also not be terribly familiar with "why" behind the architecture.)

@mhegazy Is there a resource that describes how the lib files are structured and why they are structured in the manner that they are? For example, why are all built-in types declared as interfaces with equivalently named global constants rather than classes?

classes are not callable. most of the built-in objects e.g. Object, Array, etc.. allow to be called as function as well as a constructor.

One drawback(?) that I'm seeing with the interface method being employed is that [when using JavaScript, at least] the global namespace is filled not with classes as one might expect, but interfaces. I understand that JavaScript classes are not "real" classes, per se, but it is also somewhat surprising to see autocomplete turn up ObjectConstructor as a valid completion target.

that is unfortunate, and we tried to limit it to only required objects, e.g. DOM APIs do not behave the same way.
One thing to note, you need to keep the structure, for things like ObjectConstructor, the assumption when ppl use --lib es3 is that they will get a smaller API surface area, not a completely different one.

On Callable Core "classes"

classes are not callable. most of the built-in objects e.g. Object, Array, etc.. allow to be called as function as well as a constructor.

Ahh, so that is what the last two lines of this are then:
interface ObjectConstructor {
    new (value?: any): Object;
    (): any;
    (value: any): any;
    //...
}

I'd actually not previously understood why those were there. Makes much more sense.
Small Bug in One of the Declarations?
I cross checked those with the spec. It seems to me that the one called without an argument should return an Object, no? E.g.:
interface ObjectConstructor {
    //...
    (): Object;       // "return a new Object object"
    //...
}

Un-implementable Interfaces?
Also, is the idea with the "callable interfaces" that they will simply make the interface un-implementable? I attempted to implement ObjectConstructor in a test class and got the following error:
'Class 'test' incorrectly implements interface 'ObjectConstructor'.
  Type 'test' provides no match for the signature '(): any''

I take it that this is "by design"?
Maintaining the Current Structure with an es3 Variant

One thing to note, you need to keep the structure, for things like ObjectConstructor, the assumption when ppl use --lib es3 is that they will get a smaller API surface area, not a completely different one.

Agreed. This was part of the impetus for requesting more information as to the structure of the declarations. Understanding why the structure is as it is will help anyone attempting to create a lib.es3.d.ts file.

Also, is the idea with the "callable interfaces" that they will simply make the interface un-implementable?
...
I take it that this is "by design"?

I'll answer my own question here. Yes: it appears that this is by design.
For anyone interested in more, this blog entry is extremely helpful. The main documentation is also helpful if you look for "call signature" (under Function Types) and "construct signature" (under Difference between the static and instance sides of classes).

I cross checked those with the spec. It seems to me that the two lines listed above may not be quite as accurate as they could be. I would E.g.:

sure. it just that ppl do not use Object(1) that often.

I take it that this is "by design"?

yes. these are not meant to be implemented, but rather to describe JS objects that do exist.

sure. it just that ppl do not use Object(1) that often.
I bet. Doesn't mean that it isn't technically wrong ;)

@mhegazy I bet. Doesn't mean that it isn't technically wrong ;)

it is not wrong. it is just not that common.

Reopened my PR as #28372, if anyone still is interested.

Comments in the linked PR


Yet more confusion about panic_handlers

I am using rayon's threadpool to execute a series of tasks. In the case that a task panics, I would like to set some global flag, so that I can stop adding new work and terminate. I would assume I could do this with a custom panic handler, but I've been poking at things for several hours without success.
A simple version of my program would look like,
use rayon::ThreadPoolBuilder;

fn main() {
    let threads = ThreadPoolBuilder::new()
        .thread_name(|n| format!("pool-{n}"))
        .panic_handler(|_oh_no| {
            eprintln!(
                "handled panic in thread {}",
                std::thread::current().name().unwrap_or("wat")
            );
        })
        .start_handler(|n| eprintln!("starting thread {n}"))
        .exit_handler(|n| eprintln!("exiting thread {n}"))
        .num_threads(4)
        .build()
        .expect("failed to build threadpool");

    threads.scope(|scope| {
        for i in 0..30 {
            scope.spawn(move |_| {
                eprintln!(
                    "{i} sleeping in thread {}",
                    std::thread::current().name().unwrap_or("")
                );
                std::thread::sleep_ms(i * 50);
                eprintln!("{i} woke up");
                if i == 22 {
                    panic!("oh no");
                }
            })
        }
    })
}

Should I expect this to work? Do I need to just use catch_unwind directly, inside each call I make to spawn?

The pool's panic_handler is only used in places where we cannot otherwise propagate a panic back to the user, particularly from unscoped spawns. With a scope, we do propagate panics where the scope would otherwise return, but only after all its spawns have executed.
You might like panic_fuse -- e.g. your example code would be (0..30).into_par_iter().panic_fuse().for_each(|i| ...). Under the hood, that is just using an atomic flag to skip further work after a panic. That behavior is definitely reproducible on your own if panic_fuse doesn't fit the way you're executing.

Also, caveats around catch_unwind remain -- none of this applies if the build is using panic=abort.

Okay, thanks! I ended up implementing something that looks like your explanation of panic_fuse, where I check an atomic book from within the spawned task and return if it's been set.


Added some colleges and universities

Good one @pman47
Congrats 🎉, your PR got merged. To be eligible for the swags from ClueLess. Follow these steps.

Star this repository. ⭐

SignIn / SignUp in [ClueLess Website](https://www.clueless.tech/) .

Go to the profile section from the top right-hand corner.

Comment your profile URL under this comment tagging the person who merged your PR.

That’s it. Follow the leaderboard!
And don’t forget to share your achievement with your friends.

https://www.clueless.tech/profile/admin/116529206634136025482

@pman47 | Depends upon your rank on the leaderboard.

Where can i see rank or leaderboard ? 😅

Where can i see rank or leaderboard ? 😅

https://www.clueless.tech/hacktoberfest/leaderboard  | It will update every date.

Okay got it 👍


Build failure: coreutils check fails

Steps To Reproduce
Steps to reproduce the behavior:

build coreutils

Build log
id: cannot find name for group ID 30000
separator.sh: set-up failure:
ERROR tests/chown/separator.sh (exit status: 99)

Additional context
Seems like the same issue happens in logrotate as well: https://github.com/NixOS/nix/issues/8502
Notify maintainers
@dasJ
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.75-hardened1, NixOS, 24.05 (Uakari), 24.05pre580425.faf912b08657`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(nix): `""`
 - channels(root): `"home-manager, nixos, nixos-hardware, nur"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

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

Have you enabled dynamic UID allocation in Nix?

I can only reproduce this with hardening enabled (seems like @MrQubo also has it enabled from their metadata). Some related threads on Discourse:

https://discourse.nixos.org/t/logrotate-config-fails-due-to-missing-group-30000/28501
https://discourse.nixos.org/t/cant-rebuild-the-system/32802

The appropriate maintainers to ping are @joachifm @emilazy then.

Happens to me too - broke somewhere between nixpkgs commits 842d9d80cfd4560648c785f8a4e6f3b096790e19 and 1536926ef5621b09bba54035ae2bb6d806d72ac8 it looks like (my nixpkgs rev before error and after)

@reidlabwastaken could you bisect?

@reidlabwastaken could you bisect?

I'll start bisecting for it when I get home (gonna be around 7-8 hours)

@reidlabwastaken could you bisect?

I don't think I have the hardware good enough for that - sorry (raspberry pi 4)

@reidlabwastaken the RPI4 isn't fast by any means but it can still compile software.  coreutils isn't a very intensive build; takes about 6min on an x86 machine 1.6 times as fast as an RPI4.
Make sure you exclude staging commits by running a first-parent bisect; building the stdenv is certainly beyond what is reasonable for a RPI4.

I tried building coreutils using 842d9d80cfd4560648c785f8a4e6f3b096790e19 using a hardened profile and it failed with the same error, when I run sudo sysctl kernel.unprivileged_userns_clone=1 the build succeeds, so the issue is likely this line of the hardened profile.
I think this is the same issue as this.
There is a similar issue here: https://github.com/NixOS/nix/issues/6898

Happens to logrotate as well on current Nixpkgs master:
error: builder for '/nix/store/cszlszng8qwf7wbqihjcprywv7yfqgqn-logrotate.conf.drv' failed with exit code 1;
       last 1 log lines:
       > /nix/store/0kg70swgpg45ipcz3pr2siidq9fn6d77-coreutils-9.5/bin/id: cannot find name for group ID 30000
       For full logs, run 'nix log /nix/store/cszlszng8qwf7wbqihjcprywv7yfqgqn-logrotate.conf.drv'.


Crash on Interactive Keyboard [Android only]

Describe the bug
Hard crash with this error been thrown https://github.com/kirillzyusko/react-native-keyboard-controller/blob/756be077c97a0eb6ba12fcbda0d3284b4b89d04a/android/src/main/java/com/reactnativekeyboardcontroller/extensions/View.kt#L47
Reproduction is possible in your example repo.
Upon routing into a deeper stack. Home -> Chat with Keyboard Handler -> Forward Friend --- Back Button ---> Chat with Keyboard Handler -> Open Keyboard -> Full Android Crash
java.lang.IllegalArgumentException: Can not copy bounds as view is not laid out or attached to window
08-11 12:59:11.486  4446  4446 E AndroidRuntime: 	at com.reactnativekeyboardcontroller.extensions.ViewKt.copyBoundsInWindow(View.kt:45)

Repo for reproducing
https://github.com/ImBeCiliC/keyboard-controller-crash-1
To Reproduce
Steps to reproduce the behavior:

Go to 'interactive keyboard'
Open Keyboard
Press Yellow Navigation Button
Navigate Back
Open Keyboard
Try to Scroll the Chat View
CRASH

Smartphone (please complete the following information):

OS: Android only
RN version: as in example repo
RN architecture: as in example repo
JS engine: as in example repo
Library version: 1.5.8

Additional context
In the Example the height of the fake view is strange after back navigation
Removing the KeyboardGestureArea removes the crash. Also in my example repo so you can check it out.
Appreciate the nice library and helped improve the React Native Keyboard issues we had in the past 🎉

Thanks @ImBeCiliC for reporting the problem! I'll have a look and will try to reproduce/fix the problem!

@kirillzyusko thanks for the detailed clarification. It is now working for me 🎉
Could be really helpful to others to have this section in the documentation.
If you don't need any code changes feel free to close the issue.

@ImBeCiliC actually I already wrote about this https://kirillzyusko.github.io/react-native-keyboard-controller/docs/guides/building-own-hook
Maybe it can be somehow improved? What do you think I should add to be sure that people are aware about this?

Hi @kirillzyusko ! First of all - huge thx for this lib.
I have this sort of crash right now ... and I'm sure that the problem is not because of changing windowSoftInputMode as I have "adjustResize" by default in the manifest.
So basically I have native stack (react-navigation):

Screen A (uses  , everything works fine);
navigate to Screen B (uses  , everything works fine);
navigate back from Screen B to Screen A;
try to focus input -> crash with the log "Can not copy bounds as view is not laid out or attached to window" ;

the structure of every screen is
<View>
<KeyboardGestureArea>
<ScrollView>
<View ..../>
</ScrollView>
</KeyboardGestureArea>
</View>

Hello @4yki 👋
It's hard to say what is going wrong here because input information is limited. May I kindly ask you to create a new issue and provide a minimal reproduction example?

@4yki I could reproduce this crash using native-stack navigator. I fixed a problem and published a new 1.9.3 version 👀

It seems like it is still crashing on Android. I am wrapping the FlashList inside KeyboardGestureArea. Using the latest version of package
    "react-native-keyboard-controller": "^1.10.1",

@Karthik-B-06 please, open a new issue and provide minimal reproduction example 🙏


return original order of jQuery array.

I am using Blast and wondered if it is expected that the original sequence of an array is not honoured, instead blast returns according to position in the DOM.
Here is an illustration: http://jsfiddle.net/9gogkww5/

I have a workaround for now by storing positions before Blast, and then sorting: http://jsfiddle.net/9gogkww5/2/

Unlikely to implement for time being, but will revisit shortly. Thank you, Mr. Balaam :)


Unable to install apidash on Ubuntu 20.04

Steps to Reproduce the bug/problem

Main error:
Repository is broken: apidash:amd64 (= 0.3.0+3) has no Size information
Device Info (The device where you encountered this issue):

Ubuntu 20.04

Thanks for reporting @suryagowda
We will take a look into it.

@ashitaprasad isn't it simply that you built the deb against wrong ubuntu version? or that @suryagowda uses too old ubuntu?

It seems that apidash does not support Ubuntu 20.04 because of glibc.
Trying to install newer glibc might break the system or other packages because glibc is a system package.

We looked around and it looks like it was a flutter (snap) specific issue that we were using to build the deb installers. We will be switching to vanilla flutter for building installers in Ubuntu starting next release.
Relevant Links:
https://stackoverflow.com/questions/74156104/glibc-2-33-not-found-while-building-flutter-for-linux
https://github.com/flutter/flutter/issues/121034


Revert adding field name to constraint error

There's a bunch of problems with that improvement:

It changes the type of error that is thrown by dry-types. It broke rom's specs (though I would argue it wasn't declared as part of the public interface and rom shouldn't have committed to a specific error)
It refers to dry-types explicitly though it wasn't a hard dependency. The following example fails with uninitialized constant Dry::Types:

class Foo
  extend Dry::Initializer

  param :foo, type: proc { Integer(_1) }
end

Foo.new('abc')

I decided we should ship 3.1.1 without this change and think the whole thing through. Probably, we should add a dry-types extension to dry-initializer that improves errors but requires explicit activation.

Ref https://github.com/dry-rb/dry-initializer/pull/85

/cc @swerling @nepalez @solnic 👆


Add placeholder item for optional select fields

Add a placeholder item for static select and async select fields when a field is not required.

@jamesricky discussed this topic again with UX. Instead of adding the default item only to the generated select fields, it should be added to the select components directly. In parallel, the clearable option is removed from the select fields.

OLD INFO
This needs adaptions in `FinalFormSelect`,  @jamesricky opened a separate PR (COM-942) for this. These changes are **not** in this PR.
PR Checklist

[x] Verify if the change requires a changeset. See CONTRIBUTING.md
[x] Link to the respective task if one exists: SVK-172, SVK-173
[x] Provide screenshots/screencasts if the change contains visual changes

Screenshots/screencasts
Behaviour of story:
https://github.com/user-attachments/assets/ad06fa4a-34c5-4457-914f-8c7b90df9274
Behaviour of form (generated)
https://github.com/user-attachments/assets/ad797839-617c-4ef8-b460-b4cac6016e16

@johnnyomair I shortly discussed the default behaviour of optional multiple SelectFields with @jamesricky : We decided to not show the default item for these selects. They would be part of the selected value array. Is that okay with you?

Maybe show it while there is no other option selected? That would seem the most logical option to me.

@johnnyomair I shortly discussed the default behaviour of optional multiple SelectFields with @jamesricky : We decided to not show the default item for these selects. They would be part of the selected value array. Is that okay with you?

Maybe show it while there is no other option selected? That would seem the most logical option to me.

According to UX (see UX Meeting Notes of 2024-KW8), the "Please select" item should be a selectable item in the options dropdown. Should we deviate from that for multiple selects?

Do we really need new "Please select" option PLUS the clear button?

Do we really need new "Please select" option PLUS the clear button?

In a discussion with UX we decided selects should only have the "Please select" option to clear the value which would replace the clear button. So the clear button should be removed.

And have you (and UX) considered Selects used eg. in a filter form? (At least the "Please select" text needs to be changeable)

Not that I am aware of but that should be easy with something like an clearOptionText prop that has "Please select" as the default.

And have you (and UX) considered Selects used eg. in a filter form? (At least the "Please select" text needs to be changeable)

Do you mean the data grid filter? If not, could you give an example for a filter form?

@andrearutrecht We discussed this today with UX: Every optional select should have a clear button, required selects shouldn't have a clear button (same behavior as for date pickers). The placeholder item should be removed. Could you please adapt this PR?

The placeholder item should be removed.
Meaning the placeholder item should be completely removed from select fields?

Meaning the placeholder item should be completely removed from select fields?

Yes


feat(console): set doc link in descriptions for managers

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Removing vscode python survey prompt

Python extension now has it's own survey prompt, so we would like to remove this. I've been trying to find the file where the survey is implemented, so I can submit a PR to remove it. Can you please point me to the implementation?

Hi Karthik, we currently prompt users for this Python NPS survey: https://www.research.net/r/G7ZBPW7
I can replace this survey with another one or totally remove it. Btw, what is the new survey you are pointing to or what is the new criteria for showing it?

Hi Sana. We've already implemented the prompt as stated in the issue https://github.com/microsoft/vscode-python/issues/6752.
We are randomly sampling 5% users making sure the same user is not prompted in 12 weeks again. Users sampled will be seeing the survey after 1 hour.
I am working on https://github.com/microsoft/vscode-python/issues/6957 right now, where I need to remove VSCode prompt.

Completed.


shared module for validator webhook server

Currently pilot/platform/kube/admit/admit.go defines the http server which behaves as k8s external admission webhook for validating pilot config. #1728 is going to add the webhook for mixer config.
The abstract server code (i.e. http server / certification / webhook registration) would be quite similar, although currently it is hard to merge them since some data types are incompatible for historical reason. This will track the issue to unite their implementations; so a single webhook server implementation, but each istio component will attach their own validation logic.

/subscribe

/subscribe

/subscribe

@ayj already implemented this.


Adding Error to log functions

There was a slightly similar issue (Simplify logging Error types #267) but I would like to give this another twist.
Basically all advanced logging systems accept a textual message and allow to add additional values to better describe the log event.
Any also many system allow to explicitly log an Error, not just as part of the message or metadata. Examples: Sentry, Datadog
These service do handle explicit errors in special ways like automated grouping, warning thresholds, incident management...
It's more complex to train these systems to analyze/filter/map the metadata of log events and perform the same routines as with explicit errors.
So I would like to propose to add an additional optional Error to the log functions that then can be send to log services.
Manual extraction of key values from an error, in it's simplest form error.localizedDescription or more complex, is not sufficient to leverage the potential of log services.
Given
let error: Error? = ...
let logger = Logger(label: "com.example")

Expected behavior
logger.error("message", error)

and a signature of the log(...) function of the LogHandler protocol
func log(
        level: Logging.Logger.Level,
        message: Logging.Logger.Message,
        error: Error?, // <<<<<<<<<< new line here
        metadata: Logging.Logger.Metadata?,
        source: String,
        file: String,
        function: String,
        line: UInt
    )

Actual behavior
The given log functions .log(...) or explicit like .error(...) on a logger instance only accept a message and metadata where metadata is a String, or array/dictionary hierarchy where terminal elements are again String.
SwiftLog version/commit hash
v1.5.4

Thank you! Looking forward for this!

Would be nice :)

I think this would greatly improve the ergonomics of this logging system. So many logging services have special affordances for Error that being able to log.error the actual error and have it end up in the log handler for proper processing seems like a critical need.
As-is, to do this, I have to wrap an error with a CustomStringConvertible conforming error wrapper, and attempt to extract the error from this error. :/


parsing error on complete instruction

when b3 try to parse this instruction i get this error
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffe4887f480) = -1 EINVAL (Invalid argument)

[PARSE ERROR] SyntaxError: Expected [0-9] but "A" found.

the full command here
strace -f ./a.out |& b3  -s
{"syscall":"execve","args":["./a.out",["./a.out"],140724292233112,"..."],"result":0,"timing":null,"pid":null,"type":"SYSCALL"}
{"syscall":"brk","args":[],"result":32165888,"timing":null,"pid":null,"type":"SYSCALL"}
[PARSE ERROR] SyntaxError: Expected [0-9] but "A" found.

it seem odd, because the instruction look complete (maybe the comment in the first parameter is the reason).

i'm no expert un peg but it seem that this could do the job
_ = space comment { return undefined }
space = [ \t\n\r]*

comment = space p:(single / multi)*
single = '//' p:([^\n]*) {return p.join('')}
multi = "/*" inner:(!"*/" i:. {return i})* "*/" {return inner.join('')}

thanks to:
https://stackoverflow.com/questions/26556586/peg-js-how-to-parse-c-style-comments


Cluster startup failure in CI

As evidenced in https://circleci.com/gh/WallarooLabs/wallaroo/17791#artifacts/containers/0
The test exits with following error, immediately after starting the wallaroo runners:
2019-04-02 23:56:24,576 DEBUG    [stoppable_thread.py:31] WaitForClusterToResumeProcessing stopped with error
2019-04-02 23:56:24,576 DEBUG    [stoppable_thread.py:32] Timed out after 30 seconds while waiting for cluster to resume processing.
2019-04-02 23:56:24,577 ERROR    [cluster.py:556] Encountered and error when starting up the cluster
2019-04-02 23:56:24,578 ERROR    [cluster.py:557] Timed out after 30 seconds while waiting for cluster to resume processing.

The workers themselves all seem to stall right after connecting to the initializer's control channel:
initializer:
--- initializer (pid: 29167, rc: None) ->

Adding level 1
****CLUSTERING MODE is active****
****AUTOSCALE MODE is active****
****DEBUG is active****
||| Resilience directory: /tmp/res-data.4ivt9ww8|||
Set up external channel listener on <IP_ADDRESS>:20010
Running as Initializer...
AUTOSCALE: Waiting for new autoscale event.
initializer external: listening on <IP_ADDRESS>:20010
initializer control: listening on <IP_ADDRESS>:20006
metrics outgoing connected
_create_control_connection: call from control_channel_tcp line 209
Worker worker2 control channel identified
_create_control_connection: call from line 584
_create_control_connection: target_name worker2 host <IP_ADDRESS> service 20036
ControlSenderConnectNotifier: connected to worker2 at <IP_ADDRESS>:20036.
_create_control_connection: call from control_channel_tcp line 209
_create_control_connection: call from line 584
_create_control_connection: target_name worker3 host <IP_ADDRESS> service 20041
Worker worker3 control channel identified
ControlSenderConnectNotifier: connected to worker3 at <IP_ADDRESS>:20041.
_create_control_connection: call from control_channel_tcp line 209
_create_control_connection: call from line 584
_create_control_connection: target_name worker4 host <IP_ADDRESS> service 20044
Worker worker4 control channel identified
ControlSenderConnectNotifier: connected to worker4 at <IP_ADDRESS>:20044.
_create_control_connection: call from control_channel_tcp line 209
Worker worker5 control channel identified
_create_control_connection: call from line 584
_create_control_connection: target_name worker5 host <IP_ADDRESS> service 20047
ControlSenderConnectNotifier: connected to worker5 at <IP_ADDRESS>:20047.
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed
ExternalChannelConnectNotifier (initializer): server closed

--- initializer (pid: 29167, rc: None) <-

worker1-4: (they all have identical logs)
--- worker1 (pid: 29166, rc: None) ->

Adding level 1
****CLUSTERING MODE is active****
****AUTOSCALE MODE is active****
****DEBUG is active****
||| Resilience directory: /tmp/res-data.4ivt9ww8|||
Set up external channel listener on <IP_ADDRESS>:20033
_create_control_connection: call from line 107
AUTOSCALE: Waiting for new autoscale event.
worker1 external: listening on <IP_ADDRESS>:20033
worker1 control: listening on <IP_ADDRESS>:20011
_create_control_connection: call from line 584
_create_control_connection: target_name initializer host <IP_ADDRESS> service 20006
Sent control message to initializer
metrics outgoing connected
ControlSenderConnectNotifier: connection to initializer at <IP_ADDRESS>:20006  failed!
ExternalChannelConnectNotifier (worker1): server closed
_create_control_connection: call from line 584
_create_control_connection: target_name initializer host <IP_ADDRESS> service 20006
ControlSenderConnectNotifier: connected to initializer at <IP_ADDRESS>:20006.

@JONBRWN and I have looked into this and our initial hypothesis is the following:

The initializer takes some time to start its connection due to a busy VM
The joining worker starts up and attempts to connect. This attempt fails because the initializer isn't listening yet.
This puts the worker in a bad state in its startup state machine, that results in nothing moving forward
The worker retries the connection attempt and succeeds, but is now in a bad state and cannot progress.

There are 2 places where we can address this:

Fix the bad state transition
Add a busy-loop check in the test harness that ensures that the initializer is ready and listening before starting any other workers


Add files and changes for the documentation

Pull request details
Describe the changes made in this pull request
The files have the documentation structure and the model's mathematical formulation.
List of related issues or pull requests
Closes #12 and #15
Collaboration confirmation
As a contributor I confirm

[x] I read and followed the instructions in README.dev.md
[x] The documentation is up to date with the changes introduced in this Pull Request (or NA)
[x] Tests are passing
[NA] Lint is passing

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@f0a06e2). Click here to learn what that means.
Patch has no changes to coverable lines.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff            @@
##             main       #26   +/-   ##
========================================
  Coverage        ?   100.00%
========================================
  Files           ?         1
  Lines           ?        38
  Branches        ?         0
========================================
  Hits            ?        38
  Misses          ?         0
  Partials        ?         0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Configure CSP config to allow the custom domain

Fixes rendering the media library previews because of CSP issues

LGTM!
I was a bit unsure by the "localhost:1337" usage without "http..." but I think it should work just fine.

I just didn't want it to be undefined :D There is probably a cleaner way to do it


Change color of panels

We have received a few requests for being able to change the color of the panel / text on this application. Maybe just use color picker and optional box to add a hex code.

This would require a substantial amount of code changes. Should consider in next version.


Replace mixins with higher-order components for React 0.13

Have you thought about React 0.13 compatibility re: the deprecation of Mixins? Martyjs offers Marty.createContainer to work around this, would love to hear your thoughts.

Interesting. I only heard that mixins wouldn't be supported for the ES6 class syntax.
I'll sort out any pressing issues for 1.x and then work on a major release that'll use higher-order components instead of mixins.

Awesome :) yeah I'm not a fan of ES6 class syntax (see this gist), but we'll have to make do.

If React wants ES6 classes, I'll use ES6 classes. Simple as that ;)

Amen.

It's been a while, and I was wondering if you had any thoughts on this? Another option, that Baobab exposes for example, is using decorators. Would you like help with this?

I'm currently planning to start with the 2.0 rewrite next month as I will (hopefully) finally be working on the software using this library again. Right now I'm thinking about a better representation of the state and sorting out the routing and async resource loading. I'm a bit unhappy with how it's currently solved with stores and would like the "stores" to be passed in as props rather than globals.

I'll probably extract the mixins out of the core module as I plan to replace the current mixin-based data binding in our application with pure components (and contexts where necessary).
As this wouldn't be dogfooded anymore, I'm fine providing decorators or higher order components or both.

I've experimentally implemented the connect and connectProps decorators at https://github.com/foss-haas/fynx-decorators
The mixins have been moved out of Fynx 2 and now live at https://github.com/foss-haas/fynx-mixins
I can't think of any clever ways to implement connectVia, listenTo or listenToProp as decorators, so I've removed them from the decorators repo for now.
Any further discussion of decorators and mixins should probably take place at the dedicated repos.


Add named path bases to cargo (v2)

Introduce shared base directories in Cargo configuration files that in turn enable base-relative path dependencies.
Rendered
Draft Implementation PR: https://github.com/rust-lang/cargo/pull/12974
This is a resurrection of @jonhoo's RFC (#3074). Many thanks and kudos to him for the idea, original RFC text and original implementation.

Mind fixing the 'Rendered' link in the OP? https://github.com/dpaoliello/rfcs/blob/basepath/text/3529-cargo-path-bases.md :)

Mind fixing the 'Rendered' link in the OP? https://github.com/dpaoliello/rfcs/blob/basepath/text/3529-cargo-path-bases.md :)

Oops, my bad, thanks!

Creating a thread on Rust internals to discuss alternative solutions for this issue: https://internals.rust-lang.org/t/integration-with-mono-repos-via-intermediate-directories/20160

We discussed this in today's @rust-lang/cargo meeting. We were generally in favor, but wanted to see a few changes made.
@rfcbot merge
First, this should be base-paths, rather than base_path, for consistency with other manifest fields which use plurals and dashes.
@rfcbot concern rename-to-base-paths
Second, it should be possible to define this in Cargo.toml, not only in config.toml. config.toml or environment variables can always override, but Cargo.toml should be able to define the default values.
@rfcbot concern define-in-manifest-override-in-config
Third, we should restrict the possible names for bases, to reserve space for extension in the future. We felt that base names should be restricted to the same naming as package names: "The name must use only alphanumeric characters or - or _, and cannot be empty."
@rfcbot concern base-names-alphanumeric-with-dash-or-underscore
Finally, this should define a mechanism for Cargo to provide built-in base paths. User-defined base paths should shadow built-in base paths, so that we can add more in the future without creating conflicts. And we should provide a built-in workspace base path that refers to your workspace root.
@rfcbot concern allow-built-in-base-paths-with-shadowing
@rfcbot concern define-built-in-workspace-base-path

@joshtriplett I've updated the RFC to address these concerns
Also, I especially love the built-in workspace base path - that's super nice!

@rfcbot resolved rename-to-base-paths

@rfcbot resolved allow-built-in-base-paths-with-shadowing
@rfcbot resolved define-built-in-workspace-base-path

@rfcbot resolved base-names-alphanumeric-with-dash-or-underscore

@rfcbot resolved define-in-manifest-override-in-config

@dpaoliello Thank you for the updates!

@rfcbot concern need-for-manifest
Unfortunately, I wasn't able to be in the team meeting and I'm confused on the manifest use case.  Whether we keep it or not, the reason should be passed along so it can be included in the RFC.
Going over the notes, unfortunately not much was captured.  I see that some felt it "weird".  I'm assuming this is partly from project state being dependent on environment state.
So one way we go about this, paths must be specified in the manifest and can be overridden in the config (the interpretation of what I saw in the meeting notes but not captured in the RFC).  This negates the primary use case of the RFC as this is trying to help when a package can't know about everything else.
If we say that we support reading from manifest and config and mix as needed, with config having precedence, then that supports the use case but doesn't resolve what I'm assuming was the "weird" factor.  This also means that manifest or config is the minimal feature to implement and we don't necessarily need both out the gate.
I also find it weird for us to be supporting (and maybe encouraging) absolute paths for this in manifest (granted, technical any path dependency can be but this features mostly seems centered on it).
In addition, its not clear to me what users problem we'd be solving by having this in the manifest.  I see the benefit for base = "workspace" (and we could re-invent the existing path dependencies as defaulting to base = "package") but its not clear to me what a repo would look like that is large enough to need "base"s while still being one workspace.
btw last informal chat I remember on this, a way to reframe some of the weirdness about this is to treat this like other sources that are dependent on the config.  I wish I remembered other details of that conversation because the participants at that time felt a lot more hesitance on this than I feel like is being shown now and I worry we lost some useful context for concerns.

I believe the manifest use case is about convenience: if you have a lot of dependencies cluster together which are far away from the current crate, then it can be useful to create a base path with the common subdirectory:
[dependencies]
my_util = { path = "my_util", base = "utilities" }
time = { path = "datetime/time", base = "utilities" }
date = { path = "datetime/date", base = "utilities" }

[base-paths]
utilities = "../../../common/utilities"

If you have all these crates in a workspace, then this is partially handled by the workspace built-in base name, but it may still be convenient to have a name for a more specific path. It's also possible that there might not be a single workspace for all of these if there are submodules or this is a large monorepo.

I believe the manifest use case is about convenience: if you have a lot of dependencies cluster together which are far away from the current crate, then it can be useful to create a base path with the common subdirectory:

Another use case which would be good to mention in the RFC is that for some use cases, the "named path bases" change is more than just convenience.
At my workplace, we manage multiple repositories, each with its own build system. These build systems call cargo to build Rust code. We create "publishes" from some some repositories that get consumed by other repositories. We include some Rust sources as a part of these publishes. The "consuming" repositories  have "pointer" file with the path to a specific  publish. We continually build these publishes and update the pointers in the consuming repositories.
To handle this use case today, we auto-generate Cargo.toml files with path dependencies:
Input template:
[dependencies]
foo = { path = "${MY_PUBLISH}/path/to/rust/crate/foo" }

Output Cargo.toml:
[dependencies]
foo = { path = "/very/long/path/to/publish/2024-01-01/path/to/rust/crate/foo" }

While generated Cargo.toml files work, there are several downsides:

It's messy to have a generated file in the "source" tree instead of a separate build directory with build artifacts. This requires making sure that the SCM ignores the Cargo.toml (e.g., using .gitignore for Git or svn:ignore property for SVN).
We need to maintain the logic to auto-generate the Cargo.toml, including when the publish pointers get updated.
We need to educate our team on this additional difference from "normal cargo-based Rust development" in our environment.

The "named path bases" feature would be great since it would eliminate the need to generate Cargo.toml files. Instead, the Rust build logic could write the published Rust source paths in a config.toml or set environment variables.

I believe the manifest use case is about convenience: if you have a lot of dependencies cluster together which are far away from the current crate, then it can be useful to create a base path with the common subdirectory:

From what I understand, this is speculation; let's leave it to people who were present or voiced the concern.
Which reminds me of something that worries me about this further: we would be designing the manifest part of this without any users for those use cases to provide feedback.  Even if we leave it as a future possibility, I worry these would be divergent enough that we'd at least want users to help guide this discussion.
Even for the feature as-is, we have only one or two users to be able to discuss this with so far which makes it harder for me to feel confident we are designing the right thing.  However, the challenge is that this is for such large users that its hard to have too many of them.

I believe the manifest use case is about convenience: if you have a lot of dependencies cluster together which are far away from the current crate, then it can be useful to create a base path with the common subdirectory:

From what I understand, this is speculation; let's leave it to people who were present or voiced the concern.

@arlosi @joshtriplett care to comment about define-in-manifest-override-in-config ?

@arlosi @joshtriplett care to comment about define-in-manifest-override-in-config ?

From what I remember in the discussion: we thought it would be weird to require defining it in a config file, and that similar to [profile] it should be possible to define it in both the manifest or the config (with config taking precedence).

@epage As one of the folks in the discussion who was interested in this being settable in the manifest: the use case is very much what @dpaoliello describes, being able to reference crates in the workspace or path dependencies on crates not in the workspace without having to count and fiddle with ../s in multiple places.
By way of example, one project I have uses path = "../cratename" dependencies for crates in the workspace, as well as path = "../../path/here" dependencies for crates in adjacent crates in the same project but not in a workspace. It'd be nice if these could use base = "workspace" and base = "projectname".
This gets even worse if you have crates organized at more than one directory level (because then you have to remember if you need ../../ or ../../../), or if you have a workspace that also has a top-level crate (because then you have to remember if you need ../ or ../../).

The more that I think about having base paths in the manifest, the less that I like it.
If you are using it for convenience, then this suggests that you have a bunch of packages locally which you'd like to reference from each other. In which case, why not drop a config.toml in a common parent directory that then points to each of the useful subdirectories with your packages? If you are putting the base paths in the manifests, then you'll need to duplicate that list into each of your manifests.
The original concern mentioned "default values". I'm not sure how useful that is versus using the patch feature - if you want to override where Cargo looks for packages, then that's what patch is for.
I'm going to scope it out of this RFC, and it can be proposed later if someone has a strong case for it.

I continue to think there's value in placing this in the manifest. We regularly find ourselves wishing that things in the config also existed in the manifest.
However, I'm not going to treat that as a blocking concern. We can add it to the large pile of things that only exist in config and not yet in the manifest. Hopefully we shrink that pile over time.

@epage I've removed support for defining this in the manifest, can you please resolve the need-for-manifest concern?

I had missed an important piece of the conversation. Specifically that @joshtriplett's use case is not hypothetical. The second paragraph here is his actual use case. He has two different workspaces and regularly needs to construct path dependencies from one to the other. (I would like to apologize again, and publicly, for the rude thing I said when calling for a non-hypothetical user.) This leads me to being comfortable merging a version of this RFC that does allow setting it in the Cargo.toml.
That being said, adding that functionality later is always a possibility. So if the decision of the team is to accept an RFC that only discusses config, I would not object. Leaving Cargo.toml for later is a two way door.

I had missed an important piece of the conversation. Specifically that @joshtriplett's use case is not hypothetical. The second paragraph here is his actual use case. He has two different workspaces and regularly needs to construct path dependencies from one to the other. (I would like to apologize again, and publicly, for the rude thing I said when calling for a non-hypothetical user.) This leads me to being comfortable merging a version of this RFC that does allow setting it in the Cargo.toml.
That being said, adding that functionality later is always a possibility. So if the decision of the team is to accept an RFC that only discusses config, I would not object. Leaving Cargo.toml for later is a two way door.

I agree that this is a valid use case for this feature, but it does not require path bases in the manifest - they could be specified in the configuration instead. It might be more convenient to have them in the manifest, but given all of the complexity surrounding how to handle workspace vs member manifests I'd rather defer that for now.

If we feel the config use case is important on its own, an important reason for splitting out manifest support is we don't block on the extra questions that introduces (workspace vs package, implicit vs explicit inheritance, etc)

@epage I've removed support for defining this in the manifest, can you please resolve the need-for-manifest concern?

There is a little more nuance I want to dig into.  Will need to get back to this later (soon, I'm back from vacation)

@rfcbot concern comments

@rfcbot resolved need-for-manifest

@rfcbot resolved comments


QUIC Glossary

This is becoming needed.

This pull request is ready to merge

Merged.
An afterthought: links to definitions would be beneficial.

An afterthought: is it possible that some of these would eventually move to doc/man7/openssl-glossary.pod?


[Experimental] Sorin Prompt

Added Sorin Prompt from Prezto. The prompt depends on a LOT of Prezto functions so not everything works yet. The branch is really messy because I had to build it off of my fork, so don't directly merge it. Anyways, feel free to make changes!

@Eriner @ericbn Can you review this?

@AtomicCoding, I have second thoughts about adding more prompt themes to zim. And it's not even the first time.  :- )
As I've stated before:

I still think that the themes that come with zim, alongside our git-info module, provide a good basis for users to customize their own themes, and that we should not include variations of the already existing themes to our repo.

You can keep this as a fork under your GitHub user, if you intend to keep maintaining the code. Plus, the original sorin theme display many fine-grained pieces of information about git that our git-info module does not even support (because we want to keep things simple and fast).

@ericbn Should I close this?


Understanding the trainer parameters

I am looking at the SetFit example with SetFitHead:
# Create trainer
trainer = SetFitTrainer(
    model=model,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    loss_class=CosineSimilarityLoss,
    metric="accuracy",
    batch_size=16,
    num_iterations=20, # The number of text pairs to generate for contrastive learning
    num_epochs=1, # The number of epochs to use for contrastive learning
    column_mapping={"sentence": "text", "label": "label"} # Map dataset columns to text/label expected by trainer
)

Here, what exactly is the meaning of num_iterations?  And, why is num_epochs =1? Is that sufficient?
trainer.unfreeze(keep_body_frozen=False)

trainer.train(
    num_epochs=25, # The number of epochs to train the head or the whole model (body and head)
    batch_size=16,
    body_learning_rate=1e-5, # The body's learning rate
    learning_rate=1e-2, # The head's learning rate
    l2_weight=0.0, # Weight decay on **both** the body and head. If `None`, will use 0.01.
)
metrics = trainer.evaluate()

Here the number of epochs is 25 and we are training the head and the body with different learning rates. Any reason why the per-epoch metrics are not displayed?

Here, what exactly is the meaning of num_iterations? And, why is num_epochs =1? Is that sufficient?

num_iterations is a somewhat poorly named parameter that indicates how many times we create "contrastive pairs". Every time we create these contrastive pairs, we create one "positive pair" (two sentences that are of the same class) and one "negative pair" (two sentences that are of another class) for every sentence. So, 2 pairs per sentence every time that we create the contrastive pairs. If we do it num_iterations times, then we create num_sentences * 2 * num_iterations pairs in total.
Doubling the num_iterations is roughly equivalent to doubling num_epochs, with one notable difference: with num_iterations being doubled, we "freshly" generate more pairs for training, while with doubling num_epochs we reuse the same pairs we already generated, if that makes sense. In practice, the former is recommended, so we tend to recommend increasing num_iterations rather than increasing num_epochs when you want to train for longer.
The above counts specifically for finetuning the underlying Sentence Transformer. That is step 1 of SetFit. Step 2 is training the classifier, which converts the embeddings produced by the underlying sentence transformers into the correct class labels. When using the SetFitHead, this is roughly "traditional" training. With other words, no fancy pairs. This means that we now have num_sentences samples (instead of num_sentences * 2 * num_iterations), so here we have to increase the batch number of epochs to get the model to really learn this.
We don't have per-epoch metrics because there is no mid-training evaluation or logging implemented. Ideally, that would become a part of the upcoming v1.0.0 release.
I hope this clarifies things a bit.

Tom Aarsen


Fix for #56.

Uses playwright-stealth to mask headless browser signature.

Thanks for the tip. I didn't think this would make a difference because it doesn't seem to affect the playwright browser's behavior when hitting bot.sannysoft.com, but it does seem to help.


Error while android build

What went wrong:
Could not resolve all files for configuration ':app:debugCompileClasspath'.

Could not find :ScanditBarcodeScanner:.
Searched in the following locations:
file:/Library/Android/sdk/extras/m2repository//ScanditBarcodeScanner//ScanditBarcodeScanner-.pom
file:/Library/Android/sdk/extras/m2repository//ScanditBarcodeScanner//ScanditBarcodeScanner-.aar
file:/Library/Android/sdk/extras/google/m2repository//ScanditBarcodeScanner//ScanditBarcodeScanner-.pom
file:/Library/Android/sdk/extras/google/m2repository//ScanditBarcodeScanner//ScanditBarcodeScanner-.aar
file:/Library/Android/sdk/extras/android/m2repository//ScanditBarcodeScanner//ScanditBarcodeScanner-.pom
file:/Library/Android/sdk/extras/android/m2repository//ScanditBarcodeScanner//ScanditBarcodeScanner-.aar
https://maven.google.com//ScanditBarcodeScanner//ScanditBarcodeScanner-.pom
https://maven.google.com//ScanditBarcodeScanner//ScanditBarcodeScanner-.aar
https://jcenter.bintray.com//ScanditBarcodeScanner//ScanditBarcodeScanner-.pom
https://jcenter.bintray.com//ScanditBarcodeScanner//ScanditBarcodeScanner-.aar
https://repo1.maven.org/maven2//ScanditBarcodeScanner//ScanditBarcodeScanner-.pom
https://repo1.maven.org/maven2//ScanditBarcodeScanner//ScanditBarcodeScanner-.aar
file:/SCM/MobileApp/platforms/android/app/libs/ScanditBarcodeScanner-.aar
file:/SCM/MobileApp/platforms/android/app/libs/ScanditBarcodeScanner.aar
Required by:
project :app

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

Hi @avnish90
You're missing the aar somehow. Is it possible that you downloaded just this repository or added the repository directly? The repository does not contain the aar or a way to fetch it, the 5.x releases for cordova have to be downloaded from your Scandit account as only there do they contain the aar.

@moritzhartmeier Thanks for your quick response, but I have downloaded 5.x release for cordova from my Scandit account

Hm, that's odd then. It should be in the filesystem at file:/Users/synerzip/SCM/MobileApp/platforms/android/app/libs/ScanditBarcodeScanner.aar, the fact that it isn't there would then mean that something went wrong during the installation of the plugin. So i would suggest first removing the plugin again and then readd it and see whether there are any error messages. If nothing obvious shows up, i think we would need the project (or a minimal version of it) where this is reproducible so we can look into it.

@moritzhartmeier Again downloaded 5.x release for Cordova but directory didn't content package.json file.

Is that something you noticed now or something that the plugin install complained about? Just to check i downloaded both the 5.13.3 and 5.14.0BETA1 cordova packages and they both contain a package.json although I am pretty positive that a package.json is not actually needed for the plugin to work, it would just be needed for npm distribution which only started with 6.1.0. What version are you downloading? How is the archive named that you're trying to use?

Hi @moritzhartmeier,  Downloaded "scandit-barcodescanner-phonegap_5.0.1.zip".

@avnish90 any reason why you are downloading 5.0.1? That's a very old version (like 2 years old), please get the newest stable release (5.13.3) instead. Alternatively you might also want to try the 6.2 beta which is the absolutely newest release, be aware that it is still a beta but the 6.2 production will come out in about 2 weeks so if you are starting from scratch here i would recommend directly using 6.2 as it has a new and improved API and it will enable you to do things that the 5.x releases are not capable of.

Downloaded 5.13.3, it's working fine in iOS but facing below error while Android build.
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:processDebugResources'.

Failed to execute aapt

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

Get more help at https://help.gradle.org

BUILD FAILED in 1s
FAILED
25 actionable tasks: 1 executed, 24 up-to-date
/SCM/MobileApp/platforms/android/gradlew: Command failed with exit code 1 Error output:
/.gradle/caches/transforms-1/files-1.1/core-1.0.0.aar/46e19d4506505b68270748cc95ab4221/res/values/values.xml:133:5-70: AAPT: error: resource android:attr/fontVariationSettings not found.
/.gradle/caches/transforms-1/files-1.1/core-1.0.0.aar/46e19d4506505b68270748cc95ab4221/res/values/values.xml:133:5-70: AAPT: error: resource android:attr/ttcIndex not found.
/SCM/MobileApp/platforms/android/app/build/intermediates/incremental/mergeDebugResources/merged.dir/values/values.xml:101: error: resource android:attr/fontVariationSettings not found.
/SCM/MobileApp/platforms/android/app/build/intermediates/incremental/mergeDebugResources/merged.dir/values/values.xml:101: error: resource android:attr/ttcIndex not found.
error: failed linking references.
Failed to execute aapt
com.android.ide.common.process.ProcessException: Failed to execute aapt
at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:796)
at com.android.build.gradle.tasks.ProcessAndroidResources.invokeAaptForSplit(ProcessAndroidResources.java:551)
at com.android.build.gradle.tasks.ProcessAndroidResources.doFullTaskAction(ProcessAndroidResources.java:285)
at com.android.build.gradle.internal.tasks.IncrementalTask.taskAction(IncrementalTask.java:109)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$IncrementalTaskAction.doExecute(DefaultTaskClassInfoStore.java:173)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:134)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:121)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:122)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:197)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:107)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:111)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:92)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:63)
at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:197)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:107)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:124)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:80)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:105)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:99)
at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:625)
at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:580)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:99)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: com.android.tools.aapt2.Aapt2Exception: AAPT2 error: check logs for details
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:503)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:482)
at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:79)
at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:794)
... 41 more
Caused by: java.util.concurrent.ExecutionException: com.android.tools.aapt2.Aapt2Exception: AAPT2 error: check logs for details
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:503)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:462)
at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:79)
at com.android.builder.internal.aapt.v2.QueueableAapt2.lambda$makeValidatedPackage$1(QueueableAapt2.java:179)
Caused by: com.android.tools.aapt2.Aapt2Exception: AAPT2 error: check logs for details
at com.android.builder.png.AaptProcess$NotifierProcessOutput.handleOutput(AaptProcess.java:463)
at com.android.builder.png.AaptProcess$NotifierProcessOutput.err(AaptProcess.java:415)
at com.android.builder.png.AaptProcess$ProcessOutputFacade.err(AaptProcess.java:332)
at com.android.utils.GrabProcessOutput$1.run(GrabProcessOutput.java:104)
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:processDebugResources'.

Failed to execute aapt

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

Get more help at https://help.gradle.org

The old version probably fails because it was done for a much earlier cordova version and something changed in between.
For the new version I assume this has something to do with your current project and cordova itself. I found some similar issues through google:

https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/issues/207
https://stackoverflow.com/questions/49208772/error-resource-androidattr-fontvariationsettings-not-found

And the solution is to update the compile sdk version:
compileSdkVersion 28


Integrate protoDC2 into DESCQA-2

integrate the protoDC2 catalog into DESCQA-2

The reader for proto-dc2 is basically done, so once #8 is resolved this one will be almost done too.

This is done (See https://github.com/LSSTDESC/gcr-catalogs/pull/7). Thanks to @dkorytov.
(Can someone who has permission close this issue?)


Secondary animations should still run when using Navigator pushAndRemoveUntil() or pushReplacement()

My application makes use of TransitionRoute's secondaryAnimation to create a slide-on/slide-off effect for page navigation - the new route pushes the old one out of the way. However, when I wish to push a new "root" route using pushAndRemoveUntil(), the secondary animation of the previous head does not run. If pages are transparent, they will overlap.
This seems inconsistent with calling this action a "push...", as it does not have the same visual effect as a standard push(). The removing happens after the animation is complete, so it seems reasonable that the secondaryAnimation should run too.
Steps to Reproduce

Use the following simplified route class:

class MyPageRoute<T> extends PageRouteBuilder<T> {
  IwPageRoute({
    WidgetBuilder bodyBuilder,
[main.dart.txt](https://github.com/flutter/flutter/files/3675564/main.dart.txt)

    RouteSettings settings,
  }) : super(
          pageBuilder: (context, animation, secondaryAnimation) => bodyBuilder(context),
          transitionsBuilder: (context, animation, secondaryAnimation, child) =>
            SlideTransition(
              position: Tween<Offset>(begin: Offset(1.0, 0), end: Offset.zero).animate(animation),
              child: SlideTransition(
                position: Tween<Offset>(begin: Offset.zero, end: Offset(-1.0, 0)).animate(secondaryAnimation),
                child: child),
            ),
          settings: settings,
        );
}

Push (pushNamed) a new route on top (both pages animate)
Push a new route to replace all others (only the new page animates)
pushNamedAndRemoveUntil("name", (Route<dynamic> route) => false, arguments: arguments)

(See attached example app)
main.dart
Logs
The attached sample app produces no run-time logs
Flutter Analyze
Analyzing example...
No issues found! (ran in 1.2s)

Suggested resolution
I have found that adding the following at line  #1937 in navigator.dart (pushAndRemoveUntil after newRoute.didChangeNext(null);) resolves the issue for pushAndRemoveUntil. A similar fix would apply for pushReplacement:
if (precedingRoute != null) {
  precedingRoute.didChangeNext(newRoute);
}

Flutter Doctor
[✓] Flutter (Channel stable, v1.9.1+hotfix.2, on Linux, locale en_GB.UTF-8)
    • Flutter version 1.9.1+hotfix.2 at /flutter
    • Framework revision 2d2a1ffec9 (3 weeks ago), 2019-09-06 18:39:49 -0700
    • Engine revision b863200c37
    • Dart version 2.5.0

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Android/sdk
    • Java binary at: /opt/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
    • All Android licenses accepted.

[✓] Android Studio (version 3.1)
    • Android Studio at /opt/android-studio
    • Flutter plugin version 29.0.1
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)

[✓] IntelliJ IDEA Community Edition (version 2018.3)
    • IntelliJ at /opt/intellij/idea-IC-183.5912.21
    • Flutter plugin version 36.1.1
    • Dart plugin version 183.6270

[✓] VS Code (version 1.37.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.4.1

[✓] Connected device (1 available)
    • I4213 • CQ3001V8FE • android-arm64 • Android 9 (API 28)

• No issues found!

Hello,
The issue still exists on master channel - the same alteration also still resolves the issue.
Below my flutter doctor output on master for reference:
[✓] Flutter (Channel master, v1.10.7-pre.99, on Linux, locale en_GB.UTF-8)
    • Flutter version 1.10.7-pre.99 at /flutter
    • Framework revision 2de1e4f4a1 (9 hours ago), 2019-09-30 22:05:53 -0400
    • Engine revision<PHONE_NUMBER>
    • Dart version 2.6.0 (build 2.6.0-dev.3.0 692230b484)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Android/sdk
    • Java binary at: /opt/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
    • All Android licenses accepted.

[✓] Android Studio (version 3.1)
    • Android Studio at /opt/android-studio
    • Flutter plugin version 29.0.1
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)

[✓] IntelliJ IDEA Community Edition (version 2018.3)
    • IntelliJ at /opt/intellij/idea-IC-183.5912.21
    • Flutter plugin version 36.1.1
    • Dart plugin version 183.6270

[✓] VS Code (version 1.37.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.4.1

[✓] Connected device (1 available)
    • I4213 • CQ3001V8FE • android-arm64 • Android 9 (API 28)

• No issues found!

Thanks for trying

Been running into this with pushNamedAndRemoveUntil. This fix fixes that as well. Thanks @joellurcook!


background images not rescaling on mobile devices

Firstly Academic is really great, thank you so much!
I noticed that background images on mobile devices dont seem to be rendering properly (or at least behave differently to my desktop browser).
On desktop (both chrome and safari) the background images rescale with the page width. On mobile they appear to render with a fixed dimension (much larger than the page). Is this behaviour expected? Is there a way to fix the background image width to 100% page width by default? Typically I would use some css to do this.

The CSS .parallax implementation is set to cover the section with the image. There is no mobile or desktop specific CSS. The resizing behaviour you see is based on the the CSS cover attribute and the dimensions of the provided image.

If you update to the latest master, you'll pick up some new options that have just been added based on your feedback:
image_size = "cover"  #  Options are `cover` (default), `contain`, or `actual` size.
image_position = "center"  # Options include `left`, `center` (default), or `right`.
image_parallax = true  # Use a fun parallax-like fixed background effect? true/false

I was still struggling to get this to work to my satisfaction on mobile and desktop. In case it is helpful to anyone else, I used the options:
  # Background image.
  image = "jumbotron.jpg"  # Name of image in `static/img/`.
  image_darken = 0.1  # Darken the image? Range 0-1 where 0 is transparent and 1 is opaque.
  image_size = "contain"  #  Options are `cover` (default), `contain`, or `actual` size.
  image_position = "center"  # Options include `left`, `center` (default), or `right`.
  image_parallax = true  # Use a fun parallax-like fixed background effect? true/false

as the default, and then disabled parallax for mobile by adding the following to my assets/scss/custom.scss:
/*disable parallax for background image on mobile*/
@media only screen and (max-width:749px) {
  .parallax {
    background-attachment: inherit;
  }
}


[FLINK-32563] Add disable-archunit-tests profile

This new profile will be used to disable archunit tests in the CI when connectors are tested against non-main Flink version (every version that is not the version they were built against including snapshots). This PR is part of a bigger work on CI (spread accross multiple branches in multiple PRs) to disable all sanity checks (including dependency-convergence) on non-main Flink versions.
R: @MartijnVisser
CC: @tzulitai

I submitted against main instead of parent-pom branch closing


Use print instead of input after starting server

Description
This super short PR fixes the usage of input after starting the server and replaces it with print.
The main problem solved is the necessity of having a TTY attached in case we use input - for example, with the previous input, Docker was failing if running without interactive mode.

@klaa97 , just created a new release of robyn for this. https://pypi.org/project/robyn/


Function that recognizes/transcribes a pre-recorded audio file.

Feature Request
Function that transcribes a pre-recorded audio file.
Why it is needed
For my app I need to record and recognize/transcribe speech simultaneously. This works fine on ios, but on android the api policy is to only allow one mic action at a time apparently. Having this function would at least let me record first and then transcribe the audio file afterwards as soon as I finish recording.
Possible implementation
I imagine this shouldn't be too hard to do with code already implemented? Maybe this function already exists here in some form and I just didn't find it?

Hey @amorimlucas I am trying to find a solution for this too. Have you found the solution on how to do this?

Hey @Aung-Myint-Thein, I ended up showing users on android an alert asking them to choose either to record or transcribe their voice. Couldn't find a better solution at this point.

google has reconigzation api for this but i also want to get a file from this lib instead

I also want to use a file as source for recognition.

@amorimlucas to you have the code by which you were able to get it working for ios?


Fix canonical url if multiversion is not used

Closes https://github.com/scylladb/sphinx-scylladb-theme/issues/405
Removes /index.html in projects that do not use the multi version plugin (e.g scylla-docs), which is causing duplicate content errors.
How to test this PR

Clone this PR.

Run make preview to run the docs without the multiversion plugin.

Inspect the code. The canonical tag does not have the "index.html" suffix:

Looks good. The suffix is not there.