Add state.jobs to FastAPI app

add state.jobs to FastAPI app to store job ids, add cleanup logic, add test
Checklist before merging

[ ] I added an appropriate entry to CHANGELOG.md
[ ] I merged main into the current branch.

close #1504

TBD: verify why in benchmarks there is no cleanup after 50 entries
2024-05-29 10:55:28,043 - fractal_server.app.routes.api.v2.submit - INFO - Current worker's pid is 2315. Current status of worker job's list
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136]

TBD: verify why in benchmarks there is no cleanup after 50 entries
2024-05-29 10:55:28,043 - fractal_server.app.routes.api.v2.submit - INFO - Current worker's pid is 2315. Current status of worker job's list
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136]

See e.g. https://github.com/fractal-analytics-platform/fractal-server/pull/1538/files#r1620702525


Inspire Rage freezes character in combat

I've ran into a strange problem.  My kinetic knight locks up in combat if under the effects of Inspire Rage from a skald.  His action bar blanks and I can't even end his turn with the space bar. I have to switch to RT mode and play the combat out without him.  When Inspire Rage expires everything returns to normal and he can act.
I've tested this in 2 different games now - in both the main campaign and Midnight Isles.

Sounds like a crash. Restart the game, load the save, trigger the bug, then force close the game. That way the log has the most useful information. Post here the full game log and player log.

In both cases uninstalling and reinstalling, then respecing the character seemed to fix the issue.

It's very unlikely reinstalling does anything at all. Deleting the config file might help, if you had disabled some patch that was required.
I assume respecing does clean up the unit components, so that might help. But without further information I can't search for the problem.

Hi sorry to reopen this but I'm also experiencing this problem. If I allow my Kineticist to accept Inspired Rage, attempting to attack in Turn-Based just causes the character to lock up unable to do anything unless I go into Real-Time and either tell her to do something else or turn off accepting the rage.
See:
https://i.imgur.com/kQ6IIqG.jpg
https://i.imgur.com/0qXwGUO.jpg
Additionally, if I try to attack in Real-Time mode while I'm accepting rage, I just stand there spamming some effect 10 times a second and it looks like this: https://i.imgur.com/T4L1epm.jpg
It's an aside but Blade Rush being a spell that is disabled by Inspired Rage is pretty sad too, heh.


Update CI to setup wasmtime via release artifacts.

Closes #216.

Improvement results (note: only one sample):

OS
Before
After

Linux
6m 16s
2m 47s

macOS
14m 2s
4m 41s

Windows
13m 54s
7m 39s


[idea] Feature Request : Ability to control bottomSheet state

Problem
AFAIK, currently, there's no way to control bottomSheet state. The bottomSheetNavigator.navigatorSheetState.currentValue is immutable.
Solution
Provide method to control state.Something like bottomSheetNavigator.navigatorSheetState.expand() or bottomSheetNavigator.navigatorSheetState.collapse()

The state of the bottom sheet is tied to whether the bottom sheet is on the NavController back stack - you'd want to navigate() to a bottom sheet destination or call navController.popBackStack() if you want to show or hide a destination that is displayed as a bottom sheet.
If you want to directly change the bottom sheet state and use that as your source of truth  (and not the NavController), you should not be using BottomSheetNavigator, but instead just using ModalBottomSheetLayout and its state directly.

@ianhanniballake What if I want to show bottomSheet "destination" expanded by default when navigated?

You'd want to star b/186669820, which tracks the adding of a skipCollapsed flag to ModalBottomSheetLayout. Once that is available, we'd also make it available in Navigation Material.

okay 👍

Thanks, Ian! @theapache64, for more historical reasons/discussion on this: https://github.com/androidx/androidx/pull/173#discussion_r676056715
Consider the ModalBottomSheetState an implementation detail of the navigator :)


Tab-line-mode: not possible to switch to unreal buffers

What did you expect to happen?
When tab-line-mode is active and a *scratch* or any unreal buffer is shown as a tab, clicking it should select that buffer.
What actually happened?
Another buffer is selected instead (a "real" one in doom terms)
Additional details:
This behaviour can be seen in the doom sandbox: M-x doom/sandbox, C-c C-p to open a new emacs instance without any custom config.
In the sandbox window: open any file via M-x find-file and enable tab-line-mode via M-x global-tab-line-mode. Now there are three tabs: *scratch*, *doom* and the opened file. Selecting the buffers by clicking the according tabs works fine with *doom* and the file buffer, but not with *scratch* (or more generally: it works with "real" buffers, but not with "unreal" ones). If *scratch* is marked as real (via (doom-mark-buffer-as-real-h) as described in #2891), switching to it with a click on the tab works as expected.
Apparently it is intended, that several functions like switch-to-next-buffer skip unreal buffers, but with the tab-line the behaviour seems unexpected? A click on a tab should select the according buffer right? Or should unreal buffers not be displayed in the tab-line in the first place? tab-line-tabs-function is tab-line-tabs-window-buffers (the default value)
System information:

emacs   version    27.0.91
        features   XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP
        build      Jun 08, 2020
        buildopts  (--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --without-gconf --without-gsettings --with-x-toolkit=gtk3 --without-xaw3d --without-m17n-flt --with-cairo --without-compress-install 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -g -flto -g -flto -s -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now)
        windowsys  x
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop 25b240b9b 2020-06-28 01:09:54 -0400
        dir        ~/.doom.d/
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /bin/bash
        uname      Linux 5.6.16-1-MANJARO #1 SMP PREEMPT Wed Jun 3 14:26:28 UTC 2020 x86_64
        path       (~/bin ~/.local/bin /usr/local/bin /usr/bin /bin /usr/local/sbin /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl ~/.npm-packages/bin ~/.gem/ruby/2.7.0/bin /usr/lib/emacs/27.0.91/x86_64-pc-linux-gnu)
config  envfile    nil
        elc-files  0
        modules    (:completion (company +childframe) (ivy +prescient +childframe +icons) :ui doom doom-dashboard doom-quit hl-todo hydra indent-guides minimap modeline ophints (popup +defaults) pretty-code treemacs vc-gutter vi-tilde-fringe :editor file-templates fold multiple-cursors snippets word-wrap :emacs dired electric (undo +tree) vc :term vterm :checkers syntax :tools docker (eval +overlay) lookup lsp magit pdf rgb :lang data emacs-lisp json (javascript +lsp) markdown (org +noter +pandoc) (php +lsp) (python +lsp) rest (sh +lsp) (web +lsp) yaml :config literate (default +bindings))
        packages   ((phi-search) (phi-search-mc) (crux) (bm) (auto-dim-other-buffers) (rg) (deadgrep) (whole-line-or-region) (mixed-pitch) (org-protocol-capture-html :recipe (:host github :repo alphapapa/org-protocol-capture-html)) (org-download) (org-ql) (org-super-agenda) (org-drill) (org-drill-table) (org-mru-clock) (org-clock-csv) (ox-pandoc) (org-caldav) (org-download) (org-ref) (history) (ox-reveal) (ctrlf) (visual-fill-column))
        unpin      (n/a)
        elpa       (treemacs s pfuture lv hydra ht f dash company bm avy ace-window)

I have made mostly all buffers real now with (setq doom-unreal-buffer-functions '(minibufferp)) (which was '(minibufferp doom-special-buffer-p doom-non-file-visiting-buffer-p) before). Switching tabs works fine now, also switch-to-next-buffer recognizes these tabs as expected.
Which leads to the question.. why does doom have this real/unreal buffer concept in the first place? All I could find was the documentation for doom-real-buffer-p which states:
Returns t if BUFFER-OR-NAME is a 'real' buffer.

A real buffer is a useful buffer; a first class citizen in Doom. Real ones
should get special treatment, because we will be spending most of our time in
them. Unreal ones should be low-profile and easy to cast aside, so we can focus
on real ones.

The exact criteria for a real buffer is:

  1. A non-nil value for the buffer-local value of the doom-real-buffer-p
     variable OR
  2. Any function in doom-real-buffer-functions returns non-nil OR
  3. None of the functions in doom-unreal-buffer-functions must return
     non-nil.

What exactly does "first class citizen" and "low-profile" mean? Is it just for skipping certain buffers with buffer change functions or is there more to it? Any enlightenment will be appreciated

TL;DR: use the :ui tabs module instead of tab-bar-mode directly. It comes with a nice theme by default and gets around this issue by using the correct mechanism for buffer switching (unlike tab-bar-mode).

When tab-line-mode is active and a scratch or any unreal buffer is shown as a tab, clicking it should select that buffer.

There are four problems here.

tab-bar-mode is using the wrong mechanism for switching to a buffer. A mechanism that consults the frame's buffer-predicate to determine if a buffer is "worthy" of being switched to. The buffer predicate is meant to regulate untargeting buffer switching, not explicit ones. Switching to a particular buffer+tab should be an explicit, targeted switch. tab-bar-mode is a young library and likely hasn't been tested thoroughly.

The persp-mode plugin (from the :ui workspaces module) installs a buffer predicate that ignores unreal buffers, or buffers that aren't registered to the current workspace.

Doom adds its own frame predicate (doom-buffer-frame-predicate) which prevents switching to unreal buffers.

*scratch* buffers are not real buffers.

Which leads to the question.. why does doom have this real/unreal buffer concept in the first place?

I isolate the useful (real) buffers, so we don't end up in an unreal one unless we explicitly switch to them. It exists to make buffer switching more predictable. Emacs, its plugins, and various processes all produce numerous buffers that we don't want to accidentally switch to, because they are generally unimportant or destructive to be in unintentionally. And there are many operations (mainly to do with killing buffers or switching to next/previous buffer) that could cause us to inadvertently switch to them.
Example: an LSP server produces a *lsp-log* buffer. There is no reason to see this buffer unless you're debugging an issue. If it weren't "unreal", you could accidentally land in it by invoking next-buffer or when you killing/burying the current buffer. A mild annoyance, but multiply this by the dozens, possibly hundreds of unimportant buffers that could exist in any long lived Emacs session.
Another example: imagine a hidden treemacs buffer. There exist two-key sequences that are capable of deleting entire directory trees in a treemacs buffer (which fortunately ask for confirmation, but...). Imagine this happening within a split second: you bury/kill a file buffer and land in that treemacs buffer, but you already have a new destination in mind. You immediately press some global key binding (maybe the leader key) you thought would invoke something else, but instead invoked one of those "delete this directory tree" keybinds in treemacs. The confirmation prompt pops up. You don't notice why Emacs is blocking. You mash C-g (hopefully). Disaster averted, but that was annoying, disruptive and potentially disastrous.
Of course, that kind of danger is unrealistic. Disruption is more likely than damage, but it's not impossible.
This problem is more pronounced for evil users, who have to contend with multiple modes per keymap.

Which leads to the question.. why does doom have this real/unreal buffer concept in the first place?

Is there an option to turn the unreal/real concept off?
Background: I often switch to the *compilation* buffer as part of my normal workflow, so for me that "unreal" buffer is essential to have quick access to.
My current workarounds:

C-x C-b and then locate the desired buffer hit Enter
M-x switch-to-buffer-other-frame and then type the desired buffer name (with tab support)

Note: I'm using neither ui: tabs nor tab-bar-mode

I have moved on from emacs, but I had disabled the real/unreal concept with (setq doom-unreal-buffer-functions '(minibufferp)). That makes all buffers "real" and they behave the same. I enjoyed it better like this, but you have to keep hlissners explanations in mind

Thanks tbrukmainer, but that fix didn't work for me.


[Editor] Don't show popup when clicking empty in Favorites

Fixes: https://github.com/godotengine/godot/issues/96562

Thanks!

Thank you!

Cherry-picked for 4.3.1.


Updates

[x] support Laravel 7 & 8, drop the rest
[x]  support PHP 7.4 and up
[x]  Code formatter
[x]  GitHub actions for tests

Can you remove the travis badge from the readme? And check if there's any reference to Scrutinizer left (i.e. badge)?

Can you remove the travis badge from the readme? And check if there's any reference to Scrutinizer left (i.e. badge)?

Done.


Is there any way to set camera parameters like white balance, exposure on linux?

Unfortunately, the current version does not have an interface to manipulate the various settings of the V4L2 device.
As mentioned in related #112, it would be nice if we could have an interface that would allow key-value settings...
(PRs are welcome :)


Create Update Settings form for Governance and Tokens

The governance settings proposal form can be found here:
https://www.figma.com/file/9lCwprCNaoAmUDmiMQpFEA/DAOhaus-v3?node-id=6852%3A192157
The fields for this proposal form are:

Basics (should be the same as all other proposal forms):

Proposal Name (required)
Description
Link

DAO Tokens (h5)
Update your token transferability. (text)
Voting Stake Transferability? (switch - same as summon)

Info dot: (same as summon)

Non-Voting Stake Transferability? (switch - same as summon)

Info dot: (same as summon)

Expiration (should be same as all other proposals, see https://github.com/HausDAO/daohaus-monorepo/issues/498
Submit button > proposal created

Notes:

This will use the transaction pending pattern: https://github.com/HausDAO/daohaus-monorepo/issues/17
Once submitted, land user back on the settings screen
Proposal details will have a 'governance update' specific message on it. Another ticket will be filed for this.

@adriennetilley

Designs ready for review.


Use build_runner to generate certain files

Use the build_runner package to generate assets/generated_samples_list.json and lib/models/samples_widget_list.dart.
Instead of having these files checked in to the repository, they are instead created by running dart run build_runner build.

The build_runner code doesn't work on Windows (due to the usual / vs \ problems). I need to fix that and then get fresh reviews.

In order to support building on Windows, I made an initialize.bat to go along with initialize.sh.

The initialize step is now dart tool/initialize.dart on both platforms.


JTC Open-loop Control Mode: Should last_commanded_state_ here be reduced to existing state interface from the hardware? Or is it OK to internally manage more control-states then can be received from hardware?

Should last_commanded_state_ here be reduced to existing state interface from the hardware? Or is it OK to internally manage more control-states then can be received from hardware?
Originally posted by @destogl in https://github.com/ros-controls/ros2_controllers/pull/189#r642045259

@destogl could you please explain what you meant here? I'd be happy to implement that.
You mean that it should not set the point_before_trajectory_msg from the commands, if there is no state interface with identical hardware interface for the joint? What would be the alternative? Just use the first entry of the trajectory message?

Not worth to take care of it.


Red Hat Linux 9 install error

What is the issue?
sudo: dkms: command not found
modprobe: FATAL: Module nvidia not found in directory /lib/modules/5.14.0-362.18.1.el9_3.x86_64

What did you expect to see?
No response
Steps to reproduce
No response
Are there any recent changes that introduced the issue?
No response
OS
No response
Architecture
No response
Platform
No response
Ollama version
No response
GPU
No response
GPU info
No response
CPU
No response
Other software
No response

It looks like this has already been resolved.  Confirmed I can install ollama cleanly on RHEL 9 on an an n1 instance in GCE with a T4 GPU.


Support BitSet

Can we support BitSet type? It is mostly used by consensus spec.

sorry I didn't see your message. Doesn't []bool do what you want ?

Yes, we use it right now, but we used zig master version and forked this repo


Consider merging litmusify and test

It's somewhat confusing that we now have two different workflows for compiling a C litmus test and checking the results: act test, which is multi-file multi-compiler, and act litmusify, which is single-file single-compiler.  The two are slowly starting to converge on the same feature set, which makes me wonder if they should be merged at some point down the road.
This'd involve act test gaining the following features, many of which are already planned:

[ ] Support single-file input
[ ] Support stopping act test at a stage before comparison (since litmusify supports a whole range of possible outputs and filters)
[ ] Support litmus7 (see #53)
[ ] (Optional) Make it easier to use act test with one compiler
[ ] (Optional) Support sending the intermediate results to temporary files instead of using a pathset

Dropping this, because act test doesn't exist anymore, and act litmusify no longer compiles anything.


Loading a large dictionary such as UniDic cwj 2023-02 is slow in comparison to mecab

Is your feature request related to a problem? Please describe.
Loading a large dictionary such as UniDic 2023-02 is slow in comparison to mecab.
I've downloaded the latest unidic cwj 2023-02 at https://clrd.ninjal.ac.jp/unidic/download.html#unidic_bccwj and built my own compiled vibrato dictionary using
cargo run --release -p compile -- -l unidic-cwj-202302_full/lex.csv -m unidic-cwj-202302_full/matrix.def -u unidic-cwj-202302_full/unk.def -c unidic-cwj-202302_full/char.def -o system.dic.zst

and then I tried tokenizing the example sentence from the docs
> time echo '本とカレーの街神保町へようこそ。' | cargo run --release -p tokenize -- -i system.dic.zst
     Running `target/release/tokenize -i system.dic.zst`
Loading the dictionary...
Ready to tokenize
本      名詞,普通名詞,一般,*,*,*,ホン,本,本,ホン,本,ホン,漢,ホ濁,基本形,*,*,*,*,体,ホン,ホン,ホン,ホン,1,C3,*,9584176605045248,34867
と      助詞,格助詞,*,*,*,*,ト,と,と,ト,と,ト,和,*,*,*,*,*,*,格助,ト,ト,ト,ト,*,"名詞%F1,動詞%F1,形容詞%F2@-1",*,7099014038299136,25826
カレー  名詞,普通名詞,一般,*,*,*,カレー,カレー-curry,カレー,カレー,カレー,カレー,外,*,*,*,*,*,*,体,カレー,カレー,カレー,カレー,0,C2,*,2018162216411648,7342
の      助詞,格助詞,*,*,*,*,ノ,の,の,ノ,の,ノ,和,*,*,*,*,*,*,格助,ノ,ノ,ノ,ノ,*,名詞%F1,*,7968444268028416,28989
街      名詞,普通名詞,一般,*,*,*,マチ,街,街,マチ,街,マチ,和,*,*,*,*,*,*,体,マチ,マチ,マチ,マチ,2,C3,*,9827718430597632,35753
神保町  名詞,固有名詞,地名,一般,*,*,ジンボウチョウ,ジンボウチョウ,神保町,ジンボーチョー,神保町,ジンボーチョー,固,*,*,*,*,*,*,地名,ジンボウチョウ,ジンボウチョウ,ジンボウチョウ,ジンボウチョウ,
"3,0",*,*,5174035466035712,18823
へ      助詞,格助詞,*,*,*,*,ヘ,へ,へ,エ,へ,エ,和,*,*,*,*,*,*,格助,ヘ,ヘ,ヘ,ヘ,*,名詞%F1,*,9296104558567936,33819
よう    形容詞,非自立可能,*,*,形容詞,連用形-ウ音便,ヨイ,良い,よう,ヨー,よい,ヨイ,和,*,*,*,*,*,*,相,ヨウ,ヨイ,ヨウ,ヨイ,1,C3,*,10716957049496195,38988
こそ    助詞,係助詞,*,*,*,*,コソ,こそ,こそ,コソ,こそ,コソ,和,*,*,*,*,*,*,係助,コソ,コソ,コソ,コソ,*,"形容詞%F2@0,名詞%F2@1,動詞%F2@0",*,3501403402281472,12738
。      補助記号,句点,*,*,*,*,*,。,。,*,。,*,記号,*,*,*,*,*,*,補助,*,*,*,*,*,*,*,6880571302400,25
EOS

________________________________________________________
Executed in   13.96 secs    fish           external
   usr time   13.09 secs    0.00 micros   13.09 secs
   sys time    0.86 secs    0.00 micros    0.86 secs

but it takes around 14 seconds to load the dictionary.
In comparison, mecab is near instant
> time echo "本とカレーの街神保町へようこそ。" | mecab --dicdir="unidic-cwj-202302_full"
本      名詞,普通名詞,一般,*,*,*,ホン,本,本,ホン,本,ホン,漢,ホ濁,基本形,*,*,*,*,体,ホン,ホン,ホン,ホン,1,C3,*,9584176605045248,34867
と      助詞,格助詞,*,*,*,*,ト,と,と,ト,と,ト,和,*,*,*,*,*,*,格助,ト,ト,ト,ト,*,"名詞%F1,動詞%F1,形容詞%F2@-1",*,7099014038299136,25826
カレー  名詞,普通名詞,一般,*,*,*,カレー,カレー-curry,カレー,カレー,カレー,カレー,外,*,*,*,*,*,*,体,カレー,カレー,カレー,カレー,0,C2,*,2018162216411648,7342
の      助詞,格助詞,*,*,*,*,ノ,の,の,ノ,の,ノ,和,*,*,*,*,*,*,格助,ノ,ノ,ノ,ノ,*,名詞%F1,*,7968444268028416,28989
街      名詞,普通名詞,一般,*,*,*,マチ,街,街,マチ,街,マチ,和,*,*,*,*,*,*,体,マチ,マチ,マチ,マチ,2,C3,*,9827718430597632,35753
神保町  名詞,固有名詞,地名,一般,*,*,ジンボウチョウ,ジンボウチョウ,神保町,ジンボーチョー,神保町,ジンボーチョー,固,*,*,*,*,*,*,地名,ジンボウチョウ,ジンボウチョウ,ジンボウチョウ,ジンボウチョウ,
"3,0",*,*,5174035466035712,18823
へ      助詞,格助詞,*,*,*,*,ヘ,へ,へ,エ,へ,エ,和,*,*,*,*,*,*,格助,ヘ,ヘ,ヘ,ヘ,*,名詞%F1,*,9296104558567936,33819
よう    形容詞,非自立可能,*,*,形容詞,連用形-ウ音便,ヨイ,良い,よう,ヨー,よい,ヨイ,和,*,*,*,*,*,*,相,ヨウ,ヨイ,ヨウ,ヨイ,1,C3,*,10716957049496195,38988
こそ    助詞,係助詞,*,*,*,*,コソ,こそ,こそ,コソ,こそ,コソ,和,*,*,*,*,*,*,係助,コソ,コソ,コソ,コソ,*,"形容詞%F2@0,名詞%F2@1,動詞%F2@0",*,3501403402281472,12738
。      補助記号,句点,*,*,*,*,*,。,。,*,。,*,記号,*,*,*,*,*,*,補助,*,*,*,*,*,*,*,6880571302400,25
EOS

________________________________________________________
Executed in   28.32 millis    fish           external
   usr time    0.00 millis    0.00 micros    0.00 millis
   sys time   31.25 millis    0.00 micros   31.25 millis

I looked at the code and it seems like all the time is taken from deserializing bincode into the DictionaryInner struct. In particular, when it runs the read_common function
    fn read_common<R>(mut rdr: R) -> Result<DictionaryInner>
    where
        R: Read,
    {
        let mut magic = [0; MODEL_MAGIC.len()];
        rdr.read_exact(&mut magic)?;
        if magic != MODEL_MAGIC {
            return Err(VibratoError::invalid_argument(
                "rdr",
                "The magic number of the input model mismatches.",
            ));
        }
        let config = common::bincode_config();
        let data = bincode::decode_from_std_read(&mut rdr, config)?;
        Ok(data)
    }

It takes a long time to complete let data = bincode::decode_from_std_read(&mut rdr, config)?; so it seems like bincode deserialization is slow.
How is mecab able to return results so quickly despite not loading everything in memory like vibrato? It seems like it doesn't take any memory when I use mecab, whereas vibrato takes 1 GB memory to cache everything before being able to tokenize
Describe the solution you'd like
Could we use a faster serde framework like rkyv ? According to the benchmarks, it's a lot faster than bincode
According to the rkyv docs, it says

It’s similar to other zero-copy deserialization frameworks such as Cap’n Proto and FlatBuffers. However, while the former have external schemas and heavily restricted data types, rkyv allows all serialized types to be defined in code and can serialize a wide variety of types that the others cannot. Additionally, rkyv is designed to have little to no overhead, and in most cases will perform exactly the same as native types.

Not sure if there's any other way to speed it up? Could we somehow parallelize deserialization?
Describe alternatives you've considered
Apparently bincode is slow for structs that use Vec and byte slices, and the recommendation is to use serde_bytes
The features such as
pub struct UnkEntry {
    pub cate_id: u16,
    pub left_id: u16,
    pub right_id: u16,
    pub word_cost: i16,
    pub feature: String,
}
pub struct WordFeatures {
    features: Vec<String>,
}

are stored as strings, maybe they can be stored as Vec<u8> instead?
Additional context
I'm using vibrato version 0.5.1
And here are the compiled dictionary sizes
> du -sh system.dic.zst
291M    system.dic.zst

> du -sh system.dic
988M    system.dic

@kuroahna
Thank you very much for the report and suggestions!

How is mecab able to return results so quickly despite not loading everything in memory like vibrato? It seems like it doesn't take any memory when I use mecab, whereas vibrato takes 1 GB memory to cache everything before being able to tokenize

MeCab uses mmap to load the dictionary, enabling such fast and memory-efficient deserialization.
If Vibrato uses rkyv as you suggested, an equivalent performance would be achieved because rkyv supports mmap. I agree with attempting rkyv. I will try it when I have time.

@kuroahna
Thank you very much for the report and suggestions!

How is mecab able to return results so quickly despite not loading everything in memory like vibrato? It seems like it doesn't take any memory when I use mecab, whereas vibrato takes 1 GB memory to cache everything before being able to tokenize

MeCab uses mmap to load the dictionary, enabling such fast and memory-efficient deserialization.
If Vibrato uses rkyv as you suggested, an equivalent performance would be achieved because rkyv supports mmap. I agree with attempting rkyv. I will try it when I have time.

Ah! mmap! No wonder mecab can load it so quick! And thanks for the quick response! Excited to see where this one goes 🙏


Package request: raspberry-pi-imager

Project description
raspberry pi imager, the rpi foundation's flashing tool
i want it so I can flash my pi's sd (i didnt find the package)

Metadata

homepage URL: https://www.raspberrypi.com/software/
source URL: https://github.com/raspberrypi/rpi-imager
license: apache 2
platforms: windows, linux, darwin

nvm i didnt see rpi-imager existed


Migrate to CircleCI 2.0

As part of https://github.com/openzipkin/zipkin/issues/2102
Used https://github.com/openzipkin/zipkin-aws/pull/95 as a template; diff between the 1.0 circle.yml files:
# diff {zipkin-aws,b3-propagation}/circle.yml
16,17c16,17
<   environment:
<     JAVA_HOME: /usr/lib/jvm/zulu-9-amd64
---
>   java:
>     version: openjdk8
21,24d20
<     - sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0x219BD9C9
<     - sudo apt-add-repository -y "deb http://repos.azulsystems.com/ubuntu stable main"
<     - sudo apt-get -y update
<     - sudo apt-get -y install zulu-9
29,30d24
<   override:
<     - ./mvnw verify

So essentially the same, except b3-propagation being on JDK 8, and that here we override the test command with ./mvnw verify for whatever reason..
diff of 2.0 .circleci/config.yml after this PR:
 diff {zipkin-aws,b3-propagation}/.circleci/config.yml
19c19
<       - image: circleci/openjdk:9-jdk
---
>       - image: circleci/openjdk:8-jdk
51c51
<       - image: circleci/openjdk:9-jdk
---
>       - image: circleci/openjdk:8-jdk
66c66
<       - image: circleci/openjdk:9-jdk
---
>       - image: circleci/openjdk:8-jdk
81c81
<       - image: circleci/openjdk:9-jdk
---
>       - image: circleci/openjdk:8-jdk

So only Java 8. The test command is ./mvnw clean verify, which I suspect is just as good as ./mvnw verify, so let's use the same for consistency.

heh.. we've never actually published this (which is perfectly fine), so no risk merging this.
PS I wouldn't publish it any time soon as there would be no user of it.. the code here currently is demonstration, though we could at one point make integration tests of some sort with it or similar.

thanks again!


New Weight Request - epicRealism Inpainting

I saw that there are a lot of epicRealism models that are supported but I don't see any of their inpainting models. Could you add a few of those? They seem to work the best out of the models I have looked at
https://civitai.com/models/25694?modelVersionId=134361

Added in bcc884f


Added WorkerPool to parameter list

Will close #220

Could you add a test setting this parameter and getting it back?

you mean add a function in the folder test in one of the files or simply run it and post a screenshot to prove it works?

No need for a test. The real solution is to re-write the C API layer so that all of the parameters are generated automatically from the C headers.


Several Linter issues

I've noticed several Linter issues:
Constants
let SOME_CONSTANT_FOR_ENV_VAR = "ENV_VAR"

Lint: Consider changing SOME_CONSTANT_FOR_ENV_VAR to remove any underscores.
String.Split Function
someVar.Split([| ','; ' ' |], StringSplitOptions.RemoveEmptyEntries)

The linter gets fooled by the ','. Anything which is inside double quotes or inside single quotes is a string or character definition and probably shouldn't trigger the Linter.
Unions
Not sure what it doesn't like here, but this is pretty common syntax in F# I thought:

Default Property Initialisers
When I set properties to default values when initialising an object the linter mistakes it for a tuple:
let forwardedHeadersOptions =
            ForwardedHeadersOptions(
                ForwardedHeaders = ForwardedHeaders.XForwardedFor,
                ForwardLimit = Nullable<int>(1))

function pattern matching
EDIT: Same as #1014
The linter seems to confuse the pattern matching syntax with a function declaration:

Comments on class members

Otherwise works great! Got a solution which is growing in size and it's working nice!

I think, you should open the issue on FSharpLint because Ionide is just a client of the tool.
Note that some of the issues have already been reported and fixed in the linter repo.
Example: https://github.com/fsprojects/FSharpLint/issues/293

Ok cool, thanks, didn't know about that but I'll move the issue over now!


--fix ignored if -o is also provided

Hello!
Thank you for the work you put into this tool 🙌 .
Starting testing it out today and integrating directly with existing codenarc rule sets and it's lovely.
I noticed that when both --fix and -o report.html are provided, npm-groovy-lint does not automatically fix the issues it's able to.
For example, creating a new directory and a single file Example.groovy
class Example{
  void doThing(){ println "do thing" }
}

and then running:

npm-groovy-lint -p . --fix -o report.html --noserver

does not result in the automated fixes being applied.
I'm happy to look into this. If you have any tips that might point me in the right direction, i'd appreciate it :).

To be able to parse CodeNarc result, npm-groovy-lint requires CodeNarc Json output -> https://github.com/nvuillam/npm-groovy-lint/blob/8a21ad039435f72d1a2dab0d27e81553fc5bb790/lib/codenarc-caller.js#L347
Unfortunately, when using HTML or XML output, we don't have JSON output so we can just generate report, but not parse results, and --fix requires to result to be parseable ->
https://github.com/nvuillam/npm-groovy-lint/blob/b234fcf6e0f8072c266a2afdfdbbedb39fbe9677/lib/codenarc-factory.js#L96
The solution would be to implement an evolution on CodeNarc to allow several report formats for a single lint
https://codenarc.org/codenarc-command-line.html
Something like --report json:stdout --report myHtmlReportFile
Then we could generate HTML output and apply auto-fix :)

That makes a lot of sense. I'll look into this from the CodeNarc side.
Thank you!


Adding support to not native x86 systems for external libraries

Filtering of x86 specific directive at both Makefile and setup.py level. Former needed for libraries that integrate Stim at the binary level (e.g. PyMatching).
Replacing sys with platform to gain access to additional information on the OS and CPU architecture.
Wrapped up with a function the extensions that shall be built for a specific architecture.

Is there a way to test these working, from github actions, so that I don't accidentally break them given that I'm running on x86 machines?

The new muxing logic is failing on widows and osx, as you can see in the CI tests.

Thanks @Strilanc for the quick review - enabled CI on the fork and debugged the issues (i386, i686 were missing - thus Win and Mac failures). Current version passes cleanly on my forkd' main.

@Strilanc - just checking did you manage to have a look at the latest changes? they do fix the previous error and pass in CI (on the forked branch).


ACCESS-OM2 module files missing

The ACCESS-OM2 releases are not available as modules (and they should be)
$ module avail access-om2
------ /g/data/vk83/apps/spack/0.20/release/modules/linux-rocky8-x86_64 --------
access-om2-bgc/2024.03.0

But they are visible in the spack release environment:
$ spack env list
==> 4 environments
    access-om2  access-om2-2023_11_23  access-om2-2024_03_0  access-om2-bgc-2024_03_0

This PR (https://github.com/ACCESS-NRI/build-cd/pull/29) introduced this line: https://github.com/ACCESS-NRI/build-cd/blob/main/.github/workflows/deploy-2-start.yml#L94
@harshula would you remember what it was for? I remember you trialing this command as the modulefiles were not being added correctly before.

Looking at the spack documentation:
[root@e0d239fa9b8c spack]# spack module tcl refresh --help
usage: spack module tcl refresh [-hy] [--delete-tree] [--upstream-modules] ...

positional arguments:
  installed_specs     constraint to select a subset of installed packages

optional arguments:
  --delete-tree       delete the module file tree before refresh
  --upstream-modules  generate modules for packages installed upstream
  -h, --help          show this help message and exit
  -y, --yes-to-all    assume "yes" is the answer to every confirmation request

the --delete-tree -y seems quite destructive. However, we can add installed_specs as positional args - maybe we just need to be more constrained? Not sure

It is the case that the top level version is unique between installations, but it is not guaranteed that the component model versions are unique: the component model version, which reflects the source code version, can remain the same but the spack build hash can change. An example was changing to restart reproducibility: the model version didn't change, but the default variants were changed in the spack-package, and so the build hash changed, as did the executable that was built.
We need to add spack build hash information to the model component modules, e.g. cice5 and mom5, but not to the top level model module, in this case access-om2.
It is desirable to not have a the spack build information in the top level because it makes it more difficult to programmatically change the model version, which we want to do to make it easier to update configurations.
It is not possible to add {hash} to the module projections in the environment. The spack build hash is added by default and the length of the hash is configurable for all visible modules with the hash_length setting. The only way to remove the hash from the top level model module is to set hash_length: 0, which is the current setting.
The only way to have no hash information in the top level model module but include it in the component modules is by making all the model components implicit and setting hide_implicits: true in the environment, and remove exclude_implicits.
Hidden implicit modules have the default hash length (7) added to the module versions, and those modules are hidden from the module system by adding them to a .modulerc file:
$ cat cice5/.modulerc
#%Module4.7
module-hide --soft --hidden-loaded cice5/2023.10.19-p3rnzdf

See https://spack.readthedocs.io/en/latest/module_file_support.html#customize-the-naming-of-modules
The component models can also be removed from the include list. It's not clear if this was a necessary precondition to make those component model packages "implicit". Regardless they were not required, and so should be removed to further simplify the spack.yaml.

We might also need to remove the --delete-tree y option, which should no longer be required.

Agree on all points, except for the removal of the -y - we need the module refresh to be noninteractive

Note: the Release 0.20 doesn't have the [hide|exclude]_implicits in the same way as 0.21. So, we needed to disambiguate the components with component/<version>_[bgc_]<model version>. For example, for access-om2 2023.04.0, mom5 will be mom5/2024.01.11_2023.04.0 or mom5/2024.01.11_bgc_2023.04.0.

Release now has the modulefiles for access-om2, access-om2-bgc.


Fn key issues in W10 since OC 0.6.6 release

First, thank you for all your hard work! You EFI package is amazing - if I can contribute using Paypal or some other means let me know. Ever since the introduction of your OC 0.6.6 package, with the exception of the volume =/- button, all other function keys are very slow (latency) in Windows 10 (e.g. Brightness +/-, Mic mute, search) specifically F4-F12. I tried all your OC 0.6.6 packages (v1,v2,v2.1). Your OC 0.6.5 package does not have this problem so I've been sticking with that. Is this an issue with OC 0.6.6 or something you changed in the EFI?

First, thank you for all your hard work! You EFI package is amazing - if I can contribute using Paypal or some other means let me know. Ever since the introduction of your OC 0.6.6 package, with the exception of the volume =/- button, all other function keys are very slow (latency) in Windows 10 (e.g. Brightness +/-, Mic mute, search) specifically F4-F12. I tried all your OC 0.6.6 packages (v1,v2,v2.1). Your OC 0.6.5 package does not have this problem so I've been sticking with that. Is this an issue with OC 0.6.6 or something you changed in the EFI?

I have noticed that this problem is caused by a new battery patch.
I have fixed it.
I will release a new version later.

thank you

thank you
i see You reopened this question
Has the problem been solved?

thank you

i see You reopened this question
Has the problem been solved?

No, I tried your most recent release (OC 0.6.6 v2.2) and the same issue. It works on the initial reboot but then issue reoccurs. Was gonna try to use your 0.6.5 release and upgrade to OC 0.6.6 from there, but noticed some changes in the config.plist that I need to update.

No, I tried your most recent release (OC 0.6.6 v2.2) and the same issue. It works on the initial reboot but then issue reoccurs. Was gonna try to use your 0.6.5 release and upgrade to OC 0.6.6 from there, but noticed some changes in the config.plist that I need to update.

Strange, I tested it on T450S and there is no such problem.
You can try to select in the boot interface reset nvram.

My newbie mistake - sorry. I was using ProperTree & OC Snapshot since I had to edit some kexts (I use itlwm) and remove the Tools. It was picking up the old battery patch folder you left in ACPI.


Refactor filters

Codecov Report

Merging #201 into master will decrease coverage by 2.38%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #201      +/-   ##
==========================================
- Coverage    66.2%   63.81%   -2.39%
==========================================
  Files          20       20
  Lines        1296     1205      -91
==========================================
- Hits          858      769      -89
+ Misses        438      436       -2

Impacted Files
Coverage Δ

dpemu/filters/time_series.py
100% <ø> (ø)
:arrow_up:

dpemu/filters/text.py
96.15% <ø> (-0.4%)
:arrow_down:

dpemu/filters/sound.py
100% <ø> (ø)
:arrow_up:

dpemu/filters/image.py
81.19% <100%> (-1.25%)
:arrow_down:

dpemu/filters/common.py
94.02% <100%> (-0.6%)
:arrow_down:

dpemu/filters/filter.py
97.61% <100%> (+0.95%)
:arrow_up:

dpemu/pg_utils.py
82.6% <0%> (-17.4%)
:arrow_down:

dpemu/plotting_utils.py
22.97% <0%> (-1.37%)
:arrow_down:

... and 2 more

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 5f46e51...22eca73. Read the comment docs.


Feature: Dynamic link-call

Preamble
Following up on the actionflows issue and how it used global context to provide "dynamic subroutine calls" capabilities.
Description

Add ability to perform link-call dynamically
Update documentation

Considerations / questions

Should we add a mode selector "Static", "Dynamic" where "Static" mode operates as it does now and "Dynamic" mode would hide the "node selection tree"
Would the dynamic call be made by name or id (or both)?
What property of msg would be used?

msg.link ? msg.linkId ?   msg.linkName ?

Slack discussion
https://node-red.slack.com/archives/C9RSU6S56/p1644844378969309

@knolleary @dceejay
Some thoughts on implementing this feature...

In link call node ...

Should we permit msg.link to simply override the selected destination link node? (no UI changes)
- OR -
Add a UI element to switch the node between normal and "dynamic" mode (e.g. like the MQTT-IN node can be set to "single subscription" or "dynamic subscription"

This mode selector would hide the links choice tree when set to "dynamic mode"

My opinion is option 2
I think the UI should be explicit - If in normal mode then ui as now with all the link nodes listed... if in dynamic mode then no need for the large list to be visible at all (as you suggest).  But then again - if in dynamic mode do we need a default if msg.link is not set... - though that is not the way most nodes work - ie if you leave options blank then the user must supply the option.

While not relevant to this feature... I note that currently if the link call node is not named it picks up the name from where it calls to. - maybe that should be "call - {the name}" rather than just the bare name ?   And likewise when in dynamic mode maybe the node.status could show the name of the link that was called... ?

or indeed msg.call as it is about the link call node :-) .. or indeed msg.linkcall maybe to be more explicit ?

i) no - you currently can't wire a link call node to two links - so no.
ii) thus also no

i) absolutely - name would be my preference...
a) hmm maybe not  - insensitive would be my pref.
2) DON'T - just search over them both - the node would presumably create a list of possible link in nodes.ids and names at deploy time to iterate over. - searching ids first (as they are more specific) then names.
b) if more than one then raise an error - (as can't call more than 1 (see 2-i)
c) that is a Nick question :-)

well it may be slightly restrictive - but If you start duplicating flows the ids can change and it will break all your flows... so "trust me - it's for your own good!"
re no connection... no - I think that is a job for a new flow linter rule.

I appreciate this echos some of Dave's comments, but my thoughts are:

I'd be fine with msg.target as it is more functional

no - stick with single target to be consistent with what you can configure in the node

By name is going to be far more useful than by id. It will survive flows being imported (and having their id's change)

We don't need to over specify the functionality. For now, it can search both id and name. If there are multiple matches, for now, then we can error. We can leave room in the future to support calling multiple functions - but that is not a requirement today.

Run through .eachNode and locally Cache in a lookup meaning 1st link call would be O(n) and subsequent call O(1)

I would add a global to 60-link.js that the link in nodes register/unregister themselves from when they are created/closed. The link call node can then use that to do the look up rather than have to use RED.nodes.getNode() at all.

Thanks everyone.
So I pretty much finished this earlier today (bar some tidy ups) & luckily aligns with most of what you guys suggest.
But - when it comes to naming "Link In" nodes and raising an error because two "Link In" nodes (on different flows) have the same name, it became obvious extra consideration for "copy/paste-ability" was needed because this is a common design pattern.  i.e. Not permitting same named "Link In" nodes on different TABS would mean a flow would have to be edited when a flow is duplicated onto a separate TAB - both inconvenient and preventing common design patterns
So instead of raising an error, I added the ability to scope the target to "local" and "global" using a C++ like scope resolution operator syntax (scope::target) thereby by permitting the "Link Call" to target a "Link in" on the same flow simply by specifying the "link name" only syntax & for targeting links on another flow, via a fully qualified name "flow name::link name" syntax
Note: Before I added the scoped string syntax, I first made the scoping work via an object...
msg.target = {flowName: "the ::main:: API", linkName: "my_link" }

A happy side effect of this is that it permits calling a "Link In" node someone has called "my::subroutine" on a flow named "my::main::API" 😄
Example...

msg.target
"Link Call" node on flow
Calls...

"Link 1"
Flow 1
Link 1 on Flow 1

"Link 1"
Flow 2
Link 1 on Flow 2

"Link 1"
Flow 3
Link 1 on Flow 3

"Flow 1::Link 1"
Flow 1
Link 1 on Flow 1

"Flow 1::Link 1"
Flow 2
Link 1 on Flow 1

"Flow 1::Link 1"
Flow 3
Link 1 on Flow 1

"Flow 2::Link 1"
Flow 1
Link 2 on Flow 1

"Flow 2::Link 1"
Flow 2
Link 2 on Flow 1

"Flow 2::Link 1"
Flow 3
Link 2 on Flow 1

"Flow 3::Link 1"
Flow 1
Link 3 on Flow 1

"Flow 3::Link 1"
Flow 2
Link 3 on Flow 1

"Flow 3::Link 1"
Flow 3
Link 3 on Flow 1

Difficulties

When a flow name is changed the "Link In" nodes need to rebuild their cache entry so I had to subscribe to the flows-started event to essentially tell every Link in to "re-register" in the (local) global cache.

Questions

The Fully Qualified a C++ like scope syntax for calling a Link In on a different flow is currently "flow name::link name" - does anyone have a preference?  I did consider / and // and others, but when I thunk back to my C++ days, I stopped at :: - open to suggestions :)
For now, both the simple string AND the object syntax can be used to call the remote "Link in" node. Should I remove the Object call type (leaving the string syntax only)?

I think the rules should be, given msg.target set to FOO:

if there is exactly one node called FOO, call it
if there are more than one matching node

if there is exactly one matching node on the same flow as the Link Call node, then call it.
otherwise do nothing/log a warning (tbd)

Supporting a 'fully qualified' name is a nice idea - but I'm slightly hesitant. How likely is it a user will want multiple identically named Link In nodes on different flows and be able to call out to a different one (rather than modify the name to ensure uniqueness)?
If we do choose to support it, I would stick with just a string type property, and I would use / as the separator. That's familiar and consistent with file paths, MQTT topics, npm package names - I don't feel the need to mixing C++ style syntax that isn't as familiar to the JavaScript world.

Supporting a 'fully qualified' name is a nice idea - but I'm slightly hesitant. How likely is it a user will want multiple identically named Link In nodes on different flows and be able to call out to a different one (rather than modify the name to ensure uniqueness)?

I do have use cases (like if flow TABs were named according to a location for example, I would automate the Link Calls target to msg.target = `${location}/standard_function`;) but also, I would not want to accidentally call something on another flow TAB should I misspell the name (or the automation specified a wrong name). By scoping we limit "damage" to the local flow tab.  Lastly, having to rename the other flow "Link In" nodes because we dont support scoped calling would mean, in some automation cases, having to create a lookup or use a switch node when a common pattern design was desired.
I would like the scoping part to make the cut so will finish up and raise PR for review - we can thrash it out there 😉

Really ? that sounds very fragile if you add another location - you then need to add another call to match - would you not just pass in the location as a variable in the msg ?  In the simple case where I have (say) a tab where I keep all my call flows - can I just call it from another page with just its simple name (as per when I click on the list of nodes today) ? or do I now have to use the long name ?

@dceejay  not sure which comment your "really?" is refering to.

can I just call it from another page with just its simple name (as per when I click on the list of nodes today) ?

Yes. Point 1 in my list is exactly that. If there is precisely one node named FOO (wherever it may be) then it is called.

Ok, as you 2 ganged up on me I have reneged 😆

I have removed calling a target by object (string only now)

While I think this could be useful, it can safely be added later in a compatible manor

Targeting rules...

I have removed the scoping - only call by name & call by node.id are supported.
If link-in "FOO" exists once, it is called ✅
if link-in "FOO" exists on 2 regular flows, but one of them is the same flow tab as the Link-Call, the local Link-in is called. ✅
if link-in "FOO" exists on twice on the same flow, an error is raised ❌ (dynamic mode only)
if link-in "FOO" exists on 2 different flows an error is raised ❌(dynamic mode only)
if the target does not exist, an error is raised ❌(dynamic mode only)
if the target is a node.id, that is called, regardless of which flow tab it exists. ✅

On top of that, i had fun figuring out how to get this to work in a subflow.
I have found that in a regular flow, the n.links prop is an array. In a subflow, it is a string.
I did try to track this down but it went deep into the bowels of the runtime and flow diffs.
For now, I simply do a test...
const staticTarget = typeof n.links === "string" ? n.links : n.links[0];

... If either of you guys have an idea, we can fix this (or just continue to handle it)
NOTE: The export of a subflow with link nodes actually exports the links prop as an array of string!
Lastly, I have added tests...

should call link-in node by name and get response
should timeout waiting for link return
should raise error due to multiple targets on different tabs
should raise error due to multiple targets on same tabs

The branch is here: https://github.com/Steve-Mcl/node-red/tree/dynamic-link-call
If there is anything I've missed, let me know.
I will push PR Monday.

You cannot use link nodes going in to a subflow
You should be able to use a link call node calling out of a subflow

I have found that in a regular flow, the n.links prop is an array. In a subflow, it is a string.

That doesn't sound right. There should be no difference. We will need to investigate what's happening there rather than work around anything.
I think there's an open issue around link nodes and subflows, but I don't recall the specifics (not in a position to go searching)

@dceejay

Re Q2 - not sure I understand - surely the link call node already does call link in nodes ? What else can it call ?

I should have been more explicit lol.  To paraphrase...
Should a subflow instance be able to call out of itself to a link in node that lives in the regular flows.  I'm torn. It goes against PURE  principles but others might think it is unnecessarily restrictive if we prevent it.

@knolleary could you please link this to PR #3463

Hi - I did not know this is in development. So Thank You for that. This allows me to put some plan to phase out action flows.
Plus brings it into the fold of core development - rather than custom nodes which as we see may not be maintained.
My team has been bugging me for some time now to look for alternatives in view of 2.2 issues with action flows.
And apologies for butting in - please feel free to ignore.
My 2 cents :-
I am assuming You are doing GUI changes to make this explicit. If not you may ignore the #1.
#1)
If i understand the above discussion correctly - in case of dynamic Link Call - the proposal is to set msg.target and then call the link in with value (name/id) set in msg. target ?
If so, wouldn't it be better for user to allow to set name of attribute from msg which can be used to get Link IN node name.
Else you have multiple sequential calls to different Link IN nodes - before each call , a set node for msg.target would be needed to set to the correct name. Rather i would simply say when calling Link Call node - use attribute msg.x for this call or attribute msg.y on other.
Example :-
inject---> Link Call (msg.a) ----> function node ---> Link Call (msg.b) ---> and so son.
So i set msg.a and msg.b when defining the flow. And how to set those is my handls which i may do in inject node or as part of my process initialization.
If i have msg. target - it means before each Link Call - we need a Set node - thereby increasing the number of nodes. Not sure if it really helps. Once the user goes for dynamic option exists with user - its his responsibility.

#2)
I saw a comment :-
if the target does not exist, an error is raised ❌(dynamic mode only) --> Wouldnt making  it pass through i.e the msg simply passes to the next node .... make it more flexible.
Maybe add a warning . This way user knows.
This way if user wants to have dynamic flows - it allows him to do so. Giving an error means even when the node should be a dummy call - he needs to create dummy flow so as things will not fail. i.e un-necessary clutter when can be avoided.
If you really think you want to make it - error - give the option to the user if he wants it to error.
Once again Thank You for above.


Candle stick chart

Hello!
I really like this library, but wondering if I could customize it to have a candle stick style?
Currently trying to understand how the lib works, but it you have some time, it would help a lot...
Thanks in advance.

Hello! Vico doesn’t yet include such a chart type, but we plan on adding more chart types, including candlestick charts, in the future. The API is quite flexible, so I believe it would be possible to write a Chart implementation that draws candlesticks, but you’d have to create a custom ChartEntry implementation too (since here you’d need four y values per entry, not just one).

Hi @jibe-n, the candlestick chart in the core module is mostly done. We need to add some Jetpack Compose and Views specific support for it, but our priority currently has been shifted to other features and improvements.

is there any update on this? i'm looking for candlestick chart too

Hi @makaronis, no updates since my last comment. I want to resume work on candlestick chart once #87 is done, and it’s nearly complete.

Hi @Gowsky , what's missing from current realization of that chart? i'we seen branch with that code

The API probably needs some tweaks, and we need to add missing documentation.


Migrate to nft.storage

https://nft.storage/api-docs/

https://github.com/jigglyjams/nance-ts/commit/d48543c0d1cb5f28c32650740a06f7e17d926fbb


chore: add fzf-lua highlights

https://github.com/ibhagwan/fzf-lua

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


Rip tunes out of Arduboy lib

Reference:
http://community.arduboy.com/t/atomic-puzzle-pack-beta-version/459/22
I think this needs to happen.  People want to do different things with audio (and I don't blame them, tunes kind of sucks) and it's impossible because we use ISRs for timer 1 and 3, which a lot of audio stuff also uses.  As long as audio.cpp is getting compiled it holds those vectors and no other compiled software can use them... so it's impossible to replace tunes with something else... so that causes people to hack the library and create custom versions of it that then make upgrading to later versions of the library hard (or impossible).
Ripping out tunes would solve the need for this hacking.  I propose we split what we've already done into ArduboyTunes and then a program would look something like:
Arduboy arduboy;
ArduboyTunes tunes;

// code
arduboy.audio.begin();
tunes.begin();
if (arduboy.audio.enabled()) {
  tunes.playSong(...)
}

This single issue would also close 2-3 related issues.

Doing this should allow me to then pretty easily fix Puzzle Pack by replacing tunes with it's own custom SFX library.

@davidperrenoud To do this you'd need to create a new "ArduboyTunes" repository and give me access to that also.  Then I'd have everything I needed to split this up.  Tunes example would probably move to that repository.

and it's impossible because we use ISRs for timer 1 and 3, which a lot of audio stuff also uses.

Not to mention that it breaks PWM for the RGB LED.

I think this is a great idea. There is a huge community of people interested in using the Arduboy for making music. Separating out the audio portion from our libs would make it easier to hack on. As long as we provide some solution with the library, that is easy to use for new programmers, I think it would be a huge benefit to pull the audio portion out into its own module. We can get a new repo open on this account whenever for it.

As long as we provide some solution with the library

The solution would be "pick a library of your choice" and ArduboyTunes would be the crappy choice... with the nicer tracker/4 channels choices being nicer if they can spare the room.
The Arduboy library itself would just manage audio on/off settings, nothing more.

Please make an ArduboyPlaytune repository and give me access.

Ping.

Is ArduboyAudio a candidate as name? We might as well let the name help explain the library use, and keep it simple for users new to the Arduboy library.

It's NOT our library. It's the Playtune library with support for Arduboy. It already has a name. I'm not comfortable stealing their hard work and then just renaming it.

Ah that helps, thanks

This is essentially done.  How do we want to get it released?

We do have to think about this a bit. We want to keep it as simple for the user as is possible. All of the solutions I can think of now involve the user having to do multiple steps. It's not totally unreasonable to push it as a separate library, but it adds a step to a process that is already confusing for a decent percentage of the users.
Can we utilize define blocks elegantly to include the source for the ArduboyTunePlayer in the master branch, but not have it excluded unless a pre-processor directive is defined? It would be nice if everyone could get up and running with the Arduboy Library in one step, which is including the library from the arduino index.

No this isn't a define type problem, defines can't help someone using libraries because you can't set defines that affect the library.  ArduboyLib compiles however it wants and your sketch can't make it compile differently.  To set a define you have to hack the library directly - which is exactly what we are trying to get people to stop doing.
This is going to break things, no way around it - the question is how to best approach that - not how to avoid it.

It seems like the best time to do this would be NOW while as few games as possible are production ready and then get authors to move those games to the new API... then we're golden.

One can't easily use multiple library versions with the IDE, or can you?

Actually the IDE makes it pretty easy to swap versions... so I think you could say these gamea compile with 1.1 and these games compiled with 1.2+.

We do have to think about this a bit. We want to keep it as simple for the user as is possible. All of the solutions I can think of now involve the user having to do multiple steps. It's not totally unreasonable to push it as a separate library, but it adds a step to a process that is already confusing for a decent percentage of the users.

It's not an added step, it's a step.  Tunes sucks and a lot of sketches are going to use better stuff - spec once the new stuff JO3Ri it working on is done.  So they will have to install a SFX library one way or another - it's just a matter of which one it is.  And diff sketches will require diff libraries - that's just how libraries work.
So users wanting to compile from source would have to read the READMEs, make sure they have all the pre-requisite libraries, then compile.  The way around this is binary distributables.

I'm sure y'all are expecting another "long winded" response from me, as you've come to know and love, so here it is. :smile:
We want to make things as easy as possible for beginning developers but also separate tunes into it's own library, which makes using it slightly more complicated than before. I think we can make these issues mutually exclusive. Let's separate tunes into it's own library, using PR #106 as a base, but...
A beginner is going to want to add audio to their game but most likely, at first, this would just be "beeps" and "boops", when the ball bounces off the paddle or a projectile annihilates the monster. Or maybe for a three or four note melody at the start or end, or when entering a new level. For this, just having the equivalent of Arduino tone() would be sufficient. (Indeed, it's also sufficient for a good many advanced games, as is the case for some existing ones, ArduBreakout being but one.) So let's build just the equivalent of tone() and noTone()  directly into the Arduboy library, with the only difference from the Arduino versions being that a pin doesn't have to be specified, and they will honour the global, non-volatile, EEPROM based mute capability that we've already devised.
For more advanced developers, or beginners who want to learn how to use it, the ArduboyPlaytune library will be available. We don't need any #defines or such to try to make it easier. We just document it well enough so developers can use it, just like any other Arduino library, such as those for stepper-motors, temperature sensors, etc.
We would probably want to refrain from expanding the Arduboy library itself beyond providing only tone() and noTone() for audio generation. Anything above that would be the work of external libraries, such as ArduboyPlaytune.
For the Arduboy library:
For starters, the ArduboyAudio class is quite small and simple now. I don't think it needs to be a separate sub-class. Let's just move its functions directly into the Arduboy class, adding audio to the beginning of each function. After all, we don't have display or buttons sub-classes. This makes it easier for beginners.. They don't have to wonder why they have to use the strange syntax arduboy.audio.on() instead of arduboy.audioOn(). If desired, the function prototypes and code, etc. could still remain in separate audio.h and audio.cpp files, as they are with core, but not as a sub-class.
Next, I'd make audioOn() and audioOff always set the state in EEPROM, instead of requiring the extra step of calling audioSaveOnOff() to do it. This is another simplification for beginners, and I don't think it causes any problems. There's a chance that a more advanced developer may wish to only temporarily set the on/off state without saving it to EEPROM, but this could be accomplished by making the audioEnabled  (formerly audio_enabled) variable public and allow them to directly set it true or false. Also with audioEnabled exposed, there isn't a need for the audioEnabled() function but it could be kept if desired.
I don't think we need audioBegin() (at least as a public user function). Just do what's necessary in the Arduboy constructor or in boot(). We just need to read EEPROM_AUDIO_ON_OFF and set audioEnabled accordingly, and set speaker pin 2 to output low.
Finally, we add tone() and noTone() functions, which could actually call the Arduino versions:
void Arduboy::tone(unsigned int frequency)
{
  if (audioEnabled) ::tone(PIN_SPEAKER_1, frequency);
}

void Arduboy::tone(unsigned int frequency, unsigned long duration)
{
  if (audioEnabled) ::tone(PIN_SPEAKER_1, frequency, duration);
}

void Arduboy::noTone()
{
  ::noTone(PIN_SPEAKER_1);
}

Of course, we could use our own code, instead of the Arduino tone() and noTone() if it turns out to be necessary or better.
The new versions of the remaining audio functions:
// Private function, called from the constructor or boot()
void Arduboy::audioBegin()
{
  audioEnabled = EEPROM.read(EEPROM_AUDIO_ON_OFF);
  pinMode(PIN_SPEAKER_2, OUTPUT); // I still think this could just be added to pinBootProgram[]
  digitalWrite(PIN_SPEAKER_2, LOW);
}

void Arduboy::audioOn()
{
  audio_enabled = true;
  EEPROM.update(EEPROM_AUDIO_ON_OFF, true);
}

void Arduboy::audioOff()
{
  audio_enabled = false;
  EEPROM.update(EEPROM_AUDIO_ON_OFF, false);
}

// Optional. User can just use the public audioEnable variable.
bool Arduboy::audioEnabled()
{
  return audioEnabled;
}

For the ArduboyPlaytune library:
Nitpick: Decide whether "tune" is capitalised in camelCase or not (I think not). If the actual class and file names use ArduboyPlaytune, then the repository should be the same, not ArduboyPlayTune
Keep the library as is, except:
It should honour the audio on/off state and remain silent if audio is off. It doesn't have to actually be able to change the state. This can, and should, still be done using Arduboy::audioOn() and Arduboy::audioOff().
The problem is how to make ArduboyPlaytune aware of the current audio state. I'd suggest we just pass Arduboy::audioEnabled, as a pointer, as an ArduboyPlaytune constructor parameter:
ArduboyPlaytune tunes(&arduboy.audioEnabled);
Yes, instantiation is a bit more complicated for the sketch developer, but as has been said before, that's what documentation is for. And remember, we assume a more advanced developer at this point, because we have easy to use tone functions in the Arduboy library for beginners.
The constructor would save the Arduboy::audioEnabled pointer to its own private pointer variable, for use by all other functions to decide whether to mute or not.
Alternatively we could pass a function pointer, or a pointer to the entire Arduboy class, but I think either of these would just make for more and slower code.
ArduboyPlaytune tunes(&arduboy.audioEnabled());
ArduboyPlaytune tunes(&arduboy);
The ArduboyPlaytune library should retain its own version of tone(), in case the one built into Arduboy causes conflicts, now or in the future.
End of sermon. Time for objections.

So let's build just the equivalent of tone() and noTone() directly into the Arduboy library, with the only difference from the Arduino versions being that a pin doesn't have to be specified, and they will honour the global, non-volatile, EEPROM based mute capability that we've already devised.

No, because this requires tone() (or us to rebuild tone with the same interrupts) and then we have a sound library and no way for others to choose a different sound library.  Someone who wants to use tone can use the official tone library and pass a speaker pin - or write a wrapper if that's too hard.
We could include a sample wrapper somewhere (no to be compiled) that showed how to use tone with the audio API, but it can't be part of the core library.

The problem is how to make ArduboyPlaytune aware of the current audio state. I'd suggest we just pass Arduboy::audioEnabled, as a pointer, as an ArduboyPlaytune constructor parameter:

Interesting, I've been giving some thought to this... this doesn't allow audio to hook functions though.. I had imagined passing on and off function pointers, but I was going to review this when I reworked the Puzzle game to work with Audio and see what worked best.

The ArduboyPlaytune library should retain its own version of tone(), in case the one built into Arduboy causes conflicts, now or in the future.

Again, it can't.  The problem tone causes conflicts is because it uses interrupts for the tones, and we'd cause the same conflicts if we did it ourself.

.  This makes it easier for beginners. They don't have to wonder why they have to use the strange syntax arduboy.audio.on() instead of arduboy.audioOn()

It's not that strange, plus this is really a separate discussion.  I'd like to perhaps namespace a few other internals in the future (frame management, etc) so I'm not sure we want to start walking the opposite direction,

We could include a sample wrapper somewhere (no to be compiled) that showed how to use tone with the audio API, but it can't be part of the core library.

Great use for a example perhaps?

No, because this requires tone() (or us to rebuild tone with the same interrupts) and then we have a sound library and no way for others to choose a different sound library.

If the sketch developer doesn't use Arduboy::tone() or Arduboy::noTone() then they won't be compiled in. The developer will be free to use a different sound library without conflict. It's no different than wrapping  Arduino tone() within the sketch itself or not.
The user could still use the rest of the Arduboy library audio functions to control audio on/off.

The ArduboyPlaytune library should retain its own version of tone(), in case the one built into Arduboy causes conflicts, now or in the future.

Again, it can't. The problem tone causes conflicts is because it uses interrupts for the tones, and we'd cause the same conflicts if we did it ourself.

So then are you going to remove tone() from ArduboyPlaytune?

If the sketch developer doesn't use Arduboy::tone() or Arduboy::noTone() then they won't be compiled in. The developer will be free to use a different sound library without conflict.

We have to require Tone to reference those functions, that will result in the ISR getting compiled, ISRs are always compiled and that is what causes the conflicts with other libraries.

It's no different than wrapping Arduino tone() within the sketch itself or not.

It's very different because in this case the sketch calls require, if the sketch doesn't call require Tone is not required and the ISR is never compiled.

So then are you going to remove tone() from ArduboyPlaytune?

I don't plan on doing much with playtune after it's removed.  We can't remove tone though because if you use Playtune and want to generate a tone the only way to do so is to have a built in method for it - since the Tone library can't be linked because of the ISR conflict.

ISRs are the exception to every rule since they are called by the CPU itself, not your compiled code.

We have to require Tone to reference those functions, that will result in the ISR getting compiled, ISRs are always compiled and linked and that is what causes the conflicts with other libraries.

OK, understood. That's why I wrote:

Of course, we could use our own code, instead of the Arduino tone() and noTone() if it turns out to be necessary or better.

Necessary being the key word here.
So we write our own code for Arduboy::tone() and Arduboy::noTone(), and  add another function Arduboy::tonesBegin(), which sets up the ISR. If the sketch doesn't call tonesBegin() then the ISR isn't set up (and obviously Arduboy::tone() and Arduboy::noTone() can't be used). Other audio libraries can then be used without conflict. If desired, we could add Arduboy::tonesEnd() to disable the ISR. Is this viable?
The original tone library could possibly be used as a base, or what's in ArduboyPlaytune.

Of course, we could use our own code, instead of the Arduino tone() and noTone()

Unless tone() is to be a BLOCKING function (i.e. nothing else happens while the tone run), then you have to do it with ISRs, and that means you're right back to the same way tone does it so it's the same as using tone (with all the same disadvantages).  One could easily write a blocking tone (provided that microseconds were a good enough measure of time to do frequencies).  That's essentially all the boot noises I wrote before were - blocking tones.

Arduboy::tonesBegin(), which sets up the ISR.

You can't do this, the ISR has to be in the vector table and that's setup at compile time (because the vector table exists statically at the beginning of flash memory).  The Arduino code that makes it appear like you can do stuff like this really just sets up a static ISR and then uses C glue to build a jump table ofh function pointers... there is no magic way to swap ISRs wholesale across multiple libraries.  Inside a library you could build your own proprietary system (like Arduino does), but with multiple libraries trying to latch onto the same ISR vectors C is going to yell loudly and shut you down.

You can't do this, the ISR has to be in the vector table and that's setup at compile time (because the vector table exists statically at the beginning of flash memory).

OK, got it. So I guess the Arduboy library audio support will just be functions for enabling and disabling sound, which is only of use if code that actually generates the audio uses these functions.

We could include a sample wrapper somewhere (no to be compiled) that showed how to use tone with the audio API, but it can't be part of the core library.

For just simple tone() and noTone() functions, this might be the best approach for beginners, or sketches that don't require anything more.
A file containing the sample code could be put somewhere under the extras folder for savekeeping, but for a sketch developer, it would probably be easiest to have them just copy and paste the code directly from the documentation into their sketch. If our online documentation could implement a "get code" feature, like is done with Arduino tutorials, such as near the bottom of this one, it would make it a bit easier. We would just say:

Click on [Get Code]
Copy the code to the bottom of your sketch.
If <name> is something other than arduboy in the Arduboy <name>; line near the top of your sketch, then change the two instances of arduboy.audioEnabled to <name>.audioEnabled
Functions aboyTone(<frequency>), aboyTone(<frequency>, <duration>) and aboyNoTone() work the same as the Arduino tone() and noTone() functions except you don't have to provide a pin number.

The code would be:
void aboyTone(unsigned int frequency) {
  if (arduboy.audioEnabled) {
    tone(PIN_SPEAKER_1, frequency);
  }
}

void aboyTone(unsigned int frequency, unsigned long duration) {
  if (arduboy.audioEnabled) {
    tone(PIN_SPEAKER_1, frequency, duration);
  }
}

void aboyNoTone() {
  noTone(PIN_SPEAKER_1);
}

Are removing the ArduboyAudio subclass, and having audioOn() and audioOff() write EEPROM immediately, still good ideas?
Regarding thoughts on passing audioOn(), audioOff, etc. as function pointers to an audio library such as ArduboyPlaytunes, I think it would be wiser to have the Arduboy library itself be the only thing controlling on/off. The audio library would just act on the state dynamically, by reading the value at the Arduboy::audioEnabled pointer, that it was passed.
Handling volume control is a bit trickier. It would likely be best if the Arduboy library handled this as well, the same as on/off. However, not knowing the levels supported by the particular audio library, it would have to blindly allow setting values from 0 to 255.
Maybe volume isn't something we want to save in system EEPROM. Just have volume control be volatile and handled by the sketch itself, based on the capabilities of the audio library used. This is where EEPROM management for sketches would come in handy, so each game could individually save it's last volume level, if desired.

could be put somewhere under the extras folder for savekeeping,

Why not just a demo?

Are removing the ArduboyAudio subclass, and having audioOn() and audioOff() write EEPROM immediately, still good ideas?

I'm still thinking about that, sep issue - lets try not to confuse all sorts of things.  That makes more sense if there is a mute.  I'm not sure someone turning on/off audio in a game should override the system default that they set using the boot tool.  Can you open a separate issue to discuss this?

The audio library would just act on the state dynamically, by reading the value at the Arduboy::audioEnabled pointer, that it was passed.

Exception reading is expensive depending on the audio library... does it read it every time it flips a pin for a frequence and use 50% of the CPU?  Does it do it ever 1ms?  Every 10ms?  Might be easier to have it NEVER poll and just tell it when the audio state changes.  I'll know more when I actually TRY this.

Handling volume control is a bit trickier. It would likely be best if the Arduboy library handled this as well, the same as on/off. However, not knowing the levels supported by the particular audio library, it would have to blindly allow setting values from 0 to 255.

I'd like to consider saving some bits in the storage for data checksums (so in the future we could know if there data there was valid or just random junk), but otherwise I agree with this.  I'm not sure we need two set bytes for on/off vs volume though.
[on/off] [reserved 3 bits] [volume level 4 bits]...
That's 16 volume levels... 5 bits would give you 32 volume levels... I'm not sure we need to adjust it anymore than that.  So volume and on/off are individual settings, but single byte of storage.

The audio library would just act on the state dynamically, by reading the value at the Arduboy::audioEnabled pointer, that it was passed.

You have to realize we're also looking at working with EXISTING audio libraries... that likely don't support passing in a flag.  But they may support stop/start audio... or something similar... this is why I say it needs more research.  The more stuff we can make easily work with audio the better.

Maybe volume isn't something we want to save in system EEPROM. Just have volume control be volatile and handled by the sketch itself, based on the capabilities of the audio library used.

I think saving it one place is better than many. :-)

could be put somewhere under the extras folder for savekeeping,

Why not just a demo?

In my opinion, anything in the examples folder should compile and load and do something. If it was a working sketch that used the functions, and the section of code that needed to be copied and pasted into your sketch was well delimited and commented, then that would be fine.

Right, it would be a nice example of using abstracted Tone methods with Arduboy. :-)  Just a thought.


Failed to create a Container Manager: mountpoint for cpu not found     at run cadvisor  docker image

error info
 cadvisor.go:152] Failed to create a Container Manager: mountpoint for cpu not found

Linux version
Linux version 5.15.0-52-generic (buildd@lcy02-amd64-032) (gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022

from the issue
Try replacing image by gcr.io/cadvisor/cadvisor

I change docker image , from  image: google/cadvisor:v0.33.0    to image: gcr.io/cadvisor/cadvisor.
The error is to fix
docker compose config file

After changing my logs looks like:
W1026 14:24:19.027828       1 manager.go:159] Cannot detect current cgroup on cgroup v2

@KES777
docker info

what info do you get ?
I used  Ubuntu 22.04.1 LTS
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

you can try  it.

docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.10.2)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 26
  Running: 18
  Paused: 0
  Stopped: 8
 Images: 31
 Server Version: 20.10.18
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.0-52-generic
 Operating System: Ubuntu 22.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.738GiB
 Name: ubuntu-2gb-nbg1-2
 ID: X6IR:CQPM:NB3G:ZGBT:WWGU:UIC3:UDD4:TPNV:GHFF:4GRR:YVKC:OUMF
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

# uname -a
Linux ubuntu-2gb-nbg1-2 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I found that my system lack of cpu,cpuacct. This answer makes cAdvisor container to start:
mkdir /sys/fs/cgroup/cpu,cpuacct
mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct

But after server reboot, I need to type it again... =(
Also recommended this: https://stackoverflow.com/a/32878801/4632019 (will trying it now)

Adding --exec-opt native.cgroupdriver=cgroupfs into /lib/systemd/system/docker.service, eg. ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=cgroupfs
Seems resolve problem. Now cAdvisor container starts, despite it still has this log message:
W1026 16:04:30.285638       1 manager.go:159] Cannot detect current cgroup on cgroup v2

docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.12.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 13
  Running: 6
  Paused: 0
  Stopped: 7
 Images: 16
 Server Version: 20.10.20
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.0-52-generic
 Operating System: Ubuntu 22.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 1.93GiB
 Name: monitor
 ID: xxx:xxxx:Xxxx
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: xxxx
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Registry Mirrors:
  https://registry.docker-cn.com/
  http://hub-mirror.c.163.com/
  https://docker.mirrors.ustc.edu.cn/
  https://zrb2xl6u.mirror.aliyuncs.com/
 Live Restore Enabled: false
 Default Address Pools:
   Base: <IP_ADDRESS>/16, Size: 24
   Base: <IP_ADDRESS>/16, Size: 24
   Base: <IP_ADDRESS>/16, Size: 24

compose is not same
do you  try from  https://unix.stackexchange.com/questions/471476/how-do-i-check-cgroup-v2-is-installed-on-my-machine  ?

# grep cgroup /proc/filesystems
nodev	cgroup
nodev	cgroup2

# stat -fc %T /sys/fs/cgroup/
cgroup2fs

Yes, seems not activated on my host. --exec-opt native.cgroupdriver=cgroupfs option helped.

@KES777      Do you solved your problem?

Strange: not installed, but up to date :D
# apt remove -y docker docker-engine docker.io containerd runc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'docker-engine' is not installed, so not removed
Package 'containerd' is not installed, so not removed
Package 'runc' is not installed, so not removed
Package 'docker' is not installed, so not removed
Package 'docker.io' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.

 sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
Hit:1 http://apt.postgresql.org/pub/repos/apt jammy-pgdg InRelease
Hit:2 https://download.docker.com/linux/ubuntu jammy InRelease
Hit:3 https://mirror.hetzner.com/ubuntu/packages jammy InRelease
Hit:4 https://mirror.hetzner.com/ubuntu/packages jammy-updates InRelease
Hit:5 https://mirror.hetzner.com/ubuntu/packages jammy-backports InRelease
Hit:6 https://mirror.hetzner.com/ubuntu/security jammy-security InRelease
Hit:7 https://swupdate.openvpn.net/community/openvpn3/repos jammy InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
6 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: https://swupdate.openvpn.net/community/openvpn3/repos/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
containerd.io is already the newest version (1.6.9-1).
docker-ce-cli is already the newest version (5:20.10.21~3-0~ubuntu-jammy).
docker-ce is already the newest version (5:20.10.21~3-0~ubuntu-jammy).
docker-compose-plugin is already the newest version (2.12.2~ubuntu-jammy).
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.

# docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.12.2)
  scan: Docker Scan (Docker Inc., v0.21.0)

Server:
 Containers: 27
  Running: 12
  Paused: 0
  Stopped: 15
 Images: 29
 Server Version: 20.10.21
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1c90a442489720eec95342e1789ee8a5e1b9536f
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.0-52-generic
 Operating System: Ubuntu 22.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 7.578GiB
 Name: ubuntu-2gb-nbg1-2
 ID: X6IR:CQPM:NB3G:ZGBT:WWGU:UIC3:UDD4:TPNV:GHFF:4GRR:YVKC:OUMF
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

After all of this situation is same: container is working, but message still exists.

I don't know how to solved it , said.

No problem.

I use google/cadvisor:canary  the image is ok. @KES777

I switched to: image: gcr.io/cadvisor/cadvisor


Unclear on special characters

"prefix those special characters with an escape code (_x) and the 4-digit Unicode" but the examples show "Table Name" as Table_x0020_Name which has a prefix and a suffix of _. Which is it?

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

ID: 70b360f3-21a7-adc2-896a-b1dfd5d9e384
Version Independent ID: 15e8c09f-46ad-68f9-75e6-c3d5c2c214e5
Content: Add Power BI report parameters using the url - Power BI
Content Source: powerbi-docs/service-url-filters.md
Service: powerbi
GitHub Login: @mihart
Microsoft Alias: mihart

Great catch, @o-o00o-o! The article is unclear. Turns out you also need the underscore after the 4-digit Unicode value. I'll update the article to state that.

Done


ENH: lazy init for pandas fallback

What do these changes do?

Related issue number

Fixes #304
Check code requirements

[x] tests added / passed (if needed)
[x] Ensure all linting tests pass

https://github.com/xprobe-inc/xorbits/blob/main/python/xorbits/pandas/__init__.py#L49 collect_pandas_module_members cannot pass pandas, could you open a PR to fix it and add tests to cover this issue?


Add RSA OAEP (padding) support for Oauth2

When encryption is enabled for oauht2 keys, from now on it will use RSA OAEP padding for encryption.
Since the encrypted value can be dynamic, we will use both hash and encryption .
public jira: https://wso2.org/jira/browse/IDENTITY-7301

List of PRs related to the fix:
[Carbon-kernel]
1.https://github.com/wso2/carbon-kernel/pull/1697
2.https://github.com/wso2/carbon-kernel/pull/1698
[Identity-framework]
1.https://github.com/wso2/carbon-identity-framework/pull/1357
[identity-inbound-auth-oauth]
1.https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/807


Missing some files required by tests

The data submodule is missing some files required by tests. I added them in https://github.com/LLNL/SSAPy-Data/pull/1 but I'm opening this issue for tracking (since the submodule will need to be bumped).

@igoumiri Check out https://github.com/LLNL/SSAPy/pull/2. I want to use Git LFS to store these files in the SSAPy repo rather than having them external to this repo and in a submodule. Even if these files are in a submodule, they are too big to be uploaded to GitHub and would need to be split into pieces for storage on GitHub and recombined before being used on the users computer.


Add MustVerifyEmail

Added support for Laravel authentication when users need to check their emails to connect

Not everyone needs this trait though. Also I think Laravel doesn't ship with it out of the box.

@nicolasyousician, It does.

MustVerifyEmail is a trait provided as standard by Laravel in any install.


could not be installed in prestashop 1.7

Hello Prestashop-Colleagues,
great to see that there is a sitemap module availabe, but, I just tried to use this module with prestashop <IP_ADDRESS> and it is not possible to install, because of
"incorrect zip format of module" (translated freely from german).
Should this work already for prestashop <IP_ADDRESS> - or is it not working?
and if this one is not working, any ideas where i can find a working sitemap module for prestashop 1.7 (multishop)?
thanks in advance
tom

I think you need to buy some other module... I have the same problem, but everything is for sale on prestashop marketplace...

Thank you for your report! This issue is fixed here: https://github.com/PrestaShop/gsitemap/pull/53

Sorry to reopen this issue, but I followed all the #53 and I also downloaded a fresh version of this module but I still get the same error as the OP on PS <IP_ADDRESS>.
Since I have plenty of sandboxes I also tried it on a fresh install, but that didn't change the outcome.
Unfortunately there's no log in the error log file.
FWIW if you unzip the folder in the modules directory it obviously works.
Thx in advance,
Aaron.


why put the cursor to the end when press tab?

The source code like this,
        case 9: // tab
          var nextTab
          if (nextTab = this.getNextTab(),nextTab != null) {
            // Get the nextTab if exists
            var that = this
            setTimeout(function(){
              that.setSelection(nextTab.start,nextTab.end)
            },500)

            blocked = true
          } else {
            // The next tab memory contains nothing...
            // check the cursor position to determine tab action
            var cursor = this.getSelection()

            if (cursor.start == cursor.end && cursor.end == this.getContent().length) {
              // The cursor already reach the end of the content
              blocked = false

            } else {
              // Put the cursor to the end
              this.setSelection(this.getContent().length,this.getContent().length)

              blocked = true
            }
          }

There are some case whereas the editor instance need to backward, eg : when you select an image. The editor will allow you to rewrite the image title/tag, then after there is no next tab in its memorythe editor will put the cursor at the end on the line. Thats the story behind this behaviour, and i think its pretty sensible to have it as default.

I believe this is having another, unexpected, issue.
We use your library on our software, and we have had reports of the cursor being set to the end of the text field (not the end of the line) when alt-tabbing between windows, when using Windows.
If you are using a Mac, and alt-tab between windows, or even just press tab in the textarea, the tab is not recognised as a key press on the field and so the same does not occur (this is a good thing).


Fix build ordering in GeneratedLibraries.proj

Invoking the Package target (or anything that depended on it, like the
default target Repackage) would invoke BuildProjectList before Build.
Build, in turn, is what invokes Generate, so we would try to build a
list of projects before guaranteeing the projects had actually been
generated. If Src/Generated had been deleted, BuildProjectList would
build an empty list, no projects would be built, and packaging would
fail.

/cc @chrsmith @jskeet

LGTM, assuming I understand it properly.


LOVE

LOVE under S.I.L.K

This has conflicts. Will close now & try again next time.  Make your commits longer so you avoid this.
Combine 3-4 sentences all in 1 commit together.


Add script to generate unicorn script

There is some slight duplicate in shell logic but after spending a little time trying to deduplicate things,it didn't particularly feel any better and wasn't any shorter so I just left the output as a single generated verbose file. I use this script in conjunction with monit, very handy.

Spring cleaning.


[Bug/Request?] Thirst/Temperature continues while not in survival gamemode

Thirst and temperature changes while in creative mode, which makes it difficult for testing when I need to switch from creative into survival and instantly die due to hypothermia or dehydration. Also makes it a little tricky to see when I get the hypothermia screen effects while in creative. Oh, also effects the player while in spectator mode.
If it's fairly easy to disable/pause while in creative/spectator, that would be great. It's not a huge priority, and I want to keep the mod enabled while I'm testing the pack to keep track of any issues or conflicts.

I'll fix this. I noticed this while creating the book. I must have broken this with another change. The only thing that should work is the debugging display (if enabled).

The latest versions for 1.18.2 and 1.19+ on CurseForge have this fix in. Thanks again for the report.

No worries, here to help.


Ensure main_0.1 Demo App builds in Xcode 13 running on Apple Silicon machines.

Platforms Impacted

[x] iOS
[ ] macOS

Description of changes
Building the Demo App in Xcode 13 on Apple Silicon machines generates the following error:
FluentUI.Demo.xcodeproj: error: The linked and embedded framework 'FluentUI.framework' is missing one or more architectures required by this target: x86_64. (in target 'FluentUI.Demo' from project 'FluentUI.Demo')
This happens because the Demo App excludes the arm64 architecture in simulator builds (so it can link with the AppCenter framework successfully) and causes the app to be built in the x86_64 architecture.
The FluentUI and Pods projects currently do not exclude arm64 architecture for simulator builds, and as a result will not generate x86_64 arch builds on Apple Silicon machines because the default architecture is arm64 (ARCHS_STANDARD = arm64 armv7).
Given the context above, the fix is to set the EXCLUDED_ARCHS[sdk=iphonesimulator*]" = arm64  for the FluentUI and Pods projects.
Verification

Ran pod install to ensure the changes in the podfile produced the expected result in the Pods.

Built and ran the demo app on the simulator (iOS 15) from Xcode 13.1 in machines of both architectures:
-- Intel
-- Apple Silicon

Ensured that device builds and archiving was not affected by the changes as expected.

Pull request checklist
This PR has considered:

[ ] Light and Dark appearances
[ ] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[ ] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)

Microsoft Reviewers: Open in CodeFlow

hopefully it still works with older xcode as well

hopefully it still works with older xcode as well

I don't currently have any machines running an OS older than Big Sur, so I can't test old Xcode versions. But assuming someone is able to verify that, then this looks good!

hopefully it still works with older xcode as well

I shouldn't affect older versions as we're not touching any settings that were introduced in Xcode 12 or 13.
I have tested in Xcode Version 12.5 (12E262) and built with no issues.

hopefully it still works with older xcode as well

I don't currently have any machines running an OS older than Big Sur, so I can't test old Xcode versions. But assuming someone is able to verify that, then this looks good!

Validated on Big Sur (11.3.1) and Xcode 12.5 (12E262).


Crash using Network Link Conditioner - Very Bad Network

On testing using 'Very bad network' on the iOS network link conditioner, it will throw an exception after you tap:
Begin verification > begin check.
As soon as the countdown ends, it will crash. On turning off the network link conditioner, it works fine.
Thread 54: "*** -[AVAssetWriter startWriting] Cannot call method when status is 1"
Fitafy  27-06-2023, 09-02.crash.zip

I'm alleviating the crash in [VideoChunker start] with
       guard state != .writing else {
            return
        }

However, the underlying issue is still there. Likely a timing issue on the network call returning and the LivenessStateMachine I guess, as case .recording(ovalDisplayed: false): is called twice in FaceLivenessDetectionViewModel, when in 'Very bad network'.

Thanks for opening this. We'll investigate and follow up here with any updates.

I faced the same crash if liveness check session is obsolete or invalid.

Resolved in release v1.0.2.


Run report for particular tests only

For development purposes it's useful to run particular tests in isolation (for example when adding new test case).
Let's make run.sh configurable with tests (files) filter:
sudo ./run.sh "inheritance/**/*.yml"

This would run only tests under inheritance/ folder.

Done