text:
PyTorch Failed to Build

Following the guide at https://torchcraft.github.io/TorchCraftAI/docs/install-windows.html, I am getting an error when running the command "python setup.py build".  I am running the command form the pytorch folder. Both CUDA 10 and CUDA 9 with patches are installed (I've been told that CUDA 10 is not compatible, but originally the link to CUDA brought me to version 10).
This is the last output of the command:
-- Configuring incomplete, errors occurred!
See also "E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/build/CMakeFiles/CMakeOutput.log".
See also "E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/build/CMakeFiles/CMakeError.log".
(base) E:\Program Files (x86)\BWAPI\CherryPi\TorchCraftAI\3rdparty\pytorch\build>IF ERRORLEVEL 1 exit 1
Failed to run 'tools\build_pytorch_libs.bat --use-cuda --use-fbgemm --use-nnpack --use-mkldnn --use-qnnpack caffe2'
Attached are the two log files mentioned in the error output.
CMakeError.log
CMakeOutput.log

Is it possible to paste the full output of the command? The last page or two might be informative too if it's hard for you to get the full output. The logs don't seem to be useful for me, most of it is compiling test programs to see if a compiler feature exists. Alternatively, you can check the PyTorch issues to see if you can find anything similar to your case.

Unfortunately, some of the output gets cut off because there is so much, but here is what I can access after the command finishes running.
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_sequential - mkl_core]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_sequential - mkl_core]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_sequential - mkl_core]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_sequential - mkl_core]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - libiomp5md - pthread]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - libiomp5md - pthread]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - pthread]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - pthread]
--   Library mkl_intel: not found
-- Checking for [mkl - guide - pthread - m]
--   Library mkl: not found
-- MKL library not found
-- Checking for [Accelerate]
--   Library Accelerate: BLAS_Accelerate_LIBRARY-NOTFOUND
-- Checking for [vecLib]
--   Library vecLib: BLAS_vecLib_LIBRARY-NOTFOUND
-- Checking for [openblas]
--   Library openblas: BLAS_openblas_LIBRARY-NOTFOUND
-- Checking for [openblas - pthread]
--   Library openblas: BLAS_openblas_LIBRARY-NOTFOUND
-- Checking for [libopenblas]
--   Library libopenblas: BLAS_libopenblas_LIBRARY-NOTFOUND
-- Checking for [goto2 - gfortran]
--   Library goto2: BLAS_goto2_LIBRARY-NOTFOUND
-- Checking for [goto2 - gfortran - pthread]
--   Library goto2: BLAS_goto2_LIBRARY-NOTFOUND
-- Checking for [acml - gfortran]
--   Library acml: BLAS_acml_LIBRARY-NOTFOUND
-- Checking for [ptf77blas - atlas - gfortran]
--   Library ptf77blas: BLAS_ptf77blas_LIBRARY-NOTFOUND
-- Checking for [blas]
--   Library blas: BLAS_blas_LIBRARY-NOTFOUND
-- Cannot find a library with BLAS API. Not using BLAS.
CMake Warning at cmake/Dependencies.cmake:129 (message):
Target platform "Windows" is not supported in QNNPACK.  Supported platforms
are Android, iOS, Linux, and macOS.  Turn this warning off by
USE_QNNPACK=OFF.
Call Stack (most recent call first):
CMakeLists.txt:200 (include)
CMake Warning at cmake/External/nnpack.cmake:21 (message):
NNPACK not supported on MSVC yet.  Turn this warning off by USE_NNPACK=OFF.
Call Stack (most recent call first):
cmake/Dependencies.cmake:195 (include)
CMakeLists.txt:200 (include)
CMake Warning at cmake/Dependencies.cmake:205 (message):
Not compiling with NNPACK.  Suppress this warning with -DUSE_NNPACK=OFF
Call Stack (most recent call first):
CMakeLists.txt:200 (include)
-- Found PythonInterp: E:/ProgramData/Anaconda3/python.exe (found version "3.7")
-- git Version: v1.4.0-505be96a
-- Version: 1.4.0
-- Performing Test HAVE_STD_REGEX -- success
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Using third party subdirectory Eigen.
Python 3.7.0
-- Setting Python's include dir to E:\ProgramData\Anaconda3\include from distutils.sysconfig
-- Found PythonInterp: E:/ProgramData/Anaconda3/python.exe (found suitable version "3.7", minimum required is "2.7")
-- NumPy ver. 1.15.4 found (include: E:/ProgramData/Anaconda3/lib/site-packages/numpy/core/include)
-- Could NOT find pybind11 (missing: pybind11_DIR)
-- Could NOT find pybind11 (missing: pybind11_INCLUDE_DIR)
-- Using third_party/pybind11.
-- Found CUDA: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0 (found suitable version "10.0", minimum required is "7.0")
-- Caffe2: CUDA detected: 10.0
-- Caffe2: CUDA nvcc is: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/bin/nvcc.exe
-- Caffe2: CUDA toolkit directory: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0
-- Caffe2: Header version is: 10.0
CMake Error at cmake/public/cuda.cmake:123 (file):
file failed to open for reading (No such file or directory):
\=//cudnn.h

Call Stack (most recent call first):
cmake/Dependencies.cmake:626 (include)
CMakeLists.txt:200 (include)
-- Found cuDNN: v?  (include: =/, library: =/)
-- Automatic GPU detection failed. Building for common architectures.
-- Autodetected CUDA architecture(s): 3.0;3.5;5.0;5.2;6.0;6.1;7.0;7.0+PTX
-- Added CUDA NVCC flags for: -gencode;arch=compute_30,code=sm_30;-gencode;arch=compute_35,code=sm_35;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_52,code=sm_52;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_70,code=compute_70
-- Could NOT find CUB (missing: CUB_INCLUDE_DIR)
-- ******** Summary ********
--   CMake version         : 3.12.2
--   CMake command         : E:/ProgramData/Anaconda3/Library/bin/cmake.exe
--   System                : Windows
--   C++ compiler          : E:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x64/cl.exe
--   C++ compiler version  : 19.11.25548.2
--   CXX flags             : /EHa
--   Build type            : Release
--   Compile definitions   :
--   CMAKE_PREFIX_PATH     :
--   CMAKE_INSTALL_PREFIX  : E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/torch/lib/tmp_install
--   CMAKE_MODULE_PATH     : E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/cmake/Modules;E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/cmake/public/../Modules_CUDA_fix
--   ONNX version          : 1.3.0
--   ONNX NAMESPACE        : onnx_torch
--   ONNX_BUILD_TESTS      : OFF
--   ONNX_BUILD_BENCHMARKS : OFF
--   ONNX_USE_LITE_PROTO   : OFF
--   ONNXIFI_DUMMY_BACKEND : OFF
--   Protobuf compiler     :
--   Protobuf includes     :
--   Protobuf libraries    :
--   BUILD_ONNX_PYTHON     : OFF
-- Found CUDA with FP16 support, compiling with torch.cuda.HalfTensor
-- Removing -DNDEBUG from compile flags
-- Compiling with OpenMP support
-- MAGMA not found. Compiling without MAGMA support
-- Could not find hardware support for NEON on this machine.
-- No OMAP3 processor on this machine.
-- No OMAP4 processor on this machine.
-- AVX compiler support found
-- AVX2 compiler support found
-- Atomics: using MSVC intrinsics
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - libiomp5md]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - libiomp5md]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_sequential - mkl_core]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_sequential - mkl_core]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_sequential - mkl_core]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_sequential - mkl_core]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - libiomp5md - pthread]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - libiomp5md - pthread]
--   Library mkl_intel: not found
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - pthread]
--   Library mkl_intel_lp64: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - pthread]
--   Library mkl_intel: not found
-- Checking for [mkl - guide - pthread - m]
--   Library mkl: not found
-- MKL library not found
-- Checking for [Accelerate]
--   Library Accelerate: BLAS_Accelerate_LIBRARY-NOTFOUND
-- Checking for [vecLib]
--   Library vecLib: BLAS_vecLib_LIBRARY-NOTFOUND
-- Checking for [openblas]
--   Library openblas: BLAS_openblas_LIBRARY-NOTFOUND
-- Checking for [openblas - pthread]
--   Library openblas: BLAS_openblas_LIBRARY-NOTFOUND
-- Checking for [libopenblas]
--   Library libopenblas: BLAS_libopenblas_LIBRARY-NOTFOUND
-- Checking for [goto2 - gfortran]
--   Library goto2: BLAS_goto2_LIBRARY-NOTFOUND
-- Checking for [goto2 - gfortran - pthread]
--   Library goto2: BLAS_goto2_LIBRARY-NOTFOUND
-- Checking for [acml - gfortran]
--   Library acml: BLAS_acml_LIBRARY-NOTFOUND
-- Checking for [ptf77blas - atlas - gfortran]
--   Library ptf77blas: BLAS_ptf77blas_LIBRARY-NOTFOUND
-- Checking for [blas]
--   Library blas: BLAS_blas_LIBRARY-NOTFOUND
-- Cannot find a library with BLAS API. Not using BLAS.
-- LAPACK requires BLAS
-- Cannot find a library with LAPACK API. Not using LAPACK.
-- Found CUDA: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0 (found suitable version "10.0", minimum required is "5.5")
disabling ROCM because NOT USE_ROCM is set
-- MIOpen not found. Compiling without MIOpen support
-- MKL-DNN needs omp 3+ which is not supported in MSVC so far
-- MKL-DNN needs omp 3+ which is not supported in MSVC so far
CMake Warning at cmake/Dependencies.cmake:1302 (MESSAGE):
MKLDNN could not be found.
Call Stack (most recent call first):
CMakeLists.txt:200 (include)
-- Using python found in E:\ProgramData\Anaconda3\python.exe
-- Using python found in E:\ProgramData\Anaconda3\python.exe
-- NCCL operators skipped due to no CUDA support
-- Excluding ideep operators as we are not using ideep
-- Excluding image processing operators due to no opencv
-- Excluding video processing operators due to no opencv
-- MPI operators skipped due to no MPI support
-- Include Observer library
-- Using Lib/site-packages as python relative installation path
-- Automatically generating missing init.py files.
-- A previous caffe2 cmake run already created the init.py files.
CMake Warning at CMakeLists.txt:388 (message):
Generated cmake files are only fully tested if one builds with system glog,
gflags, and protobuf.  Other settings may generate files that are not well
tested.
--
-- ******** Summary ********
-- General:
--   CMake version         : 3.12.2
--   CMake command         : E:/ProgramData/Anaconda3/Library/bin/cmake.exe
--   System                : Windows
--   C++ compiler          : E:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x64/cl.exe
--   C++ compiler version  : 19.11.25548.2
--   BLAS                  : MKL
--   CXX flags             : /EHa -openmp /MP /bigobj
--   Build type            : Release
--   Compile definitions   : ONNX_NAMESPACE=onnx_torch;_CRT_SECURE_NO_DEPRECATE=1;USE_MSC_ATOMICS=1
--   CMAKE_PREFIX_PATH     :
--   CMAKE_INSTALL_PREFIX  : E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/torch/lib/tmp_install
--   TORCH_VERSION         : 1.0.0
--   CAFFE2_VERSION        : 1.0.0
--   BUILD_ATEN_MOBILE     : OFF
--   BUILD_ATEN_ONLY       : OFF
--   BUILD_BINARY          : OFF
--   BUILD_CUSTOM_PROTOBUF : ON
--     Link local protobuf : ON
--   BUILD_DOCS            : OFF
--   BUILD_PYTHON          : ON
--     Python version      : 3.7
--     Python executable   : E:/ProgramData/Anaconda3/python.exe
--     Pythonlibs version  : 3.7.0
--     Python library      : E:/ProgramData/Anaconda3/libs/python37.lib
--     Python includes     : E:\ProgramData\Anaconda3\include
--     Python site-packages: Lib/site-packages
--   BUILD_CAFFE2_OPS      : ON
--   BUILD_SHARED_LIBS     : ON
--   BUILD_TEST            : ON
--   USE_ASAN              : OFF
--   USE_CUDA              : 1
--     CUDA static link    : OFF
--     USE_CUDNN           : ON
--     CUDA version        : 10.0
--     cuDNN version       : ?
--     CUDA root directory : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0
--     CUDA library        : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/lib/x64/cuda.lib
--     cudart library      : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/lib/x64/cudart_static.lib
--     cublas library      : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/lib/x64/cublas.lib
--     cufft library       : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/lib/x64/cufft.lib
--     curand library      : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/lib/x64/curand.lib
--     cuDNN library       : =/
--     nvrtc               : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/lib/x64/nvrtc.lib
--     CUDA include path   : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/include
--     NVCC executable     : C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/bin/nvcc.exe
--     CUDA host compiler  : $(VCInstallDir)Tools/MSVC/$(VCToolsVersion)/bin/Host$(Platform)/$(PlatformTarget)
--     USE_TENSORRT        : OFF
--   USE_ROCM              : OFF
--   USE_EIGEN_FOR_BLAS    : ON
--   USE_FBGEMM            : OFF
--   USE_FFMPEG            : OFF
--   USE_GFLAGS            : OFF
--   USE_GLOG              : OFF
--   USE_LEVELDB           : OFF
--   USE_LITE_PROTO        : OFF
--   USE_LMDB              : OFF
--   USE_METAL             : OFF
--   USE_MKL               : OFF
--   USE_MKLDNN            : OFF
--   USE_MOBILE_OPENGL     : OFF
--   USE_NCCL              : OFF
--   USE_NNPACK            : OFF
--   USE_NUMPY             : ON
--   USE_OBSERVERS         : ON
--   USE_OPENCL            : OFF
--   USE_OPENCV            : OFF
--   USE_OPENMP            : OFF
--   USE_PROF              : OFF
--   USE_QNNPACK           : OFF
--   USE_REDIS             : OFF
--   USE_ROCKSDB           : OFF
--   USE_ZMQ               : OFF
--   USE_DISTRIBUTED       : OFF
--   Public Dependencies  : Threads::Threads
--   Private Dependencies : cpuinfo;fp16;aten_op_header_gen;onnxifi_loader
-- Configuring incomplete, errors occurred!
See also "E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/build/CMakeFiles/CMakeOutput.log".
See also "E:/Program Files (x86)/BWAPI/CherryPi/TorchCraftAI/3rdparty/pytorch/build/CMakeFiles/CMakeError.log".
(base) E:\Program Files (x86)\BWAPI\CherryPi\TorchCraftAI\3rdparty\pytorch\build>IF ERRORLEVEL 1 exit 1
Failed to run 'tools\build_pytorch_libs.bat --use-cuda --use-fbgemm --use-nnpack --use-mkldnn --use-qnnpack caffe2'
(base) E:\Program Files (x86)\BWAPI\CherryPi\TorchCraftAI\3rdparty\pytorch>

It looks like the same error here. We will document that you apparently need to install cudnn, we were not aware PyTorch had this bug on windows :(
https://github.com/TorchCraft/TorchCraftAI/issues/2#issuecomment-445430169

authors: NiteKat ebetica

repo: TorchCraft/TorchCraftAI


text:
Socket-io client does not upgrade to Websocket, it just works as polling

Is your feature request related to a problem? Please describe.
Yes. Connection does not upgrade to websocket automatically
Describe the solution you'd like
I would like the connection on the side to receive the upgrade to websocket, it is keeping it as polling and does not upgrade
Describe alternatives you've considered
I don't know if I need to pass any parameters to allow this behavior, if there is something like that please let me know.
Additional context
Below is a photo of the behavior that I'm not expecting.

Could you please add a demo code of the client and server? Without this I won't be able to see what's wrong.
I suspect that it is the client that is not configured correctly to upgrade to websocket. As it is the responsability of the client to initialize a websocket upgrade request.

I managed to fix it, in fact, transports was missing: ["polling", "websocket"]. I had only defined polling.
Taking advantage, I would like to know why the emit that I am triggering when the user connects is going along with the Socketioxide connection process?
Here below is an example:

Now notice the second image, which indicates where the emitted data is being received:

Part of the code that accomplishes this:
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    tracing::subscriber::set_global_default(FmtSubscriber::default())?;

    let messages = state::MessageStore::default();
    let sockets = state::SocketDataStore::default();

    let (layer, io) = SocketIo::builder().with_state(messages).with_state(sockets).build_layer();

    io.ns("/", |socket: SocketRef, Data(auth): Data<types::AuthData>, store: State<state::SocketDataStore>| async move {

               fn emit_wrapper(event: String, socket: &SocketRef, id: String, data: impl serde::Serialize) {
                    let _result = socket
                    .within(id)
                    .emit(event, data).ok();
                }

                emit_wrapper("person:connected".to_string(), &socket, socket_data.clone().id.clone().to_string(),
                    types::PersonConnected {
                        user_id: socket_data.clone().user_id,
                        extension: socket_data.clone().extension.clone().unwrap_or("".to_string()),
                    }
                );
    });
        let app = axum::Router::new()
        .route("/", get(|| async { "Hello, World!" }))
        .route("/hello", get(handler))
        .with_state(io)
        .layer(
            ServiceBuilder::new()
                .layer(CorsLayer::permissive())
                .layer(layer),
        );

    info!("Starting server");

    axum::Server::bind(&"0.0.0.0:3010".parse().unwrap())
        .serve(app.into_make_service())
        .await?;

    Ok(())
}

Because the protocol specification doesn't specify that the initial connect response should be alone. And with http polling it is possible to have multiple packets in one response:

https://socket.io/docs/v4/engine-io-protocol/#http-long-polling-1

So for performance reasons if two packets are emitted at almost the same time they will be buffered.
https://github.com/Totodore/socketioxide/blob/a11edd6017e7d130de82b5d2979fe09781f8701d/engineioxide/src/transport/ws.rs#L239-L247

source: gharchive/issue

authors: Henrriky Totodore

repo: Totodore/socketioxide

license: MIT

license_type: permissive

license_source: github-api


text:
[WIP] Phone and tablet UX

Give me the build
Woah there, you probably want to read and review before, but eh, if you want it, here it is:

WIP 1 Pinephone Pro build

WIP 2 Pinephone Pro build

Built against db86fbfd341e7f5366217bea91cfb01a948ce54a

WIP 3 Pinephone A64 build
WIP 3 Pinephone Pro build

This is the WIP, but usable, branch for phone and "keyboard-free" devices like tablets.
This branch as it is will not be merged in Tow-Boot. Upcoming changes to use the modules system to configure builds will be necessary to make these changes less intrusive. With that said the result wouldn't differ in any significant manner. This means that a build from this branch is as good as a build from the upcoming changes.

TODO
For the Pinephone (A64)

[x] Soak test on Pinephone (A64) (just test everything again)
[ ] Allwinner mmcblk×boot0 support :eyes: (can be done after merging and releasing this)

For the Pinephone Pro

[x] Review and refresh of the U-Boot patch set on top of mainline, see what "the best we have" is to base on.
[x] Fix #86

Things that need further further investigation.

(??) Validate that the change required for SPI NOR Flash is not problematic
AFAICT rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT) should be a no-op, as "set" is the default state for the register at reset. Though removing it from the startup sequence fixes issues with SPI NOR Flash, issues that persist up into the OS.
(??) Check eMMC patches + UMS issues (was I testing correctly?)
It seems the changes are insufficient for UMS... see the WIP commit message...

Long initial PR description
What is this?
This is my attempt at making boot on "Linux phones" as painless as possible.
Features:

LED management
Phone keys based control
User-friendlier universal defaults
"Status reporting"

Anti-features:

Superficial status reporting without display enablement.

LED management
The LED is lit-up as early as possible, assuming it's RGB, it's lit-up red first.
When Tow-Boot starts running the default distro boot (as defined by U-Boot), it turns yellow.
Some additional boot modes will turn the LED different colours:

Blue for Mass Storage
Aqua for requesting SD card boot

Phone keys based control
As commonly done with "consumer" phones and mobile devices, holding volume keys during early boot phases will affect the boot in different manner.

Volume up: Boot in USB Mass Storage mode
Volume down: Request Operating System Boot from SD card

Note: USB Mass Storage (or UMS) exports the eMMC (internal) of the device over USB.

User-friendlier universal defaults
To make things less confusing across devices, all devices will load the operating system using the same rules.
The schemes supported by the distro boot scheme from U-Boot are all tried on the following devices in order:

eMMC
SD

The order is static and eMMC first on all devices. This is a deviation from the defaults from the different communities, and somewhat a deviation from the defaults of U-Boot. Doing so helps reduce confusion and should help reduce support load.
This helps reduce confusion, because the order the operating systems will be tried to be loaded is the same, wherever Tow-Boot was started from. This is quite important considering different SoCs have a different BootROM startup order, making it harder to "just" boot the SD card if started from the SD card.
Furthermore, attempting Operating System boot from eMMC first is a done considering booting from a removable storage should be a conscious choice, requested by the end-user.

Note: When all Operating System boot sources have been attempted, and none worked, the device will poweroff after reporting the failure.

Not specific to the Phone UX, Tow-Boot always uses 115200 baud rate. This way, the UART rate is always the same, helping a bit more with unified instructions.
"Status reporting"
In addition to the LEDs reporting the current boot state, vibration support has been added. The device will vibrate once as early as possible.
When failing to do the Operating System boot from SD as requested by the user (holding volume down), the LED will flash 4 times, and the device will vibrate accordingly. Boot will continue to the default distro boot.
When failing to do the default distro boot, the LED will flash 10 times, and the device will vibrate accordingly. Then the device will poweroff.

Note: when connected to a power source, some devices (the Pinephone Pro) will not poweroff, and will instead reboot.

In addition to that, a protective partition is added to the GPT to prevent bad manipulations from breaking the installed Platform Firmware. This protective partition also provides strong guarantees when updating the Tow-Boot install, such that when its size increases, it is assured not to interfere with the other partitions.
Superficial status reporting without display enablement
As described previously, all of this is done such that the user knows what is happening, even though the display shows nothing.
This, to me is a sort of "anti-feature", but in reality we must keep this scheme such that further devices can use it even if a display driver has not been written yet for them.

How do I install this?
Ideally this would be installed to SPI flash using an SPI flash installer. An implementation was written with a "specialized" Linux system build so that the initial lack of display enablement on the Pinephone Pro wouldn't be an issue.
Alas, none of the targeted devices support SPI boot, thus none can be installed to dedicated storage.
To install to eMMC, the steps will generally be the same:

These instructions will clobber the content of the SD card and the eMMC, defining a new partition table.
Write the shared.disk-image.img to an SD card as-is
Boot the device to USB Mass Storage by holding Volume Up
Write the shared.disk-image.img to the phone.

Note: With some SoCs (e.g. Rockchip) you will need to "neuter" the Platform Firmware installed to the eMMC if there is one already installed.

How do I install a Linux distro after installing Tow-Boot?
This is a hard question to answer correctly. This will require a change in habits of the different distributions.
Mobile NixOS
I can only answer for the distribution I'm involved with, Mobile NixOS.
A temporary installation method has been added:

https://github.com/NixOS/mobile-nixos/pull/442
https://github.com/NixOS/mobile-nixos/pull/445

It relies on a script and Mass Storage support on the target device. This is a method I think would be acceptable to keep recommending for other distros. The main thing to understand here is the script manipulates the partitions, then splats the content in them.

The permanent solution will be an installer system. The user will write Tow-Boot to the eMMC, and boot from a universal SD card that holds an installer system that will guide the user through some questions about partitioning (e.g. ask about FDE and filesystems), the preferred graphical environment, and then do a "classic" opinionated nixos-install under the covers.

For mass storage mode, is it possible to export the SD card as well? It would be nice if you can write to SD card from there.

The UMS driver for U-Boot at this point in time only handles exporting one LUN.
With UX improvements (mainly display output support) we could let the user pick which storage medium is exported.
An alternative could be to look into adding support for exporting more LUNs in upstream U-Boot.

An alternative could be to look into adding support for exporting more LUNs in upstream U-Boot.

I think letting the user choose which device is exported would be more foolproof. With both the SD and eMMC supported, the user could accidentally write to the wrong device. With Jump Drive on the PinePhone, I've had to check the drive size reported in dmesg to ensure I'm writing to the correct device.

This push rebases the work that was on this branch, with the refreshed work built on top of #78.
That rewrite was done because this PR showed it was really needed (in addition to making other things easier).
This push also includes the "ELO" changes, "Embedded Linux OS", which is used to build a touch-based installer system for installing to SPI, for devices that support installation to SPI.

Just writing to confirm that the WIP2 builds work fine on my Pinephone Pro.
It even makes the phone able to suspend!
Does the WIP3 build add something or is it just re-arranging some stuff?

Re-arranging stuff, adding a Pinephone A64 pre-built artifact, and fixes the OS boot order regression.
But otherwise mostly the same.

AFAICT it still is working just fine here. wget or curl output might help track down issues.

Thank you, it actually worked, it was just a bug or something in my web browser. I was able to download by copying the link to another tab (?!). Thanks for the work, now I'm rocking Tow-Boot on my PPP! It works great!

Hello all. I erased spi and flashed it. Now I cannot boot from sdcard. Is there any way to recover from this? Thank you for your help.

Apparently I still can boot from sdcard if i continue spamming volume down button on boot. Everything works as it should after. Strange.

Note that you don't need to erase the SPI before flashing it, the flash button already handles that. Also please don't ask for user support here but join #tow-boot:matrix.org instead.

Thank you. Joined;)

It was beginning to be too cumbersome to separate the changes for mmcboot support, when this PR touched the installer config.
I hate bundling more features into a huge PR, but this had to be done.

Note that you don't need to erase the SPI before flashing it, the flash button already handles that. Also please don't ask for user support here but join #tow-boot:matrix.org instead.

The tow-boot matrix doesn't seem to be join-able anymore?

That's likely because to discover rooms, sometimes "via" servers are needed, try:

https://matrix.to/#/#Tow-Boot:matrix.org?via=matrix.org

I just installed this onto my A64 Pinephone. The installation process was very smooth, and thanks to the new mmcboot support, it didn't wipe my existing OS installation! Awesome work.

This PR should get linked to #76

source: gharchive/pull-request

authors: Be-ing Danct12 NoahAndrews PureTryOut Strit jussihi justuser-ppp ragreenburg samueldr

repo: Tow-Boot/Tow-Boot


text:
Add Options on resources

Add default options and extends this on all resources.
api: {
    options: {},
    USERS: {
      GET: {
        url: '/user',
        options: {same-origin},
      },
...

#20

authors: fabienjuif guillaumecrespel

repo: Trampss/roadhog-saga


text:
Milestone Prototyp

Beschreibung:
Der Technical Demonstrator dient dazu, zu zeigen, das die Gesamte Technik beherrscht wird. In den Vorhergehenden Tasks (siehe Meilenstein Prototyp) wurden der Input, die Datenübertragung und der Output separat implementiert und getestet. Jetzt geht es darum, das Zusammenspiel sicherzustellen, und zu zeigen, dass ein komplexer Ablauf durchgeführt werden kann.
Anforderung:
Es wurde ein fachlicher Ablauf (https://github.com/Transport-Protocol/MBC-Ping-Pong/blob/master/docu/maindocumentation/architecture/prototypSequenceDiagram.png) definiert, dieser ist möglichst weitgehend umzusetzen.
Abnahmekriterien:

http://<IpDesNodeJsServers>:<HttpPortDesNodeJsServers>/DisplayPeer.html zeigt ein Spielfeld
http://<IpDesNodeJsServers>:<HttpPortDesNodeJsServers>/ControlPeer.html zeigt ein Touchfeld
Beim Aufruf der ControlPeer.html wird dem Spiel beigetrehten.
Tritt ein User dem Spiel bei, wird für ihn ein Sprite erzeugt.
Der User kann das Sprite, von seinem Handy aus, per Touch auf eine X-/Y-Koordinate setzen, und wenn er seinen Finger bewegt, bewegt sich das Sprite mit.
Verläßt ein User das Spiel, wird sein Sprite von aus dem Spiel entfernt und freigegeben.
Es können 0-6 Spieler gleichzeitig spielen.
Sind 6 Spieler vorhanden, und ein weiterer Spieler versucht sich zu verbinden, tritt er dem Spiel nicht bei.
Sind 6 Spieler vorhanden, und verlässt (Browser schließen) ein Spieler das Spiel, kann ein Anderer beitreten

Dem Prototypen wurde eine Spielerklasse hinzugefügt.
Zum Testen kann die DisplayPeer.html aufgerufen werden.
Dann in der Console eingeben: addTestPlayer() und in das Fenster klicken.
Achtung, muss entweder manuell mit browserify gebaut werden, oder mit docker gestartet werden.

@Blackgen Bitte prüfen, warum man den Player nicht beim laden hinzufügen kann.
Fehler Reproduktion:
In der DisplayPeerMain.js "Game.addPlayerToGame();" auf oberster ebene hinzufügen.

Das Game bietet jetzt das Interface gemäß der Spezifikation.
In der DisplayPeerMain.js ist ein UsageExample. Um dies zu nutzen einfach die DisplayPeer.html öffnen und in der Console eingeben:

einmal var players = [];
zum hinzufügen players.push(new addTestPlayer());
zum löschen players.push(new addTestPlayer());

repo: Transport-Protocol/MBC-Ping-Pong

license: mit

license_source: bigquery


text:
🛑 MeVuelo Core API (testing) is down

In 4134dfc, MeVuelo Core API (testing) (https://api.core.testing.travelonux.com/status) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MeVuelo Core API (testing) is back up in 5f84fa5.

repo: Travelonux/upptime


text:
Biome ID's in the config

Biome ID's should be able to be changed/viewed in the config?
In the wiki biome names and ID's should be added as well so that they can be utilized with modpack tweaking mods.

I found an alternative method to obtain mod ID's

Not sure what you mean. Biome IDs are automatically assigned by Forge and that's not something I can control.

Most of the biome names are just the same as the display names, except for traverse:green_swamp is Lush Swamp and traverse:temperate_rainforest is Coniferous Forest. The rest are just like Autumnal Woods -> traverse:autumnal_woods

You can also see the biome names in the autocomplete for the /findbiome command

authors: ProfessorProspector SextupleTap

repo: TraverseTeam/Traverse


text:
Add Error Handler

Check out gorilla/mux's error handling
I added one for not found via: r.NotFoundHandler = http.HandlerFunc(notFound)
Look through docs to find others

looks like there is method not allowed
server errors will be fairly generic... like "oops! we did it again.."

repo: TravisAvey/website-baseline


text:
[BUG]: Can't prevent pressing Enter from input

Issue description
I prevent keydown event but not working. I don't want to trigger form element.
Media & Screenshots
No response
Baklava Version
2.2.0-beta.12
Operating system

OS: [e.g. iOS]: MacOS

Browser [e.g. chrome, safari]: Firefox

Any other details...

Priority this issue should have
Low (slightly annoying)
Please review the checkboxes that are applicable.

[ ] This issue is directly related to React

Can you try keydown capture event?

We can add a prop and include it in the condition here, or we can also check whether the event is prevented or not, which I think will be the most effortless.
BTW I tried it didn't work.

Which component did you attach the keydown capture event?

bl-input

I've attached capture event to form and it works for me.

https://jsfiddle.net/enes5519/gp3k6bua/

repo: Trendyol/baklava


text:
初学者更换HEXO主题后页面一片空白是为什么？

第一次用github
第一次用github page
第一次用Hexo
第一次更换obsidian主题
然后页面就一片空白了，虽然感觉不是主题的原因，因为页面title都没有，但是我也不知道去哪里问相关的问题，有没有大佬帮忙分析下或者解决下。
拜谢！

本地测试一下，终端会有报错信息

https://shaomail.com/ 这不是正常吗？但是好型不是这个主题的

我也是，更换主题后，网页直接一片空白，什么都没有了
这是本地测试的报错信息：
希望作者大大或大佬帮忙解决下，谢谢！
ERROR Script load failed: themes\obsidian\scripts\helpers\hexo-html-truncate.js
Error: Cannot find module 'lodash.assignin'
ERROR Script load failed: themes\obsidian\scripts\libs\cheerio\api\attributes.js
Error: Cannot find module 'css-select'
ERROR Script load failed: themes\obsidian\scripts\libs\cheerio\api\manipulation.js
Error: Cannot find module 'css-select'
ERROR Script load failed: themes\obsidian\scripts\libs\cheerio\static.js
Error: Cannot find module 'css-select'
ERROR Script load failed: themes\obsidian\scripts\libs\cheerio\static.js
Error: Cannot find module 'css-select'
ERROR Script load failed: themes\obsidian\scripts\libs\cheerio\static.js
Error: Cannot find module 'css-select'

https://shaomail.com/ 这不是正常吗？但是好像不是这个主题的

是的，当时提问之后，又尝试了几次，然后加QQ群也没有很快通过，我就先换了个主题，换了以后就没出问题了。

也遇到了这个问题，查看文章详情，是可以访问的
主页的index.html文件是空白的，所以访问首页是空的。
暂时没找到原因

找到原因了， 模块缺失的问题
详见 #40  和  #97

我已经在说明文档中加入了这个步骤了。谢谢大家支持！

authors: TriDiamond bwangll ltxman mkdir700 twomoney yansheng836

repo: TriDiamond/hexo-theme-obsidian


text:
feat(e2e-runner): enable or disable target logging via options

Use the new logging option on a target to either enable, or disable the logging output for the specified target.
Closes #202
I tried adding some component tests; but I can't seem to mock child_process.spawn properly without adding extra libraries.

Thanks for the PR!

repo: TriPSs/nx-extend


text:
⚠ RbxVeri has degraded performance

In abb67b3, RbxVeri (https://verify.triza.dev) experienced degraded performance:

HTTP code: 200
Response time: 2256 ms

Resolved: RbxVeri performance has improved in 4b276e8.

repo: TrizaCorporation/Status


text:
🛑 T:Riza Community Forum is down

In 91a5dfe, T:Riza Community Forum (https://community.triza.dev) was down:

HTTP code: 0
Response time: 0 ms

Resolved: T:Riza Community Forum is back up in 8e98022.


text:
How to quantized AlexNet?

I changed the net to AlexNet(original alexnet, no batchnorm,but have dropout), and changed dataset. I follow the paper, the first conv and the last fc3 ,their params are not quantized.
HYPERPARAMETER_T = 0.15
LEARNING_RATE = 1e-1
all_kernels are tensor that only contain 0、1、-1
initial_scaling_factors are (1,1)....
but training:
0  5348670964449068.000 4.063  0.048 0.059  0.218 0.264  148.051
1  11028.571 3.509  0.055 0.057  0.271 0.278  143.362
2  11.255 3.473  0.053 0.055  0.273 0.283  141.120
3  35.804 3.465  0.055 0.057  0.271 0.280  144.584
4  41.598 3.470  0.056 0.055  0.272 0.271  133.428
5  10366.085 3.469  0.055 0.059  0.268 0.280  133.706
Epoch     5: reducing learning rate of group 0 to 1.0000e-02.
Epoch     5: reducing learning rate of group 1 to 1.0000e-02.
Epoch     5: reducing learning rate of group 0 to 1.0000e-02.
Epoch     5: reducing learning rate of group 0 to 1.0000e-02.
6  23.033 3.464  0.057 0.059  0.274 0.280  133.508
....
the accuracy is so low, it seems params didn't update.

Hi! I had the same problem.
You just need a lot of hyperparameter tuning and luck :)

authors: RichardMrLu TropComplique


text:
upload Cryptopro

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

[ ] Filename in the lowercase format
[ ] Image format: png
[ ] Image size: 256 by 256 px

make sure file extension is png and resolution min 256x256

repo: TrustWallet/tokens


text:
🎨  Change asset path to /ghost/assets

See TryGhost/Ghost#7503 for a hopefully clear explanation of why I'm making this change
I have changed to having both an admin and an asset path because, although I can't find any usages of admin, I didn't want to hijack the term "admin" to mean "asset".

This passes the tests, however it was screwing up code injection because codemirror is included using the lazyLoader.
I've fixed this & pushed up my fix, however the concatenated codemirror.js file has a source map url at the bottom:
//# sourceMappingURL=codemirror.map
And this is wrong :(
I have no idea how to make the url be correct. I tried looking at various packages that seem to be used, but none of them appear to have any documentation on how to configure them!
Any ideas?

I believe you can add this line to the codemirror concat config to specify the relative path for the sourcemap:
sourceMapConfig: {sourceRoot: 'proper/path/'}

broccoli-concat uses https://github.com/mozilla/source-map under the hood so any options passed in via sourceMapConfig are passed through to that.

Alternatively, that source map isn't particularly useful so it could be set to sourceMapConfig: {enabled: false}

Switched to remove the sourcemap ⛵

authors: ErisDS kevinansfield

repo: TryGhost/Ghost-Admin


text:
[WIP/SPIKE] Editor refactors

no issue

split key commands and text expansions into separate files for easier file skimming/searches
fix basic style formatting to match Ghost-Admin, added a few comments
move editor title input into addon

the editor and title are now tightly integrated so that it's possible to use up/down cursor navigation so it makes more sense to keep them together
start of a deeper component restructure so that we don't need to leak properties/actions to parent components

first pass at refactor of gh-koenig and koenig-title-input

remove need for editor reference to be held outside of the gh-koenig component by yielding it from the component so that the integrated title element can sit inside the container's scope

refactor gh-koenig to more closely match the default ember mobiledoc addon
fixes runloop issues by starting/ending a manual runloop

refactored the mutation observer and event handlers in koenig-title-input so that we're not doing unecessary work on every render/key press
rename CSS classes to be more specific (these may still need more separation between .gh and .kg later)

.editor-holder to .gh-koenig-container
.surface to .gh-koenig-surface

Coverage increased (+1.07%) to 74.617% when pulling 817928f2b056a344a16e363e9d4ca7ac3c3fba74 on kevinansfield:editor-review into d70ea177969e4e940a1acc6af1f3f35a3cd103a4 on TryGhost:master.

Coverage increased (+1.09%) to 74.645% when pulling b378f49382e05d9d589bb0f52af069062d1033b8 on kevinansfield:editor-review into d70ea177969e4e940a1acc6af1f3f35a3cd103a4 on TryGhost:master.

Coverage increased (+1.09%) to 74.645% when pulling 5434d7577fe850bab63821f79aad63b7c1e31b39 on kevinansfield:editor-review into d70ea177969e4e940a1acc6af1f3f35a3cd103a4 on TryGhost:master.

Coverage increased (+1.09%) to 74.645% when pulling 93dec84c9a8a86829a6d30da544a167e2c6fed6d on kevinansfield:editor-review into d70ea177969e4e940a1acc6af1f3f35a3cd103a4 on TryGhost:master.

authors: coveralls kevinansfield


text:
urlFor "nav" does the wrong thing when passed a port as a relative URL

If you setup a navigation item with a url that's just a port number on the same domain as configured in config.js, urlFor treats this like a relative path and starts adding slashes where there shouldn't be one.
Steps to Reproduce

Configure the url in config.js to be a URL that doesn't have a port number (it doesn't have to be right :wink: ) e.g. http://ghost.dev
In navigation, add an item which points at a port number on the same url e.g. http://ghost.dev:3000
Save the navigation item, everything will look fine in the admin panel
Open your theme, view the source, and see the url is output with an extra slash in the middle as well as at the end e.g. http://ghost.dev/:3000/

This is a bug with the logic here: https://github.com/TryGhost/Ghost/blob/c549914ae867cb3f185b159e0a11ac713e0218c3/core/server/config/url.js#L204
In the case that there's a port number which isn't included in config.js, this is effectively pointing at an external site.
Technical details:

Ghost Version: 0.8

Damn sry didn't see there was already another pr for this. Feel free to close mine again.

authors: ErisDS sakulstra

repo: TryGhost/Ghost


text:
Improve base model destroy method

Currently the base model destroy method only supports destroying by the id property which can make it difficult to extend without re-implementing. It would be nice to make this more generic. More info here: https://github.com/TryGhost/Ghost/pull/9909#discussion_r220512501

@allouis Can we close this issue?

@allouis


text:
Stable update

Got some code for us? Awesome 🎊!
Please include a description of your change & check your PR against this list, thanks!

[ ]  There's a clear use-case for this code change
[ ]  Commit message has a short title & references relevant issues
[ ]  The build will pass (run yarn test and yarn lint)

More info can be found by clicking the "guidelines for contributing" link above.


text:
实验用网络

你好
我看了paper，也读了源码
但是似乎源码中使用的是ResNet101而论文中将其写成ResNet1001，不知以哪一个为准
此外，inception BN的结构似乎也很大，所以是否理解为Inception BN相比较ResNet1001是一个更小的模型，起到了knowledge distill的作用？
谢谢

关于Paper还有一个问题，论文里提到不直接匹配teacher和student的feature maps
As for distribution matching, it is not a good choice to directly match the samples from it, since it ignores the sample density in the space.
可是从NST损失函数来看，也是在将两个分布之间的差异减小，不知这有什么区别。
这是论文中最疑惑的部分，希望得到指教，谢谢。

One more question
请问eq3中的第一项cross entropy loss在哪里？似乎只有kd和mmd loss

@ForeverRuri 请问你复现过文章的结果没？效果怎样呢？我按文章的方法在caffe上复现后，加入mmd loss的效果比没加还差。。。

@ForeverRuri
你好，
（1）我们提供的源码是基于我们imagenet的实验的，之后我们会提供cifar的代码
（2）直接match teacher student的feature maps是fitnet，我们的实验中也比较了fitnet的效果。
（3）cross-entropy loss就是公式中的第一项，即分类loss，并不是kd loss。

authors: ForeverZH0204 dawuchen huangzehao

repo: TuSimple/neuron-selectivity-transfer


text:
🛑 Content Delivery Network (S3 Bucket) is down

In 22a9a3a, Content Delivery Network (S3 Bucket) (https://cdn.tubnet.gg/minecraft-resourcepack/TubPack-production.zip) was down:

HTTP code: 522
Response time: 15390 ms

Resolved: Content Delivery Network (S3 Bucket) is back up in de94327 after 23 minutes.

repo: Tubnom/tubnet-uptime


text:
POLL: Old / New Crawl button?

We want your opinion and have started a small poll:
How do you want the Crawl button to look like in one of the upcoming versions?
Please vote by pressing the thumbs up  under one of the options.
Thanks for your participation!

keep it

change 1

change 2

change 3

download is better wording

Thanks to all who participated.
We'll change it to version "change 2".

repo: TumblThreeApp/TumblThree


text:
seL4 Microkernel: Visualizations for Abstractions

I like to understand things by characterizing them. Each thing I do or create should have a story and a purpose. Same goes for my writings. To make the writing 'seL4 Microkernel' I'm planing to design icons, characters or any uniquely identifiable visual elements. Each abstraction (service) provided by the seL4 needs to have one.

Capabilities
Untyped
Address Spaces
Threads
Endpoints
Notifications
Interrupts
~Faults~

The visualizations should be simple yet unique. It's not an easy job, but I believe I can create something nice ❤

Done as of f3c4a7e! I have removed "faults" from the list and replaced it with "address spaces".

repo: TunaCici/Braavos


text:
New extension: Wake Lock

Resolves #858
Adds a new extension, Wake Lock, to keep the computer and screen on when needed.
You can add it to the website if you want to. If you need my Scratch profile, I'm D-ScratchNinja.
Tested in Edge 115.

Need to change the docs to Markdown.

I have converted the documentation to Markdown. Not tested!

repo: TurboWarp/extensions


text:
Use iteration interface of DynamicHMC

This PR replaces https://github.com/TuringLang/Turing.jl/pull/1186. It makes use of the (inofficial) iteration interface of DynamicHMC to exploit more features of AbstractMCMC and enable Gibbs sampling.

Pull Request Test Coverage Report for Build 438923081

40 of 40 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+1.06%) to 69.098%

Totals

Change from base Build 429352032:
1.06%

Covered Lines:
919

Relevant Lines:
1330

💛  - Coveralls

authors: coveralls devmotion


text:
Fix MLE with ConditionContext

Alternative to #2016 that does not introduce a new context.
Something along these lines I imagined in the discussion in https://github.com/TuringLang/Turing.jl/pull/2016/files#r1235430996.
I copied your tests @torfjelde from #2016 but just noticed that I forgot to give you credit for these. I'll try to fix that.
Edit: Fixed and made @torfjelde a co-author of the commit.

Edit: Fixed and made @torfjelde a co-author of the commit.

Oh that's very unnecessary, but I apprecate it:)
Regarding the PR, I'm not quite convinced regarding the short-cutting of the tilde-pipeline :confused:
Examples of failures:

Nice examples, I hadn't considered other scenarios 👍 My computer is already turned off but it seems this could be fixed by making OptimizationContext a leaf context, couldn't it? Then the difference between the PRs would basically boil down to OptimizationContext{<:LikelihoodContext} vs LikelihoodOptimizatiomContext.

Then the difference between the PRs would basically boil down to OptimizationContext{<:LikelihoodContext} vs LikelihoodOptimizatiomContext.

Exactly. I felt two separate contexts made more sense instead doingOptimizationContext{<:LikelihoodContext}, etc

Btw, no matter which option we go, we should add the above to tests.

Btw, no matter which option we go, we should add the above to tests.

Yes, I thought the same but it took me a while to copy and edit it on my phone 😅 Hopefully I did not introduce too many typos.
I think a neat thing about just fixing the existing types is that the diff is quite small (could even be more minimal without merging the tilde definitions - but I liked that it became IMO more obvious that the only difference is the log density calculation) and the type structure is unchanged. I also think it reflects a bit better that optimization contexts are wrappers of existing leafs such as DefaultContext and LikelihoodContext with small modifications.

That makes sense :+1: I went with the other option because I thought it was a bit "disengineous" to have a leaf context wrap leaf contexts :sweat_smile:
But let's go with your approach :+1: I'll have a look now.

authors: devmotion torfjelde


text:
Car Racing Game

I want to add a Car Racing Game
Please assign me this issue under IWOC

@TusharAMD Please assign this to me

repo: TusharAMD/Runn


text:
Only use /bigobj cxx flag on MSVC

This uses a construct of qmake that should work, but i have no ability to test it.
Simply compiling it should prove that it works though.

Yes it compiles fine.

authors: TwnKey jrobeson

repo: TwnKey/SenScriptsDecompiler


text:
[Regression] Documentation for destructured object properties is not picked up.

Search terms
object destructuring, object properties
Description
This used to work in 0.17, but now it does not. For this setup, where the Sym1 and Sym2 a descructured properties of the object, the docs for them are not "picked up"
const api = () : {
    Sym1 : () => number,
    Sym2 : () => boolean
} => {
    return null
}

/**
 * Important constant
 */
export const {
    /**
     * Docs for Sym1
     */
    Sym1,

    /**
     * Docs for Sym2
     */
    Sym2
} = api()

Result is:
And if you run the command line as: npx typedoc index.ts --excludeNotDocumented, the result is empty:

Reproduce
To reproduce:

Clone this repo: https://github.com/canonic-epicure/typedoc-repro-1756
npm i && npx typedoc index.ts --out docs
Check the content of the docs/index.html

I think I'm going to punt this one to 0.23 as well, since fixing it without making a significant breaking API change involves a ridiculous amount of hackery. There's a couple additional problems here, with the one making this immediately difficult to fix being that TypeDoc's checks for "has a comment" isn't consistent with whether or not TypeDoc will actually find a comment.

Ok, cool, no rush, since its possible to workaround this one.  It worked in 0.17, I guess need to check what approach was used there.

I see. Worth pining with a test.

repo: TypeStrong/typedoc


text:
🛑 Web OPL is down

In 2157d4e, Web OPL (https://opl.uab.cat) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Web OPL is back up in 0150a84 after 5 minutes.

repo: UAB-OPL/opl-uab-monitoring


text:
Reflection for milestone 3

updated the reflection for milestone 3
updated some links in project README:

added links for milestone 3
updated links for milestone 2 to ensure they link to the correct branch / commit / version

I think this is a thorough and well-written reflection. Nice work!


text:
Milestone 1 feedback

In addition to the feedback I provided for the R package, here is some feedback specific for this package:

.DS_Store should be in your .gitignore
You have init.py in two places

Addressed in #17

authors: GabrielBogo lmguzman

repo: UBC-MDS/pyfer


text:
Delete the "used by" column. Order traffic lights by colour, and alphabetically within colour.

... on the docs pages.

What was the motivation for deleting the used by column?

What was the motivation for deleting the used by column?

It was empty. Plus, most of us agreed we didn't really like the column anyway.

authors: dstansby paddyroddy samcunliffe

repo: UCL-ARC/python-tooling


text:
Lab06 -- Low Hanging Fruit

Lab06 submission for elswenson and andrewtran1995.

Merged lab06 and lab07 changes


text:
Verify Dining API V2

Time Tracking: https://its-pro.ucsd.edu/browse/MA-82
Verify current dining card works with the following endpoints:

[x] https://hdh-sandbox-ad.ucsd.edu/dining/DiningMenuApi/api/DiningDataService/GetDiningInfo_V2
[x] https://hdh-sandbox-ad.ucsd.edu/dining/DiningMenuApi/api/DiningDataService/GetDiningInfo_V2/01

The result from the first link seems to be a 404 error, but when trying this link in a browser data was returned.
The result from the second link seems to be a type error.

Notified HDH and requested both v1 and v2 API exist together for a smooth migration to v2.

I met with the service owner.
Dining V2 API Notes:

Their sandbox environment is only available on the campus network.
HDH is migrating their existing dining V2 API to a new domain and web server.
There are no API schema changes.
The new dining V2 API sandbox endpoint has been verified working for the Campus Mobile app

Deployment Notes:

Coordinate with HDH on the deployment
When the HDH dining V2 API migration has been completed, update the DiningService Lambda to point to the new production dining V2 API endpoint

repo: UCSD/campus-mobile


text:
[BUG - Release] Unable to Build Latest Main at time of writing.

I've been trying to build the latest main build (07bb2dd), and no matter what i do, it keeps failing to build.
Here are my commands in order, with the xmake log attached.
git clone git@github.com:UE4SS-RE/RE-UE4SS.git
cd .\RE-UE4SS\
git submodule update --init --recursive
xmake f -m "Game__Shipping__Win64"
xmake -vD

I Beleive this is an error with one of the submodules (the UEPseudo), as i cant get that to build separately either, i've also tried for hours to get this work but i've had no luck, so people smarter than me can hopefully fix this issue.
xmake_log.txt

I don't have a solution for you other than defining EAspectRatioAxisConstraint yourself somewhere.
The underlying problem is UVTD generating forward declarations for enums when that's prohibited in C++.
The solution is to fix UVTD.
That said, no one else seems to be having this problem so clearly MSVC has implemented some kind of compiler extension to allow this behavior or it's a compiler bug.
Regardless, I don't know why you have this problem and no one else.

Would it be worth it to reinstall visual studio from the ground up? Could it also be possible that 2022 Preview is somehow messing it up?

Found the problem!
It was MSVC Itself, 19.41, aka Visual Studio 2022 Preview Would NOT Compile, however 19.40, which is used in normal VS2022, works just fine. I'm thinking MSVC 19.41 Disables forward decleration of enums or somthing, but it builds now. Maybe make this a check in xmake or put in the readme to use 19.40?


text:
Parallel (make -j) build of AMPI libraries and client code is racy

Original author: Nikhil Jain
Original issue: https://charm.cs.illinois.edu/redmine/issues/143

No body.

Original date: 2013-04-05 23:27:32

This one is from ampicc/ampiCC/ampicxx symlinking our mpi.h and then deleting it when each compilation is done. In a parallel build, if one compilation races with another such that it deletes the mpi.h link that another should have followed, then it will get the system's mpi.h instead and fail horribly.
The solutions I can see include

explicitly including ampi.h instead of mpi.h, which is bad for real-world usability/adoption
leaving the mpi.h link in place, rather than deleting it
adding some bits in the makefile to delete the mpi.h link at the end, rather than while compilation is still in flight

This is something that will come up in parallel compilation of any AMPI code, so I'm not sure exactly how we want to deal with it.

Original author: Nikhil Jain
Original date: 2014-01-06 04:50:30

With Intrepid down, I doubt this task is relevant.

Original date: 2014-01-06 08:17:50

This isn't in any way BG/P specific. Please read the comments.
Subject updated to accurately reflect issue.

Original author: Nikhil Jain
Original date: 2014-01-06 09:52:45

As Phil indicated, none of the solution is a clear winner. Among the three proposed solutions, I like the second one (leaving our mpi.h in place) the best, but it may be troublesome if someone wants to compile for other MPI implementations also. I wonder if we want to do an ugly include <mpi.h> inside our mpi.h to include system implementation if not compiled using Charm's compiler. I don't even know if that will work..phew.

Original date: 2015-02-19 20:02:43

http://charm.cs.uiuc.edu/gerrit/#/c/543/

Original date: 2015-02-25 21:53:41

Broke the build with MPI on BGQ:
http://charm.cs.illinois.edu/autobuild/cur/mpi-bluegeneq-xlc.txt
http://charm.cs.illinois.edu/autobuild/cur/mpi-bluegeneq-gcc.txt

authors: PhilMiller pplimport

repo: UIUC-PPL/charm


text:
Generate libmpi.{a,so} for AMPI configure scripts

Original issue: https://charm.cs.illinois.edu/redmine/issues/1763

For increased compatibility with configure scripts, when we're not on an underlying MPI build, we can produce a libmpi.a/libmpi.so with the non-prefixed names (MPI_*) as the actual symbol names so that we don't need to hack around autoconf tests that don't include mpi.h but otherwise test MPI support.

Original date: 2017-12-20 23:46:13

This gets us AMPI's MPI_* routines to not be renamed when building on non-MPI layers: ~~https://charm.cs.illinois.edu/gerrit/#/c/3460/~~ https://github.com/UIUC-PPL/charm/commit/26085533ce2ad73c891783604856094943dc3712

Original date: 2018-01-13 19:18:14

Which application does that? Would it make sense to patch those manually (similar to what we do with hdf5)?

Original date: 2018-04-18 11:18:34

The patch above was merged and will be in 6.9.0. We could still rename our library to libmpi but just avoiding the MPI_ -> AMPI_ renaming got rid of the basic problem.

Original date: 2018-04-21 15:30:51

We now have a way to build a single libcharm.so, it would be good to follow the same approach and get a single libampi.so as well
libcharm: ~~https://charm.cs.illinois.edu/gerrit/#/c/charm/+/4040/~~ https://github.com/UIUC-PPL/charm/commit/343d50363d923c0405740c8e469b1e7176b66274


text:
Update Boost ULTs to v1.67.0

Original issue: https://charm.cs.illinois.edu/redmine/issues/1866

Boost v1.67.0 was just released and it looks like there are some minor enhancements to the context library, which we should update our copy with.

Original date: 2018-04-15 00:51:23

We could add a script to make updating this automatically easy.

Original date: 2018-04-22 15:29:29

~~https://charm.cs.illinois.edu/gerrit/#/c/charm/+/4044/~~ https://github.com/UIUC-PPL/charm/commit/d667b3ec6435cdc2893c006928b6783d90a2983a

Original date: 2018-05-02 05:21:20

It'd be good to merge this before 6.9.0-beta testing, but I don't think it's necessary

Original date: 2018-08-21 20:02:37

Updated to v1.68.0: ~~https://charm.cs.illinois.edu/gerrit/#/c/charm/+/4496/~~ https://github.com/UIUC-PPL/charm/commit/f4b77dfab172e1c00ca6d9ddbad738bf79fde829


text:
Singleton chare and nodegroup creation hangs with randomized queues in SMP mode

Original issue: https://charm.cs.illinois.edu/redmine/issues/1940

examples/charm++/fib hangs in SMP mode when using randomized queues.
This issue and the nodegroup one can also be reproduced here: https://github.com/yuchenp/smp-rq-problem

Original author: Laxmikant "Sanjay" Kale
Original date: 2019-03-14 19:30:33

Michael, make at least some update (test with a simple program on a couple of machines) by next week.

Original date: 2019-03-28 17:25:17

Tried to replicate using fib on various platforms and machines:

netlrts-darwin on local machine with ++local - works (doesn't replicate aka hang)
netlrts-linux on courage - failed to build due to arbitrary priority (bitvec)
netlrts-linux on courage with prio=int - replicates (i.e. hangs)
verbs on comet - works (doesn't replicate) with ++local, mpi-exec, and standalone
mpi on comet -and courage- - failed to build
mpi on courage - replicates

Original date: 2019-03-28 17:30:54

What do you mean by it wouldn't build for netlrts and mpi? Charm didn't build, or the example didn't build? Can you post the output?

Original date: 2019-03-28 17:41:04

In both cases, charm failed to build. In the first (netlrts) case adding a fixed width priority (e.g. int) enabled charm to build. -I don't have the output but I can recreate it and post it here.-
Here's the build line from comet:
./build charm++ mpi-linux-x86_64 smp --enable-randomized-msgq -j8

And the build error:
checking "whether C++ compiler supports C++11 with '-h std=c++11'"... "no"
Charm++ requires C++11 support, but doesn't know the flag to enable it

For Intel's compiler please see
https://charm.cs.illinois.edu/redmine/issues/1560
about making a suitable version of gcc/g++/libstdc++ available

For Blue Gene/Q please use the Clang compiler
*** Please find detailed output in tmp/charmconfig.out ***
gmake[1]: Leaving directory `/home/mprobson/charm/mpi-linux-x86_64-smp/tmp'
gmake: *** [headers] Error 2
-------------------------------------------------
Charm++ NOT BUILT. Either cd into mpi-linux-x86_64-smp/tmp and try
to resolve the problems yourself, visit
http://charm.cs.illinois.edu/
for more information. Otherwise, email the developers at charm`cs.illinois.edu

Turns out for courage it was also dying on the priotype incompatbility. Changing it from the default of bitvec to int fixes the problem and replicates the hang.

Original date: 2019-03-28 21:25:20

With some further testing, this actually appears to be an error due to the combination of SMP mode and non-bitvec/fixed length priorities, which we are forced to use with randomized queues.

authors: mprobson pplimport stwhite91


text:
chore(main): release 1.22.0

:robot: I have created a release beep boop
1.22.0 (2024-12-17)
Features

APIM-608: gov notify - file upload/link support (#1083) (dddf3e6)
APIM-609: companies house - extend returned fields (#1089) (041124c)
APIM-610: markets - add country rating description field (#1090) (11ec0d4)

Bug Fixes

APIM-608: eslint downgraded (b0e349c)
APIM-608: make GovNotify properties optional (#1082) (9240907)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.22.0
:sunflower:

repo: UK-Export-Finance/mdm-api


text:
Fix field filtering and default values

Restores capability removed in https://github.com/UKHomeOfficeForms/hof-behaviour-summary-page/pull/4 for a default value to be used in place of undefined or empty values.
Also fixes functionality claimed to be added by that PR of not filtering zero-valued fields, which was broken due to the secondary pure-Boolean filter that was applied after the initial filter.
Now fields are only removed if they have a falsy, non-zero value and no default value is supplied.

Is this to fix the scenario where we have dependent and child fields and we would get some wacky things happening unless we add this https://github.com/UKHomeOffice/right-to-rent-check/blob/master/apps/right-to-rent-check/behaviours/filter-fields.js

Not really. It's to allow optional fields that were not filled out to be displayed on the summary page with a default message.
As it stands, it's impossible to have a field without a value show on the summary page.

Ok then it looks good to me

authors: lennym sulthan-ahmed


text:
Cartodb json url is dead

GET  https://code4kc.cartodb.com/api/v2_1/viz/8167c2b8-0cf3-11e5-8080-0e9d821ea90d/viz.json [HTTP/1.1 404 Not Found 763ms]

The url for the json file that we usually get from cartodb to populate the map quit working sometime between yesterday and this evening.
@rlh-aagis
It was:
https://code4kc.cartodb.com/api/v2_1/viz/8167c2b8-0cf3-11e5-8080-0e9d821ea90d/viz.json

disregard, I found how to retrieve the new one from cartodb.
The new url is at:
https://code4kc.cartodb.com/api/v2/viz/8167c2b8-0cf3-11e5-8080-0e9d821ea90d/viz.json
The only difference appears to be the change from v2_1 to v2.
You can see the change at d739cb89e34947a714e2eea66c8ae2007d2c18d5

@Questoflranon - Please bear with me, looking to merge updates today, Glad you got CartoDb export working, hopefully we will be able to expand use of CartoDb, no guarantees but hopeful, stay tuned!

authors: QuestofIranon rlh-aagis

repo: UMKC-Law/Parcel-Assessment-Tool


text:
Crear funciones de backend para gestión de salas

Las funciones que se utilizarán tanto para la creación de salas como para unirse a una, aún no están implementadas.
Queda pendiente dejar comentadas posibles implementaciones de las funciones de acuerdo a la información transmitada por los responsables de backend.

Crear Sala hecho.

Unirse sala hecho.

Resto hechas.


text:
Add stp for unicycler

Fix
>1 circ=false len=1653372 gc=30.47 cov=1251.36 asmb=unicycler stp=False

Addressed in https://github.com/UPHL-BioNGS/Donut_Falls/pull/51


text:
Switch DB code to use the new Select api

According to the docs, the Query API of SQLAlchemy has been effectively replaced by the Select API, and is now effectively only a compatibility layer.
https://docs.sqlalchemy.org/en/20/orm/queryguide/query.html
As such, we should try to go through and move all our code to Select instead of Query.
I've tagged infra-only because this heavily involves the DB. However, I believe the vast majority of the changes don't actually need infra access - it will just need to be very thoroughly tested and have infra online at merge time in case something comes up.

I think this is probably a low priority item just because there is no current plan to deprecate the existing API. However, definitely would be good when people go in and work on the couple of areas that use the database to update the queries

authors: JamesDearlove andrewj-brown

repo: UQComputingSociety/uqcsbot-discord


text:
Create Cato funciton

A script to remind @Thomas-Malcolm of his presidential duties.

Interesting comment to send automatically.
Furthermore, I think the president should wipe off his hair

authors: Vbitz bradleysigma


text:
Remove Import a MP, Submit and Evaluate from Global View

Remove the following options from the Global/Non-logged-in View in ECMPS:

Import a Monitoring Plan
Evaluate
Submit
Revert to Official Record
Status Fields for Evaluation and Submission

Test Passed

authors: mosesdeeCVP vishnunavuluri

repo: US-EPA-CAMD/easey-ui


text:
508: Update Focus in the Create/Edit/View Method

Issue:
MP Workspace - Create/Edit Modal - Making a parameter select shifts focus to the close button instead of keeping focus where it is.
Stepps to Recreate:

Login to ECMPS, navigate to MP an Select, checkout and open a Configuration
From the Section dropdown, Select Method
Click on View/Edit or Create Method to open the modal
Make a selection in the Parameter dropdown
Observe that the focus immediately goes to X. It should stay on the selection made for Parameter

Testing complete, focus is now staying on the parameter dropdown

authors: aprematta vishnunavuluri


text:
Bugfix/content type time series

Added deprecated notification to the getAll method for TimeseriesController, and aliased application/json and \*/\* as aliases to application/json;version=2.  Added application/xml as an alias for application/xml;version=2.
Fixes #505

So, did anyone check that the old format is still accessible?

If the old format was accessible before, it shouldn't have an issue with the new code, however I didn't write any code to verify the older formats still work, unless the version was tagged as a FormattableWith on the DTO.

@MikeNeilson do you want me to add an integration test for the older format for Time Series as part of #505 ?  It'll probably take 30 mins.

authors: MikeNeilson RyanM-RMA

repo: USACE/cwms-data-api


text:
Added coveralls.io support

Hi, I've added coveralls.io support. It will build from travis and update the site. All you need to do is open a coveralls.io account and link the project. I've assumed it would be under account USCiLab/cereal but if you open coveralls account under an another name please don't forget to change the link in README

Just FYI I will merge this but want to keep the option for a local valgrind build and need to decide whether to keep our own local coverage results or just link to coveralls.

Oh, sorry about the valgrind part since most of the block was related to code coverage, I've missed that there was a custom valgrind target there.
By the way, you can run Valgrind via CTest without adding an additional target by using:

ctest -T memcheck

authors: AzothAmmo furkanusta

repo: USCiLab/cereal


text:
devtools::test warnings and errors

see travis build at https://github.com/USGS-VIZLAB/vizlab/pull/326, but the same issues are currently coming up for the master branch. i'm getting 9 warnings and 13 errors locally on both master and this PR. i'm guessing the issues are a combination of (1) sciencebase's new prohibition of public items from personal accounts, (2) formatting changes in remake's output, and maybe (3) something related to #325.
==> devtools::test()

Loading vizlab
Loading required package: testthat
Testing vizlab
analytics: ..
checkVizPackages: .....
embed: .
markdown: .........
publish: ..............
publish viz landing page: WW....
readData: ........
readDepends: .....
remake: W.................
fetchTimestamps working: .12.34567.89.ab.....WWcdWW..WW...
util: ....
viz-setup: Creating directories ...
Creating viz.yaml ...
..........
testviz: Creating .gitignore
Copying LICENSE
........
sciencebase: .
templates: ...

Warnings -----------------------------------------------------------------------
1. publishLandingPage works (@tests-publishLandingPage.R#8) - NAs introduced by coercion: . is not a real

2. publishLandingPage works (@tests-publishLandingPage.R#8) - NAs introduced by coercion: . is not a real

3. createRemakefile makes remake.yaml (@tests-remake.R#8) - cannot find dependency '' of viz item 'social-media-template' so cannot include the dependency in remake.yaml

4. sciencebase works (@tests-timestamps.R#114) - Item not found for ID=575d839ee4b04f417c2a03fe. Either the item does not exist or the item is secured and requires authentication to access.

5. sciencebase works (@tests-timestamps.R#114) - could not retrieve timestamp from ScienceBase; local timestamp information will be left as-is

6. sciencebase works (@tests-timestamps.R#122) - Item not found for ID=575d839ee4b04f417c2a03fe. Either the item does not exist or the item is secured and requires authentication to access.

7. sciencebase works (@tests-timestamps.R#122) - could not retrieve timestamp from ScienceBase; local timestamp information will be left as-is

8. sciencebase works (@tests-timestamps.R#133) - Item not found for ID=575d839ee4b04f417c2a03fe. Either the item does not exist or the item is secured and requires authentication to access.

9. sciencebase works (@tests-timestamps.R#133) - could not retrieve timestamp from ScienceBase; local timestamp information will be left as-is

Failed -------------------------------------------------------------------------
1. Failure: alwaysCurrent doesn't get rebuilt unless missing (@tests-timestamps.R#15)
`messages` does not match "[ BUILD ] data/mayfly_nymph.csv".
Actual values:
* [ \033[33m LOAD\033[39m ] \n
* (       ) vizlab/remake/timestamps/cuyahoga.txt\n
* (       ) vizlab/remake/timestamps/never_current.txt\n
* Starting build at 2018-01-10 10:00:39\n
* [ \033[33m READ\033[39m ]                                                |  \033[90m# loading sources\033[39m\n
* < \033[36m MAKE\033[39m > mayfly_nymph\n
* [ \033[34mBUILD\033[39m ] arguments_all                                  |  \033[90marguments_all <-...\033[39m\n
* [ \033[33m READ\033[39m ]                                                |  \033[90m# loading packages\033[39m\n
* [ \033[34mBUILD\033[39m ] arguments_mayfly_nymph                         |  \033[90marguments_mayfly...\033[39m\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/scripts/mayfly_nymph.R           |  \033[90mprepSources(outf...\033[39m\n
* [ \033[34mBUILD\033[39m ] data/mayfly_nymph.csv                          |  \033[90mfetch("mayfly_ny...\033[39m\n
* fetching mayfly_nymph from data/mayfly_nymph.csv to data/mayfly_nymph.csv\n
* a mayfly is a kind of insect\n
* [ \033[34mBUILD\033[39m ] mayfly_nymph                                   |  \033[90mmayfly_nymph <- ...\033[39m\n
* Finished build at 2018-01-10 10:00:39\n

2. Failure: alwaysCurrent doesn't get rebuilt unless missing (@tests-timestamps.R#18)
`messages` does not match "[    OK ] mayfly_nymph".
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt\n
* (       ) vizlab/remake/timestamps/never_current.txt\n
* Starting build at 2018-01-10 10:00:39\n
* < \033[36m MAKE\033[39m > mayfly_nymph\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_mayfly_nymph\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/mayfly_nymph.R\n
* [ \033[32m   OK\033[39m ] data/mayfly_nymph.csv\n
* [ \033[32m   OK\033[39m ] mayfly_nymph\n
* Finished build at 2018-01-10 10:00:39\n

3. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#31)
`messages` does not match "[ BUILD ] cache/fetch/never_current.txt".
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt\n
* (       ) vizlab/remake/timestamps/never_current.txt\n
* Starting build at 2018-01-10 10:00:40\n
* < \033[36m MAKE\033[39m > never_current\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/never_current.txt     |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[34mBUILD\033[39m ] arguments_never_current                        |  \033[90marguments_never_...\033[39m\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/scripts/never_current.R          |  \033[90mprepSources(outf...\033[39m\n
* [ \033[34mBUILD\033[39m ] cache/fetch/never_current.txt                  |  \033[90mfetch("never_cur...\033[39m\n
* [ \033[34mBUILD\033[39m ] never_current                                  |  \033[90mnever_current <-...\033[39m\n
* Finished build at 2018-01-10 10:00:40\n

4. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#32)
`messages` does not match "[ BUILD ] cache/fetch/cuyahoga.csv".
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt\n
* Starting build at 2018-01-10 10:00:40\n
* < \033[36m MAKE\033[39m > cuyahoga\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[34mBUILD\033[39m ] arguments_cuyahoga                             |  \033[90marguments_cuyaho...\033[39m\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/scripts/cuyahoga.R               |  \033[90mprepSources(outf...\033[39m\n
* [ \033[34mBUILD\033[39m ] cache/fetch/cuyahoga.csv                       |  \033[90mfetch("cuyahoga")\033[39m\n
* [ \033[34mBUILD\033[39m ] cuyahoga                                       |  \033[90mcuyahoga <- read...\033[39m\n
* Finished build at 2018-01-10 10:00:40\n

5. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#38)
`messages` does not match "[    OK ] cache/fetch/never_current.txt".
Actual values:
* Starting build at 2018-01-10 10:00:40\n
* < \033[36m MAKE\033[39m > never_current\n
* [ \033[32m   OK\033[39m ] vizlab/remake/timestamps/never_current.txt\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_never_current\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/never_current.R\n
* [ \033[32m   OK\033[39m ] cache/fetch/never_current.txt\n
* [ \033[32m   OK\033[39m ] never_current\n
* Finished build at 2018-01-10 10:00:40\n

6. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#39)
`messages` does not match "[    OK ] cache/fetch/cuyahoga.csv".
Actual values:
* Starting build at 2018-01-10 10:00:40\n
* < \033[36m MAKE\033[39m > cuyahoga\n
* [ \033[32m   OK\033[39m ] vizlab/remake/timestamps/cuyahoga.txt\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_cuyahoga\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/cuyahoga.R\n
* [ \033[32m   OK\033[39m ] cache/fetch/cuyahoga.csv\n
* [ \033[32m   OK\033[39m ] cuyahoga\n
* Finished build at 2018-01-10 10:00:40\n

7. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#53)
`messages` does not match "[ BUILD ] vizlab/remake/timestamps/never_current.txt".
Actual values:
* ( \033[31m  DEL\033[39m ) vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfile.remove("viz...\033[39m\n
* ( \033[31m  DEL\033[39m ) vizlab/remake/timestamps/never_current.txt     |  \033[90mfile.remove("viz...\033[39m\n
* Starting build at 2018-01-10 10:00:41\n
* < \033[36m MAKE\033[39m > never_current\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/never_current.txt     |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_never_current\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/never_current.R\n
* [ \033[34mBUILD\033[39m ] cache/fetch/never_current.txt                  |  \033[90mfetch("never_cur...\033[39m\n
* [ \033[34mBUILD\033[39m ] never_current                                  |  \033[90mnever_current <-...\033[39m\n
* Finished build at 2018-01-10 10:00:41\n

8. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#57)
`messages` does not match "[ BUILD ] cache/fetch/never_current.txt".
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt\n
* ( \033[31m  DEL\033[39m ) vizlab/remake/timestamps/never_current.txt     |  \033[90mfile.remove("viz...\033[39m\n
* Starting build at 2018-01-10 10:00:41\n
* < \033[36m MAKE\033[39m > never_current\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/never_current.txt     |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_never_current\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/never_current.R\n
* [ \033[34mBUILD\033[39m ] cache/fetch/never_current.txt                  |  \033[90mfetch("never_cur...\033[39m\n
* [ \033[34mBUILD\033[39m ] never_current                                  |  \033[90mnever_current <-...\033[39m\n
* Finished build at 2018-01-10 10:00:41\n

9. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#62)
`messages` does not match "[ BUILD ] vizlab/remake/timestamps/cuyahoga.txt".
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt\n
* ( \033[31m  DEL\033[39m ) vizlab/remake/timestamps/never_current.txt     |  \033[90mfile.remove("viz...\033[39m\n
* Starting build at 2018-01-10 10:00:41\n
* < \033[36m MAKE\033[39m > cuyahoga\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_cuyahoga\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/cuyahoga.R\n
* [ \033[32m   OK\033[39m ] cache/fetch/cuyahoga.csv\n
* [ \033[32m   OK\033[39m ] cuyahoga\n
* Finished build at 2018-01-10 10:00:41\n

10. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#64)
`messages` does not match "[    OK ] cache/fetch/cuyahoga.csv".
Actual values:
* ( \033[31m  DEL\033[39m ) vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfile.remove("viz...\033[39m\n
* (       ) vizlab/remake/timestamps/never_current.txt\n
* Starting build at 2018-01-10 10:00:42\n
* < \033[36m MAKE\033[39m > cuyahoga\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_cuyahoga\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/cuyahoga.R\n
* [ \033[32m   OK\033[39m ] cache/fetch/cuyahoga.csv\n
* [ \033[32m   OK\033[39m ] cuyahoga\n
* Finished build at 2018-01-10 10:00:42\n

11. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#69)
`messages` does not match "[ BUILD ] cache/fetch/cuyahoga.csv".
Actual values:
* ( \033[31m  DEL\033[39m ) vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfile.remove("viz...\033[39m\n
* (       ) vizlab/remake/timestamps/never_current.txt\n
* Starting build at 2018-01-10 10:00:42\n
* < \033[36m MAKE\033[39m > cuyahoga\n
* [ \033[34mBUILD\033[39m ] vizlab/remake/timestamps/cuyahoga.txt          |  \033[90mfetchTimestamp("...\033[39m\n
* [ \033[32m   OK\033[39m ] arguments_all\n
* [ \033[32m   OK\033[39m ] arguments_cuyahoga\n
* [ \033[32m   OK\033[39m ] vizlab/remake/scripts/cuyahoga.R\n
* [ \033[34mBUILD\033[39m ] cache/fetch/cuyahoga.csv                       |  \033[90mfetch("cuyahoga")\033[39m\n
* [ \033[32m   OK\033[39m ] cuyahoga\n
* Finished build at 2018-01-10 10:00:42\n

12. Failure: sciencebase works (@tests-timestamps.R#115) -----------------------
file.exists(tsfile) isn't true.

13. Failure: sciencebase works (@tests-timestamps.R#118) -----------------------
`ts1` not equal to as.POSIXct("2016-06-12 15:50:15", tz = "UTC").
Modes: logical, numeric
Attributes: < target is NULL, current is list >
target is logical, current is POSIXct

DONE ===========================================================================

For the Travis build, https://github.com/USGS-VIZLAB/vizlab/pull/336 seems to be sufficient.
For local checks, some dealing with the crayon formatting is probably still necessary.

I just now ran git pull upstream master and rebuild and checked locally. This is what I'm seeing in my vizlab/../vizlab.Rcheck/tests/testthat.Rout.fail file:

R version 3.4.3 (2017-11-30) -- "Kite-Eating Tree"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testthat)
> library(vizlab)
>
> setup <- function() {
+   testtmp <- file.path(tempdir(), "testtmp")
+   dir.create(testtmp)
+   setwd(testtmp)
+   # need to copy any other files needed for testing
+   file.copy(system.file('testviz/viz.yaml', package='vizlab'), testtmp)
+   return(testtmp)
+ }
>
> cleanup <- function(oldwd, testtmp) {
+   setwd(oldwd)
+   unlink(testtmp, recursive = TRUE)
+   invisible()
+ }
>
> test_check("vizlab")
-- 1. Failure: alwaysCurrent doesn't get rebuilt unless missing (@tests-timestamps.R#15)  -----
`vizmake("mayfly_nymph")` produced unexpected messages.
Expected match: [ BUILD ] data/mayfly_nymph.csv
Actual values:
* [  LOAD ]

* (       ) vizlab/remake/timestamps/cuyahoga.txt

* (       ) vizlab/remake/timestamps/never_current.txt

* Starting build at 2018-03-06 10:45:43

* [  READ ]                                                |  # loading sources

* <  MAKE > mayfly_nymph

* [ BUILD ] arguments_all                                  |  arguments_all <-...

* [  READ ]                                                |  # loading packages

* [ BUILD ] arguments_mayfly_nymph                         |  arguments_mayfly...

* [ BUILD ] vizlab/remake/scripts/mayfly_nymph.R           |  prepSources(outf...

* [ BUILD ] data/mayfly_nymph.csv                          |  fetch("mayfly_ny...

* fetching mayfly_nymph from data/mayfly_nymph.csv to data/mayfly_nymph.csv

* a mayfly is a kind of insect

* [ BUILD ] mayfly_nymph                                   |  mayfly_nymph <- ...

* Finished build at 2018-03-06 10:45:43

-- 2. Failure: alwaysCurrent doesn't get rebuilt unless missing (@tests-timestamps.R#18)  -----
`vizmake("mayfly_nymph")` produced unexpected messages.
Expected match: [    OK ] mayfly_nymph
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt

* (       ) vizlab/remake/timestamps/never_current.txt

* Starting build at 2018-03-06 10:45:43

* <  MAKE > mayfly_nymph

* [    OK ] arguments_all

* [    OK ] arguments_mayfly_nymph

* [    OK ] vizlab/remake/scripts/mayfly_nymph.R

* [    OK ] data/mayfly_nymph.csv

* [    OK ] mayfly_nymph

* Finished build at 2018-03-06 10:45:43

-- 3. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#
`vizmake("never_current")` produced unexpected messages.
Expected match: [ BUILD ] cache/fetch/never_current.txt
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt

* (       ) vizlab/remake/timestamps/never_current.txt

* Starting build at 2018-03-06 10:45:44

* <  MAKE > never_current

* [ BUILD ] vizlab/remake/timestamps/never_current.txt     |  fetchTimestamp("...

* [    OK ] arguments_all

* [ BUILD ] arguments_never_current                        |  arguments_never_...

* [ BUILD ] vizlab/remake/scripts/never_current.R          |  prepSources(outf...

* [ BUILD ] cache/fetch/never_current.txt                  |  fetch("never_cur...

* [ BUILD ] never_current                                  |  never_current <-...

* Finished build at 2018-03-06 10:45:44

-- 4. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#
`vizmake("cuyahoga")` produced unexpected messages.
Expected match: [ BUILD ] cache/fetch/cuyahoga.csv
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt

* Starting build at 2018-03-06 10:45:44

* <  MAKE > cuyahoga

* [ BUILD ] vizlab/remake/timestamps/cuyahoga.txt          |  fetchTimestamp("...

* [    OK ] arguments_all

* [ BUILD ] arguments_cuyahoga                             |  arguments_cuyaho...

* [ BUILD ] vizlab/remake/scripts/cuyahoga.R               |  prepSources(outf...

* [ BUILD ] cache/fetch/cuyahoga.csv                       |  fetch("cuyahoga")

* [ BUILD ] cuyahoga                                       |  cuyahoga <- read...

* Finished build at 2018-03-06 10:45:44

-- 5. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#
`vizmake("never_current")` produced unexpected messages.
Expected match: [    OK ] cache/fetch/never_current.txt
Actual values:
* Starting build at 2018-03-06 10:45:44

* <  MAKE > never_current

* [    OK ] vizlab/remake/timestamps/never_current.txt

* [    OK ] arguments_all

* [    OK ] arguments_never_current

* [    OK ] vizlab/remake/scripts/never_current.R

* [    OK ] cache/fetch/never_current.txt

* [    OK ] never_current

* Finished build at 2018-03-06 10:45:44

-- 6. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#
`vizmake("cuyahoga")` produced unexpected messages.
Expected match: [    OK ] cache/fetch/cuyahoga.csv
Actual values:
* Starting build at 2018-03-06 10:45:44

* <  MAKE > cuyahoga

* [    OK ] vizlab/remake/timestamps/cuyahoga.txt

* [    OK ] arguments_all

* [    OK ] arguments_cuyahoga

* [    OK ] vizlab/remake/scripts/cuyahoga.R

* [    OK ] cache/fetch/cuyahoga.csv

* [    OK ] cuyahoga

* Finished build at 2018-03-06 10:45:44

-- 7. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#53)  -----------
`vizmake("never_current")` produced unexpected messages.
Expected match: [ BUILD ] vizlab/remake/timestamps/never_current.txt
Actual values:
* (   DEL ) vizlab/remake/timestamps/cuyahoga.txt          |  file.remove("viz...

* (   DEL ) vizlab/remake/timestamps/never_current.txt     |  file.remove("viz...

* Starting build at 2018-03-06 10:45:44

* <  MAKE > never_current

* [ BUILD ] vizlab/remake/timestamps/never_current.txt     |  fetchTimestamp("...

* [    OK ] arguments_all

* [    OK ] arguments_never_current

* [    OK ] vizlab/remake/scripts/never_current.R

* [ BUILD ] cache/fetch/never_current.txt                  |  fetch("never_cur...

* [ BUILD ] never_current                                  |  never_current <-...

* Finished build at 2018-03-06 10:45:44

-- 8. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#57)  -----------
`vizmake("never_current")` produced unexpected messages.
Expected match: [ BUILD ] cache/fetch/never_current.txt
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt

* (   DEL ) vizlab/remake/timestamps/never_current.txt     |  file.remove("viz...

* Starting build at 2018-03-06 10:45:44

* <  MAKE > never_current

* [ BUILD ] vizlab/remake/timestamps/never_current.txt     |  fetchTimestamp("...

* [    OK ] arguments_all

* [    OK ] arguments_never_current

* [    OK ] vizlab/remake/scripts/never_current.R

* [ BUILD ] cache/fetch/never_current.txt                  |  fetch("never_cur...

* [ BUILD ] never_current                                  |  never_current <-...

* Finished build at 2018-03-06 10:45:44

-- 9. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#62)  -----------
`vizmake("cuyahoga")` produced unexpected messages.
Expected match: [ BUILD ] vizlab/remake/timestamps/cuyahoga.txt
Actual values:
* (       ) vizlab/remake/timestamps/cuyahoga.txt

* (   DEL ) vizlab/remake/timestamps/never_current.txt     |  file.remove("viz...

* Starting build at 2018-03-06 10:45:44

* <  MAKE > cuyahoga

* [ BUILD ] vizlab/remake/timestamps/cuyahoga.txt          |  fetchTimestamp("...

* [    OK ] arguments_all

* [    OK ] arguments_cuyahoga

* [    OK ] vizlab/remake/scripts/cuyahoga.R

* [    OK ] cache/fetch/cuyahoga.csv

* [    OK ] cuyahoga

* Finished build at 2018-03-06 10:45:44

-- 10. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#64)  ----------
`vizmake("cuyahoga")` produced unexpected messages.
Expected match: [    OK ] cache/fetch/cuyahoga.csv
Actual values:
* (   DEL ) vizlab/remake/timestamps/cuyahoga.txt          |  file.remove("viz...

* (       ) vizlab/remake/timestamps/never_current.txt

* Starting build at 2018-03-06 10:45:45

* <  MAKE > cuyahoga

* [ BUILD ] vizlab/remake/timestamps/cuyahoga.txt          |  fetchTimestamp("...

* [    OK ] arguments_all

* [    OK ] arguments_cuyahoga

* [    OK ] vizlab/remake/scripts/cuyahoga.R

* [    OK ] cache/fetch/cuyahoga.csv

* [    OK ] cuyahoga

* Finished build at 2018-03-06 10:45:45

-- 11. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#69)  ----------
`vizmake("cuyahoga")` produced unexpected messages.
Expected match: [ BUILD ] cache/fetch/cuyahoga.csv
Actual values:
* (   DEL ) vizlab/remake/timestamps/cuyahoga.txt          |  file.remove("viz...

* (       ) vizlab/remake/timestamps/never_current.txt

* Starting build at 2018-03-06 10:45:45

* <  MAKE > cuyahoga

* [ BUILD ] vizlab/remake/timestamps/cuyahoga.txt          |  fetchTimestamp("...

* [    OK ] arguments_all

* [    OK ] arguments_cuyahoga

* [    OK ] vizlab/remake/scripts/cuyahoga.R

* [ BUILD ] cache/fetch/cuyahoga.csv                       |  fetch("cuyahoga")

* [    OK ] cuyahoga

* Finished build at 2018-03-06 10:45:45

== testthat results  ==========================================================================
OK: 121 SKIPPED: 2 FAILED: 11
1. Failure: alwaysCurrent doesn't get rebuilt unless missing (@tests-timestamps.R#15)
2. Failure: alwaysCurrent doesn't get rebuilt unless missing (@tests-timestamps.R#18)
3. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#31)
4. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#32)
5. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#38)
6. Failure: before time to live, even neverCurrent doesn't get rebuilt (@tests-timestamps.R#39)
7. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#53)
8. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#57)
9. Failure: after time to live, timestamp gets checked (@tests-timestamps.R#62)
1. ...

Error: testthat unit tests failed
Execution halted

Every error is actually about unexpected messages, which I think goes back to the crayon formatting of remake messages (https://github.com/richfitz/remake/blob/95752124430c4a57cedb0c23fc6642aebee10498/R/utils.R#L379).

Not getting errors any more!

repo: USGS-VIZLAB/vizlab


text:
Improved config workflow

This deals with #193 (1) and (3)

nice, that really cleans it up!

Coverage increased (+0.2%) to 76.776% when pulling ef7ec13d89422f8a0a60b2004904f192d8c114df on ldecicco-USGS:rebuild into 3e6ba1483d7932d4f26b445175e4c6cc89671fa2 on USGS-VIZLAB:0.2.x.

I believe this also sometimes addresses #193 (2), because now every call to updateConfigInfoFile() has the potential to update the .rds file and its timestamp.
Best case (and common) scenario:
You build iris-data once. You edit the configuration for iris-data (ignore https://github.com/USGS-VIZLAB/vizlab/issues/207 for now) in viz.yaml. You call make -f vizlab/make/fetch.make iris-data.  make notices that cache/config/iris-data.rds is out of date relative to viz.yaml, so it calls updateConfigInfoFile, whcih updates cache/config/iris-data.rds. Next time you build iris-data, iris-data.rds will already be up to date and won't result in any more calls to updateConfigInfoFile (until viz.yaml is updated again). Perfect!
Suboptimal (and also common) scenario:
You build iris-data once. You edit the configuration for other things, but not iris-data, in viz.yaml. You call make -f vizlab/make/fetch.make iris-data.  make notices that cache/config/iris-data.rds is out of date relative to viz.yaml, so it calls updateConfigInfoFile, and because iris-data config hasn't changed, cache/config/iris-data.rds is not altered. This is great because now iris-data won't rebuild, because it's already up to date relative to iris-data.rds. The suboptimal part is that every time you build iris-data without actually editing the iris-data info in viz.yaml, updateConfigInfoFile will get called again (and again will do nothing to iris-data.rds). So we're looking at a lot of calls to updateConfigInfoFile for this and other targets.
I think I'm OK will both the best-case and the suboptimal scenarios. There's probably some way to fix the latter, but I don't see an elegant one right now, and I think the costs to users will not be high. Let's roll with it, and we can consider a further optimization in the future if it turns out to be too slow in practice.

authors: aappling-usgs coveralls ldecicco-USGS


text:
Question regarding Mamba

Thank you for your interesting work on RL for CMDPs. I noticed the addition of MAMBA to the repository, which wasn't mentioned in the paper. Are there any plans to release the results for AMAGO-MAMBA to the public?
Thanks for your contributions once again.

Hi, thanks!
Yes I added Mamba many months after the experiments for the paper were done. A nice thing about how the repo is setup is that it's pretty straightforward to use any seq2seq model, even though the paper focuses on Transformers specifically.
I've only played around with Mamba a little bit as a test. Here are the results that I have, but a lot more experimentation is needed:

Mamba is super cool, but I think RL is a difficult area for state space models in general. Relying on RL credit assignment to learn hidden state reads/writes has always been hard, even though Mamba seems like a big improvement in that area. Transformers only need to use RL to learn recall of the sequence at each timestep which is much simpler. So far I think the sequences would have to be very long - or inference speed would have to be a major constraint - to justify not using a Transformer.

Hi, thanks!
Yes I added Mamba many months after the experiments for the paper were done. A nice thing about how the repo is setup is that it's pretty straightforward to use any seq2seq model, even though the paper focuses on Transformers specifically.
I've only played around with Mamba a little bit as a test. Here are the results that I have, but a lot more experimentation is needed:

Mamba is super cool, but I think RL is a difficult area for state space models in general. Relying on RL credit assignment to learn hidden state reads/writes has always been hard, even though Mamba seems like a big improvement in that area. Transformers only need to use RL to learn recall of the sequence at each timestep which is much simpler. So far I think the sequences would have to be very long - or inference speed would have to be a major constraint - to justify not using a Transformer.

The tasks demonstrated in POPGym heavily test the model's ability to handle copying. For transformers, it's just a matter of retrieval within the context, whereas for recurrent structures, it requires reconstructing all information from a hidden state. The results you presented nicely validate this point. However, in some recent SSM + RL works such as R2I they have demonstrated scores above 0.5 on these tasks in POPGym (though still not as good as AMAGO). The differences between their results and yours are worth considering. Perhaps AMAGO is better suited for transformers while Dreamer is more suitable for recurrent structures?
Additionally, I have some questions regarding the performance of key-to-door. In the paper, AMAGO achieves scores of over 40, but the baseline shown in the images is only 12. How did this difference arise?

Yes I totally agree that POPGym is especially well suited for Transformers. Not sure on the Transformer/AMAGO vs. RNN/Dreamer comparison... I'd imagine Transformer world models would have a similar advantage when predicting dynamics of memory intensive envs. But I think it will take a Dreamer-like engineering effort to find out if that's true in this setting. Hopefully future work.
The performance gap you reference is just caused by a difference in timestep budget. In the figure above i'm taking the score of the Transformer after 7M frames; in the paper the x axis is much longer.

Yes I totally agree that POPGym is especially well suited for Transformers. Not sure on the Transformer/AMAGO vs. RNN/Dreamer comparison... I'd imagine Transformer world models would have a similar advantage when predicting dynamics of memory intensive envs. But I think it will take a Dreamer-like engineering effort to find out if that's true in this setting. Hopefully future work.
The performance gap you reference is just caused by a difference in timestep budget. In the figure above i'm taking the score of the Transformer after 7M frames; in the paper the x axis is much longer.

Thank you for your response! Your work is very interesting. My questions have been mostly answered.

repo: UT-Austin-RPL/amago


text:
Try to flatten file structure

Make a new branch and try moving robotserver.py and it's config files down to the root
rename  robotserver.py to robot.py

To try this you will need to ssh onto the pi ( @mr-eggleton or @mr-evans can get you started). commands needed are:
Change to the correct folder

cd ~/robot-enrichment

To create the branch

git checkout -b 23_flatten

To move the conf files

mv python/*.conf .
mv robot.py old-robot.py
mv python/robotserver.py robot.py

To try it (I wouldn't expect it to work first time)

sudo python robot.py

repo: UTC-Sheffield/robot-enrichment