Update hashlink.

Update hashlink to latest, and add all the hdll's required for the haxe std.
Also change the names of exported functions in lime.hdll, in the interest of making future HL/C support easier.
Closes #1516.
Tested on Linux.
Note that this does not update that HL_PATH thing in the windows tooling, someone else will have to make that copy everything instead of only ssl.hdll.

Also change the names of exported functions in lime.hdll, in the interest of making future HL/C support easier.

I'm unsure how this makes things easier. Are apps going to have to load from both lime.hdll and lime.ndll, causing name conflicts? Are you saying it's clearer to have unique names?

The fact that this is all one commit makes it hard to follow. If it was me, I'd break it up into three commits:

Fix #1516. (That's just line 3950 of ExternalInterface.cpp plus line 24 of KeyEvent.h, right?)
Update HashLink. (That's just hl.h, as far as I can tell.)
Rename the functions. (Everything else.)

Even with simple commit messages, this will make it much easier to see why each change was made. (Though for the third commit I'd recommend a sentence or two of explanation.)

Fix # 1516. (That's just line 3950 of ExternalInterface.cpp plus line 24 of KeyEvent.h, right?)

Correct

Update HashLink. (That's just hl.h, as far as I can tell.)

hl.h + the binaries

I'm unsure how this makes things easier. Are apps going to have to load from both lime.hdll and lime.ndll, causing name conflicts? Are you saying it's clearer to have unique names?

It makes it easier by doing what the haxe compiler expects us to do.
When building to HL/C, apps would have to be linked with lime.hdll.
At the moment the functions exported in lime.hdll (those marked with HL_PRIM)  are named hl_lime_foo, whereas the C code generated by the haxe compiler would expect functions with named lime_lime_foo.
Now the functions are named lime_hl_foo, and the haxe code has been changed accordingly.

I've split the commit up into three, as you suggested.

I've split the commit up into three, as you suggested.

Perfect!

hl.h + the binaries

Ah, of course.

At the moment the functions exported in lime.hdll (those marked with HL_PRIM) are named hl_lime_foo, whereas the C code generated by the haxe compiler would expect functions with named lime_lime_foo.

So you're saying HashLink/C was broken, and this was never detected because we'd only tested HashLink bytecode. (It wouldn't be the first time something like that happened...)
Just to make sure I can understand, wouldn't it have required fewer changes to switch to lime_lime_foo? You would still have needed to update all the .cpp files, but it wouldn't have required so many changes on the Haxe side of things. If you went to the extra effort, you must prefer lime_hl_foo. Is this just for clarity?

So you're saying HashLink/C was broken, and this was never detected because we'd only tested HashLink bytecode.

Yes.

Just to make sure I can understand, wouldn't it have required fewer changes to switch to lime_lime_foo? You would still have needed to update all the .cpp files, but it wouldn't have required so many changes on the Haxe side of things. If you went to the extra effort, you must prefer lime_hl_foo. Is this just for clarity?

Personally I think lime_hl_foo is clearer than lime_lime_foo.
And the only changes on the Haxe side are to the @:hlNative metadata's.
The function names on the haxe side are still exactly the same as before.

I cannot reproduce the Windows build failure on my machine, so I don't know what's wrong.
As for the Android failure, you're using API level 16, whereas uchar.h was added in API level 21.
(API level 16 is Android 4.1, which was released in 2012)
(API level 21 is Android 5.0, which was released in 2014)
According to a quick search, Android versions higher than 5.0 make up more than 96% of the Android market, so I believe it would be okay to use API level 21.
Alternatively I can try patching Hashlink, but I would really like to avoid that.

As for the Android failure, Lime seems to be using API level 16, whereas uchar.h was added in API level 21.

Huh, well that led me down a rabbit hole.
Lime targets API level 28 but loads header files from the android-16 folder. According to 6dce7ad, the folder's number has to match the minimum SDK version, which is why that's also 16.
Lime does already use android-21 for 64-bit builds, because previous ones didn't support it. Everything else uses android-16 to maximize backwards compatibility. Interestingly, the NDK we're using goes as high as android-26, but since Lime is all about backwards compatibility, that isn't likely to happen.
If you want to update the minimum SDK version - and I agree you have a good case for it - please submit it as a separate pull request, so we can discuss it separately.

We can repro the build error on Windows namely the halt at JPEG.cpp. How can we help to track the root cause down?

Does it still fail if you combine this with #1519?

That’s the only way we tried and it fails. Haven’t tried without that commit.

I'm surprised it's the same error. I don't know what's up with that, but I'll take a closer look later.

I can also reproduce the Windows error now, I think I forgot to checkout my branch when I tested it last time.
The issue is the same as here: https://github.com/native-toolkit/jpeg/pull/2.

Or to merge the pull request I linked (or even to move to libjpeg-turbo).
Personally I would prefer to keep our bundled hashlink headers as close as possible to upstream.
The less patches, the easier to update.
(Ideally we could even add upstream hashlink as a git submodule and make lime rebuild hl rebuild that too, making it a lot easier to update hashlink, it would just be a question of doing git -C path/to/hl pull origin master.)

The only modification lime makes at the moment is renaming the DEFINE_PRIM macro to DEFINE_HL_PRIM (or something like that).
There are two solutions for that:

rename the other DEFINE_PRIM
add a bunch of #ifdef so that hashlink and neko/hxcpp things are not included at the same time.

So, hashlink is now a submodule.
In theory CI should pass now (at least for Linux and macOS).
Windows requires https://github.com/native-toolkit/jpeg/pull/2.

And macOS is being difficult, as usual.
Oh well, I'll deal with that tommorow.

I think the iOS failure is because char16_t and char32_t are defined in C++ (but not C, at least on iOS).
hl.h tries to define those types, since it's included in a C++ files, we get an error.

Looks like everything is working now.

I've updated the PR to use the latest version of hashlink (1.12, which is now released).

Is there any reason why this isn't merged?

It seem to work on my machine. At least, I can rebuild lime.hdll and test DisplayingABitmap.
Looking at BuildHashlink.xml (and LinuxPlatform), it looks like lime.hdll doesn't incorporate any of the other libraries (Cairo, SDL, etc.). And that would explain why you compile lime.ndll at the same time: Hashlink apps require both. Is that right?
Yet somehow lime.hdll is slightly larger than lime.ndll... Maybe that's just because Hashlink includes its own copies of several of the same libraries (inconveniently spread across two folders).

BuildHashlink.xml builds hl(.exe), libhl.so/dylib/exe, ssl.hdll, fmt.hdll, mysql.hdll, ui.hdll and uv.hdll (these hdlls are needed for functionality of the Haxe std, eg sys.ssl depends on ssl.hdll).
On Windows these indeed use hashlink's copies of the libraries, on Linux/macOS they use system packages.
lime.hdll is still built by Build.xml and includes all of lime's dependencies (SDL, Harfbuzz, etc).
Hashlink apps do not depend on lime.ndll, only on lime.hdll (and the hashlink runtime of course)

(inconveniently spread across two folders).

/include contains the copies of the libraries, /libs contains the wrapper code.

Looking back through open issues, I came across #1524, which still needs resolution. Is fmt.hdll one of the binaries you added?

Yes, all the binaries needed for things in the Haxe standard library are added.
(See previous message.)

Oh hey, you did mention it. Whoops.

lets gooo this got merged!

If anyone has issues rebuilding after this pull request was merged, don't forget to update submodules!
I got the following error on macOS:

In file included from ./src/ui/TextEvent.cpp:1:
include/system/CFFI.h:6:10: fatal error: 'hl.h' file not found
#include <hl.h>
^~~~~~
1 error generated.

But it was an easy fix:
git submodule update --recursive

Getting the following error when I try lime test hl on macOS:

dyld[29362]: Library not loaded: @executable_path/libhl.dylib
Referenced from: /Users/joshtynjala/Development/feathersui/feathersui-openfl/samples/components-explorer/bin/hl/bin/Components.app/Contents/MacOS/Components
Reason: tried: '/Users/joshtynjala/Development/feathersui/feathersui-openfl/samples/components-explorer/bin/hl/bin/Components.app/Contents/MacOS/libhl.dylib' (no such file), '/usr/local/lib/libhl.dylib' (no such file), '/usr/lib/libhl.dylib' (no such file)

It appears to be looking for libhl.dylib in the wrong location. When I "Show Package Contents" in the .app file, it is actually located here:
/Users/joshtynjala/Development/feathersui/feathersui-openfl/samples/components-explorer/bin/hl/bin/Components.app/libhl.dylib

Hmm... I'll have to look again at were the tooling copies things.
I'd have expected it to copy the libhl library to the same place were it puts the executable (although that's not the right place for libraries iirc).

If anyone has issues rebuilding after this pull request was merged, don't forget to update submodules!

 Some code that's using executableDirectory should instead use applicationDirectory, or vice versa. Maybe this line is copying the files into the app root when it should be copying them into executableDirectory?

I'd have expected it to copy the libhl library to the same place were it puts the executable (although that's not the right place for libraries iirc).

Just in case it helps, I should point out that I saw that most of the .hdll files are in the root of the .app directory with the libhl.dylib too. lime.hdll in in Contents/MacOS, though.

Found the line responsible for libhl.dylib in particular.
System.copyFile(Path.combine(hlPath, "libhl.dylib"), Path.combine(applicationDirectory, "libhl.dylib"));

And here's what that line was replacing.

@joshtynjala Since I'm not set up for Mac testing, can you be the one to change line 209 and push the commit?

Changing from applicationDirectory to executableDirectory on Line 209 seems to be the correct solution there. The .dylib and .hdll files are now placed in Contents/MacOS, and lime test hl is working for me.


Move node based settlement submission into own file

Preparation for having a higher level struct that decides between node based and archer network based submission.
Code has only been moved, not changed.
Test Plan
existing CI

Renamed to that.


Avoid double interception on Multi creation when using groups

Need a review @cescoffier?

Yes @jponge. It would be great.

todos.append(pr);


Edit: make RSS canonicalUrl required

We discovered that canonicalUrl did not work as expected in the @astrojs/rss package. So, we're asking users to apply this value manually as a required prop.
Changes made

add note that import.meta.env.SITE only works in the latest 1.0 beta
add canonicalUrl to all code examples, with explainer comments where applicable

@sarah11918 Deploy preview looks fine to me! Shouldn't be a problem in a code fence from my understanding, but lmk if there's something crazy I don't know about for production

@bholmesdev Gah! I replied in the other PR by mistake... short version, this is what this current Netlify deploy preview looks like:
Can you look carefully at this? Because this is what I see:
When it's in commented out code in the code fence, you're gonna need that component (as I gave instructions for dealing with, in the other PR):

When it's just a string in the code fence, it seems to be fine:

Totally understood! Thanks for walking through this nuanced / wacky issue @sarah11918 🙏


Update README

To reflect Flutter hitting stable Windows support.

@michalsrutek You should also add a reference to the brand new Flutter Favorite Badge 💙🚀⭐


#18707 Quote identifiers starts with numbers

Check that DBeaver can correctly work (switch default database, for example) with

identifiers like 1234
identifiers like table1234
identifiers like _fs%sfn
identifiers like 66e60ce

verified


CNAME record

[IPv4Address] Establish a connection over an IPv4 address
Looking up IPv4 address for 'egsam.mk16.de'
  x [Errno -5] No address associated with hostname

[IPv6Address] Establish a connection over an IPv6 address
Looking up IPv6 address for 'egsam.mk16.de'
  ✓ '2a03:4000:6:2784::'
Attempting to connect to [2a03:4000:6:2784::]:1965
  x timed out

but
$dig egsam.mk16.de

; <<>> DiG 9.16.27-Debian <<>> egsam.mk16.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58244
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b0e338d676ff827e (echoed)
;; QUESTION SECTION:
;egsam.mk16.de.			IN	A

;; ANSWER SECTION:
egsam.mk16.de.		254	IN	CNAME	p2p-node.de.
p2p-node.de.		254	IN	A	<IP_ADDRESS>

;; Query time: 0 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Fri Jul 22 16:53:39 CEST 2022
;; MSG SIZE  rcvd: 119

This one is working for me with the same dig results, might have been a cache issue or something.
Running server diagnostics check against egsam.mk16.de:1965
...

[IPv4Address] Establish a connection over an IPv4 address
Looking up IPv4 address for 'egsam.mk16.de'
  ✓ '<IP_ADDRESS>'
Attempting to connect to <IP_ADDRESS>:1965
  ✓ Successfully established connection

[IPv6Address] Establish a connection over an IPv6 address
Looking up IPv6 address for 'egsam.mk16.de'
  ✓ '2a03:4000:6:2784::'
Attempting to connect to [2a03:4000:6:2784::]:1965
  x timed out

Okay, IPv4 works for me now. IPv6 seems to be on the egsam server. I can't open it with Lagrange either.


Code Formatting Standards

Hi,
I was looking to contribute to this repo. I understand that we need to agree to the DCO as a requirement. I was wondering if there were any particular code formatting styles recommended/enforced for this project?

hi @vin-nag contributions are welcome!
"I was wondering if there were any particular code formatting styles recommended/enforced for this project?"
Yes, you will need to run flake8 and isort, see:
https://github.com/interpretml/interpret-community/blob/813be7ae1705ab6c13434ad6a22152785a783153/.github/workflows/python-linting.yml
I usually run flake8 at the root level:
flake8 --max-line-length=119

It will tell you what style change will need to be made.
For isort, it will actually auto-correct the code.  To see the issues, you just need to run:
isort . -c

To autocorrect the issues, you can remove the -c parameter:
isort .

It will auto-correct the imports for you.
If you have any other style suggestions please let us know.

closed with PR https://github.com/interpretml/interpret-community/pull/522 where I added a contributing guide to the website

see https://interpret-community.readthedocs.io/en/latest/contributing.html#

@vin-nag did you have any other questions about making contributions to this repository?  Did you encounter any issues when trying to make a contribution?


Update update workflows

Summary

Remove Java 11. This has gone end of life upstream, so it is being removed.
Remove Java 19. This has gone end of life upstream, so it is being removed.
Add Java 20. This is the new short-term release.
Update Java 17 to use the new Github release update dependency. We can now use this to fetch dependencies from upstream instead of the custom updater. This works for Java 17 and Java 20.

Use Cases
Fix updaters.
Checklist

[ ] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

This needs a little more work. I missed required changes to buildpack.toml. Marking as a draft for now.

I think this is ready to go now. Need a quick re-review. Thanks


Update workflows for Node 18

Following saplingjs/sapling#519, se Node 18 LTS for the codecov report test run, and linting run.
Retain Node 12 for now, even though it is EOL. If it ever causes major problems, it can be removed without worries.

Codecov Report

Merging #80 (c8ea009) into master (05f810d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #80   +/-   ##
=======================================
  Coverage   97.10%   97.10%
=======================================
  Files           1        1
  Lines          69       69
=======================================
  Hits           67       67
  Misses          2        2


Overwatch effects not working

Expected Behaviour
Overwatch effects tab displaying appropriate effects when the game is running.
Actual Behaviour
Overwatch effects tab is black when the game is running AND Razer devices are active in Device Manager. Once Razer is disabled in Device Manager, Overwatch tab ligths up.
Reproduction steps

Run Aurora.
Run Overwatch. This step and the previous one can be executed in any order.
Open Overwatch tab in Aurora.
You will see that the device preview is dark.
Go to Arurora Settings, Device Manager tab, and stop Razer devices. Open Overwatch tab again.
You will see that the device preview is lit up with effects from the game.
Go to Aurora Settings, Device Manager tab, and run Razer devices back again. Open Overwatch tab again.
You will see that the device preview is dark.

Frequency
Every time
Aurora Version:
v96
Previously an Issue?
Don't know
Additional comments
Devices are working as intended in Desktop profile.
2022-12-14 19.04.36.log

Can you tell me the chroma sdk version in Devices & Wrappers tab?

The problem is on chroma sdk. When did you install it? People have been complaining about it for 2 weeks (people that started using new) but yesterday someone got it working on first try. Can you reinstall chroma?

Yesterday, just started using. Already have, maybe will try some more

Can you give instructions on how to obtain an older SDK version?

https://cdn.razersynapse.com/1661759489M35DwFzqRazerChromaBroadcasterSetup_v3.7.0831.082915.exe
this is an older one. Uninstall chroma from Auroa first

did you solve your problem?

The problem wasn't concerned with Razer SDK. I had to reorder connected apps in Synapse and out Overwatch on top. When Overwatch is on top, Aurora can capture OW SDK messages and pass them on to keyboard and peripherals


[bug] When set "transparent": true on Windows 11, the background with the initial size will be white.

Describe the bug
When set "transparent": true, the background with the initial size will be white.
And manually resize the window, the redraw part of the window will be transparent.

the pard word should be part

Reproduction
set "transparent": true
Expected behavior
The initial part window should be transparent.
Full tauri info output
[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 126.0.2592.102
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
    ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.12.0
    - pnpm: 9.1.1
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 1.7.1
    - tauri-build [RUST]: 1.5.3
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - tauri-cli [RUST]: 1.5.14
    - @tauri-apps/api [NPM]: 1.5.6 (outdated, latest: 1.6.0)
    - @tauri-apps/cli [NPM]: 1.5.14 (outdated, latest: 1.6.0)

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite

Stack trace
No response
Additional context
No response

This is fixed in v2, for v1, try this workaround https://github.com/tauri-apps/tauri/issues/8632#issuecomment-1897656298


Support for official Chia pools - plotting & farming

Support for both plotting of portable plot and farming them on official pools. Ensure ease of setup and use within Machinaris.

is there a branch to help  you testing?

Pooling support is now available in test version: ghcr.io/guydavis/machinaris:test  Early support includes "pool" test branches of both the stock Chia plotter and the Madmax plotter.
Currently, to create portable plots for testing, you need to, first create a pool_contract_address:
docker exec -it machinaris bash
chia plotnft create -u https://my.fave.pool.org -s pool

Replace https://my.fave.pool.org with the address of your preferred pool, following their specific instructions.
Then set that pool_contract_address into the config at Setting | Plotting page of Machinaris.  Examples for Chia plotter and Madmax plotter.
NOTE: As per Chia devs, these portable plots may change before final release so this is only for testing!

seams like plotting is not working! madmax or chia! no error log

it seems like a problem when plotting with a pool contract address
plotman is not starting up

and plots can no longer be killed

The issue is, when plotting for a pool the pool_pk needs to be #. otherwise it will give the -p, -c and -f argument to the plotter.
this errors the plotter out.
when deleting the pool_pk it is plottung but it starts a new plot every 2s and the plots are not showing up in the plotting tab.
is there a way to fix that soon? unfortunately its unusable that way.

The issue is, when plotting for a pool the pool_pk needs to be #. otherwise it will give the -p, -c and -f argument to the plotter.
this errors the plotter out.
when deleting the pool_pk it is plottung but it starts a new plot every 2s and the plots are not showing up in the plotting tab.

Please share the different plotman.yaml settings files you've tried.  For example, is this for Chia stock plotter or Madmax or both?  If you share the plotting section (masking any key values), then I can better understand the issue.  Thanks for the report.
Example:

I have tried to plot for pool use with the standard plotter. I get the following error message about the code version of chia:
Exception: Chia version 1.2 required for creating pool plots but found: 1.1.7.dev80
Would it be possible to bump the chia version to 1.1.7dev454 that I know works outside Machinaris?

I have tried to plot for pool use with the standard plotter. I get the following error message about the code version of chia:
Exception: Chia version 1.2 required for creating pool plots but found: 1.1.7.dev80
Would it be possible to bump the chia version to 1.1.7dev454 that I know works outside Machinaris?

Just rebuilt the Machinaris test version and pulling from main@chia-blockchain.  This binary reports version: 1.1.7.dev95.
chia plots create --help shows:

I followed these instructions:

When starting from scratch, install Chia with these instructions: https://github.com/Chia-Network/chia-blockchain/wiki/INSTALL#ubuntudebian
Go to your Chia directory and make sure you didn't activate Chia venv yet. You can deactivate with command: deactivate
git fetch
git checkout main
git pull
sh install.sh
. ./activate
chia init
chia start farmer -r
Ensure your node and wallet are fully synced
Your wallet needs at least 1 MOJO to join a pool. Use https://faucet.chia.net/ if you don't have 0.000000000001 XCH (1 MOJO)
chia plotnft create -u https://xch.spacefarmers.io -s pool This will create the pool wallet, check details and confirm
Check if your pool wallet is activated:  chia plotnft show. It can take up till 2 minutes for the pool wallet to show up.
Copy P2 singleton address
chia plots create -t /temp/directory/ -d /final/directory -c (P2 singleton address from step 13)

this is my plotting config:
Learn more about Plotman at https://github.com/ericaltendorf/plotman
https://github.com/ericaltendorf/plotman/wiki/Configuration#versions
version: [2]
logging:
# DO NOT CHANGE THIS IN-CONTAINER PATH USED BY MACHINARIS!
plots: /root/.chia/plotman/logs
user_interface:
use_stty_size: False
commands:
interactive:
autostart_plotting: False
autostart_archiving: False
Where to plot and log.
directories:
    # One or more directories to use as tmp dirs for plotting.  The
    # scheduler will use all of them and distribute jobs among them.
    # It assumes that IO is independent for each one (i.e., that each
    # one is on a different physical device).
    #
    # If multiple directories share a common prefix, reports will
    # abbreviate and show just the uniquely identifying suffix.
     This contains a map of tmp directory names to
    # attributes. If a tmp directory and attribute is not listed here,
    # it uses the default attribute setting from the main configuration.
    #
    # Currently support override parameters:
    #     - tmpdir_max_jobs
    #tmp_overrides:
            # In this example, /plotting3 is larger than the other tmp
            # dirs and it can hold more plots than the default.
            #/plotting3:
            #        tmpdir_max_jobs: 5

    # Optional: tmp2 directory.  If specified, will be passed to
    # the chia and madmax plotters as the '-2' param.
    #tmp2: /plotting2

    # One or more directories; the scheduler will use all of them.
    # These again are presumed to be on independent physical devices,
    # so writes (plot jobs) and reads (archivals) can be scheduled
    # to minimize IO contention.
    # REMEMBER ALL PATHS ARE IN-CONTAINER, THEY MAP TO HOST PATHS
    dst:
            - /private-plots
            - /pool-plots

See: https://github.com/guydavis/machinaris/wiki/Plotman#archiving
#archiving:
#target: rsyncd
#env:
#site_root: /mnt/disks
#user: root
#host: aragorn
#rsync_port: 12000
#site: disks
Plotting scheduling parameters
scheduling:
# Run a job on a particular temp dir only if the number of existing jobs
# before tmpdir_stagger_phase_major tmpdir_stagger_phase_minor
# is less than tmpdir_stagger_phase_limit.
# Phase major corresponds to the plot phase, phase minor corresponds to
# the table or table pair in sequence, phase limit corresponds to
# the number of plots allowed before [phase major, phase minor]
tmpdir_stagger_phase_major: 4
tmpdir_stagger_phase_minor: 0
# Optional: default is 1
tmpdir_stagger_phase_limit: 1
    # Don't run more than this many jobs at a time on a single temp dir.
    # Increase for staggered plotting by chia, leave at 1 for madmax sequential plotting
    tmpdir_max_jobs: 1

    # Don't run more than this many jobs at a time in total.
    # Increase for staggered plotting by chia, leave at 1 for madmax sequential plotting
    global_max_jobs: 1

    # Don't run any jobs (across all temp dirs) more often than this, in minutes.
    global_stagger_m: 30

    # How often the daemon wakes to consider starting a new plot job, in seconds.
    polling_time_s: 20

Configure the plotter.  See: https://github.com/guydavis/machinaris/wiki/Plotman#plotting
plotting:
farmer_pk: 87b595.....
pool_pk: a952f59.....
#pool_contract_address: xch1thw.....
    # If you enable 'chia', plot in *parallel* with higher tmpdir_max_jobs and global_max_jobs
    # If you enable 'madmax', plot in *sequence* with very low tmpdir_max_jobs and global_max_jobs
    type: madmax

    # The chia plotter: https://github.com/Chia-Network/chia-blockchain
    chia:
            k: 32                # k-size of plot, leave at 32 most of the time
            e: False             # Disable bitfield back sorting (default is True)
            n_threads: 2         # Threads per job
            n_buckets: 128       # Number of buckets to split data into
            job_buffer: 3389     # Per job memory

    # The madmax plotter: https://github.com/madMAx43v3r/chia-plotter
    madmax:
            n_threads: 10          # Default is 4, SLOWLY crank up if you have many cores
            n_buckets: 256        # Default is 256

another issue i found. when i try to kill plots it does not work. not stopping nor deleting files.
tryed 5 full reinstalls. same problem

Closing as v0.5.0 release supports Chia pools.


release: 0.19.0

As per #3154 I think we're ready to push 0.19.
I'll put this live on Tuesday evening unless I hear a reason to postpone.

Rebased and I'll push shortly.

(I also added a section to the migration guide to document the changes to __traverse__, as some users may be caught out by the new panic.)

(I also added a section to the migration guide to document the changes to __traverse__, as some users may be caught out by the new panic.)

Thank you and I think this should have been part of the original PR but I never looked back at the guide after writing that one sentence in the class customization section.


[Bug]: add reviews to every listing

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
currently one user can add only only review in the entire website, which is improper
user not able to add reviews to other listing after reviewing any one of the listing
Expected behavior
user can add only one review to each listing
Add ScreenShots

On which device are you experiencing this bug?
No response
Record

[X] I have read the Contributing Guidelines
[ ] I'm a GSSOC'24 contributor
[X] I have starred the repository

@Soujanya2004
If deployment is finish then there is many ISSUE like

dark mode toggle is not working.
Individual show route loading for long time.

If it's deployment issue. Otherwise I raised ISSUE?

@Suvadip-sana i guess its deployment issue, i will look into it

@Suvadip-sana can u please try to look into that issue, i am not able to revert the last commit also
i will label level 3 and assign u dont worry

@Soujanya2004 Let me check

@Soujanya2004  Yes it's an ISSUE. I create a ISSUE for thuis.

@Suvadip-sana

@Soujanya2004
I think there is no problem related to this ISSUE.  Here I verify it in your current deployment .
Please elaborate if still there have a problem.
https://github.com/user-attachments/assets/f1b5b90f-afbd-4307-92b8-86a9ed1c7db2

@Suvadip-sana after deleting the review i am not getting option to add review again

https://github.com/user-attachments/assets/ef7b049d-d69e-4224-9e92-6232c0c45ff5
See I just verify it in your current deployment. I got no error or trouble as you said. Please verify once more then inform me.

as u can see i have added no review still not having option to add new review

In which card? Give me that cards screen short.  Are you try on your hosted server or local server?

hosted server

@Suvadip-sana
i am owner of that listing and unable to add review again

@Suvadip-sana i am owner of that listing and unable to add review again for others listing its working

Yes that's the logic added in backend from many time ego.
Basically The logic is that, listing owner is not allow to add reviews for there own list. Because that's not the way to show genuine and pure review for visitor.  Yes that logic is added in backend.
If you tell me to remove that logic means owner should allow to add the review for there own list. Then tell me.

@Suvadip-sana see i am able to add it for the first time but not after deleting it

@Soujanya2004 whats the issue in this ??

no issues for now


Purchase hardware to install pfSense

Minibox.com sells a pretty solid PCEngines board that will more than handle what I want to do on a home network for roughly $300 plus shipping: https://www.mini-box.com/ALIX-APU-4D4-AMD-G-Series-GX-412TC

[x] Board
[x] Case
[x] Power supply
[x] M2 SSD

APU2E4 board finally came back in stock. Taking delivery soon.


Include Respond.js

Respond.js is a fast & lightweight polyfill for min/max-width CSS3 Media Queries (for IE 6-8, and more), which is required for Bootstrap 2.3.0 + support in IE7 and above. Does this library already include it? If not, is there any plans to do so?

I have added Respond.js and made the necessary changes. Now do I need to include tests? If so, how should I proceed?

I have added Respond.js and made the necessary changes. Now do I need to include tests? If so, how should I proceed?

Happy new year to you too! Yes I am filing the PR now!

Happy new year to you too! Yes I am filing the PR now!


How can we add an add-on as a list in python?

In other to add an add-on variable as a string we can define the typespec as typing.Optional[str] and run command mitmdump --scripts ./log.py --set path='./content/'
However, how can we define and which command should we run if we want the add on variable to be a List in python?

Do you mean like this?
https://github.com/mitmproxy/mitmproxy/blob/e0c07d17556dc5a4a723f7b6be61f68b6e5c1553/mitmproxy/options.py#L66-L75

Do you mean like this?
https://github.com/mitmproxy/mitmproxy/blob/e0c07d17556dc5a4a723f7b6be61f68b6e5c1553/mitmproxy/options.py#L66-L75

Yes, but which command should I run in other to pass in a list sir ?

In theory you use --set multiple times. But it looks like that's broken.
You can update the option inside the addon, but not via the cli arguments
ctx.options.update(
    foo        = ["1", "2", "3"]
)

Closing as duplicate of #3015

I'm creating an addon which accept two params including a string and an array of string as bellow
def load(self, loader):
        loader.add_option(
            name = "path",
            typespec = typing.Optional[str],
            default = None,
            help = "Add a path for directory",
        )
        loader.add_option(
            name = "ignored_list",
            typespec = typing.Sequence[str],
            default = None,
            help = "Add a ignored list",
        )

But i don't know which command should I run in other two pass in those two arguments

--scripts ./log.py --set black_list=foo --set black_list=bar but like I said there's a bug and you will only receive one of them in your list. You can subscribe to #3015


Identifying terminal extubation among patients

Dear magnificent lcp team,
While trying to evaluate tachypnea episodes within MIMIC patients, we realized that the data is not granular enough so we thought that eICU must have a more granulated one.
Thus in order to identify terminal extubated patients in the eICU, we were wondering:

Can we identify extubations? If so, where?
Can we identify patients receiving CMO (neither DNR nor EOL)? If so, where?

The outcomes for these patients we will need are:

Respiratory Rate TimeStamps at least every 10 min.
Morphine Infusion TimeStamps at least every 30min?

It would be wonderful if as well we had:

At least 10 min freq. Heart Rate TimeStamp
Hourly PAIN Score TimeStamps

Thanks a lot for your time.

@theonesp I've replied to some of these points below:

Can we identify extubations? If so, where?

Not at the moment, but it is something that we'd like to be able to do.

Can we identify patients receiving CMO (neither DNR nor EOL)? If so, where?

As above! CMO is definitely recorded in the database, but you may need to look across several tables to get a complete list. e.g: take a look at:
SET search_path TO eicu_crd_phi;
SELECT patientunitstayid, cellattributevalue
FROM nurseassessment
WHERE lower(cellattributevalue) like 'cmo%'
LIMIT 10;

-- returns:
 patientunitstayid | cellattributevalue
-------------------+--------------------
           3124215 | CMO
           3124215 | CMO
           3124215 | CMO
           3124215 | CMO
           3124215 | CMO
           3124215 | CMO
           3124215 | CMO
           3044742 | CMO
           3095345 | CMO
           3107953 | CMO

If you create a query to extract CMO patients, it would be helpful if you could share it in the code repo.

The outcomes for these patients we will need are:

Respiratory Rate TimeStamps at least every 10 min.
Morphine Infusion TimeStamps at least every 30min?
It would be wonderful if as well we had:

At least 10 min freq. Heart Rate TimeStamp
Hourly PAIN Score TimeStamps

You will need to explore the data to find frequency of measurements. I would suggest extracting the intervals for the variables and then plotting the distributions. You can extract interval using the lag function. e.g.:
-- example of lag
-- would need to adapt query to focus on individual variables
WITH tmp AS (
SELECT patientunitstayid, observationoffset, LAG(observationoffset) OVER (PARTITION BY patientunitstayid ORDER BY observationoffset) AS lag
FROM vitalperiodic v
LIMIT 10)
SELECT *, observationoffset-lag AS interval
FROM tmp;

Frequency distribution of the top ten resolution values for Respiratory Rate

SET search_path TO eicu_crd_phi;
WITH tmp AS (
SELECT patientunitstayid, respiration,observationoffset, LAG(observationoffset) OVER (PARTITION BY patientunitstayid ORDER BY observationoffset) AS lag
FROM vitalperiodic v
WHERE
respiration IS NOT NULL
)
SELECT observationoffset-lag AS interval,
COUNT (observationoffset-lag) AS frequency
FROM tmp
GROUP BY interval
ORDER BY
COUNT (observationoffset-lag) DESC
;

interval;frequency
5;127777228
10;196047
15;85073
20;49681
25;33851
30;24036
35;17449
40;13080
45;10256
50;8464


-Add Arabic Language For Localization

Please Review This Code For Add Ar Language

Will Update it in Pakage ?

will update soon


Update DERP server definitions

The repo link referenced in derp.yaml is invalid and is missing the new DERP addresses.
This PR updates the file to use the newest tailscale DERP servers and updates the link in the comment.
Out of curiousity is stunonly always false, and derptestport always 0?
stunport, stunonly, and derptestport have no references in the code so not sure if these fields are still needed.

Looks good! I didn't actually include all official Tailscale DERP servers because people should be running their own DERP infra. But it does not make sense to just include some of them...
The fields you are mentioning are just part of the DERPNode struct https://github.com/tailscale/tailscale/blob/main/tailcfg/derpmap.go#L87


fastcdr: 1.0.13-1 in 'dashing/distribution.yaml' [bloom]

Increasing version of package(s) in repository fastcdr to 1.0.13-1:

upstream repository: https://github.com/eProsima/Fast-CDR.git
release repository: https://github.com/ros2-gbp/fastcdr-release.git
distro file: dashing/distribution.yaml
bloom version: 0.10.0
previous version for package: 1.0.11-1

Holding until the Fast-RTPS release is ready as well.

Please merge this together with https://github.com/ros/rosdistro/pull/27121 :green_circle:


Store container metadata in boltdb buckets

Store container values as BoltDB keys rather than JSON.
We still plan to switch to use proto encoded values but this is better than using JSON. The protos need to be refactored before using.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #896   +/-   ##
=======================================
  Coverage   59.55%   59.55%
=======================================
  Files           5        5
  Lines         759      759
=======================================
  Hits          452      452
  Misses        199      199
  Partials      108      108

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 c00d731...f98a4f1. Read the comment docs.

LGTM


AmbiguousRuleException whereas only one input file exists

Snakemake version
6.2.1
Describe the bug
Snakemake complains about ambiguous rules, but only one file really exists.
Logs
Building DAG of jobs...
AmbiguousRuleException:
Rules copy and unlzma are ambiguous for the file step/raw_reads/PE_1.fastq.
Consider starting rule output with a unique prefix, constrain your wildcards, or use the ruleorder directive.
Wildcards:
        copy: dataset=PE_1
        unlzma: dataset=PE_1
Expected input files:
        copy: /pasteur/zeus/projets/p02/stella-run/projects/sars-cov-2-detection/positives/PE_1.fastq
        unlzma: /pasteur/zeus/projets/p02/stella-run/projects/sars-cov-2-detection/positives/PE_1.fastq.xzExpected output files:
        copy: step/raw_reads/PE_1.fastq
        unlzma: step/raw_reads/PE_1.fastq

(there is a missing \n before Expected output files)
$ ls /pasteur/zeus/projets/p02/stella-run/projects/sars-cov-2-detection/positives/PE_1.fastq
/pasteur/zeus/projets/p02/stella-run/projects/sars-cov-2-detection/positives/PE_1.fastq
$ ls /pasteur/zeus/projets/p02/stella-run/projects/sars-cov-2-detection/positives/PE_1.fastq.xz
ls: cannot access '/pasteur/zeus/projets/p02/stella-run/projects/sars-cov-2-detection/positives/PE_1.fastq.xz': No such file or directory

Minimal example
rule unlzma:
    input:
        config["sample"]["path"]+"/{dataset}.fastq.xz"
    output:
        "step/raw_reads/{dataset}.fastq"
    resources: cpus=1
    shell:
        "xz -d -c '{input}' > '{output}'"

rule copy:
    input:
        config["sample"]["path"]+"/{dataset}.fastq"
    output:
        "step/raw_reads/{dataset}.fastq"
    resources: cpus=1
    shell:
        "cp '{input}' '{output}'"

Miminal example
Snakefile:
rule all:
    input:
        "dest/foobar.ext"

rule uncompress_xz_source_to_dest:
    input:
        "source/{file}.ext.xz"
    output:
        "dest/{file}.ext"
    shell:
        "touch {output}"

rule copy_source_to_dest:
    input:
        "source/{file}.ext"
    output:
        "dest/{file}.ext"
    shell:
        "touch {output}"

rule generic_compress_xz:
    input:
        "{file}.ext"
    output:
        "{file}.ext.xz"
    shell:
        "touch {output}"

mkdir source && touch source/foobar.ext
snakemake --cores 1
Building DAG of jobs...
AmbiguousRuleException:
Rules copy_source_to_dest and uncompress_xz_source_to_dest are ambiguous for the file dest/foobar.ext.
Consider starting rule output with a unique prefix, constrain your wildcards, or use the ruleorder directive.
Wildcards:
        copy_source_to_dest: file=foobar
        uncompress_xz_source_to_dest: file=foobar
Expected input files:
        copy_source_to_dest: source/foobar.ext
        uncompress_xz_source_to_dest: source/foobar.ext.xzExpected output files:
        copy_source_to_dest: dest/foobar.ext
        uncompress_xz_source_to_dest: dest/foobar.ext

In my previous message, I omitted this bug needs a rule to produce xz file in my example. So I understand theoretical ambiguity, but since one input file is already existing, I think there is no reason Snakemake tries to produce it through another rule. Am I understanding this well?


Introduce new toml_lexer crate

The documentation on the crate speaks for itself.
Shortly this crate's main idea is to be very generic to support multiple
use cases for toml tokenizer (i.e. toml-rs serde parsing itself and
error-resilient parsing for some programs like TOML language servers).
The crate exposes very low-level api, even further sub-tokenizing string
literals. The api and implementation is highly inspired by rustc_lexer,
and its ideas fully correspond.
I have a self-interest in maintaining toml_lexer crate, I assume I will need utilities for parsing toml numbers and dates from Keylike token somewhere in near future, but I didn't bother implementing it in this PR just to keep the number of changes much lower (which is to say quite large, sorry for so many changes, even tho @alexcrichton supposed it would be possible to implement error-resilient tokenizer on top of the already existing one with small changes, but I have what I have, I iterated on the api and implementation quite a lot and I couldn't introduce fewer changes...)
I also organized all crates under the crates/* dir, since toml and toml_lexer are now fully independent crates, if you find this wrong, I'll return it to the previous layout and add toml_lexer as a top-level dir.
Closes #394

Awesome and thanks for this! I started taking a look at this and it's looking pretty good to me in terms of architecture. One thing I wanted to ask about though was how low-level this is. The tokenizer for serde, for example, seems to have only reduced in size slightly in that for the serde purpose consume the raw output of the lexer crate still requires quite a bit of processing. Is this sort of processing going to need to be duplicated amongst users of this crate?
One of the main goals of splitting this out was to share logic across various consumers of TOML, but I'd be slightly afraid if the real meat of the logic is still within the toml crate itself. It looks like the main part separated is the string lexing, but other than that the new crate doesn't seem to do a huge amount?

Well, the tokenizer for serde has quite a lot of additional private helper methods which I haven't moved into toml_lexer since these are very ad-hoc for serde sphere.
Other than that mapping between toml_lexer possibly-malformed-tokens and original toml crate tokens takes some lines of code, so it may seem like there is a still lot of logic in tokens.rs.
And you are right, the gist of logic is dedicated to string literals sub-tokenizing (which is very useful e.g. for highlighting escape sequences inside of string literals for language server use case). I had a thought to move making StrLitSubtokens into a Cow<str> to toml_lexer crate but this requires moving the error enum to toml_lexer crate, and this, in turn, means we would need to maintain that as a public API.
Well, one of the goals I had was making the public API surface as small as possible, but if you don't mind moving collecting string literals into Cow<str> to toml_lexer it's hard to peek a robust api for this one.
Anyway, I do have one idea (I did a trial impl to check, and it should work)
This will be more verbose but will fully leverage the type system and ownership model by encoding the state into the types further:
// toml_lexer
struct Token<K> { span: Span, kind: K }

enum TopLevelTokenKind {
    Comment,
    Keylike,
    // ... all trivial top-level tokens (non-string-literals)
}

enum StrLitSubtokenKind {
    Char(char),
    UnicodeEscape(UnicodeEscape),
    // ... all str lit subtokens exlcuding leading and trailing quotes
}

struct TopLevelTokenizer(...);
impl TopLevelTokenizer {
    // notice consuming self
    fn next(self) -> Option<TopLevelNextState>;
}
enum TopLevelNextState {
    TopLevel(Token<TopLevelTokenKind>, TopLevelTokenizer),
    LeadingQuotes(Token<Quotes>, StrLitTokenizer),
}

struct StrLitTokenizer(...);
impl StrLitTokenizer {
    fn next(self) -> StrLitNextState;
    /// Consumes self and returns the next state with the fully unescaped string if it is well-formed.
    fn unescape_into_cow(self) -> Result<(Cow<str>, TopLevelTokenizer), EscapeError>;
}
enum StrLitNextState {
    // Optional trailing quotes span
    TopLevel(Option<Span>, TopLevelTokenizer),
    StrLit(Token<StrLitSubtokenKind>, StrLitTokenizer),
}

// tom/src/tokens.rs

struct SerdeTokenizer(Option<toml_lexer::TopLevelTokenizer>);
impl SerdeTokenizer {
    fn new(input: &str) -> Self {
        Self(Some(TopLevelTokenizer::new(input)));
    }

    fn next() -> Result<Option<(Span, Token)>, Error> {
       let tokenizer =  self.0.take()?;
       match tokenizer.next()? {
           TopLevelNextState::LeadingQuotes(quotes, str_lit_tokenizer) => {
                let (unescaped, top_level_tokenizer) = str_lit_tokenizer
                    .unescape_into_cow()
                    .map_err(|err| Error::EscapeError(err))?;

                self.0 = Some(top_level_tokenizer);
                String {
                    val: unescaped,
                    multiline: quotes.kind == Quotes::X3,
                }
           }
           // ... other  token mappings are trivial 1-to-1
       }
}

I love this because this decreases the number of unwrap(), but I hate this because it moves us from concise impl Iterator to verbose fn next(self) -> NextStateEnum.

I think I'll stick with simple iterator approach, but add a method
fn eat_str_lit(&mut self) -> Option<Result<Cow<str>, StrLitError>>

I also have minor changes to tokenize_str_lit() api in mind (returning usize instead of Span there just because the returned span always starts from 0).
Besides that I am already working on parsing number and date literals, I won't include this work in this particular PR (rather in a separate followup PR). I think it will look similarly:
enum NumOrDatetimeLitResult {
    Num(Result<Number, NumError>),
    Datetime(Result<Datetime, DatetimeError>),
}

fn eat_num_or_datetime_lit(&mut self) -> Option<NumOrDatetimeLitResult>

I actually think I will test my work in tom first to have a real test case for toml_lexer api and then move this PR from draft.

Unfortunately, I am bit out of capacity to make this. I'll close the PR, but anyone else interested is free to continue the work!


Door Service Documenation

Just noted that the HomeSpan service documentation states that the only required door characteristic is CurrentPosition. However when you start HomeSpan up it complains saying that TargetPostion and PositionSate are required.

In the Apple docs?  According to HAP R2, TargetPosition and PositionState are also required.

Ah - sorry.  You meant in my own documentation!  I will update accordingly.  Thanks for catching.

Thanks again for catching this - the doc has been updated in the master branch.


🆕 Software Suggestion | Notepack

Basic Information
Name: Notepack
Category: Digital Notebook
URL: https://github.com/Ogefest/Notepack
Description
Privacy oriented, without vendor lock in note organizer, todo list desktop application. No cloud, no accounts, no usage tracking.
Why I am making the suggestion
Only few recommendations on privacytools.io in Digital Notebook category. Application is mature enough to use it every day as primary notepad.
My connection with the software
I'm the author

[X] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

Website is dead. But app still available in GitHub Releases.

Thank you for comment, website was only temporarily unavailable.


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 13:36:29 on 2023.07.17
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 1, errors out: 0
Original problem ID: 32687
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=32687

Problem has been resolved in 3m 0s at 13:39:29 on 2023.07.17
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 32687


Dockerfile for Nvidia GPU

Build and run it like this:
Download model
mkdir -p dist && git lfs install && \
git clone https://huggingface.co/mlc-ai/demo-vicuna-v1-7b-int3 dist/vicuna-v1-7b && \
git clone https://github.com/mlc-ai/binary-mlc-llm-libs.git dist/lib

Build it
docker compose build

Run it
docker compose run -i --rm mlc-llm

Quite interesting indeed, I have a few questions about the Docker. Actually, I've tested the image nvidia/vulkan:1.3-470, but it still didn't work on my A6000 with the 525 driver installed. From my experience, Vulkan is tied to the Nvidia driver, and some Nvidia drivers may not include Vulkan support. Also, the Docker container must share the same driver with the host. So, it's strange that the image is named nvidia/vulkan:1.3-470, implying that it has Vulkan 1.3 installed with the Nvidia 470 driver (since it can't be certain it's using the 470 driver). Do you have any thoughts on this?

I tried in my WSL, it gives error:

(mlc-chat) nw@DESKTOP-BADE1QI:/mnt/c/Ubuntu/mlc$ docker compose run -i --rm mlc-llm
[+] Running 1/0
 ✔ Network mlc_default  Created                                                                                0.0s
terminate called after throwing an instance of 'tvm::runtime::InternalError'
  what():  [11:52:39] /home/runner/work/utils/utils/tvm/src/runtime/vulkan/vulkan_instance.cc:111:
---------------------------------------------------------------
An error occurred during the execution of TVM.
For more information, please see: https://tvm.apache.org/docs/errors.html
---------------------------------------------------------------
  Check failed: (__e == VK_SUCCESS) is false: Vulkan Error, code=-9: VK_ERROR_INCOMPATIBLE_DRIVER
Stack trace:
  [bt] (0) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(tvm::runtime::Backtrace[abi:cxx11]()+0x27) [0x7fae3af2fc97]
  [bt] (1) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(+0x3f375) [0x7fae3aecd375]
  [bt] (2) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(tvm::runtime::vulkan::VulkanInstance::VulkanInstance()+0x1a47) [0x7fae3b01ec07]
  [bt] (3) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(tvm::runtime::vulkan::VulkanDeviceAPI::VulkanDeviceAPI()+0x40) [0x7fae3b01ae10]
  [bt] (4) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(tvm::runtime::vulkan::VulkanDeviceAPI::Global()+0x4c) [0x7fae3b01b1ac]
  [bt] (5) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(+0x18d1ed) [0x7fae3b01b1ed]
  [bt] (6) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(+0x6c024) [0x7fae3aefa024]
  [bt] (7) /opt/conda/envs/mlc-chat/bin/../lib/libtvm_runtime.so(+0x6c5c7) [0x7fae3aefa5c7]
  [bt] (8) mlc_chat_cli(+0xeab0) [0x556e5780cab0]

/tmp/tmpi1l8mqe_: line 3:    15 Aborted                 /bin/bash -c mlc_chat_cli
ERROR conda.cli.main_run:execute(47): `conda run /bin/bash -c mlc_chat_cli` failed. (See above for error)

Hey I made a docker image that may help benchmark MLC LLM performance: https://github.com/junrushao/llm-perf-bench
On the other hand, I don’t really think docker is a perfect abstraction for those usecases (conda may be), but this docker should be a decent one


MultiFilter active class not being set

When using just mixitup core with data-filter controls, when I set a filter, that control gets class= 'mixitup-control-active' added to it.
However, when I add code to enable mixitup multifilter, this no longer happens. Instead, as I select different data-filter controls, just the word class gets added to each. So all previous selections and the current end up with the class attribute added with no value.
I'm relying on an active class being added so that I can set certain text on the page with javascript based on the current filters.
Here is the markup I am using for the controls (also using Bootstrap):
<form  data-filter-group="destination">

                    <button class="btn btn-block btn-filter btn-destination dropdown-toggle" type="button" id="destination" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
                        Destination
                    </button>

Dublin

Cork

Galway

<button type="reset" class="btn-reset">All</button>

            </form>

Here is the mixitup config:
var mixer = mixitup('#mixitup', {
      multifilter: {
        enable: true
      },
      selectors: {
        control: '[data-mixitup-control]'
      },
      callbacks: {
        onMixEnd: function(state) {
            window.console.log(state.activeFilter.selector);
        }
      }
    });

Am I doing something wrong or is this a bug? Thanks.

Hi, do you have a link to your project?

Thanks for the quick reply Patrick. I do have a link but cannot share it publicly as it's under construction. I'll send you the link directly though via the contact form on your site.

Hi Tidy,
Thanks for the link. You are doing everything right - this was a bug (or more accurately another conflict with bootstrap).
I've not added a work around and pushed a new version of the extension (v3.3.3) which you can download from your account.
Please let me know if that works for you.

Yes, that works great now! Thanks so much for the instant turnaround on this - not at all expected but very much appreciated :)

Good afternoon! I use bootstrap 4 and I have a small problem: when "all" is selected, if you click any button (callback etc.), the mixer blocks are collapsed and the button is assigned the "mixitup-control-active" class.
Is there a solution to such a problem?
Yours faithfully, Dmitry
site: https://osnova39.ru/uslugi/stroitelstvo-domov-pod-kluch-kaliningrad/proekty-domov/

@kulikonch have you seen this issue: https://github.com/patrickkunka/mixitup/issues/268 ?
Which buttons should I click on your site to reproduce the issue?


Request: ability to use double quotes

Python black prefers double quotes: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#strings
Since I use Python, I like my YAML to use double quotes too.  Running this tool on my repo moves it to use single quotes:
-        if: "github.event_name == 'release' && github.event.action == 'published'"
+        if: github.event_name == 'release' && github.event.action == 'published'

There is the --preserve-quotes option, which leads to not touching quotes at all.  I actually like when this tool makes changes like this, so I want to keep --preserve-quote on:
-                  cache: "pip"
+                  cache: pip

My request is to add a new option resembling black's --skip-string-normalization that will just not convert double quotes to single quotes.

To me, black's description for --skip-string-normalization sounds analog to --preserve-quotes:

If this option is given, strings are left unchanged instead.

Is that your request, or rather an option to enforce a certain type of quotes?
For my project, I wanted to enforce double quotes because:

unquoted strings in YAML can cause unexpected behavior (no → bool, trailing spaces being included in strings…) and
the preferred type of quotes depends on the context and should be configurable.

How should such an option look like?

--preserve-quotes |  --single-quotes | --double-quotes
--quotes="preserve" | --quotes="single" | --quotes="double"
--quotes-style=…

Yeah @aeisenbarth, thanks for the follow up question. I agree in hindsight my OP was a little vague. I am interested in the ability to format with double quotes as opposed to single quotes. I think your proposed options --double-quotes or --quotes=double look great


Diego-cell pod failing with "CrashLoopBackOff"

Describe the bug
I am trying to deploy KubeCF (v2.2.2) and getting issues in diego-cell pod. The garden container is getting failed. Below are the logs for the garden container:
{"timestamp":"1594644900.966236353","source":"grootfs","message":"grootfs.init-store.store-manager-init-store.existing-backing-store-could-not-be-mounted: Mounting filesystem: exit status 32: mount: /var/vcap/data/grootfs/store/unprivileged: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.\n","log_level":1,"data":{"session":"1.1","spec":{"UIDMappings":[{"HostID":4294967294,"NamespaceID":0,"Size":1},{"HostID":1,"NamespaceID":1,"Size":4294967293}],"GIDMappings":[{"HostID":4294967294,"NamespaceID":0,"Size":1},{"HostID":1,"NamespaceID":1,"Size":4294967293}],"StoreSizeBytes":9223372020747599872},"storePath":"/var/vcap/data/grootfs/store/unprivileged"}}
{"timestamp":"1594644900.969948530","source":"grootfs","message":"grootfs.init-store.store-manager-init-store.truncating-backing-store-file-failed","log_level":2,"data":{"backingstoreFile":"/var/vcap/data/grootfs/store/unprivileged.backing-store","error":"truncate /var/vcap/data/grootfs/store/unprivileged.backing-store: file too large","session":"1.1","size":9223372020747599872,"spec":{"UIDMappings":[{"HostID":4294967294,"NamespaceID":0,"Size":1},{"HostID":1,"NamespaceID":1,"Size":4294967293}],"GIDMappings":[{"HostID":4294967294,"NamespaceID":0,"Size":1},{"HostID":1,"NamespaceID":1,"Size":4294967293}],"StoreSizeBytes":9223372020747599872},"storePath":"/var/vcap/data/grootfs/store/unprivileged"}}
{"timestamp":"1594644900.970129967","source":"grootfs","message":"grootfs.init-store.init-store-failed","log_level":2,"data":{"error":"truncating backing store file: truncate /var/vcap/data/grootfs/store/unprivileged.backing-store: file too large","session":"1"}}
truncate /var/vcap/data/grootfs/store/unprivileged.backing-store: file too large

To Reproduce
Trying to deploy KubeCF on the cluster deployed on BOSH ( aws env). The cluster is having enabled container privileges.

Hi @lordcf
Is it possible for you to retest with a newer release of kubecf ?
There is kubecf 2.2.3 in CAP 2.0.1.
Further, do I understand "deploy KubeCF on the cluster deployed on BOSH ( aws env)" correctly as

You are setting up a BOSH system on AWS, and then deploy kubecf into that BOSH system ?

Or are you talking about

Setting up a kubernetes cluster on AWS, and deploying kubecf into that cluster ?

As kubecf is kubernetes-based I am very confused by the reference to BOSH in your description.
If you have the same issue with 2.2.3 as with 2.2.2 then it would be very helpful if you could provide the exact session and steps you used to deploy the cluster and kubecf for us to review.
@gak @satadruroy FYI

@lordcf there's a more recent version of KubeCF in case you wanna give it a try and see if your problem has been fixed there.

Hi @lordcf
Is it possible for you to retest with a newer release of kubecf ?
There is kubecf 2.2.3 in CAP 2.0.1.
Further, do I understand "deploy KubeCF on the cluster deployed on BOSH ( aws env)" correctly as

You are setting up a BOSH system on AWS, and then deploy kubecf into that BOSH system ?

Or are you talking about

Setting up a kubernetes cluster on AWS, and deploying kubecf into that cluster ?

As kubecf is kubernetes-based I am very confused by the reference to BOSH in your description.
If you have the same issue with 2.2.3 as with 2.2.2 then it would be very helpful if you could provide the exact session and steps you used to deploy the cluster and kubecf for us to review.
@gak @satadruroy FYI

Hello,
We are using follwoing steps in order to install KubeCF:

Install bosh
deploy cluster on bosh
deploy cf-operator and kubecf on cluster

Tried Kubecf deployment with v2.2.3 and with v2.3.0, still the diego-api pod is going into "CrashLoopBackOff" state.
Getting below error:
$ kubectl logs diego-api-0 -n kubecf -c bbs-bbs
{"timestamp":"2020-10-15T08:45:28.039378053Z","level":"info","source":"bbs","message":"bbs.starting","data":{}}
Failed 'curl --fail --silent http://<IP_ADDRESS>:8890/ping' on attempt 1
{"timestamp":"2020-10-15T08:45:29.086871916Z","level":"fatal","source":"bbs","message":"bbs.sql-failed-to-connect","data":{"error":"dial tcp <IP_ADDRESS>:3306: connect: connection refused","trace":"goroutine 1 [running]:\ncode.cloudfoundry.org/lager.(*logger).Fatal(0xc00025e180, 0xe8cd3f, 0x15, 0xff7180, 0xc0003e8000, 0x0, 0x0, 0x0)\n\t/var/vcap/source/bbs/src/code.cloudfoundry.org/lager/logger.go:138 +0xc6\nmain.main()\n\t/var/vcap/source/bbs/src/code.cloudfoundry.org/bbs/cmd/bbs/main.go:140 +0x49f6\n"}}
Failed 'curl --fail --silent http://<IP_ADDRESS>:8890/ping' on attempt 2
panic: dial tcp <IP_ADDRESS>:3306: connect: connection refused
goroutine 1 [running]:
code.cloudfoundry.org/lager.(*logger).Fatal(0xc00025e180, 0xe8cd3f, 0x15, 0xff7180, 0xc0003e8000, 0x0, 0x0, 0x0)
/var/vcap/source/bbs/src/code.cloudfoundry.org/lager/logger.go:162 +0x582
main.main()
/var/vcap/source/bbs/src/code.cloudfoundry.org/bbs/cmd/bbs/main.go:140 +0x49f6

@lordcf it doesn't seem like something we can debug on our end - because you're using a unique setup.
The error you're getting is pointing to some dns issues, have you checked that?


fix: Add domain to build_client

This PR

Adds domain lookup to build_client

Related Issues

Fixes #108
How to test

Instantiate the library with and without a domain for its provider.

@beeme1mr @maxveldink
I added some tests.
I didn't want to change the behavior of the library too much, but maybe trying to instantiate a client against a domain that doesn't exist should throw or something, I feel like instantiating with the NoOp provider is unexpected behavior.

Thanks for fixing this @grepfruit19! Definitely, an oversight I had when I was trying to convert us over from name to domain. I agree that we should completely drop name wherever it's used (pre-1.0, I don't think we should have the idea of "legacy" fields; we should attempt to match the spec as close as possible).
Further, I think dropping version makes sense as well. I think @technicalpickles or @josecolella could explain why it was added, but it's not a part of the current specification and might confuse users. One other thing to think through; I don't think we can reuse Metadata for both Providers and Clients; they have different required fields. I'd be up for either dropping that class in favor of a simple hash for now or introducing ClientMetadata and ProviderMetadata classes to explicitly state the keys we allow.
Let me know if that's enough to go on, or if you need more direction here. This will definitely be a breaking change.

Sounds good, I can add the changes to drop name and version if we're in agreement. I'd rather keep this PR limited in scope as far as adding the ClientMetadataandProviderMetadata` classes however, so I'd prefer not to add those changes in this PR.

@beeme1mr @maxveldink
I've removed name from the library, I think things should be good to go now. I've held off on removing version so that y'all can make a separate PR since it seems like that has some further discussion to be had.
Let me know if there's anything else to be done!

@beeme1mr Is there a good way to check what provider a client is using then?

@beeme1mr Is there a good way to check what provider a client is using then?

Hey @grepfruit19, you can use the provider metadata on the client. Here's how we implemented that in the JS SDK.
If you're interested, this is how we passed the provider reference to the client.

@beeme1mr Then in terms of this ticket, would you be okay with me un-exposing the provider and holding off on exposing the provider metadata for future work?

@beeme1mr Then in terms of this ticket, would you be okay with me un-exposing the provider and holding off on exposing the provider metadata for future work?

Sure, no problem at all. Thanks for your work on this PR.

@beeme1mr I've updated the PR and commented out the corresponding tests

@beeme1mr I think @maxveldink is out of office today, if this looks good to you mind giving it an approve + merge?


Support for postgres overlap operator && added, natural left/right/fu…

Here are the changes that are currently made
i) DoubleAnd/Overrlap operator (&&) - supported by latest DB versions, eg. postgres
overlap takes two arrays as its operands and returns true iff they have elements in common.
list of files changed
src/main/jjtree/net/sf/jsqlparser/parser/JSqlParserCC.jjt
src/main/java/net/sf/jsqlparser/util/deparser/ExpressionDeParser.java
src/main/java/net/sf/jsqlparser/expression/ExpressionVisitor.java
src/main/java/net/sf/jsqlparser/expression/ExpressionVisitorAdapter.java
src/main/java/net/sf/jsqlparser/util/TablesNamesFinder.java
src/test/java/net/sf/jsqlparser/test/select/SelectTest.java
src/main/java/net/sf/jsqlparser/expression/operators/relational/DoubleAnd.java (new java file)
ii)  NATURAL LEFT/RIGHT/FULL OUTER JOIN - Currently the parser supports only the inner one, NATURAL JOIN

could you acutualize your pull request to the actual master


Welcome to HandyControl | HandyOrg

https://hosseini.ninja/handycontrol/
HandyControl is a WPF control library that rewrites almost all native styles and includes more than 80 custom controls (increasingly). Requirements    DownloadThe difference between official and unoff

更新后分页条的“跳转”按钮变成了英文“Jump”无法修改

The "Jump" button of the page bar cannot be changed to Chinese after the update

See here
In version 3.3.10, you should install language package from nuget for example: for chinese you should install
Handycontrols.Lang.zh-CN


[Refactor] Optimize personal and system settings

目前，项目中的个人设置和系统设置功能提供了完整的前后端支持，具有很高的灵活性，在项目初期开发时效果显著。然而，随着设置类型的增多，不同插件需要配置的内容虽各有特点，但类型大体类似。如果每种设置都单独开发页面和处理逻辑，显得既繁琐又低效，且部分内容并不需要专门的数据表来存储。为此，可以考虑提供框架级支持，简化开发流程，从而节约开发者的时间和精力。
Currently, the personal and system settings in the project provide comprehensive frontend and backend capabilities, offering great flexibility, which proves effective during the early stages of development. However, as the number of settings types increases, and different plugins require specific configurations, the variations are often minor. Developing dedicated pages and handling logic for each setting becomes cumbersome and inefficient, with some settings not necessarily requiring separate database tables. To address this, introducing framework-level support can simplify the development process and save developers’ time and effort.

在不废弃原来的做法的前提下，提供一套新的插件，用来简化设置开发


Fix documentation typos

What this PR does / why we need it: Fixes a few miscellaneous typos in the documentation.
Which issue this PR fixes: N/A
Special notes for your reviewer:
I noticed that the repo's readme mentions:
⚠ Kong Ingress Controller takes care of managing all entities in Kong's datastore as per the Ingress and custom resource definitions in k8s. Any entity created using Kong's Admin API will be deleted by the Ingress Controller.
however the FAQ mentions that it is possible to create resources outside of the controller. I'm still looking into using Kong so I haven't yet tested it myself, but it would be great if these statements could be made consistent.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Upload failed: Failed API request: invalid server

I used the shipped docker-compose with below changes,
---
version: "3.7"
services:

  minio:
    image: minio/minio:RELEASE.2022-06-03T01-40-53Z.fips
    command: server /mnt/data --console-address ":9001"
    ports:
    - 9050:9000 # API
    - 9051:9001 # Webinterface
    environment:
      MINIO_ROOT_USER: "admin-user" # changeme!
      MINIO_ROOT_PASSWORD: "admin-pass"  # changeme!
      MINIO_SERVER_URL: "http://localhost:9000"
      MINIO_SITE_REGION: "s3"
    volumes:
    - minio-data:/mnt/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/ready"]
      interval: 30s
      timeout: 20s
      retries: 3

  gose:
    image: ghcr.io/stv0g/gose:v0.4.0
    container_name: gose
    build:
      context: .
    ports:
    - 8980:8080
    environment:
      GOSE_LISTEN: ":8080"
      GOSE_BASE_URL: "https://gose.teej.xyz"
      GOSE_BUCKET: "gose-uploads"
      GOSE_ENDPOINT: "minio:9000"
      GOSE_REGION: "s3"
      GOSE_PATH_STYLE: "true"
      GOSE_NO_SSL: "true"
      GOSE_ACCESS_KEY: "dfkljghe9847t0hdflhgsd--sd" # changeme!
      GOSE_SECRET_KEY: "213lkjzciuefnl097utbldksbv90423ybfsdnlo4909jp43" # changeme!
      GOSE_MAX_UPLOAD_SIZE: "50GB"
      GOSE_PART_SIZE: "16MB"
    depends_on:
    - minio

volumes:
  minio-data:

I have exposed this via SWAG proxy and when I try to upload a file, I get this error "Upload failed: Failed API request: invalid server"

Can you please provide the proxy configuration?
Both gose and minio services need to be exposed.

Please also note, that you likely leaked your S3 credentials in the snippet above.

Closed due to missing information from issue reporter


[Bug]: Autoscale group not destroyed when running cleanup.sh script

Description
I am really surprised, but indeed after terraform destroy -auto-approve hang for a while, I tried the cleanup.sh script. It said it worked, and also terraform destroy -auto-approve was successful after it, but still one autoscale node was still alive in hetzner cloud.
Not sure what is going on, but probably this is not intended.
I se that the autoscaling still has a prefix "k3s" - I changed the clustername meanwhile to "jolin", so maybe there is an interaction going on here? If that is the case, it would be awesome if kube-hetzner could give a proper warning, that changing the cluster_name on a running cluster with autoscaling group is not supported.
Kube.tf file
locals {
  hcloud_token = "xxxxxxxxxxx"
}

module "kube-hetzner" {
  providers = {
    hcloud = hcloud
  }
  hcloud_token = var.hcloud_token != "" ? var.hcloud_token : local.hcloud_token
  source = "kube-hetzner/kube-hetzner/hcloud"
  ssh_public_key = file("~/.ssh/hetzner_id_ed25519.pub")
  ssh_private_key = file("~/.ssh/hetzner_id_ed25519")
  network_region = "eu-central" # change to `us-east` if location is ash

  control_plane_nodepools = [
    {
      name        = "control-plane-fsn1",
      server_type = "cax11",
      location    = "fsn1",
      labels      = [],
      taints      = [],
      count       = 1
    },
  ]

  agent_nodepools = [
    {
      name        = "agent-arm-largest",
      server_type = "cax41",
      location    = "fsn1",
      labels      = [],
      taints      = [],
      count       = 0,
    }
  ]
  enable_wireguard = true

  load_balancer_type     = "lb11"
  load_balancer_location = "fsn1"

  base_domain = "cloud.jolin.io"

  autoscaler_nodepools = [
    {
      name        = "autoscaled-arm-largest"
      server_type = "cax41"
      location    = "fsn1"
      min_nodes   = 1  # somehow one is also deployed if min_nodes is set to 0
      max_nodes   = 4
    }
  ]
  etcd_s3_backup = {
    etcd-s3-endpoint        = "https://gateway.storjshare.io"
    etcd-s3-access-key      = var.etcd_s3_access_key
    etcd-s3-secret-key      = var.etcd_s3_secret_key
    etcd-s3-bucket          = "jolincloud-k3s-etcd-backup"
  }
  automatically_upgrade_os = false
  cluster_name = "jolin"
  use_control_plane_lb = false
  lb_hostname = "cloud.jolin.io"

}

provider "hcloud" {
  token = var.hcloud_token != "" ? var.hcloud_token : local.hcloud_token
}

terraform {
  required_version = ">= 1.3.3"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = ">= 1.38.2"
    }
  }
}

output "kubeconfig" {
  value     = module.kube-hetzner.kubeconfig
  sensitive = true
}

variable "hcloud_token" {
  sensitive = true
  default   = ""
}

variable "etcd_s3_access_key" {
  sensitive = true
  default   = ""
}

variable "etcd_s3_secret_key" {
  sensitive = true
  default   = ""
}

Screenshots

Platform
Linux

@schlichtanders Yes, you guessed correctly. Currently this script cannot know of cluster name changes. And it would be cumbersome to try to change the Hetzner ressource name along with the node name upon cluster name change. However, PR is welcome if you can think of a way.
As this shouldn't be a common scenario, closing this for now.


Move breaking changes section to the top of 7.1 upgrade guide

So that it is not mixed in between deprecations and consistent
with the previous version upgrade guides.

@bot-gradle test and merge

Your PR is queued because #17240 is being built.


Test framework improvements

Use random set of devices from the ones that present to the server
Allow tests to continue if socket.io gets reconnected
Report success only if all succeed

This change is

PR is added to the queue for testing as 1. task. (f00187f)

Test (Success) 64613803 build is completed (f00187f)
See https://github.com/ThaliTester/TestResults/tree/64613803f00187f_Test_framework_improvements_vjrantal/ for the logs

Test 64613803f00187f(f00187f) has failed
See https://github.com/ThaliTester/TestResults/tree/64613803f00187f_Test_framework_improvements_vjrantal/ for the fail logs

PR is added to the queue for testing as 1. task. (8d447f5)

Test (Success) 64613803 build is completed (8d447f5)
See https://github.com/ThaliTester/TestResults/tree/646138038d447f5_Test_framework_improvements_vjrantal/ for the logs

Test 646138038d447f5(8d447f5) has failed
See https://github.com/ThaliTester/TestResults/tree/646138038d447f5_Test_framework_improvements_vjrantal/ for the fail logs

PR is added to the queue for testing as 1. task. (717efd7)

Test (Success) 64613803 build is completed (717efd7)
See https://github.com/ThaliTester/TestResults/tree/64613803717efd7_Test_framework_improvements_vjrantal/ for the logs

Test<PHONE_NUMBER>7efd7(717efd7) has failed
See https://github.com/ThaliTester/TestResults/tree/64613803717efd7_Test_framework_improvements_vjrantal/ for the fail logs

PR is added to the queue for testing as 1. task. (6c5f71d)

Test (Success) 64613803 build is completed (6c5f71d)
See https://github.com/ThaliTester/TestResults/tree/646138036c5f71d_Test_framework_improvements_vjrantal/ for the logs

Test 646138036c5f71d(6c5f71d) has failed
See https://github.com/ThaliTester/TestResults/tree/646138036c5f71d_Test_framework_improvements_vjrantal/ for the fail logs

PR is added to the queue for testing as 1. task. (adf70b9)

Test (Success) 64613803 build is completed (adf70b9)
See https://github.com/ThaliTester/TestResults/tree/64613803adf70b9_Test_framework_improvements_vjrantal/ for the logs

Test 64613803adf70b9(adf70b9) has failed
See https://github.com/ThaliTester/TestResults/tree/64613803adf70b9_Test_framework_improvements_vjrantal/ for the fail logs

PR is added to the queue for testing as 1. task. (8b5bc7c)

Test 646138038b5bc7c(8b5bc7c) has failed
See https://github.com/ThaliTester/TestResults/tree/646138038b5bc7c_Test_framework_improvements_vjrantal/ for the fail logs

Reviewed 8 of 13 files at r3, 2 of 3 files at r4, 5 of 6 files at r5, 1 of 1 files at r6, 1 of 1 files at r7.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from the review on Reviewable.io

PR is added to the queue for testing as 1. task. (d18c8d9)

Test (Success) 64613803 build is completed (d18c8d9)
See https://github.com/ThaliTester/TestResults/tree/64613803d18c8d9_Test_framework_improvements_vjrantal/ for the logs

Test 64613803d18c8d9(d18c8d9) has failed
See https://github.com/ThaliTester/TestResults/tree/64613803d18c8d9_Test_framework_improvements_vjrantal/ for the fail logs


Move cloudbuild to Python 3.11

Python 3.7 has reached end-of-life.
Move to Python 3.11

Thanks Prashanth! merging.


Table name is not used as-is, database schema is forced to public

When specifying a table name such as posthog.events (table events in schema posthog), it creates the table public.posthogevents.
Looking at the source code, it removes all non-alphanumeric or underscore characters and forces the usage of public schema.
Actual result
Table name is badly escaped and you can't use another schema than public
Expected result
Table name is escaped correctly and public schema is only used as a fallback when a schema isn't specified.
Relevant source code
https://github.com/PostHog/postgres-plugin/blob/38a2c6e5b71e7009ef5ddf12a88af24fdb60151e/index.ts#L84-L87
https://github.com/PostHog/postgres-plugin/blob/38a2c6e5b71e7009ef5ddf12a88af24fdb60151e/index.ts#L267-L269

Closing as this plugin has been deprecated in favor of our Postgres destination for batch exports. The new system does support passing a schema field in the configuration.


Clarifying meaning of sonar ray angles

The (crude) diagram below shows one possible interpretation of the elevation and azimuth angles corresponding to individual sonar rays. The coordinate frame matches the normal vector values returned from the depth camera:

The 'x' axis is horizontal.
The 'y' axis is vertical and inverted so increasing values moves from top to bottom.
The 'z' axis corresponds to depth from the perspective of the sensor.

The elevation and azimuth angles are a new thing we are introducing. In the interpretation suggested here, increasing angles corresponds to counterclockwise rotation.

Examples:

elevation
azimuth
direction vector

0
0
<0,0,1>

0
pi/2
<1,0,0>

0
-pi/2
<-1,0,0>

pi/2
0
<0,-1,0>

-pi/2
0
<0, 1,0>

Azimuthal angle
azimutal angle reference image
Elevation angle
[elevation angle reference image] (https://www.google.com/search?q=sonar%2C ray theory%2C horizontal%2C azimuthal&tbm=isch&hl=en-US&hl=en-US&tbs=rimg%3ACVOUtt9MQ6pHYegVIdiHH-m-&prmd=ivn&rlz=1C9BKJA_enKR911KR912&sa=X&ved=0CCoQuIIBahcKEwigzrT4_cTrAhUAAAAAHQAAAAAQKw&biw=1366&bih=905#imgrc=HxJ6B-Hr-hZ_6M)

While I'm not used to azimuthal angle definition, the elevation definition with pi/20 looking down and 0 looking forward is something I am familiar with.

OK regarding the angles, let's follow the conventions @woensug-choi proposes. One clarification regarding elevation angle--this will mean:
Elevation angle

forward 0
downward pi/2
upward -pi/2

Can you confirm? The upward is missing in your version so I want to be sure.

Regarding the vectors, the function you've given has elevation corresponding to the z axis. I think this is more natural but, again, it is not what the depth camera does. In order for the incidence angle equation to work correctly, we'll need both the ray_vector and the normal_vector to use the same axis labels.
I think it would be nice if our plugin's behavior matched what one would expect from using the GPURay sensor and the usually object coordinate frames in Gazebo. I'm going to do some tests to verify these and propose a complimentary approach. This may mean we translate the normals returned by the depth camera into a more intuitive direction vector.

After some further testing of the GPURay sensor, I think the right thing to do is keep my original proposal of having positive angles correspond with counterclockwise rotation, as this is consistent with the behavior of the GPURay.
Here is a screenshot of rays coming from a lidar device where the horizontal FOV has been set to extend from 0 to 30 degrees:

Here is a screenshot of rays where the vertical FOV is set from -30 to 0 degrees. Note that a negative angle points down in this case.

Unless there is a compelling reason to deviate, let's stick with this convention.

In order to confirm the standard coordinates in Gazebo, I used the GUI to visualize forces applied to the tank in the standalone demos. The results were as follows:

x axis: negative values indicate port, positive starboard
y axis: negative is backward (stern), positive forward (bow)
z axis: negative is down, positive up

Here screenshots for confirmation:
x direction

y direction

z direction

Thank you for confirming! I agree with the idea that we stick to gazebo's and Depth camera sensor's conventions since sonar conventions can be changed easily at this stage.
To summarize,
Cartesian coordinate (XYZ)

x axis: negative is backward (stern), positive forward (bow)
y axis: negative values indicate port, positive starboard
z axis: negative is down, positive up

Horizontal (Azimuthal) - Vertical (Elevation)

Horizontal axis: positive values indicate port, negative starboard
Vertical axis: positive looking up, negative looking down

To calculate alpha (incident angle)
% calculates a direction vector for the ray
def ray_angles_to_vector(azimuth, elevation):
x = cos(-azimuth)*cos(elevation)
y = sin(-azimuth)*cos(elevation)
z = sin(elevation)
return np.array([x,y,z])
% takes two numpy arrays and returns the angle of incidence between them in radians
def get_incidence(ray_vector, normal_vector):
return pi - acos(ray_vector.dot(normal_vector))
% main code
alpha = get_incidence(ray_angles_to_vector(ray.azimuthAngle,ray.elevationAngle),ray_angles_to_vector(depthCameraObtainedNormal[1],depthCameraObtainedNormal[2]))

Great! I think we are converging, but not quite there. If we use the Cartesian axes you propose, we have to alter the direction vectors returned from the depth camera to match them. Something like:
# changes normals from depth camera to match our axis choices
def fix_normal(depth_normal):
    x,y,z = depth_normal
    return np.array([z, x, -y])

# calculates a direction vector for the ray
def ray_angles_to_vector(azimuth, elevation):
    x = cos(-azimuth)*cos(elevation)
    y = sin(-azimuth)*cos(elevation)
    z = sin(elevation)
    return np.array([x,y,z])

# takes two numpy arrays and returns the angle of incidence between them in radians
def get_incidence(ray_vector, normal_vector):
    return pi - acos(ray_vector.dot(normal_vector))

# main
# set ray.azimuth and ray.elevation from user specified configuration
# get ray.range, ray.normal, ray.sonar_retro corresponding to the ray using Gazebo's depth camera.
ray_vector = ray_angles_to_vector(ray.azimuth,ray.elevation)
normal_vector = fix_normal(ray.normal)
alpha = get_incidence(ray_vector, normal_vector)

Alternatively, we could just keep the depth camera axes and make our axes match theirs. In that case we would use:
# calculates a direction vector for the ray
def ray_angles_to_vector(azimuth, elevation):
    x = sin(-azimuth)*cos(elevation)
    y = sin(-elevation)
    z = cos(azimuth)*cos(elevation)
    return np.array([x,y,z])

# takes two numpy arrays and returns the angle of incidence between them in radians
def get_incidence(ray_vector, normal_vector):
    return pi - acos(ray_vector.dot(normal_vector))

# main
# set ray.azimuth and ray.elevation from user specified configuration
# get ray.range, ray.normal, ray.sonar_retro corresponding to the ray using Gazebo's depth camera.
ray_vector = ray_angles_to_vector(ray.azimuth,ray.elevation)
normal_vector = fix_normal(ray.normal)
alpha = get_incidence(ray_vector, normal_vector)

The second version is slightly weirder because the depth camera vectors are weird. I think they are equivalent and I'm fine with either one. @BruceMty do you have a preference?

@mabelzhang suggests the first version, in which we translate camera coordinates to the robot coordinates in the world.

Following discussion in the meeting this morning, we need to make a minor adjustment so positive values along the y axis go to port rather than starboard for consistency with the right hand rule.
Here is the final summary:
Cartesian coordinate (XYZ)

x axis: negative is backward (stern), positive forward (bow)
y axis: negative values indicate starboard, positive port
z axis: negative is down, positive up

Ray Angles

Horizontal (Azimuth): positive values indicate port, negative starboard
Vertical (Elevation): positive looking up, negative looking down

To calculate alpha (incident angle)

It appears ROS has a standard convention that I was not aware of, written here: https://www.ros.org/reps/rep-0103.html#coordinate-frame-conventions
Happily, it matches the solution we eventually converged on.


fix even more taf recomputations

What changes does this PR introduce?
small bug fixes
What is the current behaviour?
Recomputation and conflict warnings for dwnslope_apply.F, calc_3d_diffusivity.F (PCELL_MIX_CODE)
What is the new behaviour
warnings and recomputations fixed by

reorganisation of code in dwnslope_apply.F
local tape and store directives in calc_3d_diffusivity.F

Does this PR introduce a breaking change?
No, just cleaner code. Results change for AD-lab_ad because of dwnslope_apply.F, to be examined. That's why this is a draft.
Other information:
The only verification experiments left with recomputation warnings are:

global_oce_biogeo_bling (3 in pkg/bling, 6 in solve_pentadiagonal and 1 in solve_tridiagonal, the latter because SOLVE_DIAGONAL_KINNER is defined, if you don't want these warning use the default code)
global_ocean.cs32x15 (4 in seaice_lsr, we know how to get rid of the, but the relevant options are not set on purpose to remind us that the lsr-solver is an unsolved problem)
the bling-related recomputations could probably be fixed easily, but I do not know the code well enough to do it safely/quickly.

Suggested addition to tag-index

fix taf recomputation and conflict warnings in dwnslope_apply.F, calc_3d_diffusivity.F

@mmazloff Maybe you want to use this PR to also address the remaining bling-recomputations. These are mainly due to "clever" vertical loops, where (scalar) variables are overwritten in each loop iteration (similar to dwnslope_apply.F). This leads to nested k-loops like this:
DO ij
 DO k=Nr,1,-1
  DO k1=1,k-1
...

which may not be a catastrophe, but having 1D vectors or 2D fields for these variables could probably already fix this.

@mmazloff I have a fix for the remaining recomputations in bling (global_oce_biogeo_bling). It's a mix of local and global tapes. One can easily make some or all of the local tapes global or vice versa, but I am not sure what's the best in terms of performance vs. memory footprint. Maybe I can push it and you can tell me, if you want that or not.

Thanks Martin! Sounds great! Please do what you think best. I’ll have a
look after you push, but I strongly suspect I will support the fix as you
choose to implement it.
Matt
On Wed, Apr 27, 2022 at 12:14 PM Martin Losch @.***>
wrote:

@mmazloff
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mmazloff&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=HSHS34ROdfL7f2oVxuKB761hrMvWN1RWA5k3SHGts_s&m=5JY_HQu_9O_dPC5rUwSQ3A5lSlOqzM9veAbeezgCNkKw5dNXNNND3j7fjI_2Ofxe&s=T5cYRlPIUqOvz65npLkPiH9TQXVpDrqR0lv2jsWTzoY&e=
I have a fix for the remaining recomputations in bling
(global_oce_biogeo_bling). It's a mix of local and global tapes. One can
easily make some or all of the local tapes global or vice versa, but I am
not sure what's the best in terms of performance vs. memory footprint.
Maybe I can push it and you can tell me, if you want that or not.
—
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_MITgcm_MITgcm_pull_628-23issuecomment-2D1111383448&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=HSHS34ROdfL7f2oVxuKB761hrMvWN1RWA5k3SHGts_s&m=5JY_HQu_9O_dPC5rUwSQ3A5lSlOqzM9veAbeezgCNkKw5dNXNNND3j7fjI_2Ofxe&s=dPiFPja0ofsD17gDizNIgL1Cxs8DfatxviamTtOXpvM&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AIEXPOEWFP75XVP5WT2KID3VHGGZBANCNFSM5UKXHEBQ&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=HSHS34ROdfL7f2oVxuKB761hrMvWN1RWA5k3SHGts_s&m=5JY_HQu_9O_dPC5rUwSQ3A5lSlOqzM9veAbeezgCNkKw5dNXNNND3j7fjI_2Ofxe&s=bpG09NfP2wBCu5GLF3c24xupUp75cj_vKHkILZ4qzog&e=
.
You are receiving this because you were mentioned.Message ID:
@.***>

@mmazloff let me know if you think that we should make the tapes for XXXflux_u also global. It's just a matter of defining that tape and computing the proper keys.

@mmazloff commit 1e3bc24 shows, how the global tape works (and this actually avoid some recomutations, too), also, there are new stores that avoid recomputing two subroutines (which I think is worth it) and five stores that avoid recomputing a medium size loop. Maybe these five stores are not necessary and I can remove them again, if you think that having a smaller memory footprint is important.

@mjlosch I went over the store additions in bling and they all look great! I have no concerns. Thank you very much for the spring cleaning!

The size of the executable increase only marginally (1.3%), so that should not be a concern:
(base)  verification > size global_oce_biogeo_bling/build/mitgcmuv_ad
__TEXT	__DATA	__OBJC	others	dec	hex
17694720<PHONE_NUMBER>	0<PHONE_NUMBER><PHONE_NUMBER>	15670c000 (this branch)
17022976<PHONE_NUMBER>	0<PHONE_NUMBER><PHONE_NUMBER>	155584000 (master)

Hence I would go for the global tapes for all new fields. There is little improvement in runtime in global_oce_biogeo_bling, unfortunately.

@mmazloff thanks, please see you can also agree with my final solution.
@jm-c could you check the changes in the dwnslope_apply.F ? This does not involve and TAF store, just a little reorganisation, but results change a little, so I am not sure, if I did this correctly.

LGTM!

I simplify further dwnslp_apply.F, and this now make use of 1-D vector gTrLoc.
Now regarding the changes in dwnslp_apply.F, I think they are good and they remove a (tricky) dependency on the direction of the k-loop. I don't see any changes in the output (with -devel) in forward run, and this is good.
The adjoint results are a little bit different (lab_sea & lab_sea.noseaicedyn) but probably within machine truncation precision, which is expected given the simplification mentioned above.
I think it's time to remove the WIP label and work toward merging this PR (will need to update a couple of reference output).


What is "a valid version specifier" ?

https://github.com/astral-sh/ruff-action#advanced-usage mentions

You can pin a version, or use any valid version specifier.

So I tried with 0.6.*, == 0.6.* and ~= 0.6.9, as extracted from my pyproject.toml, but they all lead to an error https://github.com/Avasam/typed-D3DShot/actions/runs/11260491537/job/31311838867?pr=1#step:4:3 & https://github.com/Avasam/typed-D3DShot/actions/runs/11260669108/job/31312397054?pr=1#step:4:3 & https://github.com/Avasam/typed-D3DShot/actions/runs/11260745410/job/31312637530?pr=1#step:4:3
I suppose this just wasn't supported despite the wording. Now that the repo is forked under Astral, I'd like to request that feature.

Looks like this is completed by https://github.com/astral-sh/ruff-action/pull/17 !


Update tutor files

Some tutor files were older compared with other files as I mentioned in https://github.com/vim/vim/issues/3191#issuecomment-404997484.

tutor.ca.utf-8 was older than tutor.ca.
tutor.es.utf-8 was older than tutor.es.
tutor.fr was older than tutor.fr.utf-8.
tutor.zh.big5 was older than tutor.zh.utf-8 and tutor.zh_tw.utf-8.

Seeing the runtime/tutor/Makefile, I found that some translations use tutor.[ll].utf-8 file as the master and other translations use tutor.[ll] as the master. I think it might be confusing.
Nowadays most people use utf-8, so making tutor.[ll].utf-8 as master might be better?

Codecov Report

Merging #3209 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3209      +/-   ##
==========================================
- Coverage   76.44%   76.42%   -0.02%
==========================================
  Files          93       93
  Lines      136779   136779
==========================================
- Hits       104556   104540      -16
- Misses      32223    32239      +16

Impacted Files
Coverage Δ

src/libvterm/src/state.c
47.6% <0%> (-0.98%)
:arrow_down:

src/message.c
74.64% <0%> (-0.25%)
:arrow_down:

src/if_xcmdsrv.c
84.53% <0%> (-0.18%)
:arrow_down:

src/term.c
59.72% <0%> (-0.16%)
:arrow_down:

src/gui_gtk_x11.c
48.08% <0%> (-0.05%)
:arrow_down:

src/channel.c
83.03% <0%> (-0.04%)
:arrow_down:

src/gui.c
49.53% <0%> (ø)
:arrow_up:

src/window.c
82.21% <0%> (+0.03%)
:arrow_up:

src/os_unix.c
57.56% <0%> (+0.13%)
:arrow_up:

src/gui_beval.c
62% <0%> (+0.43%)
:arrow_up:

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 44a693a...99ae714. Read the comment docs.

I'll include it, thanks.


dragonflybsd: expose waitid() prototype + related constants

This exposes the POSIX waitid() process management function and some related defined constants for dragonflybsd. It includes one correction: WSTOPPED which previously had the wrong value. Noticed this when a crate that depended on it, process_control, wouldn't compile on this platform.

r? @Amanieu
(rust-highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit 6bfee3cb496accaabf672674626b4d22d58988b8 has been approved by Amanieu

:hourglass: Testing commit 6bfee3cb496accaabf672674626b4d22d58988b8 with merge a49576be6b57175785630c18b29dbad7f68a2aa1...

:broken_heart: Test failed - checks-actions

2021-03-03T01:18:36.6123268Z error: constant is never used: `WNOHANG`
2021-03-03T01:18:36.6125425Z    --> src/unix/bsd/freebsdlike/dragonfly/mod.rs:986:1
2021-03-03T01:18:36.6126225Z     |
2021-03-03T01:18:36.6127157Z 986 | pub const WNOHANG: ::c_int = 0x1;
2021-03-03T01:18:36.6127572Z     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2021-03-03T01:18:36.6127831Z     |
2021-03-03T01:18:36.6128278Z note: the lint level is defined here
2021-03-03T01:18:36.6129087Z    --> src/lib.rs:18:38
2021-03-03T01:18:36.6129678Z     |
2021-03-03T01:18:36.6130047Z 18  | #![cfg_attr(libc_deny_warnings, deny(warnings))]
2021-03-03T01:18:36.6130436Z     |                                      ^^^^^^^^
2021-03-03T01:18:36.6130867Z     = note: `#[deny(dead_code)]` implied by `#[deny(warnings)]`
2021-03-03T01:18:36.6131187Z
2021-03-03T01:18:36.6131545Z error: constant is never used: `WUNTRACED`
2021-03-03T01:18:36.6132183Z    --> src/unix/bsd/freebsdlike/dragonfly/mod.rs:987:1
2021-03-03T01:18:36.6132584Z     |
2021-03-03T01:18:36.6132905Z 987 | pub const WUNTRACED: ::c_int = 0x2;
2021-03-03T01:18:36.6133290Z     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2021-03-03T01:18:36.6133466Z
2021-03-03T01:18:36.6521873Z error: aborting due to 2 previous errors

Oh, I missed that, unfortunately, but I can reproduce it here. If it's a pub const, why does it trip up if it's never used? I looked around for another constant (WEXITED) to see how it was used and I could only find its definition. How can it tell if something is used or not?

@bors r+ squash

:pushpin: Commit 56c98cbe2edc36e9edacc371641d2d87fde1ee45 has been approved by JohnTitor

:hourglass: Testing commit 56c98cbe2edc36e9edacc371641d2d87fde1ee45 with merge ec86e5fb3258a844ece771d2c6f0fbf152086eab...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing ec86e5fb3258a844ece771d2c6f0fbf152086eab to master...

Merged on master, thanks!

sure thing! thanks for the tip on fixing the PR