Acked sequence number wrong(?) after wrap around

Hi!
My RTMP client uses the acknowledged sequence number in the Acknowledgement control message to keep track of how much data that is in flight. It works well when streaming to Twitch and Youtube, but when streaming to this server it does not. The acked sequence number wraps at i32-max or u32-max in those services, and the next acked sequence number is the rest (modulus). In this server it wraps at 0xf0000000, and the next acked sequence number is always 0. So seems impossibly to kow exactly how much data is acked.
https://github.com/illuspas/Node-Media-Server/blob/master/src/node_rtmp_session.js#L498-L506
I can't find anything about this in the RTMP specification unfortunately.
Looks like GStreamer expects it to wrap at u32-max. https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/gst/rtmp2/rtmp/rtmpconnection.c?ref_type=heads#L973

Any comments on this?


build failed with tf-op

Branch/Tag/Commit
v5.3
Docker Image Version
nvcr.io/nvidia/pytorch:22.12-py3
GPU name
T4
CUDA Driver
NVIDIA-SMI 470.57.02    Driver Version: 470.57.02    CUDA Version: 11.8
Reproduced Steps
build with "cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_MULTI_GPU=ON -DBUILD_TF2=ON -DTF_PATH=/usr/local/lib/python3.8/dist-packages/tensorflow/ .." and make
error message:
/workspace/FasterTransformer/src/fastertransformer/kernels/disentangled_attention_kernels.cu(382): error: more than one operator "=" matches these operands:
            function "__nv_bfloat16::operator=(float)"
/usr/local/cuda/include/cuda_bf16.hpp(178): here
            function "__nv_bfloat16::operator=(double)"
/usr/local/cuda/include/cuda_bf16.hpp(181): here
            operand types are: __nv_bfloat16 = int
          detected during instantiation of "void fastertransformer::disentangled_attention_kernel<TDataType,tTileSize,tBlockDimY>(TDataType *, TDataType *, const TDataType *, const TDataType *, int32_t, int32_t, int32_t) [with TDataType=__nv_bfloat16, tTileSize=32, tBlockDimY=8]"
(407): here

/workspace/FasterTransformer/src/fastertransformer/kernels/disentangled_attention_kernels.cu(382): error: more than one operator "=" matches these operands:
            function "__nv_bfloat16::operator=(float)"
/usr/local/cuda/include/cuda_bf16.hpp(178): here
            function "__nv_bfloat16::operator=(double)"
/usr/local/cuda/include/cuda_bf16.hpp(181): here
            operand types are: __nv_bfloat16 = int
          detected during instantiation of "void fastertransformer::disentangled_attention_kernel<TDataType,tTileSize,tBlockDimY>(TDataType *, TDataType *, const TDataType *, const TDataType *, int32_t, int32_t, int32_t) [with TDataType=__nv_bfloat16, tTileSize=64, tBlockDimY=4]"
(407): here

2 errors detected in the compilation of "/workspace/FasterTransformer/src/fastertransformer/kernels/disentangled_attention_kernels.cu".

@jackzhou121 ,
I had same issues, and resolved them using following patch. This code casts the value into a double, ensuring that the compiler always chooses double operands for the "=" operator.
--- a/src/fastertransformer/kernels/disentangled_attention_kernels.cu
+++ b/src/fastertransformer/kernels/disentangled_attention_kernels.cu
@@ -379,7 +379,7 @@ __global__ void disentangled_attention_kernel(TDataType*       result,
 #ifdef ENABLE_BF16
         else if constexpr (std::is_same<TDataType, __nv_bfloat16>::value) {
             // bf16
-            res = __hadd(res0, __hadd(res1, T[threadIdx.x][ty + threadIdx.y]));
+            res = static_cast<double>(__hadd(res0, __hadd(res1, T[threadIdx.x][ty + threadIdx.y])));
         }
 #endif


Add Cross-Origin-Resource-Policy header to embeddable files

Fixes #290.
See more: https://resourcepolicy.fyi/

I am not normally a JS dev and didn't manage to run this locally.

This change would help a lot for my project, Starboard Notebook which allows users to execute Python in the browser (in order to do so in a non-confusing way, SharedArrayBuffer is required).
Is there anything blocking this PR from being merged? @mjackson

This change would help a lot for my project, Starboard Notebook which allows users to execute Python in the browser (in order to do so in a non-confusing way, SharedArrayBuffer is required).
Is there anything blocking this PR from being merged? @mjackson


HTTP Request Routing Example (DS) doesn't match TR

When you enable a delivery services via HTTP, the example shows a http://ccr.tld. Although after a while troubleshooting why it didn't work, found out that the Traffic Router is using "tr" instead of "ccr".
I have looked in the database but couldn't nor find configuration for this, would be great to be able to change it to whatever we like.
UI Example
http://ccr.live.cdn.ltest.net
auto-zone config
tr.live.cdn.ltest.net.	3600	IN	A x.x.x.x

tr is correct and ccr in the example should be changed.

This is due to our transition to open source, and will be rectified under issue #142.  The UI says "ccr" and is not currently configurable or database driven.  The routing name can currently be configured by modifying /opt/traffic_router/conf/http.properties.  #142 will allow these to be user configurable.

See #142


geometric mechanism proof

make_base_geometric sets up a function that returns a draw from a censored two-sided geometric distribution. The code can be found in this Github permalink.
Files:

mod.tex -- the LaTeX document with the proof.

TODO: proof for sample_two_sided_geometric function

Will need to update this PR until after #685. After that issue is closed, the pseudocode in this PR will simplify.
This PR also needs to be adjusted to use lib.sty, and use the standard proof template (Hoare Triple & Proof).


Query Subpath after find()

Hey there,
is it possible to query urls like this:
http://localhost/document/4362010470902532462/content

where<PHONE_NUMBER>902532462 is the ID of a specific document?
In code I would expect something like this (but of course this wont work currently):
let document = this.API.documents.find(documentId).content.all();

You can do that
let document = this.API.documents[documentId].content.all()

Ahh! It works :-)
Thx for the fast response and the great library!


impossible to add mailto button at the top right corner

I tried to add the following to menu.toml
[[main_right]]
  name = ""
  post = ""
  url =<EMAIL_ADDRESS>  weight = 1

but the theme automatically prepends the website domain to mailto:xxxx.
A possible fix ?
Tks !

Academic uses the Contact widget for email functionality. There isn't much demand to support mailto protocol in navbar but feel free to contribute a PR if you wish :)

I can get it to work in mine with the following code (but the alignment is a little wonky, haven't tried addressing that yet.. actually, kinda OK with it):
  name = "<a<EMAIL_ADDRESS>class=\"far fa-envelope\" style=\"color: #111; font-size: 1rem; line-height: 1.25\">"
  post = ""
  url = ""
  weight = 40


Explore alternate build systems

We originally built CHERIoT RTOS with CMake.  This had a number of problems because CMake is not designed to allow users to build abstractions.  We replaced it with xmake prior to open sourcing, and xmake is mostly fine.
Requirements
We need to be able to build four kinds of things:

Special things (mostly the loader)
Shared libraries
Compartments
Firmware images

Ideally, we also want to be able to add other composable chunks, which can be made dependencies of compartments or provided separately, including:

Threads (for example, it would be nice if the TCP/IP compartment could describe the worker thread for TCP processing as a dependency)
Pre-shared objects

Shared libraries and compartments have a custom link step, as do firmware images.
Firmware images need to be able to walk their dependency graph and build a linker script containing all of the libraries and compartments.
Board description files (JSON, kind-of JSON5, could be YAML) need to be parsed to generate compiler flags, inputs to the firmware linker script, and so on.
The build system must be able to generate compile_commands.json files for IDE integration.  It's 2024, this is no longer a 'nice to have' optional extra.
For secure build environments, we must be able to do builds from a read-only mount of the source tree.  In-tree builds are an antipattern.
We should be able to build abstractions that allow very concise definitions of projects.  The current xmake build system is fairly good here.  Going through the simplest hello-world example line by line:
set_project("CHERIoT Hello World")

This is slightly redundant because we need to name firmware images and so the overall project name is not very meaningful.
sdkdir = "../../sdk"
includes(sdkdir)
set_toolchains("cheriot-clang")

This is quite ugly.  We are forced to hard-code the path of the SDK (more on this later) and then, because of xmake's scoping, also specify the toolchain here, even though the SDK files already specified it.
option("board")
    set_default("sail")

This is necessary because we don't advertise the board option from the SDK, we make each firmware select it.  This is probably the right choice.  Some projects may want to build firmware for different projects (the build2 proposed solution here is to have different build configs for each), others may not allow the board to be an option because they're specialised for a single SoC / board.
compartment("hello")
    -- memcpy
    add_deps("freestanding", "debug")
    add_files("hello.cc")

Again, this is concise.  We are defining a compartment called hello, it depends on the freestanding and debug libraries (could be compartments).  It has a single source file, hello.cc.  This will be compiled with the default options for a compartment and linked as a compartment.
firmware("hello_world")
    add_deps("hello")

We're starting to define a firmware image called hello_world, it depends on the hello compartment.
    on_load(function(target)

Now we see some of the less-nice bits of xmake.  You can't extend the xmake declarative syntax, you can only add properties in the imperative world, so we now need to write a Lua function that runs when this target is loaded.
        target:values_set("board", "$(board)")

In declarative syntax, this would be simple set_board("$(board)"), but that's a small issue.
        target:values_set("threads", {
            {
                compartment = "hello",
                priority = 1,
                entry_point = "say_hello",
                stack_size = 0x200,
                trusted_stack_frames = 1
            }
        }, {expand = false})

This defines a single thread, its entry point, and so on.  It would be nice to have this be a type that could be automatically type checked (the build2 prototype does this), but this is largely fine.
The really ugly thing here is the { expand = false }.  This is not properly documented in the xmake docs, but is essential to avoid xmake flattening the object that you've put here.
Problems with xmake
Although xmake works, we have encountered a lot of problems over time.
Poor defaults
A build system should loudly complain if things are wrong.
If you add a nonexistent file (for example, add it with a .c extension instead of .cc, or fail to commit it to git), xmake does not complain.  It simply builds and, if the link step works, the build succeeded.  You probably didn't need the file anyway.  We had a test that the FreeRTOS compat headers all compiled in C mode that was spuriously passing for months as a result of this (I added the xmake bits, forgot to add the .c file, and CI passed).
By default, xmake hid compiler warnings (this was fixed in v2.8.7).  This is the worst possible default.  The argument from the maintainer was that 'most users' didn't need to see them.  I believe that most users of a build system are developers and they absolutely need to see warnings.  The second most common users are people building packages, and they should see warnings because they may help debug problems.  The third category are people who are building things from source but are not developers, and these people are a rounding error and probably don't care either way.
If you add a compiler flag, xmake will drop it if it isn't supported.  It doesn't try passing it to the compiler to see if it's supported, it has some internal model of the compiler (which may or may not be relevant for a cross-compile toolchain) and ignores it.  You must add {force = yes } (which was undocumented the first time I needed it, I'm not sure if it's documented now) to make xmake do the thing that you explicitly told it to do.
Similarly, if you pass a positional argument with any of the flag-adding functions, even with {force = true}, and xmake doesn’t know about the argument, then it will deduplicate it. Things like -Xclang or -mllvm, which need to be passed multiple times are silently removed. There is no documented way of avoiding that, but there is an undocumented way, which is to pass the pair of flags as a Lua array and add expand = false in the last argument.
Everything in xmake is a string.  The type of a build rule is a string.  If you make a typo, it will silently make the target use the default rule.
Insecure searching
Unless you explicitly specify a target path, xmake looks up the directory tree to find the xmake.lua furthest from you.  This may be across a mount point and controlled by a different user.  This is an incredibly insecure default.
Poor scoping
Targets in xmake must have globally unique names.  Some things are local to the file, others are not.  For example, you must set the toolchain in the top-level file, you can't provide it in the SDK file.
Extensions are second class
Internally, xmake defines a lot of different target types.  These have access to a load of infrastructure that is exposed.  Anything that is implemented externally lacks access to this infrastructure and so cannot work as well as things built into the build system.
Opaque dependency tracking and poorly specified execution order
We have several custom rules.  It's not clear how to tell xmake that a given file is a dependency of them.  Sometimes, the only way to get a safe rebuild is rm -rf .xmake build.
xmake also provides its own caching, which is not invalidated when the toolchain is updated.  This breaks reproducible builds and introduces bugs when a new toolchain feature is required.
Options are not processed until after the declarative syntax is processed (and the declarative syntax isn't really declarative).  This means that you can't use an option to provide the SDK path.  We'd like to be able to have build files that have a default path for the SDK, but let you override it.  With xmake, we need to modify xmake.lua.
Similarly, it's unclear what order the on_load functions for different targets will run in.  We tried using the support that was added for dynamically cloning targets for the allocator, but this was impossible because the new target's on_load things didn't run.
There probably is some internal model for how builds work, but the author has not written it down anywhere.
Other options
There are a few potentially promising alternatives that we should explore before we do a 1.0 release and need to support whatever we ship for a long time.  For some reason, they seem to be things that match the pattern B.*2.
Build2
Build2 is a fairly new build system that is designed to support modern C++ features.  @boris-kolpackov has built us a proof of concept that can build the hello-world example.  We need to:

[ ] Port the other examples / tests / and so on to use this.
[ ] Refine the proof-of-concept
[ ] Either extend build2 to be able to parse hex literals in JSON or add a preprocessing tool for board description files.
[ ] Provide a flow to generate compile_commands.json (not yet working out of the box and a must-have feature).
[ ] If it works, add an xmake target that will generate build2 files from existing projects.

It looks quite promising.  I don't like the fact that compilation is conceptually a separate step.  To me, compilation flags depend on the target (library, executable, whatever) and the fact that you have to declare separate cxx things is not ideal.
I also don't like the focus on short names in build2.  These are hard to search for and they place a higher cognitive load on the programmer.  Most developers will spend 1% of their time touching the build system, so a build system needs to be easy for people to context switch back to.  I find a lot of the build2 logic hard to read.
I also don't like the fact that every project needs three files in two directories to build.
Buck2
Buck2 is a rewrite of Facebook's Buck build tool.  It uses Starlark, a Python-like language, for scripting and exposes all of the rules, which means that our build rules would be equivalent to first-class rules from other places.
Buck2 is written in Rust and provides a single statically linked binary that is easy to deploy.
We currently have no proof-of-concept in Buck2, but it is probably worth exploring.
Others?
CMake was used originally and its limitations were too great.
  Bazel requires both a working Java VM and a Python installation.  This is fragile and far too big a supply-chain attack surface for something in every build.
tup / make are low-level tools that rely on third-party things if you need abstractions.  We don't want to maintain a tup generator.
Any others that we should evaluate?

Now we see some of the less-nice bits of xmake. You can't extend the xmake declarative syntax, you can only add properties in the imperative world, so we now need to write a Lua function that runs when this target is loaded.

Xmake supports custom description description scope interfaces. You can customize the firmware and compartment scope api, as well as all configuration interfaces, like this:
https://github.com/xmake-io/xmake/blob/dev/xmake/includes/xpack/xmake.lua
https://github.com/xmake-io/xmake/blob/6c973f55a3130fe62342e4ab06e992eac6ee3a80/xmake/plugins/pack/xpack.lua#L521
https://github.com/xmake-io/xmake/issues/1433#issuecomment-1811761871

Targets in xmake must have globally unique names.

v3.0 will provide namespace to support it. https://github.com/xmake-io/xmake/issues/5527

If you add a compiler flag, xmake will drop it if it isn't supported. It doesn't try passing it to the compiler to see if it's supported

you can disable this policy. set_policy("check.auto_ignore_flags", false)

Xmake supports custom description scope interfaces. You can customize the firmware and compartment scope api, as well as all configuration interfaces, like this:

Are these documented? I thought they were only for internal use. If we can use them, we could tidy up a lot of our code.
It would be great if we could support add_threads and add_preshared_object on our target types and remove the need for downstream users to write on_load things in most cases.

v3.0 will provide namespace to support it

Yay!

you can disable this policy.

This comes back to the scoping problems. Yes, I can disable it, but I have to set this policy in every file. I can’t just put it at the top of the SDK file that everyone includes and have it fixed.
And that’s related to the ‘sane defaults’ problem. It is a very bad design choice for xmake to decide that it knows what flags an unknown version of a third-party tool supports. This will always be wrong because xmake has no visibility into what the tool is. As such, it gets added to the list of things where, in every project, I need to change the defaults.

Are these documented? I thought they were only for internal use. If we can use them, we could tidy up a lot of our code.

no document now. But it's public api. you can see above links.
and see https://github.com/xmake-io/xmake/issues/4276
and whole example:
https://github.com/xmake-io/xmake/blob/dev/tests/apis/custom_scopeapis/xmake.lua

sdkdir = os.getenv("SDK") or "../../sdk"
includes(sdkdir)

SDK=/xxxx/sdk xmake

Firmware images inevitably pull in lots of external code that uses
something other than xmake for building. You can see this here:
https://opensecura.googlesource.com/hw/matcha/+/refs/heads/master/sw/device/cheriot/soundstream
where I chose to use xmake because of the complexity of building a firmware
image but then had to explicitly collect the OpenTitan dependencies for the
SPI support.
The other thing I'd mention is that firmware images must be consumed by a
test environment. This means packaging, loading, etc. Here's a simple
example of integrating cheriot-rtos firmware image building:
https://opensecura.googlesource.com/build/+/refs/heads/master/platforms/sencha/cheriot.mk
and how we tie things together for simulation with renode & mpact-cheriot:
https://opensecura.googlesource.com/build/+/refs/heads/master/platforms/bancha/sim.mk
Likely all the above could've been done better with bazel because a large
portion of our repo uses that but I was worried that re-implementing much
of sdk/xmake.lua in bazel would be a sisyphean task given the velocity of
changes. The above also ignores all the infrastructure we have for CI and
hw testing.
On Fri, Oct 4, 2024 at 8:05 AM ruki @.***> wrote:

sdkdir = os.getenv("SDK") or "../../sdk"includes(sdkdir)
SDK=/xxxx/sdk xmake
—
Reply to this email directly, view it on GitHub
https://github.com/CHERIoT-Platform/cheriot-rtos/issues/304#issuecomment-2393917664,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRM7IIYPI57NZMF5YMVILLZZ2VBZAVCNFSM6AAAAABPJX5ZXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJTHEYTONRWGQ
.
You are receiving this because you are subscribed to this thread.Message
ID: <CHERIoT-Platform/cheriot-rtos/issues/304/2393917664
@.***>

A couple of questions/clarifications about build2:

a fairly new build system

The project is almost 10 years old. The first commit has the 2014-12-03 date (and there were months before that thinking with a pen and paper).

Provide a flow to generate compile_commands.json (not yet working out of the box and a must-have feature).

I am actually wrapping up the compilation database support and should have it available in the staged toolchain in a few days. Will ping this issue when it's ready with a link to the documentation.

I don't like the fact that compilation is conceptually a separate step. To me, compilation flags depend on the target (library, executable, whatever) and the fact that you have to declare separate cxx things is not ideal.

Hm, I am not sure I follow. Compilation is definitely not a separate steps if we are talking about the build execution. Could you expand on what you mean here?

I also don't like the fact that every project needs three files in two directories to build.

You can have a project with a single buildfile though it has some limitations. We've been gradually lifting these limitations replacing them with sensible defaults. So we can definitely explore supporting what you have in mind with a single buildfile.

The project is almost 10 years old. The first commit has the 2014-12-03 date (and there were months before that thinking with a pen and paper).

CMake is 24 years old, Make is from the dawn of the Epoch.  Anything from this Millennium (xmake, build2, bazel, buck2) is new to me.

I am actually wrapping up the compilation database support and should have it available in the staged toolchain in a few days. Will ping this issue when it's ready with a link to the documentation.

Yay!

Hm, I am not sure I follow. Compilation is definitely not a separate steps if we are talking about the build execution. Could you expand on what you mean here?

This is one of the things I quite like about xmake: Rules have a map-reduce structure.  There's a map phase (take a load of inputs, turn it into an equal number of outputs) and a reduce phase (take those outputs and combine them into a smaller number of outputs).  Both of those steps are optional, but they follow my mental model of how I build software.  The .cc -> .o step is not a distinct rule, it is an implementation detail of how I build a program/library/compartment.

You can have a project with a single buildfile though it has some limitations. We've been gradually lifting these limitations replacing them with sensible defaults. So we can definitely explore supporting what you have in mind with a single buildfile.

Great!  I really want people to have to read/write/maintain the smallest possible amount of boilerplate.

The .cc -> .o step is not a distinct rule, it is an implementation detail of how I build a program/library/compartment.

True typically, but not generally. The first example that comes to mind is unit testing: for a unit test you may need to link directly to the object file of a library rather than to the library itself (in order to get access to non-exported bits). So in build2 we chose to make the model general enough to accommodate such use-cases but also support automatic intermediate dependency synthesis (o: cc) for the typical case. The result is that as a user you are not exposed to such intermediate targets until you need to. Perhaps xmake does this differently, but the end result for the typical case should look the same, at least from the user's perspective.

Ok, the compilation database support is now available in the latest staged build2 toolchain. There is also the Compilation Database section in the manual with the documentation. And I've added an example to the BUILD2-README.md in my fork of cheriot-rtos.
There is one interesting question/observation: because we build the cheriot-rtos components as part of the user project, we end up with compilation commands for all the OS and system libraries that are pulled by the project. Not sure if this is desirable. If not, we may need to add some more filtering facilities (e.g., based on source path) since I don't think the ones we have (input/output target type) will be sufficient. This is what the database contains for the hello_world example:
[
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/loader/boot-c.o","file":".../cheriot-rtos/sdk/core/loader/boot.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DCHERIOT_AVOID_CAPRELOCS","-DDEBUG_LOADER=false","-DNDEBUG","-DCHERIOT_LOADER_STACK_SIZE=1024","-DCHERIOT_LOADER_TRUSTED_STACK_SIZE=192","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-O1","-fvisibility-inlines-hidden","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/loader/boot-c.o","-c","-x","c++",".../cheriot-rtos/sdk/core/loader/boot.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/loader/boot-s.o","file":".../cheriot-rtos/sdk/core/loader/boot.S","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DCHERIOT_AVOID_CAPRELOCS","-DDEBUG_LOADER=false","-DNDEBUG","-DCHERIOT_LOADER_STACK_SIZE=1024","-DCHERIOT_LOADER_TRUSTED_STACK_SIZE=192","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/loader/boot-s.o","-c","-x","assembler-with-cpp",".../cheriot-rtos/sdk/core/loader/boot.S"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/switcher/entry.o","file":".../cheriot-rtos/sdk/core/switcher/entry.S","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DCHERIOT_AVOID_CAPRELOCS","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/switcher/entry.o","-c","-x","assembler-with-cpp",".../cheriot-rtos/sdk/core/switcher/entry.S"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/freestanding/memcmp.o","file":".../cheriot-rtos/sdk/lib/freestanding/memcmp.c","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/freestanding/memcmp.o","-c","-x","c",".../cheriot-rtos/sdk/lib/freestanding/memcmp.c"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/locks/semaphore.o","file":".../cheriot-rtos/sdk/lib/locks/semaphore.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-fvisibility-inlines-hidden","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/locks/semaphore.o","-c","-x","c++",".../cheriot-rtos/sdk/lib/locks/semaphore.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/atomic1/atomic1.o","file":".../cheriot-rtos/sdk/lib/atomic/atomic1.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-fvisibility-inlines-hidden","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/atomic1/atomic1.o","-c","-x","c++",".../cheriot-rtos/sdk/lib/atomic/atomic1.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/freestanding/memcpy.o","file":".../cheriot-rtos/sdk/lib/freestanding/memcpy.c","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/freestanding/memcpy.o","-c","-x","c",".../cheriot-rtos/sdk/lib/freestanding/memcpy.c"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/atomic4/atomic4.o","file":".../cheriot-rtos/sdk/lib/atomic/atomic4.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-fvisibility-inlines-hidden","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/atomic4/atomic4.o","-c","-x","c++",".../cheriot-rtos/sdk/lib/atomic/atomic4.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/hello.o","file":".../cheriot-rtos/examples/01.hello_world/hello.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-cheri-compartment=hello","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/hello.o","-c","-x","c++",".../cheriot-rtos/examples/01.hello_world/hello.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/locks/locks.o","file":".../cheriot-rtos/sdk/lib/locks/locks.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-fvisibility-inlines-hidden","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/locks/locks.o","-c","-x","c++",".../cheriot-rtos/sdk/lib/locks/locks.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/freestanding/memset.o","file":".../cheriot-rtos/sdk/lib/freestanding/memset.c","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/freestanding/memset.o","-c","-x","c",".../cheriot-rtos/sdk/lib/freestanding/memset.c"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/allocator/main.o","file":".../cheriot-rtos/sdk/core/allocator/main.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DCHERIOT_AVOID_CAPRELOCS","-DDEBUG_ALLOCATOR=false","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-cheri-compartment=alloc","-fvisibility=hidden","-fvisibility-inlines-hidden","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/allocator/main.o","-c","-x","c++",".../cheriot-rtos/sdk/core/allocator/main.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/crt/cz.o","file":".../cheriot-rtos/sdk/lib/crt/cz.c","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DNDEBUG","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/lib/crt/cz.o","-c","-x","c",".../cheriot-rtos/sdk/lib/crt/cz.c"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/token_library/token_unseal.o","file":".../cheriot-rtos/sdk/core/token_library/token_unseal.S","arguments":["/cheriot-tools/bin/clang","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DCHERIOT_AVOID_CAPRELOCS","-DNDEBUG","-DDEBUG_TOKEN_LIBRARY=false","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-fvisibility=hidden","-std=c2x","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/token_library/token_unseal.o","-c","-x","assembler-with-cpp",".../cheriot-rtos/sdk/core/token_library/token_unseal.S"],"directory":".../cheriot-rtos/examples/01.hello_world"},
{"output":".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/scheduler/hello_world.main.o","file":".../cheriot-rtos/sdk/core/scheduler/main.cc","arguments":["/cheriot-tools/bin/clang++","-I.../cheriot-rtos/sdk/include/c++-config","-I.../cheriot-rtos/sdk/include/libc++","-I.../cheriot-rtos/sdk/include","-I.../cheriot-rtos/sdk/include/../include/platform/generic-riscv","-I.../cheriot-rtos/sdk/include/../include/platform/ibex","-DTEMPORAL_SAFETY","-DIBEX","-DIBEX_SAFE","-DCPU_TIMER_HZ=100000","-DTICK_RATE_HZ=10","-DREVOKABLE_MEMORY_START=0x20040000","-DCONFIG_MSHWM","-DCHERIOT_INTERRUPT_NAMES=RevokerInterrupt=1","-DSIMULATION","-DDEVICE_EXISTS_clint","-DDEVICE_EXISTS_plic","-DDEVICE_EXISTS_revoker","-DDEVICE_EXISTS_uart","-DDEVICE_EXISTS_shadow","-DCHERIOT_AVOID_CAPRELOCS","-DSCHEDULER_ACCOUNTING=false","-DDEBUG_SCHEDULER=false","-DCHERIOT_INTERRUPT_CONFIGURATION={1,2,false}","-DCONFIG_THREADS_NUM=1","-Qunused-arguments","-mcpu=cheriot","-mabi=cheriot","-mxcheri-rvc","-mrelax","-fshort-wchar","-fomit-frame-pointer","-fno-builtin","-fno-exceptions","-fno-asynchronous-unwind-tables","-fno-c++-static-destructors","-fno-rtti","-Oz","-g","-Werror","-cheri-compartment=sched","-std=c++2a","-target","riscv32-unknown-unknown","-nostdinc","-fdiagnostics-color","-finput-charset=UTF-8","-o",".../cheriot-rtos/examples/01.hello_world/cheriot-rtos/core/scheduler/hello_world.main.o","-c","-x","c++",".../cheriot-rtos/sdk/core/scheduler/main.cc"],"directory":".../cheriot-rtos/examples/01.hello_world"}
]

It is useful to have compile-commands for everything (it’s also useful to have entries for header files), because it helps cross referencing. Clangd will support jump-to-definition for various system features and having a compile commands entry for the target file means syntax highlighting works there as well (and, if that file is specialised based on board-specific things, having a per-project entry means that this shows up correctly).
We include a compile_flags.txt which is used when compile_commands.json is missing, but it’s helpful if the build system can generate a compile_commands.json entry for each header that’s used (ideally preferring a C++ target to a C one).
I’ve added some things I our build2 branch, I’ll try to merge your improvements into it.

it’s also useful to have entries for header files
it’s helpful if the build system can generate a compile_commands.json entry for each header that’s used (ideally preferring a C++ target to a C one).

Uh, I didn't know about having entries for headers in compile_commands.json but apparently it is a thing, though with unknown/poorly specified semantics. For once, headers are not compiled (unless we are talking about header units) so it's unclear where the corresponding command line comes from. There is a long (and still open) issue for this on CMake: https://gitlab.kitware.com/cmake/cmake/-/issues/16285
The good news is that we know the list of headers each project contains and can even accurately say whether foo.h is a C or C++ header (because of those h{} and hxx{} things). But it's unclear where the compilation command would come from. Maybe we could synthesize something plausible based on what options are visible from the header's scope...

I think header ‘compile’ lines just need to be the compile lines for a file that includes the header for clangd to be able to do the right thing, but I’m not 100% sure.
We try to make our headers all work as stand-alone compilation units (though clang doesn’t like #pragma once in the main file of a compilation unit) so our compile_flags.txt mostly works, but we can’t make that a requirement on every third-party header.


Not working in Chrome

I may be missing something dreadfully simple, but I can't seem to get this extension to work. I don't see others are having a problem. For example, the extension is supposed to allow for folders in the characters view, but it's not there. What am I doing wrong? I have a feeling I'm going to be embarrassed when you tell me lol ...

Lets check all this steps to try to find the problem:

The extention should be instaled from: chrome web store;
If go to the page chrome://extensions/ on chrome, Beyond Help (currently version v0.14.3) should be there and enabled;
When you go to the My Characters Page on D&D Beyond there should be a new button Create a Folder on the top right of the screen:

Did you find out the problem or still need assistance?

I figured out the NPC folders, thank you so much!
On Dec 27, 2018, 1:43 AM -0500, Edson Mesquita<EMAIL_ADDRESS>wrote:

Did you find out the problem or still need assistance?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

No problem!


docs: Use KEYVAULT_URL in quick start guide

Reason for Change:
Update doc to use KEYVAULT_URL, so as to support sovereign clouds
Please answer the following questions with yes/no:
Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?

[ ] yes
[x] no

Notes for Reviewers:
Follow-up #561

@karataliu could you also update the commit to say docs: Use KEYVAULT_URL in quick start guide as this a documentation update?

/azp run Azure Workload Identity CI


Doesn't work in Go 1.6

I try to compile with Go 1.6rc1.

Currently, we use a somewhat "hacky" solution for having PHP write back to the Go context. We do so by instantiating a context.Context, then passing and storing the unsafe.Pointer down in the C context. When PHP wants to e.g. write something back to the user, we call an exported Go function and pass the context pointer, which is then used for writing to the correct context.
Go 1.6 makes passing pointers between Go and C a bit more strict (as per this proposal).
The solution to this would be to store contexts in a lookup table, and pass keys instead of direct references down to the C context. I'll see if I can fix this before 1.6 is released.

Started fixing this in #19, there are some issues related to Receivers which need some thinking-through before fixing.

Fixed in #19.


Page View auto-tracking with pageTrackerTemplate send double views

Description
When configuring the lib to auto-track page views and use a custom template, the library sends the new page_title with query parameters but original page_title is sent through request payload.

Expected behavior
When pageTrackerTemplate is used, only the new page_title should be sent in the page_vew request.
Actual behavior
The new page_title is sent through the query parameters, and the old page_title is sent through request payload.
Reproducible Demo
Page title is the same on all pages. The initialisation of VueGtag library is done like this:
Vue.use(VueGtag, {
	config: {
		id: '...',
	},
	pageTrackerTemplate(to) {
		return {
			page_title: to.name,
			page_path: to.path
		};
	}
}, router);

I had the same problem, I fixed it by unchecking "Page changes based on browser history events" in the advanced settings of "Enhanced measurement" in your data stream.

Yup that solves it, thanks @kristofferdamborg  👍


Water Look improvements - above the surface

The current water surface rendering (from above - the underwater look will be dealt with separately) is working reasonably well. But a number of improvements could be brought to it relatively easily.
1st goal: light and depth factors
The color of a surface underwater (even when seen from above water) is affected by two factors:

how much water there is between the surface and the sun
how much water there is between the surface and the camera

More water between the surface and sun makes the surface darker (and even darker when the sun is low on the horizon). More water between the surface and the camera eventually fades the surface into the color of the water.
A first goal is therefore to expand the current lighting/color calculations in the shader to take into account these two factors.
2nd goal: arbitrary water tint
Right now the color of the water is hardcoded and unchangeable. Ideally we'd want it to be completely customizable, so that while normal water might be blue, water in a swamp (for example) might be more brown. This would also involve taking advantage of a per-biome water tint.
Bonus goal: while clear water allows for sharp details up to some distance, eventually surfaces seen through lots of water not only fade into the water color but also get blurred as in the Depth-of-Field effect. The challenge here is to use the code for the available DoF effect and take advantage of it for the underwater rendering.
3rd goal: switch from RGBA tint to 1d color ramp
Switch from a single RGBA water tint value to arbitrary 1d ramp textures would establish a more complex relationship between color and depth/color and water thickness. In the real world as depth increases colors are not all absorbed at the same rate: reds and yellows are the first to disappear, with greens and blues visible for longer as depth increases. Color ramps would increase realism for normal water (i.e. seas and rivers) and would create opportunities for more interesting effects in less realistic biomes.

Hey! For the goal#1, we know the water surface position (height), and the sun position (height) in the shader. To find the surface position (height), my first guess was that textureAtlasHeight stores the terrain height information, but it seems to be something else entirely, or I could not figure what it is.
Could you suggest what is the best way to get the surface height below the water?

Let me cut and paste something I wrote in irc:
the renderer first renders the scene -without- the water. And stores the results in the gbuffer. Which includes camera-space depth information.  In an entirely separate pass/node, it renders the water surface and puts it on top of the existing rendering.
So, the trick is to save somewhere (i.e. with a copy operation) the depth information of the rendering -without- the water, so that you can later reuse it. When you get to the water rendering you can then use that saved depth buffer to calculate, on a per-fragment basis, the distance between the water surface and any surface behind it. It's just a matter of subtracting one depth from the other.
At least that's the theory. :smile:

By the way, @cheekujodhpur: please send me an email address with a private message on our forum. I'll send you an invite for our slack-based chat rooms. It's quieter, more structured and more focused there than irc.
That been said, please let's continue discussing this topic primarily here.

Thanks.
I am sorry I am not convinced that is a very good idea. You would either end up passing too much information not needed, or you would end up doing too much processing figuring out which blocks have water above them.
From my perspective, expanding the rayTrace method in physics.BulletPhysics is a better idea because it will eventually give you an option to do real refraction, take account of volumetric scattering from a large water body, simulate caustics and probably more things.
What do you think? :smile:

Perhaps there is something you know that I don't know, because from my perspective the raytrace method you talk about is mostly happening CPU-side. So, assuming a standard HD monitor with 2 million pixels and a lake covering 1/5th of the view, you'd have to cast 400.000 rays, one for each pixel of the lake.
Is the raytrace method in bullet something you can somehow parallelize on the gpu? I.e. sending all the rays and the geometry at once and then getting a result altogether?
My suggestion addresses the issues I mentioned purely GPU-side and I do not see how it involves passing too much information. Can you clarify?
That been said, indeed right now I'm not thinking raytracing yet. If you wish to implement these features in raytracing I will be very curious to see how you do it without slowing rendering to a crawl.
Notice that I do think the hardware should be just at the right point where realtime raytracing is possible. But I'd start with doing raytraced shadows (and soft shadows if possible) before I get into more complex things such as water rendering.

Mmm, I was thinking of something simpler actually: to shoot only a few rays (perhaps one per surface block) to get an approximate depth map. This, I imagine would be cheap.
The problem I am speculating with your suggestion is that: you would be storing the "complete" scene rendered without the water/liquid blocks in a buffer right? Isn't that too much un-needed information, for some simple cases, for example, if I put just a single water block in front of me? Do I make sense, or have I misunderstood something?

Definitely it's not the whole scene to be stored in a buffer. Just the rendering. And it already includes the depth buffer, which is a 2d image effectively. You just need to make a copy of it because subsequent nodes will overwrite it, i.e. with the water surface.
And no, shooting a few rays would not provide results that are better or equal to what we have now, which is a requirement.

I did a little more tinkering.  I'm slowly trying to figure this out.
The depth buffer is bound to the texture texSceneOpaqueDepth. The frame buffer object named lastUpdatedgbuffer can be used to pass this texture into our fragment shader. When opaque blocks are rendered, they write to this. Now we reach the reflectiveRefractive Node. The required depth buffer should now be simply available via this texture in the fragment shader, because the depth buffer is written after the fragment shading. Hence, I do not see the over-writing that you mention happening "in theory".
Could you please clarify?
P.S. Also, the reflectiveRefractiveNode attaches the Depth Buffer to another frame buffer object called reflectiveRefractiveFbo, which is used in postProcessingNode, which means that the texture bound to lastUpdatedGBuffer is not even over-written by the water node.

To summarize something we discussed in slack, there could be a problem here due to an attempt to both read from AND write to the same depth attachment within the same rendering.
reflectiveRefractiveFbo is the buffer the reflectiveRefractiveNode intends to write to. But the node attaches the last updated gbuffer's depth attachment to it. Which means the depth attachment will also be written to. So, it can't be used as an input texture to sample data from.
The solution (probably) is to have a DuplicateDepthAttachmentNode that makes a copy of the last updated gbuffer's depth attachment before the rrNode attaches it to the rrFbo. This way the rrNode can use the copy as an input texture and write to the rrFbo as usual, including the recently attached depth attachment.
In this context the copy should provide you with the per-fragment distance between the camera and the underwater surfaces. Meanwhile, the rendering executed in the rrNode should provide the per-fragment distance from the camera to the water surface itself.


pplot should reflect initial values at x=0

pplot should reflect initial values at x=0

Moved to https://github.com/learningsimulator/learningsimulator/issues/117


Implement --version and --help flags

I wanted to make sure I was using the latest version of nv so I ran this:
# Current

$ nv --version
nv 2.1.0(2021-06-02) — context specific environment variables
Usage: nv <env files> <command> [arguments...]
$ echo $?
255

The error message (because --version is not a supported flag) output prints the version number by default but it would be nice to have a proper --version flag that would output the version number and then exit with a 0 status, eg.
# Suggestion

$ nv --version
nv 2.1.0(2021-06-02)
$ echo $?
0

Same thing for  --help :
# Current

$ nv --help
nv 2.1.0(2021-06-02) — context specific environment variables
Usage: nv <env files> <command> [arguments...]
$ echo $?
255

The usage is printed but again, as an error message. This would be nice:
# Suggestion

$ nv --help
Usage: nv <env files> <command> [arguments...]
$ echo $?
0

Cheers! ✌

Thanks for the suggestions.
I will look into it soon.


Add test case to verify #129

This is no longer relevant, because we don't have property "defaults" anymore. Instead we have "initial" properties that will always prefill app_data when a node is created


Add the possibility to parse number in scientific notation with E

As mention in #1 , we don't have the possibility to parse scientific notation with upper E. So this PR add this specificity.

Due to the code conflict, I've incorporate the changes directly in the code without merging the PR. Thanks


feat: Add style tags field for graphical theme.

Hey @zkat, great library.
We're in the process of migrating to miette from our own custom error handler and there's 1 feature we use heavily that miette does not support, and that's "style tags" within error messages. Here's an example of this:
#[error("Unable to unpack <path>{0}</path>, unsupported archive format <label>{1}</label>.")]
UnsupportedArchiveFormat(PathBuf, String),

It's basically HTML-like tags within the error message, that we replace with ANSI coloring/links/etc before rendering to the terminal. This is really nice as we can use these same tags in error messages, logs, and tracing, and all of them render in a similar fashion.
I originally approached this PR by supporting a "message formatting function", but because the graphical handler requires Clone + Debug, this wasn't easy to set and pass around. So instead I thought, why not just support the tags natively? As part of the theme perhaps? And that's what this PR does.
Here's an example of the terminal output when writing the test:

Another question I have:

Should the json/narratable handlers remove all tags? Or preserve them? If yes, I think this one will require using regex.

This is a cool idea! It definitely sounds nice to be able to have more formatting control over Graphical. That said, a change like this would be significantly breaking (for example, if a message renders actual xml/html as part of its message text).
I'm also not sure I feel comfortable messing with a field that sort of "belongs" to thiserror, if you know what I'm getting at. That particular error message is intended to work outside of any particular formatter.
In the end, I wonder if there's alternatives to this that might prove good enough, such as your end application deciding to apply these styles to its messages itself, since that's well within your purview and doesn't need to concern itself with what might conflict with a larger ecosystem.
I can imagine something like this working pretty well, Willy the need to deal with markup:
#[error("thing: {}, other: {}", .0.fg::<Red>, .1.underline())]
MyError(String, String)

What do you think?

Yeah that's fair, let me tinker around a bit with that approach.

It's a bit more verbose, but works.  https://github.com/moonrepo/starbase/pull/17
We'll go with that approach, thanks! I always forget that extra syntax exists for thiserror.


This website can't load the data set.

Hello.This website can't load the data set, but it was useful before. Could you share the data set? Thanks!
“https://openneuro.org/datasets/ds003821”

Hi @Applesuger,
Thanks for your interest in the project. I had to remove the dataset because of some de-identification issues. It will be available again soon (i.e. this week)

It should be available now

It should be available now (https://openneuro.org/datasets/ds003949)

Thank you for your attention to this matter


Develop

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

60 of 61 (98.36%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+3.0%) to 63.496%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pathways/templatetags/vite.py
40
41
97.56%

Totals

Change from base Build<PHONE_NUMBER>:
3.0%

Covered Lines:
494

Relevant Lines:
778

💛  - Coveralls


CoFH </3 Flaxbeard

COFH ore gen doesnt work with Flaxbeard installed

I need more information than that.

Eh...... I had custom ore gen with COFH.... Then I added Flaxbeard ( No config changes) ..... Ore gen didnt work in newly created worlds.... Removed Flaxbeard, ore gen works again....

What versions are you using? Did anything funny go on in the logs?

That isn't enough information, dude.

Version 0.28.1...... No funny thing in the logs ;/... Because there wasnt anything in the logs it took me awhile to find it....

@elifoster Ehh... Could you specify what info do you need? I wish I could provide a crash log... but it didnt crash... Do you want the server startup logs?

http://paste.ee/p/dOyKO     Theres the logs

I suppose a copy of your CoFH config, a copy of your FSP config, version numbers for everything involved. How does it not work?

COFH Config file
http://pastebin.com/8vqPpUs5
Flaxbeard config
http://pastebin.com/mdEnNHVf
Version of Flaxbeard 0.28.1
Version of CoFHCore-[1.7.10]3.0.0RC5-207

Just because there were some world gen changes since 0.28.1, I'd like you to test it with the latest 0.28.4. I doubt it'll do anything different, but it's worth a shot. How does it not work?

Fixed in 0.28.4 O_o

Probably has to do with:
world.provider.dimensionId = id;

to
if (id == world.provider.dimensionId)

from @c475856


How to customise plugin (Cratedb)?

Hello....any budy know How to to customise this plugin and any example of this...
Thanks In Advance !!!!....

Sorry but you'll have to provide more information than that in order for us to be able to help you.
I'm closing this for now.


yarn-berry: 4.3.1 -> 4.4.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for yarn-berry is: Fast, reliable, and secure dependency management
meta.homepage for yarn-berry is: https://yarnpkg.com/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.4.0 with grep in /nix/store/7za5b85csf425zwwdawnhgs2f4rm19f8-yarn-berry-4.4.0
found 4.4.0 in filename of file in /nix/store/7za5b85csf425zwwdawnhgs2f4rm19f8-yarn-berry-4.4.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

tilt
yarn-berry

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7za5b85csf425zwwdawnhgs2f4rm19f8-yarn-berry-4.4.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A yarn-berry https://github.com/r-ryantm/nixpkgs/archive/05ad3979d3a621a9cdff168dff8f1397909b04fc.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/05ad3979d3a621a9cdff168dff8f1397909b04fc#yarn-berry

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7za5b85csf425zwwdawnhgs2f4rm19f8-yarn-berry-4.4.0
ls -la /nix/store/7za5b85csf425zwwdawnhgs2f4rm19f8-yarn-berry-4.4.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

tilt
yarn-berry

Maintainer pings
cc @ryota-ka @pyrox0 @DimitarNestorov for testing.

All good! Tested with the following commands on aarch64-darwin:
cd /tmp
nix build github:r-ryantm/nixpkgs/05ad3979d3a621a9cdff168dff8f1397909b04fc#yarn-berry
mkdir test-package
cd test-package
../result/bin/yarn -v
../result/bin/yarn init
../result/bin/yarn add express
../result/bin/yarn node -p "require('express/package.json').version"


Propagate tag information throughout a trace lifetime

🐛 Bug
PR #1048 introduced Proxy object tagging. However, when a trace is manipulated the tag information is lost, how can we make sure that the tags are not discarded?
As of now there are many ways to create and manipulate traces, does it make sense here to start a simplification of the UX and declare a default way to create and manipulate a trace so we have more control over it and we can enforce this kind of constraints(keeping the same tag)?
Expected behavior
When setting a tag, that tag should always accompany its proxy even after transformations.
cc @apaz-cli

One possible solution is to not support constructing a trace using the interpreter + tracer pattern which is discussed in https://github.com/Lightning-AI/lightning-thunder/issues/1138.


Tutorial

http://early.witheve.com/tutorials/intro tutorial/tutorial.html
from http://www.chris-granger.com/ leads to a 404

@cmontella the link in the blog post is still leading to a 404: why are you closing this issue?

Mouvedia,
I did a bulk issue close because they're all moot at this point. The linked tutorial is for a version from last year, and it's gone from the main repo. But it exists in history if you want to see it here
https://github.com/witheve/Eve/tree/82ff0cfbf22ab5008d648de5fe6efa812b591e05/tutorials/intro tutorial

Then edit the blog post with that one.

Mouvedia,
The core issue is that the tutorial was hosted on GitHub pages, which only points to the latest master. Since the tutorial is out of date, it's not on the latest master. I've asked Chris to link to the tutorial in the repository, but we won't be hosting it.
Corey


test: scheduling: test CI behavior

Test CI because some platform build failure.
Signed-off-by: Ying ming<EMAIL_ADDRESS>

Close because it just a test!


After upgrading to rollup v0.46 this plugin causes rollup not exiting normally

When pressing Ctrl+C, rollup cannot stop automatically. After a few attempts it seems to be closed but actually it still has a background process running. Browsersync is still watching and serving and reloading the page. Hope you'll have it fixed, thanks!

Hi @ClassicOldSong,
It works for me. The module is already taking this into account (see this bit of code).
In order to be able to reproduce the issue, could you please let me know which version of node and which operating system are you running it from?
Thanks!

Screenfetch:

                 -/+:.          yukino@YukinoPrivate
                :++++.          OS: 64bit Mac OS X 10.13 17A405
               /+++/.           Kernel: x86_64 Darwin 17.0.0
       .:-::- .+/:-``.::-       Uptime: 1d 40m
    .:/++++++/::::/++++++/:`    Packages: 72
  .:///////////////////////:`   Shell: bash 3.2.57
  ////////////////////////`     Resolution: 2880x1800
 -+++++++++++++++++++++++`      DE: Aqua
 /++++++++++++++++++++++/       WM: Quartz Compositor
 /sssssssssssssssssssssss.      WM Theme: Blue
 :ssssssssssssssssssssssss-     Font: LiterationMonoPowerline 12
  osssssssssssssssssssssssso/`  CPU: Intel Core i7-6700HQ @ 2.60GHz
  `syyyyyyyyyyyyyyyyyyyyyyyy+`  GPU: Intel HD Graphics 530 / AMD Radeon Pro 450
   `ossssssssssssssssssssss/    RAM: 9170MiB / 16384MiB
     :ooooooooooooooooooo+.
      `:+oo+/:-..-:/+o+/-

❯ node -v
v8.7.0

Steps to reproduce:
git clone https://github.com/TheNeuronProject/ef.js.git
cd ef.js
git checkout dev
npm install
npm run dev

Wait a while and try ctrl+c.

Hi @ClassicOldSong,
I have fixed the problem and published a new version (0.2.5). Please reopen if you think it is not fixed.
Thanks!

Seems fixed, thanks!


linx-server: init at unstable-2021-12-24

Description of changes
Fixes #188667
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1471

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 202978 run on x86_64-linux 1

1 package failed to build and are new build failure:

linx-server: log was empty

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

linx-server:

warning: unclear-gpl
gpl3 is a deprecated license, please check if project uses gpl3Plus or gpl3Only and change meta.license accordingly.
Near pkgs/servers/web-apps/linx-server/default.nix:27:5:
   |
27 |     license = licenses.gpl3;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md

Tests fail due to nix store timestampts I would guess:
    server_test.go:499: File expiry is not<PHONE_NUMBER> but 0
--- FAIL: TestPostJSONUploadMaxExpiry (0.00s)

that was my thought too, but it breaks with go test in the shell too

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1483

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1518

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1541

ofborg is failing to build this packages and you posted it three times in the thread. Before posting it again please fix the build.
Disabling all tests is not great and if you don't know how to fix it we should skip this one.

ofborg is failing to build this packages and you posted it three times in the thread. Before posting it again please fix the build.

maybe I am looking at a different dashboard than you, but I see 17 successful checks and 4 neutral checks. can you point me to where you are seeing "ofborg is failing to build this packages"?
also, I am sorry for repeatedly posting this change in discourse, but I waited the requested week between each post. please let me know if I should be using that thread differently, but I was posting it there to get review feedback.

Disabling all tests is not great and if you don't know how to fix it we should skip this one.

as I indicated before, this appears to legitimately be a broken upstream test. is it our responsibility to fix bugs in upstream tools, or just faithfully package them as they are?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1571

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1605


ModuleNotFoundError: No module named 'py_ecc'

Followed all steps and have ubuntu 18.04 with
python3.7 --version
Python 3.7.8
pip3 --version
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.7)
git clone https://github.com/ethereum/eth2.0-deposit-cli.git
cd eth2.0-deposit-cli
pip3 install -r requirements.txt
python3.7 setup.py install
#all above worked without issues
python3.7 ./eth2deposit/deposit.py --num_validators 1 --chain medalla
Traceback (most recent call last):
File "./eth2deposit/deposit.py", line 5, in
from eth2deposit.credentials import (
File "/usr/local/lib/python3.7/dist-packages/eth2deposit-0.2.1-py3.7.egg/eth2deposit/credentials.py", line 5, in
from py_ecc.bls import G2ProofOfPossession as bls
ModuleNotFoundError: No module named 'py_ecc'

Closing to ask on the cli repo https://github.com/ethereum/eth2.0-deposit-cli/issues/78


Replace spaces with dashes in categories url

This PR is related to issue #105

@mauro-oto @etagwerker How can we ensure that all links is gonna work? Maybe add some redirect ? Is it possible with jekyll?

@cleicar I think you will need to add a plugin for that. Maybe this one: https://github.com/jekyll/jekyll-redirect-from

After evaluate this problem we came to conclusion that the best solution is not use space in category names. Therefore we can close this issue.
@etagwerker what do you think?

@cleicar Yes, I think that's a good idea. Thanks!


Opening a the .code-workspace of a (non wsl) remote-ssh destination from wsl will try to open the workspace in wsl

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.61.2
OS Version: 10.0.18363

Steps to Reproduce:

Open a (non wsl) remote-ssh workspace with vscode
Save workspace locally using "Save Workspace As..."
Quit VScode, open a wsl terminal
Navigate to the .code-workspace file saved earlier
Open with code workspace.code-workspace

VScode will then try to connect to WSL and fail to open the workspace, regardless of the fact that the workspace is remote.

Ok, I understand and agree it's a reasonable request.
Unfortunately, it's not easy to implement given the way we have layered the remote code.


Add buttons for 1D, 1W, and 1M price charts

Changes

Price charts have buttons for different timeframes
On the 1D timeframe, dates are replaced with time using the hh:mm format

So I've done a bit of investigating on the lag issues for the charts. It appears to me that regardless of whether you run the current master or my PR, the graph appears to be laggy. This makes sense since both the current version and my version make repeated calls to priceData.toDateString(), which is what you proposed I optimize. This lag goes away however when you create an optimized production build using yarn run build and serve -s build to run it. This is why the version running in prod looks smooth. I am still happy to attempt to memoize it, but as far as I can tell this will cause no performance gains compared to the current version (as the current version does not memoize it). Let me know how you want me to proceed, and I'll push the other changes.

Alright, I'll do a test deploy and get back to you

Deploy looks good 👍


docs/REFERENCE: Fix erroneous example

The host_name argument is actually called host.

Thank you for the correction!


[cxx-interop] pass the C++ language standard to Clang importer in Swi…

…ft when C++ interoperability is enabled (#6649)
Fixes https://github.com/apple/swift-package-manager/issues/6565
(cherry picked from commit cefff2b292828883fe2df768e8edfc6c520199f8)

Explanation:
When C++ interoperability is enabled, Swift can import Clang modules that have C++. C++ targets in SPM can use languages standards like C++20, which could be incompatible with the default C++ language standard used by Swift in the Clang importer. For that reason, if the C++ language standard is specified in the package manifest, SwiftPM should pass it when C++ interoperability is enabled to the Swift compiler.
Scope: Computing build settings for an SPM target.
Risk: Low. Only affects C++ interoperability enabled targets.
Testing: SwiftPM unit tests.
PR: https://github.com/apple/swift-package-manager/pull/6649

@swift-ci please test

@swift-ci please test windows platform

@swift-ci please test

@swift-ci please smoke test


Check resolution of tslib per file

This issue was raised by @andrewbranch during design meeting.
When the compiler option importHelpers is on, when we emit a module file, we will insert an appropriate import from tslib when an emit helper is needed.
To make sure this emitted import will be valid, during type checking, we try to resolve tslib whenever we detect we will need an emit helper, and error if we can't resolve it.
However, that resolution and respective error is currently not done per every file that will need the emit helper during emit, it is only done once per type checker and the resolution result is cached. This means that we could be missing errors in situations where for the first file we check tslib resolution, it resolves, but for a future file it would not resolve.
The newly added test case tslibNotFoundDifferentModules illustrates this: we have two packages in a project, one of them (package1) that has tslib in its node_modules/, and the other (package2) that doesn't. We first check the file in project1, and there we are able to resolve tslib, and so when we go and check the file in project2, we don't error saying tslib is missing, but we should.
This PR fixes this problem by making this tslib resolution check for every file an emit helper will be used.

@typescript-bot test it

@typescript-bot test it


Add new Dutch first and last names

The first name and last name counts are relatively small in nl.yml. Maybe, we can extend the number of names.
We can use the following data sets,
for first names:

https://github.com/MagicMau/DutchNameGenerator/blob/master/MarkovDutchNameGenerator/FirstNames.txt
https://github.com/hgrif/dutch-names/blob/master/app/static/names.json

for last names:

https://github.com/digitalheir/family-names-in-the-netherlands

@vbrazo just created a PR for that.

Awesome, thanks @hisener
Feel free to add more Dutch locations.


Crash after any search query

I've installed tuijam from AUR.
Authentication works but if I try to find any song, it crashes with a log just like that:
Traceback (most recent call last):
  File "/usr/bin/tuijam", line 1329, in main
    loop.run()
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 286, in run
    self._run()
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 384, in _run
    self.event_loop.run()
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 1005, in run
    reraise(*exc_info)
  File "/usr/lib/python3.7/site-packages/urwid/compat.py", line 58, in reraise
    raise value
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 1018, in wrapper
    return f(*args,**kargs)
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 938, in io_callback
    callback()
  File "/usr/lib/python3.7/site-packages/urwid/raw_display.py", line 404, in <lambda>
    event_loop, callback, self.get_available_raw_input())
  File "/usr/lib/python3.7/site-packages/urwid/raw_display.py", line 502, in parse_input
    callback(processed, processed_codes)
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 411, in _update
    self.process_input(keys)
  File "/usr/lib/python3.7/site-packages/urwid/main_loop.py", line 511, in process_input
    k = self._topmost_widget.keypress(self.screen_size, k)
  File "/usr/bin/tuijam", line 902, in keypress
    return self.focus.keypress(size, key)
  File "/usr/bin/tuijam", line 358, in keypress
    self.app.search(txt)
  File "/usr/bin/tuijam", line 985, in search
    ytvids = [YTVideo.from_dict(hit) for hit in self.youtube_search(query)[1]]
  File "/usr/bin/tuijam", line 956, in youtube_search
    from apiclient.discovery import build
ModuleNotFoundError: No module named 'apiclient'

log.txt

Thanks for reporting this. It looks like you don't have the google API python client installed. The AUR package (which I don't actually maintain) should include this as a dependency. In the mean time try installing python-google-api-python-client and see if it works for you.

I posted a comment for the AUR package so hopefully it gets updated soon. Did installing that package work for you?

Somehow I missed the AUR email (or it got buried, or never showed up, or whatever), but I caught up with GitHub notifications and saw the thread here.
I've pushed an update to the new 0.3.4 release and added the new dependency. Holler in the AUR (or tag/email/whatever me here on GitHub) if things are still wonky. Cheers!

Also @cfangmeier if you'd prefer to maintain the AUR package yourself, let me know and I'll happily turn it over. Back when I started using this there was no package so I became the de-facto maintainer there I guess and didn't realize anyone else was actually using the PKGBUILD until recently!
Either way's fine by me. I've turned on notifications for this repo in GitHub so I should see updates more frequently either way.

@klardotsh Thanks for setting up the AUR package! I'll add a note to the readme that points to it. The current maintenance situation works for me. I expect that in the future there won't be a high frequency of releases anyway since TUIJam is, to me at least, feature complete.
In any case, I guess this issue is resolved so I'll close it here.


Add BERTopic intergration information to docs

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

cc @MaartenGr I suggest we wait with merging this until you are ready to make a release for BERTopic with this integration.
@osanseviero I think I've added everything for this part. At the moment, I've indicated the widgets/ API doesn't work. I would suggest updating that once the PR in https://github.com/huggingface/api-inference-community/pull/276 is merged (which would also rely on a new release of BERTopic with the integration.

@osanseviero think this is ready to be merged :)


View registration button doesn't work on mobile

We were not able to repro this issue.
Let us know if issue is not resolved yet.


[NEW ICON] SwiftUI

Skill Name
SwiftUI
Why?
SwiftUI has become a popular framework for building user interfaces across all Apple platforms, and having a dedicated icon for it would be beneficial for developers using this framework.
Usage: This icon will help developers easily identify SwiftUI-related components in their projects and documentation.
Community Impact: Adding this icon would enhance the repository's usability and make it more comprehensive for users working with SwiftUI.
Reference Image

The issue is hereby closed as a PR has be created, waiting to be merged.