building static libraries with shared library wrapper

Ref.  #74 haveno-dex/haveno#795
Now, there is only monero-java.so. It wraps monero, monero-cpp, boost etc.
Working with haveno on linux (--useNativeXmrWallet=true).
Depends woodser/monero-cpp#64

I've applied this PR and https://github.com/woodser/monero-cpp/pull/64.
Looks promising, but I'm having trouble building it.
On Ubuntu 20.04, I first get this error:
[100%] Built target monero-cpp
-- MONERO_CPP:/home/woodser/git/monero-java/external/monero-cpp
-- EXTRA_LIBRARIES:
-- Using Boost include dir at /home/woodser/git/monero-java/external/boost/boost
-- Found boost library: boost_chrono;boost_date_time;boost_filesystem;boost_program_options;boost_regex;boost_serialization;boost_wserialization;boost_system;boost_thread
-- Using OpenSSL include dir at /usr/include
-- Using OpenSSL libs: /usr/lib/aarch64-linux-gnu/libssl.a;/usr/lib/aarch64-linux-gnu/libcrypto.a;-lpthread;dl;dl;-lpthread
-- Using libsodium library at /usr/lib/aarch64-linux-gnu/libsodium.so
-- Using monero-project build: /home/woodser/git/monero-java/external/monero-cpp/external/monero-project/build/release
-- Found libunbound library: /usr/local/lib/libunbound.a
-- Configuring done
-- Generating done
-- Build files have been written to: /home/woodser/git/monero-java/build
make[2]: *** No rule to make target 'libmonero-cpp.a', needed by 'libmonero-java.so'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/monero-java.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Setting BUILD_SHARED_LIBS to OFF in monero-cpp and deleting the build directories creates the needed static monero-cpp.a.
Then the build fails during linking:
[ 50%] Building CXX object CMakeFiles/monero-java.dir/src/main/cpp/monero_jni_bridge.cpp.o
[100%] Linking CXX shared library libmonero-java.so
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): in function `sha1_block_armv8':
(.text+0x1240): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o):(.text+0x20): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_ADR_PREL_LO21 against symbol `poly1305_blocks' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): in function `poly1305_init':
(.text+0x40): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_ADR_PREL_LO21 against symbol `poly1305_emit' which may bind externally can not be used when making a shared object; recompile with -fPIC
(.text+0x48): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): in function `poly1305_emit_neon':
(.text+0x9a0): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): in function `sha256_block_data_order':
(.text+0xf88): dangerous relocation: unsupported relocation
/usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): in function `sha512_block_data_order':
(.text+0x1108): dangerous relocation: unsupported relocation
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/monero-java.dir/build.make:122: libmonero-java.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/monero-java.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

On macOS, I get this error:
[ 50%] Building CXX object CMakeFiles/monero-java.dir/src/main/cpp/monero_jni_bridge.cpp.o
In file included from /Users/woodser/git/monero-java/src/main/cpp/monero_jni_bridge.cpp:39:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_full.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_model.h:55:
/Users/woodser/git/monero-java/external/monero-cpp/src/daemon/monero_daemon_model.h:55:10: fatal error: 'boost/property_tree/ptree.hpp' file not found
#include <boost/property_tree/ptree.hpp>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Changing set(Boost_INCLUDE_DIR "${BOOST_PATH}/boost") to set(Boost_INCLUDE_DIR "${BOOST_PATH}") seems to get further, but fails on the error:
In file included from /Users/woodser/git/monero-java/src/main/cpp/monero_jni_bridge.cpp:39:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_full.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_model.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/daemon/monero_daemon_model.h:55:
In file included from /Users/woodser/git/monero-java/external/boost/boost/property_tree/ptree.hpp:21:
In file included from /Users/woodser/git/monero-java/external/boost/boost/multi_index_container.hpp:25:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/at.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/at_impl.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/advance.hpp:19:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/negate.hpp:17:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/integral_c.hpp:32:
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
    typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
                              ^
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                              ^
In file included from /Users/woodser/git/monero-java/src/main/cpp/monero_jni_bridge.cpp:39:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_full.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_model.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/daemon/monero_daemon_model.h:55:
In file included from /Users/woodser/git/monero-java/external/boost/boost/property_tree/ptree.hpp:21:
In file included from /Users/woodser/git/monero-java/external/boost/boost/multi_index_container.hpp:25:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/at.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/at_impl.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/advance.hpp:19:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/negate.hpp:17:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/integral_c.hpp:32:
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)

Hoping the errors can be resolved because it would be really great to build to portable, static libraries. :)

Setting BUILD_SHARED_LIBS to OFF in monero-cpp and deleting the build directories creates the needed static monero-cpp.a.

This is done in bin/build_libmonero_java.sh

Then the build fails during linking:

OpenSSL will have to become a module built with -fPIC. I will look into this.

Changing set(Boost_INCLUDE_DIR "${BOOST_PATH}/boost") to set(Boost_INCLUDE_DIR "${BOOST_PATH}") seems to get further, but fails on the error:

I will look into this

Then the build fails during linking:

@woodser , could you try to build again on Ubuntu 20.04 aarch64-linux-gnu?

I was able to build successfully on Ubuntu 20.04 aarch64-linux-gnu, but I'm still having trouble building on macOS, first failing on this error:
[ 50%] Building CXX object CMakeFiles/monero-java.dir/src/main/cpp/monero_jni_bridge.cpp.o
In file included from /Users/woodser/git/monero-java/src/main/cpp/monero_jni_bridge.cpp:39:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_full.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_model.h:55:
/Users/woodser/git/monero-java/external/monero-cpp/src/daemon/monero_daemon_model.h:55:10: fatal error: 'boost/property_tree/ptree.hpp' file not found
#include <boost/property_tree/ptree.hpp>

I'm confused why the build should work at all, including on Ubuntu, because set(Boost_INCLUDE_DIR "${BOOST_PATH}/boost") would use the full include path of ./external/boost/boost/property_tree/ptree.hpp, which doesn't exist.
By modifying CMakeLists.txt to set(Boost_INCLUDE_DIR "${BOOST_PATH}"), it's able to find the include path to the property tree, but then later fails on this error:
In file included from /Users/woodser/git/monero-java/src/main/cpp/monero_jni_bridge.cpp:39:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_full.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_model.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/daemon/monero_daemon_model.h:55:
In file included from /Users/woodser/git/monero-java/external/boost/boost/property_tree/ptree.hpp:21:
In file included from /Users/woodser/git/monero-java/external/boost/boost/multi_index_container.hpp:25:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/at.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/at_impl.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/advance.hpp:19:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/negate.hpp:17:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/integral_c.hpp:32:
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
    typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
                              ^
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                              ^
In file included from /Users/woodser/git/monero-java/src/main/cpp/monero_jni_bridge.cpp:39:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_full.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/wallet/monero_wallet_model.h:55:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/daemon/monero_daemon_model.h:55:
In file included from /Users/woodser/git/monero-java/external/boost/boost/property_tree/ptree.hpp:21:
In file included from /Users/woodser/git/monero-java/external/boost/boost/multi_index_container.hpp:25:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/at.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/at_impl.hpp:18:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/advance.hpp:19:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/negate.hpp:17:
In file included from /Users/woodser/git/monero-java/external/boost/boost/mpl/integral_c.hpp:32:
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
/Users/woodser/git/monero-java/external/boost/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)

I see that the monero-cpp is building boost and openssl with these paths instead of the submodules, wondering if that could be a problem:
-- Using Boost include dir at /opt/homebrew/include
-- Using OpenSSL found at /opt/homebrew/opt/openssl@3
-- Using OpenSSL include dir at /opt/homebrew/opt/openssl@3/include
-- Using libsodium library at /opt/homebrew/lib/libsodium.dylib
-- Using HIDAPI include dir at /opt/homebrew/include/hidapi

I'm confused why the build should work at all, including on Ubuntu, because set(Boost_INCLUDE_DIR "${BOOST_PATH}/boost") would use the full include path of ./external/boost/boost/property_tree/ptree.hpp, which doesn't exist.

It works because you have boost installed. You are write, I have fixed boost include path.

I see that monero-cpp is using boost and openssl with these paths instead of the new submodules, wondering if that could be a problem:

Whats the boost version installed on macOS?
monero-cpp and monero-project require boost >= 1.58.
monero-java, monero-cpp and monero-project should be built with compatible versions of boost.
I chose to use boost 1.71 because Ubuntu 20 uses this version.
I think yours macoS is using boost < 1.71.
If its true, We can force monero-cpp to require 1.71.

I have boost 1.84 installed through brew.

monero-java, monero-cpp and monero-project should be built with compatible versions of boost

Wondering again then if boost and openssl should be a submodule within external/monero-cpp/external, which both monero-java and monero-cpp build from?
This would be consistent with how monero-ts works, where boost [1] and openssl [2] are downloaded to external/monero-cpp/external .

Wondering again then if boost and openssl should be a submodule within external/monero-cpp/external, which both monero-java and monero-cpp build from?

Ok. I will try. But monero-project also use boost and openssl and maybe we dont have control of it.

Ok. I will try.

Maybe it's not necessary, and the boost versions merely need adjusted to be compatible, but I would think monero-cpp should be built with the same version as monero-java.

But monero-project also use boost and openssl and maybe we dont have control of it.

Don't know if the -fPIC difference could be a problem, but I'm not so well versed in this build stuff.

@woodser could you try to build on macos again?
You have to apply the patch woodser/monero-cpp#64

Hm, I still end up with these errors building monero-java with the new changes to this and monero-cpp:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/utils/gen_utils.cpp:53:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/utils/gen_utils.h:57:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/lexical_cast.hpp:32:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/lexical_cast/try_lexical_convert.hpp:43:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/lexical_cast/detail/converter_numeric.hpp:36:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/cast.hpp:33:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/converter.hpp:13:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/conversion_traits.hpp:13:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/detail/conversion_traits.hpp:18:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/detail/int_float_mixture.hpp:19:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/mpl/integral_c.hpp:32:
/Users/woodser/git/monero-java/build/install/include/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
    typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
                              ^
/Users/woodser/git/monero-java/build/install/include/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                              ^
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/utils/gen_utils.cpp:53:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/src/utils/gen_utils.h:57:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/lexical_cast.hpp:32:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/lexical_cast/try_lexical_convert.hpp:43:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/lexical_cast/detail/converter_numeric.hpp:36:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/cast.hpp:33:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/converter.hpp:13:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/conversion_traits.hpp:13:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/detail/conversion_traits.hpp:18:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/numeric/conversion/detail/int_float_mixture.hpp:19:
In file included from /Users/woodser/git/monero-java/build/install/include/boost/mpl/integral_c.hpp:32:
/Users/woodser/git/monero-java/build/install/include/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: integer value -1 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
/Users/woodser/git/monero-java/build/install/include/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)

I confirmed that the build succeeds from the master branches.

Could you past here or send me the full build output? I want to know if build is using boost lib from submodule or system.

Could you past here or send me the full build output? I want to know if build is using boost lib from submodule or system.

build.log

@woodser could you try again on macos and put the log here please?
You have to apply the patch https://github.com/woodser/monero-cpp/pull/64

It's failing to build boost with the latest changes to monero-java and monero-cpp:
build.log

This is the error:
./boost/unordered/detail/fwd.hpp:53:16: error: no member named 'piecewise_construct' in namespace 'std'; did you mean 'piecewise_construct_t'?
    using std::piecewise_construct;
          ~~~~~^~~~~~~~~~~~~~~~~~~
               piecewise_construct_t

Its related with the newer macOS plus boost 1.7x. See https://github.com/bambulab/BambuStudio/issues/3957
I will try to use 1.8x.
Anyway, I need to emulate macos env on linux. Any suggestion?

Yeah I saw that. I just updated my OS to the latest version, but it didn't help.
Using 1.8x sounds good, it's what I've been using in the libraries anyway.
I don't have any experience emulating mac in linux unfortunately.

Build failed on ubuntu-20.04 with boost 1.86. We need to update monero-project. See https://github.com/monero-project/monero/pull/9313

Ok, I'm in the process of updating to monero-project v<IP_ADDRESS> now.

Ok it's all updated to monero-project v<IP_ADDRESS>.

@woodser , build ok on ubuntu-20.04. Could you try again on macos?

Please resolve the merge conflict with master.

With the PRs applied to monero-java and monero-cpp (and the merge conflict resolved), and using the latest monero-project v<IP_ADDRESS> (pushed to my master at https://github.com/woodser/monero), I get these errors on building monero-project:
[ 44%] Building CXX object contrib/epee/src/CMakeFiles/obj_epee.dir/int-util.cpp.o
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/cryptonote_basic/cryptonote_format_utils_basic.cpp:31:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/cryptonote_basic/cryptonote_format_utils.h:33:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/cryptonote_basic/cryptonote_basic_impl.h:33:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/cryptonote_basic/cryptonote_basic.h:44:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/serialization/crypto.h:37:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/crypto/chacha.h:44:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/crypto/hash.h:37:
/Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/crypto/generic-ops.h:36:10: fatal error: 'sodium/crypto_verify_32.h' file not found
#include <sodium/crypto_verify_32.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 46%] Building CXX object contrib/epee/src/CMakeFiles/obj_epee.dir/portable_storage.cpp.o
1 error generated.
make[3]: *** [src/device/CMakeFiles/obj_device.dir/device.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
[ 46%] Building CXX object contrib/epee/src/CMakeFiles/obj_epee.dir/misc_language.cpp.o
[ 46%] Building CXX object src/cryptonote_basic/CMakeFiles/obj_cryptonote_basic.dir/cryptonote_basic_impl.cpp.o
1 error generated.
[100%] Built target generate_translations_header
make[3]: *** [src/device_trezor/CMakeFiles/obj_device_trezor.dir/device_trezor.cpp.o] Error 1
make[2]: *** [src/device_trezor/CMakeFiles/obj_device_trezor.dir/all] Error 2
[ 46%] Building CXX object src/blockchain_db/CMakeFiles/obj_blockchain_db.dir/lmdb/db_lmdb.cpp.o
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/ringct/rctSigs.cpp:35:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/common/util.h:48:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/crypto/hash.h:37:
/Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/crypto/generic-ops.h:36:10: fatal error: 'sodium/crypto_verify_32.h' file not found
#include <sodium/crypto_verify_32.h>

Here's the full build log:
build.log
monero-project succeeds to build if I run make release-static directly within the repo, so it must be related to building the full stack from ./bin/build_libmonero_java.sh .
I confirmed that the build succeeds by switching to the latest master branch of all 3 projects. To ensure the build is completely fresh, I first deleted the build directory of all 3 projects.

If I first build monero-project with make release-static directly in the repo, the build gets pretty far, only failing on the final linking step, due to undefined references to boost, which points the fact that different versions of boost being used. Feels like we're getting closer.

Sure, please resolve the merge conflict with master. :)

I'm confusing. There is no conflict. I've already resolved them.

I observed a merge conflict with this PR on this line, which changed in the last release: https://github.com/woodser/monero-java/blob/c0bd817662b23b924c203db87f1b455cc00547f5/CMakeLists.txt#L86
You should see GitHub indicates this message:

I think you just need to pull the latest master and git rebase master on your branch, then force push.

I resolved this conflict here: 4cb116abbf1a30070f841ae638c11ebc872af096.
See image, its the msg: "This branch has no conflicts with the base branch"

Hm, maybe squash your commits?

The question is why github show different msgs?

Hm, maybe squash your commits?

is it a problem?

The question is why github show different msgs?

Yeah it's strange. I don't know why, but GitHub won't even let me click the button to merge. Only thing I can think to do is squash your commits, which is worth a try.

The question is why github show different msgs?

Yeah it's strange. I don't know why, but GitHub won't even let me click the button to merge. Only thing I can think to do is squash your commits, which is worth a try.

ok, squash it then

You would need to squash it, since it's not ready to squash and merge yet :)

I did a merge commit to resolve the conflict.

The question is why github show different msgs?

Maybe "Allow merge commits" is disable in project config

You should be able to simply git reset --soft HEAD~9 and then git push --force to squash to a single commit.

Not exactly this because it has a conflict but done

If I first build monero-project with make release-static directly in the repo, the build gets pretty far, only failing on the final linking step, due to undefined references to boost, which points to the fact that different versions of boost are being used. Feels like we're getting closer.

This is how I test build:
# Make sure cloned branch is clean:
git clone -b sharedLibraryWrapper https://github.com/nsec1/monero-java.git
cd monero-java

# Update modules:
git submodule update --init --recursive

# Apply woodser/monero-cpp#64 patch
(cd external/monero-cpp && curl https://patch-diff.githubusercontent.com/raw/woodser/monero-cpp/pull/64.diff | patch -p1)

# buid all
./bin/build_libmonero_java.sh

I would like to see "Using OpenSSL libs: ..." and "Using Boost libs: ..." values on monero-cpp build output.

I applied your latest PR. Still getting the error I referenced above: fatal error: 'sodium/crypto_verify_32.h' file not found.
The error occurs while building monero-project, so it never gets to building monero-cpp and monero-java (and never prints "Using OpenSSL libs".
Here's the full log: build.log

do you have libsodium (with header files) installed?

I have libsodium with header files placed within monero-cpp/external, which is referenced within CMakeLists.txt in both monero-cpp and monero-java. The build is succeeding with this on master.

It does appear that monero-java and monero-cpp are using different locations for Boost and OpenSSL, which could explain a mismatch?

Yes, it could. CMAKE_PREFIX_PATH env var is not being exported for cmake executions in /bin/build_libmonero_cpp.sh on macos. It works on linux. I will try to force to pass this by parameter to cmake.

Deleting the build directories from monero-java, monero-cpp, and monero-project and rebuilding from the top-level monero-java yields the error: sodium/crypto_verify_32.h within monero-project, which only resolves by deleting its build directory and building standalone again.

How do you build standalone?
Try to build like this:
    (cd build/release && \
     cmake -D STATIC=ON -D BUILD_64=ON -D CMAKE_BUILD_TYPE=Release\
           -D OPENSSL_ROOT_DIR=/Users/woodser/git/monero-java/build/install -D CMAKE_PREFIX_PATH=/Users/woodser/git/monero-java/build/install ../.. && \
     make -j$HOST_NCORES wallet)

Thanks for your continued effort on this.
Getting an error with the latest changes while building monero-project:
In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/cryptonote_basic/connection_context.cpp:33:
/Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/p2p/p2p_protocol_defs.h:195:7: error: static assertion failed due to requirement 'std::is_pod<boost::uuids::uuid>::value': t_type must be a POD type.
      KV_SERIALIZE_VAL_POD_AS_BLOB(network_id)

Here's the full build log: build.log

How do you build standalone?

I can build monero-project standalone using make release-static directly within the monero-project directory.
I get the same error as above in monero-project by running your recommended command:
    (cd build/release && \
     cmake -D STATIC=ON -D BUILD_64=ON -D CMAKE_BUILD_TYPE=Release\
           -D OPENSSL_ROOT_DIR=/Users/woodser/git/monero-java/build/install -D CMAKE_PREFIX_PATH=/Users/woodser/git/monero-java/build/install ../.. && \
     make -j$HOST_NCORES wallet)

It does feel like we're close since the build has succeeded on Ubuntu, but I wonder if macOS emulation would help get us past this next step to ensure it builds there too.

Ok. I am looking into darlin to emulate macos.

I realized my last error was due to an error building monero-project v<IP_ADDRESS> (see https://github.com/monero-project/monero/pull/9450), but after fixing that, I'm back to the earlier error:
'sodium/crypto_verify_32.h' file not found

In file included from /Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/cryptonote_basic/connection_context.cpp:33:
/Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/p2p/p2p_protocol_defs.h:195:7: error: static assertion failed due to requirement 'std::is_pod<boost::uuids::uuid>::value': t_type must be a POD type.
      KV_SERIALIZE_VAL_POD_AS_BLOB(network_id)

I was able to reproduce this error on debian-test using clang. Then I downgraded boost to 1.84 and the build has succeeded.

Bounty bumped to 4 XMR.

@woodser , could you send me this command output:  export | grep CMAKE ?

It doesn't return any output.

Hey, happy to see more changes coming in. Please just let me know when it's ready for retesting.

I finally figured out what was happening with sodium include path. Monero-project considers that include path for sodium is the same for boost and openssl. Now with this PR, it is not true. I have to modify monero-project in my fork.
I have problems with macos emulation, cmake is stucking on darling for example. I emulated the problem installing monero dependencies using homebrew on linux.
I have kept Trezor support off because it failed to load Monero native libraries: java.lang.UnsatisfiedLinkError:  /tmp/libmonero15436476446366776625/libmonero-java.so: undefined symbol: _ZTIN6google8protobuf7MessageE.
Monero-cpp and monero-project are pointing to my branches in forked repos, to test more easily. We need change this before go upstream.
Dont run bin/update_submodules.sh because branches will back to master. Use git submodule update --init --force --recursive.
If your test were succeed on macos, I will send a PR to monero-project. For now, we could apply a patch of monero-project modifications in monero-cpp until PR merged and released.
I had to put libsodium as module in monero-java and build with -fPIC.
Could delete monero-cpp external/libsodium?
Using boost-1.84 (1.86 incompatible with monero).
I have tested haveno with native lib on linux. Hope this work on macos.

I'm hitting this error with your PR, which is probably related to your monero-project branch not having the latest fix for macOS:
/Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/src/p2p/p2p_protocol_defs.h:195:7: error: static assertion failed due to requirement 'std::is_pod<boost::uuids::uuid>::value': t_type must be a POD type.
      KV_SERIALIZE_VAL_POD_AS_BLOB(network_id)

monero-cpp/external/libsodium is being used in the monero-ts project.
Perhaps to move your libsodium solution within monero-cpp so it can be used by monero-ts as well?

Applying that fix from monero-project myself, I then get this error with your PRs:
/Users/woodser/git/monero-java/external/monero-cpp/external/monero-project/contrib/epee/include/span.h:165:5: error: static assertion failed due to requirement 'std::is_trivially_copyable<epee::mlocked<tools::scrubbed<crypto::ec_scalar>>>()': type must be trivially copyable

These errors are about boost-1.85+. I just downgraded boost to 1.84 in this solution because this.
Could you sent me a out log?

I would confirm it with output log but for now, could you try to remove boost from homebrew and do a clean build again?

I was able to finally successfully build libmonero-cpp.a and libmonero-java.dylib. :)
By downgrading to Boost 1.84 and by making these changes to CMakeLists.txt to include hidapi:  patch.txt
However, basic tests to execute the libraries through JNI are hitting an error.
To recreate the error, simply run the tests within TestMoneroUtils.java. They can easily be invoked by importing the project into Visual Studio Code (or Eclipse if you prefer):

I was able to finally successfully build libmonero-cpp.a and libmonero-java.dylib. :)
Cool!!

By uninstallingn boost through brew and by making these changes to CMakeLists.txt to include hidapi: patch.txt
Hidapi is needed only for Trezor support but it is off on monero build. I didnt understand  why it is needed on mac.
If we had to include hidapi on monero-java build (your patch), maybe it should become a module build with fPIC because it is dynamically linked.

However, basic tests to execute the libraries through JNI are hitting an error.
I will fix this.

Ideally we can keep existing hardware wallet dependencies, unless they are not already included? In which case, no need to add them as part of this PR.

Ideally we can keep existing hardware wallet dependencies, unless they are not already included? In which case, no need to add them as part of this PR.

No. if we keep existing hardware wallet dependencies (libs linked to libmonero-java.so), the host running monero-java application must have dependencies installed on.
For example, haveno running on host with no hidapi lib installed and using monero-java (this PR) build with hidapi linked (your patch) gets this error:
[ STARTING] WARN  haveno.core.xmr.wallet.XmrWalletService: Failed to load Monero native libraries: java.lang.UnsatisfiedLinkError: /tmp/libmonero8612716650094032596/libmonero-java.so: libhidapi-libusb.so.0: cannot open shared object file: No such file or directory
[ STARTING] WARN  haveno.core.xmr.wallet.XmrWalletService: Monero native libraries applied: false

At the moment there is just this problem, mac build needs hidapi. I didnt understand why because -D USE_DEVICE_TREZOR=OFF should do the job for all related dependencies.

I've released updates to monero-java and monero-cpp, and I'd like to retest this PR with the new updates. Maybe it could have fixed the previous error we saw? But can you rebase your PRs on master, please?

Ok, I will do this and move openssl and boost build to monero-cpp.

Done.
git clone --recurse-submodules -b buildStaticOption https://github.com/nsec1/monero-cpp.git

I have your latest changes applied to monero-java, monero-cpp, and monero-project, but I'm getting this linker error at the end of the build process:
[ 50%] Building CXX object CMakeFiles/monero-java.dir/src/main/cpp/monero_jni_bridge.cpp.o
[100%] Linking CXX shared library libmonero-java.dylib
Undefined symbols for architecture arm64:
  "boost::filesystem::detail::canonical_v3(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)", referenced from:
      tools::wallet2::store_to(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, epee::wipeable_string const&, bool) in libwallet.a[2](wallet2.cpp.o)
  "boost::filesystem::detail::weakly_canonical_v3(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)", referenced from:
      tools::wallet2::store_to(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, epee::wipeable_string const&, bool) in libwallet.a[2](wallet2.cpp.o)
  "boost::filesystem::detail::directory_iterator_construct(boost::filesystem::directory_iterator&, boost::filesystem::path const&, boost::filesystem::directory_options, boost::filesystem::detail::directory_iterator_params*, boost::system::error_code*)", referenced from:
      std::__1::__function::__func<mlog_configure(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool, unsigned long, unsigned long)::$_0, std::__1::allocator<mlog_configure(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool, unsigned long, unsigned long)::$_0>, void (char const*, unsigned long)>::operator()(char const*&&, unsigned long&&) in libepee.a[7](mlog.cpp.o)
  "boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_options, boost::system::error_code*)", referenced from:
      tools::copy_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) in libcommon.a[8](util.cpp.o)
  "_hid_close", referenced from:
      hw::io::device_io_hid::disconnect() in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_enumerate", referenced from:
      hw::io::device_io_hid::connect(unsigned int, unsigned int, boost::optional<int>, boost::optional<unsigned short>) in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_error", referenced from:
      hw::io::safe_hid_error(hid_device_*) in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_free_enumeration", referenced from:
      hw::io::device_io_hid::connect(unsigned int, unsigned int, boost::optional<int>, boost::optional<unsigned short>) in libdevice.a[6](device_io_hid.cpp.o)
      hw::io::device_io_hid::connect(unsigned int, unsigned int, boost::optional<int>, boost::optional<unsigned short>) in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_init", referenced from:
      hw::io::device_io_hid::init() in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_open_path", referenced from:
      hw::io::device_io_hid::connect(unsigned int, unsigned int, boost::optional<int>, boost::optional<unsigned short>) in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_read", referenced from:
      hw::io::device_io_hid::exchange(unsigned char*, unsigned int, unsigned char*, unsigned int, bool) in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_read_timeout", referenced from:
      hw::io::device_io_hid::exchange(unsigned char*, unsigned int, unsigned char*, unsigned int, bool) in libdevice.a[6](device_io_hid.cpp.o)
      hw::io::device_io_hid::exchange(unsigned char*, unsigned int, unsigned char*, unsigned int, bool) in libdevice.a[6](device_io_hid.cpp.o)
  "_hid_write", referenced from:
      hw::io::device_io_hid::exchange(unsigned char*, unsigned int, unsigned char*, unsigned int, bool) in libdevice.a[6](device_io_hid.cpp.o)
ld: symbol(s) not found for architecture arm64

Here's the full build.log: build.log
I confirmed that the build is working from the master branches and my release-v0.18 branch in monero-project, which includes a couple of custom commits.
Confirming this change should still be applied to monero-project?
commit ef2922ec64ca510027a0773ca54f79ba6e7acc4c (HEAD -> release-v0.18)
Author: nsec1<EMAIL_ADDRESS>Date:   Fri Sep 6 06:57:55 2024 -0300

    fix zmq and sodium include dirs search

Also I was wondering, is it necessary to checkout all of boost's submodules? There are so many of them :)

Here's the full build.log: build.log

It's the include path conflict. Monero project is using /opt/homebrew/include for boost and maybe /opt/homebrew/lib too.

Confirming this change should still be applied to monero-project?

Yes. It resolves include path conflict for zmq and sodium
Could you apply this patch to monero-project and build again? It is for printing INCLUDE_DIRECTORIES list.

I confirmed that the build is working from the master branches and my release-v0.18 branch in monero-project, which includes a couple of custom commits.

Did you use my monero fork? I can fork yours and apply my change.

Also I was wondering, is it necessary to checkout all of boost's submodules? There are so many of them :)

It is out of my control, comes from git module update. I would have track each module with its version. it don't worth.

I can fork yours and apply my change.

Yes please, if you can please submit a PR to my release branch here: https://github.com/woodser/monero/tree/release-v0.18. That's now the default for the libraries, since that's what they're based on.

I applied your patch manually (it wasn't included in your PR).
Here's the resulting log file: build.log

I applied your patch manually (it wasn't included in your PR).

It is for debug only, can be ignored.
I make a fix on monero-cpp build script. -D BOOST_IGNORE_SYSTEM_PATHS=ON can resolve include/libs conflicts on macos+homebrew. Could you try again?

I pulled in your commit to monero-cpp. Looks like I'm getting the same error, here's the full build log: build.log

I don't know what to do. Monero project is using boost from /opt/homebrew/include no matter what i do. Looks like homebrew has priority over other libs on cmake. Remove boost from homebrew is a workaround. Any suggestion??

I was able to build and run the libs, by uninstalling boost through brew, because as you said, it overrides and conflicts with the build boost.
I find that I must build with USE_DEVICE_TREZOR=ON or I get linker errors related to HIDAPI, e.g. "_hid_close". I'd like to make this the default and remove this option altogether, but you encounter build problems with it enabled?

@woodser , just thoughts, why not make monero-java by passing monero-cpp and wallet2, and connect directly with monero daemon rpc? It would be java only, no jni, no portable builds.

@woodser , just thoughts, why not make monero-java by passing monero-cpp and wallet2, and connect directly with monero daemon rpc? It would be java only, no jni, no portable builds.

monero-cpp and wallet2 would still need to be built native for the OS, and monero-java communicates with monero-cpp over JNI which also uses C++, so I don't see how this would circumvent native builds.

@woodser , just thoughts, why not make monero-java by passing monero-cpp and wallet2, and connect directly with monero daemon rpc? It would be java only, no jni, no portable builds.

monero-cpp and wallet2 would still need to be built native for the OS, and monero-java communicates with monero-cpp over JNI which also uses C++, so I don't see how this would circumvent native builds.

monero-java would not use monero-cpp nor wallet2, no C++, no jni, just java communicates directly to monero daemon rpc using http. Maybe have to re-implement some wallet2 features but maybe its worth.

@nsec1 the concern is speed. Statically linked binaries run far faster than any RPC.

@nsec1 the concern is speed. Statically linked binaries run far faster than any RPC.

Ok but wallet2 communicates to node daemon over rpc


Support for Route Record Indicator packets

When using the Python Xbee library in callback mode the callback thread crashes if it receives an API Route Record Indicator (type a1) packet.
Error: Unrecognized response packet with id byte \xa1
This then renders the python program dead as it is unable to process any further received packets.

Add supports to the Zigbee API dictionary for Route Record Indicator type packets.

Look st whether it is really necessary to break (therefore crash CB thread) if the library receives a packet type it does not know - should it rather just warn?

Jim

PR #15 fixes point 1.

Closing this issue as superseded by pull request #15.


How to put reacphp in nginx upstream

Is it possible to put reactphp process listening on some port in nginx upstream which is userd by fastcgi_pass
for example:
upstream
{
server localhost:5000 (reactphp)
server localhost:9000 (php-fpm)
}
so if react is avilaible it will use reactphp process, and if is not it will pass to php-fpm.
Also how to read fastcgi parameters in reactphp process?

https://github.com/garveen/fastcgi-react

I believe this has been answered and I'm closing this for now, please feel free to come back to this ticket with more details if this problem persists and we can reopen this :+1:


cmyk not reported in reflowable epub

A cover page in the cmyk colorspace is not reported as an error, it should be.

While I agree with you that CMYK images shouldn't be used and should be reported by EpubCheck, they are not disallowed by the EPUB spec (see EPUB Publications, Core Media Types. In fact, it doesn't even say something about color spaces at all.
That's why I filed a new issue for the EPUB spec: https://github.com/IDPF/epub-revision/issues/934

While I agree with you that CMYK images shouldn't be used and should be reported by EpubCheck, they are not disallowed by the EPUB spec (see EPUB Publications, Core Media Types. In fact, it doesn't even say something about color spaces at all.
That's why I filed a new issue for the EPUB spec: https://github.com/IDPF/epub-revision/issues/934

This has also been requested by another user of our pagina EPUB-Checker GUI. So I added a +1


Support creating prepared statements

Is your feature request related to a problem? Please describe.
When inserting a huge number of rows, a prepared statement could speed up the operations by skipping the compiler overhead. Currently there is no interface available to do this
Describe the solution you'd like
Add a way to create and execute prepared statements on all possible executors/connection combinations.

It looks like sqflite does not support preparing individual statements, so this API would not be available on all implementations.

When inserting a huge number of rows, a prepared statement could speed up the operations by skipping the compiler overhead. Currently there is no interface available to do this

A batch is doing exactly that! Across all implementations, it avoids re-compiling statements. Is this your primary use-case for prepared statements? Are batches missing something you need for performance?

I was under the impression that a batch.insertAll still just calls insert for every item and thus not pre-compile it

Internally, a batch keeps a set of a SQL statements that need to be prepared and a sequence of (statement, parameter) pairs to run. This is happening here, the method is called by all other methods on Batch.
The native database implementation will not prepare more statements than necessary, other implementations behave similarly:
https://github.com/simolus3/moor/blob/17d49fcc07102b193b8018f2daf6e2da9cd5709c/drift/lib/src/ffi/database.dart#L182-L200
I'll close this since batches should address the performance concern. If you have use-cases that require custom control over prepared statements please let me know and we'll figure out something that works for that.


Topics to be covered during the advanced tutorial.

Advanced topics

[ ] #121
[ ] #12
[ ] #124
[ ] #123
[ ] #122
[ ] #10

Python Libraries

[ ] numpy
[ ] scipy
[ ] matplotlib
[ ] seaborn
[ ] pandas
[ ] sympy
[ ] scikit-learn
[ ] ipywidgets
[ ] traitlets
[ ] numba
[ ] asyncio
[ ] ase
[ ] pymatgen
[ ] toml
[ ] yaml
[ ] pydantic
[ ] subprocess

I'm not sure if TOML & YAML deserve an entire morning. Definitely we can bundle them together.

And with this last library, we can officially close the issue. Congrats @baffelli, @despadam, @edoardob90, @fabioacl, @ramador09
I think we did a great job  🎉


How to return weights instead of binary numbers for PortfolioOptimizer

Hello,
I understand that the PortfolioOptimizer in Qiskit Finance/Optimization can solve quadratic programs such as minimum variance. Following the Qiskit Optimization tutorial. However, it returns binary integers on whether or not to select a stock. How do I change the class code to return a weight that each stock should hold within the portfolio?
https://qiskit.org/documentation/finance/tutorials/01_portfolio_optimization.html

Take a look at this, see if its what you need, which was done some time back Qiskit/qiskit-finance#57 - there is a unit test added which shows its use etc.

So to my understanding, we can find integer returns by using PortfolioOptimization.bounds. However, this becomes very costly? Is there a way to return float weights? Or am I misunderstanding something.

The portfolio optimization used to have only a buy or not result for each stock, and was changed to support integer amounts. This is the functionality it has.  Now the portfolio optimization code relies on Qiskit Optimization to solve the problem it defines, through the model it creates. You can potentially look at using Qiskit Optimization more directly to define a problem/model that more fits your needs and have it solve it.


lighter foldables

About the PR

reduced body bag size to 5 from 6
reduced rollerbed size from 25 to 15
Why / Balance

too heavy
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog
:cl: JoeHammad

tweak: Rollerbeds are now lighter

buh

DNM until Storage PR is figured out


Allow multiple groups of people to use tables within the same project without interference

probably going to make multiple tables for pro accounts


Configure travis

Currently the .travis.yml is missing.
c.f https://travis-ci.org/wikimedia/citolytics
See https://github.com/TU-Berlin/mathosphere/blob/master/.travis.yml for an example of that file.

added travis
fixed build


Fixes service name in docs

Coverage remained the same at 100.0% when pulling 4ff00a5b8f2770b5addb30485d09ff66bc3b3d87 on adri:patch-2 into d6e14cb04d620c8684601b0ed1172789d5802fce on overblog:master.


Fixed #29727 -- Run transform chain from setup_joins in resolv_ref

Added test for unresolvable join in F()

This requires a Trac ticket to describe the problem you are trying to fix.
Please see the contributing guidelines.

Sorry, forgot to put a reference to the ticket in the PR.

@felixxm thanks for the review, I broke it when I rewrote history but I've made the changes you suggested. Not sure why the first commit displays failed checks though :-/

@felixxm Ok I think I'm done

@alexh546 Thanks :+1: . IMO it is ready for the final review. Can you add a reference to the ticket in the last commit message? "Fixed #29727 -- ..."


travis ci build script

seems like travis is doing the right thing but test_tutorial.sh doesnt pass, locally or on travis

@tomecho, the output looks like the Java version is 1.8+. I can reproduce the error locally when executing the test_tutorial script under Java 8 -- it works fine under Java 7.

I think you need to set the language to java -- otherwise, the jdk setting will be ignored.

It looks like it wasn't necessary.


Info for npm package (v0.13.3) shows README from master (v1.0.0-beta3)

This can cause some confusion because the "What's it look like?" section has an example using 'react-router/lib/BroserHistory'.
$ npm v react-router version
0.13.3
$ npm v react-router readme|grep BrowserHistory
import { history } from 'react-router/lib/BrowserHistory';

Or just check https://www.npmjs.com/package/react-router

This is probably why so many people have been complaining about the missing BrowserHistory, by the way.

we broke from our conventions with the 1.0 branch, we'll get this stuff resolved and not make the mistake of a long-lived branch again.


KAFKA-5310: reset ControllerContext during resignation

This ticket is all about ControllerContext initialization and teardown. The key points are:

we should teardown ControllerContext during resignation instead of waiting on election to fix it up. A heapdump shows that the former controller keeps pretty much all of its ControllerContext state laying around.
we don't properly teardown/reset ControllerContext.partitionsBeingReassigned. This can cause problems when the former controller becomes re-elected as controller at a later point in time.

Suppose a partition assignment is initially R0. Now suppose a reassignment R1 gets stuck during controller C0 and an admin tries to "undo" R1 (by deleting /admin/partitions_reassigned, deleting /controller, and submitting another reassignment specifying R0). The new controller C1 may succeed with R0. If the controller moves back to C0, it will then reattempt R1 even though that partition reassignment has been cleared from zookeeper prior to shifting the controller back to C0. This results in the actual partition reassignment in zookeeper being unexpectedly changed back to R1.

@ijuma @junrao can you take a look?

@onurkaraman : Thanks for the patch. LGTM


feat: add meta tags

Description

added all the necessary meta tags to make SEO and search engine friendly 🚀
This PR fixes #26

Notes for Reviewers

add images where there is a <!-- replace with image --> comment, as I didn't had the images

Signed commits

[x] Yes, I signed my commits.

wrong pr, my bad

@ankityadavhere Great job. As for the images you want, you may use the "cart" logo from our existing hosting link

okay, making changes @sudhay23 👍

hey @sudhay23 , you should merge the folder structure pr cuz if I'll place an image in public folder, this index.html can't get the image until the folder is present, as the folder pr is not merged yet

okay ill add the cdn link, but it wont look good as it has a transparent bg 🤔

hey @sudhay23 , you should merge the folder structure pr cuz if I'll place an image in public folder, this index.html can't get the image until the folder is present, as the folder pr is not merged yet

That's fine I believe. Bring it to a working state on your machine after whwich all your commits can be merged

hey @sudhay23 , you should merge the folder structure pr cuz if I'll place an image in public folder, this index.html can't get the image until the folder is present, as the folder pr is not merged yet

That's fine I believe. Bring it to a working state on your machine after which all your commits can be merged

done changes!

Great then :)


Reproduce results on DarkZurich val set

Hi,
I am trying to reproduce the reported result on DarkZurich validation set: 36.76.
I used your codes and the same default training configs, and trained the model on a single Tesla V100 GPU with PyTorch 1.7.0. The validation miou is 34.86. Is this result in a reasonable variance range?

Update:
I visualized the images output by lightnet, it seems that the lightnet is not properly optimized.
Here are the original image, enhanced image and light image output by the trained model given in this repo:

Here are the original image, enhanced image and light image output by my reproduced model:

Is there any suggestions for this issue?
Thanks!

Hi @DeppMeng,
Actually, we didn't encounter this problem before. What about the performance on the test set?

Sorry for our late reply. We didn't save the training log into a file during training. Have you fixed the problem in the relighting part?

Yes, I re-ran the experiment again and the re-light network output is similiar to the enhanced image you provided. Don't know what causes the lightnet fail to converge in first trial. Maybe some instability in training?

Hi,
I am trying to reproduce the reported result on DarkZurich validation set: 36.76.
I used your codes and the same default training configs, and trained the model on a single Tesla V100 GPU with PyTorch 1.7.0. The validation miou is 34.86. Is this result in a reasonable variance range?
I had a similar problem,The validation miou is 34.38。

Hi,
I am trying to reproduce the reported result on DarkZurich validation set: 36.76.
I used your codes and the same default training configs, and trained the model on a single Tesla V100 GPU with PyTorch 1.7.0. The validation miou is 34.86. Is this result in a reasonable variance range?

I had a similar problem,the validation miou is 34.86。

Yes, I re-ran the experiment again and the re-light network output is similiar to the enhanced image you provided. Don't know what causes the lightnet fail to converge in first trial. Maybe some instability in training?

@DeppMeng Hi, is your experiments results is exactly the same with the authors? My lighting effect is align with authors' in general but seems the color is tend to be green rather than blue.


Add definitions for Electricity Trading API

Add some protobuf definitions necessary for the Electricity Trading (and for Ancillary Services Market).
This folder structure is a proposal, if anyone is against it for whatever reason, please suggest another folder structure that you would consider better.
FYI @thomas-nicolai-frequenz @tiyash-basu-frequenz @frequenz-floss/api-electricity-trading-team

I guess there was already some design discussion around this, but I will mention it just in case. I wonder if it would be better to split this repo (or start new ones) based on functionality. Like having a api-common-migrogrid, api-common-trading, otherwise people only wanting to use common stuff for the microgrid will need to pull common code for all APIs, which could be a bit overkill.
Also in the future it could be harder to maintain, because if, for example, you need to make a breaking change in the DeliveryDuration, we'll need to create a new major release that will affect also the api-microgrid (and each and every API out there), when the breaking change doesn't affect it at all, and probably only affect a handful of APIs.

Like having a api-common-migrogrid, api-common-trading, otherwise people only wanting to use common stuff for the microgrid

@llucax this would lead to a hell lot of duplicated code e.g. microgrid and reporting API

you need to make a breaking change in the DeliveryDuration, we'll need to create a new major release that will affect also the api-microgrid (and each and every API out there), when the breaking change doesn't affect it at all, and probably only affect a handful of APIs.

Yes and its good like that because otherwise you do not break it on the protobuf level but on the logical level. These things have to stay aligned!

Like having a api-common-migrogrid, api-common-trading, otherwise people only wanting to use common stuff for the microgrid will need to pull common code for all APIs, which could be a bit overkill.

Why not import just the relevant subdirectories from the common repo? Also, is the overhead of including all the common specs too much? It is (as of now) a relatively small protobuf library, and the packaging structure should help users understand the scopes of its protobuf messages well enough.
Also, hypothetically speaking, if we ever head towards splitting up this repo, I'd be in favour of adding definitions to frequenz-api-microgrid instead of creating api-common-microgrid.

Also, hypothetically speaking, if we ever head towards splitting up this repo, I'd be in favour of adding definitions to frequenz-api-microgrid instead of creating api-common-microgrid.

lol very good point!

@camille-bouvy-frequenz since we are adding a new package here, I'd recommend adding market/____init__.py to this directory: https://github.com/frequenz-floss/frequenz-api-common/tree/v0.x.x/py/frequenz/api/common/v1

@thomas-nicolai-frequenz I get an error in the packages import because google/type/decimal.proto is not found. It seems like is not explicitly listed as part of the googleapis-common-protos package. Should we then directly include it in the repo?

@camille-bouvy-frequenz you need to do the following to get access to the Decimal type:

Remove the submodule api-common-protos
Add this repo as a submodule: https://github.com/googleapis/googleapis, but please use the name api-common-protos, to keep this as a non-breaking change for now. I will then create a separate issue to rename this submodule and add it to the next major release milestone.

@llucax this would lead to a hell lot of duplicated code e.g. microgrid and reporting API. they are almost using the same. Also with regards to the Platform Assets API, this API is (re-)using almost everything from all the other APIs. Splitting this all up will also lead to a lot of inconsistencies between the various APIs over time.

I didn't mean to duplicate stuff, but have a more hierarchical dependency tree, so api-trading-common would use api-microgrid-common, and both a api-common for example. Anyway, maybe it's too soon and a flat structure can help us move faster at first, but I think this will eventually need to happen.

Also, hypothetically speaking, if we ever head towards splitting up this repo, I'd be in favour of adding definitions to frequenz-api-microgrid instead of creating api-common-microgrid.

Maybe, the issue with that is if you just want to import a message for Component, you'll end up pulling the whole gRPC interface too, which is overkill. Maybe at some point we need to split gRPC interfaces from protobuf messages.
But yeah, the more I think about it, the more I believe it is too soon to split stuff beyond the protobuf/python split.

@tiyash-basu-frequenz Ok thanks this worked! I am still getting a mypy error caused by missing type stubs for the google.type.decimal_pb2 module. I looked it up a bit so far and the only solution I was able to find so far is to manually create them. Do you know of a better fix?

I am still getting a mypy error caused by missing type stubs for the google.type.decimal_pb2 module. I looked it up a bit so far and the only solution I was able to find so far is to manually create them. Do you know of a better fix?

I looked into it briefly, and I could not find a solution that uses existing stubs. Perhaps it would be better idea to add an exception for this specific type for now, to unblock this PR.
@llucax any thoughts?

Having a look now.

I'm finding too many issues with the switch of submodule, for example in the new submodule I can't find any timestamp.proto file, which we are currently using.

OK, now I am really confused. Some observations to discuss (I put them there so I don't forget).

google/protobuf/timestamp.proto doesn't live in googleapis/api-common-protos either. It seems to live in the protobuf Python package, so I guess it is part of the base protobuf definitions, even when it is under the google/ namespace.

We are only using timestamp.proto from the google namespace up to this PR, so I'm not sure why we were including the submodule in the past.

Type checking with mypy worked so far because we are using the mypy-protobuf package (provided indirectly by repo-config).

We are using the googleapis-common-protos python package to provide defnitions of googleapis/api-common-protos. This package is provided by Google.

googleapis-common-protos doesn't provide any type information for mypy.

There is a googleapis-common-protos-stubs Python package providing the mypy typing info but it's not done by Google and it doesn't look super healthy according to Snyk [^1].

google/types/decimal.proto is present in googleapis/googleapis but not in googleapis/api-common-protos.

The contents of the googleapis-common-protos is weird. It includes google/types/decimal.proto which is not included in googleapis/api-common-protos, but it doesn't nearly include everything in googleapis/googleapis either.

So the situation looks pretty ugly. I can see a few of paths forward:

Leave things are they are now and just add the googleapis-common-protos-stubs package to the dependencies here (googleapis-common-protos-stubs == 2.2.0).
Build all python bindings from google protobufs ourselves (in this or a separate repo), including mypy type info.
Remove all dependencies from Google and copy decimal.proto to this repo.

Option 1 is probably the simplest and more straightforward, but we are not making this mess any better, if any, maybe a bit worse because we keep adding dependencies, and one that is not official and we don't know how well maintained it is.
Option 2 seems a bit overkill and a lot of work.
Option 3 seems to be the best IMHO, it will simplify a lot this repo and it shouldn't be much work.
If we want to unblock this PR, I'd suggest option 1 for now, I just checked and nox passes all tests with this diff applied:
diff --git a/pyproject.toml b/pyproject.toml
index 681d206..ffb44bb 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -56,2 +56,3 @@ dev-mypy = [
   "mypy == 1.7.1",
+  "googleapis-common-protos-stubs == 2.2.0",
   "grpc-stubs == <IP_ADDRESS>",

[^1]: Not many users and not updated often, but that could only be because there is still not a very wide adoption of type hints in Python and because the proto definitions don't change ofter, so there is no need for updates. But we might consider to build our own if we need to.

google/protobuf/timestamp.proto doesn't live in googleapis/api-common-protos either.

Indeed, you don't need a submodule for google.protobuf types (explained in more details here)

Thanks @llucax
I think option 1 is the path of least resistance for now.

One more option would be to replace the decimal type with our own definition:
message Decimal {
  int64 integer_part = 1;
  int32 scale = 2;
}

As we discussed the 1st option will be implemented for now (i.e adding the googleapis-common-protos-stubs package to the dependencies). Some alternatives to having the decimal.proto file from the googleapis/googleapis submodule will be discussed in another issue.

@camille-bouvy-frequenz you just need to rebase, and this should be good to go!

I think option 1 is the path of least resistance for now.

Yup, I opened a couple of issues to be addressed in the future:

#151
#152


Skip Associating Contacts form Address Book

Associating the contacts from the address book should be something the user can skip.
The contact name, in this case, will be taken as the wallet name.
The Encryption Key will be an OTP that the requested app generates.
The receiver does not need to associate as they don't need any encryption key anyway.

While Skip Contact we need it for Keeper request as well as F&F request. This applies for both the Requester and Receiver.

The Requester send the wallet name along with the request. If the Requester skips contact, first name = F&F request, last name = awaiting. Else take from phone address book
If the Receiver skips contact, first name: Requester Wallet name + “’s”, last name: ‘wallet’ else take the name from the phone address book
The Receiver sends back the wallet name along with all other details.
If the Requester had initially skipped contact association then replace the first name and last name with Receiver wallet name + “‘s” + “wallet”

@hemants


[ADD] Change Hessian to purely PyTorch

Only review after #142

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

11 of 16 (68.75%)  changed or added relevant lines in 2 files are covered.
59 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-1.1%) to 88.61%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

curvlinops/utils.py
3
8
37.5%

Files with Coverage Reduction
New Missed Lines
%

curvlinops/_base.py
3
84.4%

curvlinops/examples/utils.py
10
31.25%

curvlinops/fisher.py
46
26.47%

Totals

Change from base Build<PHONE_NUMBER>9:
-1.1%

Covered Lines:
1517

Relevant Lines:
1712

💛  - Coveralls


Error when running python load_into_pg.py -d stackoverflow -s pgload

Hi Team,
Could you please help me with the below error when trying to run  python load_into_pg.py? Am I missing something?
Traceback (most recent call last):
File "load_into_pg.py", line 413, in
import libarchive
File "/home/pgadminuser/.local/lib/python2.7/site-packages/libarchive/init.py", line 1, in
from .entry import ArchiveEntry
File "/home/pgadminuser/.local/lib/python2.7/site-packages/libarchive/entry.py", line 6, in
from . import ffi
File "/home/pgadminuser/.local/lib/python2.7/site-packages/libarchive/ffi.py", line 108, in
errno = ffi('errno', [c_archive_p], c_int)
File "/home/pgadminuser/.local/lib/python2.7/site-packages/libarchive/ffi.py", line 95, in ffi
f = getattr(libarchive, 'archive_'+name)
File "/usr/lib/python2.7/ctypes/init.py", line 379, in getattr
func = self.getitem(name)
File "/usr/lib/python2.7/ctypes/init.py", line 384, in getitem
func = self._FuncPtr((name_or_ordinal, self))
When running the below command it all seems ok.
pip install -r requirements.txt
Collecting argparse==1.2.1 (from -r requirements.txt (line 1))
Collecting distribute==0.6.24 (from -r requirements.txt (line 2))
Collecting libarchive-c==2.9 (from -r requirements.txt (line 3))
Using cached https://files.pythonhosted.org/packages/23/16/622ae829e9c1795479df865bbcbb4e7e3990f3e451e440f00bf1615be7fc/libarchive_c-2.9-py2.py3-none-any.whl
Collecting lxml==4.5.2 (from -r requirements.txt (line 4))
Using cached https://files.pythonhosted.org/packages/d1/2d/642ef7013aa56af52e14b5b7d53c5d591e6d038c9688e06d0f2a20ed26b2/lxml-4.5.2-cp27-cp27mu-manylinux1_x86_64.whl
Collecting psycopg2-binary==2.8.4 (from -r requirements.txt (line 5))
Using cached https://files.pythonhosted.org/packages/97/2a/b854019bcb9b925cd10ff245dbc9448a82fe7fdb40127e5cf1733ad0765c/psycopg2_binary-2.8.4-cp27-cp27mu-manylinux1_x86_64.whl
Collecting six==1.10.0 (from -r requirements.txt (line 6))
Using cached https://files.pythonhosted.org/packages/c8/0a/b6723e1bc4c516cb687841499455a8505b44607ab535be01091c0f24f079/six-1.10.0-py2.py3-none-any.whl
Installing collected packages: argparse, distribute, libarchive-c, lxml, psycopg2-binary, six
Successfully installed argparse-1.2.1 distribute-0.6.24 libarchive-c-2.9 lxml-4.6.2 psycopg2-binary-2.8.4 six-1.10.0
Thank you,
Florin

It looks like a libarchive installation issue; that it couldn't probably find archive_7z for loading. The first line of the Traceback should contain the exact error.
Are you trying to run this on Windows or OSX?
If so, getting it to run inside Docker maybe easier than trying to install the dependencies directly.

Hi,
Thank you for your message. No, I am running inside ubuntu machine. Tried on multiple VMs, getting same error.
Could you please provide me the steps on how to run it inside of a container?
Florin

Curious.
On your Ubuntu machine, can you try:
sudo apt-get install libarchive-dev

and then try running the script again? If that fails, it may be necessary to give an explicit path to libarchive*.so files via the LD_LIBRARY_PATH environment variable while running the script.
I personally do not run it in a container because I'm able to install all the dependencies.


Create an API for plugin-defined text translations

This PR expands the translatable interface to be more friendly to server-side translations. It also lays the groundwork for making every string in SpongeAPI translatable. This API moves the change from untranslated string to translated string from wherever the Text is created to directly before the text is sent to the CommandSource.
Miecraft's resource pack client-side strings are still supported, but not recommended because usage is more complicated.

Why have you removed Locales?

The built-in Java Locale is sufficient, Fields

@kenzierocks This list contains an exact and unlike Java's also complete list of locales available in Minecraft, which can be used to detect the language the client is using

True.

@Minecrell that's called player.getLocale()... And the complete list of locales available is in some standards document somewhere. I don't really see any use cases for maintaining a list of possible MC languages.

@zml player.getLocale() returns the player's currently selected Minecraft locale, which can be - unless added by resource packs - only one of these in the list. You could find a lot of parts in the API you could remove with the reason "a complete list is available somewhere". The Minecraft wiki maintains lists for most things available in Minecraft.
At the end, we're creating an API that's supposed to be easily usable, so providing additional convenience for the API user is nothing bad. With this class you don't need to Google first, you can simply check the player's locale from one of the default locales available in Minecraft.
As a side note: some of the Minecraft locales are not standardized, because there are no exact specifications for some languages. Due to this, Minecraft has also changed locale codes in the past which would result in breaking plugins which is definitely something we want to prevent as much as possible. Maintaining this list (actually generated automatically from Minecraft's resource index) requires almost no effort together with a Minecraft update, but additional effort from plugin developers without this automation.
Additionally I think this removal is really out of scope for a PR for plugin-defined translations, this should be discussed in a separate issue.

is there an instance in which this list would be actually be used? Because I can't think of any?

If implemented properly you can use it like player.getLocale() == Locales.PIRATE_ENGLISH or registry.getTranslation("translation.test.none").get(Locales.KLINGON) (which would only work on the client)

However, nobody should be using fixed locales. You'd never get a translation for a specific Locale, you almost never compare a locale using the Locale instance (instead using its toString to get a strings file) -- your use cases are not particularly realistic.

Simply because it does not seem useful if you code a generic, well configurable plugin does not mean there are no use cases at all. For custom plugins there are often things hardcoded that are really unlikely to change, and even if you just use it for debugging. Keep in mind in theory you could also use it for a configuration to provide an easier way to configure locales with the name instead of their locale codes.

so you're saying just because it's not useful for well-written plugins, it might be useful for badly-written plugins? Why should we be supporting anything but well-written plugins?

@zml2008 This discussion is getting more and more off-topic, you can't see "well-written" plugins from a generalized view, it always depends on which environment and which people a plugin is developed for. For a custom plugin where direct configuration isn't that important (as it will almost never change) implementing a complex configuration would be wasted time. Just because something is hard-coded, doesn't directly mean it's not a "well-written" plugin.
As for the removal of Locales, this is really out of scope for this PR so feel free to open another issue so we can discuss this any further. At the end, it doesn't hurt if this stays in the API just because it doesn't have many use(r)s. I'm sure there will be situations where people will be glad when they can simply test with the Locales directly instead of having to find out the exact locale code mapping as used in Minecraft first.

You know you still haven't given any specific use cases for this. Every program that supports localizations does it through resource files. We have the advantage of having Java's standard library which has user-friendly name mappings for most Locales, and resource file lookup is done using the locale codes.
Anyway, special-purpose plugins that you're referring to generally don't have localizations at all -- having a translated plugin at all requires a multilingual dev and/or a large enough audience to crowdsource translations.
I don't really see the point in splitting this into a separate PR at this point -- might as well just go for a yes/no on keeping Locales @Zidane?

@zml2008 how are we going to handle the eventual addition of client side plugins?
as these might have additional translations that aren't serverside

They can either have resource bundles clientside and use translation instances from the GameRegistry (which still do translations clientside, since we don't have all languages serverside), or have all messages in a ResourceBundle and just do the translations on whatever side the code that sends the message is on (I don't think there's much/any client->server sending of translation strings though).


Have you another payment method?

I try to buy it:
https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S
But have an error on paypall. "The seller does not accept Your card"
I try 2 diferent card (visa & master) - the same error.
Have you another payment method?

Ask WrapBootstrap.com about your problem, AdminLTE is not from WrapBootstrap.
Mit freundlichen Grüßen
Raphael Jackstadt
Von meinem iPhone gesendet

Am 12.01.2017 um 15:21 schrieb Максим<EMAIL_ADDRESS>I try to buy it:
https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S
But have an error on paypall. "The seller does not accept Your card"
I try 2 diferent card (visa & master) - the same error.
Have you another payment method?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

i try to buy AdminLTE premium template. So i want know  - can i do it without WrapBootstrap. Becouse WrapBootstrap - have only one payment method and it does not work.

AdminLTE is a Free Premium Admin Control Panel Theme.
INSPINIA isn't from AdminLTE's Creator, i think you are wrong here.
Mit freundlichen Grüßen
Raphael Jackstadt
Von meinem iPhone gesendet

Am 12.01.2017 um 18:26 schrieb Максим<EMAIL_ADDRESS>i try to buy AdminLTE premium template. So i want know - can i do it without WrapBootstrap. Becouse WrapBootstrap - have only one payment method and it does not work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

This is site: https://almsaeedstudio.com
This is support link on this site: https://github.com/almasaeed2010/AdminLTE/issues
This is premium template page on this site: https://almsaeedstudio.com/premium

INSPINIA isn't from AdminLTE's Creator

Really?

Hello,
INSPINIA is sponsored by Almsaeed Studio but its authors are a completely different group that otherwise has no association with Almsaeed Studio. We apologize for the confusion! You may contact the authors of INSPINIA using the form on this page: https://wrapbootstrap.com/user/WebAppLayers (you may need to sign up first).
Thanks!


[FEATURE] Mistral Support

Is your feature request related to a problem? Please describe.
Support for Mistral AI model:

https://mistral.ai/news/announcing-mistral-7b/
https://huggingface.co/mistralai/Mistral-7B-v0.1
https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.1

Describe the solution you'd like
Run the quantization example in the README file, using pretrained_model_dir = "mistralai/Mistral-7B-Instruct-v0.1", without failure.
Describe alternatives you've considered
Additional context
I never contributed but I would be happy to help with this task, if I can.

the bloke and openerotica have done it so it's definitely possible but whatever they used to quant it doesn't seam to be public

I used Transformers to make the GPTQs, not AutoGPTQ.  Mistral GPTQs can't be made with or loaded by AutoGPTQ until support is added to AutoGPTQ itself.  This would be very easy to do, but no-one has done it yet.

the bloke and openerotica have done it so it's definitely possible but whatever they used to quant it doesn't seam to be public

I did the quant for openerotica. I just changed model type to llama in the model's configuration file and it worked.


create twitter bot that responds to people

with the data from their provided date

working on it in this repo: https://github.com/co2birthdate/twitter-reply-bot


Left shoulder yaw and camera tilt not coherent between robot and model

Today @GiulioRomualdi and @mebbaid spotted that there is a mismatch in the direction of the shoulder yaw joint and the camera tilt between the model and the robot.
This was spotted comparing the motion in Gazebo and the real robot when increasing the value of the joint from yarpmotorgui.
Here for example is the comparison for the shoulder:
https://user-images.githubusercontent.com/35487806/217552978-82aedd43-ec9c-40c4-9bbd-cacecf55c1bd.mp4
All the other joints have been checked and are coherent.
cc @pattacini @Nicogene @sgiraz

Thanks heaps for reporting!

Hi @mfussi66,
We need first to understand what is the intended correct direction of the rotation and then fix either the robot XML file or the URDF.

We need first to understand what is the intended correct direction of the rotation and then fix either the robot XML file or the URDF.

By checking within Gazebo, that the URDF needs changing. The camera should tilt upwards with a positive angle, to be consistent with the head pitch.

to be consistent with the head pitch.

True.
Sorry for being nitpicking but what is the direction of movement of the iCub eyes with respect to the head pitch? Just to understand our "heritage".

Sorry for being nitpicking but what is the direction of movement of the iCub eyes with respect to the head pitch? Just to understand our "heritage".

In Gazebo iCub3 moves neck pitch and eyes tilt in opposite directions, see:

Not sure if it's the same on the robot.

Regarding the shoulder yaw, I think that also needs a fix at the URDF level, since the iCub3 Gazebo model is consistent with the real ergoCub (assuming Gazebo iCub3 and real iCub3 are consistent between each other).

Sorry for being nitpicking but what is the direction of movement of the iCub eyes with respect to the head pitch? Just to understand our "heritage".

In Gazebo iCub3 moves neck pitch and eyes tilt in opposite directions, see:
Not sure if it's the same on the robot.

Thanks for checking 👍🏻
The physical iCub 2.x is aligned with iCub in Gazebo as there's a number of software working on both the domains correctly.
Just an example:

https://github.com/vvv-school/assignment_make-it-roll

This doesn't mean that we need to copy out the same directions on ergoCub though.


[GHSA-9c47-m6qq-7p4h] Prototype Pollution in JSON5 via Parse Method

Updates

Affected products

Comments
Patched version 1.0.2 is missing.

Hi there @jdgregson and @jordanbtucker! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.
This change will be reviewed by our highly-trained Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

Duplicated by https://github.com/github/advisory-database/pull/1548


Use range_keys instead of range where value is not needed

We have a few cases where something like .map(|(k, _)| k) is done, i.e. drop the value as part of an iteration. CosmWasm 1.3 adds the ability to iterate over keys directly. In 1.4 this becomes very efficient. We should use it in this codebase whenever applicable.

I found one internal usage in Prefix::keys_raw which is easy to change.
There is also one in Prefix::keys, but it converts them using de_fn_kv before mapping, which takes the full key-value-pair as argument, so I am not sure this can be changed in a non-breaking way.

keys

Let's just schedule this for 2.0

I started digging into the Prefix::keys part of this.
This is made difficult by the way some storage items seem to require values to be deserialized so that they know how to deserialize the keys (???). I don't think I understand this whole machinery.
As a crutch, I could try to make providing a de_fn_k function to Prefix optional and see if things can work out like that. It feels like piling workarounds on top of a bad design though.
Have there been any discussions around rewriting storage-plus lately?


The timer handling changed in the ESP32 Arduino libraries, see docume…

Hiya,
The timer handling changed in the ESP32 Arduino libraries, see documentation:  https://docs.espressif.com/projects/arduino-esp32/en/latest/api/timer.html
I have adjusted the code so it compiles again. I was building Aciduino when I discovered the issue.
Cheers,
Ron

Hi @rdridder ,
Thank you for test, debug and fixes.
Can you tell me your environment setup?
Arduino core for the ESP32:
Arduino IDE version:
ESP32 Module:
Everytime a new change on uClock or uCtrl happens, i do some tests on the microcontrollers officially supported before a new release. Since there are tons of ESP32 different models, some of then could not be fully compatible yet, so a solution that don't break old ones and bring new models to support list is what we are trying to achieve.

Hi @midilab,
I am using Windows 11, version 23H2 (OS Build 22631.4317)
Arduino core for the ESP32
Version: 3.0.5
Arduino IDE
Version: 2.3.3
Date: 2024-09-25T09:41:18.242Z
CLI Version: 1.0.4
ESP32 Module
It is basically an ultra cheap model from AliExpress, I will try to list as much info as I have below.
Engraved on chip: ESP32-WROOM-32D
Back of board: ESP32_Devkitc_V4

Please let me know if you require more information.
Have a great evening,
Ron


Geotiff conversion - output resolution does not match the model run

Greetings!
I have started using the PostWRF recently and I must admit that it is a really useful tool for quick model data processing!
Ive been using it for couple of days, however I ran into a problem when exporting the data into geotiff format. The resolution of all exported tiffs suddenly does not match the resolution of the model output for all domains. For example, parent domain with model resolution of 5 km have 8 km raster resolution as geotiff and nested domain with 1,5 km have also the resolution of about 8 km (in ncview and other SW the resolution is correct). The generated tiffs have correct space coordinates and data, despite the resolution, apparently match the timeframe.
The same error also occurs with other WRF model runs, which previously worked correctly and even after reinstalling the PostWRF from scratch. Only "WRF CONVERT TO GEOTIFF" part of namelist.wrf was edited according the documentation.
Am I missing something obvious or is it some kind of error?
Best regards.

Hi @Tomo1583
No matter what is the resolution of the WRF output, GeoTIFF images from PostWRF will be generated based on 0.1 degree (about 9km on mid-latitudes). However, this issue will be updated in the next version of PostWRF to conform to the original resolution of the WRF output.

A new capability has been added to PostWRF to handle this issue.
You can git pull or clone PostWRF again. In the Geotiff section, a new parameter (tiff_resolution (km)) has been added. You can set it to your desired value (10 km, 20 km, etc.).
If you set tiff_resolution (km) = 0, the output tiff files will be made in the same resolution of the original WRF output.


Remove zombie autoheal

Hmm. I think this issue isn't fixed by simply removing functionality from Zombieland.

Instead of pulling this, I added some conditional code to Zombieland. Thanks for the effort nevertheless!

I didn't figure you'd want to merge this.  I just made the pull request so it would be easy for you to see the changes I made and could figure out how best to actually solve the problem, since I'm not particularly familiar with your code base.

Ok. What is the motivation behind taking away the force-die on incapacitated zombies?

If I understand the mechanic correctly, it is possible for them to be immobile due to an injury that will heal, such as a broken bone.  In practice, it probably doesn't make much of a difference, since usually they're bleeding enough by that point to die before they become mobile again, or end up dying from an infection.  But if you were to use a mace or club to down one, this would let them get back up eventually.

Not exactly. The point here is that if you have auto-healing to simulate “double tap” like in the movie, any zombie that has an injury, like a missing leg that does not heal, will stay alive forever. So instead of cluttering the map with alive but immobile zombies, the mod simply kills them.

Right, that makes sense.  The question is how to detect when the lack of mobility is from an injury that won't heal vs from something that is temporary, without significantly impacting performance.  There are enough zombies that killing a few who would recover is probably not a big deal, so it probably makes sense to just eliminate them if they can't move.


Forms: Add placeholder with actual value to form field

Overwrite normal bootstrap "floating" behavior to show acutal placeholder value instead of label for input.

closed with 5b7351a


feat(heatmap_visualizer): add heatmap visualizer

Signed-off-by: Kotaro Uetake<EMAIL_ADDRESS>Description

Add heatmap visualizer to visualize heatmap of detected objects' position

Related links

Tests performed

After starting autoware, run this command
ros2 launch heatmap_visualizer heatmap_visualizer.launch.xml input/objects:=perception/object_recognition/detection/objects

Notes for reviewers

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@yukkysaito I'm sorry to late to update description of this package. Please re-review.

@ktro2828
I have some questions :pray:

What do heat maps mean? (existence probability?)
Can it subscribe to any topic of DetectedObjects type like a clustering output?
When should we use this?

@yukkysaito Thanks for quick reply!

What do heat maps mean? (existence probability?)

We create heatmap by accumulating poistions of bounding boxes on each gird map cell, by defaults. However, we have option to create heatmap from existence probability, it can be selected with use_confidence.

Can it subscribe to any topic of DetectedObjects type like a clustering output?

Currently, No. It only can subscribe autoware_auto_msgs.msg.DetectedObjects. Should we support the other msg types, like tier4_perception_msgs.mgs.DetectedObjectsWithFeature?

When should we use this?

This package is assumed to use for detection trend analysis of the detector. For instance, the heatmap shows "this detector can perform good for the objects near arround of our vehicle, but for far arround is bad".


Authorization Bearer Token Issues ...

Bug Report
Step 1:Running svix-server in Docker
File: docker-compose.yml
image: svix/svix-server
environment:
      WAIT_FOR: "true"  # We want to wait for the default services
      SVIX_JWT_SECRET: "<secret>"
      SVIX_REDIS_DSN: "redis://redis:6379"
      SVIX_DB_DSN: "< ... >"

Used config.toml while `docker compose up`.

I am able to run the server with docker compose up
Step 2: Generation of JWT token
$ docker exec -it server-backend-1  /bin/bash
appuser@f731ad956895:/$ svix-server jwt generate

Token (Bearer):  Token was generated.

Step 3: Token verification
Using https://jwt.io/ , the token was verified.

Payload:
{
  "iat":<PHONE_NUMBER>,
  "exp":<PHONE_NUMBER>,
  "nbf":<PHONE_NUMBER>,
  "iss": "svix-server",
  "sub": "org_23rb8YdGqMT0qIzpgGwdXfHirMu"
}

Step 4: Application creation using curl.
curl -X 'POST' 'https://api.vidcentum.com/api/v1/app/' \
  -H 'Authorization: Bearer  <TOKEN GENERATED in Step 2 above using svix-server jwt generate ' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
    "uid": "vt-ai-api-app",
    "name": "VT AI Application",
    "rateLimit": 1000
}'

Expected Behavior: Creation of Application
Actual behavior: {"code":"authentication_failed","detail":"Invalid token"}
I tried several times (generating new JWT token and changing the secret in config.toml, but could not create the application.
I am installing Svix first time. I think I am missing a step. Please help in resolving the issue.

I tried to build locally and followed the steps in the document.
Now I am able to create applications.
Thank you. My apologies to bother you.

I am closing the issue.