Default connection is not assumed to use when loading relations between two connections.

Laravel Version
10.0
PHP Version
8.3.0
Database Driver & Version
MySQL 8.0.31 for macOS 13.0 on arm64
Description
I've just came accross this issue.
Let's say I have these two model:
Author
class Author extends Model {
  // no connection specified, assumed that it should use default connection
}

Post
class Post extends Model {
  public $connection = 'posts';

  public function author(){
    return $this->hasOne(Author::class, 'id', 'author_id');
  }
}

When I run following query I got the similar error:
Error: Base table or view not found: 1146 Table 'posts_database.authors'
Post::query()->with('author')->get();

It was just unexpected behaviour and I solved it by adding public $connection = 'author'; to Author model. In this example it's simple, but can get tricky in my project, where I've to specify public $connection = 'mysql'; to 150+ models.
Similar unexpected error can happen when using filtering of relations such as whereHas method or any method that creates joins or sub queries for selecting/filtering data between multiple connections.
In this case the query will throw error:
Post::query()->whereHas('author', function ($query) {
  $query->where('age', '>', 21);
})->count();

Generated query would be:
select * from `posts` where exists (select * from `authors` where `authors`.`id` = `posts`.`author_id` and `age` > 21);

Where it should be:
select * from `posts_db`.`posts` where exists (select * from `authors_db`.`authors` where `authors_db`.`authors`.`id` = `posts_db`.`posts`.`author_id` and `authors`.`age` > 21);

We can differentiate if the relation model has different connection or different databases names and then qualify full column name prefixed by database name.
I know this usecase is so uncommon, but whole relation thing becomes unusable when using multiple connections even when databases can see each others and theoretically is possible.
I can start working to solve that if it is real issue not only for me.
Steps To Reproduce
I've just came accross this issue.
Let's say I have these two model:
Author
class Author extends Model {
  // no connection specified, assumed that it should use default connection
}

Post
class Post extends Model {
  public $connection = 'posts';

  public function author(){
    return $this->hasOne(Author::class, 'id', 'author_id');
  }
}

When I run following query I got the similar error:
Error: Base table or view not found: 1146 Table 'posts_database.authors'
Post::query()->with('author')->get();

It was just unexpected behaviour and I solved it by adding public $connection = 'author'; to Author model. In this example it's simple, but can get tricky in my project, where I've to specify public $connection = 'mysql'; to 150+ models.
Similar unexpected error can happen when using filtering of relations such as whereHas method or any method that creates joins or sub queries for selecting/filtering data between multiple connections.
In this case the query will throw error:
Post::query()->whereHas('author', function ($query) {
  $query->where('age', '>', 21);
})->count();

Generated query would be:
select * from `posts` where exists (select * from `authors` where `authors`.`id` = `posts`.`author_id` and `age` > 21);

Where it should be:
select * from `posts_db`.`posts` where exists (select * from `authors_db`.`authors` where `authors_db`.`authors`.`id` = `posts_db`.`posts`.`author_id` and `authors`.`age` > 21);

We can differentiate if the relation model has different connection or different databases names and then qualify full column name prefixed by database name.
I know this usecase is so uncommon, but whole relation thing becomes unusable when using multiple connections even when databases can see each others and theoretically is possible.
I can start working to solve that if it is real issue not only for me.

The same underlying issue is causing trouble and extra work in migrations. We now define the connection property on the migration, plus define the connection on every Schema/DB facade call.
First, it's a bit cumbersome. Second, the worst side effect, if not doing so, is that in some situations migrations were ran even when --pretend was passed to the migrate command.
So from me it's a "not only an issue for you". This definitely could use some love.

Hey there,
Unfortunately we don't support this version of the library anymore. Please check out our support policy on which versions we are currently supporting. Can you please try to upgrade to the latest version and see if your problem persists? If so, please open up a new issue and we'll help you out.
Thanks!

@malkhazidartsmelidze do you cosider re-submitting this for Laravel 11/12?


Clicking "Load more" removes all results for certain queries

Description

When clicking the "Load More" button on certain results, all results on the page disappear.
Reproduction

Visit this URL: https://search.openverse.engineering/search/image?q=Tycho Brahe&source=smk
Click "Load more results"
All results disappear and the empty search results page shows up

Additional context

@zackkrida found that this may be due to unexpected API behavior: https://wordpress.slack.com/archives/C02012JB00N/p1669738284048119
Resolution

[ ] 🙋 I would be interested in resolving this bug.

In a curious twist, the newly-deployed frontend is handling this search correctly. I'll need to investigate specifically why it is working now.

That's it! Thanks @AetherUnbound

I think we might still be able to reproduce this with a different search term though. Now just to find the right one... 😅


Feat new db

Proposed Changes:

move persistence from /source/file to a single package
move db config to loggie.yml
replace sqlite with badger

Which issue(s) this PR fixes:

Fixes #
Additional documentation:

https://github.com/loggie-io/loggie/pull/475


FIX: Read events from ceo file.

Reference issue
Fixes #9380
Improves #9381
What does this implement/fix?
With #9381, 'ceo' files can be imported after renaming to 'cef'. This PR adds '.ceo' extension to event file extensions.

@rezashr can you add an entry to doc/changes/latest.inc in the enhancements section?

@larsoner there was an entry for reading '.cdt.ceo' events in latest.inc, so I merged this PR description to that one. Is it okay?

@rezashr I think you just need to add your name+URL to doc/changes/names.inc then we should be good here!

thx @rezashr


Nested box

flatten ||x|| = |x|

and
flatten |xbox| = let |x| : Int = xbox in |x|

should be the same.

flatten ||x|| = |x|

is also causing issues in the desugarer

This looks like it is fixed now.

I don't know how this was resolved but flatten ||x|| = |x| should be fine, but the following should be rejected
flatty : forall (n : Nat=, m : Nat=) . (Int |n|) |m| -> Int |n*m|
flatty xboxbox = let |xbox| = xboxbox in let |x| = xbox in |x|

We need to examine whether we did something bad to allow this as a result of this issue, or just incidentally.

This is resolved now and we have tests for this, e.g.,
frontend/tests/cases/negative/flatten/flattenByLet.gr
(negative)
and
StdLib/Prelude.gr
(positive)


Custom runMode?

I see we have development.yaml, staging.yaml and production.yaml. Would it be possible to add custom run modes like alpha.yaml, beta.yaml, testing.yaml etc?

You are not able todo that today, but we would like to add this functionality, this issue is tracked here: https://github.com/serverpod/serverpod/issues/2446

@Isakdl I don't understand your answer. The issue is being tracked here (in the issue that I've opened) but you've just closed it?

@KristijanZic Sorry I pasted the wrong url, here is the correct one: https://github.com/serverpod/serverpod/issues/1212

@KristijanZic Sorry I pasted the wrong url, here is the correct one: https://github.com/serverpod/serverpod/issues/1212

Oh, makes sense, thank you :)


Update main after release v1.31.0

Issue #, if available:
Description of changes:
Update main branch from release/v1.31.x branch
DO NOT SQUASH!
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #579 (6862d20) into main (09e6487) will not change coverage.
Report is 128 commits behind head on main.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff            @@
##               main     #579   +/-   ##
=========================================
  Coverage     85.71%   85.71%
  Complexity       19       19
=========================================
  Files             3        3
  Lines            49       49
  Branches          5        5
=========================================
  Hits             42       42
  Misses            3        3
  Partials          4        4

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Hide plugins flag for now.

Does this need to be removed from the man documentation too?

Does this need to be removed from the man documentation too?

Yup, they are removed in this PR as well


How can I turn off DISABLE_OOB in 21c+ images?

Some my tests check canceling by OCIBreak. However 21c+ images set DISABLE_OOB in sqlnet.ora in the database side and the tests fail. I would be happy if DISABLE_OOB could be optionally turned off in the latest images.
I put the following step in github actions to set the environment variable TWO_TASK for later steps. The tests succeed when the docker image is 18c.
      - name: Get the Oracle container IP address
        env:
          ORACLE_SERVICE_ID: ${{ job.services.oracle.id }}
        run: |
          ORACLE_IP_ADDRESS=$(docker inspect --format='{{range .NetworkSettings.Networks}}{{println .IPAddress}}{{end}}' $ORACLE_SERVICE_ID)
          if test -z "$ORACLE_IP_ADDRESS"; then
              echo "Cannot get ORACLE_IP_ADDRESS."
              docker inspect $ORACLE_SERVICE_ID
              exit 1
          fi
          echo TWO_TASK=//$ORACLE_IP_ADDRESS:1521/XEPDB1 >> $GITHUB_ENV

I resolve it by adding the following step in github actions.
      - name: Enable OOB
        env:
          ORACLE_SERVICE_ID: ${{ job.services.oracle.id }}
        run: |
          docker exec $ORACLE_SERVICE_ID sed -i 's/^DISABLE_OOB/#DISABLE_OOB/; s/^BREAK_POLL_SKIP=1000/#BREAK_POLL_SKIP=1000/' /opt/oracle/oradata/dbconfig/XE/sqlnet.ora
          docker exec $ORACLE_SERVICE_ID lsnrctl reload


Disable Native tests for module 022  because #quarkus/17653

Adding external properties on Native make the app fail to start. Reported by https://github.com/quarkusio/quarkus/issues/17653

Will take a look tommorow

@Sgitario the problem not in converter, but in new library introduced by this commit. I'm working on changes. ConfigProperties annotation should be used instead of the io.smallrye.config.ConfigMapping. But it throws errors, which I'm trying to fix


UpdatedAt field not working anymore in 1.8.3

Hello,
the updatedAt system field do not update anymore on field change in v1.8.3.
Steps to reproduce :
1: prisma init
2: Change model to add createdAt and updatedAt
type User {
id: ID! @unique
name: String!
createdAt: DateTime!
updatedAt: DateTime!
}
3: Deploy on prisma cloud eu1
4: Create a user
mutation{createUser(data:{name:"test2"}){id, createdAt, updatedAt}}
Result :
{   "data": {     "createUser": {       "id": "cjht72uyjvrx50b75k7vy5rnf",       "createdAt": "2018-05-30T14:17:07.389Z",       "updatedAt": "2018-05-30T14:17:07.389Z"     }   } }
5: update the user :
mutation{updateUser(data:{name:"BBB"}, where:{id:"cjht72uyjvrx50b75k7vy5rnf"}){id, name,createdAt, updatedAt }}
Result:
{   "data": {     "updateUser": {       "id": "cjht72uyjvrx50b75k7vy5rnf",       "name": "BBB",       "createdAt": "2018-05-30T14:17:07.389Z",       **"updatedAt": "2018-05-30T14:17:07.389Z"**     }   } }
Expected:
updatedAt should have changed to reflect the date/time of previous update
This plays out the same way on a local cluster.
I have this example on accessible from prisma cloud. Here is the link to the playground : https://graphqlbin.com/v2/yrA0Ty
Thanks for any help on this !
Regards,
Nicolas Signes

Hey @nsignes, thanks for reporting this. Are you using the MySql or Postgres connector? And are migrations activated?

Hi do4g,
We're using the MySQL connector, and migrations left unspecified in the docker-compose.yaml (which means it's turned on by default, according to the documentation).
The bug occurs on a test service deployed to Prisma Cloud EU1, but I don't know how this one is configured.

The fix is now available in the stable channel.

@do4gr Still seeing this as an issue. What version was this fixed in?


Clean LG/Expression

Pull Request Test Coverage Report for Build 111634

103 of 113 (91.15%)  changed or added relevant lines in 16 files are covered.
73 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.4%) to 82.305%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

libraries/adaptive-expressions/src/expressionFunctions.ts
9
10
90.0%

libraries/botbuilder-lg/src/extractor.ts
0
1
0.0%

libraries/botbuilder-lg/src/lgExtensions.ts
22
23
95.65%

libraries/botbuilder-lg/src/lgFile.ts
14
16
87.5%

libraries/botbuilder-lg/src/expander.ts
8
13
61.54%

Files with Coverage Reduction
New Missed Lines
%

libraries/adaptive-expressions/src/expression.ts
1
59.32%

libraries/botbuilder-lg/src/errorListener.ts
2
58.33%

libraries/botbuilder-lg/src/range.ts
2
76.92%

libraries/botbuilder-lg/src/extractor.ts
68
3.19%

Totals

Change from base Build 111579:
-0.4%

Covered Lines:
9298

Relevant Lines:
10884

💛  - Coveralls


Executing Image.convert function crashes Godot

Godot version
4.2.beta.custom_build. e38686f85
System information
Ubuntu 22.04 CI
Issue description
When executing (this code was automatically minimized, so it is possible, that an even more "minimal" project can be created)
extends Node
func _process(delta):
	for i in get_children():
		i.queue_free()
	var temp_variable8899 = Image.new()
	temp_variable8899.crop(79, 42)
	temp_variable8899.convert(10)
	temp_variable8899.generate_mipmaps(false)
	temp_variable8899.convert(-19)

Godot crashes:
Godot Engine v4.2.beta.custom_build.e38686f85 - https://godotengine.org
Time set to: 0 seconds.
Loaded settings:
modules/gdscript/gdscript_vm.cpp:698:13: runtime error: store to misaligned address 0x62100012df5c for type '<unknown> *', which requires 8 byte alignment
0x62100012df5c: note: pointer points here
  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  15 00 00 00 10 00 00 01  14 00 00 00 06 00 00 00
              ^
'add_arguments_to_tree' with value 'true'
modules/gdscript/gdscript_vm.cpp:705:42: runtime error: load of misaligned address 0x62100012df5c for type '<unknown> *', which requires 8 byte alignment
0x62100012df5c: note: pointer points here
  04 00 00 00 05 03 fc 1a  71 55 00 00 00 00 00 00  15 00 00 00 10 00 00 01  14 00 00 00 06 00 00 00
              ^
'delay_removing_added_arguments_to_next_frame' with value 'true'
######################## Ending test ########################
ERROR: The Image format specified<PHONE_NUMBER>) is out of range. See Image's Format enum.
   at: initialize_data (core/io/image.cpp:2175)
core/io/image.cpp:3633:9: runtime error: null pointer passed as argument 1, which is declared to never be null
core/io/image.cpp:3633:9: runtime error: null pointer passed as argument 2, which is declared to never be null
ERROR: Index p_x = 0 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 1 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
....
ERROR: Index p_x = 72 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 73 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 74 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 75 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 76 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 77 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
ERROR: Index p_x = 78 is out of bounds (width = 0).
   at: set_pixel (core/io/image.cpp:3293)
core/io/image.cpp:544:10: runtime error: null pointer passed as argument 1, which is declared to never be null
core/io/image.cpp:544:10: runtime error: null pointer passed as argument 2, which is declared to never be null
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.beta.custom_build (e38686f85b768a451dc06324fe2471adc8665448)
Dumping the backtrace. Please include this when reporting the bug to the project developer.

-- END OF BACKTRACE --
================================================================
Aborted (core dumped)

This example was found by Godot fuzzer - Qarminer, so it is quite unlikelly that this code could be used in real project, but still this should be handled gracefully.
Memory leaks or asan backtraces are visible when using Godot build with sanitizers support - https://github.com/qarmin/GodotBuilds/actions (linux -> linux-editor-sanitizers)
Steps to reproduce
Above
Minimal reproduction project
Above

Missing format validity check, should be trivial to add a safety check

Added a PR. Is this how you use the error system in Godot? Is just a message enough or should a specific code be returned? https://github.com/godotengine/godot/pull/84782


Add simple matching engine

This PR adds a default/generic implementation of a MatchingEngine.

Coverage decreased (-6.8%) to 90.374% when pulling c3501eca3534f0d72550acd599e26b85081c4848 on add-simple-matching-engine into 87b0d8a99cf5263309bf231757acd858dcaaae20 on develop.

Coverage decreased (-6.8%) to 90.374% when pulling 21eafc2022e518134d41ef28165eac25efd9cb9f on add-simple-matching-engine into 87b0d8a99cf5263309bf231757acd858dcaaae20 on develop.

Coverage decreased (-4.04%) to 93.122% when pulling 2ac4ba4f1d0b984f57f8b5c57c3bb82d627d7184 on add-simple-matching-engine into 87b0d8a99cf5263309bf231757acd858dcaaae20 on develop.


Implement initial models and basic project structure.

Not one code comment. Oof

Not one code comment. Oof

Nice to meet you Max, I appreciate the friendly feedback.


Plugin is crashing when group-by is used

Is this a gitql bug or in the plugin?
 with-env {RUST_BACKTRACE : full} {query git "select name, count(1) from commits group by 1"}
thread 'plugin runner (primary)' panicked at /home/knorke/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gitql-parser-0.8.0/src/parser.rs:1367:46:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0:     0x55ed068f0376 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::he8cd6f8498d13785
   1:     0x55ed06598f9b - core::fmt::write::hc1b082ba0a6fc11c
   2:     0x55ed068fb19f - std::io::Write::write_fmt::h82b83f872da9c1a6
   3:     0x55ed068fee8b - std::panicking::default_hook::{{closure}}::hdd246f8991ed5f80
   4:     0x55ed068fe9b8 - std::panicking::default_hook::ha641aac0936707a1
   5:     0x55ed068ff532 - std::panicking::rust_panic_with_hook::ha049d193cc65543f
   6:     0x55ed068f0713 - std::panicking::begin_panic_handler::{{closure}}::hb2ea1e9aac12b33c
   7:     0x55ed068f0579 - std::sys::backtrace::__rust_end_short_backtrace::ha22b579dcb044f1c
   8:     0x55ed068ff074 - rust_begin_unwind
   9:     0x55ed0655caa3 - core::panicking::panic_fmt::h293d2254b180c654
  10:     0x55ed0655cb2c - core::panicking::panic::h629b72f7dffcf333
  11:     0x55ed0655d089 - core::option::unwrap_failed::h1adad2599d1edee7
  12:     0x55ed065d5a67 - gitql_parser::parser::parse_unary_expression::h615179ff33184771
  13:     0x55ed065d3e40 - gitql_parser::parser::parse_glob_expression::h25a3dd8a38b81c7b
  14:     0x55ed065d3abc - gitql_parser::parser::parse_like_expression::h561ca388d8046985
  15:     0x55ed065d36a8 - gitql_parser::parser::parse_factor_expression::h1c48e9da7ba34279
  16:     0x55ed065d32d9 - gitql_parser::parser::parse_term_expression::h3c5dad08609f81a3
  17:     0x55ed065d2ee4 - gitql_parser::parser::parse_bitwise_shift_expression::h084e934b056d7165
  18:     0x55ed065d2af8 - gitql_parser::parser::parse_comparison_expression::h52cdfa25f23a0df9
  19:     0x55ed065d2737 - gitql_parser::parser::parse_equality_expression::h325fb18bf5aca1cc
  20:     0x55ed065d2221 - gitql_parser::parser::parse_bitwise_and_expression::h0d22b09c27d110b7
  21:     0x55ed065d1de4 - gitql_parser::parser::parse_logical_xor_expression::h1bab6a5dc05c381c
  22:     0x55ed065d19a7 - gitql_parser::parser::parse_bitwise_or_expression::hc4ca15e0529b51ae
  23:     0x55ed065d156a - gitql_parser::parser::parse_logical_and_expression::h44e9032b009b764c
  24:     0x55ed065d112d - gitql_parser::parser::parse_logical_or_expression::hd9cce9b49bf696a8
  25:     0x55ed065d05f5 - gitql_parser::parser::parse_expression::hdfc429d422bd7e69
  26:     0x55ed065ccb31 - gitql_parser::parser::parse_gql::h8d4724bf1ebb26f4
  27:     0x55ed067ea905 - <T as nu_plugin::plugin::command::PluginCommand>::run::ha7c183173fbb2526
  28:     0x55ed0679161d - std::panic::catch_unwind::hec87457109eef2fd
  29:     0x55ed067b1518 - std::sys::backtrace::__rust_begin_short_backtrace::h2b40c9548d099ec2
  30:     0x55ed067ca756 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hd3147c9aafb01528
  31:     0x55ed068f5eab - std::sys::pal::unix::thread::Thread::new::thread_start::hc87b62e624def408
  32:     0x7fb07b0983b2 - start_thread
  33:     0x7fb07b11d5fc - __clone3
  34:                0x0 - <unknown>
Error:   × Failed to receive response to plugin call from `query_git`
   ╭─[entry #14:1:35]
 1 │ with-env {RUST_BACKTRACE : full} {query git "select name, count(1) from commits group by 1"}
   ·                                   ────┬────
   ·                                       ╰── while waiting for this operation to complete
   ╰────
  help: try restarting the plugin with `plugin use 'query_git'`

I am using Nushell 0.99.1
 version
╭────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ version            │ 0.99.1                                                                                │
│ major              │ 0                                                                                │
│ minor              │ 99                                                                                │
│ patch              │ 1                                                                                │
│ branch             │                                                                                │
│ commit_hash        │                                                                                │
│ build_os           │ linux-x86_64                                                                                │
│ build_target       │ x86_64-unknown-linux-gnu                                                                             │
│ rust_version       │ rustc 1.81.0 (eeb90cda1 2024-09-04) (built from a source tarball)                                    │
│ cargo_version      │ cargo 1.81.0 (2dbb1af80 2024-08-20)                                                                  │
│ build_time         │ 2024-10-20 22:34:00 +00:00                                                                           │
│ build_rust_channel │ release                                                                                │
│ allocator          │ mimalloc                                                                                │
│ features           │ default, sqlite, trash                                                                               │
│ installed_plugins  │ emoji 0.7.0, file 0.9.0, gstat 0.99.1, polars 0.99.1, port_scan 1.2.5, query 0.99.1, query_git 0.8.0 │
╰────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────╯

I'm not sure.
I have a newer version that I've been working on. I'm planning on just overwriting this plugin with that one since it uses all the latest gitql crates.
You could try this one to see if it works any better. https://github.com/fdncred/nu_plugin_gitql

@fdncred I installed the gitql plugin from git and (qickly) tested it with my 0.99.1 Nushell. Seems to work just fine, even though it was compiled against 0.99.2 git-based Nushell code.
Please provide a way to just install it via cargo install nushell_plugin_gitql. Thank you very very much!

I plan on just adding all the code to nu_plugin_query_git and publishing it at some point. I was waiting on a bugfix from the gitql folks.

Group-by in your "new" repo/plugin is working but leads to wrong results. I suppose that's an  GQL bug.
gitql 'select author_name, count() from commits group by author_name' in your repository with just you as a devloper leads to multiple lines…

@realknorke have you tried the latest main branch of gitql? several things were changed/update in the GQL crates.


Creating a product type fails when valid/invalid, or empty attributes were provided

Steps to reproduce the problem
Invoke createProductType with productAttributes supplied, empty or invalid.
Query:
    mutation createProductType($name: String!, $attributesIDs: [ID!]) {
      productTypeCreate(input: {name: $name, hasVariants: false, productAttributes: $attributesIDs}) {
        productType {
          id
          name
        }

        errors {
          field
          message
        }
      }
    }

Variables:
{
  "name": "Storage",
  "attributeIDs": [
    "Q29sbGVjdGlvbjo1NA==",
    "Q29sbGVjdGlvbjo1NQ==",
    "Q29sbGVjdGlvbjo1Ng==",
  ]
}

Instead I got:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/graphql/execution/executor.py", line 450, in resolve_or_error
    return executor.execute(resolve_fn, source, info, **args)
  File "/usr/local/lib/python3.7/site-packages/graphql/execution/executors/sync.py", line 16, in execute
    return fn(*args, **kwargs)
  File "./saleor/graphql/core/mutations.py", line 279, in mutate
    response = cls.perform_mutation(root, info, **data)
  File "./saleor/graphql/core/mutations.py", line 452, in perform_mutation
    cls._save_m2m(info, instance, cleaned_input)
  File "./saleor/graphql/product/mutations/products.py", line 1283, in _save_m2m
    instance.product_attributes.set(cleaned_data["product_attributes"])
  File "/usr/local/lib/python3.7/site-packages/django/db/models/fields/related_descriptors.py", line 975, in set
    objs = tuple(objs)
TypeError: 'NoneType' object is not iterable

couldn't reproduce
got proper error:
      "errors": [
        {
          "field": "productAttributes",
          "message": "Could not resolve to a node with the global id list of '['Q29sbGVjdGlvbjo1NA==', 'Q29sbGVjdGlvbjo1NQ==', 'Q29sbGVjdGlvbjo1Ng==']'."
        }
      ]


Docker image on Singularity

Context
We are now able (see #47, #49) to create a docker image and run it in a container on our workstations.
However, we also need to be able to run the image on BB5, where instead of docker we have singularity[^1].
Actions
The following are the instructions to follow (in case of issues, please contact @GianlucaFicarelli).

(Apparently not needed any more) ~Ask Core Services to add you and the other interested users to the list of allowed users for singularity.~
Clone this repo on GitLab (under https://bbpgitlab.epfl.ch/ml). There are two ways to achieve this.

(Easy way) Clone the GitHub repo locally, then push it to a brand new repo on Gitlab (or create a fork from our GitHub in GitLab). Easy and quick, but at some point the GitHub and GitLab repos will diverge.
(Hard way) Create a GitLab mirror of our GitHub repo. May be a bit harder, but will not diverge from GitHub.

Go to the GitLab repo, on the sidebar select "Packages & Registries" > "Container Registry".

Follow the instructions on the GitLab page of "Container Registry" to docker push a locally built Docker image (it will be something like docker push bbpgitlab.epfl.ch:5050/ml/Deep-Atlas).
Connect via ssh to BB5, allocate a node with salloc, and load the module for singularity:module load unstable singularityce

Run the singularity image in a container[^2][^3]singularity pull --docker-login --no-https docker://bbpgitlab.epfl.ch:5050/<group>/<project>:<tag>
singularity exec --cleanenv --containall --bind $TMPDIR:/tmp,/gpfs/bbp.cscs.ch/project <image>.sif bash

Try to run the pipeline and check that everything works fine.

[^1]: Recently singularity became part of apptainer, but the fork for singularity is still maintained as separate from the apptainer fork. Documentation and interfaces for the two forks are mostly interchangeable. Anyway, at BBP we apparently prefer to stick with the singularity fork.
[^2]: By default, singularity  passes all environment variables to the environment within your container. To avoid this, we use --cleanenv.
[^3]: The --containall option allows you to run the software in the container with only minimal access to the host operating system. One of the filesystems which are no longer mounted within the container is /tmp, but we can still bind it by adding --bind $TMPDIR:/tmp.

The Deep-Atlas repo is now cloned on GitLab as a mirror from the GitHub repo. The token has a validity of 90 days and will need to be renewed.

For Deep-Atlas developers:
2.1) The Deep-Atlas docker container can be found at "Packages & Registries" > "Container Registry"
2.2) To update the docker image, run the following commands (on the local machine):
2.3) docker login bbpgitlab.epfl.ch:5050
2.4) docker build -f docker/Dockerfile -t bbpgitlab.epfl.ch:5050/ml/deep-atlas .
2.5) docker push bbpgitlab.epfl.ch:5050/ml/deep-atlas

For Deep-Atlas users (on BB5):
3.1) singularity pull --docker-login --no-https docker://bbpgitlab.epfl.ch:5050/ml/deep-atlas:latest
3.2) singularity exec --cleanenv --containall --bind $TMPDIR:/tmp,/gpfs/bbp.cscs.ch/project,$HOME:/home deep-atlas_latest.sif bash
3.3) there is no write access inside the singularity container, so results have to be written, for instance, to the /home directory

Hi @EmilieDel @drsantos89 ,
Before closing this issue I would suggest the following steps.

[ ] Update Dockerfile by replacing MY_USER_ID with DEAL_USER_IDS, and let people know (add info relative to it in README.md) that this is a comma-separate list of <username>/<userid> such as "$(whoami)/$(id -u)".
[ ] In the Dockerfile, we can have a line testing for the variable to be define and print a warning like so:

RUN test -n "$DEAL_USER_IDS" || echo "WARNING: variable DEAL_USER_IDS was not set, creating only default user 'guest/1000' !"

[ ] Update README.md with info on how to use Singularity as a user on BB5 (i.e. more or less the content of point 3. in this comment) in a sub-section of the "Docker" section.
[ ] Make sure that we have write access to mounted volumes, namely the home and projXX folders on gpfs.
[ ] Try salloc a node with GPU (I think it should be -C volta but double check that on Confluence). Can we then run with the GPU in the Singularity container? Are the nvidia libraries all correctly set up?

I confirm that we can write on /gpfs/ in Singularity container.

GPU working with --nv flag on singularity
tested with:
salloc -N 1 -A proj101 -p interactive -C volta -t 1:00:00 --ntasks-per-node 36
singularity exec --cleanenv --nv --containall --bind $TMPDIR:/tmp,/gpfs/bbp.cscs.ch/project,$HOME:/home deep-atlas_latest.sif bash
(docker base image was also updated from cuda 10.2 to 11.4, to match bb5)

(docker base image was also updated from cuda 10.2 to 11.4, to match bb5)

Also tried with cuda 10.2, and even if doesn't match the CUDA version of the underlying system it seems to work perfectly fine.


Add a base .gitignore file

Setup a gitignore to help avoid certain files getting into the repo

*.swp (vim swap files)
Gemfile.lock (the lock file created by bundler when using Gemfile)
pkg (the result director and everything below it used for puppet
module build)
.ruby-{version,gemset} (rvm environment files for local gemset & ruby
that are in use)

Signed-off-by: Andrew Grimberg<EMAIL_ADDRESS>

LGTM.  Someone still with access feel free to merge.  Otherwise, help me transfer the repo and forge account to me.


language/perl: add rewrite_perl_shebang

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew tests with your changes locally?

Example usage:
require "language/perl"

class A < Formula
  include Language::Perl

  # ...

  uses_from_macos "perl"

  def install
    # ...

    rewrite_perl_shebang

    # ...
  end
end

In the above example all matching shebangs will be replaced with /usr/bin/perl on macOS and Formula["perl"].opt_bin/"perl" on Linux. If depends_on "perl" is used, then Formula["perl"].opt_bin/"perl" will be used on both platforms.

rewrite_perl_shebang

I think I'd like to have some DSL (either by naming or ideally by arguments) that feels like less of a "black box". One of the main features of the Formula DSL is that someone reading through it should understand what's necessary to e.g. run instructions on their machine to build the software. This criticism could be applied to the Python version too, I appreciate, so it might not be a bad idea to adjust that accordingly too. CC @iMichka for thoughts.

That makes sense. Equally, exposing even as much as rewrite_python_shebang does will mean conditional Mac & Linux checks, which would be ideal to avoid.
Do you have any suggestions of what it should look like from a formula file view? I could see Pathname.pwd.find stuff being lifted out of the DSL and into the formula file.

How about something like:
buildpath.find { |f| rewrite_shebang(detected_perl_shebang, f) }
# or for a single file
rewrite_shebang(detected_perl_shebang, "somefile.pl")

and have detected_perl_shebang be a function that generates the perl shebang we want rewritten (and we could do the same thing for detected_python_shebang or something).
I'm not crazy on the names I'm suggesting above but just thinking how to make it as granular and self-explanatory as possible?

Make sense to me.

The regex & max length will need to incorporated somewhere for a generic rewrite_shebang - I'll have a think of the best way to do that.

detected_perl_shebang could return a Hash or even some object that would mean if you used it directly in the formula (without rewrite_shebang) you might need to do detected_perl_shebang.regex, detected_perl_shebang.max_length, detected_perl_shebang.string`, etc.?

Yeah, a Hash seems sensible.

I've made some tweaks just now.

@Bo98 Love it! Could I see an example formula usage (or, ideally, usage of both forms you suggested). After that would be good to add some basic tests and (if you can be bothered and I'll do it in another PR if you can't): refactor Python stuff to use this (while keeping existing naming).

I tested this change on pulledpork (this is from a homebrew-core perspective - so no Linux checks were here):
diff --git a/Formula/pulledpork.rb b/Formula/pulledpork.rb
index f70634d07e..04953b9db0 100644
--- a/Formula/pulledpork.rb
+++ b/Formula/pulledpork.rb
@@ -1,4 +1,8 @@
+require "language/perl"
+
 class Pulledpork < Formula
+  include Language::Perl
+
   desc "Snort rule management"
   homepage "https://github.com/shirkdog/pulledpork"
   url "https://github.com/shirkdog/pulledpork/archive/v0.7.3.tar.gz"
@@ -33,7 +37,7 @@ class Pulledpork < Formula
       end
     end

-    inreplace "pulledpork.pl", "#!/usr/bin/env perl", "#!/usr/bin/perl"
+    rewrite_shebang(detected_perl_shebang, "pulledpork.pl")

     chmod 0755, "pulledpork.pl"
     bin.install "pulledpork.pl"

I've also just tried percona-toolkit:
diff --git a/Formula/percona-toolkit.rb b/Formula/percona-toolkit.rb
index 714e13d454..116c8bb6d9 100644
--- a/Formula/percona-toolkit.rb
+++ b/Formula/percona-toolkit.rb
@@ -1,4 +1,8 @@
+require "language/perl"
+
 class PerconaToolkit < Formula
+  include Language::Perl
+
   desc "Percona Toolkit for MySQL"
   homepage "https://www.percona.com/software/percona-toolkit/"
   url "https://www.percona.com/downloads/percona-toolkit/3.1.0/source/tarball/percona-toolkit-3.1.0.tar.gz"
@@ -53,12 +57,7 @@ class PerconaToolkit < Formula
     # Disable dynamic selection of perl which may cause segfault when an
     # incompatible perl is picked up.
     # https://github.com/Homebrew/homebrew-core/issues/4936
-    bin.find do |f|
-      next unless f.file?
-      next unless f.read("#!/usr/bin/env perl".length) == "#!/usr/bin/env perl"
-
-      inreplace f, "#!/usr/bin/env perl", "#!/usr/bin/perl"
-    end
+    bin.find { |f| rewrite_shebang(detected_perl_shebang, f) }

     bin.env_script_all_files(libexec/"bin", :PERL5LIB => ENV["PERL5LIB"])
   end

I should probably try fix brew tests erroring on my machine before I touch it too much. I'll have a quick look at Python.

I tested this change on pulledpork (this is from a homebrew-core perspective - so no Linux checks were here):

That looks perfect. Great work.

I should probably try fix brew tests erroring on my machine before I touch it too much.

Shout if I can help with that. brew tests --only may be a useful workaround.

I'll give --only a shot.
In terms of the rest, have you come across this error? If not, I'll look into it myself at some point.

Test output
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:661: [BUG] Segmentation fault at 0x0000000000000018
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin13]

-- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:
     * ~/Library/Logs/DiagnosticReports
     * /Library/Logs/DiagnosticReports
   for more details.
Don't forget to include the above Crash Report log file in bug reports.

-- Control frame information -----------------------------------------------
c:0012 p:0008 s:0056 e:000053 BLOCK  /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:661 [FINISH]
c:0011 p:---- s:0049 e:000048 IFUNC
c:0010 p:---- s:0046 e:000045 CFUNC  :each
c:0009 p:---- s:0043 e:000042 CFUNC  :each_with_index
c:0008 p:0006 s:0039 e:000038 METHOD /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:660
c:0007 p:0024 s:0034 e:000033 METHOD /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/specification.rb:1555
c:0006 p:0047 s:0028 e:000027 METHOD /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/specification.rb:1421
c:0005 p:0006 s:0023 e:000022 BLOCK  /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_gem.rb:68 [FINISH]
c:0004 p:---- s:0020 e:000019 CFUNC  :synchronize
c:0003 p:0223 s:0016 e:000015 METHOD /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_gem.rb:67
c:0002 p:0027 s:0006 e:000005 TOP    <internal:gem_prelude>:4 [FINISH]
c:0001 p:0000 s:0003 E:001520 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
<internal:gem_prelude>:4:in `<internal:gem_prelude>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_gem.rb:67:in `synchronize'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_gem.rb:68:in `block in gem'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/specification.rb:1421:in `activate'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/specification.rb:1555:in `add_self_to_load_path'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:660:in `load_path_insert_index'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:660:in `each_with_index'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:660:in `each'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb:661:in `block in load_path_insert_index'

-- Machine register context ------------------------------------------------
 rax: 0x000000000000008e rbx: 0x0000000109460d60 rcx: 0xfffffffffffffffe
 rdx: 0x0000000000000000 rdi: 0x00007ff23f826a00 rsi: 0x00007ff23f826250
 rbp: 0x00007ffee71f2410 rsp: 0x00007ffee71f2410  r8: 0x00007ff23dc00e28
  r9: 0x00007ff23f04dc68 r10: 0x0000000109460d60 r11: 0x00007ff23f827ac0
 r12: 0x00007ff23f827ac0 r13: 0x00007fffb5ffd070 r14: 0x00007ff23f826250
 r15: 0x00007ff23f826a00 rip: 0x0000000108c65054 rfl: 0x0000000000010246

-- C level backtrace information -------------------------------------------
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(rb_vm_bugreport+0x82) [0x108c6ac59]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108b33232) [0x108b33232]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108bfe9f4) [0x108bfe9f4]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff7fa70b5d]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c65054) [0x108c65054]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c4eb89) [0x108c4eb89]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c5cb8e) [0x108c5cb8e]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c587f0) [0x108c587f0]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108b2a34e) [0x108b2a34e]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c5fd32) [0x108c5fd32]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c617f5) [0x108c617f5]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c58558) [0x108c58558]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108adc518) [0x108adc518]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c565b0) [0x108c565b0]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c58c89) [0x108c58c89]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c58b36) [0x108c58b36]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c58b99) [0x108c58b99]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108b2729e) [0x108b2729e]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c66d8f) [0x108c66d8f]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c6625f) [0x108c6625f]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c4bb6b) [0x108c4bb6b]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c4eace) [0x108c4eace]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c5cb8e) [0x108c5cb8e]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c585c7) [0x108c585c7]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108b3b367) [0x108b3b367]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c66d8f) [0x108c66d8f]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c6625f) [0x108c6625f]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c4bb6b) [0x108c4bb6b]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c4eace) [0x108c4eace]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c5cb8e) [0x108c5cb8e]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108c72f94) [0x108c72f94]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108bfa2cc) [0x108bfa2cc]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108b3a2c0) [0x108b3a2c0]
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby(0x108a09747) [0x108a09747]

-- Other runtime information -----------------------------------------------

* Loaded script: /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby

* Loaded features:

    0 enumerator.so
    1 thread.rb
    2 rational.so
    3 complex.so
    4 encdb.so
    5 trans/transdb.so
    6 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/x86_64-darwin13/rbconfig.rb
    7 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/compatibility.rb
    8 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/defaults.rb
    9 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/deprecate.rb
   10 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/errors.rb
   11 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/version.rb
   12 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/requirement.rb
   13 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/platform.rb
   14 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/basic_specification.rb
   15 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/stub_specification.rb
   16 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/delegate.rb
   17 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/rfc2396_parser.rb
   18 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/rfc3986_parser.rb
   19 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/common.rb
   20 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/generic.rb
   21 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/file.rb
   22 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/ftp.rb
   23 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/http.rb
   24 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/https.rb
   25 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/ldap.rb
   26 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/ldaps.rb
   27 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri/mailto.rb
   28 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/uri.rb
   29 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/specification_policy.rb
   30 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/util/list.rb
   31 stringio.so
   32 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/specification.rb
   33 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/exceptions.rb
   34 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/util.rb
   35 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/bundler_version_finder.rb
   36 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/dependency.rb
   37 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_gem.rb
   38 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/monitor.rb
   39 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb
   40 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_warn.rb
   41 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems.rb
   42 /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/lib/ruby/2.6.0/rubygems/path_support.rb

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: https://www.ruby-lang.org/bugreport.html

[IMPORTANT]
Don't forget to include the Crash Report log file under
DiagnosticReports directory in bug reports.

Error: testball: failed

Made changes to Python so that both of these work:
<EMAIL_ADDRESS>
buildpath.find { |f| rewrite_shebang(Language::Python.detected_python_shebang(self), f) }

Unlike other language modules, Language::Python is not designed to be a mixin (Language::Python::Virtualenv is).
Maybe Language::Perl shouldn't either and the shebang stuff should be in a submodule of Language::Perl. Language::Perl::Shebang?

In terms of the rest, have you come across this error?

Yeh, that's a crappy one where integration tests crash 😭. What's your brew config out of interest? I think I'll sort that out once and for all.

This looks really great to me, nice work. I might suggest that Language::Python.rewrite_python_shebang get moved under compat/ so that we can deprecate it and replace its usage in formulae with your new version.

HOMEBREW_VERSION: 2.2.11-8-g3955e7e
ORIGIN: https://github.com/Homebrew/brew
HEAD: 3955e7e13b980ad4f8d38ffc3c0253d86204902e
Last commit: 11 minutes ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 706b7f8533f5e5dba8b919019d9dcd5e6fd4a471
Core tap last commit: 4 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_BINTRAY_KEY: set
HOMEBREW_BINTRAY_USER: bo98
HOMEBREW_DEV_CMD_RUN: 1
CPU: octa-core 64-bit kabylake
Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby
Clang: 11.0 build 1100
Git: 2.21.1 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 11.0.6, 11.0.2, 1.8.0_242
macOS: 10.14.6-x86_64
CLT: <IP_ADDRESS>.1.1571444319
Xcode: 11.3.1
XQuartz: 2.7.11 => /opt/X11

You've probably noticed, but I've gone ahead and made Language::Python::Shebang (and similarly for Perl) so the Python example looks much better now:
buildpath.find { |f| rewrite_shebang(detected_python_shebang, f) }

(with include Language::Python::Shebang earlier)


Roll Flutter Engine from 24ccd8fffbcb to 5184062f7543 (2 revisions)

https://github.com/flutter/engine/compare/24ccd8fffbcb...5184062f7543
2023-07-29<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from vTivaP4a62tRMYue1... to VIjw2bdybUo-rgC0t... (flutter/engine#44137)
2023-07-29<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from 1KABCKdr8VToJTlt-... to -5L2wI7BjRNgnccfl... (flutter/engine#44136)
Also rolling transitive DEPS:
fuchsia/sdk/core/linux-amd64 from 1KABCKdr8VTo to -5L2wI7BjRNg
fuchsia/sdk/core/mac-amd64 from vTivaP4a62tR to VIjw2bdybUo-
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jonahwilliams@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


[11.x] Remove redundant returns from void methods

Removed unnecessary return statements from methods with void return type.

It's OK.


Add section to examples docs with external examples

There are a bunch of great external examples (not included in the Rerun repo) that are currently hard for users to find. We should add them all to the examples page.
This requires:

Taking new screenshots
Which in turn requires recording new rrd files for all the examples

Would be nice if:

We could update these to use the new object oriented api's that are coming in 0.9

External examples:

https://github.com/rerun-io/tapnet
https://github.com/rerun-io/point-shap-e
https://github.com/rerun-io/limap
https://github.com/rerun-io/simplerecon
https://github.com/rerun-io/MCC
https://github.com/rerun-io/slahmr
https://github.com/rerun-io/grounding-sam

Closed by #3020


Error when initiating with singlepage-viewer option

Hi, thank you for this compact and awesome flipbook.
I am running into some trouble when setting up a viewer in singlepage mode. The error message reads: Uncaught TypeError: o is undefined [dist/flipbook-viewer.js:1:16674], which would translate to this line in the source code which means pdf is not defined. Could webpack produce some variable scope issues? I would answer this question myself, if I knew anything about webpack.
Does anybody else run into similar problems with the dist code?
Thanks for any help!

Hi @sebi-alt! I'm sorry I seemed to have missed your message. It may be easier to test by simply downloading the source code from GitHub and running the development/test version (npm run test). That should help see what's happening.


Histogram reuse bug in query evaluation

What did you do?
I have noticed a bug in histogram memory reuse when (chunkenc.Iterator).AtFloatHistogram returns multiple histograms with the same address and does not use the newly added destination histogram functionality.
Exemplary way to reproduce the bug:

The Iterator returns two consecutive histograms that point to the same address X.
The histograms slice now looks like this: [X, Y (.....)], () denotes part of the slice where len <= i < cap.
The iterator returns another histogram with the address Y where Y != X.
The first slot in histograms slice which is pointing to X gets pivoted to the unused back of the slice in:
https://github.com/prometheus/prometheus/blob/312e3fd728d522028285000a63157cadf0666f65/promql/engine.go#L2134-L2138
Now the histograms slice is [X, Y (X, .....)].
On arrival of another histogram, slice length is increased and the new histogram is copied to the address X, mutating histograms at i=0 and i=2:
https://github.com/prometheus/prometheus/blob/312e3fd728d522028285000a63157cadf0666f65/promql/engine.go#L2169-L2175

Demo unit test reproducing the bug: https://github.com/faustuzas/prometheus/pull/1
Debug logs from the test above printing the inputs to the rate function inside the PromQL engine:
Input into function:
 => [2024-05-09 12:00:00 +0300 EEST] 300000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:00:00 +0300 EEST] 300000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:00:00 +0300 EEST] 300000.00 (0x14000130240)
 => [2024-05-09 12:02:00 +0300 EEST] 300000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:00:00 +0300 EEST] 300000.00 (0x14000130240)
 => [2024-05-09 12:02:00 +0300 EEST] 300000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:00:00 +0300 EEST] 300000.00 (0x14000130240)
 => [2024-05-09 12:02:00 +0300 EEST] 300000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:00:00 +0300 EEST] 300000.00 (0x14000130240)
 => [2024-05-09 12:02:00 +0300 EEST] 300000.00 (0x14000130240)
 => [2024-05-09 12:05:00 +0300 EEST] 600000.00 (0x140001302d0)
Input into function:
 => [2024-05-09 12:02:00 +0300 EEST] 750000.00 (0x14000130240) <-- bug happens and rate function detects a reset
 => [2024-05-09 12:05:00 +0300 EEST] 600000.00 (0x140001302d0)
 => [2024-05-09 12:05:30 +0300 EEST] 750000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:02:00 +0300 EEST] 750000.00 (0x14000130240)
 => [2024-05-09 12:05:00 +0300 EEST] 600000.00 (0x140001302d0)
 => [2024-05-09 12:05:30 +0300 EEST] 750000.00 (0x14000130240)
Input into function:
 => [2024-05-09 12:05:00 +0300 EEST] 600000.00 (0x140001302d0)
 => [2024-05-09 12:05:30 +0300 EEST] 750000.00 (0x14000130240)

The problem is absent when line https://github.com/prometheus/prometheus/blob/312e3fd728d522028285000a63157cadf0666f65/promql/engine.go#L2218 is changed to:
t, fh := it.AtFloatHistogram(histograms[n].H)
histograms[n].T, histograms[n].H = t, fh.Copy()

However, this defeats the whole purpose of having a destination histogram in the iterator.
What did you expect to see?
No response
What did you see instead? Under which circumstances?

System information
No response
Prometheus version
main branch
Prometheus configuration file
No response
Alertmanager version
No response
Alertmanager configuration file
No response
Logs
No response

Hey @fpetkovski @krajorama, I've seen you working on optimisations around histograms in PromQL engine recently. Perhaps you could take a look at this bug?
I've tried to come up with a fix, however, promql engine code is very complex and this bug requires deep knowledge about reusing histograms in the iterators to fix it properly.

I will take a look!

@faustuzas I took at look at the bug and I don't think that the iterator stub used in tests is implemented correctly. I've made a suggestion for the correct implementation: https://github.com/faustuzas/prometheus/pull/1/files#r1597967140.
I am curious how you discovered the bug. Did you see it inside Prometheus or are you using the engine or some other Prometheus package in a different project?

Hey, @fpetkovski, thank you for taking a look. Yes, this bug was discovered outside the Prometheus.
Your suggested change to the stub iterator makes sense, the semantics of the engine have changed a little with the addition of histogram re-use and the reduction of allocations.
I will close the issue, thanks for the help again!


divided by 255.

in the below code, why did you divide image by 255 ONLY in 'Predict' function?
and why not in 'Training' function?
Don't we need to divide them in both cases?
    def preprocess(self, image):
        input_image = cv2.resize(image, (self.input_size, self.input_size))
        input_image = **input_image / 255.**

thank you!

Dividing by 255. is the preprocessing step of YOLO. During training, it's performed in the BatchGenerator class. Please refer to line 197 of file preprocessing.py. Perhaps, I should be more consistent in the use of the normalize function.

Aha! it's clear!!  thank you.


linux-qcom-uki: KERNEL_IMAGETYPES should be fully populated before use

In response to https://github.com/quic-yocto/meta-qcom-hwe/pull/42.
KERNEL_IMAGETYPES is not enough to be checked, since kernel types can also be set using KERNEL_IMAGETYPE or KERNEL_ALT_IMAGETYPE. Like it's done in OE-core kernel class, we need to combine all these variables.

@rsalveti @adhudase @quic-vkraleti . FWIW. It's untested, but that should be close to what we want for https://github.com/quic-yocto/meta-qcom-hwe/pull/42

@rsalveti @adhudase @quic-vkraleti . FWIW. It's untested, but that should be close to what we want for quic-yocto/meta-qcom-hwe#42

This should work, but wonder if worthy maintaining this piece just to set SKIP_RECIPE, while the actual runtime check already exists and produces a fatal error.
We should also probably move to https://lists.openembedded.org/g/openembedded-core/message/205686 once merged (hopefully soon once the autobuilder issues are sorted out), but it will require changes as this layer is using Image.gz as the default target.

Yes, we should backport the upstream uki class when it's merged, but it might take some time. I just tried to provide an alternate to the PR submitted on meta-qcom-hwe (which is wrong). so we can live with this change here until we remove this recipe.

@ndechesne @ricardosalveti For your information, we were using uki.bbclass and then we had to stop using it, see https://github.com/Linaro/meta-qcom/pull/562 . Basically, we wanted to have the UKI image to be availabel as a package, not only as a file inside ${DEPLOY_DIR}
I hope that @quic-vkraleti and other Qualcomm engineers are participating in the discussions on the ML regarding the UKI bbclass and provide additional information on Qualcomm requirements.

hmm. thanks for pointing this out. I will review #562.. However we really need a very strong reason for not using the 'default' mechanism. Or we should indeed participate in the upstream discussions..

Yes, we should backport the upstream uki class when it's merged, but it might take some time. I just tried to provide an alternate to the PR submitted on meta-qcom-hwe (which is wrong). so we can live with this change here until we remove this recipe.

No need to backport at this stage since we're only using main/master for now, but I'm ok with your change now to solve the issue we have.


chore: update references to zz_filesystem_generated.go

Some places were missed in the repo restructuring. This should fix test_infra build failures.
See: https://prow.knative.dev/?job=nightly_func_main_periodic
/kind chore

/override codecov/project

/approve
/lgtm


Pds3

This pull request adds a single file with some PDS3 label management methods and should not affect anything else.

There are four other files added that start with "~". I assume these are backup files that you didn't mean to check in.

removed backup files


Testing capabilities?

Hey @tucnak, thanks for creating this wonderful tool.
I'm using telebot for a project and I had questions about testing my code. Are there good ways to mock SendMessage and equivalent methods?

Hi
I'm not sure if it is the best way to do it but I'm doing this on my test
code
func processing(db db.ZbotDatabase, msg telebot.Message) string {
}

test
botMsg := telebot.Message{Text: "text"}
result := processing(dbMock, botMsg)

Just create interface that will implements methods you using.
And test it.

@m1ome cheers. Closing this for now.


add more related

btw, awful installation time of verb (verb-cli) 5min+ on 100mb net.

thanks!

doh... seems something went wrong in defaults?

ha, yeah that's exactly why I created this library. the current libs that I use for parsing/stringifying github urls return weird results.

btw, awful installation time of verb

must have been npm or something. It installs in a couple seconds for me.

I'll merge this today, I can fix the link too no worries. fwiw I'm going to be pushing up a refactor of verb this week too. it's a lot faster

must have been npm or something. It installs in a couple seconds for me.

Hmm yea, maybe, all installations are slow today. hmm, lol

fwiw I'm going to be pushing up a refactor of verb this week too. it's a lot faster

Great. btw, i'm interested in your verb configuration/boilerplate, could you share it?

i'm interested in your verb configuration/boilerplate, could you share it? Just want to review it

yeah no prob, I just use the one that is generated by generator-verb. I'd really like to refactor that generator, it was one of the first generators I did when I knew nothing about the yeoman API. plus the yeoman API has changed a lot since then


DROP3 validation against Weka

DROP3 has been checked for correctly implementation, comparing the results against Weka. Therefore, this issue will be closed.


fix: error datetime in exceptionless-client 0.1.0 #68

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.zxz seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@zen-arch Thanks for the pr! could you please sign the cla.

I will have a look as soon as possible. Thanks for the PR


Fix indentation in AWS section of acceptance-testing docs

Really minor doc fix, one of the yaml lines had too many spaces so sorted that out. Tested running make html

Thanks.  Ideally, we'd have automated test coverage to check the examples in the documentation for validity.  The values for some parts of the example, like the secret API key, would be tricky to validate.  It would be straightforward to validate the structure, though (ie, do the keys present match up with the allowed and required arguments to the Python code that consumes this stuff).
Some of our documentation has some automatic test coverage - by virtue of being derived from actual code that is executed by our test suite.  That kind of coverage probably doesn't apply in this case since the example is intentionally unusable (at least by not using a real AWS API key).
It's tempting to wonder whether some kind of doctest could help with this case.  Off hand, though, I don't quite know if you can write a doctest for a yaml blob without inserting user-facing contortions into the documentation - so perhaps that's not suitable.
I could imagine a sort of unit test that loads this particular file, pulls out the various examples, and throws them at the Python consumers to make sure they're happy.  I could also imagine codifying the exact required structure with something like jsonschema and then validating using that instead.  For this structure I think we're quite happy to make incompatible changes from release to release.  That suggests to me that a jsonschema-style testing approach may get in the way more than it helps.  Just throwing the structure at the relevant Python code would ensure we don't make simple mistakes like this one and that when we make changes to the implementation we get a reminder to fix the documentation instead.
Finally, I could also imagine generating this example from the implementation so that there isn't this duplication of content to maintain at all.  We already do some custom Sphinx generation (flocker/docs/) so this might not be particularly far out of reach.
This all implies more work than the simple (apparently correct, fwiw!) change in this PR.  Considering the number of bugs we've had in these examples, I think it's probably actually worth it.  However, automated test coverage for the documentation is not a baseline requirement for Flocker documentation development so I won't say that introducing such test coverage is required to land this fix.  I will suggest that if you feel like spending some time on it, it would probably be useful. :)
Regardless of that, it looks like the problem was introduced as a result of @davidoliverSP2 's editor configuration - which allowed him to insert a hard tab into the documentation.  It's probably worth drawing his attention to that (which perhaps I am succeeding in doing here) so he can fix that mis-configuration and avoid repeating this particularly problem again.
Go ahead and merge if you don't build some kind of wider-scoped fix like one of the things discussed here.  Otherwise, please re-submit for review with those improvements.

Ah, last thing.  It may also be worth auditing the changeset which introduced this bug to see if any other instances of it were introduced.

Certainly agree with the sentiment and had thought about how to address it,
but it seems like it might be involved enough to deserve a task or story of
its own. As you mentioned the main issue is how to extract the examples and
validate them correctly. The main thing that sprang to my mind was how to
tell the difference between e.g. yaml code sections and shell code sections.
In summary I think this should land (modulo the audit of the changeset that
introduced it) and I will make a point of creating a story for
documentation validation.
On 27 January 2016 at 00:23, Jean-Paul Calderone<EMAIL_ADDRESS>wrote:

Ah, last thing. It may also be worth auditing the changeset which
introduced this bug to see if any other instances of it were introduced.
—
Reply to this email directly or view it on GitHub
https://github.com/ClusterHQ/flocker/pull/2523#issuecomment-175310251.

Actually I can see now that the sections are marked up with e.g. code-block: yaml or prompt: bash, so we can take advantage of that. At least for YAML it should be very easy to extract the yaml and just parse it to check it's valid.

Re: the audit, the docs folder seems to have quite a lot of hard tabs. Should we be having a blanket ban across the repository?


DBZ-137 contribution to the core, Oracle related

Hey @Naros, how is it going with this one?

I have rebased this work and this PR is now superseded by #1709.  As a result, I'm going to close this PR.


AnimationController.repeat duration should be documented

Looking at the documentation there is nothing documented about what duration does.
https://api.flutter.dev/flutter/animation/AnimationController/repeat.html
This makes it harder to use and developers have to guess, google elsewhere or look at the source code for AnimationController.repeat directly.

@VladyslavBondarenko  I would like to get assigned to this issue.

@VisheshAtWork
you can open a PR and mention the issue there