build problem: stddef.not found

Sorry if this is not the right venue for this question, but it looks like a problem with the cppcoro build.
On ubuntu 16.04,
I installed clang 6 using apt and manually build libc++ per your installation instructions.
yfinkelstein@ubuntu16:~/cppcoro$ ls -la /usr/lib/llvm-6.0/
total 48
drwxr-xr-x   8 root root  4096 Aug 23 13:49 .
drwxr-xr-x 166 root root 12288 Aug 23 16:19 ..
drwxr-xr-x   2 root root  4096 Aug 23 13:49 bin
drwxr-xr-x   2 root root  4096 Aug 23 13:49 build
lrwxrwxrwx   1 root root    14 Aug  6 21:32 cmake -> lib/cmake/llvm
drwxr-xr-x   4 root root  4096 Aug 23 15:31 include
drwxr-xr-x   4 root root 12288 Aug 23 15:31 lib
drwxr-xr-x   2 root root  4096 Aug 23 13:49 libexec
drwxr-xr-x   7 root root  4096 Aug 23 13:49 share

libc++ is installed under llvm:
yfinkelstein@ubuntu16:~/cppcoro$ ls -la /usr/lib/llvm-6.0/include/c++
total 12
drwxr-xr-x 3 root root 4096 Aug 23 15:31 .
drwxr-xr-x 4 root root 4096 Aug 23 15:31 ..
drwxr-xr-x 6 root root 4096 Aug 23 15:31 v1

But while building cppcoro  I inevitably get this error:
/usr/bin/clang: failed with exit code -2
In file included from lib/async_auto_reset_event.cpp:6:
In file included from ./include/cppcoro/async_auto_reset_event.hpp:8:
In file included from /usr/lib/llvm-6.0/bin/../include/c++/v1/experimental/coroutine:50:
In file included from /usr/lib/llvm-6.0/bin/../include/c++/v1/new:89:
In file included from /usr/lib/llvm-6.0/bin/../include/c++/v1/exception:81:
/usr/lib/llvm-6.0/bin/../include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found
#include_next <stddef.h>
              ^~~~~~~~~~

I decided to also copy stdc++ headers under /usr/include just in case but that does not help.
Below are all versions of stddef.h that I have:
finkelstein@ubuntu16:~/cppcoro$ find /usr -name stddef.h
/usr/lib/llvm-6.0/lib/clang/6.0.0/include/stddef.h
/usr/lib/llvm-6.0/include/c++/v1/stddef.h
/usr/lib/gcc/x86_64-linux-gnu/5/include/stddef.h
/usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h
/usr/include/linux/stddef.h
/usr/include/c++/v1/stddef.h
/usr/src/linux-headers-4.4.0-92/include/uapi/linux/stddef.h
/usr/src/linux-headers-4.4.0-92/include/linux/stddef.h

I left the 2 key properties in config.cake intact:
  clangInstallPrefix = '/usr'

  # Set this to the install-prefix of where libc++ is installed.
  # You only need to set this if it is not installed at the same
  # location as clangInstallPrefix.
  libCxxInstallPrefix = None # '/path/to/install'

Is there something wrong with my setup?
Thanks!
P.S.
Your project is quite exciting and I'm really curious what kind of performance I would get with thousands of coroutines and multiple threads.

Thanks for trying the project out :)
This problem usually seems to manifest when clang can't find its own headers.
ie. the headers found under {{lib/Headers}} in the clang source tree.
It looks like you've got these installed under {{/usr/lib/llvm-6.0/lib/clang/6.0.0/include}}.
You can get the compiler to output the include paths by adding compiler.addCppFlag('-v') to the config.cake.
You can see what command-line is being run by adding --debug=run to the cake command-line.
If you can't see this include path in the compiler output then try adding a line like the following to config.cake:
compiler.addCppFlag('-isystem/usr/lib/llvm-6.0/lib/clang/6.0.0/include')

After adding -v and --debug=run:
clang version 6.0.0-svn310235-1~exp1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/lib/llvm-6.0/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-llvm-bc -flto -flto-unit -disable-free -disable-llvm-verifier -discard-value-names -main-file-name main.cpp -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file /home/yfinkelstein/cppcoro/build/linux_x64_clang5.0_optimised/test/obj/main.gcno -resource-dir /usr/lib/llvm-6.0/lib/clang/6.0.0 -dependency-file /tmp/CakeGccDepY6aKOj -MT build/linux_x64_clang5.0_optimised/test/obj/main.o -sys-header-deps -D CPPCORO_RELEASE_OPTIMISED -I ./include -internal-isystem /usr/include/clang/6.0.0/include/ -internal-isystem /usr/lib/llvm-6.0/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-6.0/lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -std=c++1z -fdeprecated-macro -fdebug-compilation-dir /home/yfinkelstein/cppcoro -ferror-limit 19 -fmessage-length 0 -fcoroutines-ts -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o build/linux_x64_clang5.0_optimised/test/obj/main.o -x c++ test/main.cpp
clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
ignoring duplicate directory "/usr/include/clang/6.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
 ./include
 /usr/include/clang/6.0.0/include
 /usr/lib/llvm-6.0/bin/../include/c++/v1
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
In file included from test/main.cpp:7:
In file included from test/doctest/doctest.h:460:
/usr/lib/llvm-6.0/bin/../include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found
#include_next <stddef.h>
              ^~~~~~~~~~
1 error generated.

-internal-isystem /usr/include/clang/6.0.0/include/
Is there missing white space between -internal and -isystem ?

I wonder if the issue is that the include paths are in the wrong order?
ie. that cstddef in libc++ is using #include_next <stddef.h> but the stddef.h is found earlier in the list of include paths.
What if you use -isystem-after instead of -isystem to append the clang include path to the end of the list of search paths?

compiler.addCppFlag('-isystem-after/usr/lib/llvm-6.0/lib/clang/6.0.0/include')
clang: warning: argument unused during compilation: '-isystem-after /usr/lib/llvm-6.0/lib/clang/6.0.0/include' [-Wunused-command-line-argument]

and the same error

I just noticed that file /usr/include/linux/stddef.h  is actually empty on my system and all other versions of this file are actually different:
yfinkelstein@ubuntu16:~/cppcoro$ find /usr/ -name stddef.h -exec ls -la {} \;
-rw-r--r-- 1 root root 4498 Aug  6 17:09 /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stddef.h
-rw-r--r-- 1 root root 1297 Aug 23 15:20 /usr/lib/llvm-6.0/include/c++/v1/stddef.h
-rw-r--r-- 1 root root 13754 Sep  4  2016 /usr/lib/gcc/x86_64-linux-gnu/5/include/stddef.h
-rw-r--r-- 1 root root 13754 May 21 10:13 /usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h
-rw-r--r-- 1 root root 28 Jan 10  2016 /usr/src/linux-headers-4.4.0-92/include/uapi/linux/stddef.h
-rw-r--r-- 1 root root 581 Jan 10  2016 /usr/src/linux-headers-4.4.0-92/include/linux/stddef.h

Yes, {{/usr/include/linux/stddef.h}} is either empty or a one-liner on my system.
I'll look into the issue further and get back to you.

Just fyi,
I head better luck after settings libCxxInstallPrefix = '/usr/lib/llvm-6.0'
Only 2 compilation errors this time and they are different:
yfinkelstein@ubuntu16:~/cppcoro$ cake
Building with /home/yfinkelstein/cppcoro/config.cake - Variant(release='optimised', platform='linux', architecture='x64', compiler='clang')
Building with /home/yfinkelstein/cppcoro/config.cake - Variant(release='debug', platform='linux', architecture='x64', compiler='clang')
Archiving build/linux_x64_clang6.0_optimised/lib/libcppcoro.a
Archiving build/linux_x64_clang6.0_debug/lib/libcppcoro.a
/bin/sh: 1: /usr/bin/llvm-ar: not found
/usr/bin/llvm-ar: failed with exit code 127
/bin/sh: 1: /usr/bin/llvm-ar: not found
/usr/bin/llvm-ar: failed with exit code 127
Build failed with 2 errors.
The following targets failed to build:
- build/linux_x64_clang6.0_optimised/lib/libcppcoro.a
- build/linux_x64_clang6.0_debug/lib/libcppcoro.a
Build took 0:00:00.112.

And after symlinking llvm-ar:
Building with /home/yfinkelstein/cppcoro/config.cake - Variant(release='optimised', platform='linux', architecture='x64', compiler='clang')
Building with /home/yfinkelstein/cppcoro/config.cake - Variant(release='debug', platform='linux', architecture='x64', compiler='clang')
Archiving build/linux_x64_clang6.0_optimised/lib/libcppcoro.a
Archiving build/linux_x64_clang6.0_debug/lib/libcppcoro.a
Linking build/linux_x64_clang6.0_optimised/test/run
Linking build/linux_x64_clang6.0_debug/test/run
LLD 6.0.0 (compatible with GNU linkers)
/usr/bin/ld.lld: error: unable to find library -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/bin/clang: failed with exit code 1
LLD 6.0.0 (compatible with GNU linkers)
/usr/bin/ld.lld: error: unable to find library -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/bin/clang: failed with exit code 1
Build failed with 2 errors.
The following targets failed to build:
- build/linux_x64_clang6.0_debug/test/run
- build/linux_x64_clang6.0_optimised/test/run
Build took 0:00:00.223.

Indeed, I don't have libc++abi* in my system:
yfinkelstein@ubuntu16:~/cppcoro$ find /usr -name libc++*
/usr/local/lib/libc++.so
/usr/local/lib/libc++.so.1
/usr/local/lib/libc++.so.1.0
/usr/local/lib/libc++.a
/usr/local/lib/libc++experimental.a
/usr/lib/libc++.so
/usr/lib/llvm-6.0/lib/libc++.so
/usr/lib/llvm-6.0/lib/libc++.so.1
/usr/lib/llvm-6.0/lib/libc++.so.1.0
/usr/lib/llvm-6.0/lib/libc++.a
/usr/lib/llvm-6.0/lib/libc++experimental.a
/usr/lib/libc++.so.1
/usr/lib/libc++.so.1.0
/usr/lib/libc++.a
/usr/lib/libc++experimental.a

Looks like your libc++ was built against a different ABI to mine.
Most likely is it was built against libstdc++.
Try changing compiler.addLibrary('c++abi') to compiler.addLibrary('stdc++')

enabled verbose linking and removed c++abi:
LLD 6.0.0 (compatible with GNU linkers)
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/crt1.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/crti.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/crtbegin.o
build/linux_x64_clang6.0_debug/test/obj/main.o
build/linux_x64_clang6.0_debug/test/obj/counted.o
build/linux_x64_clang6.0_debug/test/obj/generator_tests.o
build/linux_x64_clang6.0_debug/test/obj/recursive_generator_tests.o
build/linux_x64_clang6.0_debug/test/obj/async_generator_tests.o
build/linux_x64_clang6.0_debug/test/obj/async_auto_reset_event_tests.o
build/linux_x64_clang6.0_debug/test/obj/async_manual_reset_event_tests.o
build/linux_x64_clang6.0_debug/test/obj/async_mutex_tests.o
build/linux_x64_clang6.0_debug/test/obj/cancellation_token_tests.o
build/linux_x64_clang6.0_debug/test/obj/task_tests.o
build/linux_x64_clang6.0_debug/test/obj/shared_task_tests.o
build/linux_x64_clang6.0_debug/test/obj/sync_wait_tests.o
build/linux_x64_clang6.0_debug/test/obj/when_all_tests.o
build/linux_x64_clang6.0_debug/test/obj/when_all_ready_tests.o
/usr/lib/llvm-6.0/lib/libc++.so.1
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libstdc++.so
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libc_nonshared.a(elf-init.oS)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/libpthread.so.0
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(async_auto_reset_event.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(async_manual_reset_event.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(async_mutex.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(cancellation_token.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(cancellation_state.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(cancellation_source.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(cancellation_registration.o)
build/linux_x64_clang6.0_debug/lib/libcppcoro.a(lightweight_manual_reset_event.o)
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libgcc_s.so.1
/lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libgcc_s.so.1
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/crtend.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld.lld: error: duplicate symbol: range(int, int)
>>> defined at generator_tests.cpp:194 (test/generator_tests.cpp:194)
>>>            build/linux_x64_clang6.0_debug/test/obj/generator_tests.o:(range(int, int))
>>> defined at recursive_generator_tests.cpp:376 (test/recursive_generator_tests.cpp:376)
>>>            build/linux_x64_clang6.0_debug/test/obj/recursive_generator_tests.o:(.text+0x6C50)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/bin/clang: failed with exit code 1
Build failed with 2 errors.

where do get an abi library to build libc++ with ?

When building libc++, I did this:

cmake -GNinja \
      -DCMAKE_CXX_COMPILER="/usr/bin/clang++" \
      -DCMAKE_C_COMPILER="/usr/bin/clang" \
      -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_INSTALL_PREFIX="/usr" \
      -DLLVM_PATH="../llvm" \
      -DLIBCXX_CXX_ABI=libstdc++ \
      -DLIBCXX_CXX_ABI_INCLUDE_PATHS="/usr/include/x86_64-linux-gnu/c++/6" \
      ../libcxx

That's where libstdc++ is coming from. But what should be the right value for ABI include path?

The errors you are seeing now about duplicate range symbols looks likes my incorrect usage of doctest.h.
I'm not sure why I didn't see that on my setup.
I had assumed that TEST_SUITE_BEGIN macro was creating an anonymous namespace in which the test cases would be placed. However upon closer inspection it seems that isn't the case.
For now you can get around this by either renaming the range() functions in recursive_generator_tests.cpp or enclosing it in an anonymous namespace.

I took care of renaming range function but there is something else now:
/usr/bin/ld.lld: error: undefined symbol: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
>>> referenced by ld-temp.o
>>>               lto.tmp:(doctest::detail::Result doctest::detail::Expression_lhs<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>::operator==<char [4]>(char const (&) [4]))

/usr/bin/ld.lld: error: symbol 'std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)' defined in build/linux_x64_clang6.0_optimised/test/obj/shared_task_tests.o has no type
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/bin/clang: failed with exit code 1
Build failed with 2 errors.

Here is a complete output after repeating the cake command:
yfinkelstein@ubuntu16:~/cppcoro$ cake
Building with /home/yfinkelstein/cppcoro/config.cake - Variant(release='optimised', platform='linux', architecture='x64', compiler='clang')
Building with /home/yfinkelstein/cppcoro/config.cake - Variant(release='debug', platform='linux', architecture='x64', compiler='clang')
Linking build/linux_x64_clang6.0_optimised/test/run
Testing build/linux_x64_clang6.0_debug/test/run
exception_ptr not yet implemented
[doctest] doctest version is "1.2.1"
[doctest] run with "--help" for options
test build/linux_x64_clang6.0_debug/test/run failed with exit code -11 (0x-000000b)
LLD 6.0.0 (compatible with GNU linkers)
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/crt1.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/crti.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/crtbegin.o
build/linux_x64_clang6.0_optimised/test/obj/main.o
build/linux_x64_clang6.0_optimised/test/obj/counted.o
build/linux_x64_clang6.0_optimised/test/obj/generator_tests.o
build/linux_x64_clang6.0_optimised/test/obj/recursive_generator_tests.o
build/linux_x64_clang6.0_optimised/test/obj/async_generator_tests.o
build/linux_x64_clang6.0_optimised/test/obj/async_auto_reset_event_tests.o
build/linux_x64_clang6.0_optimised/test/obj/async_manual_reset_event_tests.o
build/linux_x64_clang6.0_optimised/test/obj/async_mutex_tests.o
build/linux_x64_clang6.0_optimised/test/obj/cancellation_token_tests.o
build/linux_x64_clang6.0_optimised/test/obj/task_tests.o
build/linux_x64_clang6.0_optimised/test/obj/shared_task_tests.o
build/linux_x64_clang6.0_optimised/test/obj/sync_wait_tests.o
build/linux_x64_clang6.0_optimised/test/obj/when_all_tests.o
build/linux_x64_clang6.0_optimised/test/obj/when_all_ready_tests.o
/usr/lib/llvm-6.0/lib/libc++.so.1
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libstdc++.so
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libstdc++.so
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libc_nonshared.a(elf-init.oS)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/libpthread.so.0
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(async_auto_reset_event.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(async_manual_reset_event.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(async_mutex.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(cancellation_token.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(cancellation_state.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(cancellation_source.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(cancellation_registration.o)
build/linux_x64_clang6.0_optimised/lib/libcppcoro.a(lightweight_manual_reset_event.o)
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libgcc_s.so.1
/lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/libgcc_s.so.1
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/crtend.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld.lld: error: undefined symbol: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
>>> referenced by ld-temp.o
>>>               lto.tmp:(doctest::detail::Result doctest::detail::Expression_lhs<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>::operator==<char [4]>(char const (&) [4]))

/usr/bin/ld.lld: error: symbol 'std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)' defined in build/linux_x64_clang6.0_optimised/test/obj/shared_task_tests.o has no type
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/bin/clang: failed with exit code 1
Build failed with 2 errors.
The following targets failed to build:
- build/linux_x64_clang6.0_debug/test/run.results
- build/linux_x64_clang6.0_optimised/test/run
Build took 0:00:11.467.
yfinkelstein@ubuntu16:~/cppcoro$

Looks like the debug version build the test executable successfully while optimized fails to build.
But running the debug test produces this:
./build/linux_x64_clang6.0_debug/test/run
[doctest] doctest version is "1.2.1"
[doctest] run with "--help" for options
exception_ptr not yet implemented
Segmentation fault (core dumped)

So, looks like the linux build is not quite ready for testing yet?

I've pushed a number of fixes for the build errors you encountered.
I pulled the latest clang snapshot (svn 311618) and it seemed to build and pass debug ok.
What version of clang are you using? There was a clang coroutines fix that went in quite recently (within the last day or so).
I'm still getting failing shared_task tests under optimised, but I suspect that might be a compiler bug.

ok, with the latest changes both debug and optimized builds are producing binaries, but both are failing at run-time with exit code -11. I have installed clang 6 pre-built binaries, and the latest version is clang version 6.0.0-svn310235-1~exp1 (trunk) I guess this is why I'm getting the error per your explanation.
Anyway, in your readme section on libc++ build on linux you might want to mention the specific values of env       -DCMAKE_INSTALL_PREFIX=
-DLIBCXX_CXX_ABI_INCLUDE_PATHS that you are assuming will work  in order to keep  libCxxInstallPrefix = None. This will help people avoid the same problems a was getting with compilation. Only after I set
libCxxInstallPrefix = '/usr/lib/llvm-6.0'
I was able to compile.
The issue can be closed. Thanks.

I'll look at improving the build instructions in the README.
Thanks for the feedback.

I updated clang to 6.0.0-svn311787-1~exp1 (trunk) which is greater than 311618 you mentioned above.
I get
exception_ptr not yet implemented
test build/linux_x64_clang6.0_debug/test/run failed with exit code -11 (0x-000000b)

on both debug and optimized builds. Is this not what you are getting?

I'm not seeing that error on my setup (Ubuntu 17.04) when building with clang snapshot 6.0.0-svn311829-1~exp1 (trunk) and with libcxx built from source (llvm svn-311982, libcxx svn-311967).
Running source init.sh ; cake in workspace root successfully passes debug build variant.
Optimised build variant fails with exit code -11 with the error:
Testing build/linux_x64_clang5.0_optimised/test/run
*** Error in `build/linux_x64_clang5.0_optimised/test/run': double free or corruption (out): 0x0007ffe3e359090 ***
=== Backtrace ===
....

Look at sources of libc++ it looks like that error message occurs if libc++ was not built against glibc++.
See libcxx/src/exception.cpp and libcxx/src/support/runtime/exception_pointer_unimplemented.ipp.
Perhaps there's an issue with the way you're building libcxx?
 After rebuilding libc++ with this build spec I get the debug build tests passing:
yfinkelstein@ubuntu16:~/cppcoro$ ./build/linux_x64_clang6.0_debug/test/run
[doctest] doctest version is "1.2.1"
[doctest] run with "--help" for options
===============================================================================
test/cancellation_token_tests.cpp(260)
TEST SUITE: cancellation_token tests
TEST CASE:  cancellation registration single-threaded performance

test/cancellation_token_tests.cpp(333) MESSAGE!
  Individual took 16622us (166.22 ns/item)

test/cancellation_token_tests.cpp(333) MESSAGE!
  Batch10 took 204533us (204.533 ns/item)

test/cancellation_token_tests.cpp(333) MESSAGE!
  Batch50 took 1022302us (204.46 ns/item)

===============================================================================
test/recursive_generator_tests.cpp(343)
TEST SUITE: recursive_generator
TEST CASE:  recursive iteration performance

test/recursive_generator_tests.cpp(360) MESSAGE!
  Range iteration of 100000elements took 14938us

===============================================================================
[doctest] test cases:     91 |     91 passed |      0 failed |      0 skipped
[doctest] assertions: 1000348 | 1000348 passed |      0 failed |
[doctest] Status: SUCCESS!

Not sure what made the difference, but at least I can start experimentation. Thanks again for quick responses.

Thanks for trying the project out :)
This problem usually seems to manifest when clang can't find its own headers.
ie. the headers found under lib/Headers in the clang source tree.
It looks like you've got these installed under /usr/lib/llvm-6.0/lib/clang/6.0.0/include.
You can get the compiler to output the include paths by adding compiler.addCppFlag('-v') to the config.cake.
You can see what command-line is being run by adding --debug=run to the cake command-line.
If you can't see this include path in the compiler output then try adding a line like the following to config.cake:
compiler.addCppFlag('-isystem/usr/lib/llvm-6.0/lib/clang/6.0.0/include')

I meet the error that #include_next <stddef.h> that file is not found. But I want to know where is the file you said config.cake that I should put the line compiler.addCppFlag('-isystem/usr/lib/llvm-6.0/lib/clang/6.0.0/include') into


[Event Request] report 5754 "Create Pick" DINOnWhseWorksheetCreatePickSetShipToFilter

Hello,
Is it possible to get the following event
             end;
                    if PerDestination then begin
                        PickWhseWkshLine.SetRange("Destination Type", PickWhseWkshLine."Destination Type");
                        PickWhseWkshLine.SetRange("Destination No.", PickWhseWkshLine."Destination No.");
                        // DINNL <<
                        DINOnWhseWorksheetCreatePickSetShipToFilter(PickWhseWkshLine);
                        // DINNL >>
                        SetPickFilters;
                        PickWhseWkshLineFilter.CopyFilter("Destination Type", PickWhseWkshLine."Destination Type");
                        PickWhseWkshLineFilter.CopyFilter("Destination No.", PickWhseWkshLine."Destination No.");
                    end else begin
                        PickWhseWkshLineFilter.CopyFilter("Destination Type", PickWhseWkshLine."Destination Type");
                        PickWhseWkshLineFilter.CopyFilter("Destination No.", PickWhseWkshLine."Destination No.");
                        SetPickFilters;

[IntegrationEvent(false, false)]
local procedure DINOnWhseWorksheetCreatePickSetShipToFilter(var PickWkshLine: Record "Whse. Worksheet Line")
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Kernel module fails to build on mainline kernel 6.6-rc5

Are you using the latest driver? Yes (DisplayLink 5.8)

Are you using the latest EVDI version? 1.14.1

If you are using a DisplayLink device, have you checked 'troubleshooting'
on DisplayLink's website? Yes

Is this issue related to evdi/kernel? Yes

Linux distribution and its version: Arch
Linux kernel version: 6.6-rc5-mainline-1
Xorg version (if used): Wayland
Desktop environment in use: Plasma

The kernel module is failing to build on the latest mainline kernel (6.6-rc5). Below is the output from executing make:
make -C /lib/modules/6.6.0-rc5-1-mainline/build M=$PWD
make[1]: Entering directory '/usr/lib/modules/6.6.0-rc5-1-mainline/build'
CC [M]  /usr/src/evdi/module/evdi_platform_drv.o
gcc: warning: include/drm: linker input file unused because linking not done
CC [M]  /usr/src/evdi/module/evdi_platform_dev.o
gcc: warning: include/drm: linker input file unused because linking not done
CC [M]  /usr/src/evdi/module/evdi_sysfs.o
gcc: warning: include/drm: linker input file unused because linking not done
CC [M]  /usr/src/evdi/module/evdi_modeset.o
gcc: warning: include/drm: linker input file unused because linking not done
CC [M]  /usr/src/evdi/module/evdi_connector.o
gcc: warning: include/drm: linker input file unused because linking not done
CC [M]  /usr/src/evdi/module/evdi_encoder.o
gcc: warning: include/drm: linker input file unused because linking not done
CC [M]  /usr/src/evdi/module/evdi_drm_drv.o
/usr/src/evdi/module/evdi_drm_drv.c:127:31: error: ‘drm_gem_prime_fd_to_handle’ undeclared here (not in a function)
127 |         .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
|                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/src/evdi/module/evdi_drm_drv.c:129:31: error: ‘drm_gem_prime_handle_to_fd’ undeclared here (not in a function)
129 |         .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
|                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:243: /usr/src/evdi/module/evdi_drm_drv.o] Error 1
make[2]: *** [/usr/lib/modules/6.6.0-rc5-1-mainline/build/Makefile:1913: /usr/src/evdi/module] Error 2
make[1]: *** [Makefile:234: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.6.0-rc5-1-mainline/build'
make: *** [Makefile:86: module] Error 2
The same output is produced if using dkms to build the module. I have uninstalled and reinstalled both the linux-mainline and linux-mainline-headers packages; however, the result is always the same.
This module was building and working fine on mainline kernel 6.3. After upgrading to mainline kernel 6.4 the module has failed to build.
I am currently using the kernel module for kernel 6.5.6 without issues.

It also fails on 6.6-rc1
CFLAGS="-isystem./include -isystem./include/uapi -Werror -Wextra -Wall -Wno-error=missing-field-initializers -Werror=sign-compare -Wmissing-prototypes -Wstrict-prototypes -Werror=discarded-qualifiers " make -C module
make[1]: Entering directory '/root/evdi/module'
make -C /lib/modules/6.6.0-rc1-edge-rockchip-rk3588/build M=$PWD
make[2]: Entering directory '/usr/src/linux-headers-6.6.0-rc1-edge-rockchip-rk3588'
  CC [M]  /root/evdi/module/evdi_platform_drv.o
  CC [M]  /root/evdi/module/evdi_platform_dev.o
  CC [M]  /root/evdi/module/evdi_sysfs.o
  CC [M]  /root/evdi/module/evdi_modeset.o
  CC [M]  /root/evdi/module/evdi_connector.o
  CC [M]  /root/evdi/module/evdi_encoder.o
  CC [M]  /root/evdi/module/evdi_drm_drv.o
/root/evdi/module/evdi_drm_drv.c:127:31: error: ‘drm_gem_prime_fd_to_handle’ undeclared here (not in a function)
  127 |         .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
/root/evdi/module/evdi_drm_drv.c:129:31: error: ‘drm_gem_prime_handle_to_fd’ undeclared here (not in a function)
  129 |         .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:243: /root/evdi/module/evdi_drm_drv.o] Error 1
make[3]: *** [/usr/src/linux-headers-6.6.0-rc1-edge-rockchip-rk3588/Makefile:1913: /root/evdi/module] Error 2
make[2]: *** [Makefile:234: __sub-make] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-6.6.0-rc1-edge-rockchip-rk3588'
make[1]: *** [Makefile:86: module] Error 2
make[1]: Leaving directory '/root/evdi/module'
make: *** [Makefile:10: all] Error 2

Can confirm:
make: *** [Makefile:10: all] Error 2
error: builder for '/nix/store/by4r6ygvs9r3mw9b9kc1nkl0i2x1jqrc-evdi-1.14.1.drv' failed with exit code 2
error: 1 dependencies of derivation '/nix/store/a1flmsznpk7mdl3hvjmihmnpf6xfzpim-displaylink-5.8.0-63.33.drv' failed to build
error: 1 dependencies of derivation '/nix/store/j03j48cbijs1vag278l159kjs5z9qxq4-kernel-modules.drv' failed to build
error (ignored): error: cannot unlink '/tmp/nix-build-nvidia-x11-545.23.06-6.6.0-xanmod1.drv-7/NVIDIA-Linux-x86_64-545.23.06/kernel': Directory not empty
error: 1 dependencies of derivation '/nix/store/f6x7z4agf7cj8ibdgq12myknjb5gj4x6-linux-6.6.0-xanmod1-modules.drv' failed to build
error: 1 dependencies of derivation '/nix/store/vf82qlsznacl3vjyaqci2aaw45nk2k7a-nixos-system-mother-23.11pre542330.0cbe9f69c234.drv' failed to build

Kernel 6.6 was release and will arrive in Fedora in about 2 weeks and probably earlier in Arch. Any update on this?

Kernel 6.6 has indeed been released on arch, it fails to build the package on 6.6.1.arch1-1 with:
/var/lib/dkms/evdi/1.14.03/build/evdi_fb.c: In function ‘evdifb_create’:
/var/lib/dkms/evdi/1.14.03/build/evdi_fb.c:421:23: error: ‘FBINFO_DEFAULT’ undeclared (first use in this function)
  421 |         info->flags = FBINFO_DEFAULT;
      |                       ^~~~~~~~~~~~~~
/var/lib/dkms/evdi/1.14.03/build/evdi_fb.c:421:23: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [scripts/Makefile.build:243: /var/lib/dkms/evdi/1.14.03/build/evdi_fb.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/var/lib/dkms/evdi/1.14.03/build/evdi_drm_drv.c:127:31: error: ‘drm_gem_prime_fd_to_handle’ undeclared here (not in a function)
  127 |         .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/evdi/1.14.03/build/evdi_drm_drv.c:129:31: error: ‘drm_gem_prime_handle_to_fd’ undeclared here (not in a function)
  129 |         .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:243: /var/lib/dkms/evdi/1.14.03/build/evdi_drm_drv.o] Error 1
make[2]: *** [/usr/lib/modules/6.6.1-arch1-1/build/Makefile:1913: /var/lib/dkms/evdi/1.14.03/build] Error 2
make[1]: *** [Makefile:234: __sub-make] Error 2

I'm just here waiting for the response from the DisplayLink maintainers saying that Arch/Nix/Fedora is not a supported distribution.

@cedricroijakkers i do not believe that beeing passive agressive will convince the team to chamged the supported distribution(s). And within the last two years using it they were fast in adapt to new kernels long before they're used in Ubuntu, some versions never were.

No diea what I broke with this but my journal does not get flushed and all 3 screens are working fine again.
diff --git a/module/evdi_drm_drv.c b/module/evdi_drm_drv.c
index 09a9da0..00b7402 100644
--- a/module/evdi_drm_drv.c
+++ b/module/evdi_drm_drv.c
@@ -124,9 +124,7 @@ static struct drm_driver driver = {

        .fops = &evdi_driver_fops,

-       .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
        .gem_prime_import = drm_gem_prime_import,
-       .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
 #if KERNEL_VERSION(5, 11, 0) <= LINUX_VERSION_CODE || defined(EL8)
 #else
        .preclose = evdi_driver_preclose,
diff --git a/module/evdi_fb.c b/module/evdi_fb.c
index 3789b33..4a4fb6a 100644
--- a/module/evdi_fb.c
+++ b/module/evdi_fb.c
@@ -418,7 +418,6 @@ static int evdifb_create(struct drm_fb_helper *helper,
        info->fix.smem_start = (unsigned long)efbdev->efb.obj->vmapping;

 #if KERNEL_VERSION(4, 20, 0) <= LINUX_VERSION_CODE || defined(EL8)
-       info->flags = FBINFO_DEFAULT;
 #else
        info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
 #endif

             .',;::::;,'.
         .';:cccccccccccc:;,.
      .;cccccccccccccccccccccc;.         crashdummy@crashphyrus
    .:cccccccccccccccccccccccccc:.       ----------------------
  .;ccccccccccccc;.:dddl:.;ccccccc;.     OS: Fedora release 39 (Thirty Nine) x86_64
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.    Host: ROG Zephyrus G15 GA503RW_GA503RW 1.0
.:ccccccccccccc;KMMc;cc;xMMc:ccccccc:.   Kernel: 6.6.1-0.rc1.350.vanilla.fc39.x86_64
,cccccccccccccc;MMM.;cc;;WW::cccccccc,   Uptime: 7 mins
:cccccccccccccc;MMM.;cccccccccccccccc:   Packages: 3580 (rpm), 68 (flatpak)
:ccccccc;oxOOOo;MMM0OOk.;cccccccccccc:   Shell: bash 5.2.15
cccccc:0MMKxdd:;MMMkddc.;cccccccccccc;   Resolution: 2560x1440
ccccc:XM0';cccc;MMM.;cccccccccccccccc'   DE: GNOME 45.1
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;    WM: Mutter
ccccc;0MNc.ccc.xMMd:ccccccccccccccc;     WM Theme: Sweet-Dark
cccccc;dNMWXXXWM0::cccccccccccccc:,      Theme: Sweet-Dark-v40 [GTK2/3]
cccccccc;.:odl:.;cccccccccccccc:,.       Icons: candy-icons [GTK2/3]
:cccccccccccccccccccccccccccc:'.         Terminal: terminator
.:cccccccccccccccccccccc:;,..            CPU: AMD Ryzen 9 6900HS with Radeon Graphics (16) @ 4.925GHz
  '::cccccccccccccc::;,.                 GPU: NVIDIA Geforce RTX 3070 Ti Laptop GPU
                                         GPU: AMD ATI Radeon 680M
                                         Memory: 5270MiB / 31323MiB

Tried applying this patch. The module builds with the patch, but no displays are detected.

Same here. No display. Going back to 6.59 works.

This PR https://github.com/DisplayLink/evdi/pull/436 has fixed the issue for me. It's now working on Arch Linux using DisplayLink 5.8, the devel branch of this repo, and kernel 6.6.1.

ok, now maintainers please merge. thanks.

[snip]
Sorry I'm late to respond.
The metnioned PR is basically exactly the same implementation.
It just added some compiler flags to allow backwards compatibility.
I tested it on about 20 devices running either EOS, Fedora or Ubuntu.
I had some issues with upgrading from 1.12.0 in the past maybe that one happened here again.
You can try applying the patch of the PR as well.
If you're on Fedora 37/38/39 I can provide you a rpm package if you want to

At this point I'm kind of puzzled what DocMAX and I did wrong yesterday. The latest devel branch does also build but actually functions correctly.

@Kevinjil I did have some funkyness too, a restart of the displaylink service or a reboot did the trick however.

Once loaded, evdi will stay in the kernel until a reboot. Just a hunch, but if you've had an earlier version of evdi loaded, the displaylink driver will detect the discrepancy and refuse serving the displays.

i deleted the dkms evdi folder and recompiled the module with no errors. but doesn't work with 6.6. worked on 6.5 though.

hmm, no, that wasn't the solution. no idea why the displays are detected randomly

I also get the following error on 6.6.1-arch1-1 when doing dkms install --no-depmod evdi/1.14.1 -k 6.6.1-arch1-1 --verbose. Did anybody resolve this issue?
make[3]: *** [scripts/Makefile.build:243: /var/lib/dkms/evdi/1.14.1/build/evdi_fb.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/var/lib/dkms/evdi/1.14.1/build/evdi_drm_drv.c:127:31: error: ‘drm_gem_prime_fd_to_handle’ undeclared here (not in a function)
  127 |         .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/evdi/1.14.1/build/evdi_drm_drv.c:129:31: error: ‘drm_gem_prime_handle_to_fd’ undeclared here (not in a function)
  129 |         .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:243: /var/lib/dkms/evdi/1.14.1/build/evdi_drm_drv.o] Error 1
make[2]: *** [/usr/lib/modules/6.6.1-arch1-1/build/Makefile:1913: /var/lib/dkms/evdi/1.14.1/build] Error 2
make[1]: *** [Makefile:234: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.6.1-arch1-1/build'
make: *** [Makefile:38: all] Error 2

dkms error:
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
make clean KERNELRELEASE=6.6.1-arch1-1 DKMS_BUILD=1
/lib/modules/6.6.1-arch1-1/build
make KBUILD_VERBOSE=1 M=/var/lib/dkms/evdi/1.14.1/build SUBDIRS=/var/lib/dkms/evdi/1.14.1/build SRCROOT=/var/lib/dkms/evdi/1.14.1/build -C /lib/modules/6.6.1-arch1-1/build clean
make[1]: Entering directory '/usr/lib/modules/6.6.1-arch1-1/build'
make --no-print-directory -C /usr/lib/modules/6.6.1-arch1-1/build \
-f /usr/lib/modules/6.6.1-arch1-1/build/Makefile clean
make -f ./scripts/Makefile.clean obj=/var/lib/dkms/evdi/1.14.1/build
# cmd_rmfiles clean
  rm -rf /var/lib/dkms/evdi/1.14.1/build/Module.symvers /var/lib/dkms/evdi/1.14.1/build/modules.nsdeps /var/lib/dkms/evdi/1.14.1/build/compile_commands.json /var/lib/dkms/evdi/1.14.1/build/.thinlto-cache
make[1]: Leaving directory '/usr/lib/modules/6.6.1-arch1-1/build'

{ make -j8 KERNELRELEASE=6.6.1-arch1-1 all INCLUDEDIR=/lib/modules/6.6.1-arch1-1/build/include KVERSION=6.6.1-arch1-1 DKMS_BUILD=1; } >> /var/lib/dkms/evdi/1.14.1/build/make.log 2>&1
(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.6.1-arch1-1 (x86_64)
Consult /var/lib/dkms/evdi/1.14.1/build/make.log for more information.

Any update to this issue?

The module builds for me and loads on kernel 6.6-rc5 and now 6.7-rc3.

@mrscottie or one of the maintainers @displaylink-emajewsk @displaylink-dkurek @displaylink-mlukaszek: This issue can be closed, it has been resolved. Building from the git repo works now, possibly you need to create a new release to finalise it.

[dmenezes@alienware-f15 ~]$ neofetch .',;::::;,'. dmenezes@alienware-f15 .';:cccccccccccc:;,. ---------------------- .;cccccccccccccccccccccc;. OS: Fedora Linux 39 (Workstation Edition) x86_64 .:cccccccccccccccccccccccccc:. Host: Alienware m15 R6 .;ccccccccccccc;.:dddl:.;ccccccc;. Kernel: 6.6.2-201.fc39.x86_64 .:ccccccccccccc;OWMKOOXMWd;ccccccc:. Uptime: 33 mins .:ccccccccccccc;KMMc;cc;xMMc:ccccccc:. Packages: 2994 (rpm), 90 (flatpak) ,cccccccccccccc;MMM.;cc;;WW::cccccccc, Shell: bash 5.2.21 :cccccccccccccc;MMM.;cccccccccccccccc: Resolution: 1920x1080, 1920x1080, 1920x1080, 1080x1920 :ccccccc;oxOOOo;MMM0OOk.;cccccccccccc: DE: GNOME 45.1 cccccc:0MMKxdd:;MMMkddc.;cccccccccccc; WM: Mutter ccccc:XM0';cccc;MMM.;cccccccccccccccc' WM Theme: Adwaita ccccc;MMo;ccccc;MMW.;ccccccccccccccc; Theme: Adwaita-dark [GTK2/3] ccccc;0MNc.ccc.xMMd:ccccccccccccccc; Icons: Adwaita [GTK2/3] cccccc;dNMWXXXWM0::cccccccccccccc:, Terminal: gnome-terminal cccccccc;.:odl:.;cccccccccccccc:,. CPU: 11th Gen Intel i7-11800H (16) @ 4.600GHz :cccccccccccccccccccccccccccc:'. GPU: Intel TigerLake-H GT1 [UHD Graphics] .:cccccccccccccccccccccc:;,.. GPU: NVIDIA GeForce RTX 3070 Mobile / Max-Q '::cccccccccccccc::;,. Memory: 7180MiB / 64031MiB
[dmenezes@alienware-f15 ~]$ [dmenezes@alienware-f15 ~]$ sudo fpaste /var/lib/dkms/evdi/1.14.1/build/make.log Uploading (41.1KiB)... https://paste.centos.org/view/6ad05920

Looks like you dont use the applied patch. Can you try one of mine ? https://github.com/SimonSchwendele/displaylink-rpm/releases/tag/v1.14.1-3

Just wanted to chime in - I'm on Fedora 38 with kernel 6.6.2-101.fc38.x86_64 - the current released version upstream for the displaylink-rpm stopped working for me but this RPM from the fork fixed the issue

Hi @Crashdummyy,
I am on fedora 39 (Linux 6.6.2-201.fc39.x86_64) and having the same issue as everybody here, and when I tried running your patched rpm, it displayed an error saying it was conflicting with the previous packages. I understand I need to remove the previous packages, but I am not exactly versed in how I can achieve that... any chance you could help me out and tell me how I can remove/clean the previous installation so I can install your version?
Thank you very much!

[dmenezes@alienware-f15 ~]$ neofetch .',;::::;,'. dmenezes@alienware-f15 .';:cccccccccccc:;,. ---------------------- .;cccccccccccccccccccccc;. OS: Fedora Linux 39 (Workstation Edition) x86_64 .:cccccccccccccccccccccccccc:. Host: Alienware m15 R6 .;ccccccccccccc;.:dddl:.;ccccccc;. Kernel: 6.6.2-201.fc39.x86_64 .:ccccccccccccc;OWMKOOXMWd;ccccccc:. Uptime: 33 mins .:ccccccccccccc;KMMc;cc;xMMc:ccccccc:. Packages: 2994 (rpm), 90 (flatpak) ,cccccccccccccc;MMM.;cc;;WW::cccccccc, Shell: bash 5.2.21 :cccccccccccccc;MMM.;cccccccccccccccc: Resolution: 1920x1080, 1920x1080, 1920x1080, 1080x1920 :ccccccc;oxOOOo;MMM0OOk.;cccccccccccc: DE: GNOME 45.1 cccccc:0MMKxdd:;MMMkddc.;cccccccccccc; WM: Mutter ccccc:XM0';cccc;MMM.;cccccccccccccccc' WM Theme: Adwaita ccccc;MMo;ccccc;MMW.;ccccccccccccccc; Theme: Adwaita-dark [GTK2/3] ccccc;0MNc.ccc.xMMd:ccccccccccccccc; Icons: Adwaita [GTK2/3] cccccc;dNMWXXXWM0::cccccccccccccc:, Terminal: gnome-terminal cccccccc;.:odl:.;cccccccccccccc:,. CPU: 11th Gen Intel i7-11800H (16) @ 4.600GHz :cccccccccccccccccccccccccccc:'. GPU: Intel TigerLake-H GT1 [UHD Graphics] .:cccccccccccccccccccccc:;,.. GPU: NVIDIA GeForce RTX 3070 Mobile / Max-Q '::cccccccccccccc::;,. Memory: 7180MiB / 64031MiB
[dmenezes@alienware-f15 ~]$ [dmenezes@alienware-f15 ~]$ sudo fpaste /var/lib/dkms/evdi/1.14.1/build/make.log Uploading (41.1KiB)... https://paste.centos.org/view/6ad05920

Looks like you dont use the applied patch. Can you try one of mine ? https://github.com/SimonSchwendele/displaylink-rpm/releases/tag/v1.14.1-3

Finally I got it back on Fedora 39! Thank you @Crashdummyy.
A step-by-step list of what I did, in case it is useful for somebody:
sudo dnf install fedora-packager rpmdevtools
sudo dnf install libdrm-devel glibc-devel.i686

git clone https://github.com/SimonSchwendele/displaylink-rpm

cd displaylink-rpm

make

sudo dnf autoremove displaylink
sudo dkms remove evdi/<version> -a
sudo rm -rf /var/lib/dkms/evdi

sudo dnf install x86_64/displaylink-1.14.1-*.rpm

After the last command my external displays immediately came back to life.

Closing since this has been fixed.

I'd argue that this is only "fixed" once a release has been cut?
I've just come back to using DisplayLink on a pop!_OS (Ubuntu variant) laptop running the ominously versioned 6.6.6-76060606-generic and the current apt packages do not contain the above fix.
I can build from source for now, but that still strikes me as half a solution rather than "just upgrade via the usual channels and everything will be working again"?

I'd argue that this is only "fixed" once a release has been cut?
I've just come back to using DisplayLink on a pop!_OS (Ubuntu variant) laptop running the ominously versioned 6.6.6-76060606-generic and the current apt packages do not contain the above fix.
I can build from source for now, but that still strikes me as half a solution rather than "just upgrade via the usual channels and everything will be working again"?

I, too, am on Pop with same kernel. Can you tell me what you did to build and install from source?

Clone the evdi repo to someplace
Copy everything in the module directory to /usr/src/evdi-1.14.1

This worked for me on Debian Sid with kernel 6.6.13
Thanks!

https://github.com/SimonSchwendele/displaylink-rpm

And better yet, Simon's page also has artifact RPM-s that are automatically posted in releases:
https://github.com/displaylink-rpm/displaylink-rpm/releases

https://github.com/SimonSchwendele/displaylink-rpm

And better yet, Simon's page also has artifact RPM-s that are automatically posted in releases: https://github.com/displaylink-rpm/displaylink-rpm/releases

The above one is a fork. The main reason for this fork is that it automatically pushes them into my copr. https://copr.fedorainfracloud.org/coprs/crashdummy/Displaylink/

I see, even better then!

https://github.com/SimonSchwendele/displaylink-rpm

And better yet, Simon's page also has artifact RPM-s that are automatically posted in releases: https://github.com/displaylink-rpm/displaylink-rpm/releases

The above one is a fork. The main reason for this fork is that it automatically pushes them into my copr. https://copr.fedorainfracloud.org/coprs/crashdummy/Displaylink/

hey @Crashdummyy, first things first, thank you very much for sharing this, I have been using your fork for a while now and it has worked like magic.
However, I just got a new computer and it has secure boot enabled. I followed the procedure described in your copr, and my problem is the final step... this is the first time I actually use secure boot so after registering the MOK, I dont know how to sign the module. Any chance you could teach me that? Cheers!

I dont use secureboot at all so its been ages since I last signed a module.
Well nevermind the instructions should create and import the cert.
You should now be able to sign your module.
$ sudo unxz $(modinfo -n evdi)

$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv  ./MOK.der /lib/modules/$(uname -r)/extra/evdi.ko

$ sudo xz -f /lib/modules/$(uname -r)/extra/evdi.ko

Your evdi.ko.xz should then be signed in case no error occurred

thank you so much! I didnt realized that these steps were right in front of me in the instructions, or I just didn't realized that was the procedure for signing. It worked like a charm.
Well, I kind of convinced the IT guys at work to let me continue using fedora instead of windows so they installed it with secure boot... I might end up negotiating a bit further.
Anyways, thank you very much, you are a legend.


OciExtension (helidon-integrations-oci-sdk-cdi) not detecting injection points like Provider and Instance

Environment Details

Helidon Version: 3.2.2
Helidon MP
JDK version: 17

Problem Description
OciExtension is skipping injection points like Provider<ObjectStorage> and Instance<ObjectStorage>
Steps to reproduce

add below dependencies to a helidon MP project

         <dependency>
            <groupId>io.helidon.integrations.oci.sdk</groupId>
            <artifactId>helidon-integrations-oci-sdk-cdi</artifactId>
        </dependency>
        <dependency>
            <groupId>com.oracle.oci.sdk</groupId>
            <artifactId>oci-java-sdk-objectstorage</artifactId>
        </dependency>

Then run below HelidonTest
    @Inject
    Instance<ObjectStorage> storage;

    @Test
    void testObjectCreation() {

        var resp = storage.get()
                .getBucket(GetBucketRequest.builder()
                        .bucketName("my_bucket")
                        .namespaceName("my_namespace")
                        .build());
        System.out.println(resp.getBucket().toString());
    }

Test will fail with exception org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type ObjectStorage with qualifiers @Default
If I replace the injection without the jakarta.enterprise.inject.Instance test case will execute with no exception.
Behaviour is same for jakarta.inject.Provider

A workaround should be to add an injection point anywhere else that does not use Provider or Instance. For example, a "dummy" observer method (that is deliberately never called) in an enabled bean somewhere:
private static void neverInvoked(@Observes ObjectStorage ignored) {}

The extension should scan for all injection points (including the "dummy" one I've exemplified above) and that scan will identify the need to "make" an ObjectStorage, and your Provider<ObjectStorage> injection points should also then work.
The proper fix which I'll get to next week is to augment the extension to scan for Provider points as well (that will also cover Instance points).


Internationalisation question

Is your feature request related to a problem? Please describe.
Hey! I have seen that there is a fallback language. Does it mean that this repo is for a bilingual blog or multilingual?

Hello! It is programmed as a template with a base of two languages, but it can easily be extended to other languages (3, 4, 5 or even more) by modifying a few files. (I made sure that it wasn't that complicated to set up)
I plan to explain this in a future article which will be on the demo :)
That said, I think that two languages will cover most cases of uses: English as a conventional language and technical language, and the natural language of the blogger. More could be a bit overkill for a blog lol, but if you need three, it's totally possible!
The fallback language is actually designed as the language without a locale in the url, like this : "yoursite/" instead of "yoursite/en" and is set up to english. But it can be set up to any language

Well, if you have any new ideas, or see any bugs, or things that should be improved, that's totally welcome!


Track recording should record separate tracks each time (and not use all points for one polyline)

We have an objectstore with track id's and dates and an objectstore with position records.
It thus becomes easy to iterate over separate tracks (of a certain day) and then to get route points for each track.
Plotting not yet reimplemented.

Works. Keeps same day's tracks visible.


the first link under "related topics"

the first link under "related topics" has a broken link. I proposed what might be the right one but not sure. Can you please update? For some reason this issue is blocking my ability to redirect my docs in the redirection file for windows-docs-pr.  Thanks!
Lauren

@LaurenMoynihan
The default branch for this repository has changed from master to public. Please edit your pull request to change the merge target to public via the Edit button at the top right corner. Thanks.

ok done. thx!
Lauren

From: Trond B. Krokli<EMAIL_ADDRESS>Sent: Tuesday, September 17, 2019 10:29 AM
To: MicrosoftDocs/windows-itpro-docs<EMAIL_ADDRESS>Cc: Lauren Moynihan<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/windows-itpro-docs] the first link under "related topics" (#4953)
@LaurenMoynihanhttps://github.com/LaurenMoynihan
The default branch for this repository has changed from master to public. Please edit your pull request to change the merge target to public via the Edit button at the top right corner. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windows-itpro-docs/pull/4953?email_source=notifications&email_token=AHAFWDTRDQQTWQG7INORMR3QKEHZFA5CNFSM4IXS4C5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD65JFNQ#issuecomment-532320950, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHAFWDRMLQRSINMY72R4TX3QKEHZFANCNFSM4IXS4C5A.

Very well, fair enough. It appears that in making the change, your patch-2 branch has got a backlog compared to the "head" of the public branch, adding 2 more files to your original 1 file change. I will make a local copy of your fork & branch, update it and push a PR to your repository to update it and (hopefully) remove that discrepancy.

There you go. Hope you will be able to choose between following up on my PR or use your own software (git) tools to update your branch LaurenMoynihan:patch-2 .

hey Trond,
What is it that I need to do? Sorry, this is getting a little advanced for me.
thanks,
Lauren

From: Trond B. Krokli<EMAIL_ADDRESS>Sent: Tuesday, September 17, 2019 6:33 PM
To: MicrosoftDocs/windows-itpro-docs<EMAIL_ADDRESS>Cc: Lauren Moynihan<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/windows-itpro-docs] the first link under "related topics" (#4953)
There you go. Hope you will be able to choose between following up on my PR or use your own software (git) tools to update your branch LaurenMoynihan:patch-2https://github.com/LaurenMoynihan/windows-itpro-docs/tree/patch-2 .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windows-itpro-docs/pull/4953?email_source=notifications&email_token=AHAFWDQ66VXAWEDRWVX6D53QKGAPVA5CNFSM4IXS4C5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66QBDA#issuecomment-532480140, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHAFWDRFEKUQSYT6Q4MUU3DQKGAPVANCNFSM4IXS4C5A.

OK, right. I thought that it might be more advanced than you expected. I have been debating this situation in my own head for a little while, trying to find out which route will be easier and more practical for your use. One of the challenges I faced is the fact that you have got some older work stored in a couple of unrelated branches in your current repository.
If keeping the old branches is not much of a concern to you, you could choose to delete your existing repository and fork the https://github.com/MicrosoftDocs/windows-itpro-docs repository to your own repository (making it a new https://github.com/LaurenMoynihan/windows-itpro-docs repository with the public branch the new default. This route will not keep the old branches, unfortunately, so it is only recommended if you don't specifically need the old branches anymore.
On the other hand, I can suggest a different route, if you want to keep the current branches as well as updating the current PR branch to make it work as intended. This depends very much on you trusting me to help you rebase/merge new content into your existing repository, by adding me as a collaborator in your windows-itpro-docs repository. I don't know if this feels intrusive to you or if you are OK with this. If there are someone you know well, maybe a colleague at work, who can help you do the same changes, make that user a collaborator in your windows-itpro-docs repository to enable that user to update your master branch, PR branch ( LaurenMoynihan:patch-2 ) as well as adding the MicrosoftDocs:public branch to your current repository.
I know. This can definitely look overwhelming to anyone who are not yet familiar with how branches, repositories and git commands work. I still hope you will be able to share your thoughts on what you would prefer to keep or let go as you move forward with your decisions.

Simple suggestion: if you just want to get this PR updated without any other changes,
you can merge my PR into your repository by going to this page:
https://github.com/LaurenMoynihan/windows-itpro-docs/pull/1
then scroll down to the bottom of the page and press the green [Merge] button,
to have your PR updated without the 2 unrelated files.

Sorry for creating trouble in the first place. As a Microsoft employee, you should probably use the master branch as your target, in contrast to users not employed by Microsoft (like me).
See if your PR goes back to normal (only 1 file included) if you switch back to the master branch.

@mjcaparas Following up for updates regarding review.


Make web-page responsive

Make the web-page responsive for tablets and mobiles

I'd like to give it a try


nodejs-mobile

This project links to a couple other projects at the top of the readme, but there's no mention of nodejs-mobile which at first glance appears to do the same thing but also for ios?

The readme mentions nodejs-mobile may not be open source:

We are depending on this project by Janea Systems to open source their methods and include a proper open source license.

However, now it seems as if Janea Systems has MIT Licensed their React Native implementation.
The core project, nodejs-mobile, is forked from node-chakracore, meaning it inherits node's license.
Perhaps this would be a good opportunity to use their iOS implement in this project?

Just realized this issue may be a duplicate. Issue is addressed here: https://github.com/staltz/react-native-node/issues/8#issuecomment-334679704


Model Testing: AttributeError: 'AgentDQN' object has no attribute 'action'

Hello,
Thank you for releasing the code! I finished training the model and was testing it. The terminal gave me the error as follows:
Traceback (most recent call last):
File "run.py", line 536, in
run_episodes(num_episodes, status)
File "run.py", line 470, in run_episodes
episode_over, reward = dialog_manager.next_turn(record_training_data_for_user=False)
File "../DDQ/src/deep_dialog/dialog_system/dialog_manager.py", line 67, in next_turn
self.agent_action = self.agent.state_to_action(self.state)
File "../DDQ/src/deep_dialog/agents/agent_dqn.py", line 89, in state_to_action
act_slot_response = copy.deepcopy(self.feasible_actions[self.action][0])
AttributeError: 'AgentDQN' object has no attribute 'action'
I looked at the code and could not find the variable action anywhere else in agent_dqn.py. Could you take a look at it? I appreciate your help.

Thanks much.
we just update the repo, fixed a bug in agent_dyn.py, you can check the latest version, and re-run the test. I tested it, it works.
The command line to run test with trained model (supposed agt_9_48_90_0.62000.pkl is a trained model):
python run.py --agt 9 --usr 1 --max_turn 40 --movie_kb_path ./deep_dialog/data/movie_kb.1k.p --dqn_hidden_size 80 --experience_replay_pool_size 5000 --episodes 500 --simulation_epoch_size 1 --run_mode 3 --act_level 0 --slot_err_prob 0.00 --intent_err_prob 0.00 --batch_size 16 --goal_file_path ./deep_dialog/data/user_goals_first_turn_template.part.movie.v1.p --warm_start 1 --warm_start_epochs 100 --write_model_dir ./deep_dialog/checkpoints/tmp/ --planning_steps 4 --grounded 0 --boosted 1 --train_world_model 1 --torch_seed 300 --trained_model_path ./deep_dialog/checkpoints/tmp/agt_9_48_90_0.62000.pkl

It works now. Thank you!


Can't install dolfinx_mpc

dolfinx_mpc is an extension in dolfinx used for multipoint-constraint in fenicsx. but I don't seem to be able to install it in colab.
I would appreciate your help

See https://github.com/jorgensd/dolfinx_mpc/issues/106


Can't get it work

Nothing appear in my mqtt broker, logfile is
2020-09-03 23:14:08,691 INFO [<IP_ADDRESS>]: <-- <IP_ADDRESS> :
2020-09-03 23:14:08,691 INFO [<IP_ADDRESS>]: Invalid length of a data packet

if i remove data length check - i get this:
2020-09-03 23:11:40,328 INFO [<IP_ADDRESS>]: Can't incoming data b'': ['Traceback (most recent call last):', '  File "/home/ilya/neptun2mqtt/neptun.py", line 461, in check_incoming\n    self.handle_incoming_data(self.socket, addr, data)', '  File "/home/ilya/neptun2mqtt/neptun.py", line 486, in handle_incoming_data\n    if not crc16_check(data):', '  File "/home/ilya/neptun2mqtt/neptun.py", line 77, in crc16_check\n    return (data[i - 1] == crc_lo) and (data[i - 2] == crc_hi)', 'IndexError: index out of range']
2020-09-03 23:11:40,328 INFO [<IP_ADDRESS>]: Error in connector's thread: ['Traceback (most recent call last):', '  File "/home/ilya/neptun2mqtt/neptun.py", line 344, in run\n    self.check_incoming()', '  File "/home/ilya/neptun2mqtt/neptun.py", line 461, in check_incoming\n    self.handle_incoming_data(self.socket, addr, data)', '  File "/home/ilya/neptun2mqtt/neptun.py", line 486, in handle_incoming_data\n    if not crc16_check(data):', '  File "/home/ilya/neptun2mqtt/neptun.py", line 77, in crc16_check\n    return (data[i - 1] == crc_lo) and (data[i - 2] == crc_hi)', 'IndexError: index out of range']

There is a piece from start:
2020-09-03 23:13:02,256 INFO [<IP_ADDRESS>]: Thread started
2020-09-03 23:13:02,256 INFO [<IP_ADDRESS>]: ++Q (<IP_ADDRESS>:6350) : bytearray(b'\x02TQR\x00\x00*E')
2020-09-03 23:13:02,257 INFO Starting main thread
2020-09-03 23:13:02,256 INFO [<IP_ADDRESS>]: Allocating socket
2020-09-03 23:13:02,257 INFO Connected with result code: 5
2020-09-03 23:13:02,257 INFO [<IP_ADDRESS>]: Connecting to: ('<IP_ADDRESS>', 6350)
2020-09-03 23:13:02,258 INFO [<IP_ADDRESS>]: Connected successfully to: ('<IP_ADDRESS>', 6350)
2020-09-03 23:13:02,259 INFO [<IP_ADDRESS>]: --> (<IP_ADDRESS>:6350): 02 54 51 52 00 00 2A 45
2020-09-03 23:13:02,727 INFO [<IP_ADDRESS>]: <-- <IP_ADDRESS> : 02 54 41 52 00 5C 49 00 05 4E 33 32 32 30 4D 00 11 36 30 3A 43 35 3A 41 38 3A 37 37 3A 38 46 3A
31 44 41 00 01 00 53 00 07 01 00 00 00 00 03 00 73 00 00 4C 00 04 00 00 00 00 43 00 14 00 00 00
00 01 00 00 00 00 01 00 00 00 00 01 00 00 00 00 01 44 00 0A 31 35 39 39 31 37 34 37 37 31 57 00
01 04 B3 9B
2020-09-03 23:13:02,727 INFO [<IP_ADDRESS>]: ++Q (<IP_ADDRESS>:6350) : bytearray(b'\x02TQc\x00\x00\xd8\xd0')
2020-09-03 23:13:02,728 INFO Subscribing to: home/Neptun/command/+
2020-09-03 23:13:02,728 INFO Subscribing to: home/Neptun/command
2020-09-03 23:13:03,228 INFO [<IP_ADDRESS>]: --> (<IP_ADDRESS>:6350): 02 54 51 63 00 00 D8 D0
2020-09-03 23:13:03,259 INFO Connected with result code: 5
2020-09-03 23:13:03,340 INFO [<IP_ADDRESS>]: <-- <IP_ADDRESS> : 02 54 41 FB 00 00 12 EF
2020-09-03 23:13:05,262 INFO Connected with result code: 5
2020-09-03 23:13:09,264 INFO Connected with result code: 5
2020-09-03 23:13:17,266 INFO Connected with result code: 5
2020-09-03 23:13:33,268 INFO Connected with result code: 5
2020-09-03 23:13:43,140 INFO [<IP_ADDRESS>]: <-- <IP_ADDRESS> :
2020-09-03 23:13:43,140 INFO [<IP_ADDRESS>]: Invalid length of a data packet

Hello.
The same problem. The logs are almost the same.
@ilyadavydyuk what is your firmware version? Mine is 2.2.0.
@ptvoinfo what firmware did you use?

Hi! A'm using ver 2.2.0 and have the same problems. Is there any solution?

Have the same problem with 2.2.0


malformed documents should throw an exception or return an error instead of aborting

What steps will reproduce the problem?
1. Make a document and set it via SetNull()
2. try to write the document with a Writer
3.

What is the expected output? What do you see instead?
I would expect some recovery mechanism; If we encounter such a malformed case,
we need to gracefully handle the problem (i.e. we cannot crash)

What version of the product are you using? On what operating system?
0.1.  Linux.

Please provide any additional information below.
Some of these asserts are down deep in the code.  The current design is not
geared toward return codes.  My suggestion would be to throw an exception when
malformed documents are encountered.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 22 Feb 2012 at 10:18

Merged into: #79

I noted that while snooping around in rapidjson.h that it is possible to
predefine RAPIDJSON_ASSERT, which does allow for recovery via exception
handling.  Still it would be nice to have extra information about the failure,
but this is good for now.

Original comment by<EMAIL_ADDRESS>on 22 Feb 2012 at 10:35

Yes, that's great for parsing, but I encountered this assert during file
writing after manually building a document that has null as the root value.
What might be nice is to augment RAPIDJSON_ASSERT with an informational string,
something like:

#define RAPIDJSON_ASSERT(A, B)

where A is the boolean to be checked, and B could be a const char * that gives
information about what it means when A fails.

Then, when someone predefines RAPIDJSON_ASSERT for their own app, they could
throw an exception where the what() could return that const char *.  This is
only a suggestion; I'm not sure what is the best way to handle more general
information about assert failures.

Original comment by<EMAIL_ADDRESS>on 28 Feb 2012 at 2:32

Original comment by<EMAIL_ADDRESS>on 14 Nov 2012 at 3:40

Added labels: Type-Enhancement
Removed labels: Type-Defect

Yes, I'm using rapidjson to validate and convert the ungodly mess that is
twitter, into protobuf. Since twitter is not well  documented, and they alter
the schema from day to day I need to reverse engineer it.

I want an exception thrown when a field is absent or when a field does not have
the correct type. I could use the IsType and HasMember functions but that is
just too much code.

As brian.budge mentioned above. Explicit documentation that is flagged up
should be provided. Perhaps in the feature list on the front page, since there
is no documentation at the moment, or perhaps as an example.

Original comment by<EMAIL_ADDRESS>on 4 Apr 2012 at 1:12

By default, if error is occurred during parsing, the error status, the error
message and the byte offset of the JSON stream can be obtained via

bool GenericReader::HasParseError()
const char* GenericReader::GetParseError()
size_t GenericReader::GetErrorOffset()

and

bool GenericDocument::HasParseError() const { return parseError_ != 0; }
const char* GenericDocument::GetParseError() const { return parseError_; }
size_t GenericDocument::GetErrorOffset() const { return errorOffset_; }

Please check if they may help. Suggestion are welcome.

Original comment by<EMAIL_ADDRESS>on 28 Feb 2012 at 6:12

This is how I am using it at the moment.

namespace social_sensor
{
  class rapidjson_exception : public std::runtime_error
  {
  public:
    rapidjson_exception() : std::runtime_error("json schema invalid") {}
  };
}

#define RAPIDJSON_ASSERT(x)                         \
  if(x);                                            \
  else throw social_sensor::rapidjson_exception();

#include <rapidjson/document.h>
#include <rapidjson/prettywriter.h>
#include <rapidjson/filewritestream.h>

Original comment by<EMAIL_ADDRESS>on 4 Apr 2012 at 1:34

I converted my JSON parsing code from boost property tree to rapidjson,
improving speed and correctness (ptree does not even preserve data types,
terribly wrong path to go down, sadly).  I had already included exception
handling of all malformed JSON during extraction while using ptree.  Using
Hassan's approach in comment #5 worked without any need for additional code
changes.    :-)

Better docs, and rapidjson will easily take over the world!  :-)

Original comment by<EMAIL_ADDRESS>on 22 Nov 2013 at 1:06

Original comment by<EMAIL_ADDRESS>on 24 Jun 2014 at 2:05

Changed state: Duplicate


Load simplycode through npm

This MR adds logic to load SimplyCode from GitHub, using NPM, rather than having a copy.
This is done by adding a post npm install hook that move the content of the SimplyCode www directory to a simplycode directory in the root of the project (where the copy currently lives).
To test this before https://github.com/SimplyEdit/simplycode/pull/33 is merged, change the dependencies entry for simplycode to read:
    "simplycode": "github:simplyedit/simplycode#deploy/npm"

Then run nmp install. This will update the contents of the simplycode/ directory.
At a later time, the SimplyCode code directory could be removed and added to the .gitignore file if desired.
This would keep the copy of the code completely out of this repo.

Converted to draft until point from face-to-face discussion with @ylebre are resolved.
Also, I need to add documentation.


Add mapFallbackValue attribute to @Options and @Parameters annotation

(Related to #1214)
For Map options and positional parameters, the work done for #1214 will make it possible to specify key-only parameters on the command line, like for example -Dkey (instead of -Dkey=value).
Applications can use the mapFallbackValue annotation attribute to control the value that will be put into the map for the key when no value is specified on the command line.
This should work for both options and positional parameters, and added to both the annotation API and the programmatic API.

TODO docs.

I just realized that this also requires a ${MAP-FALLBACK-VALUE} variable that can be used in the description of the option or positional parameter.


yarn docz:build goes wrong

Bug Report
yarn docz:build goes wrong
Describe the bug

A clear and concise description of what the bug is.
this is my package.json
{
  "name": "pc-design",
  "version": "1.0.3",
  "description": "pc-design in wpt",
  "main": "dist/bundle.js",
  "files": [
    "dist"
  ],
  "scripts": {
    "start": "webpack-dev-server --config webpack.dev.config.js",
    "dev": "webpack-dev-server --config webpack.dev.config.js",
    "build": "webpack --config webpack.prod.config.js",
    "docz:dev": "docz dev",
    "docz:build": "docz build"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@emotion/core": "^10.0.15",
    "@emotion/styled": "^10.0.15",
    "antd": "^4.0.0-alpha.2",
    "emotion": "^10.0.14",
    "prop-types": "15.6.0",
    "react": "16.8.6",
    "react-dom": "16.8.6",
    "scheduler": "^0.15.0"
  },
  "devDependencies": {
    "@babel/core": "7.2.2",
    "@babel/preset-env": "7.2.3",
    "@babel/preset-react": "7.0.0",
    "babel-loader": "8.0.5",
    "css-loader": "3.2.0",
    "docz": "^2.0.0-rc.1",
    "html-webpack-plugin": "3.2.0",
    "less": "^3.9.0",
    "less-loader": "^5.0.0",
    "style-loader": "^1.0.0",
    "webpack": "^4.39.2",
    "webpack-cli": "^3.3.6",
    "webpack-dev-server": "^3.8.0",
    "webpack-node-externals": "1.6.0"
  }
}

Expected behavior
how can i fixed this?

it's same to gatsby-theme-docz v2 build broken #985Open


Bad display in the grid

System information:

Windows 10 Pro, version 2004, build 19041.388
<IP_ADDRESS>008021649
None

Describe the problem you're observing:

The data in the column that is right-aligned overlaps the data in the left column

Steps to reproduce, if exist:

Change column width

The ticket duplicates https://github.com/dbeaver/dbeaver/issues/9411. It will be fixed in 7.1.5 release


Remove mocha-jsdom in favor of jsdom

We use a mix of jsdom directly and mocha-jsdom. When jsdom is updated, mocha-jsdom pulls it in automatically, but since mocha-jsdom has not been updated since February it is no longer compatible with the current jsdom version. Mocha-jsdom should probably be removed and jsdom used directly.
Current behavior

Updating jsdom leads to errors in tests using mocha-jsdom.

Expected behavior

Updates to jsdom should not depend on maintenance of mocha-jsdom

Steps to replicate behavior

Update jsdom to latest version.
Remove node_modules and npm-shrinkwrap.json
Run npm install && npm shrinkwrap --dev && ./frontend.sh
Run gulp test:unit:scripts and note errors such as ReferenceError: NodeList is not defined.

mocha-jsdom has been removed!

https://github.com/cfpb/cfgov-refresh/pull/3519


Page controller fires for PDF / download links

Page Controller fires when downloading a PDF link. Any work arounds to prevent PageController from firing on certain a href tags?

@jordan-sowers What version are you using?


is it possible to run the same generation but for people with no hair?

would be useful to do stuff like import into training for this
https://github.com/oneThousand1000/HairMapper

Could you clarify what you mean by running the same generation for people with no hair?
There are quite a few generated faces without hair in the dataset, it's possible to find them by querying the CLIP features for "bald hair", have a look here: https://www.kaggle.com/code/selfishgene/explore-synthetic-faces-hq-sfhq-dataset


Fixed #35843 -- Simplified explanation of formsets iteration behavior.

Removed references to specific methods and linked to the Python glossary for the term 'iterable.'
Trac ticket number

ticket-35843
Branch description
Provide a concise overview of the issue or rationale behind the proposed changes.
Checklist

[x] This PR targets the main branch.
[x] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[x] I have checked the "Has patch" ticket flag in the Trac system.
[ ] I have added or updated relevant tests.
[ ] I have added or updated relevant docs, including release notes if applicable.
[ ] I have attached screenshots in both light and dark modes for any UI changes.

@nessita as you also commented on the ticket, I will request you to review also as another set of eyes (when you're back from holiday, there's no rush/urgency here)

@nessita as you also commented on the ticket, I will request you to review also as another set of eyes (when you're back from holiday, there's no rush/urgency here)

Thank you @sarahboyce for the ping. I have read the ticket to refresh my memory, reviewed the patch and analyzed the referenced older ticket and commit.
On one hand, I think that removing the current information about the dunder (double underscore) methods is a loose: this information is not explained anywhere else (that I could find) and I think it's valuable. It may not be obvious that a formset can be accessed like formset_instance[1] and what that access would return. For this, I think that explicitly mentioning that a formset is/follows the Iterable API is a good but concise summary to the reader.
On the other hand, in the same docs page but further down below, there is a section about Dealing with ordering and deletion of forms, which feels confusing because one may think that can_order affects the ordering but I think it's only used for submitting data to reorder the forms after a (likely) POST request.
I guess my point is that the original concern in the ticket about documenting how forms in a formset could be reordered (after creation) is still not answered anywhere in the docs? Am I missing something? (brain is a bit rusty after holidays)

I guess my point is that the original concern in the ticket about documenting how forms in a formset could be reordered (after creation) is still not answered anywhere in the docs? Am I missing something? (brain is a bit rusty after holidays)

I agree with this but I think that's because we don't have "special" support for it (the docs was implemented as part of this commit 7adffae).
We can also wontfix the ticket

I would rather we don't wontfix it (sorry for the double negative) and instead I would love if we could add something like what @cliff688 proposed in the ticket:

you can change the order by overriding the iterator protocoliterable interface

The reason is that I think it's key to signal the reader that a formset provides an Iterable interface (a formset is an iterable not an iterator: __next__ does not need to be defined). It's certainly not the common case for a regular class, therefore I think that mentioning this explicitly hints the reader about the formset capabilities. I'll propose a suggestion below!

Proposed a slight change to the changes, let me know what you think!

Definitely a good improvement 👍🏾  Thanks

Happy to land this 👍

As per this comment I'm not 100% satisfied with mentioning the protocols without giving the context that overriding them allows reordering.

I may have been overthinking this 🥲. The current changes are fine, feel free to land them if you approve.

Happy to land this 👍

As per this comment I'm not 100% satisfied with mentioning the protocols without giving the context that overriding them allows reordering.

I may have been overthinking this 🥲. The current changes are fine, feel free to land them if you approve.

In the interest of time and saving energy from all of us, perhaps this is the best course of action! Thank you for staying on top of all the comments.


Ros bridge odometry msg

Description
This pull request add nav_msgs/Odometry for player vehicle in carla_ros_bridge. Navigation message is relative to "/map" frame.
Where has this been tested?

Platform(s): Ubuntu 16.04
Python version(s): 2.7
Unreal Engine version(s): ...

Possible Drawbacks

This change is

Could be merge after the minor code modification request

@laurent-george Fixed imports. Is there a way to get velocity value in CARLA for publishing in geometry_msgs/Twist?

Hi @ShepelIlya! Have you seen Player Measurements section on this page? Look at the forward_speed and acceleration measurements if you haven't.


NodeJS cluster module

Hello,
is it possible to use the NodeJS cluster module with grpc?

Currently, gRPC does not work with cluster. We are working on changes to add at least partial support.

@murgatroid99 How is this issue going? We met the same problem, single process on node is like a hell

I'm working on it, but it has required some major internal changes. Pull request #8125 is a large part of it, and I expect to have this done by the end of the quarter.

+1

@murgatroid99 How is this issue now? It's been already 2017 Q1.
I saw that PR #8125 was merged?

The next step is getting grpc/proposal#8 accepted and implemented.

+1

Is this issue fixed

fixed?

Would love to see this supported as well. Hopefully there's a fix soon!

Hi,
is this supported now ?

Still not. The fact that the core added SO_REUSEPORT support for Linux diminished the priority on this one.

man, it's been 2 years........we actually refactored our code in GO already.
I will see when this will be fixed, maybe the day deno takes place of node.

Kubernetes is in charge for doing this, clustering and etc. you shoudlnt use nodejs cluster module or something like pm2 .

The main reason is that grpc should by default allow opening the same TCP socket multiple times from different processes, effectively doing the same thing, in a simpler manner.

@pratapdd there is no need of fixing this while (as you also mentioned) clustering job should handle by other tools like kubernetes.

Our team not use kubernetes yet, we have to create multiple hosts. It's annoying.


Added ore boxes to cargo.

About the PR
Fixes #20251.
Adds orderable ore boxes to cargo.
Changelog
:cl:

add: Ore boxes are now orderable from cargo.

Why would cargo order ores instead of the refined materials? Is there a benefit to it?
Cargo just needs to get orders for silver and gold already.

its for an ore box not ores...

its for an ore box not ores...

Exactly what delta said and to expand I believe cargo not being able to order gold and silver is intentional maybe not.
It gives salvage a duty to provide the station with necessary material it can not order.

It should be ready for merge let me know if i broke anything else


unsupported UserAgent for Yandex.Browser

Yandex browser (https://browser.yandex.com) can have this kind of UserAgents:
on windows - Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 YaBrowser/<IP_ADDRESS>63 Yowser/2.5 Safari/537.36
on mac - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 YaBrowser/<IP_ADDRESS>65 Safari/537.36
and http://www.material-ui.com/#/components/app-bar - does not work well with it.
but if i remove all yandex part (YaBrowser/<IP_ADDRESS>63 Yowser/2.5 - for Windows , or  YaBrowser/<IP_ADDRESS>65 - for Mac) - it works fine.

As clearly written in the documentation, we do not support Yandex browser out of the box. I would suggest to use the static version instead. Caniuse.com doe s not provide any information on prefixes used within the Yandex browser.


DNS Resolve Issues when creating overlay network in same subnet as eth0

Output of docker version:
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:11:07 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:11:07 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 34
 Running: 3
 Paused: 0
 Stopped: 31
Images: 9
Server Version: 1.11.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 176
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 19.61 GiB
Name: WS23
ID: 3GNK:7E76:MOGV:QU5Y:XE53:NLP6:ZHIV:S5FF:J2KR:VZGN:RGZV:QGSR
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Cluster store: consul://ws23:8500
Cluster advertise: <IP_ADDRESS>:2375

Steps to reproduce the issue:

setup docker swarm
create network on docker swarm using docker -H :4000 network create test
run container in this network docker -H :4000 run -it --net=test busybox bash
in container run ping google.com -> will fail!

Describe the results you received:
Ping did not resolve to company internal DNS (<IP_ADDRESS>)
Describe the results you expected:
Should resolve name using the company iternal DNS
Solution
Do not create a network with the same subnet as eth0 of host (<IP_ADDRESS>/24).
Workaround: Specify subnet in create network, which is different than eth0
e.g. docker -H :4000 network create --subnet=<IP_ADDRESS>/24 --gateway=<IP_ADDRESS> hadoop
Also checkout this gist: https://gist.github.com/plieningerweb/dc83d5133e8bf113f2010e1bc79a9d16
Expected Fix
docker network create should not create a network in the same subnet as the hosts' eth0, if this leads to routing issues and (in this case) failure of DNS lookups.

/cc @mavenugo PTAL

Maybe similar to this issue
Refer to code, it directly returns a un-check's pool due to overlay network's datastore scope is global?

This is an old issue.  I will close it as stale.


Fix frozen-counters bug with multiple #pause commands

Description
This PR addresses a bug in the frozen-counters functionality where status updates show unexpected behavior when using multiple #pause commands. This issue may be related to #72.
Problem
When using multiple #pause commands, figure captions are not correctly incremented. For example, in the example below with multiple figures and pauses, the final figure might be captioned as "Figure 2:" though it should be "Figure 3:".
#import "@preview/touying:0.5.3": *
#import themes.simple: *

#show: simple-theme

== slide 1
#figure([test figure], caption: [caption])

== slide 2
#figure([test figure], caption: [caption])
#pause
paused

== slide 3
#figure([test figure], caption: [caption])
#pause
paused

Solution
Instead of storing the counter value at the beginning of a sequence of subslides, we now store the location. We then use status.at(location) to rewind the status when needed. This approach ensures that counters are correctly updated across pauses and slides.
Testing
I have tested my code with examples given in the examples folder in this repository, besides the example above, and two examples in #72. All of them compiled with no errors / warnings.

As I'm not fluent in Typst, my code might not be fully ideomatic. I welcome any revisions or improvements to the implementation.
It might be better to store the location in some outer variable (e.g. #utils.current-slide) and update it when creating a new slide, instead of querying the label for every new subslide.
minor fix: I found a variable named current, which is not used, so I deleted it.

It might be better to store the location in some outer variable (e.g. #utils.current-slide) and update it when creating a new slide, instead of querying the label for every new subslide.

I found this idea won't work because Typst doesn't allow changing outer variables within a context. Therefore, querying the label for every new subslide is necessary with this approach.

I added a new state #utils.loc-prior-newslide to store the location of parent slides. This simplifies the code and improves readability (and performance?) The implementation works well in testing. Sorry for sending multiple comments in a short period.

Thank! I'll check it out later.

Thanks, I think your method is more elegant.

With this PR, we can also add the counter(heading) to the frozon-counters: https://github.com/touying-typ/touying/commit/34bfe9e5165923baca950339e2bd19631cf4c806


Add schema for YAML

Add schema for the config.yaml, packages.yaml and compilers.yaml files in recipes.
We hardly check or validate the input in these files, and using a schema looks like the best line of defence for validating input and giving early feedback to users.

Schema were added in #31.
The schema for packages.yaml remains to be done.


Enderchest should also be added for dimensional-inventories

Heya,
I just found out that Enderchest are not added in the mod, since i only know javascript and not java, i cant tell how hard it would be to add, but i think it shouldn't be a problem :), would be nice
we use the 1.20.2 Version

Hey again,
Are you talking about the vanilla ender chest? If so, that's a bit strange. It's been implemented since the first release, but maybe there's a bug or incompatibility in there somewhere.
I gave it a quick test, both in singleplayer and on a dedicated server. In both cases, ender chest functionality worked, but I also didn't have any other mods installed.
Could you send...

A copy of the <world>/dimensionalinventories folder (a ZIP archive is fine)
A list of mods and versions (this should be at the top of the log output when you start the server)

Heya,
Um, we're really sorry, but I've got it sorted now. So, when I created the world, the enderchest got duplicated into the new dimension. Then, I configured the inventory on both ends, meaning both had the same enderchest setup.
Since we had our enderchest set up with our usual default settings, it always appeared like it was the same enderchest in both dimensions. We only noticed this while testing a building, and, well, we accidentally opened the enderchest.
Our bad for the false alarm!

Ahh, I see. No worries; it happens :)


The plugin isn't setup correctly for download from asset library

When I try to download the asset from the the editor using the assetlib tab, download succeeds but I am unable to open anything because the project is in a subfolder.
This is all I see after download:

That doesn't seem right at all..
default_env.tres and icon.png should both be in the volume project sub folder.
See, the reason why I set up the folder system like that was so that the volume generator would not be imported by godot.
That was before I new of .gdignore.
Also wouldn't you still be able to open it? You know by opening the project.godot file?
You obviously have more experience than me so I just want to know.

I can open the sub-project yeah, but not from Godot. The flow of creating a project and installing your addon in it doesn't work.

Installing the addon.Oh that's in volume project/addons/"the addon".
I always thought the workflow was to just copy and paste that mentioned folder into your other project's addon folder. Then going into project settings to enable it.

Well I guess I can say this. I am working on a mesh voxelizer that will be inside Godot. Eliminating the need for an external volume generator. When it's ready I can get rid of the current folder hierarchy in the place of the more familiar one.

Ok. Its now version 1.3, and the volume generator is no inside the editor itself.


Program closing unexpectedly when calling Core constructor

Basically the headline. I can execute Core.init() without any error, create the Params and everything just fine, and then I construct a new Core object. My program then exits, without calling finalize / shutdown hooks. Discord switches to the Games tab (where all your Games are listed). I didn't change any code that would interfere with Discord, I use the same code which has worked for a couple weeks now, but it failed just today. From debugging I found out that it probably crashes somewhere in the create() native method.
the code I use:
	String discordLibraryName;
	if(System.getProperty("os.name").toLowerCase().contains("windows"))
	{
		discordLibraryName = "discord_game_sdk.dll";
	}
	else
	{
		discordLibraryName = "discord_game_sdk.so";
	}
	Core.init(new File("libraries\\de\\jcm\\discordgamesdk\\natives\\" + discordLibraryName));

	CreateParams params = new CreateParams();
	params.setClientID(CLIENT_ID);
	params.setFlags(CreateParams.getDefaultFlags());

	core = new Core(params); // fails here

	Activity activity = new Activity();

	// set activity stuff (I removed this, there's actual code here)

	core.activityManager().updateActivity(activity);
	activity.close();

Hmm... I sadly cannot reproduce your error.
Is there any sort of crash report on console or a minidump/crash log file?
If not, please set the flags in CreateParams to 1 (which translates to DiscordCreateFlags_NoRequireDiscord).
Without this flag the SDK will terminate your application, if Discord isn't running.
With this flag set, you will at least get a Java exception if the SDK fails to communicate with Discord.
Setting this flag will probably not solve the issue, but it might help to gather more information about it.
Please also tell me which OS and Java version you are using.

 For some reason, it now works perfectly fine. I gotta remember to restart my PC and test again before making a issue.
Thank you for responding so quickly tho

No problem, this has happened to all of us :)
But I'm glad that it works again now. :partying_face:


Content installer ( Batocera Store ) Initial UI

Bezel Installer : UI Rewrite & Simplification ( on the same model as Content Installer )
Scraper : Add Tic-80

Wonderfull UI rewrite for the bezel projet. Thanks


Create and test Kontain enabled ECS optimized AMI

Note: depends on new build script in KKM (https://github.com/kontainapp/kkm/pull/20)

Very cool script to test the bring up of the cluster.


The link of the model/config in the readme.md seem to be dead.

I am trying to replicate the results on foodseg103 with SeTR-MLA(ViT-16/B). The link provided in readme.md leads to a 404 error page of google drive, please fix this.
Thanks

@KombangkoeDias Hi, since we blocked url of the models before, and I put all the models in this link: https://smu-my.sharepoint.com/:u:/g/personal/xwwu_smu_edu_sg/EWBcCC3QrO9LthKX66QCzyoBhFU7PHXKcHhh1lgIC98uKw?e=bHT7vM , and you can find the SeTR-MLA here.


Add option to expose web UI on a custom port

Problem/Motivation
I like to be able to access various add-on's UI directly vs. within HASS to reduce the amount of extra chrome. This does not currently seem to be possible with this add on.
Expected behavior
Add a config option for the addon to expose the web UI on a given port

Add a config option for the addon to expose the web UI on a given port

That won't be added as it adds unneeded complexity and maintenance to the add-on. The add-on is available via Ingress only.
All add-ons community add-ons that are ingress capable will move (or have been moved) to this model over the years.
../Frenck

I am not following your comments reasoning here to build a case.

There are also things that don't even work, like node red's dashboards

That is why Node-RED does have an port exposed. This is documented as well. This is not the same case as represented here, nor is it limited.

Or things that don't support ingress at all like nginx proxy manager.

Yes? So? I had a port available for that reason.
🤷♂


Use shield for version and amend readme a bit

Not sure if this is the right wording, but in practice that's pretty accurate I thought?
cc @jrudolph @sirthias

It's kind of temporary I guess, since I hope to get the discourse running soon and we could make space for it there I guess? spray-user I assumed to be not operating nowadays


Vuex / Computed Prop

Hi,
What is the best way to get the title from a Vuex getter?
Current problem is my Title is not the same as in the Post on the page first after a F5 Refresh the title is correct
<template>

 {{post.title}}

</template>

Also the title in post.title != my title in metaInfo but its should i dont know its a problem because async
  name: 'SinglePost',
        computed: {
            post() {
                var post = this.$store.getters.getPost
                return post;
            }
        },
        metaInfo: {
            // if no subcomponents specify a metaInfo.title, this title will be used
            title () {
                    return this.post.title
//The title is not the same as on the page the title is from the last visited page
            }
        },
        data() {
            return {
                post: {}
            }
        },
        preFetch: function (store) {
            return store.dispatch('singlePost', store.state.route.params.slug)
        },
        mounted() {

            this.$store.dispatch('singlePost', this.$store.state.route.params.slug)

        },

    }

When i use in Simple Components works fine
//E maybe the problem is from my side how i handle Switching the post
Problem is it updates not all the time when i console.log out in the metaInfo i see its just hits on the first load and not when switchting between my posts
{
          path: ':slug',
          component: SinglePost,
          meta: {
            bodyClass: 'light',
          }

Or its something like  #9
sry my english is not so good

Thanks for the report @cannap - it seems as if this is related to #9. I will have a look at it tomorrow (its night time here)

Hi @cannap!
I submitted a fix for this in https://github.com/declandewet/vue-meta/commit/6ad56ec73e428316c2e4c115274ca655024c2810
I also put together an example for you to look at on how to use Vuex getters.

Hi, is this already on npm? or should i just use the github version and compile by my self

@cannap it's not on NPM yet because it's not what I would consider stable enough to be released :wink: - use the github version for now, and make sure it's not in your Webpack excludes

Hi, yes i updated via github and checked the example
when the action is async
  actions: {
    getPost ({ commit }, payload) {
       setTimeout(() => {
          commit('getPost', payload)
       },2000)
    }
  }

same problem

@cannap Ah! I see what you mean! I'll have a look at it tonight. Getting a fix in for this will be tricky, though.

good i cant wait to use this thing 🗡 i waited since vue 2.0 for something like this 🗡  because i had no idea how to make my own my first solution was reading the store on server but this was ugly

Same - I'm building it because I'm really going to need something like it soon :D

@cannap - the "fix" has landed! :tada: https://github.com/declandewet/vue-meta/commit/076832cbd6b2ffcc804fcdb2a9edd438c58573b5
You can check out this example to see how handling async actions is done: https://github.com/declandewet/vue-meta/tree/076832cbd6b2ffcc804fcdb2a9edd438c58573b5/examples/vuex-async


mkcert -install hangs

Environment
Hello,
I install on my macOS 13.6 (22G120) normally ‘brew install mkcert’ then mkcert -install check again the version mkcert -version and as far as I can see everything is installed with version 1.4.4 fine.
Now I try to start a ddev project with ddev start and no matter with which project it always hangs when checking the certificate.
I have checked everything so far, the certificates are created and I can also see them in the macOS keychain, but the connection or query does not seem to work.
I have also analysed the mkcert, but as I am not a developer, the protocol does not tell me anything.
How can it be that the communication does not work, do you have a solution for the problem?
Analyse von „mkcert“.txt

We've seen a number of instances of a hang like this where Java was apparently misconfigured. The solution in this case was to unset JAVA_HOME before mkcert -install and that solved the problem.
Related:

Stack Overflow problem mentioning java Keytool
https://github.com/FiloSottile/mkcert/issues/425