Try to fix windows builds

I (hmaarrfk) am trying to see if we can fix a few of the oddities introduced in https://github.com/conda-forge/openfast-feedstock/pull/39 to help make this package installable again.

maybe we can have a look at the scipy feedstock and take inspiration from there
https://github.com/conda-forge/scipy-feedstock/

@hmaarrfk - Wow, thank you so much for the personalized attention here stemming from the Issue question.  For a long time this package was linux/osx only and we recently are pushing to include Windows.  The package won't built with the mingw-gfortran v5.3 that is the easiest toolchain in conda forge.  We found a workaround by using the newer mingw gfortran versions available via choco or local on the Azure runners.  Looking at your changes, it seems like that isn't recommended?

We found a workaround by using the newer mingw gfortran versions available via choco or local on the Azure runners.

this is not ok.

Duly noted- thank you.
Your changes look like you have LLVM flang 17 as something to try out here.  I was struggling to figure out the packaging to get that working.  Your changes probably have us pointed in the right direction if you prefer us package owners to take over the debugging from here on. There might need to be some updates to the underlying CMake config to enable LLVM Flang.

ok. feel free to try and take over. I'll stop pushing updates here

Your contributions are much appreciated!  I'm going to redirect this PR into a branch and then merge it, so that it is a bit easier to iterate on.

sorry why would you merge this if it was broken?


Popp firmware update files added

POPE700397 V3.15 Popp Smart Outdoor Plug
POPE700854 V2.06 Popp Solar Outdoor Siren 2
POPE701202 V1.02 Popp Mold Detector Sensor

Those are all resolved, just removed the comments (forgot to earlier). All good to go


avoid SONAME check using objdump on Windows

Haskell Platform comes with a objdump in PATH, which fails finding cuda libs because of SONAME checking.
This is already patched in mainstream, but not merged into 2.0 branch.

I signed it!

Nagging Reviewer @yifeif: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 14 days with no activity and the awaiting review label has been applied.

@goldiegadde what's the process for cherry-picking for 2.0? Thanks!

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

It has been 43 days that this pull-request has stalled. Please create a new pull-request with the requested changes.


UI lag on section expansion

https://dl.raenonx.cc/cht/misc/24
Try rendering the items but hide them first. See if there is any performance impact on page load.

The fix in 73bc85d is a dirty fix because it uses React.useState to store the rendered JSX.


Wrong mod file uploaded on modrinth

The file "servercountryflags-1.10.4-1.21.1-NEOFORGE.jar" was uploaded as World Play Time 1.2.2 - 1.21 on modrinth, which is supposed to be worldplaytime-1.2.2-1.21-NEOFORGE.jar.

Removed some time ago, I will add the correct file eventually, thanks for noticing!


refactor sparse_categorical_crossentropy

factor out the -1 * and / loss_mask.sum() for both smoothing and non-smoothing terms
saved like 1 minutes in resnet estimated for green

ran 15 epochs look all fine, can save 1+ min total https://wandb.ai/chenyuxyz/tinygrad-examples_mlperf/runs/h0st0kr9/overview?nw=nwuserchenyuxyz


Support codeblock highlighting

It would be really nice to have syntax highlighting support for inlyne. I haven't delved into the html rendering side, but getting comrak to support adding colored spans in codeblocks is as simple as
diff --git a/src/main.rs b/src/main.rs
index c14b060..7677e81 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -928,7 +928,12 @@ fn main() {
         options.extension.strikethrough = true;
         options.parse.smart = true;
         options.render.unsafe_ = true;
-        let htmlified = markdown_to_html(&md_string, &options);
+
+        let mut plugins = comrak::ComrakPlugins::default();
+        let adapter = comrak::plugins::syntect::SyntectAdapter::new("base16-ocean.dark");
+        plugins.render.codefence_syntax_highlighter = Some(&adapter);
+
+        let htmlified = comrak::markdown_to_html_with_plugins(&md_string, &options, &plugins);

         input.push_back(
             Tendril::from_str(&htmlified)

The theme is configurable (passed to SyntextAdapter), and this renders html that looks like so when viewed in my browser

and here is the raw HTML for the first block

// cat.js
import { resolve } from "path";
import { write, stdout, file, argv } from "bun";

const path = resolve(argv.at(-1));

await write(
  // stdout is a Blob
  stdout,
  // file(path) returns a Blob - https://developer.mozilla.org/en-US/docs/Web/API/Blob
  file(path)
);

// bun ./cat.js ./path-to-file

I would be happy to do the work rendering the colored spans if you think this change would be worthwhile

@LovecraftianHorror Absolutely would be worthwhile. I didn't know comrak had this feature.
I'm currently on holiday for the weekend but if you feel like producing a PR that would be great help!
It should be as easy as calling with_color() on the text in the parser. The parsers a bit of a mess but there should be enough code to get the general idea of how it works.

I've got a draft PR in, but it seems like there are some bugs regarding indentation. Anyways no rush on getting that sorted out. Enjoy your vacation!


use int64 for chat attachment sizes

Delegate to @patrickxb
On Fri, Apr 21, 2017 at 5:05 PM Steve Sanders<EMAIL_ADDRESS>wrote:

@zanderz https://github.com/zanderz requested your review on:
keybase/client#6657 https://github.com/keybase/client/pull/6657 use
int64 for chat attachment sizes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/pull/6657#event-1053095138, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA05_74eIWZwERSAhDfInEYyoYSrPk_Qks5ryRoKgaJpZM4NCaJI
.

Could you test (manually) that downloading an attachment uploaded with the old protocol works with the new protocol?

Attachment stuff looks good to me.
Are the simplefs changes meant to be in a separate PR?

I just did a download test, seems ok - did a binary compare for good measure.

re: download test: sounds good.
What about the simplefs changes?  Are those in this PR by accident?

oh yeah, sorry. Part of the original bug was missing error output on the CLI, and I found another place or two to clean up while I was in there. Could make a separate PR if you want.

Looks good to me.


Provide a way to allow connection by docker container name in whiteList.sourceRange or new configuration option.

Do you want to request a feature or report a bug?
Feature
What did you expect to see?
Actually, traefik.frontend.whiteList.sourceRange accept only IPs/IPs ranges.
It will be great to be able to restrict front end connection by container name too, as container ip are volatile and should usualy not be managed manually.
Use case:
Docker is limited to 31 networks maximum (overlay doesn't have this limitation but need swarm).
For each project (more than 31) we need to provide a connection between container of the same project.
Using proxy traefik is a solution as we can define which container can access to the backend, by restricting frontend with whiteList.sourceRange. Problem is we need to provide container ip... and using docker-compose we cannot know IP, just container name.
As container name resolve to IP, maybe it would be possible to use container name in traefik.frontend.whiteList.sourceRange, it will make restricting access more easy.
If needed a new configuration option could be added:
traefik.frontend.whiteList.container="mycontainer1,mycontainer2"
Thanks for reading this proposal.

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Træfik!
Issue templates help us help you by providing all necessary information.
Please edit your issue and use the available templates:

Feature request
Bug report

And remember: each time someone ignores the template, a cute little bunny dies.

#SaveTheCuteBunny :heart: :rabbit: :heart:

Hi and thank you for your feature request.
The current design of whiteListing is indeed to accept IPs only.
In a docker environment, it would technically be possible to add container names to these, but we feel like it wouldn't be true whiteListing anymore, but ACL in disguise, which is a whole different topic.
I'll close the issue for now, but feel free to add your thoughts in the comments.

@geraldcroes Thanks for your answer, I agree with you. I was thinking it like the Require directive from Apache (see: https://httpd.apache.org/docs/2.4/howto/access.html#host) which can handle ip or host.
So maybe it should be a new frontend config parameter, different than whiteList, only available for docker ? (or any container environment, like kubernetes, etc.) ? Something like:
traefik.frontend.restrict.container="mycontainer1,mycontainer2"


Navigation menus should appear on hover, and should not require the user to click

Across the board, all user types, all nav menus

Confirmed fixed in 9/29 milestone


Allow to disable clipping on parent

Currently all child widgets are rendered inside the parent bounds only. We should allow to disable this clipping via api on the parent so that children can be drawn outside the bounds.
This can be used for animations where you want to move a child outside of the bounds (eg swipe things away).

We have agreed to a solution where setting "clipchildren" to false on a widget allows its children
to draw outside of their bounds.

This story will be implemented in the scope of https://github.com/eclipsesource/tabris-js/issues/602.

Android implementation could be achieved by mapping the native clipChildren property. Clarify with iOS team what the effort would be.

Didn't we already have clipChildren property on the Widget? It should not be a big effort to enable it.

Research has shown that it is doable on both platforms but the implementation is missing on iOS and has not been merged yet on Android.


Update and add show option to cache config

scons-configure-cache.py can now show the cache configuration,
and some statistics (currently only a file count).  Script
passes pep8 now.
Note for submit form questions: docs are inline only; there are no external tests but have manually tested.
Signed-off-by: Mats Wichmann<EMAIL_ADDRESS>Contributor Checklist:

[X] I have created a new test or updated the unit tests to cover the new/changed functionality.
[X] I have updated master/src/CHANGES.txt directory (and read the README.txt in that directory)
[X] I have updated the appropriate documentation

Are there new or changed tests for this?

k. Merging.

This is sample output, btw. Hoping it's of some use to someone:
$ python /tmp/scon*py --show .scons_cache
Current configuration in '.scons_cache':
{
    "prefix_len": 2
}
Cache contains 1630 files


Analyzer fails to analyze files when file path contains spaces

The analyzer fails to analyze files when the file path contains spaces or non-ascii characters. There are two tests demonstrating this behavior included below. Both tests fail because resolveFile returns null. Changing only the file path will cause either test to pass.
This prevents us from analyzing some of the packages in the corpus derived from itsallwidgets.
// Copyright (c) 2020, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

import 'package:analyzer/src/dart/error/syntactic_errors.dart';
import 'package:test_reflective_loader/test_reflective_loader.dart';

import '../dart/resolution/driver_resolution.dart';

main() {
  defineReflectiveSuite(() {
    defineReflectiveTests(WithSpaceTest);
  });
}

@reflectiveTest
class WithSpaceTest extends DriverResolutionTest {
  Future<void> test_withNonAscii() async {
    var path = '/test/lib/obsesión.dart';
    var file = newFile(path, content: '''
var x =
''');
    result = await resolveFile(file.path);
    assertErrorsInResolvedUnit(result, [
      error(ParserErrorCode.EXPECTED_TOKEN, 8, 0),
      error(ParserErrorCode.MISSING_IDENTIFIER, 8, 0),
    ]);
  }

  Future<void> test_withSpace() async {
    var path = '/test/lib/with space/test.dart';
    var file = newFile(path, content: '''
var x =
''');
    result = await resolveFile(file.path);
    assertErrorsInResolvedUnit(result, [
      error(ParserErrorCode.EXPECTED_TOKEN, 8, 0),
      error(ParserErrorCode.MISSING_IDENTIFIER, 8, 0),
    ]);
  }
}

@scheglov @pq

https://dart-review.googlesource.com/c/sdk/+/150581


[FEATURE REQUEST] MARFC RTMA, NBM, and FMAT Products

POCs: Tom Ressin
TODO

[x] RHA_T_RTMA_1hr.YYYY-MM-DD.HHz.grb - hourly observed air temp processor
[x] RHA_T_NBM_XXhr.YYYY-MM-DD.HHz.grb - 1/3 hour forecast air temp XX hours (1-99) from present processor
[x] FMATXXhr_YYYYMMDD.HHz.grb - 6 hour forecast air temp XX hours (6-96) from present processor
[x] LDM push to Cumulus bucket

Processors created for

[ ] RHA_T_RTMA_1hr.YYYY-MM-DD.HHz.grb - hourly observed air temp
[ ] RHA_T_NBM_XXhr.YYYY-MM-DD.HHz.grb - 1/3 hour forecast air temp XX hours (1-99) from present
[ ] FMATXXhr_YYYYMMDD.HHz.grb - 6 hour forecast air temp XX hours (6-96) from present

LDM connection needs updating to push to Cumulus

Commit USACE/ldm-config@eaebb50e81755f26dc763b04361f84731ccd976d closes this issue.
This work to include these products is complete but LDM on EC2 continues to become more unstable.


[BUG] [2.2.2 BETA] iTrade shops cannot be destroyed

tradeshop-2.2.2-BETA-2020-05-19T18.50.13.jar
itrade signs simply re-appear when destroyed. They can only be destroyed by removing the block they're attached to
On break:
https://pastebin.com/C8hB7kd8

I think I got this too. Seems to be because I was trying to get the players Inventory Storage Contents (only exists when the player opens an inventory).

has this fix been tested?

This is fixed in the latest dev release


Named field puns

This RFC proposes a shorthand syntax for constructing struct-like values with named fields.
Rendered
We propose treating expressions like S { x } to be equivalent to S { x: x }, where S is a struct, struct-like enum variant, or untagged union.
Note: this RFC was coauthored by @joshtriplett and myself.

Rendered

Closes https://github.com/rust-lang/rfcs/issues/306
Thanks for opening this, since the implementation is trivial, a formal RFC (+ lang team decision) is the only things necessary to add this to the language.

As a point of experience, I've used a macro for this in Elixir, and the ergonomics just aren't as good as having it baked into the language, like with ECMAScript 2015.

This is clearly inspired from ECMAScript and from my experience with JS, it’s really very convenience syntactic sugar. 👍
However, I have one minor problem with the syntax, it’s IMO not very clear what’s going on at the first sight. It looks exactly like construction of tuple-like structs with positional fields, only except parenthesis.
I think that using a colon before a variable name may communicate the intention a bit better:
S { x: x } → S { :x }.
What do you think?

@jirutka - Keeping it aligned with ES6 makes it easier to understand for a growing number of devs.  Generally a good rule of thumb to reduce confusion that new syntax might cause if there's already a precedent that people will be familiar with...

@jirutka besides what @jonathandturner mentioned, there's also the issue of potential confusion for people coming from Ruby, where a : prefix is used for Symbols. Although this is admittedly a minor problem.

Well, this argument is kinda double-edged. For example, many languages uses null, so should we add it too to be more familiar? I would rather think about it from perspectives of Rust, how it fits to the current syntax and if it may cause some confusion, now what other languages uses.
That said, I consider it a minor issue, I just want to open discussion about the syntax, find more relevant arguments, not just “ECMAScript has it.”

@jirutka I think the syntax with the ':' is worth listing in the alternatives, at the very least.  I personally don't quite favor it, but not because of the additional character; it's because when compared to the field: value syntax, it makes the field name look like it takes the place of value while leaving out field, which seems odd.  Using a trailing colon seems more evocative, but field1:, field2: looks strange.
I don't think it's just the braces that'll make it look visually distinct; it's also the conventional spacing.  Consider these two typical initializers:
Struct1(a, b, c)
Struct2 { a, b, c }

If they differed only by punctuation, I'd agree that that seems slightly subtle.  But a tuple-struct-style initializer typically has no space around the parentheses, while a named field initializer (with or without shorthand) typically has space around the braces.  (Coming from C-like languages in general, braces directly next to other tokens without whitespace just looks wrong.  That tends to, instead, evoke bash-style expansion: foo{1,2,3} expanding to foo1 foo2 foo3.)

I was told to write this down, so I am.
I don't like this proposal because I think it's unnecessary and confusing. As a C programmer, I would expect that:
struct Foo {
  x: i32,
  y: i32,
}

let x = 0; let y = 1;
let foo = Foo { x: y, y: x };

to be equivalent to
struct Foo {
  int32_t x;
  int32_t y;
}

int32_t x = 0; int32_t y = 1;
Foo foo = { .x = y, .y = x };

and
let x = 0; let y = 1;
let foo = Foo { y, x };

to be equivalent to
int32_t x = 0; int32_t y = 1;
Foo foo = { y, x };

which would be the reverse of what it is now.

@ubsan - Is the gist here that positional values no longer holds?

@jonathandturner Right. If I'm writing Foo { x, y } then I'd expect it to be positional, not based on names which are easily subject to change.

Rust never had any way of observing defined positions of named fields, other than drop order, so this doesn't feel like a particularly strong argument.
On the contrary, C's syntax for this is more confusing and mistake-prone by default than it needs to be, as you can easily get the ordering wrong with the definition of the structure being somewhere else entirely.

@ubsan I can understand that.  That's part of what we were trying to capture with the note in the RFC that this could look a bit like a positional initializer.
@jonathandturner Structs with field names havenever accepted positional initializers, and this doesn't change that.  It's that, coming from other languages, this looks like a positional initializer, but interpreting it as such would produce incorrect results.  (For that matter, it would mean code that Rust would normally reject as invalid will instead compile, and if someone learning Rust tries to write a positional initializer, and happens to use the same names as the fields, they'll get weird results rather than a helpful compiler error.
This is actually a good argument for adding some kind of sigil to indicate this shorthand, as @jirutka suggested.  That would make it clear that something more is going on.  I'm finding that argument rather convincing now.
What might that sigil look like?  What are other alternatives to a leading or trailing colon on the field name?

@eddyb Foo(x, y) should feel equivalent to Foo { x, y }, and it'd be weird (to me) if they didn't. It'd also confuse many C/C++ programmers coming to Rust for the first time, imho.

C-f "pattern" found nothing, so I'd like to note that we already have half of this feature: Foo { x, y } is a pattern short for Foo { x: x, y: y }. And these are already non-positional: Foo { y, x } is an equivalent pattern.
This RFC brings the existing pattern shorthand into the expression syntax.

@solson I’m confused, what’s “C-f pattern”?

(@jirutka, I think they mean that they searched the text of this discussion)

@solson That was exactly what we were going for.
Interesting point about the non-positional patterns.  On the other hand, most other languages with this kind of syntax don't have pattern-matching, so the knowledge doesn't carry over as much.  But it would be odd to introduce an extra sigil for the initializer shorthand that patterns don't use.  Hmmm.

Yeah, given @solson's comment, it seems the current syntax is the most Rust-consistent syntax, even if it's not the most over-language-consistent syntax.

@jirutka As @ranweiler said, I just meant I did a Ctrl+F search.
@joshtriplett Yeah, I didn't say much that's not in the RFC, but I thought it was good to stress this point. Good point also about consistency between the two syntaxes.

This mirrors the existing syntactic sugar of structs patterns. +1

@joshtriplett Very good point with the pattern matching; I totally forgot that we already have something semantically similar in pattern matching. That’s IMO a good argument for the proposed syntax without any extra sigil.

@solson So you’re basically just trolling or what? 😕 Nevermind…

@jitrutka - be nice...

@jonathandturner I totally misunderstood his comment in a way that it really looked like a trolling for me. After like fifth attempt I finally got that he was referring pattern matching.

Is there a parsing ambiguity with type ascription? I.e., is S { x: y } to be interpreted as a variable x with type y or a field x and expression y?

@jirutka, I definitely see the case for an expansion sigil. However, I would be quite surprised by the resulting asymmetry between pattern match and expression occurrences. As a counterpoint to your "first glance" scenario, one might suspect S { :x } to be a typo! That is peculiar to the : sigil, but I think that with any sigil, we'd the be adding more new syntax for a beginner to learn, with less precedent, and the cost/benefit ratio of having any new compact syntax starts suffering.
@ubsan's C/C++ perspective is important to consider, and helpful, as I'm definitely coming at this more from a Haskell (where I first saw this) and ES6 background.
In support of the proposed syntax, I think the naturalness arises not from mere familiarity/relation to those other languages, but from the presence of pattern matching/destructuring within those languages. In other words, because Haskell has record destructuring in pattern matches, the expression syntax makes sense (to me). Because Rust has destructuring pattern matches, this syntax makes sense to me in Rust.

@nrc The ambiguity has to do with expressions followed by {, which was solved at the grammar level.
That is, we tell for _ in S { x: y } (type ascription) and for _ in (S { x: y }) {} (struct) apart.

Other than the clash with type ascription, I don't like this:

it is sugar that doesn't save very much - a little bit of typing maybe, I don't think it makes things easier to read, only to write
it weakens the correspondence between struct declaration and construction
it encourages local variables to have more generic names to use this sugar, rather than more descriptive names
it doesn't save any typing relative to the common constructor pattern for structs (i.e., using a new function).
it confuses actual with formal arguments, which is one of the harder concepts for beginner programmers to grasp. I believe blurring the boundaries like this makes that confusion worse (note that the pattern equivalent is categorically different in this respect).

@jirutka Sorry for the confusion! No harm done, but I'll try to use clearer language in the future.

@eddyb that is not what I meant, I am talking about a struct initialiser expression rather than the pattern/block ambiguity. E.g., let x = S { a: b };. I guess the parser never treats this as the field sugar because it is not a single expression.
Then let me call this potentially confusing syntax for the user, rather than a technical parser ambiguity.

@nrc The sugar isn't about "single-expression" but a simple identifier, any other expressions would be invalid.

er, sorry I meant variable, not expression

@nrc - some good points.  Responding "inline"
"it is sugar that doesn't save very much - a little bit of typing maybe, I don't think it makes things easier to read, only to write"
That was my first reaction when I started using it in ES6, but I found it actually to be pretty wrist-friendly.  Often I would set up something so I could build an object out of it only to have to repeat myself.  It's not a large ergonomic change, but a small one that accrues value over time.
"it weakens the correspondence between struct declaration and construction"
I think this is similar to @ubsan's claim.  This may be true for a subset of developers.
"it encourages local variables to have more generic names to use this sugar, rather than more descriptive names"
Hehe, better than using x and y for everything :)  At least naming them what your field name is it's very clear what the purpose is.
"it doesn't save any typing relative to the common constructor pattern for structs (i.e., using a new function)."
This is true.  For Rust it might have less overall impact than the equivalent JS.  It may, however, swing the pendulum a little for people making lighter-weight structs to prefer the smaller syntax.
"it confuses actual with formal arguments, which is one of the harder concepts for beginner programmers to grasp. I believe blurring the boundaries like this makes that confusion worse (note that the pattern equivalent is categorically different in this respect)."
Yeah, I can see that.  Though I'd probably add here that this is a convenience likely to be used by more advanced users.

This RFC is missing a section on proposed changes to the grammar.

I consider the type ascription ambiguity the best argument against this RFC. I don't feel any of @nrc's other points are particularly strong.
For example, I wouldn't worry about encouraging changing local variable names to use this syntax - I think it would just serve to abbreviate the Foo { a: a, b: b } code I already see everywhere today.

@jonathandturner

"it weakens the correspondence between struct declaration and construction"
I think this is similar to @ubsan's claim. This may be true for a subset of developers.

I mean that this is a principle of Rust language design and this RFC goes against it. That is a universal truth, not just true for some subset. Whether it is an important principle can of course be argued, and all principles should be broken sometimes.

"it doesn't save any typing relative to the common constructor pattern for structs (i.e., using a new function)."

This is true. For Rust it might have less overall impact than the equivalent JS. It may, however, swing the pendulum a little for people making lighter-weight structs to prefer the smaller syntax.

I usually make ctors for even the smallest structs, for this use case, I think #[derive(new)] is a possible alternative to this proposal.

"it confuses actual with formal arguments, which is one of the harder concepts for beginner programmers to grasp. I believe blurring the boundaries like this makes that confusion worse (note that the pattern equivalent is categorically different in this respect)."
Yeah, I can see that. Though I'd probably add here that this is a convenience likely to be used by more advanced users.

I'd be worried about code written by advanced users and read by new users.

On a second look, I was a bit confused about the confusion! It now occurs to me that the similarity between x: y in structs and in type ascription is an existing problem, and the proposed Foo { x, y } shorthand has even less syntactical similarity to type ascription.

yeah, @eddyb mentioned on irc, that any confusion is already there due to the existing syntax, so I retract my complaint about confusion.

Welp, time to add to the bikeshed. Nix has special syntax for this.
{x = x; y = y; z = q;} is the same as {inherit x, y; z = q;}
I'd think if we went with that approach in Rust, we'd want to re-use the use keyword.
In any case, something to add to the alternatives.

I believe this RFC has come up one or two times before, but I thought the conclusion was that it leads to a parser ambiguity?
For example:
if foo { x } { y }

Should we parse this as:
if (foo { x }) { y }

or
if (foo) { x }
{ y }

(@Havvy, I'd like to accept your PR, but I just made some changes. If you want to rebase and fit it in to the sigil section, that'd be great!)

@alexcrichton, I see discussion about parser ambiguity here, and what I think is a disambiguating change here.

@alexcrichton I think the current parser already decides to the latter as soon as it sees the {.
Consider this existing problem on nightly:
if foo { x: a } { y }

Is it this?
if (foo { x: a }) { y } // A struct foo

Or this?
if (foo) { x: a } // A path expression `x` inside a type ascription
{ y }

We currently choose the latter.

Aha, indeed! For reference, here's some old RFCs related to this same topic:

https://github.com/rust-lang/rfcs/pull/866
https://github.com/rust-lang/rfcs/pull/841
https://github.com/rust-lang/rfcs/pull/343

One clarification here: this shorthand does not allow an arbitrary expression, qualifier, ascription, or anything other than an ident.
I'd appreciate advice on the appropriate syntax for the grammar changes from someone more familiar with Rust's grammar.  Does someone have a link for an RFC that specifically describes grammar changes in precise terms, rather than by examples as we did?

I personally have found myself looking for this feature since the equivalent pattern syntax was allowed: It seems natural to be able to do something like:
let MyType{ mut x, mut y, mut z } = function_returning_mytype();
// do things to x, y, and z
function_taking_mytype(MyType{ x, y, z});
// instead of:
function_taking_mytype(MyType{ x: x, y: y, z: z});

and it's always felt like an incongruity that I can't. Real types tend to have more meaningful names than x, y, and z, and I do tend to already name my local variables after the field names. This pattern is especially common in MyType::new() functions, which take more than a line to set up. I have a ton of new functions which look like this:
impl MyType {
    fn new() -> MyType {
        let x = get_x_initial_value();
        let y = get_y_initial_value();
        let z = get_z_initial_value();
        MyType{ x: x, y: y, z: z }
    }
}

This post will count for nothing, but -1 for me.
Any change that adds a new syntax to the language also adds bloating and brings a little bit closer to a monstrosity. This change doesn't have a big enough benefit to overcome this.

I like the symmetry with patterns. We could go with one of the alternatives but then that should be made a valid pattern (and what we currently have be deprecated) for consistency.

The lack of this sugar is one of two1 reasons making struct variants less convenient than tuple variants.
Look at this for example: https://github.com/rust-lang/rust/blob/48c245411b4a550bfe68e1a3eb703e8a22926402/src/librustc/hir/def.rs#L28
Variant(DefId /* enum */, DefId /* variant */), // <- field names in comments? seriously?

it would be much nicer to rewrite this as
Variant {
    def_id: DefId,
    enum_def_id: DefId,
}

but ergonomics suffer.
Patterns stay short due to the existing shortcut:
Variant(enum_def_id, def_id) => Variant{enum_def_id, def_id},
but expressions turn into horror:
Variant(enum_def_id, def_id) => Variant{enum_def_id: enum_def_id, def_id: def_id}.
With this sugar extended to expressions variants with named fields, which are more expressive than tuple variants, could be used more often.
1 The second reason is "spacey" formatting used for struct literals S { .. } by rustfmt and by convention, as opposed to "tight" formatting for tuple structs S(..).

If anybody is bored, I'd be interested in knowing how many struct literals (percentage wise) actually could be made shorter using struct field punning (on crates.io), and how many of those only structs have ever field punnable.

I'd appreciate advice on the appropriate syntax for the grammar changes from someone more familiar with Rust's grammar. Does someone have a link for an RFC that specifically describes grammar changes in precise terms, rather than by examples as we did?

This section is an okay example of such description. Ideally, the description would be something based on src/grammar/parser-lalr.y, so it would be trivial to run this through yacc or similar tool, but a more abstract grammar syntax (as used in the linked RFC) is also fine.

I often encounter the problem this RFC is meant to solve but I also disagree with the solution because of ambiguity, not just in parsing but also when reading the code. I personally would prefer the syntax proposed by @jirutka, or a variation on it.
S { :foobar }

A suggested variation, taking _ which is already assumed to mean "infer this":
S { _: foobar }

@LaylConway Can you explain what you feel is ambiguous about it? First of all, there's no ambiguity in parsing that's not already handled, so it's actually only in reading the code, but I'm still curious.
I think it would be much worse to not match the established pattern shorthand syntax.

@solson S { x, y } to me feels very ambiguous to read with S(x, y) and S { x } feels ambiguous to just { x }. It doesn't look like a struct field being assigned, is my main problem with it.

@LaylConway _ typically means "ignore this", not "infer this"; I'd find that syntax very confusing.

This has come up before. It does me a "squiggly" feeling for the reasons (I suspect) that @nrc raises, but overall I find I want it pretty regularly, particularly since it works with patterns.

I'm 👍 on this feature -- it's something I used very regularly when working with Standard ML. As many have noted, we already have this feature at the destructuring level (pattern matching), and it's odd that the two aren't in better alignment. (I could see the complexity argument a bit more if we didn't already have this support.)
I often wind up introducing bindings with the same name as struct fields and writing MyStruct { myfield: myfield, otherfield: otherfield } always grates a little bit. And while constructors are fairly common for important public data types, I frequently have fairly large, private struct definitions, where this feature would come in handy.
Yes, it's a relatively small ergonomic point, but in general we suffer from many such paper cuts (which add up over time), and this is a particularly cheap one to eliminate.

I've pushed a subsection on proposed changes to the grammar (thanks for the reminder and references, @nagisa).

Good candidate for an "Obfuscated Rust Contest".

(I'm not too experienced in Rust, so take this with a grain of salt.) It might address the concern raised by @ubsan if, rather than requiring ':' or other extra notation, we were to require that the named fields be provided in the same order as in the struct definition. So there's a positional requirement in addition to the requirement that the variable names match the field names; a non-positional use is at least a warning, possibly an error.  The positional requirement is intended only for the shorthand syntax proposed in the RFC, of course.
If it is feasible to implement this -- and if the mismatch with the existing pattern syntax is acceptable -- then this would prevent the ugly surprise of your Foo { y, x } being interpreted as Foo { x, y }.
It's similar to the C++ behavior for constructor initializer order, for what that's worth.

@zdanz Position requirements make less sense when you consider cases like Foo { a, c, d, ..old_foo } where Foo has fields a, b, c, d, and e, so b and e are coming from old_foo. From a positional standpoint it looks like c is in b's place and d is in c's place, but of course they aren't because struct initialization simply is not positional in Rust.
It also wouldn't match patterns, where no such ordering requirement exists.

I'm always running into this and wishing there was a shorthand. I think the ambiguity issue isn't a huge deal when compared with the exact same feature in pattern matching.

@solson Thanks for the great example.  I'm still a bit concerned that someone coming from C might be surprised (and have a hard time tracking down the places where they had messed up, once they realize how the shorthand syntax works); but I agree that an ordering requirement has serious problems.

Another reason to dislike this proposal is that it makes refactoring harder (I wonder if it might also frustrate other tools, but I admit that I can't think of any examples).

@nrc

Another reason to dislike this proposal is that it makes refactoring harder

Can you elaborate a bit? I can see that it would make refactoring tools a bit harder to write, but it doesn't seem like they should be a lot harder -- you could imagine (for example) "desugaring" foo, into foo: foo, and then, if that is still present at the end, collapsing it, etc.

Can you elaborate a bit?

I'm not saying it makes things impossible, but it does make them more complex.
If you rename a local variable, it means you have to check for field puns, and if so either rename the field (which could trigger more renamings due to other puns) or reject the refactoring or desugar.
If you rename a field, you have to check for field puns (easier than the above though) and rename the local var or reject the refactoring or desugar, note that renaming the local var might fail, and thus the whole refactoring should fail.
And if you rename a field or local variable so that punning is possible, should the tool then add the sugar?
Whilst all this is tractable, it is really piling on the options/complexity for what should be a very simple operation (indicative, I think, of the cognitive complexity that this feature would add, despite being superficially simple).

I don't believe this materially adds too much complexity to refactoring.  Yes, we would need to pay attention to possible problems when supporting things like rename/refactor.  I imagine that if we rename the field bar to baz it would turn this:
Foo { bar }

into this:
Foo { baz: bar }

Expanding the pun and focusing on just the field.  C# refactoring tools have to handle cases like this, as one example.

This problem already exists with patterns, of course. @jonathandturner's example would apply in the same way to fixing up patterns after a rename and all of @nrc's questions apply to existing Rust code that has these patterns. We'll have to come up with answers to these questions regardless of this RFC, but those answers will apply here, too.

I am personally :+1: on this, especially with what @aturon said

As many have noted, we already have this feature at the destructuring level (pattern matching), and it's odd that the two aren't in better alignment. (I could see the complexity argument a bit more if we didn't already have this support.)

I've also found this a bit weird.

I think I've changed my mind on this RFC. It took a while, but... it does make sense, and that is annoying.

@nrc I agree with @jonathandturner that, while its true that refactoring tools would have to consider this feature, it doesn't seem overly complex. I would imagine they would just desugar all field puns and then reapply them if they are still relevant.

Here's the macro. (I support this RFC though!)

Given that I was just contemplating re-addressing this idea (since it was previously rejected on now-irrelevant issue with parsing), I support it.
Remember that while the value seems low when the examples are like this:
Foo {x: x, y: y}
// vs.
Foo { x, y}

The appeal is more obvious when you look at a more realistic example:
Header { id: id, message_type: message_type, op_code: op_code, authoritative: authoritative,
    truncation: truncation, recursion_desired: recursion_desired,
    recursion_available: recursion_available,
    authentic_data: authentic_data, checking_disabled: checking_disabled,
    response_code: response_code,
    query_count: query_count, answer_count: answer_count,
    name_server_count: name_server_count, additional_count: additional_count
  }
// vs.
Header { id, message_type, op_code, authoritative,
    truncation, recursion_desired,
    recursion_available,
    authentic_data, checking_disabled,
    response_code,
    query_count, answer_count,
    name_server_count, additional_count
  }

Taken from this post

This is the bike-sheddiest of bikesheds, but is there a possibility of working on the naming of this RFC / PR / eventual feature-flag? "Named field puns" doesn't really resonate with me, although I think I get the compiler historical naming. Looks like ES6 calls this "property value shorthand", so maybe we should co-opt something like "field value shorthand" or "struct literal shorthand"?
The thing that makes this not 100% bikeshed is that we will have to document this feature somehow.

@shepmaster, I think I agree. In terms of the Rust grammar, we're providing a shorthand for field initializations, so maybe "field initialization shorthand"?

field initialization shorthand

This sounds good to me; is there any other "field initialization" that this could potentially mentally conflict with?

@shepmaster I'm completely OK with changing the name; the name we proposed came entirely from the Haskell "NamedFieldPuns" extension.
field-init-shorthand seems appropriate.  (I don't think we should call it "struct" anything, because it applies to structs, unions, and struct-like enums.)

Agree w/ @joshtriplett both re avoiding struct in the name (for the reasons he stated), and in the more concise field-init-shorthand.

I hereby propose moving to FCP for merging:
@rfcbot fcp merge
I've re-read the discussion, and to briefly summarize:

Quite a few participants mention running into a desire for this feature previously, or using other languages that have it.
The main argument against appears to be that, as a piece of syntactic sugar, it doesn't carry its weight.

This was particularly well-articulated by @nrc's comment, which talks about the blurring between "formal" and "actual" parameters going on here.

A partial counter-argument is that this feature essentially already exists for destructuring, which means we've bought into the complexity anyway, and the lack of symmetry here can be seen as a kind of "corner" in the language that introduces its own complexity.
There's been some amount of discussion around alternative syntaxes, which is summarized in the RFC, but the connection to the destructing syntax basically forces our hand here.

Lang team, if I've missed any issues that might be a blocking objection, or if you don't buy the overall argument, please raise a concern with @rfcbot!

I'm still not at all happy about this proposal. It still feels very wrong to me. I'm not going to try to block consensus on it, but I'll make my case one last time:

I think the benefit is small and poorly conceived: this saves you a little typing and no thinking - I prefer sugar that buys us something in terms of 'real effort' rather than just typing. Furthermore (and importantly IMO), if it does save you a substantial amount of typing, then I think that that is a 'code smell' that you should be using a constructor function instead of a struct literal.

I do not think that the rules for patterns should be counted as motivation. Whilst we strive for symmetry between declaration, literal syntax, and destructuring, we allow an awful lot more 'stuff' in patterns than we do elsewhere - .., _, @, ref, and so forth. We also (significantly) allow binding to variables in ways that are not allowed in initialisation.

Most importantly to me (and I'm having trouble articulating this, so apologies in advance for rambling) is that this makes the names of variables significant to the semantics of programs in an entirely new way. The name of a variable should be something completely separate from its semantics. It is just an identifier which is erased at runtime, a convenience for labelling a stack offset with purely documentational benefit for the programmer. This feature asks the programmer to make a trade-off - should they choose a name which allows for more succinct struct initialisation or one which provides better documentation? It means that how a variable behaves in an expression depends on its name, not its type, not its value, and that feels wrong.

Small example of why this feels wrong - it doesn't work if you want to use one variable to initialise different fields, and yet there is nothing different about the variable itself or the semantics of the fields (move vs copy, etc.).

Another small example of why this feels wrong - if you refactor to using a ctor function, the names no longer have significance and the order does - we change from one implicit scheme to another implicit scheme. I imagine this would have ramifications too for named keyword arguments and their analogy with struct fields, something which I think is a much more important bit of syntax sugar.

I believe this is fundamentally different from punning on binding. That feels like a predictable effect of destructuring - we are binding fresh variables based on the target of destructuring. We are just copying a name, we are not making the compiler match names of two existing entities.

I have hygiene concerns - it doesn't really make sense to ever say two things have the same name. Note that the fields and variables are defined in different scopes so they have different hygienic characteristics - you can't make 'name equality' here mean hygienic equality. Totally unhygienic equality is possible, but has obvious issues. A less obvious issue is that a macro might introduce a name which without hygiene would shadow an earlier declaration, and that shadowing would only show up here:

macro_rules! foo {
    () => { let x = 42; }
}

struct Bar {
    x: i32,
}

fn main() {
    let x = 0;
    foo!();
    let b = Bar { x };
    println!("x: {}, b.x: {}", x, b.x);
    // prints `x: 0, b.x: 42`
}

It is possible that we could define name equality that works around hygiene (i.e., neither completely hygienic, nor completely unhygienic comparison) but I don't know what that would look like and it would have to be (I think) independent of the hygiene algorithm to some extent (i.e., it should work with at least MTWT and sets of scopes).

Oh
@rfcbot concern hygiene
I think that is the only concrete-enough point I have that needs addressing before (if) we accept.

I would expect b.x to be 0, not 42. After all, this should be equivalent to doing Bar{ x: x }

@nrc
Matching the name with the name of the struct is a type-directed lookup operation, which never uses hygiene, just like struct patterns.
I don't think constructors are a satisfying enough replacement - they force you to pick a particular order of parameters, which is annoying (slightly "in the small", much worse in "configuration structs" with dozens of fields).
The concern about this being confusing with named parameters (will foo put foo in the next parameter or in the parameter named foo) seems real. I'm not sure enough about our named parameter story to know how much it would hurt (e.g. if we allow type inference in struct expressions and have .. translate to Default::default(), then it would fit just right).

@nrc With respect to hygiene, a couple of thoughts:

First, my expectation is that this is the purest of syntactic sugar: we could implement this entirely in the parser, if we wanted to, by parsing Foo { x } exactly as if the user had typed Foo { x: x }. Since the user can always type this, it should interact with hygiene in precisely the same way.

At present, we don't apply hygiene (afaik) to field names, do we? This is not to say we shouldn't, but it's somewhat complicated, since the lookup of fields is type-directed, no?

I forget -- Have you tried to express what Rust hygiene would look like in terms of sets-of-scopes? Since we don't have hygiene in fields presently afaik, it'd be helpful to have some more concrete notion of what you imagine the semantics ought to be.

I think the benefit is small and poorly conceived:

I think this is one of the small kinds of quality-of-life improvements you don't realize you enjoy until you're used to it. I'm constantly forgetting that Rust doesn't do this, and it feels boring and repetitive to type out: why am I doing something that the compiler can just do for me.
FWIW,

by parsing Foo { x } exactly as if the user had typed Foo { x: x }.

is exactly the behavior I'd expect.

First, my expectation is that this is the purest of syntactic sugar: we could implement this entirely in the parser, if we wanted to, by parsing Foo { x } exactly as if the user had typed Foo { x: x }. Since the user can always type this, it should interact with hygiene in precisely the same way.

This makes sense, I assume the desugaring would happen in the HIR lowering (with most others) and we would copy the hygienic identifer, rather than trying to match names.
@rfcbot resolved hygiene

At present, we don't apply hygiene (afaik) to field names, do we? This is not to say we shouldn't, but it's somewhat complicated, since the lookup of fields is type-directed, no?

Correct, and it is one area where I'm not sure what the long-term picture should look like exactly. However, it is not too important - my concern is with the hygiene of the local variable name, not the field name.

I  forget -- Have you tried to express what Rust hygiene would look like in terms of sets-of-scopes? Since we don't have hygiene in fields presently afaik, it'd be helpful to have some more concrete notion of what you imagine the semantics ought to be.

I have, but like I said, I don't think the field name hygiene is the issue so I don't this would help.

I'm constantly forgetting that Rust doesn't do this, and it feels boring and repetitive to type out

I guess I very, very rarely have this experience - I nearly always use a ctor function for every struct, and when I don't I don't instantiate fields with just variables. The only time I hit this is in ctor functions themselves (or sometimes Builder methods), where I'd rather address this with tooling (a good IDE could generate the boilerplate with a click) or derive(new) rather than with a language feature.

why am I doing something that the compiler can just do for me

There is lots of stuff the compiler could just do - global type inference or spelling correction or implicit coercion, there's always a trade-off. Whilst I admit that this feature is not very costly, I don't agree that it is much of a benefit. And it does have costs - incentivising poor variable names, for example.

This makes sense, I assume the desugaring would happen in the HIR lowering (with most others) and we would copy the hygienic identifer, rather than trying to match names.

Except that's not the case for pattern shorthands.

@nrc I'd certainly love to see derive(new) for constructors, and perhaps a macro library that supports creating a builder more easily as well.  I'd also like to see named function arguments, particularly for constructors; however, that'd quickly lead to this same issue.

incentivising poor variable names, for example.

Are they poor names? They're only poor names if your struct fields have poor names.

Are they poor names? They're only poor names if your struct fields have poor names.

I don't think this is true - I think it is perfectly possible to have a good field name be a poor name for a local variable

I don't think this is true - I think it is perfectly possible to have a good field name be a poor name for a local variable

Then use a local variable with a good name and use normal syntax to set the struct field. It shouldn't impact readability too sharply, especially with correct use of scopes.

Then use a local variable with a good name and use normal syntax to set the struct field. It shouldn't impact readability too sharply, especially with correct use of scopes.

Of course you can do this, but the point is that the ergonomics incentivise against doing the right thing.

I'm checking off on this because I don't object strongly enough to try and block the feature (I don't think anything actually bad will happen because of it, just that I think the cons outweigh the pros). Let it be known that I still do not like it.

@eddyb

Except that's not the case for pattern shorthands.

I'm not quite sure what you are saying here. Are you saying that pattern shorthands today interact with hygiene in some complex way? Or just that the lowering doesn't happen when building HIR in particular? (I agree with @nrc that this would be a logical time to do it, regardless of what we do now.)

@nikomatsakis The latter, as you can see in the comment I linked. Of course that with HIR we may just
opt to move the lowering there, but struct pattern shorthands don't have a hygiene problem so doing exactly what they do for struct literal shorthands (i.e. expand in the parser) would work fine with hygiene.

Not sure there's any point in commenting on this now since all the subteam members have voted to merge, but I agree totally with @nrc's viewpoint. This is a totally unnecessary thing to have language-level support for.

@aturon, @nikomatsakis, I have a meta question. We're in the FCP period, but given the discussion concluding here, it looks like there's agreement to rename the feature to field-init-shorthand. Will pushing a commit to do so (at least in the RFC document, if not the branch name) disrupt the RFC procedure or supporting tooling?

@nrc
Thanks much for pushing to articulate your concerns. I think I can understand your general queasiness, but for me, thinking of as pure shorthand at the parsing level (as @nikomatsakis suggests) basically feels right, and largely settles this question. It's also noteworthy that Standard ML -- a very conservative and mathematically modeled and designed language -- has this feature.
I'll just add as a final note that the places where I've wanted this feature tend to involve relatively large structs that are purely for internal use, where I don't want to write a constructor.
Often the field name is something like token, of type Token, where I pretty consistently am using variables called token to talk about the current instance. IOW, I find that I already tend to match names up to aid readability, even though this shorthand doesn't yet exist. While it's possible that adding the shorthand could incentivize poor naming choices, I feel like in general people are (or should be) more careful about the name of struct fields than the name of particular variables.
Refactoring to use a constructor is indeed an interesting potential pitfall, though I think it's worst when you were punning all the names. It doesn't feel like enough of an issue to block the feature, though.

@ranweiler you can change the name of the feature, I don't think that disturbs the FCP period. =)

@jimmycuadra

Not sure there's any point in commenting on this now since all the subteam members have voted to merge

To be clear, we've recently moved to a system, with @rfcbot, where everyone on the subteam signs off on going into FCP with a particular disposition. Previously, it was too easy for some team members to only evaluate carefully during FCP, which was not ideal.
So, at this point the RFC is ready to go into FCP, but that still leaves another week for final community discussion, which can raise new issues.

:bell: This RFC is entering its final comment period :bell:

Just my 5 cents.
I see that this particular feature will be possibly considered a "code smell" and then lint will be added to mark it. Thus, is there any sense in adding something which will be considered a code smell?

@target-san I consider the foo: foo pattern a code smell, I see it quite a lot in Rust code, and this feature solves it cleanly. The majority consensus seems to be that this feature will make code better, not worse.

@solson I just really don't like possible gotchas with things like Vector { z, y, x } - which happen in C++ as an example.

@target-san { z, y, x } is quite different between C++ and Rust.
I can see why coming from C++ you may be wary of this, because in C++ the curly brace expressions are always positional, so things like int foo[] { 1, 2, 3 }; are placed by order of appearance.
But in Rust, curly-braces-with-commas always means non-positional, name-based associations. For example, you can have a struct struct Foo { x: i32, y: i32, z: i32 } and initialize in a different order with Foo { z: 10, y: 5, x: 0 } or pattern match with Foo { y, x, z } even today. What we pay attention to is the names, and the order has no bearing.
When you look at it this way, there really is no gotcha. It's consistent with the rest of Rust.

I think @target-san's example is interesting, as it is a case where using a struct expression (vs. a ctor) excludes certain errors (if you are already using a certain pattern).
Suppose we have something like:
struct Vector {
    x: f64,
    y: f64,
    z: f64,
}

impl Vector {
    fn new(x: f64, y: f64, z: f64) {
        Vector { x: x, y: y, z: z }
    }
}

Then lets say I'm using Vector in this context:
// The function calls here are meant to indicate "doing a bunch of complicated work"
let x = f();
let y = g();
let z = h();

let v = _  // we want build a `Vector` here, where the field names should match the local var names

What are the ways I can construct v from x, y, and z?
If I use the ctor, I can make a typesafe error like:
// Permuting arguments
let v = Vector::new(x, z, y);

or:
// Repetition of an argument
let v = Vector::new(x, y, y);

Similarly, if I use a struct literal without shorthand notation, I can make (essentially) the same errors:
let v = Vector { x: x, y: z, z: y };

or maybe a more likely typo:
let v = Vector { x: x, y: y, z: y };

But, if I was already doing some work earlier to come up with x, y, and z vars that ought to correspond to the fields of the same name, I can't make the permutation error with shorthand notation, since the following are equivalent:
Vector { x, y, z };

Vector { y, z, x };

Vector { z, x, y };

(and so on for all permutations of the field labels).
For the repetition error, with this proposal, the expression
Vector { x, y, y }

would expand to:
Vector { x: x, y: y, y: y }

which would fail to compile with the existing error:
error[E0062]: field `y` specified more than once
  --> src/lib.rs:12:34
   |
12 |     let v = Vector { x: x, y: y, y: y };
   |                            ----  ^ used more than once
   |                            |
   |                            first use of `y`

error: aborting due to previous error

Is this a colossal win? Not really, and in many (most?) cases, we want to hide struct fields and mediate all access to them with a ctor/methods, which means the syntax doesn't help end-users of Vector (just us, when writing its impl).
Also, this is only relevant in the setting where we are already (as humans) building up values named x, y, and z that are implicitly meant to match the field names of Vector. As @nrc very sharply pointed out, switching to a ctor (where order matters, not name) isn't really any worse, since we are switching from "one implicit scheme to another implicit scheme". For me, the local var name implicit scheme is common enough (even when I have a ctor!) to favor adding sugar to support it.
If this discussion surfaced gotchas that were worse than what we gain, I'd oppose this sugar (even though I co-proposed it!). But, I think it is conservative enough to provide a small net benefit here and there, including extra static safety in certain contexts.

What happens when I use a contextual keyword?
let union = ...;
struct with { some: String, locals: String } // knowing this name would riese a warning
Foo {
    union, with { some, locals }
}

Will this error or guess what is right

@dns2utf8 I don't see any conflicts there. You can't declare a union inside
a struct initializer.
On Wed, Oct 19, 2016 at 6:41 PM, dns2utf8<EMAIL_ADDRESS>wrote:

What happens when I use a contextual keyword?
let union = ...;
struct with { some: String, locals: String } // knowing this name would riese a warning
Foo {
union, with { some, locals }
}
Will this error or guess what is right
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1682#issuecomment-254962098, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC3n8mHo8tsoFN9LWxukaGRtcWtosPeks5q1pyigaJpZM4JP7RN
.

RFC merged. Further discussion should happen on the tracking issue.


Adjust formatting and Add UML descriptions

I realise the screenshots in the User Guide are of an odd size and have a black background for some reason even if the images on my local folder don't. But I think since the GUI is gonna change soon, we can update the screenshots later..

Will convert the UG and DG to PDF and submit for CS2101 once this PR is merged


Add function to convert a PlutusData object into a Plutus Blueprint Schema

As part of https://github.com/OpShin/opshin/issues/57, OpShin will have to convert PlutusData-ish arguments to smart contracts into the Plutus Blueprint Schema (CIP 57). Since this utility seems useful outside of OpShin, I propose to add the function here.

Codecov Report

Merging #276 (140873a) into main (af8afdc) will increase coverage by 0.04%.
The diff coverage is 91.30%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##             main     #276      +/-   ##
==========================================
+ Coverage   84.74%   84.78%   +0.04%
==========================================
  Files          26       26
  Lines        3067     3090      +23
  Branches      750      760      +10
==========================================
+ Hits         2599     2620      +21
- Misses        350      351       +1
- Partials      118      119       +1

Files
Coverage Δ

pycardano/plutus.py
87.04% <91.30%> (+0.35%)
:arrow_up:

Closing this since the necessary function was simply implemented as part of https://github.com/OpShin/opshin/pull/279 in OpShin - together with loading of blueprints and also handling the remaining contract-related parts.


Expose getter for ApolloClient.serverUrl

Is your feature request related to a problem? Please describe.
no
Describe the solution you'd like
I would like a simple public getter for ApolloClient.serverUrl. There are times where I need to rebuild the client when the serverUrl changes (our app supports dynamic URLs). But I would like to know what the "current" url is before I decide to re-build. Example
val initialApolloClient = ApolloClient.builder()
        .serverUrl("some URL")
        .build()

// ...some time later
val newClient = if (initialApolloClient.serverUrl == "some new URL") {
    // URLs changed, rebuild
     ApolloClient.builder()
            .serverUrl("some new URL")
            .build()
} else {
    // nothing changed, use initial client
    initialApolloClient
}

Definitely a fair request. We can actually expose more.
Would it be also useful to expose newBuilder function which will create a builder where you can create a new instance with serverUrl (or any other prop) modified. OkHttp has this option.

ohh yeah. good idea. You're thinking farther ahead than I am =)

Merged and will be released with version 1.4.0


Melt/update large stride tests

I have created a new program for the forpy large stride test and modified the existing torch (directly coupled) program to be consistent.
They both generate a random N X N matrix/tensor and run the same forward model.
The output is checked using an assert
Timings of the two programs are printed to stdout
Some useful helper functions have been moved into a separate modulebenchmarker_utils.f90 so they can be used in both programs.
I have also updated the CMake to be a bit more general.
added test results of forpy/torch comparison
added description of large_stride tests and how to compile/run

I've checked this out, built, and run. I would suggest not adding the saved_model.pth model as it's a binary, so may well need to be generated by the user for their system using pt2ts.py instead.

Yes, I agree. It was already committed to the repo (perhaps a hackathon time constraint). I don't think it should be there either. But I thought since it was I would update it :) We can remove but it will be a pain... we might be better off creating a new repo but I don't mind either way.

I also note you build with Debug in the instructions. Since end users will be building with Release I tried this, and the two methods become comparable with direct coupling arguably taking a bit longer :/ Furthermore, all runs return FAILED
Building with
cmake -DCMAKE_Fortran_COMPILER=ifort -DFTorch_DIR=~/testfplib/lib64/cmake/ -DCMAKE_BUILD_TYPE=Release -DUSETS=1 ..

yields
(torchvenv) [jwa34@login-q-2 buildTom]$ ./benchmarker_large_stride_forpy ../stridemodel run_emulator_stride 10 512
 ====== FORPY ======
Running model: ../stridemodel/run_emulator_stride 10 times.
 load torchscript model
FAILED :: [check iteration        1 (     2.635 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        2 (     1.691 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        3 (     1.696 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        4 (     1.694 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        5 (     1.688 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        6 (     1.691 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        7 (     1.681 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        8 (     1.690 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        9 (     1.682 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration       10 (     1.682 s)] maximum relative error =  0.1788E-06
 min  time taken (s):    1.681366
 max  time taken (s):    2.635299
 mean time taken (s):    1.782986
(torchvenv) [jwa34@login-q-2 buildTom]$ ./benchmarker_large_stride_torch ../stridemodel saved_model.pth 10 512
 ====== DIRECT COUPLED ======
Running model: ../stridemodel/saved_model.pth 10 times.
FAILED :: [check iteration        1 (     2.622 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        2 (     1.706 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        3 (     1.710 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        4 (     1.708 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        5 (     1.699 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        6 (     1.702 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        7 (     1.697 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        8 (     1.704 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration        9 (     1.695 s)] maximum relative error =  0.1788E-06
FAILED :: [check iteration       10 (     1.699 s)] maximum relative error =  0.1788E-06
 min  time taken (s):    1.694552
 max  time taken (s):    2.621942
 mean time taken (s):    1.794266

Can you check this?

Here are my thoughts:

I don't think it's an issue. I was perhaps a bit too strict when setting the default relative tolerance in assert_real_2d to rtol = 1e-10. Considering we are using floats and not doubles it would perhaps be better to change this to 1e-05 or something.
interestingly, gfortran :angel: doesn't suffer from this float error and so even in Release mode it produces near identical results.
you can check by adding an additional flag to the CMakeLists.txt that the error changes whether or not the fortran reals are double (-r8) or single (-r4). Obviously, we then send it to python/c++ anyway as floats so you will still get a rounding error.

elseif (CMAKE_Fortran_COMPILER_ID STREQUAL "Intel")
    set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fpp -warn all -r8")
endif()

Let me know what you think of this.

@jatkinson1000 I have just pushed a commit to increase the relative error tolerance so that the tests will pass. You can try them again now and it should run.
Although there is still the possibility I am missing something


OHLC Chart (not candlestick)

Is your feature request relasted to a problem? Please describe.
Candlestick charts are nice, but many find and OHLC chart easier to read for stock prices. Both is even better, so we can let the user of our app decide and flip back and forth.
Describe the solution you'd like
An OHLC chart type with optional log Y scale and volume pane
Describe alternatives you've considered
Syncfusion has it, but it is not open source
https://www.syncfusion.com/flutter-widgets/flutter-charts/chart-types/ohlc-chart
Additional context
It is likely this makes sense to add at the same time as a candlestick chart as they both would use the same sets of data. Only the rendering is different.

Hi. Thanks for your explanation. We will ask more about it when we start to implement it.
For now, I mark it as a new chart request.


feat: LDAP User default role

Pull Request Checklist
fixes #6943
Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.
Before submitting, make sure you've checked the following:

[x] Target branch: Please verify that the pull request targets the dev branch.
[x] Description: Provide a concise description of the changes made in this pull request.
[ ] Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
[ ] Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources?
[ ] Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?
[ ] Testing: Have you written and run sufficient tests for validating the changes?
[ ] Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
[ ] Prefix: To cleary categorize this pull request, prefix the pull request title, using one of the following:

BREAKING CHANGE: Significant changes that may affect compatibility
build: Changes that affect the build system or external dependencies
ci: Changes to our continuous integration processes or workflows
chore: Refactor, cleanup, or other non-functional code changes
docs: Documentation update or addition
feat: Introduces a new feature or enhancement to the codebase
fix: Bug fix or error correction
i18n: Internationalization or localization changes
perf: Performance improvement
refactor: Code restructuring for better maintainability, readability, or scalability
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
test: Adding missing tests or correcting existing tests
WIP: Work in progress, a temporary label for incomplete or ongoing work

Changelog Entry
Description
Fixes a bug. The LDAP auth user does not respect the default role in database.
Currently, the LDAP user is always be set to the role pending even the role user is set in web UI.
Added
Backend: Retrieve the role for LDAP user from config
Changed

[List any changes, updates, refactorings, or optimizations]

Deprecated

[List any deprecated functionality or features that have been removed]

Removed

[List any removed features, files, or functionalities]

Fixed

[List any fixes, corrections, or bug fixes]

Security

[List any new or updated security-related changes, including vulnerability fixes]

Breaking Changes

BREAKING CHANGE: [List any breaking changes affecting compatibility or functionality]

Additional Information
Related to #6743

@morgan55555 @tjbck @Xyz00777
Could you please help review this PR?

@tjbck
This pr fixes #6943.
And i notice the test is welcomed in this comment, https://github.com/open-webui/open-webui/pull/5056#issuecomment-2458738548
And it is tested locally.
Could you please tell us what else I need to do?
Thanks for your time.


Idk if this is really an error or something

I builded the file on my vm without anti vm enabled and then i opened the virus on that same vm and it didn't worked , the webhook didn't received any file or anything , is there an anti auto-grab ? Can't we grab ourself ?

We can grab ourself @Dev5un

But i can’t

It won’t work for some reasons

Can you test the debug mode, by setting the Console:debug button.

So the results?


Feature/athena integration

Pull Request Test Coverage Report for Build 525

0 of 0   changed or added relevant lines in 0 files are covered.
43 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.4%) to 70.488%

Files with Coverage Reduction
New Missed Lines
%

dist/plugins/Invocation.js
1
94.74%

dist/plugins/config/TraceConfig.js
8
75.0%

dist/plugins/integrations/AWSIntegration.js
34
72.52%

Totals

Change from base Build 522:
0.4%

Covered Lines:
2209

Relevant Lines:
2916

💛  - Coveralls

@hamitb can you resolve conflicts on package-lock.json


Add mechanism for annotating dispatches with optimization remarks.

It'd be useful to be able to easily identify optimization issues in runtime tools (nsight, tracy, perf, etc) when trying to triage performance on new inputs. Instead of having a dispatch_32_matmul that wasn't vectorized and needing to dig into the IR we could just name it dispatch_32_matmul_FAILED_VECTORIZATION (or whatever) and make it blindingly obvious. This doesn't scale to all kind of things but there are a few key paths that we know will cause performance issues. Changing symbol names immediately before executable serialization is pretty easy as all ordinals have been propagated to external code and doing so would just change the names used at runtime. Thinking of some hal.remark attr that could be added to entry points by codegen which then automatically gets merged in.

Interesting ideas! This feels similar in spirit to https://github.com/openxla/iree/issues/13207


use currentTarget to override delay

Hi @slavaGanzin @rlingineni, sorry for the delay.
You can now add data-long-press-delay to a parent element to set the application wide default:

    ...
    ...

Hope this helps


A document for Kuiper reserved keywords

A document summarizing all of reserved keywords in Kuiper.

Provided in this doc, so close the issue.


Remove unused condition on registerDevice()

In setUpNotification, before registering the device FCM token, a condition checks that the token expires before october 13th. This needs to be removed after the date.
See #172

Closed by #186


fix(drawer): screenshots use list

fixes https://github.com/material-components/material-components-web-react/issues/364

Codecov Report

Merging #432 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #432      +/-   ##
==========================================
+ Coverage   96.09%   96.14%   +0.04%
==========================================
  Files          53       55       +2
  Lines        1819     1841      +22
  Branches      214      214
==========================================
+ Hits         1748     1770      +22
  Misses         71       71

Impacted Files
Coverage Δ

packages/typography/typography.js
100% <100%> (ø)

packages/typography/index.js
100% <100%> (ø)

Continue to review full report at Codecov.

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

Closing as its almost 6 months


PowerShellOnTargetMachinesV3: Make 30 second delay while checking job status configurable

Required Information
Question, Bug, or Feature?
Type: Feature
Enter Task Name: PowerShellOnTargetMachinesV3
Environment
SF / releaseId=17078 & environmentId=83331
Private agent
Issue Description
Executing remote PowerShell on target machine V3 takes 33 seconds while the powershell script is normally finished in 3-5 seconds. Because the task depends on https://github.com/microsoft/azure-pipelines-extensions/blob/master/TaskModules/powershell/RemoteDeployer
See why here: https://github.com/microsoft/azure-pipelines-extensions/issues/632#issue-455174357
I'd rather have the Start-Sleep value configured, in ms, from this task which would require work on both repositories.
Task logs
2019-06-12T12:11:01.3753067Z VERBOSE: JobId: '2', JobState: 'running', ComputerName: 'otd0937-t.xxx.tld'
2019-06-12T12:11:01.3762516Z ================================================ otd0937-t.xxx.tld ================================================
2019-06-12T12:11:31.4202557Z VERBOSE: JobId: '2', JobState: 'completed', ComputerName: 'otd0937-t.xxx.tld'
2019-06-12T12:11:31.4203720Z ================================================ otd0937-t.xxx.tld ================================================

Troubleshooting
None
Error logs
None

closing this issue. Relevant PR: https://github.com/microsoft/azure-pipelines-tasks/pull/10661

Why is this issue closed?
I can see th PR lowering the start-sleep to 5 seconds. This issue request for making it configurable. Is that not happening with a specific reason?

@wgrthoen we do not think providing an extra input will be the right call here. Instead we are reducing the sleep time.

@argupta Is this available with Azure DevOps Server 2019.1?
Having updated we're getting version 3.1.2 of this task currently, while the updated version is 3.1.3?


Winbar flashes before being closed

Hi! I have set up simple winbar using heirline with fallback = false so I can disable it for certain buffer types or filetypes.
Generally it works except for one visual annoyance. When opening window matching first component group (as below) it has winbar set to some value before it gets set to nil, resulting in visual flash and then content shift. Is it something to do with my setup perhaps or can you reproduce?
My config is:
return {
  fallthrough = false,
  { -- Hide the winbar for special buffers
    condition = function()
      return conditions.buffer_matches {
        buftype = { 'nofile', 'prompt', 'help', 'quickfix' },
        filetype = { '^git.*', 'mail' },
      }
    end,
    init = function() vim.opt_local.winbar = nil end,
  },
  { FileNameBlock, Align, utils.insert(Diagnostics, Space), Git },
}

which then get passed as second argument of setup().

Have you tried setting up the auto command? see the example here

Thanks for coming back to me. Adding auto command does fix the issue. Wasn't really sure it was needed as doc says:

This can be accomplished directly by Heirline during component evaluation (see example below) and/or by defining your own autocommands somewhere else

so I assume that I am fulfilling that requirement (and/or) by having that fallback as in docs and above.
Could you please confirm that auto command is strictly necessary? Thanks!

Yes, the auto command is the preferred way, as it happens immediately when the winbar is set for the window. I will update the cookbook to make it clearer that the autocommand is non optional for optimal behaviour


fix page reload on enter

This makes it so pressing enter in the searchInput input no longer reloads the page.
The searchEnter function was already removed in #9.

This change (or equivalent) would be great, I frequently have to type my searches twice since the reload clears the search bar...


Swift 3.0 compatibility

[Current coverage][cc-pull] is 92.83%

No coverage report found for master at f84e0ea.

Powered by Codecov. Last updated by [f84e0ea...d340535][cc-compare]
[cc-base-branch]: https://codecov.io/gh/tomquist/ReverseJson/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/tomquist/ReverseJson/compare/f84e0eaa197782c474016c4ebb0e119d1338d826...d340535c6a68f1e5124a198447e5cdb3d8a9cabd
[cc-pull]: https://codecov.io/gh/tomquist/ReverseJson/pull/3?src=pr


Fee rate has too many decimal places

It doesn't make sense for fee rate to have more than 8 decimal places.

Fee Rate 	0.00029070080862533696 BTC per kB

Bitcoin is only divisible to satoshi, which is at the 8th decimal place.

Good point. We should probably do a Math.round() on that value.


Add skillSets during conversation

Currently CLOVA X support two skills:

shopping : 네이버 쇼핑
travel : 네이버 여행

It can easily set by adding skillSets parameters.
Raw web request example:
POST /api/v1/generate HTTP/2
Host: clova-x.naver.com
Cookie: [REDACTED]
Sec-Ch-Ua:
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.111 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryCnwBRysesplYkoV4
Accept: */*, text/event-stream
Sec-Ch-Ua-Platform: ""
Origin: https://clova-x.naver.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://clova-x.naver.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

------WebKitFormBoundaryCnwBRysesplYkoV4
Content-Disposition: form-data; name="form"; filename="blob"
Content-Type: application/json

{"text":"asdf","action":"new","skillSets":["shopping","travel"]}
------WebKitFormBoundaryCnwBRysesplYkoV4--

Related commit: https://github.com/mirusu400/CLOVA-X/commit/97cfa6c8f620abf17d427e22ad254ef68ee2d3a9


How can one test the prepend() method ?

I made a P.R. with a modification to the extension so that it uses the prepend() method of the extension to test the presence of a related configuration node for another bundle (SonataAdminBundle). Is it possible to test that with your library ?

I tested prepend() using this approach: https://github.com/alameda-red/DoctrineExtensionsBundle/blob/master/Tests/DependencyInjection/AlamedaDoctrineExtensionsExtensionTest.php

Sorry about the late reply. @zebba Looks good to me!
The example already looks quite good to me. Only problem is you have to keep repeating knowledge about kernel.bundles, registering extensions and fetching extension configs. So maybe this can be turned into something more generic. Do you have an idea for that already?

Closing this since there's no action required (if I understand correctly ;)).


Why is <x> extends infer X ? <y>: never so used in the codebase?

🤔 Question
Describe your question

Search tags, topics

I use this syntax to defer the evaluation of a type... Otherwise TS evaluates all the types in their full depth. This causes performance issues and is irrelevant because we only want to compute when we've received the type parameters. As a result, the ts-toolbelt types load fast.
But it is not the only use case. Like I said above, TS can complain that a type is too deep to compute, then you can force it to compute step by step. So I especially use this on recursive types (which are much deeper because they're recursive).
And one last reason is that it resets the type nesting count. TS also prevents to nest too many types, and throws errors when we do so. But since one of the goals of this lib is to combine types together, it is wise to reset that depth count (that is increased by the utility type itself).
In some cases it might not be wise to do this, as it can make TS swallow warnings. And this is the reason why ts-toolbelt is thoroughly tested and all the types are benchmarked (by me by hand, for now).

Can you add an example of real code from this project that does this to this wiki entry? It's hard to understand if/how x and X are related in your pseudocode <x> extends infer X ? <y>: never.

You can check this example out


Add Storage Class to Data Controller Create

Fixes #12170.

Pull Request Test Coverage Report for Build 247456789

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 39.091%

Totals

Change from base Build 247307224:
0.0%

Covered Lines:
19049

Relevant Lines:
44505

💛  - Coveralls


Downloading from YouTube fails with 'Rimon' ISP

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2017.01.29. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2017.01.29

Before submitting an issue make sure you have:

[x] At least skimmed through README and most notably FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add -v flag to your command line you run youtube-dl with, copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):
>youtube-dl -v --proxy "" --no-check-certificate https://w
ww.youtube.com/watch?v=SACeGmvxE1A
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-v', u'--proxy', u'', u'--no-check-certificate', u
'https://www.youtube.com/watch?v=SACeGmvxE1A']
[debug] Encodings: locale cp1255, fs mbcs, out cp862, pref cp1255
[debug] youtube-dl version 2017.01.29
[debug] Python version 2.7.9 - Windows-8-6.2.9200
[debug] exe versions: none
[debug] Proxy map: {}
[youtube] SACeGmvxE1A: Downloading webpage
[youtube] SACeGmvxE1A: Downloading video info webpage
[youtube] SACeGmvxE1A: Extracting video information
WARNING: unable to extract uploader nickname
[youtube] SACeGmvxE1A: Downloading embed webpage
[youtube] {22} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] SACeGmvxE1A: Downloading player https://s.ytimg.com/yts/jsbin/player-e
n_US-vflQBHHdn/base.js
[youtube] {43} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {18} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {36} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {17} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {137} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {248} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {136} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {247} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {135} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {244} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {134} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {243} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {133} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {242} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {160} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {278} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {140} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {171} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {249} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {250} signature length 44.40, html5 player en_US-vflQBHHdn
[youtube] {251} signature length 44.40, html5 player en_US-vflQBHHdn
[debug] Invoking downloader on u'https://r3---sn-gphvo-ua8e.googlevideo.com/vide
oplayback?ms=au&mv=m&initcwndbps=21143750&source=youtube&sparams=dur%2Cid%2Cinit
cwndbps%2Cip%2Cipbits%2Citag%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Cratebypass%
2Crequiressl%2Csource%2Cupn%2Cexpire&pl=24&dur=2646.563&mm=31&itag=22&mn=sn-gphv
o-ua8e&upn=8D1mRMidNmA&key=yt6&ipbits=0&mt=1485728424&expire=1485750133&id=o-AL-
8bcA5XMeISC6dZnFffjgAhbIZmleOMiEd7CtsjRvD&mime=video%2Fmp4&ratebypass=yes&requir
essl=yes&lmt=1472431379029221&ip=<IP_ADDRESS>&signature=5E61E6A46DA1636CFFAD5E
B5B5931605FE955934395.DFB731158B868A8DD4FD67DB61457FD8C0805E'
ERROR: unable to download video data: HTTP Error 403: Forbidden
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\youtube_dl\YoutubeDL.py", line 1699, in pr
ocess_info
    success = dl(filename, info_dict)
  File "C:\Python27\lib\site-packages\youtube_dl\YoutubeDL.py", line 1641, in dl

    return fd.download(name, info)
  File "C:\Python27\lib\site-packages\youtube_dl\downloader\common.py", line 353
, in download
    return self.real_download(filename, info_dict)
  File "C:\Python27\lib\site-packages\youtube_dl\downloader\http.py", line 61, i
---

### Description of your *issue*, suggested solution and other information

Hi.
My ISP (Israeli "Rimon") does content filtering and manipulates the HTTP(S) data.
It doesn't allow to watch some YouTube videos.
There are other YouTube videos, that I *can* watch (from Chrome, or other browser), but fail to download through `youtube-dl`.
When I connect to my work VPN (and therefore 'bypass' the ISP), I'm able to download these videos with `youtube-dl`.
(note: when connecting from work, I have to use proxy, which is configured with environment variables; when connecting from Rimon I have to disable that proxy)

Attaching 2 detailed log files, with HTTP traffic.
[work.traffic.txt](https://github.com/rg3/youtube-dl/files/737894/work.traffic.txt)
[rimon.traffic.txt](https://github.com/rg3/youtube-dl/files/737895/rimon.traffic.txt)

It's interesting to diff them.
There are some interesting differences that I don't understand...

Thanks!

So, can you watch https://www.youtube.com/watch?v=SACeGmvxE1A from Rimon in browser without any kind of anonymizing software/plugin enabled?

Yes.

What if you select different format with -f?

Seems similar.
C:\Users\zharamax\temp>youtube-dl -f worstaudio -v --proxy "" --no-check-certifi
cate https://www.youtube.com/watch?v=SACeGmvxE1A
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-f', u'worstaudio', u'-v', u'--proxy', u'', u'--no
-check-certificate', u'https://www.youtube.com/watch?v=SACeGmvxE1A']
[debug] Encodings: locale cp1255, fs mbcs, out cp862, pref cp1255
[debug] youtube-dl version 2017.01.29
[debug] Python version 2.7.9 - Windows-8-6.2.9200
[debug] exe versions: none
[debug] Proxy map: {}
[youtube] SACeGmvxE1A: Downloading webpage
[youtube] SACeGmvxE1A: Downloading video info webpage
[youtube] SACeGmvxE1A: Extracting video information
WARNING: unable to extract uploader nickname
[youtube] SACeGmvxE1A: Downloading embed webpage
[youtube] {22} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {43} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {18} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {36} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {17} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {137} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {248} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {136} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {247} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {135} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {244} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {134} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {243} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {133} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {242} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {160} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {278} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {140} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {171} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {249} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {250} signature length 40.40, html5 player en_US-vflQBHHdn
[youtube] {251} signature length 40.40, html5 player en_US-vflQBHHdn
[debug] Invoking downloader on u'https://r3---sn-gphvo-ua8e.googlevideo.com/vide
oplayback?clen=16982884&gir=yes&source=youtube&mime=audio%2Fwebm&key=yt6&initcwn
dbps=18818750&itag=249&lmt=1453189853584740&ipbits=0&expire=1485814165&sparams=c
len%2Cdur%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Clmt%2Cmime%2Cmm%2Cmn%2
Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cupn%2Cexpire&mm=31&pl=24&mn=sn-gphvo-ua8e&
id=o-AEIHmZJ6UHWDddYIXIDt1Wyq3CZ3mAFBbW69ecgOc-Af&dur=2646.521&requiressl=yes&mt
=1485792326&mv=m&ms=au&ip=<IP_ADDRESS>&upn=XxdlQcWYju0&signature=B5B5CDC64B113
B154324B31EAC955E4ED55D8B2.C602AA7ABA6E0A1E5BC442AB0AFEA3AA27BE2B&ratebypass=yes
'
ERROR: unable to download video data: HTTP Error 403: Forbidden
Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\youtube_dl\YoutubeDL.py", line 1699, in pr
ocess_info
    success = dl(filename, info_dict)
  File "C:\Python27\lib\site-packages\youtube_dl\YoutubeDL.py", line 1641, in dl

    return fd.download(name, info)
  File "C:\Python27\lib\site-packages\youtube_dl\downloader\common.py", line 353
, in download
    return self.real_download(filename, info_dict)
  File "C:\Python27\lib\site-packages\youtube_dl\downloader\http.py", line 61, i
n real_download
    data = self.ydl.urlopen(request)
  File "C:\Python27\lib\site-packages\youtube_dl\YoutubeDL.py", line 2001, in ur
lopen
    return self._opener.open(req, timeout=self._socket_timeout)
  File "C:\Python27\lib\urllib2.py", line 437, in open
    response = meth(req, response)
  File "C:\Python27\lib\urllib2.py", line 550, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\Python27\lib\urllib2.py", line 475, in error
    return self._call_chain(*args)
  File "C:\Python27\lib\urllib2.py", line 409, in _call_chain
    result = func(*args)
  File "C:\Python27\lib\urllib2.py", line 558, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 403: Forbidden

What's the result of nslookup r3---sn-gphvo-ua8e.googlevideo.com from within Rimon ISP?

nslookup r3---sn-gphvo-ua8e.googlevideo.com
Server:  router.asus.com
Address:  <IP_ADDRESS>

Non-authoritative answer:
Name:    r3---sn-gphvo-ua8e.googlevideo.com.ger.corp.intel.com
Address:  <IP_ADDRESS>

$ whois <IP_ADDRESS> | grep Rimon
descr:          Internet Rimon infrastructre
descr:          Internet Rimon LTD

Apparently the connection is hijacked.

You'll need to check DNS settings on router.asus.com(<IP_ADDRESS>) or ask your ISP stop hijacking YouTube connections. That's out of the scope of youtube-dl so closing.


General "hoc error" catching

Create a mechanism to catch and repackage hoc errors. (generalize NetCon hoc error approach)

This is a horribly written issue, shame on me. I have no clue what I had in mind here, but we have the catch_hoc_error error handling system now which seems to generalize well so I'm closing this.
https://github.com/Helveg/patch/blob/14bce40f2958f688c02a21bfeeb4f6d96662ce77/patch/error_handler.py#L27-L44
To use it pass a variable amount of callables to it that take the exception and a context as parameters; if any of them raise an exception it is propagated instead of the original error:
with catch_hoc_error(my_handler_for_err1, my_handler_for_err2):
  h.cause_an_error()

There is also the ErrorHandler class that you can inherit from and you just have to specify required context items (if any) and a catch method. Simple example that'll catch a section access hoc error by looking at the exception message:
class CatchSectionAccess(ErrorHandler):
    required = []

    def catch(self, error, context):
        if error.find("Section access unspecified") != -1:
            raise HocSectionAccessError("This operation requires a Section on the stack or perhaps a `sec` keyword argument.")

If you raise any errors from inside the catch method, make sure they inherit from patch.exception.PatchError or ErrorHandler will assume your error handler itself encountered an exception and will throw an ErrorHandlingError on top of your exception.


Build failure: geogebra and geogebra6

Steps To Reproduce
Steps to reproduce the behavior:

build geogebra or geogebra6

Build log
last 7 log lines:
       >
       > trying http://static.geogebra.org/images/geogebra-logo.svg
       >   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
       >                                  Dload  Upload   Total   Spent    Left  Speed
       >   0   196    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
       > curl: (22) The requested URL returned error: 404
       > error: cannot download geogebra-logo.svg from any mirror

Additional context
Well just the icon dowload path is not availaible anymore.
Notify maintainers
@voidIess
@sikmir
@soupglasses
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.7.1, NixOS, 23.11 (Tapir), 23.11.20240124.a77ab16`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/store/5hwz775f3grzikafj1sbwx4lqkjwqswb-source`

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

static.geogebra.org seems to serve no content anymore. Gone fix it by using archive.org for now


Fix a permissions issue and clean whitespace

@szakeri
What issues does this address?
Fixes #316
We need to experiment with allowing non-root to access the docker socket.   This fix will work for development but not in regression unless we allow the worker-User to be root.

@zancas is this out of date and needs to be closed?

This has been superseded.