prometheus: Optionally remove service discovery.

I read this hilarious blog post:
https://wejick.wordpress.com/2022/01/29/can-i-have-a-smaller-prometheus/
We can have a smaller Prometheus too. This patch allows users to remove
service discovery for five public clouds (AWS, Azure, DigitalOcean, GCP,
and Linode) and also Kubernetes, simply by setting the corresponding
enable-flag to false. I have tested building with each flag as I added
it to the list. I also tested running with all six flags set to false,
and the resulting Prometheus can still handle my orthogonal
service-discovery configuration (files).
To meet Adam Savage's definition of science, I measured the size of the
prometheus and promtool binaries after adding each flag with
ls -h.

flag
prometheus
promtool

starting size
84M
74M

AWS
72M
61M

Azure
71M
61M

GCE
64M
53M

k8s
40M
53M

DO
39M
52M

Linode
38M
51M

I did not go as far as the blog post. If folks want, I'll make the rest
of the service discovery optional too.
I did not shrink the build closure, just the output closure; we still
pull all of the various vendored modules into the Nix store during
builds. I don't see how to do this in a neat or easy way.

Motivation for this change
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Thanks!


README example gives an error

Following you example on the README with:
<!-- markdownlint-disable MD033 -->

# An example

<section-start>

```python
%load_ext autoreload
%autoreload 1
%aimport example

# Normally you would just need to use the following:
# import example

a_number
print('Your number is {}'.format(a_number))

```
I see:

However when I run direct (jupyter notebook --NotebookApp.default_url=/scriptedforms/robin.md) I don't see the error:

OK I also don't see when I restarted the lab (jupyter lab):

I've noticed however that watchdog isn't working...

Is watchdog really required - could you not just reload the script every second?

I'll get to the bottom of why it's not working. I imagine it was because there was too many subdirectories. I can make watchdog run quite a bit leaner.

That "an error occurred within python" probably needs the following imrovement:
https://github.com/SimonBiggs/scriptedforms/issues/98


dotnet: investigate migrating to System.Text.Json

The System.Text.Json API is a high-throughput substitute for the JSON.net API that we are currently using, and is part of the .NET SDK 3.0 and up. This is supposed to have same or better performance and would reduce the external dependency surface.
Task is to investigate whether it could and should be used.

See: https://docs.microsoft.com/dotnet/standard/serialization/system-text-json-how-to

An addition to this may be https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-source-generation?pivots=dotnet-6-0 either at the jsii level or app level. In theory can make things more explicit as well as improving throughput.


adding chat api and embeddings

Still can't merge due to conflicts.

I can't determine what the problem is.  Tried the command line.  Pushed a branch and tried to check-out this PR with
gh pr checkout 58
got this
(base) scottberenzweig@desktop-mac morpheus % gh pr checkout 58
From https://github.com/domsteil/Morpheus
 * [new branch]      main       -> github-desktop-domsteil/main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
fatal: Not possible to fast-forward, aborting.
failed to run git: exit status 128
(base) scottberenzweig@desktop-mac morpheus %


Sugesstion To optionally remove report message onJoin

Describe the solution you'd like
I want an option to disable the chatclear, report messages und teamchat messages at the join of a momber of the serverteam.
The Option in the config.yml (players.onJoin) doesnt fix this.
Example
I think it doesnt need an example...

Okay, this is just possible my mistake:
I disabled it in the Bungeecord config but have to disable this in the bukkit config too.
:D
LG FREE2WIN


nit: animated icons on folder tabs on queue page can be mistaken for "loading" pacifiers - especially when the tab is empty

Removed in d23da37a826a53e48abf32bf543c8d36640bea10


vbBack not a valid ASP/VBScript constant

In the EscapeCharacters function, line 916 or so of the class file, you have this line:
result = replace(result, vbback, "\b")
vbback returns an error if Option Explicit is turned on.  It doesn't appear that "vbback" is a valid vbscript constant.  See http://www.powerasp.net/content/new/vbscript-constants.asp

Hi. Don't know what version your are using, but the master branch (3.7) has a private variable to specify that.
Can you check that version?

3.6.0

Ah, sorry. Should have checked issues resolved after the release... https://github.com/rcdmk/aspJSON/issues/53

Absolutely no problem.
Thanks.


Tab completion eats a line

I use zsh 5.3.1 with prezto current master. I traced a problem to this line. To reproduce the problem, have editor plugin enabled and choose a multiline prompt theme. Trigger tab completion. Normally it would show "..." to indicate it's completing, then it hits this line zle redisplay and it will eat a line upwards.  but not a selection among choices).
Commenting out this line solves this issue.

The problem reproduces when zle expand-or-complete generates a no matches found warning, but the cursor is one line above it, and somehow zle redisplay erases one line too many on the top

I traced it to a few lines in the upstream zsh changelog. Guess it has nothing to do with prezto.

@hotpxl I suffer from the exact same issue. Do you know if commenting out this line has any side-effect?
I also noticed that the only multiline prompt theme where it doesn't happen is pure. Maybe they do something differently.

I just found the side effect of commenting out the line. During completion (I entered "cd ." then pressed Tab) it does this:

Pressing Enter still goes to the dir correctly, it's just a display problem. Better than completion eating lines though.

I think I have found the issue.
Refering to this patch from zsh.
commit 564fb25e821bdd143d23c4e22bc98254b0f8dd59
Author: Barton E. Schaefer<EMAIL_ADDRESS>Date:   Thu Mar 3 13:03:40 2016 -0800

    38048: fix "zle redisplay" when called while a listing is below the prompt

diff --git a/ChangeLog b/ChangeLog
index 6b80b19f5..691f54c77 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
 2016-03-03  Barton E. Schaefer<EMAIL_ADDRESS>
+       * 38048: Src/zle_refresh.c: fix "zle redisplay" when called while
+       a listing is below the prompt (e.g., from interrupt handler)
+
        * 38039: Src/options.c: POSIXy behavior for "set +o"

 2016-02-26  Peter Stephenson<EMAIL_ADDRESS>diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 7e4f32876..aca676a1c 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -2435,8 +2435,8 @@ redisplay(UNUSED(char **args))
     moveto(0, 0);
     zputc(&zr_cr);             /* extra care */
     tc_upcurs(lprompth - 1);
-    resetneeded = 1;
-    clearflag = 0;
+    resetneeded = !showinglist;
+    clearflag = showinglist;
     return 0;
 }

So why does this affect the completion prompt? It's the way module editor handles completion. In vanilla zsh, tab is bound to expand-or-complete. But in prezto, tab is bound to call expand-or-complete first and then redisplay. It's calling redisplay because otherwise the ... indicator won't disappear (like in @mdemierre case).
I guess redisplay cannot fully handle the case where there is already a line under current cursor. So it eats up a line from above instead. All in all, probably it's better to just call expand-or-complete and erase the indicator by some other means.

@mdemierre I think the reason why pure works is that its prompt is drawn by a zsh function instead of $PROMPT. It is printed to the screen so zle knows how many lines there are.

Thought I was going crazy with this.  Thanks for opening the bug and tracing it back to upstream.

My guess is that zle somehow hard-coded PROMPT to have only one line. So this bug occurs when you embed a newline in PROMPT. My workaround now is to print the prompt in precmd hook.

I could also fix this by printing the first line of the prompt in precmd, and only use PROMPT for the second line. It seems that PROMPT was in fact never intended to support multiple lines in zsh.
I guess all multiline prompts in the prezto distribution  should be patched.

I'd be surprised if the ZSH committers didn't fix this upstream.  There are tons of multi-line prompts out there.  It worked fine before (even if it was a fluke), so why willingly remove that functionality?
Unless I'm missing an announcement somewhere that says the prompt should be printed in precmd.

I'm experiencing the same issue. I'm glad someone has gotten to the bottom of this.

Can also confirm that printing the first line and making prompt a single line seems to fix the issue.

Could someone fix this for the steeef theme?

Experiencing this with vanilla zsh as soon as i set COMPLETION_WAITING_DOTS to true (this triggers 'zle redisplay' being called). See: https://github.com/robbyrussell/oh-my-zsh/issues/5767

I am also having issues here only with certain themes (such as ys).
ZSH: 5.1.1

After getting frustrated trying find a way to downgrade zsh to 5.2 using brew, this was the "solution" that I used. Don't close the session or open new ones until this finishes.
export HOMEBREW_NO_AUTO_UPDATE=1 && \
cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula && \
git checkout 5ba8893805b95b07688df90a8d0911e91709855f && \
brew remove zsh --force && \
brew install zsh && \
git checkout master && \
brew upgrade && \
brew switch zsh 5.2

Why switching back and forth? to force brew installing an older version and not switching/removing it after executing brew upgrade/cleanup.
I'd like to learn if there's an easier/cleaner way to do this.

I think I did something like:
brew uninstall zsh
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/e9d14f68b895eeb276806a956378293abe5e4bd8/Formula/zsh.rb
brew pin zsh

I'm not currently using prezto, but I use a version of the steeef theme and an old version of its editor script (modules/editor/init.zsh). I had this very same issue, and tracked it down to a line that reads:
  bindkey -M "$keymap" "$key_info[Control]I" \
    expand-or-complete-with-indicator

Without this re-binding, tab completion doesn't eat a line for me. I think you should try if commenting out this line fixes the issue for you.

Thanks for the hint. This helps with eating a line (basically due to removal of the zle redisplay inside expand-or-complete-with-indicator), but it breaks other stuff, for example showing ... while waiting for the tab complete.
So, as of today the only reliable way is to stay on zsh 5.2

Following up on this issue.
The latest ZSH master branch fixed this issue. I believe it is commit 34656ec2f00d6669cef56afdbffdd90639d7b465 that fixed this issue but I have not verified this. So wait for the next ZSH release 5.3.2 and everything will be fine!
Thanks for the discussion ppl!

Thanks for the follow up @hotpxl !

For people using zsh installed via homebrew, I confirm that the latest version resolves the issue.
You can install --head by running the following:
$ brew unlink zsh
$ brew install zsh --HEAD

Applying just the patch in question worked for me in Arch linux.
https://github.com/zsh-users/zsh/commit/34656ec2f00d6669cef56afdbffdd90639d7b465.patch

I'm still having this issue with zsh 5.4.2 + prezto + fzf.

And which prompt?

Any multi-line prompt that I try (bigfade, adam2, elite2 etc.).
fzf is also up-to-date.

Looks like we're tracking this in #1488. I'll try to investigate a bit more in depth later.

@fabioperez  Have you tried using my theme?

@hurricanehrndz What theme? Can you provide a link?

Still having this issue with zsh 5.4.2 and pretzo..

I have a temporary fix. You could try but I doubt it would work. Add the following after the initialization code to override the expand function.

function revert-expand-or-complete {
zle expand-or-complete
}
zle -N expand-or-complete-with-indicator revert-expand-or-complete

@hotpxl Thanks! That worked perfectly 😄

@hotpxl this worked for me! thanks!

@flinz, I had this issue with the mv command as well. (My zsh version: zsh 5.5.1 (x86_64-apple-darwin16.7.0))
Running which -a _mv produced the following for me:
_mv () {
        # undefined
        builtin autoload -XUz
}

Which seems strange given that mv should be supplied by zsh itself; the fact I get undefined here would imply that zsh's mv completion isn't getting loaded correctly on install (which others in this thread have already pointed out is the issue).
I ran across a similar thread from years ago for broken shell autocomplete in an issue opened on Oh My Zsh. One of the comments recommended running the following to fix the issue:
rm ~/.zcompdump*
exec zsh -l

AFAICT (and someone can correct me if I'm wrong), the first command there removes the zsh completion cache files; exec zsh -l will run zsh in place of the current shell (-l is used to tell the program that this is a login session)—it just seems to be a way to restart zsh.
Running which -a _mv now shows the correct function contents, and mv autocomplete works as expected once again.

Thx a lot for resolve the mv autocomplete problem.
I run rm -f ~/.zcompdump* and restart iTerm, everything is ok.
But if rm -f ~/.zcompdump*  then exec zsh -l and restart terminal, mv is still broken.
So weird.

@indiesquidge Thx a lot for resolve the mv autocomplete problem.
I run rm -f ~/.zcompdump* and restart iTerm, everything is ok.
But if rm -f ~/.zcompdump*  then exec zsh -l and restart terminal, mv is still broken.
So weird.

@indiesquidge @jerryshang
I too faced this problem.  rm -rf ~/.zcompdump* and restart iTerm worked where as
rm -f ~/.zcompdump* then exec zsh -l and restart terminal, mv is still broken ..

I've downgraded to zsh 5.2 which is supposed to not having this issue. But it's still the same for me.

This is not fixed yet.

I was able to work around it by commenting out the completing feature. I do not mind, this completing feature.
For example, if you are using paradox theme, change it as follows.
~/.zprezto/modules/prompt/functions/prompt_paradox_setup
# zstyle ':prezto:module:editor:info:completing' format '%B%F{red}...%f%b'

I'm also having this issue.
 ❯❯❯ zsh --version
zsh 5.7.1 (x86_64-apple-darwin18.2.0)

I installed zsh with brew. I also tried installing the zsh head (https://github.com/sorin-ionescu/prezto/issues/1245#issuecomment-299828536) but that didn't help. I'm using a custom multi-line prompt based on the default. I'm on 7c94154. @hotpxl suggestion from https://github.com/sorin-ionescu/prezto/issues/1245#issuecomment-375550386 worked for me by adding that code to my .zshrc

I also had this issue and changing the locale fixed it for me https://github.com/ohmyzsh/ohmyzsh/issues/7558#issuecomment-460812339


upgrade archaius,fix panic

Coverage decreased (-0.07%) to 64.67% when pulling b3082650f3799e65fa4e56c6277664a80fdfede0 on tianxiaoliang:master into b68613bd5d050fda75ca66b0d7036caf535f542f on go-chassis:master.


Scaling is in correct with the new larger art boards in latest update

Illustrator just came out with a minor update.  Minor update includes being able go much larger with the art boards.  We created an artboard that is 1000in x 1000in.  We draw a 500" x 500" square.  At 1/1 it provides a measurement of 50.00 in x 50.00 in

Your new document is created on a large canvas if one of the following settings is applied in the New Document dialog:

Artboard size larger than 227 inches (default canvas size) specified in Feet, Meters, Yards, or Feet and Inches.
High number of artboards that cannot be accommodated in the default canvas size.

The unit issue appears to be a known issue:

New units that are introduced for the large-sized canvas (feet, feet-inch, meter, yard) have representation issue for decimal numbers.

I can adjust the label output based on a multiplier, which is what I'm testing now. @JGonzo10 I would love if you want to help test, once I get this potential fix in place.
Source

Adam:
I would like to help and test it out for you.  I work at a sign shop, so we
work with a lot of larger graphics.  This new increased artboard is
wonderful for people in our industry.  Please let me know when you have a
version ready for me to test.
Thanks,
Joel Gonzales
<EMAIL_ADDRESS>On Wed, Jun 17, 2020 at 12:46 PM Adam DeHaven<EMAIL_ADDRESS>wrote:

Your new document is created on a large canvas if one of the following
settings is applied in the New Document dialog:

Artboard size larger than 227 inches (default canvas size) specified
in Feet, Meters, Yards, or Feet and Inches.
High number of artboards that cannot be accommodated in the default
canvas size.

The unit issue appears to be a known issue:
New units that are introduced for the large-sized canvas (feet, feet-inch,
meter, yard) have representation issue for decimal numbers.
I can adjust the label output based on a multiplier, which is what I'm
testing now. @JGonzo10 https://github.com/JGonzo10 I would love if you
want to help test, once I get this potential fix in place.
Source
https://helpx.adobe.com/illustrator/kb/large-sized-canvas-troubleshooting.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-645523323,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSFKTKUSAEOQ2TPDLWDRXD6PBANCNFSM4OAX6UXA
.

Looking through adobe's documentation, it doesn't appear that there is a way to quote detect unquote when a large canvas is being used other than simply by measuring the artboard.
The problem is, once the artboard exceeds 227 inches in either width or height, the values returned to the script appear to be 1/10 of their original value.
For example, if I create an artboard that is 400 inches wide by 300 inches tall (so Illustrator uses a "large canvas"), when I check the size of the artboard using app.activeDocument.width it returns 40 instead of 400.
@JGonzo10 since I can't seem to currently detect when a large canvas is being used, would another checkbox in the options suffice for now? When checked, it would multiply the measurement by 10, therefore giving the proper value.

I have since found the app.document.scaleFactor that gives me exactly what I needed. I have updated the script with the fix to version 2.0.1.
In addition, the free Adobe Exchange extension was approved by Adobe 🎉
The current version of the extension is 2.0.0, meaning it doesn't yet have the fix; however, it should be approved in the next 24 hours. @JGonzo10 if you're an Illustrator CC user, I'd recommend going ahead and downloading the extension and it should trigger an update via the Creative Cloud app in the next 24 hours.
Let me know if you have any issues, and thanks for submitting this bug!

This is great news.  Thank you for looking into this.  I will give this a
shot and download through Adobe Exchange.  I will continue to use this
myself along with my team and let you know of any issues.
Joel Gonzales
On Wed, Jun 17, 2020 at 6:47 PM Adam DeHaven<EMAIL_ADDRESS>wrote:

I have since found the app.document.scaleFactor that gives me exactly
what I needed. I have updated the script with the fix to version 2.0.1
https://github.com/adamdehaven/Specify/releases/tag/v2.0.1.
In addition, the free Adobe Exchange extension
https://exchange.adobe.com/creativecloud.details.104123.specify.html
was approved by Adobe 🎉
The current version of the extension is 2.0.0, meaning it doesn't yet have
the fix; however, it should be approved in the next 24 hours. @JGonzo10
https://github.com/JGonzo10 if you're an Illustrator CC user, I'd
recommend going ahead and downloading the extension and it should trigger
an update via the Creative Cloud app in the next 24 hours.
Let me know if you have any issues, and thanks for submitting this bug!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-645684153,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSCJVHCEGNI7VDCPYGDRXFI2BANCNFSM4OAX6UXA
.

--
Joel Gonzales
708-289-2305
<EMAIL_ADDRESS>

@JGonzo10 I needed to make an update to the scale factor. You'll want to download the latest version 2.0.2

Thank you for the heads up.  I also installed it using Exchange.  That
should update on its own within the next few days, correct?
Joel Gonzales
<EMAIL_ADDRESS>On Fri, Jun 19, 2020 at 8:57 AM Adam DeHaven<EMAIL_ADDRESS>wrote:

@JGonzo10 https://github.com/JGonzo10 I needed to make an update to the
scale factor. You'll want to download the latest version 2.0.2
https://github.com/adamdehaven/Specify/releases/tag/v2.0.2
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-646650985,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSBOJMDSC25OF7MGEZDRXNVD7ANCNFSM4OAX6UXA
.

@JGonzo10 Yes, the Exchange extension should auto-update (assuming you have the Creative Cloud app running), although it's still currently pending approval. Hopefully it will be approved in the next 24 hours.

Adam:
Just following up on the approval of the updates on exchange. Is it still
pending?
Thanks,
Joel Gonzales
<EMAIL_ADDRESS>On Fri, Jun 19, 2020 at 9:08 AM Adam DeHaven<EMAIL_ADDRESS>wrote:

@JGonzo10 https://github.com/JGonzo10 Yes, the Exchange extension
should auto-update (assuming you have the Creative Cloud app running),
although it's still currently pending approval. Hopefully it will be
approved in the next 24 hours.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-646656704,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSBD7IQZ63TPFAHJCVDRXNWPVANCNFSM4OAX6UXA
.

@JGonzo10 I believe they only do approvals Monday-Friday, so hopefully it will be approved today or tomorrow.

@JGonzo10 the new version of the extension is available now

Will you be updating the Adobe extension to be compatible with the new 2021
version of Illustrator?
What is interesting is the extension isn't compatible, but it says it is on
the website, but if you install the script, it seems to be working fine.
Thanks,
Joel Gonzales
708-289-2305
<EMAIL_ADDRESS>On Tue, Jun 23, 2020 at 4:50 AM Adam DeHaven<EMAIL_ADDRESS>wrote:

@JGonzo10 https://github.com/JGonzo10 the new version of the extension
is available now
https://exchange.adobe.com/creativecloud.details.104123.specify.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-648035480,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSEWUZHMWEZINVASWHTRYB3FRANCNFSM4OAX6UXA
.

@JGonzo10 I’m kinda new at Adobe Extensions, so I’m guessing I’ll just need to update the supported versions in Adobe Exchange. I’ll look into this in the coming days and push an update — thanks for the head’s up! 🙌

@JGonzo10 can you go into Illustrator Menu > Help > About Illustrator and let me know what version you show?

It shows version 25.0
Joel Gonzales
708-289-2305
<EMAIL_ADDRESS>On Wed, Oct 21, 2020 at 7:34 PM Adam DeHaven<EMAIL_ADDRESS>wrote:

@JGonzo10 https://github.com/JGonzo10 can you go into Illustrator Menu

Help > About Illustrator and let me know what version you show?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-714063685,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSDFLOYF4AX22N6FH43SL54YXANCNFSM4OAX6UXA
.

@JGonzo10 I just pushed an update here to the extension. I installed on my Windows computer and it runs with no issue.
You can run manually by downloading the newest version (3.0.0), or, hopefully Adobe will approve the new version in Exchange over the next couple days, then you can update through Creative Cloud.
I wouldn't mind seeing what is happening on your end (you've been so helpful in the past). If you wouldn't mind helping me take a look, email me at<EMAIL_ADDRESS>and maybe we can get together online later this week and take a closer look? I'd like to be able to solve this issue for everyone and prevent it from happening in the future.

Great! I just emailed you more info on your personal email address.
Joel Gonzales
708-289-2305
<EMAIL_ADDRESS>On Wed, Oct 21, 2020 at 8:07 PM Adam DeHaven<EMAIL_ADDRESS>wrote:

@JGonzo10 https://github.com/JGonzo10 I just pushed an update here to
the extension. I installed on my Windows computer and it runs with no issue.
You can run manually by downloading the newest version (3.0.0), or,
hopefully Adobe will approve the new version in Exchange over the next
couple days, then you can update through Creative Cloud.
I wouldn't mind seeing what is happening on your end (you've been so
helpful in the past). If you wouldn't mind helping me take a look, email me
at<EMAIL_ADDRESS>and maybe we can get together online later this week
and take a closer look? I'd like to be able to solve this issue for
everyone and prevent it from happening in the future.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamdehaven/Specify/issues/18#issuecomment-714110323,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKAXCSC3XM3BVLMX2KULKVLSL6AVXANCNFSM4OAX6UXA
.


Smooth histograms — which methods are best?

Following up on the discussion that took place during the kick-off meeting, an interesting point arose on the issue of which methods are best used to approximate a set of binned counts.
In the case where one has a neural network-based observable, one could apply the softmax function exp(nn / T) / sum(exp(nn / T)) ( T = temperature hyperparam) to the nn output, like one would do with a classification problem. This essentially puts every event in all bins, but weights each bin with the corresponding nn output (normalized to 1). The histogram is then the elementwise sum of the softmaxed output over all events.
An alternative to this is to take an approach using a kernel density estimate (kde), which is defined by instantiating a distribution (kernel) centered around each data point (e.g. standard normal distribution) and averaging their contributions. The smoothness of the resulting estimate is controlled with a 'bandwidth' hyperparameter, which scales the widths of the kernels. Once you choose a bandwidth, you can get 'counts' by integrating the pdf over a set of intervals (bins). One can equivalently use the cumulative density function.
Revisiting the case with the nn-based observable, one could then make the network output one value (regression net), and then define a kde over the set of outputs from a batch of events. The question is then: is there any clear advantage in expressivity or principle from using a kde, softmax, or other methods?
Another interesting question is where these approaches break down, e.g. using a kde in this way seems to be very senstitive to the bandwidth.
It's also worth noting that a kde may make more sense for general use as a candidate for smooth histogramming, but the case of the nn observable may be more nuanced.

[...] which is defined by instantiating a distribution (kernel) centered around each data point [...]

This is a very pragmatic question and shows my ignorance about these things: Have you already tried to investigate the scaling behavior of your current KDE implementation (resource-wise)? Do you (need to) keep all the kernels of all data points in memory at the same time for this to work? (Put differently: "what happens if you fill a KDE-style histogram with 10M events?")

@philippwindischhofer In practice, our code looks something like:
events = np.array([x_1, x_2, ..., x_n])
bins = np.linspace(a,b,num_steps)

edge_hi = bins[1:] # high edge for each bin
edge_lo = bins[:-1] # low edge for each bin

# get cumulative counts from ‘a’ up to each lo and hi bin edge
cdf_up = norm.cdf(edge_hi, loc = events, scale = bandwidth)
cdf_dn = norm.cdf(edge_lo, loc = events, scale = bandwidth)

# subtract to get counts in [lo,hi] for all bins
counts = cdf_up - cdf_dn

Since this is just essentially applying normcdf twice in a vectorised way, I imagine there wouldnt be any issues with scaling (but I havent tried!)

I think use of KDEs is fine, but using them with a normal Poisson-based maximum-likelihood function as implemented in pyhf is mathematically wrong. Maximum-likelihood fits only produce unbiased estimates of the value and its uncertainty when the data in each bin is Poisson-distributed, this is not the case when you convert data into KDEs. If you add a single new event, it will not only increase the value in a single bin, but also in neighboring bins. These additional correlations are not included in the fitted model.
Whether this is a problem in practice, I cannot say. The problem I describe may not affect the optimization significantly, but this point needs to be studied.

The kernel size could be reduced throughout analysis optimization to slowly approach the discrete bin case. For the final inference step after the optimization, the KDE can be replaced by a traditional histogram.

btw
events = np.array([x_1, x_2, ..., x_n])
bins = np.linspace(a,b,num_steps)

edge_hi = bins[1:] # high edge for each bin
edge_lo = bins[:-1] # low edge for each bin

# get cumulative counts from ‘a’ up to each lo and hi bin edge
cdf_up = norm.cdf(edge_hi, loc = events, scale = bandwidth)
cdf_dn = norm.cdf(edge_lo, loc = events, scale = bandwidth)

# subtract to get counts in [lo,hi] for all bins
counts = cdf_up - cdf_dn

can be more efficiently written as
events = np.array([x_1, x_2, ..., x_n])
bins = np.linspace(a,b,num_steps)

# get cumulative counts from ‘a’ up to each lo and hi bin edge
cdf = norm.cdf(bins, loc = events, scale = bandwidth)

# subtract to get counts in [lo,hi] for all bins
counts = np.diff(cdf)


Update Alibi Explainer Library to 0.4.0

/kind bug
Alibi has released 0.4.0 which has some breaking changes. Our current explainer wrapper has a setup.py which isn't fixed to 0.3.0:
https://github.com/kubeflow/kfserving/blob/3b282458eafe7fa423f7f4dcc34bd8f492c07884/python/alibiexplainer/setup.py#L36
We need to:

Fix Alibi explainer wrapper to 0.3.0 to keep existing functionality
Update and handle breaking changes for 0.4.0

Is this indeed a bug?

Is this a duplicate of #803

#803 is the PR for this issue


Set the pwsh invoke encoding as UTF-8

Set the pwsh invoke encoding as UTF-8 to avoid the zh-CN description present like this, seems issue from carapace completion

LGTM! Thanks.


chore(main): release 0.1.3

:robot: I have created a release beep boop
0.1.3 (2024-09-12)
Bug Fixes

test (8f7cd20)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.1.3
:sunflower:


Please Can I Join This Organisation? 🥺🙏"

Name:
Santa116
Why do you want to join this organization?
I want to join this organization to connect and learn from more developers
Pull request with your contribution
I add one star this repository
If you have not created a pull-request yet, please follow these instructions first.

Thank  you


[Loc] removed azdata.xlf as its no longer relevant

This PR fixes #

This is breaking the loc builds as it tries to find an extension that no longer exists.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 41.988%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
26500

Relevant Lines:
57181

💛  - Coveralls


Add extension to configure capture startup errors setting which defau…

…lts to true #552

:shipit:


Python 3.8, suitesparse 5.6, petsc 3.12

closes #97
closes #100
closes #98
closes #101
additionally:

remove extra numpy pinning (this was for the swig codegen, no longer used) closes #99

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

need to wait for builds from https://github.com/conda-forge/slepc4py-feedstock/pull/13 to propagate to CDN


ADD: Faster Signing

Pre-processing

Do keysign pre-processing whilst reviewing transaction data, have it ready
then keysign is faster

Will need to split keysign into two rounds prepareKeysign() and then finishKeysign()

I am going to close this one , as it is not possible for TSS to do this right now , TSS keysign is interactive , can't presign stuff


[bp/1.28] build(deps): bump distroless/base-nossl-debian12 from 312c829 to `8…

…a09e57` in /ci (#33956)
build(deps): bump distroless/base-nossl-debian12 in /ci
Bumps distroless/base-nossl-debian12 from 312c829 to 8a09e57.

updated-dependencies:

dependency-name: distroless/base-nossl-debian12 dependency-type: direct:production ...


[react18] Replace react-aria-menubutton with react-select

I tried to update react, and react-aria-menubutton complained it isn't compatible with latest react.
We should probably just swap it. Long story short react-aria-menubutton became less relevant in 2021 with the rise of downshift, which itself got overtaken by react-select last few years.

I think the path forward is first to use typescript, otherwise updating dependencies will cause things to break only in run time.
It shouldn't take long to upgrade to typescript.
After that we can swap packages.
I also think there's a need to use a component library instead of the proprietary components written here and the storybook here which I have no clue why we should maintain it.
But it might be just me...
Feel free to review my typescript PRs to streamline the migration to typescript.

that's a good idea. on that note react-select has proper typing too, but it's a good idea to use a component library

Migration is complete, lint is complete, feel free to push this forward.
The most well known component library for react that might be a good idea to use is MUI.
But I don't have a lot of experience with react to actually say something significant here.

@birkskyum I've created a PR to update react to version 18.
See here:

https://github.com/maplibre/maputnik/pull/890

Can you tell me what I should check in order to see the issue?


Ambient flake: : TestTraffic/dns

https://prow.istio.io/view/gs/istio-prow/pr-logs/pull/istio_istio/48249/integ-ambient_istio/1737899972755460096

If we look at https://gcsweb.istio.io/gcs/istio-prow/pr-logs/pull/istio_istio/48301/integ-ambient_istio/1742556718845399040/artifacts/ambient-4a67fe238d7346db8754f38/TestTraffic/dns/tproxy/tcp_localhost_server/_test_context/echo-1-28253-state4267053168/primary-0/, we see the dump is broken. We have the ambient AND normal workloads all in one namespace. But because we set them up separately, we must be breaking the dumping...?
cc @stevenctl
On the specific error.. query is dns://fake.service.local?&protocol=tcp&server=<IP_ADDRESS>. I don't see how it can succeed in Ambient, where there is no server running on localhost at all... it should give a connection refused.

Doesn't seem to be an active issue


High Ms(ping of excalidraw plugin)

High Ping for each device be it be mac or ipad or windows everywhere i am experiencing high ms
and

I Tried With new vault same issue
I Also Tried Formating Mac & With Fresh OS & Vault

Hi! Not sure what this means and whether it's possibly not related to the editor itself, but it's best to post this on their tracker https://github.com/zsviczian/obsidian-excalidraw-plugin/issues


NEXT Implement Svelte component unit tests

Linked Issue
Closes https://github.com/skeletonlabs/skeleton/issues/2363
Description

Implements Vitest + Testing Library for the Svelte components package.
Implements test cases for all current components.

Checklist
Please read and apply all contribution requirements.

[x] Your branch should be prefixed with: docs/, feature/, chore/, bugfix/
[x] Skeleton v3 contributions must target the next branch (NEVER dev or master)
[x] Documentation should be updated to describe all relevant changes
[x] Run pnpm check in the root of the monorepo
[x] Run pnpm format in the root of the monorepo
[x] Run pnpm lint in the root of the monorepo
[x] Run pnpm test in the root of the monorepo
[x] If you modify /package projects, please supply a Changeset

Changsets
View our documentation to learn more about Changesets. To create a Changeset:

Navigate to the root of the monorepo in your terminal
Run pnpm changeset and follow the prompts
Commit and push the changeset before flagging your PR review for review.

@Hugos68 I can't tag you as a reviewer, but I'd welcome a review from you if you have time this weekend!


Make, model, type

I wonder how to get the year, make, model, type if we don't know the type of one specific model？

There's no robustness for not knowing some of the winnowing criteria. You've got to know the list of types (go to kbb prior) and then script in a request for each type (or the type you desire specifically).


Add ability to connect to LDAP server via IPC

Make it possible to use a socket as an address to the LDAP server.
Also known as ldapi://, present in the OpenLDAP and others.
Already supported by the underlying LDAP library.
More info

Resolved by #3


Turtle parser: CURIEs in lists are not expanded

Parsing the following turtle
@base <http://example.org/> .
@prefix s: <http://schema.example.org/> .
<me> s:owns ( <Apple> <Orange>).

will (among others) generate the following triples
_:b36 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <Apple> .
_:b37 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <Orange> .

It should instead expand the relative IRIs (i.e.. http://schema.example.org/Book, http://example.org/Apple) .

Sorry, my bad CURIEs must not be in angular brackets.

I think you mean http://example.org/Apple and http://example.org/Orange right? I don't see any mention of Book and the schema.example.org namespace.
If this N3.js doing it wrong or is this in RDF-Ext? If N3.js we should probably file a bug for @RubenVerborgh

Yes, It's a resolution bug in N3.js, will solve together with https://github.com/RubenVerborgh/N3.js/issues/51.

That was actually quite a major bug. Fixed now. Not sure how this went unnoticed for years!

Great thanks for your work Ruben!

 Waiting for a feedback on https://github.com/RubenVerborgh/N3.js/issues/51 to release a new version 0.4.4 with thix fix.

My example code generates now the following triples using the git version of N3.js:
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/Apple> .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:b2 .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/Orange> .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
<http://example.org/me> <http://schema.example.org/owns> _:b1 .


genMockFromModule unreliable in a project with rooted paths

Do you want to request a feature or report a bug?
Bit of both
What is the current behavior?
jest.genMockFromModule can fail to generate mocks for npm packages. It's a bit of an edge case, but I hit it. The linked repo probably explains it better than I can in text.
Prerequisites to see this problem -

Project uses rooted/absolute paths instead of relative paths for imports
genMockFromModule is used in a __mocks__ folder to augment jest's automocks of npm packages

To use Jest with rooted paths, I set moduleDirectories to ['node_modules', './']. This makes genMockFromModule pretty angry when it's used within __mocks__ because it ends up doing recursive requires. It then supplies an empty object for the mock. I tried <rootDir> instead of ./ but it doesn't work as a moduleDirectory, which makes sense once I saw how it was used in that context.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal repository on GitHub that we can npm install and npm test.
https://github.com/jwbay/jestrelativepaths
What is the expected behavior?
Ideally <rootDir> as a moduleDirectory just works ™. I'm able to use rooted paths and genMockFromModule together.
Run Jest again with --debug and provide the full configuration it prints. Please mention your node and npm version and operating system.

node 6.9.2
yarn 0.17.10
jest version = 17.0.3
test framework = jasmine2
config = {
  "automock": true,
  "testEnvironment": "C:\\Source\\jestqwer\\jestrelativepaths\\node_modules\\jest-environment-node\\build\\index.js",
  "moduleDirectories": [
    "node_modules",
    "./"
  ],
  "rootDir": "C:\\Source\\jestqwer\\jestrelativepaths",
  "name": "C:-Source-jestqwer-jestrelativepaths",
  "setupFiles": [],
  "testRunner": "C:\\Source\\jestqwer\\jestrelativepaths\\node_modules\\jest-jasmine2\\build\\index.js",
  "transform": [
    [
      "^.+\\.jsx?$",
      "C:\\Source\\jestqwer\\jestrelativepaths\\node_modules\\babel-jest\\build\\index.js"
    ]
  ],
  "usesBabelJest": true,
  "bail": false,
  "browser": false,
  "cacheDirectory": "C:\\Users\\Admin\\AppData\\Local\\Temp\\jest",
  "coveragePathIgnorePatterns": [
    "\\\\node_modules\\\\"
  ],
  "coverageReporters": [
    "json",
    "text",
    "lcov",
    "clover"
  ],
  "expand": false,
  "globals": {},
  "haste": {
    "providesModuleNodeModules": []
  },
  "mocksPattern": "__mocks__",
  "moduleFileExtensions": [
    "js",
    "json",
    "jsx",
    "node"
  ],
  "moduleNameMapper": {},
  "modulePathIgnorePatterns": [],
  "noStackTrace": false,
  "notify": false,
  "preset": null,
  "resetMocks": false,
  "resetModules": false,
  "snapshotSerializers": [],
  "testPathDirs": [
    "C:\\Source\\jestqwer\\jestrelativepaths"
  ],
  "testPathIgnorePatterns": [
    "\\\\node_modules\\\\"
  ],
  "testRegex": "(/__tests__/.*|\\.(test|spec))\\.jsx?$",
  "testURL": "about:blank",
  "timers": "real",
  "transformIgnorePatterns": [
    "\\\\node_modules\\\\"
  ],
  "useStderr": false,
  "verbose": null,
  "watch": false,
  "cache": true,
  "watchman": true
}

I can confirm we're hitting the same issue.

We're having the same or a related issue, as we're not, at least explicitly, calling jest.genMockFromModule on the modules that come up empty.

Just in case someone comes across this, it seemed to be circular dependency on our app behaving differently while including one module rather than starting the app itself, since the require path differs quite a bit, it ended up returning empty objects back at us and the tests executed with this incomplete object as a dependency.

@jwbay any new thoughts on this?


Analytics Experiment

Purpose
Compare GTM and GA and see which one works better with the app

Coverage decreased (-0.03%) to 26.211% when pulling 8c685f1a10110dc2d4e362934dd9777b59d7a90f on martinmckenna:analytics into 3a4de2da6c8a64e9bdcac2fdac1197e81d4c38a0 on linode:develop.


Model Constructors parameters should not be required which has default value

Current
Parameters of Model which has default values also is marked as required and each time we need to pass it.
Expected
Parameters are named with a default value.

The problem is that some default values are not valid default values in Dart, because they're not constant. For instance, the current date or the current time is a valid default value in SQL, but we can't generate DateTime.now() as a default in Dart. Similarly, one might expect an auto-incrementing id column to not be required in Dart, but we need to run a full insert before we know its value.
If you want to create models to insert, use the .insert() constructor on the associated companion class. It only uses required params for columns that need to be set during an insert. If you really want default values, moor will let you use custom data classes in the next version, you're free to add default values to them.

Thanks a lot, got your point.

Can you give us an ETA for next version?

Is this issue still not solved? i am still facing the same problem on  v4.5.0

@mohammedsalem97 What particular issue are you talking about? What I wrote about in https://github.com/simolus3/moor/issues/1178#issuecomment-832742150 still applies and is not something that I intend to change.
Custom row classes are available though, their documentation is here.


Update to ES6

Is this simply a rewrite or are there breaking changes?

Not a rewrite (in the functional sense; git logs it that way since every line changed) -- just bringing it up to speed with new style guidelines and ES6 syntax before I implement more 1.0.0 changes. At this point the only breaking change is dropping 0.12 compatability, so this won't be pushed out until 1.0.

Ok, excellent! I'll all for dropping old versions of node.js and using ES6 features! :+1:

Amen. I've been systematically working through all my libs and converting over. It's a huge pain, but totally liberating. Especially for the ones that used to use Babel, and no longer need it!

@TomFrost Are you going to publish a version of Bristol with these changes? Perhaps a npm version preminor?


Move office hours to Friday at 9:30 Pacific

Per discussion in office hours toady, we're going to be moving this to Friday and trying to do more "open source friday" activities! 🎉

Done, thanks


[WIP] Better support for async/await threading model in FASTER

The FASTER model is based on a set of threads, each of which can start a session with FASTER, perform a sequence of operations, and later stop the session. Operations consist of bursts of activity, with periodic invocations of a Refresh() call to FASTER in between. It would not be okay for a thread/session to go to sleep (i.e., stop calling Refresh) without stopping its session. Sessions and threads are tightly integrated in this model.
However, this tight coupling of threads and sessions in FASTER is not ideal for an async/await API using the C# thread pool. This PR aims to investigate and prototype alternatives to this approach, and implement the best one. There is next to no code right now, this PR for now serves as a place to discuss options and alternatives.
Adding @JorgeCandeias @gunaprsd @ReubenBond for comments.
Fix #140

The first option is to eliminate thread-local variables in FASTER entirely, and have logical sessions that may move across threads. This will allow FASTER to provide persistence guarantees for a logical session (e.g., commit/persist all operations with LSN < k on the logical session), regardless of which thread the session is currently executing on. This means users can seamlessly use other async operations in their code.
Every FASTER operation would then need a session ID parameter, which is a bit ugly. Perhaps the default could still be “threads==sessions” behavior by using a session-free overload, where a thread-local variable is used to store the default session ID.
Currently, FASTER operations that go async are affinitized back to the thread that issued the I/O. The client is supposed to call CompletePending to "resume" these operations on that thread. We could leave this as it is, with logical sessions expected to call CompletePending to complete the I/Os on that session. However, it may instead be interesting to support the async model for these operations, where the operation returns a Task instead.
Internally, we could use TaskCompletionSource to handle the async operations. We could create a simplified async API layer for FASTER that simply uses FASTER’s Context generic parameter to store the TaskCompletionSource. An async callback can then complete the task using this context. Since we are in async world, there is no need for a separate user-facing Context anyway.
Note that switching a session from one thread to another is generally expensive, as the session context needs to move to the other thread. However, ideally, this would happen rarely. In the common synchronous case, we would expect a thread to have a single session to FASTER, leading to high performance very similar to the current thread-local session model.

How would you like to use ValueTask + IValueTaskSource?
It is used in library which is required high performance like System.Threading.Channels and System.IO.Pipelines.
It may be more efficient than using TaskCompletionSource.

The first option is to eliminate thread-local variables in FASTER entirely, and have logical sessions that may move across threads. This will allow FASTER to provide persistence guarantees for a logical session (e.g., commit/persist all operations with LSN < k on the logical session), regardless of which thread the session is currently executing on. This means users can seamlessly use other async operations in their code.
Every FASTER operation would then need a session ID parameter, which is a bit ugly. Perhaps the default could still be “threads==sessions” behavior by using a session-free overload, where a thread-local variable is used to store the default session ID.

One option to do away with threads could be for the lookup to pool sessions, renting them out and taking them back as needed. That could enable user syntax such as this:
using (ISession session = lookup.OpenSession())
{
    await session.UpsertAsync( /* stuff here */ )
}

In the model above, the ISession is just a shell for an object that contains a unique session id and a reference to the owning lookup. Calls on the session translate to calls on the lookup using the actual session. Disposing ISession returns the underlying rented session back to the owning session pool, while ensuring Refresh() happens at some point.

Currently, FASTER operations that go async are affinitized back to the thread that issued the I/O. The client is supposed to call CompletePending to "resume" these operations on that thread. We could leave this as it is, with logical sessions expected to call CompletePending to complete the I/Os on that session. However, it may instead be interesting to support the async model for these operations, where the operation returns a Task instead.
Internally, we could use TaskCompletionSource to handle the async operations. We could create a simplified async API layer for FASTER that simply uses FASTER’s Context generic parameter to store the TaskCompletionSource. An async callback can then complete the task using this context. Since we are in async world, there is no need for a separate user-facing Context anyway.

This what the Orleans sample is doing now. The drawback is that we now need an extra allocation for every operation, even those completing on the sync path. At this time is hard to tell what performance difference it makes due to the overhead from everything else. An implementation using ValueTask and a pooled task factory may have some merit.

Note that switching a session from one thread to another is generally expensive, as the session context needs to move to the other thread. However, ideally, this would happen rarely. In the common synchronous case, we would expect a thread to have a single session to FASTER, leading to high performance very similar to the current thread-local session model.

I think the pooled session model above could work, by making the session pool return the session that is affinitized to the running thread (instead of just an id) and only create a new one if it does not exist yet. So it would be more of a GetOrCreate()-style lookup than an actual pool. I suspect there would be some overhead as the ThreadPool adds and removes threads but in the case of Orleans that would be amortized down as the system lives on.
I'll take a stab at the AsyncFasterKV in this branch to see if this could work.

How would you like to use ValueTask + IValueTaskSource?
It is used in library which is required high performance like System.Threading.Channels and System.IO.Pipelines.
It may be more efficient than using TaskCompletionSource.

Indeed, this may have some merit, as operations in FASTER can complete sync or async.

The idea of an ISession is nice. User-facing sessions are Guids, and may need to be mapped to internal "sessions" which will simply be offsets in the epoch table. A session abstraction can potentially avoid an explicit map between session Guid and the table offset.

Yeah, the extra allocation is not good. We really need the normal sync code path to be as lightweight as it is right now. One crazy idea is to make context an out param, allowing a user defined callback to create the context when it is needed.

I think the pooled session model above could work, by making the session pool return the session that is affinitized to the running thread (instead of just an id) and only create a new one if it does not exist yet.

If the pooled session was simply going to return the session associated with the thread, then what would happen after an async call returns on a different thread? Would the code continue to use that same old session, now on a different continuation thread? What about another session that now tries to continue on the older thread? It seems that we would need sessions to be independent of threads, right?

One crazy idea is to make context an out param, allowing a user defined callback to create the context when it is needed.

At least this can get the shell AsyncFasterKV working early without affecting the sync path or the core FasterKV too much.

If the pooled session was simply going to return the session associated with the thread, then what would happen after an async call returns on a different thread? Would the code continue to use that same old session, now on a different continuation thread? What about another session that now tries to continue on the older thread? It seems that we would need sessions to be independent of threads, right?

You're right, that would open a can of worms, if it would even work at all. Best to split those concerns from the onset.
As a first step, I'd just exploit the context parameter as the Orleans sample does it, and either make the context on the FasterKV an out or a ref to allow delaying the allocation up to when we hit the async path. That will be a breaking change on the current surface, but at least we can test it. And while a ValueTask sync path may have merit, the problem is that we can only await on it once. That's fine for tight-controlled internals, but prone to bugs on a public surface. Let's see how far we can get with plain old Tasks.

I think the pooled session model is appropriate. The sessions would essentially be async-local instead of thread-local.
Alternatively, each grain could rent a session at activation and return it at deactivation. That would require something to pulse Refresh(), which we could potentially add hooks for (or use a timer).
Thread-local has issues with a dynamically sized thread pool such as .NET's ThreadPool (which grains do not use currently)

Okay, I'm just getting back to this topic after some travel. I plan to work on decoupling threads and sessions in Faster now, on this branch.
The epoch table will contain one row per session. There will be no thread local variables any more. When someone closes a session, the epoch table entry will become available for another session to rent out.
@reubenbond, the session is a local variable for the application and thus effectively 'async local'. Is this what you meant, or were you thinking of AsyncLocal? The latter seems not very useful to me, perhaps I am missing something ...

Rough sketch of session checked in, without touching the existing thread-local framework: session-based access will just update existing thread-local variables using the session's values, before proceeding with usual operation normally.

@JorgeCandeias -- I added some preliminary support for pooled sessions. we need to see if this can improve the Orleans integration. See samples at https://github.com/microsoft/FASTER/blob/async-support/cs/test/SessionFASTERTests.cs

App can request a session and perform FASTER operations on it as it hops across threads (e.g., due to other async calls it might make)
Two apps can request two different sessions on the same thread.
An app can dispose a session, i.e., the next app that requests a session will not resume that session.
An app can "return" a session to FASTER. In this case, another app can call GetSharedSession and potentially get back the same session to continue operations on.
Apps can always call CreateSharedSession to get a fresh session

I'm still a bit fuzzy on how exactly this would map to the Orleans threading model, and would appreciate your thoughts. E.g., since individual grains may perform other async ops at any time, they may be holding an active FASTER session when they go async, right? In that case, when a different grain is scheduled on that thread, it would need to "rent" a different session. Thus, the number of active sessions may grow to more than the number of threads -- it would depend on the number of pending activated grains.

@JorgeCandeias -- any comments? Would this version be of interest to you to improve the FASTER-Orleans sample? And what do you think of adding a true async interface to FASTER?

Hi @badrishc, many apologies for the delay, other things moved up on my list in the meantime, but this one is still on it.
Yes, this version is already useful for improving the sample, so I'll take it on-board, thank you!
That said, being a synchronous interface, it will still have to run on the thread pool in order not to limit throughput on the Orleans task scheduler when spinning for I/O completions. A true async interface with no blocking or background threads will enable direct integration with the Orleans scheduler and therefore not having to rely on the thread pool.
More importantly, it will become easier to promote this to product developers looking for straightforward solutions. 😄

E.g., since individual grains may perform other async ops at any time, they may be holding an active FASTER session when they go async, right? In that case, when a different grain is scheduled on that thread, it would need to "rent" a different session. Thus, the number of active sessions may grow to more than the number of threads -- it would depend on the number of pending activated grains.

This is correct. It has less to do with grains and more with TPL tasks. Although the Orleans scheduler only creates as many worker threads as processors, there can be great many tasks pending in the system, due to awaiting something non-CPU bound to complete, like I/O operations. In the meantime other tasks will run.
For background on this, Orleans does this to keep the CPU doing actual user work as much as possible and avoid wasting cycles on context switching or spinning for I/O. The reason is that grain requests on Orleans tend to be very fine-grained on the CPU, e.g. in the microseconds and lower (even if they await I/O tasks for longer), so having an Orleans worker thread spinning even for a few milliseconds can lower the throughput ceiling. Orleans is opinionated on this and enforces responsiveness in the system by killing any task taking over 30s and issuing warnings when tasks take over 200ms, regardless of CPU usage.
In my head, for an async/await model to work with the Orleans scheduler, I think...

For isolated sessions, there must be no (or very high) upper bound for the number of in-use sessions against a lookup, even if the pool itself has some limit. If faster can support this, then the sessions do not need to be thread-safe. Each grain task can request one, do work, go async, do more work, then return the session to the session pool for another task to request. This assumes developers won't pass around sessions between threads, just like we don't pass SqlConnections around.

For shared sessions, the sessions will need to be thread-safe. Let's say task 1 requests session A on thread 1 and awaits, then task 2 requests session A again on thread 1 and also awaits. When either continuation resumes, there's no guarantee the work will be performed on the same thread, as far as I know (@ReubenBond please correct me on this). We may end up with the continuations from tasks 1 and 2 accessing the same session concurrently.

I'm leaning in favour of isolated/pooled sessions because they mimic the behavior of well-known expensive resources such as SqlConnection, which product developers already tend to handle with care. Also, thread-safety and performance don't tend to mix, not sure how much concurrency handling would affect session performance, which already exists to avoid concurrency in the first place. What is your opinion?

I attempted to apply the TaskCompletionSource trick recommended by @ReubenBond on my PR clone, but wasn't able to do it on the "async lookup shell" (for lack of a better name) without it requiring changing the underlying lookup code and without avoiding allocation of TaskCompletionSource instances upfront.
Maybe you two have a better trick for this that I can learn from?
I'll try again on this new code base over the weekend and some good coffee.

Alternatively, each grain could rent a session at activation and return it at deactivation. That would require something to pulse Refresh(), which we could potentially add hooks for (or use a timer).

This matches the intent of the sample and naturally follows into creating generic grain templates for any type, or with an eye in the future, providing an injected faster lookup for some type and underlying storage via DI bindings, azure function style.

Orleans is opinionated on this and enforces responsiveness in the system by killing any task taking over 30s

One minor point: we wont kill Tasks, since .NET Tasks are co-operative & aren't preemptible

This assumes developers won't pass around sessions between threads,

Just to be precise here: a grain method call can hop between threads between await points, so the session wouldn't strictly be thread-local

When either continuation resumes, there's no guarantee the work will be performed on the same thread, as far as I know

Yes, precisely correct. This goes for any async method in .NET (i.e, it's not Orleans-specific)

One minor point: we wont kill Tasks, since .NET Tasks are co-operative & aren't preemptible. We will throw a timeout exception back to the caller, though, so that they aren't left hanging forever. We will also destroy the grain activation if it has become unresponsive for a very long time.

Thanks for this important clarification 👍

This assumes developers won't pass around sessions between threads,

Just to be precise here: a grain method call can hop between threads between await points, so the session wouldn't strictly be thread-local

What I meant was it assumes developers won't willingly pass sessions around in a way that allows concurrent access.

I attempted to apply the TaskCompletionSource trick recommended by @ReubenBond on my PR clone, but wasn't able to do it on the "async lookup shell" (for lack of a better name) without it requiring changing the underlying lookup code and without avoiding allocation of TaskCompletionSource instances upfront.

How about this: we slightly modify FASTER's API to support "ref Context" instead of "Context". User then passes in a "null" context to the lookup. If/when an operation goes async, it can fill up/augment this context via a new user-specified context provider callback. In our use case, this callback will allocate the TaskCompletionSource instance. It would be "ref" instead of "out" because users might still want to add stuff to the context (from the stack) before invoking the operation.
void UpdatePendingContext(ref context);
{
   context = new TaskCompletionSource<TOutput>(...);
}

How about this: we slightly modify FASTER's API to support "ref Context" instead of "Context".

That's what I did and that's what I was trying to avoid.

I've updated my clone with an alternate approach. Instead of relying on user code to set a ref variable on a callback (that may or may not happen), the CompletePending action is now itself async. This propagates down to the callbacks themselves, which, if called, must return at least an empty ValueTask (in order to implement the IFunctions interface, so it's now forced). If not called, that's okay too. The idea is to allow the user to continue pushing many data items to the lookup at once, while resolving any possible I/O at the end, the same way regular faster does it.
The UpsertCompletionCallback is updated as an example, as ValueTask UpsertCompletionCallback(ref Key key, ref Value value, Context ctx).
However, this required adjusting the existing signature, so it's a breaking change.
Also, I haven't yet dealt with the blocking collection call regarding IO itself.
internal void CompleteIOPendingRequests(FasterExecutionContext context)
{
    if (context.readyResponses.Count == 0) return;

    while (context.readyResponses.TryTake(out AsyncIOContext<Key, Value> request))
    {
        InternalContinuePendingRequestAndCallback(context, request);
    }
}

Do you think this approach is a viable option to replace that spinning for I/O with an async api?

Thanks @JorgeCandeias for your comments and explanation. It all makes sense.
In order to support a large number of sessions, I have redone the sessions interface so that it does not hold on to an entry in the epoch table. We ideally do not want the epoch table to grow larger than the number of cores/threads because we have to scan the epoch table in some situations.
In the current prototype, I let users create many "client sessions", and the client session simply copies the session context to the FASTER thread-local session on whatever thread the client session is currently running on. Client sessions are effectively async-local. Client sessions can scale up beyond the number of (internal) FASTER epoch entries which are thread-local. I still need to figure out how to integrate best with checkpointing, since we would need to complete the pending IO operations of sessions that are inactive as well.
I have added support for "ref Context" as an addition API, keeping the non-ref version for compatibility.
The async CompletePending is a good idea, but I don't see why the completion callbacks need to be async -- the callbacks are user code where there will likely not be async stuff going on. E.g., they just copy the value to an output variable. Instead, we can make the polling for I/O completion async by using an async semaphore.

After some hacking, I think it makes more sense, as you mentioned, to only have an async version of CompletePending, and not try to make individual operations async. This fits well in spirit with the notion of introducing batching in a non-invasive manner.
I am currently working on a truly async version of CompletePending (no spin wait or blocking) that can await all ops issued until that point in time. (This may even later be extended if needed to await all ops until a given seq. no. on that session.)
So, we don't need to add a ref context with this solution.
Checkpoint will also work similarly with an async CompleteCheckpoint, although that requires a bit more thinking/work internal to FASTER in order to notify client sessions, which may or may not be currently active.

Any idea why adding the NuGet package for ValueTask is causing C# Linux build on Mono to fail? https://dev.azure.com/ms/FASTER/_build/results?buildId=28238

The stack trace shows a MissingMethodException. I wonder if some tooling version needs updating

Yeah, updating .net core to latest fixed the issue.

@JorgeCandeias @ReubenBond et al.: we now have a prototype sessions API with async support. Please take it for a spin and let me know what you think.
Examples are here:

https://github.com/microsoft/FASTER/blob/async-support/cs/test/SessionFASTERTests.cs
https://github.com/microsoft/FASTER/blob/async-support/cs/test/AsyncLargeObjectTests.cs
https://github.com/microsoft/FASTER/blob/async-support/cs/benchmark/FasterYcsbBenchmark.cs (this one uses a faster non-async version, but still using Session object)

Interestingly, benchmark perf is unaffected by these changes! For the non-async sessions (used only in FasterYcsbBenchmark), we get 180M ops/sec, similar to before.
For async sessions (the default), as long as we are issuing non-async ops to keys in memory, we get 160M ops/sec. This is in spite of doing fine-grained per-operation epoch resume and suspend! Users now do not need to call Refresh() periodically with the async sessions interface, which is the default. So it is more natural to C# developers. Feedback requested!
            using (var session = fht.StartClientSession())
            {
                InputStruct input = default(InputStruct);
                OutputStruct output = default(OutputStruct);

                var key1 = new KeyStruct { kfield1 = 13, kfield2 = 14 };
                var value = new ValueStruct { vfield1 = 23, vfield2 = 24 };

                session.Upsert(ref key1, ref value, Empty.Default, 0);
                var status = session.Read(ref key1, ref input, ref output, Empty.Default, 0);

                if (status == Status.PENDING)
                {
                    await session.CompletePendingAsync();
                }
                else
                {
                    Assert.IsTrue(status == Status.OK);
                }

                Assert.IsTrue(output.value.vfield1 == value.vfield1);
                Assert.IsTrue(output.value.vfield2 == value.vfield2);
            }

Great! For write operations, will subsequent status be pending almost always (unless some background flush occurred)?
I wonder if the operation should return ValueTask instead of Status. If the status is Ok then the result is completed synchronously and if it's not Ok then the result must be awaited. It doesn't work with out/ref params, so the method would return ValueTask where T is some tuple or result type, but I believe it's more natural

Upsert operations will almost always complete synchronously. Read operations might return a status of pending if they are reading something that is older and not in memory.
The idea of individual operations returning a Status is that in the FASTER session model, user session can issue batches of requests synchronously at extremely high performance, and periodically compete all (hopefully rare) outstanding pending operations by calling async CompletePending, or calling sync CompletePending to complete only the pending ops that have already returned from IO.
Making every read etc. operation return ValueTask will be a breaking change, and will require us to break the current invariant that all work happens on the user thread/session, never in an async thread (expect for the actual IO completion, which just queues the competition to a session local queue for later pull-based consumption by the session (via the CompletePending call). Also, the number of parked tasks will grow to the number of outstanding operations, instead of just one task for CompletePending.
Also, see these comments:

https://github.com/microsoft/FASTER/pull/130#issuecomment-515549467
https://github.com/microsoft/FASTER/pull/130#issuecomment-517769617

We now have a full async-compliant sessions interface to FasterKv! You no longer need to call refresh or worry about thread affinity. The overall idea is to create new sessions to FasterKv and perform a sequence of operations on a session. You can also have a separate async committer (checkpointer) thread for durability. The async session operations can be configured to await until either after they are completed in memory to made durable by a checkpoint. This is similar to the new FasterLog API.
See any example in the playground for details (older API is marked obsolete for now). A good one is the newly added sample here.
I think it almost cannot get easier than this for C# users, but would love to hear feedback from everyone.

Async Sessions API
// Create new shared FASTER KV
var faster = new FasterKV(...);

// Create any number of sessions to FasterKV
var session = faster.NewSession();

// Async read, retrieves from disk if needed, reads uncommited if present
(Status, Output) result = await session.ReadAsync(key);

// Read waits for uncommitted read value to checkpoint/commit before returning
(Status, Output) result = await session.ReadAsync(key, waitForCommit: true);

// Upsert into mutable region, does not wait for commit
await session.UpsertAsync(key, value);

// Upsert into mutable region, return after this (and all prev) upserts commit
await session.UpsertAsync(key, value, waitForCommit: true);

// RMW into mutable region, does not wait for commit
await session.RMWAsync(key, input);

// RMW into mutable region, wait for commit
await session.RMWAsync(key, input, waitForCommit: true);

// Waits for all prev operations on session to commit before returning
await session.WaitForCommit();

Commits can be performed periodically by a separate thread/task:
int i = 0;
while (true)
{
  Thread.Sleep(5000);
  if (i++ % 100 == 0)
     faster.TakeFullCheckpoint(out _); // periodically take full index + log checkpoint
  else
     faster.TakeHybridLogCheckpoint(out _); // take (incremental) log checkpoint
}


Cannot zoom in or zoom out camera using gdscript

Godot version
v3.3.3.stable.custom_build [b973f997f]
System information
Raspberry pi 4
Issue description
So I'm new to godot and I'm playing around with it. However, I've stumbled upon a problem in making the camera zoom in and out using gdscript. I have a player which can move up, down, left, and right, but I want the camera to zoom out since the player is too close to the camera. Here is my code for Camera2D:
extends Camera2D

# Zoom minimum
var zoom_min = Vector2(.200001, .200001)
# Zoom max
var zoom_max = Vector2(2, 2)
# Zoom speed
var zoom_speed = Vector2(.2, .2)
# Desired zoom
var des_zoom = zoom

func _process(delta):
	zoom = lerp(zoom, des_zoom, .2)

func _input(event):
	if event is InputEventMouseButton:
		if event.is_pressed():
			if event.button_index == BUTTON_WHEEL_UP:
				if des_zoom > zoom_min:
					des_zoom -= zoom_speed
			if event.button_index == BUTTON_WHEEL_DOWN:
				if des_zoom < zoom_max:
					des_zoom += zoom_speed

and here is my player code (Just in case):
extends KinematicBody2D

var speed = 30
var velocity = Vector2.ZERO

func _physics_process(delta):
	if Input.is_action_pressed("ui_right"):
		velocity.x = speed
	elif Input.is_action_pressed("ui_left"):
		velocity.x = -speed
	else:
		velocity.x = 0
	if Input.is_action_pressed("ui_down"):
		velocity.y = speed
	elif Input.is_action_pressed("ui_up"):
		velocity.y = -speed
	else:
		velocity.y = 0

	move_and_slide(velocity)

Finally, here are 2 images for showing my output, and how the outside looks on my end:

Steps to reproduce
extends Camera2D

# Zoom minimum
var zoom_min = Vector2(.200001, .200001)
# Zoom max
var zoom_max = Vector2(2, 2)
# Zoom speed
var zoom_speed = Vector2(.2, .2)
# Desired zoom
var des_zoom = zoom

func _process(delta):
	zoom = lerp(zoom, des_zoom, .2)

func _input(event):
	if event is InputEventMouseButton:
		if event.is_pressed():
			if event.button_index == BUTTON_WHEEL_UP:
				if des_zoom > zoom_min:
					des_zoom -= zoom_speed
			if event.button_index == BUTTON_WHEEL_DOWN:
				if des_zoom < zoom_max:
					des_zoom += zoom_speed

Minimal reproduction project
No response

This is likely because using += and -+ on Vector2/Vector3 variables is currently broken. Try using = to assign the variable instead.

This is likely because using += and -+ on Vector2/Vector3 variables is currently broken in master (due to the GDScript rewrite). Try using = to assign the variable instead.

This appears in be in 3.3.3, so that should be unrelated.

It works at expected in 3.2.3.stable and my 3.4.rc.custom_build.d5adb9e4b.
At first the zoom wasn't working, but later I realized the problem was the camera wasn't the current one.
@RockZombie123 could you try to add this to your demo script?
func _init():
        current = true

You can also try to check it in the inspector window.

@robfram Thank you! This worked like a miracle. I think current was probably set to false.


⚠ 366.ru has degraded performance

In 5d3d6d2, 366.ru (https://366.ru) experienced degraded performance:

HTTP code: 200
Response time: 5339 ms

Resolved: 366.ru performance has improved in ae3cdab.


no matches for kind "ApplicationSet" in version "argoproj.io/v1alpha1"

Hi, I am trying to use kind as ApplicationSet. However it is giving me an error
no matches for kind "ApplicationSet" in version "argoproj.io/v1alpha1"

@nishit93-hub Most probably you do not have the controller installed:
Install this CDR and later you can apply your ApplicationSet YML file:
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/applicationset/master/manifests/install.yaml

Regards,

@nishit93-hub Install instructions are here: https://argocd-applicationset.readthedocs.io/en/stable/Getting-Started/

@JimFran @jgwest , yes the applicationSet controller was not installed. Thanks for the help!


p 5 par 1: remove comma, move "and"

We have over 100 Embassies , and
<enter Pangea_ bitnation.co 5
Consulates, and over 10,000 Citizens on all five continents, and a dynamic community of 2000
contributors on our Slack channel. We offer a range of services in-house or in partnership with
other providers.

got it


⚠ SceneTime has degraded performance

In 882ecea, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 3140 ms

Resolved: SceneTime performance has improved in a00d7a1 after 11 minutes.


Prefer SSZ over RLP for the History content

Fix #149
The rationale for all of the list upper limits is a bit verbose. Also, changing them will be a pain in the butt later, so maybe it's worth overshooting even more than I have? (Although the maximum count only seems to affect the proofs, rather than the full encodings)
Here is the rational for the encodings:
_MAX_TRANSACTION_LENGTH = 2**24  # ~= 16 million
# Maximum transaction body length is achieved by filling calldata with 0's
# until the block limit of 30M gas is reached.
# At a gas cost of 4 per 0-byte, that produces a 7.5MB transaction. We roughly
# double that size to a maximum of >16 million for some headroom. Note that
# EIP-4488 would put a roughly 1MB limit on transaction length, effectively. So
# increases are not planned (instead, the opposite).

_MAX_TRANSACTION_COUNT = 2**14  # ~= 16k
# 2**14 simple transactions would use up >340 million gas at 21k gas each.
# Current gas limit tops out at 30 million gas.

_MAX_RECEIPT_LENGTH = 2**23  # ~= 8 million
# Maximum receipt length is logging a bunch of data out, currently at a cost of
# 8 gas per byte. Since that is double the cost of 0 calldata bytes, the
# maximum size is roughly half that of the transaction. That gives a maximum of
# >8 million bytes per receipt.

_MAX_HEADER_LENGTH = 2**13  # = 8192
# Maximum header length is fairly stable at about 500 bytes. It might change at
# the merge, and beyond. Since the length is relatively small, and the future
# of the format is unclear to me, I'm leaving more room for expansion, and
# setting the max at about 8 kilobytes.

_MAX_ENCODED_UNCLES_LENGTH = _MAX_HEADER_LENGTH * 2**4  # = 2**17 ~= 131k
# Maximum number of uncles is currently 2. Using 16 leaves some room for the
# protocol to increase the number of uncles.

Rationale for upper limits look good to me. Only thing I might want to see is a rationale for why ~10x current gas limits is a reasonable driver for MAX_TRANSACTION_COUNT. I personally have less of a sense for why that limit won't need to be updated in the future than, for example, why it's reasonable to assume block headers won't surpass 8kb.
Agree with @kdeme on putting the limits/rationales in the spec.

Only thing I might want to see is a rationale for why ~10x current gas limits is a reasonable driver for MAX_TRANSACTION_COUNT. I personally have less of a sense for why that limit won't need to be updated in the future than, for example, why it's reasonable to assume block headers won't surpass 8kb.

My very rough rationale is mostly based on the mainnet history. The gas limit has increased a number of times over the years, fairly significantly. Started around 3M, and 6 years later has an upper limit of 30M (which almost implies that 10x upper limit might not be enough). The header format has changed once, by adding a new base_fee_per_gas field.
Actually, it might be relevant to look into how consensus headers are built. I suppose they are SSZ and contain execution headers embedded, so already had to make these decisions about how long they think a header can be.

which almost implies that 10x upper limit might not be enough

In fact, this makes me think that the receipt length limit might be low. We have some indication that an upper bound on transaction length will be enforced (because it impacts the speed that blocks are gossiped). But execution client devs don't really have any in-protocol reason to enforce the upper limit of receipt length, AFAICT. So all it would take to reach the current limit is a drop in the logging cost by half, or a doubling of the gas limit. Maybe I'll add more wiggle room on top of that...


aesthetic changes to notified page

changed the background color, display font style and size, along with the alignment and padding of the notified page. added an "instructions" section as well.

thanks for the update!


Setting cors middleware for custom rtcserver

hello,
how do i go about adding CORSMiddleware to uvicorn using this example?
https://abhitronix.github.io/vidgear/v0.2.1-dev/gears/webgear_rtc/advanced/#using-webgear_rtc-with-a-custom-sourceopencv
I cant seem to get it right.
web.routes.append(Route("/rtc", endpoint=rtc))
web.config["server"] = Custom_RTCServer(source="v.mp4")

web.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

uvicorn.run(web(), host="<IP_ADDRESS>", port=8001, forwarded_allow_ips="*")

@haviduck you're late to the party. I just released next version yesterday.

how do i go about adding CORSMiddleware to uvicorn using this example?

No, it is not yet supported yet as nobody asked about it, but I can add it by adding few lines of  code. Please wait till I push next commit in testing branch. I'll inform you here.

@haviduck You can also do as follows:
from starlette.middleware.cors import CORSMiddleware

web.routes.append(Route("/rtc", endpoint=rtc))
web.config["server"] = Custom_RTCServer(source="v.mp4")

web = CORSMiddleware(
    web,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

uvicorn.run(web(), host="<IP_ADDRESS>", port=8001, forwarded_allow_ips="*")

But I'll add middleware support natively too.

@haviduck You can also do as follows:
from starlette.middleware.cors import CORSMiddleware

web.routes.append(Route("/rtc", endpoint=rtc))
web.config["server"] = Custom_RTCServer(source="v.mp4")

web = CORSMiddleware(
    web,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

uvicorn.run(web(), host="<IP_ADDRESS>", port=8001, forwarded_allow_ips="*")

But I'll add middleware support natively too.

sweet, thanks! :)

@haviduck First install development branch as follows:
  # clone the repository and get inside
  git clone https://github.com/abhiTronix/vidgear.git && cd vidgear

  # checkout the latest development branch
  git checkout development

  # install normally
  pip install .

  # OR install with asyncio support
  pip install .[asyncio]

then use this python code:
# import necessary libs
import uvicorn, asyncio, cv2
from av import VideoFrame
from aiortc import VideoStreamTrack
from vidgear.gears.asyncio import WebGear_RTC
from vidgear.gears.asyncio.helper import reducer
from starlette.middleware import Middleware
from starlette.middleware.cors import CORSMiddleware

# initialize WebGear_RTC app without any source
web = WebGear_RTC(logging=True)

# create your own Bare-Minimum Custom Media Server
class Custom_RTCServer(VideoStreamTrack):
    """
    Custom Media Server using OpenCV, an inherit-class
    to aiortc's VideoStreamTrack.
    """

    def __init__(self, source=None):

        # don't forget this line!
        super().__init__()

        # initialize global params
        self.stream = cv2.VideoCapture(source)

    async def recv(self):
        """
        A coroutine function that yields `av.frame.Frame`.
        """
        # don't forget this function!!!

        # get next timestamp
        pts, time_base = await self.next_timestamp()

        # read video frame
        (grabbed, frame) = self.stream.read()

        # if NoneType
        if not grabbed:
            return None

        # reducer frames size if you want more performance otherwise comment this line
        frame = await reducer(frame, percentage=30)  # reduce frame by 30%

        # contruct `av.frame.Frame` from `numpy.nd.array`
        av_frame = VideoFrame.from_ndarray(frame, format="bgr24")
        av_frame.pts = pts
        av_frame.time_base = time_base

        # return `av.frame.Frame`
        return av_frame

    def terminate(self):
        """
        Gracefully terminates VideoGear stream
        """
        # don't forget this function!!!

        # terminate
        if not (self.stream is None):
            self.stream.release()
            self.stream = None

# assign your custom media server to config with adequate source (for e.g. foo.mp4)
web.config["server"] = Custom_RTCServer(source="foo.mp4")

# define suitable cors middlewares
web.middleware = [
    Middleware(
        CORSMiddleware,
        allow_origins=["*"],
        allow_credentials=True,
        allow_methods=["*"],
        allow_headers=["*"],
    )
]

# run this app on Uvicorn server at address http://localhost:8000/
uvicorn.run(web(), host="localhost", port=8000)

# close app safely
web.shutdown()

@haviduck Please test the above solution and check if it works for you.

@haviduck Please test the above solution and check if it works for you.

yeah it does  my cef app ate it like breakfast :)
thanks for helping out, man.

Successfully resolved and merged in commit https://github.com/abhiTronix/vidgear/commit/88658c083cfee1940ff69d985a5562f2edb27beb


Restore Julia 1.7 compatibility

Enzyme does not support Julia 1.7 properly with threads, even when runtime activity check is activated.


Branch logics

Specify branching behavior of sequences. Link sequential branches and link target input arguments for reproducibility of transitions as to be performed in #14

record('block1', block1Records); // Branches record, applies input on target and points target of record to branch
                                 // Map of top record always remains empty

record('block1')('block2', block2Records); // Branches block 1 and repeats procedure

record('/file', 124121); // Forwards call to target block 2, creates file record,
                         // updates record target to branch and returns content record

new record()('/file', 812714); // Branches record and modifies file, returns content but does not
                               // update target of top record

t.equal(record('/file')().valueOf(), 124121);


possible bug in optimization of qat wake signals

Hi all,
I believe I have encountered a bug with the optimization around the reduction of wake signals for qat offload which causes unneeded latency. The issue seems to be around the usage of thread-local.
Commit which added this optimization: https://github.com/intel/QAT_Engine/commit/32f37108333f712f7a0debe1a5dac9e6d79cdfb7
This optimization seems to make the assumption that a offload request will be resumed on the same thread that started it, see this pseudo-example:
This example considers a single epoll instance, with multiple worker threads waiting for events.
int global_epoll_inst = epoll_create()

Thread 1:
- app: bssl_qat_async_start_job -> ASYNC_WAIT_CTX_get_all_fds -> epollctl(global_epoll_inst. EPOLL_CTL_ADD, fd)
- engine: tlv->localOpsInFlight = 0
- engine: qat_rsa_decrypt -> QAT_INC_IN_FLIGHT_REQS -> sem_post
- engine: tlv->localOpsInFlight = 1

Intel QAT Polling Thread:
- sem_timedwait -> WAKE
- poll

Thread 2:
- app: epoll_wait(global_epoll_inst) --> resumed
- app: bssl_qat_async_ctx_copy_result(ctx)
- tlv->localOpsInFlight = 0
- engine: QAT_DEC_IN_FLIGHT_REQS
- tlv->localOpsInFlight = -1

Thread 1:
- app: bssl_qat_async_start_job -> ASYNC_WAIT_CTX_get_all_fds -> epollctl(global_epoll_inst. EPOLL_CTL_ADD, fd)
- engine: tlv->localOpsInFlight = 1
- engine: qat_rsa_decrypt -> QAT_INC_IN_FLIGHT_REQS (*bug* no call to sem_post!)
- engine: tlv->localOpsInFlight = 2

Intel QAT Polling Thread:
- sem_timedwait -> TIMEOUT
- poll

...

The side-effect is that the TLV get's into a state where localOpsInFlight it will never == 1 and so sem_post never get's called anymore and then the polling thread's sem times out.
The relevant code section seems to be: https://github.com/intel/QAT_Engine/blob/ba2035c04e826018478fdb458ce51f545de076eb/qat_hw_rsa.c#L324-L327
I'm wondering if it would be possible to use num_requests_in_flight == 1 (atomic) in the if ? I did not test this, but the use of a TLV here seems like it could be problematic to consumers

I will check this and get back to you soon.
Thanks for reporting.

We have created an internal defect to track and will keep you updated on the progress.

Thanks - for my use case I was able to work around the issue by changing the threading model from a single epoll instance shared across threads, to having an epoll instance per thread. This allows the qat transactions to be started / resumed on the same thread.


Terminal closes after adding the line to bashrc

Hi
I followed the installation guide and everything went fine.
I also installed php 7.0.4
Now whenever i open the terminal it closes instantly.
I found out that is related with the addition of the line
[[ -e ~/.phpbrew/bashrc ]] && source ~/.phpbrew/bashrc
to my bashrc (attached)
bashrc.zip
System Ubuntu 14.0.4

I think that i had to add the line to the file .bashrc which is located in my home folder, rather than in the bashrc which is located in the home/phpbrew folder


[#6872] Polishing

Codecov Report

Merging #6935 into master will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master    #6935   +/-   ##
=======================================
  Coverage   39.32%   39.33%
=======================================
  Files        3221     3221
  Lines       95044    95043    -1
  Branches    11893    11891    -2
=======================================
+ Hits        37378    37383    +5
+ Misses      54676    54670    -6
  Partials     2990     2990

Impacted Files
Coverage Δ

...npoint/web/service/TransactionInfoServiceImpl.java
0.00% <0.00%> (ø)

...corp/pinpoint/web/vo/callstacks/DefaultRecord.java
0.00% <0.00%> (ø)

...p/pinpoint/rpc/stream/StreamChannelRepository.java
75.00% <0.00%> (-10.00%)
:arrow_down:

...rc/main/java/com/navercorp/pinpoint/test/Item.java
70.00% <0.00%> (-3.34%)
:arrow_down:

.../pinpoint/rpc/client/PinpointClientHandshaker.java
65.00% <0.00%> (-1.43%)
:arrow_down:

...point/rpc/client/DefaultPinpointClientHandler.java
71.10% <0.00%> (-0.98%)
:arrow_down:

...orp/pinpoint/rpc/server/DefaultPinpointServer.java
80.28% <0.00%> (+0.35%)
:arrow_up:

...rp/pinpoint/rpc/server/PinpointServerAcceptor.java
84.10% <0.00%> (+0.66%)
:arrow_up:

...cluster/zookeeper/ZookeeperClusterDataManager.java
54.83% <0.00%> (+1.93%)
:arrow_up:

...om/navercorp/pinpoint/rpc/codec/PacketDecoder.java
59.57% <0.00%> (+2.12%)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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


Generating individual RSS by uuid

great idea! can you add a test also?

I am not sure how to do the test thing for now. Sorry about that.
Sent from Outlook for iOShttps://aka.ms/o0ukef

From: dgtlmoon @.>
Sent: Sunday, October 30, 2022 3:34:33 PM
To: dgtlmoon/changedetection.io @.>
Cc: Bing Wong @.>; Author @.>
Subject: Re: [dgtlmoon/changedetection.io] Generating individual RSS by uuid (PR #1072)
great idea! can you add a test also?
—
Reply to this email directly, view it on GitHubhttps://github.com/dgtlmoon/changedetection.io/pull/1072#issuecomment-1296150175, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGTQCLB3OTS5MNEHTY3PVTDWFYJHTANCNFSM6AAAAAARSCCR5I.
You are receiving this because you authored the thread.Message ID: @.***>

I would love this feature. It would integrate very nicely with RSS softwares.
@dgtlmoon Can you elaborate what you mean by test? I am not very good on python, but maybe this is something I or someone who knows python can do :)


Add 'Inverse scale' in gamma error output.

Submission Checklist

[x] Run unit tests: ./runTests.py test/unit
[x] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary:
gamma_* functions use shape and rate (inverse scale) parametrization for Gamma distribution.
Now the doc and the parameters checkers are consistent with the input parameters.
The issue: https://github.com/stan-dev/math/issues/514
Intended Effect:
How to Verify:
Side Effects:
Documentation:
Reviewer Suggestions:
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Nikita Doykov
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

We can't accept pull requests without copyright declaration and an agreement by the copyright holder to release the code open source.

I've added the copyright.
make cpplint returns:
make: *** [cpplint] Error 1
as before the commit.
I didn't get why, but this pull request is only about comments so I think It's ready to be merged.


Focus Traversal in Stacked Dialogs

Hey JFoenix-Team.
I'm not sure if it's a issue or if I miss something.
Setup:

Main GUI has a StackPane as it's root element
Dialogs are shown by calling new JFXDialog(somesetup and content).show()

Issue:

When "tabbing" through the controls inside the dialog, the focus jumps to controls outside the dialog which should not be possible!?
Using mouseclick, focus on outside controls is not possible

BTW: You are doing a great job! Thanks!
Best regards,
Christoph

Hi Christoph, yeah the problem with JFXDialog is that it's not modal.
I'll try to fix the focus traversal issue, however for the time being you can use JFXAlert instead.
Regards,

Hi Christoph, yeah the problem with JFXDialog is that it's not modal.
I'll try to fix the focus traversal issue, however for the time being you can use JFXAlert instead.
Regards,

Hi Shadi,
thanks for your answer and a possible fix!
Best regards and happy & healthy new year,
Christoph
Von: Shadi Shaheen<EMAIL_ADDRESS>Gesendet: Mittwoch, 6. Januar 2021 11:38
An: jfoenixadmin/JFoenix<EMAIL_ADDRESS>Cc: CTaszus<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Betreff: Re: [jfoenixadmin/JFoenix] Focus Traversal in Stacked Dialogs (#1159)
Hi Christoph, yeah the problem with JFXDialog is that it's not modal.
I'll try to fix the focus traversal issue, however for the time being you can use JFXAlert instead.
Regards,
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/jfoenixadmin/JFoenix/issues/1159#issuecomment-755223006 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIILISTQ6HB2NAWQUS2O4LSYQ4RJANCNFSM4TIRXJSQ .  https://github.com/notifications/beacon/AEIILIQFA3YBQ6OYHXBSDKLSYQ4RJA5CNFSM4TIRXJS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUB4TXQ.gif

Hi Shadi,
thanks for your answer and a possible fix!
Best regards and happy & healthy new year,
Christoph
Von: Shadi Shaheen<EMAIL_ADDRESS>Gesendet: Mittwoch, 6. Januar 2021 11:38
An: jfoenixadmin/JFoenix<EMAIL_ADDRESS>Cc: CTaszus<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Betreff: Re: [jfoenixadmin/JFoenix] Focus Traversal in Stacked Dialogs (#1159)
Hi Christoph, yeah the problem with JFXDialog is that it's not modal.
I'll try to fix the focus traversal issue, however for the time being you can use JFXAlert instead.
Regards,
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/jfoenixadmin/JFoenix/issues/1159#issuecomment-755223006 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIILISTQ6HB2NAWQUS2O4LSYQ4RJANCNFSM4TIRXJSQ .  https://github.com/notifications/beacon/AEIILIQFA3YBQ6OYHXBSDKLSYQ4RJA5CNFSM4TIRXJS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUB4TXQ.gif


Outdated. Incremental Refresh does not exist.

Outdated. Incremental Refresh does not exist as an option.

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

ID: ffc816e2-78f6-ca70-92a3-b2153461759d
Version Independent ID: e6fec9a8-1c47-b739-5146-0fa717c4535e
Content: Using incremental refresh with dataflows - Power Query
Content Source: powerquery-docs/dataflows/incremental-refresh.md
Service: powerquery
GitHub Login: @bensack
Microsoft Alias: bensack

#assign:@bensack please see if this is a documentation bug

#assign:bensack

Hi @laser-developer
Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. After review by the engineering team, it was determined that this issue is incorrect. Incremental refresh does exist for Dataflow Gen1 and is also correct in the other docs for best practices. Therefore, we are closing this issue. #please-close