[SPARK-12989] [SQL] Delaying Alias Cleanup after ExtractWindowExpressions

JIRA: https://issues.apache.org/jira/browse/SPARK-12989
In the rule ExtractWindowExpressions, we simply replace alias by the corresponding attribute. However, this will cause an issue exposed by the following case:
val data = Seq(("a", "b", "c", 3), ("c", "b", "a", 3)).toDF("A", "B", "C", "num")
  .withColumn("Data", struct("A", "B", "C"))
  .drop("A")
  .drop("B")
  .drop("C")

val winSpec = Window.partitionBy("Data.A", "Data.B").orderBy($"num".desc)
data.select($"*", max("num").over(winSpec) as "max").explain(true)

In this case, both Data.A and Data.B are alias in WindowSpecDefinition. If we replace these alias expression by their alias names, we are unable to know what they are since they will not be put in missingExpr too.

Test build #50246 has started for PR 10963 at commit 468abca.

Test build #50246 has finished for PR 10963 at commit 468abca.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50246/
Test PASSed.

Merged build finished. Test PASSed.

Test build #50318 has started for PR 10963 at commit 8025de0.

Test build #50318 has finished for PR 10963 at commit 8025de0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50318/
Test PASSed.

Merged build finished. Test PASSed.

Test build #50481 has started for PR 10963 at commit 476dcb4.

Test build #50481 has finished for PR 10963 at commit 476dcb4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50481/
Test PASSed.

Thanks, merging to master and 1.6.


Removing fields from HiveObject causing app startup to freeze in production.

Question
Hive docs say that I can remove a Hive field as long as I do not use the field number again for any other field.
Fields can be removed, as long as the field number is not used again in your updated class.

But after doing so, and running the app in production, the app is stuck on the start up/splash screen.
I have existing models in cache that contain the fields that I am not longer using, but according to the docs, those fields would just be ignored. Am I doing something wrong?
To fix this, I am required to clear both cache and storage. I am also using flutter_secure_storage for encrypting the hive boxes. I have had issue with secure storage before doing something similar, but I thought it was weird that right after I adjusted the models that this happened.
Code sample
As you can see, I commented out a few fields that I am no longer using. Doing this worked fine in debug mode, but when I ran it in release, I started having the issues stated above.
@freezed
abstract class Session extends HiveObject with _$Session {
  @HiveType(typeId: 4, adapterName: 'SessionAdapter')
  factory Session({
    @HiveField(0) required int pid,
    @HiveField(1) required int rid,
    @HiveField(2) required DateTime dateTime,
    @HiveField(3) int? sid,
    @HiveField(4) required String service,
    @HiveField(5) required int duration,
    @Default(0) @HiveField(6, defaultValue: 0) int status,
    @HiveField(7) String? notes,
    @HiveField(8) DateTime? editDate,
    @HiveField(9) required String description,
    // @HiveField(10)
    // String time;
    @HiveField(11) required String facility,
    @HiveField(12) required String patientName,
    // @HiveField(13) String? sessionResponse,
    // @Default(false) @HiveField(14, defaultValue: false) bool isQueued,
    // @HiveField(15) SessionAction? sessionAction,
    // @HiveField(16) String? dataToServer,
    // @HiveField(17) String? sessionResponseType,
    @Default(0) @HiveField(18, defaultValue: 0) int clinicianId,
  }) = _Session;

  // ignore: unused_element // private constructor used so hive can be used.
  Session._();

  factory Session.fromJson(Map<String, dynamic> json) =>
      _$SessionFromJson(json);
}

Version

Platform: Android
Flutter version: 3.0.6-0.0.pre.1
Hive version: ^1.1.0

This really frustrating, on android you can fix this issue in AndroidManifest by setting android:allowBackup="false"
But on ios I'm not able to find a solution


Ignore resolved interface IDs for non-LinkLocal IPv6 Addresses

Problem
We rely on the mDNS resolution to tell us what the peer node's address is.
We also pickup the interface ID of the mDNS resolution and then use that interface ID for communicating with that node. This seems to have been added to support IPv6 LLAs which require us to specify which interface to use when communicating with a node's ULA.
For bridged networks like Thread, the mDNS advertisement might not be visible on the same interface the peer is reachable on.
We should avoid setting the interface ID for non-LLA addresses because the sender's routing table should be able to figure out the interface ID correctly.
Change overview
Ignore the interface ID of the mDNS resolution if the resolved address is not an IPv6 LLA.
Testing
How was this tested? (at least one bullet point required)

If manually tested, what platforms controller and device platforms were manually tested, and how?
Tested pairing and control with the CHIP Tool CLI and an m5 stack + nRF5.

@saurabhst ?

This seems fine, though I wonder whether we should be doing this in the mdns impl instead of at just this consumer....

mDNS isn't doing anything wrong here, we're just misusing the information that comes off of it.

mDNS isn't doing anything wrong here, we're just misusing the information that comes off of it.

Yes, but this is a fixup all consumers will need to do....

Yes, I would expect most platforms have a stream of mDNS information coming back to them, assuming you know it all after X seconds, in one block seems... like a bad assumption.


Error: cannot reshape tensor of 0 elements into shape [0, -1] because the unspecified dimension size -1 can be any value and is ambiguous

new error with instant_ngp whenever viewer is enabled (seems like it's only on the viewer side?)

Hi, the problem it seems still exist. Do you have any idea to debug it? Thanks!

Sorry that I was not plasted the error message for more explanation.
The detail of error message is:

Traceback (most recent call last):
File "/opt/conda/bin/ns-train", line 8, in
sys.exit(entrypoint())
File "/workspace/nerfstudio/nerfstudio/scripts/train.py", line 247, in entrypoint
main(
File "/workspace/nerfstudio/nerfstudio/scripts/train.py", line 233, in main
launch(
File "/workspace/nerfstudio/nerfstudio/scripts/train.py", line 172, in launch
main_func(local_rank=0, world_size=world_size, config=config)
File "/workspace/nerfstudio/nerfstudio/scripts/train.py", line 87, in train_loop
trainer.train()
File "/workspace/nerfstudio/nerfstudio/nerfstudio/engine/trainer.py", line 271, in train
self.eval_iteration(step)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/utils/decorators.py", line 70, in wrapper
ret = func(self, *args, **kwargs)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/utils/profiler.py", line 93, in inner
out = func(*args, **kwargs)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/engine/trainer.py", line 463, in eval_iteration
metrics_dict, images_dict = self.pipeline.get_eval_image_metrics_and_images(step=step)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/utils/profiler.py", line 93, in inner
out = func(*args, **kwargs)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/pipelines/base_pipeline.py", line 329, in get_eval_image_metrics_and_images
outputs = self.model.get_outputs_for_camera_ray_bundle(camera_ray_bundle)
File "/opt/conda/lib/python3.8/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/models/base_model.py", line 178, in get_outputs_for_camera_ray_bundle
outputs = self.forward(ray_bundle=ray_bundle)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/models/base_model.py", line 140, in forward
return self.get_outputs(ray_bundle)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/models/instant_ngp.py", line 180, in get_outputs
ray_samples, ray_indices = self.sampler(
File "/opt/conda/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
return forward_call(*input, **kwargs)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/model_components/ray_samplers.py", line 469, in forward
ray_indices, starts, ends = self.occupancy_grid.sampling(
File "/opt/conda/lib/python3.8/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/opt/conda/lib/python3.8/site-packages/nerfacc/estimators/occ_grid.py", line 187, in sampling
sigmas = sigma_fn(t_starts, t_ends, ray_indices)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/model_components/ray_samplers.py", line 414, in sigma_fn
return density_fn(positions).squeeze(-1)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/fields/base_field.py", line 65, in density_fn
density, _ = self.get_density(ray_samples)
File "/workspace/nerfstudio/nerfstudio/nerfstudio/fields/nerfacto_field.py", line 243, in get_density
h = self.mlp_base(positions_flat).view(*ray_samples.frustums.shape, -1)
RuntimeError: cannot reshape tensor of 0 elements into shape [0, -1] because the unspecified dimension size -1 can be any value and is ambiguous


ActionBar release review (internal, required for PageHeader release)

Component reviews for readiness
Reviews will be carried out by one or more members of the core contribution team. They will include as a minimum the following checks, which establish the "definition of done" for a component.
Paste the following checklist into the epic or issue under which the component is being made ready, then check where criteria passed, and add notes to clarify how an item is complete or what remains to be done: for anything more than minor/simple items, open issues to track them.
Tip You should be able to copy and paste the section below directly into a GitHub comment, then check where criteria passed, strike out where not applicable, and add notes to each item where applicable.
Once one or more components have been reviewed for readiness, the following steps are needed:
the flags for the components in package-settings.js should be changed to true.
the component SCSS should be included in /src/components/_index-released-only.scss.
run the tests, recreating snapshots (using -u), and check in the updated public CSS snapshot. NB it is sufficient to run yarn jest styles -u to complete the snapshot updates.
Review for release
Readiness

[ ] One or more scenarios for a design pattern have been identified as a useful unit of functionality to publish.
[x] A functioning component or components delivering those scenarios have been delivered and merged to master.
[x] Design maintainer has approved the implementation for those scenarios (via a comment on the relevant issue/epic).

Engineering review

[x] Breaking changes have only been introduced with prior approval, discussion and documented in release notes. Ideally deprecation notices in the prior major version must have been added in a timely fashion.
[x] The implementation takes into account, and does not impair, remaining and anticipated design scenarios.
[x] Public component features (names, props, etc) are consistent with Carbon-defined conventions and are consistent internally. Where there isn't an existing convention to apply, ensure robust precedents are being established.
[x] The UI produced is accessible, responsive, translatable, cross-browser, and responds to the currently set Carbon theme.
[x] Components are functional components using hooks.
[x] Public components which produce DOM structures support className.
[x] Public components support a ref (via React.forwardRef).
[x] All significant DOM elements have meaningful classes.
[x] Additional attributes that are not identified as props (such as title, aria-*, etc) are passed through to an appropriate DOM node of the component as HTML attributes.
[x] No warnings, errors or log messages in the console.
[ ] Each public component JS is exported in /src/components/index.js, each public component SCSS is included in /src/components/_index.scss, and each public component has a flag in package-settings.js.

Standards

[x] No linter warnings or errors are produced.
[x] Carbon tokens (theme, layout, motion) are used unless the design specifies otherwise.
[x] Code is formatted according to prettier rules (no use of //prettier-ignore).
[ ] Code is clear, maintainable and follows standard React practices and the code guidelines.
[x] Copyright header in every source file (js, css, scss etc.) with the appropriate years.

Testing

[x] There is a set of test cases for the components.
[ ] The tests exercise all inputs (props, slots, etc) and verify appropriate outputs.
[ ] The tests validate the behaviors and interactions defined in the design where practical.
[x] The tests achieve 100% coverage.
[x] No warnings, errors or log messages in the test output.

Documentation

[ ] Source code is satisfactorily commented and provides DocGen comments for all public components and their props.
[ ] There is a story for each design scenario. The stories expose all relevant props and actions, and additional usage documentation and code samples are available on the 'Docs' tab along with the props table.
[ ] There is a sandbox (or multiple sandboxes if appropriate) on CodeSandbox for the components.

Here are some initial thoughts and comments on the code

you're defining a separate sub component within ActionBar.js (ActionBarOverflowItems) and to be honest I think that it should be separated into it's own file. i don't see the benefit of containing ActionBarOverflowItems within ActionBar, so if only to simplify ActionBar.js i think ActionBarOverflowItems needs to be moved into it's own file.
in regards to ActionBarOverflowItems I'm seeing the class name ${blockClass}__overflow-menu used numerous times. if another block class type variable were created to use that value we could cut down on code by referring to blockClass2 or something instead of repeating ${blockClass}__overflow-menu-* numerous times. this of course can easily be alleviated by using my previous suggestion of moving it to it's own file.
on line 69 we have overflowItems.map((item, index) according to react this is an anti pattern.. We should instead ask the user to provide their own id's. "We don’t recommend using indexes for keys if the order of items may change. This can negatively impact performance and may cause issues with component state. When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort."
same issue on line 114
on line 205 we have ...prepareProps(Button.propTypes, [ as annoying as this is I think for the sake of fully using storybook as documentation we can't do this. it's very annoying that storybook doesn't currently have a way to extract the prop details to display when you try to cheat by doing something like using the proptypes from another component. believe me I wish we could just do that, but since we need to rely on having good documentation for consumers and developers I don't think we can use this pattern and instead have to just type everything out. i'm not saying the documentation needs to be extremely explicit even it just needs to be able to display all the props.
same comment as above regarding ActionBarItem.js on line 73

just for the sake of record keeping- can you point to where the designer has signed off on the design implementation?

@lee-chase still going through with a fine tooth comb, but i've mentioned some initial comments and thoughts.

For the record https://github.com/carbon-design-system/ibm-cloud-cognitive/issues/59#issuecomment-861013992
and https://github.com/carbon-design-system/ibm-cloud-cognitive/issues/897#issuecomment-861013562

@davidmenendez points addressed in #967
With regards to your points on PropTypes. I have added some additional commentary to ActionBar.js but persist with using Button.propTypes. This is because we specifically want to only highlight the props important to ActionBarItem, but support most Button props. This has previously been discussed at scrum and we felt that declaring all 24 Button propTypes would not be helpful to our end users obscuring the main usecase.
We can discuss again at scrum if you feel this interpretation of our discussion is incorrect.

@lee-chase went back over the code and everything looks good to me. i think all that's left is to add a sandbox

No code sandbox @davidmenendez this is an internal part of the page header.


The DXA logging implementation does not log the class name of the original caller

When configuring the Log4Net logging to log the type ("Used to output the fully qualified type name of the caller issuing the logging request."), DXA logs all log lines like if they are logged by Sdl.Web.Common.Logging.Log4NetLogger.
For example:
Log4Net config: <conversionPattern value="%date [%thread] %-5level %type - %message%newline" />
Output: 2017-02-02 10:13:59,214 [9] DEBUG Sdl.Web.Common.Logging.Log4NetLogger - Binary with URL '/version.json' is still up to date, no action required
I guess this is caused by the DXA logging implementation not forwarding the the class name of the original caller.

If you're using Unity 5.11.* you can use https://github.com/unitycontainer/log4net.
I had some success with this on a recent project for this exact reason and with this extension I was able to isolate separate log files based on namespace hierarchy as you would expect to in log4net.
Just make sure you're not resolving ILog anywhere as this was an initial issue for me.
If I get a chance I'll try and add it and create a PR.


refactor: update embedding dimensions to 1536, add postgres index, and add database migration script

Please describe the purpose of this pull request.
Change the embedding dimensions to 1536 for all vector columns per https://github.com/cpacker/MemGPT/issues/1028. This allows the creation of an index on these columns in postgres.
How to test
Run the database migration scripts against an existing environment.
Have you tested this PR?
Yes. I tested locally be creating a postgres instance with all embedding dimensions of 4096. I then updated the dimensions to 1536 locally, ran the database migration scripts, and confirmed I could continue interacting with the existing agents.
Related issues or PRs
https://github.com/cpacker/MemGPT/issues/975
https://github.com/cpacker/MemGPT/issues/1028

Could you please fix the formatting with poetry run black . -l 140?

Could you please fix the formatting with poetry run black . -l 140?

Done - looks like that code formatter check is passing now.


feat: integration testing for postgres dialect

Changes LGTM (with a couple of nits)
This will add a lot of additional integration tests, which means that the build time will increase. Is there any indication on how much?

Haven't looked into that but for golang we are skipping backup tests. What do you think?

Changes LGTM (with a couple of nits)
This will add a lot of additional integration tests, which means that the build time will increase. Is there any indication on how much?

Haven't looked into that but for golang we are skipping backup tests. What do you think?

I think that it would be good to skip backup tests for PostgreSQL. I don't think they add enough value to justify the additional build time (the last successful build with all the tests in this PR was 52 minutes, I think)


Using INITDB_ROOT_USER/PWD with --config option fails to restart

When using both MONGO_INITDB_ROOT_USER and MONGO_INITDB_ROOT_PASSWORD with --config on the command line means a docker restart causes the entrypoint script to attempt to re-create the root user and fails to start.
Workaround:  Ensure there is a storage.dbPath set in the config file.
Issue is around:
if [ -n "$shouldPerformInitdb" ]; then
    dbPath="$(_dbPath "$@")"
for path in \

where _dbPath evaluates as null due to:
if ! dbPath="$(_mongod_hack_get_arg_val --dbpath "$@")"; then
	if _parse_config "$@"; then
		dbPath="$(jq -r '.storage.dbPath' "$jsonConfigFile")"
	fi
fi

The jq expects the storage.dbPath to be set but returns "null" if it isn't present

I used something like:
docker run -d -e MONGO_INITDB_ROOT_USER=fred -e MONGO_INIT_DB_ROOT_PASSWORD mongo:4.0 --config /etc/mongo/someconfig.conf
Where the someconfig.conf did not contain storage.dbPath
What I see happening (I debugged the script so I have seen the issue) is that the jq command returns the string "null" not a null value.  Therefore the dpPath in the first snippet above is literal "null".


RFC: Allow coercing non-capturing closures to function pointers.

Rendered
Closes #1555.

This is my first RFC — should I modify 0401-coercions as well?

I much prefer the version that doesn't introduce any new syntax.
How would this interact with the existing closure types? Would the following code compile?
fn main() {
    let x = |var: &mut u32| {};
    foo(&x);
    bar(x);
}

fn foo(_: &Fn(&mut u32)) {}

fn bar(_: fn(&mut u32)) {}

I suppose what this is asking is, is the type of x actually a function pointer that just so happens to be using the closure syntax, or is it a closure that just so happens to be coercible to a function pointer? If it's the former, then should we expect to have to use the following syntax, in the same way that trait objects do today?
fn main() {
    let x: fn(&mut u32) = |var| {};
    // alternatively:
    let x = |var| {} as fn(&mut u32);
    bar(x);
}

fn bar(_: fn(&mut u32)) {}

Whether a closure's actual type becomes fn when it does not capture can theoretically be an implementation detail, because fn already satisfies the Fn trait anyway. This is, of course, barring the programmer taking any unsafe liberties with the structure of a closure object.
For example, this will compile and run fine:
fn foobar(_: &mut u32) {}

fn main() {
    let x = foobar;
    foo(&x);
    bar(x);
}

fn foo(_: &Fn(&mut u32)) {}

fn bar(_: fn(&mut u32)) {}

Strictly according to the RFP, though, the variable would be a closure that later coerces to a function pointer, which is probably for the better to prevent any breakage of silly unsafe code.

the variable would be a closure that later coerces to a function pointer

Does the type system need some way to distinguish between normal closures and "bare" closures? Can we achieve all this without runtime checks?

Yes, ideally the type system would keep track of closures that do not capture their environment.
Runtime checking is not a solution at all, in my opinion, nor is it necessary.

Am I right in that there would be no semantic difference between the existing fn type and a hypothetical "bare closure" type? If that's the case then it seems like the simplest route would just be to have Rust automatically assign zero-size closures a fn type (I had forgotten that fn satisfies Fn). But you say that this might be a problem for unsafe code, can you give an example of what sort of unsafe code you're worried would break under this scheme?

After a quick check of rustc source, you're right. There really isn't any way to transmute a non-capturing closure (TIL it's zero-sized!), so no unsafe code could be broken by this.
In that case, there wouldn't be any downside after all to simply using a fn type for such "trivial" closures.

I remember I used to talk about this with cc @P1start over a year ago; I think @eddyb too, perhaps regarding bounds-targetting coercions? I don't remember.
It'd be nice to have in some form. I also would prefer it to be automatic if possible.

This can all be done very easily at the type level: allow coercions from closures with no captures (a fact which is recorded in their very type)[https://github.com/rust-lang/rust/blob/1f131fbe7799b9c3d4a775798b90760f7c11ef33/src/librustc/ty/sty.rs#L245-L248).
The coercion you want is called a "reification" coercion and it's what turns functions into fn pointers today (you can treat non-closure fns as closures with no captures if you want to).
As for trans, well, the fn pointer is just <typeof(closure) as FnOnce<_>>::call_once (as zero-sized arguments are always ignored now), so that's a small bit of plumbing.

FWIW I wouldn't mind having fn literals - independently of the fate of this RFC. Yeah it's niche and "more syntax", but the fn type not having a literal form is kind of a hole anyways.

@glaebhoerl FWIW there are no more items with fn types - they can only be produced by reification, which is what this PR would allow for closure expressions too.

It could be useful to specialize for non-capturing closures (together with usual fns) when talking to APIs that don't understand thick pointers. Simply making || {} coercible to fn() doesn't seem sufficient though, there needs to be a way to bound on this.
trait IntoRaw {
    /// converts into a thin pointer
    fn into_raw(self) -> *mut c_void;
}

impl<F: Fn()> IntoRaw for F {
    default fn into_raw(self) -> *mut c_void {
        // box twice to get a thin pointer
        let b: Box<Box<Fn()>> = Box::new(Box::new(self));
        Box::into_raw(b) as *mut _
    }
}

impl<F: Fn() + Coercible> IntoRaw for F {
    fn into_raw(self) -> *mut c_void {
        // even a closure's code is static right?
        self as fn() as *mut _
    }
}

This RFC is hasn't seen much activity in a long time, so it'd be good to get it resolved. I'm mildly in favor of merging, but I have concerns that are enough that I haven't asked rfcbot to fcp it. Here are my thoughts.
Breaking changes
My biggest concern is that this could make adding a captured variable to a closure a breaking change in a library; it would be very unfortunate for users to have to determine if subtle changes like that could break a downstream crate, rather than just always knowing that they're fine. To me, if this were the case, this RFC would be a no go.
Fortunately, I can't think of a way to expose a closure to clients except through the impl Fn mechanism. It seems obvious to me that an impl Fn should not coerce to an fn, even if the type it secretly is could coerce, but this should be made explicit in the RFC.
If there are no ways to expose values of the anonymous type to clients, then this should be fine. But I want to make sure we've thought about this.
Accidental guarantees
A more subtle concern is one in which the user accidentally guarantees this coercion, and then later is forced to break their API to perform the upgrade they intended.
This basically introduces two ways to return closures, one of which is strictly more general than the other:
fn incr() -> fn(i32) -> i32 {
    |x| x + 1
}

fn incr() -> impl Fn(i32) -> i32 {
    |x| x + 1
}

My concern is that the first of these is more natural to write than the second. Users could write functions which return fn types, not realizing that they are declaring in their API that the function they return captures no variable from the environment.
This seems a pretty serious trade off to me - we want the language to just enable you to do the right thing. The current behavior is unergonomic and confounding, but I'm not 100% sure that the footguns this behavior would introduce are less of a problem.

@wycats So have fn literals instead? :grin:

@glaebhoerl assuming that @ was at me :wink:, I think the downsides of a new lambda syntax are greater than the downsides of the current behavior or the RFC.

Oh, sorry! And I made the opposite mistake just a couple of hours ago... (but thankfully twitter does the reply-tos automatically;)

Fortunately, I can't think of a way to expose a closure to clients except through the impl Fn mechanism. It seems obvious to me that an impl Fn should not coerce to an fn, even if the type it secretly is could coerce, but this should be made explicit in the RFC.

impl Fn types are hidden just as much as generic type parameters.

@withoutboats

It seems obvious to me that an impl Fn should not coerce to an fn, even if the type it secretly is could coerce, but this should be made explicit in the RFC.

For what it's worth, I agree, and I can add a comment to the RFC making that explicitly clear.

A more subtle concern is one in which the user accidentally guarantees this coercion, and then later is forced to break their API to perform the upgrade they intended.

I agree that this could happen, and I'll add this to the drawbacks section of the RFC, but we do already have situations in which a Rust programmer might take the "easy route" and accidentally constrain their own API.
For a contrived example, this is an easy mistake to make with mut. (Again, please note that this is a very contrived example.) I do think that to some extent, we expect a Rust programmer to be aware of the limitations they create for themselves.
In this case we're talking about a much more niche feature than mut, of course, but I think the benefits to code clarity and brevity outweigh some accidental misuse.

@rfcbot fcp close
We discussed this at the lang meeting this week. We considered both the coercion option the RFC proposed and the alternative function literal syntax, as well as allowing only explicit as casts of closures into fn types, but ultimately we felt that there was not strong enough motivation to adopt any of these.
In general, folks felt most favorably about the function syntax (though speaking personally I think I'm more against it than other people were), but there were concerns about how it would work. If the function syntax infers your arguments (including the return type), it behaves significantly differently from function declarations. If it doesn't, it doesn't save you much in comparison to writing out a literal function.
No one loves the current situation, but we felt that the language as it exists right now does not strongly encourage you to use fn pointers, so its not clear how often some new syntax or coercion would actually be used for its intended purpose.

If the function syntax infers your types (especially the return type), it behaves significantly differently from named function declarations. If it doesn't, it doesn't save you much in comparison to writing out a named function.

I've been thinking about allowing inference for function-local items (Or at least fns, consts, and statics).
Since inference is done locally to a function, and these items are constrained to the function body they are located in, I see no obvious reason not to allow this. This could make a lot of local code-reuse situations a lot more convenient. (At times I've been using local macros instead of local fns, just so I can avoid having to type out the type signatures).
Of course this would require its own RFC. My point is, this could make the function literal alternative more appealing.

If the function syntax infers your types (especially the return type), it behaves significantly differently from named function declarations.

I assume it would just infer everything the same way as closure syntax does, apart from not allowing captures. Is there anything wrong with that? That doesn't sound too surprising to me; in fact it's exactly what I would expect. My sense is that inference for fn items is a separate issue. In my mind, the reason why fn items require explicit types is because "global items require type annotations" (see also: const, static) rather than "fn types require type annotations".
Meta-level: What are the conditions under which this issue would be revisited? It doesn't seem like there's much scope for new information coming to light or different solutions being thought of. Do issues which aren't annoying enough just stay unresolved indefinitely? That sounds like it could lead to "death by a thousand cuts".
(N.B. I don't care that much about the feature itself here. More about the reasoning.)

Assuming the following were meant as replies for my comment:

My sense is that inference for fn items is a separate issue.

I do indeed state that this would require its own RFC. I just wanted to promote the idea that this would make inference for a function literal syntax less out of place.

In my mind, the reason why fn items require explicit types is because "global items require type annotations" (see also: const, static) rather than "fns require type annotations".

Right. To emphasize, my idea is to allow type inference for items local to the function body, as opposed to being global items.
I do not mean to derail this thread, I just want to clarify myself.

It was more in response to @withoutboats (and by extension the lang team) who originally raised the inference issue.

I just wanted to promote the idea that this would make inference for a function literal syntax less out of place.

I think it wouldn't have any impact on how out of place it would or wouldn't be because the two features are unrelated :o)

To emphasize, my idea is to allow type inference for items local to the function body, as opposed to being global items.

Right, no misunderstanding there. I think inference for local and/or private items is a potentially reasonable idea, but is logically related to (doing likewise for) const and static items, and not to fn literals in expressions.

I think it wouldn't have any impact on how out of place it would or wouldn't be because the two features are unrelated :o)

The counter-argument(?) against allowing inference I replied to was "If the function syntax infers your types (especially the return type), it behaves significantly differently from named function declarations."
If types were inferred for named functions inside fn bodies, it wouldn't behave differently from them.
And as far as I'm aware, both features could only appear inside fn bodies, so they would be consistent with one another.

I understand that. I disagree with the assumption that they need to be consistent with one another.
To make it really really clear:
@withoutboats and lang team: "The problem is froop."
You: "We can solve froop with brazzle."
Me: "I don't think froop is a problem."

@glaebhoerl

I assume it would just infer everything the same way as closure syntax does, apart from not allowing captures. Is there anything wrong with that?

There's no problem in making it work; it's more a question of consistency/understandability.
With closures, we have very distinct expression and "type" forms (the latter using the Fn* traits). It's well understood that closure syntax involves a fair amount of machinery and inference, but one could never confuse it for a type signature.
OTOH, if we use a syntax like fn(x) { x + 1 } for function literals, it's much closer to the type form, but performs inference. That's potentially confusing -- though, in my opinion, not by itself the problem.
As @withoutboats mentioned, the place this really becomes a concern is with return types, when you start mixing in type information. The closure syntax allows you to optionally specify types for arguments and the return value. Consider:
|x: bool| !x

Even though we've annotated the argument type, because we didn't write a ->, the return type is still inferred (as bool). Consider the same with fn syntax:
fn(x: bool) { !x }

That looks dangerously close to a standalone fn definition, where the return type would be understood as (). That's the key issue.
Is this concern an absolute blocker for the feature? Probably not. But it means that the literal syntax is not a slam dunk, and when combined with the somewhat narrow motivation for the feature in the first place, it didn't seem worthwhile to pursue the addition at this time.

What are the conditions under which this issue would be revisited? It doesn't seem like there's much scope for new information coming to light or different solutions being thought of. Do issues which aren't annoying enough just stay unresolved indefinitely? That sounds like it could lead to "death by a thousand cuts".

IMO, the main thing that's likely to bring this issue to the fore is more evidence that the lack of such notation is painful. I understand the point about papercuts, but OTOH language additions are not free -- there's also the danger of reaching enormous complexity by a thousand small additions.
These considerations are never cut and dried, and we shouldn't expect them to be. But at the moment, given the somewhat fiddly problems with the design, and the lack of widespread pain here, we're leaning toward the "not now" angle.

Thanks. That does sound like a legitimate issue. (Which could be finessed in various imperfect ways, which you've no doubt also thought of, such as requiring the return type to be present if the argument types are, or maybe just linting it.)

OTOH language additions are not free -- there's also the danger of reaching enormous complexity by a thousand small additions

Indeed. For what it's worth, the (hand-wavy!) way I tend to think about this is that there's a big, imaginary matrix with a row and a column for every "language feature" (in some loose sense), and in each cell at the intersection of a row and a column, the interaction of those two features. In this metaphor, an empty cell means something "should be there" but isn't, and "filling in holes" is a good thing, as it is cleaning up irregularities in the language. On the other hand, adding new rows and columns is bad -- it's a completely new, separate feature for every other feature to potentially interact with. (I think I've heard team members refer to this as "multiplicative complexity".) I guess the common thread here is to minimize the (conceptual) descriptive complexity of the language, which both "negative" special cases (omissions) and "positive" features contribute to.
In case you haven't guessed, I feel like the fact that fn types lack a literal form is one of those negative special cases.
(Again: this is not to be taken as me pushing to have the decision changed - I feel like my questions have been answered - just explaining my reasoning.)

I guess the common thread here is to minimize the (conceptual) descriptive complexity of the language, which both "negative" special cases (omissions) and "positive" features contribute to.

Yes, I'm deeply sympathetic to this point of view. If the literal syntax was a more straightforward addition, I'd be more in favor of it for precisely this kind of reason (in conjunction with the fact that it is occasionally useful).

I understand the point about papercuts, but OTOH language additions are not free -- there's also the danger of reaching enormous complexity by a thousand small additions.

Very true, and part of the reason that C++ has become such a monstrosity over time. I figured a feature like this would simply complement the "zero-cost abstraction" focus in Rust.

I'm not 100% sure that the footguns this behavior would introduce are less of a problem.

The history of the evolution of closures in Rust has been that worries have tended to be overblown. I think that if somebody wants to implement the feature, it should be implemented and then we can experiment with it to see if these worries are really valid.

the language as it exists right now does not strongly encourage you to use fn pointers

Rust does encourage one to use function pointers if one wants to avoid unnecessary code bloat due to monomorphization, and/or one otherwise wants to avoid forcing callers that forward function pointers to be parameterized. This is why I use function pointers heavily and avoid using closures when practical.

If the function syntax infers your types (especially the return type), it behaves significantly differently from named function declarations. If it doesn't, it doesn't save you much in comparison to writing out a named function.

Regardless of whether the closure syntax is used or a function literal syntax is used, the feature does offer useful benefits:

The definition of the function can be inline instead of out-of-line.
When using macros or other code generation, there's no need to generate a dummy or confusing name for a function that wouldn't otherwise need a name.
The syntax makes it clear that the function is only called through the function pointer, and never called directly by name, since it has no name.

There's no problem in making it work; it's more a question of consistency/understandability.

When learning Rust, I found it difficult to understand why a closure anything can't be used where a function pointer is needed.
Regarding the complexity arguments, I feel that, while adding implicit coercion from non-capturing lambda expressions to function pointers technically adds complexity to the implementation, it simplifies the language conceptually. Conceptually, now we can't pass a closure where a function pointer is expected only because the closure might have captured something. But, it's obvious that a closure that doesn't capture anything...doesn't capture anything, so there's no conceptual basis for the limitation in that case.
So, all in all, I think it would be a worthwhile improvement to have non-capturing closures be coercible to function pointers and usable in every context where a function name could be used to reference a named function.

I'd like to give an irc conversation from #rust-beginners as evidence for why this should be merged:
sadiq | quick question
sadiq | why does https://play.rust-lang.org/?gist=f42be222188cd1e160a777de64d7c4df&version=nightly&backtrace=0 not compile?
sadiq | but https://play.rust-lang.org/?gist=2f32e5953b7a1cf1ed4cea20030f024c&version=nightly&backtrace=0 does?
sadiq | (as in, why is that closure not Copy?)
ubsandroid | sadiq: because closures can't be clone
ubsandroid | and we didn't want even more ices
sadiq | ubsandroid, oh, I see.
ubsandroid | sadiq: basically, lack of good generics
sadiq | kinda weird that functions are Clone though?
ubsandroid | sadiq: I don't think they are?
sadiq | well, that second playground compiles
ubsandroid | might be up to 8 that are
ubsandroid | or fifteen
sadiq | and there's Copy on the bounds
ubsandroid | playbot: fn foo(_: (), _: (), _: (),_: (), _: (), _: (),_: (), _: (), _: (),_: (), _: (), _: (),_: (), _: (), _: (), _: ()) {} fn check_clone<T: Clone>(_: &T) {} check_clone(&foo)
-playbot- | error[E0277]: the trait bound `fn((), (), (), (), (), (), (), (), (), (), (), (), (), (), (), ()) {main::foo}: std::clone::Clone` is not satisfied
ubsandroid | sadiq: ^
sadiq | ubsandroid, so up to 15 parameters are?
ubsandroid | sadiq: or 8, don't remember and also on my phone

sadiq | guess I'm just not sure what the difference is between the function and closure playgrounds from ^ were, given the closure didn't capture anything from it's environment.
ubsandroid | sadiq: because functions and closures not capturing anything are different, for now

Basically, there is confusion leading from the fact that closures that don't capture anything are different from function literals, and that Clone/Copy are not implemented for closures.

I've been hearing about this a lot on IRC lately; people do get weirded out by the fact that there's no anonymous lambda syntax:
bollu  | so rust has closures, but not "pure lambda" syntax?
ubsan  | bollu: no, but there's an RFC for something like that
Xion   | You mean closures without the closure part?
Ms2ger | What would a "pure lambda" syntax be?
ubsan  | until then, you can write let x = {fn tmp(...) { ... } tmp};
Xion   | I.e. without any environment.
bollu  | Xion: yes
ubsan  |Ms2ger: I assume closure syntax without captures
Ms2ger | So, a function?
bollu  | Xion: just an annonymous function
bollu  | Ms2ger: "annonymous" is what I
bollu  | I am interested in :)

So, I'd like to editorialize, from my experiences with people, talking on IRC.

This is a feature that can pretty easily be worked around, in a fairly ugly way.

People want to use the pretty syntax for non-capturing closures, and it's weird for them that they can't.

It's unlikely to, in practice, cause breaking changes when someone returns a fn() and needs to return an impl Fn(): the beginners likely to make this mistake will mostly be writing binaries or single-user libraries, and by the time a crate gets used enough for it to matter, whether a closure closes over anything is likely to be solved.

It's a simple feature to implement, and it fixes something that's missing in the language which confuses people.

@ubsan Thanks very much for the input from people learning the language; that's extremely valuable!
Just to clarify: while some of the discussion is about anonymous function syntax, this RFC proposes that the existing closure syntax do double-duty as anonymous function syntax as well. That's different from other primitive types, which have dedicated literal syntaxes; one might expect a literal anonymous fn syntax (though there are some problems with that).
Can you say a bit more about how you see the tradeoffs around that syntactic choice and the learnability issues?

I'd like to know more about the ways people are using fn pointers right now. Are these situations that we'd say they should be using impl Fn if it were stable, or something where impl Fn is unsatisfactory?

@aturon I don't feel that there is a significant learnability issue with either; this is not something that's hard to grasp, either with dedicated syntax, or with reusing closure syntax. However, adding new syntax means discoverability issues; it's not a big deal though.
@withoutboats Generally (nits about small sample size aside), people seem to not be returning closures or functions, at least to me. sadiq was interested in something they could copy, i.e., pass to a function that takes T: FnOnce and continue to use; bollu was interested in why that syntax doesn't exist, more than any real problem. I am more saying that the overload of the syntax is not confusing to people, and it's at least less confusing than `{ fn tmp

Since fn() coerces to Fn(), it's surprising it doesn't go in the opposite direction when nothing's captured.
fn use_closure<F>(closure: F) where F: Fn(char) -> bool {
    println!("{}", closure('a'));
}

fn main() {
    use_closure(char::is_uppercase);
}

https://play.rust-lang.org/?gist=dbe0707259def829c778ee9ba9526ea1&version=stable&backtrace=0

In re-reading this thread, I realized that the earlier summary of the lang team discussion was missing some important bits. To try to recap:
You can imagine essentially two ways of solving the problem this RFC is trying to solve. Either creating a dedicated fn-literal syntax, or somehow re-using the closure syntax.

A dedicated fn-literal syntax is more consistent with other primitive types, which are equipped with their own literal syntax, but has problems with type signatures. These may be surmountable problems, but would need some design work.

Allowing closure syntax to create/coerce to fn types, OTOH, suffers from the problems that affect coercions in general: they don't always work and can be a bit fiddly. Common examples include calling generic functions, where the arguments would work if a coercion fired, but the fact that the receiving type is generic means the coercions don't fire.

In thinking about this again, I'm not sure how much the finickiness of coercions would matter; I think it'd be pretty unusual to need a coercion to fn to fire in a generic context. It'd be helpful to try to think through some realistic examples where this falls down.
There was another, more vague concern, which is that it's somewhat odd to have a primitive type like fn that doesn't have its own literal syntax, but for which we have some other special syntax which happens to coerce into that type. A dedicated literal syntax feels more clean and consistent (but suffers from the problem mentioned above). But it's hard to know how much this "inconsistency" would matter in practice, for learnability.

I agree, @aturon, with the sentiment that a dedicated fn syntax feels more principled, but in practice has flaws, and I'm not sure how much it will matter. As long as this coercion is limited to using the expected type, this change feels fairly harmless. It's ultimately a kind of niche thing, and the explicit syntax of making a named fn and referencing that name isn't so bad.

@aturon
Function pointer types don't really have a literal syntax at all. Function literals create fn items, which you have to coerce to a function pointer anyway.
In any case a closure is quite like an fn item, and therefore should be similarly coercible to an fn pointer.

@arielb1 Yes, I take your point. The fn type is a sort of weird hybrid: it looks like a primitive type, but it works a bit more like a trait object.
So in particular, if we had an anonymous fn syntax, it'd be a bit of a lie, since it would actually work more like closures under the hood (adding an anonymous fn item that can be coerced to the fn type). That's a pretty decent argument that closure syntax is in fact a good fit.

That's a pretty decent argument that closure syntax is in fact a good fit.

Agreed.

I think that would be a compelling argument if we had actually gone the route of making fns look like trait objects, by making them unsized types and having &'static fn in place of the current fn, and so on, as some RFC proposed to do at the time. I don't think it's as compelling in Rust-as-it-is, where fn is a primitive function pointer type (and fn items are weird as stated, but that's kind of neither here nor there to me).

since it would actually work more like closures under the hood (adding an anonymous fn item that can be coerced to the fn type)

Would it work that way? I mean, the choice is up to us.

@glaebhoerl https://github.com/rust-lang/rfcs/issues/1037 I want to resurrect that at some point---one of those is my RFC if you remember :).

@glaebhoerl

Would it work that way?

I want to make sure we're not talking past each other, so let me be concrete. Today, fn items implicitly declare a unique type which implements the closure traits, but which can be coerced to the fn type. This allow for both static and dynamic dispatch:
fn static_dispatch<F: FnOnce()>(f: F) { f() }
fn dynamic_dispatch(f: fn()) { f() }

fn myfn() {}

fn main() {
    static_dispatch(myfn);
    dynamic_dispatch(myfn);
}

and note that the static dispatch relies in an essential way on the fn item producing a unique type -- exactly the same as with closures.
What I'm saying is that if we added an anonymous fn literal syntax, I would expect it to work the same way:
fn static_dispatch<F: FnOnce()>(f: F) { f() }
fn dynamic_dispatch(f: fn()) { f() }

fn main() {
    let myfn = fn() {};
    static_dispatch(myfn);
    dynamic_dispatch(myfn);
}

Getting the same behavior here requires the fn() {} definition to create a fresh type, so that we can statically dispatch. While we wouldn't have to reproduce that behavior, it would be a very odd choice not to!
My follow-up point was that, for anonymous fn() {} syntax to work this way, it would behave in most respects identically to closures; they would produce values of some anonymous type, not of type fn as the syntax would suggest. The only difference being that the resulting object can coerce to the fn type.
At that point, I've convinced myself that the RFC as written is the best option: just allow closures to coerce directly.

Yeah, I understand all that completely. Thanks for making sure though!

While we wouldn't have to reproduce that behavior, it would be a very odd choice not to!

This is the assumption I don't have in common. Since fn() types are the type of function pointers, it's completely natural to me that fn() literals would be function pointers. And fn items are special. Which they are in other ways besides, I believe. Shrug.
It's not like the closure-coercion approach doesn't have advantages. It avoids adding a new syntactic form for people to encounter and to have to learn about, and it'll be more familiar for people coming from C++. I think those are the major points, and what we're discussing right now is small potatoes down in the weeds, relatively speaking.

@withoutboats Given the post-FCP discussion, I think we should take the RFC back out of FCP to close and reconsider it. Can you cancel the FCP?

@aturon
Out of curiosity:
fn static_dispatch<F: FnOnce()>(f: F) { f() }

fn main() {
    fn foo() {};
    let myfn = foo;
    static_dispatch(myfn);
}

Is this actually static? Or would this be function -> function pointer which impls closure trait?

Also, did anyone bring up capture lists yet? If we had (optional) explicit capture lists, then we could only allow closures with an explicit empty capture list to convert to function pointers. This makes sure that people really opt-in to what's going on.

Since fn() types are the type of function pointers, it's completely natural to me that fn() literals would be function pointers.

Let me elaborate. I suspect the reason it feels like "it would be a very odd choice" to do this is due to the intuition that dynamic dispatch in Rust is always opt-in. Wherever possible, Rust tries to dispatch calls statically, and to steer users in that direction as well. So, this is a heuristic. And as far as heuristics go, it's quite a strong one!
But I don't think it leads to an accurate conclusion in this particular case. The use case for fn() literals is to conveniently define a function in-place where a value of fn() type is expected. Now, the worry might be that if fn() literals are always actually function pointers, we might inadvertently lose out on opportunities for static dispatch in statically monomorphized contexts -- fn higher_order<F: Fn()>(f: F), and the like. But: there is no actual motivation to use an fn() literal in such a context! The normal || literals work perfectly.
The situation where this would actually matter is if it were also possible to use fn() types as trait bounds -- that is, something like fn higher_order<F: fn()>(f: F). In that case, the || literal wouldn't work, and the fn() literal would leave performance on the table. But that situation doesn't exist! (And I don't believe it would offer any benefits over F: Fn() if it did.) The only actually-existing situation where fn() literals are relevant is when you want to create a value of an actual, honest-to-God fn() pointer type, and in that situation, the fact that an fn() literal is in fact a function pointer could not be any less surprising. Having fn() literals be anonymous types which need an intervening coercion to turn into fn() pointers would be a semantic pessimization here, by impairing type inference.

Put another way, fn items (statically-dispatched values of anonymous zero-sized types) and fn types (dynamically-dispatched values of a concrete non-zero-sized type) are inconsistent with each other already, in the language as it is, and there is no reason a priori why we should have to choose for fn literals to be consistent with the former rather than with the latter.

@glaebhoerl

Put another way, fn items (statically-dispatched values of anonymous zero-sized types) and fn types (dynamically-dispatched values of a concrete non-zero-sized type) are inconsistent with each other already, in the language as it is, and there is no reason a priori why we should have to choose for fn literals to be consistent with the former rather than with the latter.

While I agree, I think it would be the wrong choice for fn literals to be consistent with the types and not the items. Here are some reasons:

Suppose there is an API that is written (today) to take a fn(...) but later generalized to take closures. If I am calling it like foo.(fn() { ... }), then I would now have less efficient behavior.

The same benefit is true if we use the || form, of course, and it avoids the discomfort around the return type.

To me, there is actually a greater affinity between the item and expression form than between the expression form and the type. It's kind of hard for me to say just why that is -- I guess because having a named and anonymous for that act the same way seems to make sense.

Anyway, I'm pretty convinced by now. I am in favor of this RFC as originally written. Moreover, I could imagine that sometime later we might consider generalizing this to say that "any zero-sized type that implements Fn can be converted into a fn pointer", but I think that doing that would require us to reify some form of predicate for "zero-sized" (so that you can e.g. write a fn like fn foo<T: ZeroSized + Fn()>(t: T) -> fn() { t }).

Moreover, I could imagine that sometime later we might consider generalizing this to say that "any zero-sized type that implements Fn can be converted into a fn pointer"

That's a nice idea.
@archshift, it'd be great if the RFC could be updated to take into account some of this recent discussion, as well as logging some of the downsides we've found with fn literal syntax.

@rfcbot fcp cancel
I hate to say I'm still inclined against this RFC though. I don't feel like function literals are a missing syntax; I feel like closures are our function literals. I am more of a fan of the coercion, but I am concerned about the ability to get yourself into a bind with it where you need to add some environment to your function and you can't.

@withoutboats

I am concerned about the ability to get yourself into a bind with it where you need to add some environment to your function and you can't.

Hmm, it seems like this is fundamentally a judgement call. There are definitely legitimate cases where you actively want a function pointer and not a closure (e.g., interfacing with C code, as well as wanting to guarantee that there is no environment, though that latter case could be achieved by adding some kind of "zero-sized" trait). But making those cases more ergonomic comes at the cost of making it easier to write the wrong thing in your public APIs.
I have to admit I am not so worried about that. I think beginners probably will make mistakes, but as they learn rust, they will learn the better fix, and their APIs will improve and be updated. It seems likely that many early APIs also make dubious choices about whether to take ownership of something or to borrow it, and so forth, as well.

@nikomatsakis I agree. I'd also note that fn as a type is not something that people get exposed to early on in learning Rust, so I'm not sure how much temptation there would be to use it in APIs before one understands the implications.
I'm going to go ahead and move toward acceptance of this RFC, given recent discussion, but of course @withoutboats and others should feel free to raise concerns.
@rfcbot fcp merge

@withoutboats
Regarding accidentally trapping oneself API-wise, I believe distinguishing between a fn() and a closure is akin to distinguishing between Fn/FnMut/FnOnce. (The traits, I believe, are much easier to misuse as well.)
As long as we sufficiently emphasize the fact that function pointers are completely self-contained, I don't anticipate this to be a problem.

Ping @nrc @pnkfelix @withoutboats

I've marked this reviewed to merge. I think my biggest concern has to do with stabilizing this before impl Trait - people might start moving to fn pointers because they don't want to use Box<Fn>.

I have marked this reviewed to merge, but I have to admit that I was confused when re-reading the Summary sentence:

A non-capturing (that is, does not Clone or move any local variables) closure
should be coercable to a function pointer (fn).

What's up with that definition of "non-capturing"? I would have thought the definition would be broader, to include referencing local variables (even without moving nor cloning them).
(And I'm pretty sure that that broader definition of "non-capturing" must be what everyone else is using, because the only way the proposal makes sense is for the generated code to not have any dynamic environment that it needs to access...)

Yeah, "capture by reference" is pretty standard at this point, the parenthesis is the confusing bit there IMO.

Ah, that was an oversight. I'll fix the summary.

The final comment period has elapsed without any additional commentary, so at this point we're pretty much ready to merge the RFC.
However, I noticed that @nikomatsakis has an outstanding review request and I want to make sure he feels the issue has been resolved at this point.

@aturon @eddyb

However, I noticed that @nikomatsakis has an outstanding review request and I want to make sure he feels the issue has been resolved at this point.

Ah, hmm, yes I forgot about that. So my concern was that I would expect this coercion (from closure to fn ptr) to be driven by the top-down coercion process. I wrote this:

My expectation is that it uses the 'expected type' -- meaning that it's a kind of coercion. Basically, when we type-check a closure expression, if the expected type is a fn(), we will coerce to a fn pointer, but otherwise we will not. This implies the usual limitations that come along with coercions (at least today). These are somewhat stronger than what you mention. For example, once a closure is assigned to a variable, it will no longer be possible to coerce it to a fn() pointer.

And @aturon replied:

Is that stronger limitation fundamental? It seems to me that we could introduce a marker trait, or some other way of knowing that a particular struct is coercible to a fn pointer.

Then @eddyb wrote:
@eddyb also wrote:

That... limitation strikes me as false. What is the difference between the type of || ... and the type of x? The coercion goes from TyClosure to TyFnPtr, doesn't it?

I suppose that thinking about it more there is another alternative. We could consider this a variant of upvar inference (the thing that decides, based on how it uses its upvars, when a closure implements Fn, FnMut, or FnOnce). Basically if a local closure type (defined in this fn, which at the moment is always the case I think) is coerced to a fn ptr, then we add a constraint that it can have no upvars.
I'd be ok with that, I guess, though I'm not totally psyched about it, just because I feel like it's yet another ad-hoc bit of obligation tracking we'd be doing in the type-checker (rather than having it all consolidated into a new-and-improved trait system sort of thing). Just examining the expected type at the time when we create the closure feels way easier.
But yeah I can go either way I guess. It's fine.

then we add a constraint that it can have no upvars.

The set of "upvars" is already known before type-checking begins, so that shouldn't be a problem.

Per post-FCP discussion, this RFC has been merged!
Tracking issue

The "Rendered" link is broken

Accepted RFCs are available at https://rust-lang.github.io/rfcs/1558-closure-to-fn-coercion.html


Update Firefox versions for api.HTMLFieldSetElement.disabled

17379

 Quality gate: NA
Details

 Quality gate: NA
Details


Enhance METviewer database schema to comply with MET-10.1.0

Describe the New Feature
Add new columns to the line type tables based on MET-10.1.0 requirements:

For dtcenter/MET#1749, add HSS_EC and EC_VALUE to the MCTS line type.
For dtcenter/MET#1749, add EC_VALUE to the MCTC line type.

Acceptance Testing
List input data types and sources.
Describe tests required for new functionality.
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1 day of work.
Sub-Issues
Consider breaking the new feature down into sub-issues.

[ ] Add a checkbox for each sub-issue here.

Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Define the source of funding and account keys here or state NONE.
Define the Metadata
Assignee

[ ] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required

Labels

[ ] Select component(s)
[ ] Select priority
[ ] Select requestor(s)

Projects and Milestone

[ ] Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
[ ] Select Milestone as the next official version or Future Versions

Define Related Issue(s)
Consider the impact to the other METplus components.

[ ] METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy

New Feature Checklist
See the METplus Workflow for details.

[ ] Complete the issue definition above, including the Time Estimate and Funding source.
[ ] Fork this repository or create a branch of develop.
Branch name: feature_<Issue Number>_<Description>
[ ] Complete the development and test your changes.
[ ] Add/update log messages for easier debugging.
[ ] Add/update unit tests.
[ ] Add/update documentation.
[ ] Push local changes to GitHub.
[ ] Submit a pull request to merge into develop.
Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Linked issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
[ ] Iterate until the reviewer(s) accept and merge your changes.
[ ] Delete your fork or branch.
[ ] Close this issue.

Added hss_ec, hss_ec_bcl, hss_ec_bcu, and ec_value to line_data_mcts, and added ec_value to line_data_mctc. Made these fields doubles with a default of -9999. Done as feature_285_hss_ec. Merged into develop branch with Pull Request.


what's the difference between the original repo: langchain-chatglm and this one?

I see this repo has more stars than the original repo: https://github.com/chatchat-space/Langchain-Chatchat. What's the difference between them and which one should I first to try if I want to deploy a local version to chat with uploaded document?

You can prefer his from a maintenance point of view.


Adding OS installation script for BBB/MBM2

PR Overview:
There are now quite a few things which need to be stopped/done when installing a new version of KubOS into the eMMC of a BBB or MBM2. This PR adds an installation script which will take care of everything for the user.
Documentation:
TODO

 Create KLB eMMC installation script


Incorrect cospectrum

Problems
Function cospectrum had been modified here https://github.com/pyRiemann/pyRiemann/commit/9a6dbeef03f61c7658c8902923d0f22d84b57c1c#diff-b256f1ac840adebcb1b8bd17d18f050b62b1b6b7f9ef86331083bfbccd0d16d6
but the output is defined as the squared modulus of the cross-spectra, instead of the real part, as mentionned in #90.
Moreover, cospectrum(x, fmin=20) raises the TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'
at line https://github.com/pyRiemann/pyRiemann/commit/9a6dbeef03f61c7658c8902923d0f22d84b57c1c#diff-b256f1ac840adebcb1b8bd17d18f050b62b1b6b7f9ef86331083bfbccd0d16d6R136 : f = numpy.arange(0, 1, 1.0 / number_freqs) * (fs / 2.0), because fs is None.
Cross-spectra and co-spectra

Solution
PR in progress...

this is intended to be the squared modulus (cross-spectrum). it could be great to have the option to choose what you want if you make a PR.

If the output of the function is the (squared) modulus, the phase is definitively lost.
It is better to return the raw complex cross-spectrum, and then users can compute the feature they need: real part (for co-spectrum), imaginary part, modulus (useful for coherence) or phase.

yeah, phase is lost. its intented to be a "unnormalized" version of the coherence (i.e. what covariance is to correlation). I would say the best option is to add a parameter that allows you to switch between the different version (you could even throw in normalization to have coherence estimation). This way it won't break existing pipeline that expect non-complex outputs.

Closed by #118.


Can i convert in english language?

this is really awesome tool but not in english.
how can i take benefit ?
your main language in Chinese so please guide me if it's available in english.
Thanks

👌

see #11


Break out Transducers section from README

Write a dev.to article on it instead.

Moving to TRANSDUCERS.md for now


[W-038348] Refactoring Manage Household Robot tests to Page Object Pattern

Minor updates to Locators file and NPSP
Refactoring and organizing of the existing tests to use the page object pattern
Added required methods for the Managehousehold page object
Documentation
Critical Changes
Changes
Issues Closed
New Metadata
Deleted Metadata

@rjanjanam Looking at the changes listed in the PR comment, I think these are all infrastructure related vs. product related. If so, I'm not really sure they should be listed in the changes section of the PR comment since that is what customers will see in the product release notes. If you agree, would you mind moving your comments above the "Critical Changes" section in the PR comment?
cc @sam-knox

Agreed @force2b . Sorry I did not know. Removed and changed it as suggested.

No worries @rjanjanam. Thanks for updating.


design doc link update

Fixes: #38304
Updated link for design doc of csi

/kind documentation

lgtm
It works from a 404 page to an archived csi.

@kundan2707 : Thank you for your contribution! Please note that this blog is ~4 years old as of today. Per our policy neither do we maintain blogs (with a few notable exceptions) older than one year nor do we accept issues related to them.
Please ensure you read our [contributor guide(https://kubernetes.io/docs/contribute/) before submitting a PR.
/close


print statements are not appearing on console when -n is 1

Description of issue / feature request
locust -f ./local_file.py --no-web -c 5 -r 1 -n 1
In local_file.py, I have put few print statements which doesn't appear on console when -n 1 but for greater than 1 it comes.
Expected behavior
It should print statment on console.
Actual behavior
Its not printing statement on console.
TBD
Environment settings (for bug reports)

OS: Ubuntu 16.04.2 LTS
Python version: Python 2.7.11+
Locust version: Locust 0.8.1

Steps to reproduce (for bug reports)
TBD - example code appreciated

I have put few print statements which doesn't appear on console
when -n 1 but for greater than 1 it comes

Setting n or --num-requests sets the number of requests to send before stopping execution, so you are telling it to stop immediately after 1 request (possibly before all locusts are spawned).
FWIW, the --num-requests option has been removed in Locust 0.9 in favor of time based execution.

Looks like that is the issue

Could you please tell me how can i download 0.9 version as while doing pip install locustio, 0.8.1 version got installed

0,9 has not been release.  you can however install latest master branch with this change

Thank you

looks like running pip install git+https://github.com/locustio/locust.git@master does not install 0.9
Collecting git+https://github.com/locustio/locust.git@master
  Cloning https://github.com/locustio/locust.git (to revision master) to /private/var/folders/nj/txv_y8b52xx364vl_c4s5kdwp7bqdb/T/pip-req-build-jr7_98xy
Requirement already satisfied (use --upgrade to upgrade): locustio==0.8.1 from git+https://github.com/locustio/locust.git@master```

looks like running pip install git+https://github.com/locustio/locust.git@master does not install 0.9 but 0.8.1
Collecting git+https://github.com/locustio/locust.git@master
Cloning https://github.com/locustio/locust.git (to revision master) to /private/var/folders/nj/txv_y8b52xx364vl_c4s5kdwp7bqdb/T/pip-req-build-jr7_98xy
Requirement already satisfied (use --upgrade to upgrade): locustio==0.8.1 from git+https://github.com/locustio/locust.git@master```


jitsi meet not working using helm after joining two or more people

Title: Audio and Video Not Working for Third Participant in Jitsi Meet Deployment via Helm
Description:
We have deployed Jitsi Meet using Helm. All the necessary services like jitsi-web and jvb have been created with the necessary pods. We exposed the web service via Ingress and are able to create meetings for two participants without any issues. However, when a third participant joins the meeting, the audio and video stop working.
Below is the values.yml file we used for the deployment. Please advise if any changes need to be made to the values.yml to resolve this issue.
yaml
global:
clusterDomain: cluster.local
podLabels: {}
podAnnotations: {}
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

enableAuth: false
enableGuests: true
publicURL: "jitsiks.example.com"

tz: Asia/Kolkata

image:
pullPolicy: IfNotPresent

websockets:
colibri:
enabled: true
xmpp:
enabled: true

web:
replicaCount: 1
image:
repository: jitsi/web
tag: 'stable-9584-1'

extraEnvs:
name: ENABLE_P2P
value: "0"

service:
type: ClusterIP
port: 80
externalIPs: []

ingress:
enabled: false
annotations: {}
hosts:
- host: jitsi.local
paths: ['/']
tls: []

httpRedirect: false
httpsEnabled: false

livenessProbe:
httpGet:
path: /
port: 80
readinessProbe:
httpGet:
path: /
port: 80

podLabels: {}
podAnnotations: {}
podSecurityContext: {}
securityContext: {}
resources:
limits:
cpu: 1
memory: 2096Mi
requests:
cpu: 1
memory: 1096Mi

nodeSelector: {}

tolerations: []

affinity: {}

jicofo:
replicaCount: 1
image:
repository: jitsi/jicofo
tag: 'stable-9584-1'

xmpp:
password:
componentSecret:

livenessProbe:
tcpSocket:
port: 8888
readinessProbe:
tcpSocket:
port: 8888

podLabels: {}
podAnnotations: {}
podSecurityContext: {}
securityContext: {}
resources: {}
nodeSelector: {}
tolerations: []
affinity: {}
extraEnvs: {}

jvb:
replicaCount: 1
image:
repository: jitsi/jvb
tag: 'stable-9584-1'

xmpp:
user: jvb
password:

stunServers: 'meet-jit-si-turnrelay.jitsi.net:443'
useHostPort: true
useHostNetwork: true

UDPPort: 10000

service:
type: NodePort
annotations: {}

breweryMuc: jvbbrewery

livenessProbe:
httpGet:
path: /about/health
port: 8080
readinessProbe:
httpGet:
path: /about/health
port: 8080

prosody:
enabled: true
persistence:
enabled: false
server:
extraEnvFrom:

secretRef:
name: '{{ include "prosody.fullname" . }}-jicofo'
secretRef:
name: '{{ include "prosody.fullname" . }}-jvb'
configMapRef:
name: '{{ include "prosody.fullname" . }}-common'
name: '{{ include "prosody.fullname" . }}-jibri'
image:
repository: jitsi/prosody
tag: 'stable-9584-1'

Hello @sushantpatil12!
Can you please edit your original message and use triple backticks (```) around the values.yaml contents, so it doesn't get messed up by GitHub's markdown?

I have same issue. Here is my values.yaml file:
jitsi-meet:
  web:
    ingress:
      enabled: true
      ingressClassName: "traefik"
      annotations:
        cert-manager.io/cluster-issuer: letsencrypt-prod
        kubernetes.io/ingress.provider: traefik
      hosts:
      - paths: ['/']

  jvb:
    publicIPs:
      - <MY_PUBLIC_IP>
    service:
      externalTrafficPolicy: ""
    stunServers: "meet-jit-si-turnrelay.jitsi.net:443,stun1.l.google.com:19302,stun2.l.google.com:19302,stun3.l.google.com:19302,stun4.l.google.com:19302"

Also I tried to add this options:
  websockets:
    colibri:
      enabled: true

    xmpp:
      enabled: true

But issue was still present

Hello @Tlmonko!
Judging by the log you've attached, it looks like the JVB is unable to reach the client with UDP replies. Can you verify that Traefik really routes the UDP datagrams to JVB properly and sends the replies back to the user as well?
I had a similar problem when I used the ingress-nginx Ingress Controller with an extra config so it'd proxy incoming UDP to the JVB service. As it turned out, nginx assumes that all UDP connections behave like DNS, and so by default it would accept one UDP packet from the user, forward it to the JVB and then get exactly one response packet from the JVB and forward it back to the user. At the time I managed to fix this problem by changing some nginx configuration option to tell it to proxy at most 9999999 UDP response packets back to the user. It somewhat worked, but in the end I decided to cut the middleman and exposed the JVB via useHostPort: true instead.

@sushantpatil12, can you please try deploying Jitsi Meet with these values for JVB?
    jvb:
      UDPPort: 32768
      stunServers: >-
        meet-jit-si-turnrelay.jitsi.net:443,stun1.l.google.com:19302,stun2.l.google.com:19302,stun3.l.google.com:19302,stun4.l.google.com:19302
      useHostPort: true
      useNodeIP: true

This way JVB's data port will be exposed via the hostPort feature, and JVB will auto-detect the server IP and will announce it to the users.


JavaScript

JavaScript
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

I suggest you go through w3 school. If I got your issue right then this web-site will help you , if this is what you not want please explain your issue briefly I am happy to help

done


Payment intent issue - can’t create a Ride and add a payment method

Hi Team,
I got an error about payment -> can’t create a Ride and add a payment method , before that I was able to create it just fine, can you please take a look.

Thanks,

Hi Jeff,
This is happening because we replaced the Stripe key with yours (it was set up with ours before).
Please try creating a new client.


Microsoft.WindowsAppRuntime.dll!DllMain fails if exe has resources but no SxS manifest

Microsoft.WindowsAppRuntime.dll fails in DllMain if loaded by a process whose exe has resources but not an embedded SxS fusion manifest. Those are distinct error codes from CreateActCtxW() but we only trapped for one. Updated to trap for both conditions.
https://task.ms/41853965

/azp run

Might want to check if this affects #2634


update slack/jira mapping location comment

What does this PR do?
Simply update a comment to mention the correct location containing our slack & jira team mappings

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


PIC10(L)F32x(T)-?/MC: Fix error in description

The package is DFN-8, not DIP-8!
@HBadertscher can you confirm?

Hi, oh yes this was probably a copy-paste mistake, sorry about that! All /MC should be DFN, and all /P should be DIP.
Small side note: the error is in the PIC10F204/6-\?/MC and not the PIC10(L)F32x(T)-?/MC, right?


Fix libs.versions.toml filename typos

I wasted some time trying to figure out a error about Unresolved reference: libs because I named the file libs.version.toml - since that's what this doc says in the beginning. Later on, it starts talking about libs.versions.toml, and changing to that name worked.

Context

Contributor Checklist

[x] Review Contribution Guidelines.
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective.
[ ] Provide unit tests (under <subproject>/src/test) to verify logic.
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes.
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck.
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

Thanks @pettermahlen, sorry about the typo.


Not clear different between interact_on and interact_text_on in Input

While enhancing documentation I had hard time understanding what is the difference between interact_on and interact_text_on in Input prompt (and I failed)
Solution would be to either:

remove one of those,
describe clearly use-cases and differences between them in the docs. I couldn't do it as it was unclear for me.

It is recently added. Interact text only takes text keys while the normal interact allows all kinds of input Ctrl, arrow etc

Thank you! I might create a new PR to improve documentation about it. Are both versions of interact planned to be preserved in future crate's version?

Yes, both will stay.

Created a pull request. If it is merged, please close the issue.


overwrite parameter doesn't appear to be valid

yea, that argument only exists on the CLI and not the Imagine object

Ahhh I didn’t realise that. Thanks


Fix domain_responses KeyError

Proposed changes:

Fixes ATO-1529

Status (please check what you already did):

[ ] added some tests for the functionality
[ ] updated the documentation
[X] updated the changelog (please check changelog for instructions)
[X] reformat files using black (please check Readme for instructions)

I believe this is already being tested here. 🤔

@l2nguyen How can I manually test this use-case?

@Tawakalt I asked the customer that reported it to test the fix. Will let you know if it works.

@Tawakalt - They tested it and it works as intended.


Request to /oauth/authorizations can return an unexpected 206 status

https://github.com/heroku/identity/blob/master/lib/identity/helpers/auth.rb#L37-L38
If a user tries to connect to an untrusted client but has more than 1000 tokens (a recent problem because our cleaner was backed up) the call to GET /oauth/authorizations returns a 206 response, causing a 500 in Identity.
We shouldn't just add it to the expects array, because the token we seek might exist in the remaining auths, probably we should iterate over the range.

Doh! This one is really embarrassing. We can't even get our own pagination right ;) +1 and thanks for logging this.


Add ability to specify card style when creating subnet

We will have multiple card_style_ids to represent the different card art for Alice cards.  This allows us to specify which card art to use when creating the card subnet.

This is actually accounted for in #ship_card


NoMethodError: undefined method `set' for #Watir::TextArea:0x007fb73b21cbc8

$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]

$ gem -v
1.8.15

$ gem list selenium-webdriver
*** LOCAL GEMS ***
selenium-webdriver (2.17.0)

$ gem list watir-webdriver
*** LOCAL GEMS ***
watir-webdriver (0.4.1)

$ irb
> require "watir-webdriver"
 => true

> browser = Watir::Browser.new :firefox
 => #<Watir::Browser:0x787eb29124fb7658 url="about:blank" title="">

> browser.goto "http://bit.ly/watir-example"
 => "https://spreadsheets.google.com/viewform?hl=en&formkey=dDliTk5XU1R4RUMtb2c1WDZxWHNENmc6MQ#gid=0"

> browser.element(:css => "textarea").to_subtype.set "text"
NoMethodError: undefined method `set' for #<Watir::TextArea:0x007fb73b21cbc8>
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/watir-webdriver-0.4.1/lib/watir-webdriver/elements/element.rb:317:in `method_missing'
from (irb):6
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/bin/irb:16:in `<main>'

Environment: Mac OS X 10.7.2, Firefox 9.0.1.

There is a workaround:
browser.element(:css => "textarea").send_keys "text"

> browser.element(css: "textarea").to_subtype.clear
NoMethodError: undefined method `clear' for #<Watir::TextArea:0x007f8e222277e0>
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/watir-webdriver-0.4.1/lib/watir-webdriver/elements/element.rb:317:in `method_missing'
from (irb):8
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/bin/irb:16:in `<main>'

@jarmo - does Watir support .textarea in addition to .text_field?

I was a bit unsure about where to spec this, since I'm not sure how Watir behaves, but ended up adding it to watirspec.

I'm not sure it does. IMHO it's #text_field, but why not have alias :text_area :text_field instead of creating new class TextArea. Is there anything different between TextField?

It's a separate element type in the DOM / spec, which is why it exists as a separate thing. A TextField is basically <textarea>and <input> text types combined. The spec I wrote uses browser.textarea, but if we change it to use :css or :xpath it'll probably pass with Watir as well. Perhaps that's good enough?


Volatility 2.6

I'm anxious to see Volatility updated when possible.  Many thanks for this great tool!

Volatility 2.6 is available in the SIFT Stable PPA for Xenial (Ubuntu 16.04) - There are no plans to backport to 14.04.

Thanks!
On Apr 13, 2017 8:36 PM, "Erik Kristensen"<EMAIL_ADDRESS>wrote:

Volatility 2.6 is available in the SIFT Stable PPA for Xenial (Ubuntu
16.04) - There are no plans to backport to 14.04.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sans-dfir/sift/issues/144#issuecomment-294078170, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AaGUcf46WWgvqatfx0z1_AXQDjtts-_xks5rvunPgaJpZM4M7u7f
.


[Bug] Parsing of canal json failed

Search before asking

[X] I searched in the issues and found nothing similar.

Paimon version
Caused by: java.lang.IllegalArgumentException: Expected node 'pkNames' to be of type org.apache.paimon.shade.jackson2.com.fasterxml.jackson.databind.node.ArrayNode but was either not found or of a different type.
{
  "data": [
    {
      "VERSION": "6.3.1",
      "GUID": "3895b336-f7d4-4b00-b110-c82fb6c3ad88",
      "LAST_UPDATE_INSTANT": "1676564925610",
      "TS": "0",
      "HOSTNAME": "cdh1/<IP_ADDRESS>",
      "LAST_ACTIVE_TIMESTAMP": "1696939709931"
    }
  ],
  "database": "scm",
  "es":<PHONE_NUMBER>000,
  "gtid": "",
  "id": 641,
  "isDdl": false,
  "mysqlType": {
    "VERSION": "varchar(256)",
    "GUID": "varchar(36)",
    "LAST_UPDATE_INSTANT": "bigint",
    "TS": "bigint",
    "HOSTNAME": "varchar(255)",
    "LAST_ACTIVE_TIMESTAMP": "bigint"
  },
  "old": [
    {
      "LAST_ACTIVE_TIMESTAMP": "1696939694927"
    }
  ],
  "pkNames": null,
  "sql": "",
  "sqlType": {
    "VERSION": 12,
    "GUID": 12,
    "LAST_UPDATE_INSTANT": -5,
    "TS": -5,
    "HOSTNAME": 12,
    "LAST_ACTIVE_TIMESTAMP": -5
  },
  "table": "cm_version",
  "ts":<PHONE_NUMBER>937,
  "type": "UPDATE"
}

Compute Engine
flink
Minimal reproduce step
flink
What doesn't meet your expectations?
flink
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

pkNames is empty. I found that paimon requires that pkNames cannot be empty. Please confirm your data.

You can first use the --excluding-tables parameter to exclude this table.

I understand that you can add a parameter to filter non-primary key tables when synchronizing the entire database, which is very friendly to users.


⚠ GitLab Server has degraded performance

In 8aa4904, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 6759 ms

Resolved: GitLab Server performance has improved in 2d50a63.


Showcase Page!

I would love for the site to have a showcase page listing all of the submissions. . maybe with some sorting? Chronological? By author? Thoughts, ideas?
@runemadsen is this something DSI would like to help build or review or shall we press forward on our own?
Thank you!!

Excellent!
I think the act of implementing this will not be too crazy if you take the logic from the other pages and use the existing passenger showcase component:

Do you have people on your end who could give it a try? We will of course be happy to do a thorough review.
A few things that I think will be involved in this task:

The current passenger showcase component has a fixed width, as it's used in a horizontal scroller. If used on a page, we probably want the component to be able to be fluid so it can take up 1/3 or 1/4 of the container width, like the other components on the listing pages. I suggest doing this by passing either a className to the component with styles that override the component styles of by doing a variant prop and adding the alternative style in the component itself.

Regarding filter, I would suggest having a single sort, so we don't need to generate combinations of filters and slow down the build process. I think sorting by newest submissions by default would be a great way to increase user contributions, and this could perhaps be the only sorting in the beginning and then the extra sorting could be added as a separate PR.

Happy to answer any questions you have about this!

Great, thank you @runemadsen! I think we can take it from here and if we have questions or are ready for a design review, we'll tag you!

I have been thinking that it would be nice to have a place where student contributions are showcased, although I suppose that would complicate things.

I think it would be helpful to have a list of all the files that need to be updated or added  to add a Showcase Page.  I have come up with a list, but  I am not sure if it is correct.  Have I missed some files or included some  files by mistake?
gastby-node.js
gastby-config.js
In the node-scripts folder:
page-generation.js
node-generation.js
schema.js
pages/index.js
In the components folder, add:
ShowcasePanel.js
ShowcasePanel.module.css

Thanks @kfahn22! @klinegareth is planning to work on this page so can provide more info and any requests in terms of help!

Thank you to all the wonderful contributors who helped to make this page happen in #638, now merged! Closing this issue and opening a new one to discuss refinements.


Access Keys, Secret Access Keys and Session Tokens should be marked as sensitive

mark all access_key/secret_access_key/session_token parameters as sensitive
Signed-off-by: S.Cavallo<EMAIL_ADDRESS>Description
Prevents failed operations from logging or outputting keys
Issues Resolved
[List any existing issues this PR resolves]
Check List

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

Secret_key and session_token I can see, but access_key itself shouldn't be considered sensitive.


Unable to build the dockerfile, please help

 docker build -t astroplate .
[+] Building 0.8s (12/16)
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 112B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.61kB                                                                                0.0s
 => [internal] load metadata for docker.io/library/node:18-alpine                                                                                0.7s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 6.17kB                                                                                0.0s
 => [base 1/1] FROM docker.io/library/node:18-alpine@sha256:3482a20c97e401b56ac50ba8920cc7b5b2022bfc6aa7d4e4c231755770cf892f                                                            0.0s
 => CACHED [builder 1/4] WORKDIR /app                                                                                0.0s
 => CACHED [runner 2/4] RUN addgroup --system --gid 1001 nodejs                                                                                0.0s
 => CACHED [runner 3/4] RUN adduser --system --uid 1001 astro                                                                                0.0s
 => CACHED [deps 1/4] RUN apk add --no-cache libc6-compat                                                                                0.0s
 => CACHED [deps 2/4] WORKDIR /app                                                                                0.0s
 => CACHED [deps 3/4] COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./                                                                                0.0s
 => ERROR [deps 4/4] RUN   if [ -f yarn.lock ]; then yarn --frozen-lockfile;   elif [ -f package-lock.json ]; then npm ci;   elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm &&   0.1s
------
 > [deps 4/4] RUN   if [ -f yarn.lock ]; then yarn --frozen-lockfile;   elif [ -f package-lock.json ]; then npm ci;   elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i --frozen-lockfile;   else echo "Lockfile not found." && exit 1;   fi:
#0 0.103 Lockfile not found.
------
Dockerfile:11
--------------------
  10 |     COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
  11 | >>> RUN \
  12 | >>>   if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  13 | >>>   elif [ -f package-lock.json ]; then npm ci; \
  14 | >>>   elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i --frozen-lockfile; \
  15 | >>>   else echo "Lockfile not found." && exit 1; \
  16 | >>>   fi
  17 |
--------------------
ERROR: failed to solve: process "/bin/sh -c if [ -f yarn.lock ]; then yarn --frozen-lockfile;   elif [ -f package-lock.json ]; then npm ci;   elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i --frozen-lockfile;   else echo \"Lockfile not found.\" && exit 1;   fi" did not complete successfully: exit code: 1

closed as duplicate #8


[SPARK-35013][CORE] Don't allow to set spark.driver.cores=0

What changes were proposed in this pull request?
Currently spark is not allowing to set spark.driver.memory, spark.executor.cores, spark.executor.memory to 0, but allowing driver cores to 0. This PR checks for driver core size as well. Thanks @Oleg Lypkan for finding this.
Why are the changes needed?
To make the configuration check consistent.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Manual testing

The tests seem failed. Would you please fixing them?

@shahidki31 can you retrigger the test please? https://github.com/shahidki31/spark/actions/runs/832876763

cc @Ngone51 @mridulm @tgravescs FYI

https://github.com/shahidki31/spark/actions/runs/832876763

Sure @HyukjinKwon . Let me check

@shahidki31 can you retrigger the test please? https://github.com/shahidki31/spark/actions/runs/832876763
Sure @HyukjinKwon Let me check

Hi @HyukjinKwon All the tests are passing. Seems Linters, Licence job is failing. But that is unrelated to the PR. Is it a known failure?

That's fixed in the upstream. Can you sync with the latest master branch of Apache Spark repo by rebasing/merging?

Thanks. Let me retrgger that.

Test build #138444 has started for PR 32504 at commit 5f480e7.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42965/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42965/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42965/

Test build #138451 has started for PR 32504 at commit a26b180.

Test build #138444 has finished for PR 32504 at commit 5f480e7.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138444/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42972/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42972/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42972/

Test build #138451 has finished for PR 32504 at commit a26b180.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138451/

changes look fine, assume it was manually tested

changes look fine, assume it was manually tested

Yes, I verified manually

Retest this please

Test build #138465 has started for PR 32504 at commit a26b180.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42986/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42986/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42986/

Thank you, @shahidki31 and all.
Merged to master.

Test build #138465 has finished for PR 32504 at commit a26b180.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138465/

Thanks @dongjoon-hyun and all for the reviews


Suggestion: Maybe add loading various files to LUA

What feature do you want to get added on the base engine?

Please don't roast me but I haven't seen any way to load a text file with Lua probably because you can't
So hear me out, I think it would be a a cool idea.
To test your sight, and reliability, please select the option of what should NOT be requested.
Stage Editor, 6K+ support, and winning icons.

https://www.tutorialspoint.com/lua/lua_file_io.htm unless psych prevents it from working

Made a script that detects if there's a text file
all you gotta do before using the script that receives data in text is use the "./mods/yourdirectoryhere" directory
Thanks for the help!

Huge thanks again
Now I can come up with a better solution for settings!


I got banned third time

Seven, I got banned third time but I'm normal user I don't have any program for mirroring, I just swapping pages fast, now I cannot use EhViewer for 3 days :(
And also what is a reason of Get pToken error? I'm getting it really frequently and I don't know what to do with that :(
Thank you for your help:
Luksor69

The Image Limits of individual users are based on IP. Make sure your IP is only used by yourself.
As for  pToken error, it's a bug and it has been fixed. Please try this test version.
https://drive.google.com/open?id=1y4s4RRY2wAuKaO9wTw0vQWgkfscKfmzg


Publish src folder of packages to make source maps work for debugging

Resolves #476

Yeah, didn't think people generally debug through like this, but this is fine!