text:
Eliminating Aeron MDC as a possible issue for increased network traffic.

Hi,
I'm investigating increased network traffic, and wanted to eliminate that it's not related to Aeron MDC. I have a server side application sending data to multiple applications. Data is published over a few different streams on the same port. Lets just say there are two streams in this scenario, stream ID 1 and stream ID 2. Lets also say client application 1, on host 1, is only subscribing to stream ID 1 and client application 2, on host 2, is only subscribing to stream ID 2.
Is it at all possible the data for stream ID 1 is also being sent to host 2 and data for stream ID 2 is being sent to host 1, even though they are not subscribing to these streams? I'm using version 1.15.2, if that makes any difference.

Can you give more detail on the IP address and ports you are sending to? Addresses and ports are used to separate data at the network layer. Aeron stream ids support multiplexing within a channel over IP addresses and ports. Understanding your network data flows is something you should map out regardless of using Aeron or not.

The publication channel on the server application is aeron:udp?control=10.60.10.10:40060.
The subscription channel on the client hosts are
aeron:udp?endpoint=10.10.57.31:40062|control=10.60.10.10:40060|control-mode=dynamic
and
aeron:udp?endpoint=10.60.10.14:40062|control=10.60.10.10:40060|control-mode=dynamic
I've come to a better understanding of MDC now, and I'm guessing I should really be sending data on stream 1 and stream 2 over different ports, given this is mimicking multicast behaviour. I've done a few tests now and stopping the second client application (10.60.10.14) reduces the network traffic seen on the receiving switch for first client application (10.10.57.31). Is this what you would expect?

You will want to use different control ports on 10.60.10.10. Everything coming back to the same control port will cause things to be less than optimal from flow control and NAKing perspectives.

That makes sense now. Thanks.

authors: kpdsquare mjpt777 tmontgomery

repo: real-logic/aeron


text:
Crash on addOrUpdateObject with a nil value on iOS 9.3.5

Goals
Realm works without issue.
Expected Results
Realm works without issue.
Actual Results
Realm crashes on using optional properties with nil values
Steps to Reproduce
Found on iPhone 4S running 9.3.5

Create an instance of a realm
Create an RLMObject subclass and add some optional properties to it (for eg):

@interface CCRealmAttachment : RLMObject

@property (nonatomic, readwrite, strong) NSString *filename;
@property (nonatomic, readwrite, strong) NSString *mid;
@property (nonatomic, readwrite, strong) NSString *mimeType;

@property (nonatomic, readwrite, assign) NSNumber<RLMBool> *isInline;

@property (nonatomic, readwrite, strong) NSString *uniqueID;
@property (nonatomic, readwrite, strong) NSString *contentId;
@property (nonatomic, readwrite, strong) NSString *partId;
@property (nonatomic, readwrite, assign) NSNumber<RLMInt> *encoding;

@property (nonatomic, readwrite, assign) NSNumber<RLMInt> *size;
@property (nonatomic, readwrite, strong) NSString *savedName;
@property (nonatomic, readwrite, strong) NSString *key;

@end

Set size/savedName to nil

CCRealmAttachment {
	filename = IMG_5628.jpg;
	mid = 172;
	mimeType = image/JPEG;
	isInline = 1;
	uniqueID = 0;
	contentId = ii_15b2da2afe5f083c;
	partId = 2;
	encoding = 3;
	size = (null);
	savedName = (null);
	key = IMG_5628.jpg_0_172;
}

Call addOrUpdateObject: on the realm created above
Realm crashes:

0  libobjc.A.dylib                0x22ce7a76 objc_msgSend + 21
1  Canary-iOS                     0x423287 -[RLMObjectBase valueForKey:] (RLMObjectBase.mm:177)
2  Canary-iOS                     0x42a90d RLMAddObjectToRealm (RLMObjectStore.mm:296)
3  Canary-iOS                     0x493f91 -[RLMRealm addOrUpdateObject:] (RLMRealm.mm:695)

Sorry can't share the project, but the crash occurs on our own devices and is 100% reproducible so I can help debug it.
Version of Realm and Tooling
ProductName:	iOS
ProductVersion:	9.3.5

/Applications/Xcode.app/Contents/Developer
Xcode 8.2.1
Build version 8C1002

/usr/local/bin/pod
1.2.0
Realm (2.6.2)

/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)

(not in use here)

/usr/bin/git
git version 2.10.1 (Apple Git-78)

Also, the same code works without issue on almost all other devices, so might be some old API issue.

Nevermind. Found it on our end. One of the properties was assign.

source: gharchive/issue

repo: realm/realm-cocoa

license_type: permissive

license_source: github-api


text:
Crash when [RLMRealm defaultRealm]

Actual Results
I have set shouldCompactOnLaunch, but it seems has not been called
mmap() failed: Cannot allocate memory size: 1610612736
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
    frame #0: 0x0000000183a14c48 libc++abi.dylib`__cxa_throw
    frame #1: 0x000000010512fb84 Realm`realm::util::mmap_anon(unsigned long) + 408
    frame #2: 0x000000010512fe00 Realm`realm::util::mmap(int, unsigned long, realm::util::File::AccessMode, unsigned long, char const*, realm::util::EncryptedFileMapping*&) + 88
    frame #3: 0x0000000104fbc0cc Realm`realm::SlabAlloc::attach_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, realm::SlabAlloc::Config&) + 872
    frame #4: 0x000000010505e5f0 Realm`realm::SharedGroup::do_open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, bool, realm::SharedGroupOptions) + 3020
    frame #5: 0x0000000104e92a60 Realm`realm::SharedGroup::open(this=0x000000010810d400, repl=0x00000001d415d2d0, options=const realm::SharedGroupOptions @ 0x000000016ee38a30) at group_shared.hpp:849
    frame #6: 0x0000000104e92728 Realm`realm::SharedGroup::SharedGroup(this=0x000000010810d400, repl=0x00000001d415d2d0, options=const realm::SharedGroupOptions @ 0x000000016ee39900) at group_shared.hpp:822
    frame #7: 0x0000000104e92128 Realm`realm::SharedGroup::SharedGroup(this=0x000000010810d400, repl=0x00000001d415d2d0, options=<unavailable>) at group_shared.hpp:821
    frame #8: 0x0000000104e84234 Realm`realm::Realm::open_with_config(realm::Realm::Config const&, std::__1::unique_ptr<realm::Replication, std::__1::default_delete<realm::Replication> >&, std::__1::unique_ptr<realm::SharedGroup, std::__1::default_delete<realm::SharedGroup> >&, std::__1::unique_ptr<realm::Group, std::__1::default_delete<realm::Group> >&, realm::Realm*) [inlined] std::__1::__unique_if<realm::SharedGroup>::__unique_single std::__1::make_unique<realm::SharedGroup, realm::Replication&, realm::SharedGroupOptions&>(__args=0x00000001d415d2d0, __args=0x000000016ee398a8) at memory:3032
    frame #9: 0x0000000104e841d4 Realm`realm::Realm::open_with_config(config=0x0000000107eb48d8, history=0x0000000107eb49f0, shared_group=0x0000000107eb49f8, read_only_group=0x0000000107eb4a00, realm=0x0000000107eb48c8) at shared_realm.cpp:190
    frame #10: 0x0000000104e82dec Realm`realm::Realm::Realm(this=0x0000000107eb48c8, config=<unavailable>, coordinator=std::__1::shared_ptr<realm::_impl::RealmCoordinator>::element_type @ 0x0000000107eb45b8 strong=2 weak=3) at shared_realm.cpp:59
    frame #11: 0x0000000104c83eac Realm`realm::Realm::make_shared_realm(this=0x0000000107eb48c8, config=<unavailable>, coordinator=nullptr)::make_shared_enabler::make_shared_enabler(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>) at shared_realm.hpp:334
    frame #12: 0x0000000104c83dd4 Realm`realm::Realm::make_shared_realm(this=0x0000000107eb48c8, config=<unavailable>, coordinator=<unavailable>)::make_shared_enabler::make_shared_enabler(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>) at shared_realm.hpp:334
    frame #13: 0x0000000104c83610 Realm`std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) [inlined] std::__1::__compressed_pair_elem<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler, 1, false>::__compressed_pair_elem<realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&, 0ul, 1ul>(this=0x0000000107eb48c8, __args=tuple<realm::Realm::Config &&, std::__1::shared_ptr<realm::_impl::RealmCoordinator> &&> @ 0x000000016ee3a7f8) at memory:2057
    frame #14: 0x0000000104c8355c Realm`std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) [inlined] std::__1::__compressed_pair<std::__1::allocator<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>, realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::__compressed_pair<std::__1::allocator<realm::Realm::make_shared_realm(this=0x0000000107eb48c8, __first_args=tuple<std::__1::allocator<make_shared_enabler> &> @ 0x000000016ee3a7c0, __second_args=tuple<realm::Realm::Config &&, std::__1::shared_ptr<realm::_impl::RealmCoordinator> &&> @ 0x000000016ee3a7b0)::make_shared_enabler>&, realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&>(std::__1::piecewise_construct_t, std::__1::tuple<std::__1::allocator<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>&>, std::__1::tuple<realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&>) at memory:2159
    frame #15: 0x0000000104c834f4 Realm`std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) [inlined] std::__1::__compressed_pair<std::__1::allocator<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>, realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::__compressed_pair<std::__1::allocator<realm::Realm::make_shared_realm(this=0x0000000107eb48c8, __pc=piecewise_construct_t @ 0x000000016ee3a770, __first_args=tuple<std::__1::allocator<make_shared_enabler> &> @ 0x000000016ee3a768, __second_args=tuple<realm::Realm::Config &&, std::__1::shared_ptr<realm::_impl::RealmCoordinator> &&> @ 0x000000016ee3a758)::make_shared_enabler>&, realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&>(std::__1::piecewise_construct_t, std::__1::tuple<std::__1::allocator<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>&>, std::__1::tuple<realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&>) at memory:2160
    frame #16: 0x0000000104c834cc Realm`std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) [inlined] std::__1::__shared_ptr_emplace<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler, std::__1::allocator<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> >::__shared_ptr_emplace<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(this=0x0000000107eb48b0, __a=allocator<make_shared_enabler> @ 0x000000016ee3a728, __args=0x000000016ee3b878, __args=nullptr)::make_shared_enabler>, realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) at memory:3572
    frame #17: 0x0000000104c832d0 Realm`std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) [inlined] std::__1::__shared_ptr_emplace<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler, std::__1::allocator<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> >::__shared_ptr_emplace<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(this=0x0000000107eb48b0, __a=allocator<make_shared_enabler> @ 0x000000016ee3a6e8, __args=0x000000016ee3b878, __args=nullptr)::make_shared_enabler>, realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) at memory:3573
    frame #18: 0x0000000104c832a4 Realm`std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> std::__1::shared_ptr<realm::Realm::make_shared_realm(__args=0x000000016ee3b878, __args=nullptr)::make_shared_enabler>::make_shared<realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) at memory:4230
    frame #19: 0x0000000104c71c28 Realm`realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>) [inlined] std::__1::enable_if<!(is_array<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler>::value), std::__1::shared_ptr<realm::Realm::make_shared_realm(realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator>)::make_shared_enabler> >::type std::__1::make_shared<realm::Realm::make_shared_realm(__args=0x000000016ee3b878, __args=nullptr)::make_shared_enabler, realm::Realm::Config, std::__1::shared_ptr<realm::_impl::RealmCoordinator> >(realm::Realm::Config&&, std::__1::shared_ptr<realm::_impl::RealmCoordinator>&&) at memory:4600
    frame #20: 0x0000000104c71c00 Realm`realm::Realm::make_shared_realm(config=<unavailable>, coordinator=<unavailable>) at shared_realm.hpp:336
    frame #21: 0x0000000104c70edc Realm`realm::_impl::RealmCoordinator::get_realm(this=0x0000000107eb45b8, config=Config @ 0x000000016ee3ba88) at realm_coordinator.cpp:227
    frame #22: 0x0000000104e877d4 Realm`realm::Realm::get_shared_realm(config=Config @ 0x000000016ee3c878) at shared_realm.cpp:265
    frame #23: 0x0000000104e09b04 Realm`::+[RLMRealm realmWithConfiguration:error:](self=RLMRealm, _cmd="realmWithConfiguration:error:", configuration=0x0000000107eab780, error=0x0000000000000000) at RLMRealm.mm:400
    frame #24: 0x0000000104e07410 Realm`::+[RLMRealm defaultRealm](self=RLMRealm, _cmd="defaultRealm") at RLMRealm.mm:177
  * frame #25: 0x00000001043794fc HHDB`-[HHDBManager configRealmForAccount:](self=0x00000001d422c4c0, _cmd="configRealmForAccount:", hhid=@"1234") at HHDBManager.m:79

It seems that crash happened before compact
Steps to Reproduce
Crash on [RLMRealm defaultRealm]
Code Sample
   RLMRealmConfiguration *config = [RLMRealmConfiguration defaultConfiguration];
   config.migrationBlock = ^(RLMMigration *migration, uint64_t oldSchemaVersion) {

   };
   config.shouldCompactOnLaunch = ^BOOL(NSUInteger totalBytes, NSUInteger bytesUsed) {
       return (totalBytes > 100 * 1024 * 1024) && ((CGFloat)bytesUsed / (CGFloat)totalBytes) < 0.5; // not be called
   };
   [RLMRealmConfiguration setDefaultConfiguration:config];
   self.mainThreadRealm = [RLMRealm defaultRealm]; // crash on this line

Version of Realm and Tooling

Realm framework version: 3.5.0
Xcode version: 9.3
iOS/OSX version: 11.3

Sorry about the late response. Did you get your issue resolved?
Your file seems to be too big to be able to compact it.

Not yet. How to avoid this situation? Thank you

Closing this issue with no recent activity. I assume this issue has been resolved -- please let us know if that is not the case.

authors: bmunkholm mewehk stennie


text:
Allow throws within Realm.write(_:) block in Swift 3

Fixes #4120 /cc @austinzheng

Docs failure is unrelated. Was due to some CI workers not having jazzy 0.7.2. I updated the workers so that shouldn't happen again.

source: gharchive/pull-request


text:
Realm initialisation causes app to hang

How frequently does the bug occur?
All the time
Description
When initialising a Realm instance, we are seeing a large quantity of app hang logs in Sentry. The affected users are from a variety of iOS versions, so its unlikely that is a factor.
From our initial investigation, it may look like the very first time the app attempts to initialise Realm, e.g. try Realm(), hangs are triggered. The following is an example of how we are opening our Realm.
do {
            let realm = try Realm()

            if !Thread.isMainThread {
                realm.refresh()
            }

            return realm
        } catch {
           // Handle error
        }

Stacktrace & log output
libsystem_kernel    0x1f7608b48  __psynch_mutexwait
  libsystem_pthread   0x20784614c  _pthread_mutex_firstfit_lock_wait
  libsystem_pthread   0x20784d30c  _pthread_mutex_firstfit_lock_slow
  libc++.1            0x1c92c89ec  std::__1::mutex::lock
  muzmatch            0x101a14bcc  std::__1::lock_guard<T>::lock_guard (__mutex_base:90)
  muzmatch            0x101a14bcc  std::__1::lock_guard<T>::lock_guard (__mutex_base:90)
  muzmatch            0x101a14bcc  +[RLMRealm realmWithConfiguration:queue:error:] (RLMRealm.mm:528)
  muzmatch            0x101d5a240  RLMRealm.__allocating_init (<compiler-generated>)
  muzmatch            0x101d5a6bc  Realm.init (Realm.swift:79)
  // Stack trace here to setup Realm
  muzmatch            0x100af6f24  AppDelegate.application (AppDelegate.swift:114)
  muzmatch            0x100af5028  AppDelegate.application (<compiler-generated>)
  UIKitCore           0x1bd404ec4  -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:]
  UIKitCore           0x1bd404660  -[UIApplication _callInitializationDelegatesWithActions:forCanvas:payload:fromOriginatingProcess:]
  UIKitCore           0x1bd40363c  -[UIApplication _runWithMainScene:transitionContext:completion:]
  UIKitCore           0x1bd403288  -[_UISceneLifecycleMultiplexer completeApplicationLaunchWithFBSScene:transitionContext:]
  UIKitCore           0x1bd148d60  _UIScenePerformActionsWithLifecycleActionMask
  UIKitCore           0x1bd48ac38  __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke
  UIKitCore           0x1bd33b884  -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:]
  UIKitCore           0x1bd33b6ac  -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]
  UIKitCore           0x1bd33b25c  -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:]
  UIKitCore           0x1bd33b128  __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke
  UIKitCore           0x1bda1959c  +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:]
  UIKitCore           0x1bdab1968  _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion
  UIKitCore           0x1bd1e72d4  -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]
  UIKitCore           0x1bd659044  __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.215
  UIKitCore           0x1bd2b9be8  -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:]
  UIKitCore           0x1bd2b9a58  -[UIScene scene:didUpdateWithDiff:transitionContext:completion:]
  UIKitCore           0x1bd2b8fac  -[UIApplication workspace:didCreateScene:withTransitionContext:completion:]
  UIKitCore           0x1bd2b8d38  -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:]
  FrontBoardServices  0x1d0891d44  -[FBSScene _callOutQueue_agent_didCreateWithTransitionContext:completion:]
  FrontBoardServices  0x1d08d1100  __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke.78
  FrontBoardServices  0x1d0895ae0  -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:]
  FrontBoardServices  0x1d08d0d38  __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke
  libdispatch         0x1c23a1fd8  _dispatch_client_callout
  libdispatch         0x1c23a5a58  _dispatch_block_invoke_direct
  FrontBoardServices  0x1d089ff28  __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__
  FrontBoardServices  0x1d089fac4  -[FBSSerialQueue _targetQueue_performNextIfPossible]
  FrontBoardServices  0x1d08a22a4  -[FBSSerialQueue _performNextFromRunLoopSource]
  CoreFoundation      0x1baff2228  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
  CoreFoundation      0x1baffe610  __CFRunLoopDoSource0
  CoreFoundation      0x1baf82578  __CFRunLoopDoSources0
  CoreFoundation      0x1baf97eb4  __CFRunLoopRun
  CoreFoundation      0x1baf9d1e0  CFRunLoopRunSpecific
  GraphicsServices    0x1f3dbd364  GSEventRunModal
  UIKitCore           0x1bd44cd84  -[UIApplication _run]
  UIKitCore           0x1bd44c9e8  UIApplicationMain
  muzmatch            0x100aecde0  main (AppDelegate.swift:29)

Can you reproduce the bug?
Not yet
Reproduction Steps
We are unable to identify the hangs our side, however Sentry is suggesting we have a large number of users affected by this.
Version
10.33.0
What SDK flavour are you using?
Local Database only
Are you using encryption?
No
Platform OS and version(s)
iOS 16.0.2
Build environment
Xcode version: 14.1
Dependency manager and version: SPM

Hi @hayden-muzmatch this clearly looks like a mutex is waiting for the thread to be free to continue to open the realm, are any of your operations blocking the thread to open the realm?. Can you check what is happening in your other thread while this mutex is waiting?.

@hayden-muzmatch can you provide more information to us on this issue?

Closing this as there is no response from the user.

repo: realm/realm-swift


text:
2022 pricing

added tailwind framework
updated Pricing section according new design

Hi @DmytroPopovSSA, there are a few issues here:

[ ] The pricing header is not included in the header section. Please review the sketch file for the designs (you'll need to re-download it)
[ ] You've edited global styles, which have affected styles across the site. You should only use unique, component-local styles to edit the styles of the pricing section. See the loom video below for more details.

Overall, the pricing component itself looks good.
https://www.loom.com/share/c419ee50b20f40fbbd839c6d6cdca4e1

Also, you are overwriting the latest version of 2022-develop and removing my latest commits. Please pull the latest version of 2022-develop1 into your branch.

the issues are fixed,
pulled 2022-develop into 2022-Pricing

Thanks @DmytroPopovSSA that is better!
Regarding the styles, let's make a few minor updates:

[ ] Remove the blue background color in the Tickets section

[ ] Update the header styles, including alignment, color, size, and letter-spacing to match the previous headers

[ ] Update the paragraph text to be the same style and color and size and alignment as the first section "Welcome Back!"

[ ] Tickets: Add a 1px solid blue border (border color: #36a7ee) around the pricing columns "Reactathon Only" and "Serverless in the Park only" columns. NOTE: the pink border of the center pricing column should have the highest z-index. You should NOT see the blue border where it intersects with the center column.

[ ] Ensure that the pricing columns have rounded corners.

minor updates added

authors: DmytroPopovSSA dunphyben

license: MIT


text:
installation failed

sorry~, fixed by updating nodejs to the latest version, issue can be closed~thx

Good to know why this happened. Thanks for the report.

authors: natew sunweifeng

repo: reapp/reapp

license: mit

license_source: bigquery


text:
Reductive doesn't avoid supurious rerenders

See: https://github.com/reasonml-community/reductive/blob/master/src/reductive.re#L64
The way createMake is written Reductive would never be able to perform the function of avoiding rerenders because there's only one action type and individual action types need to explicitly pattern match to whether or not an update should be done when in use by a reducer component.
React/Redux patterned applications shouldn't see responsiveness degrade continually as app size increases, and as far as I can tell currently they will, without explicit user intervention in the form of hand written shouldComponentUpdates.

I think this is fixed now.

repo: reasonml-community/reductive


text:
Edges should support children property (similar to Nodes)

Currently, the Edge component doesn't support the children property. (or, actually, it does, but does nothing with it)
I think the Edge children should behave similarly to the Nodes, and accept either a component or a function that returns a react component.
I can make a PR for this.

Whats the use case for this? Doesn't make sense to me.

Allowing the use of foreignObject as children, and draw custom HTML elements such as additional buttons of a different style to replace the built-in Add/Remove components (and other options)
I intend to use it to build my own Add/Remove buttons on edges, with actual HTML/CSS instead of SVG.

The same logic applies to ports as well.
I need to display an icon/text next to each port.
For instance, it would be a warning when a port isn't connected with any other node.
I think the same PR should bring support for children in both Ports and Edges.

authors: Vadorequest amcdnl

repo: reaviz/reaflow


text:
CalendarHeatmap is not showing last 17 days of data

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

CalendarHeatmap is not showing last 17 days
Expected behavior
Expecting the CalendarHeatmap to fully show the data
Minimal reproduction of the problem with instructions
      <CalendarHeatmap
        height={200}
        data={calendarData}
        series={
          <HeatmapSeries
            colorScheme={CALENDAR_COLOR_SCHEME}
            padding={0.3}
          />
        }
      />
    )}

STEPS TO REPRODUCE

Add the data below to the CalendarHeatmap

Environment
Windows 10
Google Chrome

Libs:
- react version: 18.2.0
- reaviz version: 15.15.6
- Node version: 20.15.0

Most recent version have this issue too

When I'm using import { heatmapCalendarData } from 'reaviz-data-utils'; as data everything works fine, but when I put the data below it's not showing the last 17 days

data.txt

Commenting for my own visibility here

Can you share the data you used to make this chart?

data (1).txt
Please wrap key inside new Date()

authors: amcdnl cloughrm devconn99

repo: reaviz/reaviz


text:
Show the number of tasks in the default view

I needed a simple summary of the tasks listed. Perhaps its usefull for other people.

Apologies for late reply on this - I like the idea, thanks for the pull request!
I would like to use argparse to make this a bit more robust with multiple options, and should also really upgrade to python3. I will aim to do the version upgrade soon - would you be interested in using argparse here? Thanks!

authors: Pelado-Mat rebeccamorgan

repo: rebeccamorgan/due


text:
Disconnect after a couple of minutes

Hi,
i run the eufy-security in iobroker and when i change and deploy the node the node will become connected but after a couple minutes the nodes disconnects:

I can't find any possibility to enter such a token. What is also strange from time i will be asked to enter a captcha.

Or can you please describe how an invite can be used with a new account? Then I will create one especially for this module. As far as expect a mail configuration is necessary. But I do not know how I can configure mail on iobroker or node-red to receive the invite. Are there other configurations necessary?

I it is now working, why ever, i cant find anything which i changed. So you can close this issue. But it would be nice if you can explain how invites can be used to use an dedicated account for the module.

Going further on this issue. I have the same problem, I have tried 5 fresh accounts so far and all end up with this exact output.
Anybody that can help me with this?

authors: MJJH nitram-rem

repo: recallfx/node-red-contrib-eufy-security


text:
Use DetourCrowd with external physics

dtCrowd handles movement for agents internally. After each update there is new position for each actor. Calculation of a new positon includes maximum velocity and acceleration of agent. Also there is specific logic how to change agent speed.
Is there some way how can I use external physics to update agent position for given time interval and use custom logic for agent speed?
For example agent speed is constant, there is no acceleration, so in each moment of time agent could move in specific direction or stay. Agent can change direction instantly.
I see this as customization point for dtCrowd class. Probably add an interface class and default implementation with current logic. Will you approve this kind of change or is there any other way? Thanks.

I believe the main thing is that keeping the agent on mesh can be a problem if the Detour does not have full control over the movement, and if the agent gets off mesh then that causes a bunch of problems. @memononen has posted more details about it somewhere I'm sure, but I can't find it at the moment.
Unfortunately DetourCrowd is the area of R&D I am the least familiar with so I am not able to provide much feedback on eventual PRs/work. Maybe @hymerman @grahamboree could help out?

Just to close the loop on this, there's no prescribed method to drop-in a new physics engine into DetourCrowd.  IMO there's probably some work that could be done to separate the code that does the simple physics to move the agent and the code that's driving that motion.  That would better support use cases like this.

authors: elsid grahamboree jakobbotsch

repo: recastnavigation/recastnavigation

license: Zlib


text:
Please invite me to the Recode-Hive GitHub Community Organization

Name
Ananya Gupta
Discord Username (if applicable)
ann_309
Additional Context
No response

Invitation sent to join the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see. You can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/recodehive/people

repo: recodehive/Support


text:
Please invite me to the Recode-Hive GitHub Community Organization

Name
Shrey Shah
Discord Username (if applicable)
shrey061003
Additional Context
No response

Invitation sent to join the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see. You can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/recodehive/people

Thank you!


text:
Please invite me to the Recode-Hive GitHub Community Organization

Name
Utsav Singhal
Discord Username (if applicable)
utsav_singhal
Additional Context
No response

Invitation sent to join the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see. You can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/recodehive/people


text:
如何自定义popup的工具按钮

你好，作者，请问如何在ToolbarPlugin下面的popup自定义一个自己的弹窗组件

https://editor.aomao.com/zh-CN/config/toolbar#弹出框

感谢，刚刚已经找到，写出来了

还有一个疑问，就是自己写的popup，如何执行onclick后隐藏popup弹窗呢，我看hide没有找到

这个就根据 range 判断的，onclick 你就监听document的click事件呗，没点击到编辑区域就给隐藏不就行了

authors: smallCF yanmao-cc

repo: red-axe/am-editor


text:
Fail CI suite if test fails

Signed-off-by: Pranshu Srivastava rexagod@gmail.com

CI is reporting the correct status now, PTAL.

repo: red-hat-storage/mcg-osd-deployer


text:
Available CRDs check feature

Changes

Update the storageCluster controller to react whenever a create/delete event has been enqueued for a specific CRD that's become newly available.
Exit the ocs-operator process with a specific exit code whenever a new card of interest is being created or deleted
Catch the exit code with a bash script and restart the ocs-operator process
Conditionally watch the ClusterClaim CRD from the ocsinit controller

/retest-required

/retest-required

/lgtm

authors: nb-ohad rewantsoni

repo: red-hat-storage/ocs-operator


text:
Fixed Boost requirement version.

For all Boost 1.84.0 or later is required.
If you don't build tests, Boost 1.82.0 or later is required.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.80%. Comparing base (fe453b4) to head (94f152d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #322   +/-   ##
=======================================
  Coverage   96.80%   96.80%
=======================================
  Files         152      152
  Lines        9160     9160
=======================================
  Hits         8867     8867
  Misses        293      293

authors: codecov-commenter redboltz


text:
chore: bump release pipeline version in pyxis test

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Issue ticket number and link
Type of change

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/lgtm

authors: johnbieren kasemAlem


text:
Add konflux-eaas kubesaw tier

The user should only be allowed to create select resources (ClusterTemplateInstance, Secrets) in the provisioned namespace.

@dperaza4dustbit please review the new konflux-eaas tier. I'm also looking for some guidance about the rest.
I didn't intend these change but ksctl generate nstemplatetiers forces them on me:

metadata.creationTimestamp is set to null on all generated resources. Perhaps this is a recent change with ksctl but they should be non-harmful.
A new admin TierTemplate was created for the appstudio and appstudiolarge tiers. The previously generated versions lacked some RBAC rules for roles, rolebindings, serviceaccounts, and serviceaccount/tokens. I haven't removed the older admin TierTemplate considering I'd rather not touch these files to begin with. What should be done about this?

I'm running the latest ksctl version.
> ksctl --version
ksctl version commit: 'c6809574a6394a38284860ddd88999e2e30b073c-dirty', build time: '2024-07-25T18:58:24Z

@dperaza4dustbit @sadlerap @filariow please review. The issues with ksctl were resolved with #4190 (although I did manually delete the null creationTimestamps). Thanks for fixing that!

repo: redhat-appstudio/infra-deployments


text:
feat(STONEINTG-346): expose build pipeline in snapshot

This change makes easier to find which build pipeline created a snapshot.

repo: redhat-appstudio/integration-service


text:
Log the count of scenarios found

To help with debugging in staging.
See https://coreos.slack.com/archives/C030SGP2VB9/p1661881854052129

Replaced by #45 because of refactoring changes

authors: dirgim ralphbean


text:
Added a comment to manually propagate Dockerfile changes to the midstream repo

Add a reminder that Dockerfile changes need to be manually propagated to the midstream repository

/retest

repo: redhat-cne/hw-event-proxy


text:
wrap node/gulp build with a maven pom so we...

wrap node/gulp build with a maven pom so we can run it in Jenkins more easily

I don't think we need it until we really going to build installer as part of something bigger that uses maven, otherwise it adds two extra dependencies: java and maven.

why do you need a maven build to link jobs together in jenkins ? not following that since jenkins jobs can be linked together no matter the used build step inside it.

I should note too that if you don't want to use the pom to build... Don't. You can still manually install npm & gulp then run that way.

lets not add extra layers of build stuff if it is not needed. Right now I don't see a need for it so please enlighten us why introducing maven is needed - jenkins itself don't need maven to do builds.

It seems that adding Maven is not useful. Can we close this?

authors: dgolovin maxandersen nickboldt ppitonak


text:
odo deploy doesn't immediately check for namespace existence

/kind bug
What versions of software are you using?
Operating System: all
Output of odo version: main
How did you run odo exactly?

Fresh minikube cluster
The namespace myproject, which was mentioned in env.yaml, didn't exist on the cluster
odo deploy for the devfile with outer loop components and devfile-nodejs-deploy example project

Actual behavior
odo deploy builds the image, but fails when creating Kubernetes components
Expected behavior
Should odo spend time building the image if the namespace doesn't exist?
Any logs, error output, etc?
$ odo deploy
  __
 /  \__     Deploying the application using devfile-nodejs-deploy Devfile
 \__/  \    Namespace: myproject
 /  \__/    odo version: v3.0.0-beta3
 \__/

↪ Building & Pushing Container: quay.io/tkral/devfile-nodejs-deploy:latest
 •  Building image locally  ...
build -t quay.io/tkral/devfile-nodejs-deploy:latest -f /home/dshah/src/devfile-nodejs-deploy/Dockerfile /home/dshah/src/devfile-nodejs-deploy
 ✓  Building image locally [2ms]
 •  Pushing image to container registry  ...
push quay.io/tkral/devfile-nodejs-deploy:latest
 ✓  Pushing image to container registry [1ms]

↪ Deploying Kubernetes Component: devfile-nodejs-deploy
 ✗  failed to create service(s) associated with the component: namespaces "myproject" not found

@feloy do you think #6025 will/should handle this scenario as well?

repo: redhat-developer/odo


text:
Grab pod logs concurrently

Signed-off-by: Dharmit Shah shahdharmit@gmail.com
What type of PR is this:
/kind cleanup
What does this PR do / why we need it:
Uses go routines to concurrently grab the logs of the Pods matching an odo component
Which issue(s) this PR fixes:
Fixes part of #5872
PR acceptance criteria:

[ ] Unit test

[x] Integration test

[ ] Documentation

How to test changes / Special notes to the reviewer:

Create a component using this devfile
Place start := time.Now() at the beginning of Run method in pkg/odo/cli/logs/logs.go and print the time since start using time.Since(start) right before the call to printLogs function.
Do the same for code from main branch.
Compare the timings.

It seems the architecture could be simplified.
If you look to other watcher methods (fsnotify, kubernetes), the business level function should return to the CLI a channel, and the CLI should loop over this channel to get the information and display it, until the channel is closed.

Also, while testing this, I noticed a strange behavior (well, I had observed a different behavior prior to checking out this branch). In my case, when I had issues with fsnotify (e.g.: too many open files), odo logs --follow used to exit right away. But now, it no longer exits, but subsequent container logs are no longer displayed either.
To me, not exiting right away is a bit odd, because it makes users think that the error message is not an issue, so it might make them expect subsequent logs to be returned, which is not the case here.

I'm at loss as to what exactly is happening here. The too many open files seems to be an error caused because the kernel won't let you open any more files as you have many opened already. But I don't understand what behaviour you are seeing with odo logs --follow when you face this error. 😕

Also, while testing this, I noticed a strange behavior (well, I had observed a different behavior prior to checking out this branch). In my case, when I had issues with fsnotify (e.g.: too many open files), odo logs --follow used to exit right away. But now, it no longer exits, but subsequent container logs are no longer displayed either.
To me, not exiting right away is a bit odd, because it makes users think that the error message is not an issue, so it might make them expect subsequent logs to be returned, which is not the case here.

I'm at loss as to what exactly is happening here. The too many open files seems to be an error caused because the kernel won't let you open any more files as you have many opened already. But I don't understand what behaviour you are seeing with odo logs --follow when you face this error. confused

I wanted to see how this would behave with the default limit on open files (I had this error in the past and increased the limit).
On main, odo logs --folllow exits immediately whenever I face this error (perhaps it is the same behavior for other errors). But now it no longer exits, but what I found odd is that it looks like it is stuck, because it does not display new logs either.
Maybe it's me, but I thought exiting immediately would make more sense.

I wanted to see how this would behave with the default limit on open files (I had this error in the past and increased the limit).
On main, odo logs --follow exits immediately whenever I face this error (perhaps it is the same behavior for other errors). But now it no longer exits, but what I found odd is that it looks like it is stuck, because it does not display new logs either. Maybe it's me, but I thought exiting immediately would make more sense.

I still don't understand this entirely. Can you share the steps to reproduce? Are you using ulimit to reduce the number of files that could be opened? Also, is it still the case after addressing https://github.com/redhat-developer/odo/pull/5942#discussion_r922305744?

I wanted to see how this would behave with the default limit on open files (I had this error in the past and increased the limit).
On main, odo logs --follow exits immediately whenever I face this error (perhaps it is the same behavior for other errors). But now it no longer exits, but what I found odd is that it looks like it is stuck, because it does not display new logs either. Maybe it's me, but I thought exiting immediately would make more sense.

I still don't understand this entirely. Can you share the steps to reproduce? Are you using ulimit to reduce the number of files that could be opened?

Yes, I was using ulimit and I was testing against this fork of the Spring Boot guide: https://github.com/rm3l/gs-spring-boot/tree/main/complete
I don't have clear reproduction steps for now, as sometimes it works regardless of the hard/soft limit set in the system.
Ah actually, I noticed that I had the same issue when running odo logs --follow from a separate laptop, but targeting the same cluster. After digging a little bit, I noticed that the failed to create fsnotify watcher: too many open files message seems to actually be a line in the container logs..
But again, I still don't get why odo logs --follow used to exit in the past, and now it looks like it is blocked.
Even kubectl logs --follow exits right away past this error message:
☸ kind-local-k8s-cluster in ~/w/t/s/gs-spring-boot/complete on  main via ☕ v17.0.3 on ☁
❯ kubectl logs my-java-springboot-app-app-c69bfd669-4fn72 --follow

-- Truncated --
viewResolver
webEndpointDiscoverer
webEndpointPathMapper
webEndpointServletHandlerMapping
webExposeExcludePropertyEndpointFilter
webMvcMetricsFilter
webMvcTagsProvider
webServerFactoryCustomizerBeanPostProcessor
websocketServletWebServerCustomizer
welcomePageHandlerMapping
failed to create fsnotify watcher: too many open files%

☸ kind-local-k8s-cluster in ~/w/t/s/gs-spring-boot/complete on  main via ☕ v17.0.3 on ☁
❯ echo $?
0

☸ kind-local-k8s-cluster in ~/w/t/s/gs-spring-boot/complete on  main via ☕ v17.0.3 on ☁
❯

Also, is it still the case after addressing #5942 (comment)?

Unfortunately, it is still the case with your new changes.
I can try to show you tomorrow if that's ok for you.

Darn good job. No changes needed, it works wonders!
/lgtm

authors: cdrage dharmit feloy rm3l


text:
Refactoring of Integration Status Change Event handlers

Cleaned up interfaces a bit and reorganized packages
Fixed integration update logic. (e.g. the controller is only responsible for updating the status
Introduced a StatusChangeHandlerProvider interface for a single entry point (so that components can be switched more easily)
Simplified Demo and Noop implementation
Fixed Github file update issue by inserting a sleep
Tuned logging
Fixed desiredStatus of integrations in deployment.json

Codecov Report

Merging #316 into master will decrease coverage by 0.36%.
The diff coverage is 10%.

@@             Coverage Diff              @@
##             master     #316      +/-   ##
============================================
- Coverage     44.75%   44.39%   -0.37%
  Complexity      216      216
============================================
  Files           128      128
  Lines          1879     1899      +20
  Branches        192      191       -1
============================================
+ Hits            841      843       +2
- Misses          978      996      +18
  Partials         60       60

Impacted Files
Coverage Δ
Complexity Δ

...redhat/ipaas/openshift/OpenShiftConfiguration.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...m/redhat/ipaas/openshift/OpenShiftServiceImpl.java
10.07% <0%> (-0.58%)
0 <0> (ø)

...est/v1/handler/integration/IntegrationHandler.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...m/redhat/ipaas/openshift/OpenShiftServiceNoOp.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...as/openshift/OpenShiftConfigurationProperties.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...ava/com/redhat/ipaas/github/GitHubServiceImpl.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...aas/project/converter/DefaultProjectGenerator.java
91.08% <100%> (+0.18%)
25 <0> (ø)
:arrow_down:

@iocanel @jimmidyson Could I have one review please ? It's mostly about rearranging things (e.g. moving back OpenShift logic to the OpenShift service, etc.), but would love to have this is in (or rejected) soon to avoid rebasing marathons. Thanks !
Unfortunately with this sort of refactoring smaller PRs (which I would prefer of course) are not so easily possible.

Fixed problem with multiple checks for the same integration
This is uses a state map which is checked when processing a 'change-event' so
that no second job is triggered if there is already one.
Also added some logging and clarified the various steps happening (these could be even fine granular integration step states)
However there is still the problem with expiring tokens. Because of the
reordering, a GitHub API will fail first, whose error message is a bit obfuscated (its a JSON deserialisation error coming from the egit lib)
Would be awesome if there would be a check for verifying whether a token is till valid.
@iocanel @jimmidyson Any idea how such a check could look like ?
BTW, I still get the GitHub errors from time to time, even when waiting 1s between update over the API.

Another problem with out logic: When the final deployment fails on OpenShift because the created project has some issue (like it is these days), then the Integration stays in status "Pending" and ipaas-rest will constantly update the GitHub repo with the generated files (regardless whether they have been changed), recreate the OpenShift resources and start a (costly) S2I source build. There is no way yet to move to state "Failed" after some retries.
Maybe when the source state is "Pending" one should simply skip all the initial setup step and only check for the Deployment to be there ? This can be easily added.

Last push for today. It's as good as it gets for now ;-) GitHub API is still somewhat flaky (e.g. needs also some time after repo creation before files can be added, sometimes 1s is not good enough ;-(.
I highly recommend that we should go ways from GitHub API. It seems to have some serious timing issues.

@rhuss The token itself contains validity info (it's a JWT). I can't remember exactly the best way to parse it out, but pretty sure keycloak provides something in their library. I can't look right now, but will be able to find something out I'm sure if you don't get anywhere with it.

@jdyson added a JWT expiry checks so that we can now nicely bail out when things time out. Of course, there is still the issue what todo when a token expires. Ideally it could be refreshed (or it could be an offline token from the very beginning, if supported). At least the loop should be stopped and the integration should be moved into a (not yet existing) error state. At the moment it repeatedly try to process the integration but will always fails because noone updates the token.
If this is ok so far, it would be awesome if we could merge asap (there are already other PR pending touching this code regions).

Added test for Token.isTokenExpired()
... and fixed an issue. That's what tests are for ;-)
BTW, would be awesome to add a test for valid token (with expiration == Integer.MAX_INT), but tbh don't know how to create and sign such a token.

retest please

authors: codecov-io jimmidyson rhuss

repo: redhat-ipaas/ipaas-rest


text:
operator dell-csi-operator (1.12.0)

Thanks for submitting your Operator. Please check the below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want to use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description of the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/retest

/merge possible

/merge possible

/merge possible

/merge possible

authors: framework-automation satyakonduri


text:
Support multinode deployments

Currently tested deployments are based on a single node, either using the standard all-in-one or a scenario.

So, this is a tricky one.
The scope of WeIRDO is to run gate jobs outside of the gate to improve our CI coverage.
Right now, none of the implemented projects (packstack, puppet-openstack, kolla) have multi-node jobs upstream.
I do not want to implement custom jobs in WeIRDO. If we want to test multi node, it will need to follow the right path and be done upstream first.
I know it is possible and @EmilienM looked into it a while back for puppet openstack jobs but it gets a bit hard.
We can definitely keep this issue opened for when upstream starts testing multi node.

I agree with your viewpoint that this is something that needs to be upstream; however for both PackStack and Kolla a multi-node deployment is possible to realize. Just not so sure how this can be achieved and implemented at the OpenStack infrastructure.

I believe upstream multinode will be facilitated by zuul v3 -- at which point they actually intend to get rid of Jenkins as it will no longer be necessary. There's more details available about it here: https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html
We're talking Ocata timeframe for Zuul v3 unless significant effort is put towards it in the meantime.

authors: dmsimard gbraad

repo: redhat-openstack/weirdo


text:
🛑 Redhcp is down

In e486c90, Redhcp (www.redhcp.work/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Redhcp is back up in 2c09fea after 18 minutes.

repo: redhcp/status-page


text:
Fix BufferedIO to search with byteindex

As of https://github.com/redis-rb/redis-client/pull/184, the buffer String is no longer BINARY but UTF-8.
I missed that the code that search for newlines was using .index instead of .byteindex, causing the buffer offset to go out of sync.

Arf, byteindex was added in 3.2...

What are the symptoms of this bug? What behavior or errors might the user see?

This bug was never released.

Hum, now that you mention it. I have no evidence it was possible, but if somehow the internal buffer was upgraded to UTF8 when appending bytes, it would lead to a ReadTimeout.
So perhaps, and I insist on the perhaps, it could explain some of the timeout issues reported, but only for people using the Ruby driver. And this is pure conjecture, I'll have a quick look to try to confirm whether this could ever happen before the performance refactor. And if that's the case, this only fixes it for Ruby 3.2+

Hum, so no, I tried various things, and I really don't think it was possible on 0.21.1.
The only two places the buffer is mutated are:

https://github.com/redis-rb/redis-client/blob/v0.21.1/lib/redis_client/ruby_connection/buffered_io.rb#L134
https://github.com/redis-rb/redis-client/blob/v0.21.1/lib/redis_client/ruby_connection/buffered_io.rb#L124

In both case it's handled by read_nonblock.
When passed a buffer, it doesn't change its encoding as long as there is a size provided (https://github.com/ruby/spec/pull/1145)
And when not passed a buffer, similarly, the return string is binary if a size is provided.
I nonetheless simulated this with TCP/UNIX/SSL sockets to double check and couldn't cause any timeout. I also went to audit the OpenSSL gem, and couldn't see any edge case in which it would return a non-binary string.
All this being said, it could be interesting to ask people to experience these issues to log the buffer and offset when it happens.

Yeah, I wondered if it might be the cause of mysterious Sidekiq errors people have been seeing. I missed the recency of the change but this feels like the type of subtle error that can persist (and only trigger very occasionally). Thanks for checking for me.

authors: byroot casperisfine mperham

repo: redis-rb/redis-client


text:
How do I set TTL in Redis OM as part of object mapping

Hi,
I would like to know how do I set TTL in Redis OM as part of object mapping
Appreciate your help
thanks
Jay

Thanks @bsbodden  for the quick response.
I have following annotation in my model class, but it does not expire after 5 sec.
@Document(timeToLive = 5)

repo: redis/redis-om-spring


text:
Add support for Streaming Reads and Writes to redis

https://ammar.io/blog/high-performance-redis-and-go
Should we consider adding similar support in rueidis?

Sure! Thank you for sharing the great blog and the great redjet.
I would also like rueidis to have streaming read/write abilities. I believe we can add those abilities to the DedicatedClient interface.

Stream read has been implemented in the #460. But I currently have no idea how to bring streaming write into the command builder interface. If someone has a better idea, please reopen this issue.

authors: DestroyerAlpha rueian

repo: redis/rueidis


text:
RedisException / UnsupportedOperationException on RMap.fastRemove when used with transaction

Expected behavior
No RedisException  when calling fastRemove ;-)
Actual behavior
We get an UnsupportedOperationException wrapped inside a RedisException:
Caused by: org.redisson.client.RedisException: Unexpected exception while processing command
		at org.redisson.command.CommandAsyncService.convertException(CommandAsyncService.java:299)
		at org.redisson.command.CommandAsyncService.get(CommandAsyncService.java:116)
		at org.redisson.RedissonObject.get(RedissonObject.java:90)
		at org.redisson.RedissonMap.fastRemove(RedissonMap.java:1475)

[...]

Caused by: java.lang.UnsupportedOperationException: remove
		at java.base/java.util.Iterator.remove(Iterator.java:102)
		at org.redisson.transaction.BaseTransactionalMap.lambda$fastRemoveOperationAsync$19(BaseTransactionalMap.java:482)
		at org.redisson.transaction.BaseTransactionalObject.lambda$executeLocked$1(BaseTransactionalObject.java:79)
		at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1146)
		at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
		at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2143)
		at org.redisson.command.RedisExecutor.handleReference(RedisExecutor.java:595)
		at org.redisson.command.RedisExecutor.handleSuccess(RedisExecutor.java:587)
		at org.redisson.command.RedisExecutor.handleResult(RedisExecutor.java:575)
		at org.redisson.command.RedisExecutor.checkAttemptPromise(RedisExecutor.java:552)
		at org.redisson.command.RedisExecutor.lambda$execute$5(RedisExecutor.java:195)

Steps to reproduce or test case
    var tx = redisson.createTransaction(TransactionOptions.defaults());

    var m = tx.getMap("test");
    m.fastPut("x", "y");
    m.fastRemove("x");

    tx.commit();

The fastPut before the fastRemove is crucial, if you don't do that the problem seems not to arise (no matter if the entry exists or not).
Redis version
Tested with redis docker container "redis:7.0.7-alpine".
Redisson version
3.22.1
Redisson configuration
Nothing special, I guess

Fixed. Thanks for report

authors: BernhardBln mrniko

repo: redisson/redisson


text:
After the redisson version was upgraded, the memory usage became 2-3 times the original

Redisson version was upgraded from 3.11.1 to 3.14.0. Why did the memory usage become 2-3 times the original? After analysis, it was found that the default encoding changed from FstCodec to MarshallingCodec. Is this related?

It might be. Both are buggy. Did you try Kryo5Codec?

Both are buggy

You mean the official recommendation is to use Kryo5Codec？

Yes

authors: bitkbitk mrniko


text:
Fixed 'race condition' while calling tryLock function

Fix race condition of PublishSubscribe.subscribe function.
I got RedisTimeoutException while calling RedissonLock.tryLock function. After this exception, 'tryLock' call on same key failed with exactly same exception and message.
2024-07-19T10:40:05.638Z ERROR 1 --- [tContainer#13-7] org.redisson.RedissonLock                : org.redisson.client.RedisTimeoutException: Unable to acquire subscription lock after 13ms. Try to increase 'subscriptionsPerConnection' and/or 'subscriptionConnectionPoolSize' parameters.\
\
java.util.concurrent.ExecutionException: org.redisson.client.RedisTimeoutException: Unable to acquire subscription lock after 13ms. Try to increase 'subscriptionsPerConnection' and/or 'subscriptionConnectionPoolSize' parameters.\
	at java.base/java.util.concurrent.CompletableFuture.reportGet(Unknown Source)\
	at java.base/java.util.concurrent.CompletableFuture.get(Unknown Source)\
	at org.redisson.RedissonLock.tryLock(RedissonLock.java:250)\

exception was thrown by first catch (line 252 RedisTimeoutException)
logging logic located in second catch (line 264, Logging Manager Name org.redisson.RedissonLock)
=> Origin exception was thrown by first thread, after then next threads received already raised exception .
finally we found the race condition on subscribe function of PublishSubscribe (LockPubSub).
https://github.com/redisson/redisson/blob/f86744d0ff38c3dbcffbcee65b7f9cd362722111/redisson/src/main/java/org/redisson/RedissonLock.java#L249-L267

Reproduction Procedure (rarely happen but possible)

s (CompletableFuture) completed successfully
just after 1, newPromise (CompletableFuture) completed with RedisTimeoutException
line 116 logic run after 2

e is null so entryName (lock key) does not removed.
value's promise (newPromise) already completedWithException
next call subscribe with same lock key would throw previous exception

https://github.com/redisson/redisson/blob/f86744d0ff38c3dbcffbcee65b7f9cd362722111/redisson/src/main/java/org/redisson/pubsub/PublishSubscribe.java#L111-L122

Thanks for contribution!


text:
Unable to login to harbor dashboard

Describe the bug
Unable to login to harbor dashboard after Keycloak redeployment (most probably)
To Reproduce
Steps to reproduce:

Open harbor dashboard in web browser: https://harbor.demo.eks.otomi.cloud/
You are redirected to login with IDP
Login as otomi.admin@redkubes.net
Redirected to harbor login dashboard
Click: LOGIN VIA OIDC PROVIDER
Logout from harbor and logout from https://otomi.dev.onprem.otomi.cloud
Remove and redeploy keycloak
Repeat steps 1-4
Observe dialog Set OIDC Username
Click Save button
Observe error Conflict, the user with same username or email has been onboarded.

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Additional context
Cluster: https://otomi.dev.onprem.otomi.cloud

Me and @j-zimnowoda just talked through possible solutions and we came up with these scenarios:

keycloak can be manipulated to use the IDPs sub as-is (requires work from keycloak, but it might not be possible because of referential integrity on the sub which is used as id consistently)
harbor can be manipulated to work with another claim than 'sub' and we map IDP sub to another claim in keycloak. Looking at their code they just expect a varchar(255) and have no index on it so it would be less work than option 1.

Option 2 is the shortest path here imo, as intuitively I think the keycloak devs won't support our request to screw up their database model.

I have asked for this feature with harbor: https://github.com/goharbor/harbor/issues/13674

@Morriz I am wondering if we can create a keycloak mapper for sub claim.
Then sub would be rewritten from original token?

@Morriz I am wondering if we can create a keycloak mapper for sub claim.
Then sub would be rewritten from original token?

@Morriz I am wondering if we can create a keycloak mapper for sub claim.
Then sub would be rewritten from original token.
I am just not sure about possible collisions if keycloak is an IdP broker for many IdPs.

@Morriz I am wondering if we can create a keycloak mapper for sub claim.
Then sub would be rewritten from original token.
I am just not sure about possible collisions if keycloak is an IdP broker for many IdPs.

I think that is a good idea, yes. We can provide configurations for multiple IDPs, so I don't see a problem there.

I think that is a good idea, yes. We can provide configurations for multiple IDPs, so I don't see a problem there.

@j-zimnowoda this needs prio as demos are failing again. Can you inplement that mapper?

I have created the mapper nut it does not seem to take into effect, as I see that keycloak still assign sub for a new users instead of reusing the original one.

I also was thinking to use script mappers but this option seems to be deprecated.
-Dkeycloak.profile.feature.upload_scripts=enable

We will create a mapper oidc to sub.

authors: Morriz j-zimnowoda

repo: redkubes/otomi-core


text:
Add sort order to photo album widget

Says Mike
The sort order (which got edited out) is another example of a ten minute job for somebody with really basic code skills.

If there were a "newbie" tag in the project issues on github, this could be tagged with it.

This might be up my alley. What needs to happen here? Does an argument need to just get passed along via Commanche to register what order the album is sorted in?

I know nothing about photo  albums, but know enough PHP and enough Hubzilla to have been able to trace this down to probably here:
https://github.com/redmatrix/hubzilla/blob/93e5449c0843494c49ae799fa044299ca5cdeb6d/include/widgets.php#L687
Following that trail leads here:
https://github.com/redmatrix/hubzilla/blob/93e5449c0843494c49ae799fa044299ca5cdeb6d/include/photos.php#L465
And, finally, it seems the list of albums comes from here:
https://github.com/redmatrix/hubzilla/blob/93e5449c0843494c49ae799fa044299ca5cdeb6d/include/photos.php#L425
If you're trying to sort them, learning some SQL would let you edit that SELECT query to perhaps sort them. If you're trying to sort the pictures in the album, I don't know where in Hubzilla that's done.
If you already know javascript, PHP is not to hard to learn. SQL is a different beast, but its basics not too hard to learn either.

Good insights - I don't really do too much beyond HTML/CSS/Commanche at the
moment, but maybe it's time to crack out a good beginner's PHP book.
On Wed, Nov 18, 2015 at 4:21 PM, ken restivo notifications@github.com
wrote:

I know nothing about photo albums, but know enough PHP and enough Hubzilla
to have been able to trace this down to probably here:
https://github.com/redmatrix/hubzilla/blob/93e5449c0843494c49ae799fa044299ca5cdeb6d/include/widgets.php#L687
Following that trail leads here:
https://github.com/redmatrix/hubzilla/blob/93e5449c0843494c49ae799fa044299ca5cdeb6d/include/photos.php#L465
And, finally, it seems the list of albums comes from here:
https://github.com/redmatrix/hubzilla/blob/93e5449c0843494c49ae799fa044299ca5cdeb6d/include/photos.php#L425
If you're trying to sort them, learning some SQL would let you edit that
SELECT query to perhaps sort them. If you're trying to sort the pictures in
the album, I don't know where in Hubzilla that's done.
If you already know javascript, PHP is not to hard to learn. SQL is a
different beast, but its basics not too hard to learn either.
—
Reply to this email directly or view it on GitHub
https://github.com/redmatrix/hubzilla/issues/163#issuecomment-157883495.

authors: DeadSuperHero kenrestivo

repo: redmatrix/hubzilla


text:
Fix nightly build

ct lint --all --config .github/ct-redpanda.yaml
Linting charts...
Error: failed loading configuration: specifying both, '--all' and '--charts', is not allowed
failed loading configuration: specifying both, '--all' and '--charts', is not allowed
Error: Process completed with exit code 1.

https://github.com/redpanda-data/helm-charts/actions/runs/5687162122/job/15415137752#step:6:11

I pushed one correction to this fix as none of the Github action workflow was triggered. Our PR requires summary and lint jobs.

repo: redpanda-data/helm-charts


text:
Avatar Tooltip Flickering Fixed

Flickering of Tooltip of Avatars from the Horizontal Avatar List on Dashboard has been fixed with minimal modular independent changes. While the user hovers over each of the avatar from the Horizontal Avatar List on the Dashboard,  if the hover is in the lower 50% of the circle of Avatar, the tooltip goes on flickering and eventually, the pages gets stuck. I have resolved the same, using minimal independent, modular changes. Please merge if it is suitable.

Thanks @HITISINHA 👍

repo: reduction-admin/react-reduction


text:
RS-287: Use case page for vibration data

use case page for vibration data: /use-cases/vibration-sensors
add card to page: /use-cases

@atimin first draft for our discussion

repo: reductstore/website


text:
How to check if page is loading from the component?

Right now I have this strategy implemented:

Component loads + dispatches an action to call an API
The sagas handling the request will save API progress in a state, something like this:

requests: {
  "/v1/page/get?param1=value1": {
    "loading": true,
    "loaded": false,
    "error": null
  }
}

When the page is loaded, the data is saved + the request state is updated. All of that is working good so far.

The problem is I'm not sure how to write isPageLoading() function... How can I call an asynchronous saga from my component? The reason I can't just check the state directly from the component is because my API URLs are "assembled" inside the saga, like that:
function*() {
  const site = yield select(getSelectedSite);
  return {
    method: 'GET',
    route: `/v1/site/${site}`
  };
}

...and it's baked into the request which is inside other sagas. So is there any way to call an asynchronous function from the component? Or how are these functions usually written?

So you dispatch an action like SELECT_SITE in smth like componentDidMount of the component and the data might be available right away (from the state) or asynchronously (needs to be fetched with saga)? And you are unsure how to write a selector for isPageLoading?
Im not quite sure if Ive grasped the issue you are facing, but cant you just raise a flag on your resource in the state to indicate that its loading or not? some REQUEST_SUCCESS would just put in the store loading: false then and you would be able to query such flag synchronously in every situation I think.

@Andarist thank you for responding.
Yeah, sorry I made it sound all complicating. To answer your questions: yes, you're basically right.
The issue is: this component has multiple ways it can load a page (there's many UI parameters -- black shoes, blue shoes, small shoes, large shoes, etc). So my state looks something like this:
requests: {
  "/v1/page/get?color=blue": {
    "loading": true,
    "loaded": false,
    "error": null
  },
  "/v1/page/get?color=black": {
    "loading": false,
    "loaded": true,
    "error": null
  },
  "/v1/page/get?color=blue&size=large": {
    "loading": false,
    "loaded": true,
    "error": null
  }
}

The way I made it work was to call a function like this: dispatch(loadPage({ color: "black", size: "large" })), so the component is not aware of the key in the state (eg: /v1/page/get?color=black&size=large) because the saga is the one composing that key, not the component.
Therefore, the component can't really check the state directly. I could theoretically just "re-create" the loading/not-loading flags in the component itself, but then I'll have two places where these flags are kept.
Do I have the wrong strategy for this?

I would try to think how to reorganize ur state better to normalize it, aint sure atm though whats the best approach.
However even with such shape - if if component doesnt know the key it did dispatch the fetching action based on which the saga was able to construct this key - so this could be extracted and the component could query ur state with those params and not the key itself (key would be created from the parama under the hood)

Ok. Yeah, that's true, the key composition code could be extracted. The problem is that code is in asynchronous sagas (it uses select for a few parameters), so I'm not sure yet how to extract it properly so that it could be in synchronous functions that component calls.
Alright, I'll keep thinking. Thanks for your feedback.

Could u share relevant parts of the key composition code? Would be easier to advise further.

@Andarist ok, thanks for following up. Let me try to show the basics in a simple way:
In component:
import { loadItems } from '../../redux/actions';
...
componentDidMount() {
  ...
  dispatch(loadItems(page, color, size, weight));
}

Then it creates an action (which is watched), which then triggers another action.
Now in that saga:
function* sagaLoadItems(action) {
  const params = {
    page: action.page,
    color: action.color,
    size: action.size,
    weight: action.weight
  };
  const { response, error } = yield fetch(items.get, params);
}

The items.get looks something like this:
const items = {
  get: function*() {
    const site = yield select(getSelectedSite);
    return {
      method: 'GET',
      route: `/v1/items/${site}/get`
    };
  }
}

And the fetch is my own generator wrapper that a) forms the proper url from parameters b) does the call to the API and c) puts the proper values in the requests state (loading, loaded, etc).
Seeing as how items.get + the wrapper are the ones "assembling" the URL with params (and they're generator functions), I am not sure how I can write a regular isLoading() function that "assembles" a proper URL given params and then checks the state...

Damn! This one is hard. Cannot think right now to restructure it with minimal effort :/
However component should be able to query the state in your example and I would think how to refactor ur state key and all to make it happen. Will give you benefits in the long run - simpler and more predictable code.

Ok, thank you for looking @Andarist :)

authors: Andarist ivanakimov

repo: redux-saga/redux-saga


text:
SagaTestError: Assertion 1 failed: call effects do not match

saga function
export function* signIn(action) {
  try {
    const response = yield call(axios.post, '/api/v1/users/signin',
      {
        email: action.email,
        password: action.password
      });

    const { token } = data.response;
    const decode = jwt.decode(token);
    localStorage.setItem('jwtToken', token);
    yield put({ type: actionTypes.SIGN_IN_SUCCESS, user: decode.user });
  } catch (error) {
    Materialize.toast(error.response.data.message, 4000, 'red');
    yield put({ type: actionTypes.SIGN_IN_ERROR });
  }
}

test using  import { testSaga } from 'redux-saga-test-plan'
const user = {
  email: 'chibuezeayogu@hotmail.com',
  password: 'ABDC123.@'
};

let saga = testSaga(signIn, user);

saga.next().call(mock.onPost, '/api/v1/users/signin', user);
saga.next().put({ type: actionTypes.SIGN_IN_SUCCESS, user: undefined })
saga.next().isDone();

what is fn: [Function: wrap] and the difference between   fn: [Function] and fn: [Function: wrap]

Functions have their unique identity, it's the very same as in:
const foo = {a:1}
const bar = {b:2}
foo === bar // false

If you want to compare effects using deep equality you are probably looking for this:
saga.next().call(axios.post, '/api/v1/users/signin', user);

axios.post will not be executed, because in tests you do not run your effects.

authors: Andarist chibuezeayogu


text:
Project status

Is this actively maintained? 👀 If so, can we get a new maintenance release soon?

Hey, sorry, I don't check up on this very often, but it is something I intend to check in on a couple of times a year to review any PRs or do light maintenance.
Do appreciate your PR, I'll review and create a new release for it this weekend.

Awesome, thanks! Great to hear that ❤

authors: orhun realfresh

repo: reemus-dev/gitnr


text:
[FEAT] Customization of RefineKbar

Is your feature request related to a problem? Please describe.
Currently it's possible to have resources with the same name but different identifiers. We are using this to differentiate between different databases, that have the same kind of model inside (i.e. Country). The problem here is that we cannot differentiate between the resources, since the dataProvider or dataProviderName is not taken into concern.
Describe alternatives you've considered

We could go ahead and rewrite the RefineKbar provider ourselves, but that'd just lead to a separating solution where nobody benefits ultimately
We could also just rewrite a similar provider, but then we'd face issues when it comes down to access control

Describe the thing to improve
The problem is that RefineKbar is not customizable. Customizing a component inside of a framework to your needs is ultimately what Refine should be able to do for its users. I'd love to see a way of providing a template or component for the RefineKbar component that might take specialized Resource-Attributes and just renders what the user passed in.

Hello @bastianwegge, thanks for the issue as always and sorry for the late reply.
Our KBar package is quite outdated atm, I've added this issue to our backlog, we'll work on this one in our next sprint!

Thanks for the reply @BatuhanW !
I have copied the code for useRefineKbar and adjusted the section like this which had the desired effect:
let section = label;
if (resource.meta?.parent) {
  section = `${resource.meta?.parent} ${t(
    `${resource.name}.${resource.name}`,
    userFriendlyResourceName(resource.name, 'plural'),
  )}`;
}

I think adding a render prop for both the section as well as the displayed action would make sense here. If you want to go all the way, you could also provide a way to create custom kbar-Actions and pass them to useRefineKbar.
Again thanks for working with my feedback! Looking forward to making progress here! 💪

Glad to see you have a workaround for now, stay tuned for the updates 🙌🏼

authors: BatuhanW bastianwegge

repo: refinedev/refine


text:
WIP: fix: react extract incorrect resource from encoded pathname

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Please provide enough information so that others can review your pull request:

Explain the details for making this change. What existing problem does the pull request solve?

Test plan (required)
Demonstrate the code is solid. If not, please add WIP: in its title.

Closing issues
Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if such).
Self Check before Merge
Please check all items below before review.

[x] Corresponding issues are created/updated or not needed
[ ] Docs are updated/provided or not needed
[ ] Examples are updated/provided or not needed
[ ] TypeScript definitions are updated/provided or not needed
[ ] Tests are updated/provided or not needed
[ ] Changesets are provided or not needed

Hi, @thaihuynhxyz. Thanks for the PR 🙏
I see you turned PR into draft. Do you have work to continue?

Hi @alicanerdurmaz , Sorry for that confusion, I have no update for this PR.

Hi @thaihuynhxyz Thank you again 🙏
can you add changeset please ? https://refine.dev/docs/contributing/#changeset
I think it's should be semver patch.

authors: alicanerdurmaz thaihuynhxyz


text:
Report a safari-specific test failure without halting all tests

As mentioned in #479, there's a safari-specific half float bug that brings tests to a halt. Rather than a new failure, I believe this is instead the result of a new check for behavior that does seem broken in safari: https://github.com/regl-project/regl/commit/75730b6098985260438c16afc6d9a933bc7f9f2c#diff-6d2e0d9813eb0b2330521d6a391021d3R169
This PR doesn't fix anything (Babylon, for one, just detects safari and reverts from half_float to float, I believe) but instead triggers a test failure that doesn't halt all tests.
In particular, it just wraps the test in a try/catch and reports a failure if it catches anything.

As far as we log them as failure I guess that is ok. :dagger:

As far as we log them as failure I guess that is ok. dancer

Yeah, I don't love it. 🙄 It's strictly a convenience so you can figure out more quickly what's passing or failing. WebGL seems vendor-specific enough that it's maybe more of a philosophical issue what it means for a test to fail… like is accounting for safari's quirks the user's responsibility or regl's responsibility? 🤷♂

authors: dy rreusser

repo: regl-project/regl


text:
what about docs?

hey, what should we do  for docs on this project? any thoughts @webhilltech

So we should:

[ ] create 'docs' folder
[ ] create new index.md doc
[ ] turn on github pages
[ ] decide if we want more complex


text:
Dynamic library hooks

A configuration file should be able to specify library names to be hooked and map them to simple behavior models.
I think we'd need to JIT compile our our libnvram (or do something crazy with hypercalls) before a rehosting runs. We'd still have some hand-crafted library shims, but then we'd be able to map arbitrary function names to these.
This model gets us away from having the long list of aliased functions in alias.c and let us configure it per target instead.

https://github.com/rehosting/penguin/pull/129

repo: rehosting/libnvram


text:
Update sqlite-jdbc to 3.39.3.0

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

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.xerial", artifactId = "sqlite-jdbc" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.xerial", artifactId = "sqlite-jdbc" }
}]

labels: library-update, commit-count:1

Superseded by #393.

repo: reibitto/podpodge


text:
🛑 Scribees is down

In 4cb0d5f, Scribees (https://binus.ac.id/scribees/login/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Scribees is back up in cc84267.


text:
🛑 GreatNusa.com is down

In ef2c55a, GreatNusa.com (https://greatnusa.com) was down:

HTTP code: 403
Response time: 71 ms

Resolved: GreatNusa.com is back up in c12ac74.


text:
Caching ?

Polyfill service has no caching. It will repeatedly filter and sort features given user agent. It should cache results based on list of features or browser info because it already knows the set of polyfills needed from the configuration xml

@scottmo @reiniergs

repo: reiniergs/polyfill-service


text:
(URGENT) Unable to fetch "ECMA-262"

This exists but cannot be fetched.
https://www.ecma-international.org/publications-and-standards/standards/ecma-262/
We should also allow edition numbers:

This is blocking:

https://github.com/metanorma/iso-10303-2/issues/141

@ronaldtse there are also volumes, for example ECMA-269

I suggest to use references like ECMA-269 e3 vol1. The edition "e" and volume "vol" are optional. If edition is ommited then the latest edition should be found. If volume is ommited then the first volume should be found. Edition can have major an minor numbers (ECMA-262 e5.1). Is it ok?

fixed in v 1.14.1 https://github.com/relaton/relaton-ecma#fetch-documents

there are also volumes, for example ECMA-269
I suggest to use references like ECMA-269 e3 vol1. The edition "e" and volume "vol" are optional. If edition is ommited then the latest edition should be found. If volume is ommited then the first volume should be found. Edition can have major an minor numbers (ECMA-262 e5.1). Is it ok?

I agree. Thanks!

repo: relaton/relaton-ecma


text:
Use IntObjectMap to cut down on boxing/GC pressure

This is not the biggest of deals, but we can use a sliiiiiiightly more efficient data structure for tracking push notifications and response promises that have not yet been attached to HTTP/2 streams.
Benchmarks for ApnsClientBenchmark.testSendNotifications:
Before
(concurrentConnections)  (notificationCount)  Mode  Cnt  Score   Error  Units
                      1                10000    ss   40  0.329 ± 0.012   s/op
                      4                10000    ss   40  0.345 ± 0.049   s/op
                      8                10000    ss   40  0.321 ± 0.022   s/op

After
(concurrentConnections)  (notificationCount)  Mode  Cnt  Score   Error  Units
                      1                10000    ss   40  0.329 ± 0.010   s/op
                      4                10000    ss   40  0.292 ± 0.018   s/op
                      8                10000    ss   40  0.297 ± 0.023   s/op

The results are promising, but almost suspiciously so. I might try again with more forks on a better-controlled machine, but I think the moral of the story here is that we're not obviously making things worse.

Further benchmarking shows the difference to be largely in the noise. Still, I think this does no harm and possibly does some good, so I'll merge it.

makes sense to me at least -- hashmaps can be expensive enough in GC terms.

:metal:

authors: jchambers jmason

repo: relayrides/pushy


text:
Support for Swift 3.0

Getting tons of errors trying to use it in Swift 3.0

Yes because they change a lot of API. I think right now it's better to make an another branch with the compatibility.

Yeah. I got it to work in Swift 3.0 :)

@remirobert do you plan to create a new branch that we can start sending pull requests to? I plan on getting it set up for Swift 3 but it would be nice to have 'official' support for it.

@aasatt I will do it on a different branch

@aasatt I created a new branch for swift 3. The framework is working. But I think we can improve the API.

Pod install is not working with swift 3.0

authors: aasatt danieldelouya nickgreetzly remirobert

repo: remirobert/CameraEngine


text:
Fix magic export deprecation messaging

This reverts #3284 due to a few unforeseen issues:

The concatenating of files resulted in duplicate definitions of const getDeprecatedMessage and const warn which caused build failures
The import and actual usage of things in the ESM file broke the ability to tree-shake server-only code out of client bundles:

// Tree shakes correctly as long as things aren't used
export { createCookie } from '@remix-run/node`;

// Doesn't tree shake because `createCookie` is imported and referenced
import * as node from '@remix-run/node';
const createCookie = warn(node.createCookie, ...);

Instead this goes back to the old direct-export approach and adds a single global warning to the top of the file.  We lose the "warning-per-import" benefit but keep the ability to tree shake.

It would be a shame to revert #3284 imo, as we would lose TS deprecations that way, which are another added benefit imo.
Since this only seems to be impacting ESM builds, can we at least keep CJS & TS?

The concatenating of files resulted in duplicate definitions of const getDeprecatedMessage and const warn which caused build failures

This could be fixed by removing it from the specific magicExports file & including it in the concatenated file or we could rename these functions to getDeprecatedMessage_[package-name] & warn_[package-name] to not have duplicate function names 🤔

The import and actual usage of things in the ESM file broke the ability to tree-shake server-only code out of client bundles:

// Tree shakes correctly as long as things aren't used
export { createCookie } from '@remix-run/node`;

// Doesn't tree shake because `createCookie` is imported and referenced
import * as node from '@remix-run/node';
const createCookie = warn(node.createCookie, ...);

So if we can update the ESM imports properly, we can keep these I guess?

@MichaelDeBoey Definitely open to suggestions, this was just the quick fix towards getting 1.8.0-pre.1 out for community testing.
I like the idea of keeping the TS deprecation warnings.
I'm not sure if this would work for ESM, since the import is used and therefore I don't think qualifies for tree-shaking:
import { createCookie as node_createCookie } from '@remix-run/node';
/** @deprecated Import `createCookie` from `@remix-run/node` instead. */
const createCookie = warn(node_createCookie, getDeprecatedMessage('createCookie', '@remix-run/node'));
//                        ^ by accessing the imported thing here, I don't think it'll be tree shaken

Let me see about keeping the types.  I think I lean towards keeping the CJS/ESM approaches the same to avoid unintended behavioral differences, but curious what others think there too.
I did the _{packagename} suffix locally as well and it fixes the duplicate identifier issue, but we would also need to enhance the warn function since the react components aren't functions and instead react element objects, so they need to be exported as is instead of called as a function.

I'm not sure if this would work for ESM, since the import is used and therefore I don't think qualifies for tree-shaking:
import { createCookie as node_createCookie } from '@remix-run/node';
/** @deprecated Import `createCookie` from `@remix-run/node` instead. */
const createCookie = warn(node_createCookie, getDeprecatedMessage('createCookie', '@remix-run/node'));
//                        ^ by accessing the imported thing here, I don't think it'll be tree shaken

What about changing it to the following?
import node from '@remix-run/node';
/** @deprecated Import `createCookie` from `@remix-run/node` instead. */
const createCookie = warn(node.createCookie, getDeprecatedMessage('createCookie', '@remix-run/node'));

Let me see about keeping the types. I think I lean towards keeping the CJS/ESM approaches the same to avoid unintended behavioral differences, but curious what others think there too.

This would mean we would loose the benefit of the deprecated JSdoc on all these functions

we would also need to enhance the warn function since the react components aren't functions and instead react element objects, so they need to be exported as is instead of called as a function.

Since our React component are function components, it's basically the same as a normal function, no?
Also: the warn function is re-exporting the same functionality as the original function was doing.

@MichaelDeBoey As soon as we reference anything from @remix-run/node in any way in that bundle, other than a direct re-export, it's unable to be tree shaken and ends up in the client bundle - since the calling of warn is a side effect which breaks tree-shaking:

I added back in the TS deprecations in 5083780 👍
Then @jacob-ebey had a better idea of how we can do this warning at build-time via an esbuild plugin, rather than litter runtime server/browser logs with these warnings (see 229503e).  This allows us to better point the user at the file with the problematic import.
I think the React component was potentially from Link being a React.forwardRef - the fn coming into warn was a react-looking object instead of a function in my testing.

repo: remix-run/remix


text:
Added fields to ParameterException for #402

Extra fields have been added to ParameterException (argSpec and value) to allow more granular handling of bad parameters by the user.

Codecov Report

Merging #406 into master will decrease coverage by 0.01%.
The diff coverage is 96.29%.

@@             Coverage Diff              @@
##             master     #406      +/-   ##
============================================
- Coverage     89.24%   89.22%   -0.02%
  Complexity      248      248
============================================
  Files             4        4
  Lines          3404     3426      +22
  Branches        810      810
============================================
+ Hits           3038     3057      +19
- Misses          180      183       +3
  Partials        186      186

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/picocli/CommandLine.java
89.35% <96.29%> (-0.03%)
128 <0> (ø)

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 fe17b99...a8c0a24. Read the comment docs.

authors: codecov-io dhait

repo: remkop/picocli


text:
Update to Rails 5.0.1.rc1

This will allow the use of the new Ruby 2.4.0 that is being released in December (currently Ruby 2.4.0-preview3)

Addressed in commit f84727e5eb8fc80560c7089c67279c22026828fa

repo: remomueller/slice


text:
Updating usage of InheritedWidget due to Flutter SDK v1.12.1

Avoiding context.inheritFromWidgetOfExactType and using context.dependOnInheritedWidgetOfExactType

Thanx

authors: kranfix renancaraujo