Compile on OSX: lz4 and libmysqlclient issues

I am following the steps in: https://clickhouse.yandex/docs/en/development/build_osx/#install-homebrew
The make gave errors about lz4 not found so I had to do an additional step of brew install lz4
The make gave errors about:
ld: archive has no table of contents file '../../libmysqlclient.a' for architecture x86_64
collect2: error: ld returned 1 exit status

Now, I have mariadb (installed with brew install mariadb) and so I cannot install mysql as brew complains with:
Error: Cannot install mysql because conflicting formulae are installed.
  mariadb: because mysql, mariadb, and percona install the same binaries.

But I do have the lib files:
$ locate libmysqlclient
/usr/local/lib/libmysqlclient.a
/usr/local/lib/libmysqlclient.dylib
/usr/local/lib/libmysqlclient_r.a
/usr/local/lib/libmysqlclient_r.dylib

Not sure why Clickhouse is not detecting and using these files

Can you show your cmake output?
lz4 should be used from contrib:
-- Using lz4: /Users/.../ClickHouse/contrib/lz4/lib : lz4
cmake will use libmariadb or libmysql lib:
-- Using mysqlclient=1: /usr/local/include : ; staticlib=/usr/local/lib/libmariadbclient.a

Sorry for the delay ... never saw this.
Here is the cmake output:
$ cmake .. -DCMAKE_CXX_COMPILER=`which g++-8` -DCMAKE_C_COMPILER=`which gcc-8`
-- The C compiler identification is GNU 8.1.0
-- The CXX compiler identification is GNU 8.1.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/local/bin/gcc-8
-- Check for working C compiler: /usr/local/bin/gcc-8 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/local/bin/g++-8
-- Check for working CXX compiler: /usr/local/bin/g++-8 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_BUILD_TYPE is not set, set to default = RELWITHDEBINFO
-- CMAKE_BUILD_TYPE: RELWITHDEBINFO
-- Performing Test HAVE_SSE41
-- Performing Test HAVE_SSE41 - Success
-- Performing Test HAVE_SSE42
-- Performing Test HAVE_SSE42 - Success
-- Performing Test HAVE_POPCNT
-- Performing Test HAVE_POPCNT - Success
-- Performing Test HAVE_NO_PIE
-- Performing Test HAVE_NO_PIE - Failed
-- Tests are enabled
-- Building for: Darwin-17.5.0 x86_64  ; USE_STATIC_LIBRARIES=ON MAKE_STATIC_LIBRARIES=ON UNBUNDLED=OFF CCACHE=CCACHE_FOUND-NOTFOUND
CMake Warning at cmake/find_ssl.cmake:10 (message):
  Disable USE_STATIC_LIBRARIES if you have linking problems with OpenSSL on
  MacOS
Call Stack (most recent call first):
  CMakeLists.txt:238 (include)

-- Found OpenSSL: /usr/local/opt/openssl/lib/libcrypto.a (found version "1.0.2o")
-- Using ssl=TRUE: /usr/local/opt/openssl/include : /usr/local/opt/openssl/lib/libssl.a;/usr/local/opt/openssl/lib/libcrypto.a
-- Using icu=1: /opt/local/include : /opt/local/lib/libicui18n.a;/opt/local/lib/libicuuc.a;/opt/local/lib/libicudata.a
-- Using Boost: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/boost : boost_program_options_internal,boost_system_internal,boost_filesystem_internal
-- Using zlib: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/zlib-ng;/Users/abdealijk/Documents/oss/yandex/ClickHouse/build/contrib/zlib-ng : zlibstatic
-- Using zstd:  : zstd
-- Using ltdl: /usr/local/lib/libltdl.a
-- Could NOT find ODBC (missing: ODBC_INCLUDE_DIRECTORIES)
-- Using odbc: ODBC_INCLUDE_DIRECTORIES-NOTFOUND : /usr/lib/libiodbc.dylib
-- Using Poco: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/poco/Foundation/include/;/Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/poco/Util/include/;/Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/zlib-ng/;/Users/abdealijk/Documents/oss/yandex/ClickHouse/build/contrib/zlib-ng/ : PocoFoundation,PocoUtil,PocoNet,PocoNetSSL,PocoXML,PocoData,,PocoMongoDB; MongoDB=1, DataODBC=, NetSSL=1
-- Using lz4: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/lz4/lib : lz4
-- Using sparsehash: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/libsparsehash
-- Using rt: apple_rt
-- Using line editing libraries (readline): /usr/local/opt/readline/include : /usr/local/opt/readline/lib/libreadline.a;/usr/lib/libtermcap.dylib
-- Performing Test HAVE_READLINE_HISTORY
-- Performing Test HAVE_READLINE_HISTORY - Success
-- Using re2:  : re2;  : re2_st
-- Using librdkafka=1: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/librdkafka/src : rdkafka
-- Using capnp=1: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/capnproto/c++/src : capnpc
-- Using cityhash: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/libcityhash/include : cityhash
-- Using farmhash:  : farmhash
-- Using metrohash:  : metrohash
-- Using btrie:  : btrie
-- Using double-conversion: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/double-conversion : double-conversion
-- Using tcmalloc=1: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/libtcmalloc/include : tcmalloc_minimal_internal
-- Using cctz: /Users/abdealijk/Documents/oss/yandex/ClickHouse/contrib/cctz/include : cctz
-- Using mysqlclient=1: /usr/local/include : ; staticlib=/usr/local/lib/libmariadbclient.a
-- Performing Test HAVE_UNWIND_INIT_LOCAL_SIGNAL
-- Performing Test HAVE_UNWIND_INIT_LOCAL_SIGNAL - Failed
-- Using unwind=:  :
-- compiler C   = /usr/local/bin/gcc-8    -pipe -msse4.1 -msse4.2 -mpopcnt -fno-omit-frame-pointer  -Wall   -O2 -g -DNDEBUG -O3
-- compiler CXX = /usr/local/bin/g++-8  -std=c++17   -pipe -msse4.1 -msse4.2 -mpopcnt  -fno-omit-frame-pointer  -Wall  -Wnon-virtual-dtor  -O2 -g -DNDEBUG -O3
-- LINKER_FLAGS =
-- ZSTD VERSION 1.3.17
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Architecture: x86_64
-- Check size of off64_t
-- Check size of off64_t - failed
-- Check size of _off64_t
-- Check size of _off64_t - failed
-- Check size of __off64_t
-- Check size of __off64_t - failed
-- Looking for fseeko
-- Looking for fseeko - found
-- Looking for strerror
-- Looking for strerror - found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Looking for stdarg.h
-- Looking for stdarg.h - found
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_HIDDEN
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_INTERNAL
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_INTERNAL - Success
-- Performing Test HAVE_BUILTIN_CTZL
-- Performing Test HAVE_BUILTIN_CTZL - Success
-- Performing Test HAVE_SSE2_INTRIN
-- Performing Test HAVE_SSE2_INTRIN - Success
-- Performing Test HAVE_SSE42_INTRIN
-- Performing Test HAVE_SSE42_INTRIN - Success
-- Performing Test HAVE_PCLMULQDQ_INTRIN
-- Performing Test HAVE_PCLMULQDQ_INTRIN - Success
-- Architecture-specific source files: arch/x86/x86.c;arch/x86/insert_string_sse.c;arch/x86/deflate_quick.c;arch/x86/fill_window_sse.c;arch/x86/crc_folding.c;arch/x86/crc_pclmulqdq.c
-- The following features have been enabled:

 * CMAKE_BUILD_TYPE, Build type: RELWITHDEBINFO (selected)
 * WITH_OPTIM, Build with optimisation
 * WITH_NEW_STRATEGIES, Use new strategies
 * SSE2, Use the SSE2 instruction set, using "-msse2"
 * SSE4_CRC, Support CRC hash generation using the SSE4.2 instruction set, using "-msse4"
 * SSE4DEFLATE, Support SSE4.2-accelerated quick decompression
 * PCLMUL_CRC, Support CRC hash generation using PCLMULQDQ, using "-mpclmul"

-- The following OPTIONAL packages have been found:

 * PkgConfig
 * OpenSSL

-- The following features have been disabled:

 * ZLIB_COMPAT, Provide a zlib-compatible API
 * WITH_GZFILEOP, Compile with support for gzFile-related functions

-- Building: tcmalloc_minimal_internal
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.29.2")
-- Checking for module 'libsasl2'
--   No package 'libsasl2' found
-- Looking for C++ include initializer_list
-- Looking for C++ include initializer_list - found
-- Poco package version: 2.0.0
-- Using OpenSSL from /usr/local/opt/openssl
-- Building static libraries
-- Building without tests
-- Building without samples
-- Build with using external sqlite, libz, pcre, expat ...
-- Performing Test HAVE_GETADDRINFO_A
-- Performing Test HAVE_GETADDRINFO_A - Failed
-- Could NOT find ODBC (missing: ODBC_INCLUDE_DIRECTORIES)
-- ODBC Support Disabled - no ODBC runtime
-- Found APR: /usr/lib/libapr-1.dylib
-- Found APRUTIL: /usr/lib/libaprutil-1.dylib
-- Found APACHE: /usr/include/apache2
-- CMake 3.11.1 successfully configured Poco using Unix Makefiles generator
-- Installation target path: /usr/local
--
-- Generated with config types: RelWithDebInfo;Debug;Release;MinSizeRel;ASan;UBSan
-- Setting Poco build type - RELWITHDEBINFO
--
-- C_FLAGS:  =   -pipe -msse4.1 -msse4.2 -mpopcnt -fno-omit-frame-pointer  -Wall   -Wno-sign-compare -fno-strict-aliasing -Wno-unknown-pragmas
-- CMAKE_C_FLAGS_DEBUG:=-g -O0 -g3 -ggdb3 -fno-inline    -D_DEBUG
-- CMAKE_C_FLAGS_RELEASE:=-O3 -DNDEBUG
-- CMAKE_C_FLAGS_MINSIZEREL:=-Os -DNDEBUG
-- CMAKE_C_FLAGS_RELWITHDEBINFO:=-O2 -g -DNDEBUG -O3
--
--
-- CXX_FLAGS:= -std=c++17   -pipe -msse4.1 -msse4.2 -mpopcnt  -fno-omit-frame-pointer  -Wall  -Wnon-virtual-dtor  -Wno-old-style-cast -Wno-sign-compare  -fno-strict-aliasing -Wno-unknown-pragmas -Wno-non-virtual-dtor
-- CMAKE_CXX_FLAGS_DEBUG:=-g -O0 -g3 -ggdb3 -fno-inline  -D_DEBUG
-- CMAKE_CXX_FLAGS_RELEASE:=-O3 -DNDEBUG
-- CMAKE_CXX_FLAGS_MINSIZEREL:=-Os -DNDEBUG
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO:=-O2 -g -DNDEBUG -O3
-- Building: CppUnit
-- Building: XML
-- Building: JSON
-- Building: MongoDB
-- Building: Util
-- Building: Net
-- Building: NetSSL_OpenSSL
-- Building: Crypto
-- Building: Data
-- Link libtcmalloc_minimal : tcmalloc_minimal_internal
-- Will build ClickHouse 1.1.54385
-- Using internal compiler: headers=/usr/share/clickhouse/headers :  /usr/local/bin/clickhouse-clang  -std=c++17   -pipe -msse4.1 -msse4.2 -mpopcnt  -fno-omit-frame-pointer  -Wall  -Wnon-virtual-dtor  -Wextra -Werror -O2 -g -DNDEBUG -O3  -std=c++1z -x c++ -march=native -fPIC -fvisibility=hidden -fno-implement-inlines -nostdinc -nostdinc++ -Wno-unused-command-line-argument -Bprefix=/usr/share/clickhouse -isysroot=/usr/share/clickhouse/headers; /usr/local/bin/clickhouse-lld
-- Target check already exists
-- Using gtest:  : gtest_main
-- Found PythonInterp: /Users/abdealijk/anaconda3/bin/python (found version "3.6.4")
-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   dictionary_library
   dictionary_library_c
   dictionary_library_empty

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/abdealijk/Documents/oss/yandex/ClickHouse/build

I pulled the latest "stable" branch and retried this. now it gives me:
[ 23%] Linking CXX static library libPocoFoundation.a
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libPocoFoundation.a(ByteOrder.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libPocoFoundation.a(String.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libPocoFoundation.a(pcre_string_utils.c.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libPocoFoundation.a(ByteOrder.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libPocoFoundation.a(String.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libPocoFoundation.a(pcre_string_utils.c.o) has no symbols
[ 23%] Built target Foundation
make: *** [all] Error 2

The issues with OS X build are likely to have been fixed in the meantime.
Recently we have developers hackaton with numerous attendees and there was no issues compiling in Mac OS X.
If you still experience this issue, you should disable CapNProto library in cmake:
cmake -D ENABLE_CAPNP=0


spv server: Add address to supports response

Related to: https://github.com/lbryio/lbrycrd/issues/92
Changes:

keep track of supports address
modify the JSON response, include address on supports listing

(2) requires changing the client and could potentially make old clients incompatible. So, the very first step is getting an agreement on what will be the new response format and how to handle old clients.

This will be implemented by way of support metadata + new support apis


Add Onnx Model Zoo models

https://github.com/nod-ai/SHARK-TestSuite/pull/393 Thanks @vinayakdsci !


add test cases for GC bypassing Raft

Signed-off-by: qupeng<EMAIL_ADDRESS>What is changed and how it works?
Add a test case for GC bypassing Raft.
There are already some cases examining it in src/server/gc_worker/gc_worker.rs, but it's not enough because they are all based on a mock engine. This case uses real rocks engine.
Related changes
Check List
Tests

Integration test

Release note

No release note.

/merge


Implement signal.planck (Planck-taper window)

This is my tentative implementation of the Planck-taper window (added as signal.planck). See http://arxiv.org/pdf/1003.2939
Window and resulting spectra match the paper as expected, although I need to double-check the boundary conditions for very low samples to check my understanding that the first and last sample are always 0. If nobody chimes in, I'll mail the author.
Meanwhile, anything missing?

Some tests should be added. You can take a look at what was was done for the Tukey window in gh-4584.

I'll add some tests tomorrow.

@@            master   #6012   diff @@
======================================
  Files          238     238
  Stmts        43822   43840    +18
  Branches      8215    8219     +4
  Methods          0       0
======================================
+ Hit          34251   34252     +1
  Partial       2603    2603
- Missed        6968    6985    +17

Review entire Coverage Diff as of d65fd26

Powered by Codecov. Updated on successful CI builds.

Should be good now. I indeed found a typo while cross-checking the formula again. If you look at the paper, I tried to reproduce the same plot here (see page 4):

With the following:
from scipy import signal
from scipy.fftpack import fft, fftshift, fftfreq
import matplotlib.pyplot as plt

smp = 2**16-1
ftlen = 2048**2
fig, axes = plt.subplots(1, 2, figsize=(12, 5.5))
fig.suptitle("Planck-taper window")

window = signal.boxcar(smp)
axes[0].plot(np.linspace(-1, 1, smp), window, label='square')
A = fft(window, ftlen) / (smp/2)
freq = fftshift(fftfreq(ftlen, 1/(smp/2)))
resp = fftshift(np.abs(A))
axes[1].plot(freq, resp, label='square')

for f in [100, 30, 10]:
    e = 1/f
    l = '$\epsilon = 1/{}$'.format(f)
    window = signal.planck(smp, e)
    axes[0].plot(np.linspace(-1, 1, smp), window, label=l)
    A = fft(window, ftlen) / (smp/2)
    freq = fftshift(fftfreq(ftlen, 1/(smp/2)))
    resp = fftshift(np.abs(A))
    axes[1].plot(freq, resp, label=l)

axes[0].legend(loc='lower left')
axes[0].axis([0.79, 1.01, -0.1, 1.1])
axes[0].set_xlabel('Time /s')
axes[1].set_xscale('log')
axes[1].set_yscale('log')
axes[1].axis([1, 1e4, 1e-10, 1])
axes[1].set_xlabel("Frequency /Hz")
axes[1].legend(loc='upper right')

I actually find this visualization much better suited to see the frequency-response compared to the current examples in other window functions. It's a bit more expensive to compute, but I'd love to have that for all functions.
I tried to use subplots inside the example itself, but somehow run into problems and gave up, as regenerating the docs takes some time...

By "this visualization", do you mean logarithmic x-axis? I definitely agree on that point. It could also be appropriate to show responses of related windows. (Though, if you were to undertake this for other windows, you should open a different PR)
For this window, I was curious how it compares to the Tukey window, which is similar in concept. Since the Planck window was designed for GW chirp signals, I wasn't sure how much utility it really would bring to the growing zoo of window functions already in scipy.
The authors in the reference you linked to only compare this window to the rectangular window, which is a bit disingenuous, since pretty much any tapered window would show less spectral leakage than the rectangular window, so it doesn't really argue for the merit of their particular design. In any case, I did the comparison to Tukey myself:

(Note: here, the frequency response plots are normalized to DFT bins, as the window's response is independent of the specific sampling frequency used.)
So, there does seem to be some advantage to the Planck window in the eventually steeper rolloff, so I'm in favor of including this in scipy. (I suspect the apparently flat floor may be some discretization noise...)
I haven't looked too closely over your code, but will do soon. In any case, please squish this PR into one commit, and title it according to the [developer's guide].(https://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html)

Also, as I discovered when running your code, the plotting goes much faster if you don't plot every point. The source for the plot in my previous comment, which runs pretty quickly, is here: https://gist.github.com/e-q/b5069f22c190a6f72d2d322bac940b60#file-planck-py

Squashed. As for the visualization, I meant both: it would be nice to show only half of the window for greater detail, and maybe put a fixed window for comparison (boxcar is a bit pointless shape-wise, maybe it would be best to use a well-known window such as hann, or a gaussian). Also in the frequency response, aside for the log axis, it's nice to always compare to the same reference window.
As for the noise in planck at 10e-10, it's probably a float artifact. I'd expect the rolloff to continue indefinitely. The actual point changes depending on the sampling parameters.

Is this used anywhere outside of gravitational wave research?  Has it actually been used there or is this paper you've linked to just suggesting that they should use it?   If it isn't used anywhere else, can you provide some motivation for why we should include it?  I'm -something right now, since AFAICT, this isn't a window that anyone is actually using.

On Wed, Mar 30 2016, Eric Moore<EMAIL_ADDRESS>wrote:

Is this used anywhere outside of gravitational wave research? Has it
actually been used there or is this paper you've linked to just
suggesting that they should use it? If it isn't used anywhere else,
can you provide some motivation for why we should include it? I'm
-something right now, since AFAICT, this isn't a window that anyone is
actually using.

I incurred into similar problems as the authors in tremor analysis where
I needed an adjustable tapered window. I experimented with Tukey
initially, but later found also this as an alternative which has a
steeper falloff and better suited my purposes.
I actually didn't check the literature much about other uses (I really
don't care if it has been used only once). I expect one can come up with
dozens of specialty windows, so I see your point. But the definition is
pretty simple and has nice characteristics. I'm surprised to see it
defined only in a 2010 paper honestly.

I can confirm that it is actively used in GW research, but I'm not aware of
its use anywhere else.
On Wed, Mar 30, 2016 at 05:14 Eric Moore<EMAIL_ADDRESS>wrote:

Is this used anywhere outside of gravitational wave research? Has it
actually been used there or is this paper you've linked to just suggesting
that they should use it? If it isn't used anywhere else, can you provide
some motivation for why we should include it? I'm -something right now,
since AFAICT, this isn't a window that anyone is actually using.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/scipy/scipy/pull/6012#issuecomment-203401793

Any consensus? In the same spirit (and if there is interest), I'd also like to contribute the Planck-Bessel variant.

The standard procedure for things like this is to send a message to<EMAIL_ADDRESS>to try and get more responses and try to build consensus.

scipy-dev thread: https://mail.scipy.org/pipermail/scipy-dev/2017-January/021639.html

Sure. I'm not opposed to adding windows that are actually being used.

On Wed, Apr 11 2018, Eric Larson wrote:

@wavexx when you get a chance can you rebase this? The window should be added to the
signal.windows namespace only nowadays.

In a week or so would be too late?

1.1.0 branches tomorrow, but it's okay to get this into 1.2.0. That would give you time to implement the Planck-Bessel variant, too (assuming that is used in the scientific community, too).

@wavexx any interest in coming back to this now that scipy/signal/windows/ exists and has its own namespace?

I'll need to work again the project where I used the planck taper in a few months. I can revise the implementation then


Depreciate Superfluous get_ API Calls

in priority: get_messages, get_messages_by_index, get_asset_info, get_block_info, get_blocks, get_asset_names. All get_*, should be enough. We just need to store some counter cache in the database.
get_asset_info() is a good example for what I mean by counter cache: we have a table assets, it contains only the ID and the name for now. We just need to add to this table some columns (supply, holders_count, ..) etc..  Then get_asset_info() can be replace by something like get_assets(filters=[('asset_name', '=', 'TOTO')])

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8043181-depreciate-superfluous-get_-api-calls?utm_campaign=plugin&utm_content=tracker%2F494307&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F494307&utm_medium=issues&utm_source=github).

Obsoleted by #1327


Publish to Maven Central

+1

I published a link to a great guide here: https://github.com/TheThingsNetwork/java-app-lib/blob/api_improvements/MAVEN.md
Do not hesitate to slack me in case you need some help

I saw, thx 😜

JIRA ticket created: https://issues.sonatype.org/browse/OSSRH-25140

Initial releases published to staging, waiting for sonatype

Should be published soon. I documented at https://github.com/TheThingsNetwork/java-app-lib/wiki/Publishing-to-Maven-Central

Done: https://oss.sonatype.org/#nexus-search;quick~TheThingsNetwork


Optimisations for Feeds and Sharing logic

[ ] In privacy/visibility selector change “Share with...” to “Share to...”

[ ] Allow sharing to only one privacy group (context/community) and strictly adhere to the rule of ONLY showing this content within the selected community, and ONLY pushing it to HOME-feeds of users that follow that specific community.

[ ] Full list of possible “Share to...” options:
My Profile
Public
Friends
Only me
X,Y,Z Members
Relationships...
Specific friends...
Groups and other communities (spaces, events, etc.)

[ ] When user A posts to their profile (public), post should appear on their profile feed and in Home feeds of people that Follow user A.

[ ] When User A posts to a Group X, post should appear on the feed of the Group X. Users that follow Group X should receive this post in their Home feeds. The post should NOT appear on User A profile feed. The post should NOT appear on Home feeds of users that follow User A, unless they also follow Group X. Same applies for Spaces/Events.

[ ] As with groups, if User A posts to profile feed of User B, only people who follow User B receive this post in their Home feed.

[ ] One post can only be posted to one community. It is possible to repost to another destination (own profile, another group, etc), which would create a new timeline update (repost) with own comments and reactions, referencing original post.

[x] Separate Channel posts from the Home/News feeds and create a new feed that shows only posts from channels followed by the user. This feed can be called “News”.

Ultimately there should be 4 discovery feeds:

News(this is new feed which need to be added) - posts from Channels I follow
Home(current dashboard feed) - posts from people/orgs/groups/events/spaces (except channels) I follow and allowed to see (public, friends-only and I’m a friend, relationships and I’m a relationship, membership matches mine, my own).
Latest(current homepage feed) - all posts I’m allowed to see, regardless of following (except channels). All public posts for unauthenticated.
Popular(current Hot feed, change sorting algo) - all posts I’m allowed to see sorted by popularity score: Reactions+Upvotes-Downvotes/time-since-first-published.

And context specific feeds showing inside of the context (profile feeds, group feeds, etc).
Displaying feeds
Implement ‘infinite scroll’ with max 100 updates, loaded in groups of 10 on scroll-down. Once 100 is reached, offer a “load more” button, as usual. Initial load only calls for 10 updates, next 10 loaded as soon as page-scroll down is detected (before button of the page is reached).

 It will allow to select a date which posts should be loaded from.

'Empty' is shown in the timeline in the same time with items in it.

I cannot reproduce the issue with 'Empty' message anymore neither on Dev installation nor on CI.UNA.IO site.

Points №3 and №7 were moved on the next versaion.


Plugin fails when JSON payload includes key with leading underscore

Error:
   MQTT Shims Error                Error in plugin execution runConcurrentThread:

Traceback (most recent call last):
  File "plugin.py", line 107, in runConcurrentThread
  File "plugin.py", line 132, in processMessages
  File "plugin.py", line 416, in update
StandardError: LowLevelBadParameterError -- illegal character in XML tag name or value

Example payload:
{
"state_string": "Operational"
"_timestamp":<PHONE_NUMBER>
"_event": "PrinterStateChanged"
"state_id": "OPERATIONAL"
}

Try https://github.com/FlyingDiver/Indigo-Shims/releases/tag/0.3.5

That seems to work, thanks.
I now have new issue, however.  The payload includes keys that are usually numeric, but are sometimes null.  In this example printTime, printTimeLeft, and others are initially null before the print physically begins, after which they become real numbers.
Example payload:
{"_timestamp":<PHONE_NUMBER>, "progress": 0, "printer_data": {"progress": {"completion": null, "printTimeLeftOrigin": null, "printTime": null, "printTimeLeft": null, "filepos": null}, "state": {"text": "Operational", "flags": {"cancelling": false, "paused": false, "operational": true, "pausing": false, "printing": false, "resuming": false, "sdReady": true, "error": false, "ready": true, "finishing": false, "closedOrError": false}}, "currentZ": null, "job": {"averagePrintTime": null, "lastPrintTime": null, "user": "pi", "file": {"origin": "local", "name": "tray_sm_0.2mm_PLA_MK3S_7h4m-TEST-2.gcode", "date":<PHONE_NUMBER>, "path": "tray_sm_0.2mm_PLA_MK3S_7h4m-TEST-2.gcode", "display": "tray sm_0.2mm_PLA_MK3S_7h4m-TEST-2.gcode", "size": 7046139}, "estimatedPrintTime": 15356.916729460274, "filament": {"tool0": {"volume": 99.13513212812876, "length": 41215.598529984934}}}, "offsets": {}}, "location": "local", "path": "tray_sm_0.2mm_PLA_MK3S_7h4m-TEST-2.gcode"}

Error message:

Traceback (most recent call last):
  File "plugin.py", line 115, in runConcurrentThread
  File "plugin.py", line 139, in processMessages
  File "plugin.py", line 734, in update
TypeError: state value type must be bool, int, real, or string

   MQTT Shims Error                plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

Could these states remain blank or zero when null?

This issue fixed in 0.3.5.

@kmarkley See new issue.


Adds the limit for the deferred stream's queue size

Fixes the issue with streaming: if the rate of consuming data by the client is slower than the rate of streaming data by the server from the source, the server prefetches too much data from the source.
Proposed solution is to limit the queue size (size of the result buffer) in DeferredWorkState.
Changes:

size of the queue in DeferredWorkState has a limit now;
action of registering DeferredExecutionTask is unbound from its starting with new TaskDispatcher class;
previous DeferredExecutionTask has to complete before starting the new one in DeferredStream.

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


docs: add description of project direction, vision and scope

Cilium’s requirements for commit access include “Plans for sustained contribution to the project compatible with the project’s direction as viewed by current committers” but until now we had no clear articulation of what that direction is. This commit adds a description of Cilium's direction, vision and scope (agreed by lazy consensus in the committers Slack channel).

looks good :+1:


updated for null safety

Thanks for contribution, The purpose of your PR is on the repo, the repo is null-safe right now, Please check out the latest version and open another issue/PR if you see any problems! Thanks for your help and stay tuned ✌💙


Ventilator PCB Rev A Schematic Design Review

This purpose of this ticket is to record and discuss the schematic design review of the Ventilator PCB Rev A.
We've split the pages up between engineers and this ticket can serve as a checklist.  If there is a finding that results in more than a minor or formatting change, please create a separate issue ticket for it and link it here.

[x] TOP (Stephanie)
[x] Logic/Control Power Supplies (Edwin)
[x] 5V UI/ / Control Supply (Edwin)
[x] 3.3V Logic / Sensor Supply (Edwin)
[x] Cycle Controller (Don)
[x] UI Computer (Edwin)
[x] Alarms and Power Monitoring (Stephanie)
[x] Indicators (Edwin)
[x] Safety FPGA (Edwin)
[x] Pressure Sensors (Stephanie)
[x] Pressure Sensor Daughterboard (Stephanie)
[x] Oxygen and Temperature Sensors (Don)
[x] NTC Temp Sensor (Don)
[x] Stepper Motor Driver (Edwin)
[x] Additional Aux Functions (Stephanie)
[x] System Monitor / FPGA ADC (Stephanie)
[x] Power Entry / Battery Handling (Don)
[x] Battery Charger / Source Switching (Don)
[x] Battery Balancer (Don)
[x] 12V System Buck Converter (Don)
[x] PSOL / Heater Driver (Edwin)
[x] STM Programmer for Cycle Controller (Stephanie)

Special Requests:

[x] extra check on the STM32 100-pin symbol pins (Stephanie)

We want to have a comprehensive design review before we go into layout.
Here are the original board requirements: https://docs.google.com/document/d/1RPkyGj1lCVv08fhpkGO5IUJaUcc130k_tNvB63ljrs0/edit?usp=sharing
Power/Thermal Calculator tool here:
https://docs.google.com/spreadsheets/d/1Otu4uRq1WR7CHx7AOSxF2eoAqoWKeeAT3UDNmPhiSdw/edit?usp=sharing
Here's a schematic review checklist as a guideline, feel free to add to this:

[ ] Transistors, diodes, LEDs, and polarized caps oriented correctly.
[ ] Pinout checks for all components
[ ] Capacitor voltage ratings and voltage-capacitance derating
[ ] Thermal margin for power components (broken out to thermal-focused ticket #932)
[ ] I2C nets not swapped and with one set of pullups, somewhere (remember that some modules like the RPi have onboard ones)
[ ] MISO/MOSI directions and daisy-chaining, if applicable.
[ ] JTAG direction and daisy-chaining, if applicable
[ ] Single pin nets (apply NC / NoDRC mark if applicable)
[ ] Input-output directions on ports and components
[ ] Check for misspelled or incorrect power rail names
[ ] Title block correctly filled out

Don't forget

[x] Put the issue in a milestone
[x] Assign it to one of the projects
[x] Add appropriate labels
[x] Mention dependent/blocked issues if any

Potential changes in bold, everything else is just comments
UI Computer:

Pinout check is good.
Doesn't look like +5V_RPi connects to anything (upper left of TOP sheet).  Should this be +5V_GUI?
We've had trouble with powering the touchscreen exclusively from the pi's USB ports in the past, we should add a 2-pin micro-fit connector to provide 5V to the touchscreen independent of the Pi
Let's flip the bit on UI_ID0 from 0 to 1.  The ID is meant to tell the software which version PCB it is plugged into, and 0b00 was rev 1.0.  Same goes for the Cycle Controller.
Do we have a receptacle to receive the USB UART adapter TX/RX? (or are we even using it anymore? We wanted to have the Rpi be able to program the Cycle Controller, but can that be done through the STLink?)
I think we might want the buzzer on one of the PWM pins
The Rpi 3B+ never had well-published alternate pin functions, so we used generic GPIOs for CTS/RTS on PCB Rev 1,0, but the Rpi 4 does, here, and it has dedicated UART0 CTS and RTS lines. CTS0 and RTS0 are on GPIO 16 and 17, respectively.

Logic/Control Power Supplies

[x] General design looks good
[ ] CSD17304Q3 on 5V-USB-En: this should be a P-Ch FET for this work, also this is pretty oversized for the circuit, and we might be able to eliminate the level-shifter if we used a smaller, logic-level PFET (MTM231232LBF in SC70 package would do the trick.  Even better, I suspect we can lose this circuit altogether as we have been using the current Nucleo board with JP5 in the E5V position, and so this circuit was never exercised, and we had no troubles with programming.  Maybe leave the 5V-USB to diode-or into 5V-Ctrl so we have the option of powering the STLINK/CC/Sensors section of the board from USB when it is detached from the vent.

5V Buck Converter

[x] Pin check is good
[ ] Power Good is an open drain signal, so the testpoint won't have much meaning without a pullup
[ ] Inductor does not have a part selection so can't check power yet.
[x] Diode: worst case with ambient at 40C, 70% duty cycle (16.8V VLink), diode Tjmax is 150C, and Rthja of 85C/W gives about 1.3W capability, which at Vf of 0.4V and duty cycle of 70% is 4.6A.
[ ] At Vlink of 16.8V, the 7.2uH inductor will give a ripple current of 1.2A, which feels high for our likely consumption of 2A on UI and <1A on CC.  10uH might be better.
[x] FB resistor divider yields 4.98V
[x] Cap voltages on defined caps look good, but 100nF cap is not defined

3.3V LDO

[x] Pin check good
[x] Cap voltages good
[x] Power good in this case is a driven output, so is fine without a pullup

General

[ ] What, if anything, do we do about the battery charger needing a host to set charge current?  Won't charge the first time it is plugged in.
[ ] Can we rename net oxygen level to oxygen_concentration or oxygen_fio2?  I feel like oxygen level makes it sound like a tank level.

Safety FPGA

[x] Pin check good
[x] I2C polarity and pullups good

Indicators

[x] Simple page.  everything looks good here.
[ ] Not sure we need two power pins for 5V and GND, each of those microfit pins can carry 8+A.  Was the 10-pin connector selected to make it dissimilar from the other connectors (to avoid mistaken mating)?

UI Computer:

Touchscreen power: makes sense, done
ID bits: same, for RPi.  For the cycle controller I don't see any ID bits though, looks like it was never assigned in the ICD.  We may have to ditch the SD card to free up pins for this.
Receptacle for USB UART: I don't know much about this - the STLink does have its own tx and rx but I couldn't find any info in the STLink manual about whether it exposes that as a generic USB serial interface.  Wouldn't hurt to have an extra connector for that.  Any preferred USB-serial cable? (I like the FTDI TTL-232R-3V3 personally but don't know if you guys already have a specific one on-hand)
Buzzer on PWM: yep makes sense, I noticed it wasn't when looking at the ICD but figured it was for a reason/holdover from last version. GPIO18/19 can also host PWM0/1 but with GPIO12/13 being freed up below...
RTS/CTS: good find, changed.

Logic/Control Power Supplies:

5V-USB-En: Oops, I meant to copy over one of the P-FETs from the battery controller, looks like I grabbed the wrong one. (And yeah it's oversized, but didn't seem worth finding then sourcing an extra part for a one-off; same with the level-shifter even though it would be overcomplicating things in a different design; already had one for the blower)  Even better though if we can just ditch the power-switching bit though.  Yeah the point of the diode-OR is to be able to program the STM without powering up the whole thing, it was in our initial spec I think.
5V Buck:
Power Good: yeah it's not actually intended for probing, it's just a "just-in-case" testpoint so in the rare event we actually need a power-good signal it won't be as hard as soldering to a DFN pin - figured we'd patch in a pull-up if we do happen to actually want to use it.
Inductor: sounds reasonable, I just took that from the existing design, will use one in the same series as one of our existing ones.
100nF cap: not all the cap voltages are defined yet, that's still in process; I haven't picked out the USB mini-B connector yet either for the STM programmer.

General:

Oxygen: sure, oxygen-FiO2 sounds reasonable (...-concentration seems overly long for typing out labels); changed.
Pi power: good catch, fixed.  Deleted +5V_Rpi from library to prevent future mixups.

Indicators:

Doubled pins: I agree we don't need 2x, will leave Stephanie to answer about the dissimilar pin #?

Actions from meeting:

[ ] Switch valve driver fuse to PTC
[ ] Check in with software about how to do RPi to STM32 programming
[ ] Switch to 100-pin version of STM32

PSOL Driver

[ ] recommend enlarging lower FET bypass 0Ohm resistor to 0805 or bigger, to carry to up 2A.  Same with the high-side bypass 0Ohm resistor.
[ ] recommend making the fuse a thermally resettable one, 0ZCF0200AF2C was selected for Rev 1.0
[x] cap voltage good
[x] thermal: worst case Rds(on) @150C of 166mOhm, ambient temp of 40C, Rthja of 41C/W, yields max Pdiss of 2.7W, which equates to 4A of current.
[x] pin check good
[x] current limits and current sense resistor calculations good
[ ] Should we consider a resistor divider instead of the 10k current limiting resistor for the CS output?  Even weak overvoltages can saturate an ADC and affect the next reading in the conversion.

All sound reasonable; implemented.

Changed the NTC temp sensor slightly to put the ESD protection on both pins just in case (might as well since one side was unused).  Can revert if there's a reason not to do this.

swapping UI LED pinouts on ICD to match top level (just with each other)

Pressure Sensor page:
BMP280 symbol missing pin 7 to ground

Additional Aux:
Found the I2C pull-ups I didn't see originally for CC-SDA/CC-SCL. I vote to leave on top page and take out here

System Monitor ADC:
LM4120 symbol wrong: 5 should be labeled VOUT, but okay connections. Pin 1 named VRef (would be good to show it unconnected)

All good catches, fixed

STM Programmer:
Two pins have CC_SWCLK_OUT

That's correct actually, it follows the nucleo STLink schematic (which is a massive pain to read because it's under-documented and has terrible net naming, but that's a separate story).

Stepper driver

[ ] pin check: everything correct, except symbol name is EPAD, but footprint name is 37.  Recommend fix this on the footprint.
[x] IO wiring, LEDs, daisy-chain, all look good
[x] Power wiring good
[x] Cap voltages good

Review things:

[ ] Swap the indicators connector to 8 pin
[ ] DNP the i2c pullup resistors on the FPGA page (the module has them already)
[ ] check that the TVS diode on the NTC thermistor is correct
[ ]

From the first pass of thermal calcs it looks like the FETs can be made to work, but the DC (BATFET, Vin-Adp switches, Pack-P battery balancer switches) and buck high-side FETs (battery charger, +12V supply) definitely need some real heatsinking.  The buck low-side FETs are fine with the minimal footprint because duty cycles are always pretty high.  Any heatsinking scheme that gives a total Rth-ja of 70 K/W or less should work well for everything: can either...

Add lots of copper area, mechanical engineers probably won't be the biggest fan of this one but it might not be that bad space-wise
Via down and put a metal plate against the bottom of the board through some gap pad for electrical isolation
Use some SMT heatsinks like these guys: https://octopart.com/search?q=573100d00010g

I'll take a look and see if we can find some lower Rds(on) options.  These aren't switching FETs so we don't care as much about Qg.  Might add BOM lines, but I think that is better than adding assembly steps.

@dcstraney do you have your thermal calcs written down somewhere?  The only part I'm getting in my calcs as marginal is the P-Ch BATFET in the BQ24773 circuit, which we can definitely solve in the BOM by going to a 5x6mm part with lower thermal resistance and a bit less Rds(on).  Using the datasheet thermal resistance to ambient, with thermal vias to a backside ground plane, and a 35C ambient temperature, I get a temperature margin of 20C.  Not great, and we can get to a much better margin of 98C by going to SI7145DP-T1-GE3 (a 5x6 part).
All other parts have at least 30C of temperature margin mounted to the board with a solid backside ground plane and thermal vias as the only heatsinking.  The worst one is the BQ24773 because of its high switching frequency, and we are doing about as well as we can in the 5x6mm part class.  We do have the option to improve this by lowering the switching frequency from the default via i2c.
The DC FETs on the AC input have 44C of thermal margin.  I think that's good as I don't see our adapter current going up past the 120W level.
LM5141 switching FET has 53C of margin, and that's probably fine.  We could go up to a 100W blower and still be ok.  Lie you said, the bottom side FET is fine, because it's basically never on.
The FETs on the MAX17320 battery protector/balancer have 39C of margin.  This should be fine as-is, but we can open up the option for higher power blowers by going to a 5x6mm package here.
Calcs are here: https://docs.google.com/spreadsheets/d/1Otu4uRq1WR7CHx7AOSxF2eoAqoWKeeAT3UDNmPhiSdw/edit?usp=sharing
I'll get these changes (BQ24773 PFET and MAX17320 NFETs) into the schem shortly.

Review complete, design submitted.  Closing ticket.


Refactor the process ledger queue protocol

The idea behind these change is to bring this protocol in line with other recent refactors. i.e. to have a LedgerManager that is cranked (in a similar fashion to how the ObjectiveManager is cranked).
The initial goal will be to maintain current functionality, but to increase clarity wherever possible. This may involve deprecating protocolState and actions, as we have been doing elsewhere.
A possibly-useful side effect will be increased familiarity and understanding of the underlying protocol that this code implements. That should aid in judging it against alternatives.

Glad that we can better encapsulate the "pessimistic syncing" code

Glad that we can better encapsulate the "pessimistic syncing" code

One thing I dislike is that we're coupling interactions with the store into logic related to the protocol. For example, if the protocol detects that the merged outcome is equal to the current outcome, there is a call to store.removeLedgerProposals. This makes it harder to write unit tests for the protocol by requiring a spy on the store, or a mock store, or only supporting integration tests.

One thing I dislike is that we're coupling interactions with the store into logic related to the protocol. For example, if the protocol detects that the merged outcome is equal to the current outcome, there is a call to store.removeLedgerProposals. This makes it harder to write unit tests for the protocol by requiring a spy on the store, or a mock store, or only supporting integration tests.

Side comment: this draft PR is pretty old and I am probably going to close it in favour of a fresh one, although the aim is going to be the same.
I agree that by peforming this refactor we are coupling the store and the protocol more tightly, and this makes tests harder to write, and slower. But the hope is that the other advantages outweigh this.
I suppose @tomclose can speak to those advantages better than me. I think part of the rationale in other similar refactors is that the "protocol" can make calls to the store more judiciously / parsimoniously.
I'll take some time to think it over some more though, because I think you raise a good point.

Side comment: this draft PR is pretty old and I am probably going to close it in favour of a fresh one, although the aim is going to be the same.
I agree that by peforming this refactor we are coupling the store and the protocol more tightly, and this makes tests harder to write, and slower. But the hope is that the other advantages outweigh this.
I suppose @tomclose can speak to those advantages better than me. I think part of the rationale in other similar refactors is that the "protocol" can make calls to the store more judiciously / parsimoniously.
I'll take some time to think it over some more though, because I think you raise a good point.

I prepared a PR that reintroduces the pure-function test suite. I think that could live alongside the current implementation and the new tests https://github.com/statechannels/statechannels/pull/3192
If we follow through on the refactor, we can just delete it again.

I prepared a PR that reintroduces the pure-function test suite. I think that could live alongside the current implementation and the new tests https://github.com/statechannels/statechannels/pull/3192
If we follow through on the refactor, we can just delete it again.

Todo:

[ ] Link against the graph repo and run tests

Todo:

[ ] Link against the graph repo and run tests

Todo:

[ ]  Link against the graph repo and run tests [? turns out the two codebases aren't compatible at the moment :( ]

I linked this branch against this one in the other repo. Unit tests passed. I wasn't able to run e2e tests yet, I just see errors on my local machine. To be continued.

Todo:

[ ]  Link against the graph repo and run tests [? turns out the two codebases aren't compatible at the moment :( ]

I linked this branch against this one in the other repo. Unit tests passed. I wasn't able to run e2e tests yet, I just see errors on my local machine. To be continued.

I was in fact able to link and get tests to pass in the other repo https://github.com/statechannels/graph-payments/pull/15.
However tests are now failing in this repo since I solved conflicts with master 😞

I was in fact able to link and get tests to pass in the other repo https://github.com/statechannels/graph-payments/pull/15.
However tests are now failing in this repo since I solved conflicts with master 😞

The test issue could be a flicker https://github.com/statechannels/statechannels/issues/3208

The test issue could be a flicker https://github.com/statechannels/statechannels/issues/3208


Parameter description misplacement

Description

In NetworkStream constructor parameters descriptions was misplaced. Fixed it.

Motivation and Context

Avoid confusion.
It's my first PR. So I highly motivated to train on this little fixes how to do PR's right.

How Has This Been Tested?

Checked by eyes.

Screenshots
Types of changes

[x] Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

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

@networkfusion, thanks. I will in future PR's. Now I have not enough experience to somehow edit this PR... commit... or what should I actually do to follow your advice?

@networkfusion, thanks. I will in future PR's. Now I have not enough experience to somehow edit this PR... commit... or what should I actually do to follow your advice?

Just change and commit to your source branch and this PR will update automagically....

@networkfusion, done!


Invalid CSS "px solid", border not effective on "inner" zoomType

I noticed that the function getInnerZoomStyle() in line 198 contains invalid CSS:
'px solid ' + self.options.borderColour + ';' +

Obviously, there is something missing, I also noticed that a similar function for zoomType "window" contains a border, so I suppose a copy/paste went bad at some point.
The line 198 should probably look like this:
'border: ' + String(self.options.borderSize) + 'px solid ' + self.options.borderColour + ';' +

Now, you get a proper border set based on the borderSize parameter and properly coloured based on the borderColour parameter.

Hi, great!.  Do you want to create a PR or should I put it ?  (PR are most welcome, even if small)

Please open one yourself if possible, thank you.

oh well, I love seen PRs from others.
Its already committed: https://github.com/igorlino/elevatezoom-plus/commit/a71c2c125643aaef8e0bb1222f238daa4a305a2e


Remove redundant SELECT

Spark does not like the additional SELECT in front of the abs(..). Therefore I'd suggest removing it, if that is ok with the other database engines.

hey @Fokko - thanks for making this PR! We could be clearer about this, but for now, dbt-utils only works with postgres, redshift, snowflake, and BigQuery. All of this code would become a huge mess if we tried to support presto + spark + other plugins in the future too. There's just too much variance between database engines for this to be tractable IMO.
I'm going to close out this particular PR, but I'm very grateful you took the time to make it! Let's figure out a way to introduce code like this more directly into the spark integration tests. We should probably drop the dependency on dbt-utils in those tests...

Thanks, Drew for the elaborated answer. I understand your concern, but in this case, I would consider accepting this PR since it does not change the behavior of the query. I understand that Spark is a second class citizen right now, but supporting this would be nice anyway.
My experiences with Spark and DBT are in general very good. Personally I would not support Presto since it is only a query layer, instead of a processing framework such as Spark.


Consumer stops consuming after a while [kafka-pubsub]

Hi,
we encountered issue with your package, when private method createConsumer in kafka-pubsub.js does not handle node-rdkafka Stream API in correct way. This problem leads to not catching all messages from Kafka broker, in our case, after 3 events were recieved, consumer stops consuming.
Current code:
stream.consumer.on('data', (message) => {
      let parsedMessage = JSON.parse(message.value.toString())
      ...
    })

You access Standard API via Stream API object without manual setup for flowing/non-flowing mode (see examples on https://www.npmjs.com/package/node-rdkafka). One of the solutions is use only Stream API (example below).
Fix:
stream.on('data', (message) => {
      let parsedMessage = JSON.parse(message.value.toString())
      ...
    })

This fix helps us to get it working, so we'll be glad to have this thing fixed in the next release. Thanks!

This fix also fixed our issue with restarting or re initializing the kafka pubsub, so thanks @cubase for this, hope we get a new release   for this soon. cheers!


id fields on most resources claim to be type=int instead of string

Almost every resource has id marked in the schema as an int instead of a string.  I added some generic validation to the UI and everything asploded when I started coercing id: "1xx42" to ints.

This is covered in the API v2 list. https://github.com/rancher/rancher/issues/1052


gpsprune: add media type associations

Description of changes
Associate GpsPrune with GPX, KML, and KMZ files:

Things done

Built on platform(s)

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

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

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

[x] Tested compilation of all packages that depend on this change using nixpkgs-review rev gpsprune/media-type-associations.
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Great, thanks!


:bug: fix(documentation): fix documentation

To which ticket/issue is this PR linked to?
https://jira.lyft.net/browse/MGW-451
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation update
[ ] Code refactoring
[ ] CI/CD or build process changes
[ ] Other

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add n8n-nodes-execute-code

This PR adds the n8n-nodes-execute-code package to the community nodes JSON file. This package allows users to execute programming code submissions using the Judge0 API.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Trần Tuấn Anh seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

I'm not familiar with community-nodes.json.
Can you please link to where you found the docs for adding stuff to this file? 🙏🏽
We might need to update the docs.


activateAR in chrome not working

In the "Load" event hander, I am trying to call activateAR on mobile. It is working in Firefox and in Safari, but not in Chrome.
Maybe it is not a bug, it is the intended working on Chrome, due to the limitation to the browser to not imitate user interaction. Can you clarify on this?
Example
Code:
<script type="module" src="..model-viewer.js"></script>
 <model-viewer id="model-viewer" src="..Delonghi-machine.glb" ios-src="..Delonghi-machine.usdz" alt="Machine" auto-rotate camera-controls ar magic-leap>
        <button id="mv-ar-button" slot="ar-button" style="...">View in your space</button>
 /model-viewer>

...
<script>
var modelViewer = document.getElementById('model-viewer');
modelViewer.addEventListener('load', function () {
    modelViewer.activateAR();
});
</script>

Does this comment help? Does it work better if you put webxr ahead of scene-viewer in ar-modes?


Update FuseSoC SweRV config generator

Adapt swerv_config_gen.py to changes in the swerv.config script in the SweRV EL2 1.3 release

Olof, this is great!

Olof, this is great!


rigel-engine: init at 0-unstable-2024-05-26

Things done
Adds rigel-engine, closes https://github.com/NixOS/nixpkgs/issues/189620.
Decided to use an unstable revision as the stable version is more difficult to build.

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Made your suggested changes. Thank you for the very quick turnaround. Please let me know if there's anything else that needs to change!

Funny, the author of this project once gave a talk at my local C++ user group a few years ago. :-D


common: add sensor driver hdc1080

Summary:

add hdc1080.c/hdc1080.h

Description:

for AALC sensor

Test Plan:

waiting for test

for test


Installer problem

Hi Andrew - great concept, just trying to get it loaded into OS X to try out. I got this error on install any ideas? Cheers Paul.

Does the evohome-client folder exist in the directory you're in?
Has the checkout worked - can you see a setup.py file inside the folder?

Otherwise, the command you're running looks right and I've not heard of others having trouble installing.
Andrew

Hi Andrew, thanks for your quick response. I'm away from home with work for a couple of days now but when I get back I will check and let you know. I just had a first quick go at installing it so may well have made a mistake like below. I did get pip to work through. I'm an ex developer but years ago and not too familiar with Python but will pick it up again! Great idea this script, I just upgraded my old original EvoHome and impressed by the new one. Just a shame their own iOS app is rubbish. I also use a Netatmo and that has a great mechanism for logging.

Does the evohome-client folder exist in the directory you're in?
Has the checkout worked - can you see a setup.py file inside the folder?
Otherwise, the command you're running looks right and I've not heard of others having trouble installing.
Andrew
—
Reply to this email directly or view it on GitHub.

Hi Andrew - my mistake, I had the client folder in a different place and dumbass just copied in the ./ reference… Thanks!

Does the evohome-client folder exist in the directory you're in?
Has the checkout worked - can you see a setup.py file inside the folder?
Otherwise, the command you're running looks right and I've not heard of others having trouble installing.
Andrew
—
Reply to this email directly or view it on GitHub https://github.com/watchforstock/evohome-client/issues/7#issuecomment-78010894.

I'd love to pretend I'd never done something like that! Glad it's working now
Andrew


bug: ethereum transaction is not signing properly

it is signing properly
add the correct validation to accept client private key for ethereum while address creation


Add layer: '*' wildcard for data source layer matching

This PR introduces a "wildcard" syntax for the source layer in the data block in layers. When the layer is specified as *, it will match ALL layers in the data source.
This is useful for easily creating wireframe-like views, without knowing or needing to specify all the layers in the data source:
layers:
  wireframe:
    data: { source: tilezen, layer: '*' }
      draw:
        lines:
          color: red
          width: 1.5px
          order: 1
        points:
          color: yellow
          size: 4px
          collide: false

One gotcha to this syntax is that due to YAML syntax, it requires the wildcard to be quoted, e.g. layer: '*' NOT layer: * (which will generate an error). Possible alternate suggestions?
Note, this branch currently extends #712, but can be separated from it before merging if needed.

I dig it, I could have used it a few times already ;)

Seems useful and simple to implement.
I feel like the most intuitive syntax would be to treat null or undefined layer values as a wildcard. If no specific layers are named then it's reasonable to assume that any layer applies. However, this isn't compatible with the current behavior of using the scene layer name as the data layer in this scenario.
layer: '*' could be fine I think, as long as it doesn't lead people to assume that this field supports pattern-matching.
layer: _ also seems reasonable to me (it isn't as ubiquitous as * but _ acts as a sort of catch-all placeholder in Rust and Swift).

@matteblair yeah I can definitely see the logic for using an undefined layer to mean all... but that would be a pretty huge breaking change given the current scene layer matching behavior! Next time around... ;)

How do you then match a layer named *?

You could still match a layer named * with layer: ['*']

We could also use a different key, e.g.
layers:
  wireframe:
    data: { source: tilezen, all_layers: true }

👍 for using an explicit key. all_layers.

Any other votes on syntax here? While all_layers is good because it's more explicit, it feels a little less Tangram-y vs another layer variant (not saying that's necessarily a great thing :), and also means you have potential conflict if both layer and all_layers are specified. I'm totally fine with it though if that's the consensus. I'm also fine with layer: _ and like that it doesn't require quotes in YAML.

My preference:

all_layers: true (most favorite, but tossup with the next one)
layers: '*'  (the quoted * is slightly confusing, and it's a magic symbol)
layers: _ (least favorite, I'm not familiar with that syntax)

If we really wanted to make the options mutually exclusive we could do something like layers: true, but that seems even more opaque than '*' or _ 😀
My favorite option is a separate key like all_layers - I think it's the least likely to be misinterpreted. We'll just specify in the documentation that this key takes precedence over layers, I don't think that logic would be surprising.

One nice thing about a separate key is that if you wanted to toggle between a specific layer/layers and "all", you could just toggle the value of "all_layers" and wouldn't have to remember which specific layers you'd specified previously.

On Apr 16, 2019, at 10:44 AM, Matt Blair<EMAIL_ADDRESS>wrote:
If we really wanted to make the options mutually exclusive we could do something like layers: true, but that seems even more opaque than '*' or _ 😀
My favorite option is a separate key like all_layers - I think it's the least likely to be misinterpreted. We'll just specify in the documentation that this key takes precedence over layers, I don't think that logic would be surprising.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

all_layers: true it is! I'll update this branch.

Updated the branch and description to reflect the syntax described here. When all_layers: true AND layer are both specified, all_layers: true takes precedence, and a warning is logged. Note that I didn't treat other values of all_layers (e.g. all_layers: false) as a conflict, and allowed layer to be used in these cases (to @meetar's point), but this is also up for interpretation as to correct behavior.


WIP Mark process as executing remotexact

I have made the changes to mark the xact as remote. I still need to mark the validation requests as remote since they might also lead to deadlock.
@ctring Would like your input on the appropriate location to add a similar change for validation requests.

for validation request, you can do this at the beginning of the validate_and_apply_xact function.


Doc: Sample app deployment

Nodejs sample app deployment guide can be found here: Nodejs sample app guide
Anyone can access pre-deployed sample applications in here Experience Devtron demo here


⚠ Bofrost.at has degraded performance

In 328f665, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1269 ms

Resolved: Bofrost.at performance has improved in ba07fa4 after 13 minutes.


Module runs but output cannot be saved

Slicer version: 4.11.0-2019-12-02 r28659
OS: Ubuntu 16.04
Error message
cannot write ImageData, it's NULL

Could you share the input data you are using?

Yikes, I do not even remember what the problem was here. Closing for now.


Add last_replied_at column to threads table

@Gummibeer I'd be grateful for your input again :)
I know you mentioned the BC nature of this change and I'm considering a major version bump to 5.0 for that reason. If I do that, I might as well take advantage of the opportunity and do the following as well:

Go through all of the code to take full advantage of PHP 7 (e.g. add return types)
Require a minimum PHP version of 7.0.0
Change the category schema to something more appropriate for tree data (e.g. nested set or materialised path)

I can give the frontend a similar treatment (I'm actually already in the process of giving it a new Bootstrap 4 look).
What do you think?

I agree that a new major version should be planned and used wisely.
So if you have open issues that require a new major version I would also use the chance and solve them.
An idea: go to php7.1 - nullable return types are sometimes important. In php7.0 you will have to don't typehint them.

OK, great. Thanks!


chore: Update icon delivery destination repository

The destination repository for icons delivery in the GitHub workflow has been changed. Previously, icons were being delivered to the "spark" repository. Now, they will be delivered to the "polaris-web-icons" repository.

☝ this message is made by [Jetbrains-AI](https://www.jetbrains.com/ai/)


Add list command with new filter syntax

list {TYPE} [FILTER...] [ {group} {GROUPTYPE} ...]
https://musicpd.org/doc/protocol/filter_syntax.html
"list Title Artist "Otep" Album "KULT 45""

MPD 0.21 released
https://www.musicpd.org/news/2018/10/mpd-0-21-released/
Filter syntax:
https://www.musicpd.org/doc/html/protocol.html#filters

MPD 0.21 will be available in Ubuntu 19.04


You're using user passwords are the stream URL?

Why are users hashed passwords being used as the stream /livep?= parameter?

Wrong repo, sorry.


Default permissions & access > Build and Release incorrectly says Stakeholders can view build pipelines

On the site Default permissions & access for the platform TFS 2018 the section Build and Release incorrectly says that stakeholders can view build pipelines.
This problem was already fixed for the platform Azure DevOps Services in #2091, but it is still incorrect for all the other platforms.
It was fixed in https://github.com/MicrosoftDocs/vsts-docs/blob/master/docs/organizations/security/_shared/pipelines.md, but not in https://github.com/MicrosoftDocs/vsts-docs/blob/master/docs/organizations/security/_shared/build-release.md.

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

ID: a35602ee-9d11-9746-4b79-075e295a5fb8
Version Independent ID: dbea8e30-e80b-8f13-987e-ef0ad3ba9b83
Content: Default permissions and access quick reference - Azure DevOps
Content Source: docs/organizations/security/permissions-access.md
Product: devops
Technology: devops-security
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@riQQ - Thank you for the feedback. I've added to our backlog to update the topic.

Fixed in 8465c01cc4178bf09e596a3e1e1ab0813cf1b384


[Vue] On SPAs, iframe will not resize

https://user-images.githubusercontent.com/44930252/214247660-45008532-88ab-407b-92a8-8b01376b4d29.mov
Step to reproduce:

Visit https://blog.k1yoshi.com/posts/sample, scroll to bottom and iframe will render correctly
Go to other pages using SPA's routes
Come back to the page and scroll to the bottom

Can you please provide a repository where the issue can be reproduced? I noticed this seems to be an issue with Vue supplying a wrong host prop instead of leaving it empty, but I cannot reproduce it.

Can you please provide a repository where the issue can be reproduced? I noticed this seems to be an issue with Vue supplying a wrong host prop instead of leaving it empty, but I cannot reproduce it.

Check pages/posts/[...slug].vue in this repo.

The problem does get resolved after adopting the workaround provided in #1002. I will close this issue and watch on that problem instead. Thanks!


add iozone fileop to standard build.

Signed-off-by: Ronald G. Minnich<EMAIL_ADDRESS>

LGTM

needs a rebase

update branch.


Update respond-machine-alerts.md

Added Microsoft defender for business as I can confirm that endpoint detection and response (behavior-based detection and manual response actions) is available.

Issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/7969

@JohanFreelancer9 Please copy review

@mjcaparas Please merge this PR. Thanks


CAMEL-12572: Upgrade jaxb to <IP_ADDRESS>

https://issues.apache.org/jira/browse/CAMEL-12572

Yes, probably it would be better

Maybe we can go ahead with merging the PR and centralized jaxb version property

Thanks merged!


“Multimodal deep learning with DocArray” There are many errors on the page

Initial Checks

[X] I have read and followed the docs and still think this is a bug

Description
I couldn't find anywhere else to report document errors.
https://docs.docarray.org/how_to/multimodal_training_and_serving/
Defined
class PairTextImage(BaseDoc):
    text: TextDoc
    image: ImageDoc

and then use it
  da = DocList[PairTextImage](
        PairTextImage(text=Text(text=i.caption), image=Image(url=f"Images/{i.image}"))
        for i in df.itertuples()
    )

actually the Image class is not defined.
   def __call__(self, text: Text) -> None:
        assert isinstance(text, Text)
        text.tokens = Tokens(
            **self.tokenizer(
                text.text, padding="max_length", truncation=True, max_length=48
            )

and the Text class is not defined.
Example Code
No response
Python, DocArray & OS Version
I couldn't find anywhere else to report document errors

Affected Components

[ ] Vector Database / Index
[ ] Representing
[ ] Sending
[ ] storing
[X] multi modal data type

from docarray.data import MultiModalDataset

dataset = MultiModalDataset[PairTextImage](da=da, preprocessing=preprocessing)
loader = DataLoader(
    dataset,
    batch_size=128,
    collate_fn=dataset.collate_fn,
    shuffle=True,
    num_workers=4,
    multiprocessing_context="fork",
)

The parameter in this section is wrong, there is no da parameter. TypeError: MultiModalDataset.__init__() got an unexpected keyword argument 'da'

It seems is docs thr parameter and not da. Would u be able to do a PR correcting the documentation?


[18.03] backport updates to tests, and fix empty LogPath with non-blocking logging mode

Backports for 18.03 of:

https://github.com/moby/moby/pull/36292 Migrate volumes tests in integration-cli to api tests
https://github.com/moby/moby/pull/36293 Migrate several docker rm tests to api tests
https://github.com/moby/moby/pull/36384 Update docker-py This fix update docker-py so that containers from the tests run could be cleaned up during teardown
https://github.com/moby/moby/pull/36387 Clean the teardown process of network test
https://github.com/moby/moby/pull/36393 Move containerIsStopped/containerIsInState to integration/internal/container
https://github.com/moby/moby/pull/36406 Migrate some config secret tests to api test
https://github.com/moby/moby/pull/36272 Fix empty LogPath with non-blocking logging mode
https://github.com/moby/moby/pull/36429 Clean up a temp dir created in container unit test
https://github.com/moby/moby/pull/36430 Migrate config inspect test to api test
https://github.com/moby/moby/pull/36444 Migrate events tests to api tests
https://github.com/moby/moby/pull/36445 Remove docker_cli_secret_inspect_test.go
https://github.com/moby/moby/pull/36450 Enhancement of replacing ContainerCreate with helper funcs in tests
https://github.com/moby/moby/pull/36455 Fix "expected" and "actual" being reversed
https://github.com/moby/moby/pull/36459 Migrate export tests to api tests
https://github.com/moby/moby/pull/36468 Fixes some integration/container tests to run on remote daemon
https://github.com/moby/moby/pull/36471 Improvement in integration tests
https://github.com/moby/moby/pull/36474 Migrate docker rm tests to api tests
https://github.com/moby/moby/pull/36476 Remove unnecessary container.WithName in kill test
https://github.com/moby/moby/pull/36490 Address expected vs actual in integration tests
https://github.com/moby/moby/pull/36493 Adds a unit test for plugin request timeout
https://github.com/moby/moby/pull/36502 Remove duplicate TestServiceUpdatePort
https://github.com/moby/moby/pull/36550 Remove unnecessary diff tests
https://github.com/moby/moby/pull/36569 TestLinksEtcHostsContentMatch: use container.Exec()
https://github.com/moby/moby/pull/36584 Add some tests to the volume store

This PR also contains a fix; I think it would be ok to include that

https://github.com/moby/moby/pull/36272 Fix empty LogPath with non-blocking logging mode

After this is merged, https://github.com/docker/docker-ce/pull/468 should be rebased; after that one is merged, there's more changes to the tests we can backport, including the "big one"; https://github.com/moby/moby/pull/36507 Replace testify/assert with gotestyourself/assert

This PR overlaps with https://github.com/docker/docker-ce/pull/512 and https://github.com/docker/docker-ce/pull/510, so we can probably close those. Opened as a separate PR for now to discuss and see if all tests go green

Not entirely sure what the failure is in s390x; could it be that there's no more tests in that suite for s390x? https://jenkins.dockerproject.org/job/docker-ce-pr-s390x/549/execution/node/621/log/
01:36:52 + make -f Makefile-docker-ce-pr log-DockerAuthzV2Suite.tgz
01:36:52 Makefile-docker-ce-pr:6: warning: overriding recipe for target 'docker-ce'
01:36:52 Makefile-docker-ce:29: warning: ignoring old recipe for target 'docker-ce'
01:36:52 docker run --rm -v /home/ubuntu/workspace/docker-ce-pr-s390x:/v -w /v busybox chown -R 1000:1000 bundles
01:36:53 find bundles -name '*.log' -o -name '*.prof' -o -name integration.test | xargs tar -czf log-DockerAuthzV2Suite.tgz
01:36:53 tar: Cowardly refusing to create an empty archive
01:36:53 Try 'tar --help' or 'tar --usage' for more information.
01:36:53 Makefile-docker-ce:67: recipe for target 'log-DockerAuthzV2Suite.tgz' failed
01:36:53 make: *** [log-DockerAuthzV2Suite.tgz] Error 123

I think the error is with getting the image to run the tests:
docker run --rm --privileged --name jenkins-docker-ce-pr-s390x-549-0-a0b317 \
	-v "/home/ubuntu/workspace/docker-ce-pr-s390x/bundles:/go/src/github.com/docker/docker/bundles" \
	-v "/home/ubuntu/workspace/docker-ce-pr-s390x/docker-ce/components/cli/build:/usr/local/cli" \
	-e DOCKER_CLI_PATH=docker \
	-e DOCKER_GITCOMMIT=a3540962fd234faa30385d5f6ef3a96c61610ccd \
	-e TESTFLAGS='-check.f DockerAuthzV2Suite.*' \
	-e KEEPBUNDLE=1 \
	dockerbuildbot/docker@sha256:a19c21e8f86a9c1345789a72436cde7189a524c52f3ebbc6e3b0b0087845d605 hack/make.sh test-integration-cli
Unable to find image 'dockerbuildbot/docker@sha256:a19c21e8f86a9c1345789a72436cde7189a524c52f3ebbc6e3b0b0087845d605' locally
docker: Error response from daemon: Get https://registry-1.docker.io/v2/dockerbuildbot/docker/manifests/sha256:a19c21e8f86a9c1345789a72436cde7189a524c52f3ebbc6e3b0b0087845d605: EOF.

Kicking build again.

I think that flakiness  should be fixed by https://github.com/moby/moby/pull/36511, but I see it needs a rebase


Calculate changelist based on {changelist, resourcelist, updated files on local disk}

instead of calculating the changelist based on the entire set of files on local disk, this method receives the current situation from the resourceList and changeList and only the new/updated files. It calculates a new changeList to replace the current changeList


Support VS2019 and toolchain v142

Created a new solution for VS2019 and a bunch of new projects for toolchain v142

You'll need to update \Utilities\CMake cause we use CMake to ensure all the vcxprojs are updated.  I can show you how that system works

Messed up my repo so abandoning this and starting a new, better PR


Fallback justfile stabilization tracking issue

This is a tracking issue for stabilizing the currently unstable feature which allows just to check justfiles in parent directories if a recipe is missing from the first justfile it finds.
The feature is currently unstable. Please comment with any feedback, suggestions, or if you like the feature and think it's ready for stabilization.
Update 2022-10-19
Looks like this is getting stabilized, with a change to behavior. The change is that fallback through a justfile in which a recipe is not found will only occur if the justfile contains set fallback or set fallback := true.
Stabilization timeline:

2022-10-19 - The unstable version with the new behavior is released in just 1.6.0
2022-10-26 - Released just 1.7.0 with the setting defaulting to true
2022-11-25 - Release just 1.9.0 with the setting defaulting to false
2023-1-1 - Stabilize the new feature, barring any issues

Please try out the new setting-based fallback in just 1.6.0 and let me know if you have any issues. Also, regardless of issues, let me know if it works or doesn't work for your use case.

Hey!
I just started exploring that feature and it's great, thanks for adding it!
Are you planning to include also fallback of variables between parent/child justfiles?
In the current setup, I have some 'global variables' defined in the main justfile that I am using in a command. Now, if I want to overwrite that command via child justfile, I also need to redefine all of the variables, there is no fallback for them.
The same issue is with using just settings such as set shell that require to be defined both in the parent and child justfiles.
I guess that might not be exactly what this issue is about. Probably a better implementation would not be rather an explicit import to force just to get all settings and vars from the parent.

I just started exploring that feature and it's great, thanks for adding it!

Are you planning to include also fallback of variables between parent/child justfiles?

I don't think so. This feature is a simple stopgap to make it easier to work with multi-justfile repositories. For something where recipes and variables from multiple justfiles in the same invocation, have a look at #929. There's no active work on that at the moment, but some day!

I wanted this and then discovered that it was already available! I'm planning to use it to have a justfile in ~ with general shell shortcuts.
The question I have about the current implementation is about tab completion. This seems like it would become even more important with an increased number of recipes. Presently, it looks like tab completion only works with recipes in the first justfile found. I wonder what the right solution is:

Keep the current behavior.
Tab complete shows recipes from all found justfiles.
Tab complete only shows recipes from from the justfile in which it found the first match.

I can't decide if 2 would be too much. Possibly it could get confusing, since two different files could contain multiple receipes with the same name. The issue with 3 is that the tab completions could appear to change as you changed the initial string.
I'm not really loving the first behavior, tho. Now that I've turned on tab completion, I find myself relying on it for nearly every invocation. If I can't use it for the upper-level justfiles, that would make me less likely to use them.

I think #2 would be fine in the majority of cases but if someone with god like completion building skills could potentially list completions that aren't for the active Justfile under those that are. Possibly with some sort of delimiter. I'm pretty sure you can do anything you could possibly want with Zsh. It's incredibly sophisticated and harder to learn than C++.  And I suspect other newer shells like Fish, Nu or PowerShell can likely handle it.
But I think that ultimately if submodules become a reality that at the very least completions should take submodules into consideration.

Interesting situation brought up in the Discord channel while might affect this feature:

I'm trying to write my justfiles so basic commands like build, run etc. automatically work on Windows and Linux, even when those commands do different things on each OS.
I'm currently doing this - it works but is this an idiomatic way to do it?

build:
    just build-{{ os_family() }}

build-unix:
    # unix build command goes here

build-windows:
    # windows build command goes here

When this feature is implemented, that call to just in the build recipe might not find the same justfile. I think a solution to this would be to make calls to just itself from within a justfile always act as if the call was actually just -f {{ justfile() }}.

I think it would be best that if there are conflicts Just exists with an error explaining the shadowing issue. Then the user would be aware of the issue and could fix it as they see fit. Maybe Just could provide suggestions for common situations as time goes on as well.

Hello Everyone, i just started looking into just because we want it to replace a custom build tool.
right now just --unstable -l just return the tasks in the nearest justfile. it would be nice if it would merge the tasks of al the justfile in the path, showing an error/warning mentioning the shadowing like @runeimp says.

This has been unstable for a while, and no complaints so far. @52f73db mentioned that he was using it in #1148, and it seems like it might be time to stabilize it. One concern I have is that this is a change in behavior. If a user is relying on getting an error in a sub-justfile, they might be surprised when the recipe runs in the parent.

Could make it a setting to enable it. We're adopting Just now and using this feature as fundamental. Had to create an alias just so everyone doesn't have to add --unstable

Could make it a setting to enable it. We're adopting Just now and using this feature as fundamental. Had to create an alias just so everyone doesn't have to add --unstable

Great idea! I think that's better than stabilizing it as-is, since falling back to parent justfiles could be undesirable if you aren't expecting it. Also, if you plan on using fallback, you can omit the setting in the root justfile in your repository, and just will stop there instead of ascending to /.
I implemented it in this PR, have a look: https://github.com/casey/just/pull/1368
This would temporarily make things worse for your use-case, since you would have to add set fallback to your justfiles, in addition to using --unstable temporarily, since I'd like to give it a month or so with the setting to get feedback. But, assuming that feedback is good, this could be stabilized next release after that:

day N: release version which requires set fallback and --unstable
day N + 30: stabilize

How does that sound?

Forgot to @ @rberger

That's awesome idea in my opinion. We have a structure of monorepo where we have per-project justfile as well as a main, repository wide justfile and falling back even further up than the monorepo root is not desirable. Having it as a setting in each justfile solves that issue completely.

@soenkehahn What do you think of this? You would have to put set fallback in justfiles where you wanted fallback, but it would feel much safer to stabilize, because the concern about getting unexpected behavior is ameliorated.

Nobody complained, so I just released version 1.6.0, which has the new setting-controlled fallback behavior. It's still unstable, and barring any issues, I'll make it unstable in the next release in a month or so. Binaries should be available soon on the release page.
Try it out and let me know what you think!

Hey! Thanks for implementing that! One problem I stumbled on while implementing the switch.
❯ just --unstable build
error: Unknown setting `fallback`
  |
6 | set fallback := true
  |     ^^^^^^^^

The reason is obvious, I forgot to upgrade version of just on my machine. This leads to some complications however, I need to force everyone to upgrade their versions basically before I merge that commit. Otherwise, I will break workflow for literally everyone as well as for CI. The latter is obviously easier to deal with.
Is throwing an error an optimal solution for dealing with unknown settings in face of a super stability of just? It means that adoption of backward incompatible changes in justfiles is going to be very hard.
Wouldn't a warning and ignoring of unknown setting work out better? Obviously, it could lead to some unexpected behaviours but it wouldn't break stuff that heavily.

That's definitely annoying! However I don't think just can ignore a setting that it doesn't understand. A setting may do anything to the behavior of just, so running a justfile without some setting that the user intended it to be used with might do something undesirable, so I think seeing an unknown setting has to be a hard error.
In this case though, there is something that could be done to make this transaction less painful:

Release a version of just where fallaback defaults to true when --unstable is passed
Wait a while
Change the default to false, and have --unstable still be required
Wait a while
Stabilize the feature so that --unstable isn't required

This would allow you to wait for the everyone to update to the new version where true was the default, then add the setting, and then wait for the default to change, and for it to be stabilized. You would see a change in behavior when the default changed to false, but that would be minor.
However, this would be at the expense of having to wait a longer time for the feature to be stabilized, since I wouldn't want to stabilize it at the same time that the default changes.
How hard is it to ensure that everyone has upgraded to the new version of just? Also if anyone else is having this problem, definitely chime in.
As you said, this is an unstable feature, so breaking changes are to be expected. However, there's no reason not to try to minimize how annoying they are.

I think it won't be that hard to ensure everyone to use just. The only prerequisite is to be sure that the new version is available via brew so people have a familiar way of obtaining it.
I think your proposed solution will work, definitely it will ease the transition. It would be great if you could walk this release path.
And regarding ignoring unknown settings - how about introducing a switch that would allow for unknown settings to be present in a justfile? Kind of a double edged sword but could help with making transition smoother.

I think your proposed solution will work, definitely it will ease the transition. It would be great if you could walk this release path.

Done! I just released 1.7.0, which changes the new fallback setting to default to true. Binaries should be on the releases page soon.
Check the updated timeline above, and let me know if it's too fast or too slow.

Oh wow, that was fast! I think a month for each phase is plenty of time. Thank you!

I just released 1.9.0, which changes the fallback setting default to false. This should be the last step towards stabilizing this feature, i.e. making it work without the --unstable flag. Give it a shot! Barring any issues, I'll release a new version that stabilizes the feature around January 1st, 2023.

@casey did this stabilize in to 1.10.0 by any chance? Just gave it a shot and I think it still has 1.9.0 behavior.

@nyonson Nope, I didn't wasn't able to get it in, but just has no official release schedule, so I'll release 1.11 within a few days that stabilizes fallback.

It is done! I just published 1.11.0, with fallback stabilized. Prebuilt binaries should be up on the releases page soon. Thanks for waiting and providing feedback!


better collection fetch settings and fully integrated all filters and…

… time range server side calls

@DanielJMaher @oceanzus , refinement on server side filtering and added hand off TODOs for client side table triggering.