Enhancment Request: worn/inventory

hello i see you have
 player:NAME(REGEX), npc:NAME(REGEX), entityname:NAME(REGEX), helditem:MATERIALNAME(REGEX), group:GROUPNAME(EXACT), event:pvp/pvnpc/pve
what about the items on players like armor/hats ? and inventory items?

the idea behind helditem is so you can watch for holding weapons.
What's the benefit of worn items?

illegal armor..say someone is running around with some chain armor or has a common/uncommon block as a hat

"illegal armor" wot? Illegal hats too? What?!

long story short im trying to make some guards for a prison server..

You should probably supplement your Sentinel NPCs with a Denizen script then. http://wiki.citizensnpcs.co/Denizen
Something like this:
mynpc:
    type: assignment
    debug: false
    actions:
        on assignment:
        - trigger name:proximity state:true radius:10
        on enter proximity:
        - if <player.equipment.contains_text[chain]> {
          - execute as_server "npc sel <npc.id>" silent
          - execute as_server "sentinel addtarget player:<player.name>" silent
          }

thank you for sending me in the right direction :heart_eyes:  i'll start researching and testing in the morning,
sorry for any troubles my simple mind may have agrovated  :smile:
:heart:

so playing around with denizen and i know my script is far from complete and rable rable rable.
running /sentiel forgive the npc still keeps attacking the person who upset the npc LOL
NPC:
    type: assignment
    debug: false
    actions:
        on assignment:
        - chat "Duty calls"
        - trigger name:proximity state:true radius:15
        on enter proximity:
        - if <player.inventory.contains[302|303|304|305|357|442|81|373|289|338|46|407|261|385|259|353]> {
          - execute as_server "npc sel <npc.id>" silent
          - execute as_server "sentinel addtarget player:<player.name>" silent
          }
        - trigger name:click state:true
        on click:
        - chat "<red>Get back in line inmate"

by the way thank you again for recommending denizen, once i get this down it should be pretty fun

Try this:
NPC:
    type: assignment
    debug: false
    actions:
        on assignment:
        - chat "Duty calls"
        - trigger name:proximity state:true radius:15
        - trigger name:click state:true
        on enter proximity:
        - if <player.inventory.contains[302|303|304|305|357|442|81|373|289|338|46|407|261|385|259|353]> {
          - execute as_server "npc sel <npc.id>" silent
          - execute as_server "sentinel addtarget player:<player.name>" silent
          }
          else {
          - execute as_server "npc sel <npc.id>" silent
          - execute as_server "sentinel removetarget player:<player.name>" silent
          }
        on click:
        - chat "<red>Get back in line inmate"

In particular, the else block.
Optionally throw in a sentinel forgive inside the else block as well to make sure all combat ceases.
If you want them to be able to stop the moment the player gives up their illegal items,
change on enter proximity: to on move proximity:


how to select the Object3DData in the scene?

public void processTouch(float x, float y) {
	Object3DData objectToSelect = CollisionDetection.getBoxIntersection(getObjects(), parent.getgLView().getModelRenderer(), x, y);
	if (objectToSelect != null) {
		if (getSelectedObject() == objectToSelect) {
			Log.i("SceneLoader", "Unselected object " + objectToSelect.getId());
			setSelectedObject(null);
		} else {
			Log.i("SceneLoader", "Selected object " + objectToSelect.getId());
			setSelectedObject(objectToSelect);
		}
		float[] point = CollisionDetection.getTriangleIntersection2(getObjects(), parent.getgLView().getModelRenderer(), x, y);
		if (point != null) {
			addObject(Object3DBuilder.buildPoint(point).setColor(new float[]{1.0f,0f,0f,1f}));
		}
	}
}

why the objectToSelect is always null?

It shouldn't. objetToSelect is null only when touch (x,y) doesn't intersect any object.
What android / device are you using?

Hey. Do you still have the issue?

@andresoviedo I have the same issue


[apostrophe] No session secret provided, please set secret for apostrophe-express module

Hello @boutell, I originally posted this on the Google+ group but was asked to recreate this here and assign to you. Your help is greatly appreciated.
I am in the process of getting apostrophe to run by following the instructions detailed here:
http://apostrophenow.org/tutorials/getting-started/creating-your-first-project.html
I have installed the cli tool and created my first project. However running 'node app.js' throws this exception:
WARNING: No session secret provided, please set `secret` for apostrophe-express module in app.js
fs.js:897
  return binding.symlink(preprocessSymlinkDestination(target, type, path),
                 ^

Error: EPERM: operation not permitted, symlink 'C:\Users\admin\Desktop\Projects\apos-project\node_modules\apostrophe\lib\modules\apostrophe-assets\public' -> 'C:\Users\admin\Desktop\Projects\apos-project\public\modules\apostrophe-assets'
    at Error (native)
    at Object.fs.symlinkSync (fs.js:897:18)
    at C:\Users\admin\Desktop\Projects\apos-project\node_modules\apostrophe\lib\modules\apostrophe-assets\index.js:403:14
    at C:\Users\admin\Desktop\Projects\apos-project\node_modules\lodash\index.js:3073:15
    at baseForOwn (C:\Users\admin\Desktop\Projects\apos-project\node_modules\lodash\index.js:2046:14)
    at C:\Users\admin\Desktop\Projects\apos-project\node_modules\lodash\index.js:3043:18
    at Function.<anonymous> (C:\Users\admin\Desktop\Projects\apos-project\node_modules\lodash\index.js:3346:13)
    at self.symlinkModules (C:\Users\admin\Desktop\Projects\apos-project\node_modules\apostrophe\lib\modules\apostrophe-assets\index.js:384:9)
    at C:\Users\admin\Desktop\Projects\apos-project\node_modules\async\lib\async.js:718:13
    at iterate (C:\Users\admin\Desktop\Projects\apos-project\node_modules\async\lib\async.js:262:13)
    at async.forEachOfSeries.async.eachOfSeries (C:\Users\admin\Desktop\Projects\apos-project\node_modules\async\lib\async.js:281:9)
    at _parallel (C:\Users\admin\Desktop\Projects\apos-project\node_modules\async\lib\async.js:717:9)
    at Object.async.series (C:\Users\admin\Desktop\Projects\apos-project\node_modules\async\lib\async.js:739:9)
    at Object.self.afterInit (C:\Users\admin\Desktop\Projects\apos-project\node_modules\apostrophe\lib\modules\apostrophe-assets\index.js:348:20)
    at C:\Users\admin\Desktop\Projects\apos-project\node_modules\apostrophe\index.js:91:25
    at C:\Users\admin\Desktop\Projects\apos-project\node_modules\async\lib\async.js:181:20

I attempted to add configuration for apostrophe-express by adding the code below to the app.js config object, but still not working:
var apos = require('apostrophe')({
    //...
    modules: {
        //...
        'apostrophe-express': {
              secret: 'secret password'
        }
    }
});

I also tried:
var apos = require('apostrophe')({
    //...
    secret: 'secret password'
});

I am investigating ApostropheCMS as a possible content management solution for the company I work at. Any help would be really appreciated.
Many thanks in advance.

As was just announced in the google group, this is fixed in Apostrophe 2.1.1, which is now compatible with Windows when not running as administrator.


Run script failed

I installed nix-script, made dummy script test
#!/usr/bin/env nix-script-haskell
#!haskellPackages text

{-# LANGUAGE OverloadedStrings #-}

import Data.Text.IO

main :: IO ()
main = Data.Text.IO.putStrLn "Hello, World!"

and it failed on run:
❯ ./test
error: opening lock file '/nix/store/w6f248k38ymm2bffq6wx0kgda6a4hprk-scripts.lock': Permission denied
(use '--show-trace' to show detailed location information)
nix-script: readCreateProcess: nix-build "--no-out-link" ".nix-script-cache" (exit 1): failed

i tried sudo before. it doesn't help
./hello.sh
these derivations will be built:
  /nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv
building '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv'...
unpacking sources
unpacking source archive /nix/store/wa8np38w485y9lr6v7ps95x58hj9sdfj-scripts
source root is scripts
patching sources
configuring
no configure script, doing nothing
building
gcc: fatal error: input file 'hello.sh' is the same as output file
compilation terminated.
`cc' failed in phase `Linker'. (Exit code: 1)
builder for '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv' failed with exit code 1
error: build of '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv' failed
nix-script: readCreateProcess: nix-build "--no-out-link" ".nix-script-cache" (exit 100): failed

❯ sudo ./hello.sh
[sudo] password for metaxis:
these derivations will be built:
  /nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv
building '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv'...
unpacking sources
unpacking source archive /nix/store/wa8np38w485y9lr6v7ps95x58hj9sdfj-scripts
source root is scripts
patching sources
configuring
no configure script, doing nothing
building
gcc: fatal error: input file 'hello.sh' is the same as output file
compilation terminated.
`cc' failed in phase `Linker'. (Exit code: 1)
builder for '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv' failed with exit code 1
error: build of '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv' failed
nix-script: readCreateProcess: nix-build "--no-out-link" ".nix-script-cache" (exit 100): failed

❯ ./hello.sh
these derivations will be built:
  /nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv
error: cannot create '/nix/store/m32lcqypzhyibn6nf9jmh80al6ljg9py-hello.sh.drv.chroot': Permission denied
nix-script: readCreateProcess: nix-build "--no-out-link" ".nix-script-cache" (exit 1): failed

Can you build other derivations or is this problem specific to nix-script? For example, can you build GNU hello?

I did rm -rf /nix and installed it once again and got for the same script:
❯ test-hello
these derivations will be built:
  /nix/store/p3zz30vddb7jaxw8j7ypb33m6lnsd91v-test-hello.drv
building '/nix/store/p3zz30vddb7jaxw8j7ypb33m6lnsd91v-test-hello.drv'...
unpacking sources
unpacking source archive /nix/store/myh92qbcfi055w6iwnasjfjyv7cdwydz-scripts
source root is scripts
patching sources
configuring
no configure script, doing nothing
building
target `test-hello' is not a module name or a source file
builder for '/nix/store/p3zz30vddb7jaxw8j7ypb33m6lnsd91v-test-hello.drv' failed with exit code 1
error: build of '/nix/store/p3zz30vddb7jaxw8j7ypb33m6lnsd91v-test-hello.drv' failed
nix-script: readCreateProcess: nix-build "--no-out-link" ".nix-script-cache" (exit 100): failed

Can you build other derivations or is this problem specific to nix-script? For example, can you build GNU hello?
I guess something was wrong. Therefore I start from clean nix installation.

What is test-hello in the coffee sample above?

#!/usr/bin/env nix-script-haskell
#!haskellPackages text

{-# LANGUAGE OverloadedStrings #-}

import Data.Text.IO

main :: IO ()
main = Data.Text.IO.putStrLn "Hello, World!"

so that's just a text file with the executable bit set, right? If so, I was able to reproduce this! Hooray! I'll see about fixing it sometime this week.

Right. Cool!

Alright, I added a new test to the suite and I think this is fixed. GitHub automatically marked this as closed—but I'm reopening until you can confirm that it works for you now!


Pokemon FireRed/LeafGreen - Sprites are missing from intro of game

Hi, In beginning intro to pokemon Firered and Leafgreen where professor Oak talks to you and where you pick your character, Professor Oaks and the male/female protagonist sprites are missing. The game seems fine otherwise but I am only at the beginning of the game.
Thank you

Can you insure that you are utilizing a dump of an official GBA BIOS and not the community BIOS included in SkyEmu?

I got a gba BIOs and it worked


Selected app in menu

In the launcher menu it would be great and logical to indicate currently active app. I see no obvious way now without a big mess.
I guess the problem is the current approach with htmlmerger. This makes is difficult the do this rather simple thing without a javascript hack.

There is a duplicate of this issue that has slightly more info: https://github.com/StarcounterPrefabs/Launcher/issues/244
Closing this to avoid duplication.


No sound with Raspbian Stretch Lite and Hifi-Berry clone

I was trying to install it from source on an Raspberry Pi 2 with Raspbian Stretch Lite fresh install. I am using a Hifi-Berry clone (Pifi DAC+). It seems like to work after I start the script with
LD_LIBRARY_PATH=$PWD python main.py --bitrate 320 --name Test --playback_device hw:CARD=sndrpihifiberry --mixer Digital
However when I start a song there is no sound. I then tested the sound card with mplayer which shows the sound card works.
I have redone the exact same installation with a Raspbian Jessie Lite image. With Jessie Lite all works fine. I also tested the onboard sound card which works perfectly with the script.
Also tested the --mixer_device_index parameter.
LD_LIBRARY_PATH=$PWD python main.py --bitrate 320 --name Test --playback_device hw:CARD=sndrpihifiberry --mixer_device_index 0
No success
aplay -L output:
null
Discard all samples (playback) or generate zero samples (capture)
default
sysdefault:CARD=ALSA
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device
dmix:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device
dmix:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device
dsnoop:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device
dsnoop:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device
hw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions
hw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions
plughw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions
plughw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions
sysdefault:CARD=sndrpihifiberry
snd_rpi_hifiberry_dacplus,
Default Audio Device
dmix:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dacplus,
Direct sample mixing device
dsnoop:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dacplus,
Direct sample snooping device
hw:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dacplus,
Direct hardware device without any conversions
plughw:CARD=sndrpihifiberry,DEV=0
snd_rpi_hifiberry_dacplus,
Hardware device with all software conversions

Also experiencing this issue. Relevant logs (notably "Unable to acquire device"). Any help would be appreciated! Thanks for building this software.
ESDK: callback context (nil), event 15, source: (nil), param (nil) ESDK: callback context (nil), event 1001, source: (nil), param 0x76100670 ESDK: callback context (nil), event 8, source: (nil), param (nil) ESDK: Calling SpCallbackPlaybackSeek playback_seek: 105882 Requesting Bytes: 4138k => 4266k +128k (used: 0k, buf: 128k, thres: 48k, rate: 320k) ESDK: Notifying kSpPlaybackEventAudioFlush kSpPlaybackEventAudioFlush ESDK: Notifying kSpPlaybackNotifyPlay kSpPlaybackNotifyPlay Unable to acquire device:  Device or resource busy [hw:1] WARNING: Underrun in download buffer! WARNING: Underrun in download buffer! WARNING: Underrun in download buffer!

Yes, spotify-connect-web stopped working on Stretch.
Perhaps related #133

I had similar issues. I created some code that replaces the usage of alsaaudio with pymedia. Which fixes the issues I had. I guess it uses the default audio output, so if you have configured that correctly it should work.
See: https://github.com/Fornoth/spotify-connect-web/pull/136

hi, any news on this? Thnaks

I had similar issues. If I tried to route the sound from spotify-connect-web via dmix to my i2s-soundcard it did not work. But when I directly routed the sound to my i2s-card it worked. However, with this routing, I cannot combine the usage of the soundcard with OSMC. hence, I reverted back to Jessie for now. Maybe it is more a Jessie-Alsa problem?

Any news here? I just tried again with all updates at Stretch but it still doesn't work via dmix. I revert back to my images for Jessie


GSSOC EXT NOTICE: Improper Labeling in the Project

Dear Project Admin, notes-app
It has come to our attention that your repository not applying the necessary labels to issues and merged PRs, which is affecting contributor scores on the leaderboard.
Please ensure you use the correct labels:

gssoc-ext
level1, level2, level3
hacktoberfest-accepted (only if your repository have Hacktoberfest topic in description)

NOTE: Level labels should not have any dashes between them. Spaces are allowed, but no dashes should be used.
Kindly review and update the labels on your issues and PRs to ensure fairness for all contributors. Failure to address this may result in your project being flagged.
Thank you,
Core Team
GSSoC '24 Extended

@yashmandi please make sure to follow these guidelines

sure @aditya-bhaumik @AKSHITHA-CHILUKA , we'll take care of those things ;)

@yashmandi all your closed issue's and pr should also have labels please add them

see no labels , all your contributors are not getting points bcz of this

@AKSHITHA-CHILUKA  Ma'am kindly we didn't add labels on these issues before closing because these are not assigned to anyone because of duplicate issue .Others PR's and issues have correct labelling from starting .


Restructure the Repo

restructure the repo in a branch, so we move from RNW to tex files for the slides
that means you have to pull out the rcode from the slides and put them into well structured extra files in the rsrc folder

do this in a branch. do it for 1-2 chapters cleanly, and get feedback

do NOT change anything else, like contents. ensure that the external files are well named and reproducible

a script should be fully reproducible, and properly save all required objects (these will in 99,9% be tables and figs) at the end on disk, under a proper name. you need to somehow make decisions how much goes into one script. please do this "intelligently"

scripts shouldn't be too long. and if stuff is completely independent of each other, put it in different scripts

if multiple plots all build upon each other / and or they all need the same lengthy setup code, put them in 1 script which stores multiple plots

that's finished, right? Then please close the issue.

that's finished, right? Then please close the issue.


Add vuls in dockerfile

[
  {
    "rule": "CIS 4.1 Create a user for the container",
    "violations": [
      ".git/logs/refs/remotes/origin/add-vuls-in-dockerfile",
      ".git/refs/heads/add-vuls-in-dockerfile",
      ".git/refs/remotes/origin/add-vuls-in-dockerfile",
      "Dockerfile",
      ".git/logs/refs/heads/add-vuls-in-dockerfile"
    ]
  },
  {
    "rule": "CIS 4.2 Use trusted base images for containers",
    "violations": [
      "Dockerfile: httpd:2.4.51"
    ]
  },
  {
    "rule": "CIS 4.3 Do not install unnecessary packages in the container",
    "violations": []
  },
  {
    "rule": "CIS 4.6 Add HEALTHCHECK instruction to the container image",
    "violations": [
      ".git/logs/refs/heads/add-vuls-in-dockerfile",
      ".git/logs/refs/remotes/origin/add-vuls-in-dockerfile",
      ".git/refs/heads/add-vuls-in-dockerfile",
      ".git/refs/remotes/origin/add-vuls-in-dockerfile",
      "Dockerfile"
    ]
  },
  {
    "rule": "CIS 4.7 Do not use update instructions alone in the Dockerfile",
    "violations": [
      "Dockerfile"
    ]
  },
  {
    "rule": "CIS 4.9 Use COPY instead of ADD in Dockerfile",
    "violations": [
      "Dockerfile"
    ]
  },
  {
    "rule": "CIS 4.10 Do not store secrets in Dockerfiles",
    "violations": [
      "Dockerfile: LABEL contains secret*"
    ]
  }
]


Add ros2cli known issues on Windows.

Precisely what the title says. Purposefully ignored https://github.com/ros2/ros2cli/issues/630, as I hope I can fix it before the patch release.

Rebased to target rolling.

@Mergifyio backport galactic foxy dashing


Weights file format is changed, function partial_loader fails

Hi, thanks for your effort for making it easy to load and do inference from large models.
I tried your code on a gpt-j model with different model file format, the weight files of the model are in several .pt files not like a single .bin file which your code function partial_loader() expects, does the code work with multiple weight file ? , how can i change it.

Hi, You're welcome
Please provide more details on the weights you're using. The partial loader is aimed to load the large .pt or .bin file that can't be loaded directly to memory due to low memory. For example, the gpt-j bin file can be obtained from here.
If you share the weights you're using and the approach you have taken, we can investigate and solve the issue better.

Thanks for replying, https://huggingface.co/NovelAI/genji-python-6B-split/tree/main/model , i am trying to load these weights

If the model doesn't fit in your systems RAM and VRAM, then I'm afraid you wouldn't be able to use the split checkpoints with PyTorch-LIT as it's currently not supported.
Actually, in your case, you don't need to use the partial loading utility, that's for the case that the model file is too large for the system's RAM/VRAM that even torch.load throws OOM before inference for model preparation, here you have already chunked files that can be sequentially loaded without any errors.
What you should do is write a new variation of prepare_params that gets the chunked directory as input and load the files sequentially and retrieve the metadata for writing it in the NumPy memmap. After that, the inference would be easily possible in a low-memory environment.
I'm currently busy and I won't be able to implement that variation soon, but you're completely welcome to fork the repository and implement then do a PR. Feel free to ask any questions about the implementation under this issue if needed.

yes the model is too large for vram, i have a 8gb rtx 2060, i needed smooth inference early and will try the method you described if other techniques also not work, thanks for help.


Fix inverted h3Distance test

Thanks @RichardVasquez for pointing this out. The test should assert commutativity.
Fixes #424

Coverage remained the same at 99.25% when pulling 3f271343bb703cd8d1db264a26348eb00824c82e on isaacbrodsky-patch-1 into b3a6a432c985f20e8ece82b7dae3f4002e8d0bb1 on master.

Coverage remained the same at 99.25% when pulling 3f271343bb703cd8d1db264a26348eb00824c82e on isaacbrodsky-patch-1 into b3a6a432c985f20e8ece82b7dae3f4002e8d0bb1 on master.


[SPARK-24675][SQL]Rename table: validate existence of new location

What changes were proposed in this pull request?
If table is renamed to a existing new location, data won't show up.
scala>  Seq("hello").toDF("a").write.format("parquet").saveAsTable("t")

scala> sql("select * from t").show()
+-----+
|    a|
+-----+
|hello|
+-----+

scala> sql("alter table t rename to test")
res2: org.apache.spark.sql.DataFrame = []

scala> sql("select * from test").show()
+---+
|  a|
+---+
+---+

The file layout is like
$ tree test
test
├── gabage
└── t
    ├── _SUCCESS
    └── part-00000-856b0f10-08f1-42d6-9eb3-7719261f3d5e-c000.snappy.parquet

In Hive, if the new location exists, the renaming will fail even the location is empty.
We should have the same validation in Catalog, in case of unexpected bugs.
How was this patch tested?
New unit test.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/541/
Test PASSed.

Test build #92417 has started for PR 21655 at commit 1622d9c.

Test build #92417 has finished for PR 21655 at commit 1622d9c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92417/
Test PASSed.

Test build #92429 has started for PR 21655 at commit 7265f66.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/548/
Test PASSed.

Test build #92429 has finished for PR 21655 at commit 7265f66.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92429/
Test PASSed.

Test build #92591 has started for PR 21655 at commit 18418c9.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/656/
Test PASSed.

Test build #92591 has finished for PR 21655 at commit 18418c9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92591/
Test PASSed.

LGTM
Thanks! Merged to master.


README links to missing section?

Hi,
the current README.md links to a section called #integration-with-org, down in "The wrong version of my package was loaded". However, that section does not exist, it got removed during a merge (e1390a933b6f5a15079d6dec91eac97a17aad10c).
Unfortunately, I'm not a straight.el user, so I don't know whether that section is critical, but I believe that the link/mention of the old section should get removed to prevent confusion.
Hope that helps, and keep up the good work, the README.md was a fantastic tool for me to help others with their version mismatch!

Thanks for bringing this to our attention, I've updated the references in #774.


Support Progressive Web App (PWA)

Using Service Worker with / or instead of Web Worker (and possibly PWA Push Notifications with / or instead of Server Sent Events) would be required to be recognized by Chrome/Firefox/Safari as a "Progressive Web App".    PWA advantages include slightly more friendly for users as it provides app-like handling in-browser with splash screens, home screen icons,  and offline access.  Device integration for notifications may be the biggest advantage as users on a mobile device could allow alarm notifications even with the app not running in the foreground.   The disadvantage is it's somewhat experimental tech (complex and missing support on Safari and other browsers), and our customer base is primarily operators inside a control room on high powered desktops, whom have the software installed and linked manually by system administrators: ease of end-user install and smart phone and tablet friendliness would be nice, but isn't required.  Offline access is neat, but not required and operators are expected to be running the operator alarm system interface in the foreground.

Switched to smoothness weblib in v4.6.0 so this issue is now obsolete.


postgresqlPackages.timescaledb: 2.0.0 -> 2.0.1

Motivation for this change
https://github.com/timescale/timescaledb/releases/tag/2.0.1
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 111318 run on x86_64-darwin 1

2 packages failed to build and are new build failures:

postgresqlPackages.timescaledb: log https://termbin.com/105b
(postgresql11Packages.timescaledb): log was empty

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 111318 run on x86_64-darwin 1

2 packages failed to build and are new build failures:

postgresqlPackages.timescaledb: log https://termbin.com/105b
(postgresql11Packages.timescaledb): log was empty


add uri to the file

Will the uri be included in the value sent to the server?

yes, should we remove that?

it's not necessary in Arena... keep it in mobile if you need it but remove when you upload the records


lr()'s size can't consistently be applied to enclosed mid()

Description
$
  lr({ A mid(|) integral }) quad
  lr(size: #1em, { A mid(|) integral }) quad
  lr(size: #(1em+20%), { A mid(|) integral }) "wrong" \
  lr(] A mid(|) integral ]) quad
  lr(size: #1em, ] A mid(|) integral ]) quad
  lr(size: #(1em+20%), ] A mid(|) integral ]) "ok" \
  lr(( A mid(|) integral ]) quad
  lr(size: #1em, ( A mid(|) integral ]) quad
  lr(size: #(1em+20%), ( A mid(|) integral ]) "wrong"
$

Reproduction URL
No response
Operating system
No response
Typst version

[x] I am using the latest version of Typst

It is not that the MidElem element does not respect the enclosing LrElem's height. In fact, the MidElem is scaled up using the same height value that was used to scale up the LrElem's delimiters, and the computation of this height value did take the size argument into account:
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L56-L80

The root issue is actually that there are two levels of LrElem in lr({ A mid(|) integral }) and lr(size: #1em, { A mid(|) integral }), respectively.
The outer LrElem is formed by the explicit lr() function call, and the inner LrElem is implicitly formed by the {...} delimiter pair. When the inner LrElem (which holds the MidElem) is being laid out, the outer LrElem's size argument has no effect.
Also with this explanation, we can naturally understand

$ lr(size: #1em, ] A mid(|) integral ]) $ is okay because there's only one LrElem -- the one formed by the explicit lr() function, since the inner ] ... ] isn't recognized as a delimiter pair that should form an implicit LrElem.
$ lr(size: #1em, ( A mid(|) integral ]) $ is not okay because there are two levels of LrElem: the outer one is formed by the explicit lr() function, and the inner one is formed implicitly by the ( ... ] delimiter pair.

The same explanation also relates to https://github.com/typst/typst/issues/2979.

One may ask, "but this if-statement below should ensure the inner LrElem's body will be pulled out and treated as the outer LrElem's body":
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L42-L46
Yet, I can confirm with logging that if let Some(elem) = body.to::<LrElem>() was not triggered at all when rendering
$
lr({ A mid(|) integral }) \
lr(size: #auto, { A mid(|) integral }) \
lr(size: #1em, { A mid(|) integral })
$

It is not that the MidElem element does not respect the enclosing LrElem's height. In fact, the MidElem is scaled up using the same height value that was used to scale up the LrElem's delimiters, and the computation of this height value did take the size argument into account:
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L56-L80

The root issue is actually that there are two levels of LrElem in lr({ A mid(|) integral }) and lr(size: #1em, { A mid(|) integral }), respectively.
The outer LrElem is formed by the explicit lr() function call, and the inner LrElem is implicitly formed by the {...} delimiter pair. When the inner LrElem (which holds the MidElem) is being laid out, the outer LrElem's size argument has no effect.
Also with this explanation, we can naturally understand

$ lr(size: #1em, ] A mid(|) integral ]) $ is okay because there's only one LrElem -- the one formed by the explicit lr() function, since the inner ] ... ] isn't recognized as a delimiter pair that should form an implicit LrElem.
$ lr(size: #1em, ( A mid(|) integral ]) $ is not okay because there are two levels of LrElem: the outer one is formed by the explicit lr() function, and the inner one is formed implicitly by the ( ... ] delimiter pair.

The same explanation also relates to https://github.com/typst/typst/issues/2979.

One may ask, "but this if-statement below should ensure the inner LrElem's body will be pulled out and treated as the outer LrElem's body":
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L42-L46
Yet, I can confirm with logging that if let Some(elem) = body.to::<LrElem>() was not triggered at all when rendering
$
lr({ A mid(|) integral }) \
lr(size: #auto, { A mid(|) integral }) \
lr(size: #1em, { A mid(|) integral })
$

Meaning body.to::<LrElem>() is false. In fact, printing body.elem() yields Element(sequence).

It is not that the MidElem element does not respect the enclosing LrElem's height. In fact, the MidElem is scaled up using the same height value that was used to scale up the LrElem's delimiters, and the computation of this height value did take the size argument into account:
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L56-L80

The root issue is actually that there are two levels of LrElem in lr({ A mid(|) integral }) and lr(size: #1em, { A mid(|) integral }), respectively.
The outer LrElem is formed by the explicit lr() function call, and the inner LrElem is implicitly formed by the {...} delimiter pair. When the inner LrElem (which holds the MidElem) is being laid out, the outer LrElem's size argument has no effect.
Also with this explanation, we can naturally understand

$ lr(size: #1em, ] A mid(|) integral ]) $ is okay because there's only one LrElem -- the one formed by the explicit lr() function, since the inner ] ... ] isn't recognized as a delimiter pair that should form an implicit LrElem.
$ lr(size: #1em, ( A mid(|) integral ]) $ is not okay because there are two levels of LrElem: the outer one is formed by the explicit lr() function, and the inner one is formed implicitly by the ( ... ] delimiter pair.

The same explanation also relates to https://github.com/typst/typst/issues/2979.

One may ask, "but this if-statement below should ensure the inner LrElem's body will be pulled out and treated as the outer LrElem's body":
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L42-L46
Yet, I can confirm with logging that if let Some(elem) = body.to::<LrElem>() was not triggered at all when rendering
$
lr({ A mid(|) integral }) \
lr(size: #auto, { A mid(|) integral }) \
lr(size: #1em, { A mid(|) integral })
$

...meaning body.to::<LrElem>() always returns None; in fact, printing body.elem() yields Element(sequence).

We might have to disable inserting automatic lrs to solve this?

IIUC, We will have to disable inserting lrs automatically to solve this?

Do you mean lr({..}), lr((...]) should only result in one LrElem? Yeah.
I think it makes sense for the explicit lr() call to "absorb" the inner LrElem that is implicit [1] and touching-on-both-ends [2].
[1] counter example: lr(lr(...))
[2] counter examples: lr(... {...}), lr((...) ...)) e.g. lr((sum_(i=0)^oo F_i(x)) |)_0^1

btw, while an optional size argument for MidElem might be a useful feature, I don't think it's an ideal fix to this issue: it's really just a coverup of a deeper problem imo.

Yet, I can confirm with logging that if let Some(elem) = body.to::() was not triggered at all when rendering
$
lr({ A mid(|) integral })
lr(size: #auto, { A mid(|) integral })
lr(size: #1em, { A mid(|) integral })
$
...meaning body.to::() always returns None; in fact, printing body.elem() yields Element(sequence)

I'm confused about the intention of https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L42-L46
What kind of typ code input will trigger this code path? If it's not triggered in any circumstance, maybe we should delete it? Maybe it not being triggered implies there's a bug in how math layout works?

Alternatively, do nothing, for it is actually working as intended. There's no promise broken.
After all, the first principle: Typst did promise that matching delimiters will automatically form an LR. Therefore, if one wants to, say, render a math set then they should just write {...} instead of wrapping it in an explicit lr() call like lr({...}), since the latter results in two levels of LR, as explained above, and the { and } braces will be stretched twice: once by the inner LR and once by the outer LR. Further, if one wants to use the size argument to adjust the height to say 1.2em, then they should write lr(size: #1.2em, \{...\}), where the backslashes disable automatic matching so this expression only results in one LR and the braces are stretched only once, and this size argument will take effect when stretching mid in the body.
I feel attempts to "improve" (like the aforementioned idea of letting the outer LR "absorb" the inner one on certain combination of conditions) will likely further complicate the matter, creating cognitive load for both future code readers as well as end users. Just stick to the first principle and all makes sense.

Alternatively, do nothing, for it is actually working as intended. There's no promise broken.
After all, the first principle: Typst did promise that matching delimiters will automatically form an LR. Therefore, if one wants to, say, render a math set then they should just write {...} instead of wrapping it in an explicit lr() call like lr({...}), since the latter results in two levels of LR, as explained above, and the { and } braces will be stretched twice: once by the inner, automatic LR and once by the outer, forced LR. Further, if one wants to use the size argument to adjust the height to say 1.2em, then they should write lr(size: #1.2em, \{...\}), where the backslashes disable automatic matching so this expression only results in one LR and the braces are stretched only once, and this size argument will take effect when stretching mid in the body.
I feel attempts to "improve" (like the aforementioned idea of letting the outer LR "absorb" the inner one on certain combination of conditions) will likely further complicate the matter, creating cognitive load for both future code readers as well as end users. Just stick to the first principle and all makes sense.

Alternatively, do nothing, for it is actually working as intended. There's no promise broken.
After all, the first principle: Typst did promise that matching delimiters will automatically form an LR. Therefore,

If one wants to, say, render a math set then they should just write {...} instead of wrapping it in an explicit lr() call like lr({...}), since the latter results in two levels of LR, as explained above, and the { and } braces will be stretched twice: once by the inner, automatic LR and once by the outer, forced LR.
Further, if one wants to use the size argument to adjust the height to say 1.2em, then they should write lr(size: #1.2em, \{...\}), where the backslashes disable automatic matching so this expression only results in one LR and the braces are stretched only once, and this size argument will take effect when stretching mid in the body.

I feel attempts to "improve" (like the aforementioned idea of letting the outer LR "absorb" the inner one on certain combination of conditions) will likely further complicate the matter, creating cognitive load for both future code readers as well as end users.
Just stick to the first principle and all makes sense, though we might want to add an explanation in the doc reminding users of the difference between {..} vs lr({..}).

The culprit for this is actually here I think
https://github.com/typst/typst/blob/ca1f749c087bc19f6fbcebcd3ee34307959a95d5/crates/typst/src/math/lr.rs#L21-L33
This causes the inner LrElem to be wrapped inside a Sequence, which is the reason this code isn't working
https://github.com/typst/typst/blob/37249c20f793689b523cbb379f30b37466ca51b9/crates/typst/src/math/lr.rs#L42-L46


feat(systemd): Add support for zram-generator & {system,user}.conf.d

I also cleaned a code a little bit, which would fit into future code guidelines.

Updated

I'm thinking on investigating other systemd configuration entries too, such as coredump.conf.d & others, so I can include them all & explain what they do (can't explain in detail though, as I'm not expert on systemd. Even current documentation needs some check for difference between system.conf.d & user.conf.d, as I think that I'm not 100% correct there).
So I mark this as PR as draft.

I will close this, as it requires a lot of investigation & it can be very prone to change over time.


Move s3Archiver and Downloads to use s3Client v3

To resolve the error with file uploads, a move to the v3 of the AWS S3 SDK was made. This ticket is being made to track our eventual move of the s3Archiver and Downloads to v3
Acceptance Criteria:

[x] s3Archive.ts uses v3
[x] s3download.ts uses v3

downloads work!


New Related Persons Modal should mark required fields

🚀 Feature Proposal
The related person field and relationship type field should be marked with a * to indicate that it is required.
Motivation
Better use experience.

I would love to tackle this issue, along with Related Persons modal should provide better error feedback #1925


Delete Saga

Is any way to delete a saga in case in a step I want to stop the complete saga?

Hi @andretorres00123 !
Currently there's no set way to do what you mention. What's your use case? What do you want to do with the unfinished steps?
One option that comes to mind is:
Say for example that one of your steps is critical and if that fails all other steps should fail too. Then the recommended approach would be to do something like this:
const step1 = await saga.addStep(...)
const dependentStepPromises = workersArray.map(worker => {
  return saga.addStep(worker, [step1.id]);
}
await Promise.all(dependentStepPromises)

That way if step1 fails, all other steps won't be executed and the saga will be marked as failed.


Doc fixes and SPI block mode support

Various smaller fixes for documentation
Added support for SPI blockmode
Tested HW CS functionality

bors r+

bors r+


Support for Azure Open AI

Hi there,
I'm attempting to swap over to Azure Open AI and have come up against two problems.

the example here seems incomplete. It appears we have to provide the BaseAddress and AzureApiVersion. Is this correct?

A bigger issue seems to be how you are handling AuthenticationInfo

public AuthenticationInfo(string apiKey)
        {
            if (string.IsNullOrWhiteSpace(apiKey)) throw new ArgumentNullException(nameof(apiKey));

            if (!apiKey.Contains("sk-"))
            {
                throw new ArgumentException($"{apiKey} parameter must start with 'sk-'");
            }

            ApiKey = apiKey;
        }

As far as I'm aware Azure does not prefix their API keys with sk-. Without adding the "sk-" I'm getting argument exception and if I add "sk-" to my Azure key I'm getting a 404. Are you able to provide some guidance.
Cheers
-Rob

Hello,
Looks like the protocol changed in the last months as always. I will give it a look.

Hi there,
I'm attempting to swap over to Azure Open AI and have come up against two problems.

the example here seems incomplete. It appears we have to provide the BaseAddress and AzureApiVersion. Is this correct?
A bigger issue seems to be how you are handling AuthenticationInfo

public AuthenticationInfo(string apiKey)
        {
            if (string.IsNullOrWhiteSpace(apiKey)) throw new ArgumentNullException(nameof(apiKey));

            if (!apiKey.Contains("sk-"))
            {
                throw new ArgumentException($"{apiKey} parameter must start with 'sk-'");
            }

            ApiKey = apiKey;
        }

As far as I'm aware Azure does not prefix their API keys with sk-. Without adding the "sk-" I'm getting argument exception and if I add "sk-" to my Azure key I'm getting a 404. Are you able to provide some guidance.
Cheers -Rob

Please have a look to the latest release


fix(shop): fixed shop | undefined

:tada: This PR is included in version 1.14.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Is there a way to import mesh files?

A similar package I made called Grassmann.jl allows mesh importing with Grassmann.initmesh(::GeometryBasics.Mesh) although this feature is not yet officially documented, I plan to add some documentation regarding that.


Add support for command arguments

This adds basic support for argument parsing to commands. A simple example that now would have this is the help command.

Added the remaining rules for parsing @eberta, so this is ready for review now.


Back button for fungible token screen doesn't work like native #2765

Fixes #2765

Haven’t test yet, but does this actually make pan/swipe to go back as well as tap and hold the back button work?

Haven’t test yet, but does this actually make pan/swipe to go back as well as tap and hold the back button work?

oh, you right, its not, but as i know it disabled for whole application. do i need to enable it back? it could cause the new issues in the app

Ah. Nah. Just keep it. Was hoping the fix wasn’t necessary anymore. But when you have the time and inclination, you can help look into it again. No rush. Just not natural to not be able to swipe back :)

Closing for now.


Cannot interface BME280 and nRF52382 (SPI)

I have posted the question on BME160's Github, just paste it here for more visibility and because this is the BME280_driver github
Hi @BoschSensortec @XaviLC,
Your comments regarding configuration of the sensor have been very helpful, however I still cannot get the BME280 to work with the nRF52832 (I am using the RAK8211-NB board from RAK wireless).
After running rslt = bme280_init(&dev); , rslt is empty, and, in the function bme280_get_regs(), I get rslt = BME280_E_COMM_FAIL when trying to read BME280_CHIP_ID_ADDR.
Could you share your complete .c file with the spi instance and sensor initialization/read code?
I share my code below and hope you can see what I am missing.
#include "nrf_drv_spi.h"
#include "app_util_platform.h"
#include "nrf_gpio.h"
#include "nrf_delay.h"
#include "boards.h"
#include "app_error.h"
#include <string.h>
#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"
#include "bme280.h"

#define SPI_INSTANCE  0 /**< SPI instance index. */
#define SPI_SS_PIN 2
#define SPI_MISO_PIN 3
#define SPI_MOSI_PIN 5
#define SPI_SCK_PIN 4

static const nrf_drv_spi_t spi = NRF_DRV_SPI_INSTANCE(SPI_INSTANCE);

int8_t spi1_read_transfer(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t length)
{
	ret_code_t ret;

        nrf_gpio_pin_clear(SPI_SS_PIN); /* To activate the sensor on the bus, i.e., set the chip/slave select low */

	ret = nrf_drv_spi_transfer(&spi, &reg_addr, 1, NULL, 0);
	if(ret == NRF_SUCCESS)
		ret = nrf_drv_spi_transfer(&spi, NULL, 0, reg_data, length);

	nrf_gpio_pin_set(SPI_SS_PIN); /* To activate the sensor on the bus, i.e., set the chip/slave select high */

	return (int8_t)ret;
}

int8_t spi1_write_transfer(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t length)
{
	ret_code_t ret;

	nrf_gpio_pin_clear(SPI_SS_PIN); /* To activate the sensor on the bus, i.e., set the chip/slave select low */

	ret = nrf_drv_spi_transfer(&spi, &reg_addr, 1, NULL, 0);
	if(ret == NRF_SUCCESS)
		ret = nrf_drv_spi_transfer(&spi, reg_data, length, NULL, 0);

	nrf_gpio_pin_set(SPI_SS_PIN); /* To activate the sensor on the bus, i.e., set the chip/slave select high */

	return (int8_t)ret;
}

void user_delay_ms(uint32_t period)
{
    /*
     * Return control or wait,
     * for a period amount of milliseconds
     */
     nrf_delay_ms(period);
}

int8_t stream_sensor_data_forced_mode(struct bme280_dev *dev)
{
    int8_t rslt;
    uint8_t settings_sel;
    struct bme280_data comp_data;

    /* Recommended mode of operation: Indoor navigation */
    dev->settings.osr_h = BME280_OVERSAMPLING_1X;
    dev->settings.osr_p = BME280_OVERSAMPLING_16X;
    dev->settings.osr_t = BME280_OVERSAMPLING_2X;
    dev->settings.filter = BME280_FILTER_COEFF_16;

    settings_sel = BME280_OSR_PRESS_SEL | BME280_OSR_TEMP_SEL | BME280_OSR_HUM_SEL | BME280_FILTER_SEL;

    rslt = bme280_set_sensor_settings(settings_sel, dev);

    NRF_LOG_INFO("Temperature, Pressure, Humidity\r\n");
    /* Continuously stream sensor data */
    while (1) {
        rslt = bme280_set_sensor_mode(BME280_FORCED_MODE, dev);
        /* Wait for the measurement to complete and print data @25Hz */
        dev->delay_ms(40);
        rslt = bme280_get_sensor_data(BME280_ALL, &comp_data, dev);
        print_sensor_data(&comp_data);
    }
    return rslt;
}

void print_sensor_data(struct bme280_data *comp_data)
{
#ifdef BME280_FLOAT_ENABLE
        printf("%0.2f, %0.2f, %0.2f\r\n",comp_data->temperature, comp_data->pressure, comp_data->humidity);
#else
        NRF_LOG_INFO("%ld, %ld, %ld\r\n",comp_data->temperature, comp_data->pressure, comp_data->humidity);
#endif
}

/* End own function declarations and definitions */

int main(void)
{
    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    //spi_config.ss_pin   = SPI_SS_PIN;
    spi_config.ss_pin   = NRF_DRV_SPI_PIN_NOT_USED; /* Initialize p_spi_instance without an ss_pin. ss_pin = NRF_DRV_SPI_PIN_NOT_USED*/
    spi_config.miso_pin = SPI_MISO_PIN;
    spi_config.mosi_pin = SPI_MOSI_PIN;
    spi_config.sck_pin  = SPI_SCK_PIN;
    //APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL)); //Initialize in non blocking mode
    APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, NULL, NULL)); // Initialize in blocking mode

    NRF_LOG_INFO("SPI example started.");
    /* End example code */

    /* Own code */
    //APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, NULL, NULL)); // Initialize in blocking mode
    struct bme280_dev dev;
    int8_t rslt = BME280_OK;

    /* Sensor_0 interface over SPI with native chip select line */
    dev.dev_id = 0;
    dev.intf = BME280_SPI_INTF;
    dev.read = spi1_read_transfer;
    dev.write = spi1_write_transfer;
    dev.delay_ms = user_delay_ms;

    rslt = bme280_init(&dev);
    stream_sensor_data_forced_mode(&dev);
}

BME280 uses automatic protocol detection, based on the status of the CSB pin, as described in paragraph 6.1.
Try forcing the part to be in SPI mode before trying to read Chip ID by pulling low the CSB line (even without communication) for at least 40ns. (t_setup + t_hold)
Alternatively, if it is easier to program, simply try to write any value to address 0xD0 (Chip ID) and ignore the error message if the transaction fails. Since this register it read-only, the part will ignore the write command.

What I means by that, is to pull it low, then back high so that the part is already in SPI mode before the real SPI transaction.
An initial dummy transaction could achieve that.

@ma-harvey  Thanks for your quick replies.


[Bug]: Push notification iOS simulator

Component/Nuget
Push - Native (Shiny.Push)
What operating system(s) are effected?

[X] iOS (13+ supported)
[ ] Mac Catalyst
[ ] Android (8+ supported)

Version(s) of Operation Systems
Hi, starting with xcode 14 iOS simulators now support push notifications -
https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes#Simulator:~:text=Simulator now supports,these tokens. (60974170)
Looking at the code it always returns 'NotSupported' if its a simulator - https://github.com/shinyorg/shiny/blob/1b4138d42835a71447cee7b4134c7b0ef25b2f21/src/Shiny.Push/Platforms/Apple/PushManager.cs#L95C9-L96C72
Hosting Model

[X] MAUI
[ ] Native/Classic Xamarin
[ ] Manual

Steps To Reproduce
I have a 'Mac mini (M1)' running a 'iPhone 15 Pro 17.5' simulator and getting NotSupported result from await push!.RequestAccess();
Expected Behavior
Behave like a normal device and let me setup notifications
Actual Behavior
NotSupported
Exception or Log output
No response
Code Sample
No response
Code of Conduct

[X] I have supplied a reproducible sample that is NOT FROM THE SHINY SAMPLES!
[X] I am a Sponsor OR I am using the LATEST stable/beta version from nuget (v3.0 stable - ALPHAS are not taking issues - Sponsors can still send v2 issues)
[X] I am Sponsor OR My GitHub account is 30+ days old
[X] I understand that if I am checking these boxes and I am not actually following what they are saying, I will be removed from this repository!

While the simulator may support it, .NET iOS doesn't always properly push through the entitlements for the simulator.  I don't want the support that comes with opening this up right now.


I would like to thank you for your interesting work. How to identify the causes of violence？ Thanks again for your interesting work.

please see https://github.com/JimLee1996/AVSS2019/tree/master/src/Demo

please see https://github.com/JimLee1996/AVSS2019/tree/master/src/Demo

Is it through this line of code?
def predict(self, x):
x = x.to(self.device)
# need N x C x T x H x W
if len(x.shape) < 5:
x = x.unsqueeze(0)
y = self.net(x)
    _, results = y.topk(1, 1, True)

    labels = ['normal' if x else 'violent' for x in results]

    return labels

Is it through this line of code?
def predict(self, x):
x = x.to(self.device)
# need N x C x T x H x W
if len(x.shape) < 5:
x = x.unsqueeze(0)
y = self.net(x)
    _, results = y.topk(1, 1, True)

    labels = ['normal' if x else 'violent' for x in results]

    return labels

Yep

Yep

Thank you for your reply. I read your paper. What are the methods used to distinguish violent behavior from normal behavior? Thank you again for your work

Thank you for your reply. I read your paper. What are the methods used to distinguish violent behavior from normal behavior? Thank you again for your work

We use deep learning methods to do this job.
3DCNNs are proved to be effective on learning spatio-temporal features.
Here we introduce DenseNet architecture to better learn the motion pattern of violent behavior.
The outputs of model are logits of classes (in this task, violence and non-violence)

We use deep learning methods to do this job.
3DCNNs are proved to be effective on learning spatio-temporal features.
Here we introduce DenseNet architecture to better learn the motion pattern of violent behavior.
The outputs of model are logits of classes (in this task, violence and non-violence)

Thank you for your reply,
After the video passes the DenseNet model, it will identify whether there is violence in the video.

Thank you for your reply,
After the video passes the DenseNet model, it will identify whether there is violence in the video.

Use softmax. Please refer to https://github.com/JimLee1996/AVSS2019/issues/2.

Use softmax. Please refer to https://github.com/JimLee1996/AVSS2019/issues/2.

Thank you for your reply

Thank you for your reply


chore(elastic-search): add prepare script for firebase installation

Firebase extensions will currently fail on installation as the lib files will be unavailable.
Adding the proposed prepare script will build the source at runtime and successfully install the extension.

@dackers86 Thanks! Are you able to sign the CLA? If not I can make this change in a new PR.

Thanks @JasonStoltz. CLA is now passing


Integrate Restcomm SDKs

It is required to integrate and test Web SDK, iOS SDK and Android SDK.
Docs: http://documentation.telestax.com/connect/sdks/index.html

An initialization of web client is now available for testing at
https://github.com/deklab/dektalk/tree/master/desktop

Android app is available at:
https://github.com/deklab/dektalk/tree/master/mobile/android
iOS app is available at:
https://github.com/deklab/dektalk/tree/master/mobile/ios
I close this issue.


FIX: WebsiteRedirectLocation header response

Compatibility fix with AWS S3.
The WebsiteRedirectLocation will not be included in the get object or head responses if it was not set when putting the object.
AWS S3 output:
{
    "AcceptRanges": "bytes",
    "ContentType": "binary/octet-stream",
    "LastModified": "Tue, 10 Apr 2018 05:42:07 GMT",
    "ContentLength": 0,
    "ETag": "\"d41d8cd98f00b204e9800998ecf8427e\"",
    "Metadata": {}
}

Cloudserver previous output:
{
    "LastModified": "Tue, 10 Apr 2018 05:46:03 GMT",
    "ContentLength": 0,
    "ETag": "\"d41d8cd98f00b204e9800998ecf8427e\"",
    "WebsiteRedirectLocation": "",
    "Metadata": {}
}

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

CONFLICT (content): Merge conflict in lib/utilities/collectResponseHeaders.js

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

PR has been updated. Reviewers, please be cautious.

@ironman-machine try

Hello @giacomoguiulfo
"try": Success: Try build successfully launched on 'http://ci.ironmann.io/gh/scality/Integration/21152' with the following env. args:
{
    "DEFAULT_BRANCH": "master",
    "SCALITY_INTEGRATION_BRANCH": "ultron/master",
    "REPO_NAME": "S3",
    "SCALITY_S3_BRANCH": "fix/S3C-1396/website-redirect-header-response"
}

:sunny: :+1: circleCI test succeeded!

PR has been updated. Reviewers, please be cautious.

Closing this in favor of #1363, which has bert-e.


tasks: support customised user model

Go through django.contrib.auth.get_user_model() instead of a direct model import.

@noirbee Thanks for the patch, good catch.
Could you please update the CHANGELOG file as well ?
Once updated, I will merge and cut a release soon.

Thanks, for the update.
I've approved the changes.
Is there anything left that you want to push ?

Thanks, no more changes from me !

Great, let's get it merged.


[GO] - Handle MapType AST Node

Handle Below Code:
package main

func main() {
	myMap := make(map[string]int)
}

Raised pull request: https://github.com/joernio/joern/pull/3647

Pull request merged, closing the issue.


Separate error message for when GitHub username is invalid

Currently, regardless of the error in node server, "No roast available." error is show on UX. When the input username is invalid, error message like "Invalid username, please try again with valid username" can be more helpful.

The no roast available error is because the OpenAI API limit has been exceeded. I will update it on Monday.

I meant to have a separate error message for this error path:


fix: issue with post condition in workflow execution delete

LGTM but it'd be interesting to add a unit test to cover this case since we didn't catch that issue with the existing tests.

The related issue is about the faling test


as I can create a module in zend2 for api google drive?

hi guys, I created a module to integrate google api v3 https://github.com/google/google-api-php-client/tree/v1-master with ZF2, which have not been successful, I uploaded has github module, to see if anyone can help me achieve the integration of the api.
github https://github.com/losorio35/module-api-google-zf2/tree/master/Apigoogle

It looks like you've included the code to this library directly into your module. You should use composer to pull the library in, as what you are doing is definitely not recommended:
composer require google/apiclient:^1.1

Follow the zf2 setup instructions for more information. Most likely, at some point you'll be adding require "vendor/autoload.php"; to your front controller (web/index.php)
So, just to be clear, there should be no "module to integrate google api v3" necessary. Just use composer.
Also, you've included your credentials in your repo (here and here). You will want to delete these credentials from the Cloud Console and make new ones, as they are now insecure.


Error when building

Sample utterance " {query}" in intent "GptQueryIntent" must include a carrier phrase. Sample intent utterances with phrase types cannot consist of only slots.

I'm having the same issue, and it's my first time with Alexa Developer Console. I found some knowledge base articles here that I'm currently reading:
https://developer.amazon.com/en-IN/blogs/alexa/alexa-skills-kit/2020/01/improving-nlu-accuracy-of-alexa-skills
https://developer.amazon.com/en-US/docs/alexa/custom-skills/best-practices-for-sample-utterances-and-custom-slot-type-values.html

I noticed that you can't just pass the 'variable' to the intention, so I put some auxiliary words that made sense in the question, like "ask {query}", "search {query}", "tell me {query}" and it worked.

this happens because when the type is AMAZON.SearchQuery the skill requires an activation word. The downside of this is that you always have to speak this activation word to continue dialoguing with chatGPT. I solved it by adding a space before the {query} getting " {query}". This was working when I wrote this tutorial, but apparently they put an error when you do it now.
I found a solution for this at https://stackoverflow.com/questions/49948118/alexa-catchall
All that needs to be done is to change the type of AMAZON.SearchQuery to AMAZON.Person
{
    "name": "GptQueryIntent",
    "slots": [
        {
            "name": "query",
            "type": "AMAZON.Person"
        }
    ],
    "samples": [
        "{query}"
    ]
}

I fixed this in the tutorial, let me know if it's working without needing an activation word

Good afternoon. Before it worked fine. Still the same problem in Alexa. Impossible to make this skill work now.
I'm sorry because before it was perfect


Remove atexit() and replace by using a library destructor if it is available

This is the first iteration just to check if I'm heading in right direction. It removes call to atexit(3) done on behalf of library. The call to OPENSSL_cleanup() got moved to library destructors in a same fashion like we do it for FIPS. On platforms/compilers where destructor is not available nothing happens. Application then should call OPENSSL_cleanup() explicitly. Documentation is not updated yet.

Checklist

[x] documentation is added or updated
[ ] tests are added or updated

There are plenty of platforms where destructors aren't supported. We can't just ignore these.

We can. The missing OPENSSL_cleanup() call does no real harm. We had a thorough discussions on this topic on previous OTC meetings and we did not find any reason why the missing OPENSSL_cleanup() call would be a problem apart from having clean output from some leak detectors such as valgrind (which BTW even shows that the memory is not completely lost as it is still reachable, so this is not a real memory leak).

OTC: is this the solution to the known problem or are we looking for something different.

The list of changes in the most recent update is as follows:
- fixed shlibloadtest failure on windows, this prompts to rename global variable no_cleanup to ossl_no_cleanup
- no-atexit build time option is marked as deprecated
- also added ultimate/default else branch which defines _fini() function with call to OPENSSL_cleanup()

OTC: is this the solution to the known problem or are we looking for something different?

@paulidale We have already discussed this quite thoroughly within OTC when you were away. And yeah, we came to conclusion that this is a solution.

PR got updated. It comes with update to:
- CHANGES.md
- doc/man3/OPENSSL_init_crypto.pod
- doc/man3/OSSL_trace_set_channel.pod
- crypto/init.c (addresses nits pointed out by @matt)
I did use find ./ -name "*.pod" |xargs grep atexit |cut -f 1 -d : |uniq to
discover references to atexit. I hope this is sufficient. Thanks for taking a
look.

I've just forced pushed changes to documentation. The code which calls OPENSSL_cleanup() is currently left as-is.

Shouldn't we also be reviewing the whole nodelete code as part of this effort? That only exists because of atexit

...and similarly the no-pinshared option

removed notions on static linking, I agree these are corner a fairly narrow case.

Also needs a rebase.

There is something wrong with the rebase you did.

There is something wrong with the rebase you did.

yeah, another poor git driving... Should be fixed now. Also this version makes windows tests happy. It also fixes the crash I've noticed on OpenBSD. the trick is to use atexit() from stdlib/libc whenever possible. Using OPENSSL_atexit() wrapper provided by libcrypto may confuse atexit/library destructor unwinding making libc to step to/call dead memory. I'll update issue with my notes tomorrow. It's beer time for me now.

I have issues with continuing to use atexit() which has been problematic and the reason for this PR. This will cause further breakages.

New version should fix build issues which I failed to spot on my test machines.

= Current state
Currently OPEMSSL_cleanup() gets invoked by libc via atexit handler which is set when library is initialized. Current openssl library arms atexit handler almost always. The handler is not armed (set) when basic initialization is performed (OPENSSL_INIT_BASE_ONLY). The side effect of base initialization is that exit handlers set by OPENSSL_atexit() won't fire on application exit. The reason is the exit handlers are executed by OPENSSL_cleanup() which itself is invoked by libc as atexit handler. However atexit handler is not set on base level initialization.
Unlike libcrypto the libssl library always arms ssl_library_stop() as its atexit handler during its initialization.
Build configuration script Configure currently supports no-atexit option. Using the options tells openssl library not to set atexit handler with OPENSSL_clenaup(). This effectively disables implicit call to OPENSSL_cleanup() (and ssl_library_stop()) at process exit.
= Change
The PR brings two changes:
- call to OPENSSL_cleanup() and ssl_library_stop() are moved from atexit to library destructor.
- OPENSSL_atexit() is a wrapper of native libc's atexit()
- no-atexit build configuration option is deprecated and turned to no-op
The library destructors are not available in statically linked libraries (and binaries). This means OPENSSL_cleanup() and ssl_library_stop() are not invoked at statically linked application (or static library version). This is the limitation we accept. The cleanup openssl does at process termination prevents false positive detection of memory leaks done by various tools. The runtime memory debuggers usually operate on dynamically linked binaries, so no impact is expected there. Not calling cleanup routines at process exit does no harm, because typical OS reclaims resources held by process anyway. Applications which absolutely rely on doing clean-up at exit are free to call OPENSSL_cleanup() explicitly.
= Testing
The exiting test shlibloadtest does not cover situation when application uses libcrypto as a 3rd-party dependency (for example application needs library libsecret.so which itself needs libcrypto.so). I created base64.so test which covers changes introduced in this PR. Refer to ReadMe. There is also variant for Windows The windows variant uses visual studio project. The windows test needs to be ported to cmake yet.  The answers we are looking for are as follows:
- is OPENSSL_cleanup() function always being called on application exit (dlclose() on library)?
- is atexit handler set by OPENSSL_atexit() always invoked when application exits?
The scenarios we are investigating are as follows:
- application which is linked statically (-static) with libcrypto
- application which links libcrypto implicitly (-lcrypto)
- application which links 3rd party library explicitly (via. dlopen()), the 3rd party library is statically linked with libcrypto
- application which links 3rd party library explicitly (via. dlopen()), the 3rd party library pulls libcrypto in via DT_NEEDED record found in elf-header
The testing revealed some issues in various libc implementations. Those will be discussed further down in detail. To better understand results presented here following paragraphs discuss test scenarios.
== Statically linked application
The test.static application is linked with libcrypto statically using option -static. We expect OPENSSL_cleanup() function gets called as atexit handler. The changes in this PR might break this behavior, because I'm not sure how library destructors behave in statically linked binaries.
== Implicitly linked dynamic application
The test.implicit application is linked with libcrylto using option -lcrypto. The build-time linker adds dependency to libcrypto into DT_NEEDD record in elfheader. The run-time linker then uses DT_NEEDED record to construct binary. We don't expect to see any differences in behavior here because library destructor should always get called.
== Explicitly linked application
Unlike existing shlibloadtest the test.explicit application pulls libcrypto as 3rd party dependency. test.explicit application uses dlopen() to load .so library. There are two versions of .so files loaded by tests:
- base64.so is dynamically (implicitly) linked with libcrypto. The runtime linker invoked via call to dlopen() uses DT_NEEDED found in base64.so alf-header to load libcrypto automatically (implicitly)
- base64-static.so is statically linked with libcrypto, the base64-static.so file carries the whole libcrypto (or portion which is needed to run code in base64 module)
The test.explicit application uses dlclose() to explicitly close base64*.so module opened by dlopen(). It's worth to use open/close on .so module to see how libc deals with atexit handlers. Fiddling with OPENSSL_atexit() brings three options for test.explicit to install atexit handler:
- noatexit, no atexit handler is installed
- mainAtExit, atexit handler is found in test.explicit object/module (where main() function is)
- base64AtExit, atexit handler is found in base64.so module.
The selection of atexit handler discovered some challenges for libc itself. The dlopen() also allows caller to specify RTLD_ flags. The test uses various flag combinations, but there is no visible impact detected by tests. Also LoadLibrary() on windows (dlopen() equivalent) provides no RTLD_ flags at all.
== libc implementations used for testing
Following OSes where used to run tests:
- glibc as found on debian-12 (Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux)
- FreeBSD libc as found on FreeBSD 13.2
- OpenBSD libc as found on OpenBSD 7.5
- MS libc visual studio 2022 installed on windows 10 (sorry don't know how to obtain more details on windows yet)
Results for MS libc might not be that reliable, because of too much human labor involved to build and run tests. I still have to figure out proper automation on windows.
== BaseLine results (openssl@master)
Table below provides test results for current openssl (3.3). Also note the test application is nice to libcrypto. It uses OPENSSL_atexit() on library which is initialized beyond OPENSSL_INIT_BASE_ONLY level. The base level does not warrant the atexit handler installed via OPENSSL_atexit() gets called.

test
glibc
FreeBSD libc
OpenBSD libc
MS libc

test.static(base64AtExit)
OK
OK
OK
OK

test.static(mainAtExit)
OK
OK
OK
OK

test.static(noatexit)
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()

test.implicit(base64AtExit)
OK
OK
OK
OK

test.implicit(mainAtExit)
OK
OK
OK
OK

test.implicit(noatexit)
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()

base64(base64AtExit)
crash in OPENSSLcleanup()
OK
OK
OK

base64(mainAtExit)
OK
OK
OK
OK

base64(noatexit)
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()

base64-static(base64AtExit)
OK
OK
OK
OK

base64-static(mainAtExit)
OK
OK
OK
OK

base64-static(noatexit)
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()
no OPENSSL_cleanup()

The call stack in crash  from test.explicit(base64AtExit) test on glibc looks as follows:
(gdb) set args -a base64AtExit -l ./base64.so -f 'lazy|local'
(gdb) run
Starting program: /home/sashan/work.openssl/ossl-scripts/base64.so/test.explicit -a base64AtExit -l ./base64.so -f 'lazy|local'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Hello World, base64 is linked implicitly

OPENSSL_cleanup

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fbf3b9 in ?? ()
(gdb) bt
#0  0x00007ffff7fbf3b9 in ?? ()
#1  0x00007ffff78542e7 in OPENSSL_cleanup () at crypto/init.c:385
#2  0x00007ffff7e1a55d in __run_exit_handlers (status=0, listp=0x7ffff7fae820 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:116
#3  0x00007ffff7e1a69a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:146
#4  0x00007ffff7e03251 in __libc_start_call_main (main=main@entry=0x555555555621 <main>, argc=argc@entry=7, argv=argv@entry=0x7fffffffe0c8) at ../sysdeps/nptl/libc_start_call_main.h:74
#5  0x00007ffff7e03305 in __libc_start_main_impl (main=0x555555555621 <main>, argc=7, argv=0x7fffffffe0c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe0b8) at ../csu/libc-start.c:360
#6  0x0000555555555161 in _start ()

I think the story behind the crash is as follows (I have not verified it yet by looking at glibc source code closely yet):
- we do dlopen(base64.so), to satisfy DT_NEEDED dependency the runtime linker loads libcrypto for us too. both modules are memory-mapped to test.explicit process
- test installs atexit handler base64AtExit() which provided by base64.so
- finally we call dlclose(base64.so), the .so module gets unmapped from memory. the pointer to base64AtExit() function held by libcrypto becomes dead
- as soon test.explicit application performs exit the OPENSSL_cleanup() gets invoked as atexit handler, the function attempts to execute dead memory
At least that's my understanding. I still have to find answer why other libcs are immune to the issue. They must keep base64.so module around, but the exact mechanism must be discovered yet. The easiest workaround for glibc is to use a base64-static.so variant.
== NewCode results (openssl@at-exit branch)
The test application is same. We just use openssl library which does not use atexit().

test
glibc
FreeBSD libc
OpenBSD libc
MS libc

test.static(base64AtExit)
OK
OK
OK
OK

test.static(mainAtExit)
OK
OK
OK
OK

test.static(noatexit)
OK
OK
OK
OK

test.implicit(base64AtExit)
OK
OK
no OPENSSL_cleanup()
OK

test.implicit(mainAtExit)
OK
OK
no OPENSSL_cleanup()
OK

test.implicit(noatexit)
OK
OK
no OPENSSL_cleanup()
OK

base64(base64AtExit)
crash in libc
OK
OK
OK

base64(mainAtExit)
OK
OK
OK
OK

base64(noatexit)
OK
OK
OK
OK

base64-static(base64AtExit)
OK
OK
OK
OK

base64-static(mainAtExit)
OK
OK
OK
OK

base64-static(noatexit)
OK
OK
OK
OK

Two observations here are fairly interesting. test.implicit results for OpenBSD libc are very surprising. The library destructor does not get called. At this point I have no idea where to start looking at. I suspect there might be glitch in runtime linker or tooling of some sort. It works flawlessly for explicit linking but fails for kind of simple case.
The other observation is glbc crash:
sashan@debian-12:~/work.openssl/ossl-scripts/base64.so$ gdb ./test.explicit
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test.explicit...
(gdb) set args -a base64AtExit -l ./base64.so -f 'lazy|local'
(gdb) run
Starting program: /home/sashan/work.openssl/ossl-scripts/base64.so/test.explicit -a base64AtExit -l ./base64.so -f 'lazy|local'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Hello World, base64 is linked implicitly

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fbf3b9 in ?? ()
(gdb) bt
#0  0x00007ffff7fbf3b9 in ?? ()
#1  0x00007ffff7e1a55d in __run_exit_handlers (status=0, listp=0x7ffff7fae820 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:116
#2  0x00007ffff7e1a69a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:146
#3  0x00007ffff7e03251 in __libc_start_call_main (main=main@entry=0x555555555621 <main>, argc=argc@entry=7, argv=argv@entry=0x7fffffffe088) at ../sysdeps/nptl/libc_start_call_main.h:74
#4  0x00007ffff7e03305 in __libc_start_main_impl (main=0x555555555621 <main>, argc=7, argv=0x7fffffffe088, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe078) at ../csu/libc-start.c:360
#5  0x0000555555555161 in _start ()
(gdb)

I think the story is the same as earlier. However this time the dead memory gets executed by glibc directly. The base64.so gets unmapped and atexit subsystem in glibc keeps stale pointer around. Mechanism is same, just victim is different.
== Additional details
While working on a final change I've discovered yet another glitch. The only immune libc was FreeBSD. The issue (crash on dead memory) was discovered by shlibloadtest. The stack/symptoms looked as follows:
(gdb) run
Starting program: /tmp/openssl/test/shlibloadtest -crypto_first ./libcrypto.so.3 ./libssl.so.3 atexit-fantoms.txt

Program received signal SIGSEGV, Segmentation fault.
0x00000019456cbf70 in ?? ()
(gdb) bt
#0  0x00000019456cbf70 in ?? ()
#1  0x000000197765a1c5 in _libc___cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:177
#2  0x0000001977656665 in _libc_exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:54
#3  0x0000001707466dd2 in _start ()

The code at that stage was in work-in-progress. The changes for libcrypto were done, the call to atexit() in libssl was yet to be discovered.  In this test  shlibloadtest program runs as follows:
1. dlopen(libcrypto)
2. dlopen(libssl)
3. SSL_CTX_new()
3.1 ossl_init_ssl_base()
3.1.1 OPENSSL_atexit(ssl_library_stop)
4. OPENSSL_atexit(atexit_handler)
5. dlclose(libssl)
6. dlclose(libcrypto)
The program crashed in libc right after completion of atexit_handler() (function armed by unit test). The libc keeps exit handlers in array. After finishing step 4 the array looks as follows:
(gdb) p p->fns[0]
$13 = {fn_ptr = 0x297d41f1bb0 <_cleanup>, fn_arg = 0x0, fn_dso = 0x0}
(gdb) p p->fns[1]
$14 = {fn_ptr = 0x297e74af8a0 <_dl_dtors>, fn_arg = 0x0, fn_dso = 0x0}
(gdb) p p->fns[2]
$15 = {fn_ptr = 0x2959be4fa80 <__fini>, fn_arg = 0x0, fn_dso = 0x0}
(gdb) p p->fns[3]
$16 = {fn_ptr = 0x297eb7f6f70 <ssl_library_stop>, fn_arg = 0x0, fn_dso = 0x297a6f867c0 <__dso_handle>}
(gdb) p p->fns[4]
$17 = {fn_ptr = 0x2959be4f860 <atexit_handler>, fn_arg = 0x0, fn_dso = 0x297a6f867c0 <__dso_handle>}
(gdb) p p->fns[5]
$18 = {fn_ptr = 0x0, fn_arg = 0x0, fn_dso = 0x0}

There are 5 handlers (0 - 4) in array. The execution order is 4->0. So as soon as main() function terminates we libc calls atexit_handler() as the first, ssl_library_stop() as the next one etc...
The fairly important bit in this mosaic is fn_dso which holds address of the module which has installed the handler. atexit_handler() (where atexit() function got called). In this particular case the call to atexit() comes from libssl (OPENSSL_atexit() is part of libssl). However the atexit() installs exit handler found in libssl. This detail come unnoticed by libc on OpenBSD. Once test program does dlclose() in step 5 the ssl_library_stop() function gets unmapped. OpenBSD libc keeps a stale pointer. What's wrong here is that the pointer belongs to fn_dso recorded in table entry along the pointer. But that fn_dso belongs to libcrypto. Therefore the test at line 164 here:
160	for (p = __atexit; p != NULL; p = p->next) {
161		for (n = p->ind; --n >= 0;) {
162			if (p->fns[n].fn_ptr == NULL)
163				continue;	/* already called */
164			if (dso != NULL && dso != p->fns[n].fn_dso)
165				continue;	/* wrong DSO */
166
167			/*
168			 * Mark handler as having been already called to avoid
169			 * dupes and loops, then call the appropriate function.
170			 */
171			fn = p->fns[n];

does not kick in and later libc attempts to jump to dead memory. The same shlibloadtest test was also failing for identical openssl version on MS libc. I was not able to figure out the details. To workaround the issue I've decided to put call to atexit() into libssl. This did help on OpenBSD as well as on MS Windows.
=Enough is Enough
I understand motivation to keep implicit (automatic) call to OPENSSL_cleanup() working. On the other hand after spending almost three weeks in this area I've found this hovercraft is full of eels. I would just drop that approach completely. If application feels it must do clean-up on its exit, then it should call OPENSSL_cleanup() explicitly. I hope the tests done here helps us better understand limits of automatic OPENSSL_cleanup(). After all it's nothing else than best effort.

I have issues with continuing to use atexit() which has been problematic and the reason for this PR. This will cause further breakages.

all calls to *atexit() are gone now. Except the atexit() found in crypto/s390xcap.c I feel the call to OPENSSL_s390x_cleanup() should happen in OPENSSL_cleanup()  However the limited testing I've done so far shows the call to OPENSSL_cleanup() is not always granted. My gut feeling says it should be OK, but I need to find out what's this s390xcap is about first before taking the move.

The change also introduces  ossl_atexit_enabled. we let linker to initialize it to 1. The ossl_atexit_enabled controls behavior of OPENSSL_atexit() now. If ossl_atexit_enabled is 0 then OPENSSL_atexit() returns 0 (error) without doing anything. If ossl_atexit_enabled is 1, then the function schedules exit handlers to be invoked by ossl_cleanup_notify() from library destructor.
ossl_atexit_enabled is set to 0 when libcrypto is initialized by OPENSSL_init_crypto() with the OPENSSL_INIT_NO_ATEXIT flag set.

I am not sure it is necessary to add ossl_atexit_enabled. IMO the ossl_no_cleanup variable you had there was already sufficient. BTW better name would be ossl_no_implicit_cleanup.

The CI is somehow flaky today but at least the check docs and macos failures are relevant.

Now the only remaining thing to solve are the crashing tests on MacOS builds.

New PR version should fix the evp_extra_test failure seen on FreeBSD. It might help MacOS too. Details follows.
(gdb) bt
#0  engine_cleanup_cb_free (item=0x8236965b0) at crypto/engine/eng_lib.c:171
#1  0x00000000005360b3 in OPENSSL_sk_pop_free (st=0x823725120, func=0x3e42a0 <engine_cleanup_cb_free>) at crypto/stack/stack.c:439
#2  0x00000000003e428d in sk_ENGINE_CLEANUP_ITEM_pop_free (sk=0x823725120, freefunc=0x3e42a0 <engine_cleanup_cb_free>) at crypto/engine/eng_local.h:48
#3  0x00000000003e4237 in engine_cleanup_int () at crypto/engine/eng_lib.c:178
#4  0x0000000000472557 in OPENSSL_cleanup () at crypto/init.c:399
#5  0x0000000000473209 in ossl_call_cleanup () at crypto/init.c:655
#6  0x000024f995531fe9 in objlist_call_fini (list=<optimized out>, root=root@entry=0x0, lockstate=lockstate@entry=0x8211a4868)
    at /usr/src/libexec/rtld-elf/rtld.c:3040
#7  0x000024f99552ae29 in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:3452
#8  0x00000008232f4ff1 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:240
#9  0x00000008232f5571 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:74
#10 0x000000000030de87 in _start (ap=<optimized out>, cleanup=<optimized out>) at /usr/src/lib/csu/amd64/crt1_c.c:75

exit handlers as we enter __cxa_finalize() (execution order is revers! 2 -> 0)
[ rtld_exit, rtld_nop_exit, cleanup_trace ]
OPENSSL_cleanup() is invoked from rtld_exit().
Before this change OPENSSL_cleanup() got armed by atexit(). In this case the
array would look somewhat like this:
[ rtld_exit, rtld_nop_exit, cleanup_trace, OPENSSL_cleanup() ]
The execution order matters here. because OPENSSL_cleanup() armed via atexit(3)
first to play. We must look at what happens at rtld_exit() more closely.
We use ktrace/kdump to do that.
export LD_UTRACE=1
#-d      Descendants; perform the operation for all current children
#-i      Inherit; pass the trace flags to all future children
ktrace -d -i make run_tests TESTS=test_evp_extra
kdump -f ktrace.out|grep RTLD |grep evp_extra_test|less

the part related to crash I could see looks as follows:
 59607 evp_extra_test USER  RTLD: fini 0x8267e285c for 0x821bc9008 (/usr/home/sashan/openssl.sashan/engines/dasync.so)
 59607 evp_extra_test USER  RTLD: fini 0x826c63af0 for 0x821bc9408 (../../util/../util/../libcrypto.so.3)
 59607 evp_extra_test USER  RTLD: fini 0x826ea9ee0 for 0x821bc9408 (../../util/../util/../libcrypto.so.3)
 59607 evp_extra_test USER  RTLD: fini 0x4731f0 for 0x821bad008 (/usr/home/sashan/openssl.sashan/test/evp_extra_test)

I don't know how we ended up having two instances of of libcrypto.so.3 library.
The evp_extra_test is statically linked statically with libtestutisl.
the libcrypto seems to appear in process when we execute line 38 in test/testutil/main.c
 37     if ((setup_res = setup_tests()) > 0) {
 38         ret = run_tests(argv[0]);
 39         cleanup_tests();

Anyway not important for now. What matters is the order of calls to fini() function
which happens rtld_exit(). We see the order is

dasync.so is unloaded
then we unload one of the libcrypto.so
then we unload the second libcrypto.so
finally we unload the evp_extra_test

itself. It looks like engine_cleanup_int() must be stepping to dead
memory left behind dasync.so engine. Avoiding calling to now-removed
engine in engine_cleanup_cb_free() seems to resolve issue on FreeBSD.

@Sashan This is a very interesting investigation! Good work! This looks like either a bug in dasync engine or the engine cleanup code. Just removing the callback does not seem right to me though. Let me look at it more closely.

OTC: Please see https://github.com/openssl/project/issues/633 for analysis of atexit issues on BSD  and MACOSX

The analysis of the situation in my earlier comment is not quite right. After
putting in more debug effort I'm seeing quite a different picture. The thing is the
test/evp_extra_test is special enough to exploit corner case in various
runtime linker implementations. All troubles come from fact the evp_extra_test
links with the static version of libcrypto. The evp_extra_test is explicitly linked
with dasync.so (dasync.so shared library is loaded later vai dlopen(3)).
The dasync.sp shared library depends on libcrypto.so via DT_NEEDED
elf-header field in dassync.so. We say libcrypto.so is linked implicitly
with dasync.so. The libcrypto.so gets loaded on behalf of call to
dlopen("dasync.so") done by evp_extra_test during execution of main() (et. al.).
This way evp_extra_test gets two instances of OPENSSL_cleanup() function which
both are invoked after the completion of main() function. The execution order
of those two OPENSSL_cleanup() functions is defined by runtime-liner. Three
runtime liners were tested, and the results are as follows:

glibc: OPENSSL_cleanup(evp_extra_test), OPENSSL_cleanup(libcrypto)
FreeBSD: OPENSSL_cleanup(libcrypto), OPENSSL_cleanup(evp_extra_test)
OpenBSD: OPENSSL_cleanup(libcrypto) (rt-linker on OpenBSD does not seem
to call libcary destructor if static library is used, I'm still investigating
details)

The FreeBSD scenario leads to a crash when OPENSSL_cleanup(evp_extra_test)
unloads dasync.so engine. The engine unload operation executes the function
ERR_unload_DASYNC_strings() which in turn calls ERR_unload_strings()
function. The function comes from libcrypto.so, which OPENSSL_cleanup() got
called by rt-linker already. There ERR_unload_strings() finds
err_string_lock to be NULL.
I see three possible ways around it:

remove atexit() without any replacement
add a check to avoid NULL pointer dereference
explicitly enable call to  atexit() at build time, option
is disabled by default.

Given the issue is understood now, it should be safe to go
with 2. Most applications link with libcrypto dynamically via DT_NEEDED
(implicitly). This is the fairly simple case for rt-linkers and I don't
expect differences in behavior. We should perhaps add a new test case
which will be dynamically linked with libcrypto and try to load
the same dasync.so engine. This is (as I believe) a more typical case.
The option 3 is in my opinion the worst one because it further complicates
the test matrix and moves the responsibility to enable/disable atexit to
OS vendors who shop OpenSSL.
Keep reading if you are interested in details. The only standard that defines
runtime liner behavior w.r.t. library constructors/destructors is
elf.pdf. Book III, chapter
Dynamic Linking, section Initialization and Termination Function 2.14.
This paragraph discusses the execution order of finalization functions
(destructors):
Similarly, shared objects may have termination functions, which are executed with the
atexit(BA_OS) mechanism after the base process begins its termination sequence. The order
in which the dynamic linker calls termination functions is the exact reverse order of their
corresponding initialization functions. If a shared object has a termination function, but no
initialization function, the termination function will execute in the order it would have as if the
shared object's initialization function was present. The dynamic linker ensures that it will not
execute any initialization or termination functions more than once.

This is sufficient to deal with typical scenarios such as:

all elf-objects are linked to the process implicitly (via DT_NEEDED)
if application *main() program)  uses dlopen(), then each
elf-object loaded by dlopen() is also closed by explicit call to dlclose(),
before main() exits.

However evp_extra_test binary puts the reverse-order idea to the test. If the runtime
linker constructs the process it resolves all DT_NEEDED dependencies (does
implicit) linking. Let's see how the linker sees evp_extra_test binary:
lifty$ readelf -d test/evp_extra_test |grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.27.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.99.0]

So before main() gets executed the linker executes initialization functions first.
No library in the list above declares its further dependency on additional elf-object
via DT_NEEDED. If there is such dependency then the linker will execute
initialization functions for those DT_NEEDED. Let's assume the execution
order is as follows:

<EMAIL_ADDRESS><EMAIL_ADDRESS>init@evp_extra_test
main()

If main() exits right away, then finalization functions are executed in the exact
opposite order. However, things are not that simple with evp_extra_test.
The main() function calls dlopen("dasync.so") to load the engine. From the linker
point of view the dasync.so elf-object looks as follows:
lifty$ readelf -d engines/dasync.so |grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.27.1]

As you can see dasyn.so further depends on libcrypto.so.3 and
libpthread.so.27.1.  At the time dlopen() is executed the dependency on
libpthread is satisfied already, the library has been linked to the process
before main() got entered. The process does not contain libcrypto elf module
yet, thus it must be loaded before dasync.so. The execution of initialization
functions at dlopen() time is as follows:

init@libcrypto
init@dasync

The finalization functions at dlclose() will run reverse order. So far so
good. Unfortunately, we are not lucky with evp_extra_test. The call
to dlclose() happens outside of main(). I believe this is very
similar to glibc run-time linker was dealing with in issue here.
Keep in mind there are two instances of OPENSSL_cleanup() function
in evp_extra_test process after dasync.so gets loaded:

OPENSSL_cleanup@evp_extra_test
OPENSSL_cleanup@libcrypto

The runtime linker must choose an order to execute them. The FreeBSD liner sticks
to rigid interpretation of what's written in elf standard and performs
a reverse-order execution on finalization functions which is:

OPENSSL_cleanup@libcrypto
OPENSSL_cleanup@evp_extra_test

Unfortunately, call to<EMAIL_ADDRESS>Thedasync.socallsERR_unload_strings()which has been cleaned up already by an earlier call toOPENSSL_cleanup@libcrypto`.
With glibc runtime linker the situation is quite different. The linker
seems to ?always? start with main elf-object (object where main() is found,
I still have to figure out the exact mechanism yet). So in the case of glibc
we execute OPENSSL_cleanup@evp_extra_test() as the first finalization
function. The function can then safely unload dasync.so engine, because
OPENSSL_cleanup@libcrypto has not been performed yet.

I'm closing the atexit() removal for now. we need a better plan for this. moving the call to OPENSSL_cleanup() from atexit() to library destructor invites yet another bag of problems with runtime linkers. Perhaps the best way to move forward with this is change the API such explicit library initialization and explicit library cleanup will be mandatory. However this can not be done in 3.x cycles.

closing PR as can not be implemented, plan does not work reliably with various runtime liners.


Karpenter not optimising instance size for multiple pods

Version
Karpenter Version: v0.16.3
Kubernetes Version: v1.22 (EKS)
I have a provisioner which allows the following instance types:
c6i.2xlarge (8 CPU, 16Gi Memory) - cost ~$0.71
c6i.8xlarge (32 CPU, 64Gi Memory) - cost ~$2.84 (4x)
And I provision hundreds of pods each requesting 4 CPU and 8Gi Memory.
Due to overheads, only a single pod will fit on a 2xlarge instances, but 7 pods will fit on an 8xlarge instance.
My expectation is that Karpenter realises this, and the cost per pod is $0.71 for 2xlarge or $0.41 for 8xlarge, so it should launch 8xlarge instances
Instead, it seems to examine each pod 1 at a time, and always picks the smallest available instance in which the pod fits.
See the attached logs showing it launching 1 node at a time for each pod

Is there any way to get Karpenter to optimise this? My understanding was that was how it should work from the FAQ https://karpenter.sh/v0.19.0/faq/#how-does-karpenter-dynamically-select-instance-types

Are you able to post the following info:

Provisioner Spec
Deployment Spec
More of the logs during the scale-up timespan

A few initial thoughts:

It could be that the pods are being created slowly and trigger an early launch of the instance. We batch pods based on a dynamic batching window that is configurable in the karpenter-global-settings configmap (docs).
Are there any scheduling constraints on the deployments that would be limiting their ability to pack on one node, like anti-affinities?
Have you looked at the actual allocatable capacity for those instance types? (docs)

I think from further looking into it the issue is to do with allocatable ephemeral storage
The instances request 10Gi of ephemeral storage and the launch template provisions the instances with 100Gi volumes. I confirmed that the nodes have ~100Gi of allocatable ephemeral storage after launch, however it seems Karpenter uses a set 18Gi value for every instance size and so only ever allocates 1 Pod per node
Is there a way to override what Karpenter thinks is allocatable for storage?

If you use the awsnodetemplate and set the block device mappings (like you are doing with launch templates), Karpenter will know what the storage allocatable is for the node.  https://karpenter.sh/v0.19.0/aws/provisioning/#block-device-mappings

That's definitely what I'm doing. I'm going to close this ticket until I have time to do some more investigation and figure out what's happening

I looked into it some more and the issue is that we're using a custom launch template which has BlockDeviceMappings, but Karpenter only looks at the mappings from the provisioner itself. And you can't set both launch template and block device mappings in the provisioner :/ so looks like we'll need to stop using our own launch template, or we need to patch Karpenter to fetch the mappings from the launch template if provided

we'll need to stop using our own launch template

Custom launch templates are a legacy feature that are very challenging to work with for a number of reasons. We highly recommend using AWSNodeTemplates instead. It's likely that launch templates will be deprecated at some point in the future.


Cannot search for available plugins on macOS Big Sur

🐛 Bug
If I use napari on Windows 10 I can search for available plugins but that's not the case when I install on macOS Big Sur. Is the filter menu missing for Mac?
Details:
napari: 0.4.10
Platform: macOS-11.6-x86_64-i386-64bit
System: MacOS 11.6
Python: 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:36:15) [Clang 11.1.0 ]
Qt: 5.15.2
PyQt5: 5.15.4
NumPy: 1.19.5
SciPy: 1.7.1
Dask: 2021.07.2
VisPy: 0.7.3

Pretty sure the Filter box at the top was added in 0.4.11—are you using the same version on both OS?

Yes, you are right upgrading to version 0.4.11 fixed it. Thanks