Continuation of "Terms of Use" Updates

Additional functionality for the the new boost website Terms of Use acceptance. The following features to be added or verified:
JS enabled browsers:

Turn the ToU page into a pop-up modal for viewing.
turn the github and goggle log ins into popups, rather than having to navigate to a separate page

Email Registration Process:

when a person registers via email, they receive a link with a time limitation (TBD) to validate it.
if a person uses an expired link, they go to a page asking them to re-register.
if a person attempts to register an email that has already been registered, that email address will receive an email that an attempt was made to re-register that email. Perhaps include instructions to recover the password in case it was forgotten.
when a person clicks a valid registration link, they go to a page that validates the registration and notifies the user, and then invite them to login (or automatically log them in)

There may need to be some discussion as what pieces will be front end, and which will be back end, and will overlap with #1127 and #1128
Figma display of process
Other considerations:

Should JS users be stored so they can be notified to updated Terms of Use as a site popup, or would all users be notified via email?

Should JS users be stored so they can be notified to updated Terms of Use as a site popup, or would all users be notified via email?

If an email is registered, notifications about changes in legal documents such as ToU must be sent to that email. That is the common practice. This is regardless of any indication on the website itself.

This is now mostly complete, the exception being the email notification which is covered by ticket #986, so I'm closing this.


Size of screen

I use this property to define the width and height's screen:
    var width = 1280;
    var height = 600;
    browser.driver.manage().window().setSize(width, height);

In the method onPrepare() but this code is functional for somes tests, not for all of them. Why is that? I don't redefine the screen's size in my tests.
Regards,
Johnny

Hi there!
Your question is better suited for StackOverflow or Gitter. Please ask a question there with the 'protractor' tag or post in the Gitter Channel to get help.
From the the getting help section of the README:

Please ask usage and debugging questions on StackOverflow (use the "protractor" tag) or in the Angular discussion group. (Please do not ask support questions here on Github.)

It's Ok, thank you :)
http://stackoverflow.com/questions/33677458/protractor-size-of-screen


[Header] Font of text  in 'Language'  drop-down menu incorrect. Looks of drop down menu doesn't meet mock up.

Environment:  Firefox Version 78.0.2 (64-bit)/Windows 10 Home 1903
Reproducable: always
Build found: commit  9c376b1
Steps to reproduce

Go to GreenCity https://ita-social-projects.github.io/GreenCityClient/#/welcome
Log into the system.
Click on 'Eco news' link in the header.
Click  'Language'  drop-down menu on Header

Actual result
Font of text doesn't meet a mock up.

Font incorrect
Location (drop-down menu  stays under button)
Size one item (41px*22px)
Menu doesn't have  shadow

Expected result
Looks of drop down menu should meet mock up.

Font correct
Location (drop-down menu  doesn't stay under button)
Size one item (61px*44px)
Menu has shadow

User story and test case links
User story ##558

Not relevant


pmdk: init at 1.4.1

pmdk is a persistent Memory Development Kit
Motivation for this change
PMDK package is missing from Nix repostitory
Things done
Add Nix package that fetch PMDK from git and build it.

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

[x ] NixOS
[ ] macOS
[x ] other Linux distributions (Ubuntu)

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

You can force push to your branch instead of closing/reopening a pull request :)


Fixed modal styling

Overview
This PR correctly passes default styling and custom styling to the new Modal component, which uses contentStyle instead of style as property.
Test Plan
Notice the padding.
Before:

After:

Available in v8.0.1 🎉


Can We Create 2 instances of Learning Pathway in Single tenant?

[] Administration

Can we create 2 instances of learning Pathway in Single tenant with different custom content in them? Will that still work without any issues?

That has not been the architectural model since the beta version of learning pathways.  We only support tenant level deployment in the tenant app catalog.  You then have a main learning pathways site collection which is the source of learning content in whatever site collection you want to put the learning pathways web part. Please see the video for an overview of the architecture: https://www.youtube.com/watch?v=-sLXl_rKGxQ  If you need more flexibility you can look at the custom content pack concept, this can allow you to segregate custom content by maintaining it as a set of JSON files, or you can use minimal versions of those files to set up categories and then create all your custom playlists/assets using the UI. An overview of custom content packs is covered in the video.


Enable operator user to specify sampling strategies

As described here, it is possible to specify adaptive sampling strategy details in a json file.
As changes to the sampling strategies may be automatically reloaded when changed, it may be appropriate to create this mounted file as default (albeit empty) - so an update to just this part of a CR does not need to necessarily cause the restarted.
We should consider in general what the update approach should be when changes are applied to the CR. Maybe a general rolling update approach would be safer.

As changes to the sampling strategies may be automatically reloaded when changed, it may be appropriate to create this mounted file as default (albeit empty) - so an update to just this part of a CR does not need to necessarily cause the restarted.

+1

We should consider in general what the update approach should be when changes are applied to the CR. Maybe a general rolling update approach would be safer.

This request requires more thought and a lot of QE, to make sure we don't end up losing in-flight data to the agent and collector. Somewhat related: #42


Unlock version of golangci-lint by specifying it at runtime

This is cool. Does it create lots of bogus go.mod file changes though after lint runs?

It doesn't mess with go.mod from what I can tell.

This is great - thank-you!


Can be applied locally to the point in the module tree where you're doing the work, keeping file locality.
Can integrate with visibility-changing exports as well, so that you don't need to separately comment them out.
Potentially has upsides by giving you a very clear indication, at the top of your file, about your progress through the refactor.

Separately, the point about easily being able to tell what the submodules are, seems very similar to @est31's concerns. It is definitely a highly editor-specific issue, since in many editors this is (or could be) totally trivial.

I would still like to know why completely and absolutely removing mod foo; is necessary. I'd be fine with having to specify automod = false or something in Cargo.toml as an opt-out.

There are two key problems with this kind of opt out:

First, I don't think it fully solves your problems. As @est31 explained, you can't rely on others to employ the opt out, so when you're browsing their code, you have the same navigation issues.

Second, it cuts against the learnability goals for the proposal as a whole, because now there are distinct mechanisms for incorporating a submodule which must both be learned. (If mod is not commonly used then this is less of an issue, but then the first bullet point becomes more of an issue).

In general, this flavor of opt-in or opt-out is, to my mind, a kind of "design smell": it indicates that the design was unable to reach a firm decision on the topic, and is thereby punting it to the user. My hope is that we can instead continue to explore ideas like ignore above that address key use-cases within the framework of a single, unified design.

I'm in favor of the changes, introducing local as a new visibility modifier and turning export into a statement.
@aturon One question from my earlier comment here that hasn't been answered yet:

Will the new re-exporting syntax allow for glob re-exports, like pub use foo::*; today?

When export is a statement, I guess this will just work as it does today (but with relative paths), i.e. export foo::* instead of pub use self::foo::*? This should be mentioned in the RFC.

Will the new re-exporting syntax allow for glob re-exports, like pub use foo::*; today?

Yes! We'll try to clarify that in revisions.

First of all, I'd like to thank @withoutboats and everybody else who contributed towards making this RFC happen. Although I'm personally averse to a few of the changes proposed here, it seems fantastic that the Rust community has been able to be so vocal about their needs etc.. leading to what I hope is a better compromise for everyone.
When I first read this RFC my first reaction was that it was absolutely massive, encompassing 3 different, somewhat-backwards-incompatible changes in one. Considering that other RFCs of this size (ticki's original one on π types comes to mind) have been rejected for being too dramatic, I am glad that @aturon is suggesting to open a new, more conservative proposal.
After trying to read through as many of these comments as I can, I've found it really difficult on GitHub to gauge how many people are in support of different aspects, and also bikeshed particular syntax. I also feel that there is a silent majority of the user base who either haven't seen these proposed changes at all, or are simply content with the old system (or conversely open to the new change), but don't feel the need (or have the time) to voice their own opinions here. Therefore it seems like some sort of poll system would be useful to gauge what more people think. For example, it seems like features such as inferred extern crate are more accepted than the proposed visibility system, which seems to be under heated debate.
Finally, on to my own opinions, which to be honest I think are secondary to my above ideas about collaboration and participation. Regarding visibility rules (to everything else I more or less say 'meh'), I like the idea of being able to look at a definition and see exactly what visibility it has - in contrast to the current system where pub means different things. The original proposal, using the export keyword, to me seemed extremely ugly: (although I appreciate what it was trying to do)

export sounds like a verb, not a modifier
When attached to items, it may look alright (export struct Foo;), however I could imagine that prefixing every struct field with export would be a mess.

If pub means public, surely the default should be public to the world/api/other crates? Therefore I'd support the suggestion to gradually transition (through a lint etc..) to a system where pub means the item is 'world' visible. At the same time, I understand people want a more convenient way to type pub(crate). I don't think plain pub was the right choice (conveys the wrong meaning), however suggestions of local internal or protected seem fine. If anyone can find a nice looking <5 letter keyword though, that would be nice.

@aturon @phaylon

Commenting out a module tree during refactoring becomes much more difficult. I expect we can solve this use case with a bit of creativity, such as an attribute you can apply to the module at  the top of the tree like #![ignore].

Total rust newb here, but seasoned Java guy.  Being new to rust I found it kinda odd having mod foo in my main.rs and a free standing foo.rs that didn't mention what module it was. I've already gone the route of commenting out the mod when testing things as well.
Has anyone considered simply moving the mod foo INTO the foo.rs file itself. Cargo could still scan all files in src/* but only those files that declare the module would be used.
This could open one to have foo.rs and foo2.rs files, comment out the mod line in foo.rs and uncomment the other to toggle between files during experimentation.

Aren't RFCs supposed to have a motivation section?  I have not followed the "module syntax" discussion, so I do not know what all this is supposed to accomplish.
Just some questions on niche corners after removing mod lines :
I've used macros with nested mod { } to avoid naming conflicts that arise because macros cannot set declaration names.  I've did not use file submodules because you cannot pass arguments to the mod line, but maybe that would've made the code more readable.  Is there an argument that one should not need to pull modules into multiple places?
#[cfg(A)] mod foo { mod bla; ... }
#[cfg(not(A))] mod bar { mod bla; ... }

If we add parameterized modules, then we'd presumably pass those parameters with the use lines anyways.
How should one define some procedural macro, or other code generation script, that only makes sense inside some submodule?  It's rust code, so you cannot add #![ignore], maybe #![cfg(my_proc_macro)] helps.  These scripts would frequently be placed ouside src, but a separate gen/A/B/C/D/gen_bla.rs file path that paralleled the src/A/B/C/D path sounds annoying.  I suppose the easy answer is to hide the generator script inside a subdirectory that contains a mod.rs file that itself contains only #![ignore].
How should users place symlinks to elsewhere within the src tree?  Again you might use a subdirectory with a mod.rs file containing #![ignore]?
Another idea might be a .rustignore file, not unlike .gitignore, or to support !mod file; lines.

@burdges The motivation section was big enough to get its own file: https://github.com/withoutboats/rfcs/blob/modules/0000-modules/motivation.md

As an aside, I doubt use self:: will stay "exceedingly rare" or that re-export child items will remain more common than to use them.
I found like 30% of my use lines to be either use self:: or use super::, making them together more common than pub use for me, which accounted for only 20%.  I did find pub use self:: and pub use super:: to be rare, but present.
Just to look at someone else's code: ring's use lines are 21% use self:: or use super::, only 5.5% pub use, and 4%  pub use self:: and pub use super::.
I also found only about 20% of use statements in ring pointing to external crates, so almost 60% of ring's use statements would become use crate:: after this RFC.  I'd expect my own code to be similar.
These are crypto crates where control over exports gets taken seriously, but business logic can look that way too.  Anyways, the statistics linked by @aturon in https://github.com/rust-lang/rfcs/pull/2108#issuecomment-322339338 should be taken as characteristic of relatively general purpose libraries, not all code.
Afaik, this RFC won't make use self:: and use super::, or their pub variants, any harder, so no problem here.  It's just that those statistics jumped out at me as incorrect.

I'm not objecting to use crate:: either, btw.  One could always do use crate::{ foo::{ ... }, bar::{ .. } } and use self::{ aaa::{ .. }, bbb:: { .. } } if the RFC for { } in use statements got accepted.

export struct Foo;

// This is an error: you have re-exported something at a path it already is
// mounted at.
export Foo;

Is it beneficial for this to be an error? Could exporting the exact same thing in the exact same place be no-op?
export Foo;
export Foo;
export Foo;

I'm with @phaylon. I comment out modules often too. I also sometimes keep .rs files with unfinished features. I'm also concerned about conditional compilation.
Also, this is practically breaking change (disallowing mod $ident). That would mean Rust 2.0 or epochs (I'm not entirely convinced epochs are good idea yet). Instead, I'd suggest making this opt-in:

automod setting in Cargo.toml, defaults to false
New template for cargo new with Cargo.toml containing automod = true, so new users have it easy
Code with automod = false works as today without warnings or errors.

I often write no_std crates with traits and I impl those traits for std types using conditional compilation. I'd hate if I had to write #[cfg(feature = "std")] on each impl.

One more alternative may look like this:
// This statement is implied in every module unless overridden
//local mod *;

// Override the implicit statement
pub(super) mod *;

// Or for a single module (maybe even with attributes)
#[cfg(test)]
mod foo_tests;

// Opt out completely of auto-loaded modules
#[ignore] mod *;

// Opt out for a single module
#[ignore] mod foo;

// Maybe even multiple?
#[ignore] mod {bar, baz};

@withoutboats

do you have strong feelings about the difference between rustc <arg+> (first arg is root) vs rustc <root> --modules <arg*>?

"First arg is root" breaks shell globbing - rustc *.rs passes the source files in alphabetical order, which is unlikely to put the root module first.  Either option could work, though, if the root module is allowed to be repeated in the module list - then rustc root.rs *.rs would have the desired effect.  That does seem a bit unintuitive, though.
One alternative is to take only a list of files and pick the root module automatically using some simple rules, maybe with a flag to override the decision if needed.  Looking for files named lib.rs, main.rs, and $CRATE_NAME.rs in that order seems like it will cover the majority of cases.  Add a short flag for setting --crate-name and you get fairly nice command lines like rustc -c my_crate *.rs (compare with gcc -o my_program *.c).
Another option is to have rustc take only the root module and, in the absence of --module options, automatically scan the directory containing the root for child modules.  Then rustc root.rs would work nearly the same as it does today.  This approach might be the same as the second alternative in loading-files.md - if so, can you explain why it was considered to be a "bad choice of layering"?

If y'all like keeping pub pub and making pub(crate) local maybe don't change the local root from :: to crate:: but instead to local:: as well. Keep it consistent. If crate:: is the only reference to crates in the language vocabulary itself it will really throw new users off, especially if any alternative build systems emerge (and even Cargo.toml doesn't mention the word "crate", it calls the crate you are making [project]).
Ex: "I'm writing an executable, I want to reference thing in another RS file, why am I writing crate::? I'm not making a crate! I'm making a binary!"

@Korvox It's actually quite consistent:

local = local(crate) corresponds to crate::...
local(self) corresponds to self::...
local(super) corresponds to super::...

I've realized that #[path = "../some/path.rs] mod path; can be replaced by mod path { include!("../some/path.rs"); } in the new system. This clears all of my blocking issues for this RFC.
I still have some reservations about the module loading aspect (although not blocking my use case anymore). If I may explore some ideas:
The mod keyword cannot be obseleted as inline modules are still a thing (and this RFC doesn't propose to do away with inline modules, does it? it isn't mentioned in the 'loading files' section). The mod $ident; syntax can still be used in addition to automatic source file discovery.
When the compiler sees a mod $ident; statement it looks in its --module list:

The module is already in the --module list, then take the attributes on this mod statement and apply them to the module. Eg there may be a #[cfg(false)] mod foo; or even explicit #[ignore] mod foo; indicating that this module (and its children) should not be mounted.

The module is not in the --module list, include and mount it anyway. This keeps existing behavior as an opt-in without being disruptive.

This can work well with the alternative of doing file-lookup in rustc itself, dropping --module and cargo extensions entirely. Replace 'the --module list' with 'discovered source file list' above.

I've realized that #[path = "../some/path.rs] mod path; can be replaced by mod path { include!("../some/path.rs"); } in the new system. This clears all of my blocking issues for this RFC.

That makes any error happening in path way more verbose for absolutely no reason.

Any suggestion that involves adding code to ignore a module means that you will have local changes in your repository, and thus you can't just ignore a file that you haven't committed yet and may not even belong to the branch you are currently on. This will remain a problem as long as this RFC suggests mod statements shouldn't be a thing anymore.

@aturon

I understand that you would prefer to continue requiring mod declarations, but I'm curious whether something like @stevenblenkinsop's second suggestion -- which is also what I was going to propose -- would at least adequately address the specific refactoring workflow you were talking about.

Yes, it would work, but still increase the amount I'll have to switch to a shell a type tree, since I'll have to rely on the shell to just figure out what modules are there.

Separately, the point about easily being able to tell what the submodules are, seems very similar to @est31's concerns. It is definitely a highly editor-specific issue, since in many editors this is (or could be) totally trivial.

I'm often working through SSH on machines I don't really control. So besides a simple.vimrc I usually don't customize that and like things to work as vanilla as possible. I dislike requiring repeated shell accesses in normal workflow because of the constant screen window switching that can get quite laggy, especially if you have to bounce through multiple hosts. Currently, I only need to switch when I'm contextually finished in my mind and ready to type cargo check.

First, I don't think it fully solves your problems. As @est31 explained, you can't rely on others to employ the opt out, so when you're browsing their code, you have the same navigation issues.

That is true, but there's lots of things people can do to make things less readable for me. At least this way I can choose this for my own projects. It's like documentation, I can't force others to add correct and good documentation, but I can do it for my own projects.

Second, it cuts against the learnability goals for the proposal as a whole, because now there are distinct mechanisms for incorporating a submodule which must both be learned. (If mod is not commonly used then this is less of an issue, but then the first bullet point becomes more of an issue).

Patterns with match ergonomics have the same issue, and catch would too. People will already have to learn about inline mod foo { .. }. mod foo; gets the { .. } from a file seems like a simple knowledge addition to me.
Also, wouldn't any alternative like specifying a module list in Cargo.toml suffer the same issue, except without having the mod foo { .. } symmetry?

In general, this flavor of opt-in or opt-out is, to my mind, a kind of "design smell": it indicates that the design was unable to reach a firm decision on the topic, and is thereby punting it to the user. My hope is that we can instead continue to explore ideas like ignore above that address key use-cases within the framework of a single, unified design.

Do any of the other parts of the RFC depend on mod disappearing? I think the path changes, and any clarifying visibility changes are worthwhile on their own.

In defense of the current system:
It took me some time while I was very confused about how the module system works, but once it clicked I really enjoy the fact that I don't have to specify the source files explicitly in a project file and that the source code itself was the driving force for which source files are compiled.
This is very refreshing compared to other build systems like Visual Studio where each source file is specified in the project's .csproj (for C#) or .vcxproj (for C++).
My problem was that I was trying to apply my knowledge how other build systems work to Rust and  this held back my understanding.
In that sense this RFC is a regression as undoes this progress (even with some automatic source file discovery so at least you don't actually have to specify the individual files).

So, I finally printed out the RFC, read it and annotated. Given the size of the discussion above, I'm sorry if some points have been made or already discussed, I tried my best to read it.
First of all, I would also like to express gratitude the amount of work and detail that went into this RFC. My reservations expressed in #2088, though, are still the same. In some parts though, I even think the RFC is a little too conservative if implemented.
I'd also like to state that it is hard to express in this discussion the feeling that the current system is not a beauty, but adequate. There's not a wall of text to write about it.
The current module system allows all methods of crafting an API that RFC wants to support, they might not come as "naturally", but can be learned easily in a mechanical fashion.
I'd take export without the breakage and the rest of this RFC anytime.
What I like
Let's start highlight with what I like (very much):

I like export, very much. The old rule rule "something becomes a public symbol when it is public and all paths to it are public" is hard to teach and hard to grep for. export and it's enforcement are a net improvement. Especially in terms of "crafting the API", making the crafting points very visible is right up my alley.
Beyond my general reservation against the mode of working of this RFC (my reservations later), it is a well-rounded and sound system in itself.
I'd especially like to highlight the possibility to have a module named src/foo.rs with submodules in src/foo without having an intermediate src/foo/mod.rs module. Also, the rules around tests, examples and benchmarks take a lot of aggravation away, as those were often areas where a lot of mechanical module-shifting was necessary.

There's a couple of things where I don't feel like the RFC goes far enough. The rules around handling --module from the rustc side are as follows:

The file name is not a valid Rust identifier followed by .rs.
The file is not a subdirectory of the directory containing the root module.
Any of the subdirectories of the root module in the path to this file are not
valid Rust identifiers.

I don't see why not passing files named .rs should be illegal. Given that we now explicitly call rustc to include something as a module, this gives the ability to mark certain kinds of modules (for example generated ones) with special extensions. mylib.cffi may be an idea.
The RFC presents the chance to have non-hierarchical projects with multiple folders. The second rule disables this. Organisation of applications (not libraries) in a non-hierarchical fashion can make sense, many application frameworks do this, for example by having a folder for binaries, models, controllers and similar. This would also point to the presence of multiple root folders (not to be confused with root folders).

Also, I don't see why src/main.rs must be moved to src/bin. src/bin is already kind of special-cased by cargo, I don't see why src/main.rs couldn't. Especially given that cargo gives a lot of control over the position of binaries nowadays, I see cargo breakage coming along. I think the RFC should be more conservative here.
I don't think it would be bad layering to give rustc the capability to walk the file directory. It's a philosophical decision about the position of rustc in the ecosystem.
If this RFC is implemented, I'd also like to voice support for implementing the
use crate::{
  ....
}

syntax with it and not as a future extension.
Issues and why I'm still not convinced
First of all, I appreciate that quite some people voiced confusion about the module system, but I haven't seen much research into how much it persists. Every language has sore points and I still don't see that this is the one that absolutely needs to be fixed at great cost (given the breakage, semantics changes and the amount of necessary mitigation).
The semantics behind the path syntax switch (one usage of export changes path semantics) are sketchy and breaks Rusts idea of local reasoning. An explicit switch (either through a compiler flag or a stable feature flag) would be preferable in my opinion. I find the current behaviour dangerous.
The "migration" section only covers forward-compatibility. Moving to new code breaks the ability to compile on older compilers very fundamentally, though. A method of supporting older compilers could be researched (is transpilation possible?). This will make it very hard for library authors to support older compilers without a thousand deprecation warnings. This RFC deprecates all Rust code in existence, without a method to support the "old world" without completely relying on the deprecated infrastructure.
I would like to see a cleaner push towards removing the old style if this RFC is accepted. There's still places where you need to opt-in to the old system (everything involving annotations, for example), for example #[macro_use].
A problem that isn't addressed is that this proposal will still require teaching the old system for quite some time.
Finally, I still don't believe that making the module system less boiler-platy is currently an absolute must.
Wider commentary
I think it is a bad testbed for the checkpoint/epoch system, with a huge potential for actual ecosystem breakage, confusion and division. From my standpoint as a community evangelist, a revamp of the module system strongly counters the idea of Rust as a stable language in public perception. I appreciate that it does fulfill the letters of our guarantee, but that isn't worth much in public perception. No amount of "but there's epochs" will change that.
It represents a much more fundamental departure then #2088, as it further walks down the path of making rustc depending on external drivers. The RFC often uncritically uses cargo as the implementation place of certain features. This RFC, though the introduction of --module will render rustc almost unusable without any kind of tooling on top, a property that it currently has. I'm not in favour of this change, especially as I believe it is subtly introduced as a side-effect through this RFC and #2088. In my opinion, this shift is underappreciated and under-discussed, especially as this change impacts people outside of our ecosystem, namely package maintainers and build system authors.
This also means that libraries moving across the epoch boundary will refuse to build on older versions of rustc in a non-trivial way. On library that comes to mind that will be heavily impacted by this RFC is libc.
This RFC also invalidates all previous writing on the subject of Rust module design and exports, along with all experience held by practitioners. Rust already has a name for having lots of now-invalid documentation around.
Finally, and this is really meta, I believe there's much bigger fish to fry in Rusts ergonomics, at a code level, especially around trait ergonomics and similar, I'd prefer those to be given preference.
Sidenotes
The current system seems a bit like cabal, where a lot of stuff moves from the code to the build system.

@aturon thanks for the summary, it really helps when reading these long issues!

Let me know if I've missed something important.

Regarding the path confusion, I have only ever seen you talk about changing relative <-> absolute in the context of use declarations. However, what about the other way, changing all paths to be absolute everywhere else, as indicated by https://github.com/rust-lang/rfcs/pull/2108#issuecomment-322622748?
For me, that was one of the main things I found confusing when learning the module system.
Will the new system allow having pub(self) or pub(super) modules that have local items in it? Or is this an error, just like the export one?

I think it is a bad testbed for the checkpoint/epoch system, with a huge potential for actual ecosystem breakage, confusion and division. From my standpoint as a community evangelist, a revamp of the module system strongly counters the idea of Rust as a stable language in public perception. I appreciate that it does fulfill the letters of our guarantee, but that isn't worth much in public perception. No amount of "but there's epochs" will change that.

I think this is a strong reason to evolve the Rust module system in smaller steps, perhaps spanning many epochs/checkpoints.

@withoutboats Could you edit your original post with a link to @aturon's summary?

@aturon: I am largely okay with visibility modifier and item path changes (I would even say I'd prefer export/pub as @withoutboats proposed them originally, had it not been for long an complicated deprecation procedure to make pub mean pub(crate)).
But, whatever you do, please don't make us provide all crate modules and extern crates via command line parameters!   Module search logic should be in rustc.   Rustc should be usable without cargo.

I hear the argument about rustc doing file system walking being a layering violation, but if you squint a little it's already doing it to handle mod file; statements. And, even with a Cargo-side implementation, rustc still has to care about paths in order to build the module hierarchy.
Given that, I don't see much of a downside to just letting rustc walk the source tree itself. Maybe give it an --exclude option so Cargo can keep src/bin as a separate crate rather than a bin module. Maybe only include source files on use/export so rustc doesn't have to actually list directory contents, and live with #[allow(unused)] on impl-only modules. It would certainly be nice for rustc lib.rs to keep working.

I really liked the idea proposed by @talios https://github.com/rust-lang/rfcs/pull/2108#issuecomment-322696893

Has anyone considered simply moving the mod foo INTO the foo.rs file itself. Cargo could still scan all files in src/* but only those files that declare the module would be used.

This is the typical namespace mechanism that are used in other languages such as Java and C#. However, I don't think mod is the right keyword to use here, since it is ambiguous with sub-modules.
In Dyon that is a scripting language heavily inspired by Rust, I went with namespaces because I did not want to make the module system depend on files. This is important because sometimes you're loading scripts from other sources such as embedded code or the web. To keep close to the succinctness of Rust that uses fn for function, I picked ns for namespace.
In Rust this could be the syntax:
ns <namespace>;

For example:
foo.rs:
ns super::foo;

pub struct Foo { ... }

parent.rs:
use foo::Foo;

// No need to use `mod` because the file has a namespace.

...

I think this is a good idea because one of the reasons the current module system in Rust is a bit confusing, is because the namespace depends on how the code is included in the parent. In other languages such as Java and C# you do not have to check the parent module to see where it is located. This is was something I struggled with when learning Rust.
Still, I like the way Rust allows explicit control over sub-modules is something I like, because it makes it easier to share sources between examples when prototyping. In C#, I always felt depending on the IDE to be productive, but Rust is a language that is usable without much IDE support. This is something I like very much about the language and don't want it to go away.
If Rust gets namespace control like this, then it could be both more easy to understand and more flexible.
For example, I could use a flat hierarchy:
/src
    lib.rs
    math.rs             - ns ::math;
    animation_walk.rs   - ns ::animation::walk;
    animation_jump.rs   - ns ::animation::jump;

I'm one of those people who normaly stay silent, but as somebody who uses rust in production, i want to add my two cents.
first of all - automatic file loading makes me feel uneasy. the current module system - while not perfect - helps with refactoring. i would not like to have to care about some lists somewhere, #![ignore] annotations feel better, but still not the same
second, i believe rustc should keep to be useable(by useable i mean by a human, and not by some scripts) by itself.
third, the whole discussion make me a bit nervous. i fought hard to be able to use rust in production,  and i really enjoy it, and i'm very thankful for all the hard work that has gone into it. i just don't see a pressing need for breaking changes of this magnitude. this makes rust a harder sell than it allready is. i believe a conservative, slower approach would be better for all.

Has anyone considered simply moving the mod foo INTO the foo.rs file itself.

This sounds great to me. It often happens to me that some module grows large and needs to be split into submodules. So currently I have to do this:
$ mkdir foo
$ mv foo.rs foo/mod.rs

Not requiring the second command would be helpful.

PHP has went the route of annotations in the file. It turned out to be pretty bad:

Most projects use same directory hierarchy as namespace hierarchy, so the annotations are redundant. They add no new information, but break things when they are forgotten or misplaced.
When file layout and namespace annotations don't match, it becomes unclear where to look for the files.
Despite PHP originating from "do-whatever-you-want" and arbitrarily complex autoloading logic allowing projects to use anything they like, in the end all of them converge towards namespaces = filesystem paths.

I believe keep Rust works without cargo is an important goal since Rust has many low-level usages and mixing it with C/C++ would be very common.

This is in no way a change that would keep Rust from working with other build systems, it just puts more work on other build systems, as they have to properly implement this behaviour.

I've read through the most recent comments and talked on IRC with some additional stakeholders (@nox, @phaylon, @jonathandturner) to further clarify concerns. We recognize that in general there's some amount of worry about the amount of change involved here, as well as with some of the specifics.
After talking with collaborators on this RFC, we'd like to propose moving to a significantly more conservative proposal. The rough outline is:

Introduce crate as a way for absolute paths to request the current crate's root, just as in this RFC.

Deprecation: we deprecate use statements that do not start with self, super, crate, or a crate name. This then retains all of the benefits of the current proposal for clarifying paths.

Introduce local as a way to control within-crate visibility. By itself, local replaces pub(crate). But you can also use it with restrictions: local(super), local(self) etc.

Deprecation: we deprecate pub(..), leaving just bare pub plus local. This means that there's a sharp split between crate-external visibility, aka public visibility, aka pub, and crate-local visibility, aka local, again retaining the benefits of the current RFC, but without needing to change any meanings for current code -- just introducing a new form and deprecating an old one.

Introduce export statements, which are roughly equivalent to pub use self:: today. (See this comment for more detail). This is different from export in the current RFC, which is used to configure module visibility as well.
Retain mod statements. You think of these not as declaring a module, but rather configuring a module (e.g. applying attributes or non-default visibility).

In particular, as with this RFC we scan the file system to determine the initial module hierarchy, which you can think of as providing a "default" set of mod statements. If a module is local and you're happy to put any attributes at the top (e.g. #![cfg(unix)]), then you don't need a mod statement at all. But if you want to export with a different visibility, or apply attributes at the parent level (useful in cases like libc), you can use mod to apply that configuration.
This means that existing uses of mod statements remain valid, although they may be redundant. We would introduce a lint against unnecessary mod statements (which can be turned off if you prefer to have a full list).

Add an #![ignore] attribute which can be used to exclude the current module, or selectively some of its children, from the filesystem scan. This was discussed previously in the thread and can be used to support workflows for refactorings and other temporary "scratch" files.

This proposal is more conservative along several dimensions.

Nothing changes meaning relative to today.
Most forms that are valid today would be valid in the next epoch, though some might be linted against as "unnecessary".
This means, in particular, that old blog posts and code snippets should largely just work.
We also have leeway about how long we take to phase out implicit crate:: and so on (in terms of making it an error).

Epochs are still needed, strictly speaking, as a way to opt in to scanning the file system (because existing code may have files that are not currently picked up and need to be explicitly #[ignore]d).

I want to reiterate why we believe it's valuable to reduce the need for mod. In this revised proposal, you only need to use mod to "configure" a module. We believe that, when first learning Rust, people tend to write applications, where default module visibility is just fine. Thus, when first learning Rust, you're barely aware that there is a module system:

You write code in files placed in directories.
You use use crate:: to import from code elsewhere within the crate, matching the directory structure starting from src/
If you want to make an item in one file visible to another, decorate it with local.

That's it! It's only much later that you have need for mod or export. And there's less confusion about whether mod declares or imports a module -- it simply configures a submodule.
Those who value explicit mod declarations can continue to use them, and disable the lint against unnecessary declarations.

At this point, we'd like to take some time to revise the RFC according to the above. @withoutboats  and I are both a bit busy with RustConf happening this weekend, but hope to have a new RFC up by Friday, or Tuesday at the latest.
In the meantime, I'm going to close this PR. I'd ask people to refrain from digging into very detailed questions about this more conservative approach until we actually put the RFC up. But if you have comments or questions about the overall direction, feel free to leave them here, and we'll read/respond as time permits.

@aturon
Could the next iteration be splitted into a few orthogonal components, if possible, and submitted as separate RFCs?
This way the discussions will be more focused, the number of comments in a single thread won't be so intimidating (hopefully), changes with more consensus won't be pulled back by their more controversial counterparts, and changes with less consensus won't sneak through.

I don't believe this RFC can be accepted in a piecemeal fashion, because these changes interact in many ways. The advantages that we see in this system - incremental learning, heightened local reasoning, ergonomics for the common cases - all emerge from the cumulative impact of these changes together.

FWIW, I think internal would have much more of the right connotations for me than local. I would intuit local to have much smaller scope than the whole crate, closer to something like normal private items, and would be confused about what the difference is (and may wonder whether local is somehow even more restrictive). I suppose others may have the same kind of intuitions about internal though, so YMMV.

@glaebhoerl I agree, but would much rather have a shorter keyword than the most intuitive one. In fact, I rather like @est31's loc.

And I still like protected the best 😅. I'm going to go with local in the RFC and we can bikeshed that name once we've got more consensus on the bigger stuff.

would much rather have a shorter keyword than the most intuitive one

What about int? Stands for "intuitive" and "internal".
:trollface:

We can also have uint, short for uninternal, for exported items.

On a related note, I was thinking about ins for "insular".

I feel bad for thinking it, but if Rust ever wanted to earn some street e-cred you could call it protec for... you know.

How is there not a suggestion to use visible or vis as the visibility modifier keyword?

What's the reason crate can't be used? Does it collide with crate:: in paths? I seem to remember discussion about it but I can't find it back where the main downside was that it would look weird.

I just want to say that I find the mod-for-configuration idea quite brilliant. Big thanks to everyone who helped arrive at that, and special big thanks to @withoutboats and @aturon for the patience.
And to not let an opportunity for bikeshedding go to waste, I wonder if our for in-crate visibility would be descriptive.

@phaylon As in "our stuff"?

Also, I'm surprised nobody has mentioned priv

@mark-i-m Yea. As in our trait Foo {}, our(self) enum State {}. Might be a bit too phrase-like for Rust.

I don't like that modules are crate visible by default. Yes, it makes it easier to write simple applications, but at some point the user wants a private module (e.g. moving large internal functions to a submodule). At this point it gets much more difficult:

The user has to find out where to put the visibility attribute. It seems a bit strange to add some mod foo; statement to the parent module just to control something common as visibility.
The user has to find a visibility attribute that means "private". Everything else in Rust is private by default and neither private nor priv works. The solution is the arcane local(self) which definitely isn't apparent (and you will only ever see it for modules).

To me it violates both the private-by-default and the explicit-instead-of-implicit principles of Rust. Also, it makes hiding implementation details in private modules (the better design) more difficult than just exposing everything, which I think is also against Rust's principles.

We would introduce a lint against unnecessary mod statements (which can be turned off if you prefer to have a full list).

This also needs to come with a lint that disallows implicit mod statements, to disable the whole implicitness at scale.

The advantages that we see in this system - incremental learning, heightened local reasoning, ergonomics for the common cases - all emerge from the cumulative impact of these changes together.

Splitting the RFC in multiple ones may make it apparent that these advantages you are seeing are marginal and don't justify that many breaking changes for pretty much all code in existence.

Even though this thread is already closed, I would like to thank everyone involved in the discussion for the work they have put into this. Especially a big "Thank you!" to @aturon on @withoutboats. The outline of the new proposal addresses all the concerns I had with the previous one, and in particular assuages my fears that this RFC could fracture the ecosystem.

So now that I finally found the time to read through all of this, it is already deprecated: this community is indeed moving fast. Jokes aside I really like the direction this is taking: the first blog post had me aggravated, the second left me still a bit nervous and finally this RFC had me saying „I can live with that“. The new, even more conservative proposal seems even better to me. My only concern with the module system was the whole lot of boilerplate you have to write in order to get names into scope: extern crate, mod, use … I always felt a single use statement ought to be enough: if a module needs to be loaded, the compiler should be able to figure that out and do it for me. With that being addressed, I am already happy ;-)
To bikeshed a bit, local seems unrusty (everything else being an abbreviation): maybe loc is too confusing, but it would line up better with the likes of pub impl and fn. Probably a matter of taste.
Also I'd still prefer the from X use Y syntax above an explicit name for the local crate: the module comparison table posted a while ago left me struck with Python's elegance (something Python manages astoundingly often) and I'd like to see something similar in Rust.

I second the call for the new RFC to be several RFCs. I don't have many issues with the publicity (introducing local) and use changes, but I am very much against implicit loading of files (i.e. not requiring mod to load a file).
Adding implicit loading will add quite a few maintainability problems (especially in multi-person projects). E.g. Separate checkouts will have strange errors due to missing paths/impls instead of just pointing to the mod that would load the missing file)
The current model is generally suitable and matches the eventual code structure well, and I don't recall any real difficulties learning it (but that's just me).

The new proposal is up! I know this has been a long slog for everyone, but it would be really helpful to get feedback afresh, even if you were already a fan of this RFC.

Cross-posting from the new thread:

A general request: the proposal here appeared to be the consensus direction of the previous thread, but there seems to be significant pushback on this thread. Could those of you who were participating on the previous thread comment saying:

Whether you think the changes here are stepping in the right direction?

Whether you think this proposal did not correctly capture the consensus direction?

Whether you're in favor of the broad approach present in the two proposals, and if not, what the main sticking points are?

I think one of the primary problems in discussion here tends to be some disagreement about goals. This updated proposal works hard to retain the original goals around learning curves, while taking on some new constraints:

No breaking changes; purely deprecations
Retaining the use of mod for those who prefer to have such declarations in their code
Providing direct support for e.g. refactoring workflows (via ignore)

All of these were concerns raised over the course of the last few threads, and I believe this design addresses them while, again, retaining the original benefits. I'd like to understand whether there are additional constraints people feel are missing, or other major downsides to the overall approach that haven't been surfaced yet. (And of course, if you're happy with this approach, it'd be helpful to hear from you too!)

@aturon Maybe it is because I haven't had the time to let the last proposal sink in me yet, too much information in a too short span of time.
My feeling about this has been that I liked the first proposal. It had significant breaking changes, but I thought they were worth it, and that's what epochs are for. I didn't like the second proposal that much, because I am not sure if the wins outweigh the cost. The third proposal moves further along this direction, and I need more time to properly weigh in if they are worth it.
The good thing is the third proposal is backwards compatible, so we might want to pursue this now, and after some epoch go to something more drastic like the first proposal. Anyhow the RFC's are long, going through the three of them is a bit tiring, and the stress of willing to move them to FCP ASAP doesn't really help.

@aturon the new proposal looks much better to me. I think that adding an option to disable auto-scan of modules would help at least during transition (if I have some project with "sketches" - .rs files that are not compile-able, I'd like to be able to compile the project quickly without adding #[ignore] to everything).
Another thing is that I may want to retain those sketches in my project but keep them private - outside of version control and outside of any public files. Having some private setting to not include them would be helpful.

@Kixunil this proposal is not the newest one, its #2126 . It doesnt feature any auto-scanning of modules or anything.

@est31 Ah, I missed that, thanks! I like that approach much more than auto-scanning. (but I was under the impression that auto scanning is a highly desired feature)

I was under the impression that auto scanning is a highly desired feature

Its not off the table yet... the RFC I've linked is only intended to extract all the things that there is a broad consensus for and to get it implemented during the impl period. There is another RFC planned to experiment with stuff.


[CWS] move cgroup context in linux specific serializer

What does this PR do?
Move cgroup serializer to the dedicated place.
Motivation
Describe how you validated your changes

Possible Drawbacks / Trade-offs
Additional Notes

/merge


Handle TypeError in FMEA Work View init() Method

Expected Behavior
When connecting the cells in the FMEA Treeview to the callback function, if the cell does not have an 'edited' signal, a TypeError is raised.  This error should be handled or the code should be modified to connect to a callback function based on the type of gtk.CellRenderer.
Actual Behavior
Currently the init() method simply prints:
"FIXME: Handle TypeError in gui.gtk.workviews.FMEA.__init__()"

This is a place holder and not helpful to the user.
Steps to Reproduce the Problem
1. Launch RTK.
2. Open an RTK Program database.
3. Select the Hardware tab in the Module Book.
4. Select a Hardware item line in the Module Book.

The message above will be printed for every cell that does not have an 'edited' signal (combo, toggle, etc.).
Operating Environment
Not needed for Requirement errors.

The code to connect gtk.CellRenderer()s to callback functions was moved to the _make_treeview() method and revised to connect to the correct callback function based on the gtk.CellRenderer() type.  There is no longer a TypeError raised.  This issue is closed.


Enhanced MarathonSchedulerActorTest

Fixes #4534
Summary: Enhanced MarathonSchedulerActorTest to be more verbose and explicitly to handle terminal task status
Test Plan: sbt test
Reviewers: meichstedt
Subscribers: marathon-team
Differential Revision: https://phabricator.mesosphere.com/D36

Same as https://phabricator.mesosphere.com/D36 including @meichstedt `s feedback. Was not able to update the phabricator review :-(

Currently rebasing and resolving merge issues.

retest this please

retest this please

retest this please

Failing integration tests are unrelated (only UnitTests have been changed in this patch)


Added ability to run LoadRunner scripts

Added ability to run LoadRunner VuGen scripts directly from Jenkins without scenario.
Currently tested on windows and should work on linux as well.
Currently each step supports one script.
Still need improved unit tests.
In relation to ER:
https://issues.jenkins-ci.org/browse/JENKINS-41143

:x: Build hp-application-automation-tools-plugin latest.18-vsoyoegb failed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/34191d027c by @YafimK)

:x: Build hp-application-automation-tools-plugin latest.18-nagduqjd failed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/20b2829f7a by @YafimK)

:x: Build hp-application-automation-tools-plugin latest.18-hygvpfcj failed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/5b0fdccdf6 by @YafimK)

approved for test build

:x: Build hp-application-automation-tools-plugin latest.19-ngilatua failed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/9ef79dfe20 by @YafimK)

:white_check_mark: Build hp-application-automation-tools-plugin latest.20-eayntaab completed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/a5e46e6337 by @YafimK)

:white_check_mark: Build hp-application-automation-tools-plugin latest.20-dodxqctr completed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/93e71f3913 by @YafimK)

approved for test build

Merge approved


Revisit Boost reviews and implement what is meaningful

In addition to the conditions for acceptance other suggestions must be reviewed and implemented when possible/meaningful. Reviews can be found at: https://lists.boost.org/Archives/boost/2023/01/date.php
Links to individual reviews can be found below

Zach Laine: https://lists.boost.org/Archives/boost/2023/01/253883.php
Vinnie Falco: https://lists.boost.org/Archives/boost/2023/01/253886.php
Christian Mazakas: https://lists.boost.org/Archives/boost/2023/01/253900.php
Ruben Perez: https://lists.boost.org/Archives/boost/2023/01/253915.php
Dmitry Arkhipov: https://lists.boost.org/Archives/boost/2023/01/253925.php
Alan de Freitas: https://lists.boost.org/Archives/boost/2023/01/253927.php
Mohammad Nejati: https://lists.boost.org/Archives/boost/2023/01/253929.php
Sam Hartsfield: https://lists.boost.org/Archives/boost/2023/01/253931.php
Miguel Portilla: https://lists.boost.org/Archives/boost/2023/01/253935.php
Robert A.H. Leahy: https://lists.boost.org/Archives/boost/2023/01/253928.php

Regarding the suggestion to offer enum values for command names in place of requiring strings, please continue to allow strings for command names. A configuration file may still rename commands, though it has been labeled "deprecated" since Redis 6.0.

Most code review requirements have been implemented by now.


Bug in tutorial

I met this problem in tutorial/tutorial.ipynb. Any suggestion?

Hmm this seems odd, I still see parse_range_image_and_camera_projection returning 4 values at head: https://github.com/waymo-research/waymo-open-dataset/blob/master/waymo_open_dataset/utils/frame_utils.py. Perhaps did you make some changes to frame_utils.py?

I think the problem is that our tutorial still installs an old package in the colab environment:

!pip3 install waymo-open-dataset-tf-2-1-0==1.2.0

The package was built in May 2021, and a fourth return, seg_labels, was added in March 2022.
This should be our latest available built: https://pypi.org/project/waymo-open-dataset-tf-2-6-0/. Please try this one instead and let us know if you still encounter any issues. Thanks!

We will update the tutorial with the next commit.
!pip3 install waymo-open-dataset-tf-2-6-0


[BUG] NoBox with Tile leads to improper redrawing

Describe the bug
I attempted to create a very simple app with two resizable panes using Tile. If I understood the FLTK documentation correctly, the example uses DownBox for the frame type for the underlying frames to make the "dividers". For my own app I wanted to get rid of these visible dividers for a more modern look, instead relying on the background color of the tile to cleanly separate them. However, when using NoBox for the FrameType, I run into redraw issues (seemingly) where the frames don't redraw themselves correctly. Instead they smear, as though they are just repainting over the old image without clearing first. This does not appear to happen when using DownBox on both frames.
If I set only one of the two frames to up/downbox, that frame redraws correctly, while the other frame does not. In addition to the previous issues, the second pane doesn't seem to get the correct background color if it is set to NoBox.
To Reproduce
use fltk::{app, frame, group, prelude::*, window};
use fltk::enums::{Color, FrameType};

fn main() {
    let app = app::App::default();
    let mut window = window::Window::default().with_size(600, 300);
    window.set_frame(FrameType::NoBox);
    window.make_resizable(true);

    let mut tile = group::Tile::default_fill();

    // First panel
    let mut frame1 = frame::Frame::new(0, 0, 300, 300, "First");
    frame1.set_frame(FrameType::NoBox);
    frame1.set_color(Color::from_rgb(0x33, 0x33, 0x33)); // First panel color

    // Second panel
    let mut frame2 = frame::Frame::new(300, 0, 300, 300, "Second");
    frame2.set_frame(FrameType::NoBox);
    frame2.set_color(Color::from_rgb(0x55, 0x55, 0x55)); // Second panel color

    tile.end();

    window.end();
    window.show();

    app.run().unwrap();
}

Expected behavior
I expected to be able to resize the panes without redraw issues.
Screenshots
First Pane: NoBox, Second Pane: UpBox

First Pane: UpBox, Second Pane: NoBox

Both Panes: NoBox

Desktop info

OS: macOS Sonoma (14.1.1)
Version 1.4.18

Additional info
I'm completely new to FLTK, so I may have just misunderstood some documentation here. If so, my apologies!

Hi
Thanks for the report. This is a known issue in FLTK, see here.
I guess you would have to work around this behavior.  Does using FlatBox instead of NoBox not fix the issue for you?


Added Czech translation

Hey, I added Czech translation for the addon :)

@matejgordon
Thank you!
P.S. Would be great if you could give a star to the repo :) Thanks


test: add ut for pkg/common/hlog

What type of PR is this?
test

Check the PR title.

[x] This PR title match the format: <type>(optional scope): <description>
[x] The description of this PR title is user-oriented and clear enough for others to understand.

(Optional) More detail description for this PR(en: English/zh: Chinese).

en: add ut for pkg/common/hlog, coverage rate reached 81.4%
Which issue(s) this PR fixes:

#293

Good job


testnet network support - 6xtqkz6i5b6hr3w - validator, rpc, api

@ravaliGangasani , Your Moniker and validator addresses are required, please update the PR with those details

@ravaliGangasani , Your Moniker and validator addresses are required, please update the PR with those details

@ravaliGangasani , Your Moniker and validator addresses are required, please update the PR with those details

Moniker: Multiverse
Validator address: akashvaloper12cq6vpydw2cl2yfdf272hf30hkckn0ag07w5ku

@ravaliGangasani , Your Moniker and validator addresses are required, please update the PR with those details

Moniker: Multiverse
Validator address: akashvaloper12cq6vpydw2cl2yfdf272hf30hkckn0ag07w5ku


fix - load correct cds.env for the project path

When various plugins load @sap/cds the env can become invalid and set to defaults rather than the project specific values.
Before accessing cds.env it should be reloaded for the CAP project root for more reliable access.
Add compatibility with @sap/ux-ui5-tooling >= 0.14.5 and @sap/cds 8.

@geert-janklaps - Please review


Set up GitHub Actions

For Spotless, tests, Maven Central publishing, etc.

I can pick this up in case you haven't already started @ricknout

Fixed by the above PR as well as:

https://github.com/ricknout/compose-sensors/commit/576e59528497fec6e33df4bd73619a8bb68b35f3
https://github.com/ricknout/compose-sensors/commit/954bb38db3dd0c25651d36743f2b77c23b946e85

Thanks, @msasikanth!


New package: Enzyme_jll v0.0.1+0

Registering package: Enzyme_jll
Repository: https://github.com/JuliaBinaryWrappers/Enzyme_jll.jl
Created by: @vchuravy
Version: v0.0.1+0
Commit: a24ad44259a0d85fe97a3398853c6879bc51b408
Reviewed by: @vchuravy
Reference: https://github.com/JuliaBinaryWrappers/Enzyme_jll.jl/commit/a24ad44259a0d85fe97a3398853c6879bc51b408#commitcomment-42640398

[noblock]

Version number is not allowed to contain prerelease or build data

This is a mistake. We should not apply this check to JLL packages. @giordano want to look into why this check was applied?

I dug up a bit in the code of RegistryCI.jl, my understanding is that that check is triggered because only @jlbuild is expected to open pull requests for JLL packages, so other users will go through the standard checks.  I hope you can confirm my understanding.  In the meantime I'm going to merge this pull request anyway.

I dug up a bit in the code of RegistryCI.jl, my understanding is that that check is triggered because only @jlbuild is expected to open pull requests for JLL packages, so other users will go through the standard checks. I hope you can confirm my understanding. In the meantime I'm going to merge this pull request anyway.

Yes that is correct- we only apply the special JLL exemptions for registrations made by @jlbuild.
Is there a reason why this PR was made by JuliaRegistrator instead of @jlbuild?

Valentin built this locally and triggered registration with JuliaRegistrator, but this isn't the norm

Cool. Yeah if this workflow is rare, it's easy enough to just manually merge.


feat(integration-tests): create package

fix #564
fix #585

@CorentinDoue When the file type is created, or a new property is added to TestEnvVarsType, each property line is missing a trailing semi-colon ; character.
For example, the created file with the env variables API_URL and TABLE_NAME will be:
export type TestEnvVarsType = {
  API_URL: string
  TABLE_NAME: string
};

You can see that the semi-colons are missing.

@adriencaccia I know. But I can't add it with recast. It's not a part of the typescript syntax but a style preference. So it's not a node in the ast. Somebody can have a prettier config that don't add trailing ;.
I don't think it's the role of the lib to handle style preferences.
WDYT ?

Oh my bad, I did not know that TS interfaces worked without the semi-colons 😲
It's fine then yeah


After upgrade from jest 20.0.4 to 21.2.1 typeahead stop displaying any file results

I tried to reinstall jest many times, tried to run it in no-cache mode.
I'm running jest:
jest --watch ./assets --notify
Config:
  "jest": {
    "setupTestFrameworkScriptFile": "<rootDir>/assets/tests/setup.js",
    "moduleNameMapper": {
      "\\.(css|less|scss)$": "<rootDir>/assets/mocks/styleMock.js",
      "^((?:libs|stores|components|tests).*)$": "<rootDir>/assets/$1",
      "^react-pdf/build/entry.webpack$": "<rootDir>/node_modules/react-pdf"
    }
  },

Active Filters: filename /./assets/

Pattern Mode Usage
 › Press Esc to exit pattern mode.
 › Press Enter to filter by a filenames regex pattern.

 pattern › *test.jsx

And no any results are displayed, unlike it was using version 20. But if I push enter the pattern will be applied and files will be found successfully.

Please search this issue tracker more thoroughly and you’ll find that this feature has been temporarily disabled because of license migration to MIT. We’re working on watch more plugin system to make it work again.

@thymikee thanks for explanation

I had searched but found no results. @thymikee can you please provide ticket number, so I can follow, when functionality will be returned back?

We're not currently tracking this issue.

Help from the community would be greatly appreciated here. You can use the pluggable interface introduced in #4841. The plugin would be separate from the core Jest repo, but we would love to link to it (and probably host it in https://github.com/jest-community/).

Hey @SimenB I've just been taking a look into this and at the new watch mode pluggable interface.
I'm not sure how a separate plugin would be able to implement the old typeahead functionality without re-implementing a lot of Jest's internals. The previous implementation depended on the SearchSources type (amongst other things) which seems to be derived from the contexts array.
type SearchSources = Array<{|
   context: Context,
   searchSource: SearchSource
|}>;

Currently a watch mode plugin only receives the globalConfig and an end callback, which doesn't seem enough information to determine which tests to run/show based on the user's filter. Perhaps if searchSources are passed into the active plugin too (here) then this might be possible.
I'm happy to spend some time to get this working but perhaps I am missing something obvious 😆  any help you can offer on explaining the approach to building this would be greatly appreciated :smile:

Available as of Jest 23.
https://github.com/jest-community/jest-watch-typeahead


Issue #330: do not log params for sync_apply method

do not log params for sync_apply method

Thank you for your contribution @jbshu4546 but removing these params from error log isn't quite what we're after. We need to remove JSON-RPC params from debug logging for one particular method.


Fails to parse query params that are also URLs

The URL is /app?redirect=/home?referrer=ad. The redirect query param is a URL itself with its own query string. The correct value for redirect should be /home?referrer=ad but this library parses it to be /home?referrer. Thoughts?

For normal case url in param should be url-encoded %2Fhome%3Freferrer%3Dad reference
This result is predictable for current implementation.
https://github.com/boo1ean/shitty-qs/blob/master/index.js#L21-L23
You can try to work around it by joining all tokens starting from index 1 and treat it as value.
PR is welcomed.

Okay thanks!
On Thursday, June 2, 2016, Egor Gumenyuk<EMAIL_ADDRESS>wrote:

For normal case url in param should be url-encoded %2Fhome%3Freferrer%3Dad
reference http://www.w3schools.com/tags/ref_urlencode.asp
This result is predictable for current implementation.
https://github.com/boo1ean/shitty-qs/blob/master/index.js#L21-L23
You can try to work around it by joining all tokens starting from index 1
and treat it as value.
PR is welcomed.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/boo1ean/shitty-qs/issues/1#issuecomment-223234961,
or mute the thread
https://github.com/notifications/unsubscribe/AB9lxqO0d4-iZSsvD1Bg0BCNYzYPk7YVks5qHpuQgaJpZM4Ir16L
.


fix: forms row layout

Issue #, if available:
Description of changes:

fix typo of templateColumns

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #653 (01e9ffa) into tagged-release/forms-and-views (ff81eb6) will increase coverage by 0.13%.
The diff coverage is n/a.

@@                        Coverage Diff                         @@
##           tagged-release/forms-and-views     #653      +/-   ##
==================================================================
+ Coverage                           90.28%   90.42%   +0.13%
==================================================================
  Files                                  97       97
  Lines                                3644     3644
  Branches                              979      979
==================================================================
+ Hits                                 3290     3295       +5
+ Misses                                329      324       -5
  Partials                               25       25

Impacted Files
Coverage Δ

...m-to-component/map-form-definition-to-component.ts
90.62% <ø> (ø)

.../lib/amplify-ui-renderers/amplify-form-renderer.ts
38.05% <0.00%> (+0.88%)
:arrow_up:

...codegen-ui-react/lib/forms/form-renderer-helper.ts
97.74% <0.00%> (+3.00%)
:arrow_up:

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 ff81eb6...01e9ffa. Read the comment docs.


UI Simplification: Add menu / icon for adding elements

Feature Description
See Figma

[ ] Add additional + icon when hovering / focusing on element in the library.
[ ] When clicking anywhere else but the icon on the element, the element is directly inserted.
[ ] When clicking on the icon, it either opens an insertion menu (in case of media) or adds the image.
[ ] Ensure drag-drop still works as expected as well
[ ] Add the text "Click elements below to add them" to each panel
[ ] Remove the text quick-add button from the tabs

Alternatives Considered

Additional Context

To confirm:

UX for other elements but media
Accessibility: how will this work with keyboard integration considering we'll have two buttons in case of media now.
Do we need both the icon AND the text "Click elements below to add them"? In some panels, there's already a lot of stuff above the elements and on smaller screens it can push the actual content quite far.

Let's remove the copy since it pushes things down and we have added the plus.
@agingoldseco to provide mocks of templates, text, stock, shapes, and images
for accessibility can we walk through that in a meeting just to make sure we are doing it correctly?

for accessibility can we walk through that in a meeting just to make sure we are doing it correctly?

Perhaps @bmattb could set up a quick meeting once we have the UX for all the elements.

@agingoldseco / @andrew-askedall
The plus icon button can look quite invisible on some images and Page Templates, example:

Thoughts on alternatives?

Hi there,
there should be a small scrim on mouseover that darkens it so it is
legible.
a 50% 000000 scrim
On Thu, Jan 27, 2022 at 11:13 AM Miina @.***> wrote:

@agingoldseco https://github.com/agingoldseco / @andrew-askedall
https://github.com/andrew-askedall
The plus icon button can look quite invisible on some images and Page
Templates, example:
[image: Screenshot 2022-01-27 at 18 11 11]
https://user-images.githubusercontent.com/3294597/151398064-de289b4b-97ae-45e1-9f47-ea810cebc668.png
Thoughts on alternatives?
—
Reply to this email directly, view it on GitHub
https://github.com/GoogleForCreators/web-stories-wp/issues/10109#issuecomment-1023388911,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVK6S4UFA7U2IQJ62L6BLDUYFVKHANCNFSM5LMAWVBA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

--
[image: Google Logo]
Andrew Askedall
Senior Interaction Designer
@.***
5163309445

Thanks, @andrew-askedall, by "small scrim" do you mean that it's just around the button? Or does it cover the whole element?

the whole element. Here is a screenshot from the figma. Hope that clears it up!

Ah, of course, thank you! Somehow I missed this when looking at Figma currently 🤦


refactor(ts): move ts files into root

This makes our layout more consistent with other projects

Codecov Report

Merging #74 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #74   +/-   ##
=======================================
  Coverage   78.57%   78.57%
=======================================
  Files           4        4
  Lines         266      266
  Branches       41       41
=======================================
  Hits          209      209
  Misses         57       57

Impacted Files
Coverage Δ

src/checker.ts
73.07% <ø> (ø)

src/github.ts
87.93% <ø> (ø)

src/config.ts
100% <ø> (ø)

src/package-json-file.ts
65.21% <ø> (ø)

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 cb5abb9...e4e9f2c. Read the comment docs.


Index NUR packages

Would it be possible to also import NUR? We don't need to show search results for that on the NixOS homepage however, this would allow it to re-use nixos-search for NUR as well.
We already generate a simple packages.json over all repositories that can be imported. It would be great if there was a unified search that would first search nixpkgs and than fallsback to NUR in case nixpkgs does not have the package.

I would love to see this happen. There are few things we would need to figure out first but on a general note I'm very for this. This that concern me:

Size and usage of our elasticsearch account. we might need to ask for bigger . Do we want to keep all "evaluations" of NUR packages? Are there also NUR options (nixos modules)?
How to include this on the site? It is clear that searching nixpkgs is a primary goal. Should NUR be just another "channel" in the dropdown? Do we need to explain what NUR is to the visitor.

I don't have an answer for any of this yet. But this might be enough to start the conversation.

To make it easier, we don't need to include NUR in the official search.
We could also have a separate github pages page, that provides a combined NUR + Nixpkgs search. My idea is that NUR is some sort of companion people can fallback to if nixpkgs does not have the package.

Scope: We have modules/overlays and home-manager modules in NUR. Right now our index only contains packages. The rest might come later.

Size: We only need the latest NUR evaluation. We don't have different releases. Right now we have 1212 packages (packages.json is 54kb with a lot of redundancy)

I think it's a nice addition since NUR often contains things which is hard to upstream or relatively new packages, which people just want to try out before adding to nixpkgs.

Having a separate index for NUR might probably be best. Probably also a separate page on search.nixos.org.
I also wonder how we will implement search going forward when flakes become a thing. do we want to search for packages in all the flakes? or only in official flakes.

It would make sense to search other flakes. I also have not made up my mind on how to support flakes in NUR. Maybe NUR could converted to an inofficial flakes registry?

Maybe NUR could converted to an inofficial flakes registry?

Maybe the registry service could also support option to also register user flakes. And NUR becomes part of this registry service.

NUR is now part of the registry as of https://github.com/NixOS/flake-registry/pull/2

I'm closing this issue since NUR is part of the flake registry and I keep track of flake search support in #164.
Please reopen if there is any fearure that needed specific for NUR.


reduce noise about slow tests; make a few tests faster, etc.

that's about it.  want to see if it works on appveyor though.

Coverage increased (+0.05%) to 89.481% when pulling 63c2a543575a10a8f8a152ff8bbeca1b6dae5d67 on timing-tweaks into c5d69e0d9cdb494198e1c65a85ef5d58c0687aa3 on master.


Add tests for hit testing

When reviewing the latest PRs from @jkoritzinsky and @donandren I noticed that we don't seem to have unit tests covering this code - we should!

We have tests for hit testing right here: https://github.com/AvaloniaUI/Avalonia/blob/master/tests/Avalonia.Input.UnitTests/InputElement_HitTesting.cs

Oh yeah - ignore this, NCrunch was reporting faulty test coverage it seems and i was too busy to go looking for the tests.
Glad to know that you guys are starting to get to know the code better than me! :)


Gallery doesn't get images saved by the FaceOff node

Is there an existing issue for this problem?

[X] I have searched the existing issues

Operating system
Linux
GPU vendor
None (CPU)
GPU model
No response
GPU VRAM
No response
Version number
4.0.4
Browser
firefox-124.0.2-2.fc38.x86_64
Python dependencies
No response
What happened
The images generated by the FaceOff module do not appear in the Gallery (right-hand panel). Yet, they appear after reloading the browser window.
What you expected to happen
Images to appear right away.
How to reproduce the problem
Just use the FaceOff module with saving option on: images are not shown at once.
Additional context
No response
Discord username
cachochantun

In order to add images to the gallery, we use some simple logic that tests if the node's output is exactly an ImageOutput.
The FaceOff node output contains images, but isn't exactly an ImageOutput - it's a FaceOffOutput.
The logic needs to be a bit more sophisticated to handle this. Might need some changes to how outputs are handled on the backend and/or socket events.


numa lib link

Looks like when I pushed the code, I added the wrong cmake file given it was inside a submodule. Need to add.
/usr/bin/ld: git-dep/shm/lib/libshm.a(shm.cpp.o): in function `shm::move_to_tid_numa(int, void*, unsigned long)':
shm.cpp:(.text+0x18df): undefined reference to `numa_available'
/usr/bin/ld: shm.cpp:(.text+0x18f8): undefined reference to `numa_num_configured_nodes'
/usr/bin/ld: shm.cpp:(.text+0x1924): undefined reference to `numa_node_of_cpu'
/usr/bin/ld: shm.cpp:(.text+0x1aa8): undefined reference to `numa_node_of_cpu'
/usr/bin/ld: shm.cpp:(.text+0x1d05): undefined reference to `move_pages'
collect2: error: ld returned 1 exit status

Fixed.


codeworld-api-2.1.0: install failed

Hi, I have recently tried to reinstall codeworld and I'm getting the following error when I'm trying to build [./build.sh]
Building codeworld-api-<IP_ADDRESS>...
Preprocessing library codeworld-api-<IP_ADDRESS>...
[5 of 6] Compiling CodeWorld.Driver ( src/CodeWorld/Driver.hs, dist/build/CodeWorld/Driver.js_o )

src/CodeWorld/Driver.hs:86:1: error:
    Failed to load interface for ‘GHCJS.DOM.ClientRect’
    Use -v to see a list of the files searched for.
cabal: Leaving directory './codeworld-api/'
cabal: Error: some packages failed to install:
codeworld-api-<IP_ADDRESS> failed during the building phase. The exception was:
ExitFailure 1
codeworld-base-<IP_ADDRESS> depends on codeworld-api-<IP_ADDRESS> which failed to
install.
============================
= Aborting: Command failed =
============================

I tried debugging and googling, but that didn't help a lot. Any plausible cause for this error ?
The current latest commit is c33df7c

Seems to be caused by https://github.com/ghcjs/ghcjs-dom/commit/3c495cd71b2bdcc2013d305d2fab944fd9b5650a
Now to find the fix...

Some more quick research: the replacement seems to be GHCJS.DOM.DOMRect.  However, the members left and top have been replaced by x and y.  I want to be sure this works in other browsers before committing to it.  Until then, one fix would be to choose a specific commit for the ghcjs-dom dependency in install.sh.  Anything before https://github.com/ghcjs/ghcjs-dom/commit/3c495cd71b2bdcc2013d305d2fab944fd9b5650a should do fine.

Opened https://github.com/ghcjs/ghcjs-dom/issues/69 to track the underlying blocker for migration.  Until then, I'll modify install.sh to install the older ghcjs-dom version.

I've pushed some fixes, and this should install and build from a fresh checkout.
I switched away from using the git version of ghcjs-dom, to hackage.  The version from git was necessary in the early days of the project, but isn't needed any more.  That allows me to add version bounds, and I've done so to exclude the 0.9 version that deleted ClientRect.
The long-term solution is to migrate this code to use DOMRectReadOnly instead, but I'm unclear on how to do so.  The bug against ghcjs-dom addresses that.

The long-term solution is to migrate this code to use DOMRectReadOnly instead, but I'm unclear on how to do so.

There is an instance IsDOMRectReadOnly DOMRect in GHCJS.DOM.Types, so you can use all the functions in GHCJS.DOM.DOMRectReadOnly with DOMRect.
It also means you can use GHCJS.DOM.Types.toDOMRectReadOnly on a DOMRect to get a DOMRectReadOnly (this does not actually copy the object so if you use the set* functions on the DOMRect they will mutate the DOMRectReadOnly as well).


Continuous Tests with Windows

Wix Embedded MySQL uses Appveyor for this.

SBT Native Packager's configuration should be considered authoritative.

For future reference, AppVeyor's YML validation tool is a huge help. (Duh. Was hard to find.)


Allow running for multiple users

If I'm running two users on my system, chunkwm will now run for both users, but my second user is unable to get a lock on the pid file because the first user already has it. Is it possible to make similar changes here to allow to users to run skhd?

Fixed on master.

Part of release v0.3.4


Extra '[' is prepended to ARM value when loadTextContent loads text that starts with a '['

Bicep version
run bicep --version via the Bicep CLI, az bicep version via the AZ CLI or via VS code by navigating to the extensions tab and searching for Bicep
Bicep CLI version 0.12.40 (41892bd0fb)
Describe the bug
A clear and concise description of what the bug is vs what you expected to happen
Extra '[' is prepended to ARM value when loadTextContent loads text that starts with a '['
To Reproduce
create a plain text file 'testfile.txt' as
[somedata]

create a bicep file as
var defs = loadTextContent('testfile.txt')

compiling to arm json produces the result (note extra prepended '[' in the string for the defs variable):
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "<IP_ADDRESS>77",
      "templateHash": "6694211267094298175"
    }
  },
  "variables": {
    "defs": "[[somedata]"
  },
  "resources": []
}

expected result
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "<IP_ADDRESS>77",
      "templateHash": "6694211267094298175"
    }
  },
  "variables": {
    "defs": "[somedata]"
  },
  "resources": []
}

Additional context

Bicep is doing the right thing here. The ARM expression parser considers anything between [ and ] as an expression, so [somedata] would result in a deployment failure (as it would be interpreted as a language expression rather than a string). [[ is the escape sequence for a string beginning with [, so ARM's expression parser would interpret [[somedata] as a string with value [somedata].


Changing Block Icon

Hello Ryan,
I wanted to change block icons, I figure out replacing the css contents with selector can works fine
  .icon-number:before {
  content: '\f468';
  font-family: "Font Awesome 6 free";
	font-weight: 900;
}

Yes, it is..
but I don't know what to do to add and change a new block, class names are the same of that icons. Is there a way to accomplish this situation?

https://www.iconfont.cn/
You can use iconfont to reconfigure a new set of icons, which may be a bit complicated

I changed a little bit of my code block with helps of CSS, then it works.
Solution:
._blockItem_1ajtj_6:nth-last-child(1) .iconfont::before {
  content: '\f04d';
  font-family: "Font Awesome 6 free";
	font-weight: 900;
}

._blockItem_1ajtj_6:nth-last-child(2) .iconfont::before {
  content: '\f468';
  font-family: "Font Awesome 6 free";
	font-weight: 900;
}

Thank you, anyway.


[backport]Doc: Fix source links for functions defined with contextlib.contextmanager

#3245

LGTM!


Multiple joins skip relations (data missing)

Query without joins runs fine (super slow tho, hundreds of queries run sequentially):

And with a join it simply ignores that find for some reason and ends up not returning data for that node:

Note that the first join at the category level is working as expected, a single query returns all the categories + products. I wan't the same for all the product options in a product but it just works by running 1:N queries. Any idea what I'm doing wrong?

Enabling dataloader actually helped A LOT without using joins

I would not recommend using joins unless it's necessary. Joins will make query slow since it uses include option from sequelize. If you don't use joins, dataloader will kick in and will only run N+1 queries.
If you could explain what you are trying to achieve here, I will be able to suggest a solution.

Hi @alirizwan, To come back to this I've had some similar issues where the joins are taking forever, So like @jor3l I've enabled the dataloader but noticed there are some issues around joins with null values. It significantly increased performance once enabled but some queries don't work. An example of an issue i'm getting is in the screenshot below.

I don't know if this is similarly related to another issue other libraries have had previously around dataloaders and getting back the same error. For example
https://github.com/aerogear/graphback/issues/1859
Happy to have a call to discuss if anything's unclear or if you need more detail.
Thanks,
Lewis

I think a call would be great. Let's discuss it and perhaps find a solution together :)

Hi @alirizwan, To come back to this I've had some similar issues where the joins are taking forever, So like @jor3l I've enabled the dataloader but noticed there are some issues around joins with null values. It significantly increased performance once enabled but some queries don't work. An example of an issue i'm getting is in the screenshot below.

I don't know if this is similarly related to another issue other libraries have had previously around dataloaders and getting back the same error. For example
aerogear/graphback#1859
Happy to have a call to discuss if anything's unclear or if you need more detail.
Thanks,
Lewis

I think a call would be great. Let's discuss it and perhaps find a solution together :)

I've just emailed you to setup a call 👍🏻


SOAP 1.2 Headers and HTTP Content-Type - Q&D Fix

Even if its a Quick and Dirty fix, it helps to work with my SOAP12 Service flawless.
Theres a new function setSOAPVersion12 for the client (true | false) implemented to set the SOAP12 Headers and Content-Type. As well it can be determined by getSOAPVersion12 to see if Soap12 is enabled.

Thank you, this works perfectly!

Hello @neversaid - thanks a lot for your contribution and sorry for the extremely long delay :disappointed:
In order to get your PR merged I'll have to ask you to follow our Guideline on Submitting a Pull Request and work through the open points, which are:

Add accompanying tests
Rebase/Squash your commits into a single one (more information about this topic is given in the guideline)
Run npm test locally and take a look at the Travis CI logs in order to make the PR pass all the tests

Thanks a lot for your patience :+1:

I am sorry, but how can I use this? I got the custom repository in my package.json, but how can I invoke the setSOAPVersion12 ?

If you've created a client, you should be able to call client.setSOAPVersion12(true); :+1:

Has this been released? It will be really nice to have it.

Closing for lack of activity.

request-response test would be enough?

We'd need a proper PR which respects our Guidelines on Submitting a Pull Request stated in our CONTRIBUTING.md file :+1:

We have problem in setting the credential to the service call in node soap.
soap.createClient(url, {
wsdl_options: {
proxy: '---------',
timeout: 5000,
connection: 'keep-alive',
pfx: publicKey,
strictSSL: true,
passphrase: password
    }
}, function (err, client) {
    if (err)
    {
        console.log(err)
    } else
    {

     }

//we are able to get the client object, so the connection is estableshed now. But when we are trying to call the soap service method from the client object , like client.soapname.port.function. We are not able to call it. Simply the soap methods are not calling. Is it required to pass the certificate credential again in service method call ? If so, then how can we  pass certificate in function call ?
The call is as follows :
client.Servicename.port.methodName({}, function (err, res) {
if (err) {
} else {
}
});
We are not able to call the method


Translation into Spanish

initial seedings for French translation
forgot to delete a sentence
initial seeding for Chinese (simplified) translation
Translate into Spanish

@NSoiffer  sorry, I'll create a PR  against your translations branch.


Exchange Online Legacy Authentication - Caching

In Block Legacy traffic from the outside scenario, what happens with cached log ins Exchange Online?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ad5f26dc-2f8f-ef76-3d20-a0a42d2bbada
Version Independent ID: a0e971d1-05f2-2c21-06d4-60c087d45c0a
Content: Set up SharePoint Online and Exchange Online for Azure Active Directory conditional access
Content Source: articles/active-directory/active-directory-conditional-access-no-modern-authentication.md
Service: active-directory
GitHub Login: @MarkusVi
Microsoft Alias: markvi

https://blogs.technet.microsoft.com/exchangeteamjp/2017/10/27/authentication-cache-for-exchange-online-and-outlook-2/ See this reference on cached log ins.

@montereyharris  Thanks for your feedback! We will investigate and update as appropriate.

@montereyharris The adfs authorization rules will work when a connection is made to adfs for authentication. Once the login is cached, the connection is not made to adfs  and authentication will work as expected. However, when cached login expires, the new connection is made to adfs and rules will be applicable as configured.

@montereyharris We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.

So if a user logs in on with in the network on a legacy application their
account will be vulnerable from the outside?
Monterey Harris, CCNA
On Mon, Mar 26, 2018 at 3:34 PM, Mohit Garg<EMAIL_ADDRESS>wrote:

@montereyharris https://github.com/montereyharris The adfs
authorization rules will work when a connection is made to adfs for
authentication. Once the login is cached, the connection is not made to
adfs and authentication will work as expected. However, when cached login
expires, the new connection is made to adfs and rules will be applicable as
configured.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/6293#issuecomment-376302651,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APmU-OSSedNcHnh4T7UI2Xsha1mAHcSLks5tiVDqgaJpZM4S7OKf
.

@montereyharris Please open a new MSDN forum post to have further discussion of this issue and community will help address your query. Please refer to below link to MSDN forum to ask new question -
https://social.msdn.microsoft.com/Forums/azure/en-US/newthread?category=windowsazureplatform


Troubleshooting page in docs

Description
Add a troubleshooting page that explains :

how to solve [TMDB] failed to retrieve XXX because TMDB is blocked by the DNS server
how to fix some slowdowns / ipv6 errors with the forceIpv4First env var

Desired Behavior
/
Additional Context
No response
Code of Conduct

[x] I agree to follow Jellyseerr's Code of Conduct

:tada: This issue has been resolved in version 2.2.0 :tada:
The release is available on:

v2.2.0
GitHub release

Your semantic-release bot :package::rocket:


Fix booleanize closes #35

PR for godot_header is on the way

I updated the godot_headers and haven't updated these bindings yet, some files are in new subfolders, so this needs more changing. Feel free to do it if you want, otherwise I'll do it in a day or two.

I'm working on it

Closing as, #40 will fixes this as well


Edits to "Historical catches plot"

[ ] Label "Select one or more catch scenarios" (as the user can select multiple)
[ ] Remove the Historical catches from the list as it's not a scenario - if it's useful to be able to plot without historical catches, make a check box for that ("Show historical catches")
[ ] The title "Historical catches" is bit misleading to the information the user gets from this plot, maybe catch scenarios is more appropriate?


Adding a bootstrap Swagger example file

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] Validation errors from the Linter extension for VS Code have all been fixed for this spec. (Note: for large, previously checked in specs, there will likely be many errors shown. Please contact our team so we can set a timeframe for fixing these errors if your PR is not going to address them).
[x] The spec follows the patterns described in the Swagger good patterns document unless the service API makes this impossible.

Fixing broken documentation links

@kirthik This PR adds a "getting started" bootstrap file that authors can start from

No modification for Ruby

No modification for Python

No modification for NodeJS