使用adam_offload后，训练完模型save_model时报错

16卡全参数微调72B模型后，保存模型时报错，大佬么帮忙看看！
dev-worker-0: [2024-10-12 06:35:03,642] [ERROR] [launch.py:325:sigkill_handler] ['/usr/bin/python', '-u', '-m', 'openrlhf.cli.train_sft', '--local_rank=7', '--max_len', '4096', '--dataset', 'mixed_task_radiology', '--input_key', 'input', '--output_key', 'output', '--train_batch_size', '256', '--micro_train_batch_size', '2', '--max_samples_train', '5000000', '--max_samples_eval', '16', '--pretrain', 'Qwen2.5-72B-Instruct', '--model_type', 'qwen2', '--save_path', 'test-Qwen2.5-72B-Instruct', '--save_steps', '-1', '--logging_steps', '1', '--eval_steps', '-1', '--max_epochs', '5', '--bf16', '--flash_attn', '--learning_rate', '2e-5', '--load_ds_method', 'custom', '--max_ckpt_num', '1', '--zero_stage', '3', '--grad_accum_dtype', 'fp32', '--gradient_checkpointing', '--gradient_checkpointing_use_reentrant', '--adam_offload'] exits with return code = -9
pdsh@dev-launcher: dev-worker-0: ssh exited with exit code 247
dev-worker-1: [rank15]:[E ProcessGroupNCCL.cpp:550] [Rank 15] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800252 milliseconds before timing out.
dev-worker-1: [rank15]:[E ProcessGroupNCCL.cpp:564] [Rank 15] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
dev-worker-1: [rank15]:[E ProcessGroupNCCL.cpp:570] [Rank 15] To avoid data inconsistency, we are taking the entire process down.
dev-worker-1: [rank15]:[E ProcessGroupNCCL.cpp:1335] [PG 0 Rank 15] NCCL watchdog thread terminated with exception: [Rank 15] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800252 milliseconds before timing out.
dev-worker-1: Exception raised from checkTimeout at /opt/pytorch/pytorch/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:552 (most recent call first):
dev-worker-1: frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) + 0x99 (0x7f3720084dc9 in /usr/local/lib/python3.10/dist-packages/torch/lib/libc10.so)
dev-worker-1: frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1f8 (0x7f36befb2098 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #2: c10d::ProcessGroupNCCL::watchdogHandler() + 0x236 (0x7f36befb90c6 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x125 (0x7f36befb9ed5 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #4:  + 0xdc253 (0x7f371fcb0253 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
dev-worker-1: frame #5:  + 0x94ac3 (0x7f37cde3aac3 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1: frame #6: clone + 0x44 (0x7f37cdecba04 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1:
dev-worker-1: terminate called after throwing an instance of 'c10::DistBackendError'
dev-worker-1:   what():  [PG 0 Rank 15] NCCL watchdog thread terminated with exception: [Rank 15] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800252 milliseconds before timing out.
dev-worker-1: Exception raised from checkTimeout at /opt/pytorch/pytorch/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:552 (most recent call first):
dev-worker-1: frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) + 0x99 (0x7f3720084dc9 in /usr/local/lib/python3.10/dist-packages/torch/lib/libc10.so)
dev-worker-1: frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1f8 (0x7f36befb2098 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #2: c10d::ProcessGroupNCCL::watchdogHandler() + 0x236 (0x7f36befb90c6 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x125 (0x7f36befb9ed5 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #4:  + 0xdc253 (0x7f371fcb0253 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
dev-worker-1: frame #5:  + 0x94ac3 (0x7f37cde3aac3 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1: frame #6: clone + 0x44 (0x7f37cdecba04 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1:
dev-worker-1: Exception raised from ncclCommWatchdog at /opt/pytorch/pytorch/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1339 (most recent call first):
dev-worker-1: frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) + 0x99 (0x7f3720084dc9 in /usr/local/lib/python3.10/dist-packages/torch/lib/libc10.so)
dev-worker-1: frame #1:  + 0xf6f04e (0x7f36befe604e in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #2:  + 0xca016a (0x7f36bed1716a in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #3:  + 0xdc253 (0x7f371fcb0253 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
dev-worker-1: frame #4:  + 0x94ac3 (0x7f37cde3aac3 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1: frame #5: clone + 0x44 (0x7f37cdecba04 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1:
dev-worker-1: [rank12]:[E ProcessGroupNCCL.cpp:550] [Rank 12] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800263 milliseconds before timing out.
dev-worker-1: [rank12]:[E ProcessGroupNCCL.cpp:564] [Rank 12] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
dev-worker-1: [rank12]:[E ProcessGroupNCCL.cpp:570] [Rank 12] To avoid data inconsistency, we are taking the entire process down.
dev-worker-1: [rank10]:[E ProcessGroupNCCL.cpp:550] [Rank 10] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800255 milliseconds before timing out.
dev-worker-1: [rank12]:[E ProcessGroupNCCL.cpp:1335] [PG 0 Rank 12] NCCL watchdog thread terminated with exception: [Rank 12] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800263 milliseconds before timing out.
dev-worker-1: Exception raised from checkTimeout at /opt/pytorch/pytorch/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:552 (most recent call first):
dev-worker-1: frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) + 0x99 (0x7fe92c99bdc9 in /usr/local/lib/python3.10/dist-packages/torch/lib/libc10.so)
dev-worker-1: frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1f8 (0x7fe8cb7b2098 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #2: c10d::ProcessGroupNCCL::watchdogHandler() + 0x236 (0x7fe8cb7b90c6 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x125 (0x7fe8cb7b9ed5 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #4:  + 0xdc253 (0x7fe92c4b0253 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
dev-worker-1: frame #5:  + 0x94ac3 (0x7fe9da6d5ac3 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1: frame #6: clone + 0x44 (0x7fe9da766a04 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1:
dev-worker-1: terminate called after throwing an instance of 'c10::DistBackendError'
dev-worker-1:   what():  [PG 0 Rank 12] NCCL watchdog thread terminated with exception: [Rank 12] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=5650564, OpType=_ALLGATHER_BASE, NumelIn=15138816, NumelOut=242221056, Timeout(ms)=1800000) ran for 1800263 milliseconds before timing out.
dev-worker-1: Exception raised from checkTimeout at /opt/pytorch/pytorch/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:552 (most recent call first):
dev-worker-1: frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) + 0x99 (0x7fe92c99bdc9 in /usr/local/lib/python3.10/dist-packages/torch/lib/libc10.so)
dev-worker-1: frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1f8 (0x7fe8cb7b2098 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #2: c10d::ProcessGroupNCCL::watchdogHandler() + 0x236 (0x7fe8cb7b90c6 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x125 (0x7fe8cb7b9ed5 in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #4:  + 0xdc253 (0x7fe92c4b0253 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
dev-worker-1: frame #5:  + 0x94ac3 (0x7fe9da6d5ac3 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1: frame #6: clone + 0x44 (0x7fe9da766a04 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1:
dev-worker-1: Exception raised from ncclCommWatchdog at /opt/pytorch/pytorch/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1339 (most recent call first):
dev-worker-1: frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) + 0x99 (0x7fe92c99bdc9 in /usr/local/lib/python3.10/dist-packages/torch/lib/libc10.so)
dev-worker-1: frame #1:  + 0xf6f04e (0x7fe8cb7e604e in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #2:  + 0xca016a (0x7fe8cb51716a in /usr/local/lib/python3.10/dist-packages/torch/lib/libtorch_cuda.so)
dev-worker-1: frame #3:  + 0xdc253 (0x7fe92c4b0253 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
dev-worker-1: frame #4:  + 0x94ac3 (0x7fe9da6d5ac3 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1: frame #5: clone + 0x44 (0x7fe9da766a04 in /usr/lib/x86_64-linux-gnu/libc.so.6)
dev-worker-1:

请问是在 docker container里面测试的吗?

这是来自QQ邮箱的假期自动回复邮件。你发给我的信件已经收到。谢谢!

请问是在 docker container里面测试的吗?

使用kubectl 启动的yaml文件，在yaml文件中执行 bash examples/scripts/train_sft_llama.sh


UUIDResource has_many IdResource causes undefined method [] when doing GET [...]?includes=

This issue is a (choose one):

[x] Problem/bug report.

Description
I've tracked the issue to lib/jsonapi/processor.rb:587.
resource_set[resource_klass] is holding the associated resources in an array key'd by a string {"1" => [...]} and attempting to access it via an int resource.id.
With the following resources just issue this get request (make sure to have include=).
GET /uuids/3bbaf722-4583-4fa6-ac36-9190d4b93f80?include=ids
class UuidResource < JSONAPI::Resource
  key_type :uuid
  has_many :ids
end

class IdResource < JSONAPI::Resource
  has_one :uuid
end

Throws error:
Internal Server Error: undefined method `[]' for nil:NilClass /var/lib/gems/2.3.0/bundler/gems/jsonapi-resources-d185ebb76cd2/lib/jsonapi/processor.rb:587:in `block (2 levels) in populate_resource_set'
/var/lib/gems/2.3.0/bundler/gems/jsonapi-resources-d185ebb76cd2/lib/jsonapi/processor.rb:586:in `each'
/var/lib/gems/2.3.0/bundler/gems/jsonapi-resources-d185ebb76cd2/lib/jsonapi/processor.rb:586:in `block in populate_resource_set'
/var/lib/gems/2.3.0/bundler/gems/jsonapi-resources-d185ebb76cd2/lib/jsonapi/processor.rb:542:in `each_key'

Still not sure how to reproduce in unit tests.
This branch fixes my production code issue_1156

Yep this is definitely an issue - I have pushed a unit test that fails.
If the top-level controller resource is a UUID then it will cast all the included resources primary keys as strings instead of integers.
Change that top level resource from UUID -> integer and the unit test will then pass.
The source_resource array has JSONAPI::ResourceIdentity objects that have primary keys as integers cast to strings, but the related_resource[:source_rids] JSONAPI::ResourceIdentity object it's using for lookup (process.rb lines 488 to 495 have a primary key as an integer.


When sliding the Flutter interface back to the previous interface in iOS 18.2, if you quickly click the button on the previous interface, there will be a problem where the button cannot respond.

Steps to reproduce
When sliding the Flutter interface back to the previous interface in iOS 18.2, if you quickly click the button on the previous interface, there will be a problem where the button cannot respond. It takes about 0.3 seconds for all events to proceed normally, and the interface returned by the return button is also fine. This problem can be reproduced in Flutter 3.23.4 and 3.27.0
Expected results
The button briefly loses response
Actual results
I'm not sure
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: FirstScreen(),
    );
  }
}

class FirstScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('第一个界面'),
      ),
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            Navigator.push(
              context,
              MaterialPageRoute(builder: (context) => SecondScreen()),
            );
          },
          child: Text('跳转到第二个界面'),
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('第二个界面'),
      ),
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            Navigator.pop(context);
          },
          child: Text('返回第一个界面'),
        ),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.27.0, on macOS 15.0 24A5320a darwin-arm64, locale
    zh-Hans-CN)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 16.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2024.1)
[✓] VS Code (version 1.95.3)
[✓] Connected device (6 available)
    ! Error: Browsing on the local area network for che的iPhone. Ensure the
      device is unlocked and attached with a cable or associated with the same
      local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code
      -27)
    ! Error: Browsing on the local area network for Ugreen的iPhone. Ensure the
      device is unlocked and attached with a cable or associated with the same
      local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code
      -27)
    ! Error: Browsing on the local area network for iPhone 🫰. Ensure the device
      is unlocked and attached with a cable or associated with the same local
      area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code
      -27)
    ! Error: Browsing on the local area network for iPad (4). Ensure the device
      is unlocked and attached with a cable or associated with the same local
      area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code
      -27)
    ! Error: Browsing on the local area network for iPad Pro 🕸. Ensure the
      device is unlocked and attached with a cable or associated with the same
      local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code
      -27)
[✓] Network resources

• No issues found!

@SoBison
Is it only occuring on 18.2 or happens on previous versions as well ?
Can you provide a short video of the behavior ?

@SoBison 它只发生在 18.2 上还是也发生在以前的版本上？ 你能提供一个关于这种行为的简短视频吗？

It also exists on iOS 18.1

@SoBison Is it only occuring on 18.2 or happens on previous versions as well ? Can you provide a short video of the behavior ?

Uploading IMG_0535.MOV.zip…

@SoBison Is it only occuring on 18.2 or happens on previous versions as well ? Can you provide a short video of the behavior ?

It also exists on iOS 18.1
80DC00DC-D1F7-4B97-9026-114E73A4F8A7.MP4…

Thanks for the update @SoBison
I currently don't have the latest iOS update, but just to confirm that this is only specific to Flutter, is there a way for you to check in native iOS apps to see if the same behavior persist or not ?

感谢更新@SoBison 我目前没有最新的 iOS 更新，但只是为了确认这仅限于 Flutter，有没有办法检查原生 iOS 应用程序以查看相同的行为是否持续存在？

The native sliding back operation on iOS is normal

The native sliding back operation on iOS is normal

The native sliding back operation on iOS is normal

Thanks for the update @SoBison I currently don't have the latest iOS update, but just to confirm that this is only specific to Flutter, is there a way for you to check in native iOS apps to see if the same behavior persist or not ?

Thanks for the update @SoBison I currently don't have the latest iOS update, but just to confirm that this is only specific to Flutter, is there a way for you to check in native iOS apps to see if the same behavior persist or not ?

Thanks for the update @SoBison I currently don't have the latest iOS update, but just to confirm that this is only specific to Flutter, is there a way for you to check in native iOS apps to see if the same behavior persist or not ?

The native sliding back operation on iOS is normal

Can you switch to latest master and re-run your scenario to check if the behavior persist still or not ?


Cygwin alternative

The slides kinda go over my head.
Does this mean this could be used as a cygwin alternative?

The slides are a technical analysis of how it's built.
Still, the answer is mostly yes. Cygwin has an advantage in still providing applications the full Win32 API in their processes, but most of the other uses (just using Linux user land processes, servers, toolchains, and workflows) are covered by it.


FinRL-Meta - package or github repo to be used in FinRL

Hi all,
First of all, thanks a lot for this project. I've just started playing around with it and hope to be actively contributing soon as well.
I have noticed that the dataprocessors in the FinRL-Meta repo are quite different than the ones available in the package that comes with FinRL. Since I'll be setting up a custom environment and dataprocessor for my project, I was wondering which baseline I should be following to ensure compatibility with future changes?
Thanks in advance!

Thanks very much for this good question.  Actually, we are also working on "unifying" the two.  We would like to make the two repo to satisfy the "plug-and-play" principle.

Thanks for the rapid reply. If you give me a guideline, I'm definitely willing to contribute to this development if you'd need it. I'd just need to know if a certain baseline is already defined (such as the data_processor.py in the FinRL-Meta repo). I can then adapt the different dataprocessors to follow the same approach.

We are now developing finrlmeta. In the future, we will integrate finrlmeta to finrl so that they are unified.


setEmotion is not thread safe

I was checking the code, and I noticed that if I call setEmotion from code repeatedly, there might be race conditions. In fact, subsequent calls to setEmotion might change the values of isTransition and command while they are being used in updateModule
cc @Nicogene @martinaxgloria

Related PR: https://github.com/icub-tech-iit/ergocub-software/pull/139


Project creation time

Add the logic to save the date and time of creation of projects in a database and visualize it in SAVE.

duplicate of #806

Duplicate of #806


Request: Support for maintaining total issuance with balance storage change

Not super important but it would great if, when changing the storage item for balance, it also updates the total issuance of balances.

Not sure how this can be implemented without hardcode bunch pallet specific rules

Another possibility is to change a key, so you can take the balance of another account and keep the total issuance correct

you can set storage at any time just by using RPC dev_setStorages


Items no longer display upon 2 stacks in one slot.

Hello, I am having an issue with this mod and Storage Drawers (or any other barrel style inventory). When there is more than 127 items in a single slot, it is not displayed at all. If there are other stacks in the inventory, then they will be displayed (as long as they are less than 128).

It's hard to help with no version info.

Apologies, should have specified that this is on 1.12 with
HoloInventory-1.12.2-<IP_ADDRESS> and StorageDrawers-1.12.2-5.3.7 which are the latest versions and have been for ~6 months now. Forge is <IP_ADDRESS>68 which is the current recommended.

I have tested it with Storage Drawers, Charset Barrels and Worse Barrels.
Only Storage Drawers has the issue, it worked in past version so I would assume something with drawers changed.
I don't have the slightest idea as to why it would do this and I am unsure if Dries will fix it anytime soon as it's not really that important.

Sorry I made an assumption after testing a few barrel mods. So it is working with charset barrels and worse barrels. However it does not work with Compact Storage barrels or YABBA barrels. I just tested all versions of StorageDrawers for 1.12 and as of version 5.3.0 items are being displayed up to 127 only. Before 5.3.0, nothing is displayed whatsoever. I get the feeling it has something to do with IInventory since that changed in 5.3.0. Perhaps some mods use it and it works properly, but if it doesn't this bug is caused? Sorry if i'm being difficult I'd just really prefer this mod over TOP, if possible.

I'll try have a look ASAP, but I'm quite busy for the next few weeks.


Replace mainSourceFile with excludedSourceFile in unittest build

The directive wasn't using mainSourceFile,
because the configuration was only for testing.

The test system in mysql-native is kind of weird (I have to figure out why it's used here). I don't think the change is as simple as this. But you have it backwards -- the dub changes are preventing people from using this project, not the other way around. If someone depends on a specific revision of mysql-native, they shouldn't have to upgrade because the build system all of a sudden decided things don't mean what they used to mean. This is not the only project broken by the dub changes.

I don't think the change is as simple as this.

I would need more details on this. Knowing the feature and what it does, I see no reason why it'd be more complicated.

But you have it backwards -- the dub changes are preventing people from using this project, not the other way around.

Those releases versions are released, we can't change that. What we can do is make future versions of mysql-native compatible with all dub version by removing one line.

Likewise, historical versions of mysql-native are released, we can't change that. Why should someone depending on an older version of mysql-native have to upgrade (and validate their project) simply because the build system decided things didn't mean what they used to mean?
I don't disagree that it shouldn't be using this directive for future versions, I want to revisit the whole testing system in general (it's run with shell scripts and compiled test harnesses, whereas I think most of it should be with unittests). But this ignores the fact that the build system has already been fundamentally altered and I don't want to release new versions of old branches (i.e. a new 2.x release) just to workaround dub bugs.

I don't disagree that it shouldn't be using this directive for future versions

So let's merge this, shall we, unblock users, and continue the discussion about dub in the dub PR ?

I need to verify the CI still works (it's not running, and I don't know why at the moment).

Can you force push? I think I had a setting wrong on travis.

OK that seems to have done it.

So CI is failing due to the extra "main" declared in https://github.com/mysql-d/mysql-native/blob/e52eacfdd41a1972e033d2e56367658a49e0a268/source/mysql/package.d#L97
I have to spend some time digging through the CI to figure out what it is trying to do with that. It seems oddly out of place, and more of a kludge than solution.

I'm going to have to address CI soon. This one build on Travis consumed all the credits, so this will take some time. I think next step is to set up github actions to avoid this situation. See #227

Okay so I compiled with verbose output. Without any change (using mainSourceFile), configuration unittest-vibe outputs:
dmd -c -of.dub/build/mysql-native-test-unittest-vibe-unittest-posix.osx.darwin-x86_64-dmd_v2.096.1-E3DA5E7543076FDAF986A9BACAB23BA6/mysql-native-test-unittest-vibe.o -debug -g -unittest -w -version=Have_mysql_native -version=Have_vibe_core -version=Have_eventcore -version=Have_stdx_allocator -version=EventcoreKqueueDriver -version=Have_taggedalgebraic -debug=MYSQLN_TESTS -Isource/ -I../../.dub/packages/vibe-core-1.7.0/vibe-core/source/ -I../../.dub/packages/eventcore-0.8.48/eventcore/source/ -I../../.dub/packages/taggedalgebraic-0.11.6/taggedalgebraic/source/ -I../../.dub/packages/stdx-allocator-2.77.5/stdx-allocator/source/
.dub/code/mysql-native-test-unittest-vibe-unittest-posix.osx.darwin-x86_64-dmd_v2.096.1-25A439DC1BA9D7C14B9E3D73F82E2418_dub_test_root.d source/mysql/commands.d source/mysql/connection.d source/mysql/escape.d source/mysql/exceptions.d source/mysql/metadata.d source/mysql/pool.d source/mysql/prepared.d source/mysql/protocol/comms.d source/mysql/protocol/constants.d source/mysql/protocol/extra_types.d source/mysql/protocol/packet_helpers.d source/mysql/protocol/packets.d source/mysql/protocol/sockets.d source/mysql/result.d source/mysql/test/common.d source/mysql/test/integration.d source/mysql/test/regression.d source/mysql/types.d ../../.dub/packages/vibe-core-1.7.0/vibe-core/source/vibe/appmain.d -vcolumns

With the line removed:
dmd -c -of.dub/build/mysql-native-test-unittest-vibe-unittest-posix.osx.darwin-x86_64-dmd_v2.096.1-E3DA5E7543076FDAF986A9BACAB23BA6/mysql-native-test-unittest-vibe.o -debug -g -unittest -w -version=Have_mysql_native -version=Have_vibe_core -version=Have_eventcore -version=Have_stdx_allocator -version=EventcoreKqueueDriver -version=Have_taggedalgebraic -debug=MYSQLN_TESTS -Isource/ -I../../.dub/packages/vibe-core-1.7.0/vibe-core/source/ -I../../.dub/packages/eventcore-0.8.48/eventcore/source/ -I../../.dub/packages/taggedalgebraic-0.11.6/taggedalgebraic/source/ -I../../.dub/packages/stdx-allocator-2.77.5/stdx-allocator/source/
.dub/code/mysql-native-test-unittest-vibe-unittest-posix.osx.darwin-x86_64-dmd_v2.096.1-25A439DC1BA9D7C14B9E3D73F82E2418_dub_test_root.d source/mysql/commands.d source/mysql/connection.d source/mysql/escape.d source/mysql/exceptions.d source/mysql/metadata.d source/mysql/package.d source/mysql/pool.d source/mysql/prepared.d source/mysql/protocol/comms.d source/mysql/protocol/constants.d source/mysql/protocol/extra_types.d source/mysql/protocol/packet_helpers.d source/mysql/protocol/packets.d source/mysql/protocol/sockets.d source/mysql/result.d source/mysql/test/common.d source/mysql/test/integration.d source/mysql/test/regression.d source/mysql/types.d ../../.dub/packages/vibe-core-1.7.0/vibe-core/source/vibe/appmain.d -vcolumns

With the latest change (excludedSourceFiles):
dmd -c -of.dub/build/mysql-native-test-unittest-vibe-unittest-posix.osx.darwin-x86_64-dmd_v2.096.1-E3DA5E7543076FDAF986A9BACAB23BA6/mysql-native-test-unittest-vibe.o -debug -g -unittest -w -version=Have_mysql_native -version=Have_vibe_core -version=Have_eventcore -version=Have_stdx_allocator -version=EventcoreKqueueDriver -version=Have_taggedalgebraic -debug=MYSQLN_TESTS -Isource/ -I../../.dub/packages/vibe-core-1.7.0/vibe-core/source/ -I../../.dub/packages/eventcore-0.8.48/eventcore/source/ -I../../.dub/packages/taggedalgebraic-0.11.6/taggedalgebraic/source/ -I../../.dub/packages/stdx-allocator-2.77.5/stdx-allocator/source/
.dub/code/mysql-native-test-unittest-vibe-unittest-posix.osx.darwin-x86_64-dmd_v2.096.1-25A439DC1BA9D7C14B9E3D73F82E2418_dub_test_root.d source/mysql/commands.d source/mysql/connection.d source/mysql/escape.d source/mysql/exceptions.d source/mysql/metadata.d source/mysql/pool.d source/mysql/prepared.d source/mysql/protocol/comms.d source/mysql/protocol/constants.d source/mysql/protocol/extra_types.d source/mysql/protocol/packet_helpers.d source/mysql/protocol/packets.d source/mysql/protocol/sockets.d source/mysql/result.d source/mysql/test/common.d source/mysql/test/integration.d source/mysql/test/regression.d source/mysql/types.d ../../.dub/packages/vibe-core-1.7.0/vibe-core/source/vibe/appmain.d -vcolumns

(I added a newline to separate the list of files, for readability).
So currently, package.d is actually not compiled in, because mainSourceFile is excluded from dub test.
The thing is, there is some overlap between what dub test does and what the unittest configuration does.
Note that I also noticed that all configurations but one use excludedSourceFile "source/app.d". And that's exactly this kind of use case for which the mainSourceFile behavior was fixed.

I'm going to have to address CI soon. This one build on Travis consumed all the credits, so this will take some time.

Yeah Travis really killed their open source offering with the credit approach.

See #227

Thanks for the pointer, I gave a review to the PR 🤷

Fixed, although the configuration is not used anymore.

Going to close, as I think this is no longer relevant. In #235 I'm planning on removing the source/app.d file completely, as it really is its own thing not related to the library.

I'm not sure I follow ? The unittest-vibe is currently broken, but you don't see it in the CI because it's not used anymore (AFAICS). This unbreaks it. Removing source/app.d sounds like a good idea on its own, but I suppose for the present PR to be irrelevant you'd have to remove unittest-vibe, wouldn't you ?

See the referenced PR. in particular the dub.sdl. I'm making things simple.

BTW, the unittest-vibe and the unittest-vibe-ut were redundant. Just one used unit-threaded and the other didn't. I'm not sure why they were both in there.


feat: Enable traffic flow from SCC to COS is added

Description
Added SCC network zone in the COS rule context to allow traffic flow from SCC -> COS.
Git Issue
Release required?

[ ] No release
[ ] Patch release (x.x.X)
[x] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Allowed traffic from SCC to COS with private endpoint.

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 1.27.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Showcase bundles don't need to be checked in

@benshope would you mind landing your codemod prs before i land this guy? i don't wanna create any zombie code

Thanks for merging!  I was going to say that it's fine if this makes a conflict - conflicts against this will be easy to resolve


Please enable a way to hide Java examples and/or select your preferred programming language

For example:
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-communication

@rdiazconcha Thanks for your feedback. Your issue is transferred to azure team. They will help you there.


Fix composer.json

The package does not provide PSR-16 implementation anymore.
The package should require PSR-16 implementation.
Drivers should provide PSR-16 implementations.

Not relevant, since this package also contains PSR-16 implementations.

Not relevant, since this package also contains PSR-16 implementations.


Pick up icons from icon path in RPM package build

:penguin: :package: This rounds out the issues addressed in PR #5339, PR #5336 and issue #5331. Now the ideal icon for a given resolution is available to the desktop environment.

:warning: I modified the the directory structure so that the new icons @simurai would be included in the build. However, now I am pretty sure they are included in every build (Linux, Mac and Windows). I doubt this is a big issue, but I wanted to make sure that it is known in case someone can provide a workaround so that extraneous data isn't copied around willy-nilly; I am personally not familar enough with the general build process yet to know how to take care of it.

Would you mind renaming the icons back and adding an explicit copy for it in a similar pattern to this example?
https://github.com/atom/atom/blob/01bf346d0f1fb86fefaad66e80bc70dd66992bb3/build/tasks/build-task.coffee#L157-L158
It isn't a huge issue but it would be nice to not add any unnecessary size to the mac/windows distributions.

I would not mind at all. In fact I would prefer to move them back :smile: ; I just didn't know where to look for an example on how to copy them over for the build. The commit you pointed to should help. Thanks.

Thanks for the notice @eestrada - it's probably not worth worrying about, it's one meg out of a hundred.

I agree @thedaniel, but at the same time, a meg here and meg there eventually adds up. All they are used for is copying over at rpm build time, then they just sit in the install directory doing nothing after that. I'd rather clean up it the now while I am already mucking around in this part of the code.

Ok, the icons are no longer copied into the main installed directory. They are only copied for the :package: build process and only on Linux. Let me know if there is anything else this PR needs to be copacetic.

Looks great, thanks for this and all other solid PRs this week :ship: :ship: :ship:

:+1: No problem.


Added ability to fetch and pull coinbase orderbooks

Code lacks significant customizability and binance data but will be added in future PRs

will fix ci warnings

Don’t worry about CI right now, it’s not working on main either.

nice work! +1 on ninos. not super on edge about this code for now - we will be revisitng this many times in the future.

not super on edge about this code for now - we will be revisitng this many times in the future.

agreed


Chore: Bump Dependency Module Versions

what

Bump route53-alias module version to latest.
Bump s3-log-storage module to latest.

why

Dependency modules do not currently support tenant label (they are not at the version which supports it).
General module hygiene: keep dependency modules up to date.

references

https://github.com/cloudposse/terraform-null-label/releases/tag/0.25.0
Supersedes and closes #187

/test all

/test all

/test all

/test all


NodeJS: Support for new protobuf loading

Also some small name changes to make things a little more readable.
This depends on:
https://github.com/googleapis/gax-nodejs/pull/146
https://github.com/googleapis/nodejs-proto-files/pull/16
Tested this on my local machine using the dependant PRs above as well as deleting the cloud file directory from the google-proto-files node_module (to ensure that the protos were coming from the client proto directory) and the smoke test works for vision!

Codecov Report

Merging #1561 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1561      +/-   ##
============================================
+ Coverage     87.03%   87.03%   +<.01%
  Complexity     4207     4207
============================================
  Files           408      408
  Lines         16883    16885       +2
  Branches       1834     1834
============================================
+ Hits          14694    14696       +2
  Misses         1697     1697
  Partials        492      492

Impacted Files
Coverage Δ
Complexity Δ

...sformer/nodejs/NodeJSImportSectionTransformer.java
95.45% <100%> (+0.45%)
5 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

The dependency version update will be to google-proto-files once we release a new package for it here. An update to grpc version is not necessary since the current version that is imported by gax already supports protobufjs v6 (source).


[WIP] [ENH] Add ability to reject epochs using callables

Reference issue
Example: Fixes ##11775.
What does this implement/fix?
Add ability to reject epochs using functions.
Ex: epochs = mne.Epochs(..., reject=dict(eeg=lambda x: True if np.median(x) > 1e-5 else False))

I am still working on this. Does anyone know of any good testing data that has massive amplitude spikes?

The testing dataset should have some spikes due to blinks but I'm not sure they'd qualify as massive. You can always create one using RawArray or EpochsArray, and it can end up being nice and readable/explicit that way.

Thanks @larsoner! I am getting ready to write a tutorial (and the test though this question applies to both) as per @drammock's suggestion. First, I wanted to ask is the way I generated sample bad data appropriate or should I use the source simulator class (I did not really know how to get the desired large amplitude spike easily)? Here is what I made:
data_path = mne.datasets.testing.data_path(download=False)
fname_raw_testing = data_path / "MEG" / "sample" / "sample_audvis_trunc_raw.fif"
raw = mne.io.read_raw_fif(fname_raw_testing)
raw.crop(0, 5)
raw.del_proj()
chans = raw.info['ch_names'][-6:-1]
raw.pick(chans)
data = raw.get_data()

new_data = data

# Make large spike
new_data[0, 180:200] *= 1e7

# Shift amp up to calculate median/mean later
new_data[0, 610:880] += 1e-3
edit_raw = mne.io.RawArray(new_data, raw.info)

Second, I wanted to include a section of the tutorial for including boolean operations such as:
epochs = mne.Epochs(edit_raw,
                    events,
                    tmin=0,
                    tmax=1,
                    baseline=None,
                    reject=dict(eeg=lambda x: True if ((np.max(x, axis=1) > 1).any() or
                                                       (np.median(x, axis=1) > 1e-3).any()) else False),
                    preload=True, verbose='DEBUG'
)

In the tutorial is it better to place the complicated lambda function in the construction or declare a new function like:
# Preparing a function for the 'reject' parameter
def reject_criteria(x):
    max_condition = np.max(x, axis=1) > 1
    median_condition = np.median(x, axis=1) > 1e-3
    return True if max_condition.any() or median_condition.any() else False

# Creating epochs with specified parameters
epochs = mne.Epochs(
    raw=edit_raw,
    events=events,
    tmin=0,
    tmax=1,
    baseline=None,
    reject=dict(eeg=reject_criteria),
    preload=True,
    verbose='DEBUG'
)

Third, I was wondering if instead of modifying reject and flat, it would be better to just create a new parameter reject_func as it may be confusing to a user if reject or flat can do the same thing depending whether you use > or <.
Thanks for the help! :)

First, I wanted to ask is the way I generated sample bad data appropriate

I think using SourceSimulator would be overkill and direct data modification is fine!

In the tutorial is it better to place the complicated lambda function in the construction or declare a new function like:

New function is better/clearer, probably added as a short new section in https://mne.tools/stable/auto_tutorials/preprocessing/20_rejecting_bad_data.html / https://github.com/mne-tools/mne-python/blob/main/tutorials/preprocessing/20_rejecting_bad_data.py

Third, I was wondering if instead of modifying reject and flat, it would be better to just create a new parameter reject_func as it may be confusing to a user if reject or flat can do the same thing depending whether you use > or <.

Good question. I think as long as we clarify in the doc that the callable could detect all sorts of stuff -- either too large or too small amplitudes -- and that what goes in drop_log reflects whether it came from reject or flat then it's fine.

Okay, I was just asking because I personally don't think I would ever use both if I was trying to specify a minimum and a maximum absolute value and would just use boolean operators. In the tutorial, is it fine if I use reject and booleans to specify the min/max or should I use both to show it is possible @larsoner?

I think as long as we clarify in the doc that the callable could detect all sorts of stuff -- either too large or too small amplitudes -- and that what goes in drop_log ref

I was looking over the documentation and I see the drop_log as 4 main reasons listed:

Currently, when you drop based on amplitude threshold (and my implementation) it just gives the channel name:

Can I add a new reason, 'REJECT_CRITERIA', for when you drop based on reject or flat that includes the function or value used to drop?
Also, should I keep the channel that had the bad item or just include the function?

@larsoner I think I am almost done with this. When you have a chance can you look over my comments and let me how you think I should address those problems. Thanks so much!

Update epochs.drop(...) to allow reason=... to be a list or tuple of reasons rather than a single string at some point. But doesn't have to be this PR unless you're really motivated.

From my testing it seems that you can pass a tuple to reasons:
import mne
import matplotlib.pyplot as plt
import numpy as np
import os

# sample_data_folder = mne.datasets.sample.data_path(download=True)
sample_data_raw_file = (
    "/home/woess/mne_data/MNE-sample-data/MEG/sample/sample_audvis_filt-0-40_raw.fif"
)
raw = mne.io.read_raw_fif(sample_data_raw_file)

raw.crop(0, 5)
raw.del_proj()
chans = raw.info["ch_names"][-5:-1]
raw.pick(chans)
data = raw.get_data()

new_data = data
new_data[0, 180:200] *= 1e3
new_data[0, 460:580] += 1e-3
edit_raw = mne.io.RawArray(new_data, raw.info)

# Create fixed length epochs of 1 second
events = mne.make_fixed_length_events(edit_raw, id=1, duration=1.0, start=0)

epochs = mne.Epochs(
    edit_raw,
    events,
    tmin=0,
    tmax=1,
    baseline=None,
    #reject=dict(eeg=lambda x: True if (np.max(x, axis=1) > 1e-3).any() else False),
    preload=True,
)
epochs.drop([0,2,3], ['bad', 'bad', 'bad'])
epochs.drop_log

Amend the epochs.drop_log attribute doc to mention that the entry can actually be some ch_name from epochs.ch_names as well when dropping based on flat or reject. This would be great and not too difficult to add to this PR, but not 100% necessary (I can create a new issue).

Sorry, I am a little confused, if I include this in the documentation does that mean it is not required for the callable return a good, reason tuple. Because if reason was required wouldn't that mean that the channel names that are currently outputted to the drop_log would always be replaced?

From my testing it seems that you can pass a collection to reasons so I just updated the documentation
...
epochs.drop([0,2,3], ['bad', 'bad', 'bad'])

Sorry, what I actually mean is that each reason can potentially be a tuple, e.g.:
epochs.drop([0, 2, 3], [('bad', 'MEG0111'), 'bad_too', ('a', 'b', 'c')])
```

> Sorry, I am a little confused, if I include this in the documentation does that mean it is not required for the callable return a good, reason tuple.

No I think the callable needs to return a `good, reason` tuple, and `reason` itself could also be a tuple of multiple reasons (or a `str` to mean one reason, equivalent to the one-reason tuple `(<str>,)`)

Sorry, what I actually mean is that each reason can potentially be a tuple, e.g.:

Ah okay, I think I understand my confusion.
So basically instead of epochs.drop([0, 2, 3], [('bad', 'a', 'b'), 'bad', ('bad', 'a')]) returning:
(([('bad', 'a', 'b'), 'bad', ('bad', 'a')],),
 (),
 ([('bad', 'a', 'b'), 'bad', ('bad', 'a')],),
 ([('bad', 'a', 'b'), 'bad', ('bad', 'a')],),
 ())

It would return:
(('bad', 'a', 'b'),
 (),
 'bad',
 ('bad', 'a')),
 ())

Got it!

Hey @larsoner! I haven't looked at this in a while, but I just updated the code so that drop behaves how you specified:

I also added conditionals to check to see if each element in the reject and flat dicts were a tuple/list(, <list, tuple, str>)
I have another question, which reason tuple should I use in the case of an epoch fulfilling the criteria of both reject and flat? Should I just use the reasons listed by one? Or combine them someway into a new tuple?

At the end of the day the reason needs to be a tuple of str, so if it satisfies both, you can just add the two tuples of str to get a single tuple of str. Looks like recent changes broke a lot of tests FYI

@withmywoessner do my suggestions make sense in terms of when tuple of str vs tuple of tuple of str are used etc.?

I believe so @larsoner  , It should work this, right?

I didn't implement that behavior for dropping using epochs constructor, just drop(). I will fix that now.

It should work this, right?

I was thinking no, because you can't tell whether .drop([0, 2, 3], ('bad_a', 'bad_b', 'bad_c')) means "use three reasons for each of 0, 2, and 3" or "use one reason for each of 0, 2, 3, corresponding to the three entries in the tuple).
I guess one way out of that is make it so that if a list or tuple is provided, it must be a list or tuple of list or tuple of str so the mapping is always explictly a list (one entry for each dropped index) of list of reasons.

It should work this, right?

I was thinking no, because you can't tell whether .drop([0, 2, 3], ('bad_a', 'bad_b', 'bad_c')) means "use three reasons for each of 0, 2, and 3" or "use one reason for each of 0, 2, 3, corresponding to the three entries in the tuple).
I guess one way out of that is make it so that if a list or tuple is provided, it must be a list or tuple of list or tuple of str so the mapping is always explictly a list (one entry for each dropped index) of list of reasons.

The way I intended it was that if you pass just a string it applies that string to every drop_log entry like this:

But if you pass a tuple or a list, it does what I specified above.
I'll do what you think is best though!

Yes I think single str broadcasting to tuple of tuple of that one str is fine, then supporting only tuple-like of tuple-like of str and not tuple-like of str (as this case can be ambiguous) seems okay!
And at the end of the day epochs.drop_log should always be tuple of tuple of str

Yes I think single str broadcasting to tuple of tuple of that one str is fine, then supporting only tuple-like of tuple-like of str and not tuple-like of str (as this case can be ambiguous) seems okay!
And at the end of the day epochs.drop_log should always be tuple of tuple of str

I may be fixating one this too

Yes I think single str broadcasting to tuple of tuple of that one str is fine, then supporting only tuple-like of tuple-like of str and not tuple-like of str (as this case can be ambiguous) seems okay!
And at the end of the day epochs.drop_log should always be tuple of tuple of str

Maybe its just simpler to only allow a tuple of str or str? And not allow tuple of tuple of string. I think that matches the original functionality of reason better which currently only allows str, but I'll leave it alone if you think otherwise.

Maybe its just simpler to only allow a tuple of str or str? And not allow tuple of tuple of string. I think that matches the original functionality of reason better which currently only allows str, but I'll leave it alone if you think otherwise.

This would be okay, too, if that tuple of str is used as the reason for all dropped indices, like:
epochs.drop([0, 2, 3], ('a', 'b', 'c'))

yields
epochs.drop_log == (('a', 'b', 'c'), (), ('a', 'b', 'c'), ('a', 'b', 'c'))

Yields
epochs.drop_log == (('a', 'b', 'c'), (), ('a', 'b', 'c'), ('a', 'b', 'c'))

Is this okay?
epochs.drop([0, 2, 3], ('a', 'b', 'c'))
Yields
epochs.drop_log == (('a',), (), ('b',), ('c',))

I don't like that one because currently the way it works is you give one reason, it's applied to all indices. In your suggestion, you are allowed to give a different single reasons for different indices. But there is no way to give multiple reasons for any indices.

Maybe I just don't understand the benefit of giving multiple reasons as a tuple. I would assume that if someone is manually specifying something they would want it to be considered one reason.
I just wanted to include something that allowed you to give a different reason for each epoch, but I guess you can just call drop multiple times anyway.
I think I have wasted too much time on this so I will just defer to you. Thanks for the clarification!!

Maybe I just don't understand the benefit of giving multiple reasons as a tuple. I would assume that if someone is manually specifying something they would want it to be considered one reason.

I'm thinking of something like ('bad_ch_1', 'bad_ch_2', 'bad_blink') or whatever being useful in the drop log, just like having a list of channel names from reject/flat could be.

I just wanted to include something that allowed you to give a different reason for each epoch, but I guess you can just call drop multiple times anyway.

Yes exactly! I think this case is easily done within a loop just like it has to be in main currently. Hence the tuple of str meaning "use this tuple of reasons for all indices" extends functionality in a way there is no workaround/other workflow for currently I think.

... although I guess we could do something like what you propose if we say:
reason : str | list or tuple of str | list or tuple of list or tuple of str
    The reason for drops. If list or tuple, must have same length as `drops`,
    and each entry will be the reason (or list/tuple of reasons) for each
    index's drops

then I guess the case of
epochs.drop([0, 1, 2], ('a', 'b', 'c'))

will behave like you suggest, and is unambiguous at least from a docstring perspective. And the behavior I want can easily be achieved with
epochs.drop([0, 1, 2], [('a', 'b', 'c')] * 3)

So if you want to go this direction intead, that would work! And apologies if this is what you already have, I should have thought this through a bit further probably 😬

Done! Thanks so much for all your help! @larsoner Maybe this can be another PR, but one thing I realized is that I didn't include something to check if the callable returns a valid properly formatted tuple if preload=False. I don't think this is possible as it requires me to actually call it. I tried including a warning when you pass a callable and preload = False, but for whatever reason I couldn't get the proper truth value of preload. Do you think this is something I need to add in this or a seperate PR? Again thanks so much for the help!

Maybe this can be another PR, but one thing I realized is that I didn't include something to check if the callable returns a valid properly formatted tuple if preload=False

Ohh, because it's not called right away, right? This actually raises a potential issue -- we don't want epochs.reject to ever be anything other than a dict (mapping str keys to float vals) or None, and it will be after this if you allow these to be passed in the Epochs constructor. This will make it so we can't write epochs to disk anymore. See for example in your tutorial if I add a epochs.save('test-epo.fif'):
Traceback (most recent call last):
  File "/home/larsoner/python/mne-python/tutorials/preprocessing/20_rejecting_bad_data.py", line 383, in <module>
    epochs.save("test-epo.fif")
  File "<decorator-gen-199>", line 12, in save
  File "/home/larsoner/python/mne-python/mne/epochs.py", line 2226, in save
    over_size += len(json.dumps(reject_params)) + 16
                     ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/encoder.py", line 258, in iterencode
    return _iterencode(o, 0)
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/json/encoder.py", line 180, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type function is not JSON serializable

To fix this problem and the output-not-checked problem, rather than supporting callables in the constructor Epochs.__init__, we could just support callables in epochs.drop_bad. In other words, this should work (which doesn't currently):
>>> import mne
>>> raw = mne.io.read_raw_fif(mne.datasets.sample.data_path() / "MEG" / "sample" / "sample_audvis_raw.fif")
>>> epochs = mne.make_fixed_length_epochs(raw)
>>> epochs.drop_bad(reject=dict(eeg=lambda x: (x.max() > 1e-5, "bad")))

Whereas Epochs(..., reject=dict(eeg=lambda x: ...)) should not.
Then we can modify epochs.reject within def drop_bad so that saving will work. And the correctness will be checked right away, because .drop_bad operates immediately (does not wait until later).
To do this I think you can keep most of what you changed, but modify def _reject_setup(reject, flat, *, allow_callable=False) as the signature so that when it's called in __init__ it won't allow callables, but then in drop_bad it calls it with self._reject_setup(reject, flat, allow_callables=True), and then after the call to self._get_data it removes the keys in self.reject and self.flat that were callables. WDYT?
Another option I guess would be to make it so that on save we check the reject and flat and remove the callables then instead, which would probably be okay, too. Then the output correctness won't get checked right away, though.

Yes it's possible to check preload. But if you go the .drop_bad(...)-only route it's not necessary. It will go through and load each epoch from raw on demand (or from ndarray if it's preloaded) and decide whether to keep or reject it. So maybe it's cleaner to use that rather than try to support it in __init__(...) with some processing delayed until later.
Would supporting just .drop_bad(...) work for your use case?

Yes @larsoner! I think I might write new docustrings for drop_bad because it currently it shares docustrings with reject and flat in the constructor of Epochs. I think it would be confusing if this functionality was mentioned in the docustrings for both.

Hey @larsoner, just pinging here. I think everything should be ready finally. Thanks so much for helping me with this :)

maybe I'm misunderstanding something, but it looks like Circle's build_docs job passed in 8 seconds (?!) on the last commit of this PR, and didn't actually build the docs... which are now failing on #12411 with
/home/circleci/project/mne/epochs.py:docstring of mne.epochs.drop_bad:49: WARNING: Explicit markup ends without a blank line; unexpected unindent.

@larsoner any idea why we got a false-positive pass from Circle here?

Looks like for some reason it ran on his fork rather than our project. Not sure why

Looks like for some reason it ran on his fork rather than our project. Not sure why

https://support.circleci.com/hc/en-us/articles/360008097173-Troubleshooting-why-pull-requests-are-not-triggering-jobs-on-my-organization
Is this the reason why? @larsoner @drammock

A user who submits a pull request to your repository from a fork, but no pipeline is triggered with the pull request. This can happen when the user is following the project fork on their personal account rather than the project itself on CircleCI.

In these cases, the user unfollows their fork of the project on CircleCI. This will trigger their jobs to run under the organization when they submit pull requests. Those users can optionally follow the source project if they wish to see the pipelines.

I clicked unfollow.

I clicked unfollow.

thanks! hopefully that will fix it for your next PR.

I think what is supposed to happen is that if you create a CircleCI account that is linked to your GH account (maybe they always are?) then Circle will run the job automatically as long as it's not your first PR in the MNE-Python repo.  But to be honest I haven't really had time to look into the situation / failures very carefully.  Maybe I should create a new GH account so I can try it out / experience the rejection myself, and then document the fix 😆

I don't know :(  I just poked around in the admin interface and I see no list of "members" and no way to "add" people...  your list of organizations looks odd though (mine lists various user's names with images, and various named orgs, but no hash-like codes like cci-3rq7p like yours does). Do you see a link at the bottom of that dropdown saying "Can't find an organization? Check permissions"

Yes,

I click that and it takes me here:

I click, 'check permissions...' and it takes me:

Is there anything linking your CircleCI account to the mne-python public repo on your CircleCI account page? I don't see anything like that on mine.
Thanks for looking into this!

ok, IIUC they are using GitHub users & organizations as their source of "organizations" and since you're not a member of https://github.com/orgs/mne-tools you shouldn't expect to see "mne-tools" as an option within CircleCI. But since I am a member, I do see "mne-tools" as an org within CircleCI (along with other orgs I'm part of: pydata, sphinx-gallery, etc).
So I think that part at least is working as expected? (I don't see any orgs listed on your GitHub profile so it makes sense you wouldn't see any within CircleCI).  But I think (?) this shouldn't prevent the jobs from running; hopefully it was the "follow" setting that you've just changed; we'll know on your next PR I guess.

Hopefully, @drammock 😬. Is there a way to change where CircleCI is run from in an existing PR?
Looking at my open PR #12392. I just merged the branch and it still says the tests are being run from my branch:

Compared to this one from #12382:

It also has a different icon in the top left and says 'mne-tools' when I clicked on it.

#12392 looks correct to me:

not sure why you're seeing something different. To get to that page I clicked on the "Details" link on #12392:

It looks good now. Maybe I just clicked it too early. Thanks!


Show all deprecation instances (#16688)

Fixes #16688
Context
Without this PR only the first finding of a concrete deprecation
warning is shown. This means you can only fix one after the other and
also only see own violations if all plugins were fixed.
With this PR all instances of a deprecation warning are shown
as long as they come from different locations.
The printed stack information is simply included in the
message deduplication that previously only contained the message itself.
Example before:
$ ./gradlew foo foo2 bar baz
> Task :foo
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 8.0. Consult the upgrading guide for further information: https://docs.gradle.org/7.5.1/userguide/upgrading_version_7.html#task_project
        at FooTask.foo(FooTask.kt:7)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)

> Task :foo2
> Task :bar
> Task :baz

BUILD SUCCESSFUL in 1m 37s

Example after:
$ ../gradle/build/install/bin/gradle foo foo2 bar baz
> Task :foo
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 8.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.0-20221023202731+0000/userguide/upgrading_version_7.html#task_project
        at FooTask.foo(FooTask.kt:7)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)

> Task :foo2

> Task :bar
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 8.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.0-20221023202731+0000/userguide/upgrading_version_7.html#task_project
        at BarTask.bar(BarTask.kt:7)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)

> Task :baz
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 8.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.0-20221023202731+0000/userguide/upgrading_version_7.html#task_project
        at Foo_gradle$1$1.execute(foo.gradle.kts:18)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)

BUILD SUCCESSFUL in 2m 19s

Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
n/a Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[x] Verify design and implementation
[x] Verify test coverage and CI build status
[x] Verify documentation
[ ] Recognize contributor in release notes

@bot-gradle test QFL

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

@bot-gradle test QFL

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

@Vampire, after reviewing your PR the conclusion is that your reasoning and changes make sense, BUT you implemented them in an overly generic way. I would say that this behavior should happen only when --warning-more=all is used and not for any other warning mode values.
Also, pls. keep an eye out for other tests that are failing with your changes, see above failures on TC (just log in as guest).

Thanks for the heads-up.
I do not fully agree though.
It should also be done for fail as they are also all printed, and additionally the build fails.
I think the correct behavior is to do it for warningMode.shouldDisplayMessages() == true and just have a separate boolean for the summary case.
I'll do it like that and you can have another look then, after I also checked the failing tests.

I pushed a new version with the changes and the failed tests fixed

@bot-gradle test QFL

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@eskatos I fixed the failing test, please trigger another build. :-)

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

No milestone for this PR. Please set a milestone and retry.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.

@jbartok this is release notes worthy IMO


Switch to Getthermostatsdata, Gethomedata and Getstationsdata by November 30th

I got this info today:
Friendly reminder: Getthermstate, Getuser and Devicelist will move from deprecated to shut down. On November 30th, we are proceeding to a structural change to make our APIs faster and more powerful. Unfortunately, old and deprecated API methods won’t be supported anymore. Make sure you amend your code and start using newer methods as soon as possible for a smooth transition:
Replace Getthermstate with Getthermostatdata
Replace Getuser with Getthermostatdata, Gethomedata or Getstationsdata
Replace Devicelist with Getthermostatdata or Getstationsdata
So it looks like, there are some updates required.
I already implemented the netatmo welcome

Thanks for the notice.We already have the new methods.
Getthermstate, Getuser and Devicelist are marked as "deprecated". Once Neattmo shuts them down it will be easy to remove them

I hope openHAB uses the new methods.
cc @clinique

I already spend a Issue on Openhab2-addons for this, so if all is in the api, i could close this issue here?

We can keep it to remember to remove the old ones.

@cbornet , yes I made the switching


added welcome bot

issue no: #24

@kritikaparmar-programmer

@kritikaparmar-programmer @manan-bedi2908  please review this pr and also please add gssoc21 and level tags to both issue and pr

fixes #24


Review 10mn policy for expenses

In Expenses, there is a 10 min policy:

// admin of collective can reject the expense for up to 10mn after approving it
// we can approve an expense for up to 10mn after rejecting it

See:
https://github.com/opencollective/opencollective-frontend/blame/cfa9224074bc25fc569a99313102a2446624994a/src/apps/expenses/components/Expense.js#L121
Should we reconsider this?

What is the purpose of this 10 min policy? And how does it work in practice?

What is the purpose of this 10 min policy?

I have no idea. It was implemented more than 2 years ago.

And how does it work in practice?

If I understand well:

it prevents a collective admin to change their mind and reject an expense 10 minutes after it was approved
it prevents a collective admin to change their mind and approve an expense 10 minutes after it was rejected

I'm not aware of anyone using this and I haven't used it myself. I think we should allow unapprove and unreject at any time by admins anyway.

@alanna Was also surprised to see that, and surprised no one had complained ever? We we'll remove this behavior.

I think we can safely remove.

This should be done.

The new expense page doesn't implement this behavior, I think we can safely close.

@Betree We need to delete the old components.

The behavior has been deprecated in the new flow and old components are removed


Add ability to specify the :precision option

Followup to our twitter conversation earlier today: https://twitter.com/pete_higgins/status/747861010359402496
I am switching a rails app from using sass-rails to sassc-rails and looking for differences in the compiled CSS between the two. I noticed that sass has many more degrees of precision from the results of doing math in sass than sassc does. Sass has the option to specify the precision, which bootstrap-sass relies on: https://github.com/twbs/bootstrap-sass/blob/0a64ad76107e0363e0d504287c0f9b88c6679399/lib/bootstrap-sass.rb#L64-L65 This means that whne using sassc some of the derived values have a much lower precision which can lead to small differences cropping up, as mentioned in the issue linked to in the bootstrap-sass documentation above. Even if there are no visible differences, since I am switching from sass-rails to sassc-rails, I'd feel more confident that nothing was going to change between the two of them if their compiled CSS was the same, minus whitespace differences, etc.
For now I've been able to change the precision with sassc-rails by adding a monkeypatch like this to my project, which is not ideal:
if defined?(SassC)
  SassC::Engine.include Module.new do
    def precision
      super || 8
    end
  end

Would be great if #85 could be merged.

@phiggins For your workaround to work, you need to use prepend instead of include:
# config/initializers/sassc.rb
require 'sassc'

SassC::Engine.prepend(Module.new {
  def precision
    super || 10
  end
})

Also due to missing parenthesis what you're actually calling is Engine.include(Module.new) do .. end which does nothing at all.

This works as well:
# config/initializers/sassc.rb

if defined?(SassC)
  class SassC::Engine
    def precision
      8
    end
  end
end


Want to Add CSS Animation

Feature Type:

Add Earth and Saturn Rotatory Effect using CSS Animation.
It will be a Fun Project.

@Avik-creator first make the template from ur own and show us the ss or video if we think its up to the make then we will assign u

It will be like this.
This will not how the final project will look like.
It will have two different planets and different rotations.
I am doing this by seeing this tutorial.
https://youtu.be/ib8AYFCZtdk?t=16

What are the changes requested ma'am ?
@VidhiBhatt01
Please Clarify so that I could make it.

None none, I just removed the label. You can go on and work on it


Build fails after recent changes in build.sbt

The following instructions should just work:
$ find $HOME/.ivy2 -type d -name '*scala-native*' | xargs rm -r -f
$ sbt clean package nativeLink

Observe that I'm making sure that we clean whatever we have in the local Ivy repository before we start. This is a critical step! i.e: always, always! make sure we build from a clean slate!
People trying Scala Native for the first time will be building their first app from a completely clean slate. So we must guarantee we test our build from a complete clean slate.
By the way, it's critical that the documentation is always in sync with the build script. Otherwise, people trying Scala Native for the first time will have troubles, will not be able to fix it (obviously, since they are complete newbies on the matter!) and will end up asking things in the gitter room.
In other words, before commiting changes, the entire build must be performed in a clean slate. If things fail (which is the case at the moment), the change cannot be pushed onto the repository otherwise new users (and even regular users!) will be doomed to face troubles.

CC: @densh @andreaTP

The build fails like this below:
$ find $HOME/.ivy2 -type d -name '*scala-native*' | xargs rm -r -f
$ sbt clean package nativeLink
...
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: org.scala-native#nativelib_2.11;0.1-SNAPSHOT: not found
[warn]  :: org.scala-native#javalib_2.11;0.1-SNAPSHOT: not found
[warn]  :: org.scala-native#scalalib_2.11;0.1-SNAPSHOT: not found
[warn]  :: org.scala-native#nscplugin_2.11.8;0.1-SNAPSHOT: not found
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]
[warn]  Note: Unresolved dependencies path:
[warn]          org.scala-native:nativelib_2.11:0.1-SNAPSHOT ((scala.scalanative.sbtplugin.ScalaNativePluginInternal) ScalaNativePluginInternal.scala#L62)
[warn]            +- default:scala-native-example_2.11:0.1-SNAPSHOT
[warn]          org.scala-native:javalib_2.11:0.1-SNAPSHOT ((scala.scalanative.sbtplugin.ScalaNativePluginInternal) ScalaNativePluginInternal.scala#L62)
[warn]            +- default:scala-native-example_2.11:0.1-SNAPSHOT
[warn]          org.scala-native:scalalib_2.11:0.1-SNAPSHOT ((scala.scalanative.sbtplugin.ScalaNativePluginInternal) ScalaNativePluginInternal.scala#L62)
[warn]            +- default:scala-native-example_2.11:0.1-SNAPSHOT
[warn]          org.scala-native:nscplugin_2.11.8:0.1-SNAPSHOT ((sbt.BuildExtra) Defaults.scala#L1961)
[warn]            +- default:scala-native-example_2.11:0.1-SNAPSHOT

I suppose it has something to do with removed lines:
      compilerPlugin("org.scala-native" %  "tools_2.10" % "0.1-SNAPSHOT"),
      compilerPlugin("org.scala-native" %  "nir_2.10"   % "0.1-SNAPSHOT"),
      compilerPlugin("org.scala-native" %  "util_2.10"  % "0.1-SNAPSHOT"),

For your information, the original project in my account builds properly as per its documentation in the README.md. http://github.com/frgomes/scala-native-example

I've reviewed the documentation and build.sbt so that users following the old procedure of building Scala Native first and only after that, building the example application... these users will succeed.

I'm looking at the issue right now, I suspect that https://github.com/scala-native/scala-native/pull/230 should fix this, but we need wait a bit for main repo to update latest snapshot.

Seems to be fixed now:
# find $HOME/.ivy2 -type d -name '*scala-native*' | xargs rm -r -f
# sbt clean nativeLink
[info] Loading project definition from /Users/Denys/.src/native-example/project
[info] Updating {file:/Users/Denys/.src/native-example/project/}native-example-build...
[info] Resolving org.scala-native#sbtplugin;0.1-SNAPSHOT ...
[warn] Unable to reparse org.scala-native#sbtplugin;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:20 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#sbtplugin;0.1-SNAPSHOT
[info] Resolving org.scala-native#tools_2.10;0.1-SNAPSHOT ...
[warn] Unable to reparse org.scala-native#tools_2.10;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:17 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#tools_2.10;0.1-SNAPSHOT
[info] Resolving org.scala-native#nir_2.10;0.1-SNAPSHOT ...
z[warn] Unable to reparse org.scala-native#nir_2.10;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:15 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#nir_2.10;0.1-SNAPSHOT
[info] Resolving org.scala-native#util_2.10;0.1-SNAPSHOT ...
^[[warn] Unable to reparse org.scala-native#util_2.10;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:13 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#util_2.10;0.1-SNAPSHOT
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/sbtplugin_2.10_0.13/0.1-SNAPSHOT/sbtplugin-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#sbtplugin;0.1-SNAPSHOT!sbtplugin.jar (652ms)
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/tools_2.10/0.1-SNAPSHOT/tools_2.10-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#tools_2.10;0.1-SNAPSHOT!tools_2.10.jar (1057ms)
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/nir_2.10/0.1-SNAPSHOT/nir_2.10-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#nir_2.10;0.1-SNAPSHOT!nir_2.10.jar (750ms)
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/util_2.10/0.1-SNAPSHOT/util_2.10-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#util_2.10;0.1-SNAPSHOT!util_2.10.jar (555ms)
[info] Done updating.
[info] Set current project to native-example (in build file:/Users/Denys/.src/native-example/)
[success] Total time: 0 s, completed Jul 7, 2016 3:06:21 PM
[info] Updating {file:/Users/Denys/.src/native-example/}native-example...
[info] Resolving org.scala-native#nativelib_2.11;0.1-SNAPSHOT ...
[warn] Unable to reparse org.scala-native#nativelib_2.11;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:15 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#nativelib_2.11;0.1-SNAPSHOT
[info] Resolving org.scala-native#javalib_2.11;0.1-SNAPSHOT ...
[warn] Unable to reparse org.scala-native#javalib_2.11;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:16 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#javalib_2.11;0.1-SNAPSHOT
[info] Resolving org.scala-native#scalalib_2.11;0.1-SNAPSHOT ...
[warn] Unable to reparse org.scala-native#scalalib_2.11;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:18 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#scalalib_2.11;0.1-SNAPSHOT
[info] Resolving org.scala-native#nscplugin_2.11.8;0.1-SNAPSHOT ...
[warn] Unable to reparse org.scala-native#nscplugin_2.11.8;0.1-SNAPSHOT from sonatype-snapshots, using Thu Jul 07 15:05:14 CEST 2016
[warn] Choosing sonatype-snapshots for org.scala-native#nscplugin_2.11.8;0.1-SNAPSHOT
[info] Resolving jline#jline;2.12.1 ...
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/nativelib_2.11/0.1-SNAPSHOT/nativelib_2.11-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#nativelib_2.11;0.1-SNAPSHOT!nativelib_2.11.jar (1151ms)
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/javalib_2.11/0.1-SNAPSHOT/javalib_2.11-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#javalib_2.11;0.1-SNAPSHOT!javalib_2.11.jar (1088ms)
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/scalalib_2.11/0.1-SNAPSHOT/scalalib_2.11-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#scalalib_2.11;0.1-SNAPSHOT!scalalib_2.11.jar (2500ms)
[info] downloading https://oss.sonatype.org/content/repositories/snapshots/org/scala-native/nscplugin_2.11.8/0.1-SNAPSHOT/nscplugin_2.11.8-0.1-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] org.scala-native#nscplugin_2.11.8;0.1-SNAPSHOT!nscplugin_2.11.8.jar (625ms)
[info] Done updating.
[info] Compiling 1 Scala source to /Users/Denys/.src/native-example/target/scala-2.11/classes...
warning: overriding the module target triple with x86_64-apple-macosx10.11.0 [-Woverride-module]
1 warning generated.
[success] Total time: 14 s, completed Jul 7, 2016 3:06:36 PM


User specified lighting

Added user specified lighting, it will be pushed to the sprint during the STIG viewer push.


footer: Add Linux Foundation footer

As requested on https://github.com/cncf/toc/issues/532

As requested on cncf/toc#532

I see... well, the content is fine, but so much text is maybe a bit too big? Maybe we could add this modification to the style:
diff --git a/_sass/_footer.scss b/_sass/_footer.scss
index 3b2f9d4..d61bf97 100644
--- a/_sass/_footer.scss
+++ b/_sass/_footer.scss
@@ -1,4 +1,5 @@
 .mk-main-footer {
     border-top: var(--mk--BorderWidth--sm) solid var(--mk--BorderColor--300);
+    font-size: var(--mk--FontSize--xs);
     padding: var(--mk--spacer--lg) var(--mk--spacer--md);
 }

WDYT? I tested it locally and it looks a bit better to me...

@codificat thanks for the tip!  I've included that change.  Let's see how the netlify preview looks now ...

@codificat thanks for the tip! I've included that change. Let's see how the netlify preview looks now ...

yes, that looks better to me!  thanks again

Cool. Ship it.
/lgtm
/approve


Drawer edge swipe convers entire screen

When I tightened up the layout constraints for the Drawer in the
Scaffold, I ended up making the edge swipe detector cover the entire
screen.  This patch fixes that issue by putting the gesture detector for
the edge swipe just around the container with the proper width. We now
use a global key to maintain the state across hierarchy changes.

@Hixie @chinmaygarde

before you land this — have you seen the router assert? any idea what causes it?

I saw there was a bug on it.  Haven't looked in detail yet.

I only mention it because I'm guessing this is an underlying trigger for that bug, and it would be a shame to remove the trigger before tracking down the other bug.
Looking at this patch now.

LGTM.

I'm going to land this patch.  I'll take a look at the assert separately (even if I have to go back in time).


Got error with BuildCoinfig.class after updating to 2.0.0

ERROR:/Users/.gradle/caches/transforms-3/bb8cae490f23f768812abb34c4b78de0/transformed/jetified-android-1.16.3-runtime.jar: R8: Type com.segment.analytics.BuildConfig is defined multiple times: /Users/rasul/.gradle/caches/transforms-3/bb8cae490f23f768812abb34c4b78de0/transformed/jetified-android-1.16.3-runtime.jar:com/segment/analytics/BuildConfig.class, /Users/build/segment_analytics/intermediates/runtime_library_classes_jar/debug/classes.jar:com/segment/analytics/BuildConfig.class
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:minifyProdDebugWithR8'.

A failure occurred while executing com.android.build.gradle.internal.tasks.R8Task$R8Runnable
Compilation failed to complete, origin: /Users/.gradle/caches/transforms-3/bb8cae490f23f768812abb34c4b78de0/transformed/jetified-android-1.16.3-runtime.jar:com/segment/analytics/BuildConfig.class

Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 42s
Error: Gradle task assembleProdDebug failed with exit code 1

environment:
sdk: ">=3.2.0"
segment_analytics: ^1.1.2
customer_io: ^2.0.0

Hey @rassl11, thank you for reaching out, and apologies for the inconvenience. It seems like there is an incompatibility issue with the Segment flutter plugin, we are looking into it.


Using Test-SecretVault, can we suppress the password prompt?

Hello,
This is a great module, was using PoshKeePass for awhile but it does not work with PS7 due to this. This module seems to work just fine as an alternative.
Is it possible to call Test-SecretVault without getting a password prompt when the vault is NOT unlocked?
I want to test (true or false) if a connection is valid, without any password prompts.

What about using Get-SecretVault which doesn't require a pw?

+1 : I agree with this issue.
According to this page : SecretManagement Module

The Test-SecretVault cmdlet should write all errors that occur during the test. But only a single true/false boolean should be written the the output pipeline indicating success.

The prompt to open database should be removed in this cmdlet.

By design, the keepass database cannot be accessed without being unlocked first.
If you want to unlock in your script, you can do:
Unlock-SecretVault -Name YourVaultName -Password $PASSWORD
Of course, it's recommended to have your vault password encrypted in a secure string first and just load it first:
$PASSWORD = (Import-Clixml -Path "C:\Path\Path\Password.xml").Password

I want to support this issue, because I have been trying to implement a reliable way to
a) Unlock the DB if there is a key provided by the user/function already
b) Prompt the user for the key if none is provided yet
c) If the DB is unlocked, never prompt the user for reentry
This is currently impossible, because I can not check c without immediately triggering this built in credential prompt when a is false. In my opinion, the correct behavior for Test-SecretVault would be to just return locked and that's it.
There also is a related problem with the way master PWs are cached, because they even survive an unregister, making it so that as long as you ever used any unlock on a keepass db, the prompt will be surpressed until a completely new PS session is started. The cached key should be removed no later than when the db is unregistered. It would probably be better to also provide Lock-SecretVault.

Oh also if wanted, I'm happy to provide pull requests for these changes, I didn't see any indication about wanting singular contributions to the repository.


Add components section

This is a chapter on Blazor components specifically catered toward ASP.NET Web Forms developers. It pulls much of its content from the components topic in the Blazor docs, but tries to relate those concepts to server controls in ASP.NET Web Forms.

What about NotifyStateChange? I found I had to call that a lot when updating variables but maybe that's been updated in later previews.

Good point! I'll add something about that.


error

Hello,
I'm trying to differ these two kind of error:
-Error authenticating user username: LDAP Result Code 200 "Network Error": dial tcp x.y.z.w:389: i/o timeout
-Error authenticating user username: LDAP Result Code 49 "Invalid Credentials": 8009030C: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580
i'd like to map in this way:
timeout -> 500
"Invalid Credentials" -> 4xx
the problem is, in both case, err is not null,
thanks

It may not help but with the ldap return codes you would be better off sticking with what you get as they are mostly defined in the LDAP RFC so your error 49 has different reasons that can be worked out by the data code.


Fix gunicorn issues and subrocess return value such that client can now obtain the HTML response.

Hi @nicholascar
This is a small PR which cleans up some issues with regards to running pyLODE (via Falcon) as a service.
This now works perfectly.
I am standing up pyLODE on the ESIP COR machine at cor.esipfed.org/pylode so it will be available probably later today. If you could review and merge this request it would be appreciated.

Maybe we could add commentary on running as a background process ?
cd /path/to/pyLODE && gunicorn -b <IP_ADDRESS>:8080 --chdir /path/to/pyLODE/pylode server:api &

@lewismc I'll merge this in now as you want it ASAP and we can then patch up the other issues next
Thanks for the contribution!


how to isolate a single "Text" plugin instance and wrap it with an arbitrary css class?

Hello, I have a simple requirement -- I want to inject a className into the div that wraps the slate editor seen here: https://github.com/ory/editor/blob/master/packages/plugins/content/slate/src/Component/index.js#L74
In my copy of this file, I've changed that line to read:
<div className={editorState.document.data.cssClasses}>
I've added an ORY editor plugin that is added to the bottom toolbar when a "Text" plugin is active.  The plugin allows one to add one or more css class names and then press an "Update" button to perform a transform().apply() on editorState.  I'm saving this string to editorState.document.data.cssClasses.
This all works great for a single "Text" plugin.  When there are multiple "Text" plugins on the page, changing editorState.document.data.cssClasses will update all "Text" plugins.
Now, conceptually, this is how I would expect behavior to be since I'm modifying the document data (and I'm assuming a document represents all "Text" plugins on the page). I chose to save the data to that location because it looked like each instance of "Text" plugin had its own unique numeric key when looking at editorState.  Furthermore, when I inspect the generated DOM, it looks like the div I mentioned above is being duplicated for each instance of the Text plugin (since each instance sits in its own cell).
Basically, I'm a bit confused as to the proper way to accomplish this use case:

fresh editor is loaded (with a single "Text" plugin saying "Write here..." -- call this TextA)
user enters "Add" mode
user adds a second "Text" plugin to the page (call this TextB)
user enters "Edit" mode
user edits TextA to say "TEST A"
user edits TextB to say "TEST B"
user places cursor in TextA to bring up settings toolbar for TextA
user enters "style1" in the cssClasses textbox in the toolbar and presses update
TextA now has "style1" added to the div className referenced above
user places cursor in TextB to bring up settings toolbar for TextB
user enters "style2" in the cssClasses textbox in the toolbar and presses update
TextB now has "style2" added to the div className referenced above

Here's what's actually happening:

fresh editor is loaded (with a single "Text" plugin saying "Write here..." -- call this TextA)
user enters "Add" mode
user adds a second "Text" plugin to the page (call this TextB)
user enters "Edit" mode
user edits TextA to say "TEST A"
user edits TextB to say "TEST B"
user places cursor in TextA to bring up settings toolbar for TextA
user enters "style1" in the cssClasses textbox in the toolbar and presses update
TextA now has "style1" added to the div className referenced above
user places cursor in TextB to bring up settings toolbar for TextB
TextB is immediately redrawn upon focus and the div referenced above reads "style1"

What is your recommendation?
Thanks,
Paul

Hm that is weird, editorState.document.data.cssClasses should not change for all text instances at once, only for the one which is updated. Is it possible that, for some reason, multiple cells have the same ID? You can check that by logging the onChange callback in <Editor onChange=...>.

Could you also show how you handle the cssClasses update?

Here is my plugin code to handle the cssClass update: https://gist.github.com/paulkoanui/0bcf840af39e3c1a72e432bc8fed74ff
in Component.js,
I'm injecting the css class names here: https://gist.github.com/paulkoanui/0bcf840af39e3c1a72e432bc8fed74ff#file-component-js-L75
Here's a video of what I'm seeing: https://drive.google.com/file/d/0B_gV2WNeE-p5YjJRSXdrblVqalE/view
In that video, what you see in the console is logged here:
https://gist.github.com/paulkoanui/0bcf840af39e3c1a72e432bc8fed74ff#file-component-js-L34
Should there be a value for __ownerID?

Oh ok I think I know what the issue is. The editorState is actually a slate state meaning that you should not mess with it. Instead, you could use another key (e.g. cssClass) in state, so e.g.:
    const {
      focused,
      readOnly,
      state: { editorState, cssClasses },
      // ...
} = this.props

Cool, thanks for the tip!  I took your advice and it worked a charm.

Perfect, I'm glad you got it working!

I'm having one more issue on this topic.  Given your suggestion to add another key "cssClasses" to the state that will track my additional state, how do you serialize this? From looking at the slate plugin's reducer it seems like this should be happening automatically.  Any advice?

yes this should happen automatically iirc

Aloha,
I took your suggestion and it worked great.  I've been able to extend the functionality of the ory-editor very easily after getting my bearings.  Excellent project!
Thanks,
Paul


feat(web) - various UI improvements

disable the change set abandon button while on HEAD
prevent users from naming a change set "head" (on the front end only)
add map item error message if you try to add an item without a key
AssetActionDetails UI more closely matches the rest of the UI
hover states for clickable diff icons on the diagram and ComponentCard
"No Code" message in AssetDiffDetails shows outside of a CodeViewer

bors merge


Fix error on startup when using MESSAGEQUEUE_ENABLED

MQBot's first argument is the message queue but the token was sent to it. And in addition to that, the message queue was set via the keyword argument mqueue. This resulted in a:
TypeError: __init__() got multiple values for argument 'mqueue'

Codecov Report

Merging #35 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master      #35   +/-   ##
=======================================
  Coverage   41.84%   41.84%
=======================================
  Files           9        9
  Lines         325      325
=======================================
  Hits          136      136
  Misses        189      189

Impacted Files
Coverage Δ

django_telegrambot/apps.py
52.02% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Adjust docker image for yaobank manifest

Description
Adjust docker image for yaobank manifest.
Related issues/PRs
https://github.com/projectcalico/calico/pull/3720
Release Note
None required

Deploy preview for calico ready!
Built with commit 932e1d4999c1790ce0ead956722e477c2ee6ce45
https://deploy-preview-3723--calico.netlify.app


Improve cache context

Related to: #22294 #23186 #23054
Replace: #23218
Some discussion is in the comments of #23218.
Highlights:

Add Expiration for cache context. If a cache context has been used for more than 10s, the cache data will be disabled, and warning logs will be printed.
Add discard field to cacheContext, a cacheContext with discard true will drop all cached data and won't store any new one.
Introduce WithNoCacheContext, if one wants to run long-life tasks, but the parent context is a cache context, WithNoCacheContext(perentCtx) will disable and CLEAN the cache data, so it will be safe to keep the context for a long time.
It will be fine to treat an original context as a cache context, like GetContextData(context.Backgraud()), no warning logs will be printed.

Some cases about nesting:
When:

A, B or C means a cache context.
~A~, ~B~ or ~C~ means a discard cache context.
ctx means context.Backgrand()
A(ctx) means a cache context with ctx as the parent context.
B(A(ctx)) means a cache context with A(ctx) as the parent context.
With means WithCacheContext
WithNo means WithNoCacheContext

So:

With(ctx) -> A(ctx)
With(With(ctx)) -> A(ctx), not B(A(ctx))
With(With(With(ctx))) -> A(ctx), not C(B(A(ctx)))
WithNo(ctx) -> ctx, not ~A~(ctx)
WithNo(With(ctx)) -> ~A~(ctx)
WithNo(WithNo(With(ctx))) -> ~A~(ctx), not ~B~(~A~(ctx))
With(WithNo(With(ctx))) -> B(~A~(ctx))
WithNo(With(WithNo(With(ctx)))) -> ~B~(~A~(ctx))
With(WithNo(With(WithNo(With(ctx))))) -> C(~B~(~A~(ctx)))

The description seems very valuable. Maybe the description could be put into code as package comment? If would help future developers when they are using the package.

🎺 🤖


Make the calendar show the whole multi day event with how far it has progressed

Made an attempt to debug issue https://github.com/MichMich/MagicMirror/issues/2685 and couldn't really find a reason to why multi day events had their start date changed to the current date. So I tried to remove it and made comparisons with and without it, using sliceMultiDayEvents=true/false.

sliceMultiDayEvents=false
sliceMultiDayEvents=true

startDate=today
Vacation - Today
Vacation (1/13) - Today

Don't modify startDate
Vacation - Ends in 12 days
Vacation (25/37) - Today

It feels like it's wrong with sliceMultiDayEvents=true without this pull request, but since it changes the other one from "Today" to "Ends in 12 days" there might be something more that is needed to be changed? Both looks fine for me at least.

I think it's a good idea to find out why the code was there in the first place. @rejas Do you have any idea? The blame points to you. :)

Well, i didnt write the code, I merely moved it from the fetcher class into this new file... @oemel09 wrote the original code back in 2019 (6a5f0225fe87f7cd0a2db1ad71167c75a1e93be6) and @kolbyjack added a fix in 2022...

As stated in my PR where I added this code back then your example would have been displayed as Vacataion - 25 days ago. If that is no longer the case and it is instead being displayed as Vacation - Ends in 12 days, like you describe, feel free to remove my changes and do not modify the events start date 👍

Awesome! Thanks for your feedback @oemel09
Much appreciated!


Cent Browser

Cent Browser - https://github.com/WhichBrowser/Parser-PHP/issues/149

Coverage remained the same at 100.0% when pulling a332155f9694a13a62aa581a5abb9d0fac4790c9 on ayumi-cloud:Cent into 4899110cd2f87b01e04ced62dbb9dec541031dee on WhichBrowser:master.


Deploy to the Cloud

As a Marketing Manager
I need the application deployed to the cloud
So that the URL can be accessed
Details and Assumptions

IBM cloud will be used

Acceptance Criteria
Given I want to access the URL
When I go to the URL
Then the webpage will load

Seems like maybe one person should do this given the interconnectedness, but maybe one a cloud account is shared it will allow this to be split up?

Tasks completed:

Created python cloud foundry application on IBM Cloud
Added users to organization in IBM Cloud
Provisioned ElephantSQL database to be integrated with service


feat:add /var/run/rtty file to get the state of rtty

Other programs, such as Luci, can display the connection status of the program by reading /var/run/rtty

Please commit again with "add Signed-off-by" via "-s".


fix: typescript channels always expect parameters

Fixes https://github.com/the-codegen-project/cli/issues/89

:tada: This PR is included in version 0.18.6 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Clear buffer as it may contain junk

@miroof I've been experiencing some issues due to the buffer containing some junk after refreshing the page several times. This change fixed it. I find strange that nobody realized about this before.

that was fast :tada: :)

Thanks for your patch. This will increase the stability of the tool 😉
The modifications have been merged.


it gives invalid syntax error (newbie here)

File "spotify.py", line 12
print "%32.32s %s" % (track['artists'][0]['name'], track['name'])

You must be using python3.x
put parenthesis between print and " and between % and(
like this:
          print("%32.32s %s") % (track['artists'][0]['name'], track['name'])


Update INC 3.0 New API for Keras Static Quant

Description
This PR includes the code of the implementation of INC 3.0 New API for Keras Static Quant.

[x] quantize_model API aligned with TFMOT.
[x] Support Static Quant for Keras model

More algorithms might be added in later PRs.
3.0 API Usage
Users should pass the model, quant_config  and calib_dataloader as arguments to this quantize_model API.
model: A tf.keras.Model instance
quant_config: A KerasStaticQuantConfig instance, the usage is the same as nc.config.PostTrainingQuantConfig.
calib_dataloader: A Dataloader for calibration.
PTQ for Keras models
from neural_compressor.data.dataloaders.dataloader import DataLoader
from neural_compressor.keras import KerasStaticQuantConfig, quantize_model

config = KerasStaticQuantConfig(backend="itex")
model = keras.models.load_model("./baseline_model")
calib_dataloader=DataLoader(framework="tensorflow", dataset=Dataset())
q_model = quantize_model(model, config, calib_dataloader)

How has this PR been tested?
Pre-CI
Dependency Change?
No

The 3.x tf binary includes neural_compressor.common and  neural_compressor.tensorflow instead of neural_compressor.keras.  Please align with @chensuyue.

Please add 3.x test here: https://github.com/intel/neural-compressor/tree/master/test/3x
I will add separate CI for keras 3.x.

All comments above has been solved.