Ability to specify the output name for a bin target different from the crate name

Hi,
I have opened this to close the following issue #1706 .
I have decided to start by writing a test to outline what behavior is expected from Cargo.
As of now, this test fails (for obvious reasons). I will now start writing the code needed to pass this test.
This is my first time contributing to cargo. Please, feel free to let me know if there are any protocols/processes that need to be followed. I'm a newbie at this.
Closes issue #1706

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Eh2406 (or someone else) soon.
Please see the contribution instructions for more information.

Thanks for the PR, and looks reasonable so far! I think we'll also want documentation updates for Cargo as well along the lines of this, and we'll probably also want this to be gated and unstable to start out, but otherwise it's a good start :)

Hi @alexcrichton ,
I'm trying to debug the test that I have written. But, I am running into some weird behavior. I'm unable to debug beyond this point: https://github.com/rust-lang/cargo/blob/d6384de0bcdb150159f33574517d31a0b824f281/crates/cargo-util/src/process_builder.rs#L206
After this point the debugger just jumps into Assembly code. Is this the point where rustc takes over? I'm unable to find the point where the TomlManifest structure gets filled.
I'm pretty sure, I am doing something wrong, I just can't figure out what.
Also, is there a channel on the rust discord, where I can reach out to people for doubts related to cargo?

Hi @alexcrichton,
I'm trying to debug the test which I have written to understand how the data from the Cargo.toml is stored within Cargo.
I notice that the test which I have written works fine when executed from the terminal using cargo test. But, it panics in the run() method when I try to debug it. I get an error message saying:
error: process didn't exit successfully: `rustc -vV` (exit status: 1)

I want to see in which field of the TomlManifest structure is the new filename parameter stored. However, I'm unable to reach that point, as the run() method panics before that point.
Could you please guide me here? I'm using vs-code with the codeLLDB extension for debugging.

So, I think I have figured out what is going wrong. The cargo_test_support does not interact with the cargo library or binary code. What it does is, run the executable by spawning a new child process. I was working under the assumption that somewhere in cargo_test_support I would see code that is triggers code for cargo itself.

Hi @alexcrichton,
I have reached a point in the code, where I could use some review. In my current implementation, I have added a new field to the TargetInner structure called binary_name to store the filename of binary provided in the Cargo.toml. The alternative approach is to store that filename directly in the name field of the TargetInner struct. But, I have no idea what kind of effect that would have on future enhancements, and it doesn't seem like a good idea to mess with something that is already working.
Do you think my approach is correct?

Hi @alexcrichton / @Eh2406,
Can I please get a code review, here?

I don't know this part of the code all that well. Sorry. @Eric Huss may have more opinions.

I think the approach of adding to TargetInner looks correct here.
There are a few other considerations that should be handled:

Fingerprinting needs to be able to check the timestamp of the output filename.  Check that running cargo build -v a second time prints "Fresh" (that is, it doesn't build again).
cargo clean -p foo should be able to clean the binary output files.
cargo build --message-format=json should emit correct paths for artifact messages.

One way to get these to work is correctly add the new path to the output tracking.  The way Cargo predicts what the output filenames are is kinda complicated, but I'll try to walk through it:

For each run of the compiler, Cargo has a list of OutputFile values that describe the files that rustc generates.
These are stored in CompilationFiles which in turn is part of Context.
The outputs are computed in calc_outputs_rustc.

The style of outputs is driven by querying rustc.  This is fetched in file_types which uses various caching to make that quick.  Essentially it runs rustc --print=file-names … to understand the file format of each crate type.

Somewhere in that, it should compute the OutputFile with the new filename.  I'm not sure where that would go, but hopefully those are some clues where to start looking.

Hi @ehuss ,
If, my understanding is correct, the filenames from OutputFile are not being supplied to rustc. Do we need to find a way to add the path from OutputFile to the rustc args ?

Hi @ehuss,
I managed to add binary_name to rustc args. The code is now passing the basic test that I have written. It creates a file structure like this:

As you can see here, the name of the binary is different from the deps file. I think, it would make sense to use the value coming from the filename parameter in cargo.toml only for the hardlink. Do you think this is a good idea?

Hi,
I have used the filename from cargo.toml only for hardlinking. This satisfies all the requirements that @ehuss mentioned. The current code produces a folder structure like this:

I think we can start implementing more tests, now. One for cargo clean and one for deps. Would you like me to add them in their respective test modules in testsuites/ ?

Hi,
I have used the filename from cargo.toml only for hardlinking. This satisfies all the requirements that @ehuss mentioned. The current code produces a folder structure like this:

I think we can start implementing more tests, now. One for cargo clean and one for deps. Would you like me to add them in their respective test modules in testsuites/ ?

Hi @ehuss, can we try running the CI again?

@ehuss great! that seems to have taken care of that issue. since the windows CI also passed, can we assume that this works on windows, too?

Hi @ehuss / @alexcrichton , how do you want me to proceed with this, now?

Reviewers like @ehuss and I have time to help out and provide some guidance in places where necessary, but I don't think either of us (or others) have the time to do 1 on 1 mentoring right now with detailed guidanced and detailed information about how to solve all concerns. Unfortunately that can amount to the reviewer doing most of the work of design and largely implementation, which can be very time consuming.
In some sense @whereistejas you'll need to take some liberties in taking feedback on this PR and incorporating the features and requests into the implementation yourself. If you have general questions about Cargo's or need assistance we can try to help, but I don't think either of us is in a position to provide the detailed level of advice you may be looking for on this.

Hi @alexcrichton, thank you for the candid response.  No hard feelings (I mean it). The point of doing open-source contributions is to help out maintainers such as yourself save time, not further eat into it. We are all on the same team here. :)
I will try to take this PR as close to the Finished state as I can, before asking for a review again. I'm almost finished, here, as I have already finished feature gating and adding the documentation.

Hi @alexcrichton / @ehuss ,
This PR is ready from my side.
Tasks:

[x] Add tests.
[x] Feature gate and make unstable.
[x] Update cargo-feature documentation.
[x] Add appropriate comments where needed.

This is a short description of my implementation:

We are receiving the name the user expects to give the binary in a parameter called filename from cargo.toml.
This value is stored in the bin_name field of the TargetInner struct.
Instead of using bin_name to name the binaries themselves, we simply use it to create the hardlink  in the target directory.
This is done using uplift_filename method.
The uplift_filename method is used in three places:
i. fn uplift_to - used for cargo build, this is our method of interest.
ii. fn clean - used for cargo clean. uplift_filename provides the correct name for the hardlink that needs to removed in this method.
https://github.com/rust-lang/cargo/blob/54bc19ee56c2251fc749198cce9605450fecd1df/src/cargo/ops/cargo_clean.rs#L190-L197
iii. fn bin_link_for_target - this method is only used when no Unit is found. We can safely assume that uplift_filename here will always return the crate name.
https://github.com/rust-lang/cargo/blob/54bc19ee56c2251fc749198cce9605450fecd1df/src/cargo/core/compiler/context/compilation_files.rs#L304-L307
By simply renaming the hardlink, we don't disturb any other dependencies that other methods may have on the path field of the OutputFile object. Since, the user is only concerned with the final binary produced by cargo, using the hardlink, works out well.
The other binaries that are created in the deps/ folder, have the same name as the crate.

I have currently added three tests:

To check if we actually create the correct binary.
To check if the deps file has the correct content.
To check if cargo clean works.

List of tests:

[x] Check if we actually create the correct binary.
[x] Check if the deps file has the correct content.
[x] Check if cargo clean works.
[ ] Check that it is feature-gated. That is, try to run cargo build with a manifest where cargo-features is not set, and make sure it fails. Look for tests called gated() for some examples.
[ ] Check the JSON output for the artifact message in --message-format=json contains the correct path.
[x] Check that fingerprinting works correctly. You can stuff this in one of the other tests, like simple_binary_name where after the first build, just run cargo build -v again and make sure the output says [FRESH] foo [..].
[ ] Check that cargo run is able to execute the binary.
[ ] Check that cargo test is able to test the binary. I think as written, it still uses the crate name in the filename?
[ ] Check that the CARGO_BIN_EXE_$name environment variable is set correctly for integration tests.
[ ] Check the CARGO_BIN_NAME environment variable. I'm uncertain what value this should have. I think based on the original use cases, this might want to be the new filename. I'm a little concerned about the increasing inconsistencies this is introducing though (like the --bin flag uses the bin name, not the filename).
[ ] Add some tests for cargo install and cargo uninstall. Make sure it installs the correct name and is able to uninstall it.

Hi @ehuss,

Check that the CARGO_BIN_EXE_$name environment variable is set correctly for integration tests.

Writing the test and fix checking CARGO_BIN_EXE_<name> is indeed, tricky. I think, it would be best if let it be as it is. We can mention this inconsistency in the documentation.
From what I can tell, it is kind of tricky to assign the value we get from filename parameter to the env <name> variable. This is happening in the following piece of code:
diff --git a/src/cargo/core/compiler/mod.rs b/src/cargo/core/compiler/mod.rs
index 1687a5d2a..6501231c9 100644
--- a/src/cargo/core/compiler/mod.rs
+++ b/src/cargo/core/compiler/mod.rs
@@ -980,7 +980,11 @@ fn build_base_args(
             let exe_path = cx
                 .files()
                 .bin_link_for_target(bin_target, unit.kind, cx.bcx)?;
-            let key = format!("CARGO_BIN_EXE_{}", bin_target.name());
+            let name = unit
+                .target
+                .get_binary_name()
+                .unwrap_or(bin_target.name().to_string());
+            let key = format!("CARGO_BIN_EXE_{}", name);
             cmd.env(&key, exe_path);
         }
     }

This code is called once for each unit as we are looping over each root present in the build context (bcx). Our source code from the src/ directory forms the first unit and integretion tests from tests/ directory form the second unit. The filename parameter is not available to us in the second unit, as the target_type of this unit is test and not bin. The filename parameter is only available for bin target type. I think, we are moving into really slippy territory here.
Would it be problematic if we had $CARGO_BIN_EXE_foo when the actual executable name is 007bar?

Just chiming in to say that supporting cdylibs (as suggested in the original issue and by @alexcrichton here) would be awesome. Just for your consideration!
Cheers

Sorry, I'm a bit confused about the questions for CARGO_BIN_EXE.  Wouldn't the key name be something like bin_target.get_binary_name().unwrap_or(bin_target.name().to_string());?  I'm not sure why it is using unit.target, as that is the wrong target.
Also, looking at the usage of get_binary_name, it looks like it is always immediately converts None to target.name(), perhaps it shouldn't return an Option?  I may also suggest remove the get_ prefix, as that is not the recommended style in Rust (and isn't used in any other methods of that struct) (see C-GETTER).

:umbrella: The latest upstream changes (presumably #9751) made this pull request unmergeable. Please resolve the merge conflicts.

I apologize for the mess of commits, I did a git rebase and something like that happened.

Also, looking at the usage of get_binary_name, it looks like it is always immediately converts None to target.name(), perhaps it shouldn't return an Option?

get_binary_filename will not return anything, if we don't set the filename parameter. Making it an Option, makes it easier to check if it is returning a valid filename.

I see that there is no public method provided by cargo_test_support to escape the forward slashes in a windows path. Would it be a good addition if we had a such a method? We already have such a provision for with_stdout and with_stderr but not for with_json.

Sorry, I'm a bit confused about the questions for CARGO_BIN_EXE. Wouldn't the key name be something like bin_target.get_binary_name().unwrap_or(bin_target.name().to_string());? I'm not sure why it is using unit.target, as that is the wrong target.

@ehuss this is right! Thanks for this, it helped me out a bunch. I have covered all the tests, now. They are all passing. I had some trouble figuring out how to handle windows vs. unix paths, thankfully I saw the #[cfg(windows)] option in one of the other tests.
The only test I'm a little sceptical about is this: check_msg_format_json. Please let me know if there is any other pending stuff.

:umbrella: The latest upstream changes (presumably #9118) made this pull request unmergeable. Please resolve the merge conflicts.

Hi @ehuss, I have fixed all the issues you had mentioned in your comments.

Okay, so I tried to git rebase and I completely messed this up.

Hi @ehuss, is it possible to do a squash merge from your side?

No worries. Git can be finicky sometimes.  Thanks!  🎉
@bors r+

:pushpin: Commit 9e2790f828ddfe28c57024b6122ebaa6f31d9202 has been approved by ehuss

:hourglass: Testing commit 9e2790f828ddfe28c57024b6122ebaa6f31d9202 with merge 3d3ddd267f31d99d6c72d54218ff935836d6a732...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 3d3ddd267f31d99d6c72d54218ff935836d6a732 to master...

Thanks @ehuss for all of your help! I really appreciate the patience from your side. I just have one last question, what will we have to make this feature a stable feature?

There is not a well established protocol for stabilizing. Generally, features land on nightly for a while, and people should test it out and report their experiences. Preferably we would like to see that a feature has at least some degree of broad interest, and isn't being added for just one project.  The unresolved issues listed in #9778 should either get resolved or have some good explanation of why they don't need to be resolved.

Should this be named file_name? libstd nomenclature uses underscore: https://doc.rust-lang.org/stable/std/?search=filename


Fix Spec files paths

Thanks for the patch, it's appreciated.

You're welcome, thanks for the merge.


RPC changes for handling SwapClaims in the extension

Zpoken is currently working on adding support for Swap and SwapClaims to the wallet/dapp. They've requested two changes to our RPC interfaces:

[x] In TransactionPlannerRequest replace string memo = 3 with MemoPlaintext memo. This is necessary to allow dapp to hide or show the sender's address.  Alternatively, it can also be done with a combination of the fields string memo and bool hide_sender
[ ] There is currently no way to build a TransactionPlan for a SwapClaim transaction through the planner interface. It would be cool to add repeated TransactionPlannerRequest.SwapClaim

Reported by the Zpoken team in Discord.

We should absolutely make the changes requested, ideally by 2023-08-07 (#2888). But these changes may be necessary but not sufficient for Swap support; see for example https://buf.build/penumbra-zone/penumbra/docs/986b465b7fc4428d95d12d94f313c25f:penumbra.core.dex.v1alpha1#penumbra.core.dex.v1alpha1.SwapClaimPlan which requires an input of https://buf.build/penumbra-zone/penumbra/docs/986b465b7fc4428d95d12d94f313c25f:penumbra.core.dex.v1alpha1#penumbra.core.dex.v1alpha1.BatchSwapOutputData. How is the dapp expected to obtain the inputs for SwapClaimPlan?

There is currently no way to build a TransactionPlan for a SwapClaim transaction through the planner interface. It would be cool to add repeated TransactionPlannerRequest.SwapClaim

I took a look around, and this is best understood as a documentation problem: it is currently possible to build a TransactionPlan for a SwapClaim transaction, by leveraging the ActionPlan enum, which can be a dex.v1alpaha1.SwapPlan. I'll update the docstrings to make that clearer.

Ah, I see the problem: TransactionPlan supports swapclaims, but TransactionPlannerRequest does not. Will try to add that.


More french translation.

All the sheet is now in french, yay ! But, there are certainly mistakes somewhere, so I'm probably gonna need to do a patch after this pull request is accepted as I'm gonna be able to see the sheet, and not to look for mistakes directly in the code...
Tell me if you see anything bad, hopefully I didn't break anything in the english/dutch sheet.

Roll templates cannot be translated so I have reverted that file. It's an unfortunate limitation of roll20. If it ever does work I can get your translations from git history.

Yea, I was wondering if that would work or not ...
I already see some mistakes, expect a fix this evening


Investigate strange behavior on Release x64

If  4f5b718 is reverted tests start failing on Release x64 build.

@AndriySvyryd anything for us to do here?

We need to investigate whether it's us and forward the issue if it isn't.

This isn't a priority for us since it's external and we have a workaround.


As the year winds down and comes to a close, over the holidays many here at GitHub are going to be taking time off to relax, recuperate, spend time with their families and loved ones, and reflect on the year that’s gone before. Additionally, this year has continued to be particularly stressful, causing some open source projects to announce that they’re taking it slow for the final month of the year. We found the example set by the Electron project in their blog post to be particularly poignant. Following their example, we’ve decided that we also will be taking some extra time and may be slow to respond for the rest of the year.

As the year winds down and comes to a close, over the holidays many here at GitHub are going to be taking time off to relax, recuperate, spend time with their families and loved ones, and reflect on the year that’s gone before. Additionally, this year has continued to be particularly stressful, causing some open source projects to announce that they’re taking it slow for the final month of the year. We found the example set by the Electron project in their blog post to be particularly poignant. Following their example, we’ve decided that we also will be taking some extra time and may be slow to respond for the rest of the year.
In specific, for the rest of November and all of December 2021, we’ll continue to cover mission-critical activities, but full review of issues and PRs may have to wait until the new year. Please feel free to continue to contribute, we simply ask that you remain patient with us as we give everyone a well-deserved chance to pause, reflect, and recharge.
We wish each and every one of you the world over Happy Holidays and a peaceful and prosperous New Year!
Originally posted by @ramyaparimi in https://github.com/github/docs/discussions/12249

huh


[SQL] Remove decimal support in BigQuery SQL read.

Beam SQL integration tests started to fail recently. It seems like Beam SQL cannot convert decimal value successfully anymore. The root cause is still unknown.
This PR removes decimal support to make java postcommit test green. Future investigation is tracked here: https://issues.apache.org/jira/browse/BEAM-4736.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---
---

@apilloud @akedin
Will go through our code review process first. After getting a LGTM, will tag a commiter for merging PR.

run java postcommit

LGTM

run java postcommit

@reuvenlax for committer level review and/or merging PR.

cc @vectorijk

LGTM
cc @XuMingmin Could you merge this PR?


Modernizing syntax

What does the pull request do?

Modernized syntax used for argument checking exceptions. String literals have been converted to nameof()
Some instances of ArgumentException were being created incorrectly (arguments were in wrong order) so they were switched
Many places where string.Format was used were converted to interpolated string for readability

What is the updated/expected behavior with this PR?
No significant changes in behavior

You can test this PR using the following package version. 11.0.999-cibuild0037820-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]


Check the errors when importing boa-space-contracts module

깃헙 CI workflow를 진행하면서 다음에 대한 사항을 체크하도록 한다.
We use the seaport module from boa-space-contracts instead of the ProjectOpenSea/seaport. But some errors occur when running the test. This is not critical in the current state but we should check why the errors occur.
The errors are as follows.
1) As a user I want to buy now or accept an offer
       A single ERC721 is to be transferred
         [Buy now] I want to buy a single ERC721
           with ETH
             ERC721 <=> ETH (already validated order):
     AssertionError: Expected transaction to be reverted with InvalidSigner, but other exception was thrown: Error: VM Exception while processing transaction: reverted with custom error 'InvalidSignature()'

  2) As a user I want to buy now or accept an offer
       A single ERC721 is to be transferred
         [Buy now] I want to buy a single ERC721
           with ERC20
             ERC721 <=> ERC20 (already validated order):
     AssertionError: Expected transaction to be reverted with InvalidSigner, but other exception was thrown: Error: VM Exception while processing transaction: reverted with custom error 'InvalidSignature()'

  3) As a user I want to buy now or accept an offer
       A single ERC1155 is to be transferred
         [Buy now] I want to buy a single ERC1155
           with ETH
             ERC1155 <=> ETH (already validated order):
     AssertionError: Expected transaction to be reverted with InvalidSigner, but other exception was thrown: Error: VM Exception while processing transaction: reverted with custom error 'InvalidSignature()'

  4) As a user I want to buy now or accept an offer
       A single ERC1155 is to be transferred
         [Buy now] I want to buy a single ERC1155
           with ERC20
             ERC1155 <=> ERC20 (already validated order):
     AssertionError: Expected transaction to be reverted with InvalidSigner, but other exception was thrown: Error: VM Exception while processing transaction: reverted with

에러 수정됨.


Fit ee

adds fitting method for EE mchanism

Codecov Report
Attention: Patch coverage is 98.41270% with 1 line in your changes missing coverage. Please review.

Project coverage is 82.66%. Comparing base (1d2c427) to head (f5f4f86).

Files with missing lines
Patch %
Lines

src/cvsim/fit_curve.py
98.41%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           master      #16       +/-   ##
===========================================
+ Coverage   55.31%   82.66%   +27.34%
===========================================
  Files           2        2
  Lines         367      421       +54
===========================================
+ Hits          203      348      +145
+ Misses        164       73       -91

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

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests


Update unit tests for BrokerDetailsBreadcrumb component

Update unit tests for BrokerDetailsBreadcrumb component to cover all edge cases.

Closed as completed.


[Enhancement] /skill bind skillname ?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Expand the Skill Bind Menu by a additional   option.
Describe the solution you'd like
A clear and concise description of what you want to happen.
For Example if i type in /skill bind skillname a
The skill would be bound to  the a button
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

This sort of already exists with combos. And the hard part about it is, there are only certain keypresses that can be detected. These include things like pressing 'Q' to drop an item, right/left click, sneaking with 'Shift', swapping an item to your shield slot with 'F', etc. Basically, we can only detect keypresses that fire an event.
In context with your example directly, we could sort of detect a keypress for 'A' by listening to the move event and checking the movement vector in relation to where they're looking, but it's more complicated than I want to deal with at the moment. Additionally, binding skills to movement keys would be unwise as it would interfere with movement.


fix: JB-468 refactor JuiceVideoThumbnailOrImage to work correctly

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] (if relevant) I have tested this PR in all supported browsers.
[ ] (if relevant) I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3756   👈

This comment was auto-generated by Graphite.


ImplictGrantAuth instead of ImplicitGrantAuth

Copying the example from the implicit grant auth, gives the following error because there's a type on ImplictGrantAuth (there's a missing I between the C and T in the word Implicit). There's also a typo on the controller.
The type or namespace name 'ImplicitGrantAuth' could not be found (are you missing a using directive or an assembly reference?)
https://github.com/JohnnyCrazy/SpotifyAPI-NET/blob/f31af2395c2dddeab8352964099427bf6b4a54fe/SpotifyAPI.Web.Auth/ImplictGrantAuth.cs#L19 https://github.com/JohnnyCrazy/SpotifyAPI-NET/blob/f31af2395c2dddeab8352964099427bf6b4a54fe/SpotifyAPI.Web.Auth/ImplictGrantAuth.cs#L33

AuthorizationCodeAuth got changed to AutorizationCodeAuth too ?


Option include-v-in-tag not respected for github release name

TL;DR
When setting option
include-v-in-tag: false

there is no v prefix in the tag name as expected. But the github release name contains the v-prefix!
Expected behavior
No response
Observed behavior
No response
Action YAML
on:
  push:
    branches:
      - main
name: release-please
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          token: ${{ secrets.MY_TOKEN }}
          include-v-in-tag: false
          release-type: node
          package-name: release-please-action

Log output
No response
Additional information
No response

Any update on this ?

@devcharmander would happily accept a patch. This feature is low priority for us, and we're not likely to implement ourselves anytime soon.

While looking at the code I learned that this flag was not introduced in the version I was using.
Bumping up the version solved the problem for me.
Sorry for the bother.

👍 it does look like this has been added since this bug was opened.

I created a release today using this workflow and the v is still there. So this issue is not resolved.

@bcoe Could you please reopen this?


[8.x] Remove duplicated updated_at setting

There is no need to set the $columns[$this->getUpdatedAtColumn()] value when soft deleting, as Illuminate\Database\Eloquent\Builder::update already merges in the Updated At column.

Tests don't agree. :P

@GrahamCampbell I can't make sense of the test output. It seems all the errors are related to configuration issues (i.e. REDIS environment values).

this error is relevant to your pr :
There was 1 error:

1) Illuminate\Tests\Database\DatabaseSoftDeletingTraitTest::testDeleteSetsSoftDeletedColumn
Mockery\Exception\NoMatchingExpectationException: No matching handler found for Mockery_2_stdClass::update(['deleted_at' => 'date-time']). Either the method was unexpected or its arguments matched no expected argument list for this method

Thanks @lk77. Would it be acceptable to just remove the updated_at from the Mockery expectations?

i on't think so, the updated_at column needs to be updated with the deleted_at

Apologies @lk77, I referenced the namespace incorrectly in my PR - I've now fixed this.
I'd agree that the Builder::update is well-tested enough that we can rely on those tests and that it is outside of the scope of deleting to update the updated_at column.
I can see that the Eloquent Builder has a test that ensures updated_at when calling the update() method (\Illuminate\Tests\Database\DatabaseEloquentBuilderTest:1544) - this should suffice.

PR closed without explanation. Fantastic!

@joshbrw It seems this was probably closed because "if it isn't broke, don't fix it."

@BrandonSurowiec I appreciate that for 99.9% of users, this won't be considered an issue.
I came across this issue implementing Eloquent onto a legacy project with an inconsistent database. I had overwritten certain methods on my models to define the data types for the created and updated columns (some tables use date time, some unix timestamps). The issue I faced was that the Eloquent Builder always forces a Y-m-d H:i:s value into the updated column when soft-deleting, whereas in this instance I needed it to be a unix timestamp.

i think this was closed because the way the issue was presented, more like an unnecessary thing that is redundant but does not cause any bug.


When remote upload fails, it leaves temp files in /var/vcap/data/tmp

When remote upload fails, it leaves temp files in /var/vcap/data/tmp, which doesn't get cleaned and might cause subsequent uploads to fail on smaller disks. This has happened for me due to AWS connectivity issues, and I think BOSH should be clever enough to recover from that and not leave any temporary files around.
Essentially, when ReleaseInvalidArchive is raised temp directory should be cleaned.

Story filed: https://www.pivotaltracker.com/story/show/85445708

Closing - fixed via 1e0d1c12a92346c6edf46368563aa31e5fb7f3a5.


performing continuous pretraining and then finetuning causes error

I tried to perform finetuning using custom dataset on a model I continuously pretrained on another custom dataset but the following error occurs:
<

Is there any way to streamline these two procedures?

Thanks for reporting, and hm, yes, this is weird. I can reproduce it:
Pretraining
litgpt pretrain \
   --model_name pythia-14m \
   --tokenizer_dir checkpoints/EleutherAI/pythia-14m \
   --out_dir my_test_dir \
   --data TextFiles \
   --data.train_data_path custom_pretraining_data \
   --train.max_tokens 10_000

...
Seed set to 42
Time to instantiate model: 0.13 seconds.
Total parameters: 14,067,712
Validating ...
Measured TFLOPs: 0.10
Saving checkpoint to '/teamspace/studios/this_studio/my_test_dir/final/lit_model.pth'
Training time: 24.14s
Memory used: 1.44 GB

Continued Pretraining
litgpt pretrain \
   --model_name pythia-14m \
   --tokenizer_dir checkpoints/EleutherAI/pythia-14m \
   --out_dir my_test_dir_2 \
   --data TextFiles \
   --data.train_data_path custom_pretraining_data \
   --train.max_tokens 10_000 \
   --initial_checkpoint_dir /teamspace/studios/this_studio/my_test_dir/final/

RuntimeError: Error(s) in loading state_dict for GPT:
        Missing key(s) in state_dict: "lm_head.weight", "transformer.wte.weight", "transformer.h.0.norm_1.weight", "transformer.h.0.norm_1.bias", "transformer.h.0.attn.attn.weight", "transformer.h.0.attn.attn.bias", "transformer.h.0.attn.proj.weight", "transformer.h.0.attn.proj.bias", "transformer.h.0.norm_2.weight", "transformer.h.0.norm_2.bias", "transformer.h.0.mlp.fc.weight",
...

ls  /teamspace/studios/this_studio/my_test_dir/final

config.json  generation_config.json  hyperparameters.yaml  lit_model.pth  model_config.yaml  tokenizer.json  tokenizer_config.json

It did work a few months ago when I tested this for the tutorials and don't have a good explanation at the moment why it would fail. Either I am doing something incorrectly above, or there could be something that has recently changed that's causing this. I will have to think more about this ...
Have you seen this before @awaelchli  or @carmocca ?

Side note: on my end I first continuously pretrained llama-2-7b-hf and then tried finetune but it doesn't work (similar error as yours above)

I was wondering if there is a workaround to this? Like can I upload this continuously pretrained model onto HF and download it as a model from HF for finetune. Didn't find any tutorial of how to upload models trained/finetuned in Litgpt onto HF though.

Any progress on this or some workaround?


BUG: Delaunay/qhull segfault on self-pass

I noticed this segfault on main while investigating gh-21279. python dev.py test -- -k "test_find_simplex_self_segfault". It is clearly an abuse of the call signature but we generally should intercept before segfaulting.
--- a/scipy/spatial/tests/test_qhull.py
+++ b/scipy/spatial/tests/test_qhull.py
@@ -194,6 +194,12 @@ class TestUtilities:
             j = qhull.tsearch(tri, p[:2])
             assert_equal(i, j)

+    def test_find_simplex_self_segfault(self):
+        # segfaults before bug fix
+        points2d = np.array([[0, 0], [0, 1.1], [1, 0], [1, 1]])
+        tri = qhull.Delaunay(points2d)
+        tri.find_simplex(tri)
+
     def test_plane_distance(self):
         # Compare plane distance from hyperplane equations obtained from Qhull
         # to manually computed plane equations

To clarify, the abuse of signature you refer to is that find_simplex expects an array and segfaults if given non-array arguments?
Looking at https://github.com/scipy/scipy/blob/main/scipy/spatial/_qhull.pyx#L2113, it does something strange indeed: it calls np.asanyarray, but are subclasses supported really.  So I guess in your call, xi becomes an object array and things go askew from this point on?
Also tri.find_simplex(1) also segfaults for me locally, even though I'd expect the dimensionality check to ValueError instead.

There seem to be some things to address yeah. To be honest, I was kind of following the docs since our current devdocs docstring for find_simplex has the triangulation object/info as a valid parameter (see below screen capture as well). So I thought "that's weird" and tried it.


Change info for --network in rio run -h

Steps:

rio run -h

Results:  There is a option for --network.  Only two options are available for this, default & home.  We need to change the help and validate that in CLI

Version v0.0.4 rc1
Verified fixed


Resolve signed/unsigned comparison warnings

Is your feature request related to a problem? Please describe.
Enable -Wsign-compare and observe warnings.
From code reivew:
https://github.com/nasa/cFE/blob/e80aae94e0f56b868657daba965c590766a4dc57/modules/es/fsw/src/cfe_es_apps.c#L1056
Describe the solution you'd like
Resolve these
Describe alternatives you've considered
None
Additional context
Code review, specific case of #1307
Requester Info
Jacob Hageman - NASA/GSFC

Note 131 warnings generated when compiling with unit tests, 9 without.  Removing current milestone for now (future work).


Add set cwd scipt

Add a script to test the setCWD() System method.

I have merged this branch (with the missing test) into the system_setcwd branch with the pull request #144 here. Will close this PR instead, sorry for the confusion!


Support Rust and Golang

(gdb) py print(gdb.lookup_type("unsigned long").sizeof)
8
(gdb) set language go
(gdb) py print(gdb.lookup_type("unsigned long").sizeof)
Python Exception <class 'gdb.error'>: No type named unsigned long.
Error occurred in Python: No type named unsigned long.
(gdb) py print(gdb.lookup_type("uintptr").sizeof)
8

I also hit this issue when debugging rust code. I don't quite understand why we need to cast the register value into a type specific to the programming language that is being debugged. We are reading page table data structures here, so the data types should be defined by the architecture and not by the programming language that is being debugged.
I quickly tested dropping the programming language specific cast, i.e.
    def read_register(self, register_name):
        return int(gdb.parse_and_eval(register_name))

this seems to work fine.

@its-luca Length of unsigned long is different between 32-bit and 64-bit.

That's true, but I think Python's int type has a flexible bit length, so reading either 32 or 64 bit values should be fine. If not, this should then use a "are we running in 32 or 64 bit mode" check instead of using a data type that's tied to the programming language of the currently debugged program.


[Doc site] Filter on Colors page does not work

Looks like typing in the filter bar for the Colors page (https://evergreen.segment.com/foundations/colors) doesn't actually do anything.

I'm actually not seeing this locally or on the prod doc site now.. 🤔 Going to close out until I can reproduce it again


kubernetes: make tests pass by fixing a conntrack-tools dep and a missing dir

This PR fixes the kubernetes tests on master.  There are several unrelated changes, and unfortunately, all are necessary for the tests to actually succeed
Changes:

Change the dep in proxy.nix from conntrack_tools to conntrack-tools.  The former is an alias to the latter, but aliases have been disabled in tests since 3edde65.
Create the certmgrAPITokenPath dir in pki.nix.  Without that, the tests fail with an error like kube-certmgr-bootstrap-start[698]: touch: cannot touch '/var/lib/kubernetes/secrets/apitoken.secret':No such file or directory.
In tests/kubernetes/base.nix, the container network is now called mynet by default and not docker0.  This was changed during the switch to containerd in 7b5c38e973842.
Also there, add some extra options to kubectl to work around a runc bug introduced in kubernetes-1.21.1  (kubernetes/102676).  Weirdly enough, this doesn't affect my live cluster, but the tests seem to fail most of the time (but not always) due to this.

Motivation for this change
Fixes the kubernetes tests, for the most part.  Specifically, it fixes the dns.nix and rbac.nix tests as they're the only ones mentioned in default.nix.
Mind you, even with the changes here, the tests are still flaky and sometimes end up getting stuck in a loop logging "Error getting node" err="node \"machine1.my.zyx\" not found", but we can fix that separately.
Things done

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

[X] NixOS
[ ] macOS
[X] other Linux distributions

[X] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase 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.

@saschagrunert Could you review this PR, please?  Alternatively, do you know who might be a good reviewer?  I'm not familiar with who does what for kubernetes in nix.

We're still at 1.20.X on our prod cluster, so I haven't seen (or heard of) that runc bug (yet). Adding the required workarounds in the case seems safe enough for me. Thanks for that! We should remember to track the progress of related fixes upstream.
As for the rest of the fixes: :+1:

Thanks!  I'll go looking for somebody to merge and backport to 21.05.

Could somebody with the right permissions add the backport release-21.05 tag, please?

Thank you!


API Metadata not showing in API Center Portal

Description
Cannot see metadata in the API Center Portal
Reproduction steps
Steps to reproduce the behavior:
Configured an API Center->Defined Metadata properties under Metadata Schema->these show up fine here-> Registered an API (manually) and added data in the Metadata fields-> But when I go to the API Center Portal-> cannot see the Metadata fields there.
Expected behavior
Would have expected to see the datapoints under Metadata to show up in the API Center Portal
Actual behavior
Would have expected to see the datapoints under Metadata to show up in the API Center Portal but they don't
A clear and concise description of what actually happened.
Screenshots

If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Everything below the TEST MAO GET CUSTOMER INFO is from the API Center Portal...as you can see I cannot see any of the Metadata fields there...

Hi @SriniVavi ,
thanks for reaching out. Currently we don't support showcasing metadata in the APIC portal.
Metadata could potentially be information that is sensitive and that's why we currently decided on not exposing this via data plane API.
It seems like this is something you would have expected though, right?
Would you have wanted to expose all custome metadata or only certain ones?

Thank you so much for the update and info, Julia! I think if there was a way to display some of the metadata (non-sensitive info) in the portal - that would be great.
Thank you again!
Srini
From: Julia Kasper @.>
Sent: Friday, February 23, 2024 11:28 AM
To: Azure/api-center-preview @.>
Cc: Vavilala, Srinivas @.>; Mention @.>
Subject: [External Email] Re: [Azure/api-center-preview] API Metadata not showing in API Center Portal (Issue #31)
You don't often get email from<EMAIL_ADDRESS>Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
EXTERNAL EMAIL
| CAUTION: This message originated from outside CenterPoint Energy. Do not click on links, open attachments, or enter data unless you recognize the sender, were expecting the content and know it to be safe.
Hi @SriniVavihttps://github.com/SriniVavi ,
thanks for reaching out. Currently we don't support showcasing metadata in the APIC portal.
Metadata could potentially be information that is sensitive and that's why we currently decided on not exposing this via data plane API.
It seems like this is something you would have expected though, right?
Would you have wanted to expose all custome metadata or only certain ones?

Reply to this email directly, view it on GitHubhttps://github.com/Azure/api-center-preview/issues/31#issuecomment-1961719246, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BGJ4GMIJEMFLJKB45Z2EWLLYVDGRTAVCNFSM6AAAAABDSABCEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRG4YTSMRUGY.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
***** This email is from an external sender outside of the CenterPoint Energy network.  Be cautious about clicking links or opening attachments from unknown sources. *****


panic: runtime error: invalid memory address or nil pointer dereference

command executed
helm install stable/prometheus-operator --name=monitoring --namespace=monitoring -f prom_values.yaml

Error get
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x14f91b9]

goroutine 1 [running]:
main.readFile(0x7fffd9bcb57b, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000712201, 0xc00076b680, ...)
        /go/src/k8s.io/helm/cmd/helm/install.go:557 +0xa9
main.vals(0xc0002f5030, 0x1, 0x1, 0x2c0de18, 0x0, 0x0, 0x2c0de18, 0x0, 0x0, 0x2c0de18, ...)
        /go/src/k8s.io/helm/cmd/helm/install.go:399 +0x187
main.(*installCmd).run(0xc000458600, 0xc0003dce00, 0x0)
        /go/src/k8s.io/helm/cmd/helm/install.go:243 +0x1db
main.newInstallCmd.func2(0xc00013a780, 0xc000246550, 0x1, 0x5, 0x0, 0x0)
        /go/src/k8s.io/helm/cmd/helm/install.go:196 +0x30e
k8s.io/helm/vendor/github.com/spf13/cobra.(*Command).execute(0xc00013a780, 0xc000246500, 0x5, 0x5, 0xc00013a780, 0xc000246500)
        /go/src/k8s.io/helm/vendor/github.com/spf13/cobra/command.go:762 +0x465
k8s.io/helm/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc0000de500, 0x6, 0x6, 0xc0000de500)
        /go/src/k8s.io/helm/vendor/github.com/spf13/cobra/command.go:852 +0x2ec
k8s.io/helm/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        /go/src/k8s.io/helm/vendor/github.com/spf13/cobra/command.go:800
main.main()
        /go/src/k8s.io/helm/cmd/helm/helm.go:171 +0x7a
Error: failed to download "loki/loki-stack" (hint: running `helm repo update` may help)

prom_values.yaml
coreDns:
  service:
    selector:
      k8s-app: kube-dns

kubeControllerManager:
  service:
    selector:
      k8s-app: null
      component: kube-controller-manager

kubeEtcd:
  enabled: false
  endpoints: ["xxx.xxx.xxx"]
  service:
    port: '2379'
  serviceMonitor:
    scheme: https
    insecureSkipVerify: true
    certFile: "/etc/prometheus/secrets/etcd-cert/etcd.pem"
    keyFile: "/etc/prometheus/secrets/etcd-cert/etcd-key.pem"
prometheus:
  prometheusSpec:
    secrets: ["etcd-cert"]
    replicas: 1
    storageSpec:
      volumeClaimTemplate:
        metadata:
          name: data
        spec:
          storageClassName: local-storage
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 130Gi
    #    selector: {}

kubeScheduler:
  service:
    selector:
      k8s-app: null
      component: kube-scheduler

grafana:
  enabled: true

Output of helm version:
2.14.2
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):

RKE baremetal

@segator Are you able to install any other charts? Could you try installing the scaffold chart (helm create)?

helm create test
helm install test
works

@segator Is it any issue with the stable/prometheus-operator chart only?

yes but anyway I dont expect helm crash if the chart have something wrong

Good point @segator. Can you narrow down what is causing the crash? Then we can see what the bug is in Helm.

In my first message there are all you need to reproduce the error :)

I think this should be handled better than crashing.

@hickeyma Were you able to reproduce the issue? I'm not able to. I tried with
$ helm version
Client: &version.Version{SemVer:"v2.14.2", GitCommit:"a8b13cc5ab6a7dbef0a58f5061bcc7c0c61598e7", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.2", GitCommit:"a8b13cc5ab6a7dbef0a58f5061bcc7c0c61598e7", GitTreeState:"clean"}

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:23:26Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

I'm not sure about which version of prometheus-operator chart was used that lead to the issue. @segator Could you tell the version of the chart? If not we can't reproduce and fix it

@karuppiah7890 try running the cmd in the description

I tried that actually and I wasn't able to reproduce the issue
On Fri, Aug 23, 2019, 9:37 PM Martin Hickey<EMAIL_ADDRESS>wrote:

@karuppiah7890 https://github.com/karuppiah7890 try running the cmd in
the description
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/6023?email_source=notifications&email_token=ADBXB2A2UUYGM3ZKRXTV2K3QGADLBA5CNFSM4IDRROKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5AUQVA#issuecomment-524372052,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADBXB2D5SAHZTPTG2QE4D2LQGADLBANCNFSM4IDRROKA
.

I hit what looks like the same thing deploying one of our own microservcie using helm v2.14:
02:38:22  panic: runtime error: invalid memory address or nil pointer dereference
02:38:22  [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x150e8aa]
02:38:22
02:38:22  goroutine 1 [running]:
02:38:22  main.(*upgradeCmd).run(0xc000454300, 0xc000452700, 0x2)
02:38:22  	/go/src/k8s.io/helm/cmd/helm/upgrade.go:295 +0xc9a
02:38:22  main.newUpgradeCmd.func2(0xc00082bb80, 0xc0008130a0, 0x2, 0x7, 0x0, 0x0)
02:38:22  	/go/src/k8s.io/helm/cmd/helm/upgrade.go:149 +0x12c
02:38:22  k8s.io/helm/vendor/github.com/spf13/cobra.(*Command).execute(0xc00082bb80, 0xc000813030, 0x7, 0x7, 0xc00082bb80, 0xc000813030)
02:38:22  	/go/src/k8s.io/helm/vendor/github.com/spf13/cobra/command.go:762 +0x465
02:38:22  k8s.io/helm/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc0007da500, 0x8, 0x8, 0xc0007da500)
02:38:22  	/go/src/k8s.io/helm/vendor/github.com/spf13/cobra/command.go:852 +0x2ec
02:38:22  k8s.io/helm/vendor/github.com/spf13/cobra.(*Command).Execute(...)
02:38:22  	/go/src/k8s.io/helm/vendor/github.com/spf13/cobra/command.go:800
02:38:22  main.main()
02:38:22  	/go/src/k8s.io/helm/cmd/helm/helm.go:171 +0x7a

Did anyone confirm that this is a Helm issue?

We are no longer accepting bug fixes for Helm 2. See https://helm.sh/blog/helm-v2-deprecation-timeline/ for more details.


Billboards Signs and Branding Classification

Deep Learning Simplified Repository (Proposing new issue)
:red_circle: Project Title : Billboards Signs and Branding Classification
:red_circle: Aim : Create a DL model which will classify the bill boards, signs and the brandings from the posters around the streets.
:red_circle: Dataset : https://www.kaggle.com/datasets/mekabytes/billboards-signs-and-branding
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
GitHub Profile Link :
Email ID :
Participant ID (if applicable):
Approach for this Project :
What is your participant role? (Mention the Open Source program)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Full name : Abhinav kumar
GitHub Profile Link : https://github.com/Abhinavcode13
Email ID<EMAIL_ADDRESS>Participant ID (if applicable):
Approach for this Project :
Perform Exploratory Data Analysis (EDA):
Load the dataset and analyze its structure, including the number of samples, image dimensions, and class distribution.
Visualize sample images from each class to gain insights into the data.
Data Preprocessing:
Clean the dataset by removing any irrelevant or corrupted images.
Split the dataset into training, validation, and test sets.
Apply necessary preprocessing steps such as resizing, normalization, or augmentation to prepare the images for training the deep learning models.
Model Implementation:
Choose and implement three to four deep learning algorithms suitable for image classification, such as Convolutional Neural Networks (CNNs), ResNet, Inception, or DenseNet.
Utilize a deep learning framework like TensorFlow, PyTorch, or Keras to develop the models.
Train the models on the training set and adjust hyperparameters to achieve optimal performance.
Model Evaluation:
Evaluate each model on the validation set using appropriate evaluation metrics, such as accuracy, precision, recall, or F1 score.
Compare the performance of the different algorithms and select the best-fitted model based on the evaluation results.
Model Testing and Deployment:
Assess the performance of the selected model on the test set to obtain a final estimate of its accuracy.
Save the trained model for future use or deployment.
Test the model on unseen images or a real-world dataset to verify its effectiveness in classifying billboards, signs, and branding.
Documentation and Reporting:
Document each step of the project, including dataset exploration, preprocessing techniques, model architecture, hyperparameters, and evaluation results.
Write a report summarizing the project, highlighting the chosen model's performance, and providing insights into potential improvements.
What is your participant role? (Mention the Open Source program)
contributor ssoc 2.0

Issue assigned to you @Abhinavcode13

fine @abhisheks008

Hi, sir @abhisheks008 , I listed my approach down, please go through it and assign me under tag GSSOC'24
Full name : Umair Ullah
GitHub Profile Link : https://github.com/umairullah0905
Email ID<EMAIL_ADDRESS>Participant ID (if applicable):
Approach for this Project :
data preprocessing - cleaning the dataset, resizing the image ,splitting the dataset into train test and validation set then doing augmentation of dataset for better results
Algorithms - CNN architecture model such as VGG-16,ResNet,VGG-19,mobilenetv2.
Model Comparison and Selection - Evaluate Performance of all models based on the metrics obtained and will Choose the model that shows the best balance between accuracy and computational efficiency
What is your participant role? GSSOC'24

Assigned @umairullah0905


Update documentation for softmax-with-cross-entropy loss functions

softmax_cross_entropy_with_logits and sparse_softmax_cross_entropy_with_logits both have useful  behavior that conflicts with current documentation.
In softmax_cross_entropy_with_logits: "All that is required is that each row of labels is
a valid probability distribution." In sparse_softmax_cross_entropy_with_logits: "labels: Each entry labels[i] must be an index in [0, num_classes)."
Neither of these statements is true, and using all 0s in the case of softmax_cross_entropy_with_logits or -1s in the case of sparse_softmax_cross_entropy_with_logits is useful when signals include entries for which we don't want to compute loss.
softmax_cross_entropy_with_logits example:
logits_list = [tf.Variable([[0.0, 0.0, 0.0]]), tf.Variable([[99.0, 0.0, 0.0]])]
labels = tf.Variable([[0.0, 0.0, 0.0]])
loss_list = [tf.nn.softmax_cross_entropy_with_logits(logits, labels)
             for logits in logits_list]

with tf.Session() as sess:
    sess.run(tf.initialize_all_variables())
    print(sess.run(loss_list))

# [array([ 0.], dtype=float32), array([ 0.], dtype=float32)]

sparse_softmax_cross_entropy_with_logits example:
logits_list = [tf.Variable([[0.0, 0.0, 0.0]]), tf.Variable([[99.0, 0.0, 0.0]])]
labels = tf.cast(tf.Variable([-1]), tf.int64)
loss_list = [tf.nn.sparse_softmax_cross_entropy_with_logits(logits, labels)
             for logits in logits_list]

with tf.Session() as sess:
    sess.run(tf.initialize_all_variables())
    print(sess.run(loss_list))

# [array([ 0.], dtype=float32), array([ 0.], dtype=float32)]

We could filter invalid entries out before computing logits/loss, but in my use cases this would add a lot of boilerplate code and make only a negligible difference performance wise. (RNNs with long sequences, a fairly small number of time steps, multiple predictions per time step, and batch entries with varying sequence_lengths. Using this trick lets us avoid having to break up logits/targets etc. into valid chunks vs. invalid chunks.
Edit: I ended up applying a boolean mask anyway since I wanted to view the loss over time (not just take gradients and minimize). In any case I like the current behavior so that I can apply masks after I obtain loss values over all targets, both valid and invalid.

This seems like reasonable behavior to preserve, since we're unlikely to ever add any kind of checking to these ops (doing so is problematic due to numerical error) and we're unlikely to normalize due to speed.  Documentation contributions welcome!

The described convenient behavior has changed somewhere between versions 0.9 and 0.10.
The snippet with sparse_softmax_cross_entropy_with_logits now results in:
[array([ nan], dtype=float32), array([ nan], dtype=float32)]

Cross entropy for padding values became nan instead of 0.0. Looks like a breaking change: forward pass is okay (with masking), but gradients are stuffed with nans .
Versions with "0" behavior:
linux/gpu/tensorflow-0.9.0-cp27-none-linux_x86_64.whl
Versions with "nan" behavior:
linux/gpu/tensorflow-0.10.0rc0-cp27-none-linux_x86_64.whl
linux/gpu/tensorflow-0.10.0-cp27-none-linux_x86_64.whl

Can you open a new bug for this, explaining what behavior you think is correct?

I let ivan create the bug issue but I confirm that the new behavior can cause some troubles. I am using sparse_softmax_cross_entropy_with_logits and, in my opinion, the best behavior would be to return a loss of 0.0 and null gradients when the label is not in the range [0, num_classes); never return nan.

This is only going to get more strict.  Passing labels that are out of range is a sign of a hidden bug; one that may have model builders searching for a long time before figuring out the true problem.  Starting in a few days, this op will raise exceptions when passed invalid labels on CPU.  On GPU it will continue to return NaNs because we can't easily pass error flags back from the GPU.


Fix tests according changes in Appclusive 1.1.*

[ ]  fix tests in src
[ ]  fix tests in it

First run of src tests:
Describing Get-ManagementCredential
   Context Get-ManagementCredential
    [-] Get-ManagementCredentialListAvailable-ShouldReturnList 276ms
      Expected: value was {}, but should not have been the same
      at line: 26 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Get-ManagementCredential.Tests.ps1
      26:                       $result | Should Not Be $null;
    [-] Get-ManagementCredentialListAvailableSelectName-ShouldReturnListWithNamesOnly 52ms
      Expected: value was {}, but should not have been the same
      at line: 39 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Get-ManagementCredential.Tests.ps1
      39:                       $result | Should Not Be $null;
ConvertTo-SecureString : Cannot bind argument to parameter 'String' because it is null.
At C:\Github\biz.dfch.PS.Appclusive.Client\src\Get-ManagementCredential.ps1:285 char:30
+             $Password = $r.Password | ConvertTo-SecureString -asPlainText -Force;
+                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [ConvertTo-SecureString], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.ConvertToSecureStringCommand

    [-] Get-ManagementCredentialAsPSCredential-ShouldReturnPSCredential 291ms
      Expected: value was {}, but should not have been the same
      at line: 54 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Get-ManagementCredential.Tests.ps1
      54:                       $result | Should Not Be $null;
    [-] Get-ManagementCredential-ShouldReturnEntity 65ms
      Expected: value was {}, but should not have been the same
      at line: 66 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Get-ManagementCredential.Tests.ps1
      66:                       $result | Should Not Be $null;
    [+] Get-ManagementCredentialThatDoesNotExist-ShouldReturnNull 63ms
Describing Get-Time
   Context Get-Time
    [+] Warmup 1.42s
    [+] Get-TimeSucceeds 677ms
    [+] Get-TimeMatchesLocalTimeSucceeds 457ms
Describing New-KeyNameValue
   Context New-KeyNameValue
    [-] New-KeyNameValue-ShouldReturnNewEntity 598ms
      Expected: value was {}, but should not have been the same
      at line: 28 in C:\Github\biz.dfch.PS.Appclusive.Client\src\New-KeyNameValue.Tests.ps1
      28:                       $result | Should Not Be $null;
    [-] New-KeyNameValueWithDescription-ShouldReturnNewEntity 275ms
      Expected: value was {}, but should not have been the same
      at line: 46 in C:\Github\biz.dfch.PS.Appclusive.Client\src\New-KeyNameValue.Tests.ps1
      46:                       $result | Should Not Be $null;
    [+] New-KeyNameValueWithDuplicate-ShouldReturnNull 648ms
Describing New-ManagementCredential
   Context New-ManagementCredential
    [-] New-ManagementCredential-ShouldReturnNewEntity 472ms
      Expected: value was {}, but should not have been the same
      at line: 28 in C:\Github\biz.dfch.PS.Appclusive.Client\src\New-ManagementCredential.Tests.ps1
      28:                       $result | Should Not Be $null;
    [-] New-ManagementCredentialDuplicate-ShouldReturnNull 272ms
      Expected: value was {}, but should not have been the same
      at line: 41 in C:\Github\biz.dfch.PS.Appclusive.Client\src\New-ManagementCredential.Tests.ps1
      41:                       $result1 | Should Not Be $null;
Describing Pop-ChangeTracker
   Context Pop-ChangeTracker
    [+] Warmup 646ms
    [+] Pop-ChangeTrackerWithNullStack-ThrowsException 478ms
    [+] Pop-ChangeTrackerWithEmptyStack-ThrowsException 529ms
    [+] Pop-ChangeTrackerWithEmptyHashtable-ClearsChangeTracker 522ms
    [+] Pop-ChangeTrackerReinitialised-HasNoDataContext 577ms
WARNING: The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
At C:\Github\biz.dfch.PS.Appclusive.Client\src\Pop-ChangeTracker.Tests.ps1:107 char:4
+             $endpoints = $svc.Diagnostics.Endpoints | Select -First $count;
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ExtendedTypeSystemException
    + FullyQualifiedErrorId : ExceptionInGetEnumerator

    [-] Pop-ChangeTrackerReinitialised-PushAndPopHasNoDataContext 2.34s
      The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
      at line: 107 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Pop-ChangeTracker.Tests.ps1
WARNING: The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
At C:\Github\biz.dfch.PS.Appclusive.Client\src\Pop-ChangeTracker.Tests.ps1:126 char:4
+             $endpoints = $svc.Diagnostics.Endpoints | Select -First $count;
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ExtendedTypeSystemException
    + FullyQualifiedErrorId : ExceptionInGetEnumerator

    [-] Pop-ChangeTrackerClear-Succeeds 658ms
      The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
      at line: 126 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Pop-ChangeTracker.Tests.ps1
Describing Push-ChangeTracker
   Context Push-ChangeTracker
    [+] Warmup 677ms
    [+] Push-ChangeTrackerUninitialised-ThrowsException 585ms
    [+] Push-ChangeTrackerReinitialised-HasEmptyDataContext 524ms
    [+] Push-ChangeTrackerListAvailableWithZeroEntities-ReturnsHashtableWithZeroEntries 539ms
    [-] Push-ChangeTrackerListAvailableWithTwoEntities-ReturnsHashtableWithTwoEntries 560ms
      The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
      at line: 79 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Push-ChangeTracker.Tests.ps1
    [-] Push-ChangeTrackerWithTwoEntities-ReturnsHashtableWithTwoEntries 581ms
      The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
      at line: 99 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Push-ChangeTracker.Tests.ps1
    [-] Push-ChangeTrackerTwoTimes-ReturnsStackSizeTwo 469ms
      The following exception occurred while trying to enumerate the collection: "An error occurred while processing this request.".
      at line: 114 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Push-ChangeTracker.Tests.ps1
Describing Remove-KeyNameValue
   Context Remove-KeyNameValue
    [-] Remove-KeyNameValueSingleEntity-ShouldReturnRemovedEntity 450ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 23 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Remove-KeyNameValue.Tests.ps1
    [-] Remove-KeyNameValueMultipleEntities-ShouldReturnRemovedEntity 272ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 45 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Remove-KeyNameValue.Tests.ps1
    [+] Remove-KeyNameValueThatDoesNotExist-ShouldReturnNewEntity 103ms
    [+] Remove-KeyNameValueWithDuplicate-ShouldReturnNull 87ms
Describing Remove-ManagementCredential
   Context Remove-ManagementCredential
    [-] Remove-ManagementCredential-ShouldReturnDeletedEntity 516ms
      The term 'New-ManagementCredential' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that
the path is correct and try again.
      at line: 23 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Remove-ManagementCredential.Tests.ps1
    [+] Remove-ManagementCredentialThatDoesNotExist-ShouldReturnNull 69ms
Describing Set-KeyNameValue
   Context Set-KeyNameValue
    [-] Set-KeyNameValueWithCreateIfNotExist-ShouldReturnNewEntity 261ms
      Expected: value was {}, but should not have been the same
      at line: 29 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
      29:                       $result | Should Not Be $null;
    [+] Set-KeyNameValueWithoutCreateIfNotExist-ShouldReturnNull 82ms
    [-] Set-KeyNameValueWithNewValue-ShouldReturnUpdatedEntity 230ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 61 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
    [-] Set-KeyNameValueWithNewName-ShouldReturnUpdatedEntity 245ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 86 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
    [-] Set-KeyNameValueWithNewKey-ShouldReturnUpdatedEntity 187ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 111 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
    [-] Set-KeyNameValueWithNewKeyNameValue-ShouldReturnUpdatedEntity 293ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 136 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
    [-] Set-KeyNameValueWithNewKeyNameValueDescription-ShouldReturnUpdatedEntity 229ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 162 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
    [-] Set-KeyNameValueWithDuplicate-ShouldReturnNull 228ms
      The term 'New-KeyNameValue' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
 is correct and try again.
      at line: 184 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-KeyNameValue.Tests.ps1
Describing Set-ManagementCredential
   Context Set-ManagementCredential
    [-] Set-ManagementCredential-ShouldReturnNewEntity 245ms
      Expected: value was {}, but should not have been the same
      at line: 28 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-ManagementCredential.Tests.ps1
      28:                       $result | Should Not Be $null;
    [-] Set-ManagementCredentialWithNewUsernameAndDescription-ShouldReturnUpdatedEntity 82ms
      Expected: value was {}, but should not have been the same
      at line: 44 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Set-ManagementCredential.Tests.ps1
      44:                       $result1 | Should Not Be $null;
Describing Test-Status
   Context Test-Status
    [+] Warmup 800ms
    [+] Test-StatusAnonymousSucceeds 620ms
    [+] Test-StatusAuthenticatedSucceeds 528ms
    [+] Test-StatusEchoSucceeds 883ms
WARNING: Test-Status : Cannot validate argument on parameter 'InputObject'. The number of characters (0) in the argument is too small. Specify an argument whose length is greater than or equal to "1"
 and
then try the command again.
At C:\Github\biz.dfch.PS.Appclusive.Client\src\Test-Status.Tests.ps1:79 char:26
+             $result = Test-Status $InputObject -svc $svc;
+                                   ~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Test-Status], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Test-Status

    [-] Test-StatusEchoWithEmptyInputFails 659ms
      Cannot validate argument on parameter 'InputObject'. The number of characters (0) in the argument is too small. Specify an argument whose length is greater than or equal to "1" and then try the
command again.
      at line: 79 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Test-Status.Tests.ps1
WARNING: Test-Status : Cannot validate argument on parameter 'InputObject'. The number of characters (0) in the argument is too small. Specify an argument whose length is greater than or equal to "1"
 and
then try the command again.
At C:\Github\biz.dfch.PS.Appclusive.Client\src\Test-Status.Tests.ps1:92 char:26
+             $result = Test-Status $InputObject -svc $svc;
+                                   ~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Test-Status], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Test-Status

    [-] Test-StatusEchoWithTooLongInputFails 645ms
      Cannot validate argument on parameter 'InputObject'. The number of characters (0) in the argument is too small. Specify an argument whose length is greater than or equal to "1" and then try the
command again.
      at line: 92 in C:\Github\biz.dfch.PS.Appclusive.Client\src\Test-Status.Tests.ps1
Tests completed in 22.98s
Passed: 22 Failed: 27 Skipped: 0 Pending: 0

done by @dfch


fix: use non-root user

According to spec user should be set to non root user. Otherwise with newer pack there are errors: ERROR: failed to build: refusing to run as root.

@lance BTW I think that with this we might disable --trust-builder in func making it possible to use podman (before we fix root-cause  podman)


Pressing settings for a generator clears the workspace

This is due to the click handler of the generator including clicks which are in the settings/dimension box.

This was introduced in d9d02b4aefd5b73c4dff3e763050e88067220c41

Oops, sorry about that!

Fixed now and automerging.

Oops, this only fixes the settings cog. Another PR inbound.


Add Sinotimer DTS6619 EVmeter

I add code to support the Sinotimer DTS6619 KWh meter.
Bought from Aliexpress: https://www.aliexpress.com/item/1005006374239794.html
RS485 Dgital Bidirectional Wattmeter 100A 380V AC Three Phase Photovoltatic Energy Meter kWh Power Voltage Current Instrument.
Main changes:

All 16 bit (int) data except for the Energy data which is 32 bit (long)
No total active power (W) but only per phase. Need to add them 3 together.

While testing with the active power data of only 1 phase. I noticed that the minimum data length for modbus was limited to 8 bytes. I think this is not correct. It could be 7 bytes if the data returned is 16 bit (2 bytes). Or even 6 bytes when only 1 byte is returned.
Below the protocol info delivered with the device (contains one error: the divider for Phase ABC Current is not 0.1A but 0.01A)

I hope this is the correct way to contribute :-)

Hi @kwertie01
Thanks for your contribution!
I have looked at your code, and i think it's ready to be included.
I have double checked the modbus response length, and you are right, 7 bytes is the minimum when reading just 1 register.
adr(1) fc(1) len(1) reg(2) crc(2)
@dingo35 can you include it?

Thanks all !!


Is there a way to make gorm send database specific values for created_at, updated_at and deleted_at fields?

Your Question
I have one instance of Postgres DB, and several instances of my app running simultaneously. It is possible they will unsynchronized in time with each other. It will lead to some problems with my business logic because I need to precisely track changes.
I see a possible solution in using now() instead of the exact time 2022-02-09 17:39:47.785 in database transactions, but I don't know how to do it with gorm. Of course, I can update it later with a separate transaction, or even write a raw SQL query and send it via gorm, but it will add unwanted complexity to my code.
So, by doing this
type Data struct {
    gorm.Model
    Value string
}
...
db.Create(&Data{Value: "some value"})

I see this
INSERT INTO "data" ("created_at","updated_at","deleted_at","value") VALUES ('2022-02-09 18:22:44.728','2022-02-09 18:22:44.728',NULL,'some value') RETURNING "id";

And I want to see that
INSERT INTO "data" ("created_at","updated_at","deleted_at","value") VALUES (now(),now(),NULL,'some value') RETURNING "id";

The document you expected this should be explained
https://gorm.io/docs/gorm_config.html

Expected answer
Some code example or a link to the document.

by default, not possible. but you could make it works if creating with sql expression, refer: https://gorm.io/docs/create.html#Create-From-SQL-Expression-Context-Valuer,  or set a default tag with  database specific  funcs like now() for those fields


Support .devcontainer/Dockerfile for license headers check

Run curl -s https://raw.githubusercontent.com/swiftlang/github-workflows/refs/heads/main/.github/workflows/scripts/check-license-header.sh | bash
  curl -s https://raw.githubusercontent.com/swiftlang/github-workflows/refs/heads/main/.github/workflows/scripts/check-license-header.sh | bash
  shell: /usr/bin/bash -e {0}
  env:
    PROJECT_NAME: VS Code Swift
** ERROR: Unsupported file extension Dockerfile for file (exclude or update this script): .devcontainer/Dockerfile
bash: line 74: expected_file_header: unbound variable

We normally expect no license header in Dockerfiles and so far we have ignored those in .licenseignore files. I would personally say we don't need to add support for Dockerfiles here


tox link in README.md seems to be out of date

https://github.com/drivendata/cookiecutter-data-science/blob/master/README.md#the-resulting-directory-structure contains this line:
└── tox.ini            <- tox file with settings for running tox; see tox.testrun.org

However, tox.testrun.org doesn't seem to actually have to do with tox. Perhaps the link is outdated.
Suggestion: use https://tox.readthedocs.io/ instead.

Seems to be fixed in 78e001f742f8253c88e6edb62ea35ebfa8939f18


undefined function on (cepl:repl)

Hi! I am running  OS X 10.9.4 and am getting the following error after I (ql:quickload :cepl) and (cepl:repl)

Is this the OpenGL context error you mentioned? I made sure that the sbcl I had on this computer has native threads enabled. Is there anything I can do to change the default context?

This is on the todo list but has fallen behind because of focusing on other features (because of some deadlines coming). I have heard people getting cl-sdl2 working perfectly on osx so I will be able to get this work. I just dont have it today.

OSX support has been present for a while now. Sorry I forgot to close this


Optimization: use separate keys for different gpu variants

Optimization: use separate keys for different gpu variants and use std::unordered_map::find() instead of std::find_if
Before optim: Debug ~16s Release ~0.8s
After optim: Debug ~13s Release ~0.2s

You have me as an assignee? Not a reviewer?
Also, can you give me a short snippet of the before and after of the pm4_info.cpp code so I can get an idea of the difference?

You have me as an assignee? Not a reviewer? Also, can you give me a short snippet of the before and after of the pm4_info.cpp code so I can get an idea of the difference?

oops, fixed
The actual difference is only in const RegInfo *GetRegInfo(uint32_t reg), the other changes are just removing '|0x0` (since we are only parsing a6xx.xml) there is no reg that supports multiple variants other than a6xx and a7xx


Adding AutoChunk/MaxMB Support to Filer API

This is related to the following issue I added to chrislusf/seaweedfs:
https://github.com/chrislusf/seaweedfs/issues/342
I'm VERY new to golang (and github), so let me know if there is anything I should be doing differently.
Thanks!
Mike

Thanks!
Your code looks professional. :) That's what I like about Go. It helps to focus on the actual logic, rather than syntax.


[Snyk] Security upgrade python from 3.6 to 3.14.0a3

Snyk has created this PR to fix 2 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

examples/xgboost/smoke-dist/Dockerfile

We recommend upgrading to python:3.14.0a3, as this image has only 180 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Out-of-bounds Write SNYK-DEBIAN11-LIBWEBP-5893094
  829

Out-of-bounds Write SNYK-DEBIAN11-LIBWEBP-5893094
  829

Out-of-bounds Write SNYK-DEBIAN11-LIBWEBP-5893094
  829

Out-of-bounds Write SNYK-DEBIAN11-LIBWEBP-5893094
  829

CVE-2023-44487 SNYK-DEBIAN11-NGHTTP2-5953384
  829

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall first build on snyk-fix-c9eb47a17964173426a89b7bec621dc4 at 42.877%

Totals

Change from base Build<PHONE_NUMBER>4:
42.9%

Covered Lines:
3753

Relevant Lines:
8753

💛  - Coveralls


Error in Grafana datasource.

Bug Description
When relating Loki to Grafana, we can see:

Data source connected, but no labels received. Verify that Loki and Promtail is configured properly.

To Reproduce

Deploy Loki
Deploy Grafana
Relate both charms: juju relate loki grafana:grafana-source
Check Loki datasource in Grafana

Environment
COS-lite edge:
╭─ubuntu@charm-dev-juju-31 ~/repos [microk8s:cos]
╰─$ juju status                                                                                130 ↵
Model  Controller  Cloud/Region        Version  SLA          Timestamp
cos    microk8s    microk8s/localhost  3.1.2    unsupported  11:18:04-03:00

App           Version  Status  Scale  Charm             Channel  Rev  Address         Exposed  Message
alertmanager  0.25.0   active      1  alertmanager-k8s  edge      81  <IP_ADDRESS>   no
catalogue              active      1  catalogue-k8s     edge      21  <IP_ADDRESS>  no
grafana       9.2.1    active      1  grafana-k8s       edge      87  <IP_ADDRESS>  no
loki          2.7.4    active      1  loki-k8s          edge      96  <IP_ADDRESS>   no
prometheus    2.46.0   active      1  prometheus-k8s    edge     135  <IP_ADDRESS>   no
traefik       2.9.6    active      1  traefik-k8s       edge     139  <IP_ADDRESS>  no

Unit             Workload  Agent  Address      Ports  Message
alertmanager/0*  active    idle   <IP_ADDRESS>
catalogue/0*     active    idle   <IP_ADDRESS>
grafana/0*       active    idle   <IP_ADDRESS>
loki/0*          active    idle   <IP_ADDRESS>
prometheus/0*    active    idle   <IP_ADDRESS>
traefik/0*       active    idle   <IP_ADDRESS>

Offer                            Application   Charm             Rev  Connected  Endpoint              Interface                Role
alertmanager-karma-dashboard     alertmanager  alertmanager-k8s  81   0/0        karma-dashboard       karma_dashboard          provider
grafana-dashboards               grafana       grafana-k8s       87   0/0        grafana-dashboard     grafana_dashboard        requirer
loki-logging                     loki          loki-k8s          96   0/0        logging               loki_push_api            provider
prometheus-receive-remote-write  prometheus    prometheus-k8s    135  0/0        receive-remote-write  prometheus_remote_write  provider
prometheus-scrape                prometheus    prometheus-k8s    135  0/0        metrics-endpoint      prometheus_scrape        requirer

When pressing the Test button, we receive a 200:

Relevant log output
.

Additional context
No response

After deploying and relating Zinc to Loki, everything is ok

Seems it's a Grafana issue.


Update client3:async-http-client-backend-cats, ... to 3.8.5

Updates

com.softwaremill.sttp.client3:async-http-client-backend-cats
com.softwaremill.sttp.client3:circe
com.softwaremill.sttp.client3:core

from 3.8.2 to 3.8.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.client3" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.softwaremill.sttp.client3" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #200.


Fix typo in UglifyJS options

This typo caused UglifyJS to print an unhelpful error in some configurations.
Example of the error output:
ERROR in jsx.js from UglifyJs
undefined
ERROR in styles.js from UglifyJs
undefined
To reproduce the problem set ENABLE_HOT_MODULE_REPLACEMENT to false in the example project.

Thanks for taking the time to get to the bottom of that!


Add support for disabling ssl for hex

Uses global rebar config to see if user wishes to disable ssl.
If {disable_ssl, true} is present certificates will not be verified.

This change adds an option that doesn't disable SSL, it disables SSL certificate verification. Perhaps the option and code should be updated to refer to disable_ssl_verify (for example), instead of disable_ssl.

Good point. Will update accordingly.


reminder's response messages don't show up when chatting with the bot on commandline

Rasa Core version: dispatcher
Python version: 3.6
Operating system (windows, osx, ...): osx
Issue:
when using reminders the response messages don't show up when chatting with the bot on commandline
Content of domain file (if used & relevant):

@Ghostvv is this still relevant?

yes I believe so

how about now @Ghostvv ?

I think it is still relevant, but we can probably close the issue, @tmbo?

he's on holiday, so you'll need to decide :D

just leave it open for now


fix: Fixed bug with catboost and groups

Why are these changes needed?
Currently an error is raised when we attempt to use a group-based split (such as GroupKFold or StratifiedGroupKFold) with CatBoost. This issue is caused by the fit() method on CatBoostEstimator, in particular this part:
            model.fit(
                X_tr,
                y_tr,
                cat_features=cat_features,
                eval_set=eval_set,
                callbacks=CatBoostEstimator._callbacks(
                    start_time, deadline, free_mem_ratio if use_best_model else None
                ),
                **kwargs,
            )

When groups is not None, kwargs contains the groups. CatBoost fit methods don't accept groups, which causes the issue.
As I understand it, groups in FLAML (and generally) should be used when splitting data, not when fitting data. Basically, CatBoost does not need groups to be passed in, and likely never will.
I've been through the other FLAML estimators, and they all seem to remove groups from kwargs before calling model.fit. For example, in the _fit() method on the BaseEstimator class defined on flaml/automl/model.py, we have the following code:
        if "groups" in kwargs:
            kwargs = kwargs.copy()
            groups = kwargs.pop("groups")
            if self._task == "rank":
                kwargs["group"] = group_counts(groups)

This code removes groups from the kwargs dictionary, before model.fit() is called.
I've mimicked this 'removal of groups from kwargs' in my code. I've also updated the two tests of group-related splits to include CatBoost as an estimator. Before my changes, the addition of catboost causes these tests to fail, but after removing the groups from kwargs, they pass :)
I welcome any feedback!
Related issue number
Closes #304
Checks

[X] I've used pre-commit to lint the changes in this PR (note the same in integrated in our CI checks).
[X] I've included any doc changes needed for https://microsoft.github.io/FLAML/. See https://microsoft.github.io/FLAML/docs/Contribute#documentation to build and test documentation locally.
[X] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[X] I've made sure all auto checks have passed.

This is a trade-off in user experience. The current code raises an error when CatBoost is used with data containing groups, whereas your PR proposes to silently ignore the group information.

Hi @thinkall,
I'm confused by this. I would argue that my PR doesn't propose to silently ignore the group information - it is simply proposing to not pass groups into .fit(). This PR doesn't seek to treat CatBoost differently to any other estimator in FLAML - it's simply stripping groups out of the kwargs before passing the kwargs to model.fit(). I see no reason why we need to pass a groups argument into the .fit() method for CatBoost and CatBoost only.
To emphasis my point, I first created an example script which reproduces the reported CatBoost error:
from flaml import AutoML
from sklearn import datasets
import numpy as np

dic_data = datasets.load_iris(as_frame=True)  # numpy arrays
iris_data = dic_data["frame"]  # pandas dataframe data + target
rng = np.random.default_rng(42)
iris_data["cluster"] = rng.integers(
    low=0, high=5, size=iris_data.shape[0]
)
print(iris_data["cluster"])
automl = AutoML()
automl_settings = {
    "max_iter":2,
    "metric": 'accuracy',
    "task": 'classification',
    "log_file_name": "catboost_error.log",
    "log_type": "all",
    "estimator_list": ['catboost'],
    "eval_method": "cv",
    "split_type":"group",
    "groups": iris_data['cluster']
}
x_train = iris_data[["sepal length (cm)","sepal width (cm)", "petal length (cm)","petal width (cm)"]].to_numpy()
y_train = iris_data['target']

The error (as expected):

I then re-ran the script with "estimator_list": ['lgbm']. This initially runs without errors, as expected. However, if I go into BaseEstimator._fit(), on `flaml/automl/model.py and comment out this the kwarg-popping code mentioned above:
        if "groups" in kwargs:
            kwargs = kwargs.copy()
            groups = kwargs.pop("groups")
            if self._task == "rank":
                kwargs["group"] = group_counts(groups)

Then rerunning the AutoML code gives this error:

Likewise if I run the same code with RandomForestEstimator as my only estimator:

Basically as I understand it, CatBoostEstimator is the only FLAML estimator (that I use at least) which does not at any point call BaseEstimator._fit(). Therefore CatBoostEstimator is the only FLAML model which doesn't pop the groups keyword out of the kwargs before calling model.fit(). I've investigated this pretty thoroughly now, and I'm fairly confident that no other estimator tries to pass groups to model.fit(). I'm not sure why CatBoostEstimator should be the exception.
Apologies if I'm missing something obvious.
Anyway thanks for reading, I hope that makes sense - please let me know your thoughts!


question: Error: Cannot get connection "default" from the connection manager.

Error: Cannot get connection "default" from the connection manager. Make sure you have created such connection. Also make sure you have called useContainer(Container) in your application before you established a connection and importing any entity.
    at Object.value (/src/decorators/InjectConnection.ts:12:23)
    at /app/src/ContainerInstance.ts:355:37
    at Array.map (<anonymous>)
    at ContainerInstance.initializeParams (/app/src/ContainerInstance.ts:352:27)
    at ContainerInstance.getServiceValue (/app/src/ContainerInstance.ts:305:47)
    at ContainerInstance.get (/app/src/ContainerInstance.ts:119:21)
    at Object.value (/app/src/decorators/Inject.ts:48:42)
    at /app/src/ContainerInstance.ts:355:37
    at Array.map (<anonymous>)
    at ContainerInstance.initializeParams (/app/src/ContainerInstance.ts:352:27)
[nodemon] app crashed - waiting for file changes before starting...

My index.ts
import 'reflect-metadata';

import { Container } from 'typedi';
import { useContainer } from 'typeorm';
import Application from 'src/Application';

useContainer(Container);

const application = Container.get(Application);

application.start();

Same issue, the error only show up when I'm executing a GraphQL query/mutation from a resolver but there was no error on build/compilation time.

The error says it, you attempt to access the connection before you create in TypeORM via calling createConnection. Closing this issue as solved. If your issue still persists please open a new issue with a minimal, reproducible example.

The error says it, you attempt to access the connection before you create in TypeORM via calling createConnection. Closing this issue as solved. If your issue still persists please open a new issue with a minimal, reproducible example.


ERROR: initialize: Directional shadow framebuffer status invalid    At: drivers/gles2/rasterizer_scene_gles2.cpp:3369

Godot version:

Godot_v3.1-stable_win64.exe
OpenGL 2.1 / OpenGL ES 2.0 compatible hardware
OS/device including version:

Windows 10 x64
Intel(R) HD Graphics 3000
OpenGL v.3.1
Issue description:

OpenGL ES 2.0 Renderer: Intel(R) HD Graphics 3000
ERROR: initialize: Directional shadow framebuffer status invalid
At: drivers/gles2/rasterizer_scene_gles2.cpp:3369
Steps to reproduce:

Minimal reproduction project:

Duplicate of #28894

You can use Mesa for Windows and check if this help
You can use Linux(I have this graphics card and it working without any errors)

Yes, this is a duplicate of #28894.
In the future, please search existing issues before opening a new one.

use Mesa for Windows


Make Parquet Hadoop 3 compatible

It seems Hadoop 3 is getting more mature and the downstream projects and distros (e.g. Spark, CDP) are slowly transitioning to use it.
Since Hadoop 2 is probably the standard for a long term maybe we can just benefit of having an extra test configuration that provides the Hadoop 3.x dependencies to ensure that Parquet's current code base is 'forwards' compatible.
Reporter: Ismaël Mejía / @iemejia
Note: This issue was originally created as PARQUET-1697. Please see the migration documentation for further details.

Closing this one, since we're at Hadoop 3.3.6 today 👍


Update docs

PR checklist

[x] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] If necessary, also make a PR on the nf-core/metatdenovo branch on the nf-core/test-datasets repository.
[x] Make sure your code lints (nf-core lint).
[x] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
[x] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[x] CHANGELOG.md is updated.
[x] README.md is updated (including new tool citations and authors/contributors).

I updated the documentation based on issues #281  and #273

This is against master, that's not your intention, right?


Update version of senzing/init-container

Pull requests:

https://github.com/Senzing/docker-wrap-image-with-senzing-apt/pull/9


Patch opencontainers/runc v1.1.2 -> v1.1.5

Patch opencontainers/runc v1.1.2 -> v1.1.5 to fix https://github.com/advisories/GHSA-fh74-hm69-rqjw

/approve


{Branch Management} Merge release 2.26.1 back to dev

Merge fix #18856 back to dev.
🛑 Don't squash merge but merge it locally and push.

Branch Management