Error building web image after upgrading to 1.22.5 when nodejs_version set to <18

Is there an existing issue for this?

[X] I have searched the existing issues

Output of ddev debug test
Expand `ddev debug test` diagnostic information
Running bash [-c /tmp/test_ddev.sh]
======= Existing project config =========
These config files were loaded for project ddev-test-project: [/tmp/ddev-test-project/.ddev/config.yaml]
name: ddev-test-project
type: drupal10
docroot: web
php_version: 8.1
webserver_type: nginx-fpm
webimage: ddev/ddev-webserver:v1.22.5
additional_hostnames: []
additional_fqdns: []
database: {mariadb 10.8}
project_tld: ddev.site
use_dns_when_possible: true
composer_version: 2
nodejs_version: 16
default_container_timeout: 120
======= Creating dummy project named  tryddevproject-22659 in ../tryddevproject-22659 =========
OS Information: Linux jornf-kubuntu-vm 5.15.0-89-generic #99-Ubuntu SMP Mon Oct 30 20:42:41 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
User information: uid=1000(jornf) gid=1000(jornf) groups=1000(jornf),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),132(lxd),133(sambashare),999(docker)
DDEV version:  ITEM             VALUE
 DDEV version     v1.22.5
 architecture     amd64
 db               ddev/ddev-dbserver-mariadb-10.4:v1.22.5
 ddev-ssh-agent   ddev/ddev-ssh-agent:v1.22.5
 docker           24.0.7
 docker-compose   v2.23.3
 docker-platform  linux-docker
 mutagen          0.17.2
 os               linux
 router           ddev/ddev-traefik-router:v1.22.5
 web              ddev/ddev-webserver:v1.22.5
PROXY settings: HTTP_PROXY='' HTTPS_PROXY='' http_proxy='' NO_PROXY=''
======= DDEV global info =========
Global configuration:
instrumentation-opt-in=true
omit-containers=[]
performance-mode=none
router-bind-all-interfaces=false
internet-detection-timeout-ms=3000
disable-http2=false
use-letsencrypt=false
letsencrypt-email=
table-style=default
simple-formatting=false
use-hardened-images=false
fail-on-hook-fail=false
required-docker-compose-version=v2.23.3
use-docker-compose-from-path=false
project-tld=
xdebug-ide-location=
no-bind-mounts=false
router=traefik
wsl2-no-windows-hosts-mgt=false
router-http-port=80
router-https-port=443
mailpit-http-port=8025
mailpit-https-port=8026
traefik-monitor-port=10999

======= DOCKER info =========
docker location: -rwxr-xr-x 1 root root 35939040 okt.  26 11:07 /usr/bin/docker
docker version:
Client: Docker Engine - Community
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:07:41 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:07:41 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.25
  GitCommit:        d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
 runc:
  Version:          1.1.10
  GitCommit:        v1.1.10-0-g18a0cb0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
DOCKER_DEFAULT_PLATFORM=notset
======= Mutagen Info =========
======= Docker Info =========
Docker platform: linux-docker
Using Docker context: default (unix:///var/run/docker.sock)
docker-compose: v2.23.3
Using DOCKER_HOST=unix:///var/run/docker.sock
Docker version: 24.0.7
Able to run simple container that mounts a volume.
Docker disk space:
Filesystem                Size      Used Available Use% Mounted on
overlay                 195.3G    170.0G     15.8G  92% /

The ddev-ssh-agent container has been removed. When you start it again you will have to use 'ddev auth ssh' to provide key authentication again.
Network ddev_default removed
Network ddev-ddev-test-project_default removed
Existing docker containers:
CONTAINER ID   IMAGE          COMMAND     CREATED       STATUS    PORTS     NAMES
a0f0d4b4e123   1ffc385c6e71   "/bin/sh"   9 days ago    Created             phpstorm_helpers_PS-232.10227.13
21bf9611e883   d4da20f6619c   "/bin/sh"   5 weeks ago   Created             phpstorm_helpers_PS-232.10072.32
4a12323cc7c3   e7b45c3e2795   "/bin/sh"   6 weeks ago   Created             phpstorm_helpers_PS-232.9921.55
Network ddev_default created
Starting tryddevproject-22659...
Network ddev-tryddevproject-22659_default created
 Container ddev-ssh-agent  Created
 Container ddev-ssh-agent  Started
ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys.
Building project images...
Project images built in 1s.
 Container ddev-tryddevproject-22659-web  Created
 Container ddev-tryddevproject-22659-db  Created
 Container ddev-tryddevproject-22659-web  Started
 Container ddev-tryddevproject-22659-db  Started
Waiting for web/db containers to become ready: [web db]
Starting ddev-router if necessary...
 Container ddev-router  Created
 Container ddev-router  Started
Waiting for additional project containers to become ready...
All project containers are now ready.
Successfully started tryddevproject-22659
Project can be reached at https://tryddevproject-22659.ddev.site https://<IP_ADDRESS>:32963
======== Curl of site from inside container:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 01 Dec 2023 07:49:32 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding

======== curl -I of http://tryddevproject-22659.ddev.site from outside:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Fri, 01 Dec 2023 07:49:32 GMT
Server: nginx
Vary: Accept-Encoding

======== full curl of http://tryddevproject-22659.ddev.site from outside:
Success accessing database... db via TCP/IP
ddev is working. You will want to delete this project with 'ddev delete -Oy tryddevproject-22659'
======== Project ownership on host:
drwxr-xr-x 4 jornf jornf 4096 des.   1 08:48 ../tryddevproject-22659
======== Project ownership in container:
drwxr-xr-x 4 jornf jornf 4096 Dec  1 07:48 /var/www/html
======== In-container filesystem:
Filesystem     Type 1K-blocks      Used Available Use% Mounted on
/dev/sda2      ext4 204797276 178504628  16341208  92% /var/www/html
======== curl again of tryddevproject-22659 from host:
Success accessing database... db via TCP/IP
ddev is working. You will want to delete this project with 'ddev delete -Oy tryddevproject-22659'
Thanks for running the diagnostic. It was successful.
Please provide the output of this script in a new gist at gist.github.com
Running ddev launch in 5 seconds

Please run cleanup after debugging with 'ddev debug testcleanup'

Expected Behavior
When starting projects configured with nodejs_version < 18, the web image should be built.
Actual Behavior
The web image fail to build with:
#14 [web 5/6] RUN npm install -g n
#14 108.1 npm ERR! code EAI_AGAIN
#14 108.1 npm ERR! syscall getaddrinfo
#14 108.1 npm ERR! errno EAI_AGAIN
#14 108.1 npm ERR! request to https://registry.npmjs.org/n failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org
#14 108.1
#14 108.1 npm ERR! A complete log of this run can be found in: /root/.npm/_logs/2023-12-01T07_43_56_789Z-debug-0.log
#14 ERROR: process "/bin/bash -c npm install -g n" did not complete successfully: exit code: 1
------
 > [web 5/6] RUN npm install -g n:
108.1 npm ERR! code EAI_AGAIN
108.1 npm ERR! syscall getaddrinfo
108.1 npm ERR! errno EAI_AGAIN
108.1 npm ERR! request to https://registry.npmjs.org/n failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org
108.1
108.1 npm ERR!
I suspect this is related to https://github.com/ddev/ddev/pull/5521 but I'm not familiar with the internals of ddev.

Workaround:
diff --git a/.ddev/config.yaml b/.ddev/config.yaml
index 9f40beb1..f83e1631 100644
--- a/.ddev/config.yaml
+++ b/.ddev/config.yaml
@@ -16,7 +16,11 @@ mutagen_enabled: false
 use_dns_when_possible: true
 composer_version: "2"
 web_environment: []
-nodejs_version: "16"
+nodejs_version: "18"
+hooks:
+  post-start:
+    - exec-host: ddev nvm install 16
+    - exec-host: ddev nvm use 16

Hi, @jfauske,
This is a DNS issue that we unfortunately cannot fix on the DDEV side.
I'm glad you were able to "fix" it yourself with nvm, you can even remove the line nodejs_version: "18"
Other ways to solve this problem:

Change your DNS servers
Restart your machine
Restart the router

Though, I still don't understand why issue only manifested itself during the image build phase.

That's because the webserver comes with node 18 (DDEV will default to 20 in the next major release), and when you specify a different node version, it tries to get it from registry.npmjs.org - it only needs to do this once.

Yes, and on top of that I forgot about local composer cache and "tricked" myself into believing networking was fine for a few other running projects.
Sorry for the noise and thanks again!

No @rfay , it was not "just" plain-and-simple internet trouble as I was using the VM downgrade/upgrade ddev (i.e sudo apt install ddev=1.22.3 etc) but it only manifested itself during the  ddev build phase.
Only rebooting the Ubuntu 22.04 VM did not resolve the build issue.
After rebooting my hyper-v host where the ubuntu 22.04 VM is running, the build issues were gone.
Will report back if I'm able to consistently reproduce the issue again

It sounds like you had a similar issue to mine, Linux/Docker build-time internet capability.

I had this problem again today with WSL2, I think after computer has gone to sleep. wsl --terminate fixed it.

I see WSL2 in general having trouble with time/date after sleeping, apparently can be fixed with sudo hwclock -s, https://stackoverflow.com/a/66930942/215713
This shows up on WSL2 on the host with sudo apt update, where fails due to timestamp, maybe the cause of problem here.

In my case it was solved by restarting the PC.


Is there no callback function

I noticed that in vue color of vue2 version, there is @ input callback function
Is there no callback function in ckpack/vue color
look forward to your reply

I've tried @input and @inputChange, but unfortunately, they don't work

Thank you for your answer

I noticed that @ update: modelValue will trigger this method continuously during the color selection process, but I need to trigger it only at the last time. My solution is to use anti shake. Do you have a better solution

Yes, thank you for your answer

Yes, thank you for your answer

Yes, the event @update:modelValue fires immediately when the color changes, you need to add your own throttle function

<Sketch v-model="color" @update:modelValue="onColorChange" />  throttle  not work?


New package Polyline: 0.1.0

Registering: Polyline
Repository: https://github.com/NikStoyanov/Polyline.jl
Version: v0.1.0
Commit: 7f8cfad4a5b5781cadce607c5b42162c893fb237
Proposed by: @NikStoyanov
Reviewed by: @NikStoyanov
Reference: https://github.com/NikStoyanov/Polyline.jl/commit/7f8cfad4a5b5781cadce607c5b42162c893fb237#commitcomment-33304372

Please add some compatibility constraints, see https://julialang.github.io/Pkg.jl/v1/compatibility/. Also, are you really using Test and Documenter as dependencies? It looks like you can do without them.

Thanks, that makes sense. I will update the package.

Might wanna enable tagbot

I have just now enabled it. Thanks for the help!


get params from response header

Issue Type
Question
Description
When i call a request from API, it is done via Saga method call which call request method (utils > request). On that metod there is a fetch, and response Promise object is resolved by json() method and body in json format is returned to Saga.
My problem is that i had a response header 'Last-Modified' and i want to store it in reducer to use in next requests. But i have no idea how to pass it from request method to Saga, to save it by action in reducer
Steps to reproduce
(Add link to a demo on https://jsfiddle.net or similar if possible)
Versions

React-Boilerplate (see package.json): 3.7.0
Node/NPM: 10.15.1/6.7.0
Browser: all

Sorry, all questions should be taken to Stack Overflow

@daniel-pietryga your question seems important to me. Were you able to resolve that? I may need to do that in the future I think...

This ought to be fairly straightforward by making changes to request.js. The cleanest way would probably involve switching to using async/await syntax in function request().

@MaxiSantos , I do exactly what @julienben wrote - make asyc method in request file, and returned to saga a map with response body and value of headers


chore(ci): replace deprecated set-output commands

Issue number: #1591
Summary
Replace deprecated save-state and set-output commands to the new format: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter
Changes

Please provide a summary of what's being changed

User experience

Please share what the user experience looks like before and after this change

Checklist
If your change doesn't seem to apply, please leave them unchecked.

[x] Meet tenets criteria
[x] I have performed a self-review of this change
[x] Changes have been tested
[ ] Changes are documented
[x] PR title follows conventional commit semantics

Is this a breaking change?
RFC issue number:
Checklist:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

This is awesome, thank you for taking the time! I’ll review it as soon as I
can tomorrow ;)
On Mon, 27 Feb 2023 at 09:08, Cibin Mathew @.***> wrote:

@cibinmathew https://github.com/cibinmathew requested review from
@awslabs/aws-lambda-powertools-python on: #1957
https://github.com/awslabs/aws-lambda-powertools-python/pull/1957 ci:
replace deprecated set-output commands as a code owner.
—
Reply to this email directly, view it on GitHub
https://github.com/awslabs/aws-lambda-powertools-python/pull/1957#event-8612768321,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZPQBA6WBVDLZSL7VDJ2IDWZROIXANCNFSM6AAAAAAVIXLKVY
.
You are receiving this because your review was requested.Message ID:
<awslabs/aws-lambda-powertools-python/pull/1957/issue_event/8612768321@
github.com>

Looks great, merging. Thanks a lot for taking the time @cibinmathew - these are quality of life governance improvements that we appreciate very much.


Generate constants directly in CreateDebugInlinedAt

Using the ConstantManager attempts to regenerate the DefUseManager
which is not valid during inlining.

@s-perron @jaebaek I have added a test, but I have added it to inline_test.cpp since that is the pass during which the failure occurred and so it was trivial to replicate the test conditions.

I am not sure how we can add a unit test for this.

The idea is that this function should not build the analysis if it was not already available.  The test can call the function that was changed with a much smaller spir-v module.  Create an inlined at instruction, and expect that the analysies are still invalid.  They you can do another test where the constant manager is build before creating the instruction and then expect that it is valid afterwards.
I would much prefer the more focused unit test.

I am not sure what is going on with these failures. They appear to be due to github failing to clone repos. I am not sure what to do about that.

Looks like a recent change to glslang build has broken shaderc smoke test :(


Updated codebase to pydantic>=2.0

Fixes #63

Codecov Report
Patch coverage: 78.48% and project coverage change: -16.97 :warning:

Comparison is base (0b3b1a5) 84.46% compared to head (dfb0246) 67.49%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main      #75       +/-   ##
===========================================
- Coverage   84.46%   67.49%   -16.97%
===========================================
  Files          51       24       -27
  Lines        1873     1166      -707
  Branches      220      154       -66
===========================================
- Hits         1582      787      -795
- Misses        230      332      +102
+ Partials       61       47       -14

Flag
Coverage Δ

Linux
58.80% <42.66%> (-24.14%)
:arrow_down:

Windows
54.00% <42.66%> (-26.55%)
:arrow_down:

core
?

examples
67.40% <78.48%> (+0.11%)
:arrow_up:

macOS
67.40% <78.48%> (-16.31%)
:arrow_down:

src
65.02% <78.48%> (-13.82%)
:arrow_down:

tests
86.71% <ø> (-4.71%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

examples/tests/pipelines/test_mnist_network.py
92.30% <ø> (ø)

examples/tests/pipelines/test_mnist_notebook.py
92.30% <ø> (ø)

src/saf/collect/file.py
49.18% <0.00%> (-3.28%)
:arrow_down:

src/saf/process/test.py
51.06% <0.00%> (-40.43%)
:arrow_down:

src/saf/forward/disk.py
73.52% <50.00%> (-14.71%)
:arrow_down:

src/saf/process/regex_mask.py
50.00% <50.00%> (-35.19%)
:arrow_down:

src/saf/process/shannon_mask.py
41.17% <57.14%> (-47.06%)
:arrow_down:

src/saf/forward/test.py
47.16% <66.66%> (-39.63%)
:arrow_down:

src/saf/models.py
82.17% <86.79%> (-3.12%)
:arrow_down:

src/saf/collect/beacons.py
73.91% <100.00%> (ø)

... and 2 more

... and 30 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Multiple precompiled assemblies with the same name Castle.Core.dll If Mirror also installed

[Error] Multiple precompiled assemblies with the same name Castle.Core.dll included or the current platform. Only one assembly with the same name is allowed per platform. (Assets/Mirror/Tests/Common/Castle.Core.dll)
[Error] Multiple precompiled assemblies with the same name Castle.Core.dll included or the current platform. Only one assembly with the same name is allowed per platform<EMAIL_ADDRESS>I had to delete the test folders to get gamelift working.

In short term, you can delete castle.core.dll in the gamelift package. We'll look into how to implement a longer term fix.

I've captured an internal feature request for improving our dependency resolution if possible. As this issue has a workaround and is quite old, I'm closing out this issue.


feat(#224): Update jtcop version up to 0.1.18

Update jtcop version - 0.1.18
Closes: #224

PR-Codex overview
Detailed summary

Updated the version of jtcop-maven-plugin from 0.1.16 to 0.1.18 in pom.xml.
Added @SuppressWarnings("JTCOP.RuleCorrectTestName") annotation to JavaTestClasses enum in JavaTestClasses.java file.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@rultor merge

@volodya-lombrozo OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@volodya-lombrozo Done! FYI, the full log is here (took me 3min)


hardware.nvidia.forceFullCompositionPipeline disables second monitor

Describe the bug
By enabling hardware.nvidia.forceFullCompositionPipeline, it fixes the screen tearing as expected, but disables a 2nd monitor.
Steps To Reproduce
Steps to reproduce the behavior:

Copy the default nvidia settings from the wiki
Change open to false and forceFullCompositionPipeline to true
Rebuild and reboot
Observe that only one screen is turned on and detected by nvidia

Expected behavior
Second monitor works as before.
Screenshots
Additional context
Both monitors work when hardware.nvidia.forceFullCompositionPipeline = false.
Notify maintainers
@schuelermine

Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.55, NixOS, 23.11 (Tapir), 23.11.20231006.87828a0`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.17.0`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Nevermind, I can enable second monitor in nvidia settings. Still weird that forceFullCompositionPipeline disables it.

Changing settings in the GUI doesn't preserve between reboots. Is there a nix option for controlling nvidia-settings?

When exporting the xserver configuration from nvidia settings, both monitors are in screen section metamodes:
    Option         "metamodes" "HDMI-0: nvidia-auto-select +1920+0, DVI-D-0: nvidia-auto-select +0+0"

but with hardware.nvidia.forceFullCompositionPipeline = true, no monitors are specified, so I assume only the first monitor it founds will work:
  Option         "metamodes" "nvidia-auto-select +0+0 {ForceFullCompositionPipeline=On}"

My current workaround is to configure FullCompositionPipeline using services.xserver.screenSection option.
services.xserver.screenSection = ''   Option "metamodes" "DP-0: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, HDMI-0: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}" '';


The second to last Blob3.txt in the diagram under Create should be Blob5.txt because Blob3.txt has already been created once.

The second to last Blob3.txt in the diagram under Create should be Blob5.txt because Blob3.txt has already been created once.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 98acfeaa-38a5-dbb6-c717-4fcefe854ffb
Version Independent ID: 3efdd861-cb2a-3733-35df-65e0473dcde4
Content: Change feed in Azure Blob Storage
Content Source: articles/storage/blobs/storage-blob-change-feed.md
Service: storage
Sub-service: blobs
GitHub Login: @tamram
Microsoft Alias: tamram

Thanks for reporting this. I have assigned the issue to the content author to investigate further and update the document as appropriate.

The diagram has been updated and the change should go live in the next day.
#please-close


fix issue 1915 and repeated link instance key for package gdb

https://github.com/gogf/gf/issues/2251

Codecov Report
Base: 76.51% // Head: 76.58% // Increases project coverage by +0.06% :tada:

Coverage data is based on head (89e9784) compared to base (63c3e83).
Patch coverage: 84.21% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2250      +/-   ##
==========================================
+ Coverage   76.51%   76.58%   +0.06%
==========================================
  Files         582      579       -3
  Lines       48389    48069     -320
==========================================
- Hits        37027    36815     -212
+ Misses       9334     9246      -88
+ Partials     2028     2008      -20

Flag
Coverage Δ

go-1.15-386
76.55% <84.21%> (+0.04%)
:arrow_up:

go-1.15-amd64
?

go-1.16-386
76.52% <84.21%> (-0.02%)
:arrow_down:

go-1.16-amd64
?

go-1.17-386
?

go-1.17-amd64
?

go-1.18-386
?

go-1.18-amd64
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

contrib/drivers/pgsql/pgsql.go
64.76% <76.92%> (+0.47%)
:arrow_up:

database/gdb/gdb.go
66.84% <100.00%> (+2.67%)
:arrow_up:

database/gdb/gdb_core_config.go
69.10% <100.00%> (+4.39%)
:arrow_up:

os/gspath/gspath_cache.go
84.21% <0.00%> (-10.53%)
:arrow_down:

os/gfsnotify/gfsnotify_watcher_loop.go
78.15% <0.00%> (-7.57%)
:arrow_down:

net/gtcp/gtcp_pool.go
72.22% <0.00%> (-3.34%)
:arrow_down:

os/gfsnotify/gfsnotify_watcher.go
81.51% <0.00%> (-2.53%)
:arrow_down:

container/gtree/gtree_avltree.go
95.40% <0.00%> (-0.58%)
:arrow_down:

contrib/drivers/oracle/oracle.go

contrib/config/kubecm/kubecm.go

... and 7 more

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Pimoroni Pan-Tilt Hat support

Would it be possible to add support for the Pimoroni Pan-Tilt Hat?
Python API at https://github.com/pimoroni/pantilt-hat

Currently this project supports pipan and servoblaster methods to control pan and tilt. Both these methods support a command pipe that the web software uses to send down the instructions to control pan and tilt. For example, with Pipan the web software writes to FIFO_pipan the command  "servo $pan $tilt" (where $pan and $tilt are the pan and tilt values).
The pimoroni hat uses i2c to send commands which might be a little tricky to use directly. However they have a library which gives access to the functions from python.
So a good approach would be to have a simple python program which runs, waits on a pipe for commands (which could be the existing pipan ones) on a pipe and then activates the appropriate pimoroni function. This would mean the web software would be unchanged and the pimoroni support would just be a separate python program.
I don't have a pimoroni hat to do any development but I can give you some help with this approach if you need it. If this works out I can include any python program with the distribution.

https://learn.sparkfun.com/tutorials/setting-up-the-pi-zero-wireless-pan-tilt-camera/all
useful?
@roberttidey, might be interesting for you also?

I made a simple script pipan_pipe.py (after installing python libraries)
#!/usr/bin/env python

import time
import os, sys
import pantilthat

while True:
  pipein = open("/var/www/html/FIFO_pipan", 'r')
  line = pipein.readline()
  line_array = line.split(' ')
  if line_array[0] == "servo":
    pan = float(line_array[1])
    tilt = float(line_array[2])
    angle_pan = round(pan/255*180) - 90
    angle_tilt = round(tilt/255*180) - 90
    pantilthat.pan(angle_pan)
    pantilthat.tilt(angle_tilt)
  pipein.close()

That sounds good.


Add Support for Legacy IC2

What is this PR?
This PR adds functionality in Dev Env and the mod itself to support multiple IC2 versions, even if they require different patches, allowing IC2-Patcher to support pretty much any IC2 version!
Mod changes:
Mod itself didn't change a lot. Extraction of IC2 version was added, to allow the mod to choose from multiple patches packs, for supported versions, and mcmod.info was updated to include URL to this Github Repo, and added small description of the mod.
Currently tested and suported versions:

2.8.164
2.8.221 and above

OPINION REQURED - IC2 Version extraction method
Due to limitations of ASM Plugin being loaded so early, Forge ModList isn't available. Lazy Loading ASM Plugin results in 2 to 5 patches not being loaded, as those classes were already loaded. Specifically WorldData patch and TileEntityFluidPipe patches.
Because of those limitations, I decided to extract the version from IC2 Jar mcmod.info file itself. I wanted to avoid this solution, but I wasn't able to make anything else work.
If this is an issue I understand, however I don't think multiple-version support in a single jar would be possible otherwise.
Dev Enviroment Changes
Structure
Structure of the dev enviroment was changed.  Patches are now stored as folders with version range in the name.
Example folder name: patches[2.8.164,2.8.165]
1st Version is inclusive, 2nd exclusive. Placing + as 2nd version will result in any version above or equal to 1st one being accepted. Only used for 221+.
Procedures // Tasks
Some of the tasks were modified to make this PR to work, additionally updating some of the plugins to newer versions.
Changelist:

Setup was moved to its own group, easier to find initial setup task.
JEI was changed to compileonly, to make the dev game launch.
Some changes were made to improve stability of the dev game launch, however its not perfect and still missing all textures.
Added few new tasks to make this PR work.
Changed ApplyPatches mode to Offset, so there is higher chance base patches work on wider version range.

The way to change IC2 versions for testing, creating new patches and compiling the mod had also changed. Here are the procedures on how to change IC2 versions, add support for new version and actually compiling the mod itself.
Changing version task list:

Change IC2 version in Gradle Properties
Run Setup, if changing to already supported version and it fails, run it again, for some reason that fixes it.
If adding support for new version, and it fails to compile with previous patches
2a. - Run sourceJar task in Base
2b. - Make changes for it to compile
2c. - Create new patches folder if required, in the schema mentioned in section above.
2d. - run GeneratePatches in Base
2e. - run Setup again
Create new patches folder if required, in the schema mentioned in section above. If patches for other version work on this one, you can either copy the folder with patches or rename the folder with those patches to include new version in it's version range.

Compiling the mod itself

Run GeneratePatches in Patched (as always)
Run GenerateBinPatches in Patched (to generate patches in generatedResources directory)
Make sure generatedResources don't include duplicates from the older patch structure.
Run Build / ReleaseJar

And I think that's it! Hope its good-enough to be merged 😄

I hope it get accepted m8

Nice work! After testing, everything seems to function as expected.


Add license tag

Allow third-party tools (e. g., PyPI or pyp2rpm) to get the license details in a simple way.

Thanks 👍


WIP: Integrate Tekton for Kfserving CI test

What this PR does / why we need it:
Integrate Tekton for Kfserving CI test
The PR is not ready for reviewing now....

Seems we need to suspend this due to https://github.com/kubeflow/testing/issues/736, or we need better solution to review the CI process and check logs.

@jinchihe what's the status here? we don't have an overall owner and infrastructure support for Tekton based tests?

@jinchihe what's the status here? we don't have an overall owner and infrastructure support for Tekton based tests?

Seems the kubeflow/testing#736 has been addressed, we can resume the task now. Thanks.

@jinchihe I think this can be closed now?


KSearch Beta

Description
Add KSearch Beta Documentation
Testing instructions
Preview link:
Checklist

[x] Review label added
[x] PR pointed to correct branch (main for immediate publishing, or a release branch: e.g. release/gateway-3.2, release/deck-1.17)

@haydenlam I'm going to cherry pick this update into my PR (#6655), so all the Search doc changes will be in one place and easy to merge come release time.

Completed the cherry-pick to #6655 , so I'll close this PR.


WifiWizard2.getConnectedSSID() NOT working with Android >= 8.1

Prerequisites
Check all boxes if you have done the following:

[X] Checked that your issue isn't already filed: https://github.com/tripflex/wifiwizard2/issues
[ ] Make sure you fill out the Issue Type below

Issue type
Select all that apply

[X] Bug
[ ] Enhancement
[ ] Task
[ ] Question
[ ] Other

Description
I tried with permissions also but always return "unknown ssid"
Someone has a solution ?
ps. for iOS no problems
Versions
3.1.0

Duplicate issue, please continue discussion in #63


Require map keys to be homogenous to avoid confusion between num and string type

The discussion about possibly sorting the output of the keys command was side-tracked by my observation that map keys can be heterogeneous types. Which is why I'm opening this issue. Very few programming languages allow heterogeneous key types. And most don't allow heterogeneous value types but that's not what this issue is about.
The primary problem for a language like Elvish is that numbers are treated as strings unless in an explicit numeric context such as addition. The problem is that Elvish map keys are inherently type agnostic. Thus it is possible to accidentally create two keys that were intended to be identical but are not. For example:
elvish> var k1 = 1
elvish> var k2 = (num 1)
elvish> var m = [&$k1='string 1' &$k2='number 1']
elvish> pprint $m
[
 &(num 1)=	'number 1'
 &1=	'string 1'
]

The confusion between numbers as strings and numbers as the num type is only the most likely cause of problems. There are other, slightly less likely to occur, examples such as using a list as a map key when an element of the list was intended as the key.
My original idea was to make inserting a map key whose type is different from an existing map key a run-time exception worthy event. Primarily to avoid complicating the syntax to include some form of declaration of the key type. I'm not convinced that is the best long term course of action. However, I believe it is preferable to the current situation that can silently elide mistakes involving numbers as strings and the Elvish num type.

Very few programming languages allow heterogeneous key types

I think at least Java, Python, Ruby, Lua, Lisp do

@lispnik, I can only speak to Python from my personal experience. That includes resolving a bug due to inserting a map a key that should have been a number rather than a string. Allowing heterogeneous key types is more likely, in my experience, to result in unexpected behavior than value. I invite you to provide some concrete examples where heterogenous map keys are useful and justify such flexibility.

See also issue #1025 about sorting the output of the keys command and the fact that order doesn't support ordering heterogenous value types.


pandas.option_context false positive: 'Expect no arguments to "option_context" constructor'

Environment data

Language Server version: 2022.2.1 (pyright 618f54ed)
OS and version: OS X 11.6
Python version (& distribution if applicable, e.g. Anaconda): 3.9.4, 3.8.12

Expected behaviour
Should not give a warning when passing arguments to pandas.option_context
Actual behaviour
Gives error: Expect no arguments to "option_context" constructor
Logs
(omitting for now, let me know if it's useful)
Code Snippet / Additional information
Error happens on line 3:
import pandas as pd

with pd.option_context('display.max_rows', 10):
    print(pd.DataFrame(list(range(50))))

vscode screenshot:

Problem occurs with these versions:

pandas=1.4.0, python 3.9.4
pandas=1.3.5, python 3.8.12

(I didn't test other versions or combinations.)

Thanks for the report. Will investigate this.

it is an issue with our type stub.
def __init__(self, *args): ...

stub assumes option_context get no arguments unlike actual decl above.


remaining BiocCheck issues

Remainin BiocCheck errors:

[x] "At least 80% of man pages documenting exported objects must have runnable examples. The following pages do not:"
[x] "Maintainer must register at the support site; visit https://support.bioconductor.org/accounts/signup/ ."

@AlexanderPico, for the second item, I am signed up (I think, because it does not give that error for BridgeDbR). Can you plz sign up too?

How do you run that? I want to see "The following pages do not:"
I tried this:
install.packages("BiocCheck")
  Warning in install.packages :
    package ‘BiocCheck’ is not available (for R version 3.3.3)

Do I have to update to 3.4 to run this check?  I'd rather not so that I can easily test/dev for support back to 3.3.

It's a BioConductor package, so you need to source their script first... See the BiocCheck package page on BC... (From phone)

fixed with https://github.com/wikipathways/rwikipathways/commit/3e76c935c2bede285fa8149ac335bf4ae2f01a42


Add another volume example

That should probably be Dir.pwd, and I'm not sure this is something people should be doing to start with. What is your goal?

Codecov Report

Merging #260 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #260   +/-   ##
=======================================
  Coverage   33.77%   33.77%
=======================================
  Files           2        2
  Lines         228      228
=======================================
  Hits           77       77
  Misses        151      151

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 08fbc00...a1ca8bf. Read the comment docs.

Closing this PR due to inactivity. Please submit a new PR if updates are still needed. Thanks.


rasa_addons.core.tracker_stores.AnalyticsTrackerStore not found

Describe the bug
When using rasa-for-botfront:v1.9.0-bf.2 it shows the message:
/opt/venv/lib/python3.6/site-packages/rasa/utils/common.py:351: UserWarning: Tracker store with type 'rasa_addons.core.tracker_stores.AnalyticsTrackerStore' not found. Using InMemoryTrackerStore instead.
It seems can not find the Addons of botfront custom Tracker Store. Maybe the name was changed? or it is not longer in use?
I have it configure in my endpoints as:
tracker_store:
  store_type: rasa_addons.core.tracker_stores.AnalyticsTrackerStore
  url: 'http://botfront-api:8080'
  project_id: 'bf'

To Reproduce
I was using rasa-for-botfront 1.7.1 and upgrade it to 1.9.0.
Expected behavior
Keep using Botfront custom TrackerStore
NOTE: I tried to open the issue directly in rasa-for-botfront repository but issues are not available there.
thanks in advance and all the best

This version is not compatible with 0.21, please roll back to 1.7.1

Hi @znat
sorry for reopen the ticket.
version 0.22.1 is compatible?
https://hub.docker.com/layers/botfront/botfront/v0.22.1/images/sha256-f2b6cfa67d001b5f4dbe7fd1134839a7f2ea017bc68f341d0163a3ef055feec7?context=explore
in our use case it is better to work together with Rasa 1.9.x because it fix an issue with FormAction.
thanks and all the best


Add kernel commandline parameter for specifying the tink-worker image:

Description

This allows flexibility from where to pull the tink worker container image. This will be needed if the env var DOCKER_REGISTRY is not specified.
Why is this needed

Fixes: #
How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:
I have:

[ ] updated the documentation and/or roadmap (if required)
[ ] added unit or e2e tests
[ ] provided instructions on how to upgrade

This pr is alright[^1] but I kinda want to push back on it in that I feel like we shouldn't be specifying the worker to use. Letting that change due to a boots update/deployment creates a coupling that doesn't really make sense.
[^1]: my only nit for the code at hand is that location shouldn't be part of the comments, instead just using tink-worker image

This pr is alright1 but I kinda want to push back on it in that I feel like we shouldn't be specifying the worker to use. Letting that change due to a boots update/deployment creates a coupling that doesn't really make sense.
Footnotes

my only nit for the code at hand is that location shouldn't be part of the comments, instead just using tink-worker image ↩

Sorry, I dont know if i follow. the env DOCKER_REGISTRY already allows us the ability to specify from where to pull the tink worker. How would this be any different from that? This just decouples DOCKER_REGISTRY from the tink worker location so that an empty DOCKER_REGISTRY doesnt break. See bootkit in hook here

Sorry, I dont know if i follow. the env DOCKER_REGISTRY already allows us the ability to specify from where to pull the tink worker. How would this be any different from that? This just decouples DOCKER_REGISTRY from the tink worker location so that an empty DOCKER_REGISTRY doesnt break. See bootkit in hook here

Right but boots isn't prescribing which tink-worker image should be used, this PR changes that. Boots should not gain this new policy/ability. The image being booted should either know what tink-worker it wants to use (because its been tested with it), or it should know that it wants to use :latest or maybe it figures that out from some other means.

Sorry, I dont know if i follow. the env DOCKER_REGISTRY already allows us the ability to specify from where to pull the tink worker. How would this be any different from that? This just decouples DOCKER_REGISTRY from the tink worker location so that an empty DOCKER_REGISTRY doesnt break. See bootkit in hook here

Right but boots isn't prescribing which tink-worker image should be used, this PR changes that. Boots should not gain this new policy/ability. The image being booted should either know what tink-worker it wants to use (because its been tested with it), or it should know that it wants to use :latest or maybe it figures that out from some other means.

"Boots should not gain this new policy/ability." Sorry, I'm not seeing why this should be the case. There is already "coupling" as you say between many Boots env vars -> cmdline args -> bootkit.
Why does hard-coding the image name tink-worker matter?
Also, this change is optional and does not change the existing behavior. So the previous behavior of tink-worker:latest in conjunction with a specific registry is still available.

Sorry, I dont know if i follow. the env DOCKER_REGISTRY already allows us the ability to specify from where to pull the tink worker. How would this be any different from that? This just decouples DOCKER_REGISTRY from the tink worker location so that an empty DOCKER_REGISTRY doesnt break. See bootkit in hook here

Right but boots isn't prescribing which tink-worker image should be used, this PR changes that. Boots should not gain this new policy/ability. The image being booted should either know what tink-worker it wants to use (because its been tested with it), or it should know that it wants to use :latest or maybe it figures that out from some other means.

"Boots should not gain this new policy/ability." Sorry, I'm not seeing why this should be the case. There is already "coupling" as you say between many Boots env vars -> cmdline args -> bootkit.

Because boots doesn't need to provide the tink worker image arg in order to get its job done, to boot an image. We've been overloading stuff into boots because its convenient but we shouldn't continue to add on top. Solving this outside of boots could also open up the space to solve other use cases (I'm thinking of what we discussed in the last contributor's meeting about ssh-keys and an external url to fetch things).
IMO we should be working towards removing these. I can imagine doing this right and having just 1 cmdline argument for "fetch things you need to know from this url", where we can provide registry info & creds, images to use, extra services to enable maybe...

Why does hard-coding the image name tink-worker matter?
Also, this change is optional and does not change the existing behavior. So the previous behavior of tink-worker:latest in conjunction with a specific registry is still available.

It just doesn't seem like a good enough benefit compared to the cost. It doesn't help out with wanting to roll out new versions of tink-worker safely if it means we need a redeployment of boots and doing so now makes it live for everything boot that will go through boots. Solving the "how to get inputs into the live environment" outside of boots is better done outside of boots.
Optional features are worse than required ones imo, because now you have to account for both scenarios (I'm keenly aware of this after going through and removing all the mirror stuff from conf/mirror.go in #258).

Hey @mmlb, thanks for the back and forth. I'm going to close this one and see about solving this a different way.


fixed warnings #107 #109

Title changed to TensorMap instead of React App.
solves #140
@orionpax00 @ivantha @keshan please review.

Fixed warnings #107 #109
warnings from

AddData.jsx
Table.jsx
VisualizeData.jsx
VisualizeData.styles.js
src/index.js (material-ui upgrade)

Closing as stale.


JAVA-26778: Changes made for Upgrade jaxb2-maven-plugin to latest ver…

…sion

retest this please


Name added to contributors list

Name added to contributors list

please review
use as guide - https://akrabat.com/the-beginners-guide-to-contributing-to-a-github-project/


chore(main): release 2.1.0

:robot: I have created a release beep boop
2.1.0 (2023-09-16)
Features

support Nest.js 10 (#27) (7ac149c)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/apricote/nest-pg-boss/releases/tag/v2.1.0 :sunflower:


Fixing error for suggestions.text

replaced s.text with s.replacements

Great, thanks!

Great, thanks!


[WFCORE-6932] Upgrade commons-lang3 from 3.15.0

Jira issue: https://issues.redhat.com/browse/WFCORE-6932
Note: WildFly Core drives the commons-lang3 version used in WildFly Full.

Core -> WildFly Preview Integration Build 13808 outcome was FAILURE using a merge of 3e8382850d0eb3057855a34c69b0276283e9cf44
Summary: Tests failed: 1 (1 new), passed: 4915, ignored: 86 Build time: 03:07:36
Failed tests
org.wildfly.test.integration.elytron.oidc.client.subsystem.OidcWithSubsystemConfigTest(layers-test): org.wildfly.test.integration.elytron.oidc.client.subsystem.OidcWithSubsystemConfigTest(layers-test).org.wildfly.test.integration.elytron.oidc.client.subsystem.OidcWithSubsystemConfigTest: java.lang.AssertionError
	at org.wildfly.test.integration.elytron.oidc.client.OidcBaseTest.sendRealmCreationRequest(OidcBaseTest.java:136)
	at org.wildfly.test.integration.elytron.oidc.client.subsystem.OidcWithSubsystemConfigTest$KeycloakAndSubsystemSetup.setup(OidcWithSubsystemConfigTest.java:295)
	at org.jboss.as.arquillian.container.ServerSetupObserver$ServerSetupTaskHolder.setup(ServerSetupObserver.java:249)
	at org.jboss.as.arquillian.container.ServerSetupObserver.executeSetup(ServerSetupObserver.java:180)
	at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:113)
	at jdk.internal.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at jdk.internal.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at jdk.internal.reflect.GeneratedMethodAccessor62.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at jdk.internal.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at jdk.internal.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at jdk.internal.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at jdk.internal.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
------- Stdout: -------
 [0m11:10:34,976 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/integration/elytron-oidc-client/target/wildfly/standalone/data/content/9f/f4e3a708059f9fba4f7771e88c9efe932c0848/content
 [0m [0m11:10:34,979 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "arquillian-service" (runtime-name: "arquillian-service")
 [0m [33m11:10:35,209 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.arquillian-service" is using a private module ("org.jboss.as.jmx") which may be changed or removed in future versions without notice.
 [0m [33m11:10:35,209 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.arquillian-service" is using a private module ("org.jboss.as.server") which may be changed or removed in future versions without notice.
 [0m [33m11:10:35,209 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.arquillian-service" is using a private module ("org.wildfly.common") which may be changed or removed in future versions without notice.
 [0m [33m11:10:35,209 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.arquillian-service" is using a private module ("org.jboss.jandex") which may be changed or removed in future versions without notice.
 [0m [33m11:10:35,209 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.arquillian-service" is using a private module ("org.wildfly.security.manager") which may be changed or removed in future versions without notice.
 [0m [33m11:10:35,231 WARN  [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0013: Deployment arquillian-service contains Jakarta Contexts and Dependency Injection annotations but no bean archive was found (no beans.xml or class with bean defining annotations was present).
 [0m [0m11:10:35,242 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "arquillian-service" (runtime-name : "arquillian-service")
 [0m [0m11:13:56,570 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host default-host stopping
 [0m [0m11:13:56,573 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment arquillian-service (runtime-name: arquillian-service) in 5ms
 [0m [0m11:13:56,575 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
 [0m [0m11:13:56,577 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to <IP_ADDRESS>:8080
 [0m [0m11:13:56,578 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0004: Undertow 2.3.15.Final stopping
 [0m [0m11:13:56,586 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Preview 34.0.0.Beta1-SNAPSHOT (WildFly Core 26.0.0.Beta1-SNAPSHOT) stopped in 21ms
 [0m [0m11:13:56,587 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Preview 34.0.0.Beta1-SNAPSHOT (WildFly Core 26.0.0.Beta1-SNAPSHOT) starting
 [0m [0m11:13:56,722 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
 [0m [0m11:13:56,750 INFO  [org.wildfly.extension.elytron.oidc._private] (ServerService Thread Pool -- 35) WFLYOIDC0001: Activating WildFly Elytron OIDC Subsystem
 [0m [33m11:13:56,754 WARN  [org.wildfly.extension.elytron] (MSC service thread 1-4) WFLYELY00023: KeyStore file '/opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/integration/elytron-oidc-client/target/wildfly/standalone/configuration/application.keystore' does not exist. Used blank.
 [0m [33m11:13:56,754 WARN  [org.wildfly.extension.elytron] (MSC service thread 1-3) WFLYELY01084: KeyStore /opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/integration/elytron-oidc-client/target/wildfly/standalone/configuration/application.keystore not found, it will be auto-generated on first use with a self-signed certificate for host localhost
 [0m [0m11:13:56,762 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 37) WFLYIO001: Worker 'default' has auto-configured to 8 IO threads with 64 max task threads based on your 4 available processors
 [0m [0m11:13:56,767 INFO  [org.jboss.as.jaxrs] (ServerService Thread Pool -- 38) WFLYRS0016: RESTEasy version 7.0.0.Alpha2
 [0m [0m11:13:56,771 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 36) WFLYCLINF0001: Activating Infinispan subsystem.
 [0m [0m11:13:56,772 INFO  [org.jboss.as.ejb3] (MSC service thread 1-3) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 16 (per class), which is derived from thread worker pool sizing.

@ehsavoie @fjuma @jimma Please review. The uses of this library are in Artemis, Elytron tool and the WS stack (CXF and Apache Velocity used by CXF).

Thanks @fjuma @ehsavoie @jimma @bstansberry


Improve file system blob loader and generic loader

Add support for passing a specific file to the file system blob loader
Allow specifying a class parameter for the parser for the generic loader

class AudioLoader(GenericLoader):
  parser: MyAudioParser

The intent of the GenericLoader is to provide on-ramps from different sources (e.g., web, s3, file system).
An alternative is to use pipelining syntax or creating a Pipeline
FileSystemBlobLoader(...) | MyAudioParser

Actually this won't work -- need to make it possible to lazily instantiate -- one sec


Include weakly labeled elements when exporting labeled data

Is your feature request related to a problem?
When exporting labeled data, weak labels that were used for training are not included in the file.
What is the expected behavior?
Include weak labels when exporting labeled data. Mark them so the user can decide whether to use them or not.
Additional context (if any):

Weak labels are already available to be download on the system's UI. Closing this issue.


Fix generating timestamps for the files on FS.

I'm wondering if we can have tests that catch that verify this behaviour. It's tricky.

I've created another PR based on rpki-commons, it may supersede this one.

Too hard to get it right


 path is broken on Bash for Windows (blocks building NuGet packages)

Issue Title
<ProjectAssetsFile> path is broken on Bash for Windows (blocks building NuGet packages)
General
dotnet --version: 2.1.300
My project builds properly on both vanilla Windows and Linux. However, the build fails on Bash for Windows:
/usr/share/dotnet/sdk/2.1.300/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error : Assets file '/mnt/c/repos/my-repo/MyProject/C:/repos/my-repo/MyProject/obj/project.assets.json' not found. Run a NuGet package restore to generate this file. [/mnt/c/repos/my-repo/MyProject/MyProject.csproj]
From the diagnostic build log:
ProjectAssetsFile = /mnt/c/repos/my-repo/MyProject/obj/project.assets.json

...

Property reassignment: $(ProjectAssetsFile)="/mnt/c/repos/my-repo/MyProject/C:/repos/my-repo/MyProject/obj/project.assets.json" (previous value: "C:\repos\my-repo\MyProject\obj\project.assets.json") at /usr/share/dotnet/sdk/2.1.300/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets (28,5)

The line in question:
<ProjectAssetsFile>$([MSBuild]::NormalizePath($(MSBuildProjectDirectory), $(ProjectAssetsFile)))</ProjectAssetsFile>
So somehow ProjectAssetsFile is being reassigned from /mnt/c/repos/my-repo/MyProject/obj/project.assets.json to C:\repos\my-repo\MyProject\obj\project.assets.json without the reassignment appearing in the diagnostic log.
This is a blocker for local builds on Windows--my repository must be built from bash for reasons unrelated to the project described above.

Here's a minimal repro. Build from Bash for Windows using dotnet build or dotnet build ./BuildRepro.sln.
BuildRepro.zip

Weird: I've suddenly stopped seeing this error, both in my original project and in the repro project that I attached. Not sure why. Closing, will re-open if I encounter this again.


8.0.0: Improved Extensibility

Enhancements

Added Composition.IExtension to support extensibility via IoC.
Added Data.IFeature and Data.IFeatures to facilitate creation of rich fluent APIs with support of MooVC.Generators assembly.
Added Linq.IEnumerableExtensions.IsNullOrEmpty extension for checking if an enumerable is null or has no elements.
Moved Collections.Generic.EnumerableExtensions to Linq.IEnumerableExtensions (Breaking Change).
Moved Collections.Generic.EnumerableExtensions.Snapshot to Linq.IEnumerableExtensions.ToArrayOrEmpty (Breaking Change).
Moved Collections.Generic.ObjectExtensions.AsEnumerable to Linq.ObjectExtensions.AsEnumerable (Breaking Change).
Removed Async keyword from all methods (Breaking Change).

Codecov Report
Attention: Patch coverage is 86.47343% with 28 lines in your changes are missing coverage. Please review.

Project coverage is 95.24%. Comparing base (9ec6840) to head (5663fbd).

Files
Patch %
Lines

src/MooVC/Data/IFeatureExtensions.With.cs
0.00%
12 Missing :warning:

src/MooVC/Data/IFeaturesExtensions.Includes.cs
0.00%
11 Missing :warning:

src/MooVC/Linq/IEnumerableExtensions.ProcessAll.cs
88.57%
3 Missing and 1 partial :warning:

src/MooVC/Linq/IEnumerableExtensions.IsEmpty.cs
85.71%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #77      +/-   ##
==========================================
- Coverage   97.61%   95.24%   -2.37%
==========================================
  Files          54       55       +1
  Lines         921      947      +26
  Branches       90       91       +1
==========================================
+ Hits          899      902       +3
- Misses         16       39      +23
  Partials        6        6

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


make failed

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to the root directory of eCapture then run make

Expected behavior
make can compile the .c to .o success
Screenshots

Linux Server/Android (please complete the following information):

OS: CentOS Linux release 8.2.2004 (Core)
Arch: x86_64
Kernel Version: 4.18.0-193.el8.x86_64
Version: 0.3.0
BTF enabled: yes
go version: go version go1.18.4 linux/amd64

Additional context
no

this is the vmlinux.h generated at my dev machine.
vmlinux.h.txt

upload result  here used commandmake env.

---------------------------------------
Makefile Environment:
---------------------------------------
PARALLEL                 32
---------------------------------------
CLANG_VERSION            10
GO_VERSION               1.18
---------------------------------------
CMD_CLANG                clang
CMD_GIT                  git
CMD_GO                   go
CMD_INSTALL              install
CMD_LLC                  llc
CMD_MD5                  md5sum
CMD_PKGCONFIG            pkg-config
CMD_STRIP                llvm-strip
VERSION                  -20220504-1cb258a-prev--dirty
LAST_GIT_TAG             -20220504-1cb258a-prev--dirty
TAG_COMMIT
TAG
COMMIT                   1cb258a
BPF_NOCORE_TAG           4_18_0-193_el8_x86_64.-20220504-1cb258a-prev--dirty
---------------------------------------
UNAME_M                  x86_64
UNAME_R                  4.18.0-193.el8.x86_64
ARCH                     x86_64
LINUX_ARCH               x86
---------------------------------------
KERN_RELEASE             4.18.0-193.el8.x86_64
KERN_BUILD_PATH          /lib/modules/4.18.0-193.el8.x86_64/build
KERN_SRC_PATH            /lib/modules/4.18.0-193.el8.x86_64/source
---------------------------------------
GO_ARCH                  amd64
---------------------------------------

would you mind try to make it by clang-12? Thanks!
You can also get the QR of our QQ group by following the account https://github.com/ehids/ecapture/blob/master/images/wechat_gzhh.png for better communication

update the clang to version 12, but also the same problem.
BTW, i'm entering the QQ Group. :)))))

This problem seems related with bpftool version since it is fixed when we use the proper vmlinux.h. Would you please upload the result of $ bpftool version, use latest bpftool and retry, see if the vmlinux.h is correct.

The problem is related with bpftool. Feel free to reopen this issue or reach me by QQ if there is any doubt with it.


Control Names Should Reflect Field Names

I understand that the UI simplification is ongoing, but here are some problems that it's causing for us (and probably other extension developers). When Microsoft recaptions a page field (e.g., Ship-to Code on the Sales Invoice page is now just Code, as it is located in the Ship-to section of the page), it breaks our extensions. Our addafter was set to "Ship-to Code", as that's what the field has always been named (and it's named that in 2016, 2017, and earlier builds of 2018). Presumably, Microsoft is going to continue this trend, which is great, but it's wreaking havoc on pageextensions. If you are recaptioning a field on a page, could you please set the control Name to the field name? It's a problem for new extension developers, too. To take that same example, when you are adding a control to the Sales Invoice page, how would someone know that addafter(Code) is referring to the Ship-to Code? "Code" works fine in the UI, but it's not a good control name. We publish our extensions for NAV 2016 and 2017 too, so it would be ideal if the control names could be consistent across NAV versions (even though you might change the captions for simplification).
This is impacting our extensions on the following pages (so if you could revert the control Names on these pages at a minimum, I would appreciate it):
Customer Card
Sales Invoice
Sales Order
Sales Quote
Sales Return Order

Dev comments below:

When we change the field's caption it doesn't lead to extension break as it follows from the github request. When we change the field's name then it can be the reason of extension break. But these cases are quite rare I suppose and we have an effective process for such cases. So I don't see the problem here.

The second problem mentioned in the github request is that it difficult to understand what field is going to be reflected on the page because we have several fields with the same caption. While developing extension system refers on the field name but not the caption. Below is a screenshot illustrating extension of the page "Sales Invoice" which has several "Code" caption fields. We see the reference on the field's name but not the caption.


Updating pelican_director_total_advertisements_received to a better name and to include the namespace prefix as a label

This PR updates the pelican_director_total_advertisements_received metric to pelican_director_advertisements_received_total. This PR also adds the namespace prefix as a label to the metric. This PR directly addresses #1407.

Before we merge, can we please clean up the git history a bit?

I just cleaned up the commits using rebase. Sorry about the mess.

Unfortunately this didn't get merged to our 7.9 release (we were so close!), but your other PRs did! And the good news is this is likely to be the first contribution to the 7.10 release.


Nitrogen unusable :/

Hi Jesse,
Everything is in the title - this falls at a very bad moment, as I have an app to finish ASAP and I did not kept the former version of nitrogen. I'm completely stuck.
As usual, I tried to load a page I know works, but I ended with a crash of the page + one of the crash_handler, he is the console log :
=INFO REPORT==== 16-Nov-2023::02:43:57.530593 ===
Crash Handler Crashed:
{throw,
    {handler_not_found_in_context,crash_handler,
        [{handler_context,config_handler,default_config_handler,undefined,[]},
         {handler_context,log_handler,default_log_handler,undefined,[]},
         {handler_context,process_registry_handler,nprocreg_registry_handler,
             undefined,[]}]},
    [{wf_handler,get_handler,1,[{file,"src/lib/wf_handler.erl"},{line,96}]},
     {wf_handler,call_readonly,3,[{file,"src/lib/wf_handler.erl"},{line,61}]},
     {wf_core,run_crashed_first_request,3,
         [{file,"src/wf_core.erl"},{line,237}]},
     {wf_core,run_crash,4,[{file,"src/wf_core.erl"},{line,44}]},
     {cowboy_simple_bridge_anchor,init,2,
         [{file,"src/cowboy_bridge_modules/cowboy_simple_bridge_anchor.erl"},
          {line,36}]},
     {cowboy_handler,execute,2,[{file,"src/cowboy_handler.erl"},{line,41}]},
     {cowboy_stream_h,execute,3,[{file,"src/cowboy_stream_h.erl"},{line,320}]},
     {cowboy_stream_h,request_process,3,
         [{file,"src/cowboy_stream_h.erl"},{line,302}]}]}

Original Crash:
{exit,{noproc,{gen_server,call,[nitro_cache_expirer,{new,nitrogen}]}},
      [{gen_server,call,2,[{file,"gen_server.erl"},{line,370}]},
       {nitro_cache,init,1,[{file,"src/nitro_cache.erl"},{line,48}]},
       {default_cache_handler,add_cache,2,
                              [{file,"src/handlers/cache/default_cache_handler.erl"},
                               {line,42}]},
       {default_cache_handler,init,2,
                              [{file,"src/handlers/cache/default_cache_handler.erl"},
                               {line,23}]},
       {wf_handler,init,1,[{file,"src/lib/wf_handler.erl"},{line,17}]},
       {wf_core,'-call_init_on_handlers/0-lc$^0/1-0-',1,
                [{file,"src/wf_core.erl"},{line,211}]},
       {wf_core,call_init_on_handlers,0,[{file,"src/wf_core.erl"},{line,211}]},
       {wf_core,run_catched,0,[{file,"src/wf_core.erl"},{line,86}]}]}

I just re-tested with a fresh install just in case, but it also crashed as soon as I tried : http://locahost:8000
Could you please fix this ASAP ?
Thanks in advance & regards,
Jean-Yves

Is this a new project generated from the most recent master?
On Wed, Nov 15, 2023, 7:51 PM JiffB @.***> wrote:

Hi Jesse,
Everything is in the title - this falls at a very bad moment, as I have an
app to finish ASAP and I did not kept the former version of nitrogen. I'm
completely stuck.
As usual, I tried to load a page I know works, but I ended with a crash of
the page + one of the crash_handler, he is the console log :
=INFO REPORT==== 16-Nov-2023::02:43:57.530593 ===
Crash Handler Crashed:
{throw,
{handler_not_found_in_context,crash_handler,
[{handler_context,config_handler,default_config_handler,undefined,[]},
{handler_context,log_handler,default_log_handler,undefined,[]},
{handler_context,process_registry_handler,nprocreg_registry_handler,
undefined,[]}]},
[{wf_handler,get_handler,1,[{file,"src/lib/wf_handler.erl"},{line,96}]},
{wf_handler,call_readonly,3,[{file,"src/lib/wf_handler.erl"},{line,61}]},
{wf_core,run_crashed_first_request,3,
[{file,"src/wf_core.erl"},{line,237}]},
{wf_core,run_crash,4,[{file,"src/wf_core.erl"},{line,44}]},
{cowboy_simple_bridge_anchor,init,2,
[{file,"src/cowboy_bridge_modules/cowboy_simple_bridge_anchor.erl"},
{line,36}]},
{cowboy_handler,execute,2,[{file,"src/cowboy_handler.erl"},{line,41}]},
{cowboy_stream_h,execute,3,[{file,"src/cowboy_stream_h.erl"},{line,320}]},
{cowboy_stream_h,request_process,3,
[{file,"src/cowboy_stream_h.erl"},{line,302}]}]}
Original Crash:
{exit,{noproc,{gen_server,call,[nitro_cache_expirer,{new,nitrogen}]}},
[{gen_server,call,2,[{file,"gen_server.erl"},{line,370}]},
{nitro_cache,init,1,[{file,"src/nitro_cache.erl"},{line,48}]},
{default_cache_handler,add_cache,2,
[{file,"src/handlers/cache/default_cache_handler.erl"},
{line,42}]},
{default_cache_handler,init,2,
[{file,"src/handlers/cache/default_cache_handler.erl"},
{line,23}]},
{wf_handler,init,1,[{file,"src/lib/wf_handler.erl"},{line,17}]},
{wf_core,'-call_init_on_handlers/0-lc$^0/1-0-',1,
[{file,"src/wf_core.erl"},{line,211}]},
{wf_core,call_init_on_handlers,0,[{file,"src/wf_core.erl"},{line,211}]},
{wf_core,run_catched,0,[{file,"src/wf_core.erl"},{line,86}]}]}
Could you please fix this ASAP ?
I also have a question : do you have a normal page with a working
wizard ? ( I have difficulties to translate from the wizard demo which is
very different from what I use.)
Thanks in advance & regards,
Jean-Yves
—
Reply to this email directly, view it on GitHub
https://github.com/nitrogen/nitrogen/issues/143, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABNRHH2KCAIGXVPLLUUCRTYEVWQVAVCNFSM6AAAAAA7NMS6HOVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TKOBYGQ4DSOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Btw, this error is primarily indicating that nitro_cache is not started.
If this is starting from a brand new project, I just tested with both
master and the 2.x branch, and both worked as expected.
If this is a previously generated project, but you just pulled a
nitro_cache, try using application:ensure_all_started(nitro_cache), instead
of just application:start(nitro_cache).
Maybe that will help.
-Jesse
On Wed, Nov 15, 2023, 7:51 PM JiffB @.***> wrote:

Hi Jesse,
Everything is in the title - this falls at a very bad moment, as I have an
app to finish ASAP and I did not kept the former version of nitrogen. I'm
completely stuck.
As usual, I tried to load a page I know works, but I ended with a crash of
the page + one of the crash_handler, he is the console log :
=INFO REPORT==== 16-Nov-2023::02:43:57.530593 ===
Crash Handler Crashed:
{throw,
{handler_not_found_in_context,crash_handler,
[{handler_context,config_handler,default_config_handler,undefined,[]},
{handler_context,log_handler,default_log_handler,undefined,[]},
{handler_context,process_registry_handler,nprocreg_registry_handler,
undefined,[]}]},
[{wf_handler,get_handler,1,[{file,"src/lib/wf_handler.erl"},{line,96}]},
{wf_handler,call_readonly,3,[{file,"src/lib/wf_handler.erl"},{line,61}]},
{wf_core,run_crashed_first_request,3,
[{file,"src/wf_core.erl"},{line,237}]},
{wf_core,run_crash,4,[{file,"src/wf_core.erl"},{line,44}]},
{cowboy_simple_bridge_anchor,init,2,
[{file,"src/cowboy_bridge_modules/cowboy_simple_bridge_anchor.erl"},
{line,36}]},
{cowboy_handler,execute,2,[{file,"src/cowboy_handler.erl"},{line,41}]},
{cowboy_stream_h,execute,3,[{file,"src/cowboy_stream_h.erl"},{line,320}]},
{cowboy_stream_h,request_process,3,
[{file,"src/cowboy_stream_h.erl"},{line,302}]}]}
Original Crash:
{exit,{noproc,{gen_server,call,[nitro_cache_expirer,{new,nitrogen}]}},
[{gen_server,call,2,[{file,"gen_server.erl"},{line,370}]},
{nitro_cache,init,1,[{file,"src/nitro_cache.erl"},{line,48}]},
{default_cache_handler,add_cache,2,
[{file,"src/handlers/cache/default_cache_handler.erl"},
{line,42}]},
{default_cache_handler,init,2,
[{file,"src/handlers/cache/default_cache_handler.erl"},
{line,23}]},
{wf_handler,init,1,[{file,"src/lib/wf_handler.erl"},{line,17}]},
{wf_core,'-call_init_on_handlers/0-lc$^0/1-0-',1,
[{file,"src/wf_core.erl"},{line,211}]},
{wf_core,call_init_on_handlers,0,[{file,"src/wf_core.erl"},{line,211}]},
{wf_core,run_catched,0,[{file,"src/wf_core.erl"},{line,86}]}]}
Could you please fix this ASAP ?
I also have a question : do you have a normal page with a working
wizard ? ( I have difficulties to translate from the wizard demo which is
very different from what I use.)
Thanks in advance & regards,
Jean-Yves
—
Reply to this email directly, view it on GitHub
https://github.com/nitrogen/nitrogen/issues/143, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABNRHH2KCAIGXVPLLUUCRTYEVWQVAVCNFSM6AAAAAA7NMS6HOVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TKOBYGQ4DSOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Last question - what is the mechanism by which Nitrogen here is being launched?
Also, if you wouldn't mind sharing the whole compilation and startup sequence, that would be helpful?

Is this a new project generated from the most recent master?

Hi Jesse, sorry for the delay, a small e-mail server problem.
It was both, a former one upgraded with make and a brand new one to test if its was the same.
If this has a meaning, I use Erlang <IP_ADDRESS> compiled from their tarball.
Jean-Yves

This next error is indicating that nprocrec is not being started.
From the root of the nitrogen repo, what is the latest commit?
git log -1
That should be able to tell me how some of the processes are being started?

git log -1

O_o, Whiney Houston, we have a problem - i got out of the first start up and typed that, but it did not like it :/
$ git log -1
fatal: your current branch 'master' does not have any commits yet

May be it just comes from the scripts I copied at the root, as I did not commit anything since the creation of this test project.

git log -1

O_o, Whiney Houston, we have a problem - i got out of the first start up and typed that, but it did not like it :/
$ git log -1
fatal: your current branch 'master' does not have any commits yet

May be it just comes from the scripts I copied at the root, as I did not commit anything since the creation of this test project.

I mean from the root of nitrogen, not the root of your application.

Regardless, there's a disconnect between versions (pulling from the master branch of nitrogen_core won't work with the current version of the nitrogen repo on your machine).
So there are a few options here to get this squared away:
Option 1: Update your rebar.config to point nitrogen_core at the 2.x branch (instead of the master branch), then delete dependencies and rerun make
Option 2: Pull the latest version of nitrogen with git clone https://github.com/nitrogen/nitrogen and run the usual make scripts from that
For your already-existing project, I'd recommend doing option 1, for a new project, I recommend option 2.
Alternatively, you can automate some of the steps to upgrade to Nitrogen 3 and rebar3 with this: https://github.com/nitrogen/nitrogen#upgrading-from-nitrogen-2-to-nitrogen-3
Make sure you follow the instructions on-screen closely. There is a post-script step that requires some manual steps before running one more script.

I mean from the root of nitrogen, not the root of your application.

Arf, here it is :
$ git log -1
commit 839981f687bc2e9faccb9d83b655627f56f11e26 (HEAD, origin/master, origin/HEAD, master)
Author: Jesse Gumm<EMAIL_ADDRESS>Date:   Sun Nov 12 16:13:49 2023 -0600

    Fixed a crash in template callouts

Regardless, there's a disconnect between versions (pulling from the master branch of nitrogen_core won't work with the current version of the nitrogen repo on your machine).

Ah, ok, I was beginning to think about that.

So there are a few options here to get this squared away:
Option 1: Update your rebar.config to point nitrogen_core at the 2.x branch (instead of the master branch), then delete dependencies and rerun make

I'll take this one until the net stable tag appears.

Option 2: Pull the latest version of nitrogen with git clone https://github.com/nitrogen/nitrogen and run the usual make scripts from that
For your already-existing project, I'd recommend doing option 1, for a new project, I recommend option 2.

What I did was to restore nitrogen files from a former backup, but I'm locking it right now to the '2.x' branch instead of the master one to make sure there's no possibility to goof.

Alternatively, you can automate some of the steps to upgrade to Nitrogen 3 and rebar3 with this: https://github.com/nitrogen/nitrogen#upgrading-from-nitrogen-2-to-nitrogen-3
Make sure you follow the instructions on-screen closely. There is a post-script step that requires some manual steps before running one more script.

Talking about that, I have some fix/modifications to the 2.x branch, such as 'fix-slim-release' fixed (used: git:// instead of https://), the 'after' in element_checkbox that now works, adding the 'loading' parm into element_image and element_iframe and a modification to wf_convert (encoding/decoding the keyboard hyphen to the typographic one, that isn't recognized by databases) shall I send you directly (PM) the modified files ?

Ideally, I'd prefer these updates as pull requests rather than a PMs.
Thanks,
On Thu, Nov 16, 2023, 3:02 PM JiffB @.***> wrote:

Regardless, there's a disconnect between versions (pulling from the master
branch of nitrogen_core won't work with the current version of the
nitrogen repo on your machine).
Ah, ok, I was beginning to think about that.
So there are a few options here to get this squared away:
Option 1: Update your rebar.config to point nitrogen_core at the 2.x
branch (instead of the master branch), then delete dependencies and rerun
make
I'll take this one until the net stable tag appears.
Option 2: Pull the latest version of nitrogen with git clone
https://github.com/nitrogen/nitrogen and run the usual make scripts from
that
For your already-existing project, I'd recommend doing option 1, for a new
project, I recommend option 2.
What I did was to restore nitrogen files from a former backup, but I'm
locking it right now to the '2.x' branch instead of the master one to make
sure there's no possibility to goof.
Alternatively, you can automate some of the steps to upgrade to Nitrogen 3
and rebar3 with this:
https://github.com/nitrogen/nitrogen#upgrading-from-nitrogen-2-to-nitrogen-3
Make sure you follow the instructions on-screen closely. There is a
post-script step that requires some manual steps before running one more
script.
Talking about that, I have some fix/modifications to the 2.x branch, such
as 'fix-slim-release' fixed (used: git:// instead of https://), the
'after' in element_checkbox that now works, adding the 'loading' parm into
element_image and element_iframe and a modification to wf_convert
(encoding/decoding the keyboard hyphen to the typographic one, that isn't
recognized by databases) shall I send you directly (PM) the modified files ?
—
Reply to this email directly, view it on GitHub
https://github.com/nitrogen/nitrogen/issues/143#issuecomment-1815310110,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABNRHAMT64NS4HZC4MLCULYEZ5PFAVCNFSM6AAAAAA7NMS6HOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJVGMYTAMJRGA
.
You are receiving this because you commented.Message ID:
@.***>


Suggested controller/adaptor software?

I'm trying to set up some generic addressable LEDs for use, ultimately, with Lumia Stream via a Teensy. This firmware seems like a good starting point, as it allows the Teensy to emulate a USB DMX controller, and Lumia can talk to that, I guess via QLC+ and a LoopMIDI port (as suggested in this video).
So far, I have validated the basic serial connectivity just using ultraDMX Configuration, however this just seems to be a test utility, not at an actual passthru. I'm also trying QLC+, but it doesn't seem able to see the serial device (in my case COM4) in order to do anything with it:

I haven't made it to OLA yet as I'm hoping to avoid having to run a whole VM just for this one piece of the puzzle. Is there something obvious I'm missing here as far as an easy way to bridge the gap from USB serial device to MIDI in Windows? Maybe it's as easy as giving the Teensy a VID/PID that QLC will recognize as ones of its supported devices?

My sincere apologies for the delayed response!
I really like QLC+ for testing things like this, but it has always had one flaw. The issue that you're seeing with QLC+ is most likely that it expects only a FTDI-based serial to USB adapter (which all of the Enttec and Enttec-like devices use), but the Teensy does not use FTDI or similar adapters; it uses the native USB port and a standard USB serial implementation (I believe ACM).
Yeah, OLA would be my first recommendation, but you're on Windows so that's definitely more annoying for OLA. You could potentially use Docker (I'm very certain this will work) WSL (also should work fine) pretty easily. Or you could get a separate TTL FTDI adapter for the Teensy. Though I think there is a better solution for your particular case.
If you are OK skipping QLC+, then the best solution would be to not use this library at all. The Teensy can very easily instead show up as a USB MIDI device that you can use directly with your software of choice. See the "receiving" sections here: Teensyduino: Using USB MIDI with Teensy on the Arduino IDE. There is an example showing how to control an LED with a MIDI note. You can use either MIDI notes or the control parameters. This is outside the scope of this library, but I'm happy to help anyway I can :grinning:.
As a side note, it looks like Lumia Stream supports MIDI, OSC, and Artnet. OLA can convert all of those things to the Enttec USB serial protocol and is very reliable should you wish to do that.

No worries on the delay, as a fellow open-source maintainer, I expect nothing and appreciate anything at all, much less such a detailed and thoughtful response.
I did actually see that the Teensy could be a native MIDI device and played briefly with it already, but it seems like the light behaviour authoring story directly in Lumia was going to be extremely painful— its "MIDI" support appears to be limited to just triggering note X at velocity Y, which seems to be more geared toward like a one-off spotlight or something rather than having any kind of understanding of RGB or the spatial relationship between pixels (to do chaser patterns or whatever). I think I was picturing that QLC+ might be the answer to the authoring side, but honestly I'm kind of new to both these tools.
I guess another way to do it is just assign six notes to be RGB and alt-RGB, and then have others that can be triggered to "play" specific patterns of the two selected colors. Certainly my preference would have been to have the firmware part be as thin as possible and have basically all the smarts be on the computer side, but that may just not be workable.

Another option that I just thought of would be use to something like Processing as a gateway between either Lumia or QLC+ and DMXUSB. There would be some programming involved, but it would be minimal and all running on your computer. I have used the OSC library in Processing extensively, and I am certain it would receive data from QLC+ or Lumia just fine. I have not tried the Artnet library, but I am sure it is fine as well. There is also a library for connecting to Enttec-like devices, which should theoretically work perfectly to send data to a DMXUSB device. I have not used it, but I am mostly certain it is not tied to FTDI drives. So the possible patterns are:
Lumia --OSC--> QLC+ --OSC--> Processing --USB serial--> DMXUSB

or
Lumia --OSC--> Processing --USB Serial--> DMXUSB

Processing is more than capable of outright replacing QLC+ as well should you wish to. It is a programming environment designed for creative visual applications. You can either run it headless or make use of the visualization capabilities.
I would also recommend using OSC or Artnet since Lumia supports it. That way you don't need to deal with any loopback MIDI devices.

Going to close this for now since it is not really a fixable issue with DMXUSB, but please continue the conversation as this is a fascinating problem to solve that will maybe be useful to others in the future. :grin:


Missing firebase_options.dart

The import 'firebase_options.dart'; in lib/main.dart isn't referring to a checked in file.

firebase_options.dart is automatically generated by FlutterFire CLI, and contains apiKey, apiId and probably other sensitive data. Is it right to track it in git?

I've checked in a version of the file with the various IDs removed. You can see an example of this approach in https://github.com/flutter/codelabs/blob/master/firebase-get-to-know-flutter/step_09/lib/firebase_options.dart
hth!


python312Packages.gotailwind: 0.2.4 -> 0.3.0

Diff: https://github.com/frenck/python-gotailwind/compare/refs/tags/v0.2.4...v0.3.0
Changelog: https://github.com/frenck/python-gotailwind/releases/tag/v$version

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 364149

x86_64-linux

:white_check_mark: 5 packages built:

home-assistant-component-tests.tailwind
python311Packages.gotailwind
python311Packages.gotailwind.dist
python312Packages.gotailwind
python312Packages.gotailwind.dist


Add Cohere model

This adds the cohere model as an option in the dropdown, tested locally. It also adds the option of Cohere's embeddings.

@baskaryan are you able to help review here?


Missing array variants in BitWriter and BitReader

Is your feature request related to a problem? Please describe.
There should be default implementations in MLAPI to support serialization of standard array data types like float[].
Describe the solution you'd like
Here's what I've written. Maybe it needs some more fine-tuning?
        SerializationManager.RegisterSerializationHandlers<ulong[]>(
            (stream, instance) => {
                using (PooledBitWriter writer = PooledBitWriter.Get(stream)) {
                    writer.WriteULongArray(instance);
                }
            },
            stream => {
                using (PooledBitReader reader = PooledBitReader.Get(stream)) {
                    return reader.ReadULongArray();
                }
            }
        );

:tada: This issue has been resolved in version 10.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Create LICENSE

Added the same license as ecurve

Would you mind replublishing the npm package as well?

I haven't used this package in years. Feel free to fork now that there is a very permissive license in place.


Update lading container base image

What does this PR do?
This commit updates the lading base OS from Debian bullseye to the
latest stable bookworm.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1160  👈 (View in Graphite)
#1159
#1158
#1157
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Merge activity

Dec 17, 2:57 PM EST: Graphite disabled "merge when ready" on this PR due to: a merge conflict with the target branch; resolve the conflict and try again..


Persona bar still opens on every page load

I thought the problem with the persona bar opening on every page load was to be fixed in DNN 9.4.1 so that you had to manually open it to see it, or am I wrong? Or is there a settings I have missed for this now?
Having it open every time creates a lot of problems, especially if you would happen to browse a site with enough permissions from a device with a smaller screen like a smartphone.

Ok, by open do you mean expanded like showing a panel, if that is the case when you use the close button on the top right, that should not expand it upon next page load. If you mean that it is still visible then this is currently by design. There was a long long long RFC about all kinds of ideas for the Persona Bar but we try to cleanup issues that are not actionable in a decent time frame and have no activity for a long time in order to not get buried down in all kinds of non-actionable discussions.
Also, there was no consensus on that RFC and no Pull Request came in for any of those ideas. We are now at a stage where it is a bit easier to do development for the Persona Bar and I for one have many ideas for it including making it responsive, accessible, making it a drawer that can be placed into any edge of your choice (like the windows taskbar). Now this is a massive undertaking and unfortunately wont happen before Dnn 10 at least. Unless someone submits a PR that goes in a direction where we are all in agreement.
So in the spirit of cleaning the backlog, I am closing this issue, but sure if a PR comes in that improves that and we have an agreement between the approvers, I would be happy to take that within the 9.4.x bearing it has no breaking changes for other extensions that live in the Persona Bar.

Hi,
Thanks. I have actually never seen that there is a X in the top right corner and never  understood the meaning of it and the fact that it seem to be a persistent toggle for this. And neither has any of the other developers/admins that login with enough permission to have this bar. I would like to think we are not all stupid so I believe it might be a good idea to highlight this more so that people don't do what we have always done, click outside of the persona bar to close it.


merge from arlac77/npm-package-template-kronos-module

README.md

docs(README): update from template

Codecov Report

Merging #656 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #656   +/-   ##
=======================================
  Coverage   85.53%   85.53%
=======================================
  Files           8        8
  Lines         560      560
  Branches       67       67
=======================================
  Hits          479      479
  Misses         80       80
  Partials        1        1

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 1a4c054...7873dba. Read the comment docs.

:tada: This PR is included in version 7.5.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


ERROR in OfflinePlugin: Plugin's runtime wasn't added to one of your bundle entries

So I 'incorrectly' presumed that the correct place to add the runtime code was the app.js, which is the entry point in my react app. But this generated the above specified error.
My index.html file is generated by HtmlWebpackPlugin, so I then added the runtime code to the template used to build index.html, but this too generated errors.
My webpack.config file is as specified:
module.exports = {
  devtool: 'source-map',
  context: __dirname,
  entry: {
    main: path.resolve(__dirname, './client/app'),
  },
  output: {
    path: path.join(__dirname, '/public'),
    filename: '[name]-[hash].js',
    publicPath: '/'
  },
  plugins: [
    new webpack.optimize.OccurenceOrderPlugin(),
    new Dotenv({
      path: './.env', // Path to .env file (this is the default)
      safe: true // load .env.example (defaults to "false" which does not use dotenv-safe)
    }),
    new webpack.DefinePlugin({
      'process.env': {
        'NODE_ENV': "'production'"
      }
    }),
    new webpack.optimize.UglifyJsPlugin({
      compressor: {
        warnings: false
      }
    }),
    new HtmlWebpackPlugin({
      title: 'Flamingo City',
      filename: 'index.html',
      template: './index_template.ejs',
    }),
    new CopyWebpackPlugin([
      { from: '404.html' }, // Copies file from root to specified output:path:
      { from: 'manifest.json' },
      { from: 'images', to: 'images' },
    ]),
    new OfflinePlugin({
      safeToUseOptionalCaches: true,

      caches: {
        main: [
          'index.html'
        ]
      },

      ServiceWorker: {
        events: true
      },
      AppCache: {
        events: true
      }
    })
  ],
  module: {
    loaders: [
    // js
    {
      test: /\.js$/,
      loaders: ['babel'],
      include: path.join(__dirname, 'client')
    },
    // CSS
    {
      test: /\.styl$/,
      include: path.join(__dirname, 'client'),
      loader: 'style-loader!css-loader!stylus-loader'
    }
    ]
  }
};

My index_template.ejs is as follows:

    <meta charset="utf-8">
    <title><%= htmlWebpackPlugin.options.title %></title>
    <link rel="shortcut icon" type="image/png" href="/images/my-favourite-icon.png"/>
    <link rel="manifest" href="/manifest.json" />

My app.js is as follows:
......various imports......

render(
  <ApolloProvider store={store} client={client}>
    { /* Tell the Router to use our enhanced history */ }
    <Router history={history}>
      <Route path="/" component={App}>
        <IndexRoute component={PhotoGrid} />
        <Route path="/view/:postId" component={Single}></Route>
      </Route>
    </Router>
  </ApolloProvider>,
  document.getElementById('root')
);

Where exactly do I add the runtime code?

The error message is probably a red herring, as the runtime should be added to your client entry point (related https://github.com/NekR/offline-plugin/issues/152 and https://github.com/webpack/webpack/issues/3847).
Try specifying babel-loader instead of babel in module.loaders section of your webpack config and see if that makes the error go away.


*: fixed some  warning

LGTM.
Not sure about changing the casing (might break compatibility?)
Defer to @xiang90 and @heyitsanthony
Thanks!

@davygeek what's giving the warnings? golint?

@heyitsanthony  I use warning maybe not good, just coding style
golint notice as follow
"can probably use "var newp []*rangePerm" instead"
"struct field DnsCluster should be DNSCluster"
"should replace nSet += 1 with nSet++"
I think use golint easy to unify code style

lgtm


Implicit team IdentifyLite, and other changes

Parts of this were merged as https://github.com/keybase/client/pull/8185. The design of IdentifyLite is not yet settled.


Don't let change expiration time when infraction already expired.

Closes #850

@MarkKoz I made this early exiting when an infraction expired and no reason provided.

@MarkKoz I applied change now.


Bump Gemfile.lock reference to github-pages version  214

Bump Kramdown to 2.3.1 per dependabot security update.

Gemfile.lock Github version updated from 207 to 214.  Bump kramdown reference version from 2.3.0 to 2.3.1.

Bump Gemflie.lock reference to github-pages from 207 to 214, and reference to krakdown from 2.3.0 to 2.3.1 to resolve dependabot security alert.  Canceled, let dependabot do the merge.


Add suggestions for learning rust

Here are some suggestions:
https://www.lurklurk.org/effective-rust/
https://doc.rust-lang.org/book/second-edition/
https://www.youtube.com/watch?v=T_KrYLW4jw8&list=PLzMcBGfZo4-nyLTlSRBvo0zjSnCnqjHYQ
https://www.youtube.com/@NoBoilerplate

Here's another one: https://fasterthanli.me/articles/a-half-hour-to-learn-rust


mini-max sum solution cpp

Mention issue number as well

issue #200

Please add links in README

Done #221


AWS provider version constraints require bump to support newer resources

The current version constraint for the AWS provider in the module is set to >=3.73.0 however the module uses resources that do not exist in this version of the provider specifically aws_networkmanager_vpc_attachment and aws_networkmanager_attachment_accepter. These resources were added in v4.27.0.
If the resolved/matched version of the provider in a child module is below v4.27 the following is thrown:
│ Error: Invalid resource type
│
│   on .terraform\modules\vpc\main.tf line 351, in resource "aws_networkmanager_vpc_attachment" "cwan":
│  351: resource "aws_networkmanager_vpc_attachment" "cwan" {
│
│ The provider hashicorp/aws does not support resource type "aws_networkmanager_vpc_attachment".
╵
╷
│ Error: Invalid resource type
│
│   on .terraform\modules\vpc\main.tf line 369, in resource "aws_networkmanager_attachment_accepter" "cwan":
│  369: resource "aws_networkmanager_attachment_accepter" "cwan" {
│
│ The provider hashicorp/aws does not support resource type "aws_networkmanager_attachment_accepter".

Further the submodule modules/flow_logs/modules/s3_log_bucket uses the aws_s3_bucket_server_side_encryption_configuration and aws_s3_bucket_lifecycle_configuration resources introduced in v4.0.0 however the version constraint is set to ">= 3.72.0"
 Error: Invalid resource type
│
│   on .terraform\modules\vpc\modules\flow_logs\modules\s3_log_bucket\main.tf line 17, in resource "aws_s3_bucket_server_side_encryption_configuration" "flow_logs":
│   17: resource "aws_s3_bucket_server_side_encryption_configuration" "flow_logs" {
│
│ The provider hashicorp/aws does not support resource type "aws_s3_bucket_server_side_encryption_configuration".
╵
╷
│ Error: Invalid resource type
│
│   on .terraform\modules\vpc\modules\flow_logs\modules\s3_log_bucket\main.tf line 27, in resource "aws_s3_bucket_lifecycle_configuration" "flow_logs":
│   27: resource "aws_s3_bucket_lifecycle_configuration" "flow_logs" {
│
│ The provider hashicorp/aws does not support resource type "aws_s3_bucket_lifecycle_configuration".

Thanks for reporting, I'll fix in a bit
There's some misconfiguration with our tfdocs file that keeps knocking down the min version


fix(defaults): Checks for set backoff and rate limit values

What this PR does / why we need it:
The defaults file was always setting rate limits and backoff to true for the azure cloud config. This checks if the value exists before setting defaults
Release note:
The defaults file was always setting rate limits and backoff to true for the azure cloud config. This checks if the value exists before setting defaults

@jackfrancis put together a more fully featured PR in #3891 that addresses this. Closing.


[MessageCenter] Closing button displayed on the message

Hi,
In the default message center, when the message is long enough, the closing button is displayed in front of the message, hiding it partly.

will be fix with #804

Fixed with https://github.com/KleeGroup/focus-components/pull/986