ReentrantMutex hangs with fibers, even after 3.11.0

Subject of the issue
Hi! I'm following up on a reported Rspec hangup with GraphQL-Ruby's "Dataloader," a fiber-based data batching library (Original bug report: https://github.com/rmosolgo/graphql-ruby/issues/4172). The original report also included a replication: https://github.com/khamusa/gql-dataloader-rspec-mocks-hanging/pull/1/commits/fd6c05b4394fe9be72960a5b7548f94caf8d1d71#diff-cd6746fe941432087bd4ad1ba284ce7e6d3f94ef62e3954e8c04fcc007ba3968R3
I see that there has been recent work on this in rspec/rspec-core#503, etc, but even on 3.11.0, I see this stuck process.
I cloned the replication repo and triggered the reported bug, then inspected the stuck ruby process with rbspy snapshot, and here's what I saw:

 Stack trace of stuck ruby process

block in spawn_fiber - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/dataloader.rb:304
block in run - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/dataloader.rb:183
block (3 levels) in coerce_arguments - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/member/has_arguments.rb:249
block in evaluate_selection - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:429
evaluate_selection_with_args - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:530
after_lazy - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:929
block in evaluate_selection_with_args - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:529
call_method_on_directives - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:830
block (2 levels) in evaluate_selection_with_args - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:518
trace - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/tracing.rb:67
block (3 levels) in evaluate_selection_with_args - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/execution/interpreter/runtime.rb:502
resolve - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/field.rb:747
after_lazy - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema.rb:1033
block in resolve - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/field.rb:727
with_extensions - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/field.rb:836
block (2 levels) in resolve - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/field.rb:723
public_send [c function] - (unknown):0
resolve_with_support - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/relay_classic_mutation.rb:70
resolve_with_support - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/resolver.rb:116
after_lazy - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema.rb:1033
block in resolve_with_support - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/resolver.rb:115
after_lazy - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema.rb:1033
block (2 levels) in resolve_with_support - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/resolver.rb:113
after_lazy - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema.rb:1033
block (3 levels) in resolve_with_support - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/graphql-2.0.13/lib/graphql/schema/resolver.rb:112
public_send [c function] - (unknown):0
resolve - /Users/rmosolgo/code/gql-dataloader-rspec-mocks-hanging/spec/debugging_issue_spec.rb:24
block (2 levels) in define_proxy_method - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/method_double.rb:65
proxy_method_invoked - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/verifying_proxy.rb:162
proxy_method_invoked - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/method_double.rb:81
message_received - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/proxy.rb:367
message_received - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/proxy.rb:232
invoke - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/message_expectation.rb:476
invoke_incrementing_actual_calls_by - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/message_expectation.rb:630
call - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/message_expectation.rb:765
map [c function] - (unknown):0
block in call - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-mocks-3.11.1/lib/rspec/mocks/message_expectation.rb:764
block (5 levels) in <top (required)> - /Users/rmosolgo/code/gql-dataloader-rspec-mocks-hanging/spec/debugging_issue_spec.rb:78
block in let - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-core-3.11.0/lib/rspec/core/memoized_helpers.rb:343
fetch_or_store - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-core-3.11.0/lib/rspec/core/memoized_helpers.rb:182
fetch [c function] - (unknown):0
block in fetch_or_store - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-core-3.11.0/lib/rspec/core/memoized_helpers.rb:181
synchronize - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-support-3.11.0/lib/rspec/support/reentrant_mutex.rb:26
enter - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-support-3.11.0/lib/rspec/support/reentrant_mutex.rb:36
lock [c function] - (unknown):0

It seems to me like GraphQL-Ruby is executing a query, which happens inside a newly-created fiber, and then that query calls a mocked method (specifically, a method with a block-style mock), and during that block, it calls a let(...)-ed method, and during that call, the process hangs. (The let(...)ed method never returns.)
I expect this test to continue running, but is there another way it should be written? (Or, maybe something is out-of-sorts with GraphQL-Ruby's use of Fibers?)
Your environment

Ruby version: 3.0.3
rspec-support version: 3.11.0

Steps to reproduce
git clone git@github.com:khamusa/gql-dataloader-rspec-mocks-hanging.git
cd gql-dataloader-rspec-mocks-hanging
git checkout bug-demo
bundle
bundle exec rspec

Expected behavior
The let(...) value should return and the test should continue running
Actual behavior
The test hangs forever, with the rbspy snapshot pointing at:
fetch_or_store - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-core-3.11.0/lib/rspec/core/memoized_helpers.rb:182
fetch [c function] - (unknown):0
block in fetch_or_store - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-core-3.11.0/lib/rspec/core/memoized_helpers.rb:181
synchronize - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-support-3.11.0/lib/rspec/support/reentrant_mutex.rb:26
enter - /Users/rmosolgo/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rspec-support-3.11.0/lib/rspec/support/reentrant_mutex.rb:36
lock [c function] - (unknown):0

Hey @JonRowe, sure thing, I just worked up a minimal reproduction here: https://github.com/rmosolgo/rspec-support/commit/8a32cffcf155f775821edee6de5529a9c7193907
Interestingly, I found that subject(...) was also required to replicate the problem -- if I moved that call into the test body, it didn't hang!
I don't think there's any messing with Thread.current in the code there.

I don't this is a problem with ReentrantMutex; it is likely a duplicate of this issue with rspec-core: https://github.com/rspec/rspec-core/issues/2064 due how locking semantics changed with Ruby 3.

I actually verified that ReentrantMutex is not the cause in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102625#note_1156203743 by patching rspec-support to use Ruby's Monitor type, which is also reentrant.
Speaking of which, why does rspect-support not use Monitor to provide reentrancy?

Speaking of which, why does rspect-support not use Monitor to provide reentrancy?

Off the top of my head, Monitor was introduced after Ruby 1.8.7 that we still support in RSPec 3.
It’s an option to use Monitor, and fall back to ReentrantMutex, or just switch to Monitor in RSpec 4.
Mind sending a PR to the 4-0-dev branch with your patch?

Ah I see - makes sense :+1:
I wonder if this work is necessary at this point since it is being discussed to remove locks around memoized blocks completely in https://github.com/rspec/rspec-core/issues/2064
I would say let's wait for a decision about what should happen to threadsafe since that is the crux of the matter, not the lock implementation.

If you research the original development of this you'll find Monitor was actually the source of the original ReentrantMutex definition, with the desired chunks being essentially vendored to remove the dependency on it (we consider anything that requires a require a dependency to be minimized to avoid environment poisoning).

Closing this as a duplicate of rspec/rspec#14 during cleanup for the monorepo.


Feature/c file input accept types

What?
Adding in accept attribute support for c-file-input component.
Why?
Needed to convert some of the UCC settings pages over. Also just a good thing to have.

Coverage decreased (-0.1%) to 72.357% when pulling<PHONE_NUMBER>781839f6aa849777537710fa03f3db on harlio:feature/c-file-input-accept-types into 95ed8732645b05db1d549bb0a46974dc72f4bc01 on bindable-ui:master.


Feature request - piping in an image

Hi - this is an amazing node so far! Is there a way to include a way (possibly an image input  parameter) to allow you to automatically (via workflow) send an image into the paint space? An example of how another node that does this is here - https://github.com/Lerc/canvas_tab (though it would be easier to simply connect up an image output from somewhere else and connecting it to the input of this node, etc.

Probably everything is possible, but we need to look at how best to implement it, because... images are obtained after generation or a request is made to the script from the front end, and then downloaded. I haven’t had time to look at this script yet, but they already wrote https://github.com/AlekPet/ComfyUI_Custom_Nodes_AlekPet/issues/20

Is there an update on adding this feature?

Is there an update on adding this feature?

Not yet, I think even if you do this, it will most likely be the background or image, in PainterNode

Is there an update on adding this feature?

Add piping: https://github.com/AlekPet/ComfyUI_Custom_Nodes_AlekPet/tree/master/PainterNode#piping

Hi - i just updated the custom node set and tried to connect VAE decode image to the input of the painter node and it still wouldn't connect to it. Is there anything else special I need to do to get this to work?

Hi - i just updated the custom node set and tried to connect VAE decode image to the input of the painter node and it still wouldn't connect to it. Is there anything else special I need to do to get this to work?

Hello/ Check if my ComfyUI_Custom_Nodes_AlekPet folder is in the web/extensions folder, if so, delete the folder. Now all files are collected in custom_nodes/ComfyUI_Custom_Nodes_AlekPet/web_alekpet_nodes
. Alternatively, you can completely move the ComfyUI_Custom_Nodes_AlekPet folder from custom_nodes/ somewhere (or delete it) and reinstall it via git clone

Hi - i just updated the custom node set and tried to connect VAE decode image to the input of the painter node and it still wouldn't connect to it. Is there anything else special I need to do to get this to work?

Hello! Check if my AlekPet_Nodes folder is in the web/extensions folder, if so, delete the folder. Now all files are collected in custom_nodes/ComfyUI_Custom_Nodes_AlekPet/web_alekpet_nodes . Alternatively, you can completely move the ComfyUI_Custom_Nodes_AlekPet folder from custom_nodes/ somewhere (or delete it) and reinstall it via git clone

Also check if you have updated the node, there should be a Settings button at the bottom with a key icon to control piping


[runtime] enhanced and refactored recently added Mutex abstraction

added read / write lock support
added non-fatal error support to allow use of mutex in fatal error reporting pathway
isolated pthread implementation to it own header/cpp file pair
expanded unit tests to cover new code as well as better test existing mutex
removed a layer of complexity that added no real value
added static allocation friendly versions of Mutex, ConditionVariable, and ReadWriteLock

Resolved bug number: (SR-946)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Looking at conflict now.

Not a review, just triggering the CI.
@swift-ci Please test

Offline until morning (PST).

Looks like both Linux and Mac passed thanks for the early CI run.

Think I dealt with most comments with an open question or two for folks. If possible getting a CI and benchmark run would be helpful.

@swift-ci Please test
@swift-ci Please benchmark

@swift-ci Please test

!!! Couldn't read commit file !!!

In addition to CI, some should verify that this doesn't introduce any additional -Wglobal-constructors or -destructors warnings.

Looks like a lingering use of Condition instead of ConditionVariable not sure why my local benchmark run didn't flag it.

This is not a review of anything in this patch, but when writing tests for your synchronization primitives please bear in mind that 1) sleeping for XX ms is not sufficient to always have all your threads started and 2)  gtest ASSERT_* macros won't force the test to stop running if they happen inside a thread, since they work by using 'return'.
I just fixed a race in the previous tests with fa77a7a.

Yeah that test has been reworked in this patch for that very reason. I had made a comment on the prior PR about that issue after it was reported to be seen on Linux.

I'm looking at Mutex::lockOrWait(). Its body is equivalent to below code, is it right?
template <typename CriticalSection>
   void lockOrWait(ConditionVariable &condition,
                   CriticalSection criticalSection) {
     lock([&] {
       while (!criticalSection()) {
         wait(condition);
       }
     });
   }

  lock();
  while (!criticalSection()) {
    ConditionPlatformHelper::wait(condition.Handle, Handle);
  }
  unlock();

According to their manuals, all three condition variable's wait function (pthread, <condition_variable>, Win32) release the associated lock. I think the second while loop will be running in unlocked.

Upon successful return, the mutex shall have been locked and shall be owned by the calling thread.
I believe the above is universal for condition wait behavior (quoted from http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html). You must hold the lock before calling wait, then before waiting (blocking calling thread) the wait function drops the lock, and before wait returns (assuming no error / timeout) it must reacquire the lock.

So while looping the lock is held except when inside of the wait call.

Oh I understand. I was wrong about pthread, <condition_variable>, but Win32 SleepConditionVariableSRW() may differ.

I see the following community addition to the docs about SleepConditionVariableSRW(). I would be very surprised if it didn't acquire the lock before returning.

Even after the wait time expires, this function does not return until it acquires the lock again no matter how long it takes. This thread must always release the lock regardless of the return value. The return value indicates that the conditional variable was set (true) or wait timed out (false + ERROR_TIMEOUT).

Yes, I confirmed with test code. It locks again !. MSDN document was poor. Thanks for reference.

I wrote MutexWin32.cpp(.h) and they passed your test code unittests/runtime/Mutex.cpp. It was very simple. Thanks you.

I think this is finally good to go. It will need a CI & benchmark before any attempt to merge.
I have held off removing ReadWriteLock::readWriteLock([]{}, []{}) for the moment since unlock got separated into readUnlock and writeUnlock in support of Win32 version of this code. The abstraction helps avoid mistakes with calling the wrong unlock (granted likely easily detected in testing) and of course avoids duplication of code in typical fast path / slow path type usage of read write locks. I will remove it folks want.

@swift-ci Please test
@swift-ci Please benchmark

@swift-ci Please test

!!! Couldn't read commit file !!!

@shawnce There's some linker heartburn:
Undefined symbols for architecture x86_64:
  "swift::Condition::notifyAll()", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::Condition::Condition()", referenced from:
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::BoxCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(HeapObject.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::ObjCClassCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::FunctionCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::TupleCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::MetatypeCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::GenericCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::WitnessTableCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::lock()", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::wait(swift::Condition&)", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::unlock()", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::MutexImpl(bool)", referenced from:
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::BoxCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(HeapObject.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::ObjCClassCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::FunctionCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::TupleCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::MetatypeCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<(anonymous namespace)::ForeignTypeState>::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::GenericCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      ...
ld: symbol(s) not found for architecture x86_64

@jckarter I spotted that I can't explain why that is happening. Can a plain CI run be done to confirm what I am seeing on my end (I don't see any linker issues, etc.). I will rerun benchmarks locally to confirm I see no issues (didn't see any last time).

@swift-ci Please test

@jckarter the issue looks specific to what the benchmark operation is doing. I can build --benchmark locally without issues. I suspect somehow a reference branch is being made from some invalid merge point that is resulting in a mix of old and new code trying to be compiled.
Any place I can look to see how a given CI build is setup, to understand the command executed, etc.?

@shahmishal Any idea why the benchmark runner would fail with linker errors when the normal CI works?

I looked the failed benchmark consol output https://ci.swift.org/job/swift-PR-osx-perf/35/console. I think the problem is in the ci build process.
The commit a0452be removed stdlib/public/runtime/Mutex.cpp and added stdlib/public/runtime/MutexPThread.cpp, but the benchmark compiled both.
It seems it tested without MutexPThread.cpp, and older source set. There is no MutexImpl class in current commit, isn't it?
[505/949] Building CXX object stdlib/public/runtime/CMakeFiles/swiftRuntime-macosx-x86_64.dir/Mutex.cpp.o
.....
[30/167] Building CXX object stdlib/public/runtime/CMakeFiles/swiftRuntime-macosx-x86_64.dir/MutexPThread.cpp.o
.....
"swift::MutexImpl::lock()", referenced from:

@shahmishal @jckarter Do the build commands exist in git someplace for what the benchmark CI plan does? ..or does a lot of that live in Jenkins? Would a new pull request potentially side step some state that may have a hand in an incorrect merge being used?

@swift-ci Please benchmark

@shawnce Benchmark bot:

Checkout master branch  (Targeted Branch)
run swift/utils/build-script -R --no-assertions --benchmark
Checkout origin/pr/1950/merge
run swift/utils/build-script -R --no-assertions --benchmark
Upload the results to GitHub pull request.

Build comment file:
Optimized (O)

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ClassArrayGetter
12
13
+8.3%
0.92x

Improvement (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeFromNSArrayAnyObjectToString
166404
155969
-6.3%
1.07x(?)

No Changes (113)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeToNSSet
16349
15737
-3.7%
1.04x(?)

DictionaryLiteral
3418
3277
-4.1%
1.04x

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
190926
185476
-2.9%
1.03x

ObjectiveCBridgeStubFromArrayOfNSString
113176
109936
-2.9%
1.03x(?)

Array2D
2024
1981
-2.1%
1.02x(?)

StringInterpolation
10080
9920
-1.6%
1.02x

Walsh
311
306
-1.6%
1.02x

ObjectiveCBridgeToNSArray
29678
29149
-1.8%
1.02x(?)

ObjectiveCBridgeToNSDictionary
16343
16057
-1.8%
1.02x(?)

DictionaryRemove
4799
4718
-1.7%
1.02x(?)

NSStringConversion
616
606
-1.6%
1.02x

Chars
670
660
-1.5%
1.02x(?)

ArraySubscript
1338
1330
-0.6%
1.01x

ObjectiveCBridgeFromNSArrayAnyObjectForced
3654
3617
-1.0%
1.01x

ErrorHandling
2866
2829
-1.3%
1.01x(?)

ArrayLiteral
993
987
-0.6%
1.01x(?)

ProtocolDispatch2
163
162
-0.6%
1.01x

DictionarySwapOfObjects
7176
7116
-0.8%
1.01x(?)

StrComplexWalk
2808
2783
-0.9%
1.01x(?)

ArrayOfRef
3454
3434
-0.6%
1.01x(?)

ObjectiveCBridgeFromNSArrayAnyObject
63195
62477
-1.1%
1.01x(?)

NSDictionaryCastToSwift
8554
8436
-1.4%
1.01x(?)

HashTest
1807
1791
-0.9%
1.01x(?)

LinkedList
8997
8931
-0.7%
1.01x(?)

MonteCarloPi
42564
42587
+0.1%
1.00x

StackPromo
18991
18990
-0.0%
1.00x(?)

RecursiveOwnedParameter
1829
1829
+0.0%
1.00x

ObjectiveCBridgeStubToNSString
1373
1375
+0.1%
1.00x(?)

Histogram
652
652
+0.0%
1.00x

SortStrings
1753
1747
-0.3%
1.00x

DictionaryBridge
3528
3530
+0.1%
1.00x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
4550
4567
+0.4%
1.00x(?)

ArrayOfGenericPOD
207
208
+0.5%
1.00x

StringWithCString
81188
81245
+0.1%
1.00x(?)

ObjectiveCBridgeFromNSStringForced
2202
2194
-0.4%
1.00x(?)

Prims
729
730
+0.1%
1.00x(?)

SortLettersInPlace
1003
1001
-0.2%
1.00x

PopFrontArray
1228
1230
+0.2%
1.00x(?)

Dictionary3OfObjects
1184
1185
+0.1%
1.00x(?)

ByteSwap
1
1
+0.0%
1.00x

SuperChars
282895
283773
+0.3%
1.00x(?)

XorLoop
359
359
+0.0%
1.00x

ObjectiveCBridgeStubFromNSStringRef
327
327
+0.0%
1.00x

ProtocolDispatch
2879
2885
+0.2%
1.00x(?)

ObjectAllocation
141
141
+0.0%
1.00x

TypeFlood
0
0
+0.0%
1.00x

ObjectiveCBridgeFromNSSetAnyObject
93758
94213
+0.5%
1.00x(?)

Dictionary3
726
727
+0.1%
1.00x(?)

Dictionary2
2399
2400
+0.0%
1.00x(?)

SetIntersect_OfObjects
2728
2719
-0.3%
1.00x(?)

NSError
353
352
-0.3%
1.00x(?)

DictionaryOfObjects
2687
2693
+0.2%
1.00x(?)

PopFrontUnsafePointer
8506
8501
-0.1%
1.00x(?)

PolymorphicCalls
61
61
+0.0%
1.00x

114
2243449
2236732
-0.3%
1.00x

Hanoi
3431
3414
-0.5%
1.00x(?)

OpenClose
49
49
+0.0%
1.00x

DictionaryRemoveOfObjects
19410
19485
+0.4%
1.00x(?)

UTF8Decode
257
256
-0.4%
1.00x

SetIsSubsetOf
480
479
-0.2%
1.00x

NopDeinit
34609
34660
+0.1%
1.00x(?)

SetIntersect
1134
1133
-0.1%
1.00x(?)

RGBHistogramOfObjects
22346
22384
+0.2%
1.00x

StringBuilder
1369
1365
-0.3%
1.00x(?)

Phonebook
9288
9299
+0.1%
1.00x(?)

Sim2DArray
413
411
-0.5%
1.00x(?)

SetExclusiveOr_OfObjects
8855
8839
-0.2%
1.00x(?)

MonteCarloE
10048
10034
-0.1%
1.00x(?)

SetUnion_OfObjects
7013
7020
+0.1%
1.00x(?)

RC4
251
251
+0.0%
1.00x

SetIsSubsetOf_OfObjects
540
540
+0.0%
1.00x

ArrayAppend
730
728
-0.3%
1.00x(?)

RGBHistogram
3359
3352
-0.2%
1.00x(?)

ArrayValueProp4
5
5
+0.0%
1.00x

ArrayOfPOD
172
172
+0.0%
1.00x

SetUnion
3242
3234
-0.2%
1.00x

StrToInt
3622
3632
+0.3%
1.00x(?)

BitCount
1
1
+0.0%
1.00x

AngryPhonebook
3367
3358
-0.3%
1.00x(?)

SevenBoom
1267
1269
+0.2%
1.00x(?)

StringWalk
6438
6452
+0.2%
1.00x(?)

ArrayValueProp
5
5
+0.0%
1.00x

GlobalClass
0
0
+0.0%
1.00x

Memset
222
222
+0.0%
1.00x

ArrayAppendReserved
508
508
+0.0%
1.00x

ArrayValueProp2
5
5
+0.0%
1.00x

ArrayValueProp3
5
5
+0.0%
1.00x

ObjectiveCBridgeToNSString
1021
1028
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
184245
186150
+1.0%
0.99x(?)

DictionarySwap
757
762
+0.7%
0.99x(?)

Integrate
228
230
+0.9%
0.99x(?)

ObjectiveCBridgeStubFromNSString
697
701
+0.6%
0.99x(?)

Join
428
433
+1.2%
0.99x

PopFrontArrayGeneric
1255
1262
+0.6%
0.99x

CaptureProp
3752
3779
+0.7%
0.99x(?)

MapReduce
329
332
+0.9%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
122660
124131
+1.2%
0.99x(?)

Dictionary
959
973
+1.5%
0.99x

ArrayInClass
82
83
+1.2%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
106501
107077
+0.5%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectToString
169579
171590
+1.2%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
4023
4070
+1.2%
0.99x(?)

DeadArray
176
177
+0.6%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
159423
160487
+0.7%
0.99x(?)

Dictionary2OfObjects
3969
4005
+0.9%
0.99x

TwoSum
1713
1727
+0.8%
0.99x

RangeAssignment
262
266
+1.5%
0.98x(?)

ObjectiveCBridgeStubToArrayOfNSString
29702
30248
+1.8%
0.98x(?)

SetExclusiveOr
3782
3844
+1.6%
0.98x

ArrayOfGenericRef
3475
3542
+1.9%
0.98x(?)

ObjectiveCBridgeFromNSString
1529
1553
+1.6%
0.98x(?)

StaticArray
2598
2672
+2.9%
0.97x(?)

Calculator
32
33
+3.1%
0.97x

**Unoptimized (Onone)**

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

TypeFlood
142
151
+6.3%
0.94x(?)

Improvement (0)

No Changes (114)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
121775
116408
-4.4%
1.05x(?)

OpenClose
451
433
-4.0%
1.04x(?)

DictionaryOfObjects
7282
7049
-3.2%
1.03x

StringWalk
42766
41327
-3.4%
1.03x(?)

StringInterpolation
13674
13419
-1.9%
1.02x(?)

StrComplexWalk
7871
7686
-2.4%
1.02x

PopFrontArrayGeneric
12442
12203
-1.9%
1.02x

CaptureProp
55130
54267
-1.6%
1.02x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
127072
124314
-2.2%
1.02x

StackPromo
80945
80335
-0.8%
1.01x(?)

Histogram
13859
13768
-0.7%
1.01x(?)

PopFrontArray
12262
12107
-1.3%
1.01x(?)

ErrorHandling
7241
7181
-0.8%
1.01x(?)

ObjectiveCBridgeStubFromNSString
1138
1132
-0.5%
1.01x

ProtocolDispatch
5602
5568
-0.6%
1.01x(?)

MapReduce
45175
44618
-1.2%
1.01x(?)

Integrate
348
346
-0.6%
1.01x

UTF8Decode
39402
39202
-0.5%
1.01x(?)

Dictionary
4532
4500
-0.7%
1.01x

ObjectiveCBridgeStubToArrayOfNSString
30424
30172
-0.8%
1.01x(?)

StringBuilder
8268
8153
-1.4%
1.01x(?)

TwoSum
9273
9193
-0.9%
1.01x(?)

ArraySubscript
4450
4448
-0.0%
1.00x(?)

DictionarySwapOfObjects
25809
25767
-0.2%
1.00x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
192412
191679
-0.4%
1.00x(?)

RecursiveOwnedParameter
10283
10293
+0.1%
1.00x(?)

ObjectiveCBridgeStubToNSString
1672
1676
+0.2%
1.00x

ClassArrayGetter
1264
1264
+0.0%
1.00x

Array2D
697294
697454
+0.0%
1.00x(?)

SortStrings
5672
5652
-0.3%
1.00x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
7074
7042
-0.5%
1.00x(?)

MonteCarloPi
50224
50226
+0.0%
1.00x(?)

StringWithCString
713012
712645
-0.1%
1.00x(?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
7029
7038
+0.1%
1.00x(?)

Prims
13669
13646
-0.2%
1.00x(?)

SortLettersInPlace
2319
2315
-0.2%
1.00x(?)

DictionarySwap
11593
11587
-0.1%
1.00x(?)

ByteSwap
9
9
+0.0%
1.00x

XorLoop
18434
18445
+0.1%
1.00x(?)

ObjectiveCBridgeStubFromNSStringRef
651
651
+0.0%
1.00x

StaticArray
17031
16984
-0.3%
1.00x(?)

ArrayLiteral
1033
1035
+0.2%
1.00x(?)

Walsh
12244
12243
-0.0%
1.00x(?)

Dictionary3
2099
2098
-0.1%
1.00x(?)

Dictionary2
5147
5143
-0.1%
1.00x(?)

SetIntersect_OfObjects
18893
18918
+0.1%
1.00x(?)

Join
1340
1334
-0.5%
1.00x

ArrayOfRef
9929
9908
-0.2%
1.00x(?)

PopFrontUnsafePointer
95350
95047
-0.3%
1.00x(?)

Calculator
932
931
-0.1%
1.00x

DictionaryRemoveOfObjects
60971
60879
-0.1%
1.00x(?)

SetIsSubsetOf
2952
2948
-0.1%
1.00x(?)

NopDeinit
53314
53273
-0.1%
1.00x(?)

SetIntersect
18837
18853
+0.1%
1.00x(?)

SetExclusiveOr
48566
48583
+0.0%
1.00x(?)

RGBHistogramOfObjects
97745
98173
+0.4%
1.00x(?)

ArrayInClass
3648
3647
-0.0%
1.00x

ArrayOfGenericRef
10569
10563
-0.1%
1.00x(?)

Phonebook
59729
59869
+0.2%
1.00x(?)

Sim2DArray
13143
13139
-0.0%
1.00x(?)

SetExclusiveOr_OfObjects
66912
66855
-0.1%
1.00x(?)

MonteCarloE
98538
98873
+0.3%
1.00x

SetUnion_OfObjects
51158
51146
-0.0%
1.00x(?)

GlobalClass
0
0
+0.0%
1.00x

HashTest
6016
6036
+0.3%
1.00x

SetIsSubsetOf_OfObjects
2835
2847
+0.4%
1.00x(?)

ArrayAppend
2874
2865
-0.3%
1.00x(?)

DictionaryRemove
30422
30428
+0.0%
1.00x(?)

LinkedList
26390
26358
-0.1%
1.00x

RGBHistogram
49481
49605
+0.2%
1.00x(?)

ArrayOfPOD
2335
2328
-0.3%
1.00x(?)

SetUnion
34827
34854
+0.1%
1.00x(?)

Chars
54412
54391
-0.0%
1.00x(?)

DeadArray
128681
128252
-0.3%
1.00x(?)

BitCount
77
77
+0.0%
1.00x

AngryPhonebook
5880
5887
+0.1%
1.00x(?)

SevenBoom
1417
1422
+0.3%
1.00x

ArrayValueProp
2225
2227
+0.1%
1.00x(?)

RC4
8737
8753
+0.2%
1.00x(?)

Memset
20655
20659
+0.0%
1.00x(?)

Dictionary2OfObjects
6936
6918
-0.3%
1.00x(?)

ArrayAppendReserved
2697
2688
-0.3%
1.00x(?)

ArrayValueProp2
18192
18189
-0.0%
1.00x(?)

ArrayValueProp3
2580
2574
-0.2%
1.00x(?)

ObjectiveCBridgeToNSString
1048
1056
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
193233
194649
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToString
159865
160995
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSStringForced
2566
2581
+0.6%
0.99x(?)

Dictionary3OfObjects
2725
2740
+0.6%
0.99x

RangeAssignment
15535
15615
+0.5%
0.99x

SuperChars
691413
694997
+0.5%
0.99x(?)

114
5537837
5570509
+0.6%
0.99x

ObjectAllocation
1292
1301
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObject
99870
101059
+1.2%
0.99x

ProtocolDispatch2
421
424
+0.7%
0.99x

ObjectiveCBridgeToNSSet
16368
16559
+1.2%
0.99x(?)

ObjectiveCBridgeToNSArray
29459
29780
+1.1%
0.99x(?)

NSError
648
653
+0.8%
0.99x(?)

DictionaryLiteral
20071
20229
+0.8%
0.99x(?)

Hanoi
22703
22848
+0.6%
0.99x

ArrayOfGenericPOD
3426
3475
+1.4%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObject
66231
66937
+1.1%
0.99x(?)

NSDictionaryCastToSwift
9559
9662
+1.1%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectToString
189658
190659
+0.5%
0.99x(?)

NSStringConversion
2553
2570
+0.7%
0.99x(?)

ArrayValueProp4
2522
2535
+0.5%
0.99x(?)

DictionaryBridge
3534
3623
+2.5%
0.98x(?)

PolymorphicCalls
1133
1154
+1.9%
0.98x

StrToInt
18521
18920
+2.1%
0.98x

ObjectiveCBridgeFromNSString
4939
5036
+2.0%
0.98x(?)

ObjectiveCBridgeToNSDictionary
16261
16616
+2.2%
0.98x(?)

ObjectiveCBridgeStubFromArrayOfNSString
108740
111878
+2.9%
0.97x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
7453
7790
+4.5%
0.96x

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
158374
164849
+4.1%
0.96x(?)

**Hardware Overview**
      Model Name: Mac mini
      Model Identifier: Macmini7,1
      Processor Name: Intel Core i7
      Processor Speed: 3 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      L2 Cache (per Core): 256 KB
      L3 Cache: 4 MB
      Memory: 16 GB

@nadavrot Do these regressions look OK to you? It looks potentially legitimate, since both of the affected benchmarks are type-metadata-access-heavy.

@jckarter I am seeing one improvement and one regression. The numbers we are seeing could be noise. In any case, we'll benchmark this change again with the internal setup of the performance benchmark. I think that this change can go in.

Also looking at the numbers it seems like some of the benchmarks result in low values that can cause what look like larger percentage changes. It seems like they should be enhanced to always achieve a threshold of say 100 if they are going to be measured in the way they are.

bump

Any remaining objections @gparker42 @nadavrot ?

I'm going to be out next week; @gparker42, if this looks good, do you mind merging?

I am building with your code on Cygwin. I found errors.
In file included from /cygdrive/c/Work/swift_msvc/swift/stdlib/public/runtime/Casting.cpp:25:
In file included from /cygdrive/c/Work/swift_msvc/swift/include/swift/Runtime/Mutex.h:24:
/cygdrive/c/Work/swift_msvc/swift/include/swift/Runtime/MutexPThread.h:49:32: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
  static constexpr MutexHandle staticInit() {
                               ^
/cygdrive/c/Work/swift_msvc/swift/include/swift/Runtime/MutexPThread.h:50:12: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
    return PTHREAD_MUTEX_INITIALIZER;
           ^
/usr/include/pthread.h:52:35: note: expanded from macro 'PTHREAD_MUTEX_INITIALIZER'
#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
                                  ^
/usr/include/pthread.h:50:45: note: expanded from macro 'PTHREAD_NORMAL_MUTEX_INITIALIZER_NP'
#define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
                                            ^

@tinysun212 Any suggestions to how to correct? I don't currently have a usable Windows install with Cygwin (it will take me a bit to get it going). I guess Cygwin doesn't support staticly allocated pthread mutex?

I extracted some definitions from pthread.h in Cygwin.
I think you can reproduce above compile error with temporarily changing #include <pthread.h> to #include "swift/Runtime/_pthread.h" in Mutex.h/MutexPThread.h.
typedef __uint32_t pthread_mutex_t;      /* identify a mutex */
typedef __uint32_t pthread_cond_t;       /* identify a condition variable */
typedef __uint32_t pthread_rwlock_t;         /* POSIX RWLock Object */

#define PTHREAD_COND_INITIALIZER (pthread_cond_t)21
#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
#define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
#define PTHREAD_RWLOCK_INITIALIZER (pthread_rwlock_t)22

int pthread_cond_broadcast (pthread_cond_t *);
int pthread_cond_destroy (pthread_cond_t *);
int pthread_cond_init (pthread_cond_t *, const pthread_condattr_t *);
int pthread_cond_signal (pthread_cond_t *);
int pthread_cond_wait (pthread_cond_t *, pthread_mutex_t *);

int pthread_mutexattr_init (pthread_mutexattr_t *);
int pthread_mutexattr_settype (pthread_mutexattr_t *, int);
int pthread_mutexattr_destroy (pthread_mutexattr_t *);

int pthread_mutex_destroy (pthread_mutex_t *);
int pthread_mutex_init (pthread_mutex_t *, const pthread_mutexattr_t *);
int pthread_mutex_lock (pthread_mutex_t *);
int pthread_mutex_trylock (pthread_mutex_t *);
int pthread_mutex_unlock (pthread_mutex_t *);

int pthread_rwlock_destroy (pthread_rwlock_t *rwlock);
int pthread_rwlock_init (pthread_rwlock_t *rwlock, const pthread_rwlockattr_t *attr);
int pthread_rwlock_rdlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_tryrdlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_trywrlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_unlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_wrlock (pthread_rwlock_t *rwlock);

I guess we will have to predicate the use of constexpr on not Cygwin. It won't make cygwin any worse then it apparently was (doesn't have a "true" static allocated mutex, etc.) while allowing other platforms to correctly honor static allocation (under C++).

Sorry, I captured wrong header. In include/cygwin/types.h, the typedef part is as follows,
typedef struct __pthread_condattr_t {char __dummy;} *pthread_condattr_t;
typedef struct __pthread_cond_t {char __dummy;} *pthread_cond_t;
typedef struct __pthread_rwlock_t {char __dummy;} *pthread_rwlock_t;
typedef struct __pthread_rwlockattr_t {char __dummy;} *pthread_rwlockattr_t;

I wrote simple source to test.
$ cat tt.cpp

typedef struct __pthread_cond_t {char __dummy;} *pthread_cond_t;
#define PTHREAD_COND_INITIALIZER (pthread_cond_t)21

typedef pthread_cond_t ConditionHandle;

static constexpr ConditionHandle staticInit() {
  return PTHREAD_COND_INITIALIZER;
};

$ clang++ -c -std=c++11 tt.cpp
tt.cpp:7:34: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
static constexpr ConditionHandle staticInit() {
                                 ^
tt.cpp:8:10: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
  return PTHREAD_COND_INITIALIZER;
         ^
tt.cpp:3:34: note: expanded from macro 'PTHREAD_COND_INITIALIZER'
#define PTHREAD_COND_INITIALIZER (pthread_cond_t)21
                                 ^
1 error generated.

Do you have any idea to keep constexpr?

@tinysun212 I just pushed a change that should deal with the issue you reported under Cygwin on Windows. If possible can you try it out to verify it works as expected?

It is successfully compiled without any warning or error. Thanks for your patch.

@tinysun212 cool, you will need to update your Win32 implementation have the following in its header.
#define CONDITION_SUPPORTS_CONSTEXPR 1
#define MUTEX_SUPPORTS_CONSTEXPR 1
#define READWRITELOCK_SUPPORTS_CONSTEXPR 1

@gparker42 @jckarter ok I think this ready to go after a CI

@swift-ci Please test
@swift-ci Please benchmark

Build comment file:
Optimized (O)

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeToNSDictionary
16422
17423
+6.1%
0.94x

Improvement (3)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeFromNSArrayAnyObjectToString
166571
157769
-5.3%
1.06x

Calculator
35
33
-5.7%
1.06x

StringHasSuffix
714
675
-5.5%
1.06x(?)

No Changes (117)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeToNSSet
16729
15967
-4.5%
1.05x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
196894
189306
-3.9%
1.04x(?)

DictionaryOfObjects
2264
2204
-2.6%
1.03x

Dictionary
731
713
-2.5%
1.03x

SetExclusiveOr_OfObjects
8077
7816
-3.2%
1.03x

SetUnion_OfObjects
6748
6546
-3.0%
1.03x

SortStrings
1762
1730
-1.8%
1.02x

ObjectiveCBridgeStubToNSString
1415
1392
-1.6%
1.02x

AngryPhonebook
3389
3337
-1.5%
1.02x(?)

DictionaryRemove
5015
4907
-2.1%
1.02x(?)

ObjectiveCBridgeFromNSSetAnyObjectToString
166038
162739
-2.0%
1.02x(?)

ObjectiveCBridgeStubFromArrayOfNSString
109552
107570
-1.8%
1.02x

ObjectiveCBridgeToNSString
1062
1055
-0.7%
1.01x(?)

PopFrontArray
1060
1054
-0.6%
1.01x(?)

Array2D
2024
2012
-0.6%
1.01x(?)

DictionaryBridge
3636
3609
-0.7%
1.01x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
4574
4544
-0.7%
1.01x(?)

Prims
714
710
-0.6%
1.01x

DictionarySwap
757
752
-0.7%
1.01x(?)

RangeAssignment
273
270
-1.1%
1.01x

StrComplexWalk
3023
2993
-1.0%
1.01x(?)

ObjectAllocation
143
142
-0.7%
1.01x(?)

Dictionary2
1918
1904
-0.7%
1.01x

ArrayOfRef
3451
3429
-0.6%
1.01x(?)

ObjectiveCBridgeStubToArrayOfNSString
30347
30111
-0.8%
1.01x(?)

Phonebook
7221
7130
-1.3%
1.01x

NSStringConversion
612
606
-1.0%
1.01x

Chars
618
609
-1.5%
1.01x(?)

StrToInt
4936
4866
-1.4%
1.01x

DeadArray
173
172
-0.6%
1.01x

120
2294275
2269762
-1.1%
1.01x

ArraySubscript
1325
1321
-0.3%
1.00x(?)

MonteCarloPi
42667
42668
+0.0%
1.00x(?)

StackPromo
18693
18709
+0.1%
1.00x(?)

RecursiveOwnedParameter
1826
1827
+0.1%
1.00x(?)

Integrate
233
232
-0.4%
1.00x

ClassArrayGetter
12
12
+0.0%
1.00x

Histogram
639
639
+0.0%
1.00x

StringWithCString
75595
75613
+0.0%
1.00x(?)

ObjectiveCBridgeFromNSStringForced
2187
2186
-0.1%
1.00x(?)

SortLettersInPlace
940
943
+0.3%
1.00x(?)

ArrayOfGenericPOD
207
208
+0.5%
1.00x

Dictionary3OfObjects
850
846
-0.5%
1.00x

ByteSwap
1
1
+0.0%
1.00x

SuperChars
276889
275774
-0.4%
1.00x

XorLoop
359
359
+0.0%
1.00x

ObjectiveCBridgeStubFromNSStringRef
327
327
+0.0%
1.00x

StaticArray
2648
2643
-0.2%
1.00x(?)

ProtocolDispatch
2892
2888
-0.1%
1.00x(?)

TypeFlood
0
0
+0.0%
1.00x

ProtocolDispatch2
151
151
+0.0%
1.00x

Dictionary3
497
498
+0.2%
1.00x(?)

StringHasPrefix
576
577
+0.2%
1.00x(?)

SetIntersect_OfObjects
2360
2358
-0.1%
1.00x(?)

ErrorHandling
2859
2845
-0.5%
1.00x(?)

ObjectiveCBridgeToNSArray
30182
30037
-0.5%
1.00x(?)

NSError
359
359
+0.0%
1.00x

PopFrontArrayGeneric
1049
1051
+0.2%
1.00x(?)

PopFrontUnsafePointer
8657
8655
-0.0%
1.00x(?)

CaptureProp
3741
3742
+0.0%
1.00x(?)

PolymorphicCalls
61
61
+0.0%
1.00x

RC4
250
250
+0.0%
1.00x

MapReduce
327
327
+0.0%
1.00x

Hanoi
3405
3405
+0.0%
1.00x

OpenClose
48
48
+0.0%
1.00x

DictionaryRemoveOfObjects
19503
19471
-0.2%
1.00x(?)

UTF8Decode
260
260
+0.0%
1.00x

SortStringsUnicode
8994
9013
+0.2%
1.00x(?)

SetIsSubsetOf
548
549
+0.2%
1.00x(?)

NopDeinit
34619
34609
-0.0%
1.00x

ObjectiveCBridgeFromNSArrayAnyObject
61546
61842
+0.5%
1.00x

SetIntersect
1300
1298
-0.1%
1.00x(?)

SetExclusiveOr
3830
3836
+0.2%
1.00x(?)

RGBHistogramOfObjects
21199
21271
+0.3%
1.00x(?)

StringBuilder
1389
1390
+0.1%
1.00x(?)

ArrayInClass
85
85
+0.0%
1.00x

ArrayOfGenericRef
3519
3524
+0.1%
1.00x(?)

Sim2DArray
410
412
+0.5%
1.00x

MonteCarloE
9996
10032
+0.4%
1.00x

StringHasSuffixUnicode
62311
62479
+0.3%
1.00x(?)

HashTest
1819
1816
-0.2%
1.00x(?)

SetIsSubsetOf_OfObjects
617
617
+0.0%
1.00x

ArrayAppend
730
728
-0.3%
1.00x(?)

StringHasPrefixUnicode
14981
15017
+0.2%
1.00x(?)

LinkedList
6847
6843
-0.1%
1.00x

RGBHistogram
3233
3238
+0.1%
1.00x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
3981
3968
-0.3%
1.00x(?)

ArrayAppendReserved
507
507
+0.0%
1.00x

ArrayOfPOD
171
171
+0.0%
1.00x

SetUnion
3385
3398
+0.4%
1.00x(?)

BitCount
1
1
+0.0%
1.00x

ArrayLiteral
979
981
+0.2%
1.00x(?)

SevenBoom
1276
1274
-0.2%
1.00x

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
159858
159122
-0.5%
1.00x(?)

StringWalk
6008
6014
+0.1%
1.00x(?)

ArrayValueProp
5
5
+0.0%
1.00x

GlobalClass
0
0
+0.0%
1.00x

Memset
222
223
+0.5%
1.00x

Dictionary2OfObjects
3293
3283
-0.3%
1.00x(?)

ArrayValueProp4
5
5
+0.0%
1.00x

TwoSum
1642
1643
+0.1%
1.00x(?)

ArrayValueProp2
5
5
+0.0%
1.00x

ArrayValueProp3
5
5
+0.0%
1.00x

DictionarySwapOfObjects
6606
6658
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
3609
3633
+0.7%
0.99x(?)

StringInterpolation
9999
10054
+0.6%
0.99x(?)

Join
439
445
+1.4%
0.99x(?)

ObjectiveCBridgeStubFromNSString
694
700
+0.9%
0.99x

StringEqualPointerComparison
7102
7160
+0.8%
0.99x

ObjectiveCBridgeFromNSString
1561
1572
+0.7%
0.99x

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
101734
103174
+1.4%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
180143
182976
+1.6%
0.98x(?)

ObjectiveCBridgeFromNSSetAnyObject
95459
97047
+1.7%
0.98x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
114004
116779
+2.4%
0.98x(?)

NSDictionaryCastToSwift
8281
8422
+1.7%
0.98x(?)

DictionaryLiteral
3006
3113
+3.6%
0.97x(?)

Walsh
317
329
+3.8%
0.96x

**Unoptimized (Onone)**

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

TypeFlood
145
156
+7.6%
0.93x(?)

Improvement (3)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

StringHasPrefix
1630
1516
-7.0%
1.08x

ByteSwap
10
9
-10.0%
1.11x

StringWalk
26926
23276
-13.6%
1.16x

No Changes (117)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ArrayOfPOD
2256
2152
-4.6%
1.05x

StringHasSuffix
1561
1487
-4.7%
1.05x

ObjectiveCBridgeToNSSet
16775
16073
-4.2%
1.04x(?)

NopDeinit
60929
59005
-3.2%
1.03x

ObjectiveCBridgeFromNSSetAnyObjectToString
184614
179171
-3.0%
1.03x(?)

OpenClose
452
442
-2.2%
1.02x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
122508
119650
-2.3%
1.02x(?)

StringHasPrefixUnicode
16769
16441
-2.0%
1.02x

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
115560
113711
-1.6%
1.02x(?)

ArrayAppendReserved
2701
2659
-1.6%
1.02x(?)

Chars
53814
52725
-2.0%
1.02x(?)

PopFrontArray
11670
11546
-1.1%
1.01x

SortStrings
14096
13993
-0.7%
1.01x

SortLettersInPlace
4158
4134
-0.6%
1.01x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
199443
197410
-1.0%
1.01x(?)

Integrate
347
345
-0.6%
1.01x(?)

Join
1370
1363
-0.5%
1.01x(?)

ErrorHandling
7549
7464
-1.1%
1.01x(?)

PopFrontArrayGeneric
11885
11821
-0.5%
1.01x(?)

PopFrontUnsafePointer
96350
95260
-1.1%
1.01x(?)

StringEqualPointerComparison
9779
9645
-1.4%
1.01x

ArrayOfGenericPOD
3493
3449
-1.3%
1.01x(?)

DictionaryRemoveOfObjects
60808
60183
-1.0%
1.01x

UTF8Decode
38869
38347
-1.3%
1.01x

SortStringsUnicode
23042
22860
-0.8%
1.01x

StrToInt
19217
18965
-1.3%
1.01x(?)

ArrayAppend
3130
3112
-0.6%
1.01x(?)

LinkedList
26288
26108
-0.7%
1.01x(?)

StringBuilder
8351
8250
-1.2%
1.01x(?)

ObjectiveCBridgeStubFromArrayOfNSString
113665
112449
-1.1%
1.01x(?)

ArrayValueProp4
2484
2449
-1.4%
1.01x

ArraySubscript
5398
5380
-0.3%
1.00x(?)

ObjectiveCBridgeToNSString
1052
1052
+0.0%
1.00x

ObjectiveCBridgeStubToNSString
1663
1667
+0.2%
1.00x

ClassArrayGetter
1182
1183
+0.1%
1.00x(?)

Array2D
759861
760971
+0.1%
1.00x

Histogram
13495
13503
+0.1%
1.00x(?)

MonteCarloPi
50444
50489
+0.1%
1.00x(?)

StringWithCString
73856
73828
-0.0%
1.00x(?)

ObjectiveCBridgeFromNSStringForced
2605
2597
-0.3%
1.00x(?)

Prims
14107
14082
-0.2%
1.00x(?)

Dictionary3OfObjects
2653
2652
-0.0%
1.00x(?)

RangeAssignment
12817
12807
-0.1%
1.00x(?)

SuperChars
720170
720255
+0.0%
1.00x(?)

XorLoop
18026
18042
+0.1%
1.00x(?)

ObjectiveCBridgeStubFromNSStringRef
649
649
+0.0%
1.00x

StaticArray
17222
17296
+0.4%
1.00x(?)

ProtocolDispatch
5395
5398
+0.1%
1.00x(?)

ObjectAllocation
1282
1277
-0.4%
1.00x(?)

ArrayLiteral
1039
1038
-0.1%
1.00x(?)

HashTest
6172
6158
-0.2%
1.00x(?)

Dictionary3
2024
2023
-0.1%
1.00x(?)

Dictionary2
5100
5094
-0.1%
1.00x(?)

StrComplexWalk
8557
8558
+0.0%
1.00x(?)

SetIntersect_OfObjects
18947
18892
-0.3%
1.00x(?)

ArrayOfRef
8836
8796
-0.5%
1.00x

ObjectiveCBridgeToNSArray
30251
30255
+0.0%
1.00x(?)

DictionaryOfObjects
6904
6931
+0.4%
1.00x(?)

CaptureProp
52080
52161
+0.2%
1.00x(?)

RC4
8433
8430
-0.0%
1.00x(?)

MapReduce
41976
41773
-0.5%
1.00x

Hanoi
18879
18903
+0.1%
1.00x(?)

SetIsSubsetOf
3012
3002
-0.3%
1.00x

SetIntersect
18957
18953
-0.0%
1.00x(?)

SetExclusiveOr
48910
48885
-0.1%
1.00x(?)

RGBHistogramOfObjects
114910
114596
-0.3%
1.00x(?)

ArrayInClass
3562
3560
-0.1%
1.00x(?)

ArrayOfGenericRef
9464
9493
+0.3%
1.00x(?)

Sim2DArray
13160
13155
-0.0%
1.00x(?)

SetExclusiveOr_OfObjects
67180
67096
-0.1%
1.00x(?)

MonteCarloE
102055
102489
+0.4%
1.00x(?)

SetUnion_OfObjects
51266
51226
-0.1%
1.00x(?)

StringHasSuffixUnicode
64403
64445
+0.1%
1.00x(?)

Walsh
11993
11994
+0.0%
1.00x(?)

SetIsSubsetOf_OfObjects
2836
2840
+0.1%
1.00x

DictionaryRemove
30238
30204
-0.1%
1.00x(?)

NSStringConversion
2596
2608
+0.5%
1.00x(?)

RGBHistogram
65805
65844
+0.1%
1.00x(?)

SetUnion
35038
35061
+0.1%
1.00x(?)

BitCount
92
92
+0.0%
1.00x

AngryPhonebook
6087
6080
-0.1%
1.00x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
159358
158771
-0.4%
1.00x(?)

ArrayValueProp
2176
2172
-0.2%
1.00x(?)

120
5250686
5254294
+0.1%
1.00x

GlobalClass
0
0
+0.0%
1.00x

Memset
18649
18643
-0.0%
1.00x(?)

ArrayValueProp2
17864
17913
+0.3%
1.00x

SevenBoom
1436
1430
-0.4%
1.00x(?)

StackPromo
161665
164036
+1.5%
0.99x

RecursiveOwnedParameter
7555
7607
+0.7%
0.99x

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
195015
196489
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToString
156329
157882
+1.0%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
7059
7137
+1.1%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
6948
7012
+0.9%
0.99x(?)

DictionarySwap
11425
11532
+0.9%
0.99x(?)

StringInterpolation
15303
15419
+0.8%
0.99x(?)

ObjectiveCBridgeStubFromNSString
1122
1130
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObject
103827
104526
+0.7%
0.99x(?)

ProtocolDispatch2
425
428
+0.7%
0.99x

NSError
634
639
+0.8%
0.99x(?)

PolymorphicCalls
1137
1151
+1.2%
0.99x(?)

Calculator
938
952
+1.5%
0.99x

DictionaryLiteral
20228
20461
+1.1%
0.99x(?)

ObjectiveCBridgeFromNSString
5072
5105
+0.7%
0.99x(?)

Phonebook
84595
85233
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
7430
7504
+1.0%
0.99x(?)

DeadArray
136053
137218
+0.9%
0.99x(?)

ArrayValueProp3
2503
2519
+0.6%
0.99x

Dictionary2OfObjects
6866
6903
+0.5%
0.99x(?)

TwoSum
9227
9288
+0.7%
0.99x(?)

DictionarySwapOfObjects
25014
25456
+1.8%
0.98x

DictionaryBridge
3669
3753
+2.3%
0.98x(?)

Dictionary
4130
4199
+1.7%
0.98x(?)

ObjectiveCBridgeFromNSArrayAnyObject
65215
66489
+1.9%
0.98x(?)

NSDictionaryCastToSwift
9712
9926
+2.2%
0.98x

ObjectiveCBridgeStubToArrayOfNSString
30388
31338
+3.1%
0.97x

ObjectiveCBridgeToNSDictionary
16430
16901
+2.9%
0.97x(?)

**Hardware Overview**
      Model Name: Mac mini
      Model Identifier: Macmini7,1
      Processor Name: Intel Core i7
      Processor Speed: 3 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      L2 Cache (per Core): 256 KB
      L3 Cache: 4 MB
      Memory: 16 GB

@swift-ci Please test

It looks like the Linux build issues continues to affect things?
ERROR: testREPL (TestREPLArray.REPLArrayTestCase)

@swift-ci Please test

I noted a few stylistic things that should be changed, but this is good enough to accept now and polish later.

@gparker42 I will work on the changes outlined and open a new pull request when ready. Thanks


[RFC] otk: use filedescriptors instead of paths when reading files

The upside of using file descriptors is that there are less TOCTOU issues, i.e. if not src.exists() on a path is racy but this can easily be avoided by just opening the file and keeping it open.
It will also make testing for stdin/stdout easier from the test POV there is nothing special about them (i.e. it's not even needed to test that they work just that when "-" is passed on the commandline (or nothing) stdin/stdout is opened).
Note that there is probably more needed but this is enough to satify the tests (but I suspect the recursive loading will break with this change so it might be a good place to add a test with an otk.include to ensure this is covered.

Sure, happy to work on this more and also update the tests, I wanted to double check first if I overlooked something with the idea, I will work on this a bit more and undraft it in a bit.


CodeGemma

There's CodeGemma now, which may be a good alternative to CodeLlama, which doesn't work so well. (In case you ever feel bored @Andrei-Aksionov  :D)
All the various versions as listed here: https://huggingface.co/collections/google/codegemma-release-66152ac7b683e2667abdee11

Sure, I can do this.
Hopefully it's not too complicated 🤞

So, there are 3 models available:

As can be seen from the table, 2b and 7b models are mostly for code completion, they require a special prompt in format:
prompt = '''\
<|fim_prefix|>import datetime
def calculate_age(birth_year):
    """Calculates a person's age based on their birth year."""
    current_year = datetime.date.today().year
    <|fim_suffix|> <-- (Note): this is where a cursor should be in IDE
    return age<|fim_middle|>\
'''

which is somewhat tricky to implement with the current LitGPT code. And frankly speaking I don't see why do we need it, since the output is so-so quality.
If I copy-paste the codeblock from model page:
from transformers import GemmaTokenizer, AutoModelForCausalLM

model_id = "google/codegemma-2b"
tokenizer = GemmaTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id)

prompt = '''\
<|fim_prefix|>import datetime
def calculate_age(birth_year):
    """Calculates a person's age based on their birth year."""
    current_year = datetime.date.today().year
    <|fim_suffix|>
    return age<|fim_middle|>\
'''

inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
prompt_len = inputs["input_ids"].shape[-1]
outputs = model.generate(**inputs, max_new_tokens=100)
print(tokenizer.decode(outputs[0][prompt_len:]))

the output is:
age = current_year - birth_year<|file_separator|><eos>

or with another codeblock:
from transformers import GemmaTokenizer, AutoModelForCausalLM

tokenizer = GemmaTokenizer.from_pretrained("google/codegemma-2b")
model = AutoModelForCausalLM.from_pretrained("google/codegemma-2b")

input_text = "Write me a Python function to calculate the nth fibonacci number."
input_ids = tokenizer(input_text, return_tensors="pt")

outputs = model.generate(**input_ids, max_new_tokens=100)
print(tokenizer.decode(outputs[0]))

the output is:
<bos>Write me a Python function to calculate the nth fibonacci number.

The Fibonacci numbers are the numbers in the following integer sequence.

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ……..

In mathematical terms, the sequence Fn of Fibonacci numbers is defined by the recurrence relation

Fn = Fn-1 + Fn-2

with seed values

F0 = 0 and F1 = 1.

The first ten terms are

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ……..

Example

Input: n = 10
Output: 55

Input: n = 20
Output: 6765

Input: n = 30
Output: 832040

On the other hand, the 7b-it model is a much better proposition: it can chat and follow instructions.
⚡ codegemma ~/lit-gpt litgpt chat --checkpoint_dir checkpoints/$repo_id
Now chatting with CodeGemma-7b-it.
To exit, press 'Enter' on an empty prompt.

Seed set to 1234
>> Prompt: Hello
>> Reply: Hello! 👋 It's nice to hear from you. What would you like to talk about today? 😊
Time for inference: 1.70 sec total, 12.92 tokens/sec, 22 tokens

>> Prompt: Tell me a joke
>> Reply: Why did the bicycle fall over?

Because it was two tired!
Time for inference: 0.77 sec total, 18.08 tokens/sec, 14 tokens

>> Prompt: Write a softmax function in Python
>> Reply: ```python
import numpy as np

def softmax(x):
  """Compute softmax function for a given input array.

  Args:
    x: A numpy array.

  Returns:
    A numpy array of the same shape as x, containing the softmax values.
  """

  # Calculate the exponential of each element in x
  exps = np.exp(x - np.max(x, axis=1, keepdims=True))

  # Sum the exponentials of all elements in the same row
  sum_exps = np.sum(exps, axis=1, keepdims=True)

  # Divide the exponentials by the sum of exponentials in the same row
  softmax_values = exps / sum_exps

  return softmax_values

Time for inference: 8.96 sec total, 19.30 tokens/sec, 173 tokens

My recommendation to stick to 7b-it model. What do you think @rasbt?


Fix interface test for string_tree to handle abstract strings

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

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.347%

Totals

Change from base Build<PHONE_NUMBER>2:
0.0%

Covered Lines:
2418

Relevant Lines:
2536

💛  - Coveralls


Exchanges with short enabled

Hello everyone, first off thank's for this library, it has a lot of potential.
I wonder if it's possible to add an extra column in exchange-capabilities.js to indicate whether a exchange allows SHORT orders or not.
I believe that if ccxt can indicate if a exchange allows SHORT orders is big differential in relation to others libraries, because this info does not exist in other libraries and take a lot of research to discover this info.
Today I'm using https://www.cryptocompare.com/ and preparing to switch to ccxt in a near future.

Hi, @wendelmaques ! Thanks for your feedback and for the proposal! I totally agree with you and we will add that indicator shortly. Will let you know as soon as it's available. Hopefully, soon. If that answers your question, I would close this issue for now if you don't mind. Stay tuned for updates )

Thank you Igor, you answered my question, very quickly, as usual.


Fixes 600-series settings history and adds additional pump settings to history

What it says on the tin.

 600-series driver does not handle changes in pump history correctly


Minor Grammar and Formatting Improvements for README

Description:
I noticed some minor grammar and formatting inconsistencies in the README file that could be improved to enhance readability and consistency. Below are the suggested changes:
Suggested Corrections:
"Freely available programming books":
Suggestion: Change to "Freely Available Programming Books" for consistent capitalization.
"List of Free Learning Resources In Many Languages":
Suggestion: Change "In" to lowercase, i.e., "List of Free Learning Resources in Many Languages."
"Share on 𝕏 (Twitter)":
Suggestion: Update to "Share on X (formerly Twitter)" for better clarity and reference to the new name of the platform.
These changes will improve the overall consistency and professionalism of the document.
Additional Information:

These changes do not alter any technical content but only improve grammatical accuracy and consistency in formatting.
I would be happy to implement these changes as part of my Hacktoberfest contributions if assigned to me.
Let me know if you would like me to proceed with this! 😊

Steps to Reproduce:

Open the README.md file.
Look at the areas mentioned above for the suggested corrections.

Screenshots:

Expected Behavior:
Consistent capitalization, clearer phrasing, and improved formatting.

I've raised this issue, and I would like to resolve it myself. Please assign the issue to me, and I'll start working on the fix.

i can Solve this

can you please assign to me

please assign thsi i can solve this ...

#11329

check the pr #11329

These are not improvements


[.profile]: Redundancy with exporting Guix extra profiles' share directories.

I would like to inform that this section (https://github.com/daviwil/dotfiles/blob/master/.profile#L43) is not needed as this section (https://github.com/daviwil/dotfiles/blob/master/.profile#L8) exports them already.

So is it redundant or not? Does XDG separate export?

@tex It was a mistake. Sorry.


Interacting with blob storage during deployment

As part of my deploy process I would like to push some files into blob storage before copying the site over. Are there command line tools pre-installed that'd let me do this?

I think the typical tool to do this is AzCopy, but it's not preinstalled on the worker.
You'll need to just copy it into your site files. D:\home\site\deployments\tools is a good choice to put it in as it's on the path.

Thanks, I'll give that a try and see how it works.


Update spam_image_hidden_element.yml

Description
Expand matching on observed patterns of additional tags between img src items
Associated hunts
New matching messages (single hit over last 7 days)

Hunt 1

/update-test-rules


Feature Request "New folder" option

Feature request for New folder option in file menu it will save time insted of creating new folder at desired location ,it can be created directly from the editor and desired location link can be given from command pallet with filename.extension

This currently exists in tree view

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests. Please open a new issue and fill out the template for us.
Thanks for understanding and meeting us half way :grinning:

@chriswburke u r talking about to create folder in project folder but i am talking about creating main project folder

@lee-dohm  should i again submit feature request?

@MandarSant it does sound like this is something that Atom already does and adding another menu item to an already crowded menu isn't something that we're going to do lightly. But perhaps I'm not understanding what you're suggesting, that's why we need you to fill in the template if you decide to submit this again.

@lee-dohm  i am talking about creating main project folder but atom can create sub folder in project folder and this option can be added to file menu


[DOC-3120] Add partial, sync content for SMP supported platform, features, integrations

Add partial, sync content for SMP supported platform, features, integrations
For reviewers, previews are available:
Get started with Harness - Supported platforms and technologies
Self-Managed Enterprise Edition - Supported features and integrations
What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Closing in favor of https://github.com/harness/developer-hub/pull/1799


Fast incremental recompile

As of current master (5b869e630b3535935a5b28e4d5498482586b6770),
$ touch lib/cg.jl
$ time make
julia --startup-file=no --project build.jl
[ Info: PackageCompiler: creating base system image (incremental=false)...
[ Info: PackageCompiler: creating system image object file, this might take a while...
cc -o main main.o -L/usr/lib -L. -ljulia -lm -Wl,-rpath,"/usr/lib:$ORIGIN" -lcg
249.878 real   247.404 user   2.529 sys   100.02 cpu

Can this be made fast (< 5 seconds, say)? It's about 2 seconds with present PETSc (after editing a *.c source file).

Not at the moment, but Revise.jl can do live-refresh in a running process, I suspect something similar that updates an object file could be made to work.

Refresh in a running process is interesting, but I think a different use case. Suppose I have some user code (written in C or Fortran) that is failing and I want to try a fix in the library. Is a 4 minute edit-compile-debug latency unavoidable?
Can the Julia compilation be parallelized? Building (C) PETSc from scratch takes 11 seconds on my server node (versus 2 minutes on laptop), but this Julia example takes about the same time either way.
I realize the requirements are different with non-Julia clients, but how do those of you who work on large projects (like CLIMA) typically work? Are you using Revise.jl or do you somehow factor packages for fast incremental updates?

Refresh in a running process is interesting, but I think a different use case. Suppose I have some user code (written in C or Fortran) that is failing and I want to try a fix in the library. Is a 4 minute edit-compile-debug latency unavoidable?

Yes, what I was thinking is that it might be possible to leverage the same tracking/invalidation that Revise uses, so that julia is able to update the resulting object file in place. This is a beyond my experience though, @keno might be able to give further ideas.

Can the Julia compilation be parallelized? Building (C) PETSc from scratch takes 11 seconds on my server node (versus 2 minutes on laptop), but this Julia example takes about the same time either way.

Not at the moment, as far as I know. There is considerable effort at the moment in improving performance of the compiler, I'm not sure if parallelism or multi-threading is part of that though.

I realize the requirements are different with non-Julia clients, but how do those of you who work on large projects (like CLIMA) typically work? Are you using Revise.jl or do you somehow factor packages for fast incremental updates?

For most cases of interactive development, Revise.jl works very well, though it is obviously limited to programs that can be run interactively (so no MPI), and occasionally it can break (e.g. when using a lot of metaprogramming).
We also typically build a custom system image of all our dependencies, which significantly reduces latency in package loading:
https://clima.github.io/ClimateMachine.jl/latest/DevDocs/SystemImage/
this works very well (though you need to rebuild the system image if you modify dependencies).

There's a couple of different modes that could potentially be interesting here. One thing to do might be to just have a development mode where the shared library automatically checks if any of the source got modified (via Revise) and if so patches itself with any changes. That way you don't need an explicit recompile at all (though of course you'd be paying increased JIT time the father the changes are from when the library was originally built). Incrementally updating the system image is also possible, but not really something people have looked into much. For deployment, you do definitely want to do a full/clean rebuild, since we make heavy use of what is essentially LTO (just as you would for a modern C++ app). I think for development, the thing to do is just figure out what the easiest workflow is. There's some implementation work required also, but I don't think it's that bad, since Revise basically already knows how to do this.

Is there a configuration to minimize the JIT overhead for those kind of situations?


very hard to construct a suitable environment

very hard to construct a suitable environment. impossible to duplicate the environment by requirements.txt

For me it works when I have latest version of all packages, excluding torch (torch == 1.8.1+cu111, torchaudio==0.8.1, torchvision==0.9.1+cu111).
But I am using this env only for inferensing/conversion. (training in google cloud)


refactor(accordion): remove attribute selector

Better to leave it as a element, it doesn't make sense as an attribute.

LGTM if Travis is green


Looping when branch protection disallows merge commits

Recently we've seen that on repositories where branch protection forbids merge commits into master, hoff can loop (since it attempts to fast-forward merge on successful builds). GitHub has an API for checking the protection on a branch, we should check that the branch hoff will merge into has compatible permissions.
Since branch protection configuration can change, we should either listen for changes in branch protection rules if possible, or check at the start of every hoff merge. If branch protection rules would prohibit hoff from merging, it should comment this on the PR so users are aware.

The more general problem is that we treat every failed push as a conflicting commit to master, and thus as a reason to retry:
https://github.com/channable/hoff/blob/266379ed8eb44cbe311766ed9f04897cad812623/src/Logic.hs#L808-L823
I'd say we should instead whitelist the causes that are know to be fixable by retrying, and give up on the PR (with a comment) in all other cases. Then we also wouldn't necessarily need custom logic for detecting branch protection rules - depending on how good the error messages are we get back from a failed push.


No prefix

No prefixes are appearing, i have the prefix setup already, and i have both essentialsxchat and deluxechat. and i have vault of course. i also tried everything here https://github.com/lucko/LuckPerms/wiki/Prefixes,-Suffixes-&-Meta

also my chat format became from this "name: message" to the default essentials one " message" for some reason


Scoped parallel execution within a single System

@Kimundi:

Would it be possible to support scoped-parallel iteration over entities in a System? As in, having a build-in way to distribute work over the backing threadpool of specs rather than "working around" that with multiple systems and/or launching your own threadpool

Suggestions: use crossbeam or rayon
A nice library for our consideration - https://github.com/reem/rust-shared-mutex

I'll try to switch threadpool for rayon. (Wanted to test speed difference and stumbled into #116)

I have been looking at how to integrate rayon to specs.
I currently have just switched thread pool to use rayon one which seemed to need rayon-core which is currently unstable, but switching it was easy enough.
Bigger task is to implement parallel iterator for the join stuff as it required touching the bitset.
Is there any sources that explain it other than the code? Only thing that I found searching 'Hierarchical bitset' was this pdf. It seems at cursory clance to be similar. Is it accurate?
I am also currently little lost in rayons internals even though I have pretty much watched all the video presentations and read blogs on it. Have to just put time in to familiarise myself with the code base.

Also crossbeam is currently in flux:
https://www.reddit.com/r/rust/comments/5ygbwb/crossbeam_request_for_help/
https://www.reddit.com/r/rust/comments/5yp2b2/initial_release_candidate_100_by_ticki_pull/

Implemented by PR #120 by @WaDelma.


Update Azure.Identity readme

[ ] Update type references to point to reference docs on docs.microsoft.com
[ ] Add exception handling sample to troubleshooting section
[ ] Add enable logging to troubleshooting section

Any chance of adding documentation to cover developer scenarios and what is/isn't supported  currently?  I realize it's in flux, but there is almost no documentation on SharedTokenCache, AzCli or VisualStudio credential use in DefaultAzureCredential.
Mainly looking at an explanation of why the VS auth integration doesn't work, and ways around it (I've finally managed to use the latest beta with az-cli to give an option of using dev credentials, but it's been painful finding the info)

This appears to be complete


Table generation with few primary keys

Closes #853
@geralt-encore so readable tests! 👍 👍

Codecov Report

Merging #854 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #854   +/-   ##
=========================================
  Coverage     97.33%   97.33%
  Complexity      799      799
=========================================
  Files            92       92
  Lines          2663     2663
  Branches        298      298
=========================================
  Hits           2592     2592
  Misses           44       44
  Partials         27       27

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 04145e2...00481b7. Read the comment docs.


Bottom Navigation

Hi, I'm wondering if you're planning to add 'Bottom Navigation' support:
https://material.io/components/bottom-navigation
Should I just use Tabs in the meantime? If so, I'd need to fix them to the bottom.
Thanks!

They haven't implemented it upstream yet. But yes, I think it would be very useful. Personally I have just used tabs myself.

Cool, thanks for responding. I'll go with tabs for now.


Error on print statement : Is this library created using Python 3?

Traceback (most recent call last):
from textpipeliner import PipelineEngine, Context
File "/Library/Python/2.7/site-packages/textpipeliner/init.py", line 3, in
from .pipes import *
File "/Library/Python/2.7/site-packages/textpipeliner/pipes/init.py", line 1, in
from .pipe import Pipe,
File "/Library/Python/2.7/site-packages/textpipeliner/pipes/pipe.py", line 2, in
from grammaregex import find_tokens, match_tree
File "/Library/Python/2.7/site-packages/grammaregex/init.py", line 1, in
from .grammaregex import match_tree, find_tokens, print_tree, verify_pattern, PatternSyntaxException
File "/Library/Python/2.7/site-packages/grammaregex/grammaregex.py", line 70
print("{", end=" ")

Pull request #2 should fix this


Change api to enforce parameters consistency

should always be consistently
($array, $index, $value, $dafault)
if one argument does not exist, the order should be shifted, excluding the option that does not exist
therefore
A::get($array, 'a/b/c',  'default value');
or
A::set($array, 'a/b/c', $value);
etc...

the should be version 2 of the package as it breaks back compatibility

done


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Moving entire Delight into Assets subfolder and changing DelightPath in config.txt results in IO exceptions

Hello!
First and foremost: thanks for the wonderful tool - I was about to implement something very similar by myself, until I stumbled to your solution :-)
For the bug:
Steps to reproduce:

Download Delight-latest.unitypackage and open it in Unity 2020.1.10f1 (did not try other versions)
Move Delight folder -> 3rdParty\Delight\Delight
Move Content folder -> 3rdParty\Delight\Content
Create Game/Delight folder for custom content
Change config.txt:

ServerUri: http://example.com
UseSimulatedUriInEditor: true
BuildTargets: Dev
AssetBundleVersion: 1
DelightPath: 3rdParty/Delight/
ContentFolders:
	Game/Delight/
	3rdParty/Delight/Content/
DefaultContentFolder: Game/Delight/
Modules:
  TextMeshPro

Expected behaviour:
The config should be read properly
Observed behaviour:
On each asset change:

DirectoryNotFoundException: Could not find a part of the path "D:\MyProject\Assets\Delight\Content\Config_g.cs".
FileNotFoundException: Could not find file "D:\MyProject\DelightConfig.bin"

The problem persist even after restarting Unity (I saw a few static fields for config)

Thanks for your bug report Shelim.

hi! are there any workarounds for this? i'm using Delight for a sample implementation of our SDK, so it gets distributed as a unitypackage that our users then integrate into their own projects; as such, having top-level directories is kind of a deal breaker... any workaround to encapsulate all of the Delight code into a subdirectory would be greatly appreciated!

No known workarounds currently. You might try delving in the code-base.. as it's open-source you could attempt fix the issue, to make it so e.g. default folder to be configured e.g. through a project setting. Right now the config file need to reside where it is in the content folder, as the path is hard-coded.

thanks for the suggestion, Patrik!
took a stab at it and managed to get it working by identifying and updating all the relevant hardcoded paths after you move Delight into a subdirectory.
...documenting here in case others are interested in this manual workaround and for bug-fixing reference:
Assets/SUB_DIR/Delight/Source/Editor/DelightControlPanel.cs:99
                    EditorSceneManager.OpenScene("Assets/SUB_DIR/Delight/Content/Scenes/DelightDesigner.unity");

Assets/SUB_DIR/Delight/Source/Editor/Parser/MasterConfig.cs:292
            var rootPrefix = "Assets/SUB_DIR/";
            ContentFolders.Add(rootPrefix + "/Content/");
            ContentFolders.Add(rootPrefix + "/DelightDevContent/");
            ContentFolders.Add(rootPrefix + "/Delight/Content/");
            ContentFolders.Add(rootPrefix + "/Plugins/Content/");
            ContentFolders.Add(rootPrefix + "/Plugins/Delight/Content/");

Assets/SUB_DIR/Delight/Source/Editor/Parser/MasterConfig.cs:323
                    string contentFolder = String.Format("Assets/SUB_DIR/Delight/Extensions/{0}/", directoryName);

Thanks for your fix, added it to the codebase. There is now a static field "DefaultDirectory" in the MasterConfig class, for an easy way to change the root folder until a more robust solution is in place that doesn't require modifying the source.
    public class MasterConfig
    {
        public static string DefaultDirectory = "/"; // edit the following string to add Delight framework into a default subfolder, e.g. "SUB_DIR/"

thank you for taking caring of this!


UX improvements

Bus monitor: make the capture button pressed by default
If the local node is configured in anonymous mode, show some sort of non-intrusive hints suggesting to switch the node into the normal mode. A periodic message in the status bar could suit this purpose well.
Same applies to the dynamic node ID allocation server.
Indicate the name and all configuration parameters of the active interface somewhere.
Link the documentation page from the help menu

This application is nearing the end of its life cycle so this will not be worked on.

This application is nearing the end of its life cycle so this will not be worked on.


Tone down the debug error page

For issue #123

@nodegin @christiannaths this is great. Thanks for bringing this up. I didn't mind it but I can see how many would.
Can you change the background to #A6004C, title #FF84BF?

Thanks Guillermo!

@rauchg Of course, but I am closing this PR since I have another PR opened currently. Can you change that?


open gl error with procsssing v.b4

i imagined this not your problem but thought you should know in case they made a change with opengl in v.b4
. the shader example work fine in v.b3 but got a open gl function pgl.vertexAtrribPointer() error with v.b4

ok, going to look in to it, thanks!

what is the error, console output with pgl.vertexAtrribPointer() ?

b5 showing what is likely to be the same error:
The function "vertexAttribPointer()" expects parameters like: "vertexAttribPointer(int, int, int, boolean, int, int)"

i just updated the point cloud examples, so masters should be working


Transformations - again

Hi Tim,
For some reason the Dwarsberg AWS transformation on the daily soil moisture minimum is not being applied. Settings are identical to the Maximum which does work. Any ideas?

Servers are down, as soon as they come up I will have a look

Hi Tim,
A development on this I have just noticed in case it helps:
The lack of transformation application appears to only happen when one views the Observations under Import Batches.
See here for Sneeuberg rain gauge:

When viewed in the Data Query Display, it looks like the transformation did actually get applied.

The same however doesn't apply for Dwarsberg daily soil moisture. Here the transformation applied to the Maximum works but the Minimum does not. I've tried any number of different combinations of rankings with and without start & end dates. I did manage to switch the problem to Max instead of Min at one stage (to do with rankings I think) but reversed it again.

Hi Abri
For the Sneeuberg I see that the transform has been made for the tips, but to 0.254 instead of 0.2. Any idea why 0.254?

Hi Tim,
That's because it's a new rain gauge that measures rainfall in 0.254 mm increments

Ok, so are you now happy with Sneeuberg?

Yes, it looks fine

Hi again Tim,
Related to the same topic, I've added a new Texas rain gauge sensor to each of the 5B, 21B, 25B and 26B stations in Jonkershoek. I've configured them identically with Transformation end dates for the old sensors ending on 26 October 2017 (the last data for the day varies between morning and early afternoon depending on the site). Transformation start dates for the new sensors start on the 26th. I've got the transformation rankings identical as well apart from a couple of the sources which have an additional QC transformation as a third add on. Now for the weird part....
Two of the sensors' data load with the correct start and end times. The other two create fake data to complete the old sensor's day and start the new sensor's record from the 27th at 00:00

You need to filter on Phenomenon "Rainfall", RawValue > 0 to see the tips in Import Batches.
Now to Dwasberg...

More transformation weirdness...
Untransformed Raw Values and transformed Data Values in the Observations under Import Batches - perfect!

Same data viewed through the Query Display...

Hospital Bend Block A bottom daily has a very similar transformation problem as Dwarsberg -  a Minimum that transforms and a Maximum that doesn't...

Hi Abri
Still no idea why. I did notice that for some reason the sensors have a schema which in this case is not the right way to set sensors up.
Will do more investigation and get back to you.

Yes, that's how Victoria set them up back in the day because of the fact that there are several soil moisture sensors measuring the same phenomena and offering. It was a very complicated exercise that I still don't quite understand the reason for.
Either way, the database accepted a few years worth of data and performed the transformations 100% up until a few months ago. I've subsequently deleted all the daily data which did not have transformations applied correctly. So you can see where the error started.
The problem seems to be when one does a transformation on the same phenomenon from the same data source (even if it is two different sensors each with its own unique offering). I'm encountering the exact same problem at Hospital Bend...well, almost...in the Hospital Bend case it is reversed.

Ok, will delve deeper

Ok, I have found the problem. Please try again and let me know if its fixed....

I've tested it for Dwarsberg and it looks like the problem has been solved. Was it something I was doing wrong?

Nope, was the schema on sensor which means the file is processed a number of times. There was a glitch in that after the each processing the values were reset to the raw value. So it was order dependent on which transformations didn't get overwritten.
We don't have that problem with the schema on the datasource.


Totally EPIC readme and license and a really cool discord bot trust me bro

CoOL COdE bish

CoOL COdE bish

print("Thanks Baby girl")


Device unique ID

Hello, I have been looking for a long while how to get the device's id on Linux, but at this moment I am stuck because I haven't found any common way. But I noticed that a serial number is shown on the camera's page (in the Information window). Is there any way to get that with C API?

Serial number is currently only exposed via Vapix network api, see "SerialNumber" in basicdeviceinfo.cgi and has unrestricted access. There is a gap in ACAP api's when it comes to the serial number and more people has been asking for it.
I'm not aware of any work around except using Vapix to retrieve serial number.

We have recently launched a new way in ACAP Native SDK (part of ACAP 4 offering) to make VAPIX requests from an ACAP application, e.g. to basicdevicenfo.cgi that was mentioned above. Migrating to ACAP Native SDK would therefore be a way to achieve this. See example applications in acap-native-sdk-examples.


Skip tests with invalid backend providers

Jira: CT-XXX
Connection PR: XXXXX
Before asking for review make sure that:
Checklist

[ ] New client method(s) has tests
[ ] Apiary file is updated
[ ] You declared if there is a BC break or not (will affect next release of a client)

Release

[ ] I gave the PR a proper label:

major (BC break)
minor (new feature)
patch (backwards compatible fix)
no release (just test changes)

manage suita

z manage-m8 suity budou chybet uz jen testy, co prirazuji GCS stage v SNFLK, to fixnu pozdeji


feat(css/parser): Added OperatorValue node

Added OperatorValue AST Node, it represents any delim tokens.
For example:
a {
   font: italic small-caps bold 12px/30px Georgia, serif;
}

is valid CSS, but / should be not consider as division. / should be consider as division only for math functions like calc()/min()/max()/etc, we will improve them late.
The only thing I doubt is the name.
Alternative - DelimiterValue.
Note - this node will be used for , in future.

@kdy1 Can you all and give your opinion?

Is this a groundwork for

/ should be not consider as division. / should be consider as division only for math functions like calc()/min()/max()

?
I think I didn't get the point of this kind of node. Is it defined on the css specification?

@kdy1

I think I didn't get the point of this kind of node. Is it defined on the css specification?

In CSS spec no division, / can have many meanings, in
a {
  font: italic small-caps bold 12px/30px Georgia, serif;
}

it is just separator in declaration value.
In:
div {
  width: calc(100px / 2);
}

it is `/`` division.
Generally in CSS spec we have <delim-token>:

 has a value composed of a single code point.

So *, +, - and other not reserved characters (and even , (comma)) are delim characters.
Therefore, we need AST node in order to present it in AST. OperatorValue do it, but the name worries me a little, it can be misleading, so I suggest to use DelimiterValue and want to heart your opinion here.

@kdy1 Friendly ping

@kdy1 I would also like to know what you think about the OperatorValue name

Oh, I prefer OpValue over OperatorValue. Thanks! I missed it.

Close in favor https://github.com/swc-project/swc/pull/3402


Prompt Template Issue in modules/lumberchunker.py

Hello, during reading the source code of lmchunker, especially the realization for LumberChunker method, I find its Chinese prompt is:
system_prompt_zh = """你将被赋予一个英文文档，其中段落用'ID XXXX: <text>'标识。

任务：找出第一个段落（不是第一个），其中内容与前面的段落相比较，显着地发生变化。

输出：以如下格式返回段落的ID：'Answer: ID XXXX'。

其他注意事项：避免形成过长的段落集群。考虑句子逻辑和语义内容。寻找一个平衡，以识别内容变化并保持段落集群长度适中。"""

(line 32 to line 38 in modules/lumberchunker.py
I suppose that using LumberChunker with Chinese LLM for Chinese Documents processing should be accompanied by  "你将被赋予一个中文文档" instead of "你将被赋予一个英文文档".

We are deeply grateful for your profound interest in this project and for raising such meticulous questions. We feel honored and will promptly refine and update the relevant content in response to your inquiry. Thank you once again for your invaluable feedback！


remove performance warning of Opengles in Xcode

For the iOS platform, We choose to use Vulkan API  only.


Implemented search authors service.

You have basically just copied the code I have written for _fetch_all_tags_service, with a couple of minor modifications. Have you even tested this service yourself? It does not work!
The search authors service takes a query string and sends it as a param to the Quotable API to fetch the list of authors.
See the service definition here.
Please read the API documentation and test the service properly yourself before making a pull request. You can test the service from the developer tools tab in Home Assistant frontend.
http://localhost:8123/developer-tools/service

Hello Michiale,
Did you test this in developer tools? because it is not working. It should return a list of authors.

Also, rebase your code with the latest develop.


Typo on flask.g documentation section

Where: http://flask.pocoo.org/docs/0.10/api/#flask.g
"On top of that it will delegate access to the current application’s JSOn encoders and decoders for easier customization."
Should be JSON not JSOn, right?

Yeah... patches welcome. :)

Sure, can you point me in the direction to do so? Is it in a repo? Sorry, I was trying to find it on my own but I didn't run across it.

Hmm, okay. Then this will fix itself when the next version is released.

Awesome! Thanks. 🍻


CassandraSinkCluster improve handling of prepared responses

when checking the prepared responses returned by the server:

Every response should be taken into account, currently the response sent back to the client is not checked.
The response sent back to client should be a failure if any of the responses failed, otherwise any success response can be sent, currently the response sent back to the client is a random response.

To achieve this I imagine we will need something like:
struct PreparedResponse {
    index: usize,
    responses: FuturesOrdered,
}

let mut responses_future_prepare = Vec<PreparedResponse>::new();

and then receive, compare and insert the prepared responses into the messages list.

closed by https://github.com/shotover/shotover-proxy/pull/959


feat: implement first release

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@1d1e695). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             main        #1   +/-   ##
========================================
  Coverage        ?   100.00%
========================================
  Files           ?        14
  Lines           ?       486
  Branches        ?        54
========================================
  Hits            ?       486
  Misses          ?         0
  Partials        ?         0

Help us with your feedback. Take ten seconds to tell us how you rate us.


XD-3739: Fix and Configure Script Refresh

JIRA: https://jira.spring.io/browse/XD-3739
Scripts were incorrectly checked for changes with a hard-wired 60ms interval
instead of 60 seconds as stated in the reference manual.
Change the default to 60 seconds and make it configurable; -1 disables refresh.

merged as a42ccbcc3c233bc5c784262958e5e0ed001f247f


Speed up EncryptRTP

new:
BenchmarkEncryptRTP-8          	  300000	      5181 ns/op	    2512 B/op	      11 allocs/op
BenchmarkEncryptRTPInPlace-8   	  300000	      4480 ns/op	    1104 B/op	      10 allocs/op

old:
BenchmarkEncryptRTP-8          	  200000	      6378 ns/op	    4304 B/op	      12 allocs/op
BenchmarkEncryptRTPInPlace-8   	  300000	      4448 ns/op	    1104 B/op	      10 allocs/op

The old code would:

allocateIfMismatch performs bytes.Equal to check if the dst/src
are the same. It's not needed, it could technically have false-positives,
and it could have been done faster with pointers anyway.
ex: &dst[0] == &src[0]

allocateIfMismatch would always copy the payload, even if we're
just about to overwrite it with encrypted data.

allocateIfMismatch will make a byte slice of the size/cap of the
payload slice, but won't include extra room for the auth tag (10 bytes)
we're expecting to append. This means that we will always cause an extra
realloc/copy, as evidenced by the benchmark memstats.

The unit test to check if the encryption was done in place was broken.
The ciphertext was being written to the dst, but then append was used
to write the auth tag. This causes a reallocation unless the dst is
allocated with 10 extra bytes of overhead. So encrypting in place would
often not work.
I switched the API to explicitly append instead of write to [0]. The
stdlib likes to switch kind of arbitrarily between both approaches. If
the output size is not trivial, then it will always append. But if the
output size is fixed, then it can write in place. When the output size
can be calculated (like len(plaintext)+10), most APIs still use append.
For example, cipher.Block writes to indexes directly while cipher.AEAD
will append because it also attaches an auth tag.
Writing to indexes directly should always error if len(dst) is not large
enough, as a way to guarantee against reallocations. The current approach
uses append under the hood so it's better to be explicit that there may be
a reallocation.
You can still append to the same slice by using dst[:0]. It will set
the len to 0 but the cap will stay the same.

Fantastic work @kixelated!
Write in place is a poor choice, but I was testing for a realloc (and maybe my assumptions were wrong) but I would hope that people could pass the buffer and we could allocate the tag for them.
Or they could allocation ahead of time (we should add a case to test for this also!) nice little improvement there.
I see three unique inputs though (and would be nice to test for them all)

New allocation
realloc for auth tag
completely in place

@Sean-Der Thanks for the review and sorry for being so eager to break the API. I'm going to revert the API changes and just improve the performance.

Hey @kixelated
I think it is awesome you want to break the API actually :) your fresh insight is SUPER valuable, and it would be a huge mistake if I tempered it by accident.
Everything you think is wrong please put on the wiki page, I want to do them all. I just have to balance stability and making everyone happy is my only concern :( and I could be doing a bad job of that so please always push back if I am wrong.
Tell me when you are ready for another review! If there are no API changes that would be fantastic, we can bump in pions/webrtc and keep getting these wins :) really excited about the promise of faster ciphers

Should be good for a review now that the linter passes.

oh wait except for stream_srtp.go


Action type show differently for data source in "Step actions" and execution report

Describe the bug
Action type text is different in "Step Actions" and execution report.
To Reproduce
Steps to reproduce the behavior:

Add some action steps with Data Source action
Run the execution
Open the execution report
Compare action type for "Data Source Action" in steps action and execution report.

Expected behavior
Both should be same to avoid confusion.
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Also, if there is multiple execution based on data source, only the last execution snapshot is displayed in the report. However, with screenshot action we can take screenshots but report will only show the last iteration. Is it possible to have report for each iteration with snapshots?

Regarding Action Type- the type is missing for Data Source Action and we will handle it for next Beta version 3.2.1.
Regarding seeing all iterations of the executed Actions- you need to set to have it in the HTML Report template configurations- see below how to set it:


performance: try using CSS transform rather than left/top for positioning nodes

Using React has greatly simplified the page layout (as opposed to the angular version.
It should be relatively straightforward to use CSS transform for laying out vertices/edges instead of left/top.

Implemented on master (v0.5.0).
Upgrade Information
Made several performance improvements based on profiling results:

better dirty checking in React Components
memoize canvas size measurements (graph component)
use CSS transform rather than left/top for node layout