Cannot build profiler on windows 10

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): source
TensorFlow version: 1.12.0
Python version: 3.6
Installed using virtualenv? pip? conda?:
Bazel version (if compiling from source): 1.16.1
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: 9.0, 7.3.1
GPU model and memory: NVidia GTX 1080

Describe the problem
I get an error while trying to build the profiler from source.
Provide the exact sequence of commands / steps that you executed before running into the problem
C:\Users\vignesh\Documents\tensorflow-1.12.0>bazel build --config=opt tensorflow/core/profiler:profiler
INFO: Build options have changed, discarding analysis cache.
INFO: Analysed target //tensorflow/core/profiler:profiler (0 packages loaded).
INFO: Found 1 target...
INFO: From Compiling external/com_google_absl/absl/base/internal/throw_delegate.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/base/internal/spinlock_wait.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/types/optional.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/internal/memutil.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/internal/charconv_parse.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/internal/charconv_bigint.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/str_replace.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/substitute.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/ascii.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/string_view.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/match.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/charconv.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/numbers.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
INFO: From Compiling external/com_google_absl/absl/strings/str_split.cc:
cl : Command line warning D9025 : overriding '/w' with '/W3'
ERROR: C:/users/vignesh/_bazel_vignesh/g2rooyha/external/linenoise/BUILD.bazel:9:1: C++ compilation of rule '@linenoise//:linenoise' failed (Exit 2): msvc_wrapper_for_nvcc.bat failed: error executing command
cd C:/users/vignesh/_bazel_vignesh/g2rooyha/execroot/org_tensorflow
SET CUDA_TOOLKIT_PATH=C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.0
SET CUDNN_INSTALL_PATH=C:/tools/cuda
SET INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;
SET LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64;
SET PATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64;C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319;C:\WINDOWS\Microsoft.NET\Framework64;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;;C:\WINDOWS\system32
SET PWD=/proc/self/cwd
SET PYTHON_BIN_PATH=C:/Users/vignesh/AppData/Local/Programs/Python/Python36/python.exe
SET PYTHON_LIB_PATH=C:/Users/vignesh/AppData/Local/Programs/Python/Python36/lib/site-packages
SET TEMP=C:\Users\vignesh\AppData\Local\Temp
SET TF_CUDA_CLANG=0
SET TF_CUDA_COMPUTE_CAPABILITIES=6.1
SET TF_CUDA_VERSION=9.0
SET TF_CUDNN_VERSION=7
SET TF_NEED_CUDA=1
SET TF_NEED_OPENCL_SYCL=0
SET TF_NEED_ROCM=0
SET TMP=C:\Users\vignesh\AppData\Local\Temp
external/local_config_cuda/crosstool/windows/msvc_wrapper_for_nvcc.bat /nologo /DCOMPILER_MSVC /DNOMINMAX /D_WIN32_WINNT=0x0600 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_NO_WARNINGS /D_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS /bigobj /Zm500 /J /Gy /GF /EHsc /wd4351 /wd4291 /wd4250 /wd4996 /Iexternal/linenoise /Ibazel-out/x64_windows-opt/genfiles/external/linenoise /Ibazel-out/x64_windows-opt/bin/external/linenoise /Iexternal/bazel_tools /Ibazel-out/x64_windows-opt/genfiles/external/bazel_tools /Ibazel-out/x64_windows-opt/bin/external/bazel_tools /showIncludes /MD /O2 /DNDEBUG -w /arch:AVX /Fobazel-out/x64_windows-opt/bin/external/linenoise/_objs/linenoise/linenoise.o /c external/linenoise/linenoise.c
external/linenoise/linenoise.c(106): fatal error C1083: Cannot open include file: 'termios.h': No such file or directory
Target //tensorflow/core/profiler:profiler failed to build
INFO: Elapsed time: 19.622s, Critical Path: 11.13s
INFO: 138 processes: 138 local.
FAILED: Build did NOT complete successfully

@vigbk  Just to make sure, did you get a chance to go through this ?  If not, request you to follow and post blockers(if any)

@harshini-gadige. I did go through that. I was trying to build the bazel binary when I got the error I posted.

@hgadig please redirect the issue to the owners of profiler. From the error, it looks to me like the code is not fully compatible with windows.

Unassigned to trigger retriage.


Add log rotation to the daemon server

Description
This PR expands our tracing setup to allow the daemon to opt-in to rotated log files on top of the regular stdout logging. This output is non-blocking and uses the standard tracing format, respecting the env vars set by the command that runs the daemon.
Testing Instructions
Run turbo daemon with TURBO_LOG_VERBOSITY set to trace, and open the path it prints for the log file to see that the logs are also being output there.

This is in my queue to review, but I think it needs to merge main in, the diff looks like it includes the daemon implementation as well?


Use scan selection for mobility scans in ScanAccess

Mobility filter was not applied. Together with @SteffenHeu

Did you push the latest changes? The test is failing


correction bootstrap datetime field, issue #1186

correction to issue #1186
config.wrappers :horizontal_select_date, tag: 'div', class: 'form-group', error_class: 'has-error' do |b|
    b.use :html5
    b.optional :readonly
    b.use :label, class: 'control-label'
    b.wrapper tag: 'div', class: 'form-inline' do |ba|
      ba.use :input, class: 'form-control'
      ba.use :error, wrap_with: { tag: 'span', class: 'help-block' }
      ba.use :hint,  wrap_with: { tag: 'p', class: 'help-block' }
    end
  end

in html
<%= f.input :date, wrapper: :horizontal_select_date %>

I've just noticed you can add this to your config.wrapper_mappings so that it becomes the default for datetime.
config.wrapper_mappings = {
  datetime: :horizontal_select_date
}

perfect! thanks! @sparksp

perfect! @sparksp

I have tested here and looks nice. Thank you for your contribution.
I have opened this PR https://github.com/plataformatec/simple_form/pull/1236 to apply this fix for date and time also.


appBar customisation

I don't know if this is the right place to post this, but I love your plugin and I'm wondering if it's possible to implement more customisation for the appbar. Now it's possible to set the appbar color etc. but this is for all the appbars. Would it be possible to set a different color for every 'screen'? Or would it else be possible to open/close the menu from a standard scaffold appbar?

In version 1.0 this is possible using SimpleHiddenDrawer or AnimatedDrawerContent

I also don't know if it's the right place, didn't want to open another issue on this.
I like this menu very much, but I also want to have more control over the AppBar's layout.
I wish to center out the title, like it's possible with the 'centerTitle' attribute of AppBar.


add alias String for Tag

some forums's bbcode doesn't always align.
example like:

spoiler -> mask
s -> del
...

it is not very convenient to customAgain just replace these text.
is it possible to add alias in the tag prop?
by the way the package it's very useful for me.

I don't think aliases would be a good solution to solve the problem. Rather I think making the stylesheet tags able to take a non-default parameter that can be changed. That way you can just add your own tags with the existing functionality.


Extra 0 not working with neated inlines.

Extra 0 not working in following example
from django.contrib import admin
from nested_inline.admin import NestedStackedInline, NestedModelAdmin
from example.models import *

class LevelTwoInline(NestedStackedInline):
    model = LevelTwo
    extra = 0

class LevelOneInline(NestedStackedInline):
    model = LevelOne
    extra = 0
    inlines = [LevelTwoInline]

class TopLevelAdmin(NestedModelAdmin):
    model = TopLevel
    inlines = [LevelOneInline]

admin.site.register(TopLevel, TopLevelAdmin)

Please give me any solution.

I have similar problem :(

+1

working on a fix for this....

https://github.com/s-block/django-nested-inline/pull/101

on further reflection - it appears that the fix proffered works only with add form.  Not edit form.


Question about 1.20.4

Is an update to 1.20.4 planned? Sorry to ask about that.

Same question, update please!

For further context, similar to #121, i tried to place 1.10.2 for MC 1.20.2 on my 1.20.4 profile, surprisingly the game boots on, config is created, but unfortunately when entering a world and trying to spawn a E2J mob crashes the game with this report HERE.
I suspect its a minor mixin correction, but maybe i'm wrong.


Cow: Watch kccscientific.com

Cow requests the watch of the watch_keyword kccscientific\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Spevacus in Charcoal HQ


ignoreLabels is removing labels

I'm experiencing a strange behavior from the bot, as shown in the screenshot below.

My config looks like below (emoji is removed for clarity), the goal is to have the bot to check if the title is prefixed with a ticket number, add a No Ticket label if not. But do not perform the check if the No Ticket label is already present. It looks like the line 10052 https://github.com/bcchenbc/pr-title-checker/blob/main/dist/index.js#L10052 is removing label, which I guess is not intended. Would you mind taking a look? Thank you!
  "LABEL": {
    "name": "No Ticket",
  ...
  "CHECKS": {
    "ignoreLabels" : ["No Ticket"],

(I created a PR https://github.com/thehanimo/pr-title-checker/pull/39 to remove the line, but it's showing me 8,814 additions, 8,815 deletions not shown because the diff is too large. Please use a local Git client to view these changes., so I'm creating this issue guessing that you might have better way to fix it 😅 )

Your changes are in dist/, which is the build output of index.ts. All changes have to be made in the source file, which is index.ts.
For the problem itself, I think the tool works as intended. In your case, I'm assuming the title has a ticket number but you manually want to add a "No Ticket" label to it? I'm not sure if that is the use case here but I'm sure that the tool does not (and possible cannot) support it. It takes away the base logic of "if not formatted, add label; if formatted, remove label".
Does that make sense?

If you do want it to work, you could define a new label such as "verified" or "lint-disable" and add this to ignoreLabels instead.

Thank you for prompt reply! & for clarification (re: index.ts, I'll make a change to this line https://github.com/thehanimo/pr-title-checker/blob/main/index.ts#L285 when available)!
The PR I created did not have a ticket number, and I didn't modify the title during the process. I was hoping that the bot would add the No Ticket label, and keep it there. Would you mind checking if my experience was expected? What happened was something like:

(the 10 mins ago line) I created the PR (the bot added No Ticket as expected).
(the 6 mins line from me) I added other two labels,
(the 6 mins line from bot) the bot got triggered again, but removed the No Ticket label (which is unexpected).
(the 5 mins line from me) I tried to added back the No Ticket label, but
(the 5th line from bot) the bot got triggered again and removed the label.

I guess I'm a bit confused about how to interpret ignoreLabels. I was expecting that if the bot sees a ignoring label, it'll do nothing. If the title is not formatted, it'll add the label at the first execution (when PR was created). But it'd do nothing in following executions (for example, when modifying other labels), since the ignoring label is there. It'll be really nice if I can still with one label, so... really hope that it could work 😄

You are almost correct. ignoreLabels does mean it'll do nothing, but also reverts previous actions, i.e., remove tag if it was previously added.
What is unexpected in your flow (likely a bug somewhere) is step 3. If the title was the same in step 1 and 3, the bot should behave in the same way by adding the No Ticket tag. Are you sure there was no change in the title?

Oh right. It does work as intended. It "undid" its previous action of adding the tag (which in your case coincides with the one to be ignored)

Ah, reverts previous actions tripped me 😅 Thank you for clarification!
(Just confirmed, I did not change the title, btw.)

Removing ignoreLabels (setting it to []) works just fine for me. Thank you!


static_assert error on build

When I try to build I get the following error running on a rpi3b+:
echo "#define GIT_VERSION \"Commit: dadf5e6\"" > include/git_version.h-new; \
cmp -s include/git_version.h include/git_version.h-new || cp include/git_version.h-new include/git_version.h; \
rm include/git_version.h-new
clang -I include -I include/bcm283x -I /opt/vc/include -MMD  -Wall -Wno-missing-braces -c source/mailbox.c -o build/source/mailbox.c.o
source/mailbox.c:113:10: warning: cast to 'void *' from smaller integer type 'uint32_t' (aka 'unsigned int') [-Wint-to-void-pointer-cast]
  return (void*)response->tag.bus_address;
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
clang -I include -I include/bcm283x -I /opt/vc/include -MMD  -Wall -Wno-missing-braces -c source/log.c -o build/source/log.c.o
clang -I include -I include/bcm283x -I /opt/vc/include -MMD  -Wall -Wno-missing-braces -c source/spdif.c -o build/source/spdif.c.o
clang -I include -I include/bcm283x -I /opt/vc/include -MMD  -Wall -Wno-missing-braces -c source/memory.c -o build/source/memory.c.o
source/memory.c:105:53: warning: cast to smaller integer type 'uint32_t' (aka 'unsigned int') from 'void *' [-Wvoid-pointer-to-int-cast]
  return (void*)((uint32_t)entry.pfn * pageSize) + ((uint32_t) virtual % pageSize);
                                                    ^~~~~~~~~~~~~~~~~~
1 warning generated.
clang -I include -I include/bcm283x -I /opt/vc/include -MMD  -Wall -Wno-missing-braces -c source/main.c -o build/source/main.c.o
In file included from source/main.c:11:
In file included from include/bcm283x/bcm283x.h:24:
include/bcm283x/bcm283x_dma.h:221:1: error: static_assert failed due to requirement 'sizeof(struct dma_control_block_t) == 8 * sizeof(unsigned int)' "dma_control_block_t must be 32 bytes."
static_assert(sizeof(dma_control_block_t) == 8 * sizeof(uint32_t), "dma_control_block_t must be 32 bytes.");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/assert.h:143:24: note: expanded from macro 'static_assert'
# define static_assert _Static_assert
                       ^
In file included from source/main.c:11:
In file included from include/bcm283x/bcm283x.h:24:
include/bcm283x/bcm283x_dma.h:223:1: error: static_assert failed due to requirement 'sizeof(struct bcm283x_dma_channel_t) == 9 * sizeof(unsigned int)' "bcm283x_dma_channel_t must be 36 bytes."
static_assert(sizeof(bcm283x_dma_channel_t) == 9 * sizeof(uint32_t), "bcm283x_dma_channel_t must be 36 bytes.");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/assert.h:143:24: note: expanded from macro 'static_assert'
# define static_assert _Static_assert
                       ^
2 errors generated.
make: *** [Makefile:31: build/source/main.c.o] Error 1

Interesting. I'm guessing based on the other warnings you are running a 64-bit OS, and that's throwing off the size of the pointers in the DMA structures.
Can you provide the outputs of the following commands?
clang --version, lsb_release -a, uname -a

I'm running on Docker.
root@e766abdc2321:~# clang --version Ubuntu clang version 14.0.0-1ubuntu1 Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin
root@e766abdc2321:~# lsb_release -a LSB Version:    core-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch Distributor ID: Ubuntu Description:    Ubuntu 22.04.2 LTS Release:        22.04 Codename:       jammy
root@e766abdc2321:~# uname -a Linux e766abdc2321 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 aarch64 aarch64 GNU/Linux

| Linux e766abdc2321 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 aarch64 aarch64 GNU/Linux
Yep, that's a 64 bit architecture. For now, that's not supported. I'd have to think about the intricacies of supporting it. e.g. the DMA peripheral still expects 32 bit addresses, but the OS is accessing the same memory via 64 bit addresses.
As for Docker. I'd be surprised if it's possible, but glad to see you try. raspdif has to access some low-level hardware which I don't know how it will interact with Docker's isolation.
Some thoughts to consider:

You'll need to bind mount /dev/mem and /dev/vcio into the container.
raspdif uses some Raspberry Pi specific functions from bcm_host. These might not be available in an Ubuntu base image.

I have a branch for 64 bit support here. It's working on my RPi3.
I'm more or less blindly casting things to 32 bit as needed. Quite possible it might fail on HW with more than 4 GB of mem.

Closed via #22


[Bug] Images with spaces in filename are incorrectly parsed

Cloudinary delivers spaces in image names like this:
https://res.cloudinary.com/myaccount/image/upload/vnumber/foo bar.png
Where the %20 is the space. And when I use this url in the CldImage component, it breaks the url:
https://res.cloudinary.com/myaccount/image/upload/c_limit,w_70/f_webp/q_auto/vnumber/foo%2520bar
It transforms %20 to %2520 which breaks the url and is not found by cloudinary

hey @lhguerra what version are you on? I fixed a similar issue, i'm wondering if perhaps a simple upgrade might fix this 🤞
https://github.com/colbyfayock/next-cloudinary/issues/219
https://github.com/colbyfayock/next-cloudinary/pull/232

I'm using the latest version 4.15.0

hey @lhguerra sorry about that - in the package the constructs the URLs, the fix wasn't pulled in from one of its dependencies due to a bit of an inconsistent deployment setup that I need to separately figure out.
it should now be working on the latest, added a test to validate, but pleasel et me know if you still notice issues

Worked like a charm! Thanks again for the fast update!


The "initializer > initContainers"  doesn't work. The "initializer" pod uses the "runner > initContainers" definition

Brief summary
I have a K6 yaml with the "initializer > initContainers" and "runner > initContainers":
initializer:     initContainers:       - name: test-init-01-clone         image: busybox:1.28         command: ['sh', '-c', 'echo "InitiContainer Waiting for task...."; sleep 10; echo "Task is done!!!"'] .../...   runner:     initContainers:       - name: test-runner-01         image: busybox:1.28          command: ['sh', '-c', 'echo "Waiting for task...."; sleep 10; echo "Task is done!!!"']
But, the "k6-loadtest-01-initializer-" pod shows the "test-runner-01" init-container.
I'm confused, I thought that the initializer pod would use the initializer and the runner pods the "runner > initContainer".
I want to clone a git repo at the begins of the initializer pod, this repo contains the Load Tests scripts and libraries and leaves the files on the volumepersistentclaim (PVC).
k6-operator version or image
ghcr.io/grafana/k6-operator:controller-v0.0.11rc1
K6 YAML
apiVersion: k6.io/v1alpha1
kind: K6
metadata:
name: k6-loadtest-01
namespace: k6-operator-system
labels:
app: k6-sso-loadtest-01
spec:
initializer:
initContainers:
- name: test-init-01-clone
image: busybox:1.28
command: ['sh', '-c', 'echo "InitiContainer Waiting for task...."; sleep 10; echo "Task is done!!!"']
volumes:
- name: clone-repo
gitRepo:
directory: /test/project
repositoy: https://anexamplepapthofgitlab.org/k6-loadtest.git
revision: main
volumeMounts:
- name: clone-repo
mountPath: /test
readOnly: false
parallelism: 1
script:
volumeClaim:
name: k6-projects-pvc
file:  project/loadtest/10-test.js
runner:
initContainers:
- name: test-runner-01
image: busybox:1.28
command: ['sh', '-c', 'echo "Waiting for task...."; sleep 10; echo "Task is done!!!"']
Other environment details (if applicable)
No response
Steps to reproduce the problem
1/ Login in OpenShift/KUbernetes cluster
2/ Execute: oc apply -f k6-test-load.yaml
3/ go to the k6-operator-system namespace
4/ The k6-loadtest-01-intializer- pod has the init containers: "test-runner-01", defined in the "runner > initContainers" section.
Expected behaviour
The k6-loadtest-01-initializer should have the init container "test-init-01-clone", defined in the "initializer > initContainers" section.
Actual behaviour
The k6-loadtest-01-intializer- pod has the init containers: "test-runner-01", defined in the "runner > initContainers" section.

Hi @nveces, thanks for opening the issue! Yes, this is expected right now: init containers are not supposed to be defined additionally for initializer. I.e. initializer uses the init containers from runner and that's it. You can pass them to initializer spec only because that's how Pod is defined in Kubernetes (k6-operator cannot easily forbid such usage).
IIRC, there were discussions whether one would ever even need a separate init container there; I see now that was a misconception :joy:
This should be a pretty small change, in case someone would like to work on it.


Documentation doesn't build on RTD for core functionality

Getting the following errors for building documentation.
WARNING: autodoc: failed to import module u'core' from module u'scaper'; the following exception was raised:
No module named soundfile
WARNING: autodoc: failed to import module u'core.Scaper' from module u'scaper'; the following exception was raised:
No module named soundfile

WARNING: autodoc: failed to import module u'core' from module u'scaper'; the following exception was raised:
No module named soundfile
WARNING: autodoc: failed to import module u'core.Scaper' from module u'scaper'; the following exception was raised:
No module named soundfile
/home/docs/checkouts/readthedocs.org/user_builds/scaper/checkouts/stable/docs/tutorial.rst:343: WARNING: Error in "code-block" directive:
1 argument(s) required, 0 supplied.

Self-assigning and will PR with a fix.

Fixed via #81


tfa.image.sharpness does not expose in init.py

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): colab
TensorFlow version and how it was installed (source or binary): binary
TensorFlow-Addons version and how it was installed (source or binary): nightly
Python version: 3.6
Is GPU used? (yes/no): no

Describe the bug
should expose sharpness under __init__.py.
Code to reproduce the issue
https://colab.research.google.com/drive/1jSa4B06CopeVfgExeSoO6roPR5eTdSYn?usp=sharing

closed via #1827


How to create dynamic variants with the nested schemas?

Hello!
Here is the playground MRE: https://valibot.dev/playground/?code=JYWwDg9gTgLgBAKjgQwM5wG5wGZQiOAcg2QBtgAjCGQgbgCh6BjCAO1XgCUBTVAV1IwAykwAW3EMjgBeTADoIFAFbcmMABQBvenDgBrbgE8AXPI5RgrAObqAlABp6AX1sNmbDnCExkMYEwA1ZAtkVmExCSlZDDkSELD1Qn4mJl5UQns4AG0deUUVNS1c3WTU1FRTGPIYbigydWwyVG4HYrhavChKuUsOUNT1AFEoTtbdF0ddGPzVDW1dEr4UtO7q2vqYKD4WyYWoXgEYUx5+QRFxSV2J+gBdV0YWdngAEUNWZBB-IPjwi6i4AA8ABV2gAPGqsAAm6BiAHllLNzpEAaFDJlUQA+DHqXL7U6-SKmIGOWwyDG5GJxYChDRJJZldKZHILPIIwrzFlwUoreRrOqkBpNHZtXQdaDdXo+VgDYajXbjMYLaZsuYirn0nlVYA1fnqTbbRUsvGHUzGs4RS5ta66O4MIA
Inline code:
import * as v from 'valibot';

const ResultSchema = v.object({
  key: v.string(),
});

const StaticVariantSchema = v.variant('success', [
  v.object({
    success: v.literal(false),
    error: v.instance(Error),
  }),
  v.object({
    success: v.literal(true),
    result: ResultSchema,
  }),
]);

const DynamicVariantSchema = <T extends v.ObjectSchema<any, any>>(
  resultSchema: T,
) =>
  v.variant('success', [
    v.object({
      success: v.literal(false),
      error: v.instance(Error),
    }),
    // here i'm getting error
    v.object({
      success: v.literal(true),
      result: resultSchema,
    }),
  ]);

const staticResult = v.parse(StaticVariantSchema, {
  success: true,
  result: {
    key: 'string',
  },
});

const dynamicResult = v.parse(DynamicVariantSchema(ResultSchema), {
  success: true,
  result: {
    key: 'string',
  },
});

console.log(staticResult, dynamicResult);

At runtime, it's working OK, but I got an error from TS:
Type 'ObjectSchema<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, undefined>' is not assignable to type 'VariantOption<"success">'.
  Type 'ObjectSchema<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, undefined>' is not assignable to type 'ObjectSchema<Record<"success", BaseSchema<unknown, unknown, BaseIssue<unknown>>>, ErrorMessage<ObjectIssue> | undefined>'.
    The types returned by '_run(...)' are incompatible between these types.
      Type 'Dataset<{ [TKey in keyof WithReadonly<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, WithQuestionMarks<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, InferEntriesOutput<...>>>]: WithReadonly<...>[TKey]; }, ObjectIssue | InferObjectIssue<...>>' is not assignable to type 'Dataset<{ success: unknown; }, BaseIssue<unknown> | ObjectIssue>'.
        Type 'TypedDataset<{ [TKey in keyof WithReadonly<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, WithQuestionMarks<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, InferEntriesOutput<...>>>]: WithReadonly<...>[TKey]; }, ObjectIssue | InferObjectIssue<...>>' is not assignable to type 'Dataset<{ success: unknown; }, BaseIssue<unknown> | ObjectIssue>'.
          Type 'TypedDataset<{ [TKey in keyof WithReadonly<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, WithQuestionMarks<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, InferEntriesOutput<...>>>]: WithReadonly<...>[TKey]; }, ObjectIssue | InferObjectIssue<...>>' is not assignable to type 'TypedDataset<{ success: unknown; }, BaseIssue<unknown> | ObjectIssue>'.
            Property 'success' is missing in type '{ [TKey in keyof WithReadonly<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, WithQuestionMarks<{ readonly success: LiteralSchema<true, undefined>; readonly result: S; }, InferEntriesOutput<...>>>]: WithReadonly<...>[TKey]; }' but required in type '{ success: unknown; }'.ts(2322)

Am I doing something wrong with the generics, or is it a bug?

This works if you don't care about the exact output type.


Better handling of holes in area charts

Currently it looks like this

Would it be possible to:

draw an area under each slice ?
Make sure the side borders are vertical (instead of closing on the first point) ?

Hi there. There is already a PR that tries to fix this #336 but it's currently incomplete and won't fix all edge cases. I'll take a look at this.


Batch-apply remove actions in tombstone handling

Improve tombstone handling by only applying the remove actions as a
batch at the end of a load or incremental update operation.
For checkpoint loading, we entirely skip interpretation of the remove
actions because according to the delta spec, a remove must be in a later
revision than the associated add, so they wouldn't be both in the same
checkpoint.
The PR does not add any new tests, as we are only changing implementation details. I think the proper handling of tombstones is demonstrated by read_simple_table() as it makes sure that tombstones are applied properly when loading a table with remove operations.

My initial idea was to capture the changes from an update operation in a struct DeltaChangeSet, but then this struct had exactly the same fields as DeltaTableState, because all these fields can be modified by actions. I then dropped that class, which has the nice advantage that all code paths stay the same, with the exception of apply_log_from_bufread(), which happens to be the only place that requires the alignment of add and remove actions.

So I am thinking of something like this:
struct DeltaBatchChangeSet {
    remove_set: HashSet<&str>,
}

fn process_action(state, batch_change, action) {
    match action {
        ...
        Action::remove(v) => {
            state.tombstones.push(v);
            batch_change.remove_set.add(v.path.as_ref());
        }
        ...
    }
}

fn apply_logs_in_batch(
    state: &mut DeltaTableState,
    actions: impl IntoIterator<Item = Result<Action, ApplyLogError>>,
) -> Result<(), ApplyLogError> {
   let mut batch_change = DeltaBatchChangeSet::new();
   for action in actions.into() {
       process_action(&mut state, &mut batch_change, action?)?;
   }
   if !batch_change.remove_set.is_empty() {
        state.files
                .retain(|a| !batch_change.remove_set.contains(a.path.as_str()));
   }
   Ok(())
}

The only disadvantage I can see here is that retain is called on a larger set, because even the add actions from the current update are considered as remove candidates. On the other hand, this potentially handles moving forward multiple versions at once (calling retain ony once).

This way, we won't need to check and reassign for other fields in the merge method. We also won't need to go through the tombstone for a 2nd time to build the hashset.

Thanks for the great idea! The one thing I didn't like about the approach I've taken is indeed that I'm forced to handle all fields, even though only one of them is actually relevant for the merge operation.

What do you think?

I'll give it a go this evening. Thanks for the suggestion.

In that idea, we pass batch_change into process_action, irrespective of it being necessary. I wonder if we should pass in an Option<DeltaBatchChangeSet> instead so we don't have to build a potentially large hash set for checkpoint loading.

The only disadvantage I can see here is that retain is called on a larger set, because even the add actions from the current update are considered as remove candidates. On the other hand, this potentially handles moving forward multiple versions at once (calling retain ony once).

This is a good point, I think this optimization is relevant for applying actions from checkpoints. For incremental updates, I think we do still need to consider add actions from the current batch.
Another observation is even though we have to go through the newly added files in the retain call, we avoided the self.files.append(&mut new_state.files); call, so the number of times we need to iterate through the newly added batch is the same?

I'm a bit torn here. While your propsal reduces the code size and removes unnecessary handling of unrelated fields in the  change set, making it very clear that (and why) we handle tombstones separately, the initial PR has the advantage that process_action just "collects some actions", and introduces the notion of merging. The latter allows for a trivial way to do the checkpoint ingestion concurrently (on a per-file granularity), which would have been one of the next things planned to raise an issue for ;).

The latter allows for a trivial way to do the checkpoint ingestion concurrently (on a per-file granularity), which would have been one of the next things planned to raise an issue for ;).

Yeah, this is a good point. We should definitely design for concurrent apply. So looks like state merge code is unavoidable. In this case, the BatchChangeSet design becomes an optimization details. In other words, we can use it together with state merge later if going through tombstone the 2nd time to build the hashset becomes a performance issue.
In short, :+1: for the current approach :)

The beginning of exciting optimizations :) Thanks @dispanser .


Fix default connectionPool

(sorry for the weird bot comment; I deleted it. We're having some issues with our merge tool)

Silly Jarvis.  :)
@mdzor Thanks, will get this merged soon!


Separate element business logic from presentation

Add element registries with their editors:

element option;
element.

@asimonok Are we still looking to do it?


Adding ability to override number of radial bases

Quick implementation of what @arthur-lin1027 and I discussed. Still keeps default behavior intact, but adds a manual override if wanted.

I think this looks good. However, I'm unsure if I necessarily like the feature of inputting a custom list of max_radial

Additionally, when using a fixed number of bases, it unfortunately still does not learn lennard jones successfully. I think this motivates two directions

Ensure my orthonormalization code is actually correct (maybe write some more tests??)
coupling the radial gaussian width with n and/or l

@kvhuguenin thoughts?


False flag on Windows Defender

"Trojan:Script/Wacatac.B!ml"

I've submitted an appeal to microsoft so we'll see what happens 🤷♀

Appeal was accepted 🎉


Adds Oospyraidsy + ui

adds missing translations fr.
adds missing regex de and fr for e4s.
removed fixme lines.
The lines added in French which are not translated is because we use the English words (early pull, late pull, party wipe).

Thanks for the followup!


aur-build: --nocheck is not respected when using chroot

after trying to install spot-client and one of the build tests failing for some reason (still works fine after install), i attempted to rebuild with --nocheck, but the check() function was still run during build. i messed around with flags, and eventually tested it without using a chroot, and --nocheck worked fine.
running the latest commit using aurutils-git
with chroot:
$ aur build -fsCcrR --pacman-conf /etc/aurutils/pacman-aur.conf --makepkg-conf /etc/aurutils/makepkg-aur.conf --nocheck
Running aur chroot --create --makepkg-conf /etc/aurutils/makepkg-aur.conf --pacman-conf /etc/aurutils/pacman-aur.conf
Running aur chroot --update --makepkg-conf /etc/aurutils/makepkg-aur.conf --pacman-conf /etc/aurutils/pacman-aur.conf
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib              149.0 KiB   526 KiB/s 00:00 [----------------------] 100%
 aur is up to date
:: Starting full system upgrade...
 there is nothing to do
Running aur chroot --build --makepkg-conf /etc/aurutils/makepkg-aur.conf --pacman-conf /etc/aurutils/pacman-aur.conf -- -c -u --

without chroot:
$ aur build -fsCrR --nocheck
Running makepkg --syncdeps --rmdeps --clean --nocheck
==> Making package: spot-client 0.3.1-1 (Fri 25 Feb 2022 06:37:48 PM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...

To me, it seems the issue is that --nocheck is not passed to aur chroot correctly - especailly since running aur chroot manually like this builds the packages without running check()
$ aur chroot --update --build --makepkg-conf /etc/aurutils/makepkg-aur.conf --pacman-conf /etc/aurutils/pacman-aur.conf -- -c -u -- --nocheck

sidenote: i enabled ninja and it's awesome! all of my other packages updated, even when this one failed :)

looked at lib/aur-build and found a way to pass it correctly. pr is open above


Bump version to 2.0.2

Codecov Report

Merging #607 (042e03a) into master (7f70a5c) will not change coverage.
The diff coverage is 100.00%.

:exclamation: Current head 042e03a differs from pull request most recent head a993da2. Consider uploading reports for the commit a993da2 to get more accurate results

@@           Coverage Diff           @@
##           master     #607   +/-   ##
=======================================
  Coverage   97.32%   97.32%
=======================================
  Files          23       23
  Lines        2655     2655
=======================================
  Hits         2584     2584
  Misses         71       71

Impacted Files
Coverage Δ

robocop/version.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f70a5c...a993da2. Read the comment docs.


ask

is it available in english?

The theme has nothing to do with the language, just switch the language on your OpenWrt router


State of back/forward navigation

What problem does this feature solve?
It is possible to use router.back() and router.forward() to programmatically navigate. But I was not able to find a state that tells, if this navigation is possible or not. This would be required to create a custom back/forward navigation in a headless browser, where buttons would be disabled if no navigation would be possible.
What does the proposed API look like?
API could look like router.canNavigateBack() and router.canNavigateForward().

Unfortunately, this is an API limitation of the History API. You can implement a userland version of it by keeping track of the different calls to the router but there is no plan to add a native API for this.
However, this should be possible with the upcoming Navigation API

Ok, I see. Thanks @posva for the feedback.

In case somebody is looking for a solution to this problem, this hack works for me:
const state  = reactive({
  forward: false,
  back: false,
})

window.addEventListener('popstate', (event) => {
  state.back = event.state.back != null
  state.forward = event.state.forward != null
})

router.afterEach((to, from, failure) => {
  state.back = true
  state.forward = false
})


Fix a few bugs/diffs in the LIR backend.

Clear the GTF_VAR_USEDEF bit as part of rationalization. This bit is
not used in the backend and causes liveness to be unnecessarily
pessimistic when calculating use/def sets.
Fix LIR::Range::FirstNonPhiOrCatchArgNode, which was just broken.
Simplify the insertion pattern used by InsertPInvokeMethodProlog.

With these changes I am seeing the following diffs when jitting a debug
build of Hello World:

LIR rationalization more aggressively drops side-effect-free
operands to commas. This results in an extra nop in the baseline
codegen. These diffs can probably be prevented with a close reading of
the current comma processing.
LIR liveness more aggressively removes dead stores. The current backend
gives up on dead stores that involve embedded statements. These diffs
are unlikely to be preventable: preventing them would require the
ability to detect whether or not a dead store would have involved an
embedded statement, and adding this capacity is likely to require
substantial effort for very little benefit.

@BruceForstall PTAL

LGTM


Updating requirements to accomidate orchestra rebrand

Closing per slack conversation about incorporating these changes into the broader PR for orchestra rebrand. Redirect is sufficient for the time being.


errors when trying to regrid

notebook "regrid_members" in this repo
ValueError: Dimensions {'lev'} do not exist. Expected one or more of Frozen({'y': 291, 'x': 360, 'time': 1032, 'vertex': 4, 'bnds': 2})

I think you need an additional check here:
def full_testbed_processing(ds: xr.Dataset) -> xr.Dataset:
    ds = ds.squeeze(drop=True)
    # select surface depth (for chl, TODO: Check if surface chlorophyll is available)
    ds = ds.isel(lev=0).drop('lev')

    ds = ds.sel(time=slice('1850', '2100'))

    # testing
    assert len(ds.time) == 3012
    assert ds.time.data[0].year == 1850

    # Processing
    ds_regridded = regrid(ds)
    ds_new_cal = replace_calendar(ds_regridded)

    return ds_new_cal

this line:
    ds = ds.isel(lev=0).drop('lev')

should probably be something like:
    if 'lev' in ds.dims:
        ds = ds.isel(lev=0).drop('lev')

then this should be applicable to both 3d variables (chl) and surface ones (e.g. sos). Alternatively we could ingest the surface chlorophyll data (I think its chlos, but please double check!) and remove that line alltogether.

I don't understand why everything ran smoothly before with the exact same code (see all 18 members here: path = 'gs://leap-persistent/hatlenheimdalthea/testing'). Have I accidentally deleted some code or something? Anyway, I tried both solutions and I get the same error:

AssertionError                            Traceback (most recent call last)
Cell In[7], line 4
2 for k,ds in ddict.items():
3     print(f"Processing {k}")
----> 4     ds_out = full_testbed_processing(ds)
6     ds_id = cmip6_dataset_id(ds_out, id_attrs=[
7     'source_id',
8     'variant_label',
(...)
11     'version',
12     ])
13     save_path = f"gs://leap-scratch/jbusecke/pco2-testing/{ds_id}"
Cell In[6], line 34, in full_testbed_processing(ds)
31 ds = ds.sel(time=slice('1850', '2100'))
33 # testing
---> 34 assert len(ds.time) == 3012
35 assert ds.time.data[0].year == 1850
37 # Processing
AssertionError:

Seems like that dataset does not have the expected number of timesteps?

You could do something like:
for name, ds in ds_dict:
    try:
        full_testbed_processing()
        ...
    except Exception as e:
        print(f"{name} failed with {e}")

This would continue to process later datasets and then you get a printed list of the problematic datasets (which maybe you can fix).
Side note: Check if those particular runs are going beyond 2100! Then it would be as easy as adding a
ds = ds.sel(None,'2100')

To the 'full_testbed_processing' function.


chore: autosynth

This PR was generated using Autosynth. :rainbow:
Synth log will be available here:
https://source.cloud.google.com/results/invocations/e8f6a684-9218-4668-955e-2b7229bff394/targets

[x] To automatically regenerate this PR, check this box. (May take up to 24 hours.)

Closing so it can be regenerated


Dojo name not showing on Salesforce

Here is one example: https://eu2.salesforce.com/00Qb000000I487C?srPos=0&srKp=00Q
The company name is "Craig Hand" but on his listing https://zen.coderdojo.com/dashboard/dojo/gb/craigavon/craigavon It is Craigavon.
Although, here is an example that was converted: https://zen.coderdojo.com/dashboard/dojo/ro/timisoara-timis-county/oce-timisoara
Account is here https://eu2.salesforce.com/001b000001OlIfHAAV/d?retURL=https%3A%2F%2Fnpe01.eu2.visual.force.com%2Fapex%2FaccountViewOverride%3Fid%3D001b000001OlIfH%26sfdc.override%3D1&nooverride=1
but the Dojo name is nowhere to be seen on the Salesforce account.
This Dojo https://eu2.salesforce.com/001b00000143ZzlAAE/d?retURL=https%3A%2F%2Fnpe01.eu2.visual.force.com%2Fapex%2FaccountViewOverride%3Fid%3D001b00000143Zzl%26sfdc.override%3D1&nooverride=1
Has the correct name (as on the listing https://zen.coderdojo.com/dojo/at/welser-strasse-26-4060-leonding/linz) - and the champion account is "Karin" as listed in the partners.

@rosalanghammer is this resolved to the best of your knowledge? I know we had an issue with it in the past but I think it is working now?

Seems to be fixed now. :)
On 25 November 2015 at 15:58, Ursula Clarke Everett <
<EMAIL_ADDRESS>wrote:

@rosalanghammer https://github.com/rosalanghammer is this resolved to
the best of your knowledge? I know we had an issue with it in the past but
I think it is working now?
—
Reply to this email directly or view it on GitHub
https://github.com/CoderDojo/community-platform/issues/683#issuecomment-159653095
.

--
Rosa Langhammer
Reporting Lead
@RosaLanghammer | @CoderDojo
--
Volunteer at your local Dojo and inspire the next generation of digital
creators!

Pledge to start a Dojo https://coderdojo.com/pledge-a-dojo/
How to volunteer at your local CoderDojo
https://coderdojo.com/get-involved/volunteer/
Read the CoderDojo Foundation Strategy
https://coderdojo.com/news/2015/08/07/the-coderdojo-foundation-strategy-20152016/

--
Hello World Foundation operating as the CoderDojo Foundation is a company
limited by guarantee not having a share capital with charitable status, CHY
20812. Registered in Dublin, Ireland, No 524255. Registered Office:
Dogpatch Labs, Unit 1, CHQ Building, Custom House Quay, Dublin 1, Ireland.

Excellent!


Add read-the-docs support

After talking to @stefanprodan I realised that versioned docs won't work easily with Gitbook, we'd also just have one free repo.
read-the-docs might be the way to go. Here's a WIP PR to get this into shape.
To run this, do:
# prep
pip3 install sphinx recommonmark sphinx_rtd_theme sphinx_markdown_tables
# build
cd site; make html

Todo list:

[x] fix index
[x] integrate https://hub.docker.com/r/ddidier/sphinx-doc/
[x] break up docs into subdirectories(?)
[ ] generally document how to use this
[ ] hook up with release/build process
[ ] publish multiple releases
[ ] publish docs publicly
[ ] add linkchecker(?) to find broken links

In https://github.com/weaveworks/flux/pull/2152/commits/e3f3730378576b4c2a43b1cef44d4f104498897e I made some changes to set up a new directory/index structure. This is just a proposal for everyone to get an idea. Let me know what you think.

@stefanprodan in 2a30963 I added the build-in/serve-from docker, it's a bit messy, but there's instructions on how to to it in site/Dockerfile. Feedback/fixes welcome.

@dholbach I've simplified the docs preview, all you need to do is run make run-docs from the root of the project.
Running make run-docs will:

build the docs website inside the docker image
create a docker image named flux-docs:latest
run the docs website on http://localhost:8000/_build/html/index.html

PS. You can change the port binding with DOCS_PORT=8080 make run-docs

Nice work, @stefanprodan! Would it make sense to have generate-docs and serve-docs targets? How are we going to deploy this?

I just changed the directory structure somewhat... please let me know if I was jumping the :shark: here:
.
├── development
│   ├── building.md
│   └── get-started-developing.md
├── faq.md
├── helm
│   ├── helm-integration.md
│   ├── helm-operator.md
│   └── helm-upgrading-to-beta.md
├── how-it-works.md
├── install
│   ├── get-started.md
│   ├── helm-get-started.md
│   ├── installing.md
│   └── standalone-setup.md
├── internals
│   ├── daemon.md
│   ├── fluxyaml-config-files.md
│   └── garbagecollection.md
├── introduction.md
├── requirements.md
├── troubleshooting.md
└── using
    ├── annotations-tutorial.md
    ├── fluxctl.md
    ├── git-gpg.md
    ├── monitoring.md
    └── upgrading-to-1.0.md

@dholbach as describe here https://dont-be-afraid-to-commit.readthedocs.io/en/latest/documentation.html#readthedocs-org Read the Docs will watch your GitHub project, and build, render and host your documents for you automatically.

Would it be an idea to split the FAQ (fluxd / Helm op)?

The docs structure looks ok to me 💯

Yeah maybe the Helm Operator docs should be in a separate dir, this would make things easier when we'll have helm-op in its own repo.

You guys think ahead! :+1:

@dholbach I am going to file my final judgement of the new structure as soon as I have viewed a rendered version of the documentation. Hope to do this by the end of the day :crossed_fingers:

@hiddeco Luckily @stefanprodan made this very easy.... make run-docs and you're all set.

Thoughts now that I have seen the rendered views:

'Installing Flux' index should contain a section about installing Flux and the Helm operator at the same time, this could be on a new page or we can divide the 'get started' in two sections, one without the operator and one with.
I think we should rethink some of the page titles, e.g. we have a top item 'Using Flux' with a 'child page' 'Using Weave Flux'.
I think we should rethink some parts of the (naming of the) new structure, e.g, we have a 'introducing Weave Flux' index, but also a 'how Weave Flux Works' index. As a new user, I would expect the introduction to contain the latter, so we may need to rethink the naming, or merge parts.
'Internals' is something that would scare me away as a user, listing the more important features under this index (garbage collection and manifest factorization) will probably reduce the amount of people finding this information by themselves.
...more TBA (this is the result of a couple of minutes of thinking)

I think, to give people the best document experience possible, we should maybe think out a structure without looking at what we currently have, but what we do want to tell people, and merge / rewrite things back into this structure so we revise all documentation at the same time.

https://github.com/rtfd/recommonmark/issues/8 bites us for the following links:
faq.md:arguments reference](daemon.md#flags).
faq.md:[standalone-setup.md](./standalone-setup.md#using-a-private-git-host).
helm/helm-integration.md:You can use the [same annotations](./fluxctl.md#using-annotations) in
troubleshooting.md:[FAQ](./faq.md#can-i-change-the-namespace-flux-puts-things-in-by-default).
troubleshooting.md:   [./standalone-setup.md](./install/standalone-setup.md#using-a-private-git-host).
using/annotations-tutorial.md:it. `fluxctl` has the [`--k8s-fwd-ns <NAMESPACE>` option](../fluxctl.md#Connectingfluxctltothedaemon) for specifying the right
using/annotations-tutorial.md:interact with the deployments. First, please [install fluxctl](../fluxctl.md#installing-fluxctl).
using/fluxctl.md:- [`org.opencontainers.image.created`](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys)
using/fluxctl.md:using `flux.weave.works/ignore: "true"`. Read more about this in the [FAQ](faq.md#can-i-temporarily-make-flux-ignore-a-deployment).

We also need to find a solution for overflowing text boxes.

This is marvellous work, thank you @dholbach, and @stefanprodan and @hiddeco for pushing it onward.

@dholbach regarding overflowing text boxes, I think we should use multi-line code blocks and we'll get a horizontal scrollbar.

If we want to hook this up with readthedocs.org and serve the files from there, we need to decide on a project name - flux is taken.

@bia Can you remind me of which fonts to use?

Proxima Nova and Roboto Mono

Proxima Nova and Roboto Mono

For monospace, right? In this order? Which other fonts to fall back to?
Which general font?

body {
  font-family: "Montserrat", sans-serif;
  src: url(../static/fonts/montserrat-regular.ttf) format("truetype");
}

code {
  font-family: "Roboto Mono", monospace;
  src: url(../static/fonts/robotomono-regular.ttf) format("truetype");
}

Some links are also broken because of https://github.com/ryanfox/sphinx-markdown-tables/issues/18 ...

@dholbach maybe remove the links from tables? I don't think those are so important. Also I would setup readthedocs.org with weave-flux just for testing.

@stefanprodan @hiddeco @squaremo I'd appreciate if you could take a look at the TODO list at the very top and give feedback on what we want to solve now and what can happen later.
While it'd be great to solve all the problems we have with docs in this PR, I'd prefer to get something out soon. :-D

Not sure if weave-flux is future-proof considering the discussions about CNCF Sandbox - it should definitely be OK for testing.

@dholbach none of my feedback is blocking. I think we should deal with the last two items in the content section (as they break the docs), hook-up the test to the CI, and publish it, and continue iterating over what's published.

I worked around the link issues, the linkchecker run passes now. I added it to our CircleCI config.

Are these the next steps?

Add master build on readthedocs.io
Link to it from main README.md.
(Check if there are other links which need to be updated.)
Merge this PR.
File issues for all the other bits identified during this work
Celebrate! :champagne: :fireworks: :beach_umbrella:

So regarding readthedocs.io:

settle on readthedocs ID
use githubbot account (which?)
connect the two sites
push branch to new org(?)
do we link to master docs by default?
...

@dholbach

settle on readthedocs ID: I would go with fluxcd like the org name
use githubbot account: I think this one Github Weaveworksbot see 1Pass
do we link to master docs by default: yes until the next release when we could switch to it as default

Not sure Flux will need its own Github bot account in the future?

yeap, we have to create a bot account in fluxcd org

Has the bot been created?

@dholbach how does the versioned documenting work, do you know this?

We can have read-the-docs import different branches regarding versions. Stable and Latest are aliases we can assign. We can probably add more aliases too.


Make some scavs hostile to player during scav raids

Goals:

Single bot is hostile to player
Variable % of scavs being hostile to player
Only adjusts scavs when player runs a scav raid

Some investigation into making this happen:
Alter CustomAiPatch
Inside if (AiHelpers.BotIsPlayerScav(__state, ___botOwner_0))
___botOwner_0.Profile.Info.Settings.Role = aIBrainSpawnWeightAdjustment.GetRandomisedPlayerScavType(___botOwner_0, currentMapName);
___botOwner_0.BotsGroup.AddEnemy(player, EBotEnemyCause.checkAddTODO);

It makes the bot hostile to player but they dont shoot/acknowledge player is an enemy.

Originally written by chomp

It would be cool to have this as a server value that the user can toggle true or false. I kinda liked not having to worry about hostile scavs on scav runs lol so it'd be cool to have it optional for the end user, but idk if it'd be easy to implement.

Originally written by Reanimate

This is a test patch I made, it will make random scavs hostile to the player, and not cause the rest of the scavs to go hostile when you kill them. From testing, they are also not hostile to other scavs, just the player.
public class TestPatch : ModulePatch
{
    protected override MethodBase GetTargetMethod()
    {
        return AccessTools.Method(typeof(BotSpawner), nameof(BotSpawner.GetGroupAndSetEnemies));
    }

    [PatchPrefix]
    private static bool PatchPrefix(ref BotsGroup __result, IBotGame ____game, DeadBodiesController ____deadBodiesController, BotOwner bot, BotZone zone)
    {
        // TODO: This would need to check for player scav, for ease of testing I used all scavs
        WildSpawnType role = bot.Profile.Info.Settings.Role;
        if (role == WildSpawnType.assault && new Random().Next(1, 100) > 50)
        {
            Logger.LogInfo($"Making {bot.name} ({bot.Profile.Nickname}) hostile to player");

            // Create a new group for this scav itself to belong to
            var player = Singleton<GameWorld>.Instance.MainPlayer;
            var enemies = new List<BotOwner>();
            var players = new List<Player>() { player };
            var botsGroup = new BotsGroup(zone, ____game, bot, enemies, ____deadBodiesController, players, false);

            // Because we don't want to use the zone-specific group, we add the new group with no key. This is similar to free for all
            Singleton<IBotGame>.Instance.BotsController.BotSpawner.Groups.AddNoKey(botsGroup, zone);
            botsGroup.AddEnemy(player, EBotEnemyCause.checkAddTODO);

            // Make it so the player can kill the scav without aggroing the rest of the scavs
            bot.Loyalty.CanBeFreeKilled = true;

            // Return our new botgroup
            __result = botsGroup;

            // Skip original
            return false;
        }

        return true;
    }
}

Originally written by DrakiaXYZ

Implemented with:
https://dev.sp-tarkov.com/SPT-AKI/Server/commit/ff1e80e302260e0e6c44d445f1740f7a71765f17
https://dev.sp-tarkov.com/SPT-AKI/Modules/commit/761d6c339dae0fcfdc0b9fe05d6b33eabd027772

Originally written by chomp

Now we need a fix for the fact that there is no rep penalty for hostile scavs after they have hit you.

Originally written by artofsound


Default configuration not used after init start

After loading the module in a new session i have the configurations still stored. But when i try to run test-smaconfiguration i am asked about the config i want to use (see below). It should use the "is Actve" configuration.

The requirement was that the command tests a configuration.
In case of a troubleshooting process, it would be better to select the configuration to test.
From: Roman Stadlmair @.>
Sent: Samstag, 17. Juli 2021 10:47
To: seppmail/SEPPmailAPI @.>
Cc: Hans Halbmayr @.>; Assign @.>
Subject: [seppmail/SEPPmailAPI] Default configuration not used after init start (#18)
After loading the module in a new session i have the configurations still stored. But when i try to run test-smaconfiguration i am asked about the config i want to use (see below). It should use the "is Actve" configuration.
[Image removed by sender. grafik]https://user-images.githubusercontent.com/22378822/126031641-2e41333f-db29-4f86-9050-0c5fa0c1ba0d.png
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/seppmail/SEPPmailAPI/issues/18, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AT7CWMY4BPAK5GOJMREPETTTYE7R5ANCNFSM5AQ3QOPA.

The requirement was that the command tests a configuration.
In case of a troubleshooting process, it would be better to select the configuration to test.
In my opinion this is not a bug.

so true, all other CmdLets use the default config in a new session. Case closed.


Compilation in a macOS GitHub runner fails with cc v1.0.84

Hello!
For my crate opencv I see that starting with cc version 1.0.84 the macOS runners are failing: https://github.com/twistedfall/opencv-rust/actions/runs/6853515550
I must also note that I haven't used cc versions 1.0.80..=1.0.83 because of the another issue that was causing hangs due to the interaction of jobserver in both cc and opencv (https://github.com/rust-lang/cc-rs/issues/844)
The specific error is:
fatal error: 'limits' file not found

it is caused by the missing stdlib which clang warns about too:
clang: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]

As far as I can see between version 1.0.79 and 1.0.84 the C++ compiler is called with different arguments:

1.0.79

"c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-2" "-fno-omit-frame-pointer" "-m64" "-arch" "x86_64" "-I" "/Users/runner/work/opencv-rust/opencv-rust/src_cpp" "-I" "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-fb8aea6a002a5c33/out" "-I" "." "-I" "/usr/local/opt/opencv/include/opencv4" "-Wall" "-Wextra" "-std=c++14" "-Wno-deprecated-declarations" "-Wno-deprecated-copy" "-Wno-unused-parameter" "-Wno-sign-compare" "-Wno-comment" "-Wno-unused-variable" "-Wno-ignored-qualifiers" "-Wno-return-type-c-linkage" "-Wno-overloaded-virtual" "-F/usr/local/opt/opencv/include/opencv4" "-o" "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-fb8aea6a002a5c33/out/d25e1c8da0c38997-core.o" "-c" "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-fb8aea6a002a5c33/out/core.cpp"

1.0.84

"c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-2" "-fno-omit-frame-pointer" "-m64" "--target=x86_64-apple-darwin" "-mmacosx-version-min=10.7" "-I" "/Users/runner/work/opencv-rust/opencv-rust/src_cpp" "-I" "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-80956898113978e8/out" "-I" "." "-I" "/usr/local/opt/opencv/include/opencv4" "-Wall" "-Wextra" "-std=c++14" "-o" "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-80956898113978e8/out/02e9e909b56518ad-core.o" "-c" "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-80956898113978e8/out/core.cpp"

The main differences I see is the -arch, --target, -mmacosx-version-min and a bunch of -W flags. That's likely to be  The compiler identity looks different too:

1.0.79 identifiers as Gnu

=== Compiler information: Tool {
    path: "c++",
    cc_wrapper_path: None,
    cc_wrapper_args: [],
    args: [
        "-O0",
        "-ffunction-sections",
        "-fdata-sections",
        "-fPIC",
        "-gdwarf-2",
        "-fno-omit-frame-pointer",
        "-m64",
        "-arch",
        "x86_64",
        "-I",
        "/Users/runner/work/opencv-rust/opencv-rust/src_cpp",
        "-I",
        "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-fb8aea6a002a5c33/out",
        "-I",
        ".",
        "-I",
        "/usr/local/opt/opencv/include/opencv4",
        "-Wall",
        "-Wextra",
        "-std=c++14",
        "-Wno-deprecated-declarations",
        "-Wno-deprecated-copy",
        "-Wno-unused-parameter",
        "-Wno-sign-compare",
        "-Wno-comment",
        "-Wno-unused-variable",
        "-Wno-ignored-qualifiers",
        "-Wno-return-type-c-linkage",
        "-Wno-overloaded-virtual",
        "-F/usr/local/opt/opencv/include/opencv4",
    ],
    env: [],
    family: Gnu,
    cuda: false,
    removed_args: [],
}

1.0.84 identifies as Clang:

=== Compiler information: Tool {
    path: "c++",
    cc_wrapper_path: None,
    cc_wrapper_args: [],
    args: [
        "-O0",
        "-ffunction-sections",
        "-fdata-sections",
        "-fPIC",
        "-gdwarf-2",
        "-fno-omit-frame-pointer",
        "-m64",
        "--target=x86_64-apple-darwin",
        "-mmacosx-version-min=10.7",
        "-I",
        "/Users/runner/work/opencv-rust/opencv-rust/src_cpp",
        "-I",
        "/Users/runner/work/opencv-rust/opencv-rust/target/debug/build/opencv-80956898113978e8/out",
        "-I",
        ".",
        "-I",
        "/usr/local/opt/opencv/include/opencv4",
        "-Wall",
        "-Wextra",
        "-std=c++14",
    ],
    env: [],
    family: Clang,
    cuda: false,
    removed_args: [],
    has_internal_target_arg: false,
}

The compiler is created as follows in opencv code: https://github.com/twistedfall/opencv-rust/blob/730cc64955ab4ad5286bee891e795a1322b053c0/build.rs#L223-L276

The main branch seems to work (https://github.com/twistedfall/opencv-rust/actions/runs/6864735405/job/18667178550), although I do see a "macOS deployment target (10.7) too low, it will be increased" warning on each c++ invocation. Additionally it seems that it's running c++ --version a lot now.

We have the same issue with CXX-Qt, 1.0.83 works but 1.0.84 doesn't ( https://github.com/KDAB/cxx-qt/pull/733 ). I'll see if main branch works or not for us too.

So the issue changed using main, now i get the following in CI instead of the clang: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead issue before. We are using macOS 11 at the moment :thinking:
 warning: /Users/runner/cxx-qt/build/examples/qml_features/cxxqt/qml-features/cxx-qt-common/cxxqt_thread.h:32:10: error: 'shared_mutex' is unavailable: introduced in macOS 10.12
warning:   ::std::shared_mutex mutex;
warning:          ^
warning: /Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/c++/v1/shared_mutex:180:58: note: 'shared_mutex' has been explicitly marked unavailable here
warning: class _LIBCPP_TYPE_VIS _LIBCPP_AVAILABILITY_SHARED_MUTEX shared_mutex
warning:                                                          ^

and
 warning: /Users/runner/cxx-qt/build/vcpkg_installed/x64-osx/include/Qt6/QtCore/qfileinfo.h:85:22: error: 'path' is unavailable: introduced in macOS 10.15
warning:     std::filesystem::path filesystemCanonicalFilePath() const
warning:                      ^
warning: /Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/c++/v1/filesystem:902:24: note: 'path' has been explicitly marked unavailable here
warning: class _LIBCPP_TYPE_VIS path {
warning:                        ^

@ahayzen-kdab Do you have a MACOSX_DEPLOYMENT_TARGET set in your project? Based on those unavailable errors it seems like cxx-qt might have unintentionally been relying on the past behavior where cc wouldn't pass any deployment target to clang, so clang defaulted to the current OS (macOS 11 for you).
@twistedfall that's the same behavior cc used to have (rounding up the deployment target when using C++) but my recent PR made it a visible warning since it could be unexpected behavior for some projects/apps. You can get rid of it by picking a MACOSX_DEPLOYMENT_TARGET for your CI builds, and users won't see it via a crates.io download.

Hmm, the goal with that PR was to avoid the breakage we might have when rustc bumps it's deployment target from 10.7 to 10.12, if it has the side effect of requiring the ecosystem to set their deployment targets, that's unintentional.
Most people will have no clue -- it's not like there's an easy way to map between C++ stdlib features and the version of macOS they were added.
This seems like a big and unintentional regression.
I'm away for the week (still working, but without access to an Intel mac, and with limited time for non-$dayjob work like cc), and I'm probably going to yank the latest release until we can get this sorted out.
Sorry for all the issues, everyone.

1.0.84 has been yanked.

Ah, yeah, we should cache this result. Does that actually cause problems though? It's from a different change.

Not really, it's just a new behavior that I noticed which seems suboptimal.

It should be cached.

I will be working on caching the c++ --version, would submit a PR later today

I encountered that behavior when running cargo t on my M1 macbook, so it's indeed a breaking behavior

@thomcc Would it makes sense to bump the default MACOSX_DEPLOYMENT_TARGET to 10.15?
That might help reduce the regression introduced.

Thanks you are correct adding MACOSX_DEPLOYMENT_TARGET: 10.15 to github actions has helped. Guess we need to find the correct spot to put this and whether it goes into our build scripts etc but that's off topic for here.

Setting an environment variable isn't a great solution for downstream builder of crates that require deployment target minimums above cc's defaults. Unfortunately the existing Build::flag_if_supported doesn't quite work, so I think a new API is needed: #938

hello @BlackHoleFox , I think we need to fix this regression and release a new version due to amount of commits/PRs unreleased.
However I'm not sure how to handle this issue, hence I'm asking for your help here.

Would it be possible to revert the commit that caused this issue to unblock a new release of cc-rs, then we can get that commit back in once we have a fix for this issue alongside it?

I mentioned this to @NobodyXu in a Zulip DM but I will be opening a PR shortly to revert the specific behavior change of querying rustc for the default version if nothing is supplied instead of using the SDKs' DefaultDeploymentTarget. I'll try and have that up tonight for review.

The fixing PR is up now if anyone is interested in manually testing it.


[Task] Add CLI doc

What should be done
Add the CLI documentation in references/cli.
Technical recommandation
Just add it to doc-deps.yml
Is this task linked with any other ?
Blocked by https://github.com/lenra-io/lenra_cli/issues/220

:tada: This issue has been resolved in version 1.0.0-beta.12 :tada:
The release is available on:

GitHub release
v1.0.0-beta.12

Your semantic-release bot :package::rocket:


Feature/34 introduce unit tests for generator

Unit tests using Pytest for generator.py and main.py.
Release Notes:

Implemented unit tests using Pytest for generator.py and main.py (project code-cov at (96 %).

Closes #34

Added suggested Action Inputs tests for testing the default values. Ready for another review.


Integration with non rails

Can Lamby be integrated with other non rails apps such as Sinatra?
thanks!

Correct! It has always been about a basic Rack interface which means anything Rack, including Sinatra. There was some work in June where we removed some specific Rails deps. See #56 for the work and please let me know if you have any issues using it with Sinatra.
Oh, reminder, it has to be rack v2 or higher. The means Rails v5.2 or up but I do not know what that may mean for Sinatra. Thanks!!!


GitHub build workflow

@ghuntley Can you delete this? This was meant to go against my own repository and GitHub sent me straight to you instead lol


Increase GKE E2E test timeout

Shot-in-the-dark fix for test flakiness - let's see if this works.

Is this still needed?


nixvim.enable being ignored.

I'm trying to rebuild my system but it keeps trying to symlink a init.lua to my neovim config directory. And so it fails because I already have a config there.
My config:
  stylix = {
    enable = true;
    image = ../wallpapers/cherry-blossom.jpg;
    polarity = "dark";
    cursor = {
      package = pkgs.bibata-cursors;
      name = "Bibata-Modern-Ice";
      size = 44;
    };
    fonts = {
      monospace = {
        name = "JetBrains Mono";
        package = pkgs.jetbrains-mono;
      };
      sansSerif = {
        name = "Inter";
        package = pkgs.inter;
      };
      sizes = {
        terminal = 15;
      };
    };
    opacity = {
      terminal = 0.9;
    };
    targets = {
      nixvim.enable = lib.mkForce false;
    };
    homeManagerIntegration.followSystem = true;
  };

I'm trying to rebuild my system but it keeps trying to symlink a init.lua to my neovim config directory. And so it fails because I already have a config there.

What Stylix version are you encountering this on?
For reference, maybe something is wrong with the NixVim guard:
https://github.com/danth/stylix/blob/29148118cc33f08b71058e1cda7ca017f5300b51/modules/nixvim/nixvim.nix#L16-L17
Considering your stylix.targets.nixvim.enable = lib.mkForce false; declaration, the problem might come from somewhere else.

@trueNAHO
    "stylix": {
      "inputs": {
        "base16": "base16",
        "base16-fish": "base16-fish",
        "base16-foot": "base16-foot",
        "base16-helix": "base16-helix",
        "base16-kitty": "base16-kitty",
        "base16-tmux": "base16-tmux",
        "base16-vim": "base16-vim",
        "flake-compat": "flake-compat",
        "gnome-shell": "gnome-shell",
        "home-manager": "home-manager_2",
        "nixpkgs": "nixpkgs_2"
      },
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-xSO/H67GAHEW0siD2PHoO/e97MbROL3r3s5SpF6A6Dc=",
        "owner": "danth",
        "repo": "stylix",
        "rev": "1ff9d37d27377bfe8994c24a8d6c6c1734ffa116",
        "type": "github"
      },
      "original": {
        "owner": "danth",
        "repo": "stylix",
        "type": "github"
      }
    },

@trueNAHO
Yes that fixes the issue, thank you very much.


[Documentation]: Questions for RedisIndex

Documentation Issue Description
May I ask for more explaination for doc of RedisStore.

How to load index in RedisVectorStore that had been loaded previously? (So that it avoids embedding and cost again.)
Would SimpleDirectoryReader('data').load_data() do it automatically (Assume files are all unchange)
Or neither of it and VectorStoreIndex.from_documents do it, which means I need to implement this layer myself?

I also suggest that add 'retriever = index.as_retriever()' part to this page, so that readers can understand its usage with flexibility.
Documenation Link
https://gpt-index.readthedocs.io/en/latest/examples/vector_stores/RedisIndexDemo.html

I've tried something like this:
r = redis.Redis()
    check_exist = r.get(f"added:{index_name}")
    if check_exist:
        print(f"index {index_name} found.")
        vector_store = RedisVectorStore(
                index_name=index_name,
                index_prefix="llama",
                redis_url=redisURL,
                # overwrite=True,
            )
        storage_context = StorageContext.from_defaults(vector_store=vector_store)
        index = load_index_from_storage(storage_context=storage_context)

However it says:

index = load_index_from_storage(storage_context=storage_contex)
ValueError: No index in storage context, check if you specified the right persist_dir.

I've refered other source, but it did not apply to Redis:
https://gpt-index.readthedocs.io/en/latest/core_modules/data_modules/storage/save_load.html
storage_context = StorageContext.from_defaults(
    docstore=SimpleDocumentStore.from_persist_dir(persist_dir="<persist_dir>"),
    vector_store=SimpleVectorStore.from_persist_dir(persist_dir="<persist_dir>"),
    index_store=SimpleIndexStore.from_persist_dir(persist_dir="<persist_dir>"),
)

Also, RedisVectorStore seems do not have a smilar function called 'from_persist_dir' or 'from_persist'.

I've found code here and tried to put them togeher:
https://github.com/jerryjliu/llama_index/pull/6619
index_store = RedisIndexStore.from_host_and_port(
            host="localhost", port=6379, namespace="llama_index"
        )
        storage_context = StorageContext.from_defaults(vector_store=vector_store, index_store=index_store)
        index = load_index_from_storage(storage_context)

It still says

ValueError: No index in storage context, check if you specified the right persist_dir.

There I've traced to:
llama_index/indices/loading.py line 64:

index_structs = storage_context.index_store.index_structs()

This line returns empty 'index_structs' as []
That's the furthest way I can explore on my own.

I've tried another piece here:
https://gpt-index.readthedocs.io/en/latest/core_modules/data_modules/index/vector_store_guide.html
vector_store = RedisVectorStore(
                index_name=index_name,
                index_prefix="llama",
                redis_url=redisURL,
                # overwrite=True,
            )

# ADD HERE:
index = VectorStoreIndex.from_vector_store(vector_store=vector_store)

I was able to proceed to:
r = index.as_retriever()
response = r.retrieve(promt_text)

Then got a strange error from redis:
INFO:llama_index.vector_stores.redis:Querying index index_name
Querying index index_name
...
... return self._retrieve(str_or_query_bundle)
... query_result = self._vector_store.query(query, **self._kwargs)
... response = connection.read_response()
/redis/connection.py", line 905, in read_response
    raise response
redis.exceptions.ResponseError: Property `vector_score` not loaded nor in schema

That final approach is the intended way to load a saved vector store
Not sure on that error though, that's a little weird 🤔

That final approach is the intended way to load a saved vector store
Not sure on that error though, that's a little weird 🤔

Now everything is functioning normally, but I have no clue whatsoever.

any resolution to this vector_score problem
despite following the same code its still showing the same error
raise response
redis.exceptions.ResponseError: Property vector_score not loaded nor in schema

I am also getting this error, very strange as the code ran fine, then I flushed the DB and recreated the index in exactly the same way and my next query threw that error.  FT.INFO reveals the a correct index.


INTERNAL COMPILER ERROR: async functions should have already been converted

function hh(a){cf(a);if(OL(a,42)){throw Cjb(GL(a,42))}if(OL(a,153)){throw Cjb(GL(a,153))}}
                                  ^
Error: java.lang.RuntimeException: INTERNAL COMPILER ERROR. Please report this problem.  async functions should have already been converted   Node(FUNCTION ): browser.bundle.js:6213:15   static async create (sessionId) {   Parent(ASSIGN): browser.bundle.js:6213:15   static async create (sessionId) {
    at TJ.tH [as ag] (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:8093:23242)
    at TJ.wH [as cg] (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:8093:23437)
    at TJ.sH (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:2315:48)
    at TJ.AH (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:615:19)
    at new TJ (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:617:19)
    at vIb (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:5861:95)
    at TBc (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:4683:106)
    at UBc (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:5533:126)
    at t4c (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:7040:301)
    at B2b.C2b [as Ag] (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:8093:219415)
    at zNc (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:7657:306)
    at ANc.BNc [as Ag] (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:8093:319859)
    at pNc (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:5907:146)
    at YGb (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:5211:91)
    at _Hb (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:3503:69)
    at WIb.XIb [as qi] (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:8093:159481)
    at jJb (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:4841:36)
    at $Gb (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:7438:153)
    at jjd (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:7687:358)
    at hK (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:1828:29)
    at kK (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:3196:44)
    at /home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/jscomp.js:3399:46
    at module.exports (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/compile.js:31:15)
    at files.forEach.name (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/lib/webpack.js:61:28)
    at Array.forEach (<anonymous>)
    at chunks.forEach.chunk (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/lib/webpack.js:49:17)
    at Array.forEach (<anonymous>)
    at Compilation.compilation.plugin (/home/zubzub/git/greenfield/node_modules/google-closure-compiler-js/lib/webpack.js:47:16)
    at Compilation.applyPluginsAsyncSeries (/home/zubzub/git/greenfield/node_modules/tapable/lib/Tapable.js:206:13)
    at applyPluginsAsync.err (/home/zubzub/git/greenfield/node_modules/webpack/lib/Compilation.js:663:10)

Failing file:
https://github.com/udevbe/greenfield/blob/master/browser/src/BrowserSession.js
webpack config:
const path = require('path')
const ClosureCompiler = require('google-closure-compiler-js').webpack

module.exports = {
  entry: './browser/src/index.js',
  output: {
    path: path.resolve(__dirname, 'browser/public'),
    filename: 'browser.bundle.js'
  },
  plugins: [
    new ClosureCompiler({
      options: {
        languageIn: 'ECMASCRIPT6',
        languageOut: 'ECMASCRIPT5',
        // compilationLevel: 'ADVANCED',
        warningLevel: 'VERBOSE'
      }
    })
  ]
}

plain webpack'ed file attached:
bundle.zip
//edit
When trying to Java version, it complained about async being ecma8. So I changed the in & out language to 8 which resulted in an EPIPE error (using Java).
When using the javascript version I got the following error: #98

languageOut: 'ECMASCRIPT8' -> That's not yet a supported output language. Highest output language currently supported is ECMASCRIPT6.


Observed 400 bad request for Signing/monitoring api in network tab and user has to refresh the github repository page to see CLA Signed button

Background

Launch the github repository (which is configured to sign ICLA)

Login as contributor

Update any file and create PR

Checks fail

Click on the link to sign CLA

Contributor is redirected to contributor console

Click Individual option

User is navigated to docusign

Enter all details in the template to sign the document

Click Finish

Observed that after signing the document user is redirected to github repository page and "All Checks have passed" message is displayed but still CLA Not Signed button is displayed

Observed that 400 bad request is returned for https://demo.docusign.net/Signing/monitoring?ti=7a9a2b7c0f4b4c50a1bdee3dc2171a34

Observed that after user refreshes the page CLA Signed button is displayed

@wanyaland this is a tricky one - can you review the workflow to see if you can reproduce this issue that Niru has observed?
Normally GH auto-refreshes and shows a consistent view
Need to investigate the error from focusing to see if this is normal or not.

@wanyaland has confirmed that this is most-likely a GH refresh issue once the status has been updated for the PR. Nothing to fix or address on the EasyCLA side.

We need to understand why this is happening in some cases. The most recent example is https://github.com/grpc/grpc/pull/22870

May be related to #2194

Created PR: https://github.com/communitybridge/easycla/pull/2202
How to test:
Create PR on repo which has EasyCLA configured and user has not signed
Notice the user is gated and the EasyCLA status check fails. Note the comment indicates failure.
Sign the CLA to authorize the user.
Navigate back to GitHub. Observe that the status check passes and that the old comment is updated with a pass/success.

Confirmed. Closing issue.


rename bro-pkg.meta to zkg.meta

As of v6.1.0 packages no longer install with zkg without zkg.meta. This PR renames bro-pkg.meta to zkg.meta without any changes to content.

Anybody there?


Bad PSR-4

Hello,
Thank you for your response to my previous issue, however there are still some problems.
Please follow PSR-2 (Coding Style Guide)
see: http://www.php-fig.org/psr/psr-2/
Use Psr\Logger (PSR-3) for MangoPay\Libraries\Logs
see: https://github.com/php-fig/log

PSR-4 and PSR-2/3 are different things :-) So its normal that a PSR-4 compliant library may not meet the other specifications etc. If you have specific problems with the newly released version and PSR-4 in particular, then please let us know, but otherwise it's not "bad" :-)
As for PSR-2 and 3, this is not something we're currently working on, but we may well do in the future.


[Draft][Unity][Transform] Extract partial-tuple-usage from FuseTIR

Prior to this commit, the FuseTIR pass explicitly tracked usage of
tuple arguments, to minimize the set of arguments provided to each
kernel.  The additional tgracking and handling of partially-used
tuples makes it difficult to follow the primary changes being made by
FuseTIR.
This commit implements the same functionality in terms of the
ExpandTupleArguments and RemoveUnusedParameters transforms,
introduced in https://github.com/apache/tvm/pull/16115 and
https://github.com/apache/tvm/pull/16116 respectively.  By using these
passes before the main FuseOps changes, partial tuple usage is
already handled at that point.
This commit is intended to minimize any changes to user-facing
behavior, and so these pre-process passes are currently used
internally by FuseTIR.  This may be avoided in the future by pulling
this internal delegation out into a lowering pipeline.

This PR is marked as a draft, until the pre-requisite PRs #16115, #16116, #16117, and #16118 land.

All pre-requisite PRs have landed, and this is now ready for review.

Rebased onto unity to avoid stale CI results.


Feat: useServerSentEvents

Provides a solution for real-time data streaming
Based on ReadableStream, which is compatible with Hattip responses
Using @microsoft/fetch-event-source rather than vanilla EventSource for increased flexibility, e.g. the ability to obtain response headers

Oh, this is cool!
Hot reloading tests fail because of deps optimization problems. Easily fixed by adding @microsoft/fetch-event-source to optimizeDeps.include.
I'll have a look at the other failing tests to understand what's going on.

Thanks! By optimizeDeps.include, do you mean the one at src/vite-plugin/inject-config.ts?

Yes, exactly.

Great, looks like that did the trick.

I tried it and gave it quite a bit of thought.
This is a great API for a live data view: think of a live Avatar component that updates itself every time the user updates their profile photo. It can be immensely useful in some circumstances. But for the general case, it may direct Rakkas users to bad practices: One TCP connection per live view is very expensive, especially if you consider only six concurrent open SSE connections per browser are allowed at any one time. So having multiple useSSE calls in an app should be highly discouraged. Even a single call within a component that's instantiated multiple times can cause problems.
I don't have a fully clear picture in my head yet but I feel like we can come up with a solution that requires one live connection per open tab and do the multiplexing ourselves on the client.
A second consideration is the API itself: This is API great for a live view. But an event-based API (useSSE(() => { ... }, { onMessage(message) { ... })) would be more useful for things like notifications.
I want to give this a bit more thought before committing to a solution. This is a good solution but I don't want to miss a great one and I feel a great one is hiding somewhere in there :)
Feel free to ping me on Discord, we can develop the idea together.

One TCP connection per live view is very expensive, especially if you consider only six concurrent open SSE connections per browser are allowed at any one time. So having multiple useSSE calls in an app should be highly discouraged. Even a single call within a component that's instantiated multiple times can cause problems.

Good point, hadn't considered it.

I don't have a fully clear picture in my head yet but I feel like we can come up with a solution that requires one live connection per open tab and do the multiplexing ourselves on the client.

Multiplexing on the client seems relatively straightforward to implement, probably would only need to wrap the app with a context provider holding the request. Though on the server, I think it will require quite a bit of book-keeping. I'll also think about a design if I get more spare time.

A second consideration is the API itself: This is API great for a live view. But an event-based API (useSSE(() => { ... }, { onMessage(message) { ... })) would be more useful for things like notifications.

Agreed. Though I initially wrote it like this since what you described can also be achieved with useEffect(() => { ... }, [message]).

Yeah, I couldn't wrap my head around how to implement the server-side multiplexing.
I did some research and turns out HTTP/2 improves things a lot, the limit is more like about a hundred connections. But the connection limit is still a concern on development time.
It's useful as is, I'll merge it today but remove its docs from the table of contents for now. I'd like to think about documented features as final, or at least close to final. We can document it once we're more confident on the API.

Sounds good!

Published in 0.6.17!

Hi @rliang,
I'm writing here because I don't have any other contact info. I invited you to Rakkas org on GitHub. Don't think of it as a responsibility, you aren't expected to do anything. Thank you for your contributions so far, and, if you accept, welcome aboard!
If you use Discord, please add me there too! fatih#2408


Pointers not working

I am on Windows and everything works great, except the pointers in either ends.
The error message I get when I try to have pointers in both ends or in any of the ends is:
"The system cannot find the file specified."

By pointers, do you mean < and >?
Can you send a screenshot of the label you're trying to make?

By pointers, do you mean < and >?
Can you send a screenshot of the label you're trying to make?

Yes, here it is:
https://i.ibb.co/d4LsFfk/Untitled.png

Yes, here it is:
https://i.ibb.co/d4LsFfk/Untitled.png

I managed to reproduce this, and it seems like < and > are used by the windows shell as special characters. They just need to be escaped with a ^
Can you try with the latest code?

I managed to reproduce this, and it seems like < and > are used by the windows shell as special characters. They just need to be escaped with a ^
Can you try with the latest code?

Whoops, a typo in 32d0224b3f51b08673503970356040d9b81b05f7
But it should be fixed now.

Whoops, a typo in 32d0224b3f51b08673503970356040d9b81b05f7
But it should be fixed now.

Yup, fixed :)
Thank you

Yup, fixed :)
Thank you


Outdated files in the dev-1.15-ko.4 branch

This is a Bug Report
Problem
Outdated files in the dev-1.15-ko.4 branch.
30 files to be modified
need to be compared with dev-1.15-ko.1

[x] content/en/_index.html 1 file changed, 2 insertions(+), 2 deletions(-)
[x] content/en/docs/concepts/architecture/nodes.md 1 file changed, 6 insertions(+), 3 deletions(-)
[x] content/en/docs/concepts/overview/components.md 1 file changed, 12 insertions(+), 7 deletions(-)
[x] content/en/docs/concepts/overview/what-is-kubernetes.md 1 file changed, 8 insertions(+), 8 deletions(-)
[x] content/en/docs/concepts/overview/working-with-objects/field-selectors.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/concepts/overview/working-with-objects/namespaces.md 1 file changed, 11 insertions(+), 4 deletions(-)
[x] content/en/docs/concepts/workloads/pods/init-containers.md 1 file changed, 139 insertions(+), 141 deletions(-)
[x] content/en/docs/concepts/workloads/pods/pod.md 1 file changed, 2 insertions(+), 2 deletions(-)
[x] content/en/docs/reference/_index.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/reference/kubectl/cheatsheet.md 1 file changed, 7 insertions(+), 4 deletions(-)
[x] content/en/docs/setup/_index.md 1 file changed, 7 insertions(+), 4 deletions(-)
[x] content/en/docs/tasks/tools/install-minikube.md 1 file changed, 9 insertions(+), 7 deletions(-)
[x] content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html 1 file changed, 7 insertions(+), 7 deletions(-)
[x] content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html 1 file changed, 2 insertions(+), 2 deletions(-)
[x] content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md 1 file changed, 7 insertions(+)
[x] content/en/examples/application/mysql/mysql-statefulset.yaml 1 file changed, 12 insertions(+), 13 deletions(-)

need to be compared with dev-1.15-ko.3

[x] content/en/docs/concepts/containers/images.md 1 file changed, 5 insertions(+), 6 deletions(-)
[x] content/en/docs/concepts/workloads/pods/init-containers.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/concepts/workloads/pods/pod-overview.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/concepts/workloads/pods/pod.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/reference/glossary/device-plugin.md 1 file changed, 2 insertions(+), 2 deletions(-)
[x] content/en/docs/reference/glossary/kube-proxy.md 1 file changed, 12 insertions(+), 9 deletions(-)
[x] content/en/docs/reference/using-api/api-overview.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/setup/learning-environment/minikube.md 1 file changed, 2 insertions(+), 4 deletions(-)
[x] content/en/docs/setup/production-environment/container-runtimes.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md 1 file changed, 1 insertion(+), 1 deletion(-)
[x] content/en/docs/tutorials/configuration/configure-redis-using-configmap.md 1 file changed, 5 insertions(+)
[x] content/en/docs/tutorials/online-training/overview.md 1 file changed, 2 insertions(+)

1 file to be renamed
need to be compared with dev-1.15-ko.1

[x] R087 content/en/docs/concepts/configuration/scheduler-perf-tuning.md -> content/en/docs/concepts/scheduling/scheduler-perf-tuning.md

0 files to be deleted
Proposed Solution
Use git diff to check what is changed in the upstream. And apply the upstream changes manually
to the content/ko of dev-1.15-ko.4 branch.
For example:
# checkout `dev-1.15-ko.4`
...
# check what is updated in the upstream
git diff dev-1.15-ko.3 dev-1.15-ko.4 -- content/en/docs/concepts/architecture/nodes.md
# apply changes to content/ko
vi content/ko/docs/concepts/architecture/nodes.md
...
# commit and push
...
# make PR to `dev-1.15-ko.4`

Pages to Update
/language ko

/assign

/close


setup npm workspaces, moved project to lib/destack, created nextjs pr…

With this PR it's significantly easier to setup the project for local development.
See CONTRIBUTING.md!

This looks great, but what do you think about renaming lib/destack to pkg/destack.
Or would removing the ./lib dir and putting it in the library in src be better? I think the code structure would be a bit confusing for newcomers.
I suggest something like this:
Src/ -  destack source
Dev/nextjs-project - nextjs app for dev
We could move the src directory(currently inside ./lib/destack/src) to something like ./src/browser/
Ugg autocorrect sucks for writing software related stuff

Sure, something to consider.
I'm not aware of what the convention is or it might just be too early for such a convention as NPM workspaces launched just a few months ago. Will have to look into further.
Everything seems smooth so far but will need more tests before publishing to NPM. If you encounter any issues open an issue or let me know.

Thanks

Looks like yarn workspaces are a bit different to npm's. Npm allows workspaces to be enabled without being private, but yarn workspaces are meant to be only used privately. I might have to use npm for this project.

I'm having some problems with npm workspaces..
doesn't seem to work very well for me..


Missing Key doesn't display if switching language

I hope I am setting this up correctly.
If you have a key that exists in the default resource and not in the language specific resource it will not show the fallback missing key value when using {lex:Loc Key=password}, it shows the default value

Setup a key "password" in the default resx file with a value of password.
Create an Italian translation set for the resource without the translation of password.
Set the language to Italian and you will still see the default value (ex you will see password not key: password)

Expected behavior
I would expect to see the key: password (default behavior for missing key) when the language is set to Italian
I wrote a converter that uses the resource manager to get the resourceset and check that the resource set has the key or not and changes the text based on if the key exists in the selected languages resource set.
I would like to see this in default functionality as using a converter everywhere is cumbersome
I hope this makes sense
Thanks for the great library

Nevermind if you setup your Neutral to have the key: word look you will see that it doesn't exist cause it will show the neutral key


chore: make test-short

Closes https://github.com/celestiaorg/celestia-app/issues/1025
Add the Makefile command test-short which runs unit tests in -short mode. On my machine, make test-short completes in ~15 seconds

Codecov Report

Merging #1192 (847731a) into main (d148af2) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 847731a differs from pull request most recent head 7feaa70. Consider uploading reports for the commit 7feaa70 to get more accurate results

@@           Coverage Diff           @@
##             main    #1192   +/-   ##
=======================================
  Coverage   48.11%   48.11%
=======================================
  Files          72       72
  Lines        4055     4055
=======================================
  Hits         1951     1951
  Misses       1933     1933
  Partials      171      171

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


Pr/nandhini/toggle normalized

Description: Added a new feature to normalize/not normalize confusion matrix data
Fixes #115
Checklist:
You should check all boxes before the PR is ready. If a box does not apply, check it to acknowledge
it.

[x] PRE-COMMIT. You ran pre-commit on all commits, or else, you
ran pre-commit run --all-files at the end.
[x] FRONTEND TYPES. Regenerate the front-ent types if you played with types and routes.
Run cd webapp && yarn types while the back-end is running.
[x] USER CHANGES. The changes are added to CHANGELOG.md and the documentation, if they impact
our users.
[x] DEV CHANGES.

Update the documentation if this PR changes how to develop/launch on the app.
Update the README files and our wiki for any big design decisions, if relevant.
Add unit tests, docstrings, typing and comments for complex sections.

If normalized:

If not normalized:

now, I read "normalized" from the API. Quick question, do we keep track of the history for "normalized" param?


Multipart/related handling improvements

Implements the changes proposed in Jira 1956 to allow chunked encoding of multipart/related requests and make attachment lengths optional. Also addresses Jira 1685 to allow POSTing of multipart/related requests. The code for the latter was in Pull Request 91 but that ran into build problems so I will close that PR.
I'd be very grateful if members of the group could give the code a thorough review if you have time. To help out with that I will attach some review notes to the Jira ticket to give an overview of the changes.

Two years later (and four+ years after I filed COUCHDB-1403 which got duped to this) and this still hasn't been fixed :-(
This is still causing some compatibility issues with Couchbase Lite, viz. this forum thread from a few days ago.

It would be beneficial to my library if the API between POST /db and PUT /db/id were more similar regarding multipart uploads. Currently I can only create a new document with attachments if I know the id I want to use ahead of time.
Or maybe my CouchDB is too far out of date. Has this been fixed in recent versions?

I believe it is still an issue in CouchDB 2.