Cherry-pick fixes from master

Fix for Windows Store python not showing up
Fix for unittest failing due to isolation when running discovery

Codecov Report

Merging #11367 into release-2020.04 will decrease coverage by 0.02%.
The diff coverage is 40.00%.

@@                 Coverage Diff                 @@
##           release-2020.04   #11367      +/-   ##
===================================================
- Coverage            61.29%   61.27%   -0.03%
===================================================
  Files                  597      597
  Lines                33033    33034       +1
  Branches              4682     4682
===================================================
- Hits                 20249    20240       -9
+ Misses               12308    11770     -538
- Partials               476     1024     +548

Impacted Files
Coverage Δ

...ient/testing/unittest/services/discoveryService.ts
100.00% <ø> (ø)

src/client/interpreter/locators/helpers.ts
70.58% <40.00%> (+0.58%)
:arrow_up:

src/datascience-ui/react-common/arePathsSame.ts
75.00% <0.00%> (-12.50%)
:arrow_down:

src/client/common/utils/platform.ts
64.70% <0.00%> (-11.77%)
:arrow_down:

...ence/ipywidgets/localWidgetScriptSourceProvider.ts
88.13% <0.00%> (-3.39%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/common/process/internal/python.ts
58.82% <0.00%> (-1.97%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

...client/datascience/kernel-launcher/kernelFinder.ts
75.70% <0.00%> (-0.94%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

... and 131 more

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 03bfd82...acaadf0. Read the comment docs.

Tests have passed but github is not updating for some reason.
https://dev.azure.com/ms/vscode-python/_build/results?buildId=75660&view=results


Replace special character in playlist.xml

replace with make variable or character reference

Signed-off-by: Renfei Wang<EMAIL_ADDRESS>

This PR is related to TKG changes to use XML::Parser module, so special characters in playlist.xml need to be replaced. https://github.com/eclipse/openj9/pull/4785

Could you please provide Grinder links if possible? Thanks

Tested both level sanity and extended for group openjdk_regression and system internally.


[Event Request] Table 7311 "Warehouse Journal Line" - OnBeforeSetUpNewLineWhseJnlBatchGet

We are migrating our code from NAV 2018 to BC16.4. In the Table 7311 "Warehouse Journal Line", in the procedure SetUpNewLine, we need to add a condition to the use of the WhseJnlBatch.Get(). To do so, we need a IsHandled flag and an event publisher, like this :

With this integration event :

Do you think it could be possible ?
Thank you for your work.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


WebLogic on AKS Deployment fails when SSL/TLS (using upload keystore) is enabled due to JDK Segmentation fault error

WebLogic on AKS Deployment fails when SSL/TLS is enabled due to JDK Segmentation fault error
Steps to reproduce:

Deploy WebLogic on AKS with SSL/TLS enabled using the upload keystore option
The WLS on AKS deployment fails in the validate-parameter-and-fail-fast sub deployment
The error message in the deployment container logs show that the error is occuring when keytool command is executed to validate the keystore.
The error message is
userscript.sh: line 85: 269 Segmentation fault java -version Errors happen during: validate Identity Keystore..

Complete container Log:
Adding certificates not required Registering and setting the cloud Cloud is already registered Registering and setting the cloud completed Check compute resources: passed! Installing docker 0 Usage: docker [OPTIONS] COMMAND A self-sufficient runtime for containers Options: --config string Location of client config files (default "/root/.docker") -c, --context string Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use") -D, --debug Enable debug mode -H, --host list Daemon socket(s) to connect to -l, --log-level string Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info") --tls Use TLS; implied by --tlsverify --tlscacert string Trust certs signed only by this CA (default "/root/.docker/ca.pem") --tlscert string Path to TLS certificate file (default "/root/.docker/cert.pem") --tlskey string Path to TLS key file (default "/root/.docker/key.pem") --tlsverify Use TLS and verify the remote -v, --version Print version information and quit Management Commands: builder Manage builds config Manage Docker configs container Manage containers context Manage contexts image Manage images manifest Manage Docker image manifests and manifest lists network Manage networks node Manage Swarm nodes plugin Manage plugins secret Manage Docker secrets service Manage services stack Manage Docker stacks swarm Manage Swarm system Manage Docker trust Manage trust on Docker images volume Manage volumes Commands: attach Attach local standard input, output, and error streams to a running container build Build an image from a Dockerfile commit Create a new image from a container's changes cp Copy files/folders between a container and the local filesystem create Create a new container diff Inspect changes to files or directories on a container's filesystem events Get real time events from the server exec Run a command in a running container export Export a container's filesystem as a tar archive history Show the history of an image images List images import Import the contents from a tarball to create a filesystem image info Display system-wide information inspect Return low-level information on Docker objects kill Kill one or more running containers load Load an image from a tar archive or STDIN login Log in to a Docker registry logout Log out from a Docker registry logs Fetch the logs of a container pause Pause all processes within one or more containers port List port mappings or a specific mapping for the container ps List containers pull Pull an image or a repository from a registry push Push an image or a repository to a registry rename Rename a container restart Restart one or more containers rm Remove one or more containers rmi Remove one or more images run Run a command in a new container save Save one or more images to a tar archive (streamed to STDOUT by default) search Search the Docker Hub for images start Start one or more stopped containers stats Display a live stream of container(s) resource usage statistics stop Stop one or more running containers tag Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE top Display the running processes of a container unpause Unpause all processes within one or more containers update Update configuration of one or more containers version Show the Docker version information wait Block until one or more containers stop, then print their exit codes Run 'docker COMMAND --help' for more information on a command. To get more help with docker, check out our guides at https://docs.docker.com/go/guides/ Removing login credentials for https://index.docker.io/v1/ Login Succeeded login OCR with user<EMAIL_ADDRESS>Check OCR account: passed! image path: container-registry.oracle.com/middleware/weblogic:<IP_ADDRESS>-11 Check OCR image container-registry.oracle.com/middleware/weblogic:<IP_ADDRESS>-11: passed! check if admin user enabled in ACR wlsaksacrvpctcwaleem2m query 'adminUserEnabled' property of ACR wlsaksacrvpctcwaleem2m Installing openjdk11 0 java version WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store WARNING: This operation will delete the manifest 'sha256:5acc7d87ae24e4a925dec014aa8a2a24af05008a6dee778775f58059bb4bed8f' and all the following images: 'tmp1686140287:<IP_ADDRESS>-11' userscript.sh: line 85: 269 Segmentation fault java -version Errors happen during: validate Identity Keystore..

The "Segmentation fault" error which occurs when executing java -version command inside the AKS container has been resolved.
The solution was to upgrade the installed packages in the Alpine Linux OS available inside the AKS container.
To upgrade the installed packages, we need to use the apk upgrade command, before installing open JDK11 required for validating SSL keystores.
 # Install Microsoft OpenJDK
        apk upgrade
        apk add openjdk11 \
            --no-cache \
            -q --repository=http://dl-cdn.alpinelinux.org/alpine/edge/community

This fix has submitted in the local git repo, using commit # 8183aea
The fix will be merged into the oracle/weblogic-azure git repo once all the WLS-on-AKS upgrade testing is completed.


meteo-qt: init at 3.4

Description of changes
add meteo-qt

System tray application for weather status information

from https://github.com/dglent/meteo-qt
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

By the way, you may want to add your git email to Github so it show your commits correctly.

The commit would not have your profile picture next to it.


Release 1.5.3

Codecov Report
Base: 90.50% // Head: 90.48% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (602e2c7) compared to base (c635a7a).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop      #35      +/-   ##
===========================================
- Coverage    90.50%   90.48%   -0.02%
===========================================
  Files           79       69      -10
  Lines         1990     1797     -193
===========================================
- Hits          1801     1626     -175
+ Misses         189      171      -18

Flag
Coverage Δ

flat_generator
90.48% <ø> (ø)

flat_orm
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

flat_orm/lib/src/adapter/migration_adapter.dart

flat_orm/lib/src/adapter/insertion_adapter.dart

flat_orm/lib/src/adapter/query_adapter.dart

flat_orm/lib/src/util/primary_key_helper.dart

flat_orm/lib/src/adapter/deletion_adapter.dart

flat_orm/lib/src/adapter/update_adapter.dart

flat_orm/lib/src/sqflite_database_factory.dart

...src/extension/on_conflict_strategy_extensions.dart

flat_orm/lib/src/callback.dart

flat_orm/lib/src/migration.dart

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Simpler alternative dbg!() macro

This is a simpler and more opinionated counter-proposal to RFC 2173.
HTML view

Things I'd like to see included from RFC 2173:

The reference and the guide level explanations should note that the output format is unspecified and should not be relied upon.
An explanation that calling dbg!(val) moves val (unless typeof(val): Copy).
Notes/plans for/on specialization. If we don't include this in the macro right now, I'd like to see the RFC propose that we include WrapDebug once stabilization land without going through another RFC process again.
Some of the design rationale of the old RFC still applies to the new one, see: https://github.com/Centril/rfcs/blob/rfc/quick-debug-macro/text/0000-quick-debug-macro.md#formerly-unresolved-questions
(I'll work up a PR against your branch for this soon-ish).

An explanation that calling dbg!(val) moves val (unless typeof(val): Copy).

does it? how come? that seems like a bad idea™ , unless that's also true for (e)println!(), which seems to not be the case(due to magic) ?

does it? how come? that seems like a bad idea™ , unless that's also true for (e)println!(), which seems to not be the case(due to magic) ?

Yes, it does. It is not a bad idea, but instead good design. Not having move semantics would mean that you would have to evaluate the expression passed twice, and thus also any side effects. If you don't want to move p you can always use a reference as in: dbg!(&p) and then you move the reference instead, which you can do any number of times.

Ah, my bad: I forgot dbg!(p) is returning p which is unlike (e)println!.
I stand corrected :)
(deleted)what I wanted to write before realizing that

Not having move semantics would mean that you would have to evaluate the expression passed twice, and thus also any side effects. If you don't want to move p you can always use a reference as in: dbg!(&p) and then you move the reference instead

I guess I don't see what is gained by moving it? And why doesn't it happen for println! too?
If you use &p instead of p doesn't the same evaluate the expression passed twice happen?
https://play.rust-lang.org/?gist=178efc0e3b3c9420dde9df730c15d3cf&version=stable

I think this macro should be conditionally compiled, just like debug assertions are. It's rather important to distinguish debugging info from other kinds of logging. If dbg!() messages were to be always included then that would be very discouraging because you cannot always know, when writing some code, where and how that piece of code will be used.

@Centril I’ve added some wording for the exact formatting and for ownership. This RFC makes no plan for specialization. I don’t see the point of printing a line that says nothing about the value instead of failing to compile with !Debug types.
@repax I disagree, for reasons given in the Alternative section of the RFC.

@SimonSapin, debug logging for bugs that only manifest during optimisation is a fringe case. Designing the dbg!() macro for this scenario seems ill-advised to me. Not only are these cases extremly rare, naming the macro dbg!() like this suggest that it serves as a debugging/development aid -- not being present in release builds.
Following the principle of least astonishment is not a bad decision. In this case, debug assertions and debug messages are both assumed to belong to debugging. If you write a routine that include dbg!() messages -- especially if the code base is large or is a multi-person project, or if it is part of a library -- you cannot know all the situations and context in which the debug macro is going to be used. It might be used in a loop indirectly though a third-party caller, or it might leak internal information that is harmless during development but potentially disastrous in a deployed release build.
We could not permit dbg!() for debugging purposes in our products knowing that it might unintentionally slip through to deployment/production, but would require more rules for review and deployment. In this case dbg!() is better suited in a separate library on crates.io. I think eprintln can do most of the things that dbg!() aims to do.

I’ve always found the phrase “principle of least astonishment” very unconvincing. It sounds fancy, but it does nothing to justify what is found to be “astonishing”, by whom, or why.
I my mind dbg!(x) is a shorter version of println!("{:?}", x). If you add it to your code while debugging and forget to remove it before pushing a git commit, you’re already doing something wrong IMO. The situation where the performance cost would matter should not occur in the first place.

It's easy to make mistakes -- that's all. You can, and should, leave debug assertions when committing, but not debug messages? You still haven't motivated why the fringe case of optimisations-only bugs have precedence to regularity in the design.
One aim of good design should be to minimise the risk of errors, not just push the responsibility to someone else, or brush off good heuristics as fancy sounding. At least, that's something I believe.
Perhaps this macro is better suited in a library, or with a different name?

And you haven’t argued how disabling printing in release mode is more "regular" (or what that means). I might even say that I would personally find it astonishing.
As to having this macro in a library, that makes it effectively worthless in my opinion. As already discussed in https://github.com/rust-lang/rfcs/pull/2173, the whole point is having something that easier to use than println!("{:?}", foo), and println!("{:?}", foo) is easier than adding a dependency.

Related idea. How about changing the syntax for 'debug!', so that the following three statements have the same effect.
debug!("Values x = {:?} y = {:?}", x, y);
debug!("Values x = {:?}", x; y);
debug!("Values"; x, y);

Note arguments after the semicolon are formatted differently.

Related idea. How about changing the syntax for 'debug!', so that the following three statements have the same effect.

Entirely orthogonal if you are talking about the log crate as that requires doing extern crate log; and other setup as well. The dbg! macro is intended for quick and dirty debugging and optimized for just starting out & the playground.

@SimonSapin

I don’t see the point of printing a line that says nothing about the value instead of failing to compile with !Debug types.

The point is quite important and is discussed at:

https://github.com/Centril/rfcs/blob/rfc/quick-debug-macro/text/0000-quick-debug-macro.md#7-should-the-macro-accept-expressions-where-typeofexpr--debug
https://github.com/rust-lang/rfcs/pull/2173#issuecomment-338812602
https://github.com/rust-lang/rfcs/pull/2173#issuecomment-338838834

The value of specialization and fallback here is that you can start debugging anywhere in generic code without having a Debug bound infecting everything upwards. This is especially beneficial if you are deep within a generic call stack.

@rpjohnst The bikeshed so far: https://github.com/Centril/rfcs/blob/rfc/quick-debug-macro/text/0000-quick-debug-macro.md#bikeshed-the-name-of-the-macro
As a Haskeller I'm almost compelled to favor a Haskell based name, but.. I think this will cause users to think that the stack trace will somehow be printed out if you call trace!(..), so I think dbg!(..) more clearly associates this with debugging and the Debug trait.

I just want to register my support for this proposal; I think it strikes a good balance between packaging up the most impactful bits of the original RFC into a much more streamlined macro. This feels like a good foundation that we can gradually extend as time goes on.

Regarding specialization and !Debug types, I hadn’t considered the case of generic code. However I think that plans for this do not need to be in this RFC: it can be added compatibly as it would only make more programs compile. And keeping this RFC minimal might help its chances to be accepted.

I like this proposal.
I'd like to voice my support for automatically disabling these in release mode. It wouldn't be that helpful for investigation of heisenbugs that happen only in release mode, since mere presence of this statement changes generated code and timing (due to locks on stdout).
On many occasions I have had forgotten to remove my debug println!s, so I welcome a version that saves me this embarrassment.

Idea: assert! uses dbg! internally. This would probably result in a common dbg_plain! macro where dbg! includes the location in the code and dbg_plain! does not. dbg! then becomes { println!("[{}:{}] {}", file!(), line!(), dbg_plain!($val)); $val }

Intuition also suggests that dbg! should be conditional on debug_assertions if the user has experience with the debug_assert! macro.
Conversely, if the user encounters dbg! first and it's not conditional on debug_assertions, their first impression on seeing debug_assert! might be to wonder if assert! outputs to STDOUT while debug_assert! outputs to STDERR but both are unconditional.

dbg! is not an assertion. There could be a new option debug_print. What matters is that this option is disabled by cargo --release.

dbg! is not an assertion.

Good point.

What matters is that this option is disabled by cargo --release.

That was intended to be the thrust of my point but it didn't occur to me to be clear about that. It seems I'm still not fully recovered from that all-nighter I pulled a couple of days ago.

There could be a new option debug_print. What matters is that this option is disabled by cargo --release (unless there's [profile.release] debug_print = true)

I think that the RFC as written is forward compatible with that; for initial simplicity I'd like to not that go route for now; but we can extend the macro in the future if we so wish.

dbg! is not an assertion.

There is some precedent that the log crate uses cfg(debug_assertions) for its debug!.

Don't forget that debug_assertions also implies overflow checks.

So; to break the impasse... I propose we add cfg(debug_log) due to @kornelski and make it default-disabled  on release builds. This flag can then be enabled for release builds by setting a flag inside $HOME/.cargo/config thereby making it a one time setup cost per Rust user. Large projects like servo can configure this in their .cargo/config file, effectively making this a zero time setup cost per user. It is just default-enabled when you build servo, but not otherwise.
The reason for off-by-default on release builds rather than on-by-default is that I think it will benefit most users, who are more likely to be troubled by accidentally merging in dbg! into VCS than the need to find fringe hisenbugs.  Here, I find @kornelski's argument:

It wouldn't be that helpful for investigation of heisenbugs that happen only in release mode, since mere presence of this statement changes generated code and timing (due to locks on stdout).

particularly compelling.
Other debugging crates that offer similar functionality to dbg! can also lean on this debug_log flag, further augmenting its usefulness.

For what it’s worth the bug mentioned in the RFC that only happened in release mode was 100% reliable, not at all dependent on timing. So I don’t accept the “release mode = heisenbug” talking point.
I don’t think there is any point to bother with a Cargo config. It feels like a compromise proposed just for me, but I wouldn’t want to use it. If the team consensus is that dbg! being enabled in release mode by default is unacceptable, then let’s just disable it. Someone who needs release mode debugging can always keep doing what they do today and use println!("{:?}", foo) (and hopefully remember that dbg! is disabled).

The libs team discussed this at today’s triage meeting, we feel comfortable accepting this RFC as-is:
@rfcbot fcp merge
In particular:

We felt that the behavior of this macro should not change in release mode. In addition to bugs that only occur with optimizations, another case that came up was debugging a program that is CPU-intensive enough that a debug build is too slow to be usable.

Using specialization to accept types that do not necessarily implement Debug seems very worthwhile for generic code, but we’re not ready to do so until some form of specialization is stable in the language. However that can still be added later even if dbg!(x: T) is stabilized with a T: Debug requirement at first.

On stderr vs stdout: is there a guarantee that stdout is flushed by dbg!()? AFAIK without flushing this output could be printed out of order with stdout output:
print!("foo");
dbg!("bar");

could end up in a terminal as

bar
foo

Give that printing may be used to trace flow of the program, having things printed out of order could be very problematic.

another case that came up was debugging a program that is CPU-intensive enough that a debug build is too slow to be usable.

This is properly done with:
[profiles.dev]
opt-level = 3

The RFC didn't include a config option under preliminary assumption that output won't be printed in release mode. Now that this has been changed, can the setting be revived?
[profiles.release]
debug_output = false

I don't think flushing an unrelated channel is in the scope of this macro. Flushing the stdout would significantly alter the behavior of the program in an unexpected way for a macro that's printing to stderr, when this macro is designed to do as little as possible.

The RFC didn't include a config option based on a preliminary assumption that output won't be printed in release mode. Now that this has been changed, can the setting be revived?

I’m not following. This RFC hasn’t changed on this point this it was opened.

@SimonSapin regardless of the text of the RFC, that was my impression of the discussion. If that's inaccurate, then nevermind.
Still, I'm very concerned about having dbg!() left on in releases, and worried that it won't be automatically disabled, and doubly worried that I can't even disable it manually.

My understanding is that with this simplified version, you're expected to remove it from the code once you're done with it. RFC 2173 was concerned with adding provisions to leave dbg!() in production code without affecting performance, but I think that was deemed as unneeded complexity. This one is supposed to be treated like any other quick eprintln! that you might add to debug an issue. It doesn't suddenly stop printing once compiled in release mode.

I personally find having to do:
[profiles.release]
debug_output = false

to be a good enough compromise.
But this can be added backwards-compatibly at a later stage.
For now, I really want this macro shipped.

Yes, and I'm questioning that assumption. I see dbg!() as a debugging tool, and not a fancy eprintln!().

@Centril but isn't that weird to have to remove debug setting from release profile?

Still, I'm very concerned about having dbg!() left on in releases, and worried that it won't be automatically disabled, and doubly worried that I can't even disable it manually.

To me this sounds like you really want to use log::debug instead.

log::debug is still compiled into release binaries. By disabling I mean not existing in the binary, and the end user not having ability to restore it.

log::debug is still compiled into release binaries. By disabling I mean not existing in the binary, and the end user not having ability to restore it.

You can choose what levels you want to strip from your binaries: https://docs.rs/log/0.4.5/log/#compile-time-filters

@kornelski I have noted in the past that I think that I think the opt-out approach for release builds is a poor default rather than a good one because it optimizes for fringe cases and for what I think is a small minority of users rather than more casual uses of dbg! and saving users from the embarrassment of accidentally leaving dbg!s in release builds, and that the good default would instead be to have to opt-in to dbg! printing things on release builds. However, as the libs team doesn't seem to agree with me, then opt-out seems to me the next best thing.
That said, I don't find log::debug to be a substitute for this at all. This is not about principled debug logging, but for quick and dirty debugging which you accidentally got merged upstream.

for quick and dirty debugging which you accidentally got merged upstream.

Accidentally means that they should be removed, regardless of their release-mode behavior.

Accidentally means that they should be removed, regardless of their release-mode behavior.

Yes, eventually. But it seems to me worthwhile to save the one who released the software and the person who made the patch some embarrassment in the interim.

A few additional log statements are unlikely to cause that much embarrassment, I would hope. If it's so critical not to log anything accidentally, it would be better to have a tool that greps code changes for dbg! before allowing those changes to be merged into master. I think I've come around to the perspective of the libs team here: it's a more consistent experience for the output to still work on release mode.
If there isn't a good code review process in place, there are much more embarrassing, production-breaking changes that are likely to be merged and deployed, changes that the Rust compiler can't just unilaterally protect its developers from.

@coder543

If it's so critical not to log anything accidentally, it would be better to have a tool that greps code changes for dbg! before allowing those changes to be merged into master.

A very reasonable argument 👍

A few additional log statements are unlikely to cause that much embarrassment, I would hope. If it's so critical not to log anything accidentally, it would be better to have a tool that greps code changes for dbg! before allowing those changes to be merged into master.

My guess is that no team would consider this until it causes a problem, and when it does cause a problem, it will be a hard-to-debug one.
In particular, writing to a file descriptor (a syscall) and flushing (another syscall and I/O) could be problematic. I have been in situations before where all of the extra context switching and I/O overhead caused problems (e.g. timeouts) and it wasn't obvious that the source was a printf somewhere in a loop because all of the extra text ended up in a log that nobody thought to check at first.
I can't imagine why anyone would want this sort of logging on in release mode. These are not at all the sorts of messages that you would want to ship (or even leave in a tool for personal use) IMHO. At the same time, it would be really nice to leave such a logging statement in the code for the next time I need them. Leaving them on in release mode, then, would prevent me from really using this very often...

when it does cause a problem, it will be a hard-to-debug one.

It prints the file and line number for the source of the dbg! statement. I disagree wholeheartedly that this could be hard to debug, when checking the logs should be one of the very first steps of debugging any production issue.

At the same time, it would be really nice to leave such a logging statement in the code for the next time I need them.

This is the only argument I find compelling for having it behave differently between debug mode and release mode, but it is outweighed by the inconsistency that would create in the user experience, by the argument that it is useful to use these dbg! statements to debug code that can't run in a reasonable amount of time without optimizations, and I would personally argue that leaving no-longer-necessary (and a growing number of) dbg! statements in code for an extended period of time lowers the code quality, since it's not clear why certain things are dbg! and others aren't.

Leaving them on in release mode, then, would prevent me from really using this very often...

That's fine. This macro isn't meant to be everything to everyone. That was RFC 2173. What would you use instead of this, though? Just saying you're not going to use it isn't very compelling. Personally. if you want to log certain things long-term, I would suggest using debug! or info! and then just adjusting which log-levels are compiled into your release binaries statically, as mentioned in an earlier comment above.

At the same time, it would be really nice to leave such a logging statement in the code for the next time I need them.

Indeed, this macro is not the appropriate tool for such logging.

can't run in a reasonable amount of time without optimizations and therefore must be compiled in release

That is wrong assumption. Debug mode can optimize code just as well as the release mode does. You can specify opt-level = 3 in the debug profile. The image processing and compression projects that I work on already do that.
So again: release mode is never needed for speed. Debug mode can have optimizations enabled.

debug-assertions can take arbitrary amounts of time to compute, so that setting would also have to be adjusted. Maybe we can't afford overflow-checks to reproduce this bug... If you configure your debug profile to be identical to your release profile just to include log statements from dbg!, that seems like total overkill. If we carry this argument down a slippery slope, we could argue that you only need one profile, and there's no need to even have multiple compilation profiles.

@coder543 I don't follow the problem you're trying to describe. There's no need to flip debug profile settings on and off to "just include log statements". They stay on all the time, because that's necessary for the typical edit-run-debug workflow that is just a normal part of working with the code.

you're suggesting to flip settings in the debug profile to keep log statements, since you want them to disappear in the release profile. That's what my comment discusses. Being required to alter your debug profile to match your release profile just to be able to debug an issue is not an enjoyable prospect, because then you have two identical profiles, with the only difference being whether dbg! is enabled or not. I don't think that's reasonable.

No, that's not what I'm saying. I'm sorry if I'm not understood.
You work with the code day to day, bug by bug.
So in order to be able to use the debug mode at all, you will adjust it. Regardless of dbg!(). Maybe you just want run cargo run rather than cargo run --release all the time. Or maybe project needs optimizations to run, but overflow checks are still fast enough.
Regardless, it's useful to have debug mode working with usable speed. I mean overall, not related to the macro.
So you're going to have the debug mode working anyway. Then adding and removing dbg!() is free. You don't "adjust config to switch to debug mode". You just continue to use it, as you did everyday.

 But there are also others who want debug_assert, but one that prints instead of panicking.
Because Rust is unlikely to have two separate macros for this, let's make one that fits both cases.

I believe it can be extended in the future to support both use cases without complicating this RFC.

Can this RFC say that printing in release mode is not guaranteed?
I'm fine if it would in initial implementation, but I'd be very unhappy if later changes were rejected because not printing in release mode was a breaking change.

I had hoped for this feature to be targeted at developers only, providing developer-friendly information. The point of leaving these !dbg statements in the source code is to benefit people coming in and continuing the development.
But these cannot be disabled for production use. Instead, the libs team seems to recommend going with the log dependency for this dev2dev use -- which apparently can be disabled from release builds.
I'd rather see these flipped: !dbg for dev, and log::debug for production.

I prefer the approach mentioned here. I think leaving dbg! in code long-term is a niche use-case.

I agree that dgb!() shoudn't be left in code long term (to me long means months to years). However, I can see myself leaving it for days to weeks in unstable/buggy parts of code I want to "keep an eye on".
With projects that have frequent/continuous releases there may always be some dbg!() in the code all the time, even if it isn't the same instance.

Maybe we can have a cargo fix to automatically remove the dbg!() and rust to warn when building with dbg!() on release mode?

That still doesn't really support the use case where one wants to switch between debug and release though

@mark-i-m This particular RFC very consciously chooses not to support every use case. It was written after another proposal in this space was deemed “too complicated to enter the standard library”: https://github.com/rust-lang/rfcs/pull/2173#issuecomment-372419943.
This does not stop other libraries or proposals from supporting other use cases.

@SimonSapin What do you think about:

Can this RFC say that printing in release mode is not guaranteed?

That seems to me an utterly reasonable compromise to make that gives us the ability to at least to get some usage experience and see how often dbg! is used on release builds. If we make it a guarantee, we can always do that later after experience has been gained.
In other words, what may be lacking in this discussion is some empirical data to guide decision making.

I'd like to add some feedback regarding dbg! in release builds:
In the past I've come across nasty bugs in my C++ code which only manifest in release builds (due to triggering UB unintentionally), while I've yet to encounter this problem in Rust (despite my unsafe usage) it seems like a valid use case of debugging 'release' builds during development.
So uh definitely in favour of being able to use this nifty macro in 'release' builds, but I care less about how exactly this is done (debug_print, debug profile optimized builds, or otherwise).

Oh, I didn't realize dbg! was being considered for removal in release builds. I would like to add a strong vote in favor of allowing dbg! to be used in release builds, since I do somewhat frequently need to debug with release builds. I would also be OK with it being disabled by default but with a way to opt-into adding it (similar to how debug symbols are not included in release binaries by default).

With 2 days to go from Finished-FCP, could someone from T-libs say that they think of my suggestion to do what I suggested in https://github.com/rust-lang/rfcs/pull/2361#issuecomment-419107075?
cc @alexcrichton

My personal opinion is that we should guarantee the same result in all builds. It's just a macro in the standard library and fancier functionality (like controlling at build time whether it's on/off) can always be placed on crates.io

I'll merge (and implement) this RFC in an hour or so.

@vi:

The exact output printed by this macro should not be relied upon and is subject to future changes.

I interpret this as a possibility to turn off the output. After all, no output is a subset of any output. NB, semantically dbg! will still take ownership of what's passed to it.

Huzzah! This RFC has been merged!
Tracking issue: https://github.com/rust-lang/rust/issues/54306

Took a bit more time than I wanted to get to this; but I am working on an implementation right now.

@gilescope println!("{:#?}", x) doesn't move x, it borrows x, so I'm not sure what you mean.

Hmm, will need to check that, but the RFC seemed to be suggesting that it was going to move not borrow x for dbg!(x):
Move semantics
The dbg!(x) macro moves the value x and takes ownership of it, unless the type of x implements Copy, and returns x unchanged. If you want to retain ownership of the value, you can instead borrow x with dbg!(&x).

The macro takes ownership of the input passed because it then returns it, so you can do dbg!(a) + b which will have the same result as a + b but will also print a.

Hmm... come to think of it, that seems like it may have the unfortunate side effect of being used like this:
fn foo(arg: Bar) {
    dbg!(arg);
    baz(&arg); // error: `arg` was moved above!
}

Perhaps we need some sort of unused result lint?

I think this should not be #[must_use]. Printing a value (which might be Copy) in a statement by itself without using the return is an important use case IMO.
If moving / requiring a manual dbg!(&foo) borrow turns out annoying enough for !Copy types, I’d rather have the macro borrow implicitly and potentially give up on returning the value.

@SimonSapin
OK; I agree with you on #[must_use]...

I’d rather have the macro borrow implicitly and potentially give up on returning the value.

but I don't agree with this. This was an important design choice in allowing the user to write dbg!(a) + b and such things without having to create intermediate let bindings... Without it, the expressive power and usefulness diminishes a lot.

I completely agree with @Centril here. The ability to use this in the middle of an expression is the key feature IMHO.

I don't think it will be necessary anyways to do such a change because the macro already tells the user what the problem is clearly:
19 |     baz(&arg);
   |          ^^^ value used here after move

The main problem is that the error is "incorrectly spanned":
4  |             tmp => {
   |             --- value moved here

You would rather want to say:
L |    dbg!(arg);
  |         --- value moved here; try borrowing with `&arg` instead?

This seems like a general problem with macros which we should find a general solution to rather than institute an ergonomics regression...

@gilescope Ah, my bad, I thought you meant println! moves, not dbg!, in https://github.com/rust-lang/rfcs/pull/2361#issuecomment-423794837.

Doesn't this evaluate expr twice?

If you use it in an expression, I would imagine it just evaluates it once, right?
foo(dbg!(<fmt>, <expr>));

I imagine it would expand to something like
foo({
    let value = <expr>;
    println!(<fmt>, value);
    value
});

Whoops, my mistake. Thanks!


PHP 8.1 Fix BreadcrumbIterator.php

ArrayIterator fix for php 8.1 instead of suppressing the errors.
Tested on debian 11, CentOS 7/8 and Cloudlinux 7 with php 8.1.6 and php 8.1.5

Does the ReturnTypeWillChange attribute cause an issue for you in PHP 8.1? The plan is to keep it there until we drop support for PHP 7.4.

Not really, other then spamming log file about it (in debug mode). But php 7.4 active support is already 6 months EOL, and 6 more months to go for security updates. So if people still haven't updated to at least php 8.0 they will not do so in the 6 upcomming months i think. Either way i fixed it on my own projects in the vendor directory, just have to watch out when i auto update via composer.

I'm going to leave this until we officially drop PHP 7.4 support. That will probably happen pretty soon, though!


Invitation email links are set to localhost:4200

This is the docker container. When I send out invitations for users the email contains a link to localhost eg.
http://localhost:4200/invitation/6e003bd~
I'm actually running it on port 9200 (not 4200) - read thru the docs but I don't see any ref to setting the hostname and port for invitation emails. Is it an env variable?

Hi @brez please try with  APP_URL env

That was it - thanks!


Coverage-related warnings in CircleCI runs

Summary

CircleCI output includes a number of warnings related to the coverage files. I doubt these warnings affect anything, but I would love to fix this at some point.
Here are a couple of the warnings. All of the warnings have one of the two following patterns, with the only difference being the data filenames.
Coverage.py warning: Data file '/tmp/src/NiMARE/.coverage.b9a5ec5ebe99.271.780847' doesn't seem to be a coverage data file: Couldn't use data file '/tmp/src/NiMARE/.coverage.b9a5ec5ebe99.271.780847': no such table: coverage_schema
Coverage.py warning: Data file '/tmp/src/NiMARE/.coverage.b9a5ec5ebe99.279.708915' doesn't seem to be a coverage data file: 'NoneType' object is not iterable

Additional details

NiMARE version: ~0.0.9 (dev)

I think that this was resolved in the switch from CircleCI to GitHub Actions, so I'm closing.


[Chore] update Class Components to Function Components

use modern React Components (with Hooks)

I will take this, there are just two components which are  EventDetailContainer and EventsContainer


Non-orthorhombic simulation boxes with LAMMPS

Description
Please describe the behavior you would like added to Interchange.
When building LAMMPS input using to_lammps with non-orthrombic simualation boxes, an error is raised NotImplementedError: Interchange does not yet support exporting non-rectangular boxes to LAMMPS. I'd like to use LAMMPS for simulations of non-orthorombic crystal lattices, hence the possibility to export these kind of simulation boxes would be nice. I am attaching an OFF topology as an example (.json serialized) off-topology.json.zip.
Below is code I'd like to use
forcefield = ForceField("openff-2.0.0.offxml")
interchange = forcefield.create_interchange(
        topology, charge_from_molecules=topology.molecules)
interchange.to_lammps("input.inp")

This only isn't supported because I didn't think people would need it, nice to see that's not the case
I might not get to this for a few weeks - would be happy to take a PR if you're up for it. The change would need to go here, just converting the (OpenMM-style) box vectors into whichever format LAMMPS needs.

cc @timbernat

Thanks. I'll try to get a PR together (unless @timbernat wants to go ahead). From the documentation, it seems that LAMMPS's restricted triclinic box form is similar to the reduced form that OpenMM uses.

@wutobias I'd love to take a crack at this but won't have the bandwidth to do so until the week of 11/18, so I'm happy for you to take the reins on this


Feature Request: Ability to optional send to different registers

It would be awesome to send to specific registers when using YankyYank.
I use https://github.com/christoomey/vim-system-copy, and have different mappings for the normal register and the system (global) register.
It would be awesome to have separate keymaps, but also use the preserve cursor feature! for both.

Good idea, I'll try to implement this next week!

You have 2 solutions now :
You can set a mapping like : vim.keymap.set("n", "cp", '"a<Plug>(YankyYank)', {}), then cp will yank to "a register.
Following to this PR, you can also do :
vim.keymap.set("n", "cp", function()
    return require("yanky").yank({ register = "a" })
end, { expr = true })

Thanks for your feedback !

Awesome!! Thank you!


Drop non-integer count lot instead of round it

To restrict publishing multiple lots with different price and the same lot size (count) by one law, lots with non-integer size have to be prohibited but not published with rounded price.

Rebuilded on hydra.


Mac Installation

I am having difficulty setting this up on a Mac. I've tried multiple python version, but they all result in failed installations. It would be helpful if you could specify what version to use (as well as hardware requirements).

Same on Windows. I've tried Python 3.8.6, 3.10.0 and 3.12

I am having difficulty setting this up on a Mac. I've tried multiple python version, but they all result in failed installations. It would be helpful if you could specify what version to use (as well as hardware requirements).

Can you provide specific error information? My local Python version is 3.10

After ~3 hours of debugging, Somehow  I managed to run it.
Issues and Fixes

Redundant Dependency: delft

Issue: The delft dependency appears to be unnecessary and caused most of the dependency conflicts.
Fix: Commented out the delft dependency in the requirements.txt (or the relevant dependency file).

Incorrect is_azure Flag in LLM.py

Issue: In LLM.py line 56, the is_azure flag is set to True by default. Since I'm using the OpenAI API, this caused configuration issues.
Fix: Changed the is_azure flag to False to align with OpenAI API usage.

Empty Default Environment Variables

Issue: The default environment variables are empty, leading to empty values being used during model initialization.
Fix: Commented out the unused environment variables, retaining only OPENAI_API_KEY which is necessary for my setup.

Logic Bug in agents.py

Issue 1: In agents.py lines 326-376, the variable search_paper is not an array.

Fix: Renamed search_paper to search_papers and removed the redundant line at agents.py line 349.

Issue 2: The while loop logic at agents.py line 330 seems to attempt finding related papers based on each reference until some are found. However, the condition conflicts with the outer loop. It appears the intended logic is to process one reference at a time. If the result is irrelevant, proceed to the next reference. Finally, if the results are insufficient, fall back to a forward pass. Not sure if I understand it correctly

After ~3 hours of debugging, Somehow I managed to run it.
Issues and Fixes

Redundant Dependency: delft

Issue: The delft dependency appears to be unnecessary and caused most of the dependency conflicts.
Fix: Commented out the delft dependency in the requirements.txt (or the relevant dependency file).

Incorrect is_azure Flag in LLM.py

Issue: In LLM.py line 56, the is_azure flag is set to True by default. Since I'm using the OpenAI API, this caused configuration issues.
Fix: Changed the is_azure flag to False to align with OpenAI API usage.

Empty Default Environment Variables

Issue: The default environment variables are empty, leading to empty values being used during model initialization.
Fix: Commented out the unused environment variables, retaining only OPENAI_API_KEY which is necessary for my setup.

Logic Bug in agents.py

Issue 1: In agents.py lines 326-376, the variable search_paper is not an array.

Fix: Renamed search_paper to search_papers and removed the redundant line at agents.py line 349.

Issue 2: The while loop logic at agents.py line 330 seems to attempt finding related papers based on each reference until some are found. However, the condition conflicts with the outer loop. It appears the intended logic is to process one reference at a time. If the result is irrelevant, proceed to the next reference. Finally, if the results are insufficient, fall back to a forward pass. Not sure if I understand it correctly

After ~3 hours of debugging, Somehow I managed to run it.
Issues and Fixes

Redundant Dependency: delft

Issue: The delft dependency appears to be unnecessary and caused most of the dependency conflicts.
Fix: Commented out the delft dependency in the requirements.txt (or the relevant dependency file).

Incorrect is_azure Flag in LLM.py

Issue: In LLM.py line 56, the is_azure flag is set to True by default. Since I'm using the OpenAI API, this caused configuration issues.
Fix: Changed the is_azure flag to False to align with OpenAI API usage.

Empty Default Environment Variables

Issue: The default environment variables are empty, leading to empty values being used during model initialization.
Fix: Commented out the unused environment variables, retaining only OPENAI_API_KEY which is necessary for my setup.

Logic Bug in agents.py

Issue 1: In agents.py lines 326-376, the variable search_paper is not an array.

Fix: Renamed search_paper to search_papers and removed the redundant line at agents.py line 349.

Issue 2: The while loop logic at agents.py line 330 seems to attempt finding related papers based on each reference until some are found. However, the condition conflicts with the outer loop. It appears the intended logic is to process one reference at a time. If the result is irrelevant, proceed to the next reference. Finally, if the results are insufficient, fall back to a forward pass. Not sure if I understand it correctly

Hello hjzccc, are you interested in joining the project and develop it？

hjzccc

I'm really sorry for the trouble caused to you. I will fix the code as soon as possible. Thank you for your feedback, and you can also submit your PR to solve the related problem.

Reference in new

Regarding Issue 3, your understanding is correct. There is a break statement that ends the loop when relevant reference is retrieved. The condition for the outer loop was a remnant from previous code that I did not clean up properly; it was established to address other issues but is no longer necessary. I have now removed it. Thank you for your suggestion, and I apologize for any confusion this may have caused you.

May I ask if it is possible to create a more user-friendly version? For example, does it have a suitable UI interface like other AI software? It can be used immediately by beginners as well. Compared to the work you are doing, this should not be difficult.

OrangePhi

Sure, I will try to build a simple Gradio frontend later

Maybe worth a docker version?

I am not very familiar with Docker, so I will try to create one in the future


Activating Open Collective

Hi, I'm making updates for Open Collective. Either you or another core contributor signed this repository up for Open Collective. This pull request adds financial contributors from your Open Collective https://opencollective.com/flow.js ❤
What it does:

adds a badge to show the latest number of financial contributors
adds a banner displaying contributors to the project on GitHub
adds a banner displaying all individuals contributing financially on Open Collective
adds a section displaying all organizations contributing financially on Open Collective, with their logo and a link to their website

We have also added a postinstall script to let people know after npm|yarn install that you are welcoming donations. Feel free to remove it if you don't want it. [More info]
P.S: As with any pull request, feel free to comment or suggest changes.
Thank you for your great contribution to the Open Source community. You are awesome! 🙌
And welcome to the Open Collective community! 😊
Come chat with us in the #opensource channel on https://slack.opencollective.com - great place to ask questions and share best practices with other Open Source sustainers!

@AidasK : close?


Captions on Image

Hi there when I use the model to get caption on one image it gives 2 possible captions for that image. Can we increase the number of captions per image? like it give 4 or 5 possible captions for that image.

@hishamabutt --beam_size is the option.


DLP : Default application credentials are not getting picked up when running locally

Running code locally gives me:
"Error in inspectString: io.grpc.StatusRuntimeException: PERMISSION_DENIED: DLP API has not been used in project usable-auth-library before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/dlp.googleapis.com/overview?project=usable-auth-library then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
I need to explicitly provide GOOGLE_APPLICATION_CREDENTIALS env var, gcloud auth application-default login does not work.

AFAIK, usable-auth-library is an internal project assigned to gcloud, and there may be a reason that the Cloud SDK team did not enable the DLP API. I know the team cannot enable APIs if the APIs end up charging the internal project.
BTW, The DLP quickstart does not list Cloud SDK as a requirement, and it should work without gcloud installed: https://cloud.google.com/dlp/docs/quickstart-cli. Maybe it's intended that you should use GOOGLE_APPLICATION_CREDENTIALS as described in the quickstart?

We need to update the error we are seeing about the project project usable-auth-library, and guide people to use service account credentials instead.

I did some more digging. We are discouraging people and APIs from using gcloud auth application-default login and intend to deprecate this mechanism. Setting the env var is the preferable method.
I'll close this as wontfix. cc @vchudnov-g

@pongad  : fine with this not working, but can we provide a better error message to the user here to ask them to set GOOGLE_APPLICATION_CREDENTIALS or link them to the right auth docs ?

@jabubake Internally, b/64388723 tracks the implementation of the better error message. I've added you to the cc list on that.


ActionView::Template::Error: undefined local variable or method `article' for #<#Class:0x007f9b54011048:0x007f9b6a14a7c8>

View details in Rollbar: https://rollbar.com/trystant/BOW/items/234/

NameError: undefined local variable or method `article' for #<#<Class:0x007f9b54011048>:0x007f9b6a14a7c8>
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/metamagic-3.1.7/lib/metamagic/view_helper.rb", line 30, in method_missing
  File "/Users/dariusgoore/development/blackops/app/views/articles/followers.html.erb", line 27, in block in _app_views_articles_followers_html_erb__4397878825228599038_70152774527760
  File "/Users/dariusgoore/development/blackops/app/views/articles/followers.html.erb", line 21, in each
  File "/Users/dariusgoore/development/blackops/app/views/articles/followers.html.erb", line 21, in _app_views_articles_followers_html_erb__4397878825228599038_70152774527760
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/template.rb", line 145, in block in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/notifications.rb", line 166, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/template.rb", line 333, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/template.rb", line 143, in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb", line 54, in block (2 levels) in render_template
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/abstract_renderer.rb", line 39, in block in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/notifications.rb", line 164, in block in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/notifications/instrumenter.rb", line 20, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/notifications.rb", line 164, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/abstract_renderer.rb", line 39, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb", line 53, in block in render_template
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb", line 61, in render_with_layout
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb", line 52, in render_template
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb", line 14, in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/renderer.rb", line 42, in render_template
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/renderer/renderer.rb", line 23, in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/rendering.rb", line 100, in _render_template
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/streaming.rb", line 217, in _render_template
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.3/lib/action_view/rendering.rb", line 83, in render_to_body
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/rendering.rb", line 32, in render_to_body
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/renderers.rb", line 37, in render_to_body
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/abstract_controller/rendering.rb", line 25, in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/rendering.rb", line 16, in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb", line 44, in block (2 levels) in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/core_ext/benchmark.rb", line 12, in block in ms
  File "/Users/dariusgoore/.rubies/ruby-2.2.1/lib/ruby/2.2.0/benchmark.rb", line 303, in realtime
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/core_ext/benchmark.rb", line 12, in ms
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb", line 44, in block in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb", line 87, in cleanup_view_runtime
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/searchkick-0.8.7/lib/searchkick/logging.rb", line 112, in cleanup_view_runtime
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activerecord-4.2.3/lib/active_record/railties/controller_runtime.rb", line 25, in cleanup_view_runtime
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb", line 43, in render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/remotipart-1.2.1/lib/remotipart/render_overrides.rb", line 14, in render_with_remotipart
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/implicit_render.rb", line 10, in default_render
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/implicit_render.rb", line 5, in send_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/abstract_controller/base.rb", line 198, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_controller/metal/rendering.rb", line 10, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.3/lib/abstract_controller/callbacks.rb", line 20, in block in

I believe that this is happening because of the meta tag in the followers.html.erb page. Specifically,
<% meta title: "People tracking the case of<EMAIL_ADDRESS>     description: "There are<EMAIL_ADDRESS>people tracking the case of<EMAIL_ADDRESS>on EBWiki",
     keywords<EMAIL_ADDRESS>police violence people color")
%>

The description checks for the number of followers before the:
  <% if @article.followers.present? %>
check on line 12.
This should be fixed by making the descriptions generic in the short term.

this was due to an each loop in the view referencing 'article' object, when i had changed it to 'follower' instead here:

		    <% @article.followers.each do |follower| %>

	            <%= link_to image_tag(avatar_url(follower,200), :class => "img-responsive"), follower %>

		    <% end %>


ARROW-17356: [R] Update binding for add_filename() NSE function to error if used on Table

Putting this one down for now given that the current error message suffices; may pick it up again, but realised that where things are on the call stack make this much trickier than it looks


Incomplete pattern lines are left as-is

Finished this in commit https://github.com/sopra-fs22-group-34/server/commit/206af17cdaad2ee287f559fd544e7ca8b2264af5


Tag a release?

Having a stable release tagged is required for inclusion in many package managers. Could you tag a 1.0.0 or 0.1.0 version? Thanks.

@rcombs
Thanks for your advice. I have drafted the v1.0.0 release just now.
https://github.com/xqq/libaribcaption/releases/tag/v1.0.0


Add GridOptimization Colllection support

@chapincavender is considering use of a GridOptimization Collection for amino acid QM treatment. This Collection currently does not have support in QCSubmit.

@jthorton and I met today to determine necessary components for this support. We concluded:

GridOptimizations are very similar to Torsiondrives, in that they are service-based, generating new OptimizationRecords on the server as they iterate forward.
We can use the existing QCSubmit TorsiondriveDataset as a template for building out the GridOptimizationDataset.
Some new components we will need in QCSubmit include:

need results classes, similar to Torsiondrives
need support for distances (bonds, in our case), angles

Some differences from Torsiondrives:

no wavefront propagation
only a single initial molecule allowed

The items in (4) may make GridOptimization of limited utility for @chapincavender in performing scans for dipeptides.

Thanks @dotsdl and @jthorton for moving forward with this! I think I'm not being very clear about what I want to do, so apologies from my end. As an alternative to doing a 2-D TorsionDrive with an expensive QM method, I want to explore:

Doing a 2-D TorsionDrive with a fast and less accurate method - a force field, a machine learning potential like ANI, or a semiempirical method like XTB
Taking the geometries of the lowest-energy structures at each grid point as input for a constrained geometry optimization with the expensive QM method.

I think this two-step approach resolves the issues in point (4) above because it includes wavefront propagation and multiple initial conformers in the 2-D TorsionDrive in the first step, albeit with the less accurate level of theory. I was using the term "grid optimization" to describe this two-step approach. I see now that QCArchive has a GridOptimization record that is constructed from a chain of optimizations using the previous step to seed the current step, so I think I misled you by applying that term incorrectly. Sorry for the misunderstanding!
I don't anticipate needing QCArchive's GridOptimization records in the near future. If the 2-D TorsionDrive in step 1 of the two-step approach fails with the fast method, then a GridOptimization dataset with either the fast or expensive method could replace the 2-D TorsionDrive in step 1. But the 2-D TorsionDrive is the preferred option, and I will move forward with that for now.
I think that I could accomplish the two-step approach without any additional infrastructure from QCSubmit by doing two sequential submissions - one submission for the 2-D TorsionDrive for all molecules, then a second submission for the constrained optimizations for all molecules. However, it would be nice to be able to start the constrained optimizations for molecules whose TorsionDrives are completed before the TorsionDrives are completed for all molecules. In the current infrastructure, my understanding is that I would have to iteratively update the second submission with new molecules as their TorsionDrives are completed from the first submission. As an alternative, QCSubmit could support the two-step approach in a single submission that submits a single record to QCArchive. The record metadata would include the results of the TorsionDrive in step 1 (i.e. grid points, lowest-energy geometries, lowest energy with fast method) and then each grid point would also have the results of the constrained optimizations with the expensive method in step 2.
This latter approach is almost certainly beyond the scope of this issue due to my misunderstanding of the term "grid optimization", so perhaps we should close this. If we decide to move forward with the approach in the previous paragraph, I can open another issue. Probably we will need to involve QCArchive as well to support the new record type.

Thank you @chapincavender, we'll close this for now then. Feel free to re-open if you find that this is something you will need, and then we'll pursue it.


aaaaxy: 1.4.119 -> 1.4.137

Description of changes
https://github.com/divVerent/aaaaxy/releases/tag/v1.4.137
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 280042 run on x86_64-linux 1

2 packages built:

aaaaxy
aaaaxy.testing_infra


Considering that Power Apps were enabled for Document Libraries, should we update the note?

This feature was released earlier: https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=57303 (https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=57303), thus making the note "Support for generic document libraries is coming soon" incorrect. Also, a clarification would need to be done on what "generic" means here (libraries without specific fields, without content types, etc.)?

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

ID: 0eacf34e-9ae6-5c64-5fec-c250fc9986d1
Version Independent ID: 7d248abd-225e-c914-e871-f8d2424ed8c0
Content: Customize a SharePoint list form - PowerApps
Content Source: powerapps-docs/maker/canvas-apps/customize-list-form.md
Service: powerapps
GitHub Login: @tapanm-MSFT
Microsoft Alias: tapanm

Thank you for your feedback, content is updated. Please allow some time to reflect the changes. For custom lists and libraries, Power Apps option inside SharePoint allows customizing form. For lists such as Announcements, Tasks or templates, form customization using Power Apps is not available/supported.


maoritelevision.com (appears to use brightcove)

Checklist

[x] I'm reporting a new site support request
[x] I've verified that I'm running youtube-dl version 2020.03.24
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that none of provided URLs violate any copyrights
[x] I've searched the bugtracker for similar site support requests including closed ones

Example URLs

Single video: https://www.maoritelevision.com/shows/frenemies/S01E015/frenemies-episode-15

Description

A username+password is needed; the following will work:
username=rf-mtv-test@live555.com,password=testtest

Hi,
The site maoritelevision.com has been updated to maoriplus.co.nz. However URL schemes appear to be the same.
I was able to use the help here: https://github.com/ytdl-org/youtube-dl/commit/4fb25ff5a3be5206bb72e5c4046715b1529fb2c7
And use the same brightcove URL with the Maoriplus ID at the end. Hopefully an easy fix.
Thanks!

Generally, please open a new issue rather than necroposting in a closed issue. But as you suggest, this may be an easy fix.
Show URLs from the old domain redirect to https://www.maoriplus.co.nz/ (sample of 1), so we can bin the processing for those URLs.
This current show https://www.maoriplus.co.nz/show/code-the-reunion/play/6349856999112 plays in the browser from the UK with no account/cookies.
So now the extractor has the show's Brightcove ID in the URL that previously had to be extracted from the page, very simple:
...
-    _VALID_URL = r'https?://(?:www\.)?maoritelevision\.com/shows/(?:[^/]+/)+(?P<id>[^/?&#]+)'
+    _VALID_URL = r'https?://(?:www\.)?maoriplus\.co\.nz/show/(?P<series>[\w-]+)/play/(?P<id>[\d]+)'
...
     def _real_extract(self, url):
-        display_id = self._match_id(url)
-        webpage = self._download_webpage(url, display_id)
-        brightcove_id = self._search_regex(
-            r'data-main-video-id=["\'](\d+)', webpage, 'brightcove id')
+        brightcove_id = self._match_id(url)
         return self.url_result(
             self.BRIGHTCOVE_URL_TEMPLATE % brightcove_id,
             'BrightcoveNew', brightcove_id)

Then:
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-vF', u'https://www.maoriplus.co.nz/show/code-the-reunion/play/6349856999112']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
[debug] Git HEAD: f66e450bf
[debug] Python 2.7.15 (CPython i686 32bit) - Linux-6.1.0-18-686-pae-i686-with-debian-12.5 - OpenSSL 1.1.1a  20 Nov 2018 - glibc 2.1.3
[debug] exe versions: ffmpeg 5.1.4-0, ffprobe 5.1.4-0
[debug] Proxy map: {}
[brightcove:new]<PHONE_NUMBER>112: Downloading JSON metadata
[brightcove:new]<PHONE_NUMBER>112: Downloading m3u8 information
[brightcove:new]<PHONE_NUMBER>112: Downloading m3u8 information
[brightcove:new]<PHONE_NUMBER>112: Downloading MPD manifest
[brightcove:new]<PHONE_NUMBER>112: Downloading MPD manifest
[brightcove:new]<PHONE_NUMBER>112: Downloading MPD manifest
[brightcove:new]<PHONE_NUMBER>112: Downloading MPD manifest
[info] Available formats for<PHONE_NUMBER>112:
format code                                  extension  resolution note
hls-audio-0-en__Main_-0                      mp4        audio only [en]
hls-audio-0-en__Main_-1                      mp4        audio only [en]
dash-a41239e7-db53-4f4d-924c-54da159ba123-0  m4a        audio only [en] DASH audio   64k , m4a_dash container, mp4a.40.2 (48000Hz)
dash-a41239e7-db53-4f4d-924c-54da159ba123-1  m4a        audio only [en] DASH audio   64k , m4a_dash container, mp4a.40.2 (48000Hz)
dash-a41239e7-db53-4f4d-924c-54da159ba123-2  m4a        audio only [en] DASH audio   64k , m4a_dash container, mp4a.40.2 (48000Hz)
dash-a41239e7-db53-4f4d-924c-54da159ba123-3  m4a        audio only [en] DASH audio   64k , m4a_dash container, mp4a.40.2 (48000Hz)
dash-fe47bcc9-7840-47af-9ea6-727c9bcb8fa4-0  mp4        640x360    DASH video  699k , mp4_dash container, avc1.42001e, video only
dash-fe47bcc9-7840-47af-9ea6-727c9bcb8fa4-1  mp4        640x360    DASH video  699k , mp4_dash container, avc1.42001e, video only
dash-fe47bcc9-7840-47af-9ea6-727c9bcb8fa4-2  mp4        640x360    DASH video  699k , mp4_dash container, avc1.42001e, video only
dash-fe47bcc9-7840-47af-9ea6-727c9bcb8fa4-3  mp4        640x360    DASH video  699k , mp4_dash container, avc1.42001e, video only
hls-839-0                                    mp4        640x360     839k , avc1.42001e, video only
hls-839-1                                    mp4        640x360     839k , avc1.42001e, video only
dash-274d6d64-f208-4760-a7d2-b1cf121016ab-0  mp4        960x540    DASH video 1199k , mp4_dash container, avc1.4d001f, video only
dash-274d6d64-f208-4760-a7d2-b1cf121016ab-1  mp4        960x540    DASH video 1199k , mp4_dash container, avc1.4d001f, video only
dash-274d6d64-f208-4760-a7d2-b1cf121016ab-2  mp4        960x540    DASH video 1199k , mp4_dash container, avc1.4d001f, video only
dash-274d6d64-f208-4760-a7d2-b1cf121016ab-3  mp4        960x540    DASH video 1199k , mp4_dash container, avc1.4d001f, video only
hls-1389-0                                   mp4        960x540    1389k , avc1.4d001f, video only
hls-1389-1                                   mp4        960x540    1389k , avc1.4d001f, video only
dash-01a7d27c-dd8c-48d6-a16f-5be2420bfa34-0  mp4        1280x720   DASH video 1995k , mp4_dash container, avc1.4d001f, video only
dash-01a7d27c-dd8c-48d6-a16f-5be2420bfa34-1  mp4        1280x720   DASH video 1995k , mp4_dash container, avc1.4d001f, video only
dash-01a7d27c-dd8c-48d6-a16f-5be2420bfa34-2  mp4        1280x720   DASH video 1995k , mp4_dash container, avc1.4d001f, video only
dash-01a7d27c-dd8c-48d6-a16f-5be2420bfa34-3  mp4        1280x720   DASH video 1995k , mp4_dash container, avc1.4d001f, video only
hls-2264-0                                   mp4        1280x720   2264k , avc1.4d001f, video only
hls-2264-1                                   mp4        1280x720   2264k , avc1.4d001f, video only
dash-7e4ac127-f037-4a0b-a1cd-0cebb729a65b-0  mp4        1920x1080  DASH video 3496k , mp4_dash container, avc1.640028, video only
dash-7e4ac127-f037-4a0b-a1cd-0cebb729a65b-1  mp4        1920x1080  DASH video 3496k , mp4_dash container, avc1.640028, video only
dash-7e4ac127-f037-4a0b-a1cd-0cebb729a65b-2  mp4        1920x1080  DASH video 3496k , mp4_dash container, avc1.640028, video only
dash-7e4ac127-f037-4a0b-a1cd-0cebb729a65b-3  mp4        1920x1080  DASH video 3496k , mp4_dash container, avc1.640028, video only
hls-3916-0                                   mp4        1920x1080  3916k , avc1.640028, video only
hls-3916-1                                   mp4        1920x1080  3916k , avc1.640028, video only
http-3687k-1080p-0                           mp4        1920x1080  3687k , MP4 container, H264, 1.35GiB
http-3687k-1080p-1                           mp4        1920x1080  3687k , MP4 container, H264, 1.35GiB (best)
$

The show page as seen by yt-dl (with no JS) is essentially empty, so it's lucky that the ID is handed to us. With JS enabled in the browser, the page actually fetches JSON containing the Brightcove data (along with some data for other video hosts), but it happens to be the same as hard-coded in the old extractor's BRIGHTCOVE_URL_TEMPLATE. Maybe there are other shows that will need this JSON to be loaded and parsed.
There is also some schema of seasons/episodes/playlists, etc, that someone who cared could implement.


Display issues on IE 6/7/8/9 in Win 7 & XP and Galaxy Tab

Expected behaviour
New base theme must fit in as expected on all browsers across different operating systems
Actual behaviour
Issue 1) Display issues while restoring IE 6/7/8/9 browsers (Please find attached screenshot)
issue 2) Display of header on Samsung galaxy tab is not as expected
Steps to reproduce the behaviour
Launch RSI/MCI survey on IE 6/7/8/9 in Win XP/7 using browsers stack
Restore the browser and shrink the browser
Technical information
Browser

IE 6/7/8/9
Google chrome

Operating System

Win XP/7
Galaxy Tab (Android)

Screenshot

CrossBrowser testing coverage matrix.

@hamishtaplin @yoganandkunche @bennpearson what's the status of this defect since we moved the default theme to the new one?

Retested the issue and it works fine after we had the new theme


Apply changes to custom fields

I had a hard time trying to configure a custom field until I realised that changes don't take effect until you restart Firefox. There' no indication about that, neither a "Save settings" button (as in "General" tab) nor a "Apply changes" button.
It'd be cool if you could make it possible to edit custom fields without a browser restart. If it isn't feasible for technical reasons, at least add a note about it in the "Custom Fields" tab.
Thank you in advance

Just found faster workaround: open add-on manager, disable and re-enable the extension and reload the tab with the form involved.

To my knowledge, you don't have to restart Firefox (or Chrome) or disable and re-enable the extension for any changes to take effect. Simply reloading the tab will do. I am in the process of figuring out how to eliminate that step too. But for now, reloading the page works.

Oh, that's strange... I might be hitting some other issue then. I'll look further into it. Thank you for your time (and the wonderful add-on).


Fix xmlparser features for no_std build

xmlparser relies on std by default, unless the xmlparser/std feature is disabled. Conditionally enable this feature depending on roxmltree/std.
Fixes #38.

Thanks!


make generate leaves the repository dirty

What happened:
make generate has changes that aren't committed:
> Generate
> Generate Docs for OCM Plugins
Successfully written OCM Plugin docs to ../../../../../../docs/pluginreference
> Generate Docs for OCM CLI
Successfully written OCM CLI docs to ../../../docs/reference
➜  ocm git:(main) ✗ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
        modified:   pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go

no changes added to commit (use "git add" and/or "git commit -a")
➜  ocm git:(main) ✗

diff --git a/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go b/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
index 9cedc11e..58825f64 100644
--- a/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
+++ b/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
@@ -94,7 +94,7 @@ func ResourcesComponentDescriptorOcmV3SchemaYaml() (*asset, error) {
 		return nil, err
 	}

-	info := bindataFileInfo{name: "../../../../../../../../resources/component-descriptor-ocm-v3-schema.yaml", size: 11515, mode: os.FileMode(436), modTime: time.Unix(1682771838, 0)}
+	info := bindataFileInfo{name: "../../../../../../../../resources/component-descriptor-ocm-v3-schema.yaml", size: 11515, mode: os.FileMode(420), modTime: time.Unix(1683029770, 0)}
 	a := &asset{bytes: bytes, info: info}
 	return a, nil
 }
diff --git a/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go b/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go
index d8484674..41db33e0 100644
--- a/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go
+++ b/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go
@@ -94,7 +94,7 @@ func ResourcesComponentDescriptorV2SchemaYaml() (*asset, error) {
 		return nil, err
 	}

-	info := bindataFileInfo{name: "../../../../../../../resources/component-descriptor-v2-schema.yaml", size: 11202, mode: os.FileMode(436), modTime: time.Unix(1682771838, 0)}
+	info := bindataFileInfo{name: "../../../../../../../resources/component-descriptor-v2-schema.yaml", size: 11202, mode: os.FileMode(420), modTime: time.Unix(1683029770, 0)}
 	a := &asset{bytes: bytes, info: info}
 	return a, nil
 }

Looks like it's a timestamping issue.
What you expected to happen:
make generate results to be up-to-date.
How to reproduce it (as minimally and precisely as possible):
Run make generate on main.
Anything else we need to know:
Environment:

Ok, fine, but what should I do, it is just a silly generator.
May be, the file mode is the problem on MAC. I can regenerate without changing the timestamp

we should all use v3.1.3 of go-bindata. I've changed the install-requirements.sh script accordingly.
Additionally the format fights against the generate. I tried to fix this in the format script.
(#442)

I am using 3.1.3
go-bindata --version
go-bindata 3.1.3 (Go runtime go1.20.4).
Copyright (c) 2010-2013, Jim Teeuwen.

make generate
go: downloading k8s.io/utils v0.0.0-20230115233650-391b47cb4029
> Generate
> Generate Docs for OCM Plugins
Successfully written OCM Plugin docs to ../../../../../../docs/pluginreference
> Generate Docs for OCM CLI
Successfully written OCM CLI docs to ../../../docs/reference
➜  ocm git:(main) ✗ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
        modified:   pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go

no changes added to commit (use "git add" and/or "git commit -a")

ah, ok. Now my git status also shows them on both branches after the generate...

Nope.
➜  ocm git:(main) git pull
remote: Enumerating objects: 48, done.
remote: Counting objects: 100% (48/48), done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 48 (delta 22), reused 44 (delta 22), pack-reused 0
Unpacking objects: 100% (48/48), 27.92 KiB | 510.00 KiB/s, done.
From github.com:open-component-model/ocm
   6d7c2161..cac80150  main       -> origin/main
Updating 6d7c2161..cac80150
Fast-forward
 cmds/ocm/app/app_test.go                                                       | 2 +-
 cmds/ocm/commands/ocicmds/artifacts/describe/cmd.go                            | 2 +-
 cmds/ocm/commands/ocicmds/artifacts/get/cmd.go                                 | 2 +-
 cmds/ocm/commands/ocmcmds/components/get/cmd.go                                | 2 +-
 cmds/ocm/commands/ocmcmds/components/hash/cmd.go                               | 2 +-
 cmds/ocm/commands/ocmcmds/components/transfer/cmd.go                           | 2 +-
 docs/reference/ocm_describe_artifacts.md                                       | 2 +-
 docs/reference/ocm_get_artifacts.md                                            | 2 +-
 docs/reference/ocm_get_componentversions.md                                    | 2 +-
 docs/reference/ocm_hash_componentversions.md                                   | 2 +-
 docs/reference/ocm_transfer_componentversions.md                               | 2 +-
 hack/format.sh                                                                 | 4 ++--
 hack/install-requirements.sh                                                   | 3 +--
 pkg/contexts/oci/cpi/utils_test.go                                             | 1 +
 pkg/contexts/oci/transfer/transfer_test.go                                     | 7 +++----
 pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go | 4 ++--
 pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go                    | 4 ++--
 17 files changed, 22 insertions(+), 23 deletions(-)
 make generate
> Generate
> Generate Docs for OCM Plugins
Successfully written OCM Plugin docs to ../../../../../../docs/pluginreference
> Generate Docs for OCM CLI
Successfully written OCM CLI docs to ../../../docs/reference
➜  ocm git:(main) ✗ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
        modified:   pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go

no changes added to commit (use "git add" and/or "git commit -a")
➜  ocm git:(main) ✗ git diff
➜  ocm git:(main) ✗

Hi @Skarlso, since this is about generated content and timestamps, wouldn't be the only possibility to revert those after a make generate an additional git rm action as part of the generate?

That wouldn't work if your desire is actually updating the generated content.

I'm wondering what's up here. @morri-son Are you also still getting this? Or is it now really just my machine? I can ignore it if it is only on my machine.

@Skarlso , I also get this on my machine (Mac on Apple Silicon) on main and make generate. But I wonder how to avoid this as the two files are always generated, creating same two bindata.go files as the ones in GitHub from content perspective, but with different timestamps. git will always detect those as changes. What else than manually reverting them or somehow git rm them as part of the make generate?

It's not just the timestamp though. It's also the filemod that is different.
diff --git a/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go b/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
index 9ad60f07..5e300a3c 100644
--- a/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
+++ b/pkg/contexts/ocm/compdesc/versions/ocm.software/v3alpha1/jsonscheme/bindata.go
@@ -93,7 +93,7 @@ func ResourcesComponentDescriptorOcmV3SchemaYaml() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "../../../../../../../../resources/component-descriptor-ocm-v3-schema.yaml", size: 11515, mode: os.FileMode(436), modTime: time.Unix(1689587011, 0)}
+       info := bindataFileInfo{name: "../../../../../../../../resources/component-descriptor-ocm-v3-schema.yaml", size: 11515, mode: os.FileMode(420), modTime: time.Unix(1684317454, 0)}
        a := &asset{bytes: bytes, info: info}
        return a, nil
 }
diff --git a/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go b/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go
index 3ba3834c..54342677 100644
--- a/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go
+++ b/pkg/contexts/ocm/compdesc/versions/v2/jsonscheme/bindata.go
@@ -93,7 +93,7 @@ func ResourcesComponentDescriptorV2SchemaYaml() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "../../../../../../../resources/component-descriptor-v2-schema.yaml", size: 11202, mode: os.FileMode(436), modTime: time.Unix(1689587011, 0)}
+       info := bindataFileInfo{name: "../../../../../../../resources/component-descriptor-v2-schema.yaml", size: 11202, mode: os.FileMode(420), modTime: time.Unix(1684317454, 0)}
        a := &asset{bytes: bytes, info: info}
        return a, nil
 }

Also, is there a particular reason for using bindata that has been discontinued for 3 years now?

I created #452 as a follow up. @Skarlso , you mentioned a possible fix, can you please try to apply it?

Already did. :)


E1019 error incorrectly reported for Fn::Sub function in AWS::CertificateManager::Certificate resource on cfn-lint v1.5.2

CloudFormation Lint Version
1.5.2
What operating system are you using?
Amazon Linux 2
Describe the bug
I'm encountering an issue with cfn-lint, where it's reporting an E1019 error for the Fn::Sub function in an AWS::CertificateManager::Certificate resource, even though the function is receiving an array as expected.
Here's the relevant part of my CloudFormation template:
  Certificate:
    Condition: AccountIsCorrect
    Type: AWS::CertificateManager::Certificate
    Properties:
      CertificateAuthorityArn: !Sub 'arn:${AWS::Partition}:acm-pca:us-east-1:myCaARN'
      DomainName: !Sub
        - '${CertificateCN}-${SdlcKey}.example.com'
        - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
      SubjectAlternativeNames: !If
        - IsProd
        - - !Sub
            - '${CertificateCN}-${SdlcEnvironment}.example.com'
            - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
              SdlcEnvironment: !FindInMap [ SdlcKey, !Ref SdlcKey, SdlcEnvironment ]
          - !Sub
            - '${CertificateCN}.ecmc.lan'
            - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
        - !Sub
          - '${CertificateCN}-${SdlcEnvironment}.example.com'
          - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
            SdlcEnvironment: !FindInMap [ SdlcKey, !Ref SdlcKey, SdlcEnvironment ]

The error message I'm seeing is:
[cfn-lint] E1019: {'Fn::Sub': ['${CertificateCN}-${SdlcEnvironment}.ecmc.lan', {'CertificateCN': {'Fn::FindInMap': ['Global', 'ALB', 'CertificateCN']}, 'SdlcEnvironment': {'Fn::FindInMap': ['SdlcKey', {'Ref': 'SdlcKey'}, 'SdlcEnvironment']}}]} is not of type 'array'

I believe this is a false positive, as the Fn::Sub function is indeed receiving an array. I'm using cfn-lint version 1.5.2. I cannot reproduce this when running against cfn-lint v0.87.9.
Expected behavior
cfn-lint should correctly recognize the Fn::SUB function as receiving an array, and not report an E1019 error for this usage of the function. Instead, it should validate the template without any errors, assuming all other parts of the template are correct.
Reproduction template
  Certificate:
    Condition: AccountIsCorrect
    Type: AWS::CertificateManager::Certificate
    Properties:
      CertificateAuthorityArn: !Sub 'arn:${AWS::Partition}:acm-pca:us-east-1:myCaARN'
      DomainName: !Sub
        - '${CertificateCN}-${SdlcKey}.example.com'
        - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
      SubjectAlternativeNames: !If
        - IsProd
        - - !Sub
            - '${CertificateCN}-${SdlcEnvironment}.example.com'
            - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
              SdlcEnvironment: !FindInMap [ SdlcKey, !Ref SdlcKey, SdlcEnvironment ]
          - !Sub
            - '${CertificateCN}.ecmc.lan'
            - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
        - !Sub
          - '${CertificateCN}-${SdlcEnvironment}.example.com'
          - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
            SdlcEnvironment: !FindInMap [ SdlcKey, !Ref SdlcKey, SdlcEnvironment ]

The problem is related to you not producing an array in the else path of the condition.
Change
        - !Sub
          - '${CertificateCN}-${SdlcEnvironment}.example.com'
          - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
            SdlcEnvironment: !FindInMap [ SdlcKey, !Ref SdlcKey, SdlcEnvironment ]

to
        - - !Sub
            - '${CertificateCN}-${SdlcEnvironment}.example.com'
            - CertificateCN: !FindInMap [ Global, ALB, CertificateCN ]
              SdlcEnvironment: !FindInMap [ SdlcKey, !Ref SdlcKey, SdlcEnvironment ]

hi @kddejong ,
Changing the 'else' block as you suggest didn't get rid of the error.  I might add that this is already a deployed resource in Cloudformation, the template is valid. We simply started updating cfn-lint from v0 to v1 on some of our tooling and started getting linting errors like this one and trying to understand better why that is.

My mistake, adding the - - in the else  path did get rid of the lint error, my first attempt must have had a typo somewhere. I assume v1 is more strict when it comes to this as the template was deemed valid on cfn-lint v0 and did deploy correctly in AWS?

@JHBoricua v1 is more thorough for sure. What is interesting is that it was deploying correctly when the environment wasn't production.  The new schemas we are using allow for multiple types or variations so it would be possible to have this property accept an array and a string but that's not what they have defined.
"SubjectAlternativeNames": {
   "items": {
    "type": "string"
   },
   "type": "array",
   "uniqueItems": true
  }

Worth noting that early validation will work after the parameters and most functions are resolved. So any chance that its never possible that AccountIsCorrect is True and IsProd is False?

When deploying the template with AccountIsCorrect is True and IsProd is False I get the following error Value of property SubjectAlternativeNames must be of type List of String

So any chance that its never possible that AccountIsCorrect is True and IsProd is False?

Not when deploying resources to our non-prod environments. I assume you are seeing that error with the original version I posted, not the updated one you suggested?

Closing this as it is behaving as expected.


Make Geometry query in object re-assembly helper more efficient

From GeometryObject.find( { 'hash': { $in: geometriesToRequest.map( xx => xx.hash ) } } ).lean() to potentially something like:
Promise.All( geometries.ToRequest.map( gO => GeometryObject.**findOne**( { 'hash': gO.hash } ) ) )

This point is moot if we'll actually enforce unique indexes on the geometryHash (but dealing with errors will be more complicated)

n/a anymore since #26


User team 1st sprint

Login 5%
register 10%

as well as some environment setting

龚长金 implements this but for some network problems 朱一凡 commit for him this time

Overdue for 1 day, please finish all the things in this sprint. If it was done, please close this issue.
@zhuyf8899

Login 5/5
register 10/10


Fix: File.SetAttribute could fail, but the file stream will be kept open

Hi @TrabacchinLuigi ,
Thank you for the PR 👍 Well found for the context leak here

What about this not passing some tests ? it looked weird...


fix stream redirect order

This change fixes the stream redirect order when upstart_capture_errors
is set to true. Without the correct order stderr is not captured.

oops, didn't see PR #1! This is the same fix

@fredericve Just merged PR #1 and tagged an 0.2.0 release that includes it.

@dwcramer perfect! Thanks ^^


"Remove Surface" button should act as a toggle

The "remove surface" button should allow re-clicking to "Add Surface"
The documentation for 3DMol gives an example:
http://3dmol.csb.pitt.edu/doc/
(one button removes a surface, another button adds it back)

This re-adds a surface
pqr.threeDMole.all_viewers[0].addSurface($3Dmol.SurfaceType.MS, {color: "white", opacity: 0.80});