Crash when using 4 tiles for 1080p 4:2:2 input (but not with 8 tiles)

Description:
When encoding 1080p 4:2:2 video (even a single black frame) with 4 tiles, rav1e crashes.  With 8 tiles, the encoding finishes normally.
Command line:
rav1e -o /dev/null --tiles 4 black-frame.y4m
Result with debug build and RUSTBACKTRACE=full:
rav1e-422-crash.txt
Backtrace (most recent call first):
  File "<unknown>", line 0, in core::panicking::panic
  File "/var/home/gideon/rav1e/src/lrf.rs", line 1416, in rav1e::lrf::RestorationState::new
    uv_unit_log2 - uv_sb_v_log2,
  File "/var/home/gideon/rav1e/src/encoder.rs", line 384, in rav1e::encoder::FrameState<T>::new_with_frame
    let rs = RestorationState::new(fi, &frame);
  File "/var/home/gideon/rav1e/src/api/internal.rs", line 215, in rav1e::api::internal::FrameData<T>::new
    let fs = FrameState::new_with_frame(&fi, frame);
  File "/var/home/gideon/rav1e/src/api/internal.rs", line 426, in rav1e::api::internal::ContextInner<T>::set_frame_properties
    self.frame_data.insert(output_frameno, FrameData::new(fi, frame.clone()));
  File "/var/home/gideon/rav1e/src/api/internal.rs", line 744, in rav1e::api::internal::ContextInner<T>::compute_frame_invariants
    while self.set_frame_properties(self.next_lookahead_output_frameno).is_ok()
  File "/var/home/gideon/rav1e/src/api/internal.rs", line 348, in rav1e::api::internal::ContextInner<T>::send_frame
    self.compute_frame_invariants();
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/thread_pool/mod.rs", line 110, in rayon_core::thread_pool::ThreadPool::install::{{closure}}
    self.registry.in_worker(|_, _| op())
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 447, in rayon_core::registry::Registry::in_worker_cold::{{closure}}::{{closure}}
    op(&*worker_thread, true)
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs", line 113, in <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::call::{{closure}}
    move || func(true)
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panic.rs", line 318, in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panicking.rs", line 305, in std::panicking::try::do_call
  File "<unknown>", line 0, in __rust_maybe_catch_panic
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panicking.rs", line 281, in std::panicking::try
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panic.rs", line 394, in std::panic::catch_unwind
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/unwind.rs", line 17, in rayon_core::unwind::halt_unwinding
    panic::catch_unwind(AssertUnwindSafe(func))
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs", line 119, in <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
    (*this.result.get()) = match unwind::halt_unwinding(call(func)) {
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 681, in rayon_core::registry::WorkerThread::execute
    job.execute();
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 665, in rayon_core::registry::WorkerThread::wait_until_cold
    self.execute(job);
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 639, in rayon_core::registry::WorkerThread::wait_until
    self.wait_until_cold(latch);
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 759, in rayon_core::registry::main_loop
    worker_thread.wait_until(&registry.terminate_latch);
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 56, in rayon_core::registry::ThreadBuilder::run
    unsafe { main_loop(self.worker, self.registry, self.index) }
  File "/home/gideon/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs", line 101, in <rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{{closure}}
    b.spawn(|| thread.run())?;
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/sys_common/backtrace.rs", line 129, in std::sys_common::backtrace::__rust_begin_short_backtrace
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/thread/mod.rs", line 475, in std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panic.rs", line 318, in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panicking.rs", line 305, in std::panicking::try::do_call
  File "<unknown>", line 0, in __rust_maybe_catch_panic
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panicking.rs", line 281, in std::panicking::try
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/panic.rs", line 394, in std::panic::catch_unwind
  File "/builddir/build/BUILD/rustc-1.42.0-src/src/libstd/thread/mod.rs", line 474, in std::thread::Builder::spawn_unchecked::{{closure}}
  File "<unknown>", line 0, in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  File "<unknown>", line 0, in std::sys::unix::thread::Thread::new::thread_start
  File "<unknown>", line 0, in start_thread
  File "<unknown>", line 0, in clone
  File "<unknown>", line 0, in <unknown>

The application panicked (crashed).
  attempt to subtract with overflow
in /var/home/gideon/rav1e/src/lrf.rs, line 1416
thread: <unnamed>

Reproduced.  Working on it.

Update:  Bug is due to restoration filter being handed a tiling setup it cannot honor.  Tiling is selecting a tile height of 9 SBs, and in 4:2:2 LRU can't do 32x32, so it would be forced to have a non-integer vertical number of LRUs per tile.
Restoration needs to check and flag this case for debugging/abort purposes.  Tiling needs to add a check to enforce even number of vertical SBs per tile in the 4:2:2 case.

aaand that has exposed something else.  Still working on it :0)

Can we disable enough filters on 4:2:2 that it doesn't crash?

Sadly, I don't think so-- the problem is that Tiling is partially
implemented in terms of the restoration filter framework and piggybacks on
some of its infrastructure.  You can 'disable' reconstruction, but that
just means the filter doesn't run.  It's not the filter that's crashing,
it's the overall LRU accounting, which tiling uses.  This is part of the
stack of oopsie that hadn't been getting tested and turns out not to have
worked in a while :-(
On Thu, Apr 16, 2020 at 5:27 PM Thomas Daede<EMAIL_ADDRESS>wrote:

Can we disable enough filters on 4:2:2 that it doesn't crash?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/xiph/rav1e/issues/2212#issuecomment-614905482, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACWMHEEILHLBCZGY7LLAXADRM5Z4HANCNFSM4LWSOCQA
.

Another data point from fuzzing. I think LRF should be disabled because of the height but we crash in RestorationState::new() anyway.
DecodeTestParameters {
    w: 260,
    h: 16,
    chroma_sampling: Cs422,
    tile_cols_log2: 1,
    tile_rows_log2: 1,
}

        DecodeTestParameters {
            w: 260,
            h: 16,
            speed: 10,
            q: 0,
            limit: 1,
            bit_depth: 8,
            chroma_sampling: Cs422,
            min_keyint: 3,
            max_keyint: 3,
            switch_frame_interval: 0,
            low_latency: true,
            error_resilient: true,
            bitrate: 65535,
            tile_cols_log2: 1,
            tile_rows_log2: 1,
            still_picture: false,
        }


Crosswork - Two logos displayed for the same company

ENVIROMENT: production
URL: https://firme.peviitor.ro/
Browser: Chrome
Device: Laptop
OS: Windows 7
STEPS TO REPRODUCE:

Open URL in browser
Type "crosswork" in the search bar

EXPECTED RESULTS:
The logo company must be displayed only once.
ACTUAL RESULTS:
There are displayed two companies with the same name.

This bug persists despite a recent examination of the company Crosswork.

This bug persists despite a recent examination of the company Crosswork.


-Prefix "CC"

This parameter is only relevant for the Import-PSSession command.
While in the document it is placed under p.2. So it is probably should be mentioned in the p.3. instead.

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

ID: ebcb7e5d-c0aa-f4f3-e6d5-914219d16dff
Version Independent ID: 36d9a36f-fbdf-e4a1-45d7-51cc1a65643b
Content: Connect to Office 365 Security & Compliance Center PowerShell
Content Source: exchange/docs-conceptual/office-365-scc/connect-to-scc-powershell/connect-to-scc-powershell.md
Service: o365-security-and-compliance
GitHub Login: @chrisda
Microsoft Alias: chrisda

@officedocsbot assign @yogkumgit

@dariomws  Thank you very much for the contribution and updating the documentation with PR. @uz-it Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Game can't be built on Linux

Describe your bug here.
When I try compiling the game on Linux, I get these errors:
Command Prompt/Terminal logs (if existing)
source/PlayState.hx:1552: lines 1552-1585 : Warning : This case is unused
source/PlayState.hx:1667: characters 78-84 : Warning : This pattern is unused
source/PlayState.hx:7956: characters 78-81 : Warning : This pattern is unused
source/SoundTestMenu.hx:61: characters 4-17 : Type not found : DiscordClient

Are you modding a build from source or with Lua?
Source
What is your build target?
Linux
Did you edit anything in this build? If so, mention or summarize your changes.
No.

Describe your bug here.
When I try compiling the game on Linux, I get these errors:
Command Prompt/Terminal logs (if existing)
source/PlayState.hx:1552: lines 1552-1585 : Warning : This case is unused
source/PlayState.hx:1667: characters 78-84 : Warning : This pattern is unused
source/PlayState.hx:7956: characters 78-81 : Warning : This pattern is unused
source/SoundTestMenu.hx:61: characters 4-17 : Type not found : DiscordClient

Are you modding a build from source or with Lua?
Source
What is your build target?
Linux
Did you edit anything in this build? If so, mention or summarize your changes.
No.

use my version https://github.com/MemeHoovy/sonic.exe-2.5-3.0 in the restored branch

this ain't gonna be updated or fixed, I know that for sure

I'm pretty sure this is windows only

You just have to remove line 62, which states
DiscordClient.changePresence('In the Sound Test Menu', null);

You just have to remove line 62, which states DiscordClient.changePresence('In the Sound Test Menu', null);

yeah but that doesn't fix the other problems though

You just have to remove line 62, which states DiscordClient.changePresence('In the Sound Test Menu', null);

yeah but that doesn't fix the other problems though

While you might be right, this does pretty much solve the only actual issue that they're showing (the other 3 are just warnings, i believe)

https://github.com/MemeHoovy/sonic.exe-2.5-3.0/actions/runs/3193398368/jobs/5211909671

imagine being on chromebook

imagine being on chromebook

bruh my friend uses a chromebook


passing array to hv.Text

Currently we can plot a single x,y and text in the chart using hv.Text(x,y,Text)
I want to display all y values in bar chart as string. How to display them? I tried passing array to x,y, and text columns, i get the following error.
Parameter 'x' value must be an instance of (Number, str, datetime64, datetime, date, Timestamp, DatetimeTZDtypeType, Period), not '[-5.         -3.98989899 -2.97979798]'
is there an alternate for this?

Just learned about hv.Labels from here
it solves the problem. Thanks


When an app changes its app icon, it requires clearing Accrescent's storage for that to be reflected in-app

You must have mean Accroissant in your title ;)
For me it updated the icon w/o cleaning storage after some time.

I didn't clean the storage and i saw the new icon.
By the way, as a French person myself, I think this change of name and icon is an excellent move. Let's keep it forever :p

It shouldn't require storage to be cleared to see the new icon. However, you won't see the new icon until the image cache for that specific icon is invalidated (which happens normally after some time). I think this could be improved though by checking for icon updates when performing a manual refresh, so I'll keep this issue open.

Updating to 16.2 worked for me.

16.2

Can I borrow your time machine?

Display names will be updated with a manual refresh or when an automatic update occurs.

This may be unrelated, but maybe the cache should be improved so that icons don't need time to load to show up (especially for installed apps).


ninja: error: WriteFile(...) Unable to create file. File name too long

The last few lines of breakage are:
2024-11-30T07:39:49.0932034Z [26251/30488] CXX obj/extensions/common/mojom/mojom_jumbo_3.o
2024-11-30T07:39:49.0938629Z ninja: error: WriteFile(__third_party_blink_renderer_modules_document_picture_in_picture_document_picture_in_picture__jumbo_merge__github_home_rpmbuild_BUILD_qt6-qtwebengine-6.8.0-build_qtwebengine-everywhere-src-6.8.0_redhat-linux-build_src_core_target_toolchain_target__rule.rsp): Unable to create file. File name too long
2024-11-30T07:39:50.8798008Z ninja: build stopped: .
2024-11-30T07:39:50.8878759Z FAILED: src/core/RelWithDebInfo/x86_64/QtWebEngineCore.stamp src/core/RelWithDebInfo/x86_64/obj/tools/v8_context_snapshot/v8_context_snapshot.stamp src/core/RelWithDebInfo/x86_64/QtWebEngineCore /github/home/rpmbuild/BUILD/qt6-qtwebengine-6.8.0-build/qtwebengine-everywhere-src-6.8.0/redhat-linux-build/src/core/RelWithDebInfo/x86_64/QtWebEngineCore.stamp /github/home/rpmbuild/BUILD/qt6-qtwebengine-6.8.0-build/qtwebengine-everywhere-src-6.8.0/redhat-linux-build/src/core/RelWithDebInfo/x86_64/obj/tools/v8_context_snapshot/v8_context_snapshot.stamp /github/home/rpmbuild/BUILD/qt6-qtwebengine-6.8.0-build/qtwebengine-everywhere-src-6.8.0/redhat-linux-build/src/core/RelWithDebInfo/x86_64/QtWebEngineCore
2024-11-30T07:39:50.8885492Z cd /github/home/rpmbuild/BUILD/qt6-qtwebengine-6.8.0-build/qtwebengine-everywhere-src-6.8.0/redhat-linux-build/src/core && /usr/bin/ninja -j4 -C /github/home/rpmbuild/BUILD/qt6-qtwebengine-6.8.0-build/qtwebengine-everywhere-src-6.8.0/redhat-linux-build/src/core/RelWithDebInfo/x86_64 QtWebEngineCore
2024-11-30T07:39:50.8887262Z ninja: build stopped: subcommand failed.
2024-11-30T07:39:50.8887539Z

The patch here seems possible: https://bugs.gentoo.org/911715

Another https://git.syndicate-lang.org/synit/pmbootstrap/src/commit/93c95ed9cda23e8d785711bf3a9eec230d15d6bd/aports/luna/qt5-qtwebengine/patches-musl/0003-chromium-workaround-for-too-long-.rps-file-name.patch

https://github.com/ubports/qtwebengine-opensource-src-packaging/blob/xenial/debian/patches/0002-Buildfix-path-too-long.patch

https://bugreports.qt.io/browse/QTBUG-59769

https://github.com/conan-io/conan-center-index/blob/master/recipes/qt/5.x.x/patches/c72097e.diff

Fixed in https://github.com/HinTak/Qt6WE-OT-SVG/tree/Qt6WE-OT-SVG-0.21.5


CMake configuration is not well suited for monorepo builds

Does this issue affect the google-cloud-cpp-common project?
Yes
What version of google-cloud-cpp-common are you using?
v0.25.x
What operating system and version are you using?
Kubuntu 20.04
What were you trying to do?
I have a monorepo with all libraries and dependencies, including llvm-project/libcxx and llvm-project/libcxxabi. (If you are interested, I have this structure because I want to be able to build everything with various clang sanitisers).
I add this project (google-cloud-cpp-common) as a directory in my contrib/ folder and include it in CMakeLists.txt in this way: add_subdirectory(google-cloud-cpp-common).
When I try to configure the project, it says this:
CMake Error: install(EXPORT "google_cloud_cpp_common-targets" ...) includes target "google_cloud_cpp_common" which requires target "cxx_static" that is not in the export set.
CMake Error: install(EXPORT "google_cloud_cpp_common-targets" ...) includes target "google_cloud_cpp_common" which requires target "cxxabi_static" that is not in the export set.

Note, cxx_static and cxxabi_static come from llvm.
I think that the root cause is that I do not want to install anything, but google-cloud-cpp-common/google/cloud/CMakeLists.txt tries to and fails...
What did you expect to see?
I am not very good at CMake (so there might be a better/proper solution), but I would probably expect an option to disable any installation at all.

@DimanNe Thanks for contacting us. I hope you've figured out a solution that works for you. Feel free to re-open this issue if you have more questions about this.


Add new schedule approve validation rules

🛠 Changelog

Add new schedule approve validation rules:

These rules can be skipped with the force flag

Allocated duration cannot be less than event.min_duration
Allocated duration cannot be more than event.max_duration
Cannot allocate more events than event.events_per_week
Cannot allocate more than one event per day
Can only allocate on users' wished times

These rules cannot be skipped with the force flag

Cannot allocate to a reservation unit not included in the event's event reservation units
Cannot allocate an already allocated period for the same reservation unit in any overlapping schedule based on events begin and end times, even from other application rounds

Later: Include common resource and space hierarchy in this

🧪 Test plan

Automated tests

🎫 Tickets

TILA-3061

@vergama Would be easy enough to add now to the duration validation:
if duration.total_seconds() % 900 != 0:
    msg = "Allocation duration must be a multiple of 15 minutes."
    errors["allocated_end"].append(msg)


Add basic SSH documentation for CLI

What does this PR do?
This PR adds basic documentation for https://github.com/Lightning-AI/lightning/pull/15310 and https://github.com/Lightning-AI/lightning/pull/15291.
Fixes #<issue_number>
Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you list all the breaking changes introduced by this pull request?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃
cc @borda @rohitgr7 @Felonious-Spellfire

still no CLI reference?

@edenlightning what does this comment refer to exactly?

For visibility, #15521 (and more) is currently happening, need to look out for possible collisions.
Need to wait for doc build issues to be resolved on master, merging is blocked unfortunately.


packwiz: unstable-2022-06-08 -> unstable-2022-08-25

Description of changes
Updates packwiz to the latest commit.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

1 package built:

packwiz

I'm sorry. I made a mistake.
Please fix version name. Also at commit message.

The date issue is a matter of timezones, it was 08-24 EST when the commit was authored in packwiz.

Fixed in both the version number and the commit message

Fixed in both the version number and the commit message

It is missing the dash (-) in unstable-2022-08-25. (git commit message)

Ah, I see now, there we go.

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

1 package built:

packwiz


Write error messages to STDERR

Happy to justify if an explanation is needed on why. 😄

Thanks! Sorry for the long delay.


Add required to NSObject

Close https://github.com/apple/swift/issues/71874

@swift-ci test

This patch aligns the behavior on Darwin's ObjectiveC NSObject implementation but it will be source breaking for the downstream user.
Can we add it as part of Swift 6?


[Feature Request]: Add support for Ollama

Is your feature request related to a problem? Please describe.
I used Autogen dotnet with LMStudio local llm and it is very very slow, Ollama is faster, is it possible to add support to Ollama please?
Describe the solution you'd like
Have OllamaAgent and OllamaAgentConfig to use (similar to LMStudioAgent and LMStudioConfig)
Additional context
No response

@samimejri This issue has already been tracked by https://github.com/microsoft/autogen/issues/2319

yes, go ahead!


Make "easy mode" switchable and configurable

Switchable:

we should be able to switch between easy and hard mode. Maybe just a global setting for now.

Configurable:

It seems like maybe there will be other settings that come bundled with the switch, like a filter from #1463. When I switch to "easy" mode, all those go into effect as well
There may be many configurations eventually: for instance, one for agent editing, another for generated image editing (like ComfyUI), etc. For now, let's figure out how to make one, but keep the notion of many configs in mind.
We also need a way to pass configurations along to others. The ideal experience is that I just share a link with you, and you get my config. But not sure of the final shape.

My $0.02, let's stay clear of "easy" and "hard"... it's not easy and hard, it's a lite editor and a full editor. We might want to simplify the full editor with more progressive reveal.

Is it a "view" on an editor, where this is a preset that is customized for a particular purpose?
Or is it a property of a graph? "Best viewed as". If I am working on two files, one is the "full editor" mode, deep, classic Breadboard. One is the "agent designer" mode. Per URL? Remember last?
Select per board?

#1498 is enabling a lot of these. Just needs a "preset" adding which sets them all at once :)

Declaring victory 🚢 , tracking the "preset" part in #1548


Create terraform_init.sh

a terraform init function to create terraform initation files.

Sorry going to have to reject, as this is a snippets repo, for snippets of code or functions which can be included in other projects.
Your script is fully formed not a snippet, in addition, your code does not pass the required coding standards, eg shellcheck returns a lot of errors and warnings, it should return none. In addition, I would rethink your script as this is not the documented / correct way to manage terraform.

@TGWolf didnt know that it is for the snippet only and not a fully formed function. I didnt took into account the shellcheck as my aim was to write a complete function that works and return me the results and not just a templating snippet. that i wrote to create the instances otherwise all programming goes in HCL language. Thank you for the comment. Gaurav


feat(privatek8s/release.ci): migrate to ZRS volume and extend to 64Gi

as per https://github.com/jenkins-infra/helpdesk/issues/3823#issuecomment-2056385986
migrate to ZRS storage class and extend volume size to 64Go (as it's paid for).

Deployment Procedure:

to ensure successful deployment (immutable fields for PVC) we need to manually delete the statefulset and ensure PVC and PV are deleted prior to the PR merge

statefulset, PVC and PV manually deleted
PVC and PV from snapshot created


update to latest makizushi

Finishes/replaces #32

Coverage decreased (-0.7%) to 80.0% when pulling 2be7b82405d280aeebf2493577c484ba41c4450d on mapnik-version-fix into ab7afc49bce4b13b3e9d8b1de472141fb0ac46c5 on master.


fix: chunk split for dynamic import dep

Description
For a dynamic import module，the application code and the third-party dep code will be seperated.In the meanwhile, each async-vendor will be divided in terms of dynamic import entry, instead of all being packaged into a single file, so huge async vendor can be avoided.
See details in #6289.
Additional context

What is the purpose of this pull request?

[ ] Bug fix
[x] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[ ] Read the Contributing Guidelines.
[ ] Read the Pull Request Guidelines and follow the Commit Convention.
[ ] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[ ] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

will this fix https://github.com/vitejs/vite/issues/6250?

will this fix #6250?

Yes，it is general solution for the scene with dynamic import.

@QiroNT could you test this PR for us?

could you test this PR for us?

I don't particularly like this implementation since it still kinds of combining modules imported from same package, not ideal for stuff like localization files.

Maybe should have an option to either combine modules by dynamic entry, or combine by package name. Could be configured by matching entries like how the optimizeDeps does.

Why do we need to do any special vendor chunking? createMoveToVendorChunkFn has been a long-standing pain point. We've gotten lots of bug reports about it such as https://github.com/sveltejs/kit/issues/1632 and https://github.com/vitejs/vite/issues/3731 and we've even disabled it ourselves on several sites such as svelte.dev.
The feature was originally added in https://github.com/vitejs/vite/commit/f6b58a0f535b1c26f9c1dfda74c28c685402c3c9#diff-aa53520bfd53e6c24220c44494457cc66370fd2bee513c15f9be7eb537a363e7. I can only guess at why it was added as there was no explanation provided at the time. I guess the idea is that the vendor chunk changes less frequently and will be better cached? But it ends up loading lots of code that's unnecessary for a page, adds complication, creates more chunks, and causes issues if libraries are used from multiple places so I find it quite hard to believe it's an overall win. Personally, I'd really love to just remove it, or at least make it optional and off by default.

True, either split the dependency then we get #2672, or don't split the dependency then we get #3731.

could you test this PR for us?

I don't particularly like this implementation since it still kinds of combining modules imported from the same package, not ideal for stuffs like localization files.

Maybe should have an option to either combine modules by dynamic entry, or combine by package name. Could be configured by matching entries like how the optimizeDeps does.
BTW I think that localization files being split into two files is not beneficial, maybe also a option to disable this optimization (include packages in source chunk) for an entry? or just disable for very small files (also could be the default to the config above), but idk if it could fit inside vite's build cycle.

I understand.This solution separates application code and dependent code, improves the cache hit rate, and increases the number of chunks. Maybe you don’t like this way too much, but prefer to split the package size by package name.Such as:
{
  'markdown-it': ['markdown-it'],
  'echarts': ['echarts'],
  'react': ['react', 'react-dom']
}

Then the packages in the value will be packaged together.right?

@QiroNT @benmccann However, currently vite's chunk split is implemented through rollup's manualChunks. If vite is not handled by default but a new chunk split configuration is created, it will conflict with build.rollupOptions.output.manualChunks.

Maybe you don’t like this way too much, but prefer to split the package size by package name.

Actually it's the opposite, look closely at locales from date-fns, they should be packed per locale, which is how I defined in the dynamic import.

True, either split the dependency then we get #2672, or don't split the dependency then we get #3731.

Thought for the past few hours, the whole vendor thing should be rewritten with this issue in mind. Probably doing an analyze to choose whether multiple entries from a dependency should be packaged together or not, I'll hopefully open a discussion about this proposal later, but god that's a lot more to consider than I've ever thought it would be.

combine

the bundle size picture is cool, how to make it?


model.load_adapter Problem

Hello, today after downloading and installing PEFT again, I am getting the following line. But I was not getting such an error before. And my code was working. It's not working now.
I had created the requirement.txt file before. There is this in the peft version created here, maybe it can help.
peft @ git+https://github.com/huggingface/peft.git@64f63a7df2a02cfd144592d9aa9c871b59258c55

Python 3.7.7

transformers.version
'4.21.3'
torch.version
'1.9.1+cu111'

/home/glb90092345/DialoGPT/API/api.py:46 in <module>                                             │
│                                                                                │
│    43 │   #device = "cpu",                                                                       │
│    44 │   info = False                                                                           │
│    45 )                                                                                │
│ ❱  46 test.load()                                                                                │
│    47                                                                                │
│    48 app = FastAPI()                                                                            │
│    49                                                                                │
│                                                                                │
│ /home/glb90092345/DialoGPT/API/model.py:198 in load                                              │
│                                                                                │
│   195 │   │   │   │   )                                                                          │
│   196 │   │   │                                                                                │
│   197 │   │   │   # Load the Lora model                                                          │
│ ❱ 198 │   │   │   self.model = PeftModel.from_pretrained(self.model.to(self.device), self.mode   │
│   199                                                                                │
│   200                                                                                │
│   201                                                                                │
│                                                                                │
│ /usr/local/lib/python3.7/site-packages/peft/peft_model.py:166 in from_pretrained                 │
│                                                                                │
│    163 │   │   │   model = cls(model, config, adapter_name)                                      │
│    164 │   │   else:                                                                             │
│    165 │   │   │   model = MODEL_TYPE_TO_PEFT_MODEL_MAPPING[config.task_type](model, config, ad  │
│ ❱  166 │   │   model.load_adapter(model_id, adapter_name, **kwargs)                              │
│    167 │   │   return model                                                                      │
│    168 │                                                                                │
│    169 │   def _setup_prompt_encoder(self, adapter_name):                                        │
│                                                                                │
│ /usr/local/lib/python3.7/site-packages/peft/peft_model.py:355 in load_adapter                    │
│                                                                                │
│    352 │   │   │   filename, map_location=torch.device("cuda" if torch.cuda.is_available() else  │
│    353 │   │   )                                                                                │
│    354 │   │   # load the weights into the model                                                 │
│ ❱  355 │   │   set_peft_model_state_dict(self, adapters_weights, adapter_name=adapter_name)      │
│    356 │   │   if (                                                                              │
│    357 │   │   │   (getattr(self, "hf_device_map", None) is not None)                            │
│    358 │   │   │   and (len(set(self.hf_device_map.values()).intersection({"cpu", "disk"})) > 0  │
│                                                                                │
│ /usr/local/lib/python3.7/site-packages/peft/utils/save_and_load.py:120 in                        │
│ set_peft_model_state_dict                                                                        │
│                                                                                │
│   117 │   else:                                                                                │
│   118 │   │   raise NotImplementedError                                                          │
│   119 │                                                                                │
│ ❱ 120 │   model.load_state_dict(peft_model_state_dict, strict=False)                             │
│   121 │   if isinstance(config, PromptLearningConfig):                                           │
│   122 │   │   model.prompt_encoder[adapter_name].embedding.load_state_dict(                      │
│   123 │   │   │   {"weight": peft_model_state_dict["prompt_embeddings"]}, strict=True            │
│                                                                                │
│ /usr/local/lib/python3.7/site-packages/torch/nn/modules/module.py:1407 in load_state_dict        │
│                                                                                │
│   1404 │   │                                                                                │
│   1405 │   │   if len(error_msgs) > 0:                                                           │
│   1406 │   │   │   raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(     │
│ ❱ 1407 │   │   │   │   │   │   │      self.__class__.__name__, "\n\t".join(error_msgs)))         │
│   1408 │   │   return _IncompatibleKeys(missing_keys, unexpected_keys)                           │
│   1409 │                                                                                │
│   1410 │   def _named_members(self, get_members_fn, prefix='', recurse=True):

RuntimeError: Error(s) in loading state_dict for PeftModelForCausalLM:
        size mismatch for base_model.model.transformer.h.0.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.0.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.1.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.1.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.2.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.2.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.3.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.3.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.4.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.4.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.5.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.5.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.6.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.6.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.7.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.7.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.8.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.8.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.9.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.9.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.10.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.10.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.11.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.11.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.12.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.12.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.13.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.13.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.14.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.14.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.15.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.15.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.16.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.16.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.17.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.17.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.18.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.18.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.19.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.19.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.20.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.20.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.21.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.21.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.22.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.22.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).
        size mismatch for base_model.model.transformer.h.23.attn.c_attn.lora_A.default.weight: copying a param with shape torch.Size([32, 1024]) from checkpoint, the shape in
current model is torch.Size([16, 1024]).
        size mismatch for base_model.model.transformer.h.23.attn.c_attn.lora_B.default.weight: copying a param with shape torch.Size([2048, 16, 1]) from checkpoint, the shape
in current model is torch.Size([3072, 16]).

Hello @syngokhan, as explained in the latest PR https://github.com/huggingface/peft/pull/263#issuecomment-1497338967, the breaking change is for the models that used MergedLinear layers in LoRA as the support for it was supported, the reasons outlined in the link shared.  So, models impacted are GPT-2, Bloom variants as they will now use the same LoRA Linear layers as all the others.

Hi, I got the same problem. How to fix it?

Hello, as this is a breaking change, currently the way is to retrain the model

Hi, I got the same problem. How to fix it?

if you train the model again the problem is solved

I retrained my model, but the problem is still here.

I retrained my model, but the problem is still here.

Can you upgrade peft library ? And then train model ? And share problem


Implemented interfaces for Frame, Hand, Finger, Bone and Arm,  along …

…with zero-copy implementations of TransformedCopy.
The objective was to eliminate most memory allocations that contribute to GC stutter, most of which happened on Frame.TransformedCopy.
This was achieved by creating classes which transform the original values on demand, instead of transforming and copying all the values before-hand. Instances of these classes are obtained calling TransformedShallowCopy.
Of course, these Transformed* classes have different performance characteristics, but in the demo scene, using the CapsuleHand, the aggregated performance was improved. Even thou TransformedShallowCopy is much faster than TransformedCopy, the following scripts are slower since the actual calculation is happening lazily. In the end it's a clear win.
I needed to check whether those implementations were correct, so I created an Asserter class which compares two IFrame instances (and all it's children objects). This uncovered a few bugs in the original implementations and the new Transformed classes. For example, the bug #6 reported early doesn't affect the new classes. Anyway, there is some new code in LeapProvider.Update to optionally compare Frames transformed by TransformedCopy and TransformedShallowCopy.
Once those interfaces were created, I also created Invalid versions of those objects. These implementations throw NotImplementedExceptions (should change to something more appropriate like  IllegalOperationException) for every method, except IsValid and Equals. This allows a much more defensive coding style, where you MUST check IsValid before accessing an object, otherwise an exception is thrown. The static Invalid properties then were changed to return appropriate Invalid* singletons too, further reducing memory allocation.
Another huge source of memory allocations was in LeapImageRetriever. The _combinedTexture was being destroyed every frame just to be recreated. This was fixed too.
Looking at the Unity profiler, there is just a 44 byte allocation of a iterator in UpdateHandRepresentations now.
Remaining fixes and improvements:
FIX: Leap.Arm.TransformedCopy didn't normalize Direction.
FIX: Fixed FingerId propagation issue (#15)
IMP: TransformedCopy methods now receive Matrix by ref.
IMP: Methods FingerList.{Left, Front, Right}most don't allocate a temporary invalid Finger.
IMP: Methods HandList.{Left, Front, Right}most don't allocate a temporary invalid Finger.
IMP: CapsuleHand.updateCapsules performance improvements
IMP: LeapProvider.GetFixedFrame: only transform the returned frame.

Holy macrel!
I'd like to get this merged, but I do have a request:  Would you mind breaking it up a bit more?  Perhaps submitting the bugfixes in a separate PR, so we can understand and comment on them separately?

Nevermind, looks like the work is too tied together.  We'll leave it as it is.

This PR should target the develop branch instead of the master branch.  Develop branch is for developmental work, master branch is only for releases.

Let me apologize for doing things in an awkward manner. I didn't know that the UnityModules repo existed, let alone that it was publicly visible. So I didn't expect to ever create a pull request, I was prepared to keep my private copy of those scripts with our changes, and periodically merge with the official releases. I was about to blow my timebox, so I rushed it even more. Next time I'll create issues to discuss possible solutions instead of dropping a PR from out of nowhere.
Also, does the C# project have automated testing? I really needed the test code in LeapProvider and the Asserter class, it helped a lot in finding bugs, but it sure shouldn't be there.
Overall, I'm glad that this PR was received with such warmth, and I'll find some time to rewrite it.

Don't worry about it at all, it's easy enough to fix, though we will need to open a new PR.
The current system is three-layer API.  LeapC is on the bottom, then LeapCSharp (which is what this PR touches), and then at the top are the Unity wrappers.  Originally, LeapC didn't exist, and LeapCSharp was generated code.  We've always known LeapCSharp is horrible but until recently we couldn't do anything about it.
So, we spent the last two months rewriting the underlying API just so that we could change the wrapper.  We actually did fix a lot of issues in LeapCSharp, but our focus was just in getting LeapC completely stable.  We were about to blow our timebox for the Orion launch, so we focused all of our efforts on LeapC.  LeapCSharp had bugs, but it was at least functional.
Four engineers were dedicated to this project for two months for the sole purpose of allowing us to correcting these specific garbage collection problems.  And then, along comes this pull request.  Holy guacamole.  This is amazing.
THANK YOU for doing this, if you hadn't, it might have been another month before this stuff got out there.  If this isn't a testament to the power of open source, I don't know what is.

Also, we do have unit tests.  They're in a monolithic repository, though, and so I can't show you them directly.  I'm working on splitting up the monolith now, when it's done I'll make that stuff open source as well.

Closing this as superceded by #21


run cdk-nag on test

Currently in this construct, this violation is reported by cdk-nag
AwsSolutions-CB4: The CodeBuild project does not use an AWS KMS key for encryption.

We want to suppress invalid warnings inside the construct as much as possible. To detect these violations, we should run cdk-nag on unit test first.

There're already a lot of violations in the construct if we use AwsSolutionsCheck rule. We leave the violations as is at the moment and let a user decide whether they dismiss or handle them (maybe with escape hatches.)


Update build to use npm ci to improve reliability

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable
This is not yet available in Node 8.x (see https://github.com/nodejs/node/pull/21593).

We have had continual problems with the reliability of npm install in VSTS builds. It would be nice to switch to something that is designed for CI environments.

We could install the latest npm as part of the build script, there's no need to be tied to the version that comes with Node.

That would work too.
Also, we've talked about using yarn instead. My experience with Yarn so far has been that it's fast and reliable and doesn't require a special ci mode.

Looks like npm ci is significantly faster than yarn according to the post you linked. I'm not too worried either way, but I do want the install of whatever tools we use to be simple and as automated as possible.

Blocked https://github.com/aspnet/SignalR/pull/2823#issuecomment-414841842

Blocked on moving everything to AzDO

No longer blocked. TeamCity CI has NodeJS 10, as does AzDO.

Done in https://github.com/aspnet/AspNetCore/pull/4378


document Plot.valueof

Corrected the documentation to reflect that value can also be an array, null, or undefined. Also added documentation around whether valueof makes a copy, and what it will return. Also fix the documented behavior for the transform method case.


Debugger is getting the wrong file when running some specific code

I have the code on my own one note, ask me for it.
This is related to microsoft/vscode-python#8392
Run the first 3 cells
Debug the fourth, it will open the <ipython hash> file.

Closing for now. We think it might be fixed or broken in a different way.


Compilation fails on Linux (Ubuntu 22.04 LTS)

I have downloaded and build the Odin language compiler on my system. There are no errors when building the compiler. I have tried to compile OLS as instructed in the README.md as follows
$ ./build.sh

The system outputs the following errors.

Please provide some assistance in resolving these errors.

This is because your Odin version is old. Try the master branch of Odin.

@DanielGavin I don't know how I missed this, I feel so silly. The issue is resolved now.


Passing models from Url Rule to Controller fails

In one of our projects we are just using dev-master to load Yii2 (I know, that shouldn't be the case). Anyway, today we experienced the next problem, after running a composer update.
We are using URL Rules, while in the URL Rule finding a model and passing it to a frontend controller.
So, in the URL rule, within the parseRequest function:
$product = Product::findOne(2105816);
return array('product/index', ['product' => $product]);

Outputting $product gives ($product->getAttributes()):
Array
(
    [id] => 2105816
    [brand_id] => 1
    [type] => 'Test'
)

In the ProductController in frontend:
public function actionIndex(Product $product) {

Outputting $product gives ($product->getAttributes()):
Array
(
    [id] =>
    [brand_id] =>
    [type] =>
)

It might never have been the proper method of doing this (passing objects), but it clearly introduces a breaking change somewhere. Unfortunately I can't find which change introduced our problem, so I can't pinpoint it :(

You can try git bisect in order to find that change: https://git-scm.com/docs/git-bisect

Alright, I used bisect to find the moment the page stopped functioning. I believe this is the part of the composer.lock file that gives the references that changed on the yiisoft/yii2 package:
-                "reference": "3136632560e1a57f8a103e5a356d1809a078deec"
+                "reference": "e63916c82f24d0254b24cb7acc5368a6479f045e"

It ends up here: https://github.com/yiisoft/yii2/blob/master/framework/web/Controller.php#L79
Switching the if statements at L74 & L81 fixes it.
Currently it simply assumes that every class name in method signature does NOT exist as value in $params.

That timing! Just made a feature request that's related: #9890

@kidol could you create a pull request?

@SamMousa would @kidol change cover your request?

Looks like a good fix to me. @kidol, let me know if you can make it, else I'm available to submit it.

@stefandoorn Go ahead :) I didn't work on feature nor did I look further into it. Are there any tests for it yet? Probably should also add test for this issue.

It looks to me like this fix introduces the problem: #9476. I will make a PR, not sure if it's that easy to test it. Especially as I'm not that familiar with that Yii2 core.

@samdark, no, but my feature request would resolve his need for custom URL rule implementation I think.

@stefandoorn
Looks like test fail with fix:

Argument 2 passed to yiiunit\framework\web\FakeController::actionAksi6() must be an instance of yii\validators\EmailValidator, string given

This is ugly but passes tests and fixes problem:
if (($class = $param->getClass()) !== null && ($className = $class->getName()) && (!array_key_exists($name, $params) || !$params[$name] instanceof $className)) {

The first 2 checks should not be in the if, they should be evaluated before.
Let me know if you need help or want me to do fix.

I'm also bumping into the same test error indeed. If you have it ready to commit in there, please submit the PR. Some cleaning + comments in that function would help also, it's not easy to follow what's happening if looking at it for the first time :)

OK will make PR.


Command option -f  for custom app entry file

Includes

cavy run-ios and cavy run-android now have the -f (--file) option.

Pass in your app's main entry point and Cavy will assume that you have a corresponding .test.js version of this file, and boot the app from here.

Exit with code 1 if the user provides an entry point but no corresponding test entry point exists.
Tidying up of function names

Notes

The option passed in is the main app entry point not the test file. Is this confusing? Should we ask for the test file name and assume the main app entry point?
Instead of inferring of the test entry point from the entry point provided by the user, we could get them to provide both of these filenames?

Compatibility

New feature, backwards compatible, suggest minor version bump.

@jalada - ready for re-review!

LGTM! Let's :shipit:


use with zed SDK

Preliminary Checks

[X] This issue is not a duplicate. Before opening a new issue, please search existing issues.
[X] This issue is not a question, bug report, or anything other than a feature request directly related to this project.

Proposal
Is it possible to retrieve the Camera data with this package on one pc (without GPU) and then process it on another pc, on which the the ZED SDK is installed, in real time?
Use-Case
we have a smaller pc which is connected to all our sensors and then there is a second pc which receives the data from the low level pc. So in order to use the ZED Camera it would be nice to receive the zed camera data on one pc and then process it with the given ZED SDK on the second pc.
Anything else?
No response

Hi @Myzhar, I'd like to check, is this situation still the same as of now, 2024? I ask because we have a similar use case, Raspberry Pi powered device, streaming camera and sensor data to a CUDA capable laptop, and we're currently evaluating whether a Zed 2 would be a good fit for our application.
I can see from the samples that it's possible to pull the raw data from a Zed 2, and then later rectify the images and calculate the depth maps, but can you please comment on how the quality of these depth maps will compare to those produced by the SDK? Is there anything major that we'll be missing out on by not being able to process the camera data with the SDK?
Thanks in advance for your time.
Regards
Alan

Thanks for the info @Myzhar. Much appreciated.


Creating an official IRC #hugo channel on Freenode

We (some irc users) would like to have an official Hugo channel on Freenode.
For now there is two channel ( #hugo and ##hugo ).
Following Freenode guidelines, channels with only one # should be official and should be affiliated with their project.
As the channel is (for now at least) unofficial it's not perfectly clean and it could be deleted.
That's why there is a second channel (##hugo).
The IRC community is splitted between these two channels, having only one would be better for the project and for random irc users.
To make it official one of the gohugo representative ( @spf13 or @bep ) would have to agree on making it official and naming someone to take care of the channel.

21:29:04     Lord │ I wanted to gather some information now with you then open an issue on their github explaining how to do it
21:29:13        @e │ well, they'll need a representative on irc
21:29:34     Lord │ dumb question : how will you know they truly are representative ?
21:29:59     Lord │ they are 2 main devs
21:30:35        @e │ in this case if you opened an issue ideally they'd say "we want X to represent us to freenode" and then we'd read that
21:31:09      Lord │ ok thank you :-)

Thank you for considering this request.
If you are ok, you'll have to send an email to freenode (i can provide the address, or you can reach #freenode on irc.freenode.net).
edit : just found this gist mentionning what's required : https://gist.github.com/AbstractBeliefs/f82487dc7d7db54d7c94740c25c08084

My initial reaction: I think it is better to have one knowledge base, not two.

Please note that for there to be an official #hugo channel, the official project owners/maintainers wouldn't have to actually be active in managing the channel - this can be done by assigned operators like @lord-re and even myself if need be (I'm not very active though, just hanging out after building one single Hugo site) - but the maintainers which will be registered as the founders of the channel must be contactable in case the operators need assistance with some configuration of the channel.

My initial reaction: I think it is better to have one knowledge base, not two.

Yeah. That's why we're suggesting merging #hugo and ##hugo :)

This issue still needs direction from project representatives.

Happy to support this. I don't spend time on IRC anymore. Would need @bep
or community members to moderate.
On Fri, Dec 25, 2020 at 4:00 PM rawtaz<EMAIL_ADDRESS>wrote:

This issue still needs direction from project representatives.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo/issues/7421#issuecomment-751290490, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKKZHW3XAO33UL7NV7VPTSWT4P3ANCNFSM4OF7IF4Q
.


Click-through bug in Gnome 46

Describe the bug
Upgrade to Gnome 46 on NixOS (unstable) after https://github.com/NixOS/nixpkgs/pull/291339 introduces a click-through issue in some maximized windows. Clicks intended for the active application are passed through to the window below.
This bug has already been reported in the upstream in

https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
https://gitlab.gnome.org/GNOME/mutter/-/issues/3451

The first issue is closed in the upstream, and the fix might already be included in mutter 46.1 for NixOS (unstable). However, the second issue remains open and seems more relevant to our case, as it specifically mentions fullscreen games.
Steps To Reproduce
Steps to reproduce the behavior:

Upgrade to Gnome 46
Open a full-screen game in the steam
Try to click on different parts of the window, some parts have the click-through issue.

Expected behavior
The click event should be correctly passed to the top application.
Screenshots
The upstream issue contains screenshots and screencasts.
Additional context
Following the suggestion in the second issue, I tested applying this patch and it appears to resolve the bug.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.8.9, NixOS, 24.05 (Uakari), 24.05pre-git`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.22.0`
 - nixpkgs: `/nix/store/6433ddv0byqar86p7a3ja2vg6grq6mga-source`

Add a :+1: reaction to issues you find important.

Since this drove me crazy, and who knows when the next mutter version will land, here is a fix for now.
Download the patch for the mutter fix (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3720.patch)
{
  nixpkgs = {
    overlays = [
      (final: prev: {
        gnome = prev.gnome.overrideScope (
          self: super: {
            mutter = super.mutter.overrideAttrs (oldAttrs: rec {
              patches = (oldAttrs.patches or [ ]) ++ [ ./3720.patch ];
            });
          }
        );
      })
    ];
  };
}

This has been fixed in mutter 46.2 which is now in 24.05.


Re-enable tests with pys2index on Linux

The pys2index conda-forge packages have been rebuilt in https://github.com/conda-forge/pys2index-feedstock/pull/1.

Mmm so the problem is not solved by the freshly built conda-forge packages. Even worse, pys2index is broken for Python 3.9 on all platforms (see https://github.com/benbovy/pys2index/pull/3). No idea (yet) why...

Mmm so the problem is not solved by the freshly built conda-forge packages. Even worse, pys2index is broken for Python 3.9 on all platforms (see https://github.com/benbovy/pys2index/pull/3). No idea (yet) why...

pys2index has been fixed in the last release.
I also removed python 3.6 from the test matrix. Seg faults happen for that version now, which is caused by pys2index too. But I prefer seg faults happening with Python 3.6 rather than with Python 3.9. And since numpy 1.20 has dropped support for Python 3.6, I think it is ok to do the same here too.

Is this ready for merging? (Looks good from my point of view.)

Yes it's ready!


languages.en.description: custom params on the language top level is deprecated

WARN  config: languages.en.description: custom params on the language top level is deprecated and will be removed in a future release. Put the value below [languages.en.params]. See https://gohugo.io/content-management/multilingual/#changes-in-hugo-01120
WARN  config: languages.es.description: custom params on the language top level is deprecated and will be removed in a future release. Put the value below [languages.es.params]. See https://gohugo.io/content-management/multilingual/#changes-in-hugo-01120

ERROR deprecated: config: languages.en.description: custom params on the language top level was deprecated in Hugo v0.112.0 and will be removed in Hugo 0.127.0. Put the value below [languages.en.params]. See https://gohugo.io/content-management/multilingual/#changes-in-hugo-01120
ERROR deprecated: config: languages.es.description: custom params on the language top level was deprecated in Hugo v0.112.0 and will be removed in Hugo 0.127.0. Put the value below [languages.es.params]. See https://gohugo.io/content-management/multilingual/#changes-in-hugo-01120
INFO  Translation func for language es not found, use default.

+1
as soon as this will get officially removed, the
<meta name="twitter:description" content="…">

will stop working.

Fixed and released in https://github.com/cncf/dot-org-hugo-theme/releases/tag/v0.1.5
@karolyi I didn't understand your message here, after the change the Twitter card description is still working for me.


Revert addition of evil tolerance in jshint

:+1:

I did enjoy making a branch called jm-eliminate-evil.


Update readme file

I added the new features regarding issue #78  -

Adding the footer part.
Adding the contribution motivating lines so that more people contribute in this project.
Adding the link to contribution guidelines.
Adjust the heading and spaces.

Looking Great :)


Adds support for several new overrides

Deployment lifecycle, progressDeadlineSeconds, revisionHistoryLimit, and strategy are now available to override under the .Values.deployment taxonomy.
Liveness and readiness probe delays and periods are now configurable under the .Values.probes.[liveness|readiness] taxonomy
Arbitrary ingress annotations are supported under the .Values.ingress.annotations taxonomy
Container arguments are now supported under the .Values.deployment.args taxonomy.

This goes together with https://github.com/uw-it-ist/mci-k8s-flux/pull/25/files

I will approve this without comment once I get the ipfo-web deployment working with it, unless you want me to use this review to scrutinize where our k8s config has explicit options that are equal to defaults or where you've provided knobs for things that are the same across all our apps and environments. We have to do that anyway, it's a matter of whether you want to use it as revision fodder for this PR.


fix typo

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@MambaWong Thank you for your submission, please modify the commit format like
fix(tools): fix typo in sensor_calibration

@MambaWong I think he is asking you to modify the commit (i.e., rebase to reword the commit) instead of changing the title.

@YuqiHuai I see. Thank you.


Enable requester or issuer to publish File; Acknowledge by LO.

File has a new attribute: acknowledged: bool representing the acknowledgement by the LO (owner of the LOC).
Contributors to one LOC (requester or issuers) may now add file. Those items are stored NOT acknowledged.
LO may still add file - they are automatically acknowledged.
LO may acknowledge each file as long as the LOC is open.
Unauthorized is now also thrown when the given submitter does not match the actual caller (when the caller is not the LO).

Very similar to https://github.com/logion-network/logion-pallets/pull/22, with the following additions:

A migration for both File et Metadata is included.
The calls acknowledge[Metadata|File] fail when LOC is closed/voided.

Good job! However, I think there is something missing: the LOC can be closed only if all items have been acknowledged.

Done: https://github.com/logion-network/logion-pallets/pull/23/commits/36ef7bd50fb4cce4da886b05273650be53d018d6


✨  Add a scrapper for Opensubtitles

I updated 3 things :

Add the possibility to choose the wanted movie with search_result_index=None)

res = get_subtitles_from_movie(movie_name, language_code, search_result_index=None)

Fix a problem with tempfile, I had a Permission Denied error after download
Add an example with all functions in notebooks


Add tests for sparse max with axis=None

Rel #3515. Merge #3536 first.
This PR adds missing tests for sparse max with axis=None.

LGTM.
Could you merge (or rebase to) master?

I've merged the master!

Jenkins, test this please.

Jenkins CI test (for commit 455bc6a842d6188b92dd86e32ab496cbc8bebb35, target branch master) succeeded!


How to resolve possibly infinite nesting?

Parameter/Header content contains MediaType
MediaType encoding contains Encoding
Encoding headers contains Header
This structure allows possibly infinite nesting of Header->MediaType->Encoding->Header. Unfortunately I have not found in specification how should validators behave in case this occurs in a schema. Should it be allowed because Reference to a MediaType containing Header may be used in Header as well as other places? If occurance of Header is found in Header, should it be validated or ignored? Or should it be not allowed at all to have nested headers?
Another infinite nesting possibility is in Callback expression -> Path Item operation -> Operation callbacks -> Callback. In this case, it may make sense - callbacks can result in other callbacks. But I believe it should be explained by specification so implementators don't have to find it themselves.
Also references should have rules for recursion. e.g. in Schema recursive references may be valid in anyOf/oneOf and other conditional structures and in multi-level arrays (e.g. array<string|self> where self references array<string|self>). In other Schema structures and other objects recursive references should be probably forbidden.

The JSON Schema spec says:

A schema MUST NOT be run into an infinite loop against an instance. For example, if two schemas "#alice" and "#bob" both have an "allOf" property that refers to the other, a naive validator might get stuck in an infinite recursive loop trying to validate the instance. Schemas SHOULD NOT make use of infinite recursive nesting like this; the behavior is undefined.

It would be reasonable to insert similar language into the OpenAPI spec.

Json schema note is about infinite looping due to data schemas referencing each other. This issue is about unlimited spec nesting. It just does not make a lot of sense to me, that a header may define its media type if the header is already defined under a media type
e.g this media type is not explicitly considered invalid by the openapi specs, but it is complete non-sense, as media type in X-Example header can't ever happen and even if it could, it shouldn't.
# media type object
application/json:
  encoding:
    # encoding object
    exampleEncoding:
      headers:
        # header object
        X-Example:
          content:
            # media type object again
            application/xml: {}

I would simplify this issue and solve just the nesting and cyclical references in case of that nesting in openapi objects.
For the part about Schema object specifically I will probably create an issue in json schema spec repository, because recursive nesting is possible under conditions that could be defined and so behavior should not be undefined.  Here is an example of recursive nesting where structure is successfully printed and validated.

Json schema note is about infinite looping due to data schemas referencing each other.

It's the same as what you described -- we can have an infinite loop with various components referencing each other.
If they don't reference each other, then there must be some finite end, then there isn't any problem. But an implementation may still want to specify a maximum recursion depth, say 100 levels, to avoid resource contention issues.

@mabar in practice this shouldn't be a major concern, as it's hard to come up with a scenario in which this would nest deeply.  Media Type Objects only include Encoding Objects to handle multipart media types like [multipart/form-data], which uses an internal structure of headers and media types for each part.  But I'm not even sure how you could nest multipart/form-data inside multipart/form-data, much less why you'd do such a thing.
I'd try to find an actual use case or real-world example of deep nesting before worrying about it.  As @karenetheridge already pointed out, a max recursion level is an easy way to avoid problems in practice.

@handrews

Media Type Objects only include Encoding Objects to handle multipart media types like [multipart/form-data]

That's exactly what I missed, thank you! Only for multipart/* and application/x-www-form-urlencoded nesting makes sense and so only for it should be allowed. (specification says SHALL instead of MUST, which I would prefer, but good enough)
And multipart should not be nested since RFC 7578 deprecated it. It was also never well supported by tooling.
Only one level of nesting and only for multipart and form media types :) Thank you for your help


Add objects support

Needs to add objects support in ts-repeat
Example
$scope.data = {
  "123": { id: 123, name: "dave", age: 23 },
  "456": { id: 456, name: "chris", age: 23 },
  "789": { id: 789, name: "bob", age: 23 },
  "101": { id: 101, name: "tom", age: 23 },
  "102": { id: 102, name: "tim", age: 23 }
}

@mattiash It's pretty simple. I don't know why it wasn't done before :relieved:

I don't think it is a good idea to treat an object as a list and iterate over its values. I think the application should transform it into a list before trying to display it in a table.

@mattiash AngularJS natively supports object iteration via ng-repeat doc. Also I have no problem with this over 2 years of using my fork.


Updating Auth Interface

Details:
In this PR we're dropping the rounded corners UI in the Authentication UI.
@aerych B side of Simplenote PR 550!
Thank you!!!
Testing:
Testing Steps outlined here

Thank you Eric!!


Request/Future of this Repo ?

Hey @tschwery
if have used your repo to get my ttrss container up but i noticed i could not update to the latest ttrss versions since they changed their release setup (at least thats what i think).
I have updated the image in my fork of this repo https://github.com/vabene1111/docker-ttrss
I would like to polish it up some more, but i am not sure if you would like to have them under this repo or if i should just continue working on my fork. You also dont state any license so i wanted to ask if you are fine with me creating the fork and maybe adding a proper free license if that is your wish.
It would be great if you could clarify how you wish this code should live on :)

Hey,
Thanks for your issue. I am still using this repo for my ttrss instance and forgot to update them for the last 2 years.
I updated the URL to match what they are currently using (seems like ttrss migrated from Gitlab to Gogs since I deployed last time) and also updated PHP from 5.6 to 7. Concerning the license, I put a MIT license on there to clarify.
If you want to update or polish stuff, fork and go wild ! If you want to open PRs I will gladly read, consider and merge them.

ok cool, thanks for the info. I will look at it when i have time (probably when the next update is there 😂 )


Added score function into Board class.

A simple score function that adds 10 points per full_line_clear.

There are merge conflicts, you need to pull on main and merge main into score branch

merged


Find ASCII Charcode Of Inverse Case Character

Before jumping into Pr first comment for assign.All Problem from Edabit. Link is mandatory to add
**Problem statement: Find ASCII Charcode Of Inverse Case Character
**Problem Link: https://edabit.com/challenge/QFXMcwaQZ8FTAuEtg

Before submitting a PR please Check some details.Check Edabit for problem task

[ ] fileName formet should be in camelcase
example- returnTheNextNumber.py
[ ]  Add label for Problem
[ ]  In file there should be problem statement and link to probelm
example -

'''
    Probem Task : This program will add two numbers
    Problem Link : https://edabit.com/challenge/SFzHtm63XT6EYNHWY
'''
*/
def main():
    return a + b

This repository is vaild for HacktoberFest2020
Read before making PR - How to contribute on Github
Good Luck,

Please assign this issue to me.


gulp.src doesn't return files in order, very rarely

gulp: 3.8.11, node: v0.12.0, Debian squeeze
I am new to gulp, trying to move parts of our build process from bash scripts to gulp.
On very rare occasions (this is the 3rd time out of approx 100/150 runs), I am finding that gulp.src is not returning files in the order provided to it. It's difficult to reproduce it. Last time I had embedded debug messages in the gulp task and today when it re occurred, I got the log. The only thing common in these instances are that they are the first run of gulp after system restart and gulp takes much longer time to process.
The gulp task I am using is here: http://stackoverflow.com/a/28774788/235415. It's basically concatenating JS files, after processing and prepending licenses to them.
In the task, I had placed debug after gulp.src and before cache, like this:
each(jsConfig.post_jq.srcList, function(val, key, array) {
    var is_run_lint   = isProduction ? false : val.run_lint;
    var _src = val.src.map(function(el) {return srcBaseDir + el;});
    console.log('_src order: ' + _src);

    var stream = gulp.src(_src)
      .pipe( debug({title: 'before cache:'}) )
      .pipe( cache('scripts') )
      ....

I find in the log that the debug print of _src is in the order expected, but the prints with 'before cache:' is in different order, where the last item in the jsConfig is first, followed by the first two in order. The resultant merged JS is thus not in the correct order, but as in 'before cache:'.
The log (tpm.js == ih-1.js in SO post and that src has only this js file):
[20:45:52] Using gulpfile ~/gulpfile.js
[20:45:52] Starting 'build:js'...
_src order: /home/ethan/srv/tpm_ws/tpm/static/css_js/js/opensource/bootstrap.js
_src order: /home/ethan/srv/tpm_ws/tpm/static/css_js/js/opensource/jquery.lazyload.js
_src order: /home/ethan/srv/tpm_ws/tpm/static/css_js/js/tpm.js
streams.length: 3
[20:45:52] Finished 'build:js' after 245 ms

[20:45:52] before cache: srv/tpm_ws/tpm/static/css_js/js/tpm.js
[20:45:52] after cache: srv/tpm_ws/tpm/static/css_js/js/tpm.js
[20:45:53] before remember: srv/tpm_ws/tpm/static/css_js/js/tpm.js
[20:45:53] before cache: 1 items
[20:45:53] after cache: 1 items
[20:45:53] before cache: srv/tpm_ws/tpm/static/css_js/js/opensource/bootstrap.js
[20:45:53] after cache: srv/tpm_ws/tpm/static/css_js/js/opensource/bootstrap.js
[20:45:53] before remember: srv/tpm_ws/tpm/static/css_js/js/opensource/bootstrap.js
[20:45:53] before cache: 1 items
[20:45:53] after cache: 1 items
[20:45:53] before cache: srv/tpm_ws/tpm/static/css_js/js/opensource/jquery.lazyload.js
[20:45:53] after cache: srv/tpm_ws/tpm/static/css_js/js/opensource/jquery.lazyload.js
[20:45:53] before remember: srv/tpm_ws/tpm/static/css_js/js/opensource/jquery.lazyload.js
[20:45:53] before cache: 1 items
[20:45:53] after cache: 1 items
[20:45:53] before remember: 3 items
[20:45:53] after remember: srv/tpm_ws/tpm/static/css_js/js/tpm.js
[20:45:53] after remember: srv/tpm_ws/tpm/static/css_js/js/opensource/bootstrap.js
[20:45:53] after remember: srv/tpm_ws/tpm/static/css_js/js/opensource/jquery.lazyload.js
[20:45:53] after remember: 3 items

The output JS has tpm.js, bootstrap.js and jquery.lazyload.js concatenated in that order, instead of bootstrap,lazyload and tpm.

Show the whole pipeline, probably a plugin before concat that is losing the order

Here's the JSON config object:
var jsConfig = {
    post_jq: {
        output_file: 'core.js',
        srcList: [ {
            name: 'bootstrap',
            // The 'src' is kept offset from srcBaseDir (calculated below).
            src: ['js/opensource/bootstrap.js'],
            run_lint: false,
            run_uglify: true,
            drop_console: true,
            license: '/* <bootstrap license> */'
        }, {
            name: 'lazyload',
            src: ['js/opensource/jquery.lazyload.js'],
            run_lint: false,
            run_uglify: true,
            drop_console: true,
            license: '/* <lazyload license> */'
        }, {
            name: 'tpm',
            src: ['js/tpm.js'],
            run_lint: true,
            run_uglify: false,
            drop_console: false,
            license: ''
        } ]
    }
}

And here's the complete task, as-is:
gulp.task('build:js', function() {
    var streams = [];

    each(jsConfig.post_jq.srcList, function(val, key, array) {
        var is_run_lint   = isProduction ? false : val.run_lint;
        var _src = val.src.map(function(el) { return srcBaseDir + el; });
        console.log('_src order: ' + _src);

        var stream = gulp.src(_src)
          .pipe( debug({title: 'before cache:'}) )
          .pipe( cache('scripts') )
          .pipe( debug({title: 'after cache:'}) )

          .pipe( gulpif(is_run_lint, jshint('.jshintrc')) )
          .pipe( gulpif(is_run_lint, jshint.reporter('jshint-stylish')) )

          .pipe( gulpif(isProduction || (val.run_uglify && val.drop_console),
                                    uglify({compress:{drop_console:true}}),
                                        gulpif(val.run_uglify, uglify())
                        ) )

          // Notes on tap usage in docs/gulp/gulp_js_build_notes.txt.
          .pipe( tap(function(file) {
                  // file is provided here with full path. Hence.
                  var _cur_file_base = path.basename(file.path);
                  var _is_first_file =
                       (path.basename(_src[0]) === _cur_file_base) ? true:false;
                  var _is_last_file =
                       (path.basename(_src[_src.length-1]) === _cur_file_base) ?
                            true: false;

                  // If the license text is empty, don't add an extra newline.
                  var _license = (val.license.length > 0) ? val.license+'\n':'';

                  // In a bunch, first file gets license header, last file
                  // gets newline appended and middles ones are concatenated.
                  if (_is_first_file) {
                      file.contents = Buffer.concat([new Buffer(_license),
                                                    file.contents]);
                  }
                  if (_is_last_file) {
                      file.contents = Buffer.concat([file.contents,
                                                     new Buffer('\n')]);
                  }
                  return file.contents;
                }) );

        streams.push(stream);
    });

    console.log('streams.length: ' + streams.length);
    es.merge.apply(this, streams)
      .pipe( debug({title: 'before remember:'}) )
      .pipe( remember('scripts'))       // add back all files to the stream
      .pipe( debug({title: 'after remember:'}) )
      .pipe( concat(jsConfig.post_jq.output_file, {sep: ''}) )
      .pipe( rename({suffix: outputFileSuffix}) )
      .pipe( gulp.dest(outputDir) );
});

What exactly is this task supposed to do? This seems so overly complex

This has been my first task. Thanks for the feedback on it's complexity, that helps.
I describe the objectives of the task below. Note that much of the pipeline was borrowed/inspired from a gulp sample using cache/remember/tap plugins.
Objectives:

Concatenate the JS packages in order, as given by jsConfig (has other control options, and the 'name' field in jsConfig is not used). Using 'foreach' on jsConfig to process them in order.

Ugligy/remove-console.log:

Development build: Per package config via jsConfig
Production build: Mandatorily run.

jslint: Per pkg config via jsConfig (like not to run for unmodified opensource packages).

License txt: We often modify downloaded opensource files, even split them as necessary. All files for a given pkg are in 1 src, in jsConfig. We prepend the license file to the first src only (using 'tap' plugin) and append a newline to the last src of that pkg.
Our license text can be smaller than what is there on the opensource's un-minified version (generally, similar to their minified version).

An observation with the logs:
Before the gulp.src, I am prepending actual path to each of the src's relative one in jsConfig. (Didn't use 'base' of gulp.src, faced some initial issues with 'watch').
In the captured log provided above, I found that the logs with '_src order' are in correct order, but the logs with 'before cache', which is immediately after gulp.src, is not correct. Does this point give any clue on the issue?

The problem in your task is event-stream the merge method does not support ordering they are taken in the order of they are done, so smaller files will arrive first, most likely.
You should look at serial joins in the cheat sheet for reference; or maybe try gulp-order, personally I never used the later

Seems like @eth0lo has answered this.  Closing.

I don't think merge is the real problem here, but in the initial pipeline with gulp.src. Look at the logs in 1st post, especially the ones with '_src order' and 'before cache', which are just above and below the 'gulp.src'. The '_src order' shows the correct ordering, while 'before cache' has it different.
@contra Do you have any feedback? I was waiting for your simplified version, as you had mentioned.
@phated Can you keep this open for a while.

@collinsethans contra was telling you to simply your overly complex code. 99.9% of all issues opened on this tracker are due to badly behaving plugins, and as @eth0lo said, event-stream doesn't support ordering.

@phated Ok. Can you look at the structure of my code once again -- I first use 'foreach' (step 2 in below snippet) to process each of the files and push them to an array (5 below). Only after that, I use the es.merge with the array input (7). 'foreach' is widely used as I understand and I didn't yet figure any bug report there. The reported problem manifests right at the top, if you refer to the logs from below step 3 and 4 in my 1st post.
Below is the simplified structure for you to understand my code flow, with numbering to map with the logs in 1st post:
gulp.task('build:js-post_jq', function() {
    var streams = [];    // 1

    each(jsConfig.post_jq.srcList, function(val, key, array) {  // 2
        var _src = val.src.map(function(el) {
                                   return srcBaseDir + el;
                               });
        console.log('_src order: ' + _src);   // 3

        var stream = gulp.src(_src)
          .pipe( debug({title: 'before cache:'}) ) // 4
          .pipe( cache('scripts') )
           ....
          .pipe(...);

        streams.push(stream);   // 5
    });

    console.log('streams.length: ' + streams.length);   // 6
    es.merge.apply(this, streams)           // 7
        .pipe(...);
});

Would appreciate if you can take some time in pointing out where I am going wrong in my observation before the es.merge.apply.

You are generating three pipe lines there that are getting merged together with es.merge and since each of those pipes can end at any time that's why you see the error.
If you don't want to sync them manually, I would feed the gulp.src with the array of files instead, that should also solve your problem

@eth0lo Thanks for your reply and pointer to streamqueue. With the above code, I actually have been under the assumption that foreach() {} will complete first with it's array population and then comes in the merge.apply. So that's not the case.
I had initially thought of feeding gulp.src with the array, but dind't know how to do it for our requirement.
I have switched over to streamqueue. The current version looks like this:
gulp.task('build:js-post_jq', function() {
    var streams = streamqueue({ objectMode: true });       // new 1

    each(jsConfig.post_jq.srcList, function(val, key, array) {
        var _src = val.src.map(function(el) { return srcBaseDir + el; });
        console.log('_src order: ' + _src);

        var stream = gulp.src(_src)
          .pipe( debug({title: 'before cache:'}) )
          .pipe( cache('scripts') )
          ...
          .pipe(...);

        streams.queue(stream);          // new 2
    });

    return streams.done()               // new 3
      .pipe(...);
});

I am testing this out. The earlier problem was very difficult to reproduce, which used to manifest only when it's run after reboots and consuming much of the system RAM with other apps. Will update after a few days on the findings.

You are were not feeding it with an array, that's the problem, you are feeding gulp.src with only one item of your array.
foreach(jsConfig.post_jq.srcList, function(val, key, array) {
        var _src = val.src.map(function(el) { return srcBaseDir + el; });

        var stream = gulp.src(_src)

Your _src is only one file

@eth0lo Thanks for your time and help. The reported problem is now fixed with streamqueue, there hasn't been any sighting since.
However, I am facing a new problem and this is very rare. When using gulp watch, if I update one of the js files (3 js files declared in jsConfig) watch is getting triggered but gulp.src is not returning it. This happens after a very long usage of gulp watch and is very rare.
My code is same as mentioned earlier. Copied here for convenience:
gulp.task('build:js-post_jq', function() {
    var streams = streamqueue({ objectMode: true });       // new 1

    foreach(jsConfig.post_jq.srcList, function(val, key, array) {
        var _src = val.src.map(function(el) { return srcBaseDir + el; });
        console.log('_src order: ' + _src);

        var stream = gulp.src(_src)
          .pipe( debug({title: 'before cache:'}) )
          .pipe( cache('scripts') )
          ...
          .pipe(...);

        streams.queue(stream);          // new 2
    });

    return streams.done()               // new 3
      .pipe(...);
});

When this happens, I see the log message _src order: reporting the file, but the debug msg before cache called after gulp.src (and subsequent dbgs in the chain) are not reporting it. Finally, the resultant js file doesn't hold it. I really don't know yet who is creating the issue here.