Build error on macOS with GCC

Expected Behavior
I want to build HPX on macOS with GCC 11, and its standard C++ library.
Actual Behavior
I see this error:
In file included from /var/folders/gb/x5lhfpj15ln66g6br549tz5m0000gn/T/eschnett/spack-stage/spack-stage-hpx-1.6.0-i7cpnv4wlp2wc7f6552qiatdkn4dhavv/spack-src/hpx/lcos/packaged_action.hpp:11,
                 from /var/folders/gb/x5lhfpj15ln66g6br549tz5m0000gn/T/eschnett/spack-stage/spack-stage-hpx-1.6.0-i7cpnv4wlp2wc7f6552qiatdkn4dhavv/spack-src/hpx/runtime/components/default_distribution_policy.hpp:20,
                 from /var/folders/gb/x5lhfpj15ln66g6br549tz5m0000gn/T/eschnett/spack-stage/spack-stage-hpx-1.6.0-i7cpnv4wlp2wc7f6552qiatdkn4dhavv/spack-src/hpx/runtime/components/new.hpp:18,
                 from /var/folders/gb/x5lhfpj15ln66g6br549tz5m0000gn/T/eschnett/spack-stage/spack-stage-hpx-1.6.0-i7cpnv4wlp2wc7f6552qiatdkn4dhavv/spack-src/libs/full/collectives/src/detail/communication_set_node.cpp:22:
/var/folders/gb/x5lhfpj15ln66g6br549tz5m0000gn/T/eschnett/spack-stage/spack-stage-hpx-1.6.0-i7cpnv4wlp2wc7f6552qiatdkn4dhavv/spack-src/libs/core/config/include/hpx/config/detail/compat_error_code.hpp: In destructor 'hpx::compat_error_code::~compat_error_code()':
/var/folders/gb/x5lhfpj15ln66g6br549tz5m0000gn/T/eschnett/spack-stage/spack-stage-hpx-1.6.0-i7cpnv4wlp2wc7f6552qiatdkn4dhavv/spack-src/libs/core/config/include/hpx/config/detail/compat_error_code.hpp:34:19: error: no match for 'operator=' (operand types are 'std::error_code' and 'boost::system::error_code')
   34 |             _ec = _compat;
      |                   ^~~~~~~

Steps to Reproduce the Problem
I installed GCC 11.1.0 on macOS 11.4 via Spack. Using this GCC I then want to install HPX.

spack install gcc
spack compiler find
spack install hpx networking=none %gcc

Specifications
... Please describe your environment

HPX Version: 1.6.0
Platform (compiler, OS): macOS 11.4, GCC 11.1.0

The complete build output from Spack is spack-build-out.txt

Thanks @eschnett for reporting this. This is definitely odd and should not happen. Two questions, though I don't know how far they'll get us:

Do you possibly have a system-installed boost lurking somewhere in addition to the one built by spack?
Does the same happen with master (or 1.7.0-rc3)?

To my knowledge there is no other Boost installation. I also explicitly set my path to exclude all the places where Macports or Homebrew would install something, and I didn't install anything manually.
There is on Spack version for 1.7.0rc3. Installing boost @master via Spack fails with
  >> 137    CMake Error at cmake/HPX_Message.cmake:51 (message):
     138      Could not find Asio.  Set ASIO_ROOT as a CMake or environment variable to
     139      point to the Asio root install directory.  Alternatively, set
     140      HPX_WITH_FETCH_ASIO=ON to fetch Asio using CMake's FetchContent (when using
     141      this option Asio will be installed together with HPX, be careful about
     142      conflicts with separately installed versions of Asio).
     143    Call Stack (most recent call first):

This seems like a problem with the Spack build recipe.
I added asio as dependency of hpx in Spack. This resolves the issue above, and continues to lead to this error:
FAILED: lib/libhpx_core.dylib
: && /Users/eschnett/src/CarpetX/spack/lib/spack/env/gcc/g++ -O2 -g -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -dynamiclib -Wl,-headerpad_max_install_names -pthread -o lib/libhpx_core.dylib -install_name @rpath/libhpx_core.dylib libs/core/affinity/CMakeFiles/hpx_affinity.dir/src/affinity_data.cpp.o libs/core/affinity/CMakeFiles/hpx_affinity.dir/src/parse_affinity_options.cpp.o libs/core/affinity/CMakeFiles/hpx_affinity.dir/src/config_entries.cpp.o libs/core/allocator_support/CMakeFiles/hpx_allocator_support.dir/src/config_entries.cpp.o libs/core/asio/CMakeFiles/hpx_asio.dir/src/asio_util.cpp.o libs/core/asio/CMakeFiles/hpx_asio.dir/src/map_hostnames.cpp.o libs/core/asio/CMakeFiles/hpx_asio.dir/src/config_entries.cpp.o libs/core/assertion/CMakeFiles/hpx_assertion.dir/src/assertion.cpp.o libs/core/assertion/CMakeFiles/hpx_assertion.dir/src/source_location.cpp.o libs/core/assertion/CMakeFiles/hpx_assertion.dir/src/config_entries.cpp.o libs/core/cache/CMakeFiles/hpx_cache.dir/src/config_entries.cpp.o libs/core/concepts/CMakeFiles/hpx_concepts.dir/src/config_entries.cpp.o libs/core/concurrency/CMakeFiles/hpx_concurrency.dir/src/barrier.cpp.o libs/core/concurrency/CMakeFiles/hpx_concurrency.dir/src/config_entries.cpp.o libs/core/config/CMakeFiles/hpx_config.dir/src/version.cpp.o libs/core/config/CMakeFiles/hpx_config.dir/src/config_entries.cpp.o libs/core/config_registry/CMakeFiles/hpx_config_registry.dir/src/config_registry.cpp.o libs/core/config_registry/CMakeFiles/hpx_config_registry.dir/src/config_entries.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/detail/context_base.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/detail/context_posix.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/detail/coroutine_impl.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/detail/coroutine_self.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/detail/posix_utility.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/detail/tss.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/swapcontext.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/thread_enums.cpp.o libs/core/coroutines/CMakeFiles/hpx_coroutines.dir/src/config_entries.cpp.o libs/core/datastructures/CMakeFiles/hpx_datastructures.dir/src/config_entries.cpp.o libs/core/debugging/CMakeFiles/hpx_debugging.dir/src/attach_debugger.cpp.o libs/core/debugging/CMakeFiles/hpx_debugging.dir/src/backtrace.cpp.o libs/core/debugging/CMakeFiles/hpx_debugging.dir/src/print.cpp.o libs/core/debugging/CMakeFiles/hpx_debugging.dir/src/config_entries.cpp.o libs/core/errors/CMakeFiles/hpx_errors.dir/src/error_code.cpp.o libs/core/errors/CMakeFiles/hpx_errors.dir/src/exception.cpp.o libs/core/errors/CMakeFiles/hpx_errors.dir/src/exception_list.cpp.o libs/core/errors/CMakeFiles/hpx_errors.dir/src/throw_exception.cpp.o libs/core/errors/CMakeFiles/hpx_errors.dir/src/config_entries.cpp.o libs/core/execution_base/CMakeFiles/hpx_execution_base.dir/src/agent_ref.cpp.o libs/core/execution_base/CMakeFiles/hpx_execution_base.dir/src/register_locks.cpp.o libs/core/execution_base/CMakeFiles/hpx_execution_base.dir/src/spinlock_deadlock_detection.cpp.o libs/core/execution_base/CMakeFiles/hpx_execution_base.dir/src/this_thread.cpp.o libs/core/execution_base/CMakeFiles/hpx_execution_base.dir/src/config_entries.cpp.o libs/core/filesystem/CMakeFiles/hpx_filesystem.dir/src/config_entries.cpp.o libs/core/format/CMakeFiles/hpx_format.dir/src/format.cpp.o libs/core/format/CMakeFiles/hpx_format.dir/src/util/bad_lexical_cast.cpp.o libs/core/format/CMakeFiles/hpx_format.dir/src/config_entries.cpp.o libs/core/functional/CMakeFiles/hpx_functional.dir/src/basic_function.cpp.o libs/core/functional/CMakeFiles/hpx_functional.dir/src/empty_function.cpp.o libs/core/functional/CMakeFiles/hpx_functional.dir/src/config_entries.cpp.o libs/core/hardware/CMakeFiles/hpx_hardware.dir/src/config_entries.cpp.o libs/core/hashing/CMakeFiles/hpx_hashing.dir/src/config_entries.cpp.o libs/core/ini/CMakeFiles/hpx_ini.dir/src/ini.cpp.o libs/core/ini/CMakeFiles/hpx_ini.dir/src/config_entries.cpp.o libs/core/io_service/CMakeFiles/hpx_io_service.dir/src/io_service_pool.cpp.o libs/core/io_service/CMakeFiles/hpx_io_service.dir/src/io_service_thread_pool.cpp.o libs/core/io_service/CMakeFiles/hpx_io_service.dir/src/config_entries.cpp.o libs/core/iterator_support/CMakeFiles/hpx_iterator_support.dir/src/config_entries.cpp.o libs/core/itt_notify/CMakeFiles/hpx_itt_notify.dir/src/itt_notify.cpp.o libs/core/itt_notify/CMakeFiles/hpx_itt_notify.dir/src/thread_name.cpp.o libs/core/itt_notify/CMakeFiles/hpx_itt_notify.dir/src/config_entries.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/level.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/logging.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/manipulator.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/format/named_write.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/format/destination/defaults_destination.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/format/destination/file.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/format/formatter/high_precision_time.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/format/formatter/defaults_formatter.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/format/formatter/thread_id.cpp.o libs/core/logging/CMakeFiles/hpx_logging.dir/src/config_entries.cpp.o libs/core/memory/CMakeFiles/hpx_memory.dir/src/config_entries.cpp.o libs/core/plugin/CMakeFiles/hpx_plugin.dir/src/config_entries.cpp.o libs/core/prefix/CMakeFiles/hpx_prefix.dir/src/find_prefix.cpp.o libs/core/prefix/CMakeFiles/hpx_prefix.dir/src/config_entries.cpp.o libs/core/preprocessor/CMakeFiles/hpx_preprocessor.dir/src/config_entries.cpp.o libs/core/properties/CMakeFiles/hpx_properties.dir/src/config_entries.cpp.o libs/core/schedulers/CMakeFiles/hpx_schedulers.dir/src/deadlock_detection.cpp.o libs/core/schedulers/CMakeFiles/hpx_schedulers.dir/src/maintain_queue_wait_times.cpp.o libs/core/schedulers/CMakeFiles/hpx_schedulers.dir/src/config_entries.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/detail/pointer.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/detail/polymorphic_id_factory.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/detail/polymorphic_intrusive_factory.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/detail/polymorphic_nonintrusive_factory.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/exception_ptr.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/serializable_any.cpp.o libs/core/serialization/CMakeFiles/hpx_serialization.dir/src/config_entries.cpp.o libs/core/static_reinit/CMakeFiles/hpx_static_reinit.dir/src/static_reinit.cpp.o libs/core/static_reinit/CMakeFiles/hpx_static_reinit.dir/src/config_entries.cpp.o libs/core/statistics/CMakeFiles/hpx_statistics.dir/src/config_entries.cpp.o libs/core/string_util/CMakeFiles/hpx_string_util.dir/src/config_entries.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/detail/condition_variable.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/detail/counting_semaphore.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/detail/sliding_semaphore.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/local_barrier.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/mutex.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/stop_token.cpp.o libs/core/synchronization/CMakeFiles/hpx_synchronization.dir/src/config_entries.cpp.o libs/core/testing/CMakeFiles/hpx_testing.dir/src/testing.cpp.o libs/core/testing/CMakeFiles/hpx_testing.dir/src/performance.cpp.o libs/core/testing/CMakeFiles/hpx_testing.dir/src/config_entries.cpp.o libs/core/thread_pools/CMakeFiles/hpx_thread_pools.dir/src/scheduled_thread_pool.cpp.o libs/core/thread_pools/CMakeFiles/hpx_thread_pools.dir/src/config_entries.cpp.o libs/core/thread_support/CMakeFiles/hpx_thread_support.dir/src/set_thread_name.cpp.o libs/core/thread_support/CMakeFiles/hpx_thread_support.dir/src/spinlock.cpp.o libs/core/thread_support/CMakeFiles/hpx_thread_support.dir/src/config_entries.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/annotated_function.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/execution_agent.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/external_timer.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/print.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/register_thread.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/scheduler_base.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_data.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_data_stackful.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_data_stackless.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_description.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_helpers.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_num_tss.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/thread_pool_base.cpp.o libs/core/threading_base/CMakeFiles/hpx_threading_base.dir/src/config_entries.cpp.o libs/core/timing/CMakeFiles/hpx_timing.dir/src/config_entries.cpp.o libs/core/topology/CMakeFiles/hpx_topology.dir/src/cpu_mask.cpp.o libs/core/topology/CMakeFiles/hpx_topology.dir/src/topology.cpp.o libs/core/topology/CMakeFiles/hpx_topology.dir/src/config_entries.cpp.o libs/core/type_support/CMakeFiles/hpx_type_support.dir/src/config_entries.cpp.o libs/core/util/CMakeFiles/hpx_util.dir/src/manage_config.cpp.o libs/core/util/CMakeFiles/hpx_util.dir/src/regex_from_pattern.cpp.o libs/core/util/CMakeFiles/hpx_util.dir/src/sed_transform.cpp.o libs/core/util/CMakeFiles/hpx_util.dir/src/config_entries.cpp.o libs/core/version/CMakeFiles/hpx_version.dir/src/version.cpp.o libs/core/version/CMakeFiles/hpx_version.dir/src/config_entries.cpp.o libs/CMakeFiles/hpx_core.dir/src/dummy.cpp.o  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/gperftools-2.8.1-fojpdefuvg3wy5h6srfx62mhbhn6akxk/lib/libtcmalloc_minimal.dylib  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/boost-1.76.0-aagkpddcnl7vqkjqzs5anbxs2xuhuvqn/lib/libboost_context-mt.dylib  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/boost-1.76.0-aagkpddcnl7vqkjqzs5anbxs2xuhuvqn/lib/libboost_thread-mt.dylib  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/boost-1.76.0-aagkpddcnl7vqkjqzs5anbxs2xuhuvqn/lib/libboost_date_time-mt.dylib  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/boost-1.76.0-aagkpddcnl7vqkjqzs5anbxs2xuhuvqn/lib/libboost_atomic-mt.dylib  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/boost-1.76.0-aagkpddcnl7vqkjqzs5anbxs2xuhuvqn/lib/libboost_chrono-mt.dylib  /Users/eschnett/src/CarpetX/spack/opt/spack/darwin-bigsur-skylake/gcc-11.1.0/hwloc-2.5.0-fdhuxgmzrrihnqfemkfgsnfvis6opoam/lib/libhwloc.dylib  -latomic  -ldl && :
Undefined symbols for architecture x86_64:
  "_jump_fcontext", referenced from:
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE6invokeEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE5yieldEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE9do_returnENS5_19context_exit_statusEONSt15__exception_ptr13exception_ptrE in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE8do_yieldEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE9do_invokeEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail23coroutine_stackful_self10yield_implESt4pairINS0_21thread_schedule_stateENS0_9thread_idEE in coroutine_impl.cpp.o
      __ZN3hpx7threads10coroutines6detail14coroutine_implclEv in coroutine_impl.cpp.o
      ...
  "_make_fcontext", referenced from:
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE6invokeEv in context_base.cpp.o
      __ZN3hpx7threads11thread_dataclEPNS_14execution_base11this_thread6detail13agent_storageE in scheduled_thread_pool.cpp.o
      __ZN3hpx7threads20thread_data_stackful6rebindERNS0_16thread_init_dataE in thread_data_stackful.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

This is the complete build output.

Ah, yes, sorry about Asio. We haven't added the dependency yet to the recipe since 1.7.0 isn't out yet, but you've done exactly what we would do in a few days.
@albestro would you mind if I drag you into this since you're a mac user?

To clarify: I can build hpx fine on macOS when I just say spack install hpx. This uses Apple's Clang compiler. However, I want to use GCC for various reasons (openMP, Fortran, consistency with other platforms), and this fails.

Ah, yes, sorry about Asio. We haven't added the dependency yet to the recipe since 1.7.0 isn't out yet, but you've done exactly what we would do in a few days.
@albestro would you mind if I drag you into this since you're a mac user?

I never tried to build it with GCC, but always with apple-clang. However, I'm trying to build with GCC 10.2.0 and I'll let you know as soon as it completes. 😉

@eschnett, @albestro and I did a little investigation yesterday and found the following:

Boost.System defines a compatibility layer between boost::system::error_code and std::error_code for conversions in both directions
The compatibility layer is enabled if the Boost configuration decides that the standard library supports system_error
system_error is not supported if the system_error header is not available
system_error is also not supported if the mutex header is not "available" (it uses a mutex internally to protect a static map which maps Boost error codes to standard error codes)
Boost decides in the case of GCC/libstdc++ on macOS that mutex is not available because timed locks aren't available in the standard library (_GTHREAD_USE_MUTEX_TIMEDLOCK is undefined or 0, https://github.com/boostorg/config/blob/c3de80c2efa69c10dcad7c7ffa37047c3d4cf49e/include/boost/config/stdlib/libstdcpp3.hpp#L428-L431)
I think that libstdc++ decides that it doesn't have timed locks because _POSIX_TIMEOUTS is undefined (https://github.com/gcc-mirror/gcc/blob/42f10ba5b57250506d69a0391ea7771c843ea286/libgcc/gthr-posix.h#L40-L44)

In conclusion, this is at its heart a Boost problem (Boost.System could be more relaxed about detecting system_error since it doesn't need timed locks, only a plain mutex) or a libstdc++ problem (I have no idea why libstdc++ doesn't support timed locks, or if it's even feasible that it does). I recommend you report these issues upstream.
That said, there's hope. I think since the move to the standalone Asio we at least don't have any direct mentions of boost::system::error_code. I'm not 100% sure that this means that we don't rely on conversions from boost::system::error_code to std::error_code anymore but I'll give it a try to remove the compatibility layer and report back. @K-ballo do you happen to know offhand already if there might be some place in HPX that relies on the conversion?

Just to add, it even looks like at least later libstdc++s have a fallback timed_mutex even if _GTHREAD_USE_MUTEX_TIMEDLOCK isn't available so in that sense the check in Boost is too strict. I haven't yet checked if earlier libstdc++s didn't have a fallback.

One more update: It looks like the compatibility layer in Boost.System has been updated to not rely on mutex anymore, but just atomics (https://github.com/boostorg/system/commit/04bfb05b19c0f74edec7130454b46a7477a45600#diff-57b157d243f7c35362708577bf488af3a1f67c433c926d93438ccca5ca3d108e). This should (intentionally or unintentionally) fix the problem. Boost 1.77 is now in a release candidate and I think the change will be there. I suppose if you're impatient you could try the release candidate with spack to see if it fixes the problem, or otherwise simply wait for 1.77 to be officially released. I'll in any case still try removing the compatibility layer in HPX.

And finally, we can't get rid of our compatibility layer for error codes yet, because it's required for the filesystem compatibility layer, which uses Boost.Filesystem. However, we'll require C++17 after 1.7.0 which gives us std::filesystem. I've heard from others about issues with std::filesystem on macOS, but I don't know the details and we may be ok with the subset that we use. We'll have to investigate this after the release.
Now you still have the build error with master, which I don't have an answer to at the moment. It's most likely a bug in how we decide to enable or disable various coroutine implementations. In the meantime, could you provide the output of $CXX -dM -E - < /dev/null in a spack build environment (spack build-env <hpx-spec> -- <above command>). That might help tell us where we're going wrong with the detection.

I'm currently trying to build with boost @develop; so far without success.
This is the requested output:
$ spack --env-dir utils/spack/redshift build-env hpx -- gcc -dM -E - < /dev/null | sort
#define _LP64 1
#define __APPLE_CC__ 1
#define __APPLE__ 1
#define __ATOMIC_ACQUIRE 2
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_CONSUME 1
#define __ATOMIC_HLE_ACQUIRE 65536
#define __ATOMIC_HLE_RELEASE 131072
#define __ATOMIC_RELAXED 0
#define __ATOMIC_RELEASE 3
#define __ATOMIC_SEQ_CST 5
#define __BIGGEST_ALIGNMENT__ 16
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __CHAR16_TYPE__ short unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __CHAR_BIT__ 8
#define __CONSTANT_CFSTRINGS__ 1
#define __DBL_DECIMAL_DIG__ 17
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544176568792868221372e-324L)
#define __DBL_DIG__ 15
#define __DBL_EPSILON__ ((double)2.22044604925031308084726333618164062e-16L)
#define __DBL_HAS_DENORM__ 1
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __DBL_IS_IEC_60559__ 2
#define __DBL_MANT_DIG__ 53
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX_EXP__ 1024
#define __DBL_MAX__ ((double)1.79769313486231570814527423731704357e+308L)
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MIN_EXP__ (-1021)
#define __DBL_MIN__ ((double)2.22507385850720138309023271733240406e-308L)
#define __DBL_NORM_MAX__ ((double)1.79769313486231570814527423731704357e+308L)
#define __DECIMAL_DIG__ 21
#define __DEC_EVAL_METHOD__ 2
#define __DYNAMIC__ 1
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 110400
#define __FINITE_MATH_ONLY__ 0
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLT128_DECIMAL_DIG__ 36
#define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128
#define __FLT128_DIG__ 33
#define __FLT128_EPSILON__ 1.92592994438723585305597794258492732e-34F128
#define __FLT128_HAS_DENORM__ 1
#define __FLT128_HAS_INFINITY__ 1
#define __FLT128_HAS_QUIET_NAN__ 1
#define __FLT128_IS_IEC_60559__ 2
#define __FLT128_MANT_DIG__ 113
#define __FLT128_MAX_10_EXP__ 4932
#define __FLT128_MAX_EXP__ 16384
#define __FLT128_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT128_MIN_10_EXP__ (-4931)
#define __FLT128_MIN_EXP__ (-16381)
#define __FLT128_MIN__ 3.36210314311209350626267781732175260e-4932F128
#define __FLT128_NORM_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT32X_DECIMAL_DIG__ 17
#define __FLT32X_DENORM_MIN__ 4.94065645841246544176568792868221372e-324F32x
#define __FLT32X_DIG__ 15
#define __FLT32X_EPSILON__ 2.22044604925031308084726333618164062e-16F32x
#define __FLT32X_HAS_DENORM__ 1
#define __FLT32X_HAS_INFINITY__ 1
#define __FLT32X_HAS_QUIET_NAN__ 1
#define __FLT32X_IS_IEC_60559__ 2
#define __FLT32X_MANT_DIG__ 53
#define __FLT32X_MAX_10_EXP__ 308
#define __FLT32X_MAX_EXP__ 1024
#define __FLT32X_MAX__ 1.79769313486231570814527423731704357e+308F32x
#define __FLT32X_MIN_10_EXP__ (-307)
#define __FLT32X_MIN_EXP__ (-1021)
#define __FLT32X_MIN__ 2.22507385850720138309023271733240406e-308F32x
#define __FLT32X_NORM_MAX__ 1.79769313486231570814527423731704357e+308F32x
#define __FLT32_DECIMAL_DIG__ 9
#define __FLT32_DENORM_MIN__ 1.40129846432481707092372958328991613e-45F32
#define __FLT32_DIG__ 6
#define __FLT32_EPSILON__ 1.19209289550781250000000000000000000e-7F32
#define __FLT32_HAS_DENORM__ 1
#define __FLT32_HAS_INFINITY__ 1
#define __FLT32_HAS_QUIET_NAN__ 1
#define __FLT32_IS_IEC_60559__ 2
#define __FLT32_MANT_DIG__ 24
#define __FLT32_MAX_10_EXP__ 38
#define __FLT32_MAX_EXP__ 128
#define __FLT32_MAX__ 3.40282346638528859811704183484516925e+38F32
#define __FLT32_MIN_10_EXP__ (-37)
#define __FLT32_MIN_EXP__ (-125)
#define __FLT32_MIN__ 1.17549435082228750796873653722224568e-38F32
#define __FLT32_NORM_MAX__ 3.40282346638528859811704183484516925e+38F32
#define __FLT64X_DECIMAL_DIG__ 21
#define __FLT64X_DENORM_MIN__ 3.64519953188247460252840593361941982e-4951F64x
#define __FLT64X_DIG__ 18
#define __FLT64X_EPSILON__ 1.08420217248550443400745280086994171e-19F64x
#define __FLT64X_HAS_DENORM__ 1
#define __FLT64X_HAS_INFINITY__ 1
#define __FLT64X_HAS_QUIET_NAN__ 1
#define __FLT64X_IS_IEC_60559__ 2
#define __FLT64X_MANT_DIG__ 64
#define __FLT64X_MAX_10_EXP__ 4932
#define __FLT64X_MAX_EXP__ 16384
#define __FLT64X_MAX__ 1.18973149535723176502126385303097021e+4932F64x
#define __FLT64X_MIN_10_EXP__ (-4931)
#define __FLT64X_MIN_EXP__ (-16381)
#define __FLT64X_MIN__ 3.36210314311209350626267781732175260e-4932F64x
#define __FLT64X_NORM_MAX__ 1.18973149535723176502126385303097021e+4932F64x
#define __FLT64_DECIMAL_DIG__ 17
#define __FLT64_DENORM_MIN__ 4.94065645841246544176568792868221372e-324F64
#define __FLT64_DIG__ 15
#define __FLT64_EPSILON__ 2.22044604925031308084726333618164062e-16F64
#define __FLT64_HAS_DENORM__ 1
#define __FLT64_HAS_INFINITY__ 1
#define __FLT64_HAS_QUIET_NAN__ 1
#define __FLT64_IS_IEC_60559__ 2
#define __FLT64_MANT_DIG__ 53
#define __FLT64_MAX_10_EXP__ 308
#define __FLT64_MAX_EXP__ 1024
#define __FLT64_MAX__ 1.79769313486231570814527423731704357e+308F64
#define __FLT64_MIN_10_EXP__ (-307)
#define __FLT64_MIN_EXP__ (-1021)
#define __FLT64_MIN__ 2.22507385850720138309023271733240406e-308F64
#define __FLT64_NORM_MAX__ 1.79769313486231570814527423731704357e+308F64
#define __FLT_DECIMAL_DIG__ 9
#define __FLT_DENORM_MIN__ 1.40129846432481707092372958328991613e-45F
#define __FLT_DIG__ 6
#define __FLT_EPSILON__ 1.19209289550781250000000000000000000e-7F
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __FLT_EVAL_METHOD__ 0
#define __FLT_HAS_DENORM__ 1
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_IS_IEC_60559__ 2
#define __FLT_MANT_DIG__ 24
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX_EXP__ 128
#define __FLT_MAX__ 3.40282346638528859811704183484516925e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN_EXP__ (-125)
#define __FLT_MIN__ 1.17549435082228750796873653722224568e-38F
#define __FLT_NORM_MAX__ 3.40282346638528859811704183484516925e+38F
#define __FLT_RADIX__ 2
#define __FXSR__ 1
#define __GCC_ASM_FLAG_OUTPUTS__ 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_IEC_559 2
#define __GCC_IEC_559_COMPLEX 2
#define __GNUC_EXECUTION_CHARSET_NAME "UTF-8"
#define __GNUC_MINOR__ 1
#define __GNUC_PATCHLEVEL__ 0
#define __GNUC_STDC_INLINE__ 1
#define __GNUC_WIDE_EXECUTION_CHARSET_NAME "UTF-32LE"
#define __GNUC__ 11
#define __GXX_ABI_VERSION 1016
#define __HAVE_SPECULATION_SAFE_VALUE 1
#define __INT16_C(c) c
#define __INT16_MAX__ 0x7fff
#define __INT16_TYPE__ short int
#define __INT32_C(c) c
#define __INT32_MAX__ 0x7fffffff
#define __INT32_TYPE__ int
#define __INT64_C(c) c ## LL
#define __INT64_MAX__ 0x7fffffffffffffffLL
#define __INT64_TYPE__ long long int
#define __INT8_C(c) c
#define __INT8_MAX__ 0x7f
#define __INT8_TYPE__ signed char
#define __INTMAX_C(c) c ## L
#define __INTMAX_MAX__ 0x7fffffffffffffffL
#define __INTMAX_TYPE__ long int
#define __INTMAX_WIDTH__ 64
#define __INTPTR_MAX__ 0x7fffffffffffffffL
#define __INTPTR_TYPE__ long int
#define __INTPTR_WIDTH__ 64
#define __INT_FAST16_MAX__ 0x7fff
#define __INT_FAST16_TYPE__ short int
#define __INT_FAST16_WIDTH__ 16
#define __INT_FAST32_MAX__ 0x7fffffff
#define __INT_FAST32_TYPE__ int
#define __INT_FAST32_WIDTH__ 32
#define __INT_FAST64_MAX__ 0x7fffffffffffffffLL
#define __INT_FAST64_TYPE__ long long int
#define __INT_FAST64_WIDTH__ 64
#define __INT_FAST8_MAX__ 0x7f
#define __INT_FAST8_TYPE__ signed char
#define __INT_FAST8_WIDTH__ 8
#define __INT_LEAST16_MAX__ 0x7fff
#define __INT_LEAST16_TYPE__ short int
#define __INT_LEAST16_WIDTH__ 16
#define __INT_LEAST32_MAX__ 0x7fffffff
#define __INT_LEAST32_TYPE__ int
#define __INT_LEAST32_WIDTH__ 32
#define __INT_LEAST64_MAX__ 0x7fffffffffffffffLL
#define __INT_LEAST64_TYPE__ long long int
#define __INT_LEAST64_WIDTH__ 64
#define __INT_LEAST8_MAX__ 0x7f
#define __INT_LEAST8_TYPE__ signed char
#define __INT_LEAST8_WIDTH__ 8
#define __INT_MAX__ 0x7fffffff
#define __INT_WIDTH__ 32
#define __LDBL_DECIMAL_DIG__ 21
#define __LDBL_DENORM_MIN__ 3.64519953188247460252840593361941982e-4951L
#define __LDBL_DIG__ 18
#define __LDBL_EPSILON__ 1.08420217248550443400745280086994171e-19L
#define __LDBL_HAS_DENORM__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __LDBL_IS_IEC_60559__ 2
#define __LDBL_MANT_DIG__ 64
#define __LDBL_MAX_10_EXP__ 4932
#define __LDBL_MAX_EXP__ 16384
#define __LDBL_MAX__ 1.18973149535723176502126385303097021e+4932L
#define __LDBL_MIN_10_EXP__ (-4931)
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L
#define __LDBL_NORM_MAX__ 1.18973149535723176502126385303097021e+4932L
#define __LITTLE_ENDIAN__ 1
#define __LONG_LONG_MAX__ 0x7fffffffffffffffLL
#define __LONG_LONG_WIDTH__ 64
#define __LONG_MAX__ 0x7fffffffffffffffL
#define __LONG_WIDTH__ 64
#define __LP64__ 1
#define __MACH__ 1
#define __MMX_WITH_SSE__ 1
#define __MMX__ 1
#define __NO_INLINE__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412
#define __PIC__ 2
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __PTRDIFF_MAX__ 0x7fffffffffffffffL
#define __PTRDIFF_TYPE__ long int
#define __PTRDIFF_WIDTH__ 64
#define __REGISTER_PREFIX__
#define __SCHAR_MAX__ 0x7f
#define __SCHAR_WIDTH__ 8
#define __SEG_FS 1
#define __SEG_GS 1
#define __SHRT_MAX__ 0x7fff
#define __SHRT_WIDTH__ 16
#define __SIG_ATOMIC_MAX__ 0x7fffffff
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __SIG_ATOMIC_TYPE__ int
#define __SIG_ATOMIC_WIDTH__ 32
#define __SIZEOF_DOUBLE__ 8
#define __SIZEOF_FLOAT128__ 16
#define __SIZEOF_FLOAT80__ 16
#define __SIZEOF_FLOAT__ 4
#define __SIZEOF_INT128__ 16
#define __SIZEOF_INT__ 4
#define __SIZEOF_LONG_DOUBLE__ 16
#define __SIZEOF_LONG_LONG__ 8
#define __SIZEOF_LONG__ 8
#define __SIZEOF_POINTER__ 8
#define __SIZEOF_PTRDIFF_T__ 8
#define __SIZEOF_SHORT__ 2
#define __SIZEOF_SIZE_T__ 8
#define __SIZEOF_WCHAR_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __SIZE_MAX__ 0xffffffffffffffffUL
#define __SIZE_TYPE__ long unsigned int
#define __SIZE_WIDTH__ 64
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __STDC_HOSTED__ 1
#define __STDC_UTF_16__ 1
#define __STDC_UTF_32__ 1
#define __STDC_VERSION__ 201710L
#define __STDC__ 1
#define __UINT16_C(c) c
#define __UINT16_MAX__ 0xffff
#define __UINT16_TYPE__ short unsigned int
#define __UINT32_C(c) c ## U
#define __UINT32_MAX__ 0xffffffffU
#define __UINT32_TYPE__ unsigned int
#define __UINT64_C(c) c ## ULL
#define __UINT64_MAX__ 0xffffffffffffffffULL
#define __UINT64_TYPE__ long long unsigned int
#define __UINT8_C(c) c
#define __UINT8_MAX__ 0xff
#define __UINT8_TYPE__ unsigned char
#define __UINTMAX_C(c) c ## UL
#define __UINTMAX_MAX__ 0xffffffffffffffffUL
#define __UINTMAX_TYPE__ long unsigned int
#define __UINTPTR_MAX__ 0xffffffffffffffffUL
#define __UINTPTR_TYPE__ long unsigned int
#define __UINT_FAST16_MAX__ 0xffff
#define __UINT_FAST16_TYPE__ short unsigned int
#define __UINT_FAST32_MAX__ 0xffffffffU
#define __UINT_FAST32_TYPE__ unsigned int
#define __UINT_FAST64_MAX__ 0xffffffffffffffffULL
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __UINT_FAST8_MAX__ 0xff
#define __UINT_FAST8_TYPE__ unsigned char
#define __UINT_LEAST16_MAX__ 0xffff
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __UINT_LEAST32_MAX__ 0xffffffffU
#define __UINT_LEAST32_TYPE__ unsigned int
#define __UINT_LEAST64_MAX__ 0xffffffffffffffffULL
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __UINT_LEAST8_MAX__ 0xff
#define __UINT_LEAST8_TYPE__ unsigned char
#define __USER_LABEL_PREFIX__ _
#define __VERSION__ "11.1.0"
#define __WCHAR_MAX__ 0x7fffffff
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __WCHAR_TYPE__ int
#define __WCHAR_WIDTH__ 32
#define __WINT_MAX__ 0x7fffffff
#define __WINT_MIN__ (-__WINT_MAX__ - 1)
#define __WINT_TYPE__ int
#define __WINT_WIDTH__ 32
#define __amd64 1
#define __amd64__ 1
#define __code_model_small__ 1
#define __k8 1
#define __k8__ 1
#define __pic__ 2
#define __strong
#define __tune_core2__ 1
#define __weak
#define __x86_64 1
#define __x86_64__ 1

FYI: Building boost @develop with GCC gives errors like these:
  >> 921      libs/filesystem/src/path.cpp:1185:27: error: 'init_priority' attribute is not supported on this platform
     922       1185 | const path_locale_deleter g_path_locale_deleter = {};
     923            |                           ^~~~~~~~~~~~~~~~~~~~~

  >> 1052     ./boost/property_map/parallel/impl/distributed_property_map.ipp:14:10: fatal error: boost/bind.hpp: No such file or d
              irectory
     1053        14 | #include <boost/bind.hpp>
     1054           |          ^~~~~~~~~~~~~~~~

It seems the rabbit hole goes deep.
What I'm really looking for is a library that provides many efficient threads (sometimes called "thread pool"), together with a std::future like abstraction. (Because this is 2021, not the stone age.) HPX would be ideal; as alternative I'd consider using a low-level threading library (such as qthreads) and rolling my own. Any pointers would be appreciated. Maybe I'll just wait a month and see whether things improve on the Boost/macOS side.

It seems the rabbit hole goes deep.

Ugh, indeed.

What I'm really looking for is a library that provides many efficient threads (sometimes called "thread pool"), together with a std::future like abstraction. (Because this is 2021, not the stone age.) HPX would be ideal; as alternative I'd consider using a low-level threading library (such as qthreads) and rolling my own. Any pointers would be appreciated. Maybe I'll just wait a month and see whether things improve on the Boost/macOS side.

I'd give it another try once Boost 1.77 is officially released. Additionally, you might want to report that error to Boost. You're definitely in the right place if you're looking for lightweight threads. Unfortunately you're also using quite a niche configuration, which we don't really have the manpower to fully support. That said, the only way to improve things is to report problems, so I appreciate you doing that here. If you don't mind, I'd really appreciate if you could give it another try in a month or so and we can have a closer look at those undefined symbol errors if they're still a problem. In the meantime, apple clang is still an option which seems to be working at least reasonably well, but I understand that you may not want to go that route.

Reported as https://github.com/boostorg/filesystem/issues/199 and https://github.com/boostorg/property_map/issues/22 .

... and the first issue is fixed, the second is actually a problem in Spack.

Building hpx @master with boost @develop now reports this error:
Undefined symbols for architecture x86_64:
  "_jump_fcontext", referenced from:
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE6invokeEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE5yieldEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE9do_returnENS5_19context_exit_statusEONSt15__exception_ptr13exception_ptrE in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE8do_yieldEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE9do_invokeEv in context_base.cpp.o
      __ZN3hpx7threads10coroutines6detail23coroutine_stackful_self10yield_implESt4pairINS0_21thread_schedule_stateENS0_9thread_idEE in coroutine_impl.cpp.o
      __ZN3hpx7threads10coroutines6detail14coroutine_implclEv in coroutine_impl.cpp.o
      ...
  "_make_fcontext", referenced from:
      __ZN3hpx7threads10coroutines6detail12context_baseINS2_14coroutine_implEE6invokeEv in context_base.cpp.o
      __ZN3hpx7threads11thread_dataclEPNS_14execution_base11this_thread6detail13agent_storageE in scheduled_thread_pool.cpp.o
      __ZN3hpx7threads20thread_data_stackful6rebindERNS0_16thread_init_dataE in thread_data_stackful.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

The full output is in spack-build-out.txt. (Look for error:.)

I think that's another Boost thing. It doesn't know how to compile the assembler sources for the context library with GCC on macOS. The build log has
error: No best alternative for libs/context/build/asm_sources

You should also try this with the just released 1.77 beta (https://boostorg.jfrog.io/artifactory/main/beta/1.77.0.beta1/source/).

@pdimov It's difficult to build this release branch with Spack; there is no fetch recipe.
Since the development branch fails, I assume that the release branch is failing as well.

Use master - this is what the releases are built from, and at the moment it should be identical to the beta.

With the various patches to Boost, and with HPX 1.7.0, I can build and link with GCC on macOS. Thanks for all the help!
(This is with boost @develop.)

Thanks @eschnett, @pdimov, @albestro and anyone else who was involved for your patience and investigations. Nice to see this working!


Add end to end test for tracing message batch

Add any context about the cleanup here.

Closed by https://github.com/googleapis/google-cloud-cpp/pull/12995


billing: Fix css for popups on the billing page.

As of 9427fb72301c0674fdbfd75b1903e2c9d0966769, the billing page needs a proper value for --color-background-modal.
Before:

After:

Merged, thanks @mateuszmandera!


InteractiveViewer Controle not found after build apk

Duplicate Check

[X] I have searched the opened issues and there are no duplicates

Describe the bug
InteractiveViewer is not defined yet after build apk
Code sample
import flet as ft
def main(page: ft.Page):
page.add(
ft.InteractiveViewer(
expand=True,
min_scale=0.1,
max_scale=5,
boundary_margin=ft.margin.all(20),
on_interaction_start=lambda e: print(e),
on_interaction_end=lambda e: print(e),
on_interaction_update=lambda e: print(e),
content=ft.Container(
gradient=ft.LinearGradient(colors=[ft.colors.RED, ft.colors.BLUE]),
),
)
)
ft.app(target=main)
To reproduce
run the code and build it apk
Expected behavior
No response
Screenshots / Videos

Operating System
Windows
Operating system details
Windows 10
Flet version
0.24.0
Regression
I'm not sure / I don't know
Suggestions
i think you shoud add it in package folder like a Lotties controle
Logs
Logs
[Paste your logs here]

Additional details
No response

It should be fixed now. Please re-build the app.

@FeodorFitsner should i update the flet or what

Yep


namespace change

Step 11 should be
namespace Phoneword instead of
namespace Core

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

ID: 2de3e72c-8948-4dd5-e37f-9cf81e62c127
Version Independent ID: 7b7c5c7f-4102-8e91-fbe6-7d21fcc8f5be
Content: Xamarin.Forms Quickstart - Xamarin
Content Source: docs/xamarin-forms/get-started/hello-xamarin-forms/quickstart.md
Product: xamarin
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @udubnate
Thanks for the feedback. I've updated the doc in a PR, which should go live within a couple of days.


missing comma in attribute listing

Hello,
I recently used your tool to generate a rust file to use with the yaserde library.
I've noticed that the generated file had a missing comma in the listing of attributes. Is that intended or not?
    #[yaserde(attribute, prefix = "xlink" rename = "actuate")]
    pub actuate: Option<xlink::Actuate>,

I would have expected to have the following:
    #[yaserde(attribute, prefix = "xlink", rename = "actuate")]
    pub actuate: Option<xlink::Actuate>,

notice , between prefix = "xlink" and rename = "actuate".
Thank you for the awesome effort, by the way ;).

Think you are right.  Will have a look.

Got it, will fix ASAP! Thank you for the comment!

This PR here will solve the problem.


Integrate with jvm-redux-api specs.

▲▲▲▲ DNM : it is building against a non-released branch ▲▲▲▲▲
Scope
Integrate the tests implemented in jvm-redux-api

add dependency
add tests

Details
cf Cf https://github.com/jvm-redux/jvm-redux-api/pull/13

@pardom I fixed 2 bugs exposed by the tests.
Let me know what you think about the PR and the Specs!


Change vid thumbnail + add new video

Addresses #150 and #151.

I think this is a build issue related to Transifex.

@dennisreimann For future reference, what is the workflow for updating the Transifex master? I wasn't able to find much information on that.

AFAIK it can only be done via the Transifex web interface. We change the source/transifex-master/en.json as you did and then upload the new version on Transifex. Afterwards you can npm run init to pull the new translation files. (You will need the TRANSIFEX_TOKEN as an environment variable for that to work)

@dennisreimann ,  the translations worked for me locally after you updated the Transifex master, but after I pulled your git changes to the website they are no longer resolving correctly (i.e. the titles display as  {{what-is-btcpay}} & {{btcpay-for-communities}}, as before)

You are correct, it looks like someone reuploaded the master file from the master branch.
@pavlenex @britttttk Or is there another way they might have disappeared?

Nothing on my end. What do you guys need to check this? Ping @britttttk she should be able to assist with this.

I've reuploaded the en.json master file from this branch.
Imho we can merge this-- anything missing?


Try to load english spacy model while french's one is configured

Cannot load the French spacy model
I need to preprocess text input with a French tokenizer.
To Reproduce
The French model was installed using the following command:
python -m spacy download fr
I was able to check that fr-core-news-sm is properly installed and that no other spacy module is installed.
pip freeze output attached
pip_freeze_output.txt
While calling the following command:
ludwig train --data_csv 20_cate.csv --model_definition "{input_features: [{name: DESCRIPTION_DEMANDE, type: text, preprocessing: {word_format: french_tokenize}}], output_features: [{name: ID_DOMAINE, type: category}]}"

Loading NLP pipeline
Unable to load spacy model en_core_web_sm. Make sure to download it with: python -m spacy download en_core_web_sm

The full output of Ludwig is attached.
ludwig_output.txt
No word_format: french_<something> works.
Environment:

Windows 10 Enterprise
spacy 2.1.4
Python 3.6.8
Ludwig 0.1.2

I replaced in the previous command the word format french_tokenize by an unexisting value (for example, french_tokenizzzzzzzzzzzze),
ludwig train --data_csv 20_cate.csv --model_definition "{input_features: [{name: DESCRIPTION_DEMANDE, type: text, preprocessing: {word_format: french_tokenizzzzzzzzzzzze}}], output_features: [{name: ID_DOMAINE, type: category}]}"
And got the following output:
ValueError: Key french_tokenizzzzzzzzzzzze not supported, available options: dict_keys(['characters', 'json', 'space', 'space_punct', 'underscore', 'comma', 'untokenized', 'stripped', 'english_tokenize', 'english_tokenize_filter', 'english_tokenize_remove_stopwords', 'english_lemmatize', 'english_lemmatize_filter', 'english_lemmatize_remove_stopwords', 'italian_tokenize', 'italian_tokenize_filter', 'italian_tokenize_remove_stopwords', 'italian_lemmatize', 'italian_lemmatize_filter', 'italian_lemmatize_remove_stopwords', 'spanish_tokenize', 'spanish_tokenize_filter', 'spanish_tokenize_remove_stopwords', 'spanish_lemmatize', 'spanish_lemmatize_filter', 'spanish_lemmatize_remove_stopwords', 'german_tokenize', 'german_tokenize_filter', 'german_tokenize_remove_stopwords', 'german_lemmatize', 'german_lemmatize_filter', 'german_lemmatize_remove_stopwords', 'french_tokenize', 'french_tokenize_filter', 'french_tokenize_remove_stopwords', 'french_lemmatize', 'french_lemmatize_filter', 'french_lemmatize_remove_stopwords', 'portuguese_tokenize', 'portuguese_tokenize_filter', 'portuguese_tokenize_remove_stopwords', 'portuguese_lemmatize', 'portuguese_lemmatize_filter', 'portuguese_lemmatize_remove_stopwords', 'dutch_tokenize', 'dutch_tokenize_filter', 'dutch_tokenize_remove_stopwords', 'dutch_lemmatize', 'dutch_lemmatize_filter', 'dutch_lemmatize_remove_stopwords', 'greek_tokenize', 'greek_tokenize_filter', 'greek_tokenize_remove_stopwords', 'greek_lemmatize', 'greek_lemmatize_filter', 'greek_lemmatize_remove_stopwords', 'multi_tokenize', 'multi_tokenize_filter', 'multi_tokenize_remove_stopwords', 'multi_lemmatize', 'multi_lemmatize_filter', 'multi_lemmatize_remove_stopwords'])
I shows that:

the parameter word_format is taken into account
the value french_tokenize is supposed to be taken into account

Fixed it, can you please install from the current master with pip install git+https://github.com/uber/ludwig.git and confirm that it solves your problem? Thank you.

I installed your patch calling pip install git+https://github.com/uber/ludwig.git.
patched_ludwig_install.txt
I then called ludwig train --data_csv 20_cate.csv --model_definition "{input_features: [{name: DESCRIPTION_DEMANDE, type: text, preprocessing: {word_format: french_tokenize_filter}}], output_features: [{name: ID_DOMAINE, type: category}]}"  and got the same result.

Loading NLP pipeline
Unable to load spacy model en_core_web_sm. Make sure to download it with: python -m spacy download en_core_web_sm

The details of the output:
patched_ludwig_output.txt

I have tried to set preprocessing -> text -> word_format instead of input_features -> preprocessing -> word_format and got the same result.
I have tried to set italian_tokenize instead of french_tokenize (knowing that italian's spacy module is not installed) and got the same message about English spacy model.

In my tests I replicated exactly your command with fake data and it works fine.
Are you sure you are using the latest code for master? As the version number is the same it may have not replaced the regular version, try uninstalling and reinstalling using the git master.

The pip install output was misleading. The version of the file ludwig/utils/strings_utils.py actually was the older one. Uninstall/reinstall solved this and I can confirm that your patch allows to use French word formats. Thx.

You're welcome!

@w4nderlust
The release version-0.1.2 still has the typo where only english processing is used even for other languages in format_registry of string_utils.py.
Master branch though has the changes.  Will you be having those changes in the next release and for now it is better to install master?

Yes, the next release will include these changes (it will come soon), for now I suggest using master.


Practically copied what it says. Still no advance

Challenge Use a CSS Class to Style an Element has an issue.
User Agent is: Mozilla/5.0 (Linux; Android 5.1; HTC Desire 625 Build/LMY47O) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.93 Mobile Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

CatPhotoApp

Kitty ipsum dolor sit amet, shed everywhere shed everywhere stretching attack your ankles chase the red dot, hairball run catnip eat the grass sniff.

@wrannikko that's not a bug, you have to add the class name to the h2 element. Check the instructions correctly.

Thanks but I already solved it
On Dec 5, 2016 2:07 AM, "Babajide Fowotade"<EMAIL_ADDRESS>wrote:

@wrannikko https://github.com/wrannikko that's not a bug, you have to
add the class name to the h2 element. Check the instructions correctly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FreeCodeCamp/FreeCodeCamp/issues/11926#issuecomment-264781970,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXQEsvAaU-MrW3007CtuAA4EYKG8XE8mks5rE7hAgaJpZM4LD5F2
.

Closing as resolved. Happy coding!


Roll engine cc3009cb4ea9..f3a3d0ce7f0b (5 commits)

https://github.com/flutter/engine/compare/cc3009cb4ea9...f3a3d0ce7f0b
git log cc3009cb4ea9..f3a3d0ce7f0b --no-merges --oneline
f3a3d0ce7 Roll src/third_party/skia 11f4994b84e1..175b587a634d (1 commits) (flutter/engine#6313)
19ac3e1ac Roll src/third_party/skia 358558a4cecc..11f4994b84e1 (2 commits) (flutter/engine#6312)
7648d21b0 Dart SDK roll for 2018-09-21 (flutter/engine#6311)
5b8e8c328 Make FlutterStandardCodec handle writing NSData (flutter/engine#6207)
02901b78c Decouple PlatformViewsController from FlutterView. (flutter/engine#6303)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

@rmistry @liyuqian : New roll has been created by https://autoroll.skia.org/r/flutter-engine-flutter-autoroll

Auto-roller completed checks. About to merge.

complex_layout_scroll_perf__memory regressed with this commit.


Deploy Teleportation on testnets & AWS

:clipboard: Related to #942
Overview
Deployment teleportation contracts on Boba BNB testnet, Boba Avax testnet, Boba Goerli & Goerli as well as deployment of teleportation service on AWS.
Boba_base repo already updated (bnb_testnet & avax testnet branch, ..).
Testing
Services run successfully.
NOTE: I only initialized the contracts and didn't yet add any routes as I will need to collect the corresponding assets and we might wanna discuss which routes we precisely now want to support (otherwise I'll just add support for routes mentioned in #959 )

created separate issue since Boyuan has the access @souradeep-das


feat: add readFormData and eventToRequest

Resolves #419

🔗 Linked issue

❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[x] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR adds support for Request and FormData in event handler.
2 new helpers are introduced :

getRequestFromEvent
getFormData

This helpers relies on Request and FormData to be available in the global scope as per the Fetch specification, which means the tests are disabled for node < 18 (which is fine as 18 reaches EOL in 3 months)
// With a JSON body ...
const handler = eventHandler(async (event) => {
	const nativeRequest = await getRequestFromEvent(event);
	expect(nativeRequest instanceof Request).toBe(true);
	expect(nativeRequest.method).toBe("POST");
	expect(nativeRequest.headers.get("hello")).toBe("world");
	const body = await nativeRequest.json();
	expect(body).toMatchObject({
	  user: "john",
	});
	return "ok";
})

// With x-www-form-urlencoded data
const handler = eventHandler(async (event) => {
	const formData = await getFormData(event);
	const user = formData.get("user");
	expect(formData instanceof FormData).toBe(true);
	expect(user).toBe("john");
	return { user };
})

📝 Checklist

[x] I have linked an issue or discussion.
[x] I have updated the documentation accordingly.

I think getRequestFromEvent is a nice addition but we might find a more straightforward solution to handle form data that does not require creating a whole Request object to parse form-data. (splitting into two PRs would be nice 🙏🏼 )

@pi0 Updated the method names to readFormData and eventToRequest

Hi @Hebilicious,
Lovely PR 😍
I was wondering if this will handle forms with multimedia data as well?

@neo-franklin-tina Are you talking about multipart/form-data ? You're right we should also support this.

Rebased util with event.request from #454. Thanks for the ideas!


Faster state serialization

Last week we discovered with @kuychaco that serializing state is taxing on Atom's responsiveness, because serialization happens on the main thread. As per https://bugs.chromium.org/p/chromium/issues/detail?id=536620, we discovered that structured clone isn't very performant and therefore we started researching a different approach that could perform better.
Below you can take a look at a profile of saveState and IndexedDb.put():

Total: ~ 116ms for inserting 11 characters on 200 cursors.
We decided to attack the problem in two ways:

Use JSON.stringify instead of structured clone to store state in IndexedDb.
Defer work until a requestIdleCallback is dispatched. This allows to avoid blocking the main thread if some important operation is being performed.

For the same scenario, this is how this PR performs:

Total: ~ 40ms, ~ 3x faster. :racehorse:
Serializing History
Another problem we noticed is that the more edits get performed on a certain buffer the slower serializing its history becomes. This makes sense, especially in the context of large multi-cursor operations, where a single checkpoint in history could contain lots of changes.

Total: ~ 130ms, for inserting 5 characters on 1500 cursors.
This is an issue we still have to solve, but here's a list of potential solutions:

Remove history serialization altogether. I didn't expect history to be remembered across sessions and I believe this is not a "loss of work" scenario, although it's admittedly a nice feature. Sublime Text doesn't preserve history after closing the window, but you might argue that our users are already familiar with this behavior.
Add an option to preserve history. The default would be false, and users can decide to opt-in if they want to keep the original behavior.
Incrementally serialize history's state. This might be a nice improvement for long-running editor sessions, because we just have to serialize new changes as they come in, avoiding the repeated work of serializing the same state over and over and spreading the cost over a large timespan. This won't help the multi-cursor scenario, though, where a huge amount of changes could be collected over a short amount of time, and hence slow down the UI.
Serialize state across multiple requestIdleCallbacks. This is a nice idea in theory because it allows to split the cost of serialization in 50ms chunks, thus not blocking the main thread at all. In practice, however, it might be difficult to both keep track of changes and serialize stuff in parallel: for example, what happens if, while serializing state, an edit occurred?
After :ship:ping web workers, move this work off the main thread. I think @nathansobo brought up this idea in the past, but basically we could have a separate TextBuffer instance working on another thread; as changes come in, we postMessage to the worker thread and we let it deal with all the serialization stuff. This somewhat depends on structured clone being fast, though, because otherwise sending message to the worker thread would let the main thread pay roughly the same cost of serialization.

I believe 2) could actually be fine because it would allows us to keep this code path fast without sacrificing simpleness.
Conclusion
I think it might okay to :ship: and experiment with this even if we do not solve the problem illustrated above. If serialization is still a bottleneck after test-driving this, we definitely need to back the feature out and address the problem from another, more performant perspective.
What do you think?
/cc: @atom/core

Another problem we noticed is that the more edits get performed on a certain buffer the slower serializing its history becomes.

This might be the "slowdown after working for a while" problem some people are observing.

I feel that preserving buffer history across restarts is a misfeature. I've never wanted to undo past when I've opened the editor and if I do accidentally it always comes with a "now where was I again.. this is weird" reaction.
With that said.. would it be possible to move history serialization into its own non-bundled package? That would keep core clean and allow whomever to pick up the work of making it "fast" later.

Preserving undo/redo history is a must-have for any editor. Keep in mind
that when you voluntarily close the editor, you're supposed to have
finished editing whatever you were editing, but accidental quits/crashes
are the other side of the story. And since no program ever made (and Atom
just won't be the exception) is crash-free, please keep the undo/redo
restore working and in-core.
2016-02-22 18:39 GMT+01:00 Ryan Leckey<EMAIL_ADDRESS>
I feel that preserving buffer history across restarts is a misfeature.
I've never wanted to undo past when I've opened the editor and if I do
accidentally it always comes with a "now where was I again.. this is weird"
reaction.
With that said.. would it be possible to move history serialization into
its own non-bundled package? That would keep core clean and allow whomever
to pick up the work of making it "fast" later.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/pull/10925#issuecomment-187283468.

--
alexandernst

How about removing it from the normal serialization code path? Only serialize buffer history when we do #10605 (periodically save unsaved buffers) and only on an idle callback. I feel (as @alexandernst said) that this is more for a crash restore scenario and doing it on text editor change, all the time, is not ideal.

@as-cii Instead of enabling/disabling history entirely, wouldn't it be nice to have some sort of limit on it?

Instead of enabling/disabling history entirely, wouldn't it be nice to have some sort of limit on it?

Limit isn't going to solve the multi-cursor problem, where a single checkpoint in history might contain lots of changes. We can limit the number of checkpoints we store, but unfortunately we cannot cut out changes within a transaction.
I am going to :ship: this, as it is a 100% backwards compatible change that improves performance. I am still curious to see how it feels now that we have put it in a requestIdleCallback and used JSON.stringify.
In the meantime, I'll investigate what's wrong with History.serialize and how we can make that function call faster :zap:. If we manage to do so, then chunking stuff might become more enticing and we can exploit the power of requestIdleCallback to split work while still keeping the same functionality.
Thanks everyone for the precious feedback! :sparkles:


Lewis_file abscence causes diffusion steady flame solver to fail to start.

diffusion_steady_flame_solver example fails to run because it can't find a Lewis_file.  I ran bash run.sh and got an error about the code not being able to located a Lewis file. So I looked in the other examples and found out that the Lewis file is named Lewis_file, so I created a blank file with that name, and the example started to run.

Thanks for reporting this issue.  There is a Lewis_file for that example here.  I think you may have gotten this error because you ran in the build directory instead of in the install directory.  Otherwise I would guess that some error happened during the install that prevented the Lewis file from being copied over.  Can you try (re-)running make install and check to see that the Lewis_file in the installed location matches the one from <zerork_root>/examples/diffusion_steady_flame_solver?

Closing due to lack of response.


visualization detail -- which timestamps exactly?

from https://github.com/flatironinstitute/blastoSPIM_web/issues/9
"""
For the visualization page:
Let's have the choice be 8, 16,32, 64, 128 nuclei stage (without the sequence name - which doesn't mean anything to the user, nucleus -> nuclei since plural here) - and similarly change the title of the visualization to exactly match this.
"""
Please let me know which timestamps in which series I should use exactly.

Aaron reminder -- look into "holes" in 3d surface models when regenerating data sets.


Catches pokemon and spins pokestops on --mode all

Short Description:
Stops on the way to pokestops so you can capture pokemon on --mode all. I've tried to merge this in for 2 days now, but the my changes are too big and the code base too unstable for me to do this. As a consequence I've reverted and/or changed alot of code just to make it runnable.
Fixes:

catches pokemon and spins pokestops on --mode all

I like this commit, I was trying to do this days ago, just interrupted by other issue.
Please fix the conflicts :)

first thing, remove the pgoapi folder, because we install it using pip

You're clearly coming from a working dir that is messed up with master and dev code. It's impossible to consider to merge your pull request until you get a clean environment and test everything you said you fixed again.

max_steps function was just broken so I removed it, but it should be easier to implement a working version with my code.


[FLINK-17599][docs] Update documents due to FLIP-84

What is the purpose of the change
This pr aims to update the documents due to FLIP-84. Additional, add documents for USE/EXPLAIN/DESCRIBE statements, and do some code cleanup
Brief change log

fix typos in TableEnvironment javadoc and PlannerBase javadoc
Code cleanup: use new methods introduced in FLIP-84 instead of deprecated methods
Update documents due to FLIP-84
Add documents for DESCRIBE statement
Add documents for EXPLAIN statement
Add documents for USE statement

Verifying this change
(Please pick either of the following options)
This change is document updating / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

+1 from my side when Timo's comments are addressed.

cc @twalthr

@twalthr Thanks for the detailed review, I have updated the pr based on comments.

Thanks @godfreyhe. Merging...

merged (see FLINK-17599)


log_func parameter missing

There is a log_func parameter missing with recent changes:
Traceback (most recent call last):
  File "/home/spire/git/ulozto-streamer/ulozto-downloader.py", line 7, in <module>
    cmd.run()
  File "/home/spire/git/ulozto-streamer/uldlib/cmd.py", line 82, in run
    tor.launch(solver.log)
TypeError: launch() takes 1 positional argument but 2 were given

I am not sure if it was removed by mistake or if there was other intention, so leaving it with you to fix @setnicka .

I accidentally pushed commits before everything was completed. It should be fixed now.


complicated parser and ' or + character

filename
Airfiles #04 The 'Big Show' 2.cbz
turns title into
The' Big Show' 2
filename
Army #11 Operation 'Z'.cbz
turns title into
Operation' Z'
filename
De Dwaas Van De Koning #009 Het Testament Van d'Artagnan.cbz
turns title into
Het Testament Van d' Artagnan
notice the added space after the '
I am using the complicated parser through command line , but the same behaviour is seen in the GUI .
Using version 1.6.0a21.dev0
The same happens with + signs .
filename
De Man of Steel #01 The Invasion + Power of The Monster.cbz
turns title into
The Invasion+ Power of The Monster
When a title start with a ' character , it drops it completely .
For example
Atari Force #09 'Als Uw Oog U Tot Last Is...'.cbz
turns title into
Als Uw Oog U Tot Last Is'
drops the first ' completely (and it also drops the ... for some reason)

that's because quotes shouldn't be in filenames 😝. I'll see if I can get to this next week

If you need a Comic series to test with , this would be a good example for the ' sign :
https://www.stripinfo.be/reeks/index/1847_De_psy


Is there an easy way to embed any uploaded image inside a content body field / textarea (within the same model)?

please use the google group for this sort of question as it's not an issue - thanks


Make delayed output state non-member variable

It helps to look at commit it by commit.
The output_*_delayed states are used to compute the correction that gets applied to the output filter, such that the output_*_delayed states are tracking the EKF delayed states.
It seems that it is not necessary to have a member variable to store this delayed output. Storing it only introduces the need to keep it in sync with the buffer itself, during a EKF state reset.
In addition, I notice that we get the delayed output by calling the buffers get_oldest function. Will the oldest entry in the buffer always be close to the delayed fusion horizon?
Plus, in the alignOutputFilter, the output_new's quaternion gets updated, but not its velocity or position. Bug?

In addition, I notice that we get the delayed output by calling the buffers get_oldest function. Will the oldest entry in the buffer always be close to the delayed fusion horizon?

It is by definition. This is the method used to extract the oldest IMU data from the buffer. The time stamp of that oldest IMU data defines the delayed fusion time horizon and that data is used for prediction only. Observation data is extracted using the pop_first_older_than function which finds the newest data that has fallen behind the fusion time horizon defined by the _imu_sample_delayed.time_us timestamp.

Plus, in the alignOutputFilter, the output_new's quaternion gets updated, but not its velocity or position. Bug?

It gets updated the next time applyCorrectionToOutputBuffer is called, which does
_output_new = _output_buffer.get_newest();
This is happens at the end of each Ekf::update() and the accessor functions for  _output_new.vel,pos are not called in ekf2_main.cpp until after the Ekf::update() has run so currently this is not causing a change in behaviour. However this is a potential trap for future development so would recommend that in alignOutputFilter we replace:
_output_new.quat_nominal = q_delta * _output_new.quat_nominal;
_output_new.quat_nominal.normalize();

_output_sample_delayed.quat_nominal = q_delta * _output_sample_delayed.quat_nominal;
_output_sample_delayed.quat_nominal.normalize();

with
_output_new = _output_buffer.get_newest();

_output_sample_delayed.quat_nominal = _state.quat;
_output_sample_delayed.vel = _state.vel;
_output_sample_delayed.pos = _state.pos;


Added ability to set JS_URL and JS_ROOT when using staticfiles.

Hello,
First, thank you for this project. I've been using it for quite some time, and it's nice to finally be able to contribute something back.
I altered the settings slightly to allow the JS_URL and JS_ROOT properties to be set when using static files.
On a lot of projects, I serve my static files from S3 via CloudFront, and I've yet to be able to get TinyMCE's document.domain property to work properly with that setup. So, I just started serving the TinyMCE JavaScript files from the box that was handling the request, which avoids the cross-domain issue.
The functionality I added doesn't break the default behavior if you haven't specified JS_URL or JS_ROOT.
Kindest regards,
Brandon Taylor
btaylorweb.com

isn't this a duplicate of #15?
maybe i'm missing something?

Yes, it appears so. I didn't check to see if someone had already created an issue on this.


fix: do not focus the field on helper element click

cherry pick of https://github.com/vaadin/web-components/pull/2232 for v14
add missing test
Fixes vaadin/flow-components#955

 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.


Simulation with flow rate coefficient

The simulation was successfully run after adding the flow rate factor.
I intentionally set the activation energy for beta and kappa to be smaller than others to control the result
However,

The function for calculating the flow-rate coefficient still requires some updates
Haven't built the for loop for different flow rates
I haven't added the probability of growth at this time point. It probably won't make too much change to the result

Fix the above comments.
Complete the 2D simulation with both Temperature and Flow rate inputs.
Some updates for the rate coefficient function are still required.
Haven't built the data structure for Energies mentioned in Issues.


Add lines in PPP

Codecov Report

Merging #328 (950f6e4) into master (cfb1f2f) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##             master     #328   +/-   ##
=========================================
  Coverage     48.70%   48.70%
  Complexity      525      525
=========================================
  Files           114      114
  Lines          2743     2743
  Branches        293      293
=========================================
  Hits           1336     1336
  Misses         1321     1321
  Partials         86       86

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Fixed issue where BinaryReader.PeekChar would fail

Fixed issue where BinaryReader.PeekChar would fail, since bytedata is not UTF8 content

Input from @markheath:

PeekChar and ReadByte behave differently. One advances the stream and the other doesn't. And ReadByte will return -1 if it reaches the end of stream, so I don't think checking for 0 is correct.
Do you have an example failing WAV file that can't be handled?

Hi Mark,
Thanks for your quick reply!
I totally agree that PeekChar and ReadByte behaves differently.
The issue with PeekChar is that the BinaryReader by default is created with encoding set to UTF8. So when using PeekChar, it will try to peek the next character from the reader, but this of course requires that the byte read from the stream can be successfully parsed as an UTF8 character. And when dealing with raw binary data, this is unfortunately not always the case.
The most optimal solution would be if the dotnet team had included a PeekByte function. That would have solved everything.
So my suggested way around this is to actually read the next byte from the stream using ReadByte:

If the byte read is a pad byte (0) everything is good. The pad byte is consumed by ReadByte and the stream position is correctly  advanced with +1, so the next chunk read does not start with the pad byte.
If it is not a pad byte, the position of stream will be set back one byte by "stream.Position--;", so that byte will be included in the next chunk read.

What are your thoughts on this?
I have created a sample app including audio files to reproduce the issue: https://www.dropbox.com/s/ot693uy3hvclri9/NAudioPeekCharReproduction.zip?dl=0
One issue coming to mind: It might be worth checking for end of the stream before calling ReadByte...
Best,
Lars Peter


GEODE-8793: Fix PdxTypeRegistry cleanup

Upon disconnection, if option on-client-disconnect-clear-pdxType-Ids
is enabled, PdxTypeRegistry is supposed to be cleaned up. But the
problem is that this was not happening each time, but each 2 times
the client disconnects from the cluster.
As there is no need to make the call in an async fashion, PdxTypeRegistry
is now cleaned up synchronously.
Also some methods have been renamed to better represent the
functionality.
Given its quite complex to test this behaviour with IT, a UT has been
created testing that every time pool-size reaches 0, PdxTypeRegstry
is cleaned up.
Also fixed an issue within ClientMetadataService that was causing a
coredump while trying to stop the thread when it was not started in
the first time.

I wonder if anyone of this is actually necessary. I think this idea of clearing the PDX registry is a hold over from the old global world. Under that old model if you "closed" the cache it was never really closed, especially from the .NET layer, thus it never really cleared the the PDX registry, which was also global. Now the PDX registry is owned by Cache and Cache can actually be closed. If the Cache is closed the registry is destroyed. I really think we should just eliminate all this code.

Sorry Jacob for the delay in reviewing this, I've just come back from my vacations.
Thing is this change is part (or at least I though so) of a bigger issue. What we are seeing is that whenever a native client is connected to a cluster and such cluster is stopped and restarted with a backup restore point, several request are failing... we noticed that it was due to the client being aware of some PdxTypes which the cluster does not know about due to having loaded a restore point previous in time... So this change solve the issues, but I am conducting some tests as it's unclear whether or not that's the full solution.

I wonder if anyone of this is actually necessary. I think this idea of clearing the PDX registry is a hold over from the old global world. Under that old model if you "closed" the cache it was never really closed, especially from the .NET layer, thus it never really cleared the the PDX registry, which was also global. Now the PDX registry is owned by Cache and Cache can actually be closed. If the Cache is closed the registry is destroyed. I really think we should just eliminate all this code.

Sorry Jacob for the delay in reviewing this, I've just come back from my vacations.
Thing is this change is part (or at least I though so) of a bigger issue. What we are seeing is that whenever a native client is connected to a cluster and such cluster is stopped and restarted with a backup restore point, several request are failing... we noticed that it was due to the client being aware of some PdxTypes which the cluster does not know about due to having loaded a restore point previous in time... So this change solve the issues, but I am conducting some tests as it's unclear whether or not that's the full solution.

I wonder if anyone of this is actually necessary. I think this idea of clearing the PDX registry is a hold over from the old global world. Under that old model if you "closed" the cache it was never really closed, especially from the .NET layer, thus it never really cleared the the PDX registry, which was also global. Now the PDX registry is owned by Cache and Cache can actually be closed. If the Cache is closed the registry is destroyed. I really think we should just eliminate all this code.

After a detailed analysis of the problem we were experimenting, quite the opposite, this is much necessary. In fact there is the same behaviour in the Java client. This behaviour guarantees that if the cluster is restarted and the PdxTypeRegistry in the distributed system changes there is no de-sync between the client and the server.
It's quite important that there are not PdxType in the client which does not exist in the server. Otherwise it could happen that some PDX entries with this PdxType are written in the server, corrupting the data in the region.
TBH, I'd rather prefer that written entries which are PdxInstances are verified on the server-side, but this would probably increase put time.

I just wanted to point out that I noticed a quite concerning bug having to do with throwExceptionIfError, which I solved for the specific case but I created a new Jira ticket to tackle all the cases: https://issues.apache.org/jira/browse/GEODE-8973

Maybe if @moleske @mmartell @pdxcodemonkey @mivanac @mkevo @albertogpz want to jump it and throw some commments, they will be appreciated :)

Looks good to me!

@gaussianrecurrence Can you please rebase onto the latest develop?  The conflicts need to be resolved before I can merge.

@gaussianrecurrence Can you please rebase onto the latest develop? The conflicts need to be resolved before I can merge.

Rebased and pipelines passed!


Move non-plugin definition keys under a hub key

Discussed in https://github.com/meltano/hub/discussions/609

Originally posted by pnadolny13 June 15, 2022
As part of the 2.0 release upgrades to the hub which included a full refactor of the definition file format we added some new keys that are for rendering documentation. I'm proposing that we move those under something like a docs or meltanohub key so that its clean and clear what parts are plugin definition attributes and should be returned via the API to be stored in lock files vs what should simply be extra metadata for the hub.
For example tap-adwords usage metadata key for the hub docs content is in the definition file.
Then in the API payload generator we exclude them.
The keys are:

keywords
maintenance_status
domain_url
definition
next_steps
settings_preamble
usage
prereq

The new schema would be something like:
name: tap-adwords
label: Google Ads
description: Advertising Platform
...
hub:
    domain_url: x
    usage: y
    prereq: z
...

cc @tayloramurphy @aaronsteers @DouweM @alexmarple @z3z1ma
Spec proposal

[ ] Move the keys in the list above to be under a hub key
[ ] Update the generator and html files to reference the new location
[ ] Update the api payload generator to reference the new location
[ ] Update the JSON schema

@tayloramurphy - I'm not quite ready to move forward on this and wanted to propose some changes. I'll drop my comments in the linked discussion so it's all in one place.


Bump version to 0.22.0

Includes, #52, #55, #56, #57
Full diff: https://github.com/alphagov/digitalmarketplace-utils/compare/0.21.0...master

Once this is merged, do we have an established process for who should run the push_tag script?

I'm going to merge now and will run the script.


About number of generated keyphrases

关于您论文里的模型生成关键词数量的实验结果，有些地方我不是很明白，想要请教一下

关于oracle那一行，Avg #present 的2.837是统计的整个数据集，还是训练集，验证集，或是测试集？那如果是整个数据集的话，包含了训练集岂不是不太合理- -，因为感觉模型用训练集训练，再用训练集生成结果？
还有表中的众模型的结果是基于验证集还是测试集？包括MAE和平均数量。那统计过程中是去掉重复的关键词，还是未去重？
另外在ACL2020的一篇文章里《Exclusive Hierarchical Decoding for Deep Keyphrase Generation》他统计的oracle Avg #present =3.32，但是他也没有说这是基于整个数据集还是仅仅是测试集或验证集的统计结果。我自己统计了一下测试集和验证集Avg #present都是在3.4左右，比较接近ACL2020这篇文章。

希望得到您的建议

These are the results on the testing set.
We remove all the duplicated keyphrases before computing the MAE and avg # keyphrases. They are the results on the testing set.
The results of Exclusive Hierarchical Decoding for Deep Keyphrase Generation are also on the testing set, but Wang Chen may used a different way to preprocess the data in this paper. @Chen-Wang-CUHK , can you help to explain this question? Thanks.

These are the results on the testing set.
We remove all the duplicated keyphrases before computing the MAE and avg # keyphrases. They are the results on the testing set.
The results of Exclusive Hierarchical Decoding for Deep Keyphrase Generation are also on the testing set, but Wang Chen may used a different way to preprocess the data in this paper. @Chen-Wang-CUHK , can you help to explain this question? Thanks.

In the ACL 2019 paper, we do not stem the source input and keyphrases when we compute the number of present and absent keyphrases. But in the ACL 2020 paper, we stem them before we compute the statistics.

These are the results on the testing set.
We remove all the duplicated keyphrases before computing the MAE and avg # keyphrases. They are the results on the testing set.
The results of Exclusive Hierarchical Decoding for Deep Keyphrase Generation are also on the testing set, but Wang Chen may used a different way to preprocess the data in this paper. @Chen-Wang-CUHK , can you help to explain this question? Thanks.

非常感谢您的解答

These are the results on the testing set.
We remove all the duplicated keyphrases before computing the MAE and avg # keyphrases. They are the results on the testing set.
The results of Exclusive Hierarchical Decoding for Deep Keyphrase Generation are also on the testing set, but Wang Chen may used a different way to preprocess the data in this paper. @Chen-Wang-CUHK , can you help to explain this question? Thanks.

In the ACL 2019 paper, we do not stem the source input and keyphrases when we compute the number of present and absent keyphrases. But in the ACL 2020 paper, we stem them before we compute the statistics.

原来是这样呀，我明白了，非常感谢


Duplicate airline WindowNumber

Using this WindowNumber snippet
when refreshing my vimrc file within vim with command so $MYVIMRC
WindowNumber in the inactive pane would duplicate, as many times as I use so $MYVIMRC command
Is there any way to refresh vimrc without duplicate the WindowNumber in airline?

Yeah, it keeps on adding the window number. I suggest to not use it or simply do not so your VIMRC so often. That should not be needed anyhow.


unused_var object field composition spec

Just wondering if this should not be failing? Is this already fixed in 1.X branch?

Nice catch!
Your test was slightly broken:

(#{field} inside "" actually got interpolated within the test itself, and would fail with a ReferenceError: field is not defined
you'd always get a unused error for "obj" as it's assigned to but never read

However, you are correct in that the linter didn't recognize the interpolated expression as a read for field! Fixed in 0.4.4

nice ty


Missing missions - Appendices

It looks like that some missions (ConfigMap for all the runtimes) are missing within the appendices of the doc

@cmoulliard @rhoads-zach It seems that this is no longer an issue now that we have per-runtime Developer Guides instead of a common Getting Started Guide. Closing.

My mistake, I see that the appendix section has been retained for now. Reopening. Going to updated the section and file a PR

fixed in PR #273


WAL2 in 2025

Is WAL2 part of the SQLite main trunk?

I'd suggest you ask this on a SQLite forum. We're downstream.
FWIW, the answer is no.
https://sqlite.org/forum/forumpost/17249fb83a?t=c&unf


Add process id of participant to properties panel

Closes #278
Adds the inputs to edit a participant's process name and id to the properties panel.
Acceptance Criteria

[ ] Corresponds to the concept
[ ] Corresponds to the design

Definition of Done

[ ] corresponds to the design principles
[ ] corresponds to the code standards
[ ] passes Continuous Integration checks
[ ] available as feature branch on GitHub

[ ] contains the cleaned up commit history
[ ] commit messages satisfy our commit message guidelines
[ ] a single commit closes the issue via Closes #issuenr

Added @andreasgeier via modeling-design

Added @andreasgeier via modeling-design

In the current state, I can see and edit new fields for the Process ID and Process Name. So basically, the issue is fixed.
From the UX perspective, it would be an improvement when we are always specific with the process and participant ID like Ingo described here. I understand that this is a generic component and the generic labels are used for all elements but these two are main elements. Moreover: for the process we do not even have a selection marker. And having attributes of two elements in a property panel is also questionable. All of this speaks in favor of specific labels for both.

In the current state, I can see and edit new fields for the Process ID and Process Name. So basically, the issue is fixed.
From the UX perspective, it would be an improvement when we are always specific with the process and participant ID like Ingo described here. I understand that this is a generic component and the generic labels are used for all elements but these two are main elements. Moreover: for the process we do not even have a selection marker. And having attributes of two elements in a property panel is also questionable. All of this speaks in favor of specific labels for both.

All of this speaks in favor of specific labels for both.

You think of Process Id / Process Name and Participant Id / Participant Name here or what would be your suggestion?

All of this speaks in favor of specific labels for both.

You think of Process Id / Process Name and Participant Id / Participant Name here or what would be your suggestion?

Exactly

Exactly

I agree that this would improve things and it is an easy pick, too.
@azeghers Would you be O.K. with shipping that additional improvement as a follow up to this PR? We'd need to improve it in both apps, of course.

I agree that this would improve things and it is an easy pick, too.
@azeghers Would you be O.K. with shipping that additional improvement as a follow up to this PR? We'd need to improve it in both apps, of course.


Config.xml file issue even after updating everything

I've been getting this error for hours even after updating everything:
Your config.xml file does not have a  element.
Add something like:
at /usr/local/lib/node_modules/ionic/node_modules/ionic-app-lib/lib/config-xml.js:64:15
at _fulfilled (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:787:54)
at self.promiseDispatch.done (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:749:13)
at /usr/local/lib/node_modules/ionic/node_modules/q/q.js:557:44
at flush (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:108:17)
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)

Could you provide me with the output from ionic info from within your project directory? Thanks, this should help in troubleshooting.

Hello all! As it seems it has been a while since there was any activity on this issue i will be closing it for now. Feel free to comment if you are still running into this issue. Thanks for using Ionic!


Minor changes

this change adds the webhook routes and basic unit tests, but doesn't add the integration tests because I want to redo that whole suite.

Coverage increased (+0.05%) to 99.339% when pulling b17b677ba3bb2c0b99b80ea9c582e4a513917257 on more-webhooks into ab5373439497e3b6f3bbae2a60ff6734029069fe on master.


go

Ignore descendants of any vendor tree
all .go files: chmod 0644
go.mod, go.sum: 0644

#wontfix
Go source files and the Go compiler are typically excluded from deployments.


Choose an architecture

MVC is the thing that everyone knows - or at least thinks they know, because most frameworks say that's how they're built. So it ends up being the default because it's been around long enough for people to have worked with it a fair amount and gained a good understanding of how it's typically implemented.
However, modern web "MVC" on the backend is not really true MVC, which was defined and intended for interactive applications, where it governs a more-or-less unified set of code (you might say both front and back ends together). Think desktop and mobile apps, and actually, web-based SPAs that run on a JavaScript front-end framework can be a good fit for this paradigm as well.
So where does that leave us in PHP land?
Well, we can either stick with what everyone knows, the bastardized version of MVC with its ill-fitting aspects, or we can choose something else - a bastardized version of a different paradigm, or one that was built explicitly with the web, and specifically HTTP, in mind.

A while back I worked on a Google Sheet where I was documenting as many pertinent facts as I could about different popular application architectures, and I invite you to check it out. (Do note the multiple tabs at the bottom.) I haven't yet fleshed it out as well as I originally hoped to, but maybe you can still get some usefulness from it.
https://docs.google.com/spreadsheets/d/1g-pGsIa3MgjudW1AuwWlzJ8zAIKHi08DKgvIneAZBYE/edit?usp=sharing
In it I cover MVC, PAC, MVP, ECB, HMVC, MVVM, MVA, and ADR.
I would also like to provide some links to additional reading on the subject that has informed my learning over the years:
by Dr. Tom Butler, web developer and university lecturer based in Milton Keynes (UK) who has been very influential to me

MVVM, MVC it's all just roman numerals to me (or, Evolving MVC into MVVM) (05 Nov 2010)

by Paul M. Jones, an important contributor in the PHP community, not only to his own projects but also to groups such as the Zend Framework (now Laminas), PHP-FIG, and PEAR

Model View Controller and "Model 2" (18 Jan 2018)
Comparing "Model 2" MVC to ADR (18 Jan 2018)
Tradeoffs in ADR (18 Jan 2018)
Objections to ADR (18 Jan 2018)

And this other random listicle I just dug up:

What distinguishes MVC, MVP, MVVM, MVVM-C, and VIPER architecture patterns from each other? (05 Mar 2023) (full disclosure: I have not looked into this VIPER pattern he mentions)

Never heard of ADR i need to do some reading!

I've heard of MVVM, haven't used it myself -- definitely willing to work with whatever you all thinks work best! I've only created an MVC framework myself, but I'm positive there are better ways of doing it nowadays

@Kameloh you've created a framework before? that's awesome - your experience may prove valuable


Update CODEOWNERS for APIF team

 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.


External tools Fine parameter tuning

pharokka version: 1.5.1
Python version:  3.9.18
Operating System: Ubuntu

Description
Hi again @gbouras13 , this is not a bug report, just some suggestions. I have been trying and studying some of the external software pharokka uses, and I think some parameters could be adjusted to better feature detection in phages.
For instance, analysis of jumbophage CRISPR-Cas systems report spacers of 14-20 nt in length (see here), and minced defaults to a minimum of 26. The same paper reports repeats of 26 nt in length, minced defaults to a minimum of 23, which is fine in this case. And lastly, minced reports only CRISPRs with at least 3 spacers, which I would relax to 2 since there are very compact CRISPR-Cas system in this phages.
minced -h

MinCED, a program to find CRISPRs in shotgun DNA sequences or full genomes

Usage:    minced [options] file.fa [outputFile]

Options:  -searchWL  Length of search window used to discover CRISPRs (range: 6-9). Default: 8
          -minNR     Minimum number of repeats a CRISPR must contain. Default: 3
          -minRL     Minimum length of the CRISPR repeats. Default: 23
          -maxRL     Maximum length of the CRISPR repeats. Default: 47
          -minSL     Minimum length of the CRISPR spacers. Default: 26
...

For mash based identification against inphared index, I see that pharokka uses a minimum mash distance of 0.1 to report matches. I actually think that parameter default is very good, but I can think of use cases where manually setting this parameter could be useful.
Pharokka may benefit of implementing this for some of the other external tools it uses.
I'm not sure which is the best implementation for this feature (and maybe is already possible??), and I'm not enough of a python guru to implement it myself and make a pull request in the short term, although I forked the repo and maybe will try in the future.
Thanks again for implementing pharokka!

Hi @iferres ,
These are great points. I really appreciate the effort you have put into this and explaining it.
I actually think this shouldn't be too hard to implement.
For Minced I'd create some arguments like:

--minced_args and then you could specify --minced_args "-minNR 2"

For mash I'd just add the distance in as a param --mash_distance.
If you have other recommendations (trnascan, Aragorn) please let me know and I will consider it.
George

Thank you George, that parameter implementation looks very good to me. For now those are the only ones which took my attention, but I'm working on these topics so I may reach you again in the future.
Bests!

Hi @iferres ,
I've implemented this in v1.6 - if you are keen it is on the dev branch, otherwise should be out next week :)
George

Genius, thank you very much! Next week I will be working with fresh new phages, I will surely try the dev/new version and report back.
Bests!


Use custom component in columnComponent

`error NG8002: Can't bind to 'ngClass' since it isn't a known property of 'div'.
259   <div class="progress-bar l-bg-cyan" [ngClass]="'width-per-'+row.maxInVehicle*2" role="progressbar">`
`error NG8001: 'tc-rating' is not a known element:

If 'tc-rating' is an Angular component, then verify that it is part of this module.
If 'tc-rating' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the<EMAIL_ADDRESS>of this component to suppress this message.

299  template: <tc-rating [iconsNumber]="10" [value]="row.priority" [disabled]="true" [tcFontSize]="11"></tc-rating>,`
Thanks first for this wonderful library,
Is the library supports this kind of component reusability ?

Hi and sorry for the late reply, not sure if you got passed this but it's a bit hard to tell what caused the error with out some more info. My guess is that you haven't added the tc component as an entry component in this case. I've been pretty busy lately but I hope to release a new reworked version in a not to distant future. It's available as an RC (release candidate at the moment) and it will add some more flexibility to the table and allow you to define different templates that you want to use when rendering columns.


typo in security-secrets-setup README

typo in readme.md for security-secrets-setup is out of date and has a typo:
Use Makefile in the base directory of this repository to build the docker image of security-secretes-setup:

should be:
Use Makefile in the base directory of this repository to build the docker image of security-secrets-setup:

@jim-wang-intel feel free to toss in the fix for this in one of your followup PR's for security-secrets-setup


Problem with deserializing data structures from System.Collections.Immutable

At the present moment Wire is not able to correctly deserialize some of the collections from System.Collections.Immutable - checked on version 1.1.37 for immutable collection and 0.0.5 for Wire.
Sample to reproduce:
var map = ImmutableDictionary<string, object>.Empty;
var serializer = new Wire.Serializer();

using (var stream = new MemoryStream())
{
    serializer.Serialize(map, stream);
    stream.Position = 0;
    var map2 = serializer.Deserialize(stream);  // exception
}

Exception message: System.MissingMethodException - No parameterless constructor defined for this object
Stack trace:

at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at Wire.Converters.EnumerableSerializerFactory.<>c__DisplayClass3_0.b__1(Stream stream, SerializerSession session)
at Wire.ValueSerializers.ObjectSerializer.ReadValue(Stream stream, SerializerSession session)
at Wire.Serializer.Deserialize(Stream stream)

I'm working on this.
Collections of different types are somewhat tricky.
"Normal" types are just binary serialized, field members are written to the output stream.
However, collections, often hold some sort of backing datastructure with over allocated space, e.g. List<T> has a lot of empty pre allocated space in its backing array.
So binary serializng the fields of a collection would result in a very large payload.
(Similar problems exists for hashtables/dictionaries etc)
So, collections should be handled separately, so we can say that if it implements IDictionary<T> or IList<T> or similar, then it should be serialized in a certain way.
The issue here is that there is no "common" way that collections are implemented, there is no guaranteed constructor that takes an IEnumerable<T> to pre fill different collections.
Some collections also have comparison operators attached to them, e.g. dictionaries support different comparison implementations, e.g. casing invariant string comparison for string keys.
What do we consider to be the best default option here, should we add special support for every different collection type?
e.g. we add support for Microsoft.Collections.Immutable?
And should we support serializing extra data like comparison behavior?

Done


Update MainVerticle.java

Enables the use of external content ( .css, .js ... ) in .html files. Without the fix, external files are not read from webroot ( or a sub-directory)
The fix makes inline CSS in index.html obsolete. CSS embedded in this file can be exteralized and alo be reused in error.html and the like ( code de-duplication)

 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.